From nobody Sun Aug 3 02:20:15 2014 Return-Path: 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 9EA671A0295 for ; Sun, 3 Aug 2014 02:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 S7FZjESQWeRh for ; Sun, 3 Aug 2014 02:20:08 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6301A0292 for ; Sun, 3 Aug 2014 02:20:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8BABF7C3F0B for ; Sun, 3 Aug 2014 11:20:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wESMNOfX4Cyi for ; Sun, 3 Aug 2014 11:20:02 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:b1bc:6a86:83f5:2db3] (unknown [IPv6:2001:470:de0a:27:b1bc:6a86:83f5:2db3]) by mork.alvestrand.no (Postfix) with ESMTPSA id CCFA57C3F08 for ; Sun, 3 Aug 2014 11:20:01 +0200 (CEST) Message-ID: <53DDFEC1.3020907@alvestrand.no> Date: Sun, 03 Aug 2014 11:20:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060003050403050500050205" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n6RETYgKGSoqIsS-N_nSslP8Heg Subject: Re: [rtcweb] Sending of zero-length messages over data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 09:20:12 -0000 This is a multi-part message in MIME format. --------------060003050403050500050205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/24/2014 10:25 PM, Makaraju, Maridi Raju (Raju) wrote: > > */In conclusion, I think websocket API supports zero length because > websocket protocol supports zero-length data frames. So, it does not > have the issue of 'bufferedAmount' discrepancy. /* > > *//* > > Yes, that is what I meant. > > *//* > > */Ok, good. Websocket is not sending any dummy bytes, so > /**/bufferedAmount is always accurate./* > > */I am still not convinced that to keep data channel API consistent > with websocket API we need to introduce of dummy byte!?/* > > */How about keeping consistency of what goes on wire vs. what user > sent? websocket preserves that, where as data channel won't. /* > The WebSocket protocol is not on-the-wire compatible with the DataChannel protocol. This has not been a design goal, and I don't see any reason to make it one. > *//* > > */IMHO opinion, sending such a dummy byte may have other consequences:/* > > */1./**/App is not aware of what's going on? send() probably meant to > be called with non-empty data, but some error leg could have caused it > become empty, but still a byte will be sent out!!/* > > */2./**/Debugging becomes bit more complex and not intuitive. WebRTC > is already complex, why add more complexity?/* > > */3./**/Interop issues. The more the exceptions the more the interop > issues you see as some implementations may overlook these or implement > them later./* > > *//* > > */It's usually a bad idea to send a dummy byte on wire, without the > application direct involvement./* > I recommend spending some time with Wireshark looking at actual traces before making any such statement. Many protocols have dummy bytes, for many different reasons. > *//* > > */IMHO, if doing PPID_OOB is more effort and can't fit in webrtc 1.0 > then it would be better to delay and do it in more proper way than > taking a shortcut with PPID_EMPTY. With PPID_OOB approach underlying > signaling protocol can negotiate OOB before using it; though such > negotiation is not mandatory, but this approach allows such possibility./* > /*PPID_OOB would make the compatibility problem worse, not better.*/ > > *//* > > *//* > > */I then, rest my case! /**/J/**//* > > *//* > > *//* > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060003050403050500050205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/24/2014 10:25 PM, Makaraju, Maridi Raju (Raju) wrote:

In conclusion, I think websocket API supports zero length because websocket protocol supports zero-length data frames. So, it does not have the issue of ‘bufferedAmount’ discrepancy.

 

 

Yes, that is what I meant. 

<Raju>

Ok, good. Websocket is not sending any dummy bytes, so bufferedAmount is always accurate.

I am still not convinced that to keep data channel API consistent with websocket API we need to introduce of dummy byte!?

How about keeping consistency of what goes on wire vs. what user sent? websocket preserves that, where as data channel won’t.


The WebSocket protocol is not on-the-wire compatible with the DataChannel protocol.
This has not been a design goal, and I don't see any reason to make it one.

IMHO opinion, sending such a dummy byte may have other consequences:

1.       App is not aware of what’s going on? send() probably meant to be called with non-empty data, but some error leg could have caused it become empty, but still a byte will be sent out!!

2.       Debugging becomes bit more complex and not intuitive. WebRTC is already complex, why add more complexity?

3.       Interop issues. The more the exceptions the more the interop issues you see as some implementations may overlook these or implement them later.

 

It’s usually a bad idea to send a dummy byte on wire, without the application direct involvement.


I recommend spending some time with Wireshark looking at actual traces before making any such statement. Many protocols have dummy bytes, for many different reasons.

IMHO, if doing PPID_OOB is more effort and can’t fit in webrtc 1.0 then it would be better to delay and do it in more proper way than taking a shortcut with PPID_EMPTY. With PPID_OOB approach underlying signaling protocol can negotiate OOB before using it; though such negotiation is not mandatory, but this approach allows such possibility.


PPID_OOB would make the compatibility problem worse, not better.

 

I then, rest my case! J

 

</Raju>



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060003050403050500050205-- From nobody Mon Aug 4 11:09:16 2014 Return-Path: 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 A19331A00AE for ; Mon, 4 Aug 2014 11:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 vQ_xUumkMb4v for ; Mon, 4 Aug 2014 11:09:11 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE431A00E1 for ; Mon, 4 Aug 2014 11:08:59 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id E28603A03EFF0; Mon, 4 Aug 2014 18:08:55 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s74I8u5a015645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 14:08:58 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 4 Aug 2014 14:08:56 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Sending of zero-length messages over data channels Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggAI5gwD//74D0IAATLYA///AneCAAFNggP//xY3gAej9c4AAExpK0A== Date: Mon, 4 Aug 2014 18:08:55 +0000 Message-ID: References: <53DDFEC1.3020907@alvestrand.no> In-Reply-To: <53DDFEC1.3020907@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4EC8B4US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pDzFF5sbbrqoOjecj6RJX35TdV8 Subject: Re: [rtcweb] Sending of zero-length messages over data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:09:14 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E4EC8B4US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >IMHO opinion, sending such a dummy byte may have other consequences: 1. >App is not aware of what's going on? send() probably meant to be c= alled >with non-empty data, but some error leg could have caused it become = >empty, but still a byte will be sent out!! 2. >Debugging becomes bit more complex and not intuitive. WebRTC is >a= lready complex, why add more complexity? 3. >Interop issues. The more the exceptions the more the interop issue= s you >see as some implementations may overlook these or implement them >la= ter. >It's usually a bad idea to send a dummy byte on wire, without the applicat= ion >direct involvement. >I recommend spending some time with Wireshark looking at actual traces >be= fore making any such statement. Many protocols have dummy bytes, for >many = different reasons. I am afraid there is some confusion about my comment and as a result we may= be talking about dummy bytes at 2 different levels: app level and underlyi= ng protocol level. I am aware of many protocols using reserved bits, bytes, padded bits/bytes,= protocol-level heartbeats/PING-PONGs (SCTP heartbeats use of opaque data).= In all these cases the mechanism is built into the protocol below app-leve= l protocol itself with no direct involvement of application-level protocol.= My comment was in the context of application-level protocol. If app calls send() 3 times with data "abc", "" (empty/null data with size = 0) and then "xyz" then on the wire in the application-level payload you see= "abc" "xyz". So, can you please point to me a protocol where this kind of dummy byte(s) = are inserted in between application payload? Btw, If you leave the app choice to send the byte (using OOB_PPID) then the= re is a possibility for the app to send 256 distinct values instead of brow= ser hard-coding the byte to zero always, which just conveys a single value. >PPID_OOB would make the compatibility problem worse, not better. I would appreciate if you can provide reasons on why PPID_OOB making compat= ibility worse? With PPID_OOB, apps have a choice to negotiate (this negotiation is like an= y other negotiation for webrtc.) and use this option. PPID_EMPTY option see= ms to be enabled always and no way to turn-off. Without an option to turn off PPID_EMPTY, you will get into more compatibil= ity issues as some webrtc implementations may not implement it on day one; = a native client could be using an interim version of a popular webrtc lib; = or it might be using its own webrtc lib, in which case we can't expect it t= o implement all these later-adders in a timely manner. BR Raju --_000_E1FE4C082A89A246A11D7F32A95A17828E4EC8B4US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

>IMHO opinion, s= ending such a dummy byte may have other consequences:

1.      >App is not awa= re of what’s going on? send() probably meant to be called >with no= n-empty data, but some error leg could have caused it become >empty, but still a byte will be sent out!!

2.      >Debugging beco= mes bit more complex and not intuitive. WebRTC is >already complex, why = add more complexity?

3.      >Interop issues= . The more the exceptions the more the interop issues you >see as some i= mplementations may overlook these or implement them >later.

 

>It’s usua= lly a bad idea to send a dummy byte on wire, without the application >di= rect involvement.


>I recommend spending some time with Wireshark looking at actual traces = >before making any such statement. Many protocols have dummy bytes, for = >many different reasons.

<Raju2>

I am afraid there i= s some confusion about my comment and as a result we may be talking about d= ummy bytes at 2 different levels: app level and underlying protocol level.

I am aware of many = protocols using reserved bits, bytes, padded bits/bytes, protocol-level hea= rtbeats/PING-PONGs (SCTP heartbeats use of opaque data). In all these cases the mechanism is built into the protocol below app-leve= l protocol itself with no direct involvement of application-level protocol.= My comment was in the context of application-level protocol.

If app calls send()= 3 times with data “abc”, “” (empty/null data with = size 0) and then “xyz” then on the wire in the application-leve= l payload you see “abc” <dummy byte> “xyz”.<= /i>

So, can you please = point to me a protocol where this kind of dummy byte(s) are inserted in bet= ween application payload?

 

Btw, If you leave t= he app choice to send the byte (using OOB_PPID) then there is a possibility= for the app to send 256 distinct values instead of browser hard-coding the byte to zero always, which just conveys a single value.

 

</Raju2>

 


>PPID_OOB would make the compatibility problem worse, not better.<= /i>
<Raju2>

I would appreciate = if you can provide reasons on why PPID_OOB making compatibility worse?=

With PPID_OOB, apps= have a choice to negotiate (this negotiation is like any other negotiation= for webrtc.) and use this option. PPID_EMPTY option seems to be enabled always and no way to turn-off.

Without an option t= o turn off PPID_EMPTY, you will get into more compatibility issues as some = webrtc implementations may not implement it on day one; a native client could be using an interim version of a popular webrtc lib;= or it might be using its own webrtc lib, in which case we can’t expe= ct it to implement all these later-adders in a timely manner.

 

</Raju2>=

 

BR

Raju=

 <= /p>

--_000_E1FE4C082A89A246A11D7F32A95A17828E4EC8B4US70UWXCHMBA02z_-- From nobody Mon Aug 4 13:45:22 2014 Return-Path: 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 9D9621A030C for ; Mon, 4 Aug 2014 13:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 QjJyqfG_eQpP for ; Mon, 4 Aug 2014 13:45:08 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 820FB1A033C for ; Mon, 4 Aug 2014 13:44:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5E90F7C3E8D; Mon, 4 Aug 2014 22:44:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZQhJPSTL5ch; Mon, 4 Aug 2014 22:44:57 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:99e6:15c8:36c3:4395] (unknown [IPv6:2001:470:de0a:27:99e6:15c8:36c3:4395]) by mork.alvestrand.no (Postfix) with ESMTPSA id 72C587C3E88; Mon, 4 Aug 2014 22:44:57 +0200 (CEST) Message-ID: <53DFF0C8.7000604@alvestrand.no> Date: Mon, 04 Aug 2014 22:44:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Makaraju, Maridi Raju (Raju)" , "rtcweb@ietf.org" References: <53DDFEC1.3020907@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020203080203050204080903" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/L7wgBBapm7ODMDKbgmX_raTaELQ Subject: Re: [rtcweb] Sending of zero-length messages over data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:45:19 -0000 This is a multi-part message in MIME format. --------------020203080203050204080903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Not responding to rest of message. On 08/04/2014 08:08 PM, Makaraju, Maridi Raju (Raju) wrote: > > */>PPID_OOB would make the compatibility problem worse, not better./* > *//* > > */I would appreciate if you can provide reasons on why PPID_OOB making > compatibility worse?/* > Because WebSockets doesn't have any functionality corresponding to PPID_OOB. Adding more functions that WebSockets doesn't have makes compatibility with WebSockets worse. --------------020203080203050204080903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Not responding to rest of message.

On 08/04/2014 08:08 PM, Makaraju, Maridi Raju (Raju) wrote:

>PPID_OOB would make the compatibility problem worse, not better.
<Raju2>

I would appreciate if you can provide reasons on why PPID_OOB making compatibility worse?


Because WebSockets doesn't have any functionality corresponding to PPID_OOB.

Adding more functions that WebSockets doesn't have makes compatibility with WebSockets worse.


--------------020203080203050204080903-- From nobody Mon Aug 4 13:49:21 2014 Return-Path: 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 C62611A0332 for ; Mon, 4 Aug 2014 13:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 rw186V-PvTEt for ; Mon, 4 Aug 2014 13:49:18 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A611A0331 for ; Mon, 4 Aug 2014 13:49:17 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so8313987wes.17 for ; Mon, 04 Aug 2014 13:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7JBs3kw+rM7Ee8ncAhIyQZlVmR2ihoB3joJohk3mwzo=; b=VD5BeQ1SZ/v7dEyzfZS+nB+rNvxWL17JZE/rGmPtLWMsDsWlCrUPjes0gQdOu92e/I Hm64UJp8p3iT8j5D7kyRiQ9DgW446gVyQGK4NldX+x1FPgcnrg2WiQSHO/4yXCVe+QEA hfhpbUkjFHZ8lO2zVSMMYH8ZxffiZdW13+IVm+FBCou0+9o+enhYi13OQs+Kxh89Ag0M C0DdSRhZvAwCNkK93M96etRWV0vapu8nZpTzpmgPPa6Pk5pVEQpJRjb4XQDzrSsPVuln rGbFbbMhtijPMqcP69xk+qmZbfrpZXYnXzEQwlsGSiG0v/pzpme6Y8qnT0kXk+/Nkliw z7KQ== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr35293370wjb.59.1407185356332; Mon, 04 Aug 2014 13:49:16 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Mon, 4 Aug 2014 13:49:16 -0700 (PDT) In-Reply-To: <53DFF0C8.7000604@alvestrand.no> References: <53DDFEC1.3020907@alvestrand.no> <53DFF0C8.7000604@alvestrand.no> Date: Mon, 4 Aug 2014 13:49:16 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Vug-nyDrR2VsBXyW-l0uNkyXG9A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sending of zero-length messages over data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:49:20 -0000 On 4 August 2014 13:44, Harald Alvestrand wrote: > Adding more functions that WebSockets doesn't have makes compatibility with > WebSockets worse. Not that this is a good example, but I really wish this wasn't the yardstick we keep on trotting out. From nobody Mon Aug 4 14:08:18 2014 Return-Path: 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 9822B1A032E for ; Mon, 4 Aug 2014 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 R8odI93A4FbW for ; Mon, 4 Aug 2014 14:08:11 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD151A032C for ; Mon, 4 Aug 2014 14:08:10 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 4EC89C76C14C0; Mon, 4 Aug 2014 21:08:06 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s74L87so005717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 17:08:08 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 4 Aug 2014 17:08:07 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Sending of zero-length messages over data channels Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggAI5gwD//74D0IAATLYA///AneCAAFNggP//xY3gAej9c4AAExpK0AA3G/IAAAf73sA= Date: Mon, 4 Aug 2014 21:08:06 +0000 Message-ID: References: <53DDFEC1.3020907@alvestrand.no> <53DFF0C8.7000604@alvestrand.no> In-Reply-To: <53DFF0C8.7000604@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4ED9F4US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mIhT2rKq_Eo5duFNZS463md48YM Subject: Re: [rtcweb] Sending of zero-length messages over data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 21:08:13 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E4ED9F4US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Because WebSockets doesn't have any functionality corresponding to >PPID_O= OB. >Adding more functions that WebSockets doesn't have makes compatibility >wi= th WebSockets worse. Per the discussions I thought only backward compatibility with Websocket AP= I is what's desired with data channel API. Does it also mean data channel A= PI can't add new APIs while maintaining compatibility to existing ones? I d= on't see a reason why new APIs can't be added and be restricted by websocke= t API though! Such restriction will limit the data channel API and won't al= low leveraging on the flexibility provided by data channel's SCTP transport= only. BR Raju --_000_E1FE4C082A89A246A11D7F32A95A17828E4ED9F4US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Because WebSockets doesn't have any functionality corre= sponding to >PPID_OOB.

>Adding more functions that WebSock= ets doesn't have makes compatibility >with WebSockets worse.

<Raju>

Per the discussions= I thought only backward compatibility with Websocket API is what’s d= esired with data channel API. Does it also mean data channel API can’t add new APIs while maintaining compatibility to existing ones?= I don’t see a reason why new APIs can’t be added and be restri= cted by websocket API though! Such restriction will limit the data channel = API and won’t allow leveraging on the flexibility provided by data channel’s SCTP transport only.

 

</Raju><= /o:p>

 

BR

Raju=

--_000_E1FE4C082A89A246A11D7F32A95A17828E4ED9F4US70UWXCHMBA02z_-- From nobody Mon Aug 4 17:19:37 2014 Return-Path: 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 E79101A0010 for ; Mon, 4 Aug 2014 17:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 RqEKV46rVwx2 for ; Mon, 4 Aug 2014 17:19:17 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611831A0AB5 for ; Mon, 4 Aug 2014 17:19:12 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id id10so310061vcb.21 for ; Mon, 04 Aug 2014 17:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ns4+VaMn7ZX+NjQrbnnlaXiGqhJ1I1qmcXv0xklfHDg=; b=DFNHSjOC6MtFkbNAtJo8V6C09wbCg1NitOvoZdaN+rk+1YbaW85xM6qmNSX2tA+nSU MNpy+Wm9j9/cV0gAz1Gl3kegsxg9Saq+pyfxY46mPG1taz5ufk9CuvQgONlbHynfGQzC FlO4P6NQiZoZ4tWpfZiXLQZylZxNpkY2pEOmTUEy4CX5rZV1E0SzlfCtEtVkjE3fO4BJ wCDcIBq1vj/f0a7zXJTufCqaLUFvs06vKB7rr0HZsNiLALrsBJBLk14WzvIn2kXd2Zgg ppIhiIJBbnavZmGMVjAboJ1zgDoron5FSgsRCSV3t/NyxoyZW/3liX5fDft9JPu+XCPl Rzkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ns4+VaMn7ZX+NjQrbnnlaXiGqhJ1I1qmcXv0xklfHDg=; b=OsVlPLpL0gU50Gf5nC8+kblh42fEUC0wMHQ5cvJ0Uuc+qw8pAPgFuWDYusVtrgSa/t LVHFwn6x1eRI/NksEZ2X6HaVUB0ACtevmJrmNzr2NaIDCfwDCuPuvILUD1z0EkwoReR7 lfQGUZvlWZEpT7pRgVsZI+bl2Q4kwQCKvN3nNSVHGn+DelFylkMHj9eEzh4H2dYnx9B4 w8Nrbd9xsNy5u3/is2PdLJEhFl/EEjp7gpN8W821q0M8X183XHbIVzQwbWOgoOon7HYp 0RmB4Y/VXIXXoPD+Uygpo6Gk5SDAUgXjIJDe63t9zuFaIS1vFdCAkQN0WxsZM3Pu73tb SY6A== X-Gm-Message-State: ALoCoQnHsLaLBEdKRRXdTQViUUsjrR+c9jZwizQChnjy8ywwMt3ETb09uuIsQZlf87NrIf5+b/2o X-Received: by 10.221.9.72 with SMTP id ov8mr132914vcb.27.1407197951457; Mon, 04 Aug 2014 17:19:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Mon, 4 Aug 2014 17:18:51 -0700 (PDT) In-Reply-To: References: <53DDFEC1.3020907@alvestrand.no> From: Justin Uberti Date: Mon, 4 Aug 2014 17:18:51 -0700 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=089e0117772106ba2504ffd6cefc Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SZENwrMJbpvbkCsGU7DFFFywRo0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sending of zero-length messages over data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 00:19:19 -0000 --089e0117772106ba2504ffd6cefc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 4, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > > > > *>IMHO opinion, sending such a dummy byte may have other consequences:* > > 1. *>App is not aware of what=E2=80=99s going on? send() probably me= ant to > be called >with non-empty data, but some error leg could have caused it > become >empty, but still a byte will be sent out!!* > > 2. *>Debugging becomes bit more complex and not intuitive. WebRTC is > >already complex, why add more complexity?* > > 3. *>Interop issues. The more the exceptions the more the interop > issues you >see as some implementations may overlook these or implement > them >later.* > > > > *>It=E2=80=99s usually a bad idea to send a dummy byte on wire, without t= he > application >direct involvement.* > > > >I recommend spending some time with Wireshark looking at actual traces > >before making any such statement. Many protocols have dummy bytes, for > >many different reasons. > > * * > > *I am afraid there is some confusion about my comment and as a result we > may be talking about dummy bytes at 2 different levels: app level and > underlying protocol level.* > > *I am aware of many protocols using reserved bits, bytes, padded > bits/bytes, protocol-level heartbeats/PING-PONGs (SCTP heartbeats use of > opaque data). In all these cases the mechanism is built into the protocol > below app-level protocol itself with no direct involvement of > application-level protocol. My comment was in the context of > application-level protocol. * > > *If app calls send() 3 times with data =E2=80=9Cabc=E2=80=9D, =E2=80=9C= =E2=80=9D (empty/null data with > size 0) and then =E2=80=9Cxyz=E2=80=9D then on the wire in the applicatio= n-level payload > you see =E2=80=9Cabc=E2=80=9D =E2=80=9Cxyz=E2=80=9D.* > > *So, can you please point to me a protocol where this kind of dummy > byte(s) are inserted in between application payload?* > > > > *Btw, If you leave the app choice to send the byte (using OOB_PPID) then > there is a possibility for the app to send 256 distinct values instead of > browser hard-coding the byte to zero always, which just conveys a single > value.* > > > > ** > > > What value would this provide to justify the increased complexity? > > *>PPID_OOB would make the compatibility problem worse, not better.* > ** > > *I would appreciate if you can provide reasons on why PPID_OOB making > compatibility worse?* > > *With PPID_OOB, apps have a choice to negotiate (this negotiation is like > any other negotiation for webrtc.) and use this option. PPID_EMPTY option > seems to be enabled always and no way to turn-off. * > > *Without an option to turn off PPID_EMPTY, you will get into more > compatibility issues as some webrtc implementations may not implement it = on > day one; a native client could be using an interim version of a popular > webrtc lib; or it might be using its own webrtc lib, in which case we can= =E2=80=99t > expect it to implement all these later-adders in a timely manner.* > > > I doubt this will be a real-world problem, given that the protocol is still evolving and all implementations need to keep up, but if this turns out to be an issue we can negotiate it in SDP. --089e0117772106ba2504ffd6cefc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Aug 4, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

=C2=A0

=C2=A0

>IMHO opinion, s= ending such a dummy byte may have other consequences:=

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >App is not aware = of what=E2=80=99s going on? send() probably meant to be called >with non= -empty data, but some error leg could have caused it become >empty, but still a byte will be sent out!!

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >Debugging becomes= bit more complex and not intuitive. WebRTC is >already complex, why add= more complexity?

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >Interop issues. T= he more the exceptions the more the interop issues you >see as some impl= ementations may overlook these or implement them >later.<= u>

=C2=A0

>It=E2=80=99s us= ually a bad idea to send a dummy byte on wire, without the application >= direct involvement.


>I recommend spending some time with Wireshark looking at actual traces = >before making any such statement. Many protocols have dummy bytes, for = >many different reasons.

<Raju2>

I am afraid there i= s some confusion about my comment and as a result we may be talking about d= ummy bytes at 2 different levels: app level and underlying protocol level.

I am aware of many = protocols using reserved bits, bytes, padded bits/bytes, protocol-level hea= rtbeats/PING-PONGs (SCTP heartbeats use of opaque data). In all these cases the mechanism is built into the protocol below app-leve= l protocol itself with no direct involvement of application-level protocol.= My comment was in the context of application-level protocol.

If app calls send()= 3 times with data =E2=80=9Cabc=E2=80=9D, =E2=80=9C=E2=80=9D (empty/null da= ta with size 0) and then =E2=80=9Cxyz=E2=80=9D then on the wire in the appl= ication-level payload you see =E2=80=9Cabc=E2=80=9D <dummy byte> =E2=80=9Cxyz=E2=80=9D.<= /u>

So, can you please = point to me a protocol where this kind of dummy byte(s) are inserted in bet= ween application payload?

=C2=A0

Btw, If you leave t= he app choice to send the byte (using OOB_PPID) then there is a possibility= for the app to send 256 distinct values instead of browser hard-coding the byte to zero always, which just conveys a single value.=

=C2=A0

</Raju2>

=C2=A0


What value would this = provide to justify the increased complexity?
=C2=A0
<= div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt">


>PPID_OOB would make the compatibility problem worse, not better.<= /i>
<Raju2>

I would appreciate = if you can provide reasons on why PPID_OOB making compatibility worse?

With PPID_OOB, apps= have a choice to negotiate (this negotiation is like any other negotiation= for webrtc.) and use this option. PPID_EMPTY option seems to be enabled always and no way to turn-off. =

Without an option t= o turn off PPID_EMPTY, you will get into more compatibility issues as some = webrtc implementations may not implement it on day one; a native client could be using an interim version of a popular webrtc lib;= or it might be using its own webrtc lib, in which case we can=E2=80=99t ex= pect it to implement all these later-adders in a timely manner.


I doubt = this will be a real-world problem, given that the protocol is still evolvin= g and all implementations need to keep up, but if this turns out to be an i= ssue we can negotiate it in SDP.
--089e0117772106ba2504ffd6cefc-- From nobody Tue Aug 5 05:25:04 2014 Return-Path: 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 1420D1A0024 for ; Tue, 5 Aug 2014 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 VSEPhAga6JRp for ; Tue, 5 Aug 2014 05:24:56 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 413561A007E for ; Tue, 5 Aug 2014 05:24:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4C5E37C3BDE for ; Tue, 5 Aug 2014 14:24:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfxlaDdLiwSS for ; Tue, 5 Aug 2014 14:24:54 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:4d18:1c69:f6da:c271] (unknown [IPv6:2001:470:de0a:27:4d18:1c69:f6da:c271]) by mork.alvestrand.no (Postfix) with ESMTPSA id 729777C3BCB for ; Tue, 5 Aug 2014 14:24:54 +0200 (CEST) Message-ID: <53E0CD15.4060401@alvestrand.no> Date: Tue, 05 Aug 2014 05:24:53 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EwEc3XZ9NdPbW4YiFocp4vRzhkw Subject: [rtcweb] ALPN question - optional confidentiality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 12:25:03 -0000 In draft-ietf-rtcweb-alpn-00, the following text occurs: Only one of these labels can be used for any given session. A peer acting in the client role MUST NOT offer both identifiers. A peer in the server role that receives a ClientHello containing both labels MUST reject the session, though it MAY accept the confidential option and protect content accordingly. I can't make this match up in my head; the MAY seems to contradict the MUST. If a client sends a ClientHello(c-webrtc, webrtc), the MUST seems to say that the server MUST reject the session, while the MAY seems to say that the server MAY do Accept(c-webrtc). Suggested reformulation: If a client offers both c-webrtc and webrtc, the server MAY accept c-webrtc, but MUST NOT accept webrtc (possibly add: because this makes a downgrade attack possible???) -- Surveillance is pervasive. Go Dark. From nobody Tue Aug 5 06:57:58 2014 Return-Path: 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 54B171B27B3 for ; Tue, 5 Aug 2014 06:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 1rqVxzscB6Je for ; Tue, 5 Aug 2014 06:57:55 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036B11B279D for ; Tue, 5 Aug 2014 06:57:54 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id A549232C2E6AA; Tue, 5 Aug 2014 13:57:51 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s75DvofO009775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 09:57:53 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 5 Aug 2014 09:57:51 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Justin Uberti Thread-Topic: [rtcweb] Sending of zero-length messages over data channels Thread-Index: AQHPpipfEWtPO6jXOES6Y6R7CwNaxJutiTxggAI5gwD//74D0IAATLYA///AneCAAFNggP//xY3gAej9c4AAExpK0AA+lIOAABAOklA= Date: Tue, 5 Aug 2014 13:57:51 +0000 Message-ID: References: <53DDFEC1.3020907@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E4F0239US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/V1-H35DQ92VrqmuVWXi7-p165HU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sending of zero-length messages over data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 13:57:57 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E4F0239US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tbWVudHMgaW5zZXJ0ZWQgYmV0d2VlbiA8UmFqdTM+IGFuZCA8L1JhanUzPg0KDQoNCldoYXQg dmFsdWUgd291bGQgdGhpcyBwcm92aWRlIHRvIGp1c3RpZnkgdGhlIGluY3JlYXNlZCBjb21wbGV4 aXR5Pw0KPFJhanUzPg0KSXQgcHJvdmlkZXMgYSBnZW5lcmljIG1lY2hhbmlzbSBmb3IgYW4gYXBw IHRvIHNlbmQgT09CIGRhdGEgd2l0aGluIHRoZSBzYW1lIGRhdGEgY2hhbm5lbC4gVGhlIG5ldyBB UEkgY2FuIGJlIHVzZWQgZm9yIHRoZSBoZWFydGJlYXQgcHVycG9zZSBvciBmb3Igc29tZSBvdGhl ciBtb3JlIGlubm92YXRpdmUgdXNlIGNhc2VzIGxpa2Ugc2VuZGluZyBjb250cm9sIGRhdGEgKGUu Zy4gc2VuZGluZyBhIHVzZXLigJlzIGVtcHRpb24gc28gdGhhdCBvdGhlciBlbmQgY2FuIGRpc3Bs YXkgaXQgYXBwcm9wcmlhdGVseSkuIEl0IGFjaGlldmVzIGFsbCBvZiB0aGlzIGluIGEgbW9yZSB0 cmFuc3BhcmVudCB3YXkgdGhhbiBicm93c2VyIGluc2VydGluZyBhIGR1bW15IGJ5dGUuDQpMaWtl IGFueXRoaW5nIGVsc2UsIEkgbG9vayBmb3J3YXJkIHRvIG1lbWJlcnPigJkgZmVlZGJhY2sgb24g dGhpcyB0byBzZWUgaWYgc3VjaCBhIG5lZWQgZXhpc3RzIGFuZCB0aGUgYWRkZWQgQVBJIGFuZCBw cm9jZWR1cmVzIGlzIHdvcnRoIGNvbnNpZGVyaW5nLg0KDQo8L1JhanUzPg0KDQoNCj5QUElEX09P QiB3b3VsZCBtYWtlIHRoZSBjb21wYXRpYmlsaXR5IHByb2JsZW0gd29yc2UsIG5vdCBiZXR0ZXIu DQo8UmFqdTI+DQpJIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNhbiBwcm92aWRlIHJlYXNvbnMg b24gd2h5IFBQSURfT09CIG1ha2luZyBjb21wYXRpYmlsaXR5IHdvcnNlPw0KV2l0aCBQUElEX09P QiwgYXBwcyBoYXZlIGEgY2hvaWNlIHRvIG5lZ290aWF0ZSAodGhpcyBuZWdvdGlhdGlvbiBpcyBs aWtlIGFueSBvdGhlciBuZWdvdGlhdGlvbiBmb3Igd2VicnRjLikgYW5kIHVzZSB0aGlzIG9wdGlv bi4gUFBJRF9FTVBUWSBvcHRpb24gc2VlbXMgdG8gYmUgZW5hYmxlZCBhbHdheXMgYW5kIG5vIHdh eSB0byB0dXJuLW9mZi4NCldpdGhvdXQgYW4gb3B0aW9uIHRvIHR1cm4gb2ZmIFBQSURfRU1QVFks IHlvdSB3aWxsIGdldCBpbnRvIG1vcmUgY29tcGF0aWJpbGl0eSBpc3N1ZXMgYXMgc29tZSB3ZWJy dGMgaW1wbGVtZW50YXRpb25zIG1heSBub3QgaW1wbGVtZW50IGl0IG9uIGRheSBvbmU7IGEgbmF0 aXZlIGNsaWVudCBjb3VsZCBiZSB1c2luZyBhbiBpbnRlcmltIHZlcnNpb24gb2YgYSBwb3B1bGFy IHdlYnJ0YyBsaWI7IG9yIGl0IG1pZ2h0IGJlIHVzaW5nIGl0cyBvd24gd2VicnRjIGxpYiwgaW4g d2hpY2ggY2FzZSB3ZSBjYW7igJl0IGV4cGVjdCBpdCB0byBpbXBsZW1lbnQgYWxsIHRoZXNlIGxh dGVyLWFkZGVycyBpbiBhIHRpbWVseSBtYW5uZXIuDQo8L1JhanUyPg0KSSBkb3VidCB0aGlzIHdp bGwgYmUgYSByZWFsLXdvcmxkIHByb2JsZW0sIGdpdmVuIHRoYXQgdGhlIHByb3RvY29sIGlzIHN0 aWxsIGV2b2x2aW5nIGFuZCBhbGwgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8ga2VlcCB1cCwgYnV0 IGlmIHRoaXMgdHVybnMgb3V0IHRvIGJlIGFuIGlzc3VlIHdlIGNhbiBuZWdvdGlhdGUgaXQgaW4g U0RQLg0KPFJhanUzPg0KSSBhZ3JlZSB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBr ZWVwIHVwLCBidXQgaW4gcmVhbGl0eSB0aGF0IG1heSBub3QgYmUgdHJ1ZS4gSSByZW1lbWJlciB0 aGUgZGlzY3Vzc2lvbiBvZiBjaGFuZ2luZyBEVExTLVNSVFAgdHJhbnNwb3J0IOKAnFJUUC9TQVZQ RuKAnSB0byDigJxVRFAvVExTL1JUUC9TQVZQRuKAnS4gSXQgdG9vayBzb21lIHRpbWUgdG8gY28t b3JkaW5hdGUgdGhlIGNoYW5nZXMgZXZlbiBiZXR3ZWVuIEZpcmVmb3ggYW5kIENocm9tZS4gTm93 IGlmIHdlIHRoaW5rIGFib3V0IG90aGVyIHdlYnJ0YyBpbXBsZW1lbnRhdGlvbnMgKEludGVybmV0 IEV4cGxvcmVyPykgaW4gdGhlIG1peCB0aGVuIHRoZSBpbnRlcm9wIGdldHMgY29tcGxleCB2ZXJ5 IHF1aWNrbHkuDQpJTUhPLCBkZWFsaW5nIHdpdGggaXQgd2hlbiBpdCBoYXBwZW5zIGlzIG9idmlv dXNseSBhIHJlYWN0aXZlIHdheSBhbmQgaGF2aW5nIGEgY2FwYWJpbGl0eSB0byBuZWdvdGlhdGUg dGhpcyAoZWl0aGVyIFBQSURfRU1QVFkgb3IgUFBJRF9PT0IpIGlzIHByb2FjdGl2ZSB3YXkuDQpB Z2FpbiwgSSBsb29rIGZvcndhcmQgdG8gbWVtYmVyc+KAmSBmZWVkYmFjayBvbiB0aGlzLg0KDQo8 L1JhanUzPg0KDQpCUg0KUmFqdQ0KDQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E4F0239US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHMgaW5zZXJ0ZWQgYmV0d2VlbiAmbHQ7 UmFqdTMmZ3Q7IGFuZCAmbHQ7L1JhanUzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCB2 YWx1ZSB3b3VsZCB0aGlzIHByb3ZpZGUgdG8ganVzdGlmeSB0aGUgaW5jcmVhc2VkIGNvbXBsZXhp dHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O1JhanUzJmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBwcm92aWRlcyBhIGdlbmVyaWMgbWVjaGFu aXNtIGZvciBhbiBhcHAgdG8gc2VuZCBPT0IgZGF0YSB3aXRoaW4gdGhlIHNhbWUgZGF0YSBjaGFu bmVsLiBUaGUgbmV3IEFQSSBjYW4gYmUgdXNlZCBmb3IgdGhlIGhlYXJ0YmVhdCBwdXJwb3NlIG9y IGZvciBzb21lIG90aGVyDQogbW9yZSBpbm5vdmF0aXZlIHVzZSBjYXNlcyBsaWtlIHNlbmRpbmcg Y29udHJvbCBkYXRhIChlLmcuIHNlbmRpbmcgYSB1c2Vy4oCZcyBlbXB0aW9uIHNvIHRoYXQgb3Ro ZXIgZW5kIGNhbiBkaXNwbGF5IGl0IGFwcHJvcHJpYXRlbHkpLiBJdCBhY2hpZXZlcyBhbGwgb2Yg dGhpcyBpbiBhIG1vcmUgdHJhbnNwYXJlbnQgd2F5IHRoYW4gYnJvd3NlciBpbnNlcnRpbmcgYSBk dW1teSBieXRlLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpa2UgYW55dGhpbmcg ZWxzZSwgSSBsb29rIGZvcndhcmQgdG8gbWVtYmVyc+KAmSBmZWVkYmFjayBvbiB0aGlzIHRvIHNl ZSBpZiBzdWNoIGEgbmVlZCBleGlzdHMgYW5kIHRoZSBhZGRlZCBBUEkgYW5kIHByb2NlZHVyZXMg aXMgd29ydGggY29uc2lkZXJpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L1JhanUzJmd0Ozwvc3Bhbj4mbmJz cDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8Yj48aT4mZ3Q7UFBJRF9PT0Igd291bGQgbWFrZSB0aGUgY29tcGF0aWJp bGl0eSBwcm9ibGVtIHdvcnNlLCBub3QgYmV0dGVyLjwvaT48L2I+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7UmFqdTImZ3Q7PC9zcGFuPjwvaT48L2I+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNhbiBwcm92 aWRlIHJlYXNvbnMgb24gd2h5IFBQSURfT09CIG1ha2luZyBjb21wYXRpYmlsaXR5IHdvcnNlPzwv c3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aCBQUElEX09P QiwgYXBwcyBoYXZlIGEgY2hvaWNlIHRvIG5lZ290aWF0ZSAodGhpcyBuZWdvdGlhdGlvbiBpcyBs aWtlIGFueSBvdGhlciBuZWdvdGlhdGlvbg0KIGZvciB3ZWJydGMuKSBhbmQgdXNlIHRoaXMgb3B0 aW9uLiBQUElEX0VNUFRZIG9wdGlvbiBzZWVtcyB0byBiZSBlbmFibGVkIGFsd2F5cyBhbmQgbm8g d2F5IHRvIHR1cm4tb2ZmLg0KPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5XaXRob3V0IGFuIG9wdGlvbiB0byB0dXJuIG9mZiBQUElEX0VNUFRZLCB5b3Ugd2ls bCBnZXQgaW50byBtb3JlIGNvbXBhdGliaWxpdHkgaXNzdWVzIGFzIHNvbWUNCiB3ZWJydGMgaW1w bGVtZW50YXRpb25zIG1heSBub3QgaW1wbGVtZW50IGl0IG9uIGRheSBvbmU7IGEgbmF0aXZlIGNs aWVudCBjb3VsZCBiZSB1c2luZyBhbiBpbnRlcmltIHZlcnNpb24gb2YgYSBwb3B1bGFyIHdlYnJ0 YyBsaWI7IG9yIGl0IG1pZ2h0IGJlIHVzaW5nIGl0cyBvd24gd2VicnRjIGxpYiwgaW4gd2hpY2gg Y2FzZSB3ZSBjYW7igJl0IGV4cGVjdCBpdCB0byBpbXBsZW1lbnQgYWxsIHRoZXNlIGxhdGVyLWFk ZGVycyBpbiBhIHRpbWVseSBtYW5uZXIuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bHQ7L1JhanUyJmd0Ozwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg ZG91YnQgdGhpcyB3aWxsIGJlIGEgcmVhbC13b3JsZCBwcm9ibGVtLCBnaXZlbiB0aGF0IHRoZSBw cm90b2NvbCBpcyBzdGlsbCBldm9sdmluZyBhbmQgYWxsIGltcGxlbWVudGF0aW9ucyBuZWVkIHRv IGtlZXAgdXAsIGJ1dCBpZiB0aGlzIHR1cm5zIG91dCB0byBiZSBhbiBpc3N1ZSB3ZSBjYW4gbmVn b3RpYXRlIGl0IGluIFNEUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7UmFqdTMmZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB0aGUgaW1wbGVtZW50YXRp b25zIG5lZWQgdG8ga2VlcCB1cCwgYnV0IGluIHJlYWxpdHkgdGhhdCBtYXkgbm90IGJlIHRydWUu IEkgcmVtZW1iZXIgdGhlIGRpc2N1c3Npb24gb2YgY2hhbmdpbmcgRFRMUy1TUlRQIHRyYW5zcG9y dCDigJxSVFAvU0FWUEbigJ0NCiB0byDigJxVRFAvVExTL1JUUC9TQVZQRuKAnS4gSXQgdG9vayBz b21lIHRpbWUgdG8gY28tb3JkaW5hdGUgdGhlIGNoYW5nZXMgZXZlbiBiZXR3ZWVuIEZpcmVmb3gg YW5kIENocm9tZS4gTm93IGlmIHdlIHRoaW5rIGFib3V0IG90aGVyIHdlYnJ0YyBpbXBsZW1lbnRh dGlvbnMgKEludGVybmV0IEV4cGxvcmVyPykgaW4gdGhlIG1peCB0aGVuIHRoZSBpbnRlcm9wIGdl dHMgY29tcGxleCB2ZXJ5IHF1aWNrbHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SU1ITywgZGVhbGluZyB3aXRoIGl0IHdoZW4gaXQgaGFwcGVucyBpcyBvYnZpb3VzbHkgYSByZWFj dGl2ZSB3YXkgYW5kIGhhdmluZyBhIGNhcGFiaWxpdHkgdG8gbmVnb3RpYXRlIHRoaXMgKGVpdGhl ciBQUElEX0VNUFRZIG9yIFBQSURfT09CKSBpcyBwcm9hY3RpdmUgd2F5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5BZ2FpbiwgSSBsb29rIGZvcndhcmQgdG8gbWVtYmVyc+KAmSBmZWVk YmFjayBvbiB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9SYWp1MyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJhanU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E4F0239US70UWXCHMBA02z_-- From nobody Tue Aug 5 11:35:30 2014 Return-Path: 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 1F0951A0051 for ; Tue, 5 Aug 2014 11:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 plARJhpFVd1k for ; Tue, 5 Aug 2014 11:35:28 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 17A641A008B for ; Tue, 5 Aug 2014 11:35:27 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id b6Yn1o0030EZKEL536bTtd; Tue, 05 Aug 2014 18:35:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id b6bT1o00M3ZTu2S3M6bTBj; Tue, 05 Aug 2014 18:35:27 +0000 Message-ID: <53E123EF.50200@alum.mit.edu> Date: Tue, 05 Aug 2014 14:35:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140723133256.14499.93901.idtracker@ietfa.amsl.com> In-Reply-To: <20140723133256.14499.93901.idtracker@ietfa.amsl.com> 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=q20140121; t=1407263727; bh=jvNmmo/ZFTTUIOhsdOq+YdA8i7ZVY+3Q8/1QeeuWkm8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eCCm7tGHxze2RFSVdpVzLx3/UpMR6r7GcSW1c+fhbn6jqfe0V/RGiO/dknIl9R/QA 1TMoVZopj9gjoawd76FBtwTwLhIEYO9fwpXMtTPcaVg8gEVyAEWCXwICLCu20fL4eC 1H3E+c89/ds8FqdhcTydrIdQgfvyjAGGp2m+LxoCjJx1sEY26gyVzNCFQ+8VBde0sX Sl0nhJ+WBXU3A4HmPoY1cfbGTkaeb93ohhKaNragwvfv4GJZWPMFOi3VMfFlZAExyL jjZRWWHVyg2PXkiFl7u3X/vXbBnxGo6awNGYbk8pfZwvLEOcR1E8mnFV/9omcgDTKw 6EXubOMGh5Huw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l0ClkONNRzx51VptY6iU7hUshmQ Subject: [rtcweb] draft-ietf-rtcweb-alpn-00 - in what way is WebRTC an application? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 18:35:29 -0000 Why is WebRTC considered an application? It provides a platform/layer/transport in support of applications. Applications ride on top of it. I guess Meetecho or Webex++ or Skype++ would be plausible applications. Of course this is a constantly changing game. We keep adding layers to the stack, and each time we do what used to be an application becomes just a transport for the next layer. But AFAIK WebRTC is *never* an application in its own right. ISTM that it would be more appropriate if the application identifier identified the complete protocol stack that is riding on top of the layer (in this case DTLS) that is carrying the identifier. E.g. "meetecho/webex" Thanks, Paul From nobody Tue Aug 5 12:59:55 2014 Return-Path: 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 B70671B2B4E for ; Tue, 5 Aug 2014 12:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 mQYiKjs-SLIw for ; Tue, 5 Aug 2014 12:59:52 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A611B2B49 for ; Tue, 5 Aug 2014 12:59:47 -0700 (PDT) Received: by mail-ig0-f174.google.com with SMTP id c1so7600444igq.7 for ; Tue, 05 Aug 2014 12:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tN/krnAVSJcSmZo5pE/bG48Ut7CXYSmPgL5J+E3w41Q=; b=AY0FBnQszXPYFFrBeXlhKwBHruVRnyfkUhJo1N48wlAf25HZuVT5YludTfBTGD/TTG 5gGEeMkxGnNF6MS/ELXxQGm8TeMBF3ZxJ5+KvkpoZifT/sTWKeZLPQHQY6kGl1b8drXJ tMd4XD3ULVOOV0Y2qjxuSbolTgqRdfrueUoOYmqWdyafVcYreA1UxuuKPNPrfPWxU7zl XDa1NUMEaRd2QCjdyQhJLFXnAatpdYfddADreyn5C/L86vCG6vZklZHOJwf8qZv0Rw9w uUlaFrML0TzT4nS6MqEd2u8qL7kWTM396TYXr3giZbMnvOFtHdW6WHOi9An4kULUQb9H Vmgw== MIME-Version: 1.0 X-Received: by 10.42.47.140 with SMTP id o12mr8831146icf.4.1407268787422; Tue, 05 Aug 2014 12:59:47 -0700 (PDT) Received: by 10.43.154.80 with HTTP; Tue, 5 Aug 2014 12:59:47 -0700 (PDT) In-Reply-To: <53E123EF.50200@alum.mit.edu> References: <20140723133256.14499.93901.idtracker@ietfa.amsl.com> <53E123EF.50200@alum.mit.edu> Date: Tue, 5 Aug 2014 12:59:47 -0700 Message-ID: From: Ted Hardie To: Paul Kyzivat Content-Type: multipart/alternative; boundary=90e6ba6149aa2d904304ffe74cfb Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/tLOoJ4HdFI5pp-yD0CGV5IOvem4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-alpn-00 - in what way is WebRTC an application? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 19:59:53 -0000 --90e6ba6149aa2d904304ffe74cfb Content-Type: text/plain; charset=UTF-8 Hi Paul, Think of it this way: ALPN tokens identify application layer protocols. WebRTC may support a raft of applications, but it is a common application layer. Attempting to negotiate each one of the potential applications which might use the layer would be thoroughly unworkable, given the ability of a developer to mint one at will. Thus, it is more important to signal the common aspect--that this application is built on WebRTC protocols and expectations. regards, Ted Hardie On Tue, Aug 5, 2014 at 11:35 AM, Paul Kyzivat wrote: > Why is WebRTC considered an application? It provides a > platform/layer/transport in support of applications. > > Applications ride on top of it. I guess Meetecho or Webex++ or Skype++ > would be plausible applications. > > Of course this is a constantly changing game. We keep adding layers to the > stack, and each time we do what used to be an application becomes just a > transport for the next layer. > > But AFAIK WebRTC is *never* an application in its own right. > > ISTM that it would be more appropriate if the application identifier > identified the complete protocol stack that is riding on top of the layer > (in this case DTLS) that is carrying the identifier. > > E.g. "meetecho/webex" > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --90e6ba6149aa2d904304ffe74cfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Think of it this way:= =C2=A0 ALPN tokens identify application layer protocols.=C2=A0 WebRTC may s= upport a raft of applications, but it is a common application layer.

Attempting to negotiate each one of the potential applicat= ions which might use the layer would be thoroughly unworkable, given the ab= ility of a developer to mint one at will.=C2=A0 Thus, it is more important = to signal the common aspect--that this application is built on WebRTC proto= cols and expectations.

regards,

Ted Hardie


On Tue, Aug 5, 2014 at 11:35 = AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Why is WebRTC considered an application? It = provides a platform/layer/transport in support of applications.

Applications ride on top of it. I guess Meetecho or Webex++ or Skype++ woul= d be plausible applications.

Of course this is a constantly changing game. We keep adding layers to the = stack, and each time we do what used to be an application becomes just a tr= ansport for the next layer.

But AFAIK WebRTC is *never* an application in its own right.

ISTM that it would be more appropriate if the application identifier identi= fied the complete protocol stack that is riding on top of the layer (in thi= s case DTLS) that is carrying the identifier.

E.g. "meetecho/webex"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--90e6ba6149aa2d904304ffe74cfb-- From nobody Tue Aug 5 13:15:35 2014 Return-Path: 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 364AD1B2B70 for ; Tue, 5 Aug 2014 13:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 yU_BneCTD3iT for ; Tue, 5 Aug 2014 13:15:32 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F03D1B2AFD for ; Tue, 5 Aug 2014 13:15:32 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so1611595wev.27 for ; Tue, 05 Aug 2014 13:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I8xTNtL47uB/KRYQuCjm3Hnw7uMualqKY5ZUiPxwli4=; b=dwTIoIK6V3AT7e4TmPjlJ/kO0n7QPSuVtFZnleKc2PsQiwdXPxAdodRl3+FpeMMPDx aBftYFgW/CFsfX8kTdA7cwQF7ZHf10p1nLZLjYkjZnNbrtRk5zDv/y9GExtJVfj7eXoi 4h2j1JhFtnvqP3NpmaKrx/PHxlPC4wH4TCdzZsez4MgmSY5f+b4wmqpKpimkQd98EC7Z SI5gGQD12mafkcOyo7OCMBIKx03kyWXaZfWexFqg0T5ztDlrU5PfGreN3s3928dN5+xc sOiL6TYLU4D/pR8uWlPz9E+DmvMsT2BbG8GJFR2eAIuX13YPF+QzEeLEOumY0w/aOQho D+aw== MIME-Version: 1.0 X-Received: by 10.180.90.11 with SMTP id bs11mr44124654wib.47.1407269730162; Tue, 05 Aug 2014 13:15:30 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Tue, 5 Aug 2014 13:15:30 -0700 (PDT) In-Reply-To: References: <20140723133256.14499.93901.idtracker@ietfa.amsl.com> <53E123EF.50200@alum.mit.edu> Date: Tue, 5 Aug 2014 13:15:30 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TxqIiQetneavWq-IVjB17LQCzBc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-alpn-00 - in what way is WebRTC an application? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Aug 2014 20:15:34 -0000 On 5 August 2014 12:59, Ted Hardie wrote: > Think of it this way: ALPN tokens identify application layer protocols. > WebRTC may support a raft of applications, but it is a common application > layer. We commonly say the same thing about HTTP as an application layer protocol. I don't think that anyone is going to suggest that nothing else goes on above HTTP either. From nobody Tue Aug 5 18:27:39 2014 Return-Path: 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 3DE781A083D for ; Tue, 5 Aug 2014 18:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uo-yRlgjT4KQ for ; Tue, 5 Aug 2014 18:27:36 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECFD1A07AB for ; Tue, 5 Aug 2014 18:27:36 -0700 (PDT) Received: from ppp118-209-58-33.lns20.mel4.internode.on.net ([118.209.58.33]:54010 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XEq0c-0000UM-1w for rtcweb@ietf.org; Wed, 06 Aug 2014 11:27:18 +1000 Message-ID: <53E18482.6090308@nteczone.com> Date: Wed, 06 Aug 2014 11:27:30 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140723133256.14499.93901.idtracker@ietfa.amsl.com> In-Reply-To: <20140723133256.14499.93901.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hAkNP_OnH1JfgbFt8_OH3vAtlCo Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-alpn-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 01:27:38 -0000 The draft defines "webrtc" mixed media and data communications using SRTP and data channels. Does there need to be a value that describes the use of "webrtc data channel only"? E.g. An endpoint may establish a data channel for multiple applications (CLUE, BFCP etc.) without using WebRTC media. Regards, Christian On 23/07/2014 11:32 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Application Layer Protocol Negotiation for Web Real-Time Communications (WebRTC) > Author : Martin Thomson > Filename : draft-ietf-rtcweb-alpn-00.txt > Pages : 7 > Date : 2014-07-23 > > Abstract: > Application Layer Protocol Negotiation (ALPN) labels are defined for > use in identifying Web Real-Time Communications (WebRTC) usages of > Datagram Transport Layer Security (DTLS). Labels are provided for > identifying a session that uses a combination of WebRTC compatible > media and data, and for identifying a session requiring > confidentiality protection. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-alpn/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-alpn-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Aug 7 08:16:04 2014 Return-Path: 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 CB9E11B2C02 for ; Thu, 7 Aug 2014 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 G8nkhdLCDphW for ; Thu, 7 Aug 2014 08:15:52 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4CA1B2CDD for ; Thu, 7 Aug 2014 08:15:36 -0700 (PDT) Received: from [10.96.0.55] (unknown [192.195.83.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 977DB50A86; Thu, 7 Aug 2014 11:15:34 -0400 (EDT) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Aug 2014 08:16:02 -0700 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6yg2idYejfn_Ik923hltF7m9iGw Subject: [rtcweb] Raw notes from IETF91 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:15:56 -0000 You can find the raw notes at (and you can comment on them) at = https://docs.google.com/document/d/1Yl-qToN5KDdGSIhcOfsI5vbqGrDAbyzln-_ktO= OYKM0/edit?usp=3Dsharing As we finalize these, we will get proper ones submitted to list.=20 From nobody Thu Aug 7 12:32:17 2014 Return-Path: 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 070C71AD8CA for ; Thu, 7 Aug 2014 12:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 mssJnAURdXZT for ; Thu, 7 Aug 2014 12:32:06 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375C61A0AFB for ; Thu, 7 Aug 2014 12:32:06 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hy4so6848751vcb.8 for ; Thu, 07 Aug 2014 12:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=tsGqs4tZs7fBKXrIM/RH1rVXd9t1f1P8fIJLRsI9yHA=; b=opSGk1Pltglz17eXk/GAaF9eG9eusOlOIZjgVjN6Y82cu9QZyDMMd17Lie3PX4q89i 0Hn3oAnXMWNK7pDdjTzmhIhEV1RgGkRy6y50OA2uD45fGNGZBH29owucd9Z7OwOEzpM9 6vZRQdtIHyqI6BjMH7uLX9b77c89EdUOMgKjiRTaMfxz7FTN+jcLi8eO2I4w0geEpDgr kO+rt1To+U5OP9hqE+wkh3dgCS5xl3jNHj7gkqg8LULlyTIoUrMSdSPNwreSe8uLOU+4 5BJNcrzHkinqlmBhzuGj6tMPvxHSyWqiEBYw5m5BHF9CdMeimens5yhXGxopV6sYackp MPnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=tsGqs4tZs7fBKXrIM/RH1rVXd9t1f1P8fIJLRsI9yHA=; b=jc4LAEzrhp7RpfnMnoa1CsebWm8jspulLxOAdFLqYYZLvDoi8DOrm68X+X/J2N4Znp w4TR6RQHueZifvUpsGglWFLaND0GHKQIL/LXH46NB/0YbLhPvFbjEYGnhOP1f3l3BGCd bV1r2Tncc/NPWZ7t9CP1mUHuYhX2sHHYQ+++MxRwBhptW4UBnT88UYHCzHVi79FVX3pR QSY7wyjh89Kr730ahBL3A1dJqjOkhKGNAlSjRbKWrJplpR9FoQLWqpOtYijqy9hzBUFQ d5wGLXH/h/1W7Y4W3ZHa5tbQZlem/S+LRwHAJ9z/kg5wqLA80rENAQFqc9J81GXPepg3 c0lg== X-Gm-Message-State: ALoCoQliYrUqHoHA61hs0wnjv6K1DGhNnbRW35OaCC+ZUyrKIGRQfhtut+MPZMPLqJ8evS4LnAmM X-Received: by 10.52.69.172 with SMTP id f12mr3621798vdu.9.1407439925376; Thu, 07 Aug 2014 12:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Thu, 7 Aug 2014 12:31:45 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Thu, 7 Aug 2014 12:31:45 -0700 Message-ID: To: Victoria Kirst , Benjamin Schwartz , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=20cf307cffd6cb916e05000f245f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qx0BvT0KbEvDpWfV5ZI2amodTC4 Subject: Re: [rtcweb] Handling system suspend during an active call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 19:32:08 -0000 --20cf307cffd6cb916e05000f245f Content-Type: text/plain; charset=UTF-8 When screen-sharing in a video conference, it's quite common for the screen-sharing user to stop sharing by closing their laptop. However, when this happens, the browser doesn't give the application or MCU any indication, leading to zombie participants in the conference. (Of course, the MCU will stop receiving packets, but as that could also happen due to transient connectivity issues, we don't want to eject the user upon a brief interruption of RTP packets). One way to deal with this would be for the browser, upon receipt of a suspend notification from the OS, to send an indication that would let the MCU know that the stream is officially terminating. This has to be done by the browser, since the application doesn't get any such notification. For example, the browser could send RTCP BYE for all active RTP streams and terminate any outstanding SCTP associations. While this is different than how the browser treats HTTP connections on suspend, it makes sense in this case because the session really can't be resumed after suspend, as ICE consent will have disappeared within a minute. Alternatively, if we wanted to allow resumption, the browser could send RTCP PAUSED indication (via TMMBN 0) instead. Receipt of BYE/PAUSED message prior to RTP packets ceasing would tell the remote side that the sender intentionally stopped the flow, instead of falling off the Internet. While not perfect, this seems like a simple solution that avoids the complexities of trying to expose power events directly to the application. --20cf307cffd6cb916e05000f245f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When screen-sharing in a video = conference, it's quite common for the screen-sharing user to stop shari= ng by closing their laptop. However, when this happens, the browser doesn&#= 39;t give the application or MCU any indication, leading to zombie particip= ants in the conference. (Of course, the MCU will stop receiving packets, bu= t as that could also happen due to transient connectivity issues, we don= 9;t want to eject the user upon a brief interruption of RTP packets).

One way to deal with this would be for the browser, upon rec= eipt of a suspend notification from the OS, to send an indication that woul= d let the MCU know that the stream is officially terminating. This has to b= e done by the browser, since the application doesn't get any such notif= ication. For example, the browser could send RTCP BYE for all active RTP st= reams and terminate any outstanding SCTP associations. While this is differ= ent than how the browser treats HTTP connections on suspend, it makes sense= in this case because the session really can't be resumed after suspend= , as ICE consent will have disappeared within a minute. Alternatively, if w= e wanted to allow resumption, the browser could send=C2=A0RTCP PAUSED=C2=A0indication (via TMMBN 0) instead.=C2=A0=

Receipt of BYE/PAUSED message prior to RTP packets ceas= ing would tell the remote side that the sender intentionally stopped the fl= ow, instead of falling off the Internet. While not perfect, this seems like= a simple solution that avoids the complexities of trying to expose power e= vents directly to the application.
--20cf307cffd6cb916e05000f245f-- From nobody Thu Aug 7 14:24:36 2014 Return-Path: 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 78CB61B281E for ; Thu, 7 Aug 2014 14:24:34 -0700 (PDT) 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 IeInDNt31yUU for ; Thu, 7 Aug 2014 14:24:33 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD491A028B for ; Thu, 7 Aug 2014 14:24:31 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta09.westchester.pa.mail.comcast.net with comcast id bvYk1o0070vyq2s59xQWLk; Thu, 07 Aug 2014 21:24:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id bxQW1o00N3ZTu2S3RxQWsj; Thu, 07 Aug 2014 21:24:30 +0000 Message-ID: <53E3EE8E.90205@alum.mit.edu> Date: Thu, 07 Aug 2014 17:24:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" 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=q20140121; t=1407446670; bh=s0eEfyb3pxb113uwMsOTPD8obcshU/Oo3ABNZ69GQjQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s1ArJu2tNYxnjoyAs9UipWH+1Qi/APMtTuO7mQR49FXR2f1zqQiqr63ULzJX1CkGE D99YDccM6q4Y5OWUDjLVJWW+XI5jewimOWR4B1VuZ0/QXrIrz+6/Be4MNPN9B6ypt5 imUFeV4gtKZG8OYcAPNNZrhvMbEkO03mDP6zVC6tJt7arl6FozYSXDXA6qIO3/AvyQ KhWPWevMtyaj/T4RpLRr183Oi4aIqb9FhWORQ3PsOCPX3o6RAVtcGenl5A/rdd8d8C 7dVY/zlXjwd7LTWkWY5DsOBeARRjfZPGoCg99/SBDZvTyNynzny/eqvwML7yOToigq 2odeKoYGkgNSw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Bw34RKoI9D11PqRs9BFGQWV68_E Subject: [rtcweb] ALPN question - other labels? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:24:34 -0000 Section 2 says: The following identifiers are defined for use in ALPN: ... Only one of these labels can be used for any given session. A peer acting in the client role MUST NOT offer both identifiers. A peer in the server role that receives a ClientHello containing both labels MUST reject the session, though it MAY accept the confidential option and protect content accordingly. This does not quite say that a peer in a server role must reject a session that contains some *other* label. It doesn't even explicitly forbid a peer in a client role from offering some other label. Does it intend to do so? This could be an issue in interoperation. For instance, if CLUE endpoints want to be capable of interoperating with WebRTC devices must they always use one of the webrtc ALPN values? This could be handled saying that any other ALPN value is to be treated by browsers as equivalent to "webrtc". (Note: we haven't worked out in detail how to interoperate CLUE and WebRTC, but we are trying to ensure we don't do anything to preclude it.) Thanks, Paul From nobody Thu Aug 7 16:26:03 2014 Return-Path: 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 8F4001B28F6 for ; Thu, 7 Aug 2014 16:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 rJ8WeOv_H7RA for ; Thu, 7 Aug 2014 16:25:58 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE251B28D2 for ; Thu, 7 Aug 2014 16:25:57 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so161254wib.2 for ; Thu, 07 Aug 2014 16:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gcLm5o3yb/PXIU/s3TgvIP7FW8yz26pxK9FV8dBwi+I=; b=SYvuEiGWUehGluYYWq5jMZHpUB9289wzCya987oJr03NyE2tzDJCoQMXKh7jby80e+ Vvb3nYhb3eHJS11QiPeElXKOta8D+lNmDtkyFtwGNKjQc0frkPr+OcIHNMq7Hs83HNPG F7EOmMg+zd6HlFdO0CjIA2l2S0x2giBnWJ+BWFONop9MMn17fClFIPXsQnM86vRpn8H4 uBh0EHbjOA5w7KWxKdHEzauoQASyi+WRpkYTsl9AT7lC03BUPB5WbTi734YgtyeO0Jt1 h/tPtpgEvv4KV+zwi8tgYImEWWmp/A8zn7GVuvgB5vuli1gqaCLVSBfwrXzbg+KVbcgL 5Taw== MIME-Version: 1.0 X-Received: by 10.180.90.11 with SMTP id bs11mr574694wib.47.1407453956667; Thu, 07 Aug 2014 16:25:56 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 7 Aug 2014 16:25:56 -0700 (PDT) In-Reply-To: <53E3EE8E.90205@alum.mit.edu> References: <53E3EE8E.90205@alum.mit.edu> Date: Thu, 7 Aug 2014 16:25:56 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UXE1yUbkjhX34qU1OK4GA2Myf28 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ALPN question - other labels? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 23:26:00 -0000 On 7 August 2014 14:24, Paul Kyzivat wrote: > Only one of these labels can be used for any given session. A peer > acting in the client role MUST NOT offer both identifiers. A peer in > the server role that receives a ClientHello containing both labels > MUST reject the session, though it MAY accept the confidential option > and protect content accordingly. > > This does not quite say that a peer in a server role must reject a session > that contains some *other* label. It doesn't even explicitly forbid a peer > in a client role from offering some other label. Does it intend to do so? That's actually old, incorrect text. I need to update the draft, but don't want to do every time that I make a change (I'm not looking to top Ian Hickson's record here). Here's what my copy says: """A peer that is not aware of whether it needs to request confidentiality can use either form. A peer in the client role MUST offer both identifiers if it is not aware of a need for confidentiality. A peer in the server role SHOULD select webrtc if it does not prefer either."" -- https://martinthomson.github.io/drafts/draft-ietf-rtcweb-alpn.html#rfc.section.2 As to whether a completely different protocol is acceptable, the intent was to only cover the interaction of the two labels that are defined in the document. If you want to do webrtc OR some other protocol, I see no reason not to permit that. From nobody Thu Aug 7 19:25:39 2014 Return-Path: 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 96BCC1B292F for ; Thu, 7 Aug 2014 19:25:35 -0700 (PDT) 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 FfNsZvPk6-fd for ; Thu, 7 Aug 2014 19:25:34 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8591B292B for ; Thu, 7 Aug 2014 19:25:34 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta02.westchester.pa.mail.comcast.net with comcast id c1xr1o0061YDfWL512RZnD; Fri, 08 Aug 2014 02:25:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id c2RZ1o0093ZTu2S3g2RZ8V; Fri, 08 Aug 2014 02:25:33 +0000 Message-ID: <53E4351D.5030507@alum.mit.edu> Date: Thu, 07 Aug 2014 22:25:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <53E3EE8E.90205@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407464733; bh=EAmrTWLmCDbKop2v9PgJlqeqSyYFCbTH3nr/TYEUHQo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YS9SgE/Yy9erdmJkef10P7Nijyf/+Y3J0MNzmISqVjztAljcVmo2BNOT6VExXmaDx 9iICVzhDKURsWYpoFtNGgMMGq8SlFYEG3bbiCT/deToyq2+dqgLEDda+WQnnnEM6iy AynK3nnuLklJld0FNPKu6kDrYRc53i1f1uFNvHx2XirrBoGpcNhxedLVuc6vz3ANIh vU/zoARP3p4dNXFi0o3lbz+AG8vmTC/5CNAdRjdPFveGBKWhpiJIbfreNpuC9I7UGo XHE5qhVQfwf5ldNOfSRTT+fYS8K9OHH0sYpULAi62Zd15zUuY9A8KhUuxLq9yr57tz BJZJ1fLTFl6GQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4KAggdZ-HLi9X9R6NPpdsBmpbDs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ALPN question - other labels? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 02:25:35 -0000 On 8/7/14 7:25 PM, Martin Thomson wrote: > On 7 August 2014 14:24, Paul Kyzivat wrote: >> Only one of these labels can be used for any given session. A peer >> acting in the client role MUST NOT offer both identifiers. A peer in >> the server role that receives a ClientHello containing both labels >> MUST reject the session, though it MAY accept the confidential option >> and protect content accordingly. >> >> This does not quite say that a peer in a server role must reject a session >> that contains some *other* label. It doesn't even explicitly forbid a peer >> in a client role from offering some other label. Does it intend to do so? > > That's actually old, incorrect text. I need to update the draft, but > don't want to do every time that I make a change (I'm not looking to > top Ian Hickson's record here). > > Here's what my copy says: > > """A peer that is not aware of whether it needs to request > confidentiality can use either form. A peer in the client role MUST > offer both identifiers if it is not aware of a need for > confidentiality. A peer in the server role SHOULD select webrtc if it > does not prefer either."" > -- https://martinthomson.github.io/drafts/draft-ietf-rtcweb-alpn.html#rfc.section.2 > > As to whether a completely different protocol is acceptable, the > intent was to only cover the interaction of the two labels that are > defined in the document. If you want to do webrtc OR some other > protocol, I see no reason not to permit that. My primary question is how is a browser expected to behave if some other label is offered? Will it still support use of the JSEP APIs? And, for interop reasons, will there be a way to get a browser to offer another label and still support the JSEP APIs if the other end accepts it? Thanks, Paul From nobody Thu Aug 7 19:41:47 2014 Return-Path: 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 4F1CB1B292A for ; Thu, 7 Aug 2014 19:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 NVQ8f-QeW8wB for ; Thu, 7 Aug 2014 19:41:44 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96FB21A0411 for ; Thu, 7 Aug 2014 19:41:44 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so5011971wes.38 for ; Thu, 07 Aug 2014 19:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S5vLZOH/PrO4IQSrre9y5D2yYXkAuWOaYbFpsL05mzM=; b=oUIw8ZYFnevkRCfmfeXCz23hYUXvNScS09uBt5uOP5L991Q78MtR7uyAXjEFFSNJR5 PhxSqUtv2gyiG8idv7Idj3JnU48AZ5+BdZKQkMsoOZhk4b/cOtFgd/KNu8sEj3ZZAp33 hXhgz3Ign72QAWpMSDxKKxGvkee9sHLOQaUEuZQSUcHHYJaJxgwe6jaAqw18YSQSM09o O6zkdjk+ZwatA4yVliutZfM+jqpITn0UkdSYquYXEb/2m52rKMMiUU14kxkeFdgolO4m VVxMKD6g9A//z+t0Ns9+E1RRwuYuvzHVqsAMtm+Sfr8wPQyeh7B6V/EcmKPwijdOwxJx qqxw== MIME-Version: 1.0 X-Received: by 10.180.92.38 with SMTP id cj6mr852307wib.64.1407465703156; Thu, 07 Aug 2014 19:41:43 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 7 Aug 2014 19:41:43 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 7 Aug 2014 19:41:43 -0700 (PDT) In-Reply-To: <53E4351D.5030507@alum.mit.edu> References: <53E3EE8E.90205@alum.mit.edu> <53E4351D.5030507@alum.mit.edu> Date: Thu, 7 Aug 2014 19:41:43 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d043c7faa4530380500152599 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ClCg5x7ZXWxT5ZkyaPEjrLHGXNk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ALPN question - other labels? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 02:41:46 -0000 --f46d043c7faa4530380500152599 Content-Type: text/plain; charset=UTF-8 On Aug 7, 2014 7:25 PM, "Paul Kyzivat" wrote: > My primary question is how is a browser expected to behave if some other label is offered? Will it still support use of the JSEP APIs? ALPN requires that a peer in the server role reject the connection if it can't select a protocol. That is what Firefox will do, though it will tolerate no ALPN extension as long as it doesn't have confidential media. > And, for interop reasons, will there be a way to get a browser to offer another label and still support the JSEP APIs if the other end accepts it? That is an interesting question. You would need to teach the browser that other protocol, I guess. --f46d043c7faa4530380500152599 Content-Type: text/html; charset=UTF-8


On Aug 7, 2014 7:25 PM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:
> My primary question is how is a browser expected to behave if some other label is offered? Will it still support use of the JSEP APIs?

ALPN requires that a peer in the server role reject the connection if it can't select a protocol. That is what Firefox will do, though it will tolerate no ALPN extension as long as it doesn't have confidential media.

> And, for interop reasons, will there be a way to get a browser to offer another label and still support the JSEP APIs if the other end accepts it?

That is an interesting question. You would need to teach the browser that other protocol, I guess.

--f46d043c7faa4530380500152599-- From nobody Fri Aug 8 03:01:30 2014 Return-Path: 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 BE8911B29F8 for ; Fri, 8 Aug 2014 03:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.221 X-Spam-Level: X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 FSBC-xbp7X8Y for ; Fri, 8 Aug 2014 03:01:22 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3786F1B29EF for ; Fri, 8 Aug 2014 03:01:22 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id eu11so7055779pac.17 for ; Fri, 08 Aug 2014 03:01:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=OmV6HXEkD4z5C5327kR6nDJhXwFp7lKZU9yzY4mhD6A=; b=Mng8aJIVU8Nkcw8w6uu76pROZgReT03FAwcPLC9sNWaBNqZL7z5h14WIRjJboZTQm9 d28aQGLE37HMgG3o4Ak5sCoMVbUPyHuhkon6/6vd5sv70tjnQvgA4u6vK8roxTcpx2wO Ebt6lhqJdQg2qlzdoudiQyB+ai907VSyHhlfrNkjH4VPW73Y7WxY+3ToRJNBxgPaCcKS WMFNXFpzSvMVRIAwc2MDFczEdmt2fFRXMcwaxD/GcYWm57ch3ay7KvNne73nJN5o5Npm SafiDihKoHWCXO49yYA9hom8j79OnT4MdNNPPhmRM2oR+NxUkTlwLQvoFiKEuBdfyAcN SrjA== X-Gm-Message-State: ALoCoQmvrd2yzjHn8UW40fvIRLwd5SmU7wur93Z+WH0BzPjPaNBmT0/b8W36L3JidnrHjKRu7r3R X-Received: by 10.66.141.109 with SMTP id rn13mr23581308pab.117.1407492081877; Fri, 08 Aug 2014 03:01:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.61.40 with HTTP; Fri, 8 Aug 2014 03:01:00 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 8 Aug 2014 12:01:00 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lpB-dIo8Okzog00Yd3fMm1V3hHI Subject: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 10:01:28 -0000 Hi, let's assume the following scenario: - Browser and server (ICE-Lite) with just TCP candidates. - Browser sends the DTLS handshake over the TCP nominated (and single) connection. - Media begins. - Later the TCP connection is abruptly closed. The client want to "reset" the communication. So at this point I expect that: 1) Browser MUST open a new TCP connection (obviously). 2) When done it must send Binding Request for the server to allow media fro= m it. 3) Browser MUST NOT perform again the DTLS handshake. The rationale on bullet 3) is that ICE is supposed to be a "virtual socket" and thus a single DTLS handshake must be done regardless which UDP/TCP/SCTP/X.25 transport is used to carried the DTLS data between peers. 4) Said that, and assuming that there is also a UDP ICE valid pair, I also expect (and this is a bit exotic but IMHO it SHOULD work) that the browser should be able to send a DTLS Close Alert over the UDP valid pair (this is, even when the DTLS handshake and RTP is being sent over the TCP nominated pair). Well, I'm pretty sure of all the above, but I consider it a bit exotic and would like to hear opinions :) Regards. --=20 I=C3=B1aki Baz Castillo From nobody Fri Aug 8 09:13:05 2014 Return-Path: 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 BB82E1B2C45 for ; Fri, 8 Aug 2014 09:12:58 -0700 (PDT) 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 xoXYXGMDtBQG for ; Fri, 8 Aug 2014 09:12:57 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 251381B2C46 for ; Fri, 8 Aug 2014 09:12:55 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id cBYh1o0051swQuc55GCuy2; Fri, 08 Aug 2014 16:12:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id cGCu1o00h3ZTu2S3bGCuqT; Fri, 08 Aug 2014 16:12:54 +0000 Message-ID: <53E4F706.6040708@alum.mit.edu> Date: Fri, 08 Aug 2014 12:12:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <53E3EE8E.90205@alum.mit.edu> <53E4351D.5030507@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407514374; bh=lFRJmDIEiyAcflwTXD94klCHmzfIDZWNMNA3dTMSb/M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ck40hVlyqVbgaK8SRjkCSOurOkqP1q/oR/I03drKe2rFRKfCcdlW3oCmm6Nah068F jkpo3dAwXHGaUMssqGMANsongagd4WdQVXT/d9OU84Q4n3xiiE+zgsVPcYLzOzC27m 9quz35942DM2bF8NkNpRcP870EukP9TgNUU1Mp5tv7aUolFSmENcWMr4w5ZGCpi3Iw JNpfECMeHgxtN5uYHstqbHJLJB/rVpG3sjKxtfz7F6vPsY62P7rpKxCl0IRz7rvXHi LhUWwj4HMvgdIa5RizXBsGi4uuCb0brITBuwXf6CcydsCYk1M0CuG5LyjtofruK85J XLBJbCb/Ap0tw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SJbhrsSQ0iZRSh693u47XBBV8XM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ALPN question - other labels? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:12:59 -0000 On 8/7/14 10:41 PM, Martin Thomson wrote: > > On Aug 7, 2014 7:25 PM, "Paul Kyzivat" > wrote: > > My primary question is how is a browser expected to behave if some > other label is offered? Will it still support use of the JSEP APIs? > > ALPN requires that a peer in the server role reject the connection if it > can't select a protocol. That is what Firefox will do, though it will > tolerate no ALPN extension as long as it doesn't have confidential media. Are you saying that the offering and acceptance of ALPN values is controlled totally by the browser, without any influence by the JS app? > > And, for interop reasons, will there be a way to get a browser to > offer another label and still support the JSEP APIs if the other end > accepts it? > > That is an interesting question. You would need to teach the browser > that other protocol, I guess. IMO this would only be interesting if other values can also be used in the server role. For now I think it is more important that you be very clear what you intend. I think it means that CLUE implementations will always need to use "webrtc" as the ALPN for the CLUE data channel, so that it will be right when interoperating with WebRTC. That is possible, though it seems weird when not interoperating. (I'm struggling to figure out what c-webrtc means for a native clue device, such as an MCU.) Thanks, Paul From nobody Fri Aug 8 09:43:32 2014 Return-Path: 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 83A881B2C5D for ; Fri, 8 Aug 2014 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 ZtK9dBsXBcQn for ; Fri, 8 Aug 2014 09:43:20 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69381B2C62 for ; Fri, 8 Aug 2014 09:43:19 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so1326894wiv.17 for ; Fri, 08 Aug 2014 09:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/7tSEexxcukkWUGicyiT46CkQelTRK1SyN4Z591HkxY=; b=PQ6w705EuWCJbgs1W4rTifFMRSkGBAyqVQrJfYy9p9UktUp1SYZe/JoB+1zNc7LqqS rsL+vTRrropSvqmHHypALEjeNBre+b/sQwWho1zdWI9SuLs+ROB9nSgiWp0naucbbOad B/LCTxNfvlxUI9O8/2rwmfVi4SuYZ6bjGoINXQafbTY8gqqdFFyjrCYb0jPL7B/pafzE m/gFYcHZYUq9JYCpXiDx6JYr4aKarpkZeiQgbgi/NugvdWQ9w7kFl1a9wS1rhGIN3Chl uoy7EoIjqaJIes3pkbAtHNs8hKqSRxW5JEhOsJ7C0qwz9lif0BgTJISycnzcfUvAM3hO ChCw== MIME-Version: 1.0 X-Received: by 10.194.205.70 with SMTP id le6mr21627952wjc.25.1407516198410; Fri, 08 Aug 2014 09:43:18 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Fri, 8 Aug 2014 09:43:18 -0700 (PDT) In-Reply-To: <53E4F706.6040708@alum.mit.edu> References: <53E3EE8E.90205@alum.mit.edu> <53E4351D.5030507@alum.mit.edu> <53E4F706.6040708@alum.mit.edu> Date: Fri, 8 Aug 2014 09:43:18 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g7nD0P6ZmURKZk6g11e23wKFnwo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ALPN question - other labels? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 16:43:30 -0000 On 8 August 2014 09:12, Paul Kyzivat wrote: > Are you saying that the offering and acceptance of ALPN values is controlled > totally by the browser, without any influence by the JS app? Well, for the confidential media use case, it has to be. >> > And, for interop reasons, will there be a way to get a browser to >> offer another label and still support the JSEP APIs if the other end >> accepts it? >> >> That is an interesting question. You would need to teach the browser >> that other protocol, I guess. > > IMO this would only be interesting if other values can also be used in the > server role. Do you mean the server can pick something that the client didn't offer? > For now I think it is more important that you be very clear what you intend. > > I think it means that CLUE implementations will always need to use "webrtc" > as the ALPN for the CLUE data channel, so that it will be right when > interoperating with WebRTC. That is possible, though it seems weird when not > interoperating. If the intent is to interoperate with WebRTC, by effectively sitting on top of the WebRTC stack, then I don't find that to be particularly strange. That doesn't mean that you can't define a "clue" token, which may or may not be identical or at least very similar to "webrtc". From nobody Fri Aug 8 13:27:42 2014 Return-Path: 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 800301A0109 for ; Fri, 8 Aug 2014 13:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 sNnq1eM8MlmF for ; Fri, 8 Aug 2014 13:27:31 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46D41A0197 for ; Fri, 8 Aug 2014 13:27:31 -0700 (PDT) Received: by mail-oi0-f44.google.com with SMTP id x69so4058222oia.31 for ; Fri, 08 Aug 2014 13:27:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=VTC9FbXfNpIjyJRZ80MFjT//2KfuFmayI1ID2pRME+M=; b=nANI9UpVWbXp2qGBFJ4By0HfDkIXgw4e6i2JPt7gNoVRgS+xL1Nk42777QBUPObRVl r4WJokA/KGod+R/HBH/CiYMzN32bvDwpSK76IPKWrt8VX6oegBMJdG0goQdLiRTaA+TG q8Vk9DW58MlmNsa5ZWNXqHtQ3W89MAJ+zfwgU0vxrQ/2XY94GbIAwHb1shdn1zie818B /Vbg/SGWdrKMq7ntzdwXlmvDk80SQEhvHxjfjX2GzJ2fM3wAsgmeeELRU5nO3kOABCng SLnnD3GMV98reNNvJ5V/xYo30ZPZYpghMYgOel35noAmd8PlrW3f22Ug4qXffZ8f9Sxc vQ3g== X-Gm-Message-State: ALoCoQnZzdlJEdqHtIlzGyb0wvKFNGPXuC3rXnjn7Cf8Af2jPZrVfEIMe4Z1ojDHRPi2wEznWevu MIME-Version: 1.0 X-Received: by 10.60.103.195 with SMTP id fy3mr33607025oeb.35.1407529651256; Fri, 08 Aug 2014 13:27:31 -0700 (PDT) Received: by 10.76.106.202 with HTTP; Fri, 8 Aug 2014 13:27:31 -0700 (PDT) Date: Fri, 8 Aug 2014 16:27:31 -0400 Message-ID: From: Richard Barnes To: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-protocol@tools.ietf.org Content-Type: multipart/alternative; boundary=089e01182c0adfd46d050024082b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kHjaVomFVVbFiiG8XTGHTC0eQYM Subject: [rtcweb] AD review of draft-ietf-rtcweb-data-protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:27:39 -0000 --089e01182c0adfd46d050024082b Content-Type: text/plain; charset=UTF-8 I have reviewed this document in preparation for IETF LC. In general, it looks good, and I have requested LC. There are some comments below that should be addressed along with IETF LC comments. --Richard MAJOR: Section 4. "To avoid glare..." The term "glare" is undefined in this document, and will probably be unfamiliar to many readers. Please add it to the Terminology section. Section 4. "When using SCTP over DTLS..." This qualification is unnecessary, since data channels always use SCTP/DTLS/UDP: """ The DTLS encapsulation of SCTP packets as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. """ So this should be "Since data channels use the DTLS encapsulation of SCTP..." Section 6. "... all parameters in the DATA_CHANNEL_OPEN message are valid" The receiver MUST fail if the parameters are invalid, but you never define what validation needs to be performed. For example, is the DCEP layer supposed to verify that the Protocol and Label fields are valid UTF-8? Section 10.2. [I-D.ietf-rtcweb-data-channel] This reference needs to be normative, since, after all, this is a protocol for negotiating data channels. MINOR / EDITORIAL: Section 5.1. [packet diagram] The diagram seems to imply that the protocol field starts on a 4-octet boundary, even though this is not true. It might be good if you could find a way to reformat the diagram to make this clearer. Section 5.1. "The suggested value of this field for IANA is 0x03" You're defining the initial contents of this registry. Just say it. Likewise for the same text in Section 5.2. Section 6. "an Stream identifier" -> "a stream identifier" --089e01182c0adfd46d050024082b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document in preparatio= n for IETF LC.=C2=A0 In general, it looks good, and I have requested LC.=C2= =A0 There are some comments below that should be addressed along with IETF = LC comments.
--Richard


MAJOR:

=
Section 4. "To avoid glare..."
The term "= glare" is undefined in this document, and will probably be unfamiliar = to many readers.=C2=A0 Please add it to the Terminology section.

Section 4. "When using SCTP over DTLS..."
This qualification is unnecessary, since data channels always use SCT= P/DTLS/UDP:
"""
=C2=A0=C2=A0 The DTLS encapsulation of= SCTP packets as described in
=C2=A0=C2=A0 [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used.
""= ;"
So this should be "Since data channels use the D= TLS encapsulation of SCTP..."

Section 6. "... a= ll parameters in the DATA_CHANNEL_OPEN message are valid"
The receiver MUST fail if the parameters are invalid, but you never define=20 what validation needs to be performed.=C2=A0 For example, is the DCEP layer= =20 supposed to verify that the Protocol and Label fields are valid UTF-8?
<= br>
Section 10.2. [I-D.ietf-rtcweb-data-channel]
Th= is reference needs to be normative, since, after all, this is a protocol fo= r negotiating data channels.



MINOR / EDITORIAL:

Section 5.1. [packet diagram]
The diagram seems to imply th= at the protocol field starts on a 4-octet boundary, even though this is not= true.=C2=A0 It might be good if you could find a way to reformat the diagr= am to make this clearer.

Section 5.1. "The suggested value of this field for IANA is 0x03&q= uot;
You're defining the initial contents of this registr= y.=C2=A0 Just say it.=C2=A0 Likewise for the same text in Section 5.2.
<= br>
Section 6. "an Stream identifier" -> "a stream ident= ifier"

--089e01182c0adfd46d050024082b-- From nobody Fri Aug 8 13:27:44 2014 Return-Path: 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 C049A1A0109 for ; Fri, 8 Aug 2014 13:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 UAS7g9LupTyO for ; Fri, 8 Aug 2014 13:27:38 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD7F1A0450 for ; Fri, 8 Aug 2014 13:27:33 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id a141so4009236oig.14 for ; Fri, 08 Aug 2014 13:27:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=749B4vthUfRYcLtSYDpFdpA3DfP5mVZPMTPFmX4lCeQ=; b=BUmCEn0/ECU94i0vHwsMbSH2whbAZTORz2TU2YUhQi4KUz6anOgnmeq85yN1XczbSC RMJb7/W7VEX1ACX3d1KG82hO6MazZcBNpSHDvqe0Vje3Ua5RMb8y/J26lWxuXydUiwaS bHlBiWU66Dvwco0dqg4WAPvSdcH0UhFZl9cjztHhXt0/nTQVqfkTFMv8I4CReaLebK9e bIVA/IYn2I0oXwTTyMElEEwzyjeX4R5d92K4KSQo6JqT9M79TPZgoqEDz3u55Ic4fKUt HyRvmM8uqAIgq1PGrYcEccU+PbhXFWQgV1Z7c/Wa0NuwNiN4oKaKyizjNXkmVj1TAykz R+jg== X-Gm-Message-State: ALoCoQn8IfGl2yHszO7ZzGSohvtmtwCAYSDL+E3CQnJglcialGk99+DOa28hUf+sjZkamylM4e+Z MIME-Version: 1.0 X-Received: by 10.60.118.8 with SMTP id ki8mr32724058oeb.29.1407529653325; Fri, 08 Aug 2014 13:27:33 -0700 (PDT) Received: by 10.76.106.202 with HTTP; Fri, 8 Aug 2014 13:27:33 -0700 (PDT) Date: Fri, 8 Aug 2014 16:27:33 -0400 Message-ID: From: Richard Barnes To: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7b47217aff677f050024080a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Zd_BFx8K5j6o4h6C383DLd4KAZM Subject: [rtcweb] AD review of draft-ietf-rtcweb-data-channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:27:40 -0000 --047d7b47217aff677f050024080a Content-Type: text/plain; charset=UTF-8 I have reviewed this document in preparation for IETF Last Call. I have gone ahead and requested last call, but there are some comments below that I would like to be addressed before the document goes to the IESG. --Richard MAJOR: Section 6.2. I'm very concerned about interoperability of data channels given that, e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and (2) DCEP only works if it is used by both endpoints (it resets any streams that are used without DCEP negotiation). In order to avoid interoperability failure of this type, whatever mechanism is used to establish an SCTP association that is used for data channels must also negotiate the mechanism(s) that will be used to establish data channels over that association. That could be directly (by negotiating some data channels at the same time as the association), or indirectly (by indicating that DCEP or some other protocol will be used), but either way, the endpoints of the association need to know how data channels will be negotiated before they can create any data channels. This section needs to state this requirement so that applications using data channels can know that they need to meet it. Section 6.4. This section lists in passing several properties of a data channel, but doesn't give a full definition of all the things that need to be defined in order to define a data channel. Fortunately, such a list is given in draft-ietf-rtcweb-data-protocol (Section 4); I would suggest moving that here. MINOR / EDITORIAL: Figures 1 and 2 list ICE as a separate layer. That seems incorrect, since ICE isn't actually involved once the connection is set up. Section 6.4. "... in-sequence, out-of-sequence, reliable and unreliable as properties of channels" "... (as opposed to SCTP, which applies these concepts to messages)" Section 6.4. "... and waiting for onopen to fire ... meaning of the streams" This sentence doesn't really parse, and it's not clear why these API-level considerations are relevant here. Section 6.4. "stream SCTP identifier" -> "SCTP stream identifier" ? Section 6.6. "The sender SHOULD disable the Nagle algorithm..." A reference to RFC 1122 would be helpful here. --047d7b47217aff677f050024080a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this documen= t in preparation for IETF Last Call.=C2=A0 I have gone ahead and requested = last call, but there are some comments below that I would like to be addres= sed before the document goes to the IESG.
--Richard


MAJOR:

S= ection 6.2.
I'm very concerned about interoperability of data chann= els given that, e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not req= uired, and (2) DCEP only works if it is used by both endpoints (it resets a= ny streams that are used without DCEP negotiation).=C2=A0 In order to avoid= interoperability failure of this type, whatever mechanism is used to estab= lish an SCTP association that is used for data channels must also negotiate= the mechanism(s) that will be used to establish data channels over that as= sociation.=C2=A0 That could be directly (by negotiating some data channels = at the same time as the association), or indirectly (by indicating that DCE= P or some other protocol will be used), but either way, the endpoints of th= e association need to know how data channels will be negotiated before they= can create any data channels.=C2=A0 This section needs to state this requi= rement so that applications using data channels can know that they need to = meet it.

Section 6.4.
This section lists in= passing several properties of a data channel, but doesn't give a full = definition of all the things that need to be defined in order to define a d= ata channel.=C2=A0 Fortunately, such a list is given in draft-ietf-rtcweb-d= ata-protocol (Section 4); I would suggest moving that here.



MINOR / EDITORIAL:

Figures 1 and = 2 list ICE as a separate layer.=C2=A0 That seems incorrect, since ICE isn&#= 39;t actually involved once the connection is set up.

Section = 6.4. "... in-sequence, out-of-sequence, reliable and unreliable as pro= perties of channels"
"... (as opposed to SCTP, which applies these concepts to messag= es)"

Section 6.4. "... and waiting for onopen t= o fire ... meaning of the streams"
This sentence doesn&#= 39;t really parse, and it's not clear why these API-level consideration= s are relevant here.

Section 6.4. "stream SCTP identifier" -= > "SCTP stream identifier" ?

Section 6.= 6. "The sender SHOULD disable the Nagle algorithm..."
A reference to RFC 1122 would be helpful here.
--047d7b47217aff677f050024080a-- From nobody Fri Aug 8 14:21:37 2014 Return-Path: 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 98AC01B27D4; Fri, 8 Aug 2014 14:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4jF1djMCG-2U; Fri, 8 Aug 2014 14:21:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8A51B2799; Fri, 8 Aug 2014 14:21:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140808212123.1328.74407.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 14:21:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kdsuLBxT-It-cPilhpF6Uu5E9QQ Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:21:30 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Data Channels' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Aug 8 14:24:40 2014 Return-Path: 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 7378B1B27BF; Fri, 8 Aug 2014 14:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 F7Q1ivhAOMZr; Fri, 8 Aug 2014 14:24:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3031A0264; Fri, 8 Aug 2014 14:24:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140808212435.32397.39940.idtracker@ietfa.amsl.com> Date: Fri, 08 Aug 2014 14:24:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CaAIh7PvRFB_kGzAiLgPq0Dfaw4 Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (WebRTC Data Channel Establishment Protocol) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:24:37 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Data Channel Establishment Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric Data Channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Aug 8 14:57:35 2014 Return-Path: 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 4336A1A00FC for ; Fri, 8 Aug 2014 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 rHITcjv-5ZOg for ; Fri, 8 Aug 2014 14:57:28 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F5A1A00F2 for ; Fri, 8 Aug 2014 14:57:28 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id i138so4034400oig.13 for ; Fri, 08 Aug 2014 14:57:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ztjwP6L5/FbWcjTt06toFRYvtUL75zZGrN9txY78q2Q=; b=OqMzAVEjQQ4A/biGFMSLX9ijW8JwfR7tLhXSNAuqzuuEZe+/er+JzRhz12uvl1Sizz 7PBHJ3DVJMLAE8WipGtNoQqROjYSquP9XFZyE2slYq63o44ESwvaegNkMzHOgeKE/g0E hGYhNtabv7x60jLc9wVBGccjSqCu7QL+GFX8GBt1VX9sEVzCS34vYWq9W+bXR369G6Pk uNfb9Z8IPX5hd15iD/J6WX0Gh0PzvE1GTw+v5ABLZbGoNJ4iKZDOr01JikQFfsN35F7f UeafRWVU+zZAPoe2Wv7Iyz0fNi824S9cZ+OvG2fzuSvInsmKFAHnDXEji+llfaaefuiM +O5A== X-Gm-Message-State: ALoCoQnB+PMRc3nFtAD0ojC6CvyUQx7kw55yryS2MeNjBeubCbgYcOHhZ9A5ykkLxNs69TFhTSWe MIME-Version: 1.0 X-Received: by 10.60.60.167 with SMTP id i7mr34114389oer.41.1407535047623; Fri, 08 Aug 2014 14:57:27 -0700 (PDT) Received: by 10.76.106.202 with HTTP; Fri, 8 Aug 2014 14:57:27 -0700 (PDT) In-Reply-To: <20140808212123.1328.74407.idtracker@ietfa.amsl.com> References: <20140808212123.1328.74407.idtracker@ietfa.amsl.com> Date: Fri, 8 Aug 2014 17:57:27 -0400 Message-ID: From: Richard Barnes To: "ietf@ietf.org" Content-Type: multipart/alternative; boundary=089e0158bab485e15b0500254a83 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XETbMOesEhi6extY6ynhLgk_gFk Cc: "rtcweb@ietf.org" , IETF-Announce Subject: Re: [rtcweb] Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:57:30 -0000 --089e0158bab485e15b0500254a83 Content-Type: text/plain; charset=UTF-8 Dear IETF, I clicked the "Last Call" button a little too quickly on this one, and have had to pull the draft back into the AD Evaluation state. So feel free to comment in this thread, but know that there will be another (real) Last Call soon. I will make sure that comments from both threads are addressed. Thanks, --Richard On Fri, Aug 8, 2014 at 5:21 PM, The IESG wrote: > > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: > - 'WebRTC Data Channels' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The WebRTC framework specifies protocol support for direct > interactive rich communication using audio, video, and data between > two peers' web-browsers. This document specifies the non-media data > transport aspects of the WebRTC framework. It provides an > architectural overview of how the Stream Control Transmission > Protocol (SCTP) is used in the WebRTC context as a generic transport > service allowing WEB-browsers to exchange generic data from peer to > peer. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > --089e0158bab485e15b0500254a83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear IETF,

I clicked the "Last= Call" button a little too quickly on this one, and have had to pull t= he draft back into the AD Evaluation state.=C2=A0 So feel free to comment i= n this thread, but know that there will be another (real) Last Call soon.= =C2=A0 I will make sure that comments from both threads are addressed.

Thanks,
--Richard


=
On Fri, Aug 8, 2014 at 5:21 PM, The IESG <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'WebRTC Data Channels'
=C2=A0 <draft-ietf-rtcweb-data-channel-11.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08= -22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In eith= er case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0The WebRTC framework specifies protocol support for direct
=C2=A0 =C2=A0interactive rich communication using audio, video, and data be= tween
=C2=A0 =C2=A0two peers' web-browsers. =C2=A0This document specifies the= non-media data
=C2=A0 =C2=A0transport aspects of the WebRTC framework. =C2=A0It provides a= n
=C2=A0 =C2=A0architectural overview of how the Stream Control Transmission<= br> =C2=A0 =C2=A0Protocol (SCTP) is used in the WebRTC context as a generic tra= nsport
=C2=A0 =C2=A0service allowing WEB-browsers to exchange generic data from pe= er to
=C2=A0 =C2=A0peer.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-c= hannel/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb= -data-channel/ballot/


No IPR declarations have been submitted directly on this I-D.



--089e0158bab485e15b0500254a83-- From nobody Fri Aug 8 14:58:00 2014 Return-Path: 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 788031A01F3 for ; Fri, 8 Aug 2014 14:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 a2hbcqbUqVjD for ; Fri, 8 Aug 2014 14:57:50 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041221A0123 for ; Fri, 8 Aug 2014 14:57:45 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id wp18so4338397obc.22 for ; Fri, 08 Aug 2014 14:57:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KGhMTSGWMhlP07WCkDx7twlInuK6MaN3Mrzfhkp6bxc=; b=UsNBNsZnK+3RD4X8hpT4KnBHosM3hmo170OOn2iPJtl8yclf+w9PaBdzQ3gZISj1+I EmyUV5bXBwEf9gkx61qXTSocC10+n9XRuXs2tTI5Z9xR2/XQ3/I1maJD/0nS+M3IiUGB /N+Bg4TvalyNb15IuejkzvVpA/V/xU+5YdjkZu/6uor1m2Dl4zkIZ2x9dNPRzppialPh 3nJoZyJxGdmcEePs51BU50YyTOZGX4VKm7GeiZcp1CTaARqIjSvll2CHDKvgOxCEiPGN H+OrWKRmE5RIee5pPBe2ncvC1mdrKon1MYHgLXZggpX5JH5T7lihM5paqGJkmesR0N3U KqnQ== X-Gm-Message-State: ALoCoQmxVWi84lD/WzUuHoRb5p/E3WN+6fMcAWwRMieqCA9woxHsyRPn4GMijtpc9tj6FFMDTOqJ MIME-Version: 1.0 X-Received: by 10.182.16.200 with SMTP id i8mr12508786obd.68.1407535065419; Fri, 08 Aug 2014 14:57:45 -0700 (PDT) Received: by 10.76.106.202 with HTTP; Fri, 8 Aug 2014 14:57:45 -0700 (PDT) In-Reply-To: <20140808212435.32397.39940.idtracker@ietfa.amsl.com> References: <20140808212435.32397.39940.idtracker@ietfa.amsl.com> Date: Fri, 8 Aug 2014 17:57:45 -0400 Message-ID: From: Richard Barnes To: "ietf@ietf.org" Content-Type: multipart/alternative; boundary=001a11c336ca9575480500254bb3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LL_LEOHB7LBEaYEja_VZcoxjdWE Cc: "rtcweb@ietf.org" , IETF-Announce Subject: Re: [rtcweb] Last Call: (WebRTC Data Channel Establishment Protocol) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:57:59 -0000 --001a11c336ca9575480500254bb3 Content-Type: text/plain; charset=UTF-8 Dear IETF, I clicked the "Last Call" button a little too quickly on this one, and have had to pull the draft back into the AD Evaluation state. So feel free to comment in this thread, but know that there will be another (real) Last Call soon. I will make sure that comments from both threads are addressed. Thanks, --Richard On Fri, Aug 8, 2014 at 5:24 PM, The IESG wrote: > > The IESG has received a request from the Real-Time Communication in > WEB-browsers WG (rtcweb) to consider the following document: > - 'WebRTC Data Channel Establishment Protocol' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-08-22. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The WebRTC framework specifies protocol support for direct > interactive rich communication using audio, video, and data between > two peers' web-browsers. This document specifies a simple protocol > for establishing symmetric Data Channels between the peers. It uses > a two way handshake and allows sending of user data without waiting > for the handshake to complete. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > --001a11c336ca9575480500254bb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear IETF,

I clicked the "Last= Call" button a=20 little too quickly on this one, and have had to pull the draft back into the AD Evaluation state.=C2=A0 So feel free to comment in this thread, but= =20 know that there will be another (real) Last Call soon.=C2=A0 I will make su= re that comments from both threads are addressed.

Thanks,
--R= ichard


O= n Fri, Aug 8, 2014 at 5:24 PM, The IESG <iesg-secretary@ietf.org= > wrote:

The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'WebRTC Data Channel Establishment Protocol'
=C2=A0 <draft-ietf-rtcweb-data-protocol-07.txt> as Proposed Standard<= br>
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08= -22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In eith= er case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


=C2=A0 =C2=A0The WebRTC framework specifies protocol support for direct
=C2=A0 =C2=A0interactive rich communication using audio, video, and data be= tween
=C2=A0 =C2=A0two peers' web-browsers. =C2=A0This document specifies a s= imple protocol
=C2=A0 =C2=A0for establishing symmetric Data Channels between the peers. = =C2=A0It uses
=C2=A0 =C2=A0a two way handshake and allows sending of user data without wa= iting
=C2=A0 =C2=A0for the handshake to complete.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-= protocol/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtcwe= b-data-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.



--001a11c336ca9575480500254bb3-- From nobody Sat Aug 9 11:49:41 2014 Return-Path: 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 A593D1A0196; Sat, 9 Aug 2014 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] 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 vSQSEH-718yU; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66561A0009; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s79ImD3G015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 13:48:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Sat, 9 Aug 2014 13:48:13 -0500 X-Mao-Original-Outgoing-Id: 429302893.093861-e61d2b4180cda6697e5d18b3ca4c2570 Content-Transfer-Encoding: quoted-printable Message-Id: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: To: tsvwg@ietf.org, avt@ietf.org, "clue@ietf.org" , mmusic@ietf.org, rtcweb@ietf.org, rmcat@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SlwUfKPSW6-K3ZwbAV6Np6NGAfA Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 18:48:24 -0000 Hi, The DART working group has started a last call for = draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational = draft describes considerations for the use of DiffServ code points in = situations where one multiplexes multiple RTP packet streams, and = potentially other protocol streams, that share the same 5-tuple.=20 Since this draft is likely of interest to several working groups, I = would like to solicit additional reviews from participants of TSVWG, = AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback = (including feedback to the effect of "this is ready to progress") to the = DART working group mailing list. Thanks! Ben. Begin forwarded message: > Resent-From: draft-alias-bounces@tools.ietf.org > From: Ben Campbell > Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > Date: August 9, 2014 at 12:50:16 PM CDT > Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com > To: dart@ietf.org > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, = Richard Barnes >=20 > This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. = It's available on the data tracker at the following URL: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments = to the authors and the DART mailing list. If you've reviewed it and = think it's good to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 From nobody Mon Aug 11 03:53:23 2014 Return-Path: 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 833781A0475 for ; Mon, 11 Aug 2014 03:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.668] 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 mPpAg61OBCP1 for ; Mon, 11 Aug 2014 03:53:19 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 0059C1A0456 for ; Mon, 11 Aug 2014 03:53:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8FF747C3BBE for ; Mon, 11 Aug 2014 12:53:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDr45MwuRR4n for ; Mon, 11 Aug 2014 12:53:15 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:aca4:57e6:8976:ec2c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 88C9D7C3D20 for ; Mon, 11 Aug 2014 12:53:15 +0200 (CEST) Message-ID: <53E8A09B.5010502@alvestrand.no> Date: Mon, 11 Aug 2014 12:53:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5AXlnptdjSdQj1kzzvj7PTwqmUc Subject: [rtcweb] Negotiating the opening protocol (Re: AD review of draft-ietf-rtcweb-data-channel) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 10:53:21 -0000 On 08/08/2014 10:27 PM, Richard Barnes wrote: > I have reviewed this document in preparation for IETF Last Call. I > have gone ahead and requested last call, but there are some comments > below that I would like to be addressed before the document goes to > the IESG. > --Richard > > > MAJOR: > > Section 6.2. > I'm very concerned about interoperability of data channels given that, > e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and > (2) DCEP only works if it is used by both endpoints (it resets any > streams that are used without DCEP negotiation). In order to avoid > interoperability failure of this type, whatever mechanism is used to > establish an SCTP association that is used for data channels must also > negotiate the mechanism(s) that will be used to establish data > channels over that association. That could be directly (by > negotiating some data channels at the same time as the association), > or indirectly (by indicating that DCEP or some other protocol will be > used), but either way, the endpoints of the association need to know > how data channels will be negotiated before they can create any data > channels. This section needs to state this requirement so that > applications using data channels can know that they need to meet it. I *think* this is a concern we have discussed before, and decided that it's not relevant. There are two states a receiver can be in: 1) It has external knowledge of what is expected on a particular data channel 2) It has no such external knowledge. There are two actions a sender can do: A) Send a data-protocol open packet B) Send data without a data-protocol packet This produces four outcomes: 1A: The sender sends an open packet that the receiver was not expecting. 1B: The sender sends data, and the receiver knows what to expect. All is OK. 2A: The sender sends an open packet, and the receiver knows from the packet what to do. All is OK. 2B: The sender sends data, and the receiver has no configuration to match. 1A and 2B are the problematic cases, and both can occur only as a result of misconfiguration, where the two sides have different opinions. The WG decided to leave out the actual mechanism for this configuration from the spec, and most emphatically did not design an SDP-based mechanism to negotiate some channels. The WG also decided that this decision is done for each channel independently - there is no need for an overall decision for all channels up front. As long as a channel number is free, either mechanism can start using it. Summary: I disagree with the concern. I think this issue has been discussed, and the WG has found consensus that it is a problem that does not need to be solved. Harald From nobody Mon Aug 11 08:08:02 2014 Return-Path: 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 2637F1A0422 for ; Mon, 11 Aug 2014 08:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 4VQcsMIOIkf7 for ; Mon, 11 Aug 2014 08:07:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1714C1A04AE for ; Mon, 11 Aug 2014 08:07:53 -0700 (PDT) Received: from unnumerable.local (pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s7BF7pJb066326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK) for ; Mon, 11 Aug 2014 10:07:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-89-168.dllstx.fios.verizon.net [173.57.89.168] claimed to be unnumerable.local Message-ID: <53E8DC47.2010609@nostrum.com> Date: Mon, 11 Aug 2014 10:07:51 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtcweb@ >> \"rtcweb@ietf.org\"" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/o-IBLjerMoHYmfFSJpUFZ6LYNHE Subject: [rtcweb] EarlyBird registration deadline for SIPit 31 is Monday August 18 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:07:59 -0000 The Early Bird registration deadline for SIPit 31 is Monday August 18. If you haven't already registered, please do so as soon as you can. RjS > SIPit 31 will be held in Nice, France Sep 28 - Oct 3, 2014. > The event will be hosted by ETSI. > > More information, and the registration page, is available at > > Please take advantage of the opportunity to register early. > > In addition to the normal team-to-team testing at the event, > we will be concentrating on several specific interoperability areas: > * Nat and Firewall Traversal using Outbound, TURN, and STUN > * RTCWeb > * Advanced Video scenarios > * Use of TLS and DTLS > > If you're planning to attend and have other areas you would like > have a multi-team focus session around, please let me know. > > RjS From nobody Mon Aug 11 11:14:02 2014 Return-Path: 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 2EF6C1A06AB; Mon, 11 Aug 2014 11:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gwQr1iRh30yS; Mon, 11 Aug 2014 11:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD7F1A065B; Mon, 11 Aug 2014 11:13:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811181357.613.72705.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 11:13:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rnw0Tv3mljgt-K4lJ4leA-e9NxI Cc: rtcweb@ietf.org Subject: [rtcweb] RETRACTION: Last Call: (WebRTC Data Channels) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:13:58 -0000 The IESG would like to retract the current Last Call on the following document: - 'WebRTC Data Channels' as Proposed Standard The document's state has been set back to "AD Evaluation." From nobody Mon Aug 11 11:14:38 2014 Return-Path: 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 60C591A06E7; Mon, 11 Aug 2014 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PmWlcrR-8Ry8; Mon, 11 Aug 2014 11:14:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 559F81A06EA; Mon, 11 Aug 2014 11:14:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811181433.31164.82612.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 11:14:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F6ir4P60tVbPVAWK7u83PFScHMM Cc: rtcweb@ietf.org Subject: [rtcweb] RETRACTION: Last Call: (WebRTC Data Channel Establishment Protocol) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:14:35 -0000 The IESG would like to retract the current Last Call on the following document: - 'WebRTC Data Channel Establishment Protocol' as Proposed Standard The document's state has been set back to "AD Evaluation." From nobody Mon Aug 11 11:42:37 2014 Return-Path: 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 A424A1A0761 for ; Mon, 11 Aug 2014 11:42:36 -0700 (PDT) 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 H5rcRBrF4XhA for ; Mon, 11 Aug 2014 11:42:36 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id BC8F71A075B for ; Mon, 11 Aug 2014 11:42:35 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id dWJ51o0080bG4ec58WibDj; Mon, 11 Aug 2014 18:42:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id dWia1o00L3ZTu2S3PWibA2; Mon, 11 Aug 2014 18:42:35 +0000 Message-ID: <53E90E9A.1070707@alum.mit.edu> Date: Mon, 11 Aug 2014 14:42:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" 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=q20140121; t=1407782555; bh=w5BqCmcVy8GdLei9xjpso95QXIdke+wAg1F+guMdOKw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qyuLUK6W19NUMJkHUjSNDK/9DtH+6G+aIVY5TJDjwITzfhQwwlrrqt9nWHt3EqLFX CQvnjpgxCUsQ6FQKZZEsGKli6WjPsgqI+8zBoqnOCZgN8H1YH1RNbQ2WusSlMuOk0K 7mFD+weHM1Gyux6oMYgXQP5QYXRLaz8y9GnPNtTC7H1RikwQyRxN3VoDHcHi+zX3iQ xwsHpufNIgrzoqNB7uEB7s5j3ecomQ3zgLzB8zQkVud1mum/pQd/0IkuQGZubwSr6B hA3kmsJ1E6UNevDSwyVUPJj/WF3w6rVFSsnF8oAzMu6ZcSy2mxFrACGoF7DZ6TgG0k YnN1KkvONmarg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rKUWxVt9jO4ecHAYmGyj7Q5o2gI Subject: [rtcweb] Some final comments on draft-ietf-rtcweb-data-channel-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:42:36 -0000 I just did another read-through of this draft, and identified a few things that I think need to be cleared up: Association Usage: draft-ietf-mmusic-sctp-sdp specifies new SDP notation for describing SCTP associations. It is not specific to rtcweb. For SCTP m-lines, it is necessary to name an "association-usage". Support for rtcweb data channels is one possible usage. Currently draft-ietf-mmusic-sctp-sdp gives all of its examples using "webrtc-datachannel" as the association-usage. It does *not* currently define an IANA registry for association-usage, but it should. But it really is the wrong place to define this specific usage. Certainly draft-ietf-rtcweb-data-channel provides the *definition* of the usage. IMO it also ought to define and do the IANA registration of the name. (Obviously some coordination is required between this draft and the sctp-sdp draft, so that they are aligned on this.) Also, can we PLEASE use a name that not specific to webrtc? This *will* be used in contexts where webrtc is not being used. (At least by CLUE.) I propose that the name be "data-channel". SCTP port: *Something* needs to talk about SCTP ports. Currently they aren't mentioned either here or in JSEP. Since this document makes the point that this will be a user layer stack, and talks about the layering over DTLS, I think they ought to be mentioned here. They also probably need to be mentioned in JSEP, as part of aligning to the most recent version of draft-ietf-mmusic-sctp-sdp. Only a little bit needs to be stated: that SCTP supports multiple SCTP ports, but that a particular SCTP association uses a single sctp port pair. (One port at each end of the SCTP association.) JSEP needs to specify how these ports are negotiated. (Via reference to draft-ietf-mmusic-sctp-sdp.) Normative requirement for DCEP support: While this draft references ietf-rtcweb-data-protocol normatively, and talks about it, I can find no explicit statement that implementations of this draft MUST also implement DCEP. AFAIK negotiation of the sctp association-usage defined by this draft in intended to mean that DCEP is also supported. Thanks, Paul From nobody Mon Aug 11 11:42:48 2014 Return-Path: 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 54F251A077D for ; Mon, 11 Aug 2014 11:42:40 -0700 (PDT) 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 jTyHsJN0l0Ox for ; Mon, 11 Aug 2014 11:42:39 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 786641A077C for ; Mon, 11 Aug 2014 11:42:39 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta02.westchester.pa.mail.comcast.net with comcast id dUC81o0051wpRvQ51Wifje; Mon, 11 Aug 2014 18:42:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id dWie1o0173ZTu2S3eWieZB; Mon, 11 Aug 2014 18:42:39 +0000 Message-ID: <53E90E9E.6070706@alum.mit.edu> Date: Mon, 11 Aug 2014 14:42:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" 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=q20140121; t=1407782559; bh=FgbPAwaOa0IBPqoUa0GOylubZi3Bb/Qm2v0mdVuiVcI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=by4yVsTnPea9amAZXaXHuJK0Cp9YpBdIAyBIKGTVtE/YDILu5QCEExfHSjlBMI1a8 ZQ+S0HPM4UlBbt/UAlwajuafe+NAvJarKkuDdn9vOeIgvR3VNeLzKj8UQLcJM8SwHh q//nFbLZoorDgyQe4dolwo/+RFOS5iVYd5uHCzAbZBGkMlHLVnTlp2DlALcSJ5OkcE KG9n1F/yex8Kp+73ES8kpjlHrySmtIj6aw7mJFjSmGwCrZCpbMn8Lw3tn3GG1KqC+m msevKv76Dk5AOeJZl18CRCVG9/s6b/s06ZKOnu3hyKvgSFaDjiaSgrdg9hL1v7B9uf EYmsxQMOfaxHw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/l4kEdUy3rW4wUQfjzOmXWhil3tQ Subject: [rtcweb] Some final comments on draft-ietf-rtcweb-data-protocol-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 18:42:40 -0000 I just did another read-through of this draft, and identified a few things that I think need to be cleared up: IIUC the data channel APIs expect that all channels, even those defined out of band, have a well defined set of properties. But those properties are defined in *this* draft that applies only to channels created using DCEP. OTOH, draft-ietf-rtcweb-data-channel-11 is much more vague about channel properties. ISTM that most of the channel property specification should be moved to, or replicated in, draft-ietf-rtcweb-data-channel. And this extends to the definitions for Channel Type, Priority, and Reliability since those also are intended to apply for the data channel API for channels defined out of band. Alternatively, the data channel document could more extensively cross reference this document, or the two documents could be merged into one. One more thing - section 4 says: Please note that there is also no attempt to resolve protocol glare. I cannot figure out what this means. It is unambiguous which end is creating the channel, and that end is *declaring* the protocol to be used on it. There is no possibility of glare. Thanks, Paul From nobody Mon Aug 11 14:26:26 2014 Return-Path: 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 131421A006C for ; Mon, 11 Aug 2014 14:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 6FDaqlym4beC for ; Mon, 11 Aug 2014 14:26:23 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0311A0010 for ; Mon, 11 Aug 2014 14:26:22 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id q107so8914653qgd.0 for ; Mon, 11 Aug 2014 14:26:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=OTwNItwy3V5+9bdulsq7LzeFr5JPeT6I3J/dWAHdst8=; b=fXjF1BQmK8Fy7bONnCnS/WPSHgZzAxUpPfYZrG6MUok3SKj63NJpJkOZmtNt/Z2mGl 5D0rtHGJeGuwIwjxuId7sfhf8pQt8rGAeHEcKJb4zZPykLJCCuif3cSnnBDaFfDSTljV DsDymOCIabXxlxJI+ZRj3l/eSAxGSsYrkF14sT+gr0VN2Y7X040sqgrqAmJZ93/WGLUo ZxMY9yJYWMFSuEtnoGwU/AP1L0/3pzpdRzxNFyuGTmxvfU1GOxonQ6OTwU4rlE1twUDa C5N0XZwkznSCDCN4vYhEBcW5+fbCWQEaSFwiHMN9+plH5cSR3sayecxJ2TNq+9zageMv CHpw== X-Gm-Message-State: ALoCoQmUBEqO6wqWD/oobJzsvJXWtPGZl+7TtT1/1RVCRjQWA45oVAOnKw6MuEMAka4ErXWzah9O X-Received: by 10.224.128.9 with SMTP id i9mr621020qas.50.1407792381985; Mon, 11 Aug 2014 14:26:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.161 with HTTP; Mon, 11 Aug 2014 14:26:01 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 11 Aug 2014 23:26:01 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VolIBzpTyykaNOLyLIvX89v5B8M Subject: [rtcweb] "A DTLS-SRTP handshake establishes one or more SRTP crypto contexts" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 21:26:24 -0000 Hi, may somebody clarify what the following sentence in RFC 5764 (DTLS "use_srtp" extension) Section 4.1 means? "A DTLS-SRTP handshake establishes one or more SRTP crypto contexts" AFAIU a DTLS-SRTP handshake generates keys for inbound and outbound RTP or RTCP or RTP+RTCP media flows, this is, one or two. Is that what the above sentence means? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 11 14:37:31 2014 Return-Path: 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 AB5991A00F9 for ; Mon, 11 Aug 2014 14:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 eVQhIxz9MyJb for ; Mon, 11 Aug 2014 14:37:29 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269001A00FE for ; Mon, 11 Aug 2014 14:37:29 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so9017840wgh.23 for ; Mon, 11 Aug 2014 14:37:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hsDNXbI2kJc6otpbq/gxMPMdfF4NuLaXGW+18PbGr2k=; b=JPIx3hJcNm7gw0r9Hywd5V8GZW0xsxta4CWLZKP/rFMUKO6pqyrd5B6i+tdoBlqHOr 2D05uV+GtQwFD3EnQvGbp7ZOCeGFYh1UzojUrdXKfV3AVnOudbaVLL+rQY35iPvxdbSA g2RbfQSgkuPA6YvPcdkbeX1DXsFsWp4FTdL0VObWJw8EoHjr1ejIyF1TbFKZsMTNHd6r VjwhKBo3/n/UQccLK4wXoPehr4nAQWQEyyu1dGPgtSkOpzphvoLZIaxZH80i2YgV1Tx6 KVToS0S/dXN83e5tD+GTUL8lUr8yFfBlti1HqmYklVfejY/rqVeMlZFJ39NLLPcJL1Wr 6SxA== X-Gm-Message-State: ALoCoQkEP7TNqYWofvP72pcsxhMmjY/TdloAexSpVybdR3CJ/fAuoNRTrkqsP0oj/bQUDnU8jd/c X-Received: by 10.194.109.71 with SMTP id hq7mr489268wjb.114.1407793047777; Mon, 11 Aug 2014 14:37:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 11 Aug 2014 14:36:47 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:a00a:3958:8d95:14f] In-Reply-To: References: From: Eric Rescorla Date: Mon, 11 Aug 2014 14:36:47 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=089e0102e6e687c3ad0500615c84 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5Vl92MrAR6xq3YtBmzcerGNX-C8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "A DTLS-SRTP handshake establishes one or more SRTP crypto contexts" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 21:37:30 -0000 --089e0102e6e687c3ad0500615c84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable See: http://tools.ietf.org/html/rfc3711#section-3.2.3 For the definition of a crypto context. -Ekr On Mon, Aug 11, 2014 at 2:26 PM, I=C3=B1aki Baz Castillo wr= ote: > Hi, may somebody clarify what the following sentence in RFC 5764 (DTLS > "use_srtp" extension) Section 4.1 means? > > "A DTLS-SRTP handshake establishes one or more SRTP crypto contexts" > > AFAIU a DTLS-SRTP handshake generates keys for inbound and outbound > RTP or RTCP or RTP+RTCP media flows, this is, one or two. Is that what > the above sentence means? > > Thanks a lot. > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0102e6e687c3ad0500615c84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See:


For the definition of a crypto context.
=

-Ekr


On Mon, Aug 11, 2014 at 2:26 PM, I=C3=B1ak= i Baz Castillo <ibc@aliax.net> wrote:
Hi, may somebody clarify what the following = sentence in RFC 5764 (DTLS
"use_srtp" extension) Section 4.1 means?

"A DTLS-SRTP handshake establishes one or more SRTP crypto contexts&qu= ot;

AFAIU a DTLS-SRTP handshake generates keys for inbound and outbound
RTP or RTCP or RTP+RTCP media flows, this is, one or two. Is that what
the above sentence means?

Thanks a lot.

--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--089e0102e6e687c3ad0500615c84-- From nobody Mon Aug 11 14:49:56 2014 Return-Path: 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 55AED1A01E4 for ; Mon, 11 Aug 2014 14:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 fZpXPpsS0pHH for ; Mon, 11 Aug 2014 14:49:51 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A43A1A014D for ; Mon, 11 Aug 2014 14:49:51 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id f51so8935816qge.18 for ; Mon, 11 Aug 2014 14:49:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=9cdcPHDOHmiBunRpMATUsvgjksztP2ksfzQ71wjz80Q=; b=MMPFBU+vDJ60I7HMJMniY4p+ZfkfWQcYQLEVh1nwaAT6dHA7VtESfei9PO6VBRsxG2 7UpDcyMwdSTR0dvLlBhelv2SiJLa+n/LvGrzzK2H9O6ILCz6KKCQR7vmNtxbuyVN8c3c +kFLx2djS5uo/VGvEIRvkMCUHe69xWwagmqGlXyg9nONUBZEcN2ZJ6m7eyAoAJa0tLXJ XlBXIwouvqNssXcgML9XiYHSL+bv734WkBTiuMAN0g/zInc1fjJybm2/I4o7MPS+EYSM XjQcak8ATg/bfxNF4Ht6k+SHRO+cF4LGy1MdMmVQzIM8Ad9eJ3fpZsnhFOqAk/EeI93a aiAg== X-Gm-Message-State: ALoCoQlu7SucUcaxQCaH4g1hrTSsv8nXzlm2Cuz5BR9tj6EajBPuSoLjhjVPr4HvB75Ex1uxEqC/ X-Received: by 10.224.1.196 with SMTP id 4mr666181qag.99.1407793790663; Mon, 11 Aug 2014 14:49:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.161 with HTTP; Mon, 11 Aug 2014 14:49:30 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 11 Aug 2014 23:49:30 +0200 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/IOFa3pZcKsR_o5UxYpW_rweEx00 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "A DTLS-SRTP handshake establishes one or more SRTP crypto contexts" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 21:49:52 -0000 2014-08-11 23:36 GMT+02:00 Eric Rescorla : > See: > > http://tools.ietf.org/html/rfc3711#section-3.2.3 > > For the definition of a crypto context. Clear. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Mon Aug 11 15:28:23 2014 Return-Path: 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 39E851A047A for ; Mon, 11 Aug 2014 15:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 npLKvD9cfmrS for ; Mon, 11 Aug 2014 15:28:20 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24101A036D for ; Mon, 11 Aug 2014 15:28:19 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so12469746vcb.29 for ; Mon, 11 Aug 2014 15:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=95YVRXGyARP6J0I6wnwYs1s8UrFobVPKX/ZEr7qzBPc=; b=KJWVZ2QD0UKRYegAW1PlYTVabiy6dwRwBoIdZ8kcLs3zxXKz2zp64wSzLsJD3N0+EP IDxA2xbVoCf3H7DXUcFOsrAPqn1nwDhbN/HsKFWwlMwMmqiDtoUIz3j6icXrzzazHv2R t+GexdycWk3qxBUx5JfttMIRkK3me3RK5Jwxa4w6xMh1zFHn9noeP5HQWLNvMR9W1lIk 8Xk9E2iQBuunqrRnK/cg2KxaUJ2FL+TYb+rBCPOe4Ptnl155sABksuww7gh+jr0Zb3Bo I3UeSw+0NwDwl9YPr+Z5P7FLeY6v8HIiN5fIw0CK2D1gFho2/LBtslpH1ZCyxlta4jnQ UYTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=95YVRXGyARP6J0I6wnwYs1s8UrFobVPKX/ZEr7qzBPc=; b=MmF8WwiyF56H7RUo+xhYQzi5wspylJu0GkW2Ey4KKkoFvLwzMAqWLY6o9Ae1atPAee fpzXF0TwrSGxTYh0nBtROF1RNoD/v+wxizyOQHtBMxcrdKP/On37hHGf7KaYEe7l/yzo Pz1xpS0rE/3rUcy9LvNFtKHlhy1IW5lyXHnpUlrWkDF7UUctiHNwXF0SK3dOzVEI/nS3 nBkd2yENYkfAPfkvQzDdcKSvN9d6ygzEE+YchCGvQQMv0aNobAwsjvQK70SFq8dOxPri qiKJ+bI2dArJUnU1dYgalp6Tmmt6gRpdwPmfaawNV52Rdf5phVqXQBLbui514oK164OH DChg== X-Gm-Message-State: ALoCoQkPk8GIkJV6R7MVd9Fj0sFCsgdd+qTJmgF7Ca7V7t15r2IkFpkj1QMCyIZsbEr3ytwE+bqi X-Received: by 10.52.128.8 with SMTP id nk8mr2594789vdb.48.1407796097717; Mon, 11 Aug 2014 15:28:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Mon, 11 Aug 2014 15:27:57 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Mon, 11 Aug 2014 15:27:57 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec51f8f9d524f4505006212ea Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QaYcC6JM2LO0QdqiSkjgDJl73WI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 22:28:21 -0000 --bcaec51f8f9d524f4505006212ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 8, 2014 at 3:01 AM, I=C3=B1aki Baz Castillo wro= te: > Hi, let's assume the following scenario: > > - Browser and server (ICE-Lite) with just TCP candidates. > > - Browser sends the DTLS handshake over the TCP nominated (and single) > connection. > > - Media begins. > > - Later the TCP connection is abruptly closed. The client want to > "reset" the communication. > > So at this point I expect that: > > 1) Browser MUST open a new TCP connection (obviously). > Yes, per http://tools.ietf.org/html/rfc6544#section-11.1 > > 2) When done it must send Binding Request for the server to allow media > from it. > Yes, as indicated in that same section. > > 3) Browser MUST NOT perform again the DTLS handshake. > > The rationale on bullet 3) is that ICE is supposed to be a "virtual > socket" and thus a single DTLS handshake must be done regardless which > UDP/TCP/SCTP/X.25 transport is used to carried the DTLS data between > peers. > Yes, the DTLS layer is not affected. > > > 4) Said that, and assuming that there is also a UDP ICE valid pair, I > also expect (and this is a bit exotic but IMHO it SHOULD work) that > the browser should be able to send a DTLS Close Alert over the UDP > valid pair (this is, even when the DTLS handshake and RTP is being > sent over the TCP nominated pair). > Any DTLS close alert would nuke the entire DTLS connection, which is currently fatal in Chrome. --bcaec51f8f9d524f4505006212ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 8, 2014 at 3:01 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
Hi, let's assume the following scenario:

- Browser and server (ICE-Lite) with just TCP candidates.

- Browser sends the DTLS handshake over the TCP nominated (and single)
connection.

- Media begins.

- Later the TCP connection is abruptly closed. The client want to
"reset" the communication.=C2=A0

So at this point I expect that:

1) Browser MUST open a new TCP connection (obviously).


2) When done it must send Binding Request for the server to allow media fro= m it.

Yes, as indicated in that same se= ction.

3) Browser MUST NOT perform again the DTLS handshake.

The rationale on bullet 3) is that ICE is supposed to be a "virtual socket" and thus a single DTLS handshake must be done regardless which=
UDP/TCP/SCTP/X.25 transport is used to carried the DTLS data between
peers.

Yes, the DTLS layer is not affec= ted.


4) Said that, and assuming that there is also a UDP ICE valid pair, I
also expect (and this is a bit exotic but IMHO it SHOULD work) that
the browser should be able to send a DTLS Close Alert over the UDP
valid pair (this is, even when the DTLS handshake and RTP is being
sent over the TCP nominated pair).

Any = DTLS close alert would nuke the entire DTLS connection, which is currently = fatal in Chrome.
--bcaec51f8f9d524f4505006212ea-- From nobody Mon Aug 11 20:09:37 2014 Return-Path: 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 EE6451A076B for ; Mon, 11 Aug 2014 20:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xHY3KrhkUYkz for ; Mon, 11 Aug 2014 20:09:34 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758691A0769 for ; Mon, 11 Aug 2014 20:09:34 -0700 (PDT) Received: from ppp118-209-171-186.lns20.mel6.internode.on.net ([118.209.171.186]:56247 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XH2RG-0001k5-6V for rtcweb@ietf.org; Tue, 12 Aug 2014 13:07:54 +1000 Message-ID: <53E98569.4020600@nteczone.com> Date: Tue, 12 Aug 2014 13:09:29 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53E3EE8E.90205@alum.mit.edu> <53E4351D.5030507@alum.mit.edu> <53E4F706.6040708@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Tx2E1eJ80A-zM8c5IWjPnpDK4oE Subject: Re: [rtcweb] ALPN question - other labels? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 03:09:36 -0000 >> For now I think it is more important that you be very clear what you intend. >> >> I think it means that CLUE implementations will always need to use "webrtc" >> as the ALPN for the CLUE data channel, so that it will be right when >> interoperating with WebRTC. That is possible, though it seems weird when not >> interoperating. > If the intent is to interoperate with WebRTC, by effectively sitting > on top of the WebRTC stack, then I don't find that to be particularly > strange. That doesn't mean that you can't define a "clue" token, > which may or may not be identical or at least very similar to > "webrtc". I think it would be simpler to offer a "webrtc-datachannel" ALPN in addition to the ones defined that allows an endpoint to indicate that it is only using datachannel . > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Aug 12 01:52:26 2014 Return-Path: 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 C1F4E1A07AE for ; Tue, 12 Aug 2014 01:52:23 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.668, 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 BXOa-I5GYqRC for ; Tue, 12 Aug 2014 01:52:16 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A091A036A for ; Tue, 12 Aug 2014 01:52:15 -0700 (PDT) Received: from epcpsbgr5.samsung.com (u145.gpu120.samsung.co.kr [203.254.230.145]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NA6008R2RAPYM50@mailout2.samsung.com> for rtcweb@ietf.org; Tue, 12 Aug 2014 17:52:01 +0900 (KST) Received: from epcpsbgx4.samsung.com ( [172.20.52.122]) by epcpsbgr5.samsung.com (EPCPMTA) with SMTP id 9E.9F.15745.1B5D9E35; Tue, 12 Aug 2014 17:52:01 +0900 (KST) X-AuditID: cbfee691-b7f306d000003d81-fb-53e9d5b136f2 Received: from epmailer03 ( [203.254.219.143]) by epcpsbgx4.samsung.com (EPCPMTA) with SMTP id 3A.A6.18761.0B5D9E35; Tue, 12 Aug 2014 17:52:00 +0900 (KST) Message-id: <4A.A6.18761.1B5D9E35@epcpsbgx4.samsung.com> Date: Tue, 12 Aug 2014 08:52:00 +0000 (GMT) From: Kiran Kumar Guduru To: juberti@google.com MIME-version: 1.0 X-MTR: 20140812084706196@kiran.guduru Msgkey: 20140812084706196@kiran.guduru X-EPLocale: en_US.utf-8 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-EPTrCode: X-EPTrName: X-MLAttribute: X-RootMTR: 20140812084706196@kiran.guduru X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N MIME-version: 1.0 Content-type: multipart/related; boundary="=_NamoWEC-sz6ci9q761" X-Generator: Namo ActiveSquare 7 7.0.0.45 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEJsWRmVeSWpSXmKPExsWyRsSkSnfj1ZfBBqc/clus/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLenN7MVfP/LVHHo+kXmBsYHn5m6GDk5hATUJTasvscGYksI mEjsf7cGyhaTuHBvPZDNBVSzlFHi04L1cEXzdm6ESsxhlFi+eCEjSIJXwELi2pFVzCA2i4Cq xKHHJ9hBbDaghl8n1oDVCAskScw49h1ss4iAtMTmibPAapgFQiX6uudDXaQksfbqTVaImYIS J2c+YYFYrCqxeH4zG0RcTWLTvHWMEHFxib8Nj9ghbF6JGe1PoerlJKZ9XcMMYUtLnJ+1gRHm s8XfH0PF+SWO3d4BtJcDrPfJ/WCYMbs3f4H6V0Bi6pmDjBAlWhK7jzlBhPkk1ix8ywIzZdep 5cwwrfe3zGVCdz2zgJPEu8+ToUZqSjxa1MoygVF5FpIydDZMyyygzcxAmxfP8oQIK0pM6X7I DmHbSSyfsJ0dU1xV4teBJawwNVNbD7ChquEAq3nSwbGAkXsVo2hqQXJBcVJ6kalecWJucWle ul5yfu4mRmACO/3v2cQdjPcPWB9inMgIjNiJzFKiyfnAFJhXEm9obGZkYWpiamxkbmlGS2El cd70R0lBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhibeczZe94GtSZx+bMU1LkutndO8D4T efWCZopI3aup0w2VHK9oMV6Kd72+K8zyshtr1ckpMsxrmSptrt7r+vDyQlt1aNa9Q10WRR7/ VgnJP1xvxbFZ1zt3YiI7941MiSe/MrYs3F/iWyoVEPH/m8y84G+Xbi4PO6slkNhxokn186x7 ZcaF7UosxRmJhlrMRcWJAJ0LVbilAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILsWRmVeSWpSXmKPExsVy+t/tft0NV18GG7zabG2x9l87uwOjx5Il P5kCGKPSbDJSE1NSixRS85LzUzLz0m2VvIPjneNNzQwMdQ0tLcyVFPISc1NtlVx8AnTdMnOA pioplCXmlAKFAhKLi5X07WyK8ktLUhUy8otLbJWiDc2N9IwM9EyN9AxNY60MDQyMTIFqEtIy 3p7ezFbw/S9TxaHrF5kbGB98Zupi5OQQElCX2LD6HhuILSFgIjFv50YoW0ziwr31QDYXUM0c RonlixcygiRYBFQlDj0+wQ5iswE1/DqxBiwuLJAkMePYd7ChIgLSEpsnzgKrYRYIlejrng+1 TEli7dWbrCA2r4CgxMmZT1gglqlKLJ7fzAYRV5PYNG8dI0RcXOJvwyN2CJtXYkb7U6h6OYlp X9cwQ9jSEudnbWCEOXrx98dQcX6JY7d3AO3lAOt9cj8YZszuzV+gfhSQmHrmICNEiZbE7mNO EGE+iTUL37LATNl1ajkzTOv9LXOZ0F3PLOAk8e7zZKiRmhKPFrWyTGCUnYWkDJ0N0zILaDMz 0ObFszwhwooSU7ofskPYdhLLJ2xnxxRXlfh1YAkrTM3U1gNsqGo4wGqedHAsYORexSiaWpBc UJyUXmGiV5yYW1yal66XnJ+7iRGcLp8t2cHYcMH6EKMAB6MSD++PwJfBQqyJZcWVuYcYVYDG PNqw+gKjFEtefl6qkgiv+GWgNG9KYmVValF+fFFpTmrxIcb9jMAkMZFZSjQ5H5jk80riDY1N zE2NTS0MDM3NzQaPsJI474JbSUFCAumJJanZqakFqUUwLzBxcEo1MC66pb1lgtWVSzd/HK26 e4i3f4I9R6Ww6a066yOLL9Rzeftt6jzixqVzOv2zzzTLVqO47el3v3w498eQY9N2u/iLO/5f 33Q6c7e7X9PmiWrGi8OSPnkVTp1TIpCarPTx2gGrGS2vlL8vW+KxxqVgefy0vTHJDrfV1/6Y mFY/ae5pz2Nv/plNlU5XYinOSDTUYi4qTgQAZ6JJVEQEAAA= DLP-Filter: Pass X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/B2qhW8dCyMBAIDKu8x1xVTvW7XQ Cc: franklin.blek@gmail.com, rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kiran.guduru@samsung.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 08:52:24 -0000 --=_NamoWEC-sz6ci9q761 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUwgeG1sbnM6diA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6byA9 ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSAidXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bSA9ICJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiPjxIRUFEPg0KPE1FVEEgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4N CjxTVFlMRSBpZD1teXNpbmdsZV9zdHlsZSB0aXRsZT1fX0FjdGl2ZVNxdWFyZV9zdHlsZXNoZWV0 X18gdHlwZT10ZXh0L2Nzcz5QIHsNCglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlh bCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NClREIHsNCglN QVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006 IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0NCkxJIHsNCglNQVJHSU4tVE9QOiA1cHg7IEZPTlQtRkFN SUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiA5cHQNCn0N CkJPRFkgew0KCUxJTkUtSEVJR0hUOiAxLjQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6IEFy aWFsLCBhcmlhbDsgRk9OVC1TSVpFOiA5cHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJTi1UT1A6 IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQpQIHsNCglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJ Ti1CT1RUT006IDBweA0KfQ0Kdlw6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9 DQpvXDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJQkVI QVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQp4XDoqIHsNCglQT1NJVElPTjogcmVsYXRpdmU7 IFZJU0lCSUxJVFk6IGhpZGRlbg0KfQ0KVEQgew0KCVdPUkQtQlJFQUs6IGJyZWFrLWFsbA0KfQ0K VUwgew0KCU1BUkdJTi1UT1A6IDVwdDsgTUFSR0lOLUJPVFRPTTogNXB0OyBNQVJHSU4tTEVGVDog MzBwdA0KfQ0KT0wgew0KCU1BUkdJTi1UT1A6IDVwdDsgTUFSR0lOLUJPVFRPTTogNXB0OyBNQVJH SU4tTEVGVDogMzBwdA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVu dD1BY3RpdmVTcXVhcmU+PC9IRUFEPg0KPEJPRFk+DQo8UD48U1BBTiBzdHlsZT0iRk9OVC1GQU1J TFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDEx cHQiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8RElWIGNsYXNzPVdvcmRTZWN0 aW9uMT4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxp YnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkkgd2Fz IG9uIG15IGJpeiB0cmlwIHNvIG5vdCBhYmxlIHRvIHJlc3BvbmQgdG8geW91ciBtYWlscyBwcm9t cHRseS4gPC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6 IDExcHQiPlM8L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMt c2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5vcnJ5IGZvciB0aGUgZGVs YXllZCByZXNwb25zZS48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog IzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQo8 UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3Nh bnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5UaGUgcmVhc29uIHlv dSBzcGVjaWZpZWQgc2VlbXMgbm90IHN1aXRhYmxlIGluIGFsbCBzY2VuYXJpb3MuPG86cD48L286 cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFw dCI+UGxlYXNlIGZpbmQgdGhlIHNjZW5hcmlvIGV4cGxhaW5lZCB0aHJvdWdoIGJlbG93IGZpZ3Vy ZSA8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9O VC1TSVpFOiAxMXB0Ij5IZXJlIEJyb3dzZXIgc3VwcG9ydHMgT3B1cywgRy43MTEsIEdhdGV3YXkg c3VwcG9ydHMgT3B1cywgRy43MTEgYW5kIEFNUi1XQiwgSWYgd2UgY29uc2lkZXIgYSBjYWxsIGJl dHdlZW4gYSB0aGlyZCBwYXJ0eSBhcHBsaWNhdGlvbiBpbnN0ZWFkIG9mIGJyb3dzZXIsIGxpa2Ug SU1TIG9yIFJDUyBhcHBsaWNhdGlvbiB3aGljaCBzdXBwb3J0cyBBTVItV0IsPG86cD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTog J0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+ VGhlbiB0aGUgY2FsbCBmbG93IHdpbGwgYmUgbGlrZSw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8 UCBzdHlsZT0iVEVYVC1JTkRFTlQ6IC0wLjI1aW47IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIg Y2xhc3M9TXNvTGlzdFBhcmFncmFwaD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJp Jywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPjxTUEFOIHN0 eWxlPSJtc28tbGlzdDogSWdub3JlIj4xLjxTUEFOIHN0eWxlPSJMSU5FLUhFSUdIVDogbm9ybWFs OyBGT05ULVZBUklBTlQ6IG5vcm1hbDsgRk9OVC1TVFlMRTogbm9ybWFsOyBGT05ULUZBTUlMWTog J1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogN3B0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAx MXB0Ij5Ccm93c2VyIHNlbmRzIG9mZmVyIHdpdGggT3B1cywgRy43MTEgYXMgc3VwcG9ydGVkIGNv ZGVjcyBpbiB0aGUgc2FtZSBvcmRlciByZXNwZWN0aXZlbHkuPG86cD48L286cD48L1NQQU4+PC9Q Pg0KPFAgc3R5bGU9IlRFWFQtSU5ERU5UOiAtMC4yNWluOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxm bzEiIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2Fs aWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48U1BB TiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+Mi48U1BBTiBzdHlsZT0iTElORS1IRUlHSFQ6IG5v cm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1J TFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDdwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05U LUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0la RTogMTFwdCI+U2luY2UgR2F0ZXdheSBzdXBwb3J0cyBBTVItV0IgYWxzbywgaXQgc2VuZHMgdGhl IG9mZmVyIHRvIHRoaXJkIHBhcnR5IGFwcCB3aXRoIE9wdXMsIEcuNzExIGFuZCBBTVItV0IgaW4g c2FtZSBvcmRlciByZXNwZWN0aXZlbHkuIChUaGUgcmVhc29uIGZvciBtb3ZpbmcgQU1SLVdCIGxh c3QgaXMgdG8gYXZvaWQgdHJhbnNjb2RpbmcsIGlmIHRoZSByZW1vdGUgY2xpZW50IHN1cHBvcnRz IGVpdGhlciBPcHVzIG9yIEcuNzExKTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJU RVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PFNQQU4gc3R5bGU9Im1zby1s aXN0OiBJZ25vcmUiPjMuPFNQQU4gc3R5bGU9IkxJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtVkFS SUFOVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3 IFJvbWFuJzsgRk9OVC1TSVpFOiA3cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxp YnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPklmIHRo ZSB0aGlyZCBwYXJ0eSBhcHAgcmVzcG9uZHMgd2l0aCBBTVItV0IgdXNpbmcgaXRzIG93biBvcmRl ciBvZiBwcmVmZXJlbmNlIGluIHRoZSBhbnN3ZXIsIGFzIGV4cGxhaW5lZCBieSB5b3UuIChTYXlp bmcgc29tZSByZWFzb24gb2YgcXVhbGl0eSBvciBldGMpLiAoU2luY2UgM0dQUCBzcGVjaWZpY2F0 aW9ucyBhbGxvd3Mgc2VuZGluZyBvbmx5IHNpbmdsZSBjb2RlYyBpbiBhbnN3ZXIsIHRoZSBHYXRl d2F5IG1pZ2h0IHJlY2VpdmUgb25seSBBTVItV0IpPG86cD48L286cD48L1NQQU4+PC9QPg0KPFAg c3R5bGU9IlRFWFQtSU5ERU5UOiAtMC4yNWluOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIGNs YXNzPU1zb0xpc3RQYXJhZ3JhcGg+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScs J3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48U1BBTiBzdHls ZT0ibXNvLWxpc3Q6IElnbm9yZSI+NC48U1BBTiBzdHlsZT0iTElORS1IRUlHSFQ6IG5vcm1hbDsg Rk9OVC1WQVJJQU5UOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nOyBGT05ULVNJWkU6IDdwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvU1BBTj48L1NQQU4+PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFw dCI+QXMgcGVyIHRoZSBSRkMgMzI2NCBHYXRld2F5IE1VU1QgZXN0YWJsaXNoIHRoZSBjYWxsIHdp dGggcmVtb3RlIGNsaWVudCB1c2luZyBBTVItV0IgYW5kIHRoYXQgb2Ygd2l0aCBCcm93c2VyIHdp dGggT3B1cywgd2hpY2ggZm9yY2VzIGl0IHRvIGRvIHRyYW5zY29kaW5nLiAoVGhpcyByZXN1bHRz IGluIGJhZCB1c2VyIGV4cGVyaWVuY2UpLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxl PSJURVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiBjbGFzcz1N c29MaXN0UGFyYWdyYXBoPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PFNQQU4gc3R5bGU9Im1z by1saXN0OiBJZ25vcmUiPjUuPFNQQU4gc3R5bGU9IkxJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQt VkFSSUFOVDogbm9ybWFsOyBGT05ULVNUWUxFOiBub3JtYWw7IEZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJzsgRk9OVC1TSVpFOiA3cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L1NQQU4+PC9TUEFOPjwvU1BBTj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD YWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPlNv IG1vc3Qgb2YgdGhlIEltcGxlbWVudGF0aW9ucyB3aWxsIHJlc3BvbmQgd2l0aCB0aGUgY29kZWMg cHJlZmVyZW5jZXMgc3BlY2lmaWVkIGJ5IG9mZmVyZXIgYW5kIHRyeSB0byByZS1uZWdvdGlhdGUg d2l0aCBpdHMgcHJlZmVyZW5jZXMgd2l0aCBhIHJlLW9mZmVyLiBBbmQgdGhhdCB3YXMgdGhlIHJl YXNvbiB3aHkgUkZDIDMyNjQgUkVDT01NRU5EcyB0byB1c2UgdGhlIGNvZGVjIG9yZGVyIHNhbWUg YXMgdGhhdCBzcGVjaWZpZWQgYnkgdGhlIG9mZmVyZXIuPC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJU RVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8xIiBjbGFzcz1Nc29M aXN0UGFyYWdyYXBoPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNl cmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PC9TUEFOPiZuYnNwOzwvUD4N CjxQIHN0eWxlPSJURVhULUlOREVOVDogLTAuMjVpbjsgbXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8x IiBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGli cmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PG86cD48 SU1HIHN0eWxlPSJXSURUSDogNjk2cHg7IEhFSUdIVDogMjgzcHgiIHNyYz0iY2lkOlhPSzBMSzdD VDlTWkBuYW1vLmNvLmtyIj48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMx ZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFw dCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFO IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5 N2Q7IEZPTlQtU0laRTogMTFwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PEJSIHN0eWxlPSJt c28taWdub3JlOiB2Z2xheW91dCIgY2xlYXI9YWxsPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbD48 U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAj MWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPlJlZ2FyZHMsPG86cD48L286cD48L1NQQU4+PC9QPg0K PFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdz YW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+S2lyYW4uPG86cD48 L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTog MTFwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxT UEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMx ZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KPFAg Y2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5z LXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PG86cD4mbmJzcDs8L286 cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPkZyb206PC9TUEFO PjwvQj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgRk9O VC1TSVpFOiAxMHB0Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0g PEJSPjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQgOToxMyBBTTxCUj48Qj5U bzo8L0I+IEtpcmFuIEt1bWFyIEd1ZHVydTxCUj48Qj5DYzo8L0I+IGZyYW5rbGluIGJsZWs7IHB1 YmxpYy13ZWJydGNAdzMub3JnOyBydGN3ZWJAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJl OiBSZTogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ3VkdXJ1LXJ0Y3dl Yi1jb2RlYy1wcmVmZXJlbmNlcy0wMS50eHQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+DQo8RElWPg0KPERJVj4NCjxESVY+DQo8 QkxPQ0tRVU9URSBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiAjY2NjY2NjIDFwdCBzb2xpZDsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiA2 cHQ7IFBBRERJTkctUklHSFQ6IDBpbjsgTUFSR0lOLUxFRlQ6IDQuOHB0OyBCT1JERVItVE9QOiBt ZWRpdW0gbm9uZTsgTUFSR0lOLVJJR0hUOiAwaW47IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7 IFBBRERJTkctVE9QOiAwaW4iPg0KPERJVj4NCjxESVY+DQo8RElWPg0KPERJVj4NCjxQIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvUD4NCjxESVY+DQo8RElWPg0KPFAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1z b05vcm1hbD5UaGlzIGlzIGEgdXNlZnVsIGV4YW1wbGUsIHRoYW5rcyBmb3IgZXhwbGFpbmluZyB0 aGlzLiBCdXQgSSB0aGluayB0aGlzIGlzIHRoZSB3cm9uZyBzb2x1dGlvbi4gUXVvdGggUkZDMzI2 NCwgUy4gNzo8bzpwPjwvbzpwPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxJ PiZuYnNwOyAmbmJzcDtXaGVuIHRoZSBvZmZlcmVyIHJlY2VpdmVzIHRoZSBhbnN3ZXIsIGl0IE1B WSBzZW5kIG1lZGlhIG9uIHRoZTwvST48bzpwPjwvbzpwPjwvUD48L0RJVj4NCjxESVY+DQo8UCBj bGFzcz1Nc29Ob3JtYWw+PEk+Jm5ic3A7ICZuYnNwO2FjY2VwdGVkIHN0cmVhbShzKSAoYXNzdW1p bmcgaXQgaXMgbGlzdGVkIGFzIHNlbmRyZWN2IG9yIHJlY3Zvbmx5IGluPC9JPjxvOnA+PC9vOnA+ PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48ST4mbmJzcDsgJm5ic3A7dGhl IGFuc3dlcikuICZuYnNwO0l0IE1VU1Qgc2VuZCB1c2luZyBhIG1lZGlhIGZvcm1hdCBsaXN0ZWQg aW4gdGhlIGFuc3dlciw8L0k+PG86cD48L286cD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9 TXNvTm9ybWFsPjxJPiZuYnNwOyAmbmJzcDthbmQgaXQgU0hPVUxEIHVzZSB0aGUgZmlyc3QgbWVk aWEgZm9ybWF0IGxpc3RlZCBpbiB0aGUgYW5zd2VyIHdoZW4gaXQ8L0k+PG86cD48L286cD48L1A+ PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxJPiZuYnNwOyAmbmJzcDtkb2VzIHNl bmQuPC9JPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+Tm90 ZSB0aGUgdXNlIG9mIFNIT1VMRCB2cyBNVVNULjxvOnA+PC9vOnA+PC9QPjwvRElWPjwvRElWPg0K PERJVj4NCjxESVY+DQo8UCBjbGFzcz1Nc29Ob3JtYWw+W0tJUkFOXSBzZWN0aW9uIDcgZXhwbGFp bnMgYWJvdXQgIm9mZmVyZXIgcHJvY2Vzc2luZyBvZiB0aGUgQW5zd2VyIi4gQnV0IEkgdGhpbmsg dGhlIGNvcnJlY3Qgc2VjdGlvbiBmb3IgbXkgZXhwbGFuYXRpb24gaXMgc2VjdGlvbiA2LCAiIEdl bmVyYXRpbmcgdGhlIEFuc3dlciIsIHdoaWNoIHJlY29tbW9uZHMgdG8gdXNlIHRoZSBzYW1lIG9y ZGVyIG9mIHByZWZlcmVuY2UgYXMgdGhhdCBpbiB0aGUgb2ZmZXIuPG86cD48L286cD48L1A+PC9E SVY+DQo8RElWPjxQUkUgc3R5bGU9IldPUkQtV1JBUDogYnJlYWstd29yZDsgV0hJVEUtU1BBQ0U6 IHByZS13cmFwOyBXT1JELVNQQUNJTkc6IDBweCI+PFNQQU4gc3R5bGU9IkNPTE9SOiBibGFjayI+ PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QUkU+PFBSRT48U1BBTiBzdHlsZT0iQ09MT1I6IGJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIHN0eWxlPSJDT0xP UjogYmxhY2siPiZuYnNwOyZuYnNwOyAiQWx0aG91Z2ggdGhlIGFuc3dlcmVyIE1BWSBsaXN0IHRo ZSBmb3JtYXRzIGluIHRoZWlyIGRlc2lyZWQgb3JkZXIgb2Y8bzpwPjwvbzpwPjwvU1BBTj48L1BS RT48UFJFPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2siPiZuYnNwOyZuYnNwOyBwcmVmZXJlbmNl LCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHVubGVzcyB0aGVyZSBpcyBhIHNwZWNpZmljIHJlYXNv biw8bzpwPjwvbzpwPjwvU1BBTj48L1BSRT48UFJFPjxTUEFOIHN0eWxlPSJDT0xPUjogYmxhY2si PiZuYnNwOyZuYnNwOyB0aGUgYW5zd2VyZXIgbGlzdCBmb3JtYXRzIGluIHRoZSBzYW1lIHJlbGF0 aXZlIG9yZGVyIHRoZXkgd2VyZTxvOnA+PC9vOnA+PC9TUEFOPjwvUFJFPjxQUkU+PFNQQU4gc3R5 bGU9IkNPTE9SOiBibGFjayI+Jm5ic3A7Jm5ic3A7IHByZXNlbnQgaW4gdGhlIG9mZmVyLiI8bzpw PjwvbzpwPjwvU1BBTj48L1BSRT48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj48 L0JMT0NLUVVPVEU+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9QPjwvRElWPg0KPERJVj4NCjxQIGNsYXNzPU1zb05vcm1hbD5UaGUgdGV4dCBzYXlzICJ1bmxl c3MgdGhlcmUgaXMgYSBzcGVjaWZpYyByZWFzb24iLiBZb3UgaGF2ZSBhIHNwZWNpZmljIHJlYXNv bi4gSnVzdCBkbyBpdC4mbmJzcDs8bzpwPjwvbzpwPjwvUD48L0RJVj4NCjxESVY+DQo8UCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9 TXNvTm9ybWFsPkl0IGlzIGZhciBtb3JlIHNlbnNpYmxlIHRvIGNoYW5nZSB0aGUgb3JkZXIgb2Yg Y29kZWNzIGluIHRoZSBhbnN3ZXIsIHRoYW4gdG8gc2VuZCBhIHJlb2ZmZXIgd2l0aCBjaGFuZ2Vk IGNvZGVjcyBpbW1lZGlhdGVseSBhZnRlcndhcmRzLjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KPERJ Vj4NCjxQIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvUD48L0RJVj4NCjxESVY+ DQo8UCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L1A+PC9ESVY+PC9ESVY+PC9E SVY+PC9ESVY+PC9ESVY+PC9YLUJPRFk+DQo8UD4mbmJzcDs8L1A+PCEtLVNQOmtpcmFuLmd1ZHVy dS0tPjwhLS1raXJhbi5ndWR1cnU6RVAtLT4NCjxQPiZuYnNwOzwvUD4NCjxUQUJMRSBpZD1jb25m aWRlbnRpYWxzaWduaW1nPg0KPFRCT0RZPg0KPFRSPg0KPFREIE5BTU9fTE9DSz4NCjxQPjxJTUcg Ym9yZGVyPTAgc3JjPSJjaWQ6UFlNQzRDQkJFTTZTQG5hbW8uY28ua3IiPjwvUD48L1REPjwvVFI+ PC9UQk9EWT48L1RBQkxFPjwvQk9EWT48L0hUTUw+PGltZyBzcmM9J2h0dHA6Ly9leHQuc2Ftc3Vu Zy5uZXQvbWFpbGNoZWNrL1NlZW5UaW1lQ2hlY2tlcj9kbz05YTQxY2VlMmM2ODE2YmFiYTA5MWVk N2YyZDQ1ZGQzZmQ0ZjQzNDk2MjljNmQ2MGQ1MmNjYWFhNWU3OGQ3OTE3YTU4NmE4Yzk5ZGZiZmJh YjBlZGJlNjgzYzg1M2ZlNzFkYjlmZGRkZGEzM2U4MmNiZTRhMzkxNDI0ZTYyZmNmNmNmODc4Zjlh MjZjZTE1YTAnIGJvcmRlcj0wIHdpZHRoPTAgaGVpZ2h0PTAgc3R5bGU9J2Rpc3BsYXk6bm9uZSc+ --=_NamoWEC-sz6ci9q761 Content-Type: image/gif; name="201408121423999_N3WZA6X7.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhuAIbAYcAAAAAAFBQUBEREd7e3urq6gsLC3Jycn9/f8PDw01NTfv7+6enp/X19URERMjI yDIyMh4eHvf398nJyQYGBhgYGJ2dna2trcHBwSUlJaKioq+vr2BgYEBAQEhISJ+fn+/v7/j5+sDL 2Zqtw4KZtGmFpm6KqbPB0vL091hYWAgICHyUsTxgjThdir+/vzg4OCgoKLe3t8zV4WOAo1V1m8bQ 3WhoaDAwMHh4eM/Pz////9/f34iduV58oJapwcHM2s3W4trg6ebr8JuuxHCLq3BwcJeXlyAgINfX 15CkvvP1+K69z0tslVBvmN/l7Ofn5xAQEOvv80Nlj9nf6IeHh6GzyLrH1j5ijkVnkY+Pj8fR3qe3 ylx6nkpqk+zw9Pn6+4+jvbTC08fHx1FxmdLa5LnG1WqGqImfupWowGZmZjo6Ouzs7GdnZ3t7e3WP rh0dHVFRUcXV6O3y+KO93FOEvfj6/Ofu9YKlz1mIv7/R5tHe7WWQxXadytzm8a7F4JOy1k9vnCU/ Xkp+u0h7uD1mmEFto01yofP2+p662anB37TJ4o2u1GqUx3GZydbi7/Hx8aampoODg2FhYXl5eSoq KuHh4VlZWbi4uEdHRy0tLYeq0ThejDphkEh7tjtjkwkQFz9pnGCMw8vZ6+Dm7YOatneQr9Pb5a28 zuXq7ztfjX2Vs0NkjgIEBg4YIzlfjQcMEhwvRjNXgUh6tSpHaUNwpj9rn+Lq80+Au5i22Dpgjz1m lkd4skFsobrN5HuhzHibxS5PdYClzk5WX0lypPT3+IGhyFiIvmeIrzBSdwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEB AAAh+QQBAADIACwAAAAAuAIbAQAI/wCRCRxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPH jyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPn0CDCh1KtKjRo0iTKl3KtKnTp1Cj Sp1KtarVq1izat3KtavXr2DDih1LtqzZs2jTql3Ltq3bt3Djyp1Lt67du3jzgkQBoK+AAXoDCx5M mOgHADcG3gAgobDjx5Ajq0TRIAdBypYla97MubPDw40JLvib44EEv4BzGAk92vKCvgAqe55Nuzbb 06EHSiD9AMAHZFME5CjNWvhuwLaTK1/+FXfB46pDg/6wWuACIzkOL2DOvbt3qKALtg0mLvCwJfLI WiM7DODv//f38OP7RIGmIGbqoXd/wG8du2j38gUo4IAsnZaYQA24V5p7wVmGQmI5tJeZQMcRaOGF GHrEXl8oZKaaJaiV55cE2L0GW24ZpqjiihWhx+KLMMaYUXQy1mjjjQu5iOOOPPbo449ABinkkDPx FSKRSCbJ2WH1CbQYikpGKaVemF0m25RYZilXeKIBMEAODZzWXmrVpSdcerBdqeWabEblHEH6USfA bzdgR2N62FXYZkZGjvkcbLAVMRAKZ15W6J6IRvSmbryFFuF5plkn3GGCJkrRYVeSOKFB+q3n14Ts HWrpqApxOdB12ZUJ2p2oeuonqQ5VGWuTlLUqUK3+warrQTUNHDhoZehBF6mZm46G3K4ImcrQosSK Jyqyuxo4UIJkulenZb16miuFc0KLUKcO3aAmnpuS6/+ttxvG5uEDIL4aqqYm9gXludZ56aq6B0UI pXr/lUsvvXf+axGzU4yr2LaSlsuvwDjlsMAUlDXwQAMSUzxxxRhfrLHFHGfc8cYehwzyxVMU8ZtT AYOVQxZn7FDGyzDHLPPMNNds8804vyyEKf7aVJqaBfsbYaX9OtszwzAt0CegTDft9NNQRy311A0Q rVTKXWWhAixcd+3112CHLfbYZJfttSawoA1LGSHsdFqHTnaoGtxmniwawuYiPZMEvU3t99+AB/60 EZbgGEoZXA8CyyCaKM64440vHvnjkkNueeWYU6755JxfrvnioMMyww86qQZo4T9bVlqTgwLq3tIA 6t3/Ug5oMP3ADQtIIMFwvPfu++/ABy/88MIPYIkE4jJt8Io57MA1LlzLIEQIoQBB/PXYZ499HD+E csYQsEDPdRlHX5hDCEK4nPP67Le//vRxuPVB332h8YH2+Oevf/BFCABb7CsyBOLCBwshxGF/CExg 9kwwC9B9ohYryoIv1Ga2ClrwghgcX9vU8gH/9aUB91OgCEcYvMXA5lgpisMnwoeLIRyQhDCEoRC4 pgpVACFDodhC1xwHus15rnOZA6IPg/jDIvawazPIAlpKA5spxPCJMIxXt1KUgy2ogmtUgKIWFZiF FcLiE/EjUPNgcUVNaGIGZ8hCKGqxxTZ+AAihoEIZ/3i4tvJ1pXZ9OU8b95i/AcDmAXaMj/MWlwU+ GjJ7QPgEKlCxhUAyJwczSNvizhDCQx7SFCtU3CfsFpZ4OdGSoBReuwAwhZ70CYDIEBOgiEaocrVy KFkAnRBCScvfDaBrphBQHJiQNk2UoZK15KMpJKmJG4qlb8AKpjKn4BdO2gRTmdFUQjrFnm1V05E3 iaQmhqDMbs5wEKoII3wgCTqedfOQITCj6MTplXgB85yh9CDrbtIAujUkW8io1aH0ic2aZEFx4YRn MCMJiy/IZwfqLKRADVkLVShuBv2USgP6coOF1rIIfsmJshbCrIUlTCiI08QsLRpKRKTtE/GJ5eLM SdjSPcbSjLn0SoT68s6W8tEI8sKJnhoStKL59Cc5UBwsXmjTQ87gisaMyWt8lU/EFISZsjFhX6w2 kAb9akLZkqpTWzIDxZGvqHukAtrC2c4PgtWSeGQqTUbzmw0tz1P7wputfhICroHirIccpBCKhIZD TfRQh3kA3Hp6mu08Z4qHAVB4ekoplqgUjHhtoyJhcQav4PGTkW2jmBqgUwAUrqpvtepPPwoU5+FC A5nd4w+8KpPdBIw+DyCa0sRlmZ4iA58EKU2ldmOE3TLoSg9iSRnQ9oXUatEEV0T/aVeMpEfjQtGP 7WnYxCZ0A3sORDsGmWt/IiqTISguFM7V4ge4NgOZTCExU2Bdr2xbtZ5WNzP04dVgb3BegbgXbsw6 SQ4kGV4o8tKGXcEpY/oLRdjk5DRXClrqJIVC0p7qWTwpBNesR+AYgi4mNNLTgyp0nJ4SljEHYatu 1dMAw2r1rSQJgVcrDMMvcK2yXPFgTVmMQA+Wjn4gnpvqjKDWpfmmqYBypk6YgDYawzCTMZGmbhFU 0dgCJzHvRYZUISwiCXRwP4y5sn2BS+WRDJKlRkbgDxZXhgD3JcwjFDCBmKA4NIuQoDHRKr7i25rq eBhY05XyiW6FO9mgoAj8sm1+/0viXViEwLgijmEcuKbcrQjYzQq08YB4CQtIJ5CXjW6JqTqVLSb5 h7ZSls2gndSrA4mrvnGLJohTEklcUBiGDUDDcCYq694tBlhhgE1zgdcrLX4RFWYGgKURqOYBfaLN w9bfDNCWtEMtObhNPdCd4atW3eQUGdDNjW1lhZJjD/WJHahoDvgiHN4FtjKUmrXwOvgl/3It2MnW X7EFROl452+yMIH2wcB0oNecLMpRRpOQkbEg5KhmWyfm7kbqDW5xxzq2vFtAA4Kmn+u9V4uYhre9 tTfvALG50hvPnja/w4QVQpE+w3mQgsddhKAx6XqYKMIWJQwLjYf8epLuTigMYf8QXmri5tjLeG12 3nOuQbHX/IbOcdjQgeGYSObBs4SdtBjJTGfl0UAnXseZc4hiHGJTH8868eBcm65/nSBhfyLSUQ7x G1R05TlgpgCI2jsUGKCNZHf0mcUuvK0zJw69KAYvBsJwvgOPl4NIDuAFT3ijPxHl/HaYcFaTg4vz 7jSP+J0TBrzFT1zR5ob3nd+5AwQ97AGCaQ+97z6+nNKfHhmph7W4UR4HAPR1OLT1HcR9Nxq6PzGS iecK1lXfu5zDpw+BOIQXie+7FWqCO8hXvuNjCPm1Iwb3HbpBrf39uxLvkdKgZ74RZBEIQZj//OhP v/rXz/72u//98I+//OdP//qVp58QIGf+cGYwi0CU3/4AGIACOIAEWICCgH9HJ24BIG6v0W65ZyQT 0G69Ax1txGbPJ3x7p385YHzvYQi9sAgSNggaOBzgxxweuAizgAr5B1Y3EAB8VIJ6J2wjOHqP1HWI QE4ryHzAtxw5YIM4GFkPcAF8NHIYKIMaSAF9AR+8UAyKEEaTNYI5gG/JsYRNKBCYBoWeV3P/RQiF NGgbQLAIi5BUsIdsGnhUWkgbXxiGBEFQUMh6WziCSAgA3+EHiVB0OUh8K6QKtkGHRSeCIwiDWjF8 +teF3hF7Oshs3kFzULiDb3iESThp06d/iEdyi4OFKhh+xEeI3WGIxJd33KGII2iGmKh6cbhmkch8 WUiJn2BJ+LE//SNZaTOKoaeJ3MGJqkeE3cGGTyRggFIZ7PI7RlBrwpNo/rVCsmh4pQiJd6h6k1iI 4dNGkDcclNc78yNuwzh1UMQFZHSMfEeLzGGLobdsZ1iL0NNGSDccprE/xPh7iBiDUJiM9HaKeHiJ zogL0CiM1BEv7dZrTiAAj9AXA6BKU4CN/0/kc9wodt64HOBoeLhIjstIQufIRPeDGeMma4nFOzyW HQIgACCwRW7ojnD4iPH4kIYndJv4jFsUjdHhdOXWa6uSAxXnMBRQgbHYiPmjVcJIYAmpHAtJPBN1 QjTmid9YjlsUkekoecMRAHf3kom2jjEkjgcpPLmXbhUGjx4nj9dzGE03HJoiPLF2Vs14kvaYkvg4 jagSeS8Zk2epRVIIkvqzcg/CYjuZHD0ZPB2QTNgTkS0FlYVIlFpklLuDlBWZHZw3NDDZHh1JdTXp ljcpN6dxHh1kIgNAHZ9SecBCla+IUWaVKpUZmQCJQFYpH4WXPS/5O5QpIR+ACbAha3EgYGrlNpUA AHWveJotmUy5d2/0KJb3aG5m2ZIVVZpiIgBdiXHbaJP4k3CEWW6lMXvGQRqzlXI3QIG8czu4h24S okBzaRt1+TvS6TsvEJjVZ42YIG5sUBnQ8ZyDeZQo14A5YAi7lz8NOZQkyXcf/xmIGdiYvNNKTKmc 09F2qIIf2tE7lkAaGjmZhQmaInmV8wk8o8FGbvU7LZhytbYblDAcHQQECmAEC1B5ZzmNvHMDWwlx 3ak9JlmLKKmBgHh194k/K/eY+2lunhV3stYhKKA7UweUqqRrpUlsCSqaZJg9pyGEvKNgOQosSJej fREGMpoDTYcCx2MnRTocQQMJeIk/QqmQfql/jMiYx5lMuPGiFjpgJDIAHVIEbmeNLBmQc+I7O7o/ oRkfo5k9RuCCH2qenEelEsqVa+o7JPIBHbIAZ3qYgalg5nGU+hOWJjqWGtiW9mmE+QOX1hmYHVRr FLk6siYBDUA4fMobOUmYgf+ZQNlZG9vJneoipXa6O9A0bsn0AJ0qjWhwqQ3wAiYgqISZTOSWQHy5 iVl6iOOooo56nL0Ypp/6oB/KeQ9gJ/FSmLw4KQfqpj0Kp1iJPS8AKIFpQgIAMVxZP9L4P7wDCZxn BFNnrdjqdNeHQIz6jScqiYvZqFz4rPAxqng1ola6rvLZhooTlUD3pu8arc51m/tTogKRA3CgnenK fAZpnJnoru8Br2f1nvsjlLyQfNq5q53YjuwaknJoEALrjAuadWFZC2AIQQSrqPp3rlghiOL3rBF7 CIX4o7yKDIaQCYzHkxR7Tl8ZSvF5sitKfFYJsosgsifZsUCnSJqACIFwg+j/SrICpZeG9F/4enPF FrMzS3IuW7EGeLVYm7VaS38ICEWmAZTb2h7345lMgwYUU6eJWZD3irCkeGaIIAhIu69Ce3OItwev xxytBkWpSRoN0oqDeZF5Knlfko8e+W5sO4sAsArFsLWM27iOy7hdW4bMtoR+wHM0O7f4gwmSGqO9 43KFeY4iSqBQtKUXq4ECVgt78LPyAXyWqIU9WAxxK6oFO0J+uypRWprRSFuWB0UmexUom7AZCwfF ULnwAYpluK61oAh3EAoTi7nac5S7AQS4YaqeyjsR6Vm/uEW5Wrr6l3OvG7sm6oco+kUGEQqKMLJ6 awSkcS3Texgdgrt4OVEEA1mQ9P+qs78KvAWRvMubiPzKd1faEkt1GVtVVfjCBqt0EKKVT2qSVYBS bSbBBDUrQuyCGsNhwH3huZ8qJttne9+3tlxKfKzgrubrjOKrrsEXE/ThVxJyXQAgWLUlagBgWHCC WO1hTIslG42lEryktLTroQoUk4V7gR+sem6gsFnhUTVhvFpqsS7hWmWST2jgZNbxILLBXtW2ZKlE Ab3FLYCxbQ5MEhDsvNljqAoEd1THxPYLhUWcsTlxSg22Efp2E0yggq1rXuilXvR1Je0VVXQTXwZR T7VFX9LGx5YxamA8uyLktyKkoXzUu1bxu6oXqifBJIqxahzBbkNWtbdYvyuRYQD/smHukQV/0VPl WciW3C858AKAdiYl5iTBuhJhvIic/Mg7q3ocSBPcpsAKxxABhxNxSnwAWyD+gcW95mRsAGWDxa3J kmVzMh1TtG1dJhI73IbFOcSIy8Y1sVHsGSYhwipnEi8Gg8U5wbAb978qIWd+Vh+joQDfCRxRhWdR tWdQLHEOssqZIWin/MARXJIezL3Mt8adBSVxor50Yidlgio7xSl4YxO/zIyLAxOb1i2dZnszGWov bMrz4iThZmodcMyKQTeGLM2IHHopmsYzaMQvkV/C4igxOiytkcO88sU0Qc72tr0ssTDPdiB8McgX zWcIkQXXhgPX5s7whWLSvM/+//vQh2t4tywT2owd/AFXrOIfodJgGyXH/St2jowScSxl2IFPCzAB TpBqUkY3/pYvLwAgC0Jdr6zDI214W00VkHzNOYFbt4Jn+dEoDmYmKITEcqzJ4TjLzWtINwtWNm3S GgjQneUr1EJw6gsY13JbiXEYCAMut0JVvpzVHku+9WhIcUkdaLpQB2vNhifJk9zWpdEuijUiJUKt MzxwDA3YDGm4uirG+nOzrHrbrQpD9emrUNjUPIE1EgFqPNHQJK3UuslHcZlATMvbgi3XtUzXQiHc EKEjmWzbyXbYlwtFAlZrNxuNrhlCGnpCIEA/u/1maOy7NDWCBYDSOUHdUGHchkJ3RSecqDEE2im3 O8vtkhkZd+j2AGt6tpHXebmpFX0jgcxnYAPSVbDwaswnVCSH1PkzouEJkwTKbqk9HAM6a6H9lM// PRU/uWuqV00EAj64AF76N16wUAiUyMMJtABu0H2zd6lNY2VHOR4qSb96yBV4BHXMB10PQCBfpoG1 wFp9+W0kNKJI12tAPJ16NB7NTUIO1atYwUwAIDfMZ0LzJB/DNAg7oIFnwDU7UBRuXMmBEhTAN2PE 5nD6Tani1t+8GZhnCchbxDVCrBXQdb+G95MyHCC1ID4aOEeGNhSU7Mqh8WGYrROkwDUKRUIgABsO 53DCSD/lduPlpsFQFAdoU17BtqHEl+e7XBvAd2jEp+IiOBS5XCUB19U7YVpgpnq1kDZl1hVWPr9i 95MowBNlDidNw0rP8kpBQQXkxXxDAD1DQOj5/2wsRM1kQGFSsOALGjhMsDDmXbGBF6x6qvTGNAFN FLLQjNJWfWFN4R7qLxGFWKR6Y/ZFYvgTKm0tMJzRORHrX6QA+qdDg7BBXaGZnCt2AyBPOwHID4FP /PQrft0TZAA6jZ51H/AJ0ANjQtHuXazMaH5FZMB8HyBU5M4UfSO6N0ebsO3U+awQHfUsBd8TA7RJ YmcIBAVGhpHsnwbPGc8SMwQLMsB8IeULYdFBIwJ086NrboNKCmFbe90sQxEHqpCHDm5vH2DvsKDt P2HXurzsId0wlHYGqgcEkrTuXTFKsRlyA3rmO8FW9/JWT60w3u4TY4Y2mvDqw/YDzgcLiHAU0v+C IACy6lveEya1QigudomUNns1Fl8f7p5uaX56wDzxmAQh9IlP8owf8zCRBVMuOqRO+L5g57AQU0eR LkBzJcoeFIiDCjbkv1dEVmQxALzYwjeA4BU2AAXjOp8V3HlG1gWBXeIhV2f/Ex+AeFxTCGfARkb2 AaYwQF8EYATyAWXEBEkfbx+w8qRjFpX3NALwANI//dRf/dZ//dif/dqf/U9jP0CBYPcM8wyWXY2P FIYgBGakCVfUNZ+wBWXg/vD//vIf//Q///Zf//h///pf/zIg/AABS6AmWDviIEOYUOFChg0dPoQY UeJEihUtXmz445NAWKZyfAQZUuRIkiVNnkT/mTKHRliDOmKEGVPmTIYfUADAmVPnTp49fQJYxern UKI+UUigmTRmjgc6keYwgiIHMqg3Ft7U+QEZ1pxalX6N+WEHLE0ECaoim9asWrZr3bZ9G7ftXIIc W9516QsIWL59/f7FmAWtyxlZVB5GnFjxhyF2TQGGHBliDktomhbFrFPAK1iCjmUGvTNqEa+STZ9G /TdHlh1lypItG1v2bNq1Y8/6ZFu37paaXOKCNWMImampjR9HnvBDIbszzgBRHF064g+mynBE9Wlv cu7dHRpKtOiOojuCQnlHn179eopxBBUzxF7+fPQ5zvy2C+vTljJbZPwHMEABBySwQAMPHDA/BJc+ 2aH/NPoeBCuHQ/S4w4/zDtkDPgg35LDDpPYIpJhDPCSxxJnE2gg/tNLKr0UXXxTIJRhnpBEWXIBz aYjtTORRIvBqSQiRRWq5o0cjj4QwlEUUQaQYIGNagILikKQyuRxC2EEGvPTjciMvuwTzSzH1+0QQ QQj5ZMEw1xxzTJcK8cWEKaukUyFe9DCEF0Xq5LNPhpjiqYE5KcqhGCAU4aWPPWRaQICPjLDKT0l7 LFSQPSg85LxJN52JlzsOOiQRTketEoUaZjpkT0SRWURTjBYwIocPHoiUVFvn22OPRXKoRUhbFNnx VmEVCqWYg5DR48lhl4WwgVoxMkTDVUO5Y1CKGrX2/8gFAHj2pmeRmQIAQZG5QaciGprC0YRQGBch Z8nV6VtmEToEkUOqRShPZee1ldoncwiEX4HZQyHSDwTYVoABoMJJXagsaXiPPpBZQJZXxGWSYW4R 0lhKhCRoeAqPUUCDKiMgBkDhjzUbYD6S1XU35Sk/AOABqcAdF+QFGJJAAK9oVhkZmpGaYlyazx0Y mVAWVWSPbJOetBYnE1oaaquTIxmhgx1+AKmtrAJUqwA+yaHnTHhBiEhIEULBEqYiRcHRt5FhYAJ1 3w17K0Fp3rnnluXrGSqvt7IMaYoLHrfo4t5diCmkezbicZUVZ1teZqNFKBOnr+ZUaleRAQIOzkc/ jf/xoRu6QVDBEVqAFVkBACWEhHp2EFutAZDggqBhnSrr1Sl2lHaqup5vCqumKNndGyhHpoEiKL/h ZsIbauBm441HCPqbQR584CGp2mNP0vuM447Px0c/soJvHxzknFQnHvipPjjmlQL2sj2h/IfO33a8 48fW0ZDhN/msjoBfI6DfKEc57jWkUR9wnP92Bq/3PW1ZqwKf+NKHpPKhbYMfBIzpcLcyrynuA0bw 2gLcUBxELaAAThCe/mLFvhjy7msmS2GsaJaT7qlHAjN0nPKCiL3oTaVcDXva0A72ASX6LHvtipsF haWnhORAD4gAIaUWMbEsdhEsIvRaA2kGvxTCDFH/fmNK8tqWAwCoUVAMAMC5QKYu3wHQUQtoF32O WMHpYQuFOJuK4pgyrj16rWB47F0R8se8BiYtDiOq4h2w6MUO5UCSlMQkTdYntBFmL2R7A2CsHgEA i3VyhxvjJE7a5T4UzhBvf6TYDMPFQ/ac7mNOfBfN0DDD1BkxZ51kSOpuEKnUYQ8hRSQh+jqYyQfl YA+QZGY0k+MHD5omXcXJX3qyGcRNeuuJgYSi5QaIE68NgJwJYR67pDiwOBSjmtKsT/jgOU/jYNA0 vTzmDNWzyYTcIFaM25ZXkIlMigHAQVV8QNCgok8KqnKdSfMcPb3TNIlWVDL2lAygkGhRq0WUo6lR IUQvHvpRklYEoyVFqUOKta+U9kVII21pTBdyUpnGNBSCYP9pTWeCCDzp1KcRoelPS+qpYwkVJrzQ kFGVmpCgLtWiRHVqReDwqagutalVpSdPYbrUYhUVqz+96lfhea+tChUIUxOrUDNxvrRKtGll1SmR 2NrWmO5hrnSFp+bgGtN23hWvKN1DsP46T2dqEKvtfOdg6+pXgXElaLPjieGieBWYCbWwXzXEHRKr 2JYGdnRjLM4PLSi8HTK0tHutqBUn6VTVctandh1d9bbKOHZls7aVNWqhVptbPUDTtTL17NVsOZFG sg638osqYpV62d/qFLZXO+BEmGfcQWVzqcoVqjyb61zBDuyBqRRXtobLOoaSF7Uf9ahO37pd5zJ2 WSCzhEJYpivf41oXuVg9q3stiqHzsjeTwbXaIKdEUIXwjSE2VAiCsbpSmU6ov/7F5HOhG95vCti4 f0twfY8b1ZvmlKN96CmEawrgq2n0nFC5WVWushOtcAUnB3UqVP+HSlURj1i/Ne5iImjMUTgYC8cj 7u6PmalVjjJYyIs9Mj0dXFEgBMLDSeYoiaHMzPXOU65T7uyNsZw+zc3TPVreMjOlHGYvMpeZyyRz SSWcZkrmYBG+9WJmN8tmiY6ZziC0IpzxfMU7k3TNfc6iJbkY6N4C+qN2NnT60PxBMydaot9zdBfj EAjRfXAPmYi0RXec6Q+mN2k5qDRTN8dpem6a1OmrRSCCzCxeLCohh9jVqc9cVD0ci1eyRp+/oBaq V+vhwbieFxwWkRAfIyNVwB7fTb06r1YhRMe/RjaztogQqkZr2dGGmoznlQNBTEXb2O6i1OJD1V7s FtxW03F8qvjqZD8pSWmBuPa5P6iIEdU6FL6W9+iIjBB328peRkZGHKCdb04ZAqdO0gOYCW6rJVOl 27Z6pqqRUQtYu3PhG1TUHTB08dFV+c+TKkYx6H0HjbOb41CzpJnifXJ+ddnY5pZULcy0h0SsnOWc uynMb86vy1ZtVLXgxcB3TqpMCH3oSCos5o6+dKZXyZISO4gh3nwHkzfd6lefTyjupfE7CWLQWAd7 2OkTByGZybBiR3va68MLPavd7W+He9zlPne6193ud8c7md0HzLz33e9sPFcO8igZxvk9MnvvoeHF GkPjZE3xgDGw4I0eEcc//36DbEwex2CJLcG7T2Wdb9jfNKqug21rJ1YxPYUtL5Popqbwq0ef6ZHG lBzKyghO9KesEqqV3Kt4K46imT4dz3jYy4Rmz/od57sW+uF5XvRG2GjpeYJ6PhYfauGS2+Z9RnuO AcBtsGSjJfaHu+GK0HDWhxJOZm/HjzRFK9fMG/xpxTbgCwBmjGs9+iGC+E2BrAjJ16H4GZrf4R99 UiJg4qcdeiz9uwjse5TamxWvUSIBxJ0igJkDHJxNMjAGhIjIGzz1ybzIcBzuk5/fQaP48Zv8Cb/h qjz9WUAOpAj/I0HOAz/vI0Dc2R8BsAQWzDw2ShkMg8HZecHSESelGKYLa/8eqwg+3VOZ3DuhyQE+ VJKt8pMeIYSxIJyMB/g/7dO9MNo+WKIdBMPAhHg9JMTC20E+LqQ95lvDH9S86EOY6Ssoh1IKrhC9 hgmch2HDB0AZg+o+Ohwu97mB1OO7M0SdSGmUlskl+2s/AGiZdIGghHrEKHSj18nAD8y/IJQ9jmG/ +JMb9wOXT4Sb+ru/SMnE0/idKoIlQ0SNBmC+VBIA0ZoVlHEiPXRD8DIaYBJEQky8M3RAAOxC9olA 9rHA4hjDyrmdCToOEkSoXmRF70hFTnTGZ1QKGezEGvw+CcTBC9RBHqyiV0SNaMQhamQPZtS8aSTH mRhBLhzGAfpCL/wAMSRfP2AqQ+ABwnQssVU8R3w0QkRUmUX8REcMxUiEwtepRBbExCHkx4VsKVe8 RQWURT5sGK2wxaA5pVxsH5wYRKdgyI5MK3E0R48UySQLSXEcyZOsMZDUR5RkybpzrHtsyZj/3K7j 66dClEn1yQmFvMkNUieF6MmdhAxdqkl0BErhKsREbMPP48I5VL2ibIifZJsPdMrRKa5bWhhQlL8y KhudnEr2WYhtWZgGcL5xRK7Uk8qupJOqdMeFgSUl2jwdAgBlRMuFUEvaeULeixVgPMWi3JZuQaWa JCRzQR2GgsqsmSWNpInxKkEKdBv2g0WY7Mq6VBgSDL8ZjMLz68qXmRJXrCw2aoDE+SXMXMvbscgR wicBmokW1Bvbg8cTqr0Mg0ynVEzecU32AcbHjEwjaEfC0UL9aQDtKQ5+QijJMYIJEp50KsIY/MsG +DxJDMXeARuZUYi9dMoyVCcSPEGthM2p+TxC5CHD5YGi5wHNxbGcnjSeIwSk9FRLmDglAJCeivwb iIwVXpxLulxOpWxCV1JCACgv4rtJA3IiwhEevxmoX+pFGlwACTomnTjLrwjJ+mRPBi0OpqDF+MTD +eRIpxSt4UEaZwmi7kycnEyibpxMGwyadNowB11JCI2QFWVR1NmJcckaP0IKfOolCysk5UGkrVAk mCGo9XTQ+HlRvjDJIVUINmofXIpONFCXBTJQhyga9Iwe9EzPcSJKIy0gF8XS+zKZc3E8byKXmyEo 1YSsTnKfwcGn1dzSNa2SMpyCf/LHv3FSbPLDP3HO4amsw2xKNuXTPvXTPwXUQP8V1EFdupe0z52Q rOOaLEJlVDoBrY8pL7p0IgWcmY1iUUOdzshaF0VN0Ub1DqiUiC9tAAWrrUidykcdIFO1wlQyLZxQ VU/lDsXcP76zL/uaStmqCNoa1cq6rcmD1ZnwT4hIU/P6ylfdSVl9iKqs1U791eMAS1zMFiT9Sg3z VUOkToaYr2WtVgbE1DIVTPoblEVFjqqcr36KVG2tz++6SPE6ynM11pFE1Q11CNJy1Urlz22dCAv7 pj+JowOj1vqEL/k6y2ua1upi1pHEVYrQVdvaVXwlLvcsjiJCMWwK0ARzV4eFQX0NU2vZQIutrnf1 SGSdV1r91+7QGJyILwtLoxVwy8mWcTGulEmQaRdBeoB2SUR/NViMtbxrXYhsLdlmhRATG6GJNZlv cTE/PNorFEl1rb6FmM2LBdqo3ZCARaeB/VnqktqsnQ+NJTDliMsDg1qtFVsfUj2atdkhRNexVVto vIwTi4qp8L11YbGtmNu1tf/bu8XbvNXbveXbvvXbvwXcwBXceepLn/xLTwrMnBDN51yXPHqXPTrc wd1bzSRD6bwdmwGnqdAZnglQoLFQosnFxZXctQ2cVSSZ3mQdxMlc5bFT4pScRwyn0d1b7PFO5WEe 5wFOtglBMrSe5YmU3AVS2RVbAP2bgkkghZlTK3Wg7dNCBW2oPRVetd3QIErCIbKKgRJRh2giJiK/ AEVRnY3euYRcCptRR/mjOcVRWvqaHUWBHi0ORrLJ8I3aQFRSTtolX8Jf5UUdZyGm36yVH41f+W3W berNbkKl5L2hhjhThDAnYEqnBhVgWBVOcoFT1qnTgZKegGoIplAoI2AoyIUI4AgW4REm4RIlNuET RuEUVuEVZuEWduEXhuEYluEZpuEatuEbxuEc1uEdNo6AAAA7 --=_NamoWEC-sz6ci9q761 Content-Type: image/gif; name="201408121423005_LP7KBSL8.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5 uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2 ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr 8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9 AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332 3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex 7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6 C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8 bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr 4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1 8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2 9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT 27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy 3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2 m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA /IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4 h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8 cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt 0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ 2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD /xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47 0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI 3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp 4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7 xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq 4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr /YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5 TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT /FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9 NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i 1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1 6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW 1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2 M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8 B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8 Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI 9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr /l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t 0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN /8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14 qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0 U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2 SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/ lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5 1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo 2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4 Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73 qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN 7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW 6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e 6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8 hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf 06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo //moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi 4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6 n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+ JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d +i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p /gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv ++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w 7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw 345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4 hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3 Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4 loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5 klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7 umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7 MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD 9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8 e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4 nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2 bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ 7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153 UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG 4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8 mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D 0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA Ow== --=_NamoWEC-sz6ci9q761-- From nobody Tue Aug 12 02:00:40 2014 Return-Path: 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 010FE1A079F for ; Tue, 12 Aug 2014 02:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 zGysU70oB5sc for ; Tue, 12 Aug 2014 02:00:33 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A421A038C for ; Tue, 12 Aug 2014 02:00:32 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 86ABA1231E79F; Tue, 12 Aug 2014 09:00:29 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s7C9025Q009661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 11:00:30 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 12 Aug 2014 11:00:15 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Justin Uberti Thread-Topic: [rtcweb] How to reset DTLS over TCP if the connection is closed Thread-Index: AQHPsu++lbOZqSH1Kky39tupSFGXNZvL35mAgADRfmA= Date: Tue, 12 Aug 2014 09:00:15 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC2CA5A4@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC2CA5A4FR711WXCHMBA03zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/rApuRU8fMXDNwH4Hz_vWzkofvfM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 09:00:38 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC2CA5A4FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdGluLA0KcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQoNCmlmIGZpbmFsbHkgVENQIHdv dWxkIGJlIHNlbGVjdGVkIGFzIEw0IHByb3RvY29sIChpbnN0ZWFkIG9mIFVEUCksIHRoZW4gVExT IHdvdWxkIGJlIHVzZWQgaW5zdGVhZCBvZiBEVExTLCByaWdodD8NCihJZiB5ZXMsIHRoZW4gZGlz Y3Vzc2lvbiB3b3VsZCBiZSBhYm91dCDigJxyZXNldCBUTFMgb3ZlciBUQ1Ag4oCm4oCdIGluIHVu ZGVyc3RhbmRpbmcpLg0KDQotQWxicmVjaHQNCg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDog RGllbnN0YWcsIDEyLiBBdWd1c3QgMjAxNCAwMDoyOA0KVG86IEnDsWFraSBCYXogQ2FzdGlsbG8N CkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBIb3cgdG8gcmVzZXQg RFRMUyBvdmVyIFRDUCBpZiB0aGUgY29ubmVjdGlvbiBpcyBjbG9zZWQNCg0KDQoNCk9uIEZyaSwg QXVnIDgsIDIwMTQgYXQgMzowMSBBTSwgScOxYWtpIEJheiBDYXN0aWxsbyA8aWJjQGFsaWF4Lm5l dDxtYWlsdG86aWJjQGFsaWF4Lm5ldD4+IHdyb3RlOg0KSGksIGxldCdzIGFzc3VtZSB0aGUgZm9s bG93aW5nIHNjZW5hcmlvOg0KDQotIEJyb3dzZXIgYW5kIHNlcnZlciAoSUNFLUxpdGUpIHdpdGgg anVzdCBUQ1AgY2FuZGlkYXRlcy4NCg0KLSBCcm93c2VyIHNlbmRzIHRoZSBEVExTIGhhbmRzaGFr ZSBvdmVyIHRoZSBUQ1Agbm9taW5hdGVkIChhbmQgc2luZ2xlKQ0KY29ubmVjdGlvbi4NCg0KLSBN ZWRpYSBiZWdpbnMuDQoNCi0gTGF0ZXIgdGhlIFRDUCBjb25uZWN0aW9uIGlzIGFicnVwdGx5IGNs b3NlZC4gVGhlIGNsaWVudCB3YW50IHRvDQoicmVzZXQiIHRoZSBjb21tdW5pY2F0aW9uLg0KDQpT byBhdCB0aGlzIHBvaW50IEkgZXhwZWN0IHRoYXQ6DQoNCjEpIEJyb3dzZXIgTVVTVCBvcGVuIGEg bmV3IFRDUCBjb25uZWN0aW9uIChvYnZpb3VzbHkpLg0KDQpZZXMsIHBlciBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2NTQ0I3NlY3Rpb24tMTEuMQ0KDQoyKSBXaGVuIGRvbmUgaXQgbXVz dCBzZW5kIEJpbmRpbmcgUmVxdWVzdCBmb3IgdGhlIHNlcnZlciB0byBhbGxvdyBtZWRpYSBmcm9t IGl0Lg0KDQpZZXMsIGFzIGluZGljYXRlZCBpbiB0aGF0IHNhbWUgc2VjdGlvbi4NCg0KMykgQnJv d3NlciBNVVNUIE5PVCBwZXJmb3JtIGFnYWluIHRoZSBEVExTIGhhbmRzaGFrZS4NCg0KVGhlIHJh dGlvbmFsZSBvbiBidWxsZXQgMykgaXMgdGhhdCBJQ0UgaXMgc3VwcG9zZWQgdG8gYmUgYSAidmly dHVhbA0Kc29ja2V0IiBhbmQgdGh1cyBhIHNpbmdsZSBEVExTIGhhbmRzaGFrZSBtdXN0IGJlIGRv bmUgcmVnYXJkbGVzcyB3aGljaA0KVURQL1RDUC9TQ1RQL1guMjUgdHJhbnNwb3J0IGlzIHVzZWQg dG8gY2FycmllZCB0aGUgRFRMUyBkYXRhIGJldHdlZW4NCnBlZXJzLg0KDQpZZXMsIHRoZSBEVExT IGxheWVyIGlzIG5vdCBhZmZlY3RlZC4NCg0KDQo0KSBTYWlkIHRoYXQsIGFuZCBhc3N1bWluZyB0 aGF0IHRoZXJlIGlzIGFsc28gYSBVRFAgSUNFIHZhbGlkIHBhaXIsIEkNCmFsc28gZXhwZWN0IChh bmQgdGhpcyBpcyBhIGJpdCBleG90aWMgYnV0IElNSE8gaXQgU0hPVUxEIHdvcmspIHRoYXQNCnRo ZSBicm93c2VyIHNob3VsZCBiZSBhYmxlIHRvIHNlbmQgYSBEVExTIENsb3NlIEFsZXJ0IG92ZXIg dGhlIFVEUA0KdmFsaWQgcGFpciAodGhpcyBpcywgZXZlbiB3aGVuIHRoZSBEVExTIGhhbmRzaGFr ZSBhbmQgUlRQIGlzIGJlaW5nDQpzZW50IG92ZXIgdGhlIFRDUCBub21pbmF0ZWQgcGFpcikuDQoN CkFueSBEVExTIGNsb3NlIGFsZXJ0IHdvdWxkIG51a2UgdGhlIGVudGlyZSBEVExTIGNvbm5lY3Rp b24sIHdoaWNoIGlzIGN1cnJlbnRseSBmYXRhbCBpbiBDaHJvbWUuDQo= --_000_786615F3A85DF44AA2A76164A71FE1AC2CA5A4FR711WXCHMBA03zeu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9y OiMxRjQ5N0QiPkp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5xdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5pZiBmaW5hbGx5IFRDUCB3 b3VsZCBiZSBzZWxlY3RlZCBhcyBMNCBwcm90b2NvbCAoaW5zdGVhZCBvZiBVRFApLCB0aGVuIFRM UyB3b3VsZCBiZSB1c2VkIGluc3RlYWQgb2YgRFRMUywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+KElmIHllcywgdGhlbiBkaXNjdXNz aW9uIHdvdWxkIGJlIGFib3V0IOKAnHJlc2V0IFRMUyBvdmVyIFRDUCDigKbigJ0gaW4gdW5kZXJz dGFuZGluZykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzFGNDk3RCI+LUFsYnJlY2h0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IERpZW5zdGFnLCAxMi4g QXVndXN0IDIwMTQgMDA6Mjg8YnI+DQo8Yj5Ubzo8L2I+IEnDsWFraSBCYXogQ2FzdGlsbG88YnI+ DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0 Y3dlYl0gSG93IHRvIHJlc2V0IERUTFMgb3ZlciBUQ1AgaWYgdGhlIGNvbm5lY3Rpb24gaXMgY2xv c2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEZyaSwgQXVnIDgsIDIwMTQgYXQgMzowMSBBTSwgScOxYWtpIEJheiBDYXN0 aWxsbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmliY0BhbGlheC5uZXQiIHRhcmdldD0iX2JsYW5rIj5p YmNAYWxpYXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSwgbGV0J3MgYXNzdW1lIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86PGJyPg0KPGJy Pg0KLSBCcm93c2VyIGFuZCBzZXJ2ZXIgKElDRS1MaXRlKSB3aXRoIGp1c3QgVENQIGNhbmRpZGF0 ZXMuPGJyPg0KPGJyPg0KLSBCcm93c2VyIHNlbmRzIHRoZSBEVExTIGhhbmRzaGFrZSBvdmVyIHRo ZSBUQ1Agbm9taW5hdGVkIChhbmQgc2luZ2xlKTxicj4NCmNvbm5lY3Rpb24uPGJyPg0KPGJyPg0K LSBNZWRpYSBiZWdpbnMuPGJyPg0KPGJyPg0KLSBMYXRlciB0aGUgVENQIGNvbm5lY3Rpb24gaXMg YWJydXB0bHkgY2xvc2VkLiBUaGUgY2xpZW50IHdhbnQgdG88YnI+DQomcXVvdDtyZXNldCZxdW90 OyB0aGUgY29tbXVuaWNhdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpTbyBhdCB0aGlzIHBvaW50IEkgZXhwZWN0IHRoYXQ6 PGJyPg0KPGJyPg0KMSkgQnJvd3NlciBNVVNUIG9wZW4gYSBuZXcgVENQIGNvbm5lY3Rpb24gKG9i dmlvdXNseSkuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ZZXMsIHBlciA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM2NTQ0I3NlY3Rpb24tMTEuMSI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 NTQ0I3NlY3Rpb24tMTEuMTwvYT4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjIpIFdoZW4gZG9uZSBpdCBtdXN0IHNl bmQgQmluZGluZyBSZXF1ZXN0IGZvciB0aGUgc2VydmVyIHRvIGFsbG93IG1lZGlhIGZyb20gaXQu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ZZXMsIGFzIGluZGljYXRlZCBpbiB0aGF0IHNhbWUgc2VjdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjMpIEJy b3dzZXIgTVVTVCBOT1QgcGVyZm9ybSBhZ2FpbiB0aGUgRFRMUyBoYW5kc2hha2UuPGJyPg0KPGJy Pg0KVGhlIHJhdGlvbmFsZSBvbiBidWxsZXQgMykgaXMgdGhhdCBJQ0UgaXMgc3VwcG9zZWQgdG8g YmUgYSAmcXVvdDt2aXJ0dWFsPGJyPg0Kc29ja2V0JnF1b3Q7IGFuZCB0aHVzIGEgc2luZ2xlIERU TFMgaGFuZHNoYWtlIG11c3QgYmUgZG9uZSByZWdhcmRsZXNzIHdoaWNoPGJyPg0KVURQL1RDUC9T Q1RQL1guMjUgdHJhbnNwb3J0IGlzIHVzZWQgdG8gY2FycmllZCB0aGUgRFRMUyBkYXRhIGJldHdl ZW48YnI+DQpwZWVycy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlIERUTFMgbGF5ZXIgaXMgbm90IGFmZmVjdGVkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyPg0KNCkgU2FpZCB0aGF0LCBhbmQgYXNzdW1pbmcgdGhhdCB0aGVyZSBpcyBhbHNv IGEgVURQIElDRSB2YWxpZCBwYWlyLCBJPGJyPg0KYWxzbyBleHBlY3QgKGFuZCB0aGlzIGlzIGEg Yml0IGV4b3RpYyBidXQgSU1ITyBpdCBTSE9VTEQgd29yaykgdGhhdDxicj4NCnRoZSBicm93c2Vy IHNob3VsZCBiZSBhYmxlIHRvIHNlbmQgYSBEVExTIENsb3NlIEFsZXJ0IG92ZXIgdGhlIFVEUDxi cj4NCnZhbGlkIHBhaXIgKHRoaXMgaXMsIGV2ZW4gd2hlbiB0aGUgRFRMUyBoYW5kc2hha2UgYW5k IFJUUCBpcyBiZWluZzxicj4NCnNlbnQgb3ZlciB0aGUgVENQIG5vbWluYXRlZCBwYWlyKS48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFueSBEVExTIGNsb3NlIGFsZXJ0IHdvdWxkIG51a2UgdGhlIGVudGlyZSBEVExTIGNvbm5lY3Rp b24sIHdoaWNoIGlzIGN1cnJlbnRseSBmYXRhbCBpbiBDaHJvbWUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_786615F3A85DF44AA2A76164A71FE1AC2CA5A4FR711WXCHMBA03zeu_-- From nobody Tue Aug 12 02:34:18 2014 Return-Path: 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 912B71A07DC for ; Tue, 12 Aug 2014 02:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 hhGm4x-0egB3 for ; Tue, 12 Aug 2014 02:34:16 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545C01A07CE for ; Tue, 12 Aug 2014 02:34:16 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so2564412qcx.7 for ; Tue, 12 Aug 2014 02:34:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=6Gxs8q5yj5dORDRmpz1J3jwW2OrUfliYKn8JBE5amZQ=; b=e+tamCdgGuWYgf42LHOop+ed1z2kTtsKiiDALN/597324zvFQk6pUCx9NIHvPWE78I 8+ha4EUMKDWHNyVQ1mNrXXOliqRHgdulZoab8dWUHrY0/ktDl+WbAs/hRNe24sOrn0XU DO8mI9lt9+9iu+TrjAj/Ym/BCPrLBf0M/1JeHCta6NMGcpf9pxkTAsfO85+Gs8622OlZ 0oY2MDmcsDzXXL76r5xA1Hhy26ueX6+PA90mr24olXWrl4F9punISTTs9Of5AS+4hqP2 Z+wuurswtGG/QsOZvlEYJBQ77ogxKxlGMe+NN2lNM3gSO3qcCKt/EOGdgpuCmDt+wFA9 lp+g== X-Gm-Message-State: ALoCoQkIj+FC6WwFduYJJKAAtclLVE3skxK1GqYaTamPAa1aWW8dZsv+YmR3/Xp1qUJGb36/yTGw X-Received: by 10.224.3.198 with SMTP id 6mr4585704qao.5.1407836055423; Tue, 12 Aug 2014 02:34:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.161 with HTTP; Tue, 12 Aug 2014 02:33:54 -0700 (PDT) In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC2CA5A4@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC2CA5A4@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 12 Aug 2014 11:33:54 +0200 Message-ID: To: "Schwarz, Albrecht (Albrecht)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iwjQFv_exFjnpEAYJ6BTgxjsYx0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 09:34:17 -0000 2014-08-12 11:00 GMT+02:00 Schwarz, Albrecht (Albrecht) : > if finally TCP would be selected as L4 protocol (instead of UDP), then TL= S > would be used instead of DTLS, right? No. It is STUN, DTLS and SRTP/SRTCP over TCP. RFC 6544 (ICE TCP) allows both DTLS and TLS: +----------+ | | | App | +----------+----------+ +----------+----------+ | | | | | | | STUN | (D)TLS | | STUN | App | +----------+----------+ +----------+----------+ | | | | | RFC 4571 | | RFC 4571 | +---------------------+ +---------------------+ | | | | | TCP | | TCP | +---------------------+ +---------------------+ | | | | | IP | | IP | +---------------------+ +---------------------+ Figure 1: ICE TCP Stack with and without (D)TLS but AFAIK WebRTC just uses DTLS and not TLS (note that we are not talking about TURN in which TLS is supported). --=20 I=C3=B1aki Baz Castillo From nobody Tue Aug 12 03:20:21 2014 Return-Path: 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 7195C1A0830 for ; Tue, 12 Aug 2014 03:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 WI9KpP22rrpC for ; Tue, 12 Aug 2014 03:20:19 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6271F1A082F for ; Tue, 12 Aug 2014 03:20:19 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x3so2579508qcv.23 for ; Tue, 12 Aug 2014 03:20:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=M44O8pGnPDJqrdVgElOLMk69kXblOdNvWgKMtxbUsXQ=; b=P80VJ9yT1iNEllhT3yBHTQal/hPrcS941RFFxzcuUGk3CagpqA3PZxygYdUSqctmVq nAttZWfQ/5Lkkf9va6jn7iII863brN3AokRbSP4aivCN0+2wQ0qVvWMdQ8asmkEtwykM P+ilLxVQpwwajK3rZv6FV6iJQ5YWvQPvK3u01xxg+wiNtPHFY6GlYvmTqEbFLXtZN90T LLuI5w3a4ElUPc1nJbi3kOIm76LNXvzkp2mLBUP59ToIKSL5Li1LCKvohI8JfjgR5jAL 0uLWO1uQ7vRRoPTLiK5Ep30MUSZz+zch9RSpi3EtglEPf5ib3F+WTsTEJl6waRZsmUSN BzVA== X-Gm-Message-State: ALoCoQnKRvcPvNugHnpXkBc0iegkXpddAZliRYiOHLMTq0raCDrS95JREjFEV22/EEH3S/SaFeOH X-Received: by 10.140.95.101 with SMTP id h92mr4778945qge.35.1407838818481; Tue, 12 Aug 2014 03:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.234.161 with HTTP; Tue, 12 Aug 2014 03:19:58 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 12 Aug 2014 12:19:58 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GIFYnaoCjp5b9lmONVjrEZuo1i0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 10:20:20 -0000 2014-08-12 0:27 GMT+02:00 Justin Uberti : >> 4) Said that, and assuming that there is also a UDP ICE valid pair, I >> also expect (and this is a bit exotic but IMHO it SHOULD work) that >> the browser should be able to send a DTLS Close Alert over the UDP >> valid pair (this is, even when the DTLS handshake and RTP is being >> sent over the TCP nominated pair). > > > Any DTLS close alert would nuke the entire DTLS connection, which is > currently fatal in Chrome. Sure, I just meant that, theoretically, the DTLS alert can be sent over any valid pair (even if it is not the selected one). Thanks a lot. This is now clear for me, but IMHO we have a serious problem given that RFC 5764 insists on "A single DTLS-SRTP session only protects data carried over a single UDP source and destination port pair". --=20 I=C3=B1aki Baz Castillo From nobody Tue Aug 12 09:25:59 2014 Return-Path: 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 8B4721A0266 for ; Tue, 12 Aug 2014 09:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 k3-fwrvFxGwo for ; Tue, 12 Aug 2014 09:25:53 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272991A02E6 for ; Tue, 12 Aug 2014 09:25:51 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so13623343vcb.34 for ; Tue, 12 Aug 2014 09:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uEXt1KqzFI4HypkZ7qAQCANS/nsAyiAAqoGo20QG+mo=; b=ctTPDpII8R0Zfag7/g49B0ldLDy5PQHGvZimdKh739AnfJZWriHO/murLH1onxV/IS yCSEpKiHGuAJS0V7m4rc1IobbbkprlhD293dMkffrv0I+c+aTh+jT8TMinKamyUMn6Rm ujTfQ6hE3UNG7ecoybMxaIklZJ5PXZXzXlXkttMkVdNpJ4dv+daQ55/Usha9WcKhWxl4 1t1ewUZvzRjnBnxrPFuv7pNx3cIitTY/jg0ETlpatTzHC4poxgfb9OvbTZwxIYOGGh90 0tUr7jkGf9+JRGz3IuKwReCYHbU8GZHodwTYZ2p3Q84pelhP7XsKamese6N1AF0KszBh K4+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uEXt1KqzFI4HypkZ7qAQCANS/nsAyiAAqoGo20QG+mo=; b=kAiSLEm/mepuzA6pGvBF4fhrBeSOl95pOY/ezFYBSDk0nZ/wcWzxqLIMykJXrepz3b 3Re7dYhPzBaoucY8YMscuLRDnAZf4Sh0oOkERa/dThx1l+Zb8z5LSFQGtmNga8iTNngR RJf1WeXKK2pB1kBWBUD7ON/i6U0jHuryLIQUIG98e5BSVE02tW96/vWwrvnBVaJfBXUQ iSHDzT6+80WOn4ZVb3YOGoXIeTkR6pUYWR7BMczKLJbxEX1W1usLA/Skh559pGc2A2/b X4dzDLyTL8uk9xslVmDcUgm2rf1624OT+T/NWi4AuZCojGfN3hMpt7DypH/1Je5xcRqY FpWg== X-Gm-Message-State: ALoCoQn0oJmvJU+LItgKyCpWT6b7j6PuoQ8h6QR/cFIi+QtT3dasxgQ+QLBgiNgjHyPMGNBjBKwr X-Received: by 10.220.49.10 with SMTP id t10mr5016465vcf.34.1407860750365; Tue, 12 Aug 2014 09:25:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Tue, 12 Aug 2014 09:25:30 -0700 (PDT) In-Reply-To: References: <786615F3A85DF44AA2A76164A71FE1AC2CA5A4@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: Justin Uberti Date: Tue, 12 Aug 2014 09:25:30 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=089e0163412ceb4a4a0500711f0d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/85Q-XLKeEa1QC-mlnFpSuBd2298 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:25:56 -0000 --089e0163412ceb4a4a0500711f0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2014 at 2:33 AM, I=C3=B1aki Baz Castillo wr= ote: > 2014-08-12 11:00 GMT+02:00 Schwarz, Albrecht (Albrecht) > : > > if finally TCP would be selected as L4 protocol (instead of UDP), then > TLS > > would be used instead of DTLS, right? > > No. It is STUN, DTLS and SRTP/SRTCP over TCP. > > RFC 6544 (ICE TCP) allows both DTLS and TLS: > > +----------+ > | | > | App | > +----------+----------+ +----------+----------+ > | | | | | | > | STUN | (D)TLS | | STUN | App | > +----------+----------+ +----------+----------+ > | | | | > | RFC 4571 | | RFC 4571 | > +---------------------+ +---------------------+ > | | | | > | TCP | | TCP | > +---------------------+ +---------------------+ > | | | | > | IP | | IP | > +---------------------+ +---------------------+ > > Figure 1: ICE TCP Stack with and without (D)TLS > > but AFAIK WebRTC just uses DTLS and not TLS (note that we are not > talking about TURN in which TLS is supported). > > Exactly. Even when TCP is used as a L4 protocol, there can still be packet losses, as we will never buffer data when entering a flow control state. --089e0163412ceb4a4a0500711f0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGJyPjxkaXYg Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBUdWUsIEF1ZyAxMiwgMjAxNCBhdCAyOjMzIEFNLCBJw7Fh a2kgQmF6IENhc3RpbGxvIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmliY0Bh bGlheC5uZXQiIHRhcmdldD0iX2JsYW5rIj5pYmNAYWxpYXgubmV0PC9hPiZndDs8L3NwYW4+IHdy b3RlOjxicj4NCg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+ MjAxNC0wOC0xMiAxMTowMCBHTVQrMDI6MDAgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTxi cj4NCiZsdDs8YSBocmVmPSJtYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5j b20iPmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDs6PGJyPg0KPGRp diBjbGFzcz0iIj4mZ3Q7IGlmIGZpbmFsbHkgVENQIHdvdWxkIGJlIHNlbGVjdGVkIGFzIEw0IHBy b3RvY29sIChpbnN0ZWFkIG9mIFVEUCksIHRoZW4gVExTPGJyPg0KJmd0OyB3b3VsZCBiZSB1c2Vk IGluc3RlYWQgb2YgRFRMUywgcmlnaHQ/PGJyPg0KPGJyPg0KPC9kaXY+Tm8uIEl0IGlzIFNUVU4s IERUTFMgYW5kIFNSVFAvU1JUQ1Agb3ZlciBUQ1AuPGJyPg0KPGJyPg0KUkZDIDY1NDQgKElDRSBU Q1ApIGFsbG93cyBib3RoIERUTFMgYW5kIFRMUzo8YnI+DQo8YnI+DQrCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCstLS0tLS0tLS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgfCDCoCDCoCDCoCDCoCDCoHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoHwgwqAgwqBBcHAgwqAgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgICst LS0tLS0tLS0tKy0tLS0tLS0tLS0rIMKgIMKgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0rPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoHwgwqAgwqAgwqAgwqAgwqB8IMKgIMKg IHwgwqAgwqAgwqAgwqAgwqB8IMKgIMKgIMKgIMKgIMKgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKg IHwgwqAgU1RVTiDCoCB8IMKgKEQpVExTIMKgfCDCoCDCoCB8IMKgIFNUVU4gwqAgfCDCoCDCoEFw cCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsgwqAg wqAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSs8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgfCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCB8PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCDCoFJGQyA0NTcxIMKgIMKg IMKgIHwgwqAgwqAgfCDCoCDCoCDCoFJGQyA0NTcxIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyDCoCDCoCArLS0tLS0tLS0tLS0tLS0tLS0t LS0tKzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgfCDCoCDCoCB8IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCB8IMKgIMKgIMKgIMKgIFRDUCDCoCDCoCDCoCDCoCB8IMKgIMKgIHwgwqAgwqAg wqAgwqAgVENQIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCArLS0tLS0tLS0t LS0tLS0tLS0tLS0tKyDCoCDCoCArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzxicj4NCsKgIMKgIMKg IMKgIMKgIMKgIHwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgfCDCoCDCoCB8IMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHw8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCB8IMKgIMKg IMKgIMKgIElQIMKgIMKgIMKgIMKgIMKgfCDCoCDCoCB8IMKgIMKgIMKgIMKgIElQIMKgIMKgIMKg IMKgIMKgfDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rIMKg IMKgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0KPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAg wqAgRmlndXJlIDE6IElDRSBUQ1AgU3RhY2sgd2l0aCBhbmQgd2l0aG91dCAoRClUTFM8YnI+DQo8 YnI+DQpidXQgQUZBSUsgV2ViUlRDIGp1c3QgdXNlcyBEVExTIGFuZCBub3QgVExTIChub3RlIHRo YXQgd2UgYXJlIG5vdDxicj4NCnRhbGtpbmcgYWJvdXQgVFVSTiBpbiB3aGljaCBUTFMgaXMgc3Vw cG9ydGVkKS48YnI+DQo8ZGl2IGNsYXNzPSJIT0VuWmIiPjxkaXYgY2xhc3M9Img1Ij48YnI+PC9k aXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+RXhhY3RseS4gRXZlbiB3 aGVuIFRDUCBpcyB1c2VkIGFzIGEgTDQgcHJvdG9jb2wsIHRoZXJlIGNhbiBzdGlsbCBiZSBwYWNr ZXQgbG9zc2VzLCBhcyB3ZSB3aWxsIG5ldmVyIGJ1ZmZlciBkYXRhIHdoZW4gZW50ZXJpbmcgYSBm bG93IGNvbnRyb2wgc3RhdGUuwqA8L2Rpdj4NCg0KPC9kaXY+PC9kaXY+PC9kaXY+DQo= --089e0163412ceb4a4a0500711f0d-- From nobody Tue Aug 12 09:28:21 2014 Return-Path: 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 1285D1A02D7 for ; Tue, 12 Aug 2014 09:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 5ytSvHqiKshN for ; Tue, 12 Aug 2014 09:28:14 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396791A02E3 for ; Tue, 12 Aug 2014 09:28:14 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so13610894vcb.30 for ; Tue, 12 Aug 2014 09:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hR5Dv5JUruP+0PS9209N2Scete+kPsC00exr0WqG5+8=; b=LVYV2I3dAuv8aZDcisawSMZh80hoUjoO1eqVrRH2PaFDh2+lxnMqq+h/SFeZ6Wt71z oS1I01MyBbmcU8+rJePuQyrX/h8EORhawX5GM3IYi0Zo6oAa2dbdvj68QohSbdlCTLIy 1NJDiJdxSs9KpaQ6ZIw/z7BT6O07kCBBAHf/zNh2xfRtq3gaCvsXVRvQGgRfr38oU8hi zp+gx0+PxwRqsXruQkBzsG+TMsa2BdMdQGKoWpjBUsJDu8u4mOnI2h45NljVwx4Ny5Rq ytzmyJsYwvurO3MsSJBtdPp3VpvCPvh6+iXmAOix8dNK+DnMC9mx1WOk++NM/4qrCnEp HDFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hR5Dv5JUruP+0PS9209N2Scete+kPsC00exr0WqG5+8=; b=KJv1EAGTJVkd6QR3zgbHquCjC9LgzAeblVYcNwbvcomToPQJkcHL1Jr45y6npz2TVw 6nWzw++MbXJOGB56JOv9kNAaLrVovZPz1h8IrfK5KK2uODNwZsw3kNfgpkJyZRuAfKRZ ROL6UAQnU+/Q8LsQBrPuGJN7fvzKE1mIOR864+wUqW3AVx8BYm0MipVgARsRv/7EA/04 IscMCZSZRhbn1DtXPXQkEFvX3M9iC6QKjWfcUA6JdePBnatpbGsOJg8/2VyohlxZV68u 2evbLFKS8H5evqezFB/wcQhvLjUEwjGElTFbu8dGzqEHQAkQy2x8sv9s9RpHn3cU/o0y Jo4g== X-Gm-Message-State: ALoCoQksbW6dkfEopRQKWB4UYZKk4VGGDbVPfLXjCCsU0tSy+h+fbbrt/0yFy47NfdjU3ZquygO9 X-Received: by 10.221.41.135 with SMTP id tu7mr1850975vcb.70.1407860893317; Tue, 12 Aug 2014 09:28:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Tue, 12 Aug 2014 09:27:53 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 12 Aug 2014 09:27:53 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a1133901c7094150500712898 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H8rFxK9epGFgTPsxr5HmLtOPu80 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:28:20 -0000 --001a1133901c7094150500712898 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2014 at 3:19 AM, I=C3=B1aki Baz Castillo wr= ote: > 2014-08-12 0:27 GMT+02:00 Justin Uberti : > >> 4) Said that, and assuming that there is also a UDP ICE valid pair, I > >> also expect (and this is a bit exotic but IMHO it SHOULD work) that > >> the browser should be able to send a DTLS Close Alert over the UDP > >> valid pair (this is, even when the DTLS handshake and RTP is being > >> sent over the TCP nominated pair). > > > > > > Any DTLS close alert would nuke the entire DTLS connection, which is > > currently fatal in Chrome. > > Sure, I just meant that, theoretically, the DTLS alert can be sent > over any valid pair (even if it is not the selected one). > Yes. > > Thanks a lot. This is now clear for me, but IMHO we have a serious > problem given that RFC 5764 insists on "A single DTLS-SRTP session > only protects data carried over a single UDP source and destination > port pair". Agreed, this was written before the DTLS-ICE interaction had been fully understood. Errata should be filed against 5764 so that it can be made more consistent with ICE. --001a1133901c7094150500712898 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 12, 2014 at 3:19 AM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2014-08-12 0:27 GMT+02:00 Justin Uberti <= juberti@google.com>:
>> 4) Said that, and assuming that there is also a UD= P ICE valid pair, I
>> also expect (and this is a bit exotic but IMHO it SHOULD work) tha= t
>> the browser should be able to send a DTLS Close Alert over the UDP=
>> valid pair (this is, even when the DTLS handshake and RTP is being=
>> sent over the TCP nominated pair).
>
>
> Any DTLS close alert would nuke the entire DTLS connection, which is > currently fatal in Chrome.

Sure, I just meant that, theoretically, the DTLS alert can be sent over any valid pair (even if it is not the selected one).
<= div>
Yes.
=C2=A0
Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:33:23 -0000 --f46d04389533b16b360500713a85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 12, 2014 at 9:27 AM, Justin Uberti wrote: > > > > On Tue, Aug 12, 2014 at 3:19 AM, I=C3=B1aki Baz Castillo = wrote: > >> 2014-08-12 0:27 GMT+02:00 Justin Uberti : >> >> 4) Said that, and assuming that there is also a UDP ICE valid pair, I >> >> also expect (and this is a bit exotic but IMHO it SHOULD work) that >> >> the browser should be able to send a DTLS Close Alert over the UDP >> >> valid pair (this is, even when the DTLS handshake and RTP is being >> >> sent over the TCP nominated pair). >> > >> > >> > Any DTLS close alert would nuke the entire DTLS connection, which is >> > currently fatal in Chrome. >> >> Sure, I just meant that, theoretically, the DTLS alert can be sent >> over any valid pair (even if it is not the selected one). >> > > Yes. > > >> >> Thanks a lot. This is now clear for me, but IMHO we have a serious >> problem given that RFC 5764 insists on "A single DTLS-SRTP session >> only protects data carried over a single UDP source and destination >> port pair". > > > Agreed, this was written before the DTLS-ICE interaction had been fully > understood. Errata should be filed against 5764 so that it can be made mo= re > consistent with ICE. > Agreed. I think this is just a textual problem, though. It's pretty clear what has to happen. -Ekr --f46d04389533b16b360500713a85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 12, 2014 at 9:27 AM, Justin Uberti &l= t;juberti@google.co= m> wrote:



On Tue, Aug 12, 2014= at 3:19 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
2014-08-12 0:27 GMT+02:00 Justin Uberti <= juberti@google.com<= /a>>:
>> 4) Said that, and assuming that there is also a UDP ICE valid= pair, I
>> also expect (and this is a bit exotic but IMHO it SHOULD work) tha= t
>> the browser should be able to send a DTLS Close Alert over the UDP=
>> valid pair (this is, even when the DTLS handshake and RTP is being=
>> sent over the TCP nominated pair).
>
>
> Any DTLS close alert would nuke the entire DTLS connection, which is > currently fatal in Chrome.

Sure, I just meant that, theoretically, the DTLS alert can be sent over any valid pair (even if it is not the selected one).
<= div>

Thanks a lot. This is now clear for me, but IMHO we have a serious
problem given that RFC 5764 insists on "A single DTLS-SRTP session
only protects data carried over a single UDP source and destination
port pair".




--f46d04389533b16b360500713a85-- From nobody Tue Aug 12 16:56:58 2014 Return-Path: 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 65B841A0A8D; Tue, 12 Aug 2014 16:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 mmvFOxsHpewP; Tue, 12 Aug 2014 16:56:52 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C8D1A079F; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id nu7so7848740obb.0 for ; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TvOMDq5bVsm7hrc0pMtqzJ3nCKU6PoaHcLOkO23aYxw=; b=Q2edh9KLW9eYpiJj7ynYizJxi2kDLXhA+WMrRGDFSwuWjFjw6l7ID0T4Cg4ifLYflI 9krQwPRmtajzhKepJRPiSlzdXx726KuTAfhsHatbGMn2PfyKAhIOjoWJ27DuD5y/A53P PbBoP81QEVdyfvvvWR+QdV0mYtj+A0i99lN7eVoE+OCrf6UcJ3EuE1I5sJw/CxQVrurK gV3yjCrAWpFCOV+tm+2rpCZZpgVDtgUDTu1gC4rdWCmoxN0AKcgu1WZGgiZm1gEsMV37 1KinnXCsG9qOV6vcurtE3jA6biqj7Ww9hH7tH+XHpMIS5p83eAeiKksRp4xThpJgT3y9 f1VQ== MIME-Version: 1.0 X-Received: by 10.60.74.104 with SMTP id s8mr1039793oev.5.1407887811135; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) Received: by 10.202.93.69 with HTTP; Tue, 12 Aug 2014 16:56:51 -0700 (PDT) In-Reply-To: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> Date: Tue, 12 Aug 2014 16:56:51 -0700 Message-ID: From: Dave Taht To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mN6OwlmSn4ekttrYBcEQqIk_TnU Cc: mmusic@ietf.org, draft-ietf-dart-dscp-rtp.all@tools.ietf.org, "clue@ietf.org" , avt@ietf.org, "rmcat@ietf.org" , "rtcweb@ietf.org" , "tsvwg@ietf.org" Subject: Re: [rtcweb] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:56:54 -0000 This is also of some interest to me at least, and perhaps some members of the AQM working group who are working out weighted fair queuing and wred like approaches to these needs. Anyway, I do try to track thinking in this area in the ongoing development of cerowrt's sqm system, which has pluggable modules for all the known aqm and fq schedulers, and a three tier system modeled on wondershaper for managing traffic, which uses what diffserv markings that I have observed make sense... Some relevant links: http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt= _310 http://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management Missing from this discussion so far is what is actually deployed out there... I am only familiar with stuff like the above as an egress/ingress queue management system... AND: in the case of linux based wireless routers, none of the AF codepoints are respected explicitly, and how the codepoints are mapped are described by 802.11e - and that is far more about scheduling priority for airtime rather than drop probability. It is kind of hard to wrap your head around how 802.11e actually works, but, this is a start: http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel= _access_.28EDCA.29 In linux wifi at least: CS0, CS3 are mapped into the BE hw queue CS1, CS2 are mapped into the BK hw queue CS4, CS5 are mapped into the VI hw queue CS6, CS7 are mapped into the VO hw queue Bit patterns for the other classes to whatever extent they map into CSX are mapped into the underlying hardware queue. I am not saying this is an optimal state of affairs, (as notably VO should be as completely disabled as possible in the 802.11n and ac age), and am very interested in how other OSes (ios, osx, windows), and router/switch OSes do it, but the wireless scheduling aspect of all these codepoints does not seem to be well touched upon. On a personal note I tend to think that having 17+ ways to slice up traffic is about 13 or 14 too many, particularly those targetting a drop probability. When you have drop rates well below a few percentage points, adding another percentage point of granularity seems futile. Lastly, there is also an implementation issue in linux presently in that doing extensive diffserv classification basically requires one iptables or tc rule per class, which is inefficient. Someone (not me!) doing some code for doing diffserv saner there would go a long way... On Sat, Aug 9, 2014 at 11:48 AM, Ben Campbell wrote: > Hi, > > The DART working group has started a last call for draft-ietf-dart-dscp-r= tp-02, ending on August 22. This informational draft describes consideratio= ns for the use of DiffServ code points in situations where one multiplexes = multiple RTP packet streams, and potentially other protocol streams, that s= hare the same 5-tuple. > > Since this draft is likely of interest to several working groups, I would= like to solicit additional reviews from participants of TSVWG, AVTCORE, MM= USIC, CLUE, RTCWEB, and RMCAT. Please send any feedback (including feedback= to the effect of "this is ready to progress") to the DART working group ma= iling list. > > Thanks! > > Ben. > > Begin forwarded message: > >> Resent-From: draft-alias-bounces@tools.ietf.org >> From: Ben Campbell >> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 >> Date: August 9, 2014 at 12:50:16 PM CDT >> Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com >> To: dart@ietf.org >> Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, Ric= hard Barnes >> >> This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. I= t's available on the data tracker at the following URL: >> >> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >> >> The WGLC will conclude on 22 August, 2014. Please send your comments to = the authors and the DART mailing list. If you've reviewed it and think it's= good to go, please say so. >> >> Thanks! >> >> Ben. >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article From nobody Wed Aug 13 00:34:50 2014 Return-Path: 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 7511C1A701E for ; Wed, 13 Aug 2014 00:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 Vc0Fvh-wdTLq for ; Wed, 13 Aug 2014 00:34:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACBCD1A701D for ; Wed, 13 Aug 2014 00:34:45 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B87DCB0C64C97; Wed, 13 Aug 2014 07:34:42 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s7D7YftX017116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 09:34:42 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 13 Aug 2014 09:34:41 +0200 From: "Schwarz, Albrecht (Albrecht)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: TLS or DTLS?; RE: [rtcweb] How to reset DTLS over TCP if the connection is closed Thread-Index: AQHPsu++lbOZqSH1Kky39tupSFGXNZvL35mAgADRfmD//+iTAIABjy5Q Date: Wed, 13 Aug 2014 07:34:40 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC2CAF9E@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC2CA5A4@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hp1XGQaTBeqGb7XhR7q3cUtBkNg Cc: "rtcweb@ietf.org" Subject: [rtcweb] TLS or DTLS?; RE: How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 07:34:49 -0000 UmlnaHQsIHRoaXMgaXMgcm91Z2hseSBkZXNjcmliZWQgaW4gdGhlIG92ZXJ2aWV3IHNlY3Rpb24s IHdoaWNoIHByb3ZpZGVzIG9ubHkgaW5mb3JtYXRpdmUgc3RhdGVtZW50cywgYnV0IG5vdCBhbnkg bm9ybWF0aXZlIGJlaGF2aW91ci4NClRoZSBsYXRlciBzZWN0aW9ucyB0YWxrIGFib3V0IGEgIlRM UyBvciBEVExTLVNSVFAgc2Vzc2lvbiIgKGFuZCBub3QgYSBUTFMsIERUTFMgb3IgRFRMUy1TUlRQ IHNlc3Npb24pLCB3aGljaCB3b3VsZCBiZSBpbnRlcnByZXRlZCB0aGF0IHRoZSBrZXkgZXhjaGFu Z2UgZm9yIFNSVFAgdXNlcyBEVExTLVNSVFAsIGJ1dCB0aGUgImFwcGxpY2F0aW9uIiBpdHNlbGYg d291bGQgdXNlIGEgVExTL1JGQyA0NTcxL1RDUCB0cmFuc3BvcnQuDQoNCklmIFJGQyA2NTQ0IHdv dWxkIGFsbG93IGFuICJhcHBsaWNhdGlvbi9EVExTL1JGQyA0NTcxL1RDUCIgdHJhbnNwb3J0LCB0 aGVuIEkgd291bGQgZXhwZWN0IHNvbWUgaW5mb3JtYXRpb24gaG93IHRoZSBpbnRlcmFjdGlvbnMg YmV0d2VlbiB0aGUgRFRMUyBhbmQgVENQIGxheWVycyBhcmUgcmVzb2x2ZWQgaW4gY2FzZSBvZiBw YWNrZXQgbG9zcyAoImdpdmVuIHRoZSB0d28gc2VwYXJhdGUgZnVuY3Rpb25zIGhvdyBwYWNrZXQg bG9zcyBpcyBoYW5kbGVkIGJ5IFRDUCBhbmQgRFRMUyIpLCByaWdodD8NCg0KRm9yIGluc3RhbmNl LCBSRkMgNjU0NCBjb3VsZCBzdGF0ZSB0aGF0IGEgIlJGQyA2NTQ0IERUTFMgc2Vzc2lvbiIgd291 bGQgbmVlZCB0byBiZSBwcm9maWxlZCBmb3IgZW11bGF0aW5nIFRMUyBiZWhhdmlvdXIgYnkgYSBj b3JyZXNwb25kZW50IGFsaWdubWVudCBvZiBUQ1AgcmV0cmFuc21pc3Npb24gdGltZXIgYW5kIERU TFMgcmV0cmFuc21pc3Npb24gdGltZXIgc2V0dGluZ3MgLi4uIChtaWdodCBiZSBmZWFzaWJsZSwg YnV0IGxvb2tzIG9kZCwgd2h5IG5vdCBUTFMgaW5zdGVhZD8pLg0KDQpEbyBJIG1pc3Mgc3RoLj8N Cg0KQWxicmVjaHQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEnDsWFraSBC YXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XSANClNlbnQ6IERpZW5zdGFnLCAxMi4g QXVndXN0IDIwMTQgMTE6MzQNClRvOiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpDQpDYzog SnVzdGluIFViZXJ0aTsgcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSG93 IHRvIHJlc2V0IERUTFMgb3ZlciBUQ1AgaWYgdGhlIGNvbm5lY3Rpb24gaXMgY2xvc2VkDQoNCjIw MTQtMDgtMTIgMTE6MDAgR01UKzAyOjAwIFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCkNCjxh bGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50LmNvbT46DQo+IGlmIGZpbmFsbHkgVENQIHdv dWxkIGJlIHNlbGVjdGVkIGFzIEw0IHByb3RvY29sIChpbnN0ZWFkIG9mIFVEUCksIHRoZW4gDQo+ IFRMUyB3b3VsZCBiZSB1c2VkIGluc3RlYWQgb2YgRFRMUywgcmlnaHQ/DQoNCk5vLiBJdCBpcyBT VFVOLCBEVExTIGFuZCBTUlRQL1NSVENQIG92ZXIgVENQLg0KDQpSRkMgNjU0NCAoSUNFIFRDUCkg YWxsb3dzIGJvdGggRFRMUyBhbmQgVExTOg0KDQogICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgfCAgICBBcHAgICB8DQogICAgICAgICAgICArLS0tLS0tLS0tLSstLS0tLS0t LS0tKyAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsNCiAgICAgICAgICAgIHwgICAgICAgICAg fCAgICAgICAgICB8ICAgICB8ICAgICAgICAgIHwgICAgICAgICAgfA0KICAgICAgICAgICAgfCAg IFNUVU4gICB8ICAoRClUTFMgIHwgICAgIHwgICBTVFVOICAgfCAgICBBcHAgICB8DQogICAgICAg ICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsN CiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfA0KICAgICAgICAgICAgfCAgICAgIFJGQyA0NTcxICAgICAgIHwgICAgIHwgICAgICBS RkMgNDU3MSAgICAgICB8DQogICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgfCAgICAgICAgIFRD UCAgICAgICAgIHwgICAgIHwgICAgICAgICBUQ1AgICAgICAgICB8DQogICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICB8ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgfCAgICAgICAgIElQICAgICAgICAgIHwgICAgIHwgICAgICAgICBJUCAgICAg ICAgICB8DQogICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICBGaWd1cmUgMTogSUNFIFRDUCBTdGFjayB3 aXRoIGFuZCB3aXRob3V0IChEKVRMUw0KDQpidXQgQUZBSUsgV2ViUlRDIGp1c3QgdXNlcyBEVExT IGFuZCBub3QgVExTIChub3RlIHRoYXQgd2UgYXJlIG5vdCB0YWxraW5nIGFib3V0IFRVUk4gaW4g d2hpY2ggVExTIGlzIHN1cHBvcnRlZCkuDQoNCg0KDQoNCi0tDQpJw7Fha2kgQmF6IENhc3RpbGxv DQo8aWJjQGFsaWF4Lm5ldD4NCg0KDQpGcm9tOiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp IA0KU2VudDogRGllbnN0YWcsIDEyLiBBdWd1c3QgMjAxNCAxMTowMA0KVG86ICdKdXN0aW4gVWJl cnRpJw0KQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtydGN3ZWJdIEhvdyB0byBy ZXNldCBEVExTIG92ZXIgVENQIGlmIHRoZSBjb25uZWN0aW9uIGlzIGNsb3NlZA0KDQpKdXN0aW4s DQpxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbjoNCg0KaWYgZmluYWxseSBUQ1Agd291bGQgYmUg c2VsZWN0ZWQgYXMgTDQgcHJvdG9jb2wgKGluc3RlYWQgb2YgVURQKSwgdGhlbiBUTFMgd291bGQg YmUgdXNlZCBpbnN0ZWFkIG9mIERUTFMsIHJpZ2h0Pw0KKElmIHllcywgdGhlbiBkaXNjdXNzaW9u IHdvdWxkIGJlIGFib3V0IOKAnHJlc2V0IFRMUyBvdmVyIFRDUCDigKbigJ0gaW4gdW5kZXJzdGFu ZGluZykuDQoNCi1BbGJyZWNodA0KDQo= From nobody Wed Aug 13 01:35:26 2014 Return-Path: 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 C76DA1A077A; Wed, 13 Aug 2014 01:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4o2v3ec3hWFD; Wed, 13 Aug 2014 01:35:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD921A0077; Wed, 13 Aug 2014 01:35:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140813083523.4678.97862.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 01:35:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0wcvVQN_jCIcGbZhtmkZtQWe1w0 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-06.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 08:35:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-06.txt Pages : 14 Date : 2014-08-13 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-transports-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 13 05:50:42 2014 Return-Path: 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 775801A002B for ; Wed, 13 Aug 2014 05:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 R4889mVIfWMZ for ; Wed, 13 Aug 2014 05:50:37 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id DB9311A0021 for ; Wed, 13 Aug 2014 05:50:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B210A7C3D69 for ; Wed, 13 Aug 2014 14:50:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LINoRhG2msFN for ; Wed, 13 Aug 2014 14:50:34 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:480e:b098:4917:7a16]) by mork.alvestrand.no (Postfix) with ESMTPSA id 78BC27C3D63 for ; Wed, 13 Aug 2014 14:50:34 +0200 (CEST) Message-ID: <53EB5F1A.3070107@alvestrand.no> Date: Wed, 13 Aug 2014 14:50:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53C873CD.7080308@alum.mit.edu> In-Reply-To: <53C873CD.7080308@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BGLyEuRLEu07dy3s-x-ZXe-IyWE Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-overview-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 12:50:41 -0000 Finally got to this. Sorry it's taken so long. On 07/18/2014 03:09 AM, Paul Kyzivat wrote: > I haven't read the overview carefully in a long time. This time I did. > I came away with the following thoughts: > > Terminology: > > Media path: The path that media data follows from one browser to > another. > > I don't think this is quite right by restricting to browsers. I think > you mean: > > Media path: The path that media data follows from one WebRTC device > to another. Yep. Thanks! > > The intent is clear (e.g. from figure 2) but the definition doesn't > say it. > > Also, why aren't "WebRTC browser" and "WebRTC device" included in the > Terminology section? Seems like they should be. Fixed now. > > Section 5: > > Considerations for the transfer of data that is not in RTP format is > described in [I-D.ietf-rtcweb-data-channel], and a supporting > protocol is described in [I-D.ietf-rtcweb-data-protocol]. Webrtc > devices MUST implement these two specifications. > > Actually ietf-rtcweb-data-protocol only describes a protocol used for > data channel *establishment*. As such, I think it is technically a > Connection management protocol. This becomes more evident when you > consider all the discussion on how to establish channels via SDP. > > In principle I think ietf-rtcweb-data-protocol should be referenced > from section 7. If that seems heretical, then how about at least saying: > > Considerations for the transfer of data that is not in RTP format is > described in [I-D.ietf-rtcweb-data-channel], and a supporting > protocol for establishing individual data channels is described in > [I-D.ietf-rtcweb-data-protocol]. Webrtc devices MUST implement > these two specifications. Fix applied. I think it fits better here than in section 7, since section 7 deals with management of the overall connection. > > Otherwise this document is remarkably clear. Thank you! > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Aug 13 06:37:06 2014 Return-Path: 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 905741A0198 for ; Wed, 13 Aug 2014 06:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.668] 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 4XBFtl9Typzi for ; Wed, 13 Aug 2014 06:37:03 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id B2A621A017F for ; Wed, 13 Aug 2014 06:37:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 92C9A7C3C86; Wed, 13 Aug 2014 15:37:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4bhxicH6dVu; Wed, 13 Aug 2014 15:37:00 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:480e:b098:4917:7a16]) by mork.alvestrand.no (Postfix) with ESMTPSA id AA3FB7C05CD; Wed, 13 Aug 2014 15:37:00 +0200 (CEST) Message-ID: <53EB69FB.9070306@alvestrand.no> Date: Wed, 13 Aug 2014 15:36:59 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Emil Ivov , RTCWEB References: <53CFC899.6010307@jitsi.org> In-Reply-To: <53CFC899.6010307@jitsi.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gbusIgmKbgjMp_EmZUqBXwhWJJQ Subject: Re: [rtcweb] Efficient crypto for conferences X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 13:37:04 -0000 Catching up on mail..... On 07/23/2014 04:37 PM, Emil Ivov wrote: > Hey all, > > Lately, we have been working on SFU-based conferencing. SFUs and > WebRTC go together quite well: SFUs scale beautifully and are very > latency friendly which makes them great for cloud deployment. > > But! > > There is a glass ceiling currently that I was hoping we could discuss. > > Performance. > > Currently the only way an SFU can operate is by terminating DTLS/SRTP > for every participant. This means decrypting and (worse) re-encrypting > all traffic that traverses the SFU. This easily accounts for 90% of > the CPU use on the SFU. Do you have an actual measurement giving this figure? Over what configuration and AES implementation? Last time I was evaluating this, I think profiling of the conferencing engine showed that less than 5% of the time was spent in the decrypt/encrypt functions - of course, we might just have been massively inefficient in the rest of the things that implementation was doing. > > This is not a difficult problem to solve and AVTCORE even has a WG > document that addresses it. It removes the need for decrypting and > allows SFUs to just forward packets. > > However, while chatting with many others in Toronto it appeared that > most of us are focused on solving a slightly different problem: > > Privacy. > > Or in other words: making it impossible (as opposed to unnecessary) > for SFUs to decrypt. > > While this is a notable effort, it is also much more complex and parts > of it (i.e. not requiring end users to trust their web provider) would > be arguably very hard to solve. > > Therefore, my question to the working group is: wouldn't it make sense > to try and solve the efficiency issue as a first step and then worry > about the privacy one on a later stage? > > Emil > From nobody Wed Aug 13 08:51:22 2014 Return-Path: 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 A0B201A03C8 for ; Wed, 13 Aug 2014 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 W63geJYX2VvK for ; Wed, 13 Aug 2014 08:51:18 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6EE1A03C4 for ; Wed, 13 Aug 2014 08:51:18 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so11271250wes.6 for ; Wed, 13 Aug 2014 08:51:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j+LVhslhGfXIqlVZUKQEVyyUm/LwdcxODsMPNNqd4qc=; b=LFjq0jrjpYiRE4adVDGeVCS/vLCJVWnAdKMsHNfxlnXxbOXXymW47+Rp/B3nnYPR1a FSHx2i37kv3IbUCT3xwVKc5bay/noexSWvNFLj2JvSInGqG+71idvBU517izzFxlppAn JENyue1v+/hR0kDmp5GbnDfP/IA4tm2BdfJDK6HxIm09bYgmUNAACL4yXt7cpowyrTMo 5plVvVhXah5hCZhlDB0jkMQlZQOtdyiCP9CUsKirQf7vd3MK+XhVWt9DtX2G18fzWbf0 NfezVG5mP3f9VWxdtvsd/bFpzbyvZkQr3CUMEF75NwzH4v8qSh7CGQC7q/i5+7If+ZwK CmjA== X-Gm-Message-State: ALoCoQn7rEnSC4Xg54YZ0ZbtoPDrcs+rhtkwt+/4cqULvY/5YQpkAUN2XsAviGtW9zltOoTxh3ov X-Received: by 10.180.184.20 with SMTP id eq20mr5585530wic.37.1407945077241; Wed, 13 Aug 2014 08:51:17 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by mx.google.com with ESMTPSA id kw1sm5221511wjb.19.2014.08.13.08.51.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 08:51:16 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so1014275wib.8 for ; Wed, 13 Aug 2014 08:51:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.161.231 with SMTP id xv7mr950503wjb.78.1407945075847; Wed, 13 Aug 2014 08:51:15 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Wed, 13 Aug 2014 08:51:15 -0700 (PDT) In-Reply-To: <53EB69FB.9070306@alvestrand.no> References: <53CFC899.6010307@jitsi.org> <53EB69FB.9070306@alvestrand.no> Date: Wed, 13 Aug 2014 11:51:15 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e01493c541bf9ee050084c2a4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/v5ZB1qe_EKAbvBxTpBaAo8EwsH8 Cc: RTCWEB Subject: Re: [rtcweb] Efficient crypto for conferences X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 15:51:21 -0000 --089e01493c541bf9ee050084c2a4 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 13, 2014 at 9:36 AM, Harald Alvestrand wrote: > On 07/23/2014 04:37 PM, Emil Ivov wrote: > >> Currently the only way an SFU can operate is by terminating DTLS/SRTP for >> every participant. This means decrypting and (worse) re-encrypting all >> traffic that traverses the SFU. This easily accounts for 90% of the CPU use >> on the SFU. >> > > Do you have an actual measurement giving this figure? Over what > configuration and AES implementation? > > Last time I was evaluating this, I think profiling of the conferencing > engine showed that less than 5% of the time was spent in the > decrypt/encrypt functions - of course, we might just have been massively > inefficient in the rest of the things that implementation was doing. > I think we are talking about different conferencing servers here. In case of audio conferencing server where all the audio streams are received, de-jittered, decoded, mixed, re-encoded, and then re-encrypted, decryption/encryption procedures account for about 5-10% of the total CPU load. In case of packet forwarding unit, where streams from one participant is forwarded to several other participants as is (i.e, each conference participant receives audio and video stream from each other participant and then mixes audio on the client side and displays each video stream independently), the forwarding unit receives packets from the network decrypts/encrypts and forwards the data. A typical modern dual CPU Xeon server can do about 1-2GB of traffic in cases where it needs to do decryption/encryption and forward traffic. In cases where the server can simply forward packets, it can easily do around 10GB of traffic. In other words, encryption accounts for 90% of the CPU load on such server. _____________ Roman Shpount --089e01493c541bf9ee050084c2a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 07/23/2014 04:37 PM, Emil Iv= ov wrote:
Currently the only way an SFU can operate is by terminatin= g DTLS/SRTP for every participant. This means decrypting and (worse) re-enc= rypting all traffic that traverses the SFU. This easily accounts for 90% of= the CPU use on the SFU.

Do you have an actual measurement giving this figure? Over what configurati= on and AES implementation?

Last time I was evaluating this, I think profiling of the conferencing engi= ne showed that less than 5% of the time was spent in the decrypt/encrypt fu= nctions - of course, we might just have been massively inefficient in the r= est of the things that implementation was doing.

I think we are talking about different con= ferencing servers here. In case of audio conferencing server where all the = audio streams are received, de-jittered, decoded, mixed, re-encoded, and th= en re-encrypted, decryption/encryption procedures account for about 5-10% o= f the total CPU load. In case of packet forwarding unit, where streams from= one participant is forwarded to several other participants as is (i.e, eac= h conference participant receives audio and video stream from each other pa= rticipant and then mixes audio on the client side and displays each video s= tream independently), the forwarding unit receives packets from the network= decrypts/encrypts and forwards the data. A typical modern dual CPU Xeon se= rver can do about 1-2GB of traffic in cases where it needs to do decryption= /encryption and forward traffic. In cases where the server can simply forwa= rd packets, it can easily do around 10GB of traffic. In other words, encryp= tion accounts for 90% of the CPU load on such server.
_____________
Roman Shpount
=C2=A0
--089e01493c541bf9ee050084c2a4-- From nobody Wed Aug 13 09:10:33 2014 Return-Path: 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 9C7801A08EF for ; Wed, 13 Aug 2014 09:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 qprV5J4ln1qu for ; Wed, 13 Aug 2014 09:10:29 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A5A1A08EC for ; Wed, 13 Aug 2014 09:10:27 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id l13so10704040iga.10 for ; Wed, 13 Aug 2014 09:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nL6xapNIhaWSAff5t8hLF4h/fGPLmdYhoOhdKJQ3Gw0=; b=y5CRsPFwnlWOZz35g9JFNiaU9Mny4q0zcz2RDcmUn0rtqqdEEreVXb3B0kX8c4oezG vsNSJoivQUDrJK3fXQtLc65wQsJQn5gfJ8lDA/I9QdhZPqcxk27pvNA2PhCEAuBpAbCC H2EN6ydt9ex/W28OyZIvXjA3KCGVdq3IMOjZb0hvLkWBl/QM19K1Z3kHL/U4R4yfZURG I4CLutU+bVEM95yqOAZZ8Zz31XJHn8rMNoTRpxe0fQkv13/eYSborWcSz5v1fPDyakfH Cuwk76DUHWk3g1iSu+Rd/QzBb7qC9RM87sicWmA5+ewKnbh2f2GrXQOmmQOrbxvKm/hs HPug== MIME-Version: 1.0 X-Received: by 10.42.47.140 with SMTP id o12mr7839023icf.4.1407946227310; Wed, 13 Aug 2014 09:10:27 -0700 (PDT) Received: by 10.43.154.80 with HTTP; Wed, 13 Aug 2014 09:10:27 -0700 (PDT) Date: Wed, 13 Aug 2014 09:10:27 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba6149aabde6f705008506e3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9gQyxyztPKJ_mot8-fRYQxF9Xrg Subject: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 16:10:30 -0000 --90e6ba6149aabde6f705008506e3 Content-Type: text/plain; charset=UTF-8 For a while now the draft has said: For UDP, this specification assumes the ability to set the DSCP code point of the sockets opened on a per-packet basis, in order to achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos] (see Section 4.1) when multiple media types are multiplexed. It does not assume that the DSCP codepoints will be honored, and does assume that they may be zeroed or changed, since this is a local configuration issue. Platforms that do not give access to these interfaces will not be able to support a conforming WebRTC implementation. If a platform does not have this capability or does not honor the request to use it (since it may be limited to privileged users), it seems possible that an alternate approach is for the WebRTC implementation to suspend cross-media type multiplexing when it is not available. There's a cost to that, especially for IPv4, but that still seems to support a conforming use of WebRTC. Would the working group support describing that alternative as conforming? My concern here is that access to the ability to set different DSCP markings on a per packet basis for a flow may not be available generally on all platforms. Even if we want to make a forward looking push toward that ability, naming what we think is the appropriate alternative may make sense. regards, Ted (as an individual) --90e6ba6149aabde6f705008506e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For a while now the draft has said:
   For =
UDP, this specification assumes the ability to set the DSCP code
   point of the sockets opened on a per-packet basis, in order to
   achieve the prioritizations described in [I-D.ietf-tsvwg-rtcweb-qos]
   (see Section 4.1) when multiple media types are multiplexed.  It does
   not assume that the DSCP codepoints will be honored, and does assume
   that they may be zeroed or changed, since this is a local
   configuration issue.

   Platforms that do not give access to these interfaces will not be
   able to support a conforming WebRTC implementation.
If a=20 platform does not have this capability or does not honor the request to=20 use it (since it may be limited to privileged users), it seems possible=20 that an alternate approach is for the WebRTC implementation to suspend=20 cross-media type multiplexing when it is not available.=C2=A0 There's a= cost to that, especially for=20 IPv4, but that still seems to support a conforming use of WebRTC.

Would the working group support describing that alternativ= e as conforming?

My concern here is that access to the ability to set different DSCP marking= s on a per packet basis for a flow may not be available generally on all pl= atforms.=C2=A0 Even if we want to make a forward looking push toward that a= bility, naming what we think is the appropriate alternative may make sense.=

regards,

Ted (as an individual)

--90e6ba6149aabde6f705008506e3-- From nobody Wed Aug 13 12:08:40 2014 Return-Path: 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 B56291A0389 for ; Wed, 13 Aug 2014 12:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 lww48Prv179Z for ; Wed, 13 Aug 2014 12:08:20 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8971A04B8 for ; Wed, 13 Aug 2014 12:07:22 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so7893386wib.2 for ; Wed, 13 Aug 2014 12:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qp9PWGua/ll46x1CLhy2vtKNllDaGhgC3NGQNYI+GlE=; b=kekz/bUY4v8IaC04N/X8VtUHapO8/Wx21vUdm9rFbOlGik9dga13h6pXGk8/MZ5N/k lILwX3ptXphEePEd5UQCXHkq3IXQ0dvfftfkZIpNJs3kJFevnuIK5aBxUVJctdG3ef5y d/KeYrEjbHXFBPqP948G+zhAzZgsCMqBPDiLRfGLqUi7w3RmqH3/pZ5Kt2gayv9yhRO9 TAeRuzfpj0j6sa7NxZZFTYdd1T6ZfJTGUAR8ga6Qirw3K2oAvqkKsjRUzJs5xDNQQv8P MrZVgBM9vA2SDZXWVOurvSLOXWpyIVaVSdj9ei8+gPeo1rK3Q6sBR/z+AHAW/glPEhH4 e6Fg== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr6106604wjb.59.1407956840552; Wed, 13 Aug 2014 12:07:20 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Wed, 13 Aug 2014 12:07:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Aug 2014 12:07:20 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OXqvBg_NfSHXaVS2t5HZoTET6eU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 19:08:25 -0000 On 13 August 2014 09:10, Ted Hardie wrote: > My concern here is that access to the ability to set different DSCP markings > on a per packet basis for a flow may not be available generally on all > platforms. Even if we want to make a forward looking push toward that > ability, naming what we think is the appropriate alternative may make sense. Yeah, requiring per-packet DSCP seems overly enthusiastic. From nobody Wed Aug 13 13:49:19 2014 Return-Path: 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 77C441A00BA for ; Wed, 13 Aug 2014 13:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_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 M5Rd6ydc_tRC for ; Wed, 13 Aug 2014 13:49:12 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC051A0087 for ; Wed, 13 Aug 2014 13:49:12 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so397363vcb.0 for ; Wed, 13 Aug 2014 13:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pw0Ski3fobK7z6hbq9e3OllLUvmbmSa7qkKUMsQz+qo=; b=fxyQBD1lTo+pxFcL4hftXKorOi3/2SDMaG9v2e6ugE0fa2f4NnNSQINkxGSkiNDV23 4gsNQy4uS0WeaSICwZtt19Ch1g2yi1aI9SR9oV/0fNhuXaJKkNX7pa5EAHIEutupSzFD jqLLHvE3R0itCzME3J4IxXeP8Z40AsPK93LqlOujtJ8uuPBTk0H4pALBx1I5I9tiCI4k j3b2dgOQ6d344j6j2ntJQtm/gUfuHH5kizD2SzV8I44Ra4eHh7Zpoaf4umgdDN6k1luj S3j5c7b6CV1H/J+mufrD346B1EqHjcsZwLGUYD+8GdJC8fvztGGJ2aL1PWh/q4y0eDW/ TG1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pw0Ski3fobK7z6hbq9e3OllLUvmbmSa7qkKUMsQz+qo=; b=G2UhoyZIg1lLZhS5KffqHQBajDr+qKXjpH7KyitiOysAlCnpGih0mkVjW/E4ajUR+q UdSKQ2ThTJ6fkaFWeHoS3YluMOzH5xMabdK4XifboSXLrQZSiCU1hWdooCkSVmXYsQxa XgCuWLddbJs0OTnurTZFbrUJ7Syxqc9evTaeE4upDuqbhl1gywWcS++i+yiQH6h87/IB jmLd/Zpo5FSLOvuQGxaGIsK9etInk4su8EVW7ycYYYQvshYDbPm0fa7htFXwZNq+J2+j JHW0oaA8KvVVAEZk2KdNkOCbDGrsAJZ8XwrEVVz7tcUEZwZpH9HiiK+CO1GnWPnedn2D Untg== X-Gm-Message-State: ALoCoQnFMaVsiTXLnnac5/QDX2sPeP0wJBmjrOQOy/onrFp0x2PGiyCzahlOqusGeiVAkul+BxGQ X-Received: by 10.52.185.193 with SMTP id fe1mr4927163vdc.31.1407962951204; Wed, 13 Aug 2014 13:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Wed, 13 Aug 2014 13:48:51 -0700 (PDT) In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC2CAF9E@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC2CA5A4@FR711WXCHMBA03.zeu.alcatel-lucent.com> <786615F3A85DF44AA2A76164A71FE1AC2CAF9E@FR711WXCHMBA03.zeu.alcatel-lucent.com> From: Justin Uberti Date: Wed, 13 Aug 2014 13:48:51 -0700 Message-ID: To: "Schwarz, Albrecht (Albrecht)" Content-Type: multipart/alternative; boundary=bcaec548a399907fa8050088ebd1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Q98emaDeZmTEnOkXxXa0Vo_CPd4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] TLS or DTLS?; RE: How to reset DTLS over TCP if the connection is closed X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 20:49:17 -0000 --bcaec548a399907fa8050088ebd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 13, 2014 at 12:34 AM, Schwarz, Albrecht (Albrecht) < albrecht.schwarz@alcatel-lucent.com> wrote: > Right, this is roughly described in the overview section, which provides > only informative statements, but not any normative behaviour. > The later sections talk about a "TLS or DTLS-SRTP session" (and not a TLS= , > DTLS or DTLS-SRTP session), which would be interpreted that the key > exchange for SRTP uses DTLS-SRTP, but the "application" itself would use = a > TLS/RFC 4571/TCP transport. > If DTLS-SRTP/4571/TCP is permitted, then clearly application/DTLS/4571/TCP must be permitted, especially in the context of BUNDLE. You could of course use application/TLS/4571/TCP as well, but for real-time applications I think that is generally inadvisable, since such applications will typically not make any reliability guarantees regarding the ICE layer (e.g. may discard outgoing packets when flow control is encountered) > If RFC 6544 would allow an "application/DTLS/RFC 4571/TCP" transport, the= n > I would expect some information how the interactions between the DTLS and > TCP layers are resolved in case of packet loss ("given the two separate > functions how packet loss is handled by TCP and DTLS"), right? > For instance, RFC 6544 could state that a "RFC 6544 DTLS session" would > need to be profiled for emulating TLS behaviour by a correspondent > alignment of TCP retransmission timer and DTLS retransmission timer > settings ... (might be feasible, but looks odd, why not TLS instead?). > TLS requires a reliable transport, but in the 6544 case, TCP is not being used to guarantee reliability, but rather, provide connectivity in situations where use of UDP is not possible. TCP optimizations for real-time apps, such as Minion, will only exacerbate this. Therefore use of TLS is contraindicated in these situations. It would probably be worthwhile for DTLS and any higher-level protocols (e.g. SCTP) to adjust their timers when running over TCP. > > Do I miss sth.? > > Albrecht > > -----Original Message----- > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Dienstag, 12. August 2014 11:34 > To: Schwarz, Albrecht (Albrecht) > Cc: Justin Uberti; rtcweb@ietf.org > Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is > closed > > 2014-08-12 11:00 GMT+02:00 Schwarz, Albrecht (Albrecht) > : > > if finally TCP would be selected as L4 protocol (instead of UDP), then > > TLS would be used instead of DTLS, right? > > No. It is STUN, DTLS and SRTP/SRTCP over TCP. > > RFC 6544 (ICE TCP) allows both DTLS and TLS: > > +----------+ > | | > | App | > +----------+----------+ +----------+----------+ > | | | | | | > | STUN | (D)TLS | | STUN | App | > +----------+----------+ +----------+----------+ > | | | | > | RFC 4571 | | RFC 4571 | > +---------------------+ +---------------------+ > | | | | > | TCP | | TCP | > +---------------------+ +---------------------+ > | | | | > | IP | | IP | > +---------------------+ +---------------------+ > > Figure 1: ICE TCP Stack with and without (D)TLS > > but AFAIK WebRTC just uses DTLS and not TLS (note that we are not talking > about TURN in which TLS is supported). > > > > > -- > I=C3=B1aki Baz Castillo > > > > From: Schwarz, Albrecht (Albrecht) > Sent: Dienstag, 12. August 2014 11:00 > To: 'Justin Uberti' > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] How to reset DTLS over TCP if the connection is > closed > > Justin, > question for clarification: > > if finally TCP would be selected as L4 protocol (instead of UDP), then TL= S > would be used instead of DTLS, right? > (If yes, then discussion would be about =E2=80=9Creset TLS over TCP =E2= =80=A6=E2=80=9D in > understanding). > > -Albrecht > > --bcaec548a399907fa8050088ebd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 13, 2014 at 12:34 AM, Schwarz, Albrecht (Albrecht) <albrecht.schwarz@alcatel-lucent.com> wrote:
Right, this is roughly described in the over= view section, which provides only informative statements, but not any norma= tive behaviour.
The later sections talk about a "TLS or DTLS-SRTP session" (and n= ot a TLS, DTLS or DTLS-SRTP session), which would be interpreted that the k= ey exchange for SRTP uses DTLS-SRTP, but the "application" itself= would use a TLS/RFC 4571/TCP transport.

If DTLS-SRTP/4571/TCP is permitted, then c= learly application/DTLS/4571/TCP must be permitted, especially in the conte= xt of BUNDLE.

You could of course use application/= TLS/4571/TCP as well, but for real-time applications I think that is genera= lly inadvisable, since such applications will typically not make any reliab= ility guarantees regarding the ICE layer (e.g. may discard outgoing packets= when flow control is encountered)


If RFC 6544 would allow an "application/DTLS/RFC 4571/TCP" transp= ort, then I would expect some information how the interactions between the = DTLS and TCP layers are resolved in case of packet loss ("given the tw= o separate functions how packet loss is handled by TCP and DTLS"), rig= ht?=C2=A0

For instance, RFC 6544 could state that a "RFC 6544 DTLS session"= would need to be profiled for emulating TLS behaviour by a correspondent a= lignment of TCP retransmission timer and DTLS retransmission timer settings= ... (might be feasible, but looks odd, why not TLS instead?).

TLS requires a reliable transport, but in = the 6544 case, TCP is not being used to guarantee reliability, but rather, = provide connectivity in situations where use of UDP is not possible. TCP op= timizations for real-time apps, such as Minion, will only exacerbate this. = Therefore use of TLS is contraindicated in these situations.

It would probably be worthwhile for DTLS and any higher= -level protocols (e.g. SCTP) to adjust their timers when running over TCP.<= /div>

Do I miss sth.?

Albrecht

-----Original Message-----
From: I=C3=B1aki Baz Castillo [mailto:ibc@= aliax.net]
Sent: Dienstag, 12. August 2014 11:34
To: Schwarz, Albrecht (Albrecht)
Cc: Justin Uberti; rtcweb@ietf.org Subject: Re: [rtcweb] How to reset DTLS over TCP if the connection is close= d

2014-08-12 11:00 GMT+02:00 Schwarz, Albrecht (Albrecht)
<albrecht.schwarz= @alcatel-lucent.com>:
> if finally TCP would be selected as L4 protocol (instead of UDP), then=
> TLS would be used instead of DTLS, right?

No. It is STUN, DTLS and SRTP/SRTCP over TCP.

RFC 6544 (ICE TCP) allows both DTLS and TLS:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0App =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----------+----------+ =C2=A0 = =C2=A0 +----------+----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 STUN =C2=A0 | =C2=A0(D)T= LS =C2=A0| =C2=A0 =C2=A0 | =C2=A0 STUN =C2=A0 | =C2=A0 =C2=A0App =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----------+----------+ =C2=A0 = =C2=A0 +----------+----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0RFC 4571 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0RFC 4571 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------------------+ =C2=A0 = =C2=A0 +---------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP= =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 = TCP =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------------------+ =C2=A0 = =C2=A0 +---------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 IP = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 IP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +---------------------+ =C2=A0 = =C2=A0 +---------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: ICE TCP Stack wi= th and without (D)TLS

but AFAIK WebRTC just uses DTLS and not TLS (note that we are not talking a= bout TURN in which TLS is supported).




--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>


From: Schwarz, Albrecht (Albrecht)
Sent: Dienstag, 12. August 2014 11:00
To: 'Justin Uberti'
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] How to reset DTLS over TCP if the connection is close= d

Justin,
question for clarification:

if finally TCP would be selected as L4 protocol (instead of UDP), then TLS = would be used instead of DTLS, right?
(If yes, then discussion would be about =E2=80=9Creset TLS over TCP =E2=80= =A6=E2=80=9D in understanding).

-Albrecht


--bcaec548a399907fa8050088ebd1-- From nobody Wed Aug 13 18:46:46 2014 Return-Path: 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 62FD21A06EB; Wed, 13 Aug 2014 18:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5IohRa9WqNKT; Wed, 13 Aug 2014 18:46:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B14C31A06E2; Wed, 13 Aug 2014 18:46:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140814014637.22055.60463.idtracker@ietfa.amsl.com> Date: Wed, 13 Aug 2014 18:46:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eupb0zMA19HtIKxoNlBxWCDxP6o Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-06.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 01:46:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : STUN Usage for Consent Freshness Authors : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Martin Thomson Filename : draft-ietf-rtcweb-stun-consent-freshness-06.txt Pages : 9 Date : 2014-08-13 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new STUN usage. This same mechanism can also determine connection loss ("liveness") with a remote peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 14 01:19:04 2014 Return-Path: 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 0FD1D1A0921 for ; Thu, 14 Aug 2014 01:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 dfhOoWXxRgtG for ; Thu, 14 Aug 2014 01:18:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA31A095D for ; Thu, 14 Aug 2014 01:18:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 095747C3D6F for ; Thu, 14 Aug 2014 10:18:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYWT1PICw5kc for ; Thu, 14 Aug 2014 10:18:46 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:480e:b098:4917:7a16]) by mork.alvestrand.no (Postfix) with ESMTPSA id 31E847C3C47 for ; Thu, 14 Aug 2014 10:18:46 +0200 (CEST) Message-ID: <53EC70E5.7070105@alvestrand.no> Date: Thu, 14 Aug 2014 10:18:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JBoeIfeMyilJT6RBRZHfmf8_7fc Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 08:19:01 -0000 On 08/13/2014 09:07 PM, Martin Thomson wrote: > On 13 August 2014 09:10, Ted Hardie wrote: >> My concern here is that access to the ability to set different DSCP markings >> on a per packet basis for a flow may not be available generally on all >> platforms. Even if we want to make a forward looking push toward that >> ability, naming what we think is the appropriate alternative may make sense. > Yeah, requiring per-packet DSCP seems overly enthusiastic. I know it's possible to do this on Linux (for UDP, of course). I think it still requires an extra sysctl before sending each packet, which is reasonably high overhead if your app is sysctl-limited. But I don't know of any case where you would be allowed to set per-flow DSCP markings and would not be allowed to set per-packet DSCP markings; all the reasons to not do marking seem to be reasons to not do marking. I'd like to know if the APIs exist on other platforms (whether they're overridden by default policy or not). The two alternatives if we don't get per-packet setting are: - Deaggregate, so that per-port-flow classifiers can do their thing - Don't ask the network to differentiate, keep precedence of flow a sender-stack thing only I don't know which is the more (or less) distasteful / useful of those two paths. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Aug 14 08:10:16 2014 Return-Path: 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 77B721A6F1C for ; Thu, 14 Aug 2014 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 BNQPlAB6A5b2 for ; Thu, 14 Aug 2014 08:10:04 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CF31A6F24 for ; Thu, 14 Aug 2014 08:10:04 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so5281544igd.8 for ; Thu, 14 Aug 2014 08:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=c7MQiJvVCDKjFiG5xM3nwQwDQn4dy35W+p4fAQsU8u0=; b=etdrFJy6U+LplS935lBd/u6xjjoATwHDjnrouX6Hj763lPvdkoMqfcj8ucPwwzam4a tKJ6ae2x5zzK+cIz2E7OR9/bY1un7nOrk6e/gBXnyzRpBGbSOY63E+RdwpP8QcRp1gnx pa2jEhLw+LFqQ8T5rSaA2omz2ntdjByOlNB0J+TXpYs6gtnDh+OtWkB1KFEDFDg+v03b rzgxmUMp/wwkcUogIWCJZw/O4VomIVUXkIwywq6Li45m+EM6ZQYOg69NiOPCZipF2AUm J85LsDpg8NqeO5r2X67VCYxsAiWyffNlQxbd8lYoBYl5Y/Hjl+DFl8d5ydhOXdBvrrSH DzwQ== MIME-Version: 1.0 X-Received: by 10.42.47.140 with SMTP id o12mr15335220icf.4.1408029003814; Thu, 14 Aug 2014 08:10:03 -0700 (PDT) Received: by 10.43.154.80 with HTTP; Thu, 14 Aug 2014 08:10:03 -0700 (PDT) Date: Thu, 14 Aug 2014 08:10:03 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary=90e6ba6149aa9b21aa0500984c9d Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DkWO5RSS1bzQsZMQ_qXpw16koDQ Subject: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:10:09 -0000 --90e6ba6149aa9b21aa0500984c9d Content-Type: text/plain; charset=UTF-8 This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness (available at http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/). Please review the document and send comments to the list by September 10, 2014. thanks, Ted Hardie --90e6ba6149aa9b21aa0500984c9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness (available at= http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-= freshness/).=C2=A0 Please review the document and send comments to the = list by September 10, 2014.

tha= nks,

Ted Hardie
--90e6ba6149aa9b21aa0500984c9d-- From nobody Thu Aug 14 08:20:23 2014 Return-Path: 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 EB61D1A06FB for ; Thu, 14 Aug 2014 08:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.169 X-Spam-Level: X-Spam-Status: No, score=-115.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 Nba8G7DHMRZ6 for ; Thu, 14 Aug 2014 08:20:15 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883E81A04A1 for ; Thu, 14 Aug 2014 08:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=144; q=dns/txt; s=iport; t=1408029615; x=1409239215; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=RwU43cvf1iJbNYcvLALFUAU6AJNBmvjuqOLkRWlt/P4=; b=Ujpu7KjntRp82gtkl8XqmDl3ONY2ItXr+7lUXmQimm3f1rOHmdTcSKXD oH5OrVgX1cEiNoSBxhjKPcx7k4SB52QW++Li0IOguw4/dcCJh6cSExjrC PtTCS7FIATGOqZdjT6rDH/jGOzwIjVMYZKoqdfS7IJfGBMZrQHROhoT0P I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYGAMrS7FOtJA2N/2dsb2JhbABZgmojgS6NMsgEgRcWd4QKeRIBgQAnBA6IRwHFfxePTIM2gR0FkR2LHJR+g1yCNIEHAQEB X-IronPort-AV: E=Sophos;i="5.01,863,1400025600"; d="scan'208";a="69263193" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP; 14 Aug 2014 15:20:13 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7EFKDtR014571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 15:20:13 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 10:20:12 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Minutes for RTCWeb IETF90 meetings Thread-Index: AQHPt9M+cWd07aBSTEKG+HjDKp83cw== Date: Thu, 14 Aug 2014 15:20:12 +0000 Message-ID: <9E21900A-6AFA-4B75-8510-BA02413F92BF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.96] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pq_RF954JJXeWEZXk2rB4MSzaAg Subject: [rtcweb] Minutes for RTCWeb IETF90 meetings X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 15:20:19 -0000 They have now been uploaded to IETF site. If any additional problems are fo= und, we can still correct them.=20 Thanks, the chairs =85 = From nobody Thu Aug 14 11:18:05 2014 Return-Path: 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 920C61A6FCC for ; Thu, 14 Aug 2014 11:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.942 X-Spam-Level: * X-Spam-Status: No, score=1.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 dqYybRdpGtVK for ; Thu, 14 Aug 2014 11:18:02 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9A11A6FC9 for ; Thu, 14 Aug 2014 11:17:57 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so1876058vcb.13 for ; Thu, 14 Aug 2014 11:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gF61RgRfUd1esIeCdWKiIdTQYSvq4mIIUDaZNrRu2P8=; b=KAl1LMVlYEe2tHuGYazBhCc79i69RdnkQ5wMfmh1O8Ac1jmJlntY2L5z4mtUKGp0En 7qVgWlSWBVVTbfcyzAoIcpHVICcaCD6vN7+hnyUy2P3SJPr65mIMYH2n5vjNEeHqHO8n pwIpBwr10/4Fg+wLQEjcVZIQlDpr9hmByyiw5bws5VfGus2DyOXbtNvTBIdZVB8ud2UH Gaq7ktMbdhZoNjck+kE9DlAWC3c4cWunXAeE1PHgyoeER+vLQZ4oppV/Bvvb60hYig4r 6icSyaA3NXnIw45s62FkCIB1ASPI29mVPg798fCKBwUEzssTuk2CfngGGgKE2z3PBpgX 1yAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gF61RgRfUd1esIeCdWKiIdTQYSvq4mIIUDaZNrRu2P8=; b=GBcaKEdnmn76YZC8S+3NLqPtIwiGVdem5wfyh5ykNTpa5ldhwOQTl7OHMflJcv4AAg 9jMsIRPmcPvnuTuLQ0kbHxY1KDm8Hq7hTUUshATaHSR2Ya0xk162bAfNdnA/JzzxiaNj G+Ed4TjkLQNqzcH7ut8pSLouS6kZ7e3NKKVzPGc8cG3xIvhkfEaI1bLt4vbcfsJBvm8D PkaRO7NdPZEdudS/bqeKeF+H7xw9+jruEZcLZ0aUJuf9NDHt5hO8S/v+g9AcYFwazIxm uegj8TqN5K8BksipqcfClEzjdg/Dtg8uOVxRPnTT71g1vZWQC3eIhJrsFpM6zq7+4/MV 2IUA== X-Gm-Message-State: ALoCoQmTOKA2cFf+uXXWa9lVu7cGS6+Cxnt5Qi1urdLh/JQBk8++OiIkwlIEFS3MXkboHnl5jXYU X-Received: by 10.52.128.8 with SMTP id nk8mr3420845vdb.48.1408040276830; Thu, 14 Aug 2014 11:17:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Thu, 14 Aug 2014 11:17:36 -0700 (PDT) In-Reply-To: <53EC70E5.7070105@alvestrand.no> References: <53EC70E5.7070105@alvestrand.no> From: Justin Uberti Date: Thu, 14 Aug 2014 11:17:36 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec51f8f9d87d88e05009aec44 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pLW7471502oQHtTGtyr4QNEZ5x0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 18:18:04 -0000 --bcaec51f8f9d87d88e05009aec44 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 14, 2014 at 1:18 AM, Harald Alvestrand wrote: > On 08/13/2014 09:07 PM, Martin Thomson wrote: > >> On 13 August 2014 09:10, Ted Hardie wrote: >> >>> My concern here is that access to the ability to set different DSCP >>> markings >>> on a per packet basis for a flow may not be available generally on all >>> platforms. Even if we want to make a forward looking push toward that >>> ability, naming what we think is the appropriate alternative may make >>> sense. >>> >> Yeah, requiring per-packet DSCP seems overly enthusiastic. >> > > I know it's possible to do this on Linux (for UDP, of course). I think it > still requires an extra sysctl before sending each packet, which is > reasonably high overhead if your app is sysctl-limited. But I don't know of > any case where you would be allowed to set per-flow DSCP markings and would > not be allowed to set per-packet DSCP markings; all the reasons to not do > marking seem to be reasons to not do marking. > > I'd like to know if the APIs exist on other platforms (whether they're > overridden by default policy or not). > > The two alternatives if we don't get per-packet setting are: > > - Deaggregate, so that per-port-flow classifiers can do their thing > - Don't ask the network to differentiate, keep precedence of flow a > sender-stack thing only > > I don't know which is the more (or less) distasteful / useful of those two > paths. The other option, which I believe works on MacOS, is to setsockopt before each sendto: setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp)); --bcaec51f8f9d87d88e05009aec44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 14, 2014 at 1:18 AM, Harald Alvestrand &l= t;harald@alvestra= nd.no> wrote:
On 08/13/2014 09:07 PM, Martin Thomson wro= te:
On 13 August 2014 09:10, Ted Hardie <ted.ietf@gmail.com> wrote:
My concern here is that access to the ability to set different DSCP marking= s
on a per packet basis for a flow may not be available generally on all
platforms.=C2=A0 Even if we want to make a forward looking push toward that=
ability, naming what we think is the appropriate alternative may make sense= .
Yeah, requiring per-packet DSCP seems overly enthusiastic.

I know it's possible to do this on Linux (for UDP, of course). I think = it still requires an extra sysctl before sending each packet, which is reas= onably high overhead if your app is sysctl-limited. But I don't know of= any case where you would be allowed to set per-flow DSCP markings and woul= d not be allowed to set per-packet DSCP markings; all the reasons to not do= marking seem to be reasons to not do marking.

I'd like to know if the APIs exist on other platforms (whether they'= ;re overridden by default policy or not).

The two alternatives if we don't get per-packet setting are:

- Deaggregate, so that per-port-flow classifiers can do their thing
- Don't ask the network to differentiate, keep precedence of flow a sen= der-stack thing only

I don't know which is the more (or less) distasteful / useful of those = two paths.

The other option, which I believ= e works on MacOS, is to setsockopt before each sendto:
=C2=A0 =C2= =A0=C2=A0
=C2=A0 =C2=A0 setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeo= f(dscp));=C2=A0
--bcaec51f8f9d87d88e05009aec44-- From nobody Thu Aug 14 13:24:45 2014 Return-Path: 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 904C11A874D for ; Thu, 14 Aug 2014 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.988 X-Spam-Level: * X-Spam-Status: No, score=1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_STOCK2=3.988, SPF_PASS=-0.001] 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 4N-jsIUOYlA1 for ; Thu, 14 Aug 2014 13:24:44 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F54A1A8747 for ; Thu, 14 Aug 2014 13:24:37 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so1575227wes.4 for ; Thu, 14 Aug 2014 13:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ExWic3DN0O68QkDK7zb5FUOXGMw3LR48jdTHkPiPunA=; b=n4epIWWaHbXgo9I7ifEaqWnsqGM2Iyzb1PMsakOMOU36GxEIgrG3vKGrPTVtVH5oO+ 29lIlkrp2j4l86JHRCFjGcz3FlH/eu/ybXx5s+VJiYWKxQEwbjxV07KF4iJpES342UQ8 X/NgEWGnbrPr3ho29flA8+lNDsma7a/gLyXfEmzNSb/sp7YgKkFlXDRcbs9qdoFgAK9x AY33Czp57Xx1iCOWFXPI8vEtBIK4OqsmgL9oqw813Ed9E5zZGL55aRMtwRSDRbqyNpz2 Pesq/22Qie7cOwKx1uLAUEIEsJtydof9LwngBJSv8ad3WLVjhpCNkOLHWSONloU6ZGtk Xp5w== MIME-Version: 1.0 X-Received: by 10.180.103.74 with SMTP id fu10mr15421060wib.47.1408047876132; Thu, 14 Aug 2014 13:24:36 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 14 Aug 2014 13:24:36 -0700 (PDT) In-Reply-To: References: <53EC70E5.7070105@alvestrand.no> Date: Thu, 14 Aug 2014 13:24:36 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KVrbFOgjDlJ_keYAmed-YlaZNR4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 20:24:44 -0000 On 14 August 2014 11:17, Justin Uberti wrote: > The other option, which I believe works on MacOS, is to setsockopt before > each sendto: > > setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp)); That is a solution to the problem, not a fallback position :) I don't mind whether we require the fallback to be no markings, or we specify a whole-flow marking that can be used (which is functionally the same has having no markings, though much harder to define consistent behaviour as things change), or whether we require disaggregation. From nobody Thu Aug 14 13:45:50 2014 Return-Path: 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 AF8A21A8782 for ; Thu, 14 Aug 2014 13:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.01 X-Spam-Level: ** X-Spam-Status: No, score=2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 FXdBz4I8DdlB for ; Thu, 14 Aug 2014 13:45:40 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581E61A8781 for ; Thu, 14 Aug 2014 13:45:40 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so1577884wes.23 for ; Thu, 14 Aug 2014 13:45:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pWw57oR8jS4WtDVzx+WRNUdsO3uEh6QsnRZxZsktwLI=; b=OgpCYYthvSH1Z8UxGp1q6KqEDfhgwoGYq+zlQk17VwI7mH1nredTwy5hEtG7EZNQv7 rcI04sx172vaAVPGAa9Wxc0OA4g/L3K916/K/jdd49ixIL3DfUeh4yDX1+De28xAhaSL de/JED26woEnhkrL4lq38TCl8PyBXVD/wdFZ/v8OLwW1AOreOh7k+m7WYnm11WUOvcm+ 4aGoun/rAEr1i0bUmE/5NuXKdpt8jR/g0X/Oaas0JR3xC58ysp1m43SSnG6SKgpGvyLd kUuAdYPo06JuMc0x8cZQR7nj1HbPBEDw0Hn4J2WLtt04vgMEpmEp5RU03cUu8KwIfuJl 4zXw== X-Gm-Message-State: ALoCoQleN8ALeJ2IYc0cM4/k86MEn67dUl76jHk7S7g7fffs0M5M59VYSi4L+6H6JTvFBhF1iYi5 X-Received: by 10.180.75.203 with SMTP id e11mr6485013wiw.28.1408049138886; Thu, 14 Aug 2014 13:45:38 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx.google.com with ESMTPSA id kw1sm13714141wjb.19.2014.08.14.13.45.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 13:45:37 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so26419wib.16 for ; Thu, 14 Aug 2014 13:45:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.36.238 with SMTP id t14mr15861857wij.38.1408049137611; Thu, 14 Aug 2014 13:45:37 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Thu, 14 Aug 2014 13:45:37 -0700 (PDT) In-Reply-To: References: <53EC70E5.7070105@alvestrand.no> Date: Thu, 14 Aug 2014 16:45:37 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8f647859ac7c1d05009cfc6e Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7MREDGi4SWm2EwT3q5BYD9FJeZE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 20:45:43 -0000 --e89a8f647859ac7c1d05009cfc6e Content-Type: text/plain; charset=UTF-8 On Thu, Aug 14, 2014 at 2:17 PM, Justin Uberti wrote: > > > On Thu, Aug 14, 2014 at 1:18 AM, Harald Alvestrand > wrote: > >> On 08/13/2014 09:07 PM, Martin Thomson wrote: >> >>> On 13 August 2014 09:10, Ted Hardie wrote: >>> >>>> My concern here is that access to the ability to set different DSCP >>>> markings >>>> on a per packet basis for a flow may not be available generally on all >>>> platforms. Even if we want to make a forward looking push toward that >>>> ability, naming what we think is the appropriate alternative may make >>>> sense. >>>> >>> Yeah, requiring per-packet DSCP seems overly enthusiastic. >>> >> >> I know it's possible to do this on Linux (for UDP, of course). I think it >> still requires an extra sysctl before sending each packet, which is >> reasonably high overhead if your app is sysctl-limited. But I don't know of >> any case where you would be allowed to set per-flow DSCP markings and would >> not be allowed to set per-packet DSCP markings; all the reasons to not do >> marking seem to be reasons to not do marking. >> >> I'd like to know if the APIs exist on other platforms (whether they're >> overridden by default policy or not). >> >> The two alternatives if we don't get per-packet setting are: >> >> - Deaggregate, so that per-port-flow classifiers can do their thing >> - Don't ask the network to differentiate, keep precedence of flow a >> sender-stack thing only >> >> I don't know which is the more (or less) distasteful / useful of those >> two paths. > > > The other option, which I believe works on MacOS, is to setsockopt before > each sendto: > > setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp)); > > And on windows you can do the same by calling the following before sending each UDP packet: setsockopt(d_socket, IPPROTO_IP, IP_TOS, (char*)&tos, sizeof(tos)); I believe this will work on any BSD based network stack. The problem with this approach is that it requires two system calls for each sent packet. It also has some implications on threading, since without setting TOS you can send data via the same socket without locking. Now, because each send is two system calls, lock will be required to ensure right TOS value, so the overhead can be even higher. There was a discussion about updating Linux kernel to add support for setting IP_TOS via the control structure in sendmsg, but I do not think this patch was ever accepted. It was also recommended that ICE packets are sent with the same TOS as main data. Technically, you can end up with the situation where some TOS values go through the network and some do not. If data is sent with a different TOS value then ICE, ICE connectivity can succeed but sending the data will fail. This means an ICE connectivity check for each TOS value, which might produce different ICE candidates for different TOS values. Taking all of this into account I would suggest that a single TOS value should be used for each flow and data with different TOS values should be dis-aggregated across different flows. _____________ Roman Shpount --e89a8f647859ac7c1d05009cfc6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 14, 2014 at 2:17 PM, Justin Uberti <juberti@google.com> wrote:


On Thu, Aug 14, 2014 at 1:18 AM, Harald Alvestrand <harald@alvestrand.n= o> wrote:
On 08/13/2014 09:07 PM, Martin Thomson wrote:
On 13 August 2014 09:10, Ted Hardie <ted.ietf@gmail.com> wrote:
My concern here is that access to the ability to set different DSCP marking= s
on a per packet basis for a flow may not be available generally on all
platforms.=C2=A0 Even if we want to make a forward looking push toward that=
ability, naming what we think is the appropriate alternative may make sense= .
Yeah, requiring per-packet DSCP seems overly enthusiastic.

I know it's possible to do this on Linux (for UDP, of course). I think = it still requires an extra sysctl before sending each packet, which is reas= onably high overhead if your app is sysctl-limited. But I don't know of= any case where you would be allowed to set per-flow DSCP markings and woul= d not be allowed to set per-packet DSCP markings; all the reasons to not do= marking seem to be reasons to not do marking.

I'd like to know if the APIs exist on other platforms (whether they'= ;re overridden by default policy or not).

The two alternatives if we don't get per-packet setting are:

- Deaggregate, so that per-port-flow classifiers can do their thing
- Don't ask the network to differentiate, keep precedence of flow a sen= der-stack thing only

I don't know which is the more (or less) distasteful / useful of those = two paths.

The other option, which I believ= e works on MacOS, is to setsockopt before each sendto:
=C2=A0 =C2= =A0=C2=A0
=C2=A0 =C2=A0 setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeo= f(dscp));=C2=A0


And on windows you can do the same by = calling the following before sending each UDP packet:
setsockopt(d_soc= ket, IPPROTO_IP, IP_TOS, (char*)&tos, sizeof(tos));

I believe this will work on any BSD ba= sed network stack.

The problem with this approach is that it requires two system = calls for each sent packet. It also has some implications on threading, sin= ce without setting TOS you can send data via the same socket without lockin= g. Now, because each send is two system calls, lock will be required to ens= ure right TOS value, so the overhead can be even higher. There was a discus= sion about updating Linux kernel to add support for setting IP_TOS via the = control structure in sendmsg, but I do not think this patch was ever accept= ed.

It was also recommended that ICE packets are sent with = the same TOS as main data. Technically, you can end up with the situation w= here some TOS values go through the network and some do not. If data is sen= t with a different TOS value then ICE, ICE connectivity can succeed but sen= ding the data will fail. This means an ICE connectivity check for each TOS = value, which might produce different ICE candidates for different TOS value= s.

Taking all of this into account I would suggest that a = single TOS value should be used for each flow and data with different TOS v= alues should be dis-aggregated across different flows.
__________= ___
Roman Shpount

=C2=A0
--e89a8f647859ac7c1d05009cfc6e-- From nobody Thu Aug 14 14:52:31 2014 Return-Path: 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 288261A88B0 for ; Thu, 14 Aug 2014 14:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001] 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 LXmw-ikgKquZ for ; Thu, 14 Aug 2014 14:52:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4963E1A88B7 for ; Thu, 14 Aug 2014 14:52:28 -0700 (PDT) Received: from [192.168.1.200] (p54819622.dip0.t-ipconnect.de [84.129.150.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7A35E1C104E67; Thu, 14 Aug 2014 23:52:24 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Thu, 14 Aug 2014 23:52:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> References: <53EC70E5.7070105@alvestrand.no> To: Roman Shpount X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9hHk9YnOaYhP8zFPKA7JfpgM7Y4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 21:52:30 -0000 On 14 Aug 2014, at 22:45, Roman Shpount wrote: > On Thu, Aug 14, 2014 at 2:17 PM, Justin Uberti = wrote: >=20 >=20 > On Thu, Aug 14, 2014 at 1:18 AM, Harald Alvestrand = wrote: > On 08/13/2014 09:07 PM, Martin Thomson wrote: > On 13 August 2014 09:10, Ted Hardie wrote: > My concern here is that access to the ability to set different DSCP = markings > on a per packet basis for a flow may not be available generally on all > platforms. Even if we want to make a forward looking push toward that > ability, naming what we think is the appropriate alternative may make = sense. > Yeah, requiring per-packet DSCP seems overly enthusiastic. >=20 > I know it's possible to do this on Linux (for UDP, of course). I think = it still requires an extra sysctl before sending each packet, which is = reasonably high overhead if your app is sysctl-limited. But I don't know = of any case where you would be allowed to set per-flow DSCP markings and = would not be allowed to set per-packet DSCP markings; all the reasons to = not do marking seem to be reasons to not do marking. >=20 > I'd like to know if the APIs exist on other platforms (whether they're = overridden by default policy or not). >=20 > The two alternatives if we don't get per-packet setting are: >=20 > - Deaggregate, so that per-port-flow classifiers can do their thing > - Don't ask the network to differentiate, keep precedence of flow a = sender-stack thing only >=20 > I don't know which is the more (or less) distasteful / useful of those = two paths. >=20 > The other option, which I believe works on MacOS, is to setsockopt = before each sendto: > =20 > setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp));=20 >=20 >=20 > And on windows you can do the same by calling the following before = sending each UDP packet: > setsockopt(d_socket, IPPROTO_IP, IP_TOS, (char*)&tos, sizeof(tos)); >=20 > I believe this will work on any BSD based network stack. >=20 > The problem with this approach is that it requires two system calls = for each sent packet. It also has some implications on threading, since = without setting TOS you can send data via the same socket without = locking. Now, because each send is two system calls, lock will be = required to ensure right TOS value, so the overhead can be even higher. = There was a discussion about updating Linux kernel to add support for = setting IP_TOS via the control structure in sendmsg, but I do not think = this patch was ever accepted. FreeBSD supports using a cmsg. So there is only one system call: = sendmsg(). Best regards Michael >=20 > It was also recommended that ICE packets are sent with the same TOS as = main data. Technically, you can end up with the situation where some TOS = values go through the network and some do not. If data is sent with a = different TOS value then ICE, ICE connectivity can succeed but sending = the data will fail. This means an ICE connectivity check for each TOS = value, which might produce different ICE candidates for different TOS = values. >=20 > Taking all of this into account I would suggest that a single TOS = value should be used for each flow and data with different TOS values = should be dis-aggregated across different flows. > _____________ > Roman Shpount >=20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Aug 14 15:15:16 2014 Return-Path: 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 3AAE11A88E7 for ; Thu, 14 Aug 2014 15:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.01 X-Spam-Level: ** X-Spam-Status: No, score=2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 DrKr99N6lBht for ; Thu, 14 Aug 2014 15:15:10 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBD91A88E3 for ; Thu, 14 Aug 2014 15:15:10 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so1660178wes.28 for ; Thu, 14 Aug 2014 15:15:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d5Rof3iOmldcDYUurJIUVBo1PKCtASklniNHLEjDMW4=; b=bGFwQEaL7VLU5zOt6kaAbeUXVf0l4bCYfBea+Rnm8Ot1OeVl3kcbcnjSw3a0kgv67j ZUngkVqfUTIob50fyDcy1Tv1ySkJo4eDsepEZeGWG7NEuw8MJlapOsBJHTeFS8znQdZC j+mT8jrpUJZNzeLdwokckyKjaFBp1oTgFbHovm6RsG6Z5sdC9beXfCHFwXAXBczkhz5J KeDLQn5VDqv09L72WRtvhvocekGlONAztaah3wn3AJKZn9p88smm3tP92VvBnGw+brr1 1urA1ogXaiFBSQ7FMTg8zyC1MAPvthAdE4cD2AkgGLfk14ng0FqCzHxDESAQNWeQ5KhC DSCA== X-Gm-Message-State: ALoCoQkmkRLcaflkrcS/ly7PuohwwJ41JfZXCs02p160ZzAm1cAHvGuGBR7tOUsGZEHO6LeWo516 X-Received: by 10.195.13.79 with SMTP id ew15mr15160596wjd.19.1408054508681; Thu, 14 Aug 2014 15:15:08 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by mx.google.com with ESMTPSA id dc3sm14122670wjc.27.2014.08.14.15.15.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 15:15:07 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so1706747wes.9 for ; Thu, 14 Aug 2014 15:15:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.20.230 with SMTP id q6mr16166264wje.43.1408054507338; Thu, 14 Aug 2014 15:15:07 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Thu, 14 Aug 2014 15:15:07 -0700 (PDT) In-Reply-To: <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> References: <53EC70E5.7070105@alvestrand.no> <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> Date: Thu, 14 Aug 2014 18:15:07 -0400 Message-ID: From: Roman Shpount To: Michael Tuexen Content-Type: multipart/alternative; boundary=047d7b5d971bbc024505009e3c9a Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/61A8rbKfwZLkCvOWSW5f28Wpt1w Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:15:12 -0000 --047d7b5d971bbc024505009e3c9a Content-Type: text/plain; charset=UTF-8 _____________ Roman Shpount On Thu, Aug 14, 2014 at 5:52 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > On 14 Aug 2014, at 22:45, Roman Shpount wrote: > > > On Thu, Aug 14, 2014 at 2:17 PM, Justin Uberti > wrote: > > > > > > On Thu, Aug 14, 2014 at 1:18 AM, Harald Alvestrand > wrote: > > On 08/13/2014 09:07 PM, Martin Thomson wrote: > > On 13 August 2014 09:10, Ted Hardie wrote: > > My concern here is that access to the ability to set different DSCP > markings > > on a per packet basis for a flow may not be available generally on all > > platforms. Even if we want to make a forward looking push toward that > > ability, naming what we think is the appropriate alternative may make > sense. > > Yeah, requiring per-packet DSCP seems overly enthusiastic. > > > > I know it's possible to do this on Linux (for UDP, of course). I think > it still requires an extra sysctl before sending each packet, which is > reasonably high overhead if your app is sysctl-limited. But I don't know of > any case where you would be allowed to set per-flow DSCP markings and would > not be allowed to set per-packet DSCP markings; all the reasons to not do > marking seem to be reasons to not do marking. > > > > I'd like to know if the APIs exist on other platforms (whether they're > overridden by default policy or not). > > > > The two alternatives if we don't get per-packet setting are: > > > > - Deaggregate, so that per-port-flow classifiers can do their thing > > - Don't ask the network to differentiate, keep precedence of flow a > sender-stack thing only > > > > I don't know which is the more (or less) distasteful / useful of those > two paths. > > > > The other option, which I believe works on MacOS, is to setsockopt > before each sendto: > > > > setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp)); > > > > > > And on windows you can do the same by calling the following before > sending each UDP packet: > > setsockopt(d_socket, IPPROTO_IP, IP_TOS, (char*)&tos, sizeof(tos)); > > > > I believe this will work on any BSD based network stack. > > > > The problem with this approach is that it requires two system calls for > each sent packet. It also has some implications on threading, since without > setting TOS you can send data via the same socket without locking. Now, > because each send is two system calls, lock will be required to ensure > right TOS value, so the overhead can be even higher. There was a discussion > about updating Linux kernel to add support for setting IP_TOS via the > control structure in sendmsg, but I do not think this patch was ever > accepted. > FreeBSD supports using a cmsg. So there is only one system call: sendmsg(). > > Best regards > Michael > > > > It was also recommended that ICE packets are sent with the same TOS as > main data. Technically, you can end up with the situation where some TOS > values go through the network and some do not. If data is sent with a > different TOS value then ICE, ICE connectivity can succeed but sending the > data will fail. This means an ICE connectivity check for each TOS value, > which might produce different ICE candidates for different TOS values. > > > > Taking all of this into account I would suggest that a single TOS value > should be used for each flow and data with different TOS values should be > dis-aggregated across different flows. > > _____________ > > Roman Shpount > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --047d7b5d971bbc024505009e3c9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


_____________
Roman Shpount


On Thu, Aug 14, 2014 at 5:52 PM, Michael= Tuexen <Michael.Tuexen@lurchi.franken.de> wr= ote:
On 14 Aug 2014, at 22:45, Ro= man Shpount <roman@telurix.com&= gt; wrote:

> On Thu, Aug 14, 2014 at 2:17 PM, Justin Uberti <juberti@google.com> wrote:
>
>
> On Thu, Aug 14, 2014 at 1:18 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 08/13/2014 09:07 PM, Martin Thomson wrote:
> On 13 August 2014 09:10, Ted Hardie <ted.ietf@gmail.com> wrote:
> My concern here is that access to the ability to set different DSCP ma= rkings
> on a per packet basis for a flow may not be available generally on all=
> platforms. =C2=A0Even if we want to make a forward looking push toward= that
> ability, naming what we think is the appropriate alternative may make = sense.
> Yeah, requiring per-packet DSCP seems overly enthusiastic.
>
> I know it's possible to do this on Linux (for UDP, of course). I t= hink it still requires an extra sysctl before sending each packet, which is= reasonably high overhead if your app is sysctl-limited. But I don't kn= ow of any case where you would be allowed to set per-flow DSCP markings and= would not be allowed to set per-packet DSCP markings; all the reasons to n= ot do marking seem to be reasons to not do marking.
>
> I'd like to know if the APIs exist on other platforms (whether the= y're overridden by default policy or not).
>
> The two alternatives if we don't get per-packet setting are:
>
> - Deaggregate, so that per-port-flow classifiers can do their thing > - Don't ask the network to differentiate, keep precedence of flow = a sender-stack thing only
>
> I don't know which is the more (or less) distasteful / useful of t= hose two paths.
>
> The other option, which I believe works on MacOS, is to setsockopt bef= ore each sendto:
>
> =C2=A0 =C2=A0 setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeo= f(dscp));
>
>
> And on windows you can do the same by calling the following before sen= ding each UDP packet:
> setsockopt(d_socket, IPPROTO_IP, IP_TOS, (char*)&tos, sizeof(tos))= ;
>
> I believe this will work on any BSD based network stack.
>
> The problem with this approach is that it requires two system calls fo= r each sent packet. It also has some implications on threading, since witho= ut setting TOS you can send data via the same socket without locking. Now, = because each send is two system calls, lock will be required to ensure righ= t TOS value, so the overhead can be even higher. There was a discussion abo= ut updating Linux kernel to add support for setting IP_TOS via the control = structure in sendmsg, but I do not think this patch was ever accepted.
FreeBSD supports using a cmsg. So there is only one system call: send= msg().

Best regards
Michael
>
> It was also recommended that ICE packets are sent with the same TOS as= main data. Technically, you can end up with the situation where some TOS v= alues go through the network and some do not. If data is sent with a differ= ent TOS value then ICE, ICE connectivity can succeed but sending the data w= ill fail. This means an ICE connectivity check for each TOS value, which mi= ght produce different ICE candidates for different TOS values.
>
> Taking all of this into account I would suggest that a single TOS valu= e should be used for each flow and data with different TOS values should be= dis-aggregated across different flows.
> _____________
> Roman Shpount
>
>
> ________________________= _______________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b5d971bbc024505009e3c9a-- From nobody Thu Aug 14 15:16:48 2014 Return-Path: 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 C28D21A88EB for ; Thu, 14 Aug 2014 15:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 cG8gvy0IDZFk for ; Thu, 14 Aug 2014 15:16:46 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A211A88E9 for ; Thu, 14 Aug 2014 15:16:46 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so1668162wgh.23 for ; Thu, 14 Aug 2014 15:16:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5IJro79pX9RGa6bUUWLiJ6css5UWUxhigFTqjs0fPTI=; b=TXu01nMRHZDs9ZHLkydZS3VCx3jvDQOhsjr7laYtYnXZdd2KuPwZbme1JobguL5pIH 5KPxWoc3+N1TLxxbGrLn1LFNfJv9w3o+JtAUUCRIvgnvEjris2qua4fN7ZR5yYEthAks hcjxFsgD7lUJMXGWDuuRcEdUCiEM+in22XFO/84Fr3J39W1fWhjDFW7vFHTVL8tqmSdj ujJbH2dQskzy9tWZmWxaf7oYDGRuaSEPjwa6DCEJLb6g7ArtGJMgW5iTHj8dHLgnjf7c knc1c5P/IC/Gou7lBvIVZTG+S5xHds01LIwvgWogUFVP1rC+rECrqufFzT+29iKbSJgW 6z6w== X-Gm-Message-State: ALoCoQmThYREjJTUBBPaIMFPasq2D4DAVsJmD0oCergZQMQfuVdNQ8PHVZLMuWX4syfLjVfNxft1 X-Received: by 10.195.11.200 with SMTP id ek8mr16153768wjd.85.1408054605135; Thu, 14 Aug 2014 15:16:45 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by mx.google.com with ESMTPSA id c8sm14149534wjw.6.2014.08.14.15.16.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 15:16:44 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so341874wiv.0 for ; Thu, 14 Aug 2014 15:16:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.90.4 with SMTP id bs4mr16331135wjb.71.1408054604110; Thu, 14 Aug 2014 15:16:44 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Thu, 14 Aug 2014 15:16:44 -0700 (PDT) In-Reply-To: <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> References: <53EC70E5.7070105@alvestrand.no> <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> Date: Thu, 14 Aug 2014 18:16:44 -0400 Message-ID: From: Roman Shpount To: Michael Tuexen Content-Type: multipart/alternative; boundary=047d7bfcfc1880a0de05009e422f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/T6F4o2Djy0kR9U4No_XeNt6qVvI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:16:48 -0000 --047d7bfcfc1880a0de05009e422f Content-Type: text/plain; charset=UTF-8 On Thu, Aug 14, 2014 at 5:52 PM, Michael Tuexen < Michael.Tuexen@lurchi.franken.de> wrote: > FreeBSD supports using a cmsg. So there is only one system call: sendmsg(). > > Do you know if setting TOS via cmsg in sendmsg works for OSX as well? Thank You, _____________ Roman Shpount --047d7bfcfc1880a0de05009e422f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 14, 2014 at 5:= 52 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de= > wrote:
FreeBSD s= upports using a cmsg. So there is only one system call: sendmsg().

=C2=A0
Do you know if setting TOS via cmsg = in sendmsg works for OSX as well?

Thank You,
=
_____________
Roman Shpount
=C2=A0
--047d7bfcfc1880a0de05009e422f-- From nobody Thu Aug 14 15:30:49 2014 Return-Path: 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 313761A88F5 for ; Thu, 14 Aug 2014 15:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 He74GsE6lA8d for ; Thu, 14 Aug 2014 15:30:47 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3501A88F0 for ; Thu, 14 Aug 2014 15:30:46 -0700 (PDT) Received: from [192.168.1.200] (p54819622.dip0.t-ipconnect.de [84.129.150.34]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A06521C104D8A; Fri, 15 Aug 2014 00:30:44 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Fri, 15 Aug 2014 00:30:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53EC70E5.7070105@alvestrand.no> <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> To: Roman Shpount X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/06ucDVmBsq-vnvO8zlDpvHQ7xCs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 22:30:48 -0000 On 15 Aug 2014, at 00:16, Roman Shpount wrote: > On Thu, Aug 14, 2014 at 5:52 PM, Michael Tuexen = wrote: > FreeBSD supports using a cmsg. So there is only one system call: = sendmsg(). >=20 > =20 > Do you know if setting TOS via cmsg in sendmsg works for OSX as well? =46rom reading the code: They don't provide a direct way to access it. They have a proprietary cmsg type SO_TRAFFIC_CLASS, which their own = values priority levels which they map to DSCPs. Best regards Michael >=20 > Thank You, > _____________ > Roman Shpount > =20 From nobody Fri Aug 15 06:35:51 2014 Return-Path: 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 665391A0AC2 for ; Fri, 15 Aug 2014 06:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 5fWrZmOyJyPs for ; Fri, 15 Aug 2014 06:35:46 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D3F541A00B5 for ; Fri, 15 Aug 2014 06:35:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C1ED07C3DDF for ; Fri, 15 Aug 2014 15:35:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXBhnqD91LUu for ; Fri, 15 Aug 2014 15:35:43 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:7973:dfaf:6ddb:1e47]) by mork.alvestrand.no (Postfix) with ESMTPSA id A61157C3DDE for ; Fri, 15 Aug 2014 15:35:43 +0200 (CEST) Message-ID: <53EE0CAD.7090301@alvestrand.no> Date: Fri, 15 Aug 2014 15:35:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20140815133324.23199.55890.idtracker@ietfa.amsl.com> In-Reply-To: <20140815133324.23199.55890.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140815133324.23199.55890.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090401000506040409060206" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_9PTmwwyUa1nSTyPJd4MXn8TrlA Subject: [rtcweb] Gateway draft submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 13:35:49 -0000 This is a multi-part message in MIME format. --------------090401000506040409060206 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit As per discussions in Toronto, I have submitted an initial draft of a gateways draft. Uwe Rauschenbach and Christer Holmberg, who signed up to be co-authors, have contributed text and/or comments, but since both of them are on vacation at this time, and I couldn't get a signoff from them, I'm taking sole responsibility for the errors myself this time around. Comments welcome! Harald -------- Forwarded Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-gateways-00.txt Date: Fri, 15 Aug 2014 06:33:24 -0700 From: internet-drafts@ietf.org To: Harald T. Alvestrand , Harald Alvestrand A new version of I-D, draft-alvestrand-rtcweb-gateways-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Name: draft-alvestrand-rtcweb-gateways Revision: 00 Title: WebRTC Gateways Document date: 2014-08-15 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-gateways-00.txt Status: https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ Htmlized: http://tools.ietf.org/html/draft-alvestrand-rtcweb-gateways-00 Abstract: This document specifies conformance requirements for a class of WebRTC devices called "WebRTC gateways". This type of device forms interconnects between WebRTC browsers and devices that are not WebRTC browsers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------090401000506040409060206 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit As per discussions in Toronto, I have submitted an initial draft of a gateways draft.

Uwe Rauschenbach and Christer Holmberg, who signed up to be co-authors, have contributed text and/or comments, but since both of them are on vacation at this time, and I couldn't get a signoff from them, I'm taking sole responsibility for the errors myself this time around.

Comments welcome!

              Harald


-------- Forwarded Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-gateways-00.txt
Date: Fri, 15 Aug 2014 06:33:24 -0700
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-alvestrand-rtcweb-gateways-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name:		draft-alvestrand-rtcweb-gateways
Revision:	00
Title:		WebRTC Gateways
Document date:	2014-08-15
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-gateways-00.txt
Status:         https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/
Htmlized:       http://tools.ietf.org/html/draft-alvestrand-rtcweb-gateways-00


Abstract:
   This document specifies conformance requirements for a class of
   WebRTC devices called "WebRTC gateways".

   This type of device forms interconnects between WebRTC browsers and
   devices that are not WebRTC browsers.


                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------090401000506040409060206-- From nobody Fri Aug 15 07:20:25 2014 Return-Path: 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 0510F1A0AE6 for ; Fri, 15 Aug 2014 07:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 h5dxvdeuqv8O for ; Fri, 15 Aug 2014 07:20:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F4F1A0AE1 for ; Fri, 15 Aug 2014 07:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1478; q=dns/txt; s=iport; t=1408112422; x=1409322022; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3ljVV2vhnJ809jpoRlnMKlUVHvKmVvVU5o7xlsCAFqI=; b=lHrKwKhpt8qkCDjzrogDO+xlseOZTIrqm8rJA1BUmRx9RYM+LElsKyC9 p9uEKZhOxqGXH8qKaOKmVKCbTuS6UVwXYgtDsf/d9gBaKyxPVUDDUqYgy SK2mPz1nvvvBjSYYkUtWx4cZY/gCHtJ03jrhoK0UCRdMQ6miCYjNYEaaS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAOsV7lOtJV2U/2dsb2JhbABZgw1TW84DCocFUwGBEBZ3hAMBAQEDAQEBATc0CwUHBAIBCBEDAQIBHhAnCx0IAgQBDQWIOggNw38TBI8hKwcGhEYFkSCLHYwBiH2DXGwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.01,870,1400025600"; d="scan'208";a="347869340" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 15 Aug 2014 14:20:20 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7FEKKGd025556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 14:20:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 09:20:20 -0500 From: "Mo Zanaty (mzanaty)" To: Michael Tuexen , Roman Shpount Thread-Topic: [rtcweb] -transports- discussion of DSCP Thread-Index: AQHPuJQLShjadHSl6UWsh9lnXNiIew== Date: Fri, 15 Aug 2014 14:20:19 +0000 Message-ID: References: <53EC70E5.7070105@alvestrand.no> <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.81.3.65] Content-Type: text/plain; charset="us-ascii" Content-ID: <070808E6D7402C459E7E6A914043F78D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-NJC0OWl-7Y16Tmchj-oV9z6818 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 14:20:24 -0000 I thought SO_TRAFFIC_CLASS was only for IPv6. Does it also work for IPv4? Also, I thought these cmsg types were only for the recvmsg direction (when SO_RECV_TRAFFIC_CLASS is set). Do they also work in the sendmsg direction? If so, do they override the traffic class only for the specific sendmsg or all subsequent sends on the socket? This last question would also apply to FreeBSD, so that answer would be useful even if you have no idea what OSX does. Mo -----Original Message----- From: Michael Tuexen Date: Thursday, August 14, 2014 at 6:30 PM To: Roman Shpount Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP On 15 Aug 2014, at 00:16, Roman Shpount wrote: > On Thu, Aug 14, 2014 at 5:52 PM, Michael Tuexen > wrote: > FreeBSD supports using a cmsg. So there is only one system call: >sendmsg(). >=20 > =20 > Do you know if setting TOS via cmsg in sendmsg works for OSX as well? >From reading the code: They don't provide a direct way to access it. They have a proprietary cmsg type SO_TRAFFIC_CLASS, which their own values priority levels which they map to DSCPs. Best regards Michael >=20 > Thank You, > _____________ > Roman Shpount > =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 15 07:51:41 2014 Return-Path: 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 2416B1A0AEA for ; Fri, 15 Aug 2014 07:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.181 X-Spam-Level: X-Spam-Status: No, score=-11.181 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 c2_eG1J0pS0y for ; Fri, 15 Aug 2014 07:51:36 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456051A0AE8 for ; Fri, 15 Aug 2014 07:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=744; q=dns/txt; s=iport; t=1408114296; x=1409323896; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dx973b7oU35lf5yl6jZfCQr6Xd0nd5W/fGtK3L+KJIQ=; b=KkVieLJKqjamPk47BKYGxQJO3kaPcp20NINm20CW08VoQLVqTM/ce0QS AKuOre1S1O+0DjUR+d4SPI8obWgfLgTXleXrfqpbjlN7ofRGqppnqIOYI C768whvEeXM6aEiDUU7BlLmn8ixMrWmEaAIdsAAs5mxsGT2lAXKvjicMe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFACce7lOtJA2D/2dsb2JhbABZgw2BLtVlAYEQFneEBAEBAwE6RAsCAQg2EDIlAgSITQjEFRePU4RMBZEgix2MAYh9g1yCNIEHAQEB X-IronPort-AV: E=Sophos;i="5.01,870,1400025600"; d="scan'208";a="69566946" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 15 Aug 2014 14:51:36 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7FEpZGI006131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Aug 2014 14:51:35 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.204]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 09:51:35 -0500 From: "Mo Zanaty (mzanaty)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] -transports- discussion of DSCP Thread-Index: AQHPuJhozwEMTZrDC0yd6QqYkxmd6w== Date: Fri, 15 Aug 2014 14:51:35 +0000 Message-ID: References: <53EC70E5.7070105@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.81.3.65] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_iPBKsieN4Usvp4Pd4R4zyRtjX0 Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 14:51:38 -0000 > setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp)); This works if your UDP transmit queue is always empty. If it ever backs up, it fails, because this option clears the transmit queue. So while the extra syscall overhead is trivial, it is unreliable for general use. Also note that DART is likely to recommend a UDP flow only multiplex different drop precedences within the same class (e.g. AF41, AF42), but not different classes (e.g. AF41, EF). So even if there was a reliable way to set DSCP per packet on every OS, we must still deal with the higher level issue of whether to unbundle or unmark in cases DART does not recommend. Should -transports- give guidance on this? Or leave it up to implementations? Mo From nobody Fri Aug 15 17:52:11 2014 Return-Path: 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 957A31A0924 for ; Fri, 15 Aug 2014 17:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_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 AIujwqy3XW2d for ; Fri, 15 Aug 2014 17:52:07 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDB51A0919 for ; Fri, 15 Aug 2014 17:52:05 -0700 (PDT) Received: from userPC (unknown [122.166.152.109]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 6C6303C0083; Sat, 16 Aug 2014 00:52:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1408150328; bh=G6GA8Hy3SjWo+0Z7fW/FC7VNfLBO7UrwsS57ubcP/38=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=aV1mBYkSwSpl66GXWxbiPvCQ0knrDnoxxWAjfYDTZ+vjiSdKrmGZRd2FdtZKBk+sP IeyrwlTBwhBGp52DwAnuRMNW+9dhInzwOZ9ETxnXATFG+w+JKlSM3Mp2Q5ZzVkl0+H tpEI2I8fpP5qQIkwE3IvKX5VqYiMLfHuF/MjFk10= From: "Parthasarathi R" To: "'Harald Alvestrand'" , References: <20140815133324.23199.55890.idtracker@ietfa.amsl.com> <53EE0CAD.7090301@alvestrand.no> In-Reply-To: <53EE0CAD.7090301@alvestrand.no> Date: Sat, 16 Aug 2014 06:21:52 +0530 Message-ID: <001001cfb8ec$478f9ae0$d6aed0a0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CFB91A.6147D6E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+4jdruGBfuDhG8RnmKXuIcTFqC0QAGTgMA Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.53EEAB35.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CzUV9iyzzMamEwbm4QvqFvQ65BE Subject: Re: [rtcweb] Gateway draft submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 00:52:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0011_01CFB91A.6147D6E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Harald, =20 The draft looks as a good starting for WebRTC gateway. My initial review = comment are as follows: =20 1) Abstract & Sec 1 Para 2: WebRTC gateways are the type device = which shall be between WebRTC browsers=20 2) Sec 1: Figure shall be added to show the entities involved in = case WebRTC gateways 3) Sec 1.2 Bullet 1 & bullet 2: JSEP offer/answer has to be = mentioned instead of WebRTC Browser API 4) Sec 2: SDP extensions like MSID & AppID shall be relaxed 5) Sec 2: IDP shall be relaxed 6) The reference has to be added=20 =20 Thanks Partha =20 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald = Alvestrand Sent: Friday, August 15, 2014 7:06 PM To: rtcweb@ietf.org Subject: [rtcweb] Gateway draft submitted =20 As per discussions in Toronto, I have submitted an initial draft of a = gateways draft. Uwe Rauschenbach and Christer Holmberg, who signed up to be co-authors, = have contributed text and/or comments, but since both of them are on = vacation at this time, and I couldn't get a signoff from them, I'm = taking sole responsibility for the errors myself this time around. Comments welcome! Harald -------- Forwarded Message --------=20 Subject:=20 New Version Notification for draft-alvestrand-rtcweb-gateways-00.txt Date:=20 Fri, 15 Aug 2014 06:33:24 -0700 From:=20 internet-drafts@ietf.org To:=20 Harald T. Alvestrand = , Harald Alvestrand = =20 A new version of I-D, draft-alvestrand-rtcweb-gateways-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. =20 Name: draft-alvestrand-rtcweb-gateways Revision: 00 Title: WebRTC Gateways Document date: 2014-08-15 Group: Individual Submission Pages: 5 URL: = http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-gateways-00.t= xt Status: = https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ Htmlized: = http://tools.ietf.org/html/draft-alvestrand-rtcweb-gateways-00 =20 =20 Abstract: This document specifies conformance requirements for a class of WebRTC devices called "WebRTC gateways". =20 This type of device forms interconnects between WebRTC browsers and devices that are not WebRTC browsers. =20 =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 =20 ------=_NextPart_000_0011_01CFB91A.6147D6E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Harald,

 

The draft looks as a good starting for WebRTC gateway. My initial review comment are as follows:

 

1)      Abstract & Sec=C2=A0 1 Para 2:=C2=A0 WebRTC gateways = are the type device which shall be between WebRTC browsers

2)      Sec 1: Figure shall be added to show the entities = involved in case WebRTC gateways

3)      Sec 1.2=C2=A0 Bullet 1 & bullet 2:=C2=A0 JSEP = offer/answer has to be mentioned instead of WebRTC Browser API

4)      Sec 2: =C2=A0SDP extensions like MSID & AppID shall = be relaxed

5)      Sec 2: IDP shall be relaxed

6)      The reference has to be added

 

Thanks

Partha

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald = Alvestrand
Sent: Friday, August 15, 2014 7:06 PM
To: rtcweb@ietf.org
Subject: [rtcweb] Gateway draft submitted

 

As per discussions in Toronto, I have submitted an = initial draft of a gateways draft.

Uwe Rauschenbach and Christer Holmberg, who signed up to be co-authors, = have contributed text and/or comments, but since both of them are on vacation = at this time, and I couldn't get a signoff from them, I'm taking sole responsibility for the errors myself this time around.

Comments welcome!

            &= nbsp; Harald



-------- Forwarded Message --------

Subject:

New Version Notification for = draft-alvestrand-rtcweb-gateways-00.txt

Date: =

Fri, 15 Aug 2014 06:33:24 -0700

From: =

internet-drafts@ietf.org

To: =

Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no>

 

A new version of I-D, =
draft-alvestrand-rtcweb-gateways-00.txt
has been =
successfully submitted by Harald Alvestrand and posted to =
the
IETF =
repository.
 
Name:=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
draft-alvestrand-rtcweb-gateways
Revision:=C2=A0=C2=A0=
=C2=A0=C2=A0 =
00
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
WebRTC Gateways
Document date: =
2014-08-15
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Individual =
Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =
5
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-g=
ateways-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/=

Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 h=
ttp://tools.ietf.org/html/draft-alvestrand-rtcweb-gateways-00
 
 
Abs=
tract:
=C2=A0=C2=A0 This document specifies =
conformance requirements for a class =
of
=C2=A0=C2=A0 WebRTC devices called "WebRTC =
gateways".
 
=C2=A0=C2=
=A0 This type of device forms interconnects between WebRTC browsers =
and
=C2=A0=C2=A0 devices that are not WebRTC =
browsers.
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =

 
 
= 
Please note that it may take a couple of minutes from the time of =
submission
until the htmlized version and diff are =
available at =
tools.ietf.org.
 
The =
IETF Secretariat
 

 

 

------=_NextPart_000_0011_01CFB91A.6147D6E0-- From nobody Fri Aug 15 23:44:45 2014 Return-Path: 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 2B53A1A702A for ; Fri, 15 Aug 2014 23:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 pzDN5-qt0eyo for ; Fri, 15 Aug 2014 23:44:40 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0EB1A7029 for ; Fri, 15 Aug 2014 23:44:39 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Sat, 16 Aug 2014 08:44:37 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 988FD3A22E for ; Sat, 16 Aug 2014 08:44:31 +0200 (CEST) Message-ID: <53EEFDD3.6040607@omnitor.se> Date: Sat, 16 Aug 2014 08:44:35 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> In-Reply-To: <20140811181357.613.72705.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090802080707010108050401" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BqBrwBlrT4h9aAmEzQkYb-3on7Q Subject: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 06:44:43 -0000 This is a multi-part message in MIME format. --------------090802080707010108050401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times. Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft. I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations. I suggest to insert a new chapter 6.7 in the draft with the following contents. -------------------------------------------------------------------Proposed new section 6.7------------------------------------------------------------------------------------------- 6.7 Transmission failure and error handling Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications. If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted. All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels. If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel. If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers. If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel. -----------------------------------------------------------------------end of proposal--------------------------------------------------------------------------------------------------------------- I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording. Regards Gunnar ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se On 2014-08-11 20:13, IESG Secretary wrote: > The IESG would like to retract the current Last Call on the following > document: > > - 'WebRTC Data Channels' > as Proposed Standard > > The document's state has been set back to "AD Evaluation." > --------------090802080707010108050401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times.

Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft.

I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations.

I suggest to insert a new chapter 6.7 in the draft with the following contents. 

-------------------------------------------------------------------Proposed new section 6.7-------------------------------------------------------------------------------------------
6.7 Transmission failure and error handling

Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications.
If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted.  All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels.

If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel.

If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers. 

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
-----------------------------------------------------------------------end of proposal---------------------------------------------------------------------------------------------------------------

I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording.

Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se

On 2014-08-11 20:13, IESG Secretary wrote:
The IESG would like to retract the current Last Call on the following 
document:

- 'WebRTC Data Channels'
  <draft-ietf-rtcweb-data-channel-11.txt> as Proposed Standard

The document's state has been set back to "AD Evaluation."

--------------090802080707010108050401-- From nobody Sat Aug 16 05:01:29 2014 Return-Path: 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 B26A11A8771 for ; Sat, 16 Aug 2014 05:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 g8oYZ9cOFWL0 for ; Sat, 16 Aug 2014 05:01:22 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24461A876F for ; Sat, 16 Aug 2014 05:01:21 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so3261035wes.34 for ; Sat, 16 Aug 2014 05:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=UmVTVCQG1QlCpJvwndh98LMUXfetiYPFkuLUkSaoV9w=; b=tm7Hlc+N7WSXBiUcCYcHYo1+KptEVM/II3x9W7laYWsxGsjvaRHSpouYGtHcCKkQSC kYrMEM2en2EQt2R7oai7dzPDQbnUv4tIdm0U64wd4QoD1KSc3KkxPCou2TyhZz3MyRsg bvjIn0IHVe+kbKFxu2hsoumpLHkRpqNeux1A6ELAeQbQoVo+sBrtlOZ2f9aEN4nsGdEg Oq4Sc06vsAHviBkzEph5tqFGWbacsBOFxJFynC2HNmwGpHfsMW/QikkScKC4xxdmG69r ZZIVR4ASnlx9lkY60fN+Zkaqc+z8yBL+/zfvnyINbwemQxuVMEXNMPwouZld3XFZ8JsH rqYw== X-Received: by 10.194.243.230 with SMTP id xb6mr24305744wjc.100.1408190480398; Sat, 16 Aug 2014 05:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.90.229 with HTTP; Sat, 16 Aug 2014 05:01:00 -0700 (PDT) In-Reply-To: <53EEFDD3.6040607@omnitor.se> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> From: Barry Dingle Date: Sat, 16 Aug 2014 22:01:00 +1000 Message-ID: To: Gunnar Hellstrom , "rtcweb@ietf.org" , Barry Dingle Content-Type: multipart/alternative; boundary=089e01493c945c3e830500bde583 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/G3pJTLVsqEUA8TDDpGI51IgOldU Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 12:01:26 -0000 --089e01493c945c3e830500bde583 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that error handling is missing from draft-ietf-rtcweb-data-channel . Should the 'error' indications' in the proposed text be more specific? That is, should the error indications indicate the type of error. (The same error indication for all errors could be sent and be compliant with the currently proposed text.) Note - I assume that you are proposing adding the new Section 6.7 to draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 titled "Closing a channel". I assume you mean a new Section 6.8. Cheers, /Barry Dingle On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom < gunnar.hellstrom@omnitor.se> wrote: > We have discussed the lack of description of failure handling in > draft-ietf-rtcweb-data-channel a couple of times. > > Explanations of mechanisms have been provided in mail answers that I have > not seen documented elsewhere, but they have not been introduced in the > draft. > > I think that for specification and implementation of the WebRTC API, ther= e > is a need for clear specification how the channels behave in failure > situations. > > I suggest to insert a new chapter 6.7 in the draft with the following > contents. > > -------------------------------------------------------------------Propos= ed > new section > 6.7----------------------------------------------------------------------= --------------------- > 6.7 Transmission failure and error handling > > Failures can occur in an open channel by transmission error detection and > by SCTP watchdog error indications. > If transmission in a reliable channel fails, the association where the > channel belongs will be aborted. If all retries for a watchdog expires, t= he > corresponding association will be aborted. All channels in an associatio= n > that is aborted because of errors need to be closed by the party detectin= g > the failure. Network error indications shall be provided to upper layers = on > all closed channels. > > If retransmissions or transmission time is exceeded in a partially > reliable channel, the transmission SHALL be allowed to continue with othe= r > data items. A transmission error indication SHALL be provided to upper > layers on that channel. > > If reception out-of order is detected from an SCTP channel for which > ordered transmission is requested, the receiver SHALL close the data > channel, and provide an transmission error indication to upper layers. > > If a message with an unsupported PPID is received or some logical error i= s > detected by the receiver, the receiver SHALL close the corresponding data > channel. > -----------------------------------------------------------------------en= d > of > proposal-----------------------------------------------------------------= ---------------------------------------------- > > I am not sure about what the two last kinds of errors should result in an= d > hope that the experts can adjust the wording. > > Regards > > Gunnar > ------------------------------ > Gunnar Hellstr=C3=B6m > Omnitor > gunnar.hellstrom@omnitor.se > > On 2014-08-11 20:13, IESG Secretary wrote: > > The IESG would like to retract the current Last Call on the following > document: > > - 'WebRTC Data Channels' > as Proposed Standard > > The document's state has been set back to "AD Evaluation." > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01493c945c3e830500bde583 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that error handling is missing from draft-iet= f-rtcweb-data-channel .

Should the 'error' indic= ations' in the proposed text be more specific? That is, should the erro= r indications indicate the type of error. (The same error indication for al= l errors could be sent and be compliant with the currently proposed text.) =

Note - I assume that you are proposing adding the new = Section 6.7 to=C2=A0 draft-ietf-rtcweb-data-channel-11 . It already has a S= ection 6.7 titled "Closing a channel". I assume you mean a new Se= ction 6.8.

Cheers,<= br>/Barry Dingle




On Sat, Aug 16, 2014 at 4:44 PM, Gunnar = Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
=
=20 =20 =20
We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times.

Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft.

I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations.

I suggest to insert a new chapter 6.7 in the draft with the following contents.=C2=A0

-------------------------------------------------------------------Pr= oposed new section 6.7------------------------------------------------------------------------= -------------------
6.7 Transmission failure and error handling

Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications.
If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted.=C2=A0 All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels.

If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel.

If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers.=C2=A0

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
---------------------------------------------------------------------= --end of proposal-------------------------------------------------------------------= --------------------------------------------

I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording.

Regards

Gunnar
Gunnar Hellstr=C3=B6m
Omnitor
gu= nnar.hellstrom@omnitor.se

On 2014-08-11 20:13, IESG Secretary wrote:
The IESG would like to retract the current Last Call on the foll=
owing=20
document:

- 'WebRTC Data Channels'
  <draft-ietf-rtcweb-data-channel-11.txt> as Proposed Standard

The document's state has been set back to "AD Evaluation."


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--089e01493c945c3e830500bde583-- From nobody Sat Aug 16 06:25:48 2014 Return-Path: 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 0D82E1A8795 for ; Sat, 16 Aug 2014 06:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 xfXWZnHoqx0d for ; Sat, 16 Aug 2014 06:25:37 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78821A8794 for ; Sat, 16 Aug 2014 06:25:36 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS; Sat, 16 Aug 2014 15:25:12 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 414403A21D; Sat, 16 Aug 2014 15:25:26 +0200 (CEST) Message-ID: <53EF5BC8.7060803@omnitor.se> Date: Sat, 16 Aug 2014 15:25:28 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Dingle , "rtcweb@ietf.org" References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070703010100050303070609" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dm7eF79-_FLoUWVYb-5OpJYfsWo Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 13:25:44 -0000 This is a multi-part message in MIME format. --------------070703010100050303070609 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2014-08-16 14:01, Barry Dingle wrote: > I agree that error handling is missing from > draft-ietf-rtcweb-data-channel . > > Should the 'error' indications' in the proposed text be more specific? > That is, should the error indications indicate the type of error. (The > same error indication for all errors could be sent and be compliant > with the currently proposed text.) Yes, possibly more detailed failure cause information is beneficial. But this needs to be matched against the ambitions of the WebRTC API to be as similar as possible to the Websocket API. And the Websocket API groups many error reasons into one error indication because of security risks. See http://dev.w3.org/html5/websockets/ Maintenance and debugging might be hard without further refinement of error causes, while security is better with less specific information. A balanced proposal would be needed. A specific improvement would be to indicate if it is the sending side or the receiving side or both that will get an error indication. I have not seen the association concept in the WebRTC API. So, it seems that the association concept will be hidden in the implementation between the WebRTC API and the SCTP, because in interaction with SCTP, it is important to know when a new association needs to be opened, and when just a new channel can be opened in an existing association. The effect of the abortion of the association also needs to be understood by that layer and translated into separate rtcDataChannel API actions. One further note: I have assumed that ICE connectivity failures is handled separately by the WebRTC API implementation and will cause both indications to API users and to the RTCweb data channel implementations. Is that right? > > Note - I assume that you are proposing adding the new Section 6.7 to > draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 > titled "Closing a channel". I assume you mean a new Section 6.8. Right, thanks. > > Cheers, > /Barry Dingle > > > > > On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom > > wrote: > > We have discussed the lack of description of failure handling in > draft-ietf-rtcweb-data-channel a couple of times. > > Explanations of mechanisms have been provided in mail answers that > I have not seen documented elsewhere, but they have not been > introduced in the draft. > > I think that for specification and implementation of the WebRTC > API, there is a need for clear specification how the channels > behave in failure situations. > > I suggest to insert a new chapter 6.7 in the draft with the > following contents. > > -------------------------------------------------------------------Proposed > new section > 6.7------------------------------------------------------------------------------------------- > 6.7 Transmission failure and error handling > > Failures can occur in an open channel by transmission error > detection and by SCTP watchdog error indications. > If transmission in a reliable channel fails, the association where > the channel belongs will be aborted. If all retries for a watchdog > expires, the corresponding association will be aborted. All > channels in an association that is aborted because of errors need > to be closed by the party detecting the failure. Network error > indications shall be provided to upper layers on all closed channels. > > If retransmissions or transmission time is exceeded in a partially > reliable channel, the transmission SHALL be allowed to continue > with other data items. A transmission error indication SHALL be > provided to upper layers on that channel. > > If reception out-of order is detected from an SCTP channel for > which ordered transmission is requested, the receiver SHALL close > the data channel, and provide an transmission error indication to > upper layers. > > If a message with an unsupported PPID is received or some logical > error is detected by the receiver, the receiver SHALL close the > corresponding data channel. > -----------------------------------------------------------------------end > of > proposal--------------------------------------------------------------------------------------------------------------- > > I am not sure about what the two last kinds of errors should > result in and hope that the experts can adjust the wording. > > Regards > > Gunnar > ------------------------------------------------------------------------ > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > > On 2014-08-11 20:13, IESG Secretary wrote: >> The IESG would like to retract the current Last Call on the following >> document: >> >> - 'WebRTC Data Channels' >> as Proposed Standard >> >> The document's state has been set back to "AD Evaluation." >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --------------070703010100050303070609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2014-08-16 14:01, Barry Dingle wrote:
I agree that error handling is missing from draft-ietf-rtcweb-data-channel .

Should the 'error' indications' in the proposed text be more specific? That is, should the error indications indicate the type of error. (The same error indication for all errors could be sent and be compliant with the currently proposed text.)
Yes, possibly more detailed failure cause information is beneficial. But this needs to be matched against the ambitions of the WebRTC API to be as similar as possible to the Websocket API.
And the Websocket API groups many error reasons into one error indication because of security risks.
See http://dev.w3.org/html5/websockets/

Maintenance and debugging might be hard without further refinement of error causes, while security is better with less specific information. A balanced proposal would be needed.

A specific improvement would be to indicate if it is the sending side or the receiving side or both that will get an error indication.

I have not seen the association concept in the WebRTC API. So, it seems that the association concept will be hidden in the implementation between the WebRTC API and the SCTP, because in interaction with SCTP, it is important to know when a new association needs to be opened, and when just a new channel can be opened in an existing association. The effect of the abortion of the association also needs to be understood by that layer and translated into separate rtcDataChannel API actions.

One further note: I have assumed that ICE connectivity failures is handled separately by the WebRTC API implementation and will cause both indications to API users and to the RTCweb data channel implementations. Is that right?

 

Note - I assume that you are proposing adding the new Section 6.7 to  draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 titled "Closing a channel". I assume you mean a new Section 6.8.
Right, thanks.

Cheers,
/Barry Dingle




On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times.

Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft.

I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations.

I suggest to insert a new chapter 6.7 in the draft with the following contents. 

-------------------------------------------------------------------Proposed new section 6.7-------------------------------------------------------------------------------------------
6.7 Transmission failure and error handling

Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications.
If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted.  All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels.

If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel.

If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers. 

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
-----------------------------------------------------------------------end of proposal---------------------------------------------------------------------------------------------------------------

I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording.

Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se

On 2014-08-11 20:13, IESG Secretary wrote:
The IESG would like to retract the current Last Call on the following 
document:

- 'WebRTC Data Channels'
  <draft-ietf-rtcweb-data-channel-11.txt> as Proposed Standard

The document's state has been set back to "AD Evaluation."


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



--------------070703010100050303070609-- From nobody Sat Aug 16 07:16:11 2014 Return-Path: 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 C90DD1A87EC for ; Sat, 16 Aug 2014 07:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 R0m2S3MZs82E for ; Sat, 16 Aug 2014 07:16:05 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33ED1A8821 for ; Sat, 16 Aug 2014 07:16:01 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so3263218wgh.20 for ; Sat, 16 Aug 2014 07:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=MemWKnpdC1rV2WraBP7JEXSItzlUTwj+2XnFhfxe/BU=; b=mCVeZmBIHa4L6wrriW7YMnTJsMpJU9OaF3PhD3keMlz2KBe6U4p/+P9I3UfaMOxjKN EVMeVcSl1VrWMF6VBC3WDa4PMpjJvn+80ZGnlzGNKrWdjScXUBs8ttw6GrbqV4FKdK/f cxnVUlfS408J/zr3TszSqUadV4x+8ji27MrnoA6Li/83w8MkgPJVNKLoujs6oImZl7JI e00pen6S0s2zPIYRhObMO2PM+tgc8D8V3DtBcBjZvCXoXinkDw8LImNR+j8MMGuP9SMc 0LZyQ/3kWePQKvHwzu4v/ao91TmKNi5owixr9ZYglS2lL/hLITVpndZAaoDEx+e+XidZ d1hQ== X-Received: by 10.194.205.70 with SMTP id le6mr27956688wjc.25.1408198560473; Sat, 16 Aug 2014 07:16:00 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id dc3sm26831214wjc.27.2014.08.16.07.15.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 07:15:59 -0700 (PDT) Message-ID: <53EF67A3.40700@gmail.com> Date: Sat, 16 Aug 2014 16:16:03 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140815133324.23199.55890.idtracker@ietfa.amsl.com> <53EE0CAD.7090301@alvestrand.no> In-Reply-To: <53EE0CAD.7090301@alvestrand.no> Content-Type: multipart/alternative; boundary="------------020007050400010202000802" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/iViIe4bMAYfsoS362YJCCPRTtQk Subject: Re: [rtcweb] Gateway draft submitted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 14:16:08 -0000 This is a multi-part message in MIME format. --------------020007050400010202000802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Harald, Lorenzo Miniero, Victor Pascual and me wrote the "Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs)": http://tools.ietf.org/html/draft-miniero-straw-b2bua-rtcp-00 that I think could be related to this one. Maybe it could be worthy to reference it? Best regards Sergio On 15/08/2014 15:35, Harald Alvestrand wrote: > As per discussions in Toronto, I have submitted an initial draft of a > gateways draft. > > Uwe Rauschenbach and Christer Holmberg, who signed up to be > co-authors, have contributed text and/or comments, but since both of > them are on vacation at this time, and I couldn't get a signoff from > them, I'm taking sole responsibility for the errors myself this time > around. > > Comments welcome! > > Harald > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-alvestrand-rtcweb-gateways-00.txt > Date: Fri, 15 Aug 2014 06:33:24 -0700 > From: internet-drafts@ietf.org > To: Harald T. Alvestrand , Harald Alvestrand > > > > > A new version of I-D, draft-alvestrand-rtcweb-gateways-00.txt > has been successfully submitted by Harald Alvestrand and posted to the > IETF repository. > > Name: draft-alvestrand-rtcweb-gateways > Revision: 00 > Title: WebRTC Gateways > Document date: 2014-08-15 > Group: Individual Submission > Pages: 5 > URL:http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-gateways-00.txt > Status:https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ > Htmlized:http://tools.ietf.org/html/draft-alvestrand-rtcweb-gateways-00 > > > Abstract: > This document specifies conformance requirements for a class of > WebRTC devices called "WebRTC gateways". > > This type of device forms interconnects between WebRTC browsers and > devices that are not WebRTC browsers. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020007050400010202000802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Harald,

Lorenzo Miniero, Victor Pascual and me wrote the "Guidelines to support RTCP end-to-end in Back-to-Back User Agents  (B2BUAs)":

http://tools.ietf.org/html/draft-miniero-straw-b2bua-rtcp-00

that I think could be related to this one. Maybe it could be worthy to reference it?

Best regards
Sergio
On 15/08/2014 15:35, Harald Alvestrand wrote:
As per discussions in Toronto, I have submitted an initial draft of a gateways draft.

Uwe Rauschenbach and Christer Holmberg, who signed up to be co-authors, have contributed text and/or comments, but since both of them are on vacation at this time, and I couldn't get a signoff from them, I'm taking sole responsibility for the errors myself this time around.

Comments welcome!

              Harald


-------- Forwarded Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-gateways-00.txt
Date: Fri, 15 Aug 2014 06:33:24 -0700
From: internet-drafts@ietf.org
To: Harald T. Alvestrand <harald@alvestrand.no>, Harald Alvestrand <harald@alvestrand.no> 


A new version of I-D, draft-alvestrand-rtcweb-gateways-00.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name:		draft-alvestrand-rtcweb-gateways
Revision:	00
Title:		WebRTC Gateways
Document date:	2014-08-15
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-alvestrand-rtcweb-gateways-00.txt
Status:         https://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/
Htmlized:       http://tools.ietf.org/html/draft-alvestrand-rtcweb-gateways-00


Abstract:
   This document specifies conformance requirements for a class of
   WebRTC devices called "WebRTC gateways".

   This type of device forms interconnects between WebRTC browsers and
   devices that are not WebRTC browsers.


                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat






_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------020007050400010202000802-- From nobody Sun Aug 17 12:36:31 2014 Return-Path: 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 E1F841A6FCB for ; Sun, 17 Aug 2014 12:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 6yJKLKZAxRxz for ; Sun, 17 Aug 2014 12:36:26 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F046D1A6FC8 for ; Sun, 17 Aug 2014 12:36:25 -0700 (PDT) Received: from [192.168.1.200] (p54818253.dip0.t-ipconnect.de [84.129.130.83]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A728F1C104F9A; Sun, 17 Aug 2014 21:36:22 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Sun, 17 Aug 2014 21:36:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9EB98FC1-3E76-44F6-A874-C1DA3BA3AB1B@lurchi.franken.de> References: <53EC70E5.7070105@alvestrand.no> <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> To: "Mo Zanaty (mzanaty)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xibBKglJRLH8IJZzyDiXkahUtMo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 19:36:30 -0000 On 15 Aug 2014, at 16:20, Mo Zanaty (mzanaty) wrote: > I thought SO_TRAFFIC_CLASS was only for IPv6. Does it also work for = IPv4? I guess so. = http://fxr.watson.org/fxr/source/bsd/netinet/udp_usrreq.c?v=3Dxnu-2050.18.= 24#L1330 should handle IPv4 and IPv6 sockets. >=20 > Also, I thought these cmsg types were only for the recvmsg direction = (when > SO_RECV_TRAFFIC_CLASS is set). Do they also work in the sendmsg = direction? Yepp. The above is in udp_output(), a routine called when sending UDP = packets. > If so, do they override the traffic class only for the specific = sendmsg or > all subsequent sends on the socket? This last question would also = apply to Only on that packet. The value is not stored at the socket layer / = endpoint. > FreeBSD, so that answer would be useful even if you have no idea what = OSX > does. Same for FreeBSD. At least on FreeBSD you have a socket option to set the default value = for all future packets. Using the cmsg overwrites the the default on a = per-packet base. Best regards Michael >=20 > Mo >=20 > -----Original Message----- > From: Michael Tuexen > Date: Thursday, August 14, 2014 at 6:30 PM > To: Roman Shpount > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] -transports- discussion of DSCP >=20 > On 15 Aug 2014, at 00:16, Roman Shpount wrote: >=20 >> On Thu, Aug 14, 2014 at 5:52 PM, Michael Tuexen >> wrote: >> FreeBSD supports using a cmsg. So there is only one system call: >> sendmsg(). >>=20 >>=20 >> Do you know if setting TOS via cmsg in sendmsg works for OSX as well? > =46rom reading the code: They don't provide a direct way to access it. > They have a proprietary cmsg type SO_TRAFFIC_CLASS, which their own = values > priority levels which they map to DSCPs. >=20 > Best regards > Michael >>=20 >> Thank You, >> _____________ >> Roman Shpount >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From nobody Sun Aug 17 12:37:41 2014 Return-Path: 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 554A31A014E for ; Sun, 17 Aug 2014 12:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001] 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 FXlY3HB9om5w for ; Sun, 17 Aug 2014 12:37:39 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168241A011E for ; Sun, 17 Aug 2014 12:37:39 -0700 (PDT) Received: from [192.168.1.200] (p54818253.dip0.t-ipconnect.de [84.129.130.83]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C51B71C104FA5; Sun, 17 Aug 2014 21:37:29 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Sun, 17 Aug 2014 21:37:12 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6A08975F-FBF2-4153-89AB-A2249B655079@lurchi.franken.de> References: <53EC70E5.7070105@alvestrand.no> To: "Mo Zanaty (mzanaty)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8vnVmJXuzfrUegzyKmloYsNLnDo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 19:37:40 -0000 On 15 Aug 2014, at 16:51, Mo Zanaty (mzanaty) wrote: >> setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp)); > > This works if your UDP transmit queue is always empty. If it ever backs > up, it fails, because this option clears the transmit queue. So while the > extra syscall overhead is trivial, it is unreliable for general use. Which OS has a UDP send queue? Best regards Michael > > Also note that DART is likely to recommend a UDP flow only multiplex > different drop precedences within the same class (e.g. AF41, AF42), but > not different classes (e.g. AF41, EF). So even if there was a reliable way > to set DSCP per packet on every OS, we must still deal with the higher > level issue of whether to unbundle or unmark in cases DART does not > recommend. Should -transports- give guidance on this? Or leave it up to > implementations? > > Mo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Mon Aug 18 01:03:42 2014 Return-Path: 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 79D0C1A032E for ; Mon, 18 Aug 2014 01:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RCVD_IN_DNSWL_HI=-5, SPF_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 1-TfwYLYxwIR for ; Mon, 18 Aug 2014 01:03:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45071A032D for ; Mon, 18 Aug 2014 01:03:37 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s7I83ZEt012876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Aug 2014 08:03:36 GMT Received: from SGSIHTC003.nsn-intra.net ([10.159.225.20]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s7I83AbH022470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 10:03:34 +0200 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.187]) by SGSIHTC003.nsn-intra.net ([10.159.225.20]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 16:02:43 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: ext Michael Tuexen , Roman Shpount Thread-Topic: [rtcweb] -transports- discussion of DSCP Thread-Index: AQHPt+wdVqtHi1xsJECn87H27vtSl5vQC3KAgAASqICAAAbNAIAAA+mAgAXc1SA= Date: Mon, 18 Aug 2014 08:02:42 +0000 Message-ID: References: <53EC70E5.7070105@alvestrand.no> <406FAF1F-E559-4DB0-A14C-B678AF04B41B@lurchi.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1062 X-purgate-ID: 151667::1408349016-000005B1-D503732D/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FWNbPy2s0_VHF_64Yfi0sNmEP8o Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 08:03:40 -0000 DSCP can be set by using setsockopt() system call. Regards Ranjit -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Michael Tuex= en Sent: Friday, August 15, 2014 4:01 AM To: Roman Shpount Cc: rtcweb@ietf.org Subject: Re: [rtcweb] -transports- discussion of DSCP On 15 Aug 2014, at 00:16, Roman Shpount wrote: > On Thu, Aug 14, 2014 at 5:52 PM, Michael Tuexen wrote: > FreeBSD supports using a cmsg. So there is only one system call: sendmsg(= ). >=20 > =20 > Do you know if setting TOS via cmsg in sendmsg works for OSX as well? >From reading the code: They don't provide a direct way to access it. They have a proprietary cmsg type SO_TRAFFIC_CLASS, which their own values priority levels which they map to DSCPs. Best regards Michael >=20 > Thank You, > _____________ > Roman Shpount > =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 18 01:25:43 2014 Return-Path: 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 CC0AC1A0344 for ; Mon, 18 Aug 2014 01:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.42 X-Spam-Level: * X-Spam-Status: No, score=1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_STOCK2=3.988, RP_MATCHES_RCVD=-0.668] 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 Mn_ZVsJPy5V2 for ; Mon, 18 Aug 2014 01:25:39 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id C49281A0341 for ; Mon, 18 Aug 2014 01:25:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DB5917C3C42 for ; Mon, 18 Aug 2014 10:25:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeCWCrs1aw42 for ; Mon, 18 Aug 2014 10:25:37 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:f831:3e5:f731:e275] (unknown [IPv6:2001:470:de0a:27:f831:3e5:f731:e275]) by mork.alvestrand.no (Postfix) with ESMTPSA id D88997C3763 for ; Mon, 18 Aug 2014 10:25:36 +0200 (CEST) Message-ID: <53F1B880.2060905@alvestrand.no> Date: Mon, 18 Aug 2014 10:25:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53EC70E5.7070105@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/aPbgcG40wisSmgWZ1EVKC2rQACk Subject: Re: [rtcweb] -transports- discussion of DSCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 08:25:40 -0000 On 08/15/2014 04:51 PM, Mo Zanaty (mzanaty) wrote: >> setsockopt(socket_, IPPROTO_IP, IP_TOS, &dscp, sizeof(dscp)); > This works if your UDP transmit queue is always empty. If it ever backs > up, it fails, because this option clears the transmit queue. So while the > extra syscall overhead is trivial, it is unreliable for general use. I'd like to see a demo program that shows there's an issue. A natural implementation strategy would be to mark the DSCP when creating a buffer in sendmsg(), before enqueueing it; there would only be an issue if some implementation had a strategy of marking the DSCP with the socket's currently selected DSCP value at dequeueing time (and one could argue that such an implementation has a bug that needs fixing). > > Also note that DART is likely to recommend a UDP flow only multiplex > different drop precedences within the same class (e.g. AF41, AF42), but > not different classes (e.g. AF41, EF). So even if there was a reliable way > to set DSCP per packet on every OS, we must still deal with the higher > level issue of whether to unbundle or unmark in cases DART does not > recommend. Should -transports- give guidance on this? Or leave it up to > implementations? Either rtcweb-transports- says what to do, or it refers to something normative that says what to do. The only higher level target in the chain is -overview, and that's clearly the wrong place. Since DART's target is informative, by Hobson's choice it seems that rtcweb-transports- is the place. I see the implementation choices to be unbundling, marking at the lowest class (?) recommended, or not marking at all - I assume that BE is a different class than AF4*. > > Mo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 18 01:30:28 2014 Return-Path: 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 9F65E1A035E for ; Mon, 18 Aug 2014 01:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 8JMSoDuwJWbO for ; Mon, 18 Aug 2014 01:30:23 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 830E71A035D for ; Mon, 18 Aug 2014 01:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 70B6F7C3C42 for ; Mon, 18 Aug 2014 10:30:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hkV9Ml3SiTK for ; Mon, 18 Aug 2014 10:30:19 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:f831:3e5:f731:e275] (unknown [IPv6:2001:470:de0a:27:f831:3e5:f731:e275]) by mork.alvestrand.no (Postfix) with ESMTPSA id 206037C3763 for ; Mon, 18 Aug 2014 10:30:19 +0200 (CEST) Message-ID: <53F1B99A.1010404@alvestrand.no> Date: Mon, 18 Aug 2014 10:30:18 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53EF5BC8.7060803@omnitor.se> In-Reply-To: <53EF5BC8.7060803@omnitor.se> Content-Type: multipart/alternative; boundary="------------040102020100000204000709" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zeE3n_JCpxAl6xa3KdRMMVsCGfk Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 08:30:25 -0000 This is a multi-part message in MIME format. --------------040102020100000204000709 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 08/16/2014 03:25 PM, Gunnar Hellstrom wrote: > On 2014-08-16 14:01, Barry Dingle wrote: >> I agree that error handling is missing from >> draft-ietf-rtcweb-data-channel . >> >> Should the 'error' indications' in the proposed text be more >> specific? That is, should the error indications indicate the type of >> error. (The same error indication for all errors could be sent and be >> compliant with the currently proposed text.) > Yes, possibly more detailed failure cause information is beneficial. > But this needs to be matched against the ambitions of the WebRTC API > to be as similar as possible to the Websocket API. > And the Websocket API groups many error reasons into one error > indication because of security risks. > See http://dev.w3.org/html5/websockets/ > > Maintenance and debugging might be hard without further refinement of > error causes, while security is better with less specific information. > A balanced proposal would be needed. The need for debugging is handled by advice on what information needs to be in the "message" part of the error indication. If there is a need for consistent action to be taken by applications, I think that needs to be in the "name" part - that is, different errors - or in additional information passed in the error. > > A specific improvement would be to indicate if it is the sending side > or the receiving side or both that will get an error indication. > > I have not seen the association concept in the WebRTC API. So, it > seems that the association concept will be hidden in the > implementation between the WebRTC API and the SCTP, because in > interaction with SCTP, it is important to know when a new association > needs to be opened, and when just a new channel can be opened in an > existing association. The effect of the abortion of the association > also needs to be understood by that layer and translated into separate > rtcDataChannel API actions. > > One further note: I have assumed that ICE connectivity failures is > handled separately by the WebRTC API implementation and will cause > both indications to API users and to the RTCweb data channel > implementations. Is that right? I can't parse this in terms that fit my implementation - there is no distinction between the "RTCweb data channel implementation" and "the WebRTC API implementation" - it's all the WebRTC implementation, and there is no distinction that can be surfaced. What's the change that needs to be there? > > >> >> Note - I assume that you are proposing adding the new Section 6.7 to >> draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 >> titled "Closing a channel". I assume you mean a new Section 6.8. > Right, thanks. >> >> Cheers, >> /Barry Dingle >> >> >> >> >> On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom >> > wrote: >> >> We have discussed the lack of description of failure handling in >> draft-ietf-rtcweb-data-channel a couple of times. >> >> Explanations of mechanisms have been provided in mail answers >> that I have not seen documented elsewhere, but they have not been >> introduced in the draft. >> >> I think that for specification and implementation of the WebRTC >> API, there is a need for clear specification how the channels >> behave in failure situations. >> >> I suggest to insert a new chapter 6.7 in the draft with the >> following contents. >> >> -------------------------------------------------------------------Proposed >> new section >> 6.7------------------------------------------------------------------------------------------- >> 6.7 Transmission failure and error handling >> >> Failures can occur in an open channel by transmission error >> detection and by SCTP watchdog error indications. >> If transmission in a reliable channel fails, the association >> where the channel belongs will be aborted. If all retries for a >> watchdog expires, the corresponding association will be aborted. >> All channels in an association that is aborted because of errors >> need to be closed by the party detecting the failure. Network >> error indications shall be provided to upper layers on all closed >> channels. >> >> If retransmissions or transmission time is exceeded in a >> partially reliable channel, the transmission SHALL be allowed to >> continue with other data items. A transmission error indication >> SHALL be provided to upper layers on that channel. >> >> If reception out-of order is detected from an SCTP channel for >> which ordered transmission is requested, the receiver SHALL close >> the data channel, and provide an transmission error indication to >> upper layers. >> >> If a message with an unsupported PPID is received or some logical >> error is detected by the receiver, the receiver SHALL close the >> corresponding data channel. >> -----------------------------------------------------------------------end >> of >> proposal--------------------------------------------------------------------------------------------------------------- >> >> I am not sure about what the two last kinds of errors should >> result in and hope that the experts can adjust the wording. >> >> Regards >> >> Gunnar >> ------------------------------------------------------------------------ >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> >> On 2014-08-11 20:13, IESG Secretary wrote: >>> The IESG would like to retract the current Last Call on the following >>> document: >>> >>> - 'WebRTC Data Channels' >>> as Proposed Standard >>> >>> The document's state has been set back to "AD Evaluation." >>> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040102020100000204000709 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 08/16/2014 03:25 PM, Gunnar Hellstrom wrote:
On 2014-08-16 14:01, Barry Dingle wrote:
I agree that error handling is missing from draft-ietf-rtcweb-data-channel .

Should the 'error' indications' in the proposed text be more specific? That is, should the error indications indicate the type of error. (The same error indication for all errors could be sent and be compliant with the currently proposed text.)
Yes, possibly more detailed failure cause information is beneficial. But this needs to be matched against the ambitions of the WebRTC API to be as similar as possible to the Websocket API.
And the Websocket API groups many error reasons into one error indication because of security risks.
See http://dev.w3.org/html5/websockets/

Maintenance and debugging might be hard without further refinement of error causes, while security is better with less specific information. A balanced proposal would be needed.

The need for debugging is handled by advice on what information needs to be in the "message" part of the error indication.

If there is a need for consistent action to be taken by applications, I think that needs to be in the "name" part - that is, different errors - or in additional information passed in the error.


A specific improvement would be to indicate if it is the sending side or the receiving side or both that will get an error indication.

I have not seen the association concept in the WebRTC API. So, it seems that the association concept will be hidden in the implementation between the WebRTC API and the SCTP, because in interaction with SCTP, it is important to know when a new association needs to be opened, and when just a new channel can be opened in an existing association. The effect of the abortion of the association also needs to be understood by that layer and translated into separate rtcDataChannel API actions.

One further note: I have assumed that ICE connectivity failures is handled separately by the WebRTC API implementation and will cause both indications to API users and to the RTCweb data channel implementations. Is that right?

I can't parse this in terms that fit my implementation - there is no distinction between the "RTCweb data channel implementation" and "the WebRTC API implementation" - it's all the WebRTC implementation, and there is no distinction that can be surfaced.

What's the change that needs to be there?



 

Note - I assume that you are proposing adding the new Section 6.7 to  draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 titled "Closing a channel". I assume you mean a new Section 6.8.
Right, thanks.

Cheers,
/Barry Dingle




On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times.

Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft.

I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations.

I suggest to insert a new chapter 6.7 in the draft with the following contents. 

-------------------------------------------------------------------Proposed new section 6.7-------------------------------------------------------------------------------------------
6.7 Transmission failure and error handling

Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications.
If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted.  All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels.

If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel.

If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers. 

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
-----------------------------------------------------------------------end of proposal---------------------------------------------------------------------------------------------------------------

I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording.

Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se

On 2014-08-11 20:13, IESG Secretary wrote:
The IESG would like to retract the current Last Call on the following 
document:

- 'WebRTC Data Channels'
  <draft-ietf-rtcweb-data-channel-11.txt> as Proposed Standard

The document's state has been set back to "AD Evaluation."


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb





_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------040102020100000204000709-- From nobody Mon Aug 18 04:11:46 2014 Return-Path: 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 A06501A039B for ; Mon, 18 Aug 2014 04:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 ZDl-J9G2eLYv for ; Mon, 18 Aug 2014 04:11:29 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8D1A03D2 for ; Mon, 18 Aug 2014 04:11:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 335E47C3E02 for ; Mon, 18 Aug 2014 13:11:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfTcDbKJA+eu for ; Mon, 18 Aug 2014 13:11:27 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:f831:3e5:f731:e275] (unknown [IPv6:2001:470:de0a:27:f831:3e5:f731:e275]) by mork.alvestrand.no (Postfix) with ESMTPSA id 543257C3DFE for ; Mon, 18 Aug 2014 13:11:27 +0200 (CEST) Message-ID: <53F1DF5E.6030309@alvestrand.no> Date: Mon, 18 Aug 2014 13:11:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z7IyLgPJFXLBJ8fkIfuvPGAy7v8 Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 11:11:40 -0000 When writing the gateway document, I found myself grappling with the "device" description. It is somewhat uncomfortable, in that as first defined, it requires full WebRTC functionality except for the API part - this means that it should support data channels, full ICE, bundling and so on. But for gateways, it makes sense to let go of a lot of these requirements. So a gateway is not a device. But what is the name for the thing that a gateway is, a device is, and a browser is, that names "the set of things that can successfully negotiate connectivity"? And what are the requirements on *that*? I see a couple of options: - Redefine "Device" to mean "that which can successfully communicate with a browser". It's free to negotiate away features if it can, but needs to interoperate with a browser that implements only the absolute minimum of what a browser has to implement. - Define a new class of "thing" which is "the thing that can talk to browsers" - of which a gateway has to be an exemplar. This is a kind of word game in some ways, but when we make definitions, we also define what's easy to talk about. And that can influence what we end up building. What do people think? Harald From nobody Mon Aug 18 04:15:53 2014 Return-Path: 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 4D36F1A03D3 for ; Mon, 18 Aug 2014 04:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 4EwXqwT297Ti for ; Mon, 18 Aug 2014 04:15:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 791FB1A03D7 for ; Mon, 18 Aug 2014 04:15:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id BBFFC7C3E02 for ; Mon, 18 Aug 2014 13:15:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZhYBDAGmBuI for ; Mon, 18 Aug 2014 13:15:42 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:f831:3e5:f731:e275] (unknown [IPv6:2001:470:de0a:27:f831:3e5:f731:e275]) by mork.alvestrand.no (Postfix) with ESMTPSA id CF6327C3DFE for ; Mon, 18 Aug 2014 13:15:41 +0200 (CEST) Message-ID: <53F1E05D.9040804@alvestrand.no> Date: Mon, 18 Aug 2014 13:15:41 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> In-Reply-To: <53EEFDD3.6040607@omnitor.se> Content-Type: multipart/alternative; boundary="------------050405090503000108090502" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2uMY9WU0BFowto-fLy4lJ7z-FCg Subject: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 11:15:49 -0000 This is a multi-part message in MIME format. --------------050405090503000108090502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Picking up a single point.... On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote: > > If a message with an unsupported PPID is received or some logical > error is detected by the receiver, the receiver SHALL close the > corresponding data channel. This struct me when thinking about the zero-length-data proposal: If we ever want to add another such feature *without* explicitly negotiating the use of the feature at setup time, we can't do this. If we want the possibility of un-negotiated extensions, we HAVE to say (somewhere) If a message with an unsupported PPID is received, it is silently ignored. OTOH, if we're convinced we never need that kind of extensibility, any way we do this is fine. Harald --------------050405090503000108090502 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Picking up a single point....

On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote:

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel. 

This struct me when thinking about the zero-length-data proposal: If we ever want to add another such feature *without* explicitly negotiating the use of the feature at setup time, we can't do this.

If we want the possibility of un-negotiated extensions, we HAVE to say (somewhere)

  If a message with an unsupported PPID is received, it is silently ignored.

OTOH, if we're convinced we never need that kind of extensibility, any way we do this is fine.

             Harald

--------------050405090503000108090502-- From nobody Mon Aug 18 04:19:23 2014 Return-Path: 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 11A991A03E8; Mon, 18 Aug 2014 04:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HDpkfJVtcd5G; Mon, 18 Aug 2014 04:19:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C0A1A039B; Mon, 18 Aug 2014 04:19:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140818111916.2857.63981.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 04:19:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sMvMAWoZT4SGsRTX_OTr--M8QWs Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 11:19:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-11.txt Pages : 22 Date : 2014-08-18 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications RTCWEB compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 18 04:23:54 2014 Return-Path: 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 6F03D1A03F0 for ; Mon, 18 Aug 2014 04:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 uUdDRLuQwEIC for ; Mon, 18 Aug 2014 04:23:48 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA981A03E4 for ; Mon, 18 Aug 2014 04:23:47 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Mon, 18 Aug 2014 13:24:01 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 6C7671A82B for ; Mon, 18 Aug 2014 13:23:44 +0200 (CEST) Message-ID: <53F1E240.3020509@omnitor.se> Date: Mon, 18 Aug 2014 13:23:44 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> In-Reply-To: <53F1E05D.9040804@alvestrand.no> Content-Type: multipart/alternative; boundary="------------060406050801020407090607" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0jFTvk4E6s90cKHWpaCj2wsmtiM Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 11:23:51 -0000 This is a multi-part message in MIME format. --------------060406050801020407090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2014-08-18 13:15, Harald Alvestrand wrote: > Picking up a single point.... > > On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote: >> >> If a message with an unsupported PPID is received or some logical >> error is detected by the receiver, the receiver SHALL close the >> corresponding data channel. > > This struct me when thinking about the zero-length-data proposal: If > we ever want to add another such feature *without* explicitly > negotiating the use of the feature at setup time, we can't do this. > > If we want the possibility of un-negotiated extensions, we HAVE to say > (somewhere) > > If a message with an unsupported PPID is received, it is silently > ignored. [GH] That sounds wise, and also in line with the security aspects that make Websocket be very conservative about signaling errors and their reasons. WebRTC data channels have the ambition to be similar. /Gunnar > > OTOH, if we're convinced we never need that kind of extensibility, any > way we do this is fine. > > Harald > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060406050801020407090607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2014-08-18 13:15, Harald Alvestrand wrote:
Picking up a single point....

On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote:

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel. 

This struct me when thinking about the zero-length-data proposal: If we ever want to add another such feature *without* explicitly negotiating the use of the feature at setup time, we can't do this.

If we want the possibility of un-negotiated extensions, we HAVE to say (somewhere)

  If a message with an unsupported PPID is received, it is silently ignored.
[GH] That sounds wise, and also in line with the security aspects that make Websocket be very conservative about signaling errors and their reasons. WebRTC data channels have the ambition to be similar.
/Gunnar

OTOH, if we're convinced we never need that kind of extensibility, any way we do this is fine.

             Harald



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060406050801020407090607-- From nobody Mon Aug 18 04:24:49 2014 Return-Path: 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 694711A03E7 for ; Mon, 18 Aug 2014 04:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 xaZoUTStYNZG for ; Mon, 18 Aug 2014 04:24:44 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C371A03D9 for ; Mon, 18 Aug 2014 04:24:44 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id l18so4692511wgh.13 for ; Mon, 18 Aug 2014 04:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wZylTcGoSjm9sj+35vzfbW1BIeaKeJx1tBEz+hDOOy4=; b=H9GA1IilJm/DULt7jkeUdXkqUMQXcCpaWk1PVMGR57aPlC3NobZoLxYG5z9TDBZwIK SJpKHagHdsAPIykfQTK7zyJA6d2q8p3LzMCsJXrUQyXcoXd1xNQpBld8HIUZkRoQUpox SzrlCzxFJ2MboMd6K9zYcojRhJZDbAsf3i6bW3KuriXN+GQ7cFkm8xBLouW+ACZeNAEf GwJ2/D8B3HsY59PmF9luGD5YbW4BuiFTodV8ZFLRC0GtYKvuulpHiKw0JwJSmME8iYy/ N1IdVRw75s8G3kU164N1Ej0pbXgZ52dcUMN08fx2ghQ0ypmx+ZGgj+2u4Zzr+v0MMsLu Kt8g== X-Received: by 10.194.77.233 with SMTP id v9mr1962242wjw.129.1408361082915; Mon, 18 Aug 2014 04:24:42 -0700 (PDT) Received: from [192.168.1.37] (228.Red-88-9-161.dynamicIP.rima-tde.net. [88.9.161.228]) by mx.google.com with ESMTPSA id f3sm37042623wiz.0.2014.08.18.04.24.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Aug 2014 04:24:42 -0700 (PDT) Message-ID: <53F1E27F.1060403@gmail.com> Date: Mon, 18 Aug 2014 13:24:47 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> In-Reply-To: <53F1DF5E.6030309@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/c3vSzTadFtSPz-rXJXgcsZ7tPi0 Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 11:24:46 -0000 Hi Harald, I always liked "endpoint" much more than "device". We could have different types of endpoints, and define a browser like: a WebRTC "full" endpoint exposing the W3C WebRTC APIs. Just my 2 cents. Best regards Sergio On 18/08/2014 13:11, Harald Alvestrand wrote: > When writing the gateway document, I found myself grappling with the > "device" description. > > It is somewhat uncomfortable, in that as first defined, it requires > full WebRTC functionality except for the API part - this means that it > should support data channels, full ICE, bundling and so on. > > But for gateways, it makes sense to let go of a lot of these > requirements. So a gateway is not a device. But what is the name for > the thing that a gateway is, a device is, and a browser is, that names > "the set of things that can successfully negotiate connectivity"? And > what are the requirements on *that*? > > I see a couple of options: > > - Redefine "Device" to mean "that which can successfully communicate > with a browser". It's free to negotiate away features if it can, but > needs to interoperate with a browser that implements only the absolute > minimum of what a browser has to implement. > > - Define a new class of "thing" which is "the thing that can talk to > browsers" - of which a gateway has to be an exemplar. > > This is a kind of word game in some ways, but when we make > definitions, we also define what's easy to talk about. And that can > influence what we end up building. > > What do people think? > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 18 04:40:40 2014 Return-Path: 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 123051A03FC for ; Mon, 18 Aug 2014 04:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 u3PNgQTAyxT4 for ; Mon, 18 Aug 2014 04:40:36 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E711A03F1 for ; Mon, 18 Aug 2014 04:40:36 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 370AC7DCF304C; Mon, 18 Aug 2014 11:40:33 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7IBeXfo001769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 07:40:33 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 18 Aug 2014 07:40:33 -0400 From: "Makaraju, Maridi Raju (Raju)" To: "rtcweb@ietf.org" , Harald Alvestrand Thread-Topic: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? Thread-Index: AQHPutcMn/zwsdLw+EKyi2fZO0d6EpvWO+QA Date: Mon, 18 Aug 2014 11:40:33 +0000 Message-ID: References: <53F1DF5E.6030309@alvestrand.no> <53F1E27F.1060403@gmail.com> In-Reply-To: <53F1E27F.1060403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/epkOul9I6GGVQ_Qk-T8MHLERilQ Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 11:40:38 -0000 Hi Harald, How about "gw-endpoint"? in the sense that it behaves like an "endpoint" bu= t has different requirements than an "endpoint". BR Raju -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio Garcia Mu= rillo Sent: Monday, August 18, 2014 6:25 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new t= erm? Hi Harald, I always liked "endpoint" much more than "device". We could have different types of endpoints, and define a browser like: a=20 WebRTC "full" endpoint exposing the W3C WebRTC APIs. Just my 2 cents. Best regards Sergio On 18/08/2014 13:11, Harald Alvestrand wrote: > When writing the gateway document, I found myself grappling with the=20 > "device" description. > > It is somewhat uncomfortable, in that as first defined, it requires=20 > full WebRTC functionality except for the API part - this means that it=20 > should support data channels, full ICE, bundling and so on. > > But for gateways, it makes sense to let go of a lot of these=20 > requirements. So a gateway is not a device. But what is the name for=20 > the thing that a gateway is, a device is, and a browser is, that names=20 > "the set of things that can successfully negotiate connectivity"? And=20 > what are the requirements on *that*? > > I see a couple of options: > > - Redefine "Device" to mean "that which can successfully communicate=20 > with a browser". It's free to negotiate away features if it can, but=20 > needs to interoperate with a browser that implements only the absolute=20 > minimum of what a browser has to implement. > > - Define a new class of "thing" which is "the thing that can talk to=20 > browsers" - of which a gateway has to be an exemplar. > > This is a kind of word game in some ways, but when we make=20 > definitions, we also define what's easy to talk about. And that can=20 > influence what we end up building. > > What do people think? > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 18 04:56:54 2014 Return-Path: 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 C24121A0384 for ; Mon, 18 Aug 2014 04:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 q1-RSpTJmeCo for ; Mon, 18 Aug 2014 04:56:47 -0700 (PDT) Received: from vsp-authed-04-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81DB1A037B for ; Mon, 18 Aug 2014 04:56:46 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-04-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Mon, 18 Aug 2014 13:56:37 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 66CB03A1E2 for ; Mon, 18 Aug 2014 13:56:37 +0200 (CEST) Message-ID: <53F1E9F5.4000105@omnitor.se> Date: Mon, 18 Aug 2014 13:56:37 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53EF5BC8.7060803@omnitor.se> <53F1B99A.1010404@alvestrand.no> In-Reply-To: <53F1B99A.1010404@alvestrand.no> Content-Type: multipart/alternative; boundary="------------060308010700000100090405" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AngQ1t4rrKHTSlBzIttHG0sFMiE Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 11:56:51 -0000 This is a multi-part message in MIME format. --------------060308010700000100090405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2014-08-18 10:30, Harald Alvestrand wrote: > On 08/16/2014 03:25 PM, Gunnar Hellstrom wrote: >> On 2014-08-16 14:01, Barry Dingle wrote: >>> I agree that error handling is missing from >>> draft-ietf-rtcweb-data-channel . >>> >>> Should the 'error' indications' in the proposed text be more >>> specific? That is, should the error indications indicate the type of >>> error. (The same error indication for all errors could be sent and >>> be compliant with the currently proposed text.) >> Yes, possibly more detailed failure cause information is beneficial. >> But this needs to be matched against the ambitions of the WebRTC API >> to be as similar as possible to the Websocket API. >> And the Websocket API groups many error reasons into one error >> indication because of security risks. >> See http://dev.w3.org/html5/websockets/ >> >> Maintenance and debugging might be hard without further refinement of >> error causes, while security is better with less specific >> information. A balanced proposal would be needed. > > The need for debugging is handled by advice on what information needs > to be in the "message" part of the error indication. > > If there is a need for consistent action to be taken by applications, > I think that needs to be in the "name" part - that is, different > errors - or in additional information passed in the error. There are at least the following reasons: 1. Sending seems to have failed ( you do not know, it might be the feedback that failed and the receiver got the message ). 2. Transport aborted because of network errors. (transmission retry limit exceeded on a reliable channel in the association, or a watchdog expired ) ( further error causes appear in the WebRTC API, such as buffer full when requesting SEND ) > >> >> A specific improvement would be to indicate if it is the sending side >> or the receiving side or both that will get an error indication. >> >> I have not seen the association concept in the WebRTC API. So, it >> seems that the association concept will be hidden in the >> implementation between the WebRTC API and the SCTP, because in >> interaction with SCTP, it is important to know when a new association >> needs to be opened, and when just a new channel can be opened in an >> existing association. The effect of the abortion of the association >> also needs to be understood by that layer and translated into >> separate rtcDataChannel API actions. >> >> One further note: I have assumed that ICE connectivity failures is >> handled separately by the WebRTC API implementation and will cause >> both indications to API users and to the RTCweb data channel >> implementations. Is that right? > > I can't parse this in terms that fit my implementation - there is no > distinction between the "RTCweb data channel implementation" and "the > WebRTC API implementation" - it's all the WebRTC implementation, and > there is no distinction that can be surfaced. > > What's the change that needs to be there? Probably none for the lack of the Association concept on the application level. Below the API, the implementation need to keep track of the association and all channels using that association, so that a new association is requested only when the old has been aborted. For the ICE connectivity failure, I want to know if my assumption is right that the ICE connectivity and its indications of failing connectivity are handled by separate API elements, so that it is the application that needs to request closing of channels when ICE connectivity fails, while for retransmission excess and connection watchdog failures the association will be aborted by underlaying levels, and closing with error will be signaled on all channels in that association from lower layer. Therefore, I have not mentioned failing ICE connectivity in the comments to rtcweb-data-channel. If the assumption is wrong, failing ICE connectivity should be added to the reasons for the association to be aborted in the rtcweb-data-channel draft. /Gunnar > > >> >> >>> >>> Note - I assume that you are proposing adding the new Section 6.7 >>> to draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 >>> titled "Closing a channel". I assume you mean a new Section 6.8. >> Right, thanks. >>> >>> Cheers, >>> /Barry Dingle >>> >>> >>> >>> >>> On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom >>> > >>> wrote: >>> >>> We have discussed the lack of description of failure handling in >>> draft-ietf-rtcweb-data-channel a couple of times. >>> >>> Explanations of mechanisms have been provided in mail answers >>> that I have not seen documented elsewhere, but they have not >>> been introduced in the draft. >>> >>> I think that for specification and implementation of the WebRTC >>> API, there is a need for clear specification how the channels >>> behave in failure situations. >>> >>> I suggest to insert a new chapter 6.7 in the draft with the >>> following contents. >>> >>> -------------------------------------------------------------------Proposed >>> new section >>> 6.7------------------------------------------------------------------------------------------- >>> 6.7 Transmission failure and error handling >>> >>> Failures can occur in an open channel by transmission error >>> detection and by SCTP watchdog error indications. >>> If transmission in a reliable channel fails, the association >>> where the channel belongs will be aborted. If all retries for a >>> watchdog expires, the corresponding association will be aborted. >>> All channels in an association that is aborted because of errors >>> need to be closed by the party detecting the failure. Network >>> error indications shall be provided to upper layers on all >>> closed channels. >>> >>> If retransmissions or transmission time is exceeded in a >>> partially reliable channel, the transmission SHALL be allowed to >>> continue with other data items. A transmission error indication >>> SHALL be provided to upper layers on that channel. >>> >>> If reception out-of order is detected from an SCTP channel for >>> which ordered transmission is requested, the receiver SHALL >>> close the data channel, and provide an transmission error >>> indication to upper layers. >>> >>> If a message with an unsupported PPID is received or some >>> logical error is detected by the receiver, the receiver SHALL >>> close the corresponding data channel. >>> -----------------------------------------------------------------------end >>> of >>> proposal--------------------------------------------------------------------------------------------------------------- >>> >>> I am not sure about what the two last kinds of errors should >>> result in and hope that the experts can adjust the wording. >>> >>> Regards >>> >>> Gunnar >>> ------------------------------------------------------------------------ >>> Gunnar Hellström >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> >>> On 2014-08-11 20:13, IESG Secretary wrote: >>>> The IESG would like to retract the current Last Call on the following >>>> document: >>>> >>>> - 'WebRTC Data Channels' >>>> as Proposed Standard >>>> >>>> The document's state has been set back to "AD Evaluation." >>>> >>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------060308010700000100090405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 2014-08-18 10:30, Harald Alvestrand wrote:
On 08/16/2014 03:25 PM, Gunnar Hellstrom wrote:
On 2014-08-16 14:01, Barry Dingle wrote:
I agree that error handling is missing from draft-ietf-rtcweb-data-channel .

Should the 'error' indications' in the proposed text be more specific? That is, should the error indications indicate the type of error. (The same error indication for all errors could be sent and be compliant with the currently proposed text.)
Yes, possibly more detailed failure cause information is beneficial. But this needs to be matched against the ambitions of the WebRTC API to be as similar as possible to the Websocket API.
And the Websocket API groups many error reasons into one error indication because of security risks.
See http://dev.w3.org/html5/websockets/

Maintenance and debugging might be hard without further refinement of error causes, while security is better with less specific information. A balanced proposal would be needed.

The need for debugging is handled by advice on what information needs to be in the "message" part of the error indication.

If there is a need for consistent action to be taken by applications, I think that needs to be in the "name" part - that is, different errors - or in additional information passed in the error.
There are at least the following reasons:

1. Sending seems to have failed ( you do not know, it might be the feedback that failed and the receiver got the message ).

2. Transport aborted because of network errors. (transmission retry limit exceeded on a reliable channel in the association, or a watchdog expired )

( further  error causes appear in the WebRTC API, such as buffer full when requesting SEND )




A specific improvement would be to indicate if it is the sending side or the receiving side or both that will get an error indication.

I have not seen the association concept in the WebRTC API. So, it seems that the association concept will be hidden in the implementation between the WebRTC API and the SCTP, because in interaction with SCTP, it is important to know when a new association needs to be opened, and when just a new channel can be opened in an existing association. The effect of the abortion of the association also needs to be understood by that layer and translated into separate rtcDataChannel API actions.

One further note: I have assumed that ICE connectivity failures is handled separately by the WebRTC API implementation and will cause both indications to API users and to the RTCweb data channel implementations. Is that right?

I can't parse this in terms that fit my implementation - there is no distinction between the "RTCweb data channel implementation" and "the WebRTC API implementation" - it's all the WebRTC implementation, and there is no distinction that can be surfaced.

What's the change that needs to be there?
Probably none for the lack of the Association concept on the application level.
Below the API, the implementation need to keep track of the association and all channels using that association, so that a new association is requested only when the old has been aborted.

For the ICE connectivity failure, I want to know if my assumption is right that the ICE connectivity and its indications of failing connectivity are handled by separate API elements, so that it is the application that needs to request closing of channels when ICE connectivity fails,   while for retransmission excess and connection watchdog failures the association will be aborted by underlaying levels, and closing with error will be signaled on all channels in that association from lower layer.

Therefore, I have not mentioned failing ICE connectivity in the comments to rtcweb-data-channel. If the assumption is wrong, failing ICE connectivity should be added to the reasons for the association to be aborted in the rtcweb-data-channel draft.



/Gunnar




 

Note - I assume that you are proposing adding the new Section 6.7 to  draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 titled "Closing a channel". I assume you mean a new Section 6.8.
Right, thanks.

Cheers,
/Barry Dingle




On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times.

Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft.

I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations.

I suggest to insert a new chapter 6.7 in the draft with the following contents. 

-------------------------------------------------------------------Proposed new section 6.7-------------------------------------------------------------------------------------------
6.7 Transmission failure and error handling

Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications.
If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted.  All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels.

If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel.

If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers. 

If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
-----------------------------------------------------------------------end of proposal---------------------------------------------------------------------------------------------------------------

I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording.

Regards

Gunnar
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se

On 2014-08-11 20:13, IESG Secretary wrote:
The IESG would like to retract the current Last Call on the following 
document:

- 'WebRTC Data Channels'
  <draft-ietf-rtcweb-data-channel-11.txt> as Proposed Standard

The document's state has been set back to "AD Evaluation."


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb





_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------060308010700000100090405-- From nobody Mon Aug 18 05:03:10 2014 Return-Path: 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 574CD1A0369 for ; Mon, 18 Aug 2014 05:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 2-nHujknL0Z9 for ; Mon, 18 Aug 2014 05:03:07 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FBC1A0373 for ; Mon, 18 Aug 2014 05:03:06 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 6C75D38BE4893; Mon, 18 Aug 2014 12:03:04 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s7IC359B029731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 08:03:05 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 18 Aug 2014 08:03:05 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) Thread-Index: AQHPutXPyMc4V+6yu0+BmUsc84RnPpvWPUWQ Date: Mon, 18 Aug 2014 12:03:04 +0000 Message-ID: References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> In-Reply-To: <53F1E05D.9040804@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5176DDUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/jYP0RUC9S6wy8Ux8B50HWJuPtlY Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 12:03:09 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5176DDUS70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Picking up a single point.... On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote: If a message with an unsupported PPID is received or some logical error is = detected by the receiver, the receiver SHALL close the corresponding data c= hannel. This is one of the interop concern I expressed on using EMPTY PPID = without negotiating it. This struct me when thinking about the zero-length-data proposal: If we eve= r want to add another such feature *without* explicitly negotiating the use= of the feature at setup time, we can't do this. Right. I am in favor of explicitly negotiating such new PPIDs. If we want the possibility of un-negotiated extensions, we HAVE to say (som= ewhere) If a message with an unsupported PPID is received, it is silently ignored= . OTOH, if we're convinced we never need that kind of extensibility, any way = we do this is fine. Silently dropping these "unknown" PPIDs may have issues like the sen= der may "assume" the msg is "accepted" by the receiver, especially for the = EMPTY_PPID kind of use case where there is no response required. Also, at t= he receiving side an "unknown" PPID might have been received due to an err= or at the sending side (rather than transit). In such error cases it is bet= ter to drop the call rather than "limp along". Having an explicit negotiati= on allows the implementation to take an informed decision. Sorry to keep going back, but the earlier proposal I made about OOB PPID ma= y solve this issue by allowing user to negotiate an additional OOB PPID. The same mechanism can be extended to allow users to define and use arbitra= ry PPIDs. I am aware that this complicates the spec/API further, but listin= g it here for completeness and further discussion. BR Raju Harald --_000_E1FE4C082A89A246A11D7F32A95A17828E5176DDUS70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Picking up a single point....

On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote:


If a message with an unsupported PPID is received or some logical error is = detected by the receiver, the receiver SHALL close the corresponding data c= hannel. 

 

<Raju/> This is one of the interop concern I expressed on us= ing EMPTY PPID without negotiating it. </Raju>


This struct me when thinking about the zero-length-data proposal: If we eve= r want to add another such feature *without* explicitly negotiating the use= of the feature at setup time, we can't do this.

<Raju> Right. I am in favor of explicitly negotiating such new = PPIDs. </Raju>



If we want the possibility of un-negotiated extensions, we HAVE to say (som= ewhere)

  If a message with an unsupported PPID is received, it is silently ig= nored.

OTOH, if we're convinced we never need that kind of extensibility, any way = we do this is fine.

<Raju> Silently dropping these “unknown” PPIDs may = have issues like the sender may “assume” the msg is “acce= pted” by the receiver, especially for the EMPTY_PPID kind of use case where there is no response = required. Also, at the receiving side an “unknown” PPID might &= nbsp;have been received due to an error at the sending side (rather than tr= ansit). In such error cases it is better to drop the call rather than “limp along”. Having an explicit negotiat= ion allows the implementation to take an informed decision.

Sorry to keep going back, but the earlier proposal I made about OOB P= PID may solve this issue by allowing user to negotiate an additional OOB PPID.

The same mechanism can be extended to allow users to define and use a= rbitrary PPIDs. I am aware that this complicates the spec/API further, but listing it here for completeness and further discussion.=

</Raju>

BR

Raju

             Ha= rald

--_000_E1FE4C082A89A246A11D7F32A95A17828E5176DDUS70UWXCHMBA02z_-- From nobody Mon Aug 18 05:12:29 2014 Return-Path: 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 B942B1A0427 for ; Mon, 18 Aug 2014 05:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 AVJxIxFxiy29 for ; Mon, 18 Aug 2014 05:12:25 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CB91A0421 for ; Mon, 18 Aug 2014 05:12:24 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 08024D026CD10; Mon, 18 Aug 2014 12:12:22 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7ICCNL8027638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 08:12:24 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Mon, 18 Aug 2014 08:12:23 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Gunnar Hellstrom , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) Thread-Index: AQHPutXPyMc4V+6yu0+BmUsc84RnPpvWeyAA///IqZA= Date: Mon, 18 Aug 2014 12:12:22 +0000 Message-ID: References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <53F1E240.3020509@omnitor.se> In-Reply-To: <53F1E240.3020509@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E517746US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AHxd1sC6og5KEFpdaoBpbfCVYcA Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 12:12:27 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E517746US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gunnar Hellstrom Sent: Monday, August 18, 2014 6:24 AM On 2014-08-18 13:15, Harald Alvestrand wrote: Picking up a single point.... On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote: If a message with an unsupported PPID is received or some logical error is = detected by the receiver, the receiver SHALL close the corresponding data c= hannel. This struct me when thinking about the zero-length-data proposal: If we eve= r want to add another such feature *without* explicitly negotiating the use= of the feature at setup time, we can't do this. If we want the possibility of un-negotiated extensions, we HAVE to say (som= ewhere) If a message with an unsupported PPID is received, it is silently ignored= . [GH] That sounds wise, and also in line with the security aspects that make= Websocket be very conservative about signaling errors and their reasons. W= ebRTC data channels have the ambition to be similar. /Gunnar Per the following excerpts from websocket RFC, if an "unknown" opcode is re= ceived then the connection fails. I think PPID is same level as Opcode (web= socket binary and text data are represented as 2 opcodes). Did I miss somet= hing? 5.2. Base Framing Protocol Opcode: 4 bits Defines the interpretation of the "Payload data". If an unknown opcode is received, the receiving endpoint MUST _Fail the WebSocket Connection_. The following values are defined. BR Raju OTOH, if we're convinced we never need that kind of extensibility, any way = we do this is fine. Harald _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_E1FE4C082A89A246A11D7F32A95A17828E517746US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Gunnar Hellstrom
Sent: Monday, August 18, 2014 6:24 AM

On 2014-08-18 13:15, Harald Alvestrand wrote:

Picking up a single point....

On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote:


If a message with an unsupported PPID is received or some logical error is = detected by the receiver, the receiver SHALL close the corresponding data c= hannel. 


This struct me when thinking about the zero-length-data proposal: If we eve= r want to add another such feature *without* explicitly negotiating the use= of the feature at setup time, we can't do this.

If we want the possibility of un-negotiated extensions, we HAVE to say (som= ewhere)

  If a message with an unsupported PPID is received, it is silently ig= nored.

[GH] That sounds wise, and also in line with the sec= urity aspects that make Websocket be very conservative about signaling erro= rs and their reasons. WebRTC data channels have the ambition to be similar.=
/Gunnar

<Raju>

Per the following excerpts from websocket = RFC, if an “unknown” opcode is received then the connection fai= ls. I think PPID is same level as Opcode (websocket binary and text data are represented as 2 opcodes). Did I miss something?

5.2.  Base Framing Protocol

 

Opcode:  4 bits

 

   &nbs= p;  Defines the interpretation of the "Payload data".  = If an unknown

   &nbs= p;  opcode is received, the receiving endpoint MUST _Fail the

   &nbs= p;  WebSocket Connection_.  The following values are defined.

 

</Raju>

 

BR

Raju


OTOH, if we're convinced we never need that kind of extensibility, any way = we do this is fine.

             Ha= rald




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org

https://www.i=
etf.org/mailman/listinfo/rtcweb


 
--_000_E1FE4C082A89A246A11D7F32A95A17828E517746US70UWXCHMBA02z_-- From nobody Mon Aug 18 05:21:07 2014 Return-Path: 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 5F62C1A009A for ; Mon, 18 Aug 2014 05:21:01 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.668, 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 pChD0SQDZDLO for ; Mon, 18 Aug 2014 05:20:58 -0700 (PDT) Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D272B1A008D for ; Mon, 18 Aug 2014 05:20:57 -0700 (PDT) Received: from epcpsbgr1.samsung.com (u141.gpu120.samsung.co.kr [203.254.230.141]) by mailout4.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NAI0085D4YVCC10@mailout4.samsung.com> for rtcweb@ietf.org; Mon, 18 Aug 2014 21:20:55 +0900 (KST) Received: from epcpsbgx1.samsung.com ( [172.20.52.126]) by epcpsbgr1.samsung.com (EPCPMTA) with SMTP id 02.D0.25328.7AFE1F35; Mon, 18 Aug 2014 21:20:55 +0900 (KST) X-AuditID: cbfee68d-b7f2f6d0000062f0-8a-53f1efa7dfd9 Received: from epmailer01 ( [203.254.219.141]) by epcpsbgx1.samsung.com (EPCPMTA) with SMTP id EF.45.11474.7AFE1F35; Mon, 18 Aug 2014 21:20:55 +0900 (KST) Message-id: Date: Mon, 18 Aug 2014 12:20:55 +0000 (GMT) From: Kiran Kumar Guduru To: "rtcweb-request@ietf.org" , "rtcweb@ietf.org" , harald@alvestrand.no MIME-version: 1.0 X-MTR: 20140818121130589@kiran.guduru Msgkey: 20140818121130589@kiran.guduru X-EPLocale: en_US.windows-1252 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-EPTrCode: X-EPTrName: X-MLAttribute: X-RootMTR: 20140818121130589@kiran.guduru X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N MIME-version: 1.0 Content-type: multipart/related; boundary="=_NamoWEC-4v4yag1e2n" X-Generator: Namo ActiveSquare 7 7.0.0.45 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJKsWRmVeSWpSXmKPExsWyRsSkTnf5+4/BBm+nKlms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMvL9rMXvNnCWPHk1W3GBsbv6xm7GDk5hATUJTasvscGYksI mEg8+XWfBcIWk7hwbz1QnAuoZimjxO3mfywwReuPX2CHSMxhlDg37xUrSIJXwEJiy6JP7CA2 i4CqxP1rv5hAbDaghl8n1oBtExbwkViw5ymYLSJQLfFmdQMLxBVKEmuv3oSaIyhxcuYTqGWq EtuPNjNCxNUklm/ZyQ4Rl5NYMvUyE4TNKzGj/SkLTHza1zXMELa0xPlZGxhhvln8/TFUnF/i 2O0dQL0cYL1P7gfDjNm9+Qs0IAQkpp45CNWqJXGj7wPUKj6JNQvfssCM2XVqOTNM7/0tc5nQ nc8s4CTx7GIDVL2mxKNFrSygcJMQ2MMh8fNQI+sERqVZSHrQ2TD9ELahxJd5jxkhbEWJKd0P 2SFsO4nzTSfZUMU5gGxViUVNigsYOVYxiqYWJBcUJ6UXGeoVJ+YWl+al6yXn525iBKaf0/+e 9e5gvH3A+hBjFTDaJjJLiSbnA9NXXkm8obGZkYWpiamxkbmlGVWElcR5kx4mBQkJpCeWpGan phakFsUXleakFh9iZOLglGpgPDLRle3NkUkvNnafktv91X6B5IH2tLj1/NN+y25dVWmu/WtD +rw3y7gntcW89+edUH9qSdKK+t2asappV2sKS5h+zlS3PHjPNCL+1IyXYh59Pc78D1KM4qeu Tn2+7E2b7kw5x1SnEzafjPS045dfTzof/8V8U6o6q9j0vRsu9fl0XHE/vf/VdSWW4oxEQy3m ouJEAFuZ05psAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKJsWRmVeSWpSXmKPExsVy+t/tXt3l7z8GG+xrlLBY+6+d3YHRY8mS n0wBjFFpNhmpiSmpRQqpecn5KZl56bZK3sHxzvGmZgaGuoaWFuZKCnmJuam2Si4+AbpumTlA U5UUyhJzSoFCAYnFxUr6djZF+aUlqQoZ+cUltkrRhuZGekYGeqZGeoamsVaGBgZGpkA1CWkZ l5ftZy94s4Wx4smr24wNjN/XM3YxcnIICahLbFh9jw3ElhAwkVh//AI7hC0mceHeeqA4F1DN HEaJc/NesYIkWARUJe5f+8UEYrMBNfw6sQZskLCAj8SCPU/BbBGBaok3qxtYIBYoSay9ehOs l1dAUOLkzCcsEAtUJbYfbWaEiKtJLN+yE2qxnMSSqZeZIGxeiRntT1lg4tO+rmGGsKUlzs/a wAhz6OLvj6Hi/BLHbu8A6uUA631yPxhmzO7NX6B+FJCYeuYgVKuWxI2+D1Cr+CTWLHzLAjNm 16nlzDC997fMZUJ3PrOAk8Sziw1Q9ZoSjxa1skxglJmFpAydDdMCYRtKfJn3mBHCVpSY0v2Q HcK2kzjfdJINVZwDyFaVWNSkuICRYxWjaGpBckFxUnqFoV5xYm5xaV66XnJ+7iZGcEp7tnAH 45fz1ocYBTgYlXh4F7z9ECzEmlhWXJl7iFEFaMyjDasvMEqx5OXnpSqJ8HK8/hgsxJuSWFmV WpQfX1Sak1p8iHEiIzCSJzJLiSbnAxNxXkm8obGJuamxqYWBobm5GS2FlcR5795MChISSE8s Sc1OTS1ILYI5iomDU6qB0dNnNnfL7gk7d9a5e7f3aJtOvLnTokOS+2mzZMsRR08f889eK+d0 Hnx9THeTenC9VjTjNnPTw8WWxpHHGxfHT5OSuKk1OzPE7H1U2rm9hUdf9F+NYDq/wSxoEfeC 1eFWof1T14Y2ytfOWcCcpt/+cJvxmWkX4rl292r11EsHSl3VD3dXn+qpxFKckWioxVxUnAgA 5ehUjegDAAA= DLP-Filter: Pass X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DJDq4R6sedTj0tINvk2agjeEUhE Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kiran.guduru@samsung.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 12:21:01 -0000 --=_NamoWEC-4v4yag1e2n Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0x MjUyIiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxTVFlMRSBpZD1teXNpbmdsZV9zdHlsZSB0 eXBlPXRleHQvY3NzPlAgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBh cmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4OyBGT05ULVNJWkU6IDlwdA0KfQ0KVEQgew0KCU1BUkdJ Ti1UT1A6IDVweDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4 OyBGT05ULVNJWkU6IDlwdA0KfQ0KTEkgew0KCU1BUkdJTi1UT1A6IDVweDsgRk9OVC1GQU1JTFk6 IEFyaWFsLCBhcmlhbDsgTUFSR0lOLUJPVFRPTTogNXB4OyBGT05ULVNJWkU6IDlwdA0KfQ0KQk9E WSB7DQoJTElORS1IRUlHSFQ6IDEuNDsgTUFSR0lOOiAxMHB4OyBGT05ULUZBTUlMWTogQXJpYWws IGFyaWFsOyBGT05ULVNJWkU6IDlwdA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgbmFtZT1HRU5FUkFU T1IgY29udGVudD1BY3RpdmVTcXVhcmU+PC9IRUFEPg0KPEJPRFk+DQo8UD5IaSw8L1A+DQo8UD5J IHByZWZlciBXZWJSVEMgImVuZHBvaW50cyImbmJzcDsgdG8gImRldmljZXMiLiA8L1A+DQo8UD4m bmJzcDs8L1A+DQo8UD5SZWdhcmRzLDwvUD4NCjxQPktpcmFuLjwvUD4NCjxQPiZuYnNwOzwvUD5X aGVuJm5ic3A7d3JpdGluZyZuYnNwO3RoZSZuYnNwO2dhdGV3YXkmbmJzcDtkb2N1bWVudCwmbmJz cDtJJm5ic3A7Zm91bmQmbmJzcDtteXNlbGYmbmJzcDtncmFwcGxpbmcmbmJzcDt3aXRoJm5ic3A7 dGhlJm5ic3A7IDxCUj4iZGV2aWNlIiZuYnNwO2Rlc2NyaXB0aW9uLiA8QlI+PEJSPkl0Jm5ic3A7 aXMmbmJzcDtzb21ld2hhdCZuYnNwO3VuY29tZm9ydGFibGUsJm5ic3A7aW4mbmJzcDt0aGF0Jm5i c3A7YXMmbmJzcDtmaXJzdCZuYnNwO2RlZmluZWQsJm5ic3A7aXQmbmJzcDtyZXF1aXJlcyZuYnNw O2Z1bGwmbmJzcDsgPEJSPldlYlJUQyZuYnNwO2Z1bmN0aW9uYWxpdHkmbmJzcDtleGNlcHQmbmJz cDtmb3ImbmJzcDt0aGUmbmJzcDtBUEkmbmJzcDtwYXJ0Jm5ic3A7LSZuYnNwO3RoaXMmbmJzcDtt ZWFucyZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO3Nob3VsZCZuYnNwOyA8QlI+c3VwcG9ydCZuYnNw O2RhdGEmbmJzcDtjaGFubmVscywmbmJzcDtmdWxsJm5ic3A7SUNFLCZuYnNwO2J1bmRsaW5nJm5i c3A7YW5kJm5ic3A7c28mbmJzcDtvbi4gPEJSPjxCUj5CdXQmbmJzcDtmb3ImbmJzcDtnYXRld2F5 cywmbmJzcDtpdCZuYnNwO21ha2VzJm5ic3A7c2Vuc2UmbmJzcDt0byZuYnNwO2xldCZuYnNwO2dv Jm5ic3A7b2YmbmJzcDthJm5ic3A7bG90Jm5ic3A7b2YmbmJzcDt0aGVzZSZuYnNwOyA8QlI+cmVx dWlyZW1lbnRzLiZuYnNwO1NvJm5ic3A7YSZuYnNwO2dhdGV3YXkmbmJzcDtpcyZuYnNwO25vdCZu YnNwO2EmbmJzcDtkZXZpY2UuJm5ic3A7QnV0Jm5ic3A7d2hhdCZuYnNwO2lzJm5ic3A7dGhlJm5i c3A7bmFtZSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwOyA8QlI+dGhpbmcmbmJzcDt0aGF0Jm5ic3A7 YSZuYnNwO2dhdGV3YXkmbmJzcDtpcywmbmJzcDthJm5ic3A7ZGV2aWNlJm5ic3A7aXMsJm5ic3A7 YW5kJm5ic3A7YSZuYnNwO2Jyb3dzZXImbmJzcDtpcywmbmJzcDt0aGF0Jm5ic3A7bmFtZXMmbmJz cDsidGhlJm5ic3A7IDxCUj5zZXQmbmJzcDtvZiZuYnNwO3RoaW5ncyZuYnNwO3RoYXQmbmJzcDtj YW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtuZWdvdGlhdGUmbmJzcDtjb25uZWN0aXZpdHkiPyZu YnNwO0FuZCZuYnNwO3doYXQmbmJzcDsgPEJSPmFyZSZuYnNwO3RoZSZuYnNwO3JlcXVpcmVtZW50 cyZuYnNwO29uJm5ic3A7KnRoYXQqPyA8QlI+PEJSPkkmbmJzcDtzZWUmbmJzcDthJm5ic3A7Y291 cGxlJm5ic3A7b2YmbmJzcDtvcHRpb25zOiA8QlI+PEJSPi0mbmJzcDtSZWRlZmluZSZuYnNwOyJE ZXZpY2UiJm5ic3A7dG8mbmJzcDttZWFuJm5ic3A7InRoYXQmbmJzcDt3aGljaCZuYnNwO2NhbiZu YnNwO3N1Y2Nlc3NmdWxseSZuYnNwO2NvbW11bmljYXRlJm5ic3A7IDxCUj53aXRoJm5ic3A7YSZu YnNwO2Jyb3dzZXIiLiZuYnNwO0l0J3MmbmJzcDtmcmVlJm5ic3A7dG8mbmJzcDtuZWdvdGlhdGUm bmJzcDthd2F5Jm5ic3A7ZmVhdHVyZXMmbmJzcDtpZiZuYnNwO2l0Jm5ic3A7Y2FuLCZuYnNwO2J1 dCZuYnNwOyA8QlI+bmVlZHMmbmJzcDt0byZuYnNwO2ludGVyb3BlcmF0ZSZuYnNwO3dpdGgmbmJz cDthJm5ic3A7YnJvd3NlciZuYnNwO3RoYXQmbmJzcDtpbXBsZW1lbnRzJm5ic3A7b25seSZuYnNw O3RoZSZuYnNwO2Fic29sdXRlJm5ic3A7IDxCUj5taW5pbXVtJm5ic3A7b2YmbmJzcDt3aGF0Jm5i c3A7YSZuYnNwO2Jyb3dzZXImbmJzcDtoYXMmbmJzcDt0byZuYnNwO2ltcGxlbWVudC4gPEJSPjxC Uj4tJm5ic3A7RGVmaW5lJm5ic3A7YSZuYnNwO25ldyZuYnNwO2NsYXNzJm5ic3A7b2YmbmJzcDsi dGhpbmciJm5ic3A7d2hpY2gmbmJzcDtpcyZuYnNwOyJ0aGUmbmJzcDt0aGluZyZuYnNwO3RoYXQm bmJzcDtjYW4mbmJzcDt0YWxrJm5ic3A7dG8mbmJzcDsgPEJSPmJyb3dzZXJzIiZuYnNwOy0mbmJz cDtvZiZuYnNwO3doaWNoJm5ic3A7YSZuYnNwO2dhdGV3YXkmbmJzcDtoYXMmbmJzcDt0byZuYnNw O2JlJm5ic3A7YW4mbmJzcDtleGVtcGxhci4gPEJSPjxCUj5UaGlzJm5ic3A7aXMmbmJzcDthJm5i c3A7a2luZCZuYnNwO29mJm5ic3A7d29yZCZuYnNwO2dhbWUmbmJzcDtpbiZuYnNwO3NvbWUmbmJz cDt3YXlzLCZuYnNwO2J1dCZuYnNwO3doZW4mbmJzcDt3ZSZuYnNwO21ha2UmbmJzcDtkZWZpbml0 aW9ucywmbmJzcDsgPEJSPndlJm5ic3A7YWxzbyZuYnNwO2RlZmluZSZuYnNwO3doYXQncyZuYnNw O2Vhc3kmbmJzcDt0byZuYnNwO3RhbGsmbmJzcDthYm91dC4mbmJzcDtBbmQmbmJzcDt0aGF0Jm5i c3A7Y2FuJm5ic3A7aW5mbHVlbmNlJm5ic3A7d2hhdCZuYnNwO3dlJm5ic3A7IDxCUj5lbmQmbmJz cDt1cCZuYnNwO2J1aWxkaW5nLiA8QlI+PEJSPldoYXQmbmJzcDtkbyZuYnNwO3Blb3BsZSZuYnNw O3RoaW5rPyA8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0hhcmFsZCA8QlI+PEJSPjxC Uj48QlI+DQo8UD4mbmJzcDs8L1A+DQo8VEFCTEUgaWQ9Y29uZmlkZW50aWFsc2lnbmltZz4NCjxU Qk9EWT4NCjxUUj4NCjxURCBOQU1PX0xPQ0s+DQo8UD48SU1HIGJvcmRlcj0wIHNyYz0iY2lkOlo1 SkU3RVVBQkdGQ0BuYW1vLmNvLmtyIj48L1A+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0JP RFk+PC9IVE1MPjxpbWcgc3JjPSdodHRwOi8vZXh0LnNhbXN1bmcubmV0L21haWxjaGVjay9TZWVu VGltZUNoZWNrZXI/ZG89OWE0MWNlZTJjNjgxNmJhYmFjMDYzNTAyYTA5ZmQ3MjI0ZmMwMmNhZTRh ZTk1OTZkNTJjY2FhYTVlNzhkNzkxN2E1ODZhOGM5OWRmYmZiYWIwZWRiZTY4M2M4NTNmZTcxZGI5 ZmRkZGRhMzNlODJjYmU0YTM5MTQyNGU2MmZjZjZjZjg3OGY5YTI2Y2UxNWEwJyBib3JkZXI9MCB3 aWR0aD0wIGhlaWdodD0wIHN0eWxlPSdkaXNwbGF5Om5vbmUnPg== --=_NamoWEC-4v4yag1e2n Content-Type: image/gif; name="201408181753773_BEI0XT4N.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhCAKQAMQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5 uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEA ABUALAAAAAAIApAAAAX/ICOOZGmeaKqubOu+cCzPdG3feK7vfO//uYBwSCwaj8ikcslsOp/QqHRK rVqv2Kx2y+16v1YReEwum8/otHrNbhcX8Lh8Tq/b73al2M3v+/+AgYKDVniGh4h1egyEjY6PkJGS k0OJlpd5SXsBDQ6engwNjFKilHoNSaVYqkisTK5CoUqdo02waLJMubGogg6Nt1S/a3IIeAoJmHAJ CnTIipq1EBETFBERDRHDUdqmSQ8PSd1GENzbR+NN6UPgqRPYr+Hrae1MDhFE94MUfA3hRvOKlHPC z8xAIXIG4EFQAJGBOQWMzWEIDckmIfqEBFR3zhuWgk82DhGJrmOAekcy/zJpR5IMSiUqA8T8A5LN yyc1l+QEU9MSxUMKD/2cs6iIyggQKExAxSCCtVoBmlKgIC/pBEZSIzBw8I/ryWr/hDSYRjUpvq9U ozpdGiBp2rZTyzUAO9BqLyHt3IZt22Cs03Jm0YbzS2HgA2sTfj0AixfxNqlsszLqtjgtuAfDMA+p BlgpqgdJh82d8ACpZ7VPiUA4HNlp2tVKHVT7NbewWKUR9kpNy4Azvt6F8SGdIBg1W71C7CY/rTru ycr/kiYlAm620+hxm4o9K5ax5Las+04gvTschL5kD8LFBmFCZ9twp8NlO6S21uJfE7dNygD6+kpx NGTAAQMQkIwCBAxggP+AySTw0AEJPmTAAAU4SIABBiQDIYUKDCVHUflwd81JgJWomlz8UMMABCay OFdyDzBAgXh3OTBjA1T1JsqNS5VG4lxbEVeaCEut1hQ+i/VHHDsPACkbEdrYuGNfFDggI41SXnml jVbyiGWV7CDZYjnaXDmXP+CcNWOY/ly12En3xeLiiKDtZ+dISOLDIicpCucmPuTlFkBiMu61J47g HZnoiFWK4KWPoDkppJuTKkmdVjomieiQ8uHl5o38DKkjW3Vu5gCOK5pIp1YuHpqiJzNeWV+VNjIi ao+shkoplPLE6OWVbyLlKI04bpPQAgU0dICAByiQLLLGUDSAMQMkkMD/tAgMoICzCChQLbIHeBgH iEMc9Ys+a8pIhBg2BiCoumsiqh8F/dUVVkYFaVPqaj6KIBsjvQCcGL0yCTcMfc8ByQmUnpzVTaj2 ZqTvQIntCw7F2/TLSLyvWgyOjEGG6O7BaBbB0rn4pFtTN/qw++pzBb8Y85KrrctIuwT7mHPKeNmr 8b8Lj7OU0HdFxUnF/7yMKJMFC1GQwA7sqV93GMmKKMtIhuPyyBKfw49KUHdzNckjDUYijKXKo5i9 AfQUh0IRLSBtM8tCK3dD3yazgEI/xd3ggOLCQS5GIqLc9lRTEWHfy2037jR4Lx6G+L1qasQV4jlS E2N8TK01MOHuYp6x/3mFFR2lw7+EijlmqNej7+quP6b5xkN0DHuvNZdrsOU3ndw05isbvvjIMN9j I+LanPXS8AWhC3pBkk8V4+ych474PaIPARnSj49TUzv4GpcYkDXFBNLL+rQz/OmWE/H1Wdsb3332 3QkaPVUvUba64wi9bbe0cKBI3CgCobjt7W5wiNuECECAcDWEDoNrWvucJxYiTO1l8MLK19xTjnoU LXwj82BUQtGeqPiDXnsaGcH0MY6iqa8/BLNc1xonwq7FToSx0x4JiUMwdenrH58JB2jWpDviDYor e4EZ1vhnOsNdkHjgS14stqK8vTyxeTz7HV6AOMKxECcUh2mKaIxYtP8U/rB7w/heOMJnxl9wUGQy AVlU0Je1QSWNa6hznwTb6D0yKq5g/KpgPdQGs4XxLwDHGiDeAtgQRS6AGcs6wAH7hoBl0c2BFTnC RSRIPBaucUlOs1WKOigcIZ5lPKgAmqBA57goXcVdoNEaVU4pv2KxSFH9QthlaDmShrVvg5NhneVe VCxVYoY4xRpCzXxoSq69MjftkBEoQeejTSXRd56UyTSXmLOXRbFtnynHmkjjPlHCsi2lRKfjjLnM WQqhYr/BVVQQJrYq1QNiJ1GjBJUGptAUgV4gs9/u0heObuKxfbWTYD250sFQxfMuhLqHwnLzoiex 7JkFxQgi/efIAkj/ckHgWsCyEkCAZgxokg+MyAEegiBMQjAaRilc03DklHO0xz30okY1UEFTIjpF meOZJgi7cVNkIiZGQcWHjaiRG+BMY57UUM/HksqwGY5nRUFV6C+KutWstiWo26ApOXuKCqJm1XVJ bNl4wNS7WQrPGmDqZdNuyh/KrBFJ71jTYsZjqPHwR6z4GM07+FdUPs2Oqr2JKlTdkw/EQPOOvckr de76uKW+Y4072SuKnFJWwx0GNH7NqS+N+M7EnMWyTR3PTxPLWHYc9avjSc5sjFjYQV2FH4mMVkNI ysCGZCtZAiJAAQy0AAZS0lvDxVDgFhDBJpzKCH0xSi22ApUidAIK/9eNxXMxcpfsnsRW3NluSoqm BytxwiT5gIp342iErdyFutA1CcLGOwvylsu+0MVvfGsR3fyuq2i7sO5jxCtemXzQvutNCXbPUSrr vte8reCpfjUJYbF05ML2ha+F84Ff71I3HIh4RhysVQyJLKBDzZgDig3RXI9MYTGHQa+Ln+CXGdsY DIuR8Y2x0B+PiEAZQA6ykO/AJB0bYchITrIcFNAsJTs5yDvOgieiTGUt/BgTzLhElp9siS0X48R6 C7KXtZxiMSNgzGM2hIjn4OU1TyTMSXYzi1NRXezWeRBGhgkYaHNn66q3zyaUQp4DrQmeArrQTbgy HB5yCAMmwtFcbv+0if13AEkKudJAxnSQfwtpSN/hIct19HIN0EAlg/qBiDiCP0grhZtoQTNLWJFO qLATLYQqiSVhWBJm0oRaxxQmu3tCOXitSQYcS9KX8HSkM23pIGsaE89WRrQDNOk7BMUOyqZDtoF8 bUscwXeEaAkrk+BrJpT7CucuwjpIQmwstHvcUHhfoo29aAqJtECWJhBxC7DAZAyoQAcqAIfs1u9H ChxDzoJDwkccoQSSesQLGoAkLYShBBQgxRlS1sQbfm9+N4jj1xJusx+ZoH0T6OKPLJBHi8FASTpr 4P82EG9XqiEKEcAYG5p4xCVEIQedWOASt9syJKTvBBT95SjHULX/Ir5Se9+bQxOqEEsFnvSij0sy siGNaVqTGhY9JRtb7Q/pyDkfF1ZmbVWqTUOXovbupOUvZV9OpwqZNb7KvSDKGWJYq8GW3FhDI4ep HPjsXh53WWUyilHKXlrmGsw00ysjeY7d10NFvnCiHE7VE3rgHrqnKtMasuE8a3RD75SfWebaIqnR CYAsZT3kWXXD0AJkr9KLQ2j2BnBWQ4i7Ujk0sKV761YcstUsbWVrWxE5KUkPiOnfe9RbHZpWcZu1 8ptfa+SlrlvQq3/moMfh5seXPe2VdfGKR0T12Tp9t4xfLW9ZC1sCesjyRd1I8jurWeJ/fe6z9f5m ydzk14IAFJF//60nUqhmJ7c0J2KCgGQCAWJkI76SMFfxJEPyJK7VCUJyH+QRKEg1PeEwPvSyGP6g FRSYK5P1OEnSLpziUCHzJhbUTIXRFAXlgIJya0dUK4dCHCqyJ9pwJqhSRK7CQvyQOyg4gSyIFCxk ODxoMFkyIyuoOLQSK/TigzE0QsfSe7NXaYwmSR2lW3vTIHDDEJZmINqCQLJ3cwzHSAfEcovmUrUn Ug+hEJWGAKx3N1gIfnXIEMuXhUt2YtoHB5W2hye1DHnofin3PxoHLXdYSYwGOClFLQi0LXIThsPX SF4YN3lDiT8RFH7zc5LEN3gDhog4LhyjRIajMlCUJlIEDkBTVv//oEsUUzIWmISziA2vZCXZNChg xycnSEN3VE/npIs3gRU6k0opY4y+KDNWsjWr1DFsAzpbww/WsIsJdU/EsxVJ+DvgdVAj0w3qokc2 9IxWSGkDUI4SF21diEDXFoYGFBFBQRGq120/AUDF8EBz+IjFZTdyGC7mSCGaFhHZYo4RYY8jp2/P EhT3CIjN5iHrOIqYplKWplL96IaQCI8JInBCh0Dp2JCOtIYKVCClBopreEAdyVznY4q/gzmdhBQw JkSkcx7WMxWjwzuU1TRRgjlSVESuIZN9xDS+iEbzcz1t9Q5ZREHOw4rccTRwZUS2MzlFNDyJ4R7t okfWmA7ZaJT/TIg6PZlQNrQ/U3SFlqYh+TaKjlSG3gItBnRzZfgTF8JoAZSHi1SPCklJ01eG+/gT 27KIeNkhBMlwyUCPCSlSC/lA69cMZ+lID1lJEamYy4BA+ohAaEiSJiZAl0gthqmJD8SJlYRymCaS ZomZpKhBKElBQUMboAd6MANGQzNGPnlGtciN/nJalddCTNmLNtg4fUSby8MWWLlOPIOUVfNE3tgx XFRETzQNuUEN/1RISuNL3AQ67NONv/CNXNk6xfmV/kNSzeBRy0eHZHmJklQ3b3gtuKd79VZt37Jy 3TaJyWAgdAkhjLaPXwiH1xJ91KIhcdgMpfaWCRSXnamfI6ct/+63cuLphYm5fAGoneBCl55JN5So hulIoJbomJrZe8AnkhI6ioIjUKOZThZ1MDqYM2nyTlzxG1X4JtbkNK5IPHolTsOSPiZaL/lEHcN2 m/h0GHAyR2KXD0vCKOZRUD/6kwA1IwaFFDnagxhVRAYFYzaiHj9JQx0EAdnkI4LyVNGpLyYIjqgz UWGhaMVVUqTGQIuWIMaQjvBIIenZLQxUagiiIIS5npPIQM2wnnTIQKeWQMZwfXAgnyf3LfqGhn1a cy3ne3bKeggZniBZkHaacgKXDIjJhd0SpmgoqY4ZN8YVXBdSLfT3nYyaphSKp8jVll96po2qocxF VvlUGm9VU/9G9FMlBDOIpVNSFVQu6SlX9VWXw1n5gSI06FeLVRM09VPWyFr80BS+ehNBVUKI8UrL SjvtoFmwlRTZsFadBVtCpSehRSW+kkQ2ClUzog9LNSKClZXtIx05MR4zVFvYqXDClwCTJnyJsGJv Boh0Y49uKQfuegd6WG2WsGJGBwfEdWLwCmZ1MLB1IGfLEGbyiggGm692sLAkFmQLewgLW7EG+1Ia xgn4lbFOUGAF9hwfu2HlghUV1l/nxV35QGFLgGEwUQv0sg0vmwrdRV7olWCKM2FOwLGExgtLoBlL oz0Vpjgd4aXLhgcQQiA4F5mXsFxAhiALUodFG7VSO7VAFgj/rlZly6lHWCsMs+SkUUC0VDsHcxhA /IoI/+pkRtdkYbu2bNu2gTBlW4sE1xS3wnC1ULAJuxBgQgtdgIZEYJC3OGsEnxC0W6C3WsAKnTC4 h8azMPExXICNcFu4gdtegwYgIwZnbftIZXYMmMu5dUBiZbtpSztkz5Bmn7stnXuwqZsHm6ASxLZU ACFj17AYXhsGHWQenNRr16CrWzBsSbkF6TAN1XANk/tuXwFai9uz2xCut6oJtUsOudsEItgKezEH F5K5jwSpiDBtC4FqctCZTwandRAuIwlklEkH9wotTKtwDzJyLNa64fW7WwQFPjJPlduxSZluSAAS DZYF+msF//NgvL9Gbr1AhFNglSKCa3A0awe8SkbwEvg6XNibmMu2XNy7ttu2tN47B+K7vo55CSNU RNQEHaMxPdLDF150EAjzXP5BGEMUWGSBHWwBFhczjZjnFPfhd3HyONBZQtAha2qhlHKRHusxFkIM eKlRH3y3efAReFMjwilceJmHGjvcNqNQCt8hFVGaGLJhG3vVCyrBEiWkHIyhHFpcxHLBGUhcxYOi HW7XJJO3UQppABIRc+5qaZUUB/8omAnickD3UX8zc/wGcCSnIA7XQAdgccD1cwPXpiA1YirHhYV8 cS9HXCRlyODij3KKLFlIyC93jgxkcfVGXHZ8sBHCIJdcfv89R2oVV6dB53Ozd8mVtnGG7CAH9yHw W0SagkLn4SpcA1AJVQQycipLISU4glSdkCMhuCsiCA7FpCcm8nZ7wb/itIxSeCZnw4FNSCW+xIFt 0ysWpBjacM1nwiUDXCupwotGMiJ7kkLJQVHKNCa9wRWvxIFzsTmcVIOKwcw9siu3BILd7IHfHIwY UQ6vdESo4iKWW1xGx2iwVyGc2GyaJoclRZ6yR56KpADm53rTd3/Bx2TNIoAgRYADYp7ft36fGFIe VTe953yf6H+vl9IPjXskR1LFJ1IldXszjb7UZ4krx53YIqAAKXHo94gQkrYd3UD8Z4iCk8sjjIJa czOvMhP/mRUxleNMMEI0BNU46MJT0ji/tXMNO+U4FlMzFLUkxpNH7yMzOgPWFdQfOTkxJHrO8CPV VpyjqEijp4GKK1QyyhhsMmENOsXDWh1sS9HXXG2LeJFFL1EzNaOMO2q5y4cgeAqZhanHliafBySJ 2eKQ2ssQ3mmAa6hpqjefZ1mGdUOIbUiSEyfaqAuXHolzMu2FnE2JD2ogJZkQ9YqWrY1SeBrajvjb GreHK0WXTV0LrltHP7k+o1U70xXZwNlKo5UmorPV8naS0DPNnxDM9yNMRog8M/Q+GUFBLyE512BD /xDAp3UWzPM8KtleewI8hwQ+OElasuEJd5Evw8A+O1kl/zkh3utN1lb0DowVExAcQBRSqog5IN47 0YK5p5MMmhQM2oTpn2OY2f24hkPxE+BLUivnLL8XkOUYl3EDvo6UyrYtdAPphXTwjpbo4ZldqQJI kJREQC5F4ZV93Eqsy3fUDmQ31b+bDrFk1YQ93apaQdatjXMk4FqrtSJUKMSREbH5SwXzmtmtxMaI 3gglwhlxRc9TH+UCSqSJCs0ji3Vt3/Kr3ySajQtT5olt5W49F58gb3F04AuKACd14gpSkDHu4JEp 4Z8dEbB9qKIN4Y3p4pWokAf0l/yGuqS2l7H94KC5nymelqD9wcdGmYwehzL+E8GtvhoX2jiekSFc O71gP/89XlDmFJ1hjhXjcxU6MlSwggryFOt1JG8ceuXBrLXG5C7NGE7h/TsrquvapBFx7QlGdWEB ftc4WqUeOk1xVSeC8qGwdE/hhOZGAD2BJW/1K1rndN3D7tZE+DDDEk2o4D+q3ZECt7m919kOjtpw E56JWJaOmtKCWZ8BIkneuXKPvKftmdI3x5cnddr4Gekm7oXw/ph1g9G0DWf8boloCEA13n7uyXre MuOSXu90aQyl7ilMZSupHq2ixWvtcR2y5R6VJ91Zh/Ksxas+blqGtSbEfkg8bK2N0QuLwVlWBfN7 xaxubVvuAfPEw1V0ffJ/5Vgxfw42ElQAA1e0cVb/kPP/a9Iew8BrT7NWpumABJ7GsWVb6cP0TP5O d1En0PpZ7QCI3qstHZnakJwsmq0QYToh0bfIBLIsBrqmc6qQBGKO3SdwebqmDb6mKX1yDXQtwxWe wvUtminpoxj32vLoCoEgZOrZ+Ar4imhzknSpv72mjAb43TcgiC+nDMpcm+RetjC5FlY0NhtT6yVe HlZhOksKOkYLFlGylRuy6YVdAEaz+PWxrl+zFYb7SPD7KCuyUWH7VGCyJosJg7hkoZuw+ApnEctm z+8MZxYHCPtInSuvHRJm7rq5WgZn1z98q8tkKrb98DqxI/auZeawy/D8ktTxjSDAdFv/9n8EhkBq 4I+9//wPAos4kqV5oql4KKr7wqlyLAHDBLm+873/A4M5xkNoPCKTyiWz6XxCo9Kd65CIYbPaLbfr /YJdNkZYlGiV0yTEtYSInU8JBLocV8feWb25ruKLAOJxCboUqtxxJZosdi3GCR6eFNo05DQ44EA5 TD01aB4xWOrcpB3QDJYZEKAuHLwNxBQUKgwUtH0l0MymjryexGYFr7Se/A6LIPcKwxxn8cYYlECT /FJ7nVbTKMcqSKso1zhE2FBEjD5RdDo9FCGN75Quz2td84bvFZgWL1974ae4R2+gCH+pAE57Y3BL NhP4EOgDZyIAPHhS1K3L6MPiEDK+BhC4oqCArRYGDv+AnIMKwaldKAu0eGkA14IEBAZ8K7DKFyp9 NkvWvPltxE9pKEOuSIkTaNESM0/d3IVzgYGUrqoiOAkSwc03I0G+IsBqJlWrUFk5ZSq04EtXKX8i 1XcWVVWkZatqW1DgZZ2jCZbC1Ot2ajWrXwNrJcB1wJvEixUS08tXcNnAcHWl1HfYpF8SM7/aTTq1 6q1VBsj69bs34kgSe20V3Fn3yoECYmlkW5pT72ird8NRJBeBAoQh5GyQazCBeI7j7XYQN4dDOYUJ DR5wCoA9AITq6LR3d0C9OMUJE9x1t679QQRNED4Nb29jOYTjHYmGPECAqrTTevef9hdbubn0lwII MEb/AisKoMVYX6jEspdkCywo4QgLVsiCCCOxMIBLFLJgYUEsEXDgfvrpApN+rgRWgD62zaCPfwIG OIt+M5xYIoLVwKQTiAxuU+BeQLK4QCw37libiSx6gwyBE244pIcTxjLAGaHZpAuA/Unj4n8x6vVi ibUZGdmUEh7ZozRoKSklf296SeYINso1lJFXJvAXAggqMBIb+ZU45CxIHWAnThwaSYeSKyJ54jYG IHpkfjBxxSReJQSnnXo5qPdAcecxcF4AGD2nAwVFRFCEqOx5yul1EzDgwAQ7sIcDqKkGMIEDDlBA RHuyrgdBEcpxVxwExhYXgX1j+PLNNlcIaGEsitUy/8M2xBQqgmL4BaKPMg1FSAO0+y0AEbflvgiI QK5YQa65c7IEIbpQ5tfTG9mY22e5R+6SFSqKgeuaV392Wya7er0hEpn8JkNvArwIyJPBDY048bVW 1lSNs3fWFOG9NJjLC77emlkyLwcu0AKYAmEc7RvvjkimviO03PC7Nm7Myyz+bUvzFeYGYyHA8ub2 M8kh//twwsBVtOyxue46a6akupMD1TbYUKs6wArrqg7PARscsRQFgGuu12FHTqsUWMKAOr1qt6w8 B9NcNzRHniTXtew2RM27QJcQsE1oITiA4RHNO689sBBT+OECBxyyHjbae7C5P5F08CzQUN4wvCP8 Tf+y5vfe5CXDZZJkOGN35xUMxQhbXKZ+17w+jMeWp4t77K5fSztIXrJs98uIIzzSgtUQwPrN8QqM cJbcFBz05MzLvjfgIau+uh5Mk8NRAMo1sPVx8Fxtag7PPVCdsme3OhwF72e3HkXvvx+B9+7D347b ZXNC//uj5sB7c2vINlR2uzL95SQH4122KMSHSs3rW/IymgHeNbNyuSt3n+OdBf3QuTJJTlvUExnI 9NEzhm1OD0PzXMXmAEHAja4WRqtew6BxBdZJjHfN02EszlCbVhDQSAaE3ciIWMLdmSxhf5ohy4bI C5gVTwEJ2AlRYnSt5QVRZ28ggH9IEAwYQmOFNPz/4tE0eMPtTaRpPJjA08JGvvNVDYDrAV+mjqUr /l2CVkWwyA0skgn75fE5qYIbRr4nRwF6JCgYnBCZfCSnm5SMXQZCECAwhqbASWNH2wIabQx1w37t 0EydhJy8zEUmAfXtYxGMCQpZ4pPTOcko0rDk3rIxCwiajm5pStkAZmAUJ9WyGOsqWomo0gqbLFJC jVRlCItISyRmq1C4zF24ivRE4u2MBrXAD2dAGJFZILNSWiyLIKakQNe9UpcL/FAsTKmZXkazG7jI lPe4Q4HssK1sRcin2awGx7CtTzlSY085QFGqfK7tBmwjqNuIUIQHTOA4uAIWruoTj0RSpSsdI8kN /8ViFznlJjJH6VkgQFJMZfzFRUeyxbZegjHQmbQF11jFjg7mUpp8sJ2a8ShuKlfEVXDRSiipDR14 qs4RMIij+xJLC3RIU9twcT+wTBlUpZFUSOYwMiOgKQ8zahuarCJBKbUkM3P3U7FccoEpSx7GPCob xfTQFmRN3IhSipatJg8pYlleRhP01JeFg6Un3ZBRA5abvDa1Y5Cq6lpto9MR0HNZ8/uaeWDFHfP0 U47PqSwEpGYO45iHPHA8nzkQGlrknPY54XNH+IbDCYFG9KJuqMOB0HDLOigwBbrQFk1qIokNAaK2 SKUDI35brt4C1w95QC4iaJKnNTC3BMI1g3HZcP9cGFgXdISIbrkOQdzkeuG5LphuufyQ3ZR99wUH Qu6ehqvcQNThvA30Isomwd3hFjcQNJGEEFqlA0zsoAHfAUImgiCeIMQKFALewYERXOAhDJhZsgDE Kt5LgloYwDYE2TCHO+zhD4M4xK4gad1EPBEgQDR+GllxJ+b2Ag354r4bOoWFTWzjG+M4xzouQ3tN wA8bG1jFLB4yFG7QA1HEI8JENoKQEaxkIHxiyQaWsg+Q/L0m88DKQ9ayk5fMCS4nAcwQ3ggUFkyK J1P5yGhWsxKw/AQkRxkJYjaCkXVQHO/VM81AKGQQ7ixZIQBSzzzgM5X9PL8/2zlTRM7zRhC9DnX/ lGoJkdajDwg9BNFWuTiTnrSgG01nTcfRCJbehHCwjGkdMFoIdfZnqjsdhVG7egmwHjKfOT1oRQ+5 1Qx2dEZsfQRf+3rUuoaHr2P9BF3rWdfC5jUQVt0d+0WUOQ3QNH14ANE7jqc56UuVeXAwSG5b1jmo 2ra3kcMcTUnn2dM2t3yE5Z0dvGfawzk1RE/1vc4eqzuiqPa02diDb/vTnpvqjrSXI596x1He50a4 Pc/xHvOUygFVe7as5n2+5cSRAcNRj8alw530cZw+yal22TqLavPYWz5lA0XH2w1yWd3ze8tRj9oS PnNLfHs66kv4zmV+boykxxIYF/h3MM6eoT+H/+AZtzi6h1WfUz373sPx1GfXzR0BP70466YOet73 qVOpluQ53wE53K2r5XDC7DD/cnxwECrilN0S6Uv3Zxk+DokHMNRVVvA9eWUJtpGvf+hw26ty9QCN 7/Pw/sbVqUKVrH2ONuWQP1aoMsHPB4RvV2VHVtnUtiz7+Z3wpGAb+HjlbQjYSvHY6RUoTIV6xmuK CLOqVagagKtUEZ6OAWQb4d0mHutkfhwMOFb4tP3fvueT96TfVNzAU6znr4+gwtI4OW61zwfPD/PW 6drYcvC0p60vArAi6B0JCuk4lp8ckoea29BveVUdHvYQlb2mXkV/ykocVsBqh3JiJTXvo56u+P9e 6ZFe41mH361W7VkE6CkfJlSfePQK7VkHRKGN4SHeqIwbdHRe2YyfcAhHBz7f98VfqTWUPmVe7h3g OWBEZv3AqgHQAmreqFjCd/iX9p2P+jUHJzzHCuog5MnP1bwNDhzYDMIe+cygOgDS/cQgHp0PeQgL DMpcE6ZaPr1RoHGczI3DsDjfx6GaREmcE0IesamK5bWe+OSgf3XNDY6BDJYDHpEPDrDH2LwRg0nN E87K05hK2yBhD2ZK25if/PxX1uDgHNVh1YyNsMghDlqhAzIh84mhP/GfZX0H3IgHGqZNwIHecfAg DHLiOUhNgU2Hrojh2PwhIPoTIIFNqcmPEbb/IdwQFCBNh/yBITwIINyoWhkqWiZqSqCNVgCNzyCi og8Go2b54A7KkZ1Vh6iYYSHtIa7xDxSSFv1cohv+4hT6IgDhzz11nHn8Hq7M3ftUDQyWijE+oqcQ lAaKo/9UjcaByqj4DzUekv34zyB2YeTpntW84zASW/3g4KbxIzFaRKQF5OrRjyL6TwxmY/w8IgAl HXFMIqWth0VsoibmYCdWpP3IzcaJYs350SBOWjOmIh6FpP+8zTUCUnooo3aoI7EJC7ORAi5a5Cew yte4A3Z8IjDyIQ/+YOTxJEZU4sGFofq5XTMqITQCoiVAoRth5A/4pCJmhyXgof0gZQQIC2vt/9oZ guEL1tz3EEeomSH/lMp33EC/HSPOccIc3t1xGBmhWUTX2NGt5ZE+euJUMqQhqscctsNA1mNEqiUO NKMhwUOgfcdCnt/3EIEtHtJ1zCJFPiNj6mJjXqQfDR956GJe3iQxaqBciuQe0ePfmaTEAWVd5hE8 hE8a3iI6euE49B8XXsKsAMvlydEw6uQO4lwxQh4gpUqrhEpQ6lPzJeHnLSEvyoq3TWOgXZ5FxJnV FEHXQJom2t5r3ZMAqma4haMX9l/taSUgLkfrZSf/rGY/dc3+TNSs/GZvWhRCFQdb8t5dnpsOjOdm BgdA9WM4Ss36AKHQxVE+KaPcpWfzKaDnzf8HOhDmepzjHeWgCcLKf2LiEm7irPieRbIe2wBS8G0l bJbPKfJhYGaocOwReS5nqelmSg6nPi0gJZ6mDnBjapZdRDHfZcXctVnWbAojH3ZWRNkmAMFWOYjf 06QoVw6HWTrjY/LiZZlHLmYHjMaKF0IHi/rlfOzoodkoRInfclbWVeJRjaJerujKVjbfGm3pgdbo //moqLRWzJUnbKlNtHkmHYaWJuRTgJUWJ2gmZ81KYaJoaNXpaMFoHO3pLiafk/pbaYbKkx5fVUKi 4mFWgFUpkaKeRF7kgmqp+AVnDF7bnZmDjbqNoSIpZpqPZmpmmb5WZZWacuzop8BKmCraOc7/WkfE A/b1wK5sBDoAmCes2SXET4KRAvbhahTMKpQ1WYNZTazE6n+pGCYomJvxQK/uKrzp3bKeWZPFymCi GZcZaxCYWRQOqxAAK4Gt2bUG2HdUKw8A66xuq60aWIT16pVtAnf6wLWm67siqxRE65kdma4WWLp6 n961ILsaW792mlf6KxB0Fr8GLJOxYMEibMIqbJoNrJwR7MJCbK9FrHbU6sR+j75abMZq7MbSSsW+ JMeCbMiK7MiSbMmaLBO44Mmq7MqybMu67MvK68PC7MzSbM3a7M0qbMri7M7ybM/67M+irMwC7dAS bdEarcrq7NEq7dIybdMWbNI6bdRK7dRS/+2bCW3VYm3Wam3U6qwE7IDXAgHYBoHXiq0EmO3X8oDZ qq3YCkHZrq0OgO3anm0AsK0P1C3coi3czm0OxO3b8u3Xym3Y7q3bsu3dBu7fhm3b9oDh6q3a4i3d +i3d8u3bxm3aPq7kjm3aRu7dQm7hNm7eJm7nDq4TRK7dYi7g+i3hgu7lli3qHu7klm4SOC7r7u3p /gDnrqHlPu7rGu7ski3inq7n6m7jUu7wIi7n4u7k3i7otu7xsu7lQu/z2u7iZi7wzq71bu7iym3t Tm/vXm/wAq/10m7g1m3zTm/wpq70gq/zii/1Gu/Ytm7ysu/yDq/50u/5Iu/2yu/+ou7qXv+U+4Zv ++Zt5VauAOPv/XYv7Bbw+w4w9ZrvAwtw4b5u/f6t/gaw5vqu+kIwA5evAgOw8IouBg9u7YJwBH/w 7hLvBmOuCvsv+m4v+/6u6a6w6GawCE+w/kpw7Oou4aavBa/vD2cZd8Zw5zKv+xKwCbsu966u5wrv C58v5AIu2qpw8z6wElfvDFdw/wIwFv8wD3vvDdtuB0MvFVPwBZdwF39w+iLx+rJwCn8vF2PxEFsu BOdwEYev/C7BAmfx58qwC1tx7rYv45qxB6tu9MquHQNxGDMBGSPxBuOwFV/vAtuv/0qyBhuy4hpw 345uAYtxIityEl/y9xYy9kayAk/yII//8e46Lu6Wbymjchc/Mg1PcANbMuwi8imzagDL8SfT8i5P wRDrMRzzMhJ0cB2rsitHQSWbsSBPsfoegRj3rRHjbTDz7hxf8hZfcR+38TNvMQhzMv6+sDKDMzLf cRPgcCOPLxrvXR638Dd7cSTHsjVf8O2esw3PcgszMPP6cBKf7Sg/sQw3synbsw4XLDALLh6Trgbv Mz9zb+m6MzHz8TwbQT3L8h8bsiivsRfvqz2/LzPvMQJD9PyaMh6TNDdnMzbnczmH7kpntDOj9Ehz dExrb+wyMumCcRl7Mj7rtC47L0JL9DwLMku/9E5rcy3/swsyc1AT70dT9D9T8jAbcEgT/7VTU3VT Gy8uw+9M6zM5v3RQK7VSv3Ix260Tc7AbjzAyW/VQL/M093Fbwy9ZV/Q7W/QykzVGR/RRtx5Yp7QU X3NfY3JYL7Ja/3RVK4E3F/ZgIzb/ovQpn/EB7/VP+/JFS/YV+/Qjk208y/Nj+7RjD3Zlx7NeTzXu MkAL8PNf/3VTp7Vbw3Vqt/NCU/RrLzRlx7by6u1JCzYrzzJcw/RYEzQHnzVvi/Js169wa0T+1rVw o/Y+s/Zb33NotyBpb210S/d0G+1o1wB1Y3d2azfMWvd2e/d3gzfHdnd4k3d5m3esjfd5q/d6s/cU jLcTa/Lo3rJAQzZV+/Vmi/BEV+9X2/92URuBAAC4AOgAgA94gBd4EBB4AAS4gSu4gB9Bgjd4gUM4 hPsAhR84ECx4hu9Ahlu4Eiz4hROxX/P2Ejc3Udv1Y9+3UI9zidc356Y3LUtxQ7u05AY3W/fvKtM3 Z4v4Uusyjuu4P39xP+94gnN4DhC5gx+5kSP5kit5kz+4g0d4lCd5g394lEs4g/dAh284lDt5lnO4 loO4Nsd2QO+0RW+zjBtx9tKzbv/4VcdvlUE3DJ8wQ89tNct5JzP2ZG/14TbxVb8yF+c5TmM4k0v5 klf5lCM6of83lCd6lW95l2M5lXu5EHw5pQv4hFc6gfuwYhu1LIcuK7u0HiMvUKu4Xp//MSNH9osb NA1HryNjMArTOE579UzntkqL9CeLtQdHNWdb9ZEfOqEnupMH+6L7OoNP+aNbuYd/OZczAYFbuKM7 umbLeh5L8JyjbxQ/cTBD9myjdhkf8ZHFefe+8bhL76gfr4/Xsp238xKncgLzeCCvsZ4jAbQzOpYX e6MbO7P/wK9feZgLu6Ev+xIse6TzgLNz+bCHeGdr9TET90STsEnvsFuD9GGH8LkLObhftwVru7i7 MnzD+i5XMSQ/vJ+PMVf3OU+Lc5BHtsDrO7Ij/BMkOZh3OaS3vMwPvMwjeMAXupOHPCL395DFdzgD 9Ij/vGV/NBsfPSmEe5qrcSc89Hxn/zut0/QbqzaMn3ZfUzFmTwHCD7ylbznOV3i9X7mGN7vO57yX Y3q873rbjrnWJ/PQD7XRT7wco/oTv/htL3Zpf7y7I70WT/xU8zSsu3GnC/q8F7m/DzvOg/2+iz2y z7zitzyVR3vYLzo77/rGr72J67etC74tc/w64Hm5J30uK7zD13U3v/mNX7zHqzglC73eNzaQD7R8 e73jd73kH/vtJ7u/F7zOEzymV/qk277ZDzraH37C6/j95jCL2zcQ1zPrQ79gOzM0Y3us80DK5PXP l/WfZ7b2c7zGu73mQzVhb37z737aOz7lz7zw9/7Zpz/7L/76oz+x+z6z43zQ3/Pvrv/6IWcuCEiB KAajiZ7pWq5o2b7uHM9unZLuojC5BAy2hMIbEfgr2mRLpg3XjD6lqhcxCr1ZjzOB9ytIgcdNL2oM Npm76HWg7Waf4ba2mE51wcPLbN8Jc+RXRQNoIjiY2CdoxPXXhMPjk0dZaXmJmam5ydnp+QkaKjpK Wmp6KiWJusra6voKGys7S1tLqmqbq7vL2+v7CxwcgCtcbHyMnKy8fNvD/AwdLT1NDUssFZQzckW4 nX2YOeQ4pEU5uKXdXYW4sqeG9sZnmpYXd2f/jh9v1x6mL/evnrx3ZQYKzBSHXz55awLe+0JwIUQ2 bszAizenosF9F+vwucbuD5SRLMD/lTz0TV0NcY7QKVFXbh3KloXu9ItoMyM9jmQeWpyYZg/DhhDJ 7Izy0+jGORwxSjyqBw9TnDp7OqWicapWOVcPOrWHjyhVnku3LiGK55pJlkp0xEzXtlwMGHJT4ljp JO8UkyrubuFmVuzNsQH1afyJMyvGpAMZF6QatOziogYRI62M2ezXjQ4HXwXrz45gShdBR306mHFk rJkjqu1bci4jlYQCjYMbO503wHzvzja09vc5skA5U04tNWdT5YoRH3V8NnQ/ywCP2+xM3PTYzVEV ek7Y0ePTiVw/h5862vzjy6ddOzs5FzjfbuTWysUtf7hu/TSQ6O0fEmsPBcYHduNp/6feZFYRt153 UPm04GSV/KNYTgY2aBpoFU7YmGTRVaiaTgS6o9UaPCiwwF9x9aZbbfDN15tdetFlzm/GiNahVRce ViB59MAD3WZhCUUQdaetdqBkQg2FVo7nCdTkktwtx1prnCSFXEQXTtcjCgygWFMS2iDC30y8vbUX mVmsRCYLjKhp5kvZkdeeFCQOSKWWxRUZWnN0kiZdYX1KV+eVe0bHpXcLbSced1LaOaiihuqJyY/y fJkimpeMdCaMe0ES5iOe+IUNopBeImiTN4nF6qCJ/VmVn12tap1nBSnUaoOodgmejl3OasmWDvZE omBD4srrpWBqGpJ+pLa4WzZ4Uf8x3LOQ2OhpgIUyumujjqkqYj6L9rpUhkNNGSuhtgLLFbm6cqsc lQjulF6V65qqWYk+GpdluAFgGic3pDqrBZyfenqwigJTy/BJXsWb6JJPcrloow5SVK6VTNVLa5JG 4luex792S5iHHD8G3sPwOjTkvcoBTO1s2iqsCZs0/RfzzdGm9N/MEM/JypYsK1mWpNd5+HPI77p8 mdGFOo1echlNDfSwD+ar2Z3lwVxN115/DXbY0XAtdtlmn4122qSQrXbbbr8Nd9psx0133XbfLczc eO/Nd99+r71stAjjDG3CMOU2U+GFv6mwf40j7NuKKs7Y6X4z7uf44SesCRPPirj/ia3DNeqs+Hyc s1R6zz6nrjl8L30uKi1cDxwmYM6GHheNMiVOuIvZJuybpprzZq3D9eWl+/HbyGAbXc/WZzuoB7Ml p/Cmx05C7tLzPnj38Qn+O4vGQz55964wMEn4JJFfquj2bS4+bPG/Ja31zb+ouB/KF5+E49+4Jb/d yQ+A9nkeOuRTsOltr2Dr856Y4pO9hcVPf4f7nuXGFxy78AyBvTtf+sCnuwu67wm4K+AET1iI462O gOIAh/8kSD/QbRCDLoJefkyIGwP+bobzQ94CrfAD0Z0OgQSMCfU+1UDahG9362tgEmeBvhh2Dmdl cuBu1pG55KkOiE8UYRd9WJfM/1kieuLTYhnr17/OZTFOWwxii2A3xvwxgRxFQN0Ns8UmIRqxEf6D 0f9qFyoopo9xU4ScGH+InyIisYMAstG0mnczC6LEep3Aix3L6ELLVbGQcVReD3f2OgFS0Ydm9IYA N5lJPy4OEM1inxpRGYooNoyGrAtY9WgEwFZ+EpSwpKQMK3et1dkSjnuEjQUVyUs/ilFNdOwZI6fg yVI185Ss3CAzmXc5Z+5SeNFsXStkqT7QUa6XNXGe9FSYhy8ukHQj3FnsKkFMDJrzevwJYQedGM5G hvJ9v/zjNNGJQsMxEVo6FCU/uWezXIAzme7E4ori2chUMtSUVCwhIlf5TCWiie1TLYGoG+FHn1cK jAvxtKQv04Q4ac7RoW9c4ztDGghm7ZOhtwnYQWGxUP7V0p7tVKn5AvnTzVHwpZIkKvCAyroqIhOk PX1pLefYpvYJFKlMpeo903lRQDbVmzz1YP+qt1VvDhOrY3VqgLLIUeKdaYXA9B0fXyec0G01rWBN Klk54VFf5tV89cyqEeXKSHKCYqF/K6xhD4vYJRA2sYxtrGPrttjHSnaylPVaZCuL2cxqNm8f3Kxn PwtaQYZ2tKQtbSnQh9rUqna1rG2ta18L29jKdra0ra1tb4vb3Op2t7ztrW9/C9zgCne4xP1tCAAA Ow== --=_NamoWEC-4v4yag1e2n-- From nobody Mon Aug 18 09:49:58 2014 Return-Path: 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 73AA51A06A3 for ; Mon, 18 Aug 2014 09:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 CmAYYoxA_G6F for ; Mon, 18 Aug 2014 09:49:56 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263321A06A1 for ; Mon, 18 Aug 2014 09:49:55 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so3970042wiv.3 for ; Mon, 18 Aug 2014 09:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=34geyKap1cIM41uPSSE9bFZoSZ0b+L9/+Ve48A3T37Q=; b=EbY76Pgja5jjh5iEkBRL60av6xCDQAYCScNkKM7xG5quhmdzgyOIYzokxq+z/Ihmiy r/Ujokl8OXeWwJHXMjS+Sz6o+CsCqtOwvoZ08fbIpBvJCdR6vpR3B3ZX5a8fjTCOyPkf 37qT2iTRG65XDXiTahZIRCsSh+C5gFTuF1u2A72CxhFClpQEXvMv3zJAnQQDZ5lyX0sH 4whGWx5PgWu41eVg4JMSkrVzmdDSB9ET2jDYDMgcLzYJkf4JacQAb2caLg46HyBCCcdl uEUV1DDwvD0eFopnhtNQhGoO45zj0cCvAFCQxPqyJo3+6uSABDK797vMkU9ubYpAl8uW mTNA== MIME-Version: 1.0 X-Received: by 10.180.20.71 with SMTP id l7mr195673wie.64.1408380594500; Mon, 18 Aug 2014 09:49:54 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Mon, 18 Aug 2014 09:49:54 -0700 (PDT) In-Reply-To: <53F1E05D.9040804@alvestrand.no> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> Date: Mon, 18 Aug 2014 09:49:54 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/JAYlxGz4lUI1qk1oNaiMDQPS_kU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:49:57 -0000 On 18 August 2014 04:15, Harald Alvestrand wrote: > OTOH, if we're convinced we never need that kind of extensibility, any way > we do this is fine. I think that I want that kind of extensibility. People who care about secure text and files might also. From nobody Mon Aug 18 10:34:22 2014 Return-Path: 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 B8FF61A06F2 for ; Mon, 18 Aug 2014 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_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 J5ctApE3m977 for ; Mon, 18 Aug 2014 10:34:18 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.20]) by ietfa.amsl.com (Postfix) with ESMTP id BB0F61A06C8 for ; Mon, 18 Aug 2014 10:34:18 -0700 (PDT) Received: from userPC (unknown [122.167.224.115]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 5C53A639623; Mon, 18 Aug 2014 17:34:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1408383261; bh=eut4n20NnR3tcD1LeMA3ZUAoKt9AE0ge5g1Uq3LZApY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=buVxYFRLdCggcw6oUslyuFiYeuEyVi72hOJKDr0pwVDDHl/pvAchIJRE8bfgbuYel wL2LbUJYCPKh1pW4ne/CmLer4dWJkxB6zSKC5UObvuHTC1PizGhPcXKNcTCBNnbpU0 fhYAJwUXgyUrvbpkfCH0QEZzX40Da9/IY/1LD9Pw= From: "Parthasarathi R" To: "'Makaraju, Maridi Raju \(Raju\)'" , , "'Harald Alvestrand'" References: <53F1DF5E.6030309@alvestrand.no> <53F1E27F.1060403@gmail.com> In-Reply-To: Date: Mon, 18 Aug 2014 23:04:09 +0530 Message-ID: <006601cfbb0a$a1d0da80$e5728f80$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPutcMn/zwsdLw+EKyi2fZO0d6EpvWO+QAgABZWXA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.53F2391A.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.134 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xwH8_FA8ktf8-RU26ucuuKd7hlM Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 17:34:20 -0000 Hi Harald & all, I'm seeing that we are discussing about four WebRTC entities in three term which is confusing. I propose the following four entities to discuss: 1) WebRTC browser (full compliant Protocol + API) - as in draft-ietf-rtcweb-overview-10 2) WebRTC device (Full complaint protocol) - as in draft-ietf-rtcweb-overview-10 3) Invent new WebRTC term ("WebRTC endpoint") by lowering the bar. WebRTC endpoint mean "that the entity which can successfully communicate with a WebRTC browser by implementing only the absolute minimum of what a WebRTC browser has to implement". Ex: WebRTC IVR application which is hosted in the public internet. 4) "WebRTC gateway" is entity which has the WebRTC endpoint in one side and interwork with other entities (like SIP entities, Jingle, ISDN or WebRTC entities) in the another side. Here, we need additional requirements in WebRTC gateway which has to be documented in Sec 3 of draft-alvestrand-rtcweb-gateways-00.txt. Ex additional requirements: ICE-to Non-ICE handling, DTLS-SRTP to RTP handling. Please let me know your opinion on the same. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Makaraju, > Maridi Raju (Raju) > Sent: Monday, August 18, 2014 5:11 PM > To: rtcweb@ietf.org; Harald Alvestrand > Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a > new term? > > Hi Harald, > > How about "gw-endpoint"? in the sense that it behaves like an > "endpoint" but has different requirements than an "endpoint". > > BR > Raju > > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio > Garcia Murillo > Sent: Monday, August 18, 2014 6:25 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a > new term? > > Hi Harald, > > I always liked "endpoint" much more than "device". > > We could have different types of endpoints, and define a browser like: > a > WebRTC "full" endpoint exposing the W3C WebRTC APIs. > > Just my 2 cents. > > Best regards > Sergio > On 18/08/2014 13:11, Harald Alvestrand wrote: > > When writing the gateway document, I found myself grappling with the > > "device" description. > > > > It is somewhat uncomfortable, in that as first defined, it requires > > full WebRTC functionality except for the API part - this means that > it > > should support data channels, full ICE, bundling and so on. > > > > But for gateways, it makes sense to let go of a lot of these > > requirements. So a gateway is not a device. But what is the name for > > the thing that a gateway is, a device is, and a browser is, that > names > > "the set of things that can successfully negotiate connectivity"? And > > what are the requirements on *that*? > > > > I see a couple of options: > > > > - Redefine "Device" to mean "that which can successfully communicate > > with a browser". It's free to negotiate away features if it can, but > > needs to interoperate with a browser that implements only the > absolute > > minimum of what a browser has to implement. > > > > - Define a new class of "thing" which is "the thing that can talk to > > browsers" - of which a gateway has to be an exemplar. > > > > This is a kind of word game in some ways, but when we make > > definitions, we also define what's easy to talk about. And that can > > influence what we end up building. > > > > What do people think? > > > > Harald > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 18 15:10:16 2014 Return-Path: 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 D6CCB1A86E6 for ; Mon, 18 Aug 2014 15:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 MJzuSNvqAJei for ; Mon, 18 Aug 2014 15:10:13 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400801A86E4 for ; Mon, 18 Aug 2014 15:10:13 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id b6so5034003yha.22 for ; Mon, 18 Aug 2014 15:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BbUs2uDt/mGx1r8u7KNoykMyuHZABnNl2AiQO7KmwyA=; b=le8BQl4tXNCCt1BsiskYxKlSXhuMAmXnTpEsa+N9WW4xWGl14l11HLPdKIyWSHPZqd EEvNaHfnMgf6igaRZPflRWdBUxgfLsrPICfL0dRrHZbfQDJiH3kok8/95vD/TMvyC1DB inVOSKX3BSNluZaGrVWMdYbDbvuxjnWe3utJ5Y4K5L2+frCzlzBorMHPWzigugi0Oj0R d+kgqvRSc/5AhRhubH8Qo22S+uZ3drPyCcFADw2ycQEoKsw7KSTm1WJTMLKQNBHqRRhw cGke4yAj61ScX7h7pP3hIwnvBUj4O1ZVUqrJKuPwGIVvDGWsB+B0/9fqb5xq7VpWfjq6 AoTA== X-Received: by 10.236.124.132 with SMTP id x4mr6857150yhh.119.1408399812561; Mon, 18 Aug 2014 15:10:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.207.16 with HTTP; Mon, 18 Aug 2014 15:09:52 -0700 (PDT) In-Reply-To: <006601cfbb0a$a1d0da80$e5728f80$@co.in> References: <53F1DF5E.6030309@alvestrand.no> <53F1E27F.1060403@gmail.com> <006601cfbb0a$a1d0da80$e5728f80$@co.in> From: Silvia Pfeiffer Date: Tue, 19 Aug 2014 08:09:52 +1000 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/1uisUEBDxmFrnCxJt01M1CEfbnQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:10:15 -0000 On Tue, Aug 19, 2014 at 3:34 AM, Parthasarathi R wrote: > Hi Harald & all, > > I'm seeing that we are discussing about four WebRTC entities in three term > which is confusing. I propose the following four entities to discuss: > > 1) WebRTC browser (full compliant Protocol + API) - as in > draft-ietf-rtcweb-overview-10 To me, this is a WebRTC endpoint. > 2) WebRTC device (Full complaint protocol) - as in > draft-ietf-rtcweb-overview-10 To me, this is a RTCWeb endpoint (it doesn't care about the browser API, but only the stuff that is defined in the rtcweb group of IEEE). Silvia. > 3) Invent new WebRTC term ("WebRTC endpoint") by lowering the bar. WebRTC > endpoint mean "that the entity which can successfully communicate with a > WebRTC browser by implementing only the absolute minimum of what a WebRTC > browser has to implement". Ex: WebRTC IVR application which is hosted in the > public internet. > > 4) "WebRTC gateway" is entity which has the WebRTC endpoint in one side and > interwork with other entities (like SIP entities, Jingle, ISDN or WebRTC > entities) in the another side. Here, we need additional requirements in > WebRTC gateway which has to be documented in Sec 3 of > draft-alvestrand-rtcweb-gateways-00.txt. Ex additional requirements: ICE-to > Non-ICE handling, DTLS-SRTP to RTP handling. > > Please let me know your opinion on the same. > > Thanks > Partha > > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Makaraju, >> Maridi Raju (Raju) >> Sent: Monday, August 18, 2014 5:11 PM >> To: rtcweb@ietf.org; Harald Alvestrand >> Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a >> new term? >> >> Hi Harald, >> >> How about "gw-endpoint"? in the sense that it behaves like an >> "endpoint" but has different requirements than an "endpoint". >> >> BR >> Raju >> >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio >> Garcia Murillo >> Sent: Monday, August 18, 2014 6:25 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a >> new term? >> >> Hi Harald, >> >> I always liked "endpoint" much more than "device". >> >> We could have different types of endpoints, and define a browser like: >> a >> WebRTC "full" endpoint exposing the W3C WebRTC APIs. >> >> Just my 2 cents. >> >> Best regards >> Sergio >> On 18/08/2014 13:11, Harald Alvestrand wrote: >> > When writing the gateway document, I found myself grappling with the >> > "device" description. >> > >> > It is somewhat uncomfortable, in that as first defined, it requires >> > full WebRTC functionality except for the API part - this means that >> it >> > should support data channels, full ICE, bundling and so on. >> > >> > But for gateways, it makes sense to let go of a lot of these >> > requirements. So a gateway is not a device. But what is the name for >> > the thing that a gateway is, a device is, and a browser is, that >> names >> > "the set of things that can successfully negotiate connectivity"? And >> > what are the requirements on *that*? >> > >> > I see a couple of options: >> > >> > - Redefine "Device" to mean "that which can successfully communicate >> > with a browser". It's free to negotiate away features if it can, but >> > needs to interoperate with a browser that implements only the >> absolute >> > minimum of what a browser has to implement. >> > >> > - Define a new class of "thing" which is "the thing that can talk to >> > browsers" - of which a gateway has to be an exemplar. >> > >> > This is a kind of word game in some ways, but when we make >> > definitions, we also define what's easy to talk about. And that can >> > influence what we end up building. >> > >> > What do people think? >> > >> > Harald >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Aug 18 15:32:26 2014 Return-Path: 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 3B1C71A7D84 for ; Mon, 18 Aug 2014 15:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 O8Z2kTPaiURS for ; Mon, 18 Aug 2014 15:32:21 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1191A70FD for ; Mon, 18 Aug 2014 15:32:21 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id c41so5063618yho.26 for ; Mon, 18 Aug 2014 15:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hnk4cgV8nOflBFw80OL8YycN/VbTUgD8Q9RCr1qo4to=; b=lHOILzr4Cl7ruj2ELynAzdDr3WkH4jNfpLywdEDxeYQ7VdpUnToVLd16D3kA41IwwZ eI24gj2xrA9V8Qodjf/InvYmfQXP9BSLFE67+mfhaWfU9hOLd6pf+UAbUSjcV5Iskq1d 5nwaGDpF4OgBBmRxAM3QuOBA/oOmj1DY6Eebod7YvF0JT714DcmpArTZ8Imj36o8wmPY hNbD263SHsHj5vuWam2uAsMhE5hMT0KxXniyTJyGesayIDyJHgiKg78OuFXLwea0JNSW DGSCcbND1DDKrQk0pL/YX44eYSM0czQirxG6goAErQeGB5UU3Vr42Flfb0AsXEXIj+dW QOPg== X-Received: by 10.236.30.105 with SMTP id j69mr57333950yha.19.1408401140841; Mon, 18 Aug 2014 15:32:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.207.16 with HTTP; Mon, 18 Aug 2014 15:32:00 -0700 (PDT) In-Reply-To: References: <53F1DF5E.6030309@alvestrand.no> <53F1E27F.1060403@gmail.com> <006601cfbb0a$a1d0da80$e5728f80$@co.in> From: Silvia Pfeiffer Date: Tue, 19 Aug 2014 08:32:00 +1000 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sjkm772sIicxyAmxDwV2qfAQtsg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:32:23 -0000 On Tue, Aug 19, 2014 at 8:09 AM, Silvia Pfeiffer wrote: > On Tue, Aug 19, 2014 at 3:34 AM, Parthasarathi R > wrote: >> Hi Harald & all, >> >> I'm seeing that we are discussing about four WebRTC entities in three term >> which is confusing. I propose the following four entities to discuss: >> >> 1) WebRTC browser (full compliant Protocol + API) - as in >> draft-ietf-rtcweb-overview-10 > > To me, this is a WebRTC endpoint. > > >> 2) WebRTC device (Full complaint protocol) - as in >> draft-ietf-rtcweb-overview-10 > > To me, this is a RTCWeb endpoint (it doesn't care about the browser > API, but only the stuff that is defined in the rtcweb group of IEEE). BTW: I don't actually mind calling this a "WebRTC device" either. Just thought I should add this for discussion. Cheers, Silvia. > Silvia. > >> 3) Invent new WebRTC term ("WebRTC endpoint") by lowering the bar. WebRTC >> endpoint mean "that the entity which can successfully communicate with a >> WebRTC browser by implementing only the absolute minimum of what a WebRTC >> browser has to implement". Ex: WebRTC IVR application which is hosted in the >> public internet. >> >> 4) "WebRTC gateway" is entity which has the WebRTC endpoint in one side and >> interwork with other entities (like SIP entities, Jingle, ISDN or WebRTC >> entities) in the another side. Here, we need additional requirements in >> WebRTC gateway which has to be documented in Sec 3 of >> draft-alvestrand-rtcweb-gateways-00.txt. Ex additional requirements: ICE-to >> Non-ICE handling, DTLS-SRTP to RTP handling. >> >> Please let me know your opinion on the same. >> >> Thanks >> Partha >> >> >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Makaraju, >>> Maridi Raju (Raju) >>> Sent: Monday, August 18, 2014 5:11 PM >>> To: rtcweb@ietf.org; Harald Alvestrand >>> Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a >>> new term? >>> >>> Hi Harald, >>> >>> How about "gw-endpoint"? in the sense that it behaves like an >>> "endpoint" but has different requirements than an "endpoint". >>> >>> BR >>> Raju >>> >>> >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio >>> Garcia Murillo >>> Sent: Monday, August 18, 2014 6:25 AM >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a >>> new term? >>> >>> Hi Harald, >>> >>> I always liked "endpoint" much more than "device". >>> >>> We could have different types of endpoints, and define a browser like: >>> a >>> WebRTC "full" endpoint exposing the W3C WebRTC APIs. >>> >>> Just my 2 cents. >>> >>> Best regards >>> Sergio >>> On 18/08/2014 13:11, Harald Alvestrand wrote: >>> > When writing the gateway document, I found myself grappling with the >>> > "device" description. >>> > >>> > It is somewhat uncomfortable, in that as first defined, it requires >>> > full WebRTC functionality except for the API part - this means that >>> it >>> > should support data channels, full ICE, bundling and so on. >>> > >>> > But for gateways, it makes sense to let go of a lot of these >>> > requirements. So a gateway is not a device. But what is the name for >>> > the thing that a gateway is, a device is, and a browser is, that >>> names >>> > "the set of things that can successfully negotiate connectivity"? And >>> > what are the requirements on *that*? >>> > >>> > I see a couple of options: >>> > >>> > - Redefine "Device" to mean "that which can successfully communicate >>> > with a browser". It's free to negotiate away features if it can, but >>> > needs to interoperate with a browser that implements only the >>> absolute >>> > minimum of what a browser has to implement. >>> > >>> > - Define a new class of "thing" which is "the thing that can talk to >>> > browsers" - of which a gateway has to be an exemplar. >>> > >>> > This is a kind of word game in some ways, but when we make >>> > definitions, we also define what's easy to talk about. And that can >>> > influence what we end up building. >>> > >>> > What do people think? >>> > >>> > Harald >>> > >>> > _______________________________________________ >>> > rtcweb mailing list >>> > rtcweb@ietf.org >>> > https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 19 03:19:20 2014 Return-Path: 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 2F3EB1A8893 for ; Tue, 19 Aug 2014 03:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 c2u1OzLKsFIq for ; Tue, 19 Aug 2014 03:19:16 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5221A03A2 for ; Tue, 19 Aug 2014 03:19:16 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 5030323F0499; Tue, 19 Aug 2014 12:19:15 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.244]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Tue, 19 Aug 2014 12:19:15 +0200 From: "Hutton, Andrew" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? Thread-Index: AQHPutU56bXyHsKB7kaqXJWm/EL5oZvXszLA Date: Tue, 19 Aug 2014 10:19:14 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> References: <53F1DF5E.6030309@alvestrand.no> In-Reply-To: <53F1DF5E.6030309@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k54Rot-BVClcN9wePC3GuHbug2g Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 10:19:18 -0000 My thinking is that there are only two entities we need to be concerned wit= h. 1. WebRTC Browsers that implement both the IETF protocol requirements and t= he W3C API in full. 2. Things that can interoperate directly with WebRTC browsers but are not b= rowsers. These have to implement at least a minimum set of the IETF protoco= l and it is irrelevant as to whether they have anything link a PeerConnecti= on API internally. I was happy with calling these WebRTC Devices and think = it is useful to define the minimum set of things that they need to support. I am not convinced that we need to define any other entities and my thinkin= g is that gateways are just a type of WebRTC Device and we don't need to ca= ll them out explicitly. Regards Andy > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: 18 August 2014 12:11 > To: rtcweb@ietf.org > Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new > term? >=20 > When writing the gateway document, I found myself grappling with the > "device" description. >=20 > It is somewhat uncomfortable, in that as first defined, it requires > full > WebRTC functionality except for the API part - this means that it > should > support data channels, full ICE, bundling and so on. >=20 > But for gateways, it makes sense to let go of a lot of these > requirements. So a gateway is not a device. But what is the name for > the > thing that a gateway is, a device is, and a browser is, that names "the > set of things that can successfully negotiate connectivity"? And what > are the requirements on *that*? >=20 > I see a couple of options: >=20 > - Redefine "Device" to mean "that which can successfully communicate > with a browser". It's free to negotiate away features if it can, but > needs to interoperate with a browser that implements only the absolute > minimum of what a browser has to implement. >=20 > - Define a new class of "thing" which is "the thing that can talk to > browsers" - of which a gateway has to be an exemplar. >=20 > This is a kind of word game in some ways, but when we make definitions, > we also define what's easy to talk about. And that can influence what > we > end up building. >=20 > What do people think? >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 19 06:38:57 2014 Return-Path: <1jhbarnett@gmail.com> 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 D63FD1A88FD for ; Tue, 19 Aug 2014 06:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 T1eQPMHVeRkx for ; Tue, 19 Aug 2014 06:38:53 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6663B1A88F4 for ; Tue, 19 Aug 2014 06:38:53 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id j5so6001405qga.15 for ; Tue, 19 Aug 2014 06:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=aVYDt5DC3+lR6nE8BqPL4AUK1NUea965PD900dORqpA=; b=BPAuJFsi+dQWfqUCcR2Rdrx/W4phr+7/ClNYAvC/BG8/DWlr80+pxTIzs6zXoYqW2c JMIR3Liax6iZpKJkynsT3wXjlc5PbIRBBODEtLRnSkUks6+YvDFf82hrd9yTTO2LjeEb IFa798cK5asQlkooeJU8sMLU5rYG6JCYm5aQ3dSeiE50SbsLbpVe++bkxkxoIM0uLRuH HTW/BRjw7Sp9+PsgZ2jkpD+kPnYS5jTNMZXL5gsmjzEPkbo/yqPPne0pfGhFGh/r+Dt7 TDnWFxwMxwePllfvyNtHK+AEFp00zfAmLA3+hdXhAYHzJVr6dWkl+oU7SQAI3VMO21qQ Ui+A== X-Received: by 10.224.96.137 with SMTP id h9mr68378822qan.96.1408455532595; Tue, 19 Aug 2014 06:38:52 -0700 (PDT) Received: from [192.168.1.8] (pool-173-76-134-50.bstnma.fios.verizon.net. [173.76.134.50]) by mx.google.com with ESMTPSA id 2sm35171392qap.35.2014.08.19.06.38.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Aug 2014 06:38:52 -0700 (PDT) Message-ID: <53F3536C.5000302@gmail.com> Date: Tue, 19 Aug 2014 09:38:52 -0400 From: Jim Barnett <1jhbarnett@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/f8_KfNwlM-XV4Ca1d7fHiPQ5LcI Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 13:38:56 -0000 I agree. We need to define a) WebRTC browsers, which support the full protocol requirements and the API, b) WebRTC Endpoints/Devices, which support some minimum protocol set sufficient for establishing connectivity. Is there also a need to define c) Full WebRTC Devices, which support more than the minimum protocol set? What would be the use of definition c? We know that we have to define the maximal set a) and the minimum usable set b). If we can't think of a use for c) we can omit it and add extra profiles later if they turn out to be useful. On 8/19/2014 6:19 AM, Hutton, Andrew wrote: > My thinking is that there are only two entities we need to be concerned with. > > 1. WebRTC Browsers that implement both the IETF protocol requirements and the W3C API in full. > > 2. Things that can interoperate directly with WebRTC browsers but are not browsers. These have to implement at least a minimum set of the IETF protocol and it is irrelevant as to whether they have anything link a PeerConnection API internally. I was happy with calling these WebRTC Devices and think it is useful to define the minimum set of things that they need to support. > > I am not convinced that we need to define any other entities and my thinking is that gateways are just a type of WebRTC Device and we don't need to call them out explicitly. > > Regards > Andy > > > > >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >> Alvestrand >> Sent: 18 August 2014 12:11 >> To: rtcweb@ietf.org >> Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new >> term? >> >> When writing the gateway document, I found myself grappling with the >> "device" description. >> >> It is somewhat uncomfortable, in that as first defined, it requires >> full >> WebRTC functionality except for the API part - this means that it >> should >> support data channels, full ICE, bundling and so on. >> >> But for gateways, it makes sense to let go of a lot of these >> requirements. So a gateway is not a device. But what is the name for >> the >> thing that a gateway is, a device is, and a browser is, that names "the >> set of things that can successfully negotiate connectivity"? And what >> are the requirements on *that*? >> >> I see a couple of options: >> >> - Redefine "Device" to mean "that which can successfully communicate >> with a browser". It's free to negotiate away features if it can, but >> needs to interoperate with a browser that implements only the absolute >> minimum of what a browser has to implement. >> >> - Define a new class of "thing" which is "the thing that can talk to >> browsers" - of which a gateway has to be an exemplar. >> >> This is a kind of word game in some ways, but when we make definitions, >> we also define what's easy to talk about. And that can influence what >> we >> end up building. >> >> What do people think? >> >> Harald >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 19 07:00:43 2014 Return-Path: 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 E103B1A02F4 for ; Tue, 19 Aug 2014 07:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 XIQ_EnH17OlB for ; Tue, 19 Aug 2014 07:00:39 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id A73F61A88F3 for ; Tue, 19 Aug 2014 07:00:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 817197C3E1F for ; Tue, 19 Aug 2014 16:00:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LwvcQKrse0A for ; Tue, 19 Aug 2014 16:00:36 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:fd50:96da:96fd:540c] (unknown [IPv6:2001:470:de0a:27:fd50:96da:96fd:540c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 0A9F47C3E0B for ; Tue, 19 Aug 2014 16:00:35 +0200 (CEST) Message-ID: <53F35883.20306@alvestrand.no> Date: Tue, 19 Aug 2014 16:00:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> In-Reply-To: <53F3536C.5000302@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bsn28xV8JZ58Yi-vcpB9Tq99VfA Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:00:42 -0000 On 08/19/2014 03:38 PM, Jim Barnett wrote: > I agree. We need to define a) WebRTC browsers, which support the full > protocol requirements and the API, b) WebRTC Endpoints/Devices, which > support some minimum protocol set sufficient for establishing > connectivity. Is there also a need to define c) Full WebRTC Devices, > which support more than the minimum protocol set? What would be the > use of definition c? An endpoint (I kind of start to like this concept/name) would be conformant as long as it was able to successfully negotiate away use of anything that makes life difficult. It would be required to support DTLS-SRTP key handshakes and respond to ICE connectivity checks, plus whatever is MUST use in -rtp-usage (scanning, I'm not coming up with much - it's mostly MUST respond to, MUST implement (but not required to use) stuff). The RTP circuit breaker is also a MUST implement, and since it's a single-ended thing, it makes no sense if it isn't also MUST use. Scanning, I'm not even sure a WebRTC endpoint is required to send RTCP - but I think it should be. (Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a fully-featured endpoint... obviously we need to harmonize at some point.) > We know that we have to define the maximal set a) and the minimum > usable set b). If we can't think of a use for c) we can omit it and > add extra profiles later if they turn out to be useful. An example of c) would be a VC device based on a browser that can be plugged into any network (thus needing full ICE), but runs a captive application that cannot be made to run any other application. It would be nice to mandate support in such a device for full ICE and the MTI codecs (something I think we will have trouble with mandating for gateways). > > On 8/19/2014 6:19 AM, Hutton, Andrew wrote: >> My thinking is that there are only two entities we need to be >> concerned with. >> >> 1. WebRTC Browsers that implement both the IETF protocol requirements >> and the W3C API in full. >> >> 2. Things that can interoperate directly with WebRTC browsers but are >> not browsers. These have to implement at least a minimum set of the >> IETF protocol and it is irrelevant as to whether they have anything >> link a PeerConnection API internally. I was happy with calling these >> WebRTC Devices and think it is useful to define the minimum set of >> things that they need to support. >> >> I am not convinced that we need to define any other entities and my >> thinking is that gateways are just a type of WebRTC Device and we >> don't need to call them out explicitly. >> >> Regards >> Andy >> >> >> >> >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >>> Alvestrand >>> Sent: 18 August 2014 12:11 >>> To: rtcweb@ietf.org >>> Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new >>> term? >>> >>> When writing the gateway document, I found myself grappling with the >>> "device" description. >>> >>> It is somewhat uncomfortable, in that as first defined, it requires >>> full >>> WebRTC functionality except for the API part - this means that it >>> should >>> support data channels, full ICE, bundling and so on. >>> >>> But for gateways, it makes sense to let go of a lot of these >>> requirements. So a gateway is not a device. But what is the name for >>> the >>> thing that a gateway is, a device is, and a browser is, that names "the >>> set of things that can successfully negotiate connectivity"? And what >>> are the requirements on *that*? >>> >>> I see a couple of options: >>> >>> - Redefine "Device" to mean "that which can successfully communicate >>> with a browser". It's free to negotiate away features if it can, but >>> needs to interoperate with a browser that implements only the absolute >>> minimum of what a browser has to implement. >>> >>> - Define a new class of "thing" which is "the thing that can talk to >>> browsers" - of which a gateway has to be an exemplar. >>> >>> This is a kind of word game in some ways, but when we make definitions, >>> we also define what's easy to talk about. And that can influence what >>> we >>> end up building. >>> >>> What do people think? >>> >>> Harald >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 19 07:06:36 2014 Return-Path: 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 38C881A890A for ; Tue, 19 Aug 2014 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 QBwNYJxNC6dB for ; Tue, 19 Aug 2014 07:06:30 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2C71A88FE for ; Tue, 19 Aug 2014 07:06:29 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-22-53f359e31c51 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.98.02247.3E953F35; Tue, 19 Aug 2014 16:06:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Tue, 19 Aug 2014 16:06:23 +0200 From: Christer Holmberg To: Ted Hardie , "rtcweb@ietf.org" , "Sean Turner" , Cullen Jennings Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPt9HcUdxHfr02BkWcgRGKgtn5xJvX+z2w Date: Tue, 19 Aug 2014 14:06:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D41CDC3ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RvdJ5OdggynfOSw6JrNZrP3Xzm7R ONfOYse5CSwOLB5Tfm9k9dg56y67x505H1g9liz5yRTAEsVlk5Kak1mWWqRvl8CVcXXJfuaC cxEVzbM/szcwzgjrYuTkkBAwkfg4czMzhC0mceHeerYuRi4OIYGjjBITzl9lh3CWMEp0vX4K lOHgYBOwkOj+pw0SFxGYwChx5dt6sG5hgUCJrfvns4PYIgJBEt9+7WWEsI0kZs5cBBZnEVCV 2LHzPFicV8BXYuvGaSwgtpBAgMSS//fA4pxAc06eXQ9mMwJd9P3UGiYQm1lAXOLWk/lMEJcK SCzZcx7qalGJl4//sYLcJiGgJDFtaxpEeb5E79e5LBCrBCVOznzCMoFRZBaSSbOQlM1CUjYL aBKzgKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5da sokRGHkHt/y22sF48LnjIUYBDkYlHt4HbJ+ChVgTy4orcw8xSnOwKInzLjw3L1hIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QD4/Qi/6Vl2u69VZYNXMunzWl8q5draPzI6wW72aY9tQ0lIV+m zF+kFL8hseFxx4dXkfrTWcQ+x3tOXrt/1c/59+2tE3fvdshd+ubVEvtzy/i73WYs3W+74b7M DrnSmZdDfp3Y8HhnzOMpajLXp6THcExeYmC1XWBrfJ/Nr+S7xqnOS57N+OYw5Z4SS3FGoqEW c1FxIgBgMfK4nQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g3iBP8L1sPhmzXB8Dew8JLp6wIc Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:06:32 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D41CDC3ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBkcmFmdCBzYXlzOg0KDQrigJxXZWJSVEMgZW5kcG9pbnRzIGFyZSByZXF1aXJl ZCB0byBzdXBwb3J0IGZ1bGwgSUNFIGFzIHNwZWNpZmllZCBpbg0KICAgICAgICAgICAgICAgIHNl Y3Rpb24gMy40IG9mIFtJLUQuaWV0Zi1ydGN3ZWItdHJhbnNwb3J0c10uICBIb3dldmVyLCB3aGVu IFdlYlJUQw0KICAgICAgICAgICAgICAgIGVuZHBvaW50cyBpbnRlcndvcmsgd2l0aCBvdGhlciBl bmRwb2ludHMgdGhhdCBzdXBwb3J0IG9ubHkgSUNFLWxpdGUNCiAgICAgICAgICAgICAgICAoZS5n LiwgZ2F0ZXdheXMpIHRob3NlIGVuZHBvaW50cyB3aWxsIG5vdCBnZW5lcmF0ZSBjb25zZW50IGNo ZWNrcywNCiAgICAgICAgICAgICAgICBidXQganVzdCByZXNwb25kIHRvIGNvbnNlbnQgY2hlY2tz IHRoZXkgcmVjZWl2ZS7igJ0NCg0KVGhlIGRyYWZ0IGFsc28gdGFsa3MgYWJvdXQg4oCcV2ViUlRD IGltcGxlbWVudGF0aW9uc+KAnSBhbmQg4oCcV2ViUlRDIGJyb3dzZXJz4oCdLg0KDQpXZSBuZWVk IHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSB0ZXJtaW5vbG9neSBpcyBhbGlnbmVkIHdpdGggZHJhZnQt aWV0Zi1ydGN3ZWItb3ZlcnZpZXcgKGZvciBleGFtcGxlLCBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVy dmlldyBkb2VzIG5vdCB0YWxrIGFib3V0IOKAnFdlYlJUQyBlbmRwb2ludHPigJ0pLCB3aGljaCBh bHNvIG1heSBiZSBpbXBhY3RlZCBiYXNlZCBvbiB0aGUgb3V0Y29tZSBvZiB0aGUgY3VycmVudCB0 ZXJtaW5vbG9neS9nYXRld2F5IGRpc2N1c3Npb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBUZWQgSGFyZGllDQpTZW50OiAxNC4gZWxva3V1dGEgMjAxNCAxODoxMA0KVG86IHJ0Y3dl YkBpZXRmLm9yZzsgU2VhbiBUdXJuZXI7IEN1bGxlbiBKZW5uaW5ncw0KU3ViamVjdDogW3J0Y3dl Yl0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2hu ZXNzDQoNClRoaXMgc3RhcnRzIGEgV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXJ0Y3dlYi1z dHVuLWNvbnNlbnQtZnJlc2huZXNzIChhdmFpbGFibGUgYXQgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLykuICBQ bGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCBi eSBTZXB0ZW1iZXIgMTAsIDIwMTQuDQp0aGFua3MsDQoNClRlZCBIYXJkaWUNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D41CDC3ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkdhcmFtb25kOw0KCXBhbm9zZS0xOjIgMiA0IDQgMyAz IDEgMSA4IDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgc2F5czo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnFdlYlJUQyBlbmRwb2ludHMgYXJl IHJlcXVpcmVkIHRvIHN1cHBvcnQgZnVsbCBJQ0UgYXMgc3BlY2lmaWVkIGluPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VjdGlvbiAz LjQgb2YgW0ktRC5pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzXS4mbmJzcDsgSG93ZXZlciwgd2hlbiBX ZWJSVEM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBlbmRwb2ludHMgaW50ZXJ3b3JrIHdpdGggb3RoZXIgZW5kcG9pbnRzIHRoYXQgc3Vw cG9ydCBvbmx5IElDRS1saXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgKGUuZy4sIGdhdGV3YXlzKSB0aG9zZSBlbmRwb2ludHMgd2ls bCBub3QgZ2VuZXJhdGUgY29uc2VudCBjaGVja3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnV0IGp1c3QgcmVzcG9uZCB0byBjb25z ZW50IGNoZWNrcyB0aGV5IHJlY2VpdmUu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgYWxzbyB0YWxr cyBhYm91dCDigJxXZWJSVEMgaW1wbGVtZW50YXRpb25z4oCdIGFuZCDigJxXZWJSVEMgYnJvd3Nl cnPigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5XZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSB0ZXJtaW5vbG9n eSBpcyBhbGlnbmVkIHdpdGggZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXcgKGZvciBleGFtcGxl LCBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBkb2VzIG5vdCB0YWxrIGFib3V0IOKAnFdlYlJU QyBlbmRwb2ludHPigJ0pLA0KIHdoaWNoIGFsc28gbWF5IGJlIGltcGFjdGVkIGJhc2VkIG9uIHRo ZSBvdXRjb21lIG9mIHRoZSBjdXJyZW50IHRlcm1pbm9sb2d5L2dhdGV3YXkgZGlzY3Vzc2lvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+IDE0LiBlbG9rdXV0YSAyMDE0IDE4 OjEwPGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5vcmc7IFNlYW4gVHVybmVyOyBDdWxsZW4g SmVubmluZ3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0gV0cgTGFzdCBDYWxsIGZvciBk cmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dhcmFtb25kJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5UaGlzIHN0YXJ0cyBhIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1ydGN3ZWIt c3R1bi1jb25zZW50LWZyZXNobmVzcyAoYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVz aG5lc3MvIj4NCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3 ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy88L2E+KS4mbmJzcDsgUGxlYXNlIHJldmlldyB0aGUg ZG9jdW1lbnQgYW5kIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgU2VwdGVtYmVyIDEwLCAy MDE0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHYXJhbW9uZCZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+dGhhbmtzLDxicj4NCjxicj4NClRlZCBIYXJkaWU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D41CDC3ESESSMB209erics_-- From nobody Tue Aug 19 07:26:09 2014 Return-Path: <1jhbarnett@gmail.com> 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 BB6B61A030A for ; Tue, 19 Aug 2014 07:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 cN92QwGyNWRJ for ; Tue, 19 Aug 2014 07:26:06 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9A91A02F4 for ; Tue, 19 Aug 2014 07:26:05 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id dc16so5562637qab.8 for ; Tue, 19 Aug 2014 07:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+vqOqtLnOFwDHDeXcj+fu3TepPkLHDnOl3E/At0t39Q=; b=wIZY22Xhfb6Fe5+yy1bSHSz8QWPrK3rmosW1ca3NpAaGPo0PDne/XpKX0avzD4Q6gv Ad/35x9WIdOJuJyxB9nc2GoHVby+FLSLz45LqLJrvLL41tTQQ84lfR40bRv9Z9xlfaVM Rp6vfZQ/9GT/JJD5eATyF08WaISXHyJ7A5TdAdnYLxjoioIa80juQFEKPdxtmuTHNxOx rElMj8CvT6o5RAs3xpUbkUr9j2p1rk+E0RUObdCs0+V5ZPPwoTH9RKW2UT9t5RRkpL0U 3VW9Bpv82L/gkzCObIIBwKwBFJuuTkAa7SRxr1Z+U+zdQUojuELJTd745+1QdTv57WLi +8Mw== X-Received: by 10.224.36.4 with SMTP id r4mr67794701qad.69.1408458364125; Tue, 19 Aug 2014 07:26:04 -0700 (PDT) Received: from [192.168.1.8] (pool-173-76-134-50.bstnma.fios.verizon.net. [173.76.134.50]) by mx.google.com with ESMTPSA id x14sm15814051qae.13.2014.08.19.07.26.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Aug 2014 07:26:03 -0700 (PDT) Message-ID: <53F35E7A.8010409@gmail.com> Date: Tue, 19 Aug 2014 10:26:02 -0400 From: Jim Barnett <1jhbarnett@gmail.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> In-Reply-To: <53F35883.20306@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lVnyBdJcn_qB3HaVozaTirsNSLg Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:26:07 -0000 Does the VC device support the full protocol requirements that are placed on the Browser? If so, we can still get away with defining minimal protocol set, full protocol set, and then say Browser = full protocol set + API. On 8/19/2014 10:00 AM, Harald Alvestrand wrote: > On 08/19/2014 03:38 PM, Jim Barnett wrote: >> I agree. We need to define a) WebRTC browsers, which support the >> full protocol requirements and the API, b) WebRTC Endpoints/Devices, >> which support some minimum protocol set sufficient for establishing >> connectivity. Is there also a need to define c) Full WebRTC Devices, >> which support more than the minimum protocol set? What would be the >> use of definition c? > > An endpoint (I kind of start to like this concept/name) would be > conformant as long as it was able to successfully negotiate away use > of anything that makes life difficult. > > It would be required to support DTLS-SRTP key handshakes and respond > to ICE connectivity checks, plus whatever is MUST use in -rtp-usage > (scanning, I'm not coming up with much - it's mostly MUST respond to, > MUST implement (but not required to use) stuff). The RTP circuit > breaker is also a MUST implement, and since it's a single-ended thing, > it makes no sense if it isn't also MUST use. > > Scanning, I'm not even sure a WebRTC endpoint is required to send RTCP > - but I think it should be. > (Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a > fully-featured endpoint... obviously we need to harmonize at some point.) > >> We know that we have to define the maximal set a) and the minimum >> usable set b). If we can't think of a use for c) we can omit it and >> add extra profiles later if they turn out to be useful. > > An example of c) would be a VC device based on a browser that can be > plugged into any network (thus needing full ICE), but runs a captive > application that cannot be made to run any other application. > > It would be nice to mandate support in such a device for full ICE and > the MTI codecs (something I think we will have trouble with mandating > for gateways). >> >> On 8/19/2014 6:19 AM, Hutton, Andrew wrote: >>> My thinking is that there are only two entities we need to be >>> concerned with. >>> >>> 1. WebRTC Browsers that implement both the IETF protocol >>> requirements and the W3C API in full. >>> >>> 2. Things that can interoperate directly with WebRTC browsers but >>> are not browsers. These have to implement at least a minimum set of >>> the IETF protocol and it is irrelevant as to whether they have >>> anything link a PeerConnection API internally. I was happy with >>> calling these WebRTC Devices and think it is useful to define the >>> minimum set of things that they need to support. >>> >>> I am not convinced that we need to define any other entities and my >>> thinking is that gateways are just a type of WebRTC Device and we >>> don't need to call them out explicitly. >>> >>> Regards >>> Andy >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >>>> Alvestrand >>>> Sent: 18 August 2014 12:11 >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new >>>> term? >>>> >>>> When writing the gateway document, I found myself grappling with the >>>> "device" description. >>>> >>>> It is somewhat uncomfortable, in that as first defined, it requires >>>> full >>>> WebRTC functionality except for the API part - this means that it >>>> should >>>> support data channels, full ICE, bundling and so on. >>>> >>>> But for gateways, it makes sense to let go of a lot of these >>>> requirements. So a gateway is not a device. But what is the name for >>>> the >>>> thing that a gateway is, a device is, and a browser is, that names >>>> "the >>>> set of things that can successfully negotiate connectivity"? And what >>>> are the requirements on *that*? >>>> >>>> I see a couple of options: >>>> >>>> - Redefine "Device" to mean "that which can successfully communicate >>>> with a browser". It's free to negotiate away features if it can, but >>>> needs to interoperate with a browser that implements only the absolute >>>> minimum of what a browser has to implement. >>>> >>>> - Define a new class of "thing" which is "the thing that can talk to >>>> browsers" - of which a gateway has to be an exemplar. >>>> >>>> This is a kind of word game in some ways, but when we make >>>> definitions, >>>> we also define what's easy to talk about. And that can influence what >>>> we >>>> end up building. >>>> >>>> What do people think? >>>> >>>> Harald >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 19 07:27:58 2014 Return-Path: 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 942251A030A for ; Tue, 19 Aug 2014 07:27:56 -0700 (PDT) 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 5TItlHTn2mlV for ; Tue, 19 Aug 2014 07:27:55 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 18D461A02F4 for ; Tue, 19 Aug 2014 07:27:55 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id gdRz1o0031ZXKqc5EeTu8E; Tue, 19 Aug 2014 14:27:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta21.westchester.pa.mail.comcast.net with comcast id geTu1o00F3Ge9ey3heTu1V; Tue, 19 Aug 2014 14:27:54 +0000 Message-ID: <53F35EEA.3000602@alum.mit.edu> Date: Tue, 19 Aug 2014 10:27:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> In-Reply-To: <53F35883.20306@alvestrand.no> 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=q20140121; t=1408458474; bh=d1D3YjF810SBjwXQfPXZieVmI8m7/TUfPP+zfA/LAxM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rMYg/Se7U/4Zi2j11xHt2jmC2akxA5py61CWgCz/DFyyQQGFhCXUxwpKJTRfSZCxw eySKkj5C6rBDT+QSXLbvTpk+CFvb9ZiDP8H9/Ch39ZpiehWARfVQmVldQcaUYHphJE XpPvLdGlEAnCsnZTWzSHeT+1vFNw8hBD2p1IxnDZNa/PSccsaiY5Lj70L9r5amFm3v wAIuHSjQ2Fww7q070p5OEwp0WusqAeiC4HcAbHeNCgTxewLR8GyclSsyKzg33zhs53 sOLAiyumlTD1EtXXFf7MUWMUTXxWCXmArN86pD8ygKDzAgv+LGoWrXxX9sJ90iq9Hs GGr7Gpdd8WE5g== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MK4SkEuyi4oH_BCVbjTowCd0sCs Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:27:56 -0000 On 8/19/14 10:00 AM, Harald Alvestrand wrote: > On 08/19/2014 03:38 PM, Jim Barnett wrote: >> I agree. We need to define a) WebRTC browsers, which support the full >> protocol requirements and the API, b) WebRTC Endpoints/Devices, which >> support some minimum protocol set sufficient for establishing >> connectivity. Is there also a need to define c) Full WebRTC Devices, >> which support more than the minimum protocol set? What would be the >> use of definition c? > > An endpoint (I kind of start to like this concept/name) would be > conformant as long as it was able to successfully negotiate away use of > anything that makes life difficult. > > It would be required to support DTLS-SRTP key handshakes and respond to > ICE connectivity checks, plus whatever is MUST use in -rtp-usage > (scanning, I'm not coming up with much - it's mostly MUST respond to, > MUST implement (but not required to use) stuff). The RTP circuit breaker > is also a MUST implement, and since it's a single-ended thing, it makes > no sense if it isn't also MUST use. ISTM the requirement is that a foo (device, endpoint, whatever) MUST support at least one of: - draft-ietf-rtcweb-data-channel - draft-ietf-rtcweb-rtp-usage There are quite plausible use cases for endpoints that support only data channels, or only rtp. But a device that doesn't support either can't reasonably be considered to support webrtc in any way. Thanks, Paul > Scanning, I'm not even sure a WebRTC endpoint is required to send RTCP - > but I think it should be. > (Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a > fully-featured endpoint... obviously we need to harmonize at some point.) > >> We know that we have to define the maximal set a) and the minimum >> usable set b). If we can't think of a use for c) we can omit it and >> add extra profiles later if they turn out to be useful. > > An example of c) would be a VC device based on a browser that can be > plugged into any network (thus needing full ICE), but runs a captive > application that cannot be made to run any other application. > > It would be nice to mandate support in such a device for full ICE and > the MTI codecs (something I think we will have trouble with mandating > for gateways). >> >> On 8/19/2014 6:19 AM, Hutton, Andrew wrote: >>> My thinking is that there are only two entities we need to be >>> concerned with. >>> >>> 1. WebRTC Browsers that implement both the IETF protocol requirements >>> and the W3C API in full. >>> >>> 2. Things that can interoperate directly with WebRTC browsers but are >>> not browsers. These have to implement at least a minimum set of the >>> IETF protocol and it is irrelevant as to whether they have anything >>> link a PeerConnection API internally. I was happy with calling these >>> WebRTC Devices and think it is useful to define the minimum set of >>> things that they need to support. >>> >>> I am not convinced that we need to define any other entities and my >>> thinking is that gateways are just a type of WebRTC Device and we >>> don't need to call them out explicitly. >>> >>> Regards >>> Andy >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald >>>> Alvestrand >>>> Sent: 18 August 2014 12:11 >>>> To: rtcweb@ietf.org >>>> Subject: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new >>>> term? >>>> >>>> When writing the gateway document, I found myself grappling with the >>>> "device" description. >>>> >>>> It is somewhat uncomfortable, in that as first defined, it requires >>>> full >>>> WebRTC functionality except for the API part - this means that it >>>> should >>>> support data channels, full ICE, bundling and so on. >>>> >>>> But for gateways, it makes sense to let go of a lot of these >>>> requirements. So a gateway is not a device. But what is the name for >>>> the >>>> thing that a gateway is, a device is, and a browser is, that names "the >>>> set of things that can successfully negotiate connectivity"? And what >>>> are the requirements on *that*? >>>> >>>> I see a couple of options: >>>> >>>> - Redefine "Device" to mean "that which can successfully communicate >>>> with a browser". It's free to negotiate away features if it can, but >>>> needs to interoperate with a browser that implements only the absolute >>>> minimum of what a browser has to implement. >>>> >>>> - Define a new class of "thing" which is "the thing that can talk to >>>> browsers" - of which a gateway has to be an exemplar. >>>> >>>> This is a kind of word game in some ways, but when we make definitions, >>>> we also define what's easy to talk about. And that can influence what >>>> we >>>> end up building. >>>> >>>> What do people think? >>>> >>>> Harald >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Aug 19 08:26:33 2014 Return-Path: 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 C6DD41A0390 for ; Tue, 19 Aug 2014 08:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 XTQe7xv2uxaO for ; Tue, 19 Aug 2014 08:26:28 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 221B81A03BD for ; Tue, 19 Aug 2014 08:26:26 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 364161EB85D2 for ; Tue, 19 Aug 2014 17:26:25 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.244]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Tue, 19 Aug 2014 17:26:24 +0200 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: rtcweb-transports, Suggested text for HTTP Connect usage. Thread-Index: Ac+7we+V88fCCx7tSjuj5O3STFmI3A== Date: Tue, 19 Aug 2014 15:26:24 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E57EBE@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17E57EBEMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xBY13HkOzmIj3J0_GW1DbiVm3Lc Subject: [rtcweb] rtcweb-transports, Suggested text for HTTP Connect usage. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:26:30 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17E57EBEMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I promised in the Toronto meeting to provide suggested text for draft-ietf-= rtcweb-transports once http://tools.ietf.org/html/draft-ietf-httpbis-tunnel= -protocol-00 was adopted so here goes. My suggestion is to replace the following text in http://tools.ietf.org/htm= l/draft-ietf-rtcweb-transports-06#section-3.4 Further discussion of the interaction of WebRTC with firewalls is contained in [I-D.hutton-rtcweb-nat-firewall-considerations]. This document makes no requirements on interacting with HTTP proxies or HTTP proxy configuration methods. The WebRTC implementation MAY support accessing the Internet through an HTTP proxy. If it does so, it MUST support the "connect" header as specified in [I-D.hutton-httpbis-connect-protocol]. With the following "In order to deal with the scenario in which the media must traverse a HTTP= Proxy then the HTTP Connect request (Section 4.3.6 of [RFC7231]) MUST be supported. The HTTP Proxy may require a= uthentication and therefore proxy authentication as described in (Section 4= .3.6 of [RFC7231]) and [RFC7235] MUST a= lso be supported. In addition the HTTP Connect MUST include an indication o= f the protocol being used with the HTTP Connect initiated tunnel as describ= ed in [I.D.draft-ietf-httpbis-tunnel-protocol]". Note: I don't intend to maintain or progress [I-D.hutton-rtcweb-nat-firewa= ll-considerations]. Regards Andy --_000_9F33F40F6F2CD847824537F3C4E37DDF17E57EBEMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I promised in the Toronto meeting to provide suggested text for draft-= ietf–rtcweb-transports once http://tools.ie= tf.org/html/draft-ietf-httpbis-tunnel-protocol-00 was adopted so here goes.
 
My suggestion is to replace the following text in http://tools.ietf.org/html/draft-ietf-rtcweb-transports-06#sec= tion-3.4
 
   Further discussion of the interaction of WebRTC with fire= walls is
   contained in [I-D.hutton-rtcweb-nat-firewall-considerations].&= nbsp; This
   document makes no requirements on interacting with HTTP proxie= s or
   HTTP proxy configuration methods.

   The WebRTC implementation MAY support accessing the Internet t= hrough
   an HTTP proxy.  If it does so, it MUST support the "= connect" header
   as specified in [I-D.hutton-httpbis-connect-protocol].
 
 
With the following
 
“In order to deal with the scenario in which the media= must traverse a HTTP Proxy then the HTTP Connect request (Section 4.3.6 of [RFC7231]) MUST be supported.  The HTTP Proxy may require authentication and therefore proxy authentication as described in (= Section 4.3.6 of= [RFC7231]) and [RFC7235] MUST also be supported. In addition th= e HTTP Connect MUST include an indication of the protocol being used with the HTTP Connect initiated tunnel as descri= bed in [I.D.draft-ietf-httpbis-tunnel-protocol]”. <= /div>
=  
=  
Note: I don’t intend to maintain or progress [I-D.hutton-rtcweb= -nat-firewall-considerations].
 
 
Regards
Andy
 
 
 
 --_000_9F33F40F6F2CD847824537F3C4E37DDF17E57EBEMCHP04MSXglobal_-- From nobody Tue Aug 19 10:27:59 2014 Return-Path: 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 0D1361A06A1 for ; Tue, 19 Aug 2014 10:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 puKPWLC7s71T for ; Tue, 19 Aug 2014 10:27:54 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5BF1A065B for ; Tue, 19 Aug 2014 10:27:54 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hq11so7782599vcb.2 for ; Tue, 19 Aug 2014 10:27:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BDH7Jgby8hRK0YeIb1qQfBWWprYCj9gEbY/wV6dhpnE=; b=dIKadRryA1wNs7xrp2o0Qu0tSdNnIJc31ASQISNlwFe02EM9x0CUSCSu0onVI3TvmB wZcmcp0KgJYis5+0G1tPTaLXiLkbvqat/uOBZYD/v5Xdx61fsFSvvygKV4l9FD9SnVg0 70n4Tr+R0wQ2B1Tp8jU1a5h7H7uq5YZsVwdZ3FlVzF+gQkPca+f/6GlLEscCpPzfMVss pKnc/tm9o2GgUFftXOpZ9OIq+aHx2oTHO7TRb3JZBMZ0OcUCxqWLT2GoVp5FWcTP9/bz GwA800OIOTyZy3nXYMGncDFMMdF8vOAvZ/OVj3sHiA1i22HlXoCBWSNFm4sgi/2UXHjT rJdQ== X-Gm-Message-State: ALoCoQkSTCje6Yjc4W2nH5/llbaljYwscID68hXQanBul0POUrQ//bqosck3Rq4B3elj1yswJKuw X-Received: by 10.52.62.195 with SMTP id a3mr1320690vds.76.1408469273760; Tue, 19 Aug 2014 10:27:53 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by mx.google.com with ESMTPSA id em9sm60443062vdc.8.2014.08.19.10.27.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 10:27:53 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so7776649vcb.38 for ; Tue, 19 Aug 2014 10:27:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.52.136 with SMTP id t8mr24606588vdo.21.1408469272979; Tue, 19 Aug 2014 10:27:52 -0700 (PDT) Received: by 10.52.8.193 with HTTP; Tue, 19 Aug 2014 10:27:52 -0700 (PDT) In-Reply-To: <20140819143942.30111.91037.idtracker@ietfa.amsl.com> References: <20140819143942.30111.91037.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 13:27:52 -0400 Message-ID: From: Benjamin Schwartz To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e0115f048b19b650500fece69 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/foa9JLoKUEu1iD1jTXJCdSo70ZY Subject: [rtcweb] Fwd: New Version Notification for draft-schwartz-rtcweb-return-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:27:58 -0000 --089e0115f048b19b650500fece69 Content-Type: text/plain; charset=UTF-8 Hi rtcweb, We've talked occasionally about various TURN proxy configuration mechanisms and WebRTC TURN use cases, but it seems to me that we've never really explained how they're all supposed to fit together. I've written a draft to try to fill in the details. ---------- Forwarded message ---------- From: Date: Tue, Aug 19, 2014 at 10:39 AM Subject: New Version Notification for draft-schwartz-rtcweb-return-00.txt To: "Benjamin M. Schwartz" A new version of I-D, draft-schwartz-rtcweb-return-00.txt has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository. Name: draft-schwartz-rtcweb-return Revision: 00 Title: Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Document date: 2014-08-19 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-schwartz-rtcweb-return-00.txt Status: https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/ Htmlized: http://tools.ietf.org/html/draft-schwartz-rtcweb-return-00 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --089e0115f048b19b650500fece69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi rtcweb,

We&= #39;ve talked occasionally about various TURN proxy configuration mechanism= s and WebRTC TURN use cases, but it seems to me that we've never really= explained how they're all supposed to fit together. =C2=A0I've wri= tten a draft to try to fill in the details.

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
D= ate: Tue, Aug 19, 2014 at 10:39 AM
Subject: New Version Notification for draft-schwartz-rtcweb-return-00.txtTo: "Benjamin M. Schwartz" <bemasc@webrtc.org>



A new version of I-D, draft-schwartz-rtcweb-return-00.txt
has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-rtcweb-return<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Recursively Encapsulated TURN (RET= URN) for Connectivity and Privacy in WebRTC
Document date:=C2=A0 2014-08-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tp://www.ietf.org/internet-drafts/draft-schwartz-rtcweb-return-00.txt Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatrac= ker.ietf.org/doc/draft-schwartz-rtcweb-return/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/htm= l/draft-schwartz-rtcweb-return-00


Abstract:
=C2=A0 =C2=A0In the context of WebRTC, the concept of a local TURN proxy ha= s been
=C2=A0 =C2=A0suggested, but not reviewed in detail.=C2=A0 WebRTC applicatio= ns are
=C2=A0 =C2=A0already using TURN to enhance connectivity and privacy.=C2=A0 = This
=C2=A0 =C2=A0document explains how local TURN proxies and WebRTC applicatio= ns can
=C2=A0 =C2=A0work together.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--089e0115f048b19b650500fece69-- From nobody Tue Aug 19 10:35:26 2014 Return-Path: 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 2017B1A065B for ; Tue, 19 Aug 2014 10:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 mHGRRNeTji1s for ; Tue, 19 Aug 2014 10:35:23 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC871A04E9 for ; Tue, 19 Aug 2014 10:35:23 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 08856E1778C86; Tue, 19 Aug 2014 17:35:19 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s7JHZMd9022166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Aug 2014 13:35:22 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 19 Aug 2014 13:35:22 -0400 From: "Makaraju, Maridi Raju (Raju)" To: "Hutton, Andrew" , "rtcweb@ietf.org" Thread-Topic: rtcweb-transports, Suggested text for HTTP Connect usage. Thread-Index: Ac+7we+V88fCCx7tSjuj5O3STFmI3AAEQZ6g Date: Tue, 19 Aug 2014 17:35:21 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF17E57EBE@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E57EBE@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E51BF51US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TvJD1wEKHiDaxQhk1FbC1GS60Qc Subject: Re: [rtcweb] rtcweb-transports, Suggested text for HTTP Connect usage. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:35:25 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E51BF51US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "In order to deal with the scenario in which the media must traverse a HTTP= Proxy then the HTTP Connect request (Section 4.3.6 of [RFC7231]) MUST be supported. The HTTP Proxy may require a= uthentication and therefore proxy authentication as described in (Section 4= .3.6 of [RFC7231]) and [RFC7235] MUST a= lso be supported. In addition the HTTP Connect MUST include an indication o= f the protocol being used with the HTTP Connect initiated tunnel as describ= ed in [I.D.draft-ietf-httpbis-tunnel-protocol]". > ... In addition the HTTP Connect MUST include an indication of the protoc= ol being... Is the tunnel indication in CONNECT a "MUST"? or Can it be changed to "SHOU= LD"? The reason is, though typically unrecognized HTTP headers are ignored, what= if some proxies are sensitive to HTTP CONNECT's unrecognized headers? In = such a case excluding this header may just work fine. BR Raju --_000_E1FE4C082A89A246A11D7F32A95A17828E51BF51US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

“In order to deal with the sce= nario in which the media must traverse a HTTP Proxy then the HTTP Connect r= equest (Section 4.3.6 of [RFC7231]) MUST be supported.  The HTTP Proxy may requi= re authentication and therefore proxy authentication as described in (<= a href=3D"http://tools.ietf.org/html/rfc7231">Section 4.3.6 of [RFC= 7231]) and [RFC7235] MUST also be supported. In addition the HTTP Connect MUST include an indication of the = protocol being used with the HTTP Connect initiated tunnel as described in = [I.D.draft-ietf-httpbis-tunnel-protocol]”.

 

<Raju>

> … In addition the HTTP Connect MUST include an indication of th= e protocol being…

 

Is the tunnel indicati= on in CONNECT a “MUST”? or Can it be changed to “SHOULD&#= 8221;?

The reason is, though = typically unrecognized HTTP headers are ignored, what if some proxies are s= ensitive to HTTP CONNECT’s  unrecognized headers? In such a case= excluding this header may just work fine.

 

</Raju>

 

 

BR

Raju=

--_000_E1FE4C082A89A246A11D7F32A95A17828E51BF51US70UWXCHMBA02z_-- From nobody Tue Aug 19 11:40:28 2014 Return-Path: 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 1670B1A0547 for ; Tue, 19 Aug 2014 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 6cOX43rGHYT3 for ; Tue, 19 Aug 2014 11:40:25 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1521A0522 for ; Tue, 19 Aug 2014 11:40:25 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so6812793wes.7 for ; Tue, 19 Aug 2014 11:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Zu9HKYXcwHlxVUi3m3h3wvLvK5rkQsykDoVfqr5gC6o=; b=OfbduZMFz+GBIsjZ7WnLZ6VDRac6GXimqxJRC4MKbldnMoM+z2gMhfhWqmIYqy/IUF 0Kg9BpQW4lL9yIi0srj1DYHyNFT+uw5IGnsM1nEaFC56P+JinLnDF1/y39jxJyHY/ioH +zyhE6yU5oU6nmENkmWl4Mn/Mhf40fYjz1XX+YQOKg8g6rOwaXB7uZPYyhjOL8wwzRW0 /yGPn45XtBdfSAIs+THJZ7UACbbfCJMri/9f998wOszUBOeVY4K3Dk4u/Fm954Qw0jHG 6IixlInBEnA39PQO7ZNHtysg0eqQF7/46X1dWzAQjqKd+Vj26kqfVE1ZdbMWM3lVEbFH uLEg== MIME-Version: 1.0 X-Received: by 10.180.187.197 with SMTP id fu5mr9015055wic.64.1408473623914; Tue, 19 Aug 2014 11:40:23 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Tue, 19 Aug 2014 11:40:23 -0700 (PDT) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E57EBE@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17E57EBE@MCHP04MSX.global-ad.net> Date: Tue, 19 Aug 2014 11:40:23 -0700 Message-ID: From: Martin Thomson To: "Hutton, Andrew" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eA_tSSHEqI-n0be2znKJXrKNFIc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports, Suggested text for HTTP Connect usage. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 18:40:27 -0000 On 19 August 2014 08:26, Hutton, Andrew wrote: > =E2=80=9CIn order to deal with the scenario in which the media must trave= rse a HTTP > Proxy then the HTTP Connect request (Section 4.3.6 of [RFC7231]) MUST be > supported. The HTTP Proxy may require authentication and therefore proxy > authentication as described in (Section 4.3.6 of [RFC7231]) and [RFC7235] > MUST also be supported. In addition the HTTP Connect MUST include an > indication of the protocol being used with the HTTP Connect initiated tun= nel > as described in [I.D.draft-ietf-httpbis-tunnel-protocol]=E2=80=9D. s/HTTP Connect/HTTP CONNECT/g Use of lowercase "must" and "may require" are playing 2119 bingo, maybe consider alternative words. Making this mandatory on all endpoints is mainly just unnecessary. As we've seen, browsers are going to do this anyway because the economics makes sense. I don't see any reason to extend that mandate. It's a lot of work for a non-browser, for a relatively small gain. I could settle for SHOULD. I think that putting a MUST on proxy authentication is a little of a stretch for the same reasons that the traversal using CONNECT needs to be MAY. From nobody Tue Aug 19 16:29:22 2014 Return-Path: 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 CF0611A6FA6 for ; Tue, 19 Aug 2014 16:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 k9PwPI1e_PDq for ; Tue, 19 Aug 2014 16:29:19 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9C91A6FB2 for ; Tue, 19 Aug 2014 16:29:19 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so7007808wgh.2 for ; Tue, 19 Aug 2014 16:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fmKe5qzKdJEjdLggHLlhbreoDSAm9XjBXNonkA7a+gM=; b=wI77A/7ZGDB3+/tCSkSfqd+VmfMdY5a11TLBG6JVo+XKKfjEK/WaDkJfX2TAoDST4t IhdH0QAYQgtynySW7U8X2a5JoV/oAkIjZKw0sRex4W56DPrkJ2o4SUTuNZJGn55jDXEN KdkdWwYDMvrkgorMAAMgUAGs/IFRHE0wvVST10V7FeKYdOLwxcLe7zGU5SRYOwMk9KQ7 Tc3rBAOL4bUfz6UJtHcH3sxLWXW8LH6hGBJdWaFXi/MQK1kSH0F1/9L0eVc84yjoSzC8 LqhBg+OsxqcYEr7CtIPyYhHYyOxVP5X9KL5hWr52+mTjOm30Bsgurd0uMJid1I0v1+Ux jnOw== X-Received: by 10.180.21.208 with SMTP id x16mr10374712wie.73.1408490958112; Tue, 19 Aug 2014 16:29:18 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id za9sm38192132wjc.29.2014.08.19.16.29.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 16:29:17 -0700 (PDT) Message-ID: <53F3DDD4.1070505@gmail.com> Date: Wed, 20 Aug 2014 01:29:24 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <53F1E27F.1060403@gmail.com> <006601cfbb0a$a1d0da80$e5728f80$@co.in> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/STqY52emUgxUqrHeqnrqe3olvto Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:29:20 -0000 On 19/08/2014 0:09, Silvia Pfeiffer wrote: > On Tue, Aug 19, 2014 at 3:34 AM, Parthasarathi R > wrote: >> Hi Harald & all, >> >> I'm seeing that we are discussing about four WebRTC entities in three term >> which is confusing. I propose the following four entities to discuss: >> >> 1) WebRTC browser (full compliant Protocol + API) - as in >> draft-ietf-rtcweb-overview-10 > To me, this is a WebRTC endpoint. > > >> 2) WebRTC device (Full complaint protocol) - as in >> draft-ietf-rtcweb-overview-10 > To me, this is a RTCWeb endpoint (it doesn't care about the browser > API, but only the stuff that is defined in the rtcweb group of IEEE). > > Silvia. > Completely agree. Also with this definition, an ORTC browser would still be an WebRTC endpoint. Best regards Sergio From nobody Tue Aug 19 16:35:27 2014 Return-Path: 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 DCC3C1A6FD6 for ; Tue, 19 Aug 2014 16:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 BM-N9TFzoOYR for ; Tue, 19 Aug 2014 16:35:25 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4EE1A6FC1 for ; Tue, 19 Aug 2014 16:35:25 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so7132996wes.22 for ; Tue, 19 Aug 2014 16:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=A/OWV7cNvJqfv5A8/mDqf75VQxkIDmlLiz4FwW9bwB8=; b=SB193yRkKoRsRbIufyKbFPyVRZ7J/B2jsqquSaQSnmZh63LkRjZP86oYA+rMJQBWXV 88s/J750IND6dUm0PyGAm2GTs2n1tIg5lunTvA82XZYQB+3XGBOluIygY1zSh+FuzADu UcSPxvHsY5t/FL4tJ9GImp5Zqo4Ihcvt8vHKkqCp47D5Z344dAYDwAvGyNMdS2bVdqNl /PVTTQxlo1rT0yK2NsF/WsyToL8vD2VFdiOppqFJhhASMMQJ8/nwPjLbwSMcUzXjATvu sM8OXS5fqud9/i1wrRTKq2kUGe/Yk7eroIkVTfb2xownBMMxx1EoddlbzfO1YK6xfBtE yKqA== X-Received: by 10.194.179.73 with SMTP id de9mr54431530wjc.87.1408491324030; Tue, 19 Aug 2014 16:35:24 -0700 (PDT) Received: from [192.168.0.193] ([95.61.111.78]) by mx.google.com with ESMTPSA id td10sm3067342wic.10.2014.08.19.16.35.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 16:35:23 -0700 (PDT) Message-ID: <53F3DF42.6030600@gmail.com> Date: Wed, 20 Aug 2014 01:35:30 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F35EEA.3000602@alum.mit.edu> In-Reply-To: <53F35EEA.3000602@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/FhCSUUPpcrTSfNUdszOIbIJyLSY Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 23:35:27 -0000 On 19/08/2014 16:27, Paul Kyzivat wrote: > On 8/19/14 10:00 AM, Harald Alvestrand wrote: >> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>> I agree. We need to define a) WebRTC browsers, which support the full >>> protocol requirements and the API, b) WebRTC Endpoints/Devices, which >>> support some minimum protocol set sufficient for establishing >>> connectivity. Is there also a need to define c) Full WebRTC Devices, >>> which support more than the minimum protocol set? What would be the >>> use of definition c? >> >> An endpoint (I kind of start to like this concept/name) would be >> conformant as long as it was able to successfully negotiate away use of >> anything that makes life difficult. >> >> It would be required to support DTLS-SRTP key handshakes and respond to >> ICE connectivity checks, plus whatever is MUST use in -rtp-usage >> (scanning, I'm not coming up with much - it's mostly MUST respond to, >> MUST implement (but not required to use) stuff). The RTP circuit breaker >> is also a MUST implement, and since it's a single-ended thing, it makes >> no sense if it isn't also MUST use. > > ISTM the requirement is that a foo (device, endpoint, whatever) MUST > support at least one of: > - draft-ietf-rtcweb-data-channel > - draft-ietf-rtcweb-rtp-usage > > There are quite plausible use cases for endpoints that support only > data channels, or only rtp. But a device that doesn't support either > can't reasonably be considered to support webrtc in any way. > Right, but there are some other entities (gateways for example) that without fully implementing those requirements, are still able to talk to an WebRTC device/endpoint/whatever. May I suggest that we follow the ICE naming and we call that entities, WebRTC lite endpoints? Just a thought.. ;) Best regards Sergio From nobody Tue Aug 19 18:20:18 2014 Return-Path: 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 A37491A0AFD for ; Tue, 19 Aug 2014 18:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_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 ZalY_b0rUzKx for ; Tue, 19 Aug 2014 18:20:14 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 989F21A06D9 for ; Tue, 19 Aug 2014 18:20:14 -0700 (PDT) Received: from userPC (unknown [122.167.98.106]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 3F8F41908B44; Wed, 20 Aug 2014 01:20:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1408497616; bh=rrDya7TK0XbWS5mZgn22oHEx5ohdidHHKbbvowKUyYQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dY7hzicKIURu2kazvJkUSJ1M8sWBD1YevOAGPjJu/XZdBdyW4DusGRjDd0iT5AGpI VDEmd7Ig/9LaxJxbYx9MUWgswGCRqczf8+MMLbxGRwT9pqkDMwwWncmiG5KOH8TRSc spc4QRZjG0K8eN/G2M0Cq8nW94BXRH0UMIENivK0= From: "Parthasarathi R" To: "'Sergio Garcia Murillo'" , References: <53F1DF5E.6030309@alvestrand.no> <53F1E27F.1060403@gmail.com> <006601cfbb0a$a1d0da80$e5728f80$@co.in> <53F3DDD4.1070505@gmail.com> In-Reply-To: <53F3DDD4.1070505@gmail.com> Date: Wed, 20 Aug 2014 06:50:02 +0530 Message-ID: <001b01cfbc14$e16cb780$a4462680$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+8BW0zyzrYj4BnTfSx2H0FRjvTIgADnYuA Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.53F3F7CD.006F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EUDNGCQYc5wFLeYA2A6eH2J2Nek Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 01:20:16 -0000 Hi Sergio/Silvia, WebRTC browser and WebRTC device are also WebRTC endpoints as they conform to all WebRTC end points requirements. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Sergio > Garcia Murillo > Sent: Wednesday, August 20, 2014 4:59 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a > new term? > > On 19/08/2014 0:09, Silvia Pfeiffer wrote: > > On Tue, Aug 19, 2014 at 3:34 AM, Parthasarathi R > > wrote: > >> Hi Harald & all, > >> > >> I'm seeing that we are discussing about four WebRTC entities in > three term > >> which is confusing. I propose the following four entities to > discuss: > >> > >> 1) WebRTC browser (full compliant Protocol + API) - as in > >> draft-ietf-rtcweb-overview-10 > > To me, this is a WebRTC endpoint. > > > > > >> 2) WebRTC device (Full complaint protocol) - as in > >> draft-ietf-rtcweb-overview-10 > > To me, this is a RTCWeb endpoint (it doesn't care about the browser > > API, but only the stuff that is defined in the rtcweb group of IEEE). > > > > Silvia. > > > > Completely agree. > > Also with this definition, an ORTC browser would still be an WebRTC > endpoint. > > Best regards > Sergio > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 19 21:09:56 2014 Return-Path: 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 AE7731A0B82 for ; Tue, 19 Aug 2014 21:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 FkvADKVguuNq for ; Tue, 19 Aug 2014 21:09:51 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113E51A0174 for ; Tue, 19 Aug 2014 21:09:50 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so7216027wgh.23 for ; Tue, 19 Aug 2014 21:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2WtU9ja1PJaporC/+m8CaxskGAQptNvhOs9bybQ42RE=; b=PC/UD/cH607vmTSuII0AjeJaGA92mXLssSbsZzzl1jIPOUCxp5aFIk6YQ0i5u5Jdql ktxR8XUOwLKOp9RN939ZW0Bb5dqpXyRk0qVCGLjtu9cQq7HA10jgqCK9qqwwOR4UncL6 y5r2KQvnxCKmhuxB8R4FCJIDivQdhBfBkqQuaVN7cWx/FfE+Ei8J1erWtYsFPNifxKNz Tn9lTMG/cSpIRdtYjd05UcyXuZOdcs2+kCcNunKi/gzMPTD9ZLkJU1xD4yjlBy/RF/mm kQI9CEbr9EOG3C3WUMh4zEKPdfF1zo5PCBUHgnOPBTvmeDgkVjfTSw62OUj4jT+vTk5c Z1hg== MIME-Version: 1.0 X-Received: by 10.180.12.38 with SMTP id v6mr11574228wib.4.1408507789488; Tue, 19 Aug 2014 21:09:49 -0700 (PDT) Received: by 10.180.211.102 with HTTP; Tue, 19 Aug 2014 21:09:49 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> Date: Wed, 20 Aug 2014 09:39:49 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c240ea74b7f5050107c67b Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EqTIC8R43KiH7M_A8w_6WE72_sg Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 04:09:53 -0000 --001a11c240ea74b7f5050107c67b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe draft-ietf-rtcweb-stun-consent-freshness deals with the WebRTC browser. A WebRTC device (eg. a mobile phone) on the other hand, could run a WebRTC browser and a JS and perform consent. Similarly, a WebRTC endpoint (whatever that gets defined as) might also perform consent, while a WebRTC gateway might not, and how consent applies to those should get specified in the document(s) that define those requirements (note: the gateway referred to in draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway). So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC endpoint and WebRTC implementation with WebRTC browser, IMHO. Muthu On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > The draft says: > > > > =E2=80=9CWebRTC endpoints are required to support full ICE as specified i= n > > section 3.4 of [I-D. > =E2=80=8B=E2=80=8B > ietf-rtcweb-transports]. However, when WebRTC > > endpoints interwork with other endpoints that support onl= y > ICE-lite > > (e.g., gateways) those endpoints will not generate consen= t > checks, > > but just respond to consent checks they receive.=E2=80=9D > > > > The draft also talks about =E2=80=9CWebRTC implementations=E2=80=9D and = =E2=80=9CWebRTC browsers=E2=80=9D. > > > > We need to make sure that the terminology is aligned with > draft-ietf-rtcweb-overview (for example, > =E2=80=8B=E2=80=8B > draft-ietf-rtcweb-overview does not talk about =E2=80=9CWebRTC endpoints= =E2=80=9D), which > also may be impacted based on the outcome of the current > terminology/gateway discussion. > > > > Regards, > > > > Christer > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* 14. elokuuta 2014 18:10 > *To:* rtcweb@ietf.org; Sean Turner; Cullen Jennings > *Subject:* [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > > > This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness > (available at > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/= ). > Please review the document and send comments to the list by September 10, > 2014. > > thanks, > > Ted Hardie > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c240ea74b7f5050107c67b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe=C2=A0draft-ietf-rtcweb-stun-c= onsent-freshness deals with the WebRTC browser. A WebRTC device (eg. a mobi= le phone) on the other hand, could run a WebRTC browser and a JS and perfor= m consent. Similarly, a WebRTC endpoint (whatever that gets defined as) mig= ht also perform consent, while a WebRTC gateway might not, and how consent = applies to those should get specified in the document(s) that define those = requirements (note: the gateway referred to in draft-ietf-rtcweb-stun-conse= nt-freshness is any SIP gateway).

So, draft-ietf-rtcweb-stun-= consent-freshness should just replace WebRTC endpoint and WebRTC implementa= tion with WebRTC browser, IMHO.

Muthu

On Tue, Aug 19, 2014 at 7:36 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

The draft says:

=C2=A0

=E2=80=9CWebRTC e= ndpoints are required to support full ICE as specified in

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 section 3.4 of [I-D.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;display:inline"> =E2=80=8B=E2=80=8B
ietf-rtcweb-transports].=C2=A0 However, when WebRTC=

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoints interwork with other e= ndpoints that support only ICE-lite

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g., gateways) those endpoints= will not generate consent checks,

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 but just respond to consent chec= ks they receive.=E2=80=9D

=C2=A0

The draft also talks about =E2=80=9CWebRTC i= mplementations=E2=80=9D and =E2=80=9CWebRTC browsers=E2=80=9D.

=C2=A0

We need to make sure that the terminology is= aligned with draft-ietf-rtcweb-overview (for example,

=E2=80=8B=E2=80=8B
draft-ietf-rtcweb-overview does not talk about =E2= =80=9CWebRTC endpoints=E2=80=9D), which also may be impacted based on the outcome of the current terminology= /gateway discussion.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 14. elokuuta 2014 18:10
To: rtcweb@ietf= .org; Sean Turner; Cullen Jennings
Subject: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-fr= eshness

=C2=A0


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c240ea74b7f5050107c67b-- From nobody Wed Aug 20 00:44:26 2014 Return-Path: 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 DDF231A0069 for ; Wed, 20 Aug 2014 00:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.133 X-Spam-Level: X-Spam-Status: No, score=0.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 04pooNW5T80t for ; Wed, 20 Aug 2014 00:44:20 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 8F98F1A0060 for ; Wed, 20 Aug 2014 00:44:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 378CF7C3E44 for ; Wed, 20 Aug 2014 09:44:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTp3t8E+fpgM for ; Wed, 20 Aug 2014 09:44:16 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:91f5:f598:a50a:5fd] (unknown [IPv6:2001:470:de0a:27:91f5:f598:a50a:5fd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 244F57C3E06 for ; Wed, 20 Aug 2014 09:44:16 +0200 (CEST) Message-ID: <53F451CF.10705@alvestrand.no> Date: Wed, 20 Aug 2014 09:44:15 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000205010006060501040609" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OUSCYjkqiSrfcNUPZZlIhSOVsY8 Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 07:44:24 -0000 This is a multi-part message in MIME format. --------------000205010006060501040609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08/20/2014 06:09 AM, Muthu Arul Mozhi Perumal wrote: > I believe draft-ietf-rtcweb-stun-consent-freshness deals with the > WebRTC browser. A WebRTC device (eg. a mobile phone) on the other > hand, could run a WebRTC browser and a JS and perform consent. > Similarly, a WebRTC endpoint (whatever that gets defined as) might > also perform consent, while a WebRTC gateway might not, and how > consent applies to those should get specified in the document(s) that > define those requirements (note: the gateway referred to in > draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway). Note: In terms of conformance requirements, "might" and "might not" are completely equivalent (2119 style: MAY - there is no MAY NOT). > > So, draft-ietf-rtcweb-stun-consent-freshness should just replace > WebRTC endpoint and WebRTC implementation with WebRTC browser, IMHO. > > Muthu > > On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg > > wrote: > > Hi, > > > > The draft says: > > > > “WebRTC endpoints are required to support full ICE as specified in > > section 3.4 of [I-D. > > ​ ​ > ietf-rtcweb-transports]. However, when WebRTC > > endpoints interwork with other endpoints that > support only ICE-lite > > (e.g., gateways) those endpoints will not generate > consent checks, > > but just respond to consent checks they receive.†> > > > The draft also talks about “WebRTC implementations†and “WebRTC > browsersâ€. > > > > We need to make sure that the terminology is aligned with > draft-ietf-rtcweb-overview (for example, > > ​ ​ > draft-ietf-rtcweb-overview does not talk about “WebRTC > endpointsâ€), which also may be impacted based on the outcome of > the current terminology/gateway discussion. > > > > Regards, > > > > Christer > > > > > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org > ] *On Behalf Of *Ted Hardie > *Sent:* 14. elokuuta 2014 18:10 > *To:* rtcweb@ietf.org ; Sean Turner; > Cullen Jennings > *Subject:* [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > > > This starts a WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness (available at > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/). > Please review the document and send comments to the list by > September 10, 2014. > > thanks, > > Ted Hardie > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------000205010006060501040609 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 08/20/2014 06:09 AM, Muthu Arul Mozhi Perumal wrote:
I believe draft-ietf-rtcweb-stun-consent-freshness deals with the WebRTC browser. A WebRTC device (eg. a mobile phone) on the other hand, could run a WebRTC browser and a JS and perform consent. Similarly, a WebRTC endpoint (whatever that gets defined as) might also perform consent, while a WebRTC gateway might not, and how consent applies to those should get specified in the document(s) that define those requirements (note: the gateway referred to in draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway).

Note: In terms of conformance requirements, "might" and "might not" are completely equivalent (2119 style: MAY - there is no MAY NOT).


So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC endpoint and WebRTC implementation with WebRTC browser, IMHO.

Muthu

On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

The draft says:

 

“WebRTC endpoints are required to support full ICE as specified in

                section 3.4 of [I-D.

​ ​
ietf-rtcweb-transports].  However, when WebRTC

                endpoints interwork with other endpoints that support only ICE-lite

                (e.g., gateways) those endpoints will not generate consent checks,

                but just respond to consent checks they receive.â€

 

The draft also talks about “WebRTC implementations†and “WebRTC browsersâ€.

 

We need to make sure that the terminology is aligned with draft-ietf-rtcweb-overview (for example,

​ ​
draft-ietf-rtcweb-overview does not talk about “WebRTC endpointsâ€), which also may be impacted based on the outcome of the current terminology/gateway discussion.

 

Regards,

 

Christer

 

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 14. elokuuta 2014 18:10
To: rtcweb@ietf.org; Sean Turner; Cullen Jennings
Subject: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

 

This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness (available at http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/).  Please review the document and send comments to the list by September 10, 2014.

thanks,

Ted Hardie


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.
--------------000205010006060501040609-- From nobody Wed Aug 20 02:46:22 2014 Return-Path: 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 145211A014A for ; Wed, 20 Aug 2014 02:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hzao1HLpRkUH for ; Wed, 20 Aug 2014 02:46:17 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1A21A0115 for ; Wed, 20 Aug 2014 02:46:17 -0700 (PDT) Received: from [130.209.247.112] (port=58231 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XK2T9-0000P2-6J; Wed, 20 Aug 2014 10:46:15 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <53F35883.20306@alvestrand.no> Date: Wed, 20 Aug 2014 10:46:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/QjLbowW5NLKgX5XxXQglVA5Ck_I Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 09:46:20 -0000 On 19 Aug 2014, at 15:00, Harald Alvestrand = wrote: > On 08/19/2014 03:38 PM, Jim Barnett wrote: >> I agree. We need to define a) WebRTC browsers, which support the = full protocol requirements and the API, b) WebRTC Endpoints/Devices, = which support some minimum protocol set sufficient for establishing = connectivity. Is there also a need to define c) Full WebRTC Devices, = which support more than the minimum protocol set? What would be the use = of definition c? >=20 > An endpoint (I kind of start to like this concept/name) would be = conformant as long as it was able to successfully negotiate away use of = anything that makes life difficult. >=20 > It would be required to support DTLS-SRTP key handshakes and respond = to ICE connectivity checks, plus whatever is MUST use in -rtp-usage = (scanning, I'm not coming up with much - it's mostly MUST respond to, = MUST implement (but not required to use) stuff). The RTP circuit breaker = is also a MUST implement, and since it's a single-ended thing, it makes = no sense if it isn't also MUST use. >=20 > Scanning, I=92m not even sure a WebRTC endpoint is required to send = RTCP - but I think it should be. =93RTCP is a fundamental and integral part of RTP, and MUST be = implemented in all WebRTC applications.=94 rtp-usage-16 section 4.1 > (Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a = fully-featured endpoint... obviously we need to harmonize at some = point.) We certainly need to make sure the terminology is consistent, but I = would think that non-browser WebRTC endpoints would need to conform to = rtp-usage, since that specifies what they might be sent by a WebRTC = browser, what they can send to such a browser, and what needs to be = negotiated.=20 --=20 Colin Perkins http://csperkins.org/ From nobody Wed Aug 20 03:13:11 2014 Return-Path: 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 8DBFA1A006C for ; Wed, 20 Aug 2014 03:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.668] 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 yr5Ybm9-SdNu for ; Wed, 20 Aug 2014 03:13:08 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AACFE1A002C for ; Wed, 20 Aug 2014 03:13:07 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 480F223F04B3; Wed, 20 Aug 2014 12:13:06 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.244]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 12:13:06 +0200 From: "Hutton, Andrew" To: Martin Thomson Thread-Topic: [rtcweb] rtcweb-transports, Suggested text for HTTP Connect usage. Thread-Index: Ac+7we+V88fCCx7tSjuj5O3STFmI3AAClXeAACR7nIA= Date: Wed, 20 Aug 2014 10:13:05 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E58DED@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17E57EBE@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ZQRTOVBVWhDhRQ5hEA0PETkFL6Y Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-transports, Suggested text for HTTP Connect usage. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 10:13:09 -0000 T246IDE5IEF1Z3VzdCAyMDE0IDE5OjQwIFdyb3RlOg0KPiBPbiAxOSBBdWd1c3QgMjAxNCAwODoy NiwgSHV0dG9uLCBBbmRyZXcgPGFuZHJldy5odXR0b25AdW5pZnkuY29tPg0KPiB3cm90ZToNCj4g PiDigJxJbiBvcmRlciB0byBkZWFsIHdpdGggdGhlIHNjZW5hcmlvIGluIHdoaWNoIHRoZSBtZWRp YSBtdXN0IHRyYXZlcnNlDQo+IGEgSFRUUA0KPiA+IFByb3h5IHRoZW4gdGhlIEhUVFAgQ29ubmVj dCByZXF1ZXN0IChTZWN0aW9uIDQuMy42IG9mIFtSRkM3MjMxXSkgTVVTVA0KPiBiZQ0KPiA+IHN1 cHBvcnRlZC4gIFRoZSBIVFRQIFByb3h5IG1heSByZXF1aXJlIGF1dGhlbnRpY2F0aW9uIGFuZCB0 aGVyZWZvcmUNCj4gcHJveHkNCj4gPiBhdXRoZW50aWNhdGlvbiBhcyBkZXNjcmliZWQgaW4gKFNl Y3Rpb24gNC4zLjYgb2YgW1JGQzcyMzFdKSBhbmQNCj4gW1JGQzcyMzVdDQo+ID4gTVVTVCBhbHNv IGJlIHN1cHBvcnRlZC4gSW4gYWRkaXRpb24gdGhlIEhUVFAgQ29ubmVjdCBNVVNUIGluY2x1ZGUg YW4NCj4gPiBpbmRpY2F0aW9uIG9mIHRoZSBwcm90b2NvbCBiZWluZyB1c2VkIHdpdGggdGhlIEhU VFAgQ29ubmVjdCBpbml0aWF0ZWQNCj4gdHVubmVsDQo+ID4gYXMgZGVzY3JpYmVkIGluIFtJLkQu ZHJhZnQtaWV0Zi1odHRwYmlzLXR1bm5lbC1wcm90b2NvbF3igJ0uDQo+IA0KPiANCj4gcy9IVFRQ IENvbm5lY3QvSFRUUCBDT05ORUNUL2cNCg0KT2sgdGhhbmtzLg0KDQoNCj4gDQo+IFVzZSBvZiBs b3dlcmNhc2UgIm11c3QiIGFuZCAibWF5IHJlcXVpcmUiIGFyZSBwbGF5aW5nIDIxMTkgYmluZ28s DQo+IG1heWJlIGNvbnNpZGVyIGFsdGVybmF0aXZlIHdvcmRzLg0KDQpBZ3JlZWQgd2lsbCBzdWdn ZXN0IGFsdGVybmF0aXZlcy4NCg0KDQo+IA0KPiBNYWtpbmcgdGhpcyBtYW5kYXRvcnkgb24gYWxs IGVuZHBvaW50cyBpcyBtYWlubHkganVzdCB1bm5lY2Vzc2FyeS4gIEFzDQo+IHdlJ3ZlIHNlZW4s IGJyb3dzZXJzIGFyZSBnb2luZyB0byBkbyB0aGlzIGFueXdheSBiZWNhdXNlIHRoZSBlY29ub21p Y3MNCj4gbWFrZXMgc2Vuc2UuICBJIGRvbid0IHNlZSBhbnkgcmVhc29uIHRvIGV4dGVuZCB0aGF0 IG1hbmRhdGUuICBJdCdzIGENCj4gbG90IG9mIHdvcmsgZm9yIGEgbm9uLWJyb3dzZXIsIGZvciBh IHJlbGF0aXZlbHkgc21hbGwgZ2Fpbi4gIEkgY291bGQNCj4gc2V0dGxlIGZvciBTSE9VTEQuDQo+ DQoNClRoZSBhaW0gaXMgdG8gZ2V0IGNvbnNpc3RlbnQgYmVoYXZpb3IgZnJvbSBicm93c2VycyBz byBtYWtpbmcgaXQgbWFuZGF0b3J5IGZvciBXZWJSVEMgYnJvd3NlcnMgc2VlbXMgdGhlIGJlc3Qg b3B0aW9uIGZvciBtZS4gIEkgYWdyZWUgdGhhdCB0aGVyZSBhcmUgb3RoZXIgdGhpbmdzIChXZWJS VEMgRGV2aWNlcy9FbmRwb2ludHMgb3Igd2hhdGV2ZXIgdGhleSBhcmUgY2FsbGVkKSBtYXkgbm90 IG5lZWQgdG8gZG8gdGhpcyBzbyBpcyB0aGlzIGEgY2FzZSBmb3IgZGlmZmVyZW50aWF0aW5nIGJl dHdlZW4gYnJvd3NlcnMgYW5kIGRldmljZXM/IA0KDQoNCj4gDQo+IEkgdGhpbmsgdGhhdCBwdXR0 aW5nIGEgTVVTVCBvbiBwcm94eSBhdXRoZW50aWNhdGlvbiBpcyBhIGxpdHRsZSBvZiBhDQo+IHN0 cmV0Y2ggZm9yIHRoZSBzYW1lIHJlYXNvbnMgdGhhdCB0aGUgdHJhdmVyc2FsIHVzaW5nIENPTk5F Q1QgbmVlZHMgdG8NCj4gYmUgTUFZLg0KDQpBZ2FpbiBteSBhcmd1bWVudCBpcyB0aGF0IGNvbnNp c3RlbnQgYnJvd3NlciBiZWhhdmlvciBpcyBuZWVkZWQgaGVyZSBhbmQgaWYgYnJvd3NlcnMgaW1w bGVtZW50IEhUVFAgQ09OTkVDVCB0aGVuIEkgYmVsaWV2ZSB0aGV5IE1VU1QgYWxzbyBpbXBsZW1l bnQgYXV0aGVudGljYXRpb24uIERvZXMgdGhhdCBtYWtlIHNlbnNlPw0KDQpBbmR5DQoNCg0K From nobody Wed Aug 20 03:26:30 2014 Return-Path: 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 428531A0185 for ; Wed, 20 Aug 2014 03:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668] 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 DHGreRfNvYW2 for ; Wed, 20 Aug 2014 03:26:27 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 430C71A017A for ; Wed, 20 Aug 2014 03:26:26 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 557281EB850A; Wed, 20 Aug 2014 12:26:25 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.244]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 20 Aug 2014 12:26:25 +0200 From: "Hutton, Andrew" To: "Makaraju, Maridi Raju (Raju)" , "rtcweb@ietf.org" Thread-Topic: rtcweb-transports, Suggested text for HTTP Connect usage. Thread-Index: Ac+7we+V88fCCx7tSjuj5O3STFmI3AAEQZ6gACMqAhA= Date: Wed, 20 Aug 2014 10:26:24 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E58E3F@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17E57EBE@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0WIMwRfRzJwEdR5RfxdpJNsfMXY Subject: Re: [rtcweb] rtcweb-transports, Suggested text for HTTP Connect usage. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 10:26:28 -0000 >=20 > ... In addition the HTTP Connect MUST include an indication of the protoc= ol being... > >Is the tunnel indication in CONNECT a "MUST"? or Can it be changed to "SHO= ULD"? >The reason is, though typically unrecognized HTTP headers are ignored, wha= t if some proxies are sensitive to >HTTP CONNECT's unrecognized headers? I= n such a case excluding this header may just work fine. > > The consensus during the RTCWEB interim meeting in May was to my understand= ing that this needed to be a MUST so that proxies are told that the tunnel = will contain real-time media. My opinion is that we need browsers to be con= sistent and this overrides the need to cater for broken proxies. From nobody Wed Aug 20 03:38:29 2014 Return-Path: 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 304211A01C3 for ; Wed, 20 Aug 2014 03:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 TvnhNkbYT36z for ; Wed, 20 Aug 2014 03:38:24 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 701811A01A9 for ; Wed, 20 Aug 2014 03:38:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B64307C3E5A; Wed, 20 Aug 2014 12:38:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HVWlz9C9AXZ; Wed, 20 Aug 2014 12:38:22 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:4db7:86f3:8e53:83d3] (unknown [IPv6:2001:470:de0a:27:4db7:86f3:8e53:83d3]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3F80B7C3E54; Wed, 20 Aug 2014 12:38:22 +0200 (CEST) Message-ID: <53F47A9C.2000606@alvestrand.no> Date: Wed, 20 Aug 2014 12:38:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Colin Perkins References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/79tmOAA8Q3dxODUluz70I4kuYag Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 10:38:27 -0000 On 08/20/2014 11:46 AM, Colin Perkins wrote: > On 19 Aug 2014, at 15:00, Harald Alvestrand wrote: >> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>> I agree. We need to define a) WebRTC browsers, which support the full protocol requirements and the API, b) WebRTC Endpoints/Devices, which support some minimum protocol set sufficient for establishing connectivity. Is there also a need to define c) Full WebRTC Devices, which support more than the minimum protocol set? What would be the use of definition c? >> An endpoint (I kind of start to like this concept/name) would be conformant as long as it was able to successfully negotiate away use of anything that makes life difficult. >> >> It would be required to support DTLS-SRTP key handshakes and respond to ICE connectivity checks, plus whatever is MUST use in -rtp-usage (scanning, I'm not coming up with much - it's mostly MUST respond to, MUST implement (but not required to use) stuff). The RTP circuit breaker is also a MUST implement, and since it's a single-ended thing, it makes no sense if it isn't also MUST use. >> >> Scanning, I’m not even sure a WebRTC endpoint is required to send RTCP - but I think it should be. > “RTCP is a fundamental and integral part of RTP, and MUST be implemented in all WebRTC applications.” rtp-usage-16 section 4.1 Yep, I thought we wanted that too, but then I started to scan for mandatory-to-implement vs mandatory-to-use, and started being unsure; is it permitted to configure a WebRTC device to set RTCP-bandwidth to zero (the traditional means of turning off RTCP in a standards conformant manner, I think)? Perhaps we should add a requirement on minimum RTCP bandwidth? > >> (Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a fully-featured endpoint... obviously we need to harmonize at some point.) > We certainly need to make sure the terminology is consistent, but I would think that non-browser WebRTC endpoints would need to conform to rtp-usage, since that specifies what they might be sent by a WebRTC browser, what they can send to such a browser, and what needs to be negotiated. > Yup, it was when I started to read it from a "what can we successfully negotiate away" viewpoint that I started to worry about what we had in fact required. From nobody Wed Aug 20 03:48:10 2014 Return-Path: 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 6FFD91A01BD for ; Wed, 20 Aug 2014 03:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lLdWWE6RhAl6 for ; Wed, 20 Aug 2014 03:48:05 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCEC1A01C3 for ; Wed, 20 Aug 2014 03:48:05 -0700 (PDT) Received: from [130.209.247.112] (port=58553 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XK3Qx-0000Xn-2i; Wed, 20 Aug 2014 11:48:03 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <53F47A9C.2000606@alvestrand.no> Date: Wed, 20 Aug 2014 11:47:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F47A9C.2000606@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/OiOmz0FGZoZTfpnUuWepwEmv_AQ Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 10:48:08 -0000 On 20 Aug 2014, at 11:38, Harald Alvestrand = wrote: > On 08/20/2014 11:46 AM, Colin Perkins wrote: >> On 19 Aug 2014, at 15:00, Harald Alvestrand = wrote: >>> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>>> I agree. We need to define a) WebRTC browsers, which support the = full protocol requirements and the API, b) WebRTC Endpoints/Devices, = which support some minimum protocol set sufficient for establishing = connectivity. Is there also a need to define c) Full WebRTC Devices, = which support more than the minimum protocol set? What would be the use = of definition c? >>> An endpoint (I kind of start to like this concept/name) would be = conformant as long as it was able to successfully negotiate away use of = anything that makes life difficult. >>>=20 >>> It would be required to support DTLS-SRTP key handshakes and respond = to ICE connectivity checks, plus whatever is MUST use in -rtp-usage = (scanning, I'm not coming up with much - it's mostly MUST respond to, = MUST implement (but not required to use) stuff). The RTP circuit breaker = is also a MUST implement, and since it's a single-ended thing, it makes = no sense if it isn't also MUST use. >>>=20 >>> Scanning, I=92m not even sure a WebRTC endpoint is required to send = RTCP - but I think it should be. >> =93RTCP is a fundamental and integral part of RTP, and MUST be = implemented in all WebRTC applications.=94 rtp-usage-16 section 4.1 >=20 > Yep, I thought we wanted that too, but then I started to scan for = mandatory-to-implement vs mandatory-to-use, and started being unsure; is = it permitted to configure a WebRTC device to set RTCP-bandwidth to zero = (the traditional means of turning off RTCP in a standards conformant = manner, I think)? >=20 > Perhaps we should add a requirement on minimum RTCP bandwidth? I wouldn=92t know what minimum RTCP bandwidth to specify, but could = certainly change the rtp-usage draft to say =93=85MUST be implemented = and used=85=94 if that would help?=20 >>> (Note: The -rtp-usage draft uses "WebRTC endpoint" to mean a = fully-featured endpoint... obviously we need to harmonize at some = point.) >> We certainly need to make sure the terminology is consistent, but I = would think that non-browser WebRTC endpoints would need to conform to = rtp-usage, since that specifies what they might be sent by a WebRTC = browser, what they can send to such a browser, and what needs to be = negotiated. >>=20 > Yup, it was when I started to read it from a "what can we successfully = negotiate away" viewpoint that I started to worry about what we had in = fact required. Please send concrete suggestions for changes, if there are things you = think we should fix. --=20 Colin Perkins http://csperkins.org/ From nobody Wed Aug 20 03:57:04 2014 Return-Path: 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 8771A1A01DC for ; Wed, 20 Aug 2014 03:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 QvQ06Bn5ft_N for ; Wed, 20 Aug 2014 03:57:00 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38CA1A01D8 for ; Wed, 20 Aug 2014 03:56:59 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so6706238wiv.1 for ; Wed, 20 Aug 2014 03:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=L+v207j79c+r9xnDTYVHsIVUgbl+nnUUY73Dojro+Ew=; b=kRjSc+2JYQv143Otxwu4zcrmhHDYzmwkcGTBnXuFJLT/M36ahdvvNeFwMJ7oGYCfXG dyQNWDIFjfeKbmTXNP+8n2TCVg4QHOV05RYmhOQ5cc3m8Gwzm2qpPxVDTsU+/giMWYnS 5q2IvgQD5RFaakVqs40RsOYLZeFrGhW4HFqeI/xv4zcBmXUbYvfQtrASFPlb/j7U31VU 4Y+T4yzOwLDJDSRaw3jyBAdpCvZG0NYKELnQU+6uzzphVGL0wQ/9NscC1GkTl65Bz0Su QROe+3hnl/Q5d3lDrBbBctJGS6K9vYV8FD8N3O4Q3QiXqZpMM1d9fhN0qO9CbiNqcTux /U9g== X-Received: by 10.194.71.11 with SMTP id q11mr56213316wju.33.1408532218584; Wed, 20 Aug 2014 03:56:58 -0700 (PDT) Received: from [192.168.1.37] (228.Red-88-9-161.dynamicIP.rima-tde.net. [88.9.161.228]) by mx.google.com with ESMTPSA id ge8sm8128696wib.4.2014.08.20.03.56.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 03:56:57 -0700 (PDT) Message-ID: <53F47F01.8000407@gmail.com> Date: Wed, 20 Aug 2014 12:57:05 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F47A9C.2000606@alvestrand.no> <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> In-Reply-To: <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Do66hHFtoqs70DUgynmT17QqoD8 Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 10:57:02 -0000 On 20/08/2014 12:47, Colin Perkins wrote: > On 20 Aug 2014, at 11:38, Harald Alvestrand wrote: >> On 08/20/2014 11:46 AM, Colin Perkins wrote: >>> On 19 Aug 2014, at 15:00, Harald Alvestrand wrote: >>>> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>>>> I agree. We need to define a) WebRTC browsers, which support the full protocol requirements and the API, b) WebRTC Endpoints/Devices, which support some minimum protocol set sufficient for establishing connectivity. Is there also a need to define c) Full WebRTC Devices, which support more than the minimum protocol set? What would be the use of definition c? >>>> An endpoint (I kind of start to like this concept/name) would be conformant as long as it was able to successfully negotiate away use of anything that makes life difficult. >>>> >>>> It would be required to support DTLS-SRTP key handshakes and respond to ICE connectivity checks, plus whatever is MUST use in -rtp-usage (scanning, I'm not coming up with much - it's mostly MUST respond to, MUST implement (but not required to use) stuff). The RTP circuit breaker is also a MUST implement, and since it's a single-ended thing, it makes no sense if it isn't also MUST use. >>>> >>>> Scanning, I’m not even sure a WebRTC endpoint is required to send RTCP - but I think it should be. >>> “RTCP is a fundamental and integral part of RTP, and MUST be implemented in all WebRTC applications.” rtp-usage-16 section 4.1 >> Yep, I thought we wanted that too, but then I started to scan for mandatory-to-implement vs mandatory-to-use, and started being unsure; is it permitted to configure a WebRTC device to set RTCP-bandwidth to zero (the traditional means of turning off RTCP in a standards conformant manner, I think)? >> >> Perhaps we should add a requirement on minimum RTCP bandwidth? > I wouldn’t know what minimum RTCP bandwidth to specify, but could certainly change the rtp-usage draft to say “…MUST be implemented and used…” if that would help? > Theoretically speaking, it could be possible that all RTCP packets sent by a peer could be lost (dropped by the network for example) and the communication would still possible (as long as the content freshness/keep alive is done via STUN/ICE). So in practice, it should be possible for a WebRTC endpoint communicate with a peer not implementing/sending RTCP at all. Best regards Sergio From nobody Wed Aug 20 05:10:21 2014 Return-Path: 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 C14341A02A6 for ; Wed, 20 Aug 2014 05:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 CmtdZ8CTy0Il for ; Wed, 20 Aug 2014 05:10:17 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D341A0290 for ; Wed, 20 Aug 2014 05:10:17 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id hn18so11065133igb.10 for ; Wed, 20 Aug 2014 05:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=v1Pz0XYrPgywlDrLci3w/BtrdBPXYiMi9yNanKIhf24=; b=TIyLFPG4c5QCMRoOt3JszWXNs4Nb60oLUve6PEOikhqJ517/YvTn/CLpWvckeXLWbJ YwLLa0OOuC2wuf04oRHDpCKGrGb6Gkj78eupLJWpmVxrXFnGQMX94EcRfSC524xzbqQP r48LN9Sd/dVxLf8iSOwRfWbGXzCNETOs7nf9wkvXiSeKrrOvOIt8w9GUfHhZz2it9BB+ PWMSXDKekITD/Ul7xoc4px5GCwIK8TGx6xfv5XNlyV8rPuocTu9mbzS0mFNWx3D76CzV WSxz+TKYogZ1GOeWa7cW0qJi3nItTEqlO29M/lxd04S5fd03g/OSjLTYmyW12bbJNwmB d99Q== X-Received: by 10.50.164.167 with SMTP id yr7mr12110307igb.37.1408536616992; Wed, 20 Aug 2014 05:10:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.128.108 with HTTP; Wed, 20 Aug 2014 05:09:56 -0700 (PDT) In-Reply-To: <53F47F01.8000407@gmail.com> References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F47A9C.2000606@alvestrand.no> <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> <53F47F01.8000407@gmail.com> From: Varun Singh Date: Wed, 20 Aug 2014 15:09:56 +0300 Message-ID: To: Sergio Garcia Murillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RheBiJ77jFMLC70aZMo_r8XcdQ0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 12:10:20 -0000 On Wed, Aug 20, 2014 at 1:57 PM, Sergio Garcia Murillo wrote: > On 20/08/2014 12:47, Colin Perkins wrote: >> >> On 20 Aug 2014, at 11:38, Harald Alvestrand wrote= : >>> >>> On 08/20/2014 11:46 AM, Colin Perkins wrote: >>>> >>>> On 19 Aug 2014, at 15:00, Harald Alvestrand >>>> wrote: >>>>> >>>>> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>>>>> >>>>>> I agree. We need to define a) WebRTC browsers, which support the fu= ll >>>>>> protocol requirements and the API, b) WebRTC Endpoints/Devices, whic= h >>>>>> support some minimum protocol set sufficient for establishing connec= tivity. >>>>>> Is there also a need to define c) Full WebRTC Devices, which support= more >>>>>> than the minimum protocol set? What would be the use of definition = c? >>>>> >>>>> An endpoint (I kind of start to like this concept/name) would be >>>>> conformant as long as it was able to successfully negotiate away use = of >>>>> anything that makes life difficult. >>>>> >>>>> It would be required to support DTLS-SRTP key handshakes and respond = to >>>>> ICE connectivity checks, plus whatever is MUST use in -rtp-usage (sca= nning, >>>>> I'm not coming up with much - it's mostly MUST respond to, MUST imple= ment >>>>> (but not required to use) stuff). The RTP circuit breaker is also a M= UST >>>>> implement, and since it's a single-ended thing, it makes no sense if = it >>>>> isn't also MUST use. >>>>> >>>>> Scanning, I=E2=80=99m not even sure a WebRTC endpoint is required to = send RTCP >>>>> - but I think it should be. >>>> >>>> =E2=80=9CRTCP is a fundamental and integral part of RTP, and MUST be i= mplemented >>>> in all WebRTC applications.=E2=80=9D rtp-usage-16 section 4.1 >>> >>> Yep, I thought we wanted that too, but then I started to scan for >>> mandatory-to-implement vs mandatory-to-use, and started being unsure; i= s it >>> permitted to configure a WebRTC device to set RTCP-bandwidth to zero (t= he >>> traditional means of turning off RTCP in a standards conformant manner,= I >>> think)? >>> >>> Perhaps we should add a requirement on minimum RTCP bandwidth? >> >> I wouldn=E2=80=99t know what minimum RTCP bandwidth to specify, but coul= d >> certainly change the rtp-usage draft to say =E2=80=9C=E2=80=A6MUST be im= plemented and used=E2=80=A6=E2=80=9D >> if that would help? >> > Theoretically speaking, it could be possible that all RTCP packets sent b= y a > peer could be lost (dropped by the network for example) and the > communication would still possible (as long as the content freshness/keep > alive is done via STUN/ICE). So in practice, it should be possible for a > WebRTC endpoint communicate with a peer not implementing/sending RTCP at > all. > Since RTP Circuit Breaker is MTI as per rtp-usage. Not receiving any RTCP could potentially trigger the circuit-breaker. More so, if the stream is not sending any RTP packets in the measurement period (between 3 RTCP reports). Regards, Varun > Best regards > Sergio > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 http://www.netlab.tkk.fi/~varun/ From nobody Wed Aug 20 07:24:30 2014 Return-Path: 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 1EBD01A03D2 for ; Wed, 20 Aug 2014 07:24:28 -0700 (PDT) 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 0551-LHeVx5i for ; Wed, 20 Aug 2014 07:24:27 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id BC8701A03D1 for ; Wed, 20 Aug 2014 07:24:26 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id h0NR1o0021ei1Bg542QS2s; Wed, 20 Aug 2014 14:24:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta24.westchester.pa.mail.comcast.net with comcast id h2QR1o00r3Ge9ey3k2QSBf; Wed, 20 Aug 2014 14:24:26 +0000 Message-ID: <53F4AF99.2090606@alum.mit.edu> Date: Wed, 20 Aug 2014 10:24:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F47A9C.2000606@alvestrand.no> <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> In-Reply-To: <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408544666; bh=r8CNut8qetBo3veqcVDmeJouX92nVx05luwQ4ruB6hA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WDCmWBdrKcNrIM2pEPpXjBaDU5DgFejhE/zwcgiQ+jUPylzwwkdsbS4ttYEOGGVZO wQnS8QIuMeWiPdTcDKwU9BIyvnlwOAkywD9FsAnbEN+kDpLbVRvq9omFv0xlQMMjHU uXosNudkDVcHllD+n/CIiuDJPZ99cxGo897jEc4Ul5B2CCxf4gHIUnStX8KMhQn63B UAaRYZOkJEgv3NRyFhMlgz2GgYzYqaf7wcqJ8auydxH2vSy4LjO4ucFI29mS3YhTeK Cp6OgXhnReiwqZ1dV1O05P3VMXUYpx/TldVU9tLb4mQMRsiRmlpWTytzL6Sa+caNjC uW+xnm8mfBLiA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/dOt9kvUsX5F9qhuZEqKSJ2_vsRQ Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 14:24:28 -0000 On 8/20/14 6:47 AM, Colin Perkins wrote: > On 20 Aug 2014, at 11:38, Harald Alvestrand wrote: >> On 08/20/2014 11:46 AM, Colin Perkins wrote: >>> On 19 Aug 2014, at 15:00, Harald Alvestrand wrote: >>>> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>>>> I agree. We need to define a) WebRTC browsers, which support the full protocol requirements and the API, b) WebRTC Endpoints/Devices, which support some minimum protocol set sufficient for establishing connectivity. Is there also a need to define c) Full WebRTC Devices, which support more than the minimum protocol set? What would be the use of definition c? >>>> An endpoint (I kind of start to like this concept/name) would be conformant as long as it was able to successfully negotiate away use of anything that makes life difficult. >>>> >>>> It would be required to support DTLS-SRTP key handshakes and respond to ICE connectivity checks, plus whatever is MUST use in -rtp-usage (scanning, I'm not coming up with much - it's mostly MUST respond to, MUST implement (but not required to use) stuff). The RTP circuit breaker is also a MUST implement, and since it's a single-ended thing, it makes no sense if it isn't also MUST use. >>>> >>>> Scanning, I’m not even sure a WebRTC endpoint is required to send RTCP - but I think it should be. >>> “RTCP is a fundamental and integral part of RTP, and MUST be implemented in all WebRTC applications.” rtp-usage-16 section 4.1 >> >> Yep, I thought we wanted that too, but then I started to scan for mandatory-to-implement vs mandatory-to-use, and started being unsure; is it permitted to configure a WebRTC device to set RTCP-bandwidth to zero (the traditional means of turning off RTCP in a standards conformant manner, I think)? >> >> Perhaps we should add a requirement on minimum RTCP bandwidth? > > I wouldn’t know what minimum RTCP bandwidth to specify, but could certainly change the rtp-usage draft to say “…MUST be implemented and used…” if that would help? That is fine *if RTP is being used*. Use, or even implementation, of RTP should not be required in WebRTC devices that don't need it. (I know that is what you meant.) Thanks, Paul From nobody Wed Aug 20 09:37:23 2014 Return-Path: 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 E409D1A04A8 for ; Wed, 20 Aug 2014 09:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_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 W9i5a7vyfTnj for ; Wed, 20 Aug 2014 09:37:17 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0EC1A03C8 for ; Wed, 20 Aug 2014 09:37:16 -0700 (PDT) Received: from userPC (unknown [122.178.230.235]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 27B68648271; Wed, 20 Aug 2014 16:37:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1408552639; bh=ccYY7hRvfmJgcEAiXIHi5SG3BZQYqksz+mdZrsxHMi0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=GLWhEltOI6VEUeeUL88ZEco+kwnPwv1eeeZ8Ah5PqD3Zdj/Rj6I82AdzVfb48SgtZ WoBdroLp9bPZNyjhR+6HWDC5rzDy0n3S88kbkd2zQFEFD6eq6T+1pP211GiK6MUgL6 rMJYkat6cVcEfK3F2RmpiSoyGq0XVdahiQY1nHNg= From: "Parthasarathi R" To: "'Harald Alvestrand'" , , References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> In-Reply-To: <53F451CF.10705@alvestrand.no> Date: Wed, 20 Aug 2014 22:07:03 +0530 Message-ID: <001b01cfbc94$fccd5310$f667f930$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CFBCC3.16858F10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+8Spm9Uik209A/S7+YFgJPhCujvwARRaqQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.53F4CEBC.00C6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.134 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/UUhSVoP2PFMRs3_1ViXVfEPwMCE Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 16:37:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001C_01CFBCC3.16858F10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Muthu, =20 I agree with Harald that WebRTC endpoint & WebRTC gateway may implement = ice-lite and so, there is no need to send consent check. IIUC, the = intention of the draft is to mention that Full ICE supporting WebRTC = entities MUST support consent check.=20 =20 I think that the following changes will be sufficient for the below = comment: =20 1) WebRTC endpoint & WebRTC implementation replaced by WebRTC = devices. Please note that WebRTC browser is a webrtc device but not the = other way around.=20 =20 2) Add the statement that Full ICE supporting WebRTC entities MUST = support consent freshness. This statements will be useful for WebRTC = Endpoint or WebRTC gateway which supports Full ICE. =20 Thanks Partha =20 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald = Alvestrand Sent: Wednesday, August 20, 2014 1:14 PM To: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call for = draft-ietf-rtcweb-stun-consent-freshness =20 On 08/20/2014 06:09 AM, Muthu Arul Mozhi Perumal wrote: I believe draft-ietf-rtcweb-stun-consent-freshness deals with the WebRTC = browser. A WebRTC device (eg. a mobile phone) on the other hand, could = run a WebRTC browser and a JS and perform consent. Similarly, a WebRTC = endpoint (whatever that gets defined as) might also perform consent, = while a WebRTC gateway might not, and how consent applies to those = should get specified in the document(s) that define those requirements = (note: the gateway referred to in = draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway). Note: In terms of conformance requirements, "might" and "might not" are = completely equivalent (2119 style: MAY - there is no MAY NOT). =20 So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC = endpoint and WebRTC implementation with WebRTC browser, IMHO. =20 Muthu =20 On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg = wrote: Hi, =20 The draft says: =20 =E2=80=9CWebRTC endpoints are required to support full ICE as specified = in section 3.4 of [I-D. =E2=80=8B =E2=80=8B ietf-rtcweb-transports]. However, when WebRTC=20 endpoints interwork with other endpoints that support = only ICE-lite (e.g., gateways) those endpoints will not generate = consent checks, but just respond to consent checks they = receive.=E2=80=9D =20 The draft also talks about =E2=80=9CWebRTC implementations=E2=80=9D and = =E2=80=9CWebRTC browsers=E2=80=9D. =20 We need to make sure that the terminology is aligned with = draft-ietf-rtcweb-overview (for example,=20 =E2=80=8B =E2=80=8B draft-ietf-rtcweb-overview does not talk about =E2=80=9CWebRTC = endpoints=E2=80=9D), which also may be impacted based on the outcome of = the current terminology/gateway discussion.=20 =20 Regards, =20 Christer =20 =20 From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie Sent: 14. elokuuta 2014 18:10 To: rtcweb@ietf.org; Sean Turner; Cullen Jennings Subject: [rtcweb] WG Last Call for = draft-ietf-rtcweb-stun-consent-freshness =20 This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness = (available at = http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/= ). Please review the document and send comments to the list by = September 10, 2014. thanks, Ted Hardie _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. ------=_NextPart_000_001C_01CFBCC3.16858F10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Muthu,

 

I agree with Harald that WebRTC endpoint & WebRTC = gateway may implement ice-lite and so, there is no need to send consent check. = IIUC, the intention of the draft is to mention that Full ICE supporting WebRTC entities MUST support consent check.

 

I think that the following changes will be sufficient for = the below comment:

 

1)      WebRTC endpoint & WebRTC implementation replaced by = WebRTC devices. Please note that WebRTC browser is a webrtc device but not the = other way around.

 

2)      Add the statement that =C2=A0Full ICE supporting WebRTC = entities MUST support consent freshness. This statements will be useful for WebRTC = Endpoint or WebRTC gateway which supports Full ICE.

 

Thanks

Partha

 

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald = Alvestrand
Sent: Wednesday, August 20, 2014 1:14 PM
To: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

 

On 08/20/2014 06:09 AM, Muthu Arul Mozhi Perumal = wrote:

I believe draft-ietf-rtcweb-stun-consent-freshness deals with the = WebRTC browser. A WebRTC device (eg. a mobile phone) on the other hand, could = run a WebRTC browser and a JS and perform consent. Similarly, a WebRTC = endpoint (whatever that gets defined as) might also perform consent, while a = WebRTC gateway might not, and how consent applies to those should get specified = in the document(s) that define those requirements (note: the gateway referred = to in draft-ietf-rtcweb-stun-consent-freshness is any SIP = gateway).


Note: In terms of conformance requirements, "might" and = "might not" are completely equivalent (2119 style: MAY - there is no MAY = NOT).


 

So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC = endpoint and WebRTC implementation with WebRTC browser, = IMHO.

 

Muthu

 

On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

Hi,

 

The draft says:

 

=E2=80=9CWebRTC endpoints are required to support full = ICE as specified in

                section 3.4 of [I-D.

=E2=80=8B = =E2=80=8B

ietf-rtcweb-transports].  However, when WebRTC =

                endpoints interwork with other endpoints that support only = ICE-lite

                = (e.g., gateways) those endpoints will not generate consent = checks,

                = but just respond to consent checks they = receive.=E2=80=9D

 

The draft also talks about =E2=80=9CWebRTC implementations=E2=80=9D and = =E2=80=9CWebRTC browsers=E2=80=9D.

 

We need to make sure that the terminology is aligned with draft-ietf-rtcweb-overview (for example,

=E2=80=8B = =E2=80=8B

draft-ietf-rtcweb-overview does not talk about = =E2=80=9CWebRTC endpoints=E2=80=9D), which also may be impacted based on the outcome of = the current terminology/gateway discussion.

 

Regards,

 

Christer

 

 

From:= rtcweb = [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 14. elokuuta 2014 18:10
To: rtcweb@ietf.org; Sean Turner; Cullen Jennings
Subject: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

 <= /o:p>

This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness (available at http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-= consent-freshness/).  Please review the document and send comments to the list by September = 10, 2014.

thanks,

Ted Hardie


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/rtcweb




-- 
Surveillance is pervasive. Go =
Dark.
------=_NextPart_000_001C_01CFBCC3.16858F10-- From nobody Wed Aug 20 21:16:27 2014 Return-Path: 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 DD27A1A7003 for ; Wed, 20 Aug 2014 21:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 GwkKzwjmBug7 for ; Wed, 20 Aug 2014 21:16:21 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA141A7002 for ; Wed, 20 Aug 2014 21:16:20 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so8446141wgh.21 for ; Wed, 20 Aug 2014 21:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6XLsUDGEiXJ2sNQVNjG8iE8wDRq5t8O8pIJFuMg97lk=; b=t7/lp+Wy1twY5BxR9nPRK3CEYG7VZEbTqA5brDl1uAnqffrQDY5L1Bs4s6Nq+YjugU KBdN9XPkWMC1SWCKBKLEFKsH3Ysm9GAT9rhDXIPhZPyrRixGjLJtP+EMPettHU2gBS5p TSXu4azDywRmmae2ggFhP99rADX9ZUy7D/5q0VMSMwma4e1EYbV5IR2pofir8Ukpsp9Q qQ/iV8VcQZ/6i1sifZDVzvdg4bOeFtnh3zZI1eUYlCJ0d53HTuXKQgpHQqfdybCY4pZ+ +BalKfMSI7qeF0gxdvVevWtxABmDLr05MWCyj2bspXat6JP3qRJWNg87cAWflxQnrAHg 9TBA== MIME-Version: 1.0 X-Received: by 10.180.93.104 with SMTP id ct8mr20086852wib.30.1408594579173; Wed, 20 Aug 2014 21:16:19 -0700 (PDT) Received: by 10.180.211.102 with HTTP; Wed, 20 Aug 2014 21:16:19 -0700 (PDT) In-Reply-To: <001b01cfbc94$fccd5310$f667f930$@co.in> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Thu, 21 Aug 2014 09:46:19 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Parthasarathi R Content-Type: multipart/alternative; boundary=f46d043c08ea86368105011bfb94 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/7YeXH8DVDCwIAYZR7SgTWz2hz7A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 04:16:24 -0000 --f46d043c08ea86368105011bfb94 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The elementary entity that needs to perform consent is a WebRTC entity that runs untrusted applications -- essentially a WebRTC browser. Other entities may perform consent as a consequence of them running a browser or because they want to use it to compute RTT or whatever and not simply because they support full ICE. This elementary entity is the target for the consent draft and I don't think the draft should convolute it any further. Of course, adding some text that other WebRTC entities may perform consent for the above said reasons could help, I think. Muthu On Wed, Aug 20, 2014 at 10:07 PM, Parthasarathi R < partha@parthasarathi.co.in> wrote: > Hi Muthu, > > > > I agree with Harald that WebRTC endpoint & WebRTC gateway may implement > ice-lite and so, there is no need to send consent check. IIUC, the > intention of the draft is to mention that Full ICE supporting WebRTC > entities MUST support consent check. > > > > I think that the following changes will be sufficient for the below > comment: > > > > 1) WebRTC endpoint & WebRTC implementation replaced by WebRTC > devices. Please note that WebRTC browser is a webrtc device but not the > other way around. > > > > 2) Add the statement that Full ICE supporting WebRTC entities MUST > support consent freshness. This statements will be useful for WebRTC > Endpoint or WebRTC gateway which supports Full ICE. > > > > Thanks > > Partha > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Harald > Alvestrand > *Sent:* Wednesday, August 20, 2014 1:14 PM > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > > > On 08/20/2014 06:09 AM, Muthu Arul Mozhi Perumal wrote: > > I believe draft-ietf-rtcweb-stun-consent-freshness deals with the WebRTC > browser. A WebRTC device (eg. a mobile phone) on the other hand, could ru= n > a WebRTC browser and a JS and perform consent. Similarly, a WebRTC endpoi= nt > (whatever that gets defined as) might also perform consent, while a WebRT= C > gateway might not, and how consent applies to those should get specified = in > the document(s) that define those requirements (note: the gateway referre= d > to in draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway). > > > Note: In terms of conformance requirements, "might" and "might not" are > completely equivalent (2119 style: MAY - there is no MAY NOT). > > > > > So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC > endpoint and WebRTC implementation with WebRTC browser, IMHO. > > > > Muthu > > > > On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > The draft says: > > > > =E2=80=9CWebRTC endpoints are required to support full ICE as specified i= n > > section 3.4 of [I-D. > > =E2=80=8B =E2=80=8B > > ietf-rtcweb-transports]. However, when WebRTC > > endpoints interwork with other endpoints that support onl= y > ICE-lite > > (e.g., gateways) those endpoints will not generate consen= t > checks, > > but just respond to consent checks they receive.=E2=80=9D > > > > The draft also talks about =E2=80=9CWebRTC implementations=E2=80=9D and = =E2=80=9CWebRTC browsers=E2=80=9D. > > > > We need to make sure that the terminology is aligned with > draft-ietf-rtcweb-overview (for example, > > =E2=80=8B =E2=80=8B > > draft-ietf-rtcweb-overview does not talk about =E2=80=9CWebRTC endpoints= =E2=80=9D), which > also may be impacted based on the outcome of the current > terminology/gateway discussion. > > > > Regards, > > > > Christer > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* 14. elokuuta 2014 18:10 > *To:* rtcweb@ietf.org; Sean Turner; Cullen Jennings > *Subject:* [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > > > This starts a WG Last Call for draft-ietf-rtcweb-stun-consent-freshness > (available at > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/= ). > Please review the document and send comments to the list by September 10, > 2014. > > thanks, > > Ted Hardie > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > > Surveillance is pervasive. Go Dark. > > --f46d043c08ea86368105011bfb94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The elementary entity that needs to per= form consent is a WebRTC entity that runs untrusted applications -- essenti= ally a WebRTC browser. Other entities may perform consent as a consequence = of them running a browser or because they want to use it to compute RTT or = whatever and not simply because they support full ICE. This elementary enti= ty is the target for the consent draft and I don't think the draft shou= ld convolute it any further. Of course, adding some text that other WebRTC = entities may perform consent for the above said reasons could help, I think= .

Muthu

On Wed, Aug 20, 2014 at 10:07 PM, Parthasara= thi R <partha@parthasarathi.co.in> wrote:

Hi Muthu,

=C2=A0

I agree with Harald that = WebRTC endpoint & WebRTC gateway may implement ice-lite and so, there is no need to send consent check. IIUC= , the intention of the draft is to mention that Full ICE supporting WebRTC entities MUST support consent check.

=C2=A0

I think that the followin= g changes will be sufficient for the below comment:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 WebRTC endpoint &= ; WebRTC implementation replaced by WebRTC devices. Please note that WebRTC browser is a webrtc device but not the oth= er way around.

=C2=A0

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Add the statement th= at =C2=A0Full ICE supporting WebRTC entities MUST support consent freshness. This statements will be useful for WebRTC Endpoi= nt or WebRTC gateway which supports Full ICE.

=C2=A0

Thanks

Partha

=C2=A0

From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Wednesday, August 20, 2014 1:14 PM
To: rtcweb@ietf= .org
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

=C2=A0

On 08/20/2014 06:09 AM, Muthu Arul Mozhi Perumal wro= te:

I believe=C2=A0draft-ietf-rtcweb-stun-consent-freshness deals with the WebRTC browser. A WebRTC device (eg. a mobile phone) on the other hand, could run = a WebRTC browser and a JS and perform consent. Similarly, a WebRTC endpoint (whatever that gets defined as) might also perform consent, while a WebRTC gateway might not, and how consent applies to those should get specified in= the document(s) that define those requirements (note: the gateway referred to i= n draft-ietf-rtcweb-stun-consent-freshness is any SIP gateway).=


Note: In terms of conformance requirements, "might" and "mig= ht not" are completely equivalent (2119 style: MAY - there is no MAY NOT)= .


=C2=A0

So, draft-ietf-rtcweb-stun-consent-freshness should just replace WebRTC endpoin= t and WebRTC implementation with WebRTC browser, IMHO.

=C2=A0

Muthu

=C2=A0

On Tue, Aug 19, 2014 at 7:36 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,<= /p>

=C2=A0

The draft says:

=C2=A0

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 section 3.4 of [I-D.

=E2=80=8B =E2=80=8B

ietf-rtcweb-transports].=C2=A0 However, when WebRTC =

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoints interwork with other endpoints that support only ICE-lite<= u>

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e= .g., gateways) those endpoints will not generate consent checks,

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bu= t just respond to consent checks they receive.=E2=80=9D<= /p>

=C2=A0

The draft also talks about =E2=80=9CWebRTC implementations=E2=80=9D and =E2=80= =9CWebRTC browsers=E2=80=9D.

=C2=A0

We need to make sure that the terminology is aligned with draft-ietf-rtcweb-overview (for example,

=E2=80=8B =E2=80=8B

draft-ietf-rtcweb-overview does not talk about =E2= =80=9CWebRTC endpoints=E2=80=9D), which also may be impacted based on the outcome of the= current terminology/gateway discussion.

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

=C2=A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 14. elokuuta 2014 18:10
To: rtcweb@ietf= .org; Sean Turner; Cullen Jennings
Subject: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

=C2=A0

This starts a WG Last Call fo= r draft-ietf-rtcweb-stun-consent-freshness (available at http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-fre= shness/).=C2=A0 Please review the document and send comments to the list by September 10, 2= 014.

thanks,

Ted Hardie


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

=C2=A0




_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https:/=
/www.ietf.org/mailman/listinfo/rtcweb




-- 
Surveillance is pervasive. Go Dark.=

--f46d043c08ea86368105011bfb94-- From nobody Thu Aug 21 04:42:43 2014 Return-Path: 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 B7F4E1A01A8 for ; Thu, 21 Aug 2014 04:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 090dlYf9xuR1 for ; Thu, 21 Aug 2014 04:42:38 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B4B1A0197 for ; Thu, 21 Aug 2014 04:42:38 -0700 (PDT) Received: from [81.187.2.149] (port=52010 helo=[192.168.0.64]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XKQlH-0008RW-8f; Thu, 21 Aug 2014 12:42:36 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <53F4AF99.2090606@alum.mit.edu> Date: Thu, 21 Aug 2014 12:42:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F47A9C.2000606@alvestrand.no> <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> <53F4AF99.2090606@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/0bEAsJvs7fUQ789LjCVn2FMXF6g Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 11:42:42 -0000 On 20 Aug 2014, at 15:24, Paul Kyzivat wrote: > On 8/20/14 6:47 AM, Colin Perkins wrote: >> On 20 Aug 2014, at 11:38, Harald Alvestrand = wrote: >>> On 08/20/2014 11:46 AM, Colin Perkins wrote: >>>> On 19 Aug 2014, at 15:00, Harald Alvestrand = wrote: >>>>> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>>>>> I agree. We need to define a) WebRTC browsers, which support the = full protocol requirements and the API, b) WebRTC Endpoints/Devices, = which support some minimum protocol set sufficient for establishing = connectivity. Is there also a need to define c) Full WebRTC Devices, = which support more than the minimum protocol set? What would be the use = of definition c? >>>>> An endpoint (I kind of start to like this concept/name) would be = conformant as long as it was able to successfully negotiate away use of = anything that makes life difficult. >>>>>=20 >>>>> It would be required to support DTLS-SRTP key handshakes and = respond to ICE connectivity checks, plus whatever is MUST use in = -rtp-usage (scanning, I'm not coming up with much - it's mostly MUST = respond to, MUST implement (but not required to use) stuff). The RTP = circuit breaker is also a MUST implement, and since it's a single-ended = thing, it makes no sense if it isn't also MUST use. >>>>>=20 >>>>> Scanning, I=92m not even sure a WebRTC endpoint is required to = send RTCP - but I think it should be. >>>> =93RTCP is a fundamental and integral part of RTP, and MUST be = implemented in all WebRTC applications.=94 rtp-usage-16 section 4.1 >>>=20 >>> Yep, I thought we wanted that too, but then I started to scan for = mandatory-to-implement vs mandatory-to-use, and started being unsure; is = it permitted to configure a WebRTC device to set RTCP-bandwidth to zero = (the traditional means of turning off RTCP in a standards conformant = manner, I think)? >>>=20 >>> Perhaps we should add a requirement on minimum RTCP bandwidth? >>=20 >> I wouldn=92t know what minimum RTCP bandwidth to specify, but could = certainly change the rtp-usage draft to say =93=85MUST be implemented = and used=85=94 if that would help? >=20 > That is fine *if RTP is being used*. I am suggesting adding this to the RTP usage draft=85 > Use, or even implementation, of RTP should not be required in WebRTC = devices that don=92t need it. Perhaps, but if implementing RTP isn=92t a requirement, that needs to be = captured somewhere. The rtcweb-overview-11 draft currently mandates RTP = be implemented.=20 --=20 Colin Perkins http://csperkins.org/ From nobody Thu Aug 21 11:21:51 2014 Return-Path: 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 47B961A049E for ; Thu, 21 Aug 2014 11:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 8ljp3w8Me1l4 for ; Thu, 21 Aug 2014 11:21:48 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBE11A048E for ; Thu, 21 Aug 2014 11:21:47 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so9456415wgh.8 for ; Thu, 21 Aug 2014 11:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nscJWr+wMi64irrjXrsw6oaU6adNC4bQ05UZCYPuwas=; b=Q97aN5PJJf0q3hYQYCsIUmglWK4pJqsYKJbCAZS8JnJC81QF+vgr6e4oBvPxm/nHJv Cr+tq0XLoSmcSzjMvU/tZPUB7qO4Y3HPaPmF67d28PFS1u6tmbp8c0XSR2WjMUrnOQqu y+h62FSPDyr8fZfdLOXqTWXp5p7rByIQB2y8wtsLZgrkDyTkqlCdYgFrLbJ4c+TIaIMo QnoLzeRFTrpcLFBKYemRZCqE5FP0Mt2CZKhWdiHSzYYFcmopPMoq1JOJoDiFq5elaiME VCFoQ2NBujMBKcaV5omsNizJlDJRe21lLEZDT6eGi2S7ws9GymrDXJITylZEcTB4R6dI PcfA== MIME-Version: 1.0 X-Received: by 10.180.103.74 with SMTP id fu10mr5947513wib.47.1408645305400; Thu, 21 Aug 2014 11:21:45 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 21 Aug 2014 11:21:45 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Thu, 21 Aug 2014 11:21:45 -0700 Message-ID: From: Martin Thomson To: Muthu Arul Mozhi Perumal Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/d9xws6AOSqok8YNROK7Eye2ge1A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:21:49 -0000 On 20 August 2014 21:16, Muthu Arul Mozhi Perumal wrote: > The elementary entity that needs to perform consent is a WebRTC entity that > runs untrusted applications -- essentially a WebRTC browser. That is incorrect. Any entity that receives peer transport information from elsewhere needs to perform consent. From nobody Thu Aug 21 11:25:41 2014 Return-Path: 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 5A9E21A049E for ; Thu, 21 Aug 2014 11:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 HZyA3Qb-RvDM for ; Thu, 21 Aug 2014 11:25:35 -0700 (PDT) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFA31A04A7 for ; Thu, 21 Aug 2014 11:25:35 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so9693041wes.21 for ; Thu, 21 Aug 2014 11:25:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zXDbm95Sxr5BwliNPkW0cFN+NCoulaCLCGFJ4SZz0Ug=; b=KWWeaxAwzAXYq7EtaGKCdBBbqniaVbmVyeGBbCJJPC8I5UOwZUTjrsW36rZkHs9/vE 4no62+7hkfLcV9v5Jx4R+zUmK3v8OnvyLL6r81jZaT5lw8VZLMbA0Pio3W88ql5xchs2 FDQVFdmPMSIg1Tl5o+xqXqBUqSPRXgg4IFIMESGDsZCyp71F11nFmBPRLeAnayEPCd8N aYqGdL7UfbI2ynIfV2vMn+dlippu0XIVy3vWpyuuqsMfIjfFKaXxrOXza6XcbvgBtizP dGxbpGyz6agyHUnJuJ3yl3c9vgBfJBVDKhIQ72xjVRjYFnhE6bL/v8VmGsm5Peg98Erf ceGg== X-Gm-Message-State: ALoCoQk4ymL0A5fSSiPq2FnUDwemMZ5etsLGuBXOU7kRJrLnsZoTsb7R+mj0c+ShEx2G3NWHLsW1 X-Received: by 10.194.205.129 with SMTP id lg1mr151427wjc.97.1408645533792; Thu, 21 Aug 2014 11:25:33 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by mx.google.com with ESMTPSA id ez1sm22421762wib.15.2014.08.21.11.25.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 11:25:33 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so9756616wes.37 for ; Thu, 21 Aug 2014 11:25:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.74.42 with SMTP id q10mr5959092wiv.39.1408645532710; Thu, 21 Aug 2014 11:25:32 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Thu, 21 Aug 2014 11:25:32 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Thu, 21 Aug 2014 14:25:32 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043c80d6978201050127d894 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ypNrbxpFPrzjxvs_7Lj1K5CH1-A Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:25:40 -0000 --f46d043c80d6978201050127d894 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 2:21 PM, Martin Thomson wrote: > On 20 August 2014 21:16, Muthu Arul Mozhi Perumal > wrote: > > The elementary entity that needs to perform consent is a WebRTC entity > that > > runs untrusted applications -- essentially a WebRTC browser. > > That is incorrect. Any entity that receives peer transport > information from elsewhere needs to perform consent. > > All entities receive peer transport information from elsewhere, including gateways running ICE-Lite. Does it mean all of them need to perform consent? Generally it would be trivial to use any public VoIP service to force it to send RTP traffic anywhere. It is not like this is a new problem. _____________ Roman Shpount --f46d043c80d6978201050127d894 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 21, 2014 at 2:= 21 PM, Martin Thomson <martin.thomson@gmail.com> wrot= e:
On 20 August 2014 21:16, Muthu = Arul Mozhi Perumal <muthu.arul@g= mail.com> wrote:
> The elementary entity that needs to perform consent is a WebRTC entity= that
> runs untrusted applications -- essentially a WebRTC browser.

That is incorrect.=C2=A0 Any entity that receives peer transport
information from elsewhere needs to perform consent.

=C2=A0
All entities receive peer transport information from el= sewhere, including gateways running ICE-Lite. Does it mean all of them need= to perform consent?

Generally it would be trivial to use any public VoIP se= rvice to force it to send RTP traffic anywhere. It is not like this is a ne= w problem.
_____________
Roman Shpount
=C2=A0
<= /div>
--f46d043c80d6978201050127d894-- From nobody Thu Aug 21 12:36:31 2014 Return-Path: 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 DD4FC1A0694 for ; Thu, 21 Aug 2014 12:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 qAdGVHhkF09j for ; Thu, 21 Aug 2014 12:36:28 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FDB1A0689 for ; Thu, 21 Aug 2014 12:36:28 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so9738220wes.35 for ; Thu, 21 Aug 2014 12:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wCumBAjkO9C0U4SE3sfLad461Juv1zalCAe56oWTNOA=; b=R91K6uoogQo0BdYZp0gBcCM+oNkEeiq0r17LZhfIT3S5jsS04LTB1SvEkvPA7YETml xKRK0C3qh600LSpHtrXCqNeyF0Ml4AimnkKUeBQ31AsrNvBNs8mRklAHkMI29OG82rnn 9iS0fKA5g3VKJ37as0cw8g4txASu+qX5BJHKtk+oBNaAnDaFVKG3pVwnQvkbhRkruv3c lFR9eOm94KFO1Myiw4GFolnB6GX3cN6XyoUV+PThwIoipYY/d5nnWpXbnUhrNa5/RbCX tFe0yr1reRs8CgzHAaAjlCECz50++QYz/SAHe1Yabl72kF0Wh1Hb4j4yjUw+dF8KdFdh 4Gdg== MIME-Version: 1.0 X-Received: by 10.194.63.37 with SMTP id d5mr609221wjs.92.1408649787131; Thu, 21 Aug 2014 12:36:27 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 21 Aug 2014 12:36:27 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Thu, 21 Aug 2014 12:36:27 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VgIfmn_XBXzQaeaYjSmdkLZiLZI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:36:30 -0000 On 21 August 2014 11:25, Roman Shpount wrote: > All entities receive peer transport information from elsewhere, including > gateways running ICE-Lite. Does it mean all of them need to perform consent? That's the logical conclusion, yes. From nobody Thu Aug 21 12:57:45 2014 Return-Path: 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 831BB1A0678 for ; Thu, 21 Aug 2014 12:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 1qcG7JP0nj16 for ; Thu, 21 Aug 2014 12:57:40 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A941A065F for ; Thu, 21 Aug 2014 12:57:39 -0700 (PDT) Received: from [192.168.1.200] (p508F1B3F.dip0.t-ipconnect.de [80.143.27.63]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6AC0B1C104DDD; Thu, 21 Aug 2014 21:57:37 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Thu, 21 Aug 2014 21:57:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CA15305-2A2B-4FC8-9B99-4A8DC4842AE1@lurchi.franken.de> References: To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_j93zcwJdA5shYtmPW3MbnlvC3Y Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] AD review of draft-ietf-rtcweb-data-protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:57:42 -0000 On 08 Aug 2014, at 22:27, Richard Barnes wrote: > I have reviewed this document in preparation for IETF LC. In general, = it looks good, and I have requested LC. There are some comments below = that should be addressed along with IETF LC comments. > --Richard Hi Richard, thank you very much for the review. See my comments in-line. Best regards Michael >=20 >=20 > MAJOR: >=20 > Section 4. "To avoid glare..." > The term "glare" is undefined in this document, and will probably be = unfamiliar to many readers. Please add it to the Terminology section. Right. It was introduced by a co-author and I hadn't read it before. = Maybe the best is to explicitly state what the problem is. So what about using To avoid collisions where both sides try to open a Data Channel with the same Stream Identifiers, each side MUST use Streams with either even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN message. When using SCTP over DTLS [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 Stream Identifiers, the side acting as the DTLS server MUST use Streams with odd Stream Identifiers. Note: There is no attempt to ensure uniqueness for the label; if both sides open a Data Channel labeled "x" at the same time, there will be two Data Channels labeled "x" - one on an even Stream pair, one on an odd pair. The protocol field is to ease cross-application interoperation ("federation") by identifying the user data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in [RFC6455]), and may be useful for homogeneous applications which may create more than one type of Data Channel. Please note that there is also no attempt to ensure uniqueness for the protocol field. >=20 > Section 4. "When using SCTP over DTLS..." > This qualification is unnecessary, since data channels always use = SCTP/DTLS/UDP: > """ > The DTLS encapsulation of SCTP packets as described in > [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. > """ > So this should be "Since data channels use the DTLS encapsulation of = SCTP..." The text is written in a way that you could use DCEP over SCTP not over = DTLS. That is why we have the qualification cited above and also this text in = the security considerations: This protocol does not provide privacy, integrity or authentication. It needs to be used as part of a protocol suite that contains all these things. Such a protocol suite is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. So is it OK to keep the current text? >=20 > Section 6. "... all parameters in the DATA_CHANNEL_OPEN message are = valid" > The receiver MUST fail if the parameters are invalid, but you never = define what validation needs to be performed. For example, is the DCEP = layer supposed to verify that the Protocol and Label fields are valid = UTF-8? All parameters have to be checked (normal input validation of a = receiver, I would say): ChannelType: Is it one of the supported values? Priority: Is it a value the receiver wants to work with? There are four = values specified. Reliability Parameter: Is it one of the supported values? Label Length, Protocol Length: Does the packet contain exactly Label = Length + Protocol Length + 12 bytes? Label: Valid UTF-8? Protocol: Valid UTF-8? I would expect any receiver to do the above checks as normal input = validation. If you prefer, I can add explicit text. >=20 > Section 10.2. [I-D.ietf-rtcweb-data-channel] > This reference needs to be normative, since, after all, this is a = protocol for negotiating data channels. OK. >=20 >=20 >=20 > MINOR / EDITORIAL: >=20 > Section 5.1. [packet diagram] > The diagram seems to imply that the protocol field starts on a 4-octet = boundary, even though this is not true. It might be good if you could = find a way to reformat the diagram to make this clearer. If you can point me to an example figure you like, please do. We used = this kind of figure in several RFC for SCTP and don't assume that the figure = implies that the packet starts on a 4 byte boundary. It just shows 32 bits in a = row, starting from the beginning of the packet. >=20 > Section 5.1. "The suggested value of this field for IANA is 0x03" > You're defining the initial contents of this registry. Just say it. = Likewise for the same text in Section 5.2. OK. What about using in Section 5.1 Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the DATA_CHANNEL_OPEN message. The value of this field is 0x03 as specified in Section 8.2.1. and in Section 5.2 Message Type: 1 byte (unsigned integer) This field holds the IANA defined message type for the DATA_CHANNEL_ACK message. The value of this field is 0x02 as specified in Section 8.2.1. >=20 > Section 6. "an Stream identifier" -> "a stream identifier" I would prefer to change it to a Stream Identifier, since we define = 'Stream Identifier' in the Terminology section. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Aug 21 12:57:57 2014 Return-Path: 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 235981A06D3 for ; Thu, 21 Aug 2014 12:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 ruq-4YVm8wYp for ; Thu, 21 Aug 2014 12:57:43 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257111A065F for ; Thu, 21 Aug 2014 12:57:43 -0700 (PDT) Received: from [192.168.1.200] (p508F1B3F.dip0.t-ipconnect.de [80.143.27.63]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0C0411C104DF1; Thu, 21 Aug 2014 21:57:40 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53E90E9E.6070706@alum.mit.edu> Date: Thu, 21 Aug 2014 21:57:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53E90E9E.6070706@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Wdj0NAESqj_Uob2s27gCtMKUZKk Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some final comments on draft-ietf-rtcweb-data-protocol-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:57:45 -0000 On 11 Aug 2014, at 20:42, Paul Kyzivat wrote: > I just did another read-through of this draft, and identified a few = things that I think need to be cleared up: Hi Paul, thanks for bringing these points up. See my comments in-line. Best regards Michael >=20 > IIUC the data channel APIs expect that all channels, even those = defined out of band, have a well defined set of properties. But those = properties are defined in *this* draft that applies only to channels = created using DCEP. OTOH, draft-ietf-rtcweb-data-channel-11 is much more = vague about channel properties. For out-of-band these properties don't have to be the same in both = directions. That is why this ID says: The Data Channel Establishment Protocol is a simple, low-overhead way to establish bidirectional Data Channels over an SCTP association with a consistent set of properties. The set of consistent properties includes: For in-band the properties have to be the same in both directions. >=20 > ISTM that most of the channel property specification should be moved = to, or replicated in, draft-ietf-rtcweb-data-channel. I can list them there, if you think it is clearer. But they don't have = to be the same in both directions. >=20 > And this extends to the definitions for Channel Type, Priority, and = Reliability since those also are intended to apply for the data channel = API for channels defined out of band. In draft-ietf-rtcweb-data-channel, Section 6.1, the reliability is = described, in Section 6.4 the priority is described. Maybe we should describe them all together in = Section 6.4. Would that address your issue? >=20 > Alternatively, the data channel document could more extensively cross = reference this document, or the two documents could be merged into one. >=20 > One more thing - section 4 says: >=20 > Please note that > there is also no attempt to resolve protocol glare. >=20 > I cannot figure out what this means. It is unambiguous which end is = creating the channel, and that end is *declaring* the protocol to be = used on it. There is no possibility of glare. I changed the text to: To avoid collisions where both sides try to open a Data Channel with the same Stream Identifiers, each side MUST use Streams with either even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN message. When using SCTP over DTLS [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 Stream Identifiers, the side acting as the DTLS server MUST use Streams with odd Stream Identifiers. Note: There is no attempt to ensure uniqueness for the label; if both sides open a Data Channel labeled "x" at the same time, there will be two Data Channels labeled "x" - one on an even Stream pair, one on an odd pair. The protocol field is to ease cross-application interoperation ("federation") by identifying the user data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in [RFC6455]), and may be useful for homogeneous applications which may create more than one type of Data Channel. Please note that there is also no attempt to ensure uniqueness for the protocol field. Is this clearer? >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Thu Aug 21 13:24:18 2014 Return-Path: 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 BBB861A06F3 for ; Thu, 21 Aug 2014 13:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 3MQPEnS_bm_d for ; Thu, 21 Aug 2014 13:24:14 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF921A06D3 for ; Thu, 21 Aug 2014 13:24:14 -0700 (PDT) Received: from owa.genband.com (97.65.224.12 [97.65.224.12]) (Using TLS) by us-mta-6.us.mimecast.lan; Thu, 21 Aug 2014 16:24:11 -0400 Received: from GBPLMAIL02.genband.com ([fe80::9455:4039:582f:aee8]) by GBEX01.genband.com ([::1]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 15:24:10 -0500 From: Jeremy Fuller To: "harald@alvestrand.no" Thread-Topic: WebRTC gateway - draft-ietf-rtcweb-overview-11.txt Thread-Index: Ac+9fWS087JAIU5pTOeb7AlhS3h9NA== Date: Thu, 21 Aug 2014 20:24:09 +0000 Message-ID: <3DF911000D80F6459928AC50D3D742F601A509@gbplmail02.genband.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.21.173] MIME-Version: 1.0 X-MC-Unique: NMOq5z1AR7aRxRN_EqSSAg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Qh8iLa4tilkr4GI3nrWSnh0Jz70 Cc: "rtcweb@ietf.org" Subject: [rtcweb] WebRTC gateway - draft-ietf-rtcweb-overview-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 20:24:17 -0000 Hi Harald, With regard to your addition of the WebRTC gateway in the rtcweb overview. = I appreciate signalling is out of scope for WebRTC, but as you say in your = draft alvestrand-rtcweb-gateways-00.txt "any practical gateway needs to dea= l with signalling". Without getting into too much detail or any implementat= ion constraints, would it be possible to add a reference to signalling when= introducing the WebRTC gateway? I have suggested some modified text below for your consideration: Current Text (section 1): "A WebRTC gateway is something that mediates media traffic to non-WebRTC en= tities. It is like a device, but has certain restrictiions on where it can= operate, which means that some of the requirements can be relaxed." Proposed Text (section 1): "A WebRTC gateway is something that mediates media traffic, or signalling, = or both, to non-WebRTC entities. It is like a device, but has certain rest= rictions on where it can operate, which means that some of the requirements= can be relaxed." Regards, Jeremy -----Original Message----- Date: Mon, 18 Aug 2014 04:19:16 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-11.txt Message-ID: <20140818111916.2857.63981.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers W= orking Group of the IETF. Title : Overview: Real Time Protocols for Browser-based A= pplications Author : Harald T. Alvestrand =09Filename : draft-ietf-rtcweb-overview-11.txt =09Pages : 22 =09Date : 2014-08-18 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications RTCWEB compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-overview-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-overview-11 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 21 14:15:59 2014 Return-Path: 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 F07EF1A8A08 for ; Thu, 21 Aug 2014 14:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 eGo5LzaUmvDr for ; Thu, 21 Aug 2014 14:15:50 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4CA1A8A0C for ; Thu, 21 Aug 2014 14:15:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E8E047C3E9B; Thu, 21 Aug 2014 23:15:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BfjOij+2Ifk; Thu, 21 Aug 2014 23:15:47 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:25c8:275d:8974:2c6b] (unknown [IPv6:2001:470:de0a:27:25c8:275d:8974:2c6b]) by mork.alvestrand.no (Postfix) with ESMTPSA id 574397C3E7E; Thu, 21 Aug 2014 23:15:47 +0200 (CEST) Message-ID: <53F66180.6050308@alvestrand.no> Date: Thu, 21 Aug 2014 23:15:44 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jeremy Fuller References: <3DF911000D80F6459928AC50D3D742F601A509@gbplmail02.genband.com> In-Reply-To: <3DF911000D80F6459928AC50D3D742F601A509@gbplmail02.genband.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/YMeeGfQFrJT4eSQoxTsmn5eU_go Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC gateway - draft-ietf-rtcweb-overview-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 21:15:56 -0000 On 08/21/2014 10:24 PM, Jeremy Fuller wrote: > Hi Harald, > > With regard to your addition of the WebRTC gateway in the rtcweb overview. I appreciate signalling is out of scope for WebRTC, but as you say in your draft alvestrand-rtcweb-gateways-00.txt "any practical gateway needs to deal with signalling". Without getting into too much detail or any implementation constraints, would it be possible to add a reference to signalling when introducing the WebRTC gateway? > > I have suggested some modified text below for your consideration: > > Current Text (section 1): > "A WebRTC gateway is something that mediates media traffic to non-WebRTC entities. It is like a device, but has certain restrictiions on where it can operate, which means that some of the requirements can be relaxed." > > Proposed Text (section 1): > "A WebRTC gateway is something that mediates media traffic, or signalling, or both, to non-WebRTC entities. It is like a device, but has certain restrictions on where it can operate, which means that some of the requirements can be relaxed." This does not work for me. A WebRTC gateway has to handle media, because it's the transport of media that WebRTC specifies. A pure signalling gateway would just transform the signalling between two WebRTC-capable endpoints (WebRTC endpoints?); this is what an application does, not what a WebRTC gateway does. There might be a need to name the class of applications that transform signalling; I'm not sure. > > Regards, > Jeremy > > > -----Original Message----- > Date: Mon, 18 Aug 2014 04:19:16 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-11.txt > Message-ID: <20140818111916.2857.63981.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. > > Title : Overview: Real Time Protocols for Browser-based Applications > Author : Harald T. Alvestrand > Filename : draft-ietf-rtcweb-overview-11.txt > Pages : 22 > Date : 2014-08-18 > > Abstract: > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This document is an Applicability Statement - it does not itself > specify any protocol, but specifies which other specifications RTCWEB > compliant implementations are supposed to follow. > > This document is a work item of the RTCWEB working group. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-11 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > From nobody Thu Aug 21 22:26:12 2014 Return-Path: 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 865581A0054 for ; Thu, 21 Aug 2014 22:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 Gbd5WYcwuB_v for ; Thu, 21 Aug 2014 22:25:55 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1E11A0053 for ; Thu, 21 Aug 2014 22:25:54 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so10222367wes.4 for ; Thu, 21 Aug 2014 22:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=POvhw7zvmlHT5At6nJAe6LLsp/SfUC3E7BFue+Qmw6w=; b=M2f3IWa49OhOmNTmlL3qFAykcDcLMB8XQDiV4mvv3RQDhg3lvdYOhgmxfDIeIY4Yyp pq2l/1BQxyBEJxL86jWLLUUEPxZ275oNWXLgb2QPHySATcPQkcaU+sO7L3QgykKUtKBb KareYQK8E8o4azPWFA1+ccYgItM+vpo4fz2hpAlD4hxZWamQsEOVbzt5JgXfPac8UOFn 7AZmSWaMNgj+2gEOExUx34M7FKiU8ZWk7lHHmRUaqAdCXhy2c+RXG2OkdIMOs4Xb0jY3 hrBUxlWQkIZL/CajLT20Kli+TzkMSH+0MLvAhg+mZyagETH6Tl6nNwuoCVVybrFYTk/Q 4fRQ== MIME-Version: 1.0 X-Received: by 10.180.73.139 with SMTP id l11mr8524283wiv.30.1408685153181; Thu, 21 Aug 2014 22:25:53 -0700 (PDT) Received: by 10.180.14.65 with HTTP; Thu, 21 Aug 2014 22:25:53 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Fri, 22 Aug 2014 10:55:53 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043c07de27e51505013112ef Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wGy_T6qNca0ZD__7fUj4-8EYnnQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 05:25:56 -0000 --f46d043c07de27e51505013112ef Content-Type: text/plain; charset=UTF-8 ICE-lite entities don't even perform connectivity checks. Requiring they perform consent freshness doesn't seem to make sense to me (of course, we can come up with a new spec ICE-lite-with-consent, but that's a different problem). I am not saying you can't spoof a public VoIP service to send RTP anywhere. Legacy ICE entities perform connectivity checks today and not consent and consent freshness. Do we want to make them more secure? Sure. It however is a problem of different scope and need to be solved in MMUSIC or elsewhere, IMHO. draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser more secure. It however allows an RTP endpoint (that also does ICE) to use the mechanism to make it more secure or compute RTT or carry network information or whatever. However, requiring every RTP endpoint perform it seems asking too much. My take: WebRTC browser - MUST WebRTC devide - SHOULD Other RTP entities (including WebRTC gateway) - MAY Thoughts? Muthu On Fri, Aug 22, 2014 at 1:06 AM, Martin Thomson wrote: > On 21 August 2014 11:25, Roman Shpount wrote: > > All entities receive peer transport information from elsewhere, including > > gateways running ICE-Lite. Does it mean all of them need to perform > consent? > > That's the logical conclusion, yes. > --f46d043c07de27e51505013112ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ICE-lite entities don't even perfor= m connectivity checks. Requiring they perform consent freshness doesn't= seem to make sense to me (of course, we can come up with a new spec ICE-li= te-with-consent, but that's a different problem).

I am not saying you can'= ;t spoof a public VoIP service to send RTP anywhere. Legacy ICE entities pe= rform connectivity checks today and not consent and consent freshness. Do w= e want to make them more secure? Sure. It however is a problem of different= scope and need to be solved in MMUSIC or elsewhere, IMHO.

draft-ietf-rtcweb-stun-consent-freshness = is about making the WebRTC browser more secure. It however allows an RTP en= dpoint (that also does ICE) to use the mechanism to make it more secure or = compute RTT or carry network information or whatever. However, requiring ev= ery RTP endpoint perform it seems asking too much.

My take:
WebRTC browser - MUST
WebRTC devide - SHOULD
Other RTP entities (including= WebRTC gateway) - MAY

Thoughts?

Muthu

On Fri, A= ug 22, 2014 at 1:06 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 21 August 2014 11:25, Roman Shpount <= ;roman@telurix.com> wrote:
> All entities receive peer transport information from elsewhere, includ= ing
> gateways running ICE-Lite. Does it mean all of them need to perform co= nsent?

That's the logical conclusion, yes.

--f46d043c07de27e51505013112ef-- From nobody Fri Aug 22 01:34:42 2014 Return-Path: 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 B91B71A017D for ; Fri, 22 Aug 2014 01:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 JVas1rV2PJG4 for ; Fri, 22 Aug 2014 01:34:38 -0700 (PDT) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535D61A017A for ; Fri, 22 Aug 2014 01:34:37 -0700 (PDT) Received: from owa.genband.com (97.65.224.12 [97.65.224.12]) (Using TLS) by us-mta-11.us.mimecast.lan; Fri, 22 Aug 2014 04:34:34 -0400 Received: from GBPLMAIL02.genband.com ([fe80::9455:4039:582f:aee8]) by GBEX01.genband.com ([::1]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 03:34:33 -0500 From: Jeremy Fuller To: Harald Alvestrand Thread-Topic: WebRTC gateway - draft-ietf-rtcweb-overview-11.txt Thread-Index: Ac+9fWS087JAIU5pTOeb7AlhS3h9NAAMZWwAAAzHYxA= Date: Fri, 22 Aug 2014 08:34:32 +0000 Message-ID: <3DF911000D80F6459928AC50D3D742F601AA20@gbplmail02.genband.com> References: <3DF911000D80F6459928AC50D3D742F601A509@gbplmail02.genband.com> <53F66180.6050308@alvestrand.no> In-Reply-To: <53F66180.6050308@alvestrand.no> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.21.173] MIME-Version: 1.0 X-MC-Unique: YT0f-LVmSpa_aM7VN2ojEw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BnlapOM9DhXu01Fm0C-645Y0zn8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC gateway - draft-ietf-rtcweb-overview-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 08:34:40 -0000 Hi Harald,=20 It would be good to have something which explains to the reader that there = exists functionality for transforming signalling. I am reasonably flexible = on the term used. I proposed associating this functionality with the term W= ebRTC Gateway to reduce the proliferation of new terms. =20 Regards, Jeremy -----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: 21 August 2014 22:16 To: Jeremy Fuller Cc: rtcweb@ietf.org Subject: Re: WebRTC gateway - draft-ietf-rtcweb-overview-11.txt On 08/21/2014 10:24 PM, Jeremy Fuller wrote: > Hi Harald, > > With regard to your addition of the WebRTC gateway in the rtcweb overview= . I appreciate signalling is out of scope for WebRTC, but as you say in you= r draft alvestrand-rtcweb-gateways-00.txt "any practical gateway needs to d= eal with signalling". Without getting into too much detail or any implement= ation constraints, would it be possible to add a reference to signalling wh= en introducing the WebRTC gateway? > > I have suggested some modified text below for your consideration: > > Current Text (section 1): > "A WebRTC gateway is something that mediates media traffic to non-WebRTC = entities. It is like a device, but has certain restrictiions on where it c= an operate, which means that some of the requirements can be relaxed." > > Proposed Text (section 1): > "A WebRTC gateway is something that mediates media traffic, or signalling= , or both, to non-WebRTC entities. It is like a device, but has certain re= strictions on where it can operate, which means that some of the requiremen= ts can be relaxed." This does not work for me. A WebRTC gateway has to handle media, because it= 's the transport of media that WebRTC specifies. A pure signalling gateway = would just transform the signalling between two WebRTC-capable endpoints (W= ebRTC endpoints?); this is what an application does, not what a WebRTC gate= way does. There might be a need to name the class of applications that transform sign= alling; I'm not sure. > > Regards, > Jeremy > > > -----Original Message----- > Date: Mon, 18 Aug 2014 04:19:16 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-11.txt > Message-ID: <20140818111916.2857.63981.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Real-Time Communication in WEB-browser= s Working Group of the IETF. > > Title : Overview: Real Time Protocols for Browser-base= d Applications > Author : Harald T. Alvestrand > =09Filename : draft-ietf-rtcweb-overview-11.txt > =09Pages : 22 > =09Date : 2014-08-18 > > Abstract: > This document gives an overview and context of a protocol suite > intended for use with real-time applications that can be deployed in > browsers - "real time communication on the Web". > > It intends to serve as a starting and coordination point to make sure > all the parts that are needed to achieve this goal are findable, and > that the parts that belong in the Internet protocol suite are fully > specified and on the right publication track. > > This document is an Applicability Statement - it does not itself > specify any protocol, but specifies which other specifications RTCWEB > compliant implementations are supposed to follow. > > This document is a work item of the RTCWEB working group. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-overview-11 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > From nobody Fri Aug 22 06:37:18 2014 Return-Path: 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 0A4251A03E1 for ; Fri, 22 Aug 2014 06:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 nWszK9iw6Tlj for ; Fri, 22 Aug 2014 06:37:14 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4671A03E3 for ; Fri, 22 Aug 2014 06:37:14 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so10706424wes.4 for ; Fri, 22 Aug 2014 06:37:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3vMHYASA/COqg4vVmVcwcUkHjJZdjvEXsIhtvQbIbcg=; b=kdxcTXUcLblqxFv/TDCtvTws5M4ZUbtZqwdNqDsaLHVfNCVSSgGdBGc6KITdaK3dbm A2SlXeHUkW6ODC3cPYvEIY+lxvAQCN5UAeCv81AJkbyQEpNAdLKQmMxuZh4KBCBKocRW Btp7njJfwrtMYVkNuQcXqb0OnhXYvFO/HDM/Sp95kSAtrQybHpAFt8ZMpUTg8DBXSSzH O+loswpd0sxj25hsqHqchMo/dusb4ponoZHz6E+14mSC5yTD6sSJcjeUzo1HBeWH/SXg svskwSQu0cUs6WkdcgOI8SK6J2OPtwD9+8RweahB2AcI9vcASvxAa13Jkpnx3rrDKOy6 nGqg== X-Gm-Message-State: ALoCoQnAbiavcGPySWJZM7ClxI6BAJZ04Oea1j8qyEJj4jb5mSLq0Kk65qHw5FjDyl1vJ2ZdRhIy X-Received: by 10.180.211.172 with SMTP id nd12mr10798818wic.74.1408714632901; Fri, 22 Aug 2014 06:37:12 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by mx.google.com with ESMTPSA id pl7sm11774930wjc.43.2014.08.22.06.37.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Aug 2014 06:37:11 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so10741899wes.10 for ; Fri, 22 Aug 2014 06:37:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.80.105 with SMTP id q9mr29421643wix.39.1408714631653; Fri, 22 Aug 2014 06:37:11 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Fri, 22 Aug 2014 06:37:11 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Fri, 22 Aug 2014 09:37:11 -0400 Message-ID: From: Roman Shpount To: Muthu Arul Mozhi Perumal Content-Type: multipart/alternative; boundary=f46d04428e3e35b13c050137efbc Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/SdzMn_LU92KiS0cRLbKnMMaRc_E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 13:37:16 -0000 --f46d04428e3e35b13c050137efbc Content-Type: text/plain; charset=UTF-8 On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal < muthu.arul@gmail.com> wrote: > draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC > browser more secure. It however allows an RTP endpoint (that also does ICE) > to use the mechanism to make it more secure or compute RTT or carry network > information or whatever. However, requiring every RTP endpoint perform it > seems asking too much. > > My take: > WebRTC browser - MUST > WebRTC devide - SHOULD > Other RTP entities (including WebRTC gateway) - MAY > > I would say that all full ICE endpoint interworking with WebRTC MUST implement consent freshness. ICE-LITE will not implement, but MUST respond (unless someone defines it, but once you start sending STUN request you might as well do full ICE, so I do not see much point in it). And to conclude strongly encourage full ICE implementation for security and other reasons. _____________ Roman Shpount --f46d04428e3e35b13c050137efbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 22, 2014 at 1:= 25 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wr= ote:
draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser= more secure. It however allows an RTP endpoint (that also does ICE) to use= the mechanism to make it more secure or compute RTT or carry network infor= mation or whatever. However, requiring every RTP endpoint perform it seems = asking too much.

My take:
WebRTC browser - MUST
WebRTC devide - SHOULD<= /font>
Other RTP enti= ties (including WebRTC gateway) - MAY

=C2=A0
=C2=A0I would say t= hat all full ICE endpoint interworking with WebRTC MUST implement consent f= reshness. ICE-LITE will not implement, but MUST respond (unless someone def= ines it, but once you start sending STUN request you might as well do full = ICE, so I do not see much point in it). And to conclude strongly encourage = full ICE implementation for security and other reasons.
_____________
Roman Shpount
=C2=A0
--f46d04428e3e35b13c050137efbc-- From nobody Fri Aug 22 08:38:28 2014 Return-Path: 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 8A3721A0584 for ; Fri, 22 Aug 2014 08:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 JRFd-qpOQGv4 for ; Fri, 22 Aug 2014 08:38:25 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4085E1A03C0 for ; Fri, 22 Aug 2014 08:38:25 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id r5so10978247qcx.16 for ; Fri, 22 Aug 2014 08:38:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=hZWKwW4web3VZ2CNcvZhhhhTMXj03is18jn36O6oSWU=; b=eUpleNRmR0GHy5eHB6GyJIu+ZsEpypijKDrCjDwfvLczlYoKC3BmU5TkKEvombRIXl CQmeR4iOK/ApnYFET2xoN7SSK1wbwHfql+WmdtoKpTrgmkaaL7vLtFBXQLoc/zdyGXcj rTddzHjj0VmeQCTY6ueVOuJ9OJ0Ib45OgEQ76U4OTk84pKbQcLRYEkyFY3+9xXBLD9fF f4C+a5kMeq03f6TzbwDQ7b1RLzMhhM8X8kuLsOUGFWsd8bW1XV6VDIGyCwk+pmspCx2X PayRePt/+RQBICh71naILh1lzmeC+EAmDGtPBVX0RB8DLR0nkYPP63/48t9ZkmTJWUwW jh8A== X-Gm-Message-State: ALoCoQnBWGB4wFKyXbQ2cjvzCA1+Pc3qQH89kKxAPEdRERpB+Zu7DgNJONhDHUjqphBIJANHnjns X-Received: by 10.224.46.8 with SMTP id h8mr9532702qaf.6.1408721904285; Fri, 22 Aug 2014 08:38:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Fri, 22 Aug 2014 08:38:04 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 22 Aug 2014 17:38:04 +0200 Message-ID: To: draft-ietf-rtcweb-transports@tools.ietf.org, "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Ibxb_mwYDbSnqFfT9zgcdkkZ5QY Subject: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:38:26 -0000 Hi, draft-ietf-rtcweb-transports-06 says: If TCP connections are used, RTP framing according to [RFC4571] MUST be used, both for the RTP packets and for the DTLS packets used to carry data channels. Not just RTP and DTLS, but also for STUN packets must be framed with RFC4571. And I do not understand why "DTLS packets used to carry data channels". In fact all the DTLS packets (also the ones for the handshake) must be framed as per RFC 4571. So I suggest to improve the above text as follows: If TCP connections are used, RTP framing according to [RFC4571] MUST be used for the STUN packets, SRTP packets, SRTCP packets and DTLS packets. --=20 I=C3=B1aki Baz Castillo From nobody Fri Aug 22 08:59:16 2014 Return-Path: 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 9B4431A0312 for ; Fri, 22 Aug 2014 08:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 mGGca_EwpaiY for ; Fri, 22 Aug 2014 08:59:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB671A0164 for ; Fri, 22 Aug 2014 08:59:12 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-70-53f768ce2311 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F8.88.24955.EC867F35; Fri, 22 Aug 2014 17:59:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0174.001; Fri, 22 Aug 2014 17:59:09 +0200 From: Christer Holmberg To: Roman Shpount , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPvPawrVflDV3yCU6CP1aFBYsSYJvbPhKAgAABDwCAABPQgIAApK+AgACJRYCAAEiyvg== Date: Fri, 22 Aug 2014 15:59:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D427B68ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rvdcxvdgg5bdChZ/NvtZzLgwldli 7b92dgdmj52z7rJ7LFnyk8nj1pSCAOYoLpuU1JzMstQifbsEroz3GyazFlxXrzhwaApTA+N1 xS5GTg4JAROJubv+MUHYYhIX7q1n62Lk4hASOMoo8XXWEXYIZwmjxN41t1i7GDk42AQsJLr/ aYM0iAhESLxau4oZxGYWUJe4s/gcO4gtLBAosfjnL1aImiCJaZ0zmUFaRQTCJE4cDAUJswio SvS2PQEr4RXwlbjdNIUFYtUZVokvs0+DJTiB5tw7c44NxGYEOu77qTVMELvEJW49mQ91tIDE kj3nmSFsUYmXj/+BnSkhoCixvF8OojxfYvVDiHJeAUGJkzOfsExgFJ2FZNIsJGWzkJRBxPUk bkydwgZha0ssW/iaGcLWlZjx7xALsvgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIHR d3DLb9UdjJffOB5iFOBgVOLhfeDzPViINbGsuDL3EKM0B4uSOO/Cc/OChQTSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTBmreGL6Zy6ePbX6PInJdOfvNBWnfPYXadsib9+xbffqwL3Pj21birX 3NO6D2xnHX739dovzb0/zC7O5pbh4poZUNxTusaPKUtGi+fosWuCzl6/1KrlV97Y7382L+lB 4PrFt4rs67fda+dZ+TmeeYJR8JILAs9O2X5Z4L1+ltGO5fdergvt2+gSrcRSnJFoqMVcVJwI AH6aOESfAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/pWRZDUUamX2T-dml7xfTYaidFbQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:59:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D427B68ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, An ICE-lite endpoint must already today *REPLY* to STUN requests - consent = freshness does not change that. But, I don't think an ICE-lite endpoint shall be mandated to *SEND* consent= freshness requests. Regards, Christer ________________________________ From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Roman Shpount [roman@te= lurix.com] Sent: Friday, 22 August 2014 4:37 PM To: Muthu Arul Mozhi Perumal Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-fresh= ness On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal > wrote: draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser= more secure. It however allows an RTP endpoint (that also does ICE) to use= the mechanism to make it more secure or compute RTT or carry network infor= mation or whatever. However, requiring every RTP endpoint perform it seems = asking too much. My take: WebRTC browser - MUST WebRTC devide - SHOULD Other RTP entities (including WebRTC gateway) - MAY I would say that all full ICE endpoint interworking with WebRTC MUST imple= ment consent freshness. ICE-LITE will not implement, but MUST respond (unle= ss someone defines it, but once you start sending STUN request you might as= well do full ICE, so I do not see much point in it). And to conclude stron= gly encourage full ICE implementation for security and other reasons. _____________ Roman Shpount --_000_7594FB04B1934943A5C02806D1A2204B1D427B68ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

An ICE-lite endpoint must already today *REPLY* to STUN requests - = consent freshness does not change that.

 

But, I don't think an ICE-lite endpoint shall be mandated to *SEND* cons= ent freshness requests.

 

Regards,

 

Christer

 

 

From: rtcweb [rtcweb-bounces@ietf.org] on = behalf of Roman Shpount [roman@telurix.com]
Sent: Friday, 22 August 2014 4:37 PM
To: Muthu Arul Mozhi Perumal
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consen= t-freshness

On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal <muthu.a= rul@gmail.com> wrote:
dr= aft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser m= ore secure. It however allows an RTP endpoint (that also does ICE) to use t= he mechanism to make it more secure or compute RTT or carry network information or whatever. However, requirin= g every RTP endpoint perform it seems asking too much.

My take:
WebRTC browser - MUST
WebRTC devide - SHOULD
Other RTP entities (includ= ing WebRTC gateway) - MAY

 
 I would say that all full ICE endpoint interworking with WebRTC = MUST implement consent freshness. ICE-LITE will not implement, but MUST res= pond (unless someone defines it, but once you start sending STUN request yo= u might as well do full ICE, so I do not see much point in it). And to conclude strongly encourage full ICE imp= lementation for security and other reasons.
_____________
Roman Shpount
 
--_000_7594FB04B1934943A5C02806D1A2204B1D427B68ESESSMB209erics_-- From nobody Fri Aug 22 09:18:33 2014 Return-Path: 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 5271D1A0233 for ; Fri, 22 Aug 2014 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 J_eJsUYS7Mj8 for ; Fri, 22 Aug 2014 09:18:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D4B1A0164 for ; Fri, 22 Aug 2014 09:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8991; q=dns/txt; s=iport; t=1408724306; x=1409933906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=98MQmgiUZ0NtR0KJ6Tj46ILma7xsX7/Tfdb8ieuAV70=; b=kVRSYtGhbxCoZeNnMR3RRbf7Hj3o6XuSSnnsiOHmvZgsi9CytZQsEhO6 RxvKaae+kpertXMwb+lGjwLJ/0uvWu+v4rtk1xoHJDHu6j/dlbygUGJGD 7ZyJ/yBcRQmkA8RymJF1DgAFhLHz+VVkF+F/HMUPLb7EvrAB3iKzIxBJA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooFAJhs91OtJA2E/2dsb2JhbABZgkdGU1cEyneBZYdKAYEOFneEAwEBAQQdXBACAQgRAwEBASgHIREUCQgCBAENBYguAxENvykNhRkXjR+CHBEGAYRMBZEmhCmEaoIQgViMf4Y1g15sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208,217";a="349533200" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 22 Aug 2014 16:18:24 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7MGIOpc025930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:18:24 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.174]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 11:18:24 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , Roman Shpount , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPviSytsP8Fi+4skKmwMIEhdYf8A== Date: Fri, 22 Aug 2014 16:18:23 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.41.47] Content-Type: multipart/alternative; boundary="_000_D01D6B42104F8rmohanrciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5HSuyS0h_QO9DZUAM7gv6Vq1o9s Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:18:28 -0000 --_000_D01D6B42104F8rmohanrciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Right. I think we had discussed this in the past and added the below text i= n the draft " WebRTC endpoints are required to support full ICE as specified in section 3.4 of [I-D.ietf-rtcweb-transports].= However, when WebRTC endpoints interwork with other endpoints that support only ICE-lite (e.g. gateways) those endpoints will not generate consent checks, but just respond to consent checks they receive=94 Isn=92t this sufficient ? Ram From: Christer Holmberg > Date: Friday, 22 August 2014 9:29 pm To: Roman Shpount >, Muthu Arul= Mozhi Perumal > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-fresh= ness Hi, An ICE-lite endpoint must already today *REPLY* to STUN requests - consent = freshness does not change that. But, I don't think an ICE-lite endpoint shall be mandated to *SEND* consent= freshness requests. Regards, Christer ________________________________ From: rtcweb [rtcweb-bounces@ietf.org] on b= ehalf of Roman Shpount [roman@telurix.com] Sent: Friday, 22 August 2014 4:37 PM To: Muthu Arul Mozhi Perumal Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-fresh= ness On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal > wrote: draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser= more secure. It however allows an RTP endpoint (that also does ICE) to use= the mechanism to make it more secure or compute RTT or carry network infor= mation or whatever. However, requiring every RTP endpoint perform it seems = asking too much. My take: WebRTC browser - MUST WebRTC devide - SHOULD Other RTP entities (including WebRTC gateway) - MAY I would say that all full ICE endpoint interworking with WebRTC MUST imple= ment consent freshness. ICE-LITE will not implement, but MUST respond (unle= ss someone defines it, but once you start sending STUN request you might as= well do full ICE, so I do not see much point in it). And to conclude stron= gly encourage full ICE implementation for security and other reasons. _____________ Roman Shpount --_000_D01D6B42104F8rmohanrciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <84613A82A51CED40B7F71E68AE753488@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Right. I think we had discussed this in the past and added the below t= ext in the draft

" WebRTC endpoints are required t= o support full ICE as specified in
   section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
   endpoints interwork with other endpoints that support only ICE-lite
   (e.g. gateways) those endpoints will not generate consent checks, but
   just respond to consent checks they receive=94

Isn=92t this sufficient ?

Ram

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday, 22 August 2014 9:29 p= m
To: Roman Shpount <roman@telurix.com>, Muthu Arul Mozhi Perumal= <muthu.arul@gmail.com> Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: Re: [rtcweb] WG Last Call = for draft-ietf-rtcweb-stun-consent-freshness

Hi,

 

An ICE-lite endpoint must already today *REPLY* to STUN requests - = consent freshness does not change that.

 

But, I don't think an ICE-lite endpoint shall be mandated to *SEND* cons= ent freshness requests.

 

Regards,

 

Christer

 

 

From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Roman Shpount [roman@telurix.com]
Sent: Friday, 22 August 2014 4:37 PM
To: Muthu Arul Mozhi Perumal
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consen= t-freshness

On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal <muthu.a= rul@gmail.com> wrote:
dr= aft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser m= ore secure. It however allows an RTP endpoint (that also does ICE) to use t= he mechanism to make it more secure or compute RTT or carry network information or whatever. However, requirin= g every RTP endpoint perform it seems asking too much.

My take:
WebRTC browser - MUST=
WebRTC devide - SHOULD
Other RTP entities (includin= g WebRTC gateway) - MAY

 
 I would say that all full ICE endpoint interworking with WebRTC = MUST implement consent freshness. ICE-LITE will not implement, but MUST res= pond (unless someone defines it, but once you start sending STUN request yo= u might as well do full ICE, so I do not see much point in it). And to conclude strongly encourage full ICE imp= lementation for security and other reasons.
_____________
Roman Shpount
 
 --_000_D01D6B42104F8rmohanrciscocom_-- From nobody Fri Aug 22 09:22:08 2014 Return-Path: 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 152411A04E8 for ; Fri, 22 Aug 2014 09:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 ZbJ3iROIk8q0 for ; Fri, 22 Aug 2014 09:22:04 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB77C1A03ED for ; Fri, 22 Aug 2014 09:22:01 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id CAF24DE874284; Fri, 22 Aug 2014 16:21:58 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s7MGM0sc002019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 12:22:00 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Fri, 22 Aug 2014 12:22:00 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Muthu Arul Mozhi Perumal , Martin Thomson Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPvCyeYIc/MFSTfk+VKNIJfUtwNpvZX8mAgAIBcQCAABTbAYAA57WAgAAp6xA= Date: Fri, 22 Aug 2014 16:21:59 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E526CA4US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C-NgVIB3Ic2txVxFFW_kqd1J85I Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:22:07 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E526CA4US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PldlYlJUQyBicm93c2VyIC0gTVVTVA0KPldlYlJUQyBkZXZpZGUgLSBTSE9VTEQNCj5PdGhlciBS VFAgZW50aXRpZXMgKGluY2x1ZGluZyBXZWJSVEMgZ2F0ZXdheSkgLSBNQVkNCg0KKzENCg0KRnJv bTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN dXRodSBBcnVsIE1vemhpIFBlcnVtYWwNClNlbnQ6IEZyaWRheSwgQXVndXN0IDIyLCAyMDE0IDEy OjI2IEFNDQpUbzogTWFydGluIFRob21zb24NCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29u c2VudC1mcmVzaG5lc3MNCg0KSUNFLWxpdGUgZW50aXRpZXMgZG9uJ3QgZXZlbiBwZXJmb3JtIGNv bm5lY3Rpdml0eSBjaGVja3MuIFJlcXVpcmluZyB0aGV5IHBlcmZvcm0gY29uc2VudCBmcmVzaG5l c3MgZG9lc24ndCBzZWVtIHRvIG1ha2Ugc2Vuc2UgdG8gbWUgKG9mIGNvdXJzZSwgd2UgY2FuIGNv bWUgdXAgd2l0aCBhIG5ldyBzcGVjIElDRS1saXRlLXdpdGgtY29uc2VudCwgYnV0IHRoYXQncyBh IGRpZmZlcmVudCBwcm9ibGVtKS4NCg0KSSBhbSBub3Qgc2F5aW5nIHlvdSBjYW4ndCBzcG9vZiBh IHB1YmxpYyBWb0lQIHNlcnZpY2UgdG8gc2VuZCBSVFAgYW55d2hlcmUuIExlZ2FjeSBJQ0UgZW50 aXRpZXMgcGVyZm9ybSBjb25uZWN0aXZpdHkgY2hlY2tzIHRvZGF5IGFuZCBub3QgY29uc2VudCBh bmQgY29uc2VudCBmcmVzaG5lc3MuIERvIHdlIHdhbnQgdG8gbWFrZSB0aGVtIG1vcmUgc2VjdXJl PyBTdXJlLiBJdCBob3dldmVyIGlzIGEgcHJvYmxlbSBvZiBkaWZmZXJlbnQgc2NvcGUgYW5kIG5l ZWQgdG8gYmUgc29sdmVkIGluIE1NVVNJQyBvciBlbHNld2hlcmUsIElNSE8uDQoNCmRyYWZ0LWll dGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MgaXMgYWJvdXQgbWFraW5nIHRoZSBXZWJS VEMgYnJvd3NlciBtb3JlIHNlY3VyZS4gSXQgaG93ZXZlciBhbGxvd3MgYW4gUlRQIGVuZHBvaW50 ICh0aGF0IGFsc28gZG9lcyBJQ0UpIHRvIHVzZSB0aGUgbWVjaGFuaXNtIHRvIG1ha2UgaXQgbW9y ZSBzZWN1cmUgb3IgY29tcHV0ZSBSVFQgb3IgY2FycnkgbmV0d29yayBpbmZvcm1hdGlvbiBvciB3 aGF0ZXZlci4gSG93ZXZlciwgcmVxdWlyaW5nIGV2ZXJ5IFJUUCBlbmRwb2ludCBwZXJmb3JtIGl0 IHNlZW1zIGFza2luZyB0b28gbXVjaC4NCg0KTXkgdGFrZToNCldlYlJUQyBicm93c2VyIC0gTVVT VA0KV2ViUlRDIGRldmlkZSAtIFNIT1VMRA0KT3RoZXIgUlRQIGVudGl0aWVzIChpbmNsdWRpbmcg V2ViUlRDIGdhdGV3YXkpIC0gTUFZDQoNClRob3VnaHRzPw0KDQpNdXRodQ0KDQpPbiBGcmksIEF1 ZyAyMiwgMjAxNCBhdCAxOjA2IEFNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21h aWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCk9uIDIxIEF1 Z3VzdCAyMDE0IDExOjI1LCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCj4gQWxsIGVudGl0aWVzIHJlY2VpdmUgcGVlciB0 cmFuc3BvcnQgaW5mb3JtYXRpb24gZnJvbSBlbHNld2hlcmUsIGluY2x1ZGluZw0KPiBnYXRld2F5 cyBydW5uaW5nIElDRS1MaXRlLiBEb2VzIGl0IG1lYW4gYWxsIG9mIHRoZW0gbmVlZCB0byBwZXJm b3JtIGNvbnNlbnQ/DQpUaGF0J3MgdGhlIGxvZ2ljYWwgY29uY2x1c2lvbiwgeWVzLg0KDQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E526CA4US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7V2ViUlRD IGJyb3dzZXIgLSBNVVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZndDtXZWJSVEMgZGV2aWRlIC0gU0hPVUxEPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDtPdGhlciBSVFAgZW50aXRp ZXMgKGluY2x1ZGluZyBXZWJSVEMgZ2F0ZXdheSkgLSBNQVk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiYjNDM7MTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TXV0aHUgQXJ1bCBN b3poaSBQZXJ1bWFsPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDIyLCAyMDE0IDEy OjI2IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbjxicj4NCjxiPkNjOjwvYj4gcnRj d2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXRyBMYXN0IENh bGwgZm9yIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JQ0UtbGl0ZSBlbnRpdGllcyBkb24ndCBldmVuIHBlcmZvcm0gY29ubmVjdGl2aXR5IGNo ZWNrcy4gUmVxdWlyaW5nIHRoZXkgcGVyZm9ybSBjb25zZW50IGZyZXNobmVzcyBkb2Vzbid0IHNl ZW0gdG8gbWFrZSBzZW5zZSB0byBtZSAob2YgY291cnNlLCB3ZSBjYW4gY29tZSB1cCB3aXRoIGEg bmV3IHNwZWMgSUNFLWxpdGUtd2l0aC1jb25zZW50LA0KIGJ1dCB0aGF0J3MgYSBkaWZmZXJlbnQg cHJvYmxlbSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGFtIG5vdCBzYXlpbmcg eW91IGNhbid0IHNwb29mIGEgcHVibGljIFZvSVAgc2VydmljZSB0byBzZW5kIFJUUCBhbnl3aGVy ZS4gTGVnYWN5IElDRSBlbnRpdGllcyBwZXJmb3JtIGNvbm5lY3Rpdml0eSBjaGVja3MgdG9kYXkg YW5kIG5vdCBjb25zZW50IGFuZCBjb25zZW50IGZyZXNobmVzcy4gRG8gd2Ugd2FudCB0byBtYWtl IHRoZW0NCiBtb3JlIHNlY3VyZT8gU3VyZS4gSXQgaG93ZXZlciBpcyBhIHByb2JsZW0gb2YgZGlm ZmVyZW50IHNjb3BlIGFuZCBuZWVkIHRvIGJlIHNvbHZlZCBpbiBNTVVTSUMgb3IgZWxzZXdoZXJl LCBJTUhPLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtaWV0Zi1ydGN3ZWIt c3R1bi1jb25zZW50LWZyZXNobmVzcyBpcyBhYm91dCBtYWtpbmcgdGhlIFdlYlJUQyBicm93c2Vy IG1vcmUgc2VjdXJlLiBJdCBob3dldmVyIGFsbG93cyBhbiBSVFAgZW5kcG9pbnQgKHRoYXQgYWxz byBkb2VzIElDRSkgdG8gdXNlIHRoZSBtZWNoYW5pc20gdG8gbWFrZSBpdCBtb3JlIHNlY3VyZSBv cg0KIGNvbXB1dGUgUlRUIG9yIGNhcnJ5IG5ldHdvcmsgaW5mb3JtYXRpb24gb3Igd2hhdGV2ZXIu IEhvd2V2ZXIsIHJlcXVpcmluZyBldmVyeSBSVFAgZW5kcG9pbnQgcGVyZm9ybSBpdCBzZWVtcyBh c2tpbmcgdG9vIG11Y2guPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TXkgdGFrZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2ViUlRD IGJyb3dzZXIgLSBNVVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlYlJUQyBkZXZpZGUgLSBTSE9VTEQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+T3RoZXIgUlRQIGVudGl0aWVzIChpbmNsdWRpbmcgV2ViUlRDIGdhdGV3YXkpIC0gTUFZ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VGhvdWdodHM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TXV0aHU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEF1ZyAyMiwg MjAxNCBhdCAxOjA2IEFNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRp bi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gMjEgQXVndXN0IDIwMTQgMTE6 MjUsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+ cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEFsbCBlbnRpdGllcyBy ZWNlaXZlIHBlZXIgdHJhbnNwb3J0IGluZm9ybWF0aW9uIGZyb20gZWxzZXdoZXJlLCBpbmNsdWRp bmc8YnI+DQomZ3Q7IGdhdGV3YXlzIHJ1bm5pbmcgSUNFLUxpdGUuIERvZXMgaXQgbWVhbiBhbGwg b2YgdGhlbSBuZWVkIHRvIHBlcmZvcm0gY29uc2VudD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCdzIHRoZSBsb2dpY2FsIGNvbmNsdXNpb24sIHllcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E526CA4US70UWXCHMBA02z_-- From nobody Fri Aug 22 09:39:31 2014 Return-Path: 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 CF6F31A0413 for ; Fri, 22 Aug 2014 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 BP11IPqC_Kct for ; Fri, 22 Aug 2014 09:39:27 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9724D1A03F6 for ; Fri, 22 Aug 2014 09:39:27 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so10470625wiv.5 for ; Fri, 22 Aug 2014 09:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UhTkfqAsCFr+Ju6DyaNCXlGplsINGQq5A4O4oViUhgA=; b=f4xBdLm9LmRNwO8Ti0qCaWw50V1mH+jg6BUvWWo9Vr5H995tg/ReUr3RLx1dk4qIkX E0mDTuQo74kBFPui+Y3kM+txi5YU9sEwfYgBu8uiBzkcwreDW04a0PUpLYsuGQeRZsvW EEuyjgXQCA2rYkx/GPrLPqSeSpGzcWsQH8sUBWF5Tw4xALegc4UHke5OZORIOgqGk5By q5cNVC1yvdJbWpBGJ1IIb5MpukIwddEyabjogDvHONE5E7Q09RLfJ4w1IeTbPqOLw510 BX6pknxj7mnWTeYFXYbORpSVCK3VSvWBrzvW4ZuunWe0vKAGQjMBwtDzHSmQCoW6Et+8 CbrA== X-Gm-Message-State: ALoCoQnzPrnNG7NPFhgP0YkvbQQuVOS6uhlwRc6R4q75Dtz9gGc/6zlWVedZItLRugUUwwdF/aoZ X-Received: by 10.181.13.175 with SMTP id ez15mr18185409wid.59.1408725566242; Fri, 22 Aug 2014 09:39:26 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx.google.com with ESMTPSA id mw4sm32834220wic.20.2014.08.22.09.39.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Aug 2014 09:39:25 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so10863974wev.41 for ; Fri, 22 Aug 2014 09:39:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.38.84 with SMTP id e20mr11524162wik.43.1408725565099; Fri, 22 Aug 2014 09:39:25 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Fri, 22 Aug 2014 09:39:25 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Fri, 22 Aug 2014 12:39:25 -0400 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=e89a8f643366e4d87405013a7a59 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RiPt112laiF58uFMFt3dJyuwq5g Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:39:30 -0000 --e89a8f643366e4d87405013a7a59 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 22, 2014 at 12:21 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > >WebRTC browser - MUST > > >WebRTC devide - SHOULD > > >Other RTP entities (including WebRTC gateway) - MAY > > What I still do not understand, is why a full ICE end point would not send consent messages? What is the reason for this? The security and operational benefits of this are clear and the incremental work in implementing consent is minimal. Also, in what circumstances would ICE-lite end point ever send consent? Where is this even defined? Also, if you are implementing sending STUN messages, why would you not implement the full ICE end point? Once implementation of sending and processing responses to STUN consent messages is done, incremental work to implement full ICE is minimal. And finally, what does any of this have to do with type of WebRTC end point? Browsers and devices must implement full ICE and thus must implement consent. Other RTP endpoints, may implement ICE-lite and skip consent, but ideally should implement full ICE and consent. I also believe all of this is already in the specification. _____________ Roman Shpount --e89a8f643366e4d87405013a7a59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 22, 2014 at 12:21 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

>Web= RTC browser - MUST

>Web= RTC devide - SHOULD

>Oth= er RTP entities (including WebRTC gateway) - MAY


What I still do not understand, is why a full ICE end point would not se= nd consent messages? What is the reason for this? The security and operatio= nal benefits of this are clear and the incremental work in implementing con= sent is minimal.

Also, in what circumstances would ICE-lite end point ev= er send consent? Where is this even defined? Also, if you are implementing = sending STUN messages, why would you not implement the full ICE end point? = Once implementation of sending and processing responses to STUN consent mes= sages is done, incremental work to implement full ICE is minimal.

And finally, what does any of this have to do with type= of WebRTC end point? Browsers and devices must implement full ICE and thus= must implement consent. Other RTP endpoints, may implement ICE-lite and sk= ip consent, but ideally should implement full ICE and consent. I also belie= ve all of this is already in the specification.
_____________
Roman Shpount
--e89a8f643366e4d87405013a7a59-- From nobody Fri Aug 22 10:13:57 2014 Return-Path: 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 C9E621A0681 for ; Fri, 22 Aug 2014 10:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 OLqD_YdlTJ5p for ; Fri, 22 Aug 2014 10:13:53 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3601A06A1 for ; Fri, 22 Aug 2014 10:13:30 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so10215889wib.11 for ; Fri, 22 Aug 2014 10:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6FsYv7lYPnxbE/MF/lmv2YLXMvCxrWcb8LMecRj6wvU=; b=hcIQmjtx55hkKd1lqmFZ26CyQHSR8CRxvMuEBVgUlCG4UdFkg+JRC8Mb/NMuVe4MHI 3ePC+gTIZZekLzTYNhGDN8GfdORu0vFviTTX65Q1kcQ4PJ4AOdky6x0xf8FTEWtpsZax X77aG2sSysp7urBu5QxziofXi9zhnq8mdtB+0hzuoJH1SVlmIvenplCxKKSZ8qqfIWPj pgvdUVem/Lwd7RRmLaxyMo630PSlzbJ2W1LOmLuBoBDyGuZ1QwkW+wSbRI6p3yIK477x qRnZ5jLKuUnrMf+qUw0kFd7jZgU05W2S7vgAg/0gYlY210/zVts3Uy1GUW5GE9HMh/A3 9jbg== MIME-Version: 1.0 X-Received: by 10.180.104.42 with SMTP id gb10mr29941278wib.65.1408727608907; Fri, 22 Aug 2014 10:13:28 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Fri, 22 Aug 2014 10:13:28 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Fri, 22 Aug 2014 10:13:28 -0700 Message-ID: From: Martin Thomson To: Muthu Arul Mozhi Perumal Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/duU18Sp7JP9iH-glENZ-wcEb_lQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:13:55 -0000 On 21 August 2014 22:25, Muthu Arul Mozhi Perumal wrote: > ICE-lite entities don't even perform connectivity checks. Requiring they > perform consent freshness doesn't seem to make sense to me (of course, we > can come up with a new spec ICE-lite-with-consent, but that's a different > problem). I never suggested that. What I suggested was that they SHOULD be performing consent checks. The fact that they don't is what I would term a "legacy requirement". I don't think that we should be extending this exception to any other entities. The only reason that ICE-lite gets away with not sending checks is that it trusts both the signaling entities and its peers. That's dangerous. We interoperate with ICE-lite only because doing otherwise would exclude more entities than we are willing to exclude. The current text is fine. It opens a minimal hole that acknowledges the existence of the bad actors, but doesn't attempt to bestow any kind of validity or legitimacy on them. From nobody Fri Aug 22 10:40:31 2014 Return-Path: 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 D5B041A069E for ; Fri, 22 Aug 2014 10:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 mFCYMuxLXgKo for ; Fri, 22 Aug 2014 10:40:26 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333311A070F for ; Fri, 22 Aug 2014 10:40:22 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id DE4483B750BA8; Fri, 22 Aug 2014 17:40:17 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s7MHeK6j032658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 13:40:21 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 22 Aug 2014 13:40:21 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Roman Shpount Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPviel03i4NcJqKUmy26SDMafHaZvc1WPA Date: Fri, 22 Aug 2014 17:40:20 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E527121US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/68VP7Xjz4PhOh5SLJSXqobVkSpc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 17:40:29 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E527121US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6 IEZyaWRheSwgQXVndXN0IDIyLCAyMDE0IDExOjM5IEFNDQoNCk9uIEZyaSwgQXVnIDIyLCAyMDE0 IGF0IDEyOjIxIFBNLCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIDxSYWp1Lk1ha2FyYWp1 QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5j b20+PiB3cm90ZToNCj5XZWJSVEMgYnJvd3NlciAtIE1VU1QNCj5XZWJSVEMgZGV2aWRlIC0gU0hP VUxEDQo+T3RoZXIgUlRQIGVudGl0aWVzIChpbmNsdWRpbmcgV2ViUlRDIGdhdGV3YXkpIC0gTUFZ DQoNCldoYXQgSSBzdGlsbCBkbyBub3QgdW5kZXJzdGFuZCwgaXMgd2h5IGEgZnVsbCBJQ0UgZW5k IHBvaW50IHdvdWxkIG5vdCBzZW5kIGNvbnNlbnQgbWVzc2FnZXM/IFdoYXQgaXMgdGhlIHJlYXNv biBmb3IgdGhpcz8gVGhlIHNlY3VyaXR5IGFuZCBvcGVyYXRpb25hbCBiZW5lZml0cyBvZiB0aGlz IGFyZSBjbGVhciBhbmQgdGhlIGluY3JlbWVudGFsIHdvcmsgaW4gaW1wbGVtZW50aW5nIGNvbnNl bnQgaXMgbWluaW1hbC4NCjxSYWp1Pg0KQSBXZWJSVEMtZGV2aWNlIGNvdWxkIGJlIGEgbmF0aXZl IGFwcCBvciBpbiBhbiBlbWJlZGRlZCBkZXZpY2Ugd2hlcmUgdGhlcmUgY291bGQgYmUgc29tZSBs aW1pdGF0aW9ucyBhYm91dCBtZW1vcnksIGNwdSwgZW5lcmd5IGFuZC9vciBiYW5kd2lkdGguIFNv LCBzdWNoIGEgZGV2aWNlIGNvdWxkIGNob29zZSBub3QgdG8gZG8gY29uc2VudCBmcmVzaG5lc3Mg Y2hlY2tzIGJlZm9yZSBzZW5kaW5nIGRhdGEuIEltYWdpbmUgYW4gZW1iZWRkZWQgZGV2aWNlIChJ bnRlcm5ldC1vZi10aGluZ3MpIHNlbmRzIHNvbWUgbm9uIHJlYWwtdGltZSBkYXRhICh1c2luZyB3 ZWJydGMgZGF0YSBjaGFubmVsKSBldmVyeSAzMCBzZWNzOyB3aXRoIGNvbnNlbnQgY2hlY2sgaXQg Zmlyc3QgaGFzIHRvIHNlbmQgYSBTVFVOIHJlcSBmb3IgY29uc2VudCBhbmQgd2FpdCBmb3IgcmVz cG9uc2UgdGhlbiBzZW5kIHRoZSBkYXRhLiBJbiB0aGlzIGNhc2UgdGhlIGNvbnNlbnQgY2hlY2tz IGFkZCBkZWxheSBhbmQgb3ZlcmhlYWQuIElNSE8sIGZvciBXZWJSVEMtZGV2aWNlIGFsbG93aW5n IHRoZSBmbGV4aWJpbGl0eSBvZiBubyBjb25zZW50IGlzIGEgZ29vZCBpZGVhOyBzbyBhIOKAnFNI T1VMROKAnSBpcyBqdXN0aWZpZWQuIEJ1dCwgSSBhbSBvayB0byBtYWtlIGNvbnNlbnQgZm9yIFdl YlJUQy1kZXZpY2UgYSBNVVNUIHRvby4NCjwvUmFqdT4NCg0KQWxzbywgaW4gd2hhdCBjaXJjdW1z dGFuY2VzIHdvdWxkIElDRS1saXRlIGVuZCBwb2ludCBldmVyIHNlbmQgY29uc2VudD8gV2hlcmUg aXMgdGhpcyBldmVuIGRlZmluZWQ/IEFsc28sIGlmIHlvdSBhcmUgaW1wbGVtZW50aW5nIHNlbmRp bmcgU1RVTiBtZXNzYWdlcywgd2h5IHdvdWxkIHlvdSBub3QgaW1wbGVtZW50IHRoZSBmdWxsIElD RSBlbmQgcG9pbnQ/IE9uY2UgaW1wbGVtZW50YXRpb24gb2Ygc2VuZGluZyBhbmQgcHJvY2Vzc2lu ZyByZXNwb25zZXMgdG8gU1RVTiBjb25zZW50IG1lc3NhZ2VzIGlzIGRvbmUsIGluY3JlbWVudGFs IHdvcmsgdG8gaW1wbGVtZW50IGZ1bGwgSUNFIGlzIG1pbmltYWwuDQo8UmFqdT4NCk15IHVuZGVy c3RhbmRpbmcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0wNi50 eHQgaXM6IGNvbnNlbnQgaXMgdW5pZGlyZWN0aW9uYWwuIFNvLCBpZiBpY2UtbGl0ZSBlbmRwb2lu dCB3YW50cyB0byBzZW5kIGRhdGEgaXQgbmVlZHMgdG8gZ2V0IGNvbnNlbnQgaWYgaXQgZG9lcyBu b3QgdHJ1c3QgdGhlIHBlZXIuIEEgdHlwaWNhbCBpY2UtbGl0ZSBlbmRwb2ludCBoYXMgYSBwdWJs aWMgSVAsIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gcGVlciBnaXZlcyBhdXRvbWF0aWMgY29uc2Vu dCBmb3IgaXQgdG8gc2VuZCBkYXRhIG9yIHRoZXJlIGFyZSBubyBzZWN1cml0eSBpc3N1ZXMuDQpU aGUgcmVhc29uIHdoeSBJIGFtIG9rIGhlcmUgZm9yIOKAnE1BWeKAnSBpbnN0ZWFkIG9mIOKAnE1V U1QvU0hPVUxE4oCdIGlzIHRvIGFsbG93IHRoZSBwb3NzaWJpbGl0eSBmb3IgdGhlIFdlYlJUQy1n YXRld2F5IHRvIGJlIGluIGEgY29tcGxldGVseSB0cnVzdGVkIG5ldHdvcmsgKGVudGVycHJpc2Ug bmV0d29yaz8pIG9yIHNvbWUgb3RoZXIgbWVjaGFuaXNtcyAobGlrZSBMVEUgRVBDIG5ldHdvcmsp IGFyZSB0aGVyZSB0byBtYWtlIHRoZSBuZXR3b3JrIHNhZmUgYW5kIHNlY3VyZSAoZXZlbiBpZiB0 aGUgY2xpZW50IGlzIG5vdCkuDQo8L1JhanU+DQoNCkJSDQpSYWp1DQpBbmQgZmluYWxseSwgd2hh dCBkb2VzIGFueSBvZiB0aGlzIGhhdmUgdG8gZG8gd2l0aCB0eXBlIG9mIFdlYlJUQyBlbmQgcG9p bnQ/IEJyb3dzZXJzIGFuZCBkZXZpY2VzIG11c3QgaW1wbGVtZW50IGZ1bGwgSUNFIGFuZCB0aHVz IG11c3QgaW1wbGVtZW50IGNvbnNlbnQuIE90aGVyIFJUUCBlbmRwb2ludHMsIG1heSBpbXBsZW1l bnQgSUNFLWxpdGUgYW5kIHNraXAgY29uc2VudCwgYnV0IGlkZWFsbHkgc2hvdWxkIGltcGxlbWVu dCBmdWxsIElDRSBhbmQgY29uc2VudC4gSSBhbHNvIGJlbGlldmUgYWxsIG9mIHRoaXMgaXMgYWxy ZWFkeSBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQN Cg== --_000_E1FE4C082A89A246A11D7F32A95A17828E527121US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb21hbiBTaHBvdW50IFtt YWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1 c3QgMjIsIDIwMTQgMTE6MzkgQU08YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEF1ZyAyMiwg MjAxNCBhdCAxMjoyMSBQTSwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZndDtXZWJSVEMgYnJvd3NlciAtIE1VU1Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7V2ViUlRDIGRldmlkZSAtIFNIT1VM RDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZndDtPdGhlciBSVFAgZW50aXRpZXMgKGluY2x1ZGluZyBXZWJSVEMgZ2F0ZXdheSkgLSBNQVk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEkgc3RpbGwgZG8gbm90IHVuZGVyc3RhbmQsIGlzIHdo eSBhIGZ1bGwgSUNFIGVuZCBwb2ludCB3b3VsZCBub3Qgc2VuZCBjb25zZW50IG1lc3NhZ2VzPyBX aGF0IGlzIHRoZSByZWFzb24gZm9yIHRoaXM/IFRoZSBzZWN1cml0eSBhbmQgb3BlcmF0aW9uYWwg YmVuZWZpdHMgb2YgdGhpcyBhcmUgY2xlYXIgYW5kIHRoZSBpbmNyZW1lbnRhbCB3b3JrIGluIGlt cGxlbWVudGluZyBjb25zZW50IGlzIG1pbmltYWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jmx0O1JhanUmZ3Q7PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QSBXZWJSVEMtZGV2aWNlIGNvdWxkIGJlIGEgbmF0aXZlIGFwcCBvciBpbiBhbiBlbWJlZGRl ZCBkZXZpY2Ugd2hlcmUgdGhlcmUgY291bGQgYmUgc29tZSBsaW1pdGF0aW9ucyBhYm91dCBtZW1v cnksIGNwdSwgZW5lcmd5IGFuZC9vciBiYW5kd2lkdGguIFNvLCBzdWNoDQogYSBkZXZpY2UgY291 bGQgY2hvb3NlIG5vdCB0byBkbyBjb25zZW50IGZyZXNobmVzcyBjaGVja3MgYmVmb3JlIHNlbmRp bmcgZGF0YS4gSW1hZ2luZSBhbiBlbWJlZGRlZCBkZXZpY2UgKEludGVybmV0LW9mLXRoaW5ncykg c2VuZHMgc29tZSBub24gcmVhbC10aW1lIGRhdGEgKHVzaW5nIHdlYnJ0YyBkYXRhIGNoYW5uZWwp IGV2ZXJ5IDMwIHNlY3M7IHdpdGggY29uc2VudCBjaGVjayBpdCBmaXJzdCBoYXMgdG8gc2VuZCBh IFNUVU4gcmVxIGZvciBjb25zZW50DQogYW5kIHdhaXQgZm9yIHJlc3BvbnNlIHRoZW4gc2VuZCB0 aGUgZGF0YS4gSW4gdGhpcyBjYXNlIHRoZSBjb25zZW50IGNoZWNrcyBhZGQgZGVsYXkgYW5kIG92 ZXJoZWFkLiBJTUhPLCBmb3IgV2ViUlRDLWRldmljZSBhbGxvd2luZyB0aGUgZmxleGliaWxpdHkg b2Ygbm8gY29uc2VudCBpcyBhIGdvb2QgaWRlYTsgc28gYSDigJxTSE9VTETigJ0gaXMganVzdGlm aWVkLiBCdXQsIEkgYW0gb2sgdG8gbWFrZSBjb25zZW50IGZvciBXZWJSVEMtZGV2aWNlIGEgTVVT VA0KIHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7 L1JhanUmZ3Q7PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWxzbywgaW4gd2hhdCBjaXJjdW1zdGFuY2VzIHdvdWxkIElDRS1saXRl IGVuZCBwb2ludCBldmVyIHNlbmQgY29uc2VudD8gV2hlcmUgaXMgdGhpcyBldmVuIGRlZmluZWQ/ IEFsc28sIGlmIHlvdSBhcmUgaW1wbGVtZW50aW5nIHNlbmRpbmcgU1RVTiBtZXNzYWdlcywgd2h5 IHdvdWxkIHlvdSBub3QgaW1wbGVtZW50IHRoZSBmdWxsIElDRSBlbmQgcG9pbnQ/IE9uY2UgaW1w bGVtZW50YXRpb24gb2Ygc2VuZGluZw0KIGFuZCBwcm9jZXNzaW5nIHJlc3BvbnNlcyB0byBTVFVO IGNvbnNlbnQgbWVzc2FnZXMgaXMgZG9uZSwgaW5jcmVtZW50YWwgd29yayB0byBpbXBsZW1lbnQg ZnVsbCBJQ0UgaXMgbWluaW1hbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7UmFq dSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NeSB1bmRl cnN0YW5kaW5nIG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMDYu dHh0IGlzOiBjb25zZW50IGlzIHVuaWRpcmVjdGlvbmFsLiBTbywgaWYgaWNlLWxpdGUgZW5kcG9p bnQgd2FudHMgdG8gc2VuZCBkYXRhIGl0IG5lZWRzDQogdG8gZ2V0IGNvbnNlbnQgaWYgaXQgZG9l cyBub3QgdHJ1c3QgdGhlIHBlZXIuIEEgdHlwaWNhbCBpY2UtbGl0ZSBlbmRwb2ludCBoYXMgYSBw dWJsaWMgSVAsIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gcGVlciBnaXZlcyBhdXRvbWF0aWMgY29u c2VudCBmb3IgaXQgdG8gc2VuZCBkYXRhIG9yIHRoZXJlIGFyZSBubyBzZWN1cml0eSBpc3N1ZXMu PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHJlYXNvbiB3 aHkgSSBhbSBvayBoZXJlIGZvciDigJxNQVnigJ0gaW5zdGVhZCBvZiDigJxNVVNUL1NIT1VMROKA nSBpcyB0byBhbGxvdyB0aGUgcG9zc2liaWxpdHkgZm9yIHRoZSBXZWJSVEMtZ2F0ZXdheSB0byBi ZSBpbiBhIGNvbXBsZXRlbHkgdHJ1c3RlZCBuZXR3b3JrDQogKGVudGVycHJpc2UgbmV0d29yaz8p IG9yIHNvbWUgb3RoZXIgbWVjaGFuaXNtcyAobGlrZSBMVEUgRVBDIG5ldHdvcmspIGFyZSB0aGVy ZSB0byBtYWtlIHRoZSBuZXR3b3JrIHNhZmUgYW5kIHNlY3VyZSAoZXZlbiBpZiB0aGUgY2xpZW50 IGlzIG5vdCkuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0 Oy9SYWp1Jmd0Ozwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+UmFqdTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgZmluYWxseSwgd2hhdCBkb2VzIGFueSBvZiB0 aGlzIGhhdmUgdG8gZG8gd2l0aCB0eXBlIG9mIFdlYlJUQyBlbmQgcG9pbnQ/IEJyb3dzZXJzIGFu ZCBkZXZpY2VzIG11c3QgaW1wbGVtZW50IGZ1bGwgSUNFIGFuZCB0aHVzIG11c3QgaW1wbGVtZW50 IGNvbnNlbnQuIE90aGVyIFJUUCBlbmRwb2ludHMsIG1heSBpbXBsZW1lbnQgSUNFLWxpdGUgYW5k IHNraXAgY29uc2VudCwgYnV0IGlkZWFsbHkgc2hvdWxkDQogaW1wbGVtZW50IGZ1bGwgSUNFIGFu ZCBjb25zZW50LiBJIGFsc28gYmVsaWV2ZSBhbGwgb2YgdGhpcyBpcyBhbHJlYWR5IGluIHRoZSBz cGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E527121US70UWXCHMBA02z_-- From nobody Fri Aug 22 13:34:01 2014 Return-Path: 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 0B3231A0745 for ; Fri, 22 Aug 2014 13:33:56 -0700 (PDT) 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 aM3Gw80UUFWY for ; Fri, 22 Aug 2014 13:33:51 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE621A6F54 for ; Fri, 22 Aug 2014 13:33:48 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by QMTA11.westchester.pa.mail.comcast.net with comcast id hqj01o00627AodY5BwZnmj; Fri, 22 Aug 2014 20:33:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta19.westchester.pa.mail.comcast.net with comcast id hwZn1o0083Ge9ey3fwZn8K; Fri, 22 Aug 2014 20:33:47 +0000 Message-ID: <53F7A92B.6000004@alum.mit.edu> Date: Fri, 22 Aug 2014 16:33:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Colin Perkins References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F47A9C.2000606@alvestrand.no> <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> <53F4AF99.2090606@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1408739627; bh=p6La0G7ansiPF8LrgoSoHT7CROgriASfpbvcCQnCA8g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fAgjMYadxAZWiFhl55rB9ucg+Hd2ifc+assMktN/VCkz50YNNue6F4w7bOfdXcQ4t 1vQNhXCG+ft64jUQ8/V0/C4Ymb9bAfG23Yuf2Fj0he2+GCUZLXeAwi1edY47ZgYQp4 tIIajQqD+1RS+o9sIOk/2MCV9uAM8pGvH6NN9PuoN1pJ1P5CC3wj3FtHim6EJmdrG5 RXrZMWUphI8bvdveScUjAZf05AVsSRG4XxvFyx+QAZjctZTlwuSNxwEe8Ey4ooxrg9 0rRzxALeZJ4r/J1/kPvXe2wCdTQCI2993K2lFf3pTgXtTZffowlvxjSzY1jzTyP/R1 0dyhr8U0fC2TA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eDnkxIY9CiVS9ce1U-Ty2_UV73Y Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 20:33:56 -0000 On 8/21/14 7:42 AM, Colin Perkins wrote: > On 20 Aug 2014, at 15:24, Paul Kyzivat wrote: >> On 8/20/14 6:47 AM, Colin Perkins wrote: >>> On 20 Aug 2014, at 11:38, Harald Alvestrand wrote: >>>> On 08/20/2014 11:46 AM, Colin Perkins wrote: >>>>> On 19 Aug 2014, at 15:00, Harald Alvestrand wrote: >>>>>> On 08/19/2014 03:38 PM, Jim Barnett wrote: >>>>>>> I agree. We need to define a) WebRTC browsers, which support the full protocol requirements and the API, b) WebRTC Endpoints/Devices, which support some minimum protocol set sufficient for establishing connectivity. Is there also a need to define c) Full WebRTC Devices, which support more than the minimum protocol set? What would be the use of definition c? >>>>>> An endpoint (I kind of start to like this concept/name) would be conformant as long as it was able to successfully negotiate away use of anything that makes life difficult. >>>>>> >>>>>> It would be required to support DTLS-SRTP key handshakes and respond to ICE connectivity checks, plus whatever is MUST use in -rtp-usage (scanning, I'm not coming up with much - it's mostly MUST respond to, MUST implement (but not required to use) stuff). The RTP circuit breaker is also a MUST implement, and since it's a single-ended thing, it makes no sense if it isn't also MUST use. >>>>>> >>>>>> Scanning, I’m not even sure a WebRTC endpoint is required to send RTCP - but I think it should be. >>>>> “RTCP is a fundamental and integral part of RTP, and MUST be implemented in all WebRTC applications.” rtp-usage-16 section 4.1 >>>> >>>> Yep, I thought we wanted that too, but then I started to scan for mandatory-to-implement vs mandatory-to-use, and started being unsure; is it permitted to configure a WebRTC device to set RTCP-bandwidth to zero (the traditional means of turning off RTCP in a standards conformant manner, I think)? >>>> >>>> Perhaps we should add a requirement on minimum RTCP bandwidth? >>> >>> I wouldn’t know what minimum RTCP bandwidth to specify, but could certainly change the rtp-usage draft to say “…MUST be implemented and used…” if that would help? >> >> That is fine *if RTP is being used*. > > I am suggesting adding this to the RTP usage draft… > >> Use, or even implementation, of RTP should not be required in WebRTC devices that don’t need it. > > Perhaps, but if implementing RTP isn’t a requirement, that needs to be captured somewhere. The rtcweb-overview-11 draft currently mandates RTP be implemented. It is appropriate for the overview to mandate RTP support *for browsers*. But the current discussion is about how to frame requirements for compliant non-browser devices. If there was an intent to define some non-browser *platform* for webrtc applications then it would probably be appropriate to mandate RTP support for them too. (AFAIK there is no plan to define such a platform.) But other devices that only need data channels shouldn't be required to implement RTP. Thanks, Paul From nobody Fri Aug 22 14:24:31 2014 Return-Path: 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 7848A1A0977 for ; Fri, 22 Aug 2014 14:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_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 LUuwlk0viHe0 for ; Fri, 22 Aug 2014 14:24:27 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.29]) by ietfa.amsl.com (Postfix) with ESMTP id CA54E1A06E1 for ; Fri, 22 Aug 2014 14:24:26 -0700 (PDT) Received: from userPC (unknown [122.178.206.71]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 0CC593C0014; Fri, 22 Aug 2014 21:24:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1408742662; bh=lT8SmOsIQ0UOkEYJKj3t4cWKZSW107Aq5Us0a8OpYIw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=kjGYic0+qV9/htRJAHi4XfZfSTSxz1KiofTwj3/1YIGe9iMNX9j9P71EzDHDet3K8 Lrv00Dob/hH9dMaReokBxkyPuSdHkWmOagE1GkSemrvM/KaYZRTG8sV+WqbfiypnJ8 gInA/l1IGZtEHJYptRi5w8rPdURZ8N05rnYka2kE= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , "'Muthu Arul Mozhi Perumal'" References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> In-Reply-To: Date: Sat, 23 Aug 2014 02:54:03 +0530 Message-ID: <009001cfbe4f$6b92f280$42b8d780$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01CFBE7D.854B2E80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPviSytsP8Fi+4skKmwMIEhdYf8JvdHVSA Content-Language: en-us X-CTCH-RefID: str=0001.0A020209.53F7B506.0095, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/MhVIQLA4ips2whFwoemdUo6iDGM Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:24:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0091_01CFBE7D.854B2E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ram/Muthu, There is a terminology variation here. As per the current overview document, WebRTC device supports full WebRTC protocol requirement which includes consent-check. In case consent check is excluded from WebRTC device, the new definition has to be provided for "WebRTC device" in -overview draft. I don't think that WebRTC device definition has to be changed now. IMO, WebRTC device & WebRTC browser MUST support consent check. As discussed in another mail thread, there is an need to define "WebRTC endpoint" which relaxes the lot of WebRTC protocol requirement based on the specific deployment like Enterprise, LTE EPC. "WebRTC Endpoint" & "WebRTC Gateway" MAY support consent check. I have highlighted Full ICE as a criteria for "WebRTC Endpoint" & "WebRTC Gateway" in http://www.ietf.org/mail-archive/web/rtcweb/current/msg12938.html as it helps the implementers to decide whether consent check has to be implemented in their "WebRTC Endpoint"/ "WebRTC Gateway" or not. As "WebRTC Endpoint" is yet to defined and "WebRTC gateway" is just now proposed in -11 overview draft, I have proposed the text as "Full ICE supporting WebRTC entities MUST support consent freshness." Please let me your opinion on the same. Also, I agree with Muthu's statement to indicates the other requirement for WebRTC entities to include consent check are: "to use the mechanism to make it more secure or compute RTT or carry network information" Thanks Partha From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr) Sent: Friday, August 22, 2014 9:48 PM To: Christer Holmberg; Roman Shpount; Muthu Arul Mozhi Perumal Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Right. I think we had discussed this in the past and added the below text in the draft " WebRTC endpoints are required to support full ICE as specified in section 3.4 of [I-D.ietf-rtcweb-transports ]. However, when WebRTC endpoints interwork with other endpoints that support only ICE-lite (e.g. gateways) those endpoints will not generate consent checks, but just respond to consent checks they receive" Isn't this sufficient ? Ram From: Christer Holmberg Date: Friday, 22 August 2014 9:29 pm To: Roman Shpount , Muthu Arul Mozhi Perumal Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Hi, An ICE-lite endpoint must already today *REPLY* to STUN requests - consent freshness does not change that. But, I don't think an ICE-lite endpoint shall be mandated to *SEND* consent freshness requests. Regards, Christer _____ From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Roman Shpount [roman@telurix.com] Sent: Friday, 22 August 2014 4:37 PM To: Muthu Arul Mozhi Perumal Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal wrote: draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser more secure. It however allows an RTP endpoint (that also does ICE) to use the mechanism to make it more secure or compute RTT or carry network information or whatever. However, requiring every RTP endpoint perform it seems asking too much. My take: WebRTC browser - MUST WebRTC devide - SHOULD Other RTP entities (including WebRTC gateway) - MAY I would say that all full ICE endpoint interworking with WebRTC MUST implement consent freshness. ICE-LITE will not implement, but MUST respond (unless someone defines it, but once you start sending STUN request you might as well do full ICE, so I do not see much point in it). And to conclude strongly encourage full ICE implementation for security and other reasons. _____________ Roman Shpount ------=_NextPart_000_0091_01CFBE7D.854B2E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ram/Muthu,

 

There is a terminology variation here. As per the current overview document, WebRTC device supports full WebRTC protocol = requirement which includes consent-check. In case consent check is excluded from WebRTC = device,  the new definition has to be provided for “WebRTC device” in = –overview draft. I don’t think that WebRTC device definition has to be = changed now.

 

IMO, WebRTC device & WebRTC browser MUST support = consent check. As discussed in another mail thread, there is an need to define = “WebRTC endpoint” which relaxes the lot of WebRTC protocol requirement = based on the specific deployment like Enterprise, LTE EPC. “WebRTC = Endpoint” & “WebRTC Gateway” MAY support consent = check.

 

I have highlighted Full ICE as a criteria for = “WebRTC Endpoint” & “WebRTC Gateway” in http://www.ietf.org/mail-archive/web/rtcweb/current/msg12938.html as it helps the implementers to decide whether consent check has to be implemented in their “WebRTC Endpoint”/ “WebRTC = Gateway” or not. As “WebRTC Endpoint” is yet to defined and = “WebRTC gateway” is just now proposed in -11 overview draft,  I have = proposed the text as

 

“Full ICE supporting WebRTC entities  MUST = support consent freshness.”

 

Please let me your opinion on the same. =

 

Also, I agree with Muthu’s statement to indicates = the other requirement for WebRTC entities to include consent check = are:

“to use the mechanism to make it more secure or compute RTT = or carry network information” =

 

 

Thanks

Partha

 

 

 

From:= rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R = (rmohanr)
Sent: Friday, August 22, 2014 9:48 PM
To: Christer Holmberg; Roman Shpount; Muthu Arul Mozhi = Perumal
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

 

Right. I think we had discussed this in the past and added = the below text in the draft

 

" WebRTC endpoints are required to support full ICE as specified in

   section 3.4 of [I-D.ietf-rtcweb-transports].&nb=
sp; However, when WebRTC
   endpoints interwork =
with other endpoints that support only =
ICE-lite
   (e.g. gateways) =
those endpoints will not generate consent checks, =
but
   just respond to =
consent checks they receive”

Isn’t this sufficient ?

Ram

 

From: Christer Holmberg <christer.holmberg@ericsson= .com>
Date: Friday, 22 August 2014 9:29 pm
To: Roman Shpount <roman@telurix.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

 

= Hi,

=  

= An ICE-lite endpoint must already today *REPLY* to STUN requests - = consent freshness does not change that.

=  

= But, I don't think an ICE-lite endpoint shall be mandated to *SEND* consent freshness requests.

=  

= Regards,

=  

= Christer

=  

=  

From:= rtcweb [rtcweb-bounces@ietf.org] = on behalf of Roman Shpount [roman@telurix.com]
Sent: Friday, 22 August 2014 4:37 PM
To: Muthu Arul Mozhi Perumal
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] WG Last Call for = draft-ietf-rtcweb-stun-consent-freshness

On Fri, Aug 22, 2014 at = 1:25 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> = wrote:

draft-ietf-rtcweb-= stun-consent-freshness is about making the WebRTC browser more secure. It however allows an RTP endpoint (that also does ICE) to use the mechanism to make it more = secure or compute RTT or carry network information or whatever. However, requiring = every RTP endpoint perform it seems asking too much.

 

My take:

WebRTC browser - MUST

WebRTC devide - SHOULD

Other RTP entities (including WebRTC gateway) - MAY

 

 

 I would say that = all full ICE endpoint interworking with WebRTC MUST implement consent freshness. ICE-LITE will not implement, but MUST respond (unless someone defines = it, but once you start sending STUN request you might as well do full ICE, so I = do not see much point in it). And to conclude strongly encourage full ICE implementation for security and other reasons.

_____________
Roman Shpount

 

------=_NextPart_000_0091_01CFBE7D.854B2E80-- From nobody Fri Aug 22 14:32:08 2014 Return-Path: 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 5DB701A6F4B for ; Fri, 22 Aug 2014 14:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_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 FyvlPZiqOtnh for ; Fri, 22 Aug 2014 14:32:04 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.13]) by ietfa.amsl.com (Postfix) with ESMTP id 924BC1A6F6D for ; Fri, 22 Aug 2014 14:32:04 -0700 (PDT) Received: from userPC (unknown [122.178.206.71]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id F08EF1908B31; Fri, 22 Aug 2014 21:31:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1408743122; bh=P768lszVCaP6lKPqt2ESBYvYCqSle3LKD4wpTgWwPWM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=YeCm9XrogxrjKbUogXrwaytcOHT2Hn6fMchEc4r/q0/86P/MiwPvz1Xn7b7VtYb09 Sf+v3YSR3NSM314kvlYzUH7HuyVWAbLtEieGrKsHPecs0+aPcSfxo0oZRXfk4HO+M4 Xc3JvJ9jmy4kZxb2cwwwXBuukCqBEl6R6ZsOvTwM= From: "Parthasarathi R" To: "'Paul Kyzivat'" , "'Colin Perkins'" References: <53F1DF5E.6030309@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF17E57892@MCHP04MSX.global-ad.net> <53F3536C.5000302@gmail.com> <53F35883.20306@alvestrand.no> <53F47A9C.2000606@alvestrand.no> <6A59DFE5-34BA-4A07-BADF-D5A97354C543@csperkins.org> <53F4AF99.2090606@alum.mit.edu> <53F7A92B.6000004@alum.mit.edu> In-Reply-To: <53F7A92B.6000004@alum.mit.edu> Date: Sat, 23 Aug 2014 03:01:48 +0530 Message-ID: <009501cfbe50$7e33aa50$7a9afef0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac++SGzXO5TyBgSNSXi8jehJFmTOhAAB1nkw Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.53F7B6D2.00CC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xp58WET3RBi0o9a1GBOmPwIE0lk Cc: rtcweb@ietf.org Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a new term? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 21:32:06 -0000 Paul, I agree with you that WebRTC Endpoint MAY implement data channel only and not mandatory to implement RTP. But I wish to differentiate between WebRTC Endpoint & WebRTC device wherein WebRTC device MUST support RTP & data channel as it is full compliance to WebRTC protocol requirements. Please let me know your opinion on the same. Thanks Partha > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Saturday, August 23, 2014 2:04 AM > To: Colin Perkins > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] WebRTC Device: Lowering the bar, or inventing a > new term? > > On 8/21/14 7:42 AM, Colin Perkins wrote: > > On 20 Aug 2014, at 15:24, Paul Kyzivat wrote: > >> On 8/20/14 6:47 AM, Colin Perkins wrote: > >>> On 20 Aug 2014, at 11:38, Harald Alvestrand > wrote: > >>>> On 08/20/2014 11:46 AM, Colin Perkins wrote: > >>>>> On 19 Aug 2014, at 15:00, Harald Alvestrand > wrote: > >>>>>> On 08/19/2014 03:38 PM, Jim Barnett wrote: > >>>>>>> I agree. We need to define a) WebRTC browsers, which support > the full protocol requirements and the API, b) WebRTC > Endpoints/Devices, which support some minimum protocol set sufficient > for establishing connectivity. Is there also a need to define c) Full > WebRTC Devices, which support more than the minimum protocol set? What > would be the use of definition c? > >>>>>> An endpoint (I kind of start to like this concept/name) would be > conformant as long as it was able to successfully negotiate away use of > anything that makes life difficult. > >>>>>> > >>>>>> It would be required to support DTLS-SRTP key handshakes and > respond to ICE connectivity checks, plus whatever is MUST use in -rtp- > usage (scanning, I'm not coming up with much - it's mostly MUST respond > to, MUST implement (but not required to use) stuff). The RTP circuit > breaker is also a MUST implement, and since it's a single-ended thing, > it makes no sense if it isn't also MUST use. > >>>>>> > >>>>>> Scanning, I'm not even sure a WebRTC endpoint is required to > send RTCP - but I think it should be. > >>>>> "RTCP is a fundamental and integral part of RTP, and MUST be > implemented in all WebRTC applications." rtp-usage-16 section 4.1 > >>>> > >>>> Yep, I thought we wanted that too, but then I started to scan for > mandatory-to-implement vs mandatory-to-use, and started being unsure; > is it permitted to configure a WebRTC device to set RTCP-bandwidth to > zero (the traditional means of turning off RTCP in a standards > conformant manner, I think)? > >>>> > >>>> Perhaps we should add a requirement on minimum RTCP bandwidth? > >>> > >>> I wouldn't know what minimum RTCP bandwidth to specify, but could > certainly change the rtp-usage draft to say ".MUST be implemented and > used." if that would help? > >> > >> That is fine *if RTP is being used*. > > > > I am suggesting adding this to the RTP usage draft. > > > >> Use, or even implementation, of RTP should not be required in WebRTC > devices that don't need it. > > > > Perhaps, but if implementing RTP isn't a requirement, that needs to > be captured somewhere. The rtcweb-overview-11 draft currently mandates > RTP be implemented. > > It is appropriate for the overview to mandate RTP support *for > browsers*. > > But the current discussion is about how to frame requirements for > compliant non-browser devices. > > If there was an intent to define some non-browser *platform* for webrtc > applications then it would probably be appropriate to mandate RTP > support for them too. (AFAIK there is no plan to define such a > platform.) > > But other devices that only need data channels shouldn't be required to > implement RTP. > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Aug 22 15:55:08 2014 Return-Path: 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 227F41A0B00 for ; Fri, 22 Aug 2014 15:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 GemQ0vVmCiMS for ; Fri, 22 Aug 2014 15:55:04 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929F51A00A5 for ; Fri, 22 Aug 2014 15:55:04 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id hy10so12931150vcb.4 for ; Fri, 22 Aug 2014 15:55:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=pQk5bQQ3mE/S0ggfJioIkzZ3jQxNyKQjG+5Cg75kvuw=; b=F2/C6NsLE4jbcJ0Le3Z2duzGg/3diVqNro2aVg7MpbuLnHUzOJPzw6Pw4cud3GmYPl uEAze2kVKWBu4wNJmUiI7/M9PAmg9WiherioRJlr/SU7i8G2biLlJLg/tbMaL/VySWQx KyE4a0qxYQSaGCfkJ9L7z9kO+zop+XXa7ewPljf/rL5YSprY5uUnQG3lFFabRozYL/Ou WqjfkR9M0M4jJ6MtbAiccv8JhNLvQR3f61v3YH9u6YT08klJDCYpR5JaWreoKyFFmupV HOLt/LZOoJz1kZoIlDv1Zvr0DPRKE/feO2I/0YJpMTuGG6f8olq9dADQSqxuLLrDpL5P Zhpw== X-Gm-Message-State: ALoCoQkUbg6d+kNg1qmEKPgJbh5+YAZyl4iHwjpLGzwVr/aqFmCGylheRGnePng4kmLsz1Wkjje6 X-Received: by 10.52.87.144 with SMTP id ay16mr1898986vdb.43.1408748103538; Fri, 22 Aug 2014 15:55:03 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx.google.com with ESMTPSA id i3sm91922568vds.25.2014.08.22.15.55.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Aug 2014 15:55:03 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id la4so13057563vcb.37 for ; Fri, 22 Aug 2014 15:55:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.253.39 with SMTP id zx7mr4908770vdc.2.1408748102862; Fri, 22 Aug 2014 15:55:02 -0700 (PDT) Received: by 10.52.8.193 with HTTP; Fri, 22 Aug 2014 15:55:02 -0700 (PDT) In-Reply-To: <20140822225405.23952.98941.idtracker@ietfa.amsl.com> References: <20140822225405.23952.98941.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 18:55:02 -0400 Message-ID: From: Benjamin Schwartz To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1135f63c3feaff05013fba96 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Z_WeNNDAVLQpnk3cZbTcx--kQUM Subject: [rtcweb] Fwd: New Version Notification for draft-schwartz-rtcweb-return-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 22:55:07 -0000 --001a1135f63c3feaff05013fba96 Content-Type: text/plain; charset=UTF-8 I've added some diagrams and made minor wording changes in response to suggestions from Philip Hancke. ---------- Forwarded message ---------- From: Date: Fri, Aug 22, 2014 at 6:54 PM Subject: New Version Notification for draft-schwartz-rtcweb-return-01.txt To: "Benjamin M. Schwartz" A new version of I-D, draft-schwartz-rtcweb-return-01.txt has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository. Name: draft-schwartz-rtcweb-return Revision: 01 Title: Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Document date: 2014-08-22 Group: Individual Submission Pages: 12 URL: http://www.ietf.org/internet-drafts/draft-schwartz-rtcweb-return-01.txt Status: https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/ Htmlized: http://tools.ietf.org/html/draft-schwartz-rtcweb-return-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-schwartz-rtcweb-return-01 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a1135f63c3feaff05013fba96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've added some diagrams and made minor wording change= s in response to suggestions from Philip Hancke.

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Aug 22, 2014 at 6:54 PM
Subject: New Version Notification for= draft-schwartz-rtcweb-return-01.txt
To: "Benjamin M. Schwartz"= ; <bemasc@webrtc.org>


A new version of I-D, draft-schwartz-rtcweb-return-01.txt
has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-rtcweb-return<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Recursively Encapsulated TURN (RET= URN) for Connectivity and Privacy in WebRTC
Document date:=C2=A0 2014-08-22
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tp://www.ietf.org/internet-drafts/draft-schwartz-rtcweb-return-01.txt Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatrac= ker.ietf.org/doc/draft-schwartz-rtcweb-return/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/htm= l/draft-schwartz-rtcweb-return-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://= www.ietf.org/rfcdiff?url2=3Ddraft-schwartz-rtcweb-return-01

Abstract:
=C2=A0 =C2=A0In the context of WebRTC, the concept of a local TURN proxy ha= s been
=C2=A0 =C2=A0suggested, but not reviewed in detail.=C2=A0 WebRTC applicatio= ns are
=C2=A0 =C2=A0already using TURN to enhance connectivity and privacy.=C2=A0 = This
=C2=A0 =C2=A0document explains how local TURN proxies and WebRTC applicatio= ns can
=C2=A0 =C2=A0work together.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a1135f63c3feaff05013fba96-- From nobody Fri Aug 22 16:53:28 2014 Return-Path: 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 7E5B91A6F29 for ; Fri, 22 Aug 2014 16:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 rrENLRcZxPrd for ; Fri, 22 Aug 2014 16:53:24 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 934C01A6F27 for ; Fri, 22 Aug 2014 16:53:23 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so11314253wev.27 for ; Fri, 22 Aug 2014 16:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=YHUxAfoKTqQRO1uL4IL4OeycCtr92c/wsoEpTiK74lg=; b=ty3voraGQEC//PiURAoNOEbtdtZVp0XkwdY+qfUErPhZetNVzXImO4yNX6RZiQIeBr 4nZnKojW85vLov98Sq2eztqUTdcOvuGE7v1Nv6Fy/PzehGxVLOEjxO1hfFBcIPris5nW kygQnQCDwl9MQQrp8JKfAOItM025Zr78XoJT+AeinTRCZgdxS/BFsdUyogYjVWmis+Tk nsO2jXRo8pBhgOyNcmY2Avvb8XjTG4f1Q9cF/aBHhRqkkQewz3YFMKD4shUUrmlW1Myp riXz4zb7IBPVCflVLAyRH18Dj4FVwffUagoNQD13hCmFxi2CyML4bMwqR2Vy0XD7jCIF JOsg== X-Received: by 10.180.73.115 with SMTP id k19mr1301775wiv.35.1408751602124; Fri, 22 Aug 2014 16:53:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.90.229 with HTTP; Fri, 22 Aug 2014 16:53:02 -0700 (PDT) In-Reply-To: <3DF911000D80F6459928AC50D3D742F601AA20@gbplmail02.genband.com> References: <3DF911000D80F6459928AC50D3D742F601A509@gbplmail02.genband.com> <53F66180.6050308@alvestrand.no> <3DF911000D80F6459928AC50D3D742F601AA20@gbplmail02.genband.com> From: Barry Dingle Date: Sat, 23 Aug 2014 09:53:02 +1000 Message-ID: To: Jeremy Fuller Content-Type: multipart/alternative; boundary=f46d043749cbd24c460501408af4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WUIrHBLL1fOOPTPfzzL_fIAxmj0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC gateway - draft-ietf-rtcweb-overview-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:53:26 -0000 --f46d043749cbd24c460501408af4 Content-Type: text/plain; charset=UTF-8 Hi Harald, I see Jeremy's point. Gateways between a WebRTC environment and non-WebRTC environments need to convert BOTH media and signalling. Media-only Gateways are usually referred to as 'Media Gateways'. In draft-alvestrand-rtcweb-gateways-00 Section 1 paragraph 2, the description of 'the Gateway' refers only to the 'media'. As the document later refers to the Signaling Model, I suggest that the Introduction should also refer to 'Signalling' briefly also. I suggest a new second paragraph in Section 1 that says: *' When communicating between a WebRTC environment and non-WebRTC environments, interworking of both the media and signaling is required. As signaling protocols are outside the scope of WebRTC, this document only considers signaling interworking at a high level'. * To avoid confusion, when referring to 'Media only' functionality, the document should use the term 'WebRTC *media* gateway' instead of 'WebRTC gateway'. Cheers, /Barry Dingle On Fri, Aug 22, 2014 at 6:34 PM, Jeremy Fuller wrote: > Hi Harald, > > It would be good to have something which explains to the reader that there > exists functionality for transforming signalling. I am reasonably flexible > on the term used. I proposed associating this functionality with the term > WebRTC Gateway to reduce the proliferation of new terms. > > Regards, > Jeremy > > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: 21 August 2014 22:16 > To: Jeremy Fuller > Cc: rtcweb@ietf.org > Subject: Re: WebRTC gateway - draft-ietf-rtcweb-overview-11.txt > > On 08/21/2014 10:24 PM, Jeremy Fuller wrote: > > Hi Harald, > > > > With regard to your addition of the WebRTC gateway in the rtcweb > overview. I appreciate signalling is out of scope for WebRTC, but as you > say in your draft alvestrand-rtcweb-gateways-00.txt "any practical gateway > needs to deal with signalling". Without getting into too much detail or any > implementation constraints, would it be possible to add a reference to > signalling when introducing the WebRTC gateway? > > > > I have suggested some modified text below for your consideration: > > > > Current Text (section 1): > > "A WebRTC gateway is something that mediates media traffic to non-WebRTC > entities. It is like a device, but has certain restrictiions on where it > can operate, which means that some of the requirements can be relaxed." > > > > Proposed Text (section 1): > > "A WebRTC gateway is something that mediates media traffic, or > signalling, or both, to non-WebRTC entities. It is like a device, but has > certain restrictions on where it can operate, which means that some of the > requirements can be relaxed." > > This does not work for me. A WebRTC gateway has to handle media, because > it's the transport of media that WebRTC specifies. A pure signalling > gateway would just transform the signalling between two WebRTC-capable > endpoints (WebRTC endpoints?); this is what an application does, not what a > WebRTC gateway does. > > There might be a need to name the class of applications that transform > signalling; I'm not sure. > > > > > > > Regards, > > Jeremy > > > > > > -----Original Message----- > > Date: Mon, 18 Aug 2014 04:19:16 -0700 > > From: internet-drafts@ietf.org > > To: i-d-announce@ietf.org > > Cc: rtcweb@ietf.org > > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-11.txt > > Message-ID: <20140818111916.2857.63981.idtracker@ietfa.amsl.com> > > Content-Type: text/plain; charset="utf-8" > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Real-Time Communication in > WEB-browsers Working Group of the IETF. > > > > Title : Overview: Real Time Protocols for > Browser-based Applications > > Author : Harald T. Alvestrand > > Filename : draft-ietf-rtcweb-overview-11.txt > > Pages : 22 > > Date : 2014-08-18 > > > > Abstract: > > This document gives an overview and context of a protocol suite > > intended for use with real-time applications that can be deployed in > > browsers - "real time communication on the Web". > > > > It intends to serve as a starting and coordination point to make sure > > all the parts that are needed to achieve this goal are findable, and > > that the parts that belong in the Internet protocol suite are fully > > specified and on the right publication track. > > > > This document is an Applicability Statement - it does not itself > > specify any protocol, but specifies which other specifications RTCWEB > > compliant implementations are supposed to follow. > > > > This document is a work item of the RTCWEB working group. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-rtcweb-overview-11 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-11 > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d043749cbd24c460501408af4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Harald,

I see Jeremy's point.

Ga= teways between a WebRTC environment and non-WebRTC environments need to con= vert BOTH media and signalling. Media-only Gateways are usually referred to= as 'Media Gateways'. In draft-alvestrand-rtcweb-gateways-00 Sectio= n 1 paragraph 2, the description of 'the Gateway' refers only to th= e 'media'.

As the document later refers to the Signaling Model, I suggest that the= Introduction should also refer to 'Signalling' briefly also.

I suggest a new second paragraph in Section 1 that says:

'= ; When communicating between a WebRTC environment and non-WebRTC environmen= ts,=20 interworking of both the media and signaling is required. As signaling prot= ocols are outside the scope=20 of WebRTC, this document only considers signaling interworking at a high le= vel'.

To avoid confusion, when referring to 'Media only' functionality, the document should use t= he term 'WebRTC media gateway' instead of 'WebRTC=20 gateway'.

Cheers,
/Barry Dingle



On Fri, Aug 22, 2014 at 6:34 PM, Jeremy = Fuller <jeremy.fuller@genband.com> wrote:
Hi Harald,

It would be good to have something which explains to the reader that there = exists functionality for transforming signalling. I am reasonably flexible = on the term used. I proposed associating this functionality with the term W= ebRTC Gateway to reduce the proliferation of new terms.

Regards,
Jeremy

-----Original Message-----
From: Harald Alvestrand [mailto:har= ald@alvestrand.no]
Sent: 21 August 2014 22:16
To: Jeremy Fuller
Cc: rtcweb@ietf.org
Subject: Re: WebRTC gateway - draft-ietf-rtcweb-overview-11.txt

On 08/21/2014 10:24 PM, Jeremy Fuller wrote:
> Hi Harald,
>
> With regard to your addition of the WebRTC gateway in the rtcweb overv= iew. I appreciate signalling is out of scope for WebRTC, but as you say in = your draft alvestrand-rtcweb-gateways-00.txt "any practical gateway ne= eds to deal with signalling". Without getting into too much detail or = any implementation constraints, would it be possible to add a reference to = signalling when introducing the WebRTC gateway?
>
> I have suggested some modified text below for your consideration:
>
> Current Text=C2=A0 (section 1):
> "A WebRTC gateway is something that mediates media traffic to non= -WebRTC entities.=C2=A0 It is like a device, but has certain restrictiions = on where it can operate, which means that some of the requirements can be r= elaxed."
>
> Proposed Text (section 1):
> "A WebRTC gateway is something that mediates media traffic, or si= gnalling, or both, to non-WebRTC entities.=C2=A0 It is like a device, but h= as certain restrictions on where it can operate, which means that some of t= he requirements can be relaxed."

This does not work for me. A WebRTC gateway has to handle media, because it= 's the transport of media that WebRTC specifies. A pure signalling gate= way would just transform the signalling between two WebRTC-capable endpoint= s (WebRTC endpoints?); this is what an application does, not what a WebRTC = gateway does.

There might be a need to name the class of applications that transform sign= alling; I'm not sure.



>
> Regards,
> Jeremy
>
>
> -----Original Message-----
> Date: Mon, 18 Aug 2014 04:19:16 -0700
> From: internet-drafts@ietf= .org
> To: i-d-announce@ietf.org=
> Cc: rtcweb@ietf.org
> Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-11.txt
> Message-ID: <20140818111916.2857.63981.idtracker@ietfa.amsl.com><= br> > Content-Type: text/plain; charset=3D"utf-8"
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 =C2=A0This draft is a work item of the Real-Time Communication i= n WEB-browsers Working Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Overview: Real Time Protocols for Browser-based Applications >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : Harald T. Alvestrand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-rtcweb-overview-11.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 22
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2014-08-18
>
> Abstract:
>=C2=A0 =C2=A0 =C2=A0This document gives an overview and context of a pr= otocol suite
>=C2=A0 =C2=A0 =C2=A0intended for use with real-time applications that c= an be deployed in
>=C2=A0 =C2=A0 =C2=A0browsers - "real time communication on the Web= ".
>
>=C2=A0 =C2=A0 =C2=A0It intends to serve as a starting and coordination = point to make sure
>=C2=A0 =C2=A0 =C2=A0all the parts that are needed to achieve this goal = are findable, and
>=C2=A0 =C2=A0 =C2=A0that the parts that belong in the Internet protocol= suite are fully
>=C2=A0 =C2=A0 =C2=A0specified and on the right publication track.
>
>=C2=A0 =C2=A0 =C2=A0This document is an Applicability Statement - it do= es not itself
>=C2=A0 =C2=A0 =C2=A0specify any protocol, but specifies which other spe= cifications RTCWEB
>=C2=A0 =C2=A0 =C2=A0compliant implementations are supposed to follow. >
>=C2=A0 =C2=A0 =C2=A0This document is a work item of the RTCWEB working = group.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ove= rview/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtcweb-overview-11
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcw= eb-overview-11
>
>
> Please note that it may take a couple of minutes from the time of subm= ission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d043749cbd24c460501408af4-- From nobody Sun Aug 24 22:37:08 2014 Return-Path: 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 6F3881A8A3D for ; Sun, 24 Aug 2014 22:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 3DCJMsKvv81N for ; Sun, 24 Aug 2014 22:37:05 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F181A8A3A for ; Sun, 24 Aug 2014 22:37:05 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so14578042vcb.19 for ; Sun, 24 Aug 2014 22:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=++1u5/6AgQmrZPtsnsuYA4BBPtdVHmk8ppzQCpRzOiM=; b=MVysrNZWXktZbtk67bNuqgbj0C0EiKIv49lnEAoSXPUmqo3kfxt6OTQIdLXgw4LwYv gUE3kiR1cXFvOnToQnmEOvnqKbLIn5bbB9/RHNs0MWa/aylajISLe9txzYezcArA9+n1 3NoQxN6VpRrlDidslRsNOIfnTDgqxQjWZBa9Ftsq9WqQy/wiG9JLyAskUZtLOaDawAL+ JSAWtw4qD93pk0QCGXVolkzmhe77jMfTnnz6YHqhHHM9qPYDeb5qYPkWd8/XcxIPWodS KHgsH5FIJ6DTNxy22gyApInn+Mrdo5y5hNIDSXzIYWGLDzWQOUkOVWpRHIpwtyi/SMTo YTXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=++1u5/6AgQmrZPtsnsuYA4BBPtdVHmk8ppzQCpRzOiM=; b=LKq0Ktf46WOvPqmW5d1brX3HovwaQmD/MSo087sDPCUvp3wXDNX1J5ajiSW34rn6Sb HP77PfA/PXbG9V/TUD5pN9C3BrRmoEDReB7tAxax/bZLRL2IqgCwlvDIjQFjd6UX9Eoy hB1J7269EIupDxyzh8iuNJVNRHSvizmkO73Ypu5ciKYoybGni7xLI8J5RLP5dR5LkB8t woSsJtVBMHD8M6ozcAzCnrzvrXcqp7dq/izoFYx9lhHbhMP7P8vbkkHgEZdyNIEsPFi7 Qk4F0icm/NUslTJ1vJVCOcjnJM/eXiHiyFrzkR9V7IXq/ARcFY06/AX9lPD49wyTas8s 9KSw== X-Gm-Message-State: ALoCoQn0PwJPSePfKurVAz/vpocW83PwZ7o5AsTMz3ISe5+oFkA5se+eC4lsAfB28sgy8GPi1Wky X-Received: by 10.220.168.210 with SMTP id v18mr16710792vcy.3.1408945024068; Sun, 24 Aug 2014 22:37:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Sun, 24 Aug 2014 22:36:43 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Sun, 24 Aug 2014 22:36:43 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11c247e4ab0fa905016d93fe Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-Rbci8KYjkow3Rmw-UZlznv7ZEg Cc: draft-ietf-rtcweb-transports@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 05:37:06 -0000 --001a11c247e4ab0fa905016d93fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, 4571 must be used for ICE connectivity checks, when using ICE-TCP. However, TURN/TCP has its own framing for STUN messages. I would simplify your sentence to: If ICE-TCP connections are used, framing according to [RFC4571] MUST be used for all packets, unless the content has its own framing mechanism. On Fri, Aug 22, 2014 at 8:38 AM, I=C3=B1aki Baz Castillo wr= ote: > Hi, > > draft-ietf-rtcweb-transports-06 says: > > If TCP connections are used, RTP framing according to [RFC4571] MUST > be used, both for the RTP packets and for the DTLS packets used to > carry data channels. > > > Not just RTP and DTLS, but also for STUN packets must be framed with > RFC4571. And I do not understand why "DTLS packets used to carry data > channels". In fact all the DTLS packets (also the ones for the > handshake) must be framed as per RFC 4571. > > > So I suggest to improve the above text as follows: > > If TCP connections are used, RTP framing according to [RFC4571] MUST > be used for the STUN packets, SRTP packets, SRTCP packets and DTLS > packets. > > > > > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c247e4ab0fa905016d93fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, 4571 must be used for ICE connectivity checks, when u= sing ICE-TCP.

However, TURN/TCP has its own framing for = STUN messages.

I would simplify your sentence to:<= /div>

=C2=A0 =C2=A0If ICE-TCP connections are used, framing according to [RF= C4571] MUST
=C2=A0 =C2=A0b= e used for all packets, unless the content has its own framing mechanism.


O= n Fri, Aug 22, 2014 at 8:38 AM, I=C3=B1aki Baz Castillo &= lt;ibc@aliax.net>= wrote:
Hi,

draft-ietf-rtcweb-transports-06 says:

=C2=A0 =C2=A0If TCP connections are used, RTP framing according to [RFC4571= ] MUST
=C2=A0 =C2=A0be used, both for the RTP packets and for the DTLS packets use= d to
=C2=A0 =C2=A0carry data channels.


Not just RTP and DTLS, but also for STUN packets must be framed with
RFC4571. And I do not understand why "DTLS packets used to carry data<= br> channels". In fact all the DTLS packets (also the ones for the
handshake) must be framed as per RFC 4571.


So I suggest to improve the above text as follows:

=C2=A0 =C2=A0If TCP connections are used, RTP framing according to [RFC4571= ] MUST
=C2=A0 =C2=A0be used for the STUN packets, SRTP packets, SRTCP packets and = DTLS
=C2=A0 =C2=A0packets.






--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c247e4ab0fa905016d93fe-- From nobody Mon Aug 25 03:55:15 2014 Return-Path: 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 726331A902C for ; Mon, 25 Aug 2014 03:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 fSgKLwRZD-8D for ; Mon, 25 Aug 2014 03:55:10 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9731A9029 for ; Mon, 25 Aug 2014 03:55:09 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so2318451wib.16 for ; Mon, 25 Aug 2014 03:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KNgAs7eY4nV17yo/DWySbCr0vUqlkyw7IP/o7677vmU=; b=Nc43Was+tzn1tVj80PYY6vFbomeogHIUzjZ4ww+PgDRIOX1WpJL/2IY1LdqFluL9iM e1I6wBrARh58TvZKE64AmfRnnk3/ioZXh+Ze2L9N731J3ZEbvl4VCm9CMkvK//EuJpe8 YAd6yMA/v6ThdmbzfDqg8NlKg1vioz/DvQ6xXRTtrWZrY4APz1fMv/r/pAhaOvS1eETs U0Y0qWGjp389wEoJwCczA0Ef2OiQhuuF55Um1huWt6690s54Yq/3nHgYOTnUQ5L44DBI yKfRAqBcssyWHqlrMnoIcrK2StLbpyo3T452LwU8zTSN3/nSxCL+W9dpDJIvSGYL1jML Larw== MIME-Version: 1.0 X-Received: by 10.180.108.147 with SMTP id hk19mr14399766wib.4.1408964108552; Mon, 25 Aug 2014 03:55:08 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Mon, 25 Aug 2014 03:55:08 -0700 (PDT) In-Reply-To: <009001cfbe4f$6b92f280$42b8d780$@co.in> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Mon, 25 Aug 2014 16:25:08 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Parthasarathi R Content-Type: multipart/alternative; boundary=e89a8f3ba5b53111850501720513 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DhUZxZ4LcVF69W18w0nW9rOXDoM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 10:55:13 -0000 --e89a8f3ba5b53111850501720513 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought a "SHOULD perform" is more appropriate for a WebRTC device as it doesn't implement the public API and might run a proprietary/native app running in a constrained environment and the overhead of performing the periodic consent might overweigh the benefits. However, I don't have an issue of making it a MUST -- at least no one has objected so far. I hear the following options from the discussions so far: Option 1: WebRTC browser - MUST WebRTC device - MUST Other (WebRTC/non-WebRTC) entities - MAY Option 2: Any WebRTC entity doing full ICE - MUST Other (WebRTC/non-WebRTC) entities - MAY Obviously, #2 is stronger than #1 and also covers a WebRTC gateway doing full ICE. I would like to hear from others as well.. Muthu On Sat, Aug 23, 2014 at 2:54 AM, Parthasarathi R wrote: > Hi Ram/Muthu, > > > > There is a terminology variation here. As per the current overview > document, WebRTC device supports full WebRTC protocol requirement which > includes consent-check. In case consent check is excluded from WebRTC > device, the new definition has to be provided for =E2=80=9CWebRTC device= =E2=80=9D in > =E2=80=93overview draft. I don=E2=80=99t think that WebRTC device definit= ion has to be > changed now. > > > > IMO, WebRTC device & WebRTC browser MUST support consent check. As > discussed in another mail thread, there is an need to define =E2=80=9CWeb= RTC > endpoint=E2=80=9D which relaxes the lot of WebRTC protocol requirement ba= sed on the > specific deployment like Enterprise, LTE EPC. =E2=80=9CWebRTC Endpoint=E2= =80=9D & =E2=80=9CWebRTC > Gateway=E2=80=9D MAY support consent check. > > > > I have highlighted Full ICE as a criteria for =E2=80=9CWebRTC Endpoint=E2= =80=9D & =E2=80=9CWebRTC > Gateway=E2=80=9D in > http://www.ietf.org/mail-archive/web/rtcweb/current/msg12938.html as it > helps the implementers to decide whether consent check has to be > implemented in their =E2=80=9CWebRTC Endpoint=E2=80=9D/ =E2=80=9CWebRTC G= ateway=E2=80=9D or not. As =E2=80=9CWebRTC > Endpoint=E2=80=9D is yet to defined and =E2=80=9CWebRTC gateway=E2=80=9D = is just now proposed in > -11 overview draft, I have proposed the text as > > > > =E2=80=9CFull ICE supporting WebRTC entities MUST support consent freshn= ess.=E2=80=9D > > > > Please let me your opinion on the same. > > > > Also, I agree with Muthu=E2=80=99s statement to indicates the other requi= rement > for WebRTC entities to include consent check are: > > =E2=80=9Cto use the mechanism to make it more secure or compute RTT or ca= rry > network information=E2=80=9D > > > > > > Thanks > > Partha > > > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ram Mohan > R (rmohanr) > *Sent:* Friday, August 22, 2014 9:48 PM > *To:* Christer Holmberg; Roman Shpount; Muthu Arul Mozhi Perumal > > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > > > Right. I think we had discussed this in the past and added the below text > in the draft > > > > " WebRTC endpoints are required to support full ICE as specified in > > section 3.4 of [I-D.ietf-rtcweb-transports ]. However, when WebRTC > > endpoints interwork with other endpoints that support only ICE-lite > > (e.g. gateways) those endpoints will not generate consent checks, but > > just respond to consent checks they receive=E2=80=9D > > > Isn=E2=80=99t this sufficient ? > > > Ram > > > > *From: *Christer Holmberg > *Date: *Friday, 22 August 2014 9:29 pm > *To: *Roman Shpount , Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > > > Hi, > > > > An ICE-lite endpoint must already today *REPLY* to STUN requests - consen= t > freshness does not change that. > > > > But, I don't think an ICE-lite endpoint shall be mandated to *SEND* > consent freshness requests. > > > > Regards, > > > > Christer > > > > > ------------------------------ > > *From:* rtcweb [rtcweb-bounces@ietf.org] on behalf of Roman Shpount [ > roman@telurix.com] > *Sent:* Friday, 22 August 2014 4:37 PM > *To:* Muthu Arul Mozhi Perumal > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > On Fri, Aug 22, 2014 at 1:25 AM, Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> wrote: > > draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC > browser more secure. It however allows an RTP endpoint (that also does IC= E) > to use the mechanism to make it more secure or compute RTT or carry netwo= rk > information or whatever. However, requiring every RTP endpoint perform it > seems asking too much. > > > > My take: > > WebRTC browser - MUST > > WebRTC devide - SHOULD > > Other RTP entities (including WebRTC gateway) - MAY > > > > > > I would say that all full ICE endpoint interworking with WebRTC MUST > implement consent freshness. ICE-LITE will not implement, but MUST respon= d > (unless someone defines it, but once you start sending STUN request you > might as well do full ICE, so I do not see much point in it). And to > conclude strongly encourage full ICE implementation for security and othe= r > reasons. > > _____________ > Roman Shpount > > > --e89a8f3ba5b53111850501720513 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought a "SHOULD perform" = is more appropriate for a WebRTC device as it doesn't implement the pub= lic API and might run a proprietary/native app running in a constrained env= ironment and the overhead of performing the periodic consent might overweig= h the benefits. However, I don't have an issue of making it a MUST -- a= t least no one has objected so far. I hear the following options from the d= iscussions so far:

Option 1:
WebRTC browser - MUST
WebRTC device - MUST
Other (WebRTC/non-WebRTC) entities - MAY

=
Option 2:
Any WebRTC entity doing full ICE - MUST
Other (WebRTC/non-WebRTC) entities - MAY
=C2=A0=
Obviously, #2 is stronger than #1 and also covers a WebRTC gateway doing fu= ll ICE. I would like to hear from others as well..

Muthu

On S= at, Aug 23, 2014 at 2:54 AM, Parthasarathi R <partha@parthasarat= hi.co.in> wrote:

Hi Ram/Muthu,

=C2=A0

There is a terminology variation here. As pe= r the current overview document, WebRTC device supports full WebRTC protocol requirement = which includes consent-check. In case consent check is excluded from WebRTC devic= e, =C2=A0the new definition has to be provided for =E2=80=9CWebRTC device=E2=80=9D in = =E2=80=93overview draft. I don=E2=80=99t think that WebRTC device definition has to be change= d now.

=C2=A0

IMO, WebRTC device & WebRTC browser MUST= support consent check. As discussed in another mail thread, there is an need to define =E2= =80=9CWebRTC endpoint=E2=80=9D which relaxes the lot of WebRTC protocol requirement base= d on the specific deployment like Enterprise, LTE EPC. =E2=80=9CWebRTC Endpoint= =E2=80=9D & =E2=80=9CWebRTC Gateway=E2=80=9D MAY support consent check.=

=C2=A0

I have highlighted Full ICE as a criteria fo= r =E2=80=9CWebRTC Endpoint=E2=80=9D & =E2=80=9CWebRTC Gateway=E2=80=9D in http://www.ietf.org/mail-archive/web/rtcweb/current/msg12938.html as it helps the implementers to decide whether consent check has to be implemented in their =E2=80=9CWebRTC Endpoint=E2=80=9D/ =E2=80=9CWebRTC Gat= eway=E2=80=9D or not. As =E2=80=9CWebRTC Endpoint=E2=80=9D is yet to defined and =E2=80= =9CWebRTC gateway=E2=80=9D is just now proposed in -11 overview draft, =C2=A0I have p= roposed the text as

=C2=A0

=E2=80=9CFull ICE supporting WebRTC entities= =C2=A0MUST support consent freshness.=E2=80=9D

=C2=A0

Please let me your opinion on the same. <= /u>

=C2=A0

Also, I agree with Muthu=E2=80=99s statement= to indicates the other requirement for WebRTC entities to include consent check are:<= u>

=E2=80=9Cto use the mechanism to make it more secure or= compute RTT or carry network information=E2=80=9D

=C2=A0

=C2=A0

Thanks

Partha

=C2=A0

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Ram Mohan R (rmohanr)
Sent: Friday, August 22, 2014 9:48 PM
To: Christer Holmberg; Roman Shpount; Muthu Arul Mozhi Perumal


Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

=C2=A0

Right. I think we had discussed this in the past an= d added the below text in the draft

=C2=A0

" WebRTC endpoints are required to support ful= l ICE as specified in

=C2=A0=C2=A0 section 3.4 =
of [I-D.ietf-rtcwe=
b-transports].=C2=A0 However, when WebRTC
=C2=A0=C2=A0 endpoints in=
terwork with other endpoints that support only ICE-lite
=C2=A0=C2=A0 (e.g.=
 gateways) those endpoints will not generate consent checks, but<=
/u>
=C2=A0=C2=A0 just respond=
 to consent checks they receive=E2=80=9D

Isn=E2=80=99t this=
 sufficient ?

Ram<=
/span>

=C2=A0

From: Christer Holmberg <christer.holmberg@e= ricsson.com>
Date: Friday, 22 August 2014 9:29 pm
To: Roman Shpount <roman@telurix.com>, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

=C2=A0

Hi,

=C2=A0

An ICE-lite endpoint must already today=C2=A0*REPLY* to STUN requests - consen= t freshness does not change that.

=C2=A0

But, I don't think an ICE-lite endpoint shall be mandated to *SEND* consent freshness requests.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb [rtcweb-bounce= s@ietf.org] on behalf of Roman Shpount [roman@telurix.com]
Sent: Friday, 22 August 2014 4:37 PM
To: Muthu Arul Mozhi Perumal
Cc: rtcweb@ietf= .org
Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consen= t-freshness

On Fri, Aug 22, 2014 at = 1:25 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

draft-ietf-rtcweb-stun-consent-freshness is about making the WebRTC browser more secure. It however allows an RTP endpoint (that also does ICE) to use the mechanism to make it more secure o= r compute RTT or carry network information or whatever. However, requiring ev= ery RTP endpoint perform it seems asking too much.

=C2=A0

My take:

WebRTC browser - MUST

WebRTC devide - SHOULD

Other RTP entities (including WebRTC gateway) - MAY

=C2=A0

=C2=A0

=C2=A0I would say that a= ll full ICE endpoint interworking with WebRTC MUST implement consent freshness. ICE-LITE will not implement, but MUST respond (unless someone defines it, b= ut once you start sending STUN request you might as well do full ICE, so I do = not see much point in it). And to conclude strongly encourage full ICE implementation for security and other reasons.

_____________
Roman Shpount

=C2=A0


--e89a8f3ba5b53111850501720513-- From nobody Mon Aug 25 05:43:40 2014 Return-Path: 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 470C61A9081 for ; Mon, 25 Aug 2014 05:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 juiah0hw3DtO for ; Mon, 25 Aug 2014 05:43:36 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DE81A9083 for ; Mon, 25 Aug 2014 05:43:35 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so13301864wes.37 for ; Mon, 25 Aug 2014 05:43:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t+BO0uVzsS+tZFeRcJMeaAb+gjZ0Eqszk1ceHLFdGpI=; b=A4lBMWrlmBodoRg/9daLK8rhu4L2iVTCwe2338kK8ZwJ9H9CGzD5JXOBwSirGz7WNo sqrcC2r8eJP7ls0BqcM69Bp55c5BNohoF0zdcwjFP/2t0XL6T0iKodoga9IGWvn/IiUi KoCIlYhtXSSKy5Ux4dQrg9ZVLZKCrZYgYm07r8+hEXMVCG4NCdYfnwT2XLgT0+j91UX8 kaFx30yLXCj9IGVa/zBqF6Oma57ICQ3Ek6JwgUa9cuPz814XUFvg+fLfXC75ozSXncS8 4GoFfac0uzQ4JFylLPf4uDb6iZ4jTAQBPSH7t92hlPQAmbryh+zgkySHaNecrysLbCkT cM4w== X-Gm-Message-State: ALoCoQn2Z9MYPcugawjjTEV46aMt1ZtchxD6l2czlMgO91bSGUK6PDyxLcSyeiqtD4BK49wgp3is X-Received: by 10.180.212.78 with SMTP id ni14mr15454319wic.44.1408970614612; Mon, 25 Aug 2014 05:43:34 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by mx.google.com with ESMTPSA id pl7sm36368924wjc.43.2014.08.25.05.43.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 05:43:33 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so12997842wgg.19 for ; Mon, 25 Aug 2014 05:43:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.38.84 with SMTP id e20mr15004377wik.43.1408970613158; Mon, 25 Aug 2014 05:43:33 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Mon, 25 Aug 2014 05:43:33 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Mon, 25 Aug 2014 08:43:33 -0400 Message-ID: From: Roman Shpount To: Muthu Arul Mozhi Perumal Content-Type: multipart/alternative; boundary=e89a8f643366e57b7a0501738816 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/AKKad6HakbJx_gzE02odhnAqRKc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 12:43:38 -0000 --e89a8f643366e57b7a0501738816 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 25, 2014 at 6:55 AM, Muthu Arul Mozhi Perumal < muthu.arul@gmail.com> wrote: > I thought a "SHOULD perform" is more appropriate for a WebRTC device as it > doesn't implement the public API and might run a proprietary/native app > running in a constrained environment and the overhead of performing the > periodic consent might overweigh the benefits. However, I don't have an > issue of making it a MUST -- at least no one has objected so far. I hear > the following options from the discussions so far: > > Option 1: > WebRTC browser - MUST > WebRTC device - MUST > Other (WebRTC/non-WebRTC) entities - MAY > > Option 2: > Any WebRTC entity doing full ICE - MUST > Other (WebRTC/non-WebRTC) entities - MAY > > > To be clear, my opinion is Any WebRTC entity implementing full ICE - MUST Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST NOT This way we are not inventing entity types and not defining behaviors which would never be used (such as sending consent from an end point which would send no STUN requests otherwise). This will also reduce the number of interop cases from four (full ICE with consent, full iCE without consent, ICE-lite, ICE-lite with consent) to only two (full ICE with consent, ICE-lite). _____________ Roman Shpount --e89a8f643366e57b7a0501738816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 25, 2014 at 6:= 55 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wr= ote:
I thought a "SHOULD perform" is more appropriate for a WebRTC dev= ice as it doesn't implement the public API and might run a proprietary/= native app running in a constrained environment and the overhead of perform= ing the periodic consent might overweigh the benefits. However, I don't= have an issue of making it a MUST -- at least no one has objected so far. = I hear the following options from the discussions so far:

<= /div>
= Option 1:
WebRTC browser - MUST
WebRTC device - MUST
Other (WebRTC/non-WebRTC) entities - MAY

Option 2:
Any WebRTC entity doing full ICE - MUST
Other (WebRTC/non-WebRTC) entities - MAY
=C2=A0


To be clear, my opinion = is

Any WebRTC entity implementing full ICE - MUST<= /div>
Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite = -- MUST NOT

This way we are not inventing entity types and not defi= ning behaviors which would never be used (such as sending consent from an e= nd point which would send no STUN requests otherwise). This will also reduc= e the number of interop cases from four (full ICE with consent, full iCE wi= thout consent, ICE-lite, ICE-lite with consent) to only two (full ICE with = consent, ICE-lite).
_____________
Roman Shpount
=C2=A0
--e89a8f643366e57b7a0501738816-- From nobody Mon Aug 25 06:15:26 2014 Return-Path: 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 3EEA81A9085 for ; Mon, 25 Aug 2014 06:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 STcB7k2BqfDI for ; Mon, 25 Aug 2014 06:15:23 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3841A9041 for ; Mon, 25 Aug 2014 06:15:23 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id A4FC660A82E1; Mon, 25 Aug 2014 13:15:19 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s7PDFMX0010635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 09:15:22 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 25 Aug 2014 09:15:22 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Roman Shpount , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPvCyeYIc/MFSTfk+VKNIJfUtwNpvbPhKAgAABDwCAABPQgIAApK+AgACJRYCAAEiyvoAASoGAgAQ4DraAAAQc0A== Date: Mon, 25 Aug 2014 13:15:21 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E52E4B4US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/M_GHpqD0c8WJcfrNSf4CkN4fDQg Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 13:15:25 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E52E4B4US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUm9tYW4gU2hwb3VudA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjUsIDIwMTQgNzo0NCBB TQ0KDQpPbiBNb24sIEF1ZyAyNSwgMjAxNCBhdCA2OjU1IEFNLCBNdXRodSBBcnVsIE1vemhpIFBl cnVtYWwgPG11dGh1LmFydWxAZ21haWwuY29tPG1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbT4+ IHdyb3RlOg0KSSB0aG91Z2h0IGEgIlNIT1VMRCBwZXJmb3JtIiBpcyBtb3JlIGFwcHJvcHJpYXRl IGZvciBhIFdlYlJUQyBkZXZpY2UgYXMgaXQgZG9lc24ndCBpbXBsZW1lbnQgdGhlIHB1YmxpYyBB UEkgYW5kIG1pZ2h0IHJ1biBhIHByb3ByaWV0YXJ5L25hdGl2ZSBhcHAgcnVubmluZyBpbiBhIGNv bnN0cmFpbmVkIGVudmlyb25tZW50IGFuZCB0aGUgb3ZlcmhlYWQgb2YgcGVyZm9ybWluZyB0aGUg cGVyaW9kaWMgY29uc2VudCBtaWdodCBvdmVyd2VpZ2ggdGhlIGJlbmVmaXRzLiBIb3dldmVyLCBJ IGRvbid0IGhhdmUgYW4gaXNzdWUgb2YgbWFraW5nIGl0IGEgTVVTVCAtLSBhdCBsZWFzdCBubyBv bmUgaGFzIG9iamVjdGVkIHNvIGZhci4gSSBoZWFyIHRoZSBmb2xsb3dpbmcgb3B0aW9ucyBmcm9t IHRoZSBkaXNjdXNzaW9ucyBzbyBmYXI6DQoNCk9wdGlvbiAxOg0KV2ViUlRDIGJyb3dzZXIgLSBN VVNUDQpXZWJSVEMgZGV2aWNlIC0gTVVTVA0KT3RoZXIgKFdlYlJUQy9ub24tV2ViUlRDKSBlbnRp dGllcyAtIE1BWQ0KDQpPcHRpb24gMjoNCkFueSBXZWJSVEMgZW50aXR5IGRvaW5nIGZ1bGwgSUNF IC0gTVVTVA0KT3RoZXIgKFdlYlJUQy9ub24tV2ViUlRDKSBlbnRpdGllcyAtIE1BWQ0KDQoNCg0K VG8gYmUgY2xlYXIsIG15IG9waW5pb24gaXMNCg0KQW55IFdlYlJUQyBlbnRpdHkgaW1wbGVtZW50 aW5nIGZ1bGwgSUNFIC0gTVVTVA0KQW55IFdlYlJUQyBlbnRpdHkgKHN1Y2ggYXMgV2ViUlRDIGdh dGV3YXkpIGltcGxlbWVudGluZyBJQ0UtbGl0ZSAtLSBNVVNUIE5PVA0KDQpUaGlzIHdheSB3ZSBh cmUgbm90IGludmVudGluZyBlbnRpdHkgdHlwZXMgYW5kIG5vdCBkZWZpbmluZyBiZWhhdmlvcnMg d2hpY2ggd291bGQgbmV2ZXIgYmUgdXNlZCAoc3VjaCBhcyBzZW5kaW5nIGNvbnNlbnQgZnJvbSBh biBlbmQgcG9pbnQgd2hpY2ggd291bGQgc2VuZCBubyBTVFVOIHJlcXVlc3RzIG90aGVyd2lzZSku IFRoaXMgd2lsbCBhbHNvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIGludGVyb3AgY2FzZXMgZnJvbSBm b3VyIChmdWxsIElDRSB3aXRoIGNvbnNlbnQsIGZ1bGwgaUNFIHdpdGhvdXQgY29uc2VudCwgSUNF LWxpdGUsIElDRS1saXRlIHdpdGggY29uc2VudCkgdG8gb25seSB0d28gKGZ1bGwgSUNFIHdpdGgg Y29uc2VudCwgSUNFLWxpdGUpLg0KPFJhanU+DQpJIHByZWZlciBvcHRpb24gMSwgYnV0IG9rIHdp dGggb3B0aW9uIDIgYXMgd2VsbC4gSSBkaWQgbm90IGhlYXIgYW55IG9iamVjdGlvbnMgdG8gdGhl IHJhdGlvbmFsZSBJIHZvaWNlZCBlYXJsaWVyIGZvciBvcHRpb24gMSwgd2hpY2ggaXMgYXQgaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzEyOTU3 Lmh0bWwNCjwvUmFqdT4NCg0KQlINClJhanUNCg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E52E4B4US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9tYW4gU2hwb3Vu dDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAyNSwgMjAxNCA3OjQ0IEFNPGJyPg0K PGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgMjUsIDIwMTQgYXQgNjo1NSBBTSwgTXV0aHUgQXJ1 bCBNb3poaSBQZXJ1bWFsICZsdDs8YSBocmVmPSJtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5tdXRodS5hcnVsQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgdGhvdWdodCBhICZxdW90O1NIT1VMRCBwZXJm b3JtJnF1b3Q7IGlzIG1vcmUgYXBwcm9wcmlhdGUgZm9yIGEgV2ViUlRDIGRldmljZSBhcyBpdCBk b2Vzbid0IGltcGxlbWVudCB0aGUgcHVibGljIEFQSSBhbmQgbWlnaHQgcnVuIGEgcHJvcHJpZXRh cnkvbmF0aXZlIGFwcCBydW5uaW5nIGluIGEgY29uc3RyYWluZWQgZW52aXJvbm1lbnQgYW5kIHRo ZQ0KIG92ZXJoZWFkIG9mIHBlcmZvcm1pbmcgdGhlIHBlcmlvZGljIGNvbnNlbnQgbWlnaHQgb3Zl cndlaWdoIHRoZSBiZW5lZml0cy4gSG93ZXZlciwgSSBkb24ndCBoYXZlIGFuIGlzc3VlIG9mIG1h a2luZyBpdCBhIE1VU1QgLS0gYXQgbGVhc3Qgbm8gb25lIGhhcyBvYmplY3RlZCBzbyBmYXIuIEkg aGVhciB0aGUgZm9sbG93aW5nIG9wdGlvbnMgZnJvbSB0aGUgZGlzY3Vzc2lvbnMgc28gZmFyOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T3B0aW9uIDE6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlYlJU QyBicm93c2VyIC0gTVVTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZWJSVEMgZGV2aWNlIC0gTVVTVDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5PdGhlciAoV2ViUlRDL25vbi1XZWJSVEMpIGVudGl0aWVzIC0gTUFZPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5PcHRpb24gMjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QW55IFdlYlJUQyBlbnRp dHkgZG9pbmcgZnVsbCBJQ0UgLSBNVVNUPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk90aGVyIChXZWJSVEMvbm9uLVdl YlJUQykgZW50aXRpZXMgLSBNQVk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBiZSBjbGVhciwg bXkgb3BpbmlvbiBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbnkgV2ViUlRDIGVudGl0eSBpbXBsZW1lbnRpbmcgZnVsbCBJQ0UgLSBNVVNU PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbnkg V2ViUlRDIGVudGl0eSAoc3VjaCBhcyBXZWJSVEMgZ2F0ZXdheSkgaW1wbGVtZW50aW5nIElDRS1s aXRlIC0tIE1VU1QgTk9UPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgd2F5IHdlIGFyZSBub3QgaW52ZW50aW5nIGVudGl0eSB0eXBlcyBh bmQgbm90IGRlZmluaW5nIGJlaGF2aW9ycyB3aGljaCB3b3VsZCBuZXZlciBiZSB1c2VkIChzdWNo IGFzIHNlbmRpbmcgY29uc2VudCBmcm9tIGFuIGVuZCBwb2ludCB3aGljaCB3b3VsZCBzZW5kIG5v IFNUVU4gcmVxdWVzdHMgb3RoZXJ3aXNlKS4gVGhpcyB3aWxsIGFsc28gcmVkdWNlIHRoZSBudW1i ZXIgb2YgaW50ZXJvcCBjYXNlcyBmcm9tDQogZm91ciAoZnVsbCBJQ0Ugd2l0aCBjb25zZW50LCBm dWxsIGlDRSB3aXRob3V0IGNvbnNlbnQsIElDRS1saXRlLCBJQ0UtbGl0ZSB3aXRoIGNvbnNlbnQp IHRvIG9ubHkgdHdvIChmdWxsIElDRSB3aXRoIGNvbnNlbnQsIElDRS1saXRlKS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7UmFqdSZndDs8L3NwYW4+PC9pPjwvYj4mbmJzcDs8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg cHJlZmVyIG9wdGlvbiAxLCBidXQgb2sgd2l0aCBvcHRpb24gMiBhcyB3ZWxsLiBJIGRpZCBub3Qg aGVhciBhbnkgb2JqZWN0aW9ucyB0byB0aGUgcmF0aW9uYWxlIEkgdm9pY2VkIGVhcmxpZXIgZm9y IG9wdGlvbiAxLCB3aGljaCBpcyBhdA0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzEyOTU3Lmh0bWwiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3ZWIvY3VycmVudC9tc2cxMjk1Ny5odG1sPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L1JhanUmZ3Q7PG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E52E4B4US70UWXCHMBA02z_-- From nobody Mon Aug 25 07:33:59 2014 Return-Path: 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 AF2781A8966 for ; Mon, 25 Aug 2014 07:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 jh0Lalbrfysr for ; Mon, 25 Aug 2014 07:33:56 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F661A8989 for ; Mon, 25 Aug 2014 07:33:54 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so12981213wgh.3 for ; Mon, 25 Aug 2014 07:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=OKPcsLVNax676+wlNji8gX0t8tfFZpIvn57/lWbM4+k=; b=zenfjMcp7wMhq5bPxBwWcfxczEPy0p/L1uR5dv/OdQH5Ap5TRpGrBiYITGA3O9ab+8 G9ENt1MpHPFeHjkVVtasEx7nTxx7SkZEIOE4oMC+uBwBGyvzfqZa3zz5w7kDEMbW/G+i CrrZCs8nTdhs8iGFegMbwcZdqlNnMUAm82NjdCvo5KQwTwBMokHT6XVqY/PxooT9G/q3 v+BTC3XEnEssAa2FUIVMsSqhhW+qYciL6lf5pk3S8hSLspQtBRqosiCOhloNzPdjrgF3 IwUcFh8CW/4EmsdeGIJltaSd726Z3RZY/HGTTO7c7NAeIO/0iouT8Hz0ekZXLdWuEQM0 7R7A== MIME-Version: 1.0 X-Received: by 10.180.198.232 with SMTP id jf8mr15358910wic.37.1408977232996; Mon, 25 Aug 2014 07:33:52 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Mon, 25 Aug 2014 07:33:52 -0700 (PDT) Date: Mon, 25 Aug 2014 20:03:52 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Roman Shpount Content-Type: multipart/alternative; boundary=047d7b6225ac782f1f0501751365 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/z8fc6EqwjAUWoJAwe1Mwf4vVEVM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:33:57 -0000 --047d7b6225ac782f1f0501751365 Content-Type: text/plain; charset=UTF-8 An ICE-lite entity by definition doesn't generate STUN requests which means it doesn't perform consent freshness as described in the draft. If it does, it is not a ICE-lite entity. You have only two types of entities to interop test with. I don't see any use of specifying a MUST NOT for ICE-lite. Muthu On Mon, Aug 25, 2014 at 6:13 PM, Roman Shpount wrote: > On Mon, Aug 25, 2014 at 6:55 AM, Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> wrote: > >> I thought a "SHOULD perform" is more appropriate for a WebRTC device as >> it doesn't implement the public API and might run a proprietary/native app >> running in a constrained environment and the overhead of performing the >> periodic consent might overweigh the benefits. However, I don't have an >> issue of making it a MUST -- at least no one has objected so far. I hear >> the following options from the discussions so far: >> >> Option 1: >> WebRTC browser - MUST >> WebRTC device - MUST >> Other (WebRTC/non-WebRTC) entities - MAY >> >> Option 2: >> Any WebRTC entity doing full ICE - MUST >> Other (WebRTC/non-WebRTC) entities - MAY >> >> >> > To be clear, my opinion is > > Any WebRTC entity implementing full ICE - MUST > Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST > NOT > > This way we are not inventing entity types and not defining behaviors > which would never be used (such as sending consent from an end point which > would send no STUN requests otherwise). This will also reduce the number of > interop cases from four (full ICE with consent, full iCE without consent, > ICE-lite, ICE-lite with consent) to only two (full ICE with consent, > ICE-lite). > _____________ > Roman Shpount > > --047d7b6225ac782f1f0501751365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
An ICE-lite entity by definition doesn&= #39;t generate STUN requests which means it doesn't perform consent fre= shness as described in the draft. If it does, it is not a ICE-lite entity. = You have only two types of entities to interop test with. I don't see a= ny use of specifying a MUST NOT for ICE-lite.

Muthu

On Mon, Aug 25, 2014 at 6:13 PM, Roman Shpou= nt <roman@telurix.com> wrote:
On Mon, Au= g 25, 2014 at 6:55 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
I thought a "SHOULD perform" is more appropriate for a WebRTC dev= ice as it doesn't implement the public API and might run a proprietary/= native app running in a constrained environment and the overhead of perform= ing the periodic consent might overweigh the benefits. However, I don't= have an issue of making it a MUST -- at least no one has objected so far. = I hear the following options from the discussions so far:

<= /div>
= Option 1:
WebRTC browser - MUST
WebRTC device - MUST
Other (WebRTC/non-WebRTC) entities - MAY

Option 2:
Any WebRTC entity doing full ICE - MUST
Other (WebRTC/non-WebRTC) entities - MAY
=C2=A0




This way we are not inventing entity types and not defi= ning behaviors which would never be used (such as sending consent from an e= nd point which would send no STUN requests otherwise). This will also reduc= e the number of interop cases from four (full ICE with consent, full iCE wi= thout consent, ICE-lite, ICE-lite with consent) to only two (full ICE with = consent, ICE-lite).
_____________
Roman Shpoun= t
=C2=A0

--047d7b6225ac782f1f0501751365-- From nobody Mon Aug 25 07:49:15 2014 Return-Path: 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 ACC331A8986 for ; Mon, 25 Aug 2014 07:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 zx-DSuhAFA6K for ; Mon, 25 Aug 2014 07:49:12 -0700 (PDT) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A6B1A8974 for ; Mon, 25 Aug 2014 07:49:11 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id f8so2653216wiw.12 for ; Mon, 25 Aug 2014 07:49:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MdHCll/nXsH8W5o5FhkyRK2RlXTn5S8PcQtIAbWh090=; b=NzeY3S5YSJHm4m4jhJoMbBBc095IZgMZoih9ieAeQlBW/aDexMLkSkCtUvC09jiKi8 zbVc5X3TzRoO4yGuSUVtN/21DmdEs+EVtPXCNZIrDej/GPeyCP85V4DjvpWAQVXKoyUe imn3DarIqpA5l+cGerWO4r7yDw4Y8CpePkOjWh1zAQW4huurYjFxW0xvBvDpEjIl8+uv c8Ibku8uRYT52aIOYVCnemMSkkpnBB+DnUDfhpxXUpWQReXwZDImuY3cs0vzpdDu08tW Q+uqBpYT5tL62vHopoqWtbVPRacJwmpcKHRld1Ss4Hw1ppKzbLVexFwtFGkPPYUlvvvn UJJQ== X-Gm-Message-State: ALoCoQltgChy4trnF6J4sy8LHH/SPgvhmrQbW0SFnbHm0nbnQ/NBRpFF8NQiC/y7dH1DSz2JKdIa X-Received: by 10.194.203.8 with SMTP id km8mr23601004wjc.51.1408978150588; Mon, 25 Aug 2014 07:49:10 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx.google.com with ESMTPSA id fy1sm1426589wic.6.2014.08.25.07.49.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 07:49:09 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2653156wiv.9 for ; Mon, 25 Aug 2014 07:49:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.38.84 with SMTP id e20mr15680287wik.43.1408978149118; Mon, 25 Aug 2014 07:49:09 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Mon, 25 Aug 2014 07:49:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Aug 2014 10:49:09 -0400 Message-ID: From: Roman Shpount To: Muthu Arul Mozhi Perumal Content-Type: multipart/alternative; boundary=e89a8f643366131c190501754a23 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4v3LW1_sC-cF8xhdidyB4Caeef8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:49:13 -0000 --e89a8f643366131c190501754a23 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 25, 2014 at 10:33 AM, Muthu Arul Mozhi Perumal < muthu.arul@gmail.com> wrote: > An ICE-lite entity by definition doesn't generate STUN requests which > means it doesn't perform consent freshness as described in the draft. If it > does, it is not a ICE-lite entity. You have only two types of entities to > interop test with. I don't see any use of specifying a MUST NOT for > ICE-lite. > > > This is exactly what I am saying. All full ICE end points for WebRTC must implement consent freshness. We should not specify consent freshness for ICE-lite (as it is not specified right now), and we should not define a special type of end points which will not send consent freshness requests just because they are ICE-lite (since they already cannot send it). _____________ Roman Shpount --e89a8f643366131c190501754a23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Aug 25, 2014 at 10:33 AM, Muthu Arul Mozhi Perumal <muthu.arul@= gmail.com> wrote:
An ICE-lite entity by definition doesn't generate STUN requests which m= eans it doesn't perform consent freshness as described in the draft. If= it does, it is not a ICE-lite entity. You have only two types of entities = to interop test with. I don't see any use of specifying a MUST NOT for = ICE-lite.

<= /div>
=

This is exactly what I am = saying. All full ICE end points for WebRTC must implement consent freshness= . We should not specify consent freshness for ICE-lite (as it is not specif= ied right now), and we should not define a special type of end points which= will not send consent freshness requests just because they are ICE-lite (s= ince they already cannot send it).
_____________
Roman Shpount
=C2=A0
--e89a8f643366131c190501754a23-- From nobody Mon Aug 25 07:52:17 2014 Return-Path: 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 4444E1A8999 for ; Mon, 25 Aug 2014 07:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 Kr3aRIQU9T1T for ; Mon, 25 Aug 2014 07:52:11 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4576B1A899A for ; Mon, 25 Aug 2014 07:52:11 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so13250817wgh.14 for ; Mon, 25 Aug 2014 07:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5qIGrgrVGDj/R6siIyxBtEBXgJ9IlH7jf45FiR3XWy0=; b=vjSOJKv9MD0KWQVzo7uLpueevteoe0hRMSBIYtt0FCGchc1cdK9cbpB++unUJ4yFbW i7qcLsLLy3UQ4sJ07poJ3kaVEehx+PIuyOZ7ZNVsCtXpvOW355dsyDI8LwHIGSSpxFUX M2ClqwiKxYwDn7YQ1ZZywNcl011leV/nk/06ZMiNWphWEyp7QoDx+pXH9AciL++Z9gr/ OFJKzD1EuTn3Y2fYkPf/95bXoqoRQyEdmjUbVYEyP5yRBI5N8kIRpAWloHnqFl+eYFW+ k6kLPBSUUd1yZ+QNfgrUvORVRVzUtzIkIrRod4sm7gvYF69r1flFQg0o6Uh4gF62suXN ilZQ== MIME-Version: 1.0 X-Received: by 10.180.93.104 with SMTP id ct8mr15725037wib.30.1408978329918; Mon, 25 Aug 2014 07:52:09 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Mon, 25 Aug 2014 07:52:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Aug 2014 20:22:09 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Roman Shpount Content-Type: multipart/alternative; boundary=f46d043c08ead9e32705017554ef Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9OSh0PkFWEI1k0t2zcDavzjdhf0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:52:14 -0000 --f46d043c08ead9e32705017554ef Content-Type: text/plain; charset=UTF-8 Agree. On Mon, Aug 25, 2014 at 8:19 PM, Roman Shpount wrote: > > On Mon, Aug 25, 2014 at 10:33 AM, Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> wrote: > >> An ICE-lite entity by definition doesn't generate STUN requests which >> means it doesn't perform consent freshness as described in the draft. If it >> does, it is not a ICE-lite entity. You have only two types of entities to >> interop test with. I don't see any use of specifying a MUST NOT for >> ICE-lite. >> >> >> > This is exactly what I am saying. All full ICE end points for WebRTC must > implement consent freshness. We should not specify consent freshness for > ICE-lite (as it is not specified right now), and we should not define a > special type of end points which will not send consent freshness requests > just because they are ICE-lite (since they already cannot send it). > _____________ > Roman Shpount > > --f46d043c08ead9e32705017554ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree.
=
On Mon, Aug 25, 2014 at 8:19 PM, Roman Shpou= nt <roman@telurix.com> wrote:
=
On Mon, Aug 25, 2014 at 10:3= 3 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wro= te:
An ICE-lite entity by definition doesn't generate STUN requests which m= eans it doesn't perform consent freshness as described in the draft. If= it does, it is not a ICE-lite entity. You have only two types of entities = to interop test with. I don't see any use of specifying a MUST NOT for = ICE-lite.

<= /div>
=

This is exactly what= I am saying. All full ICE end points for WebRTC must implement consent fre= shness. We should not specify consent freshness for ICE-lite (as it is not = specified right now), and we should not define a special type of end points= which will not send consent freshness requests just because they are ICE-l= ite (since they already cannot send it).
_____________
Roman = Shpount
=C2=A0

--f46d043c08ead9e32705017554ef-- From nobody Mon Aug 25 07:59:55 2014 Return-Path: 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 226681A8988 for ; Mon, 25 Aug 2014 07:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 Obn_vge9Jo0j for ; Mon, 25 Aug 2014 07:59:49 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3A11A90A6 for ; Mon, 25 Aug 2014 07:59:48 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so13061530wgh.2 for ; Mon, 25 Aug 2014 07:59:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vB2w9DWX5lwgETBQJDZ4/b6IP2M2R6V3Suy+Y9LhTtk=; b=RecNyzFfe6VzYDaBYx0+u74/ufYxH0g5iHRbnCOk66zN8bGPkKLM1niy5cOEgIMApP B80kEtdFVJQm2Hc2kgM4Cg5yBqKoul5ejFM6nA/Y18Gk+bUIFsBDcBiCzEVO9pBF6I41 L6wqW9OCYXWv4BsrDjgTd4BjDINuDRElR4W7TcT6Nl4xoHb1JZM57MYzQNXLru/u1kZR 6pQSPaCNyU3RmygESe4YLEoeP9u+UzqRoc1EOkYXVue8PpzpQLb1S5LTwPTvt4LonkRI YvZljMWgMiOCWoRp16hN1Ev9I/sloEBC09UHQT/u6Dr5U/DpthtE9BzspHtnfvJSCyMm KqvA== X-Gm-Message-State: ALoCoQnPgqkRMlGG/X+ewF/u4jPcsepxRtqtz/LZmtdrIamXGKY3IuH9r7AboFiA+HgdBIPAQUwr X-Received: by 10.180.24.35 with SMTP id r3mr15654869wif.71.1408978787710; Mon, 25 Aug 2014 07:59:47 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by mx.google.com with ESMTPSA id fk9sm1529427wic.4.2014.08.25.07.59.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 07:59:46 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so13381343wes.22 for ; Mon, 25 Aug 2014 07:59:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.74.42 with SMTP id q10mr16083140wiv.39.1408978786453; Mon, 25 Aug 2014 07:59:46 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Mon, 25 Aug 2014 07:59:46 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> Date: Mon, 25 Aug 2014 10:59:46 -0400 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=f46d043c80d610129b05017570c0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/2yTDbKkK0--1fBlUPLBzcYDxUiw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:59:53 -0000 --f46d043c80d610129b05017570c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 22, 2014 at 1:40 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > *A WebRTC-device could be a native app or in an embedded device where > there could be some limitations about memory, cpu, energy and/or bandwidt= h. > So, such a device could choose not to do consent freshness checks before > sending data. Imagine an embedded device (Internet-of-things) sends some > non real-time data (using webrtc data channel) every 30 secs; with consen= t > check it first has to send a STUN req for consent and wait for response > then send the data. In this case the consent checks add delay and overhea= d. > IMHO, for WebRTC-device allowing the flexibility of no consent is a good > idea; so a =E2=80=9CSHOULD=E2=80=9D is justified. But, I am ok to make co= nsent for > WebRTC-device a MUST too.* > > > First of all I do not believe this use case is something that was covered by WebRTC normal use cases and does not comply with the consent freshness draft (where messages need to be sent regularly regardless of data being sent). This would mean that consent freshness will not introduce additional delay for sending data, but it will introduce additional battery, memory, CPU, network and other resource usage. Second, there is a need to maintain the communication channel through the NAT routers which will require regular messages in both directions, Freshness requests serve this purpose well. Third, it is useful to know that remote party is still present and ready to receive data. Otherwise you need to rely on message timeouts which can be misleading. Finally, I am not sure if p2p webrtc data channel is the best way to implement internet of things data communications. Most likely you will need a more efficient protocol for such an app. Such protocol should not affect normal use cases for WebRTC. _____________ Roman Shpount --f46d043c80d610129b05017570c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 22, 2014 a= t 1:40 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alca= tel-lucent.com> wrote:

A WebRTC-device could be a native app or in an= embedded device where there could be some limitations about memory, cpu, e= nergy and/or bandwidth. So, such a device could choose not to do consent freshness checks before sending da= ta. Imagine an embedded device (Internet-of-things) sends some non real-tim= e data (using webrtc data channel) every 30 secs; with consent check it fir= st has to send a STUN req for consent and wait for response then send the data. In this case the consent checks = add delay and overhead. IMHO, for WebRTC-device allowing the flexibility of= no consent is a good idea; so a =E2=80=9CSHOULD=E2=80=9D is justified. But= , I am ok to make consent for WebRTC-device a MUST too.



First of all I do not believe this use case = is something that was covered by WebRTC normal use cases =C2=A0and does not= comply with the consent freshness draft (where messages need to be sent re= gularly regardless of data being sent). This would mean that consent freshn= ess will not introduce additional delay for sending data, but it will intro= duce additional battery, memory, CPU, network and other resource usage.

Second,=C2=A0=C2=A0there is a need to maintain the comm= unication channel through the NAT routers which will require regular messag= es in both directions, Freshness requests serve this purpose well.

Third, it is useful to know that remote party is still prese= nt and ready to receive data. Otherwise you need to rely on message timeout= s which can be misleading.

Finally, I am not = sure if p2p webrtc data channel is the best way to implement internet of th= ings data communications. Most likely you will need a more efficient protoc= ol for such an app. Such protocol should not affect normal use cases for We= bRTC.

_____________
Roman Shpount
=C2=A0
--f46d043c80d610129b05017570c0-- From nobody Mon Aug 25 08:09:06 2014 Return-Path: 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 BBE211A909A for ; Mon, 25 Aug 2014 08:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 iAW90_2KlUnw for ; Mon, 25 Aug 2014 08:08:57 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1A31A909B for ; Mon, 25 Aug 2014 08:08:33 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 646CF93011A1; Mon, 25 Aug 2014 15:08:30 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7PF8Unp008630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 11:08:32 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 25 Aug 2014 11:08:30 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Muthu Arul Mozhi Perumal , Roman Shpount Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPwHO5YIc/MFSTfk+VKNIJfUtwNpvhqnGA//++f1A= Date: Mon, 25 Aug 2014 15:08:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E52EB28US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/N2ZC4Xw7geHt9W03YUwfZSuZHi0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 15:09:00 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E52EB28US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SUNFIFJGQyA1MjQ1IHNheXMgSUNFLWxpdGUgY2xpZW50cyBkb27igJl0IGRvIGNhbmRpZGF0ZSBn YXRoZXJpbmcrY29ubmVjdGl2aXR5IGNoZWNrcywgaXQgZG9lcyBOT1QgZXhwbGljaXRseSB0YWxr cyBhYm91dCBOT1QgdXNpbmcgU1RVTiBmb3Igb3RoZXIgcHVycG9zZSBsaWtlIGNvbnNlbnQgZnJl c2huZXNzLg0KWWVzLCBjb25zZW50IGZyZXNobmVzcyB1c2VzIHRoZSBzYW1lIFNUVU4gbWVzc2Fn ZXMuIFRoYXQgc2hvdWxkIG5vdCBiZSBhIHJlYXNvbiB0byBleGNsdWRlIElDRS1saXRlIGNsaWVu dHMgZnJvbSBjb25zZW50IGZyZXNobmVzcyBjaGVja3MuDQoNCklDRS1saXRlIGVuZHBvaW50cyBo YXZlIHNhbWUgc2VjdXJpdHkgY29uY2VybnMgYXMgSUNFLWZ1bGwgZW5kcG9pbnRzLiBJTUhPLCBp bmRlcGVuZGVudCBvZiBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3MsIHRoZSBkcmFmdCBzaG91bGQg YWxsb3cgSUNFLWxpdGUgY2xpZW50IHRvIGRvIGNvbnNlbnQgZnJlc2huZXNzLCB3aGljaCBtZWFu cyB0aGUgb3RoZXIgZW5kIChJQ0UtZnVsbCBvciBJQ0UtbGl0ZSkgc2hvdWxkIGFja25vd2xlZGdl IHRoZSBTVFVOIHJlcXVlc3RzIHNlbnQgYnkgSUNFLWxpdGUgY2xpZW50cy4gSSBiZWxpZXZlIHRo aXMgaXMgYWxyZWFkeSBzdXBwb3J0ZWQgYnkgQ2hyb21lIGFuZCBGaXJlZm94Lg0KDQpCUg0KUmFq dQ0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE11dGh1IEFydWwgTW96aGkgUGVydW1hbA0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjUs IDIwMTQgOTo1MiBBTQ0KVG86IFJvbWFuIFNocG91bnQNCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtcnRjd2ViLXN0 dW4tY29uc2VudC1mcmVzaG5lc3MNCg0KQWdyZWUuDQoNCk9uIE1vbiwgQXVnIDI1LCAyMDE0IGF0 IDg6MTkgUE0sIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpPbiBNb24sIEF1ZyAyNSwgMjAxNCBhdCAxMDozMyBBTSwg TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIDxtdXRodS5hcnVsQGdtYWlsLmNvbTxtYWlsdG86bXV0 aHUuYXJ1bEBnbWFpbC5jb20+PiB3cm90ZToNCkFuIElDRS1saXRlIGVudGl0eSBieSBkZWZpbml0 aW9uIGRvZXNuJ3QgZ2VuZXJhdGUgU1RVTiByZXF1ZXN0cyB3aGljaCBtZWFucyBpdCBkb2Vzbid0 IHBlcmZvcm0gY29uc2VudCBmcmVzaG5lc3MgYXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gSWYg aXQgZG9lcywgaXQgaXMgbm90IGEgSUNFLWxpdGUgZW50aXR5LiBZb3UgaGF2ZSBvbmx5IHR3byB0 eXBlcyBvZiBlbnRpdGllcyB0byBpbnRlcm9wIHRlc3Qgd2l0aC4gSSBkb24ndCBzZWUgYW55IHVz ZSBvZiBzcGVjaWZ5aW5nIGEgTVVTVCBOT1QgZm9yIElDRS1saXRlLg0KDQoNCg0KVGhpcyBpcyBl eGFjdGx5IHdoYXQgSSBhbSBzYXlpbmcuIEFsbCBmdWxsIElDRSBlbmQgcG9pbnRzIGZvciBXZWJS VEMgbXVzdCBpbXBsZW1lbnQgY29uc2VudCBmcmVzaG5lc3MuIFdlIHNob3VsZCBub3Qgc3BlY2lm eSBjb25zZW50IGZyZXNobmVzcyBmb3IgSUNFLWxpdGUgKGFzIGl0IGlzIG5vdCBzcGVjaWZpZWQg cmlnaHQgbm93KSwgYW5kIHdlIHNob3VsZCBub3QgZGVmaW5lIGEgc3BlY2lhbCB0eXBlIG9mIGVu ZCBwb2ludHMgd2hpY2ggd2lsbCBub3Qgc2VuZCBjb25zZW50IGZyZXNobmVzcyByZXF1ZXN0cyBq dXN0IGJlY2F1c2UgdGhleSBhcmUgSUNFLWxpdGUgKHNpbmNlIHRoZXkgYWxyZWFkeSBjYW5ub3Qg c2VuZCBpdCkuDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E52EB28US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SUNFIFJGQyA1MjQ1IHNheXMgSUNFLWxpdGUgY2xpZW50cyBkb27igJl0IGRvIGNhbmRp ZGF0ZSBnYXRoZXJpbmcmIzQzO2Nvbm5lY3Rpdml0eSBjaGVja3MsIGl0IGRvZXMgTk9UIGV4cGxp Y2l0bHkgdGFsa3MgYWJvdXQgTk9UIHVzaW5nIFNUVU4gZm9yIG90aGVyIHB1cnBvc2UgbGlrZQ0K IGNvbnNlbnQgZnJlc2huZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIGNv bnNlbnQgZnJlc2huZXNzIHVzZXMgdGhlIHNhbWUgU1RVTiBtZXNzYWdlcy4gVGhhdCBzaG91bGQg bm90IGJlIGEgcmVhc29uIHRvIGV4Y2x1ZGUgSUNFLWxpdGUgY2xpZW50cyBmcm9tIGNvbnNlbnQg ZnJlc2huZXNzIGNoZWNrcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklDRS1saXRlIGVuZHBvaW50cyBoYXZlIHNhbWUg c2VjdXJpdHkgY29uY2VybnMgYXMgSUNFLWZ1bGwgZW5kcG9pbnRzLiBJTUhPLCBpbmRlcGVuZGVu dCBvZiBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3MsIHRoZSBkcmFmdCBzaG91bGQgYWxsb3cgSUNF LWxpdGUgY2xpZW50DQogdG8gZG8gY29uc2VudCBmcmVzaG5lc3MsIHdoaWNoIG1lYW5zIHRoZSBv dGhlciBlbmQgKElDRS1mdWxsIG9yIElDRS1saXRlKSBzaG91bGQgYWNrbm93bGVkZ2UgdGhlIFNU VU4gcmVxdWVzdHMgc2VudCBieSBJQ0UtbGl0ZSBjbGllbnRzLiBJIGJlbGlldmUgdGhpcyBpcyBh bHJlYWR5IHN1cHBvcnRlZCBieSBDaHJvbWUgYW5kIEZpcmVmb3guPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMjUsIDIwMTQgOTo1MiBBTTxicj4NCjxiPlRvOjwvYj4g Um9tYW4gU2hwb3VudDxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtcnRjd2Vi LXN0dW4tY29uc2VudC1mcmVzaG5lc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZ3JlZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyAyNSwg MjAxNCBhdCA4OjE5IFBNLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gTW9uLCBBdWcgMjUsIDIwMTQgYXQgMTA6MzMgQU0sIE11dGh1IEFydWwgTW96aGkgUGVydW1h bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bXV0aHUuYXJ1bEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFuIElDRS1saXRlIGVu dGl0eSBieSBkZWZpbml0aW9uIGRvZXNuJ3QgZ2VuZXJhdGUgU1RVTiByZXF1ZXN0cyB3aGljaCBt ZWFucyBpdCBkb2Vzbid0IHBlcmZvcm0gY29uc2VudCBmcmVzaG5lc3MgYXMgZGVzY3JpYmVkIGlu IHRoZSBkcmFmdC4gSWYgaXQgZG9lcywgaXQgaXMgbm90IGEgSUNFLWxpdGUgZW50aXR5LiBZb3Ug aGF2ZQ0KIG9ubHkgdHdvIHR5cGVzIG9mIGVudGl0aWVzIHRvIGludGVyb3AgdGVzdCB3aXRoLiBJ IGRvbid0IHNlZSBhbnkgdXNlIG9mIHNwZWNpZnlpbmcgYSBNVVNUIE5PVCBmb3IgSUNFLWxpdGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGlzIGV4YWN0bHkgd2hhdCBJIGFtIHNheWluZy4gQWxsIGZ1bGwgSUNFIGVuZCBwb2lu dHMgZm9yIFdlYlJUQyBtdXN0IGltcGxlbWVudCBjb25zZW50IGZyZXNobmVzcy4gV2Ugc2hvdWxk IG5vdCBzcGVjaWZ5IGNvbnNlbnQgZnJlc2huZXNzIGZvciBJQ0UtbGl0ZSAoYXMgaXQgaXMgbm90 IHNwZWNpZmllZCByaWdodCBub3cpLCBhbmQgd2Ugc2hvdWxkIG5vdCBkZWZpbmUgYSBzcGVjaWFs IHR5cGUgb2YgZW5kDQogcG9pbnRzIHdoaWNoIHdpbGwgbm90IHNlbmQgY29uc2VudCBmcmVzaG5l c3MgcmVxdWVzdHMganVzdCBiZWNhdXNlIHRoZXkgYXJlIElDRS1saXRlIChzaW5jZSB0aGV5IGFs cmVhZHkgY2Fubm90IHNlbmQgaXQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5Sb21hbiBTaHBvdW50PC9zcGFuPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E52EB28US70UWXCHMBA02z_-- From nobody Mon Aug 25 09:13:36 2014 Return-Path: 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 21E6D1A02A3; Mon, 25 Aug 2014 09:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EyZsXVyfxo6T; Mon, 25 Aug 2014 09:13:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5940E1A02BB; Mon, 25 Aug 2014 09:02:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825160249.28001.93762.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 09:02:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HEeGhHPCO6M6HyO0adSD6wQQIus Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-17.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 16:13:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-17.txt Pages : 44 Date : 2014-08-25 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 25 09:30:14 2014 Return-Path: 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 EA7281A02D7 for ; Mon, 25 Aug 2014 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QOB1FHALibw9 for ; Mon, 25 Aug 2014 09:30:10 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9156B1A02E4 for ; Mon, 25 Aug 2014 09:15:37 -0700 (PDT) Received: from [130.209.247.112] (port=62809 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XLwve-0007pd-T2 for rtcweb@ietf.org; Mon, 25 Aug 2014 17:15:35 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <20140825160249.28001.93762.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 17:15:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B341283-9E8C-4C6A-A13E-E5391508DE66@csperkins.org> References: <20140825160249.28001.93762.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fsibequfXNkmvR0yLwt5JDrR3qw Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-17.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 16:30:12 -0000 As discussed last week, this version changes =93RTCP is a fundamental = and integral part of RTP, and MUST be implemented in all WebRTC = applications=94 to =93=85MUST be implemented and used=85=94 in Section = 4.1. There are no other technical changes. Colin On 25 Aug 2014, at 17:02, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : Web Real-Time Communication (WebRTC): Media = Transport and Use of RTP > Authors : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-17.txt > Pages : 44 > Date : 2014-08-25 >=20 > Abstract: > The Web Real-Time Communication (WebRTC) framework provides support > for direct interactive rich communication using audio, video, text, > collaboration, games, etc. between two peers' web-browsers. This > memo describes the media transport aspects of the WebRTC framework. > It specifies how the Real-time Transport Protocol (RTP) is used in > the WebRTC context, and gives requirements for which RTP features, > profiles, and extensions need to be supported. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-17 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-17 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --=20 Colin Perkins http://csperkins.org/ From nobody Mon Aug 25 09:51:51 2014 Return-Path: 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 5744B1A0023 for ; Mon, 25 Aug 2014 09:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 S35dlRl0AiHh for ; Mon, 25 Aug 2014 09:51:46 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9791A003B for ; Mon, 25 Aug 2014 09:51:45 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2840659wiv.15 for ; Mon, 25 Aug 2014 09:51:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZLXQa7o3Bumur6LO6kKySUfpQZjYMcqwR4BwMctX+rg=; b=HyumtBZN0gcjyeb5anib9KxAq8alnNvf3MF6JEgdnBjXfUn2ukc3+GPJagSUbruWN6 xLB6ovpvqAz03FCJW7RbuLtnGsdnGVIbvEckOq2wJu/TC9J/P+50w/aOHI6YrtNlx+yW d4thiqaU/hOzRZOtD/ZvhnOa+uuR7alm8dxoF7Klu6fJmAiNXl4ISci9j1Ym+Vw0Kq11 kLzme3IBGJH4wNpK+BRtHQAONLOE+1iEcT89ArO/cZkasq/Fh7X0f0EqxxQEG6/1bUuK bcSLkJSZmcv0HzV9XkUNJKGrN6Xs04i9ewSOn+6FpPvlwlhYQQNpOtGsHJKp4cya2Ny+ OL6Q== X-Gm-Message-State: ALoCoQnUzEZRzCHIlCrchKOig9ztZaDZGBGT8BuFTntTSxp96Ch+l+JyS89iE4vwPKwPGWPo/ZIX X-Received: by 10.180.87.161 with SMTP id az1mr5381007wib.13.1408985504418; Mon, 25 Aug 2014 09:51:44 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx.google.com with ESMTPSA id cy9sm2314077wib.18.2014.08.25.09.51.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 09:51:42 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so13264468wgh.33 for ; Mon, 25 Aug 2014 09:51:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.161.231 with SMTP id xv7mr10925653wjb.78.1408985502584; Mon, 25 Aug 2014 09:51:42 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Mon, 25 Aug 2014 09:51:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Aug 2014 12:51:42 -0400 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=089e01493c5460189e0501770071 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/NSuNHZB8lYOnsBIXSmXljEmwVY8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 16:51:48 -0000 --089e01493c5460189e0501770071 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > ICE RFC 5245 says ICE-lite clients don=E2=80=99t do candidate > gathering+connectivity checks, it does NOT explicitly talks about NOT usi= ng > STUN for other purpose like consent freshness. > > Yes, consent freshness uses the same STUN messages. That should not be a > reason to exclude ICE-lite clients from consent freshness checks. > > > > ICE-lite endpoints have same security concerns as ICE-full endpoints. > IMHO, independent of STUN connectivity checks, the draft should allow > ICE-lite client to do consent freshness, which means the other end > (ICE-full or ICE-lite) should acknowledge the STUN requests sent by > ICE-lite clients. I believe this is already supported by Chrome and Firef= ox. > > > If someone goes through the trouble of implementing sending STUN bind requests needed for consent freshness, why would not they implement full ICE? Incremental work (ie state machine) is not that great. Sending consent freshness or any other STUN requests is not prohibited by ICE-lite clients, but it is not defined anywhere either. Let's not define something which has no reason to exist. _____________ Roman Shpount --089e01493c5460189e0501770071 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 25, 2014 at 11:08 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

ICE RFC 5245 says ICE-lite clients don=E2=80= =99t do candidate gathering+connectivity checks, it does NOT explicitly tal= ks about NOT using STUN for other purpose like consent freshness.

Yes, consent freshness uses the same STUN me= ssages. That should not be a reason to exclude ICE-lite clients from consen= t freshness checks.

=C2=A0

ICE-lite endpoints have same security concer= ns as ICE-full endpoints. IMHO, independent of STUN connectivity checks, th= e draft should allow ICE-lite client to do consent freshness, which means the other end (ICE-full or ICE-lite) = should acknowledge the STUN requests sent by ICE-lite clients. I believe th= is is already supported by Chrome and Firefox.

=C2=A0

=C2=A0
If someone goes through the trouble of implement= ing sending STUN bind requests needed for consent freshness, why would not = they implement full ICE? Incremental work (ie state machine) is not that gr= eat.

Sending consent freshness or any other STUN requests is= not prohibited by ICE-lite clients, but it is not defined anywhere either.= Let's not define something which has no reason to exist.
_____________
Roman Shpount
=C2=A0
--089e01493c5460189e0501770071-- From nobody Mon Aug 25 10:08:50 2014 Return-Path: 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 2B7531A0030 for ; Mon, 25 Aug 2014 10:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 y8PBDIXI6cJt for ; Mon, 25 Aug 2014 10:08:42 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01021A0052 for ; Mon, 25 Aug 2014 10:08:25 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 8A22EC98314D2; Mon, 25 Aug 2014 17:08:22 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7PH8O8Z016866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 13:08:24 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 25 Aug 2014 13:08:24 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Roman Shpount Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPwITci/5CKoOiV024j3Ir7ToL8JvhiWMg Date: Mon, 25 Aug 2014 17:08:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E52F290US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/439uRfb7vko6eP_nrMZtPZoW2cs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:08:45 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E52F290US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6 IE1vbmRheSwgQXVndXN0IDI1LCAyMDE0IDExOjUyIEFNDQoNCk9uIE1vbiwgQXVnIDI1LCAyMDE0 IGF0IDExOjA4IEFNLCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIDxSYWp1Lk1ha2FyYWp1 QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5j b20+PiB3cm90ZToNCklDRSBSRkMgNTI0NSBzYXlzIElDRS1saXRlIGNsaWVudHMgZG9u4oCZdCBk byBjYW5kaWRhdGUgZ2F0aGVyaW5nK2Nvbm5lY3Rpdml0eSBjaGVja3MsIGl0IGRvZXMgTk9UIGV4 cGxpY2l0bHkgdGFsa3MgYWJvdXQgTk9UIHVzaW5nIFNUVU4gZm9yIG90aGVyIHB1cnBvc2UgbGlr ZSBjb25zZW50IGZyZXNobmVzcy4NClllcywgY29uc2VudCBmcmVzaG5lc3MgdXNlcyB0aGUgc2Ft ZSBTVFVOIG1lc3NhZ2VzLiBUaGF0IHNob3VsZCBub3QgYmUgYSByZWFzb24gdG8gZXhjbHVkZSBJ Q0UtbGl0ZSBjbGllbnRzIGZyb20gY29uc2VudCBmcmVzaG5lc3MgY2hlY2tzLg0KDQpJQ0UtbGl0 ZSBlbmRwb2ludHMgaGF2ZSBzYW1lIHNlY3VyaXR5IGNvbmNlcm5zIGFzIElDRS1mdWxsIGVuZHBv aW50cy4gSU1ITywgaW5kZXBlbmRlbnQgb2YgU1RVTiBjb25uZWN0aXZpdHkgY2hlY2tzLCB0aGUg ZHJhZnQgc2hvdWxkIGFsbG93IElDRS1saXRlIGNsaWVudCB0byBkbyBjb25zZW50IGZyZXNobmVz cywgd2hpY2ggbWVhbnMgdGhlIG90aGVyIGVuZCAoSUNFLWZ1bGwgb3IgSUNFLWxpdGUpIHNob3Vs ZCBhY2tub3dsZWRnZSB0aGUgU1RVTiByZXF1ZXN0cyBzZW50IGJ5IElDRS1saXRlIGNsaWVudHMu IEkgYmVsaWV2ZSB0aGlzIGlzIGFscmVhZHkgc3VwcG9ydGVkIGJ5IENocm9tZSBhbmQgRmlyZWZv eC4NCg0KSWYgc29tZW9uZSBnb2VzIHRocm91Z2ggdGhlIHRyb3VibGUgb2YgaW1wbGVtZW50aW5n IHNlbmRpbmcgU1RVTiBiaW5kIHJlcXVlc3RzIG5lZWRlZCBmb3IgY29uc2VudCBmcmVzaG5lc3Ms IHdoeSB3b3VsZCBub3QgdGhleSBpbXBsZW1lbnQgZnVsbCBJQ0U/IEluY3JlbWVudGFsIHdvcmsg KGllIHN0YXRlIG1hY2hpbmUpIGlzIG5vdCB0aGF0IGdyZWF0Lg0KPFJhanUyPg0KSU1PLCBJQ0Ug Z2F0aGVyaW5nLCBjb25uZWN0aXZpdHkgY2hlY2tzLCBwcmlvcml0aXphdGlvbiBldGMuIGlzIG11 Y2ggbW9yZSB3b3JrIHRoYW4gZG9pbmcganVzdCBjb25zZW50IGNoZWNrcy4NCklDRS1saXRlIGVu dGl0aWVzIChwbGVhc2Ugbm90ZSBnYXRld2F5cyBpbiBzcGVjaWZpYykgZG9u4oCZdCBpbXBsZW1l bnQgSUNFLWZ1bGwgYmVjYXVzZSB0aGV5IGNhbiBnZXQgYXdheSB3aXRoIElDRS1saXRlIGR1ZSB0 byBwcmVzZW5jZSBvZiBwdWJsaWMgaXAuIFdoeSBjb21wbGljYXRlIGFuIGltcGxlbWVudGF0aW9u IHVubmVjZXNzYXJpbHk/DQo8L1JhanUyPg0KDQpTZW5kaW5nIGNvbnNlbnQgZnJlc2huZXNzIG9y IGFueSBvdGhlciBTVFVOIHJlcXVlc3RzIGlzIG5vdCBwcm9oaWJpdGVkIGJ5IElDRS1saXRlIGNs aWVudHMsIGJ1dCBpdCBpcyBub3QgZGVmaW5lZCBhbnl3aGVyZSBlaXRoZXIuIExldCdzIG5vdCBk ZWZpbmUgc29tZXRoaW5nIHdoaWNoIGhhcyBubyByZWFzb24gdG8gZXhpc3QuDQo8UmFqdTI+DQpJ TUhPLCBjb25zZW50IGNoZWNrcyBmb3IgSUNFLWxpdGUgaGF2ZSBhIHNlY3VyaXR5IHJlYXNvbiB0 byBleGlzdDsgdGhlIHNhbWUgc2VjdXJpdHkgcmVhc29uIHdoeSBJQ0UtZnVsbCBjbGllbnRzIG5l ZWRlZCBpdC4gSXNu4oCZdCBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNz IHJpZ2h0IHBsYWNlIHRvIGRlZmluZSB0aGlzPw0KPC9SYWp1Mj4NCg0KQlINClJhanUNCl9fX19f X19fX19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E52F290US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSb21hbiBTaHBvdW50IFtt YWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1 c3QgMjUsIDIwMTQgMTE6NTIgQU08YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyAyNSwg MjAxNCBhdCAxMTowOCBBTSwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SUNFIFJGQyA1MjQ1IHNheXMgSUNFLWxp dGUgY2xpZW50cyBkb27igJl0IGRvIGNhbmRpZGF0ZSBnYXRoZXJpbmcmIzQzO2Nvbm5lY3Rpdml0 eSBjaGVja3MsIGl0IGRvZXMgTk9UDQogZXhwbGljaXRseSB0YWxrcyBhYm91dCBOT1QgdXNpbmcg U1RVTiBmb3Igb3RoZXIgcHVycG9zZSBsaWtlIGNvbnNlbnQgZnJlc2huZXNzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgY29uc2VudCBmcmVzaG5lc3MgdXNlcyB0aGUgc2Ft ZSBTVFVOIG1lc3NhZ2VzLiBUaGF0IHNob3VsZCBub3QgYmUgYSByZWFzb24gdG8gZXhjbHVkZSBJ Q0UtbGl0ZQ0KIGNsaWVudHMgZnJvbSBjb25zZW50IGZyZXNobmVzcyBjaGVja3MuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SUNFLWxpdGUgZW5kcG9pbnRzIGhhdmUgc2FtZSBzZWN1cml0eSBjb25jZXJucyBhcyBJ Q0UtZnVsbCBlbmRwb2ludHMuIElNSE8sIGluZGVwZW5kZW50IG9mIFNUVU4gY29ubmVjdGl2aXR5 DQogY2hlY2tzLCB0aGUgZHJhZnQgc2hvdWxkIGFsbG93IElDRS1saXRlIGNsaWVudCB0byBkbyBj b25zZW50IGZyZXNobmVzcywgd2hpY2ggbWVhbnMgdGhlIG90aGVyIGVuZCAoSUNFLWZ1bGwgb3Ig SUNFLWxpdGUpIHNob3VsZCBhY2tub3dsZWRnZSB0aGUgU1RVTiByZXF1ZXN0cyBzZW50IGJ5IElD RS1saXRlIGNsaWVudHMuIEkgYmVsaWV2ZSB0aGlzIGlzIGFscmVhZHkgc3VwcG9ydGVkIGJ5IENo cm9tZSBhbmQgRmlyZWZveC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgc29tZW9uZSBnb2VzIHRocm91Z2ggdGhl IHRyb3VibGUgb2YgaW1wbGVtZW50aW5nIHNlbmRpbmcgU1RVTiBiaW5kIHJlcXVlc3RzIG5lZWRl ZCBmb3IgY29uc2VudCBmcmVzaG5lc3MsIHdoeSB3b3VsZCBub3QgdGhleSBpbXBsZW1lbnQgZnVs bCBJQ0U/IEluY3JlbWVudGFsIHdvcmsgKGllIHN0YXRlIG1hY2hpbmUpIGlzIG5vdCB0aGF0IGdy ZWF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtSYWp1 MiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTU8sIElD RSBnYXRoZXJpbmcsIGNvbm5lY3Rpdml0eSBjaGVja3MsIHByaW9yaXRpemF0aW9uIGV0Yy4gaXMg bXVjaCBtb3JlIHdvcmsgdGhhbiBkb2luZyBqdXN0IGNvbnNlbnQgY2hlY2tzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklDRS1saXRlIGVudGl0aWVzIChwbGVh c2Ugbm90ZSBnYXRld2F5cyBpbiBzcGVjaWZpYykgZG9u4oCZdCBpbXBsZW1lbnQgSUNFLWZ1bGwg YmVjYXVzZSB0aGV5IGNhbiBnZXQgYXdheSB3aXRoIElDRS1saXRlIGR1ZSB0byBwcmVzZW5jZSBv ZiBwdWJsaWMgaXAuIFdoeQ0KIGNvbXBsaWNhdGUgYW4gaW1wbGVtZW50YXRpb24gdW5uZWNlc3Nh cmlseT88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7L1Jh anUyJmd0Ozwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl bmRpbmcgY29uc2VudCBmcmVzaG5lc3Mgb3IgYW55IG90aGVyIFNUVU4gcmVxdWVzdHMgaXMgbm90 IHByb2hpYml0ZWQgYnkgSUNFLWxpdGUgY2xpZW50cywgYnV0IGl0IGlzIG5vdCBkZWZpbmVkIGFu eXdoZXJlIGVpdGhlci4gTGV0J3Mgbm90IGRlZmluZSBzb21ldGhpbmcgd2hpY2ggaGFzIG5vIHJl YXNvbiB0byBleGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7UmFqdTImZ3Q7 PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU1ITywgY29uc2Vu dCBjaGVja3MgZm9yIElDRS1saXRlIGhhdmUgYSBzZWN1cml0eSByZWFzb24gdG8gZXhpc3Q7IHRo ZSBzYW1lIHNlY3VyaXR5IHJlYXNvbiB3aHkgSUNFLWZ1bGwgY2xpZW50cyBuZWVkZWQgaXQuIElz buKAmXQgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcw0KIHJpZ2h0IHBs YWNlIHRvIGRlZmluZSB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZsdDsvUmFqdTImZ3Q7PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PC9z cGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E52F290US70UWXCHMBA02z_-- From nobody Mon Aug 25 10:16:14 2014 Return-Path: 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 A35901A010A for ; Mon, 25 Aug 2014 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 sr8rbhXh2D2N for ; Mon, 25 Aug 2014 10:16:01 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353B31A0103 for ; Mon, 25 Aug 2014 10:15:52 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pn19so13358190lab.24 for ; Mon, 25 Aug 2014 10:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VKqN6nCIcuaiInZxLo5F0N2SJZ8Z5OEyc+HG6Y29l/s=; b=BXUegemxhiWCFmYbsrrllhEwHVohnW16lMze1kAVkp6BxJlhp0/bmWhXAe8W5YAH7x L7kapA2Gls+/pG/T2MvBc8M/IwrEqgl0CnWl5M4R1EHc3c2yKev6Z+G3xkwhFxBkCBmo QS/zoTFwoq41OSNcwYRDX/4hHX6HaT4+l8AJ16zvrhFDyUW84pB2ClkkR82X9tqXMI8/ SNGqZASvZ8+oEvKF6oe6FB1aHHVykDiY+VxJD02iE+8MdvnWZnT/4JRyh8JksGroTpQl jCNpYKlaVKdJ2rPGV63MIy/nCMKdTSBYCSpM6yuaUhxcEftOhlSM2e8/kuz2PNom3p9U Gxvg== MIME-Version: 1.0 X-Received: by 10.152.163.199 with SMTP id yk7mr4348840lab.85.1408986950438; Mon, 25 Aug 2014 10:15:50 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Mon, 25 Aug 2014 10:15:50 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Mon, 25 Aug 2014 10:15:50 -0700 Message-ID: From: Martin Thomson To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9ZlgfAwG39IgNRGLXrGHyMJnNeU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:16:03 -0000 On 25 August 2014 05:43, Roman Shpount wrote: > Any WebRTC entity implementing full ICE - MUST > Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST NOT Let's try this instead: Any WebRTC entity MUST implement full ICE Any entity performing full ICE MUST implement consent Done. From nobody Mon Aug 25 10:55:56 2014 Return-Path: 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 290FB1A026F for ; Mon, 25 Aug 2014 10:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 rT3E72Dz04d3 for ; Mon, 25 Aug 2014 10:55:54 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89A81A0292 for ; Mon, 25 Aug 2014 10:54:19 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2931046wiv.3 for ; Mon, 25 Aug 2014 10:54:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Igrod8r+FO9vEtyLnlSBgxdJLMAl2Mq+r1eRuEQTiq8=; b=LBo0jQPbmbG3yF1Wo6nFm4KeWoTSIZwCs2H08C1wxbKzHFbC4geyXBQRaWlr0GZBP0 4B75y5rILhWHSwYPD/3YjcoPSGypAffP+wksWgJdw1aDT0t4/8tlRttromqLTieojxFO 9mP4uiYaaUdEynnJoEPS4Q5f2VQeZ8rFgDDZYishcH0ctz5XxCpsh/QEhuVrtSGDPxFd 7RiNLs9rFCGSFw7v7dsB6h1yL1pS/V9X6we2q5g2hr8Z+H5Uihb8fGj3+4x3T71Vdg72 SXKbtDRQQs8ZYcaK6AwjyasLkUIv9m1+HXrOYkM72foCS9gu9AFxS16hKUn6OX6M49UZ Irmg== X-Gm-Message-State: ALoCoQk0X4unXO9y80MyHLt5+Qc7Ok5ge27aCJFu2oSIQ3VCdiwaG/wY49zHAFyCOBYzMtM5jZ60 X-Received: by 10.194.103.41 with SMTP id ft9mr10439379wjb.93.1408989258300; Mon, 25 Aug 2014 10:54:18 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx.google.com with ESMTPSA id ka3sm1374647wjc.3.2014.08.25.10.54.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 10:54:17 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so13336154wgh.33 for ; Mon, 25 Aug 2014 10:54:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.161.231 with SMTP id xv7mr11268696wjb.78.1408989257145; Mon, 25 Aug 2014 10:54:17 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Mon, 25 Aug 2014 10:54:17 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Mon, 25 Aug 2014 13:54:17 -0400 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01493c542a27d7050177e047 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/n__8Z5ceXBCknHtUOq_J4FH7JQE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:55:55 -0000 --089e01493c542a27d7050177e047 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 25, 2014 at 1:15 PM, Martin Thomson wrote: > Let's try this instead: > > Any WebRTC entity MUST implement full ICE > > Any entity performing full ICE MUST implement consent > > Done. > We are still going to get a fair number of WebRTC gateways that implement ICE-lite who will disagree. Unless this group will outlaw ICE-lite the way it did SDES-SRTP (for the very similar security reasons), the caveat for ICE-lite should stay. _____________ Roman Shpount --089e01493c542a27d7050177e047 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 25, 2014 at 1:15 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
Let's try this instead:

Any WebRTC entity MUST implement full ICE

Any entity performing full ICE MUST implement consent

Done.
=C2=A0
We are still going to get= a fair number of WebRTC gateways that implement ICE-lite who will disagree= . Unless this group will outlaw ICE-lite the way it did SDES-SRTP (for the = very similar security reasons), the caveat for ICE-lite should stay.
_____________
Roman Shpount

--089e01493c542a27d7050177e047-- From nobody Mon Aug 25 11:01:49 2014 Return-Path: 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 99CBA1A01DC for ; Mon, 25 Aug 2014 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 9-zPfSrs1Xz8 for ; Mon, 25 Aug 2014 11:01:43 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BB61A01AF for ; Mon, 25 Aug 2014 11:01:12 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 2EBC6C56364CB; Mon, 25 Aug 2014 18:01:07 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s7PI1A7G007953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 14:01:10 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 25 Aug 2014 14:01:10 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Roman Shpount , Martin Thomson Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPvCyeYIc/MFSTfk+VKNIJfUtwNpvbPhKAgAABDwCAABPQgIAApK+AgACJRYCAAEiyvoAASoGAgASEIQOAAE2pgP//vb5Q Date: Mon, 25 Aug 2014 18:01:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E52F5F0US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hfeZRhluSDN-eksXefBghlpf6aY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:01:46 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E52F5F0US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgd2l0aCBSb21hbi4NCkkgZG9u4oCZdCB0aGluayBvdXRsYXdpbmcgSUNFLWxpdGUgaXMg YWNjZXB0YWJsZS4NCkJ0dywgd2h5IGFyZSB3ZSBjaGFuZ2luZyB0aGUgdG9waWMgZnJvbSBJQ0Ut bGl0ZeKAmXMgc3VwcG9ydCBvZiBjb25zZW50LWZyZXNobmVzcyB0byBXZWJSVEMgc3VwcG9ydCBv ZiBJQ0UtbGl0ZT8hIOKYug0KDQpCUg0KUmFqdQ0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbWFuIFNocG91bnQNClNlbnQ6IE1v bmRheSwgQXVndXN0IDI1LCAyMDE0IDEyOjU0IFBNDQpUbzogTWFydGluIFRob21zb24NCkNjOiBy dGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBXRyBMYXN0IENhbGwgZm9yIGRy YWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MNCg0KT24gTW9uLCBBdWcgMjUs IDIwMTQgYXQgMToxNSBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpMZXQncyB0cnkgdGhp cyBpbnN0ZWFkOg0KDQpBbnkgV2ViUlRDIGVudGl0eSBNVVNUIGltcGxlbWVudCBmdWxsIElDRQ0K DQpBbnkgZW50aXR5IHBlcmZvcm1pbmcgZnVsbCBJQ0UgTVVTVCBpbXBsZW1lbnQgY29uc2VudA0K DQpEb25lLg0KDQpXZSBhcmUgc3RpbGwgZ29pbmcgdG8gZ2V0IGEgZmFpciBudW1iZXIgb2YgV2Vi UlRDIGdhdGV3YXlzIHRoYXQgaW1wbGVtZW50IElDRS1saXRlIHdobyB3aWxsIGRpc2FncmVlLiBV bmxlc3MgdGhpcyBncm91cCB3aWxsIG91dGxhdyBJQ0UtbGl0ZSB0aGUgd2F5IGl0IGRpZCBTREVT LVNSVFAgKGZvciB0aGUgdmVyeSBzaW1pbGFyIHNlY3VyaXR5IHJlYXNvbnMpLCB0aGUgY2F2ZWF0 IGZvciBJQ0UtbGl0ZSBzaG91bGQgc3RheS4NCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQN Cg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E52F5F0US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFncmVlIHdpdGggUm9tYW4uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBvdXRsYXdpbmcgSUNF LWxpdGUgaXMgYWNjZXB0YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnR3LCB3 aHkgYXJlIHdlIGNoYW5naW5nIHRoZSB0b3BpYyBmcm9tIElDRS1saXRl4oCZcyBzdXBwb3J0IG9m IGNvbnNlbnQtZnJlc2huZXNzIHRvIFdlYlJUQyBzdXBwb3J0IG9mIElDRS1saXRlPyENCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5CUjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRv OnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb21hbiBTaHBv dW50PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDI1LCAyMDE0IDEyOjU0IFBNPGJy Pg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNvbjxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXRyBMYXN0IENhbGwgZm9yIGRy YWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3M8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24s IEF1ZyAyNSwgMjAxNCBhdCAxOjE1IFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkxldCdzIHRyeSB0aGlzIGluc3RlYWQ6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkFueSBXZWJSVEMgZW50aXR5IE1VU1Qg aW1wbGVtZW50IGZ1bGwgSUNFPGJyPg0KPGJyPg0KQW55IGVudGl0eSBwZXJmb3JtaW5nIGZ1bGwg SUNFIE1VU1QgaW1wbGVtZW50IGNvbnNlbnQ8YnI+DQo8YnI+DQpEb25lLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUgc3RpbGwgZ29p bmcgdG8gZ2V0IGEgZmFpciBudW1iZXIgb2YgV2ViUlRDIGdhdGV3YXlzIHRoYXQgaW1wbGVtZW50 IElDRS1saXRlIHdobyB3aWxsIGRpc2FncmVlLiBVbmxlc3MgdGhpcyBncm91cCB3aWxsIG91dGxh dyBJQ0UtbGl0ZSB0aGUgd2F5IGl0IGRpZCBTREVTLVNSVFAgKGZvciB0aGUgdmVyeSBzaW1pbGFy IHNlY3VyaXR5IHJlYXNvbnMpLCB0aGUgY2F2ZWF0IGZvciBJQ0UtbGl0ZSBzaG91bGQNCiBzdGF5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f X19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E52F5F0US70UWXCHMBA02z_-- From nobody Mon Aug 25 11:20:16 2014 Return-Path: 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 695941A020A for ; Mon, 25 Aug 2014 11:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 kxrJqSuhFrYk for ; Mon, 25 Aug 2014 11:20:08 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07221A01EB for ; Mon, 25 Aug 2014 11:20:07 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so2997111wiv.1 for ; Mon, 25 Aug 2014 11:20:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TW1kGXohG0mUB0n2u9INt0YaZ1YQ/kizuqB+DipGGAI=; b=BexiutoF6oo/nA/1aTgPafLIZq9MdN9MxOi4AyHHw+JpzA9DBvJffpLRRlYDQ8267F Bihqk6weIaO3QX6HBgE2CyaRJHezvFhg2dUXnx+JwAzzDIgeLEYqGBbPJNAS9L4ioeqp jmMg2uoMObF3zuZjff1Zfc/wkxyq65bpZOXV2MCqk8cIQ4srwFVsXc/gPH3bMYoDuPeg BBxYwnWlIDnlpm3HNAwfAYSVC2en3Nx3nwXke+PvKzI+wXUW8a1laj2gfaWUAYirzdXZ 968NJ+5ou27KCA5DAQTUID5nK2UJNnexGLTqRolHHGtWjrkBVWvtgTOtQC52S/E44qK8 hCNA== X-Gm-Message-State: ALoCoQm5wTRCLDpN1ws6lErsFj+l8Bj7+oe2jEFLl29Cf55EqDlwAnLhsU8eQVC3YJkbwGR5nMyt X-Received: by 10.194.59.42 with SMTP id w10mr24628858wjq.15.1408990806306; Mon, 25 Aug 2014 11:20:06 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx.google.com with ESMTPSA id u10sm3170559wix.2.2014.08.25.11.20.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 11:20:05 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so2963889wiv.9 for ; Mon, 25 Aug 2014 11:20:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.161.231 with SMTP id xv7mr11413168wjb.78.1408990805283; Mon, 25 Aug 2014 11:20:05 -0700 (PDT) Received: by 10.216.20.7 with HTTP; Mon, 25 Aug 2014 11:20:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Aug 2014 14:20:05 -0400 Message-ID: From: Roman Shpount To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=089e01493c5470da100501783c13 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lcCNYwj6vdc12v2MOuDxWrfSVNs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:20:10 -0000 --089e01493c5470da100501783c13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 1:08 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > *IMO, ICE gathering, connectivity checks, prioritization etc. is much > more work than doing just consent checks.* > > *ICE-lite entities (please note gateways in specific) don=E2=80=99t imple= ment > ICE-full because they can get away with ICE-lite due to presence of publi= c > ip. Why complicate an implementation unnecessarily?* > > If the end-point is located on a public IP, ICE gathering and prioritization are trivial. The benefits of aggressive nomination, which is present in full ICE, on the other hand, are quite significant. ICE-full should be recommended anyway. > *IMHO, consent checks for ICE-lite have a security reason to exist; the > same security reason why ICE-full clients needed it. Isn=E2=80=99t > draft-ietf-rtcweb-stun-consent-freshness right place to define this?* > > > I would prefer no mongrel ICE end points to be defined since I would prefer never to test against them. _____________ Roman Shpount --089e01493c5470da100501783c13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 25, 2014 at 1:08 PM, Makaraju, Maridi Raju (Raju) <= Raju.Makaraju@alcatel-lucent.com> wrote:

IMO, ICE gathering, connectivity checks, prior= itization etc. is much more work than doing just consent checks.<= /u>

ICE-lite entities (please note gateway= s in specific) don=E2=80=99t implement ICE-full because they can get away w= ith ICE-lite due to presence of public ip. Why complicate an implementation unnecessarily?


If the end-point is located on a public IP, ICE = gathering and prioritization are trivial. The benefits of aggressive nomina= tion, which is present in full ICE, on the other hand, are quite significan= t. ICE-full should be recommended anyway.=C2=A0
=C2=A0

IMHO, consent checks for ICE-lite have a secur= ity reason to exist; the same security reason why ICE-full clients needed i= t. Isn=E2=80=99t draft-ietf-rtcweb-stun-consent-freshness right place to define this?


I would prefer no mongrel ICE end points to be defined sinc= e I would prefer never to test against them.
_____________
Roman Shpount
=C2=A0
--089e01493c5470da100501783c13-- From nobody Mon Aug 25 12:38:16 2014 Return-Path: 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 A17E81A02EB for ; Mon, 25 Aug 2014 12:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 N1Q8dtbai8RW for ; Mon, 25 Aug 2014 12:38:14 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2109B1A0262 for ; Mon, 25 Aug 2014 12:38:13 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id b17so13917891lan.11 for ; Mon, 25 Aug 2014 12:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7n2bXVDK/TWl/SRnvPP8JIug/F2bMLadJdsSNWyLXDg=; b=P0P+fKAne0VNIZqIIvxZBPpHyhp2TI194T6r7aKgYMdEE+evkDgq/nVElBQfHfTQRf ciYa+6wlfzXv+Rk9aDO57Et7hIGOni1T5Pnl23q2D6NEXsG/q9UGvH50Q6D4QOOF4xZB zSSe4ozJS42q1x0EwKzLB9mps+ulal0NpEEWHFQZRasxS4ayoyYpynY3Yp/7fyXuVf6Y oYwqkZ75YRqaRz//o5pfju7+BXmhbFn1lhnGU/NoOzXqAIXs1yyPXfOMxfbEQ/GkeQKO zwHDAjqIGfwULlJhKT5IA/OkCdsM2mKYw3Raj/zuLzYWDYIjgxVfqcfSJHGvo9umThGF VmWg== MIME-Version: 1.0 X-Received: by 10.152.7.212 with SMTP id l20mr23447024laa.7.1408995492169; Mon, 25 Aug 2014 12:38:12 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Mon, 25 Aug 2014 12:38:12 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Mon, 25 Aug 2014 12:38:12 -0700 Message-ID: From: Martin Thomson To: "Makaraju, Maridi Raju (Raju)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/RsuPovpm99_Wa5TqZo7pXv8YBz0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 19:38:15 -0000 On 25 August 2014 11:01, Makaraju, Maridi Raju (Raju) wrote: > I don=E2=80=99t think outlawing ICE-lite is acceptable. I've not ever suggested that. I'm only suggesting that ICE-lite =E2=88=89 WebRTC. (That's U+2209, btw). WebRTC devices might talk to non-WebRTC devices. Some of those might only do the minimal part of ICE that they can get away with. Still, I don't see any reason to change any text here. From nobody Mon Aug 25 14:30:22 2014 Return-Path: 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 28BFC1A039D for ; Mon, 25 Aug 2014 14:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_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 wECDB5gHfK-N for ; Mon, 25 Aug 2014 14:30:19 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998CB1A039A for ; Mon, 25 Aug 2014 14:30:18 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s7PLUGvo004684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Aug 2014 21:30:16 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s7PLUFsq012676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 23:30:15 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 Aug 2014 23:30:15 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.128]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 23:30:15 +0200 From: "Rauschenbach, Uwe (NSN - DE/Munich)" To: ext Martin Thomson , Roman Shpount Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPwFMXfQnqI/5MoEi+nAhfY9/EypvhIi6AgABMFACAAGib3A== Date: Mon, 25 Aug 2014 21:30:14 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF819485063@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF819485063DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4500 X-purgate-ID: 151667::1409002216-0000061C-4C8F5F5F/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-rIRgUWOjTrsegPc0qjwp3gRa7M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 21:30:21 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF819485063DEMUMBX005nsnin_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable I am not sure whether the -consent-freshness draft is the right place to re= quire conformance to full ICE in order for something to be called a WebRTC = endpoint. There are other drafts like -overview or -transport for this. The= -consent-freshness draft should only make the link between implemented ICE= flavor and implications for consent freshness support. I therefore prefer Roman's proposal, but I am open to relaxing the MUST NOT= . Kind regards, Uwe ________________________________ Von: ext Martin Thomson Gesendet: =FD25.=FD08.=FD2014 19:16 An: Roman Shpount Cc: rtcweb@ietf.org Betreff: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-fresh= ness On 25 August 2014 05:43, Roman Shpount wrote: > Any WebRTC entity implementing full ICE - MUST > Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST = NOT Let's try this instead: Any WebRTC entity MUST implement full ICE Any entity performing full ICE MUST implement consent Done. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_56C2F665D49E0341B9DF5938005ACDF819485063DEMUMBX005nsnin_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
I am not sure= whether the -consent-freshness draft is the right place to require conform= ance to full ICE in order for something to be called a WebRTC endpoint. The= re are other drafts like -overview or -transport for this. The -consent-freshness draft should only make the = link between implemented ICE flavor and implications for consent freshness = support.

I therefore prefer Roman's proposal, but I am open to relaxing the MUST NOT= .

Kind regards,
Uwe
Von: ext Martin Thomson
Gesendet: =FD25= .=FD08.=FD2014 19:16
An: Roman Shpount
Cc: rtcweb@ietf.org
Betreff: Re: [= rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness
On 25 August 2014 05:43, Roman Shpount <roman@t= elurix.com> wrote:
> Any WebRTC entity implementing full ICE - MUST
> Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MU= ST NOT

Let's try this instead:

Any WebRTC entity MUST implement full ICE

Any entity performing full ICE MUST implement consent

Done.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_56C2F665D49E0341B9DF5938005ACDF819485063DEMUMBX005nsnin_-- From nobody Mon Aug 25 21:14:58 2014 Return-Path: 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 0FF381A0709 for ; Mon, 25 Aug 2014 21:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 B_WZSrLQloe7 for ; Mon, 25 Aug 2014 21:14:53 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967A21A06D3 for ; Mon, 25 Aug 2014 21:14:52 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so13843703wgh.8 for ; Mon, 25 Aug 2014 21:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=44T+3hins2xEMXSoBZv8X8U+Y6mR03uCoCCJ4dYHWLI=; b=DwFgjiFQylxYWfnHk1j2I26dWCfsoWsNgaklkdZd60doPsuEAxi9OoJseDRx1yWB90 /89K+iWfmeCBrmBy3Ye+IHncDAdO9Dof2OaGJeFR4CEgZmNeXDoDucGABo4El6HVqudT +gXSwsS1sy5Et+AX63X+/KcEXrR6uhG9JTt7YjtOGR/r+WUquioMdYCi7ueu6qUWmxYV 85VY092Xn33SUbw+aia9SWU1IJbUlFJLiRr/qR7xkz3bgTqcsHehTXPW3a1O1QdcJsjL RJ8fwOhFgKuSvMBeHacuVavrAZypGi/yyyWurRFQPFzBpYcjJGI6I5DuIOcQ/T4YECUT STsg== MIME-Version: 1.0 X-Received: by 10.180.184.20 with SMTP id eq20mr18873265wic.37.1409026491039; Mon, 25 Aug 2014 21:14:51 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Mon, 25 Aug 2014 21:14:50 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Tue, 26 Aug 2014 09:44:50 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c3536a7a46380501808b02 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/bcKWVg4Z9l2D3nRXH_T0HKLYOn0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 04:14:55 -0000 --001a11c3536a7a46380501808b02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 25, 2014 at 10:45 PM, Martin Thomson wrote: > On 25 August 2014 05:43, Roman Shpount wrote: > > Any WebRTC entity implementing full ICE - MUST > > Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUS= T > NOT > > Let's try this instead: > > Any WebRTC entity MUST implement full ICE > =E2=80=8BThe transport draft already has the following: =E2=80=8B ICE [RFC5245] MUST be supported. The implementation MUST be a = full ICE implementation, not ICE-Lite. A full ICE implementation allows interworking with both ICE and ICE-Lite implementations when they are deployed appropriately. =E2=80=8BIt also says: This document focuses on the data transport protocols that are used by conforming implementations, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. "Conforming implementations" seem to mean any WebRTC entity. However, the following limits it to only WebRTC devices (and leaves out WebRTC gateway, in particular): This document describes requirements that apply to all WebRTC devices.=E2=80=8B We should probably sort this out the "full ICE" requirement in the transport draft. > Any entity performing full ICE MUST implement consent > > I guess you mean any WebRTC entity (there may be other SIP entities doing full ICE and nothing to do with WebRTC). If so, it works for me.. Muthu=E2=80=8B > Done. > --001a11c3536a7a46380501808b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mo= n, Aug 25, 2014 at 10:45 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 25 August 2014 05:43, Roman Shpount <roman@telurix.com> wrote:
> Any WebRTC entity implementing full ICE - MUST
> Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MU= ST NOT

Let's try this instead:

Any WebRTC entity MUST implement full ICE
=C2=A0
=
=E2=80=8BThe transport draft already has the follow= ing:

=E2=80=8B =C2=A0 ICE [RFC5245] MUST be support= ed. =C2=A0The implementation MUST be a full
=C2=A0 =C2=A0ICE implementation, not ICE-Lite. =C2=A0A full ICE implementat= ion allows
=C2=A0 =C2=A0interworking with both ICE and ICE-Lite imp= lementations when they are
=C2=A0 =C2=A0deployed appropriately.

=E2=80=8BIt also says:

=C2=A0 =C2=A0This document = focuses on the data transport protocols that are used
=C2=A0 =C2=A0by conforming implementations, including the protoco= ls used for
=C2=A0 =C2=A0interaction with intermediate boxe= s such as firewalls, relays and NAT
=C2=A0 =C2=A0boxes.

"Conforming imp= lementations" seem to mean any WebRTC entity. However, the following l= imits it to only WebRTC devices (and leaves out WebRTC gateway, in particul= ar):

=C2=A0 =C2=A0This document describes requirements = that apply to all WebRTC
=C2=A0 =C2=A0devices.=E2=80=8B

We should probably sort this ou= t the "full ICE" requirement in the transport draft.


Any entity performing full ICE MUST implement consent


I guess you mean an= y WebRTC entity (there may be other SIP entities doing full ICE and nothing= to do with WebRTC). If so, it works for me..=C2=A0

Muthu=E2=80=8B

=C2=A0
Done.

--001a11c3536a7a46380501808b02-- From nobody Mon Aug 25 22:07:50 2014 Return-Path: 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 A18541A0653 for ; Mon, 25 Aug 2014 22:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 RKyg98ZEl6Vb for ; Mon, 25 Aug 2014 22:07:43 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0B01A06D9 for ; Mon, 25 Aug 2014 22:07:43 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so14205070wes.32 for ; Mon, 25 Aug 2014 22:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WE19QjYy4zuFRFp/zuKjTld1mff1tLDVe9rmxYTC/FA=; b=WcsCVKDWRvq/BHASSFfrfmrqVvgl8+WwiERe98AdHu4mTk2DDGVOsvcQ2PczNVvtAx W0QAdN7ifERQSW7k0eIcSqP594v2IHhXtjTgQEb4u80tnn/AiCowpnfkGCt0eZfaMpde q96kU+3RNuIHUrGsN6ZECc8D/nbx0AYUTd8Xv/ZaOaWGidCDejmwJ4e80px8qk7eRYS6 BWj6spRudzFJuv8Cs1zMn2wmba1RH9lFsa+jL5081zSedKY1lQNcmZPEFBehCO7pCw7n 59KBKx229hYSL/VdffNQU4DDny9SkEXQzBhXdkqSorAP4HH6BijOPgK+LLqTTgpDMquh R94A== MIME-Version: 1.0 X-Received: by 10.180.12.38 with SMTP id v6mr19280315wib.4.1409029661882; Mon, 25 Aug 2014 22:07:41 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Mon, 25 Aug 2014 22:07:41 -0700 (PDT) In-Reply-To: <56C2F665D49E0341B9DF5938005ACDF819485063@DEMUMBX005.nsn-intra.net> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> <56C2F665D49E0341B9DF5938005ACDF819485063@DEMUMBX005.nsn-intra.net> Date: Tue, 26 Aug 2014 10:37:41 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: "Rauschenbach, Uwe (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=001a11c240ea7980e6050181480f Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/r2d-ba8_uJd_mSzKwmBVzkREGT0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 05:07:45 -0000 --001a11c240ea7980e6050181480f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2014 at 3:00 AM, Rauschenbach, Uwe (NSN - DE/Munich) < uwe.rauschenbach@nsn.com> wrote: > I am not sure whether the -consent-freshness draft is the right place > to require conformance to full ICE in order for something to be called a > WebRTC endpoint. > =E2=80=8BAgree. That should probably go into the transport draft, > There are other drafts like -overview or -transport for this. The > -consent-freshness draft should only make the link between implemented IC= E > flavor and implications for consent freshness support. > > I therefore prefer Roman's proposal, but I am open to relaxing the MUST > NOT. > =E2=80=8BRoman later clarified he just wants the consent draft not to speci= fy any additional requirement for ICE-lite. ICE-lite entities respond to consent checks by definition. That's all. Muthu=E2=80=8B > > Kind regards, > Uwe > ------------------------------ > Von: ext Martin Thomson > Gesendet: =E2=80=8E25.=E2=80=8E08.=E2=80=8E2014 19:16 > An: Roman Shpount > Cc: rtcweb@ietf.org > Betreff: Re: [rtcweb] WG Last Call for > draft-ietf-rtcweb-stun-consent-freshness > > On 25 August 2014 05:43, Roman Shpount wrote: > > Any WebRTC entity implementing full ICE - MUST > > Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUS= T > NOT > > Let's try this instead: > > Any WebRTC entity MUST implement full ICE > > Any entity performing full ICE MUST implement consent > > Done. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c240ea7980e6050181480f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tu= e, Aug 26, 2014 at 3:00 AM, Rauschenbach, Uwe (NSN - DE/Munich) <uwe.rauschenbach@nsn.com> wrote:
I am not sure = whether the -consent-freshness draft is the right place to require conforma= nce to full ICE in order for something to be called a WebRTC endpoint.

=E2= =80=8BAgree. That should probably go into the transport draft,
<= div>=C2=A0
There are other drafts like -overview or -transport for this. The -consent-freshness draft should only make the = link between implemented ICE flavor and implications for consent freshness = support.

I therefore prefer Roman's proposal, but I am open to relaxing the MUST= NOT.

=E2=80=8BRoman later clarified he just wants the consent draft not to speci= fy any additional requirement for ICE-lite. ICE-lite entities respond to co= nsent checks by definition. That's all.

Muthu=E2=80=8B
=C2=A0

Kind regards,
Uwe
Von: ext Martin Thomson<= /a>
Gesendet: =E2=80= =8E25.=E2=80=8E08.=E2=80=8E2014 19:16
An: Roman Shpount Cc: rtcweb@ietf.org Betreff: Re: [r= tcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

On 25 August 2014 05:43, Roman Shpount <roman@telurix.com> wrote:
> Any WebRTC entity implementing full ICE - MUST
> Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MU= ST NOT

Let's try this instead:

Any WebRTC entity MUST implement full ICE

Any entity performing full ICE MUST implement consent

Done.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


--001a11c240ea7980e6050181480f-- From nobody Tue Aug 26 03:10:23 2014 Return-Path: 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 799B71A6F0F for ; Tue, 26 Aug 2014 03:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 SV6a81tLekrc for ; Tue, 26 Aug 2014 03:10:16 -0700 (PDT) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7211A6F17 for ; Tue, 26 Aug 2014 03:10:11 -0700 (PDT) Received: from owa.genband.com (97.65.224.12 [97.65.224.12]) (Using TLS) by us-mta-2.us.mimecast.lan; Tue, 26 Aug 2014 06:10:07 -0400 Received: from GBPLMAIL02.genband.com ([fe80::9455:4039:582f:aee8]) by GBEX01.genband.com ([::1]) with mapi id 14.03.0174.001; Tue, 26 Aug 2014 05:10:05 -0500 From: Jeremy Fuller To: Barry Dingle Thread-Topic: [rtcweb] WebRTC gateway - draft-ietf-rtcweb-overview-11.txt Thread-Index: Ac+9fWS087JAIU5pTOeb7AlhS3h9NAAMZWwAAAzHYxAAKwGXAACh6t7g Date: Tue, 26 Aug 2014 10:10:04 +0000 Message-ID: <3DF911000D80F6459928AC50D3D742F601CC8C@gbplmail02.genband.com> References: <3DF911000D80F6459928AC50D3D742F601A509@gbplmail02.genband.com> <53F66180.6050308@alvestrand.no> <3DF911000D80F6459928AC50D3D742F601AA20@gbplmail02.genband.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.21.173] MIME-Version: 1.0 X-MC-Unique: mse9AMCfSxumSEzoQD-YUA-1 Content-Type: multipart/alternative; boundary="_000_3DF911000D80F6459928AC50D3D742F601CC8Cgbplmail02genband_" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hJw8tV1Jul8YFxiiQB7ZG6PmJgU Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WebRTC gateway - draft-ietf-rtcweb-overview-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:10:20 -0000 --_000_3DF911000D80F6459928AC50D3D742F601CC8Cgbplmail02genband_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSBsaWtlIEJhcnJ54oCZcyBwcm9wb3NhbCBmb3IgdGV4dC4NCg0KRnJvbTogQmFycnkgRGluZ2xl IFttYWlsdG86YnRkaW5nbGVAZ21haWwuY29tXQ0KU2VudDogMjMgQXVndXN0IDIwMTQgMDA6NTMN ClRvOiBKZXJlbXkgRnVsbGVyDQpDYzogSGFyYWxkIEFsdmVzdHJhbmQ7IHJ0Y3dlYkBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdlYlJUQyBnYXRld2F5IC0gZHJhZnQtaWV0Zi1ydGN3 ZWItb3ZlcnZpZXctMTEudHh0DQoNCkhpIEhhcmFsZCwNCg0KSSBzZWUgSmVyZW15J3MgcG9pbnQu DQoNCkdhdGV3YXlzIGJldHdlZW4gYSBXZWJSVEMgZW52aXJvbm1lbnQgYW5kIG5vbi1XZWJSVEMg ZW52aXJvbm1lbnRzIG5lZWQgdG8gY29udmVydCBCT1RIIG1lZGlhIGFuZCBzaWduYWxsaW5nLiBN ZWRpYS1vbmx5IEdhdGV3YXlzIGFyZSB1c3VhbGx5IHJlZmVycmVkIHRvIGFzICdNZWRpYSBHYXRl d2F5cycuIEluIGRyYWZ0LWFsdmVzdHJhbmQtcnRjd2ViLWdhdGV3YXlzLTAwIFNlY3Rpb24gMSBw YXJhZ3JhcGggMiwgdGhlIGRlc2NyaXB0aW9uIG9mICd0aGUgR2F0ZXdheScgcmVmZXJzIG9ubHkg dG8gdGhlICdtZWRpYScuDQoNCkFzIHRoZSBkb2N1bWVudCBsYXRlciByZWZlcnMgdG8gdGhlIFNp Z25hbGluZyBNb2RlbCwgSSBzdWdnZXN0IHRoYXQgdGhlIEludHJvZHVjdGlvbiBzaG91bGQgYWxz byByZWZlciB0byAnU2lnbmFsbGluZycgYnJpZWZseSBhbHNvLg0KDQpJIHN1Z2dlc3QgYSBuZXcg c2Vjb25kIHBhcmFncmFwaCBpbiBTZWN0aW9uIDEgdGhhdCBzYXlzOg0KDQonIFdoZW4gY29tbXVu aWNhdGluZyBiZXR3ZWVuIGEgV2ViUlRDIGVudmlyb25tZW50IGFuZCBub24tV2ViUlRDIGVudmly b25tZW50cywgaW50ZXJ3b3JraW5nIG9mIGJvdGggdGhlIG1lZGlhIGFuZCBzaWduYWxpbmcgaXMg cmVxdWlyZWQuIEFzIHNpZ25hbGluZyBwcm90b2NvbHMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9m IFdlYlJUQywgdGhpcyBkb2N1bWVudCBvbmx5IGNvbnNpZGVycyBzaWduYWxpbmcgaW50ZXJ3b3Jr aW5nIGF0IGEgaGlnaCBsZXZlbCcuDQoNClRvIGF2b2lkIGNvbmZ1c2lvbiwgd2hlbiByZWZlcnJp bmcgdG8gJ01lZGlhIG9ubHknIGZ1bmN0aW9uYWxpdHksIHRoZSBkb2N1bWVudCBzaG91bGQgdXNl IHRoZSB0ZXJtICdXZWJSVEMgbWVkaWEgZ2F0ZXdheScgaW5zdGVhZCBvZiAnV2ViUlRDIGdhdGV3 YXknLg0KQ2hlZXJzLA0KL0JhcnJ5IERpbmdsZQ0KDQpPbiBGcmksIEF1ZyAyMiwgMjAxNCBhdCA2 OjM0IFBNLCBKZXJlbXkgRnVsbGVyIDxqZXJlbXkuZnVsbGVyQGdlbmJhbmQuY29tPG1haWx0bzpq ZXJlbXkuZnVsbGVyQGdlbmJhbmQuY29tPj4gd3JvdGU6DQpIaSBIYXJhbGQsDQoNCkl0IHdvdWxk IGJlIGdvb2QgdG8gaGF2ZSBzb21ldGhpbmcgd2hpY2ggZXhwbGFpbnMgdG8gdGhlIHJlYWRlciB0 aGF0IHRoZXJlIGV4aXN0cyBmdW5jdGlvbmFsaXR5IGZvciB0cmFuc2Zvcm1pbmcgc2lnbmFsbGlu Zy4gSSBhbSByZWFzb25hYmx5IGZsZXhpYmxlIG9uIHRoZSB0ZXJtIHVzZWQuIEkgcHJvcG9zZWQg YXNzb2NpYXRpbmcgdGhpcyBmdW5jdGlvbmFsaXR5IHdpdGggdGhlIHRlcm0gV2ViUlRDIEdhdGV3 YXkgdG8gcmVkdWNlIHRoZSBwcm9saWZlcmF0aW9uIG9mIG5ldyB0ZXJtcy4NCg0KUmVnYXJkcywN CkplcmVteQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFyYWxkIEFsdmVz dHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJh bmQubm8+XQ0KU2VudDogMjEgQXVndXN0IDIwMTQgMjI6MTYNClRvOiBKZXJlbXkgRnVsbGVyDQpD YzogcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog V2ViUlRDIGdhdGV3YXkgLSBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMS50eHQNCg0KT24g MDgvMjEvMjAxNCAxMDoyNCBQTSwgSmVyZW15IEZ1bGxlciB3cm90ZToNCj4gSGkgSGFyYWxkLA0K Pg0KPiBXaXRoIHJlZ2FyZCB0byB5b3VyIGFkZGl0aW9uIG9mIHRoZSBXZWJSVEMgZ2F0ZXdheSBp biB0aGUgcnRjd2ViIG92ZXJ2aWV3LiBJIGFwcHJlY2lhdGUgc2lnbmFsbGluZyBpcyBvdXQgb2Yg c2NvcGUgZm9yIFdlYlJUQywgYnV0IGFzIHlvdSBzYXkgaW4geW91ciBkcmFmdCBhbHZlc3RyYW5k LXJ0Y3dlYi1nYXRld2F5cy0wMC50eHQgImFueSBwcmFjdGljYWwgZ2F0ZXdheSBuZWVkcyB0byBk ZWFsIHdpdGggc2lnbmFsbGluZyIuIFdpdGhvdXQgZ2V0dGluZyBpbnRvIHRvbyBtdWNoIGRldGFp bCBvciBhbnkgaW1wbGVtZW50YXRpb24gY29uc3RyYWludHMsIHdvdWxkIGl0IGJlIHBvc3NpYmxl IHRvIGFkZCBhIHJlZmVyZW5jZSB0byBzaWduYWxsaW5nIHdoZW4gaW50cm9kdWNpbmcgdGhlIFdl YlJUQyBnYXRld2F5Pw0KPg0KPiBJIGhhdmUgc3VnZ2VzdGVkIHNvbWUgbW9kaWZpZWQgdGV4dCBi ZWxvdyBmb3IgeW91ciBjb25zaWRlcmF0aW9uOg0KPg0KPiBDdXJyZW50IFRleHQgIChzZWN0aW9u IDEpOg0KPiAiQSBXZWJSVEMgZ2F0ZXdheSBpcyBzb21ldGhpbmcgdGhhdCBtZWRpYXRlcyBtZWRp YSB0cmFmZmljIHRvIG5vbi1XZWJSVEMgZW50aXRpZXMuICBJdCBpcyBsaWtlIGEgZGV2aWNlLCBi dXQgaGFzIGNlcnRhaW4gcmVzdHJpY3RpaW9ucyBvbiB3aGVyZSBpdCBjYW4gb3BlcmF0ZSwgd2hp Y2ggbWVhbnMgdGhhdCBzb21lIG9mIHRoZSByZXF1aXJlbWVudHMgY2FuIGJlIHJlbGF4ZWQuIg0K Pg0KPiBQcm9wb3NlZCBUZXh0IChzZWN0aW9uIDEpOg0KPiAiQSBXZWJSVEMgZ2F0ZXdheSBpcyBz b21ldGhpbmcgdGhhdCBtZWRpYXRlcyBtZWRpYSB0cmFmZmljLCBvciBzaWduYWxsaW5nLCBvciBi b3RoLCB0byBub24tV2ViUlRDIGVudGl0aWVzLiAgSXQgaXMgbGlrZSBhIGRldmljZSwgYnV0IGhh cyBjZXJ0YWluIHJlc3RyaWN0aW9ucyBvbiB3aGVyZSBpdCBjYW4gb3BlcmF0ZSwgd2hpY2ggbWVh bnMgdGhhdCBzb21lIG9mIHRoZSByZXF1aXJlbWVudHMgY2FuIGJlIHJlbGF4ZWQuIg0KDQpUaGlz IGRvZXMgbm90IHdvcmsgZm9yIG1lLiBBIFdlYlJUQyBnYXRld2F5IGhhcyB0byBoYW5kbGUgbWVk aWEsIGJlY2F1c2UgaXQncyB0aGUgdHJhbnNwb3J0IG9mIG1lZGlhIHRoYXQgV2ViUlRDIHNwZWNp Zmllcy4gQSBwdXJlIHNpZ25hbGxpbmcgZ2F0ZXdheSB3b3VsZCBqdXN0IHRyYW5zZm9ybSB0aGUg c2lnbmFsbGluZyBiZXR3ZWVuIHR3byBXZWJSVEMtY2FwYWJsZSBlbmRwb2ludHMgKFdlYlJUQyBl bmRwb2ludHM/KTsgdGhpcyBpcyB3aGF0IGFuIGFwcGxpY2F0aW9uIGRvZXMsIG5vdCB3aGF0IGEg V2ViUlRDIGdhdGV3YXkgZG9lcy4NCg0KVGhlcmUgbWlnaHQgYmUgYSBuZWVkIHRvIG5hbWUgdGhl IGNsYXNzIG9mIGFwcGxpY2F0aW9ucyB0aGF0IHRyYW5zZm9ybSBzaWduYWxsaW5nOyBJJ20gbm90 IHN1cmUuDQoNCg0KDQo+DQo+IFJlZ2FyZHMsDQo+IEplcmVteQ0KPg0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBEYXRlOiBNb24sIDE4IEF1ZyAyMDE0IDA0OjE5OjE2IC0wNzAw DQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPg0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc+DQo+IENjOiBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4NCj4gU3ViamVjdDogW3J0Y3dlYl0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydGN3ZWItb3Zl cnZpZXctMTEudHh0DQo+IE1lc3NhZ2UtSUQ6IDwyMDE0MDgxODExMTkxNi4yODU3LjYzOTgxLmlk dHJhY2tlckBpZXRmYS5hbXNsLmNvbTxtYWlsdG86MjAxNDA4MTgxMTE5MTYuMjg1Ny42Mzk4MS5p ZHRyYWNrZXJAaWV0ZmEuYW1zbC5jb20+Pg0KPiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNo YXJzZXQ9InV0Zi04Ig0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+ICAgVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUmVhbC1UaW1lIENvbW11bmljYXRpb24gaW4gV0VC LWJyb3dzZXJzIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICAgIFRpdGxl ICAgICAgICAgICA6IE92ZXJ2aWV3OiBSZWFsIFRpbWUgUHJvdG9jb2xzIGZvciBCcm93c2VyLWJh c2VkIEFwcGxpY2F0aW9ucw0KPiAgICAgICAgICBBdXRob3IgICAgICAgICAgOiBIYXJhbGQgVC4g QWx2ZXN0cmFuZA0KPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXJ0Y3dlYi1v dmVydmlldy0xMS50eHQNCj4gICAgICAgUGFnZXMgICAgICAgICAgIDogMjINCj4gICAgICAgRGF0 ZSAgICAgICAgICAgIDogMjAxNC0wOC0xOA0KPg0KPiBBYnN0cmFjdDoNCj4gICAgIFRoaXMgZG9j dW1lbnQgZ2l2ZXMgYW4gb3ZlcnZpZXcgYW5kIGNvbnRleHQgb2YgYSBwcm90b2NvbCBzdWl0ZQ0K PiAgICAgaW50ZW5kZWQgZm9yIHVzZSB3aXRoIHJlYWwtdGltZSBhcHBsaWNhdGlvbnMgdGhhdCBj YW4gYmUgZGVwbG95ZWQgaW4NCj4gICAgIGJyb3dzZXJzIC0gInJlYWwgdGltZSBjb21tdW5pY2F0 aW9uIG9uIHRoZSBXZWIiLg0KPg0KPiAgICAgSXQgaW50ZW5kcyB0byBzZXJ2ZSBhcyBhIHN0YXJ0 aW5nIGFuZCBjb29yZGluYXRpb24gcG9pbnQgdG8gbWFrZSBzdXJlDQo+ICAgICBhbGwgdGhlIHBh cnRzIHRoYXQgYXJlIG5lZWRlZCB0byBhY2hpZXZlIHRoaXMgZ29hbCBhcmUgZmluZGFibGUsIGFu ZA0KPiAgICAgdGhhdCB0aGUgcGFydHMgdGhhdCBiZWxvbmcgaW4gdGhlIEludGVybmV0IHByb3Rv Y29sIHN1aXRlIGFyZSBmdWxseQ0KPiAgICAgc3BlY2lmaWVkIGFuZCBvbiB0aGUgcmlnaHQgcHVi bGljYXRpb24gdHJhY2suDQo+DQo+ICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIEFwcGxpY2FiaWxp dHkgU3RhdGVtZW50IC0gaXQgZG9lcyBub3QgaXRzZWxmDQo+ICAgICBzcGVjaWZ5IGFueSBwcm90 b2NvbCwgYnV0IHNwZWNpZmllcyB3aGljaCBvdGhlciBzcGVjaWZpY2F0aW9ucyBSVENXRUINCj4g ICAgIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgYXJlIHN1cHBvc2VkIHRvIGZvbGxvdy4NCj4N Cj4gICAgIFRoaXMgZG9jdW1lbnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJUQ1dFQiB3b3JraW5n IGdyb3VwLg0KPg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1ydGN3ZWItb3ZlcnZpZXcvDQo+DQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g YXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi1vdmVydmlldy0xMQ0KPg0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTExDQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViDQoNCg== --_000_3DF911000D80F6459928AC50D3D742F601CC8Cgbplmail02genband_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J IGxpa2UgQmFycnnigJlzIHByb3Bvc2FsIGZvciB0ZXh0Lg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmFycnkg RGluZ2xlIFttYWlsdG86YnRkaW5nbGVAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDIz IEF1Z3VzdCAyMDE0IDAwOjUzPGJyPg0KPGI+VG86PC9iPiBKZXJlbXkgRnVsbGVyPGJyPg0KPGI+ Q2M6PC9iPiBIYXJhbGQgQWx2ZXN0cmFuZDsgcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbcnRjd2ViXSBXZWJSVEMgZ2F0ZXdheSAtIGRyYWZ0LWlldGYtcnRjd2ViLW92 ZXJ2aWV3LTExLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBIYXJhbGQsPGJyPg0KPGJyPg0KSSBzZWUgSmVyZW15J3MgcG9pbnQuPGJyPg0KPGJyPg0K R2F0ZXdheXMgYmV0d2VlbiBhIFdlYlJUQyBlbnZpcm9ubWVudCBhbmQgbm9uLVdlYlJUQyBlbnZp cm9ubWVudHMgbmVlZCB0byBjb252ZXJ0IEJPVEggbWVkaWEgYW5kIHNpZ25hbGxpbmcuIE1lZGlh LW9ubHkgR2F0ZXdheXMgYXJlIHVzdWFsbHkgcmVmZXJyZWQgdG8gYXMgJ01lZGlhIEdhdGV3YXlz Jy4gSW4gZHJhZnQtYWx2ZXN0cmFuZC1ydGN3ZWItZ2F0ZXdheXMtMDAgU2VjdGlvbiAxIHBhcmFn cmFwaCAyLCB0aGUgZGVzY3JpcHRpb24gb2YgJ3RoZQ0KIEdhdGV3YXknIHJlZmVycyBvbmx5IHRv IHRoZSAnbWVkaWEnLiA8YnI+DQo8YnI+DQpBcyB0aGUgZG9jdW1lbnQgbGF0ZXIgcmVmZXJzIHRv IHRoZSBTaWduYWxpbmcgTW9kZWwsIEkgc3VnZ2VzdCB0aGF0IHRoZSBJbnRyb2R1Y3Rpb24gc2hv dWxkIGFsc28gcmVmZXIgdG8gJ1NpZ25hbGxpbmcnIGJyaWVmbHkgYWxzby4NCjxicj4NCjxicj4N Ckkgc3VnZ2VzdCBhIG5ldyBzZWNvbmQgcGFyYWdyYXBoIGluIFNlY3Rpb24gMSB0aGF0IHNheXM6 PGJyPg0KPGJyPg0KPGk+JyBXaGVuIGNvbW11bmljYXRpbmcgYmV0d2VlbiBhIFdlYlJUQyBlbnZp cm9ubWVudCBhbmQgbm9uLVdlYlJUQyBlbnZpcm9ubWVudHMsIGludGVyd29ya2luZyBvZiBib3Ro IHRoZSBtZWRpYSBhbmQgc2lnbmFsaW5nIGlzIHJlcXVpcmVkLiBBcyBzaWduYWxpbmcgcHJvdG9j b2xzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiBXZWJSVEMsIHRoaXMgZG9jdW1lbnQgb25seSBj b25zaWRlcnMgc2lnbmFsaW5nIGludGVyd29ya2luZyBhdCBhIGhpZ2gNCiBsZXZlbCcuIDwvaT48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5UbyBhdm9pZCBjb25mdXNpb24sIHdoZW4gcmVmZXJyaW5nIHRvICdNZWRpYSBv bmx5JyBmdW5jdGlvbmFsaXR5LCB0aGUgZG9jdW1lbnQgc2hvdWxkIHVzZSB0aGUgdGVybSAnV2Vi UlRDDQo8Yj5tZWRpYTwvYj4gZ2F0ZXdheScgaW5zdGVhZCBvZiAnV2ViUlRDIGdhdGV3YXknLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5DaGVlcnMsPGJyPg0K L0JhcnJ5IERpbmdsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBdWcgMjIsIDIwMTQgYXQg NjozNCBQTSwgSmVyZW15IEZ1bGxlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmplcmVteS5mdWxsZXJA Z2VuYmFuZC5jb20iIHRhcmdldD0iX2JsYW5rIj5qZXJlbXkuZnVsbGVyQGdlbmJhbmQuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgSGFyYWxkLDxicj4NCjxicj4NCkl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21l dGhpbmcgd2hpY2ggZXhwbGFpbnMgdG8gdGhlIHJlYWRlciB0aGF0IHRoZXJlIGV4aXN0cyBmdW5j dGlvbmFsaXR5IGZvciB0cmFuc2Zvcm1pbmcgc2lnbmFsbGluZy4gSSBhbSByZWFzb25hYmx5IGZs ZXhpYmxlIG9uIHRoZSB0ZXJtIHVzZWQuIEkgcHJvcG9zZWQgYXNzb2NpYXRpbmcgdGhpcyBmdW5j dGlvbmFsaXR5IHdpdGggdGhlIHRlcm0gV2ViUlRDIEdhdGV3YXkgdG8gcmVkdWNlIHRoZSBwcm9s aWZlcmF0aW9uDQogb2YgbmV3IHRlcm1zLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KSmVyZW15 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSGFyYWxkIEFsdmVzdHJhbmQg W21haWx0bzo8YSBocmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iPmhhcmFsZEBhbHZl c3RyYW5kLm5vPC9hPl08YnI+DQpTZW50OiAyMSBBdWd1c3QgMjAxNCAyMjoxNjxicj4NClRvOiBK ZXJlbXkgRnVsbGVyPGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0 Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogV2ViUlRDIGdhdGV3YXkgLSBkcmFm dC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMS50eHQ8YnI+DQo8YnI+DQpPbiAwOC8yMS8yMDE0IDEw OjI0IFBNLCBKZXJlbXkgRnVsbGVyIHdyb3RlOjxicj4NCiZndDsgSGkgSGFyYWxkLDxicj4NCiZn dDs8YnI+DQomZ3Q7IFdpdGggcmVnYXJkIHRvIHlvdXIgYWRkaXRpb24gb2YgdGhlIFdlYlJUQyBn YXRld2F5IGluIHRoZSBydGN3ZWIgb3ZlcnZpZXcuIEkgYXBwcmVjaWF0ZSBzaWduYWxsaW5nIGlz IG91dCBvZiBzY29wZSBmb3IgV2ViUlRDLCBidXQgYXMgeW91IHNheSBpbiB5b3VyIGRyYWZ0IGFs dmVzdHJhbmQtcnRjd2ViLWdhdGV3YXlzLTAwLnR4dCAmcXVvdDthbnkgcHJhY3RpY2FsIGdhdGV3 YXkgbmVlZHMgdG8gZGVhbCB3aXRoIHNpZ25hbGxpbmcmcXVvdDsuIFdpdGhvdXQgZ2V0dGluZw0K IGludG8gdG9vIG11Y2ggZGV0YWlsIG9yIGFueSBpbXBsZW1lbnRhdGlvbiBjb25zdHJhaW50cywg d291bGQgaXQgYmUgcG9zc2libGUgdG8gYWRkIGEgcmVmZXJlbmNlIHRvIHNpZ25hbGxpbmcgd2hl biBpbnRyb2R1Y2luZyB0aGUgV2ViUlRDIGdhdGV3YXk/PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBo YXZlIHN1Z2dlc3RlZCBzb21lIG1vZGlmaWVkIHRleHQgYmVsb3cgZm9yIHlvdXIgY29uc2lkZXJh dGlvbjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDdXJyZW50IFRleHQmbmJzcDsgKHNlY3Rpb24gMSk6 PGJyPg0KJmd0OyAmcXVvdDtBIFdlYlJUQyBnYXRld2F5IGlzIHNvbWV0aGluZyB0aGF0IG1lZGlh dGVzIG1lZGlhIHRyYWZmaWMgdG8gbm9uLVdlYlJUQyBlbnRpdGllcy4mbmJzcDsgSXQgaXMgbGlr ZSBhIGRldmljZSwgYnV0IGhhcyBjZXJ0YWluIHJlc3RyaWN0aWlvbnMgb24gd2hlcmUgaXQgY2Fu IG9wZXJhdGUsIHdoaWNoIG1lYW5zIHRoYXQgc29tZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGNhbiBi ZSByZWxheGVkLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFByb3Bvc2VkIFRleHQgKHNlY3Rp b24gMSk6PGJyPg0KJmd0OyAmcXVvdDtBIFdlYlJUQyBnYXRld2F5IGlzIHNvbWV0aGluZyB0aGF0 IG1lZGlhdGVzIG1lZGlhIHRyYWZmaWMsIG9yIHNpZ25hbGxpbmcsIG9yIGJvdGgsIHRvIG5vbi1X ZWJSVEMgZW50aXRpZXMuJm5ic3A7IEl0IGlzIGxpa2UgYSBkZXZpY2UsIGJ1dCBoYXMgY2VydGFp biByZXN0cmljdGlvbnMgb24gd2hlcmUgaXQgY2FuIG9wZXJhdGUsIHdoaWNoIG1lYW5zIHRoYXQg c29tZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGNhbiBiZSByZWxheGVkLiZxdW90Ozxicj4NCjxicj4N ClRoaXMgZG9lcyBub3Qgd29yayBmb3IgbWUuIEEgV2ViUlRDIGdhdGV3YXkgaGFzIHRvIGhhbmRs ZSBtZWRpYSwgYmVjYXVzZSBpdCdzIHRoZSB0cmFuc3BvcnQgb2YgbWVkaWEgdGhhdCBXZWJSVEMg c3BlY2lmaWVzLiBBIHB1cmUgc2lnbmFsbGluZyBnYXRld2F5IHdvdWxkIGp1c3QgdHJhbnNmb3Jt IHRoZSBzaWduYWxsaW5nIGJldHdlZW4gdHdvIFdlYlJUQy1jYXBhYmxlIGVuZHBvaW50cyAoV2Vi UlRDIGVuZHBvaW50cz8pOyB0aGlzIGlzIHdoYXQNCiBhbiBhcHBsaWNhdGlvbiBkb2VzLCBub3Qg d2hhdCBhIFdlYlJUQyBnYXRld2F5IGRvZXMuPGJyPg0KPGJyPg0KVGhlcmUgbWlnaHQgYmUgYSBu ZWVkIHRvIG5hbWUgdGhlIGNsYXNzIG9mIGFwcGxpY2F0aW9ucyB0aGF0IHRyYW5zZm9ybSBzaWdu YWxsaW5nOyBJJ20gbm90IHN1cmUuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZn dDsgUmVnYXJkcyw8YnI+DQomZ3Q7IEplcmVteTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRGF0ZTogTW9uLCAxOCBBdWcg MjAxNCAwNDoxOToxNiAtMDcwMDxicj4NCiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxicj4NCiZn dDsgVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5j ZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBbcnRjd2ViXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMS50eHQ8YnI+DQomZ3Q7IE1lc3Nh Z2UtSUQ6ICZsdDs8YSBocmVmPSJtYWlsdG86MjAxNDA4MTgxMTE5MTYuMjg1Ny42Mzk4MS5pZHRy YWNrZXJAaWV0ZmEuYW1zbC5jb20iPjIwMTQwODE4MTExOTE2LjI4NTcuNjM5ODEuaWR0cmFja2Vy QGlldGZhLmFtc2wuY29tPC9hPiZndDs8YnI+DQomZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD0mcXVvdDt1dGYtOCZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbiBpbiBXRUItYnJv d3NlcnMgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzogT3ZlcnZpZXc6IFJlYWwgVGltZSBQcm90b2NvbHMgZm9yIEJy b3dzZXItYmFzZWQgQXBwbGljYXRpb25zPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgQXV0aG9yJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IEhh cmFsZCBULiBBbHZlc3RyYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Zp bGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0Zi1ydGN3ZWItb3Zl cnZpZXctMTEudHh0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhZ2VzJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IDIyPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IDIwMTQtMDgtMTg8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGdpdmVzIGFuIG92ZXJ2aWV3 IGFuZCBjb250ZXh0IG9mIGEgcHJvdG9jb2wgc3VpdGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtpbnRlbmRlZCBmb3IgdXNlIHdpdGggcmVhbC10aW1lIGFwcGxpY2F0aW9ucyB0aGF0IGNh biBiZSBkZXBsb3llZCBpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Jyb3dzZXJzIC0g JnF1b3Q7cmVhbCB0aW1lIGNvbW11bmljYXRpb24gb24gdGhlIFdlYiZxdW90Oy48YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7SXQgaW50ZW5kcyB0byBzZXJ2ZSBhcyBhIHN0 YXJ0aW5nIGFuZCBjb29yZGluYXRpb24gcG9pbnQgdG8gbWFrZSBzdXJlPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7YWxsIHRoZSBwYXJ0cyB0aGF0IGFyZSBuZWVkZWQgdG8gYWNoaWV2ZSB0 aGlzIGdvYWwgYXJlIGZpbmRhYmxlLCBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0 aGF0IHRoZSBwYXJ0cyB0aGF0IGJlbG9uZyBpbiB0aGUgSW50ZXJuZXQgcHJvdG9jb2wgc3VpdGUg YXJlIGZ1bGx5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7c3BlY2lmaWVkIGFuZCBvbiB0 aGUgcmlnaHQgcHVibGljYXRpb24gdHJhY2suPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgaXMgYW4gQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnQgLSBp dCBkb2VzIG5vdCBpdHNlbGY8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzcGVjaWZ5IGFu eSBwcm90b2NvbCwgYnV0IHNwZWNpZmllcyB3aGljaCBvdGhlciBzcGVjaWZpY2F0aW9ucyBSVENX RUI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtjb21wbGlhbnQgaW1wbGVtZW50YXRpb25z IGFyZSBzdXBwb3NlZCB0byBmb2xsb3cuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO1RoaXMgZG9jdW1lbnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJUQ1dFQiB3b3JraW5n IGdyb3VwLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LyIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1ydGN3ZWItb3ZlcnZpZXcvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTEiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRj d2ViLW92ZXJ2aWV3LTExPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEx IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMTwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KJmd0Ozxicj4NCiZndDsgSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCiZn dDsgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0i X2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3DF911000D80F6459928AC50D3D742F601CC8Cgbplmail02genband_-- From nobody Tue Aug 26 03:59:15 2014 Return-Path: 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 80D7C1A6F63 for ; Tue, 26 Aug 2014 03:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 dDcri3Zh3sAz for ; Tue, 26 Aug 2014 03:59:10 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4D91A001D for ; Tue, 26 Aug 2014 03:59:10 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 91D29FDDFE69; Tue, 26 Aug 2014 10:59:06 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s7QAx60U021492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 06:59:09 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 26 Aug 2014 06:59:06 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Martin Thomson Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPwJwliI9buEYWNESDP5FmOAawY5vhzk/g Date: Tue, 26 Aug 2014 10:59:05 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nnBdProweIIFmg_OB9ZMtYV1n3E Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 10:59:11 -0000 PiBPbiAyNSBBdWd1c3QgMjAxNCAxMTowMSwgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KQ0K PiA8UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KPiA+IEkgZG9u4oCZ dCB0aGluayBvdXRsYXdpbmcgSUNFLWxpdGUgaXMgYWNjZXB0YWJsZS4NCj4gDQo+IEkndmUgbm90 IGV2ZXIgc3VnZ2VzdGVkIHRoYXQuICBJJ20gb25seSBzdWdnZXN0aW5nIHRoYXQgSUNFLWxpdGUg 4oiJDQo+IFdlYlJUQy4gIChUaGF0J3MgVSsyMjA5LCBidHcpLg0KPFJhanU+DQpXZWJSVEMgaXMg ZGVmaW5lZCBieSBtb3JlIHRoYW4ganVzdCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcy4NCklNSE8s IENhdGVnb3JpemluZyBhIGNsYXNzIG9mIGRldmljZXMgYXMgTk9UIFdlYlJUQyBqdXN0IGJlY2F1 c2Ugb2YgSUNFLWxpdGUgaXMgbm90IHJpZ2h0LCB3aGlsZSB0aGVyZSBpcyBzbyBtdWNoIG90aGVy IGZ1bmN0aW9uYWxpdHkgKGNvZGVjcywgZGF0YSBjaGFubmVscykgdGhhdCBpcyBjb21tb24uIEFs c28sIHRoZSBjb252ZXJzZSBpcyBub3QgdHJ1ZSBlaXRoZXI7IGp1c3QgYmVjYXVzZSBhIGNsYXNz IG9mIGRldmljZXMgc3VwcG9ydCBJQ0UtZnVsbCBkb2VzIG5vdCBlcXVhdGUgdGhlbSB0byBXZWJS VEMgY2xhc3MuDQpTbywgSU1ITyB0aGVyZSBpcyBubyBtZXJpdCBpbiAocmUpY2xhc3NpZnlpbmcg V2ViUlRDIGRldmljZXMgYXJvdW5kIElDRS1saXRlLg0KSSBhbHNvIHdhbnQgdG8gcG9pbnQgb3V0 IHRoYXQgSUNFLWxpdGUgaXMgcGFydCBvZiBJQ0UgUkZDIGFuZCBhbHNvIFdlYlJUQyBjbGllbnRz IGFscmVhZHkgaGF2ZSBhIHdheSB0byBuZWdvdGlhdGUgSUNFLWxpdGUuDQoNCkluIGFkZGl0aW9u LCBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldy0xMSBhZGRlZCBkZWZpbml0aW9uIGZvciAzIGNs YXNzZXMgb2Ygd2VicnRjIGRldmljZXMgd2l0aCB2YXJ5aW5nIGxldmVsIG9mIGNvbmZvcm1hbmNl IHdoaWxlIGtlZXBpbmcgdGhlIGNvcmUgd2VicnRjIGNvbmZvcm1hbmNlIGNvbW1vbi4gV29uJ3Qg cmVzdCBvZiB0aGUgc3BlY3MgbGlrZSBjb25zZW50IGZyZXNobmVzcywgdHJhbnNwb3J0cyBldGMu IHJlZmVyIHRvIHRoZXNlIGNsYXNzZXMgb2Ygd2VicnRjIGRldmljZXMgaW5zdGVhZCBvZiBqdXN0 IGNvbmNlbnRyYXRpbmcgb24ganVzdCBvbmUgdHlwZSBvZiB3ZWJydGMgZGV2aWNlPw0KDQo8L1Jh anU+DQoNCkJSDQpSYWp1DQoNCg== From nobody Tue Aug 26 07:45:58 2014 Return-Path: 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 C26941A86EA for ; Tue, 26 Aug 2014 07:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_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 EOOwk0MwgPxg for ; Tue, 26 Aug 2014 07:45:55 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A681A802B for ; Tue, 26 Aug 2014 07:45:54 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so4292864wiv.1 for ; Tue, 26 Aug 2014 07:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4OpaW+f5doFIDNfUTeVO+qTvq4SCNr70SkuYGIst5ME=; b=TXBjgbRVx5BKgRklxc4lpSLQQxWmNh8Avvomfu75N94/9799fJ3cXdR4h5ma9A9P10 asxFKbch70+d5X7rzOekn5ggHuA4mWZGb6ek1dOYHUBM1pA/ynkcVL2E75xNXkheKWXq zDfgYwdZFUjk2UAyxbepgzMqGPxusp2tf9qcpydIl7NAVucLEOvRNB+skKMPnZas9076 Q249cyL5OfQG18ccYy8koDq/B4mAyCRAvgcJqTflY6Foy1RubOuBPfB+7c8BYG7e6zNh YBSJBRx4cCCR4wYUuEe8qrOSHZgRb7SSfaYJ6zZ8fffkhijCoq1ErgLKM22FZFBsca1e Y3FQ== MIME-Version: 1.0 X-Received: by 10.180.73.139 with SMTP id l11mr22159825wiv.30.1409064353299; Tue, 26 Aug 2014 07:45:53 -0700 (PDT) Received: by 10.180.197.168 with HTTP; Tue, 26 Aug 2014 07:45:53 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Tue, 26 Aug 2014 20:15:53 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=f46d043c07de3e85700501895c40 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VOI4I_ZwGPt28xQzBTrfskhlVDw Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 14:45:56 -0000 --f46d043c07de3e85700501895c40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 26, 2014 at 4:29 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > > On 25 August 2014 11:01, Makaraju, Maridi Raju (Raju) > > wrote: > > > I don=E2=80=99t think outlawing ICE-lite is acceptable. > > > > I've not ever suggested that. I'm only suggesting that ICE-lite =E2=88= =89 > > WebRTC. (That's U+2209, btw). > > WebRTC is defined by more than just ICE connectivity checks. > IMHO, Categorizing a class of devices as NOT WebRTC just because of > ICE-lite is not right, while there is so much other functionality (codecs= , > data channels) that is common. Also, the converse is not true either; jus= t > because a class of devices support ICE-full does not equate them to WebRT= C > class. > So, IMHO there is no merit in (re)classifying WebRTC devices around > ICE-lite. > I also want to point out that ICE-lite is part of ICE RFC and also WebRTC > clients already have a way to negotiate ICE-lite. > > In addition, draft-ietf-rtcweb-overview-11 added definition for 3 classes > of webrtc devices with varying level of conformance while keeping the cor= e > webrtc conformance common. Won't rest of the specs like consent freshness= , > transports etc. refer to these classes of webrtc devices instead of just > concentrating on just one type of webrtc device? > =E2=80=8BConsent freshness is applicable to any WebRTC entity supporting fu= ll ICE. A WebRTC browser/device as defined in the transport and overview drafts support full ICE, so perform consent freshness. The requirements for other WebRTC entities, including WebRTC gateway, is yet to be fully specified, and the document that specifies them would also specify whether they support full ICE or not (and hence whether they perform consent freshness or not). I don't see a problem with this approach. If you have a better approach, do suggest the text. Muthu =E2=80=8B > > > > BR > Raju > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d043c07de3e85700501895c40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tu= e, Aug 26, 2014 at 4:29 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>= ; wrote:
> On 25 August 2014 11:01, Makaraju, Mar= idi Raju (Raju)
> <Raju.Makaraju@= alcatel-lucent.com> wrote:
> > I don=E2=80=99t think outlawing ICE-lite is acceptable.
>
> I've not ever suggested that.=C2=A0 I'm only suggesting that I= CE-lite =E2=88=89
> WebRTC.=C2=A0 (That's U+2209, btw).
<Raju>
WebRTC is defined by more than just ICE connectivity checks.
IMHO, Categorizing a class of devices as NOT WebRTC just because of ICE-lit= e is not right, while there is so much other functionality (codecs, data ch= annels) that is common. Also, the converse is not true either; just because= a class of devices support ICE-full does not equate them to WebRTC class.<= br> So, IMHO there is no merit in (re)classifying WebRTC devices around ICE-lit= e.
I also want to point out that ICE-lite is part of ICE RFC and also WebRTC c= lients already have a way to negotiate ICE-lite.

In addition, draft-ietf-rtcweb-overview-11 added definition for 3 classes o= f webrtc devices with varying level of conformance while keeping the core w= ebrtc conformance common. Won't rest of the specs like consent freshnes= s, transports etc. refer to these classes of webrtc devices instead of just= concentrating on just one type of webrtc device?

=E2=80=8BConsent freshn= ess is applicable to any WebRTC entity supporting full ICE. A WebRTC browse= r/device as defined in the transport and overview drafts support full ICE, = so perform consent freshness. The requirements for other WebRTC entities, i= ncluding WebRTC gateway, is yet to be fully specified, and the document tha= t specifies them would also specify whether they support full ICE or not (a= nd hence whether they perform consent freshness or not).

I don't see a problem w= ith this approach.

If you have a better approa= ch, do suggest the text.

Muthu =E2=80=8B
=
=C2=A0

</Raju>

BR
Raju

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--f46d043c07de3e85700501895c40-- From nobody Tue Aug 26 11:00:56 2014 Return-Path: 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 4DE091A0060 for ; Tue, 26 Aug 2014 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 iF9gUBdnnlQx for ; Tue, 26 Aug 2014 11:00:54 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78D71A002D for ; Tue, 26 Aug 2014 11:00:53 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id l4so1806814lbv.37 for ; Tue, 26 Aug 2014 11:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gM2X2EKLIcvZp/F1ivlA40GQlreUXLjriaR73ooeqsQ=; b=fjb5YK0peTGKRnQRoK4C2Lr+S0BcE2PF1ouRJhM/L9Lta9SH2lFABFral7zYDHeFvN jJlsTgbQDvgG6MoaHnoumM1mQOdx0np1olGNJY2hpLhpfKZJlelfDVzjydL/cz50bUdZ BZsYZYWXSLL1sg9kPrp1Fbf1tTS0yMd7UJdKXWt/4xUJlMpJtk0ylh9wrVStEK03uYxo ZygEsQ+vUImj4TGH1ICfUl+h2g3Q+9M7qYwbAPaJQNMFxJEJLblGKf6nu8oamyq+ubj3 BzUQDriL4jVqh8LJ8kKr5j5DJHHbQbadLZXwhBrWymxARKzS14OINI+Cyf4dLOtxErCq JW9w== MIME-Version: 1.0 X-Received: by 10.152.87.81 with SMTP id v17mr18990258laz.17.1409076052241; Tue, 26 Aug 2014 11:00:52 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 26 Aug 2014 11:00:52 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> Date: Tue, 26 Aug 2014 11:00:52 -0700 Message-ID: From: Martin Thomson To: Muthu Arul Mozhi Perumal Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/thw1PfstU6cyCy2599NHzASI5XI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:00:55 -0000 On 26 August 2014 07:45, Muthu Arul Mozhi Perumal wrote: > Consent freshness is applicable to any WebRTC entity supporting full ICE. A > WebRTC browser/device as defined in the transport and overview drafts > support full ICE, so perform consent freshness. The requirements for other > WebRTC entities, including WebRTC gateway, is yet to be fully specified, and > the document that specifies them would also specify whether they support > full ICE or not (and hence whether they perform consent freshness or not). Actually, that's probably the best approach: note that this applies - and can be useful for - any ICE implementation. And leave it at that for this document. The transports or security docs might make some statements about mandating this mechanism. From nobody Tue Aug 26 12:22:39 2014 Return-Path: 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 0D98B1A875D for ; Tue, 26 Aug 2014 12:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 zbhUp8JlHc18 for ; Tue, 26 Aug 2014 12:22:36 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53ED1A8766 for ; Tue, 26 Aug 2014 12:22:35 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 9FDF88E2232D6; Tue, 26 Aug 2014 19:22:31 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7QJM3x7031284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 15:22:34 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 26 Aug 2014 15:21:41 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPwJwliI9buEYWNESDP5FmOAawY5vhzk/ggAFsZYD///NCAA== Date: Tue, 26 Aug 2014 19:21:40 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E534706US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Va6PFX2CfeEpuLMN9uN8fprieG4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:22:38 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E534706US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29uc2VudCBmcmVzaG5lc3MgaXMgYXBwbGljYWJsZSB0byBhbnkgV2ViUlRDIGVudGl0eSBzdXBw b3J0aW5nIGZ1bGwgSUNFLiBBIFdlYlJUQyBicm93c2VyL2RldmljZSBhcyBkZWZpbmVkIGluIHRo ZSB0cmFuc3BvcnQgYW5kIG92ZXJ2aWV3IGRyYWZ0cyBzdXBwb3J0IGZ1bGwgSUNFLCBzbyBwZXJm b3JtIGNvbnNlbnQgZnJlc2huZXNzLiBUaGUgcmVxdWlyZW1lbnRzIGZvciBvdGhlciBXZWJSVEMg ZW50aXRpZXMsIGluY2x1ZGluZyBXZWJSVEMgZ2F0ZXdheSwgaXMgeWV0IHRvIGJlIGZ1bGx5IHNw ZWNpZmllZCwgYW5kIHRoZSBkb2N1bWVudCB0aGF0IHNwZWNpZmllcyB0aGVtIHdvdWxkIGFsc28g c3BlY2lmeSB3aGV0aGVyIHRoZXkgc3VwcG9ydCBmdWxsIElDRSBvciBub3QgKGFuZCBoZW5jZSB3 aGV0aGVyIHRoZXkgcGVyZm9ybSBjb25zZW50IGZyZXNobmVzcyBvciBub3QpLg0KDQpJIGRvbid0 IHNlZSBhIHByb2JsZW0gd2l0aCB0aGlzIGFwcHJvYWNoLg0KDQpJZiB5b3UgaGF2ZSBhIGJldHRl ciBhcHByb2FjaCwgZG8gc3VnZ2VzdCB0aGUgdGV4dC4NCjxSYWp1Pg0KSUhNTywgdGhlIGNvbnNl bnQgZnJlc2huZXNzIGFuZCBJQ0UtZnVsbCBzaG91bGQgTk9UIGJlIGNvdXBsZWQgdG9nZXRoZXIu DQpTbywgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgYXBwcm9hY2ggd2hpY2ggb3ZlcmxhcHMgd2l0 aCB5b3Vycy4NCg0KVGhlIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3Mg c2hvdWxkIGp1c3QgdGFsayBhYm91dCBjb25zZW50IGZyZXNobmVzcyBpbiBnZW5lcmFsIGFuZCBp ZiBpdCBpcyBzdXBwb3J0ZWQgYnkgYW4gaW1wbGVtZW50YXRpb24gdGhlbiBpdCBzaG91bGQgc3Bl Y2lmeSB0aGUgYmVoYXZpb3IsIGJ1dCBub3QgdGllIGl0IHRvIElDRS1mdWxsLg0KDQoNClRoZSBk cmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzIHNob3VsZCBhbGxvdyBib3RoIElDRS1mdWxsIGFu ZCBJQ0UtbGl0ZSBpbXBsZW1lbnRhdGlvbnMgZm9yIHdlYnJ0YyBhbmQgZGVmZXIgd2hvIGltcGxl bWVudHMgd2hhdCB0byByZXNwZWN0aXZlIHdlYnJ0YyBjbGFzcyBzcGVjaWZpYyBkcmFmdHMgKGUu Zy4gSS1ELmFsdmVzdHJhbmQtcnRjd2ViLWdhdGV3YXlzKS4gSU1PLCB0aGlzIGlzIGJlY2F1c2Ug d2VicnRjIGlzIG11Y2ggYmlnZ2VyIHRoYW4ganVzdCBob3cgSUNFIGlzIGRvbmUgYW5kIGNhdGVn b3JpemluZyBhbiBpbXBsZW1lbnRhdGlvbiBhcyBub24tV2VSVEMganVzdCBiZWNhdXNlIG9mIElD RS1saXRlIGlzIG5vdCByaWdodC4NCg0KVGhlIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3IGNh biBzcGVjaWZ5IHNvbWUgaGlnaC1sZXZlbCByZXF1aXJlbWVudHMgZm9yIHZhcmlvdXMgY2xhc3Nl cyBvZiB3ZWJydGMgaW1wbGVtZW50YXRpb25zIGFuZC9vciBkZWZlciB0aGVtLCBpbiBzb21lIGNh c2VzLCB0byByZXNwZWN0aXZlIGRyYWZ0cyAobGlrZSBpdCBhbHJlYWR5IGRpZCB3aXRoIEktRC5h bHZlc3RyYW5kLXJ0Y3dlYi1nYXRld2F5cykuDQo8L1JhanU+DQoNCkJSDQpSYWp1DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E534706US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUt bmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Q29uc2VudCBmcmVzaG5lc3MgaXMgYXBwbGljYWJsZSB0byBhbnkgV2ViUlRDIGVudGl0 eSBzdXBwb3J0aW5nIGZ1bGwgSUNFLiBBIFdlYlJUQyBicm93c2VyL2RldmljZSBhcyBkZWZpbmVk IGluIHRoZSB0cmFuc3BvcnQgYW5kIG92ZXJ2aWV3IGRyYWZ0cyBzdXBwb3J0IGZ1bGwgSUNFLCBz byBwZXJmb3JtIGNvbnNlbnQgZnJlc2huZXNzLg0KIFRoZSByZXF1aXJlbWVudHMgZm9yIG90aGVy IFdlYlJUQyBlbnRpdGllcywgaW5jbHVkaW5nIFdlYlJUQyBnYXRld2F5LCBpcyB5ZXQgdG8gYmUg ZnVsbHkgc3BlY2lmaWVkLCBhbmQgdGhlIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZW0gd291 bGQgYWxzbyBzcGVjaWZ5IHdoZXRoZXIgdGhleSBzdXBwb3J0IGZ1bGwgSUNFIG9yIG5vdCAoYW5k IGhlbmNlIHdoZXRoZXIgdGhleSBwZXJmb3JtIGNvbnNlbnQgZnJlc2huZXNzIG9yIG5vdCkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGRvbid0IHNlZSBhIHByb2JsZW0gd2l0aCB0 aGlzIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGhhdmUg YSBiZXR0ZXIgYXBwcm9hY2gsIGRvIHN1Z2dlc3QgdGhlIHRleHQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZsdDtSYWp1Jmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklITU8sIHRoZSBjb25zZW50IGZyZXNo bmVzcyBhbmQgSUNFLWZ1bGwgc2hvdWxkIE5PVCBiZSBjb3VwbGVkIHRvZ2V0aGVyLjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCBJIHByb3Bvc2UgdGhlIGZv bGxvd2luZyBhcHByb2FjaCB3aGljaCBvdmVybGFwcyB3aXRoIHlvdXJzLjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNl bnQtZnJlc2huZXNzIHNob3VsZCBqdXN0IHRhbGsgYWJvdXQgY29uc2VudCBmcmVzaG5lc3MgaW4g Z2VuZXJhbCBhbmQgaWYgaXQgaXMgc3VwcG9ydGVkIGJ5IGFuIGltcGxlbWVudGF0aW9uIHRoZW4g aXQgc2hvdWxkDQogc3BlY2lmeSB0aGUgYmVoYXZpb3IsIGJ1dCBub3QgdGllIGl0IHRvIElDRS1m dWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHByZT48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGRyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9y dHMgc2hvdWxkIGFsbG93IGJvdGggSUNFLWZ1bGwgYW5kIElDRS1saXRlIGltcGxlbWVudGF0aW9u cyBmb3Igd2VicnRjIGFuZCBkZWZlciB3aG8gaW1wbGVtZW50cyB3aGF0IHRvIHJlc3BlY3RpdmUg d2VicnRjIGNsYXNzIHNwZWNpZmljIGRyYWZ0cyAoZS5nLiBJLUQuYWx2ZXN0cmFuZC1ydGN3ZWIt Z2F0ZXdheXMpLiBJTU8sIHRoaXMgaXMgYmVjYXVzZSB3ZWJydGMgaXMgbXVjaCBiaWdnZXIgdGhh biBqdXN0IGhvdyBJQ0UgaXMgZG9uZSBhbmQgY2F0ZWdvcml6aW5nIGFuIGltcGxlbWVudGF0aW9u IGFzIG5vbi1XZVJUQyBqdXN0IGJlY2F1c2Ugb2YgSUNFLWxpdGUgaXMgbm90IHJpZ2h0Ljwvc3Bh bj48L2k+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3IGNhbiBzcGVjaWZ5IHNv bWUgaGlnaC1sZXZlbCByZXF1aXJlbWVudHMgZm9yIHZhcmlvdXMgY2xhc3NlcyBvZiB3ZWJydGMg aW1wbGVtZW50YXRpb25zIGFuZC9vciBkZWZlciB0aGVtLCBpbiBzb21lIGNhc2VzLA0KIHRvIHJl c3BlY3RpdmUgZHJhZnRzIChsaWtlIGl0IGFscmVhZHkgZGlkIHdpdGggSS1ELmFsdmVzdHJhbmQt cnRjd2ViLWdhdGV3YXlzKS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbHQ7L1JhanUmZ3Q7PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJhanU8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E534706US70UWXCHMBA02z_-- From nobody Tue Aug 26 12:39:41 2014 Return-Path: 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 8393F1A0290 for ; Tue, 26 Aug 2014 12:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.32 X-Spam-Level: X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 ehiPcTnJ5uaD for ; Tue, 26 Aug 2014 12:39:35 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C241A0292 for ; Tue, 26 Aug 2014 12:39:34 -0700 (PDT) Received: from [192.168.1.200] (p508F21F2.dip0.t-ipconnect.de [80.143.33.242]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D851D1C0B3F53; Tue, 26 Aug 2014 21:39:30 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Tue, 26 Aug 2014 21:39:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06E6D6A7-95A2-414A-BB14-A200C6E8B87E@lurchi.franken.de> References: To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_nHlUhvjrMFHrk-MJdXKpTEzo20 Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org Subject: Re: [rtcweb] AD review of draft-ietf-rtcweb-data-channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:39:39 -0000 On 08 Aug 2014, at 22:27, Richard Barnes wrote: > I have reviewed this document in preparation for IETF Last Call. I = have gone ahead and requested last call, but there are some comments = below that I would like to be addressed before the document goes to the = IESG. > --Richard Richard, thank you very much for the review. See my comments in-line. Best regards Michael >=20 >=20 > MAJOR: >=20 > Section 6.2.=20 > I'm very concerned about interoperability of data channels given that, = e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and = (2) DCEP only works if it is used by both endpoints (it resets any = streams that are used without DCEP negotiation). In order to avoid = interoperability=20 Streams are only reset, if they are already used. > failure of this type, whatever mechanism is used to establish an SCTP = association that is used for data channels must also negotiate the = mechanism(s) that will be used to establish data channels over that = association. That could be directly (by negotiating some data channels = at the same time as the association), or indirectly (by indicating that = DCEP or some other protocol will be used), but either way, the endpoints = of the association need to know how data channels will be negotiated = before they can create any data channels. This section needs to state = this requirement so that applications using data channels can know that = they need to meet it. I don't think they need it at the time the association is created, they = need this information at the time a data channel is created. This is described in the first = paragraph of section 6.5. What about changing there: The details are out of scope of this document. to The details are out of scope of this document. Applications using data channels need to use the negotiation methods consistently on both end-points. >=20 > Section 6.4.=20 > This section lists in passing several properties of a data channel, = but doesn't give a full definition of all the things that need to be = defined in order to define a data channel. Fortunately, such a list is = given in draft-ietf-rtcweb-data-protocol (Section 4); I would suggest = moving that here. I agree, this is much cleaner in draft-ietf-rtcweb-data-protocol. What = about using 6.4. WebRTC Data Channel Definition One strong wish is for the application-level API to be close to the API for WebSockets, which implies bidirectional streams of data and a textual field called 'label' used to identify the meaning of the data channel. The realization of a data channel is a pair of one incoming stream and one outgoing SCTP stream having the same SCTP stream identifier. How these SCTP stream identifiers are selected is protocol and implementation dependent. This allows a bidirectional communication. Additionally, each data channel has the following properties in each direction: o reliable or unreliable message transmission. In case of unreliable transmissions, the same level of unreliability is used. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream. o in-order or out-of-order message delivery for message sent. Please note that in SCTP this is a property of an SCTP user message and not of an SCTP stream. o A priority, which is a 2 byte unsigned integer. These priorities MUST be interpreted as weighted-fair-queuing scheduling priorities per the definition of the corresponding stream scheduler supporting interleaving in [I-D.ietf-tsvwg-sctp-ndata]. For use in WebRTC, the values used SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high") or 1024 ("extra high"). o an optional label. o an optional protocol. Please note that for a data channel being negotiated with the protocol specified in [I-D.ietf-rtcweb-data-protocol] all of the above properties are the same in both directions. Does this address your comment? >=20 >=20 >=20 > MINOR / EDITORIAL: >=20 > Figures 1 and 2 list ICE as a separate layer. That seems incorrect, = since ICE isn't actually involved once the connection is set up. Doesn't ICE continue to run connectivity checks continuously and even = allows changes of the IP addresses being used for the communication? >=20 > Section 6.4. "... in-sequence, out-of-sequence, reliable and = unreliable as properties of channels" > "... (as opposed to SCTP, which applies these concepts to messages)" See above. >=20 > Section 6.4. "... and waiting for onopen to fire ... meaning of the = streams" > This sentence doesn't really parse, and it's not clear why these = API-level considerations are relevant here. See above. >=20 > Section 6.4. "stream SCTP identifier" -> "SCTP stream identifier" ? Changed. >=20 > Section 6.6. "The sender SHOULD disable the Nagle algorithm..." > A reference to RFC 1122 would be helpful here. OK. Added as an Informative Reference. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 26 12:58:40 2014 Return-Path: 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 768D51A02A6 for ; Tue, 26 Aug 2014 12:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 lzi4iEieasDW for ; Tue, 26 Aug 2014 12:58:36 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8785E1A02A3 for ; Tue, 26 Aug 2014 12:58:36 -0700 (PDT) Received: from [192.168.1.200] (p508F21F2.dip0.t-ipconnect.de [80.143.33.242]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A0C981C0B3F53; Tue, 26 Aug 2014 21:58:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53E90E9A.1070707@alum.mit.edu> Date: Tue, 26 Aug 2014 21:58:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24BC5769-7EB4-44BE-987E-336EA5A12A24@lurchi.franken.de> References: <53E90E9A.1070707@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Mp57exKsY_p36Iq0Y4DsetkTvLE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Some final comments on draft-ietf-rtcweb-data-channel-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 19:58:38 -0000 On 11 Aug 2014, at 20:42, Paul Kyzivat wrote: > I just did another read-through of this draft, and identified a few = things that I think need to be cleared up: Hi Paul, thank you very much for your comments. See my answers in-line. Best regards Michael >=20 > Association Usage: >=20 > draft-ietf-mmusic-sctp-sdp specifies new SDP notation for describing = SCTP associations. It is not specific to rtcweb. For SCTP m-lines, it is = necessary to name an "association-usage". Support for rtcweb data = channels is one possible usage. >=20 > Currently draft-ietf-mmusic-sctp-sdp gives all of its examples using = "webrtc-datachannel" as the association-usage. It does *not* currently = define an IANA registry for association-usage, but it should. But it = really is the wrong place to define this specific usage. Certainly = draft-ietf-rtcweb-data-channel provides the *definition* of the usage. = IMO it also ought to define and do the IANA registration of the name. = (Obviously some coordination is required between this draft and the = sctp-sdp draft, so that they are aligned on this.) I really think that SDP related stuff should be in the MMUSIC ID = including the IANA registrations. >=20 > Also, can we PLEASE use a name that not specific to webrtc? This = *will* be used in contexts where webrtc is not being used. (At least by = CLUE.) >=20 > I propose that the name be "data-channel". Anyone against it? I could change the name consistently in both RTCWEB = IDs. >=20 > SCTP port: >=20 > *Something* needs to talk about SCTP ports. Currently they aren't = mentioned either here or in JSEP. Since this document makes the point = that this will be a user layer stack, and talks about the layering over = DTLS, I think they ought to be mentioned here. They also probably need = to be mentioned in JSEP, as part of aligning to the most recent version = of draft-ietf-mmusic-sctp-sdp. >=20 > Only a little bit needs to be stated: that SCTP supports multiple SCTP = ports, but that a particular SCTP association uses a single sctp port = pair. (One port at each end of the SCTP association.) JSEP needs to = specify how these ports are negotiated. (Via reference to = draft-ietf-mmusic-sctp-sdp.) What about adding SCTP uses the same port number concept as TCP and UDP do. Therefore an SCTP association uses two port numbers, one at each SCTP end- point. at the end of Section 5. >=20 > Normative requirement for DCEP support: >=20 > While this draft references ietf-rtcweb-data-protocol normatively, and = talks about it, I can find no explicit statement that implementations of = this draft MUST also implement DCEP. AFAIK negotiation of the sctp = association-usage defined by this draft in intended to mean that DCEP is = also supported. If I remember it correctly, the decision was to take such a statement = out of the document... Such a statement was in the second paragraph of http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-6.5 and was taken out. See http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-08#section-6.5 >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Tue Aug 26 13:26:28 2014 Return-Path: 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 E78D61A8829 for ; Tue, 26 Aug 2014 13:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 cgI9EKPC6_EE for ; Tue, 26 Aug 2014 13:26:23 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20081A8828 for ; Tue, 26 Aug 2014 13:26:22 -0700 (PDT) Received: from [192.168.1.200] (p508F21F2.dip0.t-ipconnect.de [80.143.33.242]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5D8F51C0B3F53; Tue, 26 Aug 2014 22:26:19 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53EEFDD3.6040607@omnitor.se> Date: Tue, 26 Aug 2014 22:26:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8446CEF8-D47A-41F2-AC80-3174E3721BAC@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> To: Gunnar Hellstrom X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/EUY-llJUciESDPaUhvp72ik5pPY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:26:27 -0000 On 16 Aug 2014, at 08:44, Gunnar Hellstrom = wrote: > We have discussed the lack of description of failure handling in = draft-ietf-rtcweb-data-channel a couple of times. >=20 > Explanations of mechanisms have been provided in mail answers that I = have not seen documented elsewhere, but they have not been introduced in = the draft. >=20 > I think that for specification and implementation of the WebRTC API, = there is a need for clear specification how the channels behave in = failure situations. >=20 > I suggest to insert a new chapter 6.7 in the draft with the following = contents. =20 Hi Gunnar, see my comments in-line. Best regards Michael >=20 > = -------------------------------------------------------------------Propose= d new section = 6.7-----------------------------------------------------------------------= -------------------- > 6.7 Transmission failure and error handling=20 >=20 > Failures can occur in an open channel by transmission error detection = and by SCTP watchdog error indications. > If transmission in a reliable channel fails, the association where the = channel belongs will be aborted. If all retries for a watchdog expires, = the corresponding association will be aborted. All channels in an = association that is aborted because of errors need to be closed by the = party detecting the failure. Network error indications shall be provided = to upper layers on all closed channels. I think we could change Section 6.2. Association Setup to 6.2. Association Handling and state there that if an association is terminated, for example due to = error cases, all data channels are closed. >=20 > If retransmissions or transmission time is exceeded in a partially = reliable channel, the transmission SHALL be allowed to continue with = other data items. A transmission error indication SHALL be provided to = upper layers on that channel.=20 I think the handling of the PR-SCTP stuff is clear. Whether this should = be exposed in the API is a W3C issue, I think. >=20 > If reception out-of order is detected from an SCTP channel for which = ordered transmission is requested, the receiver SHALL close the data = channel, and provide an transmission error indication to upper layers. =20= I think we discussed this at the IETF and the conclusion was that this = kind of check is not done. >=20 > If a message with an unsupported PPID is received or some logical = error is detected by the receiver, the receiver SHALL close the = corresponding data channel.=20 This text is already in Section 6.6. > = -----------------------------------------------------------------------end= of = proposal------------------------------------------------------------------= --------------------------------------------- >=20 > I am not sure about what the two last kinds of errors should result in = and hope that the experts can adjust the wording. >=20 > Regards >=20 > Gunnar > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se >=20 > On 2014-08-11 20:13, IESG Secretary wrote: >> The IESG would like to retract the current Last Call on the following=20= >> document: >>=20 >> - 'WebRTC Data Channels' >> as Proposed Standard >>=20 >> The document's state has been set back to "AD Evaluation." >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 26 13:27:03 2014 Return-Path: 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 404601A882E for ; Tue, 26 Aug 2014 13:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 B0IyQ-9wytqZ for ; Tue, 26 Aug 2014 13:27:02 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA25E1A8836 for ; Tue, 26 Aug 2014 13:27:01 -0700 (PDT) Received: from [192.168.1.200] (p508F21F2.dip0.t-ipconnect.de [80.143.33.242]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AA3B91C0B3F53; Tue, 26 Aug 2014 22:26:59 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Tue, 26 Aug 2014 22:26:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> To: Barry Dingle X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-aUYNhNy2dEK2u7cAb9GdK6DlWA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:27:03 -0000 On 16 Aug 2014, at 14:01, Barry Dingle wrote: > I agree that error handling is missing from = draft-ietf-rtcweb-data-channel .=20 >=20 > Should the 'error' indications' in the proposed text be more specific? = That is, should the error indications indicate the type of error. (The = same error indication for all errors could be sent and be compliant with = the currently proposed text.)=20 There is no way in transporting an error indication... Best regards Michael >=20 > Note - I assume that you are proposing adding the new Section 6.7 to = draft-ietf-rtcweb-data-channel-11 . It already has a Section 6.7 titled = "Closing a channel". I assume you mean a new Section 6.8.=20 >=20 > Cheers, > /Barry Dingle >=20 >=20 >=20 >=20 > On Sat, Aug 16, 2014 at 4:44 PM, Gunnar Hellstrom = wrote: > We have discussed the lack of description of failure handling in = draft-ietf-rtcweb-data-channel a couple of times. >=20 > Explanations of mechanisms have been provided in mail answers that I = have not seen documented elsewhere, but they have not been introduced in = the draft. >=20 > I think that for specification and implementation of the WebRTC API, = there is a need for clear specification how the channels behave in = failure situations. >=20 > I suggest to insert a new chapter 6.7 in the draft with the following = contents. =20 >=20 > = -------------------------------------------------------------------Propose= d new section = 6.7-----------------------------------------------------------------------= -------------------- > 6.7 Transmission failure and error handling=20 >=20 > Failures can occur in an open channel by transmission error detection = and by SCTP watchdog error indications. > If transmission in a reliable channel fails, the association where the = channel belongs will be aborted. If all retries for a watchdog expires, = the corresponding association will be aborted. All channels in an = association that is aborted because of errors need to be closed by the = party detecting the failure. Network error indications shall be provided = to upper layers on all closed channels. >=20 > If retransmissions or transmission time is exceeded in a partially = reliable channel, the transmission SHALL be allowed to continue with = other data items. A transmission error indication SHALL be provided to = upper layers on that channel.=20 >=20 > If reception out-of order is detected from an SCTP channel for which = ordered transmission is requested, the receiver SHALL close the data = channel, and provide an transmission error indication to upper layers. =20= >=20 > If a message with an unsupported PPID is received or some logical = error is detected by the receiver, the receiver SHALL close the = corresponding data channel. =20 > = -----------------------------------------------------------------------end= of = proposal------------------------------------------------------------------= --------------------------------------------- >=20 > I am not sure about what the two last kinds of errors should result in = and hope that the experts can adjust the wording. >=20 > Regards >=20 > Gunnar > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se >=20 > On 2014-08-11 20:13, IESG Secretary wrote: >> The IESG would like to retract the current Last Call on the following=20= >> document: >>=20 >> - 'WebRTC Data Channels' >> as Proposed Standard >>=20 >> The document's state has been set back to "AD Evaluation." >>=20 >>=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 26 13:36:41 2014 Return-Path: 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 94A171A8876 for ; Tue, 26 Aug 2014 13:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 U7j80WVD6zHt for ; Tue, 26 Aug 2014 13:36:37 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01EB81A8871 for ; Tue, 26 Aug 2014 13:36:37 -0700 (PDT) Received: from [192.168.1.200] (p508F21F2.dip0.t-ipconnect.de [80.143.33.242]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3DF7B1C0B3F53; Tue, 26 Aug 2014 22:36:35 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53F1E05D.9040804@alvestrand.no> Date: Tue, 26 Aug 2014 22:36:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5H9ofzr-9zUFJn-mPFnT6U1NPYE Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 20:36:40 -0000 On 18 Aug 2014, at 13:15, Harald Alvestrand = wrote: > Picking up a single point.... >=20 > On 08/16/2014 08:44 AM, Gunnar Hellstrom wrote: >>=20 >> If a message with an unsupported PPID is received or some logical = error is detected by the receiver, the receiver SHALL close the = corresponding data channel.=20 >=20 > This struct me when thinking about the zero-length-data proposal: If = we ever want to add another such feature *without* explicitly = negotiating the use of the feature at setup time, we can't do this. >=20 > If we want the possibility of un-negotiated extensions, we HAVE to say = (somewhere) >=20 > If a message with an unsupported PPID is received, it is silently = ignored. >=20 > OTOH, if we're convinced we never need that kind of extensibility, any = way we do this is fine. Harald, I think it is important to specify how unsupported PPIDs handled. Either = close the data channel or ignore the message. What I don't understand how ignoring gives you extensibility. If one = sides sends a new PPID, and the other sides ignores it, the sender (at the SCTP level) thinks that = the message was received without any problem, since SCTP doesn't take the PPID into account. So = user messages are lost. Best regards Michael >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 26 14:22:17 2014 Return-Path: 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 63AC81A0367 for ; Tue, 26 Aug 2014 14:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 QvD7AWfwGSoC for ; Tue, 26 Aug 2014 14:22:14 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B374B1A8842 for ; Tue, 26 Aug 2014 14:22:13 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id el20so15756693lab.17 for ; Tue, 26 Aug 2014 14:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=75XaUHBFHSm7jVbV0d2TBwNjbsbDHaUuv+rv/KnEooc=; b=xuXzEII5Oolkqhkc2njNiaIFliIOxb8qFOE+HiqvSmL5ynqg9P4zqKwktD3uslhJ0+ 5myJ5DBvQg7Ra507l1tgXLJ2QCN1Dtyht7ws9K0F8u7Am/NBLYVhd9kvFX/xuJUHVUCx 0Yjuk0OHGd0kOnpFXPeu0Piy62XtZNHu8bSK0yQ9Asrj0KfERCpBJaqKZQakX503IYM7 /29S+eSd2jsKag230tqHtSkCqOhtrpooz5g8zcIP9/IvXaWFawJjbguuW3S7w2PHc8R5 ceDyR/DB4fwv6/0zoGowRT2VvdfYqVycKAZRuisMXTfo0Zr1mRM2AtuJQsIQHEK/Jz02 zqsA== MIME-Version: 1.0 X-Received: by 10.112.199.161 with SMTP id jl1mr9485464lbc.59.1409088131948; Tue, 26 Aug 2014 14:22:11 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 26 Aug 2014 14:22:11 -0700 (PDT) In-Reply-To: <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> Date: Tue, 26 Aug 2014 14:22:11 -0700 Message-ID: From: Martin Thomson To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F4SrrwOEu3QOY3B-O9O6JS4hJOM Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:22:16 -0000 On 26 August 2014 13:36, Michael Tuexen wrote: > What I don't understand how ignoring gives you extensibility. If one sides sends a new PPID, and > the other sides ignores it, the sender (at the SCTP level) thinks that the message was received > without any problem, since SCTP doesn't take the PPID into account. So user messages are lost. I think that the use of a new PPID can be negotiated prior to use, so there aren't big problems with any action recommended here. Resetting the stream might work, assuming that we can distinguish between an error and a graceful close correctly, that is. From nobody Tue Aug 26 14:23:30 2014 Return-Path: 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 324FA1A8773 for ; Tue, 26 Aug 2014 14:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 c3Uq7hXhqEVS for ; Tue, 26 Aug 2014 14:23:24 -0700 (PDT) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71711A871F for ; Tue, 26 Aug 2014 14:23:23 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTPS; Tue, 26 Aug 2014 23:22:56 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 43E273A1F9; Tue, 26 Aug 2014 23:23:14 +0200 (CEST) Message-ID: <53FCFAC3.3060809@omnitor.se> Date: Tue, 26 Aug 2014 23:23:15 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Tuexen References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <8446CEF8-D47A-41F2-AC80-3174E3721BAC@lurchi.franken.de> In-Reply-To: <8446CEF8-D47A-41F2-AC80-3174E3721BAC@lurchi.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/xSbUUg6maMQlUWHt1RIcfFX4V10 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:23:28 -0000 On 2014-08-26 22:26, Michael Tuexen wrote: > On 16 Aug 2014, at 08:44, Gunnar Hellstrom wrote: > >> We have discussed the lack of description of failure handling in draft-ietf-rtcweb-data-channel a couple of times. >> >> Explanations of mechanisms have been provided in mail answers that I have not seen documented elsewhere, but they have not been introduced in the draft. >> >> I think that for specification and implementation of the WebRTC API, there is a need for clear specification how the channels behave in failure situations. >> >> I suggest to insert a new chapter 6.7 in the draft with the following contents. > Hi Gunnar, > > see my comments in-line. Hi Michael and see my answers in-line > > Best regards > Michael >> -------------------------------------------------------------------Proposed new section 6.7------------------------------------------------------------------------------------------- >> 6.7 Transmission failure and error handling >> >> Failures can occur in an open channel by transmission error detection and by SCTP watchdog error indications. >> If transmission in a reliable channel fails, the association where the channel belongs will be aborted. If all retries for a watchdog expires, the corresponding association will be aborted. All channels in an association that is aborted because of errors need to be closed by the party detecting the failure. Network error indications shall be provided to upper layers on all closed channels. > I think we could change Section > 6.2. Association Setup > to > 6.2. Association Handling > and state there that if an association is terminated, for example due to error cases, all data channels are closed. I meant 6.8. I think a failure section is better placed after all sections on opening, closing and data transfer. Then it starts to be clear to the reader what can go wrong. And I think failure handling is so important that it is worth having a section on its own with a heading that can be found in the contents. When you say that all data channels are closed, can you then also tell how that is indicated to the application. I also think that the basic reasons for Association termination by error should be explained briefly in the data-channel specification, so that the reader does not need to dig through the SCTP RFC to try to find them. The watchdog failures and the exess retries in reliable channels, etc. I cannot understand why you want to avoid explaining the mechanisms. >> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with other data items. A transmission error indication SHALL be provided to upper layers on that channel. > I think the handling of the PR-SCTP stuff is clear. Whether this should be exposed in the API is a W3C issue, I think. I do not think it is clear. It merely mentions the names of the types of channels. The failure cases need also to be described. And, it is a case for the API description and the data-channel spec to be aligned. What the W3C API spec specify will happen in case of failure needs to be supported by the data-channel spec. I have made proposals to WebRTC as well. Please align. >> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel, and provide an transmission error indication to upper layers. > I think we discussed this at the IETF and the conclusion was that this kind of check is not done. Well, why not describe what happens, so that further questions or misunderstandings are avoided? You mean that what SCTP provides is also what the data-channel provides. >> If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel. > This text is already in Section 6.6. Yes, there is a paragraph saying: " If a message with an unsupported PPID is received or some error is detected by the receiver (for example, illegal ordering), the receiver SHOULD close the corresponding data channel. " Since my proposal was to create a separate failure handling section 6.8, my proposal would be to move all failure descriptions to 6.8, also the ones from 6.6. A question: You usually say that the Association is aborted in case of error and all its channels closed. But here it is said that just the channel is closed. Please clarify. Regards /Gunnar >> -----------------------------------------------------------------------end of proposal--------------------------------------------------------------------------------------------------------------- >> I am not sure about what the two last kinds of errors should result in and hope that the experts can adjust the wording. >> >> Regards >> >> Gunnar >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> >> On 2014-08-11 20:13, IESG Secretary wrote: >>> The IESG would like to retract the current Last Call on the following >>> document: >>> >>> - 'WebRTC Data Channels' >>> as Proposed Standard >>> >>> The document's state has been set back to "AD Evaluation." >>> >>> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 26 14:41:35 2014 Return-Path: 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 7EBE31A00E5 for ; Tue, 26 Aug 2014 14:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 Qi-WNh2qnS77 for ; Tue, 26 Aug 2014 14:41:33 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF061A00E2 for ; Tue, 26 Aug 2014 14:41:33 -0700 (PDT) Received: from [192.168.1.200] (p508F21F2.dip0.t-ipconnect.de [80.143.33.242]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7C5FC1C104DB9; Tue, 26 Aug 2014 23:41:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Tue, 26 Aug 2014 23:41:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4141AF-8A49-4BB5-A31B-7A5AF369530C@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4QdekMylu0upP9cyLximGkIeZYs Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:41:34 -0000 On 26 Aug 2014, at 23:22, Martin Thomson = wrote: > On 26 August 2014 13:36, Michael Tuexen > wrote: >> What I don't understand how ignoring gives you extensibility. If one = sides sends a new PPID, and >> the other sides ignores it, the sender (at the SCTP level) thinks = that the message was received >> without any problem, since SCTP doesn't take the PPID into account. = So user messages are lost. >=20 > I think that the use of a new PPID can be negotiated prior to use, so > there aren't big problems with any action recommended here. Resetting > the stream might work, assuming that we can distinguish between an > error and a graceful close correctly, that is. You can't. It is just closed, there is error indication included. Best regards Michael >=20 From nobody Tue Aug 26 14:44:39 2014 Return-Path: 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 9E4061A0176 for ; Tue, 26 Aug 2014 14:44:38 -0700 (PDT) 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 f7SxH_RrAO4k for ; Tue, 26 Aug 2014 14:44:37 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0ED1A0048 for ; Tue, 26 Aug 2014 14:44:37 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id jYgK1o00227AodY55Zkcpx; Tue, 26 Aug 2014 21:44:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta19.westchester.pa.mail.comcast.net with comcast id jZkc1o00R3Ge9ey3fZkcVG; Tue, 26 Aug 2014 21:44:36 +0000 Message-ID: <53FCFFC4.1090502@alum.mit.edu> Date: Tue, 26 Aug 2014 17:44:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> In-Reply-To: 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=q20140121; t=1409089476; bh=Mg7ZRVx2qtYzbt7aAJifOwUcRf0v0BqEgAVELCFKyaY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Dw+vdHKqalnvi3UE3rbacCI8Q5zbNuP+DEOy+pllUpm0zojxvY1pcncAYXpRd3puR ml3/ufR9pWGz1DNrvnRPCPXAi0LaUdNv8XCQAbsGQ1N2uQ9wSnjGRRdYmcxY2sCzYQ llr9CLzXsTrcTy6brCj/tnJkNgw/GiIIF/LKMd754yvBt0+B+h1LZSmMuxEIGi71ls rFIewCSjTQlO0J4jUAE/by1sfajB0MXH7i/EYZkz/vXNZiVk0kx8+j3PjXPqN6+mQE OxEtRV9PL16QBGkf0N+mRLMiZ4MtW9c3n0HEZN5QPSjYnf60bb5C8QzPChTSvOhZ8B //yniwo0DvnCA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LewH6Bw4PcwtcAriGXhXoGTUYBU Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 21:44:38 -0000 On 8/26/14 5:22 PM, Martin Thomson wrote: > On 26 August 2014 13:36, Michael Tuexen > wrote: >> What I don't understand how ignoring gives you extensibility. If one sides sends a new PPID, and >> the other sides ignores it, the sender (at the SCTP level) thinks that the message was received >> without any problem, since SCTP doesn't take the PPID into account. So user messages are lost. > > I think that the use of a new PPID can be negotiated prior to use, so > there aren't big problems with any action recommended here. Resetting > the stream might work, assuming that we can distinguish between an > error and a graceful close correctly, that is. There isn't currently any way to distinguish graceful close from a reset due to error is there? PPID 50 is currently being used just for DATA_CHANNEL_OPEN and Data_CHANNEL_ACK. But the message format has made provision for 512 different message types. Some others could be used, now or in the future, for other housekeeping, such as giving a reason for a reset. One approach would be to define DATA_CHANNEL_CLOSE, and specify that it be used just before reset when the close is graceful. Thanks, Paul From nobody Tue Aug 26 15:01:07 2014 Return-Path: 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 2A49F1A016C for ; Tue, 26 Aug 2014 15:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 fNMJjX57U2h9 for ; Tue, 26 Aug 2014 15:01:03 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8551A01BA for ; Tue, 26 Aug 2014 15:01:02 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so13070954lab.2 for ; Tue, 26 Aug 2014 15:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yeUHDcavtjwJf0diPec+41OpB0XOUmRNr6/owqBqyZs=; b=HeEDPnGcTDGtPTlgdJI53E1IlbzKgh6yLuUxuDvpedOno+xqq00Xh0pDcPuY+qrfPt Mqb2p/1zKhXtgjUdNGb6t0nGAWcchoBSYejPrMo6U0VocZPwQ+KzUCHdwTulK0Ya7+Ro TgmRckp+OsxfBHFz2VPkb/4+U6asm2SLz8eeW7k2AoPQikEiJgkc8VEKtVJsYVQYZLGg 3/wzroFJflbjXMwvY6zNcnh2+eVRVdBD6loxOzMxorGqlPNcT1aCfxz/ZWcK7VEl0LJg MnpFi11Z6coRO67JZkJkTXKi+DEPTtLhvz2FCNW2e8qgWhlLinnLi1RHMSNveQcgxQuy ejUA== MIME-Version: 1.0 X-Received: by 10.152.87.139 with SMTP id ay11mr8567294lab.38.1409090460822; Tue, 26 Aug 2014 15:01:00 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 26 Aug 2014 15:01:00 -0700 (PDT) In-Reply-To: <53FCFFC4.1090502@alum.mit.edu> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FCFFC4.1090502@alum.mit.edu> Date: Tue, 26 Aug 2014 15:01:00 -0700 Message-ID: From: Martin Thomson To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wXW1AhyqsecI-tqePqdiBS_6y5M Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 22:01:04 -0000 On 26 August 2014 14:44, Paul Kyzivat wrote: > One approach would be to define DATA_CHANNEL_CLOSE, and specify that it be > used just before reset when the close is graceful. Or define a DATA_CHANNEL_ERROR, which would let you explain why. Assuming that SCTP doesn't suffer from the same problems TCP does with sending just prior to a close. From nobody Wed Aug 27 04:08:12 2014 Return-Path: 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 E453B1A064A for ; Wed, 27 Aug 2014 04:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 IZtQ96wxQEYG for ; Wed, 27 Aug 2014 04:07:47 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7601A0642 for ; Wed, 27 Aug 2014 04:07:47 -0700 (PDT) Received: from [192.168.1.200] (p508F1C1B.dip0.t-ipconnect.de [80.143.28.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3497A1C104DFB; Wed, 27 Aug 2014 13:07:44 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53FCFFC4.1090502@alum.mit.edu> Date: Wed, 27 Aug 2014 13:07:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FCFFC4.1090502@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GG1A047z2Mlva_xwxW3RfuCspxA Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 11:07:56 -0000 On 26 Aug 2014, at 23:44, Paul Kyzivat wrote: > On 8/26/14 5:22 PM, Martin Thomson wrote: >> On 26 August 2014 13:36, Michael Tuexen >> wrote: >>> What I don't understand how ignoring gives you extensibility. If one = sides sends a new PPID, and >>> the other sides ignores it, the sender (at the SCTP level) thinks = that the message was received >>> without any problem, since SCTP doesn't take the PPID into account. = So user messages are lost. >>=20 >> I think that the use of a new PPID can be negotiated prior to use, so >> there aren't big problems with any action recommended here. = Resetting >> the stream might work, assuming that we can distinguish between an >> error and a graceful close correctly, that is. >=20 > There isn't currently any way to distinguish graceful close from a = reset due to error is there? >=20 > PPID 50 is currently being used just for DATA_CHANNEL_OPEN and = Data_CHANNEL_ACK. But the message format has made provision for 512 = different message types. Some others could be used, now or in the = future, for other housekeeping, such as giving a reason for a reset. >=20 > One approach would be to define DATA_CHANNEL_CLOSE, and specify that = it be used just before reset when the close is graceful. What you are suggesting is to use the Data Channel Establishment = Protocol also for error signalling... This doesn't fit since for the error it doesn't = matter whether the channel was established with DCEP or by any other mechanism. The way would be to define error messages with a different PPID and = define the message format. If I remember it correctly, we discussed this at an IETF = meeting and the conclusion was to not have such messages... Is the WG now changing its mind? After WG LC? Best regards Michael >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Wed Aug 27 04:09:47 2014 Return-Path: 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 E6DDD1A05F5 for ; Wed, 27 Aug 2014 04:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 yH7MEshNnLjd for ; Wed, 27 Aug 2014 04:09:37 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230321A05C0 for ; Wed, 27 Aug 2014 04:09:37 -0700 (PDT) Received: from [192.168.1.200] (p508F1C1B.dip0.t-ipconnect.de [80.143.28.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7DBB11C104DFB; Wed, 27 Aug 2014 13:09:34 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Wed, 27 Aug 2014 13:09:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <56B09C3F-99A8-4942-A6F9-F90F48E14CDF@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FCFFC4.1090502@alum.mit.edu> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-ik_N9qwdsnFc35LrNMPOyo3NCE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 11:09:39 -0000 On 27 Aug 2014, at 00:01, Martin Thomson wrote: > On 26 August 2014 14:44, Paul Kyzivat wrote: >> One approach would be to define DATA_CHANNEL_CLOSE, and specify that it be >> used just before reset when the close is graceful. > > Or define a DATA_CHANNEL_ERROR, which would let you explain why. This would require defining a simple packet format and register a PPID for it. However, this was discussed in the past and the result was that no error messages were wanted... Is this conclusion not valid anymore? > Assuming that SCTP doesn't suffer from the same problems TCP does with > sending just prior to a close. What TCP problems are you referring to? Best regards Michael > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Aug 27 04:16:59 2014 Return-Path: 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 84D601A0647 for ; Wed, 27 Aug 2014 04:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 Pg2Nxdqa9PG7 for ; Wed, 27 Aug 2014 04:16:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB8B1A034D for ; Wed, 27 Aug 2014 04:16:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 679887C3FEF; Wed, 27 Aug 2014 13:16:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAmeQejb5E6b; Wed, 27 Aug 2014 13:16:51 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:7cd6:dc81:94a3:b548] (unknown [IPv6:2001:470:de0a:27:7cd6:dc81:94a3:b548]) by mork.alvestrand.no (Postfix) with ESMTPSA id 599A47C05BE; Wed, 27 Aug 2014 13:16:51 +0200 (CEST) Message-ID: <53FDBE22.8080609@alvestrand.no> Date: Wed, 27 Aug 2014 13:16:50 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Martin Thomson , Michael Tuexen References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/KwgOWmZPJh3qDfVp38PdDyTQhe0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 11:16:57 -0000 On 08/26/2014 11:22 PM, Martin Thomson wrote: > On 26 August 2014 13:36, Michael Tuexen > wrote: >> What I don't understand how ignoring gives you extensibility. If one sides sends a new PPID, and >> the other sides ignores it, the sender (at the SCTP level) thinks that the message was received >> without any problem, since SCTP doesn't take the PPID into account. So user messages are lost. > I think that the use of a new PPID can be negotiated prior to use, so > there aren't big problems with any action recommended here. Resetting > the stream might work, assuming that we can distinguish between an > error and a graceful close correctly, that is. If there is negotiation, there is no problem. If there is no negotiation, starting to use the new feature will either lead to ignored messages or lead to a crashed connection. Ignored messages are not a problem if they form part of an ignorable extension (for instance if someone decided to once in a while send checksums over all the data sent so far - doesn't matter to those that don't understand it, since it doesn't carry any extra data). Crashed connections are usually a problem, so that will mean "no unnegotiated extensions, ever". I'm happy with either way of doing it, as long as we're explicit about it. From nobody Wed Aug 27 04:39:52 2014 Return-Path: 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 A5DD41A0646 for ; Wed, 27 Aug 2014 04:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 m3sbNQnjNP7c for ; Wed, 27 Aug 2014 04:39:50 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1CB1A0655 for ; Wed, 27 Aug 2014 04:39:49 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 42EAE9F7FF5F2; Wed, 27 Aug 2014 11:39:47 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s7RBdIZZ014277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 07:39:48 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 27 Aug 2014 07:38:56 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , Martin Thomson , Michael Tuexen Thread-Topic: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) Thread-Index: AQHPwW1+7TUn3aZI7UycBQe10zH565vjp8uAgADpMwD//79ZMA== Date: Wed, 27 Aug 2014 11:38:55 +0000 Message-ID: References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FDBE22.8080609@alvestrand.no> In-Reply-To: <53FDBE22.8080609@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4i3LZCEnjDDm3oBwtD-xBq7bEgY Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 11:39:51 -0000 > If there is negotiation, there is no problem. >=20 > If there is no negotiation, starting to use the new feature will either > lead to ignored messages or lead to a crashed connection. >=20 > Ignored messages are not a problem if they form part of an ignorable > extension (for instance if someone decided to once in a while send > checksums over all the data sent so far - doesn't matter to those that > don't understand it, since it doesn't carry any extra data). >=20 > Crashed connections are usually a problem, so that will mean "no > unnegotiated extensions, ever". >=20 > I'm happy with either way of doing it, as long as we're explicit about it= . +1 for negotiation. I think it is highly preferred to negotiate these additional PPIDs in all c= ases as=20 anything other than a binary or text PPID is additional capability. Use of= any additional capabilities must at least be negotiated using JSEP.=20 One element of negotiation could be "what must be done for unrecognized PPI= Ds?": ignore them or abort the connection. From nobody Wed Aug 27 05:18:44 2014 Return-Path: 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 BCA081A0663 for ; Wed, 27 Aug 2014 05:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 OjrBxoLZk9cn for ; Wed, 27 Aug 2014 05:18:38 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9943C1A064A for ; Wed, 27 Aug 2014 05:18:37 -0700 (PDT) Received: from [192.168.1.200] (p508F1C1B.dip0.t-ipconnect.de [80.143.28.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 53C0D1C104DFB; Wed, 27 Aug 2014 14:18:34 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53FCFAC3.3060809@omnitor.se> Date: Wed, 27 Aug 2014 14:18:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6725A156-7B07-48B8-AD48-08416608A780@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <8446CEF8-D47A-41F2-AC80-3174E3721BAC@lurchi.franken.de> <53FCFAC3.3060809@omnitor.se> To: Gunnar Hellstrom X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/t2tFw6Ameuuvob2jA6P7YIM0ENo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-channel failure handling description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:18:42 -0000 On 26 Aug 2014, at 23:23, Gunnar Hellstrom = wrote: > On 2014-08-26 22:26, Michael Tuexen wrote: >> On 16 Aug 2014, at 08:44, Gunnar Hellstrom = wrote: >>=20 >>> We have discussed the lack of description of failure handling in = draft-ietf-rtcweb-data-channel a couple of times. >>>=20 >>> Explanations of mechanisms have been provided in mail answers that I = have not seen documented elsewhere, but they have not been introduced in = the draft. >>>=20 >>> I think that for specification and implementation of the WebRTC API, = there is a need for clear specification how the channels behave in = failure situations. >>>=20 >>> I suggest to insert a new chapter 6.7 in the draft with the = following contents. >> Hi Gunnar, >>=20 >> see my comments in-line. > Hi Michael > and see my answers in-line >>=20 >> Best regards >> Michael >>> = -------------------------------------------------------------------Propose= d new section = 6.7-----------------------------------------------------------------------= -------------------- >>> 6.7 Transmission failure and error handling >>>=20 >>> Failures can occur in an open channel by transmission error = detection and by SCTP watchdog error indications. >>> If transmission in a reliable channel fails, the association where = the channel belongs will be aborted. If all retries for a watchdog = expires, the corresponding association will be aborted. All channels in = an association that is aborted because of errors need to be closed by = the party detecting the failure. Network error indications shall be = provided to upper layers on all closed channels. >> I think we could change Section >> 6.2. Association Setup >> to >> 6.2. Association Handling >> and state there that if an association is terminated, for example due = to error cases, all data channels are closed. > I meant 6.8. > I think a failure section is better placed after all sections on = opening, closing and data transfer. Then it starts to be clear to the = reader what can go wrong. > And I think failure handling is so important that it is worth having a = section on its own with a heading that can be found in the contents. OK. What do others think? Should error handling be moved into a separate = section? >=20 > When you say that all data channels are closed, can you then also tell = how that is indicated to the application. I consider this an API issue. When looking at http://dev.w3.org/2011/webrtc/editor/webrtc.html wouldn't that mean to fire onclose() on all data channels of the peer = connection? >=20 > I also think that the basic reasons for Association termination by = error should be explained briefly in the data-channel specification, so = that the reader does not need to dig through the SCTP RFC to try to find = them. The watchdog failures and the exess retries in reliable channels, = etc. I cannot understand why you want to avoid explaining the = mechanisms. Could go into a failure section, if the WG agrees that we want to have = some... Any opinions? >>> If retransmissions or transmission time is exceeded in a partially = reliable channel, the transmission SHALL be allowed to continue with = other data items. A transmission error indication SHALL be provided to = upper layers on that channel. >> I think the handling of the PR-SCTP stuff is clear. Whether this = should be exposed in the API is a W3C issue, I think. > I do not think it is clear. It merely mentions the names of the types = of channels. The failure cases need also to be described. > And, it is a case for the API description and the data-channel spec to = be aligned. What the W3C API spec specify will happen in case of failure = needs to be supported by the data-channel spec. I have made proposals to = WebRTC as well. Please align. =46rom an SCTP point of view, you can get a notification at the sender = side if a message is abandoned, but not at the receiver side. I don't see that such an information is exposed to the JS application... >>> If reception out-of order is detected from an SCTP channel for which = ordered transmission is requested, the receiver SHALL close the data = channel, and provide an transmission error indication to upper layers. >> I think we discussed this at the IETF and the conclusion was that = this kind of check is not done. > Well, why not describe what happens, so that further questions or = misunderstandings are avoided? You mean that what SCTP provides is also = what the data-channel provides. So isn't the text cited by you below not enough? >=20 >>> If a message with an unsupported PPID is received or some logical = error is detected by the receiver, the receiver SHALL close the = corresponding data channel. >> This text is already in Section 6.6. > Yes, there is a paragraph saying: > " >=20 > If a message with an unsupported PPID is received or some error is > detected by the receiver (for example, illegal ordering), the > receiver SHOULD close the corresponding data channel. > " > Since my proposal was to create a separate failure handling section = 6.8, my proposal would be to move all failure descriptions to > 6.8, also the ones from 6.6. Understood. Can we get some agreement if we want this or not in the WG? >=20 > A question: You usually say that the Association is aborted in case of = error and all its channels closed. > But here it is said that just the channel is closed. Please clarify. That is a good point... When I wrote this sentence, I was thinking about = errors like illegal ordering (which means the receiver expects ordered but got = unordered, or expects reliable transfer, but sees SSN holes...). I was not thinking about an = indication that the association is gone. So what about: If a message with an unsupported PPID is received or some error = condition related to the received message is detected by the receiver (for example, illegal ordering), the receiver SHOULD close the corresponding data channel. Best regards Michael >=20 >=20 > Regards > /Gunnar >=20 >>> = -----------------------------------------------------------------------end= of = proposal------------------------------------------------------------------= --------------------------------------------- >>> I am not sure about what the two last kinds of errors should result = in and hope that the experts can adjust the wording. >>>=20 >>> Regards >>>=20 >>> Gunnar >>> Gunnar Hellstr=F6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>>=20 >>> On 2014-08-11 20:13, IESG Secretary wrote: >>>> The IESG would like to retract the current Last Call on the = following >>>> document: >>>>=20 >>>> - 'WebRTC Data Channels' >>>> as Proposed Standard >>>>=20 >>>> The document's state has been set back to "AD Evaluation." >>>>=20 >>>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 From nobody Wed Aug 27 05:51:04 2014 Return-Path: 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 ECDDD1A069A for ; Wed, 27 Aug 2014 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 yaTjlVW5bW7t for ; Wed, 27 Aug 2014 05:51:02 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3695A1A069D for ; Wed, 27 Aug 2014 05:51:01 -0700 (PDT) Received: from [192.168.1.200] (p508F1C1B.dip0.t-ipconnect.de [80.143.28.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 30A191C104E65; Wed, 27 Aug 2014 14:50:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <53FDBE22.8080609@alvestrand.no> Date: Wed, 27 Aug 2014 14:50:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2157C46C-E546-4BA1-BCB3-4A6B2B242104@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FDBE22.8080609@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/k_HM7R42LruHibqvVtFHbTiNuDQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:51:03 -0000 On 27 Aug 2014, at 13:16, Harald Alvestrand = wrote: > On 08/26/2014 11:22 PM, Martin Thomson wrote: >> On 26 August 2014 13:36, Michael Tuexen >> wrote: >>> What I don't understand how ignoring gives you extensibility. If one = sides sends a new PPID, and >>> the other sides ignores it, the sender (at the SCTP level) thinks = that the message was received >>> without any problem, since SCTP doesn't take the PPID into account. = So user messages are lost. >> I think that the use of a new PPID can be negotiated prior to use, so >> there aren't big problems with any action recommended here. = Resetting >> the stream might work, assuming that we can distinguish between an >> error and a graceful close correctly, that is. >=20 > If there is negotiation, there is no problem. >=20 > If there is no negotiation, starting to use the new feature will = either lead to ignored messages or lead to a crashed connection. >=20 > Ignored messages are not a problem if they form part of an ignorable = extension (for instance if someone decided to once in a while send = checksums over all the data sent so far - doesn't matter to those that = don't understand it, since it doesn't carry any extra data). >=20 > Crashed connections are usually a problem, so that will mean "no = unnegotiated extensions, ever". >=20 > I'm happy with either way of doing it, as long as we're explicit about = it. I agree with you, don't have a preference. Up to now the consensus was = to close the channel... I can add a sentence to make clear that this means no unnegotiated = extensions. Best regards Michael >=20 >=20 >=20 >=20 From nobody Wed Aug 27 05:52:59 2014 Return-Path: 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 968701A0680 for ; Wed, 27 Aug 2014 05:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 EsSxJvomurUc for ; Wed, 27 Aug 2014 05:52:57 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631E31A0671 for ; Wed, 27 Aug 2014 05:52:57 -0700 (PDT) Received: from [192.168.1.200] (p508F1C1B.dip0.t-ipconnect.de [80.143.28.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F34011C104E65; Wed, 27 Aug 2014 14:52:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Wed, 27 Aug 2014 14:52:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6104CD64-496D-406F-9067-A5226157B9FD@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FDBE22.8080609@alvestrand.no> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/_JQRVYnyH3ldaGaqp66j7pO7IqI Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 12:52:58 -0000 On 27 Aug 2014, at 13:38, Makaraju, Maridi Raju (Raju) = wrote: >> If there is negotiation, there is no problem. >>=20 >> If there is no negotiation, starting to use the new feature will = either >> lead to ignored messages or lead to a crashed connection. >>=20 >> Ignored messages are not a problem if they form part of an ignorable >> extension (for instance if someone decided to once in a while send >> checksums over all the data sent so far - doesn't matter to those = that >> don't understand it, since it doesn't carry any extra data). >>=20 >> Crashed connections are usually a problem, so that will mean "no >> unnegotiated extensions, ever". >>=20 >> I'm happy with either way of doing it, as long as we're explicit = about it. > > +1 for negotiation. > I think it is highly preferred to negotiate these additional PPIDs in = all cases as=20 > anything other than a binary or text PPID is additional capability. = Use of any additional > capabilities must at least be negotiated using JSEP.=20 > One element of negotiation could be "what must be done for = unrecognized PPIDs?": ignore them or > abort the connection. Do we really need to negotiate that? The consensus up to now was to = close the channel. So if you negotiate the PPIDs and honor the result, you will never run = into this issue... Best regards Michael >=20 > >=20 >=20 From nobody Wed Aug 27 11:46:38 2014 Return-Path: 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 423B91A6EF8 for ; Wed, 27 Aug 2014 11:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 gPt1SAhzIzbZ for ; Wed, 27 Aug 2014 11:46:36 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA28D1A007D for ; Wed, 27 Aug 2014 11:46:35 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id u10so971389lbd.32 for ; Wed, 27 Aug 2014 11:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kh+1oExiRLXD2ssMaBVAmSIdlSTf6jc2cF2oBV/v52o=; b=p+rYDYL/02goi/NnRRApmrXdCa8Zs/3cxyqbuuGK6UyrHk6s9FNipyk0mGjpz3Qgcd dEXzBStWXuiPhXfQBhZ9GX+2ULeu8BQErRU/74WPfe8EuK6rVF39ZWGwDykgYk00hMYV cSosFN5kXDReQPpCaEe501DkAI8C4Rm8B870wKBFpTDFuMGo7lKjuElhfj8AaZDAy5vu ZO1S/1B0RO4HyWwGa7R41mqEglMf1qAGNli0WePof1+liv3C5Mu3NfrYEglg1LqK65P/ sUkgZEUAYSAvT1iN/eCbmfh0boh/kywQxRvYCW8+a2jj14yrhxZ7umV1iHegEp92TjYg 0ayA== MIME-Version: 1.0 X-Received: by 10.112.34.78 with SMTP id x14mr34897495lbi.38.1409165193914; Wed, 27 Aug 2014 11:46:33 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 27 Aug 2014 11:46:33 -0700 (PDT) In-Reply-To: <56B09C3F-99A8-4942-A6F9-F90F48E14CDF@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FCFFC4.1090502@alum.mit.edu> <56B09C3F-99A8-4942-A6F9-F90F48E14CDF@lurchi.franken.de> Date: Wed, 27 Aug 2014 11:46:33 -0700 Message-ID: From: Martin Thomson To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/TsjI152z9iMjnlapZoNBKwVd6eE Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 18:46:37 -0000 On 27 August 2014 04:09, Michael Tuexen wrote: > This would require defining a simple packet format and register a PPID for > it. However, this was discussed in the past and the result was that no > error messages were wanted... Is this conclusion not valid anymore? I have no recollection of discussing this, but will admit to not reading every email on the topic. >> Assuming that SCTP doesn't suffer from the same problems TCP does with >> sending just prior to a close. > What TCP problems are you referring to? The sort where you send data followed immediately by a FIN (or RST) and find that the data disappeared. c.f., http://tools.ietf.org/html/rfc7230#page-57 (top) From nobody Wed Aug 27 12:09:38 2014 Return-Path: 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 8DB3C1A00F2 for ; Wed, 27 Aug 2014 12:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 Fvy0pXzClSYM for ; Wed, 27 Aug 2014 12:09:36 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741511A0097 for ; Wed, 27 Aug 2014 12:09:36 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id B5B7A220E8E80; Wed, 27 Aug 2014 19:09:32 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s7RJ93ji022313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 15:09:33 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 27 Aug 2014 15:08:48 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Michael Tuexen Thread-Topic: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) Thread-Index: AQHPwW1+7TUn3aZI7UycBQe10zH565vjp8uAgADpMwD//79ZMIAAW3uAgAAlAEA= Date: Wed, 27 Aug 2014 19:08:47 +0000 Message-ID: References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FDBE22.8080609@alvestrand.no> <6104CD64-496D-406F-9067-A5226157B9FD@lurchi.franken.de> In-Reply-To: <6104CD64-496D-406F-9067-A5226157B9FD@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qvfHH8RKclmPxhXbpmKPkaPYBu4 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:09:37 -0000 > Do we really need to negotiate that? The consensus up to now was to close > the channel. > So if you negotiate the PPIDs and honor the result, you will never run in= to > this issue... I like your response to Herald: "I can add a sentence to make clear that th= is means no unnegotiated extensions." So, all un-negotiated extensions results in closing the data channel; which= leaves possibility for negotiating extensions in future and handling them appropriately. From nobody Wed Aug 27 12:40:56 2014 Return-Path: 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 EBBB01A0173 for ; Wed, 27 Aug 2014 12:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, 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 X_SbBHW-ufaT for ; Wed, 27 Aug 2014 12:40:54 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230491A0144 for ; Wed, 27 Aug 2014 12:40:54 -0700 (PDT) Received: from [192.168.1.200] (p508F1C1B.dip0.t-ipconnect.de [80.143.28.27]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 44F8C1C104FA4; Wed, 27 Aug 2014 21:40:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Wed, 27 Aug 2014 21:40:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55B3350B-0367-4634-A46D-E349CEF6F8F0@lurchi.franken.de> References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FCFFC4.1090502@alum.mit.edu> <56B09C3F-99A8-4942-A6F9-F90F48E14CDF@lurchi.franken.de> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/kuRP3ydNjlb8Y2f9re467tpeYwc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 19:40:56 -0000 On 27 Aug 2014, at 20:46, Martin Thomson = wrote: > On 27 August 2014 04:09, Michael Tuexen > wrote: >> This would require defining a simple packet format and register a = PPID for >> it. However, this was discussed in the past and the result was that = no >> error messages were wanted... Is this conclusion not valid anymore? >=20 > I have no recollection of discussing this, but will admit to not > reading every email on the topic. I think this was discussed at an IETF meeting... Basically the questions = was if we want to define any protocol for data channels. DCEP is not covered = by this question, since it is a protocol to set channels up. >=20 >>> Assuming that SCTP doesn't suffer from the same problems TCP does = with >>> sending just prior to a close. >> What TCP problems are you referring to? >=20 > The sort where you send data followed immediately by a FIN (or RST) > and find that the data disappeared. c.f., > http://tools.ietf.org/html/rfc7230#page-57 (top) No, SCTP does not have this problem when resetting streams. Messages get = delivered. However, what can happen is that when using an unordered channel, that = the message sent last before resetting the channel, is not the one received as the = last message before the SCTP Stream Reset request is received... Best regards Michael >=20 From nobody Wed Aug 27 14:07:38 2014 Return-Path: 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 B1A451A0141 for ; Wed, 27 Aug 2014 14:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 5vbX2BDVgJxl for ; Wed, 27 Aug 2014 14:07:33 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7E41A0303 for ; Wed, 27 Aug 2014 14:07:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 325C17C3FB7 for ; Wed, 27 Aug 2014 23:07:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqA36GQLpbeU for ; Wed, 27 Aug 2014 23:07:31 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:e834:a0af:ef9b:c62c] (unknown [IPv6:2001:470:de0a:27:e834:a0af:ef9b:c62c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 222AD7C3B5E for ; Wed, 27 Aug 2014 23:07:31 +0200 (CEST) Message-ID: <53FE4890.5020808@alvestrand.no> Date: Wed, 27 Aug 2014 23:07:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FCFFC4.1090502@alum.mit.edu> <56B09C3F-99A8-4942-A6F9-F90F48E14CDF@lurchi.franken.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fwcP68WugRckoELfuraEvqiGWqw Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 21:07:37 -0000 On 08/27/2014 08:46 PM, Martin Thomson wrote: > On 27 August 2014 04:09, Michael Tuexen > wrote: >> This would require defining a simple packet format and register a PPID for >> it. However, this was discussed in the past and the result was that no >> error messages were wanted... Is this conclusion not valid anymore? > I have no recollection of discussing this, but will admit to not > reading every email on the topic. > >>> Assuming that SCTP doesn't suffer from the same problems TCP does with >>> sending just prior to a close. >> What TCP problems are you referring to? > The sort where you send data followed immediately by a FIN (or RST) > and find that the data disappeared. c.f., > http://tools.ietf.org/html/rfc7230#page-57 (top) Re TCP: I think the RFC 7230 problem is an application (or API) problem, not a protocol problem. This only happens if a data receiver uses the POSIX close(3) interface to close a socket, instead of shutting it down gently (with shutdown(2) using SHUT_WR, I think). Anyone who sends RST is OK with data being lost. RST is a signal that "I'm shutting this stuff down, I don't care whether your data arrived or not". > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Wed Aug 27 14:22:31 2014 Return-Path: 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 623961A0141 for ; Wed, 27 Aug 2014 14:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 asfF-1JIPnQ0 for ; Wed, 27 Aug 2014 14:22:28 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54531A0704 for ; Wed, 27 Aug 2014 14:22:27 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTPS for ; Wed, 27 Aug 2014 23:22:23 +0200 (CEST) Received: from [192.168.2.41] (81-224-110-16-no227.business.telia.com [81.224.110.16]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 3D1AE3A1F4 for ; Wed, 27 Aug 2014 23:22:13 +0200 (CEST) Message-ID: <53FE4C08.5050605@omnitor.se> Date: Wed, 27 Aug 2014 23:22:16 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20140811181357.613.72705.idtracker@ietfa.amsl.com> <53EEFDD3.6040607@omnitor.se> <53F1E05D.9040804@alvestrand.no> <5AC6FE2A-23B1-4BDE-ABE0-2D64AE750F60@lurchi.franken.de> <53FDBE22.8080609@alvestrand.no> <6104CD64-496D-406F-9067-A5226157B9FD@lurchi.franken.de> In-Reply-To: <6104CD64-496D-406F-9067-A5226157B9FD@lurchi.franken.de> Content-Type: multipart/alternative; boundary="------------080705080602010203080600" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yATaZVoUWLfYEhrg7gSVTWUwJ7Y Subject: Re: [rtcweb] Unsupported PPID (Re: draft-ietf-rtcweb-data-channel failure handling description) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 21:22:30 -0000 This is a multi-part message in MIME format. --------------080705080602010203080600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There is an ambition to be as close as possible to Websocket. Websocket is specified in RFC 6455. It has an negotiation mechanism for extensions. See chapter 9 And it closes channels in case of reception tht is not according to the protocol. ( e.g. Section 10.7 ) So, it could be wise to copy that behavior, to maintain the ambitions of keeping these data channel types similar. /Gunnar ------------------------------------------------------------------------ On 2014-08-27 14:52, Michael Tuexen wrote: > On 27 Aug 2014, at 13:38, Makaraju, Maridi Raju (Raju) wrote: > >>> If there is negotiation, there is no problem. >>> >>> If there is no negotiation, starting to use the new feature will either >>> lead to ignored messages or lead to a crashed connection. >>> >>> Ignored messages are not a problem if they form part of an ignorable >>> extension (for instance if someone decided to once in a while send >>> checksums over all the data sent so far - doesn't matter to those that >>> don't understand it, since it doesn't carry any extra data). >>> >>> Crashed connections are usually a problem, so that will mean "no >>> unnegotiated extensions, ever". >>> >>> I'm happy with either way of doing it, as long as we're explicit about it. >> >> +1 for negotiation. >> I think it is highly preferred to negotiate these additional PPIDs in all cases as >> anything other than a binary or text PPID is additional capability. Use of any additional >> capabilities must at least be negotiated using JSEP. >> One element of negotiation could be "what must be done for unrecognized PPIDs?": ignore them or >> abort the connection. > Do we really need to negotiate that? The consensus up to now was to close the channel. > So if you negotiate the PPIDs and honor the result, you will never run into this issue... > > Best regards > Michael >> >> >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080705080602010203080600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There is an ambition to be as close as possible to Websocket.
Websocket is specified in RFC 6455.
It has an negotiation mechanism for extensions.  See chapter 9
And it closes channels in case of reception tht is not according to the protocol. ( e.g. Section 10.7 )

So, it could be wise to copy that behavior, to maintain the ambitions of keeping these data channel types similar.

/Gunnar

On 2014-08-27 14:52, Michael Tuexen wrote:
On 27 Aug 2014, at 13:38, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:


If there is negotiation, there is no problem.

If there is no negotiation, starting to use the new feature will either
lead to ignored messages or lead to a crashed connection.

Ignored messages are not a problem if they form part of an ignorable
extension (for instance if someone decided to once in a while send
checksums over all the data sent so far - doesn't matter to those that
don't understand it, since it doesn't carry any extra data).

Crashed connections are usually a problem, so that will mean "no
unnegotiated extensions, ever".

I'm happy with either way of doing it, as long as we're explicit about it.

<Raju>
+1 for negotiation.
I think it is highly preferred to negotiate these additional PPIDs in all cases as 
anything other than a binary or text  PPID is additional capability. Use of any additional
capabilities must at least be negotiated using JSEP. 
One element of negotiation could be "what must be done for unrecognized PPIDs?": ignore them or
abort the connection.

Do we really need to negotiate that? The consensus up to now was to close the channel.
So if you negotiate the PPIDs and honor the result, you will never run into this issue...

Best regards
Michael

</Raju>



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------080705080602010203080600-- From nobody Fri Aug 29 00:20:53 2014 Return-Path: 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 777C91A0672 for ; Fri, 29 Aug 2014 00:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 qehHeHKUWCua for ; Fri, 29 Aug 2014 00:20:50 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B39A91A0677 for ; Fri, 29 Aug 2014 00:20:49 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-31-540029cfc51f Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.60.21334.FC920045; Fri, 29 Aug 2014 09:20:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Fri, 29 Aug 2014 09:20:47 +0200 From: Christer Holmberg To: Martin Thomson , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHPwIhKn1GSXc7NQ0qIq+/SSCMFtZvheJWAgAAB7QCAABscAIABAUuAgAA/XoCAADZ6AIAEJH4Q Date: Fri, 29 Aug 2014 07:20:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D431848@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje4FTYYQgyMvWC2unfnHaPFns5/F 2n/t7A7MHjtn3WX3WLLkJ1MAUxSXTUpqTmZZapG+XQJXRmvDE+aCK+wVvw7YNTDOZuti5OSQ EDCROH3vDyOELSZx4d56oDgXh5DAUUaJ7taZUM4SRomrjWuAHA4ONgELie5/2iANIgIJEjdu TWEHsZkF1CXuLD4HZgsLBEos/vmLFaImSGJa50xmkFYRgSiJthWxICaLgKrElA0FICavgK/E so4YiEXfuCU+nDrAAtLJCTRl/ucdYBMZgU77fmoNE8QmcYlbT+YzQZwsILFkz3lmCFtU4uXj f6wQtqLE1enLoep1JBbs/sQGYWtLLFv4GqyeV0BQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBk WcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGEEHt/zW3cG4+rXjIUYBDkYlHt4F9/4HC7Em lhVX5h5ilOZgURLnXXRuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxnXLy0/MV00X1OMz cj0+TfLlulj3ksgLObN/fmm0vXB2j4Z5dkW/xIv/Qv4KZYqrqkSTal+cl+TxaN1dKJzlv1R3 y9zHSVqGTyqnS9+63cR8ptjLvoJ58lnLXfOd2cteLtx4uN/zwvl7n244Hjlzq3yGbXvXos0/ 1cPUOgTUzX0q802cPz7IV2Ipzkg01GIuKk4EADPu2/6BAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DVdRfpqnqRUk7HCBpIhL-apwooQ Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 07:20:51 -0000 Hi, >> Consent freshness is applicable to any WebRTC entity supporting full=20 >> ICE. A WebRTC browser/device as defined in the transport and overview=20 >> drafts support full ICE, so perform consent freshness. The=20 >> requirements for other WebRTC entities, including WebRTC gateway, is=20 >> yet to be fully specified, and the document that specifies them would=20 >> also specify whether they support full ICE or not (and hence whether the= y perform consent freshness or not). > > Actually, that's probably the best approach: note that this applies - and= can be useful for - any ICE implementation. And leave=20 > it at that for this document. The transports or security docs might make= some statements about mandating this mechanism. As long as the WebRTC entity supporting full ICE does not assume that the r= emote WebRTC entity (e.g. a WebRTC gateway) also supports full ICE (read: w= on't perform consent freshness). Regards, Christer From nobody Fri Aug 29 11:08:52 2014 Return-Path: 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 E91101A0739 for ; Fri, 29 Aug 2014 11:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 fnRI3XyuQRLT for ; Fri, 29 Aug 2014 11:08:45 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3751A08A7 for ; Fri, 29 Aug 2014 11:08:45 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so3006595lbv.5 for ; Fri, 29 Aug 2014 11:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UTu8oLLtVkup9GWvfZc8oMTGhEPziYhgpDMJ4WqxsRA=; b=mRIZ/Be+RTTn+xz9fL5J9Z4JClZ9nN/nYeBWu0ECDzxa4RQfabWFheTgQfqyyqeKws UGqd6VipfW/v0OT6MLayndXQ1sRxSRMol1t9qge9vcPJ/hTvxTBBMs4UNYh1qvRAwamJ WhIdxqGkpoc5iz5jYSv4jc0VqNYsQfdZ2WwHc2LJCNylZzy79NrokWEOvaMOqdN381J4 RLhhaQ+ggvp55e7glirLb/9H/Ult/mVatyuspXnFAJp0HepWaHLLEdf4EazU02SzfLE+ MOFZ+gFlycEdHLs3+gE2I1WhvevygVhOfUl4VJPMFhbMeU0i8C1FGs5GBsyiq04ghwj/ JfvA== MIME-Version: 1.0 X-Received: by 10.152.87.81 with SMTP id v17mr12669212laz.17.1409335723531; Fri, 29 Aug 2014 11:08:43 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Fri, 29 Aug 2014 11:08:43 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D431848@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D41CDC3@ESESSMB209.ericsson.se> <53F451CF.10705@alvestrand.no> <001b01cfbc94$fccd5310$f667f930$@co.in> <7594FB04B1934943A5C02806D1A2204B1D427B68@ESESSMB209.ericsson.se> <009001cfbe4f$6b92f280$42b8d780$@co.in> <7594FB04B1934943A5C02806D1A2204B1D431848@ESESSMB209.ericsson.se> Date: Fri, 29 Aug 2014 11:08:43 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HNBWfc6bWUoQaePG63XeZ1ndNZo Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:08:47 -0000 On 29 August 2014 00:20, Christer Holmberg wrote: > As long as the WebRTC entity supporting full ICE does not assume that the remote WebRTC entity (e.g. a WebRTC gateway) also supports full ICE (read: won't perform consent freshness). The only way that ICE uses the checks that a remote peer generates is to populate peer reflexive candidates. It doesn't apply to consent. I think we're safe there. From nobody Sun Aug 31 04:48:14 2014 Return-Path: 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 819B21A893C for ; Sun, 31 Aug 2014 04:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 FLhv3vu4w0oy for ; Sun, 31 Aug 2014 04:48:09 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AC71A893B for ; Sun, 31 Aug 2014 04:48:08 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so4193324qga.3 for ; Sun, 31 Aug 2014 04:48:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=JiZP3zN+KtvBy6s0BjSAb4y2mTFI6rFSUoBVxUzRdjs=; b=gOYp8/dMQJMqW1x0BM4hyg6y0Bqw4569uzMijDcReyhozYCZN3l0qxGEzbkGQfOiot C/EL4P7bWpJhsOmp/Ra+kqROintmWCEfxcZTq5B7DaBdObgHfWyaDEW7sitT5qQ3b/fR 4MTzzqBC+vHR0FcMqVFQxCikjx+R4wfftb25QEXV0ckZTMsePB/ZFjNvgy3j32GZ4VlY F2FANzHLdCdFKSl0dJkA1j2hrQyP8R7mpDTDeV4JnCxLAP2pVm6rBnxqH58exDdhuJJm ZF3T3K8nfsSqVUgHA9+M5ZmJhxQFUaxS7/pYkSZFTHpXi1dN8KFO/coOyQFlJZMBGu9M ZK1w== X-Gm-Message-State: ALoCoQlWuZ7nEgtWPIHpF7duNnmEq3653hjV8QqlpYO1U8sBB751Dz7livtG/z4yWvgPBw/sAyYT X-Received: by 10.229.219.138 with SMTP id hu10mr35105189qcb.5.1409485687918; Sun, 31 Aug 2014 04:48:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Sun, 31 Aug 2014 04:47:47 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 31 Aug 2014 13:47:47 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/F69CqOZKBgsSq6IdjKD8Y-SrRwk Subject: [rtcweb] Which RTCP packet types are valid in WebRTC? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 11:48:10 -0000 Hi, in order to correctly distinguish between RTP and RTCP, RFC 5761 (RTCP-mux) states: > To allow this multiplexing, future RTCP packet type assignments SHOULD be= made after the current assignments in the range 209-223, then in the range= 194-199, so that only the RTP payload types in the range 64-95 are blocked= . IANA has the following assignments for RTCP types: http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-par= ameters-4 194 SMPTETCSMPTE time-code mapping [RFC5484] 195 IJExtended inter-arrival jitter report [RFC5450] 200 SRsender report [RFC3550] 201 RRreceiver report [RFC3550] 202 SDESsource description [RFC3550] 203 BYEgoodbye [RFC3550] 204 APPapplication-defined [RFC3550] 205 RTPFBGeneric RTP Feedback [RFC4585] 206 PSFBPayload-specific [RFC4585] 207 XRextended report [RFC3611] 208 AVBAVB RTCP packet ["Standard for Layer 3 Transport Protocol for Time Sensitive Applications in Local Area Networks." Work in progress.] 209 RSIReceiver Summary Information [RFC5760] 210 TOKENPort Mapping [RFC6284] 211I DMSIDMS Settings [RFC7272] RFC 3550 defines RTCP packets types in 200-204, so I do not understand the sentence above: "future RTCP packet type assignments SHOULD be made after the current assignments in the range 209-223". So what about 205-208? It is confusing IMHO. Given the above information, is it safe to use the following check in order to find RTCP packets when RTCP-mux is used?: if (type >=3D 194 && type <=3D 223) // it is RTCP else // it is not RTCP Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Sun Aug 31 05:08:46 2014 Return-Path: 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 11BBD1A895E for ; Sun, 31 Aug 2014 05:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 p3LKV4_e2Z3x for ; Sun, 31 Aug 2014 05:08:41 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013361A895D for ; Sun, 31 Aug 2014 05:08:40 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so4176314qgf.28 for ; Sun, 31 Aug 2014 05:08:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=vGddeQqYINQqEF7fmMei811+oT4/moF3U4VXyOoRaec=; b=dlMet4ZmcCfRudhGqPl90if8lBWbGBXGRwdVWxqTrfHe+xKlBpcCiMcw+E8VG+YZyp aDfjvCYe7rwL6RmUhwDeI21SotzgZvJNMYBSFoXVLV6G7Oo96HKMdmBvlBdBUcHq3isk TBKI/2v66G9oGBE1N32CkNRqp/SdsWXSMkz95tcyR79pnP61eWxmJmh7/0adTaveSKms HA7viad9jI6FP2hNX2zIYy0T6QYFqWxZ7Ci/os7lIDTaomowV1iz+2DDvUKk5tehQq3I Zv8yDE1jtKrEe0T9hCpnR3/YnRAVsox8K1F+QO92EZVpaLGQcEpEftKag71HTYpDWVdr czvw== X-Gm-Message-State: ALoCoQkbgPnX2hVOO/Q5+c3VtWzB4fwhEbcOFbnGrRCD19LiKCDZTQfKTpaHXxL9yRE/SEs0nffL X-Received: by 10.224.122.137 with SMTP id l9mr17230144qar.76.1409486919964; Sun, 31 Aug 2014 05:08:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Sun, 31 Aug 2014 05:08:19 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 31 Aug 2014 14:08:19 +0200 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/chFM3VmavC5w0G69EIfFo-u2c20 Cc: draft-ietf-rtcweb-transports@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 12:08:43 -0000 2014-08-25 7:36 GMT+02:00 Justin Uberti : > Yes, 4571 must be used for ICE connectivity checks, when using ICE-TCP. > > However, TURN/TCP has its own framing for STUN messages. > > I would simplify your sentence to: > > If ICE-TCP connections are used, framing according to [RFC4571] MUST > be used for all packets, unless the content has its own framing > mechanism. Sure, I excluded TURN in my comment given that TURN has its own framing mechanism. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Sun Aug 31 06:25:16 2014 Return-Path: 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 21D8D1A8981 for ; Sun, 31 Aug 2014 06:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 7_cdQfeUbyVn for ; Sun, 31 Aug 2014 06:25:13 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BE71A8976 for ; Sun, 31 Aug 2014 06:25:13 -0700 (PDT) Received: from [81.187.2.149] (port=43800 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XO583-0003Yn-6R; Sun, 31 Aug 2014 14:25:12 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Sun, 31 Aug 2014 14:24:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F7EF71E-47BF-4BC3-9D08-C7BE0BCCB47C@csperkins.org> References: To: =?windows-1252?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/H-2MYccpNgDGO7tDZIWYV2JAXHc Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Which RTCP packet types are valid in WebRTC? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 13:25:15 -0000 On 31 Aug 2014, at 12:47, I=F1aki Baz Castillo wrote: > Hi, in order to correctly distinguish between RTP and RTCP, RFC 5761 > (RTCP-mux) states: >=20 >> To allow this multiplexing, future RTCP packet type assignments = SHOULD be made after the current assignments in the range 209-223, then = in the range 194-199, so that only the RTP payload types in the range = 64-95 are blocked. >=20 >=20 > IANA has the following assignments for RTCP types: >=20 > = http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-pa= rameters-4 >=20 > 194 SMPTETCSMPTE time-code mapping [RFC5484] > 195 IJExtended inter-arrival jitter report [RFC5450] > 200 SRsender report [RFC3550] > 201 RRreceiver report [RFC3550] > 202 SDESsource description [RFC3550] > 203 BYEgoodbye [RFC3550] > 204 APPapplication-defined [RFC3550] > 205 RTPFBGeneric RTP Feedback [RFC4585] > 206 PSFBPayload-specific [RFC4585] > 207 XRextended report [RFC3611] > 208 AVBAVB RTCP packet ["Standard for Layer 3 Transport Protocol for > Time Sensitive Applications in Local Area Networks." Work in > progress.] > 209 RSIReceiver Summary Information [RFC5760] > 210 TOKENPort Mapping [RFC6284] > 211I DMSIDMS Settings [RFC7272] >=20 >=20 > RFC 3550 defines RTCP packets types in 200-204, so I do not understand > the sentence above: "future RTCP packet type assignments SHOULD be > made after the current assignments in the range 209-223". >=20 > So what about 205-208? It is confusing IMHO. RTCP packet types 205-208 were already assigned when the draft that = formed RFC 5761 was submitted for publication. At that time, the current = assignments were 194, 195, and 200-208. The phrase =93after the current = assignments in the range 209-223=94 therefore makes sense, although = maybe =93after the current assignments, in the range 209=97223=94 would = have been clearer. > Given the above information, is it safe to use the following check in > order to find RTCP packets when RTCP-mux is used?: >=20 >=20 > if (type >=3D 194 && type <=3D 223) > // it is RTCP > else > // it is not RTCP RTCP packet types 192 and 193 are assigned, so a better check would be = to use the range 192-223 inclusive for RTCP packets.=20 Future RTCP packet type assignments outside that range are possible, but = would seem unlikely. --=20 Colin Perkins http://csperkins.org/ From nobody Sun Aug 31 06:31:30 2014 Return-Path: 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 0334A1A898C for ; Sun, 31 Aug 2014 06:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 4DsGXPxpsEXZ for ; Sun, 31 Aug 2014 06:31:25 -0700 (PDT) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DC01A8989 for ; Sun, 31 Aug 2014 06:31:25 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id i50so4226448qgf.14 for ; Sun, 31 Aug 2014 06:31:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=7yKUz+ygT7bCWSc/NY36y+mR8t6TJE6Q4drX7ms0Xkg=; b=f9kybebmD9WNQOwDIffScUUWFapg1IAuf8r4a/5ntDFy7rp+VYMw8sFHYtTDKIv7KL TGtqVZcToV2tKUpeMHMwNhlJMgrI4Vgg6mn2F+/uEZUpfvoT8LZokSFhtft2THhaXxp+ UTg16mZ3cCFt09Jtd8S3AgJqw0MPuvHHQ5xdAi3T1TNVHom+s9pmxtmzpd4MOlbK4SxI 5CrBn+VqhYuRdaR0HQHIaQefbnQUcZXKuFBr1f6h/SlNXM4QyDOFmcNfmA2ICrF5wLq6 3gYRdtNm06MB4mGqTaYFZyFXGfWcH29mGxPaIgcOTvhRxcRDy2S5lDyGTj6pSJ+kaaav L09w== X-Gm-Message-State: ALoCoQmNQI+qjERopDYXKGp2h6LodAttAv1gsu9KGlSWjstyRyf7DiFAC7Nd54H3f8ymfKHhp/69 X-Received: by 10.224.46.8 with SMTP id h8mr36348779qaf.6.1409491884259; Sun, 31 Aug 2014 06:31:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Sun, 31 Aug 2014 06:31:04 -0700 (PDT) In-Reply-To: <2F7EF71E-47BF-4BC3-9D08-C7BE0BCCB47C@csperkins.org> References: <2F7EF71E-47BF-4BC3-9D08-C7BE0BCCB47C@csperkins.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 31 Aug 2014 15:31:04 +0200 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Y_cTnKOBntC3sleR7mp5LA6_3rA Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Which RTCP packet types are valid in WebRTC? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 13:31:29 -0000 2014-08-31 15:24 GMT+02:00 Colin Perkins : > RTCP packet types 205-208 were already assigned when the draft that forme= d RFC 5761 was submitted for publication. At that time, the current assignm= ents were 194, 195, and 200-208. The phrase =E2=80=9Cafter the current assi= gnments in the range 209-223=E2=80=9D therefore makes sense, although maybe= =E2=80=9Cafter the current assignments, in the range 209=E2=80=94223=E2=80= =9D would have been clearer. > >> Given the above information, is it safe to use the following check in >> order to find RTCP packets when RTCP-mux is used?: >> >> >> if (type >=3D 194 && type <=3D 223) >> // it is RTCP >> else >> // it is not RTCP > > RTCP packet types 192 and 193 are assigned, so a better check would be to= use the range 192-223 inclusive for RTCP packets. > > Future RTCP packet type assignments outside that range are possible, but = would seem unlikely. Thanks, so then I assume that detecting RTCP packets by checking their packet type in the range 192-223 will not conflict with RTP packets detection. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Sun Aug 31 06:35:36 2014 Return-Path: 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 6B0E21A8990 for ; Sun, 31 Aug 2014 06:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 q2nC1z1OOAEV for ; Sun, 31 Aug 2014 06:35:32 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99FA01A0188 for ; Sun, 31 Aug 2014 06:35:32 -0700 (PDT) Received: from [81.187.2.149] (port=40877 helo=[192.168.0.22]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XO5Gv-0004ah-LP; Sun, 31 Aug 2014 14:35:30 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Sun, 31 Aug 2014 14:34:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <24417C04-AC8D-4141-A1E3-4B927D3AB646@csperkins.org> References: <2F7EF71E-47BF-4BC3-9D08-C7BE0BCCB47C@csperkins.org> To: =?windows-1252?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/5brjikTxxYlrMg9PM_TziBTCAx0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Which RTCP packet types are valid in WebRTC? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 13:35:33 -0000 On 31 Aug 2014, at 14:31, I=F1aki Baz Castillo wrote: > 2014-08-31 15:24 GMT+02:00 Colin Perkins : >> RTCP packet types 205-208 were already assigned when the draft that = formed RFC 5761 was submitted for publication. At that time, the current = assignments were 194, 195, and 200-208. The phrase =93after the current = assignments in the range 209-223=94 therefore makes sense, although = maybe =93after the current assignments, in the range 209=97223=94 would = have been clearer. >>=20 >>> Given the above information, is it safe to use the following check = in >>> order to find RTCP packets when RTCP-mux is used?: >>>=20 >>>=20 >>> if (type >=3D 194 && type <=3D 223) >>> // it is RTCP >>> else >>> // it is not RTCP >>=20 >> RTCP packet types 192 and 193 are assigned, so a better check would = be to use the range 192-223 inclusive for RTCP packets. >>=20 >> Future RTCP packet type assignments outside that range are possible, = but would seem unlikely. >=20 > Thanks, so then I assume that detecting RTCP packets by checking their > packet type in the range 192-223 will not conflict with RTP packets > detection. Don=92t assume =96 look at what=92s signalled. --=20 Colin Perkins http://csperkins.org/ From nobody Sun Aug 31 06:37:10 2014 Return-Path: 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 E459B1A8997 for ; Sun, 31 Aug 2014 06:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 lSjful3niuVV for ; Sun, 31 Aug 2014 06:37:08 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4051A8996 for ; Sun, 31 Aug 2014 06:37:08 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so4433299qcx.35 for ; Sun, 31 Aug 2014 06:37:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=lWqVHfe8o0l4qIt1x+VfDanFfMTeQ+yyFgzd2RqDgs4=; b=hW70S1kvPOE8k914J40HvZpxiU5R2NxRuNdnZ5PSAZSzKt97t2pwSJ4qMpwaaFMGhY otXoxG59zzpLksf213bZ3MAmwF/OaAFxON3ouqIBQl/yIEQiuWNGKLBj3o4YATMCf9xK FAHTWw46DvZd4vJiAWVZhl2Ijj8ltf4QOacE8/Z+gScqPx0lS0bER2SDCw4fnj3CVrUq hesqEGB2+03LYLUkKe4bxMmcKo5tcNq8I793ibMS3sQLFCXPdHS260tG/bW+jaAbiYlZ MzMQT2ZDvBBE5bVa78HUX2gJmos3HLDLsAexYFN252kO3kiQWYSMw23nsnaYSOC15iCo HWOw== X-Gm-Message-State: ALoCoQnQbjJcAPCuRr+j8plI8pvt9LKfIaYRot9Ip5MHeFVeyxzHaRnfuSNf3ebg3EQCKJVcwNJP X-Received: by 10.224.122.137 with SMTP id l9mr17899536qar.76.1409492227276; Sun, 31 Aug 2014 06:37:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.69.200 with HTTP; Sun, 31 Aug 2014 06:36:47 -0700 (PDT) In-Reply-To: <24417C04-AC8D-4141-A1E3-4B927D3AB646@csperkins.org> References: <2F7EF71E-47BF-4BC3-9D08-C7BE0BCCB47C@csperkins.org> <24417C04-AC8D-4141-A1E3-4B927D3AB646@csperkins.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 31 Aug 2014 15:36:47 +0200 Message-ID: To: Colin Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/g838b-C8jp2GIvZabjhpL630aS8 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Which RTCP packet types are valid in WebRTC? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 13:37:09 -0000 2014-08-31 15:34 GMT+02:00 Colin Perkins : >> Thanks, so then I assume that detecting RTCP packets by checking their >> packet type in the range 192-223 will not conflict with RTP packets >> detection. > > Don=E2=80=99t assume =E2=80=93 look at what=E2=80=99s signalled. Of course, I mean the case in which rtcp-mux is enabled. --=20 I=C3=B1aki Baz Castillo