From nobody Thu Jan 1 19:37: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 E55221A871D for ; Thu, 1 Jan 2015 19:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.243 X-Spam-Level: * X-Spam-Status: No, score=1.243 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQMR3nSHmY6q for ; Thu, 1 Jan 2015 19:37:53 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id AA50B1A871C for ; Thu, 1 Jan 2015 19:37:53 -0800 (PST) Received: (qmail 9954 invoked by uid 0); 2 Jan 2015 03:37:50 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 2 Jan 2015 03:37:50 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw4 with id ardi1p0092Yhrsa01rdlc7; Thu, 01 Jan 2015 20:37:50 -0700 X-Authority-Analysis: v=2.1 cv=BvIOn+n5 c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=2mhjNb98rjwA:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=KWLd9SN1AAAA:8 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=YNv0rlydsVwA:10 a=N1z6yVdWAAAA:8 a=nDFo0psPcNGRlkRzjmEA:9 a=QEXdDO2ut3YA:10 a=f_NMCpFAY0sA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=JTd4xHRZWJrv56+RXWfuSKkB3vSiG95UXEzyVdDIrIw=; b=XAtyccAbSapvkBPd2Cwv2va1gSjA3wGEozmut7+QFwp99h+Vf0aeHb0Q9I4vkTNXMWEbrWZ+foENBT7LZwk9Hjrto1RXXEeqYG7L70IoPqQRh5cBmryoZomdOqFUNAiY; Received: from localhost ([127.0.0.1]:57476 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Y6t3W-0000JV-E2 for rtcweb@ietf.org; Thu, 01 Jan 2015 20:37:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 01 Jan 2015 20:37:40 -0700 From: Jackie Blanco To: rtcweb@ietf.org Message-ID: X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/0.9.5 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/lb7wWTzmlSaI_XWutFExMx4nIXw Subject: [rtcweb] Last CFP: EECEA2015: Second International Conference on Electrical, Electronics, Computer Engineering and their Applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 02 Jan 2015 03:37:56 -0000 The Second International Conference on Electrical, Electronics, Computer Engineering and their Applications (EECEA2015) World Trade Center, Manila Philippines February 11, 2015 University of Perpetual Help System Dalta Las Piñas - Manila, Philippines February 12-14, 2015 http://sdiwc.net/conferences/eecea2015/ All registered papers will be included in SDIWC Digital Library =============================================================== RESEARCH TOPICS ARE NOT LIMITED TO: * Electronics Engineering - 3D Semiconductor Device Technology - Advanced Electromagnetics - Component Technology of MEMS - Computer Engineering - Electronics System-Level Based Design - Electronics-Medical Electronics - Fiber Optics and Fiber Devices - Intelligent Transportation Systems - Medicine and Biology Applications - Mixed Signal Circuits - Mobile Robotics - Networks Design, Protocols and Management - Radio-Frequency Integrated Circuits - VLSI Testing and Design for Testability * Electrical Engineering - Software Specification - Analysis of Power Quality and System Stability - Analog Circuits and Digital Circuits - Battery Management System - Computer Relaying - Electromagnetic and Photonics - Integrated Optics and Electro-optics Devices - Microwave and millimeter circuit and Antenna - Power Electronics - Remote control and techniques of GPS - Robotics and Atomization Engineering - Signal Processing - Smart Grid - Techniques of Laser and Applications Of Electro-optics * Computer Engineering - Algorithms - Automated Software Engineering - Computer-aided Design - Computer Architecture - Computer Modeling - Computer Security - Database and Data Mining - Data Encryption - Digital Signal and Image Processing - Expert Systems - Information Systems - Mobile Computing - Multimedia Applications - Mobile Wireless Networks - Wireless Communication Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. IMPORTANT DATES: Submission Deadline: January 12, 2015 Notification of Acceptance: 2-3 weeks from the date of submission Camera Ready Submission: January 30, 2015 Registration Deadline: January 30, 2015 Seminar Date: February 11, 2015 Conference Dates: February 12-14, 2015 From nobody Fri Jan 2 11:04: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 7D82A1A1B15 for ; Wed, 24 Dec 2014 13:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 Ci88HpIevWsC for ; Wed, 24 Dec 2014 13:55:03 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 F05201A1B13 for ; Wed, 24 Dec 2014 13:55:02 -0800 (PST) Received: from [192.168.0.131] (unknown [71.179.209.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C445622E25F; Wed, 24 Dec 2014 16:54:54 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Mark Nottingham In-Reply-To: Date: Wed, 24 Dec 2014 16:54:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> <5491B831.70704@alvestrand.no> To: Dan Wing X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/Fr55GtViwTxN6p9J8vMdPgeCnvY X-Mailman-Approved-At: Fri, 02 Jan 2015 11:04:25 -0800 Cc: RTCWEB Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 21:55:05 -0000 I=E2=80=99d say that there=E2=80=99s some level of implementer interest = in standardising / documenting proxy.pac, but =E2=80=94 so far =E2=80=94 = inadequate resources; I don=E2=80=99t see *any* interest in WPAD = standardization, as it=E2=80=99s viewed as actively bad. Regards, > On 17 Dec 2014, at 4:58 pm, =F0=9F=94=93Dan Wing = wrote: >=20 > On Dec 17, 2014, at 9:06 AM, Harald Alvestrand = wrote: >=20 >> On 12/17/2014 05:19 PM, Hutton, Andrew wrote: >>> OP: 15 December 2014 22:44 Justin Uberti Wrote: >>>> I think making it a requirement is probably premature until we have = a >>>> WG document that explains what should happen when you discover one = of >>>> these network-provided TURN servers. >>>> Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is >>>> accepted as a WG doc, we can add a requirement for support for = RETURN >>>> and server discovery. >>>>=20 >>>> Unclear whether it needs to be MUST-strength until we get some >>>> implementation feedback though. >>>>=20 >>> -transports already states " WebRTC browsers MUST support = configuration of STUN and TURN servers, both from browser configuration = and from an application". >>>=20 >>> So it looks like we already have a requirement but no explanation of = what should happen when both are available. >>=20 >> The last times we've talked about this, people have imagined = configuring this via the same mechanism as configuring HTTP proxies = (nonstandard script at a nonstandard URL). >>=20 >> Autodiscovery may be preferable, but it's not clear that it removes = the need for the script-like things. >=20 > If there is, gathering that requirement seems important. Mark = Nottingham was beginning an effort around WPAD standardization (or = something that resembled it). CC'ing him in case there is useful status = on that front. >=20 > -d >=20 >=20 >>=20 >>>=20 >>> Looks like we need to adopt draft-schwartz-rtcweb-return and explain = this stuff. I would certainly support that and put some effort into = getting this done. >>>=20 >>> Andy >>> _______________________________________________ >>> 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 -- Mark Nottingham http://www.mnot.net/ From nobody Sun Jan 4 09:44: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 19FB41A8A0F; Sun, 4 Jan 2015 09:44:09 -0800 (PST) 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 v-O88BcZpNL6; Sun, 4 Jan 2015 09:44:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 534E41A8A0B; Sun, 4 Jan 2015 09:44:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150104174406.15226.22647.idtracker@ietfa.amsl.com> Date: Sun, 04 Jan 2015 09:44:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/wydJNKaCWJRBfinnsP-3QRCzsx4 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-09.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: Sun, 04 Jan 2015 17:44:09 -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 Data Channel Establishment Protocol Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-protocol-09.txt Pages : 13 Date : 2015-01-04 Abstract: The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies a simple protocol for establishing symmetric Data Channels between the peers. It uses a two way handshake and allows sending of user data without waiting for the handshake to complete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-protocol-09 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 Sun Jan 4 09:44:36 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9455B1A8A29; Sun, 4 Jan 2015 09:44:33 -0800 (PST) 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 yc8v4VW6PXyq; Sun, 4 Jan 2015 09:44:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 582C81A8A0F; Sun, 4 Jan 2015 09:44:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150104174422.8696.88153.idtracker@ietfa.amsl.com> Date: Sun, 04 Jan 2015 09:44:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gJ-IWsWpENXz4ZoyFm7UovwaGl0 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-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: Sun, 04 Jan 2015 17:44:33 -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 Data Channels Authors : Randell Jesup Salvatore Loreto Michael Tuexen Filename : draft-ietf-rtcweb-data-channel-13.txt Pages : 16 Date : 2015-01-04 Abstract: The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service allowing WEB-browsers to exchange generic data from peer to peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-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 Jan 7 20:15: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 0016D1A8852 for ; Wed, 7 Jan 2015 20:15:34 -0800 (PST) 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 UzMtkzy7IOnH for ; Wed, 7 Jan 2015 20:15:32 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461941A8843 for ; Wed, 7 Jan 2015 20:15:32 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id im6so406267vcb.11 for ; Wed, 07 Jan 2015 20:15:31 -0800 (PST) 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=H3nxo1JAwj2L+7Q74Qf10Zwc6dqkJOTgRla0UoNhbfE=; b=OQ84ePiLv2f5B5JvtD1fQW31FcX2tXj76HR7UTpYxtvgeoA/2uHaiHJK3xRima10+n ji6WGg0jCDlG/7IjKMSRNNqnJkIVNnmferHgGtyfNr56DbCRagINjoVzL25AEkXtYGcf ssyYViKYf8wclR6enLOZN71azwGFwE5bYVdpMhQJt3uUrwvJyNL38NnbX3UAEPOHk4t4 4AimKtIapbK+nsTrh6etSuzj0JeLmvnujE0etUHlIhhiKUqOFNwGjEdu64S/pkJLiaHG XDQOQ/1qrHiTfzmuWYHnDpfpZtYIqopEXt9r4KRXE8SbkW23ARRZuzoo/4ZiQWUbLPG3 Jiuw== 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=H3nxo1JAwj2L+7Q74Qf10Zwc6dqkJOTgRla0UoNhbfE=; b=UXtZ0UxlXXNMNngipFUUwDG7RlrsaLvSHNR6odv+022TDP8D8v1gqtXAKNgX0zdWPr K/CSRHZKVwlJ6YhohviEcKEL+lMBtr4GEnLTaz8fpDDdCRrTdpzOmTmFI+ZHQnkvhFbi R/Q/lj0Jr/G6zIqtUqVhtXhwcQKSCMquTkv0d7NrxoF8Jj5tEnP1F3i6GG0IPu6IMwfT Eo4qajIeIQu2bwta8cTKSNItJxZqn9C/oi9ymEnNLgoDvYxQmwToprqjMtcWV4ICmV9G yOP8Nv7CPPRN3UvNKnRcr0z1jnwqzRzHv0hdixEkpwVOn58HOU4lnvgAVEWKEFkn5N0Q hQoQ== X-Gm-Message-State: ALoCoQnmczfsh2E3/0NwE6XjcFC1j7yebfFUWY9fOyp5Blv3HRkwctvENSvHYzTHPB2Q84+mnWcO X-Received: by 10.220.250.198 with SMTP id mp6mr5521982vcb.19.1420690531424; Wed, 07 Jan 2015 20:15:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Wed, 7 Jan 2015 20:15:11 -0800 (PST) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> <5491B831.70704@alvestrand.no> From: Justin Uberti Date: Wed, 7 Jan 2015 20:15:11 -0800 Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=089e013cb9927640c9050c1c4ac0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/yNl6RGtw4RYDZQLvV52WITnhqpc Cc: RTCWEB Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2015 04:15:35 -0000 --089e013cb9927640c9050c1c4ac0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The actual requirement (as indicated in S 3.3.5.1 of https://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-15= #page-8) is for an enterprise to be able to force the use of a enterprise-controlled TURN server. Here, enterprise policy surely can allow for all traffic to be forced through said TURN server, just as it can be done for HTTP/HTTPS proxies today. I agree that the ISP TURN server case is different, and merits additional discussion. So while we can argue about exactly how autodiscovery should work (e.g. .pac or https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00), we should be able to agree on how things should work once a local TURN server is found (i.e. https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 ). This would allow the above scenario to be satisfied when the TURN proxy configuration is set through enterprise policy, and would be a substantial improvement over the current state of affairs (e.g. where many enterprises force all WebRTC traffic to TCP or through a HTTPS proxy) On Wed, Dec 24, 2014 at 1:54 PM, Mark Nottingham wrote: > I=E2=80=99d say that there=E2=80=99s some level of implementer interest i= n standardising / > documenting proxy.pac, but =E2=80=94 so far =E2=80=94 inadequate resource= s; I don=E2=80=99t see > *any* interest in WPAD standardization, as it=E2=80=99s viewed as activel= y bad. > > Regards, > > > > On 17 Dec 2014, at 4:58 pm, =F0=9F=94=93Dan Wing wrot= e: > > > > On Dec 17, 2014, at 9:06 AM, Harald Alvestrand > wrote: > > > >> On 12/17/2014 05:19 PM, Hutton, Andrew wrote: > >>> OP: 15 December 2014 22:44 Justin Uberti Wrote: > >>>> I think making it a requirement is probably premature until we have = a > >>>> WG document that explains what should happen when you discover one o= f > >>>> these network-provided TURN servers. > >>>> Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is > >>>> accepted as a WG doc, we can add a requirement for support for RETUR= N > >>>> and server discovery. > >>>> > >>>> Unclear whether it needs to be MUST-strength until we get some > >>>> implementation feedback though. > >>>> > >>> -transports already states " WebRTC browsers MUST support > configuration of STUN and TURN servers, both from browser configuration a= nd > from an application". > >>> > >>> So it looks like we already have a requirement but no explanation of > what should happen when both are available. > >> > >> The last times we've talked about this, people have imagined > configuring this via the same mechanism as configuring HTTP proxies > (nonstandard script at a nonstandard URL). > >> > >> Autodiscovery may be preferable, but it's not clear that it removes th= e > need for the script-like things. > > > > If there is, gathering that requirement seems important. Mark > Nottingham was beginning an effort around WPAD standardization (or > something that resembled it). CC'ing him in case there is useful status = on > that front. > > > > -d > > > > > >> > >>> > >>> Looks like we need to adopt draft-schwartz-rtcweb-return and explain > this stuff. I would certainly support that and put some effort into getti= ng > this done. > >>> > >>> Andy > >>> _______________________________________________ > >>> 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 > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e013cb9927640c9050c1c4ac0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The actual requirement (as indicated in S 3.3.5.1 of https://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-= requirements-15#page-8) is for an enterprise to be able to force the us= e of a enterprise-controlled TURN server. Here, enterprise policy surely ca= n allow for all traffic to be forced through said TURN server, just as it c= an be done for HTTP/HTTPS proxies today.

I agree that th= e ISP TURN server case is different, and merits additional discussion. So w= hile we can argue about exactly how autodiscovery should work (e.g. .pac or= =C2=A0https://tools.ietf.org/html/draft-ietf-tram-turn-server-discove= ry-00), we should be able to agree on how things should work once a loc= al TURN server is found (i.e.=C2=A0https://tools.ietf.org/html/draft-schwartz-= rtcweb-return-04).=C2=A0

This would allow the = above scenario to be satisfied when the TURN proxy configuration is set thr= ough enterprise policy, and would be a substantial improvement over the cur= rent state of affairs (e.g. where many enterprises force all WebRTC traffic= to TCP or through a HTTPS proxy)


On Wed, Dec 24, 2014 at 1:5= 4 PM, Mark Nottingham <mnot@mnot.net> wrote:
I=E2=80=99d say that there=E2=80=99s some level of implement= er interest in standardising / documenting proxy.pac, but =E2=80=94 so far = =E2=80=94 inadequate resources; I don=E2=80=99t see *any* interest in WPAD = standardization, as it=E2=80=99s viewed as actively bad.

Regards,


> On 17 Dec 2014, at 4:58 pm, =F0=9F=94=93Dan Wing <dwing@cisco.com> wrote:
>
> On Dec 17, 2014, at 9:06 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>
>> On 12/17/2014 05:19 PM, Hutton, Andrew wrote:
>>> OP: 15 December 2014 22:44 Justin Uberti Wrote:
>>>> I think making it a requirement is probably premature unti= l we have a
>>>> WG document that explains what should happen when you disc= over one of
>>>> these network-provided TURN servers.
>>>> Once https://tools.ietf.org/html/draft-schw= artz-rtcweb-return-04 is
>>>> accepted as a WG doc, we can add a requirement for support= for RETURN
>>>> and server discovery.
>>>>
>>>> Unclear whether it needs to be MUST-strength until we get = some
>>>> implementation feedback though.
>>>>
>>> -transports already states " WebRTC browsers MUST support= configuration of STUN and TURN servers, both from browser configuration an= d from an application".
>>>
>>> So it looks like we already have a requirement but no explanat= ion of what should happen when both are available.
>>
>> The last times we've talked about this, people have imagined c= onfiguring this via the same mechanism as configuring HTTP proxies (nonstan= dard script at a nonstandard URL).
>>
>> Autodiscovery may be preferable, but it's not clear that it re= moves the need for the script-like things.
>
> If there is, gathering that requirement seems important.=C2=A0 Mark No= ttingham was beginning an effort around WPAD standardization (or something = that resembled it).=C2=A0 CC'ing him in case there is useful status on = that front.
>
> -d
>
>
>>
>>>
>>> Looks like we need to adopt draft-schwartz-rtcweb-return and e= xplain this stuff. I would certainly support that and put some effort into = getting this done.
>>>
>>> Andy
>>> _______________________________________________
>>> 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
>

--
Mark Nottingham=C2=A0 =C2=A0http://www.mnot.net/



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

--089e013cb9927640c9050c1c4ac0-- From nobody Thu Jan 8 06:38: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 E40BD1A0366; Thu, 8 Jan 2015 06:38:13 -0800 (PST) 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 fZVARM7UyiU2; Thu, 8 Jan 2015 06:38:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9A31A1BEC; Thu, 8 Jan 2015 06:38:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108143802.25337.84205.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 06:38:02 -0800 Archived-At: Cc: rtcweb mailing list , rtcweb chair , RFC Editor Subject: [rtcweb] Protocol Action: 'WebRTC Data Channels' to Proposed Standard (draft-ietf-rtcweb-data-channel-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, 08 Jan 2015 14:38:14 -0000 The IESG has approved the following document: - 'WebRTC Data Channels' (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Richard Barnes and Alissa Cooper. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ Technical Summary: This document specifies the non­media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service. Working Group Summary: There was early discussion of the stacking order, but there has been no significant controversy since that was fixed. There have been a number of discussion on how to manage particular aspects of the larger context (e.g. WebRTC­level congestion control, since SCTP manages congestion control at the association level) and this has played a part in those, but not in any way that mde it the focus of controversy. Document Quality: There are implmentations of previous versions of this document, and we expect updates to them to the final version. Vendor support seems solid. This document did not require expert review of the types noted. Personnel: The document shepherd is Ted Hardie; the responsible Area Director is Richard Barnes. From nobody Thu Jan 8 06:39:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BDA1A7004; Thu, 8 Jan 2015 06:39:48 -0800 (PST) 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 6VXA1eSO333Z; Thu, 8 Jan 2015 06:39:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FFF1A8746; Thu, 8 Jan 2015 06:39:33 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108143933.26487.75577.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 06:39:33 -0800 Archived-At: Cc: rtcweb mailing list , rtcweb chair , RFC Editor Subject: [rtcweb] Protocol Action: 'WebRTC Data Channel Establishment Protocol' to Proposed Standard (draft-ietf-rtcweb-data-protocol-09.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, 08 Jan 2015 14:39:48 -0000 The IESG has approved the following document: - 'WebRTC Data Channel Establishment Protocol' (draft-ietf-rtcweb-data-protocol-09.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Richard Barnes and Alissa Cooper. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-protocol/ Technical Summary: This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service. Working Group Summary: There was early discussion of the stacking order, but there has been no significant controversy since that was fixed. There have been a number of discussion on how to manage particular aspects of the larger context (e.g. WebRTC-level congestion control, since SCTP manages congestion control at the association level) and this has played a part in those, but not in any way that mde it the focus of controversy. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?\ There are implmentations of previous versions of this document, and we expect updates to them to the final version. Vendor support seems solid. This document did not require expert review of the types noted. Personnel: The document shepherd is Ted Hardie; the responsible Area Director is Richard Barnes. From nobody Thu Jan 8 07:57: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 344791A8AA9 for ; Thu, 8 Jan 2015 07:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9c5vXaNuCUrx for ; Thu, 8 Jan 2015 07:57:04 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 91FBC1A8A9E for ; Thu, 8 Jan 2015 07:57:03 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id A7AA423F052A; Thu, 8 Jan 2015 16:57:02 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.138]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 16:57:02 +0100 From: "Hutton, Andrew" To: Justin Uberti , Mark Nottingham , RTCWEB Thread-Topic: [rtcweb] rtcweb-transports reference to TRAM discovery Thread-Index: AdAYdVah0SPsel0ORrys7Zw+IDeNbwAAFj2AAAAnpIAAAkCNAAAMNtUAAFkUwwAEOVIjMgAYQRMw Date: Thu, 8 Jan 2015 15:57:01 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E665417@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF1E63FB08@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E63FD67@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF1E643D2C@MCHP04MSX.global-ad.net> <5491B831.70704@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E665417MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2015 15:57:07 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF1E665417MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3ZSBzdXJlbHkgZG8gbmVlZCB0byBuZWVkIHRvIGNhdGVyIGZvciB0aGUgY2FzZSB3 aGVuIGEgbG9jYWwgVFVSTiBzZXJ2ZXIgaXMgZGlzY292ZXJlZCBvciBjb25maWd1cmVkIGJ5IHRo ZSB1c2VyL2FkbWluIGFuZCBzcGVjaWZ5IGhvdyB0aGUgV2ViUlRDIGJyb3dzZXIgYmVoYXZlcyBp biB0aGF0IHNjZW5hcmlvLiAgV2UgaGF2ZSBhbHdheXMgaGFkIHRoYXQgcmVxdWlyZW1lbnQgc3Bl Y2lmaWVkIGFzIEp1c3RpbiBwb2ludGVkIG91dC4NCg0KSSBzdXBwb3J0IG1vdmluZyBmb3J3YXJk IHdpdGggZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybiBhcyBpdCBjb3ZlcnMgdGhhdCB1c2Ug Y2FzZS4NCg0KVGhlIGFjdHVhbCBkaXNjb3ZlcnkgbWVjaGFuaXNtIGlzIEkgYXNzdW1lIHNvbWV0 aGluZyB0byBkaXNjdXNzIGluIFRSQU0uDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCkZyb206IHJ0 Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGlu IFViZXJ0aQ0KU2VudDogMDggSmFudWFyeSAyMDE1IDA0OjE1DQpUbzogTWFyayBOb3R0aW5naGFt DQpDYzogUlRDV0VCDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gcnRjd2ViLXRyYW5zcG9ydHMgcmVm ZXJlbmNlIHRvIFRSQU0gZGlzY292ZXJ5DQoNClRoZSBhY3R1YWwgcmVxdWlyZW1lbnQgKGFzIGlu ZGljYXRlZCBpbiBTIDMuMy41LjEgb2YgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE1I3BhZ2UtOCkgaXMgZm9y IGFuIGVudGVycHJpc2UgdG8gYmUgYWJsZSB0byBmb3JjZSB0aGUgdXNlIG9mIGEgZW50ZXJwcmlz ZS1jb250cm9sbGVkIFRVUk4gc2VydmVyLiBIZXJlLCBlbnRlcnByaXNlIHBvbGljeSBzdXJlbHkg Y2FuIGFsbG93IGZvciBhbGwgdHJhZmZpYyB0byBiZSBmb3JjZWQgdGhyb3VnaCBzYWlkIFRVUk4g c2VydmVyLCBqdXN0IGFzIGl0IGNhbiBiZSBkb25lIGZvciBIVFRQL0hUVFBTIHByb3hpZXMgdG9k YXkuDQoNCkkgYWdyZWUgdGhhdCB0aGUgSVNQIFRVUk4gc2VydmVyIGNhc2UgaXMgZGlmZmVyZW50 LCBhbmQgbWVyaXRzIGFkZGl0aW9uYWwgZGlzY3Vzc2lvbi4gU28gd2hpbGUgd2UgY2FuIGFyZ3Vl IGFib3V0IGV4YWN0bHkgaG93IGF1dG9kaXNjb3Zlcnkgc2hvdWxkIHdvcmsgKGUuZy4gLnBhYyBv ciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm4tc2VydmVy LWRpc2NvdmVyeS0wMCksIHdlIHNob3VsZCBiZSBhYmxlIHRvIGFncmVlIG9uIGhvdyB0aGluZ3Mg c2hvdWxkIHdvcmsgb25jZSBhIGxvY2FsIFRVUk4gc2VydmVyIGlzIGZvdW5kIChpLmUuIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTA0KS4N Cg0KVGhpcyB3b3VsZCBhbGxvdyB0aGUgYWJvdmUgc2NlbmFyaW8gdG8gYmUgc2F0aXNmaWVkIHdo ZW4gdGhlIFRVUk4gcHJveHkgY29uZmlndXJhdGlvbiBpcyBzZXQgdGhyb3VnaCBlbnRlcnByaXNl IHBvbGljeSwgYW5kIHdvdWxkIGJlIGEgc3Vic3RhbnRpYWwgaW1wcm92ZW1lbnQgb3ZlciB0aGUg Y3VycmVudCBzdGF0ZSBvZiBhZmZhaXJzIChlLmcuIHdoZXJlIG1hbnkgZW50ZXJwcmlzZXMgZm9y Y2UgYWxsIFdlYlJUQyB0cmFmZmljIHRvIFRDUCBvciB0aHJvdWdoIGEgSFRUUFMgcHJveHkpDQoN Cg0KT24gV2VkLCBEZWMgMjQsIDIwMTQgYXQgMTo1NCBQTSwgTWFyayBOb3R0aW5naGFtIDxtbm90 QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pj4gd3JvdGU6DQpJ4oCZZCBzYXkgdGhhdCB0 aGVyZeKAmXMgc29tZSBsZXZlbCBvZiBpbXBsZW1lbnRlciBpbnRlcmVzdCBpbiBzdGFuZGFyZGlz aW5nIC8gZG9jdW1lbnRpbmcgcHJveHkucGFjLCBidXQg4oCUIHNvIGZhciDigJQgaW5hZGVxdWF0 ZSByZXNvdXJjZXM7IEkgZG9u4oCZdCBzZWUgKmFueSogaW50ZXJlc3QgaW4gV1BBRCBzdGFuZGFy ZGl6YXRpb24sIGFzIGl04oCZcyB2aWV3ZWQgYXMgYWN0aXZlbHkgYmFkLg0KDQpSZWdhcmRzLA0K DQoNCj4gT24gMTcgRGVjIDIwMTQsIGF0IDQ6NTggcG0sIPCflJNEYW4gV2luZyA8ZHdpbmdAY2lz Y28uY29tPG1haWx0bzpkd2luZ0BjaXNjby5jb20+PiB3cm90ZToNCj4NCj4gT24gRGVjIDE3LCAy MDE0LCBhdCA5OjA2IEFNLCBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm88 bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj4gd3JvdGU6DQo+DQo+PiBPbiAxMi8xNy8yMDE0 IDA1OjE5IFBNLCBIdXR0b24sIEFuZHJldyB3cm90ZToNCj4+PiBPUDogMTUgRGVjZW1iZXIgMjAx NCAyMjo0NCBKdXN0aW4gVWJlcnRpIFdyb3RlOg0KPj4+PiBJIHRoaW5rIG1ha2luZyBpdCBhIHJl cXVpcmVtZW50IGlzIHByb2JhYmx5IHByZW1hdHVyZSB1bnRpbCB3ZSBoYXZlIGENCj4+Pj4gV0cg ZG9jdW1lbnQgdGhhdCBleHBsYWlucyB3aGF0IHNob3VsZCBoYXBwZW4gd2hlbiB5b3UgZGlzY292 ZXIgb25lIG9mDQo+Pj4+IHRoZXNlIG5ldHdvcmstcHJvdmlkZWQgVFVSTiBzZXJ2ZXJzLg0KPj4+ PiBPbmNlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWIt cmV0dXJuLTA0IGlzDQo+Pj4+IGFjY2VwdGVkIGFzIGEgV0cgZG9jLCB3ZSBjYW4gYWRkIGEgcmVx dWlyZW1lbnQgZm9yIHN1cHBvcnQgZm9yIFJFVFVSTg0KPj4+PiBhbmQgc2VydmVyIGRpc2NvdmVy eS4NCj4+Pj4NCj4+Pj4gVW5jbGVhciB3aGV0aGVyIGl0IG5lZWRzIHRvIGJlIE1VU1Qtc3RyZW5n dGggdW50aWwgd2UgZ2V0IHNvbWUNCj4+Pj4gaW1wbGVtZW50YXRpb24gZmVlZGJhY2sgdGhvdWdo Lg0KPj4+Pg0KPj4+IC10cmFuc3BvcnRzIGFscmVhZHkgc3RhdGVzICIgV2ViUlRDIGJyb3dzZXJz IE1VU1Qgc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIFNUVU4gYW5kIFRVUk4gc2VydmVycywgYm90 aCBmcm9tIGJyb3dzZXIgY29uZmlndXJhdGlvbiBhbmQgZnJvbSBhbiBhcHBsaWNhdGlvbiIuDQo+ Pj4NCj4+PiBTbyBpdCBsb29rcyBsaWtlIHdlIGFscmVhZHkgaGF2ZSBhIHJlcXVpcmVtZW50IGJ1 dCBubyBleHBsYW5hdGlvbiBvZiB3aGF0IHNob3VsZCBoYXBwZW4gd2hlbiBib3RoIGFyZSBhdmFp bGFibGUuDQo+Pg0KPj4gVGhlIGxhc3QgdGltZXMgd2UndmUgdGFsa2VkIGFib3V0IHRoaXMsIHBl b3BsZSBoYXZlIGltYWdpbmVkIGNvbmZpZ3VyaW5nIHRoaXMgdmlhIHRoZSBzYW1lIG1lY2hhbmlz bSBhcyBjb25maWd1cmluZyBIVFRQIHByb3hpZXMgKG5vbnN0YW5kYXJkIHNjcmlwdCBhdCBhIG5v bnN0YW5kYXJkIFVSTCkuDQo+Pg0KPj4gQXV0b2Rpc2NvdmVyeSBtYXkgYmUgcHJlZmVyYWJsZSwg YnV0IGl0J3Mgbm90IGNsZWFyIHRoYXQgaXQgcmVtb3ZlcyB0aGUgbmVlZCBmb3IgdGhlIHNjcmlw dC1saWtlIHRoaW5ncy4NCj4NCj4gSWYgdGhlcmUgaXMsIGdhdGhlcmluZyB0aGF0IHJlcXVpcmVt ZW50IHNlZW1zIGltcG9ydGFudC4gIE1hcmsgTm90dGluZ2hhbSB3YXMgYmVnaW5uaW5nIGFuIGVm Zm9ydCBhcm91bmQgV1BBRCBzdGFuZGFyZGl6YXRpb24gKG9yIHNvbWV0aGluZyB0aGF0IHJlc2Vt YmxlZCBpdCkuICBDQydpbmcgaGltIGluIGNhc2UgdGhlcmUgaXMgdXNlZnVsIHN0YXR1cyBvbiB0 aGF0IGZyb250Lg0KPg0KPiAtZA0KPg0KPg0KPj4NCj4+Pg0KPj4+IExvb2tzIGxpa2Ugd2UgbmVl ZCB0byBhZG9wdCBkcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuIGFuZCBleHBsYWluIHRoaXMg c3R1ZmYuIEkgd291bGQgY2VydGFpbmx5IHN1cHBvcnQgdGhhdCBhbmQgcHV0IHNvbWUgZWZmb3J0 IGludG8gZ2V0dGluZyB0aGlzIGRvbmUuDQo+Pj4NCj4+PiBBbmR5DQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBydGN3ZWIgbWFpbGluZyBs aXN0DQo+Pj4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4+DQo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcnRjd2ViIG1haWxp bmcgbGlzdA0KPj4gcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPg0KLS0NCk1hcmsg Tm90dGluZ2hhbSAgIGh0dHA6Ly93d3cubW5vdC5uZXQvDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRj d2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF1E665417MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3ZSBzdXJlbHkgZG8gbmVlZCB0 byBuZWVkIHRvIGNhdGVyIGZvciB0aGUgY2FzZSB3aGVuIGEgbG9jYWwgVFVSTiBzZXJ2ZXIgaXMg ZGlzY292ZXJlZCBvciBjb25maWd1cmVkIGJ5IHRoZSB1c2VyL2FkbWluIGFuZCBzcGVjaWZ5IGhv dyB0aGUgV2ViUlRDIGJyb3dzZXINCiBiZWhhdmVzIGluIHRoYXQgc2NlbmFyaW8uICZuYnNwO1dl IGhhdmUgYWx3YXlzIGhhZCB0aGF0IHJlcXVpcmVtZW50IHNwZWNpZmllZCBhcyBKdXN0aW4gcG9p bnRlZCBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIHN1cHBvcnQgbW92aW5nIGZvcndhcmQgd2l0aCBkcmFmdC1z Y2h3YXJ0ei1ydGN3ZWItcmV0dXJuIGFzIGl0IGNvdmVycyB0aGF0IHVzZSBjYXNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhlIGFjdHVhbCBkaXNjb3ZlcnkgbWVjaGFuaXNtIGlzIEkgYXNzdW1lIHNvbWV0aGluZyB0 byBkaXNjdXNzIGluIFRSQU0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiAw OCBKYW51YXJ5IDIwMTUgMDQ6MTU8YnI+DQo8Yj5Ubzo8L2I+IE1hcmsgTm90dGluZ2hhbTxicj4N CjxiPkNjOjwvYj4gUlRDV0VCPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBydGN3 ZWItdHJhbnNwb3J0cyByZWZlcmVuY2UgdG8gVFJBTSBkaXNjb3Zlcnk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFjdHVhbCByZXF1aXJl bWVudCAoYXMgaW5kaWNhdGVkIGluIFMgMy4zLjUuMSBvZiA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVu dHMtMTUjcGFnZS04Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNSNwYWdlLTg8L2E+KSBpcyBmb3IgYW4g ZW50ZXJwcmlzZSB0byBiZSBhYmxlIHRvIGZvcmNlIHRoZSB1c2Ugb2YgYSBlbnRlcnByaXNlLWNv bnRyb2xsZWQgVFVSTiBzZXJ2ZXIuIEhlcmUsIGVudGVycHJpc2UgcG9saWN5IHN1cmVseSBjYW4g YWxsb3cgZm9yIGFsbCB0cmFmZmljIHRvIGJlIGZvcmNlZCB0aHJvdWdoIHNhaWQNCiBUVVJOIHNl cnZlciwganVzdCBhcyBpdCBjYW4gYmUgZG9uZSBmb3IgSFRUUC9IVFRQUyBwcm94aWVzIHRvZGF5 LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0 aGF0IHRoZSBJU1AgVFVSTiBzZXJ2ZXIgY2FzZSBpcyBkaWZmZXJlbnQsIGFuZCBtZXJpdHMgYWRk aXRpb25hbCBkaXNjdXNzaW9uLiBTbyB3aGlsZSB3ZSBjYW4gYXJndWUgYWJvdXQgZXhhY3RseSBo b3cgYXV0b2Rpc2NvdmVyeSBzaG91bGQgd29yayAoZS5nLiAucGFjIG9yJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuLXNlcnZlci1k aXNjb3ZlcnktMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t dHVybi1zZXJ2ZXItZGlzY292ZXJ5LTAwPC9hPiksDQogd2Ugc2hvdWxkIGJlIGFibGUgdG8gYWdy ZWUgb24gaG93IHRoaW5ncyBzaG91bGQgd29yayBvbmNlIGEgbG9jYWwgVFVSTiBzZXJ2ZXIgaXMg Zm91bmQgKGkuZS4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0wNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4tMDQ8L2E+KS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3b3VsZCBhbGxv dyB0aGUgYWJvdmUgc2NlbmFyaW8gdG8gYmUgc2F0aXNmaWVkIHdoZW4gdGhlIFRVUk4gcHJveHkg Y29uZmlndXJhdGlvbiBpcyBzZXQgdGhyb3VnaCBlbnRlcnByaXNlIHBvbGljeSwgYW5kIHdvdWxk IGJlIGEgc3Vic3RhbnRpYWwgaW1wcm92ZW1lbnQgb3ZlciB0aGUgY3VycmVudCBzdGF0ZSBvZiBh ZmZhaXJzIChlLmcuIHdoZXJlIG1hbnkgZW50ZXJwcmlzZXMgZm9yY2UgYWxsIFdlYlJUQw0KIHRy YWZmaWMgdG8gVENQIG9yIHRocm91Z2ggYSBIVFRQUyBwcm94eSk8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyAyNCwgMjAx NCBhdCAxOjU0IFBNLCBNYXJrIE5vdHRpbmdoYW0gJmx0OzxhIGhyZWY9Im1haWx0bzptbm90QG1u b3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+bW5vdEBtbm90Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgc2F5IHRoYXQgdGhlcmXigJlz IHNvbWUgbGV2ZWwgb2YgaW1wbGVtZW50ZXIgaW50ZXJlc3QgaW4gc3RhbmRhcmRpc2luZyAvIGRv Y3VtZW50aW5nIHByb3h5LnBhYywgYnV0IOKAlCBzbyBmYXIg4oCUIGluYWRlcXVhdGUgcmVzb3Vy Y2VzOyBJIGRvbuKAmXQgc2VlICphbnkqIGludGVyZXN0IGluIFdQQUQgc3RhbmRhcmRpemF0aW9u LCBhcyBpdOKAmXMgdmlld2VkIGFzIGFjdGl2ZWx5IGJhZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCiZndDsgT24gMTcgRGVjIDIwMTQsIGF0 IDQ6NTggcG0sIPCflJNEYW4gV2luZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2NvLmNv bSI+ZHdpbmdAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24g RGVjIDE3LCAyMDE0LCBhdCA5OjA2IEFNLCBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vIj5oYXJhbGRAYWx2ZXN0cmFuZC5ubzwvYT4mZ3Q7 IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBPbiAxMi8xNy8yMDE0IDA1OjE5IFBNLCBI dXR0b24sIEFuZHJldyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgT1A6IDE1IERlY2VtYmVyIDIw MTQgMjI6NDQgSnVzdGluIFViZXJ0aSBXcm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhp bmsgbWFraW5nIGl0IGEgcmVxdWlyZW1lbnQgaXMgcHJvYmFibHkgcHJlbWF0dXJlIHVudGlsIHdl IGhhdmUgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgV0cgZG9jdW1lbnQgdGhhdCBleHBsYWlucyB3 aGF0IHNob3VsZCBoYXBwZW4gd2hlbiB5b3UgZGlzY292ZXIgb25lIG9mPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyB0aGVzZSBuZXR3b3JrLXByb3ZpZGVkIFRVUk4gc2VydmVycy48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IE9uY2UgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4tMDQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTA0PC9hPiBpczxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgYWNjZXB0ZWQgYXMgYSBXRyBkb2MsIHdlIGNhbiBhZGQgYSBy ZXF1aXJlbWVudCBmb3Igc3VwcG9ydCBmb3IgUkVUVVJOPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBh bmQgc2VydmVyIGRpc2NvdmVyeS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyBVbmNsZWFyIHdoZXRoZXIgaXQgbmVlZHMgdG8gYmUgTVVTVC1zdHJlbmd0aCB1bnRp bCB3ZSBnZXQgc29tZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaW1wbGVtZW50YXRpb24gZmVlZGJh Y2sgdGhvdWdoLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgLXRyYW5z cG9ydHMgYWxyZWFkeSBzdGF0ZXMgJnF1b3Q7IFdlYlJUQyBicm93c2VycyBNVVNUIHN1cHBvcnQg Y29uZmlndXJhdGlvbiBvZiBTVFVOIGFuZCBUVVJOIHNlcnZlcnMsIGJvdGggZnJvbSBicm93c2Vy IGNvbmZpZ3VyYXRpb24gYW5kIGZyb20gYW4gYXBwbGljYXRpb24mcXVvdDsuPGJyPg0KJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFNvIGl0IGxvb2tzIGxpa2Ugd2UgYWxyZWFkeSBoYXZl IGEgcmVxdWlyZW1lbnQgYnV0IG5vIGV4cGxhbmF0aW9uIG9mIHdoYXQgc2hvdWxkIGhhcHBlbiB3 aGVuIGJvdGggYXJlIGF2YWlsYWJsZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBs YXN0IHRpbWVzIHdlJ3ZlIHRhbGtlZCBhYm91dCB0aGlzLCBwZW9wbGUgaGF2ZSBpbWFnaW5lZCBj b25maWd1cmluZyB0aGlzIHZpYSB0aGUgc2FtZSBtZWNoYW5pc20gYXMgY29uZmlndXJpbmcgSFRU UCBwcm94aWVzIChub25zdGFuZGFyZCBzY3JpcHQgYXQgYSBub25zdGFuZGFyZCBVUkwpLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQXV0b2Rpc2NvdmVyeSBtYXkgYmUgcHJlZmVyYWJsZSwg YnV0IGl0J3Mgbm90IGNsZWFyIHRoYXQgaXQgcmVtb3ZlcyB0aGUgbmVlZCBmb3IgdGhlIHNjcmlw dC1saWtlIHRoaW5ncy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiB0aGVyZSBpcywgZ2F0aGVyaW5n IHRoYXQgcmVxdWlyZW1lbnQgc2VlbXMgaW1wb3J0YW50LiZuYnNwOyBNYXJrIE5vdHRpbmdoYW0g d2FzIGJlZ2lubmluZyBhbiBlZmZvcnQgYXJvdW5kIFdQQUQgc3RhbmRhcmRpemF0aW9uIChvciBz b21ldGhpbmcgdGhhdCByZXNlbWJsZWQgaXQpLiZuYnNwOyBDQydpbmcgaGltIGluIGNhc2UgdGhl cmUgaXMgdXNlZnVsIHN0YXR1cyBvbiB0aGF0IGZyb250Ljxicj4NCiZndDs8YnI+DQomZ3Q7IC1k PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBMb29rcyBsaWtlIHdlIG5lZWQgdG8gYWRvcHQgZHJhZnQtc2Nod2FydHot cnRjd2ViLXJldHVybiBhbmQgZXhwbGFpbiB0aGlzIHN0dWZmLiBJIHdvdWxkIGNlcnRhaW5seSBz dXBwb3J0IHRoYXQgYW5kIHB1dCBzb21lIGVmZm9ydCBpbnRvIGdldHRpbmcgdGhpcyBkb25lLjxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBBbmR5PGJyPg0KJmd0OyZndDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyZndDsmZ3Q7IHJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0i bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7 Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl YiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnRjd2ViPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRj d2ViQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PGJyPg0KJmd0OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPGJyPg0KTWFyayBO b3R0aW5naGFtJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cubW5vdC5uZXQvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5tbm90Lm5ldC88L2E+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF1E665417MCHP04MSXglobal_-- From nobody Thu Jan 8 10: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 8223D1A8F41 for ; Thu, 8 Jan 2015 10:54:14 -0800 (PST) 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 lu5FZYQeFcDb for ; Thu, 8 Jan 2015 10:54:12 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2941A8F40 for ; Thu, 8 Jan 2015 10:54:12 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tr6so11077822ieb.3 for ; Thu, 08 Jan 2015 10:54:11 -0800 (PST) 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=/azIYrooL5TM8JFnfnZN0tROxZOcdUWca7sfvF7drMU=; b=EmwGpqAC52S4iejE+xmOnGTjOeevwFDUDOcaHNTdb6lLRMQXfOz0YNsVid8/0iNxj7 9OslJYxD4s2o+mOWMDp3UPYC1WxgPNDc69bi+2jpE2bhbFzGDdI4cwC+mtfkwjQ5JU6W lMrNDFPQR7onzoVoAFbwC/yvsvs7jUakTCRFZTNkbk7TeE0Bk0gkumRGwwuhlbjG7cVM OgkM+xLh09Yqvu3/d1cmGXMsva2gpeZSLBW9SZoVYryq+rgBdihZJpfHdlXnxk5r6K+q npO+W66fyOtWSRB4a5rd1k/Eqgp6NZ8XqrvYYHrY/odvtv4yPY9J2k3wRG4Xf+TyPs6+ 6IRQ== MIME-Version: 1.0 X-Received: by 10.42.194.17 with SMTP id dw17mr9595760icb.4.1420743251297; Thu, 08 Jan 2015 10:54:11 -0800 (PST) Received: by 10.42.107.145 with HTTP; Thu, 8 Jan 2015 10:54:11 -0800 (PST) Date: Thu, 8 Jan 2015 10:54:11 -0800 Message-ID: From: Ted Hardie To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=20cf30434a7ccf8d80050c2890c2 Archived-At: Subject: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2015 18:54:14 -0000 --20cf30434a7ccf8d80050c2890c2 Content-Type: text/plain; charset=UTF-8 Howdy, During the Honolulu meeting, the chairs agreed to ask for some on-list discussion of this draft prior to discussing adoption. During the holidays we dropped the ball on that, for which our apologies. At this point, though, we'd like to see some discussion of the draft--in particular on its scope and how it fits into the landscape of work we need to complete thanks, Ted, Cullen, Sean --20cf30434a7ccf8d80050c2890c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

During the Honolulu meeting, the c= hairs agreed to ask for some on-list discussion of this draft prior to disc= ussing adoption.=C2=A0 During the holidays we dropped the ball on that, for= which our apologies.=C2=A0=C2=A0 At this point, though, we'd like to s= ee some discussion of the draft--in particular on its scope and how it fits= into the landscape of work we need to complete
thanks,<= br>
Ted, Cullen, Sean
--20cf30434a7ccf8d80050c2890c2-- From nobody Thu Jan 8 10:57: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 00A981A00DF for ; Thu, 8 Jan 2015 10:57:27 -0800 (PST) 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 1nsjYr4yBi3L for ; Thu, 8 Jan 2015 10:57:25 -0800 (PST) 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 7CD2D1A8AD9 for ; Thu, 8 Jan 2015 10:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=319; q=dns/txt; s=iport; t=1420743444; x=1421953044; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uVQI/z53/18yWlk8h6AFsAtMfjtlP5znwARGy1Ul1PQ=; b=M2nwke8gS1wZnR5p5rMu2aMsigdEWgEPyI63kVk4ZzxNUNlIN4Mxrdq+ a+uJbUzCHLX/6ADZyhEbDfBTFsllnlHYAjT3NW467LZl1kiwWxdVhqhm0 lDXF+6RskY3hiJlcEYOGo/HSLwFG31Zg4j8lwALOkJi4Je7iUOsXfu1xf I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJPSrlStJV2c/2dsb2JhbABcgmQigS7LboETQwEBAQEBfYQTHR0/EgE+QicEDogxAccEAQEBAQEBAQEBAQEBAQEBAQEBAQEBF495gx2BEwWOM4kHgQ6CcY1vIoNugjR+AQEB X-IronPort-AV: E=Sophos;i="5.07,724,1413244800"; d="scan'208";a="385387053" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jan 2015 18:57:24 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t08IvNla026735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 18:57:23 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 12:57:23 -0600 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: Call for WG adoption of draft-uberti-rtcweb-fec Thread-Index: AQHQK3TvhHXhWMN7lEuck5ilPB1TkA== Date: Thu, 8 Jan 2015 18:57:22 +0000 Message-ID: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <3EC3614DF3309547B9DE60446ECCF3E5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Ted Hardie Subject: [rtcweb] Call for WG adoption of draft-uberti-rtcweb-fec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2015 18:57:27 -0000 At the last meeting there was strong support for adopting draft-uberti-rtcw= eb-fec as a WG draft. Unless we hear significant objections to this, the ch= airs plan to more forward with adopting this. If you have objection to this= , please reply to this thread before Jan 15. Thanks,=20 Cullen, Sean, & Ted From nobody Thu Jan 8 11:05: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 09E391A9009 for ; Thu, 8 Jan 2015 11:05:45 -0800 (PST) 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 oHHL5Vi4dtGg for ; Thu, 8 Jan 2015 11:05:42 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B5D1A8FD3 for ; Thu, 8 Jan 2015 11:05:42 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so5275052wiv.5 for ; Thu, 08 Jan 2015 11:05:41 -0800 (PST) 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=80H6fJBxeQWpQtIv9O3vVH6ufH/IIZH+rACt854C+rI=; b=Er+gA+pORDsohCFhsNJQga577OLtx9lJSTNs2lx0pSsbDUJzlehFLcOXig+kH743dA fLxRHOeUc0+rgd0w+82BeKU3ybmLWlcvuOymRfqeDHqDKxwL/yqk4rwRBH2qWVukUPb+ 4JyQu6RbFndk2cb48urdU9deSMUeUp3kBnb+eAy2IEyjKh15ZpLKQsxqe0uL4nOnsKot C1RV4eR3z1WNxmyRiG/Zjakaj6IS+kajSSQkcqHLNd+gdgg83EZvGeSbo0ko6NhpYzC8 SOOycDWNQU5gsmWdnUHL/J81jqn3ul+Mr2IXjPyhAvVn3toPbZd4ZwTqaXDmcgGmujZY wxuw== X-Received: by 10.180.83.129 with SMTP id q1mr22685234wiy.8.1420743941171; Thu, 08 Jan 2015 11:05:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.65 with HTTP; Thu, 8 Jan 2015 11:05:20 -0800 (PST) In-Reply-To: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> References: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> From: Bernard Aboba Date: Thu, 8 Jan 2015 11:05:20 -0800 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=14dae9cc928cee30a9050c28b907 Archived-At: Cc: Ted Hardie , "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for WG adoption of draft-uberti-rtcweb-fec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2015 19:05:45 -0000 --14dae9cc928cee30a9050c28b907 Content-Type: text/plain; charset=UTF-8 This draft is now referenced normatively in draft-ietf-rtcweb-rtp-usage Section 6.2, so it is needed and we might as well get on with it. 6.2 . Forward Error Correction (FEC) The use of Forward Error Correction (FEC) can provide an effective protection against some degree of packet loss, at the cost of steady bandwidth overhead. There are several FEC schemes that are defined for use with RTP. Some of these schemes are specific to a particular RTP payload format, others operate across RTP packets and can be used with any payload format. It needs to be noted that using redundant encoding or FEC will lead to increased play out delay, which needs to be considered when choosing FEC schemes and their parameters. WebRTC endpoints MUST follow the recommendations for FEC use given in [I-D.uberti-rtcweb-fec ]. WebRTC endpoints MAY support other types of FEC, but these MUST be negotiated before they are used. On Thu, Jan 8, 2015 at 10:57 AM, Cullen Jennings (fluffy) wrote: > > At the last meeting there was strong support for adopting > draft-uberti-rtcweb-fec as a WG draft. Unless we hear significant > objections to this, the chairs plan to more forward with adopting this. If > you have objection to this, please reply to this thread before Jan 15. > > Thanks, > > Cullen, Sean, & Ted > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae9cc928cee30a9050c28b907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft is now referenced normatively in draft-ietf-rtc= web-rtp-usage Section 6.2, so it is needed and we might as well get on with= it.=C2=A0

6.2.  Forward Error =
Correction (FEC)


   The use of Forward Error Correction (FEC) can provide an effective
   protection against some degree of packet loss, at the cost of steady
   bandwidth overhead.  There are several FEC schemes that are defined
   for use with RTP.  Some of these schemes are specific to a particular
   RTP payload format, others operate across RTP packets and can be used
   with any payload format.  It needs to be noted that using redundant
   encoding or FEC will lead to increased play out delay, which needs to
   be considered when choosing FEC schemes and their parameters.

   WebRTC endpoints MUST follow the recommendations for FEC use given in
   [I-D.uberti-rtcweb-fec].  WebRTC endpoints MAY=
 support other types of
   FEC, but these MUST be negotiated before they are used.

On Thu, Jan 8, 2= 015 at 10:57 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> = wrote:

At the last meeting there was strong support for adopting draft-uberti-rtcw= eb-fec as a WG draft. Unless we hear significant objections to this, the ch= airs plan to more forward with adopting this. If you have objection to this= , please reply to this thread before Jan 15.

Thanks,

Cullen, Sean, & Ted




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

--14dae9cc928cee30a9050c28b907-- From nobody Thu Jan 8 11:34: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 152491A9082 for ; Thu, 8 Jan 2015 11:34:50 -0800 (PST) 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 Czi8RjoZxpF7 for ; Thu, 8 Jan 2015 11:34:46 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059BE1A9080 for ; Thu, 8 Jan 2015 11:34:46 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id im6so1846784vcb.11 for ; Thu, 08 Jan 2015 11:34:45 -0800 (PST) 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=SpTzlg2Hn7xFb4O8mDTHGNKW7H4YRuvtrnrJeHPVNo4=; b=BpRFlmbOrsf7Nj2Eq2s2CQwdqbCDDaNmPv+PlPQ7hiia6IlHeKyLIoh6yddeK7iaxS 2zJZ06UCOP16FtLI6i1TA9/tmzRvebLvZOi344tBFhJjpnp1dv0WyQzibEgw5HwYU+eQ I53iwojjQYlRWggRmaSOvOor8GE8c92gFB4ICmwc8JVonNFVzRtb5yw51yH+iP6HKJzO h1pcsB8EhZuBFCQdaaY9879HMxu8NKHUxzJiY8L9KiaQhcRBFIFJu3h/280pL7S7CQIm nb62hZszDykeoDRWU1Pufj2uYt0QLvzJzbPOqCDqydrNsD6m+BRhz0rqpO8Dxb/w4sAp PXGQ== X-Gm-Message-State: ALoCoQmsMmwcWmHYmEUhbgnUewx/JOriK8Gzdl1BnIDc/TOBW4bZ4e1wxfNZxdHg/t3x4lSTgS+g X-Received: by 10.52.25.169 with SMTP id d9mr6771837vdg.85.1420745685212; Thu, 08 Jan 2015 11:34:45 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com. [209.85.220.173]) by mx.google.com with ESMTPSA id o5sm1302032vdv.24.2015.01.08.11.34.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Jan 2015 11:34:44 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id kv19so1831543vcb.4 for ; Thu, 08 Jan 2015 11:34:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.52.115.101 with SMTP id jn5mr7093641vdb.76.1420745684221; Thu, 08 Jan 2015 11:34:44 -0800 (PST) Received: by 10.52.54.194 with HTTP; Thu, 8 Jan 2015 11:34:44 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Jan 2015 14:34:44 -0500 Message-ID: From: Benjamin Schwartz To: Ted Hardie Content-Type: multipart/alternative; boundary=bcaec548a43fd32ed8050c292141 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2015 19:34:50 -0000 --bcaec548a43fd32ed8050c292141 Content-Type: text/plain; charset=UTF-8 For what it's worth, regarding scope, my perspective is that the document does not create any new protocol extensions or API points. Its only purpose is to lay out in detail the expected interaction between externally-provided TURN servers (like those found by TRAM autodiscovery) and WebRTC, which is currently extremely under-specified. Specifically, it explains that externally-provided TURN servers are _proxies_, not just additional TURN servers like those listed in the RTCPeerConnection constructor arguments. Treating these servers as proxies (in the particular manner specified) allows us to preserve (and enhance) some important performance, connectivity, and privacy properties of WebRTC. This document only imposes requirements (of any strength) on WebRTC implementations that intend to implement a mechanism for using TURN servers that were not indicated by the application. It does not demand that all browsers add support for such a mechanism, and it does not specify a preference for any particular TURN configuration mechanism. On Thu, Jan 8, 2015 at 1:54 PM, Ted Hardie wrote: > Howdy, > > During the Honolulu meeting, the chairs agreed to ask for some on-list > discussion of this draft prior to discussing adoption. During the holidays > we dropped the ball on that, for which our apologies. At this point, > though, we'd like to see some discussion of the draft--in particular on its > scope and how it fits into the landscape of work we need to complete > thanks, > > Ted, Cullen, Sean > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec548a43fd32ed8050c292141 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For what it's worth, regarding scope, my perspective i= s that the document does not create any new protocol extensions or API poin= ts.=C2=A0 Its only purpose is to lay out in detail the expected interaction= between externally-provided TURN servers (like those found by TRAM autodis= covery) and WebRTC, which is currently extremely under-specified.=C2=A0 Spe= cifically, it explains that externally-provided TURN servers are _proxies_,= not just additional TURN servers like those listed in the RTCPeerConnectio= n constructor arguments.=C2=A0 Treating these servers as proxies (in the pa= rticular manner specified) allows us to preserve (and enhance) some importa= nt performance, connectivity, and privacy properties of WebRTC.

This document only imposes requirements (of any strength) on WebRTC= implementations that intend to implement a mechanism for using TURN server= s that were not indicated by the application.=C2=A0 It does not demand that= all browsers add support for such a mechanism, and it does not specify a p= reference for any particular TURN configuration mechanism.

On Thu, Jan 8, 2015 at= 1:54 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
Howdy,

During the= Honolulu meeting, the chairs agreed to ask for some on-list discussion of = this draft prior to discussing adoption.=C2=A0 During the holidays we dropp= ed the ball on that, for which our apologies.=C2=A0=C2=A0 At this point, th= ough, we'd like to see some discussion of the draft--in particular on i= ts scope and how it fits into the landscape of work we need to complete
=
thanks,

Ted, Cullen, Sean

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


--bcaec548a43fd32ed8050c292141-- From nobody Thu Jan 8 13:06: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 09DAC1ACDDF for ; Thu, 8 Jan 2015 13:06:41 -0800 (PST) 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 zhfxrfdRZU2w for ; Thu, 8 Jan 2015 13:06:38 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF17C1A912A for ; Thu, 8 Jan 2015 13:06:38 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so1987418vcb.5 for ; Thu, 08 Jan 2015 13:06:37 -0800 (PST) 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=3D1Ko4dXRNjJjMwP9rWKiZaReSOa3js8GgR4UgZu28w=; b=hZPe3TaqIIcPMgRPPbg3EnDGX0uiLB3ZUTa07S4cW8lPqZxn/t1clD73tXGpGsodS8 Nepxl+s47zOC6WYsox8amG1Maq087ZoqDdK+hZbHriaV7MfzXqxwTj5Ls+fbaHhdYG/J 0vu9Sm3uryCJUHKI/6cuMRrDoA0Zz/Yc4e2OimQRNjWcPupcno77x9POeRaUql6UBadz Q3nKBf1Lupz0sDLqWOYFTMTrRc5i4Hye9hUvEuSjMsArI22NgrUrEsPDPZCauV2HfQaA NSeWi2B+P9jrJ3MedxVpXYSWaH4vKc8Y8OBi2Xna7dnTO7/1fIGmkmUvHhKkOC7B5Q1g 5zZg== 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=3D1Ko4dXRNjJjMwP9rWKiZaReSOa3js8GgR4UgZu28w=; b=OIksBxDDGTrAaia0ddvAo8XVBVjJAa+sPxWlW1ybI71NgwS8wxR+yPj3XqRPVWoOT8 vzCf8QO5qMOzI5a6m+xZ9TAoziuXiRQH4M0SSR4rSULLaDQtCzgE+VM1SGXs4vXKp8kA gSBZWgA2h/9VmUBzfDx2c4twyrDzATNd018AZUnrd4zchw+gjfNtwI1Mbo1sMdjt8Z9U 0JTDhc1P8zIuL+n4zjxzPegt2wfoPfvZLrC3BfSTH6eMjkVjdHVqFolt1WZ1NcxumuP4 1MriXxYWI16+4B/C+2oOOcIUnFEQN05Oxf7522STYNK1IbVJXxjpfM1xALgr1r89rCbs nCFA== X-Gm-Message-State: ALoCoQnlSRNQ1gZWkP9U3ZGysWz3kik11kBsOV7vlq/GVy0cP01/kHVKuFghSg8egmVRtSOEc9WY X-Received: by 10.220.143.209 with SMTP id w17mr8413591vcu.49.1420751197821; Thu, 08 Jan 2015 13:06:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.111.232 with HTTP; Thu, 8 Jan 2015 13:06:17 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 8 Jan 2015 13:06:17 -0800 Message-ID: To: Benjamin Schwartz Content-Type: multipart/alternative; boundary=047d7b3439d075fdf3050c2a6adb Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 08 Jan 2015 21:06:43 -0000 --047d7b3439d075fdf3050c2a6adb Content-Type: text/plain; charset=UTF-8 Right. To be absolutely clear, this draft explains how RTCWEB implementations can satisfy the requirement F20 from Section 3.3.5 of https://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-15#section-3.3.5.1. We've discussed the need for this for some time, but the RETURN draft is the first proposal for how to actually address it. ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- On Thu, Jan 8, 2015 at 11:34 AM, Benjamin Schwartz wrote: > For what it's worth, regarding scope, my perspective is that the document > does not create any new protocol extensions or API points. Its only > purpose is to lay out in detail the expected interaction between > externally-provided TURN servers (like those found by TRAM autodiscovery) > and WebRTC, which is currently extremely under-specified. Specifically, it > explains that externally-provided TURN servers are _proxies_, not just > additional TURN servers like those listed in the RTCPeerConnection > constructor arguments. Treating these servers as proxies (in the > particular manner specified) allows us to preserve (and enhance) some > important performance, connectivity, and privacy properties of WebRTC. > > This document only imposes requirements (of any strength) on WebRTC > implementations that intend to implement a mechanism for using TURN servers > that were not indicated by the application. It does not demand that all > browsers add support for such a mechanism, and it does not specify a > preference for any particular TURN configuration mechanism. > > On Thu, Jan 8, 2015 at 1:54 PM, Ted Hardie wrote: > >> Howdy, >> >> During the Honolulu meeting, the chairs agreed to ask for some on-list >> discussion of this draft prior to discussing adoption. During the holidays >> we dropped the ball on that, for which our apologies. At this point, >> though, we'd like to see some discussion of the draft--in particular on its >> scope and how it fits into the landscape of work we need to complete >> thanks, >> >> Ted, Cullen, Sean >> >> _______________________________________________ >> 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 > > --047d7b3439d075fdf3050c2a6adb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right. To be absolutely clear, this draft explains how RTC= WEB implementations can satisfy the requirement F20 from Section 3.3.5 ofhttps://tools.ietf.org/html/draft-ietf-rtcw= eb-use-cases-and-requirements-15#section-3.3.5.1. We've discussed t= he need for this for some time, but the RETURN draft is the first proposal = for how to actually address it.
   ---------------------=
-------------------------------------------
   REQ-ID      DESCRIPTION
   ----------------------------------------------------------------
   F20     The browser must support the use of STUN and TURN
           servers that are supplied by entities other than
           the web application (i.e. the network provider).
   ----------------------------------------------------------------



On Thu, Jan 8, 2015 at 11:= 34 AM, Benjamin Schwartz <bemasc@webrtc.org> wrote:
For what it's worth, regardi= ng scope, my perspective is that the document does not create any new proto= col extensions or API points.=C2=A0 Its only purpose is to lay out in detai= l the expected interaction between externally-provided TURN servers (like t= hose found by TRAM autodiscovery) and WebRTC, which is currently extremely = under-specified.=C2=A0 Specifically, it explains that externally-provided T= URN servers are _proxies_, not just additional TURN servers like those list= ed in the RTCPeerConnection constructor arguments.=C2=A0 Treating these ser= vers as proxies (in the particular manner specified) allows us to preserve = (and enhance) some important performance, connectivity, and privacy propert= ies of WebRTC.

This document only imposes requirements (= of any strength) on WebRTC implementations that intend to implement a mecha= nism for using TURN servers that were not indicated by the application.=C2= =A0 It does not demand that all browsers add support for such a mechanism, = and it does not specify a preference for any particular TURN configuration = mechanism.

On Thu, Jan 8, 2015 at 1:54 PM, Ted Hardie <t= ed.ietf@gmail.com> wrote:
Howdy,

= During the Honolulu meeting, the chairs agreed to ask for some on-list disc= ussion of this draft prior to discussing adoption.=C2=A0 During the holiday= s we dropped the ball on that, for which our apologies.=C2=A0=C2=A0 At this= point, though, we'd like to see some discussion of the draft--in parti= cular on its scope and how it fits into the landscape of work we need to co= mplete
thanks,

Ted, Cullen, Sean

_______________________________________________
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


--047d7b3439d075fdf3050c2a6adb-- From nobody Mon Jan 12 17:15: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 4FCF61ACE57; Mon, 12 Jan 2015 17:15:52 -0800 (PST) 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_81=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 T8sEWNWOc_IH; Mon, 12 Jan 2015 17:15:50 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF351A8826; Mon, 12 Jan 2015 17:15:49 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id z11so176531lbi.6; Mon, 12 Jan 2015 17:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=OzbJ0f5kb9EWtnp6GHSNmUA2//jqCdukKE/JkUYRn9g=; b=cOrWRtA8DzombbbZsPu7ccz+Bb0sZ1UjIo/iUDTFCCpahviHtcAd5eilO/VVSZuFVe 97LGX5QutiWVdaiwEppo2mM5c8SxwIFhmYGj7DBEUvZY+N6qOYBYlA4z4Ly8Y6qDMglH s15M9aN5sxBTSf8zlzfb+FuEUay7BiLgC6EqDcP3qwB75bYwbWsnCGSYDE4gPv+rfLn2 crCf0mGGpDbzpCEHn+HS/5feR4nxwnp6Gfn4q3E3BvLYeLOHrddnJYjzsMeglZiVdsZJ ADYcLYX+1ZlNAonnANMBXidX6Q6VlDnXin8mdAxAlzV7fYYd1Srl6MdPue37ssnDyd16 HTxA== X-Received: by 10.112.222.135 with SMTP id qm7mr39296254lbc.19.1421111748184; Mon, 12 Jan 2015 17:15:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.18 with HTTP; Mon, 12 Jan 2015 17:15:27 -0800 (PST) From: Barry Dingle Date: Tue, 13 Jan 2015 12:15:27 +1100 Message-ID: To: The IESG Content-Type: multipart/alternative; boundary=001a1134d228efcea5050c7e5cbb Archived-At: Cc: rtcweb mailing list , rtcweb chair , IETF-Announce , RFC Editor Subject: [rtcweb] Consistent WebRTC Descriptions in WebRTC RFC Abstracts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Jan 2015 01:15:52 -0000 --001a1134d228efcea5050c7e5cbb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The recently proposed Standards *WebRTC Data Channel RFC* and *WebRTC Data Channel Establishment Protocol RFC* have a consistent single sentence describing what WebRTC is in their Abstracts. They both say: The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. I notice that several other WebRTC proposed RFCs have single sentence WebRTC descriptions in their Abstract *but they are differen*t e.g. WebRTC Overview RFC; Media Transport + Use of RTP; Security; Security Architecture All the others have *NO WebRTC description*. *Do we need a consistent single sentence in the Abstract of all WebRTC RFCs?* If so, what should the wording be? Should the wording be in the Abstract of ALL WebRTC RFCs? Barry Dingle Fellow of University of Melbourne, Australia On Fri, Jan 9, 2015 at 1:38 AM, The IESG wrote: > The IESG has approved the following document: > - 'WebRTC Data Channels' > (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard > > This document is the product of the Real-Time Communication in > WEB-browsers Working Group. > > The IESG contact persons are Richard Barnes and Alissa Cooper. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ > > > > > Technical Summary: > > This document specifies the non=C2=ADmedia data transport aspects of the = WebRTC > framework. It provides an architectural overview of how the Stream Contro= l > Transmission > Protocol (SCTP) is used in the WebRTC context as a generic transport > service. > > Working Group Summary: > > There was early discussion of the stacking order, but there has been no > significant > controversy since that was fixed. There have been a number of discussion > on how to manage > particular aspects of the larger context (e.g. WebRTC=C2=ADlevel congesti= on > control, since SCTP > manages congestion control at the association level) and this has played = a > part in those, but > not in any way that mde it the focus of controversy. > > Document Quality: > > There are implmentations of previous versions of this document, and we > expect updates to > them to the final version. Vendor support seems solid. This document did > not require > expert review of the types noted. > > Personnel: > > The document shepherd is Ted Hardie; the responsible Area Director is > Richard Barnes. > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1134d228efcea5050c7e5cbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The recently proposed Stand= ards WebRTC Data Channel RFC and WebRTC Data Channel Establishmen= t Protocol RFC have a consistent single sentence describing what WebRTC= is in their Abstracts. They both say:
The WebRTC framework specifi=
es protocol support for direct interactive rich communication using audio, =

video, and data between two peers' web-browsers.
I noti= ce that several other WebRTC proposed RFCs have single sentence WebRTC desc= riptions in their Abstract but they are different e.g. WebRTC Overvi= ew RFC; Media Transport + Use of RTP; Security; Security Architecture
All the others have NO WebRTC description.

= Do we need a consistent single sentence in the Abstract of all WebRTC RFCs?=

If so, what should the wording be?

Should the wo= rding be in the Abstract of ALL WebRTC RFCs?


Barry Dingle
=C2=A0
Fellow of University of Melbourne, Australi= a

On Fri, Jan 9, 2015 at 1:38 AM, The IESG <iesg-secretary@ietf.org> wrote:
The IESG has approved the following document:<= br> - 'WebRTC Data Channels'
=C2=A0 (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard

This document is the product of the Real-Time Communication in
WEB-browsers Working Group.

The IESG contact persons are Richard Barnes and Alissa Cooper.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-c= hannel/




Technical Summary:

This document specifies the non=C2=ADmedia data transport aspects of the We= bRTC
framework. It provides an architectural overview of how the Stream Control = Transmission
Protocol (SCTP) is used in the WebRTC context as a generic transport servic= e.

Working Group Summary:

There was early discussion of the stacking order, but there has been no sig= nificant
controversy since that was fixed. There have been a number of discussion on= how to manage
particular aspects of the larger context (e.g. WebRTC=C2=ADlevel congestion= control, since SCTP
manages congestion control at the association level) and this has played a = part in those, but
not in any way that mde it the focus of controversy.

Document Quality:

There are implmentations of previous versions of this document, and we expe= ct updates to
them to the final version. Vendor support seems solid. This document did no= t require
expert review of the types noted.

Personnel:

The document shepherd is Ted Hardie; the responsible Area Director is Richa= rd Barnes.





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


--001a1134d228efcea5050c7e5cbb-- From nobody Mon Jan 12 21:27: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 C7E391A89B4 for ; Mon, 12 Jan 2015 21:27:53 -0800 (PST) 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_81=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 SPxoyoYy-YjA for ; Mon, 12 Jan 2015 21:27:52 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DCE71A89B0 for ; Mon, 12 Jan 2015 21:27:51 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id p9so823815lbv.0 for ; Mon, 12 Jan 2015 21:27:50 -0800 (PST) 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=INHRWQdOCN87xKr0MiMgosjIWBDM+krQD4wEfm1Zfew=; b=XVo+godi8W1jZFEjzC1Rn1aL9VXaWAdIxNPldgjrGkqyhZsWhomVV9hIg2KUVJ1SIj ScTxMMDJq5NWYDKM81B+mOHEIrflSQegFWgBgkjyM23lRcJAV9yjJG3/cCMF2QDujFVn bx9ayZkAKeOkBQ6Gy0N8HPXDa8NTiAZdP0BgRUy+j+5dY6IVxO94p49jo6ATKJWmSj2t X8M8vFLhPiKzWfJagsnSLnxhVRflOkb/O2861hfhyhaB0Itmkh7qVIgNTk+mDYOZSym9 HYBTpEkdQ68QvE2gUA3PMURNaEq+K4Oz8Sor3bAprQtaJP/t3ZCkwlZNHGnowBGHckE7 2Hjw== X-Received: by 10.112.55.199 with SMTP id u7mr14079938lbp.74.1421126870006; Mon, 12 Jan 2015 21:27:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.18 with HTTP; Mon, 12 Jan 2015 21:27:29 -0800 (PST) From: Barry Dingle Date: Tue, 13 Jan 2015 16:27:29 +1100 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1133fa76447f22050c81e28d Archived-At: Subject: [rtcweb] Consistent WebRTC Descriptions in WebRTC RFC Abstracts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Jan 2015 05:27:54 -0000 --001a1133fa76447f22050c81e28d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The recently proposed Standards *WebRTC Data Channel RFC* and *WebRTC Data Channel Establishment Protocol RFC* have a consistent single sentence describing what WebRTC is in their Abstracts. They both say: The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web-browsers. I notice that several other WebRTC proposed RFCs have single sentence WebRTC descriptions in their Abstract *but they are differen*t e.g. WebRTC Overview RFC; Media Transport + Use of RTP; Security; Security Architecture All the others have *NO WebRTC description*. *Do we need a consistent single sentence in the Abstract of all WebRTC RFCs?* If so, what should the wording be? Should the wording be in the Abstract of ALL WebRTC RFCs? Barry Dingle Fellow of University of Melbourne, Australia On Fri, Jan 9, 2015 at 1:38 AM, The IESG wrote: > The IESG has approved the following document: > - 'WebRTC Data Channels' > (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard > > This document is the product of the Real-Time Communication in > WEB-browsers Working Group. > > The IESG contact persons are Richard Barnes and Alissa Cooper. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ > > > > > Technical Summary: > > This document specifies the non=C2=ADmedia data transport aspects of the = WebRTC > framework. It provides an architectural overview of how the Stream Contro= l > Transmission > Protocol (SCTP) is used in the WebRTC context as a generic transport > service. > > Working Group Summary: > > There was early discussion of the stacking order, but there has been no > significant > controversy since that was fixed. There have been a number of discussion > on how to manage > particular aspects of the larger context (e.g. WebRTC=C2=ADlevel congesti= on > control, since SCTP > manages congestion control at the association level) and this has played = a > part in those, but > not in any way that mde it the focus of controversy. > > Document Quality: > > There are implmentations of previous versions of this document, and we > expect updates to > them to the final version. Vendor support seems solid. This document did > not require > expert review of the types noted. > > Personnel: > > The document shepherd is Ted Hardie; the responsible Area Director is > Richard Barnes. > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1133fa76447f22050c81e28d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
The recently proposed Standards WebRTC Data Channel= RFC and WebRTC Data Channel Establishment Protocol RFC have a c= onsistent single sentence describing what WebRTC is in their Abstracts. The= y both say:
The WebRTC framework specifies protocol support for dir=
ect interactive rich communication using audio, 
video, and data between=
 two peers' web-browsers.
I notice that several other WebRT= C proposed RFCs have single sentence WebRTC descriptions in their Abstract = but they are different e.g. WebRTC Overview RFC; Media Transport + U= se of RTP; Security; Security Architecture

All the others have= NO WebRTC description.

Do we need a consistent sin= gle sentence in the Abstract of all WebRTC RFCs?

If so, what sh= ould the wording be?

Should the wording be in the Abstract of= ALL WebRTC RFCs?


Barry Dingle
=C2=A0
Fellow of University = of Melbourne, Australia

On Fri, Jan 9, 2015 at 1:38 AM, The IESG <iesg-secretary@ietf.org> wrote:
The IESG has approved the following document:<= br> - 'WebRTC Data Channels'
=C2=A0 (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard

This document is the product of the Real-Time Communication in
WEB-browsers Working Group.

The IESG contact persons are Richard Barnes and Alissa Cooper.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-c= hannel/




Technical Summary:

This document specifies the non=C2=ADmedia data transport aspects of the We= bRTC
framework. It provides an architectural overview of how the Stream Control = Transmission
Protocol (SCTP) is used in the WebRTC context as a generic transport servic= e.

Working Group Summary:

There was early discussion of the stacking order, but there has been no sig= nificant
controversy since that was fixed. There have been a number of discussion on= how to manage
particular aspects of the larger context (e.g. WebRTC=C2=ADlevel congestion= control, since SCTP
manages congestion control at the association level) and this has played a = part in those, but
not in any way that mde it the focus of controversy.

Document Quality:

There are implmentations of previous versions of this document, and we expe= ct updates to
them to the final version. Vendor support seems solid. This document did no= t require
expert review of the types noted.

Personnel:

The document shepherd is Ted Hardie; the responsible Area Director is Richa= rd Barnes.





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



--001a1133fa76447f22050c81e28d-- From nobody Mon Jan 12 23:01: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 A41B81A8A1D for ; Mon, 12 Jan 2015 23:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Qfv3bYxlKdxX for ; Mon, 12 Jan 2015 23:01:05 -0800 (PST) Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 C2C181A8A16 for ; Mon, 12 Jan 2015 23:01:04 -0800 (PST) X-Halon-ID: ff09adff-9af1-11e4-a1ae-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.1.144] (unknown [81.224.110.16]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Tue, 13 Jan 2015 08:01:28 +0100 (CET) Message-ID: <54B4C2A9.9080607@omnitor.se> Date: Tue, 13 Jan 2015 08:00:57 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050606020000020006050108" Archived-At: Subject: Re: [rtcweb] Consistent WebRTC Descriptions in WebRTC RFC Abstracts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 13 Jan 2015 07:01:07 -0000 This is a multi-part message in MIME format. --------------050606020000020006050108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit A good timely observation. Similar problem in a couple of other protocol environments have caused me unnecessary waste of time. I have picked up one such definition from a central source document, while others have been used to other definitions, causing long discussions about which one to use. Time that would have been better spent on the technical content. So, I recommend harmonization, and use of the same term in the documents. That will save time in the future. Gunnar Hellström Omnitor ------------------------------------------------------------------------------------ Barry Dingle skrev den 2015-01-13 06:27: > > The recently proposed Standards /WebRTC Data Channel RFC/ and /WebRTC > Data Channel Establishment Protocol RFC/ have a consistent single > sentence describing what WebRTC is in their Abstracts. They both say: > The WebRTC framework specifies protocol support for direct interactive rich communication using audio, > video, and data between two peers' web-browsers. > I notice that several other WebRTC proposed RFCs have single sentence > WebRTC descriptions in their Abstract _but they are differen_t e.g. > WebRTC Overview RFC; Media Transport + Use of RTP; Security; Security > Architecture > > All the others have _NO WebRTC description_. > > _Do we need a consistent single sentence in the Abstract of all WebRTC > RFCs?_ > > If so, what should the wording be? > > Should the wording be in the Abstract of ALL WebRTC RFCs? > > > Barry Dingle > > Fellow of University of Melbourne, Australia > > On Fri, Jan 9, 2015 at 1:38 AM, The IESG > wrote: > > The IESG has approved the following document: > - 'WebRTC Data Channels' > (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard > > This document is the product of the Real-Time Communication in > WEB-browsers Working Group. > > The IESG contact persons are Richard Barnes and Alissa Cooper. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/ > > > > > Technical Summary: > > This document specifies the non­media data transport aspects of > the WebRTC > framework. It provides an architectural overview of how the Stream > Control Transmission > Protocol (SCTP) is used in the WebRTC context as a generic > transport service. > > Working Group Summary: > > There was early discussion of the stacking order, but there has > been no significant > controversy since that was fixed. There have been a number of > discussion on how to manage > particular aspects of the larger context (e.g. WebRTC­level > congestion control, since SCTP > manages congestion control at the association level) and this has > played a part in those, but > not in any way that mde it the focus of controversy. > > Document Quality: > > There are implmentations of previous versions of this document, > and we expect updates to > them to the final version. Vendor support seems solid. This > document did not require > expert review of the types noted. > > Personnel: > > The document shepherd is Ted Hardie; the responsible Area Director > is Richard Barnes. > > > > > > _______________________________________________ > 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 -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------050606020000020006050108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit A good timely observation.
Similar problem in a couple of other protocol environments have caused me unnecessary waste of time. I have picked up one such definition from a central source document, while others have been used to other definitions, causing long discussions about which one to use. Time that would have been better spent on the technical content.

So, I recommend harmonization, and use of the same term in the documents. That will save time in the future.

Gunnar Hellström
Omnitor

------------------------------------------------------------------------------------

Barry Dingle skrev den 2015-01-13 06:27:

The recently proposed Standards WebRTC Data Channel RFC and WebRTC Data Channel Establishment Protocol RFC have a consistent single sentence describing what WebRTC is in their Abstracts. They both say:
The WebRTC framework specifies protocol support for direct interactive rich communication using audio, 
video, and data between two peers' web-browsers.
I notice that several other WebRTC proposed RFCs have single sentence WebRTC descriptions in their Abstract but they are different e.g. WebRTC Overview RFC; Media Transport + Use of RTP; Security; Security Architecture

All the others have NO WebRTC description.

Do we need a consistent single sentence in the Abstract of all WebRTC RFCs?

If so, what should the wording be?

Should the wording be in the Abstract of ALL WebRTC RFCs?


Barry Dingle
 
Fellow of University of Melbourne, Australia

On Fri, Jan 9, 2015 at 1:38 AM, The IESG <iesg-secretary@ietf.org> wrote:
The IESG has approved the following document:
- 'WebRTC Data Channels'
  (draft-ietf-rtcweb-data-channel-13.txt) as Proposed Standard

This document is the product of the Real-Time Communication in
WEB-browsers Working Group.

The IESG contact persons are Richard Barnes and Alissa Cooper.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel/




Technical Summary:

This document specifies the non­media data transport aspects of the WebRTC
framework. It provides an architectural overview of how the Stream Control Transmission
Protocol (SCTP) is used in the WebRTC context as a generic transport service.

Working Group Summary:

There was early discussion of the stacking order, but there has been no significant
controversy since that was fixed. There have been a number of discussion on how to manage
particular aspects of the larger context (e.g. WebRTC­level congestion control, since SCTP
manages congestion control at the association level) and this has played a part in those, but
not in any way that mde it the focus of controversy.

Document Quality:

There are implmentations of previous versions of this document, and we expect updates to
them to the final version. Vendor support seems solid. This document did not require
expert review of the types noted.

Personnel:

The document shepherd is Ted Hardie; the responsible Area Director is Richard Barnes.





_______________________________________________
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


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288
--------------050606020000020006050108-- From nobody Tue Jan 13 16:48: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 176691ACE21 for ; Tue, 13 Jan 2015 16:48:26 -0800 (PST) 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 YsFTSn2uqZGN for ; Tue, 13 Jan 2015 16:48:24 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC33D1ACE2A for ; Tue, 13 Jan 2015 16:48:23 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id k48so6014018wev.5 for ; Tue, 13 Jan 2015 16:48:22 -0800 (PST) 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=Yi0l7cGTm67MMCufcJG9eFoc7oQXNxf4tstJ1PGoIlw=; b=w3pBjEKmcjHd3iybcK3UAVHWeteUCkxCHtNxJ6oMRMKmSftxS4PPzNsJPwKdst4/nP mT89PoA4dgKTHCV9fcpHV6RaMBZU0KJAiFsUw3pUBtTyncU9cyfh04oSSMczBbC8vjmD Pi5Zpu5sivmdggzci4WVQAJnpQgkhYa3I5cKqaGtHjktN71Vh4glhaEGVkU7LULZjdMb gwcTfZWg4AF8dHcwOYh28fE1w4SGsN/52pRkFcRmLPeDCE1k9lOMlZhaEUnpRRrwRThC l7zTAB1/boJx3MeY9L5HS/xjoCr3fL27wTtLwNMm7NRHrr4vbOOvpQUHGWFAyuwDy7gx OSZQ== X-Received: by 10.194.179.166 with SMTP id dh6mr1813561wjc.87.1421196502657; Tue, 13 Jan 2015 16:48:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.65 with HTTP; Tue, 13 Jan 2015 16:48:02 -0800 (PST) From: Bernard Aboba Date: Tue, 13 Jan 2015 16:48:02 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=089e01419d80b27051050c921857 Archived-At: Subject: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 00:48:26 -0000 --089e01419d80b27051050c921857 Content-Type: text/plain; charset=UTF-8 A question about negotiation of the use of the SRTP MKI field in DTLS/SRTP. RFC 5764 Section 4.1.3 has this to say about negotiation of support for the SRTP MKI field in SRTP/SRTCP: 4.1.3 . srtp_mki value The srtp_mki value MAY be used to indicate the capability and desire to use the SRTP Master Key Identifier (MKI) field in the SRTP and SRTCP packets. The MKI field indicates to an SRTP receiver which key was used to protect the packet that contains that field. Looking at draft-ietf-rtcweb-rtp-usage, draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, there is no additional mention of the SRTP MKI field. What can be concluded about negotiation and support for the SRTP MKI field within WebRTC implementations? Do existing WebRTC implementations have the capability to receive or send with the SRTP MKI field (e.g. if the peer implementation requests it?) Do existing WebRTC implementations indicate a desire to use the SRTP MKI field? Does the IETF RTCWEB WG have any additional guidance to provide on this topic beyond what is in RFC 5764 Section 4.1.3? --089e01419d80b27051050c921857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A question about negotiation of the use of the SRTP M= KI field in DTLS/SRTP.=C2=A0

RFC 5764 Section 4.1.3 has= this to say about negotiation of support for the SRTP MKI field in SRTP/SR= TCP:=C2=A0

4.1.3.  srtp_mki value


   The srtp_mki value MAY be used to indicate the capability and desire
   to use the SRTP Master Key Identifier (MKI) field in the SRTP and
   SRTCP packets.  The MKI field indicates to an SRTP receiver which key
   was used to protect the packet that contains that field.

Looking at draft-iet=
f-rtcweb-rtp-usage, draft-ietf-rtcweb-security and draft-ietf-rtcweb-securi=
ty-arch, there is no additional mention of the SRTP MKI field. =C2=A0

What can be concluded about ne=
gotiation and support for the SRTP MKI field within WebRTC implementations?=
=C2=A0

Do existing WebRTC implementations have the capability to receive or se=
nd with the SRTP MKI field (e.g. if the peer implementation requests it?)

<=
/span>
Do e=
xisting WebRTC implementations indicate a desire to use the SRTP MKI field?=
=C2=A0

Does the IETF RTCWEB WG have any additional guidance to provide on this=
 topic beyond what is in RFC 5764 Section 4.1.3?
<= /div> --089e01419d80b27051050c921857-- From nobody Tue Jan 13 16:58: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 104D81ACE0E for ; Tue, 13 Jan 2015 16:58:10 -0800 (PST) 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 Rb0cba_lYkup for ; Tue, 13 Jan 2015 16:58:05 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B78F1ACD46 for ; Tue, 13 Jan 2015 16:58:05 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id h11so25033193wiw.1 for ; Tue, 13 Jan 2015 16:58:04 -0800 (PST) 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=OlYRnPjtk9nPyBfL1waQnQVGSGEKhfjubHGplQrWJaM=; b=adjSZp5oChd4UtvdFBYW7NqDV6zI/Ag87r2SQzdhRh3fbQgrQ4vtBeGk+bZ7ad6WmL Q8RiPkiWtCpLFoU+ymkp4CJQJTTlUUgeAgC0rld1lEvX5vhXEsj+0IiEOcsHC4G3/e7h xDKz6gLd58cypuvXaoEvpbgV9LwLtgd1vAcmusSn1VCy40zJ7PVobibo/6T2QDZR7WJx vpRkz69qrYiA+6Sr1dalUTA0TprtiBvUZNugTONfhOXndBcApJ3xSh9zJfei2GntIcVO +EtG5F/HBhOs0sgG72ebD6WxJwqD9fulzgw3HUC6kEyl6Jc6hOEsBw3fpAWV8bp88aV6 ayKQ== X-Received: by 10.181.12.17 with SMTP id em17mr45432801wid.45.1421197084085; Tue, 13 Jan 2015 16:58:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.65 with HTTP; Tue, 13 Jan 2015 16:57:43 -0800 (PST) From: Bernard Aboba Date: Tue, 13 Jan 2015 16:57:43 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d043893c35a527f050c923ba3 Archived-At: Subject: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 00:58:10 -0000 --f46d043893c35a527f050c923ba3 Content-Type: text/plain; charset=UTF-8 Looking through IETF RTCWEB WG drafts ( https://tools.ietf.org/id/draft-ietf-rtcweb) and dependencies, "DTLS Heartbeat" RFC 6520 appears to be referenced only in draft-ietf-tsvwg-sctp-dtls-encaps Section 5, in the context of PMTU discovery: If path MTU discovery is performed by the DTLS layer, the method described in [RFC4821 ] MUST be used. For probe packets, the extension defined in [RFC6520 ] MUST be used. Is it correct to conclude that existing implementations do not use the DTLS heartbeat other than for PMTU discovery? --f46d043893c35a527f050c923ba3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looking through IETF RTCWEB WG drafts (https://tools.ietf.org/id/draft-ietf-r= tcweb) and dependencies, "DTLS Heartbeat" RFC 6520 appears to= be referenced only in draft-ietf-tsvwg-sctp-dtls-encaps Section 5, in the = context of PMTU discovery:=C2=A0

   If =
path MTU discovery is performed by the DTLS layer, the method
   described in [RFC4821] MUST be use=
d.  For probe packets, the
   extension defined in [RFC6520] MUST be used.

Is it correct to conclude that existing implementations d= o not use the DTLS heartbeat other than for PMTU discovery?=C2=A0
=
--f46d043893c35a527f050c923ba3-- From nobody Tue Jan 13 17:24: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 BCC101ACE42 for ; Tue, 13 Jan 2015 17:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il41kPBTfCfQ for ; Tue, 13 Jan 2015 17:24:52 -0800 (PST) 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 509AF1ACE40 for ; Tue, 13 Jan 2015 17:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6267; q=dns/txt; s=iport; t=1421198692; x=1422408292; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=re91Wg3gU2BPjou5Ya2R7/F3aX9HZcgEDVlLKe3eP4s=; b=Rgo8PShgPm7cPD2wrOGRBgPZyi7yJHRXP1Ty/OJNHTx5mFBfvoaW8PAt ht3qG54yfXHhn2LOWQddaHWUfh7dwKJbCzEC5jo10/K8xWR+UXVab9FKx gviprAAqqVfZIzLwXs9kTQ2oLMDve0PBtvZYG/3lO30PuhuQEw1e6M5Vp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsFABvEtVStJA2N/2dsb2JhbABbgwZSWMYchXECgRhDAQEBAQF9hA0BAQMBeQULC0YhNgYTiBgDCQgNzAgNg2MBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI1PgioHgxaBEwWJZoghhASBRIYag2WCGYVkIoQPHTEBAYJBAQEB X-IronPort-AV: E=Sophos;i="5.07,753,1413244800"; d="scan'208,217";a="113042705" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 14 Jan 2015 01:24:52 +0000 Received: from [10.24.147.250] ([10.24.147.250]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0E1OofV027307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2015 01:24:51 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_E20C9A6B-2488-46B3-8AEB-F22E428782A8" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 13 Jan 2015 17:24:51 -0800 Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 01:24:55 -0000 --Apple-Mail=_E20C9A6B-2488-46B3-8AEB-F22E428782A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 13, 2015, at 4:48 PM, Bernard Aboba = wrote: > A question about negotiation of the use of the SRTP MKI field in = DTLS/SRTP.=20 >=20 > RFC 5764 Section 4.1.3 has this to say about negotiation of support = for the SRTP MKI field in SRTP/SRTCP:=20 >=20 > 4.1.3. srtp_mki value >=20 > The srtp_mki value MAY be used to indicate the capability and = desire > to use the SRTP Master Key Identifier (MKI) field in the SRTP and > SRTCP packets. The MKI field indicates to an SRTP receiver which = key > was used to protect the packet that contains that field. >=20 > Looking at draft-ietf-rtcweb-rtp-usage, draft-ietf-rtcweb-security and = draft-ietf-rtcweb-security-arch, there is no additional mention of the = SRTP MKI field. =20 >=20 > What can be concluded about negotiation and support for the SRTP MKI = field within WebRTC implementations?=20 >=20 > Do existing WebRTC implementations have the capability to receive or = send with the SRTP MKI field (e.g. if the peer implementation requests = it?) >=20 > Do existing WebRTC implementations indicate a desire to use the SRTP = MKI field?=20 >=20 > Does the IETF RTCWEB WG have any additional guidance to provide on = this topic beyond what is in RFC 5764 Section 4.1.3? The function of SRTP MKI overlaps with EKT (Encrypted Key Transport), = and using both would significantly complicate EKT. Thus, in EKT, we = prohibit using MKI and EKT together. EKT brings a lot of advantages to = conferencing which cannot be achieved solely with MKI (no matter how MKI = is signaled). For WebRTC, I don't see SRTP MKI being used. -d --Apple-Mail=_E20C9A6B-2488-46B3-8AEB-F22E428782A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 13, 2015, at 4:48 PM, Bernard = Aboba <bernard.aboba@gmail.com> = wrote:

A question about negotiation of = the use of the SRTP MKI field in = DTLS/SRTP. 

RFC 5764 Section 4.1.3 has this to = say about negotiation of support for the SRTP MKI field in = SRTP/SRTCP: 

4.1.3.  srtp_mki value

   The srtp_mki value MAY be used to indicate the capability and desire
   to use the SRTP Master Key Identifier (MKI) field in the SRTP and
   SRTCP packets.  The MKI field indicates to an SRTP receiver which key
   was used to protect the packet that contains that field.

Looking at draft-ietf-rtcweb-rtp-usage, =
draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch, there is =
no additional mention of the SRTP MKI field.  

What can be concluded =
about negotiation and support for the SRTP MKI field within WebRTC =
implementations? 

Do existing WebRTC =
implementations have the capability to receive or send with the SRTP MKI =
field (e.g. if the peer implementation requests =
it?)

Do existing WebRTC =
implementations indicate a desire to use the SRTP MKI =
field? 

Does the IETF RTCWEB WG =
have any additional guidance to provide on this topic beyond what is in =
RFC 5764 Section =
4.1.3?

The = function of SRTP MKI overlaps with EKT (Encrypted Key Transport), and = using both would significantly complicate EKT.  Thus, in EKT, we = prohibit using MKI and EKT together.  EKT brings a lot of = advantages to conferencing which cannot be achieved solely with MKI (no = matter how MKI is signaled).  For WebRTC, I don't see SRTP MKI = being = used.

-d



<= /body>= --Apple-Mail=_E20C9A6B-2488-46B3-8AEB-F22E428782A8-- From nobody Tue Jan 13 17:28: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 C09B41ACE40 for ; Tue, 13 Jan 2015 17:28:19 -0800 (PST) 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 CbxjitrLANQ9 for ; Tue, 13 Jan 2015 17:28:18 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094F01ACE27 for ; Tue, 13 Jan 2015 17:28:18 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp18so1394427obc.11 for ; Tue, 13 Jan 2015 17:28:17 -0800 (PST) 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=6gwesK+rB/HiwX2nuYRwamk80wvs2OxxFgzCOU/TlHw=; b=XlEHzuw+oZNxTxOaovNSeGZjh1L11zbf5r0UsM3cCwJlsuKEtFK1U0XdprYs7A79Cj qpCIxROdBtvGjdxqwC3TYk1uV0fxKXuRwxYsgGPrDZ6TRGKkG2wODNbfopLkfQ1UMALo 6++b/0IBi4Jh3+Sm20FZGZVDojr68Js1jfLGOVsx2mWhXOFtTa0SzRE9FCUXZS+ANGzv zn2rvEztUcJPX4G3b2zlTYxb03VmRrcExl8UGMAAi5oHCxh5VnTKaBfJpm3pqoqmPv8Y Q7S5rip83jZorZqfjMDMF8dGG04TT+EIg00W+qCOTy0cAdJLeeC9GpKWkrR4rTLwgtbr FcdQ== MIME-Version: 1.0 X-Received: by 10.182.125.72 with SMTP id mo8mr836598obb.61.1421198897294; Tue, 13 Jan 2015 17:28:17 -0800 (PST) Received: by 10.202.226.136 with HTTP; Tue, 13 Jan 2015 17:28:17 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 17:28:17 -0800 Message-ID: From: Martin Thomson To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 01:28:19 -0000 On 13 January 2015 at 16:57, Bernard Aboba wrote: > Is it correct to conclude that existing implementations do not use the DTLS > heartbeat other than for PMTU discovery? I don't think we use it because I don't think that it is implemented in NSS. We don't need it now that we use ICE for the keep-alive stuff. I'll let others talk about PMTU discovery. From nobody Tue Jan 13 17:31: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 DB1661ACE42 for ; Tue, 13 Jan 2015 17:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, 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 e0QTxy4Y8n8U for ; Tue, 13 Jan 2015 17:31:12 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FAF61B2A1B for ; Tue, 13 Jan 2015 17:31:12 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id gq1so5698189obb.12 for ; Tue, 13 Jan 2015 17:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=j6R1kH6Y+vjaXciW1baX3cyUWEQvw+bBLMuCSjw0o+s=; b=NNNVp9QSKHT+McTvgxWbqX6nMQFMhhdkSOWZxoKpv3SikqkL0Oh5lps+u5y1iA7i1P 0LKuBLtDeIrUqUeveKNChCjsjf+d3d25y9yPGBOuzwgnccoUx0SgS9OBLSVxPCWt3FW0 XLXO8CWcZSIrdXvCbJl2siy0Q21cQ9UfDQgNePk/rIUrNVzho4vKne41GsncN/mU3wAC ydE3iqIuLWriDHLXcW7s/qkn/9Ou/M2sjbcBAJR3IN+9wjh7nmJLvnZNRZVSBbzrDzwr QD07bDrFzjLRyBSFG8MWn5FNN2GpQOZOFrnBp7aL3JprlRx8ETl/+IdjhD1ZHNr+Pz8Y rEUQ== MIME-Version: 1.0 X-Received: by 10.182.29.68 with SMTP id i4mr907517obh.30.1421199071438; Tue, 13 Jan 2015 17:31:11 -0800 (PST) Received: by 10.202.226.136 with HTTP; Tue, 13 Jan 2015 17:31:11 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2015 17:31:11 -0800 Message-ID: From: Martin Thomson To: =?UTF-8?B?8J+Uk0RhbiBXaW5n?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 01:31:14 -0000 On 13 January 2015 at 17:24, =F0=9F=94=93Dan Wing wrote: > For WebRTC, I don't see SRTP MKI being used. I'm not aware of anyone using it. I too would rather prohibit its use. That limits two-party session length, but from a practical perspective, that limit is going to be reached rarely, if ever without a re-handshake. Note that EKT isn't a perfect replacement because we should be prohibiting the initiation of EKT from browser endpoints (well, applications shouldn't be able to set the value used, though I guess they could request that the browser initiate EKT). From nobody Tue Jan 13 17:38: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 99A9B1A8746 for ; Tue, 13 Jan 2015 17:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuJofdxRIRz9 for ; Tue, 13 Jan 2015 17:38:40 -0800 (PST) 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 0C98B1ACE42 for ; Tue, 13 Jan 2015 17:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=844; q=dns/txt; s=iport; t=1421199520; x=1422409120; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LpyAbxONrvoVXgqXNEbhVQExrnRveKfUldCPjIIoCIM=; b=Uy8c1jG8ArqRs/c8Nh/WzqIHhXF6DF6XA9bhgE1nS1hnpR6JhpQ9qYZZ PizLB9LjuHhdqRdX/cy5z5yAoQ8WLe/qbNptrK58tPJmdq/11abf5xKDz ziJsr6IHc0y4zZ9rnHqYlEX2SzwWruNYVJmxBlGq2TBceH2aQauvCxhQL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkGAJbHtVStJV2a/2dsb2JhbABbgwaBKoMFyQkCgRhDAQEBAQF9hAwBAQEDASNWBQsJAhgCAiYCAiE2BhOIGAMJCJ8MnGqQGg2DYwEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYwugVMkMweCaC6BEwEEiWaMJYFEhhqDZYIZhWQihA8dMYEEgT8BAQE X-IronPort-AV: E=Sophos;i="5.07,753,1413244800"; d="scan'208";a="113047588" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 14 Jan 2015 01:38:40 +0000 Received: from [10.24.147.250] ([10.24.147.250]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t0E1cbZe008821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Jan 2015 01:38:38 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 13 Jan 2015 17:38:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <385387C1-F18C-48FF-9546-0042982D6763@cisco.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 01:38:44 -0000 On Jan 13, 2015, at 5:31 PM, Martin Thomson = wrote: > On 13 January 2015 at 17:24, =F0=9F=94=93Dan Wing = wrote: >> For WebRTC, I don't see SRTP MKI being used. >=20 > I'm not aware of anyone using it. I too would rather prohibit its > use. That limits two-party session length, but from a practical > perspective, that limit is going to be reached rarely, if ever without > a re-handshake. >=20 > Note that EKT isn't a perfect replacement because we should be > prohibiting the initiation of EKT from browser endpoints (well, > applications shouldn't be able to set the value used, though I guess > they could request that the browser initiate EKT). Yes, something explaining how WebRTC can safely use EKT needs to be = written, probably a document owned by RTCWEB. -d From nobody Wed Jan 14 00:49: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 9E6D91A6F96 for ; Wed, 14 Jan 2015 00:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 0G8vKFn0j8kB for ; Wed, 14 Jan 2015 00:49:52 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A601A1B3A for ; Wed, 14 Jan 2015 00:49:52 -0800 (PST) Received: from [192.168.1.200] (p508F2A85.dip0.t-ipconnect.de [80.143.42.133]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A1C251C10435D; Wed, 14 Jan 2015 09:49:49 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: Date: Wed, 14 Jan 2015 09:49:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Bernard Aboba X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 08:49:55 -0000 On 14 Jan 2015, at 01:57, Bernard Aboba wrote: >=20 > Looking through IETF RTCWEB WG drafts = (https://tools.ietf.org/id/draft-ietf-rtcweb) and dependencies, "DTLS = Heartbeat" RFC 6520 appears to be referenced only in = draft-ietf-tsvwg-sctp-dtls-encaps Section 5, in the context of PMTU = discovery:=20 >=20 > If path MTU discovery is performed by the DTLS layer, the method > described in [ > RFC4821 > ] MUST be used. For probe packets, the > extension defined in [ > RFC6520] MUST be used. >=20 > Is it correct to conclude that existing implementations do not use the = DTLS heartbeat other than for PMTU discovery?=20 http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 describes two options for SCTP over DTLS: * DTLS does the PMTUD using DTLS heartbeats * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks My understanding is the RTCWeb uses the second option as described in http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 Best regards Michael=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jan 14 07:08: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 139711A8859 for ; Wed, 14 Jan 2015 07:08:14 -0800 (PST) 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 N8jhGxXPCpna for ; Wed, 14 Jan 2015 07:08:12 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3FC1A6F0A for ; Wed, 14 Jan 2015 07:08:02 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id gd6so8631532lab.1 for ; Wed, 14 Jan 2015 07:08:01 -0800 (PST) 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=s30LPFAgdYQEyPppGcTBGOpBBhoqefhrTts4aBZxJJk=; b=OX61XURZfIdrCntx4pBa4SsTavLjm/VJxhgZVTTgMxGjZIuHONsbBXQHMKV3t7mm7Z C6UrlVgRcHR04E7vCXVFEe2xqKfU/hvhtDyvJzYeafnoxgoeDxIRBP1xjeZa8tK0aoqi zGIUcWNYRSX3Snr/ETyzhx0woTyJxp8Awb96QxLgOaJbj5IQFM+jkRXmYBK2NXgrQ/B3 Yco7v6iQ2Py5efqMHrH/hwo25swYt3oUXlVDYW2GQ6xSWKMdlgaQi/Wg5IpYFf4lJnGj wPYIvOjDKX237uuiJoXWBuq9RtbV8WbgBLKPsMu58y627NDD8hiSGzGJ8TMdEj0UwZdY kAig== X-Gm-Message-State: ALoCoQn232pP2Mvsq/YcQHxevGyZkVEFC/Ippl/zZ1TnLpTqYLEk6MqDUdMH32968oEI5v+61caU MIME-Version: 1.0 X-Received: by 10.152.8.11 with SMTP id n11mr4401974laa.38.1421248080915; Wed, 14 Jan 2015 07:08:00 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 07:08:00 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 10:08:00 -0500 Message-ID: From: Simon Perreault To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11c366e2004561050c9e1b28 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 15:08:14 -0000 --001a11c366e2004561050c9e1b28 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 13, 2015 at 7:48 PM, Bernard Aboba wrote: > Do existing WebRTC implementations have the capability to receive or send with the SRTP MKI field (e.g. if the peer implementation requests it?) > > Mine doesn't because OpenSSL doesn't support srtp_mki negotiation. Do existing WebRTC implementations indicate a desire to use the SRTP MKI field? > > I would much prefer to use MKI because otherwise re-handshake is very complex and brittle. I did implement re-handshake, which is uncommon. Simon --001a11c366e2004561050c9e1b28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jan 13, 2015 at 7:48 PM, Bernard Aboba <bernard.aboba@gmail.= com> wrote:
Do existing WebRTC implementations have the capab=
ility to receive or send with the SRTP MKI field (e.g. if the peer implemen=
tation requests it?)

Mi= ne doesn't because OpenSSL doesn't support srtp_mki negotiation.

Do existing WebRTC implementations indicate a desire to use the SRTP MKI f=
ield?=C2=A0

I would much prefer t= o use MKI because otherwise re-handshake is very complex and brittle. I did= implement re-handshake, which is uncommon.

Simon
--001a11c366e2004561050c9e1b28-- From nobody Wed Jan 14 08:08:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444B01A8ADF for ; Wed, 14 Jan 2015 08:08:33 -0800 (PST) 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 yHsAgEE7UkeN for ; Wed, 14 Jan 2015 08:08:31 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB501A8AA9 for ; Wed, 14 Jan 2015 08:08:31 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ho1so3535298wib.0 for ; Wed, 14 Jan 2015 08:08:30 -0800 (PST) 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=SzqXQ57UH/W5T2g1BA9EU9k6g9CfSNE1K883pRpWP1I=; b=qdLSZ4yJ9LS+hrNgu5ehvJn4WaxaZpgc1rCFJcywK/o5gqWcwT13hRFQNRN3W/zxh3 8AHhj0sLrrIMiVdgYFgxn20ah9mWj+pnQnn16+u14D1M4Jp5ms3GuGAdLNQm17wsMXgq 273x01m34p+mSmZoUw4YoKAZqhMyPlo8qxMSDnBp0Tb6qN4MbwveOGpZhvXBB2JEWjKc yFWBTv9EMz+H00yGZ/Z37ClTuAm91KreuPoSa9OPi/fSH3DoljbW7oYuV1YGFYSd8Cba njnVvTwEQ8eujznwtlWlSzwwVEaspEYzBqGtn78sJ8a2S6zp9mOA2ZK3sBTiZcaYNN90 /Q0w== X-Received: by 10.180.211.2 with SMTP id my2mr18463567wic.3.1421251708558; Wed, 14 Jan 2015 08:08:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.65 with HTTP; Wed, 14 Jan 2015 08:08:08 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 14 Jan 2015 08:08:08 -0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c37c1839a44c050c9ef37a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 16:08:33 -0000 --001a11c37c1839a44c050c9ef37a Content-Type: text/plain; charset=UTF-8 Simon said: "I would much prefer to use MKI because otherwise re-handshake is very complex and brittle. I did implement re-handshake, which is uncommon." [BA] Can you describe the scenario for DTLS re-handshake? On Wed, Jan 14, 2015 at 7:08 AM, Simon Perreault wrote: > > On Tue, Jan 13, 2015 at 7:48 PM, Bernard Aboba > wrote: > >> Do existing WebRTC implementations have the capability to receive or send with the SRTP MKI field (e.g. if the peer implementation requests it?) >> >> > Mine doesn't because OpenSSL doesn't support srtp_mki negotiation. > > Do existing WebRTC implementations indicate a desire to use the SRTP MKI field? >> >> > I would much prefer to use MKI because otherwise re-handshake is very > complex and brittle. I did implement re-handshake, which is uncommon. > > Simon > --001a11c37c1839a44c050c9ef37a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Simon said:

"I would m= uch prefer to use MKI because otherwise re-handshake is very complex and br= ittle. I did implement re-handshake, which is uncommon."
[BA] Can you describe the scenario for DTLS re-handshake?=C2=A0=

On W= ed, Jan 14, 2015 at 7:08 AM, Simon Perreault <sperreault@jive.com&g= t; wrote:

On Tue, Jan 13, 20= 15 at 7:48 PM, Bernard Aboba <bernard.aboba@gmail.com>= wrote:
Do exi=
sting WebRTC implementations have the capability to receive or send with th=
e SRTP MKI field (e.g. if the peer implementation requests it?)

Mine doesn't because Op= enSSL doesn't support srtp_mki negotiation.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-= left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-le= ft-style:solid">
Do existing WebRTC implementati=
ons indicate a desire to use the SRTP MKI field?=C2=A0
<=
/blockquote>

I would much prefer to use MKI because otherwi= se re-handshake is very complex and brittle. I did implement re-handshake, = which is uncommon.

Simon

--001a11c37c1839a44c050c9ef37a-- From nobody Wed Jan 14 08:34: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 C0F531A9024 for ; Wed, 14 Jan 2015 08:34:55 -0800 (PST) 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 NE1sbijZkX9t for ; Wed, 14 Jan 2015 08:34:41 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349371A8FD2 for ; Wed, 14 Jan 2015 08:34:29 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id s18so9069287lam.2 for ; Wed, 14 Jan 2015 08:34:27 -0800 (PST) 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=jTga4mxQg4DRrEsDSRhXxoShiqdYsunzPIfztlDvMOo=; b=bjacw9B6nxdfA2Awgm0sxc5p9Jp8m0hjbhdWhXlvr9IedX9QHICpe6BPl34hnoagTA TM4u7xSKCwZ1n8ScSH7QLRwboHnyIU4pWcdIpKrzyWcjrRS/GjovP8OktU/+DvnartEe 94XzNSyEN6Gh3EXF0OQzXm1tGu5XZoEMYEyqxbEr3BVZzRxSfKh6weiJggskVFcY0D0h cK4fU8QClVJYxSsGEEjneUbGMIZwXqwXRmGfzIsL+KDyTSjD+8uR23LwaA3RbwyTMnnt Orf7cUWYdQnx4GMfWOgVvTLf9l/xVUBdiPfjXEcGp/3jgvRj+1y8F3lt2PdWvpvaVafu SwLw== X-Gm-Message-State: ALoCoQn0nm1bEJeNEqnqzd1QFTDcycd/Od60TugugAhUqhEH3LYiia9UfvZ4Fy+aMewHFXVZ5ep2 MIME-Version: 1.0 X-Received: by 10.152.44.129 with SMTP id e1mr4894217lam.43.1421253267399; Wed, 14 Jan 2015 08:34:27 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 08:34:27 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 11:34:27 -0500 Message-ID: From: Simon Perreault To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e0160bc3823be66050c9f502d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 16:34:56 -0000 --089e0160bc3823be66050c9f502d Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 11:08 AM, Bernard Aboba wrote: > "I would much prefer to use MKI because otherwise re-handshake is very > complex and brittle. I did implement re-handshake, which is uncommon." > > [BA] Can you describe the scenario for DTLS re-handshake? > Sure. It is described in detail here: https://tools.ietf.org/html/rfc5764#section-5.2 Basically when a re-handshake happens you have to keep old keys around for 120 seconds in case old SRTP packets are still traveling the internet and have yet to arrive. Without an MKI, when packets arrive you have to try to authenticate them with the newest key, and if that doesn't work try progressively older keys. It's a hassle: you have to store keys in chronological order and iterate. With an MKI in the packet there's no iteration: you know exactly which key to use. You just grab it from the key table which you index by MKI. Simon --089e0160bc3823be66050c9f502d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 14, 2015 at 11:08 AM, Bernard Aboba <bernard.aboba@gmail= .com> wrote:
"= I would much prefer to use MKI because otherwise re-handshake is very compl= ex and brittle. I did implement re-handshake, which is uncommon."

[BA] Can you describe the scenario for DTLS re-= handshake?=C2=A0

Sure. It is described in detai= l here:
https://tools.ietf.org/html/rfc5764#section-5.2

= Basically when a re-handshake happens you have to keep old keys around for = 120 seconds in case old SRTP packets are still traveling the internet and h= ave yet to arrive.

Without an MKI, when packets arrive you have to try to authent= icate them with the newest key, and if that doesn't work try progressiv= ely older keys. It's a hassle: you have to store keys in chronological = order and iterate.

With an MKI in the packet there's no iteration: you know e= xactly which key to use. You just grab it from the key table which you inde= x by MKI.

Simon
--089e0160bc3823be66050c9f502d-- From nobody Wed Jan 14 09:17: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 9395C1A90E3 for ; Wed, 14 Jan 2015 09:17:22 -0800 (PST) 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 Vze_KTRtae5p for ; Wed, 14 Jan 2015 09:17:21 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91931A904D for ; Wed, 14 Jan 2015 09:17:20 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp18so4797404obc.11 for ; Wed, 14 Jan 2015 09:17:20 -0800 (PST) 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=l+Y5bpuRKt2+LrMdlR5cxXwYKj/fHd9DQBSdPKozFW4=; b=esXL6j9mR6wJcZhFKyWSWtW0vU20uPuuYtFWSju5b2hQs8IBJA2f7rIQfT+qoshh+g f1rbP692W4xCYM7qb/mm3Ifhnq6uOHGukreGdDMy0wxGIA4TDekT8+jTkQh1EamMT0vA JrXFr/k+6UwPEq8dbn6XPPrOujLZAEnlLGz0SPthoX6MTzQJNpNr9cO/DGYqd9uY/of2 oB6o8q3yaH8TgsVq5P9Sxuyo4j9jcypcVjvax4zcnKKJ2yg8UQYtpXfd5L50540Z4/F0 jnMt4uch2ameaeulHkKNFbPobN4mY3SGW08U8Oa0uDuoIQcsl/mMBO2RxwK/vMApenZJ B4fw== MIME-Version: 1.0 X-Received: by 10.60.145.167 with SMTP id sv7mr3140133oeb.38.1421255840216; Wed, 14 Jan 2015 09:17:20 -0800 (PST) Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 09:17:20 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 09:17:20 -0800 Message-ID: From: Martin Thomson To: Michael Tuexen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 17:17:22 -0000 On 14 January 2015 at 00:49, Michael Tuexen wrote: > * DTLS does the PMTUD using DTLS heartbeats > * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks > > My understanding is the RTCWeb uses the second option as described in > http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 SGTM. That means we don't need to reference the DTLS heartbleed extension. From nobody Wed Jan 14 09:26: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 B95841A9127 for ; Wed, 14 Jan 2015 09:26:36 -0800 (PST) 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 TWF6ICNH4q61 for ; Wed, 14 Jan 2015 09:26:35 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6FD1A9126 for ; Wed, 14 Jan 2015 09:26:34 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id nt9so9165601obb.4 for ; Wed, 14 Jan 2015 09:26:34 -0800 (PST) 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=s/dpUYaJxwAQe7YRSt0/EvMNxku9Gz6/8Y3nAnyTirw=; b=v6rIoo/IVaOfubfZqlPkXy2DVjWyB1TOCmHgETcV5+2QxCxzF646+FilfteW3Xer7r Ic+aphHC2d9jAuw1r8aILvidCtRG44lqFNRQraJDaJVwxbwTOCByalQM4aKoX34DpIUv 7MP2D+2Kqpl2LGHeoXTtzRBzQHiP9ITaZkGYnlv58Pp+1kq2hg/p4s81dQJ14Zh0p2ZP VPZ3wbN+89xEIkPYkus0yybdT41xKIP97KaJ2wnmSL5UsrjieUvrT8vZA36YIxzTTiVr pg8rk2n3kNlyIV58ClDL3Xjq/pF2XhHlNSpGusjIQuKGZRKevgyVNzINmMO9n4DjWfxp yFnQ== MIME-Version: 1.0 X-Received: by 10.60.76.10 with SMTP id g10mr3264160oew.0.1421256394031; Wed, 14 Jan 2015 09:26:34 -0800 (PST) Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 09:26:33 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 09:26:33 -0800 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 17:26:37 -0000 On 14 January 2015 at 08:34, Simon Perreault wrote: > Without an MKI, when packets arrive you have to try to authenticate them > with the newest key, and if that doesn't work try progressively older keys. > It's a hassle: you have to store keys in chronological order and iterate. Yes, SRTP doesn't carry the epoch and trial decryption sucks, so the MKI is quite attractive... if you rekey. However, as it stands, very few implementations will permit a DTLS re-handshake. Firefox and Chrome actively disable renegotiation (desktop Chrome anyway, I'm not 100% on the BoringSSL-based versions, like Android). Rekeying for very long sessions sounds attractive, but I don't see it happening in the short term. Actually, given expected session durations and the likelihood of a connection breaking, I think that the number of times when it might be necessary is vanishingly small. From nobody Wed Jan 14 09:43: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 2454E1A9138 for ; Wed, 14 Jan 2015 09:43:19 -0800 (PST) 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 Lb0fniIJg3Rr for ; Wed, 14 Jan 2015 09:43:17 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194171A1A86 for ; Wed, 14 Jan 2015 09:43:17 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id n3so29801137wiv.5 for ; Wed, 14 Jan 2015 09:43:15 -0800 (PST) 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=bhbRp+KMnjXdD1MNDIixCk1wK+bh6mxUO/9g9RAOssw=; b=mX6gNeiMU8ZNNvOoVgpquGhsYggBNO+pWWdLju8nGd8Zt3nHiUMHxLR4gAUF/pOpR0 3pTQdF5XuRNnpH53qsT1EVhxUllRboiWPxUblNJkgWcv4b36se+ok029jIqqQ7ShhbDx kRM2Mr+5dzEtxVQYGNC4+7guSXKj4pf+u1cccJgBGlixid4LtQ5oY/a2x36ziYMPEzLR /Qbh6Digsb7WEwxjjG7N2JxLTKfA7nh2+Jsl7ZLWFSvewjwm9AoE6MLFoyqii5BCS0fP 3L+nfvNtLX8ZJXGvrBnhC8BRrRVLpKqTtFRYhX9nOUQ/CJ6uw6/IbcaK8GlUXqs/alGc Ni1g== X-Gm-Message-State: ALoCoQmS2xDx1BeXvzDYaMfpwV2/ZoDMReDQjr5JiqOqTOSq/F4/TVawX5vtXitijJ3CtwP2PCMm X-Received: by 10.180.95.97 with SMTP id dj1mr10562445wib.43.1421257395784; Wed, 14 Jan 2015 09:43:15 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com. [74.125.82.45]) by mx.google.com with ESMTPSA id h2sm4260382wix.5.2015.01.14.09.43.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 09:43:14 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y19so10363498wgg.4 for ; Wed, 14 Jan 2015 09:43:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr9595957wjb.71.1421257394558; Wed, 14 Jan 2015 09:43:14 -0800 (PST) Received: by 10.216.97.141 with HTTP; Wed, 14 Jan 2015 09:43:14 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 12:43:14 -0500 Message-ID: From: Roman Shpount To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bd910c22321f0050ca046b2 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 17:43:19 -0000 --047d7bd910c22321f0050ca046b2 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 12:26 PM, Martin Thomson wrote: > On 14 January 2015 at 08:34, Simon Perreault wrote: > > Without an MKI, when packets arrive you have to try to authenticate them > > with the newest key, and if that doesn't work try progressively older > keys. > > It's a hassle: you have to store keys in chronological order and iterate. > > Yes, SRTP doesn't carry the epoch and trial decryption sucks, so the > MKI is quite attractive... if you rekey. However, as it stands, very > few implementations will permit a DTLS re-handshake. Firefox and > Chrome actively disable renegotiation (desktop Chrome anyway, I'm not > 100% on the BoringSSL-based versions, like Android). > > You can handle the key transition based on the SRTP sequence numbers. Not the greatest thing but it does work. BoringSSL versions do not support renegotiation either. _____________ Roman Shpount --047d7bd910c22321f0050ca046b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 14, 2015 at 12:26 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 14 Janua= ry 2015 at 08:34, Simon Perreault <sperreault@jive.com> wrote:
> Without an MKI, when packets arrive you have to try to authenticate th= em
> with the newest key, and if that doesn't work try progressively ol= der keys.
> It's a hassle: you have to store keys in chronological order and i= terate.

Yes, SRTP doesn't carry the epoch and trial decryption sucks, so= the
MKI is quite attractive... if you rekey.=C2=A0 However, as it stands, very<= br> few implementations will permit a DTLS re-handshake.=C2=A0 Firefox and
Chrome actively disable renegotiation (desktop Chrome anyway, I'm not 100% on the BoringSSL-based versions, like Android).


You can handle the key transition base= d on the SRTP sequence numbers. Not the greatest thing but it does work. Bo= ringSSL versions do not support renegotiation either.=C2=A0
_____________
Roman Shpount
= =C2=A0
--047d7bd910c22321f0050ca046b2-- From nobody Wed Jan 14 10:21: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 E9EB91AC3F3 for ; Wed, 14 Jan 2015 10:21:05 -0800 (PST) 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 b495tkaXkG-p for ; Wed, 14 Jan 2015 10:21:04 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C451AC398 for ; Wed, 14 Jan 2015 10:21:03 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id p9so9407795lbv.7 for ; Wed, 14 Jan 2015 10:21:02 -0800 (PST) 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=s/mIU3SIHTl0QzPvVJxuk/ndfU8TiyPImGGNlwfbYDE=; b=GkB5IW+ZKqH127uD9vaQggZY04Hw2BAP9kliPrWgKnac15mTbXFK9R4xkdQtcmUGr+ NSdWitF5dv4d9p+7PCqVYwUmMR05bgyRNSJscslIU9Cz9IeQVVbNrvxzbgHNSdmPFuxf IXmY4DhN/mOmY36ODe7wr6aNF0SifBlLhVoolU2OMckdtt2sTJo1kxuJTjXUZLlc8xGs 2XPjKLMu3Be9vnNHKvqZExAmjgVkEfzZCd4w2SiOcG41jqkWgEUOclXedlnunS7MVvH8 UXsqBAbOIsalKlOf2Qp9hc7/7A+DdRomvno8DBjwzxUgLfxtT5vydAenuFJ0ZoLJw1yS VPIw== X-Gm-Message-State: ALoCoQncbIZdlQ/YenIPDfIPZRklDR6GYn7+NKfqF1/J5QjkTM812tWLdKUfd6Nur+PcuGQ3b9DC MIME-Version: 1.0 X-Received: by 10.112.168.164 with SMTP id zx4mr5542252lbb.28.1421259662215; Wed, 14 Jan 2015 10:21:02 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 10:21:02 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 13:21:02 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c235644ce921050ca0cd49 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 18:21:06 -0000 --001a11c235644ce921050ca0cd49 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 12:43 PM, Roman Shpount wrote: > Yes, SRTP doesn't carry the epoch and trial decryption sucks, so the >> MKI is quite attractive... if you rekey. However, as it stands, very >> few implementations will permit a DTLS re-handshake. Firefox and >> Chrome actively disable renegotiation (desktop Chrome anyway, I'm not >> 100% on the BoringSSL-based versions, like Android). >> >> > You can handle the key transition based on the SRTP sequence numbers. Not > the greatest thing but it does work. > Please explain. Simon --001a11c235644ce921050ca0cd49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 14, 2015 at 12:43 PM, Roman Shpount <roman@telurix.com>= wrote:
Yes, SRTP doesn't carry the epoch and trial decryption sucks, s= o the
MKI is quite attractive... if you rekey.=C2=A0 However, as it stands, very<= br> few implementations will permit a DTLS re-handshake.=C2=A0 Firefox and
Chrome actively disable renegotiation (desktop Chrome anyway, I'm not 100% on the BoringSSL-based versions, like Android).


You can handle the key transiti= on based on the SRTP sequence numbers. Not the greatest thing but it does w= ork.

Please explain.

Simon
--001a11c235644ce921050ca0cd49-- From nobody Wed Jan 14 10:39: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 0C10C1ACD04 for ; Wed, 14 Jan 2015 10:39:52 -0800 (PST) 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 P6XZHnvF2zEn for ; Wed, 14 Jan 2015 10:39:50 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A34D1ACD03 for ; Wed, 14 Jan 2015 10:39:49 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id pv20so9673998lab.13 for ; Wed, 14 Jan 2015 10:39:48 -0800 (PST) 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=FxgnIQTGnvuvYfQFxkdn+eaCmUvoK0L9PMsGdlvpT9k=; b=j62qXcR0xsWFqzKgU2GhIvuumx1T/6PBmt8bVDvaRpqHveLuS8Wn87SHaNpPNWjMqU fqM98/FOJCWXWBWADE0q6v6eCw1DRgAErh7SuxxDD3PNQRioxZvn5aq1NB+wBZHUgphu 3Z4RGb5+Y0QK0bkUSa8u72G/RqJ8wXR/dp5juE/8Dd+qXbbHiZWGMsQ0DsWzOQw6wckP SNQLsOUYbPVZz86zWlNqRGPekamXqVdVI5+oJz3qaOnCUqJdAfSofSYxWSw6Pn8bwp4S BTtJYW8yLfDpCZ12jzHSGuvExlLHo0BDCRRkxO3AyvYDxdoB2ThIzv9vU71rWqD0iib+ yG9Q== X-Gm-Message-State: ALoCoQmBwKvSw6omJ7/q+4dlu1nTnkI/sBkL2vWEMPCRbp5suN1bSIsZe/QwqDxAptslAqyT4Bcs MIME-Version: 1.0 X-Received: by 10.112.159.136 with SMTP id xc8mr5512227lbb.98.1421260788321; Wed, 14 Jan 2015 10:39:48 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 10:39:48 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 13:39:48 -0500 Message-ID: From: Simon Perreault To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c3dbac6be52b050ca110d8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 18:39:52 -0000 --001a11c3dbac6be52b050ca110d8 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 12:26 PM, Martin Thomson wrote: > > Yes, SRTP doesn't carry the epoch and trial decryption sucks, so the > MKI is quite attractive... if you rekey. However, as it stands, very > few implementations will permit a DTLS re-handshake. Firefox and > Chrome actively disable renegotiation (desktop Chrome anyway, I'm not > 100% on the BoringSSL-based versions, like Android). > > Rekeying for very long sessions sounds attractive, but I don't see it > happening in the short term. Actually, given expected session > durations and the likelihood of a connection breaking, I think that > the number of times when it might be necessary is vanishingly small. I don't disagree. At 50 packets per second you're good for 497 days without a rekey. Also, didn't renegotiation just get removed from TLS 1.3 or did I get that wrong? Simon --001a11c3dbac6be52b050ca110d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 14, 2015 at 12:26 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
Yes, SRTP doesn= 't carry the epoch and trial decryption sucks, so the
MKI is quite attractive... if you rekey.=C2=A0 However, as it stands, very<= br> few implementations will permit a DTLS re-handshake.=C2=A0 Firefox and
Chrome actively disable renegotiation (desktop Chrome anyway, I'm not 100% on the BoringSSL-based versions, like Android).

Rekeying for very long sessions sounds attractive, but I don't see it happening in the short term.=C2=A0 Actually, given expected session
durations and the likelihood of a connection breaking, I think that
the number of times when it might be necessary is vanishingly small.

I don't disagree. At 50 packets per second you're g= ood for 497 days without a rekey. Also, didn't renegotiation just get r= emoved from TLS 1.3 or did I get that wrong?

Simon
--001a11c3dbac6be52b050ca110d8-- From nobody Wed Jan 14 10:40: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 0D6271ACD09 for ; Wed, 14 Jan 2015 10:40:11 -0800 (PST) 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 CRZrErSBa2AC for ; Wed, 14 Jan 2015 10:40:08 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624FF1ACD0E for ; Wed, 14 Jan 2015 10:40:08 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so28397065wib.1 for ; Wed, 14 Jan 2015 10:40:07 -0800 (PST) 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=eJXWCClaM97J76Rgw0EP3yEvWpxdO4XIXmgRCJ/QcZc=; b=Su2SHD8Do6Cq/jTn94WhNwXP1S2/Bm/3zv5jnSAFKzeuGkf407Hj+btHRW7ZonFDng PTvU/69XlLTvFuLkAlHiM88/NLtIQiEZvI87JrcMUC2h65XG1k/xsv4RwiAopl2KFJbs 1s4+fw2B46QHfpYvUKm/k691CwgocJZh0WECmQy4ax+2mQ9WzYKW3ev7dOqJjxsF0e67 iW97t0y4gFtYAu5zbLy4nowtf3NbPW7YUsuxjUWdXwG4C7k7PX9oAPVVfkc1jtL/MjTT Qzkc3o/dB4lakafp+ChMk4RU5rr4sMJYAz8BGpUYEN5ofaSew5YjKU+/T+6K9NgSFmz7 nWcA== X-Gm-Message-State: ALoCoQn+HnUNfjWxLjNvDbmp6ZUDVG3GtlMoRpb/gwfLxtAsv7z2gElkeJPflo4STKV1YF8K7b68 X-Received: by 10.180.103.6 with SMTP id fs6mr19278273wib.11.1421260807161; Wed, 14 Jan 2015 10:40:07 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com. [209.85.212.180]) by mx.google.com with ESMTPSA id ei5sm19752585wid.2.2015.01.14.10.40.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 10:40:06 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so12928112wiv.1 for ; Wed, 14 Jan 2015 10:40:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.2.75 with SMTP id 11mr10390479wjs.78.1421260805957; Wed, 14 Jan 2015 10:40:05 -0800 (PST) Received: by 10.216.97.141 with HTTP; Wed, 14 Jan 2015 10:40:05 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 13:40:05 -0500 Message-ID: From: Roman Shpount To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b3a834c78f06c050ca1111f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 18:40:11 -0000 --047d7b3a834c78f06c050ca1111f Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 1:21 PM, Simon Perreault wrote: > > On Wed, Jan 14, 2015 at 12:43 PM, Roman Shpount wrote: > >> Yes, SRTP doesn't carry the epoch and trial decryption sucks, so the >>> MKI is quite attractive... if you rekey. However, as it stands, very >>> few implementations will permit a DTLS re-handshake. Firefox and >>> Chrome actively disable renegotiation (desktop Chrome anyway, I'm not >>> 100% on the BoringSSL-based versions, like Android). >>> >>> >> You can handle the key transition based on the SRTP sequence numbers. Not >> the greatest thing but it does work. >> > > Please explain. > > You can use the old key, until the first SRTP packet fails to verify, try to verify the SRTP packet using new key and record sequence number for this SSRC as the first sequence for which new key is used. For all subsequent packets use the new SRTP key. For all previous -- repeat the above process. This should work in the absence of MKI. At the end of the day this is simply optimization of trying to decode using multiple keys. You do need to maintain the list of old keys, time them out, and keep the sequence numbers for each SSRC where you start using each key. _____________ Roman Shpount --047d7b3a834c78f06c050ca1111f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 14, 2015 at 1:21 PM, Simon Perreault <sperreault@jive.com&g= t; wrote:

On Wed, Jan 14, 2015 = at 12:43 PM, Roman Shpount <roman@telurix.com> wrote:
Yes, SRTP doesn't carry the epoch = and trial decryption sucks, so the
MKI is quite attractive... if you rekey.=C2=A0 However, as it stands, very<= br> few implementations will permit a DTLS re-handshake.=C2=A0 Firefox and
Chrome actively disable renegotiation (desktop Chrome anyway, I'm not 100% on the BoringSSL-based versions, like Android).


You can handle the key transiti= on based on the SRTP sequence numbers. Not the greatest thing but it does w= ork.

Please explain.


You can use the old key, until the first SRTP packet fails t= o verify, try to verify the SRTP packet using new key and record sequence n= umber for this SSRC as the first sequence for which new key is used. For al= l subsequent packets use the new SRTP key. For all previous -- repeat the a= bove process. This should work=C2=A0in the absence of MKI. At the end of the day this is simply= optimization of trying to decode using multiple keys. You do need to maint= ain the list of old keys, time them out, and keep the sequence numbers for = each SSRC where you start using each key.

<= div>
_____________
Roman Shpount

--047d7b3a834c78f06c050ca1111f-- From nobody Wed Jan 14 10:43: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 E74481ACD31 for ; Wed, 14 Jan 2015 10:43:43 -0800 (PST) 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 LhQOD08O9g8e for ; Wed, 14 Jan 2015 10:43:42 -0800 (PST) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798C91ACD2A for ; Wed, 14 Jan 2015 10:43:40 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id u10so9409121lbd.13 for ; Wed, 14 Jan 2015 10:43:39 -0800 (PST) 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=PbNL2M16cjy81ZrGGM0Z+o8q+9gix0YyBmGHSosCxHg=; b=nCDa6ezmHQFhYdugZAaJo6suvUTvesiz43QhEd6KYIvNiHfCJQP2xAtMWKR3zo+tNM rZJwsXwYheITUjXUWbpfarKtVvogHjhWmbo5hwKN7kG28Uomhzwx5GGnoCaY1a6LWuUk glNU7+LecWIcri0KucAL+AwrZ8zJsOnSfVJ+pFKfDEIy/3ciy49VA1caZjdJt72pl6w2 N7pVYhk2PqCoDg6qMMr9HHNYPDIcYl4JV9nw6x8D4+VXYpa1Vfmz2YQbEpiPHRxJs6GX Y7Odue+zGZfPEHfZsYwiC0f++nw3+aVyjHrfOVdslrBLqr1qqhin8D1rcOE7yCPwdPkM f+uA== X-Gm-Message-State: ALoCoQmV9QG4D7w23gNI+xTAC1gJJRhiOsJBszqgnxLaU+y/EQrIzOIOScTj7u6re1jM5PTiST4o MIME-Version: 1.0 X-Received: by 10.112.188.201 with SMTP id gc9mr5708576lbc.6.1421261018972; Wed, 14 Jan 2015 10:43:38 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 10:43:38 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 13:43:38 -0500 Message-ID: From: Simon Perreault To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11c373662b5817050ca11ec6 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 18:43:44 -0000 --001a11c373662b5817050ca11ec6 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 1:40 PM, Roman Shpount wrote: > You can use the old key, until the first SRTP packet fails to verify, try > to verify the SRTP packet using new key and record sequence number for this > SSRC as the first sequence for which new key is used. For all subsequent > packets use the new SRTP key. For all previous -- repeat the above process. > This should work in the absence of MKI. At the end of the day this is > simply optimization of trying to decode using multiple keys. You do need to > maintain the list of old keys, time them out, and keep the sequence numbers > for each SSRC where you start using each key. Yes, that's the optimization described in the last paragraph of https://tools.ietf.org/html/rfc5764#section-5.2. I didn't implement it because I don't believe it actually optimizes anything. It certainly makes code more complex, and could actually take more time to execute because of branch misprediction. Simon --001a11c373662b5817050ca11ec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 14, 2015 at 1:40 PM, Roman Shpount <roman@telurix.com><= /span> wrote:
You can use the old key, until the first SRTP packet fails to verify= , try to verify the SRTP packet using new key and record sequence number fo= r this SSRC as the first sequence for which new key is used. For all subseq= uent packets use the new SRTP key. For all previous -- repeat the above pro= cess. This should work=C2=A0in the absence of MKI. At the end of the day this is simply optimiz= ation of trying to decode using multiple keys. You do need to maintain the = list of old keys, time them out, and keep the sequence numbers for each SSR= C where you start using each key.

Yes, that= 9;s the optimization described in the last paragraph of=C2=A0https://tools.ietf.org/html/rfc5764#section-5.2. I didn&#= 39;t implement it because I don't believe it actually optimizes anythin= g. It certainly makes code more complex, and could actually take more time = to execute because of branch misprediction.

Simon
--001a11c373662b5817050ca11ec6-- From nobody Wed Jan 14 11:16: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 B6B1A1ACE90 for ; Wed, 14 Jan 2015 11:16:28 -0800 (PST) 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 p5yg8kuXsvfq for ; Wed, 14 Jan 2015 11:16:27 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B321ACE8E for ; Wed, 14 Jan 2015 11:16:26 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id a141so8853918oig.8 for ; Wed, 14 Jan 2015 11:16:26 -0800 (PST) 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=9h9OCM5IkUIShw8TSnettoGOhhOekFfSq8PL6FQ/DhI=; b=mrZvzxtBYpg6sZbT3jsFJ/+bZtsY5H+bQRNYTutLJDUQ/wU5Mty/yGl1gq1/eEj9qK awAW4HzlbNATsSAFSmERbziUcRCDYH4JoHz1YdO/r9nzR9Rrvn15Q/g4V6FYnttCVRTZ DvWtK7LP6MORIZJyWSsz6h9Aicq9GM3nYebI2EH8jjyG0XoxoXba+NYj7SbT8YbnhQS3 1fQfjv9xKBYWfj/YG6mnp42VTa2pwyzDRXJ7mtwCFtBTc0JCgndqNVqxFouFf9FmPegh YUdPoZkYQ1XyPyRSs9nhjbxQ3Mc3EV1JUDnHxuirCPIRFHTu2jlIUA/fFETOGqOc+GBF jsig== MIME-Version: 1.0 X-Received: by 10.202.79.149 with SMTP id d143mr3321912oib.16.1421262986116; Wed, 14 Jan 2015 11:16:26 -0800 (PST) Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 11:16:26 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 11:16:26 -0800 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 19:16:29 -0000 On 14 January 2015 at 10:39, Simon Perreault wrote: > I don't disagree. At 50 packets per second you're good for 497 days without > a rekey. Also, didn't renegotiation just get removed from TLS 1.3 or did I > get that wrong? Renegotiation is gone, but rekeying is going to be put back in. From nobody Wed Jan 14 11:37: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 77B551ACED9 for ; Wed, 14 Jan 2015 11:37:19 -0800 (PST) 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 ZGDnVDMSMiEj for ; Wed, 14 Jan 2015 11:37:17 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527651ACED1 for ; Wed, 14 Jan 2015 11:37:17 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z12so9777743lbi.3 for ; Wed, 14 Jan 2015 11:37:15 -0800 (PST) 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=WrcQoaxO0HWUaMIIDUlT/klHKagxgaZS2Q8AdHyEBRQ=; b=P3XEPOK9AQgEj8mkV0TxC3mhj/wwQAxtMMXRDGm3DMt65Fxc6I8d35cmmzRF60CIJ7 tcKKGgmnd2yeU15rWewjd1dv3AjL5M1kij7gws553iHh1zYaEcqM9PsRQ3KM12DVosWP uHFhfN1FgYEXLXJnkYQ+OY5QsCyr8j0JCnwi50mIwx6QefGkmH/X15NBf9V7/MFUSDi1 A6ost6oCDMVWNLFFwRbPbvQ6//4rK4e/UmlBRNmZpbnF/6d+TajzDUdRuA93rWk6W3rh cdTj0C81YqaXlRlJNeuFqj6nGy1a7dZTHmSMHV9R22V8qObPN3lT6J/1OOvcLG5F7n9F 0c1w== X-Gm-Message-State: ALoCoQkQHWkbKDeLECeUQpAOPXBPQFlAPr9RAZNUDn95T6gguWT4TVgILcr9ABSVvayoUj2ML0Ed MIME-Version: 1.0 X-Received: by 10.112.159.136 with SMTP id xc8mr5766264lbb.98.1421264235644; Wed, 14 Jan 2015 11:37:15 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 11:37:15 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 14:37:15 -0500 Message-ID: From: Simon Perreault To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c3dbace5e20c050ca1dd6e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 19:37:19 -0000 --001a11c3dbace5e20c050ca1dd6e Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 2:16 PM, Martin Thomson wrote: > On 14 January 2015 at 10:39, Simon Perreault wrote: > > Also, didn't renegotiation just get removed from TLS 1.3 or did I > > get that wrong? > > Renegotiation is gone, but rekeying is going to be put back in. use_srtp is in ClientHello, and that's renegotiation, right? If so, can you end up with new keys without a new MKI? Simon --001a11c3dbace5e20c050ca1dd6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 14, 2015 at 2:16 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
On 14 January 2015 at 10:39, Simon Perreault <sperreault@jive.com> wrote:
> Also, didn't renegotiation just get removed from TLS 1.3 or did I<= br> > get that wrong?

Renegotiation is gone, but rekeying is going to be put back in.

use_srtp is in ClientHello, and that's renegotiation,= right? If so, can you end up with new keys without a new MKI?

Simon
--001a11c3dbace5e20c050ca1dd6e-- From nobody Wed Jan 14 12:07: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 EDBAE1AD374 for ; Wed, 14 Jan 2015 12:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 CS4qO2tNy4jz for ; Wed, 14 Jan 2015 12:06:56 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0001AD36F for ; Wed, 14 Jan 2015 12:06:56 -0800 (PST) Received: from [192.168.1.200] (p508F28EF.dip0.t-ipconnect.de [80.143.40.239]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CFA0F1C10493A; Wed, 14 Jan 2015 21:06:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: Date: Wed, 14 Jan 2015 21:06:53 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> References: To: Martin Thomson X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 20:06:59 -0000 On 14 Jan 2015, at 18:17, Martin Thomson wrote: > > On 14 January 2015 at 00:49, Michael Tuexen > wrote: >> * DTLS does the PMTUD using DTLS heartbeats >> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >> >> My understanding is the RTCWeb uses the second option as described in >> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 > > SGTM. That means we don't need to reference the DTLS heartbleed extension. It is not referenced in the RTCWeb documents, only in https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 which allows both options. Best regards Michael > From nobody Wed Jan 14 13:49: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 266F71ACD4A for ; Wed, 14 Jan 2015 13:49:57 -0800 (PST) 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 JUKquMobSe9D for ; Wed, 14 Jan 2015 13:49:55 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E03C1ACCEB for ; Wed, 14 Jan 2015 13:49:55 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id uy5so10107873obc.8 for ; Wed, 14 Jan 2015 13:49:54 -0800 (PST) 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=BvOrWAeNDAjKC05FLjQ5h4LRChBsL6tB7xGPaKfKI9c=; b=IPxiO030HOJHVT0Nvpn/xYNe86EXdTT5VeHnn9+sMKeY/JajKvnFGSCczFQx3N5MtV Z66tIP3mulR9VETD5OKfyXCKeHtODrOZo+WAaqhE+StYLPDwMgKi1M+qpFWJ3mDg4Ggk OXVpHreIqoHfK9c3F/lbB2OXInZI4/Nn9jZFo9fcWkFJycIYnU9pXXVqzPwQYRQkg41U oZuH4lFQ/ekntKF14VRaBUqtpe1NbgGk8/JqZpSC/mC+8/ansmaJYodnXJh1x1wjCP3W OncQsbq4Zm7vSUrMkaTfC6BIUajxIphyzBWWp4glHyhpZfB68PrwgwCsDAOFeVFiohse ZJNQ== MIME-Version: 1.0 X-Received: by 10.182.58.102 with SMTP id p6mr3897870obq.84.1421272194546; Wed, 14 Jan 2015 13:49:54 -0800 (PST) Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 13:49:54 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 13:49:54 -0800 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 21:49:57 -0000 On 14 January 2015 at 11:37, Simon Perreault wrote: > use_srtp is in ClientHello, and that's renegotiation, right? If so, can you > end up with new keys without a new MKI? The use_srtp extension really only allows the peers to negotiate which SRTP cipher they want to use, it doesn't really establish the keys. That's the role of the exporter. In theory, you could derive new SRTP keys without doing a renegotiation, but we don't have a defined way of doing that. SRTP is somewhat disconnected from the whole DTLS thing. So I think that the idea is that it continues with the old keys until it receives some signal. Either an MKI bump, or the sequence number discontinuity thing Roman suggests using. Either way, you need some signal *in SRTP* that the keys have changed. And then it's down to assumptions: assume that the DTLS master secret has changed and re-export to get new traffic keys. Of course, you *really* need to check that the master secret has changed or you get into trouble. From nobody Wed Jan 14 14:12: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 F23B01ACDF5 for ; Wed, 14 Jan 2015 14:12:17 -0800 (PST) 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 f_-fvgNeG5r9 for ; Wed, 14 Jan 2015 14:12:15 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA721ACDE2 for ; Wed, 14 Jan 2015 14:12:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7A49F7C3C92 for ; Wed, 14 Jan 2015 23:12:14 +0100 (CET) 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 xwN_vtO1VpJY for ; Wed, 14 Jan 2015 23:12:13 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:9942:e49f:e26a:f368] (unknown [IPv6:2001:470:de0a:27:9942:e49f:e26a:f368]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7140C7C3C91 for ; Wed, 14 Jan 2015 23:12:13 +0100 (CET) Message-ID: <54B6E9BC.2060203@alvestrand.no> Date: Wed, 14 Jan 2015 23:12:12 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> In-Reply-To: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 22:12:18 -0000 Den 14. jan. 2015 21:06, skrev Michael Tuexen: > On 14 Jan 2015, at 18:17, Martin Thomson wrote: >> >> On 14 January 2015 at 00:49, Michael Tuexen >> wrote: >>> * DTLS does the PMTUD using DTLS heartbeats >>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>> >>> My understanding is the RTCWeb uses the second option as described in >>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >> >> SGTM. That means we don't need to reference the DTLS heartbleed extension. > It is not referenced in the RTCWeb documents, only in > https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 > which allows both options. So which document should we put it in that we use the second option? -transport, or a post-last-call update of -datachannel? > > Best regards > Michael >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed Jan 14 14:17: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 B828B1ACE46 for ; Wed, 14 Jan 2015 14:17:24 -0800 (PST) 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 6FDxW2-TT4MT for ; Wed, 14 Jan 2015 14:17:23 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17ECD1ACE3D for ; Wed, 14 Jan 2015 14:17:23 -0800 (PST) Received: by mail-oi0-f54.google.com with SMTP id u20so9569369oif.13 for ; Wed, 14 Jan 2015 14:17:22 -0800 (PST) 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=CODmUKRRYr1A7epYTfPO03VgKuAXPyErBjosZZVjHrk=; b=uHjKjP8PGMCyoxtbQ+DjI930X3QgD6RsTKNmiYg3aNGkRaLVqUnaMXnmWsZBZq/yAK GrNaerK+R77ZygErUfEzs1GzzRbrNePvICpo/Q8cjnWmchXjz7MWRB6s0BOwoFd8KVMS vtIOZyDbo2wUOTtofaRfMQ/ATTqQQJ3WweWSRh+K3E/Q39SHxteDy0/WdfokfAkQcibd g4R5ALm5sCa+Ib+fmjyxsAgXkr3PDqR8eGnjTTwSXLu12nfcqHe11HyEeeX+gZE1UfEm e/wgRPYfyVZrsmW68xF0fT9uSXOhQA/3FMXWyIO8RRI+a3mjDAIE3mw57RJNOmW7ywE0 PUaw== MIME-Version: 1.0 X-Received: by 10.202.75.202 with SMTP id y193mr3773368oia.12.1421273842451; Wed, 14 Jan 2015 14:17:22 -0800 (PST) Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 14:17:22 -0800 (PST) In-Reply-To: <54B6E9BC.2060203@alvestrand.no> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> Date: Wed, 14 Jan 2015 14:17:22 -0800 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 22:17:24 -0000 On 14 January 2015 at 14:12, Harald Alvestrand wrote: > So which document should we put it in that we use the second option? > -transport, or a post-last-call update of -datachannel? I think that -datachannel is most appropriate. It's very late though; if chairs think that it's too late, -transports or even -security-arch (under its DTLS profiling remit) are probably OK places to squeeze it in. From nobody Wed Jan 14 14:40: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 E44381ACEA4 for ; Wed, 14 Jan 2015 14:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 MtlWARKi7htn for ; Wed, 14 Jan 2015 14:40:07 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339921ACE6B for ; Wed, 14 Jan 2015 14:40:07 -0800 (PST) Received: from [192.168.1.200] (p508F28EF.dip0.t-ipconnect.de [80.143.40.239]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9A96F1C104357; Wed, 14 Jan 2015 23:40:05 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <54B6E9BC.2060203@alvestrand.no> Date: Wed, 14 Jan 2015 23:40:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1993) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 22:40:13 -0000 On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >=20 > Den 14. jan. 2015 21:06, skrev Michael Tuexen: >> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>=20 >>> On 14 January 2015 at 00:49, Michael Tuexen >>> wrote: >>>> * DTLS does the PMTUD using DTLS heartbeats >>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>=20 >>>> My understanding is the RTCWeb uses the second option as described = in >>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>=20 >>> SGTM. That means we don't need to reference the DTLS heartbleed = extension. >> It is not referenced in the RTCWeb documents, only in >> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >> which allows both options. >=20 > So which document should we put it in that we use the second option? > -transport, or a post-last-call update of -datachannel? Do we really need a change? We have in=20 https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] using probing messages specified in [RFC4820]. The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for IPv6. In the next revision of = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= there will be the sentence: The path MTU discovery is performed by SCTP when SCTP over DTLS is used for data channels (see Section 4 of [I-D.ietf-rtcweb-data-channel]). Best regards Michael >=20 >>=20 >> Best regards >> Michael >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Wed Jan 14 14:43: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 D3CF91ACECB for ; Wed, 14 Jan 2015 14:43:31 -0800 (PST) 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 qkUGM4LEy8Om for ; Wed, 14 Jan 2015 14:43:30 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC591ACEC8 for ; Wed, 14 Jan 2015 14:43:28 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id gd6so10794752lab.3 for ; Wed, 14 Jan 2015 14:43:27 -0800 (PST) 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=RjlM/eDAMMjZOEaKbQuvKFZHEc8Ahva4sDkx3UvYvFo=; b=NBTLqFUv1Q0sA5Hpq0kvcBRJNpjkpeer/uT5HbSO4F+n++/xsGh5yOM254JzMNx3lw sVcFoTkbLDQ8y1IuBwlwT8Sq/S1otaEQwicrmarwJ2Y/G944QIi/d50RMpZrpfWgnSI6 9UDj7ba+BRyA8mEVyaS36I9MhUFjQhPGBRNuyWrGxSafeYTRw0M+6jkukILqJ4f55Qif L1sHcqM0/Ol5uvEqxohlHtsANI058Mk/wQ2qzdVqvojSDu1dCF4UA1NlazF86NUUJ0xH BDoxUKIyvSe/LRswQaByPUswdI9brOCixvvmMe2zGwZJje+r6d86trriypg0zGkPy2e7 EaVQ== X-Gm-Message-State: ALoCoQnnfauaz801OLHR9jeLLQt6Ui7itTosbiKzE7yluqDlc29nECH3l8VLbMyhtCyOOc32Ac/l MIME-Version: 1.0 X-Received: by 10.112.164.102 with SMTP id yp6mr6378501lbb.15.1421275407122; Wed, 14 Jan 2015 14:43:27 -0800 (PST) Received: by 10.25.84.145 with HTTP; Wed, 14 Jan 2015 14:43:27 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 17:43:27 -0500 Message-ID: From: Simon Perreault To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c263f4c518c8050ca47791 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 22:43:32 -0000 --001a11c263f4c518c8050ca47791 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 14, 2015 at 4:49 PM, Martin Thomson wrote: > > use_srtp is in ClientHello, and that's renegotiation, right? If so, can > you > > end up with new keys without a new MKI? > > The use_srtp extension really only allows the peers to negotiate which > SRTP cipher they want to use, it doesn't really establish the keys. > That's the role of the exporter. Ok.... but I think you may have missed my point. My point is that srtp_mki, being part of use_srtp, only gets renewed upon renegotiation. So if you just export new keying material without renegotiating, you don't have a new MKI for those new keys you just exported. So removing renegotiation effectively makes srtp_mki useless. Unless I misunderstand the difference between renegotiation and rekey... Simon --001a11c263f4c518c8050ca47791 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jan 14, 2015 at 4:49 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
> use_srtp is in ClientHello, and that's renegotiation, right?= If so, can you
> end up with new keys without a new MKI?

The use_srtp extension really only allows the peers to negotiate whi= ch
SRTP cipher they want to use, it doesn't really establish the keys.
That's the role of the exporter.

Ok.... but I thi= nk you may have missed my point. My point is that srtp_mki, being part of u= se_srtp, only gets renewed upon renegotiation. So if you just export new ke= ying material without renegotiating, you don't have a new MKI for those= new keys you just exported. So removing renegotiation effectively makes sr= tp_mki useless. Unless I misunderstand the difference between renegotiation= and rekey...

Simon
--001a11c263f4c518c8050ca47791-- From nobody Wed Jan 14 14:52: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 9F3851ACED8 for ; Wed, 14 Jan 2015 14:52:42 -0800 (PST) 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 McKWzBpkn1QK for ; Wed, 14 Jan 2015 14:52:39 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E601AD072 for ; Wed, 14 Jan 2015 14:51:36 -0800 (PST) Received: by mail-oi0-f49.google.com with SMTP id a141so9735697oig.8 for ; Wed, 14 Jan 2015 14:51:36 -0800 (PST) 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=Q3Pcba2koJ3AsAQlWHKqewz+BvkExPqKbdvcAlLuQtA=; b=dV+mbgtvSd+hcgaR1gQx5OO1CI6dQelB+xopcebEefyOq/1EMLBEqPBYmMXdZMKei7 DYLLonM6TVk5L4h4EFRlRtaVxN1WbDJWM7OPXjoBOFQWUWOrznTzIGwTEWcnHHaZ38WM Egi7n/7d1Plp8tSdEXJO4SDIgp08ETNIA/47ii0bQldNUmK410BQwDSuTbLRnjwe1gRK L3ZuRpCCqgQs8gTnu7FmPdHBHktwx6vDvteSb4NxtzIuqDo8mYWRh8TU4m3imnUROFJn DzXQgtrydGkdCiuWx90thsZ8CBS3iaiswVcv547EEJfTrqlYvKn83+2+iHXCzpPlIbsJ iM0g== MIME-Version: 1.0 X-Received: by 10.202.79.149 with SMTP id d143mr3832461oib.16.1421275895980; Wed, 14 Jan 2015 14:51:35 -0800 (PST) Received: by 10.202.226.136 with HTTP; Wed, 14 Jan 2015 14:51:35 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Jan 2015 14:51:35 -0800 Message-ID: From: Martin Thomson To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about srtp_mki in DTLS/SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 22:52:42 -0000 On 14 January 2015 at 14:43, Simon Perreault wrote: > Ok.... but I think you may have missed my point. My point is that srtp_mki, > being part of use_srtp, only gets renewed upon renegotiation. So if you just > export new keying material without renegotiating, you don't have a new MKI > for those new keys you just exported. So removing renegotiation effectively > makes srtp_mki useless. Unless I misunderstand the difference between > renegotiation and rekey... OK, my bad. Yes, the srtp_mki field in the DTLS handshake is effectively useless without renegotiation. If you rekey without renegotiation, you will need a new scheme for signaling in SRTP proper when those changes were applied (like Roman's seqno hack). From nobody Wed Jan 14 15:19: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 E27EF1B2A65 for ; Wed, 14 Jan 2015 15:19:12 -0800 (PST) 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 zT76HNDTJeCq for ; Wed, 14 Jan 2015 15:19:09 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD7F1B2A64 for ; Wed, 14 Jan 2015 15:19:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id AD3087C3BC1; Thu, 15 Jan 2015 00:19:08 +0100 (CET) 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 CfVUXzyhiKdM; Thu, 15 Jan 2015 00:19:07 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:9942:e49f:e26a:f368] (unknown [IPv6:2001:470:de0a:27:9942:e49f:e26a:f368]) by mork.alvestrand.no (Postfix) with ESMTPSA id 177E57C0160; Thu, 15 Jan 2015 00:19:07 +0100 (CET) Message-ID: <54B6F96A.4060507@alvestrand.no> Date: Thu, 15 Jan 2015 00:19:06 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Michael Tuexen References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> In-Reply-To: <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 14 Jan 2015 23:19:13 -0000 Den 14. jan. 2015 23:40, skrev Michael Tuexen: > On 14 Jan 2015, at 23:12, Harald Alvestrand wrote: >> >> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>> On 14 Jan 2015, at 18:17, Martin Thomson wrote: >>>> >>>> On 14 January 2015 at 00:49, Michael Tuexen >>>> wrote: >>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>> >>>>> My understanding is the RTCWeb uses the second option as described in >>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>> >>>> SGTM. That means we don't need to reference the DTLS heartbleed extension. >>> It is not referenced in the RTCWeb documents, only in >>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>> which allows both options. >> >> So which document should we put it in that we use the second option? >> -transport, or a post-last-call update of -datachannel? > Do we really need a change? We have in > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 > Incoming ICMP or ICMPv6 messages can't be processed by the SCTP > layer, since there is no way to identify the corresponding > association. Therefore SCTP MUST support performing Path MTU > discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] > using probing messages specified in [RFC4820]. The initial Path MTU > at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for > IPv6. Good! I misunderstood what "it is not referenced" referred to above. > > In the next revision of > https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4 > there will be the sentence: > The path MTU discovery is performed by SCTP when SCTP over DTLS is > used for data channels (see Section 4 of > [I-D.ietf-rtcweb-data-channel]). I think the section number is wrong - section 4 of data-channel is requirements. (unless revised). > > Best regards > Michael >> >>> >>> Best regards >>> Michael >>>> >>> >>> _______________________________________________ >>> 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 Jan 14 20:45: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 9304D1ACEE6 for ; Wed, 14 Jan 2015 20:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[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 KpcRwdgE2kxz for ; Wed, 14 Jan 2015 20:45:52 -0800 (PST) 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 9F0141ACEE8 for ; Wed, 14 Jan 2015 20:45:51 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-6f-54b745fd6069 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6C.07.04484.DF547B45; Thu, 15 Jan 2015 05:45:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 05:45:48 +0100 From: Christer Holmberg To: Michael Tuexen , Harald Alvestrand Thread-Topic: [rtcweb] Question about support for RFC 6520 DTLS heartbeat Thread-Index: AQHQL5UtWHqcwktsB0yKryagMbLO8Zy/PiwAgACNzgCAAC9fgIAAIwMAgAAHyQCAAHbzWA== Date: Thu, 15 Jan 2015 04:45:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no>, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> In-Reply-To: <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D63922AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvje5f1+0hBo8WSlsc6+tis7jYtITR Yu2/dnYHZo8rE66weixZ8pPJY0PLDqYA5igum5TUnMyy1CJ9uwSujIbGHYwFk10q1h7vYW5g XGHdxcjJISFgItHz7CUbhC0mceHeeiCbi0NI4AijxJTpt5lAEkICSxgl1rxW6mLk4GATsJDo /qcNEhYRSJQ49vYPK4jNLKAucWfxOXYQW1jAQ+LdmtWsEDWeEi0Tp7FB2GESczYeZwMZwyKg KtF1yRUkzCvgKzFt3VJWiLUvmST+/DjKClLDKeAqsXASI0gNI9Bp30+tYYJYJS7R9GUlK8TJ AhJL9pxnhrBFJV4+/gfWyiyQLzGpTRVivKDEyZlPWCYwisxC0j0LoWoWkiqIEgOJL+9vQ9na EssWvmaGsPUlut+fZkIWX8DIvopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMMYObvltsIPx 5XPHQ4wCHIxKPLwbbm8NEWJNLCuuzD3EKM3BoiTOm+ewIURIID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QD48LW+/WlZRuqOU8+12eVTFOuClrE8ZDJ0Jf/1UkVzkteotvqXu49/9W2TbzziG9q NE/LzDd3bbZe4zpUXStQXRQ6rfj/l97YUr5VKx4uqH2YleUSsSamJsdVoUKsrfBW6SrrJZva N79+fOB1unHSxvqKL087Z/f93ePzpctb4PVbj7bIovtmSizFGYmGWsxFxYkA/7daoJICAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Jan 2015 04:45:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D63922AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I don't think the sctp-dtls-encaps draft shall contain data channel specifi= c procedures. I agree with Martin that the best place is the data channel draft. Regards, Christer Sent from my Windows Phone ________________________________ From: Michael Tuexen Sent: =FD15/=FD01/=FD2015 00:40 To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat On 14 Jan 2015, at 23:12, Harald Alvestrand wrote: > > Den 14. jan. 2015 21:06, skrev Michael Tuexen: >> On 14 Jan 2015, at 18:17, Martin Thomson wrot= e: >>> >>> On 14 January 2015 at 00:49, Michael Tuexen >>> wrote: >>>> * DTLS does the PMTUD using DTLS heartbeats >>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>> >>>> My understanding is the RTCWeb uses the second option as described in >>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>> >>> SGTM. That means we don't need to reference the DTLS heartbleed extens= ion. >> It is not referenced in the RTCWeb documents, only in >> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >> which allows both options. > > So which document should we put it in that we use the second option? > -transport, or a post-last-call update of -datachannel? Do we really need a change? We have in https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] using probing messages specified in [RFC4820]. The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for IPv6. In the next revision of https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4 there will be the sentence: The path MTU discovery is performed by SCTP when SCTP over DTLS is used for data channels (see Section 4 of [I-D.ietf-rtcweb-data-channel]). Best regards Michael > >> >> Best regards >> Michael >>> >> >> _______________________________________________ >> 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 --_000_7594FB04B1934943A5C02806D1A2204B1D63922AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I don't think the sctp-dtls-encaps draft shall contain data channel specifi= c procedures.

I agree with Martin that the best place is the data channel draft.

Regards,

Christer

Sent from my Windows Phone
From: Michael Tuexen Sent: =FD15= /=FD01/=FD2015 00:40
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [= rtcweb] Question about support for RFC 6520 DTLS heartbeat

On 14 Jan 2015, at 23:12, Harald Alvestrand <ha= rald@alvestrand.no> wrote:
>
> Den 14. jan. 2015 21:06, skrev Michael Tuexen:
>> On 14 Jan 2015, at 18:17, Martin Thomson <martin.thomson@gmail.= com> wrote:
>>>
>>> On 14 January 2015 at 00:49, Michael Tuexen
>>> <Michael.Tuexen@lurchi.franken.de> wrote:
>>>> * DTLS does the PMTUD using DTLS heartbeats
>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chu= nks
>>>>
>>>> My understanding is the RTCWeb uses the second option as d= escribed in
>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5<= br> >>>
>>> SGTM.  That means we don't need to reference the DTLS hea= rtbleed extension.
>> It is not referenced in the RTCWeb documents, only in
>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07=
>> which allows both options.
>
> So which document should we put it in that we use the second option? > -transport, or a post-last-call update of -datachannel?
Do we really need a change? We have in
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect= ion-5
   Incoming ICMP or ICMPv6 messages can't be processed by the SCT= P
   layer, since there is no way to identify the corresponding
   association.  Therefore SCTP MUST support performing Path= MTU
   discovery without relying on ICMP or ICMPv6 as specified in [R= FC4821]
   using probing messages specified in [RFC4820].  The initi= al Path MTU
   at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280= for
   IPv6.

In the next revision of
https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-0= 7#section-4
there will be the sentence:
   The path MTU discovery is performed by SCTP when SCTP over DTL= S is
   used for data channels (see Section 4 of
   [I-D.ietf-rtcweb-data-channel]).

Best regards
Michael
>
>>
>> Best regards
>> Michael
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.o= rg/mailman/listinfo/rtcweb
 --_000_7594FB04B1934943A5C02806D1A2204B1D63922AESESSMB209erics_-- From nobody Thu Jan 15 00:39: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 AF10F1B2BB0 for ; Thu, 15 Jan 2015 00:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 6cZtr792T8nQ for ; Thu, 15 Jan 2015 00:39:15 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091B51B2BA7 for ; Thu, 15 Jan 2015 00:39:14 -0800 (PST) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id F2BF21C104357; Thu, 15 Jan 2015 09:39:11 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <54B6F96A.4060507@alvestrand.no> Date: Thu, 15 Jan 2015 09:39:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E6A9D54-199B-4593-8A55-68C35BA3672D@lurchi.franken.de> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <54B6F96A.4060507@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1993) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Jan 2015 08:39:17 -0000 On 15 Jan 2015, at 00:19, Harald Alvestrand = wrote: >=20 > Den 14. jan. 2015 23:40, skrev Michael Tuexen: >> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>=20 >>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>=20 >>>>> On 14 January 2015 at 00:49, Michael Tuexen >>>>> wrote: >>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>>>=20 >>>>>> My understanding is the RTCWeb uses the second option as = described in >>>>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>>>=20 >>>>> SGTM. That means we don't need to reference the DTLS heartbleed = extension. >>>> It is not referenced in the RTCWeb documents, only in >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>> which allows both options. >>>=20 >>> So which document should we put it in that we use the second option? >>> -transport, or a post-last-call update of -datachannel? >> Do we really need a change? We have in=20 >> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >> layer, since there is no way to identify the corresponding >> association. Therefore SCTP MUST support performing Path MTU >> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >> using probing messages specified in [RFC4820]. The initial Path = MTU >> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >> IPv6. >=20 > Good! I misunderstood what "it is not referenced" referred to above. >=20 >>=20 >> In the next revision of >> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= >> there will be the sentence: >> The path MTU discovery is performed by SCTP when SCTP over DTLS is >> used for data channels (see Section 4 of >> [I-D.ietf-rtcweb-data-channel]). >=20 > I think the section number is wrong - section 4 of data-channel is > requirements. (unless revised). That is correct. I guess Gorry (who suggested the text) had Req. 9 in = mind. But we can change the reference to Section 5 if you prefer. Best regards Michael >=20 >=20 >=20 >>=20 >> Best regards >> Michael >>>=20 >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >=20 >=20 From nobody Thu Jan 15 00:42: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 1E0A11A89B4 for ; Thu, 15 Jan 2015 00:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 yJm4Rnrj8Rvo for ; Thu, 15 Jan 2015 00:41:57 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BA91A8701 for ; Thu, 15 Jan 2015 00:41:57 -0800 (PST) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DFB991C104357; Thu, 15 Jan 2015 09:41:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> Date: Thu, 15 Jan 2015 09:41:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Jan 2015 08:41:59 -0000 > On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >=20 > Hi, >=20 > I don't think the sctp-dtls-encaps draft shall contain data channel = specific procedures. It doesn't. It only makes clear which of the two options are used in = RTCWeb. >=20 > I agree with Martin that the best place is the data channel draft. So you think the text in the data channel draft is not enough? It is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over DTLS = is used in RTCWeb.=20 Best regards Michael >=20 > Regards, >=20 > Christer >=20 > Sent from my Windows Phone > From: Michael Tuexen > Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 > To: Harald Alvestrand > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >=20 > On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: > >=20 > > Den 14. jan. 2015 21:06, skrev Michael Tuexen: > >> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: > >>>=20 > >>> On 14 January 2015 at 00:49, Michael Tuexen > >>> wrote: > >>>> * DTLS does the PMTUD using DTLS heartbeats > >>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks > >>>>=20 > >>>> My understanding is the RTCWeb uses the second option as = described in > >>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 > >>>=20 > >>> SGTM. That means we don't need to reference the DTLS heartbleed = extension. > >> It is not referenced in the RTCWeb documents, only in > >> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 > >> which allows both options. > >=20 > > So which document should we put it in that we use the second option? > > -transport, or a post-last-call update of -datachannel? > Do we really need a change? We have in=20 > = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 > Incoming ICMP or ICMPv6 messages can't be processed by the SCTP > layer, since there is no way to identify the corresponding > association. Therefore SCTP MUST support performing Path MTU > discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] > using probing messages specified in [RFC4820]. The initial Path = MTU > at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for > IPv6. >=20 > In the next revision of > = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= > there will be the sentence: > The path MTU discovery is performed by SCTP when SCTP over DTLS is > used for data channels (see Section 4 of > [I-D.ietf-rtcweb-data-channel]). >=20 > Best regards > Michael > >=20 > >>=20 > >> Best regards > >> Michael > >>>=20 > >>=20 > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >>=20 > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jan 15 00:45: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 0F0F71B2BBA for ; Thu, 15 Jan 2015 00:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlaDZpi_AChE for ; Thu, 15 Jan 2015 00:45:47 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184821B2BBF for ; Thu, 15 Jan 2015 00:45:42 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 0614887C1AE5D; Thu, 15 Jan 2015 08:45:39 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t0F8jZiE030718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Jan 2015 09:45:40 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 09:45:39 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Michael Tuexen , Christer Holmberg Thread-Topic: [rtcweb] Question about support for RFC 6520 DTLS heartbeat Thread-Index: AQHQL5UuE1eHOSDm9ESYZIL8Z0+PT5y/PiwAgACNzgCAAC9fgIAAIwMAgAAHyQCAAGYugIAAQfqAgAARNpA= Date: Thu, 15 Jan 2015 08:45:38 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Jan 2015 08:45:49 -0000 TWljaGFlbCwNCg0KbmVpdGhlciBvYnZpb3VzIG5vciBjbGVhciB0byBtZSB3aHkgU0NUUCBpcyBy ZXNwb25zaWJsZSBmb3IgUE1UVUQgaW4gYSBzdGFjayBzdWNoIGFzIHtTQ1RQL0RUTFMvTDQvSVB9 IGxheWVyaW5nLg0KUGVyaGFwcyBJIG1pc3Mgc3RoLCBidXQgSSB3b3VsZCBhcHByZWNpYXRlIG1v cmUgdGV4dC4NCg0KVGhhbmtzLA0KQWxicmVjaHQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgTWljaGFlbCBUdWV4ZW4NClNlbnQ6IERvbm5lcnN0YWcsIDE1LiBKYW51YXIgMjAxNSAw OTo0Mg0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogcnRjd2ViQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3J0Y3dlYl0gUXVlc3Rpb24gYWJvdXQgc3VwcG9ydCBmb3IgUkZDIDY1MjAgRFRMUyBo ZWFydGJlYXQNCg0KPiBPbiAxNSBKYW4gMjAxNSwgYXQgMDU6NDUsIENocmlzdGVyIEhvbG1iZXJn IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0K PiBJIGRvbid0IHRoaW5rIHRoZSBzY3RwLWR0bHMtZW5jYXBzIGRyYWZ0IHNoYWxsIGNvbnRhaW4g ZGF0YSBjaGFubmVsIHNwZWNpZmljIHByb2NlZHVyZXMuDQpJdCBkb2Vzbid0LiBJdCBvbmx5IG1h a2VzIGNsZWFyIHdoaWNoIG9mIHRoZSB0d28gb3B0aW9ucyBhcmUgdXNlZCBpbiBSVENXZWIuDQo+ IA0KPiBJIGFncmVlIHdpdGggTWFydGluIHRoYXQgdGhlIGJlc3QgcGxhY2UgaXMgdGhlIGRhdGEg Y2hhbm5lbCBkcmFmdC4NClNvIHlvdSB0aGluayB0aGUgdGV4dCBpbiB0aGUgZGF0YSBjaGFubmVs IGRyYWZ0IGlzIG5vdCBlbm91Z2g/IEl0IGlzIGFuZCB3YXMgY2xlYXIgdG8gbWUgdGhhdCBTQ1RQ IGRvZXMgdGhlIFBNVFVELCBub3QgRFRMUywgd2hlbiBTQ1RQIG92ZXIgRFRMUyBpcyB1c2VkIGlu IFJUQ1dlYi4gDQoNCkJlc3QgcmVnYXJkcw0KTWljaGFlbA0KPiANCj4gUmVnYXJkcywNCj4gDQo+ IENocmlzdGVyDQo+IA0KPiBTZW50IGZyb20gbXkgV2luZG93cyBQaG9uZQ0KPiBGcm9tOiBNaWNo YWVsIFR1ZXhlbg0KPiBTZW50OiDigI4xNS/igI4wMS/igI4yMDE1IDAwOjQwDQo+IFRvOiBIYXJh bGQgQWx2ZXN0cmFuZA0KPiBDYzogcnRjd2ViQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcnRj d2ViXSBRdWVzdGlvbiBhYm91dCBzdXBwb3J0IGZvciBSRkMgNjUyMCBEVExTIA0KPiBoZWFydGJl YXQNCj4gDQo+IE9uIDE0IEphbiAyMDE1LCBhdCAyMzoxMiwgSGFyYWxkIEFsdmVzdHJhbmQgPGhh cmFsZEBhbHZlc3RyYW5kLm5vPiB3cm90ZToNCj4gPiANCj4gPiBEZW4gMTQuIGphbi4gMjAxNSAy MTowNiwgc2tyZXYgTWljaGFlbCBUdWV4ZW46DQo+ID4+IE9uIDE0IEphbiAyMDE1LCBhdCAxODox NywgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+ PiANCj4gPj4+IE9uIDE0IEphbnVhcnkgMjAxNSBhdCAwMDo0OSwgTWljaGFlbCBUdWV4ZW4gDQo+ ID4+PiA8TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGU+IHdyb3RlOg0KPiA+Pj4+ICog RFRMUyBkb2VzIHRoZSBQTVRVRCB1c2luZyBEVExTIGhlYXJ0YmVhdHMNCj4gPj4+PiAqIFNDVFAg ZG9lcyB0aGUgUE1UVUQgdXNpbmcgU0NUUCBIRUFSVEJFQVQgYW5kIFBBRERJTkcgY2h1bmtzDQo+ ID4+Pj4gDQo+ID4+Pj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGUgUlRDV2ViIHVzZXMgdGhlIHNl Y29uZCBvcHRpb24gYXMgDQo+ID4+Pj4gZGVzY3JpYmVkIGluDQo+ID4+Pj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsLTEzI3NlY3QNCj4g Pj4+PiBpb24tNQ0KPiA+Pj4gDQo+ID4+PiBTR1RNLiAgVGhhdCBtZWFucyB3ZSBkb24ndCBuZWVk IHRvIHJlZmVyZW5jZSB0aGUgRFRMUyBoZWFydGJsZWVkIGV4dGVuc2lvbi4NCj4gPj4gSXQgaXMg bm90IHJlZmVyZW5jZWQgaW4gdGhlIFJUQ1dlYiBkb2N1bWVudHMsIG9ubHkgaW4NCj4gPj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctc2N0cC1kdGxzLWVuY2Fw cy0wNw0KPiA+PiB3aGljaCBhbGxvd3MgYm90aCBvcHRpb25zLg0KPiA+IA0KPiA+IFNvIHdoaWNo IGRvY3VtZW50IHNob3VsZCB3ZSBwdXQgaXQgaW4gdGhhdCB3ZSB1c2UgdGhlIHNlY29uZCBvcHRp b24/DQo+ID4gLXRyYW5zcG9ydCwgb3IgYSBwb3N0LWxhc3QtY2FsbCB1cGRhdGUgb2YgLWRhdGFj aGFubmVsPw0KPiBEbyB3ZSByZWFsbHkgbmVlZCBhIGNoYW5nZT8gV2UgaGF2ZSBpbg0KPiBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsLTEz I3NlY3Rpb24tNQ0KPiAgICBJbmNvbWluZyBJQ01QIG9yIElDTVB2NiBtZXNzYWdlcyBjYW4ndCBi ZSBwcm9jZXNzZWQgYnkgdGhlIFNDVFANCj4gICAgbGF5ZXIsIHNpbmNlIHRoZXJlIGlzIG5vIHdh eSB0byBpZGVudGlmeSB0aGUgY29ycmVzcG9uZGluZw0KPiAgICBhc3NvY2lhdGlvbi4gIFRoZXJl Zm9yZSBTQ1RQIE1VU1Qgc3VwcG9ydCBwZXJmb3JtaW5nIFBhdGggTVRVDQo+ICAgIGRpc2NvdmVy eSB3aXRob3V0IHJlbHlpbmcgb24gSUNNUCBvciBJQ01QdjYgYXMgc3BlY2lmaWVkIGluIFtSRkM0 ODIxXQ0KPiAgICB1c2luZyBwcm9iaW5nIG1lc3NhZ2VzIHNwZWNpZmllZCBpbiBbUkZDNDgyMF0u ICBUaGUgaW5pdGlhbCBQYXRoIE1UVQ0KPiAgICBhdCB0aGUgSVAgbGF5ZXIgU0hPVUxEIE5PVCBl eGNlZWQgMTIwMCBieXRlcyBmb3IgSVB2NCBhbmQgMTI4MCBmb3INCj4gICAgSVB2Ni4NCj4gDQo+ IEluIHRoZSBuZXh0IHJldmlzaW9uIG9mDQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRzdndnLXNjdHAtZHRscy1lbmNhcHMtMDcjc2VjdGkNCj4gb24tNA0KPiB0aGVy ZSB3aWxsIGJlIHRoZSBzZW50ZW5jZToNCj4gICAgVGhlIHBhdGggTVRVIGRpc2NvdmVyeSBpcyBw ZXJmb3JtZWQgYnkgU0NUUCB3aGVuIFNDVFAgb3ZlciBEVExTIGlzDQo+ICAgIHVzZWQgZm9yIGRh dGEgY2hhbm5lbHMgKHNlZSBTZWN0aW9uIDQgb2YNCj4gICAgW0ktRC5pZXRmLXJ0Y3dlYi1kYXRh LWNoYW5uZWxdKS4NCj4gDQo+IEJlc3QgcmVnYXJkcw0KPiBNaWNoYWVsDQo+ID4gDQo+ID4+IA0K PiA+PiBCZXN0IHJlZ2FyZHMNCj4gPj4gTWljaGFlbA0KPiA+Pj4gDQo+ID4+IA0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBydGN3ZWIg bWFpbGluZyBsaXN0DQo+ID4+IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+PiANCj4gPiANCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHJ0Y3dlYiBtYWlsaW5n IGxpc3QNCj4gPiBydGN3ZWJAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPiBydGN3ZWJA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dl YiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWINCg== From nobody Thu Jan 15 00:56: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 D5B9A1AD1EE for ; Thu, 15 Jan 2015 00:56:30 -0800 (PST) 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 02T2lt50835X for ; Thu, 15 Jan 2015 00:56:29 -0800 (PST) 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 4E0A21A8701 for ; Thu, 15 Jan 2015 00:56:28 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-4b-54b780ba2ff8 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.CD.04231.AB087B45; Thu, 15 Jan 2015 09:56:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 09:56:25 +0100 From: Christer Holmberg To: Michael Tuexen Thread-Topic: [rtcweb] Question about support for RFC 6520 DTLS heartbeat Thread-Index: AQHQL5UtWHqcwktsB0yKryagMbLO8Zy/PiwAgACNzgCAAC9fgIAAIwMAgAAHyQCAAHbzWIAAMTWAgAATsLA= Date: Thu, 15 Jan 2015 08:56:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6397F5@ESESSMB209.ericsson.se> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <,<7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@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.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje6uhu0hBovvCVoc6+tis7jYtITR Yu2/dnYHZo8rE66weixZ8pPJY0PLDqYA5igum5TUnMyy1CJ9uwSujBkdX9gK2tQqJq1Yy9jA 2KHaxcjJISFgInHg0mY2CFtM4sK99UA2F4eQwBFGiUVPf7GDJIQEljBK/LgS0MXIwcEmYCHR /U8bJCwiYCpxcPk8FhCbWSBYordrMiuILSzgIfFuzWpWiBpPiZaJ09gg7CSJfz8+gI1kEVCV eLPpPBOIzSvgK7Hl/RomiL0fmCV2TOoDG8op4Crx8eIDsAZGoOO+n1rDBLFMXOLWk/lMEEcL SCzZc54ZwhaVePn4HyuErSjx8dU+RpCbmQU0Jdbv0odoVZSY0v2QHWKvoMTJmU9YJjCKzUIy dRZCxywkHbOQdCxgZFnFKFqcWlycm25krJdalJlcXJyfp5eXWrKJERhPB7f81t3BuPq14yFG AQ5GJR7egtTtIUKsiWXFlbmHGKU5WJTEefMcNoQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YGRZtvWbxCaLRaIffqnc3N7feHjV/DPvH66Z+eS2s5lB9QmfTj53Po2fSunu+gUfioKsH87V smln+dyVlXVv/tIEB0v2mGC9wuW8+sEhWvv2NEXfZPLZU18577Ciww01JvWyC5ZPqj+nip+6 8OjD9kttp58EV639eGa9y4uvJf1ytsn9gdv3hyuxFGckGmoxFxUnAgAKS5NpiAIAAA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Jan 2015 08:56:31 -0000 SGksDQoNCj4+IEkgZG9uJ3QgdGhpbmsgdGhlIHNjdHAtZHRscy1lbmNhcHMgZHJhZnQgc2hhbGwg Y29udGFpbiBkYXRhIGNoYW5uZWwgc3BlY2lmaWMgcHJvY2VkdXJlcy4NCj4gSXQgZG9lc24ndC4g SXQgb25seSBtYWtlcyBjbGVhciB3aGljaCBvZiB0aGUgdHdvIG9wdGlvbnMgYXJlIHVzZWQgaW4g UlRDV2ViLg0KDQpJZiBpdCBuZWVkcyB0byBiZSBjbGVhciwgaXQgc2hvdWxkIGJlIGluIGFuIFJU Q1dlYiBzcGVjLg0KDQpGb3Igc3VyZSwgeW91IGNhbiBzdGF0ZSBpdCBhcyBhbiBFWEFNUExFIGlu IHRoZSBlbmNhcHMgZHJhZnQgaWYgeW91IHdhbnQgdG8uIEJ1dCwgYW4gUlRDV2ViIGltcGxlbWVu dGVyIHNob3VsZCBub3QgaGF2ZSB0byByZWFkIHRoZSBlbmNhcHMgZHJhZnQgaW4gb3JkZXIgdG8g ZmlndXJlIG91dCB3aGljaCBvcHRpb24gaXMgdXNlZCAtIHRoYXQgbmVlZHMgdG8gYmUgY2xlYXIg aW4gYW4gUlRDV2ViIHNwZWMuDQoNCj4+IEkgYWdyZWUgd2l0aCBNYXJ0aW4gdGhhdCB0aGUgYmVz dCBwbGFjZSBpcyB0aGUgZGF0YSBjaGFubmVsIGRyYWZ0Lg0KPiBTbyB5b3UgdGhpbmsgdGhlIHRl eHQgaW4gdGhlIGRhdGEgY2hhbm5lbCBkcmFmdCBpcyBub3QgZW5vdWdoPyBJdCBpcyBhbmQgd2Fz IGNsZWFyIHRvIG1lIHRoYXQgU0NUUCBkb2VzIHRoZSBQTVRVRCwgbm90IERUTFMsIHdoZW4gU0NU UCBvdmVyIERUTFMgaXMgdXNlZCBpbiBSVENXZWIuIA0KDQpJIGRpZG4ndCBjaGVjayB0aGUgdGV4 dCBpbiB0aGUgZGF0YSBjaGFubmVsIGRyYWZ0IDopIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIEkg YXNzdW1lZCB0aGF0IHNvbWUgdGV4dCBpcyBtaXNzaW5nLCBhbmQgaXMgbmVlZGVkIHNvbWV3aGVy ZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KPiBTZW50IGZyb20gbXkgV2luZG93 cyBQaG9uZQ0KPiBGcm9tOiBNaWNoYWVsIFR1ZXhlbg0KPiBTZW50OiDigI4xNS/igI4wMS/igI4y MDE1IDAwOjQwDQo+IFRvOiBIYXJhbGQgQWx2ZXN0cmFuZA0KPiBDYzogcnRjd2ViQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBRdWVzdGlvbiBhYm91dCBzdXBwb3J0IGZvciBSRkMg NjUyMCBEVExTIA0KPiBoZWFydGJlYXQNCj4gDQo+IE9uIDE0IEphbiAyMDE1LCBhdCAyMzoxMiwg SGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPiB3cm90ZToNCj4gPiANCj4g PiBEZW4gMTQuIGphbi4gMjAxNSAyMTowNiwgc2tyZXYgTWljaGFlbCBUdWV4ZW46DQo+ID4+IE9u IDE0IEphbiAyMDE1LCBhdCAxODoxNywgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT4gd3JvdGU6DQo+ID4+PiANCj4gPj4+IE9uIDE0IEphbnVhcnkgMjAxNSBhdCAwMDo0 OSwgTWljaGFlbCBUdWV4ZW4gDQo+ID4+PiA8TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4u ZGU+IHdyb3RlOg0KPiA+Pj4+ICogRFRMUyBkb2VzIHRoZSBQTVRVRCB1c2luZyBEVExTIGhlYXJ0 YmVhdHMNCj4gPj4+PiAqIFNDVFAgZG9lcyB0aGUgUE1UVUQgdXNpbmcgU0NUUCBIRUFSVEJFQVQg YW5kIFBBRERJTkcgY2h1bmtzDQo+ID4+Pj4gDQo+ID4+Pj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0 aGUgUlRDV2ViIHVzZXMgdGhlIHNlY29uZCBvcHRpb24gYXMgDQo+ID4+Pj4gZGVzY3JpYmVkIGlu DQo+ID4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZGF0 YS1jaGFubmVsLTEzI3NlY3QNCj4gPj4+PiBpb24tNQ0KPiA+Pj4gDQo+ID4+PiBTR1RNLiAgVGhh dCBtZWFucyB3ZSBkb24ndCBuZWVkIHRvIHJlZmVyZW5jZSB0aGUgRFRMUyBoZWFydGJsZWVkIGV4 dGVuc2lvbi4NCj4gPj4gSXQgaXMgbm90IHJlZmVyZW5jZWQgaW4gdGhlIFJUQ1dlYiBkb2N1bWVu dHMsIG9ubHkgaW4NCj4gPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt dHN2d2ctc2N0cC1kdGxzLWVuY2Fwcy0wNw0KPiA+PiB3aGljaCBhbGxvd3MgYm90aCBvcHRpb25z Lg0KPiA+IA0KPiA+IFNvIHdoaWNoIGRvY3VtZW50IHNob3VsZCB3ZSBwdXQgaXQgaW4gdGhhdCB3 ZSB1c2UgdGhlIHNlY29uZCBvcHRpb24/DQo+ID4gLXRyYW5zcG9ydCwgb3IgYSBwb3N0LWxhc3Qt Y2FsbCB1cGRhdGUgb2YgLWRhdGFjaGFubmVsPw0KPiBEbyB3ZSByZWFsbHkgbmVlZCBhIGNoYW5n ZT8gV2UgaGF2ZSBpbg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y dGN3ZWItZGF0YS1jaGFubmVsLTEzI3NlY3Rpb24tNQ0KPiAgICBJbmNvbWluZyBJQ01QIG9yIElD TVB2NiBtZXNzYWdlcyBjYW4ndCBiZSBwcm9jZXNzZWQgYnkgdGhlIFNDVFANCj4gICAgbGF5ZXIs IHNpbmNlIHRoZXJlIGlzIG5vIHdheSB0byBpZGVudGlmeSB0aGUgY29ycmVzcG9uZGluZw0KPiAg ICBhc3NvY2lhdGlvbi4gIFRoZXJlZm9yZSBTQ1RQIE1VU1Qgc3VwcG9ydCBwZXJmb3JtaW5nIFBh dGggTVRVDQo+ICAgIGRpc2NvdmVyeSB3aXRob3V0IHJlbHlpbmcgb24gSUNNUCBvciBJQ01QdjYg YXMgc3BlY2lmaWVkIGluIFtSRkM0ODIxXQ0KPiAgICB1c2luZyBwcm9iaW5nIG1lc3NhZ2VzIHNw ZWNpZmllZCBpbiBbUkZDNDgyMF0uICBUaGUgaW5pdGlhbCBQYXRoIE1UVQ0KPiAgICBhdCB0aGUg SVAgbGF5ZXIgU0hPVUxEIE5PVCBleGNlZWQgMTIwMCBieXRlcyBmb3IgSVB2NCBhbmQgMTI4MCBm b3INCj4gICAgSVB2Ni4NCj4gDQo+IEluIHRoZSBuZXh0IHJldmlzaW9uIG9mDQo+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXNjdHAtZHRscy1lbmNhcHMtMDcj c2VjdGkNCj4gb24tNA0KPiB0aGVyZSB3aWxsIGJlIHRoZSBzZW50ZW5jZToNCj4gICAgVGhlIHBh dGggTVRVIGRpc2NvdmVyeSBpcyBwZXJmb3JtZWQgYnkgU0NUUCB3aGVuIFNDVFAgb3ZlciBEVExT IGlzDQo+ICAgIHVzZWQgZm9yIGRhdGEgY2hhbm5lbHMgKHNlZSBTZWN0aW9uIDQgb2YNCj4gICAg W0ktRC5pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWxdKS4NCj4gDQo+IEJlc3QgcmVnYXJkcw0KPiBN aWNoYWVsDQo+ID4gDQo+ID4+IA0KPiA+PiBCZXN0IHJlZ2FyZHMNCj4gPj4gTWljaGFlbA0KPiA+ Pj4gDQo+ID4+IA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+ID4+IHJ0Y3dlYkBpZXRmLm9yZw0K PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+PiAN Cj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gPiBydGN3ZWJAaWV0Zi5vcmcNCj4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPiA+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gcnRjd2ViIG1h aWxpbmcgbGlzdA0KPiBydGN3ZWJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ydGN3ZWINCg0K From nobody Thu Jan 15 01:13: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 87D6F1B2BBA for ; Thu, 15 Jan 2015 01:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 mse8o4ymPj0x for ; Thu, 15 Jan 2015 01:13:10 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258771A8030 for ; Thu, 15 Jan 2015 01:13:10 -0800 (PST) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9AF4B1C0E97AF; Thu, 15 Jan 2015 10:13:08 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> Date: Thu, 15 Jan 2015 10:13:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> To: "Schwarz, Albrecht (Albrecht)" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Jan 2015 09:13:12 -0000 On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) = wrote: >=20 > Michael, >=20 > neither obvious nor clear to me why SCTP is responsible for PMTUD in a = stack such as {SCTP/DTLS/L4/IP} layering. > Perhaps I miss sth, but I would appreciate more text. There are two options: * It can be done by SCTP (using HEARTBEAT and PADDING chunks) * It can be done by DTLS (using the heartbeat extension) These two options are described in = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= The next revision will add a clarifying sentence that in the case of = RTCWeb the first option is used as stated in https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 The following text Incoming ICMP or ICMPv6 messages can't be processed by the SCTP layer, since there is no way to identify the corresponding association. Therefore SCTP MUST support performing Path MTU discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] using probing messages specified in [RFC4820]. The initial Path MTU at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for IPv6. in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 states that SCTP does PMTUD using the first option above. Which text are you missing? Best regards Michael >=20 > Thanks, > Albrecht >=20 > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael = Tuexen > Sent: Donnerstag, 15. Januar 2015 09:42 > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >=20 >> On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> I don't think the sctp-dtls-encaps draft shall contain data channel = specific procedures. > It doesn't. It only makes clear which of the two options are used in = RTCWeb. >>=20 >> I agree with Martin that the best place is the data channel draft. > So you think the text in the data channel draft is not enough? It is = and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over = DTLS is used in RTCWeb.=20 >=20 > Best regards > Michael >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >> From: Michael Tuexen >> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >> To: Harald Alvestrand >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20 >> heartbeat >>=20 >> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>=20 >>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>=20 >>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>> wrote: >>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>>>=20 >>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>> described in >>>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>> ion-5 >>>>>=20 >>>>> SGTM. That means we don't need to reference the DTLS heartbleed = extension. >>>> It is not referenced in the RTCWeb documents, only in >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>> which allows both options. >>>=20 >>> So which document should we put it in that we use the second option? >>> -transport, or a post-last-call update of -datachannel? >> Do we really need a change? We have in >> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >> layer, since there is no way to identify the corresponding >> association. Therefore SCTP MUST support performing Path MTU >> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >> using probing messages specified in [RFC4820]. The initial Path = MTU >> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >> IPv6. >>=20 >> In the next revision of >> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >> on-4 >> there will be the sentence: >> The path MTU discovery is performed by SCTP when SCTP over DTLS is >> used for data channels (see Section 4 of >> [I-D.ietf-rtcweb-data-channel]). >>=20 >> Best regards >> Michael >>>=20 >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jan 15 01:19: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 B6BA41A8030 for ; Thu, 15 Jan 2015 01:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 nS77T5rz9zwA for ; Thu, 15 Jan 2015 01:19:56 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670C31B2BB0 for ; Thu, 15 Jan 2015 01:19:56 -0800 (PST) Received: from [10.225.7.42] (unknown [194.95.73.101]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 0293E1C104356; Thu, 15 Jan 2015 10:19:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6397F5@ESESSMB209.ericsson.se> Date: Thu, 15 Jan 2015 10:19:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6397F5@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 15 Jan 2015 09:19:58 -0000 On 15 Jan 2015, at 09:56, Christer Holmberg = wrote: >=20 > Hi, >=20 >>> I don't think the sctp-dtls-encaps draft shall contain data channel = specific procedures. >> It doesn't. It only makes clear which of the two options are used in = RTCWeb. >=20 > If it needs to be clear, it should be in an RTCWeb spec. I agree and I think it is... >=20 > For sure, you can state it as an EXAMPLE in the encaps draft if you = want to. But, an RTCWeb implementer should not have to read the encaps = draft in order to figure out which option is used - that needs to be = clear in an RTCWeb spec. I agree. And I think the text suggested by Gorry is meant as that. >=20 >>> I agree with Martin that the best place is the data channel draft. >> So you think the text in the data channel draft is not enough? It is = and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over = DTLS is used in RTCWeb.=20 >=20 > I didn't check the text in the data channel draft :) Based on the = discussion I assumed that some text is missing, and is needed somewhere. Please have a look at my other responses in this thread where I cite the = existing text. Let me know if you think that the existing text doesn't state clearly enough that = SCTP does PMTUD and not DTLS. Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >> Sent from my Windows Phone >> From: Michael Tuexen >> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >> To: Harald Alvestrand >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20 >> heartbeat >>=20 >> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>=20 >>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>=20 >>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>> wrote: >>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>>>=20 >>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>> described in >>>>>> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>> ion-5 >>>>>=20 >>>>> SGTM. That means we don't need to reference the DTLS heartbleed = extension. >>>> It is not referenced in the RTCWeb documents, only in >>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>> which allows both options. >>>=20 >>> So which document should we put it in that we use the second option? >>> -transport, or a post-last-call update of -datachannel? >> Do we really need a change? We have in >> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >> layer, since there is no way to identify the corresponding >> association. Therefore SCTP MUST support performing Path MTU >> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >> using probing messages specified in [RFC4820]. The initial Path = MTU >> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >> IPv6. >>=20 >> In the next revision of >> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >> on-4 >> there will be the sentence: >> The path MTU discovery is performed by SCTP when SCTP over DTLS is >> used for data channels (see Section 4 of >> [I-D.ietf-rtcweb-data-channel]). >>=20 >> Best regards >> Michael >>>=20 >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Fri Jan 16 05:04: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 0DB381ACD36; Fri, 16 Jan 2015 05:04:30 -0800 (PST) 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 9RD-jayQ75bZ; Fri, 16 Jan 2015 05:04:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3F11A6F2D; Fri, 16 Jan 2015 05:04:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150116130428.11452.93116.idtracker@ietfa.amsl.com> Date: Fri, 16 Jan 2015 05:04:28 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-codecs-for-interop-01.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, 16 Jan 2015 13:04:30 -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 : Additional WebRTC audio codecs for interoperability. Authors : Stephane Proust Espen Berger Bernhard Feiten Bo Burman Kalyani Bogineni Miao Lei Enrico Marocco Filename : draft-ietf-rtcweb-audio-codecs-for-interop-01.txt Pages : 10 Date : 2015-01-16 Abstract: To ensure a baseline level of interoperability between WebRTC clients, [I-D.ietf-rtcweb-audio] requires a minimum set of codecs. However, to maximize the possibility to establish the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser. This document provides some guidelines on the suitable codecs to be considered for WebRTC clients to address the most relevant interoperability use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio-codecs-for-interop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-audio-codecs-for-interop-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-codecs-for-interop-01 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 Jan 16 05:55: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 975571ACD73; Fri, 16 Jan 2015 05:55:27 -0800 (PST) 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 HyCRDrq9JykY; Fri, 16 Jan 2015 05:55:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 897E11ABC75; Fri, 16 Jan 2015 05:55:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150116135524.32225.14267.idtracker@ietfa.amsl.com> Date: Fri, 16 Jan 2015 05:55:24 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-constraints-registry-01.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, 16 Jan 2015 13:55: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 : IANA Registry for RTCWeb Constrainable Properties Author : Daniel C. Burnett Filename : draft-ietf-rtcweb-constraints-registry-01.txt Pages : 5 Date : 2015-01-16 Abstract: Specifications in W3C's Media Capture Task Force and WebRTC Working Group have need of a registry in which to maintain a list of constrainable properties for HTML media and other constrainable objects. This document defines this registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-constraints-registry/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-constraints-registry-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-constraints-registry-01 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 Jan 16 15:56: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 F355D1A906D for ; Fri, 16 Jan 2015 15:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMuzfpcJKJ8B for ; Fri, 16 Jan 2015 15:55:57 -0800 (PST) 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 8D1031A9068 for ; Fri, 16 Jan 2015 15:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6031; q=dns/txt; s=iport; t=1421452558; x=1422662158; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=b7++EGey0gELThISpwN21YMvu9nDsaY+gpjxBQypBFw=; b=lIeoR5qI/tDzanV7TAcWwje3ZLFiNqNFkobwjuP0auToar6dF0zVADYN vkkjQ1IYlNRu1Qo05e8CBI0/FPcVYrFyUlEy3gPlTkCStC6pLtYFwdu5a DZDrnr4a5KavDCmFr+2nMRWmKpDo32YltkY4tUZ7PeoNw1TAXGcFixqXz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAKKjuVStJV2Z/2dsb2JhbABQCoMGUliDBcMhDIUlSgKBEkMBAQEBAX2EDAEBAQMBAQEBIEsLBQcECxEEAQEBAgIjAwICIQYfAwEFCAYTiBgDCQgNvTGPdQ2EHAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYsogQaBTikzBwaCYi6BEwWJbYgmhASBRIEPMIolO4VrIoF/EA+BcR0xAYJCAQEB X-IronPort-AV: E=Sophos;i="5.09,413,1418083200"; d="scan'208";a="114071663" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 16 Jan 2015 23:55:58 +0000 Received: from dhcp-10-155-84-59.cisco.com (dhcp-10-155-84-59.cisco.com [10.155.84.59]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0GNttMa021820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Jan 2015 23:55:56 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Fri, 16 Jan 2015 15:55:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> To: Michael Tuexen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Iljitsch van Beijnum , "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 16 Jan 2015 23:56:00 -0000 On Jan 15, 2015, at 1:13 AM, Michael Tuexen = wrote: > On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) = wrote: >>=20 >> Michael, >>=20 >> neither obvious nor clear to me why SCTP is responsible for PMTUD in = a stack such as {SCTP/DTLS/L4/IP} layering. >> Perhaps I miss sth, but I would appreciate more text. > There are two options: > * It can be done by SCTP (using HEARTBEAT and PADDING chunks) > * It can be done by DTLS (using the heartbeat extension) > These two options are described in > = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= > The next revision will add a clarifying sentence that in the case of = RTCWeb > the first option is used as stated in > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 > The following text >=20 > Incoming ICMP or ICMPv6 messages can't be processed by the SCTP > layer, since there is no way to identify the corresponding > association. =20 Why does the corresponding (SCTP) association need to be identified? = It's all over UDP, anyway. On receipt of ICMP PTB, drop down to 1200 = bytes (IPv4) or 1280 bytes (IPv6), or be smarter about the reduction = (e.g., the table at https://tools.ietf.org/html/rfc1191#page-17 or = Iljitsch's recent research to find common MTUs on today's Internet). -d > Therefore SCTP MUST support performing Path MTU > discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] > using probing messages specified in [RFC4820]. The initial Path MTU > at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for > IPv6. >=20 > in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 > states that SCTP does PMTUD using the first option above. >=20 > Which text are you missing? >=20 > Best regards > Michael >>=20 >> Thanks, >> Albrecht >>=20 >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael = Tuexen >> Sent: Donnerstag, 15. Januar 2015 09:42 >> To: Christer Holmberg >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >>=20 >>> On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >>>=20 >>> Hi, >>>=20 >>> I don't think the sctp-dtls-encaps draft shall contain data channel = specific procedures. >> It doesn't. It only makes clear which of the two options are used in = RTCWeb. >>>=20 >>> I agree with Martin that the best place is the data channel draft. >> So you think the text in the data channel draft is not enough? It is = and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over = DTLS is used in RTCWeb.=20 >>=20 >> Best regards >> Michael >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> Sent from my Windows Phone >>> From: Michael Tuexen >>> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >>> To: Harald Alvestrand >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20 >>> heartbeat >>>=20 >>> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>>=20 >>>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>>=20 >>>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>>> wrote: >>>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>>>>=20 >>>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>>> described in >>>>>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>>> ion-5 >>>>>>=20 >>>>>> SGTM. That means we don't need to reference the DTLS heartbleed = extension. >>>>> It is not referenced in the RTCWeb documents, only in >>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>>> which allows both options. >>>>=20 >>>> So which document should we put it in that we use the second = option? >>>> -transport, or a post-last-call update of -datachannel? >>> Do we really need a change? We have in >>> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>> layer, since there is no way to identify the corresponding >>> association. Therefore SCTP MUST support performing Path MTU >>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>> using probing messages specified in [RFC4820]. The initial Path = MTU >>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >>> IPv6. >>>=20 >>> In the next revision of >>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >>> on-4 >>> there will be the sentence: >>> The path MTU discovery is performed by SCTP when SCTP over DTLS is >>> used for data channels (see Section 4 of >>> [I-D.ietf-rtcweb-data-channel]). >>>=20 >>> Best regards >>> Michael >>>>=20 >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>=20 >>>=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 From nobody Sat Jan 17 00:47: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 F202A1B2B58 for ; Sat, 17 Jan 2015 00:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 8szSCriNi3RC for ; Sat, 17 Jan 2015 00:47:28 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10F71A8A82 for ; Sat, 17 Jan 2015 00:47:27 -0800 (PST) Received: from [192.168.1.200] (p54819F98.dip0.t-ipconnect.de [84.129.159.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 774841C104343; Sat, 17 Jan 2015 09:47:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com> Date: Sat, 17 Jan 2015 09:47:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Iljitsch van Beijnum , "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 17 Jan 2015 08:47:31 -0000 > On 17 Jan 2015, at 00:55, =F0=9F=94=93Dan Wing = wrote: >=20 >=20 > On Jan 15, 2015, at 1:13 AM, Michael Tuexen = wrote: >=20 >> On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) = wrote: >>>=20 >>> Michael, >>>=20 >>> neither obvious nor clear to me why SCTP is responsible for PMTUD in = a stack such as {SCTP/DTLS/L4/IP} layering. >>> Perhaps I miss sth, but I would appreciate more text. >> There are two options: >> * It can be done by SCTP (using HEARTBEAT and PADDING chunks) >> * It can be done by DTLS (using the heartbeat extension) >> These two options are described in >> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= >> The next revision will add a clarifying sentence that in the case of = RTCWeb >> the first option is used as stated in >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 >> The following text >>=20 >> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >> layer, since there is no way to identify the corresponding >> association. =20 >=20 > Why does the corresponding (SCTP) association need to be identified? = It's all over UDP, anyway. On receipt of ICMP PTB, drop down to 1200 = bytes (IPv4) or 1280 bytes (IPv6), or be smarter about the reduction = (e.g., the table at https://tools.ietf.org/html/rfc1191#page-17 or = Iljitsch's recent research to find common MTUs on today's Internet). The current way SCTP processes ICMP messages is: * Find the SCTP association based on IP addresses and port numbers * Verify the verification tag contained in the SCTP common header = contained in the ICMP message * Process the ICMP message... This clearly ICMP messages can't be processed by SCTP since especially = the vtag check can't be done. But you are right: * UDP could notify its upper layer that it has received the ICMP PTB = message (and possibly could provide a hint). * DTLS could pass this through to its upper layer. * SCTP could process it for all associations running over that DTLS = connection bypassing the vtag check. However, you loose the protection provided by the vtag check. An = attacker knowing the IP-addresses and UDP port numbers can inject such an ICMP packet. SCTP normally requires that the sender of the packet does know the vtag. Therefore the way currently specified is that PMTUD as specified in = RFC4821 is used. This does not depend on incoming ICMP messages. They might be = blocked in the network or the DTLS layer might not pass them through. If you think we should change the SCTP over DTLS ID, please bring this = up at tsvwg@. Best regards Michael >=20 > -d >=20 >=20 >> Therefore SCTP MUST support performing Path MTU >> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >> using probing messages specified in [RFC4820]. The initial Path MTU >> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >> IPv6. >>=20 >> in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >> states that SCTP does PMTUD using the first option above. >>=20 >> Which text are you missing? >>=20 >> Best regards >> Michael >>>=20 >>> Thanks, >>> Albrecht >>>=20 >>> -----Original Message----- >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael = Tuexen >>> Sent: Donnerstag, 15. Januar 2015 09:42 >>> To: Christer Holmberg >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >>>=20 >>>> On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I don't think the sctp-dtls-encaps draft shall contain data channel = specific procedures. >>> It doesn't. It only makes clear which of the two options are used in = RTCWeb. >>>>=20 >>>> I agree with Martin that the best place is the data channel draft. >>> So you think the text in the data channel draft is not enough? It is = and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP over = DTLS is used in RTCWeb.=20 >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> Sent from my Windows Phone >>>> From: Michael Tuexen >>>> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >>>> To: Harald Alvestrand >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20 >>>> heartbeat >>>>=20 >>>> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>>>=20 >>>>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>>>=20 >>>>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>>>> wrote: >>>>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>>>>>=20 >>>>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>>>> described in >>>>>>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>>>> ion-5 >>>>>>>=20 >>>>>>> SGTM. That means we don't need to reference the DTLS heartbleed = extension. >>>>>> It is not referenced in the RTCWeb documents, only in >>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>>>> which allows both options. >>>>>=20 >>>>> So which document should we put it in that we use the second = option? >>>>> -transport, or a post-last-call update of -datachannel? >>>> Do we really need a change? We have in >>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>> layer, since there is no way to identify the corresponding >>>> association. Therefore SCTP MUST support performing Path MTU >>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>> using probing messages specified in [RFC4820]. The initial Path = MTU >>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >>>> IPv6. >>>>=20 >>>> In the next revision of >>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >>>> on-4 >>>> there will be the sentence: >>>> The path MTU discovery is performed by SCTP when SCTP over DTLS is >>>> used for data channels (see Section 4 of >>>> [I-D.ietf-rtcweb-data-channel]). >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>=20 >>>>=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 >=20 From nobody Mon Jan 19 09:27:20 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E081B2B07 for ; Mon, 19 Jan 2015 09:27:17 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 g3GCs_PyF-3t for ; Mon, 19 Jan 2015 09:27:15 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id AD2A41B2AE8 for ; Mon, 19 Jan 2015 09:27:14 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 3595A23F0434 for ; Mon, 19 Jan 2015 18:27:13 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.78]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0224.002; Mon, 19 Jan 2015 18:27:13 +0100 From: "Hutton, Andrew" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04 Thread-Index: AQHQK3o9VmmfZ9vAFkmJUn+/9OGnvZy2piqAgBEYKrA= Date: Mon, 19 Jan 2015 17:27:12 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E67BDEE@MCHP04MSX.global-ad.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] Discussion of draft-schwartz-rtcweb-return-04 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Jan 2015 17:27:17 -0000 SSB0aGluayB3ZSBzaG91bGQgZG8gdGhpcyBpdCBpcyBuZWVkZWQgYW5kIGFzIEp1c3RpbiBzYWlk IGl0IHNhdGlzZmllcyBhIHJlcXVpcmVtZW50IChGMjApIHdlIGdhdmUgb3Vyc2VsdmVzIGZyb20g dGhlIGJlZ2lubmluZy4NCg0KSSBkb24ndCBzZWUgaXQgYXMgc29tZXRoaW5nIHRoYXQgaXMgbWFu ZGF0b3J5IHRvIGltcGxlbWVudCBidXQgbW9yZSBvZiBhbiBvcHRpbWl6YXRpb24gdGhhdCBpcyBu ZWVkZWQgdG8gd29yayB3ZWxsIGluIHNvbWUgZW52aXJvbm1lbnRzIHNvIEkgd291bGQgbm90IGNv bnNpZGVyZWQgdGhpcyB0byBiZSBvbiB0aGUgY3JpdGljYWwgcGF0aCBidXQgdW5sZXNzIHNvbWVi b2R5IHByb3Bvc2VzIGFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIHRvIHJlcXVpcmVtZW50IEYyMCB0 aGVuIHRoaXMgc2hvdWxkIGJlIGFkb3B0ZWQgYW5kIGRvbmUgYXMgc29vbiBhcyBwb3NzaWJsZS4N Cg0KUmVnYXJkcw0KQW5keQ0KDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgSnVzdGluDQo+IFViZXJ0aQ0KPiBTZW50OiAwOCBKYW51YXJ5IDIwMTUgMjE6MDYNCj4gVG86 IEJlbmphbWluIFNjaHdhcnR6DQo+IENjOiBDdWxsZW4gSmVubmluZ3M7IHJ0Y3dlYkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRGlzY3Vzc2lvbiBvZiBkcmFmdC1zY2h3YXJ0ei1y dGN3ZWItcmV0dXJuLTA0DQo+IA0KPiBSaWdodC4gVG8gYmUgYWJzb2x1dGVseSBjbGVhciwgdGhp cyBkcmFmdCBleHBsYWlucyBob3cgUlRDV0VCDQo+IGltcGxlbWVudGF0aW9ucyBjYW4gc2F0aXNm eSB0aGUgcmVxdWlyZW1lbnQgRjIwIGZyb20gU2VjdGlvbiAzLjMuNSBvZg0KPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC0NCj4gcmVx dWlyZW1lbnRzLTE1I3NlY3Rpb24tMy4zLjUuMS4gV2UndmUgZGlzY3Vzc2VkIHRoZSBuZWVkIGZv ciB0aGlzIGZvcg0KPiBzb21lIHRpbWUsIGJ1dCB0aGUgUkVUVVJOIGRyYWZ0IGlzIHRoZSBmaXJz dCBwcm9wb3NhbCBmb3IgaG93IHRvDQo+IGFjdHVhbGx5IGFkZHJlc3MgaXQuDQo+ICAgIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gICAgUkVRLUlEICAgICAgREVTQ1JJUFRJT04NCj4gICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICBGMjAg ICAgIFRoZSBicm93c2VyIG11c3Qgc3VwcG9ydCB0aGUgdXNlIG9mIFNUVU4gYW5kIFRVUk4NCj4g ICAgICAgICAgICBzZXJ2ZXJzIHRoYXQgYXJlIHN1cHBsaWVkIGJ5IGVudGl0aWVzIG90aGVyIHRo YW4NCj4gICAgICAgICAgICB0aGUgd2ViIGFwcGxpY2F0aW9uIChpLmUuIHRoZSBuZXR3b3JrIHBy b3ZpZGVyKS4NCj4gICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IA0KPiBPbiBUaHUsIEphbiA4LCAyMDE1 IGF0IDExOjM0IEFNLCBCZW5qYW1pbiBTY2h3YXJ0eiA8YmVtYXNjQHdlYnJ0Yy5vcmc+DQo+IHdy b3RlOg0KPiBGb3Igd2hhdCBpdCdzIHdvcnRoLCByZWdhcmRpbmcgc2NvcGUsIG15IHBlcnNwZWN0 aXZlIGlzIHRoYXQgdGhlDQo+IGRvY3VtZW50IGRvZXMgbm90IGNyZWF0ZSBhbnkgbmV3IHByb3Rv Y29sIGV4dGVuc2lvbnMgb3IgQVBJIHBvaW50cy4NCj4gSXRzIG9ubHkgcHVycG9zZSBpcyB0byBs YXkgb3V0IGluIGRldGFpbCB0aGUgZXhwZWN0ZWQgaW50ZXJhY3Rpb24NCj4gYmV0d2VlbiBleHRl cm5hbGx5LXByb3ZpZGVkIFRVUk4gc2VydmVycyAobGlrZSB0aG9zZSBmb3VuZCBieSBUUkFNDQo+ IGF1dG9kaXNjb3ZlcnkpIGFuZCBXZWJSVEMsIHdoaWNoIGlzIGN1cnJlbnRseSBleHRyZW1lbHkg dW5kZXItDQo+IHNwZWNpZmllZC7CoCBTcGVjaWZpY2FsbHksIGl0IGV4cGxhaW5zIHRoYXQgZXh0 ZXJuYWxseS1wcm92aWRlZCBUVVJODQo+IHNlcnZlcnMgYXJlIF9wcm94aWVzXywgbm90IGp1c3Qg YWRkaXRpb25hbCBUVVJOIHNlcnZlcnMgbGlrZSB0aG9zZQ0KPiBsaXN0ZWQgaW4gdGhlIFJUQ1Bl ZXJDb25uZWN0aW9uIGNvbnN0cnVjdG9yIGFyZ3VtZW50cy7CoCBUcmVhdGluZyB0aGVzZQ0KPiBz ZXJ2ZXJzIGFzIHByb3hpZXMgKGluIHRoZSBwYXJ0aWN1bGFyIG1hbm5lciBzcGVjaWZpZWQpIGFs bG93cyB1cyB0bw0KPiBwcmVzZXJ2ZSAoYW5kIGVuaGFuY2UpIHNvbWUgaW1wb3J0YW50IHBlcmZv cm1hbmNlLCBjb25uZWN0aXZpdHksIGFuZA0KPiBwcml2YWN5IHByb3BlcnRpZXMgb2YgV2ViUlRD Lg0KPiANCj4gVGhpcyBkb2N1bWVudCBvbmx5IGltcG9zZXMgcmVxdWlyZW1lbnRzIChvZiBhbnkg c3RyZW5ndGgpIG9uIFdlYlJUQw0KPiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBpbnRlbmQgdG8gaW1w bGVtZW50IGEgbWVjaGFuaXNtIGZvciB1c2luZyBUVVJODQo+IHNlcnZlcnMgdGhhdCB3ZXJlIG5v dCBpbmRpY2F0ZWQgYnkgdGhlIGFwcGxpY2F0aW9uLsKgIEl0IGRvZXMgbm90IGRlbWFuZA0KPiB0 aGF0IGFsbCBicm93c2VycyBhZGQgc3VwcG9ydCBmb3Igc3VjaCBhIG1lY2hhbmlzbSwgYW5kIGl0 IGRvZXMgbm90DQo+IHNwZWNpZnkgYSBwcmVmZXJlbmNlIGZvciBhbnkgcGFydGljdWxhciBUVVJO IGNvbmZpZ3VyYXRpb24gbWVjaGFuaXNtLg0KPiANCj4gT24gVGh1LCBKYW4gOCwgMjAxNSBhdCAx OjU0IFBNLCBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiBIb3dkeSwN Cj4gDQo+IER1cmluZyB0aGUgSG9ub2x1bHUgbWVldGluZywgdGhlIGNoYWlycyBhZ3JlZWQgdG8g YXNrIGZvciBzb21lIG9uLWxpc3QNCj4gZGlzY3Vzc2lvbiBvZiB0aGlzIGRyYWZ0IHByaW9yIHRv IGRpc2N1c3NpbmcgYWRvcHRpb24uwqAgRHVyaW5nIHRoZQ0KPiBob2xpZGF5cyB3ZSBkcm9wcGVk IHRoZSBiYWxsIG9uIHRoYXQsIGZvciB3aGljaCBvdXIgYXBvbG9naWVzLsKgwqAgQXQNCj4gdGhp cyBwb2ludCwgdGhvdWdoLCB3ZSdkIGxpa2UgdG8gc2VlIHNvbWUgZGlzY3Vzc2lvbiBvZiB0aGUg ZHJhZnQtLWluDQo+IHBhcnRpY3VsYXIgb24gaXRzIHNjb3BlIGFuZCBob3cgaXQgZml0cyBpbnRv IHRoZSBsYW5kc2NhcGUgb2Ygd29yayB3ZQ0KPiBuZWVkIHRvIGNvbXBsZXRlDQo+IHRoYW5rcywN Cj4gDQo+IFRlZCwgQ3VsbGVuLCBTZWFuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== From nobody Mon Jan 19 10:39: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 39C991B2B44 for ; Mon, 19 Jan 2015 10:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKE9dEWLJhYg for ; Mon, 19 Jan 2015 10:39:17 -0800 (PST) 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 B1F0C1B2BF3 for ; Mon, 19 Jan 2015 10:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8334; q=dns/txt; s=iport; t=1421692756; x=1422902356; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5xXEIRbcqUQZbYnePHHWJVnv7rXNhBzQu2PcDtlXBss=; b=aNBWTU++CJHibpX1yVQ6nGcugrZRhsPorDPPB5Fwn3gG2UVD8+uwVZl7 uj1x8/jglpo/0kpyVAfqvMtcagI97D0PIQLJNA/TqBWvaIejads/2Yi20 NZiMGbSOLf2gKu/nEE0NBhwOmcEu+fxv2bK+Rd29AIrcKLre6ZZFP2cRD U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFABNOvVStJA2M/2dsb2JhbABRCoMGUoNewzcMhSVKAoEjQwEBAQEBfYQMAQEBAwEBAQEgSwsFBwQJAhEEAQEBAgIjAwICIQYfAwEFCAYTiBgDCQgNnh+cbI96DYQcAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiyiBBoFOKTMHBoJiLoETBYl1iCuEDIFEgRQ2gkaCH4VNPYVxIoF/EA+BcR0xAQEBgQIkgRoBAQE X-IronPort-AV: E=Sophos;i="5.09,428,1418083200"; d="scan'208";a="114664226" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 19 Jan 2015 18:39:15 +0000 Received: from [10.24.238.22] ([10.24.238.22]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t0JIdBJ0003907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Jan 2015 18:39:14 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Mon, 19 Jan 2015 09:22:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0F587DA9-D87F-4924-B970-899A5B9D14EB@cisco.com> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com> To: Michael Tuexen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Iljitsch van Beijnum , "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Jan 2015 18:39:20 -0000 On Jan 17, 2015, at 12:47 AM, Michael Tuexen = wrote: >> On 17 Jan 2015, at 00:55, =F0=9F=94=93Dan Wing = wrote: >>=20 >>=20 >> On Jan 15, 2015, at 1:13 AM, Michael Tuexen = wrote: >>=20 >>> On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) = wrote: >>>>=20 >>>> Michael, >>>>=20 >>>> neither obvious nor clear to me why SCTP is responsible for PMTUD = in a stack such as {SCTP/DTLS/L4/IP} layering. >>>> Perhaps I miss sth, but I would appreciate more text. >>> There are two options: >>> * It can be done by SCTP (using HEARTBEAT and PADDING chunks) >>> * It can be done by DTLS (using the heartbeat extension) >>> These two options are described in >>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= >>> The next revision will add a clarifying sentence that in the case of = RTCWeb >>> the first option is used as stated in >>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 >>> The following text >>>=20 >>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>> layer, since there is no way to identify the corresponding >>> association. =20 >>=20 >> Why does the corresponding (SCTP) association need to be identified? = It's all over UDP, anyway. On receipt of ICMP PTB, drop down to 1200 = bytes (IPv4) or 1280 bytes (IPv6), or be smarter about the reduction = (e.g., the table at https://tools.ietf.org/html/rfc1191#page-17 or = Iljitsch's recent research to find common MTUs on today's Internet). > The current way SCTP processes ICMP messages is: > * Find the SCTP association based on IP addresses and port numbers > * Verify the verification tag contained in the SCTP common header = contained in the ICMP message > * Process the ICMP message... > This clearly ICMP messages can't be processed by SCTP since especially = the vtag check can't be done. >=20 > But you are right: > * UDP could notify its upper layer that it has received the ICMP PTB = message (and possibly could provide a hint). > * DTLS could pass this through to its upper layer. > * SCTP could process it for all associations running over that DTLS = connection bypassing > the vtag check. >=20 > However, you loose the protection provided by the vtag check. An = attacker knowing > the IP-addresses and UDP port numbers can inject such an ICMP packet. > SCTP normally requires that the sender of the packet does know the = vtag. To prevent similar off-path attacks, many TCP implementations validate = the sequence number of ICMPs = (https://tools.ietf.org/html/rfc5927#section-4.1). The TCP sequence = number is in the same place as SCTP's VTAG (both are immediately after = the port numbers), so SCTP's VTAG should be returned in ICMP PTB as = often as TCP sequence numbers are returned in ICMP PTBs. = https://tools.ietf.org/html/rfc1812#section-4.3.2.3 increased the = recommended size of ICMPs, and I understand is pretty well deployed. -d > Therefore the way currently specified is that PMTUD as specified in = RFC4821 > is used. This does not depend on incoming ICMP messages. They might be = blocked > in the network or the DTLS layer might not pass them through. >=20 > If you think we should change the SCTP over DTLS ID, please bring this = up at tsvwg@. >=20 > Best regards > Michael >>=20 >> -d >>=20 >>=20 >>> Therefore SCTP MUST support performing Path MTU >>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>> using probing messages specified in [RFC4820]. The initial Path MTU >>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >>> IPv6. >>>=20 >>> in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>> states that SCTP does PMTUD using the first option above. >>>=20 >>> Which text are you missing? >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> Thanks, >>>> Albrecht >>>>=20 >>>> -----Original Message----- >>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael = Tuexen >>>> Sent: Donnerstag, 15. Januar 2015 09:42 >>>> To: Christer Holmberg >>>> Cc: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >>>>=20 >>>>> On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> I don't think the sctp-dtls-encaps draft shall contain data = channel specific procedures. >>>> It doesn't. It only makes clear which of the two options are used = in RTCWeb. >>>>>=20 >>>>> I agree with Martin that the best place is the data channel draft. >>>> So you think the text in the data channel draft is not enough? It = is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP = over DTLS is used in RTCWeb.=20 >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> Sent from my Windows Phone >>>>> From: Michael Tuexen >>>>> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >>>>> To: Harald Alvestrand >>>>> Cc: rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20 >>>>> heartbeat >>>>>=20 >>>>> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>>>>=20 >>>>>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>>>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>>>>=20 >>>>>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>>>>> wrote: >>>>>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>>>>>>=20 >>>>>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>>>>> described in >>>>>>>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>>>>> ion-5 >>>>>>>>=20 >>>>>>>> SGTM. That means we don't need to reference the DTLS = heartbleed extension. >>>>>>> It is not referenced in the RTCWeb documents, only in >>>>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>>>>> which allows both options. >>>>>>=20 >>>>>> So which document should we put it in that we use the second = option? >>>>>> -transport, or a post-last-call update of -datachannel? >>>>> Do we really need a change? We have in >>>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>>> layer, since there is no way to identify the corresponding >>>>> association. Therefore SCTP MUST support performing Path MTU >>>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>>> using probing messages specified in [RFC4820]. The initial Path = MTU >>>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >>>>> IPv6. >>>>>=20 >>>>> In the next revision of >>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >>>>> on-4 >>>>> there will be the sentence: >>>>> The path MTU discovery is performed by SCTP when SCTP over DTLS is >>>>> used for data channels (see Section 4 of >>>>> [I-D.ietf-rtcweb-data-channel]). >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>>=20 >>>>>>>=20 >>>>>>> Best regards >>>>>>> Michael >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> rtcweb mailing list >>>>>> rtcweb@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>=20 >>>>>=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 From nobody Mon Jan 19 11:18:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D2C1B2C00 for ; Mon, 19 Jan 2015 11:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 tFx_O2clNtc0 for ; Mon, 19 Jan 2015 11:18:40 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645BE1B2B6A for ; Mon, 19 Jan 2015 11:18:40 -0800 (PST) Received: from [192.168.1.200] (p508F3E81.dip0.t-ipconnect.de [80.143.62.129]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6EA541C0B3035; Mon, 19 Jan 2015 20:18:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <0F587DA9-D87F-4924-B970-899A5B9D14EB@cisco.com> Date: Mon, 19 Jan 2015 20:18:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com> <0F587DA9-D87F-4924-B970-899A5B9D14EB@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Iljitsch van Beijnum , "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Jan 2015 19:18:43 -0000 > On 19 Jan 2015, at 18:22, =F0=9F=94=93Dan Wing = wrote: >=20 >=20 > On Jan 17, 2015, at 12:47 AM, Michael Tuexen = wrote: >=20 >>> On 17 Jan 2015, at 00:55, =F0=9F=94=93Dan Wing = wrote: >>>=20 >>>=20 >>> On Jan 15, 2015, at 1:13 AM, Michael Tuexen = wrote: >>>=20 >>>> On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) = wrote: >>>>>=20 >>>>> Michael, >>>>>=20 >>>>> neither obvious nor clear to me why SCTP is responsible for PMTUD = in a stack such as {SCTP/DTLS/L4/IP} layering. >>>>> Perhaps I miss sth, but I would appreciate more text. >>>> There are two options: >>>> * It can be done by SCTP (using HEARTBEAT and PADDING chunks) >>>> * It can be done by DTLS (using the heartbeat extension) >>>> These two options are described in >>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= >>>> The next revision will add a clarifying sentence that in the case = of RTCWeb >>>> the first option is used as stated in >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 >>>> The following text >>>>=20 >>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>> layer, since there is no way to identify the corresponding >>>> association. =20 >>>=20 >>> Why does the corresponding (SCTP) association need to be identified? = It's all over UDP, anyway. On receipt of ICMP PTB, drop down to 1200 = bytes (IPv4) or 1280 bytes (IPv6), or be smarter about the reduction = (e.g., the table at https://tools.ietf.org/html/rfc1191#page-17 or = Iljitsch's recent research to find common MTUs on today's Internet). >> The current way SCTP processes ICMP messages is: >> * Find the SCTP association based on IP addresses and port numbers >> * Verify the verification tag contained in the SCTP common header = contained in the ICMP message >> * Process the ICMP message... >> This clearly ICMP messages can't be processed by SCTP since = especially the vtag check can't be done. >>=20 >> But you are right: >> * UDP could notify its upper layer that it has received the ICMP PTB = message (and possibly could provide a hint). >> * DTLS could pass this through to its upper layer. >> * SCTP could process it for all associations running over that DTLS = connection bypassing >> the vtag check. >>=20 >> However, you loose the protection provided by the vtag check. An = attacker knowing >> the IP-addresses and UDP port numbers can inject such an ICMP packet. >> SCTP normally requires that the sender of the packet does know the = vtag. >=20 > To prevent similar off-path attacks, many TCP implementations validate = the sequence number of ICMPs = (https://tools.ietf.org/html/rfc5927#section-4.1). The TCP sequence = number is in the same place as SCTP's VTAG (both are immediately after = the port numbers), so SCTP's VTAG should be returned in ICMP PTB as = often as TCP sequence numbers are returned in ICMP PTBs. = https://tools.ietf.org/html/rfc1812#section-4.3.2.3 increased the = recommended size of ICMPs, and I understand is pretty well deployed. You are right, this would work for SCTP/UDP/ICMP, but we are using = SCTP/DTLS/UDP/ICMP. So SCTP would get the encrypted SCTP packet, which is useless. I haven't = seen DTLS decrypting the partial packets. Therefore the TSVWG suggests using the method = described in RFC4821. Best regards Michael=20 >=20 > -d >=20 >=20 >> Therefore the way currently specified is that PMTUD as specified in = RFC4821 >> is used. This does not depend on incoming ICMP messages. They might = be blocked >> in the network or the DTLS layer might not pass them through. >>=20 >> If you think we should change the SCTP over DTLS ID, please bring = this up at tsvwg@. >>=20 >> Best regards >> Michael >>>=20 >>> -d >>>=20 >>>=20 >>>> Therefore SCTP MUST support performing Path MTU >>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>> using probing messages specified in [RFC4820]. The initial Path = MTU >>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >>>> IPv6. >>>>=20 >>>> in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>> states that SCTP does PMTUD using the first option above. >>>>=20 >>>> Which text are you missing? >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> Thanks, >>>>> Albrecht >>>>>=20 >>>>> -----Original Message----- >>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Michael = Tuexen >>>>> Sent: Donnerstag, 15. Januar 2015 09:42 >>>>> To: Christer Holmberg >>>>> Cc: rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >>>>>=20 >>>>>> On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> I don't think the sctp-dtls-encaps draft shall contain data = channel specific procedures. >>>>> It doesn't. It only makes clear which of the two options are used = in RTCWeb. >>>>>>=20 >>>>>> I agree with Martin that the best place is the data channel = draft. >>>>> So you think the text in the data channel draft is not enough? It = is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP = over DTLS is used in RTCWeb.=20 >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> Sent from my Windows Phone >>>>>> From: Michael Tuexen >>>>>> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >>>>>> To: Harald Alvestrand >>>>>> Cc: rtcweb@ietf.org >>>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20 >>>>>> heartbeat >>>>>>=20 >>>>>> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>>>>>=20 >>>>>>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>>>>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>>>>>=20 >>>>>>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>>>>>> wrote: >>>>>>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING chunks >>>>>>>>>>=20 >>>>>>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>>>>>> described in >>>>>>>>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>>>>>> ion-5 >>>>>>>>>=20 >>>>>>>>> SGTM. That means we don't need to reference the DTLS = heartbleed extension. >>>>>>>> It is not referenced in the RTCWeb documents, only in >>>>>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>>>>>> which allows both options. >>>>>>>=20 >>>>>>> So which document should we put it in that we use the second = option? >>>>>>> -transport, or a post-last-call update of -datachannel? >>>>>> Do we really need a change? We have in >>>>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>>>> layer, since there is no way to identify the corresponding >>>>>> association. Therefore SCTP MUST support performing Path MTU >>>>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>>>> using probing messages specified in [RFC4820]. The initial Path = MTU >>>>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 = for >>>>>> IPv6. >>>>>>=20 >>>>>> In the next revision of >>>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >>>>>> on-4 >>>>>> there will be the sentence: >>>>>> The path MTU discovery is performed by SCTP when SCTP over DTLS = is >>>>>> used for data channels (see Section 4 of >>>>>> [I-D.ietf-rtcweb-data-channel]). >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best regards >>>>>>>> Michael >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> rtcweb mailing list >>>>>>>> rtcweb@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> rtcweb mailing list >>>>>>> rtcweb@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>=20 >>>>>>=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 >=20 From nobody Mon Jan 19 11:44: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 C79381B2C2E for ; Mon, 19 Jan 2015 11:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBG37yJGc6ql for ; Mon, 19 Jan 2015 11:44:12 -0800 (PST) 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 A16481ACDEA for ; Mon, 19 Jan 2015 11:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9722; q=dns/txt; s=iport; t=1421696653; x=1422906253; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=04WJH7cysJjGBFR417GsMnrpkCXMsNKRQfNkV9XJ15k=; b=MwSBWUwQnhchp5s1XLtJAvzuNEILeC1jU0zhpnqMZ7KqzX3gAVYqiDdF fvHbCsr4lA4t1GuWNC9aWX9buKqfRaJGHq1tTVc5TUvd+pJkVZaQn5RhP WGYXUB4Ojxqj/Uxlssde29YYp1pvonqXCvtFvMVLIFB2VdBODbW9lqwQN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAChdvVStJV2R/2dsb2JhbABRCoMGUoNewzcMhSVKAoEkQwEBAQEBfYQMAQEBAwEBAQEgSwsMBAkCEQQBAQECAiMDAgIhBh8DAQUIBhOIGAMJCA2dV5xsj3sNhBwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGLKIEGgU4pMwcGgmIugRMFiXWIK4QMgUSBFDaCRoIfhU09hXEigX8QD4FxHTEBAQGBAiSBGgEBAQ X-IronPort-AV: E=Sophos;i="5.09,428,1418083200"; d="scan'208";a="114679448" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP; 19 Jan 2015 19:44:12 +0000 Received: from [10.24.238.22] ([10.24.238.22]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0JJhoeN031789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Jan 2015 19:44:10 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Mon, 19 Jan 2015 11:44:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <641A9DB7-B7EE-428C-8623-E92CC41D8E00@cisco.com> References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com> <0F587DA9-D87F-4924-B970-899A5B9D14EB@cisco.com> To: Michael Tuexen X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Iljitsch van Beijnum , "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Jan 2015 19:44:17 -0000 On Jan 19, 2015, at 11:18 AM, Michael Tuexen = wrote: >=20 >> On 19 Jan 2015, at 18:22, =F0=9F=94=93Dan Wing = wrote: >>=20 >>=20 >> On Jan 17, 2015, at 12:47 AM, Michael Tuexen = wrote: >>=20 >>>> On 17 Jan 2015, at 00:55, =F0=9F=94=93Dan Wing = wrote: >>>>=20 >>>>=20 >>>> On Jan 15, 2015, at 1:13 AM, Michael Tuexen = wrote: >>>>=20 >>>>> On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) = wrote: >>>>>>=20 >>>>>> Michael, >>>>>>=20 >>>>>> neither obvious nor clear to me why SCTP is responsible for PMTUD = in a stack such as {SCTP/DTLS/L4/IP} layering. >>>>>> Perhaps I miss sth, but I would appreciate more text. >>>>> There are two options: >>>>> * It can be done by SCTP (using HEARTBEAT and PADDING chunks) >>>>> * It can be done by DTLS (using the heartbeat extension) >>>>> These two options are described in >>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= >>>>> The next revision will add a clarifying sentence that in the case = of RTCWeb >>>>> the first option is used as stated in >>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 >>>>> The following text >>>>>=20 >>>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>>> layer, since there is no way to identify the corresponding >>>>> association. =20 >>>>=20 >>>> Why does the corresponding (SCTP) association need to be = identified? It's all over UDP, anyway. On receipt of ICMP PTB, drop = down to 1200 bytes (IPv4) or 1280 bytes (IPv6), or be smarter about the = reduction (e.g., the table at = https://tools.ietf.org/html/rfc1191#page-17 or Iljitsch's recent = research to find common MTUs on today's Internet). >>> The current way SCTP processes ICMP messages is: >>> * Find the SCTP association based on IP addresses and port numbers >>> * Verify the verification tag contained in the SCTP common header = contained in the ICMP message >>> * Process the ICMP message... >>> This clearly ICMP messages can't be processed by SCTP since = especially the vtag check can't be done. >>>=20 >>> But you are right: >>> * UDP could notify its upper layer that it has received the ICMP PTB = message (and possibly could provide a hint). >>> * DTLS could pass this through to its upper layer. >>> * SCTP could process it for all associations running over that DTLS = connection bypassing >>> the vtag check. >>>=20 >>> However, you loose the protection provided by the vtag check. An = attacker knowing >>> the IP-addresses and UDP port numbers can inject such an ICMP = packet. >>> SCTP normally requires that the sender of the packet does know the = vtag. >>=20 >> To prevent similar off-path attacks, many TCP implementations = validate the sequence number of ICMPs = (https://tools.ietf.org/html/rfc5927#section-4.1). The TCP sequence = number is in the same place as SCTP's VTAG (both are immediately after = the port numbers), so SCTP's VTAG should be returned in ICMP PTB as = often as TCP sequence numbers are returned in ICMP PTBs. = https://tools.ietf.org/html/rfc1812#section-4.3.2.3 increased the = recommended size of ICMPs, and I understand is pretty well deployed. > You are right, this would work for SCTP/UDP/ICMP, but we are using = SCTP/DTLS/UDP/ICMP. > So SCTP would get the encrypted SCTP packet, which is useless. I = haven't seen DTLS decrypting > the partial packets. Therefore the TSVWG suggests using the method = described in RFC4821. Seems this highlights a more general problem with validating any ICMP = error for a DTLS packet, which should have sanity checks performed = (similar to sanity checks of SCTP VTAG and TCP sequence numbers). DTLS = has some fields in the clear which would be returned in ICMP (epoch and = sequence number), but unfortunately they are not randomized like SCTP = VTAG or TCP sequence numbers. I'll bring that up on TSVWG. -d >=20 > Best regards > Michael=20 >>=20 >> -d >>=20 >>=20 >>> Therefore the way currently specified is that PMTUD as specified in = RFC4821 >>> is used. This does not depend on incoming ICMP messages. They might = be blocked >>> in the network or the DTLS layer might not pass them through. >>>=20 >>> If you think we should change the SCTP over DTLS ID, please bring = this up at tsvwg@. >>>=20 >>> Best regards >>> Michael >>>>=20 >>>> -d >>>>=20 >>>>=20 >>>>> Therefore SCTP MUST support performing Path MTU >>>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>>> using probing messages specified in [RFC4820]. The initial Path = MTU >>>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 for >>>>> IPv6. >>>>>=20 >>>>> in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>>> states that SCTP does PMTUD using the first option above. >>>>>=20 >>>>> Which text are you missing? >>>>>=20 >>>>> Best regards >>>>> Michael >>>>>>=20 >>>>>> Thanks, >>>>>> Albrecht >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Michael Tuexen >>>>>> Sent: Donnerstag, 15. Januar 2015 09:42 >>>>>> To: Christer Holmberg >>>>>> Cc: rtcweb@ietf.org >>>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >>>>>>=20 >>>>>>> On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I don't think the sctp-dtls-encaps draft shall contain data = channel specific procedures. >>>>>> It doesn't. It only makes clear which of the two options are used = in RTCWeb. >>>>>>>=20 >>>>>>> I agree with Martin that the best place is the data channel = draft. >>>>>> So you think the text in the data channel draft is not enough? It = is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP = over DTLS is used in RTCWeb.=20 >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Christer >>>>>>>=20 >>>>>>> Sent from my Windows Phone >>>>>>> From: Michael Tuexen >>>>>>> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >>>>>>> To: Harald Alvestrand >>>>>>> Cc: rtcweb@ietf.org >>>>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20= >>>>>>> heartbeat >>>>>>>=20 >>>>>>> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>>>>>>=20 >>>>>>>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>>>>>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>>>>>>=20 >>>>>>>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>>>>>>> wrote: >>>>>>>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>>>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING = chunks >>>>>>>>>>>=20 >>>>>>>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>>>>>>> described in >>>>>>>>>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>>>>>>> ion-5 >>>>>>>>>>=20 >>>>>>>>>> SGTM. That means we don't need to reference the DTLS = heartbleed extension. >>>>>>>>> It is not referenced in the RTCWeb documents, only in >>>>>>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>>>>>>> which allows both options. >>>>>>>>=20 >>>>>>>> So which document should we put it in that we use the second = option? >>>>>>>> -transport, or a post-last-call update of -datachannel? >>>>>>> Do we really need a change? We have in >>>>>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>>>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>>>>> layer, since there is no way to identify the corresponding >>>>>>> association. Therefore SCTP MUST support performing Path MTU >>>>>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>>>>> using probing messages specified in [RFC4820]. The initial Path = MTU >>>>>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 = for >>>>>>> IPv6. >>>>>>>=20 >>>>>>> In the next revision of >>>>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >>>>>>> on-4 >>>>>>> there will be the sentence: >>>>>>> The path MTU discovery is performed by SCTP when SCTP over DTLS = is >>>>>>> used for data channels (see Section 4 of >>>>>>> [I-D.ietf-rtcweb-data-channel]). >>>>>>>=20 >>>>>>> Best regards >>>>>>> Michael >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best regards >>>>>>>>> Michael >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> rtcweb mailing list >>>>>>>>> rtcweb@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> rtcweb mailing list >>>>>>>> rtcweb@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>=20 >>>>>>>=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 >>=20 >=20 From nobody Mon Jan 19 12:30:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66861B2C53 for ; Mon, 19 Jan 2015 12:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 yD6RHDKskM8I for ; Mon, 19 Jan 2015 12:30:46 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B221B2C3E for ; Mon, 19 Jan 2015 12:30:45 -0800 (PST) Received: from [192.168.1.200] (p508F3E81.dip0.t-ipconnect.de [80.143.62.129]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E01551C0B3EE3; Mon, 19 Jan 2015 21:30:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <641A9DB7-B7EE-428C-8623-E92CC41D8E00@cisco.com> Date: Mon, 19 Jan 2015 21:30:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C5B610D-DA15-4DC6-82B3-E518748B1222@lurchi.franken.de> <54B6E9BC.2060203@alvestrand.no> <, <7CEBA9FD-CCAE-473B-92FC-7E951317CEF4@lurchi.franken.de> <>> <7594FB04B1934943A5C02806D1A2204B1D63922A@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC384689@FR711WXCHMBA03.zeu.alcatel-lucent.com> <323A2603-0D0F-41E9-BC54-F4B62DAF0D91@cisco.com> <0F587DA9-D87F-4924-B970-899A5B9D14EB@cisco.com> <641A9DB7-B7EE-428C-8623-E92CC41D8E00@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Iljitsch van Beijnum , "rtcweb@ietf.org" Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS heartbeat X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 19 Jan 2015 20:30:49 -0000 > On 19 Jan 2015, at 20:44, =F0=9F=94=93Dan Wing = wrote: >=20 >=20 > On Jan 19, 2015, at 11:18 AM, Michael Tuexen = wrote: >=20 >>=20 >>> On 19 Jan 2015, at 18:22, =F0=9F=94=93Dan Wing = wrote: >>>=20 >>>=20 >>> On Jan 17, 2015, at 12:47 AM, Michael Tuexen = wrote: >>>=20 >>>>> On 17 Jan 2015, at 00:55, =F0=9F=94=93Dan Wing = wrote: >>>>>=20 >>>>>=20 >>>>> On Jan 15, 2015, at 1:13 AM, Michael Tuexen = wrote: >>>>>=20 >>>>>> On 15 Jan 2015, at 09:45, Schwarz, Albrecht (Albrecht) = wrote: >>>>>>>=20 >>>>>>> Michael, >>>>>>>=20 >>>>>>> neither obvious nor clear to me why SCTP is responsible for = PMTUD in a stack such as {SCTP/DTLS/L4/IP} layering. >>>>>>> Perhaps I miss sth, but I would appreciate more text. >>>>>> There are two options: >>>>>> * It can be done by SCTP (using HEARTBEAT and PADDING chunks) >>>>>> * It can be done by DTLS (using the heartbeat extension) >>>>>> These two options are described in >>>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#section-4= >>>>>> The next revision will add a clarifying sentence that in the case = of RTCWeb >>>>>> the first option is used as stated in >>>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 >>>>>> The following text >>>>>>=20 >>>>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>>>> layer, since there is no way to identify the corresponding >>>>>> association. =20 >>>>>=20 >>>>> Why does the corresponding (SCTP) association need to be = identified? It's all over UDP, anyway. On receipt of ICMP PTB, drop = down to 1200 bytes (IPv4) or 1280 bytes (IPv6), or be smarter about the = reduction (e.g., the table at = https://tools.ietf.org/html/rfc1191#page-17 or Iljitsch's recent = research to find common MTUs on today's Internet). >>>> The current way SCTP processes ICMP messages is: >>>> * Find the SCTP association based on IP addresses and port numbers >>>> * Verify the verification tag contained in the SCTP common header = contained in the ICMP message >>>> * Process the ICMP message... >>>> This clearly ICMP messages can't be processed by SCTP since = especially the vtag check can't be done. >>>>=20 >>>> But you are right: >>>> * UDP could notify its upper layer that it has received the ICMP = PTB message (and possibly could provide a hint). >>>> * DTLS could pass this through to its upper layer. >>>> * SCTP could process it for all associations running over that DTLS = connection bypassing >>>> the vtag check. >>>>=20 >>>> However, you loose the protection provided by the vtag check. An = attacker knowing >>>> the IP-addresses and UDP port numbers can inject such an ICMP = packet. >>>> SCTP normally requires that the sender of the packet does know the = vtag. >>>=20 >>> To prevent similar off-path attacks, many TCP implementations = validate the sequence number of ICMPs = (https://tools.ietf.org/html/rfc5927#section-4.1). The TCP sequence = number is in the same place as SCTP's VTAG (both are immediately after = the port numbers), so SCTP's VTAG should be returned in ICMP PTB as = often as TCP sequence numbers are returned in ICMP PTBs. = https://tools.ietf.org/html/rfc1812#section-4.3.2.3 increased the = recommended size of ICMPs, and I understand is pretty well deployed. >> You are right, this would work for SCTP/UDP/ICMP, but we are using = SCTP/DTLS/UDP/ICMP. >> So SCTP would get the encrypted SCTP packet, which is useless. I = haven't seen DTLS decrypting >> the partial packets. Therefore the TSVWG suggests using the method = described in RFC4821. >=20 > Seems this highlights a more general problem with validating any ICMP = error for a DTLS packet, which should have sanity checks performed = (similar to sanity checks of SCTP VTAG and TCP sequence numbers). DTLS = has some fields in the clear which would be returned in ICMP (epoch and = sequence number), but unfortunately they are not randomized like SCTP = VTAG or TCP sequence=20 Correct. > numbers. I'll bring that up on TSVWG. Great. Thanks. Best regards Michael >=20 > -d >=20 >=20 >>=20 >> Best regards >> Michael=20 >>>=20 >>> -d >>>=20 >>>=20 >>>> Therefore the way currently specified is that PMTUD as specified in = RFC4821 >>>> is used. This does not depend on incoming ICMP messages. They might = be blocked >>>> in the network or the DTLS layer might not pass them through. >>>>=20 >>>> If you think we should change the SCTP over DTLS ID, please bring = this up at tsvwg@. >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> -d >>>>>=20 >>>>>=20 >>>>>> Therefore SCTP MUST support performing Path MTU >>>>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>>>> using probing messages specified in [RFC4820]. The initial Path = MTU >>>>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 = for >>>>>> IPv6. >>>>>>=20 >>>>>> in = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>>>> states that SCTP does PMTUD using the first option above. >>>>>>=20 >>>>>> Which text are you missing? >>>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Albrecht >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Michael Tuexen >>>>>>> Sent: Donnerstag, 15. Januar 2015 09:42 >>>>>>> To: Christer Holmberg >>>>>>> Cc: rtcweb@ietf.org >>>>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS = heartbeat >>>>>>>=20 >>>>>>>> On 15 Jan 2015, at 05:45, Christer Holmberg = wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I don't think the sctp-dtls-encaps draft shall contain data = channel specific procedures. >>>>>>> It doesn't. It only makes clear which of the two options are = used in RTCWeb. >>>>>>>>=20 >>>>>>>> I agree with Martin that the best place is the data channel = draft. >>>>>>> So you think the text in the data channel draft is not enough? = It is and was clear to me that SCTP does the PMTUD, not DTLS, when SCTP = over DTLS is used in RTCWeb.=20 >>>>>>>=20 >>>>>>> Best regards >>>>>>> Michael >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Christer >>>>>>>>=20 >>>>>>>> Sent from my Windows Phone >>>>>>>> From: Michael Tuexen >>>>>>>> Sent: =E2=80=8E15/=E2=80=8E01/=E2=80=8E2015 00:40 >>>>>>>> To: Harald Alvestrand >>>>>>>> Cc: rtcweb@ietf.org >>>>>>>> Subject: Re: [rtcweb] Question about support for RFC 6520 DTLS=20= >>>>>>>> heartbeat >>>>>>>>=20 >>>>>>>> On 14 Jan 2015, at 23:12, Harald Alvestrand = wrote: >>>>>>>>>=20 >>>>>>>>> Den 14. jan. 2015 21:06, skrev Michael Tuexen: >>>>>>>>>> On 14 Jan 2015, at 18:17, Martin Thomson = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On 14 January 2015 at 00:49, Michael Tuexen=20 >>>>>>>>>>> wrote: >>>>>>>>>>>> * DTLS does the PMTUD using DTLS heartbeats >>>>>>>>>>>> * SCTP does the PMTUD using SCTP HEARTBEAT and PADDING = chunks >>>>>>>>>>>>=20 >>>>>>>>>>>> My understanding is the RTCWeb uses the second option as=20 >>>>>>>>>>>> described in >>>>>>>>>>>> = http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#sect >>>>>>>>>>>> ion-5 >>>>>>>>>>>=20 >>>>>>>>>>> SGTM. That means we don't need to reference the DTLS = heartbleed extension. >>>>>>>>>> It is not referenced in the RTCWeb documents, only in >>>>>>>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07 >>>>>>>>>> which allows both options. >>>>>>>>>=20 >>>>>>>>> So which document should we put it in that we use the second = option? >>>>>>>>> -transport, or a post-last-call update of -datachannel? >>>>>>>> Do we really need a change? We have in >>>>>>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 >>>>>>>> Incoming ICMP or ICMPv6 messages can't be processed by the SCTP >>>>>>>> layer, since there is no way to identify the corresponding >>>>>>>> association. Therefore SCTP MUST support performing Path MTU >>>>>>>> discovery without relying on ICMP or ICMPv6 as specified in = [RFC4821] >>>>>>>> using probing messages specified in [RFC4820]. The initial = Path MTU >>>>>>>> at the IP layer SHOULD NOT exceed 1200 bytes for IPv4 and 1280 = for >>>>>>>> IPv6. >>>>>>>>=20 >>>>>>>> In the next revision of >>>>>>>> = https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-07#secti >>>>>>>> on-4 >>>>>>>> there will be the sentence: >>>>>>>> The path MTU discovery is performed by SCTP when SCTP over DTLS = is >>>>>>>> used for data channels (see Section 4 of >>>>>>>> [I-D.ietf-rtcweb-data-channel]). >>>>>>>>=20 >>>>>>>> Best regards >>>>>>>> Michael >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Best regards >>>>>>>>>> Michael >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> rtcweb mailing list >>>>>>>>>> rtcweb@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> rtcweb mailing list >>>>>>>>> rtcweb@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>>>>>>=20 >>>>>>>>=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 >>>=20 >>=20 >=20 >=20 From nobody Wed Jan 21 14:19: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 4FD071A1A34 for ; Wed, 21 Jan 2015 14:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD6zUNsb94uK for ; Wed, 21 Jan 2015 14:19:37 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8978E1A00BB for ; Wed, 21 Jan 2015 14:19:37 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id ft15so23156529pdb.5 for ; Wed, 21 Jan 2015 14:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Y4NJxH1L767DGMDkuCrbehH0SFaMyX3mhDPP56JeG80=; b=GZLOz3fSics0Kvfgi9cUO3tddo/iZ/EFhvMF3BYnDnhYBXKCWygZUuQxLwZ/tdtBSg 2b7CaGQWXFOoFNvM8VsLr5MYLe4G3TU8CMhmbuYeDUIDMTrjMsrWDZgd2P5ExP85xd9m TyCuNbc5JyBQnudd2OsWHnwoec2mfhplwcXjYwpFCqAH88tuq4jhR6T7h3sjbtu4snfg DGfUmC3rBvxoyDIhn5lmlkX1WfoqIE59FaHkPrp91Y+6wPymYVe2C0axVJLjJgsr7oih 9YCGduY4zDaiahdl+LddEnrgdH9tBwA1oPGTjYdrjqziReU4J9g2PsC7V51DoqwBAICO CtMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Y4NJxH1L767DGMDkuCrbehH0SFaMyX3mhDPP56JeG80=; b=c1OhRbQrv4/YyOs31UpOjIQypkzIk0BU7U05k+U3LiPMDAodwgNjRhiuJfxOjhUJnk pdDNGD1No8dTb+iWJ231nqjIq5yTNGQYR37gkRgr47xWx+CpJsMcPbwU2GkftAH4I+TL /rpLP97Dox/SBSCc6vJTtQIxao+osn2Td1T7cDoSMmHtGma7GnysoUx6AUv0B/XV5DwP DJlYp7Fmi3Fhi8Kg7b3hLIsx0BOlxQeU4V78oji1rNkRLCwYmf2hECQ3HFe0ZZnJMmko QofwGq6qyu6lyL1YSm5i6rNvaxKLOpjNvvPOOujyELXksUoB8b+2/Wgz/PA8nXKNj9IA f78g== X-Gm-Message-State: ALoCoQlaKtcM8HUFMkKPD3C7R2ZXLgpyLINgrrUbjJAvWID+87YN5tepf+DMdmeALBjrorSxXTXq X-Received: by 10.68.242.8 with SMTP id wm8mr56478348pbc.32.1421878776716; Wed, 21 Jan 2015 14:19:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.86.167 with HTTP; Wed, 21 Jan 2015 14:18:56 -0800 (PST) From: Peter Thatcher Date: Wed, 21 Jan 2015 14:18:56 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=047d7b339c37667b99050d30f3e0 Archived-At: Subject: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 21 Jan 2015 22:19:38 -0000 --047d7b339c37667b99050d30f3e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BW=E2=80=8B e're =E2=80=8Bworking on implementing draft-ietf-mmusic-sctp-sdp-12 and going th= rough the process of making the change while not breaking things and we'd like to not have to do this a second time. Before making this change, I'd like to be doubly clear that I got the right value for data channel m-lines: =E2=80=8B=E2=80=8B "UDP/DTLS/SCTP" =E2=80=8B (or "TCP/DTLS/SCTP") =E2=80=8BIs that for sure the right value?=E2=80=8B =E2=80=8B --047d7b339c37667b99050d30f3e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BW=E2=80=8B
e're
=E2=80=8Bworking on implementing draft-ietf-mmusic-sctp-sdp-12 = and going through the process of making the change while not breaking thing= s and we'd like to not have to do this a second time. Before making thi= s change, I'd like to be doubly clear that I got the right value for da= ta channel m-lines:
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;display:inline">=E2=80=8B=E2=80=8B

"UDP/DTLS/SCTP&quo= t;
=E2=80=8B (or "TCP/DTLS/SCTP")



=E2=80=8BIs that for sure the ri= ght value?=E2=80=8B
=E2=80=8B



--047d7b339c37667b99050d30f3e0-- From nobody Wed Jan 21 17:31: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 DE88C1A00CF for ; Wed, 21 Jan 2015 17:31:20 -0800 (PST) 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_12=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 UDVKk-1wPH3y for ; Wed, 21 Jan 2015 17:31:20 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6741A00CD for ; Wed, 21 Jan 2015 17:31:19 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id p10so41649648pdj.1 for ; Wed, 21 Jan 2015 17:31:19 -0800 (PST) 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=JfgFO6eQTFgAHFJROiCLJV6xPjkFA2lqmcT4AWCoiN4=; b=cuGBjoARNS9JfEmaEFBzHfUTZIZcbjP6pppQ+5p9ele+TUskg7IWJLvep7Gfwe2AIO 3vUOurPjyI4ZNU74s3XY5jOYGDf82MkVxJ/Xn567+WrSA6lwrr+ZIL0NTCzqa/8rDcFk tNuz3TdF4wxxHB0ecgmgl92kYPGl2568mXtFqQy2M5wKsj4akx4fCrBVwuva6bIcgQHj T+m5BhHRob+tl472z2t39sHldNUvhVkPWczRwH8oh8iZa4DmCAz27yiNSOht2NJdJyCF +u6o0q9ktr6NT8GxWplXJxnQQypfZ2NXAcp3UPHg9zkyauchjv3evaSfJeCVwryUvCDn ukww== MIME-Version: 1.0 X-Received: by 10.66.255.99 with SMTP id ap3mr66110235pad.55.1421890279168; Wed, 21 Jan 2015 17:31:19 -0800 (PST) Received: by 10.70.103.200 with HTTP; Wed, 21 Jan 2015 17:31:19 -0800 (PST) In-Reply-To: References: Date: Wed, 21 Jan 2015 17:31:19 -0800 Message-ID: From: Suhas Nandakumar To: Peter Thatcher Content-Type: multipart/alternative; boundary=047d7b15fc15fff64e050d33a063 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 01:31:21 -0000 --047d7b15fc15fff64e050d33a063 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable They look right to me ..would let Christer confirm though Cheers Suhas On Wednesday, January 21, 2015, Peter Thatcher wrote= : > =E2=80=8BW=E2=80=8B > e're > =E2=80=8Bworking on implementing draft-ietf-mmusic-sctp-sdp-12 and going = through > the process of making the change while not breaking things and we'd like = to > not have to do this a second time. Before making this change, I'd like to > be doubly clear that I got the right value for data channel m-lines: > =E2=80=8B=E2=80=8B > > "UDP/DTLS/SCTP" > =E2=80=8B (or "TCP/DTLS/SCTP") > > > > =E2=80=8BIs that for sure the right value?=E2=80=8B > =E2=80=8B > > > > --047d7b15fc15fff64e050d33a063 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable They look right to=C2=A0me ..would let Christer confirm though=

Cheers
Suhas

On Wednesday, January 21,= 2015, Peter Thatcher <pthatcher= @google.com> wrote:
=E2=80=8BW=E2=80=8B
e're
= =E2=80=8Bworking on implementing draft-ietf-mmusic-sctp-sdp-12 and going th= rough the process of making the change while not breaking things and we'= ;d like to not have to do this a second time. Before making this change, I&= #39;d like to be doubly clear that I got the right value for data channel m= -lines:
=E2=80=8B=E2=80=8B

"UDP/DTLS/SCTP"
=E2=80=8B (or "TCP/DTLS/SCTP")



=E2=80=8BIs that for sure the right value?= =E2=80=8B
=E2=80=8B



--047d7b15fc15fff64e050d33a063-- From nobody Wed Jan 21 21:37: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 8E9E41AC3B8 for ; Wed, 21 Jan 2015 21:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dXjZ3jzBxBl for ; Wed, 21 Jan 2015 21:37:05 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2610D1AC3FC for ; Wed, 21 Jan 2015 21:37:05 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id rd18so17258327iec.7 for ; Wed, 21 Jan 2015 21:37:04 -0800 (PST) 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=+GnaW7AimFCtINWYdMs6nhhx9SA8OujEVNJW/bT9SjA=; b=BiHQuHjZHyGRkl/T7qOjcfs04rrUff/Pt5jiwy/PbfjotSIkoAGNhR1To2mtbNrZZK m4EEEpqswFIGPflbL13YPY5Xu72ZLZD4rK7Kvnz/3GNGCJvAo96FjnqEsGbfQdHI8XG9 TuXVe9qrEb7SKhA3fMPX8m5o+lH1YftG2CLugZ/XwDchosNI9Rszs75e308hH81Kvfnb QdkovYZUxSz8KKTd6xW+2kuECNMSaDetFQXHf6YT3SiDqXNunBhBMKDiKVtwkeoPnXzg 6+ZIBo0BNNssj69HDf/fvTW8YLBmxvfqEAg6mwXDuwRJzyfFVAEfqJX+hPsM0wSVKDci ikiQ== 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=+GnaW7AimFCtINWYdMs6nhhx9SA8OujEVNJW/bT9SjA=; b=cgaJG2wFc6Ma/ZeNwlYeU+n0EARPqMdVBnfG5fSCiU4fPxyvgn4SG9LYcrA1YoHs1F 0AAnSpy2nYQA/xSv9qqxAtQiwnnJKY81c0zmvXIaHzU8PhZRdwgLXGynSz/TmUAZ2a6X BKqf2FyKG3gedh6dAoE0916qUSOlA5y6Sc1Oo2+7cfKAU9o+x7zUkjSk+mEZWw5+6HVN KSHWV4XlQ7u63VkMbIk5FzVW79wUwigJERRD8yew8ZDORDjF0XXxrUD5IiaEDVVCk223 xmpokNEv25pdnz2UN+vLP72rBtJ5AwYcMo+KLt4WUY8XTwP0FAxANa0D9Bigu3t/azCk Jc9Q== X-Gm-Message-State: ALoCoQnUQxBi++PEYsbZs28kzQcgY6s0CZEWE/4s/A4fRtDQaaltI23lv/Bf8o8yTKYXY1prsNU4 X-Received: by 10.50.79.196 with SMTP id l4mr9717733igx.14.1421905024234; Wed, 21 Jan 2015 21:37:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Wed, 21 Jan 2015 21:36:44 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Wed, 21 Jan 2015 21:36:44 -0800 Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=089e01183f48dfd07b050d370fa4 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 05:37:06 -0000 --089e01183f48dfd07b050d370fa4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The open question was whether this should be UDP/DTLS/SCTP, or UDP/TLS/SCTP (DTLS implicit) to match the existing UDP/TLS/RTP/SAVPF values defined in 5763. Upside of TLS: consistent with precedent Upside of DTLS: less confusing On Wed, Jan 21, 2015 at 5:31 PM, Suhas Nandakumar wrote: > They look right to me ..would let Christer confirm though > > Cheers > Suhas > > > On Wednesday, January 21, 2015, Peter Thatcher > wrote: > >> =E2=80=8BW=E2=80=8B >> e're >> =E2=80=8Bworking on implementing draft-ietf-mmusic-sctp-sdp-12 and going= through >> the process of making the change while not breaking things and we'd like= to >> not have to do this a second time. Before making this change, I'd like t= o >> be doubly clear that I got the right value for data channel m-lines: >> =E2=80=8B=E2=80=8B >> >> "UDP/DTLS/SCTP" >> =E2=80=8B (or "TCP/DTLS/SCTP") >> >> >> >> =E2=80=8BIs that for sure the right value?=E2=80=8B >> =E2=80=8B >> >> >> >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01183f48dfd07b050d370fa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The open question was whether this should be UDP/DTLS/SCTP= , or UDP/TLS/SCTP (DTLS implicit) to match the existing UDP/TLS/RTP/SAVPF v= alues defined in 5763.

Upside of TLS: consistent with pr= ecedent
Upside of DTLS: less confusing

On Wed, Jan 21, 2015 at 5:31 PM,= Suhas Nandakumar <suhasietf@gmail.com> wrote:
They look right to=C2=A0me ..would let = Christer confirm though

Cheers
Suhas
<= br>
On Wednesday, January 21, 2015, Peter Thatcher <pthatcher@google.com> wrote= :
=E2= =80=8BW=E2=80=8B
e're
=E2=80=8Bworking on implem= enting draft-ietf-mmusic-sctp-sdp-12 and going through the process of makin= g the change while not breaking things and we'd like to not have to do = this a second time. Before making this change, I'd like to be doubly cl= ear that I got the right value for data channel m-lines:
=E2=80=8B=E2=80=8B
"UDP/DTLS/SCTP"
=E2=80=8B (or &q= uot;TCP/DTLS/SCTP")

=


=E2=80=8BIs that for sure the right value?=E2=80=8B
=E2=80=8B<= /span>




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


--089e01183f48dfd07b050d370fa4-- From nobody Wed Jan 21 22:48: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 CEDD51AC429 for ; Wed, 21 Jan 2015 22:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ItsKu1O_8BI for ; Wed, 21 Jan 2015 22:48:51 -0800 (PST) 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 CF0C11AC41B for ; Wed, 21 Jan 2015 22:48:50 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-f3-54c09d503f85 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.1E.04076.05D90C45; Thu, 22 Jan 2015 07:48:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 07:48:48 +0100 From: Christer Holmberg To: Justin Uberti , Suhas Nandakumar Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQNeMkjl7vTJczQUSu87vEXJpiCpzLjkYAgAAj2jA= Date: Thu, 22 Jan 2015 06:48:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D675340@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D675340ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3Rjdg7oEQg5UfTS22ThWyWPuvnd1i 59wOZgdmj52z7rJ7LNhU6rFkyU+mAOYoLpuU1JzMstQifbsErozz014zFewrqHi4/yF7A+OO 3C5GTg4JAROJ3mNvGCFsMYkL99azdTFycQgJHGGUuHFkPTuEs5hRYvLdjSxdjBwcbAIWEt3/ tEEaRAT8JI5OXMkKYjMLaEpMWLaLDcQWFgiUuDBrBRtETZDE1PnzWSBsK4ltHZeZQGwWAVWJ y+eWgNXwCvhK/JzcwAKx6x6jxIVzH8GGcgINWvJlEVgzI9B130+tYYJYJi5x68l8JoirBSSW 7DnPDGGLSrx8/I8VwlaSWHt4OwtEfb7Exd9PWCGWCUqcnPmEZQKj6Cwko2YhKZuFpGwW0Msg v63fpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHx d3DLb6sdjAefOx5iFOBgVOLhLfDbHyLEmlhWXJl7iFGag0VJnDfPYUOIkEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBsYFR+78VS5aveWujeDjpRG1F5jvRV8KfWR6w7Rbe5dT7op13ocPCzms ZrxynHE+47qEy3Js0j48DU8vRhxRbgkJiJ2WXrR/8zHpTl7h6RHKkc/e5eY6/9p8tu97HtOH n13rFs+LaMg7eFW72UEwf2ub6JM+15aKRXb1EacCSueUvV1wqLpcPlCJpTgj0VCLuag4EQCw H3KGoAIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 06:48:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D675340ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG91dGNvbWUgb2YgdGhlIGRpc2N1c3Npb25z IHdhcyB0aGF0IHdlIHdlcmUgZ29pbmcgdG8gdXNlIOKAnERUTFPigJ0uDQoNCkJ1dCwgcGVyc29u YWxseSBJIGNvdWxkIGxpdmUgd2l0aCBib3RoLCBzbyBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdy b25nIEnigJltIGhhcHB5IHRvIGNoYW5nZSB0aGUgZHJhZnQgOikNCg0KTm90ZSwgaG93ZXZlciwg dGhhdCBJRiB3ZSBjaGFuZ2UgdG8g4oCcVExT4oCdLCB0aGVuIEkgZ3Vlc3Mgd2UgYWxzbyBuZWVk IHRvIGRpc2N1c3MgdGhlIOKAnFNDVFAvRFRMU+KAnSB2YWx1ZSwgYW5kIHdoZXRoZXIgaXQgc2hv dWxkIGJlIOKAnFNDVFAvVExT4oCdIGluc3RlYWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDIyIEphbnVhcnkgMjAxNSAwNzozNw0KVG86IFN1 aGFzIE5hbmRha3VtYXINCkNjOiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3 ZWJdIEl0J3MgIlVEUC9EVExTL1NDVFAiIGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJp Z2h0Pw0KDQpUaGUgb3BlbiBxdWVzdGlvbiB3YXMgd2hldGhlciB0aGlzIHNob3VsZCBiZSBVRFAv RFRMUy9TQ1RQLCBvciBVRFAvVExTL1NDVFAgKERUTFMgaW1wbGljaXQpIHRvIG1hdGNoIHRoZSBl eGlzdGluZyBVRFAvVExTL1JUUC9TQVZQRiB2YWx1ZXMgZGVmaW5lZCBpbiA1NzYzLg0KDQpVcHNp ZGUgb2YgVExTOiBjb25zaXN0ZW50IHdpdGggcHJlY2VkZW50DQpVcHNpZGUgb2YgRFRMUzogbGVz cyBjb25mdXNpbmcNCg0KT24gV2VkLCBKYW4gMjEsIDIwMTUgYXQgNTozMSBQTSwgU3VoYXMgTmFu ZGFrdW1hciA8c3VoYXNpZXRmQGdtYWlsLmNvbTxtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbT4+ IHdyb3RlOg0KVGhleSBsb29rIHJpZ2h0IHRvIG1lIC4ud291bGQgbGV0IENocmlzdGVyIGNvbmZp cm0gdGhvdWdoDQoNCkNoZWVycw0KU3VoYXMNCg0KDQpPbiBXZWRuZXNkYXksIEphbnVhcnkgMjEs IDIwMTUsIFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRj aGVyQGdvb2dsZS5jb20+PiB3cm90ZToNCuKAi1figIsNCmUncmUNCuKAi3dvcmtpbmcgb24gaW1w bGVtZW50aW5nIGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLTEyIGFuZCBnb2luZyB0aHJvdWdo IHRoZSBwcm9jZXNzIG9mIG1ha2luZyB0aGUgY2hhbmdlIHdoaWxlIG5vdCBicmVha2luZyB0aGlu Z3MgYW5kIHdlJ2QgbGlrZSB0byBub3QgaGF2ZSB0byBkbyB0aGlzIGEgc2Vjb25kIHRpbWUuIEJl Zm9yZSBtYWtpbmcgdGhpcyBjaGFuZ2UsIEknZCBsaWtlIHRvIGJlIGRvdWJseSBjbGVhciB0aGF0 IEkgZ290IHRoZSByaWdodCB2YWx1ZSBmb3IgZGF0YSBjaGFubmVsIG0tbGluZXM6DQrigIvigIsN Cg0KIlVEUC9EVExTL1NDVFAiDQrigIsgKG9yICJUQ1AvRFRMUy9TQ1RQIikNCg0KDQoNCuKAi0lz IHRoYXQgZm9yIHN1cmUgdGhlIHJpZ2h0IHZhbHVlP+KAiw0K4oCLDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBs aXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D675340ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5NeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBvdXRjb21lIG9mIHRoZSBkaXNjdXNzaW9u cyB3YXMgdGhhdCB3ZSB3ZXJlIGdvaW5nIHRvIHVzZSDigJxEVExT4oCdLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CdXQsIHBlcnNvbmFsbHkgSSBjb3VsZCBsaXZl IHdpdGggYm90aCwgc28gaWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZyBJ4oCZbSBoYXBweSB0 byBjaGFuZ2UgdGhlIGRyYWZ0IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5Ob3RlLCBob3dldmVyLCB0aGF0IElGIHdlIGNoYW5nZSB0byDigJxUTFPigJ0sIHRoZW4g SSBndWVzcyB3ZSBhbHNvIG5lZWQgdG8gZGlzY3VzcyB0aGUg4oCcU0NUUC9EVExT4oCdIHZhbHVl LCBhbmQgd2hldGhlciBpdCBzaG91bGQgYmUg4oCcU0NUUC9UTFPigJ0NCiBpbnN0ZWFkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiAyMiBKYW51YXJ5IDIwMTUg MDc6Mzc8YnI+DQo8Yj5Ubzo8L2I+IFN1aGFzIE5hbmRha3VtYXI8YnI+DQo8Yj5DYzo8L2I+ICZs dDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBJ dCdzICZxdW90O1VEUC9EVExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5l cywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG9wZW4g cXVlc3Rpb24gd2FzIHdoZXRoZXIgdGhpcyBzaG91bGQgYmUgVURQL0RUTFMvU0NUUCwgb3IgVURQ L1RMUy9TQ1RQIChEVExTIGltcGxpY2l0KSB0byBtYXRjaCB0aGUgZXhpc3RpbmcgVURQL1RMUy9S VFAvU0FWUEYgdmFsdWVzIGRlZmluZWQgaW4gNTc2My48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVwc2lkZSBvZiBUTFM6IGNvbnNpc3RlbnQgd2l0aCBwcmVj ZWRlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlVwc2lkZSBvZiBEVExTOiBsZXNzIGNvbmZ1c2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyMSwgMjAxNSBhdCA1OjMx IFBNLCBTdWhhcyBOYW5kYWt1bWFyICZsdDs8YSBocmVmPSJtYWlsdG86c3VoYXNpZXRmQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN1aGFzaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGV5IGxv b2sgcmlnaHQgdG8mbmJzcDttZSAuLndvdWxkIGxldCBDaHJpc3RlciBjb25maXJtIHRob3VnaDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+U3VoYXM8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQpPbiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIwMTUsIFBldGVyIFRoYXRjaGVyICZs dDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5w dGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAi1figIs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmUncmUgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAi3dvcmtpbmcgb24gaW1wbGVtZW50 aW5nIGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwLTEyIGFuZCBnb2luZyB0aHJvdWdoIHRoZSBw cm9jZXNzIG9mIG1ha2luZyB0aGUgY2hhbmdlIHdoaWxlIG5vdCBicmVha2luZyB0aGluZ3MgYW5k IHdlJ2QgbGlrZSB0byBub3QgaGF2ZSB0byBkbyB0aGlzIGEgc2Vjb25kIHRpbWUuIEJlZm9yZQ0K IG1ha2luZyB0aGlzIGNoYW5nZSwgSSdkIGxpa2UgdG8gYmUgZG91Ymx5IGNsZWFyIHRoYXQgSSBn b3QgdGhlIHJpZ2h0IHZhbHVlIGZvciBkYXRhIGNoYW5uZWwgbS1saW5lczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAi+KA izxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KJnF1b3Q7VURQL0RUTFMvU0NUUCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj7igIsgKG9yICZxdW90O1RDUC9EVExTL1NDVFAmcXVvdDspPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+4oCLSXMgdGhhdCBmb3Igc3VyZSB0aGUg cmlnaHQgdmFsdWU/4oCLPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+4oCLPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2Vi IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D675340ESESSMB209erics_-- From nobody Thu Jan 22 00: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 8E36B1A8A1E for ; Thu, 22 Jan 2015 00:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Jcny7hEyMsE for ; Thu, 22 Jan 2015 00:23:47 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA631A0250 for ; Thu, 22 Jan 2015 00:23:47 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9C6957E5EACAE; Thu, 22 Jan 2015 08:23:43 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t0M8Nhi9007500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 09:23:43 +0100 Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.99]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 09:23:43 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , Justin Uberti , Suhas Nandakumar Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQNeMluJS9amIp3kmwwacf+b4ZH5zLjkYAgAAUIYCAACly0A== Date: Thu, 22 Jan 2015 08:23:42 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC4B360F87FR711WXCHMBA01z_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 08:23:50 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC4B360F87FR711WXCHMBA01z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVzcGl0ZSB0aGUgZmFjdCBvZiBjbG9hc2UgYWxpZ25tZW50IGJldHdlZW4gcHJvdG9jb2xzIERU TFMgYW5kIFRMUywgYm90aCBhcmUgc3RpbGwgZGlmZmVyZW50IHByb3RvY29scyAoZS5nLiBjYXBh YmlsaXRpZXMgY29uY2VybmluZyBhc3N1cmVkIG9yIG5vbi1hc3N1cmVkIEw0IHRyYW5zcG9ydCwg cHJvdG9jb2wgdmVyc2lvbmluZywg4oCmKS4NCg0KVGh1cywgbXkgcHJlZmVyZW5jZSB3b3VsZCBi ZSB0byB1c2UgdG8gY29ycmVjdCBuYW1lLCBpLmUuLCDigJxEVExT4oCdIGFuZCBub3QgYW55IGlu ZGlyZWN0IGluZGljYXRpb24gc3VjaCBhcyBUTFMgYmFzZWQuDQpBbHNvIGJlY2F1c2Ugb2YgdGhl IHByb3RvY29sIHN0YWNrIHNlZ21lbnQg4oCcVENQL0RUTFMvU0NUUOKAnSAo4oCcdGhlIGluZGly ZWN0IGFwcHJvYWNoIHdvdWxkIGJlIHdoYXQ/IOKAnFRDUC9UTFMvU0NUUOKAnT/igJ0gd2hpY2gg bGVhZHMgdG8gYW1iaWd1aXRpZXMg4oCmIGR1ZSB0byBuYXRpdmUg4oCcVENQL1RMUy/igKbigJ0g bGF5ZXJpbmcgYW5kIFJUQ1dFQiByZXF1aXJlZCDigJxUQ1AvRFRMUy/igKYg4oCcIGxheWVyaW5n KS4NCg0KUmVnYXJkcywNCkFsYnJlY2h0DQoNCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50 OiBEb25uZXJzdGFnLCAyMi4gSmFudWFyIDIwMTUgMDc6NDkNClRvOiBKdXN0aW4gVWJlcnRpOyBT dWhhcyBOYW5kYWt1bWFyDQpDYzogPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBJdCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxpbmVzLCBy aWdodD8NCg0KSGksDQoNCk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG91dGNvbWUgb2YgdGhlIGRp c2N1c3Npb25zIHdhcyB0aGF0IHdlIHdlcmUgZ29pbmcgdG8gdXNlIOKAnERUTFPigJ0uDQoNCkJ1 dCwgcGVyc29uYWxseSBJIGNvdWxkIGxpdmUgd2l0aCBib3RoLCBzbyBpZiBteSB1bmRlcnN0YW5k aW5nIGlzIHdyb25nIEnigJltIGhhcHB5IHRvIGNoYW5nZSB0aGUgZHJhZnQgOikNCg0KTm90ZSwg aG93ZXZlciwgdGhhdCBJRiB3ZSBjaGFuZ2UgdG8g4oCcVExT4oCdLCB0aGVuIEkgZ3Vlc3Mgd2Ug YWxzbyBuZWVkIHRvIGRpc2N1c3MgdGhlIOKAnFNDVFAvRFRMU+KAnSB2YWx1ZSwgYW5kIHdoZXRo ZXIgaXQgc2hvdWxkIGJlIOKAnFNDVFAvVExT4oCdIGluc3RlYWQuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDIyIEphbnVhcnkgMjAxNSAwNzoz Nw0KVG86IFN1aGFzIE5hbmRha3VtYXINCkNjOiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3 ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEl0J3MgIlVEUC9EVExTL1NDVFAi IGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0KDQpUaGUgb3BlbiBxdWVzdGlv biB3YXMgd2hldGhlciB0aGlzIHNob3VsZCBiZSBVRFAvRFRMUy9TQ1RQLCBvciBVRFAvVExTL1ND VFAgKERUTFMgaW1wbGljaXQpIHRvIG1hdGNoIHRoZSBleGlzdGluZyBVRFAvVExTL1JUUC9TQVZQ RiB2YWx1ZXMgZGVmaW5lZCBpbiA1NzYzLg0KDQpVcHNpZGUgb2YgVExTOiBjb25zaXN0ZW50IHdp dGggcHJlY2VkZW50DQpVcHNpZGUgb2YgRFRMUzogbGVzcyBjb25mdXNpbmcNCg0KT24gV2VkLCBK YW4gMjEsIDIwMTUgYXQgNTozMSBQTSwgU3VoYXMgTmFuZGFrdW1hciA8c3VoYXNpZXRmQGdtYWls LmNvbTxtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhleSBsb29rIHJpZ2h0 IHRvIG1lIC4ud291bGQgbGV0IENocmlzdGVyIGNvbmZpcm0gdGhvdWdoDQoNCkNoZWVycw0KU3Vo YXMNCg0KDQpPbiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIwMTUsIFBldGVyIFRoYXRjaGVyIDxw dGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+PiB3cm90ZToN CuKAi1figIsNCmUncmUNCuKAi3dvcmtpbmcgb24gaW1wbGVtZW50aW5nIGRyYWZ0LWlldGYtbW11 c2ljLXNjdHAtc2RwLTEyIGFuZCBnb2luZyB0aHJvdWdoIHRoZSBwcm9jZXNzIG9mIG1ha2luZyB0 aGUgY2hhbmdlIHdoaWxlIG5vdCBicmVha2luZyB0aGluZ3MgYW5kIHdlJ2QgbGlrZSB0byBub3Qg aGF2ZSB0byBkbyB0aGlzIGEgc2Vjb25kIHRpbWUuIEJlZm9yZSBtYWtpbmcgdGhpcyBjaGFuZ2Us IEknZCBsaWtlIHRvIGJlIGRvdWJseSBjbGVhciB0aGF0IEkgZ290IHRoZSByaWdodCB2YWx1ZSBm b3IgZGF0YSBjaGFubmVsIG0tbGluZXM6DQrigIvigIsNCg0KIlVEUC9EVExTL1NDVFAiDQrigIsg KG9yICJUQ1AvRFRMUy9TQ1RQIikNCg0KDQoNCuKAi0lzIHRoYXQgZm9yIHN1cmUgdGhlIHJpZ2h0 IHZhbHVlP+KAiw0K4oCLDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViDQoNCg== --_000_786615F3A85DF44AA2A76164A71FE1AC4B360F87FR711WXCHMBA01z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4w cHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJ e21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkRlc3BpdGUgdGhlIGZhY3Qgb2YgY2xvYXNlIGFsaWdubWVu dCBiZXR3ZWVuIHByb3RvY29scyBEVExTIGFuZCBUTFMsIGJvdGggYXJlIHN0aWxsIGRpZmZlcmVu dCBwcm90b2NvbHMgKGUuZy4gY2FwYWJpbGl0aWVzIGNvbmNlcm5pbmcgYXNzdXJlZCBvciBub24t YXNzdXJlZCBMNCB0cmFuc3BvcnQsDQogcHJvdG9jb2wgdmVyc2lvbmluZywg4oCmKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5UaHVzLCBt eSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIHVzZSB0byBjb3JyZWN0IG5hbWUsIGkuZS4sIOKAnERU TFPigJ0gYW5kIG5vdCBhbnkgaW5kaXJlY3QgaW5kaWNhdGlvbiBzdWNoIGFzIFRMUyBiYXNlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbHNv IGJlY2F1c2Ugb2YgdGhlIHByb3RvY29sIHN0YWNrIHNlZ21lbnQg4oCcVENQL0RUTFMvU0NUUOKA nSAo4oCcdGhlIGluZGlyZWN0IGFwcHJvYWNoIHdvdWxkIGJlIHdoYXQ/IOKAnFRDUC9UTFMvU0NU UOKAnT/igJ0gd2hpY2ggbGVhZHMgdG8gYW1iaWd1aXRpZXMg4oCmIGR1ZSB0byBuYXRpdmUg4oCc VENQL1RMUy/igKbigJ0NCiBsYXllcmluZyBhbmQgUlRDV0VCIHJlcXVpcmVkIOKAnFRDUC9EVExT L+KApiDigJwgbGF5ZXJpbmcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+QWxicmVjaHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxi PlNlbnQ6PC9iPiBEb25uZXJzdGFnLCAyMi4gSmFudWFyIDIwMTUgMDc6NDk8YnI+DQo8Yj5Ubzo8 L2I+IEp1c3RpbiBVYmVydGk7IFN1aGFzIE5hbmRha3VtYXI8YnI+DQo8Yj5DYzo8L2I+ICZsdDty dGN3ZWJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBJdCdz ICZxdW90O1VEUC9EVExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywg cmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkg dW5kZXJzdGFuZGluZyBvZiB0aGUgb3V0Y29tZSBvZiB0aGUgZGlzY3Vzc2lvbnMgd2FzIHRoYXQg d2Ugd2VyZSBnb2luZyB0byB1c2Ug4oCcRFRMU+KAnS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0LCBwZXJzb25h bGx5IEkgY291bGQgbGl2ZSB3aXRoIGJvdGgsIHNvIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3Jv bmcgSeKAmW0gaGFwcHkgdG8gY2hhbmdlIHRoZSBkcmFmdCA6KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm90ZSwgaG93 ZXZlciwgdGhhdCBJRiB3ZSBjaGFuZ2UgdG8g4oCcVExT4oCdLCB0aGVuIEkgZ3Vlc3Mgd2UgYWxz byBuZWVkIHRvIGRpc2N1c3MgdGhlIOKAnFNDVFAvRFRMU+KAnSB2YWx1ZSwgYW5kIHdoZXRoZXIg aXQgc2hvdWxkIGJlIOKAnFNDVFAvVExT4oCdIGluc3RlYWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYiBbPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IDIyIEphbnVhcnkg MjAxNSAwNzozNzxicj4NCjxiPlRvOjwvYj4gU3VoYXMgTmFuZGFrdW1hcjxicj4NCjxiPkNjOjwv Yj4gJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBJdCdzICZxdW90O1VEUC9E VExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG9wZW4gcXVlc3Rpb24gd2FzIHdo ZXRoZXIgdGhpcyBzaG91bGQgYmUgVURQL0RUTFMvU0NUUCwgb3IgVURQL1RMUy9TQ1RQIChEVExT IGltcGxpY2l0KSB0byBtYXRjaCB0aGUgZXhpc3RpbmcgVURQL1RMUy9SVFAvU0FWUEYgdmFsdWVz IGRlZmluZWQgaW4gNTc2My48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlVwc2lkZSBvZiBUTFM6IGNvbnNpc3RlbnQgd2l0aCBwcmVjZWRlbnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVwc2lkZSBvZiBEVExT OiBsZXNzIGNvbmZ1c2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyMSwgMjAxNSBhdCA1OjMxIFBNLCBTdWhhcyBOYW5k YWt1bWFyICZsdDs8YSBocmVmPSJtYWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnN1aGFzaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhleSBsb29rIHJpZ2h0IHRvJm5ic3A7bWUgLi53b3VsZCBsZXQgQ2hy aXN0ZXIgY29uZmlybSB0aG91Z2g8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNoZWVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4 ODgiPlN1aGFzPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KT24gV2VkbmVzZGF5LCBKYW51YXJ5IDIxLCAy MDE1LCBQZXRlciBUaGF0Y2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCL V+KAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ZSdyZSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+4oCLd29ya2luZyBvbiBpbXBsZW1lbnRpbmcgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAt MTIgYW5kIGdvaW5nIHRocm91Z2ggdGhlIHByb2Nlc3Mgb2YgbWFraW5nIHRoZSBjaGFuZ2Ugd2hp bGUgbm90IGJyZWFraW5nIHRoaW5ncyBhbmQgd2UnZCBsaWtlIHRvIG5vdCBoYXZlIHRvIGRvIHRo aXMgYSBzZWNvbmQgdGltZS4gQmVmb3JlDQogbWFraW5nIHRoaXMgY2hhbmdlLCBJJ2QgbGlrZSB0 byBiZSBkb3VibHkgY2xlYXIgdGhhdCBJIGdvdCB0aGUgcmlnaHQgdmFsdWUgZm9yIGRhdGEgY2hh bm5lbCBtLWxpbmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCL4oCLPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomcXVvdDtVRFAvRFRMUy9T Q1RQJnF1b3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPuKAiyAob3IgJnF1b3Q7VENQL0RUTFMvU0NUUCZxdW90Oyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igItJcyB0 aGF0IGZvciBzdXJlIHRoZSByaWdodCB2YWx1ZT/igIs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGll dGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_786615F3A85DF44AA2A76164A71FE1AC4B360F87FR711WXCHMBA01z_-- From nobody Thu Jan 22 03:08: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 CE7DA1AC443 for ; Thu, 22 Jan 2015 03:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP0uqPcNsmMp for ; Thu, 22 Jan 2015 03:08:47 -0800 (PST) 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 B34711AC447 for ; Thu, 22 Jan 2015 03:08:45 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-0d-54c0da3b07be Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.3A.24955.B3AD0C45; Thu, 22 Jan 2015 12:08:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 12:08:43 +0100 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , Justin Uberti , Suhas Nandakumar Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQNeMkjl7vTJczQUSu87vEXJpiCpzLjkYAgAAj2jCAAArMAIAAPr2g Date: Thu, 22 Jan 2015 11:08:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D675C09ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+Jvja7NrQMhBhd3Mlv8af3FaLF1qpDF 2n/t7BY753YwO7B4tD7by+qxc9Zddo8Fm0o9liz5yRTAEsVlk5Kak1mWWqRvl8CVcaBzN0vB j5WMFTNmzWVsYNyylLGLkZNDQsBE4t38n2wQtpjEhXvrgWwuDiGBI4wS3TPvQDmLGSUOz1rJ 3sXIwcEmYCHR/U8bJC4iMI1RonffPCaQbmYBTYkJy3aBTRIWCJS4MGsFmC0iECQxdf58Fgjb TeLhw1tg9SwCqhLnJ38Hi/MK+Ep8/7yLBWLZVyaJ9T/fgCU4BWIlTqzewwxiMwKd9/3UGqhl 4hK3nsxngjhbQGLJnvPMELaoxMvH/1ghbCWJFdsvMULU50tcb3nLBrFMUOLkzCcsExhFZyEZ NQtJ2SwkZbOAfgb5bf0ufYgSRYkp3Q/ZIWwNidY5c9mRxRcwsq9iFC1OLU7KTTcy1kstykwu Ls7P08tLLdnECIzMg1t+q+5gvPzG8RCjAAejEg/vh/kHQoRYE8uKK3MPMUpzsCiJ8+Y5bAgR EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCjobXaeXaOzVinZ7Oa1lAl7/u3/Eq3RvOYVh8KV a/dNV346Y+4962q/8YRVK5QvmWv0CixOD+TUnmmhOufktteuuSeLnGeeLgibznWiT/z31o8r DNRYFHzL1/Lvn7bVdMMXrpvMq6XD83mVp204vt7lymKVFsezcxz35jG/UsiMZ/N3/sAfJqzE UpyRaKjFXFScCAC4GcLrrQIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 11:08:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D675C09ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28sIHlvdSBzdXBwb3J0IHVzaW5nIOKAnERUTFPigJ0/IDopDQoNCkZyb206IFNjaHdhcnosIEFs YnJlY2h0IChBbGJyZWNodCkgW21haWx0bzphbGJyZWNodC5zY2h3YXJ6QGFsY2F0ZWwtbHVjZW50 LmNvbV0NClNlbnQ6IDIyIEphbnVhcnkgMjAxNSAxMDoyNA0KVG86IENocmlzdGVyIEhvbG1iZXJn OyBKdXN0aW4gVWJlcnRpOyBTdWhhcyBOYW5kYWt1bWFyDQpDYzogPHJ0Y3dlYkBpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBJdCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhlIGRhdGEg Y2hhbm5lbCBtLWxpbmVzLCByaWdodD8NCg0KRGVzcGl0ZSB0aGUgZmFjdCBvZiBjbG9hc2UgYWxp Z25tZW50IGJldHdlZW4gcHJvdG9jb2xzIERUTFMgYW5kIFRMUywgYm90aCBhcmUgc3RpbGwgZGlm ZmVyZW50IHByb3RvY29scyAoZS5nLiBjYXBhYmlsaXRpZXMgY29uY2VybmluZyBhc3N1cmVkIG9y IG5vbi1hc3N1cmVkIEw0IHRyYW5zcG9ydCwgcHJvdG9jb2wgdmVyc2lvbmluZywg4oCmKS4NCg0K VGh1cywgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byB1c2UgdG8gY29ycmVjdCBuYW1lLCBpLmUu LCDigJxEVExT4oCdIGFuZCBub3QgYW55IGluZGlyZWN0IGluZGljYXRpb24gc3VjaCBhcyBUTFMg YmFzZWQuDQpBbHNvIGJlY2F1c2Ugb2YgdGhlIHByb3RvY29sIHN0YWNrIHNlZ21lbnQg4oCcVENQ L0RUTFMvU0NUUOKAnSAo4oCcdGhlIGluZGlyZWN0IGFwcHJvYWNoIHdvdWxkIGJlIHdoYXQ/IOKA nFRDUC9UTFMvU0NUUOKAnT/igJ0gd2hpY2ggbGVhZHMgdG8gYW1iaWd1aXRpZXMg4oCmIGR1ZSB0 byBuYXRpdmUg4oCcVENQL1RMUy/igKbigJ0gbGF5ZXJpbmcgYW5kIFJUQ1dFQiByZXF1aXJlZCDi gJxUQ1AvRFRMUy/igKYg4oCcIGxheWVyaW5nKS4NCg0KUmVnYXJkcywNCkFsYnJlY2h0DQoNCg0K DQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBEb25uZXJzdGFnLCAyMi4gSmFudWFyIDIwMTUg MDc6NDkNClRvOiBKdXN0aW4gVWJlcnRpOyBTdWhhcyBOYW5kYWt1bWFyDQpDYzogPHJ0Y3dlYkBp ZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBJ dCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxpbmVzLCByaWdodD8N Cg0KSGksDQoNCk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG91dGNvbWUgb2YgdGhlIGRpc2N1c3Np b25zIHdhcyB0aGF0IHdlIHdlcmUgZ29pbmcgdG8gdXNlIOKAnERUTFPigJ0uDQoNCkJ1dCwgcGVy c29uYWxseSBJIGNvdWxkIGxpdmUgd2l0aCBib3RoLCBzbyBpZiBteSB1bmRlcnN0YW5kaW5nIGlz IHdyb25nIEnigJltIGhhcHB5IHRvIGNoYW5nZSB0aGUgZHJhZnQgOikNCg0KTm90ZSwgaG93ZXZl ciwgdGhhdCBJRiB3ZSBjaGFuZ2UgdG8g4oCcVExT4oCdLCB0aGVuIEkgZ3Vlc3Mgd2UgYWxzbyBu ZWVkIHRvIGRpc2N1c3MgdGhlIOKAnFNDVFAvRFRMU+KAnSB2YWx1ZSwgYW5kIHdoZXRoZXIgaXQg c2hvdWxkIGJlIOKAnFNDVFAvVExT4oCdIGluc3RlYWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDIyIEphbnVhcnkgMjAxNSAwNzozNw0KVG86 IFN1aGFzIE5hbmRha3VtYXINCkNjOiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEl0J3MgIlVEUC9EVExTL1NDVFAiIGZvciB0 aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0KDQpUaGUgb3BlbiBxdWVzdGlvbiB3YXMg d2hldGhlciB0aGlzIHNob3VsZCBiZSBVRFAvRFRMUy9TQ1RQLCBvciBVRFAvVExTL1NDVFAgKERU TFMgaW1wbGljaXQpIHRvIG1hdGNoIHRoZSBleGlzdGluZyBVRFAvVExTL1JUUC9TQVZQRiB2YWx1 ZXMgZGVmaW5lZCBpbiA1NzYzLg0KDQpVcHNpZGUgb2YgVExTOiBjb25zaXN0ZW50IHdpdGggcHJl Y2VkZW50DQpVcHNpZGUgb2YgRFRMUzogbGVzcyBjb25mdXNpbmcNCg0KT24gV2VkLCBKYW4gMjEs IDIwMTUgYXQgNTozMSBQTSwgU3VoYXMgTmFuZGFrdW1hciA8c3VoYXNpZXRmQGdtYWlsLmNvbTxt YWlsdG86c3VoYXNpZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhleSBsb29rIHJpZ2h0IHRvIG1l IC4ud291bGQgbGV0IENocmlzdGVyIGNvbmZpcm0gdGhvdWdoDQoNCkNoZWVycw0KU3VoYXMNCg0K DQpPbiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIwMTUsIFBldGVyIFRoYXRjaGVyIDxwdGhhdGNo ZXJAZ29vZ2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+PiB3cm90ZToNCuKAi1fi gIsNCmUncmUNCuKAi3dvcmtpbmcgb24gaW1wbGVtZW50aW5nIGRyYWZ0LWlldGYtbW11c2ljLXNj dHAtc2RwLTEyIGFuZCBnb2luZyB0aHJvdWdoIHRoZSBwcm9jZXNzIG9mIG1ha2luZyB0aGUgY2hh bmdlIHdoaWxlIG5vdCBicmVha2luZyB0aGluZ3MgYW5kIHdlJ2QgbGlrZSB0byBub3QgaGF2ZSB0 byBkbyB0aGlzIGEgc2Vjb25kIHRpbWUuIEJlZm9yZSBtYWtpbmcgdGhpcyBjaGFuZ2UsIEknZCBs aWtlIHRvIGJlIGRvdWJseSBjbGVhciB0aGF0IEkgZ290IHRoZSByaWdodCB2YWx1ZSBmb3IgZGF0 YSBjaGFubmVsIG0tbGluZXM6DQrigIvigIsNCg0KIlVEUC9EVExTL1NDVFAiDQrigIsgKG9yICJU Q1AvRFRMUy9TQ1RQIikNCg0KDQoNCuKAi0lzIHRoYXQgZm9yIHN1cmUgdGhlIHJpZ2h0IHZhbHVl P+KAiw0K4oCLDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B1D675C09ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2Vu emI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvLCB5b3Ugc3VwcG9ydCB1 c2luZyDigJxEVExT4oCdPyA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVj aHQpIFttYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gMjIgSmFudWFyeSAyMDE1IDEwOjI0PGJyPg0KPGI+VG86PC9iPiBDaHJpc3Rl ciBIb2xtYmVyZzsgSnVzdGluIFViZXJ0aTsgU3VoYXMgTmFuZGFrdW1hcjxicj4NCjxiPkNjOjwv Yj4gJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtydGN3 ZWJdIEl0J3MgJnF1b3Q7VURQL0RUTFMvU0NUUCZxdW90OyBmb3IgdGhlIGRhdGEgY2hhbm5lbCBt LWxpbmVzLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztj b2xvcjojMUY0OTdEIj5EZXNwaXRlIHRoZSBmYWN0IG9mIGNsb2FzZSBhbGlnbm1lbnQgYmV0d2Vl biBwcm90b2NvbHMgRFRMUyBhbmQgVExTLCBib3RoIGFyZSBzdGlsbCBkaWZmZXJlbnQgcHJvdG9j b2xzIChlLmcuIGNhcGFiaWxpdGllcyBjb25jZXJuaW5nIGFzc3VyZWQgb3Igbm9uLWFzc3VyZWQg TDQgdHJhbnNwb3J0LA0KIHByb3RvY29sIHZlcnNpb25pbmcsIOKApikuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+VGh1cywgbXkgcHJlZmVy ZW5jZSB3b3VsZCBiZSB0byB1c2UgdG8gY29ycmVjdCBuYW1lLCBpLmUuLCDigJxEVExT4oCdIGFu ZCBub3QgYW55IGluZGlyZWN0IGluZGljYXRpb24gc3VjaCBhcyBUTFMgYmFzZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+QWxzbyBiZWNhdXNl IG9mIHRoZSBwcm90b2NvbCBzdGFjayBzZWdtZW50IOKAnFRDUC9EVExTL1NDVFDigJ0gKOKAnHRo ZSBpbmRpcmVjdCBhcHByb2FjaCB3b3VsZCBiZSB3aGF0PyDigJxUQ1AvVExTL1NDVFDigJ0/4oCd IHdoaWNoIGxlYWRzIHRvIGFtYmlndWl0aWVzIOKApiBkdWUgdG8gbmF0aXZlIOKAnFRDUC9UTFMv 4oCm4oCdDQogbGF5ZXJpbmcgYW5kIFJUQ1dFQiByZXF1aXJlZCDigJxUQ1AvRFRMUy/igKYg4oCc IGxheWVyaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xv cjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMxRjQ5N0QiPkFsYnJlY2h0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgWzxhIGhyZWY9 Im1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8 Yj5TZW50OjwvYj4gRG9ubmVyc3RhZywgMjIuIEphbnVhciAyMDE1IDA3OjQ5PGJyPg0KPGI+VG86 PC9iPiBKdXN0aW4gVWJlcnRpOyBTdWhhcyBOYW5kYWt1bWFyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIEl0J3MgJnF1b3Q7VURQL0RUTFMvU0NU UCZxdW90OyBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxpbmVzLCByaWdodD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5N eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBvdXRjb21lIG9mIHRoZSBkaXNjdXNzaW9ucyB3YXMgdGhh dCB3ZSB3ZXJlIGdvaW5nIHRvIHVzZSDigJxEVExT4oCdLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQsIHBlcnNvbmFsbHkgSSBjb3VsZCBsaXZlIHdpdGgg Ym90aCwgc28gaWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZyBJ4oCZbSBoYXBweSB0byBjaGFu Z2UgdGhlIGRyYWZ0IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Ob3RlLCBob3dldmVyLCB0aGF0IElGIHdlIGNoYW5nZSB0byDigJxUTFPigJ0sIHRoZW4gSSBn dWVzcyB3ZSBhbHNvIG5lZWQgdG8gZGlzY3VzcyB0aGUg4oCcU0NUUC9EVExT4oCdIHZhbHVlLCBh bmQgd2hldGhlciBpdCBzaG91bGQgYmUg4oCcU0NUUC9UTFPigJ0gaW5zdGVhZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i Pkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50OjwvYj4gMjIgSmFudWFyeSAyMDE1IDA3OjM3PGJy Pg0KPGI+VG86PC9iPiBTdWhhcyBOYW5kYWt1bWFyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIEl0J3MgJnF1b3Q7VURQL0RUTFMvU0NUUCZxdW90 OyBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxpbmVzLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb3BlbiBxdWVzdGlvbiB3YXMgd2hldGhlciB0aGlzIHNo b3VsZCBiZSBVRFAvRFRMUy9TQ1RQLCBvciBVRFAvVExTL1NDVFAgKERUTFMgaW1wbGljaXQpIHRv IG1hdGNoIHRoZSBleGlzdGluZyBVRFAvVExTL1JUUC9TQVZQRiB2YWx1ZXMgZGVmaW5lZCBpbiA1 NzYzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXBzaWRl IG9mIFRMUzogY29uc2lzdGVudCB3aXRoIHByZWNlZGVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXBzaWRlIG9mIERUTFM6IGxlc3MgY29uZnVz aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFdlZCwgSmFuIDIxLCAyMDE1IGF0IDU6MzEgUE0sIFN1aGFzIE5hbmRha3VtYXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3VoYXNp ZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGV5IGxvb2sgcmlnaHQgdG8mbmJzcDttZSAuLndvdWxkIGxldCBDaHJpc3RlciBjb25maXJt IHRob3VnaDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hl ZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iaG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+U3VoYXM8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQpPbiBXZWRuZXNkYXksIEphbnVhcnkgMjEsIDIwMTUsIFBldGVyIFRo YXRjaGVyICZsdDs8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igItX4oCLPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lJ3JlIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igIt3b3JraW5nIG9uIGltcGxlbWVudGluZyBkcmFmdC1p ZXRmLW1tdXNpYy1zY3RwLXNkcC0xMiBhbmQgZ29pbmcgdGhyb3VnaCB0aGUgcHJvY2VzcyBvZiBt YWtpbmcgdGhlIGNoYW5nZSB3aGlsZSBub3QgYnJlYWtpbmcgdGhpbmdzIGFuZCB3ZSdkIGxpa2Ug dG8gbm90IGhhdmUgdG8gZG8gdGhpcyBhIHNlY29uZCB0aW1lLiBCZWZvcmUNCiBtYWtpbmcgdGhp cyBjaGFuZ2UsIEknZCBsaWtlIHRvIGJlIGRvdWJseSBjbGVhciB0aGF0IEkgZ290IHRoZSByaWdo dCB2YWx1ZSBmb3IgZGF0YSBjaGFubmVsIG0tbGluZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj7igIvigIs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZxdW90O1VE UC9EVExTL1NDVFAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+4oCLIChvciAmcXVvdDtUQ1AvRFRMUy9TQ1RQJnF1b3Q7KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKAi0lzIHRoYXQgZm9yIHN1cmUgdGhlIHJpZ2h0IHZhbHVl P+KAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPuKA izwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D675C09ESESSMB209erics_-- From nobody Thu Jan 22 04:01: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 9BB931ACC87 for ; Thu, 22 Jan 2015 04:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq9p8k4BDDjl for ; Thu, 22 Jan 2015 04:01:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2431AC7E7 for ; Thu, 22 Jan 2015 04:01:20 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 0AA38B673E852; Thu, 22 Jan 2015 12:01:15 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t0MC19v5004765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 07:01:09 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 07:01:06 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , "Schwarz, Albrecht (Albrecht)" , Justin Uberti , Suhas Nandakumar Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQNeMkgqE/d/YawUCdmxFPUp6Po5zL8tsAgAAUIYCAABqFAIAALhoA//+3wLA= Date: Thu, 22 Jan 2015 12:01:06 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E6A482EUS70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 12:01:25 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E6A482EUS70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSBwcm90b2NvbCBzdGFja3MgbGF5ZXJpbmcgcG9pbnQgb2YgdmlldywgaXNu4oCZdCB0aGUg Zm9sbG93aW5nIG1vcmUgYWNjdXJhdGVseSByZXByZXNlbnQgdGhlbT8NCkZvciBUQ1AgSUNFIGJh c2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFRDUC9SRkM0NTcxL0RUTFMvU0NUUA0KRm9yIFVE UCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMvU0NUUA0KDQpQZXIg bXkgdW5kZXJzdGFuZGluZywgaW5kZXBlbmRlbnQgb2YgdW5kZXJseWluZyB0cmFuc3BvcnQgKFVE UDsgb3Ig4oCcVENQIG92ZXIgUkZDNDQ3MeKAnSBmcmFtaW5nIG1pbWlja2luZyBkYXRhZ3JhbSB0 cmFuc3BvcnQpIHRoZSBEVExTIHByb3RvY29sIGlzIHNhbWUuDQoNCkJSDQpSYWp1DQoNCg0KDQpG cm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSA1OjA5 IEFNDQpUbzogU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgSnVzdGluIFViZXJ0aTsgU3Vo YXMgTmFuZGFrdW1hcg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gSXQncyAiVURQL0RUTFMvU0NUUCIgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmln aHQ/DQoNClNvLCB5b3Ugc3VwcG9ydCB1c2luZyDigJxEVExT4oCdPyA6KQ0KDQpGcm9tOiBTY2h3 YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpIFttYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVs LWx1Y2VudC5jb21dDQpTZW50OiAyMiBKYW51YXJ5IDIwMTUgMTA6MjQNClRvOiBDaHJpc3RlciBI b2xtYmVyZzsgSnVzdGluIFViZXJ0aTsgU3VoYXMgTmFuZGFrdW1hcg0KQ2M6IDxydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gSXQn cyAiVURQL0RUTFMvU0NUUCIgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/DQoN CkRlc3BpdGUgdGhlIGZhY3Qgb2YgY2xvYXNlIGFsaWdubWVudCBiZXR3ZWVuIHByb3RvY29scyBE VExTIGFuZCBUTFMsIGJvdGggYXJlIHN0aWxsIGRpZmZlcmVudCBwcm90b2NvbHMgKGUuZy4gY2Fw YWJpbGl0aWVzIGNvbmNlcm5pbmcgYXNzdXJlZCBvciBub24tYXNzdXJlZCBMNCB0cmFuc3BvcnQs IHByb3RvY29sIHZlcnNpb25pbmcsIOKApikuDQoNClRodXMsIG15IHByZWZlcmVuY2Ugd291bGQg YmUgdG8gdXNlIHRvIGNvcnJlY3QgbmFtZSwgaS5lLiwg4oCcRFRMU+KAnSBhbmQgbm90IGFueSBp bmRpcmVjdCBpbmRpY2F0aW9uIHN1Y2ggYXMgVExTIGJhc2VkLg0KQWxzbyBiZWNhdXNlIG9mIHRo ZSBwcm90b2NvbCBzdGFjayBzZWdtZW50IOKAnFRDUC9EVExTL1NDVFDigJ0gKOKAnHRoZSBpbmRp cmVjdCBhcHByb2FjaCB3b3VsZCBiZSB3aGF0PyDigJxUQ1AvVExTL1NDVFDigJ0/4oCdIHdoaWNo IGxlYWRzIHRvIGFtYmlndWl0aWVzIOKApiBkdWUgdG8gbmF0aXZlIOKAnFRDUC9UTFMv4oCm4oCd IGxheWVyaW5nIGFuZCBSVENXRUIgcmVxdWlyZWQg4oCcVENQL0RUTFMv4oCmIOKAnCBsYXllcmlu ZykuDQoNClJlZ2FyZHMsDQpBbGJyZWNodA0KDQoNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2Vu dDogRG9ubmVyc3RhZywgMjIuIEphbnVhciAyMDE1IDA3OjQ5DQpUbzogSnVzdGluIFViZXJ0aTsg U3VoYXMgTmFuZGFrdW1hcg0KQ2M6IDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gSXQncyAiVURQL0RUTFMvU0NUUCIgZm9yIHRo ZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/DQoNCkhpLA0KDQpNeSB1bmRlcnN0YW5kaW5n IG9mIHRoZSBvdXRjb21lIG9mIHRoZSBkaXNjdXNzaW9ucyB3YXMgdGhhdCB3ZSB3ZXJlIGdvaW5n IHRvIHVzZSDigJxEVExT4oCdLg0KDQpCdXQsIHBlcnNvbmFsbHkgSSBjb3VsZCBsaXZlIHdpdGgg Ym90aCwgc28gaWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZyBJ4oCZbSBoYXBweSB0byBjaGFu Z2UgdGhlIGRyYWZ0IDopDQoNCk5vdGUsIGhvd2V2ZXIsIHRoYXQgSUYgd2UgY2hhbmdlIHRvIOKA nFRMU+KAnSwgdGhlbiBJIGd1ZXNzIHdlIGFsc28gbmVlZCB0byBkaXNjdXNzIHRoZSDigJxTQ1RQ L0RUTFPigJ0gdmFsdWUsIGFuZCB3aGV0aGVyIGl0IHNob3VsZCBiZSDigJxTQ1RQL1RMU+KAnSBp bnN0ZWFkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KRnJvbTogcnRjd2ViIFttYWls dG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpT ZW50OiAyMiBKYW51YXJ5IDIwMTUgMDc6MzcNClRvOiBTdWhhcyBOYW5kYWt1bWFyDQpDYzogPHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBJdCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxpbmVzLCBy aWdodD8NCg0KVGhlIG9wZW4gcXVlc3Rpb24gd2FzIHdoZXRoZXIgdGhpcyBzaG91bGQgYmUgVURQ L0RUTFMvU0NUUCwgb3IgVURQL1RMUy9TQ1RQIChEVExTIGltcGxpY2l0KSB0byBtYXRjaCB0aGUg ZXhpc3RpbmcgVURQL1RMUy9SVFAvU0FWUEYgdmFsdWVzIGRlZmluZWQgaW4gNTc2My4NCg0KVXBz aWRlIG9mIFRMUzogY29uc2lzdGVudCB3aXRoIHByZWNlZGVudA0KVXBzaWRlIG9mIERUTFM6IGxl c3MgY29uZnVzaW5nDQoNCk9uIFdlZCwgSmFuIDIxLCAyMDE1IGF0IDU6MzEgUE0sIFN1aGFzIE5h bmRha3VtYXIgPHN1aGFzaWV0ZkBnbWFpbC5jb208bWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb20+ PiB3cm90ZToNClRoZXkgbG9vayByaWdodCB0byBtZSAuLndvdWxkIGxldCBDaHJpc3RlciBjb25m aXJtIHRob3VnaA0KDQpDaGVlcnMNClN1aGFzDQoNCg0KT24gV2VkbmVzZGF5LCBKYW51YXJ5IDIx LCAyMDE1LCBQZXRlciBUaGF0Y2hlciA8cHRoYXRjaGVyQGdvb2dsZS5jb208bWFpbHRvOnB0aGF0 Y2hlckBnb29nbGUuY29tPj4gd3JvdGU6DQrigItX4oCLDQplJ3JlDQrigIt3b3JraW5nIG9uIGlt cGxlbWVudGluZyBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcC0xMiBhbmQgZ29pbmcgdGhyb3Vn aCB0aGUgcHJvY2VzcyBvZiBtYWtpbmcgdGhlIGNoYW5nZSB3aGlsZSBub3QgYnJlYWtpbmcgdGhp bmdzIGFuZCB3ZSdkIGxpa2UgdG8gbm90IGhhdmUgdG8gZG8gdGhpcyBhIHNlY29uZCB0aW1lLiBC ZWZvcmUgbWFraW5nIHRoaXMgY2hhbmdlLCBJJ2QgbGlrZSB0byBiZSBkb3VibHkgY2xlYXIgdGhh dCBJIGdvdCB0aGUgcmlnaHQgdmFsdWUgZm9yIGRhdGEgY2hhbm5lbCBtLWxpbmVzOg0K4oCL4oCL DQoNCiJVRFAvRFRMUy9TQ1RQIg0K4oCLIChvciAiVENQL0RUTFMvU0NUUCIpDQoNCg0KDQrigItJ cyB0aGF0IGZvciBzdXJlIHRoZSByaWdodCB2YWx1ZT/igIsNCuKAiw0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcg bGlzdA0KcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E6A482EUS70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpi O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5Gcm9tIHByb3RvY29sIHN0YWNrcyBsYXllcmluZyBwb2ludCBvZiB2aWV3LCBp c27igJl0IHRoZSBmb2xsb3dpbmcgbW9yZSBhY2N1cmF0ZWx5IHJlcHJlc2VudCB0aGVtPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gb3IgVENQIElDRSBiYXNlZCBkYXRhIGNoYW5uZWwg dHJhbnNwb3J0OiBUQ1AvUkZDNDU3MS9EVExTL1NDVFA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Rm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMv U0NUUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UGVyIG15IHVuZGVyc3RhbmRpbmcsIGluZGVwZW5kZW50IG9mIHVuZGVy bHlpbmcgdHJhbnNwb3J0IChVRFA7IG9yIOKAnFRDUCBvdmVyIFJGQzQ0NzHigJ0gZnJhbWluZyBt aW1pY2tpbmcgZGF0YWdyYW0gdHJhbnNwb3J0KSB0aGUgRFRMUyBwcm90b2NvbCBpcyBzYW1lLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqdTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dl YiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5D aHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAyMiwg MjAxNSA1OjA5IEFNPGJyPg0KPGI+VG86PC9iPiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQp OyBKdXN0aW4gVWJlcnRpOyBTdWhhcyBOYW5kYWt1bWFyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7cnRj d2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSXQncyAm cXVvdDtVRFAvRFRMUy9TQ1RQJnF1b3Q7IGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJp Z2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIHlv dSBzdXBwb3J0IHVzaW5nIOKAnERUTFPigJ0/IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48L2E+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2Nod2FyeiwgQWxicmVjaHQg KEFsYnJlY2h0KSBbPGEgaHJlZj0ibWFpbHRvOmFsYnJlY2h0LnNjaHdhcnpAYWxjYXRlbC1sdWNl bnQuY29tIj5tYWlsdG86YWxicmVjaHQuc2Nod2FyekBhbGNhdGVsLWx1Y2VudC5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IDIyIEphbnVhcnkgMjAxNSAxMDoyNDxicj4NCjxiPlRvOjwvYj4g Q2hyaXN0ZXIgSG9sbWJlcmc7IEp1c3RpbiBVYmVydGk7IFN1aGFzIE5hbmRha3VtYXI8YnI+DQo8 Yj5DYzo8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dlYl0gSXQncyAmcXVv dDtVRFAvRFRMUy9TQ1RQJnF1b3Q7IGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0 PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPkRlc3BpdGUgdGhlIGZhY3Qg b2YgY2xvYXNlIGFsaWdubWVudCBiZXR3ZWVuIHByb3RvY29scyBEVExTIGFuZCBUTFMsIGJvdGgg YXJlIHN0aWxsIGRpZmZlcmVudCBwcm90b2NvbHMgKGUuZy4gY2FwYWJpbGl0aWVzIGNvbmNlcm5p bmcgYXNzdXJlZCBvciBub24tYXNzdXJlZA0KIEw0IHRyYW5zcG9ydCwgcHJvdG9jb2wgdmVyc2lv bmluZywg4oCmKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPlRodXMsIG15IHByZWZlcmVuY2Ug d291bGQgYmUgdG8gdXNlIHRvIGNvcnJlY3QgbmFtZSwgaS5lLiwg4oCcRFRMU+KAnSBhbmQgbm90 IGFueSBpbmRpcmVjdCBpbmRpY2F0aW9uIHN1Y2ggYXMgVExTIGJhc2VkLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj5BbHNv IGJlY2F1c2Ugb2YgdGhlIHByb3RvY29sIHN0YWNrIHNlZ21lbnQg4oCcVENQL0RUTFMvU0NUUOKA nSAo4oCcdGhlIGluZGlyZWN0IGFwcHJvYWNoIHdvdWxkIGJlIHdoYXQ/IOKAnFRDUC9UTFMvU0NU UOKAnT/igJ0gd2hpY2ggbGVhZHMgdG8gYW1iaWd1aXRpZXMg4oCmIGR1ZSB0byBuYXRpdmUNCiDi gJxUQ1AvVExTL+KApuKAnSBsYXllcmluZyBhbmQgUlRDV0VCIHJlcXVpcmVkIOKAnFRDUC9EVExT L+KApiDigJwgbGF5ZXJpbmcpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzFG NDk3RCI+QWxicmVjaHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgWzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gRG9ubmVy c3RhZywgMjIuIEphbnVhciAyMDE1IDA3OjQ5PGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gVWJlcnRp OyBTdWhhcyBOYW5kYWt1bWFyPGJyPg0KPGI+Q2M6PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtydGN3ZWJdIEl0J3MgJnF1b3Q7VURQL0RUTFMvU0NUUCZxdW90OyBmb3IgdGhlIGRh dGEgY2hhbm5lbCBtLWxpbmVzLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG91dGNvbWUg b2YgdGhlIGRpc2N1c3Npb25zIHdhcyB0aGF0IHdlIHdlcmUgZ29pbmcgdG8gdXNlIOKAnERUTFPi gJ0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0LCBwZXJzb25hbGx5 IEkgY291bGQgbGl2ZSB3aXRoIGJvdGgsIHNvIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3Jvbmcg SeKAmW0gaGFwcHkgdG8gY2hhbmdlIHRoZSBkcmFmdCA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Ob3RlLCBob3dldmVyLCB0aGF0IElGIHdlIGNoYW5nZSB0byDigJxUTFPi gJ0sIHRoZW4gSSBndWVzcyB3ZSBhbHNvIG5lZWQgdG8gZGlzY3VzcyB0aGUg4oCcU0NUUC9EVExT 4oCdIHZhbHVlLCBhbmQgd2hldGhlciBpdCBzaG91bGQgYmUg4oCcU0NUUC9UTFPigJ0gaW5zdGVh ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgWzxhIGhyZWY9Im1haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9u IEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiAyMiBKYW51YXJ5 IDIwMTUgMDc6Mzc8YnI+DQo8Yj5Ubzo8L2I+IFN1aGFzIE5hbmRha3VtYXI8YnI+DQo8Yj5DYzo8 L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSXQncyAmcXVvdDtVRFAv RFRMUy9TQ1RQJnF1b3Q7IGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0PzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZSBvcGVuIHF1ZXN0aW9uIHdhcyB3aGV0aGVyIHRoaXMg c2hvdWxkIGJlIFVEUC9EVExTL1NDVFAsIG9yIFVEUC9UTFMvU0NUUCAoRFRMUyBpbXBsaWNpdCkg dG8gbWF0Y2ggdGhlIGV4aXN0aW5nIFVEUC9UTFMvUlRQL1NBVlBGIHZhbHVlcyBkZWZpbmVkIGlu IDU3NjMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+VXBzaWRlIG9m IFRMUzogY29uc2lzdGVudCB3aXRoIHByZWNlZGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5VcHNp ZGUgb2YgRFRMUzogbGVzcyBjb25mdXNpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPk9uIFdlZCwgSmFuIDIxLCAyMDE1IGF0IDU6MzEgUE0sIFN1aGFz IE5hbmRha3VtYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzdWhhc2lldGZAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+c3VoYXNpZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZXkgbG9vayBy aWdodCB0byZuYnNwO21lIC4ud291bGQgbGV0IENocmlzdGVyIGNvbmZpcm0gdGhvdWdoPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2hlZXJzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImhvZW56YiI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5TdWhhczwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxicj4N Cjxicj4NCk9uIFdlZG5lc2RheSwgSmFudWFyeSAyMSwgMjAxNSwgUGV0ZXIgVGhhdGNoZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnB0 aGF0Y2hlckBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLV+KA izxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiPmUncmUgPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLd29ya2luZyBvbiBpbXBs ZW1lbnRpbmcgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAtMTIgYW5kIGdvaW5nIHRocm91Z2gg dGhlIHByb2Nlc3Mgb2YgbWFraW5nIHRoZSBjaGFuZ2Ugd2hpbGUgbm90IGJyZWFraW5nIHRoaW5n cyBhbmQgd2UnZCBsaWtlIHRvIG5vdCBoYXZlIHRvIGRvIHRoaXMgYSBzZWNvbmQNCiB0aW1lLiBC ZWZvcmUgbWFraW5nIHRoaXMgY2hhbmdlLCBJJ2QgbGlrZSB0byBiZSBkb3VibHkgY2xlYXIgdGhh dCBJIGdvdCB0aGUgcmlnaHQgdmFsdWUgZm9yIGRhdGEgY2hhbm5lbCBtLWxpbmVzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAi+KAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxicj4NCiZxdW90 O1VEUC9EVExTL1NDVFAmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igIsgKG9yICZxdW90O1RDUC9E VExTL1NDVFAmcXVvdDspPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCLSXMgdGhhdCBm b3Igc3VyZSB0aGUgcmlnaHQgdmFsdWU/4oCLPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAizwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E6A482EUS70UWXCHMBA02z_-- From nobody Thu Jan 22 14:45:45 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A41A006D for ; Thu, 22 Jan 2015 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdcYcowrY2U9 for ; Thu, 22 Jan 2015 14:45:42 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 801BB1A0041 for ; Thu, 22 Jan 2015 14:45:41 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id hn18so3576850igb.2 for ; Thu, 22 Jan 2015 14:45:40 -0800 (PST) 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=F+ibaVV7d5bqfA7WU14RNevyBTw9lcOmS9u4yRKqVNA=; b=R3vUuJ7+TmNUV/XZz5zBqOYt3BfOeUqXMZYAdTgXDdryvVXKiY+12S6VX3n4gcg0dp iyyOuR42j+SpSzziVeV5vU9y0uO3hxU0wTuUDivYqbl6Orsp6tt64DtLsMtv388RIC/u Hm4vYKLrPBVIUqL+ujDGTWUTEL4C6Fxsah2wi/pUvnzvA3tPRh+JkEMaqT21JOleurtz Oo3eLniyUjASAI79g3SbXpGIH4V06SPzUgK0Xqx9TZo0jzAkcbJrabi5Li1W2er+0n4K 4dR941DueIW1BGinqvAIsTSDLx3wJfr18KwUS4Nm1v08rm4Cz1PAZPSj5oxQA913asju O8cA== 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=F+ibaVV7d5bqfA7WU14RNevyBTw9lcOmS9u4yRKqVNA=; b=YK6pbqJM1qIHk1GdAVVaUkm8YdQSxSlGUUH06mmyoQe3pDc3SfMLVHVwtP3bNO2g/1 7sOgglb+6jlQU9BtskEI8Afek6af7IJJ5VQwlITaeWeVyOxgGnCDoCISmpsHPJnwVRMy TyOhT/d+/LW3Qu6lpZ8jtNGvLw8/6UM6aJr6jwfTFnj8serqtKJz4WAdc+21tk03x1iy ehLBr7q16bcvEiTTAoedTI7f/fgsmzy2HfGPSdO7JTVqAHYZMhy6z2KzXGH5kB1pmvP6 fJDOsQoufbu0+cEBKtDALgCOt/0R1WjZmC9RLKqMyWAVUx9MeT+d2xCZPctTarG3fxfj SMPw== X-Gm-Message-State: ALoCoQkxKYwWzsQ3LTFfu0K3MeGAWZfvlgSt2Jaxq8ID53aZwfD1bCOrmB5LA38hT/Ssfi2vLvJa X-Received: by 10.50.67.100 with SMTP id m4mr16264805igt.22.1421966740314; Thu, 22 Jan 2015 14:45:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Thu, 22 Jan 2015 14:45:20 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 22 Jan 2015 14:45:20 -0800 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=047d7bd75b347079c8050d456e7a Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 22:45:44 -0000 --047d7bd75b347079c8050d456e7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The protocol is the same. We are just deciding what the identifying string should be. Given the amount of confusion in this space, I think it makes sense to be as explicit as possible, and use DTLS instead of TLS for the name. On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > From protocol stacks layering point of view, isn=E2=80=99t the following= more > accurately represent them? > > For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP > > For UDP ICE based data channel transport: UDP/DTLS/SCTP > > > > Per my understanding, independent of underlying transport (UDP; or =E2=80= =9CTCP > over RFC4471=E2=80=9D framing mimicking datagram transport) the DTLS prot= ocol is > same. > > > > BR > > Raju > > > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* Thursday, January 22, 2015 5:09 AM > *To:* Schwarz, Albrecht (Albrecht); Justin Uberti; Suhas Nandakumar > > *Cc:* > *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > So, you support using =E2=80=9CDTLS=E2=80=9D? :) > > > > *From:* Schwarz, Albrecht (Albrecht) [ > mailto:albrecht.schwarz@alcatel-lucent.com > ] > *Sent:* 22 January 2015 10:24 > *To:* Christer Holmberg; Justin Uberti; Suhas Nandakumar > *Cc:* > *Subject:* RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > Despite the fact of cloase alignment between protocols DTLS and TLS, both > are still different protocols (e.g. capabilities concerning assured or > non-assured L4 transport, protocol versioning, =E2=80=A6). > > > > Thus, my preference would be to use to correct name, i.e., =E2=80=9CDTLS= =E2=80=9D and not > any indirect indication such as TLS based. > > Also because of the protocol stack segment =E2=80=9CTCP/DTLS/SCTP=E2=80= =9D (=E2=80=9Cthe indirect > approach would be what? =E2=80=9CTCP/TLS/SCTP=E2=80=9D?=E2=80=9D which le= ads to ambiguities =E2=80=A6 due > to native =E2=80=9CTCP/TLS/=E2=80=A6=E2=80=9D layering and RTCWEB require= d =E2=80=9CTCP/DTLS/=E2=80=A6 =E2=80=9C layering). > > > > Regards, > > Albrecht > > > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Christer Holmberg > *Sent:* Donnerstag, 22. Januar 2015 07:49 > *To:* Justin Uberti; Suhas Nandakumar > *Cc:* > *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > Hi, > > > > My understanding of the outcome of the discussions was that we were going > to use =E2=80=9CDTLS=E2=80=9D. > > > > But, personally I could live with both, so if my understanding is wrong > I=E2=80=99m happy to change the draft :) > > > > Note, however, that IF we change to =E2=80=9CTLS=E2=80=9D, then I guess w= e also need to > discuss the =E2=80=9CSCTP/DTLS=E2=80=9D value, and whether it should be = =E2=80=9CSCTP/TLS=E2=80=9D instead. > > > > Regards, > > > > Christer > > > > > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org ]= *On > Behalf Of *Justin Uberti > *Sent:* 22 January 2015 07:37 > *To:* Suhas Nandakumar > *Cc:* > *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > The open question was whether this should be UDP/DTLS/SCTP, or > UDP/TLS/SCTP (DTLS implicit) to match the existing UDP/TLS/RTP/SAVPF valu= es > defined in 5763. > > > > Upside of TLS: consistent with precedent > > Upside of DTLS: less confusing > > > > On Wed, Jan 21, 2015 at 5:31 PM, Suhas Nandakumar > wrote: > > They look right to me ..would let Christer confirm though > > > > Cheers > > Suhas > > > > On Wednesday, January 21, 2015, Peter Thatcher > wrote: > > =E2=80=8BW=E2=80=8B > > e're > > =E2=80=8Bworking on implementing draft-ietf-mmusic-sctp-sdp-12 and going = through > the process of making the change while not breaking things and we'd like = to > not have to do this a second time. Before making this change, I'd like to > be doubly clear that I got the right value for data channel m-lines: > > =E2=80=8B=E2=80=8B > > > "UDP/DTLS/SCTP" > > =E2=80=8B (or "TCP/DTLS/SCTP") > > > > > > > > =E2=80=8BIs that for sure the right value?=E2=80=8B > > =E2=80=8B > > > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --047d7bd75b347079c8050d456e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The protocol is the same. We are just deciding what the id= entifying string should be.

Given the amount of confusio= n in this space, I think it makes sense to be as explicit as possible, and = use DTLS instead of TLS for the name.

On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, = Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>= ; wrote:

From protocol stacks laye= ring point of view, isn=E2=80=99t the following more accurately represent t= hem?

For TCP ICE based data ch= annel transport: TCP/RFC4571/DTLS/SCTP

For UDP ICE based data ch= annel transport: UDP/DTLS/SCTP

=C2=A0

Per my understanding, ind= ependent of underlying transport (UDP; or =E2=80=9CTCP over RFC4471=E2=80= =9D framing mimicking datagram transport) the DTLS protocol is same.=

=C2=A0

BR

Raju=

=C2=A0

=C2=A0

=C2=A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, January 22, 2015 5:09 AM
To: Schwarz, Albrecht (Albrecht); Justin Uberti; Suhas Nandakumar


Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

So, you su= pport using =E2=80=9CDTLS=E2=80=9D? :)

=C2=A0

From: Schwar= z, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Sent: 22 January 2015 10:24
To: Christer Holmberg; Justin Uberti; Suhas Nandakumar
Cc: <rtcweb@= ietf.org>
Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

Despite the fact of cloase alignment between= protocols DTLS and TLS, both are still different protocols (e.g. capabilit= ies concerning assured or non-assured L4 transport, protocol versioning, =E2=80=A6).

=C2=A0

Thus, my preference would be to use to corre= ct name, i.e., =E2=80=9CDTLS=E2=80=9D and not any indirect indication such = as TLS based.

Also because of the protocol stack segment = =E2=80=9CTCP/DTLS/SCTP=E2=80=9D (=E2=80=9Cthe indirect approach would be wh= at? =E2=80=9CTCP/TLS/SCTP=E2=80=9D?=E2=80=9D which leads to ambiguities =E2= =80=A6 due to native =E2=80=9CTCP/TLS/=E2=80=A6=E2=80=9D layering and RTCWEB required =E2=80=9C= TCP/DTLS/=E2=80=A6 =E2=80=9C layering).

=C2=A0

Regards,

Albrecht

=C2=A0

=C2=A0

=C2= =A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Donnerstag, 22. Januar 2015 07:49
To: Justin Uberti; Suhas Nandakumar
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

Hi,=

=C2= =A0

My underst= anding of the outcome of the discussions was that we were going to use =E2= =80=9CDTLS=E2=80=9D.

=C2= =A0

But, perso= nally I could live with both, so if my understanding is wrong I=E2=80=99m h= appy to change the draft :)

=C2= =A0

Note, howe= ver, that IF we change to =E2=80=9CTLS=E2=80=9D, then I guess we also need = to discuss the =E2=80=9CSCTP/DTLS=E2=80=9D value, and whether it should be = =E2=80=9CSCTP/TLS=E2=80=9D instead.

=C2= =A0

Regards,

=C2= =A0

Christer

=C2= =A0

=C2= =A0

=C2= =A0

From: rtcweb= [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 22 January 2015 07:37
To: Suhas Nandakumar
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

The open question was whether t= his should be UDP/DTLS/SCTP, or UDP/TLS/SCTP (DTLS implicit) to match the e= xisting UDP/TLS/RTP/SAVPF values defined in 5763.

=C2=A0

Upside of TLS: consistent with = precedent

Upside of DTLS: less confusing<= u>

=C2=A0

On Wed, Jan 21, 2015 at 5:31 PM= , Suhas Nandakumar <suhasietf@gmail.com> wrote:

They look right to=C2=A0me ..wo= uld let Christer confirm though

=C2=A0

Cheers

S= uhas



On Wednesday, January 21, 2015, Peter Thatcher <pthatcher@google.com> wrote:

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

e're <= /p>

=E2=80=8Bworking on implementing draft-ietf= -mmusic-sctp-sdp-12 and going through the process of making the change whil= e not breaking things and we'd like to not have to do this a second time. Before making this change, I'd like to be doubly clear that I go= t the right value for data channel m-lines:

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


"UDP/DTLS/SCTP"

=E2=80=8B (or "TCP/DTLS/SCTP")=

=C2=A0

=C2=A0

=C2=A0

=E2=80=8BIs that for sure the right value?= =E2=80=8B

=E2=80=8B

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0


--047d7bd75b347079c8050d456e7a-- From nobody Thu Jan 22 15:35: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 936891A0035 for ; Thu, 22 Jan 2015 15:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImqmKaIoH-ck for ; Thu, 22 Jan 2015 15:35:36 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05A61A0029 for ; Thu, 22 Jan 2015 15:35:35 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 34E562AA9C4F3; Thu, 22 Jan 2015 23:35:29 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0MNZVIo007958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 18:35:31 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 18:35:31 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Justin Uberti Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQNpwcTKo5Ls6cc0qYND9l0Sp34g== Date: Thu, 22 Jan 2015 23:35:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@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: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E6A5D45US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 22 Jan 2015 23:35:40 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E6A5D45US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMgYWxzbyBzdWdnZXN0aW5nIHRoZSBmb2xsb3dpbmcgaWRlbnRpZnlpbmcgc3RyaW5nIHRv IG1ha2UgaXQgdW5hbWJpZ3VvdXMgdXAgdG8gTDQgcHJvdG9jb2wuDQpJIGRvbuKAmXQgaGVhciBh bnkgb2JqZWN0aW9ucyB0byBpdCBleHBsaWNpdGx5LiBPciBkaWQgSSBtaXNpbnRlcnByZXQgdGhl IHJlc3BvbnNlPw0KRm9yIFRDUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVENQ L1JGQzQ1NzEvRFRMUy9TQ1RQDQpGb3IgVURQIElDRSBiYXNlZCBkYXRhIGNoYW5uZWwgdHJhbnNw b3J0OiBVRFAvRFRMUy9TQ1RQDQoNCkJSDQpSYWp1DQoNCkZyb206IEp1c3RpbiBVYmVydGkgW21h aWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAx NSA0OjQ1IFBNDQpUbzogTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KQ0KQ2M6IENocmlzdGVy IEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1bWFy OyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEl0J3MgIlVEUC9EVExT L1NDVFAiIGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0KDQpUaGUgcHJvdG9j b2wgaXMgdGhlIHNhbWUuIFdlIGFyZSBqdXN0IGRlY2lkaW5nIHdoYXQgdGhlIGlkZW50aWZ5aW5n IHN0cmluZyBzaG91bGQgYmUuDQoNCkdpdmVuIHRoZSBhbW91bnQgb2YgY29uZnVzaW9uIGluIHRo aXMgc3BhY2UsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gYmUgYXMgZXhwbGljaXQgYXMgcG9z c2libGUsIGFuZCB1c2UgRFRMUyBpbnN0ZWFkIG9mIFRMUyBmb3IgdGhlIG5hbWUuDQoNCk9uIFRo dSwgSmFuIDIyLCAyMDE1IGF0IDQ6MDEgQU0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkg PFJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpSYWp1Lk1ha2FyYWp1QGFs Y2F0ZWwtbHVjZW50LmNvbT4+IHdyb3RlOg0KRnJvbSBwcm90b2NvbCBzdGFja3MgbGF5ZXJpbmcg cG9pbnQgb2YgdmlldywgaXNu4oCZdCB0aGUgZm9sbG93aW5nIG1vcmUgYWNjdXJhdGVseSByZXBy ZXNlbnQgdGhlbT8NCkZvciBUQ1AgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFRD UC9SRkM0NTcxL0RUTFMvU0NUUA0KRm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5z cG9ydDogVURQL0RUTFMvU0NUUA0KDQpQZXIgbXkgdW5kZXJzdGFuZGluZywgaW5kZXBlbmRlbnQg b2YgdW5kZXJseWluZyB0cmFuc3BvcnQgKFVEUDsgb3Ig4oCcVENQIG92ZXIgUkZDNDQ3MeKAnSBm cmFtaW5nIG1pbWlja2luZyBkYXRhZ3JhbSB0cmFuc3BvcnQpIHRoZSBEVExTIHByb3RvY29sIGlz IHNhbWUuDQoNCkJSDQpSYWp1DQoNCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E6A5D45US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3YXMg YWxzbyBzdWdnZXN0aW5nIHRoZSBmb2xsb3dpbmcgaWRlbnRpZnlpbmcgc3RyaW5nIHRvIG1ha2Ug aXQgdW5hbWJpZ3VvdXMgdXAgdG8gTDQgcHJvdG9jb2wuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgZG9u4oCZdCBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGl0IGV4cGxpY2l0bHkuIE9y IGRpZCBJIG1pc2ludGVycHJldCB0aGUgcmVzcG9uc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Rm9yIFRDUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVENQL1JG QzQ1NzEvRFRMUy9TQ1RQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIFVEUCBJ Q0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMvU0NUUDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QlI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqdTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBn b29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAyMDE1 IDQ6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk8YnI+ DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVj aHQpOyBTdWhhcyBOYW5kYWt1bWFyOyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSXQncyAmcXVvdDtVRFAvRFRMUy9TQ1RQJnF1b3Q7IGZv ciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvdG9jb2wgaXMgdGhlIHNhbWUu IFdlIGFyZSBqdXN0IGRlY2lkaW5nIHdoYXQgdGhlIGlkZW50aWZ5aW5nIHN0cmluZyBzaG91bGQg YmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0 aGUgYW1vdW50IG9mIGNvbmZ1c2lvbiBpbiB0aGlzIHNwYWNlLCBJIHRoaW5rIGl0IG1ha2VzIHNl bnNlIHRvIGJlIGFzIGV4cGxpY2l0IGFzIHBvc3NpYmxlLCBhbmQgdXNlIERUTFMgaW5zdGVhZCBv ZiBUTFMgZm9yIHRoZSBuYW1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAyMiwgMjAxNSBhdCA0OjAxIEFNLCBNYWthcmFq dSwgTWFyaWRpIFJhanUgKFJhanUpICZsdDs8YSBocmVmPSJtYWlsdG86UmFqdS5NYWthcmFqdUBh bGNhdGVsLWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5SYWp1Lk1ha2FyYWp1QGFsY2F0ZWwt bHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Gcm9tIHByb3RvY29sIHN0YWNrcyBsYXllcmluZyBwb2ludCBvZiB2aWV3LCBpc27i gJl0IHRoZSBmb2xsb3dpbmcgbW9yZSBhY2N1cmF0ZWx5IHJlcHJlc2VudCB0aGVtPzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBUQ1AgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0 cmFuc3BvcnQ6IFRDUC9SRkM0NTcxL0RUTFMvU0NUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkZvciBVRFAgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFVEUC9EVExT L1NDVFA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5QZXIgbXkgdW5kZXJzdGFuZGluZywgaW5kZXBlbmRlbnQgb2Yg dW5kZXJseWluZyB0cmFuc3BvcnQgKFVEUDsgb3Ig4oCcVENQIG92ZXIgUkZDNDQ3MeKAnSBmcmFt aW5nIG1pbWlja2luZw0KIGRhdGFncmFtIHRyYW5zcG9ydCkgdGhlIERUTFMgcHJvdG9jb2wgaXMg c2FtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CUjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJh anU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E6A5D45US70UWXCHMBA02z_-- From nobody Thu Jan 22 16:00: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 5FD2E1A89BB for ; Thu, 22 Jan 2015 16:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFdwU7mewyFJ for ; Thu, 22 Jan 2015 15:59:59 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2021A89B8 for ; Thu, 22 Jan 2015 15:59:58 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id bs8so43514900wib.0 for ; Thu, 22 Jan 2015 15:59:57 -0800 (PST) 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=YhuL1RdoEyVHmKNSD1Gy4/18hYW/SBj1DqEhd6KTZ1g=; b=RJHBTUchg3q7jRGRkEhjKya4vpPgsWnV28Z3WQWQ28zNGwuhohipOagt+2Lssb7Y+s yYXItDflaEz/Bc3cc81BX85T2H1FieQ4ktgMOskf9uDAnuSWZQ3fsCyhVbCLLeYr6tKZ PJtX3ASXgzuoketN/3gPgHq1rD3TMWxnxMaFIN5gqA6PfT4zIcYK2cZl5YoK9/AnHSk2 iX4vGpj06bMFoCOpiOYNrF/890xhEtnu/K0B6ZVE7DSE/6bZXVgeQtI9fQnhR38yn4w5 TOn3BGdWiLcwfkW226c+cPLKPkEQyXB0VK6dwDrjuKOakzcDCgADjYSVicQZygTKoevZ hj/g== X-Gm-Message-State: ALoCoQndwGd1J68G54tYVFY1zXa7JcyjxPXo0+SK76RplTzXTxJFdtpu2GAbBbFqeHJ2XwwRq/5+ X-Received: by 10.180.210.167 with SMTP id mv7mr71218597wic.78.1421971197609; Thu, 22 Jan 2015 15:59:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.142.215 with HTTP; Thu, 22 Jan 2015 15:59:17 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Thu, 22 Jan 2015 15:59:17 -0800 Message-ID: To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c2691e1d6433050d46788d Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 23 Jan 2015 00:00:01 -0000 --001a11c2691e1d6433050d46788d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This seems fine to me. On Thu, Jan 22, 2015 at 2:45 PM, Justin Uberti wrote: > The protocol is the same. We are just deciding what the identifying strin= g > should be. > > Given the amount of confusion in this space, I think it makes sense to be > as explicit as possible, and use DTLS instead of TLS for the name. > > On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > >> From protocol stacks layering point of view, isn=E2=80=99t the followin= g more >> accurately represent them? >> >> For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP >> >> For UDP ICE based data channel transport: UDP/DTLS/SCTP >> >> >> >> Per my understanding, independent of underlying transport (UDP; or =E2= =80=9CTCP >> over RFC4471=E2=80=9D framing mimicking datagram transport) the DTLS pro= tocol is >> same. >> >> >> >> BR >> >> Raju >> >> >> >> >> >> >> >> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer >> Holmberg >> *Sent:* Thursday, January 22, 2015 5:09 AM >> *To:* Schwarz, Albrecht (Albrecht); Justin Uberti; Suhas Nandakumar >> >> *Cc:* >> *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel >> m-lines, right? >> >> >> >> So, you support using =E2=80=9CDTLS=E2=80=9D? :) >> >> >> >> *From:* Schwarz, Albrecht (Albrecht) [ >> mailto:albrecht.schwarz@alcatel-lucent.com >> ] >> *Sent:* 22 January 2015 10:24 >> *To:* Christer Holmberg; Justin Uberti; Suhas Nandakumar >> *Cc:* >> *Subject:* RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel >> m-lines, right? >> >> >> >> Despite the fact of cloase alignment between protocols DTLS and TLS, bot= h >> are still different protocols (e.g. capabilities concerning assured or >> non-assured L4 transport, protocol versioning, =E2=80=A6). >> >> >> >> Thus, my preference would be to use to correct name, i.e., =E2=80=9CDTLS= =E2=80=9D and not >> any indirect indication such as TLS based. >> >> Also because of the protocol stack segment =E2=80=9CTCP/DTLS/SCTP=E2=80= =9D (=E2=80=9Cthe indirect >> approach would be what? =E2=80=9CTCP/TLS/SCTP=E2=80=9D?=E2=80=9D which l= eads to ambiguities =E2=80=A6 due >> to native =E2=80=9CTCP/TLS/=E2=80=A6=E2=80=9D layering and RTCWEB requir= ed =E2=80=9CTCP/DTLS/=E2=80=A6 =E2=80=9C layering). >> >> >> >> Regards, >> >> Albrecht >> >> >> >> >> >> >> >> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org = ] >> *On Behalf Of *Christer Holmberg >> *Sent:* Donnerstag, 22. Januar 2015 07:49 >> *To:* Justin Uberti; Suhas Nandakumar >> *Cc:* >> *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel >> m-lines, right? >> >> >> >> Hi, >> >> >> >> My understanding of the outcome of the discussions was that we were goin= g >> to use =E2=80=9CDTLS=E2=80=9D. >> >> >> >> But, personally I could live with both, so if my understanding is wrong >> I=E2=80=99m happy to change the draft :) >> >> >> >> Note, however, that IF we change to =E2=80=9CTLS=E2=80=9D, then I guess = we also need to >> discuss the =E2=80=9CSCTP/DTLS=E2=80=9D value, and whether it should be = =E2=80=9CSCTP/TLS=E2=80=9D instead. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> *From:* rtcweb [mailto:rtcweb-bounces@ietf.org = ] >> *On Behalf Of *Justin Uberti >> *Sent:* 22 January 2015 07:37 >> *To:* Suhas Nandakumar >> *Cc:* >> *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel >> m-lines, right? >> >> >> >> The open question was whether this should be UDP/DTLS/SCTP, or >> UDP/TLS/SCTP (DTLS implicit) to match the existing UDP/TLS/RTP/SAVPF val= ues >> defined in 5763. >> >> >> >> Upside of TLS: consistent with precedent >> >> Upside of DTLS: less confusing >> >> >> >> On Wed, Jan 21, 2015 at 5:31 PM, Suhas Nandakumar >> wrote: >> >> They look right to me ..would let Christer confirm though >> >> >> >> Cheers >> >> Suhas >> >> >> >> On Wednesday, January 21, 2015, Peter Thatcher >> wrote: >> >> =E2=80=8BW=E2=80=8B >> >> e're >> >> =E2=80=8Bworking on implementing draft-ietf-mmusic-sctp-sdp-12 and going= through >> the process of making the change while not breaking things and we'd like= to >> not have to do this a second time. Before making this change, I'd like t= o >> be doubly clear that I got the right value for data channel m-lines: >> >> =E2=80=8B=E2=80=8B >> >> >> "UDP/DTLS/SCTP" >> >> =E2=80=8B (or "TCP/DTLS/SCTP") >> >> >> >> >> >> >> >> =E2=80=8BIs that for sure the right value?=E2=80=8B >> >> =E2=80=8B >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > > --001a11c2691e1d6433050d46788d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems fine to me.
On Thu, Jan 22, 2015 at 2:45 PM, Justin Uberti = <juberti@google.com> wrote:
The protocol is the same. We are just deciding what the= identifying string should be.

Given the amount of confu= sion in this space, I think it makes sense to be as explicit as possible, a= nd use DTLS instead of TLS for the name.
<= div class=3D"h5">

= On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

From protocol stacks laye= ring point of view, isn=E2=80=99t the following more accurately represent t= hem?

For TCP ICE based data ch= annel transport: TCP/RFC4571/DTLS/SCTP

For UDP ICE based data ch= annel transport: UDP/DTLS/SCTP

=C2=A0

Per my understanding, ind= ependent of underlying transport (UDP; or =E2=80=9CTCP over RFC4471=E2=80= =9D framing mimicking datagram transport) the DTLS protocol is same.=

=C2=A0

BR

Raju=

=C2=A0

=C2=A0

=C2=A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, January 22, 2015 5:09 AM
To: Schwarz, Albrecht (Albrecht); Justin Uberti; Suhas Nandakumar


Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

So, you su= pport using =E2=80=9CDTLS=E2=80=9D? :)

=C2=A0

From: Schwar= z, Albrecht (Albrecht) [mailto:albrecht.schwarz@alcatel-lucent.com]
Sent: 22 January 2015 10:24
To: Christer Holmberg; Justin Uberti; Suhas Nandakumar
Cc: <rtcweb@= ietf.org>
Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

Despite the fact of cloase alignment between= protocols DTLS and TLS, both are still different protocols (e.g. capabilit= ies concerning assured or non-assured L4 transport, protocol versioning, =E2=80=A6).

=C2=A0

Thus, my preference would be to use to corre= ct name, i.e., =E2=80=9CDTLS=E2=80=9D and not any indirect indication such = as TLS based.

Also because of the protocol stack segment = =E2=80=9CTCP/DTLS/SCTP=E2=80=9D (=E2=80=9Cthe indirect approach would be wh= at? =E2=80=9CTCP/TLS/SCTP=E2=80=9D?=E2=80=9D which leads to ambiguities =E2= =80=A6 due to native =E2=80=9CTCP/TLS/=E2=80=A6=E2=80=9D layering and RTCWEB required =E2=80=9C= TCP/DTLS/=E2=80=A6 =E2=80=9C layering).

=C2=A0

Regards,

Albrecht

=C2=A0

=C2=A0

=C2= =A0

From: rtcweb [= mailto:rtcweb-= bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Donnerstag, 22. Januar 2015 07:49
To: Justin Uberti; Suhas Nandakumar
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

Hi,=

=C2= =A0

My underst= anding of the outcome of the discussions was that we were going to use =E2= =80=9CDTLS=E2=80=9D.

=C2= =A0

But, perso= nally I could live with both, so if my understanding is wrong I=E2=80=99m h= appy to change the draft :)

=C2= =A0

Note, howe= ver, that IF we change to =E2=80=9CTLS=E2=80=9D, then I guess we also need = to discuss the =E2=80=9CSCTP/DTLS=E2=80=9D value, and whether it should be = =E2=80=9CSCTP/TLS=E2=80=9D instead.

=C2= =A0

Regards,

=C2= =A0

Christer

=C2= =A0

=C2= =A0

=C2= =A0

From: rtcweb= [mailto:rtcwe= b-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 22 January 2015 07:37
To: Suhas Nandakumar
Cc: <rtcweb@= ietf.org>
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

The open question was whether t= his should be UDP/DTLS/SCTP, or UDP/TLS/SCTP (DTLS implicit) to match the e= xisting UDP/TLS/RTP/SAVPF values defined in 5763.

=C2=A0

Upside of TLS: consistent with = precedent

Upside of DTLS: less confusing<= u>

=C2=A0

On Wed, Jan 21, 2015 at 5:31 PM= , Suhas Nandakumar <suhasietf@gmail.com> wrote:

They look right to=C2=A0me ..wo= uld let Christer confirm though

=C2=A0

Cheers

S= uhas



On Wednesday, January 21, 2015, Peter Thatcher <pthatcher@google.com> wrote:

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

e're <= /p>

=E2=80=8Bworking on implementing draft-ietf= -mmusic-sctp-sdp-12 and going through the process of making the change whil= e not breaking things and we'd like to not have to do this a second time. Before making this change, I'd like to be doubly clear that I go= t the right value for data channel m-lines:

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


"UDP/DTLS/SCTP"

=E2=80=8B (or "TCP/DTLS/SCTP")=

=C2=A0

=C2=A0

=C2=A0

=E2=80=8BIs that for sure the right value?= =E2=80=8B

=E2=80=8B

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0



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


--001a11c2691e1d6433050d46788d-- From nobody Thu Jan 22 19:57: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 E77D91A0125 for ; Thu, 22 Jan 2015 19:57:28 -0800 (PST) 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 Npijo7thbcl3 for ; Thu, 22 Jan 2015 19:57:24 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::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 906461A0130 for ; Thu, 22 Jan 2015 19:57:24 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rl12so5240086iec.11 for ; Thu, 22 Jan 2015 19:57:23 -0800 (PST) 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=c35Wg9/36lIYqCa+BLgVFqhL159BE1SVsFVRKjHVxyM=; b=b00pnpRdOQ621YuoiySHZh4X9+AFrtMzeBsGd5wHwAFo38Weq+b6rOX1BFaYvsRhUz Z6ThpSy22vhRlI6s8OH/2vcNVjA8R4jZ1fMGA6vH2MI/+L2IU1Eos1G1hBf/rtS4ml8+ EEC4NpANbR4xVcwJHAhlojRiFt9mXUsOsMY3VPU4K+0g8NndN9+9SbFWiRwU8ybw0TdO O2i2FMpNLpEut+mOvO2CMApFr1/BwLvZ19Vs1hbkTZZCt7khqvYDMuSnE25qsFUUd/U8 W5j6Rk4xkZB4GogsIxjtrlBKVPTEt8OjiY0dBJoo32MDnDSQEG2TSQW0smgiWcVSou8L S8JQ== 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=c35Wg9/36lIYqCa+BLgVFqhL159BE1SVsFVRKjHVxyM=; b=blMAvvsyHCAAWEtCmfO32Zkaa9PlYX6l8bwIUch9FHJy4sLSJ4h85ON+XvuxBlAd/1 MgvxtzEtuph9rnw6Bwd5/qunKVSeMsie5i9IpoPcFtG2dnGrWWAvOJikPl4ZqRJ1RPSS e7L8P4ZroY1qA3G98f3yeKUauD18usFu8g1nnUtSLakjY7Y4MvIBv2dBWLSxbCIfQxPP +M10MX3i7JKwaSQNDT0DOf4Qe9yvWIAAw94g/Kg9OQaQbhz1RiA3WZdGZO647pSJBFOJ svEmsJ2GGfvW4akfdXDiYqo7qQim3d1E2KNGnf28BE3WthBh+nO++irpY//lyJHHhjo/ usiw== X-Gm-Message-State: ALoCoQl6MxRroAhikooSdSDfY+mJ/sGHUOyNW2f7Q905T9YdIXZa0nv1fePMioFbjQCYxxyxwJsU X-Received: by 10.50.32.7 with SMTP id e7mr8215268igi.21.1421985443611; Thu, 22 Jan 2015 19:57:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.64.66 with HTTP; Thu, 22 Jan 2015 19:57:03 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> From: Justin Uberti Date: Thu, 22 Jan 2015 19:57:03 -0800 Message-ID: To: "Makaraju, Maridi Raju (Raju)" Content-Type: multipart/alternative; boundary=047d7b10cbf13e740e050d49c923 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 23 Jan 2015 03:57:29 -0000 --047d7b10cbf13e740e050d49c923 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, I don't think including RFC4571 is reasonable. That ship has already sailed. On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) < Raju.Makaraju@alcatel-lucent.com> wrote: > I was also suggesting the following identifying string to make it > unambiguous up to L4 protocol. > > I don=E2=80=99t hear any objections to it explicitly. Or did I misinterpr= et the > response? > > For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP > > For UDP ICE based data channel transport: UDP/DTLS/SCTP > > > > BR > > Raju > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Thursday, January 22, 2015 4:45 PM > *To:* Makaraju, Maridi Raju (Raju) > *Cc:* Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = < > rtcweb@ietf.org> > *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > The protocol is the same. We are just deciding what the identifying strin= g > should be. > > > > Given the amount of confusion in this space, I think it makes sense to be > as explicit as possible, and use DTLS instead of TLS for the name. > > > > On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > > From protocol stacks layering point of view, isn=E2=80=99t the following = more > accurately represent them? > > For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP > > For UDP ICE based data channel transport: UDP/DTLS/SCTP > > > > Per my understanding, independent of underlying transport (UDP; or =E2=80= =9CTCP > over RFC4471=E2=80=9D framing mimicking datagram transport) the DTLS prot= ocol is > same. > > > > BR > > Raju > > > --047d7b10cbf13e740e050d49c923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, I don't think including RFC4571 is reasonable. Tha= t ship has already sailed.

On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) = <Raju.Makaraju@alcatel-lucent.com> wrote:
=

I was also suggesting the= following identifying string to make it unambiguous up to L4 protocol.<= /u>

I don=E2=80=99t hear any = objections to it explicitly. Or did I misinterpret the response?<= /u>

For TCP ICE based data ch= annel transport: TCP/RFC4571/DTLS/SCTP

For UDP ICE based data ch= annel transport: UDP/DTLS/SCTP

=C2=A0

BR

Raju=

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Thursday, January 22, 2015 4:45 PM
To: Makaraju, Maridi Raju (Raju)
Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakuma= r; <rtcweb@ietf.org= >
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

The protocol is the same. We are just deciding what = the identifying string should be.

=C2=A0

Given the amount of confusion in this space, I think= it makes sense to be as explicit as possible, and use DTLS instead of TLS = for the name.

=C2=A0

On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Ra= ju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

From protocol stacks laye= ring point of view, isn=E2=80=99t the following more accurately represent t= hem?

For TCP ICE based data ch= annel transport: TCP/RFC4571/DTLS/SCTP

For UDP ICE based data ch= annel transport: UDP/DTLS/SCTP

=C2=A0

Per my understanding, ind= ependent of underlying transport (UDP; or =E2=80=9CTCP over RFC4471=E2=80= =9D framing mimicking datagram transport) the DTLS protocol is same.

=C2=A0

BR

Raju=

=C2=A0


--047d7b10cbf13e740e050d49c923-- From nobody Thu Jan 22 23:22: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 4355F1A020A for ; Thu, 22 Jan 2015 23:22:22 -0800 (PST) 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 EcNWzmLfbd4u for ; Thu, 22 Jan 2015 23:22:19 -0800 (PST) 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 244CB1A1A56 for ; Thu, 22 Jan 2015 23:22:16 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-30-54c1f6a61c2e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.D8.04076.6A6F1C45; Fri, 23 Jan 2015 08:22:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 08:22:14 +0100 From: Christer Holmberg To: Justin Uberti , "Makaraju, Maridi Raju (Raju)" Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQNpUn47h1VHtlW0+kjJ7ECk9YHJzMukqAgABJEoCAAEmIkA== Date: Fri, 23 Jan 2015 07:22:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D678F81ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM+Jvje6ybwdDDJa1mVv8af3FaLF1qpBF w8YrrBZr/7WzW+yc28HswOrR+mwvq8fOWXfZPRZsKvVYsuQnUwBLFJdNSmpOZllqkb5dAlfG 2mufWAoeTGCs+LDyL3MD44cexi5GTg4JAROJPU2XoWwxiQv31rOB2EICRxglbj1N6mLkArIX M0psvfEJKMHBwSZgIdH9TxukRkQgW6Lx6XEmkBpmgZmMEh/fvWIGSQgLBErsWbGRDaIoCKho FhOE7SSxY99DsGUsAqoSDyYuAIvzCvhKLFr3lRli2VtWiZcL9jOBLOMEGrSwrxCkhhHouO+n 1oDVMwuIS9x6Mp8J4mgBiSV7zjND2KISLx//Y4WwFSU+vtrHCFGfL7Hg8FYWiF2CEidnPmGZ wCg6C8moWUjKZiEpmwV0BbOApsT6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRfxShanFpcnJtu ZKSXWpSZXFycn6eXl1qyiREYnwe3/LbawXjwueMhRgEORiUe3oKPB0OEWBPLiitzDzFKc7Ao ifPmOWwIERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY5CEa2cl2SeAFv6TSjhVKO7WSuH8u z/1+o/P/26naBqmLC+s9Qk9Uz3byELSd/+yNj5nNtDVVC03Oic2/LqBWrijSki5RdEt33mSh y62LFvO4P+Of+dOnOevfi25G+4O2G1Zqv9e6fnN6fbwIq7W1Gm9fS9ma+y771Po5rtuaf/Mx 3S+p06rEUpyRaKjFXFScCABdd3X5sAIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 23 Jan 2015 07:22:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D678F81ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbm90IHVzZSBSRkMgbnVtYmVycyBpbiBwcm90 byB2YWx1ZXMuDQoNCkFsc28ga2VlcCBpbiBtaW5kIHRoYXQgVURQL0RUTFMvU0NUUCBkb2VzIG5v dCBtZWFuIOKAnElDRSBiYXNlZOKAnS4gSUNFIGlzIG9wdGlvbmFsIGZvciBVRFAvRFRMUy9TQ1RQ ICh0aGF0IGZhY3QgdGhhdCB3ZSBtYW5kYXRlIElDRSBmb3IgUlRDV0VCIGlzIGEgc2VwYXJhdGUg aXNzdWUpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFtt YWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogMjMuIHRhbW1pa3V1dGEgMjAxNSA1OjU3 DQpUbzogTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KQ0KQ2M6IENocmlzdGVyIEhvbG1iZXJn OyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1bWFyOyA8cnRjd2Vi QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEl0J3MgIlVEUC9EVExTL1NDVFAiIGZv ciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0KDQpObywgSSBkb24ndCB0aGluayBp bmNsdWRpbmcgUkZDNDU3MSBpcyByZWFzb25hYmxlLiBUaGF0IHNoaXAgaGFzIGFscmVhZHkgc2Fp bGVkLg0KDQpPbiBUaHUsIEphbiAyMiwgMjAxNSBhdCAzOjM1IFBNLCBNYWthcmFqdSwgTWFyaWRp IFJhanUgKFJhanUpIDxSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86UmFq dS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCkkgd2FzIGFsc28gc3VnZ2Vz dGluZyB0aGUgZm9sbG93aW5nIGlkZW50aWZ5aW5nIHN0cmluZyB0byBtYWtlIGl0IHVuYW1iaWd1 b3VzIHVwIHRvIEw0IHByb3RvY29sLg0KSSBkb27igJl0IGhlYXIgYW55IG9iamVjdGlvbnMgdG8g aXQgZXhwbGljaXRseS4gT3IgZGlkIEkgbWlzaW50ZXJwcmV0IHRoZSByZXNwb25zZT8NCkZvciBU Q1AgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFRDUC9SRkM0NTcxL0RUTFMvU0NU UA0KRm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMvU0NU UA0KDQpCUg0KUmFqdQ0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29n bGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+XQ0KU2VudDogVGh1cnNkYXksIEphbnVh cnkgMjIsIDIwMTUgNDo0NSBQTQ0KVG86IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkNCkNj OiBDaHJpc3RlciBIb2xtYmVyZzsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgU3VoYXMg TmFuZGFrdW1hcjsgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbcnRjd2ViXSBJdCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhlIGRhdGEgY2hh bm5lbCBtLWxpbmVzLCByaWdodD8NCg0KVGhlIHByb3RvY29sIGlzIHRoZSBzYW1lLiBXZSBhcmUg anVzdCBkZWNpZGluZyB3aGF0IHRoZSBpZGVudGlmeWluZyBzdHJpbmcgc2hvdWxkIGJlLg0KDQpH aXZlbiB0aGUgYW1vdW50IG9mIGNvbmZ1c2lvbiBpbiB0aGlzIHNwYWNlLCBJIHRoaW5rIGl0IG1h a2VzIHNlbnNlIHRvIGJlIGFzIGV4cGxpY2l0IGFzIHBvc3NpYmxlLCBhbmQgdXNlIERUTFMgaW5z dGVhZCBvZiBUTFMgZm9yIHRoZSBuYW1lLg0KDQpPbiBUaHUsIEphbiAyMiwgMjAxNSBhdCA0OjAx IEFNLCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIDxSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwt bHVjZW50LmNvbTxtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90 ZToNCkZyb20gcHJvdG9jb2wgc3RhY2tzIGxheWVyaW5nIHBvaW50IG9mIHZpZXcsIGlzbuKAmXQg dGhlIGZvbGxvd2luZyBtb3JlIGFjY3VyYXRlbHkgcmVwcmVzZW50IHRoZW0/DQpGb3IgVENQIElD RSBiYXNlZCBkYXRhIGNoYW5uZWwgdHJhbnNwb3J0OiBUQ1AvUkZDNDU3MS9EVExTL1NDVFANCkZv ciBVRFAgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFVEUC9EVExTL1NDVFANCg0K UGVyIG15IHVuZGVyc3RhbmRpbmcsIGluZGVwZW5kZW50IG9mIHVuZGVybHlpbmcgdHJhbnNwb3J0 IChVRFA7IG9yIOKAnFRDUCBvdmVyIFJGQzQ0NzHigJ0gZnJhbWluZyBtaW1pY2tpbmcgZGF0YWdy YW0gdHJhbnNwb3J0KSB0aGUgRFRMUyBwcm90b2NvbCBpcyBzYW1lLg0KDQpCUg0KUmFqdQ0KDQoN Cg== --_000_7594FB04B1934943A5C02806D1A2204B1D678F81ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgd2Ugc2hvdWxkIG5vdCB1c2Ug UkZDIG51bWJlcnMgaW4gcHJvdG8gdmFsdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxzbyBrZWVwIGluIG1pbmQg dGhhdCBVRFAvRFRMUy9TQ1RQIGRvZXMgbm90IG1lYW4g4oCcSUNFIGJhc2Vk4oCdLiBJQ0UgaXMg b3B0aW9uYWwgZm9yIFVEUC9EVExTL1NDVFAgKHRoYXQgZmFjdCB0aGF0IHdlIG1hbmRhdGUgSUNF IGZvciBSVENXRUIgaXMgYSBzZXBhcmF0ZSBpc3N1ZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gMjMuIHRhbW1pa3V1dGEgMjAxNSA1OjU3PGJyPg0KPGI+VG86PC9iPiBNYWthcmFqdSwg TWFyaWRpIFJhanUgKFJhanUpPGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBIb2xtYmVyZzsgU2No d2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgU3VoYXMgTmFuZGFrdW1hcjsgJmx0O3J0Y3dlYkBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIEl0J3MgJnF1b3Q7 VURQL0RUTFMvU0NUUCZxdW90OyBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxpbmVzLCByaWdodD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObywgSSBkb24ndCB0aGluayBp bmNsdWRpbmcgUkZDNDU3MSBpcyByZWFzb25hYmxlLiBUaGF0IHNoaXAgaGFzIGFscmVhZHkgc2Fp bGVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDIy LCAyMDE1IGF0IDM6MzUgUE0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgJmx0OzxhIGhy ZWY9Im1haWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2FzIGFsc28gc3VnZ2VzdGluZyB0 aGUgZm9sbG93aW5nIGlkZW50aWZ5aW5nIHN0cmluZyB0byBtYWtlIGl0IHVuYW1iaWd1b3VzIHVw IHRvIEw0IHByb3RvY29sLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZ dCBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGl0IGV4cGxpY2l0bHkuIE9yIGRpZCBJIG1pc2ludGVy cHJldCB0aGUgcmVzcG9uc2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIFRD UCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVENQL1JGQzQ1NzEvRFRMUy9TQ1RQ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBj aGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMvU0NUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAyMDE1IDQ6NDUg UE08YnI+DQo8Yj5Ubzo8L2I+IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk8YnI+DQo8Yj5D Yzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBT dWhhcyBOYW5kYWt1bWFyOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbcnRjd2ViXSBJdCdzICZxdW90O1VEUC9EVExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRh IGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgcHJvdG9jb2wgaXMgdGhlIHNhbWUuIFdlIGFy ZSBqdXN0IGRlY2lkaW5nIHdoYXQgdGhlIGlkZW50aWZ5aW5nIHN0cmluZyBzaG91bGQgYmUuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R2l2ZW4gdGhl IGFtb3VudCBvZiBjb25mdXNpb24gaW4gdGhpcyBzcGFjZSwgSSB0aGluayBpdCBtYWtlcyBzZW5z ZSB0byBiZSBhcyBleHBsaWNpdCBhcyBwb3NzaWJsZSwgYW5kIHVzZSBEVExTIGluc3RlYWQgb2Yg VExTIGZvciB0aGUgbmFtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgSmFuIDIyLCAyMDE1IGF0IDQ6MDEgQU0sIE1ha2Fy YWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgJmx0OzxhIGhyZWY9Im1haWx0bzpSYWp1Lk1ha2FyYWp1 QGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlJhanUuTWFrYXJhanVAYWxjYXRl bC1sdWNlbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkZyb20gcHJvdG9jb2wgc3RhY2tzIGxheWVyaW5nIHBvaW50IG9mIHZpZXcsIGlz buKAmXQgdGhlIGZvbGxvd2luZyBtb3JlIGFjY3VyYXRlbHkgcmVwcmVzZW50IHRoZW0/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIFRDUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVs IHRyYW5zcG9ydDogVENQL1JGQzQ1NzEvRFRMUy9TQ1RQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Rm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RU TFMvU0NUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBlciBteSB1bmRlcnN0YW5kaW5nLCBpbmRlcGVuZGVudCBv ZiB1bmRlcmx5aW5nIHRyYW5zcG9ydCAoVURQOyBvciDigJxUQ1Agb3ZlciBSRkM0NDcx4oCdIGZy YW1pbmcgbWltaWNraW5nDQogZGF0YWdyYW0gdHJhbnNwb3J0KSB0aGUgRFRMUyBwcm90b2NvbCBp cyBzYW1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ UmFqdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D678F81ESESSMB209erics_-- From nobody Fri Jan 23 00:57:50 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFBB1A00F6; Fri, 23 Jan 2015 00:57:35 -0800 (PST) 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 gyGqXjOwUFc5; Fri, 23 Jan 2015 00:57:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 040E91A01D8; Fri, 23 Jan 2015 00:57:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123085733.5995.26420.idtracker@ietfa.amsl.com> Date: Fri, 23 Jan 2015 00:57:33 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-16.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, 23 Jan 2015 08:57:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Authors : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-16.txt Pages : 34 Date : 2015-01-23 Abstract: This document describes web based real-time communication use-cases. Requirements on the browser functionality are derived from the use- cases. This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WGs efforts so far. It is being published to record the early conclusions of the working group. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-use-cases-and-requirements-16 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 Jan 23 10:37:51 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAD81A8702; Fri, 23 Jan 2015 10:37:18 -0800 (PST) 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 Sn7xkITuNsJ5; Fri, 23 Jan 2015 10:37:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEF91A871D; Fri, 23 Jan 2015 10:37:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150123183714.27411.87824.idtracker@ietfa.amsl.com> Date: Fri, 23 Jan 2015 10:37:14 -0800 Archived-At: Cc: rtcweb mailing list , rtcweb chair , RFC Editor Subject: [rtcweb] Document Action: 'Web Real-Time Communication Use-cases and Requirements' to Informational RFC (draft-ietf-rtcweb-use-cases-and-requirements-16.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, 23 Jan 2015 18:37:19 -0000 The IESG has approved the following document: - 'Web Real-Time Communication Use-cases and Requirements' (draft-ietf-rtcweb-use-cases-and-requirements-16.txt) as Informational RFC This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Richard Barnes and Ben Campbell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ Technical Summary This document discusses a number of usages of browser based real-time communication and data transfer capabilities and establish requirements for these usages. The document is intended to be used both in IETF and W3C during the development of the WebRTC specifications. Working Group Summary The document has been under development during a longer period and a larger number of use cases has been proposed then what is included in the document. These that have been included has been considered the most basic, most relevant to core functionality and without significant controversies. Document Quality There has been some concerns about the structure of the document, but the WG see no significant need to address this. The document is requested to be published as a documentation of the core consideration around usages that was of interest during the first part of the WebRTC work. The other expected usage of this document will be to analyze if the resulting protocol solution will enable the considered use cases. The document has been reviewed and commented on by a significant number of people within the WG, including persons active in the W3C WEBRTC WG. Personnel Magnus Westerlund is the Document Shepherd. Richard Barnes is the Responsible Area Director. RFC Editor Note One minor change to address Stephen's DISCUSS. OLD: A malicious web application might use the browser to perform Denial Of Service (DOS) attacks on NAT infrastructure, or on peer devices. Also, a malicious web application might silently establish outgoing, and accept incoming, streams on an already established connection. NEW: A malicious web application might use the browser to perform Denial Of Service (DOS) attacks on NAT infrastructure, or on peer devices. For example, a malicious web application might leak TURN credentials to unauthorized parties, allowing them to consume the TURN server's bandwidth. To address this risk, Web applications should be prepared to revoke TURN credentials and issue new ones. Also, a malicious web application might silently establish outgoing, and accept incoming, streams on an already established connection. From nobody Sat Jan 24 05:35: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 90C1B1A0A85 for ; Sat, 24 Jan 2015 05:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfHIO_FMOWqg for ; Sat, 24 Jan 2015 05:35:35 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3941A0035 for ; Sat, 24 Jan 2015 05:35:33 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 475BDE03047DA; Sat, 24 Jan 2015 13:35:27 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0ODZTPB018618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 24 Jan 2015 08:35:29 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Sat, 24 Jan 2015 08:35:29 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Justin Uberti Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQNpwcTKo5Ls6cc0qYND9l0Sp34pzNZ+SAgAA5UoCAAaSbQA== Date: Sat, 24 Jan 2015 13:35:28 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E6A88E6US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 24 Jan 2015 13:35:37 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E6A88E6US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBvayB0byB1c2UgVURQL0RUTFMvU0NUUCBhbmQgVENQL0RUTFMvU0NUUC4NCkkgYWdyZWUg dGhhdCB1c2Ugb2YgUkZDICNzIGlzIG5vdCB0aGUgYmVzdCBvcHRpb24uDQpIb3dldmVyLCBJIGZp bmQgc29tZSB1bmVhc2UgaW4gdGhlIGRpc2N1c3Npb25zIGFib3V0IOKAnFRDUC9EVExT4oCdIHBh cnQsIHdoaWNoIHNlZW1zIHRvIHN1Z2dlc3Qgd2h5IG5vdCB1c2Ug4oCcVENQL1RMU+KAnT8gIFdl IHVuZGVyc3RhbmQgdGhhdCBpdCBjYW7igJl0IGJlIGNhbGxlZCB0aGF0IHdheSBiZWNhdXNlIG9m IHRoZSBSRkMgNDU3MSDigJxzaGltIGxheWVy4oCdIGluIGJldHdlZW4gRFRMUyBhbmQgVENQIGxh eWVycy4gVW5mb3J0dW5hdGVseSwgdW5saWtlIFRQS1QsIFJGQyA0NTcxIGRpZCBub3QgZ2l2ZSBh IG5hbWUgdG8gdGhlIHByb3RvY29sLCB3aGljaCB3b3VsZCBoYXZlIGJlZW4gZWFzeSB0byB1c2Ug dGhhbiB0aGUgUkZDIGRpcmVjdGx5Lg0KDQpCUg0KUmFqdQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJl cmcgW21haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBGcmlkYXks IEphbnVhcnkgMjMsIDIwMTUgMToyMiBBTQ0KVG86IEp1c3RpbiBVYmVydGk7IE1ha2FyYWp1LCBN YXJpZGkgUmFqdSAoUmFqdSkNCkNjOiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBTdWhh cyBOYW5kYWt1bWFyOyA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtydGN3ZWJdIEl0 J3MgIlVEUC9EVExTL1NDVFAiIGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0K DQpIaSwNCg0KSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgdXNlIFJGQyBudW1iZXJzIGluIHBy b3RvIHZhbHVlcy4NCg0KQWxzbyBrZWVwIGluIG1pbmQgdGhhdCBVRFAvRFRMUy9TQ1RQIGRvZXMg bm90IG1lYW4g4oCcSUNFIGJhc2Vk4oCdLiBJQ0UgaXMgb3B0aW9uYWwgZm9yIFVEUC9EVExTL1ND VFAgKHRoYXQgZmFjdCB0aGF0IHdlIG1hbmRhdGUgSUNFIGZvciBSVENXRUIgaXMgYSBzZXBhcmF0 ZSBpc3N1ZSkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkg W21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiAyMy4gdGFtbWlrdXV0YSAyMDE1IDU6 NTcNClRvOiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpDQpDYzogQ2hyaXN0ZXIgSG9sbWJl cmc7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFN1aGFzIE5hbmRha3VtYXI7IDxydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gSXQncyAiVURQL0RUTFMvU0NUUCIgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmln aHQ/DQoNCk5vLCBJIGRvbid0IHRoaW5rIGluY2x1ZGluZyBSRkM0NTcxIGlzIHJlYXNvbmFibGUu IFRoYXQgc2hpcCBoYXMgYWxyZWFkeSBzYWlsZWQuDQoNCk9uIFRodSwgSmFuIDIyLCAyMDE1IGF0 IDM6MzUgUE0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgPFJhanUuTWFrYXJhanVAYWxj YXRlbC1sdWNlbnQuY29tPG1haWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbT4+ IHdyb3RlOg0KSSB3YXMgYWxzbyBzdWdnZXN0aW5nIHRoZSBmb2xsb3dpbmcgaWRlbnRpZnlpbmcg c3RyaW5nIHRvIG1ha2UgaXQgdW5hbWJpZ3VvdXMgdXAgdG8gTDQgcHJvdG9jb2wuDQpJIGRvbuKA mXQgaGVhciBhbnkgb2JqZWN0aW9ucyB0byBpdCBleHBsaWNpdGx5LiBPciBkaWQgSSBtaXNpbnRl cnByZXQgdGhlIHJlc3BvbnNlPw0KRm9yIFRDUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5z cG9ydDogVENQL1JGQzQ1NzEvRFRMUy9TQ1RQDQpGb3IgVURQIElDRSBiYXNlZCBkYXRhIGNoYW5u ZWwgdHJhbnNwb3J0OiBVRFAvRFRMUy9TQ1RQDQoNCkJSDQpSYWp1DQoNCkZyb206IEp1c3RpbiBV YmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNv bT5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSA0OjQ1IFBNDQpUbzogTWFrYXJh anUsIE1hcmlkaSBSYWp1IChSYWp1KQ0KQ2M6IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBB bGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1bWFyOyA8cnRjd2ViQGlldGYub3JnPG1h aWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEl0J3MgIlVEUC9E VExTL1NDVFAiIGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0KDQpUaGUgcHJv dG9jb2wgaXMgdGhlIHNhbWUuIFdlIGFyZSBqdXN0IGRlY2lkaW5nIHdoYXQgdGhlIGlkZW50aWZ5 aW5nIHN0cmluZyBzaG91bGQgYmUuDQoNCkdpdmVuIHRoZSBhbW91bnQgb2YgY29uZnVzaW9uIGlu IHRoaXMgc3BhY2UsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gYmUgYXMgZXhwbGljaXQgYXMg cG9zc2libGUsIGFuZCB1c2UgRFRMUyBpbnN0ZWFkIG9mIFRMUyBmb3IgdGhlIG5hbWUuDQoNCk9u IFRodSwgSmFuIDIyLCAyMDE1IGF0IDQ6MDEgQU0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFq dSkgPFJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpSYWp1Lk1ha2FyYWp1 QGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdyb3RlOg0KRnJvbSBwcm90b2NvbCBzdGFja3MgbGF5ZXJp bmcgcG9pbnQgb2YgdmlldywgaXNu4oCZdCB0aGUgZm9sbG93aW5nIG1vcmUgYWNjdXJhdGVseSBy ZXByZXNlbnQgdGhlbT8NCkZvciBUQ1AgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6 IFRDUC9SRkM0NTcxL0RUTFMvU0NUUA0KRm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRy YW5zcG9ydDogVURQL0RUTFMvU0NUUA0KDQpQZXIgbXkgdW5kZXJzdGFuZGluZywgaW5kZXBlbmRl bnQgb2YgdW5kZXJseWluZyB0cmFuc3BvcnQgKFVEUDsgb3Ig4oCcVENQIG92ZXIgUkZDNDQ3MeKA nSBmcmFtaW5nIG1pbWlja2luZyBkYXRhZ3JhbSB0cmFuc3BvcnQpIHRoZSBEVExTIHByb3RvY29s IGlzIHNhbWUuDQoNCkJSDQpSYWp1DQoNCg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E6A88E6US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIG9rIHRvIHVz ZSBVRFAvRFRMUy9TQ1RQIGFuZCBUQ1AvRFRMUy9TQ1RQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGFncmVlIHRoYXQgdXNlIG9mIFJGQyAjcyBpcyBub3QgdGhlIGJlc3Qgb3B0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBJIGZpbmQgc29tZSB1bmVh c2UgaW4gdGhlIGRpc2N1c3Npb25zIGFib3V0IOKAnFRDUC9EVExT4oCdIHBhcnQsIHdoaWNoIHNl ZW1zIHRvIHN1Z2dlc3Qgd2h5IG5vdCB1c2Ug4oCcVENQL1RMU+KAnT8gJm5ic3A7V2UgdW5kZXJz dGFuZCB0aGF0IGl0IGNhbuKAmXQgYmUgY2FsbGVkIHRoYXQNCiB3YXkgYmVjYXVzZSBvZiB0aGUg UkZDIDQ1NzEg4oCcc2hpbSBsYXllcuKAnSBpbiBiZXR3ZWVuIERUTFMgYW5kIFRDUCBsYXllcnMu IFVuZm9ydHVuYXRlbHksIHVubGlrZSBUUEtULCBSRkMgNDU3MSBkaWQgbm90IGdpdmUgYSBuYW1l IHRvIHRoZSBwcm90b2NvbCwgd2hpY2ggd291bGQgaGF2ZSBiZWVuIGVhc3kgdG8gdXNlIHRoYW4g dGhlIFJGQyBkaXJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJhanU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSmFudWFyeSAyMywgMjAxNSAx OjIyIEFNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gVWJlcnRpOyBNYWthcmFqdSwgTWFyaWRpIFJh anUgKFJhanUpPGJyPg0KPGI+Q2M6PC9iPiBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBT dWhhcyBOYW5kYWt1bWFyOyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogW3J0Y3dlYl0gSXQncyAmcXVvdDtVRFAvRFRMUy9TQ1RQJnF1b3Q7IGZvciB0aGUg ZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbm90IHVzZSBSRkMgbnVt YmVycyBpbiBwcm90byB2YWx1ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbHNvIGtlZXAgaW4gbWluZCB0aGF0IFVE UC9EVExTL1NDVFAgZG9lcyBub3QgbWVhbiDigJxJQ0UgYmFzZWTigJ0uIElDRSBpcyBvcHRpb25h bCBmb3IgVURQL0RUTFMvU0NUUCAodGhhdCBmYWN0IHRoYXQgd2UgbWFuZGF0ZSBJQ0UgZm9yIFJU Q1dFQiBpcyBhIHNlcGFyYXRlIGlzc3VlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5D aHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGlu IFViZXJ0aSBbPGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSI+bWFpbHRvOmp1YmVy dGlAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjMuIHRhbW1pa3V1dGEgMjAx NSA1OjU3PGJyPg0KPGI+VG86PC9iPiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpPGJyPg0K PGI+Q2M6PC9iPiBDaHJpc3RlciBIb2xtYmVyZzsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0 KTsgU3VoYXMgTmFuZGFrdW1hcjsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmci PnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2Vi XSBJdCdzICZxdW90O1VEUC9EVExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1s aW5lcywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8sIEkg ZG9uJ3QgdGhpbmsgaW5jbHVkaW5nIFJGQzQ1NzEgaXMgcmVhc29uYWJsZS4gVGhhdCBzaGlwIGhh cyBhbHJlYWR5IHNhaWxlZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBUaHUsIEphbiAyMiwgMjAxNSBhdCAzOjM1IFBNLCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJh anUpICZsdDs8YSBocmVmPSJtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20i IHRhcmdldD0iX2JsYW5rIj5SYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdhcyBhbHNv IHN1Z2dlc3RpbmcgdGhlIGZvbGxvd2luZyBpZGVudGlmeWluZyBzdHJpbmcgdG8gbWFrZSBpdCB1 bmFtYmlndW91cyB1cCB0byBMNCBwcm90b2NvbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGRvbuKAmXQgaGVhciBhbnkgb2JqZWN0aW9ucyB0byBpdCBleHBsaWNpdGx5LiBPciBk aWQgSSBtaXNpbnRlcnByZXQgdGhlIHJlc3BvbnNlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkZvciBUQ1AgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFRDUC9SRkM0 NTcxL0RUTFMvU0NUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBVRFAgSUNF IGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFVEUC9EVExTL1NDVFA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5CUjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJhanU8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0 aUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAy MiwgMjAxNSA0OjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJh anUpPGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBIb2xtYmVyZzsgU2Nod2FyeiwgQWxicmVjaHQg KEFsYnJlY2h0KTsgU3VoYXMgTmFuZGFrdW1hcjsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gSXQncyAmcXVvdDtVRFAvRFRMUy9TQ1RQJnF1b3Q7 IGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHByb3RvY29sIGlzIHRo ZSBzYW1lLiBXZSBhcmUganVzdCBkZWNpZGluZyB3aGF0IHRoZSBpZGVudGlmeWluZyBzdHJpbmcg c2hvdWxkIGJlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkdpdmVuIHRoZSBhbW91bnQgb2YgY29uZnVzaW9uIGluIHRoaXMgc3BhY2UsIEkgdGhpbmsg aXQgbWFrZXMgc2Vuc2UgdG8gYmUgYXMgZXhwbGljaXQgYXMgcG9zc2libGUsIGFuZCB1c2UgRFRM UyBpbnN0ZWFkIG9mIFRMUyBmb3IgdGhlIG5hbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEphbiAyMiwgMjAxNSBhdCA0 OjAxIEFNLCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpICZsdDs8YSBocmVmPSJtYWlsdG86 UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5SYWp1Lk1h a2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Gcm9tIHByb3RvY29sIHN0YWNrcyBsYXllcmluZyBwb2lu dCBvZiB2aWV3LCBpc27igJl0IHRoZSBmb2xsb3dpbmcgbW9yZSBhY2N1cmF0ZWx5IHJlcHJlc2Vu dCB0aGVtPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBUQ1AgSUNFIGJhc2Vk IGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFRDUC9SRkM0NTcxL0RUTFMvU0NUUDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZvciBVRFAgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFu c3BvcnQ6IFVEUC9EVExTL1NDVFA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZXIgbXkgdW5kZXJzdGFuZGluZywg aW5kZXBlbmRlbnQgb2YgdW5kZXJseWluZyB0cmFuc3BvcnQgKFVEUDsgb3Ig4oCcVENQIG92ZXIg UkZDNDQ3MeKAnSBmcmFtaW5nIG1pbWlja2luZw0KIGRhdGFncmFtIHRyYW5zcG9ydCkgdGhlIERU TFMgcHJvdG9jb2wgaXMgc2FtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJhanU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_E1FE4C082A89A246A11D7F32A95A17828E6A88E6US70UWXCHMBA02z_-- From nobody Tue Jan 27 04:18: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 3BF4B1A8777 for ; Tue, 27 Jan 2015 04:18:45 -0800 (PST) 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 VU5cp5vEa7dJ for ; Tue, 27 Jan 2015 04:18:40 -0800 (PST) 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 708841A878A for ; Tue, 27 Jan 2015 04:18:36 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-bd-54c7821a8c9e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 33.5C.04484.A1287C45; Tue, 27 Jan 2015 13:18:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 13:18:33 +0100 From: Christer Holmberg To: "Makaraju, Maridi Raju (Raju)" , "Justin Uberti" Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQN9qg+Bmi2KgHIkOVp/5Q+Zh+4ZzT5p7g Date: Tue, 27 Jan 2015 12:18:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@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.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D681465ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM+Jvja5U0/EQg88/ZCz+tP5itNg6Vcii YeMVVou1/9rZLXbO7WB2YPVofbaX1WPnrLvsHgs2lXosWfKTKYAlissmJTUnsyy1SN8ugSvj 6NNPTAUtVxkrzn1dxdbAuOU8YxcjJ4eEgInEpnd7WCFsMYkL99azgdhCAkcYJb516nYxcgHZ ixklVn17xt7FyMHBJmAh0f1PG6RGRCBXYl7fSjaQGmaBmYwSH9+9YgZJCAsESuxZsZENoihI ovHpLCYI20jiZ9MCFhCbRUBV4ujMBkaQmbwCvhJ/rllD7Gphl7jVPANsDqdArMSpR8vBjmME Ou77qTVgc5gFxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7GCzJQQUJKYtjUNojxf4sG9R+wgNq+A oMTJmU9YJjCKzkIyaRaSsllIymYBTWIW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhF i1OLk3LTjYz0Uosyk4uL8/P08lJLNjECo/Pglt8GOxhfPnc8xCjAwajEw2vw/1iIEGtiWXFl 7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY5xpUxr+6Y3Kx/tyKL//b A7NPO3xa8v7AjPon9rvnrmzZxyptye7a43BQfZqD4+aK1/8/hMyWWNWyMHpy9edp5+I+nxfh XH/zxOMzS3fpuG8oL3ao3i5zvWdSx9pJ6tc09c9fOCnh57X56m+DKoPIeDaBauOHa3RTpHRs u7kK5rb/WbLmgazaKyWW4oxEQy3mouJEAIEv59uvAgAA Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2015 12:18:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D681465ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlbGF0ZWQgdG8gdGhpcywgd2hlbiBJIHJlYWQgdGhlIGRhdGEgY2hhbm5lbCBkcmFm dCwgaXQgZXhwbGljaXRseSB0YWxrcyBhYm91dCBVRFAuIFRDUCBpcyBub3QgZXZlbiBtZW50aW9u ZWQuDQoNClNvLCBkb2VzIHRoYXQgbWVhbiB0aGF0IFRDUC9EVExTL1NDVFAgaXMgbm90IOKAnG9m ZmljaWFsbHnigJ0gYSBwYXJ0IG9mIHRoZSBkYXRhIGNoYW5uZWwgc3BlYz8NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KRnJvbTogTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KSBbbWFpbHRv OlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tXQ0KU2VudDogMjQuIHRhbW1pa3V1dGEg MjAxNSAxNTozNQ0KVG86IENocmlzdGVyIEhvbG1iZXJnOyBKdXN0aW4gVWJlcnRpDQpDYzogU2No d2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgU3VoYXMgTmFuZGFrdW1hcjsgPHJ0Y3dlYkBpZXRm Lm9yZz4NClN1YmplY3Q6IFJFOiBbcnRjd2ViXSBJdCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhl IGRhdGEgY2hhbm5lbCBtLWxpbmVzLCByaWdodD8NCg0KSSBhbSBvayB0byB1c2UgVURQL0RUTFMv U0NUUCBhbmQgVENQL0RUTFMvU0NUUC4NCkkgYWdyZWUgdGhhdCB1c2Ugb2YgUkZDICNzIGlzIG5v dCB0aGUgYmVzdCBvcHRpb24uDQpIb3dldmVyLCBJIGZpbmQgc29tZSB1bmVhc2UgaW4gdGhlIGRp c2N1c3Npb25zIGFib3V0IOKAnFRDUC9EVExT4oCdIHBhcnQsIHdoaWNoIHNlZW1zIHRvIHN1Z2dl c3Qgd2h5IG5vdCB1c2Ug4oCcVENQL1RMU+KAnT8gIFdlIHVuZGVyc3RhbmQgdGhhdCBpdCBjYW7i gJl0IGJlIGNhbGxlZCB0aGF0IHdheSBiZWNhdXNlIG9mIHRoZSBSRkMgNDU3MSDigJxzaGltIGxh eWVy4oCdIGluIGJldHdlZW4gRFRMUyBhbmQgVENQIGxheWVycy4gVW5mb3J0dW5hdGVseSwgdW5s aWtlIFRQS1QsIFJGQyA0NTcxIGRpZCBub3QgZ2l2ZSBhIG5hbWUgdG8gdGhlIHByb3RvY29sLCB3 aGljaCB3b3VsZCBoYXZlIGJlZW4gZWFzeSB0byB1c2UgdGhhbiB0aGUgUkZDIGRpcmVjdGx5Lg0K DQpCUg0KUmFqdQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb21dDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMToyMiBB TQ0KVG86IEp1c3RpbiBVYmVydGk7IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkNCkNjOiBT Y2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1bWFyOyA8cnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtydGN3ZWJdIEl0 J3MgIlVEUC9EVExTL1NDVFAiIGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0K DQpIaSwNCg0KSSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBub3QgdXNlIFJGQyBudW1iZXJzIGluIHBy b3RvIHZhbHVlcy4NCg0KQWxzbyBrZWVwIGluIG1pbmQgdGhhdCBVRFAvRFRMUy9TQ1RQIGRvZXMg bm90IG1lYW4g4oCcSUNFIGJhc2Vk4oCdLiBJQ0UgaXMgb3B0aW9uYWwgZm9yIFVEUC9EVExTL1ND VFAgKHRoYXQgZmFjdCB0aGF0IHdlIG1hbmRhdGUgSUNFIGZvciBSVENXRUIgaXMgYSBzZXBhcmF0 ZSBpc3N1ZSkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkg W21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiAyMy4gdGFtbWlrdXV0YSAyMDE1IDU6 NTcNClRvOiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpDQpDYzogQ2hyaXN0ZXIgSG9sbWJl cmc7IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFN1aGFzIE5hbmRha3VtYXI7IDxydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gSXQncyAiVURQL0RUTFMvU0NUUCIgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmln aHQ/DQoNCk5vLCBJIGRvbid0IHRoaW5rIGluY2x1ZGluZyBSRkM0NTcxIGlzIHJlYXNvbmFibGUu IFRoYXQgc2hpcCBoYXMgYWxyZWFkeSBzYWlsZWQuDQoNCk9uIFRodSwgSmFuIDIyLCAyMDE1IGF0 IDM6MzUgUE0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgPFJhanUuTWFrYXJhanVAYWxj YXRlbC1sdWNlbnQuY29tPG1haWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbT4+ IHdyb3RlOg0KSSB3YXMgYWxzbyBzdWdnZXN0aW5nIHRoZSBmb2xsb3dpbmcgaWRlbnRpZnlpbmcg c3RyaW5nIHRvIG1ha2UgaXQgdW5hbWJpZ3VvdXMgdXAgdG8gTDQgcHJvdG9jb2wuDQpJIGRvbuKA mXQgaGVhciBhbnkgb2JqZWN0aW9ucyB0byBpdCBleHBsaWNpdGx5LiBPciBkaWQgSSBtaXNpbnRl cnByZXQgdGhlIHJlc3BvbnNlPw0KRm9yIFRDUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5z cG9ydDogVENQL1JGQzQ1NzEvRFRMUy9TQ1RQDQpGb3IgVURQIElDRSBiYXNlZCBkYXRhIGNoYW5u ZWwgdHJhbnNwb3J0OiBVRFAvRFRMUy9TQ1RQDQoNCkJSDQpSYWp1DQoNCkZyb206IEp1c3RpbiBV YmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNv bT5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSA0OjQ1IFBNDQpUbzogTWFrYXJh anUsIE1hcmlkaSBSYWp1IChSYWp1KQ0KQ2M6IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBB bGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1bWFyOyA8cnRjd2ViQGlldGYub3JnPG1h aWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEl0J3MgIlVEUC9E VExTL1NDVFAiIGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pw0KDQpUaGUgcHJv dG9jb2wgaXMgdGhlIHNhbWUuIFdlIGFyZSBqdXN0IGRlY2lkaW5nIHdoYXQgdGhlIGlkZW50aWZ5 aW5nIHN0cmluZyBzaG91bGQgYmUuDQoNCkdpdmVuIHRoZSBhbW91bnQgb2YgY29uZnVzaW9uIGlu IHRoaXMgc3BhY2UsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gYmUgYXMgZXhwbGljaXQgYXMg cG9zc2libGUsIGFuZCB1c2UgRFRMUyBpbnN0ZWFkIG9mIFRMUyBmb3IgdGhlIG5hbWUuDQoNCk9u IFRodSwgSmFuIDIyLCAyMDE1IGF0IDQ6MDEgQU0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFq dSkgPFJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpSYWp1Lk1ha2FyYWp1 QGFsY2F0ZWwtbHVjZW50LmNvbT4+IHdyb3RlOg0KRnJvbSBwcm90b2NvbCBzdGFja3MgbGF5ZXJp bmcgcG9pbnQgb2YgdmlldywgaXNu4oCZdCB0aGUgZm9sbG93aW5nIG1vcmUgYWNjdXJhdGVseSBy ZXByZXNlbnQgdGhlbT8NCkZvciBUQ1AgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6 IFRDUC9SRkM0NTcxL0RUTFMvU0NUUA0KRm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRy YW5zcG9ydDogVURQL0RUTFMvU0NUUA0KDQpQZXIgbXkgdW5kZXJzdGFuZGluZywgaW5kZXBlbmRl bnQgb2YgdW5kZXJseWluZyB0cmFuc3BvcnQgKFVEUDsgb3Ig4oCcVENQIG92ZXIgUkZDNDQ3MeKA nSBmcmFtaW5nIG1pbWlja2luZyBkYXRhZ3JhbSB0cmFuc3BvcnQpIHRoZSBEVExTIHByb3RvY29s IGlzIHNhbWUuDQoNCkJSDQpSYWp1DQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D681465ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlbGF0ZWQgdG8gdGhp cywgd2hlbiBJIHJlYWQgdGhlIGRhdGEgY2hhbm5lbCBkcmFmdCwgaXQgZXhwbGljaXRseSB0YWxr cyBhYm91dCBVRFAuIFRDUCBpcyBub3QgZXZlbiBtZW50aW9uZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbywgZG9l cyB0aGF0IG1lYW4gdGhhdCBUQ1AvRFRMUy9TQ1RQIGlzIG5vdCDigJxvZmZpY2lhbGx54oCdIGEg cGFydCBvZiB0aGUgZGF0YSBjaGFubmVsIHNwZWM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJh anUpIFttYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMjQuIHRhbW1pa3V1dGEgMjAxNSAxNTozNTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0 ZXIgSG9sbWJlcmc7IEp1c3RpbiBVYmVydGk8YnI+DQo8Yj5DYzo8L2I+IFNjaHdhcnosIEFsYnJl Y2h0IChBbGJyZWNodCk7IFN1aGFzIE5hbmRha3VtYXI7ICZsdDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcnRjd2ViXSBJdCdzICZxdW90O1VEUC9EVExTL1ND VFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gb2sgdG8gdXNlIFVEUC9EVExTL1NDVFAgYW5kIFRD UC9EVExTL1NDVFAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCB1 c2Ugb2YgUkZDICNzIGlzIG5vdCB0aGUgYmVzdCBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkhvd2V2ZXIsIEkgZmluZCBzb21lIHVuZWFzZSBpbiB0aGUgZGlzY3Vzc2lvbnMg YWJvdXQg4oCcVENQL0RUTFPigJ0gcGFydCwgd2hpY2ggc2VlbXMgdG8gc3VnZ2VzdCB3aHkgbm90 IHVzZSDigJxUQ1AvVExT4oCdPyAmbmJzcDtXZSB1bmRlcnN0YW5kIHRoYXQgaXQgY2Fu4oCZdCBi ZSBjYWxsZWQgdGhhdA0KIHdheSBiZWNhdXNlIG9mIHRoZSBSRkMgNDU3MSDigJxzaGltIGxheWVy 4oCdIGluIGJldHdlZW4gRFRMUyBhbmQgVENQIGxheWVycy4gVW5mb3J0dW5hdGVseSwgdW5saWtl IFRQS1QsIFJGQyA0NTcxIGRpZCBub3QgZ2l2ZSBhIG5hbWUgdG8gdGhlIHByb3RvY29sLCB3aGlj aCB3b3VsZCBoYXZlIGJlZW4gZWFzeSB0byB1c2UgdGhhbiB0aGUgUkZDIGRpcmVjdGx5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QlI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqdTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENocmlz dGVyIEhvbG1iZXJnIFs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIj5tYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMToyMiBBTTxicj4NCjxiPlRvOjwv Yj4gSnVzdGluIFViZXJ0aTsgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KTxicj4NCjxiPkNj OjwvYj4gU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgU3VoYXMgTmFuZGFrdW1hcjsgJmx0 OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcnRjd2ViXSBJdCdzICZxdW90O1VEUC9EVExTL1ND VFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHdlIHNob3Vs ZCBub3QgdXNlIFJGQyBudW1iZXJzIGluIHByb3RvIHZhbHVlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFsc28ga2Vl cCBpbiBtaW5kIHRoYXQgVURQL0RUTFMvU0NUUCBkb2VzIG5vdCBtZWFuIOKAnElDRSBiYXNlZOKA nS4gSUNFIGlzIG9wdGlvbmFsIGZvciBVRFAvRFRMUy9TQ1RQICh0aGF0IGZhY3QgdGhhdCB3ZSBt YW5kYXRlIElDRSBmb3IgUlRDV0VCIGlzIGEgc2VwYXJhdGUgaXNzdWUpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBKdXN0aW4gVWJlcnRpIFs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUu Y29tIj5tYWlsdG86anViZXJ0aUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAy My4gdGFtbWlrdXV0YSAyMDE1IDU6NTc8YnI+DQo8Yj5Ubzo8L2I+IE1ha2FyYWp1LCBNYXJpZGkg UmFqdSAoUmFqdSk8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBB bGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1bWFyOyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtydGN3ZWJdIEl0J3MgJnF1b3Q7VURQL0RUTFMvU0NUUCZxdW90OyBmb3IgdGhl IGRhdGEgY2hhbm5lbCBtLWxpbmVzLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ObywgSSBkb24ndCB0aGluayBpbmNsdWRpbmcgUkZDNDU3MSBpcyByZWFzb25h YmxlLiBUaGF0IHNoaXAgaGFzIGFscmVhZHkgc2FpbGVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDIyLCAyMDE1IGF0IDM6MzUgUE0sIE1ha2FyYWp1 LCBNYXJpZGkgUmFqdSAoUmFqdSkgJmx0OzxhIGhyZWY9Im1haWx0bzpSYWp1Lk1ha2FyYWp1QGFs Y2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlJhanUuTWFrYXJhanVAYWxjYXRlbC1s dWNlbnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkkgd2FzIGFsc28gc3VnZ2VzdGluZyB0aGUgZm9sbG93aW5nIGlkZW50aWZ5aW5nIHN0 cmluZyB0byBtYWtlIGl0IHVuYW1iaWd1b3VzIHVwIHRvIEw0IHByb3RvY29sLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGl0 IGV4cGxpY2l0bHkuIE9yIGRpZCBJIG1pc2ludGVycHJldCB0aGUgcmVzcG9uc2U/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIFRDUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRy YW5zcG9ydDogVENQL1JGQzQ1NzEvRFRMUy9TQ1RQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Rm9yIFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMv U0NUUDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFq dTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGlu IFViZXJ0aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBKYW51YXJ5IDIyLCAyMDE1IDQ6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IE1ha2FyYWp1 LCBNYXJpZGkgUmFqdSAoUmFqdSk8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBT Y2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1bWFyOyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBJdCdzICZxdW90O1VE UC9EVExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGUgcHJvdG9jb2wgaXMgdGhlIHNhbWUuIFdlIGFyZSBqdXN0IGRlY2lkaW5nIHdoYXQgdGhlIGlk ZW50aWZ5aW5nIHN0cmluZyBzaG91bGQgYmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+R2l2ZW4gdGhlIGFtb3VudCBvZiBjb25mdXNpb24gaW4gdGhp cyBzcGFjZSwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBiZSBhcyBleHBsaWNpdCBhcyBwb3Nz aWJsZSwgYW5kIHVzZSBEVExTIGluc3RlYWQgb2YgVExTIGZvciB0aGUgbmFtZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwg SmFuIDIyLCAyMDE1IGF0IDQ6MDEgQU0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgJmx0 OzxhIGhyZWY9Im1haWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZyb20gcHJvdG9jb2wgc3Rh Y2tzIGxheWVyaW5nIHBvaW50IG9mIHZpZXcsIGlzbuKAmXQgdGhlIGZvbGxvd2luZyBtb3JlIGFj Y3VyYXRlbHkgcmVwcmVzZW50IHRoZW0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Rm9yIFRDUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVENQL1JGQzQ1NzEvRFRM Uy9TQ1RQPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIFVEUCBJQ0UgYmFzZWQg ZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMvU0NUUDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBlciBt eSB1bmRlcnN0YW5kaW5nLCBpbmRlcGVuZGVudCBvZiB1bmRlcmx5aW5nIHRyYW5zcG9ydCAoVURQ OyBvciDigJxUQ1Agb3ZlciBSRkM0NDcx4oCdIGZyYW1pbmcgbWltaWNraW5nDQogZGF0YWdyYW0g dHJhbnNwb3J0KSB0aGUgRFRMUyBwcm90b2NvbCBpcyBzYW1lLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqdTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D681465ESESSMB209erics_-- From nobody Tue Jan 27 08:42: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 0B2AC1A1BE6 for ; Tue, 27 Jan 2015 08:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glfE4u9vA-OB for ; Tue, 27 Jan 2015 08:42:09 -0800 (PST) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4781A8892 for ; Tue, 27 Jan 2015 08:39:17 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so15940177wes.10 for ; Tue, 27 Jan 2015 08:39:16 -0800 (PST) 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=EoGhdNWCtNh3jToh38xufNSF+/a0YefQCKRW+egqBAw=; b=DYYsoGo6iejAXm7+o++wLlqICfi23vunF31kk++oIkO4zKYH42i42qSy5RPa6z9nOp Nj3pIifhel3K2kuu1MKhdVVWepCvw0aIJlDYLWy6MJKp/G4+DKOfnS+KHF3PzSD3nn10 cN/R7DyLf11nLLBvJ5Ss4T63bfJBno0icRqx5e4K74pbPfwokGzraVcaE51LJAys+SJM WMj5gN/uc3ffKX2ky4pJzy14yLyPO1dVs8LMIQtVg2FqCF84JTNGrJKdNWmEkFsgjt9m 5rHpLMfHL/rSgsV32VomXvlXsuJByYw6yfQSg1A1Sv0NuVd5pUFsKkaenygY1KTnp2N2 zVJQ== X-Gm-Message-State: ALoCoQkBAxRsfWvdWSwg42/W/13IrKoEBKGe59fBZO4y+tQFxuT8VOdu0J5D2mJsILsiOeqUaIy3 X-Received: by 10.180.108.165 with SMTP id hl5mr38664372wib.39.1422376756161; Tue, 27 Jan 2015 08:39:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.142.215 with HTTP; Tue, 27 Jan 2015 08:38:35 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Tue, 27 Jan 2015 08:38:35 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8f3ba10149d33f050da4e502 Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2015 16:42:13 -0000 --e89a8f3ba10149d33f050da4e502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, if you are doing ICE-TCP, I would expect you to run DataChannels over that. ISTM that that suggests that the marker should be TCP/DTLS/SCTP. -Ekr On Tue, Jan 27, 2015 at 4:18 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Related to this, when I read the data channel draft, it explicitly talks > about UDP. TCP is not even mentioned. > > > > So, does that mean that TCP/DTLS/SCTP is not =E2=80=9Cofficially=E2=80=9D= a part of the > data channel spec? > > > > Regards, > > > > Christer > > > > *From:* Makaraju, Maridi Raju (Raju) [mailto: > Raju.Makaraju@alcatel-lucent.com] > *Sent:* 24. tammikuuta 2015 15:35 > *To:* Christer Holmberg; Justin Uberti > *Cc:* Schwarz, Albrecht (Albrecht); Suhas Nandakumar; > *Subject:* RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > I am ok to use UDP/DTLS/SCTP and TCP/DTLS/SCTP. > > I agree that use of RFC #s is not the best option. > > However, I find some unease in the discussions about =E2=80=9CTCP/DTLS=E2= =80=9D part, > which seems to suggest why not use =E2=80=9CTCP/TLS=E2=80=9D? We underst= and that it can=E2=80=99t > be called that way because of the RFC 4571 =E2=80=9Cshim layer=E2=80=9D i= n between DTLS and > TCP layers. Unfortunately, unlike TPKT, RFC 4571 did not give a name to t= he > protocol, which would have been easy to use than the RFC directly. > > > > BR > > Raju > > *From:* Christer Holmberg [mailto:christer.holmberg@ericsson.com > ] > *Sent:* Friday, January 23, 2015 1:22 AM > *To:* Justin Uberti; Makaraju, Maridi Raju (Raju) > *Cc:* Schwarz, Albrecht (Albrecht); Suhas Nandakumar; > *Subject:* RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > Hi, > > > > I agree that we should not use RFC numbers in proto values. > > > > Also keep in mind that UDP/DTLS/SCTP does not mean =E2=80=9CICE based=E2= =80=9D. ICE is > optional for UDP/DTLS/SCTP (that fact that we mandate ICE for RTCWEB is a > separate issue). > > > > Regards, > > > > Christer > > > > *From:* Justin Uberti [mailto:juberti@google.com ] > *Sent:* 23. tammikuuta 2015 5:57 > *To:* Makaraju, Maridi Raju (Raju) > *Cc:* Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = < > rtcweb@ietf.org> > *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > No, I don't think including RFC4571 is reasonable. That ship has already > sailed. > > > > On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > > I was also suggesting the following identifying string to make it > unambiguous up to L4 protocol. > > I don=E2=80=99t hear any objections to it explicitly. Or did I misinterpr= et the > response? > > For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP > > For UDP ICE based data channel transport: UDP/DTLS/SCTP > > > > BR > > Raju > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Thursday, January 22, 2015 4:45 PM > *To:* Makaraju, Maridi Raju (Raju) > *Cc:* Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = < > rtcweb@ietf.org> > *Subject:* Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel > m-lines, right? > > > > The protocol is the same. We are just deciding what the identifying strin= g > should be. > > > > Given the amount of confusion in this space, I think it makes sense to be > as explicit as possible, and use DTLS instead of TLS for the name. > > > > On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > > From protocol stacks layering point of view, isn=E2=80=99t the following = more > accurately represent them? > > For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP > > For UDP ICE based data channel transport: UDP/DTLS/SCTP > > > > Per my understanding, independent of underlying transport (UDP; or =E2=80= =9CTCP > over RFC4471=E2=80=9D framing mimicking datagram transport) the DTLS prot= ocol is > same. > > > > BR > > Raju > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --e89a8f3ba10149d33f050da4e502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, if you are doing ICE-TCP, I would expect you to run = DataChannels over
that. ISTM that that suggests that the marker should = be TCP/DTLS/SCTP.

-Ekr

<= div class=3D"gmail_extra">
On Tue, Jan 27, 20= 15 at 4:18 AM, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

Hi,<= /p>

=C2=A0

Related to this, when I r= ead the data channel draft, it explicitly talks about UDP. TCP is not even = mentioned.

=C2=A0

So, does that mean that T= CP/DTLS/SCTP is not =E2=80=9Cofficially=E2=80=9D a part of the data channel= spec?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: Makaraju= , Maridi Raju (Raju) [mailto:Raju.Makaraju@alcatel-lucent.com]
Sent: 24. tammikuuta 2015 15:35
To: Christer Holmberg; Justin Uberti

Cc: Schwarz, Albrecht (Albr= echt); Suhas Nandakumar; <rtcweb@ietf.org>
Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

I am ok to use UDP/DTLS/S= CTP and TCP/DTLS/SCTP.

I agree that use of RFC #= s is not the best option.

However, I find some unea= se in the discussions about =E2=80=9CTCP/DTLS=E2=80=9D part, which seems to= suggest why not use =E2=80=9CTCP/TLS=E2=80=9D?=C2=A0 We understand that it= can=E2=80=99t be called that way because of the RFC 4571 =E2=80=9Cshim layer=E2=80=9D in between DTLS a= nd TCP layers. Unfortunately, unlike TPKT, RFC 4571 did not give a name to = the protocol, which would have been easy to use than the RFC directly.

=C2=A0

BR

Raju=

From: Christer= Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Friday, January 23, 2015 1:22 AM
To: Justin Uberti; Makaraju, Maridi Raju (Raju)
Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; <rtcweb@ietf.org>
Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

Hi,<= /p>

=C2=A0

I agree that we should no= t use RFC numbers in proto values.

=C2=A0

Also keep in mind that UD= P/DTLS/SCTP does not mean =E2=80=9CICE based=E2=80=9D. ICE is optional for = UDP/DTLS/SCTP (that fact that we mandate ICE for RTCWEB is a separate issue= ).

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: 23. tammikuuta 2015 5:57
To: Makaraju, Maridi Raju (Raju)
Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakuma= r; <rtcweb@ietf.org= >
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

No, I don't think including RFC4571 is reasonabl= e. That ship has already sailed.

=C2=A0

On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Ra= ju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

I was also suggesting the= following identifying string to make it unambiguous up to L4 protocol.

I don=E2=80=99t hear any = objections to it explicitly. Or did I misinterpret the response?<= /u>

For TCP ICE based data ch= annel transport: TCP/RFC4571/DTLS/SCTP

For UDP ICE based data ch= annel transport: UDP/DTLS/SCTP

=C2=A0

BR

Raju=

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Thursday, January 22, 2015 4:45 PM
To: Makaraju, Maridi Raju (Raju)
Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakuma= r; <rtcweb@ietf.org= >
Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the dat= a channel m-lines, right?

=C2=A0

The protocol is the same. We are just deciding what = the identifying string should be.

=C2=A0

Given the amount of confusion in this space, I think= it makes sense to be as explicit as possible, and use DTLS instead of TLS = for the name.

=C2=A0

On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Ra= ju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:

From protocol stacks laye= ring point of view, isn=E2=80=99t the following more accurately represent t= hem?

For TCP ICE based data ch= annel transport: TCP/RFC4571/DTLS/SCTP

For UDP ICE based data ch= annel transport: UDP/DTLS/SCTP

=C2=A0

Per my understanding, ind= ependent of underlying transport (UDP; or =E2=80=9CTCP over RFC4471=E2=80= =9D framing mimicking datagram transport) the DTLS protocol is same.

=C2=A0

BR

Raju=

=C2=A0

=C2=A0


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


--e89a8f3ba10149d33f050da4e502-- From nobody Tue Jan 27 09:44: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 327EB1A8894 for ; Tue, 27 Jan 2015 09:44:40 -0800 (PST) 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 Ojz9aNXi-zZM for ; Tue, 27 Jan 2015 09:44:37 -0800 (PST) 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 80C561A19FE for ; Tue, 27 Jan 2015 09:44:35 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-14-54c7ce824d94 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.DA.24955.28EC7C45; Tue, 27 Jan 2015 18:44:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 18:44:33 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? Thread-Index: AQHQN9qg+Bmi2KgHIkOVp/5Q+Zh+4ZzT5p7ggAA4TICAACMHQA== Date: Tue, 27 Jan 2015 17:44:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D682175ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+JvjW7TueMhBqs/CVqseH2O3WLrVCGL ho1XWC3W/mtnd2DxaH22l9VjwaZSjyVLfjJ5TH7cxhzAEsVlk5Kak1mWWqRvl8CV0Tr5CnPB vIVMFa+f3WJqYLwyk6mLkZNDQsBE4u+bfihbTOLCvfVsXYxcHEICRxglHvc9hHIWM0rMWT6D tYuRg4NNwEKi+582SIOIgILErz8nWEBqmAWmMEr0zP7DApIQFgiU2LNiIxtEUZBE49NZTBC2 k8S3U2fA4iwCqhJXZp4Cs3kFfCVu/ljLArGsn0Ni24avjCAJTqBBO1smgg1lBDrv+6k1YIOY BcQlbj2ZD3W2gMSSPeeZIWxRiZeP/7FC2EoSaw9vZ4Goz5dYd+w9K8QyQYmTM5+wTGAUnYVk 1CwkZbOQlM0C+plZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLWSy3K TC4uzs/Ty0st2cQIjMyDW36r7mC8/MbxEKMAB6MSD6/h/2MhQqyJZcWVuYcYpTlYlMR57YwP hQgJpCeWpGanphakFsUXleakFh9iZOLglGpgdNwt07ZMoXVvGVd2E+Ov2Hon5sn86htl2HTW dlstWCwjE8fr2fPEiiOH22tJDfNjFgZfVvvjhg4C+duf73xu8FYjd436izN7f0z6wVFgraH+ QMPRKWvOj+//zhddFo9dfX/hXvUppxskhN232G/lbAqyTLCbsF+Yg7+wpWLf/z6NNI1qRUsl luKMREMt5qLiRAARN17arQIAAA== Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2015 17:44:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D682175ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5XZWxsLCBpZiB5b3UgYXJlIGRvaW5nIElDRS1UQ1AsIEkgd291bGQgZXhwZWN0IHlv dSB0byBydW4gPkRhdGFDaGFubmVscyBvdmVyIHRoYXQuIElTVE0gdGhhdCB0aGF0IHN1Z2dlc3Rz IHRoYXQgdGhlIG1hcmtlciA+c2hvdWxkIGJlIFRDUC9EVExTL1NDVFAuDQoNCkkgYW0gbm90IGFy Z3VpbmcgYWdhaW5zdCB0aGF0LiBJIGp1c3Qgd29uZGVyIHdoeSB0aGUgZGF0YSBjaGFubmVsIGRy YWZ0IGRvZXNu4oCZdCBzYXkgYW55dGhpbmcgYWJvdXQgVENQLCB3aGlsZSBleHBsaWNpdGx5IHRh bGtpbmcgYWJvdXQgVURQLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KT24gVHVlLCBK YW4gMjcsIDIwMTUgYXQgNDoxOCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4g d3JvdGU6DQpIaSwNCg0KUmVsYXRlZCB0byB0aGlzLCB3aGVuIEkgcmVhZCB0aGUgZGF0YSBjaGFu bmVsIGRyYWZ0LCBpdCBleHBsaWNpdGx5IHRhbGtzIGFib3V0IFVEUC4gVENQIGlzIG5vdCBldmVu IG1lbnRpb25lZC4NCg0KU28sIGRvZXMgdGhhdCBtZWFuIHRoYXQgVENQL0RUTFMvU0NUUCBpcyBu b3Qg4oCcb2ZmaWNpYWxseeKAnSBhIHBhcnQgb2YgdGhlIGRhdGEgY2hhbm5lbCBzcGVjPw0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUp IFttYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOlJhanUuTWFr YXJhanVAYWxjYXRlbC1sdWNlbnQuY29tPl0NClNlbnQ6IDI0LiB0YW1taWt1dXRhIDIwMTUgMTU6 MzUNClRvOiBDaHJpc3RlciBIb2xtYmVyZzsgSnVzdGluIFViZXJ0aQ0KQ2M6IFNjaHdhcnosIEFs YnJlY2h0IChBbGJyZWNodCk7IFN1aGFzIE5hbmRha3VtYXI7IDxydGN3ZWJAaWV0Zi5vcmc8bWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3J0Y3dlYl0gSXQncyAiVURQL0RU TFMvU0NUUCIgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/DQoNCkkgYW0gb2sg dG8gdXNlIFVEUC9EVExTL1NDVFAgYW5kIFRDUC9EVExTL1NDVFAuDQpJIGFncmVlIHRoYXQgdXNl IG9mIFJGQyAjcyBpcyBub3QgdGhlIGJlc3Qgb3B0aW9uLg0KSG93ZXZlciwgSSBmaW5kIHNvbWUg dW5lYXNlIGluIHRoZSBkaXNjdXNzaW9ucyBhYm91dCDigJxUQ1AvRFRMU+KAnSBwYXJ0LCB3aGlj aCBzZWVtcyB0byBzdWdnZXN0IHdoeSBub3QgdXNlIOKAnFRDUC9UTFPigJ0/ICBXZSB1bmRlcnN0 YW5kIHRoYXQgaXQgY2Fu4oCZdCBiZSBjYWxsZWQgdGhhdCB3YXkgYmVjYXVzZSBvZiB0aGUgUkZD IDQ1NzEg4oCcc2hpbSBsYXllcuKAnSBpbiBiZXR3ZWVuIERUTFMgYW5kIFRDUCBsYXllcnMuIFVu Zm9ydHVuYXRlbHksIHVubGlrZSBUUEtULCBSRkMgNDU3MSBkaWQgbm90IGdpdmUgYSBuYW1lIHRv IHRoZSBwcm90b2NvbCwgd2hpY2ggd291bGQgaGF2ZSBiZWVuIGVhc3kgdG8gdXNlIHRoYW4gdGhl IFJGQyBkaXJlY3RseS4NCg0KQlINClJhanUNCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KU2VudDogRnJpZGF5LCBKYW51YXJ5 IDIzLCAyMDE1IDE6MjIgQU0NClRvOiBKdXN0aW4gVWJlcnRpOyBNYWthcmFqdSwgTWFyaWRpIFJh anUgKFJhanUpDQpDYzogU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgU3VoYXMgTmFuZGFr dW1hcjsgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6 IFJFOiBbcnRjd2ViXSBJdCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhlIGRhdGEgY2hhbm5lbCBt LWxpbmVzLCByaWdodD8NCg0KSGksDQoNCkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgbm90IHVzZSBS RkMgbnVtYmVycyBpbiBwcm90byB2YWx1ZXMuDQoNCkFsc28ga2VlcCBpbiBtaW5kIHRoYXQgVURQ L0RUTFMvU0NUUCBkb2VzIG5vdCBtZWFuIOKAnElDRSBiYXNlZOKAnS4gSUNFIGlzIG9wdGlvbmFs IGZvciBVRFAvRFRMUy9TQ1RQICh0aGF0IGZhY3QgdGhhdCB3ZSBtYW5kYXRlIElDRSBmb3IgUlRD V0VCIGlzIGEgc2VwYXJhdGUgaXNzdWUpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9t OiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tXQ0KU2VudDogMjMuIHRh bW1pa3V1dGEgMjAxNSA1OjU3DQpUbzogTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KQ0KQ2M6 IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBO YW5kYWt1bWFyOyA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtydGN3ZWJdIEl0J3MgIlVEUC9EVExTL1NDVFAiIGZvciB0aGUgZGF0YSBjaGFu bmVsIG0tbGluZXMsIHJpZ2h0Pw0KDQpObywgSSBkb24ndCB0aGluayBpbmNsdWRpbmcgUkZDNDU3 MSBpcyByZWFzb25hYmxlLiBUaGF0IHNoaXAgaGFzIGFscmVhZHkgc2FpbGVkLg0KDQpPbiBUaHUs IEphbiAyMiwgMjAxNSBhdCAzOjM1IFBNLCBNYWthcmFqdSwgTWFyaWRpIFJhanUgKFJhanUpIDxS YWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNh dGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCkkgd2FzIGFsc28gc3VnZ2VzdGluZyB0aGUgZm9sbG93 aW5nIGlkZW50aWZ5aW5nIHN0cmluZyB0byBtYWtlIGl0IHVuYW1iaWd1b3VzIHVwIHRvIEw0IHBy b3RvY29sLg0KSSBkb27igJl0IGhlYXIgYW55IG9iamVjdGlvbnMgdG8gaXQgZXhwbGljaXRseS4g T3IgZGlkIEkgbWlzaW50ZXJwcmV0IHRoZSByZXNwb25zZT8NCkZvciBUQ1AgSUNFIGJhc2VkIGRh dGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFRDUC9SRkM0NTcxL0RUTFMvU0NUUA0KRm9yIFVEUCBJQ0Ug YmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMvU0NUUA0KDQpCUg0KUmFqdQ0K DQpGcm9tOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpq dWJlcnRpQGdvb2dsZS5jb20+XQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjIsIDIwMTUgNDo0 NSBQTQ0KVG86IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkNCkNjOiBDaHJpc3RlciBIb2xt YmVyZzsgU2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgU3VoYXMgTmFuZGFrdW1hcjsgPHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBJdCdzICJVRFAvRFRMUy9TQ1RQIiBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxpbmVzLCBy aWdodD8NCg0KVGhlIHByb3RvY29sIGlzIHRoZSBzYW1lLiBXZSBhcmUganVzdCBkZWNpZGluZyB3 aGF0IHRoZSBpZGVudGlmeWluZyBzdHJpbmcgc2hvdWxkIGJlLg0KDQpHaXZlbiB0aGUgYW1vdW50 IG9mIGNvbmZ1c2lvbiBpbiB0aGlzIHNwYWNlLCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIGJl IGFzIGV4cGxpY2l0IGFzIHBvc3NpYmxlLCBhbmQgdXNlIERUTFMgaW5zdGVhZCBvZiBUTFMgZm9y IHRoZSBuYW1lLg0KDQpPbiBUaHUsIEphbiAyMiwgMjAxNSBhdCA0OjAxIEFNLCBNYWthcmFqdSwg TWFyaWRpIFJhanUgKFJhanUpIDxSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWls dG86UmFqdS5NYWthcmFqdUBhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCkZyb20gcHJvdG9j b2wgc3RhY2tzIGxheWVyaW5nIHBvaW50IG9mIHZpZXcsIGlzbuKAmXQgdGhlIGZvbGxvd2luZyBt b3JlIGFjY3VyYXRlbHkgcmVwcmVzZW50IHRoZW0/DQpGb3IgVENQIElDRSBiYXNlZCBkYXRhIGNo YW5uZWwgdHJhbnNwb3J0OiBUQ1AvUkZDNDU3MS9EVExTL1NDVFANCkZvciBVRFAgSUNFIGJhc2Vk IGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFVEUC9EVExTL1NDVFANCg0KUGVyIG15IHVuZGVyc3Rh bmRpbmcsIGluZGVwZW5kZW50IG9mIHVuZGVybHlpbmcgdHJhbnNwb3J0IChVRFA7IG9yIOKAnFRD UCBvdmVyIFJGQzQ0NzHigJ0gZnJhbWluZyBtaW1pY2tpbmcgZGF0YWdyYW0gdHJhbnNwb3J0KSB0 aGUgRFRMUyBwcm90b2NvbCBpcyBzYW1lLg0KDQpCUg0KUmFqdQ0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QN CnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D682175ESESSMB209erics_ 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 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZn dDs8L3NwYW4+V2VsbCwgaWYgeW91IGFyZSBkb2luZyBJQ0UtVENQLCBJIHdvdWxkIGV4cGVjdCB5 b3UgdG8gcnVuDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5EYXRhQ2hh bm5lbHMgb3ZlcjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj50aGF0LiBJU1RN IHRoYXQgdGhhdCBzdWdnZXN0cyB0aGF0IHRoZSBtYXJrZXIgPHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPg0KJmd0Ozwvc3Bhbj5zaG91bGQgYmUgVENQL0RUTFMvU0NUUC48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SSBhbSBub3QgYXJndWluZyBhZ2FpbnN0IHRoYXQuIEkganVzdCB3b25kZXIgd2h5IHRo ZSBkYXRhIGNoYW5uZWwgZHJhZnQgZG9lc27igJl0IHNheSBhbnl0aGluZyBhYm91dCBUQ1AsIHdo aWxlIGV4cGxpY2l0bHkgdGFsa2luZyBhYm91dCBVRFAuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKYW4gMjcsIDIwMTUgYXQg NDoxOCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWxhdGVkIHRvIHRoaXMsIHdo ZW4gSSByZWFkIHRoZSBkYXRhIGNoYW5uZWwgZHJhZnQsIGl0IGV4cGxpY2l0bHkgdGFsa3MgYWJv dXQgVURQLiBUQ1ANCiBpcyBub3QgZXZlbiBtZW50aW9uZWQuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28sIGRvZXMg dGhhdCBtZWFuIHRoYXQgVENQL0RUTFMvU0NUUCBpcyBub3Qg4oCcb2ZmaWNpYWxseeKAnSBhIHBh cnQgb2YgdGhlIGRhdGEgY2hhbm5lbCBzcGVjPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IE1ha2FyYWp1LA0KIE1hcmlkaSBSYWp1 IChSYWp1KSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpSYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVj ZW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlJhanUuTWFrYXJhanVAYWxjYXRlbC1sdWNlbnQuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNC4gdGFtbWlrdXV0YSAyMDE1IDE1OjM1PGJyPg0K PGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZzsgSnVzdGluIFViZXJ0aTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+Q2M6PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IFNjaHdhcnosIEFsYnJlY2h0IChBbGJyZWNodCk7IFN1aGFzIE5hbmRha3Vt YXI7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtydGN3ZWJd IEl0J3MgJnF1b3Q7VURQL0RUTFMvU0NUUCZxdW90OyBmb3IgdGhlIGRhdGEgY2hhbm5lbCBtLWxp bmVzLCByaWdodD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gb2sg dG8gdXNlIFVEUC9EVExTL1NDVFAgYW5kIFRDUC9EVExTL1NDVFAuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHVz ZSBvZiBSRkMgI3MgaXMgbm90IHRoZSBiZXN0IG9wdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBJIGZpbmQgc29t ZSB1bmVhc2UgaW4gdGhlIGRpc2N1c3Npb25zIGFib3V0IOKAnFRDUC9EVExT4oCdIHBhcnQsIHdo aWNoIHNlZW1zIHRvIHN1Z2dlc3QNCiB3aHkgbm90IHVzZSDigJxUQ1AvVExT4oCdPyZuYnNwOyBX ZSB1bmRlcnN0YW5kIHRoYXQgaXQgY2Fu4oCZdCBiZSBjYWxsZWQgdGhhdCB3YXkgYmVjYXVzZSBv ZiB0aGUgUkZDIDQ1NzEg4oCcc2hpbSBsYXllcuKAnSBpbiBiZXR3ZWVuIERUTFMgYW5kIFRDUCBs YXllcnMuIFVuZm9ydHVuYXRlbHksIHVubGlrZSBUUEtULCBSRkMgNDU3MSBkaWQgbm90IGdpdmUg YSBuYW1lIHRvIHRoZSBwcm90b2NvbCwgd2hpY2ggd291bGQgaGF2ZSBiZWVuIGVhc3kgdG8gdXNl IHRoYW4gdGhlDQogUkZDIGRpcmVjdGx5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJSPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmFqdTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IENocmlzdGVyDQogSG9sbWJlcmcgWzxhIGhyZWY9 Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5t YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEphbnVhcnkgMjMsIDIwMTUgMToyMiBBTTxicj4NCjxiPlRvOjwvYj4gSnVz dGluIFViZXJ0aTsgTWFrYXJhanUsIE1hcmlkaSBSYWp1IChSYWp1KTxicj4NCjxiPkNjOjwvYj4g U2Nod2FyeiwgQWxicmVjaHQgKEFsYnJlY2h0KTsgU3VoYXMgTmFuZGFrdW1hcjsgJmx0OzxhIGhy ZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3J0Y3dlYl0gSXQncyAmcXVvdDtV RFAvRFRMUy9TQ1RQJnF1b3Q7IGZvciB0aGUgZGF0YSBjaGFubmVsIG0tbGluZXMsIHJpZ2h0Pzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRo YXQgd2Ugc2hvdWxkIG5vdCB1c2UgUkZDIG51bWJlcnMgaW4gcHJvdG8gdmFsdWVzLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkFsc28ga2VlcCBpbiBtaW5kIHRoYXQgVURQL0RUTFMvU0NUUCBkb2VzIG5vdCBtZWFuIOKA nElDRSBiYXNlZOKAnS4gSUNFIGlzIG9wdGlvbmFsIGZvciBVRFAvRFRMUy9TQ1RQDQogKHRoYXQg ZmFjdCB0aGF0IHdlIG1hbmRhdGUgSUNFIGZvciBSVENXRUIgaXMgYSBzZXBhcmF0ZSBpc3N1ZSku PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBKdXN0aW4NCiBVYmVydGkgWzxhIGhyZWY9Im1h aWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86anViZXJ0aUBn b29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMy4gdGFtbWlrdXV0YSAyMDE1IDU6 NTc8YnI+DQo8Yj5Ubzo8L2I+IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk8YnI+DQo8Yj5D Yzo8L2I+IENocmlzdGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBT dWhhcyBOYW5kYWt1bWFyOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbcnRjd2ViXSBJdCdzICZxdW90O1VEUC9EVExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRh IGNoYW5uZWwgbS1saW5lcywgcmlnaHQ/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm8sIEkgZG9uJ3QgdGhpbmsgaW5jbHVkaW5nIFJGQzQ1 NzEgaXMgcmVhc29uYWJsZS4gVGhhdCBzaGlwIGhhcyBhbHJlYWR5IHNhaWxlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFRodSwgSmFuIDIyLCAyMDE1IGF0IDM6MzUg UE0sIE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSkgJmx0OzxhIGhyZWY9Im1haWx0bzpSYWp1 Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlJhanUuTWFrYXJh anVAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHdhcyBhbHNvIHN1Z2dlc3RpbmcgdGhlIGZv bGxvd2luZyBpZGVudGlmeWluZyBzdHJpbmcgdG8gbWFrZSBpdCB1bmFtYmlndW91cyB1cCB0byBM NA0KIHByb3RvY29sLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBoZWFyIGFueSBvYmplY3Rpb25zIHRvIGl0IGV4cGxp Y2l0bHkuIE9yIGRpZCBJIG1pc2ludGVycHJldCB0aGUgcmVzcG9uc2U/PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIFRDUCBJQ0Ug YmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVENQL1JGQzQ1NzEvRFRMUy9TQ1RQPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9y IFVEUCBJQ0UgYmFzZWQgZGF0YSBjaGFubmVsIHRyYW5zcG9ydDogVURQL0RUTFMvU0NUUDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkJSPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmFqdTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1z ZXJpZiI+IEp1c3Rpbg0KIFViZXJ0aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDIyLCAyMDE1IDQ6NDUgUE08YnI+DQo8Yj5U bzo8L2I+IE1ha2FyYWp1LCBNYXJpZGkgUmFqdSAoUmFqdSk8YnI+DQo8Yj5DYzo8L2I+IENocmlz dGVyIEhvbG1iZXJnOyBTY2h3YXJ6LCBBbGJyZWNodCAoQWxicmVjaHQpOyBTdWhhcyBOYW5kYWt1 bWFyOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2Vi XSBJdCdzICZxdW90O1VEUC9EVExTL1NDVFAmcXVvdDsgZm9yIHRoZSBkYXRhIGNoYW5uZWwgbS1s aW5lcywgcmlnaHQ/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBwcm90b2NvbCBpcyB0aGUgc2FtZS4gV2Ug YXJlIGp1c3QgZGVjaWRpbmcgd2hhdCB0aGUgaWRlbnRpZnlpbmcgc3RyaW5nIHNob3VsZCBiZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+R2l2ZW4gdGhlIGFt b3VudCBvZiBjb25mdXNpb24gaW4gdGhpcyBzcGFjZSwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0 byBiZSBhcyBleHBsaWNpdCBhcyBwb3NzaWJsZSwgYW5kIHVzZSBEVExTIGluc3RlYWQgb2YgVExT IGZvciB0aGUgbmFtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBUaHUsIEphbiAyMiwgMjAxNSBhdCA0OjAxIEFNLCBNYWthcmFqdSwgTWFy aWRpIFJhanUgKFJhanUpICZsdDs8YSBocmVmPSJtYWlsdG86UmFqdS5NYWthcmFqdUBhbGNhdGVs LWx1Y2VudC5jb20iIHRhcmdldD0iX2JsYW5rIj5SYWp1Lk1ha2FyYWp1QGFsY2F0ZWwtbHVjZW50 LmNvbTwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+RnJvbSBwcm90b2NvbCBzdGFja3MgbGF5ZXJpbmcgcG9pbnQgb2Ygdmlldywg aXNu4oCZdCB0aGUgZm9sbG93aW5nIG1vcmUgYWNjdXJhdGVseSByZXByZXNlbnQNCiB0aGVtPzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkZvciBUQ1AgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFRDUC9SRkM0NTcxL0RU TFMvU0NUUDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkZvciBVRFAgSUNFIGJhc2VkIGRhdGEgY2hhbm5lbCB0cmFuc3BvcnQ6IFVEUC9E VExTL1NDVFA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5QZXIgbXkgdW5kZXJzdGFuZGluZywgaW5kZXBlbmRlbnQgb2Yg dW5kZXJseWluZyB0cmFuc3BvcnQgKFVEUDsgb3Ig4oCcVENQIG92ZXIgUkZDNDQ3MeKAnQ0KIGZy YW1pbmcgbWltaWNraW5nIGRhdGFncmFtIHRyYW5zcG9ydCkgdGhlIERUTFMgcHJvdG9jb2wgaXMg c2FtZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5CUjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJhanU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+cnRjd2ViQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B1D682175ESESSMB209erics_-- From nobody Tue Jan 27 10:16: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 ED8031A891C for ; Tue, 27 Jan 2015 10:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 1vwbk1jBXPeJ for ; Tue, 27 Jan 2015 10:16:00 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F80B1A8913 for ; Tue, 27 Jan 2015 10:15:59 -0800 (PST) Received: from [192.168.1.200] (p508F02F3.dip0.t-ipconnect.de [80.143.2.243]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4EA791C104340; Tue, 27 Jan 2015 19:15:56 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> Date: Tue, 27 Jan 2015 19:15:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B1D675340@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC4B360F87@FR711WXCHMBA01.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D675C09@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D678F81@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D681465@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D682175@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "" Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel m-lines, right? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 27 Jan 2015 18:16:02 -0000 > On 27 Jan 2015, at 18:44, Christer Holmberg = wrote: >=20 > Hi, > =20 > >Well, if you are doing ICE-TCP, I would expect you to run = >DataChannels over that. ISTM that that suggests that the marker >should = be TCP/DTLS/SCTP. > =20 > I am not arguing against that. I just wonder why the data channel = draft doesn=E2=80=99t say anything about TCP, while explicitly talking = about UDP. That is correct. However, http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-09 says in the Abstract: Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; So it is clear that you can use other protocols like ICE/TCP. However, = this is not explicitly discussed and using TCP has the known drawback of = running a CC (in SCTP) over a CC (in TCP). I guess the reason why TCP is not mentioned explicitly is that noone = brought the issue up. It was always meant that you run over ICE no matter what = ICE is running over... Best regards Michael > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > On Tue, Jan 27, 2015 at 4:18 AM, Christer Holmberg = wrote: > Hi, > =20 > Related to this, when I read the data channel draft, it explicitly = talks about UDP. TCP is not even mentioned. > =20 > So, does that mean that TCP/DTLS/SCTP is not =E2=80=9Cofficially=E2=80=9D= a part of the data channel spec? > =20 > Regards, > =20 > Christer > =20 > From: Makaraju, Maridi Raju (Raju) = [mailto:Raju.Makaraju@alcatel-lucent.com]=20 > Sent: 24. tammikuuta 2015 15:35 > To: Christer Holmberg; Justin Uberti > Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; > Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? > =20 > I am ok to use UDP/DTLS/SCTP and TCP/DTLS/SCTP. > I agree that use of RFC #s is not the best option. > However, I find some unease in the discussions about =E2=80=9CTCP/DTLS=E2= =80=9D part, which seems to suggest why not use =E2=80=9CTCP/TLS=E2=80=9D?= We understand that it can=E2=80=99t be called that way because of the = RFC 4571 =E2=80=9Cshim layer=E2=80=9D in between DTLS and TCP layers. = Unfortunately, unlike TPKT, RFC 4571 did not give a name to the = protocol, which would have been easy to use than the RFC directly. > =20 > BR > Raju > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Friday, January 23, 2015 1:22 AM > To: Justin Uberti; Makaraju, Maridi Raju (Raju) > Cc: Schwarz, Albrecht (Albrecht); Suhas Nandakumar; > Subject: RE: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? > =20 > Hi, > =20 > I agree that we should not use RFC numbers in proto values. > =20 > Also keep in mind that UDP/DTLS/SCTP does not mean =E2=80=9CICE = based=E2=80=9D. ICE is optional for UDP/DTLS/SCTP (that fact that we = mandate ICE for RTCWEB is a separate issue). > =20 > Regards, > =20 > Christer > =20 > From: Justin Uberti [mailto:juberti@google.com]=20 > Sent: 23. tammikuuta 2015 5:57 > To: Makaraju, Maridi Raju (Raju) > Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = > Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? > =20 > No, I don't think including RFC4571 is reasonable. That ship has = already sailed. > =20 > On Thu, Jan 22, 2015 at 3:35 PM, Makaraju, Maridi Raju (Raju) = wrote: > I was also suggesting the following identifying string to make it = unambiguous up to L4 protocol. > I don=E2=80=99t hear any objections to it explicitly. Or did I = misinterpret the response? > For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP > For UDP ICE based data channel transport: UDP/DTLS/SCTP > =20 > BR > Raju > =20 > From: Justin Uberti [mailto:juberti@google.com]=20 > Sent: Thursday, January 22, 2015 4:45 PM > To: Makaraju, Maridi Raju (Raju) > Cc: Christer Holmberg; Schwarz, Albrecht (Albrecht); Suhas Nandakumar; = > Subject: Re: [rtcweb] It's "UDP/DTLS/SCTP" for the data channel = m-lines, right? > =20 > The protocol is the same. We are just deciding what the identifying = string should be. > =20 > Given the amount of confusion in this space, I think it makes sense to = be as explicit as possible, and use DTLS instead of TLS for the name. > =20 > On Thu, Jan 22, 2015 at 4:01 AM, Makaraju, Maridi Raju (Raju) = wrote: > =46rom protocol stacks layering point of view, isn=E2=80=99t the = following more accurately represent them? > For TCP ICE based data channel transport: TCP/RFC4571/DTLS/SCTP > For UDP ICE based data channel transport: UDP/DTLS/SCTP > =20 > Per my understanding, independent of underlying transport (UDP; or = =E2=80=9CTCP over RFC4471=E2=80=9D framing mimicking datagram transport) = the DTLS protocol is same. > =20 > BR > Raju > =20 > =20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jan 28 08:32:34 2015 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966F11A87A7 for ; Wed, 28 Jan 2015 08:32:31 -0800 (PST) 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 aREu4vGPhRL2 for ; Wed, 28 Jan 2015 08:32:30 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0797F1A87A3 for ; Wed, 28 Jan 2015 08:32:29 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id l15so13177427wiw.0 for ; Wed, 28 Jan 2015 08:32:27 -0800 (PST) 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=KSbCf4qceWckQU8b5JJwhBvzHcemjsi/biYMqN7Tbn8=; b=vcTQicW1HGoDJaAwTnUzxcDlM9g7s4nz3dN83RHNV+s76vo3PtzSEytPEw2O2mqdqa nJZIosa+K77chxg3eMG6QTT2qFw9bu8TF+tzcPjpAayO8I2PgpZJMOoZ/czF7Ig0Ic5G x7x2DRItsBvXqp+cliANwF7hxeH2QQm+Um2zC/JDF4p4JafLbxB4wwo8PHKUC4A0frwt /gP+LN4TnRy2UN51vOxW/C4zj1qPthOyFw1kaVTow/Z89DXQEYMtXL0SMzBepy4YixWL yB8Eghmo6sVlgZ6v9Lo/nO3klv6dc7aAeBn/LBhi17QKNyauVMvpiXNZ5d2SusdKxOk9 1LsQ== X-Received: by 10.180.77.39 with SMTP id p7mr8754105wiw.8.1422462747710; Wed, 28 Jan 2015 08:32:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.8 with HTTP; Wed, 28 Jan 2015 08:32:07 -0800 (PST) From: Bernard Aboba Date: Wed, 28 Jan 2015 08:32:07 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7b3ec89d79050db8ea46 Archived-At: Subject: [rtcweb] Rules for RTCMediaDiscardedEvent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 28 Jan 2015 16:32:31 -0000 --f46d043c7b3ec89d79050db8ea46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin submitted a pull request for RTCMediaDiscardedEvent (see https://github.com/w3c/webrtc-pc/pull/29), which is to be fired to indicate reception of =E2=80=9Cpackets having an unknown SSRC, payload typ= e, or any other error that makes it impossible to attribute an RTP packet to a specific MediaStreamTrack." I remember us discussing the rules for when such an error would occur, but can't seem to find the text in any of the RTCWEB WG documents. --f46d043c7b3ec89d79050db8ea46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin submitted a pull request for RTCMediaDiscardedEvent= (see https://github.c= om/w3c/webrtc-pc/pull/29), =C2=A0which is to be fired=C2=A0to indicate = reception of =C2=A0=E2=80=9Cpackets having an unknown SSRC, payload type, o= r any other error that makes it impossible to attribute an RTP packet to a = specific MediaStreamTrack."

I remember us discussin= g the rules for when such an error would occur, but can't seem to find = the text in any of the RTCWEB WG documents. =C2=A0
--f46d043c7b3ec89d79050db8ea46-- From nobody Wed Jan 28 09:11: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 932FD1A87A6 for ; Wed, 28 Jan 2015 09:10:58 -0800 (PST) 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 DqHWw3wXUnrd for ; Wed, 28 Jan 2015 09:10:57 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CBC1A00F3 for ; Wed, 28 Jan 2015 09:10:56 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id ar1so23120562iec.6 for ; Wed, 28 Jan 2015 09:10:56 -0800 (PST) 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=lriCjBMjQ1SHd42zrhIM9aWHN8zf/JAF3KPnPs5UT4o=; b=Cp4ZHCyqvEfVe95RddKYhksuz91WTGNOA3EjaeKCK+tryNpNEaa298H8M8LIm47MEX 3YJcXOoyVhbIK+fvbeT1o1Zegfir3G6ABrf7C/8ThZK+DX7VCRnZDdC1Vq+cPhZLWsBQ zDVBvMG5xs9bLUkbx4o1EPsVa0x7QZMqexy7v0S1+TlRPHEyul5smzZvOq/WhST2jNSF fplY/WZLQHk3kfqW3TzLmzLL0pYriQTaOZAu9i+eVR3v1n38deiwMtkt+hZG7H9xAs1Z Ryet+1pYYsxWIeexZR+omkAyUBpETDIRIL0ligX816XiaK0Oydj0dRRJem3bEy5Iz2Au PrXg== MIME-Version: 1.0 X-Received: by 10.50.136.228 with SMTP id qd4mr4893624igb.13.1422465056101; Wed, 28 Jan 2015 09:10:56 -0800 (PST) Received: by 10.42.35.142 with HTTP; Wed, 28 Jan 2015 09:10:55 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Jan 2015 18:10:55 +0100 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: multipart/alternative; boundary=089e0122aa56600326050db9740b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Rules for RTCMediaDiscardedEvent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 28 Jan 2015 17:10:58 -0000 --089e0122aa56600326050db9740b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2015 at 5:32 PM, Bernard Aboba wrote: > Martin submitted a pull request for RTCMediaDiscardedEvent (see > https://github.com/w3c/webrtc-pc/pull/29), which is to be fired to > indicate reception of =E2=80=9Cpackets having an unknown SSRC, payload t= ype, or > any other error that makes it impossible to attribute an RTP packet to a > specific MediaStreamTrack." > > I remember us discussing the rules for when such an error would occur, bu= t > can't seem to find the text in any of the RTCWEB WG documents. > > =E2=80=8BIs the formulation "any error that makes it impossible to attribut= e an RTP packet to a MediaStream track" a problem? (That is, if the rules are to always fire an error when that would result, is that a problem?) Or are you asking for a full enumeration? Ted=E2=80=8B > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e0122aa56600326050db9740b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 28, 2015 at 5:32 PM= , Bernard Aboba <bernard.aboba@gmail.com> wrote:
Ma= rtin submitted a pull request for RTCMediaDiscardedEvent (see https://github.co= m/w3c/webrtc-pc/pull/29), =C2=A0which is to be fired=C2=A0to indicate r= eception of =C2=A0=E2=80=9Cpackets having an unknown SSRC, payload type, or= any other error that makes it impossible to attribute an RTP packet to a s= pecific MediaStreamTrack."

I remember us discussing= the rules for when such an error would occur, but can't seem to find t= he text in any of the RTCWEB WG documents. =C2=A0


=E2=80=8BIs the formulation "any e= rror that makes it impossible to attribute an RTP packet to a MediaStream t= rack" a problem? (That is, if the rules are to always fire an error wh= en that would result, is that a problem?)=C2=A0 Or are you asking for a ful= l enumeration?

Ted=E2=80=8B

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


--089e0122aa56600326050db9740b-- From nobody Wed Jan 28 15:30: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 25D011A7005 for ; Wed, 28 Jan 2015 15:30:21 -0800 (PST) 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 DcycI90j3P4T for ; Wed, 28 Jan 2015 15:30:19 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DBF71A6FE7 for ; Wed, 28 Jan 2015 15:30:09 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id n3so16996142wiv.3 for ; Wed, 28 Jan 2015 15:30:08 -0800 (PST) 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=CYbn63MbdFmUxJ5OHfWYqmnRyF9YOCcONZ89Exnfxtw=; b=NXVXgRNt1RiCetHSy2CZqfPSbOp2F7PYMsXCsX9zqwVSyAQIcdmUo4R5RloqU1sQDY 7+qYBQwqmUV6zNhn/WQomZsjTxsZjt20xNqMNu5F+vWi/NP9qRQhI/11FwLZHv5nSHPz bSSMUSrIT/KWIkCWKMCgOOCIryWaKYzOSSAU1SEi55NjKoW2L7ru40yp5ACOHmsV2N/2 GFy3Ym6jNn7IsRE3JXjhDDuaUOceKm9Jt0wh8jd3AmDeNGHicOmpxGOf5mZPRMl2Yfkp 803s7bhzKtvu6wkz/x2L+GSnut7nOSW6mlgofk7lh3dfwslel65r42qykcXZJS8v1DD/ CZtQ== X-Received: by 10.180.74.229 with SMTP id x5mr11974383wiv.1.1422487808314; Wed, 28 Jan 2015 15:30:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.27.91.8 with HTTP; Wed, 28 Jan 2015 15:29:48 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 28 Jan 2015 15:29:48 -0800 Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=f46d04389591831240050dbec09f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Rules for RTCMediaDiscardedEvent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 28 Jan 2015 23:30:21 -0000 --f46d04389591831240050dbec09f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is some text in draft-ietf-mmusic-bundle-negotiation Sections 9 and 10 that provides general guidelines. However, the most specific guidance is found in draft-roach-mmusic-unified-plan Section 3.2, but does not appear to be duplicated in any WG work item. So I'm wondering if that (now expired) draft is what implementers should use or whether there is something more current/authoritative out there. On Wed, Jan 28, 2015 at 9:10 AM, Ted Hardie wrote: > On Wed, Jan 28, 2015 at 5:32 PM, Bernard Aboba > wrote: > >> Martin submitted a pull request for RTCMediaDiscardedEvent (see >> https://github.com/w3c/webrtc-pc/pull/29), which is to be fired to >> indicate reception of =E2=80=9Cpackets having an unknown SSRC, payload = type, or >> any other error that makes it impossible to attribute an RTP packet to a >> specific MediaStreamTrack." >> >> I remember us discussing the rules for when such an error would occur, >> but can't seem to find the text in any of the RTCWEB WG documents. >> >> > =E2=80=8BIs the formulation "any error that makes it impossible to attrib= ute an > RTP packet to a MediaStream track" a problem? (That is, if the rules are = to > always fire an error when that would result, is that a problem?) Or are > you asking for a full enumeration? > > Ted=E2=80=8B > > > >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --f46d04389591831240050dbec09f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is some text in draft-ietf-mmusic-bundle-negotiation= Sections 9 and 10 that provides general guidelines. However, the most spec= ific guidance is found in=C2=A0draft-roach-mmusic-unified-plan Section 3.2,= but does not appear to be duplicated in any WG work item. So I'm wonde= ring if that (now expired) draft is=C2=A0what implementers should use=C2=A0= or whether there is something more current/authoritative out there.
<= div class=3D"gmail_extra">
On Wed, Jan 28, 20= 15 at 9:10 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Wed, Jan 28, 2015 at 5:32 PM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:
Martin submitted a pull request for RTCMedi= aDiscardedEvent (see https://github.com/w3c/webrtc-pc/pull/29), =C2=A0which= is to be fired=C2=A0to indicate reception of =C2=A0=E2=80=9Cpackets having= an unknown SSRC, payload type, or any other error that makes it impossible= to attribute an RTP packet to a specific MediaStreamTrack."

<= /div>
I remember us discussing the rules for when such an error would o= ccur, but can't seem to find the text in any of the RTCWEB WG documents= . =C2=A0


=E2=80=8BIs the formulation &quo= t;any error that makes it impossible to attribute an RTP packet to a MediaS= tream track" a problem? (That is, if the rules are to always fire an e= rror when that would result, is that a problem?)=C2=A0 Or are you asking fo= r a full enumeration?

Ted=E2=80=8B

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



--f46d04389591831240050dbec09f-- From nobody Fri Jan 30 08:10: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 77AAF1A1AF4 for ; Fri, 30 Jan 2015 08:10:14 -0800 (PST) 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 gO5spZePaL-F for ; Fri, 30 Jan 2015 08:10:13 -0800 (PST) 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 8399F1A1A15 for ; Fri, 30 Jan 2015 08:10:12 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-d1-54cbace20a5b Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 66.50.04076.2ECABC45; Fri, 30 Jan 2015 17:10:10 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.195.1; Fri, 30 Jan 2015 17:10:10 +0100 Message-ID: <54CBACE1.2090104@ericsson.com> Date: Fri, 30 Jan 2015 17:10:09 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , "rtcweb@ietf.org" References: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> In-Reply-To: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvje6jNadDDBoua1t0TGazePZ2K6vF 2n/t7A7MHlN+b2T1WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBnLdvxnLXjDUXHg0SH2BsYJ 7F2MnBwSAiYS73tOMkLYYhIX7q1nA7GFBI4wSvTu8e5i5AKylzNKbL70kaWLkYODV0Bb4l9X CEgNi4CqxO5LB5hAbDYBC4mbPxrBekUFgiUWP3/KCmLzCghKnJz5hAXEFhGIkJh4/QIbyBhm ASWJ+7O0QcLCAq4S8x49Y4VYayOxbfJRdpASTgFbiS8tlSBhZgEDiSOL5rBC2PISzVtnM0OU a0s0NHWwTmAUnIVk2SwkLbOQtCxgZF7FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERi4B7f8 ttrBePC54yFGAQ5GJR7eDZ9PhQixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sa k1p8iJGJg1OqgXFRVppl9iWORUdv25Rt9gqpU03QFFh98nxIlYKZXsmBd5x9aqsOJk04XOTz rj7a2mXSng1Z7RvZH6T+UsmaeFum5bS/0Ff7R7sYUjv6OeXu8Ed49IkdW1n2STtK0MJzYkSM Za+TvnVO6DGGRWmLGQVL54cstpon5mEReGrp7jkv12oYV4leVmIpzkg01GIuKk4EAKbrRhw9 AgAA Archived-At: Cc: Ted Hardie Subject: Re: [rtcweb] Call for WG adoption of draft-uberti-rtcweb-fec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 30 Jan 2015 16:10:14 -0000 Hi, I support this. Considering that the deadline is passed. Is this now adopted? /Magnus On 2015-01-08 19:57, Cullen Jennings (fluffy) wrote: > > At the last meeting there was strong support for adopting > draft-uberti-rtcweb-fec as a WG draft. Unless we hear significant > objections to this, the chairs plan to more forward with adopting > this. If you have objection to this, please reply to this thread > before Jan 15. > > Thanks, > > Cullen, Sean, & Ted > > > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jan 30 10:19: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 A72381A1A0C for ; Fri, 30 Jan 2015 10:19:10 -0800 (PST) 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 wCXi_PlFPO0X for ; Fri, 30 Jan 2015 10:19:09 -0800 (PST) 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 B3CE71A039D for ; Fri, 30 Jan 2015 10:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1593; q=dns/txt; s=iport; t=1422641948; x=1423851548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ff3CWz5inx3cZ/x+lLCvzRAVO4sLyNCmfqQssWVPj7U=; b=mp62NHp6JRwQWU86EQAyyOZyn7c/EYxNcCv8P/uRxAjMU5p/Mt++AIgP D8CS3K4UlJXDY3v99gdOobNxWTCkyb8pqyx6RHDa49cuFwMlFh2WL+xna nsv1YaQ/bxFWQ8JNi6LHpP6QWraS79zjTfJy3tKLtrfgrKHpiwSGozSae w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DGBwBxystU/4oNJK1agmQiUlkExF8KhSdFAwICgR5DAQEBAQF9hAwBAQEDAQEBAQkRUQsFCQICAQgYJwcbDAsUEQIEAQ0FiCQIAQzXIAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBI9BMweDFoETBYVHiTWJIoEXgwGOOSKDbm+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,492,1418083200"; d="scan'208";a="119121331" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 30 Jan 2015 18:19:08 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t0UIJ738022639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 18:19:08 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 12:19:07 -0600 From: "Cullen Jennings (fluffy)" To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Call for WG adoption of draft-uberti-rtcweb-fec Thread-Index: AQHQPKc6AjiBGWiiA0+U2SP+0twH1pzZXbyA Date: Fri, 30 Jan 2015 18:19:06 +0000 Message-ID: References: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> <54CBACE1.2090104@ericsson.com> In-Reply-To: <54CBACE1.2090104@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2A7384899F510B4AA2651BC63EE8B8DC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Ted Hardie Subject: Re: [rtcweb] Call for WG adoption of draft-uberti-rtcweb-fec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 30 Jan 2015 18:19:10 -0000 Yes, we should have been clearer.=20 There is WG consensus to adopt this. We will now work with the AD to see if= we can get a milestone and after that request the authors to submit a WG v= ersion of the draft.=20 Cullen with my chair hat on=20 > On Jan 30, 2015, at 9:10 AM, Magnus Westerlund wrote: >=20 > Hi, >=20 > I support this. Considering that the deadline is passed. Is this now > adopted? >=20 > /Magnus >=20 > On 2015-01-08 19:57, Cullen Jennings (fluffy) wrote: >>=20 >> At the last meeting there was strong support for adopting >> draft-uberti-rtcweb-fec as a WG draft. Unless we hear significant >> objections to this, the chairs plan to more forward with adopting >> this. If you have objection to this, please reply to this thread >> before Jan 15. >>=20 >> Thanks, >>=20 >> Cullen, Sean, & Ted >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ rtcweb mailing list=20 >> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Fri Jan 30 10:22: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 76E5B1A1A0C for ; Fri, 30 Jan 2015 10:22:33 -0800 (PST) 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 80itPVHwK5Rk for ; Fri, 30 Jan 2015 10:22:31 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818A11A1B20 for ; Fri, 30 Jan 2015 10:21:54 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ms9so25156575lab.1 for ; Fri, 30 Jan 2015 10:21:53 -0800 (PST) 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=i0W1bADWBStfGPspK/F2kueriGWYy+AnuGtEP/Z6KZw=; b=Ic03+czTxwrZqqSKqX6FgHiejaFMZfwYoBvPUvPrhOYxqFclEKuPRSHwr/GS4Ecq1T VJtiJWTKdkJPd7Bkq3B69fdIpEa28k/F4mnde7DQq/3HZCLdjzP++ZiLyYSdeRN/hq+r r3pmdg9loaIJ1hA2EygCFlhlX0S7QLHKG8nIKTxsNjwC42VvaEZSri/OWMYW80E2Tkx5 qthATqxO7EfquNcxrck3M+oaSeaXaXTfWyYElf0sS9tjP5YwlDAVAutG/CCGfmIuxarD U7y6Nw+QqJvm13BupTcztDwbzaEn91qmttLn6xHOzWUD1Larkwboekh9Dup2YoTY67yO TCgg== MIME-Version: 1.0 X-Received: by 10.152.184.231 with SMTP id ex7mr8210532lac.4.1422642113031; Fri, 30 Jan 2015 10:21:53 -0800 (PST) Received: by 10.112.135.7 with HTTP; Fri, 30 Jan 2015 10:21:52 -0800 (PST) Received: by 10.112.135.7 with HTTP; Fri, 30 Jan 2015 10:21:52 -0800 (PST) In-Reply-To: <54CBACE1.2090104@ericsson.com> References: <4F790273-C0F3-4A78-B32F-0F4D8E34D28E@cisco.com> <54CBACE1.2090104@ericsson.com> Date: Fri, 30 Jan 2015 20:21:52 +0200 Message-ID: From: Varun Singh To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11345ac0ca32ea050de2ad9b Archived-At: Cc: "Cullen Jennings \(fluffy\)" , Ted Hardie , rtcweb@ietf.org Subject: Re: [rtcweb] Call for WG adoption of draft-uberti-rtcweb-fec X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-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, 30 Jan 2015 18:22:33 -0000 --001a11345ac0ca32ea050de2ad9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I support this too. The corresponding RTP payload draft was recently adopted as well. On 30-Jan-2015 6:10 pm, "Magnus Westerlund" wrote: > Hi, > > I support this. Considering that the deadline is passed. Is this now > adopted? > > /Magnus > > On 2015-01-08 19:57, Cullen Jennings (fluffy) wrote: > > > > At the last meeting there was strong support for adopting > > draft-uberti-rtcweb-fec as a WG draft. Unless we hear significant > > objections to this, the chairs plan to more forward with adopting > > this. If you have objection to this, please reply to this thread > > before Jan 15. > > > > Thanks, > > > > Cullen, Sean, & Ted > > > > > > > > > > _______________________________________________ rtcweb mailing list > > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11345ac0ca32ea050de2ad9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I support this too.=C2=A0 The corresponding RTP payload draf= t was recently adopted as well.

On 30-Jan-2015 6:10 pm, "Magnus Westerlund&= quot; <magnus.westerlu= nd@ericsson.com> wrote:
Hi,

I support this. Considering that the deadline is passed. Is this now
adopted?

/Magnus

On 2015-01-08 19:57, Cullen Jennings (fluffy) wrote:
>
> At the last meeting there was strong support for adopting
> draft-uberti-rtcweb-fec as a WG draft. Unless we hear significant
> objections to this, the chairs plan to more forward with adopting
> this. If you have objection to this, please reply to this thread
> before Jan 15.
>
> Thanks,
>
> Cullen, Sean, & Ted
>
>
>
>
> _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.iet= f.org/mailman/listinfo/rtcweb
>


--

Magnus Westerlund

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

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