From nobody Fri May 1 02:16: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 A6F4C1B3025 for ; Fri, 1 May 2015 02:16:46 -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 SoLCJPKaHi8q for ; Fri, 1 May 2015 02:16:45 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF93D1B3020 for ; Fri, 1 May 2015 02:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2244; q=dns/txt; s=iport; t=1430471804; x=1431681404; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LtMQkIWNTbimwmQ7jJziut5iDUjCMqk7+duBSu9fHDA=; b=b/3GEUPRTm20e8pG8O7cABlItA/GMpn+4xfmoDlN74xtR5tZgIiru28V v9gz87zr/XlArDdzybrSTPOMuS4zuszR9u4mTl9SGqoqLBvtcmSEa5cNR zOOpGiEVxn2ketbwlXI25Ho2St2nUpW0kam5oV70EgJyLa7MAcnEfRDsM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSBAC0Q0NV/5JdJa1cgwxTXAXFYQmBSgqFNk4CgVk4FAEBAQEBAQGBCoQgAQEBBAEBAUQnFwQCAQgRAwECLycLHQgCBAESiCsNuHGOLgEBAQEBAQEDAQEBAQEBAQEBGYs4hQwGhCcFizuEEIIkhAqGQIEjPYMOjT+DUCODdG+BAgc7gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,350,1427760000"; d="scan'208";a="146242846" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 01 May 2015 09:15:35 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t419FZQS028016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 May 2015 09:15:35 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.199]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 1 May 2015 04:15:34 -0500 From: "Ram Mohan R (rmohanr)" To: Alissa Cooper , "rtcweb@ietf.org" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQg+9gZtq5gzqSOE6Em1OL5/PJLg== Date: Fri, 1 May 2015 09:15:34 +0000 Message-ID: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> In-Reply-To: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.60.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 09:16:46 -0000 Hi Alissa, Thanks for your review. Please see inline for my responses. -----Original Message----- From: Alissa Cooper Date: Friday, 1 May 2015 6:02 am To: "rtcweb@ietf.org" Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 >I have reviewed draft-ietf-rtcweb-stun-consent-freshness-11 in >preparation for IETF LC. The document is in good shape and I will request >the last call shortly. I have a couple of questions I=B9d like to discuss >while the last call is ongoing, though. I=B9m not entirely caught up on >mailing list traffic so apologies if these questions/comments have >already been discussed. > >Section 4.1: >"An endpoint that is not sending any application data does not need to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow to expire. Furthermore, having one > peer unable to send is detrimental to many protocols." > >It sounds like the unstated implication here is that if you are such an >endpoint, you should keep doing consent checks anyway to maintain >consent. Should that be stated explicitly, or am I misunderstanding? This is for endpoints that does not send any application data. In such cases there may be endpoints that may not send consent. We discussed about mandating sending consent always but there was objections to that in WG and this statement was introduced to give flexibility so that endpoints that does not intend to send any data on a 5-tuple may choose not to maintain consent and can use ICE keepalives http://tools.ietf.org/html/rfc5245#section-10. > >Section 7: >The normative MAY here seems odd. It seems like this section could be >replaced with: > >"The W3C specification [cite] 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.=B2 I am fine with changing this. Regards, Ram > >Alissa >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri May 1 03:30: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 87DC31B30EC for ; Fri, 1 May 2015 03:30: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 hiV6DeabOZDF for ; Fri, 1 May 2015 03:30:41 -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 E19721B30EB for ; Fri, 1 May 2015 03:30:40 -0700 (PDT) Received: from [81.187.2.149] (port=41568 helo=[192.168.0.18]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yo8DK-0002bI-LL; Fri, 01 May 2015 11:30:39 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <5542A84D.3040006@mozilla.com> Date: Fri, 1 May 2015 11:30:28 +0100 Content-Transfer-Encoding: 7bit Message-Id: <812F2D7D-F2ED-4A3E-BD70-0A785422F72A@csperkins.org> References: <7703998F-5364-487A-84F1-1AAEE6E4C3C8@cisco.com> <5542A84D.3040006@mozilla.com> To: Jean-Marc Valin X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Few comments on draft-ietf-rtcweb-audio-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 10:30:42 -0000 On 30 Apr 2015, at 23:10, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Cullen, Magnus, Colin, > > Thanks for the review. I just updated the draft. As some of you > pointed out, I changed all instances of "client" to "endpoint" to > match the terminology. See below for more: ... > On 20/04/15 03:40 PM, Colin Perkins wrote: >> - Section 3 says "Clients MAY use the offer/answer mechanism to >> signal a preference for a particular mode or ptime". Is this just >> of Opus, or in general? It might be worthwhile saying something >> explicit about acceptable ptime values in general. > > There was some discussion on acceptable ptime values in the past, but > there was no consensus achieved. > >> - Security considerations ought to explicitly point to the >> security considerations of RFCs 3389, 4733, 6716, and >> draft-ietf-payload-rtp-opus. It should possibly also point to the >> draft-ietf-rtcweb-security-arch-11, and the security >> considerations for RTP use in WebRTC in >> draft-ietf-rtcweb-rtp-usage-22 > > Done. Okay, thanks. That's fine for both. -- Colin Perkins https://csperkins.org/ From nobody Fri May 1 06:35: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 BE0A51B29C8; Fri, 1 May 2015 06:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 graUUtHVb3Tv; Fri, 1 May 2015 06:35:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A16081B29AB; Fri, 1 May 2015 06:35:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150501133551.28321.54351.idtracker@ietfa.amsl.com> Date: Fri, 01 May 2015 06:35:51 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (STUN Usage for Consent Freshness) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 13:35:52 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'STUN Usage for Consent Freshness' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri May 1 09:54: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 A4E891A9138 for ; Fri, 1 May 2015 09:54:44 -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 JjeCZ_8yhfdY for ; Fri, 1 May 2015 09:54:43 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::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 6FAD01A6FCF for ; Fri, 1 May 2015 09:54:43 -0700 (PDT) Received: by yhcb70 with SMTP id b70so18852152yhc.0 for ; Fri, 01 May 2015 09:54:42 -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=XFZ5JtdckkHAJl5DJ5JP2JvTDUgZ9hmmISHKFRqSZa0=; b=WvEAqUEZXfRorXW0vNZ0viadeNhRYrRP2V32pEmtWO5K1SLmkZinxZ6eDKniK2uoEx OGmq75DZ/Utr8atDuxyC315w1Fzat2qkA3c2ObX/UDm2M765LL4oCPJSp3gjRZAx/Rgr nBd7ESqP9FtUrlgjwb5r8SzOoil5deAIIx/Oev3QCNJkL8RB4SKRyZUVkluUgGMODRoE JdqCQ1kwyv2w/xjT04XdpC0rFFF7qf46A4xI+OqVskmZy1ihcZB0Ipyt+UJ6hDWwm9kE f5T81UwXcf8opz0fWy1FJQTYw5+bGtv3d3q08gYWKFvL5nkr1j4CL1EUQ1fD1x1/S1kL YLfQ== MIME-Version: 1.0 X-Received: by 10.170.166.3 with SMTP id i3mr9176514ykd.104.1430499282808; Fri, 01 May 2015 09:54:42 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 1 May 2015 09:54:42 -0700 (PDT) In-Reply-To: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> Date: Fri, 1 May 2015 09:54:42 -0700 Message-ID: From: Martin Thomson To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 16:54:44 -0000 On 30 April 2015 at 17:32, Alissa Cooper wrote: > "An endpoint that is not sending any application data does not need to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow to expire. Furthermore, having one > peer unable to send is detrimental to many protocols." > > It sounds like the unstated implication here is that if you are such an endpoint, you should keep doing consent checks anyway to maintain consent. Should that be stated explicitly, or am I misunderstanding? Can you tell that this is my text? Yep, the unspoken implication is that if you stop maintaining consent, a flow is highly likely to break. I'm OK with making that explicit. ... . Absent better information about the network, an endpoint SHOULD maintain consent if there is any possibility that a flow might be needed again. (Thanks for the suggestion on Sec7. I wasn't happy with it before.) From nobody Fri May 1 11:44: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 0C53F1ACD4C for ; Fri, 1 May 2015 11:44:27 -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 lTsRjnm-bgLr for ; Fri, 1 May 2015 11:44:23 -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 9E4161A8902 for ; Fri, 1 May 2015 11:44:22 -0700 (PDT) Received: by widdi4 with SMTP id di4so60561007wid.0 for ; Fri, 01 May 2015 11:44:21 -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=1XGy4tVtrFVC91a58xT8Gy6+t7ku/RCpm74/SnHreN4=; b=gBMSWiDlbkSgooIh9/3H7v/SOfx1pp7Xxn4qBwqusRpjqUqjX6TGwuH24b+7dslbtx A7EJsN1rchQ18VRZkI2bPAU+m9LlsMhGgzx9t1jOvNoMrYg/RuglgPhG9ynYGU7cKwjP N8sARRMtVwna+rGIXfLh3g9VwclRphrBUmMSKF9QwOK6aTmVw3X3ORijEE2rzuYG+e/k ZeALrVR5R8UcumoXQtPEgy/0idQU0n6uVWbxDFVd8hpblTf8nt4Mlbp2AI1TQvs8br3b bw3RT5kl4To8aSD3/GRyr5FOIJ4HPlwfVX3C40is7vyd+IU551KcCZh+pGc9eEaMXfsj 5L9w== X-Received: by 10.180.82.41 with SMTP id f9mr16221031wiy.48.1430505861392; Fri, 01 May 2015 11:44:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Fri, 1 May 2015 11:44:01 -0700 (PDT) In-Reply-To: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> From: Bernard Aboba Date: Fri, 1 May 2015 14:44:01 -0400 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d041826e6b7adce0515099929 Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 18:44:27 -0000 --f46d041826e6b7adce0515099929 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I did notice one other odd thing though, in Section 4.1: 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.... 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] I am curious about the reasons behind this text. Is there a security vulnerability that this addresses? From a transport point of view, 30 second outages are quite possible on the Internet due to routing transients and so will introduce some brittleness, effectively requiring an ICE restart (with attendant re-gathering). As a counter-example, congestion controlled protocols such as TCP do not give up this quickly. So I'm wondering if this is taking on a function better handled in circuit breakers/congestion control specifications. On Thu, Apr 30, 2015 at 8:32 PM, Alissa Cooper wrote: > I have reviewed draft-ietf-rtcweb-stun-consent-freshness-11 in preparatio= n > for IETF LC. The document is in good shape and I will request the last ca= ll > shortly. I have a couple of questions I=E2=80=99d like to discuss while t= he last > call is ongoing, though. I=E2=80=99m not entirely caught up on mailing li= st traffic > so apologies if these questions/comments have already been discussed. > > Section 4.1: > "An endpoint that is not sending any application data does not need to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow to expire. Furthermore, having one > peer unable to send is detrimental to many protocols." > > It sounds like the unstated implication here is that if you are such an > endpoint, you should keep doing consent checks anyway to maintain consent= . > Should that be stated explicitly, or am I misunderstanding? > > Section 7: > The normative MAY here seems odd. It seems like this section could be > replaced with: > > "The W3C specification [cite] 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 da= ta > is affected, such as media or data channels.=E2=80=9D > > Alissa > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d041826e6b7adce0515099929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I did notice one other odd thing though, in Section 4= .1:

=C2=A0=C2=A0 Consent expires after 30 seconds= .=C2=A0 That is, if a valid STUN binding response
=C2=A0=C2=A0 correspon= ding to any STUN request sent in the last 30 seconds has not
=C2=A0=C2= =A0 been received from the remote peer's transport address, the endpoin= t
=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-establ= ish consent, and may be
=C2=A0=C2=A0 discarded or cause an ICMP error...= .

=C2=A0=C2=A0 After consent is lost for any reaso= n, the same ICE credentials MUST
=C2=A0=C2=A0 NOT be used on the affecte= d 5-tuple again.=C2=A0 That means that a new
=C2=A0=C2=A0 session, or an= ICE restart, is needed to obtain consent to send.

[BA] I am curious about the reasons behind this text.=C2=A0 Is there a sec= urity vulnerability that this addresses?=C2=A0 From a transport point of vi= ew, 30 second outages are quite possible on the Internet due to routing tra= nsients and so will introduce some brittleness, effectively requiring an IC= E restart (with attendant re-gathering).=C2=A0 As a counter-example, conges= tion controlled protocols such as TCP do not give up this quickly.=C2=A0 So= I'm wondering if this is taking on a function better handled in circui= t breakers/congestion control specifications.

On Thu, Apr 30, 2015 at 8:32 PM, A= lissa Cooper <alissa@cooperw.in> wrote:
I have reviewed draft-ietf-rtcweb-stun-consent-freshness-11 i= n preparation for IETF LC. The document is in good shape and I will request= the last call shortly. I have a couple of questions I=E2=80=99d like to di= scuss while the last call is ongoing, though. I=E2=80=99m not entirely caug= ht up on mailing list traffic so apologies if these questions/comments have= already been discussed.

Section 4.1:
"An endpoint that is not sending any application data does not need to=
=C2=A0 =C2=A0maintain consent.=C2=A0 However, failure to send could cause a= ny NAT or
=C2=A0 =C2=A0firewall mappings for the flow to expire.=C2=A0 Furthermore, h= aving one
=C2=A0 =C2=A0peer unable to send is detrimental to many protocols."
It sounds like the unstated implication here is that if you are such an end= point, you should keep doing consent checks anyway to maintain consent. Sho= uld that be stated explicitly, or am I misunderstanding?

Section 7:
The normative MAY here seems odd. It seems like this section could be repla= ced with:

"The W3C specification [cite] may provide an API hook that generates a= n event when consent has expired for a given 5-tuple, meaning that transmis= sion of data has ceased.=C2=A0 This could indicate what application data is= affected, such as media or data channels.=E2=80=9D

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

--f46d041826e6b7adce0515099929-- From nobody Fri May 1 13:06: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 648901A8AD0 for ; Fri, 1 May 2015 13:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qsp4uKZsmeUT for ; Fri, 1 May 2015 13:06:19 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 D1E521A8AB5 for ; Fri, 1 May 2015 13:06:18 -0700 (PDT) Received: by ykft189 with SMTP id t189so20517934ykf.1 for ; Fri, 01 May 2015 13:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JitWIvETsZbI2u7CnrE5CWO+gCOLFmXn/XLiQWbEkwU=; b=Ge9bHz/ri6NkN2CwfJb/72XrLYTX1DqXdtJEzrCA9Cpwzo7v81U0iCM8WRHabTQL9D hR/TKVAXPL9FVl2hxv1YCbVd02mslyx+UJTDqUCN7zUesKDdDTTaTw8fJMPPzNYOsx9Q O0RqRO+/KmauX/HBqDNmm0kgm+j4z3krX90ifxpF/7JZIg5uRGOYS1ogOS64rOHJe95D AbwK154NSvsC8ppmBMF8MBykpP8HmNiEotojTgQFv6YL+lXqrZHtpYNs5YPl6HShmDGW AQBIiqmPeTHL/gL2Quf5Mmjuii+yh8nlyFF6hpx7Gk4AI3ziFz/nUnkTTkHDNIkVJsiN FloQ== MIME-Version: 1.0 X-Received: by 10.236.106.74 with SMTP id l50mr5659658yhg.143.1430510778226; Fri, 01 May 2015 13:06:18 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 1 May 2015 13:06:18 -0700 (PDT) In-Reply-To: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> Date: Fri, 1 May 2015 13:06:18 -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] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 20:06:20 -0000 On 1 May 2015 at 11:44, Bernard Aboba wrote: > 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] I am curious about the reasons behind this text. Is there a security > vulnerability that this addresses? From a transport point of view, 30 > second outages are quite possible on the Internet due to routing transients > and so will introduce some brittleness, effectively requiring an ICE restart > (with attendant re-gathering). As a counter-example, congestion controlled > protocols such as TCP do not give up this quickly. So I'm wondering if this > is taking on a function better handled in circuit breakers/congestion > control specifications. There was a long discussion on this point and this only documents the conclusion. My recollection is that the concern is a robustness one, not a security one. See the thread here: https://mailarchive.ietf.org/arch/msg/rtcweb/O1Hk9vFmfj4VnKLxyrBw029Hw4M Sorry about the length, we're short on brevity, it seems. From nobody Fri May 1 16:19: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 8BEBA1A6FEB for ; Fri, 1 May 2015 16:19:24 -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 XKuH3DOt_iR8 for ; Fri, 1 May 2015 16:19:23 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C881A6EED for ; Fri, 1 May 2015 16:19:23 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9543D20BCA for ; Fri, 1 May 2015 19:19:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 01 May 2015 19:19:22 -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=7zaWpW7FtCqMDgjHovo7OUMdjac=; b=aWy8y3 5+c+g3g/1uWmgs1JrhsWbwmueW8VcojDAMAFWDhjp/cAAGtHAkACfmiFeXsd/Tec 1pZvs73R3E5fJ8a3fI6iYMXpJd9TH2pd9Qdgp8AxNTslcvrNOozb+cUT5S/9NOcE JMohSmvK49D9oAOjdblMAIPAPv3PBm2I5F3uY= 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=7zaWpW7FtCqMDgj Hovo7OUMdjac=; b=AF5CsuNrcavICsdAzbkRvl9g+B7I1hKFQeQux6NNg9ushPP NVzbpkvMvjlDt+81HKLP7e+UjrKaAeatG8JLn6jjp0NX848zzGV7d2Fht59yqtNt Ad72HdTfDcIvrJid7G8wM0aHCRg18m3k8WSo863TpWS29sEjh9CEI45a+UjA= X-Sasl-enc: XuG0t35P0pwQtcMGfRjNplRtArnZOPyEURA6AUIehi4G 1430522362 Received: from [192.168.1.203] (unknown [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 9EAB5C00013; Fri, 1 May 2015 19:19:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Fri, 1 May 2015 16:19:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 23:19:24 -0000 On May 1, 2015, at 9:54 AM, Martin Thomson = wrote: > On 30 April 2015 at 17:32, Alissa Cooper wrote: >> "An endpoint that is not sending any application data does not need = to >> maintain consent. However, failure to send could cause any NAT or >> firewall mappings for the flow to expire. Furthermore, having one >> peer unable to send is detrimental to many protocols." >>=20 >> It sounds like the unstated implication here is that if you are such = an endpoint, you should keep doing consent checks anyway to maintain = consent. Should that be stated explicitly, or am I misunderstanding? >=20 > Can you tell that this is my text? >=20 > Yep, the unspoken implication is that if you stop maintaining consent, > a flow is highly likely to break. I'm OK with making that explicit. >=20 > ... . Absent better information about the network, an endpoint SHOULD > maintain consent if there is any possibility that a flow might be > needed again. WFM >=20 > (Thanks for the suggestion on Sec7. I wasn't happy with it before.) From nobody Sat May 2 18:05: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 8B20A1AC3A7; Sat, 2 May 2015 18:05:12 -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 7HGheNi6uQmk; Sat, 2 May 2015 18:05:11 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::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 29A1A1AC3A2; Sat, 2 May 2015 18:05:11 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so124636269ied.1; Sat, 02 May 2015 18:05:10 -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=9IyZGwoBVVB3ur7CljUHd4E6yFAXqZ9FvkaROht9gMQ=; b=yBDRYOVv1kF136d2ONCMzq6g4Fl/PwsSpUXzU32BwaxEwwAHhmGD4Y1QEgBtwZM3N7 1J5gvYB2SwzYRmvKlNG40p5zp7liTZo0JBh0yydH09pGq2OrEWDbcUrxGzT8sZmZAkwk t7YXvbXzQ8QcrDMDI4zyvU5/+ZOCMFpzv1nKFZym8E0l+hDJ84WfX8bVBuGXr/2HmgUx yZ3KurZOIwDmvv0u2tIs0GlWdvlpgjrkR9oxrBYVY3ZcXjo0x4Q1rVJVZV1NvJkWW8jS GeHEGS1hbclxq/eEMWlzpHfCLaQc0ykDPV8/4sXGBsC/RUx5BeIQfdk5EpSq0QUgNK8g 7Hgg== MIME-Version: 1.0 X-Received: by 10.50.4.67 with SMTP id i3mr5541663igi.47.1430615110695; Sat, 02 May 2015 18:05:10 -0700 (PDT) Received: by 10.107.156.194 with HTTP; Sat, 2 May 2015 18:05:10 -0700 (PDT) Date: Sat, 2 May 2015 18:05:10 -0700 Message-ID: From: Suhas Nandakumar To: mmusic WG , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2a13e7bbfef051523092e Archived-At: Subject: [rtcweb] RTP/TCP - SDP IANA Registrations - 02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 01:05:12 -0000 --001a11c2a13e7bbfef051523092e Content-Type: text/plain; charset=UTF-8 Hello All Sorry for cross posting Based on our discussions from IETF 92, I have submitted a new version of SDP Iana registrations draft describing SDP proto values for RTP profiles over TCP. Link: https://datatracker.ietf.org/doc/draft-nandakumar-mmusic-proto-iana-registration/ Please let me know your thoughts. Thanks Suhas --001a11c2a13e7bbfef051523092e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 Sorry for cross postin= g

Based on our discussions from IETF 92, I have su= bmitted a new version of SDP Iana registrations draft describing SDP proto = values for RTP profiles over TCP.


Please let me know your thoughts.

=
Thanks
Suhas
--001a11c2a13e7bbfef051523092e-- From nobody Sun May 3 22:27:21 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 C2AA61A00A7 for ; Sun, 3 May 2015 22:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.1 X-Spam-Level: X-Spam-Status: No, score=-13.1 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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_HTML_ATTACH=0.01, 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 9QThWFi7WGOj for ; Sun, 3 May 2015 22:27:13 -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 0A3D21A9136 for ; Sun, 3 May 2015 22:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=135664; q=dns/txt; s=iport; t=1430717233; x=1431926833; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=52VwI7XoOq4qXVriBJYuFaIiAOJZhatyHJZASE3Guh8=; b=Zc+vLlC/bqUGZA9ioMWLImAYuxUiazy0ZbZCjc6CozT+0A6eTpZ+DWFK zglijFDce5aAwqnNaj2gbVKBdf3KmYyaTClExnoi1VUILFYoF1sbr5Zef rCPRlerYpUlkFyq9ErxLipGP3xBYnwlw1nv4wZ/IpTNr+uDSiCLBcICo1 M=; X-Files: Diff_ draft-ietf-rtcweb-stun-consent-freshness-11.txt - draft-ietf-rtcweb-stun-consent-freshness-12.txt.html, draft-ietf-rtcweb-stun-consent-freshness-12.txt : 78116, 18747 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BmBQCoAkdV/4YNJK1cgwxTXAWFIcAVgWYZAQuFNE4CgUVMAQEBAQEBgQuEIAEBAQQBAQEXExonFwQCAQgRAwECARULAQ0CHwYLHQgCBAESDg2HfAMRDbZZiD8NhR4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXizmCTYFVEQEbGwoNAgMGBgSEIwWHCoc5g0qBfIIVgkaBcjSBVYEkEiuDFYpIgw6DUiOBXAmCD28BgQECAwICFwIEHIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,364,1427760000"; d="txt'?html'217?scan'217,208,217";a="8936413" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 04 May 2015 05:27:11 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t445RBvU014956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 May 2015 05:27:11 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.61]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 4 May 2015 00:27:11 -0500 From: "Ram Mohan R (rmohanr)" To: Alissa Cooper , Martin Thomson , "rtcweb@ietf.org" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQhir4Ztq5gzqSOE6Em1OL5/PJLg== Date: Mon, 4 May 2015 05:27:10 +0000 Message-ID: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> In-Reply-To: <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.241] Content-Type: multipart/mixed; boundary="_003_D16D00E62D555rmohanrciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 05:27:18 -0000 --_003_D16D00E62D555rmohanrciscocom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <018C97E782392A4C9FA73F00B9082A35@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Alissa/ all, Attached is the diffs with the comments incorporated. Please let me know if its fine. Regards, Ram -----Original Message----- From: Alissa Cooper Date: Saturday, 2 May 2015 4:49 am To: Martin Thomson Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 > >On May 1, 2015, at 9:54 AM, Martin Thomson >wrote: > >> On 30 April 2015 at 17:32, Alissa Cooper wrote: >>> "An endpoint that is not sending any application data does not need to >>> maintain consent. However, failure to send could cause any NAT or >>> firewall mappings for the flow to expire. Furthermore, having one >>> peer unable to send is detrimental to many protocols." >>>=20 >>> It sounds like the unstated implication here is that if you are such >>>an endpoint, you should keep doing consent checks anyway to maintain >>>consent. Should that be stated explicitly, or am I misunderstanding? >>=20 >> Can you tell that this is my text? >>=20 >> Yep, the unspoken implication is that if you stop maintaining consent, >> a flow is highly likely to break. I'm OK with making that explicit. >>=20 >> ... . Absent better information about the network, an endpoint SHOULD >> maintain consent if there is any possibility that a flow might be >> needed again. > >WFM > >>=20 >> (Thanks for the suggestion on Sec7. I wasn't happy with it before.) > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb --_003_D16D00E62D555rmohanrciscocom_ Content-Type: text/html; name="Diff_ draft-ietf-rtcweb-stun-consent-freshness-11.txt - draft-ietf-rtcweb-stun-consent-freshness-12.txt.html" Content-Description: Diff_ draft-ietf-rtcweb-stun-consent-freshness-11.txt - draft-ietf-rtcweb-stun-consent-freshness-12.txt.html Content-Disposition: attachment; filename="Diff_ draft-ietf-rtcweb-stun-consent-freshness-11.txt - draft-ietf-rtcweb-stun-consent-freshness-12.txt.html"; size=78116; creation-date="Mon, 04 May 2015 05:27:10 GMT"; modification-date="Mon, 04 May 2015 05:27:10 GMT" Content-ID: Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIEdlbmVyYXRlZCBieSByZmNkaWZmIDEuNDI6IHJmY2RpZmYgIC0tPgo8IS0t IDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRpb25h bCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGdhbWF5IDIuNi4zOS0yLTY4Ni1wYWUgIzEgU01Q IFR1ZSBKdWwgNSAwMzo0ODo0OSBVVEMgMjAxMSBpNjg2IEdOVS9MaW51eCAtLT4KPCEtLSBVc2lu ZyBhd2s6IC91c3IvYmluL2dhd2s6IEdOVSBBd2sgNC4wLjEgLS0+CjwhLS0gVXNpbmcgZGlmZjog L3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRpZmZ1dGlscykgMy4zIC0tPgo8IS0tIFVzaW5nIHdk aWZmOiAvdXNyL2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4yLjEgLS0+CjxodG1sPjxo ZWFkPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD1VVEYtOCI+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUtVHlw ZSIgY29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1ydGN3ZWIt c3R1bi1jb25zZW50LWZyZXNobmVzcy0xMS50eHQgLSBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNv bnNlbnQtZnJlc2huZXNzLTEyLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgPC9zdHlsZT4gCjwvaGVhZD4gCjxib2R5PiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+ PHRyIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNo bmVzcy0xMS50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZs dDs8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTEudHh0IiBzdHlsZT0iY29sb3I6IzAw OCI+ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMS50eHQ8L2E+Jm5i c3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEyLnR4dCIg c3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5l c3MtMTIudHh0PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDE9ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMi50eHQiIHN0 eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+ PC90aD48L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5SVENXRUIg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0u IFBlcnVtYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5SVENXRUIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIFBlcnVtYWw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEVyaWNzc29uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNz c29uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRC4gV2luZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVuZGVk IHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RC4gV2luZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4 cGlyZXM6IDxzcGFuIGNsYXNzPSJkZWxldGUiPkp1bmUgMjAsIDIwMTUgICA8L3NwYW4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBSYXZpbmRyYW5hdGg8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIg NCwgMjAxNTwvc3Bhbj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIFJhdmluZHJh bmF0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVC4gUmVkZHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VC4gUmVkZHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDaXNjbyBTeXN0ZW1zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBD aXNjbyBTeXN0ZW1zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTS4gVGhvbXNvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTS4gVGhvbXNvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE1vemlsbGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1vemlsbGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAyIj48L2E+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+RGVjZW1iZXIgMTcsIDIwMTQ8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBN YXkgMywgMjAxNTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3M8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNl bnQgRnJlc2huZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMyI+PC9hPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNz LTE8c3BhbiBjbGFzcz0iZGVsZXRlIj4xPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVz aG5lc3MtMTxzcGFuIGNsYXNzPSJpbnNlcnQiPjI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij5BYnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUbyBwcmV2ZW50IHNlbmRpbmcgZXhjZXNz aXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNlbnQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUbyBwcmV2ZW50IHNlbmRpbmcgZXhjZXNzaXZlIHRyYWZm aWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNlbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbmVlZHMgdG8gYmUgb2J0YWluZWQg ZnJvbSB0aGF0IHJlbW90ZSBlbmRwb2ludC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBuZWVkcyB0byBiZSBvYnRhaW5lZCBmcm9tIHRoYXQgcmVtb3RlIGVuZHBvaW50LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjb25z ZW50IG1lY2hhbmlzbSB1c2luZyBhIG5ldyBTZXNzaW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjb25zZW50IG1lY2hhbmlzbSB1 c2luZyBhIG5ldyBTZXNzaW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgdXNh Z2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVHJhdmVyc2FsIFV0aWxpdGll cyBmb3IgTkFUIChTVFVOKSB1c2FnZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlN0YXR1 cyBvZiBUaGlzIE1lbW88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5TdGF0dXMgb2Yg VGhpcyBNZW1vPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQt bDIiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5l IDM5PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjIiPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5lIDM5PC9lbT48L2E+ PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkg YWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRHJh ZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MDQiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+SnVuZSAyMDwvc3Bhbj4sIDIwMTUuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gPHNwYW4gY2xhc3M9Imluc2VydCI+Tm92ZW1iZXIgNDwvc3Bhbj4sIDIwMTUuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA1Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBDb3B5cmlnaHQgKGMpIDIwMTxzcGFuIGNsYXNzPSJkZWxldGUiPjQ8L3NwYW4+IElFVEYgVHJ1 c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIENvcHlyaWdodCAoYykgMjAxPHNwYW4gY2xhc3M9Imluc2VydCI+NTwv c3Bhbj4gSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGU8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZG9jdW1l bnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQ IDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYg VHJ1c3QncyBMZWdhbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRG IERvY3VtZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZl Y3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoaHR0 cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUg b2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9j dW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHVibGljYXRpb24gb2Yg dGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNhcmVmdWxseSwg YXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVj dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNhcmVmdWxseSwgYXMgdGhleSBk ZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0byB0aGlz IGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQg bXVzdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIHRoaXMgZG9jdW1lbnQu ICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluY2x1 ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQu ZSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgVHJ1 c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXM8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlz aW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJn cmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMyI+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDIsIGxpbmUgMjI8L2VtPjwvYT48L3RoPjx0aD4gPC90 aD48dGg+PGEgbmFtZT0icGFydC1yMyI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGVtPiBwYWdlIDIsIGxpbmUgMjI8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxLiAg SW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgMi4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg Mi4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIDMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIDMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICA0LiAgU29sdXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICA0LiAgU29sdXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA0LjEuICBFeHBpcmF0aW9uIG9mIENvbnNlbnQgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICA0LjEuICBFeHBpcmF0aW9uIG9mIENvbnNlbnQgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNC4yLiAgSW1tZWRpYXRlIFJldm9jYXRpb24gb2Yg Q29uc2VudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgNC4yLiAgSW1tZWRpYXRlIFJldm9jYXRpb24gb2YgQ29uc2VudCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA1LiAgRGlmZlNlcnYgVHJlYXRtZW50IGZvciBD b25zZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICA1LiAgRGlmZlNlcnYgVHJlYXRtZW50IGZvciBDb25zZW50ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgNi4gIERUTFMgYXBwbGljYWJpbGl0eSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNi4gIERUTFMgYXBwbGljYWJpbGl0eSAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDcuICBBUEkgUmVjb21tZW5kYXRp b25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDcuICBBUEkgUmVjb21tZW5kYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA4LiAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDY8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9 ImRpZmYwMDA2Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA5LiAgSUFOQSBDb25zaWRlcmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPjc8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg IDkuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgPHNwYW4gY2xhc3M9Imluc2VydCI+Njwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTAuIEFja25vd2xlZGdl bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMTAuIEFja25vd2xlZGdlbWVudCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDExLiBSZWZlcmVu Y2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDExLiBSZWZlcmVuY2VzICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDExLjEu ICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDExLjEuICBOb3JtYXRp dmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDc8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAx MS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAxMS4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dGhvcnMn IEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFRvIHByZXZlbnQgYXR0YWNrcyBvbiBwZWVycywgZW5kcG9pbnRzIGhh dmUgdG8gZW5zdXJlIHRoZSByZW1vdGUgcGVlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIFRvIHByZXZlbnQgYXR0YWNrcyBvbiBwZWVycywgZW5kcG9pbnRzIGhhdmUgdG8gZW5z dXJlIHRoZSByZW1vdGUgcGVlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBpcyB3aWxsaW5nIHRvIHJlY2VpdmUgdHJhZmZpYy4gIFRoaXMg aXMgcGVyZm9ybWVkIGJvdGggd2hlbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBpcyB3aWxsaW5nIHRvIHJlY2VpdmUgdHJhZmZpYy4gIFRoaXMgaXMgcGVyZm9ybWVkIGJv dGggd2hlbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFy dC1sNCI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUsIGxp bmUgMjE8L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yNCI+PHNtYWxs PnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUsIGxpbmUgMjE8L2VtPjwv YT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNDk1M10pLCB0aGVyZSBpcyBzdGls bCBhIHJpc2sgYW4gYXR0YWNrZXIgY291bGQgY2F1c2UgYSBUQ1A8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBbUkZDNDk1M10pLCB0aGVyZSBpcyBzdGlsbCBhIHJpc2sgYW4gYXR0 YWNrZXIgY291bGQgY2F1c2UgYSBUQ1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2VuZGVyIHRvIHNlbmQgZm9yZXZlciBieSBzcG9vZmlu ZyBBQ0tzLiAgVG8gcHJldmVudCBzdWNoIGFuIGF0dGFjayw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBzZW5kZXIgdG8gc2VuZCBmb3JldmVyIGJ5IHNwb29maW5nIEFDS3MuICBU byBwcmV2ZW50IHN1Y2ggYW4gYXR0YWNrLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb25zZW50IGNoZWNrcyBNVVNUIGJlIHBlcmZvcm1l ZCBvdmVyIGFsbCB0cmFuc3BvcnQgY29ubmVjdGlvbnMsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgY29uc2VudCBjaGVja3MgTVVTVCBiZSBwZXJmb3JtZWQgb3ZlciBhbGwgdHJh bnNwb3J0IGNvbm5lY3Rpb25zLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmNsdWRpbmcgVENQLiAgSW4gdGhpcyB3YXksIGFuIG9mZi1w YXRoIGF0dGFja2VyIHNwb29maW5nIFRDUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGluY2x1ZGluZyBUQ1AuICBJbiB0aGlzIHdheSwgYW4gb2ZmLXBhdGggYXR0YWNrZXIgc3Bv b2ZpbmcgVENQPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIHNlZ21lbnRzIGNhbiBub3QgY2F1c2UgYSBUQ1Agc2VuZGVyIHRvIHNlbmQgb25j ZSB0aGUgY29uc2VudCB0aW1lcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNl Z21lbnRzIGNhbiBub3QgY2F1c2UgYSBUQ1Agc2VuZGVyIHRvIHNlbmQgb25jZSB0aGUgY29uc2Vu dCB0aW1lcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBleHBpcmVzICgzMCBzZWNvbmRzKS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBleHBpcmVzICgzMCBzZWNvbmRzKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEg ZG9lcyBub3QgbmVlZCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFuIGVu ZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3Qg bmVlZCB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBtYWludGFpbiBjb25zZW50LiAgSG93ZXZlciwgZmFpbHVyZSB0byBzZW5kIGNvdWxk IGNhdXNlIGFueSBOQVQgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBtYWlu dGFpbiBjb25zZW50LiAgSG93ZXZlciwgZmFpbHVyZSB0byBzZW5kIGNvdWxkIGNhdXNlIGFueSBO QVQgb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgZmlyZXdhbGwgbWFwcGluZ3MgZm9yIHRoZSBmbG93IHRvIGV4cGlyZS4gIEZ1cnRoZXJt b3JlLCBoYXZpbmcgb25lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmlyZXdh bGwgbWFwcGluZ3MgZm9yIHRoZSBmbG93IHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcg b25lPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNyI+PC9hPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcGVl ciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcGVlciB1bmFibGUgdG8gc2VuZCBpcyBkZXRy aW1lbnRhbCB0byBtYW55IHByb3RvY29scy4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkFic2VudCBi ZXR0ZXI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZXR3b3JrLCBhbiBlbmRwb2ludCBT SE9VTEQgbWFpbnRhaW4gY29uc2VudCBpZjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5 IHRoYXQgYSBmbG93IG1pZ2h0IGJlIG5lZWRlZCBhZ2Fpbi48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBBZnRlciBjb25zZW50IGlzIGxvc3QgZm9yIGFueSByZWFzb24sIHRo ZSBzYW1lIElDRSBjcmVkZW50aWFscyBNVVNUPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgQWZ0ZXIgY29uc2VudCBpcyBsb3N0IGZvciBhbnkgcmVhc29uLCB0aGUgc2FtZSBJQ0Ug Y3JlZGVudGlhbHMgTVVTVDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBOT1QgYmUgdXNlZCBvbiB0aGUgYWZmZWN0ZWQgNS10dXBsZSBhZ2Fp bi4gIFRoYXQgbWVhbnMgdGhhdCBhIG5ldzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIE5PVCBiZSB1c2VkIG9uIHRoZSBhZmZlY3RlZCA1LXR1cGxlIGFnYWluLiAgVGhhdCBtZWFu cyB0aGF0IGEgbmV3PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHNlc3Npb24sIG9yIGFuIElDRSByZXN0YXJ0LCBpcyBuZWVkZWQgdG8gb2J0 YWluIGNvbnNlbnQgdG8gc2VuZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBz ZXNzaW9uLCBvciBhbiBJQ0UgcmVzdGFydCwgaXMgbmVlZGVkIHRvIG9idGFpbiBjb25zZW50IHRv IHNlbmQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LjIuICBJbW1lZGlhdGUgUmV2b2Nh dGlvbiBvZiBDb25zZW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4yLiAgSW1t ZWRpYXRlIFJldm9jYXRpb24gb2YgQ29uc2VudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgSW4gc29tZSBjYXNlcyBpdCBpcyB1c2VmdWwgdG8gc2lnbmFsIHRoYXQgY29uc2VudCBpcyB0 ZXJtaW5hdGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gc29tZSBjYXNl cyBpdCBpcyB1c2VmdWwgdG8gc2lnbmFsIHRoYXQgY29uc2VudCBpcyB0ZXJtaW5hdGVkPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJhdGhl ciB0aGFuIHJlbHlpbmcgb24gYSB0aW1lb3V0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIHJhdGhlciB0aGFuIHJlbHlpbmcgb24gYSB0aW1lb3V0LjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0i cGFydC1sNSI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDYs IGxpbmUgMjM8L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yNSI+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDYsIGxpbmUgMjM8L2Vt PjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBbSS1ELmlldGYtdHN2d2ctcnRj d2ViLXFvc10uICBTdWNoIGEgY2FzZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFtJLUQuaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zXS4g IFN1Y2ggYSBjYXNlIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRoaXMgZG9jdW1lbnQuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgdGhpcyBkb2N1bWVudC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjYuICBEVExTIGFwcGxpY2FiaWxpdHk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij42LiAgRFRMUyBhcHBsaWNhYmlsaXR5PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGUgRFRMUyBhcHBsaWNhYmlsaXR5IGlzIGlkZW50aWNhbCB0byB3 aGF0IGlzIGRlc2NyaWJlZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRo ZSBEVExTIGFwcGxpY2FiaWxpdHkgaXMgaWRlbnRpY2FsIHRvIHdoYXQgaXMgZGVzY3JpYmVkIGlu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFNlY3Rpb24gNC4yIG9mIFtSRkM3MzUwXS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBTZWN0aW9uIDQuMiBvZiBbUkZDNzM1MF0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij43LiAgQVBJIFJlY29tbWVuZGF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjcuICBBUEkgUmVjb21tZW5kYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQ+PGEgbmFtZT0iZGlmZjAwMDgiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoZSBXM0Mg c3BlY2lmaWNhdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5NQVk8L3NwYW4+IHByb3ZpZGUgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+dGhlIGZvbGxvd2luZzwvc3Bhbj4gQVBJIDxzcGFuIGNsYXNzPSJk ZWxldGUiPnBvaW50cyB0byBwcm92aWRlPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBUaGUgVzNDIHNwZWNpZmljYXRpb24gPHNwYW4gY2xhc3M9Imluc2VydCI+W1cz Qy1XRUJSVENdIG1heTwvc3Bhbj4gcHJvdmlkZSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hbjwvc3Bh bj4gQVBJIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmhvb2sgdGhhdDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICBmZWVkYmFjayBhbmQgY29udHJvbCBvdmVyIGNvbnNlbnQ6PC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBnZW5l cmF0ZXM8L3NwYW4+IGFuIGV2ZW50IHdoZW4gY29uc2VudCBoYXMgZXhwaXJlZCBmb3IgYSBnaXZl biA1LXR1cGxlLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgbWVhbmluZyB0aGF0IHRyYW5zbWlzc2lvbiBvZiBkYXRhIGhhcyBj ZWFzZWQuICBUaGlzIGNvdWxkIGluZGljYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgMS4gIEdl bmVyYXRlPC9zcGFuPiBhbiBldmVudCB3aGVuIGNvbnNlbnQgaGFzIGV4cGlyZWQgZm9yIGEgZ2l2 ZW4gNS10dXBsZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgd2hhdCBhcHBs aWNhdGlvbiBkYXRhIGlzIGFmZmVjdGVkLCBzdWNoIGFzIG1lZGlhIG9yIGRhdGEgY2hhbm5lbHMu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgIG1lYW5pbmcgdGhhdCB0cmFuc21pc3Npb24gb2YgZGF0YSBoYXMgY2Vhc2VkLiAgVGhp cyBjb3VsZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgaW5kaWNhdGUg d2hhdCBhcHBsaWNhdGlvbiBkYXRhIGlzIGFmZmVjdGVkLCBzdWNoIGFzIG1lZGlhIG9yIGRhdGE8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgIGNoYW5uZWxzLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjgu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjguICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzZWN1cml0eSBtZWNoYW5pc20uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzZWN1 cml0eSBtZWNoYW5pc20uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFtSRkM1MjQ1XSBzaG91bGQgYWxzbyBiZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBkaXNjdXNzZWQgaW4gW1JGQzUyNDVdIHNob3VsZCBhbHNvIGJlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRha2VuIGludG8gYWNj b3VudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0YWtlbiBpbnRvIGFjY291 bnQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBTUlRQIGlzIGVuY3J5cHRlZCBhbmQg YXV0aGVudGljYXRlZCB3aXRoIHN5bW1ldHJpYyBrZXlzOyB0aGF0IGlzLDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNSVFAgaXMgZW5jcnlwdGVkIGFuZCBhdXRoZW50aWNhdGVk IHdpdGggc3ltbWV0cmljIGtleXM7IHRoYXQgaXMsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJvdGggc2VuZGVyIGFuZCByZWNlaXZlciBr bm93IHRoZSBrZXlzLiAgV2l0aCB0d28gcGFydHkgc2Vzc2lvbnMsPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgYm90aCBzZW5kZXIgYW5kIHJlY2VpdmVyIGtub3cgdGhlIGtleXMu ICBXaXRoIHR3byBwYXJ0eSBzZXNzaW9ucyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48 dGg+PGEgbmFtZT0icGFydC1sNiI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+ PGVtPiBwYWdlIDgsIGxpbmUgMjg8L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0i cGFydC1yNiI+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDgs IGxpbmUgMjQ8L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAg IDIwMTAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAyMDEw LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzYwNjJdICBQZXJyZWF1bHQsIFMu IGFuZCBKLiBSb3NlbmJlcmcsICJUcmF2ZXJzYWwgVXNpbmcgUmVsYXlzPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzYwNjJdICBQZXJyZWF1bHQsIFMuIGFuZCBKLiBSb3Nl bmJlcmcsICJUcmF2ZXJzYWwgVXNpbmcgUmVsYXlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgYXJvdW5kIE5BVCAoVFVS TikgRXh0ZW5zaW9ucyBmb3IgVENQIEFsbG9jYXRpb25zIiwgUkZDPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBhcm91bmQgTkFUIChUVVJOKSBFeHRlbnNpb25z IGZvciBUQ1AgQWxsb2NhdGlvbnMiLCBSRkM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICA2MDYyLCBOb3ZlbWJlciAyMDEw LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgNjA2MiwgTm92 ZW1iZXIgMjAxMC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkM3MzUwXSAgUGV0 aXQtSHVndWVuaW4sIE0uIGFuZCBHLiBTYWxndWVpcm8sICJEYXRhZ3JhbSBUcmFuc3BvcnQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDNzM1MF0gIFBldGl0LUh1Z3Vlbmlu LCBNLiBhbmQgRy4gU2FsZ3VlaXJvLCAiRGF0YWdyYW0gVHJhbnNwb3J0PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgTGF5 ZXIgU2VjdXJpdHkgKERUTFMpIGFzIFRyYW5zcG9ydCBmb3IgU2Vzc2lvbiBUcmF2ZXJzYWw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIExheWVyIFNlY3VyaXR5 IChEVExTKSBhcyBUcmFuc3BvcnQgZm9yIFNlc3Npb24gVHJhdmVyc2FsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgVXRp bGl0aWVzIGZvciBOQVQgKFNUVU4pIiwgUkZDIDczNTAsIEF1Z3VzdCAyMDE0LjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgVXRpbGl0aWVzIGZvciBOQVQgKFNU VU4pIiwgUkZDIDczNTAsIEF1Z3VzdCAyMDE0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA5Ij48L2E+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W1czQy1X RUJSVENdPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIEJlcmdrdmlzdCwgQS4sIEJ1cm5ldHQsIEQuLCBOYXJh eWFuYW4sIEEuLCBhbmQgQy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgSmVubmluZ3MsICJXZWJSVEMgMS4w OiBSZWFsLXRpbWUgQ29tbXVuaWNhdGlvbiBCZXR3ZWVuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIEJyb3dz ZXJzIiwgZmVicnVhcnkgMjAxNS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+QXV0aG9ycycgQWRkcmVzc2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRXJpY3Nzb248L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBFcmljc3NvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGZXJucyBJY29uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgRmVybnMgSWNvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEb2RkYW5la3VuZGksIE1haGFkZXZhcHVyYTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERvZGRhbmVrdW5kaSwgTWFoYWRldmFw dXJhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEJhbmdhbG9yZSwgS2FybmF0YWthICA1NjAwMzc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBCYW5nYWxvcmUsIEthcm5hdGFrYSAgNTYwMDM3PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEluZGlhPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW5kaWE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEVtYWlsOiBtdXRodS5hcnVsQGdtYWlsLmNvbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIEVtYWlsOiBtdXRodS5hcnVsQGdtYWlsLmNvbTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90 cj4KICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIi PjxhIG5hbWU9ImVuZCI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDkgY2hhbmdlIGJsb2Nrcy4mbmJz cDs8L2E+PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT4x NCBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0aD48 aT4xOCBsaW5lcyBjaGFuZ2VkIG9yIGFkZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8 dHI+PHRkIGNvbHNwYW49IjUiIGNsYXNzPSJzbWFsbCIgYWxpZ249ImNlbnRlciI+PGJyPlRoaXMg aHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBieSByZmNkaWZmIDEuNDIuIFRoZSBsYXRlc3QgdmVyc2lv biBpcyBhdmFpbGFibGUgZnJvbSA8YSBocmVmPSJodHRwOi8vd3d3LnRvb2xzLmlldGYub3JnL3Rv b2xzL3JmY2RpZmYvIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwv dGQ+PC90cj4KICAgPC90Ym9keT48L3RhYmxlPgogICAKICAgClgtR2VuZXJhdG9yOiBweWh0IDAu MzUKCjwhLS0gYXJnczogeyctLW9sZGNvbG91cic6ICdyZWQnLCAnLS13aWR0aCc6ICcnLCAnZGlm ZnR5cGUnOiAnLS1odG1sJywgJ2ZpbGVuYW1lMic6ICdcblxuXG5cblJUQ1dFQiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gUGVydW1hbFxu SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEVyaWNzc29uXG5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEQuIFdpbmdcbkV4cGlyZXM6IE5vdmVtYmVyIDQsIDIw MTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIFJhdmluZHJhbmF0aFxuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFQuIFJlZGR5XG4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENpc2NvIFN5c3RlbXNcbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gVGhvbXNvblxuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNb3pp bGxhXG4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTWF5IDMsIDIwMTVcblxuXG4gICAgICAgICAgICAgICAgICAgIFNUVU4gVXNhZ2Ug Zm9yIENvbnNlbnQgRnJlc2huZXNzXG4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtcnRjd2ViLXN0 dW4tY29uc2VudC1mcmVzaG5lc3MtMTJcblxuQWJzdHJhY3RcblxuICAgVG8gcHJldmVudCBzZW5k aW5nIGV4Y2Vzc2l2ZSB0cmFmZmljIHRvIGFuIGVuZHBvaW50LCBwZXJpb2RpYyBjb25zZW50XG4g ICBuZWVkcyB0byBiZSBvYnRhaW5lZCBmcm9tIHRoYXQgcmVtb3RlIGVuZHBvaW50LlxuXG4gICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGNvbnNlbnQgbWVjaGFuaXNtIHVzaW5nIGEgbmV3IFNl c3Npb25cbiAgIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgdXNhZ2UuXG5cblN0 YXR1cyBvZiBUaGlzIE1lbW9cblxuICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQg aW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZVxuICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5k IEJDUCA3OS5cblxuICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0 aGUgSW50ZXJuZXQgRW5naW5lZXJpbmdcbiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0 IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlXG4gICB3b3JraW5nIGRvY3VtZW50cyBh cyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LVxuICAgRHJh ZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uXG5c biAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGlt dW0gb2Ygc2l4IG1vbnRoc1xuICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jz b2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnlcbiAgIHRpbWUuICBJdCBpcyBpbmFwcHJv cHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlXG4gICBtYXRlcmlhbCBv ciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iXG5cbiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTm92ZW1iZXIgNCwgMjAxNS5cblxuQ29w eXJpZ2h0IE5vdGljZVxuXG4gICBDb3B5cmlnaHQgKGMpIDIwMTUgSUVURiBUcnVzdCBhbmQgdGhl IHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGVcbiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmln aHRzIHJlc2VydmVkLlxuXG4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdFwncyBMZWdhbFxuICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRG IERvY3VtZW50c1xuICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4g ZWZmZWN0IG9uIHRoZSBkYXRlIG9mXG4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAg UGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHNcblxuXG5cblBlcnVtYWwsIGV0IGFsLiAgICAg ICAgIEV4cGlyZXMgTm92ZW1iZXIgNCwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAxXVxuX1xu SW50ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAg ICAgICAgIE1heSAyMDE1XG5cblxuICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0XG4gICB0byB0aGlzIGRvY3VtZW50 LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdFxuICAg aW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rp b24gNC5lIG9mXG4gICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVk IHdpdGhvdXQgd2FycmFudHkgYXNcbiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0Qg TGljZW5zZS5cblxuVGFibGUgb2YgQ29udGVudHNcblxuICAgMS4gIEludHJvZHVjdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyXG4gICAyLiAg VGVybWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgIDNcbiAgIDMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgM1xuICAgNC4gIFNvbHV0aW9uICAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzXG4gICAgIDQuMS4gIEV4 cGlyYXRpb24gb2YgQ29uc2VudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDNcbiAgICAgNC4yLiAgSW1tZWRpYXRlIFJldm9jYXRpb24gb2YgQ29uc2VudCAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNVxuICAgNS4gIERpZmZTZXJ2IFRyZWF0bWVudCBmb3IgQ29uc2Vu dCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2XG4gICA2LiAgRFRMUyBhcHBsaWNh YmlsaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZcbiAg IDcuICBBUEkgUmVjb21tZW5kYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgNlxuICAgOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2XG4gICA5LiAgSUFOQSBDb25zaWRlcmF0aW9u cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZcbiAgIDEwLiBB Y2tub3dsZWRnZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgN1xuICAgMTEuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3XG4gICAgIDExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDdcbiAgICAgMTEuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg N1xuICAgQXV0aG9yc1wnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgOFxuXG4xLiAgSW50cm9kdWN0aW9uXG5cbiAgIFRvIHByZXZlbnQg YXR0YWNrcyBvbiBwZWVycywgZW5kcG9pbnRzIGhhdmUgdG8gZW5zdXJlIHRoZSByZW1vdGUgcGVl clxuICAgaXMgd2lsbGluZyB0byByZWNlaXZlIHRyYWZmaWMuICBUaGlzIGlzIHBlcmZvcm1lZCBi b3RoIHdoZW4gdGhlXG4gICBzZXNzaW9uIGlzIGZpcnN0IGVzdGFibGlzaGVkIHRvIHRoZSByZW1v dGUgcGVlciB1c2luZyBJbnRlcmFjdGl2ZVxuICAgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQg SUNFIFtSRkM1MjQ1XSBjb25uZWN0aXZpdHkgY2hlY2tzLCBhbmRcbiAgIHBlcmlvZGljYWxseSBm b3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBzZXNzaW9uIHVzaW5nIHRoZSBwcm9jZWR1cmVzXG4gICBk ZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuXG5cbiAgIFdoZW4gYSBzZXNzaW9uIGlzIGZpcnN0IGVz dGFibGlzaGVkLCBJQ0UgaW1wbGVtZW50YXRpb25zIG9idGFpbiBhblxuICAgaW5pdGlhbCBjb25z ZW50IHRvIHNlbmQgYnkgcGVyZm9ybWluZyBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3MuICBUaGlz XG4gICBkb2N1bWVudCBkZXNjcmliZXMgYSBuZXcgU1RVTiB1c2FnZSB3aXRoIGV4Y2hhbmdlIG9m IHJlcXVlc3QgYW5kXG4gICByZXNwb25zZSBtZXNzYWdlcyB0aGF0IHZlcmlmaWVzIHRoZSByZW1v dGUgcGVlclwncyBvbmdvaW5nIGNvbnNlbnQgdG9cbiAgIHJlY2VpdmUgdHJhZmZpYy4gIFRoaXMg Y29uc2VudCBleHBpcmVzIGFmdGVyIGEgcGVyaW9kIG9mIHRpbWUgYW5kXG4gICBuZWVkcyB0byBi ZSBjb250aW51YWxseSByZW5ld2VkLCB3aGljaCBlbnN1cmVzIHRoYXQgY29uc2VudCBjYW4gYmVc biAgIHRlcm1pbmF0ZWQuXG5cbiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB3aGF0IGl0IHRha2Vz IHRvIG9idGFpbiwgbWFpbnRhaW4sIGFuZCBsb3NlXG4gICBjb25zZW50IHRvIHNlbmQuICBDb25z ZW50IHRvIHNlbmQgYXBwbGllcyB0byBhIHNpbmdsZSA1LXR1cGxlLiAgSG93XG4gICBhcHBsaWNh dGlvbnMgcmVhY3QgdG8gY2hhbmdlcyBpbiBjb25zZW50IGlzIG5vdCBkZXNjcmliZWQgaW4gdGhp c1xuICAgZG9jdW1lbnQuXG5cblxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJl cyBOb3ZlbWJlciA0LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDJdXG5fXG5JbnRlcm5ldC1E cmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgICAgICAgTWF5 IDIwMTVcblxuXG4gICBDb25zZW50IGlzIG9idGFpbmVkIG9ubHkgYnkgZnVsbCBJQ0UgaW1wbGVt ZW50YXRpb25zLiAgQW4gSUNFLWxpdGVcbiAgIGltcGxlbWVudGF0aW9uIHdpbGwgbm90IGdlbmVy YXRlIGNvbnNlbnQgY2hlY2tzLCBidXQgd2lsbCBqdXN0XG4gICByZXNwb25kIHRvIGNvbnNlbnQg Y2hlY2tzIGl0IHJlY2VpdmVzLiAgTm8gY2hhbmdlcyBhcmUgcmVxdWlyZWQgdG9cbiAgIElDRS1s aXRlIGltcGxlbWVudGF0aW9ucyBpbiBvcmRlciB0byByZXNwb25kIHRvIGNvbnNlbnQgY2hlY2tz LCBhc1xuICAgdGhleSBhcmUgcHJvY2Vzc2VkIGFzIG5vcm1hbCBJQ0UgY29ubmVjdGl2aXR5IGNo ZWNrcy5cblxuMi4gIFRlcm1pbm9sb2d5XG5cbiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVT VCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIixcbiAgICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlz XG4gICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMy MTE5XS5cblxuICAgQ29uc2VudDogIFRoZSBtZWNoYW5pc20gb2Ygb2J0YWluaW5nIHBlcm1pc3Np b24gdG8gc2VuZCB0byBhIHJlbW90ZVxuICAgICAgdHJhbnNwb3J0IGFkZHJlc3MuICBJbml0aWFs IGNvbnNlbnQgaXMgb2J0YWluZWQgdXNpbmcgSUNFLlxuXG4gICBDb25zZW50IEZyZXNobmVzczog IE1haW50YWluaW5nIGFuZCByZW5ld2luZyBjb25zZW50IG92ZXIgdGltZS5cblxuICAgVHJhbnNw b3J0IEFkZHJlc3M6ICBUaGUgcmVtb3RlIHBlZXJcJ3MgSVAgYWRkcmVzcyBhbmQgVURQIG9yIFRD UCBwb3J0XG4gICAgICBudW1iZXIuXG5cbjMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnNcblxuICAg QWx0aG91Z2ggSUNFIHJlcXVpcmVzIHBlcmlvZGljIGtlZXBhbGl2ZSB0cmFmZmljIHRvIGtlZXAg TkFUIGJpbmRpbmdzXG4gICBhbGl2ZSAoU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0sIFtSRkM2MjYz XSksIHRob3NlIGtlZXBhbGl2ZXMgYXJlIHNlbnRcbiAgIGFzIFNUVU4gSW5kaWNhdGlvbnMgd2hp Y2ggYXJlIHNlbmQtYW5kLWZvcmdldCwgYW5kIGRvIG5vdCBldm9rZSBhXG4gICByZXNwb25zZS4g IEEgcmVzcG9uc2UgaXMgbmVjZXNzYXJ5IGZvciBjb25zZW50IHRvIGNvbnRpbnVlIHNlbmRpbmdc biAgIHRyYWZmaWMuICBUaHVzLCB3ZSBuZWVkIGEgcmVxdWVzdC9yZXNwb25zZSBtZWNoYW5pc20g Zm9yIGNvbnNlbnRcbiAgIGZyZXNobmVzcy4gIElDRSBjYW4gYmUgdXNlZCBmb3IgdGhhdCBtZWNo YW5pc20gYmVjYXVzZSBJQ0VcbiAgIGltcGxlbWVudGF0aW9ucyBhcmUgYWxyZWFkeSByZXF1aXJl ZCB0byBjb250aW51ZSBsaXN0ZW5pbmcgZm9yIElDRVxuICAgbWVzc2FnZXMsIGFzIGRlc2NyaWJl ZCBpbiBzZWN0aW9uIDEwIG9mIFtSRkM1MjQ1XS4gIElmIGNvbnNlbnQgaXNcbiAgIHBlcmZvcm1l ZCB0aGVuIHRoZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBrZWVwYWxpdmUgbWVzc2FnZXMuXG5cbjQu ICBTb2x1dGlvblxuXG4gICBUaGVyZSBhcmUgdHdvIHdheXMgY29uc2VudCB0byBzZW5kIHRyYWZm aWMgaXMgcmV2b2tlZDogZXhwaXJhdGlvbiBvZlxuICAgY29uc2VudCBhbmQgaW1tZWRpYXRlIHJl dm9jYXRpb24gb2YgY29uc2VudCwgd2hpY2ggYXJlIGRpc2N1c3NlZCBpblxuICAgdGhlIGZvbGxv d2luZyBzZWN0aW9ucy5cblxuNC4xLiAgRXhwaXJhdGlvbiBvZiBDb25zZW50XG5cbiAgIEEgZnVs bCBJQ0UgaW1wbGVtZW50YXRpb24gcGVyZm9ybXMgY29uc2VudCBmcmVzaG5lc3MgdGVzdCB1c2lu ZyBTVFVOXG4gICByZXF1ZXN0L3Jlc3BvbnNlIGFzIGRlc2NyaWJlZCBiZWxvdzpcblxuICAgQW4g ZW5kcG9pbnQgTVVTVCBOT1Qgc2VuZCBkYXRhIG90aGVyIHRoYW4gcGFjZWQgU1RVTiBjb25uZWN0 aXZpdHlcbiAgIGNoZWNrcyBvciByZXNwb25zZXMgdG93YXJkIGFueSB0cmFuc3BvcnQgYWRkcmVz cyB1bmxlc3MgdGhlIHJlY2VpdmluZ1xuICAgZW5kcG9pbnQgY29uc2VudHMgdG8gcmVjZWl2ZSBk YXRhLiAgVGhhdCBpcywgbm8gYXBwbGljYXRpb24gZGF0YVxuICAgKGUuZy4sIFJUUCBvciBEVExT KSBjYW4gYmUgc2VudCB1bnRpbCBjb25zZW50IGlzIG9idGFpbmVkLiAgQWZ0ZXIgYVxuICAgc3Vj Y2Vzc2Z1bCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrIG9uIGEgcGFydGljdWxhciB0cmFuc3BvcnQg YWRkcmVzcyxcblxuXG5cblBlcnVtYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg NCwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAzXVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICBT VFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1XG5cblxu ICAgY29uc2VudCBNVVNUIGJlIG1haW50YWluZWQgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgZGVz Y3JpYmVkIGluIHRoaXNcbiAgIGRvY3VtZW50LlxuXG4gICBFeHBsaWNpdCBjb25zZW50IHRvIHNl bmQgaXMgb2J0YWluZWQgYW5kIG1haW50YWluZWQgYnkgc2VuZGluZyBhblxuICAgU1RVTiBiaW5k aW5nIHJlcXVlc3QgdG8gdGhlIHJlbW90ZSBwZWVyXCdzIHRyYW5zcG9ydCBhZGRyZXNzIGFuZFxu ICAgcmVjZWl2aW5nIGEgbWF0Y2hpbmcsIGF1dGhlbnRpY2F0ZWQsIG5vbi1lcnJvciBTVFVOIGJp bmRpbmcgcmVzcG9uc2VcbiAgIGZyb20gdGhlIHJlbW90ZSBwZWVyXCdzIHRyYW5zcG9ydCBhZGRy ZXNzLiAgVGhlc2UgU1RVTiBiaW5kaW5nXG4gICByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGFyZSBh dXRoZW50aWNhdGVkIHVzaW5nIHRoZSBzYW1lIHNob3J0LXRlcm1cbiAgIGNyZWRlbnRpYWxzIGFz IHRoZSBpbml0aWFsIElDRSBleGNoYW5nZS5cblxuICAgTm90ZTogIEFsdGhvdWdoIFRDUCBoYXMg aXRzIG93biBjb25zZW50IG1lY2hhbmlzbSAoVENQXG4gICAgICBhY2tub3dsZWRnZW1lbnRzKSwg Y29uc2VudCBpcyBuZWNlc3Nhcnkgb3ZlciBhIFRDUCBjb25uZWN0aW9uXG4gICAgICBiZWNhdXNl IGl0IGNvdWxkIGJlIHRyYW5zbGF0ZWQgdG8gYSBVRFAgY29ubmVjdGlvbiAoZS5nLixcbiAgICAg IFtSRkM2MDYyXSkuXG5cbiAgIEluaXRpYWwgY29uc2VudCB0byBzZW5kIHRyYWZmaWMgaXMgb2J0 YWluZWQgdXNpbmcgSUNFLiAgQ29uc2VudFxuICAgZXhwaXJlcyBhZnRlciAzMCBzZWNvbmRzLiAg VGhhdCBpcywgaWYgYSB2YWxpZCBTVFVOIGJpbmRpbmcgcmVzcG9uc2VcbiAgIGNvcnJlc3BvbmRp bmcgdG8gYW55IFNUVU4gcmVxdWVzdCBzZW50IGluIHRoZSBsYXN0IDMwIHNlY29uZHMgaGFzIG5v dFxuICAgYmVlbiByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUgcGVlclwncyB0cmFuc3BvcnQgYWRk cmVzcywgdGhlIGVuZHBvaW50XG4gICBNVVNUIGNlYXNlIHRyYW5zbWlzc2lvbiBvbiB0aGF0IDUt dHVwbGUuICBTVFVOIGNvbnNlbnQgcmVzcG9uc2VzXG4gICByZWNlaXZlZCBhZnRlciBjb25zZW50 IGV4cGlyeSBkbyBub3QgcmUtZXN0YWJsaXNoIGNvbnNlbnQsIGFuZCBtYXkgYmVcbiAgIGRpc2Nh cmRlZCBvciBjYXVzZSBhbiBJQ01QIGVycm9yLlxuXG4gICBUbyBwcmV2ZW50IGV4cGlyeSBvZiBj b25zZW50LCBhIFNUVU4gYmluZGluZyByZXF1ZXN0IGNhbiBiZSBzZW50XG4gICBwZXJpb2RpY2Fs bHkuICBUbyBwcmV2ZW50IHN5bmNocm9uaXphdGlvbiBvZiBjb25zZW50IGNoZWNrcywgZWFjaFxu ICAgaW50ZXJ2YWwgTVVTVCBiZSByYW5kb21pemVkIGZyb20gYmV0d2VlbiAwLjggYW5kIDEuMiB0 aW1lcyB0aGUgYmFzaWNcbiAgIHBlcmlvZC4gIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgc2V0IGEg ZGVmYXVsdCBpbnRlcnZhbCBvZiA1IHNlY29uZHMsXG4gICByZXN1bHRpbmcgaW4gYSBwZXJpb2Qg YmV0d2VlbiBjaGVja3Mgb2YgNCB0byA2IHNlY29uZHMuXG5cbiAgIEVhY2ggU1RVTiBiaW5kaW5n IHJlcXVlc3QgZm9yIGNvbnNlbnQgTVVTVCB1c2UgYSBuZXdcbiAgIGNyeXB0b2dyYXBoaWNhbGx5 IHN0cm9uZyBbUkZDNDA4Nl0gU1RVTiB0cmFuc2FjdGlvbiBJRC4gIEVhY2ggU1RVTlxuICAgYmlu ZGluZyByZXF1ZXN0cyBmb3IgY29uc2VudCBpcyB0cmFuc21pdHRlZCBvbmNlIG9ubHkuICBIZW5j ZSwgdGhlXG4gICBzZW5kZXIgY2Fubm90IGFzc3VtZSB0aGF0IGl0IHdpbGwgcmVjZWl2ZSBhIHJl c3BvbnNlIGZvciBlYWNoIGNvbnNlbnRcbiAgIHJlcXVlc3QsIGFuZCBhIHJlc3BvbnNlIG1pZ2h0 IGJlIGZvciBhIHByZXZpb3VzIHJlcXVlc3QgKHJhdGhlciB0aGFuXG4gICBmb3IgdGhlIG1vc3Qg cmVjZW50bHkgc2VudCByZXF1ZXN0KS4gIENvbnNlbnQgZXhwaXJhdGlvbiBjYXVzZXNcbiAgIGlt bWVkaWF0ZSB0ZXJtaW5hdGlvbiBvZiBhbGwgb3V0c3RhbmRpbmcgU1RVTiBjb25zZW50IHRyYW5z YWN0aW9ucy5cbiAgIEVhY2ggU1RVTiB0cmFuc2FjdGlvbiBpcyBtYWludGFpbmVkIHVudGlsIG9u ZSBvZiB0aGUgZm9sbG93aW5nXG4gICBjcml0ZXJpYSBpcyBmdWxmaWxsZWQ6XG5cbiAgIG8gIEEg U1RVTiByZXNwb25zZSBhc3NvY2lhdGVkIHdpdGggdGhlIHRyYW5zYWN0aW9uIGlzIHJlY2VpdmVk OyBvclxuXG4gICBvICBBIFNUVU4gcmVzcG9uc2UgYXNzb2NpYXRlZCB0byBhIG5ld2VyIHRyYW5z YWN0aW9uIGlzIHJlY2VpdmVkLlxuXG4gICBUbyBtZWV0IHRoZSBzZWN1cml0eSBuZWVkcyBvZiBj b25zZW50LCBhbiB1bnRydXN0ZWQgYXBwbGljYXRpb25cbiAgIChlLmcuLCBKYXZhU2NyaXB0IG9y IHNpZ25hbGluZyBzZXJ2ZXJzKSBNVVNUIE5PVCBiZSBhYmxlIHRvIG9idGFpbiBvclxuICAgY29u dHJvbCB0aGUgU1RVTiB0cmFuc2FjdGlvbiBJRCwgYmVjYXVzZSB0aGF0IGVuYWJsZXMgc3Bvb2Zp bmcgb2ZcbiAgIFNUVU4gcmVzcG9uc2VzLCBmYWxzaWZ5aW5nIGNvbnNlbnQuXG5cblxuXG5cblBl cnVtYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgNCwgMjAxNSAgICAgICAgICAg ICAgICBbUGFnZSA0XVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25z ZW50IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1XG5cblxuICAgVG8gcHJldmVudCBhdHRh Y2tzIG9uIHRoZSBwZWVyIGR1cmluZyBJQ0UgcmVzdGFydCwgYW4gZW5kcG9pbnQgdGhhdFxuICAg Y29udGludWVzIHRvIHNlbmQgdHJhZmZpYyBvbiB0aGUgcHJldmlvdXNseSB2YWxpZGF0ZWQgY2Fu ZGlkYXRlIHBhaXJcbiAgIGR1cmluZyBJQ0UgcmVzdGFydCBNVVNUIGNvbnRpbnVlIHRvIHBlcmZv cm0gY29uc2VudCBmcmVzaG5lc3Mgb24gdGhhdFxuICAgY2FuZGlkYXRlIHBhaXIgYXMgZGVzY3Jp YmVkIGVhcmxpZXIuXG5cbiAgIFdoaWxlIFRDUCBhZmZvcmRzIHNvbWUgcHJvdGVjdGlvbiBmcm9t IG9mZi1wYXRoIGF0dGFja2VycyAoW1JGQzU5NjFdLFxuICAgW1JGQzQ5NTNdKSwgdGhlcmUgaXMg c3RpbGwgYSByaXNrIGFuIGF0dGFja2VyIGNvdWxkIGNhdXNlIGEgVENQXG4gICBzZW5kZXIgdG8g c2VuZCBmb3JldmVyIGJ5IHNwb29maW5nIEFDS3MuICBUbyBwcmV2ZW50IHN1Y2ggYW4gYXR0YWNr LFxuICAgY29uc2VudCBjaGVja3MgTVVTVCBiZSBwZXJmb3JtZWQgb3ZlciBhbGwgdHJhbnNwb3J0 IGNvbm5lY3Rpb25zLFxuICAgaW5jbHVkaW5nIFRDUC4gIEluIHRoaXMgd2F5LCBhbiBvZmYtcGF0 aCBhdHRhY2tlciBzcG9vZmluZyBUQ1BcbiAgIHNlZ21lbnRzIGNhbiBub3QgY2F1c2UgYSBUQ1Ag c2VuZGVyIHRvIHNlbmQgb25jZSB0aGUgY29uc2VudCB0aW1lclxuICAgZXhwaXJlcyAoMzAgc2Vj b25kcykuXG5cbiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0 aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0b1xuICAgbWFpbnRhaW4gY29uc2VudC4gIEhvd2V2ZXIs IGZhaWx1cmUgdG8gc2VuZCBjb3VsZCBjYXVzZSBhbnkgTkFUIG9yXG4gICBmaXJld2FsbCBtYXBw aW5ncyBmb3IgdGhlIGZsb3cgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZyBvbmVcbiAg IHBlZXIgdW5hYmxlIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBB YnNlbnQgYmV0dGVyXG4gICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0d29yaywgYW4gZW5kcG9p bnQgU0hPVUxEIG1haW50YWluIGNvbnNlbnQgaWZcbiAgIHRoZXJlIGlzIGFueSBwb3NzaWJpbGl0 eSB0aGF0IGEgZmxvdyBtaWdodCBiZSBuZWVkZWQgYWdhaW4uXG5cbiAgIEFmdGVyIGNvbnNlbnQg aXMgbG9zdCBmb3IgYW55IHJlYXNvbiwgdGhlIHNhbWUgSUNFIGNyZWRlbnRpYWxzIE1VU1RcbiAg IE5PVCBiZSB1c2VkIG9uIHRoZSBhZmZlY3RlZCA1LXR1cGxlIGFnYWluLiAgVGhhdCBtZWFucyB0 aGF0IGEgbmV3XG4gICBzZXNzaW9uLCBvciBhbiBJQ0UgcmVzdGFydCwgaXMgbmVlZGVkIHRvIG9i dGFpbiBjb25zZW50IHRvIHNlbmQuXG5cbjQuMi4gIEltbWVkaWF0ZSBSZXZvY2F0aW9uIG9mIENv bnNlbnRcblxuICAgSW4gc29tZSBjYXNlcyBpdCBpcyB1c2VmdWwgdG8gc2lnbmFsIHRoYXQgY29u c2VudCBpcyB0ZXJtaW5hdGVkXG4gICByYXRoZXIgdGhhbiByZWx5aW5nIG9uIGEgdGltZW91dC5c blxuICAgQ29uc2VudCBmb3Igc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhIGlzIGltbWVkaWF0ZWx5 IHJldm9rZWQgYnlcbiAgIHJlY2VpcHQgb2YgYW4gYXV0aGVudGljYXRlZCBtZXNzYWdlIHRoYXQg Y2xvc2VzIHRoZSBjb25uZWN0aW9uIChlLmcuLFxuICAgYSBUTFMgZmF0YWwgYWxlcnQpIG9yIHJl Y2VpcHQgb2YgYSB2YWxpZCBhbmQgYXV0aGVudGljYXRlZCBTVFVOXG4gICByZXNwb25zZSB3aXRo IGVycm9yIGNvZGUgRm9yYmlkZGVuICg0MDMpLiAgTm90ZSBob3dldmVyIHRoYXQgY29uc2VudFxu ICAgcmV2b2NhdGlvbiBtZXNzYWdlcyBjYW4gYmUgbG9zdCBvbiB0aGUgbmV0d29yaywgc28gYW4g ZW5kcG9pbnQgY291bGRcbiAgIHJlc2VuZCB0aGVzZSBtZXNzYWdlcywgb3Igd2FpdCBmb3IgY29u c2VudCB0byBleHBpcmUuXG5cbiAgIFJlY2VpcHQgb2YgYW4gdW5hdXRoZW50aWNhdGVkIG1lc3Nh Z2UgdGhhdCBjbG9zZXMgYSBjb25uZWN0aW9uIChlLmcuLFxuICAgVENQIEZJTikgZG9lcyBub3Qg aW5kaWNhdGUgcmV2b2NhdGlvbiBvZiBjb25zZW50LiAgVGh1cywgYW4gZW5kcG9pbnRcbiAgIHJl Y2VpdmluZyBhbiB1bmF1dGhlbnRpY2F0ZWQgZW5kLW9mLXNlc3Npb24gbWVzc2FnZSBTSE9VTEQg Y29udGludWVcbiAgIHNlbmRpbmcgbWVkaWEgKG92ZXIgY29ubmVjdGlvbmxlc3MgdHJhbnNwb3J0 KSBvciBhdHRlbXB0IHRvIHJlLVxuICAgZXN0YWJsaXNoIHRoZSBjb25uZWN0aW9uIChvdmVyIGNv bm5lY3Rpb24tb3JpZW50ZWQgdHJhbnNwb3J0KSB1bnRpbFxuICAgY29uc2VudCBleHBpcmVzIG9y IGl0IHJlY2VpdmVzIGFuIGF1dGhlbnRpY2F0ZWQgbWVzc2FnZSByZXZva2luZ1xuICAgY29uc2Vu dC5cblxuICAgTm90ZSB0aGF0IGFuIGF1dGhlbnRpY2F0ZWQgU1JUQ1AgQllFIGRvZXMgbm90IHRl cm1pbmF0ZSBjb25zZW50OyBpdFxuICAgb25seSBpbmRpY2F0ZXMgdGhlIGFzc29jaWF0ZWQgU1JU UCBzb3VyY2UgaGFzIHF1aXQuXG5cblxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciA0LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDVdXG5fXG5JbnRlcm5l dC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgICAgICAg TWF5IDIwMTVcblxuXG41LiAgRGlmZlNlcnYgVHJlYXRtZW50IGZvciBDb25zZW50XG5cbiAgIEl0 IGlzIFJFQ09NTUVOREVEIHRoYXQgU1RVTiBjb25zZW50IGNoZWNrcyB1c2UgdGhlIHNhbWUgRGlm ZnNlcnZcbiAgIENvZGVwb2ludCBtYXJraW5ncyBhcyB0aGUgSUNFIGNvbm5lY3Rpdml0eSBjaGVj a3MgZGVzY3JpYmVkIGluXG4gICBTZWN0aW9uIDcuMS4yLjQgb2YgW1JGQzUyNDVdIGZvciBhIGdp dmVuIDUtdHVwbGUuXG5cbiAgIE5vdGU6ICBJdCBpcyBwb3NzaWJsZSB0aGF0IGRpZmZlcmVudCBE aWZmc2VydiBDb2RlcG9pbnRzIGFyZSB1c2VkIGJ5XG4gICAgICBkaWZmZXJlbnQgbWVkaWEgb3Zl ciB0aGUgc2FtZSB0cmFuc3BvcnQgYWRkcmVzc1xuICAgICAgW0ktRC5pZXRmLXRzdndnLXJ0Y3dl Yi1xb3NdLiAgU3VjaCBhIGNhc2UgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2ZcbiAgICAgIHRoaXMg ZG9jdW1lbnQuXG5cbjYuICBEVExTIGFwcGxpY2FiaWxpdHlcblxuICAgVGhlIERUTFMgYXBwbGlj YWJpbGl0eSBpcyBpZGVudGljYWwgdG8gd2hhdCBpcyBkZXNjcmliZWQgaW5cbiAgIFNlY3Rpb24g NC4yIG9mIFtSRkM3MzUwXS5cblxuNy4gIEFQSSBSZWNvbW1lbmRhdGlvbnNcblxuICAgVGhlIFcz QyBzcGVjaWZpY2F0aW9uIFtXM0MtV0VCUlRDXSBtYXkgcHJvdmlkZSBhbiBBUEkgaG9vayB0aGF0 XG4gICBnZW5lcmF0ZXMgYW4gZXZlbnQgd2hlbiBjb25zZW50IGhhcyBleHBpcmVkIGZvciBhIGdp dmVuIDUtdHVwbGUsXG4gICBtZWFuaW5nIHRoYXQgdHJhbnNtaXNzaW9uIG9mIGRhdGEgaGFzIGNl YXNlZC4gIFRoaXMgY291bGQgaW5kaWNhdGVcbiAgIHdoYXQgYXBwbGljYXRpb24gZGF0YSBpcyBh ZmZlY3RlZCwgc3VjaCBhcyBtZWRpYSBvciBkYXRhIGNoYW5uZWxzLlxuXG44LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnNcblxuICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzZWN1cml0eSBt ZWNoYW5pc20uXG5cbiAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzZWQgaW4g W1JGQzUyNDVdIHNob3VsZCBhbHNvIGJlXG4gICB0YWtlbiBpbnRvIGFjY291bnQuXG5cbiAgIFNS VFAgaXMgZW5jcnlwdGVkIGFuZCBhdXRoZW50aWNhdGVkIHdpdGggc3ltbWV0cmljIGtleXM7IHRo YXQgaXMsXG4gICBib3RoIHNlbmRlciBhbmQgcmVjZWl2ZXIga25vdyB0aGUga2V5cy4gIFdpdGgg dHdvIHBhcnR5IHNlc3Npb25zLFxuICAgcmVjZWlwdCBvZiBhbiBhdXRoZW50aWNhdGVkIHBhY2tl dCBmcm9tIHRoZSBzaW5nbGUgcmVtb3RlIHBhcnR5IGlzIGFcbiAgIHN0cm9uZyBhc3N1cmFuY2Ug dGhlIHBhY2tldCBjYW1lIGZyb20gdGhhdCBwYXJ0eS4gIEhvd2V2ZXIsIHdoZW4gYVxuICAgc2Vz c2lvbiBpbnZvbHZlcyBtb3JlIHRoYW4gdHdvIHBhcnRpZXMsIGFsbCBvZiB3aG9tIGtub3cgZWFj aCBvdGhlcnNcbiAgIGtleXMsIGFueSBvZiB0aG9zZSBwYXJ0aWVzIGNvdWxkIGhhdmUgc2VudCAo b3Igc3Bvb2ZlZCkgdGhlIHBhY2tldC5cbiAgIFN1Y2ggc2hhcmVkIGtleSBkaXN0cmlidXRpb25z IGFyZSBwb3NzaWJsZSB3aXRoIHNvbWUgTUlLRVkgW1JGQzM4MzBdXG4gICBtb2RlcywgU2VjdXJp dHkgRGVzY3JpcHRpb25zIFtSRkM0NTY4XSwgYW5kIEVLVFxuICAgW0ktRC5pZXRmLWF2dGNvcmUt c3J0cC1la3RdLiAgVGh1cywgaW4gc3VjaCBzaGFyZWQga2V5aW5nXG4gICBkaXN0cmlidXRpb25z LCByZWNlaXB0IG9mIGFuIGF1dGhlbnRpY2F0ZWQgU1JUUCBwYWNrZXQgaXMgbm90XG4gICBzdWZm aWNpZW50IHRvIHZlcmlmeSBjb25zZW50LlxuXG45LiAgSUFOQSBDb25zaWRlcmF0aW9uc1xuXG4g ICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHJlcXVpcmUgYW55IGFjdGlvbiBmcm9tIElBTkEuXG5c blxuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIw MTUgICAgICAgICAgICAgICAgW1BhZ2UgNl1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBV c2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNVxuXG5cbjEwLiAg QWNrbm93bGVkZ2VtZW50XG5cbiAgIFRoYW5rcyB0byBFcmljIFJlc2NvcmxhLCBIYXJhbGQgQWx2 ZXN0cmFuZCwgQmVybmFyZCBBYm9iYSwgTWFnbnVzXG4gICBXZXN0ZXJsYW5kLCBDdWxsZW4gSmVu bmluZ3MsIENocmlzdGVyIEhvbG1iZXJnLCBTaW1vbiBQZXJyZWF1bHQsIFBhdWxcbiAgIEt5eml2 YXQsIEVtaWwgSXZvdiwgSm9uYXRoYW4gTGVubm94LCBJbmFraSBCYXogQ2FzdGlsbG8sIFJham1v aGFuXG4gICBCYW5hdmkgYW5kIENocmlzdGlhbiBHcm92ZXMgZm9yIHRoZWlyIHZhbHVhYmxlIGlu cHV0cyBhbmQgY29tbWVudHMuXG4gICBUaGFua3MgdG8gQ2hyaXN0ZXIgSG9sbWJlcmcgZm9yIGRv aW5nIGEgdGhyb3VnaCByZXZpZXcuXG5cbjExLiAgUmVmZXJlbmNlc1xuXG4xMS4xLiAgTm9ybWF0 aXZlIFJlZmVyZW5jZXNcblxuICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGVcbiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2 ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny5cblxuICAgW1JGQzQwODZdICBFYXN0 bGFrZSwgRC4sIFNjaGlsbGVyLCBKLiwgYW5kIFMuIENyb2NrZXIsICJSYW5kb21uZXNzXG4gICAg ICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU2VjdXJpdHkiLCBCQ1AgMTA2LCBSRkMgNDA4Niwg SnVuZSAyMDA1LlxuXG4gICBbUkZDNTI0NV0gIFJvc2VuYmVyZywgSi4sICJJbnRlcmFjdGl2ZSBD b25uZWN0aXZpdHkgRXN0YWJsaXNobWVudFxuICAgICAgICAgICAgICAoSUNFKTogQSBQcm90b2Nv bCBmb3IgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0b3IgKE5BVClcbiAgICAgICAgICAgICAgVHJh dmVyc2FsIGZvciBPZmZlci9BbnN3ZXIgUHJvdG9jb2xzIiwgUkZDIDUyNDUsIEFwcmlsXG4gICAg ICAgICAgICAgIDIwMTAuXG5cbiAgIFtSRkM2MjYzXSAgTWFyam91LCBYLiBhbmQgQS4gU29sbGF1 ZCwgIkFwcGxpY2F0aW9uIE1lY2hhbmlzbSBmb3JcbiAgICAgICAgICAgICAgS2VlcGluZyBBbGl2 ZSB0aGUgTkFUIE1hcHBpbmdzIEFzc29jaWF0ZWQgd2l0aCBSVFAgLyBSVFBcbiAgICAgICAgICAg ICAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgRmxvd3MiLCBSRkMgNjI2MywgSnVuZSAyMDExLlxu XG4xMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlc1xuXG4gICBbSS1ELmlldGYtYXZ0Y29yZS1z cnRwLWVrdF1cbiAgICAgICAgICAgICAgTWF0dHNzb24sIEouLCBNY0dyZXcsIEQuLCBhbmQgRC4g V2luZywgIkVuY3J5cHRlZCBLZXlcbiAgICAgICAgICAgICAgVHJhbnNwb3J0IGZvciBTZWN1cmUg UlRQIiwgZHJhZnQtaWV0Zi1hdnRjb3JlLXNydHAtZWt0LTAzXG4gICAgICAgICAgICAgICh3b3Jr IGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDE0LlxuXG4gICBbSS1ELmlldGYtcnRjd2ViLW92ZXJ2 aWV3XVxuICAgICAgICAgICAgICBBbHZlc3RyYW5kLCBILiwgIk92ZXJ2aWV3OiBSZWFsIFRpbWUg UHJvdG9jb2xzIGZvclxuICAgICAgICAgICAgICBCcm93c2VyLWJhc2VkIEFwcGxpY2F0aW9ucyIs IGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEzXG4gICAgICAgICAgICAgICh3b3JrIGluIHBy b2dyZXNzKSwgTm92ZW1iZXIgMjAxNC5cblxuICAgW0ktRC5pZXRmLXRzdndnLXJ0Y3dlYi1xb3Nd XG4gICAgICAgICAgICAgIERoZXNpa2FuLCBTLiwgSmVubmluZ3MsIEMuLCBEcnV0YSwgRC4sIEpv bmVzLCBQLiwgYW5kIEouXG4gICAgICAgICAgICAgIFBvbGssICJEU0NQIGFuZCBvdGhlciBwYWNr ZXQgbWFya2luZ3MgZm9yIFJUQ1dlYiBRb1MiLFxuICAgICAgICAgICAgICBkcmFmdC1pZXRmLXRz dndnLXJ0Y3dlYi1xb3MtMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLFxuICAgICAgICAgICAgICBOb3Zl bWJlciAyMDE0LlxuXG4gICBbUkZDMzgzMF0gIEFya2tvLCBKLiwgQ2FycmFyYSwgRS4sIExpbmRo b2xtLCBGLiwgTmFzbHVuZCwgTS4sIGFuZCBLLlxuICAgICAgICAgICAgICBOb3JybWFuLCAiTUlL RVk6IE11bHRpbWVkaWEgSW50ZXJuZXQgS0VZaW5nIiwgUkZDIDM4MzAsXG4gICAgICAgICAgICAg IEF1Z3VzdCAyMDA0LlxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3Zl bWJlciA0LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDddXG5fXG5JbnRlcm5ldC1EcmFmdCAg ICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgICAgICAgTWF5IDIwMTVc blxuXG4gICBbUkZDNDU2OF0gIEFuZHJlYXNlbiwgRi4sIEJhdWdoZXIsIE0uLCBhbmQgRC4gV2lu ZywgIlNlc3Npb25cbiAgICAgICAgICAgICAgRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgU2Vj dXJpdHkgRGVzY3JpcHRpb25zIGZvciBNZWRpYVxuICAgICAgICAgICAgICBTdHJlYW1zIiwgUkZD IDQ1NjgsIEp1bHkgMjAwNi5cblxuICAgW1JGQzQ5NTNdICBUb3VjaCwgSi4sICJEZWZlbmRpbmcg VENQIEFnYWluc3QgU3Bvb2ZpbmcgQXR0YWNrcyIsIFJGQ1xuICAgICAgICAgICAgICA0OTUzLCBK dWx5IDIwMDcuXG5cbiAgIFtSRkM1OTYxXSAgUmFtYWlhaCwgQS4sIFN0ZXdhcnQsIFIuLCBhbmQg TS4gRGFsYWwsICJJbXByb3ZpbmcgVENQXCdzXG4gICAgICAgICAgICAgIFJvYnVzdG5lc3MgdG8g QmxpbmQgSW4tV2luZG93IEF0dGFja3MiLCBSRkMgNTk2MSwgQXVndXN0XG4gICAgICAgICAgICAg IDIwMTAuXG5cbiAgIFtSRkM2MDYyXSAgUGVycmVhdWx0LCBTLiBhbmQgSi4gUm9zZW5iZXJnLCAi VHJhdmVyc2FsIFVzaW5nIFJlbGF5c1xuICAgICAgICAgICAgICBhcm91bmQgTkFUIChUVVJOKSBF eHRlbnNpb25zIGZvciBUQ1AgQWxsb2NhdGlvbnMiLCBSRkNcbiAgICAgICAgICAgICAgNjA2Miwg Tm92ZW1iZXIgMjAxMC5cblxuICAgW1JGQzczNTBdICBQZXRpdC1IdWd1ZW5pbiwgTS4gYW5kIEcu IFNhbGd1ZWlybywgIkRhdGFncmFtIFRyYW5zcG9ydFxuICAgICAgICAgICAgICBMYXllciBTZWN1 cml0eSAoRFRMUykgYXMgVHJhbnNwb3J0IGZvciBTZXNzaW9uIFRyYXZlcnNhbFxuICAgICAgICAg ICAgICBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikiLCBSRkMgNzM1MCwgQXVndXN0IDIwMTQuXG5c biAgIFtXM0MtV0VCUlRDXVxuICAgICAgICAgICAgICBCZXJna3Zpc3QsIEEuLCBCdXJuZXR0LCBE LiwgTmFyYXlhbmFuLCBBLiwgYW5kIEMuXG4gICAgICAgICAgICAgIEplbm5pbmdzLCAiV2ViUlRD IDEuMDogUmVhbC10aW1lIENvbW11bmljYXRpb24gQmV0d2VlblxuICAgICAgICAgICAgICBCcm93 c2VycyIsIGZlYnJ1YXJ5IDIwMTUuXG5cbkF1dGhvcnNcJyBBZGRyZXNzZXNcblxuICAgTXV0aHUg QXJ1bCBNb3poaSBQZXJ1bWFsXG4gICBFcmljc3NvblxuICAgRmVybnMgSWNvblxuICAgRG9kZGFu ZWt1bmRpLCBNYWhhZGV2YXB1cmFcbiAgIEJhbmdhbG9yZSwgS2FybmF0YWthICA1NjAwMzdcbiAg IEluZGlhXG5cbiAgIEVtYWlsOiBtdXRodS5hcnVsQGdtYWlsLmNvbVxuXG5cbiAgIERhbiBXaW5n XG4gICBDaXNjbyBTeXN0ZW1zXG4gICA4MjEgQWxkZXIgRHJpdmVcbiAgIE1pbHBpdGFzLCBDYWxp Zm9ybmlhICA5NTAzNVxuICAgVVNBXG5cbiAgIEVtYWlsOiBkd2luZ0BjaXNjby5jb21cblxuXG5c blxuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIw MTUgICAgICAgICAgICAgICAgW1BhZ2UgOF1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBV c2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNVxuXG5cbiAgIFJh bSBNb2hhbiBSYXZpbmRyYW5hdGhcbiAgIENpc2NvIFN5c3RlbXNcbiAgIENlc3NuYSBCdXNpbmVz cyBQYXJrXG4gICBTYXJqYXB1ci1NYXJhdGhhaGFsbGkgT3V0ZXIgUmluZyBSb2FkXG4gICBCYW5n YWxvcmUsIEthcm5hdGFrYSAgNTYwMTAzXG4gICBJbmRpYVxuXG4gICBFbWFpbDogcm1vaGFuckBj aXNjby5jb21cblxuXG4gICBUaXJ1bWFsZXN3YXIgUmVkZHlcbiAgIENpc2NvIFN5c3RlbXNcbiAg IENlc3NuYSBCdXNpbmVzcyBQYXJrLCBWYXJ0aHVyIEhvYmxpXG4gICBTYXJqYXB1ciBNYXJhdGhh bGxpIE91dGVyIFJpbmcgUm9hZFxuICAgQmFuZ2Fsb3JlLCBLYXJuYXRha2EgIDU2MDEwM1xuICAg SW5kaWFcblxuICAgRW1haWw6IHRpcmVkZHlAY2lzY28uY29tXG5cblxuICAgTWFydGluIFRob21z b25cbiAgIE1vemlsbGFcbiAgIFN1aXRlIDMwMFxuICAgNjUwIENhc3RybyBTdHJlZXRcbiAgIE1v dW50YWluIFZpZXcsIENhbGlmb3JuaWEgIDk0MDQxXG4gICBVU1xuXG4gICBFbWFpbDogbWFydGlu LnRob21zb25AZ21haWwuY29tXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5c blxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciA0LCAyMDE1 ICAgICAgICAgICAgICAgIFtQYWdlIDldXG4nLCAnZmlsZW5hbWUxJzogJ1xuXG5cblxuUlRDV0VC ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBN LiBQZXJ1bWFsXG5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRXJpY3Nzb25cbkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRy YWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gV2luZ1xuRXhwaXJlczogSnVu ZSAyMCwgMjAxNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gUmF2aW5kcmFu YXRoXG4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVC4gUmVkZHlcbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtc1xuICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBUaG9tc29uXG4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE1vemlsbGFcbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBEZWNlbWJlciAxNywgMjAxNFxuXG5cbiAgICAgICAgICAgICAgICAgICAg U1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3NcbiAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMVxuXG5BYnN0cmFjdFxuXG4gICBUbyBw cmV2ZW50IHNlbmRpbmcgZXhjZXNzaXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGlj IGNvbnNlbnRcbiAgIG5lZWRzIHRvIGJlIG9idGFpbmVkIGZyb20gdGhhdCByZW1vdGUgZW5kcG9p bnQuXG5cbiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29uc2VudCBtZWNoYW5pc20gdXNp bmcgYSBuZXcgU2Vzc2lvblxuICAgVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKSB1 c2FnZS5cblxuU3RhdHVzIG9mIFRoaXMgTWVtb1xuXG4gICBUaGlzIEludGVybmV0LURyYWZ0IGlz IHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlXG4gICBwcm92aXNpb25zIG9m IEJDUCA3OCBhbmQgQkNQIDc5LlxuXG4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZ1xuICAgVGFzayBGb3JjZSAoSUVURiku ICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGVcbiAgIHdvcmtpbmcg ZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtXG4gICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9j dXJyZW50Ly5cblxuICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQg Zm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzXG4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxh Y2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueVxuICAgdGltZS4gIEl0 IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2VcbiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiJcblxuICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBKdW5lIDIwLCAyMDE1 LlxuXG5Db3B5cmlnaHQgTm90aWNlXG5cbiAgIENvcHlyaWdodCAoYykgMjAxNCBJRVRGIFRydXN0 IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZVxuICAgZG9jdW1lbnQgYXV0aG9ycy4g IEFsbCByaWdodHMgcmVzZXJ2ZWQuXG5cbiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBC Q1AgNzggYW5kIHRoZSBJRVRGIFRydXN0XCdzIExlZ2FsXG4gICBQcm92aXNpb25zIFJlbGF0aW5n IHRvIElFVEYgRG9jdW1lbnRzXG4gICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2ZcbiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9j dW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50c1xuXG5cblxuUGVydW1hbCwgZXQg YWwuICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdl IDFdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2hu ZXNzICAgICAgIERlY2VtYmVyIDIwMTRcblxuXG4gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3Jp YmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3RcbiAgIHRvIHRoaXMg ZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBt dXN0XG4gICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiA0LmUgb2ZcbiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUg cHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhc1xuICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlLlxuXG5UYWJsZSBvZiBDb250ZW50c1xuXG4gICAxLiAgSW50cm9kdWN0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDJc biAgIDIuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgM1xuICAgMy4gIERlc2lnbiBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzXG4gICA0LiAgU29sdXRpb24gIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDNcbiAgICAg NC4xLiAgRXhwaXJhdGlvbiBvZiBDb25zZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgM1xuICAgICA0LjIuICBJbW1lZGlhdGUgUmV2b2NhdGlvbiBvZiBDb25zZW50IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1XG4gICA1LiAgRGlmZlNlcnYgVHJlYXRtZW50IGZv ciBDb25zZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZcbiAgIDYuICBEVExT IGFwcGxpY2FiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgNlxuICAgNy4gIEFQSSBSZWNvbW1lbmRhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA2XG4gICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZcbiAgIDkuICBJQU5BIENvbnNp ZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgN1xu ICAgMTAuIEFja25vd2xlZGdlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA3XG4gICAxMS4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDdcbiAgICAgMTEuMS4gIE5vcm1hdGl2ZSBS ZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgN1xuICAgICAx MS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA3XG4gICBBdXRob3JzXCcgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4XG5cbjEuICBJbnRyb2R1Y3Rpb25cblxuICAgVG8g cHJldmVudCBhdHRhY2tzIG9uIHBlZXJzLCBlbmRwb2ludHMgaGF2ZSB0byBlbnN1cmUgdGhlIHJl bW90ZSBwZWVyXG4gICBpcyB3aWxsaW5nIHRvIHJlY2VpdmUgdHJhZmZpYy4gIFRoaXMgaXMgcGVy Zm9ybWVkIGJvdGggd2hlbiB0aGVcbiAgIHNlc3Npb24gaXMgZmlyc3QgZXN0YWJsaXNoZWQgdG8g dGhlIHJlbW90ZSBwZWVyIHVzaW5nIEludGVyYWN0aXZlXG4gICBDb25uZWN0aXZpdHkgRXN0YWJs aXNobWVudCBJQ0UgW1JGQzUyNDVdIGNvbm5lY3Rpdml0eSBjaGVja3MsIGFuZFxuICAgcGVyaW9k aWNhbGx5IGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIHNlc3Npb24gdXNpbmcgdGhlIHByb2NlZHVy ZXNcbiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC5cblxuICAgV2hlbiBhIHNlc3Npb24gaXMg Zmlyc3QgZXN0YWJsaXNoZWQsIElDRSBpbXBsZW1lbnRhdGlvbnMgb2J0YWluIGFuXG4gICBpbml0 aWFsIGNvbnNlbnQgdG8gc2VuZCBieSBwZXJmb3JtaW5nIFNUVU4gY29ubmVjdGl2aXR5IGNoZWNr cy4gIFRoaXNcbiAgIGRvY3VtZW50IGRlc2NyaWJlcyBhIG5ldyBTVFVOIHVzYWdlIHdpdGggZXhj aGFuZ2Ugb2YgcmVxdWVzdCBhbmRcbiAgIHJlc3BvbnNlIG1lc3NhZ2VzIHRoYXQgdmVyaWZpZXMg dGhlIHJlbW90ZSBwZWVyXCdzIG9uZ29pbmcgY29uc2VudCB0b1xuICAgcmVjZWl2ZSB0cmFmZmlj LiAgVGhpcyBjb25zZW50IGV4cGlyZXMgYWZ0ZXIgYSBwZXJpb2Qgb2YgdGltZSBhbmRcbiAgIG5l ZWRzIHRvIGJlIGNvbnRpbnVhbGx5IHJlbmV3ZWQsIHdoaWNoIGVuc3VyZXMgdGhhdCBjb25zZW50 IGNhbiBiZVxuICAgdGVybWluYXRlZC5cblxuICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHdoYXQg aXQgdGFrZXMgdG8gb2J0YWluLCBtYWludGFpbiwgYW5kIGxvc2VcbiAgIGNvbnNlbnQgdG8gc2Vu ZC4gIENvbnNlbnQgdG8gc2VuZCBhcHBsaWVzIHRvIGEgc2luZ2xlIDUtdHVwbGUuICBIb3dcbiAg IGFwcGxpY2F0aW9ucyByZWFjdCB0byBjaGFuZ2VzIGluIGNvbnNlbnQgaXMgbm90IGRlc2NyaWJl ZCBpbiB0aGlzXG4gICBkb2N1bWVudC5cblxuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4gICAgICAg ICAgIEV4cGlyZXMgSnVuZSAyMCwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgMl1cbl9cbklu dGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAg RGVjZW1iZXIgMjAxNFxuXG5cbiAgIENvbnNlbnQgaXMgb2J0YWluZWQgb25seSBieSBmdWxsIElD RSBpbXBsZW1lbnRhdGlvbnMuICBBbiBJQ0UtbGl0ZVxuICAgaW1wbGVtZW50YXRpb24gd2lsbCBu b3QgZ2VuZXJhdGUgY29uc2VudCBjaGVja3MsIGJ1dCB3aWxsIGp1c3RcbiAgIHJlc3BvbmQgdG8g Y29uc2VudCBjaGVja3MgaXQgcmVjZWl2ZXMuICBObyBjaGFuZ2VzIGFyZSByZXF1aXJlZCB0b1xu ICAgSUNFLWxpdGUgaW1wbGVtZW50YXRpb25zIGluIG9yZGVyIHRvIHJlc3BvbmQgdG8gY29uc2Vu dCBjaGVja3MsIGFzXG4gICB0aGV5IGFyZSBwcm9jZXNzZWQgYXMgbm9ybWFsIElDRSBjb25uZWN0 aXZpdHkgY2hlY2tzLlxuXG4yLiAgVGVybWlub2xvZ3lcblxuICAgVGhlIGtleSB3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLFxuICAgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXNcbiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gW1JGQzIxMTldLlxuXG4gICBDb25zZW50OiAgVGhlIG1lY2hhbmlzbSBvZiBvYnRhaW5pbmcg cGVybWlzc2lvbiB0byBzZW5kIHRvIGEgcmVtb3RlXG4gICAgICB0cmFuc3BvcnQgYWRkcmVzcy4g IEluaXRpYWwgY29uc2VudCBpcyBvYnRhaW5lZCB1c2luZyBJQ0UuXG5cbiAgIENvbnNlbnQgRnJl c2huZXNzOiAgTWFpbnRhaW5pbmcgYW5kIHJlbmV3aW5nIGNvbnNlbnQgb3ZlciB0aW1lLlxuXG4g ICBUcmFuc3BvcnQgQWRkcmVzczogIFRoZSByZW1vdGUgcGVlclwncyBJUCBhZGRyZXNzIGFuZCBV RFAgb3IgVENQIHBvcnRcbiAgICAgIG51bWJlci5cblxuMy4gIERlc2lnbiBDb25zaWRlcmF0aW9u c1xuXG4gICBBbHRob3VnaCBJQ0UgcmVxdWlyZXMgcGVyaW9kaWMga2VlcGFsaXZlIHRyYWZmaWMg dG8ga2VlcCBOQVQgYmluZGluZ3NcbiAgIGFsaXZlIChTZWN0aW9uIDEwIG9mIFtSRkM1MjQ1XSwg W1JGQzYyNjNdKSwgdGhvc2Uga2VlcGFsaXZlcyBhcmUgc2VudFxuICAgYXMgU1RVTiBJbmRpY2F0 aW9ucyB3aGljaCBhcmUgc2VuZC1hbmQtZm9yZ2V0LCBhbmQgZG8gbm90IGV2b2tlIGFcbiAgIHJl c3BvbnNlLiAgQSByZXNwb25zZSBpcyBuZWNlc3NhcnkgZm9yIGNvbnNlbnQgdG8gY29udGludWUg c2VuZGluZ1xuICAgdHJhZmZpYy4gIFRodXMsIHdlIG5lZWQgYSByZXF1ZXN0L3Jlc3BvbnNlIG1l Y2hhbmlzbSBmb3IgY29uc2VudFxuICAgZnJlc2huZXNzLiAgSUNFIGNhbiBiZSB1c2VkIGZvciB0 aGF0IG1lY2hhbmlzbSBiZWNhdXNlIElDRVxuICAgaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5 IHJlcXVpcmVkIHRvIGNvbnRpbnVlIGxpc3RlbmluZyBmb3IgSUNFXG4gICBtZXNzYWdlcywgYXMg ZGVzY3JpYmVkIGluIHNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdLiAgSWYgY29uc2VudCBpc1xuICAg cGVyZm9ybWVkIHRoZW4gdGhlcmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZSBtZXNzYWdl cy5cblxuNC4gIFNvbHV0aW9uXG5cbiAgIFRoZXJlIGFyZSB0d28gd2F5cyBjb25zZW50IHRvIHNl bmQgdHJhZmZpYyBpcyByZXZva2VkOiBleHBpcmF0aW9uIG9mXG4gICBjb25zZW50IGFuZCBpbW1l ZGlhdGUgcmV2b2NhdGlvbiBvZiBjb25zZW50LCB3aGljaCBhcmUgZGlzY3Vzc2VkIGluXG4gICB0 aGUgZm9sbG93aW5nIHNlY3Rpb25zLlxuXG40LjEuICBFeHBpcmF0aW9uIG9mIENvbnNlbnRcblxu ICAgQSBmdWxsIElDRSBpbXBsZW1lbnRhdGlvbiBwZXJmb3JtcyBjb25zZW50IGZyZXNobmVzcyB0 ZXN0IHVzaW5nIFNUVU5cbiAgIHJlcXVlc3QvcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGJlbG93Olxu XG4gICBBbiBlbmRwb2ludCBNVVNUIE5PVCBzZW5kIGRhdGEgb3RoZXIgdGhhbiBwYWNlZCBTVFVO IGNvbm5lY3Rpdml0eVxuICAgY2hlY2tzIG9yIHJlc3BvbnNlcyB0b3dhcmQgYW55IHRyYW5zcG9y dCBhZGRyZXNzIHVubGVzcyB0aGUgcmVjZWl2aW5nXG4gICBlbmRwb2ludCBjb25zZW50cyB0byBy ZWNlaXZlIGRhdGEuICBUaGF0IGlzLCBubyBhcHBsaWNhdGlvbiBkYXRhXG4gICAoZS5nLiwgUlRQ IG9yIERUTFMpIGNhbiBiZSBzZW50IHVudGlsIGNvbnNlbnQgaXMgb2J0YWluZWQuICBBZnRlciBh XG4gICBzdWNjZXNzZnVsIElDRSBjb25uZWN0aXZpdHkgY2hlY2sgb24gYSBwYXJ0aWN1bGFyIHRy YW5zcG9ydCBhZGRyZXNzLFxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgICBFeHBpcmVz IEp1bmUgMjAsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDNdXG5fXG5JbnRlcm5ldC1EcmFm dCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgIERlY2VtYmVyIDIw MTRcblxuXG4gICBjb25zZW50IE1VU1QgYmUgbWFpbnRhaW5lZCBmb2xsb3dpbmcgdGhlIHByb2Nl ZHVyZSBkZXNjcmliZWQgaW4gdGhpc1xuICAgZG9jdW1lbnQuXG5cbiAgIEV4cGxpY2l0IGNvbnNl bnQgdG8gc2VuZCBpcyBvYnRhaW5lZCBhbmQgbWFpbnRhaW5lZCBieSBzZW5kaW5nIGFuXG4gICBT VFVOIGJpbmRpbmcgcmVxdWVzdCB0byB0aGUgcmVtb3RlIHBlZXJcJ3MgdHJhbnNwb3J0IGFkZHJl c3MgYW5kXG4gICByZWNlaXZpbmcgYSBtYXRjaGluZywgYXV0aGVudGljYXRlZCwgbm9uLWVycm9y IFNUVU4gYmluZGluZyByZXNwb25zZVxuICAgZnJvbSB0aGUgcmVtb3RlIHBlZXJcJ3MgdHJhbnNw b3J0IGFkZHJlc3MuICBUaGVzZSBTVFVOIGJpbmRpbmdcbiAgIHJlcXVlc3RzIGFuZCByZXNwb25z ZXMgYXJlIGF1dGhlbnRpY2F0ZWQgdXNpbmcgdGhlIHNhbWUgc2hvcnQtdGVybVxuICAgY3JlZGVu dGlhbHMgYXMgdGhlIGluaXRpYWwgSUNFIGV4Y2hhbmdlLlxuXG4gICBOb3RlOiAgQWx0aG91Z2gg VENQIGhhcyBpdHMgb3duIGNvbnNlbnQgbWVjaGFuaXNtIChUQ1BcbiAgICAgIGFja25vd2xlZGdl bWVudHMpLCBjb25zZW50IGlzIG5lY2Vzc2FyeSBvdmVyIGEgVENQIGNvbm5lY3Rpb25cbiAgICAg IGJlY2F1c2UgaXQgY291bGQgYmUgdHJhbnNsYXRlZCB0byBhIFVEUCBjb25uZWN0aW9uIChlLmcu LFxuICAgICAgW1JGQzYwNjJdKS5cblxuICAgSW5pdGlhbCBjb25zZW50IHRvIHNlbmQgdHJhZmZp YyBpcyBvYnRhaW5lZCB1c2luZyBJQ0UuICBDb25zZW50XG4gICBleHBpcmVzIGFmdGVyIDMwIHNl Y29uZHMuICBUaGF0IGlzLCBpZiBhIHZhbGlkIFNUVU4gYmluZGluZyByZXNwb25zZVxuICAgY29y cmVzcG9uZGluZyB0byBhbnkgU1RVTiByZXF1ZXN0IHNlbnQgaW4gdGhlIGxhc3QgMzAgc2Vjb25k cyBoYXMgbm90XG4gICBiZWVuIHJlY2VpdmVkIGZyb20gdGhlIHJlbW90ZSBwZWVyXCdzIHRyYW5z cG9ydCBhZGRyZXNzLCB0aGUgZW5kcG9pbnRcbiAgIE1VU1QgY2Vhc2UgdHJhbnNtaXNzaW9uIG9u IHRoYXQgNS10dXBsZS4gIFNUVU4gY29uc2VudCByZXNwb25zZXNcbiAgIHJlY2VpdmVkIGFmdGVy IGNvbnNlbnQgZXhwaXJ5IGRvIG5vdCByZS1lc3RhYmxpc2ggY29uc2VudCwgYW5kIG1heSBiZVxu ICAgZGlzY2FyZGVkIG9yIGNhdXNlIGFuIElDTVAgZXJyb3IuXG5cbiAgIFRvIHByZXZlbnQgZXhw aXJ5IG9mIGNvbnNlbnQsIGEgU1RVTiBiaW5kaW5nIHJlcXVlc3QgY2FuIGJlIHNlbnRcbiAgIHBl cmlvZGljYWxseS4gIFRvIHByZXZlbnQgc3luY2hyb25pemF0aW9uIG9mIGNvbnNlbnQgY2hlY2tz LCBlYWNoXG4gICBpbnRlcnZhbCBNVVNUIGJlIHJhbmRvbWl6ZWQgZnJvbSBiZXR3ZWVuIDAuOCBh bmQgMS4yIHRpbWVzIHRoZSBiYXNpY1xuICAgcGVyaW9kLiAgSW1wbGVtZW50YXRpb25zIFNIT1VM RCBzZXQgYSBkZWZhdWx0IGludGVydmFsIG9mIDUgc2Vjb25kcyxcbiAgIHJlc3VsdGluZyBpbiBh IHBlcmlvZCBiZXR3ZWVuIGNoZWNrcyBvZiA0IHRvIDYgc2Vjb25kcy5cblxuICAgRWFjaCBTVFVO IGJpbmRpbmcgcmVxdWVzdCBmb3IgY29uc2VudCBNVVNUIHVzZSBhIG5ld1xuICAgY3J5cHRvZ3Jh cGhpY2FsbHkgc3Ryb25nIFtSRkM0MDg2XSBTVFVOIHRyYW5zYWN0aW9uIElELiAgRWFjaCBTVFVO XG4gICBiaW5kaW5nIHJlcXVlc3RzIGZvciBjb25zZW50IGlzIHRyYW5zbWl0dGVkIG9uY2Ugb25s eS4gIEhlbmNlLCB0aGVcbiAgIHNlbmRlciBjYW5ub3QgYXNzdW1lIHRoYXQgaXQgd2lsbCByZWNl aXZlIGEgcmVzcG9uc2UgZm9yIGVhY2ggY29uc2VudFxuICAgcmVxdWVzdCwgYW5kIGEgcmVzcG9u c2UgbWlnaHQgYmUgZm9yIGEgcHJldmlvdXMgcmVxdWVzdCAocmF0aGVyIHRoYW5cbiAgIGZvciB0 aGUgbW9zdCByZWNlbnRseSBzZW50IHJlcXVlc3QpLiAgQ29uc2VudCBleHBpcmF0aW9uIGNhdXNl c1xuICAgaW1tZWRpYXRlIHRlcm1pbmF0aW9uIG9mIGFsbCBvdXRzdGFuZGluZyBTVFVOIGNvbnNl bnQgdHJhbnNhY3Rpb25zLlxuICAgRWFjaCBTVFVOIHRyYW5zYWN0aW9uIGlzIG1haW50YWluZWQg dW50aWwgb25lIG9mIHRoZSBmb2xsb3dpbmdcbiAgIGNyaXRlcmlhIGlzIGZ1bGZpbGxlZDpcblxu ICAgbyAgQSBTVFVOIHJlc3BvbnNlIGFzc29jaWF0ZWQgd2l0aCB0aGUgdHJhbnNhY3Rpb24gaXMg cmVjZWl2ZWQ7IG9yXG5cbiAgIG8gIEEgU1RVTiByZXNwb25zZSBhc3NvY2lhdGVkIHRvIGEgbmV3 ZXIgdHJhbnNhY3Rpb24gaXMgcmVjZWl2ZWQuXG5cbiAgIFRvIG1lZXQgdGhlIHNlY3VyaXR5IG5l ZWRzIG9mIGNvbnNlbnQsIGFuIHVudHJ1c3RlZCBhcHBsaWNhdGlvblxuICAgKGUuZy4sIEphdmFT Y3JpcHQgb3Igc2lnbmFsaW5nIHNlcnZlcnMpIE1VU1QgTk9UIGJlIGFibGUgdG8gb2J0YWluIG9y XG4gICBjb250cm9sIHRoZSBTVFVOIHRyYW5zYWN0aW9uIElELCBiZWNhdXNlIHRoYXQgZW5hYmxl cyBzcG9vZmluZyBvZlxuICAgU1RVTiByZXNwb25zZXMsIGZhbHNpZnlpbmcgY29uc2VudC5cblxu XG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAsIDIwMTUgICAg ICAgICAgICAgICAgIFtQYWdlIDRdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2Ug Zm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgIERlY2VtYmVyIDIwMTRcblxuXG4gICBUbyBwcmV2 ZW50IGF0dGFja3Mgb24gdGhlIHBlZXIgZHVyaW5nIElDRSByZXN0YXJ0LCBhbiBlbmRwb2ludCB0 aGF0XG4gICBjb250aW51ZXMgdG8gc2VuZCB0cmFmZmljIG9uIHRoZSBwcmV2aW91c2x5IHZhbGlk YXRlZCBjYW5kaWRhdGUgcGFpclxuICAgZHVyaW5nIElDRSByZXN0YXJ0IE1VU1QgY29udGludWUg dG8gcGVyZm9ybSBjb25zZW50IGZyZXNobmVzcyBvbiB0aGF0XG4gICBjYW5kaWRhdGUgcGFpciBh cyBkZXNjcmliZWQgZWFybGllci5cblxuICAgV2hpbGUgVENQIGFmZm9yZHMgc29tZSBwcm90ZWN0 aW9uIGZyb20gb2ZmLXBhdGggYXR0YWNrZXJzIChbUkZDNTk2MV0sXG4gICBbUkZDNDk1M10pLCB0 aGVyZSBpcyBzdGlsbCBhIHJpc2sgYW4gYXR0YWNrZXIgY291bGQgY2F1c2UgYSBUQ1BcbiAgIHNl bmRlciB0byBzZW5kIGZvcmV2ZXIgYnkgc3Bvb2ZpbmcgQUNLcy4gIFRvIHByZXZlbnQgc3VjaCBh biBhdHRhY2ssXG4gICBjb25zZW50IGNoZWNrcyBNVVNUIGJlIHBlcmZvcm1lZCBvdmVyIGFsbCB0 cmFuc3BvcnQgY29ubmVjdGlvbnMsXG4gICBpbmNsdWRpbmcgVENQLiAgSW4gdGhpcyB3YXksIGFu IG9mZi1wYXRoIGF0dGFja2VyIHNwb29maW5nIFRDUFxuICAgc2VnbWVudHMgY2FuIG5vdCBjYXVz ZSBhIFRDUCBzZW5kZXIgdG8gc2VuZCBvbmNlIHRoZSBjb25zZW50IHRpbWVyXG4gICBleHBpcmVz ICgzMCBzZWNvbmRzKS5cblxuICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkg YXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvXG4gICBtYWludGFpbiBjb25zZW50LiAg SG93ZXZlciwgZmFpbHVyZSB0byBzZW5kIGNvdWxkIGNhdXNlIGFueSBOQVQgb3JcbiAgIGZpcmV3 YWxsIG1hcHBpbmdzIGZvciB0aGUgZmxvdyB0byBleHBpcmUuICBGdXJ0aGVybW9yZSwgaGF2aW5n IG9uZVxuICAgcGVlciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3Rv Y29scy5cblxuICAgQWZ0ZXIgY29uc2VudCBpcyBsb3N0IGZvciBhbnkgcmVhc29uLCB0aGUgc2Ft ZSBJQ0UgY3JlZGVudGlhbHMgTVVTVFxuICAgTk9UIGJlIHVzZWQgb24gdGhlIGFmZmVjdGVkIDUt dHVwbGUgYWdhaW4uICBUaGF0IG1lYW5zIHRoYXQgYSBuZXdcbiAgIHNlc3Npb24sIG9yIGFuIElD RSByZXN0YXJ0LCBpcyBuZWVkZWQgdG8gb2J0YWluIGNvbnNlbnQgdG8gc2VuZC5cblxuNC4yLiAg SW1tZWRpYXRlIFJldm9jYXRpb24gb2YgQ29uc2VudFxuXG4gICBJbiBzb21lIGNhc2VzIGl0IGlz IHVzZWZ1bCB0byBzaWduYWwgdGhhdCBjb25zZW50IGlzIHRlcm1pbmF0ZWRcbiAgIHJhdGhlciB0 aGFuIHJlbHlpbmcgb24gYSB0aW1lb3V0LlxuXG4gICBDb25zZW50IGZvciBzZW5kaW5nIGFwcGxp Y2F0aW9uIGRhdGEgaXMgaW1tZWRpYXRlbHkgcmV2b2tlZCBieVxuICAgcmVjZWlwdCBvZiBhbiBh dXRoZW50aWNhdGVkIG1lc3NhZ2UgdGhhdCBjbG9zZXMgdGhlIGNvbm5lY3Rpb24gKGUuZy4sXG4g ICBhIFRMUyBmYXRhbCBhbGVydCkgb3IgcmVjZWlwdCBvZiBhIHZhbGlkIGFuZCBhdXRoZW50aWNh dGVkIFNUVU5cbiAgIHJlc3BvbnNlIHdpdGggZXJyb3IgY29kZSBGb3JiaWRkZW4gKDQwMykuICBO b3RlIGhvd2V2ZXIgdGhhdCBjb25zZW50XG4gICByZXZvY2F0aW9uIG1lc3NhZ2VzIGNhbiBiZSBs b3N0IG9uIHRoZSBuZXR3b3JrLCBzbyBhbiBlbmRwb2ludCBjb3VsZFxuICAgcmVzZW5kIHRoZXNl IG1lc3NhZ2VzLCBvciB3YWl0IGZvciBjb25zZW50IHRvIGV4cGlyZS5cblxuICAgUmVjZWlwdCBv ZiBhbiB1bmF1dGhlbnRpY2F0ZWQgbWVzc2FnZSB0aGF0IGNsb3NlcyBhIGNvbm5lY3Rpb24gKGUu Zy4sXG4gICBUQ1AgRklOKSBkb2VzIG5vdCBpbmRpY2F0ZSByZXZvY2F0aW9uIG9mIGNvbnNlbnQu ICBUaHVzLCBhbiBlbmRwb2ludFxuICAgcmVjZWl2aW5nIGFuIHVuYXV0aGVudGljYXRlZCBlbmQt b2Ytc2Vzc2lvbiBtZXNzYWdlIFNIT1VMRCBjb250aW51ZVxuICAgc2VuZGluZyBtZWRpYSAob3Zl ciBjb25uZWN0aW9ubGVzcyB0cmFuc3BvcnQpIG9yIGF0dGVtcHQgdG8gcmUtXG4gICBlc3RhYmxp c2ggdGhlIGNvbm5lY3Rpb24gKG92ZXIgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnQpIHVu dGlsXG4gICBjb25zZW50IGV4cGlyZXMgb3IgaXQgcmVjZWl2ZXMgYW4gYXV0aGVudGljYXRlZCBt ZXNzYWdlIHJldm9raW5nXG4gICBjb25zZW50LlxuXG4gICBOb3RlIHRoYXQgYW4gYXV0aGVudGlj YXRlZCBTUlRDUCBCWUUgZG9lcyBub3QgdGVybWluYXRlIGNvbnNlbnQ7IGl0XG4gICBvbmx5IGlu ZGljYXRlcyB0aGUgYXNzb2NpYXRlZCBTUlRQIHNvdXJjZSBoYXMgcXVpdC5cblxuXG5cblxuXG5c blxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEp1bmUgMjAsIDIwMTUgICAgICAg ICAgICAgICAgIFtQYWdlIDVdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9y IENvbnNlbnQgRnJlc2huZXNzICAgICAgIERlY2VtYmVyIDIwMTRcblxuXG41LiAgRGlmZlNlcnYg VHJlYXRtZW50IGZvciBDb25zZW50XG5cbiAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgU1RVTiBj b25zZW50IGNoZWNrcyB1c2UgdGhlIHNhbWUgRGlmZnNlcnZcbiAgIENvZGVwb2ludCBtYXJraW5n cyBhcyB0aGUgSUNFIGNvbm5lY3Rpdml0eSBjaGVja3MgZGVzY3JpYmVkIGluXG4gICBTZWN0aW9u IDcuMS4yLjQgb2YgW1JGQzUyNDVdIGZvciBhIGdpdmVuIDUtdHVwbGUuXG5cbiAgIE5vdGU6ICBJ dCBpcyBwb3NzaWJsZSB0aGF0IGRpZmZlcmVudCBEaWZmc2VydiBDb2RlcG9pbnRzIGFyZSB1c2Vk IGJ5XG4gICAgICBkaWZmZXJlbnQgbWVkaWEgb3ZlciB0aGUgc2FtZSB0cmFuc3BvcnQgYWRkcmVz c1xuICAgICAgW0ktRC5pZXRmLXRzdndnLXJ0Y3dlYi1xb3NdLiAgU3VjaCBhIGNhc2UgaXMgb3V0 c2lkZSB0aGUgc2NvcGUgb2ZcbiAgICAgIHRoaXMgZG9jdW1lbnQuXG5cbjYuICBEVExTIGFwcGxp Y2FiaWxpdHlcblxuICAgVGhlIERUTFMgYXBwbGljYWJpbGl0eSBpcyBpZGVudGljYWwgdG8gd2hh dCBpcyBkZXNjcmliZWQgaW5cbiAgIFNlY3Rpb24gNC4yIG9mIFtSRkM3MzUwXS5cblxuNy4gIEFQ SSBSZWNvbW1lbmRhdGlvbnNcblxuICAgVGhlIFczQyBzcGVjaWZpY2F0aW9uIE1BWSBwcm92aWRl IHRoZSBmb2xsb3dpbmcgQVBJIHBvaW50cyB0byBwcm92aWRlXG4gICBmZWVkYmFjayBhbmQgY29u dHJvbCBvdmVyIGNvbnNlbnQ6XG5cbiAgIDEuICBHZW5lcmF0ZSBhbiBldmVudCB3aGVuIGNvbnNl bnQgaGFzIGV4cGlyZWQgZm9yIGEgZ2l2ZW4gNS10dXBsZSxcbiAgICAgICBtZWFuaW5nIHRoYXQg dHJhbnNtaXNzaW9uIG9mIGRhdGEgaGFzIGNlYXNlZC4gIFRoaXMgY291bGRcbiAgICAgICBpbmRp Y2F0ZSB3aGF0IGFwcGxpY2F0aW9uIGRhdGEgaXMgYWZmZWN0ZWQsIHN1Y2ggYXMgbWVkaWEgb3Ig ZGF0YVxuICAgICAgIGNoYW5uZWxzLlxuXG44LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnNcblxu ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzZWN1cml0eSBtZWNoYW5pc20uXG5cbiAgIFRo ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNjdXNzZWQgaW4gW1JGQzUyNDVdIHNob3VsZCBh bHNvIGJlXG4gICB0YWtlbiBpbnRvIGFjY291bnQuXG5cbiAgIFNSVFAgaXMgZW5jcnlwdGVkIGFu ZCBhdXRoZW50aWNhdGVkIHdpdGggc3ltbWV0cmljIGtleXM7IHRoYXQgaXMsXG4gICBib3RoIHNl bmRlciBhbmQgcmVjZWl2ZXIga25vdyB0aGUga2V5cy4gIFdpdGggdHdvIHBhcnR5IHNlc3Npb25z LFxuICAgcmVjZWlwdCBvZiBhbiBhdXRoZW50aWNhdGVkIHBhY2tldCBmcm9tIHRoZSBzaW5nbGUg cmVtb3RlIHBhcnR5IGlzIGFcbiAgIHN0cm9uZyBhc3N1cmFuY2UgdGhlIHBhY2tldCBjYW1lIGZy b20gdGhhdCBwYXJ0eS4gIEhvd2V2ZXIsIHdoZW4gYVxuICAgc2Vzc2lvbiBpbnZvbHZlcyBtb3Jl IHRoYW4gdHdvIHBhcnRpZXMsIGFsbCBvZiB3aG9tIGtub3cgZWFjaCBvdGhlcnNcbiAgIGtleXMs IGFueSBvZiB0aG9zZSBwYXJ0aWVzIGNvdWxkIGhhdmUgc2VudCAob3Igc3Bvb2ZlZCkgdGhlIHBh Y2tldC5cbiAgIFN1Y2ggc2hhcmVkIGtleSBkaXN0cmlidXRpb25zIGFyZSBwb3NzaWJsZSB3aXRo IHNvbWUgTUlLRVkgW1JGQzM4MzBdXG4gICBtb2RlcywgU2VjdXJpdHkgRGVzY3JpcHRpb25zIFtS RkM0NTY4XSwgYW5kIEVLVFxuICAgW0ktRC5pZXRmLWF2dGNvcmUtc3J0cC1la3RdLiAgVGh1cywg aW4gc3VjaCBzaGFyZWQga2V5aW5nXG4gICBkaXN0cmlidXRpb25zLCByZWNlaXB0IG9mIGFuIGF1 dGhlbnRpY2F0ZWQgU1JUUCBwYWNrZXQgaXMgbm90XG4gICBzdWZmaWNpZW50IHRvIHZlcmlmeSBj b25zZW50LlxuXG5cblxuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMg SnVuZSAyMCwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgNl1cbl9cbkludGVybmV0LURyYWZ0 ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgRGVjZW1iZXIgMjAx NFxuXG5cbjkuICBJQU5BIENvbnNpZGVyYXRpb25zXG5cbiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBu b3QgcmVxdWlyZSBhbnkgYWN0aW9uIGZyb20gSUFOQS5cblxuMTAuICBBY2tub3dsZWRnZW1lbnRc blxuICAgVGhhbmtzIHRvIEVyaWMgUmVzY29ybGEsIEhhcmFsZCBBbHZlc3RyYW5kLCBCZXJuYXJk IEFib2JhLCBNYWdudXNcbiAgIFdlc3RlcmxhbmQsIEN1bGxlbiBKZW5uaW5ncywgQ2hyaXN0ZXIg SG9sbWJlcmcsIFNpbW9uIFBlcnJlYXVsdCwgUGF1bFxuICAgS3l6aXZhdCwgRW1pbCBJdm92LCBK b25hdGhhbiBMZW5ub3gsIEluYWtpIEJheiBDYXN0aWxsbywgUmFqbW9oYW5cbiAgIEJhbmF2aSBh bmQgQ2hyaXN0aWFuIEdyb3ZlcyBmb3IgdGhlaXIgdmFsdWFibGUgaW5wdXRzIGFuZCBjb21tZW50 cy5cbiAgIFRoYW5rcyB0byBDaHJpc3RlciBIb2xtYmVyZyBmb3IgZG9pbmcgYSB0aHJvdWdoIHJl dmlldy5cblxuMTEuICBSZWZlcmVuY2VzXG5cbjExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlc1xu XG4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0 byBJbmRpY2F0ZVxuICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJG QyAyMTE5LCBNYXJjaCAxOTk3LlxuXG4gICBbUkZDNDA4Nl0gIEVhc3RsYWtlLCBELiwgU2NoaWxs ZXIsIEouLCBhbmQgUy4gQ3JvY2tlciwgIlJhbmRvbW5lc3NcbiAgICAgICAgICAgICAgUmVxdWly ZW1lbnRzIGZvciBTZWN1cml0eSIsIEJDUCAxMDYsIFJGQyA0MDg2LCBKdW5lIDIwMDUuXG5cbiAg IFtSRkM1MjQ1XSAgUm9zZW5iZXJnLCBKLiwgIkludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3Rh Ymxpc2htZW50XG4gICAgICAgICAgICAgIChJQ0UpOiBBIFByb3RvY29sIGZvciBOZXR3b3JrIEFk ZHJlc3MgVHJhbnNsYXRvciAoTkFUKVxuICAgICAgICAgICAgICBUcmF2ZXJzYWwgZm9yIE9mZmVy L0Fuc3dlciBQcm90b2NvbHMiLCBSRkMgNTI0NSwgQXByaWxcbiAgICAgICAgICAgICAgMjAxMC5c blxuICAgW1JGQzYyNjNdICBNYXJqb3UsIFguIGFuZCBBLiBTb2xsYXVkLCAiQXBwbGljYXRpb24g TWVjaGFuaXNtIGZvclxuICAgICAgICAgICAgICBLZWVwaW5nIEFsaXZlIHRoZSBOQVQgTWFwcGlu Z3MgQXNzb2NpYXRlZCB3aXRoIFJUUCAvIFJUUFxuICAgICAgICAgICAgICBDb250cm9sIFByb3Rv Y29sIChSVENQKSBGbG93cyIsIFJGQyA2MjYzLCBKdW5lIDIwMTEuXG5cbjExLjIuICBJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzXG5cbiAgIFtJLUQuaWV0Zi1hdnRjb3JlLXNydHAtZWt0XVxuICAgICAg ICAgICAgICBNYXR0c3NvbiwgSi4sIE1jR3JldywgRC4sIGFuZCBELiBXaW5nLCAiRW5jcnlwdGVk IEtleVxuICAgICAgICAgICAgICBUcmFuc3BvcnQgZm9yIFNlY3VyZSBSVFAiLCBkcmFmdC1pZXRm LWF2dGNvcmUtc3J0cC1la3QtMDNcbiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBP Y3RvYmVyIDIwMTQuXG5cbiAgIFtJLUQuaWV0Zi1ydGN3ZWItb3ZlcnZpZXddXG4gICAgICAgICAg ICAgIEFsdmVzdHJhbmQsIEguLCAiT3ZlcnZpZXc6IFJlYWwgVGltZSBQcm90b2NvbHMgZm9yXG4g ICAgICAgICAgICAgIEJyb3dzZXItYmFzZWQgQXBwbGljYXRpb25zIiwgZHJhZnQtaWV0Zi1ydGN3 ZWItb3ZlcnZpZXctMTNcbiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBOb3ZlbWJl ciAyMDE0LlxuXG4gICBbSS1ELmlldGYtdHN2d2ctcnRjd2ViLXFvc11cbiAgICAgICAgICAgICAg RGhlc2lrYW4sIFMuLCBKZW5uaW5ncywgQy4sIERydXRhLCBELiwgSm9uZXMsIFAuLCBhbmQgSi5c biAgICAgICAgICAgICAgUG9saywgIkRTQ1AgYW5kIG90aGVyIHBhY2tldCBtYXJraW5ncyBmb3Ig UlRDV2ViIFFvUyIsXG4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0w MyAod29yayBpbiBwcm9ncmVzcyksXG4gICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTQuXG5cblxu XG5QZXJ1bWFsLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSnVuZSAyMCwgMjAxNSAgICAgICAg ICAgICAgICAgW1BhZ2UgN11cbl9cbkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3Ig Q29uc2VudCBGcmVzaG5lc3MgICAgICAgRGVjZW1iZXIgMjAxNFxuXG5cbiAgIFtSRkMzODMwXSAg QXJra28sIEouLCBDYXJyYXJhLCBFLiwgTGluZGhvbG0sIEYuLCBOYXNsdW5kLCBNLiwgYW5kIEsu XG4gICAgICAgICAgICAgIE5vcnJtYW4sICJNSUtFWTogTXVsdGltZWRpYSBJbnRlcm5ldCBLRVlp bmciLCBSRkMgMzgzMCxcbiAgICAgICAgICAgICAgQXVndXN0IDIwMDQuXG5cbiAgIFtSRkM0NTY4 XSAgQW5kcmVhc2VuLCBGLiwgQmF1Z2hlciwgTS4sIGFuZCBELiBXaW5nLCAiU2Vzc2lvblxuICAg ICAgICAgICAgICBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBTZWN1cml0eSBEZXNjcmlwdGlv bnMgZm9yIE1lZGlhXG4gICAgICAgICAgICAgIFN0cmVhbXMiLCBSRkMgNDU2OCwgSnVseSAyMDA2 LlxuXG4gICBbUkZDNDk1M10gIFRvdWNoLCBKLiwgIkRlZmVuZGluZyBUQ1AgQWdhaW5zdCBTcG9v ZmluZyBBdHRhY2tzIiwgUkZDXG4gICAgICAgICAgICAgIDQ5NTMsIEp1bHkgMjAwNy5cblxuICAg W1JGQzU5NjFdICBSYW1haWFoLCBBLiwgU3Rld2FydCwgUi4sIGFuZCBNLiBEYWxhbCwgIkltcHJv dmluZyBUQ1BcJ3NcbiAgICAgICAgICAgICAgUm9idXN0bmVzcyB0byBCbGluZCBJbi1XaW5kb3cg QXR0YWNrcyIsIFJGQyA1OTYxLCBBdWd1c3RcbiAgICAgICAgICAgICAgMjAxMC5cblxuICAgW1JG QzYwNjJdICBQZXJyZWF1bHQsIFMuIGFuZCBKLiBSb3NlbmJlcmcsICJUcmF2ZXJzYWwgVXNpbmcg UmVsYXlzXG4gICAgICAgICAgICAgIGFyb3VuZCBOQVQgKFRVUk4pIEV4dGVuc2lvbnMgZm9yIFRD UCBBbGxvY2F0aW9ucyIsIFJGQ1xuICAgICAgICAgICAgICA2MDYyLCBOb3ZlbWJlciAyMDEwLlxu XG4gICBbUkZDNzM1MF0gIFBldGl0LUh1Z3VlbmluLCBNLiBhbmQgRy4gU2FsZ3VlaXJvLCAiRGF0 YWdyYW0gVHJhbnNwb3J0XG4gICAgICAgICAgICAgIExheWVyIFNlY3VyaXR5IChEVExTKSBhcyBU cmFuc3BvcnQgZm9yIFNlc3Npb24gVHJhdmVyc2FsXG4gICAgICAgICAgICAgIFV0aWxpdGllcyBm b3IgTkFUIChTVFVOKSIsIFJGQyA3MzUwLCBBdWd1c3QgMjAxNC5cblxuQXV0aG9yc1wnIEFkZHJl c3Nlc1xuXG4gICBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWxcbiAgIEVyaWNzc29uXG4gICBGZXJu cyBJY29uXG4gICBEb2RkYW5la3VuZGksIE1haGFkZXZhcHVyYVxuICAgQmFuZ2Fsb3JlLCBLYXJu YXRha2EgIDU2MDAzN1xuICAgSW5kaWFcblxuICAgRW1haWw6IG11dGh1LmFydWxAZ21haWwuY29t XG5cblxuICAgRGFuIFdpbmdcbiAgIENpc2NvIFN5c3RlbXNcbiAgIDgyMSBBbGRlciBEcml2ZVxu ICAgTWlscGl0YXMsIENhbGlmb3JuaWEgIDk1MDM1XG4gICBVU0FcblxuICAgRW1haWw6IGR3aW5n QGNpc2NvLmNvbVxuXG5cblxuXG5cblxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgICBF eHBpcmVzIEp1bmUgMjAsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDhdXG5fXG5JbnRlcm5l dC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgIERlY2Vt YmVyIDIwMTRcblxuXG4gICBSYW0gTW9oYW4gUmF2aW5kcmFuYXRoXG4gICBDaXNjbyBTeXN0ZW1z XG4gICBDZXNzbmEgQnVzaW5lc3MgUGFya1xuICAgU2FyamFwdXItTWFyYXRoYWhhbGxpIE91dGVy IFJpbmcgUm9hZFxuICAgQmFuZ2Fsb3JlLCBLYXJuYXRha2EgIDU2MDEwM1xuICAgSW5kaWFcblxu ICAgRW1haWw6IHJtb2hhbnJAY2lzY28uY29tXG5cblxuICAgVGlydW1hbGVzd2FyIFJlZGR5XG4g ICBDaXNjbyBTeXN0ZW1zXG4gICBDZXNzbmEgQnVzaW5lc3MgUGFyaywgVmFydGh1ciBIb2JsaVxu ICAgU2FyamFwdXIgTWFyYXRoYWxsaSBPdXRlciBSaW5nIFJvYWRcbiAgIEJhbmdhbG9yZSwgS2Fy bmF0YWthICA1NjAxMDNcbiAgIEluZGlhXG5cbiAgIEVtYWlsOiB0aXJlZGR5QGNpc2NvLmNvbVxu XG5cbiAgIE1hcnRpbiBUaG9tc29uXG4gICBNb3ppbGxhXG4gICBTdWl0ZSAzMDBcbiAgIDY1MCBD YXN0cm8gU3RyZWV0XG4gICBNb3VudGFpbiBWaWV3LCBDYWxpZm9ybmlhICA5NDA0MVxuICAgVVNc blxuICAgRW1haWw6IG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbVxuXG5cblxuXG5cblxuXG5cblxu XG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblBlcnVtYWwsIGV0IGFsLiAgICAgICAgICAgRXhw aXJlcyBKdW5lIDIwLCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSA5XVxuJywgJ3VybDEnOiAn JywgJ3N1Ym1pdCc6ICdHZW5lcmF0ZSBkaWZmJywgJ3VybDInOiAnJywgJy0tbmV3Y29sb3VyJzog J2dyZWVuJ30gLS0+PC9ib2R5PjwvaHRtbD4= --_003_D16D00E62D555rmohanrciscocom_ Content-Type: text/plain; name="draft-ietf-rtcweb-stun-consent-freshness-12.txt" Content-Description: draft-ietf-rtcweb-stun-consent-freshness-12.txt Content-Disposition: attachment; filename="draft-ietf-rtcweb-stun-consent-freshness-12.txt"; size=18747; creation-date="Mon, 04 May 2015 05:27:10 GMT"; modification-date="Mon, 04 May 2015 05:27:10 GMT" Content-ID: <280F445FB6061D4BB916E80B08EB1885@emea.cisco.com> Content-Transfer-Encoding: base64 CgoKClJUQ1dFQiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTS4gUGVydW1hbApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBXaW5nCkV4cGly ZXM6IE5vdmVtYmVyIDQsIDIwMTUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIFJh dmluZHJhbmF0aAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVC4gUmVkZHkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gVGhvbXNv bgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE1vemlsbGEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE1heSAzLCAyMDE1CgoKICAgICAgICAgICAgICAgICAgICBT VFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcwogICAgICAgICAgICAgIGRyYWZ0LWlldGYt cnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTIKCkFic3RyYWN0CgogICBUbyBwcmV2ZW50 IHNlbmRpbmcgZXhjZXNzaXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNl bnQKICAgbmVlZHMgdG8gYmUgb2J0YWluZWQgZnJvbSB0aGF0IHJlbW90ZSBlbmRwb2ludC4KCiAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29uc2VudCBtZWNoYW5pc20gdXNpbmcgYSBuZXcg U2Vzc2lvbgogICBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pIHVzYWdlLgoKU3Rh dHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQ IDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0 IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCB3aWxsIGV4cGlyZSBvbiBOb3ZlbWJlciA0LCAyMDE1LgoKQ29weXJpZ2h0IE5vdGljZQoKICAg Q29weXJpZ2h0IChjKSAyMDE1IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQg YXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1 c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBw dWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVu dHMKCgoKUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciA0LCAyMDE1ICAg ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZv ciBDb25zZW50IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1CgoKICAgY2FyZWZ1bGx5LCBh cyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0 CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhp cyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9u cyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVkIGluIHRo ZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKVGFibGUgb2YgQ29udGVudHMKCiAgIDEuICBJbnRy b2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgMgogICAyLiAgVGVybWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgMy4gIERlc2lnbiBDb25zaWRlcmF0aW9ucyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDQuICBTb2x1dGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAg IDQuMS4gIEV4cGlyYXRpb24gb2YgQ29uc2VudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDMKICAgICA0LjIuICBJbW1lZGlhdGUgUmV2b2NhdGlvbiBvZiBDb25zZW50IC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1CiAgIDUuICBEaWZmU2VydiBUcmVhdG1lbnQgZm9y IENvbnNlbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA2LiAgRFRMUyBh cHBsaWNhYmlsaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDYKICAgNy4gIEFQSSBSZWNvbW1lbmRhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICA2CiAgIDguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgogICA5LiAgSUFOQSBDb25zaWRlcmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgMTAu IEFja25vd2xlZGdlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA3CiAgIDExLiBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgIDExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICAxMS4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3 CiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgOAoKMS4gIEludHJvZHVjdGlvbgoKICAgVG8gcHJldmVudCBhdHRhY2tz IG9uIHBlZXJzLCBlbmRwb2ludHMgaGF2ZSB0byBlbnN1cmUgdGhlIHJlbW90ZSBwZWVyCiAgIGlz IHdpbGxpbmcgdG8gcmVjZWl2ZSB0cmFmZmljLiAgVGhpcyBpcyBwZXJmb3JtZWQgYm90aCB3aGVu IHRoZQogICBzZXNzaW9uIGlzIGZpcnN0IGVzdGFibGlzaGVkIHRvIHRoZSByZW1vdGUgcGVlciB1 c2luZyBJbnRlcmFjdGl2ZQogICBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudCBJQ0UgW1JGQzUy NDVdIGNvbm5lY3Rpdml0eSBjaGVja3MsIGFuZAogICBwZXJpb2RpY2FsbHkgZm9yIHRoZSBkdXJh dGlvbiBvZiB0aGUgc2Vzc2lvbiB1c2luZyB0aGUgcHJvY2VkdXJlcwogICBkZWZpbmVkIGluIHRo aXMgZG9jdW1lbnQuCgogICBXaGVuIGEgc2Vzc2lvbiBpcyBmaXJzdCBlc3RhYmxpc2hlZCwgSUNF IGltcGxlbWVudGF0aW9ucyBvYnRhaW4gYW4KICAgaW5pdGlhbCBjb25zZW50IHRvIHNlbmQgYnkg cGVyZm9ybWluZyBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3MuICBUaGlzCiAgIGRvY3VtZW50IGRl c2NyaWJlcyBhIG5ldyBTVFVOIHVzYWdlIHdpdGggZXhjaGFuZ2Ugb2YgcmVxdWVzdCBhbmQKICAg cmVzcG9uc2UgbWVzc2FnZXMgdGhhdCB2ZXJpZmllcyB0aGUgcmVtb3RlIHBlZXIncyBvbmdvaW5n IGNvbnNlbnQgdG8KICAgcmVjZWl2ZSB0cmFmZmljLiAgVGhpcyBjb25zZW50IGV4cGlyZXMgYWZ0 ZXIgYSBwZXJpb2Qgb2YgdGltZSBhbmQKICAgbmVlZHMgdG8gYmUgY29udGludWFsbHkgcmVuZXdl ZCwgd2hpY2ggZW5zdXJlcyB0aGF0IGNvbnNlbnQgY2FuIGJlCiAgIHRlcm1pbmF0ZWQuCgogICBU aGlzIGRvY3VtZW50IGRlZmluZXMgd2hhdCBpdCB0YWtlcyB0byBvYnRhaW4sIG1haW50YWluLCBh bmQgbG9zZQogICBjb25zZW50IHRvIHNlbmQuICBDb25zZW50IHRvIHNlbmQgYXBwbGllcyB0byBh IHNpbmdsZSA1LXR1cGxlLiAgSG93CiAgIGFwcGxpY2F0aW9ucyByZWFjdCB0byBjaGFuZ2VzIGlu IGNvbnNlbnQgaXMgbm90IGRlc2NyaWJlZCBpbiB0aGlzCiAgIGRvY3VtZW50LgoKCgoKClBlcnVt YWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgNCwgMjAxNSAgICAgICAgICAgICAg ICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBG cmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNQoKCiAgIENvbnNlbnQgaXMgb2J0YWluZWQgb25s eSBieSBmdWxsIElDRSBpbXBsZW1lbnRhdGlvbnMuICBBbiBJQ0UtbGl0ZQogICBpbXBsZW1lbnRh dGlvbiB3aWxsIG5vdCBnZW5lcmF0ZSBjb25zZW50IGNoZWNrcywgYnV0IHdpbGwganVzdAogICBy ZXNwb25kIHRvIGNvbnNlbnQgY2hlY2tzIGl0IHJlY2VpdmVzLiAgTm8gY2hhbmdlcyBhcmUgcmVx dWlyZWQgdG8KICAgSUNFLWxpdGUgaW1wbGVtZW50YXRpb25zIGluIG9yZGVyIHRvIHJlc3BvbmQg dG8gY29uc2VudCBjaGVja3MsIGFzCiAgIHRoZXkgYXJlIHByb2Nlc3NlZCBhcyBub3JtYWwgSUNF IGNvbm5lY3Rpdml0eSBjaGVja3MuCgoyLiAgVGVybWlub2xvZ3kKCiAgIFRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAg IlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9O QUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJl ZCBpbiBbUkZDMjExOV0uCgogICBDb25zZW50OiAgVGhlIG1lY2hhbmlzbSBvZiBvYnRhaW5pbmcg cGVybWlzc2lvbiB0byBzZW5kIHRvIGEgcmVtb3RlCiAgICAgIHRyYW5zcG9ydCBhZGRyZXNzLiAg SW5pdGlhbCBjb25zZW50IGlzIG9idGFpbmVkIHVzaW5nIElDRS4KCiAgIENvbnNlbnQgRnJlc2hu ZXNzOiAgTWFpbnRhaW5pbmcgYW5kIHJlbmV3aW5nIGNvbnNlbnQgb3ZlciB0aW1lLgoKICAgVHJh bnNwb3J0IEFkZHJlc3M6ICBUaGUgcmVtb3RlIHBlZXIncyBJUCBhZGRyZXNzIGFuZCBVRFAgb3Ig VENQIHBvcnQKICAgICAgbnVtYmVyLgoKMy4gIERlc2lnbiBDb25zaWRlcmF0aW9ucwoKICAgQWx0 aG91Z2ggSUNFIHJlcXVpcmVzIHBlcmlvZGljIGtlZXBhbGl2ZSB0cmFmZmljIHRvIGtlZXAgTkFU IGJpbmRpbmdzCiAgIGFsaXZlIChTZWN0aW9uIDEwIG9mIFtSRkM1MjQ1XSwgW1JGQzYyNjNdKSwg dGhvc2Uga2VlcGFsaXZlcyBhcmUgc2VudAogICBhcyBTVFVOIEluZGljYXRpb25zIHdoaWNoIGFy ZSBzZW5kLWFuZC1mb3JnZXQsIGFuZCBkbyBub3QgZXZva2UgYQogICByZXNwb25zZS4gIEEgcmVz cG9uc2UgaXMgbmVjZXNzYXJ5IGZvciBjb25zZW50IHRvIGNvbnRpbnVlIHNlbmRpbmcKICAgdHJh ZmZpYy4gIFRodXMsIHdlIG5lZWQgYSByZXF1ZXN0L3Jlc3BvbnNlIG1lY2hhbmlzbSBmb3IgY29u c2VudAogICBmcmVzaG5lc3MuICBJQ0UgY2FuIGJlIHVzZWQgZm9yIHRoYXQgbWVjaGFuaXNtIGJl Y2F1c2UgSUNFCiAgIGltcGxlbWVudGF0aW9ucyBhcmUgYWxyZWFkeSByZXF1aXJlZCB0byBjb250 aW51ZSBsaXN0ZW5pbmcgZm9yIElDRQogICBtZXNzYWdlcywgYXMgZGVzY3JpYmVkIGluIHNlY3Rp b24gMTAgb2YgW1JGQzUyNDVdLiAgSWYgY29uc2VudCBpcwogICBwZXJmb3JtZWQgdGhlbiB0aGVy ZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLgoKNC4gIFNvbHV0aW9uCgog ICBUaGVyZSBhcmUgdHdvIHdheXMgY29uc2VudCB0byBzZW5kIHRyYWZmaWMgaXMgcmV2b2tlZDog ZXhwaXJhdGlvbiBvZgogICBjb25zZW50IGFuZCBpbW1lZGlhdGUgcmV2b2NhdGlvbiBvZiBjb25z ZW50LCB3aGljaCBhcmUgZGlzY3Vzc2VkIGluCiAgIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuCgo0 LjEuICBFeHBpcmF0aW9uIG9mIENvbnNlbnQKCiAgIEEgZnVsbCBJQ0UgaW1wbGVtZW50YXRpb24g cGVyZm9ybXMgY29uc2VudCBmcmVzaG5lc3MgdGVzdCB1c2luZyBTVFVOCiAgIHJlcXVlc3QvcmVz cG9uc2UgYXMgZGVzY3JpYmVkIGJlbG93OgoKICAgQW4gZW5kcG9pbnQgTVVTVCBOT1Qgc2VuZCBk YXRhIG90aGVyIHRoYW4gcGFjZWQgU1RVTiBjb25uZWN0aXZpdHkKICAgY2hlY2tzIG9yIHJlc3Bv bnNlcyB0b3dhcmQgYW55IHRyYW5zcG9ydCBhZGRyZXNzIHVubGVzcyB0aGUgcmVjZWl2aW5nCiAg IGVuZHBvaW50IGNvbnNlbnRzIHRvIHJlY2VpdmUgZGF0YS4gIFRoYXQgaXMsIG5vIGFwcGxpY2F0 aW9uIGRhdGEKICAgKGUuZy4sIFJUUCBvciBEVExTKSBjYW4gYmUgc2VudCB1bnRpbCBjb25zZW50 IGlzIG9idGFpbmVkLiAgQWZ0ZXIgYQogICBzdWNjZXNzZnVsIElDRSBjb25uZWN0aXZpdHkgY2hl Y2sgb24gYSBwYXJ0aWN1bGFyIHRyYW5zcG9ydCBhZGRyZXNzLAoKCgpQZXJ1bWFsLCBldCBhbC4g ICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgM10K DApJbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAg ICAgICAgICAgTWF5IDIwMTUKCgogICBjb25zZW50IE1VU1QgYmUgbWFpbnRhaW5lZCBmb2xsb3dp bmcgdGhlIHByb2NlZHVyZSBkZXNjcmliZWQgaW4gdGhpcwogICBkb2N1bWVudC4KCiAgIEV4cGxp Y2l0IGNvbnNlbnQgdG8gc2VuZCBpcyBvYnRhaW5lZCBhbmQgbWFpbnRhaW5lZCBieSBzZW5kaW5n IGFuCiAgIFNUVU4gYmluZGluZyByZXF1ZXN0IHRvIHRoZSByZW1vdGUgcGVlcidzIHRyYW5zcG9y dCBhZGRyZXNzIGFuZAogICByZWNlaXZpbmcgYSBtYXRjaGluZywgYXV0aGVudGljYXRlZCwgbm9u LWVycm9yIFNUVU4gYmluZGluZyByZXNwb25zZQogICBmcm9tIHRoZSByZW1vdGUgcGVlcidzIHRy YW5zcG9ydCBhZGRyZXNzLiAgVGhlc2UgU1RVTiBiaW5kaW5nCiAgIHJlcXVlc3RzIGFuZCByZXNw b25zZXMgYXJlIGF1dGhlbnRpY2F0ZWQgdXNpbmcgdGhlIHNhbWUgc2hvcnQtdGVybQogICBjcmVk ZW50aWFscyBhcyB0aGUgaW5pdGlhbCBJQ0UgZXhjaGFuZ2UuCgogICBOb3RlOiAgQWx0aG91Z2gg VENQIGhhcyBpdHMgb3duIGNvbnNlbnQgbWVjaGFuaXNtIChUQ1AKICAgICAgYWNrbm93bGVkZ2Vt ZW50cyksIGNvbnNlbnQgaXMgbmVjZXNzYXJ5IG92ZXIgYSBUQ1AgY29ubmVjdGlvbgogICAgICBi ZWNhdXNlIGl0IGNvdWxkIGJlIHRyYW5zbGF0ZWQgdG8gYSBVRFAgY29ubmVjdGlvbiAoZS5nLiwK ICAgICAgW1JGQzYwNjJdKS4KCiAgIEluaXRpYWwgY29uc2VudCB0byBzZW5kIHRyYWZmaWMgaXMg b2J0YWluZWQgdXNpbmcgSUNFLiAgQ29uc2VudAogICBleHBpcmVzIGFmdGVyIDMwIHNlY29uZHMu ICBUaGF0IGlzLCBpZiBhIHZhbGlkIFNUVU4gYmluZGluZyByZXNwb25zZQogICBjb3JyZXNwb25k aW5nIHRvIGFueSBTVFVOIHJlcXVlc3Qgc2VudCBpbiB0aGUgbGFzdCAzMCBzZWNvbmRzIGhhcyBu b3QKICAgYmVlbiByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUgcGVlcidzIHRyYW5zcG9ydCBhZGRy ZXNzLCB0aGUgZW5kcG9pbnQKICAgTVVTVCBjZWFzZSB0cmFuc21pc3Npb24gb24gdGhhdCA1LXR1 cGxlLiAgU1RVTiBjb25zZW50IHJlc3BvbnNlcwogICByZWNlaXZlZCBhZnRlciBjb25zZW50IGV4 cGlyeSBkbyBub3QgcmUtZXN0YWJsaXNoIGNvbnNlbnQsIGFuZCBtYXkgYmUKICAgZGlzY2FyZGVk IG9yIGNhdXNlIGFuIElDTVAgZXJyb3IuCgogICBUbyBwcmV2ZW50IGV4cGlyeSBvZiBjb25zZW50 LCBhIFNUVU4gYmluZGluZyByZXF1ZXN0IGNhbiBiZSBzZW50CiAgIHBlcmlvZGljYWxseS4gIFRv IHByZXZlbnQgc3luY2hyb25pemF0aW9uIG9mIGNvbnNlbnQgY2hlY2tzLCBlYWNoCiAgIGludGVy dmFsIE1VU1QgYmUgcmFuZG9taXplZCBmcm9tIGJldHdlZW4gMC44IGFuZCAxLjIgdGltZXMgdGhl IGJhc2ljCiAgIHBlcmlvZC4gIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgc2V0IGEgZGVmYXVsdCBp bnRlcnZhbCBvZiA1IHNlY29uZHMsCiAgIHJlc3VsdGluZyBpbiBhIHBlcmlvZCBiZXR3ZWVuIGNo ZWNrcyBvZiA0IHRvIDYgc2Vjb25kcy4KCiAgIEVhY2ggU1RVTiBiaW5kaW5nIHJlcXVlc3QgZm9y IGNvbnNlbnQgTVVTVCB1c2UgYSBuZXcKICAgY3J5cHRvZ3JhcGhpY2FsbHkgc3Ryb25nIFtSRkM0 MDg2XSBTVFVOIHRyYW5zYWN0aW9uIElELiAgRWFjaCBTVFVOCiAgIGJpbmRpbmcgcmVxdWVzdHMg Zm9yIGNvbnNlbnQgaXMgdHJhbnNtaXR0ZWQgb25jZSBvbmx5LiAgSGVuY2UsIHRoZQogICBzZW5k ZXIgY2Fubm90IGFzc3VtZSB0aGF0IGl0IHdpbGwgcmVjZWl2ZSBhIHJlc3BvbnNlIGZvciBlYWNo IGNvbnNlbnQKICAgcmVxdWVzdCwgYW5kIGEgcmVzcG9uc2UgbWlnaHQgYmUgZm9yIGEgcHJldmlv dXMgcmVxdWVzdCAocmF0aGVyIHRoYW4KICAgZm9yIHRoZSBtb3N0IHJlY2VudGx5IHNlbnQgcmVx dWVzdCkuICBDb25zZW50IGV4cGlyYXRpb24gY2F1c2VzCiAgIGltbWVkaWF0ZSB0ZXJtaW5hdGlv biBvZiBhbGwgb3V0c3RhbmRpbmcgU1RVTiBjb25zZW50IHRyYW5zYWN0aW9ucy4KICAgRWFjaCBT VFVOIHRyYW5zYWN0aW9uIGlzIG1haW50YWluZWQgdW50aWwgb25lIG9mIHRoZSBmb2xsb3dpbmcK ICAgY3JpdGVyaWEgaXMgZnVsZmlsbGVkOgoKICAgbyAgQSBTVFVOIHJlc3BvbnNlIGFzc29jaWF0 ZWQgd2l0aCB0aGUgdHJhbnNhY3Rpb24gaXMgcmVjZWl2ZWQ7IG9yCgogICBvICBBIFNUVU4gcmVz cG9uc2UgYXNzb2NpYXRlZCB0byBhIG5ld2VyIHRyYW5zYWN0aW9uIGlzIHJlY2VpdmVkLgoKICAg VG8gbWVldCB0aGUgc2VjdXJpdHkgbmVlZHMgb2YgY29uc2VudCwgYW4gdW50cnVzdGVkIGFwcGxp Y2F0aW9uCiAgIChlLmcuLCBKYXZhU2NyaXB0IG9yIHNpZ25hbGluZyBzZXJ2ZXJzKSBNVVNUIE5P VCBiZSBhYmxlIHRvIG9idGFpbiBvcgogICBjb250cm9sIHRoZSBTVFVOIHRyYW5zYWN0aW9uIElE LCBiZWNhdXNlIHRoYXQgZW5hYmxlcyBzcG9vZmluZyBvZgogICBTVFVOIHJlc3BvbnNlcywgZmFs c2lmeWluZyBjb25zZW50LgoKCgoKUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3Zl bWJlciA0LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1CgoK ICAgVG8gcHJldmVudCBhdHRhY2tzIG9uIHRoZSBwZWVyIGR1cmluZyBJQ0UgcmVzdGFydCwgYW4g ZW5kcG9pbnQgdGhhdAogICBjb250aW51ZXMgdG8gc2VuZCB0cmFmZmljIG9uIHRoZSBwcmV2aW91 c2x5IHZhbGlkYXRlZCBjYW5kaWRhdGUgcGFpcgogICBkdXJpbmcgSUNFIHJlc3RhcnQgTVVTVCBj b250aW51ZSB0byBwZXJmb3JtIGNvbnNlbnQgZnJlc2huZXNzIG9uIHRoYXQKICAgY2FuZGlkYXRl IHBhaXIgYXMgZGVzY3JpYmVkIGVhcmxpZXIuCgogICBXaGlsZSBUQ1AgYWZmb3JkcyBzb21lIHBy b3RlY3Rpb24gZnJvbSBvZmYtcGF0aCBhdHRhY2tlcnMgKFtSRkM1OTYxXSwKICAgW1JGQzQ5NTNd KSwgdGhlcmUgaXMgc3RpbGwgYSByaXNrIGFuIGF0dGFja2VyIGNvdWxkIGNhdXNlIGEgVENQCiAg IHNlbmRlciB0byBzZW5kIGZvcmV2ZXIgYnkgc3Bvb2ZpbmcgQUNLcy4gIFRvIHByZXZlbnQgc3Vj aCBhbiBhdHRhY2ssCiAgIGNvbnNlbnQgY2hlY2tzIE1VU1QgYmUgcGVyZm9ybWVkIG92ZXIgYWxs IHRyYW5zcG9ydCBjb25uZWN0aW9ucywKICAgaW5jbHVkaW5nIFRDUC4gIEluIHRoaXMgd2F5LCBh biBvZmYtcGF0aCBhdHRhY2tlciBzcG9vZmluZyBUQ1AKICAgc2VnbWVudHMgY2FuIG5vdCBjYXVz ZSBhIFRDUCBzZW5kZXIgdG8gc2VuZCBvbmNlIHRoZSBjb25zZW50IHRpbWVyCiAgIGV4cGlyZXMg KDMwIHNlY29uZHMpLgoKICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBw bGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvCiAgIG1haW50YWluIGNvbnNlbnQuICBIb3dl dmVyLCBmYWlsdXJlIHRvIHNlbmQgY291bGQgY2F1c2UgYW55IE5BVCBvcgogICBmaXJld2FsbCBt YXBwaW5ncyBmb3IgdGhlIGZsb3cgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZyBvbmUK ICAgcGVlciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy4g IEFic2VudCBiZXR0ZXIKICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5ldHdvcmssIGFuIGVuZHBv aW50IFNIT1VMRCBtYWludGFpbiBjb25zZW50IGlmCiAgIHRoZXJlIGlzIGFueSBwb3NzaWJpbGl0 eSB0aGF0IGEgZmxvdyBtaWdodCBiZSBuZWVkZWQgYWdhaW4uCgogICBBZnRlciBjb25zZW50IGlz IGxvc3QgZm9yIGFueSByZWFzb24sIHRoZSBzYW1lIElDRSBjcmVkZW50aWFscyBNVVNUCiAgIE5P VCBiZSB1c2VkIG9uIHRoZSBhZmZlY3RlZCA1LXR1cGxlIGFnYWluLiAgVGhhdCBtZWFucyB0aGF0 IGEgbmV3CiAgIHNlc3Npb24sIG9yIGFuIElDRSByZXN0YXJ0LCBpcyBuZWVkZWQgdG8gb2J0YWlu IGNvbnNlbnQgdG8gc2VuZC4KCjQuMi4gIEltbWVkaWF0ZSBSZXZvY2F0aW9uIG9mIENvbnNlbnQK CiAgIEluIHNvbWUgY2FzZXMgaXQgaXMgdXNlZnVsIHRvIHNpZ25hbCB0aGF0IGNvbnNlbnQgaXMg dGVybWluYXRlZAogICByYXRoZXIgdGhhbiByZWx5aW5nIG9uIGEgdGltZW91dC4KCiAgIENvbnNl bnQgZm9yIHNlbmRpbmcgYXBwbGljYXRpb24gZGF0YSBpcyBpbW1lZGlhdGVseSByZXZva2VkIGJ5 CiAgIHJlY2VpcHQgb2YgYW4gYXV0aGVudGljYXRlZCBtZXNzYWdlIHRoYXQgY2xvc2VzIHRoZSBj b25uZWN0aW9uIChlLmcuLAogICBhIFRMUyBmYXRhbCBhbGVydCkgb3IgcmVjZWlwdCBvZiBhIHZh bGlkIGFuZCBhdXRoZW50aWNhdGVkIFNUVU4KICAgcmVzcG9uc2Ugd2l0aCBlcnJvciBjb2RlIEZv cmJpZGRlbiAoNDAzKS4gIE5vdGUgaG93ZXZlciB0aGF0IGNvbnNlbnQKICAgcmV2b2NhdGlvbiBt ZXNzYWdlcyBjYW4gYmUgbG9zdCBvbiB0aGUgbmV0d29yaywgc28gYW4gZW5kcG9pbnQgY291bGQK ICAgcmVzZW5kIHRoZXNlIG1lc3NhZ2VzLCBvciB3YWl0IGZvciBjb25zZW50IHRvIGV4cGlyZS4K CiAgIFJlY2VpcHQgb2YgYW4gdW5hdXRoZW50aWNhdGVkIG1lc3NhZ2UgdGhhdCBjbG9zZXMgYSBj b25uZWN0aW9uIChlLmcuLAogICBUQ1AgRklOKSBkb2VzIG5vdCBpbmRpY2F0ZSByZXZvY2F0aW9u IG9mIGNvbnNlbnQuICBUaHVzLCBhbiBlbmRwb2ludAogICByZWNlaXZpbmcgYW4gdW5hdXRoZW50 aWNhdGVkIGVuZC1vZi1zZXNzaW9uIG1lc3NhZ2UgU0hPVUxEIGNvbnRpbnVlCiAgIHNlbmRpbmcg bWVkaWEgKG92ZXIgY29ubmVjdGlvbmxlc3MgdHJhbnNwb3J0KSBvciBhdHRlbXB0IHRvIHJlLQog ICBlc3RhYmxpc2ggdGhlIGNvbm5lY3Rpb24gKG92ZXIgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFu c3BvcnQpIHVudGlsCiAgIGNvbnNlbnQgZXhwaXJlcyBvciBpdCByZWNlaXZlcyBhbiBhdXRoZW50 aWNhdGVkIG1lc3NhZ2UgcmV2b2tpbmcKICAgY29uc2VudC4KCiAgIE5vdGUgdGhhdCBhbiBhdXRo ZW50aWNhdGVkIFNSVENQIEJZRSBkb2VzIG5vdCB0ZXJtaW5hdGUgY29uc2VudDsgaXQKICAgb25s eSBpbmRpY2F0ZXMgdGhlIGFzc29jaWF0ZWQgU1JUUCBzb3VyY2UgaGFzIHF1aXQuCgoKCgoKUGVy dW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciA0LCAyMDE1ICAgICAgICAgICAg ICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50 IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1CgoKNS4gIERpZmZTZXJ2IFRyZWF0bWVudCBm b3IgQ29uc2VudAoKICAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBTVFVOIGNvbnNlbnQgY2hlY2tz IHVzZSB0aGUgc2FtZSBEaWZmc2VydgogICBDb2RlcG9pbnQgbWFya2luZ3MgYXMgdGhlIElDRSBj b25uZWN0aXZpdHkgY2hlY2tzIGRlc2NyaWJlZCBpbgogICBTZWN0aW9uIDcuMS4yLjQgb2YgW1JG QzUyNDVdIGZvciBhIGdpdmVuIDUtdHVwbGUuCgogICBOb3RlOiAgSXQgaXMgcG9zc2libGUgdGhh dCBkaWZmZXJlbnQgRGlmZnNlcnYgQ29kZXBvaW50cyBhcmUgdXNlZCBieQogICAgICBkaWZmZXJl bnQgbWVkaWEgb3ZlciB0aGUgc2FtZSB0cmFuc3BvcnQgYWRkcmVzcwogICAgICBbSS1ELmlldGYt dHN2d2ctcnRjd2ViLXFvc10uICBTdWNoIGEgY2FzZSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZgog ICAgICB0aGlzIGRvY3VtZW50LgoKNi4gIERUTFMgYXBwbGljYWJpbGl0eQoKICAgVGhlIERUTFMg YXBwbGljYWJpbGl0eSBpcyBpZGVudGljYWwgdG8gd2hhdCBpcyBkZXNjcmliZWQgaW4KICAgU2Vj dGlvbiA0LjIgb2YgW1JGQzczNTBdLgoKNy4gIEFQSSBSZWNvbW1lbmRhdGlvbnMKCiAgIFRoZSBX M0Mgc3BlY2lmaWNhdGlvbiBbVzNDLVdFQlJUQ10gbWF5IHByb3ZpZGUgYW4gQVBJIGhvb2sgdGhh dAogICBnZW5lcmF0ZXMgYW4gZXZlbnQgd2hlbiBjb25zZW50IGhhcyBleHBpcmVkIGZvciBhIGdp dmVuIDUtdHVwbGUsCiAgIG1lYW5pbmcgdGhhdCB0cmFuc21pc3Npb24gb2YgZGF0YSBoYXMgY2Vh c2VkLiAgVGhpcyBjb3VsZCBpbmRpY2F0ZQogICB3aGF0IGFwcGxpY2F0aW9uIGRhdGEgaXMgYWZm ZWN0ZWQsIHN1Y2ggYXMgbWVkaWEgb3IgZGF0YSBjaGFubmVscy4KCjguICBTZWN1cml0eSBDb25z aWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzZWN1cml0eSBtZWNoYW5p c20uCgogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFtSRkM1MjQ1 XSBzaG91bGQgYWxzbyBiZQogICB0YWtlbiBpbnRvIGFjY291bnQuCgogICBTUlRQIGlzIGVuY3J5 cHRlZCBhbmQgYXV0aGVudGljYXRlZCB3aXRoIHN5bW1ldHJpYyBrZXlzOyB0aGF0IGlzLAogICBi b3RoIHNlbmRlciBhbmQgcmVjZWl2ZXIga25vdyB0aGUga2V5cy4gIFdpdGggdHdvIHBhcnR5IHNl c3Npb25zLAogICByZWNlaXB0IG9mIGFuIGF1dGhlbnRpY2F0ZWQgcGFja2V0IGZyb20gdGhlIHNp bmdsZSByZW1vdGUgcGFydHkgaXMgYQogICBzdHJvbmcgYXNzdXJhbmNlIHRoZSBwYWNrZXQgY2Ft ZSBmcm9tIHRoYXQgcGFydHkuICBIb3dldmVyLCB3aGVuIGEKICAgc2Vzc2lvbiBpbnZvbHZlcyBt b3JlIHRoYW4gdHdvIHBhcnRpZXMsIGFsbCBvZiB3aG9tIGtub3cgZWFjaCBvdGhlcnMKICAga2V5 cywgYW55IG9mIHRob3NlIHBhcnRpZXMgY291bGQgaGF2ZSBzZW50IChvciBzcG9vZmVkKSB0aGUg cGFja2V0LgogICBTdWNoIHNoYXJlZCBrZXkgZGlzdHJpYnV0aW9ucyBhcmUgcG9zc2libGUgd2l0 aCBzb21lIE1JS0VZIFtSRkMzODMwXQogICBtb2RlcywgU2VjdXJpdHkgRGVzY3JpcHRpb25zIFtS RkM0NTY4XSwgYW5kIEVLVAogICBbSS1ELmlldGYtYXZ0Y29yZS1zcnRwLWVrdF0uICBUaHVzLCBp biBzdWNoIHNoYXJlZCBrZXlpbmcKICAgZGlzdHJpYnV0aW9ucywgcmVjZWlwdCBvZiBhbiBhdXRo ZW50aWNhdGVkIFNSVFAgcGFja2V0IGlzIG5vdAogICBzdWZmaWNpZW50IHRvIHZlcmlmeSBjb25z ZW50LgoKOS4gIElBTkEgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3Qg cmVxdWlyZSBhbnkgYWN0aW9uIGZyb20gSUFOQS4KCgoKCgoKUGVydW1hbCwgZXQgYWwuICAgICAg ICAgRXhwaXJlcyBOb3ZlbWJlciA0LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAg ICAgIE1heSAyMDE1CgoKMTAuICBBY2tub3dsZWRnZW1lbnQKCiAgIFRoYW5rcyB0byBFcmljIFJl c2NvcmxhLCBIYXJhbGQgQWx2ZXN0cmFuZCwgQmVybmFyZCBBYm9iYSwgTWFnbnVzCiAgIFdlc3Rl cmxhbmQsIEN1bGxlbiBKZW5uaW5ncywgQ2hyaXN0ZXIgSG9sbWJlcmcsIFNpbW9uIFBlcnJlYXVs dCwgUGF1bAogICBLeXppdmF0LCBFbWlsIEl2b3YsIEpvbmF0aGFuIExlbm5veCwgSW5ha2kgQmF6 IENhc3RpbGxvLCBSYWptb2hhbgogICBCYW5hdmkgYW5kIENocmlzdGlhbiBHcm92ZXMgZm9yIHRo ZWlyIHZhbHVhYmxlIGlucHV0cyBhbmQgY29tbWVudHMuCiAgIFRoYW5rcyB0byBDaHJpc3RlciBI b2xtYmVyZyBmb3IgZG9pbmcgYSB0aHJvdWdoIHJldmlldy4KCjExLiAgUmVmZXJlbmNlcwoKMTEu MS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5 IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVt ZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuCgogICBbUkZDNDA4Nl0g IEVhc3RsYWtlLCBELiwgU2NoaWxsZXIsIEouLCBhbmQgUy4gQ3JvY2tlciwgIlJhbmRvbW5lc3MK ICAgICAgICAgICAgICBSZXF1aXJlbWVudHMgZm9yIFNlY3VyaXR5IiwgQkNQIDEwNiwgUkZDIDQw ODYsIEp1bmUgMjAwNS4KCiAgIFtSRkM1MjQ1XSAgUm9zZW5iZXJnLCBKLiwgIkludGVyYWN0aXZl IENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50CiAgICAgICAgICAgICAgKElDRSk6IEEgUHJvdG9j b2wgZm9yIE5ldHdvcmsgQWRkcmVzcyBUcmFuc2xhdG9yIChOQVQpCiAgICAgICAgICAgICAgVHJh dmVyc2FsIGZvciBPZmZlci9BbnN3ZXIgUHJvdG9jb2xzIiwgUkZDIDUyNDUsIEFwcmlsCiAgICAg ICAgICAgICAgMjAxMC4KCiAgIFtSRkM2MjYzXSAgTWFyam91LCBYLiBhbmQgQS4gU29sbGF1ZCwg IkFwcGxpY2F0aW9uIE1lY2hhbmlzbSBmb3IKICAgICAgICAgICAgICBLZWVwaW5nIEFsaXZlIHRo ZSBOQVQgTWFwcGluZ3MgQXNzb2NpYXRlZCB3aXRoIFJUUCAvIFJUUAogICAgICAgICAgICAgIENv bnRyb2wgUHJvdG9jb2wgKFJUQ1ApIEZsb3dzIiwgUkZDIDYyNjMsIEp1bmUgMjAxMS4KCjExLjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELmlldGYtYXZ0Y29yZS1zcnRwLWVrdF0K ICAgICAgICAgICAgICBNYXR0c3NvbiwgSi4sIE1jR3JldywgRC4sIGFuZCBELiBXaW5nLCAiRW5j cnlwdGVkIEtleQogICAgICAgICAgICAgIFRyYW5zcG9ydCBmb3IgU2VjdXJlIFJUUCIsIGRyYWZ0 LWlldGYtYXZ0Y29yZS1zcnRwLWVrdC0wMwogICAgICAgICAgICAgICh3b3JrIGluIHByb2dyZXNz KSwgT2N0b2JlciAyMDE0LgoKICAgW0ktRC5pZXRmLXJ0Y3dlYi1vdmVydmlld10KICAgICAgICAg ICAgICBBbHZlc3RyYW5kLCBILiwgIk92ZXJ2aWV3OiBSZWFsIFRpbWUgUHJvdG9jb2xzIGZvcgog ICAgICAgICAgICAgIEJyb3dzZXItYmFzZWQgQXBwbGljYXRpb25zIiwgZHJhZnQtaWV0Zi1ydGN3 ZWItb3ZlcnZpZXctMTMKICAgICAgICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIE5vdmVtYmVy IDIwMTQuCgogICBbSS1ELmlldGYtdHN2d2ctcnRjd2ViLXFvc10KICAgICAgICAgICAgICBEaGVz aWthbiwgUy4sIEplbm5pbmdzLCBDLiwgRHJ1dGEsIEQuLCBKb25lcywgUC4sIGFuZCBKLgogICAg ICAgICAgICAgIFBvbGssICJEU0NQIGFuZCBvdGhlciBwYWNrZXQgbWFya2luZ3MgZm9yIFJUQ1dl YiBRb1MiLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0wMyAod29y ayBpbiBwcm9ncmVzcyksCiAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxNC4KCiAgIFtSRkMzODMw XSAgQXJra28sIEouLCBDYXJyYXJhLCBFLiwgTGluZGhvbG0sIEYuLCBOYXNsdW5kLCBNLiwgYW5k IEsuCiAgICAgICAgICAgICAgTm9ycm1hbiwgIk1JS0VZOiBNdWx0aW1lZGlhIEludGVybmV0IEtF WWluZyIsIFJGQyAzODMwLAogICAgICAgICAgICAgIEF1Z3VzdCAyMDA0LgoKCgpQZXJ1bWFsLCBl dCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIwMTUgICAgICAgICAgICAgICAgW1Bh Z2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2hu ZXNzICAgICAgICAgICAgTWF5IDIwMTUKCgogICBbUkZDNDU2OF0gIEFuZHJlYXNlbiwgRi4sIEJh dWdoZXIsIE0uLCBhbmQgRC4gV2luZywgIlNlc3Npb24KICAgICAgICAgICAgICBEZXNjcmlwdGlv biBQcm90b2NvbCAoU0RQKSBTZWN1cml0eSBEZXNjcmlwdGlvbnMgZm9yIE1lZGlhCiAgICAgICAg ICAgICAgU3RyZWFtcyIsIFJGQyA0NTY4LCBKdWx5IDIwMDYuCgogICBbUkZDNDk1M10gIFRvdWNo LCBKLiwgIkRlZmVuZGluZyBUQ1AgQWdhaW5zdCBTcG9vZmluZyBBdHRhY2tzIiwgUkZDCiAgICAg ICAgICAgICAgNDk1MywgSnVseSAyMDA3LgoKICAgW1JGQzU5NjFdICBSYW1haWFoLCBBLiwgU3Rl d2FydCwgUi4sIGFuZCBNLiBEYWxhbCwgIkltcHJvdmluZyBUQ1AncwogICAgICAgICAgICAgIFJv YnVzdG5lc3MgdG8gQmxpbmQgSW4tV2luZG93IEF0dGFja3MiLCBSRkMgNTk2MSwgQXVndXN0CiAg ICAgICAgICAgICAgMjAxMC4KCiAgIFtSRkM2MDYyXSAgUGVycmVhdWx0LCBTLiBhbmQgSi4gUm9z ZW5iZXJnLCAiVHJhdmVyc2FsIFVzaW5nIFJlbGF5cwogICAgICAgICAgICAgIGFyb3VuZCBOQVQg KFRVUk4pIEV4dGVuc2lvbnMgZm9yIFRDUCBBbGxvY2F0aW9ucyIsIFJGQwogICAgICAgICAgICAg IDYwNjIsIE5vdmVtYmVyIDIwMTAuCgogICBbUkZDNzM1MF0gIFBldGl0LUh1Z3VlbmluLCBNLiBh bmQgRy4gU2FsZ3VlaXJvLCAiRGF0YWdyYW0gVHJhbnNwb3J0CiAgICAgICAgICAgICAgTGF5ZXIg U2VjdXJpdHkgKERUTFMpIGFzIFRyYW5zcG9ydCBmb3IgU2Vzc2lvbiBUcmF2ZXJzYWwKICAgICAg ICAgICAgICBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikiLCBSRkMgNzM1MCwgQXVndXN0IDIwMTQu CgogICBbVzNDLVdFQlJUQ10KICAgICAgICAgICAgICBCZXJna3Zpc3QsIEEuLCBCdXJuZXR0LCBE LiwgTmFyYXlhbmFuLCBBLiwgYW5kIEMuCiAgICAgICAgICAgICAgSmVubmluZ3MsICJXZWJSVEMg MS4wOiBSZWFsLXRpbWUgQ29tbXVuaWNhdGlvbiBCZXR3ZWVuCiAgICAgICAgICAgICAgQnJvd3Nl cnMiLCBmZWJydWFyeSAyMDE1LgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBNdXRodSBBcnVsIE1v emhpIFBlcnVtYWwKICAgRXJpY3Nzb24KICAgRmVybnMgSWNvbgogICBEb2RkYW5la3VuZGksIE1h aGFkZXZhcHVyYQogICBCYW5nYWxvcmUsIEthcm5hdGFrYSAgNTYwMDM3CiAgIEluZGlhCgogICBF bWFpbDogbXV0aHUuYXJ1bEBnbWFpbC5jb20KCgogICBEYW4gV2luZwogICBDaXNjbyBTeXN0ZW1z CiAgIDgyMSBBbGRlciBEcml2ZQogICBNaWxwaXRhcywgQ2FsaWZvcm5pYSAgOTUwMzUKICAgVVNB CgogICBFbWFpbDogZHdpbmdAY2lzY28uY29tCgoKCgoKCgoKUGVydW1hbCwgZXQgYWwuICAgICAg ICAgRXhwaXJlcyBOb3ZlbWJlciA0LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAg ICAgIE1heSAyMDE1CgoKICAgUmFtIE1vaGFuIFJhdmluZHJhbmF0aAogICBDaXNjbyBTeXN0ZW1z CiAgIENlc3NuYSBCdXNpbmVzcyBQYXJrCiAgIFNhcmphcHVyLU1hcmF0aGFoYWxsaSBPdXRlciBS aW5nIFJvYWQKICAgQmFuZ2Fsb3JlLCBLYXJuYXRha2EgIDU2MDEwMwogICBJbmRpYQoKICAgRW1h aWw6IHJtb2hhbnJAY2lzY28uY29tCgoKICAgVGlydW1hbGVzd2FyIFJlZGR5CiAgIENpc2NvIFN5 c3RlbXMKICAgQ2Vzc25hIEJ1c2luZXNzIFBhcmssIFZhcnRodXIgSG9ibGkKICAgU2FyamFwdXIg TWFyYXRoYWxsaSBPdXRlciBSaW5nIFJvYWQKICAgQmFuZ2Fsb3JlLCBLYXJuYXRha2EgIDU2MDEw MwogICBJbmRpYQoKICAgRW1haWw6IHRpcmVkZHlAY2lzY28uY29tCgoKICAgTWFydGluIFRob21z b24KICAgTW96aWxsYQogICBTdWl0ZSAzMDAKICAgNjUwIENhc3RybyBTdHJlZXQKICAgTW91bnRh aW4gVmlldywgQ2FsaWZvcm5pYSAgOTQwNDEKICAgVVMKCiAgIEVtYWlsOiBtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpQZXJ1bWFsLCBldCBhbC4gICAgICAg ICBFeHBpcmVzIE5vdmVtYmVyIDQsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgOV0K --_003_D16D00E62D555rmohanrciscocom_-- From nobody Mon May 4 04:51: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 AE8751ACE48 for ; Mon, 4 May 2015 04:51: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 mhph6vhVFVQ5 for ; Mon, 4 May 2015 04:51:32 -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 649771ACE3F for ; Mon, 4 May 2015 04:51:32 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-4c-55475d42fd03 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 97.BF.28096.24D57455; Mon, 4 May 2015 13:51:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Mon, 4 May 2015 13:51:30 +0200 Message-ID: <55475D41.6020708@ericsson.com> Date: Mon, 4 May 2015 13:51:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Emil Ivov , John Leslie References: <7978938E-B510-43E2-9F19-C4752F6D23FD@cisco.com> <55361B07.3010707@ericsson.com> <5537948F.6040007@ericsson.com> <20150422152908.GF63465@verdi> <5538EFE9.7040200@ericsson.com> <20150423134742.GI63465@verdi> <553A2BFE.4050904@ericsson.com> <553CF2E4.7000700@jitsi.org> In-Reply-To: <553CF2E4.7000700@jitsi.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvja5TrHuowYJduhZrdk5gsXh/4Tyj xdp/7ewOzB5Llvxk8vj/JtDj2NzDzAHMUVw2Kak5mWWpRfp2CVwZR272shTsV664fuQ/ewPj dJkuRk4OCQETie5ZG1ghbDGJC/fWs3UxcnEICRxllDj5ZgIzhLOMUWLOrr9gVbwC2hJNx04y g9gsAioS3SduM4LYbAIWEjd/NLKB2KICURITvx5igagXlDg58wmYLSJgLfG+ezfYHGYBUYlX D6eAzREW8JVo2PSFHWLZBxaJZxfmsoMkOAU0JVZsfwQ0lAOowV7iwdYyiF55ieats8F6hYDu aWjqYJ3AKDgLybpZCB2zkHQsYGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYwAe3/Lba wXjwueMhRgEORiUe3gWX3EKFWBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cCoFbnw9tc7MwutW/S2n1rBbpMeEhY9N3SLDvf+F7d6rh40Lb9eu+FEc3dv813O uEu8Gu0tX9JunUg+zpZau37aZqk7+8zPn2//8ZKH9cB93wWr/vv8WD/pW8+aBzmscqffGMZ/ dUnhnDJ9YeuTjornkhqSZQp1/2db3eEXDTvDUnbZvbuZY+MSJZbijERDLeai4kQAhbuXhkEC AAA= Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 11:51:34 -0000 Emil Ivov skrev den 2015-04-26 16:15: > On 24.04.15 14:41, Magnus Westerlund wrote: >> John Leslie skrev den 2015-04-23 15:47: >>> Magnus Westerlund wrote: >>>> But we do need mechanism to protect the network. Especially when the >>>> network doesn't work as intended that do happens from time to time. > > You shouldn't consider FEC as something that is only used as a reaction > to congestion. Audio codecs such as Opus and Silk allow for inband FEC > and most apps that I am aware of do turn it on unconditionally prior to > every call. No, it is put in there in reaction to loss. Some networks produce almost no loss, some a bit-more. I think it is totally appropriate to use FEC to combat that loss, as long as the total bandwidth control is such that it doesn't increase the congestion level, and thus the loss rates. From that I draw the conclusion that you need to have bit-rate adaptation and in cases where FEC is enabled, then it is the total bandwidth usage that counts, i.e. Media + FEC. Thus, if one adds or retunes the FEC application to consume more bits, then the media-bits needs to be reduced to fit within the available bandwidth. > >> In my opinion a circuit breaker that triggers for a sustained packet >> loss rate of 20% over a time period of seconds, is in fact doing its >> jobb. > > This is where I disagree. In many cases sustained 20% packet loss is > something that inband FEC would fix. I am fine that you apply FEC to fix 20% loss, but really sustained 20% packet loss means that the network is congested, and the bandwidth consumed needs to be reduced, by all parties. > > How many users do you think would be happy in such situations when given > the explanation that: we could have made your call work but it really > makes us look bad to mess with such crappy networks. Here I totally disagree with you. If you are self-congesting your application, then your own failure to reduce the bit-rate in response to the congestion, is what causing the issue. If you are competing with other flows, and several has your approach, then you all makes it impossible to adjust to a sensible working point. You are helping ensure a broken network usage. As I see it, the browsers/ webRTC endpoints will need to be the guardians here. They can't let the JS applications do whatever they want to the network. > >> If there is a short duration, like 400 ms with that loss rate and >> then it otherwise drops down below 5% for the next 5 seconds and this >> flow is in the region of 30-50 kbps in total, then I think that is fine. >> All based on my judgement. I haven't, but believe that if you run this >> case through the circuit breaker, you might get away with it. It is the >> TCP equation based breaker that is the one that will fire here if any. >> So it depends on the RTT and how many loss events this corresponds with. >> >> >>> >>> "Circuit-breaker" is not a terribly effective way to do that -- >>> especially when the WebRTC application can simply start another call. >> >> Well, to automatically restart/create a new PC when the circuit breakers >> has triggered is not in the spirit of things. The spirit of things is to >> adjust your parameter settings so that it consumes less bandwidth, then >> start it again, or simply let the session be, unless the human user >> insists. > > Your "spirit of things" does not necessarily coincide with that of the > application/service providers and users. But, this comes back to that the network is a shared resource, if you missuses it, then it becomes destroyed. This is a Tragedy of the commons case. > > Also, given that users will be allowed to insist, what exactly have we > done to resolve congestion? you are right, the use should not be allowed to insist, if the application can't adjust down its bandwidth consumption. If it can adjust it down with a significant factor, then I am fine with it restarting. 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 May 4 21:18: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 6F3A11A9062; Mon, 4 May 2015 21:18:15 -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 mZ8iunNq_K3G; Mon, 4 May 2015 21:18:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6571A90BA; Mon, 4 May 2015 21:18:12 -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.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150505041812.3096.98257.idtracker@ietfa.amsl.com> Date: Mon, 04 May 2015 21:18:12 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-12.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, 05 May 2015 04:18:15 -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-12.txt Pages : 9 Date : 2015-05-04 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new 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-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-12 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 May 4 22:29: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 32BBD1B2E37 for ; Mon, 4 May 2015 22:29:36 -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 XOoCAGD2j-3E for ; Mon, 4 May 2015 22:29:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416661B2E36 for ; Mon, 4 May 2015 22:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1430803774; x=1432013374; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z90Y+tQQeIykBeP0DMdFPFKsdMvjSEaKMO5Pv2myLQU=; b=PWH1jbq0yn/hT3grhKAkg7ydXYFNlovxiTngVzIf3zlK592bH/Fqsldl WCdPKzNe8q1wcluXMkWy6vxtsJ2UDGblX3suPuhF0pPLA1kWGsjKK3qGn /qlygQKBHs+LXumyKVQ5DMyxTrb2pT22YljJVOJe+Y3YTPkC1B+5B/oBw Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AOBQB8VEhV/5BdJa1cgwxTXAXHSQyFNU4CgThMAQEBAQEBgQuEIAEBAQQBAQE3NBcEAgEIEQMBAh8QJwsdCAIEE4grDcYnAQEBAQEBAQMBAQEBAQEBARqLOYRSOgaEJwWSDYQRhkGBJD2DFZEoI4N0b4FEgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,370,1427760000"; d="scan'208";a="413964017" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 05 May 2015 05:29:33 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t455TX26006558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 May 2015 05:29:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.61]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 5 May 2015 00:29:33 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-12.txt Thread-Index: AQHQhvR3cQm9upqvmUq75wQO+fNw3w== Date: Tue, 5 May 2015 05:29:32 +0000 Message-ID: References: <20150505041812.3096.98257.idtracker@ietfa.amsl.com> In-Reply-To: <20150505041812.3096.98257.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.241] Content-Type: text/plain; charset="us-ascii" Content-ID: <5A518D7BCEE1C24884AD6E00569C777C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-12.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, 05 May 2015 05:29:36 -0000 This version addresses the comments given by Alissa. Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Tuesday, 5 May 2015 9:48 am To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-12.txt > >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-12.txt > Pages : 9 > Date : 2015-05-04 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new 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-12 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne= ss >-12 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue May 5 23:53: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 37E031A7D80 for ; Tue, 5 May 2015 23:53:36 -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 7Ivk8Yjihrrj for ; Tue, 5 May 2015 23:53:34 -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 9FEF71A7028 for ; Tue, 5 May 2015 23:53:33 -0700 (PDT) X-AuditID: c1b4fb30-f798d6d0000009ec-c2-5549ba6b8dc3 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 34.D2.02540.B6AB9455; Wed, 6 May 2015 08:53:31 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Wed, 6 May 2015 08:53:30 +0200 From: Christer Holmberg To: Alissa Cooper , Martin Thomson Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQg6ZCX3ABhhDJOU+APBu3+BbmbJ1nNjYAgABrhwCABulYUA== Date: Wed, 6 May 2015 06:53:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> In-Reply-To: <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW72Ls9Qg08vNC2mn/nLaHHtzD9G i7X/2tkdmD2+PHnJ5LFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZTT132ctaOWt2PNhAWsD 40muLkZODgkBE4mGxzNYIGwxiQv31rN1MXJxCAkcZZQ4tH47E4SziFHi4/N7QFUcHGwCFhLd /7RBGkQEgiSu9M9nArGZBdQl7iw+xw5SIgwUX32GF6IkWGLzjlcsELaTxKpTqxlBbBYBFYk9 E7aB2bwCvhLzf++H2ruDUWLzos9gCU4BO4nTH/+wgdiMQMd9P7UGape4xK0nEHslBAQkluw5 zwxhi0q8fPyPFcJWlLg6fTlUvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJ yywkLQsYWVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbUwS2/DXYwvnzueIhRgINRiYd3 QalnqBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGEOb3zvd nHG07d/5GUevrC7cnjWphOn63olBqtvrc27Hy0bz6y8MS7zmsq20rnbqnxN8pzbsD1DvUS5/ /F6XhV1nZTrn/j2+rjH5CikpgS82PS/Ki9Gs/s/4vuZ9ovRMw+dmP5eJ3ys7v4z34szI+Fcc 1lcEGsxfbQvqrFl8aLXPzNKdMyNCWpVYijMSDbWYi4oTARhC9oOKAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 06:53:36 -0000 Hi, I don't think you need to continue doing consent because of NAT issues, if = you are sending normal STUN keep-alives. Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa Cooper Sent: 2. toukokuuta 2015 2:20 To: Martin Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshne= ss-11 On May 1, 2015, at 9:54 AM, Martin Thomson wrote= : > On 30 April 2015 at 17:32, Alissa Cooper wrote: >> "An endpoint that is not sending any application data does not need to >> maintain consent. However, failure to send could cause any NAT or >> firewall mappings for the flow to expire. Furthermore, having one >> peer unable to send is detrimental to many protocols." >>=20 >> It sounds like the unstated implication here is that if you are such an = endpoint, you should keep doing consent checks anyway to maintain consent. = Should that be stated explicitly, or am I misunderstanding? >=20 > Can you tell that this is my text? >=20 > Yep, the unspoken implication is that if you stop maintaining consent,=20 > a flow is highly likely to break. I'm OK with making that explicit. >=20 > ... . Absent better information about the network, an endpoint SHOULD=20 > maintain consent if there is any possibility that a flow might be=20 > needed again. WFM >=20 > (Thanks for the suggestion on Sec7. I wasn't happy with it before.) _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 6 02:53: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 E92341A7014 for ; Wed, 6 May 2015 02:53:09 -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 bHa219-9Mm5P for ; Wed, 6 May 2015 02:53:07 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 608531A01F9 for ; Wed, 6 May 2015 02:53:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9249B7C4111 for ; Wed, 6 May 2015 11:53:06 +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 6IuDTgYlJ1br for ; Wed, 6 May 2015 11:53:05 +0200 (CEST) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:a183:4e00:d5f4:a58c]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4C9477C410E for ; Wed, 6 May 2015 11:53:05 +0200 (CEST) Message-ID: <5549E480.4030806@alvestrand.no> Date: Wed, 06 May 2015 11:53:04 +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" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 09:53:10 -0000 security-arch-11 contains the following text: All implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite. Implementations SHOULD favor cipher suites which support PFS over non-PFS cipher suites and GCM over CBC cipher suites. [[OPEN ISSUE: Should we require ECDSA? Waiting for WG Consensus.]] security-arch-10 contained the following text in the same spot: All implementations MUST implement both DTLS 1.2 and DTLS 1.0, with the cipher suites TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_128_CBC_SHA and the DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80. Implementations SHOULD favor cipher suites which support PFS over non-PFS cipher suites and GCM over CBC cipher suites. [[OPEN ISSUE: Should we require ECDHE? Waiting for TLS WG Consensus.]] So it seems that consensus has shifted from MUST for DHE_RSA to MUST for ECDHE_RSA (presumably based on a TLS WG consensus), with some arguing for inclusion of ECDSA in the mandatory ciphersuites, and has landed on DTLS 1.0 only being mandatory. I tried to find the discussion in the archives, but failed - which makes it hard to have an opionion of where consensus is heading; there is a February note from Martin that's relevant, but that's all I found. Minutes from last meetings are here: https://tools.ietf.org/wg/rtcweb/minutes?item=minutes-92-rtcweb.html https://tools.ietf.org/wg/rtcweb/minutes?item=minutes-91-rtcweb.html I couldn't find anything relevant there either. Do we have an idea on how to move forward with resolving the outstanding question? (the trigger for the question is a colleague looking into the crypto code for our implementation; he would prefer to spend his time making sure the stuff we specify as mandatory works well.) Harald From nobody Wed May 6 08:33: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 A175A1AD186 for ; Wed, 6 May 2015 08:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, 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 zYqTlyjhIIpZ for ; Wed, 6 May 2015 08:33:02 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.31.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CDF1AD0C3 for ; Wed, 6 May 2015 08:33:02 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 8F7AD7093EB1; Wed, 6 May 2015 10:33:01 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 7DE4B7093DE8 for ; Wed, 6 May 2015 10:33:01 -0500 (CDT) Received: from [173.73.121.66] (port=56642 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yq1Jk-0000FK-Sv; Wed, 06 May 2015 10:33:00 -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: Date: Wed, 6 May 2015 11:32:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <48505E93-5BBE-4126-8F82-3452F605E717@ieca.com> References: To: rtcweb@ietf.org, draft-alvestrand-rtcweb-gateways@tools.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: 173.73.121.66 X-Exim-ID: 1Yq1Jk-0000FK-Sv X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [173.73.121.66]:56642 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [rtcweb] WG call for adoption: draft-alvestrand-rtcweb-gateways X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 15:33:07 -0000 All, Based on messages to the list from this thread and the thread in = December we=92re going to adopt this draft as a WG item. Authors, Please submit a WG version of the draft when you get a chance. spt On Apr 16, 2015, at 14:15, Sean Turner wrote: > All, >=20 > There=92s been some interest expressed in having = http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-gateways/ = adopted as an RTCWeb WG item. Please respond to say whether you support = adoption of this work as a working group work item and whether you will = participate in the discussion. If you are opposed to this draft = becoming a WG document, please say so (and say why). Please have your = response in by 20150423 23:59 UTC. >=20 > Thanks in advance! >=20 > spt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 6 08:33: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 EC9081AD2C0 for ; Wed, 6 May 2015 08:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, 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 s8c9c2JkqtIa for ; Wed, 6 May 2015 08:33:33 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.248.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFB81AD0C1 for ; Wed, 6 May 2015 08:33:33 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 3BE0C1556D7AD; Wed, 6 May 2015 10:33:33 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 2CC1E1556D759 for ; Wed, 6 May 2015 10:33:33 -0500 (CDT) Received: from [173.73.121.66] (port=56642 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yq1KG-0000FK-Ib; Wed, 06 May 2015 10:33:32 -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: Date: Wed, 6 May 2015 11:33:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: rtcweb@ietf.org, draft-schwartz-rtcweb-return@tools.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: 173.73.121.66 X-Exim-ID: 1Yq1KG-0000FK-Ib X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [173.73.121.66]:56642 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [rtcweb] WG call for adoption: draft-schwartz-rtcweb-return X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 15:33:35 -0000 All, Based on messages to the list we=92re going to adopt this draft as a WG = item. Authors, Please submit a WG version of the draft when you have a chance. spt On Apr 16, 2015, at 14:16, Sean Turner wrote: > All, >=20 > There=92s been some interest expressed in having = http://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/ adopted as = an RTCWeb WG item. Please respond to say whether you support adoption = of this work as a working group work item and whether you will = participate in the discussion. If you are opposed to this draft = becoming a WG document, please say so (and say why). Please have your = response in by 20150423 23:59 UTC. >=20 > Thanks in advance! >=20 > spt >=20 > PS - For the casual lurker, there was some vigorous discussion in = Dallas on the -05 version but based on the [1] thread and the -06 = version it looks like we=92re in much better shape. >=20 > [1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg14402.html > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 6 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 B92051A0AFE for ; Wed, 6 May 2015 08:58: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 A4Y3vY1Vq2cx for ; Wed, 6 May 2015 08:58:45 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::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 D21751B2BB2 for ; Wed, 6 May 2015 08:58:33 -0700 (PDT) Received: by yhrr66 with SMTP id r66so3535259yhr.3 for ; Wed, 06 May 2015 08:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dfBbAKZ3M8/Pnmhv0uBRMFYue2WvHxviSB/bQV+gVJc=; b=aEqiloN2uGh+g3mb8nDehyVNnCa8od7ECtYmPYWQ0666ka7sQmtSW8ptLNlNvN+NCZ PaOe3CPIxWvr2+5oYJl2hE06ftVqf+Jlgfdd1ytmgdjYDyFTTIt/6UGddZ5JQqo0N9xb UcwauIAVKjIIwTtux1HKoWb0Z5DSmcC3Oncxgky5s1UGpaD1IrLVhN975qbN+7MHQQw4 0/ohrVdZZk36E+NjndRGJI/O6HUEsrLmYvkC0zI+89baYEJWMpwKbv9C42Lffv/Hkzy9 YCRmy/G8kz54wsntIiYxM57wsLFkDoRCl7GWZJscL7yCdD8GVCbF5/CgCJa9gjsBTsYz MC7w== MIME-Version: 1.0 X-Received: by 10.236.16.138 with SMTP id h10mr22706190yhh.93.1430927913254; Wed, 06 May 2015 08:58:33 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Wed, 6 May 2015 08:58:33 -0700 (PDT) In-Reply-To: <5549E480.4030806@alvestrand.no> References: <5549E480.4030806@alvestrand.no> Date: Wed, 6 May 2015 08:58:33 -0700 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 15:58:46 -0000 On 6 May 2015 at 02:53, Harald Alvestrand wrote: > Do we have an idea on how to move forward with resolving the outstanding > question? I would like to make ECDSA mandatory. There seems to be no question regarding ECDHE. We intend to implement ECDSA, but need the certificate management API additions so that we can avoid compatibility issues (I'll note that chrome and firefox are perfectly happy to negotiate ECDSA with anyone who chooses to use it today, but there might be some gateway/server code out there that might not tolerate it as readily). We can ask TLS, but I will defer to the chairs on how they want to collect feedback (one of the chairs is in a particularly good position in this respect, I note). From nobody Wed May 6 20:57: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 810AE1A8A56 for ; Wed, 6 May 2015 20:57:35 -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 ShXq_vGaJA7F for ; Wed, 6 May 2015 20:57:34 -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 D83001A8946 for ; Wed, 6 May 2015 20:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2329; q=dns/txt; s=iport; t=1430971053; x=1432180653; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Bc6e2PkfHz5WiG/RN3sLiVuN2ukjbixTvam2FnNYzPM=; b=BzqJNnxDxtPBYSG6C1m9TYEkN7JIB3x9QqkVNyp9PqkAlY8oVy1OKBCM fO05Ujq+jdQ8rXB8rmN+nz+roVuFEu4Ika9q021vHQc1hy6EJLiQhE5HN BVMHgyzKgPAnOVqeJaz0FiFKd1C6bzzF1n4E8QEVfxW+JhJBRtKu4tqD8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CzBADm4UpV/5ldJa1cgwxUXgbFdwmBTAqFN04CgSc4FAEBAQEBAQGBCoQgAQEBBAEBAUQnCwwEAgEIEQMBAQEBJwchBgsUCQgCBAENBYgXAxINtmCJCA2FAwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizmCTYI4BwaEJwWLXIZMiQOBVY9Qhmkjg3ZvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,382,1427760000"; d="scan'208";a="147861209" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 07 May 2015 03:57:33 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t473vXiD004326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 03:57:33 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.61]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 6 May 2015 22:57:32 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , Alissa Cooper , Martin Thomson Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQiHnxx7vdP9E8Uke/9vXk+1koEg== Date: Thu, 7 May 2015 03:57:32 +0000 Message-ID: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.98] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <51C5771FD20B9544B5FA2C958F747BF9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 03:57:35 -0000 Hi Christer, Martin=B9s statement says SHOULD here and does not mandate. ICE keepalives could also be used to keep the NAT state Regards, Ram -----Original Message----- From: Christer Holmberg Date: Wednesday, 6 May 2015 12:23 pm To: Alissa Cooper , Martin Thomson Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 >Hi, > >I don't think you need to continue doing consent because of NAT issues, >if you are sending normal STUN keep-alives. > >Regards, > >Christer > >-----Original Message----- >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa Cooper >Sent: 2. toukokuuta 2015 2:20 >To: Martin Thomson >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] AD evaluation: >draft-ietf-rtcweb-stun-consent-freshness-11 > > >On May 1, 2015, at 9:54 AM, Martin Thomson >wrote: > >> On 30 April 2015 at 17:32, Alissa Cooper wrote: >>> "An endpoint that is not sending any application data does not need to >>> maintain consent. However, failure to send could cause any NAT or >>> firewall mappings for the flow to expire. Furthermore, having one >>> peer unable to send is detrimental to many protocols." >>>=20 >>> It sounds like the unstated implication here is that if you are such >>>an endpoint, you should keep doing consent checks anyway to maintain >>>consent. Should that be stated explicitly, or am I misunderstanding? >>=20 >> Can you tell that this is my text? >>=20 >> Yep, the unspoken implication is that if you stop maintaining consent, >> a flow is highly likely to break. I'm OK with making that explicit. >>=20 >> ... . Absent better information about the network, an endpoint SHOULD >> maintain consent if there is any possibility that a flow might be >> needed again. > >WFM > >>=20 >> (Thanks for the suggestion on Sec7. I wasn't happy with it before.) > >_______________________________________________ >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 Wed May 6 22:33: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 355841ACCEE for ; Wed, 6 May 2015 22:33:45 -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 d2HTDDNdV6e3 for ; Wed, 6 May 2015 22:33:43 -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 EBD021ACD6A for ; Wed, 6 May 2015 22:33:36 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-c6-554af92eb3cb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 72.9F.04401.E29FA455; Thu, 7 May 2015 07:33:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Thu, 7 May 2015 07:33:34 +0200 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , Alissa Cooper , Martin Thomson Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQg6ZCX3ABhhDJOU+APBu3+BbmbJ1nNjYAgABrhwCABulYUIABP/oAgAA7v/A= Date: Thu, 7 May 2015 05:33:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@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.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+Jvja7eT69Qg5ePNS2mn/nLaHHtzD9G i+VdOxgt1v5rZ3dg8ZjyeyOrx5cnL5k8ds66y+6xZMlPpgCWKC6blNSczLLUIn27BK6M3UfW MhV8E6m4fmYlWwPjLMEuRk4OCQETid8Pj7BC2GISF+6tZ+ti5OIQEjjKKDFvZgMLSEJIYBGj xL5b1l2MHBxsAhYS3f+0QcIiAvUSB6efYgKxmQXUJe4sPscOUiIsECSx+gwvREmwxOYdr1hA wiICfhI/ThmDmCwCKhJnt3KDVPAK+EocP3WfHWLpQiaJvuuzmUBqOAX0JW7P9QGpYQQ67Pup NVCLxCVuPZnPBHGwgMSSPeeZIWxRiZeP/0E9oiix82w7M0S9nsSNqVPYIGxtiWULXzND7BWU ODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtfB Lb9VdzBefuN4iFGAg1GJh1fhuFeoEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFF pTmpxYcYmTg4pRoYWdnaIia75GzJLWC8Ytb0/4Wg1A6htfzGbGuc9kYoh0+SPvNKZYJm+MSY Hc/vN9n+q19X0NJ95clVRsGoQwIKLxd7TmYxT4ybtGtqi8i/WezOTA2MM70ePFVNyHLyjNuQ 13Dln9GRIr6SvFul+TOOHn+ymb+md3122+POcPdXardEvSoOpRYqsRRnJBpqMRcVJwIAxIWF lJACAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 05:33:45 -0000 Hi, >Martin=B9s statement says SHOULD here and does not mandate. ICE keepalives= could also be used to keep the NAT state There needs to be a good justification for a SHOULD, and consent was never = intended for NAT keep-alives. Also keep in mind that, with the "virtual connection" concept, there might = be a big number of ICE connections - some of which you may never use. Why s= end consent on those, if there is no media? Regards, Christer -----Original Message----- From: Christer Holmberg Date: Wednesday, 6 May 2015 12:23 pm To: Alissa Cooper , Martin Thomson Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 >Hi, > >I don't think you need to continue doing consent because of NAT issues,=20 >if you are sending normal STUN keep-alives. > >Regards, > >Christer > >-----Original Message----- >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa=20 >Cooper >Sent: 2. toukokuuta 2015 2:20 >To: Martin Thomson >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] AD evaluation: >draft-ietf-rtcweb-stun-consent-freshness-11 > > >On May 1, 2015, at 9:54 AM, Martin Thomson >wrote: > >> On 30 April 2015 at 17:32, Alissa Cooper wrote: >>> "An endpoint that is not sending any application data does not need to >>> maintain consent. However, failure to send could cause any NAT or >>> firewall mappings for the flow to expire. Furthermore, having one >>> peer unable to send is detrimental to many protocols." >>>=20 >>> It sounds like the unstated implication here is that if you are such=20 >>>an endpoint, you should keep doing consent checks anyway to maintain=20 >>>consent. Should that be stated explicitly, or am I misunderstanding? >>=20 >> Can you tell that this is my text? >>=20 >> Yep, the unspoken implication is that if you stop maintaining=20 >> consent, a flow is highly likely to break. I'm OK with making that expl= icit. >>=20 >> ... . Absent better information about the network, an endpoint=20 >> SHOULD maintain consent if there is any possibility that a flow might=20 >> be needed again. > >WFM > >>=20 >> (Thanks for the suggestion on Sec7. I wasn't happy with it before.) > >_______________________________________________ >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 Thu May 7 00: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 618301B29CA for ; Thu, 7 May 2015 00:24:46 -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 3F2VjBP21nH7 for ; Thu, 7 May 2015 00:24:44 -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 4823A1B29A7 for ; Thu, 7 May 2015 00:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3643; q=dns/txt; s=iport; t=1430983485; x=1432193085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=f8cok4Hmaj2uDlTSVLrAM7RuTFyFxIXkywkYaW7OmyQ=; b=LmB3oNitkqVLBqXMWKa/v/nbpCKE1ky+IjW+eERAmFPxgzjX0upe4P96 DBkDijeLsSh/No6nYOJuccyRBB5brv+7RlDFCUfkz2ciGuQ6US8m3f1E/ zjeGkjPbx3HYEsK0jNmLL9IO23Fr7qXy+QKVJsGqfX+QN0lhuSHucuat5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArBQAmEktV/4kNJK1cgwxUXgbFJmYJgUwKhTdOAoEnOBQBAQEBAQEBgQqEIAEBAQMBAQEBRCcLDAQCAQgRAwEBAQEKHQchBgsUCQgCBAENBQiIDwMKCA22ZIkHDYUDAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s5gk2CBzEHBoMRgRYFi1yGTIQUhG+DNo1vhmkjg3ZvgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,383,1427760000"; d="scan'208";a="147783096" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP; 07 May 2015 07:24:44 +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 t477Oh0O029693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 07:24:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.74]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 7 May 2015 02:24:43 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christer Holmberg , "Ram Mohan R (rmohanr)" , Alissa Cooper , "Martin Thomson" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQg6ZKGbwEV1fvNkOtBVNfuaQEWZ1nq44AgABriACABsgmgIABYSwAgAAa04D//8lsAA== Date: Thu, 7 May 2015 07:24:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.97] 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] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 07:24:46 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Thursday, May 07, 2015 11:04 AM > To: Ram Mohan R (rmohanr); Alissa Cooper; Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent- > freshness-11 >=20 > Hi, >=20 > >Martin=B9s statement says SHOULD here and does not mandate. ICE > >keepalives could also be used to keep the NAT state >=20 > There needs to be a good justification for a SHOULD, and consent was neve= r > intended for NAT keep-alives. >=20 > Also keep in mind that, with the "virtual connection" concept, there migh= t be > a big number of ICE connections - some of which you may never use. Why > send consent on those, if there is no media? ICE keepalives or consent is only required for candidate pairs selected for= media, http://tools.ietf.org/html/rfc5245#section-10 mandates sending keep= alives if no packet is sent on the candidate pair ICE is using for a media = component for Tr seconds. STUN Binding Indication or consent can be used fo= r keepalives. -Tiru >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg > Date: Wednesday, 6 May 2015 12:23 pm > To: Alissa Cooper , Martin Thomson > > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] AD evaluation: > draft-ietf-rtcweb-stun-consent-freshness-11 >=20 > >Hi, > > > >I don't think you need to continue doing consent because of NAT issues, > >if you are sending normal STUN keep-alives. > > > >Regards, > > > >Christer > > > >-----Original Message----- > >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa > >Cooper > >Sent: 2. toukokuuta 2015 2:20 > >To: Martin Thomson > >Cc: rtcweb@ietf.org > >Subject: Re: [rtcweb] AD evaluation: > >draft-ietf-rtcweb-stun-consent-freshness-11 > > > > > >On May 1, 2015, at 9:54 AM, Martin Thomson > > >wrote: > > > >> On 30 April 2015 at 17:32, Alissa Cooper wrote: > >>> "An endpoint that is not sending any application data does not need t= o > >>> maintain consent. However, failure to send could cause any NAT or > >>> firewall mappings for the flow to expire. Furthermore, having one > >>> peer unable to send is detrimental to many protocols." > >>> > >>> It sounds like the unstated implication here is that if you are such > >>>an endpoint, you should keep doing consent checks anyway to maintain > >>>consent. Should that be stated explicitly, or am I misunderstanding? > >> > >> Can you tell that this is my text? > >> > >> Yep, the unspoken implication is that if you stop maintaining > >> consent, a flow is highly likely to break. I'm OK with making that ex= plicit. > >> > >> ... . Absent better information about the network, an endpoint > >> SHOULD maintain consent if there is any possibility that a flow might > >> be needed again. > > > >WFM > > > >> > >> (Thanks for the suggestion on Sec7. I wasn't happy with it before.) > > > >_______________________________________________ > >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 Thu May 7 02:10: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 A7C021A0025 for ; Thu, 7 May 2015 02:10:26 -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 uL6SkC4FmWO0 for ; Thu, 7 May 2015 02:10:24 -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 393011A0023 for ; Thu, 7 May 2015 02:10:24 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-60-554b2bfeb778 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.F5.04401.EFB2B455; Thu, 7 May 2015 11:10:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Thu, 7 May 2015 11:10:21 +0200 From: Christer Holmberg To: "Tirumaleswar Reddy (tireddy)" , "Ram Mohan R (rmohanr)" , Alissa Cooper , "Martin Thomson" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQg6ZCX3ABhhDJOU+APBu3+BbmbJ1nNjYAgABrhwCABulYUIABP/oAgAA7v/D///4jAIAAPj2Q Date: Thu, 7 May 2015 09:10:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A47833F10@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.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGfG3RveftneowYmFMhbTz/xltLh25h+j xfKuHYwWa/+1s1uc2L2N0YHVY8rvjaweX568ZPLYOesuu8eSJT+ZAliiuGxSUnMyy1KL9O0S uDKervrHVHBItqLtyDf2Bsbv4l2MnBwSAiYS054vY4SwxSQu3FvP1sXIxSEkcJRRouvHbCYI ZxGjxJufb5i7GDk42AQsJLr/aYPERQS2M0p0XrjHDtLNLKAucWfxOXaQGmGBIInVZ3hBwiIC wRKbd7xigbCjJP7372QFsVkEVCRmPG8Gs3kFfCV2Nrxlhdi1glni8/YXYBdxAiVa1m5lArEZ ga77fmoNE8QucYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtqLEzrPtzBD1ehI3pk5hg7C1JZYt fM0MsVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5da sokRGHMHt/xW3cF4+Y3jIUYBDkYlHl6F416hQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeWpGan phakFsUXleakFh9iZOLglGpg5PIuLck+cK3kheUqs/9VnZNblirxfP1/z/f29U1s5zqOHXeU lZyaeeI782mbF/V3fc5Pv2d583PJh0P7D6ncDJ+633Xdy8UX94kLfkl+ktpx1bK1OJpxoeJO xsdM7LevS3Iu5DB4VfV8wt2GvgT3eKOHzLbC8568y+gOZTOe0Xk18bkX57TSBCWW4oxEQy3m ouJEAFy06IqaAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 09:10:26 -0000 Hi, >>>Martin=B9s statement says SHOULD here and does not mandate. ICE=20 >>>keepalives could also be used to keep the NAT state >>=20 >> There needs to be a good justification for a SHOULD, and consent was=20 >> never intended for NAT keep-alives. >>=20 >> Also keep in mind that, with the "virtual connection" concept, there=20 >> might be a big number of ICE connections - some of which you may never=20 >> use. Why send consent on those, if there is no media? > > ICE keepalives or consent is only required for candidate pairs selected f= or media,=20 Correct. But, you may have multiple candidate pairs "selected for media", b= ut that doesn't mean you are sending media on all of them. Very likely you = are, at any given time, only sending media on one of them. > http://tools.ietf.org/html/rfc5245#section-10 mandates sending keepalives= if no packet is sent on the candidate pair ICE is using for a media compon= ent for Tr seconds. STUN Binding Indication or consent can be used for keep= alives. Correct. My issue is why there should be a "SHOULD send consent" on candida= te pairs currently not used for sending media. In such case, only the NAT b= indings need to be maintained, and the keep-alives take care of that. Regards, Christer > -----Original Message----- > From: Christer Holmberg > Date: Wednesday, 6 May 2015 12:23 pm > To: Alissa Cooper , Martin Thomson=20 > > Cc: "rtcweb@ietf.org" > Subject: Re: [rtcweb] AD evaluation: > draft-ietf-rtcweb-stun-consent-freshness-11 >=20 > >Hi, > > > >I don't think you need to continue doing consent because of NAT=20 > >issues, if you are sending normal STUN keep-alives. > > > >Regards, > > > >Christer > > > >-----Original Message----- > >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa=20 > >Cooper > >Sent: 2. toukokuuta 2015 2:20 > >To: Martin Thomson > >Cc: rtcweb@ietf.org > >Subject: Re: [rtcweb] AD evaluation: > >draft-ietf-rtcweb-stun-consent-freshness-11 > > > > > >On May 1, 2015, at 9:54 AM, Martin Thomson > > >wrote: > > > >> On 30 April 2015 at 17:32, Alissa Cooper wrote: > >>> "An endpoint that is not sending any application data does not need t= o > >>> maintain consent. However, failure to send could cause any NAT or > >>> firewall mappings for the flow to expire. Furthermore, having one > >>> peer unable to send is detrimental to many protocols." > >>> > >>> It sounds like the unstated implication here is that if you are=20 > >>>such an endpoint, you should keep doing consent checks anyway to=20 > >>>maintain consent. Should that be stated explicitly, or am I misunderst= anding? > >> > >> Can you tell that this is my text? > >> > >> Yep, the unspoken implication is that if you stop maintaining=20 > >> consent, a flow is highly likely to break. I'm OK with making that ex= plicit. > >> > >> ... . Absent better information about the network, an endpoint=20 > >> SHOULD maintain consent if there is any possibility that a flow=20 > >> might be needed again. > > > >WFM > > > >> > >> (Thanks for the suggestion on Sec7. I wasn't happy with it=20 > >> before.) > > > >_______________________________________________ > >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 Thu May 7 02:19: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 128571A005A for ; Thu, 7 May 2015 02:19:34 -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 7SzMmi-8duzH for ; Thu, 7 May 2015 02:19:32 -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 E1E8C1A0056 for ; Thu, 7 May 2015 02:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7218; q=dns/txt; s=iport; t=1430990372; x=1432199972; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fozvNs6YdA8+3JhGqmoqd5rSax/a/C82QzzsBz6E68Q=; b=lRyIdqcZKWdZo1iVlRGSEYlA85esoOX3DKKqXI6iIuv2t8c7AcKjzsiC aNw+ykDGQm3ELl39eRotuWtTfZzSuPZdyrhNG+FvfHZOThut9FGdH8vkt 04ysoHR8QR8hzd2/O0Koku4Sy2D2pLi3JDKMjk0niXzekH3x6p50D6ipc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C1BAAeLUtV/5hdJa1cgwxUXgaDGMI9CYFMCoU3TgIcgQ04FAEBAQEBAQGBCoQgAQEBBAEBATETJwsMBAIBCBEDAQEBAQQjBQICHwYLFAkIAgQBDQWIFwMSDZRfnH8GhRiIfw2FAwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBG4oegk2CBTMHBoJcgUsFkiiEFIRvgVWBYY1vhmkjgWaCEG+BRIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="scan'208";a="147807717" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 07 May 2015 09:19:31 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t479JUkT015496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 09:19:30 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.61]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 7 May 2015 04:19:30 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "Tirumaleswar Reddy (tireddy)" , Alissa Cooper , "Martin Thomson" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQiKbrGbwEV1fvNkOtBVNfuaQEWQ== Date: Thu, 7 May 2015 09:19:29 +0000 Message-ID: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.98] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 09:19:34 -0000 SGkgQ2hyaXN0ZXIsDQoNCkhvdyBhYm91dCB0aGUgYmVsb3cgdGV4dC4gRG9lcyBpdCBzb3VuZCBi ZXR0ZXIgPw0KDQpPTEQ6DQoNCiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55 IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bw0KICAgbWFpbnRhaW4gY29uc2VudC4g IEhvd2V2ZXIsIGZhaWx1cmUgdG8gc2VuZCBjb3VsZCBjYXVzZSBhbnkgTkFUIG9yDQogICBmaXJl d2FsbCBtYXBwaW5ncyBmb3IgdGhlIGZsb3cgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmlu ZyBvbmUNCiAgIHBlZXIgdW5hYmxlIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90 b2NvbHMuICBBYnNlbnQgYmV0dGVyDQogICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0d29yaywg YW4gZW5kcG9pbnQgU0hPVUxEIG1haW50YWluIGNvbnNlbnQgaWYNCiAgIHRoZXJlIGlzIGFueSBw b3NzaWJpbGl0eSB0aGF0IGEgZmxvdyBtaWdodCBiZSBuZWVkZWQgYWdhaW4uDQoNCk5FVzoNCg0K ICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBk b2VzIG5vdCBuZWVkIHRvDQogICBtYWludGFpbiBjb25zZW50LiBIb3dldmVyLCBmYWlsdXJlIHRv IHNlbmQgY291bGQgY2F1c2UgYW55IE5BVCBvcg0KICAgZmlyZXdhbGwgbWFwcGluZ3MgZm9yIHRo ZSBmbG93IHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lDQogICBwZWVyIHVuYWJs ZSB0byBzZW5kIGlzIGRldHJpbWVudGFsIHRvIG1hbnkgcHJvdG9jb2xzLiAgQWJzZW50IGJldHRl cg0KICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRz IHRvIGVuc3VyZSBpdHMgTkFUDQogICBvciBmaXJld2FsbCBtYXBwaW5ncyBwZXJzaXN0IHdoaWNo IGNhbiBiZSBkb25lIHVzaW5nIGtlZXBhbGl2ZSBvcg0KICAgb3RoZXIgdGVjaG5pcXVlcyAoc2Vl IFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS4NCg0KDQoNClJhbQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkRhdGU6IFRodXJzZGF5LCA3IE1heSAyMDE1 IDI6NDAgcG0NClRvOiAiVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSIgPHRpcmVkZHlAY2lz Y28uY29tPiwgQ2lzY28gRW1wbG95ZWUNCjxybW9oYW5yQGNpc2NvLmNvbT4sIEFsaXNzYSBDb29w ZXIgPGFsaXNzYUBjb29wZXJ3LmluPiwgTWFydGluIFRob21zb24NCjxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20+DQpDYzogInJ0Y3dlYkBpZXRmLm9yZyIgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJFOiBbcnRjd2ViXSBBRCBldmFsdWF0aW9uOg0KZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1j b25zZW50LWZyZXNobmVzcy0xMQ0KDQo+SGksDQo+DQo+Pj4+TWFydGluqfZzIHN0YXRlbWVudCBz YXlzIFNIT1VMRCBoZXJlIGFuZCBkb2VzIG5vdCBtYW5kYXRlLiBJQ0UNCj4+Pj5rZWVwYWxpdmVz IGNvdWxkIGFsc28gYmUgdXNlZCB0byBrZWVwIHRoZSBOQVQgc3RhdGUNCj4+PiANCj4+PiBUaGVy ZSBuZWVkcyB0byBiZSBhIGdvb2QganVzdGlmaWNhdGlvbiBmb3IgYSBTSE9VTEQsIGFuZCBjb25z ZW50IHdhcw0KPj4+IG5ldmVyIGludGVuZGVkIGZvciBOQVQga2VlcC1hbGl2ZXMuDQo+Pj4gDQo+ Pj4gQWxzbyBrZWVwIGluIG1pbmQgdGhhdCwgd2l0aCB0aGUgInZpcnR1YWwgY29ubmVjdGlvbiIg Y29uY2VwdCwgdGhlcmUNCj4+PiBtaWdodCBiZSBhIGJpZyBudW1iZXIgb2YgSUNFIGNvbm5lY3Rp b25zIC0gc29tZSBvZiB3aGljaCB5b3UgbWF5IG5ldmVyDQo+Pj4gdXNlLiBXaHkgc2VuZCBjb25z ZW50IG9uIHRob3NlLCBpZiB0aGVyZSBpcyBubyBtZWRpYT8NCj4+DQo+PiBJQ0Uga2VlcGFsaXZl cyBvciBjb25zZW50IGlzIG9ubHkgcmVxdWlyZWQgZm9yIGNhbmRpZGF0ZSBwYWlycyBzZWxlY3Rl ZA0KPj5mb3IgbWVkaWEsIA0KPg0KPkNvcnJlY3QuIEJ1dCwgeW91IG1heSBoYXZlIG11bHRpcGxl IGNhbmRpZGF0ZSBwYWlycyAic2VsZWN0ZWQgZm9yIG1lZGlhIiwNCj5idXQgdGhhdCBkb2Vzbid0 IG1lYW4geW91IGFyZSBzZW5kaW5nIG1lZGlhIG9uIGFsbCBvZiB0aGVtLiBWZXJ5IGxpa2VseQ0K PnlvdSBhcmUsIGF0IGFueSBnaXZlbiB0aW1lLCBvbmx5IHNlbmRpbmcgbWVkaWEgb24gb25lIG9m IHRoZW0uDQo+DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24t MTAgbWFuZGF0ZXMgc2VuZGluZw0KPj5rZWVwYWxpdmVzIGlmIG5vIHBhY2tldCBpcyBzZW50IG9u IHRoZSBjYW5kaWRhdGUgcGFpciBJQ0UgaXMgdXNpbmcgZm9yIGENCj4+bWVkaWEgY29tcG9uZW50 IGZvciBUciBzZWNvbmRzLiBTVFVOIEJpbmRpbmcgSW5kaWNhdGlvbiBvciBjb25zZW50IGNhbg0K Pj5iZSB1c2VkIGZvciBrZWVwYWxpdmVzLg0KPg0KPkNvcnJlY3QuIE15IGlzc3VlIGlzIHdoeSB0 aGVyZSBzaG91bGQgYmUgYSAiU0hPVUxEIHNlbmQgY29uc2VudCIgb24NCj5jYW5kaWRhdGUgcGFp cnMgY3VycmVudGx5IG5vdCB1c2VkIGZvciBzZW5kaW5nIG1lZGlhLiBJbiBzdWNoIGNhc2UsIG9u bHkNCj50aGUgTkFUIGJpbmRpbmdzIG5lZWQgdG8gYmUgbWFpbnRhaW5lZCwgYW5kIHRoZSBrZWVw LWFsaXZlcyB0YWtlIGNhcmUgb2YNCj50aGF0Lg0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXIN Cj4NCj4NCj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4gRGF0ZTogV2Vk bmVzZGF5LCA2IE1heSAyMDE1IDEyOjIzIHBtDQo+PiBUbzogQWxpc3NhIENvb3BlciA8YWxpc3Nh QGNvb3BlcncuaW4+LCBNYXJ0aW4gVGhvbXNvbg0KPj4gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bT4NCj4+IENjOiAicnRjd2ViQGlldGYub3JnIiA8cnRjd2ViQGlldGYub3JnPg0KPj4gU3ViamVj dDogUmU6IFtydGN3ZWJdIEFEIGV2YWx1YXRpb246DQo+PiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVu LWNvbnNlbnQtZnJlc2huZXNzLTExDQo+PiANCj4+ID5IaSwNCj4+ID4NCj4+ID5JIGRvbid0IHRo aW5rIHlvdSBuZWVkIHRvIGNvbnRpbnVlIGRvaW5nIGNvbnNlbnQgYmVjYXVzZSBvZiBOQVQNCj4+ ID5pc3N1ZXMsIGlmIHlvdSBhcmUgc2VuZGluZyBub3JtYWwgU1RVTiBrZWVwLWFsaXZlcy4NCj4+ ID4NCj4+ID5SZWdhcmRzLA0KPj4gPg0KPj4gPkNocmlzdGVyDQo+PiA+DQo+PiA+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+ID5Gcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsaXNzYQ0KPj4gPkNvb3Blcg0KPj4gPlNlbnQ6IDIu IHRvdWtva3V1dGEgMjAxNSAyOjIwDQo+PiA+VG86IE1hcnRpbiBUaG9tc29uDQo+PiA+Q2M6IHJ0 Y3dlYkBpZXRmLm9yZw0KPj4gPlN1YmplY3Q6IFJlOiBbcnRjd2ViXSBBRCBldmFsdWF0aW9uOg0K Pj4gPmRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTENCj4+ID4NCj4+ ID4NCj4+ID5PbiBNYXkgMSwgMjAxNSwgYXQgOTo1NCBBTSwgTWFydGluIFRob21zb24NCj4+IDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQo+PiA+d3JvdGU6DQo+PiA+DQo+PiA+PiBPbiAzMCBB cHJpbCAyMDE1IGF0IDE3OjMyLCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4gd3Jv dGU6DQo+PiA+Pj4gIkFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0 aW9uIGRhdGEgZG9lcyBub3QgbmVlZA0KPj50bw0KPj4gPj4+ICAgbWFpbnRhaW4gY29uc2VudC4g IEhvd2V2ZXIsIGZhaWx1cmUgdG8gc2VuZCBjb3VsZCBjYXVzZSBhbnkgTkFUIG9yDQo+PiA+Pj4g ICBmaXJld2FsbCBtYXBwaW5ncyBmb3IgdGhlIGZsb3cgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUs IGhhdmluZyBvbmUNCj4+ID4+PiAgIHBlZXIgdW5hYmxlIHRvIHNlbmQgaXMgZGV0cmltZW50YWwg dG8gbWFueSBwcm90b2NvbHMuIg0KPj4gPj4+DQo+PiA+Pj4gSXQgc291bmRzIGxpa2UgdGhlIHVu c3RhdGVkIGltcGxpY2F0aW9uIGhlcmUgaXMgdGhhdCBpZiB5b3UgYXJlDQo+PiA+Pj5zdWNoIGFu IGVuZHBvaW50LCB5b3Ugc2hvdWxkIGtlZXAgZG9pbmcgY29uc2VudCBjaGVja3MgYW55d2F5IHRv DQo+PiA+Pj5tYWludGFpbiBjb25zZW50LiBTaG91bGQgdGhhdCBiZSBzdGF0ZWQgZXhwbGljaXRs eSwgb3IgYW0gSQ0KPj5taXN1bmRlcnN0YW5kaW5nPw0KPj4gPj4NCj4+ID4+IENhbiB5b3UgdGVs bCB0aGF0IHRoaXMgaXMgbXkgdGV4dD8NCj4+ID4+DQo+PiA+PiBZZXAsIHRoZSB1bnNwb2tlbiBp bXBsaWNhdGlvbiBpcyB0aGF0IGlmIHlvdSBzdG9wIG1haW50YWluaW5nDQo+PiA+PiBjb25zZW50 LCBhIGZsb3cgaXMgaGlnaGx5IGxpa2VseSB0byBicmVhay4gIEknbSBPSyB3aXRoIG1ha2luZyB0 aGF0DQo+PmV4cGxpY2l0Lg0KPj4gPj4NCj4+ID4+IC4uLiAuICBBYnNlbnQgYmV0dGVyIGluZm9y bWF0aW9uIGFib3V0IHRoZSBuZXR3b3JrLCBhbiBlbmRwb2ludA0KPj4gPj4gU0hPVUxEIG1haW50 YWluIGNvbnNlbnQgaWYgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5IHRoYXQgYSBmbG93DQo+PiA+ PiBtaWdodCBiZSBuZWVkZWQgYWdhaW4uDQo+PiA+DQo+PiA+V0ZNDQo+PiA+DQo+PiA+Pg0KPj4g Pj4gKFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24gb24gU2VjNy4gIEkgd2Fzbid0IGhhcHB5IHdp dGggaXQNCj4+ID4+IGJlZm9yZS4pDQo+PiA+DQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5ydGN3ZWIgbWFpbGluZyBsaXN0DQo+PiA+cnRj d2ViQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWINCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+ID5ydGN3ZWJAaWV0Zi5vcmcNCj4+ ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4gDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRjd2Vi IG1haWxpbmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= From nobody Thu May 7 02:38: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 BDF3F1A0068 for ; Thu, 7 May 2015 02:38:40 -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 yustmkAHQuiC for ; Thu, 7 May 2015 02:38:39 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (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 998F11A0067 for ; Thu, 7 May 2015 02:38:38 -0700 (PDT) Received: by wgin8 with SMTP id n8so37595701wgi.0 for ; Thu, 07 May 2015 02:38:37 -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=/1OlfT3UHqZIqswxap3mubyRxw0F+cgu6o/5LFaMZFM=; b=I9GE6iofmmhd7l2BhPBCR+G6vfHltJ+BPPvugoGClueZ4yqYamlrgFZwB6OkVazCvT Ul6o/n5igqlamrf1kEsVgpPCa8mTdhGEkv1jE3YMdNeNqDyJBaTjxIJ4DC8EvKOHpRuR DAH+WLC06pGwkWo1hsh9OL8ioWAquqby3rRgy0Z08zEGucxSYnmHdhulNzMkSXRIG0cB /26CZJzQFdA4OsfAZu/4PQuXaat6qUL8i7G3OMoZSQHFxJRlc/O98dKw/m57RqPlac5p PDqa1J+y8cMn246/z8qkkKfsfoeaMyjiSGnkm7VOFqp8AeNAc/L3vZ01PFHD4xRBQcd3 qblQ== MIME-Version: 1.0 X-Received: by 10.180.87.101 with SMTP id w5mr4988598wiz.18.1430991517335; Thu, 07 May 2015 02:38:37 -0700 (PDT) Received: by 10.194.233.233 with HTTP; Thu, 7 May 2015 02:38:37 -0700 (PDT) In-Reply-To: References: <5549E480.4030806@alvestrand.no> Date: Thu, 7 May 2015 10:38:37 +0100 Message-ID: From: Ted Hardie To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d044402e411496605157aad93 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 09:38:40 -0000 --f46d044402e411496605157aad93 Content-Type: text/plain; charset=UTF-8 I am not chair with the particularly good position to collect feedback, but I happen to know he's flying today. My understanding of the current theory is that we ask TLS what cipher suites and version numbers to mandate; if we had a strong reason to disagree, we would need to document why we went with something other than what they suggested. He-who-is-in-the-air may tell me I've got it wrong, of course. Ted On Wed, May 6, 2015 at 4:58 PM, Martin Thomson wrote: > On 6 May 2015 at 02:53, Harald Alvestrand wrote: > > Do we have an idea on how to move forward with resolving the outstanding > > question? > > I would like to make ECDSA mandatory. There seems to be no question > regarding ECDHE. We intend to implement ECDSA, but need the > certificate management API additions so that we can avoid > compatibility issues (I'll note that chrome and firefox are perfectly > happy to negotiate ECDSA with anyone who chooses to use it today, but > there might be some gateway/server code out there that might not > tolerate it as readily). > > We can ask TLS, but I will defer to the chairs on how they want to > collect feedback (one of the chairs is in a particularly good position > in this respect, I note). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f46d044402e411496605157aad93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not chair with the particularly good positi= on to collect feedback, but I happen to know he's flying today.=C2=A0 M= y understanding of the current theory is that we ask TLS what cipher suites= and version numbers to mandate; if we had a strong reason to disagree, we = would need to document why we went with something other than what they sugg= ested.

He-who-is-in-the-air may tell me I've go= t it wrong, of course.

Ted

On Wed, May 6, 2015 at 4:58= PM, Martin Thomson <martin.thomson@gmail.com> wrote:=
On 6 May 2015 at 02:53,= Harald Alvestrand <harald@alves= trand.no> wrote:
> Do we have an idea on how to move forward with resolving the outstandi= ng
> question?

I would like to make ECDSA mandatory.=C2=A0 There seems to be no que= stion
regarding ECDHE.=C2=A0 We intend to implement ECDSA, but need the
certificate management API additions so that we can avoid
compatibility issues (I'll note that chrome and firefox are perfectly happy to negotiate ECDSA with anyone who chooses to use it today, but
there might be some gateway/server code out there that might not
tolerate it as readily).

We can ask TLS, but I will defer to the chairs on how they want to
collect feedback (one of the chairs is in a particularly good position
in this respect, I note).

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

--f46d044402e411496605157aad93-- From nobody Thu May 7 02:49: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 E96D31A00C2 for ; Thu, 7 May 2015 02:49:54 -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 eTf5-BWrYpkG for ; Thu, 7 May 2015 02:49:52 -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 20FA71A009B for ; Thu, 7 May 2015 02:49:51 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-97-554b353da598 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.7B.17665.D353B455; Thu, 7 May 2015 11:49:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Thu, 7 May 2015 11:49:49 +0200 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "Tirumaleswar Reddy (tireddy)" , Alissa Cooper , "Martin Thomson" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQg6ZCX3ABhhDJOU+APBu3+BbmbJ1nNjYAgABrhwCABulYUIABP/oAgAA7v/D///4jAIAAPj2Q///h1YCAACjlQA== Date: Thu, 7 May 2015 09:49:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@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.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RtfO1DvUoPMhl8X0M38ZLa6d+cdo sbxrB6PF2n/t7BYndm9jdGD1mPJ7I6vHlycvmTx2zrrL7rFkyU+mAJYoLpuU1JzMstQifbsE roz5C98zFnw0qtjzaT9TA+M8zS5GTg4JAROJA7ffsEPYYhIX7q1n62Lk4hASOMoo0bdvJTuE s4hR4uOsc4xdjBwcbAIWEt3/tEHiIgLbGSVm9GxhAelmFlCXuLP4HDtIjbBAkMTqM7wgYRGB YInNO16xgIRFBLIk/s2uAAmzCKhI7P94iRnE5hXwldj8YD7YDUICE1kkZmzOALE5BfQlPtz+ DFbDCHTb91NrmCA2iUvcejKfCeJmAYkle84zQ9iiEi8f/2OFsBUldp5tZ4ao15O4MXUKG4St LbFs4WuovYISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9 vNSSTYzAeDu45bfuDsbVrx0PMQpwMCrx8Coc9woVYk0sK67MPcQozcGiJM5rZ3woREggPbEk NTs1tSC1KL6oNCe1+BAjEwenVANjvoau3cq7tsLyqfw+d2q3He5ZynaKce4ap/XHNLUlLRyf +0+M2r79WZDqFA4fu/pfuy3X7psYGet2Z7Owl2PkitfrHJ7/qZVw/rAysnUd00a33OLsQIUM s9kbpKqO7/j8Kj2hmedBuIy4yT3lDxcDbz+ODz6bdW7/RUkrr6Pvi/8+qbRiDMlRYinOSDTU Yi4qTgQA5+vAKJgCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 09:49:55 -0000 Hi, The text looks ok, but I think we can simplify/clarify it a little.=20 For example, the usage of "flow" is a little strange, since we explicitly s= ay that no media is sent :) Also, "failure" is the wrong wording in my opinion, because there is no fai= lure. What about: 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 sen= d=20 is detrimental to many protocols. Absent better information about the=20 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=20 Section 10 of [RFC5245] and see [RFC6263]). Regards, Christer -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: 7. toukokuuta 2015 12:19 To: Christer Holmberg; Tirumaleswar Reddy (tireddy); Alissa Cooper; Martin = Thomson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshne= ss-11 Hi Christer, How about the below text. Does it sound better ? OLD: An endpoint that is not sending any application data does not need to maintain consent. However, failure to send could cause any NAT or firewall mappings for the flow to expire. Furthermore, having one peer unable to send is detrimental to many protocols. Absent better information about the network, an endpoint SHOULD maintain consent if there is any possibility that a flow might be needed again. NEW: An endpoint that is not sending any application data does not need to maintain consent. However, failure to send could cause any NAT or firewall mappings for the flow 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 persist which can be done using keepalive or other techniques (see Section 10 of [RFC5245] and see [RFC6263]). Ram -----Original Message----- From: Christer Holmberg Date: Thursday, 7 May 2015 2:40 pm To: "Tirumaleswar Reddy (tireddy)" , Cisco Employee , Alissa Cooper , Martin Thomson Cc: "rtcweb@ietf.org" Subject: RE: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 >Hi, > >>>>Martin=B9s statement says SHOULD here and does not mandate. ICE=20 >>>>keepalives could also be used to keep the NAT state >>>=20 >>> There needs to be a good justification for a SHOULD, and consent was=20 >>> never intended for NAT keep-alives. >>>=20 >>> Also keep in mind that, with the "virtual connection" concept, there=20 >>> might be a big number of ICE connections - some of which you may=20 >>> never use. Why send consent on those, if there is no media? >> >> ICE keepalives or consent is only required for candidate pairs=20 >>selected for media, > >Correct. But, you may have multiple candidate pairs "selected for=20 >media", but that doesn't mean you are sending media on all of them.=20 >Very likely you are, at any given time, only sending media on one of them. > >> http://tools.ietf.org/html/rfc5245#section-10 mandates sending=20 >>keepalives if no packet is sent on the candidate pair ICE is using for=20 >>a media component for Tr seconds. STUN Binding Indication or consent=20 >>can be used for keepalives. > >Correct. My issue is why there should be a "SHOULD send consent" on=20 >candidate pairs currently not used for sending media. In such case,=20 >only the NAT bindings need to be maintained, and the keep-alives take=20 >care of that. > >Regards, > >Christer > > > >> -----Original Message----- >> From: Christer Holmberg >> Date: Wednesday, 6 May 2015 12:23 pm >> To: Alissa Cooper , Martin Thomson=20 >> >> Cc: "rtcweb@ietf.org" >> Subject: Re: [rtcweb] AD evaluation: >> draft-ietf-rtcweb-stun-consent-freshness-11 >>=20 >> >Hi, >> > >> >I don't think you need to continue doing consent because of NAT=20 >> >issues, if you are sending normal STUN keep-alives. >> > >> >Regards, >> > >> >Christer >> > >> >-----Original Message----- >> >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa=20 >> >Cooper >> >Sent: 2. toukokuuta 2015 2:20 >> >To: Martin Thomson >> >Cc: rtcweb@ietf.org >> >Subject: Re: [rtcweb] AD evaluation: >> >draft-ietf-rtcweb-stun-consent-freshness-11 >> > >> > >> >On May 1, 2015, at 9:54 AM, Martin Thomson >> >> >wrote: >> > >> >> On 30 April 2015 at 17:32, Alissa Cooper wrote: >> >>> "An endpoint that is not sending any application data does not=20 >> >>> need >>to >> >>> maintain consent. However, failure to send could cause any NAT or >> >>> firewall mappings for the flow to expire. Furthermore, having one >> >>> peer unable to send is detrimental to many protocols." >> >>> >> >>> It sounds like the unstated implication here is that if you are=20 >> >>>such an endpoint, you should keep doing consent checks anyway to=20 >> >>>maintain consent. Should that be stated explicitly, or am I >>misunderstanding? >> >> >> >> Can you tell that this is my text? >> >> >> >> Yep, the unspoken implication is that if you stop maintaining=20 >> >> consent, a flow is highly likely to break. I'm OK with making=20 >> >> that >>explicit. >> >> >> >> ... . Absent better information about the network, an endpoint=20 >> >> SHOULD maintain consent if there is any possibility that a flow=20 >> >> might be needed again. >> > >> >WFM >> > >> >> >> >> (Thanks for the suggestion on Sec7. I wasn't happy with it >> >> before.) >> > >> >_______________________________________________ >> >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 Thu May 7 03:41:59 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 F30931A1A52 for ; Thu, 7 May 2015 03:41:57 -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 7WXVN4db0qha for ; Thu, 7 May 2015 03:41:55 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5450B1A1A48 for ; Thu, 7 May 2015 03:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9664; q=dns/txt; s=iport; t=1430995315; x=1432204915; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LTHrBX717y7fbuYh44OCgeEtIjNWeBRUt81sAfUHfbs=; b=P8Qu6Ik/PXtCOb2hepaGrqoXM2sZEWdRe85F+YfLZKt5Th2eAoGIXtkF IjFdIJHLBx27pFMqjUMOd248w22qcrcdNRrCmD19BgJi7N4NIH2B69AVI 1JLjboCOkU5CIZd+ry14n4Tpv6YjWT80dJby2IfHG25t7WXhwY0DGQFm3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CDBQDbQEtV/5NdJa1cgwxUXgaDGMQUCoU3TgIcgRBMAQEBAQEBgQuEIAEBAQQBAQExEycLDAQCAQgRAwEBAQEEIwUCAh8GCxQJCAIEAQ0FiBcDEg2VApx/BoUYiQUNhQMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgRuKHoJNgjgHBoJcgUsFkiiEFIRvgVWBYY1vhmkjgWaCEG+BRIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,384,1427760000"; d="scan'208";a="414669999" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP; 07 May 2015 10:41:54 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t47AfsNm019903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 May 2015 10:41:54 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.61]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Thu, 7 May 2015 05:41:54 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "Tirumaleswar Reddy (tireddy)" , Alissa Cooper , "Martin Thomson" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQiLJuGbwEV1fvNkOtBVNfuaQEWQ== Date: Thu, 7 May 2015 10:41:53 +0000 Message-ID: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.64.98] Content-Type: text/plain; charset="euc-kr" Content-ID: <23BA1F4D195F104E8A0F58502734F875@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 10:41:58 -0000 UHJvcG9zZWQgdGV4dCBXRk0NCg0KUmVnYXJkcywNClJhbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4NCkRhdGU6IFRodXJzZGF5LCA3IE1heSAyMDE1IDM6MTkgcG0NClRvOiBDaXNjbyBF bXBsb3llZSA8cm1vaGFuckBjaXNjby5jb20+LCAiVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KSINCjx0aXJlZGR5QGNpc2NvLmNvbT4sIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3Lmlu PiwgTWFydGluIFRob21zb24NCjxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzogInJ0Y3dl YkBpZXRmLm9yZyIgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBBRCBl dmFsdWF0aW9uOg0KZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMQ0K DQo+SGksDQo+DQo+VGhlIHRleHQgbG9va3Mgb2ssIGJ1dCBJIHRoaW5rIHdlIGNhbiBzaW1wbGlm eS9jbGFyaWZ5IGl0IGEgbGl0dGxlLg0KPg0KPkZvciBleGFtcGxlLCB0aGUgdXNhZ2Ugb2YgImZs b3ciIGlzIGEgbGl0dGxlIHN0cmFuZ2UsIHNpbmNlIHdlIGV4cGxpY2l0bHkNCj5zYXkgdGhhdCBu byBtZWRpYSBpcyBzZW50IDopDQo+DQo+QWxzbywgImZhaWx1cmUiIGlzIHRoZSB3cm9uZyB3b3Jk aW5nIGluIG15IG9waW5pb24sIGJlY2F1c2UgdGhlcmUgaXMgbm8NCj5mYWlsdXJlLg0KPg0KPldo YXQgYWJvdXQ6DQo+DQo+ICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBw bGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvDQo+ICAgbWFpbnRhaW4gY29uc2VudC4gSG93 ZXZlciwgbm90IHNlbmRpbmcgYW55IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUIG9yDQo+ICAgZmly ZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZyBvbmUgcGVlciB1 bmFibGUgdG8NCj5zZW5kIA0KPiAgIGlzIGRldHJpbWVudGFsIHRvIG1hbnkgcHJvdG9jb2xzLiAg QWJzZW50IGJldHRlciBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCj4gICBuZXR3b3JrLCBpZiBhbiBl bmRwb2ludCBuZWVkcyB0byBlbnN1cmUgaXRzIE5BVCBvciBmaXJld2FsbCBtYXBwaW5ncyBkbw0K PiAgIG5vdCBleHBpcmUsIGl0IGNhbiBiZSBkb25lIHVzaW5nIGtlZXBhbGl2ZSBvciAgb3RoZXIg dGVjaG5pcXVlcyAoc2VlDQo+ICAgU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0gYW5kIHNlZSBbUkZD NjI2M10pLg0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IFJhbSBNb2hhbiBSIChybW9oYW5yKSBbbWFpbHRvOnJtb2hh bnJAY2lzY28uY29tXQ0KPlNlbnQ6IDcuIHRvdWtva3V1dGEgMjAxNSAxMjoxOQ0KPlRvOiBDaHJp c3RlciBIb2xtYmVyZzsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgQWxpc3NhIENvb3Bl cjsNCj5NYXJ0aW4gVGhvbXNvbg0KPkNjOiBydGN3ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTog W3J0Y3dlYl0gQUQgZXZhbHVhdGlvbjoNCj5kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQt ZnJlc2huZXNzLTExDQo+DQo+SGkgQ2hyaXN0ZXIsDQo+DQo+SG93IGFib3V0IHRoZSBiZWxvdyB0 ZXh0LiBEb2VzIGl0IHNvdW5kIGJldHRlciA/DQo+DQo+T0xEOg0KPg0KPiAgIEFuIGVuZHBvaW50 IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0 bw0KPiAgIG1haW50YWluIGNvbnNlbnQuICBIb3dldmVyLCBmYWlsdXJlIHRvIHNlbmQgY291bGQg Y2F1c2UgYW55IE5BVCBvcg0KPiAgIGZpcmV3YWxsIG1hcHBpbmdzIGZvciB0aGUgZmxvdyB0byBl eHBpcmUuICBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZQ0KPiAgIHBlZXIgdW5hYmxlIHRvIHNlbmQg aXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBBYnNlbnQgYmV0dGVyDQo+ICAgaW5m b3JtYXRpb24gYWJvdXQgdGhlIG5ldHdvcmssIGFuIGVuZHBvaW50IFNIT1VMRCBtYWludGFpbiBj b25zZW50IGlmDQo+ICAgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5IHRoYXQgYSBmbG93IG1pZ2h0 IGJlIG5lZWRlZCBhZ2Fpbi4NCj4NCj5ORVc6DQo+DQo+ICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBu b3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvDQo+ICAgbWFp bnRhaW4gY29uc2VudC4gSG93ZXZlciwgZmFpbHVyZSB0byBzZW5kIGNvdWxkIGNhdXNlIGFueSBO QVQgb3INCj4gICBmaXJld2FsbCBtYXBwaW5ncyBmb3IgdGhlIGZsb3cgdG8gZXhwaXJlLiAgRnVy dGhlcm1vcmUsIGhhdmluZyBvbmUNCj4gICBwZWVyIHVuYWJsZSB0byBzZW5kIGlzIGRldHJpbWVu dGFsIHRvIG1hbnkgcHJvdG9jb2xzLiAgQWJzZW50IGJldHRlcg0KPiAgIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBuZXR3b3JrLCBpZiBhbiBlbmRwb2ludCBuZWVkcyB0byBlbnN1cmUgaXRzIE5BVA0K PiAgIG9yIGZpcmV3YWxsIG1hcHBpbmdzIHBlcnNpc3Qgd2hpY2ggY2FuIGJlIGRvbmUgdXNpbmcg a2VlcGFsaXZlIG9yDQo+ICAgb3RoZXIgdGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JG QzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS4NCj4NCj4NCj4NCj5SYW0NCj4NCj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+DQo+RGF0ZTogVGh1cnNkYXksIDcgTWF5IDIwMTUgMjo0MCBwbQ0K PlRvOiAiVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSIgPHRpcmVkZHlAY2lzY28uY29tPiwg Q2lzY28gRW1wbG95ZWUNCj48cm1vaGFuckBjaXNjby5jb20+LCBBbGlzc2EgQ29vcGVyIDxhbGlz c2FAY29vcGVydy5pbj4sIE1hcnRpbiBUaG9tc29uDQo+PG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bT4NCj5DYzogInJ0Y3dlYkBpZXRmLm9yZyIgPHJ0Y3dlYkBpZXRmLm9yZz4NCj5TdWJqZWN0OiBS RTogW3J0Y3dlYl0gQUQgZXZhbHVhdGlvbjoNCj5kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNl bnQtZnJlc2huZXNzLTExDQo+DQo+PkhpLA0KPj4NCj4+Pj4+TWFydGluqfZzIHN0YXRlbWVudCBz YXlzIFNIT1VMRCBoZXJlIGFuZCBkb2VzIG5vdCBtYW5kYXRlLiBJQ0UNCj4+Pj4+a2VlcGFsaXZl cyBjb3VsZCBhbHNvIGJlIHVzZWQgdG8ga2VlcCB0aGUgTkFUIHN0YXRlDQo+Pj4+IA0KPj4+PiBU aGVyZSBuZWVkcyB0byBiZSBhIGdvb2QganVzdGlmaWNhdGlvbiBmb3IgYSBTSE9VTEQsIGFuZCBj b25zZW50IHdhcw0KPj4+PiBuZXZlciBpbnRlbmRlZCBmb3IgTkFUIGtlZXAtYWxpdmVzLg0KPj4+ PiANCj4+Pj4gQWxzbyBrZWVwIGluIG1pbmQgdGhhdCwgd2l0aCB0aGUgInZpcnR1YWwgY29ubmVj dGlvbiIgY29uY2VwdCwgdGhlcmUNCj4+Pj4gbWlnaHQgYmUgYSBiaWcgbnVtYmVyIG9mIElDRSBj b25uZWN0aW9ucyAtIHNvbWUgb2Ygd2hpY2ggeW91IG1heQ0KPj4+PiBuZXZlciB1c2UuIFdoeSBz ZW5kIGNvbnNlbnQgb24gdGhvc2UsIGlmIHRoZXJlIGlzIG5vIG1lZGlhPw0KPj4+DQo+Pj4gSUNF IGtlZXBhbGl2ZXMgb3IgY29uc2VudCBpcyBvbmx5IHJlcXVpcmVkIGZvciBjYW5kaWRhdGUgcGFp cnMNCj4+PnNlbGVjdGVkIGZvciBtZWRpYSwNCj4+DQo+PkNvcnJlY3QuIEJ1dCwgeW91IG1heSBo YXZlIG11bHRpcGxlIGNhbmRpZGF0ZSBwYWlycyAic2VsZWN0ZWQgZm9yDQo+Pm1lZGlhIiwgYnV0 IHRoYXQgZG9lc24ndCBtZWFuIHlvdSBhcmUgc2VuZGluZyBtZWRpYSBvbiBhbGwgb2YgdGhlbS4N Cj4+VmVyeSBsaWtlbHkgeW91IGFyZSwgYXQgYW55IGdpdmVuIHRpbWUsIG9ubHkgc2VuZGluZyBt ZWRpYSBvbiBvbmUgb2YNCj4+dGhlbS4NCj4+DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTI0NSNzZWN0aW9uLTEwIG1hbmRhdGVzIHNlbmRpbmcNCj4+PmtlZXBhbGl2ZXMgaWYg bm8gcGFja2V0IGlzIHNlbnQgb24gdGhlIGNhbmRpZGF0ZSBwYWlyIElDRSBpcyB1c2luZyBmb3IN Cj4+PmEgbWVkaWEgY29tcG9uZW50IGZvciBUciBzZWNvbmRzLiBTVFVOIEJpbmRpbmcgSW5kaWNh dGlvbiBvciBjb25zZW50DQo+Pj5jYW4gYmUgdXNlZCBmb3Iga2VlcGFsaXZlcy4NCj4+DQo+PkNv cnJlY3QuIE15IGlzc3VlIGlzIHdoeSB0aGVyZSBzaG91bGQgYmUgYSAiU0hPVUxEIHNlbmQgY29u c2VudCIgb24NCj4+Y2FuZGlkYXRlIHBhaXJzIGN1cnJlbnRseSBub3QgdXNlZCBmb3Igc2VuZGlu ZyBtZWRpYS4gSW4gc3VjaCBjYXNlLA0KPj5vbmx5IHRoZSBOQVQgYmluZGluZ3MgbmVlZCB0byBi ZSBtYWludGFpbmVkLCBhbmQgdGhlIGtlZXAtYWxpdmVzIHRha2UNCj4+Y2FyZSBvZiB0aGF0Lg0K Pj4NCj4+UmVnYXJkcywNCj4+DQo+PkNocmlzdGVyDQo+Pg0KPj4NCj4+DQo+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+IERhdGU6IFdlZG5lc2RheSwgNiBNYXkgMjAxNSAx MjoyMyBwbQ0KPj4+IFRvOiBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4sIE1hcnRp biBUaG9tc29uDQo+Pj4gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCj4+PiBDYzogInJ0Y3dl YkBpZXRmLm9yZyIgPHJ0Y3dlYkBpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0g QUQgZXZhbHVhdGlvbjoNCj4+PiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2hu ZXNzLTExDQo+Pj4gDQo+Pj4gPkhpLA0KPj4+ID4NCj4+PiA+SSBkb24ndCB0aGluayB5b3UgbmVl ZCB0byBjb250aW51ZSBkb2luZyBjb25zZW50IGJlY2F1c2Ugb2YgTkFUDQo+Pj4gPmlzc3Vlcywg aWYgeW91IGFyZSBzZW5kaW5nIG5vcm1hbCBTVFVOIGtlZXAtYWxpdmVzLg0KPj4+ID4NCj4+PiA+ UmVnYXJkcywNCj4+PiA+DQo+Pj4gPkNocmlzdGVyDQo+Pj4gPg0KPj4+ID4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+ID5Gcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsaXNzYQ0KPj4+ID5Db29wZXINCj4+PiA+U2VudDogMi4g dG91a29rdXV0YSAyMDE1IDI6MjANCj4+PiA+VG86IE1hcnRpbiBUaG9tc29uDQo+Pj4gPkNjOiBy dGN3ZWJAaWV0Zi5vcmcNCj4+PiA+U3ViamVjdDogUmU6IFtydGN3ZWJdIEFEIGV2YWx1YXRpb246 DQo+Pj4gPmRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTENCj4+PiA+ DQo+Pj4gPg0KPj4+ID5PbiBNYXkgMSwgMjAxNSwgYXQgOTo1NCBBTSwgTWFydGluIFRob21zb24N Cj4+PiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KPj4+ID53cm90ZToNCj4+PiA+DQo+Pj4g Pj4gT24gMzAgQXByaWwgMjAxNSBhdCAxNzozMiwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3Bl cncuaW4+IHdyb3RlOg0KPj4+ID4+PiAiQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBh bnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdA0KPj4+ID4+PiBuZWVkDQo+Pj50bw0KPj4+ID4+ PiAgIG1haW50YWluIGNvbnNlbnQuICBIb3dldmVyLCBmYWlsdXJlIHRvIHNlbmQgY291bGQgY2F1 c2UgYW55IE5BVA0KPj4+b3INCj4+PiA+Pj4gICBmaXJld2FsbCBtYXBwaW5ncyBmb3IgdGhlIGZs b3cgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZw0KPj4+b25lDQo+Pj4gPj4+ICAgcGVl ciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy4iDQo+Pj4g Pj4+DQo+Pj4gPj4+IEl0IHNvdW5kcyBsaWtlIHRoZSB1bnN0YXRlZCBpbXBsaWNhdGlvbiBoZXJl IGlzIHRoYXQgaWYgeW91IGFyZQ0KPj4+ID4+PnN1Y2ggYW4gZW5kcG9pbnQsIHlvdSBzaG91bGQg a2VlcCBkb2luZyBjb25zZW50IGNoZWNrcyBhbnl3YXkgdG8NCj4+PiA+Pj5tYWludGFpbiBjb25z ZW50LiBTaG91bGQgdGhhdCBiZSBzdGF0ZWQgZXhwbGljaXRseSwgb3IgYW0gSQ0KPj4+bWlzdW5k ZXJzdGFuZGluZz8NCj4+PiA+Pg0KPj4+ID4+IENhbiB5b3UgdGVsbCB0aGF0IHRoaXMgaXMgbXkg dGV4dD8NCj4+PiA+Pg0KPj4+ID4+IFllcCwgdGhlIHVuc3Bva2VuIGltcGxpY2F0aW9uIGlzIHRo YXQgaWYgeW91IHN0b3AgbWFpbnRhaW5pbmcNCj4+PiA+PiBjb25zZW50LCBhIGZsb3cgaXMgaGln aGx5IGxpa2VseSB0byBicmVhay4gIEknbSBPSyB3aXRoIG1ha2luZw0KPj4+ID4+IHRoYXQNCj4+ PmV4cGxpY2l0Lg0KPj4+ID4+DQo+Pj4gPj4gLi4uIC4gIEFic2VudCBiZXR0ZXIgaW5mb3JtYXRp b24gYWJvdXQgdGhlIG5ldHdvcmssIGFuIGVuZHBvaW50DQo+Pj4gPj4gU0hPVUxEIG1haW50YWlu IGNvbnNlbnQgaWYgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5IHRoYXQgYSBmbG93DQo+Pj4gPj4g bWlnaHQgYmUgbmVlZGVkIGFnYWluLg0KPj4+ID4NCj4+PiA+V0ZNDQo+Pj4gPg0KPj4+ID4+DQo+ Pj4gPj4gKFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24gb24gU2VjNy4gIEkgd2Fzbid0IGhhcHB5 IHdpdGggaXQNCj4+PiA+PiBiZWZvcmUuKQ0KPj4+ID4NCj4+PiA+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+cnRjd2ViIG1haWxpbmcgbGlzdA0K Pj4+ID5ydGN3ZWJAaWV0Zi5vcmcNCj4+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWINCj4+PiA+DQo+Pj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+PiA+cnRjd2Vi QGlldGYub3JnDQo+Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4gcnRjd2ViQGlldGYub3JnDQo+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4NCg0K From nobody Thu May 7 06:46: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 34A051A87D4 for ; Thu, 7 May 2015 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO6f6ju-c7b8 for ; Thu, 7 May 2015 06:46:24 -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 65DC71A8905 for ; Thu, 7 May 2015 06:46:23 -0700 (PDT) Received: by ykep21 with SMTP id p21so11513438yke.3 for ; Thu, 07 May 2015 06:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QtcjnMzTvvz85H5QtcDDHrt7axM1zBc+AjnGnaCYHzY=; b=F4UdRlqoN19MCByWx3u83dzyestLzbIgaliYc55bqgfoFIgUv9tajwrdcdBbuf0ZTT VUd1b4DBwACJWTXbq06EtiQzEVTEGSXt3gLNNpOYHbSp0dJU/sxpXfedyindpLm8OhTE 96+asoxU7GmvlceacDM1sf8+DucOqr9p9OncJMeuGN0ukneJdjc+YP5vqIFhKRwf5d64 KwICo3MmgzS/xG5x/7UxUMJq/sFjar9DKinF2AuHdB4/BDx3NsAmqbtFE+27zG0Ie2sC fLYFGN5wh82ST0TmXHp2vaHkIyIQ02rRWiKx5/iJIh1F6DMFo5+BDUrZCAS8KfnHMY6T ohtQ== MIME-Version: 1.0 X-Received: by 10.236.28.79 with SMTP id f55mr3002191yha.151.1431006382757; Thu, 07 May 2015 06:46:22 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Thu, 7 May 2015 06:46:22 -0700 (PDT) In-Reply-To: References: <5549E480.4030806@alvestrand.no> Date: Thu, 7 May 2015 06:46:22 -0700 Message-ID: From: Martin Thomson To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 13:46:25 -0000 On 7 May 2015 at 02:38, Ted Hardie wrote: > I am not chair with the particularly good position to collect feedback, but > I happen to know he's flying today. My understanding of the current theory > is that we ask TLS what cipher suites and version numbers to mandate; if we > had a strong reason to disagree, we would need to document why we went with > something other than what they suggested. > > He-who-is-in-the-air may tell me I've got it wrong, of course. Sounds good, perhaps we should ask he-who-will-eventually-land to pass on the question, unless we both are wrong. From nobody Fri May 8 05:42:00 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 EC1441A005F for ; Fri, 8 May 2015 05:41:58 -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 10vz7b4Q0dLv for ; Fri, 8 May 2015 05:41:55 -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 92C711A005C for ; Fri, 8 May 2015 05:41:55 -0700 (PDT) Received: by ykft189 with SMTP id t189so19848030ykf.1 for ; Fri, 08 May 2015 05:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VwsQ33P6S//sevtvX1YBFFdrdHlSQoB8p0t/PxUILQ8=; b=NtdPl9CuKQYyhrgcoecsCG6NpsmlzTR3u7m/yZ79Mg/kUn0jvl8eEBA7w1ndpjq5zC avGHrpz8iN5hTNtS5G/6Cti1tTBFRONyLrSUWFhlfoCeDxUkiEJhLYZ8Fm3kx1Y+lBfj O6wlwrm85hqaMaD+80g2bcOW3lvF1PWGFcrJwmt6kjL0M4HWO8EJpuJGOC37/92Nbeui bo4WIY6l9xyJXMh4d2RAQBEqYkQUez9/TB/vXut0euL4xP32ihr8nNFxba2JNxx2KgpP uxy1zJwLF4kSeshN+CEGbW8vFNUzd9VzMX/B4bsw1lc0ZhTOv3BhBLjF0cE6p2xDSQRi 0mHw== MIME-Version: 1.0 X-Received: by 10.236.28.79 with SMTP id f55mr3010106yha.151.1431088914842; Fri, 08 May 2015 05:41:54 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 8 May 2015 05:41:54 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 8 May 2015 05:41:54 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> Date: Fri, 8 May 2015 05:41:54 -0700 Message-ID: From: Martin Thomson To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e0149c1986948c80515915a42 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 12:41:59 -0000 --089e0149c1986948c80515915a42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My intent was to highlight the potential need for re-use. This loses that, so it ends up saying nothing really. It is otherwise ok in the sense that it concentrates on the keep alive aspect. On May 7, 2015 4:49 AM, "Christer Holmberg" wrote: > Hi, > > The text looks ok, but I think we can simplify/clarify it a little. > > For example, the usage of "flow" is a little strange, since we explicitly > say that no media is sent :) > > Also, "failure" is the wrong wording in my opinion, because there is no > failure. > > What about: > > 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 d= o > not expire, it can be done using keepalive or other techniques (see > Section 10 of [RFC5245] and see [RFC6263]). > > Regards, > > Christer > > > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: 7. toukokuuta 2015 12:19 > To: Christer Holmberg; Tirumaleswar Reddy (tireddy); Alissa Cooper; Marti= n > Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] AD evaluation: > draft-ietf-rtcweb-stun-consent-freshness-11 > > Hi Christer, > > How about the below text. Does it sound better ? > > OLD: > > An endpoint that is not sending any application data does not need to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow to expire. Furthermore, having one > peer unable to send is detrimental to many protocols. Absent better > information about the network, an endpoint SHOULD maintain consent if > there is any possibility that a flow might be needed again. > > NEW: > > An endpoint that is not sending any application data does not need to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow 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 persist which can be done using keepalive or > other techniques (see Section 10 of [RFC5245] and see [RFC6263]). > > > > Ram > > -----Original Message----- > From: Christer Holmberg > Date: Thursday, 7 May 2015 2:40 pm > To: "Tirumaleswar Reddy (tireddy)" , Cisco Employee < > rmohanr@cisco.com>, Alissa Cooper , Martin Thomson < > martin.thomson@gmail.com> > Cc: "rtcweb@ietf.org" > Subject: RE: [rtcweb] AD evaluation: > draft-ietf-rtcweb-stun-consent-freshness-11 > > >Hi, > > > >>>>Martin=C2=B9s statement says SHOULD here and does not mandate. ICE > >>>>keepalives could also be used to keep the NAT state > >>> > >>> There needs to be a good justification for a SHOULD, and consent was > >>> never intended for NAT keep-alives. > >>> > >>> Also keep in mind that, with the "virtual connection" concept, there > >>> might be a big number of ICE connections - some of which you may > >>> never use. Why send consent on those, if there is no media? > >> > >> ICE keepalives or consent is only required for candidate pairs > >>selected for media, > > > >Correct. But, you may have multiple candidate pairs "selected for > >media", but that doesn't mean you are sending media on all of them. > >Very likely you are, at any given time, only sending media on one of the= m. > > > >> http://tools.ietf.org/html/rfc5245#section-10 mandates sending > >>keepalives if no packet is sent on the candidate pair ICE is using for > >>a media component for Tr seconds. STUN Binding Indication or consent > >>can be used for keepalives. > > > >Correct. My issue is why there should be a "SHOULD send consent" on > >candidate pairs currently not used for sending media. In such case, > >only the NAT bindings need to be maintained, and the keep-alives take > >care of that. > > > >Regards, > > > >Christer > > > > > > > >> -----Original Message----- > >> From: Christer Holmberg > >> Date: Wednesday, 6 May 2015 12:23 pm > >> To: Alissa Cooper , Martin Thomson > >> > >> Cc: "rtcweb@ietf.org" > >> Subject: Re: [rtcweb] AD evaluation: > >> draft-ietf-rtcweb-stun-consent-freshness-11 > >> > >> >Hi, > >> > > >> >I don't think you need to continue doing consent because of NAT > >> >issues, if you are sending normal STUN keep-alives. > >> > > >> >Regards, > >> > > >> >Christer > >> > > >> >-----Original Message----- > >> >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa > >> >Cooper > >> >Sent: 2. toukokuuta 2015 2:20 > >> >To: Martin Thomson > >> >Cc: rtcweb@ietf.org > >> >Subject: Re: [rtcweb] AD evaluation: > >> >draft-ietf-rtcweb-stun-consent-freshness-11 > >> > > >> > > >> >On May 1, 2015, at 9:54 AM, Martin Thomson > >> > >> >wrote: > >> > > >> >> On 30 April 2015 at 17:32, Alissa Cooper wrote: > >> >>> "An endpoint that is not sending any application data does not > >> >>> need > >>to > >> >>> maintain consent. However, failure to send could cause any NAT = or > >> >>> firewall mappings for the flow to expire. Furthermore, having o= ne > >> >>> peer unable to send is detrimental to many protocols." > >> >>> > >> >>> It sounds like the unstated implication here is that if you are > >> >>>such an endpoint, you should keep doing consent checks anyway to > >> >>>maintain consent. Should that be stated explicitly, or am I > >>misunderstanding? > >> >> > >> >> Can you tell that this is my text? > >> >> > >> >> Yep, the unspoken implication is that if you stop maintaining > >> >> consent, a flow is highly likely to break. I'm OK with making > >> >> that > >>explicit. > >> >> > >> >> ... . Absent better information about the network, an endpoint > >> >> SHOULD maintain consent if there is any possibility that a flow > >> >> might be needed again. > >> > > >> >WFM > >> > > >> >> > >> >> (Thanks for the suggestion on Sec7. I wasn't happy with it > >> >> before.) > >> > > >> >_______________________________________________ > >> >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 > > --089e0149c1986948c80515915a42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

My intent was to highlight the potential need for re-use. Th= is loses that, so it ends up saying nothing really. It is otherwise ok in t= he sense that it concentrates on the keep alive aspect.

On May 7, 2015 4:49 AM, "Christer Holmberg&= quot; <christer.holmbe= rg@ericsson.com> wrote:
Hi,

The text looks ok, but I think we can simplify/clarify it a little.

For example, the usage of "flow" is a little strange, since we ex= plicitly say that no media is sent :)

Also, "failure" is the wrong wording in my opinion, because there= is no failure.

What about:

=C2=A0 =C2=A0An endpoint that is not sending any application data does not = need to
=C2=A0 =C2=A0maintain consent. However, not sending any traffic could cause= NAT or
=C2=A0 =C2=A0firewall mappings to expire.=C2=A0 Furthermore, having one pee= r unable to send
=C2=A0 =C2=A0is detrimental to many protocols.=C2=A0 Absent better informat= ion about the
=C2=A0 =C2=A0network, if an endpoint needs to ensure its NAT or firewall ma= ppings do
=C2=A0 =C2=A0not expire, it can be done using keepalive or=C2=A0 other tech= niques (see
=C2=A0 =C2=A0Section 10 of [RFC5245] and see [RFC6263]).

Regards,

Christer


-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:rm= ohanr@cisco.com]
Sent: 7. toukokuuta 2015 12:19
To: Christer Holmberg; Tirumaleswar Reddy (tireddy); Alissa Cooper; Martin = Thomson
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshne= ss-11

Hi Christer,

How about the below text. Does it sound better ?

OLD:

=C2=A0 =C2=A0An endpoint that is not sending any application data does not = need to
=C2=A0 =C2=A0maintain consent.=C2=A0 However, failure to send could cause a= ny NAT or
=C2=A0 =C2=A0firewall mappings for the flow to expire.=C2=A0 Furthermore, h= aving one
=C2=A0 =C2=A0peer unable to send is detrimental to many protocols.=C2=A0 Ab= sent better
=C2=A0 =C2=A0information about the network, an endpoint SHOULD maintain con= sent if
=C2=A0 =C2=A0there is any possibility that a flow might be needed again.
NEW:

=C2=A0 =C2=A0An endpoint that is not sending any application data does not = need to
=C2=A0 =C2=A0maintain consent. However, failure to send could cause any NAT= or
=C2=A0 =C2=A0firewall mappings for the flow to expire.=C2=A0 Furthermore, h= aving one
=C2=A0 =C2=A0peer unable to send is detrimental to many protocols.=C2=A0 Ab= sent better
=C2=A0 =C2=A0information about the network, if an endpoint needs to ensure = its NAT
=C2=A0 =C2=A0or firewall mappings persist which can be done using keepalive= or
=C2=A0 =C2=A0other techniques (see Section 10 of [RFC5245] and see [RFC6263= ]).



Ram

-----Original Message-----
From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thursday, 7 May 2015 2:40 pm
To: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, Cisco Employee <rmohanr@cisco.com>, Alissa Cooper <alissa@cooperw.in>, Martin Thomson <martin.thomson@gmail.com> Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: RE: [rtcweb] AD evaluation:
draft-ietf-rtcweb-stun-consent-freshness-11

>Hi,
>
>>>>Martin=C2=B9s statement says SHOULD here and does not manda= te. ICE
>>>>keepalives could also be used to keep the NAT state
>>>
>>> There needs to be a good justification for a SHOULD, and conse= nt was
>>> never intended for NAT keep-alives.
>>>
>>> Also keep in mind that, with the "virtual connection"= ; concept, there
>>> might be a big number of ICE connections - some of which you m= ay
>>> never use. Why send consent on those, if there is no media? >>
>> ICE keepalives or consent is only required for candidate pairs
>>selected for media,
>
>Correct. But, you may have multiple candidate pairs "selected for<= br> >media", but that doesn't mean you are sending media on all of = them.
>Very likely you are, at any given time, only sending media on one of th= em.
>
>> http://tools.ietf.org/html/rfc5245#section-10 mandates send= ing
>>keepalives if no packet is sent on the candidate pair ICE is using = for
>>a media component for Tr seconds. STUN Binding Indication or consen= t
>>can be used for keepalives.
>
>Correct. My issue is why there should be a "SHOULD send consent&qu= ot; on
>candidate pairs currently not used for sending media. In such case,
>only the NAT bindings need to be maintained, and the keep-alives take >care of that.
>
>Regards,
>
>Christer
>
>
>
>> -----Original Message-----
>> From: Christer Holmberg <christer.holmberg@ericsson.com>
>> Date: Wednesday, 6 May 2015 12:23 pm
>> To: Alissa Cooper <alissa@= cooperw.in>, Martin Thomson
>> <martin.thomson@gma= il.com>
>> Cc: "rtcweb@ietf.org&q= uot; <rtcweb@ietf.org>
>> Subject: Re: [rtcweb] AD evaluation:
>> draft-ietf-rtcweb-stun-consent-freshness-11
>>
>> >Hi,
>> >
>> >I don't think you need to continue doing consent because o= f NAT
>> >issues, if you are sending normal STUN keep-alives.
>> >
>> >Regards,
>> >
>> >Christer
>> >
>> >-----Original Message-----
>> >From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa
>> >Cooper
>> >Sent: 2. toukokuuta 2015 2:20
>> >To: Martin Thomson
>> >Cc: rtcweb@ietf.org
>> >Subject: Re: [rtcweb] AD evaluation:
>> >draft-ietf-rtcweb-stun-consent-freshness-11
>> >
>> >
>> >On May 1, 2015, at 9:54 AM, Martin Thomson
>> <martin.thomson@gma= il.com>
>> >wrote:
>> >
>> >> On 30 April 2015 at 17:32, Alissa Cooper <alissa@cooperw.in> wrote:
>> >>> "An endpoint that is not sending any application= data does not
>> >>> need
>>to
>> >>>=C2=A0 =C2=A0maintain consent.=C2=A0 However, failure = to send could cause any NAT or
>> >>>=C2=A0 =C2=A0firewall mappings for the flow to expire.= =C2=A0 Furthermore, having one
>> >>>=C2=A0 =C2=A0peer unable to send is detrimental to man= y protocols."
>> >>>
>> >>> It sounds like the unstated implication here is that = if you are
>> >>>such an endpoint, you should keep doing consent checks= anyway to
>> >>>maintain consent. Should that be stated explicitly, or= am I
>>misunderstanding?
>> >>
>> >> Can you tell that this is my text?
>> >>
>> >> Yep, the unspoken implication is that if you stop maintai= ning
>> >> consent, a flow is highly likely to break.=C2=A0 I'm = OK with making
>> >> that
>>explicit.
>> >>
>> >> ... .=C2=A0 Absent better information about the network, = an endpoint
>> >> SHOULD maintain consent if there is any possibility that = a flow
>> >> might be needed again.
>> >
>> >WFM
>> >
>> >>
>> >> (Thanks for the suggestion on Sec7.=C2=A0 I wasn't ha= ppy with it
>> >> before.)
>> >
>> >_______________________________________________
>> >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

--089e0149c1986948c80515915a42-- From nobody Fri May 8 06:11: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 5141A1A0193 for ; Fri, 8 May 2015 06:11:44 -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 ivc7QLfVMURv for ; Fri, 8 May 2015 06:11:42 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6611D1A0242 for ; Fri, 8 May 2015 06:11:17 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 78EFE20C1E for ; Fri, 8 May 2015 09:11:16 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 08 May 2015 09:11:16 -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=8J0vtO1Z68e5IulisM5VIuOll+g=; b=10hDL7 ej0N9+MPQXrVOd1ak/zW6X/ROOQBKMj9nGpp3R+6A3lyhCoiEFI1FR9C2TDwIF80 2DFHT5mAD9ISzWE41JWRyTzcz/sXvKTtzBrH4WKmfxNu0Uut8oHg3OE0DeZMFrzr XGRuBx0SzE/Vgf8FHgaYzufuMw67I7wFMAsko= 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=8J0vtO1Z68e5Iul isM5VIuOll+g=; b=f1B6ojztbCJ7XyU1cj4P4QmgauGUzM6lRptF9lg++2u+9q9 nX3D/XCug22PMqOfZOPsSJ4QyyGC4ri6nxYbk1X+ih+PbnfPFNeJe/594FG8IRUh de0wJSkqGE901Zos5zoJ3TzT5QR+pW9w7wc7BzFYKvaDh/Vv80JWV2nVyyHA= X-Sasl-enc: ZQxVRLsaPdpyKIKM6g80EuI+cJi+GGxZLFllyjAAI86K 1431090676 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.190]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BD9AC00017; Fri, 8 May 2015 09:11:14 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> Date: Fri, 8 May 2015 06:11:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 13:11:44 -0000 Ok with me. Alissa On May 7, 2015, at 2:49 AM, Christer Holmberg = wrote: > Hi, >=20 > The text looks ok, but I think we can simplify/clarify it a little.=20 >=20 > For example, the usage of "flow" is a little strange, since we = explicitly say that no media is sent :) >=20 > Also, "failure" is the wrong wording in my opinion, because there is = no failure. >=20 > What about: >=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=20 > is detrimental to many protocols. Absent better information about = the=20 > 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=20= > Section 10 of [RFC5245] and see [RFC6263]). >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 > Sent: 7. toukokuuta 2015 12:19 > To: Christer Holmberg; Tirumaleswar Reddy (tireddy); Alissa Cooper; = Martin Thomson > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] AD evaluation: = draft-ietf-rtcweb-stun-consent-freshness-11 >=20 > Hi Christer, >=20 > How about the below text. Does it sound better ? >=20 > OLD: >=20 > An endpoint that is not sending any application data does not need = to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow to expire. Furthermore, having one > peer unable to send is detrimental to many protocols. Absent better > information about the network, an endpoint SHOULD maintain consent = if > there is any possibility that a flow might be needed again. >=20 > NEW: >=20 > An endpoint that is not sending any application data does not need = to > maintain consent. However, failure to send could cause any NAT or > firewall mappings for the flow 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 persist which can be done using keepalive or > other techniques (see Section 10 of [RFC5245] and see [RFC6263]). >=20 >=20 >=20 > Ram >=20 > -----Original Message----- > From: Christer Holmberg > Date: Thursday, 7 May 2015 2:40 pm > To: "Tirumaleswar Reddy (tireddy)" , Cisco Employee = , Alissa Cooper , Martin Thomson = > Cc: "rtcweb@ietf.org" > Subject: RE: [rtcweb] AD evaluation: > draft-ietf-rtcweb-stun-consent-freshness-11 >=20 >> Hi, >>=20 >>>>> Martin=B9s statement says SHOULD here and does not mandate. ICE=20 >>>>> keepalives could also be used to keep the NAT state >>>>=20 >>>> There needs to be a good justification for a SHOULD, and consent = was=20 >>>> never intended for NAT keep-alives. >>>>=20 >>>> Also keep in mind that, with the "virtual connection" concept, = there=20 >>>> might be a big number of ICE connections - some of which you may=20 >>>> never use. Why send consent on those, if there is no media? >>>=20 >>> ICE keepalives or consent is only required for candidate pairs=20 >>> selected for media, >>=20 >> Correct. But, you may have multiple candidate pairs "selected for=20 >> media", but that doesn't mean you are sending media on all of them.=20= >> Very likely you are, at any given time, only sending media on one of = them. >>=20 >>> http://tools.ietf.org/html/rfc5245#section-10 mandates sending=20 >>> keepalives if no packet is sent on the candidate pair ICE is using = for=20 >>> a media component for Tr seconds. STUN Binding Indication or consent=20= >>> can be used for keepalives. >>=20 >> Correct. My issue is why there should be a "SHOULD send consent" on=20= >> candidate pairs currently not used for sending media. In such case,=20= >> only the NAT bindings need to be maintained, and the keep-alives take=20= >> care of that. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Christer Holmberg >>> Date: Wednesday, 6 May 2015 12:23 pm >>> To: Alissa Cooper , Martin Thomson=20 >>> >>> Cc: "rtcweb@ietf.org" >>> Subject: Re: [rtcweb] AD evaluation: >>> draft-ietf-rtcweb-stun-consent-freshness-11 >>>=20 >>>> Hi, >>>>=20 >>>> I don't think you need to continue doing consent because of NAT=20 >>>> issues, if you are sending normal STUN keep-alives. >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alissa=20= >>>> Cooper >>>> Sent: 2. toukokuuta 2015 2:20 >>>> To: Martin Thomson >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] AD evaluation: >>>> draft-ietf-rtcweb-stun-consent-freshness-11 >>>>=20 >>>>=20 >>>> On May 1, 2015, at 9:54 AM, Martin Thomson >>> >>>> wrote: >>>>=20 >>>>> On 30 April 2015 at 17:32, Alissa Cooper = wrote: >>>>>> "An endpoint that is not sending any application data does not=20 >>>>>> need >>> to >>>>>> maintain consent. However, failure to send could cause any NAT = or >>>>>> firewall mappings for the flow to expire. Furthermore, having = one >>>>>> peer unable to send is detrimental to many protocols." >>>>>>=20 >>>>>> It sounds like the unstated implication here is that if you are=20= >>>>>> such an endpoint, you should keep doing consent checks anyway to=20= >>>>>> maintain consent. Should that be stated explicitly, or am I >>> misunderstanding? >>>>>=20 >>>>> Can you tell that this is my text? >>>>>=20 >>>>> Yep, the unspoken implication is that if you stop maintaining=20 >>>>> consent, a flow is highly likely to break. I'm OK with making=20 >>>>> that >>> explicit. >>>>>=20 >>>>> ... . Absent better information about the network, an endpoint=20 >>>>> SHOULD maintain consent if there is any possibility that a flow=20 >>>>> might be needed again. >>>>=20 >>>> WFM >>>>=20 >>>>>=20 >>>>> (Thanks for the suggestion on Sec7. I wasn't happy with it >>>>> before.) >>>>=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 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon May 11 06:53: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 A807F1A8886 for ; Mon, 11 May 2015 06:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.601 X-Spam-Level: X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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_HTML_ATTACH=0.01, 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 Aniewg--02v8 for ; Mon, 11 May 2015 06:53:28 -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 610861A8870 for ; Mon, 11 May 2015 06:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=120100; q=dns/txt; s=iport; t=1431352408; x=1432562008; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dWZ5V3tUMMV7k7A+7gkE//SiBJ7ZyTdY7MyPG1HvOQc=; b=RsbuW/3KDMGnpXRl0fHDuRYHvYipKT/iasE53pXVibm5ASuIGktUA8tU Pyol1p72XWic3nUtAo6aSQkAw57wDKcAkH8hW+BPovqiUKAujL++LvT3E a1xw6YgupxT/VN/GSEBTgwGog+9zmyq9UqGVnpdypSa3a0t9ZEPGPGApo E=; X-Files: Diff_ draft-ietf-rtcweb-stun-consent-freshness-12.txt - draft-ietf-rtcweb-stun-consent-freshness-13.txt.html, draft-ietf-rtcweb-stun-consent-freshness-13.txt : 60333, 18817 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFBQDTs1BV/4kNJK1cgw9UXgaDGIIJvyIqCYE1GQELhTVOAhyBFDgUAQEBAQEBAYEKhCABAQEEAQEBFxMaJwsMBAIBCBEDAQEBARULAQYFAgIfBgsUCQgCBAENBQ4Nh3wDEg2XDJx/BoUYiQYNhRIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizmCTYFVEQEbJQ0CAgEGBgSCWIFLAQSHF4dRg1WCBYIZgkaBdjSBVYEkEyuDHIppgxuDVSOBXQmCEW8BgQICAwICFwIEHIEBAQEB X-IronPort-AV: E=Sophos;i="5.13,407,1427760000"; d="txt'?html'217?scan'217,208,217";a="148864869" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP; 11 May 2015 13:53:26 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4BDrQ18007803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 May 2015 13:53:26 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.121]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 11 May 2015 08:53:26 -0500 From: "Ram Mohan R (rmohanr)" To: Alissa Cooper , Christer Holmberg , Martin Thomson Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQi/HaNRq6SQBuQUqpM992EE341A== Date: Mon, 11 May 2015 13:53:25 +0000 Message-ID: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.38.196] Content-Type: multipart/mixed; boundary="_003_D176B2232E5DCrmohanrciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 13:53:34 -0000 --_003_D176B2232E5DCrmohanrciscocom_ Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 QXR0YWNoZWQgaXMgdGhlIGRpZmZzIHdpdGggY29tbWVudCBmcm9tIENocmlzdGVyIGluY29ycG9y YXRlZC4gUGxlYXNlIGxldA0KbWUga25vdyBpZiBhbnkgb25lIGVsc2UgaGFzIGNvbW1lbnRzLiBJ ZiBub3QgSSB3aWxsIHB1Ymxpc2ggdGhpcyBkaWZmIGFzIGENCm5ldyByZXZpc2lvbi4NCg0KUmVn YXJkcywNClJhbQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxpc3NhIENv b3BlciA8YWxpc3NhQGNvb3BlcncuaW4+DQpEYXRlOiBGcmlkYXksIDggTWF5IDIwMTUgNjo0MSBw bQ0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ DQpDYzogQ2lzY28gRW1wbG95ZWUgPHJtb2hhbnJAY2lzY28uY29tPiwgIlRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSkiDQo8dGlyZWRkeUBjaXNjby5jb20+LCBNYXJ0aW4gVGhvbXNvbiA8bWFy dGluLnRob21zb25AZ21haWwuY29tPiwNCiJydGN3ZWJAaWV0Zi5vcmciIDxydGN3ZWJAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQUQgZXZhbHVhdGlvbjoNCmRyYWZ0LWlldGYtcnRj d2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTENCg0KPk9rIHdpdGggbWUuDQo+QWxpc3NhDQo+ DQo+T24gTWF5IDcsIDIwMTUsIGF0IDI6NDkgQU0sIENocmlzdGVyIEhvbG1iZXJnDQo+PGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+DQo+PiBIaSwNCj4+IA0KPj4gVGhl IHRleHQgbG9va3Mgb2ssIGJ1dCBJIHRoaW5rIHdlIGNhbiBzaW1wbGlmeS9jbGFyaWZ5IGl0IGEg bGl0dGxlLg0KPj4gDQo+PiBGb3IgZXhhbXBsZSwgdGhlIHVzYWdlIG9mICJmbG93IiBpcyBhIGxp dHRsZSBzdHJhbmdlLCBzaW5jZSB3ZQ0KPj5leHBsaWNpdGx5IHNheSB0aGF0IG5vIG1lZGlhIGlz IHNlbnQgOikNCj4+IA0KPj4gQWxzbywgImZhaWx1cmUiIGlzIHRoZSB3cm9uZyB3b3JkaW5nIGlu IG15IG9waW5pb24sIGJlY2F1c2UgdGhlcmUgaXMgbm8NCj4+ZmFpbHVyZS4NCj4+IA0KPj4gV2hh dCBhYm91dDoNCj4+IA0KPj4gICBBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBh cHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90IG5lZWQgdG8NCj4+ICAgbWFpbnRhaW4gY29uc2VudC4g SG93ZXZlciwgbm90IHNlbmRpbmcgYW55IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUIG9yDQo+PiAg IGZpcmV3YWxsIG1hcHBpbmdzIHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lIHBl ZXIgdW5hYmxlIHRvDQo+PnNlbmQgDQo+PiAgIGlzIGRldHJpbWVudGFsIHRvIG1hbnkgcHJvdG9j b2xzLiAgQWJzZW50IGJldHRlciBpbmZvcm1hdGlvbiBhYm91dA0KPj50aGUgDQo+PiAgIG5ldHdv cmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsIG1h cHBpbmdzDQo+PmRvDQo+PiAgIG5vdCBleHBpcmUsIGl0IGNhbiBiZSBkb25lIHVzaW5nIGtlZXBh bGl2ZSBvciAgb3RoZXIgdGVjaG5pcXVlcyAoc2VlDQo+PiAgIFNlY3Rpb24gMTAgb2YgW1JGQzUy NDVdIGFuZCBzZWUgW1JGQzYyNjNdKS4NCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gQ2hyaXN0 ZXINCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUmFt IE1vaGFuIFIgKHJtb2hhbnIpIFttYWlsdG86cm1vaGFuckBjaXNjby5jb21dDQo+PiBTZW50OiA3 LiB0b3Vrb2t1dXRhIDIwMTUgMTI6MTkNCj4+IFRvOiBDaHJpc3RlciBIb2xtYmVyZzsgVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgQWxpc3NhIENvb3BlcjsNCj4+TWFydGluIFRob21zb24N Cj4+IENjOiBydGN3ZWJAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBBRCBldmFs dWF0aW9uOg0KPj5kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTExDQo+ PiANCj4+IEhpIENocmlzdGVyLA0KPj4gDQo+PiBIb3cgYWJvdXQgdGhlIGJlbG93IHRleHQuIERv ZXMgaXQgc291bmQgYmV0dGVyID8NCj4+IA0KPj4gT0xEOg0KPj4gDQo+PiAgIEFuIGVuZHBvaW50 IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0 bw0KPj4gICBtYWludGFpbiBjb25zZW50LiAgSG93ZXZlciwgZmFpbHVyZSB0byBzZW5kIGNvdWxk IGNhdXNlIGFueSBOQVQgb3INCj4+ICAgZmlyZXdhbGwgbWFwcGluZ3MgZm9yIHRoZSBmbG93IHRv IGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lDQo+PiAgIHBlZXIgdW5hYmxlIHRvIHNl bmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBBYnNlbnQgYmV0dGVyDQo+PiAg IGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZXR3b3JrLCBhbiBlbmRwb2ludCBTSE9VTEQgbWFpbnRh aW4gY29uc2VudCBpZg0KPj4gICB0aGVyZSBpcyBhbnkgcG9zc2liaWxpdHkgdGhhdCBhIGZsb3cg bWlnaHQgYmUgbmVlZGVkIGFnYWluLg0KPj4gDQo+PiBORVc6DQo+PiANCj4+ICAgQW4gZW5kcG9p bnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVk IHRvDQo+PiAgIG1haW50YWluIGNvbnNlbnQuIEhvd2V2ZXIsIGZhaWx1cmUgdG8gc2VuZCBjb3Vs ZCBjYXVzZSBhbnkgTkFUIG9yDQo+PiAgIGZpcmV3YWxsIG1hcHBpbmdzIGZvciB0aGUgZmxvdyB0 byBleHBpcmUuICBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZQ0KPj4gICBwZWVyIHVuYWJsZSB0byBz ZW5kIGlzIGRldHJpbWVudGFsIHRvIG1hbnkgcHJvdG9jb2xzLiAgQWJzZW50IGJldHRlcg0KPj4g ICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0d29yaywgaWYgYW4gZW5kcG9pbnQgbmVlZHMgdG8g ZW5zdXJlIGl0cyBOQVQNCj4+ICAgb3IgZmlyZXdhbGwgbWFwcGluZ3MgcGVyc2lzdCB3aGljaCBj YW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3INCj4+ICAgb3RoZXIgdGVjaG5pcXVlcyAoc2Vl IFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS4NCj4+IA0KPj4gDQo+ PiANCj4+IFJhbQ0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTog Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+IERh dGU6IFRodXJzZGF5LCA3IE1heSAyMDE1IDI6NDAgcG0NCj4+IFRvOiAiVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KSIgPHRpcmVkZHlAY2lzY28uY29tPiwgQ2lzY28gRW1wbG95ZWUNCj4+PHJt b2hhbnJAY2lzY28uY29tPiwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+LCBNYXJ0 aW4gVGhvbXNvbg0KPj48bWFydGluLnRob21zb25AZ21haWwuY29tPg0KPj4gQ2M6ICJydGN3ZWJA aWV0Zi5vcmciIDxydGN3ZWJAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSRTogW3J0Y3dlYl0gQUQg ZXZhbHVhdGlvbjoNCj4+IGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3Mt MTENCj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+Pj4+IE1hcnRpbqn2cyBzdGF0ZW1lbnQgc2F5cyBT SE9VTEQgaGVyZSBhbmQgZG9lcyBub3QgbWFuZGF0ZS4gSUNFDQo+Pj4+Pj4ga2VlcGFsaXZlcyBj b3VsZCBhbHNvIGJlIHVzZWQgdG8ga2VlcCB0aGUgTkFUIHN0YXRlDQo+Pj4+PiANCj4+Pj4+IFRo ZXJlIG5lZWRzIHRvIGJlIGEgZ29vZCBqdXN0aWZpY2F0aW9uIGZvciBhIFNIT1VMRCwgYW5kIGNv bnNlbnQgd2FzDQo+Pj4+PiBuZXZlciBpbnRlbmRlZCBmb3IgTkFUIGtlZXAtYWxpdmVzLg0KPj4+ Pj4gDQo+Pj4+PiBBbHNvIGtlZXAgaW4gbWluZCB0aGF0LCB3aXRoIHRoZSAidmlydHVhbCBjb25u ZWN0aW9uIiBjb25jZXB0LCB0aGVyZQ0KPj4+Pj4gbWlnaHQgYmUgYSBiaWcgbnVtYmVyIG9mIElD RSBjb25uZWN0aW9ucyAtIHNvbWUgb2Ygd2hpY2ggeW91IG1heQ0KPj4+Pj4gbmV2ZXIgdXNlLiBX aHkgc2VuZCBjb25zZW50IG9uIHRob3NlLCBpZiB0aGVyZSBpcyBubyBtZWRpYT8NCj4+Pj4gDQo+ Pj4+IElDRSBrZWVwYWxpdmVzIG9yIGNvbnNlbnQgaXMgb25seSByZXF1aXJlZCBmb3IgY2FuZGlk YXRlIHBhaXJzDQo+Pj4+IHNlbGVjdGVkIGZvciBtZWRpYSwNCj4+PiANCj4+PiBDb3JyZWN0LiBC dXQsIHlvdSBtYXkgaGF2ZSBtdWx0aXBsZSBjYW5kaWRhdGUgcGFpcnMgInNlbGVjdGVkIGZvcg0K Pj4+IG1lZGlhIiwgYnV0IHRoYXQgZG9lc24ndCBtZWFuIHlvdSBhcmUgc2VuZGluZyBtZWRpYSBv biBhbGwgb2YgdGhlbS4NCj4+PiBWZXJ5IGxpa2VseSB5b3UgYXJlLCBhdCBhbnkgZ2l2ZW4gdGlt ZSwgb25seSBzZW5kaW5nIG1lZGlhIG9uIG9uZSBvZg0KPj4+dGhlbS4NCj4+PiANCj4+Pj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTEwIG1hbmRhdGVzIHNlbmRp bmcNCj4+Pj4ga2VlcGFsaXZlcyBpZiBubyBwYWNrZXQgaXMgc2VudCBvbiB0aGUgY2FuZGlkYXRl IHBhaXIgSUNFIGlzIHVzaW5nDQo+Pj4+Zm9yIA0KPj4+PiBhIG1lZGlhIGNvbXBvbmVudCBmb3Ig VHIgc2Vjb25kcy4gU1RVTiBCaW5kaW5nIEluZGljYXRpb24gb3IgY29uc2VudA0KPj4+PiBjYW4g YmUgdXNlZCBmb3Iga2VlcGFsaXZlcy4NCj4+PiANCj4+PiBDb3JyZWN0LiBNeSBpc3N1ZSBpcyB3 aHkgdGhlcmUgc2hvdWxkIGJlIGEgIlNIT1VMRCBzZW5kIGNvbnNlbnQiIG9uDQo+Pj4gY2FuZGlk YXRlIHBhaXJzIGN1cnJlbnRseSBub3QgdXNlZCBmb3Igc2VuZGluZyBtZWRpYS4gSW4gc3VjaCBj YXNlLA0KPj4+IG9ubHkgdGhlIE5BVCBiaW5kaW5ncyBuZWVkIHRvIGJlIG1haW50YWluZWQsIGFu ZCB0aGUga2VlcC1hbGl2ZXMgdGFrZQ0KPj4+IGNhcmUgb2YgdGhhdC4NCj4+PiANCj4+PiBSZWdh cmRzLA0KPj4+IA0KPj4+IENocmlzdGVyDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+Pj4+IERhdGU6IFdlZG5lc2RheSwgNiBNYXkgMjAx NSAxMjoyMyBwbQ0KPj4+PiBUbzogQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+LCBN YXJ0aW4gVGhvbXNvbg0KPj4+PiA8bWFydGluLnRob21zb25AZ21haWwuY29tPg0KPj4+PiBDYzog InJ0Y3dlYkBpZXRmLm9yZyIgPHJ0Y3dlYkBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFty dGN3ZWJdIEFEIGV2YWx1YXRpb246DQo+Pj4+IGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2Vu dC1mcmVzaG5lc3MtMTENCj4+Pj4gDQo+Pj4+PiBIaSwNCj4+Pj4+IA0KPj4+Pj4gSSBkb24ndCB0 aGluayB5b3UgbmVlZCB0byBjb250aW51ZSBkb2luZyBjb25zZW50IGJlY2F1c2Ugb2YgTkFUDQo+ Pj4+PiBpc3N1ZXMsIGlmIHlvdSBhcmUgc2VuZGluZyBub3JtYWwgU1RVTiBrZWVwLWFsaXZlcy4N Cj4+Pj4+IA0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+IA0KPj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+IA0K Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IHJ0Y3dlYiBbbWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxpc3NhDQo+Pj4+PiBD b29wZXINCj4+Pj4+IFNlbnQ6IDIuIHRvdWtva3V1dGEgMjAxNSAyOjIwDQo+Pj4+PiBUbzogTWFy dGluIFRob21zb24NCj4+Pj4+IENjOiBydGN3ZWJAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJl OiBbcnRjd2ViXSBBRCBldmFsdWF0aW9uOg0KPj4+Pj4gZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1j b25zZW50LWZyZXNobmVzcy0xMQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE9uIE1heSAxLCAyMDE1 LCBhdCA5OjU0IEFNLCBNYXJ0aW4gVGhvbXNvbg0KPj4+PiA8bWFydGluLnRob21zb25AZ21haWwu Y29tPg0KPj4+Pj4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+PiBPbiAzMCBBcHJpbCAyMDE1IGF0IDE3 OjMyLCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4gd3JvdGU6DQo+Pj4+Pj4+ICJB biBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMg bm90DQo+Pj4+Pj4+IG5lZWQNCj4+Pj4gdG8NCj4+Pj4+Pj4gIG1haW50YWluIGNvbnNlbnQuICBI b3dldmVyLCBmYWlsdXJlIHRvIHNlbmQgY291bGQgY2F1c2UgYW55IE5BVCBvcg0KPj4+Pj4+PiAg ZmlyZXdhbGwgbWFwcGluZ3MgZm9yIHRoZSBmbG93IHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBo YXZpbmcgb25lDQo+Pj4+Pj4+ICBwZWVyIHVuYWJsZSB0byBzZW5kIGlzIGRldHJpbWVudGFsIHRv IG1hbnkgcHJvdG9jb2xzLiINCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEl0IHNvdW5kcyBsaWtlIHRoZSB1 bnN0YXRlZCBpbXBsaWNhdGlvbiBoZXJlIGlzIHRoYXQgaWYgeW91IGFyZQ0KPj4+Pj4+PiBzdWNo IGFuIGVuZHBvaW50LCB5b3Ugc2hvdWxkIGtlZXAgZG9pbmcgY29uc2VudCBjaGVja3MgYW55d2F5 IHRvDQo+Pj4+Pj4+IG1haW50YWluIGNvbnNlbnQuIFNob3VsZCB0aGF0IGJlIHN0YXRlZCBleHBs aWNpdGx5LCBvciBhbSBJDQo+Pj4+IG1pc3VuZGVyc3RhbmRpbmc/DQo+Pj4+Pj4gDQo+Pj4+Pj4g Q2FuIHlvdSB0ZWxsIHRoYXQgdGhpcyBpcyBteSB0ZXh0Pw0KPj4+Pj4+IA0KPj4+Pj4+IFllcCwg dGhlIHVuc3Bva2VuIGltcGxpY2F0aW9uIGlzIHRoYXQgaWYgeW91IHN0b3AgbWFpbnRhaW5pbmcN Cj4+Pj4+PiBjb25zZW50LCBhIGZsb3cgaXMgaGlnaGx5IGxpa2VseSB0byBicmVhay4gIEknbSBP SyB3aXRoIG1ha2luZw0KPj4+Pj4+IHRoYXQNCj4+Pj4gZXhwbGljaXQuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gLi4uIC4gIEFic2VudCBiZXR0ZXIgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5ldHdvcmssIGFu IGVuZHBvaW50DQo+Pj4+Pj4gU0hPVUxEIG1haW50YWluIGNvbnNlbnQgaWYgdGhlcmUgaXMgYW55 IHBvc3NpYmlsaXR5IHRoYXQgYSBmbG93DQo+Pj4+Pj4gbWlnaHQgYmUgbmVlZGVkIGFnYWluLg0K Pj4+Pj4gDQo+Pj4+PiBXRk0NCj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IChUaGFua3MgZm9yIHRo ZSBzdWdnZXN0aW9uIG9uIFNlYzcuICBJIHdhc24ndCBoYXBweSB3aXRoIGl0DQo+Pj4+Pj4gYmVm b3JlLikNCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+Pj4+IHJ0Y3dlYkBpZXRm Lm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0K Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+Pj4g DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+Pj4gcnRjd2ViQGlldGYub3JnDQo+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+PiANCj4NCg0K --_003_D176B2232E5DCrmohanrciscocom_ Content-Type: text/html; name="Diff_ draft-ietf-rtcweb-stun-consent-freshness-12.txt - draft-ietf-rtcweb-stun-consent-freshness-13.txt.html" Content-Description: Diff_ draft-ietf-rtcweb-stun-consent-freshness-12.txt - draft-ietf-rtcweb-stun-consent-freshness-13.txt.html Content-Disposition: attachment; filename="Diff_ draft-ietf-rtcweb-stun-consent-freshness-12.txt - draft-ietf-rtcweb-stun-consent-freshness-13.txt.html"; size=60333; creation-date="Mon, 11 May 2015 13:53:25 GMT"; modification-date="Mon, 11 May 2015 13:53:25 GMT" Content-ID: <4B76EEDB3BB22D45BCD048E9CBA685C1@emea.cisco.com> Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIEdlbmVyYXRlZCBieSByZmNkaWZmIDEuNDI6IHJmY2RpZmYgIC0tPgo8IS0t IDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRpb25h bCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGdhbWF5IDIuNi4zOS0yLTY4Ni1wYWUgIzEgU01Q IFR1ZSBKdWwgNSAwMzo0ODo0OSBVVEMgMjAxMSBpNjg2IEdOVS9MaW51eCAtLT4KPCEtLSBVc2lu ZyBhd2s6IC91c3IvYmluL2dhd2s6IEdOVSBBd2sgNC4wLjEgLS0+CjwhLS0gVXNpbmcgZGlmZjog L3Vzci9iaW4vZGlmZjogZGlmZiAoR05VIGRpZmZ1dGlscykgMy4zIC0tPgo8IS0tIFVzaW5nIHdk aWZmOiAvdXNyL2Jpbi93ZGlmZjogd2RpZmYgKEdOVSB3ZGlmZikgMS4yLjEgLS0+CjxodG1sPjxo ZWFkPiAKICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRt bDsgY2hhcnNldD1VVEYtOCI+IAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUtVHlw ZSIgY29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1ydGN3ZWIt c3R1bi1jb25zZW50LWZyZXNobmVzcy0xMi50eHQgLSBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNv bnNlbnQtZnJlc2huZXNzLTEzLnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgPC9zdHlsZT4gCjwvaGVhZD4gCjxib2R5PiAKICA8dGFi bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+ PHRyIGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNo bmVzcy0xMi50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZs dDs8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTIudHh0IiBzdHlsZT0iY29sb3I6IzAw OCI+ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMi50eHQ8L2E+Jm5i c3A7PC90aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEzLnR4dCIg c3R5bGU9ImNvbG9yOiMwMDgiPmRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5l c3MtMTMudHh0PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDE9ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMy50eHQiIHN0 eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+ PC90aD48L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5SVENXRUIg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0u IFBlcnVtYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5SVENXRUIgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIFBlcnVtYWw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEVyaWNzc29uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVyaWNz c29uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRC4gV2luZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVuZGVk IHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RC4gV2luZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDEiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4 cGlyZXM6IE5vdmVtYmVyIDxzcGFuIGNsYXNzPSJkZWxldGUiPjUsIDIwMTUgPC9zcGFuPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBSYXZpbmRyYW5hdGg8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+RXhwaXJlczogTm92ZW1iZXIgPHNwYW4gY2xhc3M9Imluc2VydCI+ MTIsIDIwMTU8L3NwYW4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIFJhdmluZHJh bmF0aDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVC4gUmVkZHk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VC4gUmVkZHk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDaXNjbyBTeXN0ZW1zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBD aXNjbyBTeXN0ZW1zPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTS4gVGhvbXNvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTS4gVGhvbXNvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE1vemlsbGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE1vemlsbGE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDAyIj48L2E+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4gTWF5IDQ8L3NwYW4+LCAyMDE1PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPk1h eSAxMTwvc3Bhbj4sIDIwMTU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3M8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNl bnQgRnJlc2huZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwMyI+PC9hPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAgICBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNz LTE8c3BhbiBjbGFzcz0iZGVsZXRlIj4yPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVz aG5lc3MtMTxzcGFuIGNsYXNzPSJpbnNlcnQiPjM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij5BYnN0cmFjdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkFic3RyYWN0 PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUbyBwcmV2ZW50IHNlbmRpbmcgZXhjZXNz aXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNlbnQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUbyBwcmV2ZW50IHNlbmRpbmcgZXhjZXNzaXZlIHRyYWZm aWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNlbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbmVlZHMgdG8gYmUgb2J0YWluZWQg ZnJvbSB0aGF0IHJlbW90ZSBlbmRwb2ludC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBuZWVkcyB0byBiZSBvYnRhaW5lZCBmcm9tIHRoYXQgcmVtb3RlIGVuZHBvaW50LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjb25z ZW50IG1lY2hhbmlzbSB1c2luZyBhIG5ldyBTZXNzaW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBjb25zZW50IG1lY2hhbmlzbSB1 c2luZyBhIG5ldyBTZXNzaW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikgdXNh Z2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVHJhdmVyc2FsIFV0aWxpdGll cyBmb3IgTkFUIChTVFVOKSB1c2FnZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlN0YXR1 cyBvZiBUaGlzIE1lbW88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5TdGF0dXMgb2Yg VGhpcyBNZW1vPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRkPjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQt bDIiPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5l IDM5PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjIiPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5lIDM5PC9lbT48L2E+ PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkg YWxzbyBkaXN0cmlidXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kcmFmdHMvY3VycmVudC8uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRHJh ZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2 YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBs YWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3By aWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRl cm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9n cmVzcy4iPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAw MDQiPjwvYT48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gTm92ZW1iZXIgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj4sIDIwMTUuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2ls bCBleHBpcmUgb24gTm92ZW1iZXIgPHNwYW4gY2xhc3M9Imluc2VydCI+MTI8L3NwYW4+LCAyMDE1 LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIENvcHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29u cyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENv cHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNl cnZlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFu ZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm92aXNpb25zIFJlbGF0 aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWlu Zm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBv biB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmll dyB0aGVzZSBkb2N1bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwdWJs aWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBiZ2NvbG9yPSJncmF5Ij48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sMyI+PHNtYWxs PnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUsIGxpbmUgMTk8L2VtPjwv YT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMyI+PHNtYWxsPnNraXBwaW5nIHRv IGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDUsIGxpbmUgMTk8L2VtPjwvYT48L3RoPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgV2hpbGUg VENQIGFmZm9yZHMgc29tZSBwcm90ZWN0aW9uIGZyb20gb2ZmLXBhdGggYXR0YWNrZXJzIChbUkZD NTk2MV0sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgV2hpbGUgVENQIGFmZm9y ZHMgc29tZSBwcm90ZWN0aW9uIGZyb20gb2ZmLXBhdGggYXR0YWNrZXJzIChbUkZDNTk2MV0sPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtS RkM0OTUzXSksIHRoZXJlIGlzIHN0aWxsIGEgcmlzayBhbiBhdHRhY2tlciBjb3VsZCBjYXVzZSBh IFRDUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM0OTUzXSksIHRoZXJl IGlzIHN0aWxsIGEgcmlzayBhbiBhdHRhY2tlciBjb3VsZCBjYXVzZSBhIFRDUDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzZW5kZXIgdG8g c2VuZCBmb3JldmVyIGJ5IHNwb29maW5nIEFDS3MuICBUbyBwcmV2ZW50IHN1Y2ggYW4gYXR0YWNr LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNlbmRlciB0byBzZW5kIGZvcmV2 ZXIgYnkgc3Bvb2ZpbmcgQUNLcy4gIFRvIHByZXZlbnQgc3VjaCBhbiBhdHRhY2ssPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbnNlbnQg Y2hlY2tzIE1VU1QgYmUgcGVyZm9ybWVkIG92ZXIgYWxsIHRyYW5zcG9ydCBjb25uZWN0aW9ucyw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjb25zZW50IGNoZWNrcyBNVVNUIGJl IHBlcmZvcm1lZCBvdmVyIGFsbCB0cmFuc3BvcnQgY29ubmVjdGlvbnMsPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluY2x1ZGluZyBUQ1Au ICBJbiB0aGlzIHdheSwgYW4gb2ZmLXBhdGggYXR0YWNrZXIgc3Bvb2ZpbmcgVENQPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW5jbHVkaW5nIFRDUC4gIEluIHRoaXMgd2F5LCBh biBvZmYtcGF0aCBhdHRhY2tlciBzcG9vZmluZyBUQ1A8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2VnbWVudHMgY2FuIG5vdCBjYXVzZSBh IFRDUCBzZW5kZXIgdG8gc2VuZCBvbmNlIHRoZSBjb25zZW50IHRpbWVyPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgc2VnbWVudHMgY2FuIG5vdCBjYXVzZSBhIFRDUCBzZW5kZXIg dG8gc2VuZCBvbmNlIHRoZSBjb25zZW50IHRpbWVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4cGlyZXMgKDMwIHNlY29uZHMpLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGV4cGlyZXMgKDMwIHNlY29uZHMpLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGlu ZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBw bGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNSI+PC9h PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbWFpbnRhaW4gY29uc2VudC4gIEhvd2V2ZXIsIDxzcGFu IGNsYXNzPSJkZWxldGUiPmZhaWx1cmUgdG8gc2VuZDwvc3Bhbj4gY291bGQgY2F1c2UgPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+YW55PC9zcGFuPiBOQVQgb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgbWFpbnRhaW4gY29uc2VudC4gIEhvd2V2ZXIsIDxzcGFuIGNsYXNzPSJpbnNl cnQiPm5vdCBzZW5kaW5nIGFueSB0cmFmZmljPC9zcGFuPiBjb3VsZCBjYXVzZSBOQVQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBmaXJl d2FsbCBtYXBwaW5ncyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5mb3IgdGhlIGZsb3c8L3NwYW4+IHRv IGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIG9yIGZpcmV3YWxsIG1hcHBpbmdzIHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3Jl LCBoYXZpbmcgb25lIHBlZXIgdW5hYmxlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcGVlciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1l bnRhbCB0byBtYW55IHByb3RvY29scy4gIEFic2VudCBiZXR0ZXI8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+ICAgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29s cy4gIEFic2VudCBiZXR0ZXIgaW5mb3JtYXRpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0 d29yaywgYW4gZW5kcG9pbnQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+U0hPVUxEIG1haW50YWluIGNv bnNlbnQgaWY8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFib3V0 IHRoZSBuZXR3b3JrLCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5pZjwvc3Bhbj4gYW4gZW5kcG9pbnQg PHNwYW4gY2xhc3M9Imluc2VydCI+bmVlZHMgdG8gZW5zdXJlIGl0cyBOQVQgb3IgZmlyZXdhbGw8 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgdGhlcmUgaXMgYW55IHBvc3NpYmlsaXR5IHRo YXQgYSBmbG93IG1pZ2h0PC9zcGFuPiBiZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5uZWVkZWQgYWdh aW4uPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW48L3NwYW4+IGJlIDxzcGFu IGNsYXNzPSJpbnNlcnQiPmRvbmUgdXNpbmcga2VlcGFsaXZlIG9yIG90aGVyPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB0ZWNo bmlxdWVzIChzZWUgU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0gYW5kIHNlZSBbUkZDNjI2M10pLjwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFmdGVyIGNvbnNlbnQgaXMgbG9z dCBmb3IgYW55IHJlYXNvbiwgdGhlIHNhbWUgSUNFIGNyZWRlbnRpYWxzIE1VU1Q8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBZnRlciBjb25zZW50IGlzIGxvc3QgZm9yIGFueSBy ZWFzb24sIHRoZSBzYW1lIElDRSBjcmVkZW50aWFscyBNVVNUPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE5PVCBiZSB1c2VkIG9uIHRoZSBh ZmZlY3RlZCA1LXR1cGxlIGFnYWluLiAgVGhhdCBtZWFucyB0aGF0IGEgbmV3PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgTk9UIGJlIHVzZWQgb24gdGhlIGFmZmVjdGVkIDUtdHVw bGUgYWdhaW4uICBUaGF0IG1lYW5zIHRoYXQgYSBuZXc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc2Vzc2lvbiwgb3IgYW4gSUNFIHJlc3Rh cnQsIGlzIG5lZWRlZCB0byBvYnRhaW4gY29uc2VudCB0byBzZW5kLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIHNlc3Npb24sIG9yIGFuIElDRSByZXN0YXJ0LCBpcyBuZWVkZWQg dG8gb2J0YWluIGNvbnNlbnQgdG8gc2VuZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQu Mi4gIEltbWVkaWF0ZSBSZXZvY2F0aW9uIG9mIENvbnNlbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij40LjIuICBJbW1lZGlhdGUgUmV2b2NhdGlvbiBvZiBDb25zZW50PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbiBzb21lIGNhc2VzIGl0IGlzIHVzZWZ1bCB0byBzaWdu YWwgdGhhdCBjb25zZW50IGlzIHRlcm1pbmF0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBJbiBzb21lIGNhc2VzIGl0IGlzIHVzZWZ1bCB0byBzaWduYWwgdGhhdCBjb25zZW50 IGlzIHRlcm1pbmF0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgcmF0aGVyIHRoYW4gcmVseWluZyBvbiBhIHRpbWVvdXQuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmF0aGVyIHRoYW4gcmVseWluZyBvbiBhIHRpbWVv dXQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4K ICAgICA8dHIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxh IG5hbWU9ImVuZCI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDUgY2hhbmdlIGJsb2Nrcy4mbmJzcDs8 L2E+PC90aD48L3RyPgogICAgIDx0ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT45IGxp bmVzIGNoYW5nZWQgb3IgZGVsZXRlZDwvaT48L3RoPjx0aD48aT4gPC9pPjwvdGg+PHRoPjxpPjEw IGxpbmVzIGNoYW5nZWQgb3IgYWRkZWQ8L2k+PC90aD48dGQ+PC90ZD48L3RyPgogICAgIDx0cj48 dGQgY29sc3Bhbj0iNSIgY2xhc3M9InNtYWxsIiBhbGlnbj0iY2VudGVyIj48YnI+VGhpcyBodG1s IGRpZmYgd2FzIHByb2R1Y2VkIGJ5IHJmY2RpZmYgMS40Mi4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMv cmZjZGlmZi8iPmh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48 L3RyPgogICA8L3Rib2R5PjwvdGFibGU+CiAgIAogICAKWC1HZW5lcmF0b3I6IHB5aHQgMC4zNQoK PCEtLSBhcmdzOiB7Jy0tb2xkY29sb3VyJzogJ3JlZCcsICctLXdpZHRoJzogJycsICdkaWZmdHlw ZSc6ICctLWh0bWwnLCAnZmlsZW5hbWUyJzogJ1xuXG5cblxuUlRDV0VCICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBQZXJ1bWFsXG5JbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRXJpY3Nzb25cbkludGVuZGVkIHN0YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRC4gV2luZ1xuRXhwaXJlczogTm92ZW1iZXIgMTIsIDIwMTUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gUmF2aW5kcmFuYXRoXG4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4g UmVkZHlcbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQ2lzY28gU3lzdGVtc1xuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBUaG9tc29uXG4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vemlsbGFc biAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE1heSAxMSwgMjAxNVxuXG5cbiAgICAgICAgICAgICAgICAgICAgU1RVTiBVc2FnZSBmb3Ig Q29uc2VudCBGcmVzaG5lc3NcbiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1j b25zZW50LWZyZXNobmVzcy0xM1xuXG5BYnN0cmFjdFxuXG4gICBUbyBwcmV2ZW50IHNlbmRpbmcg ZXhjZXNzaXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNlbnRcbiAgIG5l ZWRzIHRvIGJlIG9idGFpbmVkIGZyb20gdGhhdCByZW1vdGUgZW5kcG9pbnQuXG5cbiAgIFRoaXMg ZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29uc2VudCBtZWNoYW5pc20gdXNpbmcgYSBuZXcgU2Vzc2lv blxuICAgVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKSB1c2FnZS5cblxuU3RhdHVz IG9mIFRoaXMgTWVtb1xuXG4gICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBm dWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlXG4gICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQ IDc5LlxuXG4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJ bnRlcm5ldCBFbmdpbmVlcmluZ1xuICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3Ro ZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGVcbiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIElu dGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtXG4gICBEcmFmdHMg aXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly5cblxuICAg SW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBv ZiBzaXggbW9udGhzXG4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0 ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueVxuICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlh dGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2VcbiAgIG1hdGVyaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiJcblxuICAgVGhpcyBJ bnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBOb3ZlbWJlciAxMiwgMjAxNS5cblxuQ29weXJp Z2h0IE5vdGljZVxuXG4gICBDb3B5cmlnaHQgKGMpIDIwMTUgSUVURiBUcnVzdCBhbmQgdGhlIHBl cnNvbnMgaWRlbnRpZmllZCBhcyB0aGVcbiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRz IHJlc2VydmVkLlxuXG4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0 aGUgSUVURiBUcnVzdFwncyBMZWdhbFxuICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv Y3VtZW50c1xuICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mXG4gICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxl YXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHNcblxuXG5cblBlcnVtYWwsIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgTm92ZW1iZXIgMTIsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSAxXVxuX1xuSW50 ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAg ICAgIE1heSAyMDE1XG5cblxuICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmln aHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0XG4gICB0byB0aGlzIGRvY3VtZW50LiAg Q29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdFxuICAgaW5j bHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NC5lIG9mXG4gICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdp dGhvdXQgd2FycmFudHkgYXNcbiAgIGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGlj ZW5zZS5cblxuVGFibGUgb2YgQ29udGVudHNcblxuICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyXG4gICAyLiAgVGVy bWlub2xvZ3kgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDNcbiAgIDMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgM1xuICAgNC4gIFNvbHV0aW9uICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzXG4gICAgIDQuMS4gIEV4cGly YXRpb24gb2YgQ29uc2VudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDNc biAgICAgNC4yLiAgSW1tZWRpYXRlIFJldm9jYXRpb24gb2YgQ29uc2VudCAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNVxuICAgNS4gIERpZmZTZXJ2IFRyZWF0bWVudCBmb3IgQ29uc2VudCAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2XG4gICA2LiAgRFRMUyBhcHBsaWNhYmls aXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZcbiAgIDcu ICBBUEkgUmVjb21tZW5kYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNlxuICAgOC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2XG4gICA5LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZcbiAgIDEwLiBBY2tu b3dsZWRnZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgN1xuICAgMTEuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA3XG4gICAgIDExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDdcbiAgICAgMTEuMi4gIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgN1xu ICAgQXV0aG9yc1wnIEFkZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgOFxuXG4xLiAgSW50cm9kdWN0aW9uXG5cbiAgIFRvIHByZXZlbnQgYXR0 YWNrcyBvbiBwZWVycywgZW5kcG9pbnRzIGhhdmUgdG8gZW5zdXJlIHRoZSByZW1vdGUgcGVlclxu ICAgaXMgd2lsbGluZyB0byByZWNlaXZlIHRyYWZmaWMuICBUaGlzIGlzIHBlcmZvcm1lZCBib3Ro IHdoZW4gdGhlXG4gICBzZXNzaW9uIGlzIGZpcnN0IGVzdGFibGlzaGVkIHRvIHRoZSByZW1vdGUg cGVlciB1c2luZyBJbnRlcmFjdGl2ZVxuICAgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgSUNF IFtSRkM1MjQ1XSBjb25uZWN0aXZpdHkgY2hlY2tzLCBhbmRcbiAgIHBlcmlvZGljYWxseSBmb3Ig dGhlIGR1cmF0aW9uIG9mIHRoZSBzZXNzaW9uIHVzaW5nIHRoZSBwcm9jZWR1cmVzXG4gICBkZWZp bmVkIGluIHRoaXMgZG9jdW1lbnQuXG5cbiAgIFdoZW4gYSBzZXNzaW9uIGlzIGZpcnN0IGVzdGFi bGlzaGVkLCBJQ0UgaW1wbGVtZW50YXRpb25zIG9idGFpbiBhblxuICAgaW5pdGlhbCBjb25zZW50 IHRvIHNlbmQgYnkgcGVyZm9ybWluZyBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3MuICBUaGlzXG4g ICBkb2N1bWVudCBkZXNjcmliZXMgYSBuZXcgU1RVTiB1c2FnZSB3aXRoIGV4Y2hhbmdlIG9mIHJl cXVlc3QgYW5kXG4gICByZXNwb25zZSBtZXNzYWdlcyB0aGF0IHZlcmlmaWVzIHRoZSByZW1vdGUg cGVlclwncyBvbmdvaW5nIGNvbnNlbnQgdG9cbiAgIHJlY2VpdmUgdHJhZmZpYy4gIFRoaXMgY29u c2VudCBleHBpcmVzIGFmdGVyIGEgcGVyaW9kIG9mIHRpbWUgYW5kXG4gICBuZWVkcyB0byBiZSBj b250aW51YWxseSByZW5ld2VkLCB3aGljaCBlbnN1cmVzIHRoYXQgY29uc2VudCBjYW4gYmVcbiAg IHRlcm1pbmF0ZWQuXG5cbiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB3aGF0IGl0IHRha2VzIHRv IG9idGFpbiwgbWFpbnRhaW4sIGFuZCBsb3NlXG4gICBjb25zZW50IHRvIHNlbmQuICBDb25zZW50 IHRvIHNlbmQgYXBwbGllcyB0byBhIHNpbmdsZSA1LXR1cGxlLiAgSG93XG4gICBhcHBsaWNhdGlv bnMgcmVhY3QgdG8gY2hhbmdlcyBpbiBjb25zZW50IGlzIG5vdCBkZXNjcmliZWQgaW4gdGhpc1xu ICAgZG9jdW1lbnQuXG5cblxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBO b3ZlbWJlciAxMiwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDJdXG5fXG5JbnRlcm5ldC1EcmFm dCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgICAgICAgTWF5IDIw MTVcblxuXG4gICBDb25zZW50IGlzIG9idGFpbmVkIG9ubHkgYnkgZnVsbCBJQ0UgaW1wbGVtZW50 YXRpb25zLiAgQW4gSUNFLWxpdGVcbiAgIGltcGxlbWVudGF0aW9uIHdpbGwgbm90IGdlbmVyYXRl IGNvbnNlbnQgY2hlY2tzLCBidXQgd2lsbCBqdXN0XG4gICByZXNwb25kIHRvIGNvbnNlbnQgY2hl Y2tzIGl0IHJlY2VpdmVzLiAgTm8gY2hhbmdlcyBhcmUgcmVxdWlyZWQgdG9cbiAgIElDRS1saXRl IGltcGxlbWVudGF0aW9ucyBpbiBvcmRlciB0byByZXNwb25kIHRvIGNvbnNlbnQgY2hlY2tzLCBh c1xuICAgdGhleSBhcmUgcHJvY2Vzc2VkIGFzIG5vcm1hbCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNr cy5cblxuMi4gIFRlcm1pbm9sb2d5XG5cbiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIixcbiAgICJTSE9VTEQiLCAiU0hP VUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzXG4g ICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5 XS5cblxuICAgQ29uc2VudDogIFRoZSBtZWNoYW5pc20gb2Ygb2J0YWluaW5nIHBlcm1pc3Npb24g dG8gc2VuZCB0byBhIHJlbW90ZVxuICAgICAgdHJhbnNwb3J0IGFkZHJlc3MuICBJbml0aWFsIGNv bnNlbnQgaXMgb2J0YWluZWQgdXNpbmcgSUNFLlxuXG4gICBDb25zZW50IEZyZXNobmVzczogIE1h aW50YWluaW5nIGFuZCByZW5ld2luZyBjb25zZW50IG92ZXIgdGltZS5cblxuICAgVHJhbnNwb3J0 IEFkZHJlc3M6ICBUaGUgcmVtb3RlIHBlZXJcJ3MgSVAgYWRkcmVzcyBhbmQgVURQIG9yIFRDUCBw b3J0XG4gICAgICBudW1iZXIuXG5cbjMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnNcblxuICAgQWx0 aG91Z2ggSUNFIHJlcXVpcmVzIHBlcmlvZGljIGtlZXBhbGl2ZSB0cmFmZmljIHRvIGtlZXAgTkFU IGJpbmRpbmdzXG4gICBhbGl2ZSAoU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0sIFtSRkM2MjYzXSks IHRob3NlIGtlZXBhbGl2ZXMgYXJlIHNlbnRcbiAgIGFzIFNUVU4gSW5kaWNhdGlvbnMgd2hpY2gg YXJlIHNlbmQtYW5kLWZvcmdldCwgYW5kIGRvIG5vdCBldm9rZSBhXG4gICByZXNwb25zZS4gIEEg cmVzcG9uc2UgaXMgbmVjZXNzYXJ5IGZvciBjb25zZW50IHRvIGNvbnRpbnVlIHNlbmRpbmdcbiAg IHRyYWZmaWMuICBUaHVzLCB3ZSBuZWVkIGEgcmVxdWVzdC9yZXNwb25zZSBtZWNoYW5pc20gZm9y IGNvbnNlbnRcbiAgIGZyZXNobmVzcy4gIElDRSBjYW4gYmUgdXNlZCBmb3IgdGhhdCBtZWNoYW5p c20gYmVjYXVzZSBJQ0VcbiAgIGltcGxlbWVudGF0aW9ucyBhcmUgYWxyZWFkeSByZXF1aXJlZCB0 byBjb250aW51ZSBsaXN0ZW5pbmcgZm9yIElDRVxuICAgbWVzc2FnZXMsIGFzIGRlc2NyaWJlZCBp biBzZWN0aW9uIDEwIG9mIFtSRkM1MjQ1XS4gIElmIGNvbnNlbnQgaXNcbiAgIHBlcmZvcm1lZCB0 aGVuIHRoZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBrZWVwYWxpdmUgbWVzc2FnZXMuXG5cbjQuICBT b2x1dGlvblxuXG4gICBUaGVyZSBhcmUgdHdvIHdheXMgY29uc2VudCB0byBzZW5kIHRyYWZmaWMg aXMgcmV2b2tlZDogZXhwaXJhdGlvbiBvZlxuICAgY29uc2VudCBhbmQgaW1tZWRpYXRlIHJldm9j YXRpb24gb2YgY29uc2VudCwgd2hpY2ggYXJlIGRpc2N1c3NlZCBpblxuICAgdGhlIGZvbGxvd2lu ZyBzZWN0aW9ucy5cblxuNC4xLiAgRXhwaXJhdGlvbiBvZiBDb25zZW50XG5cbiAgIEEgZnVsbCBJ Q0UgaW1wbGVtZW50YXRpb24gcGVyZm9ybXMgY29uc2VudCBmcmVzaG5lc3MgdGVzdCB1c2luZyBT VFVOXG4gICByZXF1ZXN0L3Jlc3BvbnNlIGFzIGRlc2NyaWJlZCBiZWxvdzpcblxuICAgQW4gZW5k cG9pbnQgTVVTVCBOT1Qgc2VuZCBkYXRhIG90aGVyIHRoYW4gcGFjZWQgU1RVTiBjb25uZWN0aXZp dHlcbiAgIGNoZWNrcyBvciByZXNwb25zZXMgdG93YXJkIGFueSB0cmFuc3BvcnQgYWRkcmVzcyB1 bmxlc3MgdGhlIHJlY2VpdmluZ1xuICAgZW5kcG9pbnQgY29uc2VudHMgdG8gcmVjZWl2ZSBkYXRh LiAgVGhhdCBpcywgbm8gYXBwbGljYXRpb24gZGF0YVxuICAgKGUuZy4sIFJUUCBvciBEVExTKSBj YW4gYmUgc2VudCB1bnRpbCBjb25zZW50IGlzIG9idGFpbmVkLiAgQWZ0ZXIgYVxuICAgc3VjY2Vz c2Z1bCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrIG9uIGEgcGFydGljdWxhciB0cmFuc3BvcnQgYWRk cmVzcyxcblxuXG5cblBlcnVtYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTIs IDIwMTUgICAgICAgICAgICAgICBbUGFnZSAzXVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICBTVFVO IFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1XG5cblxuICAg Y29uc2VudCBNVVNUIGJlIG1haW50YWluZWQgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmUgZGVzY3Jp YmVkIGluIHRoaXNcbiAgIGRvY3VtZW50LlxuXG4gICBFeHBsaWNpdCBjb25zZW50IHRvIHNlbmQg aXMgb2J0YWluZWQgYW5kIG1haW50YWluZWQgYnkgc2VuZGluZyBhblxuICAgU1RVTiBiaW5kaW5n IHJlcXVlc3QgdG8gdGhlIHJlbW90ZSBwZWVyXCdzIHRyYW5zcG9ydCBhZGRyZXNzIGFuZFxuICAg cmVjZWl2aW5nIGEgbWF0Y2hpbmcsIGF1dGhlbnRpY2F0ZWQsIG5vbi1lcnJvciBTVFVOIGJpbmRp bmcgcmVzcG9uc2VcbiAgIGZyb20gdGhlIHJlbW90ZSBwZWVyXCdzIHRyYW5zcG9ydCBhZGRyZXNz LiAgVGhlc2UgU1RVTiBiaW5kaW5nXG4gICByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGFyZSBhdXRo ZW50aWNhdGVkIHVzaW5nIHRoZSBzYW1lIHNob3J0LXRlcm1cbiAgIGNyZWRlbnRpYWxzIGFzIHRo ZSBpbml0aWFsIElDRSBleGNoYW5nZS5cblxuICAgTm90ZTogIEFsdGhvdWdoIFRDUCBoYXMgaXRz IG93biBjb25zZW50IG1lY2hhbmlzbSAoVENQXG4gICAgICBhY2tub3dsZWRnZW1lbnRzKSwgY29u c2VudCBpcyBuZWNlc3Nhcnkgb3ZlciBhIFRDUCBjb25uZWN0aW9uXG4gICAgICBiZWNhdXNlIGl0 IGNvdWxkIGJlIHRyYW5zbGF0ZWQgdG8gYSBVRFAgY29ubmVjdGlvbiAoZS5nLixcbiAgICAgIFtS RkM2MDYyXSkuXG5cbiAgIEluaXRpYWwgY29uc2VudCB0byBzZW5kIHRyYWZmaWMgaXMgb2J0YWlu ZWQgdXNpbmcgSUNFLiAgQ29uc2VudFxuICAgZXhwaXJlcyBhZnRlciAzMCBzZWNvbmRzLiAgVGhh dCBpcywgaWYgYSB2YWxpZCBTVFVOIGJpbmRpbmcgcmVzcG9uc2VcbiAgIGNvcnJlc3BvbmRpbmcg dG8gYW55IFNUVU4gcmVxdWVzdCBzZW50IGluIHRoZSBsYXN0IDMwIHNlY29uZHMgaGFzIG5vdFxu ICAgYmVlbiByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUgcGVlclwncyB0cmFuc3BvcnQgYWRkcmVz cywgdGhlIGVuZHBvaW50XG4gICBNVVNUIGNlYXNlIHRyYW5zbWlzc2lvbiBvbiB0aGF0IDUtdHVw bGUuICBTVFVOIGNvbnNlbnQgcmVzcG9uc2VzXG4gICByZWNlaXZlZCBhZnRlciBjb25zZW50IGV4 cGlyeSBkbyBub3QgcmUtZXN0YWJsaXNoIGNvbnNlbnQsIGFuZCBtYXkgYmVcbiAgIGRpc2NhcmRl ZCBvciBjYXVzZSBhbiBJQ01QIGVycm9yLlxuXG4gICBUbyBwcmV2ZW50IGV4cGlyeSBvZiBjb25z ZW50LCBhIFNUVU4gYmluZGluZyByZXF1ZXN0IGNhbiBiZSBzZW50XG4gICBwZXJpb2RpY2FsbHku ICBUbyBwcmV2ZW50IHN5bmNocm9uaXphdGlvbiBvZiBjb25zZW50IGNoZWNrcywgZWFjaFxuICAg aW50ZXJ2YWwgTVVTVCBiZSByYW5kb21pemVkIGZyb20gYmV0d2VlbiAwLjggYW5kIDEuMiB0aW1l cyB0aGUgYmFzaWNcbiAgIHBlcmlvZC4gIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgc2V0IGEgZGVm YXVsdCBpbnRlcnZhbCBvZiA1IHNlY29uZHMsXG4gICByZXN1bHRpbmcgaW4gYSBwZXJpb2QgYmV0 d2VlbiBjaGVja3Mgb2YgNCB0byA2IHNlY29uZHMuXG5cbiAgIEVhY2ggU1RVTiBiaW5kaW5nIHJl cXVlc3QgZm9yIGNvbnNlbnQgTVVTVCB1c2UgYSBuZXdcbiAgIGNyeXB0b2dyYXBoaWNhbGx5IHN0 cm9uZyBbUkZDNDA4Nl0gU1RVTiB0cmFuc2FjdGlvbiBJRC4gIEVhY2ggU1RVTlxuICAgYmluZGlu ZyByZXF1ZXN0cyBmb3IgY29uc2VudCBpcyB0cmFuc21pdHRlZCBvbmNlIG9ubHkuICBIZW5jZSwg dGhlXG4gICBzZW5kZXIgY2Fubm90IGFzc3VtZSB0aGF0IGl0IHdpbGwgcmVjZWl2ZSBhIHJlc3Bv bnNlIGZvciBlYWNoIGNvbnNlbnRcbiAgIHJlcXVlc3QsIGFuZCBhIHJlc3BvbnNlIG1pZ2h0IGJl IGZvciBhIHByZXZpb3VzIHJlcXVlc3QgKHJhdGhlciB0aGFuXG4gICBmb3IgdGhlIG1vc3QgcmVj ZW50bHkgc2VudCByZXF1ZXN0KS4gIENvbnNlbnQgZXhwaXJhdGlvbiBjYXVzZXNcbiAgIGltbWVk aWF0ZSB0ZXJtaW5hdGlvbiBvZiBhbGwgb3V0c3RhbmRpbmcgU1RVTiBjb25zZW50IHRyYW5zYWN0 aW9ucy5cbiAgIEVhY2ggU1RVTiB0cmFuc2FjdGlvbiBpcyBtYWludGFpbmVkIHVudGlsIG9uZSBv ZiB0aGUgZm9sbG93aW5nXG4gICBjcml0ZXJpYSBpcyBmdWxmaWxsZWQ6XG5cbiAgIG8gIEEgU1RV TiByZXNwb25zZSBhc3NvY2lhdGVkIHdpdGggdGhlIHRyYW5zYWN0aW9uIGlzIHJlY2VpdmVkOyBv clxuXG4gICBvICBBIFNUVU4gcmVzcG9uc2UgYXNzb2NpYXRlZCB0byBhIG5ld2VyIHRyYW5zYWN0 aW9uIGlzIHJlY2VpdmVkLlxuXG4gICBUbyBtZWV0IHRoZSBzZWN1cml0eSBuZWVkcyBvZiBjb25z ZW50LCBhbiB1bnRydXN0ZWQgYXBwbGljYXRpb25cbiAgIChlLmcuLCBKYXZhU2NyaXB0IG9yIHNp Z25hbGluZyBzZXJ2ZXJzKSBNVVNUIE5PVCBiZSBhYmxlIHRvIG9idGFpbiBvclxuICAgY29udHJv bCB0aGUgU1RVTiB0cmFuc2FjdGlvbiBJRCwgYmVjYXVzZSB0aGF0IGVuYWJsZXMgc3Bvb2Zpbmcg b2ZcbiAgIFNUVU4gcmVzcG9uc2VzLCBmYWxzaWZ5aW5nIGNvbnNlbnQuXG5cblxuXG5cblBlcnVt YWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTIsIDIwMTUgICAgICAgICAgICAg ICBbUGFnZSA0XVxuX1xuSW50ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50 IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1XG5cblxuICAgVG8gcHJldmVudCBhdHRhY2tz IG9uIHRoZSBwZWVyIGR1cmluZyBJQ0UgcmVzdGFydCwgYW4gZW5kcG9pbnQgdGhhdFxuICAgY29u dGludWVzIHRvIHNlbmQgdHJhZmZpYyBvbiB0aGUgcHJldmlvdXNseSB2YWxpZGF0ZWQgY2FuZGlk YXRlIHBhaXJcbiAgIGR1cmluZyBJQ0UgcmVzdGFydCBNVVNUIGNvbnRpbnVlIHRvIHBlcmZvcm0g Y29uc2VudCBmcmVzaG5lc3Mgb24gdGhhdFxuICAgY2FuZGlkYXRlIHBhaXIgYXMgZGVzY3JpYmVk IGVhcmxpZXIuXG5cbiAgIFdoaWxlIFRDUCBhZmZvcmRzIHNvbWUgcHJvdGVjdGlvbiBmcm9tIG9m Zi1wYXRoIGF0dGFja2VycyAoW1JGQzU5NjFdLFxuICAgW1JGQzQ5NTNdKSwgdGhlcmUgaXMgc3Rp bGwgYSByaXNrIGFuIGF0dGFja2VyIGNvdWxkIGNhdXNlIGEgVENQXG4gICBzZW5kZXIgdG8gc2Vu ZCBmb3JldmVyIGJ5IHNwb29maW5nIEFDS3MuICBUbyBwcmV2ZW50IHN1Y2ggYW4gYXR0YWNrLFxu ICAgY29uc2VudCBjaGVja3MgTVVTVCBiZSBwZXJmb3JtZWQgb3ZlciBhbGwgdHJhbnNwb3J0IGNv bm5lY3Rpb25zLFxuICAgaW5jbHVkaW5nIFRDUC4gIEluIHRoaXMgd2F5LCBhbiBvZmYtcGF0aCBh dHRhY2tlciBzcG9vZmluZyBUQ1BcbiAgIHNlZ21lbnRzIGNhbiBub3QgY2F1c2UgYSBUQ1Agc2Vu ZGVyIHRvIHNlbmQgb25jZSB0aGUgY29uc2VudCB0aW1lclxuICAgZXhwaXJlcyAoMzAgc2Vjb25k cykuXG5cbiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9u IGRhdGEgZG9lcyBub3QgbmVlZCB0b1xuICAgbWFpbnRhaW4gY29uc2VudC4gIEhvd2V2ZXIsIG5v dCBzZW5kaW5nIGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVFxuICAgb3IgZmlyZXdhbGwgbWFw cGluZ3MgdG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZyBvbmUgcGVlciB1bmFibGVcbiAg IHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBBYnNlbnQgYmV0dGVy IGluZm9ybWF0aW9uXG4gICBhYm91dCB0aGUgbmV0d29yaywgaWYgYW4gZW5kcG9pbnQgbmVlZHMg dG8gZW5zdXJlIGl0cyBOQVQgb3IgZmlyZXdhbGxcbiAgIG1hcHBpbmdzIGRvIG5vdCBleHBpcmUs IGl0IGNhbiBiZSBkb25lIHVzaW5nIGtlZXBhbGl2ZSBvciBvdGhlclxuICAgdGVjaG5pcXVlcyAo c2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS5cblxuICAgQWZ0 ZXIgY29uc2VudCBpcyBsb3N0IGZvciBhbnkgcmVhc29uLCB0aGUgc2FtZSBJQ0UgY3JlZGVudGlh bHMgTVVTVFxuICAgTk9UIGJlIHVzZWQgb24gdGhlIGFmZmVjdGVkIDUtdHVwbGUgYWdhaW4uICBU aGF0IG1lYW5zIHRoYXQgYSBuZXdcbiAgIHNlc3Npb24sIG9yIGFuIElDRSByZXN0YXJ0LCBpcyBu ZWVkZWQgdG8gb2J0YWluIGNvbnNlbnQgdG8gc2VuZC5cblxuNC4yLiAgSW1tZWRpYXRlIFJldm9j YXRpb24gb2YgQ29uc2VudFxuXG4gICBJbiBzb21lIGNhc2VzIGl0IGlzIHVzZWZ1bCB0byBzaWdu YWwgdGhhdCBjb25zZW50IGlzIHRlcm1pbmF0ZWRcbiAgIHJhdGhlciB0aGFuIHJlbHlpbmcgb24g YSB0aW1lb3V0LlxuXG4gICBDb25zZW50IGZvciBzZW5kaW5nIGFwcGxpY2F0aW9uIGRhdGEgaXMg aW1tZWRpYXRlbHkgcmV2b2tlZCBieVxuICAgcmVjZWlwdCBvZiBhbiBhdXRoZW50aWNhdGVkIG1l c3NhZ2UgdGhhdCBjbG9zZXMgdGhlIGNvbm5lY3Rpb24gKGUuZy4sXG4gICBhIFRMUyBmYXRhbCBh bGVydCkgb3IgcmVjZWlwdCBvZiBhIHZhbGlkIGFuZCBhdXRoZW50aWNhdGVkIFNUVU5cbiAgIHJl c3BvbnNlIHdpdGggZXJyb3IgY29kZSBGb3JiaWRkZW4gKDQwMykuICBOb3RlIGhvd2V2ZXIgdGhh dCBjb25zZW50XG4gICByZXZvY2F0aW9uIG1lc3NhZ2VzIGNhbiBiZSBsb3N0IG9uIHRoZSBuZXR3 b3JrLCBzbyBhbiBlbmRwb2ludCBjb3VsZFxuICAgcmVzZW5kIHRoZXNlIG1lc3NhZ2VzLCBvciB3 YWl0IGZvciBjb25zZW50IHRvIGV4cGlyZS5cblxuICAgUmVjZWlwdCBvZiBhbiB1bmF1dGhlbnRp Y2F0ZWQgbWVzc2FnZSB0aGF0IGNsb3NlcyBhIGNvbm5lY3Rpb24gKGUuZy4sXG4gICBUQ1AgRklO KSBkb2VzIG5vdCBpbmRpY2F0ZSByZXZvY2F0aW9uIG9mIGNvbnNlbnQuICBUaHVzLCBhbiBlbmRw b2ludFxuICAgcmVjZWl2aW5nIGFuIHVuYXV0aGVudGljYXRlZCBlbmQtb2Ytc2Vzc2lvbiBtZXNz YWdlIFNIT1VMRCBjb250aW51ZVxuICAgc2VuZGluZyBtZWRpYSAob3ZlciBjb25uZWN0aW9ubGVz cyB0cmFuc3BvcnQpIG9yIGF0dGVtcHQgdG8gcmUtXG4gICBlc3RhYmxpc2ggdGhlIGNvbm5lY3Rp b24gKG92ZXIgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnQpIHVudGlsXG4gICBjb25zZW50 IGV4cGlyZXMgb3IgaXQgcmVjZWl2ZXMgYW4gYXV0aGVudGljYXRlZCBtZXNzYWdlIHJldm9raW5n XG4gICBjb25zZW50LlxuXG4gICBOb3RlIHRoYXQgYW4gYXV0aGVudGljYXRlZCBTUlRDUCBCWUUg ZG9lcyBub3QgdGVybWluYXRlIGNvbnNlbnQ7IGl0XG4gICBvbmx5IGluZGljYXRlcyB0aGUgYXNz b2NpYXRlZCBTUlRQIHNvdXJjZSBoYXMgcXVpdC5cblxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAg ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxMiwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDVdXG5f XG5JbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAg ICAgICAgICAgTWF5IDIwMTVcblxuXG41LiAgRGlmZlNlcnYgVHJlYXRtZW50IGZvciBDb25zZW50 XG5cbiAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgU1RVTiBjb25zZW50IGNoZWNrcyB1c2UgdGhl IHNhbWUgRGlmZnNlcnZcbiAgIENvZGVwb2ludCBtYXJraW5ncyBhcyB0aGUgSUNFIGNvbm5lY3Rp dml0eSBjaGVja3MgZGVzY3JpYmVkIGluXG4gICBTZWN0aW9uIDcuMS4yLjQgb2YgW1JGQzUyNDVd IGZvciBhIGdpdmVuIDUtdHVwbGUuXG5cbiAgIE5vdGU6ICBJdCBpcyBwb3NzaWJsZSB0aGF0IGRp ZmZlcmVudCBEaWZmc2VydiBDb2RlcG9pbnRzIGFyZSB1c2VkIGJ5XG4gICAgICBkaWZmZXJlbnQg bWVkaWEgb3ZlciB0aGUgc2FtZSB0cmFuc3BvcnQgYWRkcmVzc1xuICAgICAgW0ktRC5pZXRmLXRz dndnLXJ0Y3dlYi1xb3NdLiAgU3VjaCBhIGNhc2UgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2ZcbiAg ICAgIHRoaXMgZG9jdW1lbnQuXG5cbjYuICBEVExTIGFwcGxpY2FiaWxpdHlcblxuICAgVGhlIERU TFMgYXBwbGljYWJpbGl0eSBpcyBpZGVudGljYWwgdG8gd2hhdCBpcyBkZXNjcmliZWQgaW5cbiAg IFNlY3Rpb24gNC4yIG9mIFtSRkM3MzUwXS5cblxuNy4gIEFQSSBSZWNvbW1lbmRhdGlvbnNcblxu ICAgVGhlIFczQyBzcGVjaWZpY2F0aW9uIFtXM0MtV0VCUlRDXSBtYXkgcHJvdmlkZSBhbiBBUEkg aG9vayB0aGF0XG4gICBnZW5lcmF0ZXMgYW4gZXZlbnQgd2hlbiBjb25zZW50IGhhcyBleHBpcmVk IGZvciBhIGdpdmVuIDUtdHVwbGUsXG4gICBtZWFuaW5nIHRoYXQgdHJhbnNtaXNzaW9uIG9mIGRh dGEgaGFzIGNlYXNlZC4gIFRoaXMgY291bGQgaW5kaWNhdGVcbiAgIHdoYXQgYXBwbGljYXRpb24g ZGF0YSBpcyBhZmZlY3RlZCwgc3VjaCBhcyBtZWRpYSBvciBkYXRhIGNoYW5uZWxzLlxuXG44LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnNcblxuICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBz ZWN1cml0eSBtZWNoYW5pc20uXG5cbiAgIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBkaXNj dXNzZWQgaW4gW1JGQzUyNDVdIHNob3VsZCBhbHNvIGJlXG4gICB0YWtlbiBpbnRvIGFjY291bnQu XG5cbiAgIFNSVFAgaXMgZW5jcnlwdGVkIGFuZCBhdXRoZW50aWNhdGVkIHdpdGggc3ltbWV0cmlj IGtleXM7IHRoYXQgaXMsXG4gICBib3RoIHNlbmRlciBhbmQgcmVjZWl2ZXIga25vdyB0aGUga2V5 cy4gIFdpdGggdHdvIHBhcnR5IHNlc3Npb25zLFxuICAgcmVjZWlwdCBvZiBhbiBhdXRoZW50aWNh dGVkIHBhY2tldCBmcm9tIHRoZSBzaW5nbGUgcmVtb3RlIHBhcnR5IGlzIGFcbiAgIHN0cm9uZyBh c3N1cmFuY2UgdGhlIHBhY2tldCBjYW1lIGZyb20gdGhhdCBwYXJ0eS4gIEhvd2V2ZXIsIHdoZW4g YVxuICAgc2Vzc2lvbiBpbnZvbHZlcyBtb3JlIHRoYW4gdHdvIHBhcnRpZXMsIGFsbCBvZiB3aG9t IGtub3cgZWFjaCBvdGhlcnNcbiAgIGtleXMsIGFueSBvZiB0aG9zZSBwYXJ0aWVzIGNvdWxkIGhh dmUgc2VudCAob3Igc3Bvb2ZlZCkgdGhlIHBhY2tldC5cbiAgIFN1Y2ggc2hhcmVkIGtleSBkaXN0 cmlidXRpb25zIGFyZSBwb3NzaWJsZSB3aXRoIHNvbWUgTUlLRVkgW1JGQzM4MzBdXG4gICBtb2Rl cywgU2VjdXJpdHkgRGVzY3JpcHRpb25zIFtSRkM0NTY4XSwgYW5kIEVLVFxuICAgW0ktRC5pZXRm LWF2dGNvcmUtc3J0cC1la3RdLiAgVGh1cywgaW4gc3VjaCBzaGFyZWQga2V5aW5nXG4gICBkaXN0 cmlidXRpb25zLCByZWNlaXB0IG9mIGFuIGF1dGhlbnRpY2F0ZWQgU1JUUCBwYWNrZXQgaXMgbm90 XG4gICBzdWZmaWNpZW50IHRvIHZlcmlmeSBjb25zZW50LlxuXG45LiAgSUFOQSBDb25zaWRlcmF0 aW9uc1xuXG4gICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHJlcXVpcmUgYW55IGFjdGlvbiBmcm9t IElBTkEuXG5cblxuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVt YmVyIDEyLCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgNl1cbl9cbkludGVybmV0LURyYWZ0ICAg ICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNVxu XG5cbjEwLiAgQWNrbm93bGVkZ2VtZW50XG5cbiAgIFRoYW5rcyB0byBFcmljIFJlc2NvcmxhLCBI YXJhbGQgQWx2ZXN0cmFuZCwgQmVybmFyZCBBYm9iYSwgTWFnbnVzXG4gICBXZXN0ZXJsYW5kLCBD dWxsZW4gSmVubmluZ3MsIENocmlzdGVyIEhvbG1iZXJnLCBTaW1vbiBQZXJyZWF1bHQsIFBhdWxc biAgIEt5eml2YXQsIEVtaWwgSXZvdiwgSm9uYXRoYW4gTGVubm94LCBJbmFraSBCYXogQ2FzdGls bG8sIFJham1vaGFuXG4gICBCYW5hdmkgYW5kIENocmlzdGlhbiBHcm92ZXMgZm9yIHRoZWlyIHZh bHVhYmxlIGlucHV0cyBhbmQgY29tbWVudHMuXG4gICBUaGFua3MgdG8gQ2hyaXN0ZXIgSG9sbWJl cmcgZm9yIGRvaW5nIGEgdGhyb3VnaCByZXZpZXcuXG5cbjExLiAgUmVmZXJlbmNlc1xuXG4xMS4x LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXNcblxuICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktl eSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGVcbiAgICAgICAgICAgICAgUmVxdWly ZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny5cblxuICAgW1JGQzQw ODZdICBFYXN0bGFrZSwgRC4sIFNjaGlsbGVyLCBKLiwgYW5kIFMuIENyb2NrZXIsICJSYW5kb21u ZXNzXG4gICAgICAgICAgICAgIFJlcXVpcmVtZW50cyBmb3IgU2VjdXJpdHkiLCBCQ1AgMTA2LCBS RkMgNDA4NiwgSnVuZSAyMDA1LlxuXG4gICBbUkZDNTI0NV0gIFJvc2VuYmVyZywgSi4sICJJbnRl cmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudFxuICAgICAgICAgICAgICAoSUNFKTog QSBQcm90b2NvbCBmb3IgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0b3IgKE5BVClcbiAgICAgICAg ICAgICAgVHJhdmVyc2FsIGZvciBPZmZlci9BbnN3ZXIgUHJvdG9jb2xzIiwgUkZDIDUyNDUsIEFw cmlsXG4gICAgICAgICAgICAgIDIwMTAuXG5cbiAgIFtSRkM2MjYzXSAgTWFyam91LCBYLiBhbmQg QS4gU29sbGF1ZCwgIkFwcGxpY2F0aW9uIE1lY2hhbmlzbSBmb3JcbiAgICAgICAgICAgICAgS2Vl cGluZyBBbGl2ZSB0aGUgTkFUIE1hcHBpbmdzIEFzc29jaWF0ZWQgd2l0aCBSVFAgLyBSVFBcbiAg ICAgICAgICAgICAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkgRmxvd3MiLCBSRkMgNjI2MywgSnVu ZSAyMDExLlxuXG4xMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlc1xuXG4gICBbSS1ELmlldGYt YXZ0Y29yZS1zcnRwLWVrdF1cbiAgICAgICAgICAgICAgTWF0dHNzb24sIEouLCBNY0dyZXcsIEQu LCBhbmQgRC4gV2luZywgIkVuY3J5cHRlZCBLZXlcbiAgICAgICAgICAgICAgVHJhbnNwb3J0IGZv ciBTZWN1cmUgUlRQIiwgZHJhZnQtaWV0Zi1hdnRjb3JlLXNydHAtZWt0LTAzXG4gICAgICAgICAg ICAgICh3b3JrIGluIHByb2dyZXNzKSwgT2N0b2JlciAyMDE0LlxuXG4gICBbSS1ELmlldGYtcnRj d2ViLW92ZXJ2aWV3XVxuICAgICAgICAgICAgICBBbHZlc3RyYW5kLCBILiwgIk92ZXJ2aWV3OiBS ZWFsIFRpbWUgUHJvdG9jb2xzIGZvclxuICAgICAgICAgICAgICBCcm93c2VyLWJhc2VkIEFwcGxp Y2F0aW9ucyIsIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEzXG4gICAgICAgICAgICAgICh3 b3JrIGluIHByb2dyZXNzKSwgTm92ZW1iZXIgMjAxNC5cblxuICAgW0ktRC5pZXRmLXRzdndnLXJ0 Y3dlYi1xb3NdXG4gICAgICAgICAgICAgIERoZXNpa2FuLCBTLiwgSmVubmluZ3MsIEMuLCBEcnV0 YSwgRC4sIEpvbmVzLCBQLiwgYW5kIEouXG4gICAgICAgICAgICAgIFBvbGssICJEU0NQIGFuZCBv dGhlciBwYWNrZXQgbWFya2luZ3MgZm9yIFJUQ1dlYiBRb1MiLFxuICAgICAgICAgICAgICBkcmFm dC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MtMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLFxuICAgICAgICAg ICAgICBOb3ZlbWJlciAyMDE0LlxuXG4gICBbUkZDMzgzMF0gIEFya2tvLCBKLiwgQ2FycmFyYSwg RS4sIExpbmRob2xtLCBGLiwgTmFzbHVuZCwgTS4sIGFuZCBLLlxuICAgICAgICAgICAgICBOb3Jy bWFuLCAiTUlLRVk6IE11bHRpbWVkaWEgSW50ZXJuZXQgS0VZaW5nIiwgUkZDIDM4MzAsXG4gICAg ICAgICAgICAgIEF1Z3VzdCAyMDA0LlxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhw aXJlcyBOb3ZlbWJlciAxMiwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDddXG5fXG5JbnRlcm5l dC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgICAgICAg TWF5IDIwMTVcblxuXG4gICBbUkZDNDU2OF0gIEFuZHJlYXNlbiwgRi4sIEJhdWdoZXIsIE0uLCBh bmQgRC4gV2luZywgIlNlc3Npb25cbiAgICAgICAgICAgICAgRGVzY3JpcHRpb24gUHJvdG9jb2wg KFNEUCkgU2VjdXJpdHkgRGVzY3JpcHRpb25zIGZvciBNZWRpYVxuICAgICAgICAgICAgICBTdHJl YW1zIiwgUkZDIDQ1NjgsIEp1bHkgMjAwNi5cblxuICAgW1JGQzQ5NTNdICBUb3VjaCwgSi4sICJE ZWZlbmRpbmcgVENQIEFnYWluc3QgU3Bvb2ZpbmcgQXR0YWNrcyIsIFJGQ1xuICAgICAgICAgICAg ICA0OTUzLCBKdWx5IDIwMDcuXG5cbiAgIFtSRkM1OTYxXSAgUmFtYWlhaCwgQS4sIFN0ZXdhcnQs IFIuLCBhbmQgTS4gRGFsYWwsICJJbXByb3ZpbmcgVENQXCdzXG4gICAgICAgICAgICAgIFJvYnVz dG5lc3MgdG8gQmxpbmQgSW4tV2luZG93IEF0dGFja3MiLCBSRkMgNTk2MSwgQXVndXN0XG4gICAg ICAgICAgICAgIDIwMTAuXG5cbiAgIFtSRkM2MDYyXSAgUGVycmVhdWx0LCBTLiBhbmQgSi4gUm9z ZW5iZXJnLCAiVHJhdmVyc2FsIFVzaW5nIFJlbGF5c1xuICAgICAgICAgICAgICBhcm91bmQgTkFU IChUVVJOKSBFeHRlbnNpb25zIGZvciBUQ1AgQWxsb2NhdGlvbnMiLCBSRkNcbiAgICAgICAgICAg ICAgNjA2MiwgTm92ZW1iZXIgMjAxMC5cblxuICAgW1JGQzczNTBdICBQZXRpdC1IdWd1ZW5pbiwg TS4gYW5kIEcuIFNhbGd1ZWlybywgIkRhdGFncmFtIFRyYW5zcG9ydFxuICAgICAgICAgICAgICBM YXllciBTZWN1cml0eSAoRFRMUykgYXMgVHJhbnNwb3J0IGZvciBTZXNzaW9uIFRyYXZlcnNhbFxu ICAgICAgICAgICAgICBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikiLCBSRkMgNzM1MCwgQXVndXN0 IDIwMTQuXG5cbiAgIFtXM0MtV0VCUlRDXVxuICAgICAgICAgICAgICBCZXJna3Zpc3QsIEEuLCBC dXJuZXR0LCBELiwgTmFyYXlhbmFuLCBBLiwgYW5kIEMuXG4gICAgICAgICAgICAgIEplbm5pbmdz LCAiV2ViUlRDIDEuMDogUmVhbC10aW1lIENvbW11bmljYXRpb24gQmV0d2VlblxuICAgICAgICAg ICAgICBCcm93c2VycyIsIGZlYnJ1YXJ5IDIwMTUuXG5cbkF1dGhvcnNcJyBBZGRyZXNzZXNcblxu ICAgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsXG4gICBFcmljc3NvblxuICAgRmVybnMgSWNvblxu ICAgRG9kZGFuZWt1bmRpLCBNYWhhZGV2YXB1cmFcbiAgIEJhbmdhbG9yZSwgS2FybmF0YWthICA1 NjAwMzdcbiAgIEluZGlhXG5cbiAgIEVtYWlsOiBtdXRodS5hcnVsQGdtYWlsLmNvbVxuXG5cbiAg IERhbiBXaW5nXG4gICBDaXNjbyBTeXN0ZW1zXG4gICA4MjEgQWxkZXIgRHJpdmVcbiAgIE1pbHBp dGFzLCBDYWxpZm9ybmlhICA5NTAzNVxuICAgVVNBXG5cbiAgIEVtYWlsOiBkd2luZ0BjaXNjby5j b21cblxuXG5cblxuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVt YmVyIDEyLCAyMDE1ICAgICAgICAgICAgICAgW1BhZ2UgOF1cbl9cbkludGVybmV0LURyYWZ0ICAg ICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNVxu XG5cbiAgIFJhbSBNb2hhbiBSYXZpbmRyYW5hdGhcbiAgIENpc2NvIFN5c3RlbXNcbiAgIENlc3Nu YSBCdXNpbmVzcyBQYXJrXG4gICBTYXJqYXB1ci1NYXJhdGhhaGFsbGkgT3V0ZXIgUmluZyBSb2Fk XG4gICBCYW5nYWxvcmUsIEthcm5hdGFrYSAgNTYwMTAzXG4gICBJbmRpYVxuXG4gICBFbWFpbDog cm1vaGFuckBjaXNjby5jb21cblxuXG4gICBUaXJ1bWFsZXN3YXIgUmVkZHlcbiAgIENpc2NvIFN5 c3RlbXNcbiAgIENlc3NuYSBCdXNpbmVzcyBQYXJrLCBWYXJ0aHVyIEhvYmxpXG4gICBTYXJqYXB1 ciBNYXJhdGhhbGxpIE91dGVyIFJpbmcgUm9hZFxuICAgQmFuZ2Fsb3JlLCBLYXJuYXRha2EgIDU2 MDEwM1xuICAgSW5kaWFcblxuICAgRW1haWw6IHRpcmVkZHlAY2lzY28uY29tXG5cblxuICAgTWFy dGluIFRob21zb25cbiAgIE1vemlsbGFcbiAgIFN1aXRlIDMwMFxuICAgNjUwIENhc3RybyBTdHJl ZXRcbiAgIE1vdW50YWluIFZpZXcsIENhbGlmb3JuaWEgIDk0MDQxXG4gICBVU1xuXG4gICBFbWFp bDogbWFydGluLnRob21zb25AZ21haWwuY29tXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5cblxu XG5cblxuXG5cblxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJl ciAxMiwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDldXG4nLCAnZmlsZW5hbWUxJzogJ1xuXG5c blxuUlRDV0VCICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBNLiBQZXJ1bWFsXG5JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb25cbkludGVuZGVkIHN0YXR1czogU3Rh bmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRC4gV2luZ1xuRXhw aXJlczogTm92ZW1iZXIgNSwgMjAxNSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4g UmF2aW5kcmFuYXRoXG4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVC4gUmVkZHlcbiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtc1xuICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBU aG9tc29uXG4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1vemlsbGFcbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNYXkgNCwgMjAxNVxuXG5cbiAgICAgICAgICAg ICAgICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3NcbiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMlxuXG5BYnN0cmFjdFxu XG4gICBUbyBwcmV2ZW50IHNlbmRpbmcgZXhjZXNzaXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQs IHBlcmlvZGljIGNvbnNlbnRcbiAgIG5lZWRzIHRvIGJlIG9idGFpbmVkIGZyb20gdGhhdCByZW1v dGUgZW5kcG9pbnQuXG5cbiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29uc2VudCBtZWNo YW5pc20gdXNpbmcgYSBuZXcgU2Vzc2lvblxuICAgVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFU IChTVFVOKSB1c2FnZS5cblxuU3RhdHVzIG9mIFRoaXMgTWVtb1xuXG4gICBUaGlzIEludGVybmV0 LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlXG4gICBwcm92 aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LlxuXG4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdv cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZ1xuICAgVGFzayBGb3Jj ZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGVcbiAg IHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtXG4gICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RyYWZ0cy9jdXJyZW50Ly5cblxuICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzXG4gICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueVxuICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2VcbiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGlu IHByb2dyZXNzLiJcblxuICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBOb3Zl bWJlciA1LCAyMDE1LlxuXG5Db3B5cmlnaHQgTm90aWNlXG5cbiAgIENvcHlyaWdodCAoYykgMjAx NSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZVxuICAgZG9jdW1l bnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuXG5cbiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0XCdzIExlZ2FsXG4gICBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzXG4gICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5v cmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2ZcbiAgIHB1YmxpY2F0aW9u IG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50c1xuXG5cblxu UGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciA1LCAyMDE1ICAgICAgICAg ICAgICAgIFtQYWdlIDFdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENv bnNlbnQgRnJlc2huZXNzICAgICAgICAgICAgTWF5IDIwMTVcblxuXG4gICBjYXJlZnVsbHksIGFz IHRoZXkgZGVzY3JpYmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Rc biAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhp cyBkb2N1bWVudCBtdXN0XG4gICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2ZcbiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNp b25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhc1xuICAgZGVzY3JpYmVkIGlu IHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLlxuXG5UYWJsZSBvZiBDb250ZW50c1xuXG4gICAx LiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDJcbiAgIDIuICBUZXJtaW5vbG9neSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgM1xuICAgMy4gIERlc2lnbiBDb25zaWRlcmF0aW9u cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzXG4gICA0LiAgU29s dXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDNcbiAgICAgNC4xLiAgRXhwaXJhdGlvbiBvZiBDb25zZW50IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgM1xuICAgICA0LjIuICBJbW1lZGlhdGUgUmV2b2NhdGlvbiBv ZiBDb25zZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1XG4gICA1LiAgRGlmZlNlcnYg VHJlYXRtZW50IGZvciBDb25zZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZc biAgIDYuICBEVExTIGFwcGxpY2FiaWxpdHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNlxuICAgNy4gIEFQSSBSZWNvbW1lbmRhdGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2XG4gICA4LiAgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDZcbiAgIDku ICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNlxuICAgMTAuIEFja25vd2xlZGdlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3XG4gICAxMS4gUmVmZXJlbmNlcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDdcbiAgICAgMTEuMS4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgN1xuICAgICAxMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA3XG4gICBBdXRob3JzXCcgQWRkcmVzc2VzICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4XG5cbjEuICBJbnRyb2R1Y3Rp b25cblxuICAgVG8gcHJldmVudCBhdHRhY2tzIG9uIHBlZXJzLCBlbmRwb2ludHMgaGF2ZSB0byBl bnN1cmUgdGhlIHJlbW90ZSBwZWVyXG4gICBpcyB3aWxsaW5nIHRvIHJlY2VpdmUgdHJhZmZpYy4g IFRoaXMgaXMgcGVyZm9ybWVkIGJvdGggd2hlbiB0aGVcbiAgIHNlc3Npb24gaXMgZmlyc3QgZXN0 YWJsaXNoZWQgdG8gdGhlIHJlbW90ZSBwZWVyIHVzaW5nIEludGVyYWN0aXZlXG4gICBDb25uZWN0 aXZpdHkgRXN0YWJsaXNobWVudCBJQ0UgW1JGQzUyNDVdIGNvbm5lY3Rpdml0eSBjaGVja3MsIGFu ZFxuICAgcGVyaW9kaWNhbGx5IGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIHNlc3Npb24gdXNpbmcg dGhlIHByb2NlZHVyZXNcbiAgIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC5cblxuICAgV2hlbiBh IHNlc3Npb24gaXMgZmlyc3QgZXN0YWJsaXNoZWQsIElDRSBpbXBsZW1lbnRhdGlvbnMgb2J0YWlu IGFuXG4gICBpbml0aWFsIGNvbnNlbnQgdG8gc2VuZCBieSBwZXJmb3JtaW5nIFNUVU4gY29ubmVj dGl2aXR5IGNoZWNrcy4gIFRoaXNcbiAgIGRvY3VtZW50IGRlc2NyaWJlcyBhIG5ldyBTVFVOIHVz YWdlIHdpdGggZXhjaGFuZ2Ugb2YgcmVxdWVzdCBhbmRcbiAgIHJlc3BvbnNlIG1lc3NhZ2VzIHRo YXQgdmVyaWZpZXMgdGhlIHJlbW90ZSBwZWVyXCdzIG9uZ29pbmcgY29uc2VudCB0b1xuICAgcmVj ZWl2ZSB0cmFmZmljLiAgVGhpcyBjb25zZW50IGV4cGlyZXMgYWZ0ZXIgYSBwZXJpb2Qgb2YgdGlt ZSBhbmRcbiAgIG5lZWRzIHRvIGJlIGNvbnRpbnVhbGx5IHJlbmV3ZWQsIHdoaWNoIGVuc3VyZXMg dGhhdCBjb25zZW50IGNhbiBiZVxuICAgdGVybWluYXRlZC5cblxuICAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIHdoYXQgaXQgdGFrZXMgdG8gb2J0YWluLCBtYWludGFpbiwgYW5kIGxvc2VcbiAgIGNv bnNlbnQgdG8gc2VuZC4gIENvbnNlbnQgdG8gc2VuZCBhcHBsaWVzIHRvIGEgc2luZ2xlIDUtdHVw bGUuICBIb3dcbiAgIGFwcGxpY2F0aW9ucyByZWFjdCB0byBjaGFuZ2VzIGluIGNvbnNlbnQgaXMg bm90IGRlc2NyaWJlZCBpbiB0aGlzXG4gICBkb2N1bWVudC5cblxuXG5cblxuXG5QZXJ1bWFsLCBl dCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDUsIDIwMTUgICAgICAgICAgICAgICAgW1Bh Z2UgMl1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVz aG5lc3MgICAgICAgICAgICBNYXkgMjAxNVxuXG5cbiAgIENvbnNlbnQgaXMgb2J0YWluZWQgb25s eSBieSBmdWxsIElDRSBpbXBsZW1lbnRhdGlvbnMuICBBbiBJQ0UtbGl0ZVxuICAgaW1wbGVtZW50 YXRpb24gd2lsbCBub3QgZ2VuZXJhdGUgY29uc2VudCBjaGVja3MsIGJ1dCB3aWxsIGp1c3RcbiAg IHJlc3BvbmQgdG8gY29uc2VudCBjaGVja3MgaXQgcmVjZWl2ZXMuICBObyBjaGFuZ2VzIGFyZSBy ZXF1aXJlZCB0b1xuICAgSUNFLWxpdGUgaW1wbGVtZW50YXRpb25zIGluIG9yZGVyIHRvIHJlc3Bv bmQgdG8gY29uc2VudCBjaGVja3MsIGFzXG4gICB0aGV5IGFyZSBwcm9jZXNzZWQgYXMgbm9ybWFs IElDRSBjb25uZWN0aXZpdHkgY2hlY2tzLlxuXG4yLiAgVGVybWlub2xvZ3lcblxuICAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBO T1QiLFxuICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFu ZCAiT1BUSU9OQUwiIGluIHRoaXNcbiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBh cyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLlxuXG4gICBDb25zZW50OiAgVGhlIG1lY2hhbmlzbSBv ZiBvYnRhaW5pbmcgcGVybWlzc2lvbiB0byBzZW5kIHRvIGEgcmVtb3RlXG4gICAgICB0cmFuc3Bv cnQgYWRkcmVzcy4gIEluaXRpYWwgY29uc2VudCBpcyBvYnRhaW5lZCB1c2luZyBJQ0UuXG5cbiAg IENvbnNlbnQgRnJlc2huZXNzOiAgTWFpbnRhaW5pbmcgYW5kIHJlbmV3aW5nIGNvbnNlbnQgb3Zl ciB0aW1lLlxuXG4gICBUcmFuc3BvcnQgQWRkcmVzczogIFRoZSByZW1vdGUgcGVlclwncyBJUCBh ZGRyZXNzIGFuZCBVRFAgb3IgVENQIHBvcnRcbiAgICAgIG51bWJlci5cblxuMy4gIERlc2lnbiBD b25zaWRlcmF0aW9uc1xuXG4gICBBbHRob3VnaCBJQ0UgcmVxdWlyZXMgcGVyaW9kaWMga2VlcGFs aXZlIHRyYWZmaWMgdG8ga2VlcCBOQVQgYmluZGluZ3NcbiAgIGFsaXZlIChTZWN0aW9uIDEwIG9m IFtSRkM1MjQ1XSwgW1JGQzYyNjNdKSwgdGhvc2Uga2VlcGFsaXZlcyBhcmUgc2VudFxuICAgYXMg U1RVTiBJbmRpY2F0aW9ucyB3aGljaCBhcmUgc2VuZC1hbmQtZm9yZ2V0LCBhbmQgZG8gbm90IGV2 b2tlIGFcbiAgIHJlc3BvbnNlLiAgQSByZXNwb25zZSBpcyBuZWNlc3NhcnkgZm9yIGNvbnNlbnQg dG8gY29udGludWUgc2VuZGluZ1xuICAgdHJhZmZpYy4gIFRodXMsIHdlIG5lZWQgYSByZXF1ZXN0 L3Jlc3BvbnNlIG1lY2hhbmlzbSBmb3IgY29uc2VudFxuICAgZnJlc2huZXNzLiAgSUNFIGNhbiBi ZSB1c2VkIGZvciB0aGF0IG1lY2hhbmlzbSBiZWNhdXNlIElDRVxuICAgaW1wbGVtZW50YXRpb25z IGFyZSBhbHJlYWR5IHJlcXVpcmVkIHRvIGNvbnRpbnVlIGxpc3RlbmluZyBmb3IgSUNFXG4gICBt ZXNzYWdlcywgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdLiAgSWYgY29u c2VudCBpc1xuICAgcGVyZm9ybWVkIHRoZW4gdGhlcmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBh bGl2ZSBtZXNzYWdlcy5cblxuNC4gIFNvbHV0aW9uXG5cbiAgIFRoZXJlIGFyZSB0d28gd2F5cyBj b25zZW50IHRvIHNlbmQgdHJhZmZpYyBpcyByZXZva2VkOiBleHBpcmF0aW9uIG9mXG4gICBjb25z ZW50IGFuZCBpbW1lZGlhdGUgcmV2b2NhdGlvbiBvZiBjb25zZW50LCB3aGljaCBhcmUgZGlzY3Vz c2VkIGluXG4gICB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLlxuXG40LjEuICBFeHBpcmF0aW9uIG9m IENvbnNlbnRcblxuICAgQSBmdWxsIElDRSBpbXBsZW1lbnRhdGlvbiBwZXJmb3JtcyBjb25zZW50 IGZyZXNobmVzcyB0ZXN0IHVzaW5nIFNUVU5cbiAgIHJlcXVlc3QvcmVzcG9uc2UgYXMgZGVzY3Jp YmVkIGJlbG93OlxuXG4gICBBbiBlbmRwb2ludCBNVVNUIE5PVCBzZW5kIGRhdGEgb3RoZXIgdGhh biBwYWNlZCBTVFVOIGNvbm5lY3Rpdml0eVxuICAgY2hlY2tzIG9yIHJlc3BvbnNlcyB0b3dhcmQg YW55IHRyYW5zcG9ydCBhZGRyZXNzIHVubGVzcyB0aGUgcmVjZWl2aW5nXG4gICBlbmRwb2ludCBj b25zZW50cyB0byByZWNlaXZlIGRhdGEuICBUaGF0IGlzLCBubyBhcHBsaWNhdGlvbiBkYXRhXG4g ICAoZS5nLiwgUlRQIG9yIERUTFMpIGNhbiBiZSBzZW50IHVudGlsIGNvbnNlbnQgaXMgb2J0YWlu ZWQuICBBZnRlciBhXG4gICBzdWNjZXNzZnVsIElDRSBjb25uZWN0aXZpdHkgY2hlY2sgb24gYSBw YXJ0aWN1bGFyIHRyYW5zcG9ydCBhZGRyZXNzLFxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAg ICAgRXhwaXJlcyBOb3ZlbWJlciA1LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDNdXG5fXG5J bnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAg ICAgICAgTWF5IDIwMTVcblxuXG4gICBjb25zZW50IE1VU1QgYmUgbWFpbnRhaW5lZCBmb2xsb3dp bmcgdGhlIHByb2NlZHVyZSBkZXNjcmliZWQgaW4gdGhpc1xuICAgZG9jdW1lbnQuXG5cbiAgIEV4 cGxpY2l0IGNvbnNlbnQgdG8gc2VuZCBpcyBvYnRhaW5lZCBhbmQgbWFpbnRhaW5lZCBieSBzZW5k aW5nIGFuXG4gICBTVFVOIGJpbmRpbmcgcmVxdWVzdCB0byB0aGUgcmVtb3RlIHBlZXJcJ3MgdHJh bnNwb3J0IGFkZHJlc3MgYW5kXG4gICByZWNlaXZpbmcgYSBtYXRjaGluZywgYXV0aGVudGljYXRl ZCwgbm9uLWVycm9yIFNUVU4gYmluZGluZyByZXNwb25zZVxuICAgZnJvbSB0aGUgcmVtb3RlIHBl ZXJcJ3MgdHJhbnNwb3J0IGFkZHJlc3MuICBUaGVzZSBTVFVOIGJpbmRpbmdcbiAgIHJlcXVlc3Rz IGFuZCByZXNwb25zZXMgYXJlIGF1dGhlbnRpY2F0ZWQgdXNpbmcgdGhlIHNhbWUgc2hvcnQtdGVy bVxuICAgY3JlZGVudGlhbHMgYXMgdGhlIGluaXRpYWwgSUNFIGV4Y2hhbmdlLlxuXG4gICBOb3Rl OiAgQWx0aG91Z2ggVENQIGhhcyBpdHMgb3duIGNvbnNlbnQgbWVjaGFuaXNtIChUQ1BcbiAgICAg IGFja25vd2xlZGdlbWVudHMpLCBjb25zZW50IGlzIG5lY2Vzc2FyeSBvdmVyIGEgVENQIGNvbm5l Y3Rpb25cbiAgICAgIGJlY2F1c2UgaXQgY291bGQgYmUgdHJhbnNsYXRlZCB0byBhIFVEUCBjb25u ZWN0aW9uIChlLmcuLFxuICAgICAgW1JGQzYwNjJdKS5cblxuICAgSW5pdGlhbCBjb25zZW50IHRv IHNlbmQgdHJhZmZpYyBpcyBvYnRhaW5lZCB1c2luZyBJQ0UuICBDb25zZW50XG4gICBleHBpcmVz IGFmdGVyIDMwIHNlY29uZHMuICBUaGF0IGlzLCBpZiBhIHZhbGlkIFNUVU4gYmluZGluZyByZXNw b25zZVxuICAgY29ycmVzcG9uZGluZyB0byBhbnkgU1RVTiByZXF1ZXN0IHNlbnQgaW4gdGhlIGxh c3QgMzAgc2Vjb25kcyBoYXMgbm90XG4gICBiZWVuIHJlY2VpdmVkIGZyb20gdGhlIHJlbW90ZSBw ZWVyXCdzIHRyYW5zcG9ydCBhZGRyZXNzLCB0aGUgZW5kcG9pbnRcbiAgIE1VU1QgY2Vhc2UgdHJh bnNtaXNzaW9uIG9uIHRoYXQgNS10dXBsZS4gIFNUVU4gY29uc2VudCByZXNwb25zZXNcbiAgIHJl Y2VpdmVkIGFmdGVyIGNvbnNlbnQgZXhwaXJ5IGRvIG5vdCByZS1lc3RhYmxpc2ggY29uc2VudCwg YW5kIG1heSBiZVxuICAgZGlzY2FyZGVkIG9yIGNhdXNlIGFuIElDTVAgZXJyb3IuXG5cbiAgIFRv IHByZXZlbnQgZXhwaXJ5IG9mIGNvbnNlbnQsIGEgU1RVTiBiaW5kaW5nIHJlcXVlc3QgY2FuIGJl IHNlbnRcbiAgIHBlcmlvZGljYWxseS4gIFRvIHByZXZlbnQgc3luY2hyb25pemF0aW9uIG9mIGNv bnNlbnQgY2hlY2tzLCBlYWNoXG4gICBpbnRlcnZhbCBNVVNUIGJlIHJhbmRvbWl6ZWQgZnJvbSBi ZXR3ZWVuIDAuOCBhbmQgMS4yIHRpbWVzIHRoZSBiYXNpY1xuICAgcGVyaW9kLiAgSW1wbGVtZW50 YXRpb25zIFNIT1VMRCBzZXQgYSBkZWZhdWx0IGludGVydmFsIG9mIDUgc2Vjb25kcyxcbiAgIHJl c3VsdGluZyBpbiBhIHBlcmlvZCBiZXR3ZWVuIGNoZWNrcyBvZiA0IHRvIDYgc2Vjb25kcy5cblxu ICAgRWFjaCBTVFVOIGJpbmRpbmcgcmVxdWVzdCBmb3IgY29uc2VudCBNVVNUIHVzZSBhIG5ld1xu ICAgY3J5cHRvZ3JhcGhpY2FsbHkgc3Ryb25nIFtSRkM0MDg2XSBTVFVOIHRyYW5zYWN0aW9uIElE LiAgRWFjaCBTVFVOXG4gICBiaW5kaW5nIHJlcXVlc3RzIGZvciBjb25zZW50IGlzIHRyYW5zbWl0 dGVkIG9uY2Ugb25seS4gIEhlbmNlLCB0aGVcbiAgIHNlbmRlciBjYW5ub3QgYXNzdW1lIHRoYXQg aXQgd2lsbCByZWNlaXZlIGEgcmVzcG9uc2UgZm9yIGVhY2ggY29uc2VudFxuICAgcmVxdWVzdCwg YW5kIGEgcmVzcG9uc2UgbWlnaHQgYmUgZm9yIGEgcHJldmlvdXMgcmVxdWVzdCAocmF0aGVyIHRo YW5cbiAgIGZvciB0aGUgbW9zdCByZWNlbnRseSBzZW50IHJlcXVlc3QpLiAgQ29uc2VudCBleHBp cmF0aW9uIGNhdXNlc1xuICAgaW1tZWRpYXRlIHRlcm1pbmF0aW9uIG9mIGFsbCBvdXRzdGFuZGlu ZyBTVFVOIGNvbnNlbnQgdHJhbnNhY3Rpb25zLlxuICAgRWFjaCBTVFVOIHRyYW5zYWN0aW9uIGlz IG1haW50YWluZWQgdW50aWwgb25lIG9mIHRoZSBmb2xsb3dpbmdcbiAgIGNyaXRlcmlhIGlzIGZ1 bGZpbGxlZDpcblxuICAgbyAgQSBTVFVOIHJlc3BvbnNlIGFzc29jaWF0ZWQgd2l0aCB0aGUgdHJh bnNhY3Rpb24gaXMgcmVjZWl2ZWQ7IG9yXG5cbiAgIG8gIEEgU1RVTiByZXNwb25zZSBhc3NvY2lh dGVkIHRvIGEgbmV3ZXIgdHJhbnNhY3Rpb24gaXMgcmVjZWl2ZWQuXG5cbiAgIFRvIG1lZXQgdGhl IHNlY3VyaXR5IG5lZWRzIG9mIGNvbnNlbnQsIGFuIHVudHJ1c3RlZCBhcHBsaWNhdGlvblxuICAg KGUuZy4sIEphdmFTY3JpcHQgb3Igc2lnbmFsaW5nIHNlcnZlcnMpIE1VU1QgTk9UIGJlIGFibGUg dG8gb2J0YWluIG9yXG4gICBjb250cm9sIHRoZSBTVFVOIHRyYW5zYWN0aW9uIElELCBiZWNhdXNl IHRoYXQgZW5hYmxlcyBzcG9vZmluZyBvZlxuICAgU1RVTiByZXNwb25zZXMsIGZhbHNpZnlpbmcg Y29uc2VudC5cblxuXG5cblxuUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJl ciA1LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDRdXG5fXG5JbnRlcm5ldC1EcmFmdCAgICAg IFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQgRnJlc2huZXNzICAgICAgICAgICAgTWF5IDIwMTVcblxu XG4gICBUbyBwcmV2ZW50IGF0dGFja3Mgb24gdGhlIHBlZXIgZHVyaW5nIElDRSByZXN0YXJ0LCBh biBlbmRwb2ludCB0aGF0XG4gICBjb250aW51ZXMgdG8gc2VuZCB0cmFmZmljIG9uIHRoZSBwcmV2 aW91c2x5IHZhbGlkYXRlZCBjYW5kaWRhdGUgcGFpclxuICAgZHVyaW5nIElDRSByZXN0YXJ0IE1V U1QgY29udGludWUgdG8gcGVyZm9ybSBjb25zZW50IGZyZXNobmVzcyBvbiB0aGF0XG4gICBjYW5k aWRhdGUgcGFpciBhcyBkZXNjcmliZWQgZWFybGllci5cblxuICAgV2hpbGUgVENQIGFmZm9yZHMg c29tZSBwcm90ZWN0aW9uIGZyb20gb2ZmLXBhdGggYXR0YWNrZXJzIChbUkZDNTk2MV0sXG4gICBb UkZDNDk1M10pLCB0aGVyZSBpcyBzdGlsbCBhIHJpc2sgYW4gYXR0YWNrZXIgY291bGQgY2F1c2Ug YSBUQ1BcbiAgIHNlbmRlciB0byBzZW5kIGZvcmV2ZXIgYnkgc3Bvb2ZpbmcgQUNLcy4gIFRvIHBy ZXZlbnQgc3VjaCBhbiBhdHRhY2ssXG4gICBjb25zZW50IGNoZWNrcyBNVVNUIGJlIHBlcmZvcm1l ZCBvdmVyIGFsbCB0cmFuc3BvcnQgY29ubmVjdGlvbnMsXG4gICBpbmNsdWRpbmcgVENQLiAgSW4g dGhpcyB3YXksIGFuIG9mZi1wYXRoIGF0dGFja2VyIHNwb29maW5nIFRDUFxuICAgc2VnbWVudHMg Y2FuIG5vdCBjYXVzZSBhIFRDUCBzZW5kZXIgdG8gc2VuZCBvbmNlIHRoZSBjb25zZW50IHRpbWVy XG4gICBleHBpcmVzICgzMCBzZWNvbmRzKS5cblxuICAgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qg c2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvXG4gICBtYWludGFp biBjb25zZW50LiAgSG93ZXZlciwgZmFpbHVyZSB0byBzZW5kIGNvdWxkIGNhdXNlIGFueSBOQVQg b3JcbiAgIGZpcmV3YWxsIG1hcHBpbmdzIGZvciB0aGUgZmxvdyB0byBleHBpcmUuICBGdXJ0aGVy bW9yZSwgaGF2aW5nIG9uZVxuICAgcGVlciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0 byBtYW55IHByb3RvY29scy4gIEFic2VudCBiZXR0ZXJcbiAgIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBuZXR3b3JrLCBhbiBlbmRwb2ludCBTSE9VTEQgbWFpbnRhaW4gY29uc2VudCBpZlxuICAgdGhl cmUgaXMgYW55IHBvc3NpYmlsaXR5IHRoYXQgYSBmbG93IG1pZ2h0IGJlIG5lZWRlZCBhZ2Fpbi5c blxuICAgQWZ0ZXIgY29uc2VudCBpcyBsb3N0IGZvciBhbnkgcmVhc29uLCB0aGUgc2FtZSBJQ0Ug Y3JlZGVudGlhbHMgTVVTVFxuICAgTk9UIGJlIHVzZWQgb24gdGhlIGFmZmVjdGVkIDUtdHVwbGUg YWdhaW4uICBUaGF0IG1lYW5zIHRoYXQgYSBuZXdcbiAgIHNlc3Npb24sIG9yIGFuIElDRSByZXN0 YXJ0LCBpcyBuZWVkZWQgdG8gb2J0YWluIGNvbnNlbnQgdG8gc2VuZC5cblxuNC4yLiAgSW1tZWRp YXRlIFJldm9jYXRpb24gb2YgQ29uc2VudFxuXG4gICBJbiBzb21lIGNhc2VzIGl0IGlzIHVzZWZ1 bCB0byBzaWduYWwgdGhhdCBjb25zZW50IGlzIHRlcm1pbmF0ZWRcbiAgIHJhdGhlciB0aGFuIHJl bHlpbmcgb24gYSB0aW1lb3V0LlxuXG4gICBDb25zZW50IGZvciBzZW5kaW5nIGFwcGxpY2F0aW9u IGRhdGEgaXMgaW1tZWRpYXRlbHkgcmV2b2tlZCBieVxuICAgcmVjZWlwdCBvZiBhbiBhdXRoZW50 aWNhdGVkIG1lc3NhZ2UgdGhhdCBjbG9zZXMgdGhlIGNvbm5lY3Rpb24gKGUuZy4sXG4gICBhIFRM UyBmYXRhbCBhbGVydCkgb3IgcmVjZWlwdCBvZiBhIHZhbGlkIGFuZCBhdXRoZW50aWNhdGVkIFNU VU5cbiAgIHJlc3BvbnNlIHdpdGggZXJyb3IgY29kZSBGb3JiaWRkZW4gKDQwMykuICBOb3RlIGhv d2V2ZXIgdGhhdCBjb25zZW50XG4gICByZXZvY2F0aW9uIG1lc3NhZ2VzIGNhbiBiZSBsb3N0IG9u IHRoZSBuZXR3b3JrLCBzbyBhbiBlbmRwb2ludCBjb3VsZFxuICAgcmVzZW5kIHRoZXNlIG1lc3Nh Z2VzLCBvciB3YWl0IGZvciBjb25zZW50IHRvIGV4cGlyZS5cblxuICAgUmVjZWlwdCBvZiBhbiB1 bmF1dGhlbnRpY2F0ZWQgbWVzc2FnZSB0aGF0IGNsb3NlcyBhIGNvbm5lY3Rpb24gKGUuZy4sXG4g ICBUQ1AgRklOKSBkb2VzIG5vdCBpbmRpY2F0ZSByZXZvY2F0aW9uIG9mIGNvbnNlbnQuICBUaHVz LCBhbiBlbmRwb2ludFxuICAgcmVjZWl2aW5nIGFuIHVuYXV0aGVudGljYXRlZCBlbmQtb2Ytc2Vz c2lvbiBtZXNzYWdlIFNIT1VMRCBjb250aW51ZVxuICAgc2VuZGluZyBtZWRpYSAob3ZlciBjb25u ZWN0aW9ubGVzcyB0cmFuc3BvcnQpIG9yIGF0dGVtcHQgdG8gcmUtXG4gICBlc3RhYmxpc2ggdGhl IGNvbm5lY3Rpb24gKG92ZXIgY29ubmVjdGlvbi1vcmllbnRlZCB0cmFuc3BvcnQpIHVudGlsXG4g ICBjb25zZW50IGV4cGlyZXMgb3IgaXQgcmVjZWl2ZXMgYW4gYXV0aGVudGljYXRlZCBtZXNzYWdl IHJldm9raW5nXG4gICBjb25zZW50LlxuXG4gICBOb3RlIHRoYXQgYW4gYXV0aGVudGljYXRlZCBT UlRDUCBCWUUgZG9lcyBub3QgdGVybWluYXRlIGNvbnNlbnQ7IGl0XG4gICBvbmx5IGluZGljYXRl cyB0aGUgYXNzb2NpYXRlZCBTUlRQIHNvdXJjZSBoYXMgcXVpdC5cblxuXG5cblxuXG5QZXJ1bWFs LCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDUsIDIwMTUgICAgICAgICAgICAgICAg W1BhZ2UgNV1cbl9cbkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBG cmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNVxuXG5cbjUuICBEaWZmU2VydiBUcmVhdG1lbnQg Zm9yIENvbnNlbnRcblxuICAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBTVFVOIGNvbnNlbnQgY2hl Y2tzIHVzZSB0aGUgc2FtZSBEaWZmc2VydlxuICAgQ29kZXBvaW50IG1hcmtpbmdzIGFzIHRoZSBJ Q0UgY29ubmVjdGl2aXR5IGNoZWNrcyBkZXNjcmliZWQgaW5cbiAgIFNlY3Rpb24gNy4xLjIuNCBv ZiBbUkZDNTI0NV0gZm9yIGEgZ2l2ZW4gNS10dXBsZS5cblxuICAgTm90ZTogIEl0IGlzIHBvc3Np YmxlIHRoYXQgZGlmZmVyZW50IERpZmZzZXJ2IENvZGVwb2ludHMgYXJlIHVzZWQgYnlcbiAgICAg IGRpZmZlcmVudCBtZWRpYSBvdmVyIHRoZSBzYW1lIHRyYW5zcG9ydCBhZGRyZXNzXG4gICAgICBb SS1ELmlldGYtdHN2d2ctcnRjd2ViLXFvc10uICBTdWNoIGEgY2FzZSBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZlxuICAgICAgdGhpcyBkb2N1bWVudC5cblxuNi4gIERUTFMgYXBwbGljYWJpbGl0eVxu XG4gICBUaGUgRFRMUyBhcHBsaWNhYmlsaXR5IGlzIGlkZW50aWNhbCB0byB3aGF0IGlzIGRlc2Ny aWJlZCBpblxuICAgU2VjdGlvbiA0LjIgb2YgW1JGQzczNTBdLlxuXG43LiAgQVBJIFJlY29tbWVu ZGF0aW9uc1xuXG4gICBUaGUgVzNDIHNwZWNpZmljYXRpb24gW1czQy1XRUJSVENdIG1heSBwcm92 aWRlIGFuIEFQSSBob29rIHRoYXRcbiAgIGdlbmVyYXRlcyBhbiBldmVudCB3aGVuIGNvbnNlbnQg aGFzIGV4cGlyZWQgZm9yIGEgZ2l2ZW4gNS10dXBsZSxcbiAgIG1lYW5pbmcgdGhhdCB0cmFuc21p c3Npb24gb2YgZGF0YSBoYXMgY2Vhc2VkLiAgVGhpcyBjb3VsZCBpbmRpY2F0ZVxuICAgd2hhdCBh cHBsaWNhdGlvbiBkYXRhIGlzIGFmZmVjdGVkLCBzdWNoIGFzIG1lZGlhIG9yIGRhdGEgY2hhbm5l bHMuXG5cbjguICBTZWN1cml0eSBDb25zaWRlcmF0aW9uc1xuXG4gICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhIHNlY3VyaXR5IG1lY2hhbmlzbS5cblxuICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIGRpc2N1c3NlZCBpbiBbUkZDNTI0NV0gc2hvdWxkIGFsc28gYmVcbiAgIHRha2VuIGlu dG8gYWNjb3VudC5cblxuICAgU1JUUCBpcyBlbmNyeXB0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQgd2l0 aCBzeW1tZXRyaWMga2V5czsgdGhhdCBpcyxcbiAgIGJvdGggc2VuZGVyIGFuZCByZWNlaXZlciBr bm93IHRoZSBrZXlzLiAgV2l0aCB0d28gcGFydHkgc2Vzc2lvbnMsXG4gICByZWNlaXB0IG9mIGFu IGF1dGhlbnRpY2F0ZWQgcGFja2V0IGZyb20gdGhlIHNpbmdsZSByZW1vdGUgcGFydHkgaXMgYVxu ICAgc3Ryb25nIGFzc3VyYW5jZSB0aGUgcGFja2V0IGNhbWUgZnJvbSB0aGF0IHBhcnR5LiAgSG93 ZXZlciwgd2hlbiBhXG4gICBzZXNzaW9uIGludm9sdmVzIG1vcmUgdGhhbiB0d28gcGFydGllcywg YWxsIG9mIHdob20ga25vdyBlYWNoIG90aGVyc1xuICAga2V5cywgYW55IG9mIHRob3NlIHBhcnRp ZXMgY291bGQgaGF2ZSBzZW50IChvciBzcG9vZmVkKSB0aGUgcGFja2V0LlxuICAgU3VjaCBzaGFy ZWQga2V5IGRpc3RyaWJ1dGlvbnMgYXJlIHBvc3NpYmxlIHdpdGggc29tZSBNSUtFWSBbUkZDMzgz MF1cbiAgIG1vZGVzLCBTZWN1cml0eSBEZXNjcmlwdGlvbnMgW1JGQzQ1NjhdLCBhbmQgRUtUXG4g ICBbSS1ELmlldGYtYXZ0Y29yZS1zcnRwLWVrdF0uICBUaHVzLCBpbiBzdWNoIHNoYXJlZCBrZXlp bmdcbiAgIGRpc3RyaWJ1dGlvbnMsIHJlY2VpcHQgb2YgYW4gYXV0aGVudGljYXRlZCBTUlRQIHBh Y2tldCBpcyBub3RcbiAgIHN1ZmZpY2llbnQgdG8gdmVyaWZ5IGNvbnNlbnQuXG5cbjkuICBJQU5B IENvbnNpZGVyYXRpb25zXG5cbiAgIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgcmVxdWlyZSBhbnkg YWN0aW9uIGZyb20gSUFOQS5cblxuXG5cblxuXG5cblBlcnVtYWwsIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgNSwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSA2XVxuX1xuSW50ZXJu ZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAgICAg IE1heSAyMDE1XG5cblxuMTAuICBBY2tub3dsZWRnZW1lbnRcblxuICAgVGhhbmtzIHRvIEVyaWMg UmVzY29ybGEsIEhhcmFsZCBBbHZlc3RyYW5kLCBCZXJuYXJkIEFib2JhLCBNYWdudXNcbiAgIFdl c3RlcmxhbmQsIEN1bGxlbiBKZW5uaW5ncywgQ2hyaXN0ZXIgSG9sbWJlcmcsIFNpbW9uIFBlcnJl YXVsdCwgUGF1bFxuICAgS3l6aXZhdCwgRW1pbCBJdm92LCBKb25hdGhhbiBMZW5ub3gsIEluYWtp IEJheiBDYXN0aWxsbywgUmFqbW9oYW5cbiAgIEJhbmF2aSBhbmQgQ2hyaXN0aWFuIEdyb3ZlcyBm b3IgdGhlaXIgdmFsdWFibGUgaW5wdXRzIGFuZCBjb21tZW50cy5cbiAgIFRoYW5rcyB0byBDaHJp c3RlciBIb2xtYmVyZyBmb3IgZG9pbmcgYSB0aHJvdWdoIHJldmlldy5cblxuMTEuICBSZWZlcmVu Y2VzXG5cbjExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlc1xuXG4gICBbUkZDMjExOV0gIEJyYWRu ZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZVxuICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Llxu XG4gICBbUkZDNDA4Nl0gIEVhc3RsYWtlLCBELiwgU2NoaWxsZXIsIEouLCBhbmQgUy4gQ3JvY2tl ciwgIlJhbmRvbW5lc3NcbiAgICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTZWN1cml0eSIs IEJDUCAxMDYsIFJGQyA0MDg2LCBKdW5lIDIwMDUuXG5cbiAgIFtSRkM1MjQ1XSAgUm9zZW5iZXJn LCBKLiwgIkludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50XG4gICAgICAgICAg ICAgIChJQ0UpOiBBIFByb3RvY29sIGZvciBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvciAoTkFU KVxuICAgICAgICAgICAgICBUcmF2ZXJzYWwgZm9yIE9mZmVyL0Fuc3dlciBQcm90b2NvbHMiLCBS RkMgNTI0NSwgQXByaWxcbiAgICAgICAgICAgICAgMjAxMC5cblxuICAgW1JGQzYyNjNdICBNYXJq b3UsIFguIGFuZCBBLiBTb2xsYXVkLCAiQXBwbGljYXRpb24gTWVjaGFuaXNtIGZvclxuICAgICAg ICAgICAgICBLZWVwaW5nIEFsaXZlIHRoZSBOQVQgTWFwcGluZ3MgQXNzb2NpYXRlZCB3aXRoIFJU UCAvIFJUUFxuICAgICAgICAgICAgICBDb250cm9sIFByb3RvY29sIChSVENQKSBGbG93cyIsIFJG QyA2MjYzLCBKdW5lIDIwMTEuXG5cbjExLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzXG5cbiAg IFtJLUQuaWV0Zi1hdnRjb3JlLXNydHAtZWt0XVxuICAgICAgICAgICAgICBNYXR0c3NvbiwgSi4s IE1jR3JldywgRC4sIGFuZCBELiBXaW5nLCAiRW5jcnlwdGVkIEtleVxuICAgICAgICAgICAgICBU cmFuc3BvcnQgZm9yIFNlY3VyZSBSVFAiLCBkcmFmdC1pZXRmLWF2dGNvcmUtc3J0cC1la3QtMDNc biAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBPY3RvYmVyIDIwMTQuXG5cbiAgIFtJ LUQuaWV0Zi1ydGN3ZWItb3ZlcnZpZXddXG4gICAgICAgICAgICAgIEFsdmVzdHJhbmQsIEguLCAi T3ZlcnZpZXc6IFJlYWwgVGltZSBQcm90b2NvbHMgZm9yXG4gICAgICAgICAgICAgIEJyb3dzZXIt YmFzZWQgQXBwbGljYXRpb25zIiwgZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXctMTNcbiAgICAg ICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBOb3ZlbWJlciAyMDE0LlxuXG4gICBbSS1ELmll dGYtdHN2d2ctcnRjd2ViLXFvc11cbiAgICAgICAgICAgICAgRGhlc2lrYW4sIFMuLCBKZW5uaW5n cywgQy4sIERydXRhLCBELiwgSm9uZXMsIFAuLCBhbmQgSi5cbiAgICAgICAgICAgICAgUG9saywg IkRTQ1AgYW5kIG90aGVyIHBhY2tldCBtYXJraW5ncyBmb3IgUlRDV2ViIFFvUyIsXG4gICAgICAg ICAgICAgIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0wMyAod29yayBpbiBwcm9ncmVzcyks XG4gICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTQuXG5cbiAgIFtSRkMzODMwXSAgQXJra28sIEou LCBDYXJyYXJhLCBFLiwgTGluZGhvbG0sIEYuLCBOYXNsdW5kLCBNLiwgYW5kIEsuXG4gICAgICAg ICAgICAgIE5vcnJtYW4sICJNSUtFWTogTXVsdGltZWRpYSBJbnRlcm5ldCBLRVlpbmciLCBSRkMg MzgzMCxcbiAgICAgICAgICAgICAgQXVndXN0IDIwMDQuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4g ICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDUsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgN11c bl9cbkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3Mg ICAgICAgICAgICBNYXkgMjAxNVxuXG5cbiAgIFtSRkM0NTY4XSAgQW5kcmVhc2VuLCBGLiwgQmF1 Z2hlciwgTS4sIGFuZCBELiBXaW5nLCAiU2Vzc2lvblxuICAgICAgICAgICAgICBEZXNjcmlwdGlv biBQcm90b2NvbCAoU0RQKSBTZWN1cml0eSBEZXNjcmlwdGlvbnMgZm9yIE1lZGlhXG4gICAgICAg ICAgICAgIFN0cmVhbXMiLCBSRkMgNDU2OCwgSnVseSAyMDA2LlxuXG4gICBbUkZDNDk1M10gIFRv dWNoLCBKLiwgIkRlZmVuZGluZyBUQ1AgQWdhaW5zdCBTcG9vZmluZyBBdHRhY2tzIiwgUkZDXG4g ICAgICAgICAgICAgIDQ5NTMsIEp1bHkgMjAwNy5cblxuICAgW1JGQzU5NjFdICBSYW1haWFoLCBB LiwgU3Rld2FydCwgUi4sIGFuZCBNLiBEYWxhbCwgIkltcHJvdmluZyBUQ1BcJ3NcbiAgICAgICAg ICAgICAgUm9idXN0bmVzcyB0byBCbGluZCBJbi1XaW5kb3cgQXR0YWNrcyIsIFJGQyA1OTYxLCBB dWd1c3RcbiAgICAgICAgICAgICAgMjAxMC5cblxuICAgW1JGQzYwNjJdICBQZXJyZWF1bHQsIFMu IGFuZCBKLiBSb3NlbmJlcmcsICJUcmF2ZXJzYWwgVXNpbmcgUmVsYXlzXG4gICAgICAgICAgICAg IGFyb3VuZCBOQVQgKFRVUk4pIEV4dGVuc2lvbnMgZm9yIFRDUCBBbGxvY2F0aW9ucyIsIFJGQ1xu ICAgICAgICAgICAgICA2MDYyLCBOb3ZlbWJlciAyMDEwLlxuXG4gICBbUkZDNzM1MF0gIFBldGl0 LUh1Z3VlbmluLCBNLiBhbmQgRy4gU2FsZ3VlaXJvLCAiRGF0YWdyYW0gVHJhbnNwb3J0XG4gICAg ICAgICAgICAgIExheWVyIFNlY3VyaXR5IChEVExTKSBhcyBUcmFuc3BvcnQgZm9yIFNlc3Npb24g VHJhdmVyc2FsXG4gICAgICAgICAgICAgIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKSIsIFJGQyA3 MzUwLCBBdWd1c3QgMjAxNC5cblxuICAgW1czQy1XRUJSVENdXG4gICAgICAgICAgICAgIEJlcmdr dmlzdCwgQS4sIEJ1cm5ldHQsIEQuLCBOYXJheWFuYW4sIEEuLCBhbmQgQy5cbiAgICAgICAgICAg ICAgSmVubmluZ3MsICJXZWJSVEMgMS4wOiBSZWFsLXRpbWUgQ29tbXVuaWNhdGlvbiBCZXR3ZWVu XG4gICAgICAgICAgICAgIEJyb3dzZXJzIiwgZmVicnVhcnkgMjAxNS5cblxuQXV0aG9yc1wnIEFk ZHJlc3Nlc1xuXG4gICBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWxcbiAgIEVyaWNzc29uXG4gICBG ZXJucyBJY29uXG4gICBEb2RkYW5la3VuZGksIE1haGFkZXZhcHVyYVxuICAgQmFuZ2Fsb3JlLCBL YXJuYXRha2EgIDU2MDAzN1xuICAgSW5kaWFcblxuICAgRW1haWw6IG11dGh1LmFydWxAZ21haWwu Y29tXG5cblxuICAgRGFuIFdpbmdcbiAgIENpc2NvIFN5c3RlbXNcbiAgIDgyMSBBbGRlciBEcml2 ZVxuICAgTWlscGl0YXMsIENhbGlmb3JuaWEgIDk1MDM1XG4gICBVU0FcblxuICAgRW1haWw6IGR3 aW5nQGNpc2NvLmNvbVxuXG5cblxuXG5cblxuXG5cblBlcnVtYWwsIGV0IGFsLiAgICAgICAgIEV4 cGlyZXMgTm92ZW1iZXIgNSwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSA4XVxuX1xuSW50ZXJu ZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAgICAgICAgICAg IE1heSAyMDE1XG5cblxuICAgUmFtIE1vaGFuIFJhdmluZHJhbmF0aFxuICAgQ2lzY28gU3lzdGVt c1xuICAgQ2Vzc25hIEJ1c2luZXNzIFBhcmtcbiAgIFNhcmphcHVyLU1hcmF0aGFoYWxsaSBPdXRl ciBSaW5nIFJvYWRcbiAgIEJhbmdhbG9yZSwgS2FybmF0YWthICA1NjAxMDNcbiAgIEluZGlhXG5c biAgIEVtYWlsOiBybW9oYW5yQGNpc2NvLmNvbVxuXG5cbiAgIFRpcnVtYWxlc3dhciBSZWRkeVxu ICAgQ2lzY28gU3lzdGVtc1xuICAgQ2Vzc25hIEJ1c2luZXNzIFBhcmssIFZhcnRodXIgSG9ibGlc biAgIFNhcmphcHVyIE1hcmF0aGFsbGkgT3V0ZXIgUmluZyBSb2FkXG4gICBCYW5nYWxvcmUsIEth cm5hdGFrYSAgNTYwMTAzXG4gICBJbmRpYVxuXG4gICBFbWFpbDogdGlyZWRkeUBjaXNjby5jb21c blxuXG4gICBNYXJ0aW4gVGhvbXNvblxuICAgTW96aWxsYVxuICAgU3VpdGUgMzAwXG4gICA2NTAg Q2FzdHJvIFN0cmVldFxuICAgTW91bnRhaW4gVmlldywgQ2FsaWZvcm5pYSAgOTQwNDFcbiAgIFVT XG5cbiAgIEVtYWlsOiBtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21cblxuXG5cblxuXG5cblxuXG5c blxuXG5cblxuXG5cblxuXG5cblxuXG5cblxuXG5QZXJ1bWFsLCBldCBhbC4gICAgICAgICBFeHBp cmVzIE5vdmVtYmVyIDUsIDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgOV1cbicsICd1cmwxJzog JycsICdzdWJtaXQnOiAnR2VuZXJhdGUgZGlmZicsICd1cmwyJzogJycsICctLW5ld2NvbG91cic6 ICdncmVlbid9IC0tPjwvYm9keT48L2h0bWw+ --_003_D176B2232E5DCrmohanrciscocom_ Content-Type: text/plain; name="draft-ietf-rtcweb-stun-consent-freshness-13.txt" Content-Description: draft-ietf-rtcweb-stun-consent-freshness-13.txt Content-Disposition: attachment; filename="draft-ietf-rtcweb-stun-consent-freshness-13.txt"; size=18817; creation-date="Mon, 11 May 2015 13:53:25 GMT"; modification-date="Mon, 11 May 2015 13:53:25 GMT" Content-ID: Content-Transfer-Encoding: base64 CgoKClJUQ1dFQiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTS4gUGVydW1hbApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBXaW5nCkV4cGly ZXM6IE5vdmVtYmVyIDEyLCAyMDE1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIFJh dmluZHJhbmF0aAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVC4gUmVkZHkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gVGhvbXNv bgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE1vemlsbGEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTWF5IDExLCAyMDE1CgoKICAgICAgICAgICAgICAgICAgICBT VFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcwogICAgICAgICAgICAgIGRyYWZ0LWlldGYt cnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTMKCkFic3RyYWN0CgogICBUbyBwcmV2ZW50 IHNlbmRpbmcgZXhjZXNzaXZlIHRyYWZmaWMgdG8gYW4gZW5kcG9pbnQsIHBlcmlvZGljIGNvbnNl bnQKICAgbmVlZHMgdG8gYmUgb2J0YWluZWQgZnJvbSB0aGF0IHJlbW90ZSBlbmRwb2ludC4KCiAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgY29uc2VudCBtZWNoYW5pc20gdXNpbmcgYSBuZXcg U2Vzc2lvbgogICBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pIHVzYWdlLgoKU3Rh dHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQ IDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50 ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC0KICAgRHJhZnRzIGlzIGF0 IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90 aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFm dCB3aWxsIGV4cGlyZSBvbiBOb3ZlbWJlciAxMiwgMjAxNS4KCkNvcHlyaWdodCBOb3RpY2UKCiAg IENvcHlyaWdodCAoYykgMjAxNSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVk IGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRo aXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVn YWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3Ry dXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAg cHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1l bnRzCgoKClBlcnVtYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTIsIDIwMTUg ICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBm b3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNQoKCiAgIGNhcmVmdWxseSwg YXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVj dAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRo aXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lv bnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0 aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50 cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDIKICAgMi4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICA0LiAgU29sdXRpb24gIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMKICAg ICA0LjEuICBFeHBpcmF0aW9uIG9mIENvbnNlbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICAzCiAgICAgNC4yLiAgSW1tZWRpYXRlIFJldm9jYXRpb24gb2YgQ29uc2VudCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQogICA1LiAgRGlmZlNlcnYgVHJlYXRtZW50IGZv ciBDb25zZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgNi4gIERUTFMg YXBwbGljYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICA2CiAgIDcuICBBUEkgUmVjb21tZW5kYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgNgogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgOS4gIElBTkEgQ29uc2lkZXJh dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgIDEw LiBBY2tub3dsZWRnZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgNwogICAxMS4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDcKICAgICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgICAgMTEuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NwogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDgKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRvIHByZXZlbnQgYXR0YWNr cyBvbiBwZWVycywgZW5kcG9pbnRzIGhhdmUgdG8gZW5zdXJlIHRoZSByZW1vdGUgcGVlcgogICBp cyB3aWxsaW5nIHRvIHJlY2VpdmUgdHJhZmZpYy4gIFRoaXMgaXMgcGVyZm9ybWVkIGJvdGggd2hl biB0aGUKICAgc2Vzc2lvbiBpcyBmaXJzdCBlc3RhYmxpc2hlZCB0byB0aGUgcmVtb3RlIHBlZXIg dXNpbmcgSW50ZXJhY3RpdmUKICAgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgSUNFIFtSRkM1 MjQ1XSBjb25uZWN0aXZpdHkgY2hlY2tzLCBhbmQKICAgcGVyaW9kaWNhbGx5IGZvciB0aGUgZHVy YXRpb24gb2YgdGhlIHNlc3Npb24gdXNpbmcgdGhlIHByb2NlZHVyZXMKICAgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50LgoKICAgV2hlbiBhIHNlc3Npb24gaXMgZmlyc3QgZXN0YWJsaXNoZWQsIElD RSBpbXBsZW1lbnRhdGlvbnMgb2J0YWluIGFuCiAgIGluaXRpYWwgY29uc2VudCB0byBzZW5kIGJ5 IHBlcmZvcm1pbmcgU1RVTiBjb25uZWN0aXZpdHkgY2hlY2tzLiAgVGhpcwogICBkb2N1bWVudCBk ZXNjcmliZXMgYSBuZXcgU1RVTiB1c2FnZSB3aXRoIGV4Y2hhbmdlIG9mIHJlcXVlc3QgYW5kCiAg IHJlc3BvbnNlIG1lc3NhZ2VzIHRoYXQgdmVyaWZpZXMgdGhlIHJlbW90ZSBwZWVyJ3Mgb25nb2lu ZyBjb25zZW50IHRvCiAgIHJlY2VpdmUgdHJhZmZpYy4gIFRoaXMgY29uc2VudCBleHBpcmVzIGFm dGVyIGEgcGVyaW9kIG9mIHRpbWUgYW5kCiAgIG5lZWRzIHRvIGJlIGNvbnRpbnVhbGx5IHJlbmV3 ZWQsIHdoaWNoIGVuc3VyZXMgdGhhdCBjb25zZW50IGNhbiBiZQogICB0ZXJtaW5hdGVkLgoKICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIHdoYXQgaXQgdGFrZXMgdG8gb2J0YWluLCBtYWludGFpbiwg YW5kIGxvc2UKICAgY29uc2VudCB0byBzZW5kLiAgQ29uc2VudCB0byBzZW5kIGFwcGxpZXMgdG8g YSBzaW5nbGUgNS10dXBsZS4gIEhvdwogICBhcHBsaWNhdGlvbnMgcmVhY3QgdG8gY2hhbmdlcyBp biBjb25zZW50IGlzIG5vdCBkZXNjcmliZWQgaW4gdGhpcwogICBkb2N1bWVudC4KCgoKCgpQZXJ1 bWFsLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDEyLCAyMDE1ICAgICAgICAgICAg ICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgIFNUVU4gVXNhZ2UgZm9yIENvbnNlbnQg RnJlc2huZXNzICAgICAgICAgICAgTWF5IDIwMTUKCgogICBDb25zZW50IGlzIG9idGFpbmVkIG9u bHkgYnkgZnVsbCBJQ0UgaW1wbGVtZW50YXRpb25zLiAgQW4gSUNFLWxpdGUKICAgaW1wbGVtZW50 YXRpb24gd2lsbCBub3QgZ2VuZXJhdGUgY29uc2VudCBjaGVja3MsIGJ1dCB3aWxsIGp1c3QKICAg cmVzcG9uZCB0byBjb25zZW50IGNoZWNrcyBpdCByZWNlaXZlcy4gIE5vIGNoYW5nZXMgYXJlIHJl cXVpcmVkIHRvCiAgIElDRS1saXRlIGltcGxlbWVudGF0aW9ucyBpbiBvcmRlciB0byByZXNwb25k IHRvIGNvbnNlbnQgY2hlY2tzLCBhcwogICB0aGV5IGFyZSBwcm9jZXNzZWQgYXMgbm9ybWFsIElD RSBjb25uZWN0aXZpdHkgY2hlY2tzLgoKMi4gIFRlcm1pbm9sb2d5CgogICBUaGUga2V5IHdvcmRz ICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAg ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElP TkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmli ZWQgaW4gW1JGQzIxMTldLgoKICAgQ29uc2VudDogIFRoZSBtZWNoYW5pc20gb2Ygb2J0YWluaW5n IHBlcm1pc3Npb24gdG8gc2VuZCB0byBhIHJlbW90ZQogICAgICB0cmFuc3BvcnQgYWRkcmVzcy4g IEluaXRpYWwgY29uc2VudCBpcyBvYnRhaW5lZCB1c2luZyBJQ0UuCgogICBDb25zZW50IEZyZXNo bmVzczogIE1haW50YWluaW5nIGFuZCByZW5ld2luZyBjb25zZW50IG92ZXIgdGltZS4KCiAgIFRy YW5zcG9ydCBBZGRyZXNzOiAgVGhlIHJlbW90ZSBwZWVyJ3MgSVAgYWRkcmVzcyBhbmQgVURQIG9y IFRDUCBwb3J0CiAgICAgIG51bWJlci4KCjMuICBEZXNpZ24gQ29uc2lkZXJhdGlvbnMKCiAgIEFs dGhvdWdoIElDRSByZXF1aXJlcyBwZXJpb2RpYyBrZWVwYWxpdmUgdHJhZmZpYyB0byBrZWVwIE5B VCBiaW5kaW5ncwogICBhbGl2ZSAoU2VjdGlvbiAxMCBvZiBbUkZDNTI0NV0sIFtSRkM2MjYzXSks IHRob3NlIGtlZXBhbGl2ZXMgYXJlIHNlbnQKICAgYXMgU1RVTiBJbmRpY2F0aW9ucyB3aGljaCBh cmUgc2VuZC1hbmQtZm9yZ2V0LCBhbmQgZG8gbm90IGV2b2tlIGEKICAgcmVzcG9uc2UuICBBIHJl c3BvbnNlIGlzIG5lY2Vzc2FyeSBmb3IgY29uc2VudCB0byBjb250aW51ZSBzZW5kaW5nCiAgIHRy YWZmaWMuICBUaHVzLCB3ZSBuZWVkIGEgcmVxdWVzdC9yZXNwb25zZSBtZWNoYW5pc20gZm9yIGNv bnNlbnQKICAgZnJlc2huZXNzLiAgSUNFIGNhbiBiZSB1c2VkIGZvciB0aGF0IG1lY2hhbmlzbSBi ZWNhdXNlIElDRQogICBpbXBsZW1lbnRhdGlvbnMgYXJlIGFscmVhZHkgcmVxdWlyZWQgdG8gY29u dGludWUgbGlzdGVuaW5nIGZvciBJQ0UKICAgbWVzc2FnZXMsIGFzIGRlc2NyaWJlZCBpbiBzZWN0 aW9uIDEwIG9mIFtSRkM1MjQ1XS4gIElmIGNvbnNlbnQgaXMKICAgcGVyZm9ybWVkIHRoZW4gdGhl cmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZSBtZXNzYWdlcy4KCjQuICBTb2x1dGlvbgoK ICAgVGhlcmUgYXJlIHR3byB3YXlzIGNvbnNlbnQgdG8gc2VuZCB0cmFmZmljIGlzIHJldm9rZWQ6 IGV4cGlyYXRpb24gb2YKICAgY29uc2VudCBhbmQgaW1tZWRpYXRlIHJldm9jYXRpb24gb2YgY29u c2VudCwgd2hpY2ggYXJlIGRpc2N1c3NlZCBpbgogICB0aGUgZm9sbG93aW5nIHNlY3Rpb25zLgoK NC4xLiAgRXhwaXJhdGlvbiBvZiBDb25zZW50CgogICBBIGZ1bGwgSUNFIGltcGxlbWVudGF0aW9u IHBlcmZvcm1zIGNvbnNlbnQgZnJlc2huZXNzIHRlc3QgdXNpbmcgU1RVTgogICByZXF1ZXN0L3Jl c3BvbnNlIGFzIGRlc2NyaWJlZCBiZWxvdzoKCiAgIEFuIGVuZHBvaW50IE1VU1QgTk9UIHNlbmQg ZGF0YSBvdGhlciB0aGFuIHBhY2VkIFNUVU4gY29ubmVjdGl2aXR5CiAgIGNoZWNrcyBvciByZXNw b25zZXMgdG93YXJkIGFueSB0cmFuc3BvcnQgYWRkcmVzcyB1bmxlc3MgdGhlIHJlY2VpdmluZwog ICBlbmRwb2ludCBjb25zZW50cyB0byByZWNlaXZlIGRhdGEuICBUaGF0IGlzLCBubyBhcHBsaWNh dGlvbiBkYXRhCiAgIChlLmcuLCBSVFAgb3IgRFRMUykgY2FuIGJlIHNlbnQgdW50aWwgY29uc2Vu dCBpcyBvYnRhaW5lZC4gIEFmdGVyIGEKICAgc3VjY2Vzc2Z1bCBJQ0UgY29ubmVjdGl2aXR5IGNo ZWNrIG9uIGEgcGFydGljdWxhciB0cmFuc3BvcnQgYWRkcmVzcywKCgoKUGVydW1hbCwgZXQgYWwu ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxMiwgMjAxNSAgICAgICAgICAgICAgIFtQYWdlIDNd CgwKSW50ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBDb25zZW50IEZyZXNobmVzcyAg ICAgICAgICAgIE1heSAyMDE1CgoKICAgY29uc2VudCBNVVNUIGJlIG1haW50YWluZWQgZm9sbG93 aW5nIHRoZSBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIHRoaXMKICAgZG9jdW1lbnQuCgogICBFeHBs aWNpdCBjb25zZW50IHRvIHNlbmQgaXMgb2J0YWluZWQgYW5kIG1haW50YWluZWQgYnkgc2VuZGlu ZyBhbgogICBTVFVOIGJpbmRpbmcgcmVxdWVzdCB0byB0aGUgcmVtb3RlIHBlZXIncyB0cmFuc3Bv cnQgYWRkcmVzcyBhbmQKICAgcmVjZWl2aW5nIGEgbWF0Y2hpbmcsIGF1dGhlbnRpY2F0ZWQsIG5v bi1lcnJvciBTVFVOIGJpbmRpbmcgcmVzcG9uc2UKICAgZnJvbSB0aGUgcmVtb3RlIHBlZXIncyB0 cmFuc3BvcnQgYWRkcmVzcy4gIFRoZXNlIFNUVU4gYmluZGluZwogICByZXF1ZXN0cyBhbmQgcmVz cG9uc2VzIGFyZSBhdXRoZW50aWNhdGVkIHVzaW5nIHRoZSBzYW1lIHNob3J0LXRlcm0KICAgY3Jl ZGVudGlhbHMgYXMgdGhlIGluaXRpYWwgSUNFIGV4Y2hhbmdlLgoKICAgTm90ZTogIEFsdGhvdWdo IFRDUCBoYXMgaXRzIG93biBjb25zZW50IG1lY2hhbmlzbSAoVENQCiAgICAgIGFja25vd2xlZGdl bWVudHMpLCBjb25zZW50IGlzIG5lY2Vzc2FyeSBvdmVyIGEgVENQIGNvbm5lY3Rpb24KICAgICAg YmVjYXVzZSBpdCBjb3VsZCBiZSB0cmFuc2xhdGVkIHRvIGEgVURQIGNvbm5lY3Rpb24gKGUuZy4s CiAgICAgIFtSRkM2MDYyXSkuCgogICBJbml0aWFsIGNvbnNlbnQgdG8gc2VuZCB0cmFmZmljIGlz IG9idGFpbmVkIHVzaW5nIElDRS4gIENvbnNlbnQKICAgZXhwaXJlcyBhZnRlciAzMCBzZWNvbmRz LiAgVGhhdCBpcywgaWYgYSB2YWxpZCBTVFVOIGJpbmRpbmcgcmVzcG9uc2UKICAgY29ycmVzcG9u ZGluZyB0byBhbnkgU1RVTiByZXF1ZXN0IHNlbnQgaW4gdGhlIGxhc3QgMzAgc2Vjb25kcyBoYXMg bm90CiAgIGJlZW4gcmVjZWl2ZWQgZnJvbSB0aGUgcmVtb3RlIHBlZXIncyB0cmFuc3BvcnQgYWRk cmVzcywgdGhlIGVuZHBvaW50CiAgIE1VU1QgY2Vhc2UgdHJhbnNtaXNzaW9uIG9uIHRoYXQgNS10 dXBsZS4gIFNUVU4gY29uc2VudCByZXNwb25zZXMKICAgcmVjZWl2ZWQgYWZ0ZXIgY29uc2VudCBl eHBpcnkgZG8gbm90IHJlLWVzdGFibGlzaCBjb25zZW50LCBhbmQgbWF5IGJlCiAgIGRpc2NhcmRl ZCBvciBjYXVzZSBhbiBJQ01QIGVycm9yLgoKICAgVG8gcHJldmVudCBleHBpcnkgb2YgY29uc2Vu dCwgYSBTVFVOIGJpbmRpbmcgcmVxdWVzdCBjYW4gYmUgc2VudAogICBwZXJpb2RpY2FsbHkuICBU byBwcmV2ZW50IHN5bmNocm9uaXphdGlvbiBvZiBjb25zZW50IGNoZWNrcywgZWFjaAogICBpbnRl cnZhbCBNVVNUIGJlIHJhbmRvbWl6ZWQgZnJvbSBiZXR3ZWVuIDAuOCBhbmQgMS4yIHRpbWVzIHRo ZSBiYXNpYwogICBwZXJpb2QuICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIHNldCBhIGRlZmF1bHQg aW50ZXJ2YWwgb2YgNSBzZWNvbmRzLAogICByZXN1bHRpbmcgaW4gYSBwZXJpb2QgYmV0d2VlbiBj aGVja3Mgb2YgNCB0byA2IHNlY29uZHMuCgogICBFYWNoIFNUVU4gYmluZGluZyByZXF1ZXN0IGZv ciBjb25zZW50IE1VU1QgdXNlIGEgbmV3CiAgIGNyeXB0b2dyYXBoaWNhbGx5IHN0cm9uZyBbUkZD NDA4Nl0gU1RVTiB0cmFuc2FjdGlvbiBJRC4gIEVhY2ggU1RVTgogICBiaW5kaW5nIHJlcXVlc3Rz IGZvciBjb25zZW50IGlzIHRyYW5zbWl0dGVkIG9uY2Ugb25seS4gIEhlbmNlLCB0aGUKICAgc2Vu ZGVyIGNhbm5vdCBhc3N1bWUgdGhhdCBpdCB3aWxsIHJlY2VpdmUgYSByZXNwb25zZSBmb3IgZWFj aCBjb25zZW50CiAgIHJlcXVlc3QsIGFuZCBhIHJlc3BvbnNlIG1pZ2h0IGJlIGZvciBhIHByZXZp b3VzIHJlcXVlc3QgKHJhdGhlciB0aGFuCiAgIGZvciB0aGUgbW9zdCByZWNlbnRseSBzZW50IHJl cXVlc3QpLiAgQ29uc2VudCBleHBpcmF0aW9uIGNhdXNlcwogICBpbW1lZGlhdGUgdGVybWluYXRp b24gb2YgYWxsIG91dHN0YW5kaW5nIFNUVU4gY29uc2VudCB0cmFuc2FjdGlvbnMuCiAgIEVhY2gg U1RVTiB0cmFuc2FjdGlvbiBpcyBtYWludGFpbmVkIHVudGlsIG9uZSBvZiB0aGUgZm9sbG93aW5n CiAgIGNyaXRlcmlhIGlzIGZ1bGZpbGxlZDoKCiAgIG8gIEEgU1RVTiByZXNwb25zZSBhc3NvY2lh dGVkIHdpdGggdGhlIHRyYW5zYWN0aW9uIGlzIHJlY2VpdmVkOyBvcgoKICAgbyAgQSBTVFVOIHJl c3BvbnNlIGFzc29jaWF0ZWQgdG8gYSBuZXdlciB0cmFuc2FjdGlvbiBpcyByZWNlaXZlZC4KCiAg IFRvIG1lZXQgdGhlIHNlY3VyaXR5IG5lZWRzIG9mIGNvbnNlbnQsIGFuIHVudHJ1c3RlZCBhcHBs aWNhdGlvbgogICAoZS5nLiwgSmF2YVNjcmlwdCBvciBzaWduYWxpbmcgc2VydmVycykgTVVTVCBO T1QgYmUgYWJsZSB0byBvYnRhaW4gb3IKICAgY29udHJvbCB0aGUgU1RVTiB0cmFuc2FjdGlvbiBJ RCwgYmVjYXVzZSB0aGF0IGVuYWJsZXMgc3Bvb2Zpbmcgb2YKICAgU1RVTiByZXNwb25zZXMsIGZh bHNpZnlpbmcgY29uc2VudC4KCgoKClBlcnVtYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92 ZW1iZXIgMTIsIDIwMTUgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAg ICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNQoK CiAgIFRvIHByZXZlbnQgYXR0YWNrcyBvbiB0aGUgcGVlciBkdXJpbmcgSUNFIHJlc3RhcnQsIGFu IGVuZHBvaW50IHRoYXQKICAgY29udGludWVzIHRvIHNlbmQgdHJhZmZpYyBvbiB0aGUgcHJldmlv dXNseSB2YWxpZGF0ZWQgY2FuZGlkYXRlIHBhaXIKICAgZHVyaW5nIElDRSByZXN0YXJ0IE1VU1Qg Y29udGludWUgdG8gcGVyZm9ybSBjb25zZW50IGZyZXNobmVzcyBvbiB0aGF0CiAgIGNhbmRpZGF0 ZSBwYWlyIGFzIGRlc2NyaWJlZCBlYXJsaWVyLgoKICAgV2hpbGUgVENQIGFmZm9yZHMgc29tZSBw cm90ZWN0aW9uIGZyb20gb2ZmLXBhdGggYXR0YWNrZXJzIChbUkZDNTk2MV0sCiAgIFtSRkM0OTUz XSksIHRoZXJlIGlzIHN0aWxsIGEgcmlzayBhbiBhdHRhY2tlciBjb3VsZCBjYXVzZSBhIFRDUAog ICBzZW5kZXIgdG8gc2VuZCBmb3JldmVyIGJ5IHNwb29maW5nIEFDS3MuICBUbyBwcmV2ZW50IHN1 Y2ggYW4gYXR0YWNrLAogICBjb25zZW50IGNoZWNrcyBNVVNUIGJlIHBlcmZvcm1lZCBvdmVyIGFs bCB0cmFuc3BvcnQgY29ubmVjdGlvbnMsCiAgIGluY2x1ZGluZyBUQ1AuICBJbiB0aGlzIHdheSwg YW4gb2ZmLXBhdGggYXR0YWNrZXIgc3Bvb2ZpbmcgVENQCiAgIHNlZ21lbnRzIGNhbiBub3QgY2F1 c2UgYSBUQ1Agc2VuZGVyIHRvIHNlbmQgb25jZSB0aGUgY29uc2VudCB0aW1lcgogICBleHBpcmVz ICgzMCBzZWNvbmRzKS4KCiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFw cGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bwogICBtYWludGFpbiBjb25zZW50LiAgSG93 ZXZlciwgbm90IHNlbmRpbmcgYW55IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUCiAgIG9yIGZpcmV3 YWxsIG1hcHBpbmdzIHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lIHBlZXIgdW5h YmxlCiAgIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBBYnNlbnQg YmV0dGVyIGluZm9ybWF0aW9uCiAgIGFib3V0IHRoZSBuZXR3b3JrLCBpZiBhbiBlbmRwb2ludCBu ZWVkcyB0byBlbnN1cmUgaXRzIE5BVCBvciBmaXJld2FsbAogICBtYXBwaW5ncyBkbyBub3QgZXhw aXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXIKICAgdGVjaG5pcXVl cyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdIGFuZCBzZWUgW1JGQzYyNjNdKS4KCiAgIEFm dGVyIGNvbnNlbnQgaXMgbG9zdCBmb3IgYW55IHJlYXNvbiwgdGhlIHNhbWUgSUNFIGNyZWRlbnRp YWxzIE1VU1QKICAgTk9UIGJlIHVzZWQgb24gdGhlIGFmZmVjdGVkIDUtdHVwbGUgYWdhaW4uICBU aGF0IG1lYW5zIHRoYXQgYSBuZXcKICAgc2Vzc2lvbiwgb3IgYW4gSUNFIHJlc3RhcnQsIGlzIG5l ZWRlZCB0byBvYnRhaW4gY29uc2VudCB0byBzZW5kLgoKNC4yLiAgSW1tZWRpYXRlIFJldm9jYXRp b24gb2YgQ29uc2VudAoKICAgSW4gc29tZSBjYXNlcyBpdCBpcyB1c2VmdWwgdG8gc2lnbmFsIHRo YXQgY29uc2VudCBpcyB0ZXJtaW5hdGVkCiAgIHJhdGhlciB0aGFuIHJlbHlpbmcgb24gYSB0aW1l b3V0LgoKICAgQ29uc2VudCBmb3Igc2VuZGluZyBhcHBsaWNhdGlvbiBkYXRhIGlzIGltbWVkaWF0 ZWx5IHJldm9rZWQgYnkKICAgcmVjZWlwdCBvZiBhbiBhdXRoZW50aWNhdGVkIG1lc3NhZ2UgdGhh dCBjbG9zZXMgdGhlIGNvbm5lY3Rpb24gKGUuZy4sCiAgIGEgVExTIGZhdGFsIGFsZXJ0KSBvciBy ZWNlaXB0IG9mIGEgdmFsaWQgYW5kIGF1dGhlbnRpY2F0ZWQgU1RVTgogICByZXNwb25zZSB3aXRo IGVycm9yIGNvZGUgRm9yYmlkZGVuICg0MDMpLiAgTm90ZSBob3dldmVyIHRoYXQgY29uc2VudAog ICByZXZvY2F0aW9uIG1lc3NhZ2VzIGNhbiBiZSBsb3N0IG9uIHRoZSBuZXR3b3JrLCBzbyBhbiBl bmRwb2ludCBjb3VsZAogICByZXNlbmQgdGhlc2UgbWVzc2FnZXMsIG9yIHdhaXQgZm9yIGNvbnNl bnQgdG8gZXhwaXJlLgoKICAgUmVjZWlwdCBvZiBhbiB1bmF1dGhlbnRpY2F0ZWQgbWVzc2FnZSB0 aGF0IGNsb3NlcyBhIGNvbm5lY3Rpb24gKGUuZy4sCiAgIFRDUCBGSU4pIGRvZXMgbm90IGluZGlj YXRlIHJldm9jYXRpb24gb2YgY29uc2VudC4gIFRodXMsIGFuIGVuZHBvaW50CiAgIHJlY2Vpdmlu ZyBhbiB1bmF1dGhlbnRpY2F0ZWQgZW5kLW9mLXNlc3Npb24gbWVzc2FnZSBTSE9VTEQgY29udGlu dWUKICAgc2VuZGluZyBtZWRpYSAob3ZlciBjb25uZWN0aW9ubGVzcyB0cmFuc3BvcnQpIG9yIGF0 dGVtcHQgdG8gcmUtCiAgIGVzdGFibGlzaCB0aGUgY29ubmVjdGlvbiAob3ZlciBjb25uZWN0aW9u LW9yaWVudGVkIHRyYW5zcG9ydCkgdW50aWwKICAgY29uc2VudCBleHBpcmVzIG9yIGl0IHJlY2Vp dmVzIGFuIGF1dGhlbnRpY2F0ZWQgbWVzc2FnZSByZXZva2luZwogICBjb25zZW50LgoKICAgTm90 ZSB0aGF0IGFuIGF1dGhlbnRpY2F0ZWQgU1JUQ1AgQllFIGRvZXMgbm90IHRlcm1pbmF0ZSBjb25z ZW50OyBpdAogICBvbmx5IGluZGljYXRlcyB0aGUgYXNzb2NpYXRlZCBTUlRQIHNvdXJjZSBoYXMg cXVpdC4KCgoKClBlcnVtYWwsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTIsIDIw MTUgICAgICAgICAgICAgICBbUGFnZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2Fn ZSBmb3IgQ29uc2VudCBGcmVzaG5lc3MgICAgICAgICAgICBNYXkgMjAxNQoKCjUuICBEaWZmU2Vy diBUcmVhdG1lbnQgZm9yIENvbnNlbnQKCiAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgU1RVTiBj b25zZW50IGNoZWNrcyB1c2UgdGhlIHNhbWUgRGlmZnNlcnYKICAgQ29kZXBvaW50IG1hcmtpbmdz IGFzIHRoZSBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiA3 LjEuMi40IG9mIFtSRkM1MjQ1XSBmb3IgYSBnaXZlbiA1LXR1cGxlLgoKICAgTm90ZTogIEl0IGlz IHBvc3NpYmxlIHRoYXQgZGlmZmVyZW50IERpZmZzZXJ2IENvZGVwb2ludHMgYXJlIHVzZWQgYnkK ICAgICAgZGlmZmVyZW50IG1lZGlhIG92ZXIgdGhlIHNhbWUgdHJhbnNwb3J0IGFkZHJlc3MKICAg ICAgW0ktRC5pZXRmLXRzdndnLXJ0Y3dlYi1xb3NdLiAgU3VjaCBhIGNhc2UgaXMgb3V0c2lkZSB0 aGUgc2NvcGUgb2YKICAgICAgdGhpcyBkb2N1bWVudC4KCjYuICBEVExTIGFwcGxpY2FiaWxpdHkK CiAgIFRoZSBEVExTIGFwcGxpY2FiaWxpdHkgaXMgaWRlbnRpY2FsIHRvIHdoYXQgaXMgZGVzY3Jp YmVkIGluCiAgIFNlY3Rpb24gNC4yIG9mIFtSRkM3MzUwXS4KCjcuICBBUEkgUmVjb21tZW5kYXRp b25zCgogICBUaGUgVzNDIHNwZWNpZmljYXRpb24gW1czQy1XRUJSVENdIG1heSBwcm92aWRlIGFu IEFQSSBob29rIHRoYXQKICAgZ2VuZXJhdGVzIGFuIGV2ZW50IHdoZW4gY29uc2VudCBoYXMgZXhw aXJlZCBmb3IgYSBnaXZlbiA1LXR1cGxlLAogICBtZWFuaW5nIHRoYXQgdHJhbnNtaXNzaW9uIG9m IGRhdGEgaGFzIGNlYXNlZC4gIFRoaXMgY291bGQgaW5kaWNhdGUKICAgd2hhdCBhcHBsaWNhdGlv biBkYXRhIGlzIGFmZmVjdGVkLCBzdWNoIGFzIG1lZGlhIG9yIGRhdGEgY2hhbm5lbHMuCgo4LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2Vj dXJpdHkgbWVjaGFuaXNtLgoKICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRpc2N1c3Nl ZCBpbiBbUkZDNTI0NV0gc2hvdWxkIGFsc28gYmUKICAgdGFrZW4gaW50byBhY2NvdW50LgoKICAg U1JUUCBpcyBlbmNyeXB0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQgd2l0aCBzeW1tZXRyaWMga2V5czsg dGhhdCBpcywKICAgYm90aCBzZW5kZXIgYW5kIHJlY2VpdmVyIGtub3cgdGhlIGtleXMuICBXaXRo IHR3byBwYXJ0eSBzZXNzaW9ucywKICAgcmVjZWlwdCBvZiBhbiBhdXRoZW50aWNhdGVkIHBhY2tl dCBmcm9tIHRoZSBzaW5nbGUgcmVtb3RlIHBhcnR5IGlzIGEKICAgc3Ryb25nIGFzc3VyYW5jZSB0 aGUgcGFja2V0IGNhbWUgZnJvbSB0aGF0IHBhcnR5LiAgSG93ZXZlciwgd2hlbiBhCiAgIHNlc3Np b24gaW52b2x2ZXMgbW9yZSB0aGFuIHR3byBwYXJ0aWVzLCBhbGwgb2Ygd2hvbSBrbm93IGVhY2gg b3RoZXJzCiAgIGtleXMsIGFueSBvZiB0aG9zZSBwYXJ0aWVzIGNvdWxkIGhhdmUgc2VudCAob3Ig c3Bvb2ZlZCkgdGhlIHBhY2tldC4KICAgU3VjaCBzaGFyZWQga2V5IGRpc3RyaWJ1dGlvbnMgYXJl IHBvc3NpYmxlIHdpdGggc29tZSBNSUtFWSBbUkZDMzgzMF0KICAgbW9kZXMsIFNlY3VyaXR5IERl c2NyaXB0aW9ucyBbUkZDNDU2OF0sIGFuZCBFS1QKICAgW0ktRC5pZXRmLWF2dGNvcmUtc3J0cC1l a3RdLiAgVGh1cywgaW4gc3VjaCBzaGFyZWQga2V5aW5nCiAgIGRpc3RyaWJ1dGlvbnMsIHJlY2Vp cHQgb2YgYW4gYXV0aGVudGljYXRlZCBTUlRQIHBhY2tldCBpcyBub3QKICAgc3VmZmljaWVudCB0 byB2ZXJpZnkgY29uc2VudC4KCjkuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIGRvY3Vt ZW50IGRvZXMgbm90IHJlcXVpcmUgYW55IGFjdGlvbiBmcm9tIElBTkEuCgoKCgoKClBlcnVtYWws IGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTIsIDIwMTUgICAgICAgICAgICAgICBb UGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVz aG5lc3MgICAgICAgICAgICBNYXkgMjAxNQoKCjEwLiAgQWNrbm93bGVkZ2VtZW50CgogICBUaGFu a3MgdG8gRXJpYyBSZXNjb3JsYSwgSGFyYWxkIEFsdmVzdHJhbmQsIEJlcm5hcmQgQWJvYmEsIE1h Z251cwogICBXZXN0ZXJsYW5kLCBDdWxsZW4gSmVubmluZ3MsIENocmlzdGVyIEhvbG1iZXJnLCBT aW1vbiBQZXJyZWF1bHQsIFBhdWwKICAgS3l6aXZhdCwgRW1pbCBJdm92LCBKb25hdGhhbiBMZW5u b3gsIEluYWtpIEJheiBDYXN0aWxsbywgUmFqbW9oYW4KICAgQmFuYXZpIGFuZCBDaHJpc3RpYW4g R3JvdmVzIGZvciB0aGVpciB2YWx1YWJsZSBpbnB1dHMgYW5kIGNvbW1lbnRzLgogICBUaGFua3Mg dG8gQ2hyaXN0ZXIgSG9sbWJlcmcgZm9yIGRvaW5nIGEgdGhyb3VnaCByZXZpZXcuCgoxMS4gIFJl ZmVyZW5jZXMKCjExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFk bmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAg ICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoK ICAgW1JGQzQwODZdICBFYXN0bGFrZSwgRC4sIFNjaGlsbGVyLCBKLiwgYW5kIFMuIENyb2NrZXIs ICJSYW5kb21uZXNzCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBTZWN1cml0eSIsIEJD UCAxMDYsIFJGQyA0MDg2LCBKdW5lIDIwMDUuCgogICBbUkZDNTI0NV0gIFJvc2VuYmVyZywgSi4s ICJJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudAogICAgICAgICAgICAgIChJ Q0UpOiBBIFByb3RvY29sIGZvciBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvciAoTkFUKQogICAg ICAgICAgICAgIFRyYXZlcnNhbCBmb3IgT2ZmZXIvQW5zd2VyIFByb3RvY29scyIsIFJGQyA1MjQ1 LCBBcHJpbAogICAgICAgICAgICAgIDIwMTAuCgogICBbUkZDNjI2M10gIE1hcmpvdSwgWC4gYW5k IEEuIFNvbGxhdWQsICJBcHBsaWNhdGlvbiBNZWNoYW5pc20gZm9yCiAgICAgICAgICAgICAgS2Vl cGluZyBBbGl2ZSB0aGUgTkFUIE1hcHBpbmdzIEFzc29jaWF0ZWQgd2l0aCBSVFAgLyBSVFAKICAg ICAgICAgICAgICBDb250cm9sIFByb3RvY29sIChSVENQKSBGbG93cyIsIFJGQyA2MjYzLCBKdW5l IDIwMTEuCgoxMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0ktRC5pZXRmLWF2dGNv cmUtc3J0cC1la3RdCiAgICAgICAgICAgICAgTWF0dHNzb24sIEouLCBNY0dyZXcsIEQuLCBhbmQg RC4gV2luZywgIkVuY3J5cHRlZCBLZXkKICAgICAgICAgICAgICBUcmFuc3BvcnQgZm9yIFNlY3Vy ZSBSVFAiLCBkcmFmdC1pZXRmLWF2dGNvcmUtc3J0cC1la3QtMDMKICAgICAgICAgICAgICAod29y ayBpbiBwcm9ncmVzcyksIE9jdG9iZXIgMjAxNC4KCiAgIFtJLUQuaWV0Zi1ydGN3ZWItb3ZlcnZp ZXddCiAgICAgICAgICAgICAgQWx2ZXN0cmFuZCwgSC4sICJPdmVydmlldzogUmVhbCBUaW1lIFBy b3RvY29scyBmb3IKICAgICAgICAgICAgICBCcm93c2VyLWJhc2VkIEFwcGxpY2F0aW9ucyIsIGRy YWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3LTEzCiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jl c3MpLCBOb3ZlbWJlciAyMDE0LgoKICAgW0ktRC5pZXRmLXRzdndnLXJ0Y3dlYi1xb3NdCiAgICAg ICAgICAgICAgRGhlc2lrYW4sIFMuLCBKZW5uaW5ncywgQy4sIERydXRhLCBELiwgSm9uZXMsIFAu LCBhbmQgSi4KICAgICAgICAgICAgICBQb2xrLCAiRFNDUCBhbmQgb3RoZXIgcGFja2V0IG1hcmtp bmdzIGZvciBSVENXZWIgUW9TIiwKICAgICAgICAgICAgICBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dl Yi1xb3MtMDMgKHdvcmsgaW4gcHJvZ3Jlc3MpLAogICAgICAgICAgICAgIE5vdmVtYmVyIDIwMTQu CgogICBbUkZDMzgzMF0gIEFya2tvLCBKLiwgQ2FycmFyYSwgRS4sIExpbmRob2xtLCBGLiwgTmFz bHVuZCwgTS4sIGFuZCBLLgogICAgICAgICAgICAgIE5vcnJtYW4sICJNSUtFWTogTXVsdGltZWRp YSBJbnRlcm5ldCBLRVlpbmciLCBSRkMgMzgzMCwKICAgICAgICAgICAgICBBdWd1c3QgMjAwNC4K CgoKUGVydW1hbCwgZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxMiwgMjAxNSAgICAg ICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJuZXQtRHJhZnQgICAgICBTVFVOIFVzYWdlIGZvciBD b25zZW50IEZyZXNobmVzcyAgICAgICAgICAgIE1heSAyMDE1CgoKICAgW1JGQzQ1NjhdICBBbmRy ZWFzZW4sIEYuLCBCYXVnaGVyLCBNLiwgYW5kIEQuIFdpbmcsICJTZXNzaW9uCiAgICAgICAgICAg ICAgRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgU2VjdXJpdHkgRGVzY3JpcHRpb25zIGZvciBN ZWRpYQogICAgICAgICAgICAgIFN0cmVhbXMiLCBSRkMgNDU2OCwgSnVseSAyMDA2LgoKICAgW1JG QzQ5NTNdICBUb3VjaCwgSi4sICJEZWZlbmRpbmcgVENQIEFnYWluc3QgU3Bvb2ZpbmcgQXR0YWNr cyIsIFJGQwogICAgICAgICAgICAgIDQ5NTMsIEp1bHkgMjAwNy4KCiAgIFtSRkM1OTYxXSAgUmFt YWlhaCwgQS4sIFN0ZXdhcnQsIFIuLCBhbmQgTS4gRGFsYWwsICJJbXByb3ZpbmcgVENQJ3MKICAg ICAgICAgICAgICBSb2J1c3RuZXNzIHRvIEJsaW5kIEluLVdpbmRvdyBBdHRhY2tzIiwgUkZDIDU5 NjEsIEF1Z3VzdAogICAgICAgICAgICAgIDIwMTAuCgogICBbUkZDNjA2Ml0gIFBlcnJlYXVsdCwg Uy4gYW5kIEouIFJvc2VuYmVyZywgIlRyYXZlcnNhbCBVc2luZyBSZWxheXMKICAgICAgICAgICAg ICBhcm91bmQgTkFUIChUVVJOKSBFeHRlbnNpb25zIGZvciBUQ1AgQWxsb2NhdGlvbnMiLCBSRkMK ICAgICAgICAgICAgICA2MDYyLCBOb3ZlbWJlciAyMDEwLgoKICAgW1JGQzczNTBdICBQZXRpdC1I dWd1ZW5pbiwgTS4gYW5kIEcuIFNhbGd1ZWlybywgIkRhdGFncmFtIFRyYW5zcG9ydAogICAgICAg ICAgICAgIExheWVyIFNlY3VyaXR5IChEVExTKSBhcyBUcmFuc3BvcnQgZm9yIFNlc3Npb24gVHJh dmVyc2FsCiAgICAgICAgICAgICAgVXRpbGl0aWVzIGZvciBOQVQgKFNUVU4pIiwgUkZDIDczNTAs IEF1Z3VzdCAyMDE0LgoKICAgW1czQy1XRUJSVENdCiAgICAgICAgICAgICAgQmVyZ2t2aXN0LCBB LiwgQnVybmV0dCwgRC4sIE5hcmF5YW5hbiwgQS4sIGFuZCBDLgogICAgICAgICAgICAgIEplbm5p bmdzLCAiV2ViUlRDIDEuMDogUmVhbC10aW1lIENvbW11bmljYXRpb24gQmV0d2VlbgogICAgICAg ICAgICAgIEJyb3dzZXJzIiwgZmVicnVhcnkgMjAxNS4KCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAg TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsCiAgIEVyaWNzc29uCiAgIEZlcm5zIEljb24KICAgRG9k ZGFuZWt1bmRpLCBNYWhhZGV2YXB1cmEKICAgQmFuZ2Fsb3JlLCBLYXJuYXRha2EgIDU2MDAzNwog ICBJbmRpYQoKICAgRW1haWw6IG11dGh1LmFydWxAZ21haWwuY29tCgoKICAgRGFuIFdpbmcKICAg Q2lzY28gU3lzdGVtcwogICA4MjEgQWxkZXIgRHJpdmUKICAgTWlscGl0YXMsIENhbGlmb3JuaWEg IDk1MDM1CiAgIFVTQQoKICAgRW1haWw6IGR3aW5nQGNpc2NvLmNvbQoKCgoKCgoKClBlcnVtYWws IGV0IGFsLiAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMTIsIDIwMTUgICAgICAgICAgICAgICBb UGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgU1RVTiBVc2FnZSBmb3IgQ29uc2VudCBGcmVz aG5lc3MgICAgICAgICAgICBNYXkgMjAxNQoKCiAgIFJhbSBNb2hhbiBSYXZpbmRyYW5hdGgKICAg Q2lzY28gU3lzdGVtcwogICBDZXNzbmEgQnVzaW5lc3MgUGFyawogICBTYXJqYXB1ci1NYXJhdGhh aGFsbGkgT3V0ZXIgUmluZyBSb2FkCiAgIEJhbmdhbG9yZSwgS2FybmF0YWthICA1NjAxMDMKICAg SW5kaWEKCiAgIEVtYWlsOiBybW9oYW5yQGNpc2NvLmNvbQoKCiAgIFRpcnVtYWxlc3dhciBSZWRk eQogICBDaXNjbyBTeXN0ZW1zCiAgIENlc3NuYSBCdXNpbmVzcyBQYXJrLCBWYXJ0aHVyIEhvYmxp CiAgIFNhcmphcHVyIE1hcmF0aGFsbGkgT3V0ZXIgUmluZyBSb2FkCiAgIEJhbmdhbG9yZSwgS2Fy bmF0YWthICA1NjAxMDMKICAgSW5kaWEKCiAgIEVtYWlsOiB0aXJlZGR5QGNpc2NvLmNvbQoKCiAg IE1hcnRpbiBUaG9tc29uCiAgIE1vemlsbGEKICAgU3VpdGUgMzAwCiAgIDY1MCBDYXN0cm8gU3Ry ZWV0CiAgIE1vdW50YWluIFZpZXcsIENhbGlmb3JuaWEgIDk0MDQxCiAgIFVTCgogICBFbWFpbDog bWFydGluLnRob21zb25AZ21haWwuY29tCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGVydW1hbCwg ZXQgYWwuICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAxMiwgMjAxNSAgICAgICAgICAgICAgIFtQ YWdlIDldCg== --_003_D176B2232E5DCrmohanrciscocom_-- From nobody Tue May 12 13:36: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 6A6A91AD071 for ; Tue, 12 May 2015 13:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7HdKfEzAkVXN for ; Tue, 12 May 2015 13:36:34 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 046591AD06F for ; Tue, 12 May 2015 13:36:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D07E67C4CE6 for ; Tue, 12 May 2015 22:36:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEb1rbb5QIvu for ; Tue, 12 May 2015 22:36:31 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:6dea:5b1e:1a3d:ae56] (unknown [IPv6:2001:470:de0a:27:6dea:5b1e:1a3d:ae56]) by mork.alvestrand.no (Postfix) with ESMTPSA id 896CC7C4CE4 for ; Tue, 12 May 2015 22:36:31 +0200 (CEST) Message-ID: <5552644E.4040000@alvestrand.no> Date: Tue, 12 May 2015 22:36:30 +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: <552B7277.4060401@alvestrand.no> In-Reply-To: <552B7277.4060401@alvestrand.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] W3C Media Capture and Streams - Last Call review request X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 20:36:36 -0000 Just a reminder - the deadline for comments is May 15; at that time we'll try to make an evaluation based on the comments we've had so far. If someone really have comments you need to make, but won't get them ready by May 15, it's possible to drop us a note asking for later input to be considered. Harald Den 13. april 2015 09:38, skrev Harald Alvestrand: > To the chairs of the IETF RTCWEB working group (cc the group): > > The W3C WebRTC and Device APIs Working Groups request feedback on the > Last Call Working Draft of Media Capture and Streams, a JavaScript API > that enables access to cameras and microphones from Web browsers: > > http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/ > > This forms part of an interface that is intended to connect a Javascript > API with the functionality standardized in the IETF rtcweb working > group. Some aspects of this API relate to requirements from the RTCWEB > requirements draft, and we’d especially like feedback on those aspects; > we would welcome feedback from the IETF RTCWEB WG on this document. > > We naturally also welcome feedback from any other reviewers. > > The end of last call review for this specification is set to May 15; > should that deadline prove difficult to target, please get in touch so > that we can determine a new deadline. > > As indicated in the document, comments should be sent to the > public-media-capture@w3.org mailing list. > > Thanks, > > Harald Alvestrand and Stefan Hakansson, WebRTC Working Group Chairs and > Media Capture Task Force Chairs > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 13 15:29: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 B0C6C1AD291; Wed, 13 May 2015 15:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjuQCsHQNi3S; Wed, 13 May 2015 15:29:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9641ACEDE; Wed, 13 May 2015 15:29:27 -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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513222927.5331.57264.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 15:29:27 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 22:29:28 -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 : Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in WebRTC Authors : Benjamin M. Schwartz Justin Uberti Filename : draft-ietf-rtcweb-return-00.txt Pages : 18 Date : 2015-05-13 Abstract: In the context of WebRTC, the concept of a local TURN proxy has been suggested, but not reviewed in detail. WebRTC applications are already using TURN to enhance connectivity and privacy. This document explains how local TURN proxies and WebRTC applications can work together. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-return-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 16:59: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 72A081B31B9 for ; Wed, 13 May 2015 16:59:10 -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 gA9l54OklgO2 for ; Wed, 13 May 2015 16:59:08 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3831B31AC for ; Wed, 13 May 2015 16:59:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BB47220756 for ; Wed, 13 May 2015 19:59:07 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 13 May 2015 19:59:07 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=Do6 2zKjDUFJOFCY//ZmNqqJ6oHg=; b=F/OQ2rBH6MiG/AHzw+lx/JSPWdUsgHqumlk R7xo7eepD3pYTdbFy3DIn3df5B6yC1Vbzd552qWpNFcmKl3LnyigXs6KXOpWn4DE 7mb3eEEbCaseGwp6mzl7sAbcbFJcKoH7I223ggjRBwuA5x0+dx0tssXOr3IFYIIv JqFkl4tc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=Do62zKjDUFJOFCY//ZmNqqJ6oHg=; b=iqJS8 f+i9xmi8yUC1JmBrfljG/hB3df6DVEzs68OL8MWUIk6XDDg//3UZB6e3D0o4I5MO 9fQxbPrJHgz0RmX6hR10nzzkaasrnl72AbKNIwMn8bAXSTXYdZZtVXTjy28nzNRp InaUOOyeQLElGJiJr7CLVa6CweWb9dCxFE1kIU= X-Sasl-enc: YOnB+DgE4mvEPuMHCwLVgnQigPyKq4kJ9Pwck4FUPEyT 1431561547 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 35AC6C00013 for ; Wed, 13 May 2015 19:59:06 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in> Date: Wed, 13 May 2015 16:58:58 -0700 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [rtcweb] AD evaluation: 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, 13 May 2015 23:59:10 -0000 I have reviewed draft-ietf-rtcweb-rtp-usage-23 in preparation for IETF = LC. Overall, the document is in really good shape. I have requested the = LC, but I have a few substantive questions and suggestions I=92d like to = discuss while it is ongoing. I=92ve also included a list of nits to be = resolved together with any LC comments. =3D=3D=3D Substantive comments and questions =3D=3D=3D =3D=3D Section 7: "A future version of this memo will mandate the use of a congestion control algorithm that satisfies these requirements." I can appreciate the intent here, but I think it's unwise to make this = kind of guarantee while it's still unclear what RMCAT will produce and = when. I would suggest instead something like: "If a standardized congestion control algorithm that satisfies these = requirements is developed in the future, this memo may be updated to = mandate its use."=20 =3D=3D Section 11: "Note: this doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking." I don't quite get this note. Is this trying to say that using the same = CNAME in this case does not facilitate cross-service tracking because = the CNAME re-use only occurs within a single origin? =20 =3D=3D Section 12.1.3: OLD This is done according to three methods: NEW Three common methods for classifying IP packets are: =3D "When flow- based differentiation is available, the WebRTC Endpoint needs to know about it so that it can provide the separation of the RTP packet streams onto different UDP flows to enable a more granular usage of flow based differentiation." I feel like this needs a bit more explanation since I assume it's not = terribly commonplace for an endpoint to be able to find out that = flow-based differentiation is taking place. Is there some mechanism you = can point to that provides this information in some cases, or is this = basically saying "wouldn't it be nice if endpoints could find this out = somehow"? =3D I note that there is discussion of how DiffServ and flow-based = classification might work for RTP traffic in the WebRTC context, but not = DPI. Is there anything to be said, in particular given the SRTP = requirement? =3D=3D Section 13: "The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP middleboxes or third party monitoring that will greatly benefit from the information, and this has been expressed using API or signalling. If further evidence are produced to show that information leakage is significant from audio level indications, then use of encryption needs to be mandated at that time." =20 =20 I'm not sure that "known reasons" are quite enough to justify the = SHOULD-level requirement here. It would help if you could elaborate = specific legitimate use cases where a middlebox or a specific kind of = third party makes use of the audio level information and how that = information provides a great benefit. =20 =3D=3D=3D Nits =3D=3D=3D =3D=3D Section 4.1: OLD Support for the reduced minimum RTCP reporting interval described in Section 6.2 of [RFC3550] is REQUIRED. NEW Support for the reduced minimum RTCP reporting interval described in Section 6.2 of [RFC3550]. =20 =3D=3D Section 5.1.6: s/This can be various reasons for this/There can be various reasons for = this/ =3D=3D Section 7.1: OLD A WebRTC Endpoint receiving media SHOULD signal its bandwidth limitations, these limitations have to be based on known bandwidth limitations, for example the capacity of the edge links. NEW A WebRTC Endpoint receiving media SHOULD signal its bandwidth limitations. These limitations have to be based on known bandwidth limitations, for example the capacity of the edge links. =3D=3D Section 11: This sentence doesn't parse: "This, as the sending party needs to change the CNAME to the one it uses, which implies that the sender has to use a local system clock as timebase for the synchronisation." s/needs to defined/needs to be defined/ s/enables more efficient/enable more efficient/ =3D=3D Section 16: draft-ietf-mmusic-sdp-bundle-negotiation should not be listed as an = informative reference.= From nobody Wed May 13 17:18: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 8995A1B3246 for ; Wed, 13 May 2015 17:18:30 -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 Xb7oWpgImHo3 for ; Wed, 13 May 2015 17:18:29 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B8E1B3245 for ; Wed, 13 May 2015 17:18:29 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9ACE1209D4 for ; Wed, 13 May 2015 20:18:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 13 May 2015 20:18:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=tbU PWY9ZBTs2DaHzM+zDcvNrCIk=; b=X8aoZPD/eJjts/EAASNE25TW7MGYQP+EuKn CuN9GiPnjzkoHtYsn1BerFmyS+ViJAlXWSdKHNGEB55AT18Dlj/CVb5fAwhCEGA2 KJQ/LqiXwbCKEUVuXNylpz7yJCzPF5zK/+h1OmJ7KpklTjeUYmaX6Ens+5oNCBYo TWjDutZE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=tbUPWY9ZBTs2DaHzM+zDcvNrCIk=; b=YdzRF JZXIiq4940d6jCT2U5Dr+Dr8tuxi4m0F6Y2Aa6SgkV00wLvNUXKEsNBbydVYZDqF gylsx+mvrvtx/Z1TmdE/wM0XURPTXd3fzjrQepW7SR6bsjyprT3rPYJzCMygUh4H CDVMziIOOZO4TRta9Z4cTDop5VCP/9/DTp2uqQ= X-Sasl-enc: VTSWYmwVpQflAkSuE9T95Phwu1jLcnPCKAtx0aayD95O 1431562708 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id ED253C00018 for ; Wed, 13 May 2015 20:18:27 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 13 May 2015 17:18:18 -0700 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [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: Thu, 14 May 2015 00:18:30 -0000 I have reviewed draft-ietf-rtcweb-video-05 in preparation for IETF LC. = The document is in good shape and I have requested the last call. I have = a couple of questions and nits below that should be resolved together = with any LC comments. 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? Couple of nits in that section: 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.= From nobody Wed May 13 20:11: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 1D68E1B32B4; Wed, 13 May 2015 20:11:32 -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 ZZS-dPTVtp5H; Wed, 13 May 2015 20:11:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0731B32B7; Wed, 13 May 2015 20:11:30 -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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514031130.7309.41794.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 20:11:30 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 03:11:32 -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-13.txt Pages : 9 Date : 2015-05-13 Abstract: To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new 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-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-stun-consent-freshness-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 20:17: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 CF17D1B32B8 for ; Wed, 13 May 2015 20:17:04 -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 F1sZtksQcsbn for ; Wed, 13 May 2015 20:17:02 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C04D1A9098 for ; Wed, 13 May 2015 20:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2055; q=dns/txt; s=iport; t=1431573422; x=1432783022; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WCyP6mvC+YuSwDZ+PtjC3d/ODBZJ7hRY63DdhtJiuOo=; b=gffNxFbkhgksjy0iKa0d7gVYeSLVCVm1CrWkxM/uK18YiO3d7duKikc6 UfITeLg+U7/cU7UWU5pSw0YuLRxN/MlrhO0LamoFmkaRqtGOTdOzQAIIm 24t7o9uVMFBuiODGMetElmkmwl1yOB+gqNfW69oIargnyNPFhvVvTlYGk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBAAtElRV/5pdJa1cgw9UXgbEXgmBTgyFNU4CgTg4FAEBAQEBAQGBCoQgAQEBBAEBAWsXBAIBCBEDAQIvJwsdCAIEE4gsDdonAQEBAQEBAQMBAQEBAQEBARqLOoRSOgaEJwWLb4ZshCeGSoElPoMlkW4jg3dvgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,425,1427760000"; d="scan'208";a="149929488" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 14 May 2015 03:17:01 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4E3H1x2010186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 May 2015 03:17:01 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.121]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 13 May 2015 22:17:01 -0500 From: "Ram Mohan R (rmohanr)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-13.txt Thread-Index: AQHQjfRxucSuoX3EmEaH6BZ7wMbtxg== Date: Thu, 14 May 2015 03:17:00 +0000 Message-ID: References: <20150514031130.7309.41794.idtracker@ietfa.amsl.com> In-Reply-To: <20150514031130.7309.41794.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.78.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <10CB896C8392DF4584EAA5B1A762D6DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 03:17:05 -0000 This version addresses AD comments/Christer=B9s comments. Regards, Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Thursday, 14 May 2015 8:41 am To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-13.txt > >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-13.txt > Pages : 9 > Date : 2015-05-13 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new 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-13 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshne= ss >-13 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 13 20:18: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 D6B961B32B8 for ; Wed, 13 May 2015 20:18:33 -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 E8XBibpO1EXY for ; Wed, 13 May 2015 20:18:31 -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 C27FA1B32BC for ; Wed, 13 May 2015 20:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11622; q=dns/txt; s=iport; t=1431573511; x=1432783111; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8f+Z7LWH6Lrn7dD/JjEun412aTUc+tqji03BuTrGj4M=; b=a+IyoP/toZ72maAivuj11zaOCuEKuRQhN8rTaAiVbJq2lWvsS9AjYJOc OiWOdWirzrLMmNJDj1WhYI7HGEotg3q0ppY5HPi8RZraOf334P4cv6zsI J0x6C7Y9dnXc/ROJJxmxjWfZHfsAMmK+V1h+glR/RPp4OxbE+jqPJixHC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlBQAaE1RV/4cNJK1cgw9UXgaDGMMdDIU1TgIcgRxMAQEBAQEBgQuEIAEBAQQBAQExEycXBAIBCBEDAQEBAQQjBQICHwYLFAkIAgQBEogXAxINmHOcfwaFGZoDDYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4Ebih+CTYIFOgaCXIFLBZJbhCeEdYFVgSU+gyWKeIZ2I4FmghFvgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,425,1427760000"; d="scan'208";a="419640212" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 14 May 2015 03:18:29 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4E3ITQd004154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 03:18:29 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.121]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 13 May 2015 22:18:29 -0500 From: "Ram Mohan R (rmohanr)" To: Alissa Cooper , Christer Holmberg , "rtcweb@ietf.org" Thread-Topic: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 Thread-Index: AQHQjfSlNRq6SQBuQUqpM992EE341A== Date: Thu, 14 May 2015 03:18:28 +0000 Message-ID: References: <3B27E16C-2AD7-427B-864C-741F38575B97@cooperw.in> <3BE7E012-A474-4CEA-889A-B611EEFC4AEC@cooperw.in> <7594FB04B1934943A5C02806D1A2204B1D7EA1AE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EB649@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47833F10@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D7EBB8D@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D7EBCDD@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.78.73] Content-Type: text/plain; charset="euc-kr" Content-ID: <195EF8E033082F42924A596451B771BC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 03:18:34 -0000 SGkgQWxpc3NhL0FsbCwNCg0KSSBqdXN0IHB1Ymxpc2hlZCB0aGUgcmV2aXNpb24gdGhhdCBhZGRy ZXNzIGJlbG93IGNvbW1lbnRzLiBMaW5rIC0NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MvDQpEaWZmIC0gDQpo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1j b25zZW50LWZyZXNobmVzcw0KDQpSZWdhcmRzLA0KUmFtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBDaXNjbyBFbXBsb3llZSA8cm1vaGFuckBjaXNjby5jb20+DQpEYXRlOiBN b25kYXksIDExIE1heSAyMDE1IDc6MjQgcG0NClRvOiBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29v cGVydy5pbj4sIENocmlzdGVyIEhvbG1iZXJnDQo8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPiwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NCkNjOiAiVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSIgPHRpcmVkZHlAY2lzY28uY29tPiwgInJ0Y3dlYkBp ZXRmLm9yZyINCjxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQUQgZXZh bHVhdGlvbjoNCmRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTENCg0K PkF0dGFjaGVkIGlzIHRoZSBkaWZmcyB3aXRoIGNvbW1lbnQgZnJvbSBDaHJpc3RlciBpbmNvcnBv cmF0ZWQuIFBsZWFzZSBsZXQNCj5tZSBrbm93IGlmIGFueSBvbmUgZWxzZSBoYXMgY29tbWVudHMu IElmIG5vdCBJIHdpbGwgcHVibGlzaCB0aGlzIGRpZmYgYXMgYQ0KPm5ldyByZXZpc2lvbi4NCj4N Cj5SZWdhcmRzLA0KPlJhbQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTog QWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4+DQo+RGF0ZTogRnJpZGF5LCA4IE1heSAy MDE1IDY6NDEgcG0NCj5UbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4NCj5DYzogQ2lzY28gRW1wbG95ZWUgPHJtb2hhbnJAY2lzY28uY29tPiwgIlRp cnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkiDQo+PHRpcmVkZHlAY2lzY28uY29tPiwgTWFydGlu IFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4sDQo+InJ0Y3dlYkBpZXRmLm9yZyIg PHJ0Y3dlYkBpZXRmLm9yZz4NCj5TdWJqZWN0OiBSZTogW3J0Y3dlYl0gQUQgZXZhbHVhdGlvbjoN Cj5kcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTExDQo+DQo+Pk9rIHdp dGggbWUuDQo+PkFsaXNzYQ0KPj4NCj4+T24gTWF5IDcsIDIwMTUsIGF0IDI6NDkgQU0sIENocmlz dGVyIEhvbG1iZXJnDQo+PjxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0K Pj4NCj4+PiBIaSwNCj4+PiANCj4+PiBUaGUgdGV4dCBsb29rcyBvaywgYnV0IEkgdGhpbmsgd2Ug Y2FuIHNpbXBsaWZ5L2NsYXJpZnkgaXQgYSBsaXR0bGUuDQo+Pj4gDQo+Pj4gRm9yIGV4YW1wbGUs IHRoZSB1c2FnZSBvZiAiZmxvdyIgaXMgYSBsaXR0bGUgc3RyYW5nZSwgc2luY2Ugd2UNCj4+PmV4 cGxpY2l0bHkgc2F5IHRoYXQgbm8gbWVkaWEgaXMgc2VudCA6KQ0KPj4+IA0KPj4+IEFsc28sICJm YWlsdXJlIiBpcyB0aGUgd3Jvbmcgd29yZGluZyBpbiBteSBvcGluaW9uLCBiZWNhdXNlIHRoZXJl IGlzIG5vDQo+Pj5mYWlsdXJlLg0KPj4+IA0KPj4+IFdoYXQgYWJvdXQ6DQo+Pj4gDQo+Pj4gICBB biBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMg bm90IG5lZWQgdG8NCj4+PiAgIG1haW50YWluIGNvbnNlbnQuIEhvd2V2ZXIsIG5vdCBzZW5kaW5n IGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVCBvcg0KPj4+ICAgZmlyZXdhbGwgbWFwcGluZ3Mg dG8gZXhwaXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZyBvbmUgcGVlciB1bmFibGUgdG8NCj4+PnNl bmQgDQo+Pj4gICBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy4gIEFic2VudCBiZXR0 ZXIgaW5mb3JtYXRpb24gYWJvdXQNCj4+PnRoZSANCj4+PiAgIG5ldHdvcmssIGlmIGFuIGVuZHBv aW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsIG1hcHBpbmdzDQo+Pj5kbw0K Pj4+ICAgbm90IGV4cGlyZSwgaXQgY2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9yICBvdGhl ciB0ZWNobmlxdWVzIChzZWUNCj4+PiAgIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdIGFuZCBzZWUg W1JGQzYyNjNdKS4NCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IA0KPj4+IENocmlzdGVyDQo+Pj4g DQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBSYW0gTW9o YW4gUiAocm1vaGFucikgW21haWx0bzpybW9oYW5yQGNpc2NvLmNvbV0NCj4+PiBTZW50OiA3LiB0 b3Vrb2t1dXRhIDIwMTUgMTI6MTkNCj4+PiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSk7IEFsaXNzYSBDb29wZXI7DQo+Pj5NYXJ0aW4gVGhvbXNvbg0K Pj4+IENjOiBydGN3ZWJAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gQUQgZXZh bHVhdGlvbjoNCj4+PmRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTEN Cj4+PiANCj4+PiBIaSBDaHJpc3RlciwNCj4+PiANCj4+PiBIb3cgYWJvdXQgdGhlIGJlbG93IHRl eHQuIERvZXMgaXQgc291bmQgYmV0dGVyID8NCj4+PiANCj4+PiBPTEQ6DQo+Pj4gDQo+Pj4gICBB biBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMg bm90IG5lZWQgdG8NCj4+PiAgIG1haW50YWluIGNvbnNlbnQuICBIb3dldmVyLCBmYWlsdXJlIHRv IHNlbmQgY291bGQgY2F1c2UgYW55IE5BVCBvcg0KPj4+ICAgZmlyZXdhbGwgbWFwcGluZ3MgZm9y IHRoZSBmbG93IHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lDQo+Pj4gICBwZWVy IHVuYWJsZSB0byBzZW5kIGlzIGRldHJpbWVudGFsIHRvIG1hbnkgcHJvdG9jb2xzLiAgQWJzZW50 IGJldHRlcg0KPj4+ICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5ldHdvcmssIGFuIGVuZHBvaW50 IFNIT1VMRCBtYWludGFpbiBjb25zZW50IGlmDQo+Pj4gICB0aGVyZSBpcyBhbnkgcG9zc2liaWxp dHkgdGhhdCBhIGZsb3cgbWlnaHQgYmUgbmVlZGVkIGFnYWluLg0KPj4+IA0KPj4+IE5FVzoNCj4+ PiANCj4+PiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9u IGRhdGEgZG9lcyBub3QgbmVlZCB0bw0KPj4+ICAgbWFpbnRhaW4gY29uc2VudC4gSG93ZXZlciwg ZmFpbHVyZSB0byBzZW5kIGNvdWxkIGNhdXNlIGFueSBOQVQgb3INCj4+PiAgIGZpcmV3YWxsIG1h cHBpbmdzIGZvciB0aGUgZmxvdyB0byBleHBpcmUuICBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZQ0K Pj4+ICAgcGVlciB1bmFibGUgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29s cy4gIEFic2VudCBiZXR0ZXINCj4+PiAgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZXR3b3JrLCBp ZiBhbiBlbmRwb2ludCBuZWVkcyB0byBlbnN1cmUgaXRzIE5BVA0KPj4+ICAgb3IgZmlyZXdhbGwg bWFwcGluZ3MgcGVyc2lzdCB3aGljaCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3INCj4+ PiAgIG90aGVyIHRlY2huaXF1ZXMgKHNlZSBTZWN0aW9uIDEwIG9mIFtSRkM1MjQ1XSBhbmQgc2Vl IFtSRkM2MjYzXSkuDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gUmFtDQo+Pj4gDQo+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+IERhdGU6IFRodXJzZGF5LCA3IE1heSAyMDE1 IDI6NDAgcG0NCj4+PiBUbzogIlRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkiIDx0aXJlZGR5 QGNpc2NvLmNvbT4sIENpc2NvIEVtcGxveWVlDQo+Pj48cm1vaGFuckBjaXNjby5jb20+LCBBbGlz c2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4sIE1hcnRpbiBUaG9tc29uDQo+Pj48bWFydGlu LnRob21zb25AZ21haWwuY29tPg0KPj4+IENjOiAicnRjd2ViQGlldGYub3JnIiA8cnRjd2ViQGll dGYub3JnPg0KPj4+IFN1YmplY3Q6IFJFOiBbcnRjd2ViXSBBRCBldmFsdWF0aW9uOg0KPj4+IGRy YWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTENCj4+PiANCj4+Pj4gSGks DQo+Pj4+IA0KPj4+Pj4+PiBNYXJ0aW6p9nMgc3RhdGVtZW50IHNheXMgU0hPVUxEIGhlcmUgYW5k IGRvZXMgbm90IG1hbmRhdGUuIElDRQ0KPj4+Pj4+PiBrZWVwYWxpdmVzIGNvdWxkIGFsc28gYmUg dXNlZCB0byBrZWVwIHRoZSBOQVQgc3RhdGUNCj4+Pj4+PiANCj4+Pj4+PiBUaGVyZSBuZWVkcyB0 byBiZSBhIGdvb2QganVzdGlmaWNhdGlvbiBmb3IgYSBTSE9VTEQsIGFuZCBjb25zZW50IHdhcw0K Pj4+Pj4+IG5ldmVyIGludGVuZGVkIGZvciBOQVQga2VlcC1hbGl2ZXMuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gQWxzbyBrZWVwIGluIG1pbmQgdGhhdCwgd2l0aCB0aGUgInZpcnR1YWwgY29ubmVjdGlvbiIg Y29uY2VwdCwgdGhlcmUNCj4+Pj4+PiBtaWdodCBiZSBhIGJpZyBudW1iZXIgb2YgSUNFIGNvbm5l Y3Rpb25zIC0gc29tZSBvZiB3aGljaCB5b3UgbWF5DQo+Pj4+Pj4gbmV2ZXIgdXNlLiBXaHkgc2Vu ZCBjb25zZW50IG9uIHRob3NlLCBpZiB0aGVyZSBpcyBubyBtZWRpYT8NCj4+Pj4+IA0KPj4+Pj4g SUNFIGtlZXBhbGl2ZXMgb3IgY29uc2VudCBpcyBvbmx5IHJlcXVpcmVkIGZvciBjYW5kaWRhdGUg cGFpcnMNCj4+Pj4+IHNlbGVjdGVkIGZvciBtZWRpYSwNCj4+Pj4gDQo+Pj4+IENvcnJlY3QuIEJ1 dCwgeW91IG1heSBoYXZlIG11bHRpcGxlIGNhbmRpZGF0ZSBwYWlycyAic2VsZWN0ZWQgZm9yDQo+ Pj4+IG1lZGlhIiwgYnV0IHRoYXQgZG9lc24ndCBtZWFuIHlvdSBhcmUgc2VuZGluZyBtZWRpYSBv biBhbGwgb2YgdGhlbS4NCj4+Pj4gVmVyeSBsaWtlbHkgeW91IGFyZSwgYXQgYW55IGdpdmVuIHRp bWUsIG9ubHkgc2VuZGluZyBtZWRpYSBvbiBvbmUgb2YNCj4+Pj50aGVtLg0KPj4+PiANCj4+Pj4+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi0xMCBtYW5kYXRlcyBz ZW5kaW5nDQo+Pj4+PiBrZWVwYWxpdmVzIGlmIG5vIHBhY2tldCBpcyBzZW50IG9uIHRoZSBjYW5k aWRhdGUgcGFpciBJQ0UgaXMgdXNpbmcNCj4+Pj4+Zm9yIA0KPj4+Pj4gYSBtZWRpYSBjb21wb25l bnQgZm9yIFRyIHNlY29uZHMuIFNUVU4gQmluZGluZyBJbmRpY2F0aW9uIG9yIGNvbnNlbnQNCj4+ Pj4+IGNhbiBiZSB1c2VkIGZvciBrZWVwYWxpdmVzLg0KPj4+PiANCj4+Pj4gQ29ycmVjdC4gTXkg aXNzdWUgaXMgd2h5IHRoZXJlIHNob3VsZCBiZSBhICJTSE9VTEQgc2VuZCBjb25zZW50IiBvbg0K Pj4+PiBjYW5kaWRhdGUgcGFpcnMgY3VycmVudGx5IG5vdCB1c2VkIGZvciBzZW5kaW5nIG1lZGlh LiBJbiBzdWNoIGNhc2UsDQo+Pj4+IG9ubHkgdGhlIE5BVCBiaW5kaW5ncyBuZWVkIHRvIGJlIG1h aW50YWluZWQsIGFuZCB0aGUga2VlcC1hbGl2ZXMgdGFrZQ0KPj4+PiBjYXJlIG9mIHRoYXQuDQo+ Pj4+IA0KPj4+PiBSZWdhcmRzLA0KPj4+PiANCj4+Pj4gQ2hyaXN0ZXINCj4+Pj4gDQo+Pj4+IA0K Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+Pj4gRGF0 ZTogV2VkbmVzZGF5LCA2IE1heSAyMDE1IDEyOjIzIHBtDQo+Pj4+PiBUbzogQWxpc3NhIENvb3Bl ciA8YWxpc3NhQGNvb3BlcncuaW4+LCBNYXJ0aW4gVGhvbXNvbg0KPj4+Pj4gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbT4NCj4+Pj4+IENjOiAicnRjd2ViQGlldGYub3JnIiA8cnRjd2ViQGlldGYu b3JnPg0KPj4+Pj4gU3ViamVjdDogUmU6IFtydGN3ZWJdIEFEIGV2YWx1YXRpb246DQo+Pj4+PiBk cmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTExDQo+Pj4+PiANCj4+Pj4+ PiBIaSwNCj4+Pj4+PiANCj4+Pj4+PiBJIGRvbid0IHRoaW5rIHlvdSBuZWVkIHRvIGNvbnRpbnVl IGRvaW5nIGNvbnNlbnQgYmVjYXVzZSBvZiBOQVQNCj4+Pj4+PiBpc3N1ZXMsIGlmIHlvdSBhcmUg c2VuZGluZyBub3JtYWwgU1RVTiBrZWVwLWFsaXZlcy4NCj4+Pj4+PiANCj4+Pj4+PiBSZWdhcmRz LA0KPj4+Pj4+IA0KPj4+Pj4+IENocmlzdGVyDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsaXNzYQ0KPj4+Pj4+IENvb3Blcg0KPj4+Pj4+IFNl bnQ6IDIuIHRvdWtva3V1dGEgMjAxNSAyOjIwDQo+Pj4+Pj4gVG86IE1hcnRpbiBUaG9tc29uDQo+ Pj4+Pj4gQ2M6IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBB RCBldmFsdWF0aW9uOg0KPj4+Pj4+IGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVz aG5lc3MtMTENCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPbiBNYXkgMSwgMjAxNSwgYXQgOTo1 NCBBTSwgTWFydGluIFRob21zb24NCj4+Pj4+IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQo+ Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4+IE9uIDMwIEFwcmlsIDIwMTUgYXQgMTc6MzIs IEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPiB3cm90ZToNCj4+Pj4+Pj4+ICJBbiBl bmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90 DQo+Pj4+Pj4+PiBuZWVkDQo+Pj4+PiB0bw0KPj4+Pj4+Pj4gIG1haW50YWluIGNvbnNlbnQuICBI b3dldmVyLCBmYWlsdXJlIHRvIHNlbmQgY291bGQgY2F1c2UgYW55IE5BVA0KPj4+Pj4+Pj5vcg0K Pj4+Pj4+Pj4gIGZpcmV3YWxsIG1hcHBpbmdzIGZvciB0aGUgZmxvdyB0byBleHBpcmUuICBGdXJ0 aGVybW9yZSwgaGF2aW5nDQo+Pj4+Pj4+Pm9uZQ0KPj4+Pj4+Pj4gIHBlZXIgdW5hYmxlIHRvIHNl bmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuIg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBJdCBzb3VuZHMgbGlrZSB0aGUgdW5zdGF0ZWQgaW1wbGljYXRpb24gaGVyZSBpcyB0aGF0IGlm IHlvdSBhcmUNCj4+Pj4+Pj4+IHN1Y2ggYW4gZW5kcG9pbnQsIHlvdSBzaG91bGQga2VlcCBkb2lu ZyBjb25zZW50IGNoZWNrcyBhbnl3YXkgdG8NCj4+Pj4+Pj4+IG1haW50YWluIGNvbnNlbnQuIFNo b3VsZCB0aGF0IGJlIHN0YXRlZCBleHBsaWNpdGx5LCBvciBhbSBJDQo+Pj4+PiBtaXN1bmRlcnN0 YW5kaW5nPw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQ2FuIHlvdSB0ZWxsIHRoYXQgdGhpcyBpcyBteSB0 ZXh0Pw0KPj4+Pj4+PiANCj4+Pj4+Pj4gWWVwLCB0aGUgdW5zcG9rZW4gaW1wbGljYXRpb24gaXMg dGhhdCBpZiB5b3Ugc3RvcCBtYWludGFpbmluZw0KPj4+Pj4+PiBjb25zZW50LCBhIGZsb3cgaXMg aGlnaGx5IGxpa2VseSB0byBicmVhay4gIEknbSBPSyB3aXRoIG1ha2luZw0KPj4+Pj4+PiB0aGF0 DQo+Pj4+PiBleHBsaWNpdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IC4uLiAuICBBYnNlbnQgYmV0dGVy IGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZXR3b3JrLCBhbiBlbmRwb2ludA0KPj4+Pj4+PiBTSE9V TEQgbWFpbnRhaW4gY29uc2VudCBpZiB0aGVyZSBpcyBhbnkgcG9zc2liaWxpdHkgdGhhdCBhIGZs b3cNCj4+Pj4+Pj4gbWlnaHQgYmUgbmVlZGVkIGFnYWluLg0KPj4+Pj4+IA0KPj4+Pj4+IFdGTQ0K Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gKFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24gb24g U2VjNy4gIEkgd2Fzbid0IGhhcHB5IHdpdGggaXQNCj4+Pj4+Pj4gYmVmb3JlLikNCj4+Pj4+PiAN Cj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPj4+Pj4+IA0K Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4+PiANCj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+PiBydGN3ZWJAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4gDQo+Pg0KPg0KDQo= From nobody Thu May 14 05:01: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 B54B71A1BCB; Thu, 14 May 2015 05:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sTiRMpc3S4YW; Thu, 14 May 2015 05:01:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3DE1A023E; Thu, 14 May 2015 05:01:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150514120153.17983.12828.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 05:01:53 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (WebRTC Video Processing and Codec Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 12:01:54 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Video Processing and Codec Requirements' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu May 14 05:19: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 3818D1A0029 for ; Thu, 14 May 2015 05:19:26 -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 Aq1JIhvtCJ7R for ; Thu, 14 May 2015 05:19:24 -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 385DD1A0302 for ; Thu, 14 May 2015 05:19:24 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-08-555492cafa29 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.D6.04401.AC294555; Thu, 14 May 2015 14:19:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Thu, 14 May 2015 14:18:17 +0200 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-13.txt Thread-Index: AQHQjfPE2hqkB0CXS0ux+o+LSOnJE516q3MAgAC4zaA= Date: Thu, 14 May 2015 12:18:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D7F887D@ESESSMB209.ericsson.se> References: <20150514031130.7309.41794.idtracker@ietfa.amsl.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre6pSSGhBid/CFss79rBaLH2Xzu7 A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx5PFq9oI9whXTvj5ka2Dcxd/FyMkhIWAi sajrKDOELSZx4d56ti5GLg4hgaOMEj9+n4ZyFjNKnF7cw97FyMHBJmAh0f1PG6RBRCBMYvqJ BSwgtrBAsMTh88uYIeIhEm9f32CBsK0k9jx4ww5iswioSrzZuowRZAyvgK/Eowt+IGEhgVSJ HUcngZVwCuhLPH73iRXEZgS65/upNUwgNrOAuMStJ/OZIO4UkFiy5zzUzaISLx//Y4WwlSRW bL/ECFGvJ3Fj6hQ2CFtbYtnC12D1vAKCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU 4qTcdCNjvdSizOTi4vw8vbzUkk2MwCg5uOW36g7Gy28cDzEKcDAq8fAqFIWECrEmlhVX5h5i lOZgURLn9ewCCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk+GH/PZ5DRPueUfbsthW31FMe ehmu/5Z80PnJ/Qbx7Ck8WTvaZgVozSv5kX6hRzXdeyWjzZOkf0Z2j+Y2hbV3HIn8diBabJvs JN+aWi3Xtc8Pboy+8r3+KP/dbxqF0p9sdcUuh1fP9fzMEBUnsXVuw2QNmUmmjo5cU222m+7y 2pl8aKWC+gklluKMREMt5qLiRABL8/TrcwIAAA== Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 12:19:26 -0000 Thanks, Ram! Regards, Christer -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ram Mohan R (rmo= hanr) Sent: 14 May 2015 06:17 To: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-= 13.txt This version addresses AD comments/Christer=B9s comments. Regards, Ram -----Original Message----- From: "internet-drafts@ietf.org" Date: Thursday, 14 May 2015 8:41 am To: "i-d-announce@ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-13.txt > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Real-Time Communication in=20 >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-13.txt > Pages : 9 > Date : 2015-05-13 > >Abstract: > To prevent sending excessive traffic to an endpoint, periodic consent > needs to be obtained from that remote endpoint. > > This document describes a consent mechanism using a new 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-freshne >ss/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-13 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-stun-consent-freshn >ess >-13 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >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 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu May 14 05:34: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 BF53D1A9072; Thu, 14 May 2015 05:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SzW6r9BfcmBA; Thu, 14 May 2015 05:34:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5F1A902A; Thu, 14 May 2015 05:33:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150514123325.29826.37409.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 05:33:25 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Last Call: (Web Real-Time Communication (WebRTC): Media Transport and Use of RTP) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 12:34:45 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Web Real-Time Communication (WebRTC): Media Transport and Use of RTP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu May 14 16:21: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 104E51B2D10; Thu, 14 May 2015 16:21:36 -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 Q6Rm6-bBs8-2; Thu, 14 May 2015 16:21:33 -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 7198C1B2D05; Thu, 14 May 2015 16:21:33 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4ENLSmw025081 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 May 2015 19:21:29 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t4ENLSmw025081 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1431645689; bh=fz/+r8IBtyp3wSr/KffPFGCvYn8=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=LbonngiXRpfy1c87sOKv9h3vEBfmjmo13qJ6I2YjD3ysDC4MnQ+I72dnclLzegRyO +jgW5CRhrIfZjniNCqedvf+GAOGcXrhO0uEKtf1/nz1XtYzSrp/GcB8uhdmoC3FQQm z2WPaFbTNau0o4GWYgSO8U5nQtxwP9nq7L+w7cxM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t4ENLSmw025081 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd05.lss.emc.com (RSA Interceptor); Thu, 14 May 2015 19:20:59 -0400 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4ENLDev025807 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 May 2015 19:21:14 -0400 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub34.corp.emc.com (10.254.93.82) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 14 May 2015 19:21:13 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.21]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0224.002; Thu, 14 May 2015 19:21:13 -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-13 Thread-Index: AdCOnKf3lsrra0GlRrmLRbgZJ92NVg== Date: Thu, 14 May 2015 23:21:11 +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.131] 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: [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: Thu, 14 May 2015 23:21:36 -0000 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 attacks. -- 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 "paced" means in "paced STUN connectivity checks or responses." -- Nits/Editorial Comments -- The SRTP paragraph in Section 8 (Security Considerations) feels out of plac= e - 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 line 32= 0, 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 cryptographica= lly 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 dra= ft, 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 sente= nce 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 form= s 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 duratio= n of loss and re-establishment of consent-based connectivity, as such informa= tion has operational value. In particular, a discussion of how a server could i= nfer loss of connectivity with a client that is using this mechanism might be us= eful 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 - fau= lt management]. The primary operational impact of this protocol should be reduction in unwa= nted traffic, which is a benefit - the consent check traffic added by this proto= col should not have significant impacts. The writeup indicates that implemente= rs have reviewed the draft and implementations are in progress. [A.3 - Documen= tation] 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-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From nobody Thu May 14 16:29: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 F30471B2D78; Thu, 14 May 2015 16:29:24 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpHDGS_52Fur; Thu, 14 May 2015 16:29:20 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 C1FB31B2D6C; Thu, 14 May 2015 16:29:15 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:484:396b:f794:75d0]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t4ENT5hn010130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 May 2015 23:29:05 GMT (envelope-from joelja@bogus.com) To: "Black, David" , "muthu.arul@gmail.com" , "dwing@cisco.com" , "rmohanr@cisco.com" , "tireddy@cisco.com" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" references: From: joel jaeggli message-id: <55552FC0.8080103@bogus.com> Date: Thu, 14 May 2015 16:29:04 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 in-reply-to: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aH6uxfXwQVrMMUimi4RILx4SRcNtnS5vl" Archived-At: Cc: "rtcweb@ietf.org" , "ietf@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: Thu, 14 May 2015 23:29:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aH6uxfXwQVrMMUimi4RILx4SRcNtnS5vl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks David, I'll be looking with interest for the addressing of items 1/2. joel On 5/14/15 4:21 PM, Black, David wrote: > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG= =2E > These comments were written with the intent of improving the operationa= l > aspects of the IETF drafts. Comments that are not addressed in last cal= l > 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 applica= ble > to? Is this generally applicable wherever ICE and STUN are used? I do= n'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 referenc= e > should suffice. >=20 > [4] In Section 4.1, please explain or provide a reference for what "pac= ed" > means in "paced STUN connectivity checks or responses." >=20 > -- Nits/Editorial Comments -- >=20 > The SRTP paragraph in Section 8 (Security Considerations) feels out of = place > - this looks like design rationale material that would be better locate= d 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 lin= e 320, but > no explicit reference was found in the text >=20 > That reference is likely to be useful to address the absence of discuss= ion 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 proto= cols, > and can be implemented by one party to a communication session; ordinar= y > response generation behavior (already required) reflects the cryptograp= hically > strong STUN transaction IDs on which the mechanism is based. As a resu= lt, the > mechanism can be deployed at one end of a two-party communication sessi= on > 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] >=20 > 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] >=20 > There is an obvious fault condition, namely that consent is lost or rev= oked > causing immediate cessation of traffic. While the details depend on th= e > environment in which this mechanism is used, it'd be helpful to add a s= entence > 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 draf= t. > [A.1.8 - fault and threshold conditions] >=20 > 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)] >=20 > It might be useful to mention the utility of tracking frequency and dur= ation > of loss and re-establishment of consent-based connectivity, as such inf= ormation > has operational value. In particular, a discussion of how a server cou= ld infer > loss of connectivity with a client that is using this mechanism might b= e 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]. >=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 p= rotocol > should not have significant impacts. The writeup indicates that implem= enters > have reviewed the draft and implementations are in progress. [A.3 - Doc= umentation] >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 >=20 --aH6uxfXwQVrMMUimi4RILx4SRcNtnS5vl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlVVL8EACgkQ8AA1q7Z/VrIB+gCeKFtm6QR08QV5YC8YDg4OrfbN kQ4An05uzlqe1k123Fkdqk0cK2NLXxce =hv+a -----END PGP SIGNATURE----- --aH6uxfXwQVrMMUimi4RILx4SRcNtnS5vl-- From nobody Sun May 17 05:00: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 232951A870B for ; Sun, 17 May 2015 05:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbbAnQtSgwIP for ; Sun, 17 May 2015 05:00:33 -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 AC99F1A906D for ; Sun, 17 May 2015 05:00:33 -0700 (PDT) Received: from [82.132.245.123] (port=41016 helo=[10.168.26.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YtxF8-0002yW-Rz; Sun, 17 May 2015 13:00:32 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Colin Perkins X-Mailer: iPad Mail (12F69) In-Reply-To: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in> Date: Sun, 17 May 2015 13:00:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org> References: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in> To: Alissa Cooper X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: 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: Sun, 17 May 2015 12:00:36 -0000 Hi Alissa, Thanks for the review. Comments inline.=20 > On 14 May 2015, at 00:58, Alissa Cooper wrote: >=20 > I have reviewed draft-ietf-rtcweb-rtp-usage-23 in preparation for IETF LC.= Overall, the document is in really good shape. I have requested the LC, but= I have a few substantive questions and suggestions I=E2=80=99d like to disc= uss while it is ongoing. I=E2=80=99ve also included a list of nits to be res= olved together with any LC comments. >=20 > =3D=3D=3D Substantive comments and questions =3D=3D=3D >=20 > =3D=3D Section 7: >=20 > "A future version of this memo will mandate the use of a congestion > control algorithm that satisfies these requirements." >=20 > I can appreciate the intent here, but I think it's unwise to make this kin= d of guarantee while it's still unclear what RMCAT will produce and when. I w= ould suggest instead something like: >=20 > "If a standardized congestion control algorithm that satisfies these requi= rements is developed in the future, this memo may be updated to mandate its u= se." No objection on my part.=20 > =3D=3D Section 11: >=20 > "Note: this doesn't result in a tracking issue, since the creation > of matching CNAMEs depends on existing tracking." >=20 > I don't quite get this note. Is this trying to say that using the same CNA= ME in this case does not facilitate cross-service tracking because the CNAME= re-use only occurs within a single origin? =20 That's part of it. Also, that using the same CNAME for several streams that a= re part of a single call is okay, and indeed needed for lip-sync, since ther= e are other ways of telling that these streams are part of the same call. > =3D=3D Section 12.1.3: >=20 > OLD > This is done according to three methods: > NEW > Three common methods for classifying IP packets are: Sure. > =3D >=20 > "When flow- > based differentiation is available, the WebRTC Endpoint needs to know > about it so that it can provide the separation of the RTP packet > streams onto different UDP flows to enable a more granular usage of > flow based differentiation." >=20 > I feel like this needs a bit more explanation since I assume it's not terr= ibly commonplace for an endpoint to be able to find out that flow-based diff= erentiation is taking place. Is there some mechanism you can point to that p= rovides this information in some cases, or is this basically saying "wouldn'= t it be nice if endpoints could find this out somehow"? We could say "The use of flow-based differentiation needs to be signalled to= the WebRTC Endpoint, so it knows to provide the separation..."? The point i= s that the endpoint can't enable this without being told that it' so be used= , and what parameters are to be used.=20 > =3D >=20 > I note that there is discussion of how DiffServ and flow-based classificat= ion might work for RTP traffic in the WebRTC context, but not DPI. Is there a= nything to be said, in particular given the SRTP requirement? I'm happy to add some text, if you have any suggestions.=20 > =3D=3D Section 13: >=20 > "The use of the encryption of the header > extensions are RECOMMENDED, unless there are known reasons, like RTP > middleboxes or third party monitoring that will greatly benefit from > the information, and this has been expressed using API or signalling. > If further evidence are produced to show that information leakage is > significant from audio level indications, then use of encryption > needs to be mandated at that time." =20 >=20 > I'm not sure that "known reasons" are quite enough to justify the SHOULD-l= evel requirement here. It would help if you could elaborate specific legitim= ate use cases where a middlebox or a specific kind of third party makes use o= f the audio level information and how that information provides a great bene= fit. The issue is that middle boxes use the audio level information in the header= extensions to perform voice activity-based source switching. Sending audio l= evel information in the header extension is preferable to trusting the middl= e box with access to the media. We can add some words to explain this furthe= r, and perhaps a pointer to the PERC working group, if chartered? > =3D=3D=3D Nits =3D=3D=3D >=20 > =3D=3D Section 4.1: >=20 > OLD > Support for the reduced minimum RTCP reporting interval described > in Section 6.2 of [RFC3550] is REQUIRED. > NEW > Support for the reduced minimum RTCP reporting interval described > in Section 6.2 of [RFC3550]. >=20 > =3D=3D Section 5.1.6: > s/This can be various reasons for this/There can be various reasons for th= is/ >=20 > =3D=3D Section 7.1: >=20 > OLD > A WebRTC Endpoint receiving media SHOULD signal > its bandwidth limitations, these limitations have to be based on > known bandwidth limitations, for example the capacity of the edge > links. >=20 > NEW > A WebRTC Endpoint receiving media SHOULD signal > its bandwidth limitations. These limitations have to be based on > known bandwidth limitations, for example the capacity of the edge > links. Okay to all the above.=20 > =3D=3D Section 11: >=20 > This sentence doesn't parse: > "This, as the sending party needs to change the CNAME to the one it > uses, which implies that the sender has to use a local system clock > as timebase for the synchronisation." "Since the sending party needs to change the CNAME to the one it uses, this i= mplies it has to use..." > s/needs to defined/needs to be defined/ >=20 > s/enables more efficient/enable more efficient/ Okay. > =3D=3D Section 16: > draft-ietf-mmusic-sdp-bundle-negotiation should not be listed as an inform= ative reference. Why not? Cheers, Colin --=20 Colin Perkins http://csperkins.org/ From nobody Sun May 17 14:14: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 1B57B1ACEC4 for ; Sun, 17 May 2015 14:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ZV-CusboWJ for ; Sun, 17 May 2015 14:14:51 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E0C1AD0C7 for ; Sun, 17 May 2015 14:13:48 -0700 (PDT) Received: from [10.0.232.47] (unknown [205.158.164.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 965FD509BB; Sun, 17 May 2015 17:13:46 -0400 (EDT) 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: Date: Sun, 17 May 2015 14:13:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <91729460-43E8-43A2-8A95-57513EBC03B2@iii.ca> To: Justin Uberti X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] [Suspected Junk Mail] Importance of local addresses in ICE X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 21:14:53 -0000 The problem with surfacing a single host IP is it is very hard to choose = which one. As I pointed the idea of a default route is not as simple as = one might think. For example, on some things the default route depends = on the domain name you are trying to reach.=20 > On Apr 29, 2015, at 4:54 PM, Justin Uberti wrote: >=20 > Are you referring to our proposal where we surface the single host IP = used for contacting the STUN/TURN servers, or surfacing all host IPs? I = generally agree that surfacing a single host IP is important, especially = given CGN as you mention, but surfacing all may have fingerprinting = implications. >=20 > It would be good to get empirical data on how often host-host occurs = in the wild - if anyone is running a WebRTC service with p2p calls and = can get data on the %age of host-host candidate calls, that would be = greatly appreciated. (Hangouts is client-server.) >=20 > On Sun, Apr 26, 2015 at 8:24 PM, Cullen Jennings = wrote: > There has been some suggestion that the ICE should not advertise = candidates that were addresses from a NATed address space. I think it is = critical that we do and here is why. >=20 > Carrier Grade NATs (CGN) are becoming far more common in many = countries. Most measures of them show they are not friendly towards over = the top VoIP traffic (totally shocker given they are often deployed by = people offering a commercial voice service as well). So when you have = two user both behind the same GCN, if ICE does not expose the local = address, all of the traffic is forced thought the GCN (which may have = more jitter than you might hope) and to a TURN server. If the ICE = contained the local candidates then media would go directly through = between the devices. >=20 > CGN while not that common in the US is prevalent in many countries - = particularly ones that had less IPv4 addressed allocated to them. >=20 > Now you can say that this might reveal some information about their IP = address. But think about what we really wish the wold looked like. There = was no NAT and they had a IPv6 address. I have a hard time seeing how to = DHCP generated address behind the NAT is hugely different than a random = allocated v6 address so I don't see much downside on doing this and I = see huge upside - particularly for people that are working of a cellular = data link behind a CGN. >=20 > I am also think that in general, end to end is better for privacy than = forcing all your data through a MITM that the user does not control (the = TURN server and CGN in this case). >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Mon May 18 10:03: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 1E5661AD359; Mon, 18 May 2015 10:03:44 -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 UhRw9EBSK7Wz; Mon, 18 May 2015 10:03:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4611AD352; Mon, 18 May 2015 10:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2479; q=dns/txt; s=iport; t=1431968622; x=1433178222; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=jExbXwt7lT4eDugHZTTmGpQHIICFrYkfsOgsHSvk/mY=; b=Hg4a3odi56QxpF78b3c9MFM/LYDZ7bDSA5EeWM7tlx2p8LoI4zIugU2R HYhr1/IYhhgTdcmdjw1FS0edqnOtROaCGcCZ5+3fpJZDUycFPy/mOux0J 8+kV3UFSa9uiZhaazQoKyMEZOM6T+vaCxpetRYuFYxXhMQxpnvO2DHEYC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQBnGlpV/5RdJa1cgxBUXgbGT4V2AoE0TAEBAQEBAYELhCIBAQEEOksEAgEIEQMBAh8QMh0IAQEEARKILA3YRwEBAQEBAQEBAgEBAQEBAQEBGos6hQwGhCcFkmWEL4ZLgSc+gyqOJYNYI2GDF28BgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,454,1427760000"; d="scan'208";a="417537085" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-9.cisco.com with ESMTP; 18 May 2015 17:03:41 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4IH3faw028856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 May 2015 17:03:41 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.60]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Mon, 18 May 2015 12:03:41 -0500 From: "Ram Mohan R (rmohanr)" To: Meral Shirazipour , "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "gen-art@ietf.org" , "rtcweb@ietf.org" Thread-Topic: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCPTCeBLwIOGK4OTCGKJsw8iNXzOwCmJtAA Date: Mon, 18 May 2015 17:03:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.60.246] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Gen-ART Last Call 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, 18 May 2015 17:03:44 -0000 Hi Meral, Thanks for your feedback. See inline -----Original Message----- From: Meral Shirazipour Date: Saturday, 16 May 2015 1:47 am To: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "gen-art@ietf.org" Subject: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Resent-From: Resent-To: Resent-Date: Saturday, 16 May 2015 1:48 am >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at >http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > >Please resolve these comments along with any other Last Call comments you >may receive. > >Document: draft-ietf-rtcweb-stun-consent-freshness-13 >Reviewer: Meral Shirazipour >Review Date: 2015-05-15 >IETF LC End Date: 2015-05-15 >IESG Telechat date: NA > > >Summary: >This draft is ready to be published as Standards Track RFC but I have >some comments . > > > >Major issues: > >Minor issues: > >Nits/editorial comments: > >-The abstract lacks context, please consider adding some more text. A >suggestion: repeat the first sentence from the intro in the abstract: >"To prevent attacks on peers, endpoints have to ensure the remote peer is >willing to receive traffic." Sure we will add this text > >-[Page 2] Intro: It was not clear if this document is specific to webRTC >implementations. Is there any limitation to only use for webRTC? Maybe a >sentence in the intro could clarify if there is or there is not such >Limitation This document does not restrict itself to webRTC implementations alone which is the reason we have not specified any where that Consent freshness is for only webRTC clients. Any full ICE implementations can use Consent freshness. We have this text at the end of introduction in the current draft "This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. Consent is obtained only by full ICE implementations. An ICE-lite implementation will not generate consent checks, but will just respond to consent checks it receives." Is this not sufficient ? Regards, Ram From nobody Mon May 18 11:05: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 3EB781A6F12; Mon, 18 May 2015 11:01:39 -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 HiGVn7i7Eo95; Mon, 18 May 2015 11:01:32 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DEE11AD2D5; Mon, 18 May 2015 11:01:32 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-d8-5559d0692471 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 54.D9.32689.960D9555; Mon, 18 May 2015 13:43:37 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Mon, 18 May 2015 14:01:30 -0400 From: Meral Shirazipour To: "Ram Mohan R (rmohanr)" Thread-Topic: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCPTCeBLwIOGK4OTCGKJsw8iNXzOwCmJtAAABQ/LBA= Date: Mon, 18 May 2015 18:01:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPiG7mhchQgxf/9SxmX13IaHH11WcW i+VdOxgt1v5rZ3dg8ZjyeyOrx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV0bDoAUvBZb2K bwuesTYwzlTrYuTkkBAwkdixfzUbhC0mceHeeiCbi0NI4CijxOqXm8ASQgLLGSWun3YDsdkE LCS2/37OCmKLCOhLvNmwDKyBWeA8o8S8rj1MIAlhgTCJvS0djBBF4RJXpzeyQ9hWEkfWHQar YRFQldjQMhvM5hXwlZg4ZznQUA6gZUUSB86IgYQ5geYv//aXBcRmBDru+6k1YOXMAuISt57M Z4I4WkBiyZ7zzBC2qMTLx/9YIWxFiX3909kh6nUkFuz+xAZha0ssW/iaGWKtoMTJmU9YJjCK zUIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IYBMjMIaOSbDp7mDc89LyEKMAB6MSD++DeRGh QqyJZcWVuYcYpTlYlMR5vxmGhAoJpCeWpGanphakFsUXleakFh9iZOLglGpglJmqKJpnI292 cauWyNWGFyULN+04YDY/wWX9yvWFNn/DE6PK71TW3Tmw+6XdBuXrykXzSmZN2Bii62/P8vTw noht0h++6Aa7veo/e7m178rM5N9ZFwvq/7ntvH7L0VQgirFkW9nx1+zZcqtXnbG5sqKx8v4U 9v3K79qXFK/e8v20ev+fBHNPOSWW4oxEQy3mouJEABOEl4yCAgAA Archived-At: X-Mailman-Approved-At: Mon, 18 May 2015 11:05:13 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Gen-ART Last Call 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, 18 May 2015 18:01:39 -0000 Hi Ram, Thank you for the response. Please see in line. Also, I did not see resp= onse to the rest of the comments, not sure if it was cut from the email (pl= ease see below-I copy pasted the original email). Best regards, Meral -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Monday, May 18, 2015 10:04 AM To: Meral Shirazipour; draft-ietf-rtcweb-stun-consent-freshness.all@tools.i= etf.org; gen-art@ietf.org; rtcweb@ietf.org Subject: Re: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-fre= shness-13 Hi Meral, Thanks for your feedback. See inline -----Original Message----- From: Meral Shirazipour Date: Saturday, 16 May 2015 1:47 am To: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "gen-art@ietf.org" Subject: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Resent-From: Resent-To: Resent-Date: Saturday, 16 May 2015 1:48 am >I am the assigned Gen-ART reviewer for this draft. For background on=20 >Gen-ART, please see the FAQ at=20 >http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > >Please resolve these comments along with any other Last Call comments=20 >you may receive. > >Document: draft-ietf-rtcweb-stun-consent-freshness-13 >Reviewer: Meral Shirazipour >Review Date: 2015-05-15 >IETF LC End Date: 2015-05-15 >IESG Telechat date: NA > > >Summary: >This draft is ready to be published as Standards Track RFC but I have=20 >some comments . > > > >Major issues: > >Minor issues: > >Nits/editorial comments: > >-The abstract lacks context, please consider adding some more text. A >suggestion: repeat the first sentence from the intro in the abstract: >"To prevent attacks on peers, endpoints have to ensure the remote peer=20 >is willing to receive traffic." Sure we will add this text [Msh] thank you > >-[Page 2] Intro: It was not clear if this document is specific to=20 >webRTC implementations. Is there any limitation to only use for webRTC?=20 >Maybe a sentence in the intro could clarify if there is or there is not=20 >such Limitation This document does not restrict itself to webRTC implementations alone whic= h is the reason we have not specified any where that Consent freshness is f= or only webRTC clients. Any full ICE implementations can use Consent freshn= ess. We have this text at the end of introduction in the current draft "This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. Consent is obtained only by full ICE implementations. An ICE-lite implementation will not generate consent checks, but will just respond to consent checks it receives." Is this not sufficient ? [Msh] Somehow I had to read twice to deduce that. If you think that is suff= icient and there is no need to specifically state not limited to webRTC the= I am ok with it too. Regards, Ram From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Meral Shirazip= our Sent: Friday, May 15, 2015 1:18 PM To: draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; gen-art@ie= tf.org Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-rtcweb-stun-conse= nt-freshness-13 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenA= rtfaq.=20 Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-rtcweb-stun-consent-freshness-13=20 Reviewer: Meral Shirazipour Review Date: 2015-05-15 IETF LC End Date: 2015-05-15 IESG Telechat date: NA Summary: This draft is ready to be published as Standards Track RFC but I have some = comments . Major issues: Minor issues: Nits/editorial comments: -The abstract lacks context, please consider adding some more text. A sugge= stion: repeat the first sentence from the intro in the abstract:=20 "To prevent attacks on peers, endpoints have to ensure the remote peer is w= illing to receive traffic." -[Page 2] Intro: It was not clear if this document is specific to webRTC im= plementations. Is there any limitation to only use for webRTC? Maybe a sent= ence in the intro could clarify if there is or there is not such limitation= . -[Page 2] Intro, it would be good if the intro section could give a good ex= ample (use case, application) of when a receiving end would revoke the cons= ent during the session.(why closing the session is not enough)=20 -[Page 3], Section2, "Transport Address" definition. It would be good to cl= arify this wrt 5-tuple. The two terms are used interchangeably, yet Transpo= rt address carries only destination IP protocol port, not the sender's (as = carried in 5-tuple). e.g. [Page 4]:"....the remote peer's transport address, the endpoint MUST c= ease transmission on that 5-tuple." -[Page 4] "Initial consent to send traffic is obtained using ICE. Consent = expires after 30 seconds." =20 Is this value specified by [RFC6062] or this document? not clear. -[Page 4-5]Section 4.1 addresses security issues. Section 8 adds additional= content on security. It would be best to consolidate or at least have Sect= ion 8 point back to 4.1. nits: -[Page 5], "can not cause"--->"cannot cause" -[Page 6], "each others keys"--->"each other's keys" -[Page 7], typo "through review"--->"thorough review" -SRTCP,DTLs, etc. please spell out acronyms at first use. Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com From nobody Tue May 19 07:52: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 95CC01ACD0C; Tue, 19 May 2015 07:52:04 -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 PnIRHRWnm1Cc; Tue, 19 May 2015 07:51:59 -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 5D5EA1B3004; Tue, 19 May 2015 07:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16623; q=dns/txt; s=iport; t=1432046973; x=1433256573; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GDmujqVjw/qTtmDIavT5NBk2dvoI1qPz1V6jwWF/Buc=; b=QiGfoYpFbz8J7yf5op25GCgfVJAC05HNvNGgnK6k6lp0DMoaHe0SXssh oucgTPbtrGViM8Uf6s39AVWm+ZHCKuCc5bWXGcgETeUF2OVg1d7pLI7lQ iBUiRVL3hqLGFCaaOsdtUJFGeZVu8uTXPZSdX3jSA7odxkmG0CQBQxkCt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BaBAAOTFtV/4UNJK1cgxBUXgbFBwmBWoV2AoE8OBQBAQEBAQEBgQqEIgEBAQQnQBIMBAIBCBEDAQEBKAcyFAkIAgQOBQ6IHg3ScAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoQiCgcBQBEHBgOEJAEEi3aGdoIPgiKGTYEnPoMrgn2LKoNZI2GBBSQcgVJvAYECCRcCIYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,458,1427760000"; d="scan'208";a="151483247" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 19 May 2015 14:49:32 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4JEnV5E029032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 May 2015 14:49:31 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.60]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Tue, 19 May 2015 09:49:31 -0500 From: "Ram Mohan R (rmohanr)" To: Meral Shirazipour Thread-Topic: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQkYyj3TSzfN5u2U2hX6WyQgId5A== Date: Tue, 19 May 2015 14:49:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.39.182] Content-Type: multipart/mixed; boundary="_002_D180B0BB2FF13rmohanrciscocom_" MIME-Version: 1.0 Archived-At: Cc: "gen-art@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Gen-ART Last Call 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, 19 May 2015 14:52:04 -0000 --_002_D180B0BB2FF13rmohanrciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-ID: <660DB38D08C47840BE5A366FC8A302B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Not sure why the email I received got truncated. Attached for reference the original email I received. Please see below for responses to your other comments: -----Original Message----- From: Meral Shirazipour Date: Monday, 18 May 2015 11:31 pm To: Cisco Employee Cc: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "gen-art@ietf.org" , "rtcweb@ietf.org" Subject: RE: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 >Hi Ram, > Thank you for the response. Please see in line. Also, I did not see >response to the rest of the comments, not sure if it was cut from the >email (please see below-I copy pasted the original email). > >Best regards, >Meral > >-----Original Message----- >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >Sent: Monday, May 18, 2015 10:04 AM >To: Meral Shirazipour; >draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; >gen-art@ietf.org; rtcweb@ietf.org >Subject: Re: Gen-ART Last Call review of >draft-ietf-rtcweb-stun-consent-freshness-13 > >Hi Meral, > >Thanks for your feedback. See inline > >-----Original Message----- >From: Meral Shirazipour >Date: Saturday, 16 May 2015 1:47 am >To: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" >, >"gen-art@ietf.org" >Subject: Gen-ART Last Call review of >draft-ietf-rtcweb-stun-consent-freshness-13 >Resent-From: >Resent-To: >Resent-Date: Saturday, 16 May 2015 1:48 am > >>I am the assigned Gen-ART reviewer for this draft. For background on >>Gen-ART, please see the FAQ at >>http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. >> >>Please resolve these comments along with any other Last Call comments >>you may receive. >> >>Document: draft-ietf-rtcweb-stun-consent-freshness-13 >>Reviewer: Meral Shirazipour >>Review Date: 2015-05-15 >>IETF LC End Date: 2015-05-15 >>IESG Telechat date: NA >> >> >>Summary: >>This draft is ready to be published as Standards Track RFC but I have >>some comments . >> >> >> >>Major issues: >> >>Minor issues: >> >>Nits/editorial comments: >> >>-The abstract lacks context, please consider adding some more text. A >>suggestion: repeat the first sentence from the intro in the abstract: >>"To prevent attacks on peers, endpoints have to ensure the remote peer >>is willing to receive traffic." > >Sure we will add this text > >[Msh] thank you > >> >>-[Page 2] Intro: It was not clear if this document is specific to >>webRTC implementations. Is there any limitation to only use for webRTC? >>Maybe a sentence in the intro could clarify if there is or there is not >>such Limitation > >This document does not restrict itself to webRTC implementations alone >which is the reason we have not specified any where that Consent >freshness is for only webRTC clients. Any full ICE implementations can >use Consent freshness. We have this text at the end of introduction in >the current draft > >"This document defines what it takes to obtain, maintain, and lose > consent to send. Consent to send applies to a single 5-tuple. How > applications react to changes in consent is not described in this > document. > Consent is obtained only by full ICE implementations. An ICE-lite > implementation will not generate consent checks, but will just > respond to consent checks it receives." > >Is this not sufficient ? > >[Msh] Somehow I had to read twice to deduce that. If you think that is >sufficient and there is no need to specifically state not limited to >webRTC the I am ok with it too. We are planning to add a new section =B3Applicability=B2 that would cover s= ome more details on this right after the introduction section. Here is the tentative proposed text. After discussing in WG I will refine this and add to document This document defines what it takes to obtain, maintain, and lose consent to send using ICE.Verification of peer consent before sending traffic is necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks.Section 4.4 and section 5.3 of [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs consent. Other Applications that have similar security requirement where it is required to verify=20 peer's consent before sending non-ICE packets can use the consent mechanism described in this draft. > > > >Regards, >Ram > > >From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Meral >Shirazipour >Sent: Friday, May 15, 2015 1:18 PM >To: draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; >gen-art@ietf.org >Subject: [Gen-art] Gen-ART Last Call review of >draft-ietf-rtcweb-stun-consent-freshness-13 > >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at >http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > >Please resolve these comments along with any other Last Call comments you >may receive. > >Document: draft-ietf-rtcweb-stun-consent-freshness-13 >Reviewer: Meral Shirazipour >Review Date: 2015-05-15 >IETF LC End Date: 2015-05-15 >IESG Telechat date: NA > > >Summary: >This draft is ready to be published as Standards Track RFC but I have >some comments . > > > >Major issues: > >Minor issues: > >Nits/editorial comments: > >-The abstract lacks context, please consider adding some more text. A >suggestion: repeat the first sentence from the intro in the abstract: >"To prevent attacks on peers, endpoints have to ensure the remote peer is >willing to receive traffic." Sure. As mentioned above, we will add this text in abstract > >-[Page 2] Intro: It was not clear if this document is specific to webRTC >implementations. Is there any limitation to only use for webRTC? Maybe a >sentence in the intro could clarify if there is or there is not such >limitation. > >-[Page 2] Intro, it would be good if the intro section could give a good >example (use case, application) of when a receiving end would revoke the >consent during the session.(why closing the session is not enough) Section 4.2 has some details on when Consent is revoked. one use-case is mentioned in 4.2 is immediate revocation when we receive a TLS Alert. >=20 > >-[Page 3], Section2, "Transport Address" definition. It would be good to >clarify this wrt 5-tuple. The two terms are used interchangeably, yet >Transport address carries only destination IP protocol port, not the >sender's (as carried in 5-tuple). >e.g. [Page 4]:"....the remote peer's transport address, the endpoint MUST >cease transmission on that 5-tuple." Terminology section defines Transport address. >-[Page 4] "Initial consent to send traffic is obtained using ICE. >Consent expires after 30 seconds." >Is this value specified by [RFC6062] or this document? not clear. 30 second timeout period was selected so that consent checks could be sent between 7 to 5 times (to handle packet loss) . This was discussed a lot in WG and it was agreed to make 30 seconds as consent expiry. > >-[Page 4-5]Section 4.1 addresses security issues. Section 8 adds >additional content on security. It would be best to consolidate or at >least have Section 8 point back to 4.1. Sure we will add some back reference from security considerations to 4.1 > > > >nits: > >-[Page 5], "can not cause"--->"cannot cause" >-[Page 6], "each others keys"--->"each other's keys" >-[Page 7], typo "through review"--->"thorough review" >-SRTCP,DTLs, etc. please spell out acronyms at first use. Thanks. Will take care of these nits. Regards, Ram > >Best Regards, >Meral >--- >Meral Shirazipour >Ericsson >Research >www.ericsson.com > > --_002_D180B0BB2FF13rmohanrciscocom_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 19 May 2015 14:49:30 GMT"; modification-date="Tue, 19 May 2015 14:49:30 GMT" Content-ID: <70C30BC025439D42A55210E688EEA74F@emea.cisco.com> Received: from alln-iport-4.cisco.com (173.37.142.91) by mail.cisco.com (173.36.12.78) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 15 May 2015 15:18:59 -0500 Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP; 15 May 2015 20:18:59 +0000 Received: from alln-inbound-d.cisco.com (alln-inbound-d.cisco.com [173.37.147.234]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4FKIqpv028334; Fri, 15 May 2015 20:18:58 GMT Authentication-Results: alln-inbound-d.cisco.com; dkim=neutral (message not signed) header.i=none Received-SPF: SoftFail (alln-inbound-d.cisco.com: domain of meral.shirazipour@ericsson.com is inclined to not designate 2001:1900:3001:11::2c as permitted sender) identity=mailfrom; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-d.cisco.com; envelope-from="meral.shirazipour@ericsson.com"; x-sender="meral.shirazipour@ericsson.com"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-d.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-d.cisco.com; envelope-from="meral.shirazipour@ericsson.com"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only X-from-outside-Cisco: 2001:1900:3001:11::2c X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A8GKAQA4VFZVlwAZASCDgISAEQAsXIJmfl4GxF8JgVmFdgKBNTgUAQEBAQEBAQMOAQEBAQEIFgdPglE7CAQdAg1gAgMDfAwBHA4kLAYmAQQBFwOIJAECCtdQAQEIAQEBAQEBHJAOIIMvgRYFlwqHcT6DJ5FxAoEEgxdwgUSBAQEBAQ X-IPAS-Result: A8GKAQA4VFZVlwAZASCDgISAEQAsXIJmfl4GxF8JgVmFdgKBNTgUAQEBAQEBAQMOAQEBAQEIFgdPglE7CAQdAg1gAgMDfAwBHA4kLAYmAQQBFwOIJAECCtdQAQEIAQEBAQEBHJAOIIMvgRYFlwqHcT6DJ5FxAoEEgxdwgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,436,1427760000"; d="scan'208";a="69191432" X-Amp-Result: Clean X-Amp-File-Uploaded: False X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c]) by alln-inbound-d.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 May 2015 20:18:58 +0000 Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9082A1A1BB8; Fri, 15 May 2015 13:18:57 -0700 (PDT) X-Original-To: xfilter-draft-ietf-rtcweb-stun-consent-freshness.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-rtcweb-stun-consent-freshness.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740D81A1B92 for ; Fri, 15 May 2015 13:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DebRd6_9TeqS for ; Fri, 15 May 2015 13:18:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (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 8D3001A1B7B for ; Fri, 15 May 2015 13:18:54 -0700 (PDT) Received: from usevmg21.ericsson.net ([198.24.6.65]:60195) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YtM3J-0001Pe-Ii for draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; Fri, 15 May 2015 13:17:51 -0700 X-AuditID: c6180641-f79086d000001909-4c-5555efd18424 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4E.E1.06409.1DFE5555; Fri, 15 May 2015 15:08:33 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Fri, 15 May 2015 16:17:39 -0400 From: Meral Shirazipour To: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCPTCeBLwIOGK4OTCGKJsw8iNXzOw== Date: Fri, 15 May 2015 20:17:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] boundary="_000_ABCAA4EF18F17B4FB619EA93DEF7939A33239E08eusaamb107erics_" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPlO7F96GhBi0bTSxmX13IaHH11WcW ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugSuj5eYWxoJ7bhX/v+xia2Dcb9vFyMEhIWAi 8fKyXBcjJ5ApJnHh3nq2LkYuDiGBo4wSd2ctZQJJCAksZ5R4e48PxGYTsJDY/vs5K0iRiMAq RokLqw6wgySEBYIkuqbPYwaxRQTCJa5Ob2SHsPUkXq78xgJiswioSvzvfQRm8wr4Suw/28EI YjMCbf5+ag3YMmYBcYlbT+YzQVwkILFkz3lmCFtU4uXjf6wQtpLEnNfXmCHq8yUm9kDU8AoI Spyc+YRlAqPQLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i5CgtTi3L TTcy3MQIjIZjEmyOOxgXfLI8xCjAwajEw7vgUUioEGtiWXFl7iFGaQ4WJXHei6pAIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYxFT5R2ePVPfbfKQOr38yfbGW5oHXjf7rTEPmFfSfW1/OLc v7ybP7R+Wv4ztn5Dd7D/mrfT+PJu7soSihOS3/44bVabd/KTKQ/ub17GkfWkdWGgzvOItR8K GM1fnrm99VNZ3u6etVvdskyDuSYV6/47vZ5t3QzVeY2tjKlx1tOi6oTjVXaqLP+ixFKckWio xVxUnAgA5RkJz2cCAAA= X-SA-Exim-Connect-IP: 198.24.6.65 X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org X-SA-Exim-Mail-From: meral.shirazipour@ericsson.com Subject: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: List-ID: Resent-Message-ID: <20150515201854.8D3001A1B7B@ietfa.amsl.com> Resent-Date: Fri, 15 May 2015 13:18:54 -0700 Resent-From: Archived-At: Return-Path: meral.shirazipour@ericsson.com X-MS-Exchange-Organization-AuthSource: xhc-aln-x04.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-rtcweb-stun-consent-freshness-13 Reviewer: Meral Shirazipour Review Date: 2015-05-15 IETF LC End Date: 2015-05-15 IESG Telechat date: NA Summary: This draft is ready to be published as Standards Track RFC but I have some comments . Major issues: Minor issues: Nits/editorial comments: -The abstract lacks context, please consider adding some more text. A suggestion: repeat the first sentence from the intro in the abstract: "To prevent attacks on peers, endpoints have to ensure the remote peer is willing to receive traffic." -[Page 2] Intro: It was not clear if this document is specific to webRTC implementations. Is there any limitation to only use for webRTC? Maybe a sentence in the intro could clarify if there is or there is not such limitation --_002_D180B0BB2FF13rmohanrciscocom_-- From nobody Tue May 19 08:28: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 823711A8AAC; Tue, 19 May 2015 08:28:08 -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 q9nZj2t3AMMr; Tue, 19 May 2015 08:28:05 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F88F1A8BB0; Tue, 19 May 2015 08:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10414; q=dns/txt; s=iport; t=1432049285; x=1433258885; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3GT3vSpTWj0gQefdDJECRzsi4v4sMfB3okS6B4QVLj4=; b=lYzTzoRfmOzoS753IjD9xLnWUrrAi6Wy2cdsyw01OpIklIzhUStTn5nd QUtR43U2FAoSeszTSwaVkp0pAp9j1ubUygJlXpJM9yBUl9fwci7wPHt/+ Xt7q/PSKmYYTdJ5qtQvs3SuLO6S9SIdpcwZSsFZYoOb5Aji4WAqmv3xEs Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYBAC9VVtV/51dJa1ZA4MQgTIGxQcJh1ACgT04FAEBAQEBAQGBCoQiAQEBBIEFBAIBCBEDAQIBLiERHQgCBAESiBcDEs1zDYR6AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6gk2BYA07FwYLhBwFhmWEZiuGdokpgVWBJ4NpgiOIBluGfCNhgxdvgQMBHwIhgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,458,1427760000"; d="scan'208";a="151378652" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 19 May 2015 15:28:04 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t4JFS469020803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 May 2015 15:28:04 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.60]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 19 May 2015 10:28:04 -0500 From: "Ram Mohan R (rmohanr)" To: joel jaeggli , "Black, David" , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "Tirumaleswar Reddy (tireddy)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQkkhlFSffw99jN0Sa47pQKspsMw== Date: Tue, 19 May 2015 15:28:03 +0000 Message-ID: References: <55552FC0.8080103@bogus.com> In-Reply-To: <55552FC0.8080103@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.65.39.182] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8C6BF0460146C444B29652925B5807B5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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, 19 May 2015 15:28:08 -0000 Hi David/Joel, Please see inline for my responses. -----Original Message----- From: joel jaeggli Date: Friday, 15 May 2015 4:59 am To: "Black, David" , "muthu.arul@gmail.com" , "dwing@cisco.com" , Cisco Employee , "tireddy@cisco.com" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" Cc: "rtcweb@ietf.org" , "ietf@ietf.org" Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 >Thanks David, > >I'll be looking with interest for the addressing of items 1/2. > >joel > >On 5/14/15 4:21 PM, Black, David wrote: >> 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 >>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. This document defines what it takes to obtain, maintain, and lose consent to send using ICE. This draft does not restrict on what applications should use Consent. Currently on webRTC applications use Consent, however any other application that has Similar security requirements can use this mechanism. We will add a new section =B3Applicability=B2 after the introduction section. 2. Applicability This document defines what it takes to obtain, maintain, and lose consent to send using ICE.Verification of peer consent before sending traffic is necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks.Section 4.4 and section 5.3 of [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs consent. Other Applications that have similar security requirement where it is required to verify peer's consent before sending non-ICE packets can use the consent mechanism described in this draft. Also we will modify para 3 of Intro to make it clearer. OLD: This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. NEW: This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. The consent mechanism does not update the ICE procedures defined in [RFC 5245]. >>=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). Cryptographically strong STUN transaction IDs are required so that off-path attacker does not replay old consent responses. >>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. We will add the following line to Security Considerations section. NEW: Consent requires 96 bits transaction ID to be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically strong. This is good enough security against an off-path attacker replaying old STUN consent responses. >>=20 >> -- Minor Issues -- >>=20 >> [3] In Section 1, please explain what ICE-lite is. A suitable reference >> should suffice. Yes we will add reference to RFC5245 that describes ICE-lite >>=20 >> [4] In Section 4.1, please explain or provide a reference for what >>"paced" >> means in "paced STUN connectivity checks or responses." Pacing is explained in the same section below. Let us know if this is not sufficient/not clear. 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. >>=20 >> -- Nits/Editorial Comments -- >>=20 >> 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. Okay, will move this paragraph to 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 >>discussion of >> applicability (major issue [1], above). This reference is not needed. Once we add applicability section we will reference rtcweb-security-arch draft. >>=20 >> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >>=20 >> 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. We will add a new applicability section proposed above and also modified para 3 of Intro to make it clearer that this draft does not change ICE procedures. Please let us know if this solves the comment above. >> [A.1.1 - deployment] >>=20 >> 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. 30 second timeout period was selected so that consent checks could be sent between 7 to 5 times (to handle packet loss). >> [A.1.5 - network impact] >>=20 >> 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. We specifically discussed in WG about how applications should handle changes in Consent and it was decided to keep it outside the scope of this draft. Para 3 of introduction already has a text that says the same. There can be many possibilities if consent is lost or failed depending on what the application wants. >> [A.1.8 - fault and threshold conditions] >>=20 >> 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)] >>=20 >> 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]. This again seems some thing outside the scope of this draft as it is trying to specify application behavior. Is there some thing that you want us to add in the draft for this? Regards, Ram >>=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 >>protocol >> should not have significant impacts. The writeup indicates that >>implementers >> 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 01748 >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >> david.black@emc.com Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- >>=20 >>=20 >>=20 > > From nobody Tue May 19 09:33:21 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 DE6841A90D2; Tue, 19 May 2015 07:54:05 -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 qMxGe_73ku8G; Tue, 19 May 2015 07:54:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56ABB1A90D4; Tue, 19 May 2015 07:53:18 -0700 (PDT) X-AuditID: c618062d-f79a96d000007fb1-52-555af5c0103f Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4C.41.32689.0C5FA555; Tue, 19 May 2015 10:35:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Tue, 19 May 2015 10:53:16 -0400 From: Meral Shirazipour To: "Ram Mohan R (rmohanr)" Thread-Topic: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCPTCeBLwIOGK4OTCGKJsw8iNXzOwC908gg Date: Tue, 19 May 2015 14:53:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPiO6Br1GhBj0b5CxmX13IaHH11WcW i+VdOxgt1v5rZ3dg8ZjyeyOrx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CV8eFVO3PBKueK 7rZelgbGS+ZdjBwcEgImEr0vxLoYOYFMMYkL99azdTFycQgJHGWUuHJ4OTuEs5xR4tXyI8wg VWwCFhLbfz9nBbFFBPQl3mxYBtbBLHCeUWJe1x4mkISwQJjE3pYORoiicImr0xvZIWwjic5d 08AGsQioSnTe3QRm8wr4Siw9dIMFxBYSuM0ocfm/PojNCbTgT9N0sJmMQOd9P7UGzGYWEJe4 9WQ+E8TZAhJL9pxnhrBFJV4+/scKYStK7Oufzg5RrydxY+oUNghbW2LZwtdQewUlTs58wjKB UWwWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnpRgabGIFRdEyCTXcH456XlocYBTgYlXh4HyRE hQqxJpYVV+YeYpTmYFES5/1mGBIqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXH6qcj/R3wy v57+16EunSN+o/MJ360zDov2XNVYLZ/qt94901Tk6z+G/rhYcfHYxSzd3aa6vyKfusz8q1EW NMlxyzTbOB+vy26JRueWSf81e2BWtOfGO2b7j4Jmm23vrrvnLTT725+W04feVuRL/Xlu3L4m RkCgu2N/8fvIfUJvvhxL+Ve/v16JpTgj0VCLuag4EQDpI2R/gwIAAA== Archived-At: X-Mailman-Approved-At: Tue, 19 May 2015 09:33:20 -0700 Cc: "gen-art@ietf.org" , "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] Gen-ART Last Call 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, 19 May 2015 14:54:06 -0000 Hi, Thank you for the replies.=20 Best Regards, Meral -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: Tuesday, May 19, 2015 7:50 AM To: Meral Shirazipour Cc: draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; gen-art@ie= tf.org; rtcweb@ietf.org Subject: Re: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-fre= shness-13 Not sure why the email I received got truncated. Attached for reference the= original email I received. Please see below for responses to your other comments: -----Original Message----- From: Meral Shirazipour Date: Monday, 18 May 2015 11:31 pm To: Cisco Employee Cc: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" , "gen-art@ietf.org" , "rtcweb@ietf.org" Subject: RE: Gen-ART Last Call review of draft-ietf-rtcweb-stun-consent-freshness-13 >Hi Ram, > Thank you for the response. Please see in line. Also, I did not see=20 >response to the rest of the comments, not sure if it was cut from the=20 >email (please see below-I copy pasted the original email). > >Best regards, >Meral > >-----Original Message----- >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >Sent: Monday, May 18, 2015 10:04 AM >To: Meral Shirazipour; >draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; >gen-art@ietf.org; rtcweb@ietf.org >Subject: Re: Gen-ART Last Call review of >draft-ietf-rtcweb-stun-consent-freshness-13 > >Hi Meral, > >Thanks for your feedback. See inline > >-----Original Message----- >From: Meral Shirazipour >Date: Saturday, 16 May 2015 1:47 am >To: "draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org" >, >"gen-art@ietf.org" >Subject: Gen-ART Last Call review of >draft-ietf-rtcweb-stun-consent-freshness-13 >Resent-From: >Resent-To: >Resent-Date: Saturday, 16 May 2015 1:48 am > >>I am the assigned Gen-ART reviewer for this draft. For background on=20 >>Gen-ART, please see the FAQ at=20 >>http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. >> >>Please resolve these comments along with any other Last Call comments=20 >>you may receive. >> >>Document: draft-ietf-rtcweb-stun-consent-freshness-13 >>Reviewer: Meral Shirazipour >>Review Date: 2015-05-15 >>IETF LC End Date: 2015-05-15 >>IESG Telechat date: NA >> >> >>Summary: >>This draft is ready to be published as Standards Track RFC but I have=20 >>some comments . >> >> >> >>Major issues: >> >>Minor issues: >> >>Nits/editorial comments: >> >>-The abstract lacks context, please consider adding some more text. A >>suggestion: repeat the first sentence from the intro in the abstract: >>"To prevent attacks on peers, endpoints have to ensure the remote peer=20 >>is willing to receive traffic." > >Sure we will add this text > >[Msh] thank you > >> >>-[Page 2] Intro: It was not clear if this document is specific to=20 >>webRTC implementations. Is there any limitation to only use for webRTC? >>Maybe a sentence in the intro could clarify if there is or there is=20 >>not such Limitation > >This document does not restrict itself to webRTC implementations alone=20 >which is the reason we have not specified any where that Consent=20 >freshness is for only webRTC clients. Any full ICE implementations can=20 >use Consent freshness. We have this text at the end of introduction in=20 >the current draft > >"This document defines what it takes to obtain, maintain, and lose > consent to send. Consent to send applies to a single 5-tuple. How > applications react to changes in consent is not described in this > document. > Consent is obtained only by full ICE implementations. An ICE-lite > implementation will not generate consent checks, but will just > respond to consent checks it receives." > >Is this not sufficient ? > >[Msh] Somehow I had to read twice to deduce that. If you think that is=20 >sufficient and there is no need to specifically state not limited to=20 >webRTC the I am ok with it too. We are planning to add a new section =B3Applicability=B2 that would cover s= ome more details on this right after the introduction section. Here is the= tentative proposed text. After discussing in WG I will refine this and add= to document This document defines what it takes to obtain, maintain, and lose consent t= o send using ICE.Verification of peer consent before sending traffic is nec= essary in deployments like WebRTC to ensure that a malicious JavaScript can= not use the browser as a platform for launching attacks.Section 4.4 and sec= tion 5.3 of [I-D.ietf-rtcweb-security-arch] explains why webRTC application= needs consent. Other Applications that have similar security requirement where it is requi= red to verify peer's consent before sending non-ICE packets can use the con= sent mechanism described in this draft. > > > >Regards, >Ram > > >From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Meral >Shirazipour >Sent: Friday, May 15, 2015 1:18 PM >To: draft-ietf-rtcweb-stun-consent-freshness.all@tools.ietf.org; >gen-art@ietf.org >Subject: [Gen-art] Gen-ART Last Call review of >draft-ietf-rtcweb-stun-consent-freshness-13 > >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please see the FAQ at >http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. > >Please resolve these comments along with any other Last Call comments you >may receive. > >Document: draft-ietf-rtcweb-stun-consent-freshness-13 >Reviewer: Meral Shirazipour >Review Date: 2015-05-15 >IETF LC End Date: 2015-05-15 >IESG Telechat date: NA > > >Summary: >This draft is ready to be published as Standards Track RFC but I have >some comments . > > > >Major issues: > >Minor issues: > >Nits/editorial comments: > >-The abstract lacks context, please consider adding some more text. A >suggestion: repeat the first sentence from the intro in the abstract: >"To prevent attacks on peers, endpoints have to ensure the remote peer is >willing to receive traffic." Sure. As mentioned above, we will add this text in abstract > >-[Page 2] Intro: It was not clear if this document is specific to webRTC >implementations. Is there any limitation to only use for webRTC? Maybe a >sentence in the intro could clarify if there is or there is not such >limitation. > >-[Page 2] Intro, it would be good if the intro section could give a good >example (use case, application) of when a receiving end would revoke the >consent during the session.(why closing the session is not enough) Section 4.2 has some details on when Consent is revoked. one use-case is mentioned in 4.2 is immediate revocation when we receive a TLS Alert. >=20 > >-[Page 3], Section2, "Transport Address" definition. It would be good to >clarify this wrt 5-tuple. The two terms are used interchangeably, yet >Transport address carries only destination IP protocol port, not the >sender's (as carried in 5-tuple). >e.g. [Page 4]:"....the remote peer's transport address, the endpoint MUST >cease transmission on that 5-tuple." Terminology section defines Transport address. >-[Page 4] "Initial consent to send traffic is obtained using ICE. >Consent expires after 30 seconds." >Is this value specified by [RFC6062] or this document? not clear. 30 second timeout period was selected so that consent checks could be sent between 7 to 5 times (to handle packet loss) . This was discussed a lot in WG and it was agreed to make 30 seconds as consent expiry. > >-[Page 4-5]Section 4.1 addresses security issues. Section 8 adds >additional content on security. It would be best to consolidate or at >least have Section 8 point back to 4.1. Sure we will add some back reference from security considerations to 4.1 > > > >nits: > >-[Page 5], "can not cause"--->"cannot cause" >-[Page 6], "each others keys"--->"each other's keys" >-[Page 7], typo "through review"--->"thorough review" >-SRTCP,DTLs, etc. please spell out acronyms at first use. Thanks. Will take care of these nits. Regards, Ram > >Best Regards, >Meral >--- >Meral Shirazipour >Ericsson >Research >www.ericsson.com > > From nobody Wed May 20 05:56: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 C92C11A020B for ; Wed, 20 May 2015 05:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.673 X-Spam-Level: * X-Spam-Status: No, score=1.673 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FSL_HELO_BARE_IP_2=1.675, 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 NUaQAG9hsndY for ; Wed, 20 May 2015 05:56:29 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.54.2]) (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 4B0C41A0242 for ; Wed, 20 May 2015 05:56:28 -0700 (PDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 9807285A6F12 for ; Wed, 20 May 2015 07:56:27 -0500 (CDT) Received: from [173.73.121.66] (port=62018 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yv3Xu-0005eL-PC; Wed, 20 May 2015 07:56:26 -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: Date: Wed, 20 May 2015 08:56:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0FEF3981-063C-450C-9E6A-685696B4F5E0@ieca.com> References: <5549E480.4030806@alvestrand.no> To: Martin Thomson 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: 173.73.121.66 X-Exim-ID: 1Yv3Xu-0005eL-PC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [173.73.121.66]:62018 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 12:56:30 -0000 On May 07, 2015, at 09:46, Martin Thomson = wrote: > On 7 May 2015 at 02:38, Ted Hardie wrote: >> I am not chair with the particularly good position to collect = feedback, but >> I happen to know he's flying today. My understanding of the current = theory >> is that we ask TLS what cipher suites and version numbers to mandate; = if we >> had a strong reason to disagree, we would need to document why we = went with >> something other than what they suggested. >>=20 >> He-who-is-in-the-air may tell me I've got it wrong, of course. >=20 > Sounds good, perhaps we should ask he-who-will-eventually-land to pass > on the question, unless we both are wrong. On it - albeit a little late. It=92s worth noting that the UTA BCP195 = (RFC 7525) (Recommendations for Secure Use of Transport Layer Security = (TLS) and Datagram Transport Layer Security (DTLS)) was recently = published and recommends this set of algorithms: o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 I also admit that I prefer ECDSA, primarily for smaller certs for = comparable security, but acknowledge Martin=92s point about the cert = management APIs. spt= From nobody Wed May 20 06:17: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 421AE1A1A82; Wed, 20 May 2015 06:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OGuMy4ahWF27; Wed, 20 May 2015 06:17:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD61A1A24; Wed, 20 May 2015 06:17:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150520131732.5519.10061.idtracker@ietfa.amsl.com> Date: Wed, 20 May 2015 06:17:32 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Revised Last Call: (WebRTC Video Processing and Codec Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 13:17:33 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Video Processing and Codec Requirements' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-06-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This document contains a normative reference to an informational RFC: RFC 6386 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed May 20 10:32: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 63E651A89BB for ; Wed, 20 May 2015 10:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Ymnt7-8hRv6U for ; Wed, 20 May 2015 10:32:20 -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 C42371A89B8 for ; Wed, 20 May 2015 10:32:19 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-65-555cc521e05f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D0.14.28096.125CC555; Wed, 20 May 2015 19:32:17 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Wed, 20 May 2015 19:32:17 +0200 Message-ID: <555CC520.7010800@ericsson.com> Date: Wed, 20 May 2015 19:32:16 +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: Colin Perkins , Alissa Cooper References: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in> <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org> In-Reply-To: <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvra7i0ZhQg3fTtSymn/nLaLH85QlG i7X/2tkdmD2+PHnJ5DHt/n02jyVLfjIFMEdx2aSk5mSWpRbp2yVwZXx78oel4JpeRe++T4wN jBtVuxg5OSQETCR+PF3PDGGLSVy4t56ti5GLQ0jgKKPEhD1fmCCc5YwSNx6/YQSp4hXQlvj5 o5kVxGYRUJWYP+UjC4jNJmAhcfNHIxuILSoQJTH18ToWiHpBiZMzn4DZIgIeEhsebASzmQXU Je4sPscOYgsLOEv07HwNNlNIoEji0M52sBpOAUeJ27tfs0PUW0jMnH+eEcKWl2jeOpsZol5b oqGpg3UCo+AsJOtmIWmZhaRlASPzKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAID645bfV DsaDzx0PMQpwMCrx8C54FR0qxJpYVlyZe4hRmoNFSZzXsyskVEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAOjnX3JE3Pe7Sn/Hl+VV5Z6JHhRbtnVtrsWL3qn/q9mXPd4Usfzxe+5eIwWGsSY nzgYcGNqtfaE5zPbH6T7aJpKb9WyWRh2Y4LAQd6sl7kzXkzdIBXuJ+Sqd5pBJuW4wNoLW24t efPC7lO1+vZV8u5mX7ZN1JusricmmTXprL7olpB2Fsmvi5cFKrEUZyQaajEXFScCAJJh1sdD AgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: 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, 20 May 2015 17:32:24 -0000 Hi, Some additional comments on this. I have removed the parts where there appear to be agreement and no open issues. Colin Perkins skrev den 2015-05-17 14:00: >> On 14 May 2015, at 00:58, Alissa Cooper wrote: > >> == Section 11: >> >> "Note: this doesn't result in a tracking issue, since the creation >> of matching CNAMEs depends on existing tracking." >> >> I don't quite get this note. Is this trying to say that using the >> same CNAME in this case does not facilitate cross-service tracking >> because the CNAME re-use only occurs within a single origin? > > That's part of it. Also, that using the same CNAME for several > streams that are part of a single call is okay, and indeed needed for > lip-sync, since there are other ways of telling that these streams > are part of the same call. Yes, it really is a matter that this stays within an origin and the binding if needed would be exposed anyway. I think the text will be a bit clearer with the minor tweak at the end to clarify that is really is within one origin. "Note: this doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking within a single origin." > >> == Section 12.1.3: >> >> "When flow- based differentiation is available, the WebRTC Endpoint >> needs to know about it so that it can provide the separation of the >> RTP packet streams onto different UDP flows to enable a more >> granular usage of flow based differentiation." >> >> I feel like this needs a bit more explanation since I assume it's >> not terribly commonplace for an endpoint to be able to find out >> that flow-based differentiation is taking place. Is there some >> mechanism you can point to that provides this information in some >> cases, or is this basically saying "wouldn't it be nice if >> endpoints could find this out somehow"? > > We could say "The use of flow-based differentiation needs to be > signalled to the WebRTC Endpoint, so it knows to provide the > separation..."? The point is that the endpoint can't enable this > without being told that it' so be used, and what parameters are to be > used. Yes, this is better formulation. My understanding is that so far, there need to be some out-of-band coordination between the network provider and the WebRTC based service that uses the network prioritization. > >> = >> >> I note that there is discussion of how DiffServ and flow-based >> classification might work for RTP traffic in the WebRTC context, >> but not DPI. Is there anything to be said, in particular given the >> SRTP requirement? Actually, I think you are at least partly wrong. A DPI can despite SRTP with encryption actually do quite significant classification due to the information exposed. First of all SRTP exposes the first 12 bytes of the RTP packet. Thus the SSRC is available, enabling RTP stream level tracking. This can then be used with RTP packet frequency and size analysis to determine which RTP streams are audio and which are video for example. Thus enabling such prioritization. The API level priorities are not exposed, so it can't take that into account unless they are exposed in the DSCP field. > > I'm happy to add some text, if you have any suggestions. Yes, I would like to have some indication from people who don't know this in and out to what appears necessary here. > >> == Section 13: >> >> "The use of the encryption of the header extensions are >> RECOMMENDED, unless there are known reasons, like RTP middleboxes >> or third party monitoring that will greatly benefit from the >> information, and this has been expressed using API or signalling. >> If further evidence are produced to show that information leakage >> is significant from audio level indications, then use of >> encryption needs to be mandated at that time." >> >> I'm not sure that "known reasons" are quite enough to justify the >> SHOULD-level requirement here. It would help if you could elaborate >> specific legitimate use cases where a middlebox or a specific kind >> of third party makes use of the audio level information and how >> that information provides a great benefit. > > The issue is that middle boxes use the audio level information in the > header extensions to perform voice activity-based source switching. > Sending audio level information in the header extension is preferable > to trusting the middle box with access to the media. We can add some > words to explain this further, and perhaps a pointer to the PERC > working group, if chartered? I suggest that we make the RTP middlebox usage clearer: The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP middleboxes performing voice activity based source selection or third party monitoring that will greatly benefit from the information, and this has been expressed using API or signalling. > >> == Section 16: draft-ietf-mmusic-sdp-bundle-negotiation should not >> be listed as an informative reference. > > Why not? Because we actually have normative inclusion of its header extension in Section 4.1: Such endpoints MUST implement the RTCP SDES MID item described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. We actually had it listed as both a normative and informative reference. I will remove the informative listing. 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 May 20 16:49: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 06FD21ACCF3; Wed, 20 May 2015 16:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 W2SzTX8k85SK; Wed, 20 May 2015 16:48:56 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::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 A2F571ACCF2; Wed, 20 May 2015 16:48:55 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so171826594wic.0; Wed, 20 May 2015 16:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=4DF9tNdhfSl9UzQPWNg8rbnQxHZlo/+LltDTSBBOib4=; b=nPY98dttXluAaKt5JNq80CbqnMaPg9gyp1tkR2rGD0Pezr5Jz4KBuy45/vGEE9hGQG QO6tbdSnrxD0IPC5G8PutZwPQMTiJgNfD+u3lXwPnYSD23llHsnLU97dG4+cW1a4lx1Q VFE4KJpa6FEoZi2WSlS0MpAFYjWqsUZ/ubrQq1ElG9Ur/LlBxkMc+xZOig4C10NFdYck DaEkNefOsBX+s0dmKQGvlih6XKWQb57EuPTC8KAcIfFKx48yiy/vzlRS5BjgODWufx3d hCZJU2dxtKfSgHhj/4Aagh59rk3iNdHe0/U348sgq8omP/6QdKVa2twOUaMM6JteIQoB cW2w== X-Received: by 10.180.96.196 with SMTP id du4mr8087768wib.77.1432165734417; Wed, 20 May 2015 16:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Wed, 20 May 2015 16:48:34 -0700 (PDT) From: Bernard Aboba Date: Wed, 20 May 2015 16:48:34 -0700 Message-ID: To: "rtcweb@ietf.org" , The IESG Content-Type: multipart/alternative; boundary=f46d043bdabcdc0b2605168c116b Archived-At: Subject: [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: Wed, 20 May 2015 23:49:00 -0000 --f46d043bdabcdc0b2605168c116b Content-Type: text/plain; charset=UTF-8 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? --f46d043bdabcdc0b2605168c116b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a review of draft-ietf-rtcweb-stun-consent-fr= eshness. =C2=A0

Overall, I believe that this docum= ent is not yet ready for publication as a proposed standard,=C2=A0
due to transport-related issues.=C2=A0 Rather than building upon the RFC = 5389 transport model
(including the transaction structure and RTT= /RTO estimator), the specification proposes a
new (and poorly spe= cified) transport model that does not adapt properly=C2=A0
to net= works with differing transport characteristics.=C2=A0

<= div>RFC 5389 Section 7.2.1 describes how stun handles retransmissions and R= TT/RTO computation:=C2=A0

=C2=A0 =C2=A0The RTO is = an estimate of the round-trip time (RTT),
=C2=A0 =C2=A0and is com= puted as described in RFC 2988 [RFC2988], with two
=C2=A0 =C2=A0e= xceptions.=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 SHOU= LD be greater
=C2=A0 =C2=A0than 500 ms.=C2=A0 The exception cases= for this "SHOULD" are when other
=C2=A0 =C2=A0mechanis= ms are used to derive congestion thresholds (such as the ones
=C2= =A0 =C2=A0defined in ICE for fixed rate streams), or when STUN is used in n= on-
=C2=A0 =C2=A0Internet environments with known network capacit= ies.=C2=A0 In fixed-line
=C2=A0 =C2=A0access links, a value of 50= 0 ms is RECOMMENDED.=C2=A0 Second, the value of
=C2=A0 =C2=A0RTO = SHOULD NOT be rounded up to the nearest second.=C2=A0 Rather, a 1 ms
<= div>=C2=A0 =C2=A0accuracy SHOULD be maintained.=C2=A0 As with TCP, the usag= e of Karn's
=C2=A0 =C2=A0algorithm is RECOMMENDED [KARN87].= =C2=A0 When applied to STUN, it means
=C2=A0 =C2=A0that RTT estim= ates SHOULD NOT be computed from STUN transactions that
=C2=A0 = =C2=A0result in the retransmission of a request.

= =C2=A0 =C2=A0The value for RTO SHOULD be cached by a client after the compl= etion
=C2=A0 =C2=A0of the transaction, and used as the starting v= alue for RTO for the
=C2=A0 =C2=A0next transaction to the same se= rver (based on equality of IP
=C2=A0 =C2=A0address).=C2=A0 The va= lue SHOULD be considered stale and discarded after
=C2=A0 =C2=A01= 0 minutes.

=C2=A0 =C2=A0Retransmissions continue u= ntil a response is received, or until a
=C2=A0 =C2=A0total of Rc = requests have been sent.=C2=A0 Rc SHOULD be configurable and
=C2= =A0 =C2=A0SHOULD have a default of 7.=C2=A0 If, after the last request, a d= uration
=C2=A0 =C2=A0equal to Rm times the RTO has passed without= a response (providing
=C2=A0 =C2=A0ample time to get a response = if only this final request actually
=C2=A0 =C2=A0succeeds), the c= lient SHOULD consider the transaction to have failed.
=C2=A0 =C2= =A0Rm SHOULD be configurable and SHOULD have a default of 16.=C2=A0 A STUN<= /div>
=C2=A0 =C2=A0transaction over UDP is also considered failed if th= ere has been a
=C2=A0 =C2=A0hard ICMP error [RFC1122].=C2=A0 For = example, assuming an RTO of 500 ms,
=C2=A0 =C2=A0requests would b= e sent at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500
=C2=A0 =C2= =A0ms, 15500 ms, and 31500 ms.=C2=A0 If the client has not received a
=
=C2=A0 =C2=A0response after 39500 ms, the client will consider the tra= nsaction to
=C2=A0 =C2=A0have timed out.

The above mechanism addresses a number of issues:=C2=A0

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 tran= sients

Unfortunately, rather than reusing all or p= art of this approach, the consent freshness specification invents an new an= d poorly specified transport scheme in Section 4.1:

=C2=A0 =C2=A0Initial consent to send traffic is obtained using ICE.=C2=A0= Consent
=C2=A0 =C2=A0expires after 30 seconds.=C2=A0 That is, if= a valid STUN binding response
=C2=A0 =C2=A0corresponding to any = STUN request sent in the last 30 seconds has not
=C2=A0 =C2=A0bee= n received from the remote peer's transport address, the endpoint
=
=C2=A0 =C2=A0MUST cease transmission on that 5-tuple.=C2=A0 STUN conse= nt responses
=C2=A0 =C2=A0received after consent expiry do not re= -establish consent, and may be
=C2=A0 =C2=A0discarded or cause an= ICMP error.

=C2=A0 =C2=A0To prevent expiry of con= sent, a STUN binding request can be sent
=C2=A0 =C2=A0periodicall= y.=C2=A0 To prevent synchronization of consent checks, each
=C2= =A0 =C2=A0interval MUST be randomized from between 0.8 and 1.2 times the ba= sic
=C2=A0 =C2=A0period.=C2=A0 Implementations SHOULD set a defau= lt interval of 5 seconds,
=C2=A0 =C2=A0resulting in a period betw= een checks of 4 to 6 seconds.

=C2=A0 =C2=A0Each ST= UN binding request for consent MUST use a new
=C2=A0 =C2=A0crypto= graphically strong [RFC4086] STUN transaction ID.=C2=A0 Each STUN
=C2=A0 =C2=A0binding requests for consent is transmitted once only.=C2=A0 = Hence, the
=C2=A0 =C2=A0sender cannot assume that it will receive= a response for each consent
=C2=A0 =C2=A0request, and a response= might be for a previous request (rather than
=C2=A0 =C2=A0for th= e most recently sent request).=C2=A0 Consent expiration causes
= =C2=A0 =C2=A0immediate termination of all outstanding STUN consent transact= ions.
=C2=A0 =C2=A0Each STUN transaction is maintained until one = of the following
=C2=A0 =C2=A0criteria is fulfilled:
=C2=A0 =C2=A0o =C2=A0A STUN response associated with the trans= action is received; or

=C2=A0 =C2=A0o =C2=A0A STUN= response associated to a newer transaction is received.

The above mechanism has several drawbacks:=C2=A0

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 n= etwork characteristics.=C2=A0

2. Inconsistent numb= er of requests before failure.=C2=A0 Given the randomization, 4 to 6 reques= ts might be sent within the 30 seconds. =C2=A0

3. = Unclear timer behavior.=C2=A0 Does an implementation continue to send reque= sts until 30 seconds has elapsed, or does it stop before then so as to allo= w for a response to the last request to arrive?=C2=A0 One could interpret t= he above to =C2=A0imply that requests continue to be sent for up to 30 seco= nds, but the last request is considered failed as soon as the 30 second tim= er expires.=C2=A0

Detailed comments below.=C2=A0

Abstract

To prevent se= nding excessive traffic to an endpoint, periodic consent needs to be obtain= ed from that remote endpoint.=C2=A0

[BA] This sent= ence is puzzling, since Section 1 does not mention preventing "excessi= ve traffic" as an objective - =C2=A0focusing instead of prevention of = denial of service attacks.

AFAICT, the consent fre= shness mechanism does not actually prevent sending of excessive traffic, no= r is it =C2=A0intended to. That is the role of congestion control mechanism= s such as those under development in RMCAT, or prior to their deployment, t= he objective of the "Circuit Breakers" mechanism.=C2=A0

As an example, =C2=A0the consent mechanism does not restric= t the sending of video on a connection that was only =C2=A0intended for aud= io, although it would be possible for a peer receiving unwanted media to re= voke consent.=C2=A0

My suggested rewording is as f= ollows:

"To prevent browsers supporting WebRT= C from being used to launch denial of service attacks by sending media to u= nsuspecting victims, periodic consent needs to be obtained from remote endp= oints."

Section 4.1

= An endpoint MUST NOT send data other than paced STUN connectivity checks or= responses toward any transport address =C2=A0unless the receiving endpoint= consents to receive data. That is, no application data (e.g., RTP or DTLS)= can be =C2=A0sent until consent is obtained. After a successful ICE connec= tivity 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 b= efore ICE completes, and would therefore interact with the scheduling and p= acing mechanism specified in RFC 5245.=C2=A0 This does make some sense, sin= ce in Trickle ICE, trickling all the candidates might take a while, and med= ia might be sent after a successful response, so that consent would be in o= rder.=C2=A0 However, if that is the intent, then it needs to be explicitly = stated, and this document
needs to contain an Updates: RFC 5245 h= eader. =C2=A0

Each STUN binding request for consen= t MUST use a new cryptographically strong [RFC4086] STUN transaction ID.=C2= =A0

[BA] I think that RFC 5389 Section 6 says what= is in intended here in a more precise way, so it should be referenced inst= ead:

=C2=A0 =C2=A0As such, the transaction ID MUST= be uniformly
=C2=A0 =C2=A0and randomly chosen from the interval = 0 .. 2**96-1, and SHOULD be
=C2=A0 =C2=A0cryptographically random= .=C2=A0

After consent is lost for any reason, the = same ICE credentials MUST NOT be used on the affected 5-tuple again. That m= eans that a new session, or an ICE restart, is needed to obtain consent to = send.

[BA] The second sentence does not follow fro= m the first. RFC 5245 enables sending of media once a successful ICE connec= tivity check has been received.=C2=A0 If multiple successful candidate pair= s 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.=C2=A0 What other reasons are there?
--f46d043bdabcdc0b2605168c116b-- From nobody Thu May 21 08:24: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 937C91A870F for ; Thu, 21 May 2015 08:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 7YLlkL76Kmoq for ; Thu, 21 May 2015 08:23:58 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.106.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805191A7023 for ; Thu, 21 May 2015 08:23:58 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 98B52A2FFD18E; Thu, 21 May 2015 10:23:57 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 87094A2FFD165 for ; Thu, 21 May 2015 10:23:57 -0500 (CDT) Received: from [173.73.121.66] (port=49435 helo=[192.168.1.6]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YvSK7-0006m4-Np; Thu, 21 May 2015 10:23:56 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 21 May 2015 11:23:49 -0400 Message-Id: <07094C12-14AC-4C57-823E-DF9CFEBA0E1A@ieca.com> 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: 173.73.121.66 X-Exim-ID: 1YvSK7-0006m4-Np X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.6]) [173.73.121.66]:49435 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: rai-ads@tools.ietf.org Subject: [rtcweb] June 18th RTCweb WG Virtual Interim Meeting - JSEP-focused X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:23:59 -0000 All, The chairs want to propose a two-hour RTCweb WG Virtual Interim Meeting = on June 18th to progress the JSEP draft; the link for the draft is = http://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/. We=92ve = selected this time based on author availability as well as the IETF = submission deadlines (2015-07-06) to give the authors two-ish weeks to = incorporate any changes resulting from the Virtual Interim Meeting. = Please respond to the forthcoming doodle poll to select a time-slot by = May 26th. Once we=92ve settled on a time, we=92ll get the formal = announcement out through the Secretariat. Cheers, Cullen, Ted, and Sean= From nobody Thu May 21 08:55: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 BB2131B29D9 for ; Thu, 21 May 2015 08:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 BwCq6syBcYaV for ; Thu, 21 May 2015 08:55:13 -0700 (PDT) Received: from worker2.doodle.com (worker2.doodle.com [94.230.219.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046E61A87B3 for ; Thu, 21 May 2015 08:55:12 -0700 (PDT) Received: from worker2.doodle.com (localhost [127.0.0.1]) by worker2.doodle.com (Postfix) with ESMTP id 4423D92858C for ; Thu, 21 May 2015 17:55:11 +0200 (CEST) Date: Thu, 21 May 2015 17:55:11 +0200 (CEST) From: "Sean Turner (via Doodle)" To: rtcweb@ietf.org Message-ID: <39169098.225023.1432223711277.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker2.doodle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_225022_1442134796.1432223711276" Archived-At: Subject: [rtcweb] RTCweb June 18th Virtual Interim Meeting - JSEP-focused X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Sean Turner List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:55:15 -0000 ------=_Part_225022_1442134796.1432223711276 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, Sean Turner (turners@ieca.com) invites you to participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." This doodle poll will help us determine a time for the JSEP-focused RTCweb WG Interim Meeting to be held on June 18th. See the following link for more information: http://www.ietf.org/mail-archive/web/rtcweb/current/msg14632.html. Participate now https://doodle.com/pbckxc56dvr64h8n?tmail=3Dpoll_invitecontact_participant_= invitation_with_message&tlink=3Dpollbtn What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date for meeting with a group of people. Learn more about how Doodle works. (https://doodle.com/main.html?tlink=3DcheckOutLink&tmail=3Dpoll_inviteconta= ct_participant_invitation_with_message) ---------------------------------------------------------------------- You have received this e-mail because "Sean Turner" has invited you to participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." ---- Doodle is also available for iOS and Android. ---- Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich ------=_Part_225022_1442134796.1432223711276 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =
=09
Sean Turner invites you to = participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeti= ng - JSEP-focused."
=09
=09 =09 =09
=09 =09=09 =09=09 =09=09=09=09=09=09=09 =09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09 =09
=20
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09 =09=09=09=09=09=09=09=09 =09=09=09=09=09=09=09=09
=09=09=09=09=09=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
"RTCweb June 18th= Virtual Interim Meeting - JSEP-focused." =09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09
=09=09=09=09=09=09=09This doodle poll will help us determine a time for the= JSEP-focused RTCweb WG Interim Meeting to be held on June 18th. See the f= ollowing link for more information: http://www.ietf.org/mail-archive/web/rt= cweb/current/msg14632.html. =09=09=09=09=09=09
=09=09=09=09=09
=20 =09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=
=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09=09=09 =09=09=09=09=09=09 =09=09=09=09=09
=09=09=09=09=09=09=09=09Participate now =09=09=09=09=09=09=09
=09=09=09=09=09
=
=09
=09=09 =09=09=09 =09=09=09=09 =09=09=09=09=09 =09=09=09=09=09 =09=09=09=09 =09=09=09 =09=09
=09=09=09=09=09=09 =09=09=09=09=09 =09=09=09=09=09=09
=09=09=09=09=09=09=09 What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date f= or meeting with a group of people. Learn more about how Doodle works.
=09=09=09=09=09=09
=09=09=09=09=09
=09
=09=09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09 =09=09 =09 =09=09 =09=09 =09=09 =09 =09=09 =09=09
=09=09 =09You have received this e-mail because "Sean Turner&qu= ot; has invited you to participate in the Doodle poll "RTCweb June 18t= h Virtual Interim Meeting - JSEP-focused." =09=09
=09
Doodle is also available for iOS and Android.
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

------=_Part_225022_1442134796.1432223711276-- From nobody Thu May 21 09:39:55 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 7A08B1A001C for ; Thu, 21 May 2015 09:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, 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 5f_HIJS6SbRU for ; Thu, 21 May 2015 09:39:52 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 3A1721A6FFB for ; Thu, 21 May 2015 09:39:52 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so14592940igb.1 for ; Thu, 21 May 2015 09:39:51 -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=ZeqpkYKg8EJcMHvblukLYI5aoklkeeKYezDSMIkYwko=; b=BaeoTF/lUiPnN9wftckPm1rp5ufxbJSnyaML4TUGpt02SR53+ieWKZnTolHHpaPi3l nDwPXihm88mLSdvrLdJxs2wysdbAveTJ4gOM7wLsJkIkEpDP6mkLwNHfgOay42dW657R +kwrb7zz/3eCwYLJVh3bKO8F5bDJIvTzcntbZPUqrgmnngTV6J8gHrrRggGwNxZdcvn6 TlwIZrf65IxFzmg7ygKVvkSWWIt1BI/+knOlimtzFQMgi0hro/29OPMEvPcDhFyriNrH 3jAxy4lJFbGXGyks0qw7fK5pUCRpRspq+xd+scu8WVNX8Q5hWybnvbPmAiIlBr0UQjJU xFwA== 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=ZeqpkYKg8EJcMHvblukLYI5aoklkeeKYezDSMIkYwko=; b=IArhgA8C0E3tCo5v8k0VkjvkmEkdPWt58YW9Y/1ei7zpPpxDVBv3fuEWC2zwI7HGtM sQ41bYJs5qyYLyQAhQFYrN3AI59g3u8heoIN3NEkOWUoNS2vmKNq96dbdRBp7J8yWpBI XjJwKdb5iDr1Z+4q0NHZv+IntvDNMU03QmC0xCbLwuL+BHm9p7zLEli65eznHOiVzt2X 6n759pZ97QbsnpdodrvzstjTf5bRqjyFRv90SjsgURA4B1+Wtj6TUFGLFv3OP2YO66TG gUJ2MdVtzOoIvH4fQn8wVD1Qg0NZ2vqmvzLTYi61JIzOufCQ287lPxSkRp2x6iSKCjGf Ljyw== X-Gm-Message-State: ALoCoQkTYyNx/QO4/l2np7wE003zZWt1Fzqo4AZ9QixA0GdhqlpzCCl1yHKRXAuuc9HpzQTxLT3H X-Received: by 10.43.24.76 with SMTP id rd12mr4255053icb.84.1432226391709; Thu, 21 May 2015 09:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.5.1 with HTTP; Thu, 21 May 2015 09:39:31 -0700 (PDT) In-Reply-To: <0FEF3981-063C-450C-9E6A-685696B4F5E0@ieca.com> References: <5549E480.4030806@alvestrand.no> <0FEF3981-063C-450C-9E6A-685696B4F5E0@ieca.com> From: Justin Uberti Date: Thu, 21 May 2015 09:39:31 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=bcaec51dd02d50f08c05169a319f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:39:53 -0000 --bcaec51dd02d50f08c05169a319f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 20, 2015 at 5:56 AM, Sean Turner wrote: > On May 07, 2015, at 09:46, Martin Thomson > wrote: > > > On 7 May 2015 at 02:38, Ted Hardie wrote: > >> I am not chair with the particularly good position to collect feedback= , > but > >> I happen to know he's flying today. My understanding of the current > theory > >> is that we ask TLS what cipher suites and version numbers to mandate; > if we > >> had a strong reason to disagree, we would need to document why we went > with > >> something other than what they suggested. > >> > >> He-who-is-in-the-air may tell me I've got it wrong, of course. > > > > Sounds good, perhaps we should ask he-who-will-eventually-land to pass > > on the question, unless we both are wrong. > > On it - albeit a little late. It=E2=80=99s worth noting that the UTA BCP1= 95 (RFC > 7525) (Recommendations for Secure Use of Transport Layer Security (TLS) a= nd > Datagram Transport Layer Security (DTLS)) was recently published and > recommends this set of algorithms: > > o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > I also admit that I prefer ECDSA, primarily for smaller certs for > comparable security, but acknowledge Martin=E2=80=99s point about the cer= t > management APIs. > I'd also like to see ECDSA mandated, since it is much more friendly for low-power devices. --bcaec51dd02d50f08c05169a319f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 20, 2015 at 5:56 AM, Sean Turner <turners@ieca.com><= /span> wrote:
On May 07, 2015, at 0= 9:46, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 7 May 2015 at 02:38, Ted Hardie <ted.ietf@gmail.com> wrote:
>> I am not chair with the particularly good position to collect feed= back, but
>> I happen to know he's flying today.=C2=A0 My understanding of = the current theory
>> is that we ask TLS what cipher suites and version numbers to manda= te; if we
>> had a strong reason to disagree, we would need to document why we = went with
>> something other than what they suggested.
>>
>> He-who-is-in-the-air may tell me I've got it wrong, of course.=
>
> Sounds good, perhaps we should ask he-who-will-eventually-land to pass=
> on the question, unless we both are wrong.

On it - albeit a little late. It=E2=80=99s worth noting that the UTA= BCP195 (RFC 7525) (Recommendations for Secure Use of Transport Layer Secur= ity (TLS) and Datagram Transport Layer Security (DTLS)) was recently publis= hed and recommends this set of algorithms:

=C2=A0 =C2=A0o=C2=A0 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
=C2=A0 =C2=A0o=C2=A0 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
=C2=A0 =C2=A0o=C2=A0 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
=C2=A0 =C2=A0o=C2=A0 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

I also admit that I prefer ECDSA, primarily for smaller certs for comparabl= e security, but acknowledge Martin=E2=80=99s point about the cert managemen= t APIs.

I'd also like to see ECDSA = mandated, since it is much more friendly for low-power devices.=C2=A0
=
--bcaec51dd02d50f08c05169a319f-- From nobody Thu May 21 10:03:59 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 A2DA11A006F for ; Thu, 21 May 2015 10:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvcb_62xnNF1 for ; Thu, 21 May 2015 10:03:56 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (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 894581A0062 for ; Thu, 21 May 2015 10:03:56 -0700 (PDT) Received: by yhom41 with SMTP id m41so22755312yho.1 for ; Thu, 21 May 2015 10:03:55 -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=Z2KEMze8/IqbezXDGvnsryWRSKpOcVQWeyuDn7nyDvA=; b=iaKLmjFDEokRvAquZUuWUOAjL2emqflusE50iAuqrYKTHvYyw6uq9im2c7Jykr1oEn b4KevlSyMmUxdoB6ia0aa31JSYQ0O9Aq5GUthtdAgwuAv/QT63n/xVRBAXMPV9WIZkNa HYVD30uOzA9yA6cj0ofTUT7lghmy3RZAKyGerByPdObN8Q73+soDMbsHPiXM4YSVkN6c tOLwMIohJTV04dbowPPksW2gs/cL0mmE8E/AcyjNhy7u6A9hF4aSZGMmjBQvIB4SctWG Zuxr7j96OYydpOASwtOXvyBEFLIlpQuitH/IosN9cJ70RWcqYXsTW+nxcFpXDS4/2nwd kh9g== MIME-Version: 1.0 X-Received: by 10.236.208.106 with SMTP id p70mr3599145yho.1.1432227835884; Thu, 21 May 2015 10:03:55 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Thu, 21 May 2015 10:03:55 -0700 (PDT) In-Reply-To: References: <5549E480.4030806@alvestrand.no> <0FEF3981-063C-450C-9E6A-685696B4F5E0@ieca.com> Date: Thu, 21 May 2015 10:03:55 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:03:57 -0000 On 21 May 2015 at 09:39, Justin Uberti wrote: >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 This would be my preference for a MUST. From nobody Thu May 21 13:01: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 C4EEB1A8A12 for ; Thu, 21 May 2015 13:01:29 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vssXRC08kitL for ; Thu, 21 May 2015 13:01:27 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.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 76BAE1A8A39 for ; Thu, 21 May 2015 13:01:26 -0700 (PDT) Received: by obcus9 with SMTP id us9so68457781obc.2 for ; Thu, 21 May 2015 13:01:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UNsiDaeFZhMSU+gAw5z06sCirqMPHv7uf/In5ASMHiY=; b=B9PFi1TwXCbmka/fn6WxMNfUsdRGZyC66IaXhUTwPdMoP8tI9DhF/ZxphdqEEPZ7st 1x9QZADnWxCwCqaojlR8q2JK2thw9ZJM+qnx/rpIhxuVWtHTdOipiVLDZVYRhzJ+fNKg imFDmrn0Ska8IVLgsPmt/hdCmZIUamqpJyb58htX4F/0z5TjtVtvDS2x4WpUyUJiPZeK ThDdcU4OJnqKg3gzJjgnMfsQQRDWr93DC7OCBGh1w2Q7uaBgzfyJYmkWxCXNjs1lhQZg kdZHWvEQLnKz9+sdVpfmz08JCvnHrb1CBcmBpU82zLAVnFSEMNwCBtEojiScM8s9cegD rCFw== X-Gm-Message-State: ALoCoQkfkl2M29WT0TQkB4096u7ePA6CgSCn2oxivxcx3CuMpnZV75uAEhgQy6OSzXkwlaAO0dpS X-Received: by 10.182.70.100 with SMTP id l4mr3658155obu.77.1432238485953; Thu, 21 May 2015 13:01:25 -0700 (PDT) Received: from camionet.local (9.6.69.91.rev.sfr.net. [91.69.6.9]) by mx.google.com with ESMTPSA id s3sm12650892obt.27.2015.05.21.13.01.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 13:01:25 -0700 (PDT) Message-ID: <555E3991.9010809@jitsi.org> Date: Thu, 21 May 2015 22:01:21 +0200 From: Emil Ivov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bernard Aboba , "rtcweb@ietf.org" , The IESG References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Thu, 21 May 2015 20:01:29 -0000 On 21.05.15 1: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. I think we can easily fix this if we replace semantic usage of "STUN request" throughout the specification with "STUN transaction". For example, in page 4 in the following paragraph: 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). replacing request with transaction we would get: Each STUN transaction MUST use a new cryptographically strong [RFC4086] STUN transaction ID. Each STUN transaction for consent is transmitted once only. Hence, the sender cannot assume that it will receive a response for each consent transaction, and a response might be for a previous transaction (rather than for the most recently sent request). The fact that this entire paragraphs becomes redundant after the change is probably good indication that we were basically defining STUN transactions ... Obviously using transactions for every consent check would leave us with a couple of potential issues, like, what if you already have an ongoing STUN transaction and randomization tells you to start a new one. Those could be easily fixed however. For example, by simply starting the random timer after a STUN transaction has completed (as opposed to after sending the request). Emil -- https://jitsi.org From nobody Thu May 21 14:13:33 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 50F6D1A9064; Thu, 21 May 2015 14:13: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 7hvz5t_4e9vz; Thu, 21 May 2015 14:13:30 -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 A1F0A1A9061; Thu, 21 May 2015 14:13:29 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so98001495wgb.3; Thu, 21 May 2015 14:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RDogaSd7479udWww3IwVtVd0PPeXLoI+dtAzfSZ/BFA=; b=tesebUsOHuU90+Tnc2vL53bWnR5uqZjnPax/A5eRkfgU4xf++zdfrAS+d0aRUKSHn0 46qmaK+0oBsMAgXfJ5qMwNShtvuCY7oCWt3UwWYq8dh9HLR3k7a+f89X8X9qdeUh9LNv u308TY/37MU4f1iRFLCHsqgp7uaQP5CXLWFb+hX5XyRNbJAXsFnLGmXCNrXUzuk32BlH 8SMoVaUkNpCgZZf2W6fbv0FV3APCZwlf3/BL/kpWDxM5MdAQSyU9/eZ2OzbzREECPyCH SjokTGjvN+aUQIqgPDEZMJkvPU0M8zQZ9E05uE9jb3lvRqwc7LBPwX8/mpCkUMIoEQkz +Cug== X-Received: by 10.181.13.165 with SMTP id ez5mr1116682wid.77.1432242808389; Thu, 21 May 2015 14:13:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Thu, 21 May 2015 14:13:08 -0700 (PDT) In-Reply-To: <555E3991.9010809@jitsi.org> References: <555E3991.9010809@jitsi.org> From: Bernard Aboba Date: Thu, 21 May 2015 14:13:08 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=f46d043c80d0d3868605169e03d5 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: Thu, 21 May 2015 21:13:32 -0000 --f46d043c80d0d3868605169e03d5 Content-Type: text/plain; charset=UTF-8 Emil said: "Each STUN transaction MUST use a new cryptographically strong [RFC4086] STUN transaction ID. Each STUN transaction for consent is transmitted once only. Hence, the sender cannot assume that it will receive a response for each consent transaction, and a response might be for a previous transaction (rather than for the most recently sent request). [BA] Within a STUN transaction you can have retransmissions, so not sure about the "transmitted once only" part. But I generally agree with your point - reusing the RF 5389 STUN transaction and RTT/RTO mechanism would fix the problems. The fact that this entire paragraphs becomes redundant after the change is probably good indication that we were basically defining STUN transactions ... [BA] I agree - and the mechanism specified in this document is not as good as the one in RFC 5389 (which is already widely deployed). Obviously using transactions for every consent check would leave us with a couple of potential issues, like, what if you already have an ongoing STUN transaction and randomization tells you to start a new one. Those could be easily fixed however. For example, by simply starting the random timer after a STUN transaction has completed (as opposed to after sending the request)." [BA] Exactly. So you end up with a series of STUN transactions spaced randomly apart. Except now you get adaptation to network characteristics, backoff (which reduces the ability to use freshness to mount denial of service attacks), RTT/RTO estimation, etc. Plus you get to reuse RFC 5389 code (which many of us were going to do anyway, since it will work better than what is specified in this draft). On Thu, May 21, 2015 at 1:01 PM, Emil Ivov wrote: > On 21.05.15 1: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. >> > > I think we can easily fix this if we replace semantic usage of "STUN > request" throughout the specification with "STUN transaction". > > For example, in page 4 in the following paragraph: > > 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). > > replacing request with transaction we would get: > > Each STUN transaction MUST use a new cryptographically strong > [RFC4086] STUN transaction ID. Each STUN transaction for consent > is transmitted once only. Hence, the sender cannot assume that it > will receive a response for each consent transaction, and a response > might be for a previous transaction (rather than for the most > recently sent request). > > The fact that this entire paragraphs becomes redundant after the change is > probably good indication that we were basically defining STUN transactions > ... > > Obviously using transactions for every consent check would leave us with a > couple of potential issues, like, what if you already have an ongoing STUN > transaction and randomization tells you to start a new one. Those could be > easily fixed however. For example, by simply starting the random timer > after a STUN transaction has completed (as opposed to after sending the > request). > > Emil > > -- > https://jitsi.org > --f46d043c80d0d3868605169e03d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Emil said:

=C2=A0=C2=A0 &qu= ot;Each STUN transaction MUST use a new cryptographically strong
=C2=A0= =C2=A0[RFC4086] STUN transaction ID.=C2=A0 Each STUN transaction for conse= nt
=C2=A0 =C2=A0is transmitted once only. Hence, the= sender cannot assume that it
 =C2=A0 =C2=A0will receive a respon= se for each consent transaction, and a response
=C2=A0 =C2=A0might be f= or a previous transaction (rather than for the most
=C2=A0 =C2=A0recent= ly sent request).

[BA]=C2=A0Within a STUN transact= ion you=C2=A0can have retransmissions, so not sure about the "transmit= ted once only" part.=C2=A0 But I generally agree with your point - reu= sing the RF 5389 STUN transaction and RTT/RTO mechanism would fix the probl= ems.

=C2=A0The fact that this entire paragraphs becomes redundant a= fter the change is probably good indication that we were basically defining= STUN transactions ...

[BA]=C2=A0I agree - and the= mechanism specified in this document is not as good as the one in RFC 5389= (which is already widely deployed).

=C2=A0Obviously using t= ransactions for every consent check would leave us with a couple of potenti= al issues, like, what if you already have an ongoing STUN transaction and r= andomization tells you to start a new one. Those could be easily fixed howe= ver. For example, by simply starting the random timer after a STUN transact= ion has completed (as opposed to after sending the request)."

[BA] Exactly.=C2=A0 So you end up with a series of STUN tr= ansactions spaced randomly apart.=C2=A0 Except now you get adaptation to ne= twork characteristics, backoff (which reduces the ability to use freshness = to mount denial of service attacks), RTT/RTO estimation, etc.=C2=A0 Plus yo= u get to reuse RFC 5389 code (which many of us were going to do anyway, sin= ce it will work better than what is specified in this draft).=C2=A0
<= /div>

On Thu, May = 21, 2015 at 1:01 PM, Emil Ivov <emcho@jitsi.org> wrote:
On 21.05.15 1: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.=C2=A0 Rather than building upon the RFC 53= 89
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.

 I think we can easily fix this if we replace semantic usage of "STUN r= equest" throughout the specification with "STUN transaction"= .

For example, in page 4 in the following paragraph:

=C2=A0 =C2=A0Each STUN binding request for consent MUST use a new
=C2=A0 =C2=A0cryptographically strong [RFC4086] STUN transaction ID.=C2=A0 = Each STUN
=C2=A0 =C2=A0binding requests for consent is transmitted once only.=C2=A0 H= ence, the
=C2=A0 =C2=A0sender cannot assume that it will receive a response for each = consent
=C2=A0 =C2=A0request, and a response might be for a previous request (rathe= r than
=C2=A0 =C2=A0for the most recently sent request).

 replacing request with transaction we would get:

=C2=A0 =C2=A0Each STUN transaction MUST use a new cryptographically strong<= br> =C2=A0 =C2=A0[RFC4086] STUN transaction ID.=C2=A0 Each STUN transaction for= consent
=C2=A0 =C2=A0is transmitted once only. Hence, the sender cannot assume that= it
 =C2=A0 =C2=A0will receive a response for each consent transaction, and a re= sponse
=C2=A0 =C2=A0might be for a previous transaction (rather than for the most<= br> =C2=A0 =C2=A0recently sent request).

The fact that this entire paragraphs becomes redundant after the change is = probably good indication that we were basically defining STUN transactions = ...

Obviously using transactions for every consent check would leave us with a = couple of potential issues, like, what if you already have an ongoing STUN = transaction and randomization tells you to start a new one. Those could be = easily fixed however. For example, by simply starting the random timer afte= r a STUN transaction has completed (as opposed to after sending the request= ).

Emil

--
https://jitsi.org

--f46d043c80d0d3868605169e03d5-- From nobody Thu May 21 16:10:27 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 6CC531A8A9D; Thu, 21 May 2015 16:10: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 VZWX40O1fw8V; Thu, 21 May 2015 16:10:20 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 4F7561A001D; Thu, 21 May 2015 16:10:20 -0700 (PDT) Received: by yked142 with SMTP id d142so702289yke.3; Thu, 21 May 2015 16:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RYvHsIh2hyFrjUsWrZ5C7P+tOKW0jCgiTaWdk0O0bkk=; b=vjG+RWNlYmoo+ZHOU3OCrIJDLNKN2u0WgeAhkioK3RMwN0+G5FYzsjjyhkYeBGGMN5 DXIRsvInJ3ulAXQsWMjAYD+o8Fbq0Mf2JJQLu2hJGKICwQS+8rGxFEDURZqUXYNM1o8Z 6AGTi0zh0O5TA6238hLuwD6gpVR+R7VcyKYEe1vtZ5i3Kq25cVvvIIGcBo59hVC6T7MP dMYs90vSdzA53gT0AvxNKqbJWcleLrVmtzMg9Bz5pEfBfm0OM+VSKvEyrLVaEd/h5tAm uKVRUD6JZGaNitzEdASOywfzSDMJIQW/9OnwpAoPZMbcuuWe3VinLAzDOF1Kp8sIRurb sT8Q== MIME-Version: 1.0 X-Received: by 10.236.47.169 with SMTP id t29mr4984511yhb.69.1432249819747; Thu, 21 May 2015 16:10:19 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Thu, 21 May 2015 16:10:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 May 2015 16:10:19 -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: Thu, 21 May 2015 23:10:22 -0000 On 20 May 2015 at 16:48, Bernard Aboba wrote: > This is a review of draft-ietf-rtcweb-stun-consent-freshness. ... > 1. Adaptation of the RTO via RTT measurement I agree that this is a concern, but we have a means of determining RTO, so we just need to add text that says something like: The initial STUN transaction produces a value for RTO on any given candidate pair. That value is used in determining how long to await a STUN response, it is updated as new STUN responses are received. > 2. Consistent number of requests sent without a response (Rc) before > transaction failure > 3. Total time to transaction failure robust against routing transients I don't agree that either of these is a problem. It's a design, certainly, but it suffers from a dire lack of determinism in running time, something that might be exploited to increase denial of service exposure time. > 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. If response i arrives after i+1, that's not going to provide any useful information about RTO itself (RTO jitter perhaps). Note that the original STUN design doesn't even allow you to detect this sort of reordering, since the transaction ID is reused, so that's strictly worse. > 2. Inconsistent number of requests before failure. Given the randomization, > 4 to 6 requests might be sent within the 30 seconds. That doesn't bother me. > 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. How can we make this clearer? It says: Consent expires after 30 seconds. And: [...] a STUN binding request can be sent periodically [at] a default interval of 5 seconds, [...] Those are independent. If you are under the impression that these are somehow coupled, we can add "This timer is independent of the consent expiry timeout." > 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." I like that. Note that "excessive traffic" was intended to be in time, not volume. > 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. That's easy, let's just say that this process applies *after* consent has been acquired. maybe we could move this up to Section 4: Initial consent to send traffic is obtained using ICE. Consent expires after 30 seconds. An endpoint maintains consent as described in Section 4.2. The second sentence can stay where it is to provide context. Repetition of that point is harmless. > 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. WFM. We can cite that instead. > 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? ... is needed to obtain consent to send *on that candidate pair*. There was a long discussion about this point, the conclusion of which was "use it or lose it". This captures that conclusion. I can't remember the details of the discussion, but I think that it wasn't a security concern but a robustness one. > Also, it is not clear what "any reason" means - We can drop those words. From nobody Thu May 21 16:55: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 D64571A90F3; Thu, 21 May 2015 16:55:19 -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 DzyZQlKrzuqt; Thu, 21 May 2015 16:55:15 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 7F8A61A8AF0; Thu, 21 May 2015 16:55:14 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so2525564wgb.3; Thu, 21 May 2015 16:55: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:from:date:message-id:subject:to :cc:content-type; bh=N+wf94Zkd8CoRlrsxjPgZP4OCcv8GWvInvxyLaSDI08=; b=ULXEWUPWkLaM1YVjsJ70FbjUS448IbxIak5G9GI8rE2qeTgCSvFThkgQqYCAqKY+Mp sIc+03GotrR7RvlXUVigY/ckZJoEv05o9GfLaW0Py70RfFlzH4O28VCw9gMaJhCH67DN R6sIHQpoHz0tPaljRj491ZpzKp6SFq2IryLhZmDbneP2+zIKR8PEvq8P5u/QnlxHdAX+ tUVfBGWDGXX4gRIn4ImgqC41ctot9gSZfJXlNMy2Wdij//0lmiFKdtOhAW+c5K2u/Uea e/8Wc2kyLQ/DruMg9pPwBX82ySelnHgvJmY1ixQtTJI/JfIwRWrF0NSoY+VgKgqKjCUI N6+g== X-Received: by 10.181.13.165 with SMTP id ez5mr2002316wid.77.1432252513305; Thu, 21 May 2015 16:55:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Thu, 21 May 2015 16:54:52 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 21 May 2015 16:54:52 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043c80d048c81e0516a04613 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: Thu, 21 May 2015 23:55:20 -0000 --f46d043c80d048c81e0516a04613 Content-Type: text/plain; charset=UTF-8 Martin said: > 1. Adaptation of the RTO via RTT measurement [Martin] I agree that this is a concern, but we have a means of determining RTO, so we just need to add text that says something like: The initial STUN transaction produces a value for RTO on any given candidate pair. That value is used in determining how long to await a STUN response, it is updated as new STUN responses are received. [BA] If you cite the RFC 5389 text relating to initial RTO, caching, estimation algorithm, etc. you can then use the calculated value to determine how long to await a STUN response. > 2. Consistent number of requests sent without a response (Rc) before > transaction failure > 3. Total time to transaction failure robust against routing transients I don't agree that either of these is a problem. It's a design, certainly, but it suffers from a dire lack of determinism in running time, something that might be exploited to increase denial of service exposure time. [BA] The effective transmission rate matters in DDOS more than running time - which is why the RFC 5389 backoff algorithm makes a difference. Here an Rc value of 7 is not as critical as having it be a constant. > 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. If response i arrives after i+1, that's not going to provide any useful information about RTO itself (RTO jitter perhaps). [BA] That is true if the transaction ID doesn't change (e.g. RFC 5389). But if the transaction ID changes, then you can use the arrival time of response i to get a better RTO estimate, even if i+1 arrives first. This is valuable since it is most likely to happen when the originally calculated RTO value is too low, making a false retransmission timeout more likely. RFC 5682 describes some of the concerns relating to F-RTO. Note that the original STUN design doesn't even allow you to detect this sort of reordering, since the transaction ID is reused, so that's strictly worse. [BA] Right. So by changing the transaction ID on each request, it is possible to do better - particularly if F-RTO can be taken into account. > 2. Inconsistent number of requests before failure. Given the randomization, > 4 to 6 requests might be sent within the 30 seconds. That doesn't bother me. [BA] Varying Rc will produce a false retransmission probability that will vary by network conditions, particularly if Rc can be small (e.g. only a few retransmissions prior to declaring consent revocation). > 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. How can we make this clearer? [BA] If consent expires at 30 seconds + RTO (or better, at last request sending time plus RTO) then that would clarify things. It says: Consent expires after 30 seconds. I like that. Note that "excessive traffic" was intended to be in time, not volume. [BA] Why would time matter if consent packets aren't being sent (e.g. backoff)? > > [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. That's easy, let's just say that this process applies *after* consent has been acquired. maybe we could move this up to Section 4: [BA] The question is when consent is acquired. I'd assume that this begins when media starts being sent - which according to RFC 5245 can occur after a successful connectivity check response. So ICE isn't necessarily complete. ... is needed to obtain consent to send *on that candidate pair*. [BA] That part makes sense - but if there is another valid pair, it should be possible to start sending media on that pair without having to do an ICE restart. That is allowed under RFC 5245. On Thu, May 21, 2015 at 4:10 PM, Martin Thomson wrote: > On 20 May 2015 at 16:48, Bernard Aboba wrote: > > This is a review of draft-ietf-rtcweb-stun-consent-freshness. > ... > > 1. Adaptation of the RTO via RTT measurement > > I agree that this is a concern, but we have a means of determining > RTO, so we just need to add text that says something like: The initial > STUN transaction produces a value for RTO on any given candidate pair. > That value is used in determining how long to await a STUN response, > it is updated as new STUN responses are received. > > > 2. Consistent number of requests sent without a response (Rc) before > > transaction failure > > 3. Total time to transaction failure robust against routing transients > > I don't agree that either of these is a problem. It's a design, > certainly, but it suffers from a dire lack of determinism in running > time, something that might be exploited to increase denial of service > exposure time. > > > 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. > > If response i arrives after i+1, that's not going to provide any > useful information about RTO itself (RTO jitter perhaps). Note that > the original STUN design doesn't even allow you to detect this sort of > reordering, since the transaction ID is reused, so that's strictly > worse. > > > 2. Inconsistent number of requests before failure. Given the > randomization, > > 4 to 6 requests might be sent within the 30 seconds. > > That doesn't bother me. > > > 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. > > How can we make this clearer? > > It says: > > Consent expires after 30 seconds. > > And: > > [...] a STUN binding request can be sent > periodically [at] a default interval of 5 seconds, [...] > > Those are independent. If you are under the impression that these are > somehow coupled, we can add "This timer is independent of the consent > expiry timeout." > > > 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." > > I like that. Note that "excessive traffic" was intended to be in > time, not volume. > > > 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. > > That's easy, let's just say that this process applies *after* consent > has been acquired. maybe we could move this up to Section 4: > > Initial consent to send traffic is obtained using ICE. Consent > expires after 30 seconds. An endpoint maintains consent as > described in Section 4.2. > > The second sentence can stay where it is to provide context. > Repetition of that point is harmless. > > > 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. > > WFM. We can cite that instead. > > > 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? > > ... is needed to obtain consent to send *on that candidate pair*. > > There was a long discussion about this point, the conclusion of which > was "use it or lose it". This captures that conclusion. I can't > remember the details of the discussion, but I think that it wasn't a > security concern but a robustness one. > > > Also, it is not clear what "any reason" means - > > We can drop those words. > --f46d043c80d048c81e0516a04613 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin said:=C2=A0
> 1= . Adaptation of the RTO via RTT measurement

[Martin] I agree that this is a concern, but we= have a means of determining
RTO, so we just need to add= text that says something like: The initial
STUN transac= tion produces a value for RTO on any given candidate pair.
That value is used in determining how long to await a STUN response,
it is updated as new STUN responses are received.
[BA] If you cite the RFC 5389 text relating to initial RT= O, caching, estimation algorithm, etc. you can then use the calculated valu= e to determine how long to await a STUN response.=C2=A0

> 2. Consistent number of requests sent without a response (Rc= ) before
> transaction failure
> 3. Total time to transaction f= ailure robust against routing transients

I don't agree that either of these is a proble= m.=C2=A0 It's a design,
certainly, but it suffers fr= om a dire lack of determinism in running
time, something= that might be exploited to increase denial of service
e= xposure time.

[BA] The effective transmissi= on rate matters in DDOS more than running time - which is why the RFC 5389 = backoff algorithm makes a difference.=C2=A0 Here an Rc value of 7 is not as= critical as having it be a constant. =C2=A0

&= gt; 1. No RTT/RTO estimation - and given that responses to a request that a= rrive
> after a new request is sent are ignored, no ability to make u= se of the
> information that is available. Effectively, the specifica= tion sets the RTO
> to be a random value between 4 and 6 seconds, wit= h no relationship to
> network characteristics.

If response i arrives after i+1, that= 's not going to provide any
useful information about= RTO itself (RTO jitter perhaps). =C2=A0

[BA] That is true if the transaction ID doesn't cha= nge (e.g. RFC 5389).=C2=A0 But if the transaction ID changes, then you can = use the arrival time of response i to get a better RTO estimate, even if i+= 1 arrives first. This is valuable since it is most likely to happen when th= e originally calculated RTO value is too low, making a false retransmission= timeout more likely.=C2=A0 RFC 5682 describes some of the concerns relatin= g to F-RTO.=C2=A0

Not= e that
the original STUN design doesn't even allow y= ou to detect this sort of
= reordering, since the transact= ion ID is reused, so that's strictly
worse.

[BA] Right.=C2=A0 So by changing the transaction ID= on each request, it is possible to do better - particularly if F-RTO can b= e taken into account.=C2=A0

> 2. Inconsiste= nt number of requests before failure.=C2=A0 Given the randomization,
>= ; 4 to 6 requests might be sent within the 30 seconds.

That doesn't bother me.

[BA] Varying Rc will produce a false retransmission= probability that will vary by network conditions, particularly if Rc can b= e small (e.g. only a few retransmissions prior to declaring consent revocat= ion).=C2=A0

> 3. Unclear timer behavior.=C2= =A0 Does an implementation continue to send requests
> until 30 secon= ds has elapsed, or does it stop before then so as to allow for
> a re= sponse to the last request to arrive?=C2=A0 One could interpret the above t= o
> 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 tim= er expires.

How = can we make this clearer?

[BA] If consent e= xpires at 30 seconds + RTO (or better, at last request sending time plus RT= O) then that would clarify things.=C2=A0

It sa= ys:

=C2=A0 =C2=A0Consent expires after 30 seconds.

I like that.=C2=A0 Note that "excess= ive traffic" was intended to be in
time, not volume= .

[BA] Why would time matter if consent pac= kets aren't being sent (e.g. backoff)? =C2=A0
=
>
> [BA] The last sentence seems to imply that consent checks = are scheduled
> before ICE completes, and would therefore interact wi= th the scheduling and
> pacing mechanism specified in RFC 5245.=C2=A0= This does make some sense, since in
> Trickle ICE, trickling all the= candidates might take a while, and media
> might be sent after a suc= cessful response, so that consent would be in
> order.=C2=A0 However,= if that is the intent, then it needs to be explicitly
> stated, and = this document
> needs to contain an Updates: RFC 5245 header.

= That's easy, let= 9;s just say that this process applies *after* consent
h= as been acquired.=C2=A0 maybe we could move this up to Section 4:

[BA] The question is when consent is acquired. I'= ;d assume that this begins when media starts being sent - which according t= o RFC 5245 can occur after a successful connectivity check response.=C2=A0 = So ICE isn't necessarily complete.=C2=A0

... is needed to obtain consent to send *on that candidate pair= *.

[BA] That part makes sense - but if ther= e is another valid pair, it should be possible to start sending media on th= at pair without having to do an ICE restart.=C2=A0 That is allowed under RF= C 5245.=C2=A0


On Thu, May 21, 2015 at 4:10 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 20 May 2015 at 16:48, Bernard Aboba <bernard.aboba@gmail.com> wrot= e:
> This is a review of draft-ietf-rtcweb-stun-consent-freshness.
...
> 1. Adaptation of the RTO via RTT measurement

I agree that this is a concern, but we have a means of determining RTO, so we just need to add text that says something like: The initial
STUN transaction produces a value for RTO on any given candidate pair.
That value is used in determining how long to await a STUN response,
it is updated as new STUN responses are received.

> 2. Consistent number of requests sent without a response (Rc) before > transaction failure
> 3. Total time to transaction failure robust against routing transients=

I don't agree that either of these is a problem.=C2=A0 It's = a design,
certainly, but it suffers from a dire lack of determinism in running
time, something that might be exploited to increase denial of service
exposure time.

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

If response i arrives after i+1, that's not going to provide any=
useful information about RTO itself (RTO jitter perhaps).=C2=A0 Note that the original STUN design doesn't even allow you to detect this sort of<= br> reordering, since the transaction ID is reused, so that's strictly
worse.

> 2. Inconsistent number of requests before failure.=C2=A0 Given the ran= domization,
> 4 to 6 requests might be sent within the 30 seconds.

That doesn't bother me.

> 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.
How can we make this clearer?

It says:

=C2=A0 =C2=A0Consent expires after 30 seconds.

And:

=C2=A0 =C2=A0[...] a STUN binding request can be sent
=C2=A0 =C2=A0periodically [at] a default interval of 5 seconds, [...]

Those are independent.=C2=A0 If you are under the impression that these are=
somehow coupled, we can add "This timer is independent of the consent<= br> expiry timeout."

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

I like that.=C2=A0 Note that "excessive traffic" was inten= ded to be in
time, not volume.

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

That's easy, let's just say that this process applies *after= * consent
has been acquired.=C2=A0 maybe we could move this up to Section 4:

=C2=A0 =C2=A0Initial consent to send traffic is obtained using ICE.=C2=A0 C= onsent
=C2=A0 =C2=A0expires after 30 seconds.=C2=A0 An endpoint maintains c= onsent as
described in Section 4.2.

The second sentence can stay where it is to provide context.
Repetition of that point is harmless.

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

WFM.=C2=A0 We can cite that instead.

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

... is needed to obtain consent to send *on that candidate pair*.
There was a long discussion about this point, the conclusion of which
was "use it or lose it".=C2=A0 This captures that conclusion.=C2= =A0 I can't
remember the details of the discussion, but I think that it wasn't a security concern but a robustness one.

> Also, it is not clear what "any reason" means -

We can drop those words.

--f46d043c80d048c81e0516a04613-- From nobody Thu May 21 19:41: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 325771A8FD2; Thu, 21 May 2015 19:41:09 -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 itwb6ncKSgEB; Thu, 21 May 2015 19:41:07 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC4D1A8F51; Thu, 21 May 2015 19:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2853; q=dns/txt; s=iport; t=1432262467; x=1433472067; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Hnx8As9DlnvfbuywhSaSg4GHjBi8CMptGB17ekYMV+I=; b=hg3uvdnfzetPddlZd6u3C3ustyl1tQ8MRzdT7LUbBDRmm0xmnmRDTdWE gStNsmI13SemT8i8ysWC9CFvv3+Bjjob78lDJ+RqLR1WBXo8tbL01rRK4 2RhpKzaQRwiaNGw61PNwJUj3B/KIGFTXy0XreiD1pDQStbif/AMPGcKwF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFBADkll5V/5hdJa1cgxBUXgbCKmYJgU8KhS1KAoFFOBQBAQEBAQEBgQqEIgEBAQQBAQE3NBcEAgEIDgMEAQEBChQJBycLFAkIAgQBEgiIJA3SXQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEizqEVDgGgxGBFgWSfYQ1nXwjg3hvgQMFPoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,473,1427760000"; d="scan'208";a="152373388" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 22 May 2015 02:40:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4M2em89013317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 May 2015 02:40:48 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; Thu, 21 May 2015 21:40:48 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Emil Ivov , Bernard Aboba , "rtcweb@ietf.org" , The IESG Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHQk1eS1ZbgKeHyC0Cjwx+443SghJ2HLvKAgAAXjrA= Date: Fri, 22 May 2015 02:40:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47859C63@xmb-rcd-x10.cisco.com> References: <555E3991.9010809@jitsi.org> In-Reply-To: <555E3991.9010809@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.37.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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: Fri, 22 May 2015 02:41:09 -0000 Hi Emil, The current mechanism helps determine RTT and packet loss, since transactio= n could be confused with the retransmission mechanism in RFC 5389 it was no= t used.=20 -Tiru > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: Friday, May 22, 2015 1:31 AM > To: Bernard Aboba; rtcweb@ietf.org; The IESG > Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness >=20 > On 21.05.15 1: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 538= 9 > > 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. >=20 > I think we can easily fix this if we replace semantic usage of "STUN > request" throughout the specification with "STUN transaction". >=20 > For example, in page 4 in the following paragraph: >=20 > 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). >=20 > replacing request with transaction we would get: >=20 > Each STUN transaction MUST use a new cryptographically strong > [RFC4086] STUN transaction ID. Each STUN transaction for consent > is transmitted once only. Hence, the sender cannot assume that it > will receive a response for each consent transaction, and a response > might be for a previous transaction (rather than for the most > recently sent request). >=20 > The fact that this entire paragraphs becomes redundant after the change > is probably good indication that we were basically defining STUN > transactions ... >=20 > Obviously using transactions for every consent check would leave us with > a couple of potential issues, like, what if you already have an ongoing > STUN transaction and randomization tells you to start a new one. Those > could be easily fixed however. For example, by simply starting the > random timer after a STUN transaction has completed (as opposed to after > sending the request). >=20 > Emil >=20 > -- > https://jitsi.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu May 21 20:55: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 196561A90C1; Thu, 21 May 2015 20:55:12 -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 qd5vm6H5tCLO; Thu, 21 May 2015 20:55:10 -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 073571A90BB; Thu, 21 May 2015 20:55:09 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-90-555ea89be708 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.6E.28096.B98AE555; Fri, 22 May 2015 05:55:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Fri, 22 May 2015 05:55:06 +0200 From: Christer Holmberg To: Martin Thomson , Bernard Aboba Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHQk1ePQtH0SmDHm02NITW7o6QoRZ2G7maAgABv25A= Date: Fri, 22 May 2015 03:55:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D82B0F3@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvre7sFXGhBs+Xylls2Pef2WLGn4nM FtfO/GO0WPuvnd2BxWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgylj46Q5bwWqeiv6JZxgb GJ9ydjFyckgImEjs2rqeFcIWk7hwbz0biC0kcJRR4vcEhS5GLiB7MaPEzAcrgIo4ONgELCS6 /2mD1IgIREg0X7nHCGIzCzhKXLyykRnEFhbwkJhy+xIzRI2nxPttN1ghbCuJm6cugs1nEVCV OD93DVgNr4CvRHfrNkaIXdMZJY4d6gIr4hQIlNi0ciGYzQh03PdTa5gglolL3HoynwniaAGJ JXvOM0PYohIvH/+DekZJYsX2S1DH6Ugs2P2JDcLWlli28DXUYkGJkzOfsExgFJuFZOwsJC2z kLTMQtKygJFlFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgTB3c8ttqB+PB546HGAU4GJV4 eBVsYkOFWBPLiitzDzFKc7AoifN6doWECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCcdq4g 65Lwtf/9Sw9dPpOTq73kO+P5r9vEqi0Yyh4/LXhRNy3lme8a6+++Bxb99XbONEmS/znLfGnb G+HeyQFrs0RVmlzM3DNv+jw4z7fj+UpWnvTwEIVubtW/mUbTjmqqN9ZrTGP4mv3m5xa3DHbF rK9Cr+6aBRrIimt8CHydqOCXMMXN9LMSS3FGoqEWc1FxIgCdPOYEigIAAA== 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: Fri, 22 May 2015 03:55:12 -0000 Hi, ... >> After consent is lost for any reason, the same ICE credentials MUST=20 >> NOT be used on the affected 5-tuple again. That means that a new=20 >> session, or an ICE restart, is needed to obtain consent to send. >> >> [BA] The second sentence does not follow from the first. RFC 5245=20 >> enables sending of media once a successful ICE connectivity check has be= en received. >> If multiple successful candidate pairs have been identified, why=20 >> should failure of consent on one candidate pair require an ICE restart=20 >> if another operational candidate pair exists? > >... is needed to obtain consent to send *on that candidate pair*. > >There was a long discussion about this point, the conclusion of which was = "use it or lose it". This captures that >conclusion. I can't remember the= details of the discussion, but I think that it wasn't a security concern b= ut a >robustness one. A while ago, we agreed that consent does not need to be maintained on candi= date pairs that aren't currently used. That should not be seen as lost cons= ent (i.e. if the UA wants to start sending data on the candidate pair it sh= ould not have to do ICE restart or create a new session). So, consent is lost if the UA sends consent requests, and does not receive = a response. Consent is NOT lost if the UA stops sending consent requests (a= nd therefor obviously will not receive a response). Perhaps that is clear in the draft, but if people have a different understa= nding it may need to be clarified :) Regards, Christer From nobody Thu May 21 21:54: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 E830F1A9103; Thu, 21 May 2015 21:54:10 -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 wx13Fjf8lqpv; Thu, 21 May 2015 21:54:09 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 B6FBF1A9108; Thu, 21 May 2015 21:54:08 -0700 (PDT) Received: by wibt6 with SMTP id t6so34767794wib.0; Thu, 21 May 2015 21:54:07 -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=M9GK6veDWhblg37p5x5ia9EXwaC8Vcut1j/SL0joveM=; b=lLMgXzIhsUS6SU0CC6Xu5oLE48cFFQcepRElF3nK1Zn0DzWTFeTAj8t5UCeTgxk9TO 675JEzuCgUoy8CPByYqcrL5e6IJ5h8CTP4JjuBvRJB0QR3oXPJ0H7EduyW5gGrkWeuqL ewRoJhhOhQsL9HqG3qLJPirUtQ4Y3grsPYberT1FWz8uwWc1WH+PAWJ85Z9+ug9L4IU3 ETussXTZ15eKzDFHtJeYRYIe7gXdn/Gt55NsK7aMcMx55NeP6B9dwCgO0Ag12rcGKAfz NGeT2HlagtVCCnkclPzSSz1oE0L7ouPH7mBKk/lm8bmPc6CZ2qcuzxhwSCUctpYp8npq 5Zmw== X-Received: by 10.180.96.196 with SMTP id du4mr3614917wib.77.1432270447465; Thu, 21 May 2015 21:54:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Thu, 21 May 2015 21:53:47 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D82B0F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D82B0F3@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Thu, 21 May 2015 21:53:47 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043bdabc3e5c740516a473a1 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: Fri, 22 May 2015 04:54:11 -0000 --f46d043bdabc3e5c740516a473a1 Content-Type: text/plain; charset=UTF-8 Christer said: "A while ago, we agreed that consent does not need to be maintained on candidate pairs that aren't currently used." [BA] If the specification were to say that consent is required once media is sent, then this would logically follow. That should not be seen as lost consent (i.e. if the UA wants to start sending data on the candidate pair it should not have to do ICE restart or create a new session). [BA] I agree. As long as it can obtain consent on the new pair (without having to update the ufrag/pwd), it should be fine. So, consent is lost if the UA sends consent requests, and does not receive a response. [BA] Consent is lost for that candidate pair, and that pair alone. If connectivity checks are being done on an unused candidate pair (as advocated in Justin's nombis draft), the consent mechanism does not apply until media is sent on that pair. So you can't revoke consent on a candidate pair if media isn't being sent on the pair. Perhaps that is clear in the draft, but if people have a different understanding it may need to be clarified :) [BA] I agree with your perspective, but I do think it could be made more clear in the document. On Thu, May 21, 2015 at 8:55 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > ... > > >> 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? > > > >... is needed to obtain consent to send *on that candidate pair*. > > > >There was a long discussion about this point, the conclusion of which was > "use it or lose it". This captures that >conclusion. I can't remember the > details of the discussion, but I think that it wasn't a security concern > but a >robustness one. > > A while ago, we agreed that consent does not need to be maintained on > candidate pairs that aren't currently used. That should not be seen as lost > consent (i.e. if the UA wants to start sending data on the candidate pair > it should not have to do ICE restart or create a new session). > > So, consent is lost if the UA sends consent requests, and does not receive > a response. Consent is NOT lost if the UA stops sending consent requests > (and therefor obviously will not receive a response). > > Perhaps that is clear in the draft, but if people have a different > understanding it may need to be clarified :) > > Regards, > > Christer > --f46d043bdabc3e5c740516a473a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0

"A while ago, we agreed that consent does = not need to be maintained on candidate pairs that aren't currently used= ."

<= /span>
[BA] If the s= pecification were to say that consent is required once media is sent, then = this would logically follow.=C2=A0

That should not be seen as lost consent (i.e. if the UA wants= to start sending data on the candidate pair it should not have to do ICE r= estart or create a=C2=A0 new session).

[BA] I agree. As long as it can obtain consent on the new= pair (without having to update the ufrag/pwd), it should be fine.=C2=A0

So, consent is lost if the UA sends consent requests= , and does not receive a response.=C2=A0

[BA] Consent is lost for that candidate pair, and that pair a= lone.=C2=A0 If connectivity checks are being done on an unused candidate pa= ir (as advocated in Justin's nombis draft), the consent mechanism does = not apply until media is sent on that pair.=C2=A0 So you can't revoke c= onsent on a candidate pair if media isn't being sent on the pair.=C2=A0=

Perhaps that is clear in the draft, but if p= eople have a different understanding it may need to be clarified :)<= br style=3D"font-size:12.8000001907349px">
[BA] I agree with yo= ur perspective, but I do think it could be made more clear in the document.= =C2=A0

On Thu, May 21, 2015 at 8:55 PM, Christer Holmberg <= christer.holmberg@ericsson.com> wrote:
Hi,

...

>> After consent is lost for any reason, the same ICE credentials MUS= T
>> 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<= br> >> 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 res= tart
>> if another operational candidate pair exists?
>
>... is needed to obtain consent to send *on that candidate pair*.
>
>There was a long discussion about this point, the conclusion of which w= as "use it or lose it".=C2=A0 This captures that >conclusion.= =C2=A0 I can't remember the details of the discussion, but I think that= it wasn't a security concern but a >robustness one.

A while ago, we agreed that consent does not need to be maintained o= n candidate pairs that aren't currently used. That should not be seen a= s lost consent (i.e. if the UA wants to start sending data on the candidate= pair it should not have to do ICE restart or create a=C2=A0 new session).<= br>
So, consent is lost if the UA sends consent requests, and does not receive = a response. Consent is NOT lost if the UA stops sending consent requests (a= nd therefor obviously will not receive a response).

Perhaps that is clear in the draft, but if people have a different understa= nding it may need to be clarified :)

Regards,

Christer

--f46d043bdabc3e5c740516a473a1-- From nobody Thu May 21 22:49: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 88E151A913F; Thu, 21 May 2015 22:49:02 -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 QsLrjI61Isbp; Thu, 21 May 2015 22:49:00 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42CF1A9136; Thu, 21 May 2015 22:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18568; q=dns/txt; s=iport; t=1432273740; x=1433483340; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vJ4mNYW+SbfCr8QlrKSDXUjlj9OI3RweYgB/XtgXx3E=; b=YQsDhG05fYTQEbOo7nNbfl54B16NiHB8+5qQkMAjisYIYIRu9NinOVjb NAenI4nRNynTHGzOEKZK4JukmNplyUa7GMLKkoUas0WyPI9y/sd/2Tg99 +mpAtJkMc9lgtSUDYjrjKy6Da3Uvg2JsfH1+f2mSFjNQmk35ELbLCUfTD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIBQBQwl5V/49dJa1cgkVLVF4Ggxm/EzwqCYFZhXcCHIEfOBQBAQEBAQEBgQqEIgEBAQMBIwpMEAIBCBEEAQELHQMCAgIwFAkIAgQBDQUIiBwIDa5IpBkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqEVBYbBgGCaC+BFgWSfYQ1h38+jWKEBINZI4IKHIFSb4EDIiGBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,474,1427760000"; d="scan'208,217";a="152470647" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 22 May 2015 05:48:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t4M5mwTD027377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 May 2015 05:48:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 22 May 2015 00:48:57 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Bernard Aboba , Christer Holmberg Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHQk1eS1ZbgKeHyC0Cjwx+443SghJ2HY76AgABPkgCAABBlgP//u2LQ Date: Fri, 22 May 2015 05:48:57 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A4785A0D5@xmb-rcd-x10.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D82B0F3@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.37.83] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A4785A0D5xmbrcdx10ciscoc_" MIME-Version: 1.0 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: Fri, 22 May 2015 05:49:02 -0000 --_000_913383AAA69FF945B8F946018B75898A4785A0D5xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNCBvZiB0aGUgZHJhZnQNCjxzbmlwPg0KICAgQW4g ZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5v dCBuZWVkIHRvDQogICBtYWludGFpbiBjb25zZW50LiAgSG93ZXZlciwgbm90IHNlbmRpbmcgYW55 IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUDQogICBvciBmaXJld2FsbCBtYXBwaW5ncyB0byBleHBp cmUuICBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJsZQ0KICAgdG8gc2VuZCBpcyBk ZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy4gIEFic2VudCBiZXR0ZXIgaW5mb3JtYXRpb24N CiAgIGFib3V0IHRoZSBuZXR3b3JrLCBpZiBhbiBlbmRwb2ludCBuZWVkcyB0byBlbnN1cmUgaXRz IE5BVCBvciBmaXJld2FsbA0KICAgbWFwcGluZ3MgZG8gbm90IGV4cGlyZSwgaXQgY2FuIGJlIGRv bmUgdXNpbmcga2VlcGFsaXZlIG9yIG90aGVyDQogICB0ZWNobmlxdWVzIChzZWUgU2VjdGlvbiAx MCBvZiBbUkZDNTI0NV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9u LTEwPiBhbmQgc2VlIFtSRkM2MjYzPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNjM+ XSkuDQo8L3NuaXA+DQoNCi1UaXJ1DQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmVybmFyZCBBYm9iYQ0KU2VudDogRnJpZGF5LCBN YXkgMjIsIDIwMTUgMTA6MjQgQU0NClRvOiBDaHJpc3RlciBIb2xtYmVyZw0KQ2M6IHJ0Y3dlYkBp ZXRmLm9yZzsgVGhlIElFU0cNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBSZXZpZXcgb2YgZHJhZnQt aWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcw0KDQpDaHJpc3RlciBzYWlkOg0KDQoi QSB3aGlsZSBhZ28sIHdlIGFncmVlZCB0aGF0IGNvbnNlbnQgZG9lcyBub3QgbmVlZCB0byBiZSBt YWludGFpbmVkIG9uIGNhbmRpZGF0ZSBwYWlycyB0aGF0IGFyZW4ndCBjdXJyZW50bHkgdXNlZC4i DQoNCltCQV0gSWYgdGhlIHNwZWNpZmljYXRpb24gd2VyZSB0byBzYXkgdGhhdCBjb25zZW50IGlz IHJlcXVpcmVkIG9uY2UgbWVkaWEgaXMgc2VudCwgdGhlbiB0aGlzIHdvdWxkIGxvZ2ljYWxseSBm b2xsb3cuDQoNClRoYXQgc2hvdWxkIG5vdCBiZSBzZWVuIGFzIGxvc3QgY29uc2VudCAoaS5lLiBp ZiB0aGUgVUEgd2FudHMgdG8gc3RhcnQgc2VuZGluZyBkYXRhIG9uIHRoZSBjYW5kaWRhdGUgcGFp ciBpdCBzaG91bGQgbm90IGhhdmUgdG8gZG8gSUNFIHJlc3RhcnQgb3IgY3JlYXRlIGEgIG5ldyBz ZXNzaW9uKS4NCg0KW0JBXSBJIGFncmVlLiBBcyBsb25nIGFzIGl0IGNhbiBvYnRhaW4gY29uc2Vu dCBvbiB0aGUgbmV3IHBhaXIgKHdpdGhvdXQgaGF2aW5nIHRvIHVwZGF0ZSB0aGUgdWZyYWcvcHdk KSwgaXQgc2hvdWxkIGJlIGZpbmUuDQoNClNvLCBjb25zZW50IGlzIGxvc3QgaWYgdGhlIFVBIHNl bmRzIGNvbnNlbnQgcmVxdWVzdHMsIGFuZCBkb2VzIG5vdCByZWNlaXZlIGEgcmVzcG9uc2UuDQoN CltCQV0gQ29uc2VudCBpcyBsb3N0IGZvciB0aGF0IGNhbmRpZGF0ZSBwYWlyLCBhbmQgdGhhdCBw YWlyIGFsb25lLiAgSWYgY29ubmVjdGl2aXR5IGNoZWNrcyBhcmUgYmVpbmcgZG9uZSBvbiBhbiB1 bnVzZWQgY2FuZGlkYXRlIHBhaXIgKGFzIGFkdm9jYXRlZCBpbiBKdXN0aW4ncyBub21iaXMgZHJh ZnQpLCB0aGUgY29uc2VudCBtZWNoYW5pc20gZG9lcyBub3QgYXBwbHkgdW50aWwgbWVkaWEgaXMg c2VudCBvbiB0aGF0IHBhaXIuICBTbyB5b3UgY2FuJ3QgcmV2b2tlIGNvbnNlbnQgb24gYSBjYW5k aWRhdGUgcGFpciBpZiBtZWRpYSBpc24ndCBiZWluZyBzZW50IG9uIHRoZSBwYWlyLg0KDQpQZXJo YXBzIHRoYXQgaXMgY2xlYXIgaW4gdGhlIGRyYWZ0LCBidXQgaWYgcGVvcGxlIGhhdmUgYSBkaWZm ZXJlbnQgdW5kZXJzdGFuZGluZyBpdCBtYXkgbmVlZCB0byBiZSBjbGFyaWZpZWQgOikNCg0KW0JB XSBJIGFncmVlIHdpdGggeW91ciBwZXJzcGVjdGl2ZSwgYnV0IEkgZG8gdGhpbmsgaXQgY291bGQg YmUgbWFkZSBtb3JlIGNsZWFyIGluIHRoZSBkb2N1bWVudC4NCg0KT24gVGh1LCBNYXkgMjEsIDIw MTUgYXQgODo1NSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpI aSwNCg0KLi4uDQoNCj4+IEFmdGVyIGNvbnNlbnQgaXMgbG9zdCBmb3IgYW55IHJlYXNvbiwgdGhl IHNhbWUgSUNFIGNyZWRlbnRpYWxzIE1VU1QNCj4+IE5PVCBiZSB1c2VkIG9uIHRoZSBhZmZlY3Rl ZCA1LXR1cGxlIGFnYWluLiBUaGF0IG1lYW5zIHRoYXQgYSBuZXcNCj4+IHNlc3Npb24sIG9yIGFu IElDRSByZXN0YXJ0LCBpcyBuZWVkZWQgdG8gb2J0YWluIGNvbnNlbnQgdG8gc2VuZC4NCj4+DQo+ PiBbQkFdIFRoZSBzZWNvbmQgc2VudGVuY2UgZG9lcyBub3QgZm9sbG93IGZyb20gdGhlIGZpcnN0 LiBSRkMgNTI0NQ0KPj4gZW5hYmxlcyBzZW5kaW5nIG9mIG1lZGlhIG9uY2UgYSBzdWNjZXNzZnVs IElDRSBjb25uZWN0aXZpdHkgY2hlY2sgaGFzIGJlZW4gcmVjZWl2ZWQuDQo+PiBJZiBtdWx0aXBs ZSBzdWNjZXNzZnVsIGNhbmRpZGF0ZSBwYWlycyBoYXZlIGJlZW4gaWRlbnRpZmllZCwgd2h5DQo+ PiBzaG91bGQgZmFpbHVyZSBvZiBjb25zZW50IG9uIG9uZSBjYW5kaWRhdGUgcGFpciByZXF1aXJl IGFuIElDRSByZXN0YXJ0DQo+PiBpZiBhbm90aGVyIG9wZXJhdGlvbmFsIGNhbmRpZGF0ZSBwYWly IGV4aXN0cz8NCj4NCj4uLi4gaXMgbmVlZGVkIHRvIG9idGFpbiBjb25zZW50IHRvIHNlbmQgKm9u IHRoYXQgY2FuZGlkYXRlIHBhaXIqLg0KPg0KPlRoZXJlIHdhcyBhIGxvbmcgZGlzY3Vzc2lvbiBh Ym91dCB0aGlzIHBvaW50LCB0aGUgY29uY2x1c2lvbiBvZiB3aGljaCB3YXMgInVzZSBpdCBvciBs b3NlIGl0Ii4gIFRoaXMgY2FwdHVyZXMgdGhhdCA+Y29uY2x1c2lvbi4gIEkgY2FuJ3QgcmVtZW1i ZXIgdGhlIGRldGFpbHMgb2YgdGhlIGRpc2N1c3Npb24sIGJ1dCBJIHRoaW5rIHRoYXQgaXQgd2Fz bid0IGEgc2VjdXJpdHkgY29uY2VybiBidXQgYSA+cm9idXN0bmVzcyBvbmUuDQoNCkEgd2hpbGUg YWdvLCB3ZSBhZ3JlZWQgdGhhdCBjb25zZW50IGRvZXMgbm90IG5lZWQgdG8gYmUgbWFpbnRhaW5l ZCBvbiBjYW5kaWRhdGUgcGFpcnMgdGhhdCBhcmVuJ3QgY3VycmVudGx5IHVzZWQuIFRoYXQgc2hv dWxkIG5vdCBiZSBzZWVuIGFzIGxvc3QgY29uc2VudCAoaS5lLiBpZiB0aGUgVUEgd2FudHMgdG8g c3RhcnQgc2VuZGluZyBkYXRhIG9uIHRoZSBjYW5kaWRhdGUgcGFpciBpdCBzaG91bGQgbm90IGhh dmUgdG8gZG8gSUNFIHJlc3RhcnQgb3IgY3JlYXRlIGEgIG5ldyBzZXNzaW9uKS4NCg0KU28sIGNv bnNlbnQgaXMgbG9zdCBpZiB0aGUgVUEgc2VuZHMgY29uc2VudCByZXF1ZXN0cywgYW5kIGRvZXMg bm90IHJlY2VpdmUgYSByZXNwb25zZS4gQ29uc2VudCBpcyBOT1QgbG9zdCBpZiB0aGUgVUEgc3Rv cHMgc2VuZGluZyBjb25zZW50IHJlcXVlc3RzIChhbmQgdGhlcmVmb3Igb2J2aW91c2x5IHdpbGwg bm90IHJlY2VpdmUgYSByZXNwb25zZSkuDQoNClBlcmhhcHMgdGhhdCBpcyBjbGVhciBpbiB0aGUg ZHJhZnQsIGJ1dCBpZiBwZW9wbGUgaGF2ZSBhIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5nIGl0IG1h eSBuZWVkIHRvIGJlIGNsYXJpZmllZCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= --_000_913383AAA69FF945B8F946018B75898A4785A0D5xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNCBv ZiB0aGUgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O3NuaXAmZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBk YXRhIGRvZXMgbm90IG5lZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1haW50YWluIGNvbnNlbnQuJm5ic3A7IEhv d2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg b3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiZuYnNwOyBGdXJ0aGVybW9yZSwgaGF2aW5n IG9uZSBwZWVyIHVuYWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdG8gc2VuZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55 IHByb3RvY29scy4mbmJzcDsgQWJzZW50IGJldHRlciBpbmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYWJv dXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9y IGZpcmV3YWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9u ZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRlY2huaXF1ZXMgKHNlZQ0KPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTEwIj5TZWN0 aW9uJm5ic3A7MTAgb2YgW1JGQzUyNDVdPC9hPiBhbmQgc2VlIFs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjYzIiB0aXRsZT0iJnF1b3Q7QXBwbGljYXRpb24gTWVjaGFu aXNtIGZvciBLZWVwaW5nIEFsaXZlIHRoZSBOQVQgTWFwcGluZ3MgQXNzb2NpYXRlZCB3aXRoIFJU UCAvIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBGbG93cyZxdW90OyI+UkZDNjI2MzwvYT5d KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9zbmlwJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2Vi IFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJl cm5hcmQgQWJvYmE8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMjIsIDIwMTUgMTA6MjQg QU08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBydGN3 ZWJAaWV0Zi5vcmc7IFRoZSBJRVNHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBS ZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaHJpc3RlciBz YWlkOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ JnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+QSB3aGlsZSBhZ28sIHdlIGFncmVl ZCB0aGF0IGNvbnNlbnQgZG9lcyBub3QgbmVlZCB0byBiZSBtYWludGFpbmVkIG9uIGNhbmRpZGF0 ZSBwYWlycyB0aGF0IGFyZW4ndCBjdXJyZW50bHkgdXNlZC4mcXVvdDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPltCQV0gSWYgdGhlIHNwZWNpZmljYXRpb24gd2VyZSB0byBzYXkg dGhhdCBjb25zZW50IGlzIHJlcXVpcmVkIG9uY2UgbWVkaWEgaXMgc2VudCwgdGhlbiB0aGlzIHdv dWxkIGxvZ2ljYWxseSBmb2xsb3cuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0Ij5UaGF0IHNob3VsZCBub3QgYmUgc2VlbiBhcyBsb3N0IGNvbnNlbnQgKGkuZS4gaWYgdGhl IFVBIHdhbnRzIHRvIHN0YXJ0IHNlbmRpbmcgZGF0YSBvbiB0aGUgY2FuZGlkYXRlIHBhaXIgaXQg c2hvdWxkIG5vdCBoYXZlIHRvIGRvIElDRSByZXN0YXJ0IG9yIGNyZWF0ZSBhJm5ic3A7IG5ldyBz ZXNzaW9uKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPltCQV0gSSBhZ3JlZS4g QXMgbG9uZyBhcyBpdCBjYW4gb2J0YWluIGNvbnNlbnQgb24gdGhlIG5ldyBwYWlyICh3aXRob3V0 IGhhdmluZyB0byB1cGRhdGUgdGhlIHVmcmFnL3B3ZCksIGl0IHNob3VsZCBiZSBmaW5lLiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PGJyPg0KU28sIGNvbnNlbnQgaXMgbG9zdCBpZiB0 aGUgVUEgc2VuZHMgY29uc2VudCByZXF1ZXN0cywgYW5kIGRvZXMgbm90IHJlY2VpdmUgYSByZXNw b25zZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5bQkFdIENvbnNlbnQgaXMgbG9z dCBmb3IgdGhhdCBjYW5kaWRhdGUgcGFpciwgYW5kIHRoYXQgcGFpciBhbG9uZS4mbmJzcDsgSWYg Y29ubmVjdGl2aXR5IGNoZWNrcyBhcmUgYmVpbmcgZG9uZSBvbiBhbiB1bnVzZWQgY2FuZGlkYXRl IHBhaXIgKGFzIGFkdm9jYXRlZCBpbiBKdXN0aW4ncyBub21iaXMgZHJhZnQpLCB0aGUgY29uc2Vu dCBtZWNoYW5pc20gZG9lcyBub3QNCiBhcHBseSB1bnRpbCBtZWRpYSBpcyBzZW50IG9uIHRoYXQg cGFpci4mbmJzcDsgU28geW91IGNhbid0IHJldm9rZSBjb25zZW50IG9uIGEgY2FuZGlkYXRlIHBh aXIgaWYgbWVkaWEgaXNuJ3QgYmVpbmcgc2VudCBvbiB0aGUgcGFpci4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij48YnI+DQpQZXJoYXBzIHRoYXQgaXMgY2xlYXIgaW4gdGhl IGRyYWZ0LCBidXQgaWYgcGVvcGxlIGhhdmUgYSBkaWZmZXJlbnQgdW5kZXJzdGFuZGluZyBpdCBt YXkgbmVlZCB0byBiZSBjbGFyaWZpZWQgOik8YnI+DQo8YnI+DQpbQkFdIEkgYWdyZWUgd2l0aCB5 b3VyIHBlcnNwZWN0aXZlLCBidXQgSSBkbyB0aGluayBpdCBjb3VsZCBiZSBtYWRlIG1vcmUgY2xl YXIgaW4gdGhlIGRvY3VtZW50LiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWF5IDIxLCAyMDE1IGF0IDg6 NTUgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSw8YnI+DQo8YnI+DQouLi48YnI+DQo8YnI+DQomZ3Q7Jmd0OyBBZnRlciBjb25zZW50 IGlzIGxvc3QgZm9yIGFueSByZWFzb24sIHRoZSBzYW1lIElDRSBjcmVkZW50aWFscyBNVVNUPGJy Pg0KJmd0OyZndDsgTk9UIGJlIHVzZWQgb24gdGhlIGFmZmVjdGVkIDUtdHVwbGUgYWdhaW4uIFRo YXQgbWVhbnMgdGhhdCBhIG5ldzxicj4NCiZndDsmZ3Q7IHNlc3Npb24sIG9yIGFuIElDRSByZXN0 YXJ0LCBpcyBuZWVkZWQgdG8gb2J0YWluIGNvbnNlbnQgdG8gc2VuZC48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFtCQV0gVGhlIHNlY29uZCBzZW50ZW5jZSBkb2VzIG5vdCBmb2xsb3cgZnJv bSB0aGUgZmlyc3QuIFJGQyA1MjQ1PGJyPg0KJmd0OyZndDsgZW5hYmxlcyBzZW5kaW5nIG9mIG1l ZGlhIG9uY2UgYSBzdWNjZXNzZnVsIElDRSBjb25uZWN0aXZpdHkgY2hlY2sgaGFzIGJlZW4gcmVj ZWl2ZWQuPGJyPg0KJmd0OyZndDsgSWYgbXVsdGlwbGUgc3VjY2Vzc2Z1bCBjYW5kaWRhdGUgcGFp cnMgaGF2ZSBiZWVuIGlkZW50aWZpZWQsIHdoeTxicj4NCiZndDsmZ3Q7IHNob3VsZCBmYWlsdXJl IG9mIGNvbnNlbnQgb24gb25lIGNhbmRpZGF0ZSBwYWlyIHJlcXVpcmUgYW4gSUNFIHJlc3RhcnQ8 YnI+DQomZ3Q7Jmd0OyBpZiBhbm90aGVyIG9wZXJhdGlvbmFsIGNhbmRpZGF0ZSBwYWlyIGV4aXN0 cz88YnI+DQomZ3Q7PGJyPg0KJmd0Oy4uLiBpcyBuZWVkZWQgdG8gb2J0YWluIGNvbnNlbnQgdG8g c2VuZCAqb24gdGhhdCBjYW5kaWRhdGUgcGFpciouPGJyPg0KJmd0Ozxicj4NCiZndDtUaGVyZSB3 YXMgYSBsb25nIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBwb2ludCwgdGhlIGNvbmNsdXNpb24gb2Yg d2hpY2ggd2FzICZxdW90O3VzZSBpdCBvciBsb3NlIGl0JnF1b3Q7LiZuYnNwOyBUaGlzIGNhcHR1 cmVzIHRoYXQgJmd0O2NvbmNsdXNpb24uJm5ic3A7IEkgY2FuJ3QgcmVtZW1iZXIgdGhlIGRldGFp bHMgb2YgdGhlIGRpc2N1c3Npb24sIGJ1dCBJIHRoaW5rIHRoYXQgaXQgd2Fzbid0IGEgc2VjdXJp dHkgY29uY2VybiBidXQgYSAmZ3Q7cm9idXN0bmVzcyBvbmUuPGJyPg0KPGJyPg0KQSB3aGlsZSBh Z28sIHdlIGFncmVlZCB0aGF0IGNvbnNlbnQgZG9lcyBub3QgbmVlZCB0byBiZSBtYWludGFpbmVk IG9uIGNhbmRpZGF0ZSBwYWlycyB0aGF0IGFyZW4ndCBjdXJyZW50bHkgdXNlZC4gVGhhdCBzaG91 bGQgbm90IGJlIHNlZW4gYXMgbG9zdCBjb25zZW50IChpLmUuIGlmIHRoZSBVQSB3YW50cyB0byBz dGFydCBzZW5kaW5nIGRhdGEgb24gdGhlIGNhbmRpZGF0ZSBwYWlyIGl0IHNob3VsZCBub3QgaGF2 ZSB0byBkbyBJQ0UgcmVzdGFydA0KIG9yIGNyZWF0ZSBhJm5ic3A7IG5ldyBzZXNzaW9uKS48YnI+ DQo8YnI+DQpTbywgY29uc2VudCBpcyBsb3N0IGlmIHRoZSBVQSBzZW5kcyBjb25zZW50IHJlcXVl c3RzLCBhbmQgZG9lcyBub3QgcmVjZWl2ZSBhIHJlc3BvbnNlLiBDb25zZW50IGlzIE5PVCBsb3N0 IGlmIHRoZSBVQSBzdG9wcyBzZW5kaW5nIGNvbnNlbnQgcmVxdWVzdHMgKGFuZCB0aGVyZWZvciBv YnZpb3VzbHkgd2lsbCBub3QgcmVjZWl2ZSBhIHJlc3BvbnNlKS48YnI+DQo8YnI+DQpQZXJoYXBz IHRoYXQgaXMgY2xlYXIgaW4gdGhlIGRyYWZ0LCBidXQgaWYgcGVvcGxlIGhhdmUgYSBkaWZmZXJl bnQgdW5kZXJzdGFuZGluZyBpdCBtYXkgbmVlZCB0byBiZSBjbGFyaWZpZWQgOik8YnI+DQo8YnI+ DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A4785A0D5xmbrcdx10ciscoc_-- From nobody Fri May 22 01:47:27 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 786361B29E6; Fri, 22 May 2015 01:47:23 -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 fj1FNYYMTpOz; Fri, 22 May 2015 01:47:21 -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 3B7911B29E1; Fri, 22 May 2015 01:47:19 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-69-555eed1521e6 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F6.77.04401.51DEE555; Fri, 22 May 2015 10:47:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Fri, 22 May 2015 10:47:17 +0200 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHQk1ePQtH0SmDHm02NITW7o6QoRZ2G7maAgABv25D///AbgIAAYOrA Date: Fri, 22 May 2015 08:47:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D82B694@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D82B0F3@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D82B694ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3VlfsbVyowbVTLBYb9v1ntpjxZyKz xbUz/xgt1v5rZ3dg8dg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mt6sespecKqHsWLhv+fs DYwvOhi7GDk5JARMJP4vmA9li0lcuLeeDcQWEjjKKPH3R0wXIxeQvZhR4t+MK6xdjBwcbAIW Et3/tEFqRAS0Jfq+7WMCsZkF8iRmnmwF6xUW8JCYcvsSM0SNp8T7bTdYIWw3ieWzr7GBjGER UJX4dSATJMwr4CvxYe8mZohVi5gkpsyYDVbPKRAo0XruPNgcRqDbvp9aA7VLXOLWk/lMEDcL SCzZA1EjISAq8fLxP1YIW0li0e3PUPX5Eg2n2lkhlglKnJz5hGUCo+gsJKNmISmbhaRsFtCp zAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmAMHtzyW3UH4+U3jocYBTgYlXh4HxyNCxViTSwrrsw9xCjNwaIkzuvZFRIqJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgTH6mffH2S3HK7/M2mvAdDsjwvrr0hl2diyz5k65/1DWVnbD+YsV RTP0th8L7HT77Xvlx575i22FQnef4P5UV/+++HOdSHo2t/GETyc6vY5k71wqtP8yy/HHi7wm xbP0pr0OrUkXb4z3/neL8++GY1NF6wWWZUtvTV99WfZSZvWBRH4F27LfoYJKLMUZiYZazEXF iQAxyIngogIAAA== 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: Fri, 22 May 2015 08:47:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D82B694ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4+IkEgd2hpbGUgYWdvLCB3ZSBhZ3JlZWQgdGhhdCBjb25zZW50IGRvZXMgbm90IG5l ZWQgdG8gYmUgbWFpbnRhaW5lZCBvbiBjYW5kaWRhdGUgcGFpcnMgdGhhdCBhcmVuJ3QgY3VycmVu dGx5IHVzZWQuIg0KPg0KPltCQV0gSWYgdGhlIHNwZWNpZmljYXRpb24gd2VyZSB0byBzYXkgdGhh dCBjb25zZW50IGlzIHJlcXVpcmVkIG9uY2UgbWVkaWEgaXMgc2VudCwgdGhlbiB0aGlzIHdvdWxk IGxvZ2ljYWxseSBmb2xsb3cuDQoNCk9yLCBXSElMRSBtZWRpYSBpcyBzZW50IDopIEJlY2F1c2Us IGlmIHlvdSBzdG9wIHNlbmRpbmcgbWVkaWEgb24gYSBwYWlyIChlLmcuIGJlY2F1c2UgeW91IHN3 aXRjaCB0byBhbm90aGVyIHBhaXIpLCB5b3UgY2FuIGFsc28gc3RvcCBkb2luZyBjb25zZW50LCBi dXQgdGhhdCBkb2VzbuKAmXQgbWVhbiBjb25zZW50IHdpbGwgYmUgbG9zdC4NCg0KPj5UaGF0IHNo b3VsZCBub3QgYmUgc2VlbiBhcyBsb3N0IGNvbnNlbnQgKGkuZS4gaWYgdGhlIFVBIHdhbnRzIHRv IHN0YXJ0IHNlbmRpbmcgZGF0YSBvbiB0aGUgY2FuZGlkYXRlIHBhaXIgaXQgc2hvdWxkIG5vdCBo YXZlIHRvIGRvIElDRSA+PnJlc3RhcnQgb3IgY3JlYXRlIGEgIG5ldyBzZXNzaW9uKS4NCj4NCj5b QkFdIEkgYWdyZWUuIEFzIGxvbmcgYXMgaXQgY2FuIG9idGFpbiBjb25zZW50IG9uIHRoZSBuZXcg cGFpciAod2l0aG91dCBoYXZpbmcgdG8gdXBkYXRlIHRoZSB1ZnJhZy9wd2QpLCBpdCBzaG91bGQg YmUgZmluZS4NCg0KSXQgY291bGQgZXZlbiBiZSBhbiBvbGQgcGFpciwgb24gd2hpY2ggdGhlIFVB IHByZXZpb3VzbHkgc2VudCBtZWRpYSwgYnV0IHRoZW4gc3dpdGNoZWQgdG8gYW5vdGhlciBwYWly IChmb3Igd2hhdGV2ZXIgcmVhc29uKS4NCg0KPj5TbywgY29uc2VudCBpcyBsb3N0IGlmIHRoZSBV QSBzZW5kcyBjb25zZW50IHJlcXVlc3RzLCBhbmQgZG9lcyBub3QgcmVjZWl2ZSBhIHJlc3BvbnNl Lg0KPg0KPltCQV0gQ29uc2VudCBpcyBsb3N0IGZvciB0aGF0IGNhbmRpZGF0ZSBwYWlyLCBhbmQg dGhhdCBwYWlyIGFsb25lLg0KDQpDb3JyZWN0Lg0KDQo+SWYgY29ubmVjdGl2aXR5IGNoZWNrcyBh cmUgYmVpbmcgZG9uZSBvbiBhbiB1bnVzZWQgY2FuZGlkYXRlIHBhaXIgKGFzIGFkdm9jYXRlZCBp biBKdXN0aW4ncyBub21iaXMgZHJhZnQpLCB0aGUNCj5jb25zZW50IG1lY2hhbmlzbSBkb2VzIG5v dCBhcHBseSB1bnRpbCBtZWRpYSBpcyBzZW50IG9uIHRoYXQgcGFpci4gIFNvIHlvdSBjYW4ndCBy ZXZva2UgY29uc2VudCBvbiBhIGNhbmRpZGF0ZQ0KPnBhaXIgaWYgbWVkaWEgaXNuJ3QgYmVpbmcg c2VudCBvbiB0aGUgcGFpci4NCg0KQ29ycmVjdC4NCg0KT2YgY291cnNlLCBpZiB5b3Ugd2FudCB0 byBtYWludGFpbiB0aGUgcGFpciwgeW91IHN0aWxsIGhhdmUgdG8gc2VuZCBrZWVwLWFsaXZlcywg YnV0IHRoYXTigJlzIGEgc2VwYXJhdGUgc3RvcnkgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KDQoNCk9uIFRodSwgTWF5IDIxLCAyMDE1IGF0IDg6NTUgUE0sIENocmlzdGVyIEhvbG1iZXJn IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCi4uLg0KDQo+PiBBZnRlciBjb25zZW50IGlz IGxvc3QgZm9yIGFueSByZWFzb24sIHRoZSBzYW1lIElDRSBjcmVkZW50aWFscyBNVVNUDQo+PiBO T1QgYmUgdXNlZCBvbiB0aGUgYWZmZWN0ZWQgNS10dXBsZSBhZ2Fpbi4gVGhhdCBtZWFucyB0aGF0 IGEgbmV3DQo+PiBzZXNzaW9uLCBvciBhbiBJQ0UgcmVzdGFydCwgaXMgbmVlZGVkIHRvIG9idGFp biBjb25zZW50IHRvIHNlbmQuDQo+Pg0KPj4gW0JBXSBUaGUgc2Vjb25kIHNlbnRlbmNlIGRvZXMg bm90IGZvbGxvdyBmcm9tIHRoZSBmaXJzdC4gUkZDIDUyNDUNCj4+IGVuYWJsZXMgc2VuZGluZyBv ZiBtZWRpYSBvbmNlIGEgc3VjY2Vzc2Z1bCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrIGhhcyBiZWVu IHJlY2VpdmVkLg0KPj4gSWYgbXVsdGlwbGUgc3VjY2Vzc2Z1bCBjYW5kaWRhdGUgcGFpcnMgaGF2 ZSBiZWVuIGlkZW50aWZpZWQsIHdoeQ0KPj4gc2hvdWxkIGZhaWx1cmUgb2YgY29uc2VudCBvbiBv bmUgY2FuZGlkYXRlIHBhaXIgcmVxdWlyZSBhbiBJQ0UgcmVzdGFydA0KPj4gaWYgYW5vdGhlciBv cGVyYXRpb25hbCBjYW5kaWRhdGUgcGFpciBleGlzdHM/DQo+DQo+Li4uIGlzIG5lZWRlZCB0byBv YnRhaW4gY29uc2VudCB0byBzZW5kICpvbiB0aGF0IGNhbmRpZGF0ZSBwYWlyKi4NCj4NCj5UaGVy ZSB3YXMgYSBsb25nIGRpc2N1c3Npb24gYWJvdXQgdGhpcyBwb2ludCwgdGhlIGNvbmNsdXNpb24g b2Ygd2hpY2ggd2FzICJ1c2UgaXQgb3IgbG9zZSBpdCIuICBUaGlzIGNhcHR1cmVzIHRoYXQgPmNv bmNsdXNpb24uICBJIGNhbid0IHJlbWVtYmVyIHRoZSBkZXRhaWxzIG9mIHRoZSBkaXNjdXNzaW9u LCBidXQgSSB0aGluayB0aGF0IGl0IHdhc24ndCBhIHNlY3VyaXR5IGNvbmNlcm4gYnV0IGEgPnJv YnVzdG5lc3Mgb25lLg0KDQpBIHdoaWxlIGFnbywgd2UgYWdyZWVkIHRoYXQgY29uc2VudCBkb2Vz IG5vdCBuZWVkIHRvIGJlIG1haW50YWluZWQgb24gY2FuZGlkYXRlIHBhaXJzIHRoYXQgYXJlbid0 IGN1cnJlbnRseSB1c2VkLiBUaGF0IHNob3VsZCBub3QgYmUgc2VlbiBhcyBsb3N0IGNvbnNlbnQg KGkuZS4gaWYgdGhlIFVBIHdhbnRzIHRvIHN0YXJ0IHNlbmRpbmcgZGF0YSBvbiB0aGUgY2FuZGlk YXRlIHBhaXIgaXQgc2hvdWxkIG5vdCBoYXZlIHRvIGRvIElDRSByZXN0YXJ0IG9yIGNyZWF0ZSBh ICBuZXcgc2Vzc2lvbikuDQoNClNvLCBjb25zZW50IGlzIGxvc3QgaWYgdGhlIFVBIHNlbmRzIGNv bnNlbnQgcmVxdWVzdHMsIGFuZCBkb2VzIG5vdCByZWNlaXZlIGEgcmVzcG9uc2UuIENvbnNlbnQg aXMgTk9UIGxvc3QgaWYgdGhlIFVBIHN0b3BzIHNlbmRpbmcgY29uc2VudCByZXF1ZXN0cyAoYW5k IHRoZXJlZm9yIG9idmlvdXNseSB3aWxsIG5vdCByZWNlaXZlIGEgcmVzcG9uc2UpLg0KDQpQZXJo YXBzIHRoYXQgaXMgY2xlYXIgaW4gdGhlIGRyYWZ0LCBidXQgaWYgcGVvcGxlIGhhdmUgYSBkaWZm ZXJlbnQgdW5kZXJzdGFuZGluZyBpdCBtYXkgbmVlZCB0byBiZSBjbGFyaWZpZWQgOikNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D82B694ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7PC9zcGFuPiZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQiPkEgd2hpbGUgYWdvLCB3ZSBhZ3JlZWQgdGhhdCBjb25zZW50IGRvZXMgbm90IG5l ZWQgdG8gYmUgbWFpbnRhaW5lZCBvbiBjYW5kaWRhdGUgcGFpcnMgdGhhdCBhcmVuJ3QgY3VycmVu dGx5IHVzZWQuJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+W0JBXSBJZiB0aGUgc3BlY2lmaWNhdGlvbiB3 ZXJlIHRvIHNheSB0aGF0IGNvbnNlbnQgaXMgcmVxdWlyZWQgb25jZSBtZWRpYSBpcyBzZW50LCB0 aGVuIHRoaXMgd291bGQgbG9naWNhbGx5IGZvbGxvdy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9yLCBXSElMRSBtZWRpYSBpcyBz ZW50IDopIEJlY2F1c2UsIGlmIHlvdSBzdG9wIHNlbmRpbmcgbWVkaWEgb24gYSBwYWlyIChlLmcu IGJlY2F1c2UgeW91IHN3aXRjaCB0byBhbm90aGVyIHBhaXIpLCB5b3UgY2FuIGFsc28gc3RvcCBk b2luZyBjb25zZW50LCBidXQgdGhhdCBkb2VzbuKAmXQNCiBtZWFuIGNvbnNlbnQgd2lsbCBiZSBs b3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku NXB0O2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPlRoYXQgc2hvdWxkIG5vdCBiZSBzZWVuIGFzIGxvc3QgY29uc2VudCAoaS5lLiBpZiB0 aGUgVUEgd2FudHMgdG8gc3RhcnQgc2VuZGluZyBkYXRhIG9uIHRoZSBjYW5kaWRhdGUgcGFpciBp dCBzaG91bGQgbm90IGhhdmUgdG8gZG8gSUNFDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jmd0OyZndDs8L3NwYW4+cmVzdGFydCBvciBjcmVhdGUgYSZuYnNwOyBuZXcgc2Vzc2lvbikuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+W0JBXSBJIGFncmVlLiBBcyBsb25nIGFzIGl0IGNhbiBvYnRhaW4gY29uc2Vu dCBvbiB0aGUgbmV3IHBhaXIgKHdpdGhvdXQgaGF2aW5nIHRvIHVwZGF0ZSB0aGUgdWZyYWcvcHdk KSwgaXQgc2hvdWxkIGJlIGZpbmUuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBjb3VsZCBldmVuIGJlIGFuIG9s ZCBwYWlyLCBvbiB3aGljaCB0aGUgVUEgcHJldmlvdXNseSBzZW50IG1lZGlhLCBidXQgdGhlbiBz d2l0Y2hlZCB0byBhbm90aGVyIHBhaXIgKGZvciB3aGF0ZXZlciByZWFzb24pLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0Ozwvc3Bhbj5T bywgY29uc2VudCBpcyBsb3N0IGlmIHRoZSBVQSBzZW5kcyBjb25zZW50IHJlcXVlc3RzLCBhbmQg ZG9lcyBub3QgcmVjZWl2ZSBhIHJlc3BvbnNlLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jmd0Ozwvc3Bhbj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6IzFGNDk3RCI+ Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5bQkFdIENvbnNlbnQgaXMg bG9zdCBmb3IgdGhhdCBjYW5kaWRhdGUgcGFpciwgYW5kIHRoYXQgcGFpciBhbG9uZS48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Q29ycmVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdDtjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPklmIGNvbm5lY3Rpdml0eSBjaGVja3MgYXJlIGJlaW5nIGRvbmUgb24gYW4gdW51c2Vk IGNhbmRpZGF0ZSBwYWlyIChhcyBhZHZvY2F0ZWQgaW4gSnVzdGluJ3Mgbm9tYmlzIGRyYWZ0KSwg dGhlDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPmNvbnNlbnQgbWVjaGFu aXNtIGRvZXMgbm90IGFwcGx5IHVudGlsIG1lZGlhIGlzIHNlbnQgb24gdGhhdCBwYWlyLiZuYnNw OyBTbyB5b3UgY2FuJ3QgcmV2b2tlIGNvbnNlbnQgb24gYSBjYW5kaWRhdGUNCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+cGFpciBpZiBtZWRpYSBpc24ndCBiZWluZyBzZW50 IG9uIHRoZSBwYWlyLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db3JyZWN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T2YgY291cnNlLCBpZiB5b3Ugd2FudCB0byBt YWludGFpbiB0aGUgcGFpciwgeW91IHN0aWxsIGhhdmUgdG8gc2VuZCBrZWVwLWFsaXZlcywgYnV0 IHRoYXTigJlzIGEgc2VwYXJhdGUgc3RvcnkgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPiZu YnNwOzxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIE1heSAyMSwgMjAxNSBhdCA4OjU1IFBNLCBDaHJpc3RlciBI b2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpLDxicj4NCjxicj4NCi4uLjxicj4NCjxicj4NCiZndDsmZ3Q7IEFmdGVyIGNvbnNlbnQgaXMg bG9zdCBmb3IgYW55IHJlYXNvbiwgdGhlIHNhbWUgSUNFIGNyZWRlbnRpYWxzIE1VU1Q8YnI+DQom Z3Q7Jmd0OyBOT1QgYmUgdXNlZCBvbiB0aGUgYWZmZWN0ZWQgNS10dXBsZSBhZ2Fpbi4gVGhhdCBt ZWFucyB0aGF0IGEgbmV3PGJyPg0KJmd0OyZndDsgc2Vzc2lvbiwgb3IgYW4gSUNFIHJlc3RhcnQs IGlzIG5lZWRlZCB0byBvYnRhaW4gY29uc2VudCB0byBzZW5kLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgW0JBXSBUaGUgc2Vjb25kIHNlbnRlbmNlIGRvZXMgbm90IGZvbGxvdyBmcm9tIHRo ZSBmaXJzdC4gUkZDIDUyNDU8YnI+DQomZ3Q7Jmd0OyBlbmFibGVzIHNlbmRpbmcgb2YgbWVkaWEg b25jZSBhIHN1Y2Nlc3NmdWwgSUNFIGNvbm5lY3Rpdml0eSBjaGVjayBoYXMgYmVlbiByZWNlaXZl ZC48YnI+DQomZ3Q7Jmd0OyBJZiBtdWx0aXBsZSBzdWNjZXNzZnVsIGNhbmRpZGF0ZSBwYWlycyBo YXZlIGJlZW4gaWRlbnRpZmllZCwgd2h5PGJyPg0KJmd0OyZndDsgc2hvdWxkIGZhaWx1cmUgb2Yg Y29uc2VudCBvbiBvbmUgY2FuZGlkYXRlIHBhaXIgcmVxdWlyZSBhbiBJQ0UgcmVzdGFydDxicj4N CiZndDsmZ3Q7IGlmIGFub3RoZXIgb3BlcmF0aW9uYWwgY2FuZGlkYXRlIHBhaXIgZXhpc3RzPzxi cj4NCiZndDs8YnI+DQomZ3Q7Li4uIGlzIG5lZWRlZCB0byBvYnRhaW4gY29uc2VudCB0byBzZW5k ICpvbiB0aGF0IGNhbmRpZGF0ZSBwYWlyKi48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZXJlIHdhcyBh IGxvbmcgZGlzY3Vzc2lvbiBhYm91dCB0aGlzIHBvaW50LCB0aGUgY29uY2x1c2lvbiBvZiB3aGlj aCB3YXMgJnF1b3Q7dXNlIGl0IG9yIGxvc2UgaXQmcXVvdDsuJm5ic3A7IFRoaXMgY2FwdHVyZXMg dGhhdCAmZ3Q7Y29uY2x1c2lvbi4mbmJzcDsgSSBjYW4ndCByZW1lbWJlciB0aGUgZGV0YWlscyBv ZiB0aGUgZGlzY3Vzc2lvbiwgYnV0IEkgdGhpbmsgdGhhdCBpdCB3YXNuJ3QgYSBzZWN1cml0eSBj b25jZXJuIGJ1dCBhICZndDtyb2J1c3RuZXNzIG9uZS48YnI+DQo8YnI+DQpBIHdoaWxlIGFnbywg d2UgYWdyZWVkIHRoYXQgY29uc2VudCBkb2VzIG5vdCBuZWVkIHRvIGJlIG1haW50YWluZWQgb24g Y2FuZGlkYXRlIHBhaXJzIHRoYXQgYXJlbid0IGN1cnJlbnRseSB1c2VkLiBUaGF0IHNob3VsZCBu b3QgYmUgc2VlbiBhcyBsb3N0IGNvbnNlbnQgKGkuZS4gaWYgdGhlIFVBIHdhbnRzIHRvIHN0YXJ0 IHNlbmRpbmcgZGF0YSBvbiB0aGUgY2FuZGlkYXRlIHBhaXIgaXQgc2hvdWxkIG5vdCBoYXZlIHRv IGRvIElDRSByZXN0YXJ0DQogb3IgY3JlYXRlIGEmbmJzcDsgbmV3IHNlc3Npb24pLjxicj4NCjxi cj4NClNvLCBjb25zZW50IGlzIGxvc3QgaWYgdGhlIFVBIHNlbmRzIGNvbnNlbnQgcmVxdWVzdHMs IGFuZCBkb2VzIG5vdCByZWNlaXZlIGEgcmVzcG9uc2UuIENvbnNlbnQgaXMgTk9UIGxvc3QgaWYg dGhlIFVBIHN0b3BzIHNlbmRpbmcgY29uc2VudCByZXF1ZXN0cyAoYW5kIHRoZXJlZm9yIG9idmlv dXNseSB3aWxsIG5vdCByZWNlaXZlIGEgcmVzcG9uc2UpLjxicj4NCjxicj4NClBlcmhhcHMgdGhh dCBpcyBjbGVhciBpbiB0aGUgZHJhZnQsIGJ1dCBpZiBwZW9wbGUgaGF2ZSBhIGRpZmZlcmVudCB1 bmRlcnN0YW5kaW5nIGl0IG1heSBuZWVkIHRvIGJlIGNsYXJpZmllZCA6KTxicj4NCjxicj4NClJl Z2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D82B694ESESSMB209erics_-- From nobody Fri May 22 09:38: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 D5DBD1A1BA2; Fri, 22 May 2015 09:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_35=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 wC817DihBiL0; Fri, 22 May 2015 09:38:07 -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 417611A1B7C; Fri, 22 May 2015 09:38:07 -0700 (PDT) Received: by yhom41 with SMTP id m41so5707077yho.1; Fri, 22 May 2015 09:38:06 -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=JhE1rpEpNlXY48/VcAYSch6QWFdLBa7LdZe8uvMBR+0=; b=WD0gg6WQT06M+NWlHT10QJGxp5UVm3rnpxS6SeFZuVY3pqfkZ1RLsnjpzD1v9ceLLF EpMCFCyGBzup8hlyC0K9N/zw2ZclP/ZerfbhHYadtUFOHGH2MVqkziaFwBucmCcNuSiw Z9qLTvVRVsPFmCc/y1U4V9OupewpWoWl+7qX9SInj69t5sqG5XNxOYXq833pYBWn6I4D R5YdRTpJC1iaojH74uqR8SeOnVs0GUK5HdH8bYkvZDInGAsClnH0IhMSu6wAG7aoJKyw xbNDBRTd6dQItEL3GvEitez4+P+HxHg9O+YgyFqg7svDODzeF92r8d0rsk0R8DXQ8un6 Bf2Q== MIME-Version: 1.0 X-Received: by 10.170.204.15 with SMTP id v15mr177459yke.57.1432312686631; Fri, 22 May 2015 09:38:06 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 22 May 2015 09:38:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 May 2015 09:38:06 -0700 Message-ID: From: Martin Thomson To: Bernard Aboba , Muthu Arul Mozhi Perumal , "Tirumaleswar Reddy (tireddy)" 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: Fri, 22 May 2015 16:38:09 -0000 Tiru/Muthu, where the hell is the master copy of the draft? This requires a little care and I'd like to propose several pull requests. On 21 May 2015 at 16:54, Bernard Aboba wrote: > Martin said: >> 1. Adaptation of the RTO via RTT measurement > > [Martin] I agree that this is a concern, but we have a means of determining > RTO, so we just need to add text that says something like: The initial > STUN transaction produces a value for RTO on any given candidate pair. > That value is used in determining how long to await a STUN response, > it is updated as new STUN responses are received. > > [BA] If you cite the RFC 5389 text relating to initial RTO, caching, > estimation algorithm, etc. you can then use the calculated value to > determine how long to await a STUN response. That's reasonable. I'll propose text as soon as I can lay my hands on a copy of a draft. >> 2. Consistent number of requests sent without a response (Rc) before >> transaction failure >> 3. Total time to transaction failure robust against routing transients > > I don't agree that either of these is a problem. It's a design, > certainly, but it suffers from a dire lack of determinism in running > time, something that might be exploited to increase denial of service > exposure time. > > [BA] The effective transmission rate matters in DDOS more than running time > - which is why the RFC 5389 backoff algorithm makes a difference. Here an > Rc value of 7 is not as critical as having it be a constant. The draft requires at most one check every 4s for a pair and only when consent is active. ICE sends at 20ms intervals. Open loop. That matters far more for DDOS. >> 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. > > If response i arrives after i+1, that's not going to provide any > useful information about RTO itself (RTO jitter perhaps). > > [BA] That is true if the transaction ID doesn't change (e.g. RFC 5389). But > if the transaction ID changes, then you can use the arrival time of response > i to get a better RTO estimate, even if i+1 arrives first. This is valuable > since it is most likely to happen when the originally calculated RTO value > is too low, making a false retransmission timeout more likely. RFC 5682 > describes some of the concerns relating to F-RTO. Sure, but I don't think that we *need* that level of sophistication. There's nothing stopping an implementation from doing smarter things, but we are only looking to ensure that consent doesn't persist indefinitely. > [BA] Varying Rc will produce a false retransmission probability that will > vary by network conditions, particularly if Rc can be small (e.g. only a few > retransmissions prior to declaring consent revocation). See above regarding unnecessary sophistication. >> 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. > > How can we make this clearer? > > [BA] If consent expires at 30 seconds + RTO (or better, at last request > sending time plus RTO) then that would clarify things. I can see where you are coming from here. I think that we need a different fix, if anything. 1. STUN requests are sent at a regular interval (with variance). 2. Each STUN request is tracked for RTO+delta. 3. If a successful STUN response has been received in the last 30 seconds, you have consent. That is a subtle change, but it would allow for connections with an RTO greater than 30 seconds. The only actual problem I can detect with the current formulation. > I like that. Note that "excessive traffic" was intended to be in > time, not volume. > > [BA] Why would time matter if consent packets aren't being sent (e.g. > backoff)? Let me rephrase. The mechanism in this draft prevents packets from being sent to an unwilling recipient. It does that by limiting the *time* that this can happen. It does nothing about the *volume*, either in number of packets or number of bytes. I agree that "excessive" implies the latter (and hence think that your proposed text in this regard was good.) > That's easy, let's just say that this process applies *after* consent > has been acquired. maybe we could move this up to Section 4: > > [BA] The question is when consent is acquired. I'd assume that this begins > when media starts being sent - which according to RFC 5245 can occur after a > successful connectivity check response. So ICE isn't necessarily complete. Right. We can clarify that too. If only I had a copy of the damned draft, I'd propose some changes. > ... is needed to obtain consent to send *on that candidate pair*. > > [BA] That part makes sense - but if there is another valid pair, it should > be possible to start sending media on that pair without having to do an ICE > restart. That is allowed under RFC 5245. Correct. We can add that clarification too. From nobody Fri May 22 10:29: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 873491A1BA3; Fri, 22 May 2015 10:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, 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 a3LTLdrsXKHT; Fri, 22 May 2015 10:28:54 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120321A874D; Fri, 22 May 2015 10:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8590; q=dns/txt; s=iport; t=1432315734; x=1433525334; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pTYze2wDKYbmXTHuv3CWcMKXaGNCZvsAgH7C08FUa2g=; b=IqOA/NjGUCszkdnmIVOB250YUlPyTGicnOd679EdfcMt5KcbC+pQp83P +2zBPCr1uCJkyKq/tUMm+568m33HPnjo7etX7OtQqy+mHc2/08JnYTC1w V/SivzpiKoAqB+XNrgqYEj5PyrJwKL0kEoJwSTceWKt0uKlImwOnj5ttI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B4BAATZ19V/5NdJa1cgxBUXgaDGb8ZZgmBXYVzAhyBHTgUAQEBAQEBAYEKhCIBAQEDASMRPgcFBwQCAQgRBAEBAQICBh0DAgICHxEUAQgIAgQBDQUIiA8DCggNr3afDg2EcgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGKGYJNggcWGwcGgmIvgRYBBJMBhDWEf4MBjnyDKINZI4IHAxyBUm+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,477,1427760000"; d="scan'208";a="152492928" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 22 May 2015 17:28:53 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4MHSrjV001193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 May 2015 17:28:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 22 May 2015 12:28:52 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Martin Thomson , Bernard Aboba , Muthu Arul Mozhi Perumal Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness Thread-Index: AQHQk1eS1ZbgKeHyC0Cjwx+443SghJ2HY76AgAAMcwCAARhNAP//ujjg Date: Fri, 22 May 2015 17:28:51 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A4785AE60@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.37.83] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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: Fri, 22 May 2015 17:29:02 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBNYXkgMjIsIDIw MTUgMTA6MDggUE0NCj4gVG86IEJlcm5hcmQgQWJvYmE7IE11dGh1IEFydWwgTW96aGkgUGVydW1h bDsgVGlydW1hbGVzd2FyIFJlZGR5DQo+ICh0aXJlZGR5KQ0KPiBDYzogcnRjd2ViQGlldGYub3Jn OyBUaGUgSUVTRzsgRW1pbCBJdm92OyBSb2JpbiBSYXltb25kDQo+IFN1YmplY3Q6IFJlOiBbcnRj d2ViXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcw0K PiANCj4gVGlydS9NdXRodSwgd2hlcmUgdGhlIGhlbGwgaXMgdGhlIG1hc3RlciBjb3B5IG9mIHRo ZSBkcmFmdD8gIFRoaXMgcmVxdWlyZXMgYQ0KPiBsaXR0bGUgY2FyZSBhbmQgSSdkIGxpa2UgdG8g cHJvcG9zZSBzZXZlcmFsIHB1bGwgcmVxdWVzdHMuDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9EcmFm dC1NYWZpYS9JRVRGLWRyYWZ0cy9ibG9iL21hc3Rlci9TVFVOLUNvbnNlbnQtZHJhZnQvZHJhZnQt aWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMy54bWwgDQoNCi1UaXJ1DQoNCj4g DQo+IE9uIDIxIE1heSAyMDE1IGF0IDE2OjU0LCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbT4NCj4gd3JvdGU6DQo+ID4gTWFydGluIHNhaWQ6DQo+ID4+IDEuIEFkYXB0YXRp b24gb2YgdGhlIFJUTyB2aWEgUlRUIG1lYXN1cmVtZW50DQo+ID4NCj4gPiBbTWFydGluXSBJIGFn cmVlIHRoYXQgdGhpcyBpcyBhIGNvbmNlcm4sIGJ1dCB3ZSBoYXZlIGEgbWVhbnMgb2YNCj4gPiBk ZXRlcm1pbmluZyBSVE8sIHNvIHdlIGp1c3QgbmVlZCB0byBhZGQgdGV4dCB0aGF0IHNheXMgc29t ZXRoaW5nIGxpa2U6DQo+ID4gVGhlIGluaXRpYWwgU1RVTiB0cmFuc2FjdGlvbiBwcm9kdWNlcyBh IHZhbHVlIGZvciBSVE8gb24gYW55IGdpdmVuDQo+IGNhbmRpZGF0ZSBwYWlyLg0KPiA+IFRoYXQg dmFsdWUgaXMgdXNlZCBpbiBkZXRlcm1pbmluZyBob3cgbG9uZyB0byBhd2FpdCBhIFNUVU4gcmVz cG9uc2UsDQo+ID4gaXQgaXMgdXBkYXRlZCBhcyBuZXcgU1RVTiByZXNwb25zZXMgYXJlIHJlY2Vp dmVkLg0KPiA+DQo+ID4gW0JBXSBJZiB5b3UgY2l0ZSB0aGUgUkZDIDUzODkgdGV4dCByZWxhdGlu ZyB0byBpbml0aWFsIFJUTywgY2FjaGluZywNCj4gPiBlc3RpbWF0aW9uIGFsZ29yaXRobSwgZXRj LiB5b3UgY2FuIHRoZW4gdXNlIHRoZSBjYWxjdWxhdGVkIHZhbHVlIHRvDQo+ID4gZGV0ZXJtaW5l IGhvdyBsb25nIHRvIGF3YWl0IGEgU1RVTiByZXNwb25zZS4NCj4gDQo+IFRoYXQncyByZWFzb25h YmxlLiAgSSdsbCBwcm9wb3NlIHRleHQgYXMgc29vbiBhcyBJIGNhbiBsYXkgbXkgaGFuZHMgb24g YSBjb3B5IG9mDQo+IGEgZHJhZnQuDQo+IA0KPiA+PiAyLiBDb25zaXN0ZW50IG51bWJlciBvZiBy ZXF1ZXN0cyBzZW50IHdpdGhvdXQgYSByZXNwb25zZSAoUmMpIGJlZm9yZQ0KPiA+PiB0cmFuc2Fj dGlvbiBmYWlsdXJlIDMuIFRvdGFsIHRpbWUgdG8gdHJhbnNhY3Rpb24gZmFpbHVyZSByb2J1c3QN Cj4gPj4gYWdhaW5zdCByb3V0aW5nIHRyYW5zaWVudHMNCj4gPg0KPiA+IEkgZG9uJ3QgYWdyZWUg dGhhdCBlaXRoZXIgb2YgdGhlc2UgaXMgYSBwcm9ibGVtLiAgSXQncyBhIGRlc2lnbiwNCj4gPiBj ZXJ0YWlubHksIGJ1dCBpdCBzdWZmZXJzIGZyb20gYSBkaXJlIGxhY2sgb2YgZGV0ZXJtaW5pc20g aW4gcnVubmluZw0KPiA+IHRpbWUsIHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJlIGV4cGxvaXRlZCB0 byBpbmNyZWFzZSBkZW5pYWwgb2Ygc2VydmljZQ0KPiA+IGV4cG9zdXJlIHRpbWUuDQo+ID4NCj4g PiBbQkFdIFRoZSBlZmZlY3RpdmUgdHJhbnNtaXNzaW9uIHJhdGUgbWF0dGVycyBpbiBERE9TIG1v cmUgdGhhbiBydW5uaW5nDQo+ID4gdGltZQ0KPiA+IC0gd2hpY2ggaXMgd2h5IHRoZSBSRkMgNTM4 OSBiYWNrb2ZmIGFsZ29yaXRobSBtYWtlcyBhIGRpZmZlcmVuY2UuDQo+ID4gSGVyZSBhbiBSYyB2 YWx1ZSBvZiA3IGlzIG5vdCBhcyBjcml0aWNhbCBhcyBoYXZpbmcgaXQgYmUgYSBjb25zdGFudC4N Cj4gDQo+IFRoZSBkcmFmdCByZXF1aXJlcyBhdCBtb3N0IG9uZSBjaGVjayBldmVyeSA0cyBmb3Ig YSBwYWlyIGFuZCBvbmx5IHdoZW4NCj4gY29uc2VudCBpcyBhY3RpdmUuICBJQ0Ugc2VuZHMgYXQg MjBtcyBpbnRlcnZhbHMuICBPcGVuIGxvb3AuICBUaGF0IG1hdHRlcnMgZmFyDQo+IG1vcmUgZm9y IERET1MuDQo+IA0KPiA+PiAxLiBObyBSVFQvUlRPIGVzdGltYXRpb24gLSBhbmQgZ2l2ZW4gdGhh dCByZXNwb25zZXMgdG8gYSByZXF1ZXN0IHRoYXQNCj4gPj4gYXJyaXZlIGFmdGVyIGEgbmV3IHJl cXVlc3QgaXMgc2VudCBhcmUgaWdub3JlZCwgbm8gYWJpbGl0eSB0byBtYWtlDQo+ID4+IHVzZSBv ZiB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyBhdmFpbGFibGUuIEVmZmVjdGl2ZWx5LCB0aGUNCj4g Pj4gc3BlY2lmaWNhdGlvbiBzZXRzIHRoZSBSVE8gdG8gYmUgYSByYW5kb20gdmFsdWUgYmV0d2Vl biA0IGFuZCA2DQo+ID4+IHNlY29uZHMsIHdpdGggbm8gcmVsYXRpb25zaGlwIHRvIG5ldHdvcmsg Y2hhcmFjdGVyaXN0aWNzLg0KPiA+DQo+ID4gSWYgcmVzcG9uc2UgaSBhcnJpdmVzIGFmdGVyIGkr MSwgdGhhdCdzIG5vdCBnb2luZyB0byBwcm92aWRlIGFueQ0KPiA+IHVzZWZ1bCBpbmZvcm1hdGlv biBhYm91dCBSVE8gaXRzZWxmIChSVE8gaml0dGVyIHBlcmhhcHMpLg0KPiA+DQo+ID4gW0JBXSBU aGF0IGlzIHRydWUgaWYgdGhlIHRyYW5zYWN0aW9uIElEIGRvZXNuJ3QgY2hhbmdlIChlLmcuIFJG Qw0KPiA+IDUzODkpLiAgQnV0IGlmIHRoZSB0cmFuc2FjdGlvbiBJRCBjaGFuZ2VzLCB0aGVuIHlv dSBjYW4gdXNlIHRoZQ0KPiA+IGFycml2YWwgdGltZSBvZiByZXNwb25zZSBpIHRvIGdldCBhIGJl dHRlciBSVE8gZXN0aW1hdGUsIGV2ZW4gaWYgaSsxDQo+ID4gYXJyaXZlcyBmaXJzdC4gVGhpcyBp cyB2YWx1YWJsZSBzaW5jZSBpdCBpcyBtb3N0IGxpa2VseSB0byBoYXBwZW4gd2hlbg0KPiA+IHRo ZSBvcmlnaW5hbGx5IGNhbGN1bGF0ZWQgUlRPIHZhbHVlIGlzIHRvbyBsb3csIG1ha2luZyBhIGZh bHNlDQo+ID4gcmV0cmFuc21pc3Npb24gdGltZW91dCBtb3JlIGxpa2VseS4gIFJGQyA1NjgyIGRl c2NyaWJlcyBzb21lIG9mIHRoZQ0KPiBjb25jZXJucyByZWxhdGluZyB0byBGLVJUTy4NCj4gDQo+ IFN1cmUsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgd2UgKm5lZWQqIHRoYXQgbGV2ZWwgb2Ygc29w aGlzdGljYXRpb24uDQo+IFRoZXJlJ3Mgbm90aGluZyBzdG9wcGluZyBhbiBpbXBsZW1lbnRhdGlv biBmcm9tIGRvaW5nIHNtYXJ0ZXIgdGhpbmdzLCBidXQNCj4gd2UgYXJlIG9ubHkgbG9va2luZyB0 byBlbnN1cmUgdGhhdCBjb25zZW50IGRvZXNuJ3QgcGVyc2lzdCBpbmRlZmluaXRlbHkuDQo+IA0K PiA+IFtCQV0gVmFyeWluZyBSYyB3aWxsIHByb2R1Y2UgYSBmYWxzZSByZXRyYW5zbWlzc2lvbiBw cm9iYWJpbGl0eSB0aGF0DQo+ID4gd2lsbCB2YXJ5IGJ5IG5ldHdvcmsgY29uZGl0aW9ucywgcGFy dGljdWxhcmx5IGlmIFJjIGNhbiBiZSBzbWFsbCAoZS5nLg0KPiA+IG9ubHkgYSBmZXcgcmV0cmFu c21pc3Npb25zIHByaW9yIHRvIGRlY2xhcmluZyBjb25zZW50IHJldm9jYXRpb24pLg0KPiANCj4g U2VlIGFib3ZlIHJlZ2FyZGluZyB1bm5lY2Vzc2FyeSBzb3BoaXN0aWNhdGlvbi4NCj4gDQo+ID4+ IDMuIFVuY2xlYXIgdGltZXIgYmVoYXZpb3IuICBEb2VzIGFuIGltcGxlbWVudGF0aW9uIGNvbnRp bnVlIHRvIHNlbmQNCj4gPj4gcmVxdWVzdHMgdW50aWwgMzAgc2Vjb25kcyBoYXMgZWxhcHNlZCwg b3IgZG9lcyBpdCBzdG9wIGJlZm9yZSB0aGVuIHNvDQo+ID4+IGFzIHRvIGFsbG93IGZvciBhIHJl c3BvbnNlIHRvIHRoZSBsYXN0IHJlcXVlc3QgdG8gYXJyaXZlPyAgT25lIGNvdWxkDQo+ID4+IGlu dGVycHJldCB0aGUgYWJvdmUgdG8gaW1wbHkgdGhhdCByZXF1ZXN0cyBjb250aW51ZSB0byBiZSBz ZW50IGZvciB1cA0KPiA+PiB0byAzMCBzZWNvbmRzLCBidXQgdGhlIGxhc3QgcmVxdWVzdCBpcyBj b25zaWRlcmVkIGZhaWxlZCBhcyBzb29uIGFzDQo+ID4+IHRoZSAzMCBzZWNvbmQgdGltZXIgZXhw aXJlcy4NCj4gPg0KPiA+IEhvdyBjYW4gd2UgbWFrZSB0aGlzIGNsZWFyZXI/DQo+ID4NCj4gPiBb QkFdIElmIGNvbnNlbnQgZXhwaXJlcyBhdCAzMCBzZWNvbmRzICsgUlRPIChvciBiZXR0ZXIsIGF0 IGxhc3QNCj4gPiByZXF1ZXN0IHNlbmRpbmcgdGltZSBwbHVzIFJUTykgdGhlbiB0aGF0IHdvdWxk IGNsYXJpZnkgdGhpbmdzLg0KPiANCj4gSSBjYW4gc2VlIHdoZXJlIHlvdSBhcmUgY29taW5nIGZy b20gaGVyZS4gIEkgdGhpbmsgdGhhdCB3ZSBuZWVkIGEgZGlmZmVyZW50IGZpeCwNCj4gaWYgYW55 dGhpbmcuDQo+IA0KPiAxLiBTVFVOIHJlcXVlc3RzIGFyZSBzZW50IGF0IGEgcmVndWxhciBpbnRl cnZhbCAod2l0aCB2YXJpYW5jZSkuDQo+IDIuIEVhY2ggU1RVTiByZXF1ZXN0IGlzIHRyYWNrZWQg Zm9yIFJUTytkZWx0YS4NCj4gMy4gSWYgYSBzdWNjZXNzZnVsIFNUVU4gcmVzcG9uc2UgaGFzIGJl ZW4gcmVjZWl2ZWQgaW4gdGhlIGxhc3QgMzAgc2Vjb25kcywgeW91DQo+IGhhdmUgY29uc2VudC4N Cj4gDQo+IFRoYXQgaXMgYSBzdWJ0bGUgY2hhbmdlLCBidXQgaXQgd291bGQgYWxsb3cgZm9yIGNv bm5lY3Rpb25zIHdpdGggYW4gUlRPDQo+IGdyZWF0ZXIgdGhhbiAzMCBzZWNvbmRzLiAgVGhlIG9u bHkgYWN0dWFsIHByb2JsZW0gSSBjYW4gZGV0ZWN0IHdpdGggdGhlDQo+IGN1cnJlbnQgZm9ybXVs YXRpb24uDQo+IA0KPiA+IEkgbGlrZSB0aGF0LiAgTm90ZSB0aGF0ICJleGNlc3NpdmUgdHJhZmZp YyIgd2FzIGludGVuZGVkIHRvIGJlIGluDQo+ID4gdGltZSwgbm90IHZvbHVtZS4NCj4gPg0KPiA+ IFtCQV0gV2h5IHdvdWxkIHRpbWUgbWF0dGVyIGlmIGNvbnNlbnQgcGFja2V0cyBhcmVuJ3QgYmVp bmcgc2VudCAoZS5nLg0KPiA+IGJhY2tvZmYpPw0KPiANCj4gTGV0IG1lIHJlcGhyYXNlLiAgVGhl IG1lY2hhbmlzbSBpbiB0aGlzIGRyYWZ0IHByZXZlbnRzIHBhY2tldHMgZnJvbSBiZWluZw0KPiBz ZW50IHRvIGFuIHVud2lsbGluZyByZWNpcGllbnQuICBJdCBkb2VzIHRoYXQgYnkgbGltaXRpbmcg dGhlDQo+ICp0aW1lKiB0aGF0IHRoaXMgY2FuIGhhcHBlbi4gIEl0IGRvZXMgbm90aGluZyBhYm91 dCB0aGUgKnZvbHVtZSosIGVpdGhlciBpbg0KPiBudW1iZXIgb2YgcGFja2V0cyBvciBudW1iZXIg b2YgYnl0ZXMuICBJIGFncmVlIHRoYXQgImV4Y2Vzc2l2ZSIgaW1wbGllcyB0aGUNCj4gbGF0dGVy IChhbmQgaGVuY2UgdGhpbmsgdGhhdCB5b3VyIHByb3Bvc2VkIHRleHQgaW4gdGhpcyByZWdhcmQg d2FzIGdvb2QuKQ0KPiANCj4gPiBUaGF0J3MgZWFzeSwgbGV0J3MganVzdCBzYXkgdGhhdCB0aGlz IHByb2Nlc3MgYXBwbGllcyAqYWZ0ZXIqIGNvbnNlbnQNCj4gPiBoYXMgYmVlbiBhY3F1aXJlZC4g IG1heWJlIHdlIGNvdWxkIG1vdmUgdGhpcyB1cCB0byBTZWN0aW9uIDQ6DQo+ID4NCj4gPiBbQkFd IFRoZSBxdWVzdGlvbiBpcyB3aGVuIGNvbnNlbnQgaXMgYWNxdWlyZWQuIEknZCBhc3N1bWUgdGhh dCB0aGlzDQo+ID4gYmVnaW5zIHdoZW4gbWVkaWEgc3RhcnRzIGJlaW5nIHNlbnQgLSB3aGljaCBh Y2NvcmRpbmcgdG8gUkZDIDUyNDUgY2FuDQo+ID4gb2NjdXIgYWZ0ZXIgYSBzdWNjZXNzZnVsIGNv bm5lY3Rpdml0eSBjaGVjayByZXNwb25zZS4gIFNvIElDRSBpc24ndCBuZWNlc3NhcmlseQ0KPiBj b21wbGV0ZS4NCj4gDQo+IFJpZ2h0LiAgV2UgY2FuIGNsYXJpZnkgdGhhdCB0b28uICBJZiBvbmx5 IEkgaGFkIGEgY29weSBvZiB0aGUgZGFtbmVkIGRyYWZ0LCBJJ2QNCj4gcHJvcG9zZSBzb21lIGNo YW5nZXMuDQo+IA0KPiA+IC4uLiBpcyBuZWVkZWQgdG8gb2J0YWluIGNvbnNlbnQgdG8gc2VuZCAq b24gdGhhdCBjYW5kaWRhdGUgcGFpciouDQo+ID4NCj4gPiBbQkFdIFRoYXQgcGFydCBtYWtlcyBz ZW5zZSAtIGJ1dCBpZiB0aGVyZSBpcyBhbm90aGVyIHZhbGlkIHBhaXIsIGl0DQo+ID4gc2hvdWxk IGJlIHBvc3NpYmxlIHRvIHN0YXJ0IHNlbmRpbmcgbWVkaWEgb24gdGhhdCBwYWlyIHdpdGhvdXQg aGF2aW5nDQo+ID4gdG8gZG8gYW4gSUNFIHJlc3RhcnQuICBUaGF0IGlzIGFsbG93ZWQgdW5kZXIg UkZDIDUyNDUuDQo+IA0KPiBDb3JyZWN0LiAgV2UgY2FuIGFkZCB0aGF0IGNsYXJpZmljYXRpb24g dG9vLg0K From nobody Fri May 22 10:41: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 6840B1A8778; Fri, 22 May 2015 10:41:20 -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_35=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 NwDxFttMRDYq; Fri, 22 May 2015 10:41:17 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 C8FAA1A8772; Fri, 22 May 2015 10:41:16 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so24298283wgb.3; Fri, 22 May 2015 10:41:15 -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=deHpB1Q23p+ogGwfiu1a4pXas0dsRzrJrG+Aj6e2l40=; b=oiknTsl35G78AjP4vAPvKGDF9BPIE7dQiUbBS5kpFBNYIti57nSi23CAt74fh0JsCa I++RIJS/xIl9ap7wgu+MtAR3+1FNoBp6hbykR9EmP4JjBEk/fih9VdMCSI1b8OpOpxwX Pps/tj67kVGMmWbq5AGOU1LKJ8DKddGAV0Ikrww/9S3fSWxsNQaiWo0pgJ+KW7llAQjb zfWh5WOMllbzQ7F2Zu70NTq3ksdJanpM1SnnUzBOlXvRTqlOVbyV68TyJWvM3D6o3llr e8kQoXn1v5zvIGeATLYi/FNgP58UaEDpeGsYsdUq1/88QG/18i/h3okAPF4MvIl1Jn2e A9jw== X-Received: by 10.180.20.200 with SMTP id p8mr9464274wie.78.1432316475553; Fri, 22 May 2015 10:41:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.54.16 with HTTP; Fri, 22 May 2015 10:40:55 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A4785AE60@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A4785AE60@xmb-rcd-x10.cisco.com> From: Bernard Aboba Date: Fri, 22 May 2015 10:40:55 -0700 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=bcaec53f35efbb3c0d0516af2a8c 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: Fri, 22 May 2015 17:41:20 -0000 --bcaec53f35efbb3c0d0516af2a8c Content-Type: text/plain; charset=UTF-8 Martin said: "Sure, but I don't think that we *need* that level of sophistication. There's nothing stopping an implementation from doing smarter things," [BA] While ignoring an i response after arrival of i+1 makes sense with respect to consent, the i RTT value should still be taken into account, so as to properly estimate the RTO. :"1. STUN requests are sent at a regular interval (with variance). 2. Each STUN request is tracked for RTO+delta. 3. If a successful STUN response has been received in the last 30 seconds, you have consent." [BA] If a STUN request is still being tracked (RTO has not yet expired), would expiration of the 30 second timer still cause consent to expire? Or would revocation wait until the RTO timer expires? The latter makes more sense to me. On Fri, May 22, 2015 at 10:28 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > -----Original Message----- > > From: Martin Thomson [mailto:martin.thomson@gmail.com] > > Sent: Friday, May 22, 2015 10:08 PM > > To: Bernard Aboba; Muthu Arul Mozhi Perumal; Tirumaleswar Reddy > > (tireddy) > > Cc: rtcweb@ietf.org; The IESG; Emil Ivov; Robin Raymond > > Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness > > > > Tiru/Muthu, where the hell is the master copy of the draft? This > requires a > > little care and I'd like to propose several pull requests. > > > https://github.com/Draft-Mafia/IETF-drafts/blob/master/STUN-Consent-draft/draft-ietf-rtcweb-stun-consent-freshness-13.xml > > -Tiru > > > > > On 21 May 2015 at 16:54, Bernard Aboba > > wrote: > > > Martin said: > > >> 1. Adaptation of the RTO via RTT measurement > > > > > > [Martin] I agree that this is a concern, but we have a means of > > > determining RTO, so we just need to add text that says something like: > > > The initial STUN transaction produces a value for RTO on any given > > candidate pair. > > > That value is used in determining how long to await a STUN response, > > > it is updated as new STUN responses are received. > > > > > > [BA] If you cite the RFC 5389 text relating to initial RTO, caching, > > > estimation algorithm, etc. you can then use the calculated value to > > > determine how long to await a STUN response. > > > > That's reasonable. I'll propose text as soon as I can lay my hands on a > copy of > > a draft. > > > > >> 2. Consistent number of requests sent without a response (Rc) before > > >> transaction failure 3. Total time to transaction failure robust > > >> against routing transients > > > > > > I don't agree that either of these is a problem. It's a design, > > > certainly, but it suffers from a dire lack of determinism in running > > > time, something that might be exploited to increase denial of service > > > exposure time. > > > > > > [BA] The effective transmission rate matters in DDOS more than running > > > time > > > - which is why the RFC 5389 backoff algorithm makes a difference. > > > Here an Rc value of 7 is not as critical as having it be a constant. > > > > The draft requires at most one check every 4s for a pair and only when > > consent is active. ICE sends at 20ms intervals. Open loop. That > matters far > > more for DDOS. > > > > >> 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. > > > > > > If response i arrives after i+1, that's not going to provide any > > > useful information about RTO itself (RTO jitter perhaps). > > > > > > [BA] That is true if the transaction ID doesn't change (e.g. RFC > > > 5389). But if the transaction ID changes, then you can use the > > > arrival time of response i to get a better RTO estimate, even if i+1 > > > arrives first. This is valuable since it is most likely to happen when > > > the originally calculated RTO value is too low, making a false > > > retransmission timeout more likely. RFC 5682 describes some of the > > concerns relating to F-RTO. > > > > Sure, but I don't think that we *need* that level of sophistication. > > There's nothing stopping an implementation from doing smarter things, but > > we are only looking to ensure that consent doesn't persist indefinitely. > > > > > [BA] Varying Rc will produce a false retransmission probability that > > > will vary by network conditions, particularly if Rc can be small (e.g. > > > only a few retransmissions prior to declaring consent revocation). > > > > See above regarding unnecessary sophistication. > > > > >> 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. > > > > > > How can we make this clearer? > > > > > > [BA] If consent expires at 30 seconds + RTO (or better, at last > > > request sending time plus RTO) then that would clarify things. > > > > I can see where you are coming from here. I think that we need a > different fix, > > if anything. > > > > 1. STUN requests are sent at a regular interval (with variance). > > 2. Each STUN request is tracked for RTO+delta. > > 3. If a successful STUN response has been received in the last 30 > seconds, you > > have consent. > > > > That is a subtle change, but it would allow for connections with an RTO > > greater than 30 seconds. The only actual problem I can detect with the > > current formulation. > > > > > I like that. Note that "excessive traffic" was intended to be in > > > time, not volume. > > > > > > [BA] Why would time matter if consent packets aren't being sent (e.g. > > > backoff)? > > > > Let me rephrase. The mechanism in this draft prevents packets from being > > sent to an unwilling recipient. It does that by limiting the > > *time* that this can happen. It does nothing about the *volume*, either > in > > number of packets or number of bytes. I agree that "excessive" implies > the > > latter (and hence think that your proposed text in this regard was good.) > > > > > That's easy, let's just say that this process applies *after* consent > > > has been acquired. maybe we could move this up to Section 4: > > > > > > [BA] The question is when consent is acquired. I'd assume that this > > > begins when media starts being sent - which according to RFC 5245 can > > > occur after a successful connectivity check response. So ICE isn't > necessarily > > complete. > > > > Right. We can clarify that too. If only I had a copy of the damned > draft, I'd > > propose some changes. > > > > > ... is needed to obtain consent to send *on that candidate pair*. > > > > > > [BA] That part makes sense - but if there is another valid pair, it > > > should be possible to start sending media on that pair without having > > > to do an ICE restart. That is allowed under RFC 5245. > > > > Correct. We can add that clarification too. > --bcaec53f35efbb3c0d0516af2a8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin said:=C2=A0

"Sure, but I don't think that we *need* t= hat level of sophistication.
There's nothing stopping an implementation from doing smarte= r things,"

[BA] Wh= ile ignoring an i response after arrival of i+1 makes sense with respect to= consent, the i RTT value should still be taken into account, so as to prop= erly estimate the RTO.=C2=A0

:"1. STUN = requests are sent at a regular interval (with variance).
2. Each STUN request is tracked for = RTO+delta.
3. If a successful STUN response has been rec= eived in the last 30=C2=A0seconds, you have consent."

[BA] If a STUN= request is still being tracked (RTO has not yet expired), would expiration= of the 30 second timer still cause consent to expire?=C2=A0 Or would revoc= ation wait until the RTO timer expires?=C2=A0 The latter makes more sense t= o me.=C2=A0

On Fri, May 22, 2015 at 10:28 AM, Tirumaleswar Reddy (tireddy)= <tireddy@cisco.com> wrote:
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Friday, May 22, 2015 10:08 PM
> To: Bernard Aboba; Muthu Arul Mozhi Perumal; Tirumaleswar Reddy
> (tireddy)
> Cc: rtcweb@ietf.org; The IESG; = Emil Ivov; Robin Raymond
> Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshne= ss
>
> Tiru/Muthu, where the hell is the master copy = of the draft?=C2=A0 This requires a
> little care and I'd like to propose several pull requests.

https://github.com/Draft-Mafia/IETF-drafts/blob/master/STUN-Consen= t-draft/draft-ietf-rtcweb-stun-consent-freshness-13.xml

-Tiru

>
> On 21 May 2015 at 16:54, Bernard Aboba <bernard.aboba@gmail.com>
> wrote:
> > Martin said:
> >> 1. Adaptation of the RTO via RTT measurement
> >
> > [Martin] I agree that this is a concern, but we have a means of > > determining RTO, so we just need to add text that says something = like:
> > The initial STUN transaction produces a value for RTO on any give= n
> candidate pair.
> > That value is used in determining how long to await a STUN respon= se,
> > it is updated as new STUN responses are received.
> >
> > [BA] If you cite the RFC 5389 text relating to initial RTO, cachi= ng,
> > estimation algorithm, etc. you can then use the calculated value = to
> > determine how long to await a STUN response.
>
> That's reasonable.=C2=A0 I'll propose text as soon as I can la= y my hands on a copy of
> a draft.
>
> >> 2. Consistent number of requests sent without a response (Rc)= before
> >> transaction failure 3. Total time to transaction failure robu= st
> >> against routing transients
> >
> > I don't agree that either of these is a problem.=C2=A0 It'= ;s a design,
> > certainly, but it suffers from a dire lack of determinism in runn= ing
> > time, something that might be exploited to increase denial of ser= vice
> > exposure time.
> >
> > [BA] The effective transmission rate matters in DDOS more than ru= nning
> > time
> > - which is why the RFC 5389 backoff algorithm makes a difference.=
> > Here an Rc value of 7 is not as critical as having it be a consta= nt.
>
> The draft requires at most one check every 4s for a pair and only when=
> consent is active.=C2=A0 ICE sends at 20ms intervals.=C2=A0 Open loop.= =C2=A0 That matters far
> more for DDOS.
>
> >> 1. No RTT/RTO estimation - and given that responses to a requ= est 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.
> >
> > If response i arrives after i+1, that's not going to provide = any
> > useful information about RTO itself (RTO jitter perhaps).
> >
> > [BA] That is true if the transaction ID doesn't change (e.g. = RFC
> > 5389).=C2=A0 But if the transaction ID changes, then you can use = the
> > arrival time of response i to get a better RTO estimate, even if = i+1
> > arrives first. This is valuable since it is most likely to happen= when
> > the originally calculated RTO value is too low, making a false > > retransmission timeout more likely.=C2=A0 RFC 5682 describes some= of the
> concerns relating to F-RTO.
>
> Sure, but I don't think that we *need* that level of sophisticatio= n.
> There's nothing stopping an implementation from doing smarter thin= gs, but
> we are only looking to ensure that consent doesn't persist indefin= itely.
>
> > [BA] Varying Rc will produce a false retransmission probability t= hat
> > will vary by network conditions, particularly if Rc can be small = (e.g.
> > only a few retransmissions prior to declaring consent revocation)= .
>
> See above regarding unnecessary sophistication.
>
> >> 3. Unclear timer behavior.=C2=A0 Does an implementation conti= nue 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?=C2= =A0 One could
> >> interpret the above to imply that requests continue to be sen= t for up
> >> to 30 seconds, but the last request is considered failed as s= oon as
> >> the 30 second timer expires.
> >
> > How can we make this clearer?
> >
> > [BA] If consent expires at 30 seconds + RTO (or better, at last > > request sending time plus RTO) then that would clarify things. >
> I can see where you are coming from here.=C2=A0 I think that we need a= different fix,
> if anything.
>
> 1. STUN requests are sent at a regular interval (with variance).
> 2. Each STUN request is tracked for RTO+delta.
> 3. If a successful STUN response has been received in the last 30 seco= nds, you
> have consent.
>
> That is a subtle change, but it would allow for connections with an RT= O
> greater than 30 seconds.=C2=A0 The only actual problem I can detect wi= th the
> current formulation.
>
> > I like that.=C2=A0 Note that "excessive traffic" was in= tended to be in
> > time, not volume.
> >
> > [BA] Why would time matter if consent packets aren't being se= nt (e.g.
> > backoff)?
>
> Let me rephrase.=C2=A0 The mechanism in this draft prevents packets fr= om being
> sent to an unwilling recipient.=C2=A0 It does that by limiting the
> *time* that this can happen.=C2=A0 It does nothing about the *volume*,= either in
> number of packets or number of bytes.=C2=A0 I agree that "excessi= ve" implies the
> latter (and hence think that your proposed text in this regard was goo= d.)
>
> > That's easy, let's just say that this process applies *af= ter* consent
> > has been acquired.=C2=A0 maybe we could move this up to Section 4= :
> >
> > [BA] The question is when consent is acquired. I'd assume tha= t this
> > begins when media starts being sent - which according to RFC 5245= can
> > occur after a successful connectivity check response.=C2=A0 So IC= E isn't necessarily
> complete.
>
> Right.=C2=A0 We can clarify that too.=C2=A0 If only I had a copy of th= e damned draft, I'd
> propose some changes.
>
> > ... is needed to obtain consent to send *on that candidate pair*.=
> >
> > [BA] That part makes sense - but if there is another valid pair, = it
> > should be possible to start sending media on that pair without ha= ving
> > to do an ICE restart.=C2=A0 That is allowed under RFC 5245.
>
> Correct.=C2=A0 We can add that clarification too.

--bcaec53f35efbb3c0d0516af2a8c-- From nobody Fri May 22 10:54: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 7E41B1A8729; Fri, 22 May 2015 10:54:39 -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 Fhhear-Vcv2z; Fri, 22 May 2015 10:54:38 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::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 2E3521A8774; Fri, 22 May 2015 10:54:38 -0700 (PDT) Received: by yked142 with SMTP id d142so8240612yke.3; Fri, 22 May 2015 10:54:37 -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=5qtaVJiooh8i7vdYXmlXMK+5fEiAvM5vffqJnrsvCkA=; b=SMgO12wXScgVO//j+Tn54vUV0zICbuMzGLISp2F8bsSPNumuZt2Tu0L6DOaDu5Yp70 3pmwe+Pri7/fA8bvaMfp+nk0sUuXnpgn5k8YB43c1k+fB26SzaVX0AvOHQSs4agRynpA D73xbxMphpuMkuYunJ8UmdyooW91GPv3RV6pSXE5rRSFZ8Ty+/aJXjd3Fi4kalc4w4ig 5xqPkdNjLpwXScQ6mrc/2PG27Y01UM5vSTnLr4oS6461t5/eBPqrwpuCoyhBbba5zAnY 0x37OqWl8UVHAOhH7NyRsLlt/0R5GQ4vg3sWZrj7M6U66Q9Fi8qY3xdPFkIUVv3jatST x7DA== MIME-Version: 1.0 X-Received: by 10.170.112.18 with SMTP id e18mr5912713ykb.101.1432317277558; Fri, 22 May 2015 10:54:37 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 22 May 2015 10:54:37 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A4785AE60@xmb-rcd-x10.cisco.com> Date: Fri, 22 May 2015 10:54:37 -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: Fri, 22 May 2015 17:54:39 -0000 On 22 May 2015 at 10:40, Bernard Aboba wrote: > [BA] If a STUN request is still being tracked (RTO has not yet expired), > would expiration of the 30 second timer still cause consent to expire? Or > would revocation wait until the RTO timer expires? The latter makes more > sense to me. I think the former is better since it makes the consent window more deterministic. The only consequence there is that an increase in RTO over the course of that 30s interval will increase the probability of failure. If we assume that a client sends every 5s, it should be receiving at 5s intervals too. From nobody Fri May 22 14:31: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 B857E1A88DA for ; Fri, 22 May 2015 14:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HN8l6e6hXpZM for ; Fri, 22 May 2015 14:31:15 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.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 4898D1A88E9 for ; Fri, 22 May 2015 14:31:15 -0700 (PDT) Received: by obbea2 with SMTP id ea2so21882338obb.3 for ; Fri, 22 May 2015 14:31:14 -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=QeQ4SOaH0a6ngc8eTWb5CDFTeLm7azK+hT9beBss6zc=; b=eMnSm5SWFLxY0jSZWeF+d5DD/Ep9Rf6z6O9C86S+hdKeSookegoV2zedB7C/OXMK3u XXIjcM7AlzbnqWC+ve2mkXHBMP4i+9OBEX3ZCgMSRzupipIcaJzsCfCew35TThaCUj+b 5OBhnZvGOzbAVITy+2IrIBJvH6gwtNMfoB2otMxcAQm6JfGGdmOP4T5Ycd0tQvWCJFER /nvY5i7uiOIslM+q5hb91zg07t1cIxTkZEpuw0nmnXHrZULN0RS5HdKGY3bVpXu6HF84 5RMqlPGP8MBs1i1uni0GSUy0ZfBa215Ip8lmqNaMVV9L2jDEvhSXLJ1vme8uU0Pheuv2 8V4Q== X-Gm-Message-State: ALoCoQkcYeCgFz+gNDgCkffCxF43p57ViJEJBpzCNptek/QHOsFxgIzkp54WdkqAJwxVFpuGVNTe X-Received: by 10.202.78.142 with SMTP id c136mr5502918oib.131.1432330274778; Fri, 22 May 2015 14:31:14 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com. [209.85.218.44]) by mx.google.com with ESMTPSA id u141sm2027370oie.8.2015.05.22.14.31.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2015 14:31:10 -0700 (PDT) Received: by oige141 with SMTP id e141so23238446oig.1 for ; Fri, 22 May 2015 14:31:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.190.134 with SMTP id o128mr7838729oif.111.1432330269549; Fri, 22 May 2015 14:31:09 -0700 (PDT) Received: by 10.76.169.36 with HTTP; Fri, 22 May 2015 14:31:09 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A4785AE60@xmb-rcd-x10.cisco.com> Date: Fri, 22 May 2015 23:31:09 +0200 Message-ID: From: Emil Ivov To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113dcceceaf3700516b2607e 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: Fri, 22 May 2015 21:31:16 -0000 --001a113dcceceaf3700516b2607e Content-Type: text/plain; charset=UTF-8 Hey Martin, Taking a step back, could you maybe remind us exactly why we are defining this new sort of a 30 second transaction instead of just using traditional STUN transactions every time our periodic timer fires? I wasn't able to find this here and there's no rationale in the draft. Was it maybe decided at a meeting at some point? Emil On Friday, May 22, 2015, Martin Thomson wrote: > On 22 May 2015 at 10:40, Bernard Aboba > wrote: > > [BA] If a STUN request is still being tracked (RTO has not yet expired), > > would expiration of the 30 second timer still cause consent to expire? > Or > > would revocation wait until the RTO timer expires? The latter makes more > > sense to me. > > I think the former is better since it makes the consent window more > deterministic. The only consequence there is that an increase in RTO > over the course of that 30s interval will increase the probability of > failure. > > If we assume that a client sends every 5s, it should be receiving at > 5s intervals too. > -- sent from my mobile --001a113dcceceaf3700516b2607e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Martin,=C2=A0

Taking a step back, could you maybe re= mind us exactly why we are defining this new sort of a 30 second transactio= n instead of just using traditional=C2=A0STUN transactions every time our p= eriodic timer fires?

I wasn't abl= e to find this here and there's no rationale in the draft. Was it maybe= decided at a meeting at some point?

Emil

O= n Friday, May 22, 2015, Martin Thomson <martin.thomson@gmail.com> wrote:
On 22 May 2015 at 10:40, Bernard Aboba <, 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: Fri, 22 May 2015 21:35:44 -0000 On 22 May 2015 at 14:31, Emil Ivov wrote: > Taking a step back, could you maybe remind us exactly why we are defining > this new sort of a 30 second transaction instead of just using traditional > STUN transactions every time our periodic timer fires? Transactions take too long, they send too many checks, and those checks appear too close together, meaning that they are prone to loss due to routing transients. I think that's it. There's probably more. > I wasn't able to find this here and there's no rationale in the draft. Was > it maybe decided at a meeting at some point? It was, or maybe on list. It's been like this since almost the second or third revision. It's not that common to provide extensive rationale in specifications like this. From nobody Fri May 22 15:23: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 AE7901A8969; Fri, 22 May 2015 15:23:53 -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 qqE3x1TDoGpo; Fri, 22 May 2015 15:23:50 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 9C9461A891B; Fri, 22 May 2015 15:23:50 -0700 (PDT) Received: by ykec202 with SMTP id c202so9980520yke.2; Fri, 22 May 2015 15:23: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=2P9Zj/i/784xS5gL/bYGOwmWAtpu/6x2W1DKj6OgdgY=; b=v8KsmhxSdvghZp+VxEGuxnawpl+K0hGuF1AqT6l3pOE43wbD7Hf6bOJ6Hb5vDJQEOs wOy6dnR5a4oYM7nN08K2p8mcXiivsekWU/bZAG3F6GqTEqVOzT7Y8n1MtxI7MG0WOcEp WkFf+mPByU+hWF9Sh0IkKPW/JD0iuvFdnNJQ56y4EkJmWNioD7q4ueggCghHaEceumaL SAxWOvbNgSWvnC3zFhMq9Xk5VWjpukBMj9IronUdgleDVViT1gD3X/PgdqKRo724pkOK OWRa8BPC55QqqeokX2je4nRFAhkV/r6Y8/QMcIp2HGsyUZ3pug0lGgFZ4h/7ZgEHGIYm LS/A== MIME-Version: 1.0 X-Received: by 10.236.106.74 with SMTP id l50mr10345021yhg.143.1432333429991; Fri, 22 May 2015 15:23:49 -0700 (PDT) Received: by 10.13.247.71 with HTTP; Fri, 22 May 2015 15:23:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 May 2015 15:23:49 -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: Fri, 22 May 2015 22:23:53 -0000 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 > From nobody Sun May 24 13:55:27 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 6F7BA1AD072 for ; Sun, 24 May 2015 13:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 cA9x_B-YkOku for ; Sun, 24 May 2015 13:55:21 -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 CDB5C1AD09A for ; Sun, 24 May 2015 13:55:20 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AF44220894 for ; Sun, 24 May 2015 16:55:19 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 24 May 2015 16:55:19 -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=SK30ZSaGLRSNNlflxlpt6uiZlv8=; b=Qxgz4K sBGYM2kWE4Ns359n7p/5VGTy5T0aaJj+5dXsCRsqHKrPnmEF4kEOa8EyUbVAq83m r3ZpTIkGryRViHmjFkkw47PI5Tf4iSYuL2vviMnbLPKfUvdfuVhHFxVwL/1N4/JT ZrESb/Airb3PKsA7aW58VS6Nrn9j9b3sa19uI= 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=SK30ZSaGLRSNNlf lxlpt6uiZlv8=; b=qP1wvsnn0fcSIQ3lBA/b0TN4j3+/Fz6O5btXpJ2zUwv2TLm NgWQnRoHxAcvU1z6+ID38Q5jeePOCKsIwz2O2YzBc2KGpEnmE0+UkktVCHGPcoRZ Tc/XoCNQ286lWNC8Er4QbpJlCyNXS+aD4jatTvQfAGy9N/1LNM+6ZvVyc8jg= X-Sasl-enc: k5DQ0+NDG3cy8ftKLyUbQlFzumhNeGDsdYdFY94xCkkn 1432500919 Received: from sjc-alcoop-8814.cisco.com (unknown [128.107.241.181]) by mail.messagingengine.com (Postfix) with ESMTPA id 8A46C6800C3; Sun, 24 May 2015 16:55:18 -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: <555CC520.7010800@ericsson.com> Date: Sun, 24 May 2015 13:56:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in> <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org> <555CC520.7010800@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] AD evaluation: 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: Sun, 24 May 2015 20:55:25 -0000 Thanks to both of you for your responses. Some comments in-line. If you = can make these changes and rev the draft that would be great. On May 20, 2015, at 10:32 AM, Magnus Westerlund = wrote: > Hi, >=20 > Some additional comments on this. I have removed the parts where there = appear to be agreement and no open issues. >=20 > Colin Perkins skrev den 2015-05-17 14:00: >>> On 14 May 2015, at 00:58, Alissa Cooper wrote: >>=20 >>> =3D=3D Section 11: >>>=20 >>> "Note: this doesn't result in a tracking issue, since the creation >>> of matching CNAMEs depends on existing tracking." >>>=20 >>> I don't quite get this note. Is this trying to say that using the >>> same CNAME in this case does not facilitate cross-service tracking >>> because the CNAME re-use only occurs within a single origin? >>=20 >> That's part of it. Also, that using the same CNAME for several >> streams that are part of a single call is okay, and indeed needed for >> lip-sync, since there are other ways of telling that these streams >> are part of the same call. >=20 > Yes, it really is a matter that this stays within an origin and the = binding if needed would be exposed anyway. I think the text will be a = bit clearer with the minor tweak at the end to clarify that is really is = within one origin. >=20 > "Note: this doesn't result in a tracking issue, since the creation of = matching CNAMEs depends on existing tracking within a single origin.=94 WFM >=20 >>=20 >>> =3D=3D Section 12.1.3: >>>=20 >>> "When flow- based differentiation is available, the WebRTC Endpoint >>> needs to know about it so that it can provide the separation of the >>> RTP packet streams onto different UDP flows to enable a more >>> granular usage of flow based differentiation." >>>=20 >>> I feel like this needs a bit more explanation since I assume it's >>> not terribly commonplace for an endpoint to be able to find out >>> that flow-based differentiation is taking place. Is there some >>> mechanism you can point to that provides this information in some >>> cases, or is this basically saying "wouldn't it be nice if >>> endpoints could find this out somehow"? >>=20 >> We could say "The use of flow-based differentiation needs to be >> signalled to the WebRTC Endpoint, so it knows to provide the >> separation..."? The point is that the endpoint can't enable this >> without being told that it' so be used, and what parameters are to be >> used. >=20 > Yes, this is better formulation. My understanding is that so far, = there need to be some out-of-band coordination between the network = provider and the WebRTC based service that uses the network = prioritization. I think it would help to indicate that out-of-band coordination is = needed. >=20 >>=20 >>> =3D >>>=20 >>> I note that there is discussion of how DiffServ and flow-based >>> classification might work for RTP traffic in the WebRTC context, >>> but not DPI. Is there anything to be said, in particular given the >>> SRTP requirement? >=20 > Actually, I think you are at least partly wrong. A DPI can despite = SRTP with encryption actually do quite significant classification due to = the information exposed. First of all SRTP exposes the first 12 bytes of = the RTP packet. Thus the SSRC is available, enabling RTP stream level = tracking. This can then be used with RTP packet frequency and size = analysis to determine which RTP streams are audio and which are video = for example. Thus enabling such prioritization. The API level priorities = are not exposed, so it can't take that into account unless they are = exposed in the DSCP field. I think this context would be a helpful addition for less familiar = readers. >=20 >>=20 >> I'm happy to add some text, if you have any suggestions. >=20 > Yes, I would like to have some indication from people who don't know = this in and out to what appears necessary here. >=20 >>=20 >>> =3D=3D Section 13: >>>=20 >>> "The use of the encryption of the header extensions are >>> RECOMMENDED, unless there are known reasons, like RTP middleboxes >>> or third party monitoring that will greatly benefit from the >>> information, and this has been expressed using API or signalling. >>> If further evidence are produced to show that information leakage >>> is significant from audio level indications, then use of >>> encryption needs to be mandated at that time." >>>=20 >>> I'm not sure that "known reasons" are quite enough to justify the >>> SHOULD-level requirement here. It would help if you could elaborate >>> specific legitimate use cases where a middlebox or a specific kind >>> of third party makes use of the audio level information and how >>> that information provides a great benefit. >>=20 >> The issue is that middle boxes use the audio level information in the >> header extensions to perform voice activity-based source switching. >> Sending audio level information in the header extension is preferable >> to trusting the middle box with access to the media. We can add some >> words to explain this further, and perhaps a pointer to the PERC >> working group, if chartered? >=20 > I suggest that we make the RTP middlebox usage clearer: >=20 > The use of the encryption of the header extensions are RECOMMENDED, = unless there are known reasons, like RTP middleboxes performing voice = activity based source selection or third party monitoring that will = greatly benefit from the information, and this has been expressed using = API or signaling. This is better, thanks. I don=92t think including a PERC pointer is = necessary at this point since that work is quite nascent. Alissa >=20 >=20 >=20 >>=20 >>> =3D=3D Section 16: draft-ietf-mmusic-sdp-bundle-negotiation should = not >>> be listed as an informative reference. >>=20 >> Why not? >=20 > Because we actually have normative inclusion of its header extension = in Section 4.1: >=20 > Such endpoints MUST implement the RTCP SDES MID item > described in [I-D.ietf-mmusic-sdp-bundle-negotiation]. >=20 > We actually had it listed as both a normative and informative = reference. I will remove the informative listing. Yep, thanks. >=20 > Cheers >=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 From nobody Mon May 25 06:34: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 B071B1A8A8C for ; Mon, 25 May 2015 06:34:56 -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 Pzv0d5UvX6cx for ; Mon, 25 May 2015 06:34:52 -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 0E7FC1A8A7F for ; Mon, 25 May 2015 06:34:51 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-69-556324f95a8b Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5E.0A.04401.9F423655; Mon, 25 May 2015 15:34:50 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Mon, 25 May 2015 15:34:49 +0200 Message-ID: <556324F8.1080008@ericsson.com> Date: Mon, 25 May 2015 15:34:48 +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: <3099D1C3-005C-4C14-AF0E-D9A79164467F@cooperw.in> <62EF47FC-0298-4FCC-A7C4-59C4A75EC717@csperkins.org> <555CC520.7010800@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvre4vleRQg6+XuSymn/nLaLH85QlG i7X/2tkdmD2+PHnJ5DHt/n02jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcxf+ZC5YI1axbXln9gb GFvluxg5OSQETCSun53PBmGLSVy4tx7I5uIQEjjKKDGxZQo7hLOcUWLa98UsIFW8AtoSM+6v Yexi5OBgEVCVWHkgFiTMJmAhcfNHI9ggUYEoiamP10GVC0qcnPkEzBYBKr967AdYDbOAl8Tz nTsYQWxhAWeJnp2vWSF2HWGUWHH9GVgRp4CdxK7dT9lBdjEL2Es82FoG0Ssv0bx1NjOILQR0 TkNTB+sERsFZSNbNQuiYhaRjASPzKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAAD645bfq DsbLbxwPMQpwMCrx8Co2JYUKsSaWFVfmHmKU5mBREuf17AoJFRJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cAoqzyXqedc3WyVzadXTE3W+Nztt/iq7d/u68GZxxq9LofOE7qe9LDuZ+vTpXeb epeYaT31CHx7jNlv2ykOmSXRq1j2cNmJq/K3lXy3etC/pF20b/LDam1tngesYlcPuL0Xign8 fdbSz4XVLe+d0rnZ0XrTDHtb1rn9kzy1WSVa4FjFtf1b5F4osRRnJBpqMRcVJwIAUm9d9kEC AAA= Archived-At: Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] AD evaluation: 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: Mon, 25 May 2015 13:34:56 -0000 Hi, some comments and suggested text based on your feedback. I think we should await the expiration of the IETF last call deadline on Thursday before submitting an update. Alissa Cooper skrev den 2015-05-24 22:56: > Thanks to both of you for your responses. Some comments in-line. If > you can make these changes and rev the draft that would be great. > > On May 20, 2015, at 10:32 AM, Magnus Westerlund > wrote: > [snip] >> >>> >>>> == Section 12.1.3: >>>> >>>> "When flow- based differentiation is available, the WebRTC >>>> Endpoint needs to know about it so that it can provide the >>>> separation of the RTP packet streams onto different UDP flows >>>> to enable a more granular usage of flow based >>>> differentiation." >>>> >>>> I feel like this needs a bit more explanation since I assume >>>> it's not terribly commonplace for an endpoint to be able to >>>> find out that flow-based differentiation is taking place. Is >>>> there some mechanism you can point to that provides this >>>> information in some cases, or is this basically saying >>>> "wouldn't it be nice if endpoints could find this out >>>> somehow"? >>> >>> We could say "The use of flow-based differentiation needs to be >>> signalled to the WebRTC Endpoint, so it knows to provide the >>> separation..."? The point is that the endpoint can't enable this >>> without being told that it' so be used, and what parameters are >>> to be used. >> >> Yes, this is better formulation. My understanding is that so far, >> there need to be some out-of-band coordination between the network >> provider and the WebRTC based service that uses the network >> prioritization. > > I think it would help to indicate that out-of-band coordination is > needed. Okay, I have attempted to reword the paragraph so that it now reads: Flow-based differentiation will provide the same treatment to all packets within a transport-layer flow, i.e., relative prioritization is not possible. Moreover, if the resources are limited it might not be possible to provide differential treatment compared to best-effort for all the RTP packet streams used in a WebRTC session. The use of flow-based differentiation needs to be coordinated between the WebRTC system and the network(s). The WebRTC endpoint must know that flow-based differentiation may be used to provide the separation of the RTP packet streams onto different UDP flows to enable a more granular usage of flow based differentiation. The used flows, their 5-tuples and prioritization will need to be communicated to the network so that it can identify the flows correctly to enable prioritization. No specific protocol support for this is specified. > >> >>> >>>> = >>>> >>>> I note that there is discussion of how DiffServ and flow-based >>>> classification might work for RTP traffic in the WebRTC >>>> context, but not DPI. Is there anything to be said, in >>>> particular given the SRTP requirement? >> >> Actually, I think you are at least partly wrong. A DPI can despite >> SRTP with encryption actually do quite significant classification >> due to the information exposed. First of all SRTP exposes the first >> 12 bytes of the RTP packet. Thus the SSRC is available, enabling >> RTP stream level tracking. This can then be used with RTP packet >> frequency and size analysis to determine which RTP streams are >> audio and which are video for example. Thus enabling such >> prioritization. The API level priorities are not exposed, so it >> can't take that into account unless they are exposed in the DSCP >> field. > > I think this context would be a helpful addition for less familiar > readers. Okay, then I propose we add the following paragraph before the second last paragraph in the section: Deep Packet Inspectors will, despite the SRTP media encryption, still be fairly capable at classifying the RTP streams. The reason is that SRTP leaves the first 12 bytes of the RTP header unencrypted. This enables easy RTP stream identification using the SSRC and provides the classifier with useful information that can be correlated to determine for example the stream's media type. Using packet sizes, reception times, packet inter-spacing, RTP timestamp increments and sequence numbers, fairly reliable classifications are achieved. 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 May 26 13:33: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 C0E5B1B313F for ; Tue, 26 May 2015 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.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, 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 IslmqoEoeHqv for ; Tue, 26 May 2015 13:33:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3901B3138 for ; Tue, 26 May 2015 13:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=896; q=dns/txt; s=iport; t=1432672417; x=1433882017; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z80ndV/MZqVG81V9c74IGp1ezxWCSKYRJylHsCnNieA=; b=FGxb2h7OHa7Pg99xSdMQ9Ac1hpTyz1i1EMRVUwT8fRwAAuV/GdQRhFww m1OhMyo6hsU4IA3tbN7opEsdNr6hsYUSZco4fc+8IqZ0u/VsgOZOTnH/3 Rku7K39K/JrAbmsBYkIa0s5dszw9U9LHCLNkEeuCQCtyx7TqLg7r8DIn8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQBY2GRV/4cNJK1cgxCBMgbLBAKBSUwBAQEBAQGBC4QiAQEBAwE6PwULAgEIGB4QIRElAgQBDQWIFwMKCMYdDYRwAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6gk2BaRwzB4MXgRYBBJMIiTaBWZAshwMjg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,501,1427760000"; d="scan'208";a="422767864" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 26 May 2015 20:33:21 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4QKXLSO017871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 May 2015 20:33:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 26 May 2015 15:33:21 -0500 From: "Cullen Jennings (fluffy)" To: Martin Thomson , Justin Uberti Thread-Topic: [rtcweb] Open Security issue: Crypto algorithms Thread-Index: AQHQl/M0tKGTckfL50yoPV3DPTsARQ== Date: Tue, 26 May 2015 20:33:20 +0000 Message-ID: References: <5549E480.4030806@alvestrand.no> <0FEF3981-063C-450C-9E6A-685696B4F5E0@ieca.com> In-Reply-To: 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: <62C9A9230634CC40B08B73BA24FE98E9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:33:38 -0000 > On May 21, 2015, at 11:03 AM, Martin Thomson w= rote: >=20 > On 21 May 2015 at 09:39, Justin Uberti wrote: >>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >=20 > This would be my preference for a MUST. I looked into the the issue with backwards compat with gateways / servers. = It seems that most the stuff I could find claimed Suite B compliance or was= based on recent version of openssl - either way, I'm not seeing a problem = with making=20 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 MTI.=20 I agree it has advantage for low power stuff. I think the IoT people that w= ant to use the WebRTC data channel would be much happier with no RSA (or to= put it a bit more concretely, I doubt they will put both EC and RSA on ver= y small stuff regardless of what our specs require and they seem to be most= ly going EC not RSA).=20 From nobody Tue May 26 13:35: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 09CE61B3146 for ; Tue, 26 May 2015 13:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 xkSfeUf3MUHw for ; Tue, 26 May 2015 13:35:04 -0700 (PDT) Received: from gateway33.websitewelcome.com (gateway33.websitewelcome.com [192.185.145.239]) (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 63F2A1B3138 for ; Tue, 26 May 2015 13:35:04 -0700 (PDT) Received: by gateway33.websitewelcome.com (Postfix, from userid 500) id AA6BB19704816; Tue, 26 May 2015 15:35:03 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 9890D197047F1 for ; Tue, 26 May 2015 15:35:03 -0500 (CDT) Received: from [173.73.121.66] (port=50672 helo=[192.168.1.6]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YxLZ0-00054q-VZ for rtcweb@ietf.org; Tue, 26 May 2015 15:35:03 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <39169098.225023.1432223711277.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker2.doodle.com> Date: Tue, 26 May 2015 16:35:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D73B422-1F4D-4ACC-8F0E-5B7B3ED2BEEB@ieca.com> References: <39169098.225023.1432223711277.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker2.doodle.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: 173.73.121.66 X-Exim-ID: 1YxLZ0-00054q-VZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.6]) [173.73.121.66]:50672 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [rtcweb] RTCweb June 18th Virtual Interim Meeting - JSEP-focused X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:35:06 -0000 This is a reminder about the doodle poll. spt On May 21, 2015, at 11:55, Sean Turner (via Doodle) = wrote: > =09 > Hi there, > =20 > Sean Turner (turners@ieca.com) invites you to participate in the = Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." > This doodle poll will help us determine a time for the JSEP-focused = RTCweb WG Interim Meeting to be held on June 18th. See the following = link for more information: = http://www.ietf.org/mail-archive/web/rtcweb/current/msg14632.html. > Participate now =09 > =09 > What is Doodle? Doodle is a web service that helps Sean Turner to find = a suitable date for meeting with a group of people. Learn more about how = Doodle works. > You have received this e-mail because "Sean Turner" has invited you to = participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeting = - JSEP-focused." > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue May 26 13:58: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 0589C1B315F for ; Tue, 26 May 2015 13:58: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 XdWMZqfqmHzR for ; Tue, 26 May 2015 13:58:37 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9991B3143 for ; Tue, 26 May 2015 13:58:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A210E7C0570; Tue, 26 May 2015 22:58:36 +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 u-jKLz2XCVch; Tue, 26 May 2015 22:58:35 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:e848:f29f:b6b:9231] (unknown [IPv6:2001:470:de0a:27:e848:f29f:b6b:9231]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1CD827C054F; Tue, 26 May 2015 22:58:35 +0200 (CEST) Message-ID: <5564DE7A.70503@alvestrand.no> Date: Tue, 26 May 2015 22:58:34 +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: Sean Turner , rtcweb@ietf.org References: <39169098.225023.1432223711277.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker2.doodle.com> <8D73B422-1F4D-4ACC-8F0E-5B7B3ED2BEEB@ieca.com> In-Reply-To: <8D73B422-1F4D-4ACC-8F0E-5B7B3ED2BEEB@ieca.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] RTCweb June 18th Virtual Interim Meeting - JSEP-focused X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:58:40 -0000 Den 26. mai 2015 22:35, skrev Sean Turner: > This is a reminder about the doodle poll. But ..... where's the link to the Doodle poll? > > spt > > On May 21, 2015, at 11:55, Sean Turner (via Doodle) wrote: > >> >> Hi there, >> >> Sean Turner (turners@ieca.com) invites you to participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." >> This doodle poll will help us determine a time for the JSEP-focused RTCweb WG Interim Meeting to be held on June 18th. See the following link for more information: http://www.ietf.org/mail-archive/web/rtcweb/current/msg14632.html. >> Participate now >> >> What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date for meeting with a group of people. Learn more about how Doodle works. >> You have received this e-mail because "Sean Turner" has invited you to participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue May 26 13:59: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 70CD51B3181 for ; Tue, 26 May 2015 13:59:47 -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 k4mjGDSI81uB for ; Tue, 26 May 2015 13:59:46 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 069E91B317B for ; Tue, 26 May 2015 13:59:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4EC207C0570 for ; Tue, 26 May 2015 22:59:45 +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 Kzv96irX8ajH for ; Tue, 26 May 2015 22:59:44 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:e848:f29f:b6b:9231] (unknown [IPv6:2001:470:de0a:27:e848:f29f:b6b:9231]) by mork.alvestrand.no (Postfix) with ESMTPSA id DF9E17C054F for ; Tue, 26 May 2015 22:59:43 +0200 (CEST) Message-ID: <5564DEBF.9090906@alvestrand.no> Date: Tue, 26 May 2015 22:59:43 +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: <39169098.225023.1432223711277.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker2.doodle.com> <8D73B422-1F4D-4ACC-8F0E-5B7B3ED2BEEB@ieca.com> <5564DE7A.70503@alvestrand.no> In-Reply-To: <5564DE7A.70503@alvestrand.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] RTCweb June 18th Virtual Interim Meeting - JSEP-focused X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:59:47 -0000 Den 26. mai 2015 22:58, skrev Harald Alvestrand: > Den 26. mai 2015 22:35, skrev Sean Turner: >> This is a reminder about the doodle poll. > > > But ..... where's the link to the Doodle poll? Answering my own mail - it was in the HTML of the original message, and got stripped out by the "quote" function. http://doodle.com/pbckxc56dvr64h8n > >> >> spt >> >> On May 21, 2015, at 11:55, Sean Turner (via Doodle) wrote: >> >>> >>> Hi there, >>> >>> Sean Turner (turners@ieca.com) invites you to participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." >>> This doodle poll will help us determine a time for the JSEP-focused RTCweb WG Interim Meeting to be held on June 18th. See the following link for more information: http://www.ietf.org/mail-archive/web/rtcweb/current/msg14632.html. >>> Participate now >>> >>> What is Doodle? Doodle is a web service that helps Sean Turner to find a suitable date for meeting with a group of people. Learn more about how Doodle works. >>> You have received this e-mail because "Sean Turner" has invited you to participate in the Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue May 26 14:01: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 92D021B317B for ; Tue, 26 May 2015 14:01:34 -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 mCsumwzAB5KV for ; Tue, 26 May 2015 14:01:33 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.185.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657161B3174 for ; Tue, 26 May 2015 14:01:33 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id A9123D107E4D8; Tue, 26 May 2015 16:01:32 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 9A4B5D107E4A5 for ; Tue, 26 May 2015 16:01:32 -0500 (CDT) Received: from [173.73.121.66] (port=51388 helo=[192.168.1.6]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YxLyd-0007nn-WD; Tue, 26 May 2015 16:01:32 -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: <5564DE7A.70503@alvestrand.no> Date: Tue, 26 May 2015 17:01:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8ACFDAF5-25B4-447F-8EE5-6DAA61644A0C@ieca.com> References: <39169098.225023.1432223711277.POLL_INVITECONTACT_PARTICIPANT_INVITATION_WITH_MESSAGE@worker2.doodle.com> <8D73B422-1F4D-4ACC-8F0E-5B7B3ED2BEEB@ieca.com> <5564DE7A.70503@alvestrand.no> 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: 173.73.121.66 X-Exim-ID: 1YxLyd-0007nn-WD X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.6]) [173.73.121.66]:51388 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: Re: [rtcweb] RTCweb June 18th Virtual Interim Meeting - JSEP-focused X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:01:34 -0000 That would be useful to add wouldn=92t it :) http://doodle.com/pbckxc56dvr64h8n spt On May 26, 2015, at 16:58, Harald Alvestrand = wrote: > Den 26. mai 2015 22:35, skrev Sean Turner: >> This is a reminder about the doodle poll. >=20 >=20 > But ..... where's the link to the Doodle poll? >=20 >>=20 >> spt >>=20 >> On May 21, 2015, at 11:55, Sean Turner (via Doodle) = wrote: >>=20 >>> =09 >>> Hi there, >>>=20 >>> Sean Turner (turners@ieca.com) invites you to participate in the = Doodle poll "RTCweb June 18th Virtual Interim Meeting - JSEP-focused." >>> This doodle poll will help us determine a time for the JSEP-focused = RTCweb WG Interim Meeting to be held on June 18th. See the following = link for more information: = http://www.ietf.org/mail-archive/web/rtcweb/current/msg14632.html. >>> Participate now =09 >>> =09 >>> What is Doodle? Doodle is a web service that helps Sean Turner to = find a suitable date for meeting with a group of people. Learn more = about how Doodle works. >>> You have received this e-mail because "Sean Turner" has invited you = to participate in the Doodle poll "RTCweb June 18th Virtual Interim = Meeting - JSEP-focused." >>> _______________________________________________ >>> 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 Tue May 26 14:40:33 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 433841B31C0 for ; Tue, 26 May 2015 14:40:32 -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 sQwuGIU5Exrm for ; Tue, 26 May 2015 14:40:31 -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 CCDF81A8ACB for ; Tue, 26 May 2015 14:40:30 -0700 (PDT) Received: by yhom41 with SMTP id m41so34610523yho.1 for ; Tue, 26 May 2015 14:40:30 -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=vsfVuMkpjCU5LZIN9PhXLf5Of/vR65/G/g1O4+Z5h5U=; b=D2+vmnEB0e/V/mnRNP0HC4A6TOdv5LAu6jB9vSoWpXbzuWSUCMF4h6VcLAM6P3u/ea EfZ1ngL+gY94+0C0mdy8OUvb3ejBRBuuKigyni34BTzzJKofF5ilHix95jX+AY60APVh ljHVuwnZFI9cWZk4V4pj3VYXTmeHAHSIc8fD99TVlL+TDYZ3wUhmd6UpBZgoqlY1rh0M DOFUAgRDN/iOy/n0sseW7ySxuRwaqlYp0x1LnUO34n9RpCQZkxLxuDWIBzEjLAXhjQfO 60cUDKjnKzU3r6pyMHcd8ZjGACfr5LN6hgk/VdCfbdjEDg/XybIukP7jSMBlxfgVPiMS 6ZkA== MIME-Version: 1.0 X-Received: by 10.170.121.214 with SMTP id n205mr28967435ykb.98.1432676430229; Tue, 26 May 2015 14:40:30 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 26 May 2015 14:40:30 -0700 (PDT) In-Reply-To: References: <5549E480.4030806@alvestrand.no> <0FEF3981-063C-450C-9E6A-685696B4F5E0@ieca.com> Date: Tue, 26 May 2015 14:40:30 -0700 Message-ID: From: Martin Thomson To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Open Security issue: Crypto algorithms X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:40:32 -0000 On 26 May 2015 at 13:33, Cullen Jennings (fluffy) wrote: > I'm not seeing a problem with making > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 MTI. Thanks for doing the checking. If we can agree on this, then I'd be quite happy. p.s., Everyone is welcome to contact me privately if you want a Firefox build that does ECDSA only if you want to test for compatibility with your software. From nobody Wed May 27 00:17:59 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 97B2F1A8854; Wed, 27 May 2015 00:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 G7rLVen20cZS; Wed, 27 May 2015 00:17:47 -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 86F521A8853; Wed, 27 May 2015 00:17:46 -0700 (PDT) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4R7HaOd004812 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 May 2015 03:17:39 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t4R7HaOd004812 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1432711059; bh=HadnoJmDs6lj4hzZXJkyKmHM7fg=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=fa7VCyDPpdLoa+y4oHm7nvbfKotQcxGj0QTNUH+/YbJ6xbO7fj1KLDSaABPgbkHv6 Qp+uAVJ8Th4SGO9kPdH9MhCPXqLxnCGjsb6pPeNo0aqkBqlU0mRRJIMNqyzWIJQ+Vr ogySzz2ae0qo6uqKgTIjFvO1mdBjTvwWXdw50714= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t4R7HaOd004812 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 27 May 2015 03:17:02 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4R7HLSF001344 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 03:17:22 -0400 Received: from MXHUB206.corp.emc.com (10.253.68.32) by mxhub05.corp.emc.com (128.222.70.202) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 27 May 2015 03:17:21 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.77]) by MXHUB206.corp.emc.com ([10.253.68.32]) with mapi id 14.03.0224.002; Wed, 27 May 2015 03:17:21 -0400 From: "Black, David" To: "Ram Mohan R (rmohanr)" , joel jaeggli , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "Tirumaleswar Reddy (tireddy)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQ== Date: Wed, 27 May 2015 07:17:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.56.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "Black, David" 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: Wed, 27 May 2015 07:17:54 -0000 I'll limit comments here to the two major issues. Quick summary: [1] Applicability: The proposed text looks generally good, but the definiti= on of "consent" needs a couple of clarifications. [2] Security Considerations: The proposed text isn't sufficient. In additi= on to the new applicability text's reference to the WebRTC security architecture draft, a reference to the WebRTC security considerations draft with specific section pointers needs to be added to the security considerations section of this draft. > >> [1] The draft seems to be missing discussion of applicability - what > >> environments and/or protocols is this mechanism intended for or applic= able > >> to? > We will add a new section =B3Applicability=B2 after the introduction sect= ion. I think that proposed applicability section will address most of the concer= n. As part of this, the definition of consent (Section 2) needs elaboration: Consent: The mechanism of obtaining permission to send to a remote transport address. Initial consent is obtained using ICE. Two important concepts should be clearer: - Permission to send is obtained *from the recipient* of the traffic. - The traffic to which permission to send applies is *non-ICE* traffic. > >> [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 shoul= d > >> be a discussion of how and why replays of previous consent responses > >> are harmless (will be ignored by the recipient). >=20 > Cryptographically strong STUN transaction IDs are required so that > off-path attacker does not replay old consent responses. >=20 >=20 >=20 > >>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 > We will add the following line to Security Considerations section. > > NEW: >=20 > Consent requires 96 bits transaction ID to be uniformly and randomly > chosen from the interval 0 .. 2**96-1, and be cryptographically strong. > This is good enough security against an off-path attacker replaying old > STUN consent responses. That's good, but the actual problem is a missing reference. The rationale discussion is in draft-ietf-rtcweb-security, so that draft needs to be adde= d as a normative reference, plus text added to the security considerations section of this consent draft to call attention to sections 3.3 and 4.2 of that rtcweb-security draft. This is in addition to the citation of section= s 4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new applicability text. Thanks, --David > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Tuesday, May 19, 2015 11:28 AM > To: joel jaeggli; Black, David; muthu.arul@gmail.com; Dan Wing (dwing); > Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops-dir@ietf.org; > rtcweb@ietf.org > Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-1= 3 >=20 > Hi David/Joel, >=20 > Please see inline for my responses. >=20 >=20 > -----Original Message----- > From: joel jaeggli > Date: Friday, 15 May 2015 4:59 am > To: "Black, David" , "muthu.arul@gmail.com" > , "dwing@cisco.com" , Cisco > Employee , "tireddy@cisco.com" , > "martin.thomson@gmail.com" , "ops-dir@ietf.org" > > Cc: "rtcweb@ietf.org" , "ietf@ietf.org" > Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-1= 3 >=20 > >Thanks David, > > > >I'll be looking with interest for the addressing of items 1/2. > > > >joel > > > >On 5/14/15 4:21 PM, Black, David wrote: > >> I have reviewed this document as part of the Operational directorate's > >> ongoing effort to review all IETF documents being processed by the IES= G. > >> These comments were written with the intent of improving the operation= al > >> aspects of the IETF drafts. Comments that are not addressed in last ca= ll > >> may be included in AD reviews during the IESG review. Document editor= s > >> and WG chairs should treat these comments just like any other last cal= l > >> 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 nonce= s > >> 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 applic= able > >> to? Is this generally applicable wherever ICE and STUN are used? I d= on't > >> see any RFCs listed as updated by this draft, so I'm guessing that thi= s > >> 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 > This document defines what it takes to obtain, maintain, and lose > consent to send using ICE. This draft does not restrict on what > applications should use > Consent. Currently on webRTC applications use Consent, however any other > application that has > Similar security requirements can use this mechanism. We will add a new > section =B3Applicability=B2 > after the introduction section. >=20 > > 2. Applicability >=20 > This document defines what it takes to obtain, maintain, and lose consent > to send using ICE.Verification of peer consent before sending traffic is > necessary in deployments like WebRTC to ensure that a malicious JavaScrip= t > cannot use the browser as a platform for launching attacks.Section 4.4 an= d > section 5.3 of [I-D.ietf-rtcweb-security-arch] explains why webRTC > application needs consent. >=20 > Other Applications that have similar security requirement where it is > required to verify peer's consent before sending non-ICE packets can use > the consent mechanism described in this draft. >=20 >=20 > >=20 >=20 > Also we will modify para 3 of Intro to make it clearer. >=20 > OLD: > This document defines what it takes to obtain, maintain, and lose > consent to send. Consent to send applies to a single 5-tuple. How > applications react to changes in consent is not described in this > document. >=20 >=20 >=20 > NEW: > This document defines what it takes to obtain, maintain, and lose consent > to send. Consent > to send applies to a single 5-tuple. How applications react to changes > in consent is not > described in this document. The consent mechanism does not update the > ICE procedures > defined in [RFC 5245]. >=20 >=20 >=20 >=20 >=20 >=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 shoul= d > >> be a discussion of how and why replays of previous consent responses > >> are harmless (will be ignored by the recipient). >=20 > Cryptographically strong STUN transaction IDs are required so that > off-path attacker does not replay old consent responses. >=20 >=20 >=20 > >>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 > We will add the following line to Security Considerations section. >=20 > NEW: >=20 > Consent requires 96 bits transaction ID to be uniformly and randomly > chosen from the interval 0 .. 2**96-1, and be cryptographically strong. > This is good enough security against an off-path attacker replaying old > STUN consent responses. >=20 >=20 >=20 > >> > >> -- Minor Issues -- > >> > >> [3] In Section 1, please explain what ICE-lite is. A suitable referen= ce > >> should suffice. >=20 > Yes we will add reference to RFC5245 that describes ICE-lite >=20 >=20 >=20 > >> > >> [4] In Section 4.1, please explain or provide a reference for what > >>"paced" > >> means in "paced STUN connectivity checks or responses." >=20 > Pacing is explained in the same section below. Let us know if this is not > sufficient/not clear. > > 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. > >=20 >=20 >=20 > >> > >> -- 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. >=20 > Okay, will move this paragraph to Section 3. >=20 >=20 >=20 > >> > >> idnits 2.13.02 found an unused reference: > >> > >> =3D=3D Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on li= ne > >>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). >=20 > This reference is not needed. Once we add applicability section we will > reference rtcweb-security-arch draft. >=20 > >> > >> --- 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; ordina= ry > >> 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 th= e > >>draft, > >> but would be useful to state explicitly. >=20 > We will add a new applicability section proposed above and also modified > para 3 of Intro to make it clearer that this draft does not change ICE > procedures. Please let us know if this solves the comment above. >=20 >=20 > >> [A.1.1 - deployment] > >> > >> The mechanism has been defined to limit the amount of added traffic an= d > >>to > >> shut down unwanted traffic, plus contains a facility to desynchronize > >> independent users of this protocol. Some rationale should be added fo= r > >> the choice of the 30 second timeout period. >=20 > 30 second timeout period was selected so that consent checks could be sen= t > between 7 to 5 times (to handle packet loss). >=20 >=20 > >> [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 t= he > >> 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 an= d > >>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. >=20 > We specifically discussed in WG about how applications should handle > changes in Consent and it was decided to keep it outside the scope of thi= s > draft. Para 3 of introduction already has a text that says the same. > There can be many possibilities if consent is lost or failed depending on > what the application wants. >=20 >=20 > >> [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 server= s > >>and > >> related networks than clients. [A.2.2 - management information, A.2.3 = - > >>fault > >> management]. >=20 > This again seems some thing outside the scope of this draft as it is > trying to specify application behavior. Is there some thing that you want > us to add in the draft for this? >=20 > Regards, > Ram >=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 > >>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 01748 > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > >> david.black@emc.com Mobile: +1 (978) 394-7754 > >> ---------------------------------------------------- > >> > >> > >> > > > > From nobody Wed May 27 12:22: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 176451A90A5 for ; Wed, 27 May 2015 12:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Bn3zTLRMfrHr for ; Wed, 27 May 2015 12:22:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (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 D49F11A909D for ; Wed, 27 May 2015 12:22:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.15.1/8.15.1) with ESMTPS id t4RJMFeu027342 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 May 2015 19:22:15 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t4RJMBmP017009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 21:22:14 +0200 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 27 May 2015 21:22:11 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.28]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0235.001; Wed, 27 May 2015 21:22:10 +0200 From: "Rauschenbach, Uwe (Nokia - DE/Munich)" To: "ext Hutton, Andrew" , Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: rtcweb-gateways- Statis IP Address Comment Thread-Index: AQHQgx/q7KWF0Xdw9kyt1tqhlfwnMp2QXTqg Date: Wed, 27 May 2015 19:22:10 +0000 Message-ID: <56C2F665D49E0341B9DF5938005ACDF81968336D@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> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E7547BD@MCHP04MSX.global-ad.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1203 X-purgate-ID: 151667::1432754535-00006C8C-D29D9B47/0/0 Archived-At: 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, 27 May 2015 19:22:26 -0000 Hi Andy, Fair comment - this will be addressed in the version I upload as adopted. Kind regards, Uwe -----Original Message----- From: ext Hutton, Andrew [mailto:andrew.hutton@unify.com]=20 Sent: Thursday, April 30, 2015 10:30 AM To: Harald Alvestrand; Rauschenbach, Uwe (Nokia - DE/Munich); rtcweb@ietf.o= rg Subject: rtcweb-gateways- Statis IP Address Comment Section 2 contains the following text: "Since a gateway is expected to be deployed where it can be reached with a = static IP address (as seen from the client), a WebRTC gateway does not need= to support full ICE; it therefore MAY implement ICE-Lite only". It might be a minor comment but I think it is wrong to say that a gateway "= is expected to be deployed where it can be reached with a static IP address= " and this gives the wrong impression. A gateway might be deployed in such a way but I would not say it is expecte= d to be deployed that way. So I suggest the following text. "A WebRTC gateway which is deployed where it can be reached with a static I= P address (as seen from the client), does not need to support full ICE; it = therefore MAY implement ICE-Lite only". Regards Andy From nobody Wed May 27 12:54: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 7C3E61A912B; Wed, 27 May 2015 12:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMVj9vidjRph; Wed, 27 May 2015 12:54:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FADE1A90AA; Wed, 27 May 2015 12:54:19 -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 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527195419.2803.75671.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 12:54:19 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-gateways-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 19:54:20 -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 Gateways Authors : Harald Alvestrand Uwe Rauschenbach Filename : draft-ietf-rtcweb-gateways-00.txt Pages : 5 Date : 2015-05-27 Abstract: This document specifies conformance requirements for a class of WebRTC-compatible endpoints called "WebRTC gateways", which interconnect between WebRTC endpoints and devices that are not WebRTC endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-gateways/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-gateways-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 27 13:00: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 0549F1A908D for ; Wed, 27 May 2015 13:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.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, 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 t4MLZlzDFk0s for ; Wed, 27 May 2015 13:00:10 -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 E58881A88BD for ; Wed, 27 May 2015 13:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=363; q=dns/txt; s=iport; t=1432756810; x=1433966410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=o0/KfZ03Xwr+x3/gmFlG2qmvGVJ6V+Iu3yUr8gIfv6s=; b=AWitrgc6h4xJWJD8ozhFJro4BghdzdZrklYqkugszQBTSkF2Ma4UsB8T H6EjI/x/+S3J2ees+vflshhCMOCOv4hGI2o6ZT1LF2Te6zKlF0/+aEeOe rhgeduXbN8ljE7zF7cDnXa1aCvqFPgsd7kHoe3LZ+n7oAncomUda3DZ8p 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBADxIGZV/5pdJa1cgxCBMgbBXgmHUAKBQzgUAQEBAQEBAYEKhCIBAQEDATo/BQsCAQgYHhAyJQIEDgWIJQjSLAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoRSMweDF4EWAQSTCIsPAZcuI4N4b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,507,1427760000"; d="scan'208";a="153918103" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2015 20:00:09 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t4RK09X7015383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 20:00:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 27 May 2015 15:00:08 -0500 From: "Cullen Jennings (fluffy)" To: "Hutton, Andrew" Thread-Topic: [rtcweb] rtcweb-gateways- Statis IP Address Comment Thread-Index: AQHQmLe7UTUOzOhqWEezi9M+ZLdOuw== Date: Wed, 27 May 2015 20:00:08 +0000 Message-ID: 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> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1E7547BD@MCHP04MSX.global-ad.net> 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: <23ABE647649C714B9CB35884C2204DBE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.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, 27 May 2015 20:00:11 -0000 > 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; i= t therefore MAY implement ICE-Lite only". >=20 > Regards > Andy +1 From nobody Wed May 27 16:07: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 A7E591ACD01; Wed, 27 May 2015 15:05:35 -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 2TqbUDIjcv71; Wed, 27 May 2015 15:05:31 -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 F2F291AC40B; Wed, 27 May 2015 15:05:30 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4RM5KMu017458 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 27 May 2015 18:05:21 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t4RM5KMu017458 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1432764321; bh=J8DY9jb6qQfm5fVnQ9gQYrG+21U=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=TkWx2e93+kIrE2am9M5/34bFZxVvEy8W4kQakRkOcZu9gGz0Ke/2zDajYkG+0PeSk z5orP1XL0IqhM/gx6npSfGLIegRVXi0yk5yiERgQ7Nc5hKoc89/q+9lQhrZVsZilgo 0cwm+vxL0vDqSWGABrdysyml9tCZAegsAQCOLjQs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com t4RM5KMu017458 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 27 May 2015 18:04:22 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4RM56gs006553 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 18:05:06 -0400 Received: from MXHUB210.corp.emc.com (10.253.68.36) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 27 May 2015 18:05:05 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.77]) by MXHUB210.corp.emc.com ([10.253.68.36]) with mapi id 14.03.0224.002; Wed, 27 May 2015 18:05:05 -0400 From: "Black, David" To: "Ram Mohan R (rmohanr)" , joel jaeggli , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "Tirumaleswar Reddy (tireddy)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" , "rtcweb@ietf.org" , "Black, David" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAc0OqA Date: Wed, 27 May 2015 22:05:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.48.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: X-Mailman-Approved-At: Wed, 27 May 2015 16:07:29 -0700 Cc: "Black, David" , "rtcweb-chairs@tools.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: Wed, 27 May 2015 22:05:35 -0000 Unfortunately, one of the major issues just became much more serious. As part of my issue [1], I wrote: 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. Unfortunately, the required clarification is more than editorial, as upon further reading, I see this sentence at the end of Section 3 in this draft: If consent is performed then there is no need to send keepalive messages. However, the first sentence in section 10 of RFC 5245 says: All endpoints MUST send keepalives for each media session. Therefore, this draft normatively modifies RFC 5245, but there was no indication of that modification during IETF Last Call, as the draft contains neither an Updates: header nor a summary description of changes to RFC 5245. This is a serious process problem; please work with your WG chairs and AD to determine what to do, as your AD (Alissa) owns the decision about what has to happen to correct this mistake in addition to correcting the text in the draft. ---------- Moving on to concerns beyond the two major issues ... anything not mentioned here (aside from [1] and [2] covered in my previous message, plus the above missing info on the updates to RFC 5245) is ok with me. > >> [3] In Section 1, please explain what ICE-lite is. A suitable referen= ce > >> should suffice. > > Yes we will add reference to RFC5245 that describes ICE-lite Please add a sentence to summarize ICE-lite, not just the reference. > >> [4] In Section 4.1, please explain or provide a reference for what "pa= ced" > >> means in "paced STUN connectivity checks or responses." >=20 > Pacing is explained in the same section below. Let us know if this is not > sufficient/not clear. > > 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. It's not clear - the word "paced" is absent, and that explanation shows up in the middle of the next page after the use of "paced." I suggest the following two changes to the second paragraph in Section 4.1 for clarity: First sentence: 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. a) Delete "paced" from the first line. b) Add the following sentence immediately after that first sentence. Additional constraints apply to when these checks are allowed to be sent= , including a minimum interval between checks, as further specified in thi= s section. -- Everything below here is editorial -- > >> This mechanism is an incremental modification to the STUN and ICE prot= ocols, > >> and can be implemented by one party to a communication session; ordina= ry > >> response generation behavior (already required) reflects the cryptogra= phically > >> strong STUN transaction IDs on which the mechanism is based. As a res= ult, the > >> mechanism can be deployed at one end of a two-party communication sess= ion > >> without impact on the other party. This is implied by section 3 of th= e draft, > >> but would be useful to state explicitly. >=20 > We will add a new applicability section proposed above and also modified > para 3 of Intro to make it clearer that this draft does not change ICE > procedures. Please let us know if this solves the comment above. It does not. Please add a sentence to say that consent checks can be deployed via modifications solely to endpoints that send STUN connectivity checks because implementations are already required to respond to such checks. A rephrasing of Section 3 would be a good means of adding = this. > >> [A.1.1 - deployment] > >> > >> The mechanism has been defined to limit the amount of added traffic an= d > >>to > >> shut down unwanted traffic, plus contains a facility to desynchronize > >> independent users of this protocol. Some rationale should be added fo= r > >> the choice of the 30 second timeout period. >=20 > 30 second timeout period was selected so that consent checks could be sen= t > between 7 to 5 times (to handle packet loss). Please add that statement to the draft. > >> [A.1.5 - network impact] > >> > >> There is an obvious fault condition, namely that consent is lost or re= voked > >> causing immediate cessation of traffic. While the details depend on t= he > >> 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 an= d 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 dra= ft. >=20 > We specifically discussed in WG about how applications should handle > changes in Consent and it was decided to keep it outside the scope of thi= s > draft. Para 3 of introduction already has a text that says the same. > There can be many possibilities if consent is lost or failed depending on > what the application wants. Ok, but .. this is not about "how applications should handle" loss of conse= nt; it's about "how implementations should report" loss of consent. Part of th= is is already in Section 7, which indicates how the application learns that consent has expired. It would suffice to add a sentence added to that sect= ion to indicate that there are other reasons for loss of ability to transmit da= ta, and include an example of how at least one other is reported to application= s. > >> [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 du= ration > >> of loss and re-establishment of consent-based connectivity, as such in= formation > >> has operational value. In particular, a discussion of how a server co= uld 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 server= s and > >> related networks than clients. [A.2.2 - management information, A.2.3 = - fault > >> management]. >=20 > This again seems some thing outside the scope of this draft as it is > trying to specify application behavior. Is there some thing that you want > us to add in the draft for this? Nope, this is again about reporting information, not how applications respo= nd to the reports. In addition, the consumer of this information may be a networ= k operation tool of some sort as opposed to a WebRTC application. Specific d= etails of what to track and how to report it belong elsewhere, but it would be goo= d to at least add a sentence pointing out that it is useful to track frequency a= nd duration of loss of consent, e.g., to assist in troubleshooting application= problems.=20 Thanks, --David > -----Original Message----- > From: Black, David > Sent: Wednesday, May 27, 2015 3:17 AM > To: Ram Mohan R (rmohanr); joel jaeggli; muthu.arul@gmail.com; Dan Wing > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops- > dir@ietf.org; rtcweb@ietf.org > Cc: Black, David > Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-1= 3 >=20 > I'll limit comments here to the two major issues. Quick summary: >=20 > [1] Applicability: The proposed text looks generally good, but the defini= tion > of "consent" needs a couple of clarifications. >=20 > [2] Security Considerations: The proposed text isn't sufficient. In addi= tion > to the new applicability text's reference to the WebRTC security > architecture draft, a reference to the WebRTC security considerations > draft with specific section pointers needs to be added to the security > considerations section of this draft. >=20 > > >> [1] The draft seems to be missing discussion of applicability - what > > >> environments and/or protocols is this mechanism intended for or > applicable > > >> to? >=20 > > We will add a new section =B3Applicability=B2 after the introduction se= ction. >=20 > I think that proposed applicability section will address most of the conc= ern. > As part of this, the definition of consent (Section 2) needs elaboration: >=20 > Consent: The mechanism of obtaining permission to send to a remote > transport address. Initial consent is obtained using ICE. >=20 > Two important concepts should be clearer: > - Permission to send is obtained *from the recipient* of the traffic. > - The traffic to which permission to send applies is *non-ICE* traffic. >=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 sho= uld > > >> be a discussion of how and why replays of previous consent responses > > >> are harmless (will be ignored by the recipient). > > > > Cryptographically strong STUN transaction IDs are required so that > > off-path attacker does not replay old consent responses. > > > > > > > > >>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. > > > > We will add the following line to Security Considerations section. > > > > NEW: > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > chosen from the interval 0 .. 2**96-1, and be cryptographically strong. > > This is good enough security against an off-path attacker replaying old > > STUN consent responses. >=20 > That's good, but the actual problem is a missing reference. The rational= e > discussion is in draft-ietf-rtcweb-security, so that draft needs to be ad= ded > as a normative reference, plus text added to the security considerations > section of this consent draft to call attention to sections 3.3 and 4.2 o= f > that rtcweb-security draft. This is in addition to the citation of secti= ons > 4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new > applicability text. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: Tuesday, May 19, 2015 11:28 AM > > To: joel jaeggli; Black, David; muthu.arul@gmail.com; Dan Wing (dwing); > > Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops-dir@ietf.or= g; > > rtcweb@ietf.org > > Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness= -13 > > > > Hi David/Joel, > > > > Please see inline for my responses. > > > > > > -----Original Message----- > > From: joel jaeggli > > Date: Friday, 15 May 2015 4:59 am > > To: "Black, David" , "muthu.arul@gmail.com" > > , "dwing@cisco.com" , Cisco > > Employee , "tireddy@cisco.com" , > > "martin.thomson@gmail.com" , "ops-dir@ietf.or= g" > > >=20 > > Cc: "rtcweb@ietf.org" , "ietf@ietf.org" > > Subject: Re: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness= -13 > > > > >Thanks David, > > > > > >I'll be looking with interest for the addressing of items 1/2. > > > > > >joel > > > > > >On 5/14/15 4:21 PM, Black, David wrote: > > >> I have reviewed this document as part of the Operational directorate= 's > > >> ongoing effort to review all IETF documents being processed by the I= ESG. > > >> These comments were written with the intent of improving the operati= onal > > >> aspects of the IETF drafts. Comments that are not addressed in last = call > > >> may be included in AD reviews during the IESG review. Document edit= ors > > >> and WG chairs should treat these comments just like any other last c= all > > >> 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 i= n > > >> a fashion that is secured by the use of cryptographically strong non= ces > > >> 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 t= his > > >> is not intended to promulgate new requirements for all uses of ICE a= nd > > >> STUN, but this should be clarified. The shepherd writeup implies th= at > > >> this draft is intended primarily for WebRTC. > > > > This document defines what it takes to obtain, maintain, and lose > > consent to send using ICE. This draft does not restrict on what > > applications should use > > Consent. Currently on webRTC applications use Consent, however any othe= r > > application that has > > Similar security requirements can use this mechanism. We will add a new > > section =B3Applicability=B2 > > after the introduction section. > > > > > > 2. Applicability > > > > This document defines what it takes to obtain, maintain, and lose conse= nt > > to send using ICE.Verification of peer consent before sending traffic i= s > > necessary in deployments like WebRTC to ensure that a malicious JavaScr= ipt > > cannot use the browser as a platform for launching attacks.Section 4.4 = and > > section 5.3 of [I-D.ietf-rtcweb-security-arch] explains why webRTC > > application needs consent. > > > > Other Applications that have similar security requirement where it is > > required to verify peer's consent before sending non-ICE packets can us= e > > the consent mechanism described in this draft. > > > > > > > > > > > > Also we will modify para 3 of Intro to make it clearer. > > > > OLD: > > This document defines what it takes to obtain, maintain, and lose > > consent to send. Consent to send applies to a single 5-tuple. How > > applications react to changes in consent is not described in this > > document. > > > > > > > > NEW: > > This document defines what it takes to obtain, maintain, and lose conse= nt > > to send. Consent > > to send applies to a single 5-tuple. How applications react to change= s > > in consent is not > > described in this document. The consent mechanism does not update the > > ICE procedures > > defined in [RFC 5245]. > > > > > > > > > > > > > > >> > > >> [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 sho= uld > > >> be a discussion of how and why replays of previous consent responses > > >> are harmless (will be ignored by the recipient). > > > > Cryptographically strong STUN transaction IDs are required so that > > off-path attacker does not replay old consent responses. > > > > > > > > >>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. > > > > We will add the following line to Security Considerations section. > > > > NEW: > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > chosen from the interval 0 .. 2**96-1, and be cryptographically strong. > > This is good enough security against an off-path attacker replaying old > > STUN consent responses. > > > > > > > > >> > > >> -- Minor Issues -- > > >> > > >> [3] In Section 1, please explain what ICE-lite is. A suitable refer= ence > > >> should suffice. > > > > Yes we will add reference to RFC5245 that describes ICE-lite > > > > > > > > >> > > >> [4] In Section 4.1, please explain or provide a reference for what > > >>"paced" > > >> means in "paced STUN connectivity checks or responses." > > > > Pacing is explained in the same section below. Let us know if this is n= ot > > sufficient/not clear. > > > > 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 basi= c > > period. Implementations SHOULD set a default interval of 5 seconds= , > > resulting in a period between checks of 4 to 6 seconds. > > > > > > > > > > >> > > >> -- 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. > > > > Okay, will move this paragraph to Section 3. > > > > > > > > >> > > >> idnits 2.13.02 found an unused reference: > > >> > > >> =3D=3D Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on = line > > >>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). > > > > This reference is not needed. Once we add applicability section we will > > reference rtcweb-security-arch draft. > > > > >> > > >> --- 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; ordi= nary > > >> 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. > > > > We will add a new applicability section proposed above and also modifie= d > > para 3 of Intro to make it clearer that this draft does not change ICE > > procedures. Please let us know if this solves the comment above. > > > > > > >> [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 desynchroniz= e > > >> independent users of this protocol. Some rationale should be added = for > > >> the choice of the 30 second timeout period. > > > > 30 second timeout period was selected so that consent checks could be s= ent > > between 7 to 5 times (to handle packet loss). > > > > > > >> [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 oth= er > > >>forms > > >> of connectivity (e.g., TCP, SRTP/SRTCP) that are mentioned in this > > >>draft. > > > > We specifically discussed in WG about how applications should handle > > changes in Consent and it was decided to keep it outside the scope of t= his > > draft. Para 3 of introduction already has a text that says the same. > > There can be many possibilities if consent is lost or failed depending = on > > what the application wants. > > > > > > >> [A.1.8 - fault and threshold conditions] > > >> > > >> This mechanism is a simple extension to existing protocols, and shou= ld > > >>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 migh= t > > >>be useful > > >> to add, as the operational concerns may be more significant for serv= ers > > >>and > > >> related networks than clients. [A.2.2 - management information, A.2.= 3 - > > >>fault > > >> management]. > > > > This again seems some thing outside the scope of this draft as it is > > trying to specify application behavior. Is there some thing that you wa= nt > > us to add in the draft for this? > > > > Regards, > > Ram > > > > >> > > >> The primary operational impact of this protocol should be reduction = in > > >>unwanted > > >> traffic, which is a benefit - the consent check traffic added by thi= s > > >>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 01748 > > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > >> david.black@emc.com Mobile: +1 (978) 394-7754 > > >> ---------------------------------------------------- > > >> > > >> > > >> > > > > > > From nobody Wed May 27 22:12: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 93CA01A8A4A; Wed, 27 May 2015 22:12:21 -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_4F1s1T07vw; Wed, 27 May 2015 22:12:18 -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 436621A8A44; Wed, 27 May 2015 22:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15749; q=dns/txt; s=iport; t=1432789938; x=1433999538; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oCInt/9qMNc07EkpB0fteFXFwVCq+fKq0f5yGdxc6TQ=; b=L5ahu81gWGefop8oc7zztpLZvCkFapzvieD2WIBM+ccDnSjnBYUq/i4W KHTNBIaejqrvx4bkVKNQFCL5d51sQMgvB617FdU8yGDsUmBIfdxboL2U/ oGUFEMoOLixJtzoKjH5ZBj8erAWU/OcVKBG266MkxmzexJ4Wx/vwaDesd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBABBo2ZV/4kNJK1ZA4MQgTIGwHtmCYdRAoFHOBQBAQEBAQEBgQqEIgEBAQMBfgcEAgEIEQECAQEBAQodByERFAMGCAEBBAESCIgQAwoIzkcNhH4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYFgDRohFwYLgwaBFgWFDYFehHQrhn6IfDqDAoNxijZchwMjYYMXb4EDAR8CIYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,511,1427760000"; d="scan'208";a="2421355" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP; 28 May 2015 05:12:16 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4S5CGfs029873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 05:12:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Thu, 28 May 2015 00:12:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Black, David" , "Ram Mohan R (rmohanr)" , joel jaeggli , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAtFSwA Date: Thu, 28 May 2015 05:12:15 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47860737@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.47.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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: Thu, 28 May 2015 05:12:21 -0000 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Wednesday, May 27, 2015 12:47 PM > To: Ram Mohan R (rmohanr); joel jaeggli; muthu.arul@gmail.com; Dan Wing > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops- > dir@ietf.org; rtcweb@ietf.org > Cc: Black, David > Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-1= 3 >=20 > I'll limit comments here to the two major issues. Quick summary: >=20 > [1] Applicability: The proposed text looks generally good, but the defini= tion > of "consent" needs a couple of clarifications. >=20 > [2] Security Considerations: The proposed text isn't sufficient. In addi= tion > to the new applicability text's reference to the WebRTC security > architecture draft, a reference to the WebRTC security > considerations > draft with specific section pointers needs to be added to the security > considerations section of this draft. >=20 > > >> [1] The draft seems to be missing discussion of applicability - > > >> what environments and/or protocols is this mechanism intended for > > >> or applicable to? >=20 > > We will add a new section =B3Applicability=B2 after the introduction se= ction. >=20 > I think that proposed applicability section will address most of the conc= ern. > As part of this, the definition of consent (Section 2) needs elaboration: >=20 > Consent: The mechanism of obtaining permission to send to a remote > transport address. Initial consent is obtained using ICE. >=20 > Two important concepts should be clearer: > - Permission to send is obtained *from the recipient* of the traffic. > - The traffic to which permission to send applies is *non-ICE* traffic. NEW: Consent: The mechanism of obtaining permission from the remote endpoint to= send non-ICE traffic to a remote transport address. =20 Initial consent is obtained using ICE. >=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). > > > > Cryptographically strong STUN transaction IDs are required so that > > off-path attacker does not replay old consent responses. > > > > > > > > >>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. > > > > We will add the following line to Security Considerations section. > > > > NEW: > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > chosen from the interval 0 .. 2**96-1, and be cryptographically strong. > > This is good enough security against an off-path attacker replaying > > old STUN consent responses. >=20 > That's good, but the actual problem is a missing reference. The rational= e > discussion is in draft-ietf-rtcweb-security, so that draft needs to be ad= ded as > a normative reference, plus text added to the security considerations sec= tion > of this consent draft to call attention to sections 3.3 and 4.2 of that r= tcweb- > security draft. =20 Added the following line to security considerations section NEW: Consent Verification to avoid attacks using browser as an attack platform against machines is discussed in sections 3.2 and 4.2 of [I-D.ietf-rtcweb-security]. > This is in addition to the citation of sections > 4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new > applicability text. Added draft-ietf-rtcweb-security-arch and draft-ietf-rtcweb-security as nor= mative references. -Tiru >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > Sent: Tuesday, May 19, 2015 11:28 AM > > To: joel jaeggli; Black, David; muthu.arul@gmail.com; Dan Wing > > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; > > ops-dir@ietf.org; rtcweb@ietf.org > > Subject: Re: OPS-Dir review of > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > Hi David/Joel, > > > > Please see inline for my responses. > > > > > > -----Original Message----- > > From: joel jaeggli > > Date: Friday, 15 May 2015 4:59 am > > To: "Black, David" , "muthu.arul@gmail.com" > > , "dwing@cisco.com" , Cisco > > Employee , "tireddy@cisco.com" > , > > "martin.thomson@gmail.com" , "ops- > dir@ietf.org" > > >=20 > > Cc: "rtcweb@ietf.org" , "ietf@ietf.org" > > > > Subject: Re: OPS-Dir review of > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > >Thanks David, > > > > > >I'll be looking with interest for the addressing of items 1/2. > > > > > >joel > > > > > >On 5/14/15 4:21 PM, Black, David wrote: > > >> 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. > > > > This document defines what it takes to obtain, maintain, and lose > > consent to send using ICE. This draft does not restrict on what > > applications should use Consent. Currently on webRTC applications use > > Consent, however any other application that has Similar security > > requirements can use this mechanism. We will add a new section > > =B3Applicability=B2 after the introduction section. > > > > > > 2. Applicability > > > > This document defines what it takes to obtain, maintain, and lose > > consent to send using ICE.Verification of peer consent before sending > > traffic is necessary in deployments like WebRTC to ensure that a > > malicious JavaScript cannot use the browser as a platform for > > launching attacks.Section 4.4 and section 5.3 of > > [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs > consent. > > > > Other Applications that have similar security requirement where it is > > required to verify peer's consent before sending non-ICE packets can > > use the consent mechanism described in this draft. > > > > > > > > > > > > Also we will modify para 3 of Intro to make it clearer. > > > > OLD: > > This document defines what it takes to obtain, maintain, and lose > > consent to send. Consent to send applies to a single 5-tuple. How > > applications react to changes in consent is not described in this > > document. > > > > > > > > NEW: > > This document defines what it takes to obtain, maintain, and lose > > consent to send. Consent to send applies to a single 5-tuple. How > > applications react to changes in consent is not > > described in this document. The consent mechanism does not update > > the ICE procedures defined in [RFC 5245]. > > > > > > > > > > > > > > >> > > >> [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). > > > > Cryptographically strong STUN transaction IDs are required so that > > off-path attacker does not replay old consent responses. > > > > > > > > >>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. > > > > We will add the following line to Security Considerations section. > > > > NEW: > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > chosen from the interval 0 .. 2**96-1, and be cryptographically strong. > > This is good enough security against an off-path attacker replaying > > old STUN consent responses. > > > > > > > > >> > > >> -- Minor Issues -- > > >> > > >> [3] In Section 1, please explain what ICE-lite is. A suitable > > >> reference should suffice. > > > > Yes we will add reference to RFC5245 that describes ICE-lite > > > > > > > > >> > > >> [4] In Section 4.1, please explain or provide a reference for what > > >>"paced" > > >> means in "paced STUN connectivity checks or responses." > > > > Pacing is explained in the same section below. Let us know if this is > > not sufficient/not clear. > > > > 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 basi= c > > period. Implementations SHOULD set a default interval of 5 seconds= , > > resulting in a period between checks of 4 to 6 seconds. > > > > > > > > > > >> > > >> -- 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. > > > > Okay, will move this paragraph to Section 3. > > > > > > > > >> > > >> idnits 2.13.02 found an unused reference: > > >> > > >> =3D=3D Unused Reference: 'I-D.ietf-rtcweb-overview' is defined on > > >>line 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). > > > > This reference is not needed. Once we add applicability section we > > will reference rtcweb-security-arch draft. > > > > >> > > >> --- 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. > > > > We will add a new applicability section proposed above and also > > modified para 3 of Intro to make it clearer that this draft does not > > change ICE procedures. Please let us know if this solves the comment > above. > > > > > > >> [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. > > > > 30 second timeout period was selected so that consent checks could be > > sent between 7 to 5 times (to handle packet loss). > > > > > > >> [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. > > > > We specifically discussed in WG about how applications should handle > > changes in Consent and it was decided to keep it outside the scope of > > this draft. Para 3 of introduction already has a text that says the sam= e. > > There can be many possibilities if consent is lost or failed depending > > on what the application wants. > > > > > > >> [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]. > > > > This again seems some thing outside the scope of this draft as it is > > trying to specify application behavior. Is there some thing that you > > want us to add in the draft for this? > > > > Regards, > > Ram > > > > >> > > >> 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 01748 > > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > >> david.black@emc.com Mobile: +1 (978) 394-7754 > > >> ---------------------------------------------------- > > >> > > >> > > >> > > > > > > From nobody Wed May 27 23:32: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 7B9DC1A1AFF; Wed, 27 May 2015 23:32:29 -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 7g-8sDEM93Jm; Wed, 27 May 2015 23:32:25 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5841A1AA6; Wed, 27 May 2015 23:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25576; q=dns/txt; s=iport; t=1432794744; x=1434004344; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=oPqd+wi7+SFf6VT1IrlMlQ3dpj1AyZtBCqTf4gK3Qik=; b=NpSrPO/2nocpI9FNANYFUm06o8LhE9ZPAcEsaXF6ba/+WBDmFidjg1bp UajRNws5w7/TpSU1M5MKH8YA2X8/+NGtIkuldHtDkFr74k0HjLAtBAOMM xmBg4LeYbWgG3/9fYggoHY+Drbnlfn2ceevkJCHoMpfGjN/+yVQuv46U8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBADStWZV/4MNJK1ZA4MQgTIGwHxmCYdRAoFKOBQBAQEBAQEBgQqEIgEBAQMBGl8FBwYBCBEBAgEBAQEKHSgRFAMGCQEEAQ0FCIgQAwoIzmYNhH4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYFgDRohEA0LgwaBFgWFDYFehHQrhn6HBIF4OoMCg3GKNlyDKoNZI2GDF2+BAwEGGQIhgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,511,1427760000"; d="scan'208";a="154051107" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP; 28 May 2015 06:32:23 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4S6WM2B014252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 06:32:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 28 May 2015 01:32:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Black, David (david.black@emc.com)" , "joel jaeggli (joelja@bogus.com)" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCZEAkgUwawg8/yQZKvd0M2cshTwQ== Date: Thu, 28 May 2015 06:32:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478607D3@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.47.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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: Thu, 28 May 2015 06:32:29 -0000 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, May 28, 2015 3:35 AM > To: Ram Mohan R (rmohanr); joel jaeggli; muthu.arul@gmail.com; Dan Wing > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops- > dir@ietf.org; rtcweb@ietf.org; Black, David > Cc: Black, David; rtcweb-chairs@tools.ietf.org; Alissa Cooper > (alissa@cooperw.in) > Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-1= 3 >=20 > Unfortunately, one of the major issues just became much more serious. As > part of my issue [1], I wrote: >=20 > I don't > see any RFCs listed as updated by this draft, so I'm guessing that thi= s > is not intended to promulgate new requirements for all uses of ICE and > STUN, but this should be clarified. >=20 > Unfortunately, the required clarification is more than editorial, as upon > further reading, I see this sentence at the end of Section 3 in this draf= t: >=20 > If consent is > performed then there is no need to send keepalive messages. >=20 > However, the first sentence in section 10 of RFC 5245 says: >=20 > All endpoints MUST send keepalives for each media session. >=20 > Therefore, this draft normatively modifies RFC 5245, but there was no > indication of that modification during IETF Last Call, as the draft conta= ins > neither an Updates: header nor a summary description of changes to RFC > 5245. >=20 > This is a serious process problem; please work with your WG chairs and AD > to determine what to do, as your AD (Alissa) owns the decision about what > has to happen to correct this mistake in addition to correcting the text = in the > draft. >=20 > ---------- >=20 > Moving on to concerns beyond the two major issues ... anything not > mentioned here (aside from [1] and [2] covered in my previous message, > plus the above missing info on the updates to RFC 5245) is ok with me. >=20 > > >> [3] In Section 1, please explain what ICE-lite is. A suitable > > >> reference should suffice. > > > > Yes we will add reference to RFC5245 that describes ICE-lite >=20 > Please add a sentence to summarize ICE-lite, not just the reference. NEW: ICE-lite agent defined in section 2.7 of [RFC5245] does not generate connec= tivity checks or runs the ICE state machine, it only needs to be able to respond to connectivity checks. Hence an ICE-lite implementation will not generate consent checks, but will just respond to consent checks it receives. No changes are required to ICE-lite implementations in order to respond to consent checks, as they are processed as normal ICE connectivity checks. >=20 > > >> [4] In Section 4.1, please explain or provide a reference for what > "paced" > > >> means in "paced STUN connectivity checks or responses." > > > > Pacing is explained in the same section below. Let us know if this is > > not sufficient/not clear. > > > > 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 basi= c > > period. Implementations SHOULD set a default interval of 5 seconds= , > > resulting in a period between checks of 4 to 6 seconds. >=20 > It's not clear - the word "paced" is absent, and that explanation shows u= p in > the middle of the next page after the use of "paced." I suggest the foll= owing > two changes to the second paragraph in Section 4.1 for clarity: >=20 > First sentence: >=20 > 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. >=20 > a) Delete "paced" from the first line. > b) Add the following sentence immediately after that first sentence. >=20 > Additional constraints apply to when these checks are allowed to be se= nt, > including a minimum interval between checks, as further specified in t= his > section. >=20 > -- Everything below here is editorial -- >=20 > > >> 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 wou= ld be > useful to state explicitly. > > > > We will add a new applicability section proposed above and also > > modified para 3 of Intro to make it clearer that this draft does not > > change ICE procedures. Please let us know if this solves the comment > above. >=20 > It does not. Please add a sentence to say that consent checks can be > deployed via modifications solely to endpoints that send STUN connectivit= y > checks because implementations are already required to respond to such > checks. A rephrasing of Section 3 would be a good means of adding this. Section 3. NEW: The mechanism proposed in the document is an optional extension to the ICE = protocol, it can be deployed at one end of the two-party communication sess= ion without impact on the other party. >=20 > > >> [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. > > > > 30 second timeout period was selected so that consent checks could be > > sent between 7 to 5 times (to handle packet loss). >=20 > Please add that statement to the draft. NEW: 30 second timeout period was selected so that consent checks could be sent = between 7 to 5 times to handle packet loss. >=20 > > >> [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. > > > > We specifically discussed in WG about how applications should handle > > changes in Consent and it was decided to keep it outside the scope of > > this draft. Para 3 of introduction already has a text that says the sam= e. > > There can be many possibilities if consent is lost or failed depending > > on what the application wants. >=20 > Ok, but .. this is not about "how applications should handle" loss of con= sent; > it's about "how implementations should report" loss of consent. Part of = this > is already in Section 7, which indicates how the application learns that > consent has expired. It would suffice to add a sentence added to that > section to indicate that there are other reasons for loss of ability to t= ransmit > data, and include an example of how at least one other is reported to > applications. NEW: The circuit breaker algorithm discussed in section 7.1 of [I-D.ietf-rtcweb-= rtp-usage] could be one of the reasons for ceasing transmission of media an= d to notify the application about the loss of ability to transmit data. >=20 > > >> [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]. > > > > This again seems some thing outside the scope of this draft as it is > > trying to specify application behavior. Is there some thing that you > > want us to add in the draft for this? >=20 > Nope, this is again about reporting information, not how applications > respond to the reports. In addition, the consumer of this information ma= y > be a network operation tool of some sort as opposed to a WebRTC > application. Specific details of what to track and how to report it belo= ng > elsewhere, but it would be good to at least add a sentence pointing out t= hat > it is useful to track frequency and duration of loss of consent, e.g., to= assist in > troubleshooting application problems. NEW: WebRTC client application may in-turn notify WebRTC server about loss of co= nsent so that it can track frequency and duration of loss of consent , e.g.= , to assist in troubleshooting application problems. Cheers, -Tiru >=20 >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Wednesday, May 27, 2015 3:17 AM > > To: Ram Mohan R (rmohanr); joel jaeggli; muthu.arul@gmail.com; Dan > > Wing (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; > > ops- dir@ietf.org; rtcweb@ietf.org > > Cc: Black, David > > Subject: RE: OPS-Dir review of > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > I'll limit comments here to the two major issues. Quick summary: > > > > [1] Applicability: The proposed text looks generally good, but the defi= nition > > of "consent" needs a couple of clarifications. > > > > [2] Security Considerations: The proposed text isn't sufficient. In ad= dition > > to the new applicability text's reference to the WebRTC security > > architecture draft, a reference to the WebRTC security > considerations > > draft with specific section pointers needs to be added to the security > > considerations section of this draft. > > > > > >> [1] The draft seems to be missing discussion of applicability - > > > >> what environments and/or protocols is this mechanism intended for > > > >> or > > applicable > > > >> to? > > > > > We will add a new section =B3Applicability=B2 after the introduction = section. > > > > I think that proposed applicability section will address most of the co= ncern. > > As part of this, the definition of consent (Section 2) needs elaboratio= n: > > > > Consent: The mechanism of obtaining permission to send to a remote > > transport address. Initial consent is obtained using ICE. > > > > Two important concepts should be clearer: > > - Permission to send is obtained *from the recipient* of the traffic. > > - The traffic to which permission to send applies is *non-ICE* traffic= . > > > > > >> [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). > > > > > > Cryptographically strong STUN transaction IDs are required so that > > > off-path attacker does not replay old consent responses. > > > > > > > > > > > > >>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. > > > > > > We will add the following line to Security Considerations section. > > > > > > NEW: > > > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > > chosen from the interval 0 .. 2**96-1, and be cryptographically stron= g. > > > This is good enough security against an off-path attacker replaying > > > old STUN consent responses. > > > > That's good, but the actual problem is a missing reference. The > > rationale discussion is in draft-ietf-rtcweb-security, so that draft > > needs to be added as a normative reference, plus text added to the > > security considerations section of this consent draft to call > > attention to sections 3.3 and 4.2 of that rtcweb-security draft. This > > is in addition to the citation of sections > > 4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new > > applicability text. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: Tuesday, May 19, 2015 11:28 AM > > > To: joel jaeggli; Black, David; muthu.arul@gmail.com; Dan Wing > > > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; > > > ops-dir@ietf.org; rtcweb@ietf.org > > > Subject: Re: OPS-Dir review of > > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > > > Hi David/Joel, > > > > > > Please see inline for my responses. > > > > > > > > > -----Original Message----- > > > From: joel jaeggli > > > Date: Friday, 15 May 2015 4:59 am > > > To: "Black, David" , "muthu.arul@gmail.com" > > > , "dwing@cisco.com" , > Cisco > > > Employee , "tireddy@cisco.com" > > > , "martin.thomson@gmail.com" > , "ops-dir@ietf.org" > > > > > > > > Cc: "rtcweb@ietf.org" , "ietf@ietf.org" > > > > > > Subject: Re: OPS-Dir review of > > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > > > >Thanks David, > > > > > > > >I'll be looking with interest for the addressing of items 1/2. > > > > > > > >joel > > > > > > > >On 5/14/15 4:21 PM, Black, David wrote: > > > >> 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. > > > > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send using ICE. This draft does not restrict on what > > > applications should use Consent. Currently on webRTC applications > > > use Consent, however any other application that has Similar security > > > requirements can use this mechanism. We will add a new section > > > =B3Applicability=B2 after the introduction section. > > > > > > > > > 2. Applicability > > > > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send using ICE.Verification of peer consent before > > > sending traffic is necessary in deployments like WebRTC to ensure > > > that a malicious JavaScript cannot use the browser as a platform for > > > launching attacks.Section 4.4 and section 5.3 of > > > [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs > consent. > > > > > > Other Applications that have similar security requirement where it > > > is required to verify peer's consent before sending non-ICE packets > > > can use the consent mechanism described in this draft. > > > > > > > > > > > > > > > > > > Also we will modify para 3 of Intro to make it clearer. > > > > > > OLD: > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send. Consent to send applies to a single 5-tuple. Ho= w > > > applications react to changes in consent is not described in this > > > document. > > > > > > > > > > > > NEW: > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send. Consent to send applies to a single 5-tuple. How > > > applications react to changes in consent is not > > > described in this document. The consent mechanism does not update > > > the ICE procedures defined in [RFC 5245]. > > > > > > > > > > > > > > > > > > > > > >> > > > >> [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). > > > > > > Cryptographically strong STUN transaction IDs are required so that > > > off-path attacker does not replay old consent responses. > > > > > > > > > > > > >>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. > > > > > > We will add the following line to Security Considerations section. > > > > > > NEW: > > > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > > chosen from the interval 0 .. 2**96-1, and be cryptographically stron= g. > > > This is good enough security against an off-path attacker replaying > > > old STUN consent responses. > > > > > > > > > > > > >> > > > >> -- Minor Issues -- > > > >> > > > >> [3] In Section 1, please explain what ICE-lite is. A suitable > > > >> reference should suffice. > > > > > > Yes we will add reference to RFC5245 that describes ICE-lite > > > > > > > > > > > > >> > > > >> [4] In Section 4.1, please explain or provide a reference for > > > >>what "paced" > > > >> means in "paced STUN connectivity checks or responses." > > > > > > Pacing is explained in the same section below. Let us know if this > > > is not sufficient/not clear. > > > > > > 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 secon= ds, > > > resulting in a period between checks of 4 to 6 seconds. > > > > > > > > > > > > > > > >> > > > >> -- 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. > > > > > > Okay, will move this paragraph to Section 3. > > > > > > > > > > > > >> > > > >> idnits 2.13.02 found an unused reference: > > > >> > > > >> =3D=3D Unused Reference: 'I-D.ietf-rtcweb-overview' is defined o= n > > > >>line 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). > > > > > > This reference is not needed. Once we add applicability section we > > > will reference rtcweb-security-arch draft. > > > > > > >> > > > >> --- 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. > > > > > > We will add a new applicability section proposed above and also > > > modified para 3 of Intro to make it clearer that this draft does not > > > change ICE procedures. Please let us know if this solves the comment > above. > > > > > > > > > >> [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. > > > > > > 30 second timeout period was selected so that consent checks could > > > be sent between 7 to 5 times (to handle packet loss). > > > > > > > > > >> [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. > > > > > > We specifically discussed in WG about how applications should handle > > > changes in Consent and it was decided to keep it outside the scope > > > of this draft. Para 3 of introduction already has a text that says th= e same. > > > There can be many possibilities if consent is lost or failed > > > depending on what the application wants. > > > > > > > > > >> [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]. > > > > > > This again seems some thing outside the scope of this draft as it is > > > trying to specify application behavior. Is there some thing that you > > > want us to add in the draft for this? > > > > > > Regards, > > > Ram > > > > > > >> > > > >> 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 01748 > > > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > >> david.black@emc.com Mobile: +1 (978) 394-7754 > > > >> ---------------------------------------------------- > > > >> > > > >> > > > >> > > > > > > > > From nobody Thu May 28 03:49: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 8C1311A8893 for ; Thu, 28 May 2015 03:49:51 -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 wmp2Kn5Dwy9a for ; Thu, 28 May 2015 03:49:49 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4C81A882C for ; Thu, 28 May 2015 03:49:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 948757C0628 for ; Thu, 28 May 2015 12:49:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Zx4AJBoxkb for ; Thu, 28 May 2015 12:49:47 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:8033:cfd7:4e1e:7674] (unknown [IPv6:2001:470:de0a:27:8033:cfd7:4e1e:7674]) by mork.alvestrand.no (Postfix) with ESMTPSA id 969667C0620 for ; Thu, 28 May 2015 12:49:47 +0200 (CEST) Message-ID: <5566F2CB.8050205@alvestrand.no> Date: Thu, 28 May 2015 12:49:47 +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: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: 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: Thu, 28 May 2015 10:49:51 -0000 Den 28. mai 2015 08:32, skrev Tirumaleswar Reddy (tireddy): >> > Please add a sentence to summarize ICE-lite, not just the reference. > NEW: > ICE-lite agent defined in section 2.7 of [RFC5245] does not generate connectivity > checks or runs the ICE state machine, it only needs to be able to > respond to connectivity checks. Hence an ICE-lite implementation > will not generate consent checks, but will just respond to consent > checks it receives. No changes are required to ICE-lite > implementations in order to respond to consent checks, as they are > processed as normal ICE connectivity checks. > >> > Grammar stickler: "An ICE-lite agent, as defined in section 2.7 of [RFC5245], does not generate connectivity check or run the ICE state machine". .... "Hence an ICE-lite agent will not ..." I think the second occurence of "implementation" is OK, but the first one really needs to be "agent". From nobody Thu May 28 03:50: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 416721A882C; Thu, 28 May 2015 03:50:39 -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 gpXtqZSPzgK8; Thu, 28 May 2015 03:50:38 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 082F81A8893; Thu, 28 May 2015 03:50:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2F1E87C0628; Thu, 28 May 2015 12:50:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNDhnpu-Tzpu; Thu, 28 May 2015 12:50:36 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:8033:cfd7:4e1e:7674] (unknown [IPv6:2001:470:de0a:27:8033:cfd7:4e1e:7674]) by mork.alvestrand.no (Postfix) with ESMTPSA id CBB9E7C0620; Thu, 28 May 2015 12:50:35 +0200 (CEST) Message-ID: <5566F2FB.2070708@alvestrand.no> Date: Thu, 28 May 2015 12:50:35 +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: "Tirumaleswar Reddy (tireddy)" , "Black, David" , "Ram Mohan R (rmohanr)" , joel jaeggli , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" , "rtcweb@ietf.org" References: <913383AAA69FF945B8F946018B75898A47860737@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A47860737@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: 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: Thu, 28 May 2015 10:50:39 -0000 Den 28. mai 2015 07:12, skrev Tirumaleswar Reddy (tireddy): >> > Two important concepts should be clearer: >> > - Permission to send is obtained *from the recipient* of the traffic. >> > - The traffic to which permission to send applies is *non-ICE* traffic. > NEW: > Consent: The mechanism of obtaining permission from the remote endpoint to send non-ICE traffic to a remote transport address. > Initial consent is obtained using ICE. > CLarity stickler: Delete "initial" above. As defined in this specification, *all* consent is obtained using ICE. From nobody Thu May 28 03:54: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 F025B1A88FD for ; Thu, 28 May 2015 03:54:20 -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 kOKZFrvIuE8W for ; Thu, 28 May 2015 03:54:19 -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 7C4E31A88F1 for ; Thu, 28 May 2015 03:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1467; q=dns/txt; s=iport; t=1432810460; x=1434020060; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ar3XhJJ5b0lUG+uKSZ4iUo4K4EshbSXDL/M7wTUErBs=; b=Fm8J9Q3horlr4JR+n5QFDUAYQgyjsnwJ/Gisi8SpQM0E+D0rhWgtjmOR W8BJTNfXfPmzgKguiT+KWYsxuvxSbxjGhOA9E9ND28WGozI4kKPX/QbVo PybqioC8hGDR30vUgWaDkHGVhz5Kqw5572ogcsapoDIS5/8MvVR1dW1Lx 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBACl8mZV/4ENJK1cgxBUXga/GWYJgVAKhS1KAoFROBQBAQEBAQEBgQqEIgEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCIglDdQcAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOoRUOAaDEYEWBZMIhwSFNINxkhUjYYMXb4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,512,1427760000"; d="scan'208";a="153983689" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP; 28 May 2015 10:54:19 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4SAsIrY002545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 10:54:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 28 May 2015 05:54:18 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCZEAkgUwawg8/yQZKvd0M2cshTwQATeM6AAApZRWA= Date: Thu, 28 May 2015 10:54:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47860AA6@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <5566F2CB.8050205@alvestrand.no> In-Reply-To: <5566F2CB.8050205@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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: Thu, 28 May 2015 10:54:21 -0000 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald > Alvestrand > Sent: Thursday, May 28, 2015 4:20 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent- > freshness-13 >=20 > Den 28. mai 2015 08:32, skrev Tirumaleswar Reddy (tireddy): > >> > Please add a sentence to summarize ICE-lite, not just the reference. > > NEW: > > ICE-lite agent defined in section 2.7 of [RFC5245] does not generate > connectivity > > checks or runs the ICE state machine, it only needs to be able to > > respond to connectivity checks. Hence an ICE-lite implementation > > will not generate consent checks, but will just respond to consent > > checks it receives. No changes are required to ICE-lite > > implementations in order to respond to consent checks, as they are > > processed as normal ICE connectivity checks. > > > >> > >=20 > Grammar stickler: >=20 > "An ICE-lite agent, as defined in section 2.7 of [RFC5245], does not > generate connectivity check or run the ICE state machine". >=20 > .... "Hence an ICE-lite agent will not ..." >=20 > I think the second occurence of "implementation" is OK, but the first > one really needs to be "agent". Thanks, fixed in my local copy. -Tiru >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu May 28 03:55: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 CA3041A88FD; Thu, 28 May 2015 03:55:26 -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 lXtlg52FywLp; Thu, 28 May 2015 03:55:25 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874091A88AD; Thu, 28 May 2015 03:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1039; q=dns/txt; s=iport; t=1432810525; x=1434020125; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qA5S2+vAcQQXiRQ7tdffc5vH1aSXFi8I7uDoen1TTco=; b=QdwQXqV+jJ/QpSh7z3+gTIuHE0+o9BnNiHFWm0RGshM6H7hTawylfy5v NyebgOVvD2PVOJjrh4aeyscdoUP6Cmd41WVk7acTlp5VTIpRehLn9Mfas GZolaS+VUhIb6+MiYQSbsH7SZy+bBvz7liI3BsrfAJL0f9qQBMmG2MXCn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ARBADW82ZV/4sNJK1cgxCBMga/GWYJh1ECgVE4FAEBAQEBAQGBCoQiAQEBBDpLBAIBCBEEAQELFAkHIREUCQgBAQQBEgiIEAMSzyENhH4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYIHOAaDEYEWAQSQTII8iTaSBYcDI2GDF2+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,512,1427760000"; d="scan'208";a="154176869" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 28 May 2015 10:55:04 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t4SAt468031900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 10:55:04 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 28 May 2015 05:55:04 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Harald Alvestrand , "Black, David" , "Ram Mohan R (rmohanr)" , "joel jaeggli" , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAtFSwAABcmB4AAClbZMA== Date: Thu, 28 May 2015 10:55:03 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47860ABD@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A47860737@xmb-rcd-x10.cisco.com> <5566F2FB.2070708@alvestrand.no> In-Reply-To: <5566F2FB.2070708@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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: Thu, 28 May 2015 10:55:27 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Thursday, May 28, 2015 4:21 PM > To: Tirumaleswar Reddy (tireddy); Black, David; Ram Mohan R (rmohanr); > joel jaeggli; muthu.arul@gmail.com; Dan Wing (dwing); > martin.thomson@gmail.com; ops-dir@ietf.org; rtcweb@ietf.org > Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent- > freshness-13 >=20 > Den 28. mai 2015 07:12, skrev Tirumaleswar Reddy (tireddy): > >> > Two important concepts should be clearer: > >> > - Permission to send is obtained *from the recipient* of the traffi= c. > >> > - The traffic to which permission to send applies is *non-ICE* traf= fic. > > NEW: > > Consent: The mechanism of obtaining permission from the remote > endpoint to send non-ICE traffic to a remote transport address. > > Initial consent is obtained using ICE. > > >=20 > CLarity stickler: Delete "initial" above. As defined in this specificatio= n, *all* > consent is obtained using ICE. Fixed. -Tiru From nobody Thu May 28 09:13: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 BAEA51B2AD3; Wed, 27 May 2015 16:41:43 -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 uVbfycZBf6fG; Wed, 27 May 2015 16:41:42 -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 D38B61B2AD1; Wed, 27 May 2015 16:41:41 -0700 (PDT) Received: by yhom41 with SMTP id m41so7015223yho.1; Wed, 27 May 2015 16:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HDP9NdQvVgkUN7K/kGilmG+FwZ+h3vHclOoVw+ee2F8=; b=UCNhCzOSbjJwh1E4mmBtulJ9szKRPY1oNERoacLMIkjsBcQwKc3ZZUCBXH9U025cVb uJhMsLPz06wRTF1Jlbf/8/eZv90K2pVKrKtXC3hevAv5pvyZL99TllhIh5eCxbkiki8y n3vCmpcJnPNTnIVApSMzPp9tshe/BekBNmKQJjYELmcmUKkGrCFtYTmDhv60hFGxU220 A3qyT6Tmwnkd2iOG5rEGeua/KW3imxZSam3zn9YRwNc9l5SbTynTL+Q9lNsIkUgzOMQL dMKvjn1qfTs77ZwuvqCQN5TYIYAzPa9LlD5B6zOmO4CDkEaHm3Jx8Zy/9dBT3p/pTIZf 7X9Q== MIME-Version: 1.0 X-Received: by 10.170.120.86 with SMTP id m83mr21791758ykb.110.1432770101205; Wed, 27 May 2015 16:41:41 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Wed, 27 May 2015 16:41:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2015 16:41:41 -0700 Message-ID: From: Martin Thomson To: "Black, David" Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 09:13:01 -0700 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: Wed, 27 May 2015 23:41:43 -0000 I apologize for not catching these, but I think that you are collectively headed toward changing the intent of the draft in ways that might not be good. Unfortunately, I'm not always able to consume the amount of email that is produced in relation to this draft. On 27 May 2015 at 15:05, Black, David wrote: > However, the first sentence in section 10 of RFC 5245 says: > > All endpoints MUST send keepalives for each media session. > > Therefore, this draft normatively modifies RFC 5245, but there was no > indication of that modification during IETF Last Call, as the draft > contains neither an Updates: header nor a summary description of changes > to RFC 5245. That's one interpretation. Or, we could say - more explicitly - that this is intentionally contrary to the advice in RFC 5245. We're overriding 5245, not patching it. Other users of RFC 5245 can continue to be bound by the restriction. BTW, no ICE implementation I'm aware of follows the requirement to send keep-alives (I'm certain that some compliant implementations exist, just that my limited exposure hasn't included one). That reduces the risk that a recipient is checking and enforcing that peers are sending keepalives to nil, in case you are concerned about the interop risk. >> >> [4] In Section 4.1, please explain or provide a reference for what "paced" >> >> means in "paced STUN connectivity checks or responses." >> >> Pacing is explained in the same section below. Let us know if this is not >> sufficient/not clear. Actually, "paced" has a specific meaning in ICE and the word was used intentionally: https://tools.ietf.org/html/rfc5245#section-16 The intent is to permit ICE connectivity checking, no more, no less. Absolutely not consent maintenance. Perhaps something like: An endpoint MUST NOT send data toward any transport address unless the receiving endpoint has consented to receive data, unless the messages are those that are used to establish consent. Connectivity checks that are paced as described in Section 16 of [RFC5245] and responses to connectivity checks are permitted. --- I disagree with David about the editorial nature of some of the changes he suggests, but I'm prepared to wait for proposals and discuss them. I'd be very happy if those changes manifested in the form of pull requests. From nobody Thu May 28 09:13: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 CC7901A1AFF; Wed, 27 May 2015 23:30:03 -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 6cldwmjLOWKa; Wed, 27 May 2015 23:29:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C7C1A1AA6; Wed, 27 May 2015 23:29:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25578; q=dns/txt; s=iport; t=1432794599; x=1434004199; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tHyKNHe+wNkkLMaoL9ecc+7dfaoofGmoswAsirBu9ko=; b=PjJIwHmWCP5ug/adOVBetIOuZtGkBxRvUPtKs8U8cdCT9EiMYswTy5Xn UkbVhM1s+MxspUAvsF3Ljip4kgrSNxm62OkW3R7X+PqmME7KOaMVtiuS/ wG0jNOdRKr8TDWq627dCo2WDj8yKF/l2FQtUCY0qLXci4jaTJ1c6LUaPn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnBQABtWZV/49dJa1ZA4MQgTIGwHyIQAKBSkwBAQEBAQGBC4QiAQEBAwEaXwUHBAIBCBEBAgEBAQEKHQchERQDBggBAQQBDQUIiBADCgjOZg2EfgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoJNgWANGiEQBwYLgwaBFgWFDYFehHQrhEKCPIcEgXg6gwKDcYo2XIMqg1kjYYMXb4EDAQYZAiGBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,511,1427760000"; d="scan'208";a="423253716" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 28 May 2015 06:29:57 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t4S6Tvcd018908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 06:29:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 28 May 2015 01:29:56 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Black, David" , "Ram Mohan R (rmohanr)" , joel jaeggli , "muthu.arul@gmail.com" , "Dan Wing (dwing)" , "martin.thomson@gmail.com" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAc0OqAABE7tRA= Date: Thu, 28 May 2015 06:29:56 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478607B9@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.47.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 09:13:01 -0700 Cc: "rtcweb-chairs@tools.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: Thu, 28 May 2015 06:30:04 -0000 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Thursday, May 28, 2015 3:35 AM > To: Ram Mohan R (rmohanr); joel jaeggli; muthu.arul@gmail.com; Dan Wing > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; ops- > dir@ietf.org; rtcweb@ietf.org; Black, David > Cc: Black, David; rtcweb-chairs@tools.ietf.org; Alissa Cooper > (alissa@cooperw.in) > Subject: RE: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-1= 3 >=20 > Unfortunately, one of the major issues just became much more serious. As > part of my issue [1], I wrote: >=20 > I don't > see any RFCs listed as updated by this draft, so I'm guessing that thi= s > is not intended to promulgate new requirements for all uses of ICE and > STUN, but this should be clarified. >=20 > Unfortunately, the required clarification is more than editorial, as upon > further reading, I see this sentence at the end of Section 3 in this draf= t: >=20 > If consent is > performed then there is no need to send keepalive messages. >=20 > However, the first sentence in section 10 of RFC 5245 says: >=20 > All endpoints MUST send keepalives for each media session. >=20 > Therefore, this draft normatively modifies RFC 5245, but there was no > indication of that modification during IETF Last Call, as the draft conta= ins > neither an Updates: header nor a summary description of changes to RFC > 5245. >=20 > This is a serious process problem; please work with your WG chairs and AD > to determine what to do, as your AD (Alissa) owns the decision about what > has to happen to correct this mistake in addition to correcting the text = in the > draft. >=20 > ---------- >=20 > Moving on to concerns beyond the two major issues ... anything not > mentioned here (aside from [1] and [2] covered in my previous message, > plus the above missing info on the updates to RFC 5245) is ok with me. >=20 > > >> [3] In Section 1, please explain what ICE-lite is. A suitable > > >> reference should suffice. > > > > Yes we will add reference to RFC5245 that describes ICE-lite >=20 > Please add a sentence to summarize ICE-lite, not just the reference. NEW: ICE-lite agent defined in section 2.7 of [RFC5245] does not generate connec= tivity checks or runs the ICE state machine, it only needs to be able to respond to connectivity checks. Hence an ICE-lite implementation will not generate consent checks, but will just respond to consent checks it receives. No changes are required to ICE-lite implementations in order to respond to consent checks, as they are processed as normal ICE connectivity checks. >=20 > > >> [4] In Section 4.1, please explain or provide a reference for what > "paced" > > >> means in "paced STUN connectivity checks or responses." > > > > Pacing is explained in the same section below. Let us know if this is > > not sufficient/not clear. > > > > 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 basi= c > > period. Implementations SHOULD set a default interval of 5 seconds= , > > resulting in a period between checks of 4 to 6 seconds. >=20 > It's not clear - the word "paced" is absent, and that explanation shows u= p in > the middle of the next page after the use of "paced." I suggest the foll= owing > two changes to the second paragraph in Section 4.1 for clarity: >=20 > First sentence: >=20 > 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. >=20 > a) Delete "paced" from the first line. > b) Add the following sentence immediately after that first sentence. >=20 > Additional constraints apply to when these checks are allowed to be se= nt, > including a minimum interval between checks, as further specified in t= his > section. >=20 > -- Everything below here is editorial -- >=20 > > >> 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 wou= ld be > useful to state explicitly. > > > > We will add a new applicability section proposed above and also > > modified para 3 of Intro to make it clearer that this draft does not > > change ICE procedures. Please let us know if this solves the comment > above. >=20 > It does not. Please add a sentence to say that consent checks can be > deployed via modifications solely to endpoints that send STUN connectivit= y > checks because implementations are already required to respond to such > checks. A rephrasing of Section 3 would be a good means of adding this. Section 3. NEW: The mechanism proposed in the document is an optional extension to the ICE = protocol, it can be deployed at one end of the two-party communication sess= ion without impact on the other party. >=20 > > >> [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. > > > > 30 second timeout period was selected so that consent checks could be > > sent between 7 to 5 times (to handle packet loss). >=20 > Please add that statement to the draft. NEW: 30 second timeout period was selected so that consent checks could be sent = between 7 to 5 times to handle packet loss. >=20 > > >> [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. > > > > We specifically discussed in WG about how applications should handle > > changes in Consent and it was decided to keep it outside the scope of > > this draft. Para 3 of introduction already has a text that says the sam= e. > > There can be many possibilities if consent is lost or failed depending > > on what the application wants. >=20 > Ok, but .. this is not about "how applications should handle" loss of con= sent; > it's about "how implementations should report" loss of consent. Part of = this > is already in Section 7, which indicates how the application learns that > consent has expired. It would suffice to add a sentence added to that > section to indicate that there are other reasons for loss of ability to t= ransmit > data, and include an example of how at least one other is reported to > applications. NEW: The circuit breaker algorithm discussed in section 7.1 of [I-D.ietf-rtcweb-= rtp-usage] could be one of the reasons for ceasing transmission of media an= d to notify the application about the loss of ability to transmit data. >=20 > > >> [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]. > > > > This again seems some thing outside the scope of this draft as it is > > trying to specify application behavior. Is there some thing that you > > want us to add in the draft for this? >=20 > Nope, this is again about reporting information, not how applications > respond to the reports. In addition, the consumer of this information ma= y > be a network operation tool of some sort as opposed to a WebRTC > application. Specific details of what to track and how to report it belo= ng > elsewhere, but it would be good to at least add a sentence pointing out t= hat > it is useful to track frequency and duration of loss of consent, e.g., to= assist in > troubleshooting application problems. NEW: WebRTC client application may in-turn notify WebRTC server about loss of co= nsent so that it can track frequency and duration of loss of consent , e.g.= , to assist in troubleshooting application problems. Cheers, -Tiru >=20 >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Wednesday, May 27, 2015 3:17 AM > > To: Ram Mohan R (rmohanr); joel jaeggli; muthu.arul@gmail.com; Dan > > Wing (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; > > ops- dir@ietf.org; rtcweb@ietf.org > > Cc: Black, David > > Subject: RE: OPS-Dir review of > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > I'll limit comments here to the two major issues. Quick summary: > > > > [1] Applicability: The proposed text looks generally good, but the defi= nition > > of "consent" needs a couple of clarifications. > > > > [2] Security Considerations: The proposed text isn't sufficient. In ad= dition > > to the new applicability text's reference to the WebRTC security > > architecture draft, a reference to the WebRTC security > considerations > > draft with specific section pointers needs to be added to the security > > considerations section of this draft. > > > > > >> [1] The draft seems to be missing discussion of applicability - > > > >> what environments and/or protocols is this mechanism intended for > > > >> or > > applicable > > > >> to? > > > > > We will add a new section =B3Applicability=B2 after the introduction = section. > > > > I think that proposed applicability section will address most of the co= ncern. > > As part of this, the definition of consent (Section 2) needs elaboratio= n: > > > > Consent: The mechanism of obtaining permission to send to a remote > > transport address. Initial consent is obtained using ICE. > > > > Two important concepts should be clearer: > > - Permission to send is obtained *from the recipient* of the traffic. > > - The traffic to which permission to send applies is *non-ICE* traffic= . > > > > > >> [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). > > > > > > Cryptographically strong STUN transaction IDs are required so that > > > off-path attacker does not replay old consent responses. > > > > > > > > > > > > >>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. > > > > > > We will add the following line to Security Considerations section. > > > > > > NEW: > > > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > > chosen from the interval 0 .. 2**96-1, and be cryptographically stron= g. > > > This is good enough security against an off-path attacker replaying > > > old STUN consent responses. > > > > That's good, but the actual problem is a missing reference. The > > rationale discussion is in draft-ietf-rtcweb-security, so that draft > > needs to be added as a normative reference, plus text added to the > > security considerations section of this consent draft to call > > attention to sections 3.3 and 4.2 of that rtcweb-security draft. This > > is in addition to the citation of sections > > 4.4 and 5.3 of draft-ietf-rtcweb-security-arch in the proposed new > > applicability text. > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > > Sent: Tuesday, May 19, 2015 11:28 AM > > > To: joel jaeggli; Black, David; muthu.arul@gmail.com; Dan Wing > > > (dwing); Tirumaleswar Reddy (tireddy); martin.thomson@gmail.com; > > > ops-dir@ietf.org; rtcweb@ietf.org > > > Subject: Re: OPS-Dir review of > > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > > > Hi David/Joel, > > > > > > Please see inline for my responses. > > > > > > > > > -----Original Message----- > > > From: joel jaeggli > > > Date: Friday, 15 May 2015 4:59 am > > > To: "Black, David" , "muthu.arul@gmail.com" > > > , "dwing@cisco.com" , > Cisco > > > Employee , "tireddy@cisco.com" > > > , "martin.thomson@gmail.com" > , "ops-dir@ietf.org" > > > > > > > > Cc: "rtcweb@ietf.org" , "ietf@ietf.org" > > > > > > Subject: Re: OPS-Dir review of > > > draft-ietf-rtcweb-stun-consent-freshness-13 > > > > > > >Thanks David, > > > > > > > >I'll be looking with interest for the addressing of items 1/2. > > > > > > > >joel > > > > > > > >On 5/14/15 4:21 PM, Black, David wrote: > > > >> 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. > > > > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send using ICE. This draft does not restrict on what > > > applications should use Consent. Currently on webRTC applications > > > use Consent, however any other application that has Similar security > > > requirements can use this mechanism. We will add a new section > > > =B3Applicability=B2 after the introduction section. > > > > > > > > > 2. Applicability > > > > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send using ICE.Verification of peer consent before > > > sending traffic is necessary in deployments like WebRTC to ensure > > > that a malicious JavaScript cannot use the browser as a platform for > > > launching attacks.Section 4.4 and section 5.3 of > > > [I-D.ietf-rtcweb-security-arch] explains why webRTC application needs > consent. > > > > > > Other Applications that have similar security requirement where it > > > is required to verify peer's consent before sending non-ICE packets > > > can use the consent mechanism described in this draft. > > > > > > > > > > > > > > > > > > Also we will modify para 3 of Intro to make it clearer. > > > > > > OLD: > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send. Consent to send applies to a single 5-tuple. Ho= w > > > applications react to changes in consent is not described in this > > > document. > > > > > > > > > > > > NEW: > > > This document defines what it takes to obtain, maintain, and lose > > > consent to send. Consent to send applies to a single 5-tuple. How > > > applications react to changes in consent is not > > > described in this document. The consent mechanism does not update > > > the ICE procedures defined in [RFC 5245]. > > > > > > > > > > > > > > > > > > > > > >> > > > >> [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). > > > > > > Cryptographically strong STUN transaction IDs are required so that > > > off-path attacker does not replay old consent responses. > > > > > > > > > > > > >>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. > > > > > > We will add the following line to Security Considerations section. > > > > > > NEW: > > > > > > Consent requires 96 bits transaction ID to be uniformly and randomly > > > chosen from the interval 0 .. 2**96-1, and be cryptographically stron= g. > > > This is good enough security against an off-path attacker replaying > > > old STUN consent responses. > > > > > > > > > > > > >> > > > >> -- Minor Issues -- > > > >> > > > >> [3] In Section 1, please explain what ICE-lite is. A suitable > > > >> reference should suffice. > > > > > > Yes we will add reference to RFC5245 that describes ICE-lite > > > > > > > > > > > > >> > > > >> [4] In Section 4.1, please explain or provide a reference for > > > >>what "paced" > > > >> means in "paced STUN connectivity checks or responses." > > > > > > Pacing is explained in the same section below. Let us know if this > > > is not sufficient/not clear. > > > > > > 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 secon= ds, > > > resulting in a period between checks of 4 to 6 seconds. > > > > > > > > > > > > > > > >> > > > >> -- 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. > > > > > > Okay, will move this paragraph to Section 3. > > > > > > > > > > > > >> > > > >> idnits 2.13.02 found an unused reference: > > > >> > > > >> =3D=3D Unused Reference: 'I-D.ietf-rtcweb-overview' is defined o= n > > > >>line 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). > > > > > > This reference is not needed. Once we add applicability section we > > > will reference rtcweb-security-arch draft. > > > > > > >> > > > >> --- 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. > > > > > > We will add a new applicability section proposed above and also > > > modified para 3 of Intro to make it clearer that this draft does not > > > change ICE procedures. Please let us know if this solves the comment > above. > > > > > > > > > >> [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. > > > > > > 30 second timeout period was selected so that consent checks could > > > be sent between 7 to 5 times (to handle packet loss). > > > > > > > > > >> [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. > > > > > > We specifically discussed in WG about how applications should handle > > > changes in Consent and it was decided to keep it outside the scope > > > of this draft. Para 3 of introduction already has a text that says th= e same. > > > There can be many possibilities if consent is lost or failed > > > depending on what the application wants. > > > > > > > > > >> [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]. > > > > > > This again seems some thing outside the scope of this draft as it is > > > trying to specify application behavior. Is there some thing that you > > > want us to add in the draft for this? > > > > > > Regards, > > > Ram > > > > > > >> > > > >> 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 01748 > > > >> +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > >> david.black@emc.com Mobile: +1 (978) 394-7754 > > > >> ---------------------------------------------------- > > > >> > > > >> > > > >> > > > > > > > > From nobody Thu May 28 13:19: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 612521A8709; Thu, 28 May 2015 12:39:13 -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 8ev4coN4LE8l; Thu, 28 May 2015 12:39:11 -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 BB23D1A8843; Thu, 28 May 2015 12:39:09 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4SJd0af009722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 May 2015 15:39:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t4SJd0af009722 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1432841943; bh=/zmpxPSJuQQcUBIrbNQvtIf0wck=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=QKk+EJBov/AnT8qv+BkZmeK5Rgdkhch+v54rWc9MKwTOZum3HX1k+STH43BqruO1g xzHJcQLip4G3dGsjC5Cl7FgLIvRKHgadoI+1VtcUkdgPkJwHFpEf9Lf6Ta79YYkzqY Y7AjcQBRiYLKnO1Rv/QCYktnkZilNyC+qsXyYLWo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t4SJd0af009722 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 28 May 2015 15:38:11 -0400 Received: from mxhub37.corp.emc.com (mxhub37.corp.emc.com [128.222.70.104]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4SJU0hB016432 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 15:38:41 -0400 Received: from MXHUB106.corp.emc.com (10.253.58.23) by mxhub37.corp.emc.com (128.222.70.104) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 28 May 2015 15:36:54 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.77]) by MXHUB106.corp.emc.com ([10.253.58.23]) with mapi id 14.03.0224.002; Thu, 28 May 2015 15:36:55 -0400 From: "Black, David" To: Martin Thomson Thread-Topic: OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAc0OqAAA31aYAAIJaowA== Date: Thu, 28 May 2015 19:36:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.55.127] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 13:19:02 -0700 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: Thu, 28 May 2015 19:39:13 -0000 SGkgTWFydGluLA0KDQo+IE9uIDI3IE1heSAyMDE1IGF0IDE1OjA1LCBCbGFjaywgRGF2aWQgPGRh dmlkLmJsYWNrQGVtYy5jb20+IHdyb3RlOg0KPiA+IEhvd2V2ZXIsIHRoZSBmaXJzdCBzZW50ZW5j ZSBpbiBzZWN0aW9uIDEwIG9mIFJGQyA1MjQ1IHNheXM6DQo+ID4NCj4gPiAgICBBbGwgZW5kcG9p bnRzIE1VU1Qgc2VuZCBrZWVwYWxpdmVzIGZvciBlYWNoIG1lZGlhIHNlc3Npb24uDQo+ID4NCj4g PiBUaGVyZWZvcmUsIHRoaXMgZHJhZnQgbm9ybWF0aXZlbHkgbW9kaWZpZXMgUkZDIDUyNDUsIGJ1 dCB0aGVyZSB3YXMgbm8NCj4gPiBpbmRpY2F0aW9uIG9mIHRoYXQgbW9kaWZpY2F0aW9uIGR1cmlu ZyBJRVRGIExhc3QgQ2FsbCwgYXMgdGhlIGRyYWZ0DQo+ID4gY29udGFpbnMgbmVpdGhlciBhbiBV cGRhdGVzOiBoZWFkZXIgbm9yIGEgc3VtbWFyeSBkZXNjcmlwdGlvbiBvZiBjaGFuZ2VzDQo+ID4g dG8gUkZDIDUyNDUuDQo+IA0KPiBUaGF0J3Mgb25lIGludGVycHJldGF0aW9uLiAgT3IsIHdlIGNv dWxkIHNheSAtIG1vcmUgZXhwbGljaXRseSAtIHRoYXQNCj4gdGhpcyBpcyBpbnRlbnRpb25hbGx5 IGNvbnRyYXJ5IHRvIHRoZSBhZHZpY2UgaW4gUkZDIDUyNDUuICBXZSdyZQ0KPiBvdmVycmlkaW5n IDUyNDUsIG5vdCBwYXRjaGluZyBpdC4gIE90aGVyIHVzZXJzIG9mIFJGQyA1MjQ1IGNhbg0KPiBj b250aW51ZSB0byBiZSBib3VuZCBieSB0aGUgcmVzdHJpY3Rpb24uDQoNClRoYXQncyBmaW5lLCBi dXQgc29tZXRoaW5nIGRvZXMgaGF2ZSB0byBiZSBkb25lIGFib3V0IHRoYXQgUkZDIDUyNDUgIk1V U1QiDQpyZXF1aXJlbWVudCwgd2hpY2ggaXMgYSAicmVxdWlyZW1lbnQiIG5vdCBqdXN0ICJhZHZp Y2UiIDstKS4NCg0KSSdkIGV4cGVjdCB0aGF0IGV2ZW4gb3ZlcnJpZGluZyBSRkMgNTI0NSBjb3Vu dHMgYXMgYW4gVXBkYXRlLA0KYmVjYXVzZSB0aGUgcmVzdWx0IHdvdWxkIGJlIHRoYXQgdGhlIG9y aWdpbmFsIFJGQyA1MjQ1ICJNVVNUIiByZXF1aXJlbWVudA0KaXMgbm8gbG9uZ2VyIGdsb2JhbGx5 IGFwcGxpY2FibGUgdG8gYWxsIHVzZXMgb2YgUkZDIDUyNDUuICBJbiBvdGhlciB3b3JkcywNCm92 ZXJyaWRpbmcgUkZDIDUyNDUgZWZmZWN0aXZlbHkgcmV3cml0ZXMgdGhlICJNVVNUIiB0byBiZWNv bWUgIk1VU1QsIGV4Y2VwdA0KYXMgZnVydGhlciBzcGVjaWZpZWQgYnkgdGhlIGNvbnNlbnQgUkZD LiINCg0KU29ycnkgdG8gcHV0IHRoZSBlbXBoYXNpcyBvbiB0aGUgIlVwZGF0ZSIgcHJvY2Vzcywg YnV0IEkndmUgcmVjZW50bHkgaGFkIGENCip2ZXJ5KiBsb25nIGRpc2N1c3Npb24gYWJvdXQgd2hl dGhlciBvciBub3QgaXQgd2FzIG9rIGZvciBhbm90aGVyIGRyYWZ0IHRvDQptb2RpZnkgYW4gdW5k ZXJseWluZyBSRkMgLSB0aGUgYW5zd2VyIGluIHRoYXQgb3RoZXIgY2FzZSB3YXMgIjxibGVlcD4g Tk8hIg0KYW5kIHNvbWUgaW50ZXJlc3RpbmcgdGV4dCBlZGl0aW5nIHJlc3VsdGVkLiAgSW4gY29u dHJhc3QsIGZvciB0aGUgcHJlc2VudA0Kc2l0dWF0aW9uIGNhc2UsIEkgd291bGQgdGhpbmsgdGhh dCBvdmVycmlkaW5nIFJGQyA1MjQ1IGlzIG9rLCBidXQgdGhhdA0KY2hhbmdlIGRvZXMgbmVlZCB0 byBiZSBjYWxsZWQgb3V0Lg0KDQo+IEFjdHVhbGx5LCAicGFjZWQiIGhhcyBhIHNwZWNpZmljIG1l YW5pbmcgaW4gSUNFIGFuZCB0aGUgd29yZCB3YXMgdXNlZA0KPiBpbnRlbnRpb25hbGx5OiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTE2DQo+IA0KPiBUaGUgaW50 ZW50IGlzIHRvIHBlcm1pdCBJQ0UgY29ubmVjdGl2aXR5IGNoZWNraW5nLCBubyBtb3JlLCBubyBs ZXNzLg0KPiBBYnNvbHV0ZWx5IG5vdCBjb25zZW50IG1haW50ZW5hbmNlLg0KPiANCj4gUGVyaGFw cyBzb21ldGhpbmcgbGlrZToNCj4gDQo+ICAgIEFuIGVuZHBvaW50IE1VU1QgTk9UIHNlbmQgZGF0 YSB0b3dhcmQgYW55IHRyYW5zcG9ydCBhZGRyZXNzIHVubGVzcw0KPiB0aGUgcmVjZWl2aW5nIGVu ZHBvaW50IGhhcyBjb25zZW50ZWQgdG8gcmVjZWl2ZSBkYXRhLCB1bmxlc3MgdGhlDQo+IG1lc3Nh Z2VzIGFyZSB0aG9zZSB0aGF0IGFyZSB1c2VkIHRvIGVzdGFibGlzaCBjb25zZW50LiAgQ29ubmVj dGl2aXR5DQo+IGNoZWNrcyB0aGF0IGFyZSBwYWNlZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAx NiBvZiBbUkZDNTI0NV0gYW5kDQo+IHJlc3BvbnNlcyB0byBjb25uZWN0aXZpdHkgY2hlY2tzIGFy ZSBwZXJtaXR0ZWQuDQoNClRoYXQgbmV3IHRleHQgbG9va3MgZ29vZC4NCg0KPiAtLS0NCj4gSSBk aXNhZ3JlZSB3aXRoIERhdmlkIGFib3V0IHRoZSBlZGl0b3JpYWwgbmF0dXJlIG9mIHNvbWUgb2Yg dGhlDQo+IGNoYW5nZXMgaGUgc3VnZ2VzdHMsIGJ1dCBJJ20gcHJlcGFyZWQgdG8gd2FpdCBmb3Ig cHJvcG9zYWxzIGFuZA0KPiBkaXNjdXNzIHRoZW0uICBJJ2QgYmUgdmVyeSBoYXBweSBpZiB0aG9z ZSBjaGFuZ2VzIG1hbmlmZXN0ZWQgaW4gdGhlDQo+IGZvcm0gb2YgcHVsbCByZXF1ZXN0cy4NCg0K VG8gdGhlIGV4dGVudCB0aGF0IG15ICJlZGl0b3JpYWwiIHN1Z2dlc3Rpb25zIGFyZW4ndCBhY3R1 YWxseSBlZGl0b3JpYWwsDQp0aGUgc3VnZ2VzdGlvbnMgYXJlIHByb2JhYmx5IHdyb25nLiAgQXMg dGhleSdyZSBpbnRlbmRlZCB0byBiZSBlZGl0b3JpYWwsDQpJJ20gb2sgd2l0aCB0aGVtIGJlaW5n IGlnbm9yZWQgb3IgZGVhbHQgd2l0aCBpbiBzb21lIG90aGVyIGZhc2hpb24uDQoNClRoYW5rcywN Ci0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYXJ0aW4g VGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVz ZGF5LCBNYXkgMjcsIDIwMTUgNzo0MiBQTQ0KPiBUbzogQmxhY2ssIERhdmlkDQo+IENjOiBSYW0g TW9oYW4gUiAocm1vaGFucik7IGpvZWwgamFlZ2dsaTsgbXV0aHUuYXJ1bEBnbWFpbC5jb207IERh biBXaW5nDQo+IChkd2luZyk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IG9wcy1kaXJA aWV0Zi5vcmc7IHJ0Y3dlYkBpZXRmLm9yZzsNCj4gcnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9y ZzsgQWxpc3NhIENvb3BlciAoYWxpc3NhQGNvb3BlcncuaW4pDQo+IFN1YmplY3Q6IFJlOiBPUFMt RGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEz DQo+IA0KPiBJIGFwb2xvZ2l6ZSBmb3Igbm90IGNhdGNoaW5nIHRoZXNlLCBidXQgSSB0aGluayB0 aGF0IHlvdSBhcmUNCj4gY29sbGVjdGl2ZWx5IGhlYWRlZCB0b3dhcmQgY2hhbmdpbmcgdGhlIGlu dGVudCBvZiB0aGUgZHJhZnQgaW4gd2F5cw0KPiB0aGF0IG1pZ2h0IG5vdCBiZSBnb29kLiAgVW5m b3J0dW5hdGVseSwgSSdtIG5vdCBhbHdheXMgYWJsZSB0byBjb25zdW1lDQo+IHRoZSBhbW91bnQg b2YgZW1haWwgdGhhdCBpcyBwcm9kdWNlZCBpbiByZWxhdGlvbiB0byB0aGlzIGRyYWZ0Lg0KPiAN Cj4gT24gMjcgTWF5IDIwMTUgYXQgMTU6MDUsIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1j LmNvbT4gd3JvdGU6DQo+ID4gSG93ZXZlciwgdGhlIGZpcnN0IHNlbnRlbmNlIGluIHNlY3Rpb24g MTAgb2YgUkZDIDUyNDUgc2F5czoNCj4gPg0KPiA+ICAgIEFsbCBlbmRwb2ludHMgTVVTVCBzZW5k IGtlZXBhbGl2ZXMgZm9yIGVhY2ggbWVkaWEgc2Vzc2lvbi4NCj4gPg0KPiA+IFRoZXJlZm9yZSwg dGhpcyBkcmFmdCBub3JtYXRpdmVseSBtb2RpZmllcyBSRkMgNTI0NSwgYnV0IHRoZXJlIHdhcyBu bw0KPiA+IGluZGljYXRpb24gb2YgdGhhdCBtb2RpZmljYXRpb24gZHVyaW5nIElFVEYgTGFzdCBD YWxsLCBhcyB0aGUgZHJhZnQNCj4gPiBjb250YWlucyBuZWl0aGVyIGFuIFVwZGF0ZXM6IGhlYWRl ciBub3IgYSBzdW1tYXJ5IGRlc2NyaXB0aW9uIG9mIGNoYW5nZXMNCj4gPiB0byBSRkMgNTI0NS4N Cj4gDQo+IFRoYXQncyBvbmUgaW50ZXJwcmV0YXRpb24uICBPciwgd2UgY291bGQgc2F5IC0gbW9y ZSBleHBsaWNpdGx5IC0gdGhhdA0KPiB0aGlzIGlzIGludGVudGlvbmFsbHkgY29udHJhcnkgdG8g dGhlIGFkdmljZSBpbiBSRkMgNTI0NS4gIFdlJ3JlDQo+IG92ZXJyaWRpbmcgNTI0NSwgbm90IHBh dGNoaW5nIGl0LiAgT3RoZXIgdXNlcnMgb2YgUkZDIDUyNDUgY2FuDQo+IGNvbnRpbnVlIHRvIGJl IGJvdW5kIGJ5IHRoZSByZXN0cmljdGlvbi4NCj4gDQo+IEJUVywgbm8gSUNFIGltcGxlbWVudGF0 aW9uIEknbSBhd2FyZSBvZiBmb2xsb3dzIHRoZSByZXF1aXJlbWVudCB0bw0KPiBzZW5kIGtlZXAt YWxpdmVzIChJJ20gY2VydGFpbiB0aGF0IHNvbWUgY29tcGxpYW50IGltcGxlbWVudGF0aW9ucw0K PiBleGlzdCwganVzdCB0aGF0IG15IGxpbWl0ZWQgZXhwb3N1cmUgaGFzbid0IGluY2x1ZGVkIG9u ZSkuICBUaGF0DQo+IHJlZHVjZXMgdGhlIHJpc2sgdGhhdCBhIHJlY2lwaWVudCBpcyBjaGVja2lu ZyBhbmQgZW5mb3JjaW5nIHRoYXQgcGVlcnMNCj4gYXJlIHNlbmRpbmcga2VlcGFsaXZlcyB0byBu aWwsIGluIGNhc2UgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQgdGhlDQo+IGludGVyb3Agcmlzay4N Cj4gDQo+ID4+ID4+IFs0XSBJbiBTZWN0aW9uIDQuMSwgcGxlYXNlIGV4cGxhaW4gb3IgcHJvdmlk ZSBhIHJlZmVyZW5jZSBmb3Igd2hhdA0KPiAicGFjZWQiDQo+ID4+ID4+IG1lYW5zIGluICJwYWNl ZCBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3Mgb3IgcmVzcG9uc2VzLiINCj4gPj4NCj4gPj4gUGFj aW5nIGlzIGV4cGxhaW5lZCBpbiB0aGUgc2FtZSBzZWN0aW9uIGJlbG93LiBMZXQgdXMga25vdyBp ZiB0aGlzIGlzIG5vdA0KPiA+PiBzdWZmaWNpZW50L25vdCBjbGVhci4NCj4gDQo+IEFjdHVhbGx5 LCAicGFjZWQiIGhhcyBhIHNwZWNpZmljIG1lYW5pbmcgaW4gSUNFIGFuZCB0aGUgd29yZCB3YXMg dXNlZA0KPiBpbnRlbnRpb25hbGx5OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0 NSNzZWN0aW9uLTE2DQo+IA0KPiBUaGUgaW50ZW50IGlzIHRvIHBlcm1pdCBJQ0UgY29ubmVjdGl2 aXR5IGNoZWNraW5nLCBubyBtb3JlLCBubyBsZXNzLg0KPiBBYnNvbHV0ZWx5IG5vdCBjb25zZW50 IG1haW50ZW5hbmNlLg0KPiANCj4gUGVyaGFwcyBzb21ldGhpbmcgbGlrZToNCj4gDQo+ICAgIEFu IGVuZHBvaW50IE1VU1QgTk9UIHNlbmQgZGF0YSB0b3dhcmQgYW55IHRyYW5zcG9ydCBhZGRyZXNz IHVubGVzcw0KPiB0aGUgcmVjZWl2aW5nIGVuZHBvaW50IGhhcyBjb25zZW50ZWQgdG8gcmVjZWl2 ZSBkYXRhLCB1bmxlc3MgdGhlDQo+IG1lc3NhZ2VzIGFyZSB0aG9zZSB0aGF0IGFyZSB1c2VkIHRv IGVzdGFibGlzaCBjb25zZW50LiAgQ29ubmVjdGl2aXR5DQo+IGNoZWNrcyB0aGF0IGFyZSBwYWNl ZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAxNiBvZiBbUkZDNTI0NV0gYW5kDQo+IHJlc3BvbnNl cyB0byBjb25uZWN0aXZpdHkgY2hlY2tzIGFyZSBwZXJtaXR0ZWQuDQo+IA0KPiANCj4gLS0tDQo+ IEkgZGlzYWdyZWUgd2l0aCBEYXZpZCBhYm91dCB0aGUgZWRpdG9yaWFsIG5hdHVyZSBvZiBzb21l IG9mIHRoZQ0KPiBjaGFuZ2VzIGhlIHN1Z2dlc3RzLCBidXQgSSdtIHByZXBhcmVkIHRvIHdhaXQg Zm9yIHByb3Bvc2FscyBhbmQNCj4gZGlzY3VzcyB0aGVtLiAgSSdkIGJlIHZlcnkgaGFwcHkgaWYg dGhvc2UgY2hhbmdlcyBtYW5pZmVzdGVkIGluIHRoZQ0KPiBmb3JtIG9mIHB1bGwgcmVxdWVzdHMu DQo= From nobody Thu May 28 13:30:59 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 AF28F1A88E3; Thu, 28 May 2015 13:25: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 az4miMpchFGM; Thu, 28 May 2015 13:25:41 -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 9AB461A88E7; Thu, 28 May 2015 13:25:41 -0700 (PDT) Received: by wizo1 with SMTP id o1so76707002wiz.1; Thu, 28 May 2015 13:25:40 -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=v9xCihG3Copr+Ys0DqTt2GKP49l6twA/jkz0gKf3Y2g=; b=WgNicSkGmpqX5udiwYWbIR98K1MvffDfruq7sG5sg0X21bGr5pL0G/1m5mOJIQymfw 6d7HeVcv2oQlp+8qyiat8aRS6gN/SEg6yAWkCM8gjY+NiDTjgDhTnpABHV1wvutUUXD1 yL6L9UGthrNDPqnqt5wASue/8ifykBRaOzOxlsThcvJlIe2aKIY1C5T6G+dNydbHDSML TmJHK/bqSiCTunx8vbcx6y1/FlacU4NgRAtQYzpGeCQdF1LBlZr4ofwYK02saxHkipad nt4gAdN9Ln6Csm+QZlwmpMtJB1LRCFBngjN7TINReQeu+9XZdHd88DbVwymtmpMvl2bM G3XA== MIME-Version: 1.0 X-Received: by 10.194.189.80 with SMTP id gg16mr8612250wjc.9.1432844740404; Thu, 28 May 2015 13:25:40 -0700 (PDT) Received: by 10.194.91.133 with HTTP; Thu, 28 May 2015 13:25:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 May 2015 13:25:40 -0700 Message-ID: From: Ted Hardie To: "Black, David" Content-Type: multipart/alternative; boundary=047d7bb03f9cc529dc05172a29b3 Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 13:30:58 -0700 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 28 May 2015 20:25:43 -0000 --047d7bb03f9cc529dc05172a29b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 "Upd= ates" 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 the 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 out. regards, Ted HArdie=E2=80=8B --047d7bb03f9cc529dc05172a29b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,
<= br>
On Thu, May 28, 2015 at 12:36 PM, Black, Davi= d <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."

=E2=80=8BSo I agree with you that this must be called out, but I th= ink "Updates" is wrong for the draft'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 o= f messages to optimize the combination of heartbeat and consent."=C2= =A0 We are not updating RFC 5245 thereby, because we are neither changing i= ts 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).=C2=A0 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.=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 friendly AD, and we await her reading on next steps on this.=C2=A0 I= n either approach, however, this will get called out.

regards,

Ted HArdie=E2=80=8B

--047d7bb03f9cc529dc05172a29b3-- From nobody Thu May 28 18:23: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 A20F41A00F0; Thu, 28 May 2015 18:23:50 -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 sjfAtF3OFoxU; Thu, 28 May 2015 18:23:48 -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 441E81A006C; Thu, 28 May 2015 18:23:46 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-bf-5567bfa18d7e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.E2.04401.1AFB7655; Fri, 29 May 2015 03:23:45 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Fri, 29 May 2015 03:23:44 +0200 From: Christer Holmberg To: Ted Hardie , "Black, David" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAc0OqAAAFiwoAAKb4SAAABtAIAAA58WwA= Date: Fri, 29 May 2015 01:23:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D86E037ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM+Jvre7C/emhBismylpsPbyW3eLVqTWM Fr1NS5gt5ux6wGSx9l87u0XjXDsHNo+zRxYwehw5MpvFY+esu+weS5b8ZPL4cvkzWwBrFJdN SmpOZllqkb5dAldG194VzAX3KioW3DrM0sC4p7SLkZNDQsBEouH2XkYIW0ziwr31bF2MXBxC AkcZJc4+mcAC4SxmlGj9M5m1i5GDg03AQqL7nzaIKSLgKXHqpwhICbPAFkaJabM/sIMMEhYI lbg7cRWYLSIQJvH26DImCNtPYvOfJ+wgvSwCqhLrzrKBhHkFfCVWfTnICLHqLpPEo43/wHo5 BQIl3s9YCtbLCHTc91NrwGxmAXGJW0/mM0EcLSCxZM95ZghbVOLl43+sELaSxKLbn6Hq8yU2 Xb3PDrFMUOLkzCcsExhFZyEZNQtJ2SwkZbOATmUW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTx BYzsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECI/bglt+qOxgvv3E8xCjAwajEw/tgXVqo EGtiWXFl7iFGaQ4WJXFez66QUCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MXrWfVCskLwav ccmq+SnQUn01LzC1+cKa4nq7hm3Gc7WY+433N7/l5BLUP3g9Y/3eu8ePNVeyTNvlFHHg6Oek hUy1azesVHc2zF4v+rLUaGLhvO8S+W5r/tSv0ghVYTzR7Nhtv4C3dsE/d6Epy6V/NIQETH4u 1pF3oOTjQutzFdeuCWeZH8lXYinOSDTUYi4qTgQALkM9HrkCAAA= Archived-At: 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 01:23:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D86E037ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KU2VjdGlvbiAyMC4yLjMgb2YgUkZDIDUyNDUgc2F5czoNCg0K4oCcU1RVTiBrZWVw YWxpdmVzIChpbiB0aGUgZm9ybSBvZiBTVFVOIEJpbmRpbmcgSW5kaWNhdGlvbnMpIGFyZSBzZW50 IGluDQogICAgICAgICAgICAgIHRoZSBtaWRkbGUgb2YgYSBtZWRpYSBzZXNzaW9uLiAgSG93ZXZl ciwgdGhleSBhcmUgc2VudCBvbmx5IGluIHRoZQ0KICAgICAgICAgICAgICBhYnNlbmNlIG9mIGFj dHVhbCBtZWRpYSB0cmFmZmljLuKAnQ0KDQpTbywgaW4gdGhlIGNvbnNlbnQgZHJhZnQgd2UgY291 bGQgc2F5IHRoYXQsIGZyb20gYSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVz dHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEgdHJhZmZpYy4gVGhhdCB3b3VsZCB0aGVuIGltcGxpY2l0 bHkgbWVhbiB0aGF0IGFjdHVhbCBrZWVwYWxpdmVzIGFyZW7igJl0IHNlbnQgd2hlbiBjb25zZW50 IGlzIHVzZWQuIFRoYXQgd2F5LCB0aGUgY29uc2VudCBzcGVjIHdvdWxkIGJlIGNvbXBsaWFudCB0 byA1MjQ1LCBhbmQgdGhlcmUgd291bGQgYmUgbm8gbmVlZCBmb3IgYW55IHVwZGF0ZSBldGPigKYN Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6IDI4IE1heSAy MDE1IDIzOjI2DQpUbzogQmxhY2ssIERhdmlkDQpDYzogcnRjd2ViLWNoYWlyc0B0b29scy5pZXRm Lm9yZzsgam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYub3JnOyBydGN3ZWJAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1z dHVuLWNvbnNlbnQtZnJlc2huZXNzLTEzDQoNCkhpIERhdmlkLA0KDQpPbiBUaHUsIE1heSAyOCwg MjAxNSBhdCAxMjozNiBQTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0 bzpkYXZpZC5ibGFja0BlbWMuY29tPj4NCg0KSSdkIGV4cGVjdCB0aGF0IGV2ZW4gb3ZlcnJpZGlu ZyBSRkMgNTI0NSBjb3VudHMgYXMgYW4gVXBkYXRlLA0KYmVjYXVzZSB0aGUgcmVzdWx0IHdvdWxk IGJlIHRoYXQgdGhlIG9yaWdpbmFsIFJGQyA1MjQ1ICJNVVNUIiByZXF1aXJlbWVudA0KaXMgbm8g bG9uZ2VyIGdsb2JhbGx5IGFwcGxpY2FibGUgdG8gYWxsIHVzZXMgb2YgUkZDIDUyNDUuICBJbiBv dGhlciB3b3JkcywNCm92ZXJyaWRpbmcgUkZDIDUyNDUgZWZmZWN0aXZlbHkgcmV3cml0ZXMgdGhl ICJNVVNUIiB0byBiZWNvbWUgIk1VU1QsIGV4Y2VwdA0KYXMgZnVydGhlciBzcGVjaWZpZWQgYnkg dGhlIGNvbnNlbnQgUkZDLiINCg0K4oCLU28gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoaXMgbXVz dCBiZSBjYWxsZWQgb3V0LCBidXQgSSB0aGluayAiVXBkYXRlcyIgaXMgd3JvbmcgZm9yIHRoZSBk cmFmdCdzIGN1cnJlbnQgaW50ZW50LiAgSSB0aGluayB3aGF0IE1hcnRpbiBoYXMgc2FpZCBhbW91 bnRzIHRvICJXZSBoYXZlIGNob3NlbiB0byBmb2xsb3cgUkZDIDUyNDUgZXhjZXB0IGFzIGRldGFp bGVkIGluIHNlY3Rpb25zIFggYW5kIFksIHdoZXJlIHdlIHVzZSBhIGRpZmZlcmVudCBzZXQgb2Yg bWVzc2FnZXMgdG8gb3B0aW1pemUgdGhlIGNvbWJpbmF0aW9uIG9mIGhlYXJ0YmVhdCBhbmQgY29u c2VudC4iICBXZSBhcmUgbm90IHVwZGF0aW5nIFJGQyA1MjQ1IHRoZXJlYnksIGJlY2F1c2Ugd2Ug YXJlIG5laXRoZXIgY2hhbmdpbmcgaXRzIGNvcmUgc2VtYW50aWNzIG5vciBvZmZlcmluZyB0byBh ZGQgYSBuZXcsIGdlbmVyYWwgc2VtYW50aWMgdG8gUkZDIDUyNDUgKHdlIGNvdWxkIGhhdmUgbWFk ZSB0aGF0IGNob2ljZSwgYnV0IGFyZSBub3QgZG9pbmcgc28gbm93KS4gIEluc3RlYWQgb2YgdXBk YXRpbmcgUkZDIDUyNDUsIGluIG90aGVyIHdvcmRzLCB3ZSBhcmUgbGltaXRpbmcgb3VyIHJlZmVy ZW5jZSB0byBpdC4NClRoYXQgc2hvdWxkIGJlIGRvbmUgZXhwbGljaXRseSwgYW5kIEkgdGhpbmsg aXQgc2hvdWxkIGJlIGNhbGxlZCBpdCBzdWZmaWljaWVudGx5IHRoYXQgYSBuZXcgc3BpbiBvZiB0 aGUgZHJhZnQgbGlrZWx5IG5lZWRzIGEgbmV3IHJvdW5kIG9mIHJldmlldy4gIEJ1dCBJIGRvbid0 IHRoaW5rIHdlIGFyZSByZXF1aXJlZCB0byB1cGRhdGUgUkZDIDUyNDUgdG8gZ2V0IHRoYXQgZG9u ZS4NCkkndmUgcmVmZXJyZWQgdGhlIG1hdHRlciB0byBvdXIgZnJpZW5kbHkgQUQsIGFuZCB3ZSBh d2FpdCBoZXIgcmVhZGluZyBvbiBuZXh0IHN0ZXBzIG9uIHRoaXMuICBJbiBlaXRoZXIgYXBwcm9h Y2gsIGhvd2V2ZXIsIHRoaXMgd2lsbCBnZXQgY2FsbGVkIG91dC4NCnJlZ2FyZHMsDQpUZWQgSEFy ZGll4oCLDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D86E037ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U2VjdGlvbiAyMC4y LjMgb2YgUkZDIDUyNDUgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtaW5kZW50OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKAnFNUVU4ga2VlcGFsaXZlcyAoaW4gdGhl IGZvcm0gb2YgU1RVTiBCaW5kaW5nIEluZGljYXRpb25zKSBhcmUgc2VudCBpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBt aWRkbGUgb2YgYSBtZWRpYSBzZXNzaW9uLiZuYnNwOyBIb3dldmVyLA0KPGI+dGhleSBhcmUgc2Vu dCBvbmx5IGluIHRoZTxvOnA+PC9vOnA+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhYnNlbmNlIG9mIGFjdHVhbCBtZWRpYSB0cmFmZmlj PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+LuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ U28sIGluIHRoZSBjb25zZW50IGRyYWZ0IHdlIGNvdWxkIHNheSB0aGF0LCBmcm9tIGEga2VlcGFs aXZlIHBlcnNwZWN0aXZlLCBjb25zZW50IHJlcXVlc3RzIGFyZSBjb25zaWRlcmVkIG1lZGlhIHRy YWZmaWMuIFRoYXQgd291bGQNCiB0aGVuIGltcGxpY2l0bHkgbWVhbiB0aGF0IGFjdHVhbCBrZWVw YWxpdmVzIGFyZW7igJl0IHNlbnQgd2hlbiBjb25zZW50IGlzIHVzZWQuIFRoYXQgd2F5LCB0aGUg Y29uc2VudCBzcGVjIHdvdWxkIGJlIGNvbXBsaWFudCB0byA1MjQ1LCBhbmQgdGhlcmUgd291bGQg YmUgbm8gbmVlZCBmb3IgYW55IHVwZGF0ZSBldGPigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVkIEhh cmRpZTxicj4NCjxiPlNlbnQ6PC9iPiAyOCBNYXkgMjAxNSAyMzoyNjxicj4NCjxiPlRvOjwvYj4g QmxhY2ssIERhdmlkPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3Jn OyBqb2VsIGphZWdnbGk7IG9wcy1kaXJAaWV0Zi5vcmc7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1y dGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPkhpIERhdmlkLCA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWF5IDI4LCAyMDE1IGF0IDEyOjM2 IFBNLCBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJJ2QgZXhwZWN0 IHRoYXQgZXZlbiBvdmVycmlkaW5nIFJGQyA1MjQ1IGNvdW50cyBhcyBhbiBVcGRhdGUsPGJyPg0K YmVjYXVzZSB0aGUgcmVzdWx0IHdvdWxkIGJlIHRoYXQgdGhlIG9yaWdpbmFsIFJGQyA1MjQ1ICZx dW90O01VU1QmcXVvdDsgcmVxdWlyZW1lbnQ8YnI+DQppcyBubyBsb25nZXIgZ2xvYmFsbHkgYXBw bGljYWJsZSB0byBhbGwgdXNlcyBvZiBSRkMgNTI0NS4mbmJzcDsgSW4gb3RoZXIgd29yZHMsPGJy Pg0Kb3ZlcnJpZGluZyBSRkMgNTI0NSBlZmZlY3RpdmVseSByZXdyaXRlcyB0aGUgJnF1b3Q7TVVT VCZxdW90OyB0byBiZWNvbWUgJnF1b3Q7TVVTVCwgZXhjZXB0PGJyPg0KYXMgZnVydGhlciBzcGVj aWZpZWQgYnkgdGhlIGNvbnNlbnQgUkZDLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+ 4oCLU28gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoaXMgbXVzdCBiZSBjYWxsZWQgb3V0LCBidXQg SSB0aGluayAmcXVvdDtVcGRhdGVzJnF1b3Q7IGlzIHdyb25nIGZvciB0aGUgZHJhZnQncyBjdXJy ZW50IGludGVudC4mbmJzcDsgSSB0aGluayB3aGF0IE1hcnRpbiBoYXMgc2FpZCBhbW91bnRzIHRv ICZxdW90O1dlIGhhdmUNCiBjaG9zZW4gdG8gZm9sbG93IFJGQyA1MjQ1IGV4Y2VwdCBhcyBkZXRh aWxlZCBpbiBzZWN0aW9ucyBYIGFuZCBZLCB3aGVyZSB3ZSB1c2UgYSBkaWZmZXJlbnQgc2V0IG9m IG1lc3NhZ2VzIHRvIG9wdGltaXplIHRoZSBjb21iaW5hdGlvbiBvZiBoZWFydGJlYXQgYW5kIGNv bnNlbnQuJnF1b3Q7Jm5ic3A7IFdlIGFyZSBub3QgdXBkYXRpbmcgUkZDIDUyNDUgdGhlcmVieSwg YmVjYXVzZSB3ZSBhcmUgbmVpdGhlciBjaGFuZ2luZyBpdHMgY29yZSBzZW1hbnRpY3Mgbm9yDQog b2ZmZXJpbmcgdG8gYWRkIGEgbmV3LCBnZW5lcmFsIHNlbWFudGljIHRvIFJGQyA1MjQ1ICh3ZSBj b3VsZCBoYXZlIG1hZGUgdGhhdCBjaG9pY2UsIGJ1dCBhcmUgbm90IGRvaW5nIHNvIG5vdykuJm5i c3A7IEluc3RlYWQgb2YgdXBkYXRpbmcgUkZDIDUyNDUsIGluIG90aGVyIHdvcmRzLCB3ZSBhcmUg bGltaXRpbmcgb3VyIHJlZmVyZW5jZSB0byBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+VGhhdCBzaG91bGQgYmUgZG9uZSBleHBsaWNpdGx5LCBhbmQgSSB0aGluayBpdCBzaG91bGQg YmUgY2FsbGVkIGl0IHN1ZmZpaWNpZW50bHkgdGhhdCBhIG5ldyBzcGluIG9mIHRoZSBkcmFmdCBs aWtlbHkgbmVlZHMgYSBuZXcgcm91bmQgb2YgcmV2aWV3LiZuYnNwOyBCdXQgSSBkb24ndCB0aGlu aw0KIHdlIGFyZSByZXF1aXJlZCB0byB1cGRhdGUgUkZDIDUyNDUgdG8gZ2V0IHRoYXQgZG9uZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+SSd2ZSByZWZlcnJlZCB0aGUgbWF0dGVyIHRv IG91ciBmcmllbmRseSBBRCwgYW5kIHdlIGF3YWl0IGhlciByZWFkaW5nIG9uIG5leHQgc3RlcHMg b24gdGhpcy4mbmJzcDsgSW4gZWl0aGVyIGFwcHJvYWNoLCBob3dldmVyLCB0aGlzIHdpbGwgZ2V0 IGNhbGxlZCBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPnJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5UZWQg SEFyZGll4oCLPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D86E037ESESSMB209erics_-- From nobody Thu May 28 18:57: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 1195F1A01F7; Thu, 28 May 2015 18:57:39 -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 LZzOIfmCdLYP; Thu, 28 May 2015 18:57:36 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717A91A03A3; Thu, 28 May 2015 18:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24670; q=dns/txt; s=iport; t=1432864643; x=1434074243; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sKE/CyqfVz8H55HZLAuDvvqDwuJTabfm6C5xmWo9ATw=; b=XMThhg5+JMx0KJ0d66ErvZseGdf+U/KbvAwbUyXTW8jsKL5O7E/h6RaU 3LJ7rVBLa6uvOagKQxCWfHriNJhjsxD0Iug6QdP/GdwS755MwB5NrMl1P BFz/wlRMS4F+maWQdwftMDZTv1UteVNYdgDhPDD6Jx+cZy4zKoMjEqPNh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBADUxmdV/4kNJK1cgkVLVF4Ggxi6ADwqCYFahXcCHIEsOBQBAQEBAQEBgQqEIgEBAQQjCkwQAgEIEQQBAQsdAwICAjAUCQgCBAENBQiIJQ2yAKQQAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhFUxBgGCaC+BFgWHJ4thhDWIAz6NaYdfI2GBKRyBUm+BAwc8gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,514,1427760000"; d="scan'208,217";a="154436621" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 29 May 2015 01:57:22 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4T1vM4E003428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 01:57:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 28 May 2015 20:57:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christer Holmberg , Ted Hardie , "Black, David" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAc0OqAABAN2oAAKb4SAAABtAIAAApo7AAACcBoUA== Date: Fri, 29 May 2015 01:57:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.115] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A47861342xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 01:57:39 -0000 --_000_913383AAA69FF945B8F946018B75898A47861342xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludC4gV2UgZGlzY3VzcyB0aGUgZm9sbG93aW5nIHBvaW50IGluIHNlY3Rpb24gNC4x IG9mIHRoZSBkcmFmdCBhYm91dCBrZWVwYWxpdmVzOg0KDQogICBBbiBlbmRwb2ludCB0aGF0IGlz IG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90IG5lZWQgdG8NCiAgIG1h aW50YWluIGNvbnNlbnQuICBIb3dldmVyLCBub3Qgc2VuZGluZyBhbnkgdHJhZmZpYyBjb3VsZCBj YXVzZSBOQVQNCiAgIG9yIGZpcmV3YWxsIG1hcHBpbmdzIHRvIGV4cGlyZS4gIEZ1cnRoZXJtb3Jl LCBoYXZpbmcgb25lIHBlZXIgdW5hYmxlDQogICB0byBzZW5kIGlzIGRldHJpbWVudGFsIHRvIG1h bnkgcHJvdG9jb2xzLiAgQWJzZW50IGJldHRlciBpbmZvcm1hdGlvbg0KICAgYWJvdXQgdGhlIG5l dHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxs DQogICBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxp dmUgb3Igb3RoZXINCiAgIHRlY2huaXF1ZXMgKHNlZSBTZWN0aW9uIDEwIG9mIFtSRkM1MjQ1XTxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tMTA+IGFuZCBzZWUgW1JG QzYyNjM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI2Mz5dKS4NCg0KU28gdGhlcmUg aXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZXMgYmVjYXVzZSBvZiB0aGUgbWVkaWEgdHJhZmZp YyBhcyBpdCBpcyBwb2ludGVkIG91dCBpbiBTZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NSBpcnJl c3BlY3RpdmUgb2Ygd2hldGhlciBjb25zZW50IGlzIHVzZWQgb3Igbm90LiBJIHRoaW5rIHdlIGNh biByZW1vdmUgdGhlIGZvbGxvd2luZyBsaW5lIGluIOKAnElmIGNvbnNlbnQgaXMgcGVyZm9ybWVk IHRoZW4gdGhlcmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZSBtZXNzYWdlcy4iIGFuZCBh dm9pZCB0aGUgY29uZnVzaW9uIG9mIHVwZGF0aW5nIFJGQyA1MjQ1Lg0KDQotVGlydQ0KDQpGcm9t OiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENo cmlzdGVyIEhvbG1iZXJnDQpTZW50OiBGcmlkYXksIE1heSAyOSwgMjAxNSA2OjU0IEFNDQpUbzog VGVkIEhhcmRpZTsgQmxhY2ssIERhdmlkDQpDYzogam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYu b3JnOyBydGN3ZWJAaWV0Zi5vcmc7IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVu LWNvbnNlbnQtZnJlc2huZXNzLTEzDQoNCg0KSGksDQoNClNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1 MjQ1IHNheXM6DQoNCuKAnFNUVU4ga2VlcGFsaXZlcyAoaW4gdGhlIGZvcm0gb2YgU1RVTiBCaW5k aW5nIEluZGljYXRpb25zKSBhcmUgc2VudCBpbg0KICAgICAgICAgICAgICB0aGUgbWlkZGxlIG9m IGEgbWVkaWEgc2Vzc2lvbi4gIEhvd2V2ZXIsIHRoZXkgYXJlIHNlbnQgb25seSBpbiB0aGUNCiAg ICAgICAgICAgICAgYWJzZW5jZSBvZiBhY3R1YWwgbWVkaWEgdHJhZmZpYy7igJ0NCg0KU28sIGlu IHRoZSBjb25zZW50IGRyYWZ0IHdlIGNvdWxkIHNheSB0aGF0LCBmcm9tIGEga2VlcGFsaXZlIHBl cnNwZWN0aXZlLCBjb25zZW50IHJlcXVlc3RzIGFyZSBjb25zaWRlcmVkIG1lZGlhIHRyYWZmaWMu IFRoYXQgd291bGQgdGhlbiBpbXBsaWNpdGx5IG1lYW4gdGhhdCBhY3R1YWwga2VlcGFsaXZlcyBh cmVu4oCZdCBzZW50IHdoZW4gY29uc2VudCBpcyB1c2VkLiBUaGF0IHdheSwgdGhlIGNvbnNlbnQg c3BlYyB3b3VsZCBiZSBjb21wbGlhbnQgdG8gNTI0NSwgYW5kIHRoZXJlIHdvdWxkIGJlIG5vIG5l ZWQgZm9yIGFueSB1cGRhdGUgZXRj4oCmDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJv bTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBU ZWQgSGFyZGllDQpTZW50OiAyOCBNYXkgMjAxNSAyMzoyNg0KVG86IEJsYWNrLCBEYXZpZA0KQ2M6 IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYi1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+OyBqb2VsIGphZWdnbGk7IG9wcy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJA aWV0Zi5vcmc+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVu LWNvbnNlbnQtZnJlc2huZXNzLTEzDQoNCkhpIERhdmlkLA0KDQpPbiBUaHUsIE1heSAyOCwgMjAx NSBhdCAxMjozNiBQTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpk YXZpZC5ibGFja0BlbWMuY29tPj4NCg0KSSdkIGV4cGVjdCB0aGF0IGV2ZW4gb3ZlcnJpZGluZyBS RkMgNTI0NSBjb3VudHMgYXMgYW4gVXBkYXRlLA0KYmVjYXVzZSB0aGUgcmVzdWx0IHdvdWxkIGJl IHRoYXQgdGhlIG9yaWdpbmFsIFJGQyA1MjQ1ICJNVVNUIiByZXF1aXJlbWVudA0KaXMgbm8gbG9u Z2VyIGdsb2JhbGx5IGFwcGxpY2FibGUgdG8gYWxsIHVzZXMgb2YgUkZDIDUyNDUuICBJbiBvdGhl ciB3b3JkcywNCm92ZXJyaWRpbmcgUkZDIDUyNDUgZWZmZWN0aXZlbHkgcmV3cml0ZXMgdGhlICJN VVNUIiB0byBiZWNvbWUgIk1VU1QsIGV4Y2VwdA0KYXMgZnVydGhlciBzcGVjaWZpZWQgYnkgdGhl IGNvbnNlbnQgUkZDLiINCg0K4oCLU28gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoaXMgbXVzdCBi ZSBjYWxsZWQgb3V0LCBidXQgSSB0aGluayAiVXBkYXRlcyIgaXMgd3JvbmcgZm9yIHRoZSBkcmFm dCdzIGN1cnJlbnQgaW50ZW50LiAgSSB0aGluayB3aGF0IE1hcnRpbiBoYXMgc2FpZCBhbW91bnRz IHRvICJXZSBoYXZlIGNob3NlbiB0byBmb2xsb3cgUkZDIDUyNDUgZXhjZXB0IGFzIGRldGFpbGVk IGluIHNlY3Rpb25zIFggYW5kIFksIHdoZXJlIHdlIHVzZSBhIGRpZmZlcmVudCBzZXQgb2YgbWVz c2FnZXMgdG8gb3B0aW1pemUgdGhlIGNvbWJpbmF0aW9uIG9mIGhlYXJ0YmVhdCBhbmQgY29uc2Vu dC4iICBXZSBhcmUgbm90IHVwZGF0aW5nIFJGQyA1MjQ1IHRoZXJlYnksIGJlY2F1c2Ugd2UgYXJl IG5laXRoZXIgY2hhbmdpbmcgaXRzIGNvcmUgc2VtYW50aWNzIG5vciBvZmZlcmluZyB0byBhZGQg YSBuZXcsIGdlbmVyYWwgc2VtYW50aWMgdG8gUkZDIDUyNDUgKHdlIGNvdWxkIGhhdmUgbWFkZSB0 aGF0IGNob2ljZSwgYnV0IGFyZSBub3QgZG9pbmcgc28gbm93KS4gIEluc3RlYWQgb2YgdXBkYXRp bmcgUkZDIDUyNDUsIGluIG90aGVyIHdvcmRzLCB3ZSBhcmUgbGltaXRpbmcgb3VyIHJlZmVyZW5j ZSB0byBpdC4NClRoYXQgc2hvdWxkIGJlIGRvbmUgZXhwbGljaXRseSwgYW5kIEkgdGhpbmsgaXQg c2hvdWxkIGJlIGNhbGxlZCBpdCBzdWZmaWljaWVudGx5IHRoYXQgYSBuZXcgc3BpbiBvZiB0aGUg ZHJhZnQgbGlrZWx5IG5lZWRzIGEgbmV3IHJvdW5kIG9mIHJldmlldy4gIEJ1dCBJIGRvbid0IHRo aW5rIHdlIGFyZSByZXF1aXJlZCB0byB1cGRhdGUgUkZDIDUyNDUgdG8gZ2V0IHRoYXQgZG9uZS4N CkkndmUgcmVmZXJyZWQgdGhlIG1hdHRlciB0byBvdXIgZnJpZW5kbHkgQUQsIGFuZCB3ZSBhd2Fp dCBoZXIgcmVhZGluZyBvbiBuZXh0IHN0ZXBzIG9uIHRoaXMuICBJbiBlaXRoZXIgYXBwcm9hY2gs IGhvd2V2ZXIsIHRoaXMgd2lsbCBnZXQgY2FsbGVkIG91dC4NCnJlZ2FyZHMsDQpUZWQgSEFyZGll 4oCLDQoNCg== --_000_913383AAA69FF945B8F946018B75898A47861342xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkdvb2QgcG9pbnQuIFdlIGRpc2N1c3MgdGhlIGZvbGxvd2luZyBwb2ludCBpbiBz ZWN0aW9uIDQuMSBvZiB0aGUgZHJhZnQgYWJvdXQga2VlcGFsaXZlczo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBBbiBlbmRwb2ludCB0aGF0IGlzIG5vdCBz ZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90IG5lZWQgdG88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG1h aW50YWluIGNvbnNlbnQuJm5ic3A7IEhvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0cmFmZmljIGNv dWxkIGNhdXNlIE5BVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgb3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiZu YnNwOyBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJsZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdG8gc2Vu ZCBpcyBkZXRyaW1lbnRhbCB0byBtYW55IHByb3RvY29scy4mbmJzcDsgQWJzZW50IGJldHRlciBp bmZvcm1hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5l ZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBtYXBwaW5ncyBkbyBu b3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IHRlY2huaXF1ZXMgKHNlZQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTI0NSNzZWN0aW9uLTEwIj5TZWN0aW9uJm5ic3A7MTAgb2YgW1JGQzUyNDVdPC9hPiBhbmQg c2VlIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjYzIiB0aXRsZT0i JnF1b3Q7QXBwbGljYXRpb24gTWVjaGFuaXNtIGZvciBLZWVwaW5nIEFsaXZlIHRoZSBOQVQgTWFw cGluZ3MgQXNzb2NpYXRlZCB3aXRoIFJUUCAvIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBG bG93cyZxdW90OyI+UkZDNjI2MzwvYT5dKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHRoZXJlIGlzIG5vIG5lZWQg dG8gc2VuZCBrZWVwYWxpdmVzIGJlY2F1c2Ugb2YgdGhlIG1lZGlhIHRyYWZmaWMgYXMgaXQgaXMg cG9pbnRlZCBvdXQgaW4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1MjQ1IGlycmVzcGVj dGl2ZSBvZiB3aGV0aGVyIGNvbnNlbnQgaXMgdXNlZCBvciBub3Q8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi4NCiBJIHRoaW5rIHdlIGNhbiByZW1vdmUg dGhlIGZvbGxvd2luZyBsaW5lIGluIOKAnElmIGNvbnNlbnQgaXMgcGVyZm9ybWVkIHRoZW4gdGhl cmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZSBtZXNzYWdlcy4mcXVvdDsgYW5kIGF2b2lk IHRoZSBjb25mdXNpb24gb2YgdXBkYXRpbmcgUkZDIDUyNDUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9s bWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMjksIDIwMTUgNjo1NCBBTTxicj4N CjxiPlRvOjwvYj4gVGVkIEhhcmRpZTsgQmxhY2ssIERhdmlkPGJyPg0KPGI+Q2M6PC9iPiBqb2Vs IGphZWdnbGk7IG9wcy1kaXJAaWV0Zi5vcmc7IHJ0Y3dlYkBpZXRmLm9yZzsgcnRjd2ViLWNoYWly c0B0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gT1BTLURp ciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiAyMC4yLjMgb2YgUkZDIDUyNDUgc2F5czo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWlu Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PuKAnFNUVU4ga2VlcGFsaXZlcyAoaW4gdGhlIGZvcm0gb2YgU1RVTiBCaW5kaW5nIEluZGljYXRp b25zKSBhcmUgc2VudCBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbWlkZGxlIG9mIGEgbWVkaWEgc2Vzc2lvbi4mbmJzcDsg SG93ZXZlciwNCjxiPnRoZXkgYXJlIHNlbnQgb25seSBpbiB0aGU8bzpwPjwvbzpwPjwvYj48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFic2VuY2Ug b2YgYWN0dWFsIG1lZGlhIHRyYWZmaWM8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TbywgaW4gdGhlIGNvbnNlbnQgZHJhZnQgd2UgY291bGQgc2F5IHRo YXQsIGZyb20gYSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNv bnNpZGVyZWQgbWVkaWEgdHJhZmZpYy4gVGhhdCB3b3VsZCB0aGVuIGltcGxpY2l0bHkNCiBtZWFu IHRoYXQgYWN0dWFsIGtlZXBhbGl2ZXMgYXJlbuKAmXQgc2VudCB3aGVuIGNvbnNlbnQgaXMgdXNl ZC4gVGhhdCB3YXksIHRoZSBjb25zZW50IHNwZWMgd291bGQgYmUgY29tcGxpYW50IHRvIDUyNDUs IGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciBhbnkgdXBkYXRlIGV0Y+KApjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48L2E+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIg WzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGVkIEhhcmRpZTxicj4N CjxiPlNlbnQ6PC9iPiAyOCBNYXkgMjAxNSAyMzoyNjxicj4NCjxiPlRvOjwvYj4gQmxhY2ssIERh dmlkPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5p ZXRmLm9yZyI+cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzwvYT47IGpvZWwgamFlZ2dsaTsN CjxhIGhyZWY9Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIj5vcHMtZGlyQGlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1p ZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SGkgRGF2aWQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj5PbiBUaHUsIE1heSAyOCwgMjAxNSBhdCAxMjozNiBQTSwgQmxhY2ssIERh dmlkICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmRhdmlkLmJsYWNrQGVtYy5jb208L2E+Jmd0Ow0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PGJyPg0KSSdkIGV4cGVjdCB0aGF0IGV2 ZW4gb3ZlcnJpZGluZyBSRkMgNTI0NSBjb3VudHMgYXMgYW4gVXBkYXRlLDxicj4NCmJlY2F1c2Ug dGhlIHJlc3VsdCB3b3VsZCBiZSB0aGF0IHRoZSBvcmlnaW5hbCBSRkMgNTI0NSAmcXVvdDtNVVNU JnF1b3Q7IHJlcXVpcmVtZW50PGJyPg0KaXMgbm8gbG9uZ2VyIGdsb2JhbGx5IGFwcGxpY2FibGUg dG8gYWxsIHVzZXMgb2YgUkZDIDUyNDUuJm5ic3A7IEluIG90aGVyIHdvcmRzLDxicj4NCm92ZXJy aWRpbmcgUkZDIDUyNDUgZWZmZWN0aXZlbHkgcmV3cml0ZXMgdGhlICZxdW90O01VU1QmcXVvdDsg dG8gYmVjb21lICZxdW90O01VU1QsIGV4Y2VwdDxicj4NCmFzIGZ1cnRoZXIgc3BlY2lmaWVkIGJ5 IHRoZSBjb25zZW50IFJGQy4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItTbyBJ IGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBtdXN0IGJlIGNhbGxlZCBvdXQsIGJ1dCBJIHRoaW5r ICZxdW90O1VwZGF0ZXMmcXVvdDsgaXMgd3JvbmcgZm9yIHRoZSBkcmFmdCdzIGN1cnJlbnQgaW50 ZW50LiZuYnNwOyBJIHRoaW5rIHdoYXQgTWFydGluIGhhcyBzYWlkIGFtb3VudHMNCiB0byAmcXVv dDtXZSBoYXZlIGNob3NlbiB0byBmb2xsb3cgUkZDIDUyNDUgZXhjZXB0IGFzIGRldGFpbGVkIGlu IHNlY3Rpb25zIFggYW5kIFksIHdoZXJlIHdlIHVzZSBhIGRpZmZlcmVudCBzZXQgb2YgbWVzc2Fn ZXMgdG8gb3B0aW1pemUgdGhlIGNvbWJpbmF0aW9uIG9mIGhlYXJ0YmVhdCBhbmQgY29uc2VudC4m cXVvdDsmbmJzcDsgV2UgYXJlIG5vdCB1cGRhdGluZyBSRkMgNTI0NSB0aGVyZWJ5LCBiZWNhdXNl IHdlIGFyZSBuZWl0aGVyIGNoYW5naW5nIGl0cyBjb3JlIHNlbWFudGljcw0KIG5vciBvZmZlcmlu ZyB0byBhZGQgYSBuZXcsIGdlbmVyYWwgc2VtYW50aWMgdG8gUkZDIDUyNDUgKHdlIGNvdWxkIGhh dmUgbWFkZSB0aGF0IGNob2ljZSwgYnV0IGFyZSBub3QgZG9pbmcgc28gbm93KS4mbmJzcDsgSW5z dGVhZCBvZiB1cGRhdGluZyBSRkMgNTI0NSwgaW4gb3RoZXIgd29yZHMsIHdlIGFyZSBsaW1pdGlu ZyBvdXIgcmVmZXJlbmNlIHRvIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhdCBzaG91bGQgYmUgZG9uZSBleHBsaWNpdGx5LCBhbmQg SSB0aGluayBpdCBzaG91bGQgYmUgY2FsbGVkIGl0IHN1ZmZpaWNpZW50bHkgdGhhdCBhIG5ldyBz cGluIG9mIHRoZSBkcmFmdCBsaWtlbHkgbmVlZHMgYSBuZXcgcm91bmQgb2YgcmV2aWV3LiZuYnNw Ow0KIEJ1dCBJIGRvbid0IHRoaW5rIHdlIGFyZSByZXF1aXJlZCB0byB1cGRhdGUgUkZDIDUyNDUg dG8gZ2V0IHRoYXQgZG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkkndmUgcmVmZXJyZWQgdGhlIG1hdHRlciB0byBvdXIgZnJpZW5kbHkg QUQsIGFuZCB3ZSBhd2FpdCBoZXIgcmVhZGluZyBvbiBuZXh0IHN0ZXBzIG9uIHRoaXMuJm5ic3A7 IEluIGVpdGhlciBhcHByb2FjaCwgaG93ZXZlciwgdGhpcyB3aWxsIGdldCBjYWxsZWQgb3V0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UZWQgSEFyZGll4oCLPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A47861342xmbrcdx10ciscoc_-- From nobody Thu May 28 19:06: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 CE7A11A07BD; Thu, 28 May 2015 19:06:47 -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 7qkkTBHXut4o; Thu, 28 May 2015 19:06:45 -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 3363A1A19F2; Thu, 28 May 2015 19:06:44 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-1b-5567c9b192f9 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D6.86.04401.1B9C7655; Fri, 29 May 2015 04:06:42 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Fri, 29 May 2015 04:06:41 +0200 From: Christer Holmberg To: "Tirumaleswar Reddy (tireddy)" , Ted Hardie , "Black, David" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmbLPRahjX/HfekSlgolcsAIqXJ2SMykg Date: Fri, 29 May 2015 02:06:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A47861342@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D86E2EDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM+Jvre6mk+mhBg828VpsPbyW3eLVqTWM Fr1NS5gt5ux6wGSx9l87u0XjXDuLE7u3MTqwe5w9soDRY8rvjaweR47MZvHYOesuu8eSJT+Z PL5c/swWwBbFZZOSmpNZllqkb5fAlbG/8zpTQccdxopdf3vYGhgXXGPsYuTkkBAwkTh24Sg7 hC0mceHeerYuRi4OIYGjjBJfJ39ihHAWM0r0bPnH0sXIwcEmYCHR/U8bpEFEoF7icP9lVhCb WWATo8TefT4gtrBAqETfhwNsIOUiAmEStw+aQZQbSTTcWA5WziKgKrG86RALiM0r4Cux4ucR qFVPmCXO3tnIDNLLCZRobigAqWEEuu37qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4//sULY ShKLbn+Gqs+XeP13LRPELkGJkzOfsExgFJ2FZNQsJGWzkJTNArqCWUBTYv0ufYgSRYkp3Q/Z IWwNidY5c9mRxRcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIzjg1t+q+5gvPzG8RCj AAejEg/vg3VpoUKsiWXFlbmHGKU5WJTEeT27QkKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MHJv+D9rj3It9yebDvnIkD4WZ8Vfhg8s3q+73uzj+H/9rXC2EkFTpvK5xUcO5F1iF9z/LmH+ 8pSOrb/V46/szLtzpjbh6KH2A7NzH+3dmipyt0QmYK6j9cpqob7lbfOWzbj3b61XSua9llei aXmOezWs2zS80lh6P8z5YCv3aNF5/hmhTyNTKpVYijMSDbWYi4oTAVp/nN7EAgAA Archived-At: 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 02:06:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D86E2EDESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5Hb29kIHBvaW50LiBXZSBkaXNjdXNzIHRoZSBmb2xsb3dpbmcgcG9pbnQgaW4gc2Vj dGlvbiA0LjEgb2YgdGhlIGRyYWZ0IGFib3V0IGtlZXBhbGl2ZXM6DQo+DQo+ICAgQW4gZW5kcG9p bnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkgYXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVk IHRvDQo+ICAgbWFpbnRhaW4gY29uc2VudC4gIEhvd2V2ZXIsIG5vdCBzZW5kaW5nIGFueSB0cmFm ZmljIGNvdWxkIGNhdXNlIE5BVA0KPiAgIG9yIGZpcmV3YWxsIG1hcHBpbmdzIHRvIGV4cGlyZS4g IEZ1cnRoZXJtb3JlLCBoYXZpbmcgb25lIHBlZXIgdW5hYmxlDQo+ICAgdG8gc2VuZCBpcyBkZXRy aW1lbnRhbCB0byBtYW55IHByb3RvY29scy4gIEFic2VudCBiZXR0ZXIgaW5mb3JtYXRpb24NCj4g ICBhYm91dCB0aGUgbmV0d29yaywgaWYgYW4gZW5kcG9pbnQgbmVlZHMgdG8gZW5zdXJlIGl0cyBO QVQgb3IgZmlyZXdhbGwNCj4gICBtYXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9u ZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXINCj4gICB0ZWNobmlxdWVzIChzZWUgU2VjdGlvbiAx MCBvZiBbUkZDNTI0NV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9u LTEwPiBhbmQgc2VlIFtSRkM2MjYzPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNjM+ XSkuDQo+DQo+IFNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBrZWVwYWxpdmVzIGJlY2F1c2Ug b2YgdGhlIG1lZGlhIHRyYWZmaWMgYXMgaXQgaXMgcG9pbnRlZCBvdXQgaW4gU2VjdGlvbiAyMC4y LjMgb2YgUkZDIDUyNDUNCj4gaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgY29uc2VudCBpcyB1c2Vk IG9yIG5vdC4gSSB0aGluayB3ZSBjYW4gcmVtb3ZlIHRoZSBmb2xsb3dpbmcgbGluZSBpbiDigJxJ ZiBjb25zZW50IGlzIHBlcmZvcm1lZCB0aGVuDQo+IHRoZXJlIGlzIG5vIG5lZWQgdG8gc2VuZCBr ZWVwYWxpdmUgbWVzc2FnZXMuIiBhbmQgYXZvaWQgdGhlIGNvbmZ1c2lvbiBvZiB1cGRhdGluZyBS RkMgNTI0NS4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBjdXJyZW50IHRleHQgY2FuIGNvbmZ1c2UgcGVv cGxlLCBidXQgSSBzdGlsbCB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgZXhwbGljaXQg dGV4dCBzYXlpbmcgdGhhdCBrZWVwYWxpdmVzIGFyZSBub3Qgc2VudC4gUGVyaGFwcyBzb21ldGhp bmcgbGlrZToNCg0K4oCcRnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVjdGl2ZSwgY29uc2VudCByZXF1 ZXN0cyBhcmUgY29uc2lkZXJlZCBtZWRpYSB0cmFmZmljLiBCZWNhdXNlIG9mIHRoYXQsIGRlZGlj YXRlZCBrZWVwYWxpdmVzIChlLmcuIFNUVU4gYmluZGluZyByZXF1ZXN0cykgYXJlIG5vdCBzZW50 IG9uIGNhbmRpZGF0ZSBwYWlycyB3aGVyZSBjb25zZW50IHJlcXVlc3RzIGFyZSBzZW50LCBpbiBh Y2NvcmRhbmNlIHdpdGggU2VjdGlvbiAyMC4yLjMgb2YgW1JGQzUyNDVdLuKAnQ0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IEZyaWRheSwgTWF5 IDI5LCAyMDE1IDY6NTQgQU0NClRvOiBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQNCkNjOiBqb2Vs IGphZWdnbGk7IG9wcy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz47IHJ0Y3dlYi1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25z ZW50LWZyZXNobmVzcy0xMw0KDQoNCkhpLA0KDQpTZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NSBz YXlzOg0KDQrigJxTVFVOIGtlZXBhbGl2ZXMgKGluIHRoZSBmb3JtIG9mIFNUVU4gQmluZGluZyBJ bmRpY2F0aW9ucykgYXJlIHNlbnQgaW4NCiAgICAgICAgICAgICAgdGhlIG1pZGRsZSBvZiBhIG1l ZGlhIHNlc3Npb24uICBIb3dldmVyLCB0aGV5IGFyZSBzZW50IG9ubHkgaW4gdGhlDQogICAgICAg ICAgICAgIGFic2VuY2Ugb2YgYWN0dWFsIG1lZGlhIHRyYWZmaWMu4oCdDQoNClNvLCBpbiB0aGUg Y29uc2VudCBkcmFmdCB3ZSBjb3VsZCBzYXkgdGhhdCwgZnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVj dGl2ZSwgY29uc2VudCByZXF1ZXN0cyBhcmUgY29uc2lkZXJlZCBtZWRpYSB0cmFmZmljLiBUaGF0 IHdvdWxkIHRoZW4gaW1wbGljaXRseSBtZWFuIHRoYXQgYWN0dWFsIGtlZXBhbGl2ZXMgYXJlbuKA mXQgc2VudCB3aGVuIGNvbnNlbnQgaXMgdXNlZC4gVGhhdCB3YXksIHRoZSBjb25zZW50IHNwZWMg d291bGQgYmUgY29tcGxpYW50IHRvIDUyNDUsIGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZv ciBhbnkgdXBkYXRlIGV0Y+KApg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0 Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhh cmRpZQ0KU2VudDogMjggTWF5IDIwMTUgMjM6MjYNClRvOiBCbGFjaywgRGF2aWQNCkNjOiBydGN3 ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYu b3JnPjsgam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYu b3JnPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25z ZW50LWZyZXNobmVzcy0xMw0KDQpIaSBEYXZpZCwNCg0KT24gVGh1LCBNYXkgMjgsIDIwMTUgYXQg MTI6MzYgUE0sIEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQu YmxhY2tAZW1jLmNvbT4+DQoNCkknZCBleHBlY3QgdGhhdCBldmVuIG92ZXJyaWRpbmcgUkZDIDUy NDUgY291bnRzIGFzIGFuIFVwZGF0ZSwNCmJlY2F1c2UgdGhlIHJlc3VsdCB3b3VsZCBiZSB0aGF0 IHRoZSBvcmlnaW5hbCBSRkMgNTI0NSAiTVVTVCIgcmVxdWlyZW1lbnQNCmlzIG5vIGxvbmdlciBn bG9iYWxseSBhcHBsaWNhYmxlIHRvIGFsbCB1c2VzIG9mIFJGQyA1MjQ1LiAgSW4gb3RoZXIgd29y ZHMsDQpvdmVycmlkaW5nIFJGQyA1MjQ1IGVmZmVjdGl2ZWx5IHJld3JpdGVzIHRoZSAiTVVTVCIg dG8gYmVjb21lICJNVVNULCBleGNlcHQNCmFzIGZ1cnRoZXIgc3BlY2lmaWVkIGJ5IHRoZSBjb25z ZW50IFJGQy4iDQoNCuKAi1NvIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2Fs bGVkIG91dCwgYnV0IEkgdGhpbmsgIlVwZGF0ZXMiIGlzIHdyb25nIGZvciB0aGUgZHJhZnQncyBj dXJyZW50IGludGVudC4gIEkgdGhpbmsgd2hhdCBNYXJ0aW4gaGFzIHNhaWQgYW1vdW50cyB0byAi V2UgaGF2ZSBjaG9zZW4gdG8gZm9sbG93IFJGQyA1MjQ1IGV4Y2VwdCBhcyBkZXRhaWxlZCBpbiBz ZWN0aW9ucyBYIGFuZCBZLCB3aGVyZSB3ZSB1c2UgYSBkaWZmZXJlbnQgc2V0IG9mIG1lc3NhZ2Vz IHRvIG9wdGltaXplIHRoZSBjb21iaW5hdGlvbiBvZiBoZWFydGJlYXQgYW5kIGNvbnNlbnQuIiAg V2UgYXJlIG5vdCB1cGRhdGluZyBSRkMgNTI0NSB0aGVyZWJ5LCBiZWNhdXNlIHdlIGFyZSBuZWl0 aGVyIGNoYW5naW5nIGl0cyBjb3JlIHNlbWFudGljcyBub3Igb2ZmZXJpbmcgdG8gYWRkIGEgbmV3 LCBnZW5lcmFsIHNlbWFudGljIHRvIFJGQyA1MjQ1ICh3ZSBjb3VsZCBoYXZlIG1hZGUgdGhhdCBj aG9pY2UsIGJ1dCBhcmUgbm90IGRvaW5nIHNvIG5vdykuICBJbnN0ZWFkIG9mIHVwZGF0aW5nIFJG QyA1MjQ1LCBpbiBvdGhlciB3b3Jkcywgd2UgYXJlIGxpbWl0aW5nIG91ciByZWZlcmVuY2UgdG8g aXQuDQpUaGF0IHNob3VsZCBiZSBkb25lIGV4cGxpY2l0bHksIGFuZCBJIHRoaW5rIGl0IHNob3Vs ZCBiZSBjYWxsZWQgaXQgc3VmZmlpY2llbnRseSB0aGF0IGEgbmV3IHNwaW4gb2YgdGhlIGRyYWZ0 IGxpa2VseSBuZWVkcyBhIG5ldyByb3VuZCBvZiByZXZpZXcuICBCdXQgSSBkb24ndCB0aGluayB3 ZSBhcmUgcmVxdWlyZWQgdG8gdXBkYXRlIFJGQyA1MjQ1IHRvIGdldCB0aGF0IGRvbmUuDQpJJ3Zl IHJlZmVycmVkIHRoZSBtYXR0ZXIgdG8gb3VyIGZyaWVuZGx5IEFELCBhbmQgd2UgYXdhaXQgaGVy IHJlYWRpbmcgb24gbmV4dCBzdGVwcyBvbiB0aGlzLiAgSW4gZWl0aGVyIGFwcHJvYWNoLCBob3dl dmVyLCB0aGlzIHdpbGwgZ2V0IGNhbGxlZCBvdXQuDQpyZWdhcmRzLA0KVGVkIEhBcmRpZeKAiw0K DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D86E2EDESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pkdvb2QgcG9pbnQuIFdlIGRpc2N1c3MgdGhlIGZvbGxvd2luZyBwb2ludCBpbiBzZWN0aW9uIDQu MSBvZiB0aGUgZHJhZnQgYWJvdXQga2VlcGFsaXZlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m Z3Q7Jm5ic3A7Jm5ic3A7IEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxp Y2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyBt YWludGFpbiBjb25zZW50LiZuYnNwOyBIb3dldmVyLCBub3Qgc2VuZGluZyBhbnkgdHJhZmZpYyBj b3VsZCBjYXVzZSBOQVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgb3IgZmlyZXdhbGwgbWFw cGluZ3MgdG8gZXhwaXJlLiZuYnNwOyBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJs ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyB0byBzZW5kIGlzIGRldHJpbWVudGFsIHRvIG1h bnkgcHJvdG9jb2xzLiZuYnNwOyBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m Z3Q7Jm5ic3A7Jm5ic3A7IGFib3V0IHRoZSBuZXR3b3JrLCBpZiBhbiBlbmRwb2ludCBuZWVkcyB0 byBlbnN1cmUgaXRzIE5BVCBvciBmaXJld2FsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyBt YXBwaW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Ig b3RoZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgdGVjaG5pcXVlcyAoc2VlDQo8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tMTAiPlNlY3Rpb24m bmJzcDsxMCBvZiBbUkZDNTI0NV08L2E+IGFuZCBzZWUgWzxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzYyNjMiIHRpdGxlPSImcXVvdDtBcHBsaWNhdGlvbiBNZWNoYW5pc20g Zm9yIEtlZXBpbmcgQWxpdmUgdGhlIE5BVCBNYXBwaW5ncyBBc3NvY2lhdGVkIHdpdGggUlRQIC8g UlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIEZsb3dzJnF1b3Q7Ij5SRkM2MjYzPC9hPl0pLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5T byB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlcyBiZWNhdXNlIG9mIHRoZSBtZWRp YSB0cmFmZmljIGFzIGl0IGlzIHBvaW50ZWQgb3V0IGluDQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NQ0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ aXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgY29uc2VudCBpcyB1c2VkIG9yIG5vdDwvc3Bhbj48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4uIEkgdGhpbmsg d2UgY2FuIHJlbW92ZSB0aGUgZm9sbG93aW5nIGxpbmUgaW4g4oCcSWYgY29uc2VudCBpcyBwZXJm b3JtZWQgdGhlbg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj50aGVyZSBpcyBubyBu ZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLiZxdW90OyBhbmQgYXZvaWQgdGhlIGNvbmZ1 c2lvbiBvZiB1cGRhdGluZyBSRkMgNTI0NS48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SSBhZ3JlZSB0aGF0IHRoZSBjdXJyZW50IHRleHQgY2FuIGNvbmZ1 c2UgcGVvcGxlLCBidXQgSSBzdGlsbCB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgZXhw bGljaXQgdGV4dCBzYXlpbmcgdGhhdCBrZWVwYWxpdmVzIGFyZSBub3Qgc2VudC4gUGVyaGFwcyBz b21ldGhpbmcNCiBsaWtlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PuKAnEZyb20gYSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNv bnNpZGVyZWQgbWVkaWEgdHJhZmZpYy4gQmVjYXVzZSBvZiB0aGF0LCBkZWRpY2F0ZWQga2VlcGFs aXZlcyAoZS5nLiBTVFVOIGJpbmRpbmcgcmVxdWVzdHMpIGFyZSBub3Qgc2VudCBvbg0KIGNhbmRp ZGF0ZSBwYWlycyB3aGVyZSBjb25zZW50IHJlcXVlc3RzIGFyZSBzZW50LCBpbiBhY2NvcmRhbmNl IHdpdGggU2VjdGlvbiAyMC4yLjMgb2YgW1JGQzUyNDVdLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIE1heSAyOSwgMjAxNSA2OjU0IEFNPGJyPg0KPGI+VG86PC9iPiBUZWQgSGFyZGllOyBCbGFj aywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+IGpvZWwgamFlZ2dsaTsgPGEgaHJlZj0ibWFpbHRvOm9w cy1kaXJAaWV0Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRj d2ViQGlldGYub3JnIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3 ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnIj5ydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMjAu Mi4zIG9mIFJGQyA1MjQ1IHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJxTVFVOIGtlZXBhbGl2ZXMgKGlu IHRoZSBmb3JtIG9mIFNUVU4gQmluZGluZyBJbmRpY2F0aW9ucykgYXJlIHNlbnQgaW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbWlkZGxlIG9mIGEgbWVkaWEgc2Vzc2lv bi4mbmJzcDsgSG93ZXZlciwNCjxiPnRoZXkgYXJlIHNlbnQgb25seSBpbiB0aGU8bzpwPjwvbzpw PjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWJzZW5jZSBvZiBhY3R1YWwgbWVkaWEg dHJhZmZpYzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi7igJ08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCBpbiB0aGUgY29uc2Vu dCBkcmFmdCB3ZSBjb3VsZCBzYXkgdGhhdCwgZnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVjdGl2ZSwg Y29uc2VudCByZXF1ZXN0cyBhcmUgY29uc2lkZXJlZCBtZWRpYSB0cmFmZmljLiBUaGF0IHdvdWxk IHRoZW4gaW1wbGljaXRseSBtZWFuIHRoYXQNCiBhY3R1YWwga2VlcGFsaXZlcyBhcmVu4oCZdCBz ZW50IHdoZW4gY29uc2VudCBpcyB1c2VkLiBUaGF0IHdheSwgdGhlIGNvbnNlbnQgc3BlYyB3b3Vs ZCBiZSBjb21wbGlhbnQgdG8gNTI0NSwgYW5kIHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgZm9yIGFu eSB1cGRhdGUgZXRj4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hy aXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlRlZCBIYXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gMjggTWF5IDIwMTUgMjM6MjY8YnI+DQo8Yj5U bzo8L2I+IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnJ0Y3dl Yi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+ OyBqb2VsIGphZWdnbGk7DQo8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyI+b3BzLWRp ckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPg0KcnRjd2Vi QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gT1BTLURpciBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIERhdmlkLCA8bzpwPg0K PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwg TWF5IDI4LCAyMDE1IGF0IDEyOjM2IFBNLCBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0 bzpkYXZpZC5ibGFja0BlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNv bTwvYT4mZ3Q7DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSdkIGV4cGVj dCB0aGF0IGV2ZW4gb3ZlcnJpZGluZyBSRkMgNTI0NSBjb3VudHMgYXMgYW4gVXBkYXRlLDxicj4N CmJlY2F1c2UgdGhlIHJlc3VsdCB3b3VsZCBiZSB0aGF0IHRoZSBvcmlnaW5hbCBSRkMgNTI0NSAm cXVvdDtNVVNUJnF1b3Q7IHJlcXVpcmVtZW50PGJyPg0KaXMgbm8gbG9uZ2VyIGdsb2JhbGx5IGFw cGxpY2FibGUgdG8gYWxsIHVzZXMgb2YgUkZDIDUyNDUuJm5ic3A7IEluIG90aGVyIHdvcmRzLDxi cj4NCm92ZXJyaWRpbmcgUkZDIDUyNDUgZWZmZWN0aXZlbHkgcmV3cml0ZXMgdGhlICZxdW90O01V U1QmcXVvdDsgdG8gYmVjb21lICZxdW90O01VU1QsIGV4Y2VwdDxicj4NCmFzIGZ1cnRoZXIgc3Bl Y2lmaWVkIGJ5IHRoZSBjb25zZW50IFJGQy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi PuKAi1NvIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2FsbGVkIG91dCwgYnV0 IEkgdGhpbmsgJnF1b3Q7VXBkYXRlcyZxdW90OyBpcyB3cm9uZyBmb3IgdGhlIGRyYWZ0J3MgY3Vy cmVudCBpbnRlbnQuJm5ic3A7IEkgdGhpbmsgd2hhdCBNYXJ0aW4gaGFzIHNhaWQgYW1vdW50cyB0 byAmcXVvdDtXZSBoYXZlDQogY2hvc2VuIHRvIGZvbGxvdyBSRkMgNTI0NSBleGNlcHQgYXMgZGV0 YWlsZWQgaW4gc2VjdGlvbnMgWCBhbmQgWSwgd2hlcmUgd2UgdXNlIGEgZGlmZmVyZW50IHNldCBv ZiBtZXNzYWdlcyB0byBvcHRpbWl6ZSB0aGUgY29tYmluYXRpb24gb2YgaGVhcnRiZWF0IGFuZCBj b25zZW50LiZxdW90OyZuYnNwOyBXZSBhcmUgbm90IHVwZGF0aW5nIFJGQyA1MjQ1IHRoZXJlYnks IGJlY2F1c2Ugd2UgYXJlIG5laXRoZXIgY2hhbmdpbmcgaXRzIGNvcmUgc2VtYW50aWNzIG5vcg0K IG9mZmVyaW5nIHRvIGFkZCBhIG5ldywgZ2VuZXJhbCBzZW1hbnRpYyB0byBSRkMgNTI0NSAod2Ug Y291bGQgaGF2ZSBtYWRlIHRoYXQgY2hvaWNlLCBidXQgYXJlIG5vdCBkb2luZyBzbyBub3cpLiZu YnNwOyBJbnN0ZWFkIG9mIHVwZGF0aW5nIFJGQyA1MjQ1LCBpbiBvdGhlciB3b3Jkcywgd2UgYXJl IGxpbWl0aW5nIG91ciByZWZlcmVuY2UgdG8gaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPlRoYXQgc2hvdWxkIGJlIGRvbmUgZXhwbGljaXRseSwgYW5kIEkgdGhpbmsgaXQgc2hvdWxk IGJlIGNhbGxlZCBpdCBzdWZmaWljaWVudGx5IHRoYXQgYSBuZXcgc3BpbiBvZiB0aGUgZHJhZnQg bGlrZWx5IG5lZWRzIGEgbmV3IHJvdW5kIG9mIHJldmlldy4mbmJzcDsgQnV0IEkgZG9uJ3QgdGhp bmsNCiB3ZSBhcmUgcmVxdWlyZWQgdG8gdXBkYXRlIFJGQyA1MjQ1IHRvIGdldCB0aGF0IGRvbmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkkndmUgcmVmZXJyZWQgdGhlIG1hdHRlciB0 byBvdXIgZnJpZW5kbHkgQUQsIGFuZCB3ZSBhd2FpdCBoZXIgcmVhZGluZyBvbiBuZXh0IHN0ZXBz IG9uIHRoaXMuJm5ic3A7IEluIGVpdGhlciBhcHByb2FjaCwgaG93ZXZlciwgdGhpcyB3aWxsIGdl dCBjYWxsZWQgb3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5yZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+VGVk IEhBcmRpZeKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D86E2EDESESSMB209erics_-- From nobody Thu May 28 19:59: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 978EF1A8789; Thu, 28 May 2015 19:59:42 -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 r9p9CGvs762k; Thu, 28 May 2015 19:59:40 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36EA1A876D; Thu, 28 May 2015 19:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31902; q=dns/txt; s=iport; t=1432868379; x=1434077979; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QLPF7q7AdEUejGb6rEwQ7VlBoBdypyDq7BRZGgilhKs=; b=gO63Co/5E6KH/EUkmODvrsvLvnFlRwzPeErbaiHfBrVf+uLg45NkNtC8 g/tgimkxqMv13Ajo6MBcG9qGwtn+no5vipPz6b5VRKTyPKSFBo+/VK1pd T81Z83xID7TN12GKdOg3vQyn/DtRaMzRHADb+UWbqE//0t9n3T63tgjl/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BTBQBN1WdV/5tdJa1cgkVLVF4Ggxi6PyoJgVqFdwIcgS04FAEBAQEBAQGBCoQiAQEBAwEjCkwFCwIBCBEDAQEBIQcDAgICHxEUCQgCBAENBYgYAwoIDbITnwANhQQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0OCTYIoEQYBgmiBRQWTCIQ1hQGBWYEpPo1pXIcDI2GBKRyBUm+BAwc8gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,514,1427760000"; d="scan'208,217";a="154290433" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 29 May 2015 02:59:29 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4T2xTl4000972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 02:59:29 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.135]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 28 May 2015 21:59:29 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , "Tirumaleswar Reddy (tireddy)" , Ted Hardie , "Black, David" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmbt6Bo1mJR1ZV0+0h6pSyJVumw== Date: Fri, 29 May 2015 02:59:29 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.66.37] Content-Type: multipart/alternative; boundary="_000_D18DD3D531978rmohanrciscocom_" MIME-Version: 1.0 Archived-At: 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 02:59:42 -0000 --_000_D18DD3D531978rmohanrciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBmaW5lIHdpdGggdGhlIGJlbG93IHByb3Bvc2VkIHRleHQgZnJvbSBDaHJpc3Rlci4gSXQg aW5kaWNhdGVzIHRoYXQgIGNvbnNlbnQgZG9jdW1lbnQgZG9lcyBOT1QgdXBkYXRlIFJGQyA1MjQ1 IHdoaWNoIHdhcyB0aGUgY29uZnVzaW9uIHdlIGhhdmUgd2l0aCB0aGUgZXhpc3RpbmcgdGV4dCBp biB0aGUgZHJhZnQuDQoNClJhbQ0KDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+Pg0KRGF0ZTogRnJpZGF5LCAyOSBNYXkgMjAxNSA3OjM2IGFtDQpUbzogIlRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkiIDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNj by5jb20+PiwgVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQuaWV0ZkBn bWFpbC5jb20+PiwgIkJsYWNrLCBEYXZpZCIgPGRhdmlkLmJsYWNrQGVtYy5jb208bWFpbHRvOmRh dmlkLmJsYWNrQGVtYy5jb20+Pg0KQ2M6IGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbTxt YWlsdG86am9lbGphQGJvZ3VzLmNvbT4+LCAib3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRp ckBpZXRmLm9yZz4iIDxvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPj4s ICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4iIDxydGN3ZWJAaWV0Zi5v cmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+LCAicnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9y ZzxtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZz4iIDxydGN3ZWItY2hhaXJzQHRv b2xzLmlldGYub3JnPG1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVu LWNvbnNlbnQtZnJlc2huZXNzLTEzDQoNCkhpLA0KDQo+R29vZCBwb2ludC4gV2UgZGlzY3VzcyB0 aGUgZm9sbG93aW5nIHBvaW50IGluIHNlY3Rpb24gNC4xIG9mIHRoZSBkcmFmdCBhYm91dCBrZWVw YWxpdmVzOg0KPg0KPiAgIEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxp Y2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bw0KPiAgIG1haW50YWluIGNvbnNlbnQuICBIb3dl dmVyLCBub3Qgc2VuZGluZyBhbnkgdHJhZmZpYyBjb3VsZCBjYXVzZSBOQVQNCj4gICBvciBmaXJl d2FsbCBtYXBwaW5ncyB0byBleHBpcmUuICBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVu YWJsZQ0KPiAgIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuICBBYnNl bnQgYmV0dGVyIGluZm9ybWF0aW9uDQo+ICAgYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBv aW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsDQo+ICAgbWFwcGluZ3MgZG8g bm90IGV4cGlyZSwgaXQgY2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9yIG90aGVyDQo+ICAg dGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUyNDVdPGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi0xMD4gYW5kIHNlZSBbUkZDNjI2MzxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjYzPl0pLg0KPg0KPiBTbyB0aGVyZSBpcyBubyBuZWVkIHRv IHNlbmQga2VlcGFsaXZlcyBiZWNhdXNlIG9mIHRoZSBtZWRpYSB0cmFmZmljIGFzIGl0IGlzIHBv aW50ZWQgb3V0IGluIFNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1MjQ1DQo+IGlycmVzcGVjdGl2ZSBv ZiB3aGV0aGVyIGNvbnNlbnQgaXMgdXNlZCBvciBub3QuIEkgdGhpbmsgd2UgY2FuIHJlbW92ZSB0 aGUgZm9sbG93aW5nIGxpbmUgaW4g4oCcSWYgY29uc2VudCBpcyBwZXJmb3JtZWQgdGhlbg0KPiB0 aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLiIgYW5kIGF2b2lkIHRo ZSBjb25mdXNpb24gb2YgdXBkYXRpbmcgUkZDIDUyNDUuDQoNCkkgYWdyZWUgdGhhdCB0aGUgY3Vy cmVudCB0ZXh0IGNhbiBjb25mdXNlIHBlb3BsZSwgYnV0IEkgc3RpbGwgdGhpbmsgaXQgd291bGQg YmUgZ29vZCB0byBoYXZlIGV4cGxpY2l0IHRleHQgc2F5aW5nIHRoYXQga2VlcGFsaXZlcyBhcmUg bm90IHNlbnQuIFBlcmhhcHMgc29tZXRoaW5nIGxpa2U6DQoNCuKAnEZyb20gYSBrZWVwYWxpdmUg cGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEgdHJhZmZp Yy4gQmVjYXVzZSBvZiB0aGF0LCBkZWRpY2F0ZWQga2VlcGFsaXZlcyAoZS5nLiBTVFVOIGJpbmRp bmcgcmVxdWVzdHMpIGFyZSBub3Qgc2VudCBvbiBjYW5kaWRhdGUgcGFpcnMgd2hlcmUgY29uc2Vu dCByZXF1ZXN0cyBhcmUgc2VudCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gMjAuMi4zIG9m IFtSRkM1MjQ1XS7igJ0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpGcm9tOiBydGN3ZWIg W21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhv bG1iZXJnDQpTZW50OiBGcmlkYXksIE1heSAyOSwgMjAxNSA2OjU0IEFNDQpUbzogVGVkIEhhcmRp ZTsgQmxhY2ssIERhdmlkDQpDYzogam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYub3JnPG1haWx0 bzpvcHMtZGlyQGlldGYub3JnPjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+OyBydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzpydGN3ZWItY2hhaXJzQHRv b2xzLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRy YWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTMNCg0KDQpIaSwNCg0KU2Vj dGlvbiAyMC4yLjMgb2YgUkZDIDUyNDUgc2F5czoNCg0K4oCcU1RVTiBrZWVwYWxpdmVzIChpbiB0 aGUgZm9ybSBvZiBTVFVOIEJpbmRpbmcgSW5kaWNhdGlvbnMpIGFyZSBzZW50IGluDQogICAgICAg ICAgICAgIHRoZSBtaWRkbGUgb2YgYSBtZWRpYSBzZXNzaW9uLiAgSG93ZXZlciwgdGhleSBhcmUg c2VudCBvbmx5IGluIHRoZQ0KICAgICAgICAgICAgICBhYnNlbmNlIG9mIGFjdHVhbCBtZWRpYSB0 cmFmZmljLuKAnQ0KDQpTbywgaW4gdGhlIGNvbnNlbnQgZHJhZnQgd2UgY291bGQgc2F5IHRoYXQs IGZyb20gYSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNp ZGVyZWQgbWVkaWEgdHJhZmZpYy4gVGhhdCB3b3VsZCB0aGVuIGltcGxpY2l0bHkgbWVhbiB0aGF0 IGFjdHVhbCBrZWVwYWxpdmVzIGFyZW7igJl0IHNlbnQgd2hlbiBjb25zZW50IGlzIHVzZWQuIFRo YXQgd2F5LCB0aGUgY29uc2VudCBzcGVjIHdvdWxkIGJlIGNvbXBsaWFudCB0byA1MjQ1LCBhbmQg dGhlcmUgd291bGQgYmUgbm8gbmVlZCBmb3IgYW55IHVwZGF0ZSBldGPigKYNCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNClNlbnQ6IDI4IE1heSAyMDE1IDIzOjI2DQpU bzogQmxhY2ssIERhdmlkDQpDYzogcnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86 cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IGpvZWwgamFlZ2dsaTsgb3BzLWRpckBpZXRm Lm9yZzxtYWlsdG86b3BzLWRpckBpZXRmLm9yZz47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRy YWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTMNCg0KSGkgRGF2aWQsDQoN Ck9uIFRodSwgTWF5IDI4LCAyMDE1IGF0IDEyOjM2IFBNLCBCbGFjaywgRGF2aWQgPGRhdmlkLmJs YWNrQGVtYy5jb208bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20+Pg0KDQpJJ2QgZXhwZWN0IHRo YXQgZXZlbiBvdmVycmlkaW5nIFJGQyA1MjQ1IGNvdW50cyBhcyBhbiBVcGRhdGUsDQpiZWNhdXNl IHRoZSByZXN1bHQgd291bGQgYmUgdGhhdCB0aGUgb3JpZ2luYWwgUkZDIDUyNDUgIk1VU1QiIHJl cXVpcmVtZW50DQppcyBubyBsb25nZXIgZ2xvYmFsbHkgYXBwbGljYWJsZSB0byBhbGwgdXNlcyBv ZiBSRkMgNTI0NS4gIEluIG90aGVyIHdvcmRzLA0Kb3ZlcnJpZGluZyBSRkMgNTI0NSBlZmZlY3Rp dmVseSByZXdyaXRlcyB0aGUgIk1VU1QiIHRvIGJlY29tZSAiTVVTVCwgZXhjZXB0DQphcyBmdXJ0 aGVyIHNwZWNpZmllZCBieSB0aGUgY29uc2VudCBSRkMuIg0KDQrigItTbyBJIGFncmVlIHdpdGgg eW91IHRoYXQgdGhpcyBtdXN0IGJlIGNhbGxlZCBvdXQsIGJ1dCBJIHRoaW5rICJVcGRhdGVzIiBp cyB3cm9uZyBmb3IgdGhlIGRyYWZ0J3MgY3VycmVudCBpbnRlbnQuICBJIHRoaW5rIHdoYXQgTWFy dGluIGhhcyBzYWlkIGFtb3VudHMgdG8gIldlIGhhdmUgY2hvc2VuIHRvIGZvbGxvdyBSRkMgNTI0 NSBleGNlcHQgYXMgZGV0YWlsZWQgaW4gc2VjdGlvbnMgWCBhbmQgWSwgd2hlcmUgd2UgdXNlIGEg ZGlmZmVyZW50IHNldCBvZiBtZXNzYWdlcyB0byBvcHRpbWl6ZSB0aGUgY29tYmluYXRpb24gb2Yg aGVhcnRiZWF0IGFuZCBjb25zZW50LiIgIFdlIGFyZSBub3QgdXBkYXRpbmcgUkZDIDUyNDUgdGhl cmVieSwgYmVjYXVzZSB3ZSBhcmUgbmVpdGhlciBjaGFuZ2luZyBpdHMgY29yZSBzZW1hbnRpY3Mg bm9yIG9mZmVyaW5nIHRvIGFkZCBhIG5ldywgZ2VuZXJhbCBzZW1hbnRpYyB0byBSRkMgNTI0NSAo d2UgY291bGQgaGF2ZSBtYWRlIHRoYXQgY2hvaWNlLCBidXQgYXJlIG5vdCBkb2luZyBzbyBub3cp LiAgSW5zdGVhZCBvZiB1cGRhdGluZyBSRkMgNTI0NSwgaW4gb3RoZXIgd29yZHMsIHdlIGFyZSBs aW1pdGluZyBvdXIgcmVmZXJlbmNlIHRvIGl0Lg0KVGhhdCBzaG91bGQgYmUgZG9uZSBleHBsaWNp dGx5LCBhbmQgSSB0aGluayBpdCBzaG91bGQgYmUgY2FsbGVkIGl0IHN1ZmZpaWNpZW50bHkgdGhh dCBhIG5ldyBzcGluIG9mIHRoZSBkcmFmdCBsaWtlbHkgbmVlZHMgYSBuZXcgcm91bmQgb2YgcmV2 aWV3LiAgQnV0IEkgZG9uJ3QgdGhpbmsgd2UgYXJlIHJlcXVpcmVkIHRvIHVwZGF0ZSBSRkMgNTI0 NSB0byBnZXQgdGhhdCBkb25lLg0KSSd2ZSByZWZlcnJlZCB0aGUgbWF0dGVyIHRvIG91ciBmcmll bmRseSBBRCwgYW5kIHdlIGF3YWl0IGhlciByZWFkaW5nIG9uIG5leHQgc3RlcHMgb24gdGhpcy4g IEluIGVpdGhlciBhcHByb2FjaCwgaG93ZXZlciwgdGhpcyB3aWxsIGdldCBjYWxsZWQgb3V0Lg0K cmVnYXJkcywNClRlZCBIQXJkaWXigIsNCg0K --_000_D18DD3D531978rmohanrciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <87E71C4A6A42BF4CAB790787D8326C65@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5JIGFtIGZpbmUg d2l0aCB0aGUgYmVsb3cgcHJvcG9zZWQgdGV4dCBmcm9tIENocmlzdGVyLiBJdCBpbmRpY2F0ZXMg dGhhdCAmbmJzcDtjb25zZW50IGRvY3VtZW50IGRvZXMgTk9UIHVwZGF0ZSBSRkMgNTI0NSB3aGlj aCB3YXMgdGhlIGNvbmZ1c2lvbiB3ZSBoYXZlIHdpdGggdGhlIGV4aXN0aW5nIHRleHQgaW4gdGhl IGRyYWZ0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmFtPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNv bG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1 bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1S SUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RnJvbTogPC9zcGFuPkNocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8 L3NwYW4+RnJpZGF5LCAyOSBNYXkgMjAxNSA3OjM2IGFtPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIj50aXJlZGR5QGNp c2NvLmNvbTwvYT4mZ3Q7LCBUZWQgSGFyZGllICZsdDs8YSBocmVmPSJtYWlsdG86dGVkLmlldGZA Z21haWwuY29tIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7QmxhY2ssIERhdmlk JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSI+ZGF2aWQuYmxh Y2tAZW1jLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNj OiA8L3NwYW4+am9lbCBqYWVnZ2xpICZsdDs8YSBocmVmPSJtYWlsdG86am9lbGphQGJvZ3VzLmNv bSI+am9lbGphQGJvZ3VzLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86b3BzLWRp ckBpZXRmLm9yZyI+b3BzLWRpckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpvcHMtZGlyQGlldGYub3JnIj5vcHMtZGlyQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mcXVvdDsNCiAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnIj5y dGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8 L3NwYW4+UmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0 dW4tY29uc2VudC1mcmVzaG5lc3MtMTM8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQg V29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0 aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5v c2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPGRpdiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4mZ3Q7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkdvb2QgcG9p bnQuIFdlIGRpc2N1c3MgdGhlIGZvbGxvd2luZyBwb2ludCBpbiBzZWN0aW9uIDQuMSBvZiB0aGUg ZHJhZnQgYWJvdXQga2VlcGFsaXZlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Jmd0OzxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jmd0OyZuYnNwOyZuYnNwOyBBbiBlbmRwb2lu dCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90IG5lZWQg dG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l dyc7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IG1haW50YWluIGNvbnNlbnQuJm5ic3A7IEhvd2V2ZXIsIG5v dCBzZW5kaW5nIGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZndDsmbmJzcDsmbmJzcDsg b3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiZuYnNwOyBGdXJ0aGVybW9yZSwgaGF2aW5n IG9uZSBwZWVyIHVuYWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJ0NvdXJpZXIgTmV3JzsiPiZndDsmbmJzcDsmbmJzcDsgdG8gc2VuZCBpcyBkZXRyaW1lbnRh bCB0byBtYW55IHByb3RvY29scy4mbmJzcDsgQWJzZW50IGJldHRlciBpbmZvcm1hdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPiZn dDsmbmJzcDsmbmJzcDsgYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRv IGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3YWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+Jmd0OyZuYnNwOyZuYnNwOyBtYXBwaW5ncyBk byBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3RoZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij4m Z3Q7Jm5ic3A7Jm5ic3A7IHRlY2huaXF1ZXMgKHNlZQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTI0NSNzZWN0aW9uLTEwIj5TZWN0aW9uJm5ic3A7MTAgb2YgW1JGQzUy NDVdPC9hPiBhbmQgc2VlIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2 MjYzIiB0aXRsZT0iJnF1b3Q7QXBwbGljYXRpb24gTWVjaGFuaXNtIGZvciBLZWVwaW5nIEFsaXZl IHRoZSBOQVQgTWFwcGluZ3MgQXNzb2NpYXRlZCB3aXRoIFJUUCAvIFJUUCBDb250cm9sIFByb3Rv Y29sIChSVENQKSBGbG93cyZxdW90OyI+UkZDNjI2MzwvYT5dKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mZ3Q7PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mZ3Q7DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+U28gdGhlcmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2 ZXMgYmVjYXVzZSBvZiB0aGUgbWVkaWEgdHJhZmZpYyBhcyBpdCBpcyBwb2ludGVkIG91dCBpbg0K PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5TZWN0aW9uIDIw LjIuMyBvZiBSRkMgNTI0NQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4mZ3Q7DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+aXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgY29uc2VudCBpcyB1c2VkIG9yIG5vdDwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPi4g SSB0aGluayB3ZSBjYW4gcmVtb3ZlIHRoZSBmb2xsb3dpbmcgbGluZSBpbiDigJxJZiBjb25zZW50 IGlzIHBlcmZvcm1lZA0KIHRoZW4gPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi PiZndDsNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj50aGVyZSBpcyBubyBuZWVkIHRvIHNl bmQga2VlcGFsaXZlIG1lc3NhZ2VzLiZxdW90OyBhbmQgYXZvaWQgdGhlIGNvbmZ1c2lvbiBvZiB1 cGRhdGluZyBSRkMgNTI0NS48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SSBhZ3JlZSB0 aGF0IHRoZSBjdXJyZW50IHRleHQgY2FuIGNvbmZ1c2UgcGVvcGxlLCBidXQgSSBzdGlsbCB0aGlu ayBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgZXhwbGljaXQgdGV4dCBzYXlpbmcgdGhhdCBrZWVw YWxpdmVzIGFyZSBub3Qgc2VudC4gUGVyaGFwcyBzb21ldGhpbmcNCiBsaWtlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPuKAnEZyb20gYSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVx dWVzdHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEgdHJhZmZpYy4gQmVjYXVzZSBvZiB0aGF0LCBkZWRp Y2F0ZWQga2VlcGFsaXZlcyAoZS5nLiBTVFVOIGJpbmRpbmcgcmVxdWVzdHMpIGFyZSBub3Qgc2Vu dA0KIG9uIGNhbmRpZGF0ZSBwYWlycyB3aGVyZSBjb25zZW50IHJlcXVlc3RzIGFyZSBzZW50LCBp biBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiAyMC4yLjMgb2YgW1JGQzUyNDVdLuKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Q2hyaXN0ZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IE1heSAyOSwgMjAxNSA2OjU0IEFNPGJyPg0KPGI+VG86PC9iPiBUZWQgSGFyZGllOyBCbGFjaywg RGF2aWQ8YnI+DQo8Yj5DYzo8L2I+IGpvZWwgamFlZ2dsaTsgPGEgaHJlZj0ibWFpbHRvOm9wcy1k aXJAaWV0Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWIt Y2hhaXJzQHRvb2xzLmlldGYub3JnIj5ydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQt aWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+U2VjdGlv biAyMC4yLjMgb2YgUkZDIDUyNDUgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRl bnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij7igJxTVFVOIGtlZXBh bGl2ZXMgKGluIHRoZSBmb3JtIG9mIFNUVU4gQmluZGluZyBJbmRpY2F0aW9ucykgYXJlIHNlbnQg aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBtaWRkbGUgb2YgYSBt ZWRpYSBzZXNzaW9uLiZuYnNwOyBIb3dldmVyLA0KPGI+dGhleSBhcmUgc2VudCBvbmx5IGluIHRo ZTxvOnA+PC9vOnA+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFic2VuY2Ugb2Yg YWN0dWFsIG1lZGlhIHRyYWZmaWM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPi7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij5TbywgaW4gdGhlIGNvbnNlbnQgZHJhZnQgd2UgY291bGQgc2F5IHRoYXQsIGZyb20gYSBrZWVw YWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEg dHJhZmZpYy4gVGhhdCB3b3VsZCB0aGVuIGltcGxpY2l0bHkNCiBtZWFuIHRoYXQgYWN0dWFsIGtl ZXBhbGl2ZXMgYXJlbuKAmXQgc2VudCB3aGVuIGNvbnNlbnQgaXMgdXNlZC4gVGhhdCB3YXksIHRo ZSBjb25zZW50IHNwZWMgd291bGQgYmUgY29tcGxpYW50IHRvIDUyNDUsIGFuZCB0aGVyZSB3b3Vs ZCBiZSBubyBuZWVkIGZvciBhbnkgdXBkYXRlIGV0Y+KApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2VudDo8L2I+IDI4IE1heSAyMDE1IDIz OjI2PGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnIj5ydGN3ZWItY2hhaXJzQHRvb2xz LmlldGYub3JnPC9hPjsgam9lbCBqYWVnZ2xpOw0KPGEgaHJlZj0ibWFpbHRvOm9wcy1kaXJAaWV0 Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3 ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVz aG5lc3MtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5IaSBEYXZpZCwgPG86 cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU aHUsIE1heSAyOCwgMjAxNSBhdCAxMjozNiBQTSwgQmxhY2ssIERhdmlkICZsdDs8YSBocmVmPSJt YWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLmJsYWNrQGVt Yy5jb208L2E+Jmd0Ow0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkknZCBl eHBlY3QgdGhhdCBldmVuIG92ZXJyaWRpbmcgUkZDIDUyNDUgY291bnRzIGFzIGFuIFVwZGF0ZSw8 YnI+DQpiZWNhdXNlIHRoZSByZXN1bHQgd291bGQgYmUgdGhhdCB0aGUgb3JpZ2luYWwgUkZDIDUy NDUgJnF1b3Q7TVVTVCZxdW90OyByZXF1aXJlbWVudDxicj4NCmlzIG5vIGxvbmdlciBnbG9iYWxs eSBhcHBsaWNhYmxlIHRvIGFsbCB1c2VzIG9mIFJGQyA1MjQ1LiZuYnNwOyBJbiBvdGhlciB3b3Jk cyw8YnI+DQpvdmVycmlkaW5nIFJGQyA1MjQ1IGVmZmVjdGl2ZWx5IHJld3JpdGVzIHRoZSAmcXVv dDtNVVNUJnF1b3Q7IHRvIGJlY29tZSAmcXVvdDtNVVNULCBleGNlcHQ8YnI+DQphcyBmdXJ0aGVy IHNwZWNpZmllZCBieSB0aGUgY29uc2VudCBSRkMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij7igItT byBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBtdXN0IGJlIGNhbGxlZCBvdXQsIGJ1dCBJIHRo aW5rICZxdW90O1VwZGF0ZXMmcXVvdDsgaXMgd3JvbmcgZm9yIHRoZSBkcmFmdCdzIGN1cnJlbnQg aW50ZW50LiZuYnNwOyBJIHRoaW5rIHdoYXQgTWFydGluIGhhcyBzYWlkIGFtb3VudHMgdG8gJnF1 b3Q7V2UgaGF2ZQ0KIGNob3NlbiB0byBmb2xsb3cgUkZDIDUyNDUgZXhjZXB0IGFzIGRldGFpbGVk IGluIHNlY3Rpb25zIFggYW5kIFksIHdoZXJlIHdlIHVzZSBhIGRpZmZlcmVudCBzZXQgb2YgbWVz c2FnZXMgdG8gb3B0aW1pemUgdGhlIGNvbWJpbmF0aW9uIG9mIGhlYXJ0YmVhdCBhbmQgY29uc2Vu dC4mcXVvdDsmbmJzcDsgV2UgYXJlIG5vdCB1cGRhdGluZyBSRkMgNTI0NSB0aGVyZWJ5LCBiZWNh dXNlIHdlIGFyZSBuZWl0aGVyIGNoYW5naW5nIGl0cyBjb3JlIHNlbWFudGljcyBub3INCiBvZmZl cmluZyB0byBhZGQgYSBuZXcsIGdlbmVyYWwgc2VtYW50aWMgdG8gUkZDIDUyNDUgKHdlIGNvdWxk IGhhdmUgbWFkZSB0aGF0IGNob2ljZSwgYnV0IGFyZSBub3QgZG9pbmcgc28gbm93KS4mbmJzcDsg SW5zdGVhZCBvZiB1cGRhdGluZyBSRkMgNTI0NSwgaW4gb3RoZXIgd29yZHMsIHdlIGFyZSBsaW1p dGluZyBvdXIgcmVmZXJlbmNlIHRvIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5UaGF0IHNob3Vs ZCBiZSBkb25lIGV4cGxpY2l0bHksIGFuZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBjYWxsZWQgaXQg c3VmZmlpY2llbnRseSB0aGF0IGEgbmV3IHNwaW4gb2YgdGhlIGRyYWZ0IGxpa2VseSBuZWVkcyBh IG5ldyByb3VuZCBvZiByZXZpZXcuJm5ic3A7IEJ1dCBJIGRvbid0IHRoaW5rDQogd2UgYXJlIHJl cXVpcmVkIHRvIHVwZGF0ZSBSRkMgNTI0NSB0byBnZXQgdGhhdCBkb25lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMt c2VyaWY7Ij5JJ3ZlIHJlZmVycmVkIHRoZSBtYXR0ZXIgdG8gb3VyIGZyaWVuZGx5IEFELCBhbmQg d2UgYXdhaXQgaGVyIHJlYWRpbmcgb24gbmV4dCBzdGVwcyBvbiB0aGlzLiZuYnNwOyBJbiBlaXRo ZXIgYXBwcm9hY2gsIGhvd2V2ZXIsIHRoaXMgd2lsbCBnZXQgY2FsbGVkIG91dC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogVGFob21hLCBz YW5zLXNlcmlmOyI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9tYSwg c2Fucy1zZXJpZjsiPlRlZCBIQXJkaWXigIs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_D18DD3D531978rmohanrciscocom_-- From nobody Thu May 28 20:20: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 8F7CE1A8982; Thu, 28 May 2015 20:20:06 -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 0iyPNSKZN3kx; Thu, 28 May 2015 20:20:01 -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 A681B1A8990; Thu, 28 May 2015 20:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32016; q=dns/txt; s=iport; t=1432869601; x=1434079201; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gfZBTFCJEBA7HY8gGwzfpOFY66gvGQwI7a1xhsbW6lw=; b=I09q44FBZuW1pMRsOMPa0peJ5c2AUCSBXw5unU/K89jBkEpnj+ZKPc3O MuuKpahC/nFGAxPaAHS+tcShRzKp7MemrFM8gBEQTMy55qMv+XYkra+BY Aku7PCe0e5ltdJSBVbJ+dvXu2dYcrzaZnUQco/dnPLu5Wquk0JLOkMS9O 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBACv2mdV/5NdJa1cgkVLVF4Ggxi6BDwqCYFahXcCHIEsOBQBAQEBAQEBgQqEIgEBAQMBIwpMBQsCAQgRBAEBCxYHAwICAjAUCQgCBAENBQiIHQgNshWkEgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLQ4RVMQYBgmgvgRYFkwiENYgDPo1ph18jYYEpHIFSb4EDBzyBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,514,1427760000"; d="scan'208,217";a="2732942" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-3.cisco.com with ESMTP; 29 May 2015 03:19:58 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4T3Jv2U011911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 03:19:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.253]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 28 May 2015 22:19:56 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Christer Holmberg , Ted Hardie , "Black, David" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AdCYTRwpDLI16eMpRUmkDRETmBwKqQAc0OqAABAN2oAAKb4SAAABtAIAAApo7AAACcBoUP//vfsAgABAAjA= Date: Fri, 29 May 2015 03:19:56 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A47861447@xmb-rcd-x10.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D86E037@ESESSMB209.ericsson.se> <913383AAA69FF945B8F946018B75898A47861342@xmb-rcd-x10.cisco.com> <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D86E2ED@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.38.201] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A47861447xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 03:20:06 -0000 --_000_913383AAA69FF945B8F946018B75898A47861447xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb21dDQpTZW50OiBGcmlkYXksIE1heSAyOSwgMjAxNSA3OjM3IEFNDQpUbzogVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTsgVGVkIEhhcmRpZTsgQmxhY2ssIERhdmlkDQpDYzogam9lbCBq YWVnZ2xpOyBvcHMtZGlyQGlldGYub3JnOyBydGN3ZWJAaWV0Zi5vcmc7IHJ0Y3dlYi1jaGFpcnNA dG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBk cmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLTEzDQoNCkhpLA0KDQo+R29v ZCBwb2ludC4gV2UgZGlzY3VzcyB0aGUgZm9sbG93aW5nIHBvaW50IGluIHNlY3Rpb24gNC4xIG9m IHRoZSBkcmFmdCBhYm91dCBrZWVwYWxpdmVzOg0KPg0KPiAgIEFuIGVuZHBvaW50IHRoYXQgaXMg bm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgbmVlZCB0bw0KPiAgIG1h aW50YWluIGNvbnNlbnQuICBIb3dldmVyLCBub3Qgc2VuZGluZyBhbnkgdHJhZmZpYyBjb3VsZCBj YXVzZSBOQVQNCj4gICBvciBmaXJld2FsbCBtYXBwaW5ncyB0byBleHBpcmUuICBGdXJ0aGVybW9y ZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJsZQ0KPiAgIHRvIHNlbmQgaXMgZGV0cmltZW50YWwgdG8g bWFueSBwcm90b2NvbHMuICBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uDQo+ICAgYWJvdXQgdGhl IG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBpdHMgTkFUIG9yIGZpcmV3 YWxsDQo+ICAgbWFwcGluZ3MgZG8gbm90IGV4cGlyZSwgaXQgY2FuIGJlIGRvbmUgdXNpbmcga2Vl cGFsaXZlIG9yIG90aGVyDQo+ICAgdGVjaG5pcXVlcyAoc2VlIFNlY3Rpb24gMTAgb2YgW1JGQzUy NDVdPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi0xMD4gYW5kIHNl ZSBbUkZDNjI2MzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjYzPl0pLg0KPg0KPiBT byB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlcyBiZWNhdXNlIG9mIHRoZSBtZWRp YSB0cmFmZmljIGFzIGl0IGlzIHBvaW50ZWQgb3V0IGluIFNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1 MjQ1DQo+IGlycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIGNvbnNlbnQgaXMgdXNlZCBvciBub3QuIEkg dGhpbmsgd2UgY2FuIHJlbW92ZSB0aGUgZm9sbG93aW5nIGxpbmUgaW4g4oCcSWYgY29uc2VudCBp cyBwZXJmb3JtZWQgdGhlbg0KPiB0aGVyZSBpcyBubyBuZWVkIHRvIHNlbmQga2VlcGFsaXZlIG1l c3NhZ2VzLiIgYW5kIGF2b2lkIHRoZSBjb25mdXNpb24gb2YgdXBkYXRpbmcgUkZDIDUyNDUuDQoN CkkgYWdyZWUgdGhhdCB0aGUgY3VycmVudCB0ZXh0IGNhbiBjb25mdXNlIHBlb3BsZSwgYnV0IEkg c3RpbGwgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGV4cGxpY2l0IHRleHQgc2F5aW5n IHRoYXQga2VlcGFsaXZlcyBhcmUgbm90IHNlbnQuIFBlcmhhcHMgc29tZXRoaW5nIGxpa2U6DQoN CuKAnEZyb20gYSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNv bnNpZGVyZWQgbWVkaWEgdHJhZmZpYy4gQmVjYXVzZSBvZiB0aGF0LCBkZWRpY2F0ZWQga2VlcGFs aXZlcyAoZS5nLiBTVFVOIGJpbmRpbmcgcmVxdWVzdHMpIGFyZSBub3Qgc2VudCBvbiBjYW5kaWRh dGUgcGFpcnMgd2hlcmUgY29uc2VudCByZXF1ZXN0cyBhcmUgc2VudCwgaW4gYWNjb3JkYW5jZSB3 aXRoIFNlY3Rpb24gMjAuMi4zIG9mIFtSRkM1MjQ1XS7igJ0NCg0KV29ya3MgZm9yIG1lIChSZXBs YWNlZCBTVFVOIGJpbmRpbmcgcmVxdWVzdHMgd2l0aCBTVFVOIEJpbmRpbmcgSW5kaWNhdGlvbnMg aW4gdGhlIGFib3ZlIGxpbmUpLg0KDQpDaGVlcnMsDQotVGlydQ0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IEZyaWRheSwgTWF5IDI5LCAyMDE1 IDY6NTQgQU0NClRvOiBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQNCkNjOiBqb2VsIGphZWdnbGk7 IG9wcy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBydGN3ZWJAaWV0Zi5v cmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz47IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNo bmVzcy0xMw0KDQoNCkhpLA0KDQpTZWN0aW9uIDIwLjIuMyBvZiBSRkMgNTI0NSBzYXlzOg0KDQri gJxTVFVOIGtlZXBhbGl2ZXMgKGluIHRoZSBmb3JtIG9mIFNUVU4gQmluZGluZyBJbmRpY2F0aW9u cykgYXJlIHNlbnQgaW4NCiAgICAgICAgICAgICAgdGhlIG1pZGRsZSBvZiBhIG1lZGlhIHNlc3Np b24uICBIb3dldmVyLCB0aGV5IGFyZSBzZW50IG9ubHkgaW4gdGhlDQogICAgICAgICAgICAgIGFi c2VuY2Ugb2YgYWN0dWFsIG1lZGlhIHRyYWZmaWMu4oCdDQoNClNvLCBpbiB0aGUgY29uc2VudCBk cmFmdCB3ZSBjb3VsZCBzYXkgdGhhdCwgZnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVjdGl2ZSwgY29u c2VudCByZXF1ZXN0cyBhcmUgY29uc2lkZXJlZCBtZWRpYSB0cmFmZmljLiBUaGF0IHdvdWxkIHRo ZW4gaW1wbGljaXRseSBtZWFuIHRoYXQgYWN0dWFsIGtlZXBhbGl2ZXMgYXJlbuKAmXQgc2VudCB3 aGVuIGNvbnNlbnQgaXMgdXNlZC4gVGhhdCB3YXksIHRoZSBjb25zZW50IHNwZWMgd291bGQgYmUg Y29tcGxpYW50IHRvIDUyNDUsIGFuZCB0aGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciBhbnkgdXBk YXRlIGV0Y+KApg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IHJ0Y3dlYiBbbWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2Vu dDogMjggTWF5IDIwMTUgMjM6MjYNClRvOiBCbGFjaywgRGF2aWQNCkNjOiBydGN3ZWItY2hhaXJz QHRvb2xzLmlldGYub3JnPG1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgam9l bCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3JnPjsgcnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNo bmVzcy0xMw0KDQpIaSBEYXZpZCwNCg0KT24gVGh1LCBNYXkgMjgsIDIwMTUgYXQgMTI6MzYgUE0s IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2aWQuYmxhY2tAZW1j LmNvbT4+DQoNCkknZCBleHBlY3QgdGhhdCBldmVuIG92ZXJyaWRpbmcgUkZDIDUyNDUgY291bnRz IGFzIGFuIFVwZGF0ZSwNCmJlY2F1c2UgdGhlIHJlc3VsdCB3b3VsZCBiZSB0aGF0IHRoZSBvcmln aW5hbCBSRkMgNTI0NSAiTVVTVCIgcmVxdWlyZW1lbnQNCmlzIG5vIGxvbmdlciBnbG9iYWxseSBh cHBsaWNhYmxlIHRvIGFsbCB1c2VzIG9mIFJGQyA1MjQ1LiAgSW4gb3RoZXIgd29yZHMsDQpvdmVy cmlkaW5nIFJGQyA1MjQ1IGVmZmVjdGl2ZWx5IHJld3JpdGVzIHRoZSAiTVVTVCIgdG8gYmVjb21l ICJNVVNULCBleGNlcHQNCmFzIGZ1cnRoZXIgc3BlY2lmaWVkIGJ5IHRoZSBjb25zZW50IFJGQy4i DQoNCuKAi1NvIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2FsbGVkIG91dCwg YnV0IEkgdGhpbmsgIlVwZGF0ZXMiIGlzIHdyb25nIGZvciB0aGUgZHJhZnQncyBjdXJyZW50IGlu dGVudC4gIEkgdGhpbmsgd2hhdCBNYXJ0aW4gaGFzIHNhaWQgYW1vdW50cyB0byAiV2UgaGF2ZSBj aG9zZW4gdG8gZm9sbG93IFJGQyA1MjQ1IGV4Y2VwdCBhcyBkZXRhaWxlZCBpbiBzZWN0aW9ucyBY IGFuZCBZLCB3aGVyZSB3ZSB1c2UgYSBkaWZmZXJlbnQgc2V0IG9mIG1lc3NhZ2VzIHRvIG9wdGlt aXplIHRoZSBjb21iaW5hdGlvbiBvZiBoZWFydGJlYXQgYW5kIGNvbnNlbnQuIiAgV2UgYXJlIG5v dCB1cGRhdGluZyBSRkMgNTI0NSB0aGVyZWJ5LCBiZWNhdXNlIHdlIGFyZSBuZWl0aGVyIGNoYW5n aW5nIGl0cyBjb3JlIHNlbWFudGljcyBub3Igb2ZmZXJpbmcgdG8gYWRkIGEgbmV3LCBnZW5lcmFs IHNlbWFudGljIHRvIFJGQyA1MjQ1ICh3ZSBjb3VsZCBoYXZlIG1hZGUgdGhhdCBjaG9pY2UsIGJ1 dCBhcmUgbm90IGRvaW5nIHNvIG5vdykuICBJbnN0ZWFkIG9mIHVwZGF0aW5nIFJGQyA1MjQ1LCBp biBvdGhlciB3b3Jkcywgd2UgYXJlIGxpbWl0aW5nIG91ciByZWZlcmVuY2UgdG8gaXQuDQpUaGF0 IHNob3VsZCBiZSBkb25lIGV4cGxpY2l0bHksIGFuZCBJIHRoaW5rIGl0IHNob3VsZCBiZSBjYWxs ZWQgaXQgc3VmZmlpY2llbnRseSB0aGF0IGEgbmV3IHNwaW4gb2YgdGhlIGRyYWZ0IGxpa2VseSBu ZWVkcyBhIG5ldyByb3VuZCBvZiByZXZpZXcuICBCdXQgSSBkb24ndCB0aGluayB3ZSBhcmUgcmVx dWlyZWQgdG8gdXBkYXRlIFJGQyA1MjQ1IHRvIGdldCB0aGF0IGRvbmUuDQpJJ3ZlIHJlZmVycmVk IHRoZSBtYXR0ZXIgdG8gb3VyIGZyaWVuZGx5IEFELCBhbmQgd2UgYXdhaXQgaGVyIHJlYWRpbmcg b24gbmV4dCBzdGVwcyBvbiB0aGlzLiAgSW4gZWl0aGVyIGFwcHJvYWNoLCBob3dldmVyLCB0aGlz IHdpbGwgZ2V0IGNhbGxlZCBvdXQuDQpyZWdhcmRzLA0KVGVkIEhBcmRpZeKAiw0KDQo= --_000_913383AAA69FF945B8F946018B75898A47861447xmbrcdx10ciscoc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDI5LCAyMDE1IDc6 MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7IFRlZCBI YXJkaWU7IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj4gam9lbCBqYWVnZ2xpOyBvcHMtZGly QGlldGYub3JnOyBydGN3ZWJAaWV0Zi5vcmc7IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OzxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5Hb29kIHBvaW50LiBXZSBkaXNjdXNzIHRoZSBmb2xsb3dpbmcg cG9pbnQgaW4gc2VjdGlvbiA0LjEgb2YgdGhlIGRyYWZ0IGFib3V0IGtlZXBhbGl2ZXM6PG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jmd0OzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZndDsmbmJzcDsmbmJzcDsgQW4gZW5kcG9pbnQgdGhhdCBpcyBub3Qgc2VuZGluZyBhbnkg YXBwbGljYXRpb24gZGF0YSBkb2VzIG5vdCBuZWVkIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgbWFpbnRhaW4g Y29uc2VudC4mbmJzcDsgSG93ZXZlciwgbm90IHNlbmRpbmcgYW55IHRyYWZmaWMgY291bGQgY2F1 c2UgTkFUPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZndDsmbmJzcDsmbmJzcDsgb3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhwaXJlLiZuYnNw OyBGdXJ0aGVybW9yZSwgaGF2aW5nIG9uZSBwZWVyIHVuYWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IHRvIHNl bmQgaXMgZGV0cmltZW50YWwgdG8gbWFueSBwcm90b2NvbHMuJm5ic3A7IEFic2VudCBiZXR0ZXIg aW5mb3JtYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyBhYm91dCB0aGUgbmV0d29yaywgaWYgYW4gZW5kcG9p bnQgbmVlZHMgdG8gZW5zdXJlIGl0cyBOQVQgb3IgZmlyZXdhbGw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyBtYXBw aW5ncyBkbyBub3QgZXhwaXJlLCBpdCBjYW4gYmUgZG9uZSB1c2luZyBrZWVwYWxpdmUgb3Igb3Ro ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jmd0OyZuYnNwOyZuYnNwOyB0ZWNobmlxdWVzIChzZWUNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi0xMCI+U2VjdGlvbiZuYnNwOzEwIG9mIFtSRkM1 MjQ1XTwvYT4gYW5kIHNlZSBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NjI2MyIgdGl0bGU9IiZxdW90O0FwcGxpY2F0aW9uIE1lY2hhbmlzbSBmb3IgS2VlcGluZyBBbGl2 ZSB0aGUgTkFUIE1hcHBpbmdzIEFzc29jaWF0ZWQgd2l0aCBSVFAgLyBSVFAgQ29udHJvbCBQcm90 b2NvbCAoUlRDUCkgRmxvd3MmcXVvdDsiPlJGQzYyNjM8L2E+XSkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m Z3Q7PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZndDsNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyB0aGVyZSBpcyBubyBuZWVk IHRvIHNlbmQga2VlcGFsaXZlcyBiZWNhdXNlIG9mIHRoZSBtZWRpYSB0cmFmZmljIGFzIGl0IGlz IHBvaW50ZWQgb3V0IGluDQo8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiAyMC4yLjMgb2YgUkZDIDUyNDUN Cjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ aXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgY29uc2VudCBpcyB1c2VkIG9yIG5vdDwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi4gSSB0aGluayB3 ZSBjYW4gcmVtb3ZlIHRoZSBmb2xsb3dpbmcgbGluZSBpbiDigJxJZiBjb25zZW50IGlzIHBlcmZv cm1lZCB0aGVuDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZndDsNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj50aGVyZSBpcyBubyBuZWVk IHRvIHNlbmQga2VlcGFsaXZlIG1lc3NhZ2VzLiZxdW90OyBhbmQgYXZvaWQgdGhlIGNvbmZ1c2lv biBvZiB1cGRhdGluZyBSRkMgNTI0NS48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkkgYWdyZWUgdGhhdCB0aGUgY3VycmVudCB0ZXh0IGNhbiBjb25mdXNlIHBl b3BsZSwgYnV0IEkgc3RpbGwgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGV4cGxpY2l0 IHRleHQgc2F5aW5nIHRoYXQga2VlcGFsaXZlcyBhcmUgbm90IHNlbnQuIFBlcmhhcHMgc29tZXRo aW5nIGxpa2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAnEZyb20g YSBrZWVwYWxpdmUgcGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQg bWVkaWEgdHJhZmZpYy4gQmVjYXVzZSBvZiB0aGF0LCBkZWRpY2F0ZWQga2VlcGFsaXZlcyAoZS5n LiBTVFVOIGJpbmRpbmcgcmVxdWVzdHMpIGFyZSBub3Qgc2VudCBvbiBjYW5kaWRhdGUNCiBwYWly cyB3aGVyZSBjb25zZW50IHJlcXVlc3RzIGFyZSBzZW50LCBpbiBhY2NvcmRhbmNlIHdpdGggU2Vj dGlvbiAyMC4yLjMgb2YgW1JGQzUyNDVdLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V29ya3MgZm9yIG1lIChSZXBs YWNlZA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U1RVTiBiaW5kaW5nIHJl cXVlc3RzIHdpdGggU1RVTiBCaW5kaW5nIEluZGljYXRpb25zIGluIHRoZSBhYm92ZSBsaW5lKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+LVRpcnU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgWzxhIGhyZWY9 Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMjksIDIwMTUgNjo1NCBBTTxicj4NCjxiPlRvOjwvYj4g VGVkIEhhcmRpZTsgQmxhY2ssIERhdmlkPGJyPg0KPGI+Q2M6PC9iPiBqb2VsIGphZWdnbGk7IDxh IGhyZWY9Im1haWx0bzpvcHMtZGlyQGlldGYub3JnIj5vcHMtZGlyQGlldGYub3JnPC9hPjsgPGEg aHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+cnRjd2ViLWNoYWlyc0B0 b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIE9QUy1E aXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1MjQ1IHNheXM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVp biI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij7igJxTVFVOIGtlZXBhbGl2ZXMgKGluIHRoZSBmb3JtIG9mIFNUVU4gQmluZGluZyBJbmRpY2F0 aW9ucykgYXJlIHNlbnQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIG1pZGRsZSBvZiBhIG1lZGlhIHNlc3Npb24uJm5ic3A7 IEhvd2V2ZXIsDQo8Yj50aGV5IGFyZSBzZW50IG9ubHkgaW4gdGhlPG86cD48L286cD48L2I+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhYnNlbmNl IG9mIGFjdHVhbCBtZWRpYSB0cmFmZmljPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi7igJ08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U28sIGluIHRoZSBjb25zZW50IGRyYWZ0IHdlIGNvdWxkIHNheSB0 aGF0LCBmcm9tIGEga2VlcGFsaXZlIHBlcnNwZWN0aXZlLCBjb25zZW50IHJlcXVlc3RzIGFyZSBj b25zaWRlcmVkIG1lZGlhIHRyYWZmaWMuIFRoYXQgd291bGQgdGhlbiBpbXBsaWNpdGx5DQogbWVh biB0aGF0IGFjdHVhbCBrZWVwYWxpdmVzIGFyZW7igJl0IHNlbnQgd2hlbiBjb25zZW50IGlzIHVz ZWQuIFRoYXQgd2F5LCB0aGUgY29uc2VudCBzcGVjIHdvdWxkIGJlIGNvbXBsaWFudCB0byA1MjQ1 LCBhbmQgdGhlcmUgd291bGQgYmUgbm8gbmVlZCBmb3IgYW55IHVwZGF0ZSBldGPigKY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5j ZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlRlZCBIYXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gMjggTWF5IDIwMTUgMjM6 MjY8YnI+DQo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPnJ0Y3dlYi1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8L2E+OyBqb2VsIGphZWdnbGk7DQo8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRm Lm9yZyI+b3BzLWRpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciPg0KcnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dl Yl0gT1BTLURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNo bmVzcy0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIERhdmlkLA0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gVGh1LCBNYXkgMjgs IDIwMTUgYXQgMTI6MzYgUE0sIEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlk LmJsYWNrQGVtYy5jb20iIHRhcmdldD0iX2JsYW5rIj5kYXZpZC5ibGFja0BlbWMuY29tPC9hPiZn dDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxicj4NCkknZCBleHBlY3QgdGhhdCBldmVuIG92ZXJyaWRpbmcgUkZDIDUyNDUgY291bnRz IGFzIGFuIFVwZGF0ZSw8YnI+DQpiZWNhdXNlIHRoZSByZXN1bHQgd291bGQgYmUgdGhhdCB0aGUg b3JpZ2luYWwgUkZDIDUyNDUgJnF1b3Q7TVVTVCZxdW90OyByZXF1aXJlbWVudDxicj4NCmlzIG5v IGxvbmdlciBnbG9iYWxseSBhcHBsaWNhYmxlIHRvIGFsbCB1c2VzIG9mIFJGQyA1MjQ1LiZuYnNw OyBJbiBvdGhlciB3b3Jkcyw8YnI+DQpvdmVycmlkaW5nIFJGQyA1MjQ1IGVmZmVjdGl2ZWx5IHJl d3JpdGVzIHRoZSAmcXVvdDtNVVNUJnF1b3Q7IHRvIGJlY29tZSAmcXVvdDtNVVNULCBleGNlcHQ8 YnI+DQphcyBmdXJ0aGVyIHNwZWNpZmllZCBieSB0aGUgY29uc2VudCBSRkMuJnF1b3Q7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLU28gSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHRoaXMgbXVz dCBiZSBjYWxsZWQgb3V0LCBidXQgSSB0aGluayAmcXVvdDtVcGRhdGVzJnF1b3Q7IGlzIHdyb25n IGZvciB0aGUgZHJhZnQncyBjdXJyZW50IGludGVudC4mbmJzcDsgSSB0aGluayB3aGF0IE1hcnRp biBoYXMgc2FpZCBhbW91bnRzDQogdG8gJnF1b3Q7V2UgaGF2ZSBjaG9zZW4gdG8gZm9sbG93IFJG QyA1MjQ1IGV4Y2VwdCBhcyBkZXRhaWxlZCBpbiBzZWN0aW9ucyBYIGFuZCBZLCB3aGVyZSB3ZSB1 c2UgYSBkaWZmZXJlbnQgc2V0IG9mIG1lc3NhZ2VzIHRvIG9wdGltaXplIHRoZSBjb21iaW5hdGlv biBvZiBoZWFydGJlYXQgYW5kIGNvbnNlbnQuJnF1b3Q7Jm5ic3A7IFdlIGFyZSBub3QgdXBkYXRp bmcgUkZDIDUyNDUgdGhlcmVieSwgYmVjYXVzZSB3ZSBhcmUgbmVpdGhlciBjaGFuZ2luZyBpdHMg Y29yZSBzZW1hbnRpY3MNCiBub3Igb2ZmZXJpbmcgdG8gYWRkIGEgbmV3LCBnZW5lcmFsIHNlbWFu dGljIHRvIFJGQyA1MjQ1ICh3ZSBjb3VsZCBoYXZlIG1hZGUgdGhhdCBjaG9pY2UsIGJ1dCBhcmUg bm90IGRvaW5nIHNvIG5vdykuJm5ic3A7IEluc3RlYWQgb2YgdXBkYXRpbmcgUkZDIDUyNDUsIGlu IG90aGVyIHdvcmRzLCB3ZSBhcmUgbGltaXRpbmcgb3VyIHJlZmVyZW5jZSB0byBpdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYXQgc2hv dWxkIGJlIGRvbmUgZXhwbGljaXRseSwgYW5kIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGNhbGxlZCBp dCBzdWZmaWljaWVudGx5IHRoYXQgYSBuZXcgc3BpbiBvZiB0aGUgZHJhZnQgbGlrZWx5IG5lZWRz IGEgbmV3IHJvdW5kIG9mIHJldmlldy4mbmJzcDsNCiBCdXQgSSBkb24ndCB0aGluayB3ZSBhcmUg cmVxdWlyZWQgdG8gdXBkYXRlIFJGQyA1MjQ1IHRvIGdldCB0aGF0IGRvbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JJ3ZlIHJlZmVycmVk IHRoZSBtYXR0ZXIgdG8gb3VyIGZyaWVuZGx5IEFELCBhbmQgd2UgYXdhaXQgaGVyIHJlYWRpbmcg b24gbmV4dCBzdGVwcyBvbiB0aGlzLiZuYnNwOyBJbiBlaXRoZXIgYXBwcm9hY2gsIGhvd2V2ZXIs IHRoaXMgd2lsbCBnZXQgY2FsbGVkIG91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+VGVkIEhBcmRpZeKAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A47861447xmbrcdx10ciscoc_-- From nobody Thu May 28 20:50:59 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 DA0891A8A1C; Thu, 28 May 2015 20:50:54 -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 1SSUJm2iFFKP; Thu, 28 May 2015 20:50:53 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8277B1A8A0E; Thu, 28 May 2015 20:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1612; q=dns/txt; s=iport; t=1432871453; x=1434081053; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IsXcVr3qqRVc7LZm7idyPEJ4WjhNKWoaZlTgElAufQo=; b=hszSjO8XVQ/+GjQ5O+/xYwAgMcgJYZ9yN1ueUqZma5f7hH9ScNtoI7eo 2MyhCDKXPd5vCJ5npy0kx64Eh4oFDCBq4vwsvrYcuciFXe8ZAol+EsQxZ nGwx8BCuloJLUHTEaDNDYDCKnBVp9lN+oYltkBwVD31sI+HhaR+loR6aT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A/BACq4WdV/4MNJK1cgxCBMga+AgmHUQKBSDgUAQEBAQEBAYEKhCIBAQEEOksEAgEIEQMBAh8QMh0IAgQBEogt1hMBAQEBAQEBAQIBAQEBAQEBG4tDhQ0GhCcBBJMIiw+XLyNhgxdvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,514,1427760000"; d="scan'208";a="154298840" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP; 29 May 2015 03:50:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4T3oqLc007491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 03:50:52 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.135]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 28 May 2015 22:50:52 -0500 From: "Ram Mohan R (rmohanr)" To: "Tirumaleswar Reddy (tireddy)" , "Black, David (david.black@emc.com)" , "joel jaeggli (joelja@bogus.com)" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmcKoVnZDKnMNxUCZQpJSA9/Blw== Date: Fri, 29 May 2015 03:50:51 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.66.37] Content-Type: text/plain; charset="us-ascii" Content-ID: <549A17227FF46748920508CFF8D333CE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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: Fri, 29 May 2015 03:50:55 -0000 See inline for one comment: -----Original Message----- From: "Tirumaleswar Reddy (tireddy)" Date: Thursday, 28 May 2015 12:02 pm To: "Black, David (david.black@emc.com)" , "joel jaeggli (joelja@bogus.com)" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 >>Ok, but .. this is not about "how applications should handle" loss of >>consent; >>it's about "how implementations should report" loss of consent. Part of >>this >>is already in Section 7, which indicates how the application learns that >>consent has expired. It would suffice to add a sentence added to that >>section to indicate that there are other reasons for loss of ability to >>transmit >>data, and include an example of how at least one other is reported to >>applications. > >NEW: >The circuit breaker algorithm discussed in section 7.1 of >[I-D.ietf-rtcweb-rtp-usage] could be one of the reasons for ceasing >transmission of media and to notify the application about the loss of >ability to transmit data. There may be multiple reasons for a webRTC endpoint to cease transmission (one being circuit breaker) and I feel we should not add all those here in consent draft. Also the the above statement indicates a need for a new API to notify the application about the loss of ability and this is some thing outside the scope of this document. IMO this text looks out of place and we should not add this to draft. Regards, Ram From nobody Fri May 29 01:49: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 E62B21B2A97; Fri, 29 May 2015 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQctFUuNJ2P0; Fri, 29 May 2015 01:48:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A9C1A87C6; Fri, 29 May 2015 01:48:57 -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.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529084857.8376.81137.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 01:48:57 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-24.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, 29 May 2015 08:48:59 -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-24.txt Pages : 45 Date : 2015-05-29 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-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-24 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 May 29 02:00: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 DB8DF1B2A9F for ; Fri, 29 May 2015 02:00:17 -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 crAVzOLesR2p for ; Fri, 29 May 2015 02:00:16 -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 B8E5F1A8A67 for ; Fri, 29 May 2015 02:00:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-07-55682a9d28b3 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1A.BD.28096.D9A28655; Fri, 29 May 2015 11:00:14 +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; Fri, 29 May 2015 11:00:13 +0200 Message-ID: <55682A9C.3040705@ericsson.com> Date: Fri, 29 May 2015 11:00:12 +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: <20150529084857.8376.81137.idtracker@ietfa.amsl.com> In-Reply-To: <20150529084857.8376.81137.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvre48rYxQg18NTBbTz/xltFj7r53d gcnjy5OXTB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYveIvW8E10YqfX86zNDA2CXYxcnJICJhI LLr3nAXCFpO4cG89WxcjF4eQwFFGiXt3m1ggnOWMEjP+zmQEqeIV0Ja4dbiDHcRmEVCVWPWo hwnEZhOwkLj5o5ENxBYViJKY+ngdC0S9oMTJmU/AbBGg+qvHfoDVMAuISrx6OIUZxBYWsJb4 vR7CFhJwkJi0dxbYLk4BR4mz084A9XIA1dtLPNhaBtEqL9G8dTZUubZEQ1MH6wRGwVlIts1C 6JiFpGMBI/MqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMBgPbjlt9UOxoPPHQ8xCnAwKvHw JjBkhAqxJpYVV+YeYpTmYFES5/XsCgkVEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiXeVFO IttLwECnpMpjlqfc3K9+j8RsJs3sFlT0jok4pf3uwQbnoLxp3t+YzqurCH3jWnf2xUJnkyed J5OPlzJbm55NX8u4xkbom3berOADrHKC7ybzfXy56FH3z/MP6j4qnV781faJ3D3OmhcXVvWF 7zi3ILrt4C71mvhZrCanOlOf/3h5/okSS3FGoqEWc1FxIgBDq+PWNwIAAA== Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-24.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, 29 May 2015 09:00:18 -0000 Alissa and WG, This version should address the AD review comments. Please review the diff for the various minor fixes to the text that has been done. I have not seen any other IETF last call comments than IANA. Which is a bit surprising. Cheers Magnus internet-drafts@ietf.org skrev den 2015-05-29 10:48: > > 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-24.txt > Pages : 45 > Date : 2015-05-29 > > 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-24 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-24 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- 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 May 29 07:37: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 BC5911A90D1 for ; Fri, 29 May 2015 07:37:15 -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_20=-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 BEgS88fqtFeI for ; Fri, 29 May 2015 07:37:15 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.159.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0411A90C8 for ; Fri, 29 May 2015 07:37:14 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 433934E269807; Fri, 29 May 2015 09:37:14 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 35BC94E2697E6 for ; Fri, 29 May 2015 09:37:14 -0500 (CDT) Received: from [173.73.121.66] (port=59823 helo=[192.168.1.6]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YyLPN-0003At-Kp for rtcweb@ietf.org; Fri, 29 May 2015 09:37:13 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 29 May 2015 10:37:12 -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: 173.73.121.66 X-Exim-ID: 1YyLPN-0003At-Kp X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.6]) [173.73.121.66]:59823 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [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: Fri, 29 May 2015 14:37:15 -0000 Hi, =20 Doodle has spoken and we have a majority preference from the = participants in the poll for the next RTCweb WG JSEP-focused Virtual = Interim to be held on Thursday 6/18, 9-11AM PDT. Please mark this date = and time in your schedules. I will ask the Secretariat for a Webex = session =96 please stay tuned. =20 Thanks and Regards, =20 spt= From nobody Fri May 29 11:12: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 47DFE1B2B50; Fri, 29 May 2015 11:12:05 -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 4kQIQ1MGm_nA; Fri, 29 May 2015 11:11:59 -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 712C31B2B44; Fri, 29 May 2015 11:11:59 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4TIBkDF031285 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2015 14:11:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t4TIBkDF031285 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1432923110; bh=aQD6Ce30m6R/qs2+4eGSQG3TYVw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=gnlR60pk4xff5jSgnJAMPkcD05F5+FyvXc1W9xWHJpqv06+0fo4orVzqjub4vpqtw yjBWW1P5O0g0GRWnEuA2nKD+GEtFyir04fVdDCDPiFLaM1P2Joe9uMgInNUi5hQGox RY5DnhN2wXru0dvNQFTr6qrwCA7l2jIMOLpzwsdQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com t4TIBkDF031285 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 29 May 2015 14:10:56 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4TIBTNB014798 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 14:11:29 -0400 Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub01.corp.emc.com (10.254.141.103) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 29 May 2015 14:11:28 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.77]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0224.002; Fri, 29 May 2015 14:11:29 -0400 From: "Black, David" To: "Tirumaleswar Reddy (tireddy)" , Christer Holmberg , Ted Hardie Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmbLQj9rK05idUkWAIovS2YdbXZ2Sd9wAgAAUeACAALWgYA== Date: Fri, 29 May 2015 18:11: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> In-Reply-To: <913383AAA69FF945B8F946018B75898A47861447@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.13.35.216] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949364CB73DMX104CL02corpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: 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 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 18:12:05 -0000 --_000_CE03DB3D7B45C245BCA0D243277949364CB73DMX104CL02corpemcc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBhbHNvIHdvcmtzIGZvciBtZSwgYW5kIG5lYXRseSBzaWRlc3RlcHMgdGhlIGNvbmNlcm4g YWJvdXQNCndoZXRoZXIgUkZDIDUyNDUgaXMgYmVpbmcgdXBkYXRlZC4NCg0KVGhhbmtzLA0KLS1E YXZpZA0KDQpGcm9tOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFttYWlsdG86dGlyZWRk eUBjaXNjby5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDI4LCAyMDE1IDExOjIwIFBNDQpUbzog Q2hyaXN0ZXIgSG9sbWJlcmc7IFRlZCBIYXJkaWU7IEJsYWNrLCBEYXZpZA0KQ2M6IGpvZWwgamFl Z2dsaTsgb3BzLWRpckBpZXRmLm9yZzsgcnRjd2ViQGlldGYub3JnOyBydGN3ZWItY2hhaXJzQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gT1BTLURpciByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0xMw0KDQpGcm9tOiBDaHJpc3Rl ciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbV0NClNlbnQ6 IEZyaWRheSwgTWF5IDI5LCAyMDE1IDc6MzcgQU0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRp cmVkZHkpOyBUZWQgSGFyZGllOyBCbGFjaywgRGF2aWQNCkNjOiBqb2VsIGphZWdnbGk7IG9wcy1k aXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz47IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gT1BT LURpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNobmVzcy0x Mw0KDQpIaSwNCg0KPkdvb2QgcG9pbnQuIFdlIGRpc2N1c3MgdGhlIGZvbGxvd2luZyBwb2ludCBp biBzZWN0aW9uIDQuMSBvZiB0aGUgZHJhZnQgYWJvdXQga2VlcGFsaXZlczoNCj4NCj4gICBBbiBl bmRwb2ludCB0aGF0IGlzIG5vdCBzZW5kaW5nIGFueSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMgbm90 IG5lZWQgdG8NCj4gICBtYWludGFpbiBjb25zZW50LiAgSG93ZXZlciwgbm90IHNlbmRpbmcgYW55 IHRyYWZmaWMgY291bGQgY2F1c2UgTkFUDQo+ICAgb3IgZmlyZXdhbGwgbWFwcGluZ3MgdG8gZXhw aXJlLiAgRnVydGhlcm1vcmUsIGhhdmluZyBvbmUgcGVlciB1bmFibGUNCj4gICB0byBzZW5kIGlz IGRldHJpbWVudGFsIHRvIG1hbnkgcHJvdG9jb2xzLiAgQWJzZW50IGJldHRlciBpbmZvcm1hdGlv bg0KPiAgIGFib3V0IHRoZSBuZXR3b3JrLCBpZiBhbiBlbmRwb2ludCBuZWVkcyB0byBlbnN1cmUg aXRzIE5BVCBvciBmaXJld2FsbA0KPiAgIG1hcHBpbmdzIGRvIG5vdCBleHBpcmUsIGl0IGNhbiBi ZSBkb25lIHVzaW5nIGtlZXBhbGl2ZSBvciBvdGhlcg0KPiAgIHRlY2huaXF1ZXMgKHNlZSBTZWN0 aW9uIDEwIG9mIFtSRkM1MjQ1XTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3Nl Y3Rpb24tMTA+IGFuZCBzZWUgW1JGQzYyNjM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NjI2Mz5dKS4NCj4NCj4gU28gdGhlcmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZXMgYmVj YXVzZSBvZiB0aGUgbWVkaWEgdHJhZmZpYyBhcyBpdCBpcyBwb2ludGVkIG91dCBpbiBTZWN0aW9u IDIwLjIuMyBvZiBSRkMgNTI0NQ0KPiBpcnJlc3BlY3RpdmUgb2Ygd2hldGhlciBjb25zZW50IGlz IHVzZWQgb3Igbm90LiBJIHRoaW5rIHdlIGNhbiByZW1vdmUgdGhlIGZvbGxvd2luZyBsaW5lIGlu IOKAnElmIGNvbnNlbnQgaXMgcGVyZm9ybWVkIHRoZW4NCj4gdGhlcmUgaXMgbm8gbmVlZCB0byBz ZW5kIGtlZXBhbGl2ZSBtZXNzYWdlcy4iIGFuZCBhdm9pZCB0aGUgY29uZnVzaW9uIG9mIHVwZGF0 aW5nIFJGQyA1MjQ1Lg0KDQpJIGFncmVlIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCBjYW4gY29uZnVz ZSBwZW9wbGUsIGJ1dCBJIHN0aWxsIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBleHBs aWNpdCB0ZXh0IHNheWluZyB0aGF0IGtlZXBhbGl2ZXMgYXJlIG5vdCBzZW50LiBQZXJoYXBzIHNv bWV0aGluZyBsaWtlOg0KDQrigJxGcm9tIGEga2VlcGFsaXZlIHBlcnNwZWN0aXZlLCBjb25zZW50 IHJlcXVlc3RzIGFyZSBjb25zaWRlcmVkIG1lZGlhIHRyYWZmaWMuIEJlY2F1c2Ugb2YgdGhhdCwg ZGVkaWNhdGVkIGtlZXBhbGl2ZXMgKGUuZy4gU1RVTiBiaW5kaW5nIHJlcXVlc3RzKSBhcmUgbm90 IHNlbnQgb24gY2FuZGlkYXRlIHBhaXJzIHdoZXJlIGNvbnNlbnQgcmVxdWVzdHMgYXJlIHNlbnQs IGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDIwLjIuMyBvZiBbUkZDNTI0NV0u4oCdDQoNCldv cmtzIGZvciBtZSAoUmVwbGFjZWQgU1RVTiBiaW5kaW5nIHJlcXVlc3RzIHdpdGggU1RVTiBCaW5k aW5nIEluZGljYXRpb25zIGluIHRoZSBhYm92ZSBsaW5lKS4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBGcmlk YXksIE1heSAyOSwgMjAxNSA2OjU0IEFNDQpUbzogVGVkIEhhcmRpZTsgQmxhY2ssIERhdmlkDQpD Yzogam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYub3JnPG1haWx0bzpvcHMtZGlyQGlldGYub3Jn PjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+OyBydGN3ZWItY2hhaXJz QHRvb2xzLmlldGYub3JnPG1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0 dW4tY29uc2VudC1mcmVzaG5lc3MtMTMNCg0KDQpIaSwNCg0KU2VjdGlvbiAyMC4yLjMgb2YgUkZD IDUyNDUgc2F5czoNCg0K4oCcU1RVTiBrZWVwYWxpdmVzIChpbiB0aGUgZm9ybSBvZiBTVFVOIEJp bmRpbmcgSW5kaWNhdGlvbnMpIGFyZSBzZW50IGluDQogICAgICAgICAgICAgIHRoZSBtaWRkbGUg b2YgYSBtZWRpYSBzZXNzaW9uLiAgSG93ZXZlciwgdGhleSBhcmUgc2VudCBvbmx5IGluIHRoZQ0K ICAgICAgICAgICAgICBhYnNlbmNlIG9mIGFjdHVhbCBtZWRpYSB0cmFmZmljLuKAnQ0KDQpTbywg aW4gdGhlIGNvbnNlbnQgZHJhZnQgd2UgY291bGQgc2F5IHRoYXQsIGZyb20gYSBrZWVwYWxpdmUg cGVyc3BlY3RpdmUsIGNvbnNlbnQgcmVxdWVzdHMgYXJlIGNvbnNpZGVyZWQgbWVkaWEgdHJhZmZp Yy4gVGhhdCB3b3VsZCB0aGVuIGltcGxpY2l0bHkgbWVhbiB0aGF0IGFjdHVhbCBrZWVwYWxpdmVz IGFyZW7igJl0IHNlbnQgd2hlbiBjb25zZW50IGlzIHVzZWQuIFRoYXQgd2F5LCB0aGUgY29uc2Vu dCBzcGVjIHdvdWxkIGJlIGNvbXBsaWFudCB0byA1MjQ1LCBhbmQgdGhlcmUgd291bGQgYmUgbm8g bmVlZCBmb3IgYW55IHVwZGF0ZSBldGPigKYNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFRlZCBIYXJkaWUNClNlbnQ6IDI4IE1heSAyMDE1IDIzOjI2DQpUbzogQmxhY2ssIERhdmlkDQpD YzogcnRjd2ViLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86cnRjd2ViLWNoYWlyc0B0b29s cy5pZXRmLm9yZz47IGpvZWwgamFlZ2dsaTsgb3BzLWRpckBpZXRmLm9yZzxtYWlsdG86b3BzLWRp ckBpZXRmLm9yZz47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRjd2ViLXN0 dW4tY29uc2VudC1mcmVzaG5lc3MtMTMNCg0KSGkgRGF2aWQsDQoNCk9uIFRodSwgTWF5IDI4LCAy MDE1IGF0IDEyOjM2IFBNLCBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb208bWFpbHRv OmRhdmlkLmJsYWNrQGVtYy5jb20+Pg0KDQpJJ2QgZXhwZWN0IHRoYXQgZXZlbiBvdmVycmlkaW5n IFJGQyA1MjQ1IGNvdW50cyBhcyBhbiBVcGRhdGUsDQpiZWNhdXNlIHRoZSByZXN1bHQgd291bGQg YmUgdGhhdCB0aGUgb3JpZ2luYWwgUkZDIDUyNDUgIk1VU1QiIHJlcXVpcmVtZW50DQppcyBubyBs b25nZXIgZ2xvYmFsbHkgYXBwbGljYWJsZSB0byBhbGwgdXNlcyBvZiBSRkMgNTI0NS4gIEluIG90 aGVyIHdvcmRzLA0Kb3ZlcnJpZGluZyBSRkMgNTI0NSBlZmZlY3RpdmVseSByZXdyaXRlcyB0aGUg Ik1VU1QiIHRvIGJlY29tZSAiTVVTVCwgZXhjZXB0DQphcyBmdXJ0aGVyIHNwZWNpZmllZCBieSB0 aGUgY29uc2VudCBSRkMuIg0KDQrigItTbyBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBtdXN0 IGJlIGNhbGxlZCBvdXQsIGJ1dCBJIHRoaW5rICJVcGRhdGVzIiBpcyB3cm9uZyBmb3IgdGhlIGRy YWZ0J3MgY3VycmVudCBpbnRlbnQuICBJIHRoaW5rIHdoYXQgTWFydGluIGhhcyBzYWlkIGFtb3Vu dHMgdG8gIldlIGhhdmUgY2hvc2VuIHRvIGZvbGxvdyBSRkMgNTI0NSBleGNlcHQgYXMgZGV0YWls ZWQgaW4gc2VjdGlvbnMgWCBhbmQgWSwgd2hlcmUgd2UgdXNlIGEgZGlmZmVyZW50IHNldCBvZiBt ZXNzYWdlcyB0byBvcHRpbWl6ZSB0aGUgY29tYmluYXRpb24gb2YgaGVhcnRiZWF0IGFuZCBjb25z ZW50LiIgIFdlIGFyZSBub3QgdXBkYXRpbmcgUkZDIDUyNDUgdGhlcmVieSwgYmVjYXVzZSB3ZSBh cmUgbmVpdGhlciBjaGFuZ2luZyBpdHMgY29yZSBzZW1hbnRpY3Mgbm9yIG9mZmVyaW5nIHRvIGFk ZCBhIG5ldywgZ2VuZXJhbCBzZW1hbnRpYyB0byBSRkMgNTI0NSAod2UgY291bGQgaGF2ZSBtYWRl IHRoYXQgY2hvaWNlLCBidXQgYXJlIG5vdCBkb2luZyBzbyBub3cpLiAgSW5zdGVhZCBvZiB1cGRh dGluZyBSRkMgNTI0NSwgaW4gb3RoZXIgd29yZHMsIHdlIGFyZSBsaW1pdGluZyBvdXIgcmVmZXJl bmNlIHRvIGl0Lg0KVGhhdCBzaG91bGQgYmUgZG9uZSBleHBsaWNpdGx5LCBhbmQgSSB0aGluayBp dCBzaG91bGQgYmUgY2FsbGVkIGl0IHN1ZmZpaWNpZW50bHkgdGhhdCBhIG5ldyBzcGluIG9mIHRo ZSBkcmFmdCBsaWtlbHkgbmVlZHMgYSBuZXcgcm91bmQgb2YgcmV2aWV3LiAgQnV0IEkgZG9uJ3Qg dGhpbmsgd2UgYXJlIHJlcXVpcmVkIHRvIHVwZGF0ZSBSRkMgNTI0NSB0byBnZXQgdGhhdCBkb25l Lg0KSSd2ZSByZWZlcnJlZCB0aGUgbWF0dGVyIHRvIG91ciBmcmllbmRseSBBRCwgYW5kIHdlIGF3 YWl0IGhlciByZWFkaW5nIG9uIG5leHQgc3RlcHMgb24gdGhpcy4gIEluIGVpdGhlciBhcHByb2Fj aCwgaG93ZXZlciwgdGhpcyB3aWxsIGdldCBjYWxsZWQgb3V0Lg0KcmVnYXJkcywNClRlZCBIQXJk aWXigIsNCg0K --_000_CE03DB3D7B45C245BCA0D243277949364CB73DMX104CL02corpemcc_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h bDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+VGhhdCBhbHNvIHdvcmtzIGZvciBtZSwgYW5kIG5lYXRseSBzaWRlc3RlcHMgdGhl IGNvbmNlcm4gYWJvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+d2hldGhlciBSRkMgNTI0NSBpcyBiZWluZyB1cGRhdGVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MsPGJyPg0KLS1E YXZpZDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFttYWlsdG86dGly ZWRkeUBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAyOCwgMjAx NSAxMToyMCBQTTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc7IFRlZCBIYXJkaWU7 IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNjOjwvYj4gam9lbCBqYWVnZ2xpOyBvcHMtZGlyQGlldGYu b3JnOyBydGN3ZWJAaWV0Zi5vcmc7IHJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUkU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYt cnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2hyaXN0ZXIgSG9sbWJl cmcgWzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPm1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgTWF5IDI5LCAyMDE1IDc6MzcgQU08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSk7IFRlZCBIYXJkaWU7IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNjOjwv Yj4gam9lbCBqYWVnZ2xpOyA8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyI+b3BzLWRp ckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPg0KcnRjd2Vi QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5v cmciPnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNv bnNlbnQtZnJlc2huZXNzLTEzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ R29vZCBwb2ludC4gV2UgZGlzY3VzcyB0aGUgZm9sbG93aW5nIHBvaW50IGluIHNlY3Rpb24gNC4x IG9mIHRoZSBkcmFmdCBhYm91dCBrZWVwYWxpdmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZn dDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 IEFuIGVuZHBvaW50IHRoYXQgaXMgbm90IHNlbmRpbmcgYW55IGFwcGxpY2F0aW9uIGRhdGEgZG9l cyBub3QgbmVlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IG1haW50YWluIGNvbnNlbnQuJm5ic3A7IEhvd2V2 ZXIsIG5vdCBzZW5kaW5nIGFueSB0cmFmZmljIGNvdWxkIGNhdXNlIE5BVDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7Jm5ic3A7Jm5ic3A7 IG9yIGZpcmV3YWxsIG1hcHBpbmdzIHRvIGV4cGlyZS4mbmJzcDsgRnVydGhlcm1vcmUsIGhhdmlu ZyBvbmUgcGVlciB1bmFibGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jmd0OyZuYnNwOyZuYnNwOyB0byBzZW5kIGlzIGRldHJpbWVudGFsIHRv IG1hbnkgcHJvdG9jb2xzLiZuYnNwOyBBYnNlbnQgYmV0dGVyIGluZm9ybWF0aW9uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsm bmJzcDsgYWJvdXQgdGhlIG5ldHdvcmssIGlmIGFuIGVuZHBvaW50IG5lZWRzIHRvIGVuc3VyZSBp dHMgTkFUIG9yIGZpcmV3YWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgbWFwcGluZ3MgZG8gbm90IGV4cGlyZSwg aXQgY2FuIGJlIGRvbmUgdXNpbmcga2VlcGFsaXZlIG9yIG90aGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsmbmJzcDsmbmJzcDsgdGVj aG5pcXVlcyAoc2VlDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1 I3NlY3Rpb24tMTAiPlNlY3Rpb24mbmJzcDsxMCBvZiBbUkZDNTI0NV08L2E+IGFuZCBzZWUgWzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNjMiIHRpdGxlPSImcXVvdDtB cHBsaWNhdGlvbiBNZWNoYW5pc20gZm9yIEtlZXBpbmcgQWxpdmUgdGhlIE5BVCBNYXBwaW5ncyBB c3NvY2lhdGVkIHdpdGggUlRQIC8gUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIEZsb3dzJnF1 b3Q7Ij5SRkM2MjYzPC9hPl0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OzxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7DQo8c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+U28gdGhlcmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZXMg YmVjYXVzZSBvZiB0aGUgbWVkaWEgdHJhZmZpYyBhcyBpdCBpcyBwb2ludGVkIG91dCBpbg0KPC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNlY3Rpb24gMjAuMi4zIG9mIFJGQyA1MjQ1DQo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0Ow0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmlycmVzcGVjdGl2ZSBvZiB3aGV0 aGVyIGNvbnNlbnQgaXMgdXNlZCBvciBub3Q8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4uIEkgdGhpbmsgd2UgY2FuIHJlbW92ZSB0aGUgZm9s bG93aW5nIGxpbmUgaW4g4oCcSWYgY29uc2VudCBpcyBwZXJmb3JtZWQgdGhlbg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+dGhlcmUgaXMgbm8gbmVlZCB0byBzZW5kIGtlZXBhbGl2ZSBt ZXNzYWdlcy4mcXVvdDsgYW5kIGF2b2lkIHRoZSBjb25mdXNpb24gb2YgdXBkYXRpbmcgUkZDIDUy NDUuPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGFncmVl IHRoYXQgdGhlIGN1cnJlbnQgdGV4dCBjYW4gY29uZnVzZSBwZW9wbGUsIGJ1dCBJIHN0aWxsIHRo aW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBleHBsaWNpdCB0ZXh0IHNheWluZyB0aGF0IGtl ZXBhbGl2ZXMgYXJlIG5vdCBzZW50LiBQZXJoYXBzIHNvbWV0aGluZyBsaWtlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igJxGcm9tIGEga2VlcGFsaXZlIHBlcnNwZWN0 aXZlLCBjb25zZW50IHJlcXVlc3RzIGFyZSBjb25zaWRlcmVkIG1lZGlhIHRyYWZmaWMuIEJlY2F1 c2Ugb2YgdGhhdCwgZGVkaWNhdGVkIGtlZXBhbGl2ZXMgKGUuZy4gU1RVTiBiaW5kaW5nIHJlcXVl c3RzKSBhcmUgbm90IHNlbnQgb24gY2FuZGlkYXRlDQogcGFpcnMgd2hlcmUgY29uc2VudCByZXF1 ZXN0cyBhcmUgc2VudCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gMjAuMi4zIG9mIFtSRkM1 MjQ1XS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPldvcmtzIGZvciBtZSAoUmVwbGFjZWQNCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlNUVU4gYmluZGluZyByZXF1ZXN0cyB3aXRoIFNUVU4gQmlu ZGluZyBJbmRpY2F0aW9ucyBpbiB0aGUgYWJvdmUgbGluZSkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi1UaXJ1PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNo cmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDI5LCAyMDE1IDY6 NTQgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlZCBIYXJkaWU7IEJsYWNrLCBEYXZpZDxicj4NCjxiPkNj OjwvYj4gam9lbCBqYWVnZ2xpOyA8YSBocmVmPSJtYWlsdG86b3BzLWRpckBpZXRmLm9yZyI+b3Bz LWRpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPg0KcnRj d2ViQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmciPnJ0Y3dlYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbcnRjd2ViXSBPUFMtRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVu LWNvbnNlbnQtZnJlc2huZXNzLTEzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDIwLjIu MyBvZiBSRkMgNTI0NSBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcU1RVTiBrZWVwYWxpdmVzIChpbiB0aGUgZm9ybSBv ZiBTVFVOIEJpbmRpbmcgSW5kaWNhdGlvbnMpIGFyZSBzZW50IGluPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBtaWRkbGUgb2Yg YSBtZWRpYSBzZXNzaW9uLiZuYnNwOyBIb3dldmVyLA0KPGI+dGhleSBhcmUgc2VudCBvbmx5IGlu IHRoZTxvOnA+PC9vOnA+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYWJzZW5jZSBvZiBhY3R1YWwgbWVkaWEgdHJhZmZpYzwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4u 4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCBpbiB0aGUgY29uc2Vu dCBkcmFmdCB3ZSBjb3VsZCBzYXkgdGhhdCwgZnJvbSBhIGtlZXBhbGl2ZSBwZXJzcGVjdGl2ZSwg Y29uc2VudCByZXF1ZXN0cyBhcmUgY29uc2lkZXJlZCBtZWRpYSB0cmFmZmljLiBUaGF0IHdvdWxk IHRoZW4gaW1wbGljaXRseQ0KIG1lYW4gdGhhdCBhY3R1YWwga2VlcGFsaXZlcyBhcmVu4oCZdCBz ZW50IHdoZW4gY29uc2VudCBpcyB1c2VkLiBUaGF0IHdheSwgdGhlIGNvbnNlbnQgc3BlYyB3b3Vs ZCBiZSBjb21wbGlhbnQgdG8gNTI0NSwgYW5kIHRoZXJlIHdvdWxkIGJlIG5vIG5lZWQgZm9yIGFu eSB1cGRhdGUgZXRj4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbPGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UZWQgSGFyZGllPGJyPg0KPGI+U2Vu dDo8L2I+IDI4IE1heSAyMDE1IDIzOjI2PGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+ DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3Jn Ij5ydGN3ZWItY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgam9lbCBqYWVnZ2xpOw0KPGEgaHJl Zj0ibWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmciPm9wcy1kaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj4NCnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIE9QUy1EaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcnRj d2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MtMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5IaSBEYXZpZCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPk9uIFRodSwgTWF5IDI4LCAyMDE1IGF0IDEyOjM2IFBNLCBCbGFjaywgRGF2aWQgJmx0 OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2 aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQpJJ2QgZXhwZWN0IHRoYXQgZXZlbiBvdmVy cmlkaW5nIFJGQyA1MjQ1IGNvdW50cyBhcyBhbiBVcGRhdGUsPGJyPg0KYmVjYXVzZSB0aGUgcmVz dWx0IHdvdWxkIGJlIHRoYXQgdGhlIG9yaWdpbmFsIFJGQyA1MjQ1ICZxdW90O01VU1QmcXVvdDsg cmVxdWlyZW1lbnQ8YnI+DQppcyBubyBsb25nZXIgZ2xvYmFsbHkgYXBwbGljYWJsZSB0byBhbGwg dXNlcyBvZiBSRkMgNTI0NS4mbmJzcDsgSW4gb3RoZXIgd29yZHMsPGJyPg0Kb3ZlcnJpZGluZyBS RkMgNTI0NSBlZmZlY3RpdmVseSByZXdyaXRlcyB0aGUgJnF1b3Q7TVVTVCZxdW90OyB0byBiZWNv bWUgJnF1b3Q7TVVTVCwgZXhjZXB0PGJyPg0KYXMgZnVydGhlciBzcGVjaWZpZWQgYnkgdGhlIGNv bnNlbnQgUkZDLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi1NvIEkgYWdyZWUg d2l0aCB5b3UgdGhhdCB0aGlzIG11c3QgYmUgY2FsbGVkIG91dCwgYnV0IEkgdGhpbmsgJnF1b3Q7 VXBkYXRlcyZxdW90OyBpcyB3cm9uZyBmb3IgdGhlIGRyYWZ0J3MgY3VycmVudCBpbnRlbnQuJm5i c3A7IEkgdGhpbmsgd2hhdCBNYXJ0aW4gaGFzIHNhaWQgYW1vdW50cw0KIHRvICZxdW90O1dlIGhh dmUgY2hvc2VuIHRvIGZvbGxvdyBSRkMgNTI0NSBleGNlcHQgYXMgZGV0YWlsZWQgaW4gc2VjdGlv bnMgWCBhbmQgWSwgd2hlcmUgd2UgdXNlIGEgZGlmZmVyZW50IHNldCBvZiBtZXNzYWdlcyB0byBv cHRpbWl6ZSB0aGUgY29tYmluYXRpb24gb2YgaGVhcnRiZWF0IGFuZCBjb25zZW50LiZxdW90OyZu YnNwOyBXZSBhcmUgbm90IHVwZGF0aW5nIFJGQyA1MjQ1IHRoZXJlYnksIGJlY2F1c2Ugd2UgYXJl IG5laXRoZXIgY2hhbmdpbmcgaXRzIGNvcmUgc2VtYW50aWNzDQogbm9yIG9mZmVyaW5nIHRvIGFk ZCBhIG5ldywgZ2VuZXJhbCBzZW1hbnRpYyB0byBSRkMgNTI0NSAod2UgY291bGQgaGF2ZSBtYWRl IHRoYXQgY2hvaWNlLCBidXQgYXJlIG5vdCBkb2luZyBzbyBub3cpLiZuYnNwOyBJbnN0ZWFkIG9m IHVwZGF0aW5nIFJGQyA1MjQ1LCBpbiBvdGhlciB3b3Jkcywgd2UgYXJlIGxpbWl0aW5nIG91ciBy ZWZlcmVuY2UgdG8gaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5UaGF0IHNob3VsZCBiZSBkb25lIGV4cGxpY2l0bHksIGFuZCBJIHRoaW5r IGl0IHNob3VsZCBiZSBjYWxsZWQgaXQgc3VmZmlpY2llbnRseSB0aGF0IGEgbmV3IHNwaW4gb2Yg dGhlIGRyYWZ0IGxpa2VseSBuZWVkcyBhIG5ldyByb3VuZCBvZiByZXZpZXcuJm5ic3A7DQogQnV0 IEkgZG9uJ3QgdGhpbmsgd2UgYXJlIHJlcXVpcmVkIHRvIHVwZGF0ZSBSRkMgNTI0NSB0byBnZXQg dGhhdCBkb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+SSd2ZSByZWZlcnJlZCB0aGUgbWF0dGVyIHRvIG91ciBmcmllbmRseSBBRCwgYW5k IHdlIGF3YWl0IGhlciByZWFkaW5nIG9uIG5leHQgc3RlcHMgb24gdGhpcy4mbmJzcDsgSW4gZWl0 aGVyIGFwcHJvYWNoLCBob3dldmVyLCB0aGlzIHdpbGwgZ2V0IGNhbGxlZCBvdXQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5yZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRlZCBIQXJkaWXigIs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949364CB73DMX104CL02corpemcc_-- From nobody Fri May 29 11:25: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 9B40E1B2BF9; Fri, 29 May 2015 11:25:02 -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 cHipJI4hd0LN; Fri, 29 May 2015 11:25: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 0CEA41B2BFA; Fri, 29 May 2015 11:25:00 -0700 (PDT) Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4TIOuPl029974 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 May 2015 14:24:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t4TIOuPl029974 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1432923898; bh=H2tHZ+wmhPSBo5Rr7P1PI4UmK7M=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GIjbH2+8Qt4Fopb7iCZAeLpg19zx2wAs5ke37f2h+s3KD3Fvs7jfzogvhAtT6BI/0 MMwvjwrltmXf9sL+dQ2e3G3rM7te3n4ZC3rTRAmPpxnUE+YRDbcw/rX1peO2muxDF3 qCIPyJIFvAfJlEInTc98+E1EW6EyT1v2FbIdD4Bc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com t4TIOuPl029974 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd51.lss.emc.com (RSA Interceptor); Fri, 29 May 2015 14:24:10 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t4TIOhLJ021983 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 14:24:44 -0400 Received: from MXHUB202.corp.emc.com (10.253.68.28) by mxhub11.corp.emc.com (10.254.92.106) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 29 May 2015 14:24:43 -0400 Received: from MX104CL02.corp.emc.com ([169.254.8.77]) by MXHUB202.corp.emc.com ([10.253.68.28]) with mapi id 14.03.0224.002; Fri, 29 May 2015 14:24:43 -0400 From: "Black, David" To: "Ram Mohan R (rmohanr)" , "Tirumaleswar Reddy (tireddy)" , "joel jaeggli (joelja@bogus.com)" , "ops-dir@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmcKoj9rK05idUkWAIovS2YdbXZ2TQ1Yw Date: Fri, 29 May 2015 18:24:42 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A478607D3@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.13.35.216] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: Cc: "Black, David" 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: Fri, 29 May 2015 18:25:02 -0000 > Also the above statement indicates a need for a new API to notify the > application about the loss of ability and this is some thing outside the > scope of this document. At the moment, the new API is in scope, as it's discussed in section 7: 7. 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. If that section remains in the draft, I would be happy with adding one sentence to the end of that paragraph: That API hook could also include other reasons for loss of ability to send data, e.g., tripping of the circuit breaker mechanism discussed in section 7.1 of [I-D.ietf-rtcweb-rtp-usage]. Alternatively, Section 7 could be deleted - I could live with that, although I'd prefer that section 7 remain, as I'd expect readers to be interested in how an application learns that consent has expired. Thanks, --David > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Thursday, May 28, 2015 11:51 PM > To: Tirumaleswar Reddy (tireddy); Black, David; joel jaeggli > (joelja@bogus.com); ops-dir@ietf.org; rtcweb@ietf.org > Subject: Re: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent- > freshness-13 >=20 > See inline for one comment: >=20 > -----Original Message----- > From: "Tirumaleswar Reddy (tireddy)" > Date: Thursday, 28 May 2015 12:02 pm > To: "Black, David (david.black@emc.com)" , "joel > jaeggli (joelja@bogus.com)" , "ops-dir@ietf.org" > , "rtcweb@ietf.org" > Subject: Re: [rtcweb] OPS-Dir review > of draft-ietf-rtcweb-stun-consent-freshness-13 >=20 > >>Ok, but .. this is not about "how applications should handle" loss of > >>consent; > >>it's about "how implementations should report" loss of consent. Part o= f > >>this > >>is already in Section 7, which indicates how the application learns tha= t > >>consent has expired. It would suffice to add a sentence added to that > >>section to indicate that there are other reasons for loss of ability to > >>transmit > >>data, and include an example of how at least one other is reported to > >>applications. > > > >NEW: > >The circuit breaker algorithm discussed in section 7.1 of > >[I-D.ietf-rtcweb-rtp-usage] could be one of the reasons for ceasing > >transmission of media and to notify the application about the loss of > >ability to transmit data. >=20 > There may be multiple reasons for a webRTC endpoint to cease transmission > (one being circuit breaker) and I feel we should not add all those here i= n > consent draft. >=20 > Also the the above statement indicates a need for a new API to notify the > application about the loss of ability and this is some thing outside the > scope of this document. >=20 > IMO this text looks out of place and we should not add this to draft. >=20 > Regards, > Ram From nobody Fri May 29 13:37: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 11A411A886E; Fri, 29 May 2015 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yo9mzaNnvzYE; Fri, 29 May 2015 13:37:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 365E01A88A1; Fri, 29 May 2015 13:37:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529203722.31896.80860.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 13:37:22 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] RTCWEB WG Virtual Interim Meeting (RTCWeb WG JSEP-focused): June 18, 2015 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 20:37:37 -0000 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. From nobody Sat May 30 00:25: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 CEB2F1AC3F4 for ; Sat, 30 May 2015 00:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1NnmXcZGnr2i for ; Sat, 30 May 2015 00:25:52 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 912C61AC3F3 for ; Sat, 30 May 2015 00:25:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4C2977C061A for ; Sat, 30 May 2015 09:25: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 Mc8cfeSR_tyw for ; Sat, 30 May 2015 09:25:50 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:6528:fe3c:aadc:664b] (unknown [IPv6:2001:470:de0a:27:6528:fe3c:aadc:664b]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1E8B47C03EE for ; Sat, 30 May 2015 09:25:50 +0200 (CEST) Message-ID: <556965FD.1060001@alvestrand.no> Date: Sat, 30 May 2015 09:25:49 +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: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: 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: Sat, 30 May 2015 07:25:55 -0000 On 05/29/2015 08:24 PM, Black, David wrote: >> Also the above statement indicates a need for a new API to notify the >> application about the loss of ability and this is some thing outside the >> scope of this document. > At the moment, the new API is in scope, as it's discussed in section 7: > > 7. 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. > > If that section remains in the draft, I would be happy with adding one > sentence to the end of that paragraph: > > That API hook could also include other reasons for loss of ability > to send data, e.g., tripping of the circuit breaker mechanism > discussed in section 7.1 of [I-D.ietf-rtcweb-rtp-usage]. > > Alternatively, Section 7 could be deleted - I could live with that, > although I'd prefer that section 7 remain, as I'd expect readers to > be interested in how an application learns that consent has expired. 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."? From nobody Sat May 30 10:45: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 93CEA1A90D2 for ; Sat, 30 May 2015 10:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1fZ7us1URRI for ; Sat, 30 May 2015 10:44:59 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::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 602201A90D1 for ; Sat, 30 May 2015 10:44:59 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so15028607pdb.2 for ; Sat, 30 May 2015 10:44:59 -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=gs0261Vw5gxFeocXaUnngLeSx7j6W8ervSoxk+AIvY4=; b=gPT51067kTwNwt2njTbofDYYdKX2ExfO1gZ37idQj24JiQ9kRPFDsjfYQWF8pvfML+ mGq7CqHzP7TNZnqriQEK6EVZHTgGrNucbZjS0788pHDgzij5PgAr4Fmk97k1DDTkXw7u rHvYlJLHzhAbeWiPEGlNwf+K8CpMEOgfpdVYfkUMvhr6Vwe8ygZa9ogkDaL2O4S8RTl2 WcYSTFz3qTPL3ZAwWB+ds7X1LXViTn2n8kUf/AWHDTFYvW9G1F6roVR7K1ygtkYqF14u NGgwrjlliH/Xf6w+64wQWIF3fkiRy2va1ld1CAbp4Eus9CEjaa9R3Ew7qN6KVI9cj7Jj Do8A== X-Received: by 10.70.37.225 with SMTP id b1mr25659090pdk.35.1433007899113; Sat, 30 May 2015 10:44:59 -0700 (PDT) Received: from [192.168.1.107] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by mx.google.com with ESMTPSA id p5sm9313552pdi.2.2015.05.30.10.44.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 May 2015 10:44:57 -0700 (PDT) References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <556965FD.1060001@alvestrand.no> Mime-Version: 1.0 (1.0) In-Reply-To: <556965FD.1060001@alvestrand.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (12F69) From: Bernard Aboba Date: Sat, 30 May 2015 10:44:57 -0700 To: Harald Alvestrand 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: Sat, 30 May 2015 17:45:00 -0000 On May 30, 2015, at 00:25, Harald Alvestrand wrote: >=20 > I'd prefer to limit the number of documents that try to design APIs. >=20 > 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= .= From nobody Sun May 31 06: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 203551A1BB8 for ; Sun, 31 May 2015 06:38:17 -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 xkY7FpbD3vOU for ; Sun, 31 May 2015 06:38:15 -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 3A4381A1BB1 for ; Sun, 31 May 2015 06:38:15 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-65-556b0ec5f27c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C6.31.04401.5CE0B655; Sun, 31 May 2015 15:38:13 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Sun, 31 May 2015 15:38:12 +0200 From: Christer Holmberg To: Bernard Aboba , Harald Alvestrand Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQmcKuxYNeEsZ9K0CG03cvwAJmIp2TJGkAgADaPoCAAKz8gIABQITg Date: Sun, 31 May 2015 13:38:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D873AEB@ESESSMB209.ericsson.se> References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <556965FD.1060001@alvestrand.no> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvre5RvuxQg4nXRCw27PvPbHGsr4vN Yu2/dnYHZo8rE66weuycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGXPf32AuOMJRsXfRI9YG xs9sXYycHBICJhI3bq1ggrDFJC7cWw8U5+IQEjjKKHF1xh12kISQwGJGiZ1z1bsYOTjYBCwk uv9pg4RFBMIl3rc/YwGxmQXUJe4sPgdWLiwQKtH34QAbSLmIQJjE7YNmEOVuEvdfPwIrYRFQ lbj/dwIziM0r4Ctx58xrZoi1nUwSJw7vALuNU8BW4uW/u2BFjEC3fT+1hglil7jErSfzoW4W kFiy5zwzhC0q8fLxP1YIW0li0e3PUPU6Egt2f2KDsLUlli18DbVYUOLkzCcsExjFZiEZOwtJ yywkLbOQtCxgZFnFKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhRB7f8Vt3BePmN4yFGAQ5G JR5eheysUCHWxLLiytxDjNIcLErivJ5dIaFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGBlD cv70X20/FfBRYs/LY55Rx3dvssh/l363L2OZepD0k8LIb/80zqy6ZHpLf09J6Nuf4t+4hCc9 XP09kDtM+rT+GgWW/K9HnKe6mr5ZpvDTav/C8L0bp54+ynBDSOT8ukSV0v+Pt6eePzp1y7XU a6/+TXbZL8Os9sLLISuYaQVXu7R6xL4IHlElluKMREMt5qLiRAA9yMYhiQIAAA== 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: Sun, 31 May 2015 13:38:17 -0000 Hi, >> I'd prefer to limit the number of documents that try to design APIs. >>=20 >> 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 differ= ent from tripping=20 > 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 d= ocument instead? The consent freshness draft could then state that the mechanism/requirement= s how applications are made aware of consent expiration is outside the scop= e of the document. Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun May 31 23:01: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 64B7E1A88C7 for ; Sun, 31 May 2015 23:01:13 -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 K3s86hSCmqEU for ; Sun, 31 May 2015 23:01:11 -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 756781A88BE for ; Sun, 31 May 2015 23:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1775; q=dns/txt; s=iport; t=1433138472; x=1434348072; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QMo8BLFJCL9ACqXt6YYKxsrKZC+z+Ash4E3fvLe/2B4=; b=HCBCIsiq9U5mnFLDhsDjai1F5GWtTq1CKMIfRZ0Lpi3teafAjvvdyLAX 0TtEHbvFo5uFay6MpvlViIwZKBpv/MGczIs1DpsNTSQjm6eDCn7OWTBOg oNrjDLJN3IBDKtDQI3LtDDBRtgqni1iCn+iaeLm2RV+aN2grm1VdMKECc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0APBQB09GtV/4MNJK1cgxBUXgbAHwqFLUoCgSVMAQEBAQEBgQuEIgEBAQQBAQE3NAsMBAIBCBEDAQIfECEGCx0IAgQBDQWIGAMSDdARDYR2AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4JNgWFYBwaEJwEEkwqJOYFZkC6HBCNhgxdvgQRCgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,530,1427760000"; d="scan'208";a="16375139" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 01 Jun 2015 06:01:11 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5161Ad1019877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jun 2015 06:01:10 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.78]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 01:01:10 -0500 From: "Ram Mohan R (rmohanr)" To: Christer Holmberg , Bernard Aboba , Harald Alvestrand Thread-Topic: [rtcweb] OPS-Dir review of draft-ietf-rtcweb-stun-consent-freshness-13 Thread-Index: AQHQnDBb22/gwedzA02iXYPQWliciA== Date: Mon, 1 Jun 2015 06:01:09 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A478607D3@xmb-rcd-x10.cisco.com> <556965FD.1060001@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D873AEB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D873AEB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [173.39.66.102] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E53443F8D162643873555C838EEE5AF@emea.cisco.com> 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 06:01:13 -0000 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. 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. >>>=20 >>> 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