From nobody Mon Jun 1 02:13:17 2015 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 129451A90C6 for ; Mon, 1 Jun 2015 02:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 G_iRnhnQNcsT for ; Mon, 1 Jun 2015 02:13:15 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B0981A90C1 for ; Mon, 1 Jun 2015 02:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2823; q=dns/txt; s=iport; t=1433149995; x=1434359595; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2GhGONdNACeOGe+iz8XbCegInX98cjdvUp/M81NN5u8=; b=NkyXiUcGODnGgBXSGxSk20bZKQJNtFPRjGQDjbFsqG/jRAJ8Nv6KR8Y4 SRnu6GmbLKYaqphxIMSjFlyTJGyZg3Uty9JVtKa63a7ITMUoE8GFvnaa+ G32ZEd/VevILNVluvNcjF/BTzHDOI06ZNeFrdFO5JaPmGIp/kX9EWHm4l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A3BAByIWxV/5BdJa1cgxBUXga9aGYJgVAKhS1KAoErOBQBAQEBAQEBgQqEIgEBAQMBAQEBNzQLDAQCAQgRAwEBAQsUCQchBgsUCQgCBAENBQiIEAMKCA3QUg2EdgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OCTYFhJzEHBoMRgRYBBJMKiTmSB4cEI2GDF2+BBEKBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,531,1427760000"; d="scan'208";a="155101180" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 01 Jun 2015 09:13:14 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t519DEWb021543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jun 2015 09:13:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 04:13:14 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Ram Mohan R (rmohanr)" , Christer Holmberg , Bernard Aboba , Harald Alvestrand Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCZEAkgUwawg8/yQZKvd0M2cshTwQA3IdqAAB6E1AAAG0e6gAAVn3yAACmsfAAAIlRCgAADy+0A Date: Mon, 1 Jun 2015 09:13:13 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478627AA@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <556965FD.1060001@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D873AEB@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.18.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 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, 01 Jun 2015 09:13:17 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Monday, June 01, 2015 11:31 AM > To: Christer Holmberg; Bernard Aboba; Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent- > freshness-13 >=20 > WFM. I am fine with keeping APIs out of scope for consent document. It wi= ll > be better to have all APIs in one document and have reference to that whe= re > ever applicable. NEW: 8. API Recommendations The W3C specification [W3C-WEBRTC] may provide an API hook that generates an event when consent has expired for a given 5-tuple, meaning that transmission of data has ceased. This could indicate what application data is affected, such as media or data channels. The mechanism of how applications are made aware of consent expiration is outside the scope of the document. -Tiru >=20 > Regards, > Ram >=20 > -----Original Message----- > From: Christer Holmberg > Date: Sunday, 31 May 2015 7:08 pm > To: Bernard Aboba , Harald Alvestrand > > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] OPS-Dir review of > draft-ietf-rtcweb-stun-consent-freshness-13 >=20 > >Hi, > > > >>> I'd prefer to limit the number of documents that try to design APIs. > >>> > >>> Can we do something more generic, like "Applications that use the > >>> RTWEB transport will need to be notified when transmission ceases > >>> due to expiry of consent. The design of APIs to carry these > >>> notifications is out of scope for this document."? > >> > >> [BA] Agree with Harald. Loss of STUN consent on a 5-tuple is quite > >>different from tripping a circuit breaker. Let's not design the APIs > >>in this document. > > > >I agree on the not-designing-the-API part. > > > >Regarding Harald's suggested text, it's fine - but I don't think it > >belongs in this document. Shouldn't it be in the RTCWEB overview and/or > >security document instead? > > > >The consent freshness draft could then state that the > >mechanism/requirements how applications are made aware of consent > >expiration is outside the scope of the document. > > > >Regards, > > > >Christer > > > > > > > > > > > >_______________________________________________ > >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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jun 1 02:16:45 2015 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 572181A90CF for ; Mon, 1 Jun 2015 02:16:44 -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 6oSpAuEf61MC for ; Mon, 1 Jun 2015 02:16:42 -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 599031A90C0 for ; Mon, 1 Jun 2015 02:16:41 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-cf-556c22f7feca Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.D1.04401.7F22C655; Mon, 1 Jun 2015 11:16:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Mon, 1 Jun 2015 11:16:38 +0200 From: Christer Holmberg To: "Tirumaleswar Reddy (tireddy)" , "Ram Mohan R (rmohanr)" , Bernard Aboba , Harald Alvestrand Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmcKuxYNeEsZ9K0CG03cvwAJmIp2TJGkAgADaPoCAAKz8gIABQITggAEfgoCAADWpgIAAIiEA Date: Mon, 1 Jun 2015 09:16:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D874C4F@ESESSMB209.ericsson.se> References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <556965FD.1060001@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D873AEB@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A478627AA@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A478627AA@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3Vve7Uk6owby3EhYb9v1ntjjW18Vm sbxrB6PF2n/t7BYndm9jdGD1uDLhCqvHlN8bWT12zrrL7rFkyU+mAJYoLpuU1JzMstQifbsE roy3b5pYCl5KVfQdPMDewPhFtIuRk0NCwERi5p+VbBC2mMSFe+uBbC4OIYGjjBIvD69mhHAW MUpc3dfL2sXIwcEmYCHR/U8bJC4isItRYuvkyYwg3cwC6hJ3Fp9jB7GFBUIl+j4cYAOpFxEI k7h90AwkLCIQJTG39SgTiM0ioCKx58dHsFZeAV+JVxv2Qu3ayixx8MVCsAQnUGLz57VgNiPQ dd9PrWGC2CUucevJfCaIqwUkluw5zwxhi0q8fPyPFcJWlGh/2gB1m57EjalT2CBsbYllC18z QywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxi BMbcwS2/VXcwXn7jeIhRgINRiYd3wZ7sUCHWxLLiytxDjNIcLErivJ5dIaFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGBvPayom5Zbe/sv5s8ieTyJwve7q3jtVAqdkeafnK+1+wPbW/fiT w0xPK1hfOLg8143zkbjo4X24O7p+TfEe++kHxYPO9ySfvF0hUPln3/bN1qZ2ZSc/vIyVL3rp EWyetHjS/M9mflveWVy8YrY2/sXSW4xhv/adT5z2I6oyY+/6d3yHtTaa+CmxFGckGmoxFxUn AgAZsfAFmgIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 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, 01 Jun 2015 09:16:44 -0000 Hi, Why do we need to talk about W3C specifications at all? Couldn't we simply = remove section 8? The out-of-the-scope text I suggested earlier could be put e.g. in the Intr= oduction, or in an Applicability section. Regards, Christer -----Original Message----- From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Sent: 1. kes=E4kuuta 2015 12:13 To: Ram Mohan R (rmohanr); Christer Holmberg; Bernard Aboba; Harald Alvestr= and Cc: rtcweb@ietf.org Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-fres= hness-13 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Monday, June 01, 2015 11:31 AM > To: Christer Holmberg; Bernard Aboba; Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] OPS-Dir review of=20 > draft-ietf-rtcweb-stun-consent- > freshness-13 >=20 > WFM. I am fine with keeping APIs out of scope for consent document. It=20 > will be better to have all APIs in one document and have reference to=20 > that where ever applicable. NEW: 8. API Recommendations The W3C specification [W3C-WEBRTC] may provide an API hook that generates an event when consent has expired for a given 5-tuple, meaning that transmission of data has ceased. This could indicate what application data is affected, such as media or data channels. The mechanism of how applications are made aware of consent expiration is outside the scope of the document. -Tiru >=20 > Regards, > Ram >=20 > -----Original Message----- > From: Christer Holmberg > Date: Sunday, 31 May 2015 7:08 pm > To: Bernard Aboba , Harald Alvestrand=20 > > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] OPS-Dir review of > draft-ietf-rtcweb-stun-consent-freshness-13 >=20 > >Hi, > > > >>> I'd prefer to limit the number of documents that try to design APIs. > >>> > >>> Can we do something more generic, like "Applications that use the=20 > >>> RTWEB transport will need to be notified when transmission ceases=20 > >>> due to expiry of consent. The design of APIs to carry these=20 > >>> notifications is out of scope for this document."? > >> > >> [BA] Agree with Harald. Loss of STUN consent on a 5-tuple is quite=20 > >>different from tripping a circuit breaker. Let's not design the=20 > >>APIs in this document. > > > >I agree on the not-designing-the-API part. > > > >Regarding Harald's suggested text, it's fine - but I don't think it=20 > >belongs in this document. Shouldn't it be in the RTCWEB overview=20 > >and/or security document instead? > > > >The consent freshness draft could then state that the=20 > >mechanism/requirements how applications are made aware of consent=20 > >expiration is outside the scope of the document. > > > >Regards, > > > >Christer > > > > > > > > > > > >_______________________________________________ > >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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jun 1 02:21:29 2015 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 1A3E41A90E0 for ; Mon, 1 Jun 2015 02:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 w_cjtNzjxtCJ for ; Mon, 1 Jun 2015 02:21:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63391A90D9 for ; Mon, 1 Jun 2015 02:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4075; q=dns/txt; s=iport; t=1433150485; x=1434360085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3xFevg1a/FE2oxPZwJrCKVSPLBIW2ATvpbci7Wy0lMQ=; b=YlohcelexqddWCvxsNU+q7AmN1P9XA4CxKx7K2FBB9AIeqzLDOHsq6ua NGfS+MIiBOqH7OHRlYNQFyQ59uLNFkvcqG5POK/SsHLAmDwPgnE64U01d z/z/bDtd6IkEMLWt3ZQNrNnvad5UXpIZgc0kUGsBJjKAe+/VHv1+Q6Lro g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BXBQBoI2xV/4UNJK1cgxBUXga9aII/CoUtSgKBK0wBAQEBAQGBC4QiAQEBAwEBAQFrCwwEAgEIEQMBAQELHQchBgsUCQgCBAENBQiIEAMKCA3QUw2EdgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OCTYFhJzEHBoMRgRYFjAqERII8iTmSB4cEI2GDF2+BBEKBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,531,1427760000"; d="scan'208";a="16412784" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 01 Jun 2015 09:21:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t519LOsh024076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jun 2015 09:21:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 04:21:23 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christer Holmberg , "Ram Mohan R (rmohanr)" , Bernard Aboba , Harald Alvestrand Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCZEAkgUwawg8/yQZKvd0M2cshTwQA3IdqAAB6E1AAAG0e6gAAVn3yAACmsfAAAIlRCgAADy+0AAAMH1QAACmCWYA== Date: Mon, 1 Jun 2015 09:21:22 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478627E0@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <556965FD.1060001@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D873AEB@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A478627AA@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D874C4F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D874C4F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.18.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 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, 01 Jun 2015 09:21:28 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 01, 2015 2:47 PM > To: Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr); Bernard Aboba; > Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent- > freshness-13 >=20 > Hi, >=20 > Why do we need to talk about W3C specifications at all? Couldn't we simpl= y > remove section 8? It can be removed, discussion about W3C was there from day one of the draft= . >=20 > The out-of-the-scope text I suggested earlier could be put e.g. in the > Introduction, or in an Applicability section. Works for me. -Tiru >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Sent: 1. kes=E4kuuta 2015 12:13 > To: Ram Mohan R (rmohanr); Christer Holmberg; Bernard Aboba; Harald > Alvestrand > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent- > freshness-13 >=20 > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan > R > > (rmohanr) > > Sent: Monday, June 01, 2015 11:31 AM > > To: Christer Holmberg; Bernard Aboba; Harald Alvestrand > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] OPS-Dir review of > > draft-ietf-rtcweb-stun-consent- > > freshness-13 > > > > WFM. I am fine with keeping APIs out of scope for consent document. It > > will be better to have all APIs in one document and have reference to > > that where ever applicable. >=20 > NEW: >=20 > 8. API Recommendations >=20 > The W3C specification [W3C-WEBRTC] may provide an API hook that > generates an event when consent has expired for a given 5-tuple, > meaning that transmission of data has ceased. This could indicate > what application data is affected, such as media or data channels. > The mechanism of how applications are made aware of consent > expiration is outside the scope of the document. >=20 > -Tiru >=20 > > > > Regards, > > Ram > > > > -----Original Message----- > > From: Christer Holmberg > > Date: Sunday, 31 May 2015 7:08 pm > > To: Bernard Aboba , Harald Alvestrand > > > > Cc: "rtcweb@ietf.org" > > Subject: Re: [rtcweb] OPS-Dir review of > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > >Hi, > > > > > >>> I'd prefer to limit the number of documents that try to design APIs= . > > >>> > > >>> Can we do something more generic, like "Applications that use the > > >>> RTWEB transport will need to be notified when transmission ceases > > >>> due to expiry of consent. The design of APIs to carry these > > >>> notifications is out of scope for this document."? > > >> > > >> [BA] Agree with Harald. Loss of STUN consent on a 5-tuple is quite > > >>different from tripping a circuit breaker. Let's not design the > > >>APIs in this document. > > > > > >I agree on the not-designing-the-API part. > > > > > >Regarding Harald's suggested text, it's fine - but I don't think it > > >belongs in this document. Shouldn't it be in the RTCWEB overview > > >and/or security document instead? > > > > > >The consent freshness draft could then state that the > > >mechanism/requirements how applications are made aware of consent > > >expiration is outside the scope of the document. > > > > > >Regards, > > > > > >Christer > > > > > > > > > > > > > > > > > >_______________________________________________ > > >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 Jun 1 06:10:56 2015 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 513641A001D; Mon, 1 Jun 2015 06:10:54 -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 9b5WUxmq8lR6; Mon, 1 Jun 2015 06:10:51 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 109691A001A; Mon, 1 Jun 2015 06:10:50 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so75113642wic.0; Mon, 01 Jun 2015 06:10:48 -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=Cj2GCtZwxTuy12QCP1wrAi0UFhhbEt5kF0HL1gkLHnQ=; b=tr3N+G3s9OyL2RrJCzyBEm6AwBCqPMk0g/QP2JarMe0jXDVk63K+cbWkQeUGkHRv68 qOgHMTCiYcXZSc1h8brGKsfzUNxKurA29YV1GEP5ZTM4fyMFAC5l+aFvtuEi2kNTFoyk GSXYDCTiUlA8172bwU9ENQ+/uayQL73oeSYxyOJz0gZCvxM4UDiKszs6MHxlLQEOyJgU enD/7XHVnRg14MfyQCgdKjeJVofnHDkEZhvm0ICQYzumEcKqmKWaFN4nVzjpNwIsVkaw y3DyUosoDDDa1M4ejY3Wk1UpvtGU+1HPwxCXesUWqmhtZLX0lMxRCCfkBgyw2Adhfic/ ZjJg== MIME-Version: 1.0 X-Received: by 10.180.218.137 with SMTP id pg9mr20444494wic.79.1433164248676; Mon, 01 Jun 2015 06:10:48 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Mon, 1 Jun 2015 06:10:48 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861447@xmb-rcd-x10.cisco.com> Date: Mon, 1 Jun 2015 18:40:48 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: "Black, David" Content-Type: multipart/alternative; boundary=001a1134cedcf27efa0517748dd3 Archived-At: Cc: "rtcweb-chairs@tools.ietf.org" , "ops-dir@ietf.org" , joel jaeggli , "rtcweb@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 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, 01 Jun 2015 13:10:54 -0000 --001a1134cedcf27efa0517748dd3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think RFC5245 does not rule out someone using STUN binding requests for keepalive: Though Binding Indications are used for keepalives, an agent MUST be prepared to receive a connectivity check as well. If a connectivity check is received, a response is generated as discussed in [RFC5389], but there is no impact on ICE processing otherwise. OLD: If consent is performed then there is no need to send keepalive messages. Suggested NEW: If consent is performed then the STUN binding requests sent for consent freshness also serve the keepalive purpose. That is effectively what RFC5245 says for keepalive.. Muthu On Fri, May 29, 2015 at 11:41 PM, Black, David wrote: > That also works for me, and neatly sidesteps the concern about > > whether RFC 5245 is being updated. > > > > Thanks, > --David > > > > *From:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > *Sent:* Thursday, May 28, 2015 11:20 PM > *To:* Christer Holmberg; Ted Hardie; Black, David > > *Cc:* joel jaeggli; ops-dir@ietf.org; rtcweb@ietf.org; > rtcweb-chairs@tools.ietf.org > *Subject:* RE: [rtcweb] OPS-Dir review of > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > *From:* Christer Holmberg [mailto:christer.holmberg@ericsson.com > ] > *Sent:* Friday, May 29, 2015 7:37 AM > *To:* Tirumaleswar Reddy (tireddy); Ted Hardie; Black, David > *Cc:* joel jaeggli; ops-dir@ietf.org; rtcweb@ietf.org; > rtcweb-chairs@tools.ietf.org > *Subject:* RE: [rtcweb] OPS-Dir review of > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > Hi, > > > > >Good point. We discuss the following point in section 4.1 of the draft > about keepalives: > > > > > > An endpoint that is not sending any application data does not need to > > > maintain consent. However, not sending any traffic could cause NAT > > > or firewall mappings to expire. Furthermore, having one peer unable > > > to send is detrimental to many protocols. Absent better information > > > about the network, if an endpoint needs to ensure its NAT or firewall > > > mappings do not expire, it can be done using keepalive or other > > > techniques (see Section 10 of [RFC5245] > and see [RFC6263 > ]). > > > > > > So there is no need to send keepalives because of the media traffic as > it is pointed out in Section 20.2.3 of RFC 5245 > > > irrespective of whether consent is used or not. I think we can remove > the following line in =E2=80=9CIf consent is performed then > > > there is no need to send keepalive messages." and avoid the confusion > of updating RFC 5245. > > > > I agree that the current text can confuse people, but I still think it > would be good to have explicit text saying that keepalives are not sent. > Perhaps something like: > > > > =E2=80=9CFrom a keepalive perspective, consent requests are considered me= dia > traffic. Because of that, dedicated keepalives (e.g. STUN binding request= s) > are not sent on candidate pairs where consent requests are sent, in > accordance with Section 20.2.3 of [RFC5245].=E2=80=9D > > > > Works for me (Replaced STUN binding requests with STUN Binding > Indications in the above line). > > > > Cheers, > > -Tiru > > > > Regards, > > > > Christer > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Christer Holmberg > *Sent:* Friday, May 29, 2015 6:54 AM > *To:* Ted Hardie; Black, David > *Cc:* joel jaeggli; ops-dir@ietf.org; rtcweb@ietf.org; > rtcweb-chairs@tools.ietf.org > *Subject:* Re: [rtcweb] OPS-Dir review of > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > > > Hi, > > > > Section 20.2.3 of RFC 5245 says: > > > > =E2=80=9CSTUN keepalives (in the form of STUN Binding Indications) are se= nt in > > the middle of a media session. However, *they are sent > only in the* > > * absence of actual media traffic*.=E2=80=9D > > > > So, in the consent draft we could say that, from a keepalive perspective, > consent requests are considered media traffic. That would then implicitly > mean that actual keepalives aren=E2=80=99t sent when consent is used. Tha= t way, the > consent spec would be compliant to 5245, and there would be no need for a= ny > update etc=E2=80=A6 > > > > Regards, > > > > Christer > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Ted Hardie > *Sent:* 28 May 2015 23:26 > *To:* Black, David > *Cc:* rtcweb-chairs@tools.ietf.org; joel jaeggli; ops-dir@ietf.org; > rtcweb@ietf.org > *Subject:* Re: [rtcweb] OPS-Dir review of > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > Hi David, > > > > On Thu, May 28, 2015 at 12:36 PM, Black, David > > > I'd expect that even overriding RFC 5245 counts as an Update, > because the result would be that the original RFC 5245 "MUST" requirement > is no longer globally applicable to all uses of RFC 5245. In other words= , > overriding RFC 5245 effectively rewrites the "MUST" to become "MUST, exce= pt > as further specified by the consent RFC." > > > > =E2=80=8BSo I agree with you that this must be called out, but I think "U= pdates" > is wrong for the draft's current intent. I think what Martin has said > amounts to "We have chosen to follow RFC 5245 except as detailed in > sections X and Y, where we use a different set of messages to optimize th= e > combination of heartbeat and consent." We are not updating RFC 5245 > thereby, because we are neither changing its core semantics nor offering = to > add a new, general semantic to RFC 5245 (we could have made that choice, > but are not doing so now). Instead of updating RFC 5245, in other words, > we are limiting our reference to it. > > That should be done explicitly, and I think it should be called it > suffiiciently that a new spin of the draft likely needs a new round of > review. But I don't think we are required to update RFC 5245 to get that > done. > > I've referred the matter to our friendly AD, and we await her reading on > next steps on this. In either approach, however, this will get called ou= t. > > regards, > > Ted HArdie=E2=80=8B > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1134cedcf27efa0517748dd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think RFC5245 does not rule out someo= ne using STUN binding requests for keepalive:

<= /div>
<snip>
=C2=A0 =C2=A0Though Binding Indications are used for k= eepalives,
=C2=A0 =C2=A0an agent MUST be prepared t= o receive a connectivity check as well.
=C2=A0 =C2= =A0If a connectivity check is received, a response is generated as
=C2=A0 =C2=A0discussed in [RFC5389], but there is no impact= on ICE processing
=C2=A0 =C2=A0otherwise.
</snip>

OLD:
=C2=A0 =C2=A0 If consent = is performed then there is no need to send keepalive messages.
=

Suggested NEW:
=C2=A0 =C2=A0If con= sent is performed then the STUN binding requests sent for consent
=C2=A0 =C2=A0freshness also serve the keepalive purpose.

That is effectively what RFC5245 says for keepali= ve..

Muthu

=
On = Fri, May 29, 2015 at 11:41 PM, Black, David <david.black@emc.com&g= t; wrote:

That also works for me, and neatly sidesteps the c= oncern about

whether RFC 5245 is being updated.

=C2=A0

Thanks,
--David

=C2=A0

From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
Sent: Thursday, May 28, 2015 11:20 PM
To: Christer Holmberg; Ted Hardie; Black, David


Cc: joel jaeggli; ops-dir@ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-conse= nt-freshness-13

=C2=A0

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Friday, May 29, 2015 7:37 AM
To: Tirumaleswar Reddy (tireddy); Ted Hardie; Black, David
Cc: joel jaeggli; ops-dir@ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
Subject: RE: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-conse= nt-freshness-13

=C2=A0

Hi,

=C2=A0

>Good point. We discuss t= he following point in section 4.1 of the draft about keepalives:<= /u>

>=C2=A0

>=C2=A0=C2=A0 An endpoint that is not sending any applicati= on data does not need to

>=C2=A0=C2=A0 maintain consent.=C2=A0 However, not sending = any traffic could cause NAT

>=C2=A0=C2=A0 or firewall mappings to expire.=C2=A0 Further= more, having one peer unable

>=C2=A0=C2=A0 to send is detrimental to many protocols.=C2= =A0 Absent better information

>=C2=A0=C2=A0 about the network, if an endpoint needs to en= sure its NAT or firewall

>=C2=A0=C2=A0 mappings do not expire, it can be done using = keepalive or other

>=C2=A0=C2=A0 techniques (see Section=C2=A010 of [RFC5245] and see [RFC6263]).

>=C2=A0

> So there is no need to send keepalives= because of the media traffic as it is pointed out in Section 20.2.3 of RFC 5245

> irrespective of whether consent is use= d or not. I think we can remove the following line in= =E2=80=9CIf consent is performed then

> there is no need to send keepalive mes= sages." and avoid the confusion of updating RFC 5245.

=C2=A0

I agree that the current text can confuse people, but I still thi= nk it would be good to have explicit text saying that keepalives are not se= nt. Perhaps something like:

=C2=A0

=E2=80=9CFrom a keepalive perspective, consent requests are consi= dered media traffic. Because of that, dedicated keepalives (e.g. STUN bindi= ng requests) are not sent on candidate pairs where consent requests are sent, in accordance with Section 20.2.3 o= f [RFC5245].=E2=80=9D

=C2=A0

Works for me (Replaced STUN b= inding requests with STUN Binding Indications in the above line).=

=C2=A0

Cheers,

-Tiru

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, May 29, 2015 6:54 AM
To: Ted Hardie; Black, David
Cc: joel jaeggli; ops-dir@ietf.org; rtcweb@ietf.org; rtcweb-chairs@tools.ietf.org
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-conse= nt-freshness-13

=C2=A0

=C2=A0

Hi,

=C2=A0

Section 20.2.3 of RFC 5245 sa= ys:

=C2=A0

= =E2=80=9CSTUN keepalives (in the form of STUN Binding Indications) are sent= 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 the middle of a media session= .=C2=A0 However, they are sent only in the

=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 absence of actual media tr= affic.=E2=80=9D

=C2=A0

So, in the consent draft we c= ould say that, from a keepalive perspective, consent requests are considere= d media traffic. That would then implicitly mean that actual keepalives aren=E2=80=99t sent when consent is used. That= way, the consent spec would be compliant to 5245, and there would be no ne= ed for any update etc=E2=80=A6

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: 28 May 2015 23:26
To: Black, David
Cc: rtcweb-chairs@tools.ietf.org; joel jaeggli; ops-dir@ietf.org;= rtcweb@ietf.org
Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-conse= nt-freshness-13

=C2=A0

Hi David,

=C2=A0

On Thu, May 28, 2015 at 12:36 P= M, Black, David <david.black@emc.com>


I'd expect that even overriding RFC 5245 counts as an Update,
because the result would be that the original RFC 5245 "MUST" req= uirement
is no longer globally applicable to all uses of RFC 5245.=C2=A0 In other wo= rds,
overriding RFC 5245 effectively rewrites the "MUST" to become &qu= ot;MUST, except
as further specified by the consent RFC."

=C2=A0

=E2=80=8BSo I agree with you that thi= s must be called out, but I think "Updates" is wrong for the draf= t's current intent.=C2=A0 I think what Martin has said amounts to "We have chosen to follow RFC 5245 except as detailed in sections = X and Y, where we use a different set of messages to optimize the combinati= on of heartbeat and consent."=C2=A0 We are not updating RFC 5245 there= by, because we are neither changing its core semantics nor offering to add a new, general semantic to RFC 5245 (we could have mad= e that choice, but are not doing so now).=C2=A0 Instead of updating RFC 524= 5, in other words, we are limiting our reference to it.

That should be done explicitly, and I= think it should be called it suffiiciently that a new spin of the draft li= kely needs a new round of review.=C2=A0 But I don't think we are required to update RFC 5245 to get that done.=

I've referred the matter to our f= riendly AD, and we await her reading on next steps on this.=C2=A0 In either= approach, however, this will get called out.

regards,

Ted HArdie=E2=80=8B

=C2=A0


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


--001a1134cedcf27efa0517748dd3-- From nobody Mon Jun 1 15:07:07 2015 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 4E4911A0199; Mon, 1 Jun 2015 15:07:03 -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 4pAAYeddH3bo; Mon, 1 Jun 2015 15:06:58 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EB01A0197; Mon, 1 Jun 2015 15:06:57 -0700 (PDT) Received: by wgez8 with SMTP id z8so125601819wge.0; Mon, 01 Jun 2015 15:06: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:from:date:message-id:subject:to :cc:content-type; bh=hor2tD2Hyhdqn0o38nuPRxwK+DICYuw0NqwWtZAb2zw=; b=Yu6pxCq+SBWqnK2mmDM62WMMFOVscGMty8rdX9H5THpjc3aBdjMzaNdWyNu6D43QYr o41LUgI4qBqwfcRKOdDucaXCn8PKAQNMrhuh6jkMXNBB6fkTFeEBm5ZVgO6yyMBnFWD2 wYUzcgvTqdfEdYT/UeQH9QW90Y2qYLhczLF32s54xhduHUkU7gJ+xKbStqnor1OonAdk ttCsFctDBnbusY55ukdSlm064PFvywkKWyZygTxhr31GyMRZnNIePyn8YpT3CQWwYLLS Kw54ZAbf6fVbUTsnxEACosL4b7giyXwoUoxXC4unc1te8cAsPzpQmc7MEqeVioov59je OIAQ== X-Received: by 10.194.22.131 with SMTP id d3mr34224436wjf.111.1433196416401; Mon, 01 Jun 2015 15:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Mon, 1 Jun 2015 15:06:36 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Mon, 1 Jun 2015 15:06:36 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7b5d504e4b06f205177c0bd6 Archived-At: Cc: "rtcweb@ietf.org" , The IESG Subject: Re: [rtcweb] Review of 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, 01 Jun 2015 22:07:03 -0000 --047d7b5d504e4b06f205177c0bd6 Content-Type: text/plain; charset=UTF-8 Comments on the PR: +pair when the pair enters Succeeded ICE state. consent; this document +establishes a 30 second expiry time on consent. [BA] Is the text starting from "consent;" intended to be there? Looks like a cut/paste error. +Consent expires after 30 seconds. That is, if a valid STUN binding response has +not been received from the remote peer's transport address in 30 seconds, the +endpoint MUST cease transmission on that 5-tuple. STUN consent responses +received after consent expiry do not re-establish consent, and may be discarded +or cause an ICMP error. [BA] If a response still has not been received, but the RTO timer has not expired, why should consent be revoked just because the 30 second timer elapsed? As an example, if a request is sent at 29.9 seconds, and the RTO timer is 2 seconds, why should consent be revoked only 100 ms after sending the request?? Also, this text does not appear consistent with the text below: +periodically. To prevent synchronization of consent checks, each interval MUST +be randomized from between 0.8 and 1.2 times the basic period. Implementations +SHOULD set a default interval of 5 seconds, resulting in a period between checks +of 4 to 6 seconds. This timer is independent of the consent expiry timeout. + + +Each STUN binding request for consent MUST use a new STUN transaction identifier +for every consent binding request, as described in Section 6 of . Each STUN binding request for consent is transmitted once +only. A sender therefore cannot assume +that it will receive a response for every consent request, and a response might +be for a previous request (rather than for the most recently sent request). + + +An endpoint SHOULD await a binding response for each request it sends for a time +based on the estimated round-trip time (RTT) (see Section 7.2.1 of ) with an allowance for variation in network delay. The RTT +value can be updated as described in . After this time +elapses, an endpoint can discard associated state and ignore any late responses. [BA] I do not understand why responses arriving after the RTO timer expires are completely ignored. Post-RTO responses not only indicate that consent has been maintained, but also that the RTO needs to be revised upwards. So I would consider deleting the last sentence. +All outstanding STUN consent transactions for a candidate pair MUST be discarded +when consent expires. [BA] This part does make sense. But overall, the paragraph seems to indicate that consent expires at max(30, Tlast-request + RTO), not 30 seconds. On Fri, May 22, 2015 at 3:23 PM, Martin Thomson wrote: > To reset the thread, here are the changes that I am going to propose: > > > https://github.com/martinthomson/IETF-drafts-1/compare/vc...martinthomson:bernard-consent > > I have a pull request on the repo that you can follow, but the diff > there is a complete mess due to some nasty version control issues: > > https://github.com/Draft-Mafia/IETF-drafts/pull/10 > > The following changes are substantive in some sense: > > Consent is maintained now by receiving a valid response. Previously, > it was receiving a response to one of the checks that were initiated > in the 30s window (which would have prevented this from working with > RTT approaching 30s, so I considered it harmless). This change should > make it more robust. > > Requests are abandoned when RTT (+delta) expires or when consent is > lost. Requests aren't abandoned by receiving a response to a later > request (the unlikely out of order request Bernard was concerned > with). This means that there is another timer that runs, in theory > (clever implementers will learn that this timer doesn't need to be an > actual timer). > > > On 20 May 2015 at 16:48, Bernard Aboba wrote: > > This is a review of draft-ietf-rtcweb-stun-consent-freshness. > > > > Overall, I believe that this document is not yet ready for publication > as a > > proposed standard, > > due to transport-related issues. Rather than building upon the RFC 5389 > > transport model > > (including the transaction structure and RTT/RTO estimator), the > > specification proposes a > > new (and poorly specified) transport model that does not adapt properly > > to networks with differing transport characteristics. > > > > RFC 5389 Section 7.2.1 describes how stun handles retransmissions and > > RTT/RTO computation: > > > > The RTO is an estimate of the round-trip time (RTT), > > and is computed as described in RFC 2988 [RFC2988], with two > > exceptions. First, the initial value for RTO SHOULD be configurable > > (rather than the 3 s recommended in RFC 2988) and SHOULD be greater > > than 500 ms. The exception cases for this "SHOULD" are when other > > mechanisms are used to derive congestion thresholds (such as the ones > > defined in ICE for fixed rate streams), or when STUN is used in non- > > Internet environments with known network capacities. In fixed-line > > access links, a value of 500 ms is RECOMMENDED. Second, the value of > > RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms > > accuracy SHOULD be maintained. As with TCP, the usage of Karn's > > algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means > > that RTT estimates SHOULD NOT be computed from STUN transactions that > > result in the retransmission of a request. > > > > The value for RTO SHOULD be cached by a client after the completion > > of the transaction, and used as the starting value for RTO for the > > next transaction to the same server (based on equality of IP > > address). The value SHOULD be considered stale and discarded after > > 10 minutes. > > > > Retransmissions continue until a response is received, or until a > > total of Rc requests have been sent. Rc SHOULD be configurable and > > SHOULD have a default of 7. If, after the last request, a duration > > equal to Rm times the RTO has passed without a response (providing > > ample time to get a response if only this final request actually > > succeeds), the client SHOULD consider the transaction to have failed. > > Rm SHOULD be configurable and SHOULD have a default of 16. A STUN > > transaction over UDP is also considered failed if there has been a > > hard ICMP error [RFC1122]. For example, assuming an RTO of 500 ms, > > requests would be sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 > > ms, 15500 ms, and 31500 ms. If the client has not received a > > response after 39500 ms, the client will consider the transaction to > > have timed out. > > > > The above mechanism addresses a number of issues: > > > > 1. Adaptation of the RTO via RTT measurement > > 2. Consistent number of requests sent without a response (Rc) before > > transaction failure > > 3. Total time to transaction failure robust against routing transients > > > > Unfortunately, rather than reusing all or part of this approach, the > consent > > freshness specification invents an new and poorly specified transport > scheme > > in Section 4.1: > > > > Initial consent to send traffic is obtained using ICE. Consent > > expires after 30 seconds. That is, if a valid STUN binding response > > corresponding to any STUN request sent in the last 30 seconds has not > > been received from the remote peer's transport address, the endpoint > > MUST cease transmission on that 5-tuple. STUN consent responses > > received after consent expiry do not re-establish consent, and may be > > discarded or cause an ICMP error. > > > > To prevent expiry of consent, a STUN binding request can be sent > > periodically. To prevent synchronization of consent checks, each > > interval MUST be randomized from between 0.8 and 1.2 times the basic > > period. Implementations SHOULD set a default interval of 5 seconds, > > resulting in a period between checks of 4 to 6 seconds. > > > > Each STUN binding request for consent MUST use a new > > cryptographically strong [RFC4086] STUN transaction ID. Each STUN > > binding requests for consent is transmitted once only. Hence, the > > sender cannot assume that it will receive a response for each consent > > request, and a response might be for a previous request (rather than > > for the most recently sent request). Consent expiration causes > > immediate termination of all outstanding STUN consent transactions. > > Each STUN transaction is maintained until one of the following > > criteria is fulfilled: > > > > o A STUN response associated with the transaction is received; or > > > > o A STUN response associated to a newer transaction is received. > > > > The above mechanism has several drawbacks: > > > > 1. No RTT/RTO estimation - and given that responses to a request that > arrive > > after a new request is sent are ignored, no ability to make use of the > > information that is available. Effectively, the specification sets the > RTO > > to be a random value between 4 and 6 seconds, with no relationship to > > network characteristics. > > > > 2. Inconsistent number of requests before failure. Given the > randomization, > > 4 to 6 requests might be sent within the 30 seconds. > > > > 3. Unclear timer behavior. Does an implementation continue to send > requests > > until 30 seconds has elapsed, or does it stop before then so as to allow > for > > a response to the last request to arrive? One could interpret the above > to > > imply that requests continue to be sent for up to 30 seconds, but the > last > > request is considered failed as soon as the 30 second timer expires. > > > > Detailed comments below. > > > > Abstract > > > > To prevent sending excessive traffic to an endpoint, periodic consent > needs > > to be obtained from that remote endpoint. > > > > [BA] This sentence is puzzling, since Section 1 does not mention > preventing > > "excessive traffic" as an objective - focusing instead of prevention of > > denial of service attacks. > > > > AFAICT, the consent freshness mechanism does not actually prevent > sending of > > excessive traffic, nor is it intended to. That is the role of congestion > > control mechanisms such as those under development in RMCAT, or prior to > > their deployment, the objective of the "Circuit Breakers" mechanism. > > > > As an example, the consent mechanism does not restrict the sending of > video > > on a connection that was only intended for audio, although it would be > > possible for a peer receiving unwanted media to revoke consent. > > > > My suggested rewording is as follows: > > > > "To prevent browsers supporting WebRTC from being used to launch denial > of > > service attacks by sending media to unsuspecting victims, periodic > consent > > needs to be obtained from remote endpoints." > > > > Section 4.1 > > > > An endpoint MUST NOT send data other than paced STUN connectivity checks > or > > responses toward any transport address unless the receiving endpoint > > consents to receive data. That is, no application data (e.g., RTP or > DTLS) > > can be sent until consent is obtained. After a successful ICE > connectivity > > check on a particular transport address, consent MUST be maintained > > following the procedure described in this document. > > > > [BA] The last sentence seems to imply that consent checks are scheduled > > before ICE completes, and would therefore interact with the scheduling > and > > pacing mechanism specified in RFC 5245. This does make some sense, > since in > > Trickle ICE, trickling all the candidates might take a while, and media > > might be sent after a successful response, so that consent would be in > > order. However, if that is the intent, then it needs to be explicitly > > stated, and this document > > needs to contain an Updates: RFC 5245 header. > > > > Each STUN binding request for consent MUST use a new cryptographically > > strong [RFC4086] STUN transaction ID. > > > > [BA] I think that RFC 5389 Section 6 says what is in intended here in a > more > > precise way, so it should be referenced instead: > > > > As such, the transaction ID MUST be uniformly > > and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be > > cryptographically random. > > > > After consent is lost for any reason, the same ICE credentials MUST NOT > be > > used on the affected 5-tuple again. That means that a new session, or an > ICE > > restart, is needed to obtain consent to send. > > > > [BA] The second sentence does not follow from the first. RFC 5245 enables > > sending of media once a successful ICE connectivity check has been > received. > > If multiple successful candidate pairs have been identified, why should > > failure of consent on one candidate pair require an ICE restart if > another > > operational candidate pair exists? > > > > Also, it is not clear what "any reason" means - the document only > discusses > > loss of consent due to lack of a response to consent checks. What other > > reasons are there? > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > --047d7b5d504e4b06f205177c0bd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Comments on the PR:=C2=A0

+pai= r when the pair enters Succeeded ICE state. =C2=A0consent; this document
+establishes a 30 second expiry time on consent.

[BA] Is the text starting from "consent;" intended to be t= here? Looks like a cut/paste error.=C2=A0

+Consent= expires after 30 seconds. That is, if a valid STUN binding response has
+not been received from the remote peer's transport address in = 30 seconds, the
+endpoint MUST cease transmission on that 5-tuple= . STUN consent responses
+received after consent expiry do not re= -establish consent, and may be discarded
+or cause an ICMP error.=

[BA] If a response still has not been received, b= ut the RTO timer has not expired, why should consent be revoked just becaus= e the 30 second timer elapsed? As an example, if a request is sent at 29.9 = seconds, and the RTO timer is 2 seconds, why should consent be revoked only= 100 ms after sending the request?? Also, this text does not appear consist= ent with the text below:=C2=A0

+periodically. To p= revent synchronization of consent checks, each interval MUST
+be = randomized from between 0.8 and 1.2 times the basic period. Implementations=
+SHOULD set a default interval of 5 seconds, resulting in a peri= od between checks
+of 4 to 6 seconds.=C2=A0 This timer is indepen= dent of the consent expiry timeout.
+</t>
+<t&= gt;
+Each STUN binding request for consent MUST use a new STUN tr= ansaction identifier
+for every consent binding request, as descr= ibed in Section 6 of <xref
+target=3D"RFC5389"/>.= Each STUN binding request for consent is transmitted once
+only.= A sender therefore cannot assume
+that it will receive a respons= e for every consent request, and a response might
+be for a previ= ous request (rather than for the most recently sent request).
+&l= t;/t>
+<t>
+An endpoint SHOULD await a binding= response for each request it sends for a time
+based on the esti= mated round-trip time (RTT) (see Section 7.2.1 of <xref
+targe= t=3D"RFC5389"/>) with an allowance for variation in network de= lay.=C2=A0 The RTT
+value can be updated as described in <xref= target=3D"RFC5389"/>.=C2=A0 After this time
+elapse= s, an endpoint can discard associated state and ignore any late responses.<= /div>

[BA] I do not understand why responses arriving af= ter the RTO timer expires are completely ignored.=C2=A0 Post-RTO responses = not only indicate that consent has been maintained, but also that the RTO n= eeds to be revised upwards.=C2=A0 So I would consider deleting the last sen= tence.=C2=A0

+All outstanding STUN consent transac= tions for a candidate pair MUST be discarded
+when consent expire= s.

[BA] This part does make sense.=C2=A0 But overa= ll, the paragraph seems to indicate that consent expires at max(30, Tlast-r= equest + RTO), not 30 seconds.=C2=A0

On Fri, May 22, 2015 at 3:23 PM, Marti= n Thomson <martin.thomson@gmail.com> wrote:
To reset the thread, here are the changes that I a= m going to propose:

https://github.com/martinthoms= on/IETF-drafts-1/compare/vc...martinthomson:bernard-consent

I have a pull request on the repo that you can follow, but the diff
there is a complete mess due to some nasty version control issues:

https://github.com/Draft-Mafia/IETF-drafts/pull/10

The following changes are substantive in some sense:

Consent is maintained now by receiving a valid response. Previously,
it was receiving a response to one of the checks that were initiated
in the 30s window (which would have prevented this from working with
RTT approaching 30s, so I considered it harmless). This change should
make it more robust.

Requests are abandoned when RTT (+delta) expires or when consent is
lost. Requests aren't abandoned by receiving a response to a later
request (the unlikely out of order request Bernard was concerned
with). This means that there is another timer that runs, in theory
(clever implementers will learn that this timer doesn't need to be an actual timer).


On 20 May 2015 at 16:48, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> This is a review of dra= ft-ietf-rtcweb-stun-consent-freshness.
>
> Overall, I believe that this document is not yet ready for publication= as a
> proposed standard,
> due to transport-related issues.=C2=A0 Rather than building upon the R= FC 5389
> transport model
> (including the transaction structure and RTT/RTO estimator), the
> specification proposes a
> new (and poorly specified) transport model that does not adapt properl= y
> to networks with differing transport characteristics.
>
> RFC 5389 Section 7.2.1 describes how stun handles retransmissions and<= br> > RTT/RTO computation:
>
>=C2=A0 =C2=A0 The RTO is an estimate of the round-trip time (RTT),
>=C2=A0 =C2=A0 and is computed as described in RFC 2988 [RFC2988], with = two
>=C2=A0 =C2=A0 exceptions.=C2=A0 First, the initial value for RTO SHOULD= be configurable
>=C2=A0 =C2=A0 (rather than the 3 s recommended in RFC 2988) and SHOULD = be greater
>=C2=A0 =C2=A0 than 500 ms.=C2=A0 The exception cases for this "SHO= ULD" are when other
>=C2=A0 =C2=A0 mechanisms are used to derive congestion thresholds (such= as the ones
>=C2=A0 =C2=A0 defined in ICE for fixed rate streams), or when STUN is u= sed in non-
>=C2=A0 =C2=A0 Internet environments with known network capacities.=C2= =A0 In fixed-line
>=C2=A0 =C2=A0 access links, a value of 500 ms is RECOMMENDED.=C2=A0 Sec= ond, the value of
>=C2=A0 =C2=A0 RTO SHOULD NOT be rounded up to the nearest second.=C2=A0= Rather, a 1 ms
>=C2=A0 =C2=A0 accuracy SHOULD be maintained.=C2=A0 As with TCP, the usa= ge of Karn's
>=C2=A0 =C2=A0 algorithm is RECOMMENDED [KARN87].=C2=A0 When applied to = STUN, it means
>=C2=A0 =C2=A0 that RTT estimates SHOULD NOT be computed from STUN trans= actions that
>=C2=A0 =C2=A0 result in the retransmission of a request.
>
>=C2=A0 =C2=A0 The value for RTO SHOULD be cached by a client after the = completion
>=C2=A0 =C2=A0 of the transaction, and used as the starting value for RT= O for the
>=C2=A0 =C2=A0 next transaction to the same server (based on equality of= IP
>=C2=A0 =C2=A0 address).=C2=A0 The value SHOULD be considered stale and = discarded after
>=C2=A0 =C2=A0 10 minutes.
>
>=C2=A0 =C2=A0 Retransmissions continue until a response is received, or= until a
>=C2=A0 =C2=A0 total of Rc requests have been sent.=C2=A0 Rc SHOULD be c= onfigurable and
>=C2=A0 =C2=A0 SHOULD have a default of 7.=C2=A0 If, after the last requ= est, a duration
>=C2=A0 =C2=A0 equal to Rm times the RTO has passed without a response (= providing
>=C2=A0 =C2=A0 ample time to get a response if only this final request a= ctually
>=C2=A0 =C2=A0 succeeds), the client SHOULD consider the transaction to = have failed.
>=C2=A0 =C2=A0 Rm SHOULD be configurable and SHOULD have a default of 16= .=C2=A0 A STUN
>=C2=A0 =C2=A0 transaction over UDP is also considered failed if there h= as been a
>=C2=A0 =C2=A0 hard ICMP error [RFC1122].=C2=A0 For example, assuming an= RTO of 500 ms,
>=C2=A0 =C2=A0 requests would be sent at times 0 ms, 500 ms, 1500 ms, 35= 00 ms, 7500
>=C2=A0 =C2=A0 ms, 15500 ms, and 31500 ms.=C2=A0 If the client has not r= eceived a
>=C2=A0 =C2=A0 response after 39500 ms, the client will consider the tra= nsaction to
>=C2=A0 =C2=A0 have timed out.
>
> The above mechanism addresses a number of issues:
>
> 1. Adaptation of the RTO via RTT measurement
> 2. Consistent number of requests sent without a response (Rc) before > transaction failure
> 3. Total time to transaction failure robust against routing transients=
>
> Unfortunately, rather than reusing all or part of this approach, the c= onsent
> freshness specification invents an new and poorly specified transport = scheme
> in Section 4.1:
>
>=C2=A0 =C2=A0 Initial consent to send traffic is obtained using ICE.=C2= =A0 Consent
>=C2=A0 =C2=A0 expires after 30 seconds.=C2=A0 That is, if a valid STUN = binding response
>=C2=A0 =C2=A0 corresponding to any STUN request sent in the last 30 sec= onds has not
>=C2=A0 =C2=A0 been received from the remote peer's transport addres= s, the endpoint
>=C2=A0 =C2=A0 MUST cease transmission on that 5-tuple.=C2=A0 STUN conse= nt responses
>=C2=A0 =C2=A0 received after consent expiry do not re-establish consent= , and may be
>=C2=A0 =C2=A0 discarded or cause an ICMP error.
>
>=C2=A0 =C2=A0 To prevent expiry of consent, a STUN binding request can = be sent
>=C2=A0 =C2=A0 periodically.=C2=A0 To prevent synchronization of consent= checks, each
>=C2=A0 =C2=A0 interval MUST be randomized from between 0.8 and 1.2 time= s the basic
>=C2=A0 =C2=A0 period.=C2=A0 Implementations SHOULD set a default interv= al of 5 seconds,
>=C2=A0 =C2=A0 resulting in a period between checks of 4 to 6 seconds. >
>=C2=A0 =C2=A0 Each STUN binding request for consent MUST use a new
>=C2=A0 =C2=A0 cryptographically strong [RFC4086] STUN transaction ID.= =C2=A0 Each STUN
>=C2=A0 =C2=A0 binding requests for consent is transmitted once only.=C2= =A0 Hence, the
>=C2=A0 =C2=A0 sender cannot assume that it will receive a response for = each consent
>=C2=A0 =C2=A0 request, and a response might be for a previous request (= rather than
>=C2=A0 =C2=A0 for the most recently sent request).=C2=A0 Consent expira= tion causes
>=C2=A0 =C2=A0 immediate termination of all outstanding STUN consent tra= nsactions.
>=C2=A0 =C2=A0 Each STUN transaction is maintained until one of the foll= owing
>=C2=A0 =C2=A0 criteria is fulfilled:
>
>=C2=A0 =C2=A0 o=C2=A0 A STUN response associated with the transaction i= s received; or
>
>=C2=A0 =C2=A0 o=C2=A0 A STUN response associated to a newer transaction= is received.
>
> The above mechanism has several drawbacks:
>
> 1. No RTT/RTO estimation - and given that responses to a request that = arrive
> after a new request is sent are ignored, no ability to make use of the=
> information that is available. Effectively, the specification sets the= RTO
> to be a random value between 4 and 6 seconds, with no relationship to<= br> > network characteristics.
>
> 2. Inconsistent number of requests before failure.=C2=A0 Given the ran= domization,
> 4 to 6 requests might be sent within the 30 seconds.
>
> 3. Unclear timer behavior.=C2=A0 Does an implementation continue to se= nd requests
> until 30 seconds has elapsed, or does it stop before then so as to all= ow for
> a response to the last request to arrive?=C2=A0 One could interpret th= e above to
> imply that requests continue to be sent for up to 30 seconds, but the = last
> request is considered failed as soon as the 30 second timer expires. >
> Detailed comments below.
>
> Abstract
>
> To prevent sending excessive traffic to an endpoint, periodic consent = needs
> to be obtained from that remote endpoint.
>
> [BA] This sentence is puzzling, since Section 1 does not mention preve= nting
> "excessive traffic" as an objective -=C2=A0 focusing instead= of prevention of
> denial of service attacks.
>
> AFAICT, the consent freshness mechanism does not actually prevent send= ing of
> excessive traffic, nor is it=C2=A0 intended to. That is the role of co= ngestion
> control mechanisms such as those under development in RMCAT, or prior = to
> their deployment, the objective of the "Circuit Breakers" me= chanism.
>
> As an example,=C2=A0 the consent mechanism does not restrict the sendi= ng of video
> on a connection that was only=C2=A0 intended for audio, although it wo= uld be
> possible for a peer receiving unwanted media to revoke consent.
>
> My suggested rewording is as follows:
>
> "To prevent browsers supporting WebRTC from being used to launch = denial of
> service attacks by sending media to unsuspecting victims, periodic con= sent
> needs to be obtained from remote endpoints."
>
> Section 4.1
>
> An endpoint MUST NOT send data other than paced STUN connectivity chec= ks or
> responses toward any transport address=C2=A0 unless the receiving endp= oint
> consents to receive data. That is, no application data (e.g., RTP or D= TLS)
> can be=C2=A0 sent until consent is obtained. After a successful ICE co= nnectivity
> check on a particular transport address, consent MUST be maintained > following the procedure described in this document.
>
> [BA] The last sentence seems to imply that consent checks are schedule= d
> before ICE completes, and would therefore interact with the scheduling= and
> pacing mechanism specified in RFC 5245.=C2=A0 This does make some sens= e, since in
> Trickle ICE, trickling all the candidates might take a while, and medi= a
> might be sent after a successful response, so that consent would be in=
> order.=C2=A0 However, if that is the intent, then it needs to be expli= citly
> stated, and this document
> needs to contain an Updates: RFC 5245 header.
>
> Each STUN binding request for consent MUST use a new cryptographically=
> strong [RFC4086] STUN transaction ID.
>
> [BA] I think that RFC 5389 Section 6 says what is in intended here in = a more
> precise way, so it should be referenced instead:
>
>=C2=A0 =C2=A0 As such, the transaction ID MUST be uniformly
>=C2=A0 =C2=A0 and randomly chosen from the interval 0 .. 2**96-1, and S= HOULD be
>=C2=A0 =C2=A0 cryptographically random.
>
> After consent is lost for any reason, the same ICE credentials MUST NO= T be
> used on the affected 5-tuple again. That means that a new session, or = an ICE
> restart, is needed to obtain consent to send.
>
> [BA] The second sentence does not follow from the first. RFC 5245 enab= les
> sending of media once a successful ICE connectivity check has been rec= eived.
> If multiple successful candidate pairs have been identified, why shoul= d
> failure of consent on one candidate pair require an ICE restart if ano= ther
> operational candidate pair exists?
>
> Also, it is not clear what "any reason" means - the document= only discusses
> loss of consent due to lack of a response to consent checks.=C2=A0 Wha= t other
> reasons are there?
>
> __________________= _____________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

--047d7b5d504e4b06f205177c0bd6-- From nobody Mon Jun 1 15:50:53 2015 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 09E3B1A1A7E; Mon, 1 Jun 2015 15:50:51 -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 K99Ushi9inAj; Mon, 1 Jun 2015 15:50:49 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143CB1A19FE; Mon, 1 Jun 2015 15:50:49 -0700 (PDT) Received: by yhom41 with SMTP id m41so37362626yho.1; Mon, 01 Jun 2015 15:50:48 -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=G8EXoLG4V7dbDE0Up15zfXSrXsewhxVU499cpZ5We3I=; b=BGP2MwfF1Ll0c6gfxZIQQ8/UX5CIwP/TSkuwmWDQeVEWWRIF1VAZSfT4+hALOLg25B /nKe34JJpyTMYvpZD+lPZ8NFepZEgPV5DVMYr/h8hdl46cGwMX6ObIKrXO6EXDzxrBtf 7zOoxIsrZYryJA85uL9+41mXXWttwOlbft5BWbbpV1rCp13wqxtMiXw5xjHv+WfcHdx2 KniDRLb4pZadNl6yXd3gk4Zz98urUMYoDN4Wj2SVbep+Sw45A3igiOMFxhZ0mbrou4cf hoDbX9gqnC9UksqrSwUvSCSONGj5RfYzBvA1//8g1qMwvkL1KkqXw6h0k3HA9u8A3llj Rlgg== MIME-Version: 1.0 X-Received: by 10.236.47.169 with SMTP id t29mr25264933yhb.69.1433199048423; Mon, 01 Jun 2015 15:50:48 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Mon, 1 Jun 2015 15:50:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2015 15:50:48 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" , The IESG Subject: Re: [rtcweb] Review of 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, 01 Jun 2015 22:50:51 -0000 On 1 June 2015 at 15:06, Bernard Aboba wrote: > Comments on the PR: > > +pair when the pair enters Succeeded ICE state. consent; this document > +establishes a 30 second expiry time on consent. > > [BA] Is the text starting from "consent;" intended to be there? Looks like a > cut/paste error. The latter statement was intended to be there. > [BA] If a response still has not been received, but the RTO timer has not > expired, why should consent be revoked just because the 30 second timer > elapsed? As an example, if a request is sent at 29.9 seconds, and the RTO > timer is 2 seconds, why should consent be revoked only 100 ms after sending > the request?? Also, this text does not appear consistent with the text > below: If you sent something 100ms ago, then it might be useful in the future, but for now, your consent has expired. Extending the window to max(30, Tlast-request + RTO) is extending the window. It's also more complicated to implement. I'm not sure how that would be inconsistent; the text below says that consent expiry is independent of check interval. If I were to implement this (as I once did), I would initiate a check every 5s, awaiting a response for each separately. If one of those succeeded, I would update a "lastSuccessfulCheck" variable to the current time. Then when sending, I would check that "lastSuccessfulCheck" is more recent than (now - 30s). If so, explode. Or you can run a 30s timer that you reset each time a check succeeds. Explode if it ever actually runs to completion without being reset. Neither of those needs to care about RTO. The implementation of the checking might (in practice, you can just wait. > +An endpoint SHOULD await a binding response for each request it sends for a > time > +based on the estimated round-trip time (RTT) (see Section 7.2.1 of +target="RFC5389"/>) with an allowance for variation in network delay. The > RTT > +value can be updated as described in . After this > time > +elapses, an endpoint can discard associated state and ignore any late > responses. > > [BA] I do not understand why responses arriving after the RTO timer expires > are completely ignored. Post-RTO responses not only indicate that consent > has been maintained, but also that the RTO needs to be revised upwards. So > I would consider deleting the last sentence. OK. Done. > > +All outstanding STUN consent transactions for a candidate pair MUST be > discarded > +when consent expires. > > [BA] This part does make sense. But overall, the paragraph seems to > indicate that consent expires at max(30, Tlast-request + RTO), not 30 > seconds. I don't know how you get that. It's certainly isn't the intent. From nobody Mon Jun 1 20:14:17 2015 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 A28371A90B9; Mon, 1 Jun 2015 20:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 CZ0L-k4HCSFE; Mon, 1 Jun 2015 20:14:10 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16071A90B4; Mon, 1 Jun 2015 20:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49378; q=dns/txt; s=iport; t=1433214850; x=1434424450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jREaBhxft+P/2wE3a0NlugwOheBwJDHtjon4brYHMsk=; b=byZQgzMXSNB8Bipr9padEAsBQ2ze8tHOjMflc+8TxRaIfim6LKIrkT9i 5rTiD769UZjqZlfLI89Pj/Pbr1THWRD8Z4HMOyVXami50RheZH+2C8qhb nfkkvZlyxivcBikIK7r6nOZyYPM0n1bXOboXV/9Alm4/LRMM1q7iIbU7E w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DIBgDZHm1V/4oNJK1cgkVLVF4Ggxi6WTwqCYE3GQEJhS1KAhyBFzgUAQEBAQEBAYEKhCIBAQEDAQEBASAKQQsFCwIBCBEEAQELFgEGAwICAh8GCxQJCAIEDgUIiBADCggNtG2edQ2FGwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLQ4JNgggWFwQGAYJoL4EWBZBSgj6ENoUEgwc+jW1dhwUjYYEpHIFSb4EDBzyBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,536,1427760000"; d="scan'208,217";a="155357520" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP; 02 Jun 2015 03:14:08 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t523E8fh019471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jun 2015 03:14:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 22:14:08 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Muthu Arul Mozhi Perumal , "Black, David" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAc0OqAABAN2oAAKb4SAAABtAIAAApo7AAACcBoUP//vfsAgABAAjCAAM2OAIAEYv0A//9oT2A= Date: Tue, 2 Jun 2015 03:14:07 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47862F06@xmb-rcd-x10.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861447@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.48.236] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A47862F06xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb-chairs@tools.ietf.org" , "ops-dir@ietf.org" , joel jaeggli , "rtcweb@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 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, 02 Jun 2015 03:14:13 -0000 --_000_913383AAA69FF945B8F946018B75898A47862F06xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIFttYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5j b21dDQpTZW50OiBNb25kYXksIEp1bmUgMDEsIDIwMTUgNjo0MSBQTQ0KVG86IEJsYWNrLCBEYXZp ZA0KQ2M6IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IENocmlzdGVyIEhvbG1iZXJnOyBU ZWQgSGFyZGllOyBqb2VsIGphZWdnbGk7IG9wcy1kaXJAaWV0Zi5vcmc7IHJ0Y3dlYkBpZXRmLm9y ZzsgcnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIE9Q Uy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3Mt MTMNCg0KSSB0aGluayBSRkM1MjQ1IGRvZXMgbm90IHJ1bGUgb3V0IHNvbWVvbmUgdXNpbmcgU1RV TiBiaW5kaW5nIHJlcXVlc3RzIGZvciBrZWVwYWxpdmU6DQoNCjxzbmlwPg0KICAgVGhvdWdoIEJp bmRpbmcgSW5kaWNhdGlvbnMgYXJlIHVzZWQgZm9yIGtlZXBhbGl2ZXMsDQogICBhbiBhZ2VudCBN VVNUIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgYSBjb25uZWN0aXZpdHkgY2hlY2sgYXMgd2VsbC4N CiAgIElmIGEgY29ubmVjdGl2aXR5IGNoZWNrIGlzIHJlY2VpdmVkLCBhIHJlc3BvbnNlIGlzIGdl bmVyYXRlZCBhcw0KICAgZGlzY3Vzc2VkIGluIFtSRkM1Mzg5XSwgYnV0IHRoZXJlIGlzIG5vIGlt cGFjdCBvbiBJQ0UgcHJvY2Vzc2luZw0KICAgb3RoZXJ3aXNlLg0KPC9zbmlwPg0KDQpPTEQ6DQog ICAgSWYgY29uc2VudCBpcyBwZXJmb3JtZWQgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQg a2VlcGFsaXZlIG1lc3NhZ2VzLg0KDQpTdWdnZXN0ZWQgTkVXOg0KICAgSWYgY29uc2VudCBpcyBw ZXJmb3JtZWQgdGhlbiB0aGUgU1RVTiBiaW5kaW5nIHJlcXVlc3RzIHNlbnQgZm9yIGNvbnNlbnQN CiAgIGZyZXNobmVzcyBhbHNvIHNlcnZlIHRoZSBrZWVwYWxpdmUgcHVycG9zZS4NCg0KVXBkYXRl ZCBpbiBteSBsb2NhbCBjb3B5Lg0KDQotVGlydQ0KDQpUaGF0IGlzIGVmZmVjdGl2ZWx5IHdoYXQg UkZDNTI0NSBzYXlzIGZvciBrZWVwYWxpdmUuLg0KDQpNdXRodQ0KDQpPbiBGcmksIE1heSAyOSwg MjAxNSBhdCAxMTo0MSBQTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0 bzpkYXZpZC5ibGFja0BlbWMuY29tPj4gd3JvdGU6DQpUaGF0IGFsc28gd29ya3MgZm9yIG1lLCBh bmQgbmVhdGx5IHNpZGVzdGVwcyB0aGUgY29uY2VybiBhYm91dA0Kd2hldGhlciBSRkMgNTI0NSBp cyBiZWluZyB1cGRhdGVkLg0KDQpUaGFua3MsDQotLURhdmlkDQoNCkZyb206IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRk eUBjaXNjby5jb20+XQ0KU2VudDogVGh1cnNkYXksIE1heSAyOCwgMjAxNSAxMToyMCBQTQ0KVG86 IENocmlzdGVyIEhvbG1iZXJnOyBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQNCg0KQ2M6IGpvZWwg amFlZ2dsaTsgb3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRpckBpZXRmLm9yZz47IHJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcnRjd2ViLWNoYWlyc0B0b29scy5p ZXRmLm9yZzxtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNl bnQtZnJlc2huZXNzLTEzDQoNCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KU2VudDogRnJpZGF5LCBNYXkgMjksIDIwMTUgNzoz NyBBTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFRlZCBIYXJkaWU7IEJsYWNr LCBEYXZpZA0KQ2M6IGpvZWwgamFlZ2dsaTsgb3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRp ckBpZXRmLm9yZz47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcnRj d2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRm LXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEzDQoNCkhpLA0KDQo+R29vZCBwb2ludC4g V2UgZGlzY3VzcyB0aGUgZm9sbG93aW5nIHBvaW50IGluIHNlY3Rpb24gNC4xIG9mIHRoZSBkcmFm dCBhYm91dCBrZWVwYWxpdmVzOg0KPg0KPiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRp bmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bw0KPiAgIG1haW50YWluIGNv bnNlbnQuICBIb3dldmVyLCBub3Qgc2VuZGluZyBhbnkgdHJhZmZpYyBjb3VsZCBjYXVzZSBOQVQN Cj4gICBvciBmaXJld2FsbCBtYXBwaW5ncyB0byBleHBpcmUuICBGdXJ0aGVybW9yZSwgaGF2aW5n IG9uZSBwZWVyIHVuYWJsZQ0KPiAgIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90 b2NvbHMuICBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uDQo+ICAgYWJvdXQgdGhlIG5ldHdvcmss IGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsDQo+ICAg bWFwcGluZ3MgZG8gbm90IGV4cGlyZSwgaXQgY2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9y IG90aGVyDQo+ICAgdGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdPGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi0xMD4gYW5kIHNlZSBbUkZDNjI2 MzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjYzPl0pLg0KPg0KPiBTbyB0aGVyZSBp cyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlcyBiZWNhdXNlIG9mIHRoZSBtZWRpYSB0cmFmZmlj IGFzIGl0IGlzIHBvaW50ZWQgb3V0IGluIFNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1MjQ1DQo+IGly cmVzcGVjdGl2ZSBvZiB3aGV0aGVyIGNvbnNlbnQgaXMgdXNlZCBvciBub3QuIEkgdGhpbmsgd2Ug Y2FuIHJlbW92ZSB0aGUgZm9sbG93aW5nIGxpbmUgaW4g4oCcSWYgY29uc2VudCBpcyBwZXJmb3Jt ZWQgdGhlbg0KPiB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLiIg YW5kIGF2b2lkIHRoZSBjb25mdXNpb24gb2YgdXBkYXRpbmcgUkZDIDUyNDUuDQoNCkkgYWdyZWUg dGhhdCB0aGUgY3VycmVudCB0ZXh0IGNhbiBjb25mdXNlIHBlb3BsZSwgYnV0IEkgc3RpbGwgdGhp bmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGV4cGxpY2l0IHRleHQgc2F5aW5nIHRoYXQga2Vl cGFsaXZlcyBhcmUgbm90IHNlbnQuIFBlcmhhcHMgc29tZXRoaW5nIGxpa2U6DQoNCuKAnEZyb20g YSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQg bWVkaWEgdHJhZmZpYy4gQmVjYXVzZSBvZiB0aGF0LCBkZWRpY2F0ZWQga2VlcGFsaXZlcyAoZS5n LiBTVFVOIGJpbmRpbmcgcmVxdWVzdHMpIGFyZSBub3Qgc2VudCBvbiBjYW5kaWRhdGUgcGFpcnMg d2hlcmUgY29uc2VudCByZXF1ZXN0cyBhcmUgc2VudCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rp b24gMjAuMi4zIG9mIFtSRkM1MjQ1XS7igJ0NCg0KV29ya3MgZm9yIG1lIChSZXBsYWNlZCBTVFVO IGJpbmRpbmcgcmVxdWVzdHMgd2l0aCBTVFVOIEJpbmRpbmcgSW5kaWNhdGlvbnMgaW4gdGhlIGFi b3ZlIGxpbmUpLg0KDQpDaGVlcnMsDQotVGlydQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN CkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IEZyaWRheSwgTWF5IDI5LCAyMDE1IDY6NTQgQU0N ClRvOiBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQNCkNjOiBqb2VsIGphZWdnbGk7IG9wcy1kaXJA aWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz47IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gT1BTLURp ciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMw0K DQoNCkhpLA0KDQpTZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NSBzYXlzOg0KDQrigJxTVFVOIGtl ZXBhbGl2ZXMgKGluIHRoZSBmb3JtIG9mIFNUVU4gQmluZGluZyBJbmRpY2F0aW9ucykgYXJlIHNl bnQgaW4NCiAgICAgICAgICAgICAgdGhlIG1pZGRsZSBvZiBhIG1lZGlhIHNlc3Npb24uICBIb3dl dmVyLCB0aGV5IGFyZSBzZW50IG9ubHkgaW4gdGhlDQogICAgICAgICAgICAgIGFic2VuY2Ugb2Yg YWN0dWFsIG1lZGlhIHRyYWZmaWMu4oCdDQoNClNvLCBpbiB0aGUgY29uc2VudCBkcmFmdCB3ZSBj b3VsZCBzYXkgdGhhdCwgZnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVjdGl2ZSwgY29uc2VudCByZXF1 ZXN0cyBhcmUgY29uc2lkZXJlZCBtZWRpYSB0cmFmZmljLiBUaGF0IHdvdWxkIHRoZW4gaW1wbGlj aXRseSBtZWFuIHRoYXQgYWN0dWFsIGtlZXBhbGl2ZXMgYXJlbuKAmXQgc2VudCB3aGVuIGNvbnNl bnQgaXMgdXNlZC4gVGhhdCB3YXksIHRoZSBjb25zZW50IHNwZWMgd291bGQgYmUgY29tcGxpYW50 IHRvIDUyNDUsIGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciBhbnkgdXBkYXRlIGV0Y+KA pg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dl Yi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2VudDogMjggTWF5 IDIwMTUgMjM6MjYNClRvOiBCbGFjaywgRGF2aWQNCkNjOiBydGN3ZWItY2hhaXJzQHRvb2xzLmll dGYub3JnPG1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgam9lbCBqYWVnZ2xp OyBvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPjsgcnRjd2ViQGlldGYu b3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gT1BTLURp ciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMw0K DQpIaSBEYXZpZCwNCg0KT24gVGh1LCBNYXkgMjgsIDIwMTUgYXQgMTI6MzYgUE0sIEJsYWNrLCBE YXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbT4+DQoN CkknZCBleHBlY3QgdGhhdCBldmVuIG92ZXJyaWRpbmcgUkZDIDUyNDUgY291bnRzIGFzIGFuIFVw ZGF0ZSwNCmJlY2F1c2UgdGhlIHJlc3VsdCB3b3VsZCBiZSB0aGF0IHRoZSBvcmlnaW5hbCBSRkMg NTI0NSAiTVVTVCIgcmVxdWlyZW1lbnQNCmlzIG5vIGxvbmdlciBnbG9iYWxseSBhcHBsaWNhYmxl IHRvIGFsbCB1c2VzIG9mIFJGQyA1MjQ1LiAgSW4gb3RoZXIgd29yZHMsDQpvdmVycmlkaW5nIFJG QyA1MjQ1IGVmZmVjdGl2ZWx5IHJld3JpdGVzIHRoZSAiTVVTVCIgdG8gYmVjb21lICJNVVNULCBl eGNlcHQNCmFzIGZ1cnRoZXIgc3BlY2lmaWVkIGJ5IHRoZSBjb25zZW50IFJGQy4iDQoNCuKAi1Nv IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2FsbGVkIG91dCwgYnV0IEkgdGhp bmsgIlVwZGF0ZXMiIGlzIHdyb25nIGZvciB0aGUgZHJhZnQncyBjdXJyZW50IGludGVudC4gIEkg dGhpbmsgd2hhdCBNYXJ0aW4gaGFzIHNhaWQgYW1vdW50cyB0byAiV2UgaGF2ZSBjaG9zZW4gdG8g Zm9sbG93IFJGQyA1MjQ1IGV4Y2VwdCBhcyBkZXRhaWxlZCBpbiBzZWN0aW9ucyBYIGFuZCBZLCB3 aGVyZSB3ZSB1c2UgYSBkaWZmZXJlbnQgc2V0IG9mIG1lc3NhZ2VzIHRvIG9wdGltaXplIHRoZSBj b21iaW5hdGlvbiBvZiBoZWFydGJlYXQgYW5kIGNvbnNlbnQuIiAgV2UgYXJlIG5vdCB1cGRhdGlu ZyBSRkMgNTI0NSB0aGVyZWJ5LCBiZWNhdXNlIHdlIGFyZSBuZWl0aGVyIGNoYW5naW5nIGl0cyBj b3JlIHNlbWFudGljcyBub3Igb2ZmZXJpbmcgdG8gYWRkIGEgbmV3LCBnZW5lcmFsIHNlbWFudGlj IHRvIFJGQyA1MjQ1ICh3ZSBjb3VsZCBoYXZlIG1hZGUgdGhhdCBjaG9pY2UsIGJ1dCBhcmUgbm90 IGRvaW5nIHNvIG5vdykuICBJbnN0ZWFkIG9mIHVwZGF0aW5nIFJGQyA1MjQ1LCBpbiBvdGhlciB3 b3Jkcywgd2UgYXJlIGxpbWl0aW5nIG91ciByZWZlcmVuY2UgdG8gaXQuDQpUaGF0IHNob3VsZCBi ZSBkb25lIGV4cGxpY2l0bHksIGFuZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBjYWxsZWQgaXQgc3Vm ZmlpY2llbnRseSB0aGF0IGEgbmV3IHNwaW4gb2YgdGhlIGRyYWZ0IGxpa2VseSBuZWVkcyBhIG5l dyByb3VuZCBvZiByZXZpZXcuICBCdXQgSSBkb24ndCB0aGluayB3ZSBhcmUgcmVxdWlyZWQgdG8g dXBkYXRlIFJGQyA1MjQ1IHRvIGdldCB0aGF0IGRvbmUuDQpJJ3ZlIHJlZmVycmVkIHRoZSBtYXR0 ZXIgdG8gb3VyIGZyaWVuZGx5IEFELCBhbmQgd2UgYXdhaXQgaGVyIHJlYWRpbmcgb24gbmV4dCBz dGVwcyBvbiB0aGlzLiAgSW4gZWl0aGVyIGFwcHJvYWNoLCBob3dldmVyLCB0aGlzIHdpbGwgZ2V0 IGNhbGxlZCBvdXQuDQpyZWdhcmRzLA0KVGVkIEhBcmRpZeKAiw0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_913383AAA69FF945B8F946018B75898A47862F06xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTXV0aHUgQXJ1 bCBNb3poaSBQZXJ1bWFsIFttYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBKdW5lIDAxLCAyMDE1IDY6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEJs YWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsg Q2hyaXN0ZXIgSG9sbWJlcmc7IFRlZCBIYXJkaWU7IGpvZWwgamFlZ2dsaTsgb3BzLWRpckBpZXRm Lm9yZzsgcnRjd2ViQGlldGYub3JnOyBydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRm LXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEzPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSB0aGluayBS RkM1MjQ1IGRvZXMgbm90IHJ1bGUgb3V0IHNvbWVvbmUgdXNpbmcgU1RVTiBiaW5kaW5nIHJlcXVl c3RzIGZvciBrZWVwYWxpdmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbHQ7c25p cCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtUaG91Z2ggQmluZGluZyBJbmRp Y2F0aW9ucyBhcmUgdXNlZCBmb3Iga2VlcGFsaXZlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNw O2FuIGFnZW50IE1VU1QgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBhIGNvbm5lY3Rpdml0eSBjaGVj ayBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7SWYgYSBjb25uZWN0aXZpdHkgY2hl Y2sgaXMgcmVjZWl2ZWQsIGEgcmVzcG9uc2UgaXMgZ2VuZXJhdGVkIGFzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOyAmbmJzcDtkaXNjdXNzZWQgaW4gW1JGQzUzODldLCBidXQgdGhlcmUgaXMgbm8gaW1wYWN0 IG9uIElDRSBwcm9jZXNzaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtvdGhlcndpc2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZsdDsvc25pcCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5PTEQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDsgSWYgY29uc2VudCBpcyBwZXJmb3Jt ZWQgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlN1Z2dlc3RlZCBORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtJZiBjb25z ZW50IGlzIHBlcmZvcm1lZCB0aGVuIHRoZSBTVFVOIGJpbmRpbmcgcmVxdWVzdHMgc2VudCBmb3Ig Y29uc2VudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ZnJlc2huZXNzIGFsc28gc2VydmUgdGhl IGtlZXBhbGl2ZSBwdXJwb3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VXBkYXRlZCBpbiBteSBsb2NhbCBjb3B5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGF0IGlzIGVmZmVjdGl2ZWx5IHdoYXQgUkZD NTI0NSBzYXlzIGZvciBrZWVwYWxpdmUuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11dGh1PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWF5IDI5LCAyMDE1IGF0IDExOjQxIFBNLCBCbGFjaywg RGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5UaGF0IGFsc28gd29ya3MgZm9yIG1lLCBhbmQgbmVhdGx5IHNpZGVzdGVwcyB0aGUgY29uY2Vy biBhYm91dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPndoZXRoZXIgUkZDIDUyNDUgaXMgYmVpbmcgdXBkYXRlZC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8YnI+DQotLURh dmlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KQ0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMjgsIDIwMTUgMTE6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+ IENocmlzdGVyIEhvbG1iZXJnOyBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPkNj OjwvYj4gam9lbCBqYWVnZ2xpOyA8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm9wcy1kaXJAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpy dGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50 LWZyZXNobmVzcy0xMzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDaHJpc3Rl ciBIb2xtYmVyZyBbPGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDI5LCAyMDE1IDc6MzcgQU08YnI+ DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFRlZCBIYXJkaWU7IEJs YWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj4gam9lbCBqYWVnZ2xpOyA8YSBocmVmPSJtYWlsdG86 b3BzLWRpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9wcy1kaXJAaWV0Zi5vcmc8L2E+Ow0K PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDs8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R29vZCBwb2ludC4gV2UgZGlzY3VzcyB0aGUgZm9sbG93 aW5nIHBvaW50IGluIHNlY3Rpb24gNC4xIG9mIHRoZSBkcmFmdCBhYm91dCBrZWVwYWxpdmVzOjwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyBBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5k aW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90IG5lZWQgdG88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 IG1haW50YWluIGNvbnNlbnQuJm5ic3A7IEhvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0cmFmZmlj IGNvdWxkIGNhdXNlIE5BVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgb3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8g ZXhwaXJlLiZuYnNwOyBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJsZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJz cDsmbmJzcDsgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy4mbmJzcDsg QWJzZW50IGJldHRlciBpbmZvcm1hdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgYWJvdXQgdGhlIG5ldHdv cmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0 OyZuYnNwOyZuYnNwOyBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2lu ZyBrZWVwYWxpdmUgb3Igb3RoZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IHRlY2huaXF1ZXMgKHNlZQ0KPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTEwIiB0YXJn ZXQ9Il9ibGFuayI+U2VjdGlvbiZuYnNwOzEwIG9mIFtSRkM1MjQ1XTwvYT4gYW5kIHNlZSBbPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI2MyIgdGFyZ2V0PSJfYmxhbmsi IHRpdGxlPSImcXVvdDtBcHBsaWNhdGlvbiBNZWNoYW5pc20gZm9yIEtlZXBpbmcgQWxpdmUgdGhl IE5BVCBNYXBwaW5ncyBBc3NvY2lhdGVkIHdpdGggUlRQIC8gUlRQIENvbnRyb2wgUHJvdG9jb2wg KFJUQ1ApIEZsb3dzJnF1b3Q7Ij5SRkM2MjYzPC9hPl0pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7 PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0Ow0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNvIHRoZXJlIGlzIG5vIG5lZWQg dG8gc2VuZCBrZWVwYWxpdmVzIGJlY2F1c2Ugb2YgdGhlIG1lZGlhIHRyYWZmaWMgYXMgaXQgaXMg cG9pbnRlZCBvdXQgaW4NCjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NQ0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7DQo8c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+aXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgY29uc2VudCBpcyB1c2VkIG9yIG5vdDwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi4g SSB0aGluayB3ZSBjYW4gcmVtb3ZlIHRoZSBmb2xsb3dpbmcgbGluZSBpbiDigJxJZiBjb25zZW50 IGlzIHBlcmZvcm1lZCB0aGVuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPnRoZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBrZWVwYWxpdmUgbWVzc2Fn ZXMuJnF1b3Q7IGFuZCBhdm9pZCB0aGUgY29uZnVzaW9uIG9mIHVwZGF0aW5nIFJGQyA1MjQ1Ljwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgYWdyZWUg dGhhdCB0aGUgY3VycmVudCB0ZXh0IGNhbiBjb25mdXNlIHBlb3BsZSwgYnV0IEkgc3RpbGwgdGhp bmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGV4cGxpY2l0IHRleHQgc2F5aW5nDQogdGhhdCBr ZWVwYWxpdmVzIGFyZSBub3Qgc2VudC4gUGVyaGFwcyBzb21ldGhpbmcgbGlrZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAnEZyb20gYSBrZWVwYWxpdmUgcGVy c3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEgdHJhZmZpYy4g QmVjYXVzZSBvZiB0aGF0LCBkZWRpY2F0ZWQga2VlcGFsaXZlcw0KIChlLmcuIFNUVU4gYmluZGlu ZyByZXF1ZXN0cykgYXJlIG5vdCBzZW50IG9uIGNhbmRpZGF0ZSBwYWlycyB3aGVyZSBjb25zZW50 IHJlcXVlc3RzIGFyZSBzZW50LCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiAyMC4yLjMgb2Yg W1JGQzUyNDVdLuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldvcmtzIGZvciBtZSAoUmVwbGFjZWQNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNUVU4gYmluZGluZyByZXF1ZXN0cyB3aXRo IFNUVU4gQmluZGluZyBJbmRpY2F0aW9ucyBpbiB0aGUgYWJvdmUgbGluZSkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pi1UaXJ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdhcmRz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hyaXN0ZXI8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g cnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSAy OSwgMjAxNSA2OjU0IEFNPGJyPg0KPGI+VG86PC9iPiBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQ8 YnI+DQo8Yj5DYzo8L2I+IGpvZWwgamFlZ2dsaTsgPGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vcHMtZGlyQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KcnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0 dW4tY29uc2VudC1mcmVzaG5lc3MtMTM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5T ZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NSBzYXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87dGV4dC1pbmRlbnQ6LjVpbiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnFNUVU4ga2VlcGFsaXZlcyAoaW4g dGhlIGZvcm0gb2YgU1RVTiBCaW5kaW5nIEluZGljYXRpb25zKSBhcmUgc2VudCBpbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBtaWRkbGUgb2YgYSBtZWRpYSBzZXNzaW9uLiZuYnNwOyBIb3dldmVyLA0KPGI+dGhleSBhcmUg c2VudCBvbmx5IGluIHRoZTwvYj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhYnNlbmNlIG9mIGFjdHVhbCBtZWRpYSB0cmFm ZmljPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvLCBpbiB0aGUgY29uc2VudCBkcmFmdCB3ZSBjb3VsZCBzYXkgdGhhdCwgZnJvbSBhIGtlZXBh bGl2ZSBwZXJzcGVjdGl2ZSwgY29uc2VudCByZXF1ZXN0cw0KIGFyZSBjb25zaWRlcmVkIG1lZGlh IHRyYWZmaWMuIFRoYXQgd291bGQgdGhlbiBpbXBsaWNpdGx5IG1lYW4gdGhhdCBhY3R1YWwga2Vl cGFsaXZlcyBhcmVu4oCZdCBzZW50IHdoZW4gY29uc2VudCBpcyB1c2VkLiBUaGF0IHdheSwgdGhl IGNvbnNlbnQgc3BlYyB3b3VsZCBiZSBjb21wbGlhbnQgdG8gNTI0NSwgYW5kIHRoZXJlIHdvdWxk IGJlIG5vIG5lZWQgZm9yIGFueSB1cGRhdGUgZXRj4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+IDI4 IE1heSAyMDE1IDIzOjI2PGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8 L2I+IDxhIGhyZWY9Im1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47IGpvZWwgamFlZ2dsaTsN CjxhIGhyZWY9Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BzLWRp ckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFty dGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1m cmVzaG5lc3MtMTM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkg RGF2aWQsDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24g VGh1LCBNYXkgMjgsIDIwMTUgYXQgMTI6MzYgUE0sIEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZpZC5ibGFja0Bl bWMuY29tPC9hPiZndDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KSSdkIGV4cGVjdCB0aGF0IGV2ZW4gb3ZlcnJpZGluZyBS RkMgNTI0NSBjb3VudHMgYXMgYW4gVXBkYXRlLDxicj4NCmJlY2F1c2UgdGhlIHJlc3VsdCB3b3Vs ZCBiZSB0aGF0IHRoZSBvcmlnaW5hbCBSRkMgNTI0NSAmcXVvdDtNVVNUJnF1b3Q7IHJlcXVpcmVt ZW50PGJyPg0KaXMgbm8gbG9uZ2VyIGdsb2JhbGx5IGFwcGxpY2FibGUgdG8gYWxsIHVzZXMgb2Yg UkZDIDUyNDUuJm5ic3A7IEluIG90aGVyIHdvcmRzLDxicj4NCm92ZXJyaWRpbmcgUkZDIDUyNDUg ZWZmZWN0aXZlbHkgcmV3cml0ZXMgdGhlICZxdW90O01VU1QmcXVvdDsgdG8gYmVjb21lICZxdW90 O01VU1QsIGV4Y2VwdDxicj4NCmFzIGZ1cnRoZXIgc3BlY2lmaWVkIGJ5IHRoZSBjb25zZW50IFJG Qy4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPuKAi1NvIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2FsbGVkIG91dCwg YnV0IEkgdGhpbmsgJnF1b3Q7VXBkYXRlcyZxdW90OyBpcyB3cm9uZyBmb3IgdGhlIGRyYWZ0J3Mg Y3VycmVudCBpbnRlbnQuJm5ic3A7IEkgdGhpbmsNCiB3aGF0IE1hcnRpbiBoYXMgc2FpZCBhbW91 bnRzIHRvICZxdW90O1dlIGhhdmUgY2hvc2VuIHRvIGZvbGxvdyBSRkMgNTI0NSBleGNlcHQgYXMg ZGV0YWlsZWQgaW4gc2VjdGlvbnMgWCBhbmQgWSwgd2hlcmUgd2UgdXNlIGEgZGlmZmVyZW50IHNl dCBvZiBtZXNzYWdlcyB0byBvcHRpbWl6ZSB0aGUgY29tYmluYXRpb24gb2YgaGVhcnRiZWF0IGFu ZCBjb25zZW50LiZxdW90OyZuYnNwOyBXZSBhcmUgbm90IHVwZGF0aW5nIFJGQyA1MjQ1IHRoZXJl YnksIGJlY2F1c2Ugd2UgYXJlDQogbmVpdGhlciBjaGFuZ2luZyBpdHMgY29yZSBzZW1hbnRpY3Mg bm9yIG9mZmVyaW5nIHRvIGFkZCBhIG5ldywgZ2VuZXJhbCBzZW1hbnRpYyB0byBSRkMgNTI0NSAo d2UgY291bGQgaGF2ZSBtYWRlIHRoYXQgY2hvaWNlLCBidXQgYXJlIG5vdCBkb2luZyBzbyBub3cp LiZuYnNwOyBJbnN0ZWFkIG9mIHVwZGF0aW5nIFJGQyA1MjQ1LCBpbiBvdGhlciB3b3Jkcywgd2Ug YXJlIGxpbWl0aW5nIG91ciByZWZlcmVuY2UgdG8gaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5U aGF0IHNob3VsZCBiZSBkb25lIGV4cGxpY2l0bHksIGFuZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBj YWxsZWQgaXQgc3VmZmlpY2llbnRseSB0aGF0IGEgbmV3IHNwaW4gb2YgdGhlIGRyYWZ0IGxpa2Vs eSBuZWVkcw0KIGEgbmV3IHJvdW5kIG9mIHJldmlldy4mbmJzcDsgQnV0IEkgZG9uJ3QgdGhpbmsg d2UgYXJlIHJlcXVpcmVkIHRvIHVwZGF0ZSBSRkMgNTI0NSB0byBnZXQgdGhhdCBkb25lLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SSd2ZSByZWZlcnJlZCB0aGUgbWF0dGVyIHRvIG91ciBmcmllbmRs eSBBRCwgYW5kIHdlIGF3YWl0IGhlciByZWFkaW5nIG9uIG5leHQgc3RlcHMgb24gdGhpcy4mbmJz cDsgSW4gZWl0aGVyIGFwcHJvYWNoLCBob3dldmVyLA0KIHRoaXMgd2lsbCBnZXQgY2FsbGVkIG91 dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5UZWQgSEFyZGll4oCLPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_913383AAA69FF945B8F946018B75898A47862F06xmbrcdx10ciscoc_-- From nobody Tue Jun 2 07:15:13 2015 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 75E9B1AC3F9; Tue, 2 Jun 2015 07:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MqxTPCVIrr8q; Tue, 2 Jun 2015 07:15:01 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 4C74B1A8979; Tue, 2 Jun 2015 07:15:01 -0700 (PDT) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t52EElgk002367 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Jun 2015 10:14:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t52EElgk002367 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1433254489; bh=SM/qugoOLHidjjKf+05Cyb0NCWs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=GIArbTg8uaPf0oZOWTh+OeUPKMJvsDEvAQ+arfcNzSdA+GKqEP7D7+k/KoYaj5hij 81bjCAX8rA0Yo3xj3tiuIeqAk7oPjAM80yxo74BmxYeoh41Z87BKit6c6PfHV/2OBq jXhrLEMjVBMNGH6rFL7pwOGBq5Skoz+kQ62fBZzY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com t52EElgk002367 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor); Tue, 2 Jun 2015 10:12:46 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t52EETXm032322 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jun 2015 10:14:30 -0400 Received: from MXHUB209.corp.emc.com (10.253.68.35) by mxhub04.corp.emc.com (10.254.141.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 2 Jun 2015 10:14:29 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.90]) by MXHUB209.corp.emc.com ([10.253.68.35]) with mapi id 14.03.0224.002; Tue, 2 Jun 2015 10:14:29 -0400 From: "Black, David" To: "Tirumaleswar Reddy (tireddy)" , "Muthu Arul Mozhi Perumal" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmbLQj9rK05idUkWAIovS2YdbXZ2Sd9wAgAAUeACAALWgYIAEpnUAgADrnoCAAHUfAA== Date: Tue, 2 Jun 2015 14:14:28 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861447@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A47862F06@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A47862F06@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.45.63] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949360B33A751MX104CL02corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "rtcweb-chairs@tools.ietf.org" , "Black, David" , "ops-dir@ietf.org" , joel jaeggli , "rtcweb@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 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, 02 Jun 2015 14:15:10 -0000 --_000_CE03DB3D7B45C245BCA0D243277949360B33A751MX104CL02corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmXigJlzIGJlZW4gYSBsb3Qgb2YgZGlzY3Vzc2lvbiAtIHdvdWxkIGl0IGJlIHJlYXNvbmFi bGUgZm9yIHRoZSBhdXRob3JzIHRvIHN1Ym1pdCBhIG5ldyAoLTE0KSB2ZXJzaW9uLCBzbyB3ZSBj YW4gc2VlIHdoYXQgdGhlIHJlc3VsdHMgbG9vayBsaWtlIGF0IHRoaXMgcG9pbnQ/DQoNClRoYW5r cywNCi0tRGF2aWQNCg0KRnJvbTogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSBbbWFpbHRv OnRpcmVkZHlAY2lzY28uY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDAxLCAyMDE1IDExOjE0IFBN DQpUbzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsOyBCbGFjaywgRGF2aWQNCkNjOiBDaHJpc3Rl ciBIb2xtYmVyZzsgVGVkIEhhcmRpZTsgam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYub3JnOyBy dGN3ZWJAaWV0Zi5vcmc7IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNl bnQtZnJlc2huZXNzLTEzDQoNCkZyb206IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCBbbWFpbHRv Om11dGh1LmFydWxAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBKdW5lIDAxLCAyMDE1IDY6NDEg UE0NClRvOiBCbGFjaywgRGF2aWQNCkNjOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBD aHJpc3RlciBIb2xtYmVyZzsgVGVkIEhhcmRpZTsgam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYu b3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+OyBydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpydGN3ZWIt Y2hhaXJzQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTMNCg0KSSB0 aGluayBSRkM1MjQ1IGRvZXMgbm90IHJ1bGUgb3V0IHNvbWVvbmUgdXNpbmcgU1RVTiBiaW5kaW5n IHJlcXVlc3RzIGZvciBrZWVwYWxpdmU6DQoNCjxzbmlwPg0KICAgVGhvdWdoIEJpbmRpbmcgSW5k aWNhdGlvbnMgYXJlIHVzZWQgZm9yIGtlZXBhbGl2ZXMsDQogICBhbiBhZ2VudCBNVVNUIGJlIHBy ZXBhcmVkIHRvIHJlY2VpdmUgYSBjb25uZWN0aXZpdHkgY2hlY2sgYXMgd2VsbC4NCiAgIElmIGEg Y29ubmVjdGl2aXR5IGNoZWNrIGlzIHJlY2VpdmVkLCBhIHJlc3BvbnNlIGlzIGdlbmVyYXRlZCBh cw0KICAgZGlzY3Vzc2VkIGluIFtSRkM1Mzg5XSwgYnV0IHRoZXJlIGlzIG5vIGltcGFjdCBvbiBJ Q0UgcHJvY2Vzc2luZw0KICAgb3RoZXJ3aXNlLg0KPC9zbmlwPg0KDQpPTEQ6DQogICAgSWYgY29u c2VudCBpcyBwZXJmb3JtZWQgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZl IG1lc3NhZ2VzLg0KDQpTdWdnZXN0ZWQgTkVXOg0KICAgSWYgY29uc2VudCBpcyBwZXJmb3JtZWQg dGhlbiB0aGUgU1RVTiBiaW5kaW5nIHJlcXVlc3RzIHNlbnQgZm9yIGNvbnNlbnQNCiAgIGZyZXNo bmVzcyBhbHNvIHNlcnZlIHRoZSBrZWVwYWxpdmUgcHVycG9zZS4NCg0KVXBkYXRlZCBpbiBteSBs b2NhbCBjb3B5Lg0KDQotVGlydQ0KDQpUaGF0IGlzIGVmZmVjdGl2ZWx5IHdoYXQgUkZDNTI0NSBz YXlzIGZvciBrZWVwYWxpdmUuLg0KDQpNdXRodQ0KDQpPbiBGcmksIE1heSAyOSwgMjAxNSBhdCAx MTo0MSBQTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5i bGFja0BlbWMuY29tPj4gd3JvdGU6DQpUaGF0IGFsc28gd29ya3MgZm9yIG1lLCBhbmQgbmVhdGx5 IHNpZGVzdGVwcyB0aGUgY29uY2VybiBhYm91dA0Kd2hldGhlciBSRkMgNTI0NSBpcyBiZWluZyB1 cGRhdGVkLg0KDQpUaGFua3MsDQotLURhdmlkDQoNCkZyb206IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkgW21haWx0bzp0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5j b20+XQ0KU2VudDogVGh1cnNkYXksIE1heSAyOCwgMjAxNSAxMToyMCBQTQ0KVG86IENocmlzdGVy IEhvbG1iZXJnOyBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQNCg0KQ2M6IGpvZWwgamFlZ2dsaTsg b3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRpckBpZXRmLm9yZz47IHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzxt YWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbcnRjd2Vi XSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2hu ZXNzLTEzDQoNCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tXQ0KU2VudDogRnJpZGF5LCBNYXkgMjksIDIwMTUgNzozNyBBTQ0KVG86 IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFRlZCBIYXJkaWU7IEJsYWNrLCBEYXZpZA0K Q2M6IGpvZWwgamFlZ2dsaTsgb3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRpckBpZXRmLm9y Zz47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPjsgcnRjd2ViLWNoYWly c0B0b29scy5pZXRmLm9yZzxtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1 YmplY3Q6IFJFOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1z dHVuLWNvbnNlbnQtZnJlc2huZXNzLTEzDQoNCkhpLA0KDQo+R29vZCBwb2ludC4gV2UgZGlzY3Vz cyB0aGUgZm9sbG93aW5nIHBvaW50IGluIHNlY3Rpb24gNC4xIG9mIHRoZSBkcmFmdCBhYm91dCBr ZWVwYWxpdmVzOg0KPg0KPiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFw cGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bw0KPiAgIG1haW50YWluIGNvbnNlbnQuICBI b3dldmVyLCBub3Qgc2VuZGluZyBhbnkgdHJhZmZpYyBjb3VsZCBjYXVzZSBOQVQNCj4gICBvciBm aXJld2FsbCBtYXBwaW5ncyB0byBleHBpcmUuICBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVy IHVuYWJsZQ0KPiAgIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBB YnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uDQo+ICAgYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVu ZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsDQo+ICAgbWFwcGluZ3Mg ZG8gbm90IGV4cGlyZSwgaXQgY2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9yIG90aGVyDQo+ ICAgdGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdPGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi0xMD4gYW5kIHNlZSBbUkZDNjI2MzxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjYzPl0pLg0KPg0KPiBTbyB0aGVyZSBpcyBubyBuZWVk IHRvIHNlbmQga2VlcGFsaXZlcyBiZWNhdXNlIG9mIHRoZSBtZWRpYSB0cmFmZmljIGFzIGl0IGlz IHBvaW50ZWQgb3V0IGluIFNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1MjQ1DQo+IGlycmVzcGVjdGl2 ZSBvZiB3aGV0aGVyIGNvbnNlbnQgaXMgdXNlZCBvciBub3QuIEkgdGhpbmsgd2UgY2FuIHJlbW92 ZSB0aGUgZm9sbG93aW5nIGxpbmUgaW4g4oCcSWYgY29uc2VudCBpcyBwZXJmb3JtZWQgdGhlbg0K PiB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLiIgYW5kIGF2b2lk IHRoZSBjb25mdXNpb24gb2YgdXBkYXRpbmcgUkZDIDUyNDUuDQoNCkkgYWdyZWUgdGhhdCB0aGUg Y3VycmVudCB0ZXh0IGNhbiBjb25mdXNlIHBlb3BsZSwgYnV0IEkgc3RpbGwgdGhpbmsgaXQgd291 bGQgYmUgZ29vZCB0byBoYXZlIGV4cGxpY2l0IHRleHQgc2F5aW5nIHRoYXQga2VlcGFsaXZlcyBh cmUgbm90IHNlbnQuIFBlcmhhcHMgc29tZXRoaW5nIGxpa2U6DQoNCuKAnEZyb20gYSBrZWVwYWxp dmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEgdHJh ZmZpYy4gQmVjYXVzZSBvZiB0aGF0LCBkZWRpY2F0ZWQga2VlcGFsaXZlcyAoZS5nLiBTVFVOIGJp bmRpbmcgcmVxdWVzdHMpIGFyZSBub3Qgc2VudCBvbiBjYW5kaWRhdGUgcGFpcnMgd2hlcmUgY29u c2VudCByZXF1ZXN0cyBhcmUgc2VudCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gMjAuMi4z IG9mIFtSRkM1MjQ1XS7igJ0NCg0KV29ya3MgZm9yIG1lIChSZXBsYWNlZCBTVFVOIGJpbmRpbmcg cmVxdWVzdHMgd2l0aCBTVFVOIEJpbmRpbmcgSW5kaWNhdGlvbnMgaW4gdGhlIGFib3ZlIGxpbmUp Lg0KDQpDaGVlcnMsDQotVGlydQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0 Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0 ZXIgSG9sbWJlcmcNClNlbnQ6IEZyaWRheSwgTWF5IDI5LCAyMDE1IDY6NTQgQU0NClRvOiBUZWQg SGFyZGllOyBCbGFjaywgRGF2aWQNCkNjOiBqb2VsIGphZWdnbGk7IG9wcy1kaXJAaWV0Zi5vcmc8 bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz47IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYi1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMw0KDQoNCkhpLA0K DQpTZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NSBzYXlzOg0KDQrigJxTVFVOIGtlZXBhbGl2ZXMg KGluIHRoZSBmb3JtIG9mIFNUVU4gQmluZGluZyBJbmRpY2F0aW9ucykgYXJlIHNlbnQgaW4NCiAg ICAgICAgICAgICAgdGhlIG1pZGRsZSBvZiBhIG1lZGlhIHNlc3Npb24uICBIb3dldmVyLCB0aGV5 IGFyZSBzZW50IG9ubHkgaW4gdGhlDQogICAgICAgICAgICAgIGFic2VuY2Ugb2YgYWN0dWFsIG1l ZGlhIHRyYWZmaWMu4oCdDQoNClNvLCBpbiB0aGUgY29uc2VudCBkcmFmdCB3ZSBjb3VsZCBzYXkg dGhhdCwgZnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVjdGl2ZSwgY29uc2VudCByZXF1ZXN0cyBhcmUg Y29uc2lkZXJlZCBtZWRpYSB0cmFmZmljLiBUaGF0IHdvdWxkIHRoZW4gaW1wbGljaXRseSBtZWFu IHRoYXQgYWN0dWFsIGtlZXBhbGl2ZXMgYXJlbuKAmXQgc2VudCB3aGVuIGNvbnNlbnQgaXMgdXNl ZC4gVGhhdCB3YXksIHRoZSBjb25zZW50IHNwZWMgd291bGQgYmUgY29tcGxpYW50IHRvIDUyNDUs IGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciBhbnkgdXBkYXRlIGV0Y+KApg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2VudDogMjggTWF5IDIwMTUgMjM6 MjYNClRvOiBCbGFjaywgRGF2aWQNCkNjOiBydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPG1h aWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgam9lbCBqYWVnZ2xpOyBvcHMtZGly QGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPjsgcnRjd2ViQGlldGYub3JnPG1haWx0 bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcg b2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMw0KDQpIaSBEYXZp ZCwNCg0KT24gVGh1LCBNYXkgMjgsIDIwMTUgYXQgMTI6MzYgUE0sIEJsYWNrLCBEYXZpZCA8ZGF2 aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbT4+DQoNCkknZCBleHBl Y3QgdGhhdCBldmVuIG92ZXJyaWRpbmcgUkZDIDUyNDUgY291bnRzIGFzIGFuIFVwZGF0ZSwNCmJl Y2F1c2UgdGhlIHJlc3VsdCB3b3VsZCBiZSB0aGF0IHRoZSBvcmlnaW5hbCBSRkMgNTI0NSAiTVVT VCIgcmVxdWlyZW1lbnQNCmlzIG5vIGxvbmdlciBnbG9iYWxseSBhcHBsaWNhYmxlIHRvIGFsbCB1 c2VzIG9mIFJGQyA1MjQ1LiAgSW4gb3RoZXIgd29yZHMsDQpvdmVycmlkaW5nIFJGQyA1MjQ1IGVm ZmVjdGl2ZWx5IHJld3JpdGVzIHRoZSAiTVVTVCIgdG8gYmVjb21lICJNVVNULCBleGNlcHQNCmFz IGZ1cnRoZXIgc3BlY2lmaWVkIGJ5IHRoZSBjb25zZW50IFJGQy4iDQoNCuKAi1NvIEkgYWdyZWUg d2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2FsbGVkIG91dCwgYnV0IEkgdGhpbmsgIlVwZGF0 ZXMiIGlzIHdyb25nIGZvciB0aGUgZHJhZnQncyBjdXJyZW50IGludGVudC4gIEkgdGhpbmsgd2hh dCBNYXJ0aW4gaGFzIHNhaWQgYW1vdW50cyB0byAiV2UgaGF2ZSBjaG9zZW4gdG8gZm9sbG93IFJG QyA1MjQ1IGV4Y2VwdCBhcyBkZXRhaWxlZCBpbiBzZWN0aW9ucyBYIGFuZCBZLCB3aGVyZSB3ZSB1 c2UgYSBkaWZmZXJlbnQgc2V0IG9mIG1lc3NhZ2VzIHRvIG9wdGltaXplIHRoZSBjb21iaW5hdGlv biBvZiBoZWFydGJlYXQgYW5kIGNvbnNlbnQuIiAgV2UgYXJlIG5vdCB1cGRhdGluZyBSRkMgNTI0 NSB0aGVyZWJ5LCBiZWNhdXNlIHdlIGFyZSBuZWl0aGVyIGNoYW5naW5nIGl0cyBjb3JlIHNlbWFu dGljcyBub3Igb2ZmZXJpbmcgdG8gYWRkIGEgbmV3LCBnZW5lcmFsIHNlbWFudGljIHRvIFJGQyA1 MjQ1ICh3ZSBjb3VsZCBoYXZlIG1hZGUgdGhhdCBjaG9pY2UsIGJ1dCBhcmUgbm90IGRvaW5nIHNv IG5vdykuICBJbnN0ZWFkIG9mIHVwZGF0aW5nIFJGQyA1MjQ1LCBpbiBvdGhlciB3b3Jkcywgd2Ug YXJlIGxpbWl0aW5nIG91ciByZWZlcmVuY2UgdG8gaXQuDQpUaGF0IHNob3VsZCBiZSBkb25lIGV4 cGxpY2l0bHksIGFuZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBjYWxsZWQgaXQgc3VmZmlpY2llbnRs eSB0aGF0IGEgbmV3IHNwaW4gb2YgdGhlIGRyYWZ0IGxpa2VseSBuZWVkcyBhIG5ldyByb3VuZCBv ZiByZXZpZXcuICBCdXQgSSBkb24ndCB0aGluayB3ZSBhcmUgcmVxdWlyZWQgdG8gdXBkYXRlIFJG QyA1MjQ1IHRvIGdldCB0aGF0IGRvbmUuDQpJJ3ZlIHJlZmVycmVkIHRoZSBtYXR0ZXIgdG8gb3Vy IGZyaWVuZGx5IEFELCBhbmQgd2UgYXdhaXQgaGVyIHJlYWRpbmcgb24gbmV4dCBzdGVwcyBvbiB0 aGlzLiAgSW4gZWl0aGVyIGFwcHJvYWNoLCBob3dldmVyLCB0aGlzIHdpbGwgZ2V0IGNhbGxlZCBv dXQuDQpyZWdhcmRzLA0KVGVkIEhBcmRpZeKAiw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_CE03DB3D7B45C245BCA0D243277949360B33A751MX104CL02corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGVyZeKAmXMgYmVlbiBhIGxvdCBvZiBk aXNjdXNzaW9uIC0gd291bGQgaXQgYmUgcmVhc29uYWJsZSBmb3IgdGhlIGF1dGhvcnMgdG8gc3Vi bWl0IGEgbmV3ICgtMTQpIHZlcnNpb24sIHNvIHdlIGNhbiBzZWUgd2hhdCB0aGUgcmVzdWx0cyBs b29rIGxpa2UgYXQgdGhpcyBwb2ludD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+VGhhbmtzLDxicj4NCi0tRGF2aWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KSBbbWFpbHRvOnRpcmVkZHlAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgSnVuZSAwMSwgMjAxNSAxMToxNCBQTTxicj4NCjxiPlRvOjwvYj4gTXV0aHUgQXJ1 bCBNb3poaSBQZXJ1bWFsOyBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhv bG1iZXJnOyBUZWQgSGFyZGllOyBqb2VsIGphZWdnbGk7IG9wcy1kaXJAaWV0Zi5vcmc7IHJ0Y3dl YkBpZXRmLm9yZzsgcnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1 bi1jb25zZW50LWZyZXNobmVzcy0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE11dGh1IEFydWwgTW96aGkgUGVydW1h bCBbPGEgaHJlZj0ibWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tIj5tYWlsdG86bXV0aHUuYXJ1 bEBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVuZSAwMSwgMjAx NSA2OjQxIFBNPGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+IFRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IENocmlzdGVyIEhvbG1iZXJnOyBUZWQgSGFyZGll OyBqb2VsIGphZWdnbGk7DQo8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyI+b3BzLWRp ckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPg0KcnRjd2Vi QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5v cmciPnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNv bnNlbnQtZnJlc2huZXNzLTEzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSB0aGluayBSRkM1MjQ1IGRvZXMgbm90 IHJ1bGUgb3V0IHNvbWVvbmUgdXNpbmcgU1RVTiBiaW5kaW5nIHJlcXVlc3RzIGZvciBrZWVwYWxp dmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbHQ7c25pcCZndDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtUaG91Z2ggQmluZGluZyBJbmRpY2F0aW9ucyBhcmUgdXNl ZCBmb3Iga2VlcGFsaXZlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICZuYnNwO2FuIGFnZW50IE1VU1Qg YmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBhIGNvbm5lY3Rpdml0eSBjaGVjayBhcyB3ZWxsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7SWYgYSBjb25uZWN0aXZpdHkgY2hlY2sgaXMgcmVjZWl2ZWQs IGEgcmVzcG9uc2UgaXMgZ2VuZXJhdGVkIGFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtkaXNj dXNzZWQgaW4gW1JGQzUzODldLCBidXQgdGhlcmUgaXMgbm8gaW1wYWN0IG9uIElDRSBwcm9jZXNz aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtvdGhlcndpc2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZsdDsv c25pcCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PTEQ6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOyAmbmJzcDsgSWYgY29uc2VudCBpcyBwZXJmb3JtZWQgdGhlbiB0aGVyZSBp cyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1Z2dl c3RlZCBORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtJZiBjb25zZW50IGlzIHBlcmZvcm1l ZCB0aGVuIHRoZSBTVFVOIGJpbmRpbmcgcmVxdWVzdHMgc2VudCBmb3IgY29uc2VudDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsgJm5ic3A7ZnJlc2huZXNzIGFsc28gc2VydmUgdGhlIGtlZXBhbGl2ZSBwdXJw b3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VXBkYXRlZCBpbiBteSBsb2NhbCBjb3B5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5UaGF0IGlzIGVmZmVjdGl2ZWx5IHdoYXQgUkZDNTI0NSBzYXlzIGZvciBr ZWVwYWxpdmUuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk11dGh1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIEZyaSwgTWF5IDI5LCAyMDE1IGF0IDExOjQxIFBNLCBCbGFjaywgRGF2aWQgJmx0OzxhIGhy ZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxh Y2tAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGF0IGFsc28gd29y a3MgZm9yIG1lLCBhbmQgbmVhdGx5IHNpZGVzdGVwcyB0aGUgY29uY2VybiBhYm91dDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPndoZXRoZXIgUkZDIDUyNDUgaXMgYmVpbmcgdXBkYXRlZC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8YnI+DQotLURhdmlkPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KQ0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBNYXkgMjgsIDIwMTUgMTE6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1i ZXJnOyBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPkNjOjwvYj4gam9lbCBqYWVn Z2xpOyA8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9w cy1kaXJAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWIt Y2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGN3ZWItY2hhaXJzQHRv b2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dlYl0gT1BTLURp ciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBDaHJpc3RlciBIb2xtYmVyZyBbPGEg aHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgTWF5IDI5LCAyMDE1IDc6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IFRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFRlZCBIYXJkaWU7IEJsYWNrLCBEYXZpZDxicj4N CjxiPkNjOjwvYj4gam9lbCBqYWVnZ2xpOyA8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm9wcy1kaXJAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+DQpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1j b25zZW50LWZyZXNobmVzcy0xMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGks PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+R29vZCBwb2ludC4gV2UgZGlzY3VzcyB0aGUgZm9sbG93aW5nIHBvaW50IGluIHNl Y3Rpb24gNC4xIG9mIHRoZSBkcmFmdCBhYm91dCBrZWVwYWxpdmVzOjwvc3Bhbj48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jmd0OzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0 OyZuYnNwOyZuYnNwOyBBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNh dGlvbiBkYXRhIGRvZXMgbm90IG5lZWQgdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IG1haW50YWluIGNvbnNl bnQuJm5ic3A7IEhvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5B VDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZndDsmbmJzcDsmbmJzcDsgb3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiZuYnNwOyBG dXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgdG8gc2Vu ZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy4mbmJzcDsgQWJzZW50IGJldHRlciBp bmZvcm1hdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBv aW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyBt YXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Ig b3RoZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IHRlY2huaXF1ZXMgKHNlZQ0KPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTEwIiB0YXJnZXQ9Il9ibGFuayI+U2Vj dGlvbiZuYnNwOzEwIG9mIFtSRkM1MjQ1XTwvYT4gYW5kIHNlZSBbPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNjI2MyIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSImcXVvdDtB cHBsaWNhdGlvbiBNZWNoYW5pc20gZm9yIEtlZXBpbmcgQWxpdmUgdGhlIE5BVCBNYXBwaW5ncyBB c3NvY2lhdGVkIHdpdGggUlRQIC8gUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIEZsb3dzJnF1 b3Q7Ij5SRkM2MjYzPC9hPl0pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBrZWVwYWxp dmVzIGJlY2F1c2Ugb2YgdGhlIG1lZGlhIHRyYWZmaWMgYXMgaXQgaXMgcG9pbnRlZCBvdXQgaW4N Cjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5TZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NQ0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+aXJyZXNw ZWN0aXZlIG9mIHdoZXRoZXIgY29uc2VudCBpcyB1c2VkIG9yIG5vdDwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi4gSSB0aGluayB3ZSBjYW4g cmVtb3ZlIHRoZSBmb2xsb3dpbmcgbGluZSBpbiDigJxJZiBjb25zZW50IGlzIHBlcmZvcm1lZCB0 aGVuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PnRoZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBrZWVwYWxpdmUgbWVzc2FnZXMuJnF1b3Q7IGFuZCBh dm9pZCB0aGUgY29uZnVzaW9uIG9mIHVwZGF0aW5nIFJGQyA1MjQ1Ljwvc3Bhbj48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgYWdyZWUgdGhhdCB0aGUgY3VycmVu dCB0ZXh0IGNhbiBjb25mdXNlIHBlb3BsZSwgYnV0IEkgc3RpbGwgdGhpbmsgaXQgd291bGQgYmUg Z29vZCB0byBoYXZlIGV4cGxpY2l0IHRleHQgc2F5aW5nDQogdGhhdCBrZWVwYWxpdmVzIGFyZSBu b3Qgc2VudC4gUGVyaGFwcyBzb21ldGhpbmcgbGlrZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPuKAnEZyb20gYSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNl bnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEgdHJhZmZpYy4gQmVjYXVzZSBvZiB0aGF0 LCBkZWRpY2F0ZWQga2VlcGFsaXZlcw0KIChlLmcuIFNUVU4gYmluZGluZyByZXF1ZXN0cykgYXJl IG5vdCBzZW50IG9uIGNhbmRpZGF0ZSBwYWlycyB3aGVyZSBjb25zZW50IHJlcXVlc3RzIGFyZSBz ZW50LCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiAyMC4yLjMgb2YgW1JGQzUyNDVdLuKAnTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldvcmtzIGZvciBtZSAoUmVwbGFjZWQNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlNUVU4gYmluZGluZyByZXF1ZXN0cyB3aXRoIFNUVU4gQmluZGluZyBJ bmRpY2F0aW9ucyBpbiB0aGUgYWJvdmUgbGluZSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi1UaXJ1PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVm PSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3Rl ciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE1heSAyOSwgMjAxNSA2OjU0IEFN PGJyPg0KPGI+VG86PC9iPiBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+ IGpvZWwgamFlZ2dsaTsgPGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5vcHMtZGlyQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWls dG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRjd2Vi LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3 ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVz aG5lc3MtMTM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGks PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDIwLjIuMyBv ZiBSRkMgNTI0NSBzYXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1pbmRlbnQ6LjVpbiI+DQo8c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnFNUVU4ga2VlcGFsaXZlcyAoaW4gdGhlIGZvcm0gb2YgU1RV TiBCaW5kaW5nIEluZGljYXRpb25zKSBhcmUgc2VudCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBtaWRkbGUgb2YgYSBt ZWRpYSBzZXNzaW9uLiZuYnNwOyBIb3dldmVyLA0KPGI+dGhleSBhcmUgc2VudCBvbmx5IGluIHRo ZTwvYj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBhYnNlbmNlIG9mIGFjdHVhbCBtZWRpYSB0cmFmZmljPC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi7i gJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCBpbiB0aGUgY29u c2VudCBkcmFmdCB3ZSBjb3VsZCBzYXkgdGhhdCwgZnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVjdGl2 ZSwgY29uc2VudCByZXF1ZXN0cw0KIGFyZSBjb25zaWRlcmVkIG1lZGlhIHRyYWZmaWMuIFRoYXQg d291bGQgdGhlbiBpbXBsaWNpdGx5IG1lYW4gdGhhdCBhY3R1YWwga2VlcGFsaXZlcyBhcmVu4oCZ dCBzZW50IHdoZW4gY29uc2VudCBpcyB1c2VkLiBUaGF0IHdheSwgdGhlIGNvbnNlbnQgc3BlYyB3 b3VsZCBiZSBjb21wbGlhbnQgdG8gNTI0NSwgYW5kIHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgZm9y IGFueSB1cGRhdGUgZXRj4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0 ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+IDI4IE1heSAyMDE1IDIzOjI2 PGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2Vi LWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47IGpvZWwgamFlZ2dsaTsNCjxhIGhyZWY9Im1haWx0 bzpvcHMtZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3BzLWRpckBpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dl YkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIE9QUy1EaXIg cmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTM8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgRGF2aWQsDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gVGh1LCBNYXkgMjgsIDIw MTUgYXQgMTI6MzYgUE0sIEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJs YWNrQGVtYy5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZpZC5ibGFja0BlbWMuY29tPC9hPiZndDsN Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiI+PGJyPg0KSSdkIGV4cGVjdCB0aGF0IGV2ZW4gb3ZlcnJpZGluZyBSRkMgNTI0NSBjb3VudHMg YXMgYW4gVXBkYXRlLDxicj4NCmJlY2F1c2UgdGhlIHJlc3VsdCB3b3VsZCBiZSB0aGF0IHRoZSBv cmlnaW5hbCBSRkMgNTI0NSAmcXVvdDtNVVNUJnF1b3Q7IHJlcXVpcmVtZW50PGJyPg0KaXMgbm8g bG9uZ2VyIGdsb2JhbGx5IGFwcGxpY2FibGUgdG8gYWxsIHVzZXMgb2YgUkZDIDUyNDUuJm5ic3A7 IEluIG90aGVyIHdvcmRzLDxicj4NCm92ZXJyaWRpbmcgUkZDIDUyNDUgZWZmZWN0aXZlbHkgcmV3 cml0ZXMgdGhlICZxdW90O01VU1QmcXVvdDsgdG8gYmVjb21lICZxdW90O01VU1QsIGV4Y2VwdDxi cj4NCmFzIGZ1cnRoZXIgc3BlY2lmaWVkIGJ5IHRoZSBjb25zZW50IFJGQy4mcXVvdDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi1NvIEkgYWdy ZWUgd2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2FsbGVkIG91dCwgYnV0IEkgdGhpbmsgJnF1 b3Q7VXBkYXRlcyZxdW90OyBpcyB3cm9uZyBmb3IgdGhlIGRyYWZ0J3MgY3VycmVudCBpbnRlbnQu Jm5ic3A7IEkgdGhpbmsNCiB3aGF0IE1hcnRpbiBoYXMgc2FpZCBhbW91bnRzIHRvICZxdW90O1dl IGhhdmUgY2hvc2VuIHRvIGZvbGxvdyBSRkMgNTI0NSBleGNlcHQgYXMgZGV0YWlsZWQgaW4gc2Vj dGlvbnMgWCBhbmQgWSwgd2hlcmUgd2UgdXNlIGEgZGlmZmVyZW50IHNldCBvZiBtZXNzYWdlcyB0 byBvcHRpbWl6ZSB0aGUgY29tYmluYXRpb24gb2YgaGVhcnRiZWF0IGFuZCBjb25zZW50LiZxdW90 OyZuYnNwOyBXZSBhcmUgbm90IHVwZGF0aW5nIFJGQyA1MjQ1IHRoZXJlYnksIGJlY2F1c2Ugd2Ug YXJlDQogbmVpdGhlciBjaGFuZ2luZyBpdHMgY29yZSBzZW1hbnRpY3Mgbm9yIG9mZmVyaW5nIHRv IGFkZCBhIG5ldywgZ2VuZXJhbCBzZW1hbnRpYyB0byBSRkMgNTI0NSAod2UgY291bGQgaGF2ZSBt YWRlIHRoYXQgY2hvaWNlLCBidXQgYXJlIG5vdCBkb2luZyBzbyBub3cpLiZuYnNwOyBJbnN0ZWFk IG9mIHVwZGF0aW5nIFJGQyA1MjQ1LCBpbiBvdGhlciB3b3Jkcywgd2UgYXJlIGxpbWl0aW5nIG91 ciByZWZlcmVuY2UgdG8gaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGF0IHNob3VsZCBiZSBk b25lIGV4cGxpY2l0bHksIGFuZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBjYWxsZWQgaXQgc3VmZmlp Y2llbnRseSB0aGF0IGEgbmV3IHNwaW4gb2YgdGhlIGRyYWZ0IGxpa2VseSBuZWVkcw0KIGEgbmV3 IHJvdW5kIG9mIHJldmlldy4mbmJzcDsgQnV0IEkgZG9uJ3QgdGhpbmsgd2UgYXJlIHJlcXVpcmVk IHRvIHVwZGF0ZSBSRkMgNTI0NSB0byBnZXQgdGhhdCBkb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SSd2ZSByZWZlcnJlZCB0aGUgbWF0dGVyIHRvIG91ciBmcmllbmRseSBBRCwgYW5kIHdlIGF3 YWl0IGhlciByZWFkaW5nIG9uIG5leHQgc3RlcHMgb24gdGhpcy4mbmJzcDsgSW4gZWl0aGVyIGFw cHJvYWNoLCBob3dldmVyLA0KIHRoaXMgd2lsbCBnZXQgY2FsbGVkIG91dC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPnJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UZWQgSEFyZGll 4oCLPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dl YiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3 ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949360B33A751MX104CL02corpem_-- From nobody Wed Jun 3 02:38:18 2015 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 8598E1A0024 for ; Wed, 3 Jun 2015 02:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.013 X-Spam-Level: ** X-Spam-Status: No, score=2.013 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 W48IP11GyURM for ; Wed, 3 Jun 2015 02:38:15 -0700 (PDT) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 031941A0022 for ; Wed, 3 Jun 2015 02:38:14 -0700 (PDT) Received: (qmail 30613 invoked by uid 0); 3 Jun 2015 09:38:07 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by qproxy2.mail.unifiedlayer.com with SMTP; 3 Jun 2015 09:38:07 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw2 with id blAS1q00y2Yhrsa01lAV7L; Wed, 03 Jun 2015 03:10:32 -0600 X-Authority-Analysis: v=2.1 cv=efyuId0H c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=x9HPBuXWPrAA:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10 a=KWLd9SN1AAAA:8 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=XAFQembCKUMA:10 a=N1z6yVdWAAAA:8 a=Wrg9GR17TvHSOMpSY40A:9 a=CjuIK1q_8ugA:10 a=OP3iMzCqpaEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=v2mfdq2tnFTG8oA4kZUhkVS1Ihjci0oRaalXHtCPFYI=; b=ZGOBBv8uBfUZiCuwft4Qa6fLapyn7G9CxctpI94pLHLwoZRwfrec2vyx7G6sbnhI3lW87qvQvRTNosLEAE1lk1DAiB9MmUZp+GtHYPdfqAmMF+T9lYijtg7uEQ0Gdcla; Received: from localhost ([127.0.0.1]:42902 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1Z04oE-0007NN-Et for rtcweb@ietf.org; Wed, 03 Jun 2015 03:18:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 03 Jun 2015 03:18:00 -0600 From: Malaysia Conference Update To: rtcweb@ietf.org Message-ID: <770ea958c50ae1fa10461978541264ad@sdiwc.info> X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.1 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} Archived-At: Subject: [rtcweb] CFP: Fourth World Congress - SEMCMI2015 - Malaysia 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, 03 Jun 2015 09:38:16 -0000 The International Conference on Software Engineering, Mobile Computing and Media Informatics (SEMCMI2015) - Part of The Fourth World Congress on Computing, Engineering and Technology (WCET) - Asia Pacific University of Technology and Innovation (APU) Kuala Lumpur, Malaysia September 8-10, 2015 http://sdiwc.net/conferences/semcmi2015/ All registered papers will be included in SDIWC Digital Library ================================================================ The proposed conference on the above theme will be held at Asia Pacific University of Technology and Innovation (APU) on September 8-10, 2015 which aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: *Software Engineering Advanced Database Systems Advanced Human-Computer Interaction Artificial Intelligence Data Mining Economics of Innovation & Entrepreneurship Electronic Circuits Embedded Systems Design & Interfacing Globalisation & the World Economy Managing the International Enterprise Service-Oriented Architectures Spatial and Multimedia Databases Systems Safety Engineering Virtual Organisation Management Advanced Embedded Systems Algorithms & Data Structures Carbon & Energy Management Distributed Computing Electrical Energy Conversion & Utilisation Embedded Systems Design & Interfacing Engineering Project Management Information Security Operating Systems Architecture Signals, Systems & Control Systems Engineering Systems Thinking for Sustainability Web Information Systems *Mobile Computing Access Control Application Service Providers Bluetooth Broadband Wireless Networks Enterprise Asset Management Software Fixed Wireless Networks Converged Networks Data Security PDA Operating Systems Satellite Communications Systems Wireless Application Development Wireless Applications Software Wireless Development Tools Wireless Home Networks Application Performance Management Base Stations Broadband Satellite Systems Enhanced Messaging Service Ethernet Cable Fixed-mobile Convergence Data Migration Document Management Voice Communications Software Security Managers Wireless Application Services Providers Wireless Computing Wireless Hardware Wireless Infrared Communications *Media Informatics Computer Graphics/Animation/Visualisation Data Communication Digital Interactive Media Game Design Knowledge Management Multimedia Technology Speech/Image/Video Processing and Technology Cooperative Work Environments Designing Interactive Systems E-Business Internet Infrastructures Management of Information Security and Cryptography Virtual and Augmented Reality Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Dates : The submission is open from now until August 08, 2015 Notification of Acceptance : August 18, 2015 or 4 weeks from the submission date Camera Ready Submission : Open from now until August 29, 2015 Registration : Open from now until August 29, 2015 Conference Dates : September 8-10, 2015 From nobody Wed Jun 3 05:37:32 2015 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 960E91A8777 for ; Wed, 3 Jun 2015 05:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 pZ3XHzuhpSDV for ; Wed, 3 Jun 2015 05:37: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 B35041A8775 for ; Wed, 3 Jun 2015 05:37:29 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-9c-556ef5079b22 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 44.3E.28096.705FE655; Wed, 3 Jun 2015 14:37:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.210.2; Wed, 3 Jun 2015 14:37:13 +0200 Message-ID: <556EF4F9.1060700@ericsson.com> Date: Wed, 3 Jun 2015 14:37:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJMWRmVeSWpSXmKPExsUyM+JvrS7717xQg4/3ZSzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqnOi6wFeyUqpu69wtjAuFi4i5GTQ0LARGLN5LksELaYxIV7 69m6GLk4hASOMkr039zNBJIQEljGKPHssyGIzSugLXH5xgH2LkYODhYBFYnp/RkgYTYBC4mb PxrZQGxRgSiJqY/XsUCUC0qcnPkEzBYRUJe4/PACO4gtLOAgMWv9BhaQMcwC9hIPtpaBhJkF 5CWat85mhtiqLdHQ1ME6gZFvFpJJsxA6ZiHpWMDIvIpRtDi1uDg33chIL7UoM7m4OD9PLy+1 ZBMjMJgObvlttYPx4HPHQ4wCHIxKPLwL4/NChVgTy4orcw8xSnOwKInzztgMFBJITyxJzU5N LUgtii8qzUktPsTIxMEp1cDI1PprRsiqe0capr96sr976YcP+ju/pTxnM7QISK2Yxu1056QB w7To94u2HdxxX/xXJ5ecPufr3JdCxbsj3zDf03yfHe3KPyEiaL2KIOOjSSe0pBNW6Tx0rmTR sS5v/yj1qD7GJjtHzZjBNepUSEVR1Ksj3x7NCXA4/uVPrTT/0fN+XdPCutKUWIozEg21mIuK EwGhnUmYBwIAAA== Archived-At: Subject: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 03 Jun 2015 12:37:31 -0000 Hi, I want raise for discussion the fact that I think JSEP does not handle RTP payload type switching as currently specified. So lets walk through a case of RTP payload type switching and what it means according to the specifications we do have. So we have an established PeerConnection with one audio track for which we have negotiated the possibility to send both PCM and OPUS. If the sender decides to switch RTP payload type, lets say from OPUS to PCM. The reason is actually not important, but lets say due to a "replace track" API call as currently being discussed on W3C WebRTC group. When that RTP payload type switch from OPUS to PCM we also have an RTP timestamp rate change, from 48 kHz to 8 kHz. As specified in RTP usage (Section 4.3): If performing changes between two RTP payload types that use different RTP clock rates, an RTP sender MUST follow the recommendations in Section 4.1 of [RFC7160]. So lets look at what RFC 7160 says: 4.1. RTP Sender (with RTCP) An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST be used if the clock rate switches back to a value already seen in the RTP stream. Thus, this Payload type change forces the use of a new SSRC. This in itself should not be a significant issue. The binding to the right media block in the SDP is done using MID. Which, will be sent in an RTP header extension to ensure that stream upon reception is correctly associated. The RTP synchronization information will arrive in RTCP or even in the RTP header extension if the peers both supports RFC 6051. Thus minimal media impacts is to be expected. But, discussing what happens in this case with Stefan Håkansson we did look into JSEP. And here we clearly have some short commings in the specification. A. First of all there is an assumption that the value of a=ssrc will not change. For example Section 5.2.2 (Subsequent Offers): o For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same. If an RTP payload type switching has occured that forces a SSRC change then I expect that the actually used SSRCs are included in the offer. Thus, both a=ssrc and a=ssrc-group can change in subsequent offers. B. The next question is if a RTP payload type change actually requires the node that performs the change to actually initiate an Offer/answer exchange to update their a=ssrc values? Clearly JSEP needs to be updated to address these issues. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jun 3 11:17:52 2015 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 3BAA51AD068 for ; Wed, 3 Jun 2015 11:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_14=0.6, 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 tBqLAZ_5mehu for ; Wed, 3 Jun 2015 11:17:41 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABC71AD06B for ; Wed, 3 Jun 2015 11:17:40 -0700 (PDT) Received: by wibut5 with SMTP id ut5so111766560wib.1 for ; Wed, 03 Jun 2015 11:17:39 -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=+kZkEpj8KuyiEvtZQJgOtfH8qymGT7gTb92yhO0jRBo=; b=U2iG6OwU6kPpG0GjbJjAQG9nwqy+BlTFdtPT7Bg3MOLBjyAvaEOCRvdN2nzyHNvH00 rGHZj07t4WkovgKHlF2krf1SHH2RI3o8dEAlZt0Awt//LpHUcmFLTWl7buGxg8XdRpML 6rdF2JuaKdlTEh5qBdExzamd9GlAw2wIeMFkj60LUQvSfJfPMoj7zgxP0aLLuNhaO3o3 2/fuiCyI7ptIODDtTBQyItHafqE4LAsOHHgxgcXnNaQBrtPkXWwnd49hi2UxtgJ6a/pX M99BT5dJe3xsxoK8NLMc5UyWPvXiQsGT5rFoeuxLYneMuf9ajWskHSlQAas6WjWoXzf8 WyuQ== X-Received: by 10.180.95.67 with SMTP id di3mr43108724wib.78.1433355459138; Wed, 03 Jun 2015 11:17:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Wed, 3 Jun 2015 11:17:18 -0700 (PDT) In-Reply-To: <556EF4F9.1060700@ericsson.com> References: <556EF4F9.1060700@ericsson.com> From: Bernard Aboba Date: Wed, 3 Jun 2015 11:17:18 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d044287e2fa997d0517a112d9 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 03 Jun 2015 18:17:44 -0000 --f46d044287e2fa997d0517a112d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Magnus said: "This in itself should not be a significant issue. The binding to the right media block in the SDP is done using MID. Which, will be sent in an RTP header extension to ensure that stream upon reception is correctly associated. The RTP synchronization information will arrive in RTCP or even in the RTP header extension if the peers both supports RFC 6051. Thus minimal media impacts is to be expected." [BA] I do agree that this is a basic scenario that should work. However, Section 5.2.1 of draft-ietf-rtcweb-rtp-usage indicates that RFC 6051 is RECOMMENDED, but not mandatory. "B. The next question is if a RTP payload type change actually requires the node that performs the change to actually initiate an Offer/answer exchange to update their a=3Dssrc values?" [BA]Today in audio scenarios the use of a=3Dssrc is not very prevalent outside of WebRTC, and yet the switching scenario you describe still typically works without an additional O/A exchange. So a developer experienced in legacy systems might be surprised if another O/A exchange was needed. So I wonder if the a=3Dssrc line should always be required (an= d if it is not there, whether the audio scenario should be expected to "just work"). One argument in favor of requiring a=3Dssrc is that at the RTP level the switching scenario may not be that easily distinguished from a scenario where multiple SSRCs are being received at once (where a mediadiscarded Event might be appropriate). Also, in video scenarios the a=3Dssrc line is much more common (e.g. where one of several simulcast streams is being received, the SSRC can change along with characteristics of the video such as framerate and resolution). Overall though, IMHO the behavior in this scenario is currently under-specified. The Unified Plan document included some text relating to this, but it doesn't seem to have made its way into any WG work items. On Wed, Jun 3, 2015 at 5:37 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I want raise for discussion the fact that I think JSEP does not handle RT= P > payload type switching as currently specified. > > So lets walk through a case of RTP payload type switching and what it > means according to the specifications we do have. > > So we have an established PeerConnection with one audio track for which w= e > have negotiated the possibility to send both PCM and OPUS. If the sender > decides to switch RTP payload type, lets say from OPUS to PCM. The reason > is actually not important, but lets say due to a "replace track" API call > as currently being discussed on W3C WebRTC group. > > When that RTP payload type switch from OPUS to PCM we also have an RTP > timestamp rate change, from 48 kHz to 8 kHz. As specified in RTP usage > (Section 4.3): > > If performing changes between two RTP payload types that use > different RTP clock rates, an RTP sender MUST follow the > recommendations in Section 4.1 of [RFC7160]. > > So lets look at what RFC 7160 says: > > 4.1. RTP Sender (with RTCP) > > An RTP Sender with RTCP turned on MUST use a different SSRC for each > different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST > be used if the clock rate switches back to a value already seen in > the RTP stream. > > Thus, this Payload type change forces the use of a new SSRC. > > This in itself should not be a significant issue. The binding to the righ= t > media block in the SDP is done using MID. Which, will be sent in an RTP > header extension to ensure that stream upon reception is correctly > associated. The RTP synchronization information will arrive in RTCP or ev= en > in the RTP header extension if the peers both supports RFC 6051. Thus > minimal media impacts is to be expected. > > But, discussing what happens in this case with Stefan H=C3=A5kansson we d= id > look into JSEP. And here we clearly have some short commings in the > specification. > > A. First of all there is an assumption that the value of a=3Dssrc will no= t > change. For example Section 5.2.2 (Subsequent Offers): > > o For MediaStreamTracks that are still present, the "a=3Dmsid", > "a=3Dssrc", and "a=3Dssrc-group" lines MUST stay the same. > > If an RTP payload type switching has occured that forces a SSRC change > then I expect that the actually used SSRCs are included in the offer. Thu= s, > both a=3Dssrc and a=3Dssrc-group can change in subsequent offers. > > B. The next question is if a RTP payload type change actually requires th= e > node that performs the change to actually initiate an Offer/answer exchan= ge > to update their a=3Dssrc values? > > Clearly JSEP needs to be updated to address these issues. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d044287e2fa997d0517a112d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus said:=C2=A0

"This in itself should not be a significant i= ssue. The binding to the right media block in the SDP is done using MID. Wh= ich, will be sent in an RTP header extension to ensure that stream upon rec= eption is correctly associated. The RTP synchronization information will ar= rive in RTCP or even in the RTP header extension if the peers both supports= RFC 6051. Thus minimal media impacts is to be expected."
=

[BA] I do agree that this is a basic scenario that shou= ld work. However, Section 5.2.1 of draft-ietf-rtcweb-rtp-usage indicates th= at RFC 6051 is RECOMMENDED, but not mandatory.=C2=A0

"B. The next question = is if a RTP payload type change actually requires the node that performs th= e change to actually initiate an Offer/answer exchange to update their a=3D= ssrc values?"

[BA]Today in audio scena= rios the use of a=3Dssrc is not very prevalent outside of WebRTC, and yet t= he switching scenario you describe still typically works without an additio= nal O/A exchange.=C2=A0 So a developer experienced in legacy systems might = be surprised if another O/A exchange was needed.=C2=A0 So I wonder if the a= =3Dssrc line should always be required (and if it is not there, whether the= audio scenario should be expected to "just work"). =C2=A0
<= div>
One argument in favor of requiring a=3Dssrc is that at t= he RTP level the switching scenario may not be that easily distinguished fr= om a scenario where multiple SSRCs are being received at once (where a medi= adiscarded Event might be appropriate).=C2=A0 Also, in video scenarios the = a=3Dssrc line is much more common (e.g. where one of several simulcast stre= ams is being received, the SSRC can change along with characteristics of th= e video such as framerate and resolution). =C2=A0

= Overall though, IMHO the behavior in this scenario is currently under-speci= fied.=C2=A0 The Unified Plan document included some text relating to this, = but it doesn't seem to have made its way into any WG work items.=C2=A0<= /div>

On Wed= , Jun 3, 2015 at 5:37 AM, Magnus Westerlund <magnus.westerl= und@ericsson.com> wrote:
Hi= ,

I want raise for discussion the fact that I think JSEP does not handle RTP = payload type switching as currently specified.

So lets walk through a case of RTP payload type switching and what it means= according to the specifications we do have.

So we have an established PeerConnection with one audio track for which we = have negotiated the possibility to send both PCM and OPUS. If the sender de= cides to switch RTP payload type, lets say from OPUS to PCM. The reason is = actually not important, but lets say due to a "replace track" API= call as currently being discussed on W3C WebRTC group.

When that RTP payload type switch from OPUS to PCM we also have an RTP time= stamp rate change, from 48 kHz to 8 kHz. As specified in RTP usage (Section= 4.3):

=C2=A0 =C2=A0If performing changes between two RTP payload types that use =C2=A0 =C2=A0different RTP clock rates, an RTP sender MUST follow the
=C2=A0 =C2=A0recommendations in Section 4.1 of [RFC7160].

So lets look at what RFC 7160 says:

4.1.=C2=A0 RTP Sender (with RTCP)

=C2=A0 =C2=A0An RTP Sender with RTCP turned on MUST use a different SSRC fo= r each
=C2=A0 =C2=A0different clock rate.=C2=A0 An RTCP BYE MUST be sent and a new= SSRC MUST
=C2=A0 =C2=A0be used if the clock rate switches back to a value already see= n in
=C2=A0 =C2=A0the RTP stream.

Thus, this Payload type change forces the use of a new SSRC.

This in itself should not be a significant issue. The binding to the right = media block in the SDP is done using MID. Which, will be sent in an RTP hea= der extension to ensure that stream upon reception is correctly associated.= The RTP synchronization information will arrive in RTCP or even in the RTP= header extension if the peers both supports RFC 6051. Thus minimal media i= mpacts is to be expected.

But, discussing what happens in this case with Stefan H=C3=A5kansson we did= look into JSEP. And here we clearly have some short commings in the specif= ication.

A. First of all there is an assumption that the value of a=3Dssrc will not = change. For example Section 5.2.2 (Subsequent Offers):

=C2=A0 o=C2=A0 For MediaStreamTracks that are still present, the "a=3D= msid",
=C2=A0 =C2=A0 =C2=A0 "a=3Dssrc", and "a=3Dssrc-group" l= ines MUST stay the same.

If an RTP payload type switching has occured that forces a SSRC change then= I expect that the actually used SSRCs are included in the offer. Thus, bot= h a=3Dssrc and a=3Dssrc-group can change in subsequent offers.

B. The next question is if a RTP payload type change actually requires the = node that performs the change to actually initiate an Offer/answer exchange= to update their a=3Dssrc values?

Clearly JSEP needs to be updated to address these issues.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--f46d044287e2fa997d0517a112d9-- From nobody Wed Jun 3 13:07:01 2015 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 0B0561A7028 for ; Wed, 3 Jun 2015 13:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] 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 l920UxJV92nR for ; Wed, 3 Jun 2015 13:06:56 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 789761A0282 for ; Wed, 3 Jun 2015 13:06:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8A1CD7C0951 for ; Wed, 3 Jun 2015 22:06: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 X6h58Z4pg7B8 for ; Wed, 3 Jun 2015 22:06:53 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:e536:c983:6fc4:1d46]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3E4577C0950 for ; Wed, 3 Jun 2015 22:06:53 +0200 (CEST) Message-ID: <556F5E5C.5080600@alvestrand.no> Date: Wed, 03 Jun 2015 22:06:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <556EF4F9.1060700@ericsson.com> In-Reply-To: <556EF4F9.1060700@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 03 Jun 2015 20:06:59 -0000 On 06/03/2015 02:37 PM, Magnus Westerlund wrote: > Hi, > > I want raise for discussion the fact that I think JSEP does not handle > RTP payload type switching as currently specified. > > So lets walk through a case of RTP payload type switching and what it > means according to the specifications we do have. > > So we have an established PeerConnection with one audio track for > which we have negotiated the possibility to send both PCM and OPUS. If > the sender decides to switch RTP payload type, lets say from OPUS to > PCM. The reason is actually not important, but lets say due to a > "replace track" API call as currently being discussed on W3C WebRTC > group. > > When that RTP payload type switch from OPUS to PCM we also have an RTP > timestamp rate change, from 48 kHz to 8 kHz. As specified in RTP usage > (Section 4.3): > > If performing changes between two RTP payload types that use > different RTP clock rates, an RTP sender MUST follow the > recommendations in Section 4.1 of [RFC7160]. > > So lets look at what RFC 7160 says: > > 4.1. RTP Sender (with RTCP) > > An RTP Sender with RTCP turned on MUST use a different SSRC for each > different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST > be used if the clock rate switches back to a value already seen in > the RTP stream. > > Thus, this Payload type change forces the use of a new SSRC. > > This in itself should not be a significant issue. The binding to the > right media block in the SDP is done using MID. Which, will be sent in > an RTP header extension to ensure that stream upon reception is > correctly associated. The RTP synchronization information will arrive > in RTCP or even in the RTP header extension if the peers both supports > RFC 6051. Thus minimal media impacts is to be expected. > > But, discussing what happens in this case with Stefan Håkansson we did > look into JSEP. And here we clearly have some short commings in the > specification. > > A. First of all there is an assumption that the value of a=ssrc will > not change. For example Section 5.2.2 (Subsequent Offers): > > o For MediaStreamTracks that are still present, the "a=msid", > "a=ssrc", and "a=ssrc-group" lines MUST stay the same. > > If an RTP payload type switching has occured that forces a SSRC change > then I expect that the actually used SSRCs are included in the offer. > Thus, both a=ssrc and a=ssrc-group can change in subsequent offers. If we want to have a mechanism that: a) allows PT switching b) uses different clock rates (and therefore different SSRCs) c) doesn't need renegotiation on SSRC change I would think that the initial SDP would have to contain a=ssrc fields for *all* the possible SSRCs - that is, one "a=ssrc: cname:" line per payload type. Section 5.2.1 already specifies that there will be multiple a=ssrc lines (and a=ssrc-group lines) in the case of RTX data. So it's not exactly a novel solution. > B. The next question is if a RTP payload type change actually requires > the node that performs the change to actually initiate an Offer/answer > exchange to update their a=ssrc values? > > Clearly JSEP needs to be updated to address these issues. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 4 14:02:50 2015 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 73FF21AC3B2 for ; Thu, 4 Jun 2015 14:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 uZNz70TNFcg0 for ; Thu, 4 Jun 2015 14:02:47 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A66C1AC3B0 for ; Thu, 4 Jun 2015 14:02:47 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so1346889igb.0 for ; Thu, 04 Jun 2015 14:02:46 -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=Ii6GtkWTLWVscoLzovrfunXTK4N2fm2jLyLIzS2u270=; b=KjDO87PBFmHuIrB2TEuERq4n+A6z130hNUj+gy+xRHSQVUwWXutDP0ya6/S7cBuQaO Q3XoKd+go0NHQ49MgegIE1jUvbh429wt6AuOG77llLuuAwBtdybEFmtSp7lodSkDXDXq o6EtOAdoGo5ZqMRFF/HLZuhnDk2mpJCIUVdwuV812zMLwbLj1aacFxlr9ihx1ndKM+fb fIdVkIs6wxB1mxwPsw2au86tlDuvN3ll0Zh4k5SpJwORximpiwQqRfmjDBwI9oFoVkJY RIre2lknATxpKiZVNr0KEjyBr18Lg+dcT8CTxY+AQsrAR8XhcybmRXjGXw5JAKdZTJhX UrFw== X-Gm-Message-State: ALoCoQkczHRMpws7Rz0eggwZorrs2pL/U9hmcGBXUa6j9OLHan/6ahWjEggA9zF+g46J2CCyT5gd X-Received: by 10.107.163.146 with SMTP id m140mr5945137ioe.85.1433451766526; Thu, 04 Jun 2015 14:02:46 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by mx.google.com with ESMTPSA id j5sm1924344ioo.8.2015.06.04.14.02.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2015 14:02:45 -0700 (PDT) Received: by igbhj9 with SMTP id hj9so1324358igb.1 for ; Thu, 04 Jun 2015 14:02:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.155.74 with SMTP id d71mr30363294ioe.29.1433451764219; Thu, 04 Jun 2015 14:02:44 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Thu, 4 Jun 2015 14:02:44 -0700 (PDT) In-Reply-To: <556F5E5C.5080600@alvestrand.no> References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> Date: Thu, 4 Jun 2015 17:02:44 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1140eada359a950517b77f3a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 04 Jun 2015 21:02:48 -0000 --001a1140eada359a950517b77f3a Content-Type: text/plain; charset=UTF-8 On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand wrote: > > If we want to have a mechanism that: > > a) allows PT switching > b) uses different clock rates (and therefore different SSRCs) > c) doesn't need renegotiation on SSRC change > > I would think that the initial SDP would have to contain a=ssrc fields for > *all* the possible SSRCs - that is, one "a=ssrc: cname:" line > per payload type. > > Section 5.2.1 already specifies that there will be multiple a=ssrc lines > (and a=ssrc-group lines) in the case of RTX data. So it's not exactly a > novel solution. > > I agree with one small correction -- it is not a separate SSRC per payload type, but separate SSRC per clock rate. For instance, if you have G.711 audio, RFC 4733 tones and CN at 8KHz, there is going to be a payload type for each of them, but all this media should use the same SSRC. Opus, RFC 4733 tones and CN at 48Khz (and you will need to specify to different payloads for tones and CN for different clock rates), will use second SSRC. The reason for separate SSRCs is to have RTCP reports to work correctly, which requires to use the same time units for all the media under particular SSRC. Multiple payloads running with the same clock rate can re-use the same SSRC without any issues. It actually is beneficial to use the same SSRC since they can be synchronized based on the RTP time stamps which would be more precise then ntp time. _____________ Roman Shpount --001a1140eada359a950517b77f3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand &l= t;harald@alvestra= nd.no> wrote:

 If we want to have a mechanism that:

a) allows PT switching
b) uses different clock rates (and therefore different SSRCs)
c) doesn't need renegotiation on SSRC change

I would think that the initial SDP would have to contain a=3Dssrc fields fo= r *all* the possible SSRCs - that is, one "a=3Dssrc:<nnnn> cname= :<cname>" line per payload type.

Section 5.2.1 already specifies that there will be multiple a=3Dssrc lines = (and a=3Dssrc-group lines) in the case of RTX data. So it's not exactly= a novel solution.


I agree with one small correction -- it is not a = separate SSRC per payload type, but separate SSRC per clock rate. For insta= nce, if you have G.711 audio, RFC 4733 tones and CN at 8KHz, there is going= to be a payload type for each of them, but all this media should use the s= ame SSRC. Opus, RFC 4733 tones and CN at 48Khz (and you will need to specif= y to different payloads for tones and CN for different clock rates), will u= se second SSRC.

The reason for separate SSRCs is t= o have RTCP reports to work correctly, which requires to use the same time = units for all the media under particular SSRC. Multiple payloads running wi= th the same clock rate can re-use the same SSRC without any issues. It actu= ally is beneficial to use the same SSRC since they can be synchronized base= d on the RTP time stamps which would be more precise then ntp time.
_____________
Roman Shpount

=C2=A0
--001a1140eada359a950517b77f3a-- From nobody Mon Jun 8 01:48:51 2015 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 D21331B2D94 for ; Mon, 8 Jun 2015 01:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_14=0.6, 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 rm31uf76HMyX for ; Mon, 8 Jun 2015 01:48:49 -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 E16251B2CAA for ; Mon, 8 Jun 2015 01:48:48 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-f6-557556ee6534 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.27.28096.EE655755; Mon, 8 Jun 2015 10:48:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Mon, 8 Jun 2015 10:48:46 +0200 Message-ID: <557556ED.8050206@ericsson.com> Date: Mon, 8 Jun 2015 10:48:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Roman Shpount , Harald Alvestrand References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+Jvre77sNJQgz0XuC2O9XWxWcy4MJXZ Yu2/dnYHZo8rE66weixZ8pPJ49aUggDmKC6blNSczLLUIn27BK6MXzP3sBbsla3Y9fgkawNj v3gXIyeHhICJROOVT8wQtpjEhXvr2boYuTiEBI4ySsz8+ogZwlnGKNEwcx6Qw8HBK6Atcf+1 L0gDi4CKxILdDSwgNpuAhcTNH41sILaoQJTE1MfrwOK8AoISJ2c+AbNFBAIlnh+ewApiMwuo S9xZfI4dxBYW8JV4vWgzK8SuiYwSvzqfgl3ECdTQNmsmI8heZgF7iQdbyyB65SWat84GKxEC OqehqYN1AqPgLCTrZiF0zELSsYCReRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYPge3PLb agfjweeOhxgFOBiVeHgf7CsJFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8UWlO avEhRiYOTqkGxvitTnbBHO1RCh1WHxkO2u53fC/dM98o4PIRYd8JV27t6ntRqvXRn2dtuPyy C7Uym73WK7Upr57076P9l4g8xTe6scl35092Zo1V37WjQ0Jkg47l3bPx2zf2+D6XbN8fm/HK y/yr0TzddNsDmeyH/s951W1gcEZp7fV1pmI1VZbW167dXO7coMRSnJFoqMVcVJwIAJNql7hA AgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 08:48:51 -0000 Roman Shpount skrev den 2015-06-04 23:02: > On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand > wrote: > > > If we want to have a mechanism that: > > a) allows PT switching > b) uses different clock rates (and therefore different SSRCs) > c) doesn't need renegotiation on SSRC change > > I would think that the initial SDP would have to contain a=ssrc > fields for *all* the possible SSRCs - that is, one "a=ssrc: > cname:" line per payload type. > > Section 5.2.1 already specifies that there will be multiple a=ssrc > lines (and a=ssrc-group lines) in the case of RTX data. So it's not > exactly a novel solution. > > > I agree with one small correction -- it is not a separate SSRC per > payload type, but separate SSRC per clock rate. For instance, if you > have G.711 audio, RFC 4733 tones and CN at 8KHz, there is going to be a > payload type for each of them, but all this media should use the same > SSRC. Opus, RFC 4733 tones and CN at 48Khz (and you will need to specify > to different payloads for tones and CN for different clock rates), will > use second SSRC. > > The reason for separate SSRCs is to have RTCP reports to work correctly, > which requires to use the same time units for all the media under > particular SSRC. Multiple payloads running with the same clock rate can > re-use the same SSRC without any issues. It actually is beneficial to > use the same SSRC since they can be synchronized based on the RTP time > stamps which would be more precise then ntp time. However, this can't work as RFC 7160 says in Section 4.1: An RTP Sender with RTCP turned on MUST use a different SSRC for each different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST be used if the clock rate switches back to a value already seen in the RTP stream. Note the second sentence. One would still have to do a new round of signalling to prime a new SSRC for the previous rate after having switched to be able to switch back to that Payload Type. I would to some degree argue that renegotiation is not needed here. My preference would be for a solution that rather use header extensions to indicate what "purpose" the new RTP stream has so that one understands that this is the replacement for an earlier RTP stream. For the cases where a source is encoded into a single encoded stream and put in one RTP stream I think all the necessary indications are there. MID for which m line it belongs. The PT will indicate if it a source RTP stream or an Redundancy RTP stream (FEC or RTX). It is when one comes to scalability layers sent in multiple RTP streams it becomes problematic to determine on RTP level which is which, without looking into payload header info to determine which layer the payload contains. Having said that I do wonder if this will be a problem, especially in gateways to legacy. Where this behaviour will make the legacy peer fall over. Thus requiring a gateway that remap back to a single stable SSRC, possibly with loss of synch information. Please remember that there are reasons why the SSRC change was made as the required behaviour. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 8 02:19:23 2015 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 4DC0D1B2DD1 for ; Mon, 8 Jun 2015 02:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] 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 Ixq7cSgDmgs0 for ; Mon, 8 Jun 2015 02:19: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 EAD591B2DCE for ; Mon, 8 Jun 2015 02:19:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 52AF37C0A3A; Mon, 8 Jun 2015 11:19:17 +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 j0KN_mc2sV-J; Mon, 8 Jun 2015 11:19:15 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:fd19:c332:d33e:eb48] (unknown [IPv6:2001:470:de0a:27:fd19:c332:d33e:eb48]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6624C7C05D7; Mon, 8 Jun 2015 11:19:15 +0200 (CEST) Message-ID: <55755E12.8020201@alvestrand.no> Date: Mon, 08 Jun 2015 11:19:14 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> In-Reply-To: <557556ED.8050206@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 09:19:21 -0000 Den 08. juni 2015 10:48, skrev Magnus Westerlund: > Roman Shpount skrev den 2015-06-04 23:02: >> On Wed, Jun 3, 2015 at 4:06 PM, Harald Alvestrand > > wrote: >> >> >> If we want to have a mechanism that: >> >> a) allows PT switching >> b) uses different clock rates (and therefore different SSRCs) >> c) doesn't need renegotiation on SSRC change >> >> I would think that the initial SDP would have to contain a=ssrc >> fields for *all* the possible SSRCs - that is, one "a=ssrc: >> cname:" line per payload type. >> >> Section 5.2.1 already specifies that there will be multiple a=ssrc >> lines (and a=ssrc-group lines) in the case of RTX data. So it's not >> exactly a novel solution. >> >> >> I agree with one small correction -- it is not a separate SSRC per >> payload type, but separate SSRC per clock rate. For instance, if you >> have G.711 audio, RFC 4733 tones and CN at 8KHz, there is going to be a >> payload type for each of them, but all this media should use the same >> SSRC. Opus, RFC 4733 tones and CN at 48Khz (and you will need to specify >> to different payloads for tones and CN for different clock rates), will >> use second SSRC. >> >> The reason for separate SSRCs is to have RTCP reports to work correctly, >> which requires to use the same time units for all the media under >> particular SSRC. Multiple payloads running with the same clock rate can >> re-use the same SSRC without any issues. It actually is beneficial to >> use the same SSRC since they can be synchronized based on the RTP time >> stamps which would be more precise then ntp time. > > However, this can't work as RFC 7160 says in Section 4.1: > > An RTP Sender with RTCP turned on MUST use a different SSRC for each > different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST > be used if the clock rate switches back to a value already seen in > the RTP stream. > > Note the second sentence. One would still have to do a new round of > signalling to prime a new SSRC for the previous rate after having > switched to be able to switch back to that Payload Type. Hm. I missed that when reviewing the clock-rate doc. So that means one uses up an SSRC for every clock rate switch. That seems silly; is it possible that this should be considered an erratum for RFC 7160? > I would to some degree argue that renegotiation is not needed here. My > preference would be for a solution that rather use header extensions to > indicate what "purpose" the new RTP stream has so that one understands > that this is the replacement for an earlier RTP stream. That would of course be incompatible with anything that came before. > For the cases where a source is encoded into a single encoded stream and > put in one RTP stream I think all the necessary indications are there. > MID for which m line it belongs. The PT will indicate if it a source RTP > stream or an Redundancy RTP stream (FEC or RTX). > > It is when one comes to scalability layers sent in multiple RTP streams > it becomes problematic to determine on RTP level which is which, without > looking into payload header info to determine which layer the payload > contains. But I just can't imagine switching clock rates for different layers of a scalability-encoded stream. Should we just not solve the problem of behaving bizarrely for this case? > > Having said that I do wonder if this will be a problem, especially in > gateways to legacy. Where this behaviour will make the legacy peer fall > over. Thus requiring a gateway that remap back to a single stable SSRC, > possibly with loss of synch information. Please remember that there are > reasons why the SSRC change was made as the required behaviour. Are there legacy gateways that will NOT fall over on a clock rate + SSRC switch? If so - what do these legacy gateways do when switching back to the original PT? New SSRC, or back to a previously used SSRC? > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From nobody Mon Jun 8 02:37:13 2015 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 945C01B2E2D for ; Mon, 8 Jun 2015 02:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 M6lcuyP1DXZm for ; Mon, 8 Jun 2015 02:37:04 -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 5B69D1B2DE2 for ; Mon, 8 Jun 2015 02:37:02 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-54-55756239b948 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4D.22.28096.C3265755; Mon, 8 Jun 2015 11:37:00 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.210.2; Mon, 8 Jun 2015 11:36:56 +0200 Message-ID: <55756237.6060206@ericsson.com> Date: Mon, 8 Jun 2015 11:36:55 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Harald Alvestrand , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> In-Reply-To: <55755E12.8020201@alvestrand.no> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvra5NUmmowalODYtjfV1sFjMuTGW2 WPuvnd2B2ePKhCusHkuW/GTyuDWlIIA5issmJTUnsyy1SN8ugSvj7Wvvgh7liln7drI2MH6V 7mLk5JAQMJF4tm0vO4QtJnHh3nq2LkYuDiGBo4wSdw++ZgJJCAksY5R4s8oSxOYV0Jb4eXYO WAOLgIrEtCMPwGw2AQuJmz8a2UBsUYEoiamP17FA1AtKnJz5BMwWEQiUuP39M1gNs4C6xJ3F 58B6hQV8JV4v2swKsesSo8Sm18UgNqeArsSf0++AbuAAqreXeLC1DKJVXqJ562xmiHJtiYam DtYJjIKzkGybhdAxC0nHAkbmVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBoXtwy2+rHYwH nzseYhTgYFTi4X2wryRUiDWxrLgy9xCjNAeLkjjvjM15oUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYXS4c5S1u9b1VsunfBUthkTjBLZv/fzzvfeFoTNUjnp+rDWuWTgqYqR2yUCeYY15P xJFPgo+kfk3QiRKe/G3PmURuyRTHbTcOfN7822OS0ZT+HSuseae9e/zz/NS0Ey3Hrzi6l+W1 Tv0t11zmH/bNQem9eKugMUPddn3pIqnH4rvswg9Ubd/RrsRSnJFoqMVcVJwIAApItbg+AgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 09:37:06 -0000 Harald Alvestrand skrev den 2015-06-08 11:19: > Den 08. juni 2015 10:48, skrev Magnus Westerlund: >> However, this can't work as RFC 7160 says in Section 4.1: >> >> An RTP Sender with RTCP turned on MUST use a different SSRC for each >> different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST >> be used if the clock rate switches back to a value already seen in >> the RTP stream. >> >> Note the second sentence. One would still have to do a new round of >> signalling to prime a new SSRC for the previous rate after having >> switched to be able to switch back to that Payload Type. > > Hm. I missed that when reviewing the clock-rate doc. > So that means one uses up an SSRC for every clock rate switch. That > seems silly; is it possible that this should be considered an erratum > for RFC 7160? No, it is highly intentional as I remember the discussion. > >> I would to some degree argue that renegotiation is not needed here. My >> preference would be for a solution that rather use header extensions to >> indicate what "purpose" the new RTP stream has so that one understands >> that this is the replacement for an earlier RTP stream. > > That would of course be incompatible with anything that came before. All that has used multiple streams per endpoint before has had some implicit rules to handle different situations. What is forcing the issue here is the realization about RFC 7160 forcing SSRC changes. If there is single encoding per endpoint, then using CNAME and PT is sufficient to associate when one switches. If one have multiple streams then the fun starts. IETF has never had any specifications for solving this, so from that perspective we are laying down a solution where different interpretations has been used based on what is specific for that application. > >> For the cases where a source is encoded into a single encoded stream and >> put in one RTP stream I think all the necessary indications are there. >> MID for which m line it belongs. The PT will indicate if it a source RTP >> stream or an Redundancy RTP stream (FEC or RTX). >> >> It is when one comes to scalability layers sent in multiple RTP streams >> it becomes problematic to determine on RTP level which is which, without >> looking into payload header info to determine which layer the payload >> contains. > > But I just can't imagine switching clock rates for different layers of a > scalability-encoded stream. Should we just not solve the problem of > behaving bizarrely for this case? That was not what I meant. If one switches to or from a scalable encoder or between different encoders, the one might be in a situation where one needs to identify that one set of SSRCs are now replaced with a different set of SSRCs. What I was unclear on was that multiple RTP streams for a single media source due to scalable encoding anyway has this issue with identification. I think the solution to that is likely a combination of MID and something like the header marking header extension being proposed in AVTEXT: https://datatracker.ietf.org/doc/draft-berger-avtext-framemarking/ That way the identification information is available to the receiver directly before having to look into payload. Something that will be impossible in a PERC scenario anyway. > >> >> Having said that I do wonder if this will be a problem, especially in >> gateways to legacy. Where this behaviour will make the legacy peer fall >> over. Thus requiring a gateway that remap back to a single stable SSRC, >> possibly with loss of synch information. Please remember that there are >> reasons why the SSRC change was made as the required behaviour. > > Are there legacy gateways that will NOT fall over on a clock rate + SSRC > switch? Good Question! > If so - what do these legacy gateways do when switching back to the > original PT? New SSRC, or back to a previously used SSRC? > Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 8 05:28:46 2015 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 2DA451A1BBB; Mon, 8 Jun 2015 05:28:45 -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 bosc4BTREqLf; Mon, 8 Jun 2015 05:28:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4DE1A1A25; Mon, 8 Jun 2015 05:28:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608122843.32038.25147.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 05:28:43 -0700 Archived-At: Cc: draft-ietf-rtcweb-video.ad@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-video@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-video.shepherd@ietf.org Subject: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-video-05: (with COMMENT) 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, 08 Jun 2015 12:28:45 -0000 Barry Leiba has entered the following ballot position for draft-ietf-rtcweb-video-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do wonder that the Abstract and Introduction are both short, and, yet, give such different descriptions of the document as to make it look like two different documents.  Given how short they are, perhaps it really is best to make them the same, no? Abstract:    This specification provides the requirements and considerations for    WebRTC applications to send and receive video across a network.  It    specifies the video processing that is required, as well as video    codecs and their parameters. Introduction:    This    specification defines how the video is used and discusses special    considerations for processing the video.  It also covers the video-    related algorithms WebRTC devices need to support. From nobody Mon Jun 8 07:15:05 2015 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 91E081A88BD for ; Mon, 8 Jun 2015 07:15:04 -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, J_CHICKENPOX_14=0.6, 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 FLD1hQprFSc6 for ; Mon, 8 Jun 2015 07:15:03 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9C21A88C0 for ; Mon, 8 Jun 2015 07:15:03 -0700 (PDT) Received: by oihb142 with SMTP id b142so93884398oih.3 for ; Mon, 08 Jun 2015 07:15:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zd2MBFaKf36zKH/Bg1Np6JS997uI/IPVPNSkDzoENQ0=; b=gmKlyNcpKTqSTP5RhUlzT9TWBdqkTLn5WhDBXONthIhYXadAL84792sXVUJd/6Bsu0 ek+sh9GWOOudLXujfsBbsOag44mEYGtxCzqekRpUZraWihtXRC/+CituF/b10qeHCMWh qALuqjP+0ETpUOIiEdtSrdyVi/onNIlJMAqkhE4js9WzArUvTjNq1KfxszLYGXLwvlct 8Y//hlP2l5TdURg/CfRqBwcbVrtYjIDFzRA4yyUAVDuI3IIpwuakOqO8uRfqel31+aH1 i83TjX7IBbuGPLNllR95cGPgsIPqepy+UBdGmMP0ggexlju5F7xI6WYl8BSbqpmTKZ+W bd4g== X-Gm-Message-State: ALoCoQkdCnAajmwEGUFAfEhbSAwO0lC4iBNR5ejK2nGMJShf+f1tMlm+m00S4G64cqs59d852J8a X-Received: by 10.202.216.138 with SMTP id p132mr13863923oig.133.1433772902789; Mon, 08 Jun 2015 07:15:02 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id yo9sm1829006obc.3.2015.06.08.07.15.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2015 07:15:01 -0700 (PDT) Message-ID: <5575A364.7060900@jive.com> Date: Mon, 08 Jun 2015 08:15:00 -0600 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , Harald Alvestrand , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> In-Reply-To: <55756237.6060206@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 14:15:04 -0000 Le 2015-06-08 03:36, Magnus Westerlund a écrit : > Harald Alvestrand skrev den 2015-06-08 11:19: >> Den 08. juni 2015 10:48, skrev Magnus Westerlund: > >>> However, this can't work as RFC 7160 says in Section 4.1: >>> >>> An RTP Sender with RTCP turned on MUST use a different SSRC for each >>> different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST >>> be used if the clock rate switches back to a value already seen in >>> the RTP stream. >>> >>> Note the second sentence. One would still have to do a new round of >>> signalling to prime a new SSRC for the previous rate after having >>> switched to be able to switch back to that Payload Type. >> >> Hm. I missed that when reviewing the clock-rate doc. >> So that means one uses up an SSRC for every clock rate switch. That >> seems silly; is it possible that this should be considered an erratum >> for RFC 7160? > > No, it is highly intentional as I remember the discussion. Can you please explain, for those of us with short memories? :) >> Are there legacy gateways that will NOT fall over on a clock rate + SSRC >> switch? > > Good Question! Depends what you mean by "legacy". My gateway will not fall over. >> If so - what do these legacy gateways do when switching back to the >> original PT? New SSRC, or back to a previously used SSRC? As RFC 7160 says: new SSRC. Simon From nobody Mon Jun 8 07:43:12 2015 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 4667B1A8AE9 for ; Mon, 8 Jun 2015 07:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 GyLvlQlo758Q for ; Mon, 8 Jun 2015 07:43:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF7F1A8AE3 for ; Mon, 8 Jun 2015 07:43:08 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-7a-5575a9fb696e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FE.EC.04015.BF9A5755; Mon, 8 Jun 2015 16:43:07 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.210.2; Mon, 8 Jun 2015 16:43:06 +0200 Message-ID: <5575A9F9.5030504@ericsson.com> Date: Mon, 8 Jun 2015 16:43:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Perreault , Harald Alvestrand , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> <5575A364.7060900@jive.com> In-Reply-To: <5575A364.7060900@jive.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvre7vlaWhBg93SFkc6+tis5hxYSqz xdp/7ewW16+EOrB4XJlwhdVjyZKfTB7/5jxl9rg1pSCAJYrLJiU1J7MstUjfLoErY/XHH6wF P8Qrfqzbx9TA+FGoi5GTQ0LAROLTzK2MELaYxIV769m6GLk4hASOMkrM3HiDHcJZxijRMO89 E0gVr4C2xIrLO1lBbBYBFYnlO76C2WwCFhI3fzSygdiiAlESUx+vY4GoF5Q4OfMJmC0iUCFx c00bM4jNLKAucWfxOXYQW1jAV+L1os2sEMv6mCROLTgHtIyDg1NAQ6J7kwWIySxgL/FgaxlE q7xE89bZYGOEgM5paOpgncAoOAvJtlkIHbOQdCxgZF7FKFqcWpyUm25kpJdalJlcXJyfp5eX WrKJERjQB7f8NtjB+PK54yFGAQ5GJR7eB/tKQoVYE8uKK3MPMUpzsCiJ887YnBcqJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgbH8eNdP8e3lTvLbI3rqWl2FrzK+33O3j5V/8rTmaYsMP81V OMpSbtqjzPw5aN688lA2w+3+zZtrTix7qb+zq3Pl/NnnNr3Wua9xtdWWy/DTTEbOrzzFHOXv nc7yStfWWThfLzL9e+NxkGde4CqHWemlcvfDVv7JWzth9ureshzJlded44uKTyqxFGckGmox FxUnAgDEE2p0SQIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 14:43:11 -0000 Simon Perreault skrev den 2015-06-08 16:15: > Le 2015-06-08 03:36, Magnus Westerlund a écrit : >> Harald Alvestrand skrev den 2015-06-08 11:19: >>> Den 08. juni 2015 10:48, skrev Magnus Westerlund: >> >>>> However, this can't work as RFC 7160 says in Section 4.1: >>>> >>>> An RTP Sender with RTCP turned on MUST use a different SSRC for each >>>> different clock rate. An RTCP BYE MUST be sent and a new SSRC MUST >>>> be used if the clock rate switches back to a value already seen in >>>> the RTP stream. >>>> >>>> Note the second sentence. One would still have to do a new round of >>>> signalling to prime a new SSRC for the previous rate after having >>>> switched to be able to switch back to that Payload Type. >>> >>> Hm. I missed that when reviewing the clock-rate doc. >>> So that means one uses up an SSRC for every clock rate switch. That >>> seems silly; is it possible that this should be considered an erratum >>> for RFC 7160? >> >> No, it is highly intentional as I remember the discussion. > > Can you please explain, for those of us with short memories? :) I went and checked this. This formulation has been present since the first versions, and no one has questioned this RFC 2119 worded statement. Therefore I consider there to be consensus behind it and being intentional. The motivation I see for this statement is the following. First of all I think people have been against considering having stand bye SSRCs that are really likely to never be used. I think DTMF is one of these exceptions. Having stand by SSRC also have an overhead cost, primarily in the result of the number of SSRCs present in the session and their consumption of their share of the RTCP bandwidth resources. We also have the issue of correctly associating the SSRC to a media source, now that there are more than one. Based on that, (with the assumption that you do PT switching rarely) the lower cost is to drop the SSRC after its usage. From that follows that one stop using it, and therefore sends BYE, then you really should not revive a dead SSRC. Thus, need to create a new one. Simply codifying this expectation in the RFC. > >>> Are there legacy gateways that will NOT fall over on a clock rate + SSRC >>> switch? >> >> Good Question! > > Depends what you mean by "legacy". My gateway will not fall over. > I think this is an import aspect. The gateway is not legacy, as it is an WebRTC gateway. It is the endpoint on the other side of the gateway that is "legacy". Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 8 07:57:39 2015 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 BB9C61B2E70 for ; Mon, 8 Jun 2015 07:57:37 -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, J_CHICKENPOX_14=0.6, 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 v4WCpt9_4y96 for ; Mon, 8 Jun 2015 07:57:36 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB351B2E73 for ; Mon, 8 Jun 2015 07:57:36 -0700 (PDT) Received: by obbgp2 with SMTP id gp2so77776480obb.2 for ; Mon, 08 Jun 2015 07:57:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xBGkc4lPSYaze8jMbHeCFP64guUlH0T2DNCXz9lVu1c=; b=ht/SZUnOQ3zVfe1d6yeI9PlmarSyJz1cd9u0R1TmUWG4gUruYRh3ws4Bb/LL/rIE02 UKzf4saePvJxrETc9uTp5f/R2zyaeLxie0uL0/YLI4ntCAQtwBMu+L5UCDI/Ccpm6wqm 1Bwq57bmU6M6LFANF4EyunSBnXjFw1Ylm+lz1LEu5KJLe6R6msKlqnw/ZJ4TmmP98D3n nzyZiTK0ONFm6u/0XboQBsU5FUikP+ZsYa6L1wxshIy3P7fh/ZewPrvHc5DwpXfzimgG mNI3KIztmCoB0N3zC8H1zm5SpXRnqBn6fP9tRBcH+fmpZEUnTok/bOOkML7fwSg2cWcM LYoQ== X-Gm-Message-State: ALoCoQlEaRrDHSjChd4ErIcwuS06rbJCSmydN8R3z3AnV3R4GdvypTWsepCYZm7VBOvTxWx2+F1H X-Received: by 10.182.230.75 with SMTP id sw11mr14230897obc.60.1433775455736; Mon, 08 Jun 2015 07:57:35 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id fy4sm1881082oeb.12.2015.06.08.07.57.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2015 07:57:35 -0700 (PDT) Message-ID: <5575AD5D.5070001@jive.com> Date: Mon, 08 Jun 2015 08:57:33 -0600 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , Harald Alvestrand , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> <5575A364.7060900@jive.com> <5575A9F9.5030504@ericsson.com> In-Reply-To: <5575A9F9.5030504@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 14:57:37 -0000 Le 2015-06-08 08:43, Magnus Westerlund a écrit : >>>> Are there legacy gateways that will NOT fall over on a clock rate + >>>> SSRC >>>> switch? >>> >>> Good Question! >> >> Depends what you mean by "legacy". My gateway will not fall over. >> > > I think this is an import aspect. The gateway is not legacy, as it is an > WebRTC gateway. It is the endpoint on the other side of the gateway that > is "legacy". My modus operandi with endpoints is: if you haven't tested it and seen it working, then you must assume it will fail. It's a sad state of affairs. Implementers should be whipped and forced to attend SIPit. ;) In any case, that's why we have SBCs. Personally, having the WebRTC clients do the right thing makes my life easier. Focusing too much on compatibility with legacy makes my life harder. I can make the gateway do the fixup easily. But as WebRTC inevitably grows and SIP diminishes, my life becomes gradually happier. :D Simon From nobody Mon Jun 8 08:13:05 2015 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 6CC161B2E8D for ; Mon, 8 Jun 2015 08:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 1YhEmdZ1U4q9 for ; Mon, 8 Jun 2015 08:13:01 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9C1B2EC3 for ; Mon, 8 Jun 2015 08:09:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D55077C0A46; Mon, 8 Jun 2015 17:09:11 +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 iGp4mF8b82pC; Mon, 8 Jun 2015 17:09:10 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:f4ab:e7e9:ac4b:ad3e] (unknown [IPv6:2001:470:de0a:27:f4ab:e7e9:ac4b:ad3e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6D12C7C0A45; Mon, 8 Jun 2015 17:09:10 +0200 (CEST) Message-ID: <5575B013.3030701@alvestrand.no> Date: Mon, 08 Jun 2015 17:09:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , Simon Perreault , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> <5575A364.7060900@jive.com> <5575A9F9.5030504@ericsson.com> In-Reply-To: <5575A9F9.5030504@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 15:13:03 -0000 On 06/08/2015 04:43 PM, Magnus Westerlund wrote: > Simon Perreault skrev den 2015-06-08 16:15: >> Le 2015-06-08 03:36, Magnus Westerlund a écrit : >>> Harald Alvestrand skrev den 2015-06-08 11:19: >>>> Den 08. juni 2015 10:48, skrev Magnus Westerlund: >>> >>>>> However, this can't work as RFC 7160 says in Section 4.1: >>>>> >>>>> An RTP Sender with RTCP turned on MUST use a different SSRC >>>>> for each >>>>> different clock rate. An RTCP BYE MUST be sent and a new >>>>> SSRC MUST >>>>> be used if the clock rate switches back to a value already >>>>> seen in >>>>> the RTP stream. >>>>> >>>>> Note the second sentence. One would still have to do a new round of >>>>> signalling to prime a new SSRC for the previous rate after having >>>>> switched to be able to switch back to that Payload Type. >>>> >>>> Hm. I missed that when reviewing the clock-rate doc. >>>> So that means one uses up an SSRC for every clock rate switch. That >>>> seems silly; is it possible that this should be considered an erratum >>>> for RFC 7160? >>> >>> No, it is highly intentional as I remember the discussion. >> >> Can you please explain, for those of us with short memories? :) > > I went and checked this. This formulation has been present since the > first versions, and no one has questioned this RFC 2119 worded > statement. Therefore I consider there to be consensus behind it and > being intentional. > > The motivation I see for this statement is the following. First of all > I think people have been against considering having stand bye SSRCs > that are really likely to never be used. I think DTMF is one of these > exceptions. Having stand by SSRC also have an overhead cost, primarily > in the result of the number of SSRCs present in the session and their > consumption of their share of the RTCP bandwidth resources. We also > have the issue of correctly associating the SSRC to a media source, > now that there are more than one. > > Based on that, (with the assumption that you do PT switching rarely) > the lower cost is to drop the SSRC after its usage. From that follows > that one stop using it, and therefore sends BYE, then you really > should not revive a dead SSRC. Thus, need to create a new one. Simply > codifying this expectation in the RFC. This has another implication: When doing PT switching for comfort noise, you MUST have a CN with the same clock rate as your normal audio codec. CN is exactly the type of PT-switching that, if it occurs at all, occurs very frequently. From nobody Mon Jun 8 08:16:38 2015 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 2A5FD1B2ED9 for ; Mon, 8 Jun 2015 08:16:37 -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, J_CHICKENPOX_14=0.6, 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 tyNk0ngD3fPj for ; Mon, 8 Jun 2015 08:16:36 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B691B2F19 for ; Mon, 8 Jun 2015 08:15:07 -0700 (PDT) Received: by obbgp2 with SMTP id gp2so78216550obb.2 for ; Mon, 08 Jun 2015 08:15: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HHa3GBlVNj3JS2SZm0rTXTTbfQK91+1vrFUA1pEkF/g=; b=Ub2zE56FwyLHfL1YDFxL6Orr34ACEs8Fsd4qrSE6tbSm3mfMURyT4BFwt5x3csL2JR /LjZwG6+ojOYk9h8wTRnFoE3wbVYmR56pBhR+s500+e0iHMptGoCjvQpz7gf3ABcWEDS ZSYmT56bx/khiFb6pu+rYyGdYiQjbTFHneGfEbSpNDNwOKvoZVJ2hIhCIf/P1dQP87xr nS2jYpkmsyqi6A/ioA9ESwQVgVhujVE164swC/OpwZKanvj81k5NER2WF1UT/eCmCtxs /HGI2tUdMraMU0TflNtdWpMwXrXU0hFmgbd6JikLEJnNFBctb+Q6pSKCdKwCiFFxWOrs Kgfg== X-Gm-Message-State: ALoCoQkG+Qf4AgwkiwObd6R5OUQK2w67Ej8D8GMPV2H5/oOFVAyP3GyS76Zh3HaZr+GM6DkIIWr3 X-Received: by 10.182.87.36 with SMTP id u4mr14948951obz.50.1433776507111; Mon, 08 Jun 2015 08:15:07 -0700 (PDT) Received: from jivecommunications.com ([199.87.120.129]) by mx.google.com with ESMTPSA id yr6sm1936262obc.23.2015.06.08.08.15.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2015 08:15:06 -0700 (PDT) Message-ID: <5575B178.1040309@jive.com> Date: Mon, 08 Jun 2015 09:15:04 -0600 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Harald Alvestrand , Magnus Westerlund , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> <5575A364.7060900@jive.com> <5575A9F9.5030504@ericsson.com> <5575B013.3030701@alvestrand.no> In-Reply-To: <5575B013.3030701@alvestrand.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 15:16:37 -0000 Le 2015-06-08 09:09, Harald Alvestrand a écrit : > This has another implication: > > When doing PT switching for comfort noise, you MUST have a CN with the > same clock rate as your normal audio codec. > > CN is exactly the type of PT-switching that, if it occurs at all, occurs > very frequently. I'm not following. We're discussing generating a new SSRC on clock rate-switching, not on PT-switching. For the CN example, you would typically include in your SDP one CN payload type per possible clock type so that you can switch payload types without switching the clock rate. Simon From nobody Mon Jun 8 08:17:58 2015 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 288901B2E90 for ; Mon, 8 Jun 2015 08:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 WglqoqAGDaC5 for ; Mon, 8 Jun 2015 08:17:56 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id ED7391B2E9A for ; Mon, 8 Jun 2015 08:17:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 288817C0A46; Mon, 8 Jun 2015 17:17: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 YRRkUmf9bo2U; Mon, 8 Jun 2015 17:17:40 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:fd19:c332:d33e:eb48] (unknown [IPv6:2001:470:de0a:27:fd19:c332:d33e:eb48]) by mork.alvestrand.no (Postfix) with ESMTPSA id 81F2F7C0A45; Mon, 8 Jun 2015 17:17:40 +0200 (CEST) Message-ID: <5575B212.3070004@alvestrand.no> Date: Mon, 08 Jun 2015 17:17:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Perreault , Magnus Westerlund , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> <5575A364.7060900@jive.com> <5575A9F9.5030504@ericsson.com> <5575B013.3030701@alvestrand.no> <5575B178.1040309@jive.com> In-Reply-To: <5575B178.1040309@jive.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 08 Jun 2015 15:17:57 -0000 Den 08. juni 2015 17:15, skrev Simon Perreault: > Le 2015-06-08 09:09, Harald Alvestrand a écrit : >> This has another implication: >> >> When doing PT switching for comfort noise, you MUST have a CN with the >> same clock rate as your normal audio codec. >> >> CN is exactly the type of PT-switching that, if it occurs at all, occurs >> very frequently. > > I'm not following. We're discussing generating a new SSRC on clock > rate-switching, not on PT-switching. For the CN example, you would > typically include in your SDP one CN payload type per possible clock > type so that you can switch payload types without switching the clock rate. Yep. It's only because I've seen SDP trying to match CN/8000 with OPUS/48000 that I'm mentioning it - it's obvious, but only after it's bitten you. From nobody Mon Jun 8 19:49:10 2015 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 840C71A8822; Mon, 8 Jun 2015 19:49: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 f9KRltNr-pPq; Mon, 8 Jun 2015 19:49:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 662791A212D; Mon, 8 Jun 2015 19:49:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609024907.7027.84578.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 19:49:07 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-14.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: Tue, 09 Jun 2015 02:49:08 -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-14.txt Pages : 10 Date : 2015-06-08 Abstract: To prevent WebRTC applications, such as browsers, from launching attacks by sending media to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. 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: https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-14 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 Jun 8 19:57:57 2015 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 6CF9B1A8A1E for ; Mon, 8 Jun 2015 19:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 y09x-FIXhsw1 for ; Mon, 8 Jun 2015 19:57:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD00F1A8A0E for ; Mon, 8 Jun 2015 19:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2186; q=dns/txt; s=iport; t=1433818674; x=1435028274; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=2cpU+GhnmPHV9w9bITFrV/HAmv9J0fHuu1oNBByLzZI=; b=gOOLHewpXPgFinUUZa7P3YP70H75rEYHRmMMOKxSv+RR1Nj1aOmX/Vua 8f+Vn2TnKEN2LWpDel/59caawt5Z+ttQKYKfX9+yrCG4g2MhwDWvdVLdr +TUKedAtxj/RtZPz+lZXYbWCFWzkebO5WzFzeBFysM8P+RLKuMO3cxvTH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeBADSVXZV/4kNJK1cgxBUXga9amYJgTUiDIUtSgKBMTgUAQEBAQEBAX8LhCIBAQEBAwEBATc0CwwGAQgRBAEBCxQJLgsUCQkBBA4FCIgmDc5QAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhFUxDYMRgRYFkzyEQogeQIM7kjokg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,577,1427760000"; d="scan'208";a="5619512" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP; 09 Jun 2015 02:57:27 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t592vQL1007947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jun 2015 02:57:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 8 Jun 2015 21:57:26 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-14.txt Thread-Index: AdCiYAG8eWkh4DUwS6e4lqV/0m0ymQ== Date: Tue, 9 Jun 2015 02:57:26 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47866900@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.79.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Black, David \(david.black@emc.com\)" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-14.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, 09 Jun 2015 02:57:56 -0000 This revision addresses comments from David and Bernard. -Tiru > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, June 09, 2015 8:19 AM > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-14= .txt >=20 >=20 > 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-browsers > Working Group of the IETF. >=20 > 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-14.txt > Pages : 10 > Date : 2015-06-08 >=20 > Abstract: > To prevent WebRTC applications, such as browsers, from launching > attacks by sending media to unwilling victims, periodic consent to > send needs to be obtained from remote endpoints. >=20 > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness= / >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshn= ess-14 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jun 8 20:02:49 2015 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 07DCD1A92B2; Mon, 8 Jun 2015 20:02:49 -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 KElpOpAHmq7a; Mon, 8 Jun 2015 20:02:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C04ED1A9028; Mon, 8 Jun 2015 20:02:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609030246.22841.25559.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 20:02:46 -0700 Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-rtp-usage@ietf.org Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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: Tue, 09 Jun 2015 03:02:49 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-rtp-usage-24: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found this in general to be informative and well written, given the rather large scope of information. I do have a few comments/questions: Substantive: -- 4.9: The discussion of RTCPeerConnection in this section seems to need a normative reference to [W3C.WD-webrtc-20130910] (or a local explanation, if there are issues normatively referencing that doc.) -- 5.1: This section seems to need a normative reference to topologies-update. There is normative language here to the effect of “Don’t do these things†where it seems like one needs to read that doc to understand what the “things†mean. -- 7.1, first paragraph: "applications MUST also implement congestion control to allow them to adapt to changes in network capacity." Is that the aformentioned not-yet-standardized congestion control algorithm, or something else? -- 11, 2nd paragraph from end: It seems like the msid reference should be normative. -- 12.1.3: seems like a mention of draft-ietf-dart-dscp-rtp might be in order now. IIRC, when I did a gen-art review on a much older version, the thought was that if draft-ietf-dart-dscp-rtp was far enough along when it was time to publish this draft, it would make sense to add a mention. It's in the RFC editor queue now, in MISSREF on a dependency that I think this draft shares. -- 13: 3rd paragraph: Isn't that security solution MTU as well as MTI? If so, it might be worth mentioning it here. Editorial: -- 11, paragraph 3: "...can be feeding multiple..." Consider "... can feed multiple ..." paragraph 4: "This is motivating the discussion..." consider "This motivates the discussion..." (or possibly "motivated") paragraph 5: "... each of different MediaStreamTracks ..." missing "the" paragraph 6: "... relay/forward ..." consider "... relay or forward ..." -- 12.1, last sentence "... ways in which WebRTC Endpoints can configure and use RTP sessions is outlined." s/is/are From nobody Mon Jun 8 20:04:12 2015 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 3670A1ACD63; Mon, 8 Jun 2015 20:04:10 -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 zAvrUpzctler; Mon, 8 Jun 2015 20:04:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DE61A9040; Mon, 8 Jun 2015 20:04:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609030408.24606.8383.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 20:04:08 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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: Tue, 09 Jun 2015 03:04:10 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-rtp-usage-24: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Edit: Meta-Comment: The notify field for this draft seems sparse. I found this in general to be informative and well written, given the rather large scope of information. I do have a few comments/questions: Substantive: -- 4.9: The discussion of RTCPeerConnection in this section seems to need a normative reference to [W3C.WD-webrtc-20130910] (or a local explanation, if there are issues normatively referencing that doc.) -- 5.1: This section seems to need a normative reference to topologies-update. There is normative language here to the effect of “Don’t do these things†where it seems like one needs to read that doc to understand what the “things†mean. -- 7.1, first paragraph: "applications MUST also implement congestion control to allow them to adapt to changes in network capacity." Is that the aformentioned not-yet-standardized congestion control algorithm, or something else? -- 11, 2nd paragraph from end: It seems like the msid reference should be normative. -- 12.1.3: seems like a mention of draft-ietf-dart-dscp-rtp might be in order now. IIRC, when I did a gen-art review on a much older version, the thought was that if draft-ietf-dart-dscp-rtp was far enough along when it was time to publish this draft, it would make sense to add a mention. It's in the RFC editor queue now, in MISSREF on a dependency that I think this draft shares. -- 13: 3rd paragraph: Isn't that security solution MTU as well as MTI? If so, it might be worth mentioning it here. Editorial: -- 11, paragraph 3: "...can be feeding multiple..." Consider "... can feed multiple ..." paragraph 4: "This is motivating the discussion..." consider "This motivates the discussion..." (or possibly "motivated") paragraph 5: "... each of different MediaStreamTracks ..." missing "the" paragraph 6: "... relay/forward ..." consider "... relay or forward ..." -- 12.1, last sentence "... ways in which WebRTC Endpoints can configure and use RTP sessions is outlined." s/is/are From nobody Tue Jun 9 01:20:11 2015 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 7D8C21B2A66 for ; Tue, 9 Jun 2015 01:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 AejjNCRKE4dE for ; Tue, 9 Jun 2015 01:20:08 -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 09D6C1B2A67 for ; Tue, 9 Jun 2015 01:20:07 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-0c-5576a1b69645 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id ED.C8.28096.6B1A6755; Tue, 9 Jun 2015 10:20:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.210.2; Tue, 9 Jun 2015 10:20:05 +0200 Message-ID: <5576A1B5.1040508@ericsson.com> Date: Tue, 9 Jun 2015 10:20:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Harald Alvestrand , Simon Perreault , Roman Shpount References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> <5575A364.7060900@jive.com> <5575A9F9.5030504@ericsson.com> <5575B013.3030701@alvestrand.no> <5575B178.1040309@jive.com> <5575B212.3070004@alvestrand.no> In-Reply-To: <5575B212.3070004@alvestrand.no> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvre62hWWhBp2XeS2O9XWxWcy4MJXZ Yu2/dnaL61dCHVg8rky4wuqxZMlPJo9/c54ye9yaUhDAEsVlk5Kak1mWWqRvl8CVMe36d/aC GfwVx7o+MDYwTuPpYuTkkBAwkXi3/C4ThC0mceHeerYuRi4OIYGjjBKdV28wQzjLGCXOXP0E VsUroC3x6cEqMJtFQEVi9v3zjCA2m4CFxM0fjWwgtqhAlMTUx+tYIOoFJU7OfAJmiwhUSMze /oEdxGYWUJe4s/gcmC0s4CvxetFmVohlPcwS108eB1vAKaArsfz+cWaIBguJmfMhljELyEs0 b50NFhcCOqihqYN1AqPgLCT7ZiFpmYWkZQEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2M wLA+uOW31Q7Gg88dDzEKcDAq8fAu8CgLFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxhC/Oe5pPMpz7wTN+X1Ea7W1wiLead7TXtY/1tu2RfifXCs3e7XP hfVhzbZzO54sUlNr4pol8lSuY62b5IuI+rx7zz6+fWjJZGWXFFc5871vEvOO3REBnVvPM6Vq vluv9CNYQv7QDCMH8zkq8tP7fs88K2cqmr6WK5ZtS8djLuH3fPK9nMGvlFiKMxINtZiLihMB N0AxM0wCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 09 Jun 2015 08:20:10 -0000 Harald Alvestrand skrev den 2015-06-08 17:17: > Den 08. juni 2015 17:15, skrev Simon Perreault: >> Le 2015-06-08 09:09, Harald Alvestrand a écrit : >>> This has another implication: >>> >>> When doing PT switching for comfort noise, you MUST have a CN with the >>> same clock rate as your normal audio codec. >>> >>> CN is exactly the type of PT-switching that, if it occurs at all, occurs >>> very frequently. >> >> I'm not following. We're discussing generating a new SSRC on clock >> rate-switching, not on PT-switching. For the CN example, you would >> typically include in your SDP one CN payload type per possible clock >> type so that you can switch payload types without switching the clock rate. > > Yep. It's only because I've seen SDP trying to match CN/8000 with > OPUS/48000 that I'm mentioning it - it's obvious, but only after it's > bitten you. > Yes, this is likely one of these things that the ones that considered the issues see as obvious, but is in fact not until you actually tried it and therefore could have benefited from a note about the need for having one PT configuration per timestamp rate used by the codecs that may use the CN. As the RTP usage is in IESG review, I am hesitant to add such discussion into the RTP usage document. As it is really a configuration issue, I think it can be discussed in JSEP, but the audio draft might be an even better fit adding to the CN text. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 9 01:51:22 2015 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 125B71B2AAE; Tue, 9 Jun 2015 01:51:18 -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 9vFIFVd1E1Qw; Tue, 9 Jun 2015 01:51:16 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C901B2AAC; Tue, 9 Jun 2015 01:51:15 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-4d-5576a900e772 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.BE.04015.009A6755; Tue, 9 Jun 2015 10:51:12 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.210.2; Tue, 9 Jun 2015 10:51:12 +0200 Message-ID: <5576A8FE.2060001@ericsson.com> Date: Tue, 9 Jun 2015 10:51:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell , The IESG References: <20150609030408.24606.8383.idtracker@ietfa.amsl.com> In-Reply-To: <20150609030408.24606.8383.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+JvrS7DyrJQg3eTDCzmd55mt5jxZyKz xdp/7ewOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8a7zZeZC2ZoVky8c4GxgbFHsYuR k0NCwESiacJfNghbTOLCvfVANheHkMBRRonupefYIZxljBJn350Bq+IV0Ja4tWczUxcjBweL gIrE9DfeIGE2AQuJmz8awUpEBaIkpj5exwJRLihxcuYTMFtEwEZi+cGXYDXMAqISrx5OYQax hQViJKZcXsoOYgsJOEg8fzGNFcTmFHCU2L9rFlS9hcTM+ecZIWx5ieats5kh6rUlGpo6WCcw Cs5Csm4WkpZZSFoWMDKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAgM3INbfhvsYHz53PEQ owAHoxIP7wKPslAh1sSy4srcQ4zSHCxK4rwzNueFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amA0+S0udbwrNIer9czRnf5lgdt2iVx//Opo9K9frkyO92PmPN/anCPu3fHTv37qVQXnM6cU Gu7G6Z3mf6N8PUEyj8ms4/ZWz3T7llNynz83VD54/936ZtNau7Adj5YkeHH+ibHdmqnWsP7D M4EF88p/L6nyn3IoiydZp+IXD/d5rjC7VCetpbeUWIozEg21mIuKEwHk9d/hPQIAAA== Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 09 Jun 2015 08:51:18 -0000 Hi Ben, Thanks for the review, some inline comments. Will address these after Thursday when we know the rest of IESGs views. Ben Campbell skrev den 2015-06-09 05:04: > Ben Campbell has entered the following ballot position for > draft-ietf-rtcweb-rtp-usage-24: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Edit: Meta-Comment: The notify field for this draft seems sparse. > > > I found this in general to be informative and well written, given the > rather large scope of information. I do have a few comments/questions: > > Substantive: > > -- 4.9: The discussion of RTCPeerConnection in this section seems to need > a normative reference to [W3C.WD-webrtc-20130910] (or a local > explanation, if there are issues normatively referencing that doc.) Do I understand that you want a reference in the second paragraph at the mentioning of RTCPeerConnection? As it is reference in the previous paragraph, I assumed that people would not be confused on what we talk about. I guess the second issue is that the reference is classified as informative and should be normative. Changing the classification is simple, it will however create a need to ensure that the publication of this document is held until the W3C document reaches Recommendation status if I understand the rules and recommendations correctly. > > -- 5.1: This section seems to need a normative reference to > topologies-update. There is normative language here to the effect of > “Don’t do these things†where it seems like one needs to read that doc to > understand what the “things†mean. I do understand the reasoning behind your comment. I personally do not agree the need for using normative references for documents that import a term for a concept. We already had this discussion around the topologies document's status. I have no issue with reclassifying the reference, but I do note that we will have to re-run the IETF last call as this will now be a down-ref. > > -- 7.1, first paragraph: "applications MUST also implement congestion > control to > allow them to adapt to changes in network capacity." > > Is that the aformentioned not-yet-standardized congestion control > algorithm, or something else? As we have no standardized congestion control yet, we can't point to anything. But, an implementation must implement something, even if completely proprietary. > > -- 11, 2nd paragraph from end: > > It seems like the msid reference should be normative. Our intention was to keep this informative. Therefore the chosen style of writing that sentence. The actual normative inclusion of MSID into the WebRTC solution is done by JSEP. > > -- 12.1.3: > > seems like a mention of draft-ietf-dart-dscp-rtp might be in order now. > IIRC, when I did a gen-art review on a much older version, the thought > was that if draft-ietf-dart-dscp-rtp was far enough along when it was > time to publish this draft, it would make sense to add a mention. It's in > the RFC editor queue now, in MISSREF on a dependency that I think this > draft shares. The TSVWG document referenced do normatively reference the DART document. But, we could include the DART document in the same sentence as the TSVWG document. > > -- 13: 3rd paragraph: > > Isn't that security solution MTU as well as MTI? If so, it might be worth > mentioning it here. You mean Mandatory to Use, not Maximum Transmission Unit, don't you? Yes, it is mandatory to use, we can make that clear. Will deal with the editorials > > Editorial: > > -- 11, paragraph 3: "...can be feeding multiple..." > > Consider "... can feed multiple ..." > > paragraph 4: "This is motivating the discussion..." > > consider "This motivates the discussion..." (or possibly "motivated") > > paragraph 5: "... each of different MediaStreamTracks ..." > > missing "the" > > paragraph 6: "... relay/forward ..." > > consider "... relay or forward ..." > > -- 12.1, last sentence "... ways in which WebRTC Endpoints can configure > and use > RTP sessions is outlined." > > s/is/are > > Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 9 07:32:25 2015 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 97DBA1B2CFE; Tue, 9 Jun 2015 07:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 nKIi1oMw6z1Q; Tue, 9 Jun 2015 07:32:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA811B2CFB; Tue, 9 Jun 2015 07:32:21 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t59EW6Lw025877 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 9 Jun 2015 09:32:16 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Magnus Westerlund" Date: Tue, 09 Jun 2015 09:32:06 -0500 Message-ID: In-Reply-To: <5576A8FE.2060001@ericsson.com> References: <20150609030408.24606.8383.idtracker@ietfa.amsl.com> <5576A8FE.2060001@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: rtcweb@ietf.org, The IESG Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 09 Jun 2015 14:32:23 -0000 On 9 Jun 2015, at 3:51, Magnus Westerlund wrote: > Hi Ben, > > Thanks for the review, some inline comments. Will address these after > Thursday when we know the rest of IESGs views. > Thanks for the response. Comments inline. [...] >> Substantive: >> >> -- 4.9: The discussion of RTCPeerConnection in this section seems to >> need >> a normative reference to [W3C.WD-webrtc-20130910] (or a local >> explanation, if there are issues normatively referencing that doc.) > > Do I understand that you want a reference in the second paragraph at > the mentioning of RTCPeerConnection? As it is reference in the > previous paragraph, I assumed that people would not be confused on > what we talk about. > I'm okay with the reference where it is--my comment was more about normativity (see comment to next paragraph) > I guess the second issue is that the reference is classified as > informative and should be normative. Changing the classification is > simple, it will however create a need to ensure that the publication > of this document is held until the W3C document reaches Recommendation > status if I understand the rules and recommendations correctly. > I think the reader will at least need a high level understanding of the meaning of RTCPeerConnection to implement the normative requirements in this section. If the W3C doc is not going to be sufficiently mature in the immediate future, it might be good enough to put a couple of sentences in this doc about the meaning of RTCPeerConnection. (The full interface spec is probably not needed.) >> >> -- 5.1: This section seems to need a normative reference to >> topologies-update. There is normative language here to the effect of >> “Don’t do these things†where it seems like one needs to read >> that doc to >> understand what the “things†mean. > > I do understand the reasoning behind your comment. I personally do not > agree the need for using normative references for documents that > import a term for a concept. We already had this discussion around the > topologies document's status. (I'm not sure if you meant "do _not_ understand", but I expected you to disagree :-) ) I realize there is not universal agreement on whether BCP 97 applies to terminology. I think it can in some cases. But in this case, I think we are going beyond just terminology. The topology doc describes structure and behavior associated with each topology. I assume it is informational because it is descriptive rather than prescriptive. > > I have no issue with reclassifying the reference, but I do note that > we will have to re-run the IETF last call as this will now be a > down-ref. Yes, that is an issue. You will note I made this a comment, not a discuss :-) I will leave it up to you guys and Alissa to decide if this is needed badly enough to go through another LC. (For the record, there's some work going on to update 97 to allow more discretion around this sort of thing without triggering pointlessly repeated last calls.) > >> >> -- 7.1, first paragraph: "applications MUST also implement congestion >> control to >> allow them to adapt to changes in network capacity." >> >> Is that the aformentioned not-yet-standardized congestion control >> algorithm, or something else? > > As we have no standardized congestion control yet, we can't point to > anything. But, an implementation must implement something, even if > completely proprietary. It would be helpful to either clarify the "even if proprietary" part, or perhaps move this sentence closer to the bit about no standardized mechanism. (But this is not a show stopper.) > > >> >> -- 11, 2nd paragraph from end: >> >> It seems like the msid reference should be normative. > > Our intention was to keep this informative. Therefore the chosen style > of writing that sentence. The actual normative inclusion of MSID into > the WebRTC solution is done by JSEP. Okay. It might be helpful, but not required, to state this sentence in the form of "[jsep] specifies that..." > >> >> -- 12.1.3: >> >> seems like a mention of draft-ietf-dart-dscp-rtp might be in order >> now. >> IIRC, when I did a gen-art review on a much older version, the >> thought >> was that if draft-ietf-dart-dscp-rtp was far enough along when it was >> time to publish this draft, it would make sense to add a mention. >> It's in >> the RFC editor queue now, in MISSREF on a dependency that I think >> this >> draft shares. > > The TSVWG document referenced do normatively reference the DART > document. But, we could include the DART document in the same sentence > as the TSVWG document. I'm okay leaving it to the deeper conversation in the TSVWG doc. I mainly mentioned it because I had thought the intent was to add the mention here if the dart draft was sufficiently far along in the process when this draft was submitted. > >> >> -- 13: 3rd paragraph: >> >> Isn't that security solution MTU as well as MTI? If so, it might be >> worth >> mentioning it here. > > You mean Mandatory to Use, not Maximum Transmission Unit, don't you? > Yes, it is mandatory to use, we can make that clear. > Yes, mandatory to use. :-) [...] From nobody Tue Jun 9 10:28:26 2015 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 3FC0F1B2D99 for ; Tue, 9 Jun 2015 10:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 KdAZbITdOVyR for ; Tue, 9 Jun 2015 10:28:21 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7FC1B2D91 for ; Tue, 9 Jun 2015 10:28:21 -0700 (PDT) Received: by wifx6 with SMTP id x6so23893842wif.0 for ; Tue, 09 Jun 2015 10:28:20 -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=oX5s11SDGm402rQbU3yOZFkK1XqZL21TH/Wexd5G4VM=; b=WjlQC27z7hY1+nKYYAASw2h2HuYThRjLuyV8EJqec3G5YmzrRlJIu0OVMtQTyEDeR5 Py8o1Nu3pLE4oeAJeN9Gm5ONHYcCYoXqFy+sxkIlpZlLoZvaW2qu+C9L9IRlKLApREoM ijt9FVksG5oI7DV46cQ6FWQ6W7E/DEYgNhqnskJpI/hwVNH+vlPxrUsooArF8XknbQ39 fMlnCe1jwCOhytYZwJK9mlc7CXxGgQ0tUt8r1dOLMEU0WiPom2ojFIa+tVHKaDDDjMoA gtTDuVxRNGuRllfwRnVXLKPeRNQ3G4Jd6iH2mLvsH0uvA8pCa1K/SqQK1BZFIkbkKiqX LceA== MIME-Version: 1.0 X-Received: by 10.180.9.111 with SMTP id y15mr34159681wia.18.1433870899985; Tue, 09 Jun 2015 10:28:19 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Tue, 9 Jun 2015 10:28:19 -0700 (PDT) Date: Tue, 9 Jun 2015 10:28:19 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a11c24888a5c32f05181915aa Archived-At: Subject: [rtcweb] Note taker and Issue-updater for Virtual Interim 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, 09 Jun 2015 17:28:23 -0000 --001a11c24888a5c32f05181915aa Content-Type: text/plain; charset=UTF-8 Howdy, For the upcoming virtual Interim, we expect to spend a lot of the time working through JSEP issues. To make sure we get the most of our time, the chairs would like to solicit volunteers for two roles now: 1) Note taker--create standard IETF notes for the minutes 2) Github Issue updater For the portion of the meeting in which we're reviewing issues that have github references (https://github.com/rtcweb-wg/jsep), the "issue updater" will record any results there, as an aid to the editing team. You will need a free github account to update the issues. We'd reall appreciate volunteers for this now, thanks, Ted, Cullen, Sean --001a11c24888a5c32f05181915aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

For the upcoming v= irtual Interim, we expect to spend a lot of the time working through JSEP i= ssues.=C2=A0 To make sure we get the most of our time, the chairs would lik= e to solicit volunteers for two roles now:

1) Note t= aker--create standard IETF notes for the minutes
2) Gith= ub Issue updater

For the portion of the meeting in w= hich we're reviewing issues that have github references (https://github.com/rtcweb-wg/jsep), the= "issue updater" will record any results there, as an aid to the = editing team.=C2=A0 You will need a free github account to update the issue= s.

We'd reall appreciate volunteers for this now= ,

thanks,

Ted, Cullen, Sean
--001a11c24888a5c32f05181915aa-- From nobody Tue Jun 9 10:54:26 2015 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 73B561AC3C8; Tue, 9 Jun 2015 10:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 tSXi1HEZKoms; Tue, 9 Jun 2015 10:54:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF011AC399; Tue, 9 Jun 2015 10:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609175421.20827.64467.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 10:54:21 -0700 Archived-At: Cc: draft-ietf-rtcweb-video.ad@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-video@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-video.shepherd@ietf.org Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-video-05: (with COMMENT) 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: Tue, 09 Jun 2015 17:54:22 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-rtcweb-video-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for producing this document. I'm only mildly familiar with this level of detail, and the document was clear, with pointers when I needed them. I'm honored to ballot Yes. I did have one question. In this text: Implementations MAY send and act upon "User data registered by Rec. ITU-T T.35" and "User data unregistered" messages. Even if they do not act on them, implementations MUST be prepared to receive such messages without any ill effects. Is that a usual thing to say? Perhaps it is, but I thought that might be understood. From nobody Tue Jun 9 12:09:54 2015 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 C3F0B1B2EDD; Tue, 9 Jun 2015 12:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BtPOAFXz23IV; Tue, 9 Jun 2015 12:09:50 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 0EC1C1A0140; Tue, 9 Jun 2015 12:09:49 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t59J9hK9016577 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jun 2015 15:09:45 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t59J9hK9016577 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1433876985; bh=ZrGTTsmI0U+c29QuX2a4Ct5n3ds=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ex2XKeOejLbawJp8qYPJ6rgDdD6jcVhLTXAiLk9zIY1oPbEWOzL2y4N4pwlFIvQYn tZJHPElTpe+o0am09PKNKxj1wooT2ebaLloT456SJowRNf6HUYVX7VxZNg2VCNo/NZ FaxUPIvks5YkquC6EO9HTTQoePKFAGBxFqndHX5w= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com t59J9hK9016577 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 9 Jun 2015 15:09:24 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t59J9OwM016196 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jun 2015 15:09:24 -0400 Received: from MXHUB101.corp.emc.com (10.253.50.15) by mxhub18.corp.emc.com (10.254.93.47) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 9 Jun 2015 15:09:24 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.123]) by MXHUB101.corp.emc.com ([::1]) with mapi id 14.03.0224.002; Tue, 9 Jun 2015 15:09:24 -0400 From: "Black, David" To: "muthu.arul@gmail.com" , "dwing@cisco.com" , "rmohanr@cisco.com" , "tireddy@cisco.com" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-14 Thread-Index: AdCi58lPi5K+gAtNQriBoM1GKpG0Qg== Date: Tue, 9 Jun 2015 19:09:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public, Resumes Archived-At: Cc: "Black, David" , "rtcweb@ietf.org" , "ietf@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-14 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, 09 Jun 2015 19:09:53 -0000 As a result of lengthy ;-) discussion, the -14 version of this draft addres= ses all of the concerns in the OPS-Dir review of the -13 version, as well a= s the subsequent concern about whether this draft is an update to RFC 5245.= That latter update concern has been resolved with a conclusion that this = draft does not update RFC 5245 - the keepalive material in this draft has b= een revised to explain how consent checks effectively serve as keepalives, = removing any need to send separate keepalives in a fashion that's compatibl= e with RFC 5245. I noticed a minor editorial nit: - Section 1, top of p.3 Consent is obtained only by full ICE implementations. An ICE-lite agent (as defined in Section 2.7 of [RFC5245]) does not generate connectivity checks or run the ICE state machine. An ICE-lite agent does not generate consent checks, it will only respond to any checks that it receives. I'd change the start of latter sentence to better connect it to the=20 previous sentence: "An ICE-lite agent" -> "Hence, an ICE-lite agent" also: "consent checks, it will" -> "consent checks and will" idnits 2.13.02 ran clean. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Thursday, May 14, 2015 7:21 PM > To: muthu.arul@gmail.com; dwing@cisco.com; rmohanr@cisco.com; > tireddy@cisco.com; martin.thomson@gmail.com; ops-dir@ietf.org > Cc: rtcweb@ietf.org; Black, David; ietf@ietf.org > Subject: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 >=20 > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written with the intent of improving the operational > aspects of the IETF drafts. Comments that are not addressed in last call > may be included in AD reviews during the IESG review. Document editors > and WG chairs should treat these comments just like any other last call > comments. >=20 > Document: draft-ietf-rtcweb-stun-consent-freshness-13 > Reviewer: David Black > Review Date: May 14, 2015 > IETF LC End Date: May 15, 2015 (on -11) >=20 > Summary: This draft is on the right track, but has open issues > described in the review. >=20 > This draft describes use of STUN to obtain ongoing consent to send in > a fashion that is secured by the use of cryptographically strong nonces > as STUN transaction IDs. >=20 > -- Major issues -- >=20 > [1] The draft seems to be missing discussion of applicability - what > environments and/or protocols is this mechanism intended for or applicabl= e > to? Is this generally applicable wherever ICE and STUN are used? I don'= t > see any RFCs listed as updated by this draft, so I'm guessing that this > is not intended to promulgate new requirements for all uses of ICE and > STUN, but this should be clarified. The shepherd writeup implies that > this draft is intended primarily for WebRTC. >=20 > [2] The security considerations appear to be incomplete. > There should be an explanation of why cryptographically strong STUN > transaction IDs are required (e.g., there are no cryptographically > strong IDs in the TCP consent mechanism noted on p.4), and there should > be a discussion of how and why replays of previous consent responses > are harmless (will be ignored by the recipient). The mechanism design > appears to be ok, but this rationale should be provided in terms of > attacks that are of concern and how they are prevented - a primary > intent appears to be to resisting off-path attacks. >=20 > -- Minor Issues -- >=20 > [3] In Section 1, please explain what ICE-lite is. A suitable reference > should suffice. >=20 > [4] In Section 4.1, please explain or provide a reference for what "paced= " > means in "paced STUN connectivity checks or responses." >=20 > -- Nits/Editorial Comments -- >=20 > The SRTP paragraph in Section 8 (Security Considerations) feels out of pl= ace > - this looks like design rationale material that would be better located = in > Section 3. >=20 > idnits 2.13.02 found an unused reference: >=20 > =3D=3D Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on line = 320, but > no explicit reference was found in the text >=20 > That reference is likely to be useful to address the absence of discussio= n of > applicability (major issue [1], above). >=20 > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >=20 > This mechanism is an incremental modification to the STUN and ICE protoco= ls, > and can be implemented by one party to a communication session; ordinary > response generation behavior (already required) reflects the cryptographi= cally > strong STUN transaction IDs on which the mechanism is based. As a result= , the > mechanism can be deployed at one end of a two-party communication session > without impact on the other party. This is implied by section 3 of the d= raft, > but would be useful to state explicitly. [A.1.1 - deployment] >=20 > The mechanism has been defined to limit the amount of added traffic and t= o > shut down unwanted traffic, plus contains a facility to desynchronize > independent users of this protocol. Some rationale should be added for > the choice of the 30 second timeout period. [A.1.5 - network impact] >=20 > There is an obvious fault condition, namely that consent is lost or revok= ed > causing immediate cessation of traffic. While the details depend on the > environment in which this mechanism is used, it'd be helpful to add a sen= tence > or two on reporting of the state of STUN consent-based connectivity and h= ow > that reporting should or may relate to reporting of the state of other fo= rms > of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned in this draft. > [A.1.8 - fault and threshold conditions] >=20 > This mechanism is a simple extension to existing protocols, and should fi= t > into existing configuration and management for those protocols. [A.1.9 - > configuration, A.2 - Management (in general)] >=20 > It might be useful to mention the utility of tracking frequency and durat= ion > of loss and re-establishment of consent-based connectivity, as such > information > has operational value. In particular, a discussion of how a server could > infer > loss of connectivity with a client that is using this mechanism might be > useful > to add, as the operational concerns may be more significant for servers a= nd > related networks than clients. [A.2.2 - management information, A.2.3 - f= ault > management]. >=20 > The primary operational impact of this protocol should be reduction in > unwanted > traffic, which is a benefit - the consent check traffic added by this pro= tocol > should not have significant impacts. The writeup indicates that implemen= ters > have reviewed the draft and implementations are in progress. [A.3 - > Documentation] >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From nobody Tue Jun 9 13:21:57 2015 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 743151B30BC; Tue, 9 Jun 2015 13:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] 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 mH8ZZDIrkAN4; Tue, 9 Jun 2015 13:21:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B911D1B30C0; Tue, 9 Jun 2015 13:21:54 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t59KLrea056593 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Jun 2015 15:21:53 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55774AE0.6060909@nostrum.com> Date: Tue, 09 Jun 2015 15:21:52 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Spencer Dawkins , The IESG References: <20150609175421.20827.64467.idtracker@ietfa.amsl.com> In-Reply-To: <20150609175421.20827.64467.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-rtcweb-video.ad@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-video@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-video.shepherd@ietf.org Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-video-05: (with COMMENT) 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, 09 Jun 2015 20:21:56 -0000 On 6/9/15 12:54, Spencer Dawkins wrote: > I did have one question. In this text: > > Implementations MAY send and act upon "User data registered by Rec. > ITU-T T.35" and "User data unregistered" messages. Even if they do > not act on them, implementations MUST be prepared to receive such > messages without any ill effects. > > Is that a usual thing to say? Perhaps it is, but I thought that might be > understood. > This text is the result of a specific recommendation from Stefan Wenger, who has far more familiarity with what H.264 implementors are likely to get wrong than I do. His suggestion (to the RTCWEB mailing list, November 24, 2014) was: > MAY: > User data T.35 registered, and user data unregistered > Especially the latter you see occasionally for proprietary extensions. > It's a good idea to advise implementers that a bitstream may contain that > kind of stuff, even if they don't act on it. Given Stefan's specific mention of this as a potential issue, I'm inclined to leave it in unless someone can provide a reasonable argument that it causes harm. /a From nobody Tue Jun 9 13:28:04 2015 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 5BFB01B30C8; Tue, 9 Jun 2015 13:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 AX6l5H58___4; Tue, 9 Jun 2015 13:28:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670B21B30C5; Tue, 9 Jun 2015 13:28:02 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t59KS0SD057059 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Jun 2015 15:28:01 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55774C50.4030709@nostrum.com> Date: Tue, 09 Jun 2015 15:28:00 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150608122843.32038.25147.idtracker@ietfa.amsl.com> In-Reply-To: <20150608122843.32038.25147.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-rtcweb-video.ad@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-video@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-video.shepherd@ietf.org Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-video-05: (with COMMENT) 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, 09 Jun 2015 20:28:03 -0000 On 6/8/15 07:28, Barry Leiba wrote: > I do wonder that the Abstract and Introduction are both short, and, yet, > give such different descriptions of the document as to make it look like > two different documents. Given how short they are, perhaps it really is > best to make them the same, no? > > Abstract: > This specification provides the requirements and considerations for > WebRTC applications to send and receive video across a network. It > specifies the video processing that is required, as well as video > codecs and their parameters. > > Introduction: > This > specification defines how the video is used and discusses special > considerations for processing the video. It also covers the video- > related algorithms WebRTC devices need to support. > I think the quoted sections say pretty much the same thing, but I'm not really attached to either formulation. I'll happily replace the cited "Introduction" text with the contents of the Abstract. /a From nobody Tue Jun 9 14:04:42 2015 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 CFD031A026C for ; Tue, 9 Jun 2015 14:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 KV6A6Fd9tdZG for ; Tue, 9 Jun 2015 14:04:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CD91A0127 for ; Tue, 9 Jun 2015 14:04:39 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t59L4aHR060126 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Jun 2015 16:04:36 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <557754E4.6010806@nostrum.com> Date: Tue, 09 Jun 2015 16:04:36 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alissa Cooper , rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-video-05 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, 09 Jun 2015 21:04:41 -0000 On 5/13/15 19:18, Alissa Cooper wrote: > Reading Section 7, it strikes me that a question may arise during IETF LC or IESG eval about whether there is any plan to write something similar to RFC 6562 for video. Has that been discussed? Not really. Magnus had concerns that 6562 wasn't an appropriate citation for video, so I shortened it to a brief description of the issue. I would be happy if a more rigorous treatment were written, but I'm not a likely candidate to author it. > s/what the other documents it references/what is in the other documents it references/ > > s/A complete discussion of the security/A complete discussion of the security considerations/ > > And in Section 10.1: > The URL given for H264 links to a seemingly blank page. > Thanks. Good catches, will be fixed in the final version. /a From nobody Tue Jun 9 14:34:08 2015 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 CCD151B30D9; Tue, 9 Jun 2015 13:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 I3bCdQRsPP-m; Tue, 9 Jun 2015 13:36:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9F1B30C4; Tue, 9 Jun 2015 13:36:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609203611.18304.3157.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 13:36:11 -0700 Archived-At: X-Mailman-Approved-At: Tue, 09 Jun 2015 14:34:04 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] Kathleen Moriarty's No Objection on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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: Tue, 09 Jun 2015 20:36:12 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-rtcweb-rtp-usage-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for your work on this well-written draft. The SecDir review picked up on a number of nits that should be corrected, tow in the Security considerations section in particular. The full review can be found here: http://www.ietf.org/mail-archive/web/secdir/current/msg05759.html And the specific fixes for the security considerations text is as follows: The security considerations section was comprehensive and security impacts were taken into account throughout this draft. I have two small NIT’s about the security section that I would like improved, and I feel these are rather small: First, in the paragraph in the security section that starts “RTCP packets convey a Canonical Name…†the authors state that the CNAME generation algorithm in described in section 4.9 – it isn’t, section 4.9 references RFC7022 for the generation algorithm. Second, the last paragraph on page 39, starting with “Providing source authentication in multi-party…†ends the page with a large security warning. Please include a reference in that paragraph in the security considerations and possibly to the appropriate draft/RFC which discusses that issue in some more depth. From nobody Tue Jun 9 14:35:48 2015 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 290DA1A1BDF for ; Tue, 9 Jun 2015 14:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, RCVD_IN_SORBS_WEB=0.77, 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 ZiTk0CY0nqeX for ; Tue, 9 Jun 2015 14:35:46 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43941A1BC3 for ; Tue, 9 Jun 2015 14:35:45 -0700 (PDT) Received: by yken206 with SMTP id n206so14177896yke.2 for ; Tue, 09 Jun 2015 14:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7NirFmp69hUbX2b+YPWhUamiw74Uf0SlTj+BcGbt6gk=; b=mW6J3T3RbyYsaiIeH5DjxsO1sZzsBZtVfKiWVVJ9HmvrmGK7gfDX8Qlr7aEU03pAAG kQ/ODq7zoqKMbPapoJ7mXr8f1RlhHHJ9+FKtA6kGimsVNxtwYdHCQIIbi0Y6wtIz3HJX BLDMoJGEjc4BfsWBnQHEEL7yCQO1oMX1NXLiJn8+WNThmWUaXN1C0Ir3VFhBi4OzwEhx 4GJN/OmCyvT5VVFigaL3+c8m6LqBwTZ02F1LiptmXur77nmNSZu9HCnwetq4dzO0GccJ rYSqav9w4vNvL4OkW8XDxwPGno+LgUyjawcC/4UEObqWAh0XIHwsR7aWUBzYwgv+n9Gp GJXA== X-Received: by 10.170.45.136 with SMTP id 130mr28022979ykn.105.1433885745309; Tue, 09 Jun 2015 14:35:45 -0700 (PDT) Received: from [192.168.1.80] ([190.235.61.213]) by mx.google.com with ESMTPSA id c2sm5088115ywa.31.2015.06.09.14.35.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jun 2015 14:35:43 -0700 (PDT) References: <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E7547BD@MCHP04MSX.global-ad.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <19F65762-3692-4949-82E4-4CBD4B2D3AAC@gmail.com> X-Mailer: iPhone Mail (11D201) From: Victor Pascual Date: Tue, 9 Jun 2015 16:35:38 -0500 To: "Cullen Jennings (fluffy)" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-gateways- Statis IP Address Comment 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, 09 Jun 2015 21:35:47 -0000 Agree > On May 27, 2015, at 3:00 PM, "Cullen Jennings (fluffy)" = wrote: >=20 >=20 >> On Apr 30, 2015, at 2:30 AM, Hutton, Andrew wro= te: >>=20 >> So I suggest the following text. >>=20 >> "A WebRTC gateway which is deployed where it can be reached with a static= IP address (as seen from the client), does not need to support full ICE; it= therefore MAY implement ICE-Lite only". >>=20 >> Regards >> Andy >=20 > +1 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 9 18:02:29 2015 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 4A42A1A9063; Tue, 9 Jun 2015 18:02: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 zT4a22FqOJS4; Tue, 9 Jun 2015 18:02:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E3C1A9059; Tue, 9 Jun 2015 18:02:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610010219.25383.1025.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 18:02:19 -0700 Archived-At: Cc: draft-ietf-rtcweb-video.ad@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-video@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-video.shepherd@ietf.org Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-video-05: (with COMMENT) 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, 10 Jun 2015 01:02:23 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-video-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this, it is well written and easy to read. (It easily hides all the gnashing-of-teeth that went into it.) I've got just a couple of minor comments: -- section 3: "the video scan pattern for video codecs is Y’CbCr 4:2:0." At the risk of stepping way outside my expertise, I've generally heard that referred to as a (sub)sampling ratio. Is this talking about something different? -- 6.2, "max-mbps,..." Odd vertical spacing. From nobody Wed Jun 10 00:26:51 2015 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 00D5D1A92DC for ; Wed, 10 Jun 2015 00:26:49 -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 cnNw0sHGRyhq for ; Wed, 10 Jun 2015 00:26:47 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 D81461A92AF for ; Wed, 10 Jun 2015 00:26:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t5A7Qgxn020467 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Jun 2015 07:26:43 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t5A7QPQg031563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jun 2015 09:26:37 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 10 Jun 2015 09:26:33 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.53]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0235.001; Wed, 10 Jun 2015 09:26:33 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: ext Victor Pascual , "Cullen Jennings (fluffy)" Thread-Topic: [rtcweb] rtcweb-gateways- Statis IP Address Comment Thread-Index: AQHQgx/q7KWF0Xdw9kyt1tqhlfwnMp2k8kTngAClCVA= Date: Wed, 10 Jun 2015 07:26:33 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF8196A0206@DEMUMBX005.nsn-intra.net> References: <5531EFD2.5010107@alvestrand.no> <56C2F665D49E0341B9DF5938005ACDF81962D96C@DEMUMBX005.nsn-intra.net> <92D0D52F3A63344CA478CF12DB0648AAEC0E1EC8@XMB111CNC.rim.net> <5537CA1F.1060209@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E75341E@MCHP04MSX.global-ad.net> <55412808.7040409@alvestrand.no> <9F33F40F6F2CD847824537F3C4E37DDF1E7547BD@MCHP04MSX.global-ad.net> , <19F65762-3692-4949-82E4-4CBD4B2D3AAC@gmail.com> In-Reply-To: <19F65762-3692-4949-82E4-4CBD4B2D3AAC@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF8196A0206DEMUMBX005nsnin_" 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: 4513 X-purgate-ID: 151667::1433921203-00006B28-130CC1B8/0/0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] rtcweb-gateways- Statis IP Address Comment 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, 10 Jun 2015 07:26:49 -0000 --_000_56C2F665D49E0341B9DF5938005ACDF8196A0206DEMUMBX005nsnin_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi all, This change has been in the WG-adopted version I have uploaded recently. Kind regards, Uwe ________________________________ Von: ext Victor Pascual Gesendet: =FD09.=FD06.=FD2015 23:35 An: Cullen Jennings (fluffy) Cc: rtcweb@ietf.org Betreff: Re: [rtcweb] rtcweb-gateways- Statis IP Address Comment Agree > On May 27, 2015, at 3:00 PM, "Cullen Jennings (fluffy)" wrote: > > >> On Apr 30, 2015, at 2:30 AM, Hutton, Andrew wr= ote: >> >> So I suggest the following text. >> >> "A WebRTC gateway which is deployed where it can be reached with a stati= c IP address (as seen from the client), does not need to support full ICE; = it therefore MAY implement ICE-Lite only". >> >> Regards >> Andy > > +1 > > _______________________________________________ > 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 --_000_56C2F665D49E0341B9DF5938005ACDF8196A0206DEMUMBX005nsnin_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi all,

This change has been in the WG-adopted version I have uploaded recently.
Kind regards,
Uwe
Von: ext Victor Pascual<= br> Gesendet: =FD09= .=FD06.=FD2015 23:35
An: Cullen Jennings (fluffy)
Cc: rtcweb@ietf.org
Betreff: Re: [= rtcweb] rtcweb-gateways- Statis IP Address Comment

Agree

> On May 27, 2015, at 3:00 PM, "Cullen Jennings (fluffy)" <= fluffy@cisco.com> wrote:
>
>
>> On Apr 30, 2015, at 2:30 AM, Hutton, Andrew <andrew.hutton@unif= y.com> wrote:
>>
>> So I suggest the following text.
>>
>> "A WebRTC gateway which is deployed where it can be reached w= ith a static IP address (as seen from the client), does not need to support= full ICE; it therefore MAY implement ICE-Lite only".
>>
>> Regards
>> Andy
>
> +1
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_56C2F665D49E0341B9DF5938005ACDF8196A0206DEMUMBX005nsnin_-- From nobody Wed Jun 10 03:47:42 2015 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 030FB1ACE9B; Wed, 10 Jun 2015 03:47:42 -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 jJJIf3_Njt2e; Wed, 10 Jun 2015 03:47:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C16571ACE98; Wed, 10 Jun 2015 03:47:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150610104740.4842.50101.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 03:47:40 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 10 Jun 2015 10:47:42 -0000 Barry Leiba has entered the following ballot position for draft-ietf-rtcweb-rtp-usage-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Well written -- thanks! I just have a small comment: This document uses the terminology from [I-D.ietf-avtext-rtp-grouping-taxonomy] and [I-D.ietf-rtcweb-overview]. I'm not making this a DISCUSS, but I think that definitions of terminology that are necessary for the understanding of the document need to be normative references. I think that makes those two references normative, not informative. From nobody Wed Jun 10 08:13:43 2015 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 6ED801ACE72; Wed, 10 Jun 2015 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 N4SmqqyWyBZX; Wed, 10 Jun 2015 08:13:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297F21A877D; Wed, 10 Jun 2015 08:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8092; q=dns/txt; s=iport; t=1433949216; x=1435158816; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=T4JSRmW1cBMLMZnh+/HSKY23mqUPmVGX0LaTWyHdo+Y=; b=fBpEbxa4dqTCruWEigfaXsYB/2XMn6Ytz4LRin29GMlA30ScTdZ6rU7r LMiTe8d4Si2Zb1ewSvISu65jAN1jiTqnUtLFYVPnfXj6sc1GKbcgTEXzC UosiYnTkkIllt9EZxgW0qjl8h0Iu8KR1/5aFl9MB2lMtRG1e1p3iTcaL4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B7BABTU3hV/5JdJa1ZA4MQgTMGvRpmCYdbAoE2OBQBAQEBAQEBgQqEIgEBAQECASdSDAQCAQgRAwEBAQsdByERFAkIAQEEAQ0FCIgRAwoIy34NhUABAQEBAQEBAQEBAQEBAQEBAQEBAQEXikGBAoJNgWENGiEQBwYLgwaBFgEEhniFAyyHI4lWgxCDf4pWZIcSJGKDFm+BAwEfAiGBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,588,1427760000"; d="scan'208";a="463889" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jun 2015 15:13:34 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5AFDYIh015788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jun 2015 15:13:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 10 Jun 2015 10:13:34 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Black, David" , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "Ram Mohan R (rmohanr)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-14 Thread-Index: AdCi58lPi5K+gAtNQriBoM1GKpG0QgAqBvrw Date: Wed, 10 Jun 2015 15:13:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47867933@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" , "ietf@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-14 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, 10 Jun 2015 15:13:38 -0000 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, June 10, 2015 12:39 AM > To: muthu.arul@gmail.com; Dan Wing (dwing); Ram Mohan R (rmohanr); > Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops-dir@ietf.org > Cc: rtcweb@ietf.org; ietf@ietf.org; Black, David > Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-1= 4 >=20 > As a result of lengthy ;-) discussion, the -14 version of this draft addr= esses all of > the concerns in the OPS-Dir review of the -13 version, as well as the sub= sequent > concern about whether this draft is an update to RFC 5245. That latter u= pdate > concern has been resolved with a conclusion that this draft does not upda= te > RFC 5245 - the keepalive material in this draft has been revised to expla= in how > consent checks effectively serve as keepalives, removing any need to send > separate keepalives in a fashion that's compatible with RFC 5245. >=20 > I noticed a minor editorial nit: >=20 > - Section 1, top of p.3 >=20 > Consent is obtained only by full ICE implementations. An ICE-lite > agent (as defined in Section 2.7 of [RFC5245]) does not generate > connectivity checks or run the ICE state machine. An ICE-lite agent > does not generate consent checks, it will only respond to any checks > that it receives. >=20 > I'd change the start of latter sentence to better connect it to the previ= ous > sentence: >=20 > "An ICE-lite agent" -> "Hence, an ICE-lite agent" >=20 > also: >=20 > "consent checks, it will" -> "consent checks and will" Thanks, fixed in my local copy. -Tiru >=20 > idnits 2.13.02 ran clean. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Thursday, May 14, 2015 7:21 PM > > To: muthu.arul@gmail.com; dwing@cisco.com; rmohanr@cisco.com; > > tireddy@cisco.com; martin.thomson@gmail.com; ops-dir@ietf.org > > Cc: rtcweb@ietf.org; Black, David; ietf@ietf.org > > Subject: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 > > > > I have reviewed this document as part of the Operational directorate's > > ongoing effort to review all IETF documents being processed by the IESG= . > > These comments were written with the intent of improving the > > operational aspects of the IETF drafts. Comments that are not > > addressed in last call may be included in AD reviews during the IESG > > review. Document editors and WG chairs should treat these comments > > just like any other last call comments. > > > > Document: draft-ietf-rtcweb-stun-consent-freshness-13 > > Reviewer: David Black > > Review Date: May 14, 2015 > > IETF LC End Date: May 15, 2015 (on -11) > > > > Summary: This draft is on the right track, but has open issues > > described in the review. > > > > This draft describes use of STUN to obtain ongoing consent to send in > > a fashion that is secured by the use of cryptographically strong > > nonces as STUN transaction IDs. > > > > -- Major issues -- > > > > [1] The draft seems to be missing discussion of applicability - what > > environments and/or protocols is this mechanism intended for or > > applicable to? Is this generally applicable wherever ICE and STUN are > > used? I don't see any RFCs listed as updated by this draft, so I'm > > guessing that this is not intended to promulgate new requirements for > > all uses of ICE and STUN, but this should be clarified. The shepherd > > writeup implies that this draft is intended primarily for WebRTC. > > > > [2] The security considerations appear to be incomplete. > > There should be an explanation of why cryptographically strong STUN > > transaction IDs are required (e.g., there are no cryptographically > > strong IDs in the TCP consent mechanism noted on p.4), and there > > should be a discussion of how and why replays of previous consent > > responses are harmless (will be ignored by the recipient). The > > mechanism design appears to be ok, but this rationale should be > > provided in terms of attacks that are of concern and how they are > > prevented - a primary intent appears to be to resisting off-path attack= s. > > > > -- Minor Issues -- > > > > [3] In Section 1, please explain what ICE-lite is. A suitable > > reference should suffice. > > > > [4] In Section 4.1, please explain or provide a reference for what "pac= ed" > > means in "paced STUN connectivity checks or responses." > > > > -- Nits/Editorial Comments -- > > > > The SRTP paragraph in Section 8 (Security Considerations) feels out of > > place > > - this looks like design rationale material that would be better > > located in Section 3. > > > > idnits 2.13.02 found an unused reference: > > > > =3D=3D Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on lin= e 320, but > > no explicit reference was found in the text > > > > That reference is likely to be useful to address the absence of > > discussion of applicability (major issue [1], above). > > > > --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- > > > > This mechanism is an incremental modification to the STUN and ICE > > protocols, and can be implemented by one party to a communication > > session; ordinary response generation behavior (already required) > > reflects the cryptographically strong STUN transaction IDs on which > > the mechanism is based. As a result, the mechanism can be deployed at > > one end of a two-party communication session without impact on the > > other party. This is implied by section 3 of the draft, but would be > > useful to state explicitly. [A.1.1 - deployment] > > > > The mechanism has been defined to limit the amount of added traffic > > and to shut down unwanted traffic, plus contains a facility to > > desynchronize independent users of this protocol. Some rationale > > should be added for the choice of the 30 second timeout period. > > [A.1.5 - network impact] > > > > There is an obvious fault condition, namely that consent is lost or > > revoked causing immediate cessation of traffic. While the details > > depend on the environment in which this mechanism is used, it'd be > > helpful to add a sentence or two on reporting of the state of STUN > > consent-based connectivity and how that reporting should or may relate > > to reporting of the state of other forms of connectivity (e.g., TCP, > SRTP/SRTCP) that are mentioned in this draft. > > [A.1.8 - fault and threshold conditions] > > > > This mechanism is a simple extension to existing protocols, and should > > fit into existing configuration and management for those protocols. > > [A.1.9 - configuration, A.2 - Management (in general)] > > > > It might be useful to mention the utility of tracking frequency and > > duration of loss and re-establishment of consent-based connectivity, > > as such information has operational value. In particular, a > > discussion of how a server could infer loss of connectivity with a > > client that is using this mechanism might be useful to add, as the > > operational concerns may be more significant for servers and related > > networks than clients. [A.2.2 - management information, A.2.3 - fault > > management]. > > > > The primary operational impact of this protocol should be reduction in > > unwanted traffic, which is a benefit - the consent check traffic added > > by this protocol should not have significant impacts. The writeup > > indicates that implementers have reviewed the draft and > > implementations are in progress. [A.3 - Documentation] > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer EMC Corporation, 176 South St., > > Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > From nobody Wed Jun 10 08:50:08 2015 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 45B4A1B2F36; Wed, 10 Jun 2015 08:50:06 -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 yW6jVFde9fQL; Wed, 10 Jun 2015 08:50:03 -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 AF7701B2F24; Wed, 10 Jun 2015 08:50:02 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-fc-55785ca81856 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.3B.17665.8AC58755; Wed, 10 Jun 2015 17:50:00 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Wed, 10 Jun 2015 17:50:00 +0200 Message-ID: <55785CA7.4090005@ericsson.com> Date: Wed, 10 Jun 2015 17:49:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Chris Inacio , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> In-Reply-To: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM+Jvre6KmIpQgw/vtCzmtMZbzPgzkdli 4dqTjBZr/7WzW3xY+JDFgdVjxgYfjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr4+PTRSwF Cx0rpvflNDCeN+5i5OSQEDCROLrqPjOELSZx4d56ti5GLg4hgaOMEq8v72SBcJYzSnSv28oG UsUroC3x78sTFhCbRUBVYtW8g+wgNpuAhcTNH41gNaICURJTH69jgagXlDg58wnYIBGBb0BT t05nBEkIC9hILJrxD6xBSMBaYufCR0CDODg4geK/upVAwsxAM2fOP88IYctLNG+dzQxRri3R 0NTBOoFRYBaSFbOQtMxC0rKAkXkVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmDoHtzyW3cH 4+rXjocYBTgYlXh4FWaVhwqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2PT8uoKs4y4WSdyOWzP3u6qiti1Mq9zupO9wUIzlzVJ/m5at1+4yTEvu6t19Psl GU0G70Obg3kK5k6az55q5sexI/H8hkeSE1uOPfmyauo5v8qP2xgzE9t5XX1erT+lO2vzWu3W gE1HMmfuzLnbM31B4qIguYmuTP9/JcqGLO5g8I2aM+9RgpISS3FGoqEWc1FxIgDDl9LSPgIA AA== Archived-At: Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 10 Jun 2015 15:50:06 -0000 Hi, (Adding RTCWEB WG list as this discusses changes to the draft) Thanks for the very detailed review. We will include all relevant changes in an update that will be submitted after the IESG call tomorrow. WG, this is your chance to scream if there are bad changes here. Chris Inacio skrev den 2015-06-09 17:13: > > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > > BLUF: This draft is ready to go with some NITS. > > > This draft is an overarching set of guidelines of the use and > application of RTP and RTCP as it applies to WebRTC and the related > W3C API. The W3C API is not described in this document, but > references to functionality requirements for the API are made. > > This draft is extremely well written. At the same time, however, it > reads like an encyclopedia of references and requirements across 35 > different normative other referenced drafts. Correspondingly, I did > NOT read through all of the referenced drafts, nor did I believe that > it was necessary in this case to do so. > > The security considerations section was comprehensive and security > impacts were taken into account throughout this draft. I have two > small NIT’s about the security section that I would like improved, > and I feel these are rather small: First, in the paragraph in the > security section that starts “RTCP packets convey a Canonical Name…†> the authors state that the CNAME generation algorithm in described in > section 4.9 – it isn’t, section 4.9 references RFC7022 for the > generation algorithm. Yes, but it actually specifies which particular generation algorithm to use. RFC7022 does contain more than one. I propose that we change this text to say: Section 4.9 of this memo mandates generation of short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in untraceable CNAME values that alleviate this risk. Second, the last paragraph on page 39, > starting with “Providing source authentication in multi-party…†ends > the page with a large security warning. Please include a reference > in that paragraph in the security considerations and possibly to the > appropriate draft/RFC which discusses that issue in some more depth. If I understand this correctly, you want something like the below added to the security consideration section. I suggest to add this last in the section. In multi-party communication scenarios using RTP Middleboxes, a lot of trust is placed on these middleboxes to preserve the sessions security. The middlebox needs to maintain the confidentiality, integrity and perform source authentication. As discussed in Section 12.1.1 the middlebox can perform checks that prevents any endpoint participating in a conference to impersonate another. Some additional security considerations regarding multi-party topologies can be found in [I-D.ietf-avtcore-rtp-topologies-update]. > > > general NITS: > > I believe there are multiple versions of “end point†used in the > document End Point, end-point, etc. Those should be harmonized. > Yes, we will use endpoint > > page 4: > > Section 2 Rationale > > “This builds on the past 20 years development of RTP to mandate the > use of extensions that have shown widespread utility†> > can this be reworded to “This builds on the past 20 years of RTP > development to mandate the use of extensions that have shown > widespread utility.†> Yes. > > page 6: > > “This specification requires the usage of a single CNAME when sending > RTP Packet Streams…†should the “require†be “REQUIREâ€? This is intended as an informational reference, thus I propose to change this to "mandates" thus avoiding the RFC2119 terms. > > page 7: > > "This to ensure robust handling of future extensions…†to “This is to > ensure…†Sure. > > page 14: > > In reference to the paragraph that starts with “While the use of IP > multicast...â€. There is no MAY/SHOULD/SHALL/REQUIRE etc. in the > paragraph, but the last sentence does seem to imply an implementation > requirement. Was that intentional? Yes, it is intentional. > > page 16: > > “This can be various reasons for this:…†to “There can be various > reasons for this:…†Addressed in -24 version. > > page 20: > > “heterogeneous network environments using a variety set of link > technologies…†get rid of “setâ€. > Yes. > page 23: > > “…supported by the RTCP Extended Reports (XR) framework > [RFC3611][RFC6792].†RFC3611 seems to be a full fledged reference > while RFC6792 seems to just be text of “[RFC6792]â€. > They are both relevant references when understanding what RTCP XR are and what metrics one should consider. I propose to add a "see" so that the results become "... framework, see [RFC3611][RFC6792]. > page 25: > > First paragraph of section 11 defines a number of WebRTC API terms, > PLEASE move those (far) forward in the document. “The > MediaStreamTracks within a MediaStream need to be possible to play > out synchronized.†rewrite to “The MediaStreamTracks within a > MediaStream may need to be synchronized during play back.†or > something similar. I have added also MediaStreamTrack to the Terminology section (3). And populated both MediaStream and MediaStreamTrack with text from this paragraph. I have however not removed any text from this paragraph in Section 11. > > page 26: > > “force an end-point to to disrupt†only one “toâ€. Ok > > “This is motivating the discussion in Section 4.9â€, (yes, now I’m > really getting picky,) but the discussion was already motivated. :) Changed this to: This is motivating the use of a single CNAME in Section 4.9. > > page 27: > > “Optimizations of this method is clearly possible and …†“is†-> > “are†ok > > “receiving multiple MediaStreamTracks, where each of different > MediaStreamTracks (and …†to “ … where each of *the* different > MediaStreamTracks … “ Fixed > > “This later is relevant to handle some cases of legacy interop.†to > “The later is relevant … legacy interoperability.†> Ok > page 28: > > “. . . Endpoints can configure and use RTP sessions is outlined.†> change “is†to “are†> > “ . . . it is common to use one RTP session for each type of media > sources (e.g. . . .†change “sources†to “source†> > page 31: > > “To maintain a coherent mapping between the relation between RTP > sessions and RTCPeerConnection objects it is …†rewrite to maybe > > “To maintain a coherent mapping between the relationship of RTP > sessions and RTCPeerConnection objects it is ….†I propose: To maintain a coherent mapping of the relationship between RTP sessions and RTCPeerConnection objects it is recommend that this is implemented as several individual RTP sessions. > > page 32: > > “This scenario also results in that an end-point’s feedback or > requests goes to the mixer…†change “goes†to “goâ€. ok > > “necessarily be explicitly visible any RTP and RTCP traffic …†to > “necessarily be explicitly visible to any RTP and RTCP trafficâ€. Yes > > page 38: > > “combing†to “combining†> ok > > > -- Chris Inacio inacio@cert.org > > > Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jun 10 08:58:48 2015 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 EA9851A8852; Wed, 10 Jun 2015 08:58:46 -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 VX7Wf8f58NoK; Wed, 10 Jun 2015 08:58:45 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE401B319F; Wed, 10 Jun 2015 08:58:27 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-f4-55785ea1dc5c Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 66.ED.04015.1AE58755; Wed, 10 Jun 2015 17:58:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Wed, 10 Jun 2015 17:58:25 +0200 Message-ID: <55785EA0.6000803@ericsson.com> Date: Wed, 10 Jun 2015 17:58:24 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150610104740.4842.50101.idtracker@ietfa.amsl.com> In-Reply-To: <20150610104740.4842.50101.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvre7CuIpQg+MXDS0OLb7EajHjz0Rm i7X/2tkdmD1aVvUyeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PEvtXMBd95KuYvVm5g3MnVxcjJ ISFgIrFj92ZGCFtM4sK99WxdjFwcQgJHGSWaHixlAkkICSxnlNi9xATE5hXQluh9N5kNxGYR UJVY+OwGK4jNJmAhcfNHI1hcVCBKYurjdSwQ9YISJ2c+AbNFBJwl3lz6AzaTWUBU4tXDKcwg trBAisSnr1egdjlIHNk0H2wmp4CjxJwjS4BqOIDq7SUebC2DaJWXaN46mxmiXFuioamDdQKj 4Cwk22YhdMxC0rGAkXkVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmDIHtzy22AH48vnjocY BTgYlXh4FWeVhwqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU AyPHZI3GaYXH++asz9dOu/9QPuSO8/t3V7nLTjHLvZBKDONNN2iPm5otHlN/4gTLM/6e+2Zs eRrPRb8cm9YnKsX5cUWymcu6d9dXxk/lsWiz+f0ybrYm/5EM9pbL5ZorKth1WrKDP58S/zjx BOv66jXnQmb7XpTkvcK7dXvdz4wEWz79D71i85RYijMSDbWYi4oTAcfi9AY6AgAA Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 10 Jun 2015 15:58:47 -0000 Hi Barry, Barry Leiba skrev den 2015-06-10 12:47: > > This document uses the terminology from > [I-D.ietf-avtext-rtp-grouping-taxonomy] and > [I-D.ietf-rtcweb-overview]. > > I'm not making this a DISCUSS, but I think that definitions of > terminology that are necessary for the understanding of the document need > to be normative references. I think that makes those two references > normative, not informative. > I am changing the rtp-grouping-taxonomy to a normative reference. See discussion with Ben. This of course will result in the need for a new IETF last call for the downref. But, that is probably good, as also the WG needs time to digest the many small changes. However, my personal view is that IETF need to be able to reference concept and basic definitions from informational documents without making it normative references. Otherwise we will have a lot of things in the downref registry and not be able to find when we end up in actual real issues with protocol mechanisms and their source and maturity. That is why I intended to leave draft-ietf-rtcweb-overview as an informational reference. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jun 10 09:07:41 2015 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 1C45E1B3264; Wed, 10 Jun 2015 09:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 ZZFiAFL34IHQ; Wed, 10 Jun 2015 09:07:36 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6391B3260; Wed, 10 Jun 2015 09:07:36 -0700 (PDT) Received: by igblz2 with SMTP id lz2so37019339igb.1; Wed, 10 Jun 2015 09:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XyHVUnvzu5LRLMxwroGVSn/SM52/TGTmn5nWDzukeis=; b=PcMEI9Bt79cQIIbJmswWjG27NMRqg8d9b8NTHsy5f78+Y4qGLaWWYm4/rduhWCsS6a iJND+1SUOwJSwoQm45NJFBrA/DAGXsH91noNvejFBcd57a9ZeL9STIFdiZJRSL+0JlH4 nAOWksVNyBFGGdAf8emn/Zzw3NAV3b4xv82DoN9WSPmcMHX3I4mp9dzfh2SAA9b9i0Ht u7/laq7hCJ+tQ7MeTBZ7MNdUOVrvfuBOyFHHQ76hE7kPmLWDAiD+cKE6OnMjkq7hvN71 hd6BUfn5IZbUFNCc6sJyCwg7xfAItXSMus5IeuAUzamGhngo09yvXQIeAA4a2P+bbwMM CHgg== MIME-Version: 1.0 X-Received: by 10.50.43.227 with SMTP id z3mr6846162igl.12.1433952455691; Wed, 10 Jun 2015 09:07:35 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.16.222 with HTTP; Wed, 10 Jun 2015 09:07:35 -0700 (PDT) In-Reply-To: <55785EA0.6000803@ericsson.com> References: <20150610104740.4842.50101.idtracker@ietfa.amsl.com> <55785EA0.6000803@ericsson.com> Date: Wed, 10 Jun 2015 17:07:35 +0100 X-Google-Sender-Auth: twdC6GeavPBJa3uAgr2tiGMRZFQ Message-ID: From: Barry Leiba To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" , The IESG Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 10 Jun 2015 16:07:37 -0000 > However, my personal view is that IETF need to be able to reference concept > and basic definitions from informational documents without making it > normative references. Otherwise we will have a lot of things in the downref > registry and not be able to find when we end up in actual real issues with > protocol mechanisms and their source and maturity. That is why I intended to > leave draft-ietf-rtcweb-overview as an informational reference. Well, I think normative references are all those that you *need* in order to understand the document. If you don't read rtcweb-overview and understand the terminology in it... would you be able to properly understand this document? That said, I'll leave it to your judgment here, and won't argue the point further. [And as a side point, I'm working with some other folks on an update to BCP 97. The update would *not* require that these sorts of documents go into the downref registry, but would instead give judgment to the IESG on the right way to handle this while making sure that normative references were sufficiently mature. Because I agree that the downref registry was never *meant* for documents that are only used for terminology.] Barry From nobody Wed Jun 10 09:30:49 2015 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 61EDB1A8971; Wed, 10 Jun 2015 09:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 cCSF4mca8rAc; Wed, 10 Jun 2015 09:30:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533DA1A8968; Wed, 10 Jun 2015 09:30:42 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5AGUX4M074752 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Jun 2015 11:30:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55786629.6060705@nostrum.com> Date: Wed, 10 Jun 2015 11:30:33 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Magnus Westerlund , Chris Inacio , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> In-Reply-To: <55785CA7.4090005@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 10 Jun 2015 16:30:43 -0000 On 6/10/15 10:49, Magnus Westerlund wrote: >> page 6: >> >> “This specification requires the usage of a single CNAME when sending >> RTP Packet Streams…†should the “require†be “REQUIREâ€? > > This is intended as an informational reference, thus I propose to > change this to "mandates" thus avoiding the RFC2119 terms. RFC 2119 doesn't remove the words "require", "must", "should", "may" and "recommend" from the English language. If all you mean is the ordinary word "require," (rather than the 2119 term "REQUIRE"), then "require" is just fine. /a From nobody Wed Jun 10 11:25:38 2015 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 16EE31B33ED; Wed, 10 Jun 2015 11:25: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 Vyt_mly73Ut7; Wed, 10 Jun 2015 11:25:35 -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 90A971B2E90; Wed, 10 Jun 2015 11:25:35 -0700 (PDT) Received: from [81.187.2.149] (port=48437 helo=[192.168.0.24]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Z2kgq-0002ER-DW; Wed, 10 Jun 2015 19:25: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: <55786629.6060705@nostrum.com> Date: Wed, 10 Jun 2015 19:25:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> <55786629.6060705@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "secdir@ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , Chris Inacio Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 10 Jun 2015 18:25:37 -0000 On 10 Jun 2015, at 17:30, Adam Roach wrote: > On 6/10/15 10:49, Magnus Westerlund wrote: >>> page 6: >>>=20 >>> =93This specification requires the usage of a single CNAME when = sending >>> RTP Packet Streams=85=94 should the =93require=94 be =93REQUIRE=94? >>=20 >> This is intended as an informational reference, thus I propose to = change this to "mandates" thus avoiding the RFC2119 terms. >=20 > RFC 2119 doesn't remove the words "require", "must", "should", "may" = and "recommend" from the English language. If all you mean is the = ordinary word "require," (rather than the 2119 term "REQUIRE"), then = "require" is just fine. The RFC 2119 term is "REQUIRED", not "REQUIRES" or "REQUIRE" anyway, but = we have explicitly avoided lower-case versions of RFC 2119 terms in the = draft, precisely to avoid any possible confusion. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Jun 10 13:37:43 2015 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 7843C1A00F3; Wed, 10 Jun 2015 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_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 4WzXR7BsIPn4; Wed, 10 Jun 2015 11:34:30 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112AA1A0091; Wed, 10 Jun 2015 11:34:29 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t5AIYPKX017219; Wed, 10 Jun 2015 14:34:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1433961266; bh=bhnNdMnS9M/mCUISEP8TcP2nw3GptvSuIxvDDHOFa8I=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=YgMaHQoSuzl3WMASp2GrjfSrTIaaZw6EDsnqYJgmNsN0RGNl052ZBNRRP7h63Kx55 +j+37tGW3b0jH8i8RyhQGQzJESXAB9pSxa8GHgsSCTlGbAFk1lfUyLF9RPMdeEgwkW e8YOWdrCguVz13WUJxuEfJCiFh7AMEJ0DFZTZHMo= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by timber.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t5AIYKHC003932; Wed, 10 Jun 2015 14:34:20 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 14:34:20 -0400 From: Chris Inacio To: Adam Roach Thread-Topic: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 Thread-Index: AQHQosbhcvT38Apty0Os5Xa8WMhXhJ2mJ7aAgAALVYD//9+Hag== Date: Wed, 10 Jun 2015 18:34:20 +0000 Message-ID: <2D926D03-6D62-4C9E-AA5B-330E168DD969@cert.org> References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com>,<55786629.6060705@nostrum.com> In-Reply-To: <55786629.6060705@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 13:37:42 -0700 Cc: "rtcweb@ietf.org" , "iesg@ietf.org" , "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 10 Jun 2015 18:34:31 -0000 > On Jun 10, 2015, at 9:30 AM, Adam Roach wrote: >=20 > On 6/10/15 10:49, Magnus Westerlund wrote: >>> page 6: >>>=20 >>> =93This specification requires the usage of a single CNAME when sending >>> RTP Packet Streams=85=94 should the =93require=94 be =93REQUIRE=94? >>=20 >> This is intended as an informational reference, thus I propose to change= this to "mandates" thus avoiding the RFC2119 terms. >=20 > RFC 2119 doesn't remove the words "require", "must", "should", "may" and = "recommend" from the English language. If all you mean is the ordinary word= "require," (rather than the 2119 term "REQUIRE"), then "require" is just f= ine. >=20 > /a That was exactly my comment and you have made a thoughtful decision -- I'm = good.=20 -- Chris Inacio From nobody Wed Jun 10 13:37:45 2015 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 610C71AC3F7; Wed, 10 Jun 2015 13:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_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 tKUTK0gjLpW1; Wed, 10 Jun 2015 13:31:29 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5F31A8AF3; Wed, 10 Jun 2015 13:31:29 -0700 (PDT) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id t5AKVPPD019698; Wed, 10 Jun 2015 16:31:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1433968285; bh=mzppUFy1xpGixGdkun8nL7U+O23+P0JsH+cuwZpHJB8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-ID:Content-Transfer-Encoding:MIME-Version: Sender:Reply-To; b=cD9Yu9MKDGXM3hrybFdqbkYHCVhzOhr5tCUxlgIBiX9z/nNGOSg9QI5Pg8BkMPJ+f VGheqWQ0UxGIkov+7U2Xdj2FRlMPEzoW6sYzZUuijRJGy83q4+1hl/OJTmlb8mTT4H s/YdUK7NaLdhX2qsd4njkCbBf/jyLI2oosv5pwho= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id t5AKVTCe005093; Wed, 10 Jun 2015 16:31:29 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0210.002; Wed, 10 Jun 2015 16:31:22 -0400 From: Chris Inacio To: Magnus Westerlund Thread-Topic: sector review of draft-ietf-rtcweb-rtp-usage-23 Thread-Index: AQHQosbhcvT38Apty0Os5Xa8WMhXhJ2mJ7aAgABOk4A= Date: Wed, 10 Jun 2015 20:31:22 +0000 Message-ID: References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> In-Reply-To: <55785CA7.4090005@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.96.46] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 10 Jun 2015 13:37:42 -0700 Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 10 Jun 2015 20:31:32 -0000 DQoNCj4gT24gSnVuIDEwLCAyMDE1LCBhdCA4OjQ5IEFNLCBNYWdudXMgV2VzdGVybHVuZCA8bWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gKEFk ZGluZyBSVENXRUIgV0cgbGlzdCBhcyB0aGlzIGRpc2N1c3NlcyBjaGFuZ2VzIHRvIHRoZSBkcmFm dCkNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHZlcnkgZGV0YWlsZWQgcmV2aWV3LiBXZSB3aWxsIGlu Y2x1ZGUgYWxsIHJlbGV2YW50IGNoYW5nZXMgaW4gYW4gdXBkYXRlIHRoYXQgd2lsbCBiZSBzdWJt aXR0ZWQgYWZ0ZXIgdGhlIElFU0cgY2FsbCB0b21vcnJvdy4NCj4gDQo+IFdHLCB0aGlzIGlzIHlv dXIgY2hhbmNlIHRvIHNjcmVhbSBpZiB0aGVyZSBhcmUgYmFkIGNoYW5nZXMgaGVyZS4NCj4gDQo+ IA0KPiBDaHJpcyBJbmFjaW8gc2tyZXYgZGVuIDIwMTUtMDYtMDkgMTc6MTM6DQo+PiANCj4+IA0K Pj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkg ZGlyZWN0b3JhdGUncw0KPj4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+PiBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQo+PiBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJl YXQNCj4+IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLg0KPj4gDQo+PiANCj4+IEJMVUY6ICBUaGlzIGRyYWZ0IGlzIHJlYWR5IHRvIGdvIHdpdGgg c29tZSBOSVRTLg0KPj4gDQo+PiANCj4+IFRoaXMgZHJhZnQgaXMgYW4gb3ZlcmFyY2hpbmcgc2V0 IG9mIGd1aWRlbGluZXMgb2YgdGhlIHVzZSBhbmQNCj4+IGFwcGxpY2F0aW9uIG9mIFJUUCBhbmQg UlRDUCBhcyBpdCBhcHBsaWVzIHRvIFdlYlJUQyBhbmQgdGhlIHJlbGF0ZWQNCj4+IFczQyBBUEku ICBUaGUgVzNDIEFQSSBpcyBub3QgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQsIGJ1dA0KPj4g cmVmZXJlbmNlcyB0byBmdW5jdGlvbmFsaXR5IHJlcXVpcmVtZW50cyBmb3IgdGhlIEFQSSBhcmUg bWFkZS4NCj4+IA0KPj4gVGhpcyBkcmFmdCBpcyBleHRyZW1lbHkgd2VsbCB3cml0dGVuLiAgQXQg dGhlIHNhbWUgdGltZSwgaG93ZXZlciwgaXQNCj4+IHJlYWRzIGxpa2UgYW4gZW5jeWNsb3BlZGlh IG9mIHJlZmVyZW5jZXMgYW5kIHJlcXVpcmVtZW50cyBhY3Jvc3MgMzUNCj4+IGRpZmZlcmVudCBu b3JtYXRpdmUgb3RoZXIgcmVmZXJlbmNlZCBkcmFmdHMuICBDb3JyZXNwb25kaW5nbHksIEkgZGlk DQo+PiBOT1QgcmVhZCB0aHJvdWdoIGFsbCBvZiB0aGUgcmVmZXJlbmNlZCBkcmFmdHMsIG5vciBk aWQgSSBiZWxpZXZlIHRoYXQNCj4+IGl0IHdhcyBuZWNlc3NhcnkgaW4gdGhpcyBjYXNlIHRvIGRv IHNvLg0KPj4gDQo+PiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiB3YXMgY29t cHJlaGVuc2l2ZSBhbmQgc2VjdXJpdHkNCj4+IGltcGFjdHMgd2VyZSB0YWtlbiBpbnRvIGFjY291 bnQgdGhyb3VnaG91dCB0aGlzIGRyYWZ0LiAgSSBoYXZlIHR3bw0KPj4gc21hbGwgTklU4oCZcyBh Ym91dCB0aGUgc2VjdXJpdHkgc2VjdGlvbiB0aGF0IEkgd291bGQgbGlrZSBpbXByb3ZlZCwNCj4+ IGFuZCBJIGZlZWwgdGhlc2UgYXJlIHJhdGhlciBzbWFsbDoNCj4gDQo+IEZpcnN0LCBpbiB0aGUg cGFyYWdyYXBoIGluIHRoZQ0KPj4gc2VjdXJpdHkgc2VjdGlvbiB0aGF0IHN0YXJ0cyDigJxSVENQ IHBhY2tldHMgY29udmV5IGEgQ2Fub25pY2FsIE5hbWXigKbigJ0NCj4+IHRoZSBhdXRob3JzIHN0 YXRlIHRoYXQgdGhlIENOQU1FIGdlbmVyYXRpb24gYWxnb3JpdGhtIGluIGRlc2NyaWJlZCBpbg0K Pj4gc2VjdGlvbiA0Ljkg4oCTIGl0IGlzbuKAmXQsIHNlY3Rpb24gNC45IHJlZmVyZW5jZXMgUkZD NzAyMiBmb3IgdGhlDQo+PiBnZW5lcmF0aW9uIGFsZ29yaXRobS4NCj4gDQo+IFllcywgYnV0IGl0 IGFjdHVhbGx5IHNwZWNpZmllcyB3aGljaCBwYXJ0aWN1bGFyIGdlbmVyYXRpb24gYWxnb3JpdGht IHRvIHVzZS4gUkZDNzAyMiBkb2VzIGNvbnRhaW4gbW9yZSB0aGFuIG9uZS4NCj4gDQo+IEkgcHJv cG9zZSB0aGF0IHdlIGNoYW5nZSB0aGlzIHRleHQgdG8gc2F5Og0KPiANCj4gU2VjdGlvbiA0Ljkg b2YgdGhpcyBtZW1vIG1hbmRhdGVzIGdlbmVyYXRpb24gb2Ygc2hvcnQtdGVybSBwZXJzaXN0ZW50 IFJUQ1AgQ05BTUVTLCBhcyBzcGVjaWZpZWQgaW4gUkZDNzAyMiwgcmVzdWx0aW5nIGluIHVudHJh Y2VhYmxlIENOQU1FIHZhbHVlcyB0aGF0IGFsbGV2aWF0ZSB0aGlzIHJpc2suDQo+IA0KDQpsb29r cyBnb29kLg0KDQo+IFNlY29uZCwgdGhlIGxhc3QgcGFyYWdyYXBoIG9uIHBhZ2UgMzksDQo+PiBz dGFydGluZyB3aXRoIOKAnFByb3ZpZGluZyBzb3VyY2UgYXV0aGVudGljYXRpb24gaW4gbXVsdGkt cGFydHnigKbigJ0gZW5kcw0KPj4gdGhlIHBhZ2Ugd2l0aCBhIGxhcmdlIHNlY3VyaXR5IHdhcm5p bmcuICAgUGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UNCj4+IGluIHRoYXQgcGFyYWdyYXBoIGlu IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgcG9zc2libHkgdG8gdGhlDQo+PiBhcHBy b3ByaWF0ZSBkcmFmdC9SRkMgd2hpY2ggZGlzY3Vzc2VzIHRoYXQgaXNzdWUgaW4gc29tZSBtb3Jl IGRlcHRoLg0KPiANCj4gDQo+IElmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgeW91IHdh bnQgc29tZXRoaW5nIGxpa2UgdGhlIGJlbG93IGFkZGVkIHRvIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9uIHNlY3Rpb24uIEkgc3VnZ2VzdCB0byBhZGQgdGhpcyBsYXN0IGluIHRoZSBzZWN0aW9u Lg0KPiANCj4gICBJbiBtdWx0aS1wYXJ0eSBjb21tdW5pY2F0aW9uIHNjZW5hcmlvcyB1c2luZyBS VFAgTWlkZGxlYm94ZXMsIGEgbG90DQo+ICAgb2YgdHJ1c3QgaXMgcGxhY2VkIG9uIHRoZXNlIG1p ZGRsZWJveGVzIHRvIHByZXNlcnZlIHRoZSBzZXNzaW9ucw0KPiAgIHNlY3VyaXR5LiAgVGhlIG1p ZGRsZWJveCBuZWVkcyB0byBtYWludGFpbiB0aGUgY29uZmlkZW50aWFsaXR5LA0KPiAgIGludGVn cml0eSBhbmQgcGVyZm9ybSBzb3VyY2UgYXV0aGVudGljYXRpb24uICBBcyBkaXNjdXNzZWQgaW4N Cj4gICBTZWN0aW9uIDEyLjEuMSB0aGUgbWlkZGxlYm94IGNhbiBwZXJmb3JtIGNoZWNrcyB0aGF0 IHByZXZlbnRzIGFueQ0KPiAgIGVuZHBvaW50IHBhcnRpY2lwYXRpbmcgaW4gYSBjb25mZXJlbmNl IHRvIGltcGVyc29uYXRlIGFub3RoZXIuICBTb21lDQo+ICAgYWRkaXRpb25hbCBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyByZWdhcmRpbmcgbXVsdGktcGFydHkgdG9wb2xvZ2llcw0KPiAgIGNhbiBi ZSBmb3VuZCBpbiBbSS1ELmlldGYtYXZ0Y29yZS1ydHAtdG9wb2xvZ2llcy11cGRhdGVdLg0KPiAN Cg0KVGhhdCB3b3VsZCBiZSBleGNlbGxlbnQuDQoNCj4+IA0KPj4gDQo+PiBnZW5lcmFsIE5JVFM6 DQo+PiANCj4+IEkgYmVsaWV2ZSB0aGVyZSBhcmUgbXVsdGlwbGUgdmVyc2lvbnMgb2Yg4oCcZW5k IHBvaW504oCdIHVzZWQgaW4gdGhlDQo+PiBkb2N1bWVudCBFbmQgUG9pbnQsIGVuZC1wb2ludCwg ZXRjLiAgVGhvc2Ugc2hvdWxkIGJlIGhhcm1vbml6ZWQuDQo+PiANCj4gDQo+IFllcywgd2Ugd2ls bCB1c2UgZW5kcG9pbnQNCj4gDQo+PiANCj4+IHBhZ2UgNDoNCj4+IA0KPj4gU2VjdGlvbiAyIFJh dGlvbmFsZQ0KPj4gDQo+PiDigJxUaGlzIGJ1aWxkcyBvbiB0aGUgcGFzdCAyMCB5ZWFycyBkZXZl bG9wbWVudCBvZiBSVFAgdG8gbWFuZGF0ZSB0aGUNCj4+IHVzZSBvZiBleHRlbnNpb25zIHRoYXQg aGF2ZSBzaG93biB3aWRlc3ByZWFkIHV0aWxpdHnigJ0NCj4+IA0KPj4gY2FuIHRoaXMgYmUgcmV3 b3JkZWQgdG8g4oCcVGhpcyBidWlsZHMgb24gdGhlIHBhc3QgMjAgeWVhcnMgb2YgUlRQDQo+PiBk ZXZlbG9wbWVudCB0byBtYW5kYXRlIHRoZSB1c2Ugb2YgZXh0ZW5zaW9ucyB0aGF0IGhhdmUgc2hv d24NCj4+IHdpZGVzcHJlYWQgdXRpbGl0eS7igJ0NCj4+IA0KPiANCj4gWWVzLg0KPiANCj4+IA0K Pj4gcGFnZSA2Og0KPj4gDQo+PiDigJxUaGlzIHNwZWNpZmljYXRpb24gcmVxdWlyZXMgdGhlIHVz YWdlIG9mIGEgc2luZ2xlIENOQU1FIHdoZW4gc2VuZGluZw0KPj4gUlRQIFBhY2tldCBTdHJlYW1z 4oCm4oCdICAgc2hvdWxkIHRoZSDigJxyZXF1aXJl4oCdIGJlIOKAnFJFUVVJUkXigJ0/DQo+IA0K PiBUaGlzIGlzIGludGVuZGVkIGFzIGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlLCB0aHVzIEkg cHJvcG9zZSB0byBjaGFuZ2UgdGhpcyB0byAibWFuZGF0ZXMiIHRodXMgYXZvaWRpbmcgdGhlIFJG QzIxMTkgdGVybXMuDQo+IA0KPiANCknigJltIGdvb2Qgd2l0aCB0aGF0Lg0KDQo+PiANCj4+IHBh Z2UgNzoNCj4+IA0KPj4gIlRoaXMgdG8gZW5zdXJlIHJvYnVzdCBoYW5kbGluZyBvZiBmdXR1cmUg ZXh0ZW5zaW9uc+KApuKAnSB0byDigJxUaGlzIGlzIHRvDQo+PiBlbnN1cmXigKbigJ0NCj4gDQo+ IFN1cmUuDQo+IA0KPj4gDQo+PiBwYWdlIDE0Og0KPj4gDQo+PiBJbiByZWZlcmVuY2UgdG8gdGhl IHBhcmFncmFwaCB0aGF0IHN0YXJ0cyB3aXRoIOKAnFdoaWxlIHRoZSB1c2Ugb2YgSVANCj4+IG11 bHRpY2FzdC4uLuKAnS4gIFRoZXJlIGlzIG5vIE1BWS9TSE9VTEQvU0hBTEwvUkVRVUlSRSBldGMu IGluIHRoZQ0KPj4gcGFyYWdyYXBoLCBidXQgdGhlIGxhc3Qgc2VudGVuY2UgZG9lcyBzZWVtIHRv IGltcGx5IGFuIGltcGxlbWVudGF0aW9uDQo+PiByZXF1aXJlbWVudC4gIFdhcyB0aGF0IGludGVu dGlvbmFsPw0KPiANCj4gWWVzLCBpdCBpcyBpbnRlbnRpb25hbC4NCj4gDQo+PiANCj4+IHBhZ2Ug MTY6DQo+PiANCj4+IOKAnFRoaXMgY2FuIGJlIHZhcmlvdXMgcmVhc29ucyBmb3IgdGhpczrigKbi gJ0gIHRvIOKAnFRoZXJlIGNhbiBiZSB2YXJpb3VzDQo+PiByZWFzb25zIGZvciB0aGlzOuKApuKA nQ0KPiANCj4gQWRkcmVzc2VkIGluIC0yNCB2ZXJzaW9uLg0KPiANCj4+IA0KPj4gcGFnZSAyMDoN Cj4+IA0KPj4g4oCcaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIGVudmlyb25tZW50cyB1c2luZyBhIHZh cmlldHkgc2V0IG9mIGxpbmsNCj4+IHRlY2hub2xvZ2llc+KApuKAnSBnZXQgcmlkIG9mIOKAnHNl dOKAnS4NCj4+IA0KPiBZZXMuDQo+IA0KPj4gcGFnZSAyMzoNCj4+IA0KPj4g4oCc4oCmc3VwcG9y dGVkIGJ5IHRoZSBSVENQIEV4dGVuZGVkIFJlcG9ydHMgKFhSKSBmcmFtZXdvcmsNCj4+IFtSRkMz NjExXVtSRkM2NzkyXS7igJ0gICBSRkMzNjExIHNlZW1zIHRvIGJlIGEgZnVsbCBmbGVkZ2VkIHJl ZmVyZW5jZQ0KPj4gd2hpbGUgUkZDNjc5MiBzZWVtcyB0byBqdXN0IGJlIHRleHQgb2Yg4oCcW1JG QzY3OTJd4oCdLg0KPj4gDQo+IA0KPiBUaGV5IGFyZSBib3RoIHJlbGV2YW50IHJlZmVyZW5jZXMg d2hlbiB1bmRlcnN0YW5kaW5nIHdoYXQgUlRDUCBYUiBhcmUgYW5kIHdoYXQgbWV0cmljcyBvbmUg c2hvdWxkIGNvbnNpZGVyLg0KPiANCj4gSSBwcm9wb3NlIHRvIGFkZCBhICJzZWUiIHNvIHRoYXQg dGhlIHJlc3VsdHMgYmVjb21lICIuLi4gZnJhbWV3b3JrLCBzZWUgW1JGQzM2MTFdW1JGQzY3OTJd Lg0KPiANCg0KSSB0aGluayBJIHdhcyBtaXN1bmRlcnN0b29kLCBsaWtlbHkgbXkgZmF1bHQuICBJ biB0aGUgUERGLCB0aGUgUkZDMzYxMSBzZWVtZWQgdG8gYmUgYSB0cnVlIHJlZmVyZW5jZSBpbiB0 aGUgZG9jdW1lbnQ7IGJ1dCBSRkM2NzkyIGRpZCBOT1Qgc2VlbSB0byBiZSBhIHJlZmVyZW5jZS4g IE1heWJlIGFuIGlzc3VlIGluIHRoZSBhY3R1YWwgWE1MLCBub3QgdGhlIHJlc3VsdGluZyBQREYv VFhULiAgSXQgbWF5IGJlIG5vdGhpbmcuDQoNCj4gDQo+PiBwYWdlIDI1Og0KPj4gDQo+PiBGaXJz dCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAxMSBkZWZpbmVzIGEgbnVtYmVyIG9mIFdlYlJUQyBBUEkg dGVybXMsDQo+PiBQTEVBU0UgbW92ZSB0aG9zZSAoZmFyKSBmb3J3YXJkIGluIHRoZSBkb2N1bWVu dC4g4oCcVGhlDQo+PiBNZWRpYVN0cmVhbVRyYWNrcyB3aXRoaW4gYSBNZWRpYVN0cmVhbSBuZWVk IHRvIGJlIHBvc3NpYmxlIHRvIHBsYXkNCj4+IG91dCBzeW5jaHJvbml6ZWQu4oCdICByZXdyaXRl IHRvIOKAnFRoZSBNZWRpYVN0cmVhbVRyYWNrcyB3aXRoaW4gYQ0KPj4gTWVkaWFTdHJlYW0gbWF5 IG5lZWQgdG8gYmUgc3luY2hyb25pemVkIGR1cmluZyBwbGF5IGJhY2su4oCdICBvcg0KPj4gc29t ZXRoaW5nIHNpbWlsYXIuDQo+IA0KPiBJIGhhdmUgYWRkZWQgYWxzbyBNZWRpYVN0cmVhbVRyYWNr IHRvIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uICgzKS4gQW5kIHBvcHVsYXRlZCBib3RoIE1lZGlh U3RyZWFtIGFuZCBNZWRpYVN0cmVhbVRyYWNrIHdpdGggdGV4dCBmcm9tIHRoaXMgcGFyYWdyYXBo LiBJIGhhdmUgaG93ZXZlciBub3QgcmVtb3ZlZCBhbnkgdGV4dCBmcm9tIHRoaXMgcGFyYWdyYXBo IGluIFNlY3Rpb24gMTEuDQo+IA0KPiANCnNvdW5kcyBnb29kLg0KDQo+PiANCj4+IHBhZ2UgMjY6 DQo+PiANCj4+IOKAnGZvcmNlIGFuIGVuZC1wb2ludCB0byB0byBkaXNydXB04oCdICBvbmx5IG9u ZSDigJx0b+KAnS4NCj4gDQo+IE9rDQo+IA0KPj4gDQo+PiDigJxUaGlzIGlzIG1vdGl2YXRpbmcg dGhlIGRpc2N1c3Npb24gaW4gU2VjdGlvbiA0LjnigJ0sICh5ZXMsIG5vdyBJ4oCZbQ0KPj4gcmVh bGx5IGdldHRpbmcgcGlja3ksKSBidXQgdGhlIGRpc2N1c3Npb24gd2FzIGFscmVhZHkgbW90aXZh dGVkLiAgOikNCj4gDQo+IENoYW5nZWQgdGhpcyB0bzoNCj4gDQo+IFRoaXMgaXMgbW90aXZhdGlu ZyB0aGUgdXNlIG9mIGEgc2luZ2xlIENOQU1FIGluIFNlY3Rpb24gNC45Lg0KPiANCjopDQoNCg0K Pj4gDQo+PiBwYWdlIDI3Og0KPj4gDQo+PiDigJxPcHRpbWl6YXRpb25zIG9mIHRoaXMgbWV0aG9k IGlzIGNsZWFybHkgcG9zc2libGUgYW5kIOKApuKAnSAg4oCcaXPigJ0gLT4NCj4+IOKAnGFyZeKA nQ0KPiANCj4gb2sNCj4gDQo+PiANCj4+IOKAnHJlY2VpdmluZyBtdWx0aXBsZSBNZWRpYVN0cmVh bVRyYWNrcywgd2hlcmUgZWFjaCBvZiBkaWZmZXJlbnQNCj4+IE1lZGlhU3RyZWFtVHJhY2tzIChh bmQg4oCm4oCdIHRvIOKAnCDigKYgd2hlcmUgZWFjaCBvZiAqdGhlKiBkaWZmZXJlbnQNCj4+IE1l ZGlhU3RyZWFtVHJhY2tzIOKApiDigJwNCj4gDQo+IEZpeGVkDQo+IA0KPj4gDQo+PiDigJxUaGlz IGxhdGVyIGlzIHJlbGV2YW50IHRvIGhhbmRsZSBzb21lIGNhc2VzIG9mIGxlZ2FjeSBpbnRlcm9w LuKAnSB0bw0KPj4g4oCcVGhlIGxhdGVyIGlzIHJlbGV2YW50IOKApiBsZWdhY3kgaW50ZXJvcGVy YWJpbGl0eS7igJ0NCj4+IA0KPiANCj4gT2sNCj4gDQo+IA0KPj4gcGFnZSAyODoNCj4+IA0KPj4g 4oCcLiAuIC4gRW5kcG9pbnRzIGNhbiBjb25maWd1cmUgYW5kIHVzZSBSVFAgc2Vzc2lvbnMgaXMg b3V0bGluZWQu4oCdDQo+PiBjaGFuZ2Ug4oCcaXPigJ0gdG8g4oCcYXJl4oCdDQo+IA0KPiANCj4+ IA0KPj4g4oCcIC4gLiAuIGl0IGlzIGNvbW1vbiB0byB1c2Ugb25lIFJUUCBzZXNzaW9uIGZvciBl YWNoIHR5cGUgb2YgbWVkaWENCj4+IHNvdXJjZXMgKGUuZy4gLiAuIC7igJ0gIGNoYW5nZSDigJxz b3VyY2Vz4oCdIHRvIOKAnHNvdXJjZeKAnQ0KPj4gDQo+PiBwYWdlIDMxOg0KPj4gDQo+PiDigJxU byBtYWludGFpbiBhIGNvaGVyZW50IG1hcHBpbmcgYmV0d2VlbiB0aGUgcmVsYXRpb24gYmV0d2Vl biBSVFANCj4+IHNlc3Npb25zIGFuZCBSVENQZWVyQ29ubmVjdGlvbiBvYmplY3RzIGl0IGlzIOKA puKAnSAgcmV3cml0ZSB0byBtYXliZQ0KPj4gDQo+PiDigJxUbyBtYWludGFpbiBhIGNvaGVyZW50 IG1hcHBpbmcgYmV0d2VlbiB0aGUgcmVsYXRpb25zaGlwIG9mIFJUUA0KPj4gc2Vzc2lvbnMgYW5k IFJUQ1BlZXJDb25uZWN0aW9uIG9iamVjdHMgaXQgaXMg4oCmLuKAnQ0KPiANCj4gSSBwcm9wb3Nl Og0KPiANCj4gVG8gbWFpbnRhaW4gYSBjb2hlcmVudCBtYXBwaW5nIG9mIHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiBSVFAgc2Vzc2lvbnMgYW5kIFJUQ1BlZXJDb25uZWN0aW9uIG9iamVjdHMgaXQg aXMgcmVjb21tZW5kIHRoYXQgdGhpcyBpcyBpbXBsZW1lbnRlZCBhcyBzZXZlcmFsIGluZGl2aWR1 YWwgUlRQIHNlc3Npb25zLg0KPiANCg0KbG9va3MgZ29vZC4NCg0KDQo+PiANCj4+IHBhZ2UgMzI6 DQo+PiANCj4+IOKAnFRoaXMgc2NlbmFyaW8gYWxzbyByZXN1bHRzIGluIHRoYXQgYW4gZW5kLXBv aW504oCZcyBmZWVkYmFjayBvcg0KPj4gcmVxdWVzdHMgZ29lcyB0byB0aGUgbWl4ZXLigKbigJ0g IGNoYW5nZSDigJxnb2Vz4oCdIHRvIOKAnGdv4oCdLg0KPiANCj4gb2sNCj4gDQo+PiANCj4+IOKA nG5lY2Vzc2FyaWx5IGJlIGV4cGxpY2l0bHkgdmlzaWJsZSBhbnkgUlRQIGFuZCBSVENQIHRyYWZm aWMg4oCm4oCdIHRvDQo+PiDigJxuZWNlc3NhcmlseSBiZSBleHBsaWNpdGx5IHZpc2libGUgdG8g YW55IFJUUCBhbmQgUlRDUCB0cmFmZmlj4oCdLg0KPiANCj4gWWVzDQo+IA0KPj4gDQo+PiBwYWdl IDM4Og0KPj4gDQo+PiDigJxjb21iaW5n4oCdIHRvIOKAnGNvbWJpbmluZ+KAnQ0KPj4gDQo+IA0K PiBvaw0KPiANCj4+IA0KPj4gDQo+PiAtLSBDaHJpcyBJbmFjaW8gaW5hY2lvQGNlcnQub3JnDQo+ PiANCj4+IA0KPj4gDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+IA0K DQpncmVhdC4gIEl0IGlzIGEgdmVyeSB3ZWxsIHdyaXR0ZW4gZHJhZnQuDQoNCg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24g UmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAg ICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAg ICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBT d2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KDQoNCg0KLS0NCkNocmlzIEluYWNpbw0KaW5hY2lvQGNlcnQub3JnDQoNCg0K From nobody Wed Jun 10 20:07:20 2015 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 DD8C11A876F; Wed, 10 Jun 2015 20:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 l03NxSgJz-Py; Wed, 10 Jun 2015 20:07:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A41E1A0078; Wed, 10 Jun 2015 20:07:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150611030717.14942.21451.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 20:07:17 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 11 Jun 2015 03:07:19 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-rtcweb-rtp-usage-24: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This draft looks very helpful, and I could understand it pretty well, I think. I did have a few comments. Am I reading this correctly? The following RTP and RTCP features are sometimes omitted in limited functionality implementations of RTP, but are REQUIRED in all WebRTC Endpoints: ... skipping down to ... o Support for sending and receiving RTCP SR, RR, SDES, and BYE packet types, with OPTIONAL support for other RTCP packet types unless mandated by other parts of this specification. Is this saying that OPTIONAL support is REQUIRED unless some other part of the spec says it's a MUST? or a MUST NOT? or something else entirely? In this text, Signalled bandwidth limitations, such as SDP "b=AS:" or "b=CT:" lines received from the peer, MUST be followed when sending RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal ^^^^^^ could you help me understand why this is a SHOULD, and not a MUST? its bandwidth limitations. These limitations have to be based on ^^^^^^^^^^^^^^^^^^^ known bandwidth limitations, for example the capacity of the edge ^^^^^^^^^^^^^^^^^^^^^^^^^^^ links. S0, not a 2119 MUST/REQUIRED ... is this simply recognizing that the signaled limitation has to be based on something, and the capacity of the edge links is the best upper limit that is easily available without probing? Or is it saying something else? I'd think the capacity of the edge links wouldn't be a great plan if you end up with a multi-unicast mesh with no middleboxes, for instance (but I could be wrong about that), but you might be saying that's still as good a limit as anything else. In this text, However, implementations that can use detailed performance monitoring data MAY generate RTCP XR packets as appropriate; the use of such packets SHOULD be signalled in advance. I wouldn't ask this question except that the draft has an entire section on dodgy implementations, but ... is there an unstated assumption that if the use of RTCP XR packets is signaled, the sender would respond to this information? I'm guessing "yes", and that could be fine, but I wanted to ask. I think Section 9. WebRTC Use of RTP: Future Extensions is very good, but I wonder if the first paragraph needs to be as 2119-heavy as it is. The second paragraph says what it needs to say without 2119 language. In this text, I think there's a nit. whereas it would it all three participants were part of a single ** I'm guessing this is "if"? From nobody Thu Jun 11 01:08:36 2015 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 957861ACD0D; Thu, 11 Jun 2015 01:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 8BBGQSgoEjOY; Thu, 11 Jun 2015 01:08:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 ABB9D1AC3B6; Thu, 11 Jun 2015 01:08:29 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C61CFEC0798C; Thu, 11 Jun 2015 08:08:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t5B88O61016691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jun 2015 10:08:25 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 11 Jun 2015 10:08:08 +0200 From: "DRAGE, Keith (Keith)" To: Colin Perkins , Adam Roach Thread-Topic: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 Thread-Index: AQHQo5UyIGbw77cZCECqEegNh+rEXZ2lzNmAgAAgDICAAQbP0A== Date: Thu, 11 Jun 2015 08:08:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B69728E95@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> <55786629.6060705@nostrum.com> <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> In-Reply-To: <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , Chris Inacio , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 11 Jun 2015 08:08:31 -0000 I support Colin on this. Using lower case versions of RFC 2119 terms causes its own confusions. It is usually easy to maintain clarity while avoiding this. Keith > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of=20 > Colin Perkins > Sent: 10 June 2015 19:25 > To: Adam Roach > Cc: secdir@ietf.org; rtcweb@ietf.org; iesg@ietf.org;=20 > draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org; Chris Inacio > Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 >=20 > On 10 Jun 2015, at 17:30, Adam Roach wrote: > > On 6/10/15 10:49, Magnus Westerlund wrote: > >>> page 6: > >>>=20 > >>> "This specification requires the usage of a single CNAME=20 > when sending > >>> RTP Packet Streams..." should the "require" be "REQUIRE"? > >>=20 > >> This is intended as an informational reference, thus I=20 > propose to change this to "mandates" thus avoiding the RFC2119 terms. > >=20 > > RFC 2119 doesn't remove the words "require", "must",=20 > "should", "may" and "recommend" from the English language. If=20 > all you mean is the ordinary word "require," (rather than the=20 > 2119 term "REQUIRE"), then "require" is just fine. >=20 > The RFC 2119 term is "REQUIRED", not "REQUIRES" or "REQUIRE"=20 > anyway, but we have explicitly avoided lower-case versions of=20 > RFC 2119 terms in the draft, precisely to avoid any possible=20 > confusion. >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From nobody Thu Jun 11 01:21:02 2015 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 D82201ACC87; Thu, 11 Jun 2015 01:20:57 -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 OsFkgVy0F5kv; Thu, 11 Jun 2015 01:20:56 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76501ACAD5; Thu, 11 Jun 2015 01:20:55 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-99-557944e587f5 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D4.56.04015.5E449755; Thu, 11 Jun 2015 10:20:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 10:20:53 +0200 Message-ID: <557944E3.7030809@ericsson.com> Date: Thu, 11 Jun 2015 10:20:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Chris Inacio References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvre4zl8pQg6m/mCzmtMZbzPgzkdli 4dqTjBZr/7WzW3xY+JDFgdVjxgYfjyVLfjJ5fLn8mS2AOYrLJiU1J7MstUjfLoEr43n3XbaC abwVR5Z3MjcwnuDqYuTkkBAwkXh7fiY7hC0mceHeerYuRi4OIYGjjBIL1+9ignCWM0psfNfH BlLFK6At0XdjPhOIzSKgKvH9zQtWEJtNwELi5o9GsBpRgSiJqY/XsUDUC0qcnPkEzBYRUJJY fuA2M8hQZoErjBLdi6aAJYQFbCQWzfgHtbqbUaJj6jawDZxAidMztjGC2MxAG2bOPw9ly0s0 b53NDGILAV3U0NTBOoFRcBaShbOQtMxC0rKAkXkVo2hxanFSbrqRkV5qUWZycXF+nl5easkm RmBgH9zy22AH48vnjocYBTgYlXh4F7yuCBViTSwrrsw9xCjNwaIkzjtjc16okEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsZs+Slb32VIfv0Z8WBfxI+O/aYClw48Zv5zadpPnuMH28yOJSpc /v+jpe5Recnjt5IFTr3XuEPWJ1+oMZd4afH3yMHLMkxrpD/UZfU3hm2KXc19pq3m9iqOnKW9 fAVWPye4yhwpni8b8axg8l9NUZPV3R48y3fJp9aW/9pvuskvYrXL9HcfG1SUWIozEg21mIuK EwGY56AITQIAAA== Archived-At: Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 11 Jun 2015 08:20:58 -0000 Hi Snipping it down to a single thing I want to comment on. Chris Inacio skrev den 2015-06-10 22:31: > > >> On Jun 10, 2015, at 8:49 AM, Magnus Westerlund wrote: >> >>> page 23: >>> >>> “…supported by the RTCP Extended Reports (XR) framework >>> [RFC3611][RFC6792].†RFC3611 seems to be a full fledged reference >>> while RFC6792 seems to just be text of “[RFC6792]â€. >>> >> >> They are both relevant references when understanding what RTCP XR are and what metrics one should consider. >> >> I propose to add a "see" so that the results become "... framework, see [RFC3611][RFC6792]. >> > > I think I was misunderstood, likely my fault. In the PDF, the > RFC3611 seemed to be a true reference in the document; but RFC6792 did NOT seem to be a reference. Maybe an issue in the actual XML, not the resulting PDF/TXT. It may be nothing. I haven't looked at the PDF generated at all before. It appear as a bug in the generation. Both these are xref items in the XML source. So it must be something when putting two xref after each other and no display text. I have reported this as a bug in the XML2RFC tracker. cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 11 01:26:13 2015 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 5BC9B1ACCE1; Thu, 11 Jun 2015 01:26:08 -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 ouh4r_ayixIA; Thu, 11 Jun 2015 01:26:07 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A151ACC92; Thu, 11 Jun 2015 01:26:06 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-67-557945f89e35 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.27.04015.8F549755; Thu, 11 Jun 2015 10:25:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 10:25:28 +0200 Message-ID: <557945F8.9080504@ericsson.com> Date: Thu, 11 Jun 2015 10:25:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Colin Perkins , Adam Roach References: <24C0D45F-DBF0-43A4-A2D6-B086F7EC368F@cert.org> <55785CA7.4090005@ericsson.com> <55786629.6060705@nostrum.com> <1F558D60-16EB-40B5-B7F8-C51FC2CE604B@csperkins.org> <949EF20990823C4C85C18D59AA11AD8B69728E95@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B69728E95@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvra6MW2WowYSvShZ7/i5it1j+8gSj xZzWeIsZfyYyWyxce5LR4mnjWUaLtf/a2S0+LHzI4sDh0fpsL6vHjA0+HtPu32fzWLLkJ5PH rJ1PWDy+XP7MFsAWxWWTkpqTWZZapG+XwJVxqecBW8E5zoppM1cxNjBeY+9i5OSQEDCRuL1l DSuELSZx4d56ti5GLg4hgaOMEpMmzIdyljNKbHu0E6yDV0BbovfbCzCbRUBVYu/yvywgNpuA hcTNH41sILaoQJTE1MfrWCDqBSVOznwCZosI1Es0tR5lArGZBb4wStz4xQ1iCwu4Suz92cgI sayBSWLmvmNgDZwCsRLPG1uBlnEANdhLPNhaBtErL9G8dTYziC0EdE9DUwfrBEbBWUjWzULo mIWkYwEj8ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwHg4uOW3wQ7Gl88dDzEKcDAq8fAu eF0RKsSaWFZcmXuIUZqDRUmcd8bmvFAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjJ0B0y+U P+Nw4rpVbp7OuJDX5fvy2vsC5v2iJ6eW2t08IJN0/4POj6Qkg3pmtRbGj29vN4nPceBdt3ct d95n1VLJWGPpp93taeqs6pJvVez1FrzZ98n1EYvvC7H4svqNprWnPadvv8MkFiPb7pJlf+HZ zxdLbX7vqJFvW7j26vzrnc379yg+UmIpzkg01GIuKk4EAFTBN7BoAgAA Archived-At: Cc: "draft-ietf-rtcweb-rtp-usage-23@tools.ietf.org" , Chris Inacio , "rtcweb@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [rtcweb] sector review of draft-ietf-rtcweb-rtp-usage-23 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, 11 Jun 2015 08:26:08 -0000 DRAGE, Keith (Keith) skrev den 2015-06-11 10:08: > I support Colin on this. > > Using lower case versions of RFC 2119 terms causes its own confusions. I have heard some people argue that also the lower case usage have the RFC 2119 meaning. The RFC 2119 to some degree support such an interpretation, but is not more explicit than this. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. > > It is usually easy to maintain clarity while avoiding this. > Yes, and the rewrite here was trivial and conveys the same meaning. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 11 01:33:12 2015 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 CBA871B2AA3 for ; Thu, 11 Jun 2015 01:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 8tNMj1vTLlnQ for ; Thu, 11 Jun 2015 01:33:09 -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 ED3A01B2A10 for ; Thu, 11 Jun 2015 01:33:08 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-43-557947c26ec7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.FA.28096.2C749755; Thu, 11 Jun 2015 10:33:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Thu, 11 Jun 2015 10:33:06 +0200 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: Sean Turner , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWeb WG JSEP-focused Virtual Meeting - Thursday 6/18, 9-11AM PDT Thread-Index: AQHQmhz62GKFBKQHyEOPLVIfqYCD7w== Date: Thu, 11 Jun 2015 08:33:05 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D26C2DF@ESESSMB209.ericsson.se> References: 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: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre4h98pQgy2nDS3W/mtnt9hxbgKL A5PHnTkfWD2WLPnJFMAUxWWTkpqTWZZapG+XwJUxf4pjwVy2ijMPHrI1MPazdjFyckgImEgs W34AyhaTuHBvPVsXIxeHkMBRRokTyyawQziLGSWWP98HlOHgYBMIlmj66wbSICLgLnGg4TUT iC0sECVx6PZBFoh4tMTbdeeZIGw9iWf7b7KB2CwCqhLTF/Qyg9i8Ar4Sm1p62UFsIQFrienT LoAdwQh0xPdTa8B6mQXEJW49mc8EcZyAxJI955khbFGJl4//sYKcIyGgKLG8Xw6i3EDi/bn5 zBC2tsSyha+hVglKnJz5hGUCo8gsJFNnIWmZhaRlFpKWBYwsqxhFi1OLi3PTjYz0Uosyk4uL 8/P08lJLNjECY+Hglt9WOxgPPnc8xCjAwajEw7vgdUWoEGtiWXFl7iFGaQ4WJXHeGZvzQoUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwVkb+ESuN80xbXHt0M9edm9W1a2w8Q37KfHoiNIHL 8v+xCSu/R70UXv+9qzimcrl54im18GDV11dbxDS9ZBKPnF1Sf8ZHZFND2czPnVsuyB9fv8st 8UxtsPPpzE3vf57knK27rT14yVIuF+9pZjqSh8J+M3BVFa6c9zFOQWfyg+mTjM5tffb1thJL cUaioRZzUXEiAKQe98ZmAgAA Archived-At: Subject: Re: [rtcweb] RTCWeb WG JSEP-focused Virtual Meeting - Thursday 6/18, 9-11AM PDT 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, 11 Jun 2015 08:33:11 -0000 Will there be an agenda sent out? I'd be interested to know if the =0A= purpose is to deal with Issues in general, focus on a specific area or =0A= something else.=0A= =0A= Stefan=0A= =0A= =0A= On 29/05/15 16:37, Sean Turner wrote:=0A= > Hi,=0A= >=0A= > Doodle has spoken and we have a majority preference from the=0A= > participants in the poll for the next RTCweb WG JSEP-focused Virtual=0A= > Interim to be held on Thursday 6/18, 9-11AM PDT. Please mark this=0A= > date and time in your schedules. I will ask the Secretariat for a=0A= > Webex session =96 please stay tuned.=0A= >=0A= > Thanks and Regards,=0A= >=0A= > spt _______________________________________________ rtcweb mailing=0A= > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From nobody Thu Jun 11 01:40:22 2015 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 566211A8B84; Thu, 11 Jun 2015 01:40:20 -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 6-Y-zSPtb6rI; Thu, 11 Jun 2015 01:40:19 -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 60B2B1A8837; Thu, 11 Jun 2015 01:40:18 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-9a-5579497007c7 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AD.4C.28096.07949755; Thu, 11 Jun 2015 10:40:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 10:40:16 +0200 Message-ID: <5579496E.9080000@ericsson.com> Date: Thu, 11 Jun 2015 10:40:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Barry Leiba References: <20150610104740.4842.50101.idtracker@ietfa.amsl.com> <55785EA0.6000803@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+JvrW6BZ2Wowccn+haHFl9itZjxZyKz xdp/7ewOzB4tq3qZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHiw0vWgjNiFbuurWVsYJwl1MXI ySEhYCIxb/YzNghbTOLCvfVANheHkMBRRomGd2uYQRJCAssZJea8qOxiZOfgFdCWuKIAEmUR UJV4cHUKWCubgIXEzR+NYLaoQJTE1MfrWEBsXgFBiZMzn4DZIgKaEs8/T2ECsZkFHCVWTloH Vi8skCLx6esVJoi1Sxkl5n5fzA6S4BQIlHh7Zi4bRIOFxMz55xkhbHmJ5q2zoU7Tlmho6mCd wCg4C8m+WUhaZiFpWcDIvIpRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMGwPbvlttYPx4HPH Q4wCHIxKPLwLXleECrEmlhVX5h5ilOZgURLnnbE5L1RIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDY1h73z/ek/O3XQ7klH23+4r5jykPuvfU5K/7F7Q3X7JM4eVxG44V73e9NLOepds0442J TQrXgzBG7ukCNhUuuziljnqbcrqvuDf7yazPst3sFewP6zM/PDyT23vEvuDw3lnbX278tjWd hSG6Nr8ysyN5cr/OhT7hTyrPXPLrGyMzc5aWC6kfUmIpzkg01GIuKk4EAEZGlcE8AgAA Archived-At: Cc: "rtcweb@ietf.org" , The IESG Subject: Re: [rtcweb] Barry Leiba's No Objection on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 11 Jun 2015 08:40:20 -0000 Barry Leiba skrev den 2015-06-10 18:07: >> However, my personal view is that IETF need to be able to reference concept >> and basic definitions from informational documents without making it >> normative references. Otherwise we will have a lot of things in the downref >> registry and not be able to find when we end up in actual real issues with >> protocol mechanisms and their source and maturity. That is why I intended to >> leave draft-ietf-rtcweb-overview as an informational reference. > > Well, I think normative references are all those that you *need* in > order to understand the document. If you don't read rtcweb-overview > and understand the terminology in it... would you be able to properly > understand this document? So the overview is the entry point into the whole set of RTCWEB WG documents. It gives high level understanding of the relation of all the components. The RTP usage I think only one real include, which is the definition of WebRTC endpoint. > > That said, I'll leave it to your judgment here, and won't argue the > point further. I will change this to a normative reference, mostly because I have a faulty memory and overview is actually targeted to become an applicability statement, i.e. standards track. Thus, this whole circus around downrefs don't apply. From my point of view the overview is important, but it is only this definition you truly need to understand to implement correctly the RTP stack. However, you clearly need to understand where the piece fits. > > [And as a side point, I'm working with some other folks on an update > to BCP 97. The update would *not* require that these sorts of > documents go into the downref registry, but would instead give > judgment to the IESG on the right way to handle this while making sure > that normative references were sufficiently mature. Because I agree > that the downref registry was never *meant* for documents that are > only used for terminology.] I think that is mostly good. But, we clearly have had a shift in interpretation of what a normative reference is from when I started being on the IESG 2006 (When the IESG statement was written) and now. I hope this means that also the expectations are a bit more explicitly written up on what an normative reference is. Thus avoiding discussions due to shifts in interpretation. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 11 05:04:39 2015 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 867EC1ACDCD; Thu, 11 Jun 2015 05:04:37 -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 L855TyKQwmwp; Thu, 11 Jun 2015 05:04:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223B81ACDC7; Thu, 11 Jun 2015 05:04:31 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-ae-5579794d956c Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.A4.04015.D4979755; Thu, 11 Jun 2015 14:04:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 14:04:29 +0200 Message-ID: <55797949.2030004@ericsson.com> Date: Thu, 11 Jun 2015 14:04:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Campbell References: <20150609030408.24606.8383.idtracker@ietfa.amsl.com> <5576A8FE.2060001@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM+Jvra5fZWWoQfMWbov5nafZLWb8mchs sfZfO7sDs8eSJT+ZPGbtfMISwBTFZZOSmpNZllqkb5fAlXG+fzlzwTmviverjzA2ME6z7mLk 5JAQMJHYu+spC4QtJnHh3nq2LkYuDiGBo4wSH459ZoFwljNKzPi/kg2kildAW2Lvg6VgHSwC qhIzH6xnBbHZBCwkbv5oBKsRFYiSmPp4HQtEvaDEyZlPwGwRASWJ581bwWxmAX2JJ29WM4PY wgIxElMuL2WHWDaZUWLplrtgCU4Be4m3a7rZIBosJGbOP88IYctLNG+dDVYjBHRQQ1MH6wRG wVlI9s1C0jILScsCRuZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIHBe3DLb4MdjC+fOx5i FOBgVOLhXfC6IlSINbGsuDL3EKM0B4uSOO+MzXmhQgLpiSWp2ampBalF8UWlOanFhxiZODil GhgN20TzpSqsY+bNu5P/++TEq6q9jtueH6jZOntG+JLolbFrX+ke5m/8XnLlkW7dsYuXf3xV KEr3WS248a3J4pVsZyo37J+V8n3KFdakiJKMexP6CrIZlkrtkSqeEu2xpYBFOzrS60tMtemq XV/+hS3fbffprWqARq/9o7VJGgkicy7NNl16a7egEktxRqKhFnNRcSIApGn8kz8CAAA= Archived-At: Cc: rtcweb@ietf.org, The IESG Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 11 Jun 2015 12:04:37 -0000 Hi, Inline Ben Campbell skrev den 2015-06-09 16:32: > On 9 Jun 2015, at 3:51, Magnus Westerlund wrote: > >> Hi Ben, >> >> Thanks for the review, some inline comments. Will address these after >> Thursday when we know the rest of IESGs views. >> > > Thanks for the response. Comments inline. > > [...] > >>> Substantive: >>> >>> -- 4.9: The discussion of RTCPeerConnection in this section seems to >>> need >>> a normative reference to [W3C.WD-webrtc-20130910] (or a local >>> explanation, if there are issues normatively referencing that doc.) >> >> Do I understand that you want a reference in the second paragraph at >> the mentioning of RTCPeerConnection? As it is reference in the >> previous paragraph, I assumed that people would not be confused on >> what we talk about. >> > > I'm okay with the reference where it is--my comment was more about > normativity (see comment to next paragraph) > >> I guess the second issue is that the reference is classified as >> informative and should be normative. Changing the classification is >> simple, it will however create a need to ensure that the publication >> of this document is held until the W3C document reaches Recommendation >> status if I understand the rules and recommendations correctly. >> > > I think the reader will at least need a high level understanding of the > meaning of RTCPeerConnection to implement the normative requirements in > this section. If the W3C doc is not going to be sufficiently mature in > the immediate future, it might be good enough to put a couple of > sentences in this doc about the meaning of RTCPeerConnection. (The full > interface spec is probably not needed.) I think might have to up level this discussion a bit. We always know that we where going to need to put in normative references somewhere between the IETF RFCs and the W3C WebRTC specifications. I think it is time we realize the implications of that. And I think this document, JSEP, and Overview at least are going to need to have correct references to the W3C specifications. Thus, I would suggest that we convert them to normative references and then let them hang in missref until the are ready to publish. The W3C WebRTC spec currently have a lot of normative references to drafts in the rtcweb wg, including this. So RFC-editor and W3C equivalent will need to have a coordination step. My suggestion is that we do change the W3C references to normative. > >>> >>> -- 5.1: This section seems to need a normative reference to >>> topologies-update. There is normative language here to the effect of >>> “Don’t do these things†where it seems like one needs to read that >>> doc to >>> understand what the “things†mean. >> >> I do understand the reasoning behind your comment. I personally do not >> agree the need for using normative references for documents that >> import a term for a concept. We already had this discussion around the >> topologies document's status. > > (I'm not sure if you meant "do _not_ understand", but I expected you to > disagree :-) ) I actually mean I do understand some of the thinking, I simply think it is flawed and has downsides making me have another view on what is to be considered normative references. > > I realize there is not universal agreement on whether BCP 97 applies to > terminology. I think it can in some cases. But in this case, I think we > are going beyond just terminology. The topology doc describes structure > and behavior associated with each topology. I assume it is informational > because it is descriptive rather than prescriptive. I will agree with you that the topology will be used in such way that it is often normative. > >> >> I have no issue with reclassifying the reference, but I do note that >> we will have to re-run the IETF last call as this will now be a down-ref. > > Yes, that is an issue. You will note I made this a comment, not a > discuss :-) I will leave it up to you guys and Alissa to decide if this > is needed badly enough to go through another LC. (For the record, > there's some work going on to update 97 to allow more discretion around > this sort of thing without triggering pointlessly repeated last calls.) Lets get the downref last call out of the way as soon as we have updated the draft. That way the WG (and rest of IETF) will have two weeks to review the changes. > >> >>> >>> -- 7.1, first paragraph: "applications MUST also implement congestion >>> control to >>> allow them to adapt to changes in network capacity." >>> >>> Is that the aformentioned not-yet-standardized congestion control >>> algorithm, or something else? >> >> As we have no standardized congestion control yet, we can't point to >> anything. But, an implementation must implement something, even if >> completely proprietary. > > It would be helpful to either clarify the "even if proprietary" part, or > perhaps move this sentence closer to the bit about no standardized > mechanism. (But this is not a show stopper.) Ok, I propose that we add this sentence: "The congestion control algorithm will have to be proprietary until a standardized congestion control algorithm is available." into the first paragraph in 7.1: WebRTC Endpoints MUST implement the RTP circuit breaker algorithm that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP circuit breaker is designed to enable applications to recognise and react to situations of extreme network congestion. However, since the RTP circuit breaker might not be triggered until congestion becomes extreme, it cannot be considered a substitute for congestion control, and applications MUST also implement congestion control to allow them to adapt to changes in network capacity. The congestion control algorithm will have to be proprietary until a standardized congestion control algorithm is available. Any future RTP congestion control algorithms are expected to operate within the envelope allowed by the circuit breaker. Does this satisfies your concerns? > >> >> >>> >>> -- 11, 2nd paragraph from end: >>> >>> It seems like the msid reference should be normative. >> >> Our intention was to keep this informative. Therefore the chosen style >> of writing that sentence. The actual normative inclusion of MSID into >> the WebRTC solution is done by JSEP. > > Okay. It might be helpful, but not required, to state this sentence in > the form of "[jsep] specifies that..." > So what you want is that paragraph to read more like this? Javascript Session Establishment Protocol [I-D.ietf-rtcweb-jsep] specifies that the binding between the WebRTC MediaStreams, MediaStreamTracks and the SSRC is done as specified in "Cross Session Stream Identification in the Session Description Protocol" [I-D.ietf-mmusic-msid]. The MSID document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to map unknown source packet stream SSRCs to MediaStreamTracks and MediaStreams. > >> >>> >>> -- 12.1.3: >>> >>> seems like a mention of draft-ietf-dart-dscp-rtp might be in order now. >>> IIRC, when I did a gen-art review on a much older version, the thought >>> was that if draft-ietf-dart-dscp-rtp was far enough along when it was >>> time to publish this draft, it would make sense to add a mention. >>> It's in >>> the RFC editor queue now, in MISSREF on a dependency that I think this >>> draft shares. >> >> The TSVWG document referenced do normatively reference the DART >> document. But, we could include the DART document in the same sentence >> as the TSVWG document. > > I'm okay leaving it to the deeper conversation in the TSVWG doc. I > mainly mentioned it because I had thought the intent was to add the > mention here if the dart draft was sufficiently far along in the process > when this draft was submitted. Actually, I think I found a simple way of referencing it, and it is relevant in that discussion. So the sentence is proposed to read: However, depending on the QoS mechanism and what markings that are applied, this can result in not only different packet drop probabilities but also packet reordering, see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for further discussion. > >> >>> >>> -- 13: 3rd paragraph: >>> >>> Isn't that security solution MTU as well as MTI? If so, it might be >>> worth >>> mentioning it here. >> >> You mean Mandatory to Use, not Maximum Transmission Unit, don't you? >> Yes, it is mandatory to use, we can make that clear. >> > > Yes, mandatory to use. :-) > So text proposed to be changed to. A mandatory to implement and use media security solution is created by combining this secured RTP profile and DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of [I-D.ietf-rtcweb-security-arch]. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 11 07:45:38 2015 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 5BD761B2F7B; Thu, 11 Jun 2015 07:45:34 -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 DEaTb5wrlu2x; Thu, 11 Jun 2015 07:45:32 -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 7C2471B2F61; Thu, 11 Jun 2015 07:45:31 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-17-55799f098546 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AF.F2.17665.90F99755; Thu, 11 Jun 2015 16:45:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Thu, 11 Jun 2015 16:45:29 +0200 Message-ID: <55799F06.5060101@ericsson.com> Date: Thu, 11 Jun 2015 16:45:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Spencer Dawkins , The IESG References: <20150611030717.14942.21451.idtracker@ietfa.amsl.com> In-Reply-To: <20150611030717.14942.21451.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+JvrS7n/MpQg+UTTCxm/JnIbLH2Xzu7 xbIpe5gdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsEroy+zS2MBT8NK/bf6mFpYNyi1sXI ySEhYCIx7/Q+NghbTOLCvfVANheHkMBRRomH09qYIJzljBKrbr1gAqniFdCW+HypCayDRUBV Yn/nHGYQm03AQuLmj0awuKhAlMTUx+tYIOoFJU7OfAJmiwj4SlyZvBSshllAVOLVwylgvcIC cRLXTrUB2RxAyxwl1u3NBAlzCjhJ/JlzhxUkzCxgL/FgaxlEp7xE89bZYJ1CQNc0NHWwTmAU nIVk2SyEjllIOhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzag1t+6+5gXP3a8RCj AAejEg/vgtcVoUKsiWXFlbmHGKU5WJTEeWdszgsVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnV wKi6Tu6fw92cip3MUfWHr6y+czpng2f5s+9ukz6/fibBYcPye4H7EsnpIZ98cgueT42+UxSR dvqIuz870+FVqVa5tVeTjuzhVO5ZX1jgHr18q4iawLETl4tOz516YkaReOG6gvpTF+4KvJdV 47qoYSu3MehkoFbBI+5TvknBjBafrrvOrzF+e0eJpTgj0VCLuag4EQBuPHqxOwIAAA== Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 11 Jun 2015 14:45:34 -0000 Hi, Please see inlien. Spencer Dawkins skrev den 2015-06-11 05:07: > Spencer Dawkins has entered the following ballot position for > draft-ietf-rtcweb-rtp-usage-24: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This draft looks very helpful, and I could understand it pretty well, I > think. > > I did have a few comments. > > Am I reading this correctly? > > The following RTP and RTCP features are sometimes omitted in limited > functionality implementations of RTP, but are REQUIRED in all WebRTC > Endpoints: > > ... skipping down to ... > > o Support for sending and receiving RTCP SR, RR, SDES, and BYE > packet types, with OPTIONAL support for other RTCP packet types > unless mandated by other parts of this specification. > > Is this saying that OPTIONAL support is REQUIRED unless some other part > of the spec says it's a MUST? or a MUST NOT? or something else entirely? So RTCP packet type SR, RR ,SDES and BYE are REQUIRED (following the top statement), but the other RTCP packet types are OPTIONAL unless mandated explicitly further down in the document. Do you want us to rewrite this so that it is clearer that the second part is just a note that the not explicitly enumerated packet types are OPTIONAL? o Support for sending and receiving RTCP SR, RR, SDES, and BYE packet types. Note, that the other RTCP packet types are OPTIONAL to support unless mandated by other parts of this specification. > > In this text, > > Signalled bandwidth limitations, such as SDP "b=AS:" or > "b=CT:" lines received from the peer, MUST be followed when sending > RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal > ^^^^^^ > could you help me understand why this is a SHOULD, and not a MUST? > > > its bandwidth limitations. These limitations have to be based on > ^^^^^^^^^^^^^^^^^^^ > known bandwidth limitations, for example the capacity of the edge > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > links. > > S0, not a 2119 MUST/REQUIRED ... is this simply recognizing that the > signaled limitation has to be based on something, and the capacity of the > edge links is the best upper limit that is easily available without > probing? Or is it saying something else? I'd think the capacity of the > edge links wouldn't be a great plan if you end up with a multi-unicast > mesh with no middleboxes, for instance (but I could be wrong about that), > but you might be saying that's still as good a limit as anything else. The reason for a SHOULD is that it may not know. Then signalling a limitation it doesn't know is strange. Therefore the should. If one considers how these figures are created in other applications, they are often based on knowledge about the highest intended to be used bit-rate for any of the offered codecs and the number of streams are usually known. For WebRTC that is less certain. Thus, here one should offer a limit that is more related to what one actually know is a limitation for what one is capable of receiving. Thus maximum number of streams times highest codec rate is possibilities. But that does not provide good figures for video either. So it is fiddly in how an implementation populate the field well. > > In this text, > > However, implementations that can use > detailed performance monitoring data MAY generate RTCP XR packets as > appropriate; the use of such packets SHOULD be signalled in advance. > > I wouldn't ask this question except that the draft has an entire section > on dodgy implementations, but ... is there an unstated assumption that if > the use of RTCP XR packets is signaled, the sender would respond to this > information? I'm guessing "yes", and that could be fine, but I wanted to > ask. If RTCP XR is signalled, then it is a request to send those RTCP XR attributes, i.e. the consumer requests them to be sent. (unless recvonly direction where it is informative what one could report) Thus, yes if one request them one can assume that endpoint has some use for them. However, because of this style of signalling and multiparty scenarios it is a possibility that RTCP XR are included and forward to a particular endpoint. The intention is that one should signal and agree on what is being sent, but it can't be considered erroneous if an RTCP XR packet showed up unasked for. I would note that if any specific response are expected from the reception of an RTCP XR that would need to be specified somewhere. > > I think Section 9. WebRTC Use of RTP: Future Extensions is very good, > but I wonder if the first paragraph needs to be as 2119-heavy as it is. > The second paragraph says what it needs to say without 2119 language. Yes, I agree that these RFC 2119 could be replaced. MUST -> have to SHOULD (remove) Any issues with changing this? > > In this text, I think there's a nit. > > whereas it would it all three participants were part of a single > ** I'm guessing this is "if"? Yes, it is a nit. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jun 12 01:33:17 2015 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 F27201A88FE for ; Fri, 12 Jun 2015 01:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, 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 HUa-dfJtMwr1 for ; Fri, 12 Jun 2015 01:33:14 -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 9A9541A88DC for ; Fri, 12 Jun 2015 01:33:13 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-78-557a9947af6f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.63.17665.7499A755; Fri, 12 Jun 2015 10:33:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.72]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Fri, 12 Jun 2015 10:33:10 +0200 From: Christer Holmberg To: Magnus Westerlund , Harald Alvestrand , Simon Perreault , Roman Shpount Thread-Topic: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching Thread-Index: AQHQnfoTGRvazoDt2kK99KUvVw7qVJ2bFC4AgAGh8QCABXxAgIAACIUAgAAE8YCAAE2yAIAAB9iAgAAHRoCAAAGqAIAAALgAgAEdq4CABNqN0A== Date: Fri, 12 Jun 2015 08:33:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8BEE5F@ESESSMB209.ericsson.se> References: <556EF4F9.1060700@ericsson.com> <556F5E5C.5080600@alvestrand.no> <557556ED.8050206@ericsson.com> <55755E12.8020201@alvestrand.no> <55756237.6060206@ericsson.com> <5575A364.7060900@jive.com> <5575A9F9.5030504@ericsson.com> <5575B013.3030701@alvestrand.no> <5575B178.1040309@jive.com> <5575B212.3070004@alvestrand.no> <5576A1B5.1040508@ericsson.com> In-Reply-To: <5576A1B5.1040508@ericsson.com> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvra77zKpQgxtrlSyO9XWxWcy4MJXZ Yu2/dnaL61dCHVg8rky4wuqxZMlPJo9/c54ye9yaUhDAEsVlk5Kak1mWWqRvl8CV8Wv9UuaC CXIVJ/rOsDYwrpHtYuTkkBAwkfjX2sUGYYtJXLi3Hsjm4hASOMoo0dG4CcpZzCjx79xqxi5G Dg42AQuJ7n/aIHERgXWMEo++bmYG6WYWUJe4s/gcO4gtLOAr0fbmIBNIvYhAgETLXh6QsIhA ncTKk1tZQWwWAVWJ7vYXYDYvUPmzlT0sELt2MEvcfHAErJdTQEdi+Zs4kBpGoOO+n1rDBLFK XOLWk/lMEEcLSCzZc54ZwhaVePn4HytIq4SAksS0rWkgJrOApsT6XfoQnYoSU7ofskNsFZQ4 OfMJywRGsVlIhs5C6JiFpGMWko4FjCyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQKj6+CW 37o7GFe/djzEKMDBqMTDq2BbFSrEmlhWXJl7iFGag0VJnHfG5rxQIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYzrXef5HopY8MN3WybvAwHhwvSVtz2TLt24yRLg8tn8pMT21gUiNrPes1+3 7XnU+zvpdrXMRIet/3wdJr43VlLVzT0qWZSnULNkX+yFsCmPeGTZLuYc54jZasKbNk9RUphj LtvEfRzLHi74ZWPtsmQeE8/Ups9lohVvpaY/PvnxyjJGiVf3ol8rsRRnJBpqMRcVJwIA45+Q q48CAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: Issues with a=ssrc and RTP payload type switching 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, 12 Jun 2015 08:33:16 -0000 SGksDQoNCktlZXAgaW4gbWluZCB0aGF0IHdoYXRldmVyIGNoYW5nZXMgd2UgZG8gaW4gSlNFUCBt dXN0IGJlICJjb21wYXRpYmxlIiB3aXRoIEJVTkRMRSA6KQ0KDQpIb3dldmVyLCBCVU5ETEUgY3Vy cmVudGx5IGRvZXNuJ3QgbWFuZGF0ZSB0aGUgdXNhZ2Ugb2YgdGhlIFNEUCAnc3NyYycgYXR0cmli dXRlLCBidXQgaXQgZG9lcyBoYXZlIHRoZSBmb2xsb3dpbmcgcnVsZSBvbiBTU1JDIHVzYWdlOg0K DQoJbyAgQSBnaXZlbiBTU1JDIE1VU1QgTk9UIHRyYW5zbWl0IFJUUCBwYWNrZXRzIHVzaW5nIHBh eWxvYWQgdHlwZXMNCiAgICAgIAl0aGF0IG9yaWdpbmF0ZSBmcm9tIGRpZmZlcmVudCBidW5kbGVk ICJtPSIgbGluZXMuDQoNCkhvd2V2ZXIsIHRoYXQgZG9lc24ndCBzZWVtIHRvIGJlIHJlbGF0ZWQg dG8gdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFnbnVzIFdlc3Rlcmx1bmQNClNlbnQ6IDkuIGtl c8Oka3V1dGEgMjAxNSAxMToyMA0KVG86IEhhcmFsZCBBbHZlc3RyYW5kOyBTaW1vbiBQZXJyZWF1 bHQ7IFJvbWFuIFNocG91bnQNCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBKU0VQOiBJc3N1ZXMgd2l0aCBhPXNzcmMgYW5kIFJUUCBwYXlsb2FkIHR5cGUgc3dpdGNo aW5nDQoNCkhhcmFsZCBBbHZlc3RyYW5kIHNrcmV2IGRlbiAyMDE1LTA2LTA4IDE3OjE3Og0KPiBE ZW4gMDguIGp1bmkgMjAxNSAxNzoxNSwgc2tyZXYgU2ltb24gUGVycmVhdWx0Og0KPj4gTGUgMjAx NS0wNi0wOCAwOTowOSwgSGFyYWxkIEFsdmVzdHJhbmQgYSDDqWNyaXQgOg0KPj4+IFRoaXMgaGFz IGFub3RoZXIgaW1wbGljYXRpb246DQo+Pj4NCj4+PiBXaGVuIGRvaW5nIFBUIHN3aXRjaGluZyBm b3IgY29tZm9ydCBub2lzZSwgeW91IE1VU1QgaGF2ZSBhIENOIHdpdGggDQo+Pj4gdGhlIHNhbWUg Y2xvY2sgcmF0ZSBhcyB5b3VyIG5vcm1hbCBhdWRpbyBjb2RlYy4NCj4+Pg0KPj4+IENOIGlzIGV4 YWN0bHkgdGhlIHR5cGUgb2YgUFQtc3dpdGNoaW5nIHRoYXQsIGlmIGl0IG9jY3VycyBhdCBhbGws IA0KPj4+IG9jY3VycyB2ZXJ5IGZyZXF1ZW50bHkuDQo+Pg0KPj4gSSdtIG5vdCBmb2xsb3dpbmcu IFdlJ3JlIGRpc2N1c3NpbmcgZ2VuZXJhdGluZyBhIG5ldyBTU1JDIG9uIGNsb2NrIA0KPj4gcmF0 ZS1zd2l0Y2hpbmcsIG5vdCBvbiBQVC1zd2l0Y2hpbmcuIEZvciB0aGUgQ04gZXhhbXBsZSwgeW91 IHdvdWxkIA0KPj4gdHlwaWNhbGx5IGluY2x1ZGUgaW4geW91ciBTRFAgb25lIENOIHBheWxvYWQg dHlwZSBwZXIgcG9zc2libGUgY2xvY2sgDQo+PiB0eXBlIHNvIHRoYXQgeW91IGNhbiBzd2l0Y2gg cGF5bG9hZCB0eXBlcyB3aXRob3V0IHN3aXRjaGluZyB0aGUgY2xvY2sgcmF0ZS4NCj4NCj4gWWVw LiBJdCdzIG9ubHkgYmVjYXVzZSBJJ3ZlIHNlZW4gU0RQIHRyeWluZyB0byBtYXRjaCBDTi84MDAw IHdpdGgNCj4gT1BVUy80ODAwMCB0aGF0IEknbSBtZW50aW9uaW5nIGl0IC0gaXQncyBvYnZpb3Vz LCBidXQgb25seSBhZnRlciBpdCdzIA0KPiBiaXR0ZW4geW91Lg0KPg0KDQpZZXMsIHRoaXMgaXMg bGlrZWx5IG9uZSBvZiB0aGVzZSB0aGluZ3MgdGhhdCB0aGUgb25lcyB0aGF0IGNvbnNpZGVyZWQg dGhlIGlzc3VlcyBzZWUgYXMgb2J2aW91cywgYnV0IGlzIGluIGZhY3Qgbm90IHVudGlsIHlvdSBh Y3R1YWxseSB0cmllZCBpdCBhbmQgdGhlcmVmb3JlIGNvdWxkIGhhdmUgYmVuZWZpdGVkIGZyb20g YSBub3RlIGFib3V0IHRoZSBuZWVkIGZvciBoYXZpbmcgb25lIFBUIGNvbmZpZ3VyYXRpb24gcGVy IHRpbWVzdGFtcCByYXRlIHVzZWQgYnkgdGhlIGNvZGVjcyB0aGF0IG1heSB1c2UgdGhlIENOLg0K DQpBcyB0aGUgUlRQIHVzYWdlIGlzIGluIElFU0cgcmV2aWV3LCBJIGFtIGhlc2l0YW50IHRvIGFk ZCBzdWNoIGRpc2N1c3Npb24gaW50byB0aGUgUlRQIHVzYWdlIGRvY3VtZW50LiBBcyBpdCBpcyBy ZWFsbHkgYSBjb25maWd1cmF0aW9uIGlzc3VlLCBJIHRoaW5rIGl0IGNhbiBiZSBkaXNjdXNzZWQg aW4gSlNFUCwgYnV0IHRoZSBhdWRpbyBkcmFmdCBtaWdodCBiZSBhbiBldmVuIGJldHRlciBmaXQg YWRkaW5nIHRvIHRoZSBDTiB0ZXh0Lg0KDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmlj c3NvbiBSZXNlYXJjaCBFQUIvVFhNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAgICAg ICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCkbDpHLDtmdhdGFuIDYgICAgICAgICAg ICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2Vk ZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRj d2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From nobody Fri Jun 12 04:27:42 2015 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 903581A90B0; Fri, 12 Jun 2015 04:27:40 -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 B7q-wgorEf9x; Fri, 12 Jun 2015 04:27:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2A1A90A6; Fri, 12 Jun 2015 04:27:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612112739.17037.10147.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 04:27:39 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-25.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: Fri, 12 Jun 2015 11:27:40 -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-25.txt Pages : 45 Date : 2015-06-12 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: https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-25 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 Fri Jun 12 04:31:39 2015 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 009D61A9098 for ; Fri, 12 Jun 2015 04:31:37 -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 jTVhpNna8UTh for ; Fri, 12 Jun 2015 04:31:34 -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 5FE0A1A9092 for ; Fri, 12 Jun 2015 04:31:34 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-dd-557ac3147013 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.48.28096.413CA755; Fri, 12 Jun 2015 13:31:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Fri, 12 Jun 2015 13:31:32 +0200 Message-ID: <557AC310.5000007@ericsson.com> Date: Fri, 12 Jun 2015 13:31:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: References: <20150612112739.17037.10147.idtracker@ietfa.amsl.com> In-Reply-To: <20150612112739.17037.10147.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42KZGfG3VlfkcFWowb6zuhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+KHkywF38Ur3m06xNTA+ESoi5GTQ0LAROLw/o+MELaYxIV7 69lAbCGBo4wSVzZ6djFyAdnLGSXm/7oBVsQroC3x7UA/E4jNIqAqMfHBBXYQm03AQuLmj0aw ZlGBKImpj9exQNQLSpyc+QTMFhEQlXj9eBoriC0s4CIxedItRohljhJrZi9i7mLk4OAUcJJ4 fkAJxGQWsJd4sLUMpIJZQF6ieetsZohqbYmGpg7WCYwCs5AsmIXQMQtJxwJG5lWMosWpxcW5 6UZGeqlFmcnFxfl5enmpJZsYgcF3cMtvqx2MB587HmIU4GBU4uFVsK0KFWJNLCuuzD3EKM3B oiTOO2NzXqiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRkVLf5WKdfWL0qN+dm3ee3LPDgmm tS5hvgbBHwUYNMqDk3QuTsp+25YgGKfB8sBkzePC2MkR7VcY8oP/rt3Le+7S7Yuc5zX+/cpo bGFoMG8Q3f7qfeYR654v0w3cl62YPEc96MgeRctzB154l+gXPP9caX11QrvV70UaKdH+ggvW 5RtKfznbq8RSnJFoqMVcVJwIAH66G6UfAgAA Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-25.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, 12 Jun 2015 11:31:37 -0000 WG, This is the update that resulted from the comments from the IESG members and the Security Directorate review. Most worth noting are the move of four references into normative classification, this is the Overview, the W3C API specifications and draft-ietf-avtcore-rtp-topologies. What is worth noting is that the last is a downref and thus I expect that there will be a new IETF last call to check that people are fine with that before it can be formally approved by the AD. The IESG positions are already in place to approve the document. But, please check the changes: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-25 Cheers Magnus internet-drafts@ietf.org skrev den 2015-06-12 13:27: > > 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-25.txt > Pages : 45 > Date : 2015-06-12 > > 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: > https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-25 > > > 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 > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jun 12 07:45:03 2015 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 C460C1ACD0A; Fri, 12 Jun 2015 07:45:00 -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 tUT9Hs9EaymI; Fri, 12 Jun 2015 07:44:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A352A1ACCFF; Fri, 12 Jun 2015 07:44:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150612144459.7261.99748.idtracker@ietfa.amsl.com> Date: Fri, 12 Jun 2015 07:44:59 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-video-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: Fri, 12 Jun 2015 14:45:01 -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 : WebRTC Video Processing and Codec Requirements Author : Adam Roach Filename : draft-ietf-rtcweb-video-06.txt Pages : 9 Date : 2015-06-12 Abstract: This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, as well as video codecs and their parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-video-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-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 Fri Jun 12 13:33:51 2015 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 390721ACEA7 for ; Fri, 12 Jun 2015 13:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 0HLEFGn1nCav for ; Fri, 12 Jun 2015 13:33:48 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444121A1A6B for ; Fri, 12 Jun 2015 13:33:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A8F8020B4D for ; Fri, 12 Jun 2015 16:33:47 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 12 Jun 2015 16:33:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=MhQYiMr5GhmB60gvRstncy/7eTA=; b=DhmNMC 2FeHt1JNETMBsM3LoxLxZ44AsSZ6zqEEX02XTWPtKeGeY1Eqti+SILJxRyn/BXsw q5Wi3tr8lbqWDJ2cCG4tPdWEO1E498+ay4c6MKOInOQDwv45Sh5limVMgOBSKHxL XGPs6W4zgqRy5lgMQ578OsfKYTD1V8d/PYSkI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=MhQYiMr5GhmB60g vRstncy/7eTA=; b=CBbc9jsdPgdTl/dlFIMVbjmEZdUyTUbXQb6W1vO7Z2kxxR7 dxRHPS6QxR1lOVwerIbTVlV0IvqwTLT6JOmk6GMjOpOxUkhKBHXd21uoMDDZil7a Z7CoXQkKncnNMGyXHmVuy4DfRX/CmnG8P6380yi24NJ+5nzh9ZYGhY8sfLS8= X-Sasl-enc: Ldc0oYjbSxNRQp1ywM7FJVXumiGqAwX9BqZagNKuadCw 1434141227 Received: from dhcp-171-68-21-86.cisco.com (unknown [171.68.21.86]) by mail.messagingengine.com (Postfix) with ESMTPA id EC736680105; Fri, 12 Jun 2015 16:33:46 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <557AC310.5000007@ericsson.com> Date: Fri, 12 Jun 2015 13:33:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <548F16B7-DFFE-42AA-8693-8B0BC6B4C59C@cooperw.in> References: <20150612112739.17037.10147.idtracker@ietfa.amsl.com> <557AC310.5000007@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-25.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, 12 Jun 2015 20:33:50 -0000 Hi Magnus, On Jun 12, 2015, at 4:31 AM, Magnus Westerlund = wrote: > WG, >=20 > This is the update that resulted from the comments from the IESG = members and the Security Directorate review. >=20 > Most worth noting are the move of four references into normative = classification, this is the Overview, the W3C API specifications and = draft-ietf-avtcore-rtp-topologies. >=20 > What is worth noting is that the last is a downref and thus I expect = that there will be a new IETF last call to check that people are fine = with that before it can be formally approved by the AD. The IESG = positions are already in place to approve the document. Because the suggestion to make draft-ietf-avtcore-rtp-topologies-update = was in a comment from Barry that you didn=92t seem to agree with, I was = not expecting it to change from informative to normative. I don=92t = particularly agree with the comment either, because it creates exactly = the situation we=92re in now =97 since many terminology documents are = not standards track documents, requiring terminology documents to be = normative references just bloats the downref registry and adds a bunch = of unnecessary process delays without realistically impacting = interoperability. So I would prefer if = draft-ietf-avtcore-rtp-topologies-update remains an informative = reference, which is a change we can make in an RFC Editor note. The = document was approved by the IESG with the reference as such. Let me know if you are anyone else has a problem with that. I will still = wait a week before approving so the WG can review all the other changes. Thanks, Alissa >=20 > But, please check the changes: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-25 >=20 > Cheers >=20 > Magnus >=20 > internet-drafts@ietf.org skrev den 2015-06-12 13:27: >>=20 >> 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-25.txt >> Pages : 45 >> Date : 2015-06-12 >>=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: >> https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-rtp-usage-25 >>=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 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jun 12 14:00:35 2015 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 2A1541B2AB2; Fri, 12 Jun 2015 14:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 lo10RqbS4ss7; Fri, 12 Jun 2015 14:00:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399AA1B2AAE; Fri, 12 Jun 2015 14:00:26 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5CL0AFk096849 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2015 16:00:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Magnus Westerlund" Date: Fri, 12 Jun 2015 16:00:10 -0500 Message-ID: <9C881C2A-B25A-41EC-852B-7D138D383349@nostrum.com> In-Reply-To: <55797949.2030004@ericsson.com> References: <20150609030408.24606.8383.idtracker@ietfa.amsl.com> <5576A8FE.2060001@ericsson.com> <55797949.2030004@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: rtcweb@ietf.org, The IESG Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-rtp-usage-24: (with COMMENT) 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, 12 Jun 2015 21:00:31 -0000 Hi, Comments inline. I removed parts that do not seem to need further discussion. On 11 Jun 2015, at 7:04, Magnus Westerlund wrote: [...] >>>> -- 7.1, first paragraph: "applications MUST also implement >>>> congestion >>>> control to >>>> allow them to adapt to changes in network capacity." >>>> >>>> Is that the aformentioned not-yet-standardized congestion control >>>> algorithm, or something else? >>> >>> As we have no standardized congestion control yet, we can't point to >>> anything. But, an implementation must implement something, even if >>> completely proprietary. >> >> It would be helpful to either clarify the "even if proprietary" part, >> or >> perhaps move this sentence closer to the bit about no standardized >> mechanism. (But this is not a show stopper.) > > Ok, > > I propose that we add this sentence: "The congestion control algorithm > will have to be proprietary until a standardized congestion control > algorithm is available." into the first paragraph in 7.1: > > WebRTC Endpoints MUST implement the RTP circuit breaker algorithm > that is described in [I-D.ietf-avtcore-rtp-circuit-breakers]. The > RTP circuit breaker is designed to enable applications to recognise > and react to situations of extreme network congestion. However, > since the RTP circuit breaker might not be triggered until congestion > becomes extreme, it cannot be considered a substitute for congestion > control, and applications MUST also implement congestion control to > allow them to adapt to changes in network capacity. The congestion > control algorithm will have to be proprietary until a standardized > congestion control algorithm is available. Any future RTP congestion > control algorithms are expected to operate within the envelope > allowed by the circuit breaker. > > Does this satisfies your concerns? > Yes, thanks. >> >>> >>> >>>> >>>> -- 11, 2nd paragraph from end: >>>> >>>> It seems like the msid reference should be normative. >>> >>> Our intention was to keep this informative. Therefore the chosen >>> style >>> of writing that sentence. The actual normative inclusion of MSID >>> into >>> the WebRTC solution is done by JSEP. >> >> Okay. It might be helpful, but not required, to state this sentence >> in >> the form of "[jsep] specifies that..." >> > > So what you want is that paragraph to read more like this? > > Javascript Session Establishment Protocol [I-D.ietf-rtcweb-jsep] > specifies that the binding between the WebRTC MediaStreams, > MediaStreamTracks and the SSRC is done as specified in "Cross Session > Stream Identification in the Session Description Protocol" > [I-D.ietf-mmusic-msid]. The MSID document [I-D.ietf-mmusic-msid] > also defines, in section 4.1, how to map unknown source packet stream > SSRCs to MediaStreamTracks and MediaStreams. Yes, I think that helps. [...] >>> The TSVWG document referenced do normatively reference the DART >>> document. But, we could include the DART document in the same >>> sentence >>> as the TSVWG document. >> >> I'm okay leaving it to the deeper conversation in the TSVWG doc. I >> mainly mentioned it because I had thought the intent was to add the >> mention here if the dart draft was sufficiently far along in the >> process >> when this draft was submitted. > > Actually, I think I found a simple way of referencing it, and it is > relevant in that discussion. So the sentence is proposed to read: > > However, depending on the QoS > mechanism and what markings that are applied, this can result in not > only different packet drop probabilities but also packet reordering, > see [I-D.ietf-tsvwg-rtcweb-qos] and [I-D.ietf-dart-dscp-rtp] for > further discussion. > That works for me. >>>> -- 13: 3rd paragraph: >>>> >>>> Isn't that security solution MTU as well as MTI? If so, it might be >>>> worth >>>> mentioning it here. >>> >>> You mean Mandatory to Use, not Maximum Transmission Unit, don't you? >>> Yes, it is mandatory to use, we can make that clear. >>> >> >> Yes, mandatory to use. :-) >> > > So text proposed to be changed to. > > A mandatory to implement and use > media security solution is created by combining this secured RTP > profile and DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of > [I-D.ietf-rtcweb-security-arch]. That works for me. Thanks! Ben. From nobody Fri Jun 12 15:06:47 2015 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 185CB1B2B7B for ; Fri, 12 Jun 2015 15:06: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 9yDH84x2CPJo for ; Fri, 12 Jun 2015 15:06:44 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804051B2B78 for ; Fri, 12 Jun 2015 15:06:44 -0700 (PDT) Received: by yhid80 with SMTP id d80so18872163yhi.1 for ; Fri, 12 Jun 2015 15:06:44 -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=WDmqO/+Q7GJkoRfmi9Pufg3H2r9QQrzb9cZEtXOrIGM=; b=a99bIXu/hS8UqqqAoy+rZCu69cbxM0AAFRl7IAYlKdeVoqnYOSgiI62o+uM6zQ6Czf w/2BO3KkAQCRsay4pG/h/hMVHMLBjhSK5P6RvY8VDPME7s3kSmnWH0tEhYGeyW1jlgkc 1/wNZcandnaZQV7wI4bpeDst97Dg3e0P6eZ/42eHkH1Ao5NdozB0kaOta2scExH+zszJ gAMRdfWaSsZFg2GHjzs8x1XI+klli/5XeRqo5P9FpIPFZbSBngdoXwHP0/Cw41zdzcv+ hqm7o23He1oJvTxB/GbajT0/P/2AEPRK6Bewb2uqWBEvyS6hZX0ze7n2g4L5GmlBMgJ5 O13A== MIME-Version: 1.0 X-Received: by 10.170.139.132 with SMTP id g126mr21197159ykc.98.1434146803917; Fri, 12 Jun 2015 15:06:43 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 12 Jun 2015 15:06:43 -0700 (PDT) Date: Fri, 12 Jun 2015 15:06:43 -0700 Message-ID: From: Martin Thomson To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [rtcweb] Security architecture: Making ECDSA mandatory 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, 12 Jun 2015 22:06:46 -0000 I've opened https://github.com/rtcweb-wg/security-arch/pull/33 This changes the MTI cipher suites to ECDSA and does a little cleanup on the corresponding API requirements to more closely match what has just landed in the W3C specification. We discussed ECDSA and the only concerns raised were with compatibility. I've done some testing with other implementations with no issues, and ECDSA seems to be well supported on all those hard-to-upgrade PSTN gateways (thanks to Cullen and Ethan for helping out with checks there and to NIST for creating certification pressure with FIPS-2). I have an implementation that switches Firefox to ECDSA with P-256 by default. It's much, much faster. http://bench.cr.yp.to/ claims that it's 150 times faster on mobile devices for keygen. From nobody Sun Jun 14 16:08:35 2015 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 128B51A88AD for ; Sun, 14 Jun 2015 16:08:34 -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 2Q5SBkhipPwL for ; Sun, 14 Jun 2015 16:08:30 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260A51A88C9 for ; Sun, 14 Jun 2015 16:07:37 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so60873255wib.1 for ; Sun, 14 Jun 2015 16:07:20 -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=SDLeKePW9WvMMQ8I2UczbizA05DCc0yEW5/FbIMKJnI=; b=IqeaNOMffPqTnrZBKm0iDlWY+TgpatOlxsmsOALjRu3NceZGA4iHqi9LmQ4Q3GbvB5 AIGg/Gcs+pMDdxeW355QSbvS42DfYtVjfiNHY4rBaGLq1WU1bbEQGrRzq6WzMjHvLAqc nV+LpYatPz1zS9Aus4LSfg8Ba0hRRg7JiwTU6NurKHqNDq0CRtbW7vz+kgJCVlUw5NXH uW9BSJ/13QxZ9NCP8Jec9XpBUAK8JUiuywNPdjgvNx7uMl7zaIf9WDze3z3FazvBiehg jEzgnFEkaUPNgEXbXcIlEXQH/b9kiCSoZw9ZQWSSL8PK4eG8AA7EyRuscxyu2i7UBJNG 4bgw== MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr46786795wjc.26.1434323240579; Sun, 14 Jun 2015 16:07:20 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Sun, 14 Jun 2015 16:07:20 -0700 (PDT) Date: Sun, 14 Jun 2015 16:07:20 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Alissa Cooper , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=047d7bb03a923f758405188267ec Archived-At: Subject: [rtcweb] Updated 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: Sun, 14 Jun 2015 23:08:34 -0000 --047d7bb03a923f758405188267ec Content-Type: text/plain; charset=UTF-8 The -14 of this draft is out now, with updates related to several of the external reviews. Please re-review the document by June 29, 2015 and provide comments. Below is a link for your convenience, http://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ regards, Ted, Cullen, Sean --047d7bb03a923f758405188267ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The -14 of this draft is out now, with updates r= elated to several of the external reviews.=C2=A0 Please re-review the docum= ent by June 29, 2015 and provide comments.=C2=A0 Below is a link for your c= onvenience,

http://datatracker.ietf.org/d= oc/draft-ietf-rtcweb-stun-consent-freshness/

reg= ards,

Ted, Cullen, Sean
--047d7bb03a923f758405188267ec-- From nobody Mon Jun 15 00:29:01 2015 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 090A71A89FE for ; Mon, 15 Jun 2015 00:29:01 -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 4BUDrF9lanhA for ; Mon, 15 Jun 2015 00:28:59 -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 0CFE11B33B6 for ; Mon, 15 Jun 2015 00:28:57 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-c9-557e7eb87a6d Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.9F.17665.8BE7E755; Mon, 15 Jun 2015 09:28:56 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.210.2; Mon, 15 Jun 2015 09:28:55 +0200 Message-ID: <557E7EB6.1090405@ericsson.com> Date: Mon, 15 Jun 2015 09:28:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Alissa Cooper References: <20150612112739.17037.10147.idtracker@ietfa.amsl.com> <557AC310.5000007@ericsson.com> <548F16B7-DFFE-42AA-8693-8B0BC6B4C59C@cooperw.in> In-Reply-To: <548F16B7-DFFE-42AA-8693-8B0BC6B4C59C@cooperw.in> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvre6OurpQg7kLhSymn/nLaLH2Xzu7 A5PHlycvmTyWLPnJFMAUxWWTkpqTWZZapG+XwJUx/3UrY8FP/ornu0+xNTC283YxcnJICJhI PHvRygphi0lcuLeeDcQWEjjKKPFpqUkXIxeQvZxR4tXprWBFvALaEse2XWYEsVkEVCUmPVzG DmKzCVhI3PzRCNYsKhAlMfXxOhaIekGJkzOfgNkiQPVXj/0Aq2EWEJV49XAKM4gtLOAiMXnS LUaIZZMZJQ7MWQ82lFPATuJ12wSgxRxADfYSD7aWQfTKSzRvnc0Mcai2RENTB+sERsFZSNbN QuiYhaRjASPzKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAYD245bfuDsbVrx0PMQpwMCrx 8Cb8rA0VYk0sK67MPcQozcGiJM47Y3NeqJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGvTXC uYHHm6dsP/bdpHbrqcfs/r9WSWd0Hz3w9HpqU4vT9ZP8vJGlF+89to1Z3vpQ92fs3T9Fnfwv 3uUsPKU8+7xjwfITDXs1Pauf6ra7H3htLXFde27prYfa8x/uV8zSYwupOsqccC/dT0Ry8u5J H76mrNLoWXnD8CnX594t3d9nd3TdCl58QomlOCPRUIu5qDgRAL9Oz2c3AgAA Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-25.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, 15 Jun 2015 07:29:01 -0000 Alissa Cooper skrev den 2015-06-12 22:33: > On Jun 12, 2015, at 4:31 AM, Magnus Westerlund > wrote: > > Because the suggestion to make > draft-ietf-avtcore-rtp-topologies-update was in a comment from Barry > that you didn’t seem to agree with, I was not expecting it to change > from informative to normative. I don’t particularly agree with the > comment either, because it creates exactly the situation we’re in now > — since many terminology documents are not standards track documents, > requiring terminology documents to be normative references just > bloats the downref registry and adds a bunch of unnecessary process > delays without realistically impacting interoperability. So I would > prefer if draft-ietf-avtcore-rtp-topologies-update remains an > informative reference, which is a change we can make in an RFC Editor > note. The document was approved by the IESG with the reference as > such. Ok, I have no issues with it remaining informative reference. I think the rtp-topologies-update will be end up on the downref list anyway eventually, but we can wait until it is actually an RFC ;-). rtp-topologies-update is a grey zone document even by my standards. But, I have no strong opinions here. > > Let me know if you are anyone else has a problem with that. I will > still wait a week before approving so the WG can review all the other > changes. > >> But, please check the changes: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-25 >> Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 15 11:33:39 2015 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 E08861A1A9F for ; Mon, 15 Jun 2015 11:33:37 -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 rwlY7vL5vN9c for ; Mon, 15 Jun 2015 11:33:36 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0091A014D for ; Mon, 15 Jun 2015 11:33:36 -0700 (PDT) Received: by wgzl5 with SMTP id l5so50837425wgz.3 for ; Mon, 15 Jun 2015 11:33:35 -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=VNeY9Uf0dKWpDqVT4DusFY+sAQpCXVdVxMDtX9diBNc=; b=xhJizHl2Wn/rHDFn7u8qmNCjHizusSf/ErEgHwjANcq9fVXHhp9vTqPFqS8aaRogBE AzbBxsgtyE5I5feNS0gWcdATwm6wbZVcvubdLU+EnrjkxWzJzZXgSo/tTSWuQ0skq94T d+Ktud5+rOBjnGWNsYLE9o1szRyneSRXrq7ezPMx8TwKJdEIxbQMXwKNajC10bB6l0vp 6OLxuT7UTutdkdbWgpwxSmHSkKWnI8BOrxiPw2D6V430ZZcSGVWX7rNJOqUqdBVuE1uo 9hhZOBQGGdglmFmLiDraHMzXlQ6gRDqQ61HNDyHPeWAOYut675flylxpSs/Vd/dP0iAW LXkQ== MIME-Version: 1.0 X-Received: by 10.181.11.229 with SMTP id el5mr34608244wid.40.1434393215014; Mon, 15 Jun 2015 11:33:35 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Mon, 15 Jun 2015 11:33:34 -0700 (PDT) Date: Mon, 15 Jun 2015 11:33:34 -0700 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary=f46d043c80040c9b0a051892b2a5 Archived-At: Subject: [rtcweb] Agenda for the meeting on Thursday 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, 15 Jun 2015 18:33:38 -0000 --f46d043c80040c9b0a051892b2a5 Content-Type: text/plain; charset=UTF-8 As a reminder the meeting on Thursday will be focused on JSEP, running through open issues documented in the github issue tracker. The slides will each focus on an issue, the set of available resolutions, and the proposal of the editing team, and discussion will proceed from there. The issues are here: https://github.com/rtcweb-wg/jsep/issues As I reminder we still need a note taker for the minutes and we could use an issue-tracker-scribe as well. regards, Ted, Cullen, Sean --f46d043c80040c9b0a051892b2a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a reminder the meeting on Thursday will be fo= cused on JSEP, running through open issues documented in the github issue t= racker.=C2=A0 The slides will each focus on an issue, the set of available = resolutions, and the proposal of the editing team, and discussion will proc= eed from there.=C2=A0 The issues are here:

https://github.com/rtcweb-wg/jsep/issues
As I reminder we still need a note taker for the minut= es and we could use an issue-tracker-scribe as well.

regards,

Ted, Cullen, Sean
--f46d043c80040c9b0a051892b2a5-- From nobody Mon Jun 15 11:57:58 2015 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 8CFED1A0069; Mon, 15 Jun 2015 11:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 oy2U_ckCrAVz; Mon, 15 Jun 2015 11:57:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5E71A6F2F; Mon, 15 Jun 2015 11:57:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150615185747.26441.175.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 11:57:47 -0700 Archived-At: Cc: rtcweb mailing list , rtcweb chair , RFC Editor Subject: [rtcweb] Protocol Action: 'WebRTC Video Processing and Codec Requirements' to Proposed Standard (draft-ietf-rtcweb-video-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: Mon, 15 Jun 2015 18:57:54 -0000 The IESG has approved the following document: - 'WebRTC Video Processing and Codec Requirements' (draft-ietf-rtcweb-video-06.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ Technical Summary This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required, as well as video codecs and their parameters. Working Group Summary From Sean Turner: I’d characterize discussions about this draft as a lengthy, lively, and spirited and that’s putting it mildly, but I also think if Chuck were representative of this then this meme would sum it up:http://cdn.meme.am/instances/500x/58865172.jpg. There has easily been in excess of 1,000 email messages about this draft and this draft has been discussed at many f2f meetings ​(IETF 81, 82, 85, 86, and 88) before the WG consciously decided to take an entire year off from discussing it before re-engaging around the IETF 91 timeframe. >From the start, VP8 and H.264 were the front runners though H.261, H.263, Theora, and Motion JPEG were also considered. From the 10,000 foot level, the draw to H.264 was its widespread support and the draw to VP8 was its BSD-like license and irrevocable free patent license on its bitstream format. Of course, VP8 was shown to be widely supported and the IPR “freeness†of VP8 was questioned (discussed in response to question #3 below). And, H.264’s widespread support was attacked based on the number of profiles and H.264’s licensing cost was described as “lowâ€. Of course, the topic that dominated the discussion was IPR. But, from the start everybody that this was going to be the case so there’s text to address it in the charter, i.e., there’s the possibly that an IPR-encumbered solution might be selected. See Section 3 for more on IPR issues. Lest you think that the entire debate was about IPR, early on technical topics included video quality and performance as well as status of VP8 standardization, which BTW is moving its way through ISO. None of these topics however were interesting enough to maintain the WG's attention while the IPR debated raged. As far as the consensus process goes, there were actually three attempts at reaching consensus. The first attempt did not result in WG consensus. After the 1st attempt failed, the WG explored an alternative decision making process (the 2nd attempt), which also was fodder for the IETF discussion list, based on this msghttp://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html. This too didn’t result in WG consensus but a couple of important topics did fall out: 1) it helped enumerate more options (i.e., it wasn’t just H.264 vs VP8) and 2) confirmed that the WG did in fact want to decide on an MTI codec. Leading up to IETF 91, the chairs proposed a series of physical and vocal calisthenics, which can be found here:http://www.ietf.org/mail-archive/web/rtcweb/current/msg13358.html, that we thought would help the WG reach consensus (i.e., third time being the charm and all). But, Adam took the wind out of our sails with his so called “novel proposal", which can be found here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html. Based on list support for the proposal we modified our questions to refer to Adam’s text prior to the meeting. So at the 2nd RTCWeb session @ IETF 91 we had presentations from the draft author on the compromise text and from the VP8 and H.264 “camps†in support of the compromise. Then, we had an open mic session followed by some hums. The rough consensus in the room was to adopt the comprise text but there were some objections raised and I pointed these out in the message sent to the mailing list confirming the room’s consensus:http:// www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html. After the allotted time elapsed (and a few hundred more emails), I determined that the consensus in the room was confirmed. I’ll note that during the second WG consensus attempt, I purposely requested that the other two chairs step down from the podium and I, along with some help from my ADs, made the consensus call and it was later confirmed on the list. Document Quality There are many implementations that will or do make use of this specification. Personnel Sean Turner is the document shepherd. Alissa Cooper is the responsible Area Director. From nobody Mon Jun 15 21:36:36 2015 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 6402E1B394F; Mon, 15 Jun 2015 21:36: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 VrASKg5YvXu1; Mon, 15 Jun 2015 21:36:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEE01B3948; Mon, 15 Jun 2015 21:36:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150616043634.12918.28538.idtracker@ietfa.amsl.com> Date: Mon, 15 Jun 2015 21:36:34 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-10.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: Tue, 16 Jun 2015 04:36:35 -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 : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-10.txt Pages : 75 Date : 2015-06-15 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-10 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 Tue Jun 16 05:13:22 2015 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 7A6451B338C for ; Tue, 16 Jun 2015 05:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, 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 IeyJlQ7JSUKo for ; Tue, 16 Jun 2015 05:13:19 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881351B2C1F for ; Tue, 16 Jun 2015 05:13:18 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-10-558012dca9cd Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.9E.04015.CD210855; Tue, 16 Jun 2015 14:13:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.210.2; Tue, 16 Jun 2015 14:13:16 +0200 Message-ID: <558012DB.4010608@ericsson.com> Date: Tue, 16 Jun 2015 14:13:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHJMWRmVeSWpSXmKPExsUyM+Jvre4doYZQgzW39C3md6xjs1j7r53d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mr4/2oJY8ED+4qWVVMZGxjPG3YxcnJICJhI dD++zAZhi0lcuLcezBYSOMooMf0zTxcjF5C9nFHi09tVTF2MHBy8AtoSk4+4gtSwCKhKbP96 jgnEZhOwkLj5oxGsV1QgSmLq43UsIDavgKDEyZlPwGwRgSCJdQu7weqFBfQkXt2ZxwwyklnA XuLB1jKQMLOAvETz1tnMECdoSzQ0dbBOYOSbhWTSLISOWUg6FjAyr2IULU4tTspNNzLSSy3K TC4uzs/Ty0st2cQIDLCDW34b7GB8+dzxEKMAB6MSD2/Cz9pQIdbEsuLK3EOM0hwsSuK8Mzbn hQoJpCeWpGanphakFsUXleakFh9iZOLglGpgnPpvh+EsGb+1rXuj+eR+epnHCc8UUWI/nFBX 2PD37vfrzw7a7U25x6M+YdXpbTt8VY9+eimq3slkxXDF5sENsY0GpupxCjfsl3H6Mx6ovfv2 d1jGB3mvKpG/x58ukpR95VTN2/3uTMsi3+hNPfm7WNMtKsrEpfJnqj/4eIVhVeLlLPG12avf KLEUZyQaajEXFScCAK+tjZURAgAA Archived-At: Subject: [rtcweb] Comments on draft-ietf-rtcweb-jsep-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: Tue, 16 Jun 2015 12:13:21 -0000 Hi, I have reviewed the changes between the -09 and -10 versions and have some comments. A. Section 3.5: 3.5. RTP CNAME Semantics RTP CNAME values provide a canonical name for the RTP endpoint, allowing other RTP endpoints to determine which RTP streams are using the same clock and thus which clock sources can be used that to synchronize media playout. Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.] Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME. For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME. The main problem is that this is out-of-synch (Pardon the pun) with what RTP-usage specifies. See Section 4.9: I think the relevant is the following: Taking the discussion in Section 11 into account, a WebRTC Endpoint MUST NOT use more than one RTCP CNAME in the RTP sessions belonging to single RTCPeerConnection (that is, an RTCPeerConnection forms a synchronisation context). RTP middleboxes MAY generate RTP packet streams associated with more than one RTCP CNAME, to allow them to avoid having to resynchronize media from multiple different endpoints part of a multi-party RTP session. So lets look at the normative statements in JSEP: "Any MediaStreamTracks which have different clock sources MUST have different CNAMEs [TODO: need a reference for this.]" This is not allowed by an WebRTC endpoint, which must use only a single CNAME. Although a RTP middlebox can forward multiple CNAMEs, the WebRTC endpoint is instead required to perform re-synchronization into the used clock based of the other streams. "Any MediaStreamTracks which are in different PeerConnection objects MUST have different CNAMEs; this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME." This one is correct, but I don't quite understand the "this prevents peers from linking calls from multiple remote PeerConnections based on the CNAME." part. First of all what is a "call". Secondly, what type of linking are you considering here? "For simplicity, MediaStreamTracks in the same PeerConnection which have the same clock source SHOULD have the same CNAME." The SHOULD needs to be a MUST. B. Section 3.6.1: Otherwise, an "a=imageattr" attribute is created with "recv" direction, and the resulting resolution space formed by intersecting the decoder limits and constraints is used to specify its minimum and maximum x= and y= values. If the intersection is the null set, i.e., there are no resolutions that are permitted by both the decoder and the mandatory constraints, this SHOULD be represented by x=0 and y=0 values. The rules here express a single set of preferences, and therefore, the "a=imageattr" q= value is not important. It SHOULD be set to 1.0. What about end-points that can produce different aspect ratios on its video. Such a system is likely to have different constraints on its min and max resolution in X and Y for 1:1, 4:3, 16:9 and 1:2.35 aspect ratios. It is unclear if that is allowed, and even recommend practice. And in this case there might be a usage for the q value. C. Section 3.6.1: As an example, consider a system with a HD-capable, multiformat video decoder, where the application has constrained the received track to at most 360p. In this case, the implemention would generate this attribute: a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] Maybe this example should discuss the minimal aspect of this. What it really is expressing in that it can handle any resolution between 16x16 pixels up to 640x360 as the longest in respective side. No limitations to any picture aspect ratio. D. Section 3.6.1: What about usage of "par" in the sets. I actually expect most have limitations to perform a scaling that maintain the PAR, not performing cropping or scaling that warps the picture. E. Section 3.6: I am missing a discussion on how video orientation affects what one states. Taking the above example with a maximum resolution of 640x360, which gives a landscape 16:9 PAR. If one rotates this, then it is not clear if one is allowed to have 360x640 or are limited to 203x360. Or should one actually state the different orientations maximum resolution and consider that this is simply different PAR, as 16:9 (Landscape) is 9:16 (Portrait) two different picture aspect ratios. F. Section 4.1.1: Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will offer a single BUNDLE group across all media sections. I think this sentence may be a bit misleading without additional sentence(s) to explain that the actual number of established transport streams will depend on the peer's response to the attempt to bundle. G. Section 5.2.1: This section contains the following: Each m= section MUST include the following attribute lines: o If this m= section is for video media, an "a=imageattr" line, as specified in Section 3.6. But, Section 3.6 does not mandate that a=imageattr always is included. Thus the text must be modified to allow the selective inclusion of the attribute based on what needs to be said. H. Section 5.2.1: o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source. The CNAME must be generated in accordance with [RFC7022] and Section 3.5. I think this document shouldn't make normative statement to how CNAMEs shall be generated. That last sentence points to RFC7022, but that is not the whole story. If you like to point to how CNAMEs are to be generated then say that Section 4.9 of RTP-usage is the place to determine that. I. Section 5.3.1: The next step is to generate lip sync groups as defined in [RFC5888], Section 7. For each MediaStream with more than one MediaStreamTrack, a group of type "LS" MUST be added that contains the mid values for each MediaStreamTrack in that MediaStream. In some cases this may result in adding a mid to a given LS group that was not in that LS group in the associated offer. Although this is not allowed by [RFC5888], it is allowed when implementing this specification. So, do I understand it correctly the violation this paragraph is discussing is the following from Section 9.2 of RFC5888: The identification-tags contained in this "a=group" line MUST be the same as those received in the offer, or a subset of them (zero identification-tags is a valid subset). So when will these violations occur for a LS group in JSEP. I assume due to that offer and answer has different structure of how MediaStreams uses the different m= lines. But, isn't this just another case of when an answerer will have to do an follow up Offer to be able to add all the MediaStreamTracks and their MediaStreams due to different sets on the two peers? I don't really think this specification should override RFC 5888. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jun 16 05:51:47 2015 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 384A71B2C04; Tue, 16 Jun 2015 05:51:46 -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 L7OBujARQ9TW; Tue, 16 Jun 2015 05:51:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB191B33EE; Tue, 16 Jun 2015 05:51:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150616125143.5664.44261.idtracker@ietfa.amsl.com> Date: Tue, 16 Jun 2015 05:51:43 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-14.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: Tue, 16 Jun 2015 12:51:46 -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-14.txt Pages : 22 Date : 2015-06-16 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 WebRTC 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: https://tools.ietf.org/html/draft-ietf-rtcweb-overview-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-14 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 Tue Jun 16 08:22:39 2015 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 D22731B2E6A for ; Tue, 16 Jun 2015 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, 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 b3FLMik2OmCs for ; Tue, 16 Jun 2015 08:22:35 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AFF11B2E14 for ; Tue, 16 Jun 2015 08:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1434468154; x=1466004154; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=cH2mo0rderXgM+3I7CT92LV1NJF0pWauGrHV2X7BpYc=; b=Q+kAaigERY+xownbovYVQieRKZUCgoO+mZ7wSvbC7T9QtwC8ZwsNOXQG hChbrb7KocTNLh85LWX+K5Y+2oskXxedqn5M5g5fZkDgIjFNhwcQQqwdn nVrhFnQbplYbgGFUMcMhzX7mZQ3x5nNEG5qk2UK6qxTrbJuGV5d9zVvgA Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7833"; a="123520012" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jun 2015 08:22:33 -0700 X-IronPort-AV: E=Sophos;i="5.13,626,1427785200"; d="scan'208";a="911439869" Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Jun 2015 08:22:28 -0700 Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 16 Jun 2015 08:22:28 -0700 Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1044.021; Tue, 16 Jun 2015 08:22:28 -0700 From: "Mandyam, Giridhar" To: "rtcweb@ietf.org" Thread-Topic: New draft uploaded: FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources Thread-Index: AdCoRflJkns0s7AMQGiGAX/ITs019A== Date: Tue, 16 Jun 2015 15:22:27 +0000 Message-ID: <4faa72a8ab7446fea96d0b17ce23bd4b@NASANEXM01C.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rtcweb] New draft uploaded: FEC FRAME Raptor Extensions for Multiple RTP Synchronization Sources 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, 16 Jun 2015 15:22:38 -0000 Hello All, Please note that a new I.-D. has been uploaded to being to address the foll= owing from the WebRTC FEC Draft (https://tools.ietf.org/html/draft-ietf-rtc= web-fec-01#section-5.1): " Support for protecting multiple primary streams= with a single FEC stream is complicated by WebRTC's 1-m-line-per-stream po= licy and requires further study."=20 Please note that this draft is submitted as "Informational". The particula= rs for the draft are as follows: ---------------------------------------------------------------- A new version of I-D, draft-mandyam-rtcweb-fecframebundledssrc-00.txt has been successfully submitted by Giridhar Mandyam and posted to the IETF = repository. Name: draft-mandyam-rtcweb-fecframebundledssrc Revision: 00 Title: FEC FRAME Raptor Extensions for Multiple RTP Synchronization Source= s Document date: 2015-06-16 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-mandyam-rtcweb-f= ecframebundledssrc-00.txt Status: https://datatracker.ietf.org/doc/draft-mandyam-rtcweb-fecfr= amebundledssrc/ Htmlized: https://tools.ietf.org/html/draft-mandyam-rtcweb-fecframebu= ndledssrc-00 Abstract: The FEC FRAME Raptor code options do not currently address the case of bundled protection of multiple media types over multiple real-time transport protocol (RTP) synchronization sources (SSRC's). This document provides the FEC source and repair payload definitions that enable a single repair flow to be defined for multiple RTP flows -Giri Mandyam, Qualcomm Innovation Center From nobody Wed Jun 17 12:14:38 2015 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 562BA1ACE13 for ; Wed, 17 Jun 2015 12:14:36 -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, 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 TgaBm1QsIOYQ for ; Wed, 17 Jun 2015 12:14:34 -0700 (PDT) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.147.201]) (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 D91931A0091 for ; Wed, 17 Jun 2015 12:14:34 -0700 (PDT) Received: by gateway34.websitewelcome.com (Postfix, from userid 500) id 619EF39983A71; Wed, 17 Jun 2015 14:14:34 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 51CE339983A55 for ; Wed, 17 Jun 2015 14:14:34 -0500 (CDT) Received: from [96.231.223.98] (port=58803 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z5InB-0005yM-PI for rtcweb@ietf.org; Wed, 17 Jun 2015 14:14:33 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2015 15:14:31 -0400 References: <20150529203722.31896.80860.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org Message-Id: <07121297-C275-47D2-909F-7AEE863214B7@ieca.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.223.98 X-Exim-ID: 1Z5InB-0005yM-PI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.223.98]:58803 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [rtcweb] reminder: webex details: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): June 18, 2015 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, 17 Jun 2015 19:14:36 -0000 In case you missed it here=92s the webex details for the virtual interim = meeting tomorrow. spt Begin forwarded message: > From: IESG Secretary > Subject: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): = June 18, 2015 > Date: May 29, 2015 at 16:37:22 EDT > To: "IETF Announcement List" > Cc: rtcweb@ietf.org > Reply-To: ietf@ietf.org >=20 > The Real-Time Communication in WEB-browsers (rtcweb) Working Group=20 > will hold a virtual interim meeting on Thursday, June 18, 2015, = between=20 > 0900 and 1100 PDT (1600 and 1800 UTC). >=20 > JOIN WEBEX MEETING > = https://ietf.webex.com/ietf/j.php?MTID=3Dm165b021236787e79a2e807a31717e8d0= >=20 > Meeting number: 649 055 392 > Meeting password: 1234 >=20 > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada)=20 > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 649 055 392 >=20 > Toll-free dialing restrictions:=20 > http://www.webex.com/pdf/tollfree_restrictions.pdf >=20 > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc >=20 >=20 > IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. You should inform all meeting attendees = prior to recording if you intend to record the meeting. >=20 From nobody Wed Jun 17 20:52:47 2015 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 473F41ACEDB for ; Wed, 17 Jun 2015 20:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 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, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Lz4hy--GX2fw for ; Wed, 17 Jun 2015 20:52:42 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD171ACD4C for ; Wed, 17 Jun 2015 20:52:42 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so46979387ieb.0 for ; Wed, 17 Jun 2015 20:52:42 -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=0Vg8qlqhhaNuuNDuSIVggpAFeBR8oxa43oqgkthBnpA=; b=SUCKXa2Q4l2i5bSlTWr+ZLpM839+ax2uwU9kUfKkWgzJwGQaaNEwwKmjPm2gV7XXeM qVqibEr0mP2jw6WYoI3F/Do7fmsEhg6IC3J8HDNdOtWGqd059SsjupBP2MeOHUrCkSpa E3EXW3WVRoy2CmV5Jq0pAogpVKJLn74gS5qE3Ahg/7gK/Q89HHqiQrVtIpj11+KPkUDd UryUBVxHYeRPZQytOTmbhGb/4E/iS7SWqBE5VQA0zUh9A1WBb9nGtV10XoBqa5gCLdVA wc9jKnLKJ0pQS2/UTbOmIAwK8rEUSJuSt834LRUAAmkweoc1ociafHCh0G+pWoSGjidC s1Bw== 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=0Vg8qlqhhaNuuNDuSIVggpAFeBR8oxa43oqgkthBnpA=; b=Ub55DHzjoSuZjrhR8EkcBngg40GU6JVdQ1ss17Vp9hPf5DKbTobbhI071N7Wizz0AA wa060qsz5ZrThAxQtEWgcjWID6v9x4xicbyBR45b0Ybg7N3TkG3h05wBEVXyEJ62xYkO TukBTagdn0UaJ98d+R0PZ/eSNlD9mt5+1SM0x7LtkS5c4YbmEq8znhERJmrQxIPFmQdA quxWecxG0+yVsqrChym15aZwHAeZoMd27ZBiylIQG1khErAFRENoCPXnpigtHzx7g/cB XWgD5WG3PGAYii/57EZq16TV8a2UQAJKvZyxKgqxNnM0ieTvyFXjR5/ZEwyOJ6FwX/fK 8K9g== X-Gm-Message-State: ALoCoQlL67thwmcUwP8uKZ9n61EgZLFZw989ycF4Zl5zSJ6mqBxN8wpuA92u4rHlwT/P/IbzSvr/ X-Received: by 10.50.109.138 with SMTP id hs10mr15543239igb.48.1434599561926; Wed, 17 Jun 2015 20:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.233 with HTTP; Wed, 17 Jun 2015 20:52:21 -0700 (PDT) In-Reply-To: <558012DB.4010608@ericsson.com> References: <558012DB.4010608@ericsson.com> From: Justin Uberti Date: Wed, 17 Jun 2015 20:52:21 -0700 Message-ID: To: Magnus Westerlund , Cullen Jennings Content-Type: multipart/alternative; boundary=089e0122e6aa48b55a0518c2bda0 Archived-At: Cc: draft-ietf-rtcweb-jsep@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-jsep-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: Thu, 18 Jun 2015 03:52:46 -0000 --089e0122e6aa48b55a0518c2bda0 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 16, 2015 at 5:13 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I have reviewed the changes between the -09 and -10 versions and have some > comments. > Thanks for the feedback. Comments inline; I will also try to cover any issues identified here in tomorrow's presentation. > > A. Section 3.5: > > 3.5. RTP CNAME Semantics > > RTP CNAME values provide a canonical name for the RTP endpoint, > allowing other RTP endpoints to determine which RTP streams are using > the same clock and thus which clock sources can be used that to > synchronize media playout. > > Any MediaStreamTracks which have different clock sources MUST have > different CNAMEs [TODO: need a reference for this.] Any > MediaStreamTracks which are in different PeerConnection objects MUST > have different CNAMEs; this prevents peers from linking calls from > multiple remote PeerConnections based on the CNAME. For simplicity, > MediaStreamTracks in the same PeerConnection which have the same > clock source SHOULD have the same CNAME. > > The main problem is that this is out-of-synch (Pardon the pun) with what > RTP-usage specifies. See Section 4.9: > > I think the relevant is the following: > > Taking the discussion in Section 11 into account, a WebRTC Endpoint > MUST NOT use more than one RTCP CNAME in the RTP sessions belonging > to single RTCPeerConnection (that is, an RTCPeerConnection forms a > synchronisation context). RTP middleboxes MAY generate RTP packet > streams associated with more than one RTCP CNAME, to allow them to > avoid having to resynchronize media from multiple different endpoints > part of a multi-party RTP session. > > So lets look at the normative statements in JSEP: > > "Any MediaStreamTracks which have different clock sources MUST have > different CNAMEs [TODO: need a reference for this.]" > > This is not allowed by an WebRTC endpoint, which must use only a single > CNAME. Although a RTP middlebox can forward multiple CNAMEs, the WebRTC > endpoint is instead required to perform re-synchronization into the used > clock based of the other streams. > TBH, I wasn't sure exactly where it was mandated that different clock sources translate into different CNAMEs (hence the missing ref). Cullen, do you know? If there is no problem with using a single CNAME in this case, I think that is clearly the simplest thing to do. > > "Any > MediaStreamTracks which are in different PeerConnection objects MUST > have different CNAMEs; this prevents peers from linking calls from > multiple remote PeerConnections based on the CNAME." > > This one is correct, but I don't quite understand the "this prevents peers > from linking calls from multiple remote PeerConnections based on the > CNAME." part. First of all what is a "call". Secondly, what type of linking > are you considering here? > "call" may not be the ideal terminology here, but the concern here is an application which makes a connection to peer A with PC A and then later makes a connection to peer B with PC B. If CNAME was reused, someone with knowledge of A and B could see that they received calls from the same originating endpoint. > > > "For simplicity, > MediaStreamTracks in the same PeerConnection which have the same > clock source SHOULD have the same CNAME." > > The SHOULD needs to be a MUST. If we follow the advice from rtp-usage as mentioned above, I agree. > > > B. Section 3.6.1: > > Otherwise, an "a=imageattr" attribute is created with "recv" > direction, and the resulting resolution space formed by intersecting > the decoder limits and constraints is used to specify its minimum and > maximum x= and y= values. If the intersection is the null set, i.e., > there are no resolutions that are permitted by both the decoder and > the mandatory constraints, this SHOULD be represented by x=0 and y=0 > values. > > The rules here express a single set of preferences, and therefore, > the "a=imageattr" q= value is not important. It SHOULD be set to > 1.0. > > What about end-points that can produce different aspect ratios on its > video. Such a system is likely to have different constraints on its min and > max resolution in X and Y for 1:1, 4:3, 16:9 and 1:2.35 aspect ratios. It > is unclear if that is allowed, and even recommend practice. And in this > case there might be a usage for the q value. > Recall that these are "recv" direction attributes, so what can be produced is not in question here. I do see a valid point in that a receiver might want to optionally request a specific aspect ratio on incoming video (perhaps inferred from optional constraints). That seems like a matter for further study, but does not contradict any of the existing text. > C. Section 3.6.1: > > As an example, consider a system with a HD-capable, multiformat video > decoder, where the application has constrained the received track to > at most 360p. In this case, the implemention would generate this > attribute: > > a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] > > Maybe this example should discuss the minimal aspect of this. What it > really is expressing in that it can handle any resolution between 16x16 > pixels up to 640x360 as the longest in respective side. No limitations to > any picture aspect ratio. > I was trying to give a reasonably real-world example. Do you think this is confusing? > > D. Section 3.6.1: > > What about usage of "par" in the sets. I actually expect most have > limitations to perform a scaling that maintain the PAR, not performing > cropping or scaling that warps the picture. > I agree that scaling should be done at 1:1, but not sure exactly what you think ought to be specified here. > > E. Section 3.6: > > I am missing a discussion on how video orientation affects what one > states. Taking the above example with a maximum resolution of 640x360, > which gives a landscape 16:9 PAR. If one rotates this, then it is not clear > if one is allowed to have 360x640 or are limited to 203x360. Or should one > actually state the different orientations maximum resolution and consider > that this is simply different PAR, as 16:9 (Landscape) is 9:16 (Portrait) > two different picture aspect ratios. > This is a good point. I would like to assume the limit applies to the horizontal orientation and the video will be sent in that format, with CVO used to handle rotation (since we are mandating support for CVO). > > > F. Section 4.1.1: > > Regardless of policy, the > application will always try to negotiate BUNDLE onto a single > transport, and will offer a single BUNDLE group across all media > sections. > > I think this sentence may be a bit misleading without additional > sentence(s) to explain that the actual number of established transport > streams will depend on the peer's response to the attempt to bundle. > OK, I am fine with including a sentence to mention the "else" case. > > G. Section 5.2.1: > > This section contains the following: > > > Each m= section MUST include the following attribute lines: > > o If this m= section is for video media, an "a=imageattr" line, as > specified in Section 3.6. > > But, Section 3.6 does not mandate that a=imageattr always is included. > Thus the text must be modified to allow the selective inclusion of the > attribute based on what needs to be said. > I tried to spell this out in 3.6, but if you think it needs to be reiterated here as well that is fine by me. > > H. Section 5.2.1: > > o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, > indicating the SSRC to be used for sending media, along with the > mandatory "cname" source attribute, as specified in Section 6.1, > indicating the CNAME for the source. The CNAME must be generated > in accordance with [RFC7022] and Section 3.5. > > I think this document shouldn't make normative statement to how CNAMEs > shall be generated. That last sentence points to RFC7022, but that is not > the whole story. If you like to point to how CNAMEs are to be generated > then say that Section 4.9 of RTP-usage is the place to determine that. > I just read over 4.9, and I agree. In fact, Section 3.5 in JSEP should probably mostly be a pointer to Section 4.9 in rtp-usage. > > I. Section 5.3.1: > > The next step is to generate lip sync groups as defined in [RFC5888], > Section 7. For each MediaStream with more than one MediaStreamTrack, > a group of type "LS" MUST be added that contains the mid values for > each MediaStreamTrack in that MediaStream. In some cases this may > result in adding a mid to a given LS group that was not in that LS > group in the associated offer. Although this is not allowed by > [RFC5888], it is allowed when implementing this specification. > > > So, do I understand it correctly the violation this paragraph is > discussing is the following from Section 9.2 of RFC5888: > > The > identification-tags contained in this "a=group" line MUST be the same > as those received in the offer, or a subset of them (zero > identification-tags is a valid subset). > > So when will these violations occur for a LS group in JSEP. I assume due > to that offer and answer has different structure of how MediaStreams uses > the different m= lines. But, isn't this just another case of when an > answerer will have to do an follow up Offer to be able to add all the > MediaStreamTracks and their MediaStreams due to different sets on the two > peers? > No. Consider this trivial case: A offers two streams (audio and video), unsynced. B replies with a single stream (with audio and video), to be synced. A will have two (or zero) LS groups, but B wants to have a single LS group with two mid entries. This is not a completely hypothetical case, as A could be a screenshare endpoint. > > I don't really think this specification should override RFC 5888. > I don't see any other way to make this work. > > --089e0122e6aa48b55a0518c2bda0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 16, 2015 at 5:13 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Hi,

I have reviewed the changes between the -09 and -10 versions and have some = comments.

Thanks for the feedback. Comm= ents inline; I will also try to cover any issues identified here in tomorro= w's presentation.

A. Section 3.5:

3.5.=C2=A0 RTP CNAME Semantics

=C2=A0 =C2=A0RTP CNAME values provide a canonical name for the RTP endpoint= ,
=C2=A0 =C2=A0allowing other RTP endpoints to determine which RTP streams ar= e using
=C2=A0 =C2=A0the same clock and thus which clock sources can be used that t= o
=C2=A0 =C2=A0synchronize media playout.

=C2=A0 =C2=A0Any MediaStreamTracks which have different clock sources MUST = have
=C2=A0 =C2=A0different CNAMEs [TODO: need a reference for this.]=C2=A0 Any<= br> =C2=A0 =C2=A0MediaStreamTracks which are in different PeerConnection object= s MUST
=C2=A0 =C2=A0have different CNAMEs; this prevents peers from linking calls = from
=C2=A0 =C2=A0multiple remote PeerConnections based on the CNAME.=C2=A0 For = simplicity,
=C2=A0 =C2=A0MediaStreamTracks in the same PeerConnection which have the sa= me
=C2=A0 =C2=A0clock source SHOULD have the same CNAME.

The main problem is that this is out-of-synch (Pardon the pun) with what RT= P-usage specifies. See Section 4.9:

I think the relevant is the following:

=C2=A0 =C2=A0Taking the discussion in Section 11 into account, a WebRTC End= point
=C2=A0 =C2=A0MUST NOT use more than one RTCP CNAME in the RTP sessions belo= nging
=C2=A0 =C2=A0to single RTCPeerConnection (that is, an RTCPeerConnection for= ms a
=C2=A0 =C2=A0synchronisation context).=C2=A0 RTP middleboxes MAY generate R= TP packet
=C2=A0 =C2=A0streams associated with more than one RTCP CNAME, to allow the= m to
=C2=A0 =C2=A0avoid having to resynchronize media from multiple different en= dpoints
=C2=A0 =C2=A0part of a multi-party RTP session.

So lets look at the normative statements in JSEP:

=C2=A0 "Any MediaStreamTracks which have different clock sources MUST = have
=C2=A0 =C2=A0different CNAMEs [TODO: need a reference for this.]"

This is not allowed by an WebRTC endpoint, which must use only a single CNA= ME. Although a RTP middlebox can forward multiple CNAMEs, the WebRTC endpoi= nt is instead required to perform re-synchronization into the used clock ba= sed of the other streams.

TBH, I wasn&#= 39;t sure exactly where it was mandated that different clock sources transl= ate into different CNAMEs (hence the missing ref). Cullen, do you know?

If there is no problem with using a single CNAME in t= his case, I think that is clearly the simplest thing to do.

<= /div>


=C2=A0 "Any
=C2=A0 =C2=A0MediaStreamTracks which are in different PeerConnection object= s MUST
=C2=A0 =C2=A0have different CNAMEs; this prevents peers from linking calls = from
=C2=A0 =C2=A0multiple remote PeerConnections based on the CNAME."

This one is correct, but I don't quite understand the "this preven= ts peers from linking calls from multiple remote PeerConnections based on t= he CNAME." part. First of all what is a "call". Secondly, wh= at type of linking are you considering here?

"call" may not be the ideal terminology here, but the conce= rn here is an application which makes a connection to peer A with PC A and = then later makes a connection to peer B with PC B. If CNAME was reused, som= eone with knowledge of A and B could see that they received calls from the = same originating endpoint.

=C2=A0


=C2=A0 "For simplicity,
=C2=A0 =C2=A0MediaStreamTracks in the same PeerConnection which have the sa= me
=C2=A0 =C2=A0clock source SHOULD have the same CNAME."

The SHOULD needs to be a MUST.

If we follow= the advice from rtp-usage as mentioned above, I agree.=C2=A0
=C2=A0


B. Section 3.6.1:

=C2=A0 =C2=A0Otherwise, an "a=3Dimageattr" attribute is created w= ith "recv"
=C2=A0 =C2=A0direction, and the resulting resolution space formed by inters= ecting
=C2=A0 =C2=A0the decoder limits and constraints is used to specify its mini= mum and
=C2=A0 =C2=A0maximum x=3D and y=3D values.=C2=A0 If the intersection is the= null set, i.e.,
=C2=A0 =C2=A0there are no resolutions that are permitted by both the decode= r and
=C2=A0 =C2=A0the mandatory constraints, this SHOULD be represented by x=3D0= and y=3D0
=C2=A0 =C2=A0values.

=C2=A0 =C2=A0The rules here express a single set of preferences, and theref= ore,
=C2=A0 =C2=A0the "a=3Dimageattr" q=3D value is not important.=C2= =A0 It SHOULD be set to
=C2=A0 =C2=A01.0.

What about end-points that can produce different aspect ratios on its video= . Such a system is likely to have different constraints on its min and max = resolution in X and Y for 1:1, 4:3, 16:9 and 1:2.35 aspect ratios. It is un= clear if that is allowed, and even recommend practice. And in this case the= re might be a usage for the q value.

Re= call that these are "recv" direction attributes, so what can be p= roduced is not in question here.=C2=A0

I do see a = valid point in that a receiver might want to optionally request a specific = aspect ratio on incoming video (perhaps inferred from optional constraints)= . That seems like a matter for further study, but does not contradict any o= f the existing text.


C. Section 3.6.1:

=C2=A0 =C2=A0As an example, consider a system with a HD-capable, multiforma= t video
=C2=A0 =C2=A0decoder, where the application has constrained the received tr= ack to
=C2=A0 =C2=A0at most 360p.=C2=A0 In this case, the implemention would gener= ate this
=C2=A0 =C2=A0attribute:

=C2=A0 =C2=A0a=3Dimageattr:* recv [x=3D[16:640],y=3D[16:360],q=3D1.0]

Maybe this example should discuss the minimal aspect of this. What it reall= y is expressing in that it can handle any resolution between 16x16 pixels u= p to 640x360 as the longest in respective side. No limitations to any pictu= re aspect ratio.

I was trying to give a= reasonably real-world example. Do you think this is confusing?=C2=A0
=

D. Section 3.6.1:

What about usage of "par" in the sets. I actually expect most hav= e limitations to perform a scaling that maintain the PAR, not performing cr= opping or scaling that warps the picture.

I agree that scaling should be done at 1:1, but not sure exactly what yo= u think ought to be specified here.
=C2=A0

E. Section 3.6:

I am missing a discussion on how video orientation affects what one states.= Taking the above example with a maximum resolution of 640x360, which gives= a landscape 16:9 PAR. If one rotates this, then it is not clear if one is = allowed to have 360x640 or are limited to 203x360. Or should one actually s= tate the different orientations maximum resolution and consider that this i= s simply different PAR, as 16:9 (Landscape) is 9:16 (Portrait) two differen= t picture aspect ratios.

This is a good= point. I would like to assume the limit applies to the horizontal orientat= ion and the video will be sent in that format, with CVO used to handle rota= tion (since we are mandating support for CVO).


F. Section 4.1.1:

=C2=A0 =C2=A0Regardless of policy, the
=C2=A0 =C2=A0application will always try to negotiate BUNDLE onto a single<= br> =C2=A0 =C2=A0transport, and will offer a single BUNDLE group across all med= ia
=C2=A0 =C2=A0sections.

I think this sentence may be a bit misleading without additional sentence(s= ) to explain that the actual number of established transport streams will d= epend on the peer's response to the attempt to bundle.
=

OK, I am fine with including a sentence to mention the = "else" case.
=C2=A0

G. Section 5.2.1:

This section contains the following:


=C2=A0 =C2=A0Each m=3D section MUST include the following attribute lines:<= br>
=C2=A0 =C2=A0o=C2=A0 If this m=3D section is for video media, an "a=3D= imageattr" line, as
=C2=A0 =C2=A0 =C2=A0 specified in Section 3.6.

But, Section 3.6 does not mandate that a=3Dimageattr always is included. Th= us the text must be modified to allow the selective inclusion of the attrib= ute based on what needs to be said.

I t= ried to spell this out in 3.6, but if you think it needs to be reiterated h= ere as well that is fine by me.

H. Section 5.2.1:

=C2=A0 =C2=A0o=C2=A0 An "a=3Dssrc" line, as specified in [RFC5576= ], Section 4.1,
=C2=A0 =C2=A0 =C2=A0 indicating the SSRC to be used for sending media, alon= g with the
=C2=A0 =C2=A0 =C2=A0 mandatory "cname" source attribute, as speci= fied in Section 6.1,
=C2=A0 =C2=A0 =C2=A0 indicating the CNAME for the source.=C2=A0 The CNAME m= ust be generated
=C2=A0 =C2=A0 =C2=A0 in accordance with [RFC7022] and Section 3.5.

I think this document shouldn't make normative statement to how CNAMEs = shall be generated. That last sentence points to RFC7022, but that is not t= he whole story. If you like to point to how CNAMEs are to be generated then= say that Section 4.9 of RTP-usage is the place to determine that.

I just read over 4.9, and I agree. In fact, Sec= tion 3.5 in JSEP should probably mostly be a pointer to Section 4.9 in rtp-= usage.

I. Section 5.3.1:

=C2=A0 =C2=A0The next step is to generate lip sync groups as defined in [RF= C5888],
=C2=A0 =C2=A0Section 7.=C2=A0 For each MediaStream with more than one Media= StreamTrack,
=C2=A0 =C2=A0a group of type "LS" MUST be added that contains the= mid values for
=C2=A0 =C2=A0each MediaStreamTrack in that MediaStream.=C2=A0 In some cases= this may
=C2=A0 =C2=A0result in adding a mid to a given LS group that was not in tha= t LS
=C2=A0 =C2=A0group in the associated offer.=C2=A0 Although this is not allo= wed by
=C2=A0 =C2=A0[RFC5888], it is allowed when implementing this specification.=


So, do I understand it correctly the violation this paragraph is discussing= is the following from Section 9.2 of RFC5888:

=C2=A0 =C2=A0The
=C2=A0 =C2=A0identification-tags contained in this "a=3Dgroup" li= ne MUST be the same
=C2=A0 =C2=A0as those received in the offer, or a subset of them (zero
=C2=A0 =C2=A0identification-tags is a valid subset).

So when will these violations occur for a LS group in JSEP. I assume due to= that offer and answer has different structure of how MediaStreams uses the= different m=3D lines. But, isn't this just another case of when an ans= werer will have to do an follow up Offer to be able to add all the MediaStr= eamTracks and their MediaStreams due to different sets on the two peers?

No. Consider this trivial case: A offers = two streams (audio and video), unsynced. B replies with a single stream (wi= th audio and video), to be synced.

A will have two= (or zero) LS groups, but B wants to have a single LS group with two mid en= tries.=C2=A0

This is not a completely hypothetical= case, as A could be a screenshare endpoint.

I don't really think this specification should override RFC 5888.

I don't see any other way to make this w= ork.=C2=A0

--089e0122e6aa48b55a0518c2bda0-- From nobody Thu Jun 18 02:58:30 2015 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 E7E771B30E8 for ; Thu, 18 Jun 2015 02:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 vSju3_uA2KWA for ; Thu, 18 Jun 2015 02:58:26 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 314A21B30FB for ; Thu, 18 Jun 2015 02:58:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3D6987C320D for ; Thu, 18 Jun 2015 11:58: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 2FijrLaDbt7p for ; Thu, 18 Jun 2015 11:58:21 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:50b7:cd65:abd3:73a8]) by mork.alvestrand.no (Postfix) with ESMTPSA id CC2457C320B for ; Thu, 18 Jun 2015 11:58:21 +0200 (CEST) Message-ID: <5582963D.3010202@alvestrand.no> Date: Thu, 18 Jun 2015 11:58:21 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20150529203722.31896.80860.idtracker@ietfa.amsl.com> <07121297-C275-47D2-909F-7AEE863214B7@ieca.com> In-Reply-To: <07121297-C275-47D2-909F-7AEE863214B7@ieca.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] reminder: webex details: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): June 18, 2015 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, 18 Jun 2015 09:58:29 -0000 Will there be slides? (I don't have a machine (other than my phone) capable of joining webex with the slide display, due to the Java plugin problem, so I'm kind of dependent on the slides being available in an outside channel.) On 06/17/2015 09:14 PM, Sean Turner wrote: > In case you missed it here’s the webex details for the virtual interim meeting tomorrow. > > spt > > Begin forwarded message: > >> From: IESG Secretary >> Subject: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): June 18, 2015 >> Date: May 29, 2015 at 16:37:22 EDT >> To: "IETF Announcement List" >> Cc: rtcweb@ietf.org >> Reply-To: ietf@ietf.org >> >> The Real-Time Communication in WEB-browsers (rtcweb) Working Group >> will hold a virtual interim meeting on Thursday, June 18, 2015, between >> 0900 and 1100 PDT (1600 and 1800 UTC). >> >> JOIN WEBEX MEETING >> https://ietf.webex.com/ietf/j.php?MTID=m165b021236787e79a2e807a31717e8d0 >> >> Meeting number: 649 055 392 >> Meeting password: 1234 >> >> JOIN BY PHONE >> 1-877-668-4493 Call-in toll free number (US/Canada) >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 649 055 392 >> >> Toll-free dialing restrictions: >> http://www.webex.com/pdf/tollfree_restrictions.pdf >> >> Can't join the meeting? Contact support here: >> https://ietf.webex.com/ietf/mc >> >> >> IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting. >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 18 07:04:44 2015 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 00D2D1A92FD for ; Thu, 18 Jun 2015 07:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_19=0.6, 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 HUve5ACRY-H5 for ; Thu, 18 Jun 2015 07:04:34 -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 873631A92F5 for ; Thu, 18 Jun 2015 07:04:31 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-f7-5582cfedf8af Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.58.04401.DEFC2855; Thu, 18 Jun 2015 16:04:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Thu, 18 Jun 2015 16:04:29 +0200 Message-ID: <5582CFEC.7050008@ericsson.com> Date: Thu, 18 Jun 2015 16:04:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Justin Uberti , Cullen Jennings References: <558012DB.4010608@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvre7b802hBjP2mFrM71jHZtExmc1i 61Qhi7X/2tkdWDym/N7I6rFgU6nHkiU/mTy+XP7MFsASxWWTkpqTWZZapG+XwJWxYOFepoKv xRXz7x1mb2A8FdbFyMkhIWAi0fnnOxuELSZx4d56IJuLQ0jgKKPE8e/fWSCc5YwSvTsXMYFU 8QpoS+xZ3QDWwSKgKnF2+Tp2EJtNwELi5o9GsLioQJTE1MfrWCDqBSVOznwCZosIeEn8WHYM bA6zQJDE2VtrmEFsYQFriSmfD4D1CgkUSBxe+ZoVxOYUCJTYvGg2C0S9hcTM+ecZIWx5ieat s5kh6rUlGpo6WCcwCs5Csm4WkpZZSFoWMDKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAgM 6YNbfqvuYLz8xvEQowAHoxIPr4JaU6gQa2JZcWXuIUZpDhYlcd4Zm/NChQTSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTAW8s1fxv3MJGe3dlL8FO9v3yYYa09smc6+fY+voWF4pdzzTeoCq/1l 57xbwa7+Xc7h87fNDW9Ef2384v15dkBxtM1dKcGSWD2NKcUxCz9sbRevmPoze7Wuhrefntvq hPpbSkc9PJYuKV41seCx64qoaq919yYeiex0/tv+VWPZovnicT6N07YrsRRnJBpqMRcVJwIA AWxvQkoCAAA= Archived-At: Cc: draft-ietf-rtcweb-jsep@tools.ietf.org, "rtcweb@ietf.org" Subject: Re: [rtcweb] Comments on draft-ietf-rtcweb-jsep-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: Thu, 18 Jun 2015 14:04:37 -0000 Hi, Please see inline. I will add these to the github issue tracker. Justin Uberti skrev den 2015-06-18 05:52: > > > On Tue, Jun 16, 2015 at 5:13 AM, Magnus Westerlund > > > wrote: > > Hi, > > I have reviewed the changes between the -09 and -10 versions and > have some comments. > > > Thanks for the feedback. Comments inline; I will also try to cover any > issues identified here in tomorrow's presentation. > > > A. Section 3.5: > > 3.5. RTP CNAME Semantics > > RTP CNAME values provide a canonical name for the RTP endpoint, > allowing other RTP endpoints to determine which RTP streams are > using > the same clock and thus which clock sources can be used that to > synchronize media playout. > > Any MediaStreamTracks which have different clock sources MUST have > different CNAMEs [TODO: need a reference for this.] Any > MediaStreamTracks which are in different PeerConnection objects MUST > have different CNAMEs; this prevents peers from linking calls from > multiple remote PeerConnections based on the CNAME. For simplicity, > MediaStreamTracks in the same PeerConnection which have the same > clock source SHOULD have the same CNAME. > > The main problem is that this is out-of-synch (Pardon the pun) with > what RTP-usage specifies. See Section 4.9: > > I think the relevant is the following: > > Taking the discussion in Section 11 into account, a WebRTC Endpoint > MUST NOT use more than one RTCP CNAME in the RTP sessions belonging > to single RTCPeerConnection (that is, an RTCPeerConnection forms a > synchronisation context). RTP middleboxes MAY generate RTP packet > streams associated with more than one RTCP CNAME, to allow them to > avoid having to resynchronize media from multiple different > endpoints > part of a multi-party RTP session. > > So lets look at the normative statements in JSEP: > > "Any MediaStreamTracks which have different clock sources MUST have > different CNAMEs [TODO: need a reference for this.]" > > This is not allowed by an WebRTC endpoint, which must use only a > single CNAME. Although a RTP middlebox can forward multiple CNAMEs, > the WebRTC endpoint is instead required to perform > re-synchronization into the used clock based of the other streams. > > > TBH, I wasn't sure exactly where it was mandated that different clock > sources translate into different CNAMEs (hence the missing ref). Cullen, > do you know? Depends of what one means with clock sources. However, in RTP one need to be able to provide the RTP Timestamp value of media source in relation to the endpoints reference clock (in NTP format). All SSRCs with the same CNAME needs to have the same reference clock otherwise they are not possible to synchronize. > > If there is no problem with using a single CNAME in this case, I think > that is clearly the simplest thing to do. Clearly re-synchronization is not trivial, but there are complexities with having WebRTC endpoint sending multiple synchronization contexts also. But, I expect that at some point in the future one might want to change this behaviour. > > > > "Any > MediaStreamTracks which are in different PeerConnection objects MUST > have different CNAMEs; this prevents peers from linking calls from > multiple remote PeerConnections based on the CNAME." > > This one is correct, but I don't quite understand the "this prevents > peers from linking calls from multiple remote PeerConnections based > on the CNAME." part. First of all what is a "call". Secondly, what > type of linking are you considering here? > > > "call" may not be the ideal terminology here, but the concern here is an > application which makes a connection to peer A with PC A and then later > makes a connection to peer B with PC B. If CNAME was reused, someone > with knowledge of A and B could see that they received calls from the > same originating endpoint. I think my main problem was the usage of call. In grouping taxonomy I think you are talking about Multimedia Sessions. But, can't you simply talk about PeerConnections. The grouping taxonomies larger term is communication session, which would be potentially multiple multimedia sessions (PCs) with a common context. The tracking issue you are talking about is already covered in Section 4.9 of RTP usage: Accordingly, a WebRTC Endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a single exception; if explicitly requested at creation an RTCPeerConnection MAY use the same CNAME as as an existing RTCPeerConnection within their common same-origin context. > > > > "For simplicity, > MediaStreamTracks in the same PeerConnection which have the same > clock source SHOULD have the same CNAME." > > The SHOULD needs to be a MUST. > > > If we follow the advice from rtp-usage as mentioned above, I agree. I think you have no choice! JSEP can't override other documents at will. > > > > B. Section 3.6.1: > > Otherwise, an "a=imageattr" attribute is created with "recv" > direction, and the resulting resolution space formed by intersecting > the decoder limits and constraints is used to specify its > minimum and > maximum x= and y= values. If the intersection is the null set, > i.e., > there are no resolutions that are permitted by both the decoder and > the mandatory constraints, this SHOULD be represented by x=0 and y=0 > values. > > The rules here express a single set of preferences, and therefore, > the "a=imageattr" q= value is not important. It SHOULD be set to > 1.0. > > What about end-points that can produce different aspect ratios on > its video. Such a system is likely to have different constraints on > its min and max resolution in X and Y for 1:1, 4:3, 16:9 and 1:2.35 > aspect ratios. It is unclear if that is allowed, and even recommend > practice. And in this case there might be a usage for the q value. > > > Recall that these are "recv" direction attributes, so what can be > produced is not in question here. But, a=imageattr can express send direction limiations also. That is not discussed currently. And also for receiving an receiver can have different capabilites depending on picture aspect rate. > > I do see a valid point in that a receiver might want to optionally > request a specific aspect ratio on incoming video (perhaps inferred from > optional constraints). That seems like a matter for further study, but > does not contradict any of the existing text. That is one possibility, the other is that one actually have limiations that vary with what PAR is to be used. > > > C. Section 3.6.1: > > As an example, consider a system with a HD-capable, multiformat > video > decoder, where the application has constrained the received track to > at most 360p. In this case, the implemention would generate this > attribute: > > a=imageattr:* recv [x=[16:640],y=[16:360],q=1.0] > > Maybe this example should discuss the minimal aspect of this. What > it really is expressing in that it can handle any resolution between > 16x16 pixels up to 640x360 as the longest in respective side. No > limitations to any picture aspect ratio. > > > I was trying to give a reasonably real-world example. Do you think this > is confusing? No, it is not confusing, but I think it could be more explicit and also mention what else it says, not only the maximum, but also a minimal of 16x16 pixels with 1 pixel steps in both directions. > > > D. Section 3.6.1: > > What about usage of "par" in the sets. I actually expect most have > limitations to perform a scaling that maintain the PAR, not > performing cropping or scaling that warps the picture. > > > I agree that scaling should be done at 1:1, but not sure exactly what > you think ought to be specified here. I think the important to make clear is that limitations may be PAR dependent. > > > E. Section 3.6: > > I am missing a discussion on how video orientation affects what one > states. Taking the above example with a maximum resolution of > 640x360, which gives a landscape 16:9 PAR. If one rotates this, then > it is not clear if one is allowed to have 360x640 or are limited to > 203x360. Or should one actually state the different orientations > maximum resolution and consider that this is simply different PAR, > as 16:9 (Landscape) is 9:16 (Portrait) two different picture aspect > ratios. > > > This is a good point. I would like to assume the limit applies to the > horizontal orientation and the video will be sent in that format, with > CVO used to handle rotation (since we are mandating support for CVO). So you are saying is that if one have y=[16:640], y=[16:360] then one should be capable of handling a 90 degrees rotated video that has to display in portrait. It needs to be specified, lets see if you get protests on that interpretation. > > > > F. Section 4.1.1: > > Regardless of policy, the > application will always try to negotiate BUNDLE onto a single > transport, and will offer a single BUNDLE group across all media > sections. > > I think this sentence may be a bit misleading without additional > sentence(s) to explain that the actual number of established > transport streams will depend on the peer's response to the attempt > to bundle. > > > OK, I am fine with including a sentence to mention the "else" case. > > > G. Section 5.2.1: > > This section contains the following: > > > Each m= section MUST include the following attribute lines: > > o If this m= section is for video media, an "a=imageattr" line, as > specified in Section 3.6. > > But, Section 3.6 does not mandate that a=imageattr always is > included. Thus the text must be modified to allow the selective > inclusion of the attribute based on what needs to be said. > > > I tried to spell this out in 3.6, but if you think it needs to be > reiterated here as well that is fine by me. The issue is that the structure results in contradiciting the Section 3.6 thus I think one need to consider if one needs to change the formulation of the MUST statement or the bullet to avoid that. > > > H. Section 5.2.1: > > o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, > indicating the SSRC to be used for sending media, along with the > mandatory "cname" source attribute, as specified in Section 6.1, > indicating the CNAME for the source. The CNAME must be generated > in accordance with [RFC7022] and Section 3.5. > > I think this document shouldn't make normative statement to how > CNAMEs shall be generated. That last sentence points to RFC7022, but > that is not the whole story. If you like to point to how CNAMEs are > to be generated then say that Section 4.9 of RTP-usage is the place > to determine that. > > > I just read over 4.9, and I agree. In fact, Section 3.5 in JSEP should > probably mostly be a pointer to Section 4.9 in rtp-usage. Please do. > > > I. Section 5.3.1: > > The next step is to generate lip sync groups as defined in > [RFC5888], > Section 7. For each MediaStream with more than one > MediaStreamTrack, > a group of type "LS" MUST be added that contains the mid values for > each MediaStreamTrack in that MediaStream. In some cases this may > result in adding a mid to a given LS group that was not in that LS > group in the associated offer. Although this is not allowed by > [RFC5888], it is allowed when implementing this specification. > > > So, do I understand it correctly the violation this paragraph is > discussing is the following from Section 9.2 of RFC5888: > > The > identification-tags contained in this "a=group" line MUST be the > same > as those received in the offer, or a subset of them (zero > identification-tags is a valid subset). > > So when will these violations occur for a LS group in JSEP. I assume > due to that offer and answer has different structure of how > MediaStreams uses the different m= lines. But, isn't this just > another case of when an answerer will have to do an follow up Offer > to be able to add all the MediaStreamTracks and their MediaStreams > due to different sets on the two peers? > > > No. Consider this trivial case: A offers two streams (audio and video), > unsynced. B replies with a single stream (with audio and video), to be > synced. > > A will have two (or zero) LS groups, but B wants to have a single LS > group with two mid entries. > > This is not a completely hypothetical case, as A could be a screenshare > endpoint. Thanks for providing cases when it can occur. > > > I don't really think this specification should override RFC 5888. > > > I don't see any other way to make this work. > There is one obvious solution, the answering part needs to initiate an offer by themselves. We have several such cases already, for example answer adding more media streams than the offer. And you have previously argued that a negotiation isn't that expensive, so I see that is the reasonable way of handling this limiation. I think we shouldn't override RFC5888 due to implications that has on WebRTC endpoint to WebRTC compatible endpoints. It can make them throw up if they do support LS groups. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jun 18 07:30:31 2015 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 DD6AC1B3250 for ; Thu, 18 Jun 2015 07:30: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, 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 fCs6EkBAp0l5 for ; Thu, 18 Jun 2015 07:30:27 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.61.9]) (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 36B101B3217 for ; Thu, 18 Jun 2015 07:30:27 -0700 (PDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 73E1F1DE1D93B for ; Thu, 18 Jun 2015 09:30:21 -0500 (CDT) Received: from [96.231.223.98] (port=57200 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z5apg-0002NJ-M1; Thu, 18 Jun 2015 09:30:20 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <5582963D.3010202@alvestrand.no> Date: Thu, 18 Jun 2015 10:30:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150529203722.31896.80860.idtracker@ietfa.amsl.com> <07121297-C275-47D2-909F-7AEE863214B7@ieca.com> <5582963D.3010202@alvestrand.no> To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.223.98 X-Exim-ID: 1Z5apg-0002NJ-M1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.223.98]:57200 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] reminder: webex details: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): June 18, 2015 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, 18 Jun 2015 14:30:29 -0000 I uploaded the preso to = http://www.ietf.org/proceedings/interim/2015/06/18/rtcweb/proceedings.html= spt On Jun 18, 2015, at 05:58, Harald Alvestrand = wrote: > Will there be slides? >=20 > (I don't have a machine (other than my phone) capable of joining = webex with the slide display, due to the Java plugin problem, so I'm = kind of dependent on the slides being available in an outside channel.) >=20 > On 06/17/2015 09:14 PM, Sean Turner wrote: >> In case you missed it here=92s the webex details for the virtual = interim meeting tomorrow. >>=20 >> spt >>=20 >> Begin forwarded message: >>=20 >>> From: IESG Secretary >>> Subject: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): = June 18, 2015 >>> Date: May 29, 2015 at 16:37:22 EDT >>> To: "IETF Announcement List" >>> Cc: rtcweb@ietf.org >>> Reply-To: ietf@ietf.org >>>=20 >>> The Real-Time Communication in WEB-browsers (rtcweb) Working Group >>> will hold a virtual interim meeting on Thursday, June 18, 2015, = between >>> 0900 and 1100 PDT (1600 and 1800 UTC). >>>=20 >>> JOIN WEBEX MEETING >>> = https://ietf.webex.com/ietf/j.php?MTID=3Dm165b021236787e79a2e807a31717e8d0= >>>=20 >>> Meeting number: 649 055 392 >>> Meeting password: 1234 >>>=20 >>> JOIN BY PHONE >>> 1-877-668-4493 Call-in toll free number (US/Canada) >>> 1-650-479-3208 Call-in toll number (US/Canada) >>> Access code: 649 055 392 >>>=20 >>> Toll-free dialing restrictions: >>> http://www.webex.com/pdf/tollfree_restrictions.pdf >>>=20 >>> Can't join the meeting? Contact support here: >>> https://ietf.webex.com/ietf/mc >>>=20 >>>=20 >>> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. You should inform all meeting = attendees prior to recording if you intend to record the meeting. >>>=20 >> _______________________________________________ >> 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 From nobody Thu Jun 18 08:55:34 2015 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 AB3AB1AD05D for ; Thu, 18 Jun 2015 08:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 58vgCupPHriU for ; Thu, 18 Jun 2015 08:55:29 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.176.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534D71B32CB for ; Thu, 18 Jun 2015 08:54:38 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 2DA99B9A663D5; Thu, 18 Jun 2015 10:54:37 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 1F1BFB9A66399 for ; Thu, 18 Jun 2015 10:54:37 -0500 (CDT) Received: from [96.231.223.98] (port=57758 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z5c9E-0004Uw-DO for rtcweb@ietf.org; Thu, 18 Jun 2015 10:54:36 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <07121297-C275-47D2-909F-7AEE863214B7@ieca.com> Date: Thu, 18 Jun 2015 11:54:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150529203722.31896.80860.idtracker@ietfa.amsl.com> <07121297-C275-47D2-909F-7AEE863214B7@ieca.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.223.98 X-Exim-ID: 1Z5c9E-0004Uw-DO X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.223.98]:57758 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [rtcweb] reminder: webex details: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): June 18, 2015 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, 18 Jun 2015 15:55:31 -0000 Meeting starts in about 5 minutes. spt On Jun 17, 2015, at 15:14, Sean Turner wrote: > In case you missed it here=92s the webex details for the virtual = interim meeting tomorrow. >=20 > spt >=20 > Begin forwarded message: >=20 >> From: IESG Secretary >> Subject: RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): = June 18, 2015 >> Date: May 29, 2015 at 16:37:22 EDT >> To: "IETF Announcement List" >> Cc: rtcweb@ietf.org >> Reply-To: ietf@ietf.org >>=20 >> The Real-Time Communication in WEB-browsers (rtcweb) Working Group=20 >> will hold a virtual interim meeting on Thursday, June 18, 2015, = between=20 >> 0900 and 1100 PDT (1600 and 1800 UTC). >>=20 >> JOIN WEBEX MEETING >> = https://ietf.webex.com/ietf/j.php?MTID=3Dm165b021236787e79a2e807a31717e8d0= >>=20 >> Meeting number: 649 055 392 >> Meeting password: 1234 >>=20 >> JOIN BY PHONE >> 1-877-668-4493 Call-in toll free number (US/Canada)=20 >> 1-650-479-3208 Call-in toll number (US/Canada) >> Access code: 649 055 392 >>=20 >> Toll-free dialing restrictions:=20 >> http://www.webex.com/pdf/tollfree_restrictions.pdf >>=20 >> Can't join the meeting? Contact support here: >> https://ietf.webex.com/ietf/mc >>=20 >>=20 >> IMPORTANT NOTICE: Please note that this WebEx service allows audio = and other information sent during the session to be recorded, which may = be discoverable in a legal matter. You should inform all meeting = attendees prior to recording if you intend to record the meeting. >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 18 11:00:52 2015 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 36AFD1B2B4A for ; Thu, 18 Jun 2015 11:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.511 X-Spam-Level: X-Spam-Status: No, score=-112.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 zLqRDL5XnrFN for ; Thu, 18 Jun 2015 11:00:48 -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 B23581B2B31 for ; Thu, 18 Jun 2015 11:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3140; q=dns/txt; s=iport; t=1434650448; x=1435860048; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2e5gz+/uqjkpbikrhp2hkQv9z5R54fN/74tw5ltb/dU=; b=YmWtp0WelHS6rkn6HcSdllEzD0ySDbDGpLzGGdq3u9DfMXYw830xJ5ki cm3J0pfHd+38YqLSfRpIKcQY/RN/bHUxdJTpODTr7Acexu7G9q5VQGvNi MyRwxaDZKZHDK08PvaBCw8tKoTLYOolKu+IXPlYUICjGk93rQbK9pzGA6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AZBQADB4NV/4kNJK1cgxBUZb9chXyBPjwQAQEBAQEBAYEKhCUEOj8SAT5CJwQOiDQNxiMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI0Cg0mDHoEUBZNwAYRShniBNYcWj1smghiBYYI1gQIBAQE X-IronPort-AV: E=Sophos;i="5.13,640,1427760000"; d="scan'208";a="4684746" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 18 Jun 2015 18:00:37 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5II0bXO019297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jun 2015 18:00:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.175]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 18 Jun 2015 13:00:37 -0500 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Cullen Notes from RTCWeb interim on June 18, 2015 Thread-Index: AQHQqfCtcbh3jP6YIUqueUzbk8fzYQ== Date: Thu, 18 Jun 2015 18:00:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [rtcweb] Cullen Notes from RTCWeb interim on June 18, 2015 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, 18 Jun 2015 18:00:50 -0000 These are just my rough notes and chairs will form minutes from everything = we get * make sure to add note well slide to slide deck=20 LS Behavior=20 - Magnus points out that if JSEP overrides 5888, we will have issue with le= gacy things - Martin points needs more thought to make declarative groups - Martin raised point that we might be able to add some extra signaling tha= t indicates that we can support this declarative LS usage=20 Conclusion: Magnus will dig into more analysis of options on this and send = to list. No decision on Option 1,2=20 ImageAttr specification (receiver) - people are good on what we send (intersection) - do need to talk more about with receiving min or not=20 b=3D slide=20 - no issues c=3D slide=20 - no issue=20 Note :: does not work in c line but the 0.0.0.0 does=20 Moving on to Open Issue slides=20 Issue #9 - changing b=3D Do we need to deal with bs=3DRS/RR=20 Magnus - reason to honor this... consider use case with middle box where mi= ddle box wants to tune RTCP to ensure the middle box gets enough feedback. = 5% is a problem if you want rapid feedback and low bit rate media. So you m= ight want to use this to up it.=20 Randal - might want to be up this above 5% to improve bandwidth estimation Magnus - thinks we need to be able to set them and have endpoint honor them= =20 Randal - use case is what if you want to send feedback on every frame of a = video for some congestion control use case Justin - hard to implement and not clear at this point Randal - propose what we implement now is if you receive this, you will not= go over the specified value (but does not mean that the implementation wou= ld necessarily send more) Magnus propose. Browsers set it (at default 5% is fine). This allows middle= boxes to change. And browsers interpret it and do not exceed it.=20 Conclusion: browser need to be able to receive RS/RR and honor it=20 #144 b=3D at session level - no objections #122 b=3DTIAS=20 - OK with this=20 #148/149 a=3Dssrc - Question can we list both and switch ?=20 - read more in https://tools.ietf.org/html/rfc7160 - HTA raise point that switching is not going to happen in a session with s= imulcast=20 - HTA proposal, if on a session that is not simulcast, and you see a SSRC s= witch, just deal with it Next steps: go study what this hybrid approach would look like=20 # question on imageattr - what happens when rotate Proposal: always send image attr in landscape and rely on CVO for rotations= . We need to take this idea and circulate widely (such as 3GPP). Randal - what if native is not rotated.=20 CVO is Coordination of Video Orientation (CVO) section 7.4.5 of [TS26.114] Probably needs some offline discussion.=20 Magnus will see if he can get someone to explain where the 3GPP and related= standards are on this.=20 #16 Accessors=20 - no comments Skip forward to last slide on Upscaling video=20 Conclusion: - we add some sort of switch that sets if upscale is allowed or not - default is to allow upscale=20 From nobody Thu Jun 18 11:12:12 2015 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 1003C1B2B60 for ; Thu, 18 Jun 2015 11:12:11 -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 hbaHPMiOyYPA for ; Thu, 18 Jun 2015 11:12:09 -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 D63E81B2B4B for ; Thu, 18 Jun 2015 11:12:08 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-43-558309f677a1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 10.1C.17665.6F903855; Thu, 18 Jun 2015 20:12:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Thu, 18 Jun 2015 20:12:06 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGA== Date: Thu, 18 Jun 2015 18:12:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F266AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre53zuZQg/0X2CzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqam4ywF51Uq/s6fztjAeFG+i5GTQ0LARGL+uldsELaYxIV7 64FsLg4hgaOMEq+e/oVyFjNK3FnTAeRwcLAJWEh0/9MGaRARUJe4/PACO4gtLKAhcXr6cRaQ EhEBXYl9nW4QJXoSN1euAJvPIqAqsfzBaWYQm1fAV2LT0bdMIDYj0N7vp9aA2cwC4hK3nsxn grhHQGLJnvPMELaoxMvH/1ghbCWJtYe3s0DU50tsaX/NBjFTUOLkzCcsExiFZiEZNQtJ2Swk ZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkm RmBEHNzyW3cH4+rXjocYBTgYlXh4FdSaQoVYE8uKK3MPMUpzsCiJ887YnBcqJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgZEjkntGo5DhU35VgbP71l2sXvog4p3IAp6cU2VfVIunHeRaVr9C ce21kvM7zjc8+iDzI7jvh/C1+oZJPGzTDlXd3iIp+/Bpef329muP4rQe2LJafnxyatKGl95c 518e1DZ8duo5d+O8VS+q8rjOPuRm3yk5o/tl/pT/n/weSfREXn9zd/b9xRJ+SizFGYmGWsxF xYkArwqXLGkCAAA= Archived-At: Subject: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 18:12:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F266AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I had a look at the latest version (-14) of the consent-freshness draft. The keep-alive issue we discussed earlier seems to be solved now. However, I thought we were also going to add text saying that consent is on= ly needed while media is sent on a given candidate pair, and allow the send= er to stop sending consent requests when no data is sent on a candidate pai= r. Then, if the sender later wants to start sending media on the candidate = pair again, it simply start sending consent requests again. However, the way I read the draft now is that it would require an ICE resta= rt, and I don't think we want that? I think that ICE restart should only be required if the sender DOES send co= nsent requests, but do not receive any response within 30 seconds. Or, have I missed something? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D8F266AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I had a look at the latest version (-14) of the cons= ent-freshness draft.

 

The keep-alive issue we discussed earlier seems to b= e solved now.

 

However, I thought we were also going to add text sa= ying that consent is only needed while media is sent on a given candidate p= air, and allow the sender to stop sending consent requests when no data is = sent on a candidate pair. Then, if the sender later wants to start sending media on the candidate pair again,= it simply start sending consent requests again.

 

However, the way I read the draft now is that it wou= ld require an ICE restart, and I don’t think we want that?=

 

I think that ICE restart should only be required if = the sender DOES send consent requests, but do not receive any response with= in 30 seconds.

 

Or, have I missed something?

 

Regards,

 

Christer

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D8F266AESESSMB209erics_-- From nobody Thu Jun 18 11:23:28 2015 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 D918F1B2C5E for ; Thu, 18 Jun 2015 11:23: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 qG4QrqwH0_4P for ; Thu, 18 Jun 2015 11:23:25 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268EB1B2C31 for ; Thu, 18 Jun 2015 11:23:25 -0700 (PDT) Received: by ykdr198 with SMTP id r198so73473585ykd.3 for ; Thu, 18 Jun 2015 11:23:24 -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=6w81i8niddkepM5Z1nzGDMx7QllwGvusJizxwXd3ugQ=; b=KViofhNzBNpVcuJhuTfVCcBO0ba2GhM0VG6rN1VRyAGJIW/VoSV05R801pYhSpE1Go WYjEXFEAgBPm1GcRN1rwMzZFX8cotUdYT0+jbGv6nLcGQyFA+UY030Tkz3scvVoPFli+ mgOTPPgsL5MxT4qNEPq1llCz8jwOor2VWIvVOHOKOGreil7kGKifVFDcDOxdR8c0+s3z neYd9iVQYJR9fUauZwoIDy740tAr9XmKjlXnt/mc6RIlKwCVoJL0atQwKK+768Y2dpbP bPma8lmqq2GCe4eKp2Q6FsGtc1KcI6tI+Bk+LXm+HAs2Wqhlx9EkfaDfVUBH6Ed5Oq8j hnPg== MIME-Version: 1.0 X-Received: by 10.129.97.213 with SMTP id v204mr15114168ywb.56.1434651804541; Thu, 18 Jun 2015 11:23:24 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Thu, 18 Jun 2015 11:23:24 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> Date: Thu, 18 Jun 2015 11:23:24 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 18:23:27 -0000 On 18 June 2015 at 11:12, Christer Holmberg wrote: > Then, if the sender later wants to start sending media on the candidate p= air > again, it simply start sending consent requests again. >From a security perspective, this would be OK. Functionally however, do you really expect that to work? NATs and relays tend to garbage collect pretty aggressively. > However, the way I read the draft now is that it would require an ICE > restart, and I don=E2=80=99t think we want that? Why the question? You are the one who has to decide if you want that. Seriously, given the above, I would rather say that if you don't use it, you lose it. Are you concerned about the cost of an ICE restart, or the cost of maintaining consent? From nobody Thu Jun 18 11:44:11 2015 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 3A0FF1A90D7 for ; Thu, 18 Jun 2015 11:44:10 -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 gLVo1Mg9NAgP for ; Thu, 18 Jun 2015 11:44:08 -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 4CB891A903C for ; Thu, 18 Jun 2015 11:44:08 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-cf-558311763a7c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4E.8A.04401.67113855; Thu, 18 Jun 2015 20:44:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0210.002; Thu, 18 Jun 2015 20:44:06 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgA///aitA= Date: Thu, 18 Jun 2015 18:44:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> 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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvrW6ZYHOowa4F6hbXzvxjtFj7r53d gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4tuUKW8ESvopvJz4wNjB+4e1i5OSQEDCR uPZiMiOELSZx4d56ti5GLg4hgaOMEs96TjNBOIsZJc78bGbpYuTgYBOwkOj+pw3SICKgK7Ho 7AN2EJtZQF3izuJzYLawgKnEmstzmCFqzCRaz85khbCtJDafXgUWZxFQlfjR3sYGYvMK+Eq0 flgFtWsKo8T2i0fAdnEKBEq8u2sOUsMIdNz3U2uYIHaJS9x6Mp8J4mgBiSV7zjND2KISLx// Y4WwlSRWbL/ECDKGWUBTYv0ufYhWRYkp3Q/ZIdYKSpyc+YRlAqPYLCRTZyF0zELSMQtJxwJG llWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgbFzcMtv1R2Ml984HmIU4GBU4uFVUGsKFWJN LCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRtff/kwVJ/fa/bYV NlWr4Xte8TTLVOr39uiois/m55lKVEumzi1vXH/VpsBCYXas1t0wtszzXTsdlhetcPEKk9W+ Z7X2/csVEW9yE0qE1hrcSIi7KmLLaNXwtblme5iZXFVTZpnTrN6957yFPm6bsDDo3Cfx/f0S hwteHvKUebbxw8wMjg3LlViKMxINtZiLihMBZhUFLH4CAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 18:44:10 -0000 SGksDQoNCj4+IFRoZW4sIGlmIHRoZSBzZW5kZXIgbGF0ZXIgd2FudHMgdG8gc3RhcnQgc2VuZGlu ZyBtZWRpYSBvbiB0aGUgDQo+PiBjYW5kaWRhdGUgcGFpciBhZ2FpbiwgaXQgc2ltcGx5IHN0YXJ0 IHNlbmRpbmcgY29uc2VudCByZXF1ZXN0cyBhZ2Fpbi4NCj4NCj4gRnJvbSBhIHNlY3VyaXR5IHBl cnNwZWN0aXZlLCB0aGlzIHdvdWxkIGJlIE9LLiAgRnVuY3Rpb25hbGx5IGhvd2V2ZXIsIGRvIHlv dSByZWFsbHkgZXhwZWN0IHRoYXQgdG8gd29yaz8gIA0KPiBOQVRzIGFuZCByZWxheXMgdGVuZCB0 byBnYXJiYWdlIGNvbGxlY3QgcHJldHR5IGFnZ3Jlc3NpdmVseS4NCg0KWW91IHdvdWxkIHN0aWxs IHNlbmQga2VlcC1hbGl2ZXMsIGluIG9yZGVyIHRvIGtlZXAgdGhlIE5BVCBiaW5kaW5ncyBvcGVu Lg0KDQo+PiBIb3dldmVyLCB0aGUgd2F5IEkgcmVhZCB0aGUgZHJhZnQgbm93IGlzIHRoYXQgaXQg d291bGQgcmVxdWlyZSBhbiBJQ0UgDQo+PiByZXN0YXJ0LCBhbmQgSSBkb27igJl0IHRoaW5rIHdl IHdhbnQgdGhhdD8NCj4NCj4gV2h5IHRoZSBxdWVzdGlvbj8gIFlvdSBhcmUgdGhlIG9uZSB3aG8g aGFzIHRvIGRlY2lkZSBpZiB5b3Ugd2FudCB0aGF0Lg0KPg0KPiBTZXJpb3VzbHksIGdpdmVuIHRo ZSBhYm92ZSwgSSB3b3VsZCByYXRoZXIgc2F5IHRoYXQgaWYgeW91IGRvbid0IHVzZSBpdCwgeW91 IGxvc2UgaXQuICANCj4gQXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgdGhlIGNvc3Qgb2YgYW4gSUNF IHJlc3RhcnQsIG9yIHRoZSBjb3N0IG9mIG1haW50YWluaW5nIGNvbnNlbnQ/DQoNCkJvdGgsIGFj dHVhbGx5IDopDQoNClJlZ2FyZGluZyBJQ0UgcmVzdGFydCwgaXQgcmVxdWlyZXMgYW4gb2ZmZXIv YW5zd2VyIHRyYW5zYWN0aW9uLiBTbywgZXZlcnkgdGltZSB5b3Ugc3dpdGNoIGZyb20gYSBjYW5k aWRhdGUgcGFpciB0byBhbm90aGVyLCBpZiBjb25zZW50IGhhcyBleHBpcmVkIG9uIHRoZSBjYW5k aWRhdGUgcGFpciB5b3Ugc3dpdGNoIHRvLCB5b3UgaGF2ZSB0byBkbyBhbiBvZmZlci9hbnN3ZXIu IA0KDQooSW4gYWRkaXRpb24sIGNhbiB5b3UgZG8gSUNFIHJlc3RhcnQgb24gYSBzaW5nbGUgY2Fu ZGlkYXRlIHBhaXI/KQ0KDQpSZWdhcmRpbmcgbWFpbnRhaW5pbmcgY29uc2VudCwgaWYgd2UgaGF2 ZSBtdWx0aXBsZSBjYW5kaWRhdGUgcGFpcnMsIEkgYW0gd29ycmllZCBhYm91dCB0aGUgY29zdCBv ZiBoYXZpbmcgdG8gbWFpbnRhaW4gY29uc2VudCBvbiBhbGwgb2YgdGhlbSAtIGV2ZW4gaWYgd2Ug YXJlIG9ubHkgdXNpbmcgb25lIGZvciBzZW5kaW5nIGRhdGEgYXQgYW55IGdpdmVuIHRpbWUuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Thu Jun 18 11:48:45 2015 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 EFEE71B2CB3 for ; Thu, 18 Jun 2015 11:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 ZEkopGmJf56w for ; Thu, 18 Jun 2015 11:48:32 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791551B2C89 for ; Thu, 18 Jun 2015 11:48:32 -0700 (PDT) Received: by yhan67 with SMTP id n67so62601542yha.3 for ; Thu, 18 Jun 2015 11:48:32 -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=bPU18j7jjMGDR+CiR2IQRSMwlSX6KLJxkc6SYp3XArQ=; b=FsSVvtlBTtfvqf+bwuGblY6jTPTRGq2eJGc5TQVibd/Q9MvplluXcciBKRNKYYLLyx Xyj5+9dG7cywo2S3jPKIoG9rN5q8MAj2jq9puT4V3eU372M11rTh5R2KxX7x6V2ERb5z FoC7zybmInwOYpT7Mw51chNAurpDTfs72Nh/BIESD9UnSVG8yswbLk1e1FzKvs+zYfmR XOz+ar4BFKlZsQE8elkGASiN6S6qOMdDsNN9H0a4nIc+ZErXOS80fbLvLazXWjOjzbAN xwpSd98y19cAaPWqMBDDMHZTtyJrTADUmgW5qIaAHxXpM81Oa/TxpK0HzfrFWoOwekeE gXVg== MIME-Version: 1.0 X-Received: by 10.170.120.86 with SMTP id m83mr15129863ykb.110.1434653311953; Thu, 18 Jun 2015 11:48:31 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Thu, 18 Jun 2015 11:48:31 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> Date: Thu, 18 Jun 2015 11:48:31 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 18:48:41 -0000 On 18 June 2015 at 11:44, Christer Holmberg wrote: > You would still send keep-alives, in order to keep the NAT bindings open. [...] >> Are you concerned about the cost of an ICE restart, or the cost of maintaining consent? > > Both, actually :) Of course. If you want to put someone on hold, maintaining consent, as opposed to sending keep-alives is not that much of an additional burden. And if you are willing to let the pair go idle and rot, why not require another O/A to restore it. But I don't know your use case. This seems (at least to me) a fairly narrow window, and providing special allowances for it will only increase complexity of implementations. Can you justify making everyone else's life that much worse? From nobody Thu Jun 18 12:14:24 2015 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 B4A791B33DF for ; Thu, 18 Jun 2015 12:14:22 -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 aP0linMe45Ih for ; Thu, 18 Jun 2015 12:14:18 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA4861B33E7 for ; Thu, 18 Jun 2015 12:14:17 -0700 (PDT) Received: by yhpn97 with SMTP id n97so63157980yhp.0 for ; Thu, 18 Jun 2015 12:14:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XeEkeCVJZ9Corlzm2saZAKHWpfKotHXp/9s0QiQErMY=; b=AxPRTSVlVKBBXDPPd3EDIVgVIwh63FIp1ciWlrLtvqV1WVUgO1utuZzbRdK+mG2bcx EAirWONYquG0qZ08nk8zJPW3ZiuRXefDI+hxH2v/ac3WjYUocYHnxkWN1xTu7ZFSRwSb cXMhNvO0K4ajqlbkoswCmofo5O5wVJFkSJL/pOPB8Xjd0s9lV3UTjRUQpfT5+Rps+h92 cy6NiTO6X1JLn/RnxFTqGh4M+Nh1O/vj9uq9vvsZfSaU/K+29+Y00bzs/srBRoIYBhQ6 SFcxNwxzrPQZ2OtQbUQ9G4uYxEmeHs4xUhJnvONhOVLAze5l2d8AdGTlJyudZuNY8Vhh uckQ== X-Received: by 10.129.117.5 with SMTP id q5mr15542583ywc.82.1434654857292; Thu, 18 Jun 2015 12:14:17 -0700 (PDT) Received: from [192.168.1.130] ([71.23.40.3]) by mx.google.com with ESMTPSA id p205sm6761222ywb.7.2015.06.18.12.14.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jun 2015 12:14:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12F69) In-Reply-To: Date: Thu, 18 Jun 2015 15:14:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> To: Martin Thomson Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 19:14:22 -0000 Comments below. > On Jun 18, 2015, at 2:23 PM, Martin Thomson wro= te: >=20 > On 18 June 2015 at 11:12, Christer Holmberg > wrote: >> Then, if the sender later wants to start sending media on the candidate p= air >> again, it simply start sending consent requests again. >=20 >> =46rom a security perspective, this would be OK. Functionally however, > do you really expect that to work? NATs and relays tend to garbage > collect pretty aggressively. It might not work if no keepalives are sent. But Christer's point is that co= nsent is not required since no media is being sent.=20 >> However, the way I read the draft now is that it would require an ICE >> restart, and I don=E2=80=99t think we want that? >=20 > Why the question? You are the one who has to decide if you want that. I think Christer's point is that this should not be considered a loss of con= sent. The draft already says that consent is not needed on a pair if no medi= a is being sent. So one might interpret the existing draft as not imposing a= n ICE restart requirement in that case (how can consent expire if consent is= not required??) > Seriously, given the above, I would rather say that if you don't use > it, you lose it. Are you concerned about the cost of an ICE restart, > or the cost of maintaining consent? [BA] Personally, I think that the existing draft is close to saying what Chr= ister wants (if not already there). I would rather not add text on topics or= thogonal to consent, such as ICE keepalive requirements.= From nobody Thu Jun 18 12:17:14 2015 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 281241A1B07 for ; Thu, 18 Jun 2015 12:17:13 -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 dg-cOADNM-7y for ; Thu, 18 Jun 2015 12:17:12 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189A21A00EE for ; Thu, 18 Jun 2015 12:17:12 -0700 (PDT) Received: by yhak3 with SMTP id k3so63145534yha.2 for ; Thu, 18 Jun 2015 12:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CAXF8Cd4H46Qj+J1ib5CL1WWI4k0R+/eQz9AdXACMi8=; b=I38wjdwsMx7Y6OX0ywdWafHthGLaSu2TxDozheLBHGCj8W3jPDpVON/dZnZbSD/cN0 OrGTVwS0w8+ayOXOtL7ZsVgz99qqypI351IaAVGfZ+pfuwsJkNIT9Rhj8P6nazJR5xrK WtNIdChhKmqbdS4y43NfqgIGTlzyvsFAJsj1v0UntLZqAB0d96YXr5TCR0ysNH9gKJZg NWf1qnTOMc6cWmRwkwH9Z5DMrN2pm/EVuf3szVojv5EpmOYFLaz6ATI//BtQF6t7HM28 i6fN7l9m7/OJSYg46cyC2E7osa2JEAWc4mCJeUZIw+h8j+uNHgmN3+ogV9UOaMTbcK6M j2pw== X-Received: by 10.170.79.5 with SMTP id v5mr15359171ykv.52.1434655031558; Thu, 18 Jun 2015 12:17:11 -0700 (PDT) Received: from [192.168.1.130] ([71.23.40.3]) by mx.google.com with ESMTPSA id o127sm6765808ywd.38.2015.06.18.12.17.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jun 2015 12:17:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12F69) In-Reply-To: Date: Thu, 18 Jun 2015 15:17:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> To: Martin Thomson Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 19:17:13 -0000 On Jun 18, 2015, at 2:48 PM, Martin Thomson wrote= : >=20 > And if you are willing to let the pair go idle and rot, why not > require another O/A to restore it. [BA] Because the candidate pair might still be viable even if consent were n= ot maintained on it while media was suspended (but other RFC 5245 requiremen= ts were met).= From nobody Thu Jun 18 12:21:06 2015 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 B31C71B33FD for ; Thu, 18 Jun 2015 12:21:04 -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 BYcUj5aPcGeu for ; Thu, 18 Jun 2015 12:21:03 -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 E930B1B33FB for ; Thu, 18 Jun 2015 12:21:02 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-ea-55831a1c5d9b Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.81.17665.C1A13855; Thu, 18 Jun 2015 21:21:01 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Thu, 18 Jun 2015 21:21:00 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgA///aitCAACx7gP//2LYA Date: Thu, 18 Jun 2015 19:21:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F28B3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> 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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvra6sVHOowdPJPBbXzvxjtFj7r53d gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4//4Lc8EG4Yrn3yewNTB+EOpi5OSQEDCR WPvvDRuELSZx4d56IJuLQ0jgKKPE58erWCCcxYwSdw7sYO9i5OBgE7CQ6P6nDdIgIqArsejs A3YQm1lAXeLO4nNgtrCAqcSay3OYIWrMJFrPzmSFsN0kdk7eAWazCKhKXPmwkQnE5hXwlZh8 +w0rxK75TBKzHr8Eu4hTIFBi8r0PYIMYga77fmoNE8QycYlbT+YzQVwtILFkz3lmCFtU4uXj f6wQtpLEiu2XGEFuZhbQlFi/Sx+iVVFiSvdDdoi9ghInZz5hmcAoNgvJ1FkIHbOQdMxC0rGA kWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmD0HNzyW3cH4+rXjocYBTgYlXh4FdSaQoVY E8uKK3MPMUpzsCiJ887YnBcqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVH13aTXB3zNKrak t77Kq/i2NKtxfeiXBY98bmhnfq89dO5KVWHgF5vU6ye0vZXdOqe/kjSJ+Dzrlr5Ja3O6qENK h5T0XPllPxnvSTpyLeduir9lsW/SvT9rlW7s5u8xfndLbdb8Ns3TjM+3iQjtzz+yP2HeHc2C ZdOeZ384vs+pXPT+vyUHYsyVWIozEg21mIuKEwHB9YAJfwIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 19:21:04 -0000 SGksDQoNCj4+PiBZb3Ugd291bGQgc3RpbGwgc2VuZCBrZWVwLWFsaXZlcywgaW4gb3JkZXIgdG8g a2VlcCB0aGUgTkFUIGJpbmRpbmdzIG9wZW4uDQo+Pj4gWy4uLl0NCj4+IEFyZSB5b3UgY29uY2Vy bmVkIGFib3V0IHRoZSBjb3N0IG9mIGFuIElDRSByZXN0YXJ0LCBvciB0aGUgY29zdCBvZiBtYWlu dGFpbmluZyBjb25zZW50Pw0KPg0KPiBCb3RoLCBhY3R1YWxseSA6KQ0KPg0KPiBPZiBjb3Vyc2Uu ICBJZiB5b3Ugd2FudCB0byBwdXQgc29tZW9uZSBvbiBob2xkLCBtYWludGFpbmluZyBjb25zZW50 LCBhcyBvcHBvc2VkIHRvIHNlbmRpbmcga2VlcC1hbGl2ZXMgaXMgbm90IHRoYXQgbXVjaCBvZiBh biBhZGRpdGlvbmFsIGJ1cmRlbi4NCg0KSSBhbSBub3QgdGFsa2luZyBhYm91dCBwdXR0aW5nIHNv bWVvbmUgb24gaG9sZCwgaW4gd2hpY2ggY2FzZSB5b3Ugd291bGRuJ3Qgc2VuZCBtZWRpYSBvbiBh bnkgY2FuZGlkYXRlIHBhaXIuIEkgYW0gdGFsa2luZyBhYm91dCBub3Qgc2VuZGluZyBtZWRpYSBv biBjYW5kaWRhdGUgcGFpcnMgWCwgWSBhbmQgWiBiZWNhdXNlIHlvdSBhcmUgc2VuZGluZyBtZWRp YSBvbiBjYW5kaWRhdGUgcGFpciBXLg0KDQo+IEFuZCBpZiB5b3UgYXJlIHdpbGxpbmcgdG8gbGV0 IHRoZSBwYWlyIGdvIGlkbGUgYW5kIHJvdCwgd2h5IG5vdCByZXF1aXJlIGFub3RoZXIgTy9BIHRv IHJlc3RvcmUgaXQuDQoNCkl0IGRlcGVuZHMgb24gaG93IG9mdGVuIHlvdSBzd2l0Y2ggYmV0d2Vl biBjYW5kaWRhdGVzLCBidXQgSSB0aGluayB3ZSBzaG91bGQgYXZvaWQgTy9BIHRyYW5zYWN0aW9u cyBpZiB3ZSBjYW4uIEFsc28sIGFzIHRoaXMgY2FuIGhhcHBlbiBhdCBib3RoIGVuZHBvaW50cywg eW91IGNhbiBlbmQgdXAgd2l0aCBPL0EgcmFjZSBjb25kaXRpb25zLCBhbmQgYWxsIGtpbmQgb2Yg bWVzc3kgc3R1ZmYuDQoNCkFsc28sIGFjY29yZGluZyB0byB0aGUgUkZDIDUyNDUsIHdoaWxlIHRo ZSBJQ0UgcmVzdGFydCB0YWtlcyBwbGFjZSwgeW91IGFyZSBzdGlsbCBzdXBwb3NlZCB0byBiZSBh YmxlIHRvIHVzZSB0aGUgb2xkIGNhbmRpZGF0ZSBwYWlycy4gQnV0LCBpbiB0aGlzIGNhc2UgdGhp cyB3b3VsZCBub3QgYmUgYWxsb3dlZCwgc2luY2UgY29udGVudCBoYXMgZXhwaXJlZCBvbiB0aGUg b2xkIGNhbmRpZGF0ZSBwYWlycy4gRG9lc24ndCB0aGF0IG1lYW4gdGhlcmUgaXMgYSByaXNrIG9m IGNsaXBwaW5nIGV0Yz8NCg0KPkJ1dCBJIGRvbid0IGtub3cgeW91ciB1c2UgY2FzZS4gIFRoaXMg c2VlbXMgKGF0IGxlYXN0IHRvIG1lKSBhIGZhaXJseSBuYXJyb3cgd2luZG93LCBhbmQgcHJvdmlk aW5nIHNwZWNpYWwgYWxsb3dhbmNlcyBmb3IgaXQgd2lsbCBvbmx5IGluY3JlYXNlID5jb21wbGV4 aXR5IG9mIGltcGxlbWVudGF0aW9ucy4gIENhbiB5b3UganVzdGlmeSBtYWtpbmcgZXZlcnlvbmUg ZWxzZSdzIGxpZmUgdGhhdCBtdWNoIHdvcnNlPw0KDQpXaHkgZG8geW91IHRoaW5rIHN0YXJ0IHJl LXVzaW5nIGEgY2FuZGlkYXRlIHBhaXIsIHdpdGhvdXQgaGF2aW5nIHRvIGRvIElDRSByZXN0YXJ0 LCBtYWtlcyBsaXZlcyBoYXJkPyBGcm9tIGV4cGVyaWVuY2UgSSBjYW4gdGVsbCB5b3UgdGhhdCBo YXZpbmcgdG8gZGVhbCB3aXRoIE8vQSByYWNlIGNvbmRpdGlvbnMgZXRjIERPRVMgbWFrZSBsaWZl IGhhcmQgOikNCg0KQW55d2F5LCBJIHRoaW5rIEp1c3RpbiBhbmQgQmVybmFyZCB3ZXJlIHByZXZp b3VzbHkgaW52b2x2ZWQgaW4gdGhlc2UgZGlzY3Vzc2lvbnMsIHNvIEknZCBsaWtlIHRvIGhlYXIg d2hhdCB0aGV5IHRoaW5rLiANCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Thu Jun 18 14:28:26 2015 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 545941B3407 for ; Thu, 18 Jun 2015 14:28:25 -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 9XtQk9gdKIo8 for ; Thu, 18 Jun 2015 14:28:23 -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 6BC551B3403 for ; Thu, 18 Jun 2015 14:28:23 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-8e-558337f5b626 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.E7.04401.5F733855; Thu, 18 Jun 2015 23:28:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Thu, 18 Jun 2015 23:28:21 +0200 From: Christer Holmberg To: Bernard Aboba , Martin Thomson Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74A== Date: Thu, 18 Jun 2015 21:28:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvre5X8+ZQg4bdehYb9v1ntrh25h+j xdp/7ewOzB47Z91l91iy5CdTAFMUl01Kak5mWWqRvl0CV8ai27fZCk4JVsw+dIi9gXGCYBcj J4eEgInExH/zWCFsMYkL99azdTFycQgJHGWUWNO6lRHCWcwocf7fSqAMBwebgIVE9z9tkAYR gQiJ4yvnMoHYzALqEncWn2MHsYUFTCXWXJ7DDFFjJtF6diYrhO0ksejycrAaFgFVicsLOxlB bF4BX4l7+3ezQuw6zijxec5GsGZOAVuJKR97wJoZga77fmoN1DJxiVtP5jNBXC0gsWTPeWYI W1Ti5eN/UN8oSSy6/ZkJ5GZmAU2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJjGKzkEydhdAxC0nH LCQdCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtHBLb9VdzBefuN4iFGAg1GJh1dB rSlUiDWxrLgy9xCjNAeLkjjvjM15oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYvab9mbD0 6gtR05MVr+dtzvaxjrNYHd94bvV8//YZnOsNwg4Wcoh+iXSNsfk0o+/jeQ/eowsW77e6zuy6 Y5nE6U1MjxSTe1gmuV31W3Wq3rlwl2/OHimeZes6rO1ZpeuZd+Q9YVA0C3+2mvFZaciysm95 5qI/przvWeQYoaAxVeal48KG+SzPlFiKMxINtZiLihMB9NB3JoQCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 18 Jun 2015 21:28:25 -0000 SGksDQoNCj4+PiBUaGVuLCBpZiB0aGUgc2VuZGVyIGxhdGVyIHdhbnRzIHRvIHN0YXJ0IHNlbmRp bmcgbWVkaWEgb24gdGhlIA0KPj4+IGNhbmRpZGF0ZSBwYWlyIGFnYWluLCBpdCBzaW1wbHkgc3Rh cnQgc2VuZGluZyBjb25zZW50IHJlcXVlc3RzIGFnYWluLg0KPj4gDQo+PiBGcm9tIGEgc2VjdXJp dHkgcGVyc3BlY3RpdmUsIHRoaXMgd291bGQgYmUgT0suICBGdW5jdGlvbmFsbHkgaG93ZXZlciwN Cj4+IGRvIHlvdSByZWFsbHkgZXhwZWN0IHRoYXQgdG8gd29yaz8gIE5BVHMgYW5kIHJlbGF5cyB0 ZW5kIHRvIGdhcmJhZ2UgDQo+PiBjb2xsZWN0IHByZXR0eSBhZ2dyZXNzaXZlbHkuDQo+DQo+IEl0 IG1pZ2h0IG5vdCB3b3JrIGlmIG5vIGtlZXBhbGl2ZXMgYXJlIHNlbnQuIEJ1dCBDaHJpc3Rlcidz IHBvaW50IGlzIHRoYXQgY29uc2VudCBpcyBub3QgcmVxdWlyZWQgc2luY2Ugbm8gbWVkaWEgaXMg YmVpbmcgc2VudC4gDQoNCkNvcnJlY3QuDQoNCg0KPj4+IEhvd2V2ZXIsIHRoZSB3YXkgSSByZWFk IHRoZSBkcmFmdCBub3cgaXMgdGhhdCBpdCB3b3VsZCByZXF1aXJlIGFuIElDRSANCj4+PiByZXN0 YXJ0LCBhbmQgSSBkb27igJl0IHRoaW5rIHdlIHdhbnQgdGhhdD8NCj4+IA0KPj4gV2h5IHRoZSBx dWVzdGlvbj8gIFlvdSBhcmUgdGhlIG9uZSB3aG8gaGFzIHRvIGRlY2lkZSBpZiB5b3Ugd2FudCB0 aGF0Lg0KPg0KPiBJIHRoaW5rIENocmlzdGVyJ3MgcG9pbnQgaXMgdGhhdCB0aGlzIHNob3VsZCBu b3QgYmUgY29uc2lkZXJlZCBhIGxvc3Mgb2YgY29uc2VudC4NCg0KQ29ycmVjdC4gDQoNCkxvc3Mg b2YgY29uc2VudCBpcyBkZWZpbmVkIGFzIG5vdCByZWNlaXZpbmcgYSByZXNwb25zZSB0byBhIHNl bnQgY29uc2VudCByZXF1ZXN0IC0gYnV0IGluIHRoaXMgY2FzZSB0aGVyZSBpcyBub3QgY29uc2Vu dCByZXF1ZXN0IHNlbnQgdG8gYmVnaW4gd2l0aCA6KQ0KDQo+IFRoZSBkcmFmdCBhbHJlYWR5IHNh eXMgdGhhdCBjb25zZW50IGlzIG5vdCBuZWVkZWQgb24gYSBwYWlyIGlmIG5vIG1lZGlhIGlzIGJl aW5nIHNlbnQuIFNvIG9uZSBtaWdodCANCj4gaW50ZXJwcmV0IHRoZSBleGlzdGluZyBkcmFmdCBh cyBub3QgaW1wb3NpbmcgYW4gSUNFIHJlc3RhcnQgcmVxdWlyZW1lbnQgaW4gdGhhdCBjYXNlICho b3cgY2FuIGNvbnNlbnQgZXhwaXJlIGlmIGNvbnNlbnQgaXMgbm90IHJlcXVpcmVkPz8pDQoNCkNv cnJlY3QuIA0KDQpJIHRoaW5rIGFsbCB0aGF0IGlzIG5lZWRlZCBpcyBhIGNsYXJpZmljYXRpb24g c3RhdGVtZW50IHNheWluZyB0aGF0IHN0b3Agc2VuZGluZyB0byBjb25zZW50IHJlcXVlc3RzIHNo YWxsIG5vdCBiZSBjb25zaWRlcmVkIGxvc3Mgb2YgY29uc2VudCwgYW5kIHRoYXQgYSBzZW5kZXIg Y2FuIGxhdGVyIHJlcXVlc3QgY29uc2VudCBvbiB0aGUgc2FtZSBjYW5kaWRhdGUgcGFpciBhZ2Fp biAtIHdpdGhvdXQgaGF2aW5nIHRvIGRvIGFuIElDRSByZXN0YXJ0Lg0KDQpJQ0UgcmVzdGFydCBp cyBvbmx5IHJlcXVpcmVkIHdoZW4gYSBzZW5kZXIgaGFzIHJlcXVlc3RlZCBjb25zZW50LCBidXQg aGFzIG5vdCBnb3QgaXQgKGkuZS4gdGhlcmUgd2FzIG5vIHJlc3BvbnNlIHRvIHRoZSBjb25zZW50 IGZyZXNobmVzcyByZXF1ZXN0KS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Thu Jun 18 18:07:40 2015 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 DDF621B2E56 for ; Thu, 18 Jun 2015 18:07:38 -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 3-FswUQpzb9A for ; Thu, 18 Jun 2015 18:07:36 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC111B2E42 for ; Thu, 18 Jun 2015 18:07:36 -0700 (PDT) Received: by yhpn97 with SMTP id n97so68508993yhp.0 for ; Thu, 18 Jun 2015 18:07:35 -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=HBqcPhQ8hOXQwPFAUEvNHIq2HAIwJr4ABJsxhphBw5g=; b=pE+yK71+7Kqj5O0+YTF8gmYgtXCbwMxKuZWoKWBBYTWhmuv6mw+FpH6drKrP0gmLVU 7I4lXqA22EN/JlWuM9h5V8QDQMCOHikIY9xnwMiAF8C0i09gN+oVZEqGc+4V/q3cqzfw dRHny5/AqZOQ1uVPFrZUr4uC6L0ONUbHDlX3PcCTV65hAAs0vEUctA6lXQcdSWngL2wH Qe7HwWjHdTyutYxdLj8itelqwPwl6NTjnkvoE8DZMpy3IKJDjDeSwpbqY88CUNmxuUaD Rdi+Xm5EQ7jZY2AwIS3vr/nTxst2Y1IxK3B3siWVGRwvRbt99vy/vEpVV+zyJ1j8n7Io 1fcg== MIME-Version: 1.0 X-Received: by 10.129.43.136 with SMTP id r130mr17430823ywr.106.1434676055583; Thu, 18 Jun 2015 18:07:35 -0700 (PDT) Received: by 10.37.80.4 with HTTP; Thu, 18 Jun 2015 18:07:35 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 06:37:35 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11451a02a931b90518d48c26 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 01:07:39 -0000 --001a11451a02a931b90518d48c26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> Then, if the sender later wants to start sending media on the > >>> candidate pair again, it simply start sending consent requests again. > >> > >> From a security perspective, this would be OK. Functionally however, > >> do you really expect that to work? NATs and relays tend to garbage > >> collect pretty aggressively. > > > > It might not work if no keepalives are sent. But Christer's point is > that consent is not required since no media is being sent. > > Correct. > > > >>> However, the way I read the draft now is that it would require an ICE > >>> restart, and I don=E2=80=99t think we want that? > >> > >> Why the question? You are the one who has to decide if you want that. > > > > I think Christer's point is that this should not be considered a loss o= f > consent. > > Correct. > > Loss of consent is defined as not receiving a response to a sent consent > request - but in this case there is not consent request sent to begin wit= h > :) > > > The draft already says that consent is not needed on a pair if no media > is being sent. So one might > > interpret the existing draft as not imposing an ICE restart requirement > in that case (how can consent expire if consent is not required??) > > Correct. > > I think all that is needed is a clarification statement saying that stop > sending to consent requests shall not be considered loss of consent, and > that a sender can later request consent on the same candidate pair again = - > without having to do an ICE restart. > =E2=80=8BExisting test: An endpoint that is not sending any application data does not need to maintain consent. However, not sending any traffic could cause NAT or firewall mappings to expire. Furthermore, having one peer unable to send is detrimental to many protocols. Absent better information about the network, if an endpoint needs to ensure its NAT or firewall mappings do not expire, it can be done using keepalive or other techniques (see Section 10 of [RFC5245] and see [RFC6263]). New test: An endpoint that is not sending any application data after obtaining consent does not need to maintain consent. As soon as the endpoint starts sending application again, consent is maintained following the procedure described in this document. However, not sending any traffic could cause NAT or firewall mappings to expire. Furthermore, having one peer unable to send is detrimental to many protocols. Absent better information about the network, if an endpoint needs to ensure its NAT or firewall mappings do not expire, it can be done using keepalive or other techniques (see Section 10 of [RFC5245] and see [RFC6263]). Does it work? thanks, Muthu > > ICE restart is only required when a sender has requested consent, but has > not got it (i.e. there was no response to the consent freshness request). > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11451a02a931b90518d48c26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg <christer.holmberg@ericsson.com= > wrote:<= br>
Hi,

>>> Then, if the sender later wants to start sending media on the<= br> >>> candidate pair again, it simply start sending consent requests= again.
>>
>> From a security perspective, this would be OK.=C2=A0 Functionally = however,
>> do you really expect that to work?=C2=A0 NATs and relays tend to g= arbage
>> collect pretty aggressively.
>
> It might not work if no keepalives are sent. But Christer's point = is that consent is not required since no media is being sent.

Correct.


>>> However, the way I read the draft now is that it would require= an ICE
>>> restart, and I don=E2=80=99t think we want that?
>>
>> Why the question?=C2=A0 You are the one who has to decide if you w= ant that.
>
> I think Christer's point is that this should not be considered a l= oss of consent.

Correct.

Loss of consent is defined as not receiving a response to a sent consent re= quest - but in this case there is not consent request sent to begin with :)=

> The draft already says that consent is not needed on a pair if no medi= a is being sent. So one might
> interpret the existing draft as not imposing an ICE restart requiremen= t in that case (how can consent expire if consent is not required??)

Correct.

I think all that is needed is a clarification statement saying that stop se= nding to consent requests shall not be considered loss of consent, and that= a sender can later request consent on the same candidate pair again - with= out having to do an ICE restart.


=E2=80=8BExisting test:=C2=A0
=C2=A0 =C2=A0= An endpoint that is not sending any application data does not need to
=C2=A0 =C2=A0maintain consent.=C2=A0 However, not sending any tr= affic could cause NAT
=C2=A0 =C2=A0or firewall mappings to = expire.=C2=A0 Furthermore, having one peer unable
=C2=A0 = =C2=A0to send is detrimental to many protocols.=C2=A0 Absent better informa= tion
=C2=A0 =C2=A0about the network, if an endpoint needs t= o ensure its NAT or firewall
=C2=A0 =C2=A0mappings do not e= xpire, it can be done using keepalive or other
=C2=A0 =C2= =A0techniques (see Section 10 of [RFC5245] and see [RFC6263]).
=

New test:
=C2=A0 =C2=A0An endpoint= that is not sending any application data after obtaining=C2=A0
=C2=A0 =C2=A0consent does not need to maintain consent. As soon as the= endpoint
=C2=A0 =C2=A0starts sending application again, co= nsent is maintained following the=C2=A0
=C2=A0 =C2=A0proced= ure described in this document.

=C2=A0= =C2=A0However, not sending any traffic could cause NAT or firewall mapping= s=C2=A0
=C2=A0 =C2=A0to expire. Furthermore, having one pee= r unable to send is detrimental=C2=A0
=C2=A0 =C2=A0to many = protocols.=C2=A0 Absent better information about the network, if an=C2=A0
=C2=A0 =C2=A0endpoint needs to ensure its NAT or firewall ma= ppings do not expire,=C2=A0
= =C2=A0 =C2=A0it can be done usi= ng keepalive or other techniques (see Section 10 of=C2=A0
= =C2=A0 =C2=A0[RFC5245] and see [RFC6263]).
<= br>
Does it work?

thanks,
Muthu
= =C2=A0

ICE restart is only required when a sender has requested consent, but has n= ot got it (i.e. there was no response to the consent freshness request).
Regards,

Christer
_________________________________________= ______
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a11451a02a931b90518d48c26-- From nobody Thu Jun 18 18:08:56 2015 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 45D181B2E42 for ; Thu, 18 Jun 2015 18:08:54 -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 0yXH9bbtSgeX for ; Thu, 18 Jun 2015 18:08:52 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21051B2E49 for ; Thu, 18 Jun 2015 18:08:51 -0700 (PDT) Received: by yhan67 with SMTP id n67so68456588yha.3 for ; Thu, 18 Jun 2015 18:08: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=lvB7GWT28Wivgs9V6/wVUUhJauSduhFsBs2Pz6BhY88=; b=Ma5y0EUWWWisumMyjY3k9AeUg/ANTRSIJz4MQJ4DxIHlx/3xWI/BHV23Peg6QJ08vx vHSpw1t6lodj3mfgS57KcJXdKa+veEPSTyGCOI+1rCRBfuGkJLbQm6vzBHUgqcwZiruF K/+BV4mSNwWJmTu1YQ0h8EWO2pTK4kke7EdexBxTb3Sc73a2gIHL2+YVghcb4T1bjYQ8 TminKggIcWzCaCKWmelwkz4J6Y8CrgdP7Lt27Cdmjpb63xJLtddQ19j3S/9sTnaQiAnF pPDgVCqoJyRAUYxduQGmbhBq4i56XkOBBoYHuj6TCfVVPYnYmv0pqEh8CtYYCQrEoVpM M5Ww== MIME-Version: 1.0 X-Received: by 10.170.128.16 with SMTP id u16mr11993895ykb.49.1434676131196; Thu, 18 Jun 2015 18:08:51 -0700 (PDT) Received: by 10.37.80.4 with HTTP; Thu, 18 Jun 2015 18:08:51 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 06:38:51 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113953b62af4130518d49148 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 01:08:54 -0000 --001a113953b62af4130518d49148 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable s/test/text.. On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal < muthu.arul@gmail.com> wrote: > On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >>> Then, if the sender later wants to start sending media on the >> >>> candidate pair again, it simply start sending consent requests again= . >> >> >> >> From a security perspective, this would be OK. Functionally however, >> >> do you really expect that to work? NATs and relays tend to garbage >> >> collect pretty aggressively. >> > >> > It might not work if no keepalives are sent. But Christer's point is >> that consent is not required since no media is being sent. >> >> Correct. >> >> >> >>> However, the way I read the draft now is that it would require an IC= E >> >>> restart, and I don=E2=80=99t think we want that? >> >> >> >> Why the question? You are the one who has to decide if you want that= . >> > >> > I think Christer's point is that this should not be considered a loss >> of consent. >> >> Correct. >> >> Loss of consent is defined as not receiving a response to a sent consent >> request - but in this case there is not consent request sent to begin wi= th >> :) >> >> > The draft already says that consent is not needed on a pair if no medi= a >> is being sent. So one might >> > interpret the existing draft as not imposing an ICE restart requiremen= t >> in that case (how can consent expire if consent is not required??) >> >> Correct. >> >> I think all that is needed is a clarification statement saying that stop >> sending to consent requests shall not be considered loss of consent, and >> that a sender can later request consent on the same candidate pair again= - >> without having to do an ICE restart. >> > > > =E2=80=8BExisting test: > An endpoint that is not sending any application data does not need to > maintain consent. However, not sending any traffic could cause NAT > or firewall mappings to expire. Furthermore, having one peer unable > to send is detrimental to many protocols. Absent better information > about the network, if an endpoint needs to ensure its NAT or firewall > mappings do not expire, it can be done using keepalive or other > techniques (see Section 10 of [RFC5245] and see [RFC6263]). > > New test: > An endpoint that is not sending any application data after obtaining > consent does not need to maintain consent. As soon as the endpoint > starts sending application again, consent is maintained following the > procedure described in this document. > > However, not sending any traffic could cause NAT or firewall mappings > to expire. Furthermore, having one peer unable to send is detrimental > to many protocols. Absent better information about the network, if an > endpoint needs to ensure its NAT or firewall mappings do not expire, > it can be done using keepalive or other techniques (see Section 10 of > [RFC5245] and see [RFC6263]). > > Does it work? > > thanks, > Muthu > > >> >> ICE restart is only required when a sender has requested consent, but ha= s >> not got it (i.e. there was no response to the consent freshness request)= . >> >> Regards, >> >> Christer >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --001a113953b62af4130518d49148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
s/test/text..

On Fri, Jun 19, 2015 at 6:37 AM, Muth= u Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmbe= rg <christer.ho= lmberg@ericsson.com> wrote:
Hi,

>>> Then, if the sender later wants to start sending media on the<= br> >>> candidate pair again, it simply start sending consent requests= again.
>>
>> From a security perspective, this would be OK.=C2=A0 Functionally = however,
>> do you really expect that to work?=C2=A0 NATs and relays tend to g= arbage
>> collect pretty aggressively.
>
> It might not work if no keepalives are sent. But Christer's point = is that consent is not required since no media is being sent.

Correct.


>>> However, the way I read the draft now is that it would require= an ICE
>>> restart, and I don=E2=80=99t think we want that?
>>
>> Why the question?=C2=A0 You are the one who has to decide if you w= ant that.
>
> I think Christer's point is that this should not be considered a l= oss of consent.

Correct.

Loss of consent is defined as not receiving a response to a sent consent re= quest - but in this case there is not consent request sent to begin with :)=

> The draft already says that consent is not needed on a pair if no medi= a is being sent. So one might
> interpret the existing draft as not imposing an ICE restart requiremen= t in that case (how can consent expire if consent is not required??)

Correct.

I think all that is needed is a clarification statement saying that stop se= nding to consent requests shall not be considered loss of consent, and that= a sender can later request consent on the same candidate pair again - with= out having to do an ICE restart.


=E2=80=8B=C2=A0 =C2=A0An endpoint that is not sending any application data = does not need to
=C2=A0 =C2=A0maintain consent.=C2=A0 However, not sending any traffic co= uld cause NAT
= =C2=A0 =C2=A0or firewall mappings to expire.=C2=A0 Furthermore, having one = peer unable
= =C2=A0 =C2=A0to send is detrimental to many protocols.=C2=A0 Absent better = information
= =C2=A0 =C2=A0about the network, if an endpoint needs to ensure its NAT or f= irewall
=C2=A0= =C2=A0mappings do not expire, it can be done using keepalive or other
=C2=A0 =C2=A0techn= iques (see Section 10 of [RFC5245] and see [RFC6263]).

New test:
=C2=A0 =C2=A0An endpoint that is not sending = any application data after obtaining=C2=A0
=C2=A0 =C2=A0consent does not need to maintain= consent. As soon as the endpoint
=C2=A0 =C2=A0starts sending application again, consent = is maintained following the=C2=A0
=C2=A0 =C2=A0procedure described in this document.

<= div>=C2=A0 =C2=A0However, not s= ending any traffic could cause NAT or firewall mappings=C2=A0
<= div>=C2=A0 =C2=A0to expire. Fur= thermore, having one peer unable to send is detrimental=C2=A0
<= div>=C2=A0 =C2=A0to many protoc= ols.=C2=A0 Absent better information about the network, if an=C2=A0<= /div>
=C2=A0 =C2=A0endpoint= needs to ensure its NAT or firewall mappings do not expire,=C2=A0
=C2=A0 =C2=A0it can be= done using keepalive or other techniques (see Section 10 of=C2=A0
=C2=A0 =C2=A0[RFC5245]= and see [RFC6263]).

Does it work?

thanks,
Muthu
=C2=A0

ICE restart is only required when a sender has requested consent, but has n= ot got it (i.e. there was no response to the consent freshness request).
Regards,

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


--001a113953b62af4130518d49148-- From nobody Thu Jun 18 20:14:12 2015 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 81C3E1ABC74 for ; Thu, 18 Jun 2015 20:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 ev3KQbQxzDtr for ; Thu, 18 Jun 2015 20:14:09 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322731ABD3E for ; Thu, 18 Jun 2015 20:14:09 -0700 (PDT) Received: by yhpn97 with SMTP id n97so70069632yhp.0 for ; Thu, 18 Jun 2015 20:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c4nNcgOfa7H/JUn86OBD36N8/FwLq9Ce9eH+AAzZHHY=; b=zZ2BHRQfxdakdYQYW9dfWRB4492kZXOEMNtUtacCwKbfWEpkGOoXTyTEFPNl1hpsUZ XjBF9Of9VT6FUSQs5v4laWNv6JQ1SFTZr2VrfaKJLHfYiYEFlVJOjOMqUo/i9k0Qa5Af dVoV3oUCXsTEXk6ue7PDnudYksrG/SuIAoQfdfqZcsUe/se6lwMiXQB1I2SJT+6rJs0F r/nFVODV5jpM4kUPv0woeDebofl0hSQypRi6MlzYuCK2kIhAKuPsNzYADrQJTaZH3bVD qe7GGs+nN5yP3AA9XCnYQnyx5793QCdBYy8WqsNimK9J3brqqghfySiBrZrIxMBi6u31 slpQ== X-Received: by 10.13.221.141 with SMTP id g135mr17461829ywe.11.1434683648568; Thu, 18 Jun 2015 20:14:08 -0700 (PDT) Received: from [192.168.1.130] ([71.23.40.3]) by mx.google.com with ESMTPSA id x185sm7770855ywf.44.2015.06.18.20.14.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Jun 2015 20:14:07 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6423E0DC-17B0-4FCB-8F17-0721585CB56E Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12F69) In-Reply-To: Date: Thu, 18 Jun 2015 23:14:05 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> To: Muthu Arul Mozhi Perumal Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 03:14:11 -0000 --Apple-Mail-6423E0DC-17B0-4FCB-8F17-0721585CB56E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable s/sending application/sending application data/ Otherwise, WFM. > On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal wrote: >=20 > s/test/text.. >=20 >> On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal wrote: >>> On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg wrote: >>=20 >>> Hi, >>>=20 >>> >>> Then, if the sender later wants to start sending media on the >>> >>> candidate pair again, it simply start sending consent requests again= . >>> >> >>> >> =46rom a security perspective, this would be OK. Functionally howeve= r, >>> >> do you really expect that to work? NATs and relays tend to garbage >>> >> collect pretty aggressively. >>> > >>> > It might not work if no keepalives are sent. But Christer's point is t= hat consent is not required since no media is being sent. >>>=20 >>> Correct. >>>=20 >>>=20 >>> >>> However, the way I read the draft now is that it would require an IC= E >>> >>> restart, and I don=E2=80=99t think we want that? >>> >> >>> >> Why the question? You are the one who has to decide if you want that= . >>> > >>> > I think Christer's point is that this should not be considered a loss o= f consent. >>>=20 >>> Correct. >>>=20 >>> Loss of consent is defined as not receiving a response to a sent consent= request - but in this case there is not consent request sent to begin with := ) >>>=20 >>> > The draft already says that consent is not needed on a pair if no medi= a is being sent. So one might >>> > interpret the existing draft as not imposing an ICE restart requiremen= t in that case (how can consent expire if consent is not required??) >>>=20 >>> Correct. >>>=20 >>> I think all that is needed is a clarification statement saying that stop= sending to consent requests shall not be considered loss of consent, and th= at a sender can later request consent on the same candidate pair again - wit= hout having to do an ICE restart. >>=20 >>=20 >> =E2=80=8BExisting test:=20 >> An endpoint that is not sending any application data does not need to >> maintain consent. However, not sending any traffic could cause NAT >> or firewall mappings to expire. Furthermore, having one peer unable >> to send is detrimental to many protocols. Absent better information >> about the network, if an endpoint needs to ensure its NAT or firewall >> mappings do not expire, it can be done using keepalive or other >> techniques (see Section 10 of [RFC5245] and see [RFC6263]). >>=20 >> New test: >> An endpoint that is not sending any application data after obtaining=20= >> consent does not need to maintain consent. As soon as the endpoint >> starts sending application again, consent is maintained following the=20= >> procedure described in this document. >>=20 >> However, not sending any traffic could cause NAT or firewall mappings=20= >> to expire. Furthermore, having one peer unable to send is detrimental=20= >> to many protocols. Absent better information about the network, if an= =20 >> endpoint needs to ensure its NAT or firewall mappings do not expire,=20= >> it can be done using keepalive or other techniques (see Section 10 of=20= >> [RFC5245] and see [RFC6263]). >>=20 >> Does it work? >>=20 >> thanks, >> Muthu >> =20 >>>=20 >>> ICE restart is only required when a sender has requested consent, but ha= s not got it (i.e. there was no response to the consent freshness request). >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail-6423E0DC-17B0-4FCB-8F17-0721585CB56E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
s/sending application/sending applicat= ion data/

Otherwise, WFM.


On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

s/test/text..<= /div>

On Fri, Jun 1= 9, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>= wrote:
= On Fri, Jun 19, 2015 at 2:58 AM= , Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=
Hi,

>>> Then, if the sender later wants to start sending media on the >>> candidate pair again, it simply start sending consent requests a= gain.
>>
>> =46rom a security perspective, this would be OK.  Functionally= however,
>> do you really expect that to work?  NATs and relays tend to ga= rbage
>> collect pretty aggressively.
>
> It might not work if no keepalives are sent. But Christer's point is th= at consent is not required since no media is being sent.

Correct.


>>> However, the way I read the draft now is that it would require a= n ICE
>>> restart, and I don=E2=80=99t think we want that?
>>
>> Why the question?  You are the one who has to decide if you wa= nt that.
>
> I think Christer's point is that this should not be considered a loss o= f consent.

Correct.

Loss of consent is defined as not receiving a response to a sent consent req= uest - but in this case there is not consent request sent to begin with :)
> The draft already says that consent is not needed on a pair if no media= is being sent. So one might
> interpret the existing draft as not imposing an ICE restart requirement= in that case (how can consent expire if consent is not required??)

Correct.

I think all that is needed is a clarification statement saying that stop sen= ding to consent requests shall not be considered loss of consent, and that a= sender can later request consent on the same candidate pair again - without= having to do an ICE restart.


=
=E2=80=8BExis= ting test: 
 =  maintain consent.  However, not sending any traffic could cause N= AT
   = ;or firewall mappings to expire.  Furthermore, having one peer unable
   to s= end is detrimental to many protocols.  Absent better information=
   about th= e network, if an endpoint needs to ensure its NAT or firewall
   mappings do not e= xpire, it can be done using keepalive or other
   techniques (see Section 10 of [R= FC5245] and see [RFC6263]).

New test:
&n= bsp;  An endpoint that is not sending any application data after obtain= ing 
 = ;  consent does not need to maintain consent. As soon as the endpoint
   sta= rts sending application again, consent is maintained following the 
   proce= dure described in this document.

   However, not sending any traffic could cause NAT or fir= ewall mappings 
   to expire. Furthermore, having one peer unable to send is= detrimental 
   to many protocols.  Absent better information about th= e network, if an 
   endpoint needs to ensure its NAT or firewall mappings d= o not expire, 
   it can be done using keepalive or other techniques (see Se= ction 10 of 
   [RFC5245] and see [RFC6263]).

Does it work?
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small">
tha= nks,
Muthu
 

ICE restart is only required when a sender has requested consent, but has no= t got it (i.e. there was no response to the consent freshness request).

Regards,

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


= --Apple-Mail-6423E0DC-17B0-4FCB-8F17-0721585CB56E-- From nobody Thu Jun 18 20:19:02 2015 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 B36181AC3A6 for ; Thu, 18 Jun 2015 20:19:00 -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 uOfsFvLTt2XT for ; Thu, 18 Jun 2015 20:18:58 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6B21ABD8F for ; Thu, 18 Jun 2015 20:18:57 -0700 (PDT) Received: by wiga1 with SMTP id a1so6396288wig.0 for ; Thu, 18 Jun 2015 20:18: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=IuKn91sMzdy527ygYlJSxgjdGFZkH5B/kDWZAn7mY+Q=; b=WSq3/w3yPVsqiYG/Cc2EETKdivj7naHBnUXmyBRda3wTEysSYHMuMROyfDt02Ztwcj bJKx46Y0jFIjeBBoroHBo3D8Ac0VDvGMt4f5yqyFvc1DeQIVjgQKkg/wi+KZuBbosiGk jLnpC0opu0nBSppaQnhMib4XdOk54zhOCsLDzoZ2hpthUMRyjYYeXpjhCqP2fYNs43Jc JeQh3Jj3uO7le5MqYZ52uBAfkSNRkJ7M5rU4f1bQlOvcpqj+3bBfiige1atJZBtkO9OS Zg6UfXmUGWjpMWyc1EJJlQZmmoF7eRGTq3k+uNwHnN6FMswR1h5/FBNFH8BKGPSPfTp7 W3rA== MIME-Version: 1.0 X-Received: by 10.180.76.8 with SMTP id g8mr2082259wiw.79.1434683936742; Thu, 18 Jun 2015 20:18:56 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Thu, 18 Jun 2015 20:18:56 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 08:48:56 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d043893c56a24b90518d66291 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 03:19:00 -0000 --f46d043893c56a24b90518d66291 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks. It was missed in a haste :) Muthu On Fri, Jun 19, 2015 at 8:44 AM, Bernard Aboba wrote: > s/sending application/sending application data/ > > Otherwise, WFM. > > > > On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> wrote: > > s/test/text.. > > On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> wrote: > >> On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >>> Then, if the sender later wants to start sending media on the >>> >>> candidate pair again, it simply start sending consent requests agai= n. >>> >> >>> >> From a security perspective, this would be OK. Functionally however= , >>> >> do you really expect that to work? NATs and relays tend to garbage >>> >> collect pretty aggressively. >>> > >>> > It might not work if no keepalives are sent. But Christer's point is >>> that consent is not required since no media is being sent. >>> >>> Correct. >>> >>> >>> >>> However, the way I read the draft now is that it would require an I= CE >>> >>> restart, and I don=E2=80=99t think we want that? >>> >> >>> >> Why the question? You are the one who has to decide if you want tha= t. >>> > >>> > I think Christer's point is that this should not be considered a loss >>> of consent. >>> >>> Correct. >>> >>> Loss of consent is defined as not receiving a response to a sent consen= t >>> request - but in this case there is not consent request sent to begin w= ith >>> :) >>> >>> > The draft already says that consent is not needed on a pair if no >>> media is being sent. So one might >>> > interpret the existing draft as not imposing an ICE restart >>> requirement in that case (how can consent expire if consent is not >>> required??) >>> >>> Correct. >>> >>> I think all that is needed is a clarification statement saying that sto= p >>> sending to consent requests shall not be considered loss of consent, an= d >>> that a sender can later request consent on the same candidate pair agai= n - >>> without having to do an ICE restart. >>> >> >> >> =E2=80=8BExisting test: >> An endpoint that is not sending any application data does not need to >> maintain consent. However, not sending any traffic could cause NAT >> or firewall mappings to expire. Furthermore, having one peer unable >> to send is detrimental to many protocols. Absent better information >> about the network, if an endpoint needs to ensure its NAT or firewall >> mappings do not expire, it can be done using keepalive or other >> techniques (see Section 10 of [RFC5245] and see [RFC6263]). >> >> New test: >> An endpoint that is not sending any application data after obtaining >> consent does not need to maintain consent. As soon as the endpoint >> starts sending application again, consent is maintained following the >> procedure described in this document. >> >> However, not sending any traffic could cause NAT or firewall mappings >> to expire. Furthermore, having one peer unable to send is detrimental >> to many protocols. Absent better information about the network, if a= n >> endpoint needs to ensure its NAT or firewall mappings do not expire, >> it can be done using keepalive or other techniques (see Section 10 of >> [RFC5245] and see [RFC6263]). >> >> Does it work? >> >> thanks, >> Muthu >> >> >>> >>> ICE restart is only required when a sender has requested consent, but >>> has not got it (i.e. there was no response to the consent freshness >>> request). >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> > --f46d043893c56a24b90518d66291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. It was missed in a haste :)

Muthu

On Fri, Jun 19, 2015 at 8:44 AM= , Bernard Aboba <bernard.aboba@gmail.com> wrote:
s/sending application/s= ending application data/

Otherwise, WFM.


On Jun 18, 2015, at 9:08 PM, Muthu = Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

s/test/text..

On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi = Perumal <muthu.arul@gmail.com> wrote:
On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg <christer.holmberg@ericsson.com&= gt; wrote:
Hi,

>>> Then, if the sender later wants to start sending media on the<= br> >>> candidate pair again, it simply start sending consent requests= again.
>>
>> From a security perspective, this would be OK.=C2=A0 Functionally = however,
>> do you really expect that to work?=C2=A0 NATs and relays tend to g= arbage
>> collect pretty aggressively.
>
> It might not work if no keepalives are sent. But Christer's point = is that consent is not required since no media is being sent.

Correct.


>>> However, the way I read the draft now is that it would require= an ICE
>>> restart, and I don=E2=80=99t think we want that?
>>
>> Why the question?=C2=A0 You are the one who has to decide if you w= ant that.
>
> I think Christer's point is that this should not be considered a l= oss of consent.

Correct.

Loss of consent is defined as not receiving a response to a sent consent re= quest - but in this case there is not consent request sent to begin with :)=

> The draft already says that consent is not needed on a pair if no medi= a is being sent. So one might
> interpret the existing draft as not imposing an ICE restart requiremen= t in that case (how can consent expire if consent is not required??)

Correct.

I think all that is needed is a clarification statement saying that stop se= nding to consent requests shall not be considered loss of consent, and that= a sender can later request consent on the same candidate pair again - with= out having to do an ICE restart.


=E2=80=8B=C2=A0 =C2=A0An endpoint that is not sending any application data = does not need to
=C2=A0 =C2=A0maintain consent.=C2=A0 However, not sending any traffic co= uld cause NAT
= =C2=A0 =C2=A0or firewall mappings to expire.=C2=A0 Furthermore, having one = peer unable
= =C2=A0 =C2=A0to send is detrimental to many protocols.=C2=A0 Absent better = information
= =C2=A0 =C2=A0about the network, if an endpoint needs to ensure its NAT or f= irewall
=C2=A0= =C2=A0mappings do not expire, it can be done using keepalive or other
=C2=A0 =C2=A0techn= iques (see Section 10 of [RFC5245] and see [RFC6263]).

New test:
=C2=A0 =C2=A0An endpoint that is not sending = any application data after obtaining=C2=A0
=C2=A0 =C2=A0consent does not need to maintain= consent. As soon as the endpoint
=C2=A0 =C2=A0starts sending application again, consent = is maintained following the=C2=A0
=C2=A0 =C2=A0procedure described in this document.

<= div>=C2=A0 =C2=A0However, not s= ending any traffic could cause NAT or firewall mappings=C2=A0
<= div>=C2=A0 =C2=A0to expire. Fur= thermore, having one peer unable to send is detrimental=C2=A0
<= div>=C2=A0 =C2=A0to many protoc= ols.=C2=A0 Absent better information about the network, if an=C2=A0<= /div>
=C2=A0 =C2=A0endpoint= needs to ensure its NAT or firewall mappings do not expire,=C2=A0
=C2=A0 =C2=A0it can be= done using keepalive or other techniques (see Section 10 of=C2=A0
=C2=A0 =C2=A0[RFC5245]= and see [RFC6263]).

Does it work?

thanks,
Muthu
=C2=A0

ICE restart is only required when a sender has requested consent, but has n= ot got it (i.e. there was no response to the consent freshness request).
Regards,

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



--f46d043893c56a24b90518d66291-- From nobody Thu Jun 18 22:35:13 2015 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 BA80D1A1B44 for ; Thu, 18 Jun 2015 22:35:11 -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 O-aku0RO5hZE for ; Thu, 18 Jun 2015 22:35:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F301A1B3E for ; Thu, 18 Jun 2015 22:35:07 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-12-5583aa0a8d95 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8C.89.04015.A0AA3855; Fri, 19 Jun 2015 07:35:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 07:35:05 +0200 From: Christer Holmberg To: Muthu Arul Mozhi Perumal , Bernard Aboba Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRQ= Date: Fri, 19 Jun 2015 05:35:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F2E37ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3VpdrVXOowf4tIhYb9v1ntrh25h+j xZ/NfhZr/7WzO7B47Jx1l91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZNye/YSxYMYux4kjHXaYG xhnTGLsYOTkkBEwkDszqg7LFJC7cW8/WxcjFISRwlFFi14ouVpCEkMBiRokFh1K7GDk42AQs JLr/aYOERQTiJGbcOMoEYjMLhEg8PPuOGcQWFjCVWHN5DjNEjZlE69mZrBB2ksS/Z7vAdrEI qEqcXPOaBcTmFfCV6PvVxwaxaiKLRMP5KBCbUyBQ4ua2XWBxRqDbvp9aA7VLXKLpy0pWiJsF JJbsOc8MYYtKvHz8jxWiJl/i0McGVoj5ghInZz5hmcAoMgtJ+ywkZbOQlM0C+pJZQFNi/S59 iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjLSDW34b 7GB8+dzxEKMAB6MSD6+CWlOoEGtiWXFl7iFGaQ4WJXHeGZvzQoUE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwrq+dIPrU5dBa+dVa/6/5b5H8lL9G8OOFh7OVjurrSrhO2PGi27Jc4Valromc 2b6fRxVW5y+uWt/TYnGz8MLM50ump7tM2Ni64BnPSrs2h1/XN0yJOrf48O7tbmy5Fce/dnay SuocE0zqyev4/i/uiNu5tb01zNFefqXFQT/0gp/0RUhsnPBtoxJLcUaioRZzUXEiALubp+iV AgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 05:35:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F2E37ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSB0ZXh0IG90aGVyd2lzZSBsb29rcyBnb29kLCBidXQgSSBzdWdnZXN0IGFkZGlu ZyB0aGUgZm9sbG93aW5nIGFmdGVyIHRoZSAiQXMgc29vbiBhcy4uLiIgc3RhdGVtZW50OiAiSW4g dGhpcyBjYXNlIHRoZSBlbmRwb2ludCBkb2VzIG5vdCBuZWVkIHRvIHBlcmZvcm0gSUNFIHJlc3Rh cnQuIg0KDQpUaGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBX aW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTXV0 aHUgQXJ1bCBNb3poaSBQZXJ1bWFsPG1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbT4NClNlbnQ6 IOKAjjE5L+KAjjA2L+KAjjIwMTUgMDY6MTgNClRvOiBCZXJuYXJkIEFib2JhPG1haWx0bzpiZXJu YXJkLmFib2JhQGdtYWlsLmNvbT4NCkNjOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgTWFydGluIFRob21zb248bWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIENvbW1lbnQgb24gY29uc2VudC1mcmVzaG5lc3MtMTQN Cg0KVGhhbmtzLiBJdCB3YXMgbWlzc2VkIGluIGEgaGFzdGUgOikNCg0KTXV0aHUNCg0KT24gRnJp LCBKdW4gMTksIDIwMTUgYXQgODo0NCBBTSwgQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBn bWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj4gd3JvdGU6DQpzL3NlbmRp bmcgYXBwbGljYXRpb24vc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhLw0KDQpPdGhlcndpc2UsIFdG TS4NCg0KDQoNCk9uIEp1biAxOCwgMjAxNSwgYXQgOTowOCBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQ ZXJ1bWFsIDxtdXRodS5hcnVsQGdtYWlsLmNvbTxtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20+ PiB3cm90ZToNCg0Kcy90ZXN0L3RleHQuLg0KDQpPbiBGcmksIEp1biAxOSwgMjAxNSBhdCA2OjM3 IEFNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgPG11dGh1LmFydWxAZ21haWwuY29tPG1haWx0 bzptdXRodS5hcnVsQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gRnJpLCBKdW4gMTksIDIwMTUgYXQg Mjo1OCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0K Pj4+IFRoZW4sIGlmIHRoZSBzZW5kZXIgbGF0ZXIgd2FudHMgdG8gc3RhcnQgc2VuZGluZyBtZWRp YSBvbiB0aGUNCj4+PiBjYW5kaWRhdGUgcGFpciBhZ2FpbiwgaXQgc2ltcGx5IHN0YXJ0IHNlbmRp bmcgY29uc2VudCByZXF1ZXN0cyBhZ2Fpbi4NCj4+DQo+PiBGcm9tIGEgc2VjdXJpdHkgcGVyc3Bl Y3RpdmUsIHRoaXMgd291bGQgYmUgT0suICBGdW5jdGlvbmFsbHkgaG93ZXZlciwNCj4+IGRvIHlv dSByZWFsbHkgZXhwZWN0IHRoYXQgdG8gd29yaz8gIE5BVHMgYW5kIHJlbGF5cyB0ZW5kIHRvIGdh cmJhZ2UNCj4+IGNvbGxlY3QgcHJldHR5IGFnZ3Jlc3NpdmVseS4NCj4NCj4gSXQgbWlnaHQgbm90 IHdvcmsgaWYgbm8ga2VlcGFsaXZlcyBhcmUgc2VudC4gQnV0IENocmlzdGVyJ3MgcG9pbnQgaXMg dGhhdCBjb25zZW50IGlzIG5vdCByZXF1aXJlZCBzaW5jZSBubyBtZWRpYSBpcyBiZWluZyBzZW50 Lg0KDQpDb3JyZWN0Lg0KDQoNCj4+PiBIb3dldmVyLCB0aGUgd2F5IEkgcmVhZCB0aGUgZHJhZnQg bm93IGlzIHRoYXQgaXQgd291bGQgcmVxdWlyZSBhbiBJQ0UNCj4+PiByZXN0YXJ0LCBhbmQgSSBk b27igJl0IHRoaW5rIHdlIHdhbnQgdGhhdD8NCj4+DQo+PiBXaHkgdGhlIHF1ZXN0aW9uPyAgWW91 IGFyZSB0aGUgb25lIHdobyBoYXMgdG8gZGVjaWRlIGlmIHlvdSB3YW50IHRoYXQuDQo+DQo+IEkg dGhpbmsgQ2hyaXN0ZXIncyBwb2ludCBpcyB0aGF0IHRoaXMgc2hvdWxkIG5vdCBiZSBjb25zaWRl cmVkIGEgbG9zcyBvZiBjb25zZW50Lg0KDQpDb3JyZWN0Lg0KDQpMb3NzIG9mIGNvbnNlbnQgaXMg ZGVmaW5lZCBhcyBub3QgcmVjZWl2aW5nIGEgcmVzcG9uc2UgdG8gYSBzZW50IGNvbnNlbnQgcmVx dWVzdCAtIGJ1dCBpbiB0aGlzIGNhc2UgdGhlcmUgaXMgbm90IGNvbnNlbnQgcmVxdWVzdCBzZW50 IHRvIGJlZ2luIHdpdGggOikNCg0KPiBUaGUgZHJhZnQgYWxyZWFkeSBzYXlzIHRoYXQgY29uc2Vu dCBpcyBub3QgbmVlZGVkIG9uIGEgcGFpciBpZiBubyBtZWRpYSBpcyBiZWluZyBzZW50LiBTbyBv bmUgbWlnaHQNCj4gaW50ZXJwcmV0IHRoZSBleGlzdGluZyBkcmFmdCBhcyBub3QgaW1wb3Npbmcg YW4gSUNFIHJlc3RhcnQgcmVxdWlyZW1lbnQgaW4gdGhhdCBjYXNlIChob3cgY2FuIGNvbnNlbnQg ZXhwaXJlIGlmIGNvbnNlbnQgaXMgbm90IHJlcXVpcmVkPz8pDQoNCkNvcnJlY3QuDQoNCkkgdGhp bmsgYWxsIHRoYXQgaXMgbmVlZGVkIGlzIGEgY2xhcmlmaWNhdGlvbiBzdGF0ZW1lbnQgc2F5aW5n IHRoYXQgc3RvcCBzZW5kaW5nIHRvIGNvbnNlbnQgcmVxdWVzdHMgc2hhbGwgbm90IGJlIGNvbnNp ZGVyZWQgbG9zcyBvZiBjb25zZW50LCBhbmQgdGhhdCBhIHNlbmRlciBjYW4gbGF0ZXIgcmVxdWVz dCBjb25zZW50IG9uIHRoZSBzYW1lIGNhbmRpZGF0ZSBwYWlyIGFnYWluIC0gd2l0aG91dCBoYXZp bmcgdG8gZG8gYW4gSUNFIHJlc3RhcnQuDQoNCg0K4oCLRXhpc3RpbmcgdGVzdDoNCiAgIEFuIGVu ZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3Qg bmVlZCB0bw0KICAgbWFpbnRhaW4gY29uc2VudC4gIEhvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0 cmFmZmljIGNvdWxkIGNhdXNlIE5BVA0KICAgb3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJl LiAgRnVydGhlcm1vcmUsIGhhdmluZyBvbmUgcGVlciB1bmFibGUNCiAgIHRvIHNlbmQgaXMgZGV0 cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uDQog ICBhYm91dCB0aGUgbmV0d29yaywgaWYgYW4gZW5kcG9pbnQgbmVlZHMgdG8gZW5zdXJlIGl0cyBO QVQgb3IgZmlyZXdhbGwNCiAgIG1hcHBpbmdzIGRvIG5vdCBleHBpcmUsIGl0IGNhbiBiZSBkb25l IHVzaW5nIGtlZXBhbGl2ZSBvciBvdGhlcg0KICAgdGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAg b2YgW1JGQzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS4NCg0KTmV3IHRlc3Q6DQogICBBbiBlbmRw b2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGFmdGVyIG9idGFp bmluZw0KICAgY29uc2VudCBkb2VzIG5vdCBuZWVkIHRvIG1haW50YWluIGNvbnNlbnQuIEFzIHNv b24gYXMgdGhlIGVuZHBvaW50DQogICBzdGFydHMgc2VuZGluZyBhcHBsaWNhdGlvbiBhZ2Fpbiwg Y29uc2VudCBpcyBtYWludGFpbmVkIGZvbGxvd2luZyB0aGUNCiAgIHByb2NlZHVyZSBkZXNjcmli ZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgSG93ZXZlciwgbm90IHNlbmRpbmcgYW55IHRyYWZm aWMgY291bGQgY2F1c2UgTkFUIG9yIGZpcmV3YWxsIG1hcHBpbmdzDQogICB0byBleHBpcmUuIEZ1 cnRoZXJtb3JlLCBoYXZpbmcgb25lIHBlZXIgdW5hYmxlIHRvIHNlbmQgaXMgZGV0cmltZW50YWwN CiAgIHRvIG1hbnkgcHJvdG9jb2xzLiAgQWJzZW50IGJldHRlciBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgbmV0d29yaywgaWYgYW4NCiAgIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9y IGZpcmV3YWxsIG1hcHBpbmdzIGRvIG5vdCBleHBpcmUsDQogICBpdCBjYW4gYmUgZG9uZSB1c2lu ZyBrZWVwYWxpdmUgb3Igb3RoZXIgdGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YNCiAgIFtS RkM1MjQ1XSBhbmQgc2VlIFtSRkM2MjYzXSkuDQoNCkRvZXMgaXQgd29yaz8NCg0KdGhhbmtzLA0K TXV0aHUNCg0KDQpJQ0UgcmVzdGFydCBpcyBvbmx5IHJlcXVpcmVkIHdoZW4gYSBzZW5kZXIgaGFz IHJlcXVlc3RlZCBjb25zZW50LCBidXQgaGFzIG5vdCBnb3QgaXQgKGkuZS4gdGhlcmUgd2FzIG5v IHJlc3BvbnNlIHRvIHRoZSBjb25zZW50IGZyZXNobmVzcyByZXF1ZXN0KS4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoN Cg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D8F2E37ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPkhp LDxicj4NCjxicj4NClRoZSB0ZXh0IG90aGVyd2lzZSBsb29rcyBnb29kLCBidXQgSSBzdWdnZXN0 IGFkZGluZyB0aGUgZm9sbG93aW5nIGFmdGVyIHRoZSAmcXVvdDtBcyBzb29uIGFzLi4uJnF1b3Q7 IHN0YXRlbWVudDogJnF1b3Q7SW4gdGhpcyBjYXNlIHRoZSBlbmRwb2ludCBkb2VzIG5vdCBuZWVk IHRvIHBlcmZvcm0gSUNFIHJlc3RhcnQuJnF1b3Q7PGJyPg0KPGJyPg0KVGhhbmtzITxicj4NCjxi cj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQpTZW50IGZyb20gbXkg V2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxocj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBm b250LXdlaWdodDpib2xkIj5Gcm9tOg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBocmVmPSJtYWlsdG86bXV0aHUu YXJ1bEBnbWFpbC5jb20iPk11dGh1IEFydWwgTW96aGkgUGVydW1hbDwvYT48L3NwYW4+PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjEx cHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPuKAjjE5L+KAjjA2L+KAjjIw MTUgMDY6MTg8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlRvOg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0 Ij48YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iPkJlcm5hcmQgQWJvYmE8 L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5DYzoNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEg aHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Q2hyaXN0ZXIgSG9s bWJlcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+TWFy dGluIFRob21zb248L2E+OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj4NCnJ0Y3dl YkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9u dC1zaXplOjExcHQiPlJlOiBbcnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0 PC9zcGFuPjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KVGhhbmtzLiBJdCB3YXMgbWlzc2VkIGluIGEg aGFzdGUgOik8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCjxicj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KTXV0aHU8L2Rpdj4N CjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+ T24gRnJpLCBKdW4gMTksIDIwMTUgYXQgODo0NCBBTSwgQmVybmFyZCBBYm9iYSA8c3BhbiBkaXI9 Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6 PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7IGJvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk aXYgZGlyPSJhdXRvIj4NCjxkaXY+cy9zZW5kaW5nIGFwcGxpY2F0aW9uL3NlbmRpbmcgYXBwbGlj YXRpb24gZGF0YS88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk90aGVyd2lzZSwgV0ZN Ljxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+ PGJyPg0KT24gSnVuIDE4LCAyMDE1LCBhdCA5OjA4IFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVt YWwgJmx0OzxhIGhyZWY9Im1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm11dGh1LmFydWxAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 c21hbGwiPnMvdGVzdC90ZXh0Li48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBKdW4gMTksIDIwMTUgYXQgNjozNyBB TSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsDQo8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9 Im1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm11dGh1LmFydWxA Z21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4OyBib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj48c3Bhbj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 c21hbGwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmIj5PbiBGcmks IEp1biAxOSwgMjAxNSBhdCAyOjU4IEFNLCBDaHJpc3RlciBIb2xtYmVyZw0KPC9zcGFuPjxzcGFu IGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZiI+Jmx0OzxhIGhy ZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZiI+IHdyb3RlOjwvc3Bhbj48YnI+DQo8L2Rp dj4NCjwvc3Bhbj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj48c3Bhbj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6MXB4OyBib3JkZXItbGVm dC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBib3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGlu Zy1sZWZ0OjFleCI+DQpIaSw8YnI+DQo8c3Bhbj48YnI+DQomZ3Q7Jmd0OyZndDsgVGhlbiwgaWYg dGhlIHNlbmRlciBsYXRlciB3YW50cyB0byBzdGFydCBzZW5kaW5nIG1lZGlhIG9uIHRoZTxicj4N CiZndDsmZ3Q7Jmd0OyBjYW5kaWRhdGUgcGFpciBhZ2FpbiwgaXQgc2ltcGx5IHN0YXJ0IHNlbmRp bmcgY29uc2VudCByZXF1ZXN0cyBhZ2Fpbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZy b20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwgdGhpcyB3b3VsZCBiZSBPSy4mbmJzcDsgRnVuY3Rp b25hbGx5IGhvd2V2ZXIsPGJyPg0KJmd0OyZndDsgZG8geW91IHJlYWxseSBleHBlY3QgdGhhdCB0 byB3b3JrPyZuYnNwOyBOQVRzIGFuZCByZWxheXMgdGVuZCB0byBnYXJiYWdlPGJyPg0KJmd0OyZn dDsgY29sbGVjdCBwcmV0dHkgYWdncmVzc2l2ZWx5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IG1p Z2h0IG5vdCB3b3JrIGlmIG5vIGtlZXBhbGl2ZXMgYXJlIHNlbnQuIEJ1dCBDaHJpc3RlcidzIHBv aW50IGlzIHRoYXQgY29uc2VudCBpcyBub3QgcmVxdWlyZWQgc2luY2Ugbm8gbWVkaWEgaXMgYmVp bmcgc2VudC48YnI+DQo8YnI+DQo8L3NwYW4+Q29ycmVjdC48YnI+DQo8c3Bhbj48YnI+DQo8YnI+ DQomZ3Q7Jmd0OyZndDsgSG93ZXZlciwgdGhlIHdheSBJIHJlYWQgdGhlIGRyYWZ0IG5vdyBpcyB0 aGF0IGl0IHdvdWxkIHJlcXVpcmUgYW4gSUNFPGJyPg0KJmd0OyZndDsmZ3Q7IHJlc3RhcnQsIGFu ZCBJIGRvbuKAmXQgdGhpbmsgd2Ugd2FudCB0aGF0Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgV2h5IHRoZSBxdWVzdGlvbj8mbmJzcDsgWW91IGFyZSB0aGUgb25lIHdobyBoYXMgdG8gZGVj aWRlIGlmIHlvdSB3YW50IHRoYXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0aGluayBDaHJpc3Rl cidzIHBvaW50IGlzIHRoYXQgdGhpcyBzaG91bGQgbm90IGJlIGNvbnNpZGVyZWQgYSBsb3NzIG9m IGNvbnNlbnQuPGJyPg0KPGJyPg0KPC9zcGFuPkNvcnJlY3QuPGJyPg0KPGJyPg0KTG9zcyBvZiBj b25zZW50IGlzIGRlZmluZWQgYXMgbm90IHJlY2VpdmluZyBhIHJlc3BvbnNlIHRvIGEgc2VudCBj b25zZW50IHJlcXVlc3QgLSBidXQgaW4gdGhpcyBjYXNlIHRoZXJlIGlzIG5vdCBjb25zZW50IHJl cXVlc3Qgc2VudCB0byBiZWdpbiB3aXRoIDopPGJyPg0KPHNwYW4+PGJyPg0KJmd0OyBUaGUgZHJh ZnQgYWxyZWFkeSBzYXlzIHRoYXQgY29uc2VudCBpcyBub3QgbmVlZGVkIG9uIGEgcGFpciBpZiBu byBtZWRpYSBpcyBiZWluZyBzZW50LiBTbyBvbmUgbWlnaHQ8YnI+DQomZ3Q7IGludGVycHJldCB0 aGUgZXhpc3RpbmcgZHJhZnQgYXMgbm90IGltcG9zaW5nIGFuIElDRSByZXN0YXJ0IHJlcXVpcmVt ZW50IGluIHRoYXQgY2FzZSAoaG93IGNhbiBjb25zZW50IGV4cGlyZSBpZiBjb25zZW50IGlzIG5v dCByZXF1aXJlZD8/KTxicj4NCjxicj4NCjwvc3Bhbj5Db3JyZWN0Ljxicj4NCjxicj4NCkkgdGhp bmsgYWxsIHRoYXQgaXMgbmVlZGVkIGlzIGEgY2xhcmlmaWNhdGlvbiBzdGF0ZW1lbnQgc2F5aW5n IHRoYXQgc3RvcCBzZW5kaW5nIHRvIGNvbnNlbnQgcmVxdWVzdHMgc2hhbGwgbm90IGJlIGNvbnNp ZGVyZWQgbG9zcyBvZiBjb25zZW50LCBhbmQgdGhhdCBhIHNlbmRlciBjYW4gbGF0ZXIgcmVxdWVz dCBjb25zZW50IG9uIHRoZSBzYW1lIGNhbmRpZGF0ZSBwYWlyIGFnYWluIC0gd2l0aG91dCBoYXZp bmcgdG8gZG8gYW4gSUNFIHJlc3RhcnQuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pg0KPGRpdj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFs bCI+4oCLPC9zcGFuPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPkV4 aXN0aW5nIHRlc3Q6Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwg aGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QW4gZW5kcG9pbnQgdGhhdCBpcyBu b3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvPC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7bWFpbnRhaW4gY29uc2VudC4mbmJzcDsgSG93ZXZlciwgbm90IHNlbmRpbmcgYW55 IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJh cmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7b3IgZmlyZXdhbGwgbWFw cGluZ3MgdG8gZXhwaXJlLiZuYnNwOyBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJs ZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwO3RvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2Nv bHMuJm5ic3A7IEFic2VudCBiZXR0ZXIgaW5mb3JtYXRpb248L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDthYm91 dCB0aGUgbmV0d29yaywgaWYgYW4gZW5kcG9pbnQgbmVlZHMgdG8gZW5zdXJlIGl0cyBOQVQgb3Ig ZmlyZXdhbGw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2Es IHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDttYXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4g YmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXI8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt0ZWNobmlx dWVzIChzZWUgU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0gYW5kIHNlZSBbUkZDNjI2M10pLjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+ PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBz YW5zLXNlcmlmIj5OZXcgdGVzdDo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFs LCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtBbiBlbmRwb2ludCB0aGF0IGlz IG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGFmdGVyIG9idGFpbmluZyZuYnNwOzwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwO2NvbnNlbnQgZG9lcyBub3QgbmVlZCB0byBtYWludGFpbiBjb25zZW50 LiBBcyBzb29uIGFzIHRoZSBlbmRwb2ludDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i YXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3N0YXJ0cyBzZW5kaW5n IGFwcGxpY2F0aW9uIGFnYWluLCBjb25zZW50IGlzIG1haW50YWluZWQgZm9sbG93aW5nIHRoZSZu YnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3Byb2NlZHVyZSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVu dC48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMt c2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZl dGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0hvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0 cmFmZmljIGNvdWxkIGNhdXNlIE5BVCBvciBmaXJld2FsbCBtYXBwaW5ncyZuYnNwOzwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwO3RvIGV4cGlyZS4gRnVydGhlcm1vcmUsIGhhdmluZyBvbmUgcGVlciB1bmFibGUg dG8gc2VuZCBpcyBkZXRyaW1lbnRhbCZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3RvIG1hbnkgcHJv dG9jb2xzLiZuYnNwOyBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZXR3b3Jr LCBpZiBhbiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZl dGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2VuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBp dHMgTkFUIG9yIGZpcmV3YWxsIG1hcHBpbmdzIGRvIG5vdCBleHBpcmUsJm5ic3A7PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7aXQgY2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9yIG90aGVyIHRlY2huaXF1 ZXMgKHNlZSBTZWN0aW9uIDEwIG9mJm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNl PSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7W1JGQzUyNDVdIGFu ZCBzZWUgW1JGQzYyNjNdKS48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6c21hbGwiPkRvZXMgaXQgd29yaz88L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTpzbWFsbCI+dGhhbmtzLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+TXV0aHU8L2Rpdj4NCjwv ZGl2Pg0KPHNwYW4+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0 aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IGJvcmRlci1sZWZ0LXN0 eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxicj4NCklDRSByZXN0YXJ0IGlzIG9ubHkg cmVxdWlyZWQgd2hlbiBhIHNlbmRlciBoYXMgcmVxdWVzdGVkIGNvbnNlbnQsIGJ1dCBoYXMgbm90 IGdvdCBpdCAoaS5lLiB0aGVyZSB3YXMgbm8gcmVzcG9uc2UgdG8gdGhlIGNvbnNlbnQgZnJlc2hu ZXNzIHJlcXVlc3QpLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+ DQo8ZGl2Pg0KPGRpdj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiByZWw9Im5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYjwvYT48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9z cGFuPjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D8F2E37ESESSMB209erics_-- From nobody Thu Jun 18 23:02:04 2015 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 E636D1A1B7D for ; Thu, 18 Jun 2015 23:02:02 -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 iEzqSOVmyE7q for ; Thu, 18 Jun 2015 23:02:00 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4F01A1B76 for ; Thu, 18 Jun 2015 23:01:59 -0700 (PDT) Received: by wiga1 with SMTP id a1so8707203wig.0 for ; Thu, 18 Jun 2015 23:01:58 -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=xfFP5ZvPwQ2DUZ8sCaRt1y1W1f4VSuwb3fGNkvYF2Z8=; b=YA40C6qm0xmGoptcV2CEbl10g8NIp4czS0ieEJgwwSZN7HVKGR13Lo6wnlnVIDxf4E AQHtsdU1WnNkqWml+lq+eqaKLkXaqOAO5cz8pl3yy9bsyCbz1dT6PpZSJdq4KuIO0TZg LlTyqRulD0y0sThTdmWU6ROQmEGYbPKbgiSODjnfcBIJV7b3hP7hsA46yGP0qemg9YtG aKULMOUGy/JNSCv9DH7apOlsNgUg2iWXFTXFL+HAT1I+6igWN/ZYbh4JGKtXrnBdw7pY u6LG1ncmoIqnBXZxmVgpbAuPXf5Ojh+g+Wdf3NmhlJjpioSbOww2UByHscIMhauU7JZ5 azsg== MIME-Version: 1.0 X-Received: by 10.180.23.8 with SMTP id i8mr3174880wif.39.1434693718618; Thu, 18 Jun 2015 23:01:58 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Thu, 18 Jun 2015 23:01:58 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 11:31:58 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013d12ca75b4e20518d8a935 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 06:02:03 -0000 --089e013d12ca75b4e20518d8a935 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think an ICE-restart can still be performed for a bunch of other reasons. Here is my take: New text: An endpoint that is not sending any application data after obtaining consent does not need to maintain consent. The endpoint can resume sending application data using the consent obtained earlier. As soon as the endpoint resumes sending application data, consent is maintained following the procedure described in this document. Would that work? thanks, Muthu On Fri, Jun 19, 2015 at 11:05 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The text otherwise looks good, but I suggest adding the following after > the "As soon as..." statement: "In this case the endpoint does not need t= o > perform ICE restart." > > Thanks! > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Muthu Arul Mozhi Perumal > Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 06:18 > To: Bernard Aboba > Cc: Christer Holmberg ; Martin Thomson > ; rtcweb@ietf.org > Subject: Re: [rtcweb] Comment on consent-freshness-14 > > Thanks. It was missed in a haste :) > > Muthu > > On Fri, Jun 19, 2015 at 8:44 AM, Bernard Aboba > wrote: > >> s/sending application/sending application data/ >> >> Otherwise, WFM. >> >> >> >> On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal < >> muthu.arul@gmail.com> wrote: >> >> s/test/text.. >> >> On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal < >> muthu.arul@gmail.com> wrote: >> >>> On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> >>> Then, if the sender later wants to start sending media on the >>>> >>> candidate pair again, it simply start sending consent requests >>>> again. >>>> >> >>>> >> From a security perspective, this would be OK. Functionally howeve= r, >>>> >> do you really expect that to work? NATs and relays tend to garbage >>>> >> collect pretty aggressively. >>>> > >>>> > It might not work if no keepalives are sent. But Christer's point is >>>> that consent is not required since no media is being sent. >>>> >>>> Correct. >>>> >>>> >>>> >>> However, the way I read the draft now is that it would require an >>>> ICE >>>> >>> restart, and I don=E2=80=99t think we want that? >>>> >> >>>> >> Why the question? You are the one who has to decide if you want >>>> that. >>>> > >>>> > I think Christer's point is that this should not be considered a los= s >>>> of consent. >>>> >>>> Correct. >>>> >>>> Loss of consent is defined as not receiving a response to a sent >>>> consent request - but in this case there is not consent request sent t= o >>>> begin with :) >>>> >>>> > The draft already says that consent is not needed on a pair if no >>>> media is being sent. So one might >>>> > interpret the existing draft as not imposing an ICE restart >>>> requirement in that case (how can consent expire if consent is not >>>> required??) >>>> >>>> Correct. >>>> >>>> I think all that is needed is a clarification statement saying that >>>> stop sending to consent requests shall not be considered loss of conse= nt, >>>> and that a sender can later request consent on the same candidate pair >>>> again - without having to do an ICE restart. >>>> >>> >>> >>> =E2=80=8BExisting test: >>> An endpoint that is not sending any application data does not need t= o >>> maintain consent. However, not sending any traffic could cause NAT >>> or firewall mappings to expire. Furthermore, having one peer unable >>> to send is detrimental to many protocols. Absent better information >>> about the network, if an endpoint needs to ensure its NAT or firewal= l >>> mappings do not expire, it can be done using keepalive or other >>> techniques (see Section 10 of [RFC5245] and see [RFC6263]). >>> >>> New test: >>> An endpoint that is not sending any application data after obtaining >>> consent does not need to maintain consent. As soon as the endpoint >>> starts sending application again, consent is maintained following th= e >>> procedure described in this document. >>> >>> However, not sending any traffic could cause NAT or firewall >>> mappings >>> to expire. Furthermore, having one peer unable to send is detrimenta= l >>> to many protocols. Absent better information about the network, if >>> an >>> endpoint needs to ensure its NAT or firewall mappings do not expire, >>> it can be done using keepalive or other techniques (see Section 10 o= f >>> [RFC5245] and see [RFC6263]). >>> >>> Does it work? >>> >>> thanks, >>> Muthu >>> >>> >>>> >>>> ICE restart is only required when a sender has requested consent, but >>>> has not got it (i.e. there was no response to the consent freshness >>>> request). >>>> >>>> Regards, >>>> >>>> Christer >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> >> > --089e013d12ca75b4e20518d8a935 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think an ICE-restart can still be per= formed for a bunch of other reasons. Here is my take:

New text:
=C2=A0 =C2=A0An endpoint that is not sending any applic= ation data after obtaining=C2=A0
=C2=A0 = =C2=A0consent does not need to maintain consent. The endpoint can resume se= nding=C2=A0
=C2=A0 =C2=A0application data= using the consent obtained earlier. As soon as the endpoint=C2=A0
=C2=A0 =C2=A0resumes sending application data, co= nsent is maintained following the=C2=A0
= =C2=A0 =C2=A0procedure described in this document.

Would that work?

thanks,
Muthu
=
On Fri, Jun 19, 2015 at 11:05 AM, Christer H= olmberg <christer.holmberg@ericsson.com> wrote:=
Hi,

The text otherwise looks good, but I suggest adding the following after the= "As soon as..." statement: "In this case the endpoint does = not need to perform ICE restart."

Thanks!

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Peruma= l
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 06:18
To: Bernard Aboba
Cc: Christer Holm= berg; Martin Thomso= n; rtcweb@ietf.org
Subject: Re: [r= tcweb] Comment on consent-freshness-14

Thanks. It was missed in a haste :)

Muthu

On Fri, Jun 19, 2015 at 8:44 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard.ab= oba@gmail.com> wrote:
s/sending application/sending application data/

Otherwise, WFM.



On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote= :

s/tes= t/text..

On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozh= i Perumal <muthu.arul@gmail.com> wrote:
On Fri, Jun 19, 2015 at 2:58 AM, Ch= rister Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

>>> Then, if the sender later wants to start sending media on the<= br> >>> candidate pair again, it simply start sending consent requests= again.
>>
>> From a security perspective, this would be OK.=C2=A0 Functionally = however,
>> do you really expect that to work?=C2=A0 NATs and relays tend to g= arbage
>> collect pretty aggressively.
>
> It might not work if no keepalives are sent. But Christer's point = is that consent is not required since no media is being sent.

Correct.


>>> However, the way I read the draft now is that it would require= an ICE
>>> restart, and I don=E2=80=99t think we want that?
>>
>> Why the question?=C2=A0 You are the one who has to decide if you w= ant that.
>
> I think Christer's point is that this should not be considered a l= oss of consent.

Correct.

Loss of consent is defined as not receiving a response to a sent consent re= quest - but in this case there is not consent request sent to begin with :)=

> The draft already says that consent is not needed on a pair if no medi= a is being sent. So one might
> interpret the existing draft as not imposing an ICE restart requiremen= t in that case (how can consent expire if consent is not required??)

Correct.

I think all that is needed is a clarification statement saying that stop se= nding to consent requests shall not be considered loss of consent, and that= a sender can later request consent on the same candidate pair again - with= out having to do an ICE restart.
=E2=80=8BExisting test:= =C2=A0
=C2=A0 =C2=A0An endpoint t= hat is not sending any application data does not need to
=C2=A0 =C2=A0maintain cons= ent.=C2=A0 However, not sending any traffic could cause NAT
=C2=A0 =C2=A0or firewall m= appings to expire.=C2=A0 Furthermore, having one peer unable
=C2=A0 =C2=A0to send is de= trimental to many protocols.=C2=A0 Absent better information
=C2=A0 =C2=A0about the net= work, if an endpoint needs to ensure its NAT or firewall
=C2=A0 =C2=A0mappings do n= ot expire, it can be done using keepalive or other
=C2=A0 =C2=A0techniques (s= ee Section 10 of [RFC5245] and see [RFC6263]).

New test:
=C2=A0 =C2=A0An endpoint t= hat is not sending any application data after obtaining=C2=A0
=C2=A0 =C2=A0consent does = not need to maintain consent. As soon as the endpoint
=C2=A0 =C2=A0starts sendin= g application again, consent is maintained following the=C2=A0
=C2=A0 =C2=A0procedure des= cribed in this document.

=C2=A0 =C2=A0However, not = sending any traffic could cause NAT or firewall mappings=C2=A0
=C2=A0 =C2=A0to expire. Fu= rthermore, having one peer unable to send is detrimental=C2=A0
=C2=A0 =C2=A0to many proto= cols.=C2=A0 Absent better information about the network, if an=C2=A0=
=C2=A0 =C2=A0endpoint need= s to ensure its NAT or firewall mappings do not expire,=C2=A0
=C2=A0 =C2=A0it can be don= e using keepalive or other techniques (see Section 10 of=C2=A0
=C2=A0 =C2=A0[RFC5245] and= see [RFC6263]).

Does = it work?

thank= s,
Muthu=
=C2=A0

ICE restart is only required when a sender has requested consent, but has n= ot got it (i.e. there was no response to the consent freshness request).
Regards,

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




--089e013d12ca75b4e20518d8a935-- From nobody Fri Jun 19 01:55:37 2015 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 81B351A8790 for ; Fri, 19 Jun 2015 01:55:36 -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 OACGLayfodCw for ; Fri, 19 Jun 2015 01:55:33 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE551A8799 for ; Fri, 19 Jun 2015 01:55:32 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-59-5583d902f874 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.9C.04015.209D3855; Fri, 19 Jun 2015 10:55:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 10:55:30 +0200 From: Christer Holmberg To: Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAAUgJ0 Date: Fri, 19 Jun 2015 08:55:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F2F9B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F2F9BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3Vpf5ZnOowYxmDosN+/4zW1w784/R 4s9mP4u1/9rZHVg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6Mtr+nGAtOXWWs+LVhF1sD 44/zjF2MnBwSAiYSZ6c+ZIWwxSQu3FvP1sXIxSEkcJRRYvapL6wQzmJGiX3vjgE5HBxsAhYS 3f+0QRpEBIwltrT8AmtmFqiVaDsFYQsLmEqsuTyHGaLGTKL17ExWCDtP4v+hDWwgNouAqkTr ynnsIDavgK/ElK8nGSF2zWGVOPv+O9h1nAKBEk/7vjGB2IxA130/tYYJYpm4RNOXlVBXC0gs 2XOeGcIWlXj5+B/UQfkSPUsOM0MsEJQ4OfMJywRGkVlI2mchKZuFpGwW0JvMApoS63fpQ5Qo SkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYLQd3PLbYAfj y+eOhxgFOBiVeHgV1JpChVgTy4orcw8xSnOwKInzzticFyokkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qB0bH4SWrMj8e/V1X5BYrfnfJco39C4eNDlWphmw42T6kNyDYs99p96K6t6l51qa0s ugUiDiZX3WuLS5bzvZH2PJZkmJd5Yr/+co+WzP/TJws81u+zPGglM3utnrUy52n9d6s6btrM FbNa6q7wVOjr3Z0HtJW4hEW3fjkSYuO4VS+val/qSUsfJZbijERDLeai4kQA8+w8Q5cCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 08:55:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F2F9BESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClN1cmUsIHRoZXJlIG1heSBiZSBhIG5lZWQgdG8gcGVyZm9ybSBJQ0UgcmVzdGFydCBm b3Igc29tZSBvdGhlciByZWFzb25zLCBhbmQgbXkgc3VnZ2VzdGVkIHRleHQgZG9lcyBub3QgZm9y YmlkIGl0LiBCdXQsIEkgcmVxdWVzdCBhIHN0YXRlbWVudCBzYXlpbmcgdGhhdCBhbiBJQ0UgcmVz dGFydCBpcyBub3QgcmVxdWlyZWQgc2ltcGx5IGJlY2F1c2UgeW91IHdhbnQgdG8gc3RhcnQgc2Vu ZGluZyBkYXRhIGFnYWluLg0KDQpQZXJoYXBzOg0KDQoiSW4gdGhpcyBjYXNlIGFuIElDRSByZXN0 YXJ0IGlzIG5vdCByZXF1aXJlZCwgYXMgaXMgdGhlIGNhc2Ugd2hlbiB0aGUgc2VuZGVyIGZhaWxz IHRvIGdldCBjb25zZW50LiINCg0KRnJvbSBleHBlcmllbmNlIEkgYW0gcHJldHR5IHN1cmUgdGhh dCwgaWYgd2UgZG9uJ3QgaGF2ZSBleHBsaWNpdCB0ZXh0LCB3ZSB3aWxsIHNvb24gaGF2ZSBkby1J LW5lZWQtdG8tZG8tSUNFLXJlc3RhcnQgbWFpbHMgb24gdGhlIGxpc3QgOikNCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpGcm9tOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8bWFpbHRv Om11dGh1LmFydWxAZ21haWwuY29tPg0KU2VudDog4oCOMTkv4oCOMDYv4oCOMjAxNSAwOTowMQ0K VG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+DQpDYzogQmVybmFyZCBBYm9iYTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+OyBN YXJ0aW4gVGhvbXNvbjxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPjsgcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQ29t bWVudCBvbiBjb25zZW50LWZyZXNobmVzcy0xNA0KDQpJIHRoaW5rIGFuIElDRS1yZXN0YXJ0IGNh biBzdGlsbCBiZSBwZXJmb3JtZWQgZm9yIGEgYnVuY2ggb2Ygb3RoZXIgcmVhc29ucy4gSGVyZSBp cyBteSB0YWtlOg0KDQpOZXcgdGV4dDoNCiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRp bmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgYWZ0ZXIgb2J0YWluaW5nDQogICBjb25zZW50IGRvZXMg bm90IG5lZWQgdG8gbWFpbnRhaW4gY29uc2VudC4gVGhlIGVuZHBvaW50IGNhbiByZXN1bWUgc2Vu ZGluZw0KICAgYXBwbGljYXRpb24gZGF0YSB1c2luZyB0aGUgY29uc2VudCBvYnRhaW5lZCBlYXJs aWVyLiBBcyBzb29uIGFzIHRoZSBlbmRwb2ludA0KICAgcmVzdW1lcyBzZW5kaW5nIGFwcGxpY2F0 aW9uIGRhdGEsIGNvbnNlbnQgaXMgbWFpbnRhaW5lZCBmb2xsb3dpbmcgdGhlDQogICBwcm9jZWR1 cmUgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCldvdWxkIHRoYXQgd29yaz8NCg0KdGhh bmtzLA0KTXV0aHUNCg0KT24gRnJpLCBKdW4gMTksIDIwMTUgYXQgMTE6MDUgQU0sIENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNClRoZSB0ZXh0IG90aGVyd2lz ZSBsb29rcyBnb29kLCBidXQgSSBzdWdnZXN0IGFkZGluZyB0aGUgZm9sbG93aW5nIGFmdGVyIHRo ZSAiQXMgc29vbiBhcy4uLiIgc3RhdGVtZW50OiAiSW4gdGhpcyBjYXNlIHRoZSBlbmRwb2ludCBk b2VzIG5vdCBuZWVkIHRvIHBlcmZvcm0gSUNFIHJlc3RhcnQuIg0KDQpUaGFua3MhDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsPG1h aWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbT4NClNlbnQ6IOKAjjE5L+KAjjA2L+KAjjIwMTUgMDY6 MTgNClRvOiBCZXJuYXJkIEFib2JhPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4NCkNj OiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PjsgTWFydGluIFRob21zb248bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IHJ0Y3dl YkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJd IENvbW1lbnQgb24gY29uc2VudC1mcmVzaG5lc3MtMTQNCg0KVGhhbmtzLiBJdCB3YXMgbWlzc2Vk IGluIGEgaGFzdGUgOikNCg0KTXV0aHUNCg0KT24gRnJpLCBKdW4gMTksIDIwMTUgYXQgODo0NCBB TSwgQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQu YWJvYmFAZ21haWwuY29tPj4gd3JvdGU6DQpzL3NlbmRpbmcgYXBwbGljYXRpb24vc2VuZGluZyBh cHBsaWNhdGlvbiBkYXRhLw0KDQpPdGhlcndpc2UsIFdGTS4NCg0KDQoNCk9uIEp1biAxOCwgMjAx NSwgYXQgOTowOCBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIDxtdXRodS5hcnVsQGdtYWls LmNvbTxtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20+PiB3cm90ZToNCg0Kcy90ZXN0L3RleHQu Lg0KDQpPbiBGcmksIEp1biAxOSwgMjAxNSBhdCA2OjM3IEFNLCBNdXRodSBBcnVsIE1vemhpIFBl cnVtYWwgPG11dGh1LmFydWxAZ21haWwuY29tPG1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbT4+ IHdyb3RlOg0KT24gRnJpLCBKdW4gMTksIDIwMTUgYXQgMjo1OCBBTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KPj4+IFRoZW4sIGlmIHRoZSBzZW5kZXIg bGF0ZXIgd2FudHMgdG8gc3RhcnQgc2VuZGluZyBtZWRpYSBvbiB0aGUNCj4+PiBjYW5kaWRhdGUg cGFpciBhZ2FpbiwgaXQgc2ltcGx5IHN0YXJ0IHNlbmRpbmcgY29uc2VudCByZXF1ZXN0cyBhZ2Fp bi4NCj4+DQo+PiBGcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIHRoaXMgd291bGQgYmUgT0su ICBGdW5jdGlvbmFsbHkgaG93ZXZlciwNCj4+IGRvIHlvdSByZWFsbHkgZXhwZWN0IHRoYXQgdG8g d29yaz8gIE5BVHMgYW5kIHJlbGF5cyB0ZW5kIHRvIGdhcmJhZ2UNCj4+IGNvbGxlY3QgcHJldHR5 IGFnZ3Jlc3NpdmVseS4NCj4NCj4gSXQgbWlnaHQgbm90IHdvcmsgaWYgbm8ga2VlcGFsaXZlcyBh cmUgc2VudC4gQnV0IENocmlzdGVyJ3MgcG9pbnQgaXMgdGhhdCBjb25zZW50IGlzIG5vdCByZXF1 aXJlZCBzaW5jZSBubyBtZWRpYSBpcyBiZWluZyBzZW50Lg0KDQpDb3JyZWN0Lg0KDQoNCj4+PiBI b3dldmVyLCB0aGUgd2F5IEkgcmVhZCB0aGUgZHJhZnQgbm93IGlzIHRoYXQgaXQgd291bGQgcmVx dWlyZSBhbiBJQ0UNCj4+PiByZXN0YXJ0LCBhbmQgSSBkb27igJl0IHRoaW5rIHdlIHdhbnQgdGhh dD8NCj4+DQo+PiBXaHkgdGhlIHF1ZXN0aW9uPyAgWW91IGFyZSB0aGUgb25lIHdobyBoYXMgdG8g ZGVjaWRlIGlmIHlvdSB3YW50IHRoYXQuDQo+DQo+IEkgdGhpbmsgQ2hyaXN0ZXIncyBwb2ludCBp cyB0aGF0IHRoaXMgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGEgbG9zcyBvZiBjb25zZW50Lg0K DQpDb3JyZWN0Lg0KDQpMb3NzIG9mIGNvbnNlbnQgaXMgZGVmaW5lZCBhcyBub3QgcmVjZWl2aW5n IGEgcmVzcG9uc2UgdG8gYSBzZW50IGNvbnNlbnQgcmVxdWVzdCAtIGJ1dCBpbiB0aGlzIGNhc2Ug dGhlcmUgaXMgbm90IGNvbnNlbnQgcmVxdWVzdCBzZW50IHRvIGJlZ2luIHdpdGggOikNCg0KPiBU aGUgZHJhZnQgYWxyZWFkeSBzYXlzIHRoYXQgY29uc2VudCBpcyBub3QgbmVlZGVkIG9uIGEgcGFp ciBpZiBubyBtZWRpYSBpcyBiZWluZyBzZW50LiBTbyBvbmUgbWlnaHQNCj4gaW50ZXJwcmV0IHRo ZSBleGlzdGluZyBkcmFmdCBhcyBub3QgaW1wb3NpbmcgYW4gSUNFIHJlc3RhcnQgcmVxdWlyZW1l bnQgaW4gdGhhdCBjYXNlIChob3cgY2FuIGNvbnNlbnQgZXhwaXJlIGlmIGNvbnNlbnQgaXMgbm90 IHJlcXVpcmVkPz8pDQoNCkNvcnJlY3QuDQoNCkkgdGhpbmsgYWxsIHRoYXQgaXMgbmVlZGVkIGlz IGEgY2xhcmlmaWNhdGlvbiBzdGF0ZW1lbnQgc2F5aW5nIHRoYXQgc3RvcCBzZW5kaW5nIHRvIGNv bnNlbnQgcmVxdWVzdHMgc2hhbGwgbm90IGJlIGNvbnNpZGVyZWQgbG9zcyBvZiBjb25zZW50LCBh bmQgdGhhdCBhIHNlbmRlciBjYW4gbGF0ZXIgcmVxdWVzdCBjb25zZW50IG9uIHRoZSBzYW1lIGNh bmRpZGF0ZSBwYWlyIGFnYWluIC0gd2l0aG91dCBoYXZpbmcgdG8gZG8gYW4gSUNFIHJlc3RhcnQu DQoNCg0K4oCLRXhpc3RpbmcgdGVzdDoNCiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRp bmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bw0KICAgbWFpbnRhaW4gY29u c2VudC4gIEhvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVA0K ICAgb3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZyBv bmUgcGVlciB1bmFibGUNCiAgIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2Nv bHMuICBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uDQogICBhYm91dCB0aGUgbmV0d29yaywgaWYg YW4gZW5kcG9pbnQgbmVlZHMgdG8gZW5zdXJlIGl0cyBOQVQgb3IgZmlyZXdhbGwNCiAgIG1hcHBp bmdzIGRvIG5vdCBleHBpcmUsIGl0IGNhbiBiZSBkb25lIHVzaW5nIGtlZXBhbGl2ZSBvciBvdGhl cg0KICAgdGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdIGFuZCBzZWUgW1JG QzYyNjNdKS4NCg0KTmV3IHRlc3Q6DQogICBBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5n IGFueSBhcHBsaWNhdGlvbiBkYXRhIGFmdGVyIG9idGFpbmluZw0KICAgY29uc2VudCBkb2VzIG5v dCBuZWVkIHRvIG1haW50YWluIGNvbnNlbnQuIEFzIHNvb24gYXMgdGhlIGVuZHBvaW50DQogICBz dGFydHMgc2VuZGluZyBhcHBsaWNhdGlvbiBhZ2FpbiwgY29uc2VudCBpcyBtYWludGFpbmVkIGZv bGxvd2luZyB0aGUNCiAgIHByb2NlZHVyZSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0K ICAgSG93ZXZlciwgbm90IHNlbmRpbmcgYW55IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUIG9yIGZp cmV3YWxsIG1hcHBpbmdzDQogICB0byBleHBpcmUuIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lIHBl ZXIgdW5hYmxlIHRvIHNlbmQgaXMgZGV0cmltZW50YWwNCiAgIHRvIG1hbnkgcHJvdG9jb2xzLiAg QWJzZW50IGJldHRlciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0d29yaywgaWYgYW4NCiAgIGVu ZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsIG1hcHBpbmdzIGRvIG5v dCBleHBpcmUsDQogICBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXIgdGVj aG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YNCiAgIFtSRkM1MjQ1XSBhbmQgc2VlIFtSRkM2MjYz XSkuDQoNCkRvZXMgaXQgd29yaz8NCg0KdGhhbmtzLA0KTXV0aHUNCg0KDQpJQ0UgcmVzdGFydCBp cyBvbmx5IHJlcXVpcmVkIHdoZW4gYSBzZW5kZXIgaGFzIHJlcXVlc3RlZCBjb25zZW50LCBidXQg aGFzIG5vdCBnb3QgaXQgKGkuZS4gdGhlcmUgd2FzIG5vIHJlc3BvbnNlIHRvIHRoZSBjb25zZW50 IGZyZXNobmVzcyByZXF1ZXN0KS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0 DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D8F2F9BESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPkhp LDxicj4NCjxicj4NClN1cmUsIHRoZXJlIG1heSBiZSBhIG5lZWQgdG8gcGVyZm9ybSBJQ0UgcmVz dGFydCBmb3Igc29tZSBvdGhlciByZWFzb25zLCBhbmQgbXkgc3VnZ2VzdGVkIHRleHQgZG9lcyBu b3QgZm9yYmlkIGl0LiBCdXQsIEkgcmVxdWVzdCBhIHN0YXRlbWVudCBzYXlpbmcgdGhhdCBhbiBJ Q0UgcmVzdGFydCBpcyBub3QgcmVxdWlyZWQgc2ltcGx5IGJlY2F1c2UgeW91IHdhbnQgdG8gc3Rh cnQgc2VuZGluZyBkYXRhIGFnYWluLjxicj4NCjxicj4NClBlcmhhcHM6PGJyPg0KPGJyPg0KJnF1 b3Q7SW4gdGhpcyBjYXNlIGFuIElDRSByZXN0YXJ0IGlzIG5vdCByZXF1aXJlZCwgYXMgaXMgdGhl IGNhc2Ugd2hlbiB0aGUgc2VuZGVyIGZhaWxzIHRvIGdldCBjb25zZW50LiZxdW90Ozxicj4NCjxi cj4NCkZyb20gZXhwZXJpZW5jZSBJIGFtIHByZXR0eSBzdXJlIHRoYXQsIGlmIHdlIGRvbid0IGhh dmUgZXhwbGljaXQgdGV4dCwgd2Ugd2lsbCBzb29uIGhhdmUgZG8tSS1uZWVkLXRvLWRvLUlDRS1y ZXN0YXJ0IG1haWxzIG9uIHRoZSBsaXN0IDopPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+ DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGhyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkZyb206 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9u dC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbSI+TXV0aHUg QXJ1bCBNb3poaSBQZXJ1bWFsPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+ U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6MTFwdCI+4oCOMTkv4oCOMDYv4oCOMjAxNSAwOTowMTwvc3Bhbj48YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dDsgZm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPkNocmlzdGVyIEhvbG1iZXJnPC9hPjwvc3Bhbj48 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNp emU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0 bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSI+QmVybmFyZCBBYm9iYTwvYT47DQo8YSBocmVmPSJt YWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5NYXJ0aW4gVGhvbXNvbjwvYT47IDxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPg0KcnRjd2ViQGlldGYub3JnPC9hPjwvc3Bhbj48 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNp emU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+UmU6IFtydGN3 ZWJdIENvbW1lbnQgb24gY29uc2VudC1mcmVzaG5lc3MtMTQ8L3NwYW4+PGJyPg0KPGJyPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBz dHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpz bWFsbCI+DQpJIHRoaW5rIGFuIElDRS1yZXN0YXJ0IGNhbiBzdGlsbCBiZSBwZXJmb3JtZWQgZm9y IGEgYnVuY2ggb2Ygb3RoZXIgcmVhc29ucy4gSGVyZSBpcyBteSB0YWtlOjwvZGl2Pg0KPGRpdiBj bGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJn bWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpOZXcgdGV4dDo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOnNtYWxsIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJz cDtBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGFm dGVyIG9idGFpbmluZyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5i c3A7ICZuYnNwO2NvbnNlbnQgZG9lcyBub3QgbmVlZCB0byBtYWludGFpbiBjb25zZW50LiBUaGUg ZW5kcG9pbnQgY2FuIHJlc3VtZSBzZW5kaW5nJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7YXBwbGljYXRpb24gZGF0YSB1c2luZyB0aGUgY29uc2Vu dCBvYnRhaW5lZCBlYXJsaWVyLiBBcyBzb29uIGFzIHRoZSBlbmRwb2ludCZuYnNwOzwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwO3Jlc3VtZXMgc2VuZGluZyBh cHBsaWNhdGlvbiBkYXRhLCBjb25zZW50IGlzIG1haW50YWluZWQgZm9sbG93aW5nIHRoZSZuYnNw OzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5ic3A7ICZuYnNwO3Byb2NlZHVy ZSBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2Rl ZmF1bHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+V291bGQgdGhh dCB3b3JrPzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+PGJyPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0Ij50aGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0Ij5NdXRodTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+ PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgSnVuIDE5LCAyMDE1IGF0IDEx OjA1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHgg MC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwy MDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZToxMXB0Ij5IaSw8YnI+DQo8YnI+DQpUaGUgdGV4dCBvdGhlcndpc2UgbG9va3MgZ29v ZCwgYnV0IEkgc3VnZ2VzdCBhZGRpbmcgdGhlIGZvbGxvd2luZyBhZnRlciB0aGUgJnF1b3Q7QXMg c29vbiBhcy4uLiZxdW90OyBzdGF0ZW1lbnQ6ICZxdW90O0luIHRoaXMgY2FzZSB0aGUgZW5kcG9p bnQgZG9lcyBub3QgbmVlZCB0byBwZXJmb3JtIElDRSByZXN0YXJ0LiZxdW90Ozxicj4NCjxicj4N ClRoYW5rcyE8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJy Pg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0 ciI+DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJl Zj0ibWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+TXV0aHUgQXJ1 bCBNb3poaSBQZXJ1bWFsPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2Vu dDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTFwdCI+4oCOMTkv4oCOMDYv4oCOMjAxNSAwNjoxODwvc3Bhbj48YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsg Zm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpiZXJuYXJk LmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkJlcm5hcmQgQWJvYmE8L2E+PC9zcGFu Pjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5DYzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlz dGVyIEhvbG1iZXJnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5NYXJ0aW4gVGhvbXNvbjwvYT47IDxhIGhyZWY9Im1haWx0bzpy dGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT48L3Nw YW4+PHNwYW4gY2xhc3M9IiI+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQiPlJlOiBbcnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0PC9z cGFuPjxicj4NCjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8 ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj5UaGFua3MuIEl0IHdhcyBtaXNzZWQg aW4gYSBoYXN0ZSA6KTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0 aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxs Ij5NdXRodTwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBGcmksIEp1biAxOSwgMjAxNSBhdCA4OjQ0IEFNLCBCZXJuYXJkIEFi b2JhIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7 PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVy LWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBh ZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5zL3NlbmRpbmcgYXBwbGlj YXRpb24vc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhLzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+T3RoZXJ3aXNlLCBXRk0uPGJyPg0KPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+PGJyPg0KT24gSnVuIDE4LCAyMDE1LCBhdCA5OjA4IFBNLCBNdXRodSBBcnVsIE1v emhpIFBlcnVtYWwgJmx0OzxhIGhyZWY9Im1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPm11dGh1LmFydWxAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJy Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRy Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBm b250LXNpemU6c21hbGwiPnMvdGVzdC90ZXh0Li48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBKdW4gMTksIDIwMTUg YXQgNjozNyBBTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsDQo8c3BhbiBkaXI9Imx0ciI+Jmx0 OzxhIGhyZWY9Im1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm11 dGh1LmFydWxAZ21haWwuY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3Rl IGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9y ZGVyLWxlZnQtd2lkdGg6MXB4OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBi b3JkZXItbGVmdC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRy Ij48c3Bhbj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmOyBmb250LXNpemU6c21hbGwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxzYW5z LXNlcmlmIj5PbiBGcmksIEp1biAxOSwgMjAxNSBhdCAyOjU4IEFNLCBDaHJpc3RlciBIb2xtYmVy Zw0KPC9zcGFuPjxzcGFuIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1z ZXJpZiI+Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZiI+IHdyb3RlOjwv c3Bhbj48YnI+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48c3Bhbj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQtd2lkdGg6 MXB4OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBib3JkZXItbGVmdC1zdHls ZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQpIaSw8YnI+DQo8c3Bhbj48YnI+DQomZ3Q7Jmd0 OyZndDsgVGhlbiwgaWYgdGhlIHNlbmRlciBsYXRlciB3YW50cyB0byBzdGFydCBzZW5kaW5nIG1l ZGlhIG9uIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyBjYW5kaWRhdGUgcGFpciBhZ2FpbiwgaXQgc2lt cGx5IHN0YXJ0IHNlbmRpbmcgY29uc2VudCByZXF1ZXN0cyBhZ2Fpbi48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwgdGhpcyB3b3VsZCBiZSBP Sy4mbmJzcDsgRnVuY3Rpb25hbGx5IGhvd2V2ZXIsPGJyPg0KJmd0OyZndDsgZG8geW91IHJlYWxs eSBleHBlY3QgdGhhdCB0byB3b3JrPyZuYnNwOyBOQVRzIGFuZCByZWxheXMgdGVuZCB0byBnYXJi YWdlPGJyPg0KJmd0OyZndDsgY29sbGVjdCBwcmV0dHkgYWdncmVzc2l2ZWx5Ljxicj4NCiZndDs8 YnI+DQomZ3Q7IEl0IG1pZ2h0IG5vdCB3b3JrIGlmIG5vIGtlZXBhbGl2ZXMgYXJlIHNlbnQuIEJ1 dCBDaHJpc3RlcidzIHBvaW50IGlzIHRoYXQgY29uc2VudCBpcyBub3QgcmVxdWlyZWQgc2luY2Ug bm8gbWVkaWEgaXMgYmVpbmcgc2VudC48YnI+DQo8YnI+DQo8L3NwYW4+Q29ycmVjdC48YnI+DQo8 c3Bhbj48YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsgSG93ZXZlciwgdGhlIHdheSBJIHJlYWQgdGhl IGRyYWZ0IG5vdyBpcyB0aGF0IGl0IHdvdWxkIHJlcXVpcmUgYW4gSUNFPGJyPg0KJmd0OyZndDsm Z3Q7IHJlc3RhcnQsIGFuZCBJIGRvbuKAmXQgdGhpbmsgd2Ugd2FudCB0aGF0Pzxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgV2h5IHRoZSBxdWVzdGlvbj8mbmJzcDsgWW91IGFyZSB0aGUgb25l IHdobyBoYXMgdG8gZGVjaWRlIGlmIHlvdSB3YW50IHRoYXQuPGJyPg0KJmd0Ozxicj4NCiZndDsg SSB0aGluayBDaHJpc3RlcidzIHBvaW50IGlzIHRoYXQgdGhpcyBzaG91bGQgbm90IGJlIGNvbnNp ZGVyZWQgYSBsb3NzIG9mIGNvbnNlbnQuPGJyPg0KPGJyPg0KPC9zcGFuPkNvcnJlY3QuPGJyPg0K PGJyPg0KTG9zcyBvZiBjb25zZW50IGlzIGRlZmluZWQgYXMgbm90IHJlY2VpdmluZyBhIHJlc3Bv bnNlIHRvIGEgc2VudCBjb25zZW50IHJlcXVlc3QgLSBidXQgaW4gdGhpcyBjYXNlIHRoZXJlIGlz IG5vdCBjb25zZW50IHJlcXVlc3Qgc2VudCB0byBiZWdpbiB3aXRoIDopPGJyPg0KPHNwYW4+PGJy Pg0KJmd0OyBUaGUgZHJhZnQgYWxyZWFkeSBzYXlzIHRoYXQgY29uc2VudCBpcyBub3QgbmVlZGVk IG9uIGEgcGFpciBpZiBubyBtZWRpYSBpcyBiZWluZyBzZW50LiBTbyBvbmUgbWlnaHQ8YnI+DQom Z3Q7IGludGVycHJldCB0aGUgZXhpc3RpbmcgZHJhZnQgYXMgbm90IGltcG9zaW5nIGFuIElDRSBy ZXN0YXJ0IHJlcXVpcmVtZW50IGluIHRoYXQgY2FzZSAoaG93IGNhbiBjb25zZW50IGV4cGlyZSBp ZiBjb25zZW50IGlzIG5vdCByZXF1aXJlZD8/KTxicj4NCjxicj4NCjwvc3Bhbj5Db3JyZWN0Ljxi cj4NCjxicj4NCkkgdGhpbmsgYWxsIHRoYXQgaXMgbmVlZGVkIGlzIGEgY2xhcmlmaWNhdGlvbiBz dGF0ZW1lbnQgc2F5aW5nIHRoYXQgc3RvcCBzZW5kaW5nIHRvIGNvbnNlbnQgcmVxdWVzdHMgc2hh bGwgbm90IGJlIGNvbnNpZGVyZWQgbG9zcyBvZiBjb25zZW50LCBhbmQgdGhhdCBhIHNlbmRlciBj YW4gbGF0ZXIgcmVxdWVzdCBjb25zZW50IG9uIHRoZSBzYW1lIGNhbmRpZGF0ZSBwYWlyIGFnYWlu IC0gd2l0aG91dCBoYXZpbmcgdG8gZG8gYW4gSUNFIHJlc3RhcnQuPGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pg0K PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTpzbWFsbCI+4oCLPC9zcGFuPjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2Es IHNhbnMtc2VyaWYiPkV4aXN0aW5nIHRlc3Q6Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QW4gZW5k cG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBu ZWVkIHRvPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bWFpbnRhaW4gY29uc2VudC4mbmJzcDsgSG93ZXZlciwg bm90IHNlbmRpbmcgYW55IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 b3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiZuYnNwOyBGdXJ0aGVybW9yZSwgaGF2aW5n IG9uZSBwZWVyIHVuYWJsZTwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhl bHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3RvIHNlbmQgaXMgZGV0cmltZW50YWwg dG8gbWFueSBwcm90b2NvbHMuJm5ic3A7IEFic2VudCBiZXR0ZXIgaW5mb3JtYXRpb248L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDthYm91dCB0aGUgbmV0d29yaywgaWYgYW4gZW5kcG9pbnQgbmVlZHMgdG8gZW5z dXJlIGl0cyBOQVQgb3IgZmlyZXdhbGw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFy aWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDttYXBwaW5ncyBkbyBub3Qg ZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXI8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDt0ZWNobmlxdWVzIChzZWUgU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0gYW5kIHNlZSBb UkZDNjI2M10pLjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGlj YSwgc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlh bCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj5OZXcgdGVzdDo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtBbiBl bmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGFmdGVyIG9i dGFpbmluZyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZl dGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2NvbnNlbnQgZG9lcyBub3QgbmVlZCB0byBt YWludGFpbiBjb25zZW50LiBBcyBzb29uIGFzIHRoZSBlbmRwb2ludDwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw O3N0YXJ0cyBzZW5kaW5nIGFwcGxpY2F0aW9uIGFnYWluLCBjb25zZW50IGlzIG1haW50YWluZWQg Zm9sbG93aW5nIHRoZSZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWws IGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3Byb2NlZHVyZSBkZXNjcmliZWQg aW4gdGhpcyBkb2N1bWVudC48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBo ZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0hvd2V2ZXIsIG5v dCBzZW5kaW5nIGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVCBvciBmaXJld2FsbCBtYXBwaW5n cyZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwg c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3RvIGV4cGlyZS4gRnVydGhlcm1vcmUsIGhhdmluZyBv bmUgcGVlciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCZuYnNwOzwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwO3RvIG1hbnkgcHJvdG9jb2xzLiZuYnNwOyBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBuZXR3b3JrLCBpZiBhbiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2VuZHBvaW50IG5l ZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsIG1hcHBpbmdzIGRvIG5vdCBleHBpcmUs Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7aXQgY2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9y IG90aGVyIHRlY2huaXF1ZXMgKHNlZSBTZWN0aW9uIDEwIG9mJm5ic3A7PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7W1JGQzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS48L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxs Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxz YW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPkRvZXMgaXQgd29yaz88L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+dGhhbmtzLDwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+ TXV0aHU8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBi b3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7 IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxicj4NCklDRSBy ZXN0YXJ0IGlzIG9ubHkgcmVxdWlyZWQgd2hlbiBhIHNlbmRlciBoYXMgcmVxdWVzdGVkIGNvbnNl bnQsIGJ1dCBoYXMgbm90IGdvdCBpdCAoaS5lLiB0aGVyZSB3YXMgbm8gcmVzcG9uc2UgdG8gdGhl IGNvbnNlbnQgZnJlc2huZXNzIHJlcXVlc3QpLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJy Pg0KQ2hyaXN0ZXI8YnI+DQo8ZGl2Pg0KPGRpdj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9zcGFuPjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D8F2F9BESESSMB209erics_-- From nobody Fri Jun 19 02:54:03 2015 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 79C321A8851 for ; Fri, 19 Jun 2015 02:54:02 -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 YirV1jfFt87H for ; Fri, 19 Jun 2015 02:53:59 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13711A8845 for ; Fri, 19 Jun 2015 02:53:58 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so13882349wic.1 for ; Fri, 19 Jun 2015 02:53:57 -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=788rU7OjRyMpLJWEiJuA33UdGwounwD4h3mepbj+g+4=; b=PUj4lhQZvnzZcvgxx/0mLj8LkZj6gGzt7WKqKcUoRI7A6BFCBORSM5CFPoWCFg9Sfh WFPoM9W28u3JKhSIwRr8R5bQ/YpibfsFNl2BHy3e2YRH3Vs5rDVC75MxCaM0Rt1/CN9T KfRraWvswXGks5/J0RxgxiVU7nXufgFx7kLw5+Ya1Xt8idHDZOmywvjY400H7O0lRGWC egKt0h9nAt4lKO34X2dOgkooIlqm3+d6BrCIJE0h3PHOjIFa1SxijmHGXZNYNFNr38uj iNBGi3vmiH/By7DyiO8Irslf034cjsHlC9fey6dBMUArZxSnSekCUGFA6PMASoZSglia P8Jw== MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr24388248wjb.133.1434707637562; Fri, 19 Jun 2015 02:53:57 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Fri, 19 Jun 2015 02:53:57 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F2F9B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2F9B@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 15:23:57 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0116000217f12b0518dbe7c9 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 09:54:02 -0000 --089e0116000217f12b0518dbe7c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about the following text? An endpoint that is not sending any application data after obtaining consent does not need to maintain consent. The endpoint can resume sending application data using the consent obtained earlier (hence, does not nee= d to perform ICE restart). As soon as the endpoint resumes sending application data, consent is maintained following the procedure described in this document. thanks, Muthu On Fri, Jun 19, 2015 at 2:25 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Sure, there may be a need to perform ICE restart for some other reasons, > and my suggested text does not forbid it. But, I request a statement sayi= ng > that an ICE restart is not required simply because you want to start > sending data again. > > Perhaps: > > "In this case an ICE restart is not required, as is the case when the > sender fails to get consent." > > From experience I am pretty sure that, if we don't have explicit text, we > will soon have do-I-need-to-do-ICE-restart mails on the list :) > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Muthu Arul Mozhi Perumal > Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 09:01 > To: Christer Holmberg > Cc: Bernard Aboba ; Martin Thomson > ; rtcweb@ietf.org > > Subject: Re: [rtcweb] Comment on consent-freshness-14 > > I think an ICE-restart can still be performed for a bunch of other > reasons. Here is my take: > > New text: > =E2=80=8B=E2=80=8B > An endpoint that is not sending any application data after obtaining > consent does not need to maintain consent. The endpoint can resume > sending > application data using the consent obtained earlier. As soon as the > endpoint > resumes sending application data, consent is maintained following the > procedure described in this document. > > Would that work? > > thanks, > Muthu > > On Fri, Jun 19, 2015 at 11:05 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> The text otherwise looks good, but I suggest adding the following after >> the "As soon as..." statement: "In this case the endpoint does not need = to >> perform ICE restart." >> >> Thanks! >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------ >> From: Muthu Arul Mozhi Perumal >> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 06:18 >> To: Bernard Aboba >> Cc: Christer Holmberg ; Martin Thomson >> ; rtcweb@ietf.org >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >> >> Thanks. It was missed in a haste :) >> >> Muthu >> >> On Fri, Jun 19, 2015 at 8:44 AM, Bernard Aboba >> wrote: >> >>> s/sending application/sending application data/ >>> >>> Otherwise, WFM. >>> >>> >>> >>> On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal < >>> muthu.arul@gmail.com> wrote: >>> >>> s/test/text.. >>> >>> On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozhi Perumal < >>> muthu.arul@gmail.com> wrote: >>> >>>> On Fri, Jun 19, 2015 at 2:58 AM, Christer Holmberg < >>>> christer.holmberg@ericsson.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>> Then, if the sender later wants to start sending media on the >>>>> >>> candidate pair again, it simply start sending consent requests >>>>> again. >>>>> >> >>>>> >> From a security perspective, this would be OK. Functionally >>>>> however, >>>>> >> do you really expect that to work? NATs and relays tend to garbag= e >>>>> >> collect pretty aggressively. >>>>> > >>>>> > It might not work if no keepalives are sent. But Christer's point i= s >>>>> that consent is not required since no media is being sent. >>>>> >>>>> Correct. >>>>> >>>>> >>>>> >>> However, the way I read the draft now is that it would require an >>>>> ICE >>>>> >>> restart, and I don=E2=80=99t think we want that? >>>>> >> >>>>> >> Why the question? You are the one who has to decide if you want >>>>> that. >>>>> > >>>>> > I think Christer's point is that this should not be considered a >>>>> loss of consent. >>>>> >>>>> Correct. >>>>> >>>>> Loss of consent is defined as not receiving a response to a sent >>>>> consent request - but in this case there is not consent request sent = to >>>>> begin with :) >>>>> >>>>> > The draft already says that consent is not needed on a pair if no >>>>> media is being sent. So one might >>>>> > interpret the existing draft as not imposing an ICE restart >>>>> requirement in that case (how can consent expire if consent is not >>>>> required??) >>>>> >>>>> Correct. >>>>> >>>>> I think all that is needed is a clarification statement saying that >>>>> stop sending to consent requests shall not be considered loss of cons= ent, >>>>> and that a sender can later request consent on the same candidate pai= r >>>>> again - without having to do an ICE restart. >>>>> >>>> >>>> >>>> =E2=80=8BExisting test: >>>> An endpoint that is not sending any application data does not need = to >>>> maintain consent. However, not sending any traffic could cause NAT >>>> or firewall mappings to expire. Furthermore, having one peer unabl= e >>>> to send is detrimental to many protocols. Absent better informatio= n >>>> about the network, if an endpoint needs to ensure its NAT or firewa= ll >>>> mappings do not expire, it can be done using keepalive or other >>>> techniques (see Section 10 of [RFC5245] and see [RFC6263]). >>>> >>>> New test: >>>> An endpoint that is not sending any application data after obtainin= g >>>> consent does not need to maintain consent. As soon as the endpoint >>>> starts sending application again, consent is maintained following >>>> the >>>> procedure described in this document. >>>> >>>> However, not sending any traffic could cause NAT or firewall >>>> mappings >>>> to expire. Furthermore, having one peer unable to send is >>>> detrimental >>>> to many protocols. Absent better information about the network, if >>>> an >>>> endpoint needs to ensure its NAT or firewall mappings do not expire= , >>>> it can be done using keepalive or other techniques (see Section 10 >>>> of >>>> [RFC5245] and see [RFC6263]). >>>> >>>> Does it work? >>>> >>>> thanks, >>>> Muthu >>>> >>>> >>>>> >>>>> ICE restart is only required when a sender has requested consent, but >>>>> has not got it (i.e. there was no response to the consent freshness >>>>> request). >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> >>>> >>> >> > --089e0116000217f12b0518dbe7c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about the following text?

= =C2=A0 =C2=A0An endpoint that is not sending any application data after obt= aining=C2=A0
=C2=A0 =C2=A0consent does no= t need to maintain consent. The endpoint can resume sending=C2=A0
=C2=A0 =C2=A0application data using the consent ob= tained earlier (hence, does not need
=C2= =A0 =C2=A0to perform ICE restart). As soon as the endpoint resumes sending = application=C2=A0
=C2=A0 =C2=A0data, cons= ent is maintained following the procedure described in this=C2=A0
=C2=A0 =C2=A0document.

thanks,
Muthu

On Fri, Jun 19, 2015 at 2:25 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

Sure, there may be a need to perform ICE restart for some other reasons, an= d my suggested text does not forbid it. But, I request a statement saying t= hat an ICE restart is not required simply because you want to start sending= data again.

Perhaps:

"In this case an ICE restart is not required, as is the case when the = sender fails to get consent."

>From experience I am pretty sure that, if we don't have explicit text, = we will soon have do-I-need-to-do-ICE-restart mails on the list :)

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Peruma= l
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 09:01
To: Christer Holm= berg
Cc: Bernard Aboba; Martin Thomso= n; rtcweb@ietf.org

Subject: Re: [r= tcweb] Comment on consent-freshness-14

I think an ICE-restart can still be performed for a bunch of other reasons.= Here is my take:

New text:
=E2=80=8B=E2=80=8B
=C2=A0 =C2= =A0An endpoint that is not sending any application data after obtaining=C2= =A0
=C2=A0 =C2=A0consent does not need to maintain consent. The endpoint c= an resume sending=C2=A0
=C2=A0 =C2=A0application data using the consent obtained earlier. As s= oon as the endpoint=C2=A0
=C2=A0 =C2=A0resumes sending application data, consent is maintained f= ollowing the=C2=A0
=C2=A0 =C2=A0procedure described in this document.

Would that work?

thanks,
Muthu

On Fri, Jun 19, 2015 at 11:05 AM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

The text otherwise looks good, but I suggest adding the following after the= "As soon as..." statement: "In this case the endpoint does = not need to perform ICE restart."

Thanks!

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Peruma= l
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 06:18
To: Bernard Aboba
Cc: Christer Holm= berg; Martin Thomso= n; rtcweb@ietf.org
Subject: Re: [r= tcweb] Comment on consent-freshness-14

Thank= s. It was missed in a haste :)

Muthu=

On Fri, Jun 19, 2015 at 8:44 AM, Bernard Aboba <= span dir=3D"ltr"> <bernard.ab= oba@gmail.com> wrote:
s/sending application/sending application data/

Otherwise, WFM.



On Jun 18, 2015, at 9:08 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote= :

s/tes= t/text..

On Fri, Jun 19, 2015 at 6:37 AM, Muthu Arul Mozh= i Perumal <muthu.arul@gmail.com> wrote:
On Fri, Jun 19, 2015 at 2:58 AM, Ch= rister Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

>>> Then, if the sender later wants to start sending media on the<= br> >>> candidate pair again, it simply start sending consent requests= again.
>>
>> From a security perspective, this would be OK.=C2=A0 Functionally = however,
>> do you really expect that to work?=C2=A0 NATs and relays tend to g= arbage
>> collect pretty aggressively.
>
> It might not work if no keepalives are sent. But Christer's point = is that consent is not required since no media is being sent.

Correct.


>>> However, the way I read the draft now is that it would require= an ICE
>>> restart, and I don=E2=80=99t think we want that?
>>
>> Why the question?=C2=A0 You are the one who has to decide if you w= ant that.
>
> I think Christer's point is that this should not be considered a l= oss of consent.

Correct.

Loss of consent is defined as not receiving a response to a sent consent re= quest - but in this case there is not consent request sent to begin with :)=

> The draft already says that consent is not needed on a pair if no medi= a is being sent. So one might
> interpret the existing draft as not imposing an ICE restart requiremen= t in that case (how can consent expire if consent is not required??)

Correct.

I think all that is needed is a clarification statement saying that stop se= nding to consent requests shall not be considered loss of consent, and that= a sender can later request consent on the same candidate pair again - with= out having to do an ICE restart.
=E2=80=8BExisting test:= =C2=A0
=C2=A0 =C2=A0An endpoint t= hat is not sending any application data does not need to
=C2=A0 =C2=A0maintain cons= ent.=C2=A0 However, not sending any traffic could cause NAT
=C2=A0 =C2=A0or firewall m= appings to expire.=C2=A0 Furthermore, having one peer unable
=C2=A0 =C2=A0to send is de= trimental to many protocols.=C2=A0 Absent better information
=C2=A0 =C2=A0about the net= work, if an endpoint needs to ensure its NAT or firewall
=C2=A0 =C2=A0mappings do n= ot expire, it can be done using keepalive or other
=C2=A0 =C2=A0techniques (s= ee Section 10 of [RFC5245] and see [RFC6263]).

New test:
=C2=A0 =C2=A0An endpoint t= hat is not sending any application data after obtaining=C2=A0
=C2=A0 =C2=A0consent does = not need to maintain consent. As soon as the endpoint
=C2=A0 =C2=A0starts sendin= g application again, consent is maintained following the=C2=A0
=C2=A0 =C2=A0procedure des= cribed in this document.

=C2=A0 =C2=A0However, not = sending any traffic could cause NAT or firewall mappings=C2=A0
=C2=A0 =C2=A0to expire. Fu= rthermore, having one peer unable to send is detrimental=C2=A0
=C2=A0 =C2=A0to many proto= cols.=C2=A0 Absent better information about the network, if an=C2=A0=
=C2=A0 =C2=A0endpoint need= s to ensure its NAT or firewall mappings do not expire,=C2=A0
=C2=A0 =C2=A0it can be don= e using keepalive or other techniques (see Section 10 of=C2=A0
=C2=A0 =C2=A0[RFC5245] and= see [RFC6263]).

Does = it work?

thank= s,
Muthu=
=C2=A0

ICE restart is only required when a sender has requested consent, but has n= ot got it (i.e. there was no response to the consent freshness request).
Regards,

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





--089e0116000217f12b0518dbe7c9-- From nobody Fri Jun 19 03:46:16 2015 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 951E11A8924 for ; Fri, 19 Jun 2015 03:46:15 -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 7XpQUm9S3k4x for ; Fri, 19 Jun 2015 03:46:12 -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 6F1A51A891F for ; Fri, 19 Jun 2015 03:46:11 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-29-5583f2f1aa1f Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4B.C9.04401.1F2F3855; Fri, 19 Jun 2015 12:46:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 12:46:08 +0200 From: Christer Holmberg To: Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAAUgJ0///uz4AABgNmtA== Date: Fri, 19 Jun 2015 10:46:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F30A7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2F9B@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F30A7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvre7HT82hBs2z9C027PvPbHHtzD9G iz+b/SzW/mtnd2Dx2DnrLrvHkiU/mQKYorhsUlJzMstSi/TtErgy7l2cz1bwoZGpYvfSBcwN jD2/GbsYOTkkBEwk+ievYIGwxSQu3FvP1sXIxSEkcJRR4sikD2wgCSGBxYwSv4+YdDFycLAJ WEh0/9MGCYsIGEtsafnFCmIzC9RKtJ2CsIUFTCXWXJ7DDFFjJtF6diYrhF0ncWPdXbBdLAKq Emfuv2UEGckr4CuxchsrxKblbBKvd6eA2JwCgRIbv+0CK2cEOu37qTVMEKvEJZq+rGSFOFlA Ysme88wQtqjEy8f/WEFGMgvkSzS+1wAJ8woISpyc+YRlAqPILCTdsxCqZiGpgghrSqzfpQ9R rSgxpfshO4StIdE6Zy47svgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIExdnDLb9Ud jJffOB5iFOBgVOLhVVBrChViTSwrrsw9xCjNwaIkzjtjc16okEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBkajH/O9VxTu4FVhLnL5FKisz6+pznI9h4+DY0PGp22ndt5X5Mg2b1oV4ugVx/w5 YV0eh9uvVfuLr8js+NVwNndt8c62Pc/fh849EZncoL5O1nd3+Lvp8384uogotIT9WHNJcPWW oigu5l8u7TtncF5ZrsWVWWfYlye7JfIjt3L/boPXWjFfWpVYijMSDbWYi4oTASNh5oCSAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 10:46:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F30A7ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3Mgb2suIFRoYW5rcyENCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15 IFdpbmRvd3MgUGhvbmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBN dXRodSBBcnVsIE1vemhpIFBlcnVtYWw8bWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tPg0KU2Vu dDog4oCOMTkv4oCOMDYv4oCOMjAxNSAxMjo1Mw0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogQmVybmFyZCBBYm9iYTxtYWls dG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+OyBNYXJ0aW4gVGhvbXNvbjxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQ29tbWVudCBvbiBjb25zZW50LWZyZXNobmVzcy0x NA0KDQpIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Pw0KDQogICBBbiBlbmRwb2ludCB0aGF0 IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGFmdGVyIG9idGFpbmluZw0KICAg Y29uc2VudCBkb2VzIG5vdCBuZWVkIHRvIG1haW50YWluIGNvbnNlbnQuIFRoZSBlbmRwb2ludCBj YW4gcmVzdW1lIHNlbmRpbmcNCiAgIGFwcGxpY2F0aW9uIGRhdGEgdXNpbmcgdGhlIGNvbnNlbnQg b2J0YWluZWQgZWFybGllciAoaGVuY2UsIGRvZXMgbm90IG5lZWQNCiAgIHRvIHBlcmZvcm0gSUNF IHJlc3RhcnQpLiBBcyBzb29uIGFzIHRoZSBlbmRwb2ludCByZXN1bWVzIHNlbmRpbmcgYXBwbGlj YXRpb24NCiAgIGRhdGEsIGNvbnNlbnQgaXMgbWFpbnRhaW5lZCBmb2xsb3dpbmcgdGhlIHByb2Nl ZHVyZSBkZXNjcmliZWQgaW4gdGhpcw0KICAgZG9jdW1lbnQuDQoNCnRoYW5rcywNCk11dGh1DQoN Ck9uIEZyaSwgSnVuIDE5LCAyMDE1IGF0IDI6MjUgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4+IHdyb3RlOg0KSGksDQoNClN1cmUsIHRoZXJlIG1heSBiZSBhIG5lZWQgdG8gcGVy Zm9ybSBJQ0UgcmVzdGFydCBmb3Igc29tZSBvdGhlciByZWFzb25zLCBhbmQgbXkgc3VnZ2VzdGVk IHRleHQgZG9lcyBub3QgZm9yYmlkIGl0LiBCdXQsIEkgcmVxdWVzdCBhIHN0YXRlbWVudCBzYXlp bmcgdGhhdCBhbiBJQ0UgcmVzdGFydCBpcyBub3QgcmVxdWlyZWQgc2ltcGx5IGJlY2F1c2UgeW91 IHdhbnQgdG8gc3RhcnQgc2VuZGluZyBkYXRhIGFnYWluLg0KDQpQZXJoYXBzOg0KDQoiSW4gdGhp cyBjYXNlIGFuIElDRSByZXN0YXJ0IGlzIG5vdCByZXF1aXJlZCwgYXMgaXMgdGhlIGNhc2Ugd2hl biB0aGUgc2VuZGVyIGZhaWxzIHRvIGdldCBjb25zZW50LiINCg0KRnJvbSBleHBlcmllbmNlIEkg YW0gcHJldHR5IHN1cmUgdGhhdCwgaWYgd2UgZG9uJ3QgaGF2ZSBleHBsaWNpdCB0ZXh0LCB3ZSB3 aWxsIHNvb24gaGF2ZSBkby1JLW5lZWQtdG8tZG8tSUNFLXJlc3RhcnQgbWFpbHMgb24gdGhlIGxp c3QgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBNdXRodSBBcnVsIE1v emhpIFBlcnVtYWw8bWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tPg0KU2VudDog4oCOMTkv4oCO MDYv4oCOMjAxNSAwOTowMQ0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogQmVybmFyZCBBYm9iYTxtYWlsdG86YmVybmFyZC5h Ym9iYUBnbWFpbC5jb20+OyBNYXJ0aW4gVGhvbXNvbjxtYWlsdG86bWFydGluLnRob21zb25AZ21h aWwuY29tPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQoNClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0DQoNCkkgdGhp bmsgYW4gSUNFLXJlc3RhcnQgY2FuIHN0aWxsIGJlIHBlcmZvcm1lZCBmb3IgYSBidW5jaCBvZiBv dGhlciByZWFzb25zLiBIZXJlIGlzIG15IHRha2U6DQoNCk5ldyB0ZXh0Og0K4oCL4oCLDQogICBB biBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGFmdGVy IG9idGFpbmluZw0KICAgY29uc2VudCBkb2VzIG5vdCBuZWVkIHRvIG1haW50YWluIGNvbnNlbnQu IFRoZSBlbmRwb2ludCBjYW4gcmVzdW1lIHNlbmRpbmcNCiAgIGFwcGxpY2F0aW9uIGRhdGEgdXNp bmcgdGhlIGNvbnNlbnQgb2J0YWluZWQgZWFybGllci4gQXMgc29vbiBhcyB0aGUgZW5kcG9pbnQN CiAgIHJlc3VtZXMgc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhLCBjb25zZW50IGlzIG1haW50YWlu ZWQgZm9sbG93aW5nIHRoZQ0KICAgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50 Lg0KDQpXb3VsZCB0aGF0IHdvcms/DQoNCnRoYW5rcywNCk11dGh1DQoNCk9uIEZyaSwgSnVuIDE5 LCAyMDE1IGF0IDExOjA1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90 ZToNCkhpLA0KDQpUaGUgdGV4dCBvdGhlcndpc2UgbG9va3MgZ29vZCwgYnV0IEkgc3VnZ2VzdCBh ZGRpbmcgdGhlIGZvbGxvd2luZyBhZnRlciB0aGUgIkFzIHNvb24gYXMuLi4iIHN0YXRlbWVudDog IkluIHRoaXMgY2FzZSB0aGUgZW5kcG9pbnQgZG9lcyBub3QgbmVlZCB0byBwZXJmb3JtIElDRSBy ZXN0YXJ0LiINCg0KVGhhbmtzIQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZyb20g bXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206 IE11dGh1IEFydWwgTW96aGkgUGVydW1hbDxtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20+DQpT ZW50OiDigI4xOS/igI4wNi/igI4yMDE1IDA2OjE4DQpUbzogQmVybmFyZCBBYm9iYTxtYWlsdG86 YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IE1hcnRpbiBUaG9tc29uPG1haWx0bzptYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNz LTE0DQoNClRoYW5rcy4gSXQgd2FzIG1pc3NlZCBpbiBhIGhhc3RlIDopDQoNCk11dGh1DQoNCk9u IEZyaSwgSnVuIDE5LCAyMDE1IGF0IDg6NDQgQU0sIEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJv YmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+IHdyb3RlOg0Kcy9z ZW5kaW5nIGFwcGxpY2F0aW9uL3NlbmRpbmcgYXBwbGljYXRpb24gZGF0YS8NCg0KT3RoZXJ3aXNl LCBXRk0uDQoNCg0KDQpPbiBKdW4gMTgsIDIwMTUsIGF0IDk6MDggUE0sIE11dGh1IEFydWwgTW96 aGkgUGVydW1hbCA8bXV0aHUuYXJ1bEBnbWFpbC5jb208bWFpbHRvOm11dGh1LmFydWxAZ21haWwu Y29tPj4gd3JvdGU6DQoNCnMvdGVzdC90ZXh0Li4NCg0KT24gRnJpLCBKdW4gMTksIDIwMTUgYXQg NjozNyBBTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIDxtdXRodS5hcnVsQGdtYWlsLmNvbTxt YWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20+PiB3cm90ZToNCk9uIEZyaSwgSnVuIDE5LCAyMDE1 IGF0IDI6NTggQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGks DQoNCj4+PiBUaGVuLCBpZiB0aGUgc2VuZGVyIGxhdGVyIHdhbnRzIHRvIHN0YXJ0IHNlbmRpbmcg bWVkaWEgb24gdGhlDQo+Pj4gY2FuZGlkYXRlIHBhaXIgYWdhaW4sIGl0IHNpbXBseSBzdGFydCBz ZW5kaW5nIGNvbnNlbnQgcmVxdWVzdHMgYWdhaW4uDQo+Pg0KPj4gRnJvbSBhIHNlY3VyaXR5IHBl cnNwZWN0aXZlLCB0aGlzIHdvdWxkIGJlIE9LLiAgRnVuY3Rpb25hbGx5IGhvd2V2ZXIsDQo+PiBk byB5b3UgcmVhbGx5IGV4cGVjdCB0aGF0IHRvIHdvcms/ICBOQVRzIGFuZCByZWxheXMgdGVuZCB0 byBnYXJiYWdlDQo+PiBjb2xsZWN0IHByZXR0eSBhZ2dyZXNzaXZlbHkuDQo+DQo+IEl0IG1pZ2h0 IG5vdCB3b3JrIGlmIG5vIGtlZXBhbGl2ZXMgYXJlIHNlbnQuIEJ1dCBDaHJpc3RlcidzIHBvaW50 IGlzIHRoYXQgY29uc2VudCBpcyBub3QgcmVxdWlyZWQgc2luY2Ugbm8gbWVkaWEgaXMgYmVpbmcg c2VudC4NCg0KQ29ycmVjdC4NCg0KDQo+Pj4gSG93ZXZlciwgdGhlIHdheSBJIHJlYWQgdGhlIGRy YWZ0IG5vdyBpcyB0aGF0IGl0IHdvdWxkIHJlcXVpcmUgYW4gSUNFDQo+Pj4gcmVzdGFydCwgYW5k IEkgZG9u4oCZdCB0aGluayB3ZSB3YW50IHRoYXQ/DQo+Pg0KPj4gV2h5IHRoZSBxdWVzdGlvbj8g IFlvdSBhcmUgdGhlIG9uZSB3aG8gaGFzIHRvIGRlY2lkZSBpZiB5b3Ugd2FudCB0aGF0Lg0KPg0K PiBJIHRoaW5rIENocmlzdGVyJ3MgcG9pbnQgaXMgdGhhdCB0aGlzIHNob3VsZCBub3QgYmUgY29u c2lkZXJlZCBhIGxvc3Mgb2YgY29uc2VudC4NCg0KQ29ycmVjdC4NCg0KTG9zcyBvZiBjb25zZW50 IGlzIGRlZmluZWQgYXMgbm90IHJlY2VpdmluZyBhIHJlc3BvbnNlIHRvIGEgc2VudCBjb25zZW50 IHJlcXVlc3QgLSBidXQgaW4gdGhpcyBjYXNlIHRoZXJlIGlzIG5vdCBjb25zZW50IHJlcXVlc3Qg c2VudCB0byBiZWdpbiB3aXRoIDopDQoNCj4gVGhlIGRyYWZ0IGFscmVhZHkgc2F5cyB0aGF0IGNv bnNlbnQgaXMgbm90IG5lZWRlZCBvbiBhIHBhaXIgaWYgbm8gbWVkaWEgaXMgYmVpbmcgc2VudC4g U28gb25lIG1pZ2h0DQo+IGludGVycHJldCB0aGUgZXhpc3RpbmcgZHJhZnQgYXMgbm90IGltcG9z aW5nIGFuIElDRSByZXN0YXJ0IHJlcXVpcmVtZW50IGluIHRoYXQgY2FzZSAoaG93IGNhbiBjb25z ZW50IGV4cGlyZSBpZiBjb25zZW50IGlzIG5vdCByZXF1aXJlZD8/KQ0KDQpDb3JyZWN0Lg0KDQpJ IHRoaW5rIGFsbCB0aGF0IGlzIG5lZWRlZCBpcyBhIGNsYXJpZmljYXRpb24gc3RhdGVtZW50IHNh eWluZyB0aGF0IHN0b3Agc2VuZGluZyB0byBjb25zZW50IHJlcXVlc3RzIHNoYWxsIG5vdCBiZSBj b25zaWRlcmVkIGxvc3Mgb2YgY29uc2VudCwgYW5kIHRoYXQgYSBzZW5kZXIgY2FuIGxhdGVyIHJl cXVlc3QgY29uc2VudCBvbiB0aGUgc2FtZSBjYW5kaWRhdGUgcGFpciBhZ2FpbiAtIHdpdGhvdXQg aGF2aW5nIHRvIGRvIGFuIElDRSByZXN0YXJ0Lg0KDQoNCuKAi0V4aXN0aW5nIHRlc3Q6DQogICBB biBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMg bm90IG5lZWQgdG8NCiAgIG1haW50YWluIGNvbnNlbnQuICBIb3dldmVyLCBub3Qgc2VuZGluZyBh bnkgdHJhZmZpYyBjb3VsZCBjYXVzZSBOQVQNCiAgIG9yIGZpcmV3YWxsIG1hcHBpbmdzIHRvIGV4 cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lIHBlZXIgdW5hYmxlDQogICB0byBzZW5kIGlz IGRldHJpbWVudGFsIHRvIG1hbnkgcHJvdG9jb2xzLiAgQWJzZW50IGJldHRlciBpbmZvcm1hdGlv bg0KICAgYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBp dHMgTkFUIG9yIGZpcmV3YWxsDQogICBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUg ZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXINCiAgIHRlY2huaXF1ZXMgKHNlZSBTZWN0aW9u IDEwIG9mIFtSRkM1MjQ1XSBhbmQgc2VlIFtSRkM2MjYzXSkuDQoNCk5ldyB0ZXN0Og0KICAgQW4g ZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBhZnRlciBv YnRhaW5pbmcNCiAgIGNvbnNlbnQgZG9lcyBub3QgbmVlZCB0byBtYWludGFpbiBjb25zZW50LiBB cyBzb29uIGFzIHRoZSBlbmRwb2ludA0KICAgc3RhcnRzIHNlbmRpbmcgYXBwbGljYXRpb24gYWdh aW4sIGNvbnNlbnQgaXMgbWFpbnRhaW5lZCBmb2xsb3dpbmcgdGhlDQogICBwcm9jZWR1cmUgZGVz Y3JpYmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIEhvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0 cmFmZmljIGNvdWxkIGNhdXNlIE5BVCBvciBmaXJld2FsbCBtYXBwaW5ncw0KICAgdG8gZXhwaXJl LiBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJsZSB0byBzZW5kIGlzIGRldHJpbWVu dGFsDQogICB0byBtYW55IHByb3RvY29scy4gIEFic2VudCBiZXR0ZXIgaW5mb3JtYXRpb24gYWJv dXQgdGhlIG5ldHdvcmssIGlmIGFuDQogICBlbmRwb2ludCBuZWVkcyB0byBlbnN1cmUgaXRzIE5B VCBvciBmaXJld2FsbCBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLA0KICAgaXQgY2FuIGJlIGRvbmUg dXNpbmcga2VlcGFsaXZlIG9yIG90aGVyIHRlY2huaXF1ZXMgKHNlZSBTZWN0aW9uIDEwIG9mDQog ICBbUkZDNTI0NV0gYW5kIHNlZSBbUkZDNjI2M10pLg0KDQpEb2VzIGl0IHdvcms/DQoNCnRoYW5r cywNCk11dGh1DQoNCg0KSUNFIHJlc3RhcnQgaXMgb25seSByZXF1aXJlZCB3aGVuIGEgc2VuZGVy IGhhcyByZXF1ZXN0ZWQgY29uc2VudCwgYnV0IGhhcyBub3QgZ290IGl0IChpLmUuIHRoZXJlIHdh cyBubyByZXNwb25zZSB0byB0aGUgY29uc2VudCBmcmVzaG5lc3MgcmVxdWVzdCkuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KDQoNCg0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D8F30A7ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPkxv b2tzIG9rLiBUaGFua3MhPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxi cj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lPC9kaXY+DQo8L2Rpdj4NCjxkaXYg ZGlyPSJsdHIiPg0KPGhyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkZyb206DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQi PjxhIGhyZWY9Im1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbSI+TXV0aHUgQXJ1bCBNb3poaSBQ ZXJ1bWFsPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxz YW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTFwdCI+4oCOMTkv4oCOMDYv4oCOMjAxNSAxMjo1Mzwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWln aHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iPkNocmlzdGVyIEhvbG1iZXJnPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9u dC13ZWlnaHQ6Ym9sZCI+Q2M6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFi b2JhQGdtYWlsLmNvbSI+QmVybmFyZCBBYm9iYTwvYT47DQo8YSBocmVmPSJtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tIj5NYXJ0aW4gVGhvbXNvbjwvYT47IDxhIGhyZWY9Im1haWx0bzpy dGN3ZWJAaWV0Zi5vcmciPg0KcnRjd2ViQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+UmU6IFtydGN3ZWJdIENvbW1lbnQg b24gY29uc2VudC1mcmVzaG5lc3MtMTQ8L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpIb3cg YWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0PzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVs dCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNp emU6c21hbGwiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFs bCI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7QW4gZW5kcG9pbnQg dGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBhZnRlciBvYnRhaW5pbmcm bmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiPiZuYnNwOyAmbmJzcDtjb25z ZW50IGRvZXMgbm90IG5lZWQgdG8gbWFpbnRhaW4gY29uc2VudC4gVGhlIGVuZHBvaW50IGNhbiBy ZXN1bWUgc2VuZGluZyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCI+Jm5i c3A7ICZuYnNwO2FwcGxpY2F0aW9uIGRhdGEgdXNpbmcgdGhlIGNvbnNlbnQgb2J0YWluZWQgZWFy bGllciAoaGVuY2UsIGRvZXMgbm90IG5lZWQ8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiPiZuYnNwOyAmbmJzcDt0byBwZXJmb3JtIElDRSByZXN0YXJ0KS4gQXMgc29vbiBhcyB0aGUg ZW5kcG9pbnQgcmVzdW1lcyBzZW5kaW5nIGFwcGxpY2F0aW9uJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSJnbWFpbF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7ZGF0YSwgY29uc2VudCBpcyBtYWludGFp bmVkIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiB0aGlzJm5ic3A7PC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0Ij4mbmJzcDsgJm5ic3A7ZG9jdW1lbnQuPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiPnRoYW5rcyw8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1 bHQiPk11dGh1PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gRnJpLCBKdW4gMTksIDIwMTUgYXQgMjoyNSBQTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4OyBi b3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7 IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTFwdCI+SGksPGJyPg0KPGJyPg0KU3VyZSwgdGhlcmUgbWF5IGJlIGEgbmVlZCB0byBwZXJmb3Jt IElDRSByZXN0YXJ0IGZvciBzb21lIG90aGVyIHJlYXNvbnMsIGFuZCBteSBzdWdnZXN0ZWQgdGV4 dCBkb2VzIG5vdCBmb3JiaWQgaXQuIEJ1dCwgSSByZXF1ZXN0IGEgc3RhdGVtZW50IHNheWluZyB0 aGF0IGFuIElDRSByZXN0YXJ0IGlzIG5vdCByZXF1aXJlZCBzaW1wbHkgYmVjYXVzZSB5b3Ugd2Fu dCB0byBzdGFydCBzZW5kaW5nIGRhdGEgYWdhaW4uPGJyPg0KPGJyPg0KUGVyaGFwczo8YnI+DQo8 YnI+DQomcXVvdDtJbiB0aGlzIGNhc2UgYW4gSUNFIHJlc3RhcnQgaXMgbm90IHJlcXVpcmVkLCBh cyBpcyB0aGUgY2FzZSB3aGVuIHRoZSBzZW5kZXIgZmFpbHMgdG8gZ2V0IGNvbnNlbnQuJnF1b3Q7 PGJyPg0KPGJyPg0KRnJvbSBleHBlcmllbmNlIEkgYW0gcHJldHR5IHN1cmUgdGhhdCwgaWYgd2Ug ZG9uJ3QgaGF2ZSBleHBsaWNpdCB0ZXh0LCB3ZSB3aWxsIHNvb24gaGF2ZSBkby1JLW5lZWQtdG8t ZG8tSUNFLXJlc3RhcnQgbWFpbHMgb24gdGhlIGxpc3QgOik8c3BhbiBjbGFzcz0iIj48YnI+DQo8 YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15 IFdpbmRvd3MgUGhvbmU8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxzcGFu IGNsYXNzPSIiPg0KPGhyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1z ZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkZyb206DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQi PjxhIGhyZWY9Im1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk11 dGh1IEFydWwgTW96aGkgUGVydW1hbDwvYT48L3NwYW4+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdl aWdodDpib2xkIj5TZW50Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij7igI4xOS/igI4wNi/igI4yMDE1IDA5OjAxPC9z cGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5UbzoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNo cmlzdGVyIEhvbG1iZXJnPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9u dC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPkJlcm5hcmQgQWJvYmE8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1hcnRpbiBUaG9tc29uPC9hPjsgPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KcnRjd2ViQGll dGYub3JnPC9hPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQt d2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPlJlOiBbcnRjd2ViXSBDb21tZW50IG9u IGNvbnNlbnQtZnJlc2huZXNzLTE0PC9zcGFuPjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOnNtYWxsIj5JIHRoaW5rIGFuIElDRS1yZXN0YXJ0IGNhbiBzdGlsbCBiZSBwZXJmb3JtZWQg Zm9yIGEgYnVuY2ggb2Ygb3RoZXIgcmVhc29ucy4gSGVyZSBpcyBteSB0YWtlOjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTpzbWFsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2 ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj5OZXcgdGV4dDo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 c21hbGwiPg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsOyBkaXNwbGF5 OmlubGluZSI+DQrigIvigIs8L2Rpdj4NCiZuYnNwOyAmbmJzcDtBbiBlbmRwb2ludCB0aGF0IGlz IG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGFmdGVyIG9idGFpbmluZyZuYnNwOzwv ZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7Y29uc2VudCBkb2VzIG5vdCBuZWVkIHRvIG1haW50YWlu IGNvbnNlbnQuIFRoZSBlbmRwb2ludCBjYW4gcmVzdW1lIHNlbmRpbmcmbmJzcDs8L2Rpdj4NCjxk aXY+Jm5ic3A7ICZuYnNwO2FwcGxpY2F0aW9uIGRhdGEgdXNpbmcgdGhlIGNvbnNlbnQgb2J0YWlu ZWQgZWFybGllci4gQXMgc29vbiBhcyB0aGUgZW5kcG9pbnQmbmJzcDs8L2Rpdj4NCjxkaXY+Jm5i c3A7ICZuYnNwO3Jlc3VtZXMgc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhLCBjb25zZW50IGlzIG1h aW50YWluZWQgZm9sbG93aW5nIHRoZSZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7cHJv Y2VkdXJlIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+V291bGQgdGhhdCB3b3JrPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ dGhhbmtzLDwvZGl2Pg0KPGRpdj5NdXRodTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgSnVuIDE5LCAy MDE1IGF0IDExOjA1IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8c3BhbiBkaXI9Imx0ciI+DQombHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90 ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4 IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtY29sb3I6 cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDox ZXgiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij5IaSw8YnI+DQo8YnI+DQpUaGUgdGV4dCBvdGhlcndpc2Ug bG9va3MgZ29vZCwgYnV0IEkgc3VnZ2VzdCBhZGRpbmcgdGhlIGZvbGxvd2luZyBhZnRlciB0aGUg JnF1b3Q7QXMgc29vbiBhcy4uLiZxdW90OyBzdGF0ZW1lbnQ6ICZxdW90O0luIHRoaXMgY2FzZSB0 aGUgZW5kcG9pbnQgZG9lcyBub3QgbmVlZCB0byBwZXJmb3JtIElDRSByZXN0YXJ0LiZxdW90Ozxi cj4NCjxicj4NClRoYW5rcyE8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVy PGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRp diBkaXI9Imx0ciI+DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFw dCI+PGEgaHJlZj0ibWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6 Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCOMTkv4oCOMDYv4oCOMjAxNSAwNjoxODwvc3Bhbj48 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNp emU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0 bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkJlcm5hcmQgQWJvYmE8 L2E+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5DYzoNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEg aHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkNocmlzdGVyIEhvbG1iZXJnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5NYXJ0aW4gVGhvbXNvbjwvYT47IDxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dlYkBpZXRmLm9y ZzwvYT48L3NwYW4+PHNwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQiPlJlOiBbcnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0PC9z cGFuPjxicj4NCjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg ZGlyPSJsdHIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+VGhhbmtzLiBJdCB3YXMgbWlzc2VkIGluIGEgaGFzdGUg Oik8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmOyBmb250LXNpemU6c21hbGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+TXV0aHU8L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+T24gRnJpLCBKdW4gMTksIDIwMTUgYXQgODo0NCBBTSwgQmVybmFyZCBBYm9iYSA8c3BhbiBk aXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv dGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDoxcHg7IGJvcmRlci1sZWZ0LWNvbG9y OnJnYigyMDQsMjA0LDIwNCk7IGJvcmRlci1sZWZ0LXN0eWxlOnNvbGlkOyBwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxkaXYgZGlyPSJhdXRvIj4NCjxkaXY+cy9zZW5kaW5nIGFwcGxpY2F0aW9uL3NlbmRp bmcgYXBwbGljYXRpb24gZGF0YS88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk90aGVy d2lzZSwgV0ZNLjxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pjxi cj4NCk9uIEp1biAxOCwgMjAxNSwgYXQgOTowOCBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFs ICZsdDs8YSBocmVmPSJtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tdXRodS5hcnVsQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNt YWxsIj5zL3Rlc3QvdGV4dC4uPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgSnVuIDE5LCAyMDE1IGF0IDY6MzcgQU0s IE11dGh1IEFydWwgTW96aGkgUGVydW1hbA0KPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt YWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tdXRodS5hcnVsQGdt YWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdp ZHRoOjFweDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQt c3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOnNtYWxsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsc2Fucy1zZXJpZiI+T24g RnJpLCBKdW4gMTksIDIwMTUgYXQgMjo1OCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcNCjwvc3Bhbj48 c3BhbiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWYiPiZsdDs8 YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9i bGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWYiPiB3cm90ZTo8L3NwYW4+PGJyPg0K PC9kaXY+DQo8L3NwYW4+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+PHNwYW4+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVy LWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBh ZGRpbmctbGVmdDoxZXgiPg0KSGksPGJyPg0KPHNwYW4+PGJyPg0KJmd0OyZndDsmZ3Q7IFRoZW4s IGlmIHRoZSBzZW5kZXIgbGF0ZXIgd2FudHMgdG8gc3RhcnQgc2VuZGluZyBtZWRpYSBvbiB0aGU8 YnI+DQomZ3Q7Jmd0OyZndDsgY2FuZGlkYXRlIHBhaXIgYWdhaW4sIGl0IHNpbXBseSBzdGFydCBz ZW5kaW5nIGNvbnNlbnQgcmVxdWVzdHMgYWdhaW4uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBGcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIHRoaXMgd291bGQgYmUgT0suJm5ic3A7IEZ1 bmN0aW9uYWxseSBob3dldmVyLDxicj4NCiZndDsmZ3Q7IGRvIHlvdSByZWFsbHkgZXhwZWN0IHRo YXQgdG8gd29yaz8mbmJzcDsgTkFUcyBhbmQgcmVsYXlzIHRlbmQgdG8gZ2FyYmFnZTxicj4NCiZn dDsmZ3Q7IGNvbGxlY3QgcHJldHR5IGFnZ3Jlc3NpdmVseS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ dCBtaWdodCBub3Qgd29yayBpZiBubyBrZWVwYWxpdmVzIGFyZSBzZW50LiBCdXQgQ2hyaXN0ZXIn cyBwb2ludCBpcyB0aGF0IGNvbnNlbnQgaXMgbm90IHJlcXVpcmVkIHNpbmNlIG5vIG1lZGlhIGlz IGJlaW5nIHNlbnQuPGJyPg0KPGJyPg0KPC9zcGFuPkNvcnJlY3QuPGJyPg0KPHNwYW4+PGJyPg0K PGJyPg0KJmd0OyZndDsmZ3Q7IEhvd2V2ZXIsIHRoZSB3YXkgSSByZWFkIHRoZSBkcmFmdCBub3cg aXMgdGhhdCBpdCB3b3VsZCByZXF1aXJlIGFuIElDRTxicj4NCiZndDsmZ3Q7Jmd0OyByZXN0YXJ0 LCBhbmQgSSBkb27igJl0IHRoaW5rIHdlIHdhbnQgdGhhdD88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IFdoeSB0aGUgcXVlc3Rpb24/Jm5ic3A7IFlvdSBhcmUgdGhlIG9uZSB3aG8gaGFzIHRv IGRlY2lkZSBpZiB5b3Ugd2FudCB0aGF0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgQ2hy aXN0ZXIncyBwb2ludCBpcyB0aGF0IHRoaXMgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGEgbG9z cyBvZiBjb25zZW50Ljxicj4NCjxicj4NCjwvc3Bhbj5Db3JyZWN0Ljxicj4NCjxicj4NCkxvc3Mg b2YgY29uc2VudCBpcyBkZWZpbmVkIGFzIG5vdCByZWNlaXZpbmcgYSByZXNwb25zZSB0byBhIHNl bnQgY29uc2VudCByZXF1ZXN0IC0gYnV0IGluIHRoaXMgY2FzZSB0aGVyZSBpcyBub3QgY29uc2Vu dCByZXF1ZXN0IHNlbnQgdG8gYmVnaW4gd2l0aCA6KTxicj4NCjxzcGFuPjxicj4NCiZndDsgVGhl IGRyYWZ0IGFscmVhZHkgc2F5cyB0aGF0IGNvbnNlbnQgaXMgbm90IG5lZWRlZCBvbiBhIHBhaXIg aWYgbm8gbWVkaWEgaXMgYmVpbmcgc2VudC4gU28gb25lIG1pZ2h0PGJyPg0KJmd0OyBpbnRlcnBy ZXQgdGhlIGV4aXN0aW5nIGRyYWZ0IGFzIG5vdCBpbXBvc2luZyBhbiBJQ0UgcmVzdGFydCByZXF1 aXJlbWVudCBpbiB0aGF0IGNhc2UgKGhvdyBjYW4gY29uc2VudCBleHBpcmUgaWYgY29uc2VudCBp cyBub3QgcmVxdWlyZWQ/Pyk8YnI+DQo8YnI+DQo8L3NwYW4+Q29ycmVjdC48YnI+DQo8YnI+DQpJ IHRoaW5rIGFsbCB0aGF0IGlzIG5lZWRlZCBpcyBhIGNsYXJpZmljYXRpb24gc3RhdGVtZW50IHNh eWluZyB0aGF0IHN0b3Agc2VuZGluZyB0byBjb25zZW50IHJlcXVlc3RzIHNoYWxsIG5vdCBiZSBj b25zaWRlcmVkIGxvc3Mgb2YgY29uc2VudCwgYW5kIHRoYXQgYSBzZW5kZXIgY2FuIGxhdGVyIHJl cXVlc3QgY29uc2VudCBvbiB0aGUgc2FtZSBjYW5kaWRhdGUgcGFpciBhZ2FpbiAtIHdpdGhvdXQg aGF2aW5nIHRvIGRvIGFuIElDRSByZXN0YXJ0Ljxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj4NCjxkaXY+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6 c21hbGwiPuKAizwvc3Bhbj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlm Ij5FeGlzdGluZyB0ZXN0OiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJp YWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0FuIGVuZHBvaW50IHRoYXQg aXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bzwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO21haW50YWluIGNvbnNlbnQuJm5ic3A7IEhvd2V2ZXIsIG5vdCBzZW5kaW5n IGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVDwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO29yIGZpcmV3YWxs IG1hcHBpbmdzIHRvIGV4cGlyZS4mbmJzcDsgRnVydGhlcm1vcmUsIGhhdmluZyBvbmUgcGVlciB1 bmFibGU8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt0byBzZW5kIGlzIGRldHJpbWVudGFsIHRvIG1hbnkgcHJv dG9jb2xzLiZuYnNwOyBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uPC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 YWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFU IG9yIGZpcmV3YWxsPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0 aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7bWFwcGluZ3MgZG8gbm90IGV4cGlyZSwgaXQg Y2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9yIG90aGVyPC9mb250PjwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7dGVj aG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2Vy aWYiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGlj YSwgc2Fucy1zZXJpZiI+TmV3IHRlc3Q6PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJh cmlhbCwgaGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QW4gZW5kcG9pbnQgdGhh dCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBhZnRlciBvYnRhaW5pbmcmbmJz cDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDtjb25zZW50IGRvZXMgbm90IG5lZWQgdG8gbWFpbnRhaW4gY29u c2VudC4gQXMgc29vbiBhcyB0aGUgZW5kcG9pbnQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtzdGFydHMgc2Vu ZGluZyBhcHBsaWNhdGlvbiBhZ2FpbiwgY29uc2VudCBpcyBtYWludGFpbmVkIGZvbGxvd2luZyB0 aGUmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2Es IHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtwcm9jZWR1cmUgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQuPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJhcmlhbCwgaGVsdmV0aWNhLCBz YW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBo ZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtIb3dldmVyLCBub3Qgc2VuZGluZyBh bnkgdHJhZmZpYyBjb3VsZCBjYXVzZSBOQVQgb3IgZmlyZXdhbGwgbWFwcGluZ3MmbmJzcDs8L2Zv bnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDt0byBleHBpcmUuIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lIHBlZXIgdW5h YmxlIHRvIHNlbmQgaXMgZGV0cmltZW50YWwmbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9ImFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt0byBtYW55 IHByb3RvY29scy4mbmJzcDsgQWJzZW50IGJldHRlciBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0 d29yaywgaWYgYW4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9ImFyaWFsLCBo ZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtlbmRwb2ludCBuZWVkcyB0byBlbnN1 cmUgaXRzIE5BVCBvciBmaXJld2FsbCBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLCZuYnNwOzwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+ Jm5ic3A7ICZuYnNwO2l0IGNhbiBiZSBkb25lIHVzaW5nIGtlZXBhbGl2ZSBvciBvdGhlciB0ZWNo bmlxdWVzIChzZWUgU2VjdGlvbiAxMCBvZiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1tSRkM1MjQ1 XSBhbmQgc2VlIFtSRkM2MjYzXSkuPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsg Zm9udC1zaXplOnNtYWxsIj5Eb2VzIGl0IHdvcms/PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm OyBmb250LXNpemU6c21hbGwiPnRoYW5rcyw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGwiPk11dGh1PC9kaXY+ DQo8L2Rpdj4NCjxzcGFuPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDsgYm9yZGVyLWxlZnQt d2lkdGg6MXB4OyBib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpOyBib3JkZXItbGVm dC1zdHlsZTpzb2xpZDsgcGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpJQ0UgcmVzdGFydCBpcyBv bmx5IHJlcXVpcmVkIHdoZW4gYSBzZW5kZXIgaGFzIHJlcXVlc3RlZCBjb25zZW50LCBidXQgaGFz IG5vdCBnb3QgaXQgKGkuZS4gdGhlcmUgd2FzIG5vIHJlc3BvbnNlIHRvIHRoZSBjb25zZW50IGZy ZXNobmVzcyByZXF1ZXN0KS48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVy PGJyPg0KPGRpdj4NCjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjwvc3Bhbj48L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D8F30A7ESESSMB209erics_-- From nobody Fri Jun 19 06:53:28 2015 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 558BA1A01A9 for ; Fri, 19 Jun 2015 06:53: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 T6NHIVfLx_W7 for ; Fri, 19 Jun 2015 06:53:25 -0700 (PDT) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAEF01A017E for ; Fri, 19 Jun 2015 06:53:24 -0700 (PDT) Received: by ykfr66 with SMTP id r66so92168595ykf.0 for ; Fri, 19 Jun 2015 06:53: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=FeU+Od9CzNXhn+f5xwzaJIed/UTHEgWVOaf+QCvqZyQ=; b=byBjarW63vbk3P01atynbwriXCMRRVnYDOsgGvUHwnNw3deVdXlJ2TaQhVrolMbKgY OKQMGZgiaTZFX2ruUI0/d2DjCiy8btXc+omeAypf/QInJYQDQrOWyptHKB+UhHs1J6P8 Iin9RAfuq7Cq92Dpnu7Z8F7UEPCg/IZ9s1HyUmk7xqB3ZR5yOO5qStDHRGqx1QnmPUkb n6HrhZe+Ct32YASEjpGRBA670Nb5H9ZsuUvMilj30DCelvhdS2BOSirMuU0V6vmcic6y 67lbCSfyWioJBeoXoRbWMr7Q6fvwcKfHt5Jb0Ur5OlSYl/Kqp38k37xeEaOO8qSfuBoZ FUYQ== X-Gm-Message-State: ALoCoQmiMMnXD/mO82wf+K+QCZNvP/SifiOSFOcgyGKN+91h/ihBlQBQLQDDZ4vwSLuA+hb/ly1f X-Received: by 10.129.111.65 with SMTP id k62mr20642051ywc.88.1434722004171; Fri, 19 Jun 2015 06:53:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.76.5 with HTTP; Fri, 19 Jun 2015 06:53:03 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F28B3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F28B3@ESESSMB209.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 19 Jun 2015 15:53:03 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 13:53:26 -0000 2015-06-18 21:21 GMT+02:00 Christer Holmberg : > I am not talking about putting someone on hold, in which case you wouldn'= t send media on any candidate pair. I am talking about not sending media on= candidate pairs X, Y and Z because you are sending media on candidate pair= W. Correct me if I'm wrong, but once a final/definitive ICE path is chosen and proven (so USE-CANCIDATE is used) there is no need at all to keep all the other bindings open. In fact it is useless since once a chosen path exists there is no way (according to current ICE spec) to move to another one even if such a chosen path suddenly fails (that requires indeed ICE restart, at least according to the current ICE RFC). --=20 I=C3=B1aki Baz Castillo From nobody Fri Jun 19 08:13:19 2015 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 E56611A8A84 for ; Fri, 19 Jun 2015 08:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 M0yTpFk2Lfxk for ; Fri, 19 Jun 2015 08:13:16 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC7EB1A8A7B for ; Fri, 19 Jun 2015 08:13:15 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-36-5584318a761a Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.4B.04015.A8134855; Fri, 19 Jun 2015 17:13:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 17:13:13 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgA///aitCAACx7gP//2LYAgAFnEYD//8vqkA== Date: Fri, 19 Jun 2015 15:13:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F3414@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F28B3@ESESSMB209.ericsson.se> 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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+JvrW6XYUuowavVYhbT99lYXDvzj9Fi 7b92dgdmj3MN79k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6MLZM3sRW08FRcOfifpYHx DncXIyeHhICJxL7nbewQtpjEhXvr2boYuTiEBI4ySnz6sZQZwlnMKNG8fSeQw8HBJmAh0f1P G6RBRMBG4t+FC2DNzAIhEg/PvmMGsYUFTCXWXJ7DDFFjJtF6diYrhB0m8eFaGxOIzSKgKjH9 9ytGEJtXwFdiXUMDE8SuVcwSey5vB2vmFAiU+HniDJjNCHTd91NrmCCWiUvcejKfCeJqAYkl e84zQ9iiEi8f/2OFsJUkGpc8YQW5mVlAU2L9Ln2IVkWJKd0P2SH2CkqcnPmEZQKj2CwkU2ch dMxC0jELSccCRpZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIHxdHDLb4MdjC+fOx5iFOBg VOLhTVBoCRViTSwrrsw9xCjNwaIkzjtjc16okEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkZt TSVXNRNdmcB/YueUThlb/mPbVrSi/m0vi1kRqxeX5o76aRW+Z3MYvuRwXArkn9zl+XnzN4Z2 kUVGvZk+O1wOr+Y+KFl3IW+iPd/D/VH7erdrTrawXPv2i4rVrbo1bWIG3j6TS755XPew1tnT vvvB3HDO+3s+Ki3+/d1542tBoXcif9aItyuxFGckGmoxFxUnAgAk2/h7iAIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 15:13:18 -0000 SGksDQoNCj4+IEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgcHV0dGluZyBzb21lb25lIG9uIGhvbGQs IGluIHdoaWNoIGNhc2UgeW91IHdvdWxkbid0IHNlbmQgbWVkaWEgb24gYW55IA0KPj4gY2FuZGlk YXRlIHBhaXIuIEkgYW0gdGFsa2luZyBhYm91dCBub3Qgc2VuZGluZyBtZWRpYSBvbiBjYW5kaWRh dGUgcGFpcnMgWCwgWSBhbmQgWiBiZWNhdXNlIHlvdSBhcmUgc2VuZGluZyBtZWRpYSBvbiBjYW5k aWRhdGUgcGFpciBXLg0KPg0KPiBDb3JyZWN0IG1lIGlmIEknbSB3cm9uZywgYnV0IG9uY2UgYSBm aW5hbC9kZWZpbml0aXZlIElDRSBwYXRoIGlzIGNob3NlbiBhbmQgcHJvdmVuIChzbyBVU0UtQ0FO Q0lEQVRFIGlzIHVzZWQpIHRoZXJlIGlzIG5vIG5lZWQgYXQgYWxsIHRvIGtlZXAgYWxsIA0KPiB0 aGUgb3RoZXIgYmluZGluZ3Mgb3Blbi4gSW4gZmFjdCBpdCBpcyB1c2VsZXNzIHNpbmNlIG9uY2Ug YSBjaG9zZW4gcGF0aCBleGlzdHMgdGhlcmUgaXMgbm8gd2F5IChhY2NvcmRpbmcgdG8gY3VycmVu dCBJQ0Ugc3BlYykgdG8gbW92ZSB0byBhbm90aGVyIG9uZSA+IGV2ZW4gaWYgc3VjaCBhIGNob3Nl biBwYXRoIHN1ZGRlbmx5IGZhaWxzICh0aGF0IHJlcXVpcmVzIGluZGVlZCBJQ0UgcmVzdGFydCwg YXQgbGVhc3QgYWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IElDRSBSRkMpLg0KDQpJbiByZWNlbnQg bW9vbnMgcGVvcGxlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0IG5ldmVyIGZpbmFsaXppbmcgSUNF LCBpbnN0ZWFkIHlvdSB3aWxsIGtlZXAgY29sbGVjdGluZyBjYW5kaWRhdGVzIHRocm91Z2hvdXQg dGhlIHNlc3Npb24sIGFuZCBzd2l0Y2ggYmV0d2VlbiB0aGVtIGlmIG9uZSBpcyAiYmV0dGVyIiB0 aGFuIHRoYXQgb3RoZXIuIFlvdSBtYXkgZHJvcCBzb21lIGNhbmRpZGF0ZXMsIGFuZCB5b3UgbWF5 IG1haW50YWluIG90aGVycyAoZXZlbnRob3VnaCB5b3UgYXJlIGN1cnJlbnRseSBub3Qgc2VuZGlu ZyBhbnkgZGF0YSBvbiB0aGVtKS4NCg0KVGhhdCBicmluZ3MgdXAgYSBxdWVzdGlvbiwgdGhvdWdo OiBpZiB5b3UgbmV2ZXIgZmluYWxpemUgSUNFLCB3aWxsIHlvdSBldmVyIGJlIGFibGUgdG8gZG8g YW4gSUNFIHJlc3RhcnQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From nobody Fri Jun 19 09:00:16 2015 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 2E3EE1A914D for ; Fri, 19 Jun 2015 09:00: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 tfM7Y1qqThMu for ; Fri, 19 Jun 2015 09:00:14 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44241A914B for ; Fri, 19 Jun 2015 09:00:12 -0700 (PDT) Received: by ykar6 with SMTP id r6so95193875yka.2 for ; Fri, 19 Jun 2015 09:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/13pLd3+UF0EWupz0RKdx4mqFes/n+PP4J9lQj/VERM=; b=wilsoqLocrmXTEJGz1ukpUlZQ93A1dSBi6pJG9jPylCs1CAOtk51eP5Na0ZCweuQF8 MaEHZ78hkxfSz9KCxIYYrAiEQiMWrU7LH0lNgXk+D8I0MknlKv8Ma8NVYHjsWT8F1V4N OqPUU1iT5Vx3KWKhNTO28JdM+SCnudihu6s9phh5iXhYs98pc8nfldsEGGPJvonf6p0E t8D/mKt6lCk0dJFDDB2fvCSX7YpVEdapRKgtfLRpjQ2xqSPfqz96gEhlC/QXOS74Y8+o ElAV5j9c930llh3serzAq5Z5PdnnCsRuTnUVKukeUlekvIrJgHSXx75FOjjJwVQMBE1h AOXA== X-Received: by 10.129.146.19 with SMTP id j19mr21013590ywg.71.1434729612077; Fri, 19 Jun 2015 09:00:12 -0700 (PDT) Received: from [192.168.1.130] ([71.23.40.3]) by mx.google.com with ESMTPSA id d198sm273911ywe.34.2015.06.19.09.00.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jun 2015 09:00:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12F69) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F3414@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 12:00:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02B8A0C4-ABEF-4790-9D35-4C1BB9C05D4F@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F27AF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F28B3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3414@ESESSMB209.ericsson.se> To: Christer Holmberg Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 16:00:15 -0000 On Jun 19, 2015, at 11:13 AM, Christer Holmberg wrote: >=20 > In recent moons people have been talking about never finalizing ICE, inste= ad you will keep collecting candidates throughout the session, and switch be= tween them if one is "better" than that other. You may drop some candidates,= and you may maintain others (even though you are currently not sending any d= ata on them) [BA] A specific proposal is here: https://tools.ietf.org/html/draft-uberti-mmusic-nombis > That brings up a question, though: if you never finalize ICE, will you eve= r be able to do an ICE restart? ICE can always be restarted, whether media is currently flowing or not.=20= From nobody Fri Jun 19 09:15:43 2015 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 2B2F61A92BC for ; Fri, 19 Jun 2015 09:15:42 -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 9w0hbaCZs9I6 for ; Fri, 19 Jun 2015 09:15:41 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7971B1A92B9 for ; Fri, 19 Jun 2015 09:15:39 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-b8-55844029aea2 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AE.92.04015.92044855; Fri, 19 Jun 2015 18:15:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 18:15:37 +0200 From: Christer Holmberg To: Bernard Aboba Thread-Topic: nombis and ICE restart [was: [rtcweb] Comment on consent-freshness-14] Thread-Index: AdCqqudelIuiLXHwRdyDPdR4U3pKaw== Date: Fri, 19 Jun 2015 16:15:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F35F9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvra6WQ0uowd0j/BYb9v1ntpi+z8Zi 7b92dgdmj3MN79k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6M+40NbAVTOSt+nWVvYFzJ 3sXIySEhYCKxfNd6ZghbTOLCvfVsXYxcHEICRxklTnZcZoJwFjNKvF86k7GLkYODTcBCovuf NkiDiIC2RN+3fUwgNrNAgsT7GZfBBgkLBEqc3XGJGaImTGLi491sELaexNy9HWBxFgFViY39 LWA2r4CvxLWLy1lAbEagI76fWgM1U1zi1pP5TBDHCUgs2XMe6lBRiZeP/7FC2EoSjUuesELU 60ncmDqFDcLWlli28DXUfEGJkzOfsExgFJmFZOwsJC2zkLTMQtKygJFlFaNocWpxUm66kZFe alFmcnFxfp5eXmrJJkZgfBzc8ttgB+PL546HGAU4GJV4eBMUWkKFWBPLiitzDzFKc7AoifPO 2JwXKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxWnjejDNTzObnn3cUE5YM5tmy0Si0/EG+ Uku/8Z/FPvs26d8/err7XyinDVditskrn0l3N81vEXq8OuDM38krfHy3z5wSP6vi+3d24Z97 l3sv5t75yO/p5hn2Sh//b7+6I/DAmp23VzqXGkU83Z9TtMXvnwZTHuOjShGlpJBEv75s08yW 5OucSizFGYmGWsxFxYkAKcEu1HACAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: [rtcweb] nombis and ICE restart [was: Comment on consent-freshness-14] 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, 19 Jun 2015 16:15:42 -0000 (Changed the subject, because ICE restart with nombis is not related to con= sent-freshness) Hi, >> In recent moons people have been talking about never finalizing ICE, ins= tead you will keep collecting candidates throughout the session, and=20 >> switch between them if one is "better" than that other. You may drop som= e candidates, and you may maintain others (even though you are=20 >> currently not sending any data on them) > > [BA] A specific proposal is here: > https://tools.ietf.org/html/draft-uberti-mmusic-nombis Correct, I forgot to include the link. >> That brings up a question, though: if you never finalize ICE, will you e= ver be able to do an ICE restart? > > ICE can always be restarted, whether media is currently flowing or not. Sure, but my question was more general whether you can do ICE restart if yo= u use nombis. When reading the nombis draft, it does say that you can perform an ICE rest= art. But, is there any reason for doing it, as you can simply continue coll= ecting new candidates (and drop the ones you don't want to use anymore, I a= ssume) using "normal nombis behaviour"? Regards, Christer From nobody Fri Jun 19 09:26:07 2015 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 C79BA1AC3E4 for ; Fri, 19 Jun 2015 09:26:05 -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 XVtKhBWDFvFf for ; Fri, 19 Jun 2015 09:26:03 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 047D11AC3F0 for ; Fri, 19 Jun 2015 09:26:03 -0700 (PDT) Received: by yhnv31 with SMTP id v31so55722499yhn.1 for ; Fri, 19 Jun 2015 09:26:02 -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=pNcpLQCclEkigwkm2kzH9EfWipWrjndgLTYJMgd1gJc=; b=baJ8kmszGySB/RZhH4OOQAbRVSsn6G//BsQF8S7qM5R/YOq6nlIubasS2R3RtZkt/F HFsh3CCZ+gymZRB56f65HKIAc/LXy2LBeMlT1E3JtV15B8zEumXjuVvN6UN5RMXY+Pyd JlRouWOvBPKiw78SVwblXfZE25DhMA1yT2CPnxuHMiOHlvTZU0xIqDXoNVNhhq5Tvb38 6/7OVaMcW0ouVaD2HG5zqkVn2yAXnqutONy9StKIkmM4/S8N8/576Olc/KvDwrRqw9KA NCUnfp1DkI6kUvtVeKVQrBFBqav7XNEs78+wdHoT7MogN1x2Ve5YcX0g7R9g1NlYpcqp WcNw== MIME-Version: 1.0 X-Received: by 10.129.93.136 with SMTP id r130mr516307ywb.52.1434731162403; Fri, 19 Jun 2015 09:26:02 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 19 Jun 2015 09:26:02 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 09:26:02 -0700 Message-ID: From: Martin Thomson To: Muthu Arul Mozhi Perumal Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 16:26:05 -0000 On 18 June 2015 at 23:01, Muthu Arul Mozhi Perumal wrote: > An endpoint that is not sending any application data after obtaining > consent does not need to maintain consent. The endpoint can resume > sending > application data using the consent obtained earlier. As soon as the > endpoint > resumes sending application data, consent is maintained following the > procedure described in this document. This isn't right. Consent has to be *reacquired* before sending. This implies that you can use consent from earlier, even expired consent. From nobody Fri Jun 19 10:20:44 2015 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 AC1381A8F40 for ; Fri, 19 Jun 2015 10:20:43 -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 v7iAksy8h4BA for ; Fri, 19 Jun 2015 10:20:39 -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 AEA561A8A06 for ; Fri, 19 Jun 2015 10:20:38 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-70-55844f64fa3d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FF.61.04401.46F44855; Fri, 19 Jun 2015 19:20:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 19:20:36 +0200 From: Christer Holmberg To: Martin Thomson , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAArlwA///Qu4A= Date: Fri, 19 Jun 2015 17:20:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+JvrW6qf0uowU5Niw37/jNbXDvzj9Hi z2Y/i7X/2tkdWDx2zrrL7rFkyU+mAKYoLpuU1JzMstQifbsEroy3My6yFbRxVsxa2MnawPiC o4uRk0NCwETi57z/zBC2mMSFe+vZQGwhgaOMEvfu1XQxcgHZixkl9n/5w9rFyMHBJmAh0f1P G6RGRCBB4satKewgNrNAkMS1pZeYQGxhAVOJNZfnMEPUmEm0np3JCmGXSSy4MAWshkVAVWLv 3XNgvbwCvhLLbi9mhdj1lFXi0s0TYM2cAoESbYfngx3ECHTc91NrmCCWiUvcejKfCeJoAYkl e85DPSAq8fLxP1YIW0li0e3PTCA3MwtoSqzfpQ/Rqigxpfsh1F5BiZMzn7BMYBSbhWTqLISO WUg6ZiHpWMDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMJYObvmtuoPx8hvHQ4wCHIxK PLwJCi2hQqyJZcWVuYcYpTlYlMR5Z2zOCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqPbv 2reCe2cOcB/R0lPykLE/mKJ2pv9Op9C3mfWRBWpn4o4uDk37qnnkx8dD3Kccu/VKz57ecOzs 7/P6F3TuPlN/6rQhZ+mZh5virG5yKTasMHkocJOzIYmded56m62iT9WDWVRa+1KvVX5jfrm/ 9fv/Vdp3n0zZElVadJ2HfcFDX78Pi7q/rVViKc5INNRiLipOBADihml8hgIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 17:20:43 -0000 SGksDQoNCj4+ICAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0 aW9uIGRhdGEgYWZ0ZXIgb2J0YWluaW5nDQo+PiAgICBjb25zZW50IGRvZXMgbm90IG5lZWQgdG8g bWFpbnRhaW4gY29uc2VudC4gVGhlIGVuZHBvaW50IGNhbiByZXN1bWUgDQo+PiAgIHNlbmRpbmcg YXBwbGljYXRpb24gZGF0YSB1c2luZyB0aGUgY29uc2VudCBvYnRhaW5lZCBlYXJsaWVyLiBBcyBz b29uIGFzIHRoZSANCj4+ICBlbmRwb2ludCByZXN1bWVzIHNlbmRpbmcgYXBwbGljYXRpb24gZGF0 YSwgY29uc2VudCBpcyBtYWludGFpbmVkIGZvbGxvd2luZyB0aGUNCj4+ICAgIHByb2NlZHVyZSBk ZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4NCj4NCj4gVGhpcyBpc24ndCByaWdodC4gIENvbnNl bnQgaGFzIHRvIGJlICpyZWFjcXVpcmVkKiBiZWZvcmUgc2VuZGluZy4NCj4gVGhpcyBpbXBsaWVz IHRoYXQgeW91IGNhbiB1c2UgY29uc2VudCBmcm9tIGVhcmxpZXIsIGV2ZW4gZXhwaXJlZCBjb25z ZW50Lg0KDQpHb29kIHBvaW50Lg0KDQpJIGd1ZXNzIHRoZSB0ZXh0IHNob3VsZCBzYXk6DQoNCiJX aGVuIHRoZSBlbmRwb2ludCB3YW50cyB0byBzdGFydCBzZW5kaW5nIGRhdGEgYWdhaW4sIGl0IGZp cnN0IG5lZWRzIHRvIHJlLW9idGFpbg0KY29uc2VudCwgc28gaXQgc3RhcnRzIHRoZSBzZW5kaW5n IG9mIGNvbnNlbnQgcmVxdWVzdHMgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzIGluIHRoaXMg ZG9jdW1lbnQNCih0aGUgZW5kcG9pbnQgZG9lcyBub3QgbmVlZCB0byBwZXJmb3JtIElDRSByZXN0 YXJ0IGluIHRoaXMgY2FzZSkuIg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Fri Jun 19 10:25:02 2015 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 E3A291A92AF for ; Fri, 19 Jun 2015 10:25:01 -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 5W_JHN_0xm_9 for ; Fri, 19 Jun 2015 10:25:00 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF3E1A9007 for ; Fri, 19 Jun 2015 10:25:00 -0700 (PDT) Received: by yhan67 with SMTP id n67so82619858yha.3 for ; Fri, 19 Jun 2015 10:25: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=OM5Ka3POgHdaaVCmCvT+th/roCGFXuamBGQwPwEFOl4=; b=LSjMtX8Un+xm9WI5wlQAoQMejGjaNCbeFHkLG53fSJ6JFeMiR5+8YfNuR6IOtK3eg1 qqERI2JtMCYzvde99RPKY+uHoBwlfhaoX9/ZcJHnrzCax1ms++yCd2AaIbVCWGL+qXE6 hvihCId2ppUUoPCJtOp8FhCwwGuxYU780G9I5wnaap/yAmFTNa3wDAuO1Dr62ZirOwIP hkEkwcd/JesHOmARdAMh/FyLHUnGYBNvDHWvvJe8ukGnvDGjE95bkrDp59S+4sKQm8Cd e1F02DbYzU9I21jvovdowOaBjbzgEnfOLd/x4wuyfwmmW939YPC9qvqPAySqynuEoGEX 5D9g== MIME-Version: 1.0 X-Received: by 10.129.93.136 with SMTP id r130mr866046ywb.52.1434734700132; Fri, 19 Jun 2015 10:25:00 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Fri, 19 Jun 2015 10:25:00 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 10:25:00 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 17:25:02 -0000 On 19 June 2015 at 10:20, Christer Holmberg wrote: > "When the endpoint wants to start sending data again, it first needs to re-obtain > consent, so it starts the sending of consent requests according to the procedures in this document > (the endpoint does not need to perform ICE restart in this case)." Packet loss is going to be devastating to performance if you just start checking again. Should we also recommend (or allow) the use of a STUN transaction to regain consent? From nobody Fri Jun 19 10:36:14 2015 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 858EB1ACD24 for ; Fri, 19 Jun 2015 10:36:13 -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 7uZJgsxp6BZE for ; Fri, 19 Jun 2015 10:36:12 -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 9BFEF1ACCFF for ; Fri, 19 Jun 2015 10:36:11 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-14-55845309e4dc Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2F.C7.17665.90354855; Fri, 19 Jun 2015 19:36:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 19:36:09 +0200 From: Christer Holmberg To: Martin Thomson Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAArlwA///Qu4AAB/fzAAAElIFW Date: Fri, 19 Jun 2015 17:36:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F376EESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3VpczuCXU4Ncha4sN+/4zW1w784/R 4s9mP4u1/9rZHVg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MpZe4C5bKVzze8p+9gfGg dBcjJ4eEgInErvW72CFsMYkL99azdTFycQgJHGWUOHH4DBtIQkhgMaPElB2qXYwcHGwCFhLd /7RBwiICuhKLzj5gB6lnFmhmlFj45BnYIGEBU4k1l+cwQxSZSbSenckKYTcxSrw5Wgxiswio Sky7+4URxOYV8JWY8qCfEWLxOzaJKV/vs4AkOAUCJXpuLQFrZgS67vupNUwgNrOAuETTl5Ws EFcLSCzZc54ZwhaVePn4HytETb7Ej8lHmSAWCEqcnPmEZQKjyCwk7bOQlM1CUgYRN5D48v42 lK0tsWzha2YIW1+i+/1pJmTxBYzsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECI+3glt+6 OxhXv3Y8xCjAwajEw5ug0BIqxJpYVlyZe4hRmoNFSZx3xua8UCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2Mgozn2fs8ZZli+Ve1O/S+PpbQ9WXN+2VOzJ3eJ70f/zWZ9vqYxfQjwk18IULb eJ42xlcEG0qstZCTXbFzXsS6ZdL+py+J/hd+yDnpsxNDAb/2mzrP7slm9WlVXj3nXuct+nDm adScCf76/RrfuidNYDknuvur2KO0t0LHGpITlFPM97vPu7dKiaU4I9FQi7moOBEA3y/9RJUC AAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 17:36:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F376EESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, You re-obtain consent using STUN. Regards, Christer Sent from my Windows Phone ________________________________ From: Martin Thomson Sent: =FD19/=FD06/=FD2015 20:25 To: Christer Holmberg Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org Subject: Re: [rtcweb] Comment on consent-freshness-14 On 19 June 2015 at 10:20, Christer Holmberg wrote: > "When the endpoint wants to start sending data again, it first needs to r= e-obtain > consent, so it starts the sending of consent requests according to the pr= ocedures in this document > (the endpoint does not need to perform ICE restart in this case)." Packet loss is going to be devastating to performance if you just start checking again. Should we also recommend (or allow) the use of a STUN transaction to regain consent? --_000_7594FB04B1934943A5C02806D1A2204B1D8F376EESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone
From: Martin Thomson
Sent: =FD19= /=FD06/=FD2015 20:25
To: Christer Holmberg Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [= rtcweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first ne= eds to re-obtain
> consent, so it starts the sending of consent requests according to the= procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."= ;


Packet loss is going to be devastating to performance if you just
start checking again.  Should we also recommend (or allow) the use of<= br> a STUN transaction to regain consent?
 --_000_7594FB04B1934943A5C02806D1A2204B1D8F376EESESSMB209erics_-- From nobody Fri Jun 19 11:19:56 2015 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 6D20D1ACEA8 for ; Fri, 19 Jun 2015 11:19:54 -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 oXrskrK9G9OV for ; Fri, 19 Jun 2015 11:19:52 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6FA1ACEA7 for ; Fri, 19 Jun 2015 11:19:52 -0700 (PDT) Received: by wgfq1 with SMTP id q1so49352132wgf.1 for ; Fri, 19 Jun 2015 11:19: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=VZEK3khesxSjFXkDpsCD9Tpun06Fivu8YeNwuEuKi/M=; b=cLIQQFa0FMCtEoA730YZ+3vuVYGw2vKMiwy3j8ItXFVNObNWz16pY9EKYY/Cg76qJL 2OhaklXH47rS+NqLcXHO24y021reFYYH2Rty7OvflSXnecqJZMuVbmcBItqcuuoqyuXk +f92jl827B5FLsdxZVfVI6jYrGONDwxKCYW4BcjSs0FTmj5woAkPOaoJSRmEz+rMutPl mFGY4kK9mFxr/0XFNBfOvdR23sZHS3qs1Ip14RlCdvUHOVSMqegfJJ5cg9sAQU6IMam9 W1/BKXon1EPImcLXQIqpuavjFOP8rzAbA4IFtwBQALpIrJ4MKKZfxNRIlNamu/B0kIjH ORIg== MIME-Version: 1.0 X-Received: by 10.180.73.145 with SMTP id l17mr9077004wiv.39.1434737991319; Fri, 19 Jun 2015 11:19:51 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Fri, 19 Jun 2015 11:19:51 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> Date: Fri, 19 Jun 2015 23:49:51 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043c7e805189380518e2f8aa Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 18:19:54 -0000 --f46d043c7e805189380518e2f8aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But there would still be loss of application data for at least one RTT before consent can be regained. Would that be devastating for video if the initial packets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after a minute)? Muthu On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > You re-obtain consent using STUN. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Martin Thomson > Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 > To: Christer Holmberg > Cc: Muthu Arul Mozhi Perumal ; Bernard Aboba > ; rtcweb@ietf.org > Subject: Re: [rtcweb] Comment on consent-freshness-14 > > On 19 June 2015 at 10:20, Christer Holmberg > wrote: > > "When the endpoint wants to start sending data again, it first needs to > re-obtain > > consent, so it starts the sending of consent requests according to the > procedures in this document > > (the endpoint does not need to perform ICE restart in this case)." > > > Packet loss is going to be devastating to performance if you just > start checking again. Should we also recommend (or allow) the use of > a STUN transaction to regain consent? > --f46d043c7e805189380518e2f8aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But there would still be loss of applic= ation data for at least one RTT before consent can be regained. Would that = be devastating for video if the initial packets sent after resumption conta= ined the I-frame (for e.g, the user turns off the camera and turns it on af= ter a minute)?

Muthu

On Fri, Jun 1= 9, 2015 at 11:06 PM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone
From: Martin Thomson<= /span>
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holm= berg
Cc: Muthu Arul Mozhi Peruma= l; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: Re: [r= tcweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first ne= eds to re-obtain
> consent, so it starts the sending of consent requests according to the= procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."= ;


Packet loss is going to be devastating to performance if you just
start checking again.=C2=A0 Should we also recommend (or allow) the use of<= br> a STUN transaction to regain consent?

--f46d043c7e805189380518e2f8aa-- From nobody Fri Jun 19 11:47:43 2015 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 1F38D1ACEFD for ; Fri, 19 Jun 2015 11:47:42 -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 h85vWY1R20w5 for ; Fri, 19 Jun 2015 11:47:40 -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 C363B1ACEFB for ; Fri, 19 Jun 2015 11:47:39 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-7e-558463c9d9af Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 68.52.28096.9C364855; Fri, 19 Jun 2015 20:47:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Fri, 19 Jun 2015 20:47:37 +0200 From: Christer Holmberg To: Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAArlwA///Qu4AAB/fzAAAElIFWAAKqG4AAACs3Vg== Date: Fri, 19 Jun 2015 18:47:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F3806ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3VvdUckuowbvJXBYb9v1ntrh25h+j xZ/NfhZr/7WzO7B47Jx1l91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZU/csZCvYYFuxb8cl9gbG FrMuRk4OCQETialzrzNC2GISF+6tZ+ti5OIQEjjKKHFv3SVmCGcxo8SCFReBqjg42AQsJLr/ aYM0iAgYS2xp+cUKYjML1EpcmnYVbJCwgKnEmstzmCFqzCRaz85kBZkjIjCJUWLb7n6wBhYB VYlHqzvBbF4BX4m+t3vYIZb9ZJdY2rWZCSTBKRAo8WbnAjYQmxHovO+n1jBBbBOXaPqykhXi bAGJJXvOM0PYohIvH/+DuihfYvqrzYwQCwQlTs58wjKBUWQWkvZZSMpmISmDiBtIfHl/G8rW lli28DUzhK0v0f3+NBOy+AJG9lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgdF2cMtvqx2M B587HmIU4GBU4uFNUGgJFWJNLCuuzD3EKM3BoiTOO2NzXqiQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGRqXZKRyPH2mZlJSd8I1YNH97H+/1L9yHfszYtUf8gyrz6fIM9w0dkgIW8emfb9bF FL+bfj1P8M3TDa8mFibuXqnlytZ6Psybz/gd+9qA+hNn5r5d6Z53e9aNovqQuB0zd6q9uXN8 37a7lcyva/KtzmrujzyWde1m0FIRoWmvS5Wrz9/gUH9e90SJpTgj0VCLuag4EQDKL6NflwIA AA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 19 Jun 2015 18:47:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F3806ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, In order to avoid loss of data, you shall not start sending data until you = have regained consent, similar to when the session was established. Regards, Christer Sent from my Windows Phone ________________________________ From: Muthu Arul Mozhi Perumal Sent: =FD19/=FD06/=FD2015 21:19 To: Christer Holmberg Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org Subject: Re: [rtcweb] Comment on consent-freshness-14 But there would still be loss of application data for at least one RTT befo= re consent can be regained. Would that be devastating for video if the init= ial packets sent after resumption contained the I-frame (for e.g, the user = turns off the camera and turns it on after a minute)? Muthu On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg > wrote: Hi, You re-obtain consent using STUN. Regards, Christer Sent from my Windows Phone ________________________________ From: Martin Thomson Sent: =FD19/=FD06/=FD2015 20:25 To: Christer Holmberg Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org Subject: Re: [rtcweb] Comment on consent-freshness-14 On 19 June 2015 at 10:20, Christer Holmberg > wro= te: > "When the endpoint wants to start sending data again, it first needs to r= e-obtain > consent, so it starts the sending of consent requests according to the pr= ocedures in this document > (the endpoint does not need to perform ICE restart in this case)." Packet loss is going to be devastating to performance if you just start checking again. Should we also recommend (or allow) the use of a STUN transaction to regain consent? --_000_7594FB04B1934943A5C02806D1A2204B1D8F3806ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

In order to avoid loss of data, you shall not start sending data until you = have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Perumal
Sent: =FD19= /=FD06/=FD2015 21:19
To: Christer Holmberg Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [= rtcweb] Comment on consent-freshness-14

But there would still be loss of application data for at least one RTT befo= re consent can be regained. Would that be devastating for video if the init= ial packets sent after resumption contained the I-frame (for e.g, the user = turns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone
From: Martin Thomson=
Sent: =FD19= /=FD06/=FD2015 20:25
To: Christer Hol= mberg
Cc: Muthu Arul Mozhi Perum= al; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: Re: [= rtcweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first ne= eds to re-obtain
> consent, so it starts the sending of consent requests according to the= procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."= ;


Packet loss is going to be devastating to performance if you just
start checking again.  Should we also recommend (or allow) the use of<= br> a STUN transaction to regain consent?

--_000_7594FB04B1934943A5C02806D1A2204B1D8F3806ESESSMB209erics_-- From nobody Fri Jun 19 19:11:07 2015 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 C4B761B2C96 for ; Fri, 19 Jun 2015 19:11:05 -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 yTyShXHgdx5q for ; Fri, 19 Jun 2015 19:11:03 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E52E1B2C94 for ; Fri, 19 Jun 2015 19:11:03 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so33006829wic.1 for ; Fri, 19 Jun 2015 19:11:02 -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=24ZBa+F2yeNFk6xLX2XKTnbkHa3SDL0xtUMKB4WMeuA=; b=RdZZGnJI5PrMC1diFrT81yUHOtcAnQjA6nb7e52nxSxNdL0iI3MMpq9hBPTzMUoQbk IP77eLZjGTPbWycKQYA5yIsFK6Qlu/+exITK3TYga2FkxPgfosgz3hk0u022E9D4hIsX xtsl5BoTm9YuseuQ7p+JGWue7kWCocUqNrhI/ymd5/omaZ/zkAcS1qAgg2gGveTq4OL0 tx1S65okb6mSW6vmemuymUUzdT0y22y3yAlUvOPVYzVai/omgkXxzaGpcEtt/G4Kd/xL Xa+h2q3cF0GnimvRKRQv9VDgufYyy22IkmSe8Y1qUCByJaGdXCnp/Vls0h3LNtuHo7qi veWA== MIME-Version: 1.0 X-Received: by 10.180.218.137 with SMTP id pg9mr11403870wic.79.1434766262225; Fri, 19 Jun 2015 19:11:02 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Fri, 19 Jun 2015 19:11:02 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> Date: Sat, 20 Jun 2015 07:41:02 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1134cedc654f580518e98dd8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 02:11:06 -0000 --001a1134cedc654f580518e98dd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But unless the application starts sending data, consent will not be regained, so it is a chicken-and-egg problem -:) Some of the possible solutions: - ICE restart -- too much of overhead and possible O/A race conditions, don't like. - Endpoint buffers the application data till consent is regained -- kluge, don't like. - Allow the endpoint to resume sending application data using the consent it had when it stopped sending -- could open a backdoor, still don't like. - Keep maintaining consent irrespective of whether application data is sent or not -- simple, serves as a heartbeat in the absence of application data, helps to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is insignificant (some keepalives would be sent anyway), so like it. Muthu On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > In order to avoid loss of data, you shall not start sending data until yo= u > have regained consent, similar to when the session was established. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Muthu Arul Mozhi Perumal > Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 > To: Christer Holmberg > Cc: Martin Thomson ; Bernard Aboba > ; rtcweb@ietf.org > Subject: Re: [rtcweb] Comment on consent-freshness-14 > > But there would still be loss of application data for at least one RTT > before consent can be regained. Would that be devastating for video if th= e > initial packets sent after resumption contained the I-frame (for e.g, the > user turns off the camera and turns it on after a minute)? > > Muthu > > On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> You re-obtain consent using STUN. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------ >> From: Martin Thomson >> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 >> To: Christer Holmberg >> Cc: Muthu Arul Mozhi Perumal ; Bernard Aboba >> ; rtcweb@ietf.org >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >> >> On 19 June 2015 at 10:20, Christer Holmberg >> wrote: >> > "When the endpoint wants to start sending data again, it first needs t= o >> re-obtain >> > consent, so it starts the sending of consent requests according to the >> procedures in this document >> > (the endpoint does not need to perform ICE restart in this case)." >> >> >> Packet loss is going to be devastating to performance if you just >> start checking again. Should we also recommend (or allow) the use of >> a STUN transaction to regain consent? >> > > --001a1134cedc654f580518e98dd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But unless the application starts sendi= ng data, consent will not be regained, so it is a chicken-and-egg problem -= :)

Some of the possibl= e solutions:
- ICE restart -- too much of overhead = and possible O/A race conditions, don't like.
- Endpoint buffers the application data till consent is regained -- klug= e, don't like.
- Allow the endpoint to resume s= ending application data using the consent it had when it stopped sending --= could open a backdoor, still don't like.
- Kee= p maintaining consent irrespective of whether application data is sent or n= ot -- simple, serves as a heartbeat in the absence of application data, hel= ps to keep NAT bindings alive and helps to refine RTT. The trade off is som= e network bandwidth, but I think it is insignificant (some keepalives would= be sent anyway), so like it.

Muthu

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

In order to avoid loss of data, you shall not start sending data until you = have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Peruma= l
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 21:19
To: Christer Holm= berg
Cc: Martin Thomson; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: Re: [r= tcweb] Comment on consent-freshness-14

But there would still be loss of application data for at least one RTT befo= re consent can be regained. Would that be devastating for video if the init= ial packets sent after resumption contained the I-frame (for e.g, the user = turns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone
From: Martin Thomson<= /span>
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holm= berg
Cc: Muthu Arul Mozhi Peruma= l; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: Re: [r= tcweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first ne= eds to re-obtain
> consent, so it starts the sending of consent requests according to the= procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."= ;


Packet loss is going to be devastating to performance if you just
start checking again.=C2=A0 Should we also recommend (or allow) the use of<= br> a STUN transaction to regain consent?


--001a1134cedc654f580518e98dd8-- From nobody Fri Jun 19 21:58:39 2015 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 3E7A31B2D0F for ; Fri, 19 Jun 2015 21:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 aUzCRcxZ0xDW for ; Fri, 19 Jun 2015 21:58:36 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1651ACCEC for ; Fri, 19 Jun 2015 21:58:36 -0700 (PDT) Received: by ykfl8 with SMTP id l8so103698076ykf.1 for ; Fri, 19 Jun 2015 21:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bqhSaxnVeCznUgFpSoXh2GwNBIU6ZV/C3Ni2BQeXJtw=; b=P20S8KEMV8hjPR84lN+6dPlJFy27/2URgMDFy00Rhl8BWhtuISxn87cOOcJcWrSeox aS9o1sr899yZ1yKeUngVzG7lsdDsZBONUp6M7v+Xciyf4cHY0AoKsamLswndDcO/hcAz gnSUKRYX59OAB6SUQspRoyrG5i/7R9Rw7DgCp2frtAVX2zn7owtaeQtQH554zw3t6tr4 7J0qtoRu1FnVag9nAfg4m8LTftA6aZ5F686u3KzL/TKjPpiAqg+AMpmirQ096sA2Iwcn ptw2b708Tddo8t7f8wraLESn1IXGBWOhh/lBdbEWK3CagS0y+Zufv5gv7DxsvCGIV/oo Wb8w== X-Received: by 10.129.90.69 with SMTP id o66mr22689911ywb.21.1434776315692; Fri, 19 Jun 2015 21:58:35 -0700 (PDT) Received: from ?IPv6:2601:580:4001:4a05:f959:411a:d1b6:3dac? ([2601:580:4001:4a05:f959:411a:d1b6:3dac]) by mx.google.com with ESMTPSA id 74sm10506088ywe.43.2015.06.19.21.58.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jun 2015 21:58:34 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-AA750F7E-7FDD-4183-A4C3-DD09CDF2248B Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12F69) In-Reply-To: Date: Sat, 20 Jun 2015 00:58:33 -0400 Content-Transfer-Encoding: 7bit Message-Id: <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> To: Muthu Arul Mozhi Perumal Archived-At: Cc: "" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 04:58:38 -0000 --Apple-Mail-AA750F7E-7FDD-4183-A4C3-DD09CDF2248B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Personally, I'm fine with requiring that consent be regained before sending.= This need not exact a performance penalty. In make before break scenarios, consent can be regained first in the backgro= und before data is switched over to the revived candidate pair, so no buffer= ing is needed. If there is a desire to have a "hot standby" so as to avoid b= uffering in break before make, then consent can be continued even when no da= ta is being sent (what Justin's nombis draft proposes). =20 However I do not see the need to mandate consent for pairs over which no dat= a is sent in this document. Let us leave that decision to future documents i= n MMUSIC WG.=20 > On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal wrote: >=20 > But unless the application starts sending data, consent will not be regain= ed, so it is a chicken-and-egg problem -:) >=20 > Some of the possible solutions: > - ICE restart -- too much of overhead and possible O/A race conditions, do= n't like. > - Endpoint buffers the application data till consent is regained -- kluge,= don't like. > - Allow the endpoint to resume sending application data using the consent i= t had when it stopped sending -- could open a backdoor, still don't like. > - Keep maintaining consent irrespective of whether application data is sen= t or not -- simple, serves as a heartbeat in the absence of application data= , helps to keep NAT bindings alive and helps to refine RTT. The trade off is= some network bandwidth, but I think it is insignificant (some keepalives wo= uld be sent anyway), so like it. >=20 > Muthu >=20 >> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg wrote: >> Hi, >>=20 >> In order to avoid loss of data, you shall not start sending data until yo= u have regained consent, similar to when the session was established. >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >> From: Muthu Arul Mozhi Perumal >> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 >> To: Christer Holmberg >> Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >>=20 >> But there would still be loss of application data for at least one RTT be= fore consent can be regained. Would that be devastating for video if the ini= tial packets sent after resumption contained the I-frame (for e.g, the user t= urns off the camera and turns it on after a minute)? >>=20 >> Muthu >>=20 >>> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg wrote: >>> Hi, >>>=20 >>> You re-obtain consent using STUN. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> Sent from my Windows Phone >>> From: Martin Thomson >>> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 >>> To: Christer Holmberg >>> Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org >>> Subject: Re: [rtcweb] Comment on consent-freshness-14 >>>=20 >>> On 19 June 2015 at 10:20, Christer Holmberg >>> wrote: >>> > "When the endpoint wants to start sending data again, it first needs t= o re-obtain >>> > consent, so it starts the sending of consent requests according to the= procedures in this document >>> > (the endpoint does not need to perform ICE restart in this case)." >>>=20 >>>=20 >>> Packet loss is going to be devastating to performance if you just >>> start checking again. Should we also recommend (or allow) the use of >>> a STUN transaction to regain consent? >>=20 >=20 --Apple-Mail-AA750F7E-7FDD-4183-A4C3-DD09CDF2248B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Personally, I'm fine with requiring th= at consent be regained before sending.  This need not exact a performan= ce penalty.

In make before break scenarios, consent= can be regained first in the background before data is switched over to the= revived candidate pair, so no buffering is needed. If there is a desire to h= ave a "hot standby" so as to avoid buffering in break before make, then consent can be co= ntinued even when no data is being sent (what Justin's nombis draft proposes= ).  

However I do not see the need to mandate consent for pairs over= which no data is sent in this document. Let us leave that decision to futur= e documents in MMUSIC WG. 


On Jun 1= 9, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

But unless the applicat= ion starts sending data, consent will not be regained, so it is a chicken-an= d-egg problem -:)

Some of= the possible solutions:
- ICE restart -- too much of= overhead and possible O/A race conditions, don't like.
- Endpoint buffers the application data till consent is regained -- klu= ge, don't like.
- Allow the endpoint to resume sendin= g application data using the consent it had when it stopped sending -- could= open a backdoor, still don't like.
- Keep maintaining c= onsent irrespective of whether application data is sent or not -- simple, se= rves as a heartbeat in the absence of application data, helps to keep NAT bi= ndings alive and helps to refine RTT. The trade off is some network bandwidt= h, but I think it is insignificant (some keepalives would be sent anyway), s= o like it.

Muthu

On Sat, Jun 20, 2015 a= t 12:17 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

In order to avoid loss of data, you shall not start sending data until you h= ave regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone
But there would still be loss of application data for at least one RTT befor= e consent can be regained. Would that be devastating for video if the initia= l packets sent after resumption contained the I-frame (for e.g, the user tur= ns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmbe= rg <chri= ster.holmberg@ericsson.com> wrote:
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone
From: Martin Thomson
Sent: =E2=80=8E= 19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holmbe= rg
Cc: Muthu Arul Mozhi Perumal<= /a>; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [rt= cweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<chri= ster.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first needs to= re-obtain
> consent, so it starts the sending of consent requests according to the p= rocedures in this document
> (the endpoint does not need to perform ICE restart in this case)."


Packet loss is going to be devastating to performance if you just
start checking again.  Should we also recommend (or allow) the use of a STUN transaction to regain consent?


= --Apple-Mail-AA750F7E-7FDD-4183-A4C3-DD09CDF2248B-- From nobody Sat Jun 20 02:09:45 2015 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 34D9E1A007D for ; Sat, 20 Jun 2015 02:09:44 -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 zaas_W0iTPWR for ; Sat, 20 Jun 2015 02:09:41 -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 A35CF1A006D for ; Sat, 20 Jun 2015 02:09:40 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-41-55852dd2af58 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.25.04401.2DD25855; Sat, 20 Jun 2015 11:09:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Sat, 20 Jun 2015 11:09:38 +0200 From: Christer Holmberg To: Bernard Aboba , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAArlwA///Qu4AAB/fzAAAElIFWAAKqG4AAACs3VgAK9UgAAAXZt4D//5jVUA== Date: Sat, 20 Jun 2015 09:09:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F3D49@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> In-Reply-To: <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F3D49ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3VveSbmuowbxJ5hYb9v1ntrh25h+j xZ/NfhZr/7WzO7B47Jx1l91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZa94vYS/YsZ+xovXdavYG xg27GLsYOTkkBEwk5ky4zwphi0lcuLeeDcQWEjjKKHF2c1IXIxeQvZhRYt3jn8xdjBwcbAIW Et3/tEFqRATiJBZe+8wCYjMLhEm8/T+TCcQWFjCVWHN5DjNEjZlE69mZrCBzRASWMUpc/v+H CWQOi4CqxNdGCZAaXgFfifstvSwQu3ZySqy//QRsKKeArcSSlk6woYxAx30/tYYJYpm4xK0n 85kgjhaQWLLnPDOELSrx8vE/qGeUJBqXPGEF2cUskC/x7a83xC5BiZMzn7BMYBSdhWTSLISq WUiqIMKaEut36UNUK0pM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRsV5qUWZycXF+nl5e askmRmD8HdzyW3UH4+U3jocYBTgYlXh4FU62hAqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA+NEhg0FfszhVi4XbhiWtht92sX7QtWrJH/61CVdmUIrdJS0 T90OZ1TU36z75ZOTYJsOE+PjGufWxzcfizoK2txIn7y0dcGzjUKblt8wY95swdMWJNKxrP+y 4GWjQyujfHyatG7Pli05LCz+66fFr1OvHJO+Tg7ZcFphq4w/9+uTKhzs1pHZ2kosxRmJhlrM RcWJAKLf9eCgAgAA Archived-At: Cc: "" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 09:09:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F3D49ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gZXZlcnl0aGluZyBCZXJuYXJkIHNhaWQuDQoNCkl0IGlzIHBlcmZlY3RseSBvayB0byBt YWludGFpbiBjb25zZW50LCBldmVuIGlmIG5vIGFwcGxpY2F0aW9uIGRhdGEgaXMgc2VudCwgZS5n LiBpZiB5b3Ugd2FudCB0byBoYXZlIGEg4oCcaG90IHN0YW5kYnnigJ0uDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCkZyb206IEJlcm5hcmQgQWJvYmEgW21haWx0bzpiZXJuYXJkLmFib2JhQGdt YWlsLmNvbV0NClNlbnQ6IDIwIEp1bmUgMjAxNSAwNzo1OQ0KVG86IE11dGh1IEFydWwgTW96aGkg UGVydW1hbA0KQ2M6IENocmlzdGVyIEhvbG1iZXJnOyBNYXJ0aW4gVGhvbXNvbjsgPHJ0Y3dlYkBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2hu ZXNzLTE0DQoNClBlcnNvbmFsbHksIEknbSBmaW5lIHdpdGggcmVxdWlyaW5nIHRoYXQgY29uc2Vu dCBiZSByZWdhaW5lZCBiZWZvcmUgc2VuZGluZy4gIFRoaXMgbmVlZCBub3QgZXhhY3QgYSBwZXJm b3JtYW5jZSBwZW5hbHR5Lg0KDQpJbiBtYWtlIGJlZm9yZSBicmVhayBzY2VuYXJpb3MsIGNvbnNl bnQgY2FuIGJlIHJlZ2FpbmVkIGZpcnN0IGluIHRoZSBiYWNrZ3JvdW5kIGJlZm9yZSBkYXRhIGlz IHN3aXRjaGVkIG92ZXIgdG8gdGhlIHJldml2ZWQgY2FuZGlkYXRlIHBhaXIsIHNvIG5vIGJ1ZmZl cmluZyBpcyBuZWVkZWQuIElmIHRoZXJlIGlzIGEgZGVzaXJlIHRvIGhhdmUgYSAiaG90IHN0YW5k YnkiIHNvIGFzIHRvIGF2b2lkIGJ1ZmZlcmluZyBpbiBicmVhayBiZWZvcmUgbWFrZSwgdGhlbiBj b25zZW50IGNhbiBiZSBjb250aW51ZWQgZXZlbiB3aGVuIG5vIGRhdGEgaXMgYmVpbmcgc2VudCAo d2hhdCBKdXN0aW4ncyBub21iaXMgZHJhZnQgcHJvcG9zZXMpLg0KDQoNCkhvd2V2ZXIgSSBkbyBu b3Qgc2VlIHRoZSBuZWVkIHRvIG1hbmRhdGUgY29uc2VudCBmb3IgcGFpcnMgb3ZlciB3aGljaCBu byBkYXRhIGlzIHNlbnQgaW4gdGhpcyBkb2N1bWVudC4gTGV0IHVzIGxlYXZlIHRoYXQgZGVjaXNp b24gdG8gZnV0dXJlIGRvY3VtZW50cyBpbiBNTVVTSUMgV0cuDQoNCg0KT24gSnVuIDE5LCAyMDE1 LCBhdCAxMDoxMSBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIDxtdXRodS5hcnVsQGdtYWls LmNvbTxtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20+PiB3cm90ZToNCkJ1dCB1bmxlc3MgdGhl IGFwcGxpY2F0aW9uIHN0YXJ0cyBzZW5kaW5nIGRhdGEsIGNvbnNlbnQgd2lsbCBub3QgYmUgcmVn YWluZWQsIHNvIGl0IGlzIGEgY2hpY2tlbi1hbmQtZWdnIHByb2JsZW0gLTopDQoNClNvbWUgb2Yg dGhlIHBvc3NpYmxlIHNvbHV0aW9uczoNCi0gSUNFIHJlc3RhcnQgLS0gdG9vIG11Y2ggb2Ygb3Zl cmhlYWQgYW5kIHBvc3NpYmxlIE8vQSByYWNlIGNvbmRpdGlvbnMsIGRvbid0IGxpa2UuDQotIEVu ZHBvaW50IGJ1ZmZlcnMgdGhlIGFwcGxpY2F0aW9uIGRhdGEgdGlsbCBjb25zZW50IGlzIHJlZ2Fp bmVkIC0tIGtsdWdlLCBkb24ndCBsaWtlLg0KLSBBbGxvdyB0aGUgZW5kcG9pbnQgdG8gcmVzdW1l IHNlbmRpbmcgYXBwbGljYXRpb24gZGF0YSB1c2luZyB0aGUgY29uc2VudCBpdCBoYWQgd2hlbiBp dCBzdG9wcGVkIHNlbmRpbmcgLS0gY291bGQgb3BlbiBhIGJhY2tkb29yLCBzdGlsbCBkb24ndCBs aWtlLg0KLSBLZWVwIG1haW50YWluaW5nIGNvbnNlbnQgaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIg YXBwbGljYXRpb24gZGF0YSBpcyBzZW50IG9yIG5vdCAtLSBzaW1wbGUsIHNlcnZlcyBhcyBhIGhl YXJ0YmVhdCBpbiB0aGUgYWJzZW5jZSBvZiBhcHBsaWNhdGlvbiBkYXRhLCBoZWxwcyB0byBrZWVw IE5BVCBiaW5kaW5ncyBhbGl2ZSBhbmQgaGVscHMgdG8gcmVmaW5lIFJUVC4gVGhlIHRyYWRlIG9m ZiBpcyBzb21lIG5ldHdvcmsgYmFuZHdpZHRoLCBidXQgSSB0aGluayBpdCBpcyBpbnNpZ25pZmlj YW50IChzb21lIGtlZXBhbGl2ZXMgd291bGQgYmUgc2VudCBhbnl3YXkpLCBzbyBsaWtlIGl0Lg0K DQpNdXRodQ0KDQpPbiBTYXQsIEp1biAyMCwgMjAxNSBhdCAxMjoxNyBBTSwgQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSW4gb3JkZXIgdG8gYXZvaWQgbG9z cyBvZiBkYXRhLCB5b3Ugc2hhbGwgbm90IHN0YXJ0IHNlbmRpbmcgZGF0YSB1bnRpbCB5b3UgaGF2 ZSByZWdhaW5lZCBjb25zZW50LCBzaW1pbGFyIHRvIHdoZW4gdGhlIHNlc3Npb24gd2FzIGVzdGFi bGlzaGVkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQ aG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IE11dGh1IEFydWwg TW96aGkgUGVydW1hbDxtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20+DQpTZW50OiDigI4xOS/i gI4wNi/igI4yMDE1IDIxOjE5DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBNYXJ0aW4gVGhvbXNvbjxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPjsgQmVybmFyZCBBYm9iYTxtYWlsdG86YmVybmFyZC5hYm9iYUBn bWFpbC5jb20+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0DQpCdXQgdGhl cmUgd291bGQgc3RpbGwgYmUgbG9zcyBvZiBhcHBsaWNhdGlvbiBkYXRhIGZvciBhdCBsZWFzdCBv bmUgUlRUIGJlZm9yZSBjb25zZW50IGNhbiBiZSByZWdhaW5lZC4gV291bGQgdGhhdCBiZSBkZXZh c3RhdGluZyBmb3IgdmlkZW8gaWYgdGhlIGluaXRpYWwgcGFja2V0cyBzZW50IGFmdGVyIHJlc3Vt cHRpb24gY29udGFpbmVkIHRoZSBJLWZyYW1lIChmb3IgZS5nLCB0aGUgdXNlciB0dXJucyBvZmYg dGhlIGNhbWVyYSBhbmQgdHVybnMgaXQgb24gYWZ0ZXIgYSBtaW51dGUpPw0KDQpNdXRodQ0KDQpP biBGcmksIEp1biAxOSwgMjAxNSBhdCAxMTowNiBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPj4gd3JvdGU6DQpIaSwNCg0KWW91IHJlLW9idGFpbiBjb25zZW50IHVzaW5nIFNUVU4u DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTWFydGluIFRob21zb248bWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NClNlbnQ6IOKAjjE5L+KAjjA2L+KAjjIwMTUg MjA6MjUNClRvOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPg0KQ2M6IE11dGh1IEFydWwgTW96aGkgUGVydW1hbDxtYWlsdG86bXV0aHUuYXJ1 bEBnbWFpbC5jb20+OyBCZXJuYXJkIEFib2JhPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNv bT47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtydGN3ZWJdIENvbW1lbnQgb24gY29uc2VudC1mcmVzaG5lc3MtMTQNCk9uIDE5IEp1bmUgMjAx NSBhdCAxMDoyMCwgQ2hyaXN0ZXIgSG9sbWJlcmcNCjxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KPiAi V2hlbiB0aGUgZW5kcG9pbnQgd2FudHMgdG8gc3RhcnQgc2VuZGluZyBkYXRhIGFnYWluLCBpdCBm aXJzdCBuZWVkcyB0byByZS1vYnRhaW4NCj4gY29uc2VudCwgc28gaXQgc3RhcnRzIHRoZSBzZW5k aW5nIG9mIGNvbnNlbnQgcmVxdWVzdHMgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzIGluIHRo aXMgZG9jdW1lbnQNCj4gKHRoZSBlbmRwb2ludCBkb2VzIG5vdCBuZWVkIHRvIHBlcmZvcm0gSUNF IHJlc3RhcnQgaW4gdGhpcyBjYXNlKS4iDQoNCg0KUGFja2V0IGxvc3MgaXMgZ29pbmcgdG8gYmUg ZGV2YXN0YXRpbmcgdG8gcGVyZm9ybWFuY2UgaWYgeW91IGp1c3QNCnN0YXJ0IGNoZWNraW5nIGFn YWluLiAgU2hvdWxkIHdlIGFsc28gcmVjb21tZW5kIChvciBhbGxvdykgdGhlIHVzZSBvZg0KYSBT VFVOIHRyYW5zYWN0aW9uIHRvIHJlZ2FpbiBjb25zZW50Pw0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D8F3D49ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ JiM0MzsxIHRvIGV2ZXJ5dGhpbmcgQmVybmFyZCBzYWlkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SXQgaXMgcGVyZmVjdGx5IG9rIHRvIG1haW50YWluIGNvbnNlbnQs IGV2ZW4gaWYgbm8gYXBwbGljYXRpb24gZGF0YSBpcyBzZW50LCBlLmcuIGlmIHlvdSB3YW50IHRv IGhhdmUgYSDigJxob3Qgc3RhbmRieeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCZXJuYXJkIEFib2JhIFttYWlsdG86YmVybmFyZC5hYm9i YUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjAgSnVuZSAyMDE1IDA3OjU5PGJyPg0K PGI+VG86PC9iPiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8YnI+DQo8Yj5DYzo8L2I+IENocmlz dGVyIEhvbG1iZXJnOyBNYXJ0aW4gVGhvbXNvbjsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIENvbW1lbnQgb24gY29uc2VudC1mcmVzaG5l c3MtMTQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UGVyc29uYWxseSwgSSdtIGZpbmUgd2l0aCByZXF1aXJpbmcgdGhhdCBjb25zZW50IGJlIHJl Z2FpbmVkIGJlZm9yZSBzZW5kaW5nLiAmbmJzcDtUaGlzIG5lZWQgbm90IGV4YWN0IGEgcGVyZm9y bWFuY2UgcGVuYWx0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gbWFrZSBiZWZvcmUgYnJlYWsgc2NlbmFyaW9zLCBjb25zZW50IGNhbiBi ZSByZWdhaW5lZCBmaXJzdCBpbiB0aGUgYmFja2dyb3VuZCBiZWZvcmUgZGF0YSBpcyBzd2l0Y2hl ZCBvdmVyIHRvIHRoZSByZXZpdmVkIGNhbmRpZGF0ZSBwYWlyLCBzbyBubyBidWZmZXJpbmcgaXMg bmVlZGVkLiBJZiB0aGVyZSBpcyBhIGRlc2lyZSB0byBoYXZlIGEgJnF1b3Q7aG90IHN0YW5kYnkm cXVvdDsgc28gYXMgdG8gYXZvaWQgYnVmZmVyaW5nDQogaW4gYnJlYWsgYmVmb3JlIG1ha2UsJm5i c3A7dGhlbiBjb25zZW50IGNhbiBiZSBjb250aW51ZWQgZXZlbiB3aGVuIG5vIGRhdGEgaXMgYmVp bmcgc2VudCAod2hhdCBKdXN0aW4ncyBub21iaXMgZHJhZnQgcHJvcG9zZXMpLiAmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SG93ZXZlciBJIGRvIG5vdCBzZWUgdGhlIG5lZWQgdG8gbWFuZGF0ZSBjb25zZW50IGZvciBwYWly cyBvdmVyIHdoaWNoIG5vIGRhdGEgaXMgc2VudCBpbiB0aGlzIGRvY3VtZW50LiBMZXQgdXMgbGVh dmUgdGhhdCBkZWNpc2lvbiB0byBmdXR1cmUgZG9jdW1lbnRzIGluIE1NVVNJQyBXRy4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiBKdW4gMTksIDIwMTUsIGF0IDEwOjEx IFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgJmx0OzxhIGhyZWY9Im1haWx0bzptdXRodS5h cnVsQGdtYWlsLmNvbSI+bXV0aHUuYXJ1bEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+QnV0IHVubGVzcyB0aGUgYXBwbGljYXRpb24gc3RhcnRzIHNlbmRpbmcgZGF0YSwgY29uc2Vu dCB3aWxsIG5vdCBiZSByZWdhaW5lZCwgc28gaXQgaXMgYSBjaGlja2VuLWFuZC1lZ2cgcHJvYmxl bSAtOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPlNvbWUgb2YgdGhlIHBvc3NpYmxlIHNvbHV0aW9uczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LSBJQ0UgcmVzdGFy dCAtLSB0b28gbXVjaCBvZiBvdmVyaGVhZCBhbmQgcG9zc2libGUgTy9BIHJhY2UgY29uZGl0aW9u cywgZG9uJ3QgbGlrZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+LSBFbmRwb2ludCBidWZmZXJzIHRoZSBhcHBsaWNhdGlvbiBkYXRhIHRp bGwgY29uc2VudCBpcyByZWdhaW5lZCAtLSBrbHVnZSwgZG9uJ3QgbGlrZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LSBBbGxvdyB0aGUg ZW5kcG9pbnQgdG8gcmVzdW1lIHNlbmRpbmcgYXBwbGljYXRpb24gZGF0YSB1c2luZyB0aGUgY29u c2VudCBpdCBoYWQgd2hlbiBpdCBzdG9wcGVkIHNlbmRpbmcgLS0gY291bGQgb3BlbiBhIGJhY2tk b29yLCBzdGlsbCBkb24ndCBsaWtlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tIEtlZXAgbWFpbnRhaW5pbmcgY29uc2VudCBpcnJlc3Bl Y3RpdmUgb2Ygd2hldGhlciBhcHBsaWNhdGlvbiBkYXRhIGlzIHNlbnQgb3Igbm90IC0tIHNpbXBs ZSwgc2VydmVzIGFzIGEgaGVhcnRiZWF0IGluIHRoZSBhYnNlbmNlIG9mIGFwcGxpY2F0aW9uIGRh dGEsIGhlbHBzIHRvIGtlZXAgTkFUIGJpbmRpbmdzIGFsaXZlIGFuZCBoZWxwcw0KIHRvIHJlZmlu ZSBSVFQuIFRoZSB0cmFkZSBvZmYgaXMgc29tZSBuZXR3b3JrIGJhbmR3aWR0aCwgYnV0IEkgdGhp bmsgaXQgaXMgaW5zaWduaWZpY2FudCAoc29tZSBrZWVwYWxpdmVzIHdvdWxkIGJlIHNlbnQgYW55 d2F5KSwgc28gbGlrZSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk11dGh1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBKdW4gMjAsIDIwMTUgYXQgMTI6MTcg QU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSw8 YnI+DQo8YnI+DQpJbiBvcmRlciB0byBhdm9pZCBsb3NzIG9mIGRhdGEsIHlvdSBzaGFsbCBub3Qg c3RhcnQgc2VuZGluZyBkYXRhIHVudGlsIHlvdSBoYXZlIHJlZ2FpbmVkIGNvbnNlbnQsIHNpbWls YXIgdG8gd2hlbiB0aGUgc2Vzc2lvbiB3YXMgZXN0YWJsaXNoZWQuPGJyPg0KPGJyPg0KUmVnYXJk cyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dzIFBo b25lPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+ DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWls dG86bXV0aHUuYXJ1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5NdXRodSBBcnVsIE1vemhp IFBlcnVtYWw8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VudDogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKAjjE5L+KAjjA2L+KAjjIwMTUgMjE6MTk8L3NwYW4+PGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxh IGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2Js YW5rIj5DaHJpc3RlciBIb2xtYmVyZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5DYzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5NYXJ0aW4gVGhvbXNvbjwvYT47DQo8 YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5C ZXJuYXJkIEFib2JhPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KcnRjd2ViQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlN1YmplY3Q6IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlOiBbcnRjd2Vi XSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+QnV0IHRoZXJl IHdvdWxkIHN0aWxsIGJlIGxvc3Mgb2YgYXBwbGljYXRpb24gZGF0YSBmb3IgYXQgbGVhc3Qgb25l IFJUVCBiZWZvcmUgY29uc2VudCBjYW4gYmUgcmVnYWluZWQuIFdvdWxkIHRoYXQgYmUgZGV2YXN0 YXRpbmcgZm9yIHZpZGVvIGlmIHRoZSBpbml0aWFsIHBhY2tldHMgc2VudCBhZnRlciByZXN1bXB0 aW9uIGNvbnRhaW5lZA0KIHRoZSBJLWZyYW1lIChmb3IgZS5nLCB0aGUgdXNlciB0dXJucyBvZmYg dGhlIGNhbWVyYSBhbmQgdHVybnMgaXQgb24gYWZ0ZXIgYSBtaW51dGUpPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TXV0aHU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG cmksIEp1biAxOSwgMjAxNSBhdCAxMTowNiBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhy ZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5r Ij5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSw8YnI+DQo8YnI+DQpZb3UgcmUtb2J0YWlu IGNvbnNlbnQgdXNpbmcgU1RVTi48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlz dGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0 aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOg0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5NYXJ0aW4gVGhvbXNvbjwvYT48L3NwYW4+PGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5TZW50OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCO MTkv4oCOMDYv4oCOMjAxNSAyMDoyNTwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRv OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdGVyIEhvbG1iZXJnPC9h Pjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNjOiA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpiZXJu YXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkJlcm5hcmQgQWJvYmE8L2E+OyA8 YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGN3ZWJA aWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDogPC9z cGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmU6IFtydGN3ZWJdIENvbW1lbnQgb24gY29uc2Vu dC1mcmVzaG5lc3MtMTQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPk9uIDE5IEp1bmUgMjAxNSBhdCAxMDoyMCwgQ2hyaXN0ZXIgSG9sbWJlcmc8 YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDsgJnF1b3Q7V2hlbiB0aGUgZW5kcG9pbnQgd2FudHMgdG8gc3RhcnQgc2Vu ZGluZyBkYXRhIGFnYWluLCBpdCBmaXJzdCBuZWVkcyB0byByZS1vYnRhaW48YnI+DQomZ3Q7IGNv bnNlbnQsIHNvIGl0IHN0YXJ0cyB0aGUgc2VuZGluZyBvZiBjb25zZW50IHJlcXVlc3RzIGFjY29y ZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbiB0aGlzIGRvY3VtZW50PGJyPg0KJmd0OyAodGhlIGVu ZHBvaW50IGRvZXMgbm90IG5lZWQgdG8gcGVyZm9ybSBJQ0UgcmVzdGFydCBpbiB0aGlzIGNhc2Up LiZxdW90Ozxicj4NCjxicj4NCjxicj4NClBhY2tldCBsb3NzIGlzIGdvaW5nIHRvIGJlIGRldmFz dGF0aW5nIHRvIHBlcmZvcm1hbmNlIGlmIHlvdSBqdXN0PGJyPg0Kc3RhcnQgY2hlY2tpbmcgYWdh aW4uJm5ic3A7IFNob3VsZCB3ZSBhbHNvIHJlY29tbWVuZCAob3IgYWxsb3cpIHRoZSB1c2Ugb2Y8 YnI+DQphIFNUVU4gdHJhbnNhY3Rpb24gdG8gcmVnYWluIGNvbnNlbnQ/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D8F3D49ESESSMB209erics_-- From nobody Sat Jun 20 02:13:29 2015 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 106AD1A007D for ; Sat, 20 Jun 2015 02:13:28 -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 v-ZXupN0VEcI for ; Sat, 20 Jun 2015 02:13:26 -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 061BC1A0074 for ; Sat, 20 Jun 2015 02:13:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-21-55852eb2ec4a Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0D.BE.28096.2BE25855; Sat, 20 Jun 2015 11:13:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0210.002; Sat, 20 Jun 2015 11:13:22 +0200 From: Christer Holmberg To: Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAArlwA///Qu4AAB/fzAAAElIFWAAKqG4AAACs3VgAK9UgA//9pcbA= Date: Sat, 20 Jun 2015 09:13:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F3D8F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2A54@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> 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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F3D8FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3VneTXmuowZKzNhYb9v1ntrh25h+j xZ/NfhZr/7WzO7B47Jx1l91jyZKfTAFMUVw2Kak5mWWpRfp2CVwZvx7VFDxbwlhx51F2A+OW BYxdjJwcEgImEl9aP7JA2GISF+6tZ+ti5OIQEjjKKDFh7w92kISQwGJGieWfPLsYOTjYBCwk uv9pg4RFBIwltrT8YgWxmQVqJS5Nuwo2U1jAVGLN5TnMEDVmEq1nZ7JC2PMYJU4dcQSxWQRU JY6s+QS2l1fAV2LZ12ssEHvbOCUOv33MBpLgFAiUaGv4D1bECHTc91NrmCCWiUvcejKfCeJo AYkle84zQ9iiEi8f/2OFsJUkGpc8gTouX+LkpW+sEMsEJU7OfMIygVF0FpJRs5CUzUJSNgvo ZWYBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7Vk EyMw/g5u+W21g/Hgc8dDjAIcjEo8vAonW0KFWBPLiitzDzFKc7AoifPO2JwXKiSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFxwayke0rP9P/eddtUbadm/VljyZaau2Udvdf2/219xnjm3A/2 dxNWxLwuO33TV+j/bLetWyZNPLDM/MzkP4Fc05Q29DJ8at1xQkv++t3fLbMe3Q1ZYpJzbWNz CINIm+ra5pjHf9YmcJpYH7Zek/z5oszs2cHrHq14EXPp0Qk1Vd2z7bqzBMveBCixFGckGmox FxUnAgCFNYTZoAIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 09:13:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F3D8FESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5CdXQgdW5sZXNzIHRoZSBhcHBsaWNhdGlvbiBzdGFydHMgc2VuZGluZyBkYXRhLCBj b25zZW50IHdpbGwgbm90IGJlIHJlZ2FpbmVkLCBzbyBpdCBpcyBhIGNoaWNrZW4tYW5kLWVnZyBw cm9ibGVtIC06KQ0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZC4gWW91IGFsd2F5cyBoYXZlIHRvIChy ZSlnYWluIGNvbnNlbnQsIHVzaW5nIFNUVU4sIGJlZm9yZSB5b3Ugc2VuZCBhcHBsaWNhdGlvbiBk YXRhLiBUaGF04oCZcyB0aGUgd2hvbGUgaWRlYSBvZiB0aGUgbWVjaGFuaXNtLCBhbmQgbm90aGlu ZyB0aGF0IGhhcyBiZWVuIHN1Z2dlc3RlZCBoZXJlIGNoYW5nZXMgdGhhdC4NCg0KQW5kLCBhcyBC ZXJuYXJkIHNhaWQsIGl0IGlzIG9rIHRvIG1haW50YWluIGEg4oCcaG90IHN0YW5kYnnigJ0uIE9y LCBpZiB5b3Uga25vdyB0aGF0IHlvdSBhcmUgZ29pbmcgdG8gc3RhcnQgc2VuZGluZyBhcHBsaWNh dGlvbiBkYXRhIG9uIGEgbmV3IGNhbmRpZGF0ZSBwYWlyLCB5b3UgY2FuIHJlZ2FpbiBjb25zZW50 IHdoaWxlIHN0aWxsIHNlbmRpbmcgYXBwbGljYXRpb24gZGF0YSBvbiB0aGUgcHJldmlvdXMgY2Fu ZGlkYXRlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTb21lIG9mIHRoZSBwb3NzaWJsZSBz b2x1dGlvbnM6DQotIElDRSByZXN0YXJ0IC0tIHRvbyBtdWNoIG9mIG92ZXJoZWFkIGFuZCBwb3Nz aWJsZSBPL0EgcmFjZSBjb25kaXRpb25zLCBkb24ndCBsaWtlLg0KLSBFbmRwb2ludCBidWZmZXJz IHRoZSBhcHBsaWNhdGlvbiBkYXRhIHRpbGwgY29uc2VudCBpcyByZWdhaW5lZCAtLSBrbHVnZSwg ZG9uJ3QgbGlrZS4NCi0gQWxsb3cgdGhlIGVuZHBvaW50IHRvIHJlc3VtZSBzZW5kaW5nIGFwcGxp Y2F0aW9uIGRhdGEgdXNpbmcgdGhlIGNvbnNlbnQgaXQgaGFkIHdoZW4gaXQgc3RvcHBlZCBzZW5k aW5nIC0tIGNvdWxkIG9wZW4gYSBiYWNrZG9vciwgc3RpbGwgZG9uJ3QgbGlrZS4NCi0gS2VlcCBt YWludGFpbmluZyBjb25zZW50IGlycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIGFwcGxpY2F0aW9uIGRh dGEgaXMgc2VudCBvciBub3QgLS0gc2ltcGxlLCBzZXJ2ZXMgYXMgYSBoZWFydGJlYXQgaW4gdGhl IGFic2VuY2Ugb2YgYXBwbGljYXRpb24gZGF0YSwgaGVscHMgdG8ga2VlcCBOQVQgYmluZGluZ3Mg YWxpdmUgYW5kIGhlbHBzIHRvIHJlZmluZSBSVFQuIFRoZSB0cmFkZSBvZmYgaXMgc29tZSBuZXR3 b3JrIGJhbmR3aWR0aCwgYnV0IEkgdGhpbmsgaXQgaXMgaW5zaWduaWZpY2FudCAoc29tZSBrZWVw YWxpdmVzIHdvdWxkIGJlIHNlbnQgYW55d2F5KSwgc28gbGlrZSBpdC4NCg0KTXV0aHUNCg0KT24g U2F0LCBKdW4gMjAsIDIwMTUgYXQgMTI6MTcgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4+IHdyb3RlOg0KSGksDQoNCkluIG9yZGVyIHRvIGF2b2lkIGxvc3Mgb2YgZGF0YSwgeW91 IHNoYWxsIG5vdCBzdGFydCBzZW5kaW5nIGRhdGEgdW50aWwgeW91IGhhdmUgcmVnYWluZWQgY29u c2VudCwgc2ltaWxhciB0byB3aGVuIHRoZSBzZXNzaW9uIHdhcyBlc3RhYmxpc2hlZC4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmUNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8 bWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tPg0KU2VudDog4oCOMTkv4oCOMDYv4oCOMjAxNSAy MToxOQ0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+DQpDYzogTWFydGluIFRob21zb248bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbT47IEJlcm5hcmQgQWJvYmE8bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPjsgcnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gQ29tbWVudCBvbiBjb25zZW50LWZyZXNobmVzcy0xNA0KQnV0IHRoZXJlIHdvdWxkIHN0aWxs IGJlIGxvc3Mgb2YgYXBwbGljYXRpb24gZGF0YSBmb3IgYXQgbGVhc3Qgb25lIFJUVCBiZWZvcmUg Y29uc2VudCBjYW4gYmUgcmVnYWluZWQuIFdvdWxkIHRoYXQgYmUgZGV2YXN0YXRpbmcgZm9yIHZp ZGVvIGlmIHRoZSBpbml0aWFsIHBhY2tldHMgc2VudCBhZnRlciByZXN1bXB0aW9uIGNvbnRhaW5l ZCB0aGUgSS1mcmFtZSAoZm9yIGUuZywgdGhlIHVzZXIgdHVybnMgb2ZmIHRoZSBjYW1lcmEgYW5k IHR1cm5zIGl0IG9uIGFmdGVyIGEgbWludXRlKT8NCg0KTXV0aHUNCg0KT24gRnJpLCBKdW4gMTks IDIwMTUgYXQgMTE6MDYgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3Rl Og0KSGksDQoNCllvdSByZS1vYnRhaW4gY29uc2VudCB1c2luZyBTVFVOLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IE1hcnRpbiBUaG9tc29uPG1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+DQpTZW50OiDigI4xOS/igI4wNi/igI4yMDE1IDIwOjI1DQpUbzogQ2hy aXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNj OiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8bWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tPjsg QmVybmFyZCBBYm9iYTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+OyBydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDb21t ZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0DQpPbiAxOSBKdW5lIDIwMTUgYXQgMTA6MjAsIENo cmlzdGVyIEhvbG1iZXJnDQo8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCj4gIldoZW4gdGhlIGVuZHBv aW50IHdhbnRzIHRvIHN0YXJ0IHNlbmRpbmcgZGF0YSBhZ2FpbiwgaXQgZmlyc3QgbmVlZHMgdG8g cmUtb2J0YWluDQo+IGNvbnNlbnQsIHNvIGl0IHN0YXJ0cyB0aGUgc2VuZGluZyBvZiBjb25zZW50 IHJlcXVlc3RzIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbiB0aGlzIGRvY3VtZW50DQo+ ICh0aGUgZW5kcG9pbnQgZG9lcyBub3QgbmVlZCB0byBwZXJmb3JtIElDRSByZXN0YXJ0IGluIHRo aXMgY2FzZSkuIg0KDQoNClBhY2tldCBsb3NzIGlzIGdvaW5nIHRvIGJlIGRldmFzdGF0aW5nIHRv IHBlcmZvcm1hbmNlIGlmIHlvdSBqdXN0DQpzdGFydCBjaGVja2luZyBhZ2Fpbi4gIFNob3VsZCB3 ZSBhbHNvIHJlY29tbWVuZCAob3IgYWxsb3cpIHRoZSB1c2Ugb2YNCmEgU1RVTiB0cmFuc2FjdGlv biB0byByZWdhaW4gY29uc2VudD8NCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D8F3D8FESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O0J1dCB1bmxlc3MgdGhlIGFw cGxpY2F0aW9uIHN0YXJ0cyBzZW5kaW5nIGRhdGEsIGNvbnNlbnQgd2lsbCBub3QgYmUgcmVnYWlu ZWQsIHNvIGl0IGlzIGEgY2hpY2tlbi1hbmQtZWdnIHByb2JsZW0gLTopPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBk b27igJl0IHVuZGVyc3RhbmQuIFlvdSBhbHdheXMgaGF2ZSB0byAocmUpZ2FpbiBjb25zZW50LCB1 c2luZyBTVFVOLCBiZWZvcmUgeW91IHNlbmQgYXBwbGljYXRpb24gZGF0YS4gVGhhdOKAmXMgdGhl IHdob2xlIGlkZWEgb2YgdGhlIG1lY2hhbmlzbSwgYW5kIG5vdGhpbmcgdGhhdCBoYXMgYmVlbiBz dWdnZXN0ZWQNCiBoZXJlIGNoYW5nZXMgdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kLCBhcyBCZXJu YXJkIHNhaWQsIGl0IGlzIG9rIHRvIG1haW50YWluIGEg4oCcaG90IHN0YW5kYnnigJ0uIE9yLCBp ZiB5b3Uga25vdyB0aGF0IHlvdSBhcmUgZ29pbmcgdG8gc3RhcnQgc2VuZGluZyBhcHBsaWNhdGlv biBkYXRhIG9uIGEgbmV3IGNhbmRpZGF0ZSBwYWlyLCB5b3UgY2FuIHJlZ2FpbiBjb25zZW50DQog d2hpbGUgc3RpbGwgc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhIG9uIHRoZSBwcmV2aW91cyBjYW5k aWRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+U29tZSBvZiB0aGUgcG9zc2libGUgc29sdXRpb25zOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tIElDRSByZXN0YXJ0IC0t IHRvbyBtdWNoIG9mIG92ZXJoZWFkIGFuZCBwb3NzaWJsZSBPL0EgcmFjZSBjb25kaXRpb25zLCBk b24ndCBsaWtlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4tIEVuZHBvaW50IGJ1ZmZlcnMgdGhlIGFwcGxpY2F0aW9uIGRhdGEgdGlsbCBj b25zZW50IGlzIHJlZ2FpbmVkIC0tIGtsdWdlLCBkb24ndCBsaWtlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tIEFsbG93IHRoZSBlbmRw b2ludCB0byByZXN1bWUgc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhIHVzaW5nIHRoZSBjb25zZW50 IGl0IGhhZCB3aGVuIGl0IHN0b3BwZWQgc2VuZGluZyAtLSBjb3VsZCBvcGVuIGEgYmFja2Rvb3Is IHN0aWxsIGRvbid0IGxpa2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPi0gS2VlcCBtYWludGFpbmluZyBjb25zZW50IGlycmVzcGVjdGl2 ZSBvZiB3aGV0aGVyIGFwcGxpY2F0aW9uIGRhdGEgaXMgc2VudCBvciBub3QgLS0gc2ltcGxlLCBz ZXJ2ZXMgYXMgYSBoZWFydGJlYXQgaW4gdGhlIGFic2VuY2Ugb2YgYXBwbGljYXRpb24gZGF0YSwg aGVscHMgdG8ga2VlcCBOQVQgYmluZGluZ3MgYWxpdmUgYW5kIGhlbHBzDQogdG8gcmVmaW5lIFJU VC4gVGhlIHRyYWRlIG9mZiBpcyBzb21lIG5ldHdvcmsgYmFuZHdpZHRoLCBidXQgSSB0aGluayBp dCBpcyBpbnNpZ25pZmljYW50IChzb21lIGtlZXBhbGl2ZXMgd291bGQgYmUgc2VudCBhbnl3YXkp LCBzbyBsaWtlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+TXV0aHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIEp1biAyMCwgMjAxNSBhdCAxMjoxNyBBTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDxicj4N Cjxicj4NCkluIG9yZGVyIHRvIGF2b2lkIGxvc3Mgb2YgZGF0YSwgeW91IHNoYWxsIG5vdCBzdGFy dCBzZW5kaW5nIGRhdGEgdW50aWwgeW91IGhhdmUgcmVnYWluZWQgY29uc2VudCwgc2ltaWxhciB0 byB3aGVuIHRoZSBzZXNzaW9uIHdhcyBlc3RhYmxpc2hlZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxi cj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxo ciBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzpt dXRodS5hcnVsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk11dGh1IEFydWwgTW96aGkgUGVy dW1hbDwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW50OiA8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+4oCOMTkv4oCOMDYv4oCOMjAxNSAyMToxOTwvc3Bhbj48YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRvOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJl Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PkNocmlzdGVyIEhvbG1iZXJnPC9hPjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNj OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1hcnRpbiBUaG9tc29uPC9hPjsNCjxhIGhy ZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkJlcm5h cmQgQWJvYmE8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+U3ViamVjdDogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmU6IFtydGN3ZWJdIENv bW1lbnQgb24gY29uc2VudC1mcmVzaG5lc3MtMTQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5CdXQgdGhlcmUgd291 bGQgc3RpbGwgYmUgbG9zcyBvZiBhcHBsaWNhdGlvbiBkYXRhIGZvciBhdCBsZWFzdCBvbmUgUlRU IGJlZm9yZSBjb25zZW50IGNhbiBiZSByZWdhaW5lZC4gV291bGQgdGhhdCBiZSBkZXZhc3RhdGlu ZyBmb3IgdmlkZW8gaWYgdGhlIGluaXRpYWwgcGFja2V0cyBzZW50IGFmdGVyIHJlc3VtcHRpb24g Y29udGFpbmVkDQogdGhlIEktZnJhbWUgKGZvciBlLmcsIHRoZSB1c2VyIHR1cm5zIG9mZiB0aGUg Y2FtZXJhIGFuZCB0dXJucyBpdCBvbiBhZnRlciBhIG1pbnV0ZSk/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5NdXRodTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwg SnVuIDE5LCAyMDE1IGF0IDExOjA2IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDxicj4NCjxicj4NCllvdSByZS1vYnRhaW4gY29u c2VudCB1c2luZyBTVFVOLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8 YnI+DQo8YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0i Y2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjMiIHdpZHRoPSIx MDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206DQo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1hcnRpbiBUaG9tc29uPC9hPjwvc3Bhbj48YnI+DQo8Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlNlbnQ6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igI4xOS/i gI4wNi/igI4yMDE1IDIwOjI1PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG86IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Q2hyaXN0ZXIgSG9sbWJlcmc8L2E+PC9z cGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48YSBocmVmPSJtYWlsdG86bXV0aHUuYXJ1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5NdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQu YWJvYmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+QmVybmFyZCBBYm9iYTwvYT47IDxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dlYkBpZXRm Lm9yZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdWJqZWN0OiA8L3NwYW4+ DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZTogW3J0Y3dlYl0gQ29tbWVudCBvbiBjb25zZW50LWZy ZXNobmVzcy0xNDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+T24gMTkgSnVuZSAyMDE1IGF0IDEwOjIwLCBDaHJpc3RlciBIb2xtYmVyZzxicj4N CiZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyAmcXVvdDtXaGVuIHRoZSBlbmRwb2ludCB3YW50cyB0byBzdGFydCBzZW5kaW5n IGRhdGEgYWdhaW4sIGl0IGZpcnN0IG5lZWRzIHRvIHJlLW9idGFpbjxicj4NCiZndDsgY29uc2Vu dCwgc28gaXQgc3RhcnRzIHRoZSBzZW5kaW5nIG9mIGNvbnNlbnQgcmVxdWVzdHMgYWNjb3JkaW5n IHRvIHRoZSBwcm9jZWR1cmVzIGluIHRoaXMgZG9jdW1lbnQ8YnI+DQomZ3Q7ICh0aGUgZW5kcG9p bnQgZG9lcyBub3QgbmVlZCB0byBwZXJmb3JtIElDRSByZXN0YXJ0IGluIHRoaXMgY2FzZSkuJnF1 b3Q7PGJyPg0KPGJyPg0KPGJyPg0KUGFja2V0IGxvc3MgaXMgZ29pbmcgdG8gYmUgZGV2YXN0YXRp bmcgdG8gcGVyZm9ybWFuY2UgaWYgeW91IGp1c3Q8YnI+DQpzdGFydCBjaGVja2luZyBhZ2Fpbi4m bmJzcDsgU2hvdWxkIHdlIGFsc28gcmVjb21tZW5kIChvciBhbGxvdykgdGhlIHVzZSBvZjxicj4N CmEgU1RVTiB0cmFuc2FjdGlvbiB0byByZWdhaW4gY29uc2VudD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D8F3D8FESESSMB209erics_-- From nobody Sat Jun 20 03:49:43 2015 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 7A5FB1A1A17 for ; Sat, 20 Jun 2015 03:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 VQpabX8P6Pal for ; Sat, 20 Jun 2015 03:49:40 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 242001A1A15 for ; Sat, 20 Jun 2015 03:49:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 91C5C7C0E5A for ; Sat, 20 Jun 2015 12:49:38 +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 6mSTy3CzM7h9 for ; Sat, 20 Jun 2015 12:49:37 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:5c39:1efd:cc8b:728e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4EBB77C0E2F for ; Sat, 20 Jun 2015 12:49:37 +0200 (CEST) Message-ID: <55854540.3030300@alvestrand.no> Date: Sat, 20 Jun 2015 12:49:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D8F35F9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F35F9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] nombis and ICE restart [was: Comment on consent-freshness-14] 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, 20 Jun 2015 10:49:42 -0000 On 06/19/2015 06:15 PM, Christer Holmberg wrote: > (Changed the subject, because ICE restart with nombis is not related to consent-freshness) > > Hi, > >>> In recent moons people have been talking about never finalizing ICE, instead you will keep collecting candidates throughout the session, and >>> switch between them if one is "better" than that other. You may drop some candidates, and you may maintain others (even though you are >>> currently not sending any data on them) >> [BA] A specific proposal is here: >> https://tools.ietf.org/html/draft-uberti-mmusic-nombis > Correct, I forgot to include the link. > >>> That brings up a question, though: if you never finalize ICE, will you ever be able to do an ICE restart? >> ICE can always be restarted, whether media is currently flowing or not. > Sure, but my question was more general whether you can do ICE restart if you use nombis. > > When reading the nombis draft, it does say that you can perform an ICE restart. But, is there any reason for doing it, as you can simply continue collecting new candidates (and drop the ones you don't want to use anymore, I assume) using "normal nombis behaviour"? If you believe the ICE credentials at the other end have been lost or compromised, or if you've lost your own ICE credentials (relevant in the rehydration case, if rehydration is possible to do), an ICE restart is a Good Thing. With nombis, losing the connection should not be a reason to do an ICE restart. From nobody Sat Jun 20 03:53:57 2015 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 9D1E41A1A28 for ; Sat, 20 Jun 2015 03:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 FDzEo_BuQrQg for ; Sat, 20 Jun 2015 03:53:53 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id D076C1A1A25 for ; Sat, 20 Jun 2015 03:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id AD3477C0E5A for ; Sat, 20 Jun 2015 12:53:51 +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 17AgaDVXFwkF for ; Sat, 20 Jun 2015 12:53:49 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:5c39:1efd:cc8b:728e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 149C57C0E2F for ; Sat, 20 Jun 2015 12:53:49 +0200 (CEST) Message-ID: <5585463C.5030005@alvestrand.no> Date: Sat, 20 Jun 2015 12:53:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> In-Reply-To: <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> Content-Type: multipart/alternative; boundary="------------040700080204070307010809" Archived-At: Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 10:53:55 -0000 This is a multi-part message in MIME format. --------------040700080204070307010809 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06/20/2015 06:58 AM, Bernard Aboba wrote: > Personally, I'm fine with requiring that consent be regained before > sending. This need not exact a performance penalty. > > In make before break scenarios, consent can be regained first in the > background before data is switched over to the revived candidate pair, > so no buffering is needed. If there is a desire to have a "hot > standby" so as to avoid buffering in break before make, then consent > can be continued even when no data is being sent (what Justin's nombis > draft proposes). > > However I do not see the need to mandate consent for pairs over which > no data is sent in this document. Let us leave that decision to future > documents in MMUSIC WG. +1. It's currently technically unclear whether the advantages of running consent over "hot standby" candidate pairs (NATs stay up, consent is immediately and obviously available, continuous measurement of candiate pair performance) outweigh the disadvantages (overhead of running checks, need for picking sensible candidate pairs, risk of running useless hot standbys). The document should not attempt to legislate that one or the other way is right, it should permit experimentation. Engineering will show which one gets deployed; once it's clear that all the developers have picked one way to do it, we can standardize on that. > > > On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal > > wrote: > >> But unless the application starts sending data, consent will not be >> regained, so it is a chicken-and-egg problem -:) >> >> Some of the possible solutions: >> - ICE restart -- too much of overhead and possible O/A race >> conditions, don't like. >> - Endpoint buffers the application data till consent is regained -- >> kluge, don't like. >> - Allow the endpoint to resume sending application data using the >> consent it had when it stopped sending -- could open a backdoor, >> still don't like. >> - Keep maintaining consent irrespective of whether application data >> is sent or not -- simple, serves as a heartbeat in the absence of >> application data, helps to keep NAT bindings alive and helps to >> refine RTT. The trade off is some network bandwidth, but I think it >> is insignificant (some keepalives would be sent anyway), so like it. >> >> Muthu >> >> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg >> > > wrote: >> >> Hi, >> >> In order to avoid loss of data, you shall not start sending data >> until you have regained consent, similar to when the session was >> established. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------------------------------------------------ >> From: Muthu Arul Mozhi Perumal >> Sent: ‎19/‎06/‎2015 21:19 >> To: Christer Holmberg >> Cc: Martin Thomson ; Bernard >> Aboba ; rtcweb@ietf.org >> >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >> >> But there would still be loss of application data for at least >> one RTT before consent can be regained. Would that be devastating >> for video if the initial packets sent after resumption contained >> the I-frame (for e.g, the user turns off the camera and turns it >> on after a minute)? >> >> Muthu >> >> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg >> > > wrote: >> >> Hi, >> >> You re-obtain consent using STUN. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------------------------------------------------ >> From: Martin Thomson >> Sent: ‎19/‎06/‎2015 20:25 >> To: Christer Holmberg >> Cc: Muthu Arul Mozhi Perumal ; >> Bernard Aboba ; >> rtcweb@ietf.org >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >> >> On 19 June 2015 at 10:20, Christer Holmberg >> > > wrote: >> > "When the endpoint wants to start sending data again, it >> first needs to re-obtain >> > consent, so it starts the sending of consent requests >> according to the procedures in this document >> > (the endpoint does not need to perform ICE restart in this >> case)." >> >> >> Packet loss is going to be devastating to performance if you just >> start checking again. Should we also recommend (or allow) the >> use of >> a STUN transaction to regain consent? >> >> >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040700080204070307010809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 06/20/2015 06:58 AM, Bernard Aboba wrote:
Personally, I'm fine with requiring that consent be regained before sending.  This need not exact a performance penalty.

In make before break scenarios, consent can be regained first in the background before data is switched over to the revived candidate pair, so no buffering is needed. If there is a desire to have a "hot standby" so as to avoid buffering in break before make, then consent can be continued even when no data is being sent (what Justin's nombis draft proposes).  

However I do not see the need to mandate consent for pairs over which no data is sent in this document. Let us leave that decision to future documents in MMUSIC WG.

+1.

It's currently technically unclear whether the advantages of running consent over "hot standby" candidate pairs (NATs stay up, consent is immediately and obviously available, continuous measurement of candiate pair performance) outweigh the disadvantages (overhead of running checks, need for picking sensible candidate pairs, risk of running useless hot standbys).

The document should not attempt to legislate that one or the other way is right, it should permit experimentation. Engineering will show which one gets deployed; once it's clear that all the developers have picked one way to do it, we can standardize on that.



On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

But unless the application starts sending data, consent will not be regained, so it is a chicken-and-egg problem -:)

Some of the possible solutions:
- ICE restart -- too much of overhead and possible O/A race conditions, don't like.
- Endpoint buffers the application data till consent is regained -- kluge, don't like.
- Allow the endpoint to resume sending application data using the consent it had when it stopped sending -- could open a backdoor, still don't like.
- Keep maintaining consent irrespective of whether application data is sent or not -- simple, serves as a heartbeat in the absence of application data, helps to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is insignificant (some keepalives would be sent anyway), so like it.

Muthu

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

In order to avoid loss of data, you shall not start sending data until you have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Perumal
Sent: ‎19/‎06/‎2015 21:19
To: Christer Holmberg
Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [rtcweb] Comment on consent-freshness-14

But there would still be loss of application data for at least one RTT before consent can be regained. Would that be devastating for video if the initial packets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone
From: Martin Thomson
Sent: ‎19/‎06/‎2015 20:25
To: Christer Holmberg
Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [rtcweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first needs to re-obtain
> consent, so it starts the sending of consent requests according to the procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."


Packet loss is going to be devastating to performance if you just
start checking again.  Should we also recommend (or allow) the use of
a STUN transaction to regain consent?




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

--------------040700080204070307010809-- From nobody Sat Jun 20 04:40:15 2015 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 66BD51A1B39 for ; Sat, 20 Jun 2015 04:40:14 -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 cU8DqqvYGLeH for ; Sat, 20 Jun 2015 04:40:13 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788641A1B2E for ; Sat, 20 Jun 2015 04:40:12 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-1f-5585511a9b2e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3D.EA.04015.A1155855; Sat, 20 Jun 2015 13:40:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Sat, 20 Jun 2015 13:40:09 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] nombis and ICE restart [was: Comment on consent-freshness-14] Thread-Index: AQHQq0bUbAkqTLrz2UGWkNVkZAwnLZ21RIfQ Date: Sat, 20 Jun 2015 11:40:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F4195@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F35F9@ESESSMB209.ericsson.se> <55854540.3030300@alvestrand.no> In-Reply-To: <55854540.3030300@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvra5UYGuoQeMefYtjfV1sFmv/tbM7 MHlcmXCF1WPJkp9MAUxRXDYpqTmZZalF+nYJXBmrJhxmKzjPW3Fw7wvmBsaPXF2MnBwSAiYS i98dZoWwxSQu3FvP1sXIxSEkcJRR4tvpKywQzmJGiWnzTwNVcXCwCVhIdP/TBmkQEQiW6H3+ nhHEFhYIlfhz+g0bRDxM4tGXJ4wQtpHExutL2EFsFgFVifYZa8FqeAV8JZZMnMoCYgsJFEhM +fWFGcTmFNCVmDzvHFicEeig76fWMIHYzALiEreezGeCOFRAYsme88wQtqjEy8f/oB5Qkmhc 8oQVol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGEWLU4uT ctONjPRSizKTi4vz8/TyUks2MQLj5OCW3wY7GF8+dzzEKMDBqMTDq3CyJVSINbGsuDL3EKM0 B4uSOO+MzXmhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjtmp7eLJX+G7wl/22JZWn5j97b P519faUaTqZx5goYnZ1hOzErskIuc8WhRVe63fb1vlpvFiB8bKrw7SfRZc5x3E+b5u9zOFDS vVDqrmt80ipXB7nlXxKyTC/tVtn2+fC0szVPfp4v2u025dMkY8/F75Un67iU6M5bssJmb2jA YrtvJx6+F6lTYinOSDTUYi4qTgQAU99ajXQCAAA= Archived-At: Subject: Re: [rtcweb] nombis and ICE restart [was: Comment on consent-freshness-14] 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, 20 Jun 2015 11:40:14 -0000 Hi Harald, >> (Changed the subject, because ICE restart with nombis is not related=20 >> to consent-freshness) >> >> Hi, >> >>>> In recent moons people have been talking about never finalizing ICE,=20 >>>> instead you will keep collecting candidates throughout the session,=20 >>>> and switch between them if one is "better" than that other. You may=20 >>>> drop some candidates, and you may maintain others (even though you=20 >>>> are currently not sending any data on them) >>> [BA] A specific proposal is here: >>> https://tools.ietf.org/html/draft-uberti-mmusic-nombis >> Correct, I forgot to include the link. >> >>>> That brings up a question, though: if you never finalize ICE, will you= ever be able to do an ICE restart? >>> ICE can always be restarted, whether media is currently flowing or not. >> Sure, but my question was more general whether you can do ICE restart if= you use nombis. >> >> When reading the nombis draft, it does say that you can perform an ICE r= estart. But, is there any reason for doing it, as you can simply continue >= > collecting new candidates (and drop the ones you don't want to use anymor= e, I assume) using "normal nombis behaviour"? > > If you believe the ICE credentials at the other end have been lost or com= promised, or if you've lost your own ICE credentials (relevant in the=20 > rehydration case, if rehydration is possible to do), an ICE restart is a = Good Thing. > > With nombis, losing the connection should not be a reason to do an ICE re= start. I think it would be good to capture what you just said in the nombis draft,= e.g. in an "ICE Restart Considerations"/"To ICE Restart or not to ICE rest= art" section. Regards, Christer From nobody Sat Jun 20 08:14:47 2015 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 E97771A0430 for ; Sat, 20 Jun 2015 08:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 duWlb7jspQk4 for ; Sat, 20 Jun 2015 08:14:42 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id AFF811A1A56 for ; Sat, 20 Jun 2015 08:14:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A75417C3261; Sat, 20 Jun 2015 17:14:41 +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 PhOjkQxwHL_B; Sat, 20 Jun 2015 17:14:40 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:5c39:1efd:cc8b:728e]) by mork.alvestrand.no (Postfix) with ESMTPSA id 438F57C3257; Sat, 20 Jun 2015 17:14:40 +0200 (CEST) Message-ID: <5585835F.7060102@alvestrand.no> Date: Sat, 20 Jun 2015 17:14:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christer Holmberg , "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D8F35F9@ESESSMB209.ericsson.se> <55854540.3030300@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D8F4195@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F4195@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] nombis and ICE restart [was: Comment on consent-freshness-14] 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, 20 Jun 2015 15:14:45 -0000 On 06/20/2015 01:40 PM, Christer Holmberg wrote: > Hi Harald, > >>> (Changed the subject, because ICE restart with nombis is not related >>> to consent-freshness) >>> >>> Hi, >>> >>>>> In recent moons people have been talking about never finalizing ICE, >>>>> instead you will keep collecting candidates throughout the session, >>>>> and switch between them if one is "better" than that other. You may >>>>> drop some candidates, and you may maintain others (even though you >>>>> are currently not sending any data on them) >>>> [BA] A specific proposal is here: >>>> https://tools.ietf.org/html/draft-uberti-mmusic-nombis >>> Correct, I forgot to include the link. >>> >>>>> That brings up a question, though: if you never finalize ICE, will you ever be able to do an ICE restart? >>>> ICE can always be restarted, whether media is currently flowing or not. >>> Sure, but my question was more general whether you can do ICE restart if you use nombis. >>> >>> When reading the nombis draft, it does say that you can perform an ICE restart. But, is there any reason for doing it, as you can simply continue >> collecting new candidates (and drop the ones you don't want to use anymore, I assume) using "normal nombis behaviour"? >> If you believe the ICE credentials at the other end have been lost or compromised, or if you've lost your own ICE credentials (relevant in the >> rehydration case, if rehydration is possible to do), an ICE restart is a Good Thing. >> >> With nombis, losing the connection should not be a reason to do an ICE restart. > I think it would be good to capture what you just said in the nombis draft, e.g. in an "ICE Restart Considerations"/"To ICE Restart or not to ICE restart" section. Filed as https://github.com/juberti/draughts/issues/19 (the repo is still a private one). > > Regards, > > Christer > From nobody Sat Jun 20 11:56:04 2015 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 2BE8A1A905D for ; Sat, 20 Jun 2015 11:56:03 -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 FJFMNNPqlahL for ; Sat, 20 Jun 2015 11:56:01 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B531A9060 for ; Sat, 20 Jun 2015 11:56:00 -0700 (PDT) Received: by wicnd19 with SMTP id nd19so44468741wic.1 for ; Sat, 20 Jun 2015 11:55:59 -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=+oIamSgvRS2Hx0/kwOBShtLx8Pem4/egfTxvsQF0n9M=; b=PGyA9AWYcJEWcNxGSRN+gudkz7GK57X4LqjScMP4VVoZJx3T67CkaRE3PwmWCiMR7Q sINzUk+CqtyhNDUYllOWe/I+W+DLZtK9fuNKYIZbjCRBgOnHnOmtie4xN1S2Lp2sHpVz GOb1pwbQCkV17smbMPYs8AzGrKYVlu6uaNBrJ/ziNQP2yemKX51+/3e62fRghg3zevG8 PcLbTb66FbzSEnkdu5Y+iOowAo2Mc6mlbnNa5yc9wdtDeS3kR0qL0lEIwi5AA40ZRuc7 sXala/9ocXFMRo2YcFm7aK7/ldZxgCk20Xa1oZKgeCsle4DO8wHPA6QttcEORXyPId6g SVrg== MIME-Version: 1.0 X-Received: by 10.180.23.8 with SMTP id i8mr17627540wif.39.1434826559238; Sat, 20 Jun 2015 11:55:59 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Sat, 20 Jun 2015 11:55:59 -0700 (PDT) In-Reply-To: <5585463C.5030005@alvestrand.no> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> Date: Sun, 21 Jun 2015 00:25:59 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013d12ca60b7230518f797a4 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 18:56:03 -0000 --089e013d12ca60b7230518f797a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >But unless the application starts sending data, consent will not be > regained, so it is a chicken-and-egg problem -:) > > > > I don=E2=80=99t understand. You always have to (re)gain consent, using ST= UN, > before you send application data. That=E2=80=99s the whole idea of the me= chanism, > and nothing that has been suggested here changes that. > =E2=80=8B The question is, how would the browser know that the application is about to send data so that it can regain consent before the application data arrives? Isn't the trigger for the browser to regain consent application data itself? I am however okay to keep it outside the scope of this document and figured out elsewhere. It looks we don't to need change any text in the document then. Perhaps, we could make it explicit that consent needs to be regained. Current text: An endpoint that is not sending any application data does not need to maintain consent. New text: An endpoint that is not sending any application data after obtaining consent does not need to maintain consent, but the endpoint MUST regain consent before it resumes sending application data. Muthu =E2=80=8B > > > And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby=E2=80= =9D. Or, if you > know that you are going to start sending application data on a new > candidate pair, you can regain consent while still sending application da= ta > on the previous candidate. > > > Regards, > > > > Christer > > > > Some of the possible solutions: > > - ICE restart -- too much of overhead and possible O/A race conditions, > don't like. > > - Endpoint buffers the application data till consent is regained -- kluge= , > don't like. > > - Allow the endpoint to resume sending application data using the consent > it had when it stopped sending -- could open a backdoor, still don't like= . > > - Keep maintaining consent irrespective of whether application data is > sent or not -- simple, serves as a heartbeat in the absence of applicatio= n > data, helps to keep NAT bindings alive and helps to refine RTT. The trade > off is some network bandwidth, but I think it is insignificant (some > keepalives would be sent anyway), so like it. > > > > Muthu > > > > On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > In order to avoid loss of data, you shall not start sending data until yo= u > have regained consent, similar to when the session was established. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > > *From: *Muthu Arul Mozhi Perumal > *Sent: *=E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 > *To: *Christer Holmberg > *Cc: *Martin Thomson ; Bernard Aboba > ; rtcweb@ietf.org > *Subject: *Re: [rtcweb] Comment on consent-freshness-14 > > But there would still be loss of application data for at least one RTT > before consent can be regained. Would that be devastating for video if th= e > initial packets sent after resumption contained the I-frame (for e.g, the > user turns off the camera and turns it on after a minute)? > > > > Muthu > > > > On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > You re-obtain consent using STUN. > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > > *From: *Martin Thomson > *Sent: *=E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 > *To: *Christer Holmberg > *Cc: *Muthu Arul Mozhi Perumal ; Bernard Aboba > ; rtcweb@ietf.org > *Subject: *Re: [rtcweb] Comment on consent-freshness-14 > > On 19 June 2015 at 10:20, Christer Holmberg > wrote: > > "When the endpoint wants to start sending data again, it first needs to > re-obtain > > consent, so it starts the sending of consent requests according to the > procedures in this document > > (the endpoint does not need to perform ICE restart in this case)." > > > Packet loss is going to be devastating to performance if you just > start checking again. Should we also recommend (or allow) the use of > a STUN transaction to regain consent? > > > > > --089e013d12ca60b7230518f797a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg <christer.holmberg@ericsson.com= > wrote:<= br>

Hi,

=C2=A0

>But= unless the application starts sending data, consent will not be regained, = so it is a chicken-and-egg problem -:)

= =C2=A0

I don=E2=80=99t understand. You always have to (re)gain consent, = using STUN, before you send application data. That=E2=80=99s the whole idea= of the mechanism, and nothing that has been suggested here changes that.

=E2=80=8B
The question is, how would the bro= wser know that the application is about to send data so that it can regain = consent before the application data arrives? Isn't the trigger for the = browser to regain consent application data itself?

I am however okay to keep it outs= ide the scope of this document and figured out elsewhere. It looks we don&#= 39;t to need change any text in the document then. Perhaps, we could make i= t explicit that consent needs to be regained.

Current text:
=C2=A0 =C2= =A0An endpoint that is not sending any application data does not need to
=C2=A0 =C2=A0maintain consent.

New text:
=C2=A0 =C2=A0An endpoint that is not = sending any application data after obtaining=C2=A0
=C2=A0 =C2=A0c= onsent does not need to maintain consent, but the endpoint MUST regain
=C2=A0 =C2=A0consent before it resumes sending application data.

=
=C2=A0Muthu
=E2=80=8B
=C2=A0

=C2=A0

And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby= =E2=80=9D. Or, if you know that you are going to start sending application = data on a new candidate pair, you can regain consent while still sending application data on the previous candidate.=C2= =A0

=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

Some of= the possible solutions:

- ICE r= estart -- too much of overhead and possible O/A race conditions, don't = like.

- Endpo= int buffers the application data till consent is regained -- kluge, don'= ;t like.

- Allow= the endpoint to resume sending application data using the consent it had w= hen it stopped sending -- could open a backdoor, still don't like.

- Keep = maintaining consent irrespective of whether application data is sent or not= -- simple, serves as a heartbeat in the absence of application data, helps= to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is = insignificant (some keepalives would be sent anyway), so like it.=

= =C2=A0

Muthu

=C2=A0

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

In order to avoid loss of data, you shall not start sending data until you = have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone

From: Muthu Arul Mozhi Pe= rumal
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 21:19
To: Christer Holmb= erg
Cc: Martin Thomson; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: <= /span> Re: [rtcw= eb] Comment on consent-freshness-14

But the= re would still be loss of application data for at least one RTT before cons= ent can be regained. Would that be devastating for video if the initial pac= kets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after = a minute)?

= =C2=A0

Muthu

=C2=A0

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone

From: Martin Thomson<= /a>
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holmb= erg
Cc: Muthu Arul Mozhi Perumal= ; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: <= /span> Re: [rtcw= eb] Comment on consent-freshness-14

On 19 June 2015 at 10= :20, Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first ne= eds to re-obtain
> consent, so it starts the sending of consent requests according to the= procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."= ;


Packet loss is going to be devastating to performance if you just
start checking again.=C2=A0 Should we also recommend (or allow) the use of<= br> a STUN transaction to regain consent?

=C2=A0

=C2=A0


--089e013d12ca60b7230518f797a4-- From nobody Sat Jun 20 12:10:31 2015 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 267281A90AE for ; Sat, 20 Jun 2015 12: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 Q0feAfeVVx6Q for ; Sat, 20 Jun 2015 12:10:27 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FEB1A90AC for ; Sat, 20 Jun 2015 12:10:26 -0700 (PDT) Received: by wgbhy7 with SMTP id hy7so112373407wgb.2 for ; Sat, 20 Jun 2015 12:10:25 -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=t1utAPLUQah9Hv0y9PMZc3bhcVmhLd4dsZMURtgcXQw=; b=K7jKn2gzo6zIDL7wGbyGPR6G8/wxICavU0QD2+YwxKQMM7vzgjuQX/OCukTKovGWvj WGcIdAqhd+3zo6V/pnEPts6z4GSLSHQTjz3UaZJibWi+x8hEs8aIEIjLpArS4PipY5QP 8IcXldHU4efZtoFXaDArecMaRClwMAoywEfc+dm31qpF6KSVExEZhhJeaQURroXe6vcZ uwWKwpnIyoH8PRJ3TWiiOvpOFQt1zvp2/l0MIEQRVeFEhEILw/7QbcB+VW7DRdoU8nik gufm+T3Sm4QKjQhtVYvfu+YsA9TBS5SGvedM1E5ukn5Be5YciwVmMV8WzZYCzAiz9QnT EWUg== MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr37219893wjb.133.1434827425496; Sat, 20 Jun 2015 12:10:25 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Sat, 20 Jun 2015 12:10:25 -0700 (PDT) In-Reply-To: <5585463C.5030005@alvestrand.no> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> Date: Sun, 21 Jun 2015 00:40:25 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e0116000202c4710518f7cb2d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 19:10:30 -0000 --089e0116000202c4710518f7cb2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The -14 version seems to require hot standby already: A full ICE implementation obtains consent to send using ICE. After a successful ICE connectivity check on a particular transport address (i.e., a candidate pair has been marked as Succeeded), consent MUST be maintained following the procedure described in this document. Do we want to change that to? A full ICE implementation obtains consent to send using ICE. After ICE concludes on a particular candidate pair consent MUST be maintained following the procedure described in this document. Muthu On Sat, Jun 20, 2015 at 4:23 PM, Harald Alvestrand wrote: > On 06/20/2015 06:58 AM, Bernard Aboba wrote: > > Personally, I'm fine with requiring that consent be regained before > sending. This need not exact a performance penalty. > > In make before break scenarios, consent can be regained first in the > background before data is switched over to the revived candidate pair, so > no buffering is needed. If there is a desire to have a "hot standby" so a= s > to avoid buffering in break before make, then consent can be continued > even when no data is being sent (what Justin's nombis draft proposes). > > However I do not see the need to mandate consent for pairs over which no > data is sent in this document. Let us leave that decision to future > documents in MMUSIC WG. > > > +1. > > It's currently technically unclear whether the advantages of running > consent over "hot standby" candidate pairs (NATs stay up, consent is > immediately and obviously available, continuous measurement of candiate > pair performance) outweigh the disadvantages (overhead of running checks, > need for picking sensible candidate pairs, risk of running useless hot > standbys). > > The document should not attempt to legislate that one or the other way is > right, it should permit experimentation. Engineering will show which one > gets deployed; once it's clear that all the developers have picked one wa= y > to do it, we can standardize on that. > > > > On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> wrote: > > But unless the application starts sending data, consent will not be > regained, so it is a chicken-and-egg problem -:) > > Some of the possible solutions: > - ICE restart -- too much of overhead and possible O/A race conditions, > don't like. > - Endpoint buffers the application data till consent is regained -- > kluge, don't like. > - Allow the endpoint to resume sending application data using the consent > it had when it stopped sending -- could open a backdoor, still don't like= . > - Keep maintaining consent irrespective of whether application data is > sent or not -- simple, serves as a heartbeat in the absence of applicatio= n > data, helps to keep NAT bindings alive and helps to refine RTT. The trade > off is some network bandwidth, but I think it is insignificant (some > keepalives would be sent anyway), so like it. > > Muthu > > On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> In order to avoid loss of data, you shall not start sending data until >> you have regained consent, similar to when the session was established. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------ >> From: Muthu Arul Mozhi Perumal >> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 >> To: Christer Holmberg >> Cc: Martin Thomson ; Bernard Aboba >> ; rtcweb@ietf.org >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >> >> But there would still be loss of application data for at least one >> RTT before consent can be regained. Would that be devastating for video = if >> the initial packets sent after resumption contained the I-frame (for e.g= , >> the user turns off the camera and turns it on after a minute)? >> >> Muthu >> >> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> You re-obtain consent using STUN. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> ------------------------------ >>> From: Martin Thomson >>> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 >>> To: Christer Holmberg >>> Cc: Muthu Arul Mozhi Perumal ; Bernard Aboba >>> ; rtcweb@ietf.org >>> Subject: Re: [rtcweb] Comment on consent-freshness-14 >>> >>> On 19 June 2015 at 10:20, Christer Holmberg >>> wrote: >>> > "When the endpoint wants to start sending data again, it first needs >>> to re-obtain >>> > consent, so it starts the sending of consent requests according to th= e >>> procedures in this document >>> > (the endpoint does not need to perform ICE restart in this case)." >>> >>> >>> Packet loss is going to be devastating to performance if you just >>> start checking again. Should we also recommend (or allow) the use of >>> a STUN transaction to regain consent? >>> >> >> > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0116000202c4710518f7cb2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The -14 version seems to require hot st= andby already:

   A full ICE implementation obtains consent to send using ICE.  After a
   successful ICE connectivity check on a particular transport address
   (i.e., a candidate pair has been marked as Succeeded), consent MUST
   be maintained following the procedure described in this document.
<= pre class=3D"" style=3D"font-family:arial,helvetica,sans-serif;font-size:13= .3333330154419px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">
Do we want to change that to?

=C2=A0 =C2=A0A full ICE implementation obtains consent=
 to send using ICE.=C2=A0 After ICE
=C2=A0 =C2=A0concludes on a part=
icular candidate pair consent MUST be maintained=C2=A0
<=
pre class=3D"" style=3D"margin-top:0px;margin-bottom:0px">=C2=A0 =C2=A0=
following the procedure described in this document.

Muth=
u

On Sat, Jun 20, 2015 at 4:23 PM, Harald Alvestrand <ha= rald@alvestrand.no> wrote:
=20 =20 =20
On 06/20/2015 06:58 AM, Bernard Aboba wrote:
=20
Personally, I'm fine with requiring that consent be regained before sending.=C2=A0 This need not exact a performance penalty.

In make before break scenarios, consent can be regained first in the background before data is switched over to the revived candidate pair, so no buffering is needed. If there is a desire to have a "hot standby" so as to avoid buffering in break= before make,=C2=A0the= n consent can be continued even when no data is being sent (what Justin's nombis draft proposes). =C2=A0

However I do not see the need to mandate consent for pairs over which no data is sent in this document. Let us leave that decision to future documents in MMUSIC WG.

+1.

It's currently technically unclear whether the advantages of runnin= g consent over "hot standby" candidate pairs (NATs stay up, con= sent is immediately and obviously available, continuous measurement of candiate pair performance) outweigh the disadvantages (overhead of running checks, need for picking sensible candidate pairs, risk of running useless hot standbys).

The document should not attempt to legislate that one or the other way is right, it should permit experimentation. Engineering will show which one gets deployed; once it's clear that all the developers have picked one way to do it, we can standardize on that.


On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com= > wrote:

But unless the application starts sending data, consent will not be regained, so it is a chicken-and-egg problem -:)

Some of the possible solutions:
- ICE restart -- too much of overhead and possible O/A race conditions, don't like.
- Endpoint buffers the application data till consent is regained -- kluge, don't like.
- Allow the endpoint to resume sending application data using the consent it had when it stopped sending -- could open a backdoor, still don't like.
- Keep maintaining consent irrespective of whether application data is sent or not -- simple, serves as a heartbeat in the absence of application data, helps to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is insignificant (some keepalives would be sent anyway), so like it.

Muthu

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi,

In order to avoid loss of data, you shall not start sending data until you have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Perumal
Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19
To: Christer Holmberg
Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [rtcweb] Comment on consent-freshness-14
But there would still be loss of application data for at least one RTT before consent can be regained. Would that be devastating for video if the initial packets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone=
From: Martin Thomson
Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holmberg
Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org<= br> Subject: Re: [rtcweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<christer.holmberg@ericsson.com= > wrote:
> "When the endpoint wants to start sending data again, it first needs to re-obtain
> consent, so it starts the sending of consent requests according to the procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."


Packet loss is going to be devastating to performance if you just
start checking again.=C2=A0 Should we also recommend (or allow) the use of
a STUN transaction to regain consent?




___________________________________=
____________
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


--089e0116000202c4710518f7cb2d-- From nobody Sat Jun 20 12:26:16 2015 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 4A30A1A90F6 for ; Sat, 20 Jun 2015 12:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 d7VMQNshRyLW for ; Sat, 20 Jun 2015 12:26:13 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372381A90E6 for ; Sat, 20 Jun 2015 12:26:13 -0700 (PDT) Received: by yhak3 with SMTP id k3so91690355yha.2 for ; Sat, 20 Jun 2015 12:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=B365gTs033fW7j4T0ET1vANOialDxBMzYbRaQiF7lxw=; b=dHzIFHApG+1iUg/r96Hwl72sqY2LOyHzdCOn2ys88mKmgTADyrmqds4Td9McFYtc1q uGOOAcKp9PkwAQjWP7rewMfjEtCkO+58sH5kTi9W160MVzK1MoGxuCNPiXlGKehoZBZD o9/GgoEbB/7tnKLeVuqS1pZpVMZhZdlAOqenacTUKw0KpRfts8TwJL4g0z7xG2wKWDUh xiUac4rqhaTZ8w3I4GqwQ5dR0KowMxR+Km7FNatzq4qi0usb2pkAWXeQm8o8EOu/de8s adu5S4dCX1WDSe8iBVGZypt1KrPRbOSvQ3cxWgmFZ1ip6d3N3bNVi2ldW3uQzHe1YDq8 zQWQ== X-Received: by 10.13.250.70 with SMTP id k67mr25768928ywf.146.1434828372499; Sat, 20 Jun 2015 12:26:12 -0700 (PDT) Received: from [10.69.93.14] (mobile-166-172-191-198.mycingular.net. [166.172.191.198]) by mx.google.com with ESMTPSA id v64sm11862441ywa.20.2015.06.20.12.26.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 12:26:11 -0700 (PDT) References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-CD8E3BF2-F690-43CB-BBAA-43B83D4764B6 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12F70) From: Bernard Aboba Date: Sat, 20 Jun 2015 15:26:06 -0400 To: Muthu Arul Mozhi Perumal Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 19:26:15 -0000 --Apple-Mail-CD8E3BF2-F690-43CB-BBAA-43B83D4764B6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The trigger is the browser ICE implementation deciding which pair(s) to send= data on. So the browser doesn't have to anticipate app behavior for this i= ssue to be relevant. > On Jun 20, 2015, at 2:55 PM, Muthu Arul Mozhi Perumal wrote: >=20 >> On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> =20 >>=20 >> >But unless the application starts sending data, consent will not be rega= ined, so it is a chicken-and-egg problem -:) >>=20 >> =20 >>=20 >> I don=E2=80=99t understand. You always have to (re)gain consent, using ST= UN, before you send application data. That=E2=80=99s the whole idea of the m= echanism, and nothing that has been suggested here changes that. >>=20 >=20 > =E2=80=8BThe question is, how would the browser know that the application i= s about to send data so that it can regain consent before the application da= ta arrives? Isn't the trigger for the browser to regain consent application d= ata itself? >=20 > I am however okay to keep it outside the scope of this document and figure= d out elsewhere. It looks we don't to need change any text in the document t= hen. Perhaps, we could make it explicit that consent needs to be regained. >=20 > Current text: > An endpoint that is not sending any application data does not need to > maintain consent. >=20 > New text: > An endpoint that is not sending any application data after obtaining=20= > consent does not need to maintain consent, but the endpoint MUST regain= > consent before it resumes sending application data. >=20 > Muthu > =E2=80=8B=20 >> =20 >>=20 >> And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby=E2=80=9D= . Or, if you know that you are going to start sending application data on a n= ew candidate pair, you can regain consent while still sending application da= ta on the previous candidate.=20 >>=20 >> =20 >>=20 >> Regards, >>=20 >> =20 >>=20 >> Christer >>=20 >> =20 >>=20 >> Some of the possible solutions: >>=20 >> - ICE restart -- too much of overhead and possible O/A race conditions, d= on't like. >>=20 >> - Endpoint buffers the application data till consent is regained -- kluge= , don't like. >>=20 >> - Allow the endpoint to resume sending application data using the consent= it had when it stopped sending -- could open a backdoor, still don't like. >>=20 >> - Keep maintaining consent irrespective of whether application data is se= nt or not -- simple, serves as a heartbeat in the absence of application dat= a, helps to keep NAT bindings alive and helps to refine RTT. The trade off i= s some network bandwidth, but I think it is insignificant (some keepalives w= ould be sent anyway), so like it. >>=20 >> =20 >>=20 >> Muthu >>=20 >> =20 >>=20 >> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg wrote: >>=20 >> Hi, >>=20 >> In order to avoid loss of data, you shall not start sending data until yo= u have regained consent, similar to when the session was established. >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >>=20 >> From: Muthu Arul Mozhi Perumal >> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 >> To: Christer Holmberg >> Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >>=20 >> But there would still be loss of application data for at least one RTT be= fore consent can be regained. Would that be devastating for video if the ini= tial packets sent after resumption contained the I-frame (for e.g, the user t= urns off the camera and turns it on after a minute)? >>=20 >> =20 >>=20 >> Muthu >>=20 >> =20 >>=20 >> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg wrote: >>=20 >> Hi, >>=20 >> You re-obtain consent using STUN. >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >>=20 >> From: Martin Thomson >> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 >> To: Christer Holmberg >> Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org >> Subject: Re: [rtcweb] Comment on consent-freshness-14 >>=20 >> On 19 June 2015 at 10:20, Christer Holmberg >> wrote: >> > "When the endpoint wants to start sending data again, it first needs to= re-obtain >> > consent, so it starts the sending of consent requests according to the p= rocedures in this document >> > (the endpoint does not need to perform ICE restart in this case)." >>=20 >>=20 >> Packet loss is going to be devastating to performance if you just >> start checking again. Should we also recommend (or allow) the use of >> a STUN transaction to regain consent? >>=20 >=20 --Apple-Mail-CD8E3BF2-F690-43CB-BBAA-43B83D4764B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The trigger is the browser ICE impleme= ntation deciding which pair(s) to send data on.  So the browser doesn't= have to anticipate app behavior for this issue to be relevant.


<= /div>

On Jun 20, 2015, at 2:55 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
<= br>
<= span style=3D"font-family:arial,sans-serif">On Sat, Jun 20, 2015 at 2:43 PM,= Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

>But u= nless the application starts sending data, consent will not be regained, so i= t is a chicken-and-egg problem -:)

&= nbsp;

I don=E2=80=99t understand. You always have to (re)gain consent, us= ing STUN, before you send application data. That=E2=80=99s the whole idea of= the mechanism, and nothing that has been suggested here changes that.


=
=E2=80=8B
The question is, how would the browser= know that the application is about to send data so that it can regain conse= nt before the application data arrives? Isn't the trigger for the browser to= regain consent application data itself?

I am however okay to keep it outside the scope of= this document and figured out elsewhere. It looks we don't to need change a= ny text in the document then. Perhaps, we could make it explicit that consen= t needs to be regained.

=
Current text:
<= div>
   An endpoint that is n= ot sending any application data does not need to
 =  maintain consent.

New t= ext:
   An endpoint that is not sending a= ny application data after obtaining 
   consent doe= s not need to maintain consent, but the endpoint MUST regain
 = ;  consent before it resumes sending application data.

 Muthu
=E2=80=8B
 

<= /p>

 

And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby=E2= =80=9D. Or, if you know that you are going to start sending application data= on a new candidate pair, you can regain consent while still sending application data on the previous candidate. = ;

<= /p>

 

Regards,<= /span>

 

Christer

 

Some of t= he possible solutions:

- ICE re= start -- too much of overhead and possible O/A race conditions, don't like.<= u>

- Endpoi= nt buffers the application data till consent is regained -- kluge, don't lik= e.

- Allow t= he endpoint to resume sending application data using the consent it had when= it stopped sending -- could open a backdoor, still don't like.

- Keep m= aintaining consent irrespective of whether application data is sent or not -= - simple, serves as a heartbeat in the absence of application data, helps to= keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is i= nsignificant (some keepalives would be sent anyway), so like it.

&= nbsp;

Muthu=

 

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg &= lt;chris= ter.holmberg@ericsson.com> wrote:

Hi,

In order to avoid loss of data, you shall not start sending data until you h= ave regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone

From: Muthu Arul Mozhi Perum= al
Sent: =E2=80=8E= 19/=E2=80=8E06/=E2=80=8E2015 21:19
To: = Christer Holmberg<= /a>
Cc: = Martin Thomson; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [rtcwe= b] Comment on consent-freshness-14

But ther= e would still be loss of application data for at least one RTT before consen= t can be regained. Would that be devastating for video if the initial packet= s sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after a= minute)?

&= nbsp;

Muthu=

 

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg &= lt;chris= ter.holmberg@ericsson.com> wrote:

Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone

From: Martin Thomson=
Sent: =E2=80=8E= 19/=E2=80=8E06/=E2=80=8E2015 20:25
To: = Christer Holmberg<= /a>
Cc: = Muthu Arul Mozhi Perumal= ; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [rtcwe= b] Comment on consent-freshness-14

On 19 June 2015 at 10:= 20, Christer Holmberg
<chri= ster.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first needs to= re-obtain
> consent, so it starts the sending of consent requests according to the p= rocedures in this document
> (the endpoint does not need to perform ICE restart in this case)."


Packet loss is going to be devastating to performance if you just
start checking again.  Should we also recommend (or allow) the use of a STUN transaction to regain consent?

 

 


= --Apple-Mail-CD8E3BF2-F690-43CB-BBAA-43B83D4764B6-- From nobody Sat Jun 20 12:27:37 2015 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 7D2461A90E6 for ; Sat, 20 Jun 2015 12:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 PqgE6FsepWeW for ; Sat, 20 Jun 2015 12:27:33 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7221A90ED for ; Sat, 20 Jun 2015 12:27:32 -0700 (PDT) Received: by ykdr198 with SMTP id r198so110188625ykd.3 for ; Sat, 20 Jun 2015 12:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=J/u8E9E3xU5WJ9MjyEKYDvXx9V1ZElAmrDnfoUaLZgc=; b=dzi9AHOUqtTTcWk8vk67SpXXEZxFT4ysO2Sqi1DTyVf6mHzXxR9yGSvSWYIGOQWfXa hJFXa/nNF8MGcYEuuOIqCD8EU+Ex6V/aiKWKg2w3YmkajE/axc7zO50+78r3LxlyJ4MN g5QGCdYVg9UES2kp/csnPLuSka00jsWH0118BfJ2AN6QaRR+Q68cxSXowuJipZV6nvgz RtkbBJAHYEaxlvcg5Q+1FXLmfqmWuQlxnObRNq+Sa83ElVY81qqdNsKFt97+Y6UI7QOZ YMcd+QXvNaAYbBRPPNNLaSdDTCafiJnIA7XUuSkQXz0Ji6oxli3YgfgPWSYSOj4TO/40 KY4g== X-Received: by 10.129.111.65 with SMTP id k62mr28301591ywc.88.1434828452334; Sat, 20 Jun 2015 12:27:32 -0700 (PDT) Received: from [10.69.93.14] (mobile-166-172-191-198.mycingular.net. [166.172.191.198]) by mx.google.com with ESMTPSA id y5sm4207031ywc.11.2015.06.20.12.27.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 12:27:31 -0700 (PDT) References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-A32A0BA6-188F-4715-B3EA-8F50D0CCED31 Content-Transfer-Encoding: 7bit Message-Id: <135DFF02-8199-4B52-B809-A3C1ED56B3AF@gmail.com> X-Mailer: iPhone Mail (12F70) From: Bernard Aboba Date: Sat, 20 Jun 2015 15:27:26 -0400 To: Muthu Arul Mozhi Perumal Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 19:27:35 -0000 --Apple-Mail-A32A0BA6-188F-4715-B3EA-8F50D0CCED31 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable You could add "until the browser decides to stop sending data on that pair."= > On Jun 20, 2015, at 3:10 PM, Muthu Arul Mozhi Perumal wrote: >=20 > The -14 version seems to require hot standby already: >=20 > A full ICE implementation obtains consent to send using ICE. After a > successful ICE connectivity check on a particular transport address > (i.e., a candidate pair has been marked as Succeeded), consent MUST > be maintained following the procedure described in this document. >=20 > Do we want to change that to? >=20 > A full ICE implementation obtains consent to send using ICE. After ICE= > concludes on a particular candidate pair consent MUST be maintained=20 > following the procedure described in this document. >=20 > Muthu >=20 >> On Sat, Jun 20, 2015 at 4:23 PM, Harald Alvestrand = wrote: >>> On 06/20/2015 06:58 AM, Bernard Aboba wrote: >>> Personally, I'm fine with requiring that consent be regained before send= ing. This need not exact a performance penalty. >>>=20 >>> In make before break scenarios, consent can be regained first in the bac= kground before data is switched over to the revived candidate pair, so no bu= ffering is needed. If there is a desire to have a "hot standby" so as to avo= id buffering in break before make, then consent can be continued even when n= o data is being sent (what Justin's nombis draft proposes). =20 >>>=20 >>> However I do not see the need to mandate consent for pairs over which no= data is sent in this document. Let us leave that decision to future documen= ts in MMUSIC WG. >>=20 >> +1. >>=20 >> It's currently technically unclear whether the advantages of running c= onsent over "hot standby" candidate pairs (NATs stay up, consent is immediat= ely and obviously available, continuous measurement of candiate pair perform= ance) outweigh the disadvantages (overhead of running checks, need for picki= ng sensible candidate pairs, risk of running useless hot standbys). >>=20 >> The document should not attempt to legislate that one or the other way is= right, it should permit experimentation. Engineering will show which one ge= ts deployed; once it's clear that all the developers have picked one way to d= o it, we can standardize on that. >>=20 >>>=20 >>>=20 >>> On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal wrote: >>>=20 >>>> But unless the application starts sending data, consent will not be reg= ained, so it is a chicken-and-egg problem -:) >>>>=20 >>>> Some of the possible solutions: >>>> - ICE restart -- too much of overhead and possible O/A race conditions,= don't like. >>>> - Endpoint buffers the application data till consent is regained -- klu= ge, don't like. >>>> - Allow the endpoint to resume sending application data using the conse= nt it had when it stopped sending -- could open a backdoor, still don't like= . >>>> - Keep maintaining consent irrespective of whether application data is s= ent or not -- simple, serves as a heartbeat in the absence of application da= ta, helps to keep NAT bindings alive and helps to refine RTT. The trade off i= s some network bandwidth, but I think it is insignificant (some keepalives w= ould be sent anyway), so like it. >>>>=20 >>>> Muthu >>>>=20 >>>>> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>> In order to avoid loss of data, you shall not start sending data until= you have regained consent, similar to when the session was established. >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> Sent from my Windows Phone >>>>> From: Muthu Arul Mozhi Perumal >>>>> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 >>>>> To: Christer Holmberg >>>>> Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Comment on consent-freshness-14 >>>>>=20 >>>>> But there would still be loss of application data for at least one RTT= before consent can be regained. Would that be devastating for video if the i= nitial packets sent after resumption contained the I-frame (for e.g, the use= r turns off the camera and turns it on after a minute)? >>>>>=20 >>>>> Muthu >>>>>=20 >>>>>> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg wrote: >>>>>> Hi, >>>>>>=20 >>>>>> You re-obtain consent using STUN. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> Sent from my Windows Phone >>>>>> From: Martin Thomson >>>>>> Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 >>>>>> To: Christer Holmberg >>>>>> Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org >>>>>> Subject: Re: [rtcweb] Comment on consent-freshness-14 >>>>>>=20 >>>>>> On 19 June 2015 at 10:20, Christer Holmberg >>>>>> wrote: >>>>>> > "When the endpoint wants to start sending data again, it first need= s to re-obtain >>>>>> > consent, so it starts the sending of consent requests according to t= he procedures in this document >>>>>> > (the endpoint does not need to perform ICE restart in this case)." >>>>>>=20 >>>>>>=20 >>>>>> Packet loss is going to be devastating to performance if you just >>>>>> start checking again. Should we also recommend (or allow) the use of= >>>>>> a STUN transaction to regain consent? >>>=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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-A32A0BA6-188F-4715-B3EA-8F50D0CCED31 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You could add "until the browser decid= es to stop sending data on that pair."



On Jun 20, 2= 015, at 3:10 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

The -14 version seems to requ= ire hot standby already:

   A full ICE implementation obtains consent to send using ICE=
.  After a
   successful ICE connectivity check on a particular transport address
   (i.e., a candidate pair has been marked as Succeeded), consent MUST
   be maintained following the procedure described in this document.

= 
Do we want to change that to?

   A full ICE implementation obtains consent to send using I=
CE.  After ICE
   concludes on a particular candidate pa=
ir consent MUST be maintained 
   following the procedur=
e described in this document.
=

Muthu
=

On Sat, Jun 2= 0, 2015 at 4:23 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
On 06/20/2015 06:58 AM, Bernard Aboba wrote:
=20
Personally, I'm fine with requiring that consent be regained before sending.  This need not exact a performance penalty.

In make before break scenarios, consent can be regained first in the background before data is switched over to the revived candidate pair, so no buffering is needed. If there is a desire to have a "hot standby" so as to avoid buffering in break before make, then= consent can be continued even when no data is being sent (what Justin's nombis draft proposes).  

However I do not see the need to mandate consent for pairs over which no data is sent in this document. Let us leave that decision to future documents in MMUSIC WG.

+1.

It's currently technically unclear whether the advantages of running consent over "hot standby" candidate pairs (NATs stay up, consent is immediately and obviously available, continuous measurement of candiate pair performance) outweigh the disadvantages (overhead of running checks, need for picking sensible candidate pairs, risk of running useless hot standbys).

The document should not attempt to legislate that one or the other way is right, it should permit experimentation. Engineering will show which one gets deployed; once it's clear that all the developers have picked one way to do it, we can standardize on that.
=


On Jun 19, 2015, at 10:11 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>= wrote:

But unless the application starts sending data, consent will not be regained, so it is a chicken-and-egg problem -:)

Some of the possible solutions:
- ICE restart -- too much of overhead and possible O/A race conditions, don't like.
- Endpoint buffers the application data till consent is regained -- kluge, don't like.
- Allow the endpoint to resume sending application data using the consent it had when it stopped sending -- could open a backdoor, still don't like.
- Keep maintaining consent irrespective of whether application data is sent or not -- simple, serves as a heartbeat in the absence of application data, helps to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is insignificant (some keepalives would be sent anyway), so like it.

Muthu

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg <christer.holmberg@ericsson.c= om> wrote:
Hi,

In order to avoid loss of data, you shall not start sending data until you have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone
From: M= uthu Arul Mozhi Perumal
Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19
To: Christer Holmberg
Cc: Martin Thomson; Bernard Aboba; rtcweb@ietf.org
Subject: Re: [rtcweb] Comment on consent-freshness-14
But there would still be loss of application data for at least one RTT before consent can be regained. Would that be devastating for video if the initial packets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after a minute)?

Muthu

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone<= /div>
From: Martin Thomson
Sent: =E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holmberg
Cc: Muthu Arul Mozhi Perumal; Bernard Aboba; rtcweb@ietf.org Subject: Re: [rtcweb] Comment on consent-freshness-14

On 19 June 2015 at 10:20, Christer Holmberg
<christer.holmberg@ericsson.com&g= t; wrote:
> "When the endpoint wants to start sending data again, it first needs to re-obtain
> consent, so it starts the sending of consent requests according to the procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."


Packet loss is going to be devastating to performance if you just
start checking again.  Should we also recommend (or allow) the use of
a STUN transaction to regain consent?




____________________________________=
___________
rtcweb mailing list
rtcweb@ietf.org
h=
ttps://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
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-A32A0BA6-188F-4715-B3EA-8F50D0CCED31-- From nobody Sat Jun 20 12:42:54 2015 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 C6FA41A910B for ; Sat, 20 Jun 2015 12:42:52 -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 u4MBaLyp1MSu for ; Sat, 20 Jun 2015 12:42:51 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C121A9124 for ; Sat, 20 Jun 2015 12:42:51 -0700 (PDT) Received: by yhan67 with SMTP id n67so91755545yha.3 for ; Sat, 20 Jun 2015 12:42: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=eZraRHOiH++UWWamzgdmVWh8p1tflEKFgXxzLutcGZw=; b=XQ08Qru52840c36DBokH6906TlI9WagLDyDJXbj94lv+ARv/L22RiBkHPa7EfTRoAW 1y1/bAqfpEvvBk9wtJh1HzFnwok/1RM0vEzz7vTtyMp0Z5LT4QxiY4z2gOWCppt1iZB6 TYkqjb+thodTm6aMiDP6XdoGggIJxGhYDPiMx23IIJH1F05yN6Ru+xhJVuP8QaS7yuOv ZqurR3VfyD8i6+/5N5kYUrLkNPbUfVXAq5+ilIYFllkvPk5ei4dUdVEwKU+I4P7t1wS/ jgVrT2Z0//DwxM5E0eqrdUPHsCNJdYo2oCPCo9VOWJdQZ0hP0MORF5Q/F+NEeOUhq5/G z1lQ== MIME-Version: 1.0 X-Received: by 10.129.103.84 with SMTP id b81mr13538514ywc.55.1434829370120; Sat, 20 Jun 2015 12:42:50 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Sat, 20 Jun 2015 12:42:50 -0700 (PDT) In-Reply-To: <135DFF02-8199-4B52-B809-A3C1ED56B3AF@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> <135DFF02-8199-4B52-B809-A3C1ED56B3AF@gmail.com> Date: Sat, 20 Jun 2015 12:42:50 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 19:42:52 -0000 On 20 June 2015 at 12:27, Bernard Aboba wrote: > You could add "until the browser decides to stop sending data on that pair." Though this is primarily for browsers, I'd prefer to avoid mentioning them directly like that. Though the addition is fine. From nobody Sat Jun 20 13:02:35 2015 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 8BFA11A912B for ; Sat, 20 Jun 2015 13:02:33 -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 E886NAfXTRgu for ; Sat, 20 Jun 2015 13:02:32 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009FE1A9093 for ; Sat, 20 Jun 2015 13:02:23 -0700 (PDT) Received: by yhan67 with SMTP id n67so91825491yha.3 for ; Sat, 20 Jun 2015 13:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gcXY49u7AEcT4Yya11TXMpwKL4bWw5G6VNMnS1DKuIw=; b=05cyrwKX0IS7ybjQkwL2YCmVEybFC24mmVaU0USBjNgRuDG/cGHTgOA0azy3Bv/MFW TfPneXLKZWt0m9BdIqiYnsU4Lu64p1C37Tk3Yj1KERalCsLHi4/CiWjvNR8HvdS1ScD7 fQwJHG7GcVy21AenbOSO937zLjaM0aaHCTEMhDHnHM1F2SAS2z6Ab/ftRRgVVHLoDPT9 JprzL57a0aUhsoHH2x0LcMXJkUO0+hJhztUJfGoJ2JAaRJ8Dbtg3kl0gxqymvIOnxb5A lMKXUFXFWvE+z1JEKTFRNLo2LsnPZ+5jhopakLwLVXWlC3qY15oPi2/m1Bq9YLmfIPMc PP3A== X-Received: by 10.129.73.150 with SMTP id w144mr25588606ywa.28.1434830542431; Sat, 20 Jun 2015 13:02:22 -0700 (PDT) Received: from ?IPv6:2601:580:4001:4a05:f1db:a3e1:3974:6787? ([2601:580:4001:4a05:f1db:a3e1:3974:6787]) by mx.google.com with ESMTPSA id z126sm11931232ywe.40.2015.06.20.13.02.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jun 2015 13:02:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (12F69) In-Reply-To: Date: Sat, 20 Jun 2015 16:02:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06345ED5-222A-4847-BFF9-729168DD07A2@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> <135DFF02-8199-4B52-B809-A3C1ED56B3AF@gmail.com> To: Martin Thomson Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 20:02:33 -0000 Right. Using the term "ICE agent" might be better, for example. > On Jun 20, 2015, at 3:42 PM, Martin Thomson wro= te: >=20 >> On 20 June 2015 at 12:27, Bernard Aboba wrote: >> You could add "until the browser decides to stop sending data on that pai= r." >=20 > Though this is primarily for browsers, I'd prefer to avoid mentioning > them directly like that. Though the addition is fine. From nobody Sat Jun 20 14:55:26 2015 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 AE4021AC418 for ; Sat, 20 Jun 2015 14:55:25 -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 uMMCVERAEDJR for ; Sat, 20 Jun 2015 14:55:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79A01AC416 for ; Sat, 20 Jun 2015 14:55:23 -0700 (PDT) X-AuditID: c1b4fb30-f799f6d000000faf-3a-5585e149c58d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B3.59.04015.941E5855; Sat, 20 Jun 2015 23:55:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Sat, 20 Jun 2015 23:55:21 +0200 From: Christer Holmberg To: Bernard Aboba , Martin Thomson Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAArlwA///Qu4AAB/fzAAAElIFWAAKqG4AAACs3VgAK9UgAAAXZt4AADGgvAAARWBmAAACYJAAAAImwAAAArlgA//+/ZuA= Date: Sat, 20 Jun 2015 21:55:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F4828@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> <135DFF02-8199-4B52-B809-A3C1ED56B3AF@gmail.com> <06345ED5-222A-4847-BFF9-729168DD07A2@gmail.com> In-Reply-To: <06345ED5-222A-4847-BFF9-729168DD07A2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvra7nw9ZQgwlLDCw27PvPbHHtzD9G i7X/2tkdmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsErow783cyFUzkqLh44AF7A+MVti5G Tg4JAROJ7knnWCFsMYkL99YDxbk4hASOMkpc6PwN5SxmlPi1+CJjFyMHB5uAhUT3P22QBhGB CInjK+cygdjMAuoSdxafYwexhQVMJdZcnsMMUWMm0Xp2JivIHBGBY4wSx7+uZQRJsAioSuxf MR1sM6+Ar8SN82eZIZZN4pKYsvgsC0iCU8BWYuacaWA2I9B530+tgdomLnHryXwmiLMFJJbs Oc8MYYtKvHz8D+odJYlFtz9D1etILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUm4Vk7CwkLbOQ tMxC0rKAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmA0Hdzy22AH48vnjocYBTgYlXh4 FU62hAqxJpYVV+YeYpTmYFES552xOS9USCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+NaJq2J 51TnWKxmSVlpzHBXWnfGt422SZ/nSeQZvayMeb3mis/z69yTyy5o2c/3/Hc/acVBa6ud26co Tpw7Nfs3A8vrwGMCHs82bzrdrLHJK8DJNcov4tmTPUWHGBa9tlp61O1W6/V+gatua+XsRF4s 2xZ8IrpV/PrruVdeK5tJnnaLn+R5XHa1EktxRqKhFnNRcSIAup9Zh4cCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 20 Jun 2015 21:55:25 -0000 Perhaps "whenever the ICE agent sends data on that pair". "Stop" may sound like the ICE agent will never again send data on that pair= (which in some cases may be true, but not always). Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: 20 June 2015 23:02 To: Martin Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Comment on consent-freshness-14 Right. Using the term "ICE agent" might be better, for example. > On Jun 20, 2015, at 3:42 PM, Martin Thomson wr= ote: >=20 >> On 20 June 2015 at 12:27, Bernard Aboba wrote: >> You could add "until the browser decides to stop sending data on that pa= ir." >=20 > Though this is primarily for browsers, I'd prefer to avoid mentioning=20 > them directly like that. Though the addition is fine. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sat Jun 20 22:50:35 2015 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 779901A9045 for ; Sat, 20 Jun 2015 22:50:32 -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 XvlA04lBZld4 for ; Sat, 20 Jun 2015 22:50:29 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410811A903E for ; Sat, 20 Jun 2015 22:50:29 -0700 (PDT) Received: by wiwl6 with SMTP id l6so10298153wiw.0 for ; Sat, 20 Jun 2015 22:50: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=sGQa/jjBAaJtKUGWJhiuuUgvG5Clb3ydXS7VjO5t4XY=; b=emc729W1DYXW77bvreBIcfkcOIMd/RpD87t1CdmwBdeHl/Xq4SiV0dkvunCsZMN99u WHVSvHUwz31tmRrA3DV2mmX8wgeRqoStK2g7jgtCkW8o0/Kw8LRPWwrHq1KmBHYIATJI w+gg6FiOJDblTjA5FqiiIttTJ7n4w/y1lzOW8mBAGyeybNHLozM8y6nCDqmN45IN4A0V 7yJZQCkJuznIfaZ0MEnIVNE7+H3qw8UT8VZkVl1abk6O4qwhPdb0443uEHrquogIaGvt Oz/3qDqq/tHcBo4UD5X46o7/Lxv4a+GKXzVjuwBnaZgVbI17dhQ3N7WC/EFPeHK/bJVx haIg== MIME-Version: 1.0 X-Received: by 10.180.23.8 with SMTP id i8mr20766000wif.39.1434865457884; Sat, 20 Jun 2015 22:44:17 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Sat, 20 Jun 2015 22:44:17 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> Date: Sun, 21 Jun 2015 11:14:17 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e013d12caeaf3e2051900a5b7 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 21 Jun 2015 05:50:32 -0000 --089e013d12caeaf3e2051900a5b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's true at the beginning of the session, but if the user mutes the source during the session and the browser decides not to maintain consent because no application data is being sent, it may have to rely on the arrival of application data to regain consent, which can lead to packet loss for at least one RTT.. Muthu On Sun, Jun 21, 2015 at 12:56 AM, Bernard Aboba wrote: > The trigger is the browser ICE implementation deciding which pair(s) to > send data on. So the browser doesn't have to anticipate app behavior for > this issue to be relevant. > > > > On Jun 20, 2015, at 2:55 PM, Muthu Arul Mozhi Perumal < > muthu.arul@gmail.com> wrote: > > On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> >But unless the application starts sending data, consent will not be >> regained, so it is a chicken-and-egg problem -:) >> >> >> >> I don=E2=80=99t understand. You always have to (re)gain consent, using S= TUN, >> before you send application data. That=E2=80=99s the whole idea of the m= echanism, >> and nothing that has been suggested here changes that. >> > > =E2=80=8B > The question is, how would the browser know that the application is about > to send data so that it can regain consent before the application data > arrives? Isn't the trigger for the browser to regain consent application > data itself? > > I am however okay to keep it outside the scope of this document and > figured out elsewhere. It looks we don't to need change any text in the > document then. Perhaps, we could make it explicit that consent needs to b= e > regained. > > Current text: > An endpoint that is not sending any application data does not need to > maintain consent. > > New text: > An endpoint that is not sending any application data after obtaining > consent does not need to maintain consent, but the endpoint MUST regai= n > consent before it resumes sending application data. > > Muthu > =E2=80=8B > > >> >> >> And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby=E2=80= =9D. Or, if you >> know that you are going to start sending application data on a new >> candidate pair, you can regain consent while still sending application d= ata >> on the previous candidate. >> > >> >> Regards, >> >> >> >> Christer >> >> >> >> Some of the possible solutions: >> >> - ICE restart -- too much of overhead and possible O/A race conditions, >> don't like. >> >> - Endpoint buffers the application data till consent is regained -- >> kluge, don't like. >> >> - Allow the endpoint to resume sending application data using the consen= t >> it had when it stopped sending -- could open a backdoor, still don't lik= e. >> >> - Keep maintaining consent irrespective of whether application data is >> sent or not -- simple, serves as a heartbeat in the absence of applicati= on >> data, helps to keep NAT bindings alive and helps to refine RTT. The trad= e >> off is some network bandwidth, but I think it is insignificant (some >> keepalives would be sent anyway), so like it. >> >> >> >> Muthu >> >> >> >> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> Hi, >> >> In order to avoid loss of data, you shall not start sending data until >> you have regained consent, similar to when the session was established. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------ >> >> *From: *Muthu Arul Mozhi Perumal >> *Sent: *=E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 >> *To: *Christer Holmberg >> *Cc: *Martin Thomson ; Bernard Aboba >> ; rtcweb@ietf.org >> *Subject: *Re: [rtcweb] Comment on consent-freshness-14 >> >> But there would still be loss of application data for at least one RTT >> before consent can be regained. Would that be devastating for video if t= he >> initial packets sent after resumption contained the I-frame (for e.g, th= e >> user turns off the camera and turns it on after a minute)? >> >> >> >> Muthu >> >> >> >> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> Hi, >> >> You re-obtain consent using STUN. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------ >> >> *From: *Martin Thomson >> *Sent: *=E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 >> *To: *Christer Holmberg >> *Cc: *Muthu Arul Mozhi Perumal ; Bernard Aboba >> ; rtcweb@ietf.org >> *Subject: *Re: [rtcweb] Comment on consent-freshness-14 >> >> On 19 June 2015 at 10:20, Christer Holmberg >> wrote: >> > "When the endpoint wants to start sending data again, it first needs t= o >> re-obtain >> > consent, so it starts the sending of consent requests according to the >> procedures in this document >> > (the endpoint does not need to perform ICE restart in this case)." >> >> >> Packet loss is going to be devastating to performance if you just >> start checking again. Should we also recommend (or allow) the use of >> a STUN transaction to regain consent? >> >> >> >> >> > > --089e013d12caeaf3e2051900a5b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's true at the beginning of the= session, but if the user mutes the source during the session and the brows= er decides not to maintain consent because no application data is being sen= t, it may have to rely on the arrival of application data to regain consent= , which can lead to packet loss for at least one RTT..

Muthu

=
On Sun, Jun 21, 2015 at 12:56 AM, Bernard Aboba = <bernard.aboba@gmail.com> wrote:
The trigger is the browser ICE impleme= ntation deciding which pair(s) to send data on.=C2=A0 So the browser doesn&= #39;t have to anticipate app behavior for this issue to be relevant.


On Jun 20, 2015, at 2:55 PM, Mut= hu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

On = Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>But= unless the application starts sending data, consent will not be regained, = so it is a chicken-and-egg problem -:)

= =C2=A0

I don=E2=80=99t understand. You always have to (re)gain consent, = using STUN, before you send application data. That=E2=80=99s the whole idea= of the mechanism, and nothing that has been suggested here changes that.

=E2=80=8B
The question is, how would the browser know that the appli= cation is about to send data so that it can regain consent before the appli= cation data arrives? Isn't the trigger for the browser to regain consen= t application data itself?

I am however okay to keep it out= side the scope of this document and figured out elsewhere. It looks we don&= #39;t to need change any text in the document then. Perhaps, we could make = it explicit that consent needs to be regained.
=
Current text:
=C2=A0 =C2= =A0An endpoint that is not sending any application data does not need to
=C2=A0 =C2=A0maintain consent.

New text:
=C2=A0 =C2=A0An endpoint that is not sending any application = data after obtaining=C2=A0
=C2=A0 =C2=A0consent does not need to = maintain consent, but the endpoint MUST regain
=C2=A0 =C2=A0conse= nt before it resumes sending application data.

=C2=A0Muthu
=E2=80=8B
=C2=A0

=C2=A0

And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby= =E2=80=9D. Or, if you know that you are going to start sending application = data on a new candidate pair, you can regain consent while still sending application data on the previous candidate.=C2= =A0

=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

Some of= the possible solutions:

- ICE r= estart -- too much of overhead and possible O/A race conditions, don't = like.

- Endpo= int buffers the application data till consent is regained -- kluge, don'= ;t like.

- Allow= the endpoint to resume sending application data using the consent it had w= hen it stopped sending -- could open a backdoor, still don't like.

- Keep = maintaining consent irrespective of whether application data is sent or not= -- simple, serves as a heartbeat in the absence of application data, helps= to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is = insignificant (some keepalives would be sent anyway), so like it.=

= =C2=A0

Muthu

=C2=A0

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

In order to avoid loss of data, you shall not start sending data until you = have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone

From: Muthu Arul Mozhi Pe= rumal
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 21:19
To: Christer Holmb= erg
Cc: Martin Thomson; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: <= /span> Re: [rtcw= eb] Comment on consent-freshness-14

But the= re would still be loss of application data for at least one RTT before cons= ent can be regained. Would that be devastating for video if the initial pac= kets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after = a minute)?

= =C2=A0

Muthu

=C2=A0

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone

From: Martin Thomson<= /a>
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holmb= erg
Cc: Muthu Arul Mozhi Perumal= ; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: <= /span> Re: [rtcw= eb] Comment on consent-freshness-14

On 19 June 2015 at 10= :20, Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first ne= eds to re-obtain
> consent, so it starts the sending of consent requests according to the= procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."= ;


Packet loss is going to be devastating to performance if you just
start checking again.=C2=A0 Should we also recommend (or allow) the use of<= br> a STUN transaction to regain consent?

=C2=A0

=C2=A0



--089e013d12caeaf3e2051900a5b7-- From nobody Sun Jun 21 00:10:56 2015 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 495D71ACDBF for ; Sun, 21 Jun 2015 00:10:54 -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 FfU7GHInvIs7 for ; Sun, 21 Jun 2015 00:10:51 -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 67C1F1ACDBE for ; Sun, 21 Jun 2015 00:10:50 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-5d-55866378d358 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 71.18.17665.87366855; Sun, 21 Jun 2015 09:10:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Sun, 21 Jun 2015 09:10:47 +0200 From: Christer Holmberg To: Muthu Arul Mozhi Perumal , Bernard Aboba Thread-Topic: [rtcweb] Comment on consent-freshness-14 Thread-Index: AdCp8ZzPYjobCCgiRiODoxNtnTqGGP//4vgAgAAONAD//7w74IAApn+AgAAAWoCAACL+gIAAAVsAgABHkRT//+X8AIAArlwA///Qu4AAB/fzAAAElIFWAAKqG4AAACs3VgAK9UgAAAXZt4AADGgvAAAQ1w6AAAENQwAAFZb+gAAHNj3N Date: Sun, 21 Jun 2015 07:10:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8F4C91@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8F4C91ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3VrciuS3U4P4/IYsN+/4zW1w784/R 4s9mP4u1/9rZHVg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MnTP+sxZcectYcerXNeYG xi3PGbsYOTgkBEwkJp416WLkBDLFJC7cW8/WxcjFISRwlFHiz45F7BDOYkaJSQc2soM0sAlY SHT/0wZpEBGIk5hx4ygTiM0sECLx8Ow7ZhBbWMBUYs3lOcwQNWYSrWdnsoLMERHYxyjR/XAN C0iCRUBV4vmLS6wgM3kFfCVevcqH2HWXU6Jn7Tk2kBpOgUCJm1/PsYPYjEDXfT+1BmqZuETT l5WsEFcLSCzZc54ZwhaVePn4HytETb7Ery2HwebwCghKnJz5hGUCo8gsJO2zkJTNQlI2C+gk ZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQT IzDWDm75rbuDcfVrx0OMAhyMSjy8C6TaQoVYE8uKK3MPMUpzsCiJ887YnBcqJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgXFZqDQ/v1jCifOn77kttHoTPuPOmg0S7uwOzO7v5Pu0p7OuNAwo 2Ca85cn7h4VJMV9Ybh3I/rDH37els/JNUJJx/nyBF8vfaxyZrpR0rlPp0g8vca/Tq/Za9Wh5 5vj8F5o1q6u+zDxpQzOnwBtht3Wuz6ssZC+u8ntfvnCXP+c/M/1ysSPc/5VYijMSDbWYi4oT AVFn9S+WAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 21 Jun 2015 07:10:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8F4C91ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgYSBnb29kIGltcGxlbWVudGF0aW9uIHdpbGwgYWx3YXlzIG1haW50YWlu IGNvbnNlbnQgb24gc29tZSBwYWlyKHMpLCBldmVuIGlmIG5vIGFwcGxpY2F0aW9uIGRhdGEgSSBz ZW50LiBBZ2FpbiwgdGhlIHN1Z2dlc3Rpb24gaXMgbm90IHRvIGZvcmJpZCB0aGF0Li4uDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFs PG1haWx0bzptdXRodS5hcnVsQGdtYWlsLmNvbT4NClNlbnQ6IOKAjjIxL+KAjjA2L+KAjjIwMTUg MDg6NDQNClRvOiBCZXJuYXJkIEFib2JhPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4N CkNjOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPjsgTWFydGluIFRob21zb248bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIENvbW1lbnQgb24gY29uc2VudC1mcmVzaG5lc3MtMTQNCg0KVGhhdCdzIHRydWUgYXQgdGhl IGJlZ2lubmluZyBvZiB0aGUgc2Vzc2lvbiwgYnV0IGlmIHRoZSB1c2VyIG11dGVzIHRoZSBzb3Vy Y2UgZHVyaW5nIHRoZSBzZXNzaW9uIGFuZCB0aGUgYnJvd3NlciBkZWNpZGVzIG5vdCB0byBtYWlu dGFpbiBjb25zZW50IGJlY2F1c2Ugbm8gYXBwbGljYXRpb24gZGF0YSBpcyBiZWluZyBzZW50LCBp dCBtYXkgaGF2ZSB0byByZWx5IG9uIHRoZSBhcnJpdmFsIG9mIGFwcGxpY2F0aW9uIGRhdGEgdG8g cmVnYWluIGNvbnNlbnQsIHdoaWNoIGNhbiBsZWFkIHRvIHBhY2tldCBsb3NzIGZvciBhdCBsZWFz dCBvbmUgUlRULi4NCg0KTXV0aHUNCg0KT24gU3VuLCBKdW4gMjEsIDIwMTUgYXQgMTI6NTYgQU0s IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFi b2JhQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlIHRyaWdnZXIgaXMgdGhlIGJyb3dzZXIgSUNFIGlt cGxlbWVudGF0aW9uIGRlY2lkaW5nIHdoaWNoIHBhaXIocykgdG8gc2VuZCBkYXRhIG9uLiAgU28g dGhlIGJyb3dzZXIgZG9lc24ndCBoYXZlIHRvIGFudGljaXBhdGUgYXBwIGJlaGF2aW9yIGZvciB0 aGlzIGlzc3VlIHRvIGJlIHJlbGV2YW50Lg0KDQoNCg0KT24gSnVuIDIwLCAyMDE1LCBhdCAyOjU1 IFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgPG11dGh1LmFydWxAZ21haWwuY29tPG1haWx0 bzptdXRodS5hcnVsQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpPbiBTYXQsIEp1biAyMCwgMjAxNSBh dCAyOjQzIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0K DQo+QnV0IHVubGVzcyB0aGUgYXBwbGljYXRpb24gc3RhcnRzIHNlbmRpbmcgZGF0YSwgY29uc2Vu dCB3aWxsIG5vdCBiZSByZWdhaW5lZCwgc28gaXQgaXMgYSBjaGlja2VuLWFuZC1lZ2cgcHJvYmxl bSAtOikNCg0KSSBkb27igJl0IHVuZGVyc3RhbmQuIFlvdSBhbHdheXMgaGF2ZSB0byAocmUpZ2Fp biBjb25zZW50LCB1c2luZyBTVFVOLCBiZWZvcmUgeW91IHNlbmQgYXBwbGljYXRpb24gZGF0YS4g VGhhdOKAmXMgdGhlIHdob2xlIGlkZWEgb2YgdGhlIG1lY2hhbmlzbSwgYW5kIG5vdGhpbmcgdGhh dCBoYXMgYmVlbiBzdWdnZXN0ZWQgaGVyZSBjaGFuZ2VzIHRoYXQuDQoNCuKAiw0KVGhlIHF1ZXN0 aW9uIGlzLCBob3cgd291bGQgdGhlIGJyb3dzZXIga25vdyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBp cyBhYm91dCB0byBzZW5kIGRhdGEgc28gdGhhdCBpdCBjYW4gcmVnYWluIGNvbnNlbnQgYmVmb3Jl IHRoZSBhcHBsaWNhdGlvbiBkYXRhIGFycml2ZXM/IElzbid0IHRoZSB0cmlnZ2VyIGZvciB0aGUg YnJvd3NlciB0byByZWdhaW4gY29uc2VudCBhcHBsaWNhdGlvbiBkYXRhIGl0c2VsZj8NCg0KSSBh bSBob3dldmVyIG9rYXkgdG8ga2VlcCBpdCBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50IGFuZCBmaWd1cmVkIG91dCBlbHNld2hlcmUuIEl0IGxvb2tzIHdlIGRvbid0IHRvIG5lZWQg Y2hhbmdlIGFueSB0ZXh0IGluIHRoZSBkb2N1bWVudCB0aGVuLiBQZXJoYXBzLCB3ZSBjb3VsZCBt YWtlIGl0IGV4cGxpY2l0IHRoYXQgY29uc2VudCBuZWVkcyB0byBiZSByZWdhaW5lZC4NCg0KQ3Vy cmVudCB0ZXh0Og0KICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGlj YXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvDQogICBtYWludGFpbiBjb25zZW50Lg0KDQpOZXcg dGV4dDoNCiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9u IGRhdGEgYWZ0ZXIgb2J0YWluaW5nDQogICBjb25zZW50IGRvZXMgbm90IG5lZWQgdG8gbWFpbnRh aW4gY29uc2VudCwgYnV0IHRoZSBlbmRwb2ludCBNVVNUIHJlZ2Fpbg0KICAgY29uc2VudCBiZWZv cmUgaXQgcmVzdW1lcyBzZW5kaW5nIGFwcGxpY2F0aW9uIGRhdGEuDQoNCiBNdXRodQ0K4oCLDQoN Cg0KQW5kLCBhcyBCZXJuYXJkIHNhaWQsIGl0IGlzIG9rIHRvIG1haW50YWluIGEg4oCcaG90IHN0 YW5kYnnigJ0uIE9yLCBpZiB5b3Uga25vdyB0aGF0IHlvdSBhcmUgZ29pbmcgdG8gc3RhcnQgc2Vu ZGluZyBhcHBsaWNhdGlvbiBkYXRhIG9uIGEgbmV3IGNhbmRpZGF0ZSBwYWlyLCB5b3UgY2FuIHJl Z2FpbiBjb25zZW50IHdoaWxlIHN0aWxsIHNlbmRpbmcgYXBwbGljYXRpb24gZGF0YSBvbiB0aGUg cHJldmlvdXMgY2FuZGlkYXRlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTb21lIG9mIHRo ZSBwb3NzaWJsZSBzb2x1dGlvbnM6DQotIElDRSByZXN0YXJ0IC0tIHRvbyBtdWNoIG9mIG92ZXJo ZWFkIGFuZCBwb3NzaWJsZSBPL0EgcmFjZSBjb25kaXRpb25zLCBkb24ndCBsaWtlLg0KLSBFbmRw b2ludCBidWZmZXJzIHRoZSBhcHBsaWNhdGlvbiBkYXRhIHRpbGwgY29uc2VudCBpcyByZWdhaW5l ZCAtLSBrbHVnZSwgZG9uJ3QgbGlrZS4NCi0gQWxsb3cgdGhlIGVuZHBvaW50IHRvIHJlc3VtZSBz ZW5kaW5nIGFwcGxpY2F0aW9uIGRhdGEgdXNpbmcgdGhlIGNvbnNlbnQgaXQgaGFkIHdoZW4gaXQg c3RvcHBlZCBzZW5kaW5nIC0tIGNvdWxkIG9wZW4gYSBiYWNrZG9vciwgc3RpbGwgZG9uJ3QgbGlr ZS4NCi0gS2VlcCBtYWludGFpbmluZyBjb25zZW50IGlycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIGFw cGxpY2F0aW9uIGRhdGEgaXMgc2VudCBvciBub3QgLS0gc2ltcGxlLCBzZXJ2ZXMgYXMgYSBoZWFy dGJlYXQgaW4gdGhlIGFic2VuY2Ugb2YgYXBwbGljYXRpb24gZGF0YSwgaGVscHMgdG8ga2VlcCBO QVQgYmluZGluZ3MgYWxpdmUgYW5kIGhlbHBzIHRvIHJlZmluZSBSVFQuIFRoZSB0cmFkZSBvZmYg aXMgc29tZSBuZXR3b3JrIGJhbmR3aWR0aCwgYnV0IEkgdGhpbmsgaXQgaXMgaW5zaWduaWZpY2Fu dCAoc29tZSBrZWVwYWxpdmVzIHdvdWxkIGJlIHNlbnQgYW55d2F5KSwgc28gbGlrZSBpdC4NCg0K TXV0aHUNCg0KT24gU2F0LCBKdW4gMjAsIDIwMTUgYXQgMTI6MTcgQU0sIENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkluIG9yZGVyIHRvIGF2b2lkIGxvc3Mg b2YgZGF0YSwgeW91IHNoYWxsIG5vdCBzdGFydCBzZW5kaW5nIGRhdGEgdW50aWwgeW91IGhhdmUg cmVnYWluZWQgY29uc2VudCwgc2ltaWxhciB0byB3aGVuIHRoZSBzZXNzaW9uIHdhcyBlc3RhYmxp c2hlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmUNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBNdXRodSBBcnVsIE1v emhpIFBlcnVtYWw8bWFpbHRvOm11dGh1LmFydWxAZ21haWwuY29tPg0KU2VudDog4oCOMTkv4oCO MDYv4oCOMjAxNSAyMToxOQ0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogTWFydGluIFRob21zb248bWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT47IEJlcm5hcmQgQWJvYmE8bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21h aWwuY29tPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gQ29tbWVudCBvbiBjb25zZW50LWZyZXNobmVzcy0xNA0KQnV0IHRoZXJl IHdvdWxkIHN0aWxsIGJlIGxvc3Mgb2YgYXBwbGljYXRpb24gZGF0YSBmb3IgYXQgbGVhc3Qgb25l IFJUVCBiZWZvcmUgY29uc2VudCBjYW4gYmUgcmVnYWluZWQuIFdvdWxkIHRoYXQgYmUgZGV2YXN0 YXRpbmcgZm9yIHZpZGVvIGlmIHRoZSBpbml0aWFsIHBhY2tldHMgc2VudCBhZnRlciByZXN1bXB0 aW9uIGNvbnRhaW5lZCB0aGUgSS1mcmFtZSAoZm9yIGUuZywgdGhlIHVzZXIgdHVybnMgb2ZmIHRo ZSBjYW1lcmEgYW5kIHR1cm5zIGl0IG9uIGFmdGVyIGEgbWludXRlKT8NCg0KTXV0aHUNCg0KT24g RnJpLCBKdW4gMTksIDIwMTUgYXQgMTE6MDYgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4+IHdyb3RlOg0KSGksDQoNCllvdSByZS1vYnRhaW4gY29uc2VudCB1c2luZyBTVFVOLg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IE1hcnRpbiBUaG9tc29uPG1haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTZW50OiDigI4xOS/igI4wNi/igI4yMDE1IDIw OjI1DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4NCkNjOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8bWFpbHRvOm11dGh1LmFydWxA Z21haWwuY29tPjsgQmVybmFyZCBBYm9iYTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+ OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb cnRjd2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0DQpPbiAxOSBKdW5lIDIwMTUg YXQgMTA6MjAsIENocmlzdGVyIEhvbG1iZXJnDQo8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCj4gIldo ZW4gdGhlIGVuZHBvaW50IHdhbnRzIHRvIHN0YXJ0IHNlbmRpbmcgZGF0YSBhZ2FpbiwgaXQgZmly c3QgbmVlZHMgdG8gcmUtb2J0YWluDQo+IGNvbnNlbnQsIHNvIGl0IHN0YXJ0cyB0aGUgc2VuZGlu ZyBvZiBjb25zZW50IHJlcXVlc3RzIGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbiB0aGlz IGRvY3VtZW50DQo+ICh0aGUgZW5kcG9pbnQgZG9lcyBub3QgbmVlZCB0byBwZXJmb3JtIElDRSBy ZXN0YXJ0IGluIHRoaXMgY2FzZSkuIg0KDQoNClBhY2tldCBsb3NzIGlzIGdvaW5nIHRvIGJlIGRl dmFzdGF0aW5nIHRvIHBlcmZvcm1hbmNlIGlmIHlvdSBqdXN0DQpzdGFydCBjaGVja2luZyBhZ2Fp bi4gIFNob3VsZCB3ZSBhbHNvIHJlY29tbWVuZCAob3IgYWxsb3cpIHRoZSB1c2Ugb2YNCmEgU1RV TiB0cmFuc2FjdGlvbiB0byByZWdhaW4gY29uc2VudD8NCg0KDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D8F4C91ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPkhp LDxicj4NCjxicj4NCkkgdGhpbmsgYSBnb29kIGltcGxlbWVudGF0aW9uIHdpbGwgYWx3YXlzIG1h aW50YWluIGNvbnNlbnQgb24gc29tZSBwYWlyKHMpLCBldmVuIGlmIG5vIGFwcGxpY2F0aW9uIGRh dGEgSSBzZW50LiBBZ2FpbiwgdGhlIHN1Z2dlc3Rpb24gaXMgbm90IHRvIGZvcmJpZCB0aGF0Li4u PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQg ZnJvbSBteSBXaW5kb3dzIFBob25lPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGhy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXpl OjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkZyb206DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0 bzptdXRodS5hcnVsQGdtYWlsLmNvbSI+TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsPC9hPjwvc3Bh bj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCOMjEv4oCO MDYv4oCOMjAxNSAwODo0NDwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSI+QmVybmFy ZCBBYm9iYTwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPkNjOg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTox MXB0Ij48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5DaHJp c3RlciBIb2xtYmVyZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwu Y29tIj5NYXJ0aW4gVGhvbXNvbjwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci Pg0KcnRjd2ViQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+ U3ViamVjdDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmOyBmb250LXNpemU6MTFwdCI+UmU6IFtydGN3ZWJdIENvbW1lbnQgb24gY29uc2VudC1mcmVz aG5lc3MtMTQ8L3NwYW4+PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQpUaGF0J3MgdHJ1ZSBhdCB0aGUg YmVnaW5uaW5nIG9mIHRoZSBzZXNzaW9uLCBidXQgaWYgdGhlIHVzZXIgbXV0ZXMgdGhlIHNvdXJj ZSBkdXJpbmcgdGhlIHNlc3Npb24gYW5kIHRoZSBicm93c2VyIGRlY2lkZXMgbm90IHRvIG1haW50 YWluIGNvbnNlbnQgYmVjYXVzZSBubyBhcHBsaWNhdGlvbiBkYXRhIGlzIGJlaW5nIHNlbnQsIGl0 IG1heSBoYXZlIHRvIHJlbHkgb24gdGhlIGFycml2YWwgb2YgYXBwbGljYXRpb24gZGF0YSB0byBy ZWdhaW4gY29uc2VudCwNCiB3aGljaCBjYW4gbGVhZCB0byBwYWNrZXQgbG9zcyBmb3IgYXQgbGVh c3Qgb25lIFJUVC4uPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTpzbWFsbCI+DQo8 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWls eTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj4NCk11dGh1PC9k aXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPk9uIFN1biwgSnVuIDIxLCAyMDE1IGF0IDEyOjU2IEFNLCBCZXJuYXJkIEFib2JhIDxzcGFu IGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3 cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46 MCAwIDAgLjhleDsgYm9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7IHBhZGRpbmctbGVmdDoxZXgi Pg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5UaGUgdHJpZ2dlciBpcyB0aGUgYnJvd3NlciBJQ0Ug aW1wbGVtZW50YXRpb24gZGVjaWRpbmcgd2hpY2ggcGFpcihzKSB0byBzZW5kIGRhdGEgb24uJm5i c3A7IFNvIHRoZSBicm93c2VyIGRvZXNuJ3QgaGF2ZSB0byBhbnRpY2lwYXRlIGFwcCBiZWhhdmlv ciBmb3IgdGhpcyBpc3N1ZSB0byBiZSByZWxldmFudC48YnI+DQo8YnI+DQo8YnI+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2Pjxicj4NCk9uIEp1biAyMCwgMjAxNSwgYXQg Mjo1NSBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsICZsdDs8YSBocmVmPSJtYWlsdG86bXV0 aHUuYXJ1bEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tdXRodS5hcnVsQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxo ZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOnNtYWxsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsc2Fucy1zZXJpZiI+T24gU2F0LCBKdW4gMjAsIDIwMTUgYXQgMjo0MyBQTSwg Q2hyaXN0ZXIgSG9sbWJlcmcNCjwvc3Bhbj48c3BhbiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQtZmFt aWx5OmFyaWFsLHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLHNhbnMt c2VyaWYiPiB3cm90ZTo8L3NwYW4+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy YSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRo OjFweDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5 bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1HQiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGNvbG9yOnJnYigzMSw3MywxMjUpIj5IaSw8dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjxkaXY+PHNwYW4+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWYiPiZndDtCdXQgdW5sZXNzIHRoZSBh cHBsaWNhdGlvbiBzdGFydHMgc2VuZGluZyBkYXRhLCBjb25zZW50IHdpbGwgbm90IGJlIHJlZ2Fp bmVkLCBzbyBpdCBpcyBhIGNoaWNrZW4tYW5kLWVnZyBwcm9ibGVtIC06KTx1PjwvdT48dT48L3U+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmIj48dT48L3U+Jm5ic3A7 PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+SSBkb27igJl0IHVu ZGVyc3RhbmQuIFlvdSBhbHdheXMgaGF2ZSB0byAocmUpZ2FpbiBjb25zZW50LCB1c2luZyBTVFVO LCBiZWZvcmUgeW91IHNlbmQgYXBwbGljYXRpb24gZGF0YS4gVGhhdOKAmXMgdGhlIHdob2xlIGlk ZWEgb2YgdGhlIG1lY2hhbmlzbSwgYW5kIG5vdGhpbmcgdGhhdCBoYXMgYmVlbiBzdWdnZXN0ZWQN CiBoZXJlIGNoYW5nZXMgdGhhdC48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21h bGw7IGRpc3BsYXk6aW5saW5lIj4NCuKAizwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmIj5UaGUgcXVlc3Rpb24gaXMsIGhvdyB3b3VsZCB0 aGUgYnJvd3NlciBrbm93IHRoYXQgdGhlIGFwcGxpY2F0aW9uIGlzIGFib3V0IHRvIHNlbmQgZGF0 YSBzbyB0aGF0IGl0IGNhbiByZWdhaW4gY29uc2VudCBiZWZvcmUgdGhlIGFwcGxpY2F0aW9uIGRh dGEgYXJyaXZlcz8gSXNuJ3QgdGhlIHRyaWdnZXIgZm9yIHRoZSBicm93c2VyIHRvIHJlZ2FpbiBj b25zZW50DQogYXBwbGljYXRpb24gZGF0YSBpdHNlbGY/PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxicj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlm OyBmb250LXNpemU6c21hbGw7IGRpc3BsYXk6aW5saW5lIj4NCkkgYW0gaG93ZXZlciBva2F5IHRv IGtlZXAgaXQgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBhbmQgZmlndXJlZCBv dXQgZWxzZXdoZXJlLiBJdCBsb29rcyB3ZSBkb24ndCB0byBuZWVkIGNoYW5nZSBhbnkgdGV4dCBp biB0aGUgZG9jdW1lbnQgdGhlbi4gUGVyaGFwcywgd2UgY291bGQgbWFrZSBpdCBleHBsaWNpdCB0 aGF0IGNvbnNlbnQgbmVlZHMgdG8gYmUgcmVnYWluZWQuPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOnNtYWxsOyBkaXNwbGF5OmlubGluZSI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250 LXNpemU6c21hbGw7IGRpc3BsYXk6aW5saW5lIj4NCkN1cnJlbnQgdGV4dDo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImRpc3BsYXk6aW5saW5lIj48Zm9udCBmYWNlPSJhcmlhbCwg aGVsdmV0aWNhLCBzYW5zLXNlcmlmIj4NCjxkaXY+Jm5ic3A7ICZuYnNwO0FuIGVuZHBvaW50IHRo YXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bzwv ZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7bWFpbnRhaW4gY29uc2VudC48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pk5ldyB0ZXh0OjwvZGl2Pg0KPGRpdj4NCjxkaXY+Jm5ic3A7ICZuYnNw O0FuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgYWZ0 ZXIgb2J0YWluaW5nJm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtjb25zZW50IGRvZXMg bm90IG5lZWQgdG8gbWFpbnRhaW4gY29uc2VudCwgYnV0IHRoZSBlbmRwb2ludCBNVVNUIHJlZ2Fp bjwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7Y29uc2VudCBiZWZvcmUgaXQgcmVzdW1lcyBzZW5k aW5nIGFwcGxpY2F0aW9uIGRhdGEuPC9kaXY+DQo8L2Rpdj4NCjwvZm9udD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNl cmlmOyBmb250LXNpemU6c21hbGw7IGRpc3BsYXk6aW5saW5lIj4NCjxicj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTpzbWFsbDsgZGlzcGxheTppbmxpbmUiPg0KJm5ic3A7TXV0aHU8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGlj YSxzYW5zLXNlcmlmOyBmb250LXNpemU6c21hbGw7IGRpc3BsYXk6aW5saW5lIj4NCuKAizwvZGl2 Pg0KJm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxl ZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRp bmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1HQiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7IGZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZiI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpD YWxpYnJpLHNhbnMtc2VyaWYiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmIj5BbmQsIGFzIEJlcm5hcmQgc2FpZCwgaXQgaXMgb2sgdG8gbWFp bnRhaW4gYSDigJxob3Qgc3RhbmRieeKAnS4gT3IsIGlmIHlvdSBrbm93IHRoYXQgeW91IGFyZSBn b2luZyB0byBzdGFydCBzZW5kaW5nIGFwcGxpY2F0aW9uIGRhdGEgb24gYSBuZXcgY2FuZGlkYXRl IHBhaXIsIHlvdSBjYW4gcmVnYWluIGNvbnNlbnQNCiB3aGlsZSBzdGlsbCBzZW5kaW5nIGFwcGxp Y2F0aW9uIGRhdGEgb24gdGhlIHByZXZpb3VzIGNhbmRpZGF0ZS48L3NwYW4+Jm5ic3A7PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7IGJv cmRlci1sZWZ0LXdpZHRoOjFweDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsg Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJF Ti1HQiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+PHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPjx1PjwvdT4m bmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj5SZWdhcmRz LDxzcGFuPjxmb250IGNvbG9yPSIjODg4ODg4Ij48dT48L3U+PHU+PC91PjwvZm9udD48L3NwYW4+ PC9zcGFuPjwvcD4NCjxzcGFuPjxmb250IGNvbG9yPSIjODg4ODg4Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxz YW5zLXNlcmlmIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmks c2Fucy1zZXJpZiI+Q2hyaXN0ZXI8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9mb250Pjwv c3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmIj5Tb21lIG9mIHRoZSBwb3Nz aWJsZSBzb2x1dGlvbnM6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMt c2VyaWYiPi0gSUNFIHJlc3RhcnQgLS0gdG9vIG11Y2ggb2Ygb3ZlcmhlYWQgYW5kIHBvc3NpYmxl IE8vQSByYWNlIGNvbmRpdGlvbnMsIGRvbid0IGxpa2UuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWYiPi0gRW5kcG9pbnQgYnVmZmVycyB0aGUgYXBwbGljYXRp b24gZGF0YSB0aWxsIGNvbnNlbnQgaXMgcmVnYWluZWQgLS0ga2x1Z2UsIGRvbid0IGxpa2UuPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWYiPi0gQWxsb3cgdGhl IGVuZHBvaW50IHRvIHJlc3VtZSBzZW5kaW5nIGFwcGxpY2F0aW9uIGRhdGEgdXNpbmcgdGhlIGNv bnNlbnQgaXQgaGFkIHdoZW4gaXQgc3RvcHBlZCBzZW5kaW5nIC0tIGNvdWxkIG9wZW4gYSBiYWNr ZG9vciwgc3RpbGwgZG9uJ3QgbGlrZS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJp YWwsc2Fucy1zZXJpZiI+LSBLZWVwIG1haW50YWluaW5nIGNvbnNlbnQgaXJyZXNwZWN0aXZlIG9m IHdoZXRoZXIgYXBwbGljYXRpb24gZGF0YSBpcyBzZW50IG9yIG5vdCAtLSBzaW1wbGUsIHNlcnZl cyBhcyBhIGhlYXJ0YmVhdCBpbiB0aGUgYWJzZW5jZSBvZiBhcHBsaWNhdGlvbiBkYXRhLCBoZWxw cyB0byBrZWVwIE5BVCBiaW5kaW5ncyBhbGl2ZSBhbmQgaGVscHMNCiB0byByZWZpbmUgUlRULiBU aGUgdHJhZGUgb2ZmIGlzIHNvbWUgbmV0d29yayBiYW5kd2lkdGgsIGJ1dCBJIHRoaW5rIGl0IGlz IGluc2lnbmlmaWNhbnQgKHNvbWUga2VlcGFsaXZlcyB3b3VsZCBiZSBzZW50IGFueXdheSksIHNv IGxpa2UgaXQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsLHNhbnMtc2VyaWYi Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmIj5N dXRodTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFNhdCwgSnVuIDIwLCAyMDE1IGF0IDEyOjE3IEFNLCBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojx1PjwvdT48dT48L3U+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTpub25l IG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9y ZGVyLWxlZnQtd2lkdGg6MXB0OyBwYWRkaW5nOjBjbSAwY20gMGNtIDZwdDsgbWFyZ2luLWxlZnQ6 NC44cHQ7IG1hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxp YnJpLHNhbnMtc2VyaWYiPkhpLDxicj4NCjxicj4NCkluIG9yZGVyIHRvIGF2b2lkIGxvc3Mgb2Yg ZGF0YSwgeW91IHNoYWxsIG5vdCBzdGFydCBzZW5kaW5nIGRhdGEgdW50aWwgeW91IGhhdmUgcmVn YWluZWQgY29uc2VudCwgc2ltaWxhciB0byB3aGVuIHRoZSBzZXNzaW9uIHdhcyBlc3RhYmxpc2hl ZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2Vu dCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEycHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOm11 dGh1LmFydWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+TXV0aHUgQXJ1bCBNb3poaSBQZXJ1 bWFsPC9hPjwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7IGZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+U2VudDogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+4oCOMTkv4oCO MDYv4oCOMjAxNSAyMToxOTwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+VG86IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPjxh IGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2Js YW5rIj5DaHJpc3RlciBIb2xtYmVyZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPkNjOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj48YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+TWFydGluIFRob21zb248L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJv YmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+QmVybmFyZCBBYm9iYTwvYT47IDxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnJ0Y3dlYkBpZXRmLm9y ZzwvYT48L3NwYW4+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPlN1YmplY3Q6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPlJlOiBbcnRj d2ViXSBDb21tZW50IG9uIGNvbnNlbnQtZnJlc2huZXNzLTE0PC9zcGFuPjx1PjwvdT48dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZiI+QnV0IHRoZXJlIHdvdWxk IHN0aWxsIGJlIGxvc3Mgb2YgYXBwbGljYXRpb24gZGF0YSBmb3IgYXQgbGVhc3Qgb25lIFJUVCBi ZWZvcmUgY29uc2VudCBjYW4gYmUgcmVnYWluZWQuIFdvdWxkIHRoYXQgYmUgZGV2YXN0YXRpbmcg Zm9yIHZpZGVvIGlmIHRoZSBpbml0aWFsIHBhY2tldHMgc2VudCBhZnRlciByZXN1bXB0aW9uIGNv bnRhaW5lZA0KIHRoZSBJLWZyYW1lIChmb3IgZS5nLCB0aGUgdXNlciB0dXJucyBvZmYgdGhlIGNh bWVyYSBhbmQgdHVybnMgaXQgb24gYWZ0ZXIgYSBtaW51dGUpPzx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpBcmlhbCxzYW5zLXNlcmlmIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6QXJpYWwsc2Fucy1zZXJpZiI+TXV0aHU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91 PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEp1biAxOSwgMjAxNSBh dCAxMTowNiBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6bm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0 LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7IGJvcmRlci1sZWZ0LXdpZHRoOjFwdDsgcGFkZGluZzow Y20gMGNtIDBjbSA2cHQ7IG1hcmdpbi1sZWZ0OjQuOHB0OyBtYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+SGksPGJy Pg0KPGJyPg0KWW91IHJlLW9idGFpbiBjb25zZW50IHVzaW5nIFNUVU4uPGJyPg0KPGJyPg0KUmVn YXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4NCjxicj4NClNlbnQgZnJvbSBteSBXaW5kb3dz IFBob25lPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlciI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMnB0Ij48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWls eTpDYWxpYnJpLHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5NYXJ0aW4gVGhvbXNvbjwvYT48L3NwYW4+PGJyPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2Vy aWYiPlNlbnQ6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPuKAjjE5L+KAjjA2L+KAjjIwMTUgMjA6MjU8L3NwYW4+ PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyBmb250LWZhbWlseTpDYWxpYnJp LHNhbnMtc2VyaWYiPlRvOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsg Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Q2hyaXN0ZXIgSG9sbWJlcmc8 L2E+PC9zcGFuPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsgZm9udC1mYW1p bHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj5DYzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExcHQ7IGZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRv Om11dGh1LmFydWxAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+TXV0aHUgQXJ1bCBNb3poaSBQ ZXJ1bWFsPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPkJlcm5hcmQgQWJvYmE8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5z LXNlcmlmIj5TdWJqZWN0OiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsg Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj5SZTogW3J0Y3dlYl0gQ29tbWVudCBvbiBj b25zZW50LWZyZXNobmVzcy0xNDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwcHQiPk9uIDE5IEp1bmUgMjAxNSBhdCAxMDoyMCwgQ2hyaXN0ZXIgSG9s bWJlcmc8YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZndDsgJnF1b3Q7V2hlbiB0aGUgZW5kcG9pbnQgd2FudHMgdG8gc3Rh cnQgc2VuZGluZyBkYXRhIGFnYWluLCBpdCBmaXJzdCBuZWVkcyB0byByZS1vYnRhaW48YnI+DQom Z3Q7IGNvbnNlbnQsIHNvIGl0IHN0YXJ0cyB0aGUgc2VuZGluZyBvZiBjb25zZW50IHJlcXVlc3Rz IGFjY29yZGluZyB0byB0aGUgcHJvY2VkdXJlcyBpbiB0aGlzIGRvY3VtZW50PGJyPg0KJmd0OyAo dGhlIGVuZHBvaW50IGRvZXMgbm90IG5lZWQgdG8gcGVyZm9ybSBJQ0UgcmVzdGFydCBpbiB0aGlz IGNhc2UpLiZxdW90Ozxicj4NCjxicj4NCjxicj4NClBhY2tldCBsb3NzIGlzIGdvaW5nIHRvIGJl IGRldmFzdGF0aW5nIHRvIHBlcmZvcm1hbmNlIGlmIHlvdSBqdXN0PGJyPg0Kc3RhcnQgY2hlY2tp bmcgYWdhaW4uJm5ic3A7IFNob3VsZCB3ZSBhbHNvIHJlY29tbWVuZCAob3IgYWxsb3cpIHRoZSB1 c2Ugb2Y8YnI+DQphIFNUVU4gdHJhbnNhY3Rpb24gdG8gcmVnYWluIGNvbnNlbnQ/PHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D8F4C91ESESSMB209erics_-- From nobody Sun Jun 21 01:50:18 2015 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 5300F1A1B89 for ; Sun, 21 Jun 2015 01:50:17 -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 m6AV_U2ozct7 for ; Sun, 21 Jun 2015 01:50:14 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA421A1B81 for ; Sun, 21 Jun 2015 01:50:14 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so50309302wib.1 for ; Sun, 21 Jun 2015 01:50:13 -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=PySwOtWXHDBEpr0KWraxqKj+gQh8FxQ6p01ZK9isJNY=; b=id5KUOKBViEmn9/avrLKafVu3c8SXwjtLoH0cwVYV0ylRswJ6sTY2CndaifTmC7PIC BjeNV7Hs3hye6UqaD4qq/duVeJAq+Y2vb18s5jamZiwaoQbEeQ6msdIqJQB2+K2oCmTa sewnJYjsqOb89JL0H3YDlO0OB9hsJfh7ogOQeDJRUI+vzUFM/n3d8Wo8h/hyJtrLTxYk PnqlG8MoUA//gr/PxXSL+NSG6fR3/T5lSp5fqOVd5g1OlIiXgR1KOs3PKgi4rV8gT+ej hchbQBwpdmme6ZfA/+rUthMm/bI7MJ9PLNC6RcMjW8WVC65kmpKDO/KT2a7dh5fpJfwA 61hA== MIME-Version: 1.0 X-Received: by 10.180.23.8 with SMTP id i8mr21831871wif.39.1434876612992; Sun, 21 Jun 2015 01:50:12 -0700 (PDT) Received: by 10.180.35.7 with HTTP; Sun, 21 Jun 2015 01:50:12 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8F4C91@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8F266A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F2E37@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F371C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F376E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F3806@ESESSMB209.ericsson.se> <8B048618-F0AB-435A-A6E4-50A7500F9C26@gmail.com> <5585463C.5030005@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D8F4C91@ESESSMB209.ericsson.se> Date: Sun, 21 Jun 2015 14:20:12 +0530 Message-ID: From: Muthu Arul Mozhi Perumal To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013d12cad061d70519033e84 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Comment on consent-freshness-14 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, 21 Jun 2015 08:50:17 -0000 --089e013d12cad061d70519033e84 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree, most of the implementations would do that. Perhaps, some experimental/constrained implementation would do otherwise... Muthu On Sun, Jun 21, 2015 at 12:40 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I think a good implementation will always maintain consent on some > pair(s), even if no application data I sent. Again, the suggestion is not > to forbid that... > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Muthu Arul Mozhi Perumal > Sent: =E2=80=8E21/=E2=80=8E06/=E2=80=8E2015 08:44 > To: Bernard Aboba > Cc: Christer Holmberg ; Martin Thomson > ; rtcweb@ietf.org > > Subject: Re: [rtcweb] Comment on consent-freshness-14 > > That's true at the beginning of the session, but if the user mutes the > source during the session and the browser decides not to maintain consent > because no application data is being sent, it may have to rely on the > arrival of application data to regain consent, which can lead to packet > loss for at least one RTT.. > > Muthu > > On Sun, Jun 21, 2015 at 12:56 AM, Bernard Aboba > wrote: > >> The trigger is the browser ICE implementation deciding which pair(s) to >> send data on. So the browser doesn't have to anticipate app behavior fo= r >> this issue to be relevant. >> >> >> >> On Jun 20, 2015, at 2:55 PM, Muthu Arul Mozhi Perumal < >> muthu.arul@gmail.com> wrote: >> >> On Sat, Jun 20, 2015 at 2:43 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >>> >>> >But unless the application starts sending data, consent will not be >>> regained, so it is a chicken-and-egg problem -:) >>> >>> >>> >>> I don=E2=80=99t understand. You always have to (re)gain consent, using = STUN, >>> before you send application data. That=E2=80=99s the whole idea of the = mechanism, >>> and nothing that has been suggested here changes that. >>> >> >> =E2=80=8B >> The question is, how would the browser know that the application is abou= t >> to send data so that it can regain consent before the application data >> arrives? Isn't the trigger for the browser to regain consent application >> data itself? >> >> I am however okay to keep it outside the scope of this document and >> figured out elsewhere. It looks we don't to need change any text in the >> document then. Perhaps, we could make it explicit that consent needs to = be >> regained. >> >> Current text: >> An endpoint that is not sending any application data does not need >> to >> maintain consent. >> >> New text: >> An endpoint that is not sending any application data after obtaining >> consent does not need to maintain consent, but the endpoint MUST rega= in >> consent before it resumes sending application data. >> >> Muthu >> =E2=80=8B >> >> >>> >>> >>> And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby=E2=80= =9D. Or, if you >>> know that you are going to start sending application data on a new >>> candidate pair, you can regain consent while still sending application = data >>> on the previous candidate. >>> >> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> Some of the possible solutions: >>> >>> - ICE restart -- too much of overhead and possible O/A race conditions, >>> don't like. >>> >>> - Endpoint buffers the application data till consent is regained -- >>> kluge, don't like. >>> >>> - Allow the endpoint to resume sending application data using the >>> consent it had when it stopped sending -- could open a backdoor, still >>> don't like. >>> >>> - Keep maintaining consent irrespective of whether application data is >>> sent or not -- simple, serves as a heartbeat in the absence of applicat= ion >>> data, helps to keep NAT bindings alive and helps to refine RTT. The tra= de >>> off is some network bandwidth, but I think it is insignificant (some >>> keepalives would be sent anyway), so like it. >>> >>> >>> >>> Muthu >>> >>> >>> >>> On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>> Hi, >>> >>> In order to avoid loss of data, you shall not start sending data until >>> you have regained consent, similar to when the session was established. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> ------------------------------ >>> >>> *From: *Muthu Arul Mozhi Perumal >>> *Sent: *=E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 21:19 >>> *To: *Christer Holmberg >>> *Cc: *Martin Thomson ; Bernard Aboba >>> ; rtcweb@ietf.org >>> *Subject: *Re: [rtcweb] Comment on consent-freshness-14 >>> >>> But there would still be loss of application data for at least one RTT >>> before consent can be regained. Would that be devastating for video if = the >>> initial packets sent after resumption contained the I-frame (for e.g, t= he >>> user turns off the camera and turns it on after a minute)? >>> >>> >>> >>> Muthu >>> >>> >>> >>> On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>> Hi, >>> >>> You re-obtain consent using STUN. >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> ------------------------------ >>> >>> *From: *Martin Thomson >>> *Sent: *=E2=80=8E19/=E2=80=8E06/=E2=80=8E2015 20:25 >>> *To: *Christer Holmberg >>> *Cc: *Muthu Arul Mozhi Perumal ; Bernard Aboba >>> ; rtcweb@ietf.org >>> *Subject: *Re: [rtcweb] Comment on consent-freshness-14 >>> >>> On 19 June 2015 at 10:20, Christer Holmberg >>> wrote: >>> > "When the endpoint wants to start sending data again, it first needs >>> to re-obtain >>> > consent, so it starts the sending of consent requests according to th= e >>> procedures in this document >>> > (the endpoint does not need to perform ICE restart in this case)." >>> >>> >>> Packet loss is going to be devastating to performance if you just >>> start checking again. Should we also recommend (or allow) the use of >>> a STUN transaction to regain consent? >>> >>> >>> >>> >>> >> >> > --089e013d12cad061d70519033e84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree, most of the implementations woul= d do that. Perhaps, some experimental/constrained implementation would do o= therwise...

Muthu
<= /div>

On Sun, Jun = 21, 2015 at 12:40 PM, Christer Holmberg <christer.holmberg@er= icsson.com> wrote:
Hi,

I think a good implementation will always maintain consent on some pair(s),= even if no application data I sent. Again, the suggestion is not to forbid= that...

Regards,

Christer

Sent from my Windows Phone
From: Muthu Arul Mozhi Peruma= l
Sent: =E2=80= =8E21/=E2=80=8E06/=E2=80=8E2015 08:44
To: Bernard Aboba
Cc: Christer Holm= berg; Martin Thomso= n; rtcweb@ietf.org

Subject: Re: [r= tcweb] Comment on consent-freshness-14

That's true at the beginning of the session, but if the user mutes the = source during the session and the browser decides not to maintain consent b= ecause no application data is being sent, it may have to rely on the arriva= l of application data to regain consent, which can lead to packet loss for at least one RTT..

Muthu

On Sun, Jun 21, 2015 at 12:56 AM, Bernard Aboba = <bernard.ab= oba@gmail.com> wrote:
The trigger is the browser ICE implementation deciding which pair(s) t= o send data on.=C2=A0 So the browser doesn't have to anticipate app beh= avior for this issue to be relevant.



On Jun 20, 2015, at 2:55 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote= :

On Sat, Jun 20, 2015 at 2:43 PM, Ch= rister Holmberg <christer.holmb= erg@ericsson.com> wrote:

Hi,

=C2=A0

>But= unless the application starts sending data, consent will not be regained, = so it is a chicken-and-egg problem -:)

= =C2=A0

I don=E2=80=99t understand. You always have to (re)gain consent, = using STUN, before you send application data. That=E2=80=99s the whole idea= of the mechanism, and nothing that has been suggested here changes that.


=E2=80=8B
The question is, how= would the browser know that the application is about to send data so that = it can regain consent before the application data arrives? Isn't the tr= igger for the browser to regain consent application data itself?

I am however okay to keep it outside the scope of this document and figured= out elsewhere. It looks we don't to need change any text in the docume= nt then. Perhaps, we could make it explicit that consent needs to be regain= ed.

Current text:
=C2=A0 =C2=A0An endpoint that is not sending any application data does= not need to
=C2=A0 =C2=A0maintain consent.

New text:
=C2=A0 =C2=A0An endpoint that is not sending any application data afte= r obtaining=C2=A0
=C2=A0 =C2=A0consent does not need to maintain consent, but the endpoi= nt MUST regain
=C2=A0 =C2=A0consent before it resumes sending application data.

=C2=A0Muthu
=E2=80=8B
=C2=A0

=C2=A0

And, as Bernard said, it is ok to maintain a =E2=80=9Chot standby= =E2=80=9D. Or, if you know that you are going to start sending application = data on a new candidate pair, you can regain consent while still sending application data on the previous candidate.=C2= =A0

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

Some of= the possible solutions:

- ICE r= estart -- too much of overhead and possible O/A race conditions, don't = like.

- Endpo= int buffers the application data till consent is regained -- kluge, don'= ;t like.

- Allow= the endpoint to resume sending application data using the consent it had w= hen it stopped sending -- could open a backdoor, still don't like.

- Keep = maintaining consent irrespective of whether application data is sent or not= -- simple, serves as a heartbeat in the absence of application data, helps= to keep NAT bindings alive and helps to refine RTT. The trade off is some network bandwidth, but I think it is = insignificant (some keepalives would be sent anyway), so like it.=

= =C2=A0

Muthu

=C2=A0

On Sat, Jun 20, 2015 at 12:17 AM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

In order to avoid loss of data, you shall not start sending data until you = have regained consent, similar to when the session was established.

Regards,

Christer

Sent from my Windows Phone

From: Muthu Arul Mozhi Pe= rumal
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 21:19
To: Christer Holmb= erg
Cc: Martin Thomson; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: <= /span>Re:= [rtcweb] Comment on consent-freshness-14

But the= re would still be loss of application data for at least one RTT before cons= ent can be regained. Would that be devastating for video if the initial pac= kets sent after resumption contained the I-frame (for e.g, the user turns off the camera and turns it on after = a minute)?

= =C2=A0

Muthu

=C2=A0

On Fri, Jun 19, 2015 at 11:06 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

You re-obtain consent using STUN.

Regards,

Christer

Sent from my Windows Phone

From: Martin Thomson<= /a>
Sent: =E2=80= =8E19/=E2=80=8E06/=E2=80=8E2015 20:25
To: Christer Holmb= erg
Cc: Muthu Arul Mozhi Perumal= ; Bernard Aboba<= /a>; rtcweb@ietf.org
Subject: <= /span>Re:= [rtcweb] Comment on consent-freshness-14

On 19 June 2015 at 10= :20, Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:
> "When the endpoint wants to start sending data again, it first ne= eds to re-obtain
> consent, so it starts the sending of consent requests according to the= procedures in this document
> (the endpoint does not need to perform ICE restart in this case)."= ;


Packet loss is going to be devastating to performance if you just
start checking again.=C2=A0 Should we also recommend (or allow) the use of<= br> a STUN transaction to regain consent?

=C2=A0

=C2=A0




--089e013d12cad061d70519033e84-- From nobody Mon Jun 22 02:34:53 2015 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 6D9951B2EAA for ; Mon, 22 Jun 2015 02:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_19=0.6, 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 CSM1ht0YWLOQ for ; Mon, 22 Jun 2015 02:34: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 B916E1B2EA7 for ; Mon, 22 Jun 2015 02:34:49 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-93-5587d6b7d84d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.B1.17665.7B6D7855; Mon, 22 Jun 2015 11:34:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.210.2; Mon, 22 Jun 2015 11:34:47 +0200 Message-ID: <5587D6B6.40609@ericsson.com> Date: Mon, 22 Jun 2015 11:34:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "rtcweb@ietf.org" , Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZGfG3VnfHtfZQg5/rWSzmd6xjs1j7r53d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mpom3aSreAUd0V30z7mBsbVnF2MnBwSAiYS L1YsYYKwxSQu3FvP1sXIxSEkcJRR4uin72AJIYHljBJdu51BbF4BTYnJl46zgtgsAqoS2490 gNlsAhYSN380soHYogJRElMfr2OBqBeUODnzCZgtIhAksW5hN9hMZgFDiYnfdzKC2MICChIn ds8F6uUAittLPNhaBlEiL9G8dTYzxAnaEg1NHawTGPlnIZk6C6FjFpKOBYzMqxhFi1OLi3PT jYz1Uosyk4uL8/P08lJLNjECQ+/glt+6OxhXv3Y8xCjAwajEw6uQ0x4qxJpYVlyZe4hRmoNF SZx3xua8UCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MHR+8pz0X5XuYurTv8xena3sefvwh 3fdevM1ihZ/jnrniz7XeSOk7pRzpUO/3Kviy2NO0/4au6GH10E7GX3afxN5rWLg3T/ldEskd ljbb9wNH+0lXw+f/Iip/72JqXXH9lIBW/leN5UUlOd/bOG9MEjutck3i7Pc5IYLfvu4tVtK4 47TvxdMXSizFGYmGWsxFxYkAyqUKMx4CAAA= Archived-At: Subject: [rtcweb] JSEP: Imageattr and CVO 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, 22 Jun 2015 09:34:51 -0000 Hi, I got an action point at the interim to check on what 3GPP and GSMA says about their usage of a=imageattr and CVO (Coordination of Video Orientation). 3GPP SA4 in TS 26.114 (Which defines CVO) there is discussion about the usage of a=imageattr when a endpoint is not CVO capable, but it appears to fail to be explicit about interpretation of imageattr when using CVO. As the text says that for a non CVO capable endpoint one have to express both orientations (x,y) and (y,x) in imageattr and perform the rotation prior to encoding. This appear to support the proposed interpretation for JSEP, i.e. that one expresses the supported max resolution without rotation using imageattr. Bo Burman intend to prepare an contribution to 3GPP SA4 in their upcoming meeting in two weeks time and see if SA4 can come to agreement on this interpretation and write it into their specifications. So in time for Prague we will hopefully be able to conclude on this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jun 22 04:20:05 2015 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 110691B2F78 for ; Mon, 22 Jun 2015 04:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 HTDaROKm653c for ; Mon, 22 Jun 2015 04:20:02 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id AD4391B2F76 for ; Mon, 22 Jun 2015 04:20:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 862D37C32F2 for ; Mon, 22 Jun 2015 13:20: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 K0kXXsv_xiy2 for ; Mon, 22 Jun 2015 13:20:00 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:d51f:e4f1:be20:a73b]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5F6177C3282 for ; Mon, 22 Jun 2015 13:20:00 +0200 (CEST) Message-ID: <5587EF5F.5040805@alvestrand.no> Date: Mon, 22 Jun 2015 13:19:59 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.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: Subject: [rtcweb] LS groups (Re: Cullen Notes from RTCWeb interim on June 18, 2015) 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, 22 Jun 2015 11:20:05 -0000 On 06/18/2015 08:00 PM, Cullen Jennings (fluffy) wrote: > * make sure to add note well slide to slide deck > > LS Behavior > - Magnus points out that if JSEP overrides 5888, we will have issue with legacy things > - Martin points needs more thought to make declarative groups > - Martin raised point that we might be able to add some extra signaling that indicates that we can support this declarative LS usage > > Conclusion: Magnus will dig into more analysis of options on this and send to list. No decision on Option 1,2 > Just FWIW: Personally, I don't see the added value in adding LS groups. We already have a well defined, declarative (=one-way) means of declaring synchronization in the form of the MSID values, which bind MediaStreamTracks into MediaStreams, which you're supposed to try syncing if you can (it's not a hard requirement in the spec that you should succeed). If we want to be extra helpful for non-WebRTC implementations, and end up in the case where we have one audio and one video track from one stream in one direction using the same media descriptions as an audio and video track in the other direction (which will be the normal case when your application is trying to emulate a single-channel VC unit), I have no particular problems with adding LS group markings to those media descriptions - but I don't want to spend resources changing the semantics of LS groups (and thereby imperiling the exact interworking we're trying to make easier) when we already have something that fulfils all the requirements for a pure WebRTC scenario. My $0.02. From nobody Mon Jun 22 22:24:40 2015 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 41AEE1A1BED; Mon, 22 Jun 2015 22:24: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 m0uZsCBM6x4e; Mon, 22 Jun 2015 22:24:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 360B11A1BA5; Mon, 22 Jun 2015 22:24:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150623052437.10453.24881.idtracker@ietfa.amsl.com> Date: Mon, 22 Jun 2015 22:24:37 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-15.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: Tue, 23 Jun 2015 05:24:38 -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-15.txt Pages : 10 Date : 2015-06-22 Abstract: To prevent WebRTC applications, such as browsers, from launching attacks by sending media to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. 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: https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-15 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 Jun 22 22:46:26 2015 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 2A0201A86F0 for ; Mon, 22 Jun 2015 22:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 cBZH-b_Z69CG for ; Mon, 22 Jun 2015 22:46:22 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917B91A86E6 for ; Mon, 22 Jun 2015 22:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2240; q=dns/txt; s=iport; t=1435038382; x=1436247982; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FRlk1DBGAexYuELrqOrDxaF1xmGql9ChaT0gfHgbOTI=; b=WtkuMDlDU3HS9Ip1dv7PlHBtWjf3u71hHC4IaCaGTwr7ZkAJoTTo8S+D Jl2+AHIF1L9ljL1C6NLpyu6GwusOya6eesy/DMt1WU/UaOelI7i/qGlBc 53ZrH+N48pH5TQgzJk9bxxTXGxgB//DuFK82VcxlNc2o7yTv6HbxiCDPb Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DrAwCK8YhV/5BdJa1cgxBUXwa8a2YJgVwMhSxKAoE8OBQBAQEBAQEBgQqEIgEBAQQBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBA4FCIgnDctQAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tFhFUxBwaDEYEUBZN9AYRViDJBg0ySaiaDeW+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,664,1427760000"; d="scan'208";a="9483117" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 23 Jun 2015 05:46:21 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5N5kL0b013802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 05:46:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Tue, 23 Jun 2015 00:46:21 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-15.txt Thread-Index: AQHQrXTtuJYO+QFKd0qBJyQBvibd7Z25k/iA Date: Tue, 23 Jun 2015 05:46:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A4787C4A9@xmb-rcd-x10.cisco.com> References: <20150623052437.10453.24881.idtracker@ietfa.amsl.com> In-Reply-To: <20150623052437.10453.24881.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.63.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-15.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, 23 Jun 2015 05:46:24 -0000 This revision addresses comment on regaining consent before the endpoint re= sumes sending application data. -Tiru > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, June 23, 2015 10:55 AM > To: i-d-announce@ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-15= .txt >=20 >=20 > 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-browsers > Working Group of the IETF. >=20 > 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-15.txt > Pages : 10 > Date : 2015-06-22 >=20 > Abstract: > To prevent WebRTC applications, such as browsers, from launching > attacks by sending media to unwilling victims, periodic consent to > send needs to be obtained from remote endpoints. >=20 > This document describes a consent mechanism using a new Session > Traversal Utilities for NAT (STUN) usage. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness= / >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshn= ess-15 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Jun 23 14:57:46 2015 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 C826C1A895B for ; Tue, 23 Jun 2015 14:57:44 -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 8pQFFtG1jxp7 for ; Tue, 23 Jun 2015 14:57:43 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F7D1A892B for ; Tue, 23 Jun 2015 14:57:43 -0700 (PDT) Received: by ieqy10 with SMTP id y10so21398762ieq.0 for ; Tue, 23 Jun 2015 14:57:43 -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=AeJqQFRlQvRE7k/4YLrtWPlttL+lyabKJ7OVfL/AjGk=; b=mprBwN6jySYuSWbdVDmlCAVA1cgd2kzKOULnOvwQ6rszDTD6FUYxZBKsF9d7FhMOGp sNsDgI9CQGLdtNHoMpyOrDqWJtdsHRGIbnnxjQLilU8Ih/Nr1+1OQudakybXcDSrHmh3 kMxEVUbEYlYGccg6rZD3CKTJJ0QB2r2GSU/60ktLsvmTP9xoIoaHNfHlTKPNroD3JrGf +23hBEw3qgDGhQVNaxUk5g+RlkURLFD3HLVriFb/Ew0VUKlhcEVfbITXQY/NGAl6cqFF D/1mWLOyUdzKm59cMMPzfsLKJcwqEGIfi7bq3fj+XkMrZ6qeR8+e9XBGCtXEFO12gku4 V/RA== X-Gm-Message-State: ALoCoQka/4p68SnFf8iHNKgThFMl8CzhitgJ29zAkI3ZVo+ELfil4OBm7Q3vAhkZgB7tLkvhMnpw X-Received: by 10.50.176.228 with SMTP id cl4mr5153025igc.2.1435096663069; Tue, 23 Jun 2015 14:57:43 -0700 (PDT) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com. [209.85.213.178]) by mx.google.com with ESMTPSA id j20sm642136igt.5.2015.06.23.14.57.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2015 14:57:41 -0700 (PDT) Received: by igin14 with SMTP id n14so21772874igi.1 for ; Tue, 23 Jun 2015 14:57:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.64.244 with SMTP id r20mr4949476igs.33.1435096660836; Tue, 23 Jun 2015 14:57:40 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Tue, 23 Jun 2015 14:57:40 -0700 (PDT) Date: Tue, 23 Jun 2015 17:57:40 -0400 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7bea3d22b02dfb0519367a83 Archived-At: Subject: [rtcweb] Consent freshness for TURN servers 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, 23 Jun 2015 21:57:44 -0000 --047d7bea3d22b02dfb0519367a83 Content-Type: text/plain; charset=UTF-8 Hi All, I wanted to see if there is a consent check issued by the TURN server to verify that remote party is willing to accept media. Is this something that is planned or do TURN servers suppose to rely that the clients sending media through TURN servers will perform their own consent checks and simply trust the client? Regards, _____________ Roman Shpount --047d7bea3d22b02dfb0519367a83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

I wanted to see if there is a c= onsent check issued by the TURN server to verify that remote party is willi= ng to accept media. Is this something that is planned or do TURN servers su= ppose to rely that the clients sending media through TURN servers will perf= orm their own consent checks and simply trust the client?

Regards,
_____________
R= oman Shpount
--047d7bea3d22b02dfb0519367a83-- From nobody Wed Jun 24 00:48:54 2015 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 42CC31B314E for ; Wed, 24 Jun 2015 00:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 FZC5U6S-v5vS for ; Wed, 24 Jun 2015 00:48:51 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445721B3146 for ; Wed, 24 Jun 2015 00:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=718; q=dns/txt; s=iport; t=1435132131; x=1436341731; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=eJH1RxqBClT57VzXegTwj0Uzhza23MFYRUocDc4gC3U=; b=fF2rN5l0vXCSEjDDCz08EEAx6VopU3yA/09dU4tXGDybxtCL2odkUC+A ELkUbSS8pACfRYAsHHnSWJMKlmiXzTkSQ71mQg8P2EY3xAE608hOyNijc OjR+XBZmfFfy4JTJM8UlBx6A5pxvhl0HH33VgzAnik4iSm9M6tmm/8RQq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C3CwBPYIpV/5FdJa1bgxCBM7k9hDSHXgKBSDoSAQEBAQEBAYEKQQODXwEBBDo/EAsYGRVXBhOIL80tAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhDsYMweDF4EUBYx9hwKLUYg1kAAmY4M3HjFmBRolgR4BAQE X-IronPort-AV: E=Sophos;i="5.13,671,1427760000"; d="scan'208";a="162396836" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jun 2015 07:48:50 +0000 Received: from [10.24.206.20] ([10.24.206.20]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5O7miCK007005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2015 07:48:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 23 Jun 2015 23:28:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> References: To: Roman Shpount X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 24 Jun 2015 07:48:52 -0000 On 23-Jun-2015 02:57 pm, Roman Shpount wrote:=20 > I wanted to see if there is a consent check issued by the TURN server = to verify that remote party is willing to accept media. Is this = something that is planned or do TURN servers suppose to rely that the = clients sending media through TURN servers will perform their own = consent checks and simply trust the client? The TURN server doesn't know the ice-passwd between the two peers, which = is necessary to create a valid STUN request (or to validate the STUN = response). If we decide it necessary, the TURN server could watch for = consent check packets and tear down the channel binding if none seen in = NNN seconds. -d From nobody Wed Jun 24 07:32:52 2015 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 1C1CF1A1A4A for ; Tue, 23 Jun 2015 21:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, 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 6THP3v4V3x7c for ; Tue, 23 Jun 2015 21:28:41 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5AF71A0015 for ; Tue, 23 Jun 2015 21:28:41 -0700 (PDT) Received: by oiax193 with SMTP id x193so21960610oia.2 for ; Tue, 23 Jun 2015 21:28:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=CY1bPP7IQKcn7C43yIBh+rPeLRS0ziDNoSOyOUb1LwI=; b=Pp12X5qYHCvN+7hawdmAqxx+kgWzgd6X2gD6d8QgN8U10M/lNIPbYtxWHUT9aK1ANq YQ2jEnRIoALgJqRsb80MjMIjvcVbprU2M4e719M5d/8lC73wDJ8DOA90uK3wCE7eEpZB y/SfnkaVzWjPRVy2yxvmKAB+WwyQodPcpEw0W1ZNVnAhpDOKS59ebbyLbd13g9XjRmCT iAkvzkaj11qeN/6I1Cl+d2SiqAaE7jMTXUV5/gJBDvek010Xckqk8GRoipPTVyoR9FcQ mAqLDTmD6KrKO9uVteGMOzbgIjtUs7f4qlTreUQRracBrrRcyXKK5ubJyKiL7xmgVvRR qWgg== X-Received: by 10.182.199.103 with SMTP id jj7mr33279016obc.49.1435120121225; Tue, 23 Jun 2015 21:28:41 -0700 (PDT) MIME-Version: 1.0 References: <5587D6B6.40609@ericsson.com> In-Reply-To: <5587D6B6.40609@ericsson.com> From: Justin Uberti Date: Wed, 24 Jun 2015 04:28:31 +0000 Message-ID: To: Magnus Westerlund , "rtcweb@ietf.org" , draft-ietf-rtcweb-jsep@tools.ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c9ec0929ed05193bf143 Archived-At: X-Mailman-Approved-At: Wed, 24 Jun 2015 07:32:46 -0700 Subject: Re: [rtcweb] JSEP: Imageattr and CVO 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, 24 Jun 2015 04:28:43 -0000 --e89a8ff1c9ec0929ed05193bf143 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great. Thanks for tracking this down. On Mon, Jun 22, 2015 at 2:35 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I got an action point at the interim to check on what 3GPP and GSMA says > about their usage of a=3Dimageattr and CVO (Coordination of Video > Orientation). > > 3GPP SA4 in TS 26.114 (Which defines CVO) there is discussion about the > usage of a=3Dimageattr when a endpoint is not CVO capable, but it appears > to fail to be explicit about interpretation of imageattr when using CVO. > As the text says that for a non CVO capable endpoint one have to express > both orientations (x,y) and (y,x) in imageattr and perform the rotation > prior to encoding. > > This appear to support the proposed interpretation for JSEP, i.e. that > one expresses the supported max resolution without rotation using > imageattr. > > Bo Burman intend to prepare an contribution to 3GPP SA4 in their > upcoming meeting in two weeks time and see if SA4 can come to agreement > on this interpretation and write it into their specifications. So in > time for Prague we will hopefully be able to conclude on this. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --e89a8ff1c9ec0929ed05193bf143 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great. Thanks for tracking this down.

On Mon, Jun 22, 2015 at 2:35 AM Magnus We= sterlund <magnus.weste= rlund@ericsson.com> wrote:
H= i,

I got an action point at the interim to check on what 3GPP and GSMA says about their usage of a=3Dimageattr and CVO (Coordination of Video
Orientation).

3GPP SA4 in TS 26.114 (Which defines CVO) there is discussion about the
usage of a=3Dimageattr when a endpoint is not CVO capable, but it appears to fail to be explicit about interpretation of imageattr when using CVO. As the text says that for a non CVO capable endpoint one have to express both orientations (x,y) and (y,x) in imageattr and perform the rotation
prior to encoding.

This appear to support the proposed interpretation for JSEP, i.e. that
one expresses the supported max resolution without rotation using
imageattr.

Bo Burman intend to prepare an contribution to 3GPP SA4 in their
upcoming meeting in two weeks time and see if SA4 can come to agreement
on this interpretation and write it into their specifications. So in
time for Prague we will hopefully be able to conclude on this.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--e89a8ff1c9ec0929ed05193bf143-- From nobody Wed Jun 24 15:52:03 2015 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 5C72D1A899D for ; Wed, 24 Jun 2015 15:52:02 -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, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Fpala2n60qNy for ; Wed, 24 Jun 2015 15:52:01 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD0B1A1F73 for ; Wed, 24 Jun 2015 15:52:01 -0700 (PDT) Received: by iecvh10 with SMTP id vh10so43253089iec.3 for ; Wed, 24 Jun 2015 15:52:00 -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=7kowYuoiR8MUoBHqsLWQ/cPTLsT0rxUGNAqwvKW0iOU=; b=EJclqSYUoKQ396APBBasbgt8mhDdHj3EOY5qnDt78vUQSxpHKMSXvk91dl9ap3wIuL FT483w/k9oD4+FSzRYszMut5CQqs4gMQWUK0Jxe4tqS/yTUzbqSlTL/+WGRBJLR++Mgf 7omcJwKAqSAyCLL10dj25MWys/MM8Ejm1sSRylxW0AsNkCSE6joPurUgGRe4koPgA6qh Z+IGtDVApv4qbmj7hPHtqxmbuAt0nd64tIbBga3oUhBgTNjTaZ3DLM6uGppTtiFB2f7r xoq+iTGZzJdkfPY24NKjg4aOV87ks4LbMJOz7zvYhcaoj8kbdymZHLi6A0nRXd1f6XkW qNJw== X-Gm-Message-State: ALoCoQmvaTJdl2MxkcGC4h5zKKeXZAcMfxliu3OBm+WIMsATKpf5Y+LGmOjxjZfqR7RH4DSiXK9R X-Received: by 10.43.171.202 with SMTP id nv10mr39739267icc.30.1435186320515; Wed, 24 Jun 2015 15:52:00 -0700 (PDT) Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com. [209.85.213.170]) by mx.google.com with ESMTPSA id 137sm18314096ioo.29.2015.06.24.15.51.58 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 15:51:59 -0700 (PDT) Received: by igblr2 with SMTP id lr2so44035242igb.0 for ; Wed, 24 Jun 2015 15:51:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.43.54.20 with SMTP id vs20mr18803110icb.96.1435186318573; Wed, 24 Jun 2015 15:51:58 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Wed, 24 Jun 2015 15:51:58 -0700 (PDT) In-Reply-To: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> Date: Wed, 24 Jun 2015 18:51:58 -0400 Message-ID: From: Roman Shpount To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: multipart/alternative; boundary=bcaec51d2264b48f5005194b5acf Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 24 Jun 2015 22:52:02 -0000 --bcaec51d2264b48f5005194b5acf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 24, 2015 at 2:28 AM, =F0=9F=94=93Dan Wing wro= te: > On 23-Jun-2015 02:57 pm, Roman Shpount wrote: > > I wanted to see if there is a consent check issued by the TURN server t= o > verify that remote party is willing to accept media. Is this something th= at > is planned or do TURN servers suppose to rely that the clients sending > media through TURN servers will perform their own consent checks and simp= ly > trust the client? > > The TURN server doesn't know the ice-passwd between the two peers, which > is necessary to create a valid STUN request (or to validate the STUN > response). If we decide it necessary, the TURN server could watch for > consent check packets and tear down the channel binding if none seen in N= NN > seconds. Was there discussion already if consent is necessary for TURN servers? I am trying to see if decision was already made or if the topic was not discussed yet. I can see how consent monitoring can be implemented by client sharing ICE pwd with the TURN server via an additional command or via additional parameter in Allocate or CreatePermission request. Regards, _____________ Roman Shpount --bcaec51d2264b48f5005194b5acf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 24, 2015 at 2:28 AM, =F0=9F=94=93Dan Wing <dwing@cisco.com> wrote:
On 23-Jun-2015 02:57 pm, = Roman Shpount <roman@telurix.com> wrote:
> I wanted to see if there is a consent check issued by the TURN server = to verify that remote party is willing to accept media. Is this something t= hat is planned or do TURN servers suppose to rely that the clients sending = media through TURN servers will perform their own consent checks and simply= trust the client?

The TURN server doesn't know the ice-passwd between the two peer= s, which is necessary to create a valid STUN request (or to validate the ST= UN response).=C2=A0 If we decide it necessary, the TURN server could watch = for consent check packets and tear down the channel binding if none seen in= NNN seconds.


<= div>I can see how consent monitoring can be implemented by client sharing I= CE pwd with the TURN server via an additional command or via=C2=A0additiona= l parameter in Allocate or CreatePermission request.=C2=A0
--bcaec51d2264b48f5005194b5acf-- From nobody Wed Jun 24 18:13:50 2015 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 317A01A1A69 for ; Wed, 24 Jun 2015 18:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 02v0EkfbXfDk for ; Wed, 24 Jun 2015 18:13:47 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9934B1A1A7B for ; Wed, 24 Jun 2015 18:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5724; q=dns/txt; s=iport; t=1435194827; x=1436404427; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=htSEg38nQL+n7+0PKE74ztemYMql9MuBrrvmnufL/to=; b=U8Mu3A5dxJas0V65PoPIOUFOl9Noo1dGVujJFfM2RF1axP5qxTTWb8Sh utOw+A0WrEY8d8m8UZyMSq09ENsu9Buj7O0QVe1q6xO4q16uY2LHUZ9vV dfU+/4Aitr1wSbU7oUYjLG2DWMUwDSdmzT9GMeR/DaAxKf1tkVEepUqKt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5BQD/VItV/51dJa1bgxGBM4MetUaMEgKBTDwQAQEBAQEBAYEKhCIBAQEDASNWBQsJAhgYAQ4DAgJGEQYTiCcImiWdGZY7AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tKhDtLBxiCUC+BFAWNAYcEi1GINZADJmODNx4xZgUaJYEeAQEB X-IronPort-AV: E=Sophos;i="5.13,674,1427760000"; d="scan'208,217";a="4445134" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jun 2015 01:13:46 +0000 Received: from [10.24.138.6] ([10.24.138.6]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t5P1DNxw004200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2015 01:13:46 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_8273FCF5-2BD4-4786-A11B-908342C6EA7B" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Wed, 24 Jun 2015 18:13:46 -0700 Message-Id: <73D84617-5DC0-463A-A913-3BC8B05C3169@cisco.com> References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 01:13:50 -0000 --Apple-Mail=_8273FCF5-2BD4-4786-A11B-908342C6EA7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 24-Jun-2015 03:51 pm, Roman Shpount wrote:=20 > On Wed, Jun 24, 2015 at 2:28 AM, =F0=9F=94=93Dan Wing > wrote: > On 23-Jun-2015 02:57 pm, Roman Shpount > wrote: > > I wanted to see if there is a consent check issued by the TURN = server to verify that remote party is willing to accept media. Is this = something that is planned or do TURN servers suppose to rely that the = clients sending media through TURN servers will perform their own = consent checks and simply trust the client? >=20 > The TURN server doesn't know the ice-passwd between the two peers, = which is necessary to create a valid STUN request (or to validate the = STUN response). If we decide it necessary, the TURN server could watch = for consent check packets and tear down the channel binding if none seen = in NNN seconds. >=20 > Was there discussion already if consent is necessary for TURN servers? = I am trying to see if decision was already made or if the topic was not = discussed yet. To my knowledge, it has not been discussed. Seems a good microphone = discussion for Prague. > I can see how consent monitoring can be implemented by client sharing = ICE pwd with the TURN server via an additional command or via additional = parameter in Allocate or CreatePermission request.=20 I suppose we could do that, but sharing the ICE password with the TURN = server feels wrong. The TURN server does not, itself, generate traffic. = Because it doesn't generate traffic itself, I don't think it needs to = have consent. It may well be valuable for the TURN server to verify the = client has obtained consent (by watching for consent request/response = across the TURN server), but that seems more a firewall function and = IETF typically shies away from defining firewall functions. -d --Apple-Mail=_8273FCF5-2BD4-4786-A11B-908342C6EA7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24-Jun-2015 03:51 pm, Roman Shpount <roman@telurix.com> = wrote:
On Wed, Jun 24, 2015 at = 2:28 AM, =F0=9F=94=93Dan Wing <dwing@cisco.com> wrote:
On 23-Jun-2015 02:57 pm, = Roman Shpount <roman@telurix.com> wrote:
> I wanted to see if there is a consent check issued by the TURN = server to verify that remote party is willing to accept media. Is this = something that is planned or do TURN servers suppose to rely that the = clients sending media through TURN servers will perform their own = consent checks and simply trust the client?

The TURN server doesn't know the ice-passwd between the two = peers, which is necessary to create a valid STUN request (or to validate = the STUN response).  If we decide it necessary, the TURN server = could watch for consent check packets and tear down the channel binding = if none seen in NNN seconds.

Was there discussion already if consent = is necessary for TURN servers? I am trying to see if decision was = already made or if the topic was not discussed = yet.

To my knowledge, it has not been discussed. =  Seems a good microphone discussion for Prague.

I can see how consent monitoring = can be implemented by client sharing ICE pwd with the TURN server via an = additional command or via additional parameter in Allocate or = CreatePermission request. 

I suppose we could do = that, but sharing the ICE password with the TURN server feels wrong. =  The TURN server does not, itself, generate traffic.  Because = it doesn't generate traffic itself, I don't think it needs to have = consent.  It may well be valuable for the TURN server to verify the = client has obtained consent (by watching for consent request/response = across the TURN server), but that seems more a firewall function and = IETF typically shies away from defining firewall functions.

-d

= --Apple-Mail=_8273FCF5-2BD4-4786-A11B-908342C6EA7B-- From nobody Thu Jun 25 02:53:09 2015 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 CB8911B34FA for ; Thu, 25 Jun 2015 02:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 G0KQ71j59Lr9 for ; Thu, 25 Jun 2015 02:53:05 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 05EA41B34C4 for ; Thu, 25 Jun 2015 02:53:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A0A7D7C358F for ; Thu, 25 Jun 2015 11:53:03 +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 zcp_cXbnJ_ka for ; Thu, 25 Jun 2015 11:53:01 +0200 (CEST) Received: from [10.21.145.167] (unknown [89.248.140.8]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9C9917C358E for ; Thu, 25 Jun 2015 11:53:01 +0200 (CEST) Message-ID: <558BCF77.2030602@alvestrand.no> Date: Thu, 25 Jun 2015 11:52:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050803020804010605050101" Archived-At: Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 09:53:08 -0000 This is a multi-part message in MIME format. --------------050803020804010605050101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 06/25/2015 12:51 AM, Roman Shpount wrote: > On Wed, Jun 24, 2015 at 2:28 AM, 🔓Dan Wing > wrote: > > On 23-Jun-2015 02:57 pm, Roman Shpount > wrote: > > I wanted to see if there is a consent check issued by the TURN > server to verify that remote party is willing to accept media. Is > this something that is planned or do TURN servers suppose to rely > that the clients sending media through TURN servers will perform > their own consent checks and simply trust the client? > > The TURN server doesn't know the ice-passwd between the two peers, > which is necessary to create a valid STUN request (or to validate > the STUN response). If we decide it necessary, the TURN server > could watch for consent check packets and tear down the channel > binding if none seen in NNN seconds. > > > Was there discussion already if consent is necessary for TURN servers? > I am trying to see if decision was already made or if the topic was > not discussed yet. I thought it was obvious that TURN servers are outside both ICE authentication flow and ICE consent flows - they just relay stuff, they have no separate data-generating role. If someone wants to make the argument that TURN servers need to have a different role from just being a TURN server, that's an interesting discussion to have - but I'd want to see the argument for this change in the model (it's a CHANGE, and we're late in the process) clearly laid out in text (preferably an I-D) before even accepting it as a discussion topic. Or to put it even more shortly: I think it's a bad idea, and we shouldn't spend time discussing it until somoene explains to the group why I might be wrong about that. > > I can see how consent monitoring can be implemented by client sharing > ICE pwd with the TURN server via an additional command or > via additional parameter in Allocate or CreatePermission request. > > Regards, > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------050803020804010605050101 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 06/25/2015 12:51 AM, Roman Shpount wrote:
On Wed, Jun 24, 2015 at 2:28 AM, 🔓Dan Wing <dwing@cisco.com> wrote:
On 23-Jun-2015 02:57 pm, Roman Shpount <roman@telurix.com> wrote:
> I wanted to see if there is a consent check issued by the TURN server to verify that remote party is willing to accept media. Is this something that is planned or do TURN servers suppose to rely that the clients sending media through TURN servers will perform their own consent checks and simply trust the client?

The TURN server doesn't know the ice-passwd between the two peers, which is necessary to create a valid STUN request (or to validate the STUN response).  If we decide it necessary, the TURN server could watch for consent check packets and tear down the channel binding if none seen in NNN seconds.

Was there discussion already if consent is necessary for TURN servers? I am trying to see if decision was already made or if the topic was not discussed yet.

I thought it was obvious that TURN servers are outside both ICE authentication flow and ICE consent flows - they just relay stuff, they have no separate data-generating role.

If someone wants to make the argument that TURN servers need to have a different role from just being a TURN server, that's an interesting discussion to have - but I'd want to see the argument for this change in the model (it's a CHANGE, and we're late in the process) clearly laid out in text (preferably an I-D) before even accepting it as a discussion topic.

Or to put it even more shortly: I think it's a bad idea, and we shouldn't spend time discussing it until somoene explains to the group why I might be wrong about that.


I can see how consent monitoring can be implemented by client sharing ICE pwd with the TURN server via an additional command or via additional parameter in Allocate or CreatePermission request. 

Regards,
_____________
Roman Shpount
 


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



-- 
Surveillance is pervasive. Go Dark.
--------------050803020804010605050101-- From nobody Thu Jun 25 05:30:15 2015 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 C98A01A013B for ; Thu, 25 Jun 2015 05:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 wCuiryfW_GfT for ; Thu, 25 Jun 2015 05:30:11 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 601C91A00EE for ; Thu, 25 Jun 2015 05:30:11 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 18BEFEC44E077; Thu, 25 Jun 2015 12:30:06 +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 t5PCU7rj020998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 12:30:08 GMT Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 08:30:07 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Consent freshness for TURN servers Thread-Index: AQHQrf+peED7acelCUCAxSUckpmf4Z27dQUAgAESyQCAALirgP//1MAg Date: Thu, 25 Jun 2015 12:30:06 +0000 Deferred-Delivery: Thu, 25 Jun 2015 12:30:00 +0000 Message-ID: References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> <558BCF77.2030602@alvestrand.no> In-Reply-To: <558BCF77.2030602@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_E1FE4C082A89A246A11D7F32A95A1782013D0755A2US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 12:30:14 -0000 --_000_E1FE4C082A89A246A11D7F32A95A1782013D0755A2US70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KyAxDQpBcyBJIHVuZGVyc3RhbmQsIHBlcmlvZGljIGNvbnNlbnQgYmV0d2VlbiBwZWVycyBhcmUg bmVlZGVkIGFzIHRoZXJlIGlzIG5vIG90aGVyIG1lY2hhbmlzbSB0byBrbm93IHRoZSBwZWVyIGlz IHN0aWxsIHdpbGxpbmcgdG8gcmVjZWl2ZSBhbmQgYWxzbyBhbGxvY2F0ZWQgdGhlIHJlc291cmNl cyBmb3IgdGhpcyBwZWVyLg0KSG93ZXZlciwgaW4gVFVSTiBjYXNlLCBUVVJOIGNsaWVudCBhbmQg VFVSTiBzZXJ2ZXIgY2FuIHVzZSBwcm9jZWR1cmVzIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1NzY2I3NlY3Rpb24tNyB0byByZWZyZXNoIHRoZSBhbGxvY2F0aW9uIHdpdGggY2Vy dGFpbiBsaWZlIHRpbWUuIFRoaXMgSSBiZWxpZXZlIHNlcnZlIHRoZSBzYW1lIHB1cnBvc2UgYXMg Y29uc2VudDsgaS5lLiBkdXJpbmcgdGhhdCBsaWZlIHRpbWUgVFVSTiBzZXJ2ZXIgaXMgd2lsbGlu ZyB0byBhY2NlcHQgdGhlIGNvbnRlbnQgYW5kIGtlZXBzIHRoZSBhbGxvY2F0aW9uIGZvciB0aGUg cGVlciB1bnRpbCB0aGUgbGlmZXRpbWUgZXhwaXJlcy4NCg0KTWF5IGJlIHNvbWUgZ3VpZGFuY2Ug b24gdGhlIGxpZmV0aW1lIG9mIHRoZSBUVVJOIGFsbG9jYXRpb25zLCB0byBhbGlnbiB3aXRoIHdl YnJ0YyBTVFVOIGNvbnNlbnQgdGltZXJzLCBiZSBzdWdnZXN0ZWQgaGVyZSBpbiBkcmFmdC1pZXRm LXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzPw0KQWxzbywgcGxlYXNlIG5vdGUgdGhhdCB0 aGVyZSBpcyBvbmx5IG9uZSBUVVJOIGFsbG9jYXRpb24gdG8gYmUgdXNlZCB0byBjb21tdW5pY2F0 ZSB3aXRoIGFsbCBwZWVyIGNhbmRpZGF0ZXM7IHNvLCBhIGNvbnNlbnQgZmFpbHVyZSBvbiBvbmUg Y2FuZGlkYXRlIGRvZXMgbm90IGF1dG9tYXRpY2FsbHkgbmVlZCBmcmVlaW5nIHVwIG9mIFRVUk4g cmVzb3VyY2VzLg0KDQpCUg0KUmFqdQ0KDQoNCk9yIHRvIHB1dCBpdCBldmVuIG1vcmUgc2hvcnRs eTogSSB0aGluayBpdCdzIGEgYmFkIGlkZWEsIGFuZCB3ZSBzaG91bGRuJ3Qgc3BlbmQgdGltZSBk aXNjdXNzaW5nIGl0IHVudGlsIHNvbW9lbmUgZXhwbGFpbnMgdG8gdGhlIGdyb3VwIHdoeSBJIG1p Z2h0IGJlIHdyb25nIGFib3V0IHRoYXQuDQoNCg== --_000_E1FE4C082A89A246A11D7F32A95A1782013D0755A2US70UWXCHMBA0_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOyAxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkFzIEkgdW5kZXJzdGFuZCwgcGVyaW9kaWMgY29uc2VudCBiZXR3ZWVuIHBlZXJz IGFyZSBuZWVkZWQgYXMgdGhlcmUgaXMgbm8gb3RoZXIgbWVjaGFuaXNtIHRvIGtub3cgdGhlIHBl ZXIgaXMgc3RpbGwgd2lsbGluZyB0byByZWNlaXZlIGFuZCBhbHNvIGFsbG9jYXRlZCB0aGUNCiBy ZXNvdXJjZXMgZm9yIHRoaXMgcGVlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93 ZXZlciwgaW4gVFVSTiBjYXNlLCBUVVJOIGNsaWVudCBhbmQgVFVSTiBzZXJ2ZXIgY2FuIHVzZSBw cm9jZWR1cmVzIGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2 NiNzZWN0aW9uLTciPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2I3NlY3Rpb24t NzwvYT4gdG8gcmVmcmVzaCB0aGUgYWxsb2NhdGlvbiB3aXRoIGNlcnRhaW4gbGlmZSB0aW1lLiBU aGlzIEkgYmVsaWV2ZSBzZXJ2ZSB0aGUgc2FtZSBwdXJwb3NlIGFzIGNvbnNlbnQ7IGkuZS4gZHVy aW5nIHRoYXQgbGlmZSB0aW1lIFRVUk4gc2VydmVyIGlzIHdpbGxpbmcgdG8NCiBhY2NlcHQgdGhl IGNvbnRlbnQgYW5kIGtlZXBzIHRoZSBhbGxvY2F0aW9uIGZvciB0aGUgcGVlciB1bnRpbCB0aGUg bGlmZXRpbWUgZXhwaXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heSBiZSBzb21lIGd1aWRhbmNlIG9uIHRoZSBs aWZldGltZSBvZiB0aGUgVFVSTiBhbGxvY2F0aW9ucywgdG8gYWxpZ24gd2l0aCB3ZWJydGMgU1RV TiBjb25zZW50IHRpbWVycywgYmUgc3VnZ2VzdGVkIGhlcmUgaW4gZHJhZnQtaWV0Zi1ydGN3ZWIt c3R1bi1jb25zZW50LWZyZXNobmVzcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxz bywgcGxlYXNlIG5vdGUgdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSBUVVJOIGFsbG9jYXRpb24gdG8g YmUgdXNlZCB0byBjb21tdW5pY2F0ZSB3aXRoIGFsbCBwZWVyIGNhbmRpZGF0ZXM7IHNvLCBhIGNv bnNlbnQgZmFpbHVyZSBvbiBvbmUgY2FuZGlkYXRlIGRvZXMgbm90DQogYXV0b21hdGljYWxseSBu ZWVkIGZyZWVpbmcgdXAgb2YgVFVSTiByZXNvdXJjZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SYWp1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQpPciB0byBwdXQgaXQgZXZlbiBtb3JlIHNob3J0bHk6IEkg dGhpbmsgaXQncyBhIGJhZCBpZGVhLCBhbmQgd2Ugc2hvdWxkbid0IHNwZW5kIHRpbWUgZGlzY3Vz c2luZyBpdCB1bnRpbCBzb21vZW5lIGV4cGxhaW5zIHRvIHRoZSBncm91cCB3aHkgSSBtaWdodCBi ZSB3cm9uZyBhYm91dCB0aGF0Ljxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_E1FE4C082A89A246A11D7F32A95A1782013D0755A2US70UWXCHMBA0_-- From nobody Thu Jun 25 10:21:48 2015 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 9F6A71AC3F0 for ; Thu, 25 Jun 2015 10:21:41 -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 h1W6HAC2CjI8 for ; Thu, 25 Jun 2015 10:21:38 -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 428801AC3F6 for ; Thu, 25 Jun 2015 10:21:37 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-b4-558c389f6c14 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 33.5B.28096.F983C855; Thu, 25 Jun 2015 19:21:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.27]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Thu, 25 Jun 2015 19:21:35 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Consent freshness for TURN servers Thread-Index: AQHQrf+l7Vh26m8kUkKmEaW7gIYSDZ27EHAAgAESyQCAALirgIAAnuF7 Date: Thu, 25 Jun 2015 17:21:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8FD467@ESESSMB209.ericsson.se> References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> , <558BCF77.2030602@alvestrand.no> In-Reply-To: <558BCF77.2030602@alvestrand.no> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8FD467ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre58i55Qgw0/VCyO9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGXcWDqXpWCSf8Wez5uYGhh/+HQxcnBICJhI nLjl0cXICWSKSVy4t56ti5GLQ0jgKKPE6z3/oZzFjBL3Di1iAmlgE7CQ6P6nDdIgIhAs0fv8 PSNIWBgo/OlhFIgpImApsWRtAESFm8T3d8/YQWwWAVWJ5cv7WUFsXgFfiQsT2xkhpr9mlJh3 tBusiFNAV+L7zENMIDYj0D3fT60Bs5kFxCWavqxkhbhTQGLJnvPMELaoxMvH/1ghavIlth18 yAaxQFDi5MwnLBMYhWchaZ+FpGwWkrJZQGczC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG 9lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgZFzcMtvqx2MB587HmIU4GBU4uFdmNAdKsSa WFZcmXuIUZqDRUmcd8bmvFAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOF2byVylFxL5t27 qzxz21cD7kjTHtkLVVbtvJs1avhrRQPmLdw7t2DWkW/Pvr/f8906W/pnbF1AmNsic8Ude3XW 8HGd2MWUa/frW543V0XwtQYply33ZrUJLC8rrmtx9TYJnZordvTzW7ULnipp7CJ93Htkj1wz 4jBy8k52M+mQubbmgWiaEktxRqKhFnNRcSIAvIrivn0CAAA= Archived-At: Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 17:21:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D8FD467ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWdyZWUgd2l0aCBIYXJhbGQuIE9uIG15IG9waW5pb24gVFVSTiBpcyBhYm91dCBO QVQgdHJhdmVyc2FsLCBub3QgdHJhZmZpYy9jb25zZW50IHBvbGljaW5nLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IEhhcmFsZCBBbHZlc3RyYW5kPG1haWx0bzpoYXJhbGRA YWx2ZXN0cmFuZC5ubz4NClNlbnQ6IOKAjjI1L+KAjjA2L+KAjjIwMTUgMTE6NTMNClRvOiBydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2Vi XSBDb25zZW50IGZyZXNobmVzcyBmb3IgVFVSTiBzZXJ2ZXJzDQoNCk9uIDA2LzI1LzIwMTUgMTI6 NTEgQU0sIFJvbWFuIFNocG91bnQgd3JvdGU6DQpPbiBXZWQsIEp1biAyNCwgMjAxNSBhdCAyOjI4 IEFNLCDwn5STRGFuIFdpbmcgPGR3aW5nQGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29t Pj4gd3JvdGU6DQpPbiAyMy1KdW4tMjAxNSAwMjo1NyBwbSwgUm9tYW4gU2hwb3VudCA8cm9tYW5A dGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQo+IEkgd2FudGVk IHRvIHNlZSBpZiB0aGVyZSBpcyBhIGNvbnNlbnQgY2hlY2sgaXNzdWVkIGJ5IHRoZSBUVVJOIHNl cnZlciB0byB2ZXJpZnkgdGhhdCByZW1vdGUgcGFydHkgaXMgd2lsbGluZyB0byBhY2NlcHQgbWVk aWEuIElzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgcGxhbm5lZCBvciBkbyBUVVJOIHNlcnZlcnMg c3VwcG9zZSB0byByZWx5IHRoYXQgdGhlIGNsaWVudHMgc2VuZGluZyBtZWRpYSB0aHJvdWdoIFRV Uk4gc2VydmVycyB3aWxsIHBlcmZvcm0gdGhlaXIgb3duIGNvbnNlbnQgY2hlY2tzIGFuZCBzaW1w bHkgdHJ1c3QgdGhlIGNsaWVudD8NCg0KVGhlIFRVUk4gc2VydmVyIGRvZXNuJ3Qga25vdyB0aGUg aWNlLXBhc3N3ZCBiZXR3ZWVuIHRoZSB0d28gcGVlcnMsIHdoaWNoIGlzIG5lY2Vzc2FyeSB0byBj cmVhdGUgYSB2YWxpZCBTVFVOIHJlcXVlc3QgKG9yIHRvIHZhbGlkYXRlIHRoZSBTVFVOIHJlc3Bv bnNlKS4gIElmIHdlIGRlY2lkZSBpdCBuZWNlc3NhcnksIHRoZSBUVVJOIHNlcnZlciBjb3VsZCB3 YXRjaCBmb3IgY29uc2VudCBjaGVjayBwYWNrZXRzIGFuZCB0ZWFyIGRvd24gdGhlIGNoYW5uZWwg YmluZGluZyBpZiBub25lIHNlZW4gaW4gTk5OIHNlY29uZHMuDQoNCldhcyB0aGVyZSBkaXNjdXNz aW9uIGFscmVhZHkgaWYgY29uc2VudCBpcyBuZWNlc3NhcnkgZm9yIFRVUk4gc2VydmVycz8gSSBh bSB0cnlpbmcgdG8gc2VlIGlmIGRlY2lzaW9uIHdhcyBhbHJlYWR5IG1hZGUgb3IgaWYgdGhlIHRv cGljIHdhcyBub3QgZGlzY3Vzc2VkIHlldC4NCg0KSSB0aG91Z2h0IGl0IHdhcyBvYnZpb3VzIHRo YXQgVFVSTiBzZXJ2ZXJzIGFyZSBvdXRzaWRlIGJvdGggSUNFIGF1dGhlbnRpY2F0aW9uIGZsb3cg YW5kIElDRSBjb25zZW50IGZsb3dzIC0gdGhleSBqdXN0IHJlbGF5IHN0dWZmLCB0aGV5IGhhdmUg bm8gc2VwYXJhdGUgZGF0YS1nZW5lcmF0aW5nIHJvbGUuDQoNCklmIHNvbWVvbmUgd2FudHMgdG8g bWFrZSB0aGUgYXJndW1lbnQgdGhhdCBUVVJOIHNlcnZlcnMgbmVlZCB0byBoYXZlIGEgZGlmZmVy ZW50IHJvbGUgZnJvbSBqdXN0IGJlaW5nIGEgVFVSTiBzZXJ2ZXIsIHRoYXQncyBhbiBpbnRlcmVz dGluZyBkaXNjdXNzaW9uIHRvIGhhdmUgLSBidXQgSSdkIHdhbnQgdG8gc2VlIHRoZSBhcmd1bWVu dCBmb3IgdGhpcyBjaGFuZ2UgaW4gdGhlIG1vZGVsIChpdCdzIGEgQ0hBTkdFLCBhbmQgd2UncmUg bGF0ZSBpbiB0aGUgcHJvY2VzcykgY2xlYXJseSBsYWlkIG91dCBpbiB0ZXh0IChwcmVmZXJhYmx5 IGFuIEktRCkgYmVmb3JlIGV2ZW4gYWNjZXB0aW5nIGl0IGFzIGEgZGlzY3Vzc2lvbiB0b3BpYy4N Cg0KT3IgdG8gcHV0IGl0IGV2ZW4gbW9yZSBzaG9ydGx5OiBJIHRoaW5rIGl0J3MgYSBiYWQgaWRl YSwgYW5kIHdlIHNob3VsZG4ndCBzcGVuZCB0aW1lIGRpc2N1c3NpbmcgaXQgdW50aWwgc29tb2Vu ZSBleHBsYWlucyB0byB0aGUgZ3JvdXAgd2h5IEkgbWlnaHQgYmUgd3JvbmcgYWJvdXQgdGhhdC4N Cg0KDQpJIGNhbiBzZWUgaG93IGNvbnNlbnQgbW9uaXRvcmluZyBjYW4gYmUgaW1wbGVtZW50ZWQg YnkgY2xpZW50IHNoYXJpbmcgSUNFIHB3ZCB3aXRoIHRoZSBUVVJOIHNlcnZlciB2aWEgYW4gYWRk aXRpb25hbCBjb21tYW5kIG9yIHZpYSBhZGRpdGlvbmFsIHBhcmFtZXRlciBpbiBBbGxvY2F0ZSBv ciBDcmVhdGVQZXJtaXNzaW9uIHJlcXVlc3QuDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpS b21hbiBTaHBvdW50DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViDQoNCg0KDQoNCi0tDQpTdXJ2ZWlsbGFuY2UgaXMgcGVydmFzaXZlLiBHbyBEYXJrLg0K DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D8FD467ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsg Zm9udC1zaXplOjExcHQiPkhpLDxicj4NCjxicj4NCkkgYWdyZWUgd2l0aCBIYXJhbGQuIE9uIG15 IG9waW5pb24gVFVSTiBpcyBhYm91dCBOQVQgdHJhdmVyc2FsLCBub3QgdHJhZmZpYy9jb25zZW50 IHBvbGljaW5nLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8 YnI+DQpTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZTwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGRpcj0i bHRyIj4NCjxocj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZToxMXB0OyBmb250LXdlaWdodDpib2xkIj5Gcm9tOg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0Ij48YSBo cmVmPSJtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iPkhhcmFsZCBBbHZlc3RyYW5kPC9hPjwv c3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBm b250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCOMjUv 4oCOMDYv4oCOMjAxNSAxMTo1Mzwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+VG86 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9u dC1zaXplOjExcHQiPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRm Lm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXpl OjExcHQiPlJlOiBbcnRjd2ViXSBDb25zZW50IGZyZXNobmVzcyBmb3IgVFVSTiBzZXJ2ZXJzPC9z cGFuPjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZp eCI+T24gMDYvMjUvMjAxNSAxMjo1MSBBTSwgUm9tYW4gU2hwb3VudCB3cm90ZTo8YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBKdW4gMjQs IDIwMTUgYXQgMjoyOCBBTSwg8J+Uk0RhbiBXaW5nIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86ZHdpbmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHdpbmdAY2lzY28u Y29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweA0KMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRo OjFweDsgYm9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTsgYm9yZGVyLWxlZnQtc3R5 bGU6c29saWQ7IHBhZGRpbmctbGVmdDoxZXgiPg0KPHNwYW4gY2xhc3M9IiI+T24gMjMtSnVuLTIw MTUgMDI6NTcgcG0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEkgd2Fu dGVkIHRvIHNlZSBpZiB0aGVyZSBpcyBhIGNvbnNlbnQgY2hlY2sgaXNzdWVkIGJ5IHRoZSBUVVJO IHNlcnZlciB0byB2ZXJpZnkgdGhhdCByZW1vdGUgcGFydHkgaXMgd2lsbGluZyB0byBhY2NlcHQg bWVkaWEuIElzIHRoaXMgc29tZXRoaW5nIHRoYXQgaXMgcGxhbm5lZCBvciBkbyBUVVJOIHNlcnZl cnMgc3VwcG9zZSB0byByZWx5IHRoYXQgdGhlIGNsaWVudHMgc2VuZGluZyBtZWRpYSB0aHJvdWdo IFRVUk4gc2VydmVycyB3aWxsIHBlcmZvcm0NCiB0aGVpciBvd24gY29uc2VudCBjaGVja3MgYW5k IHNpbXBseSB0cnVzdCB0aGUgY2xpZW50Pzxicj4NCjxicj4NCjwvc3Bhbj5UaGUgVFVSTiBzZXJ2 ZXIgZG9lc24ndCBrbm93IHRoZSBpY2UtcGFzc3dkIGJldHdlZW4gdGhlIHR3byBwZWVycywgd2hp Y2ggaXMgbmVjZXNzYXJ5IHRvIGNyZWF0ZSBhIHZhbGlkIFNUVU4gcmVxdWVzdCAob3IgdG8gdmFs aWRhdGUgdGhlIFNUVU4gcmVzcG9uc2UpLiZuYnNwOyBJZiB3ZSBkZWNpZGUgaXQgbmVjZXNzYXJ5 LCB0aGUgVFVSTiBzZXJ2ZXIgY291bGQgd2F0Y2ggZm9yIGNvbnNlbnQgY2hlY2sgcGFja2V0cyBh bmQgdGVhciBkb3duIHRoZQ0KIGNoYW5uZWwgYmluZGluZyBpZiBub25lIHNlZW4gaW4gTk5OIHNl Y29uZHMuPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2FzIHRoZXJlIGRp c2N1c3Npb24gYWxyZWFkeSBpZiBjb25zZW50IGlzIG5lY2Vzc2FyeSBmb3IgVFVSTiBzZXJ2ZXJz PyBJIGFtIHRyeWluZyB0byBzZWUgaWYgZGVjaXNpb24gd2FzIGFscmVhZHkgbWFkZSBvciBpZiB0 aGUgdG9waWMgd2FzIG5vdCBkaXNjdXNzZWQgeWV0LjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KSSB0aG91Z2h0IGl0IHdhcyBvYnZpb3VzIHRoYXQg VFVSTiBzZXJ2ZXJzIGFyZSBvdXRzaWRlIGJvdGggSUNFIGF1dGhlbnRpY2F0aW9uIGZsb3cgYW5k IElDRSBjb25zZW50IGZsb3dzIC0gdGhleSBqdXN0IHJlbGF5IHN0dWZmLCB0aGV5IGhhdmUgbm8g c2VwYXJhdGUgZGF0YS1nZW5lcmF0aW5nIHJvbGUuPGJyPg0KPGJyPg0KSWYgc29tZW9uZSB3YW50 cyB0byBtYWtlIHRoZSBhcmd1bWVudCB0aGF0IFRVUk4gc2VydmVycyBuZWVkIHRvIGhhdmUgYSBk aWZmZXJlbnQgcm9sZSBmcm9tIGp1c3QgYmVpbmcgYSBUVVJOIHNlcnZlciwgdGhhdCdzIGFuIGlu dGVyZXN0aW5nIGRpc2N1c3Npb24gdG8gaGF2ZSAtIGJ1dCBJJ2Qgd2FudCB0byBzZWUgdGhlIGFy Z3VtZW50IGZvciB0aGlzIGNoYW5nZSBpbiB0aGUgbW9kZWwgKGl0J3MgYSBDSEFOR0UsIGFuZCB3 ZSdyZSBsYXRlIGluIHRoZQ0KIHByb2Nlc3MpIGNsZWFybHkgbGFpZCBvdXQgaW4gdGV4dCAocHJl ZmVyYWJseSBhbiBJLUQpIGJlZm9yZSBldmVuIGFjY2VwdGluZyBpdCBhcyBhIGRpc2N1c3Npb24g dG9waWMuPGJyPg0KPGJyPg0KT3IgdG8gcHV0IGl0IGV2ZW4gbW9yZSBzaG9ydGx5OiBJIHRoaW5r IGl0J3MgYSBiYWQgaWRlYSwgYW5kIHdlIHNob3VsZG4ndCBzcGVuZCB0aW1lIGRpc2N1c3Npbmcg aXQgdW50aWwgc29tb2VuZSBleHBsYWlucyB0byB0aGUgZ3JvdXAgd2h5IEkgbWlnaHQgYmUgd3Jv bmcgYWJvdXQgdGhhdC48YnI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYg ZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBjYW4gc2VlIGhvdyBjb25zZW50IG1v bml0b3JpbmcgY2FuIGJlIGltcGxlbWVudGVkIGJ5IGNsaWVudCBzaGFyaW5nIElDRSBwd2Qgd2l0 aCB0aGUgVFVSTiBzZXJ2ZXIgdmlhIGFuIGFkZGl0aW9uYWwgY29tbWFuZCBvciB2aWEmbmJzcDth ZGRpdGlvbmFsIHBhcmFtZXRlciBpbiBBbGxvY2F0ZSBvciBDcmVhdGVQZXJtaXNzaW9uIHJlcXVl c3QuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0K PGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVyZSI+X19fX19fX19fX19fXzxicj4NClJv bWFuIFNocG91bnQ8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxicj4NCjxmaWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1lbnRIZWFkZXIi PjwvZmllbGRzZXQ+IDxicj4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxp bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRm Lm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGJy Pg0KPGJyPg0KPHByZSBjbGFzcz0ibW96LXNpZ25hdHVyZSIgY29scz0iNzIiPi0tIA0KU3VydmVp bGxhbmNlIGlzIHBlcnZhc2l2ZS4gR28gRGFyay4NCjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D8FD467ESESSMB209erics_-- From nobody Thu Jun 25 10:24:46 2015 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 176301AC40F for ; Thu, 25 Jun 2015 10:24:45 -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_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 ffuRoy4N26xm for ; Thu, 25 Jun 2015 10:24:43 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8671AC411 for ; Thu, 25 Jun 2015 10:24:43 -0700 (PDT) Received: by ieqy10 with SMTP id y10so59345606ieq.0 for ; Thu, 25 Jun 2015 10:24:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c8DY1LsTab0l2JAntl6Wj2F0yRDkc89MsbIMoO3cwZE=; b=D+8/jNrV+QnabCodMybB0Yuy1TOM5na264aIDjVvQ49A/z1FJgNJArNgyg5x7IjZ5d 0TGaGJdCuwgRlKr5HK7ir4lHudrV6R0UZQ0mhalVcigVcWFsucyJjKgMLwBxCkddM+Ay J+/Y2xW/ME67D1JwdSfJoEIdHL0OOL89ES9HPO2U657ZDbcs8qR4ezucdEZ/krUaWCdz YyS4/pOXN858M3sjBmCRByMWYgFACS0kzJilt76Je7KMLzDmNQfD9zIInV2C6Y2JM2IW c8bapq6Cg5UUwrmsdj58W2+9HnEQDJQTYQb0ZXe0t6YDpNF6Cd1Nve4hHB6LrLT84U6x d4xg== X-Gm-Message-State: ALoCoQlBQhraV7ZxjKoG4H6F5k0sTGX8OpdQc7kxuHhTcYnTbmbtlTL7tSenWG7pjb45AlYrHtml X-Received: by 10.50.176.134 with SMTP id ci6mr5504898igc.32.1435253082907; Thu, 25 Jun 2015 10:24:42 -0700 (PDT) Received: from aither.local ([2601:282:4201:ef5b:9cc2:3fcc:fa76:603a]) by mx.google.com with ESMTPSA id o2sm3716509igr.9.2015.06.25.10.24.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 10:24:41 -0700 (PDT) Message-ID: <558C3957.1050708@andyet.net> Date: Thu, 25 Jun 2015 11:24:39 -0600 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Harald Alvestrand , rtcweb@ietf.org References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> <558BCF77.2030602@alvestrand.no> In-Reply-To: <558BCF77.2030602@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 17:24:45 -0000 On 6/25/15 3:52 AM, Harald Alvestrand wrote: > On 06/25/2015 12:51 AM, Roman Shpount wrote: >> On Wed, Jun 24, 2015 at 2:28 AM, 🔓Dan Wing > > wrote: >> >> On 23-Jun-2015 02:57 pm, Roman Shpount > > wrote: >> > I wanted to see if there is a consent check issued by the TURN >> server to verify that remote party is willing to accept media. Is >> this something that is planned or do TURN servers suppose to rely >> that the clients sending media through TURN servers will perform >> their own consent checks and simply trust the client? >> >> The TURN server doesn't know the ice-passwd between the two peers, >> which is necessary to create a valid STUN request (or to validate >> the STUN response). If we decide it necessary, the TURN server >> could watch for consent check packets and tear down the channel >> binding if none seen in NNN seconds. >> >> >> Was there discussion already if consent is necessary for TURN servers? >> I am trying to see if decision was already made or if the topic was >> not discussed yet. > > I thought it was obvious that TURN servers are outside both ICE > authentication flow and ICE consent flows - they just relay stuff, they > have no separate data-generating role. > > If someone wants to make the argument that TURN servers need to have a > different role from just being a TURN server, that's an interesting > discussion to have - but I'd want to see the argument for this change in > the model (it's a CHANGE, and we're late in the process) clearly laid > out in text (preferably an I-D) before even accepting it as a discussion > topic. > > Or to put it even more shortly: I think it's a bad idea, and we > shouldn't spend time discussing it until somoene explains to the group > why I might be wrong about that. +1 Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Jun 25 10:26:44 2015 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 530841AC44A for ; Thu, 25 Jun 2015 10:26:43 -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 RQt-dVH_f61A for ; Thu, 25 Jun 2015 10:26:41 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC6C1AC414 for ; Thu, 25 Jun 2015 10:26:40 -0700 (PDT) Received: by wgqq4 with SMTP id q4so68486353wgq.1 for ; Thu, 25 Jun 2015 10:26:39 -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=SeaqbMEcIg6i9ZntasLxvyMUgUyUs5XA53wymzGtAEA=; b=BK0TYixNlAINu4aGpagCFvREYi3R5cCHbbh+yDAeKSg1wUUI2SAVWTH2u50nWiE8BP Pxxnnw64MAGuaC7tzhlUjbVyqZ+7jStsS7A1p7WJDPgOOhN9GNOwKbGfEY6pm23sQlL8 crvNIXODxFCuAOv3V4aEs13NSAhHWeNVxdAWlHJVLnYvtVznv5gQ9Qfqwz4Y5fJH+BH/ u3K+ItV/Mo3wfwQmNUri7ejRk15yBGPU0/CRn4e/UIYerrkEpks4wbIrrXsDZpEBhr7t E3HVlVWQZcXXCSSEObp0RY4mcAwkLvGgtoVA48/MDfhhrKgL92XFw/HAlijpgiQB+SXo 14ng== MIME-Version: 1.0 X-Received: by 10.181.6.37 with SMTP id cr5mr7702774wid.18.1435253199541; Thu, 25 Jun 2015 10:26:39 -0700 (PDT) Received: by 10.194.25.74 with HTTP; Thu, 25 Jun 2015 10:26:39 -0700 (PDT) In-Reply-To: References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> <558BCF77.2030602@alvestrand.no> Date: Thu, 25 Jun 2015 10:26:39 -0700 Message-ID: From: Ted Hardie To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=001a1136012e1f1a0405195aed93 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 17:26:43 -0000 --001a1136012e1f1a0405195aed93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 25, 2015 at 5:30 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > + 1 > > As I understand, periodic consent between peers are needed as there is no > other mechanism to know the peer is still willing to receive and also > allocated the resources for this peer. > > However, in TURN case, TURN client and TURN server can use procedures in > https://tools.ietf.org/html/rfc5766#section-7 to refresh the allocation > with certain life time. This I believe serve the same purpose as consent; > i.e. during that life time TURN server is willing to accept the content a= nd > keeps the allocation for the peer until the lifetime expires. > =E2=80=8BI'm a bit confused. The TURN server and client interaction you ci= te seems to handle the TURN server confirming that it is still willing to act on behalf of the client until the state time, where the consent mechanisms are for the client to confirm that a remote client is still willing to receive data. I don't see a reason to extend either to cover the other case. What am I missing? regards, Ted=E2=80=8B > > > May be some guidance on the lifetime of the TURN allocations, to align > with webrtc STUN consent timers, be suggested here in > draft-ietf-rtcweb-stun-consent-freshness? > > Also, please note that there is only one TURN allocation to be used to > communicate with all peer candidates; so, a consent failure on one > candidate does not automatically need freeing up of TURN resources. > > > > BR > > Raju > > > > > Or to put it even more shortly: I think it's a bad idea, and we shouldn't > spend time discussing it until somoene explains to the group why I might = be > wrong about that. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1136012e1f1a0405195aed93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 25, 2015 at 5:30 AM= , Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucen= t.com> wrote:

+ 1<= /p>

As I understand, periodic= consent between peers are needed as there is no other mechanism to know th= e peer is still willing to receive and also allocated the resources for this peer.

However, in TURN case, TU= RN client and TURN server can use procedures in https://tools.ietf.org/html/rfc5766#section-7 to refresh the allocatio= n with certain life time. This I believe serve the same purpose as consent;= i.e. during that life time TURN server is willing to accept the content and keeps the allocation for the peer until the lifetim= e expires.


=E2=80=8BI= 'm a bit confused.=C2=A0 The TURN server and client interaction you cit= e seems to handle the TURN server confirming that it is still willing to ac= t on behalf of the client until the state time, where the consent mechanism= s are for the client to confirm that a remote client is still willing to re= ceive data.=C2=A0 I don't see a reason to extend either to cover the ot= her case.=C2=A0 What am I missing?

regards,

<= /div>
Ted=E2=80=8B

=C2=A0
<= div>

=

=C2=A0

May be some guidance on t= he lifetime of the TURN allocations, to align with webrtc STUN consent time= rs, be suggested here in draft-ietf-rtcweb-stun-consent-freshness?

Also, please note that th= ere is only one TURN allocation to be used to communicate with all peer can= didates; so, a consent failure on one candidate does not automatically need freeing up of TURN resources.

=C2=A0

BR=

Raju=

=C2=A0


Or to put it even more shortly: I think it's a bad idea, and we shouldn= 't spend time discussing it until somoene explains to the group why I m= ight be wrong about that.


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


--001a1136012e1f1a0405195aed93-- From nobody Thu Jun 25 10:44:36 2015 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 B32E81A1BFF for ; Thu, 25 Jun 2015 10:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.332 X-Spam-Level: X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 3wYJPUVg4zLi for ; Thu, 25 Jun 2015 10:44:34 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.206.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82EA1A1B00 for ; Thu, 25 Jun 2015 10:44:34 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id E25CD11212556; Thu, 25 Jun 2015 12:44:33 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id D00D51121250E for ; Thu, 25 Jun 2015 12:44:33 -0500 (CDT) Received: from [204.42.252.17] (port=54793 helo=[5.5.33.215]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z8BCT-0002zS-0H for rtcweb@ietf.org; Thu, 25 Jun 2015 12:44:33 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 25 Jun 2015 14:44:29 -0300 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 204.42.252.17 X-Exim-ID: 1Z8BCT-0002zS-0H X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([5.5.33.215]) [204.42.252.17]:54793 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [rtcweb] 20150618 Virtual Interim notes/minutes 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, 25 Jun 2015 17:44:35 -0000 I uploaded notes that Cullen and I took during the interim: = http://www.ietf.org/proceedings/interim/2015/06/18/rtcweb/proceedings.html= We=92re going to use these to produce the minutes. spt= From nobody Thu Jun 25 11:44:53 2015 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 CF8681A8A93 for ; Thu, 25 Jun 2015 11:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 DUiQAXww6_r1 for ; Thu, 25 Jun 2015 11:44:51 -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 56DFB1A8AE5 for ; Thu, 25 Jun 2015 11:44:47 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 672B0A66049A9; Thu, 25 Jun 2015 18:44:41 +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 t5PIig0s006045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 18:44:42 GMT Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 14:44:42 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Ted Hardie Thread-Topic: [rtcweb] Consent freshness for TURN servers Thread-Index: AQHQrf+peED7acelCUCAxSUckpmf4Z27dQUAgAESyQCAALirgP//1MAggACqBoD//9CkMA== Date: Thu, 25 Jun 2015 18:44:41 +0000 Message-ID: References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> <558BCF77.2030602@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.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A1782013D077BA5US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 18:44:53 -0000 --_000_E1FE4C082A89A246A11D7F32A95A1782013D077BA5US70UWXCHMBA0_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KyAxDQpBcyBJIHVuZGVyc3RhbmQsIHBlcmlvZGljIGNvbnNlbnQgYmV0d2VlbiBwZWVycyBhcmUg bmVlZGVkIGFzIHRoZXJlIGlzIG5vIG90aGVyIG1lY2hhbmlzbSB0byBrbm93IHRoZSBwZWVyIGlz IHN0aWxsIHdpbGxpbmcgdG8gcmVjZWl2ZSBhbmQgYWxzbyBhbGxvY2F0ZWQgdGhlIHJlc291cmNl cyBmb3IgdGhpcyBwZWVyLg0KSG93ZXZlciwgaW4gVFVSTiBjYXNlLCBUVVJOIGNsaWVudCBhbmQg VFVSTiBzZXJ2ZXIgY2FuIHVzZSBwcm9jZWR1cmVzIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1NzY2I3NlY3Rpb24tNyB0byByZWZyZXNoIHRoZSBhbGxvY2F0aW9uIHdpdGggY2Vy dGFpbiBsaWZlIHRpbWUuIFRoaXMgSSBiZWxpZXZlIHNlcnZlIHRoZSBzYW1lIHB1cnBvc2UgYXMg Y29uc2VudDsgaS5lLiBkdXJpbmcgdGhhdCBsaWZlIHRpbWUgVFVSTiBzZXJ2ZXIgaXMgd2lsbGlu ZyB0byBhY2NlcHQgdGhlIGNvbnRlbnQgYW5kIGtlZXBzIHRoZSBhbGxvY2F0aW9uIGZvciB0aGUg cGVlciB1bnRpbCB0aGUgbGlmZXRpbWUgZXhwaXJlcy4NCg0K4oCLSSdtIGEgYml0IGNvbmZ1c2Vk LiAgVGhlIFRVUk4gc2VydmVyIGFuZCBjbGllbnQgaW50ZXJhY3Rpb24geW91IGNpdGUgc2VlbXMg dG8gaGFuZGxlIHRoZSBUVVJOIHNlcnZlciBjb25maXJtaW5nIHRoYXQgaXQgaXMgc3RpbGwgd2ls bGluZyB0byBhY3Qgb24gYmVoYWxmIG9mIHRoZSBjbGllbnQgdW50aWwgdGhlIHN0YXRlIHRpbWUs IHdoZXJlIHRoZSBjb25zZW50IG1lY2hhbmlzbXMgYXJlIGZvciB0aGUgY2xpZW50IHRvIGNvbmZp cm0gdGhhdCBhIHJlbW90ZSBjbGllbnQgaXMgc3RpbGwgd2lsbGluZyB0byByZWNlaXZlIGRhdGEu ICBJIGRvbid0IHNlZSBhIHJlYXNvbiB0byBleHRlbmQgZWl0aGVyIHRvIGNvdmVyIHRoZSBvdGhl ciBjYXNlLiAgV2hhdCBhbSBJIG1pc3Npbmc/DQpbUmFqdV0gSSBhbSBub3Qgc3VnZ2VzdGluZyBl eHRlbmRpbmcgb25lIHRvIGNvdmVyIHRoZSBvdGhlci4gTXkgY29tbWVudCBpcyB0byBzdXBwb3J0 IHRoZSBvcHBvc2l0ZSB3aGljaCBzdXBwb3J0cyBIYXJhbGTigJlzIGVhcmxpZXIgY29tbWVudC4g QmFzaWNhbGx5IHdoYXQgSSB0cmllZCB0byBjb252ZXkgd2FzLCBUVVJOIGhhcyBpdHMgb3duIHdh eSBvZiBrZWVwaW5nIHRoZSBhbGxvY2F0aW9uIGZyZXNoIGFuZCBubyBuZWVkIHRvIG1peCBpdCB3 aXRoIHBlZXIgdG8gcGVlciBjb25zZW50LiBTb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4NCkJSDQpS YWp1DQo= --_000_E1FE4C082A89A246A11D7F32A95A1782013D077BA5US70UWXCHMBA0_ 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 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+JiM0MzsgMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFzIEkgdW5kZXJzdGFuZCwgcGVyaW9kaWMgY29uc2VudCBiZXR3ZWVuIHBlZXJzIGFy ZSBuZWVkZWQgYXMgdGhlcmUgaXMgbm8gb3RoZXIgbWVjaGFuaXNtIHRvIGtub3cNCiB0aGUgcGVl ciBpcyBzdGlsbCB3aWxsaW5nIHRvIHJlY2VpdmUgYW5kIGFsc28gYWxsb2NhdGVkIHRoZSByZXNv dXJjZXMgZm9yIHRoaXMgcGVlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dl dmVyLCBpbiBUVVJOIGNhc2UsIFRVUk4gY2xpZW50IGFuZCBUVVJOIHNlcnZlciBjYW4gdXNlIHBy b2NlZHVyZXMgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2 I3NlY3Rpb24tNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1NzY2I3NlY3Rpb24tNzwvYT4gdG8gcmVmcmVzaCB0aGUgYWxsb2NhdGlvbiB3aXRoIGNlcnRh aW4gbGlmZSB0aW1lLiBUaGlzIEkgYmVsaWV2ZSBzZXJ2ZSB0aGUgc2FtZSBwdXJwb3NlIGFzIGNv bnNlbnQ7IGkuZS4gZHVyaW5nIHRoYXQgbGlmZSB0aW1lIFRVUk4gc2VydmVyDQogaXMgd2lsbGlu ZyB0byBhY2NlcHQgdGhlIGNvbnRlbnQgYW5kIGtlZXBzIHRoZSBhbGxvY2F0aW9uIGZvciB0aGUg cGVlciB1bnRpbCB0aGUgbGlmZXRpbWUgZXhwaXJlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItJJ20gYSBiaXQgY29uZnVzZWQu Jm5ic3A7IFRoZSBUVVJOIHNlcnZlciBhbmQgY2xpZW50IGludGVyYWN0aW9uIHlvdSBjaXRlIHNl ZW1zIHRvIGhhbmRsZSB0aGUgVFVSTiBzZXJ2ZXIgY29uZmlybWluZyB0aGF0IGl0IGlzIHN0aWxs IHdpbGxpbmcgdG8gYWN0IG9uIGJlaGFsZiBvZiB0aGUNCiBjbGllbnQgdW50aWwgdGhlIHN0YXRl IHRpbWUsIHdoZXJlIHRoZSBjb25zZW50IG1lY2hhbmlzbXMgYXJlIGZvciB0aGUgY2xpZW50IHRv IGNvbmZpcm0gdGhhdCBhIHJlbW90ZSBjbGllbnQgaXMgc3RpbGwgd2lsbGluZyB0byByZWNlaXZl IGRhdGEuJm5ic3A7IEkgZG9uJ3Qgc2VlIGEgcmVhc29uIHRvIGV4dGVuZCBlaXRoZXIgdG8gY292 ZXIgdGhlIG90aGVyIGNhc2UuJm5ic3A7IFdoYXQgYW0gSSBtaXNzaW5nPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltSYWp1 XSBJIGFtIG5vdCBzdWdnZXN0aW5nIGV4dGVuZGluZyBvbmUgdG8gY292ZXIgdGhlIG90aGVyLiBN eSBjb21tZW50IGlzIHRvIHN1cHBvcnQgdGhlIG9wcG9zaXRlIHdoaWNoIHN1cHBvcnRzIEhhcmFs ZOKAmXMNCiBlYXJsaWVyIGNvbW1lbnQuIEJhc2ljYWxseSB3aGF0IEkgdHJpZWQgdG8gY29udmV5 IHdhcywgVFVSTiBoYXMgaXRzIG93biB3YXkgb2Yga2VlcGluZyB0aGUgYWxsb2NhdGlvbiBmcmVz aCBhbmQgbm8gbmVlZCB0byBtaXggaXQgd2l0aCBwZWVyIHRvIHBlZXIgY29uc2VudC4gU29ycnkg Zm9yIHRoZSBjb25mdXNpb24uPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWp1 PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E1FE4C082A89A246A11D7F32A95A1782013D077BA5US70UWXCHMBA0_-- From nobody Thu Jun 25 12:15:32 2015 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 DEE341A8ADC for ; Thu, 25 Jun 2015 12:15:30 -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 MVVLXjj9aHm9 for ; Thu, 25 Jun 2015 12:15:29 -0700 (PDT) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388661AC412 for ; Thu, 25 Jun 2015 12:15:29 -0700 (PDT) Received: by igin14 with SMTP id n14so62370145igi.1 for ; Thu, 25 Jun 2015 12:15:28 -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=kdU6cadD1C4N3A5gVVBcOlkILsbj5BIZEFIdUZMGfsU=; b=Nxsc94RO3Gb8DqX18BlI2xY3w0+tWeIO8q0MkkHeYGoNZr3HzJAKoKDyee/XwIdsva PYehAgR31tVABfMEpOZznqD6h/9qSD2jt2AMfHepS/iWOFZ4YMzpCyEhfij1zbkfN58A o/ViaDPbtOVYQUI1OU/1vjNSX0ez0AjYX2B+PeaJbVFOs+ljnbKkj9wqEubVsKrXwg5/ TjBY7HDBjk3QvpTNVg2l780RrQksKBoUdaoB9t+UkTHxUwA92Z5djmYAe2rDcTTlaRDr aplyvUEWuvia28ox9ak9aZvUSHWsCVRphqsXC/1LptGniZ8E+JVMoilulliciXq+s1dA Zp2w== X-Gm-Message-State: ALoCoQkER0vD+I2Vm3QfJmxenmd5rVQRcEcrclQcguRjF4Ew+LP6zwX9maeFNJIRWZae4mOVB/Zp X-Received: by 10.43.84.73 with SMTP id aj9mr45415379icc.69.1435259728688; Thu, 25 Jun 2015 12:15:28 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com. [209.85.223.176]) by mx.google.com with ESMTPSA id vk8sm3903019igb.4.2015.06.25.12.15.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2015 12:15:27 -0700 (PDT) Received: by ieqy10 with SMTP id y10so61373663ieq.0 for ; Thu, 25 Jun 2015 12:15:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.46.2 with SMTP id i2mr61607582ioo.18.1435259726600; Thu, 25 Jun 2015 12:15:26 -0700 (PDT) Received: by 10.36.89.70 with HTTP; Thu, 25 Jun 2015 12:15:26 -0700 (PDT) In-Reply-To: <558BCF77.2030602@alvestrand.no> References: <75E6D483-FED6-4865-BEE7-1CE0891C83BC@cisco.com> <558BCF77.2030602@alvestrand.no> Date: Thu, 25 Jun 2015 15:15:26 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114406842a221805195c722e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Consent freshness for TURN servers 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, 25 Jun 2015 19:15:31 -0000 --001a114406842a221805195c722e Content-Type: text/plain; charset=UTF-8 On Thu, Jun 25, 2015 at 5:52 AM, Harald Alvestrand wrote: > I thought it was obvious that TURN servers are outside both ICE > authentication flow and ICE consent flows - they just relay stuff, they > have no separate data-generating role. > > If someone wants to make the argument that TURN servers need to have a > different role from just being a TURN server, that's an interesting > discussion to have - but I'd want to see the argument for this change in > the model (it's a CHANGE, and we're late in the process) clearly laid out > in text (preferably an I-D) before even accepting it as a discussion topic. > > Or to put it even more shortly: I think it's a bad idea, and we shouldn't > spend time discussing it until someone explains to the group why I might be > wrong about that. > I agree that consent monitoring by TURN server is not necessary. I just wanted to know if anybody brought this up. From what I can see everybody else thinks it is not needed so we can continue to live happily without this. Regards, _____________ Roman Shpount --001a114406842a221805195c722e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 25, 2015 at 5:52 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
I thought it was obvious that TURN servers are outside both ICE authentication flow and ICE consent flows - they just relay stuff, they have no separate data-generating role.
If someone wants to make the argument that TURN servers need to have a different role from just being a TURN server, that's an interesting discussion to have - but I'd want to see the argument for this change in the model (it's a CHANGE, and we're late in = the process) clearly laid out in text (preferably an I-D) before even accepting it as a discussion topic.

Or to put it even more shortly: I think it's a bad idea, and we shouldn't spend time discussing it until someone explains to the group why I might be wrong about that.

<= /div>
I agree that consent monitoring by TURN server is not necessary. = I just wanted to know if anybody brought this up. From what I can see every= body else thinks it is not needed so we can continue to live happily withou= t this.

Regards,
_____________
Roman Shpount

--001a114406842a221805195c722e-- From nobody Sun Jun 28 19:25:40 2015 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 C981D1B2E36 for ; Sun, 28 Jun 2015 19:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 B3SaYIYYgopY for ; Sun, 28 Jun 2015 19:25:37 -0700 (PDT) Received: from gateway24.websitewelcome.com (gateway24.websitewelcome.com [192.185.50.252]) (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 9D31F1AC3B2 for ; Sun, 28 Jun 2015 19:25:37 -0700 (PDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway24.websitewelcome.com (Postfix) with ESMTP id 01A7222DCF727 for ; Sun, 28 Jun 2015 21:25:37 -0500 (CDT) Received: from [96.231.221.219] (port=57585 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Z9OlL-0001Od-L5 for rtcweb@ietf.org; Sun, 28 Jun 2015 21:25:36 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <9BFA8176-CAB0-47E3-929F-2DD7A31DB900@ieca.com> Date: Sun, 28 Jun 2015 22:25:27 -0400 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.221.219 X-Exim-ID: 1Z9OlL-0001Od-L5 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.221.219]:57585 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [rtcweb] 20150618 Virtual Interim Recording 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, 29 Jun 2015 02:25:38 -0000 Here=92s a link to the audio recording of the virtual interim (1hr = 51min): = https://ietf.webex.com/ietf/ldr.php?RCID=3D1b62afe2dbc9006dbd7532d379d5dcf= 9 Just learning about b=3D is worth the price of admission. spt= From nobody Mon Jun 29 10:24:48 2015 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 6A22B1B2BE8 for ; Mon, 29 Jun 2015 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 qni1vrAMvSOD for ; Mon, 29 Jun 2015 10:24:45 -0700 (PDT) Received: from smtp121.ord1c.emailsrvr.com (smtp121.ord1c.emailsrvr.com [108.166.43.121]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C071B2BE3 for ; Mon, 29 Jun 2015 10:24:45 -0700 (PDT) Received: from smtp16.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id B79FB180230; Mon, 29 Jun 2015 13:24:44 -0400 (EDT) Received: by smtp16.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 189EF180349; Mon, 29 Jun 2015 13:24:43 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.0.0.63] (c-71-198-88-125.hsd1.ca.comcast.net [71.198.88.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Mon, 29 Jun 2015 17:24:44 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <5587EF5F.5040805@alvestrand.no> Date: Mon, 29 Jun 2015 10:24:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5587EF5F.5040805@alvestrand.no> To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] LS groups (Re: Cullen Notes from RTCWeb interim on June 18, 2015) 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, 29 Jun 2015 17:24:47 -0000 I think that LS makes more sense. Doing both LS and MSID was a comprise = the WG came to long ago. We need for a say to synchronized audio and = video and the IETF has already defined a widely deployed way of doing = that so I don't see a gain in ignoring it and inventing something else.=20= > On Jun 22, 2015, at 5:19 AM, Harald Alvestrand = wrote: >=20 > On 06/18/2015 08:00 PM, Cullen Jennings (fluffy) wrote: >> * make sure to add note well slide to slide deck >>=20 >> LS Behavior >> - Magnus points out that if JSEP overrides 5888, we will have issue = with legacy things >> - Martin points needs more thought to make declarative groups >> - Martin raised point that we might be able to add some extra = signaling that indicates that we can support this declarative LS usage >>=20 >> Conclusion: Magnus will dig into more analysis of options on this and = send to list. No decision on Option 1,2 >>=20 > Just FWIW: >=20 > Personally, I don't see the added value in adding LS groups. >=20 > We already have a well defined, declarative (=3Done-way) means of = declaring synchronization in the form of the MSID values, which bind = MediaStreamTracks into MediaStreams, which you're supposed to try = syncing if you can (it's not a hard requirement in the spec that you = should succeed). >=20 > If we want to be extra helpful for non-WebRTC implementations, and end = up in the case where we have one audio and one video track from one = stream in one direction using the same media descriptions as an audio = and video track in the other direction (which will be the normal case = when your application is trying to emulate a single-channel VC unit), I = have no particular problems with adding LS group markings to those media = descriptions - but I don't want to spend resources changing the = semantics of LS groups (and thereby imperiling the exact interworking = we're trying to make easier) when we already have something that fulfils = all the requirements for a pure WebRTC scenario. >=20 > My $0.02. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb