From nobody Fri Sep 1 08:22:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D700134166 for ; Fri, 1 Sep 2017 08:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ea1vX34cg99t for ; Fri, 1 Sep 2017 08:22:37 -0700 (PDT) Received: from smtp66.ord1c.emailsrvr.com (smtp66.ord1c.emailsrvr.com [108.166.43.66]) (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 83382133100 for ; Fri, 1 Sep 2017 08:22:37 -0700 (PDT) Received: from smtp9.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DCE58204AC; Fri, 1 Sep 2017 11:22:33 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7E78F202D7; Fri, 1 Sep 2017 11:22:33 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 01 Sep 2017 11:22:33 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 1 Sep 2017 09:22:32 -0600 Cc: Roman Shpount , Martin Thomson To: mmusic Message-Id: <28A313A2-AC1C-4E09-9604-C45AE63A37AF@iii.ca> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [MMUSIC] Question about global uniqueness of dtls-id X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 15:22:38 -0000 There is a bug where we are discussing if the the dtls-id needs to be = globally unique or not. Can someone walk me though the logic of why it = needs to be globally unique? I'm not finding it in the previous list = discussion. =20= From nobody Fri Sep 1 09:13:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3097134268 for ; Fri, 1 Sep 2017 09:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 v563oiP4mehY for ; Fri, 1 Sep 2017 09:13:15 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3C336132FC6 for ; Fri, 1 Sep 2017 09:13:15 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-c4-59a98719e142 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.3D.22436.91789A95; Fri, 1 Sep 2017 18:13:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 18:13:13 +0200 From: Christer Holmberg To: Cullen Jennings , mmusic CC: Roman Shpount Thread-Topic: [MMUSIC] Question about global uniqueness of dtls-id Thread-Index: AQHTIzYoN+dg19iIHU2NdDPQ0j/gzqKgM8aQ Date: Fri, 1 Sep 2017 16:13:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD123BD@ESESSMB109.ericsson.se> References: <28A313A2-AC1C-4E09-9604-C45AE63A37AF@iii.ca> In-Reply-To: <28A313A2-AC1C-4E09-9604-C45AE63A37AF@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdV1eyfWWkwYJfChYf1v9gtJi6/DGL Rc+59ewOzB47Z91l91iy5CeTx+XzHxkDmKO4bFJSczLLUov07RK4Mjo717MW3GataHiyia2B 8RZLFyMnh4SAicTCzhusXYxcHEICRxgl9v7/wg7hLGaUWD6pn7mLkYODTcBCovufNkiDiICt RN+uE8wgNrOAmsSBrbeZQEqEBRwlFm7PhChxkljX/5MVwjaSuDXlIRuIzSKgIrHm4xqwvbwC vhKz1l4GGyMkYCnRvP06E4jNKWAlsej9R3YQm1FATOL7qTVMEKvEJW49mc8EcbOAxJI955kh bFGJl4//sULYShIrtl9ihKjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydhZSFpmIWmZ haRlASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAyDm45bfuDsbVrx0PMQpwMCrx8KaW r4wUYk0sK67MPcQowcGsJMJb2QoU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuw70KEkEB6Yklq dmpqQWoRTJaJg1OqgTHv8JeilW7KXxKS23+eWHw+ZbVG9K8nntt1xBT/8W3bt+zepH/C107v 1/prvyXdRmKx7FdlOdmS2d2f1t0TvfEpdBXbxt9LNijK1eyI+Lf1zMcjAr1xXivCfiyp3P38 BduuqkPct07wvjCIX3/k+5LESWtOXVGt9avmu1Kw7dCe6ccfrd9scNJ4rxJLcUaioRZzUXEi AHBsH5yYAgAA Archived-At: Subject: Re: [MMUSIC] Question about global uniqueness of dtls-id X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 16:13:17 -0000 Hi, Does the GitHub discussion not answer the question? Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 01 September 2017 17:23 To: mmusic Cc: Roman Shpount Subject: [MMUSIC] Question about global uniqueness of dtls-id There is a bug where we are discussing if the the dtls-id needs to be globa= lly unique or not. Can someone walk me though the logic of why it needs to = be globally unique? I'm not finding it in the previous list discussion. =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Sep 1 09:15:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF5C13316D for ; Fri, 1 Sep 2017 09:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVLqCwFDF6cH for ; Fri, 1 Sep 2017 09:15:42 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927831342CB for ; Fri, 1 Sep 2017 09:15:42 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 63so1817756pgc.2 for ; Fri, 01 Sep 2017 09:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sN/Ly08rL6UwSgJoUfmSDP/Kbl2JFtCr8IBuY3MSb3Y=; b=l/VcdFUAXKpIQfWyrObkUzKhWLPazY7gNjm9HIkLK6y6nxn4Kh3GYHr44p9bL9Wspx OnfRshP9lDZyMkvBStNU1bJVMNe/UHzDqCv2W7i7WBgC0ey1hvtRzcQbBVLTuauSGpf5 yg5gEhzrrE9bhTvd8tsI1Li4mV7iyPf90t3lRqkK3wrQ599Pp1OwLEj94lQu/joj6oTN EmrcmowjQF1v3HDuIGXpA29qMIxgsHpb4jVl40e9ExALH5UzuJwgiF2XR566uQJpEkwN NwjcqPTFk64Btdkl7UpoVPlRQgfmfV34MxZuAOGF/YYWmvJ674rm7JycQcGt7rz7nMvr /UuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sN/Ly08rL6UwSgJoUfmSDP/Kbl2JFtCr8IBuY3MSb3Y=; b=ZsVqHRGVXiVoz/9+GroFomP0svdi9GmmigTVQxiJZOXGTMCP/O0RfXqlpg4nqsBLDL oc6+q9UxrvF0zRaci4CxzhcGiyMFZ0xDnWHrSNfN53KwCkKS6+aV3A8KKmazIGpzGrti W3beabJQQCHpIpttVnL6CVlsx/4oufWJYxGrmUPuTyg94HuYV7wgbGHJTY6lCuxWyxCB rMhXMJways5yQ/Y0scwCLymp3GuMBbGyElpy5rCaJ0/gJsIZW8/N/SFR3sr5OdvbouC7 Wi9b+CvANnr1AYKhdVZqXeA77XzewFQLonYbbPj+xQFMi0/hjDeDe+4orm9S6/hpWYOh VG9A== X-Gm-Message-State: AHPjjUggJG8vAFEsUNbrvhxHj8Yq4LJHh4q4CxCcdam5yvlR4p3k6nO7 CIrvY+TLaEkQ1puqkOY= X-Received: by 10.98.101.6 with SMTP id z6mr2986970pfb.120.1504282541701; Fri, 01 Sep 2017 09:15:41 -0700 (PDT) Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com. [209.85.192.176]) by smtp.gmail.com with ESMTPSA id g63sm674896pgc.94.2017.09.01.09.15.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 09:15:41 -0700 (PDT) Received: by mail-pf0-f176.google.com with SMTP id r187so1804781pfr.3 for ; Fri, 01 Sep 2017 09:15:41 -0700 (PDT) X-Google-Smtp-Source: ADKCNb5/39oc1dtNjFjJB5jNBaetMf1O0yU3yBSG5DhPYT27fdPoFkGJA0za0jm5ajJimcSZoDZmcI9zbyC8P/9JFIk= X-Received: by 10.98.69.212 with SMTP id n81mr2891744pfi.181.1504282540769; Fri, 01 Sep 2017 09:15:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Fri, 1 Sep 2017 09:15:40 -0700 (PDT) In-Reply-To: References: <28A313A2-AC1C-4E09-9604-C45AE63A37AF@iii.ca> From: Roman Shpount Date: Fri, 1 Sep 2017 12:15:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: mmusic , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c0b7fee7c0abc0558231227" Archived-At: Subject: Re: [MMUSIC] Question about global uniqueness of dtls-id X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 16:15:44 -0000 --94eb2c0b7fee7c0abc0558231227 Content-Type: text/plain; charset="UTF-8" Cullen, Imagine that call is established between end points A and B through a third party call control element 3PCC. 3PCC then decides to connect end points A and C. 3PCC sends a request for an offer to C (INVITE with no SDP in case of SIP). When 3PCC gets offer from C, 3PCC send this offer to A. As far as A is concerned this is just a re-offer on an existing connection, so if tls-id must be different if new DTLS association is needed. If tls-id just happens to be the same due to collision, this will either be treated as invalid offer, if fingerprints has changed, or DTLS association will not be created when it should have. Essentially, because of 3PCC, connections can migrate between end points, connecting, disconnecting, and re-connecting multiple end points. For each end point this looks like a single connection to a 3PCC controller, but tls-id generated by multiple unrelated end points and should not collide between any of them. I agree that 120 bits of randomness is excessive just to avoid collisions. Amount of randomness was increased in order to securely identify TLS connection and DTLS associations. Regards, _____________ Roman Shpount On Fri, Sep 1, 2017 at 11:46 AM, Roman Shpount wrote: > Cullen, > > Imagine that call is established between end points A and B through a > third party call control element 3PCC. > 3PCC then decides to connect end points A and C. 3PCC sends a request for > an offer to C (INVITE with no SDP in case of SIP). > When 3PCC gets offer from C, 3PCC send this offer to A. > As far as A is concerned this is just a re-offer on an existing > connection, so if tls-id must be different if new DTLS association is > needed. If tls-id just happens to be the same due to collision, this will > either be treated as invalid offer, if fingerprints has changed, or DTLS > association will not be created when it should have. > > Essentially, because of 3PCC, connections can migrate between end points, > connecting, disconnecting, and re-connecting multiple end points. For each > end point this looks like a single connection to a 3PCC controller, but > tls-id generated by multiple unrelated end points and should not collide > between any of them. > > I agree that 120 bits of randomness is excessive just to avoid collisions. > Amount of randomness was increased in order to securely identify TLS > connection and DTLS associations. > > Regards, > > _____________ > Roman Shpount > > On Fri, Sep 1, 2017 at 11:22 AM, Cullen Jennings wrote: > >> There is a bug where we are discussing if the the dtls-id needs to be >> globally unique or not. Can someone walk me though the logic of why it >> needs to be globally unique? I'm not finding it in the previous list >> discussion. >> >> >> >> >> > > > --94eb2c0b7fee7c0abc0558231227 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Cullen,

Imagine that c= all is established between end points A and B through a third party call co= ntrol element 3PCC.
3PCC then decides to connect end points A= and C. 3PCC sends a request for an offer to C (INVITE with no SDP in case = of SIP).=C2=A0
When 3PCC gets offer from C, 3PCC send this offer = to A.
As far as A is concerned this is just a re-offer on an exis= ting connection, so if tls-id must be different if new DTLS association is = needed. If tls-id just happens to be the same due to collision, this will e= ither be treated as invalid offer, if fingerprints has changed, or DTLS ass= ociation will not be created when it should have.

= Essentially, because of 3PCC, connections can migrate between end points, c= onnecting, disconnecting, and re-connecting multiple end points. For each e= nd point this looks like a single connection to a 3PCC controller, but tls-= id generated by multiple unrelated end points and should not collide betwee= n any of them.

I agree that 120 bits of random= ness is excessive just to avoid collisions. Amount of randomness was increa= sed in order to securely identify TLS connection and DTLS associations.

Regards,



_____________
Ro= man Shpount

On Fri, Sep 1, 2017 at 11:46 AM, Roman Shpou= nt <rshpount@gmail.com> wrote:
Cullen,

Imagine that call is esta= blished between end points A and B through a third party call control eleme= nt 3PCC.
3PCC then decides to connect end points A and C. 3PC= C sends a request for an offer to C (INVITE with no SDP in case of SIP).=C2= =A0
When 3PCC gets offer from C, 3PCC send this offer to A.
=
As far as A is concerned this is just a re-offer on an existing connec= tion, so if tls-id must be different if new DTLS association is needed. If = tls-id just happens to be the same due to collision, this will either be tr= eated as invalid offer, if fingerprints has changed, or DTLS association wi= ll not be created when it should have.

Essentially= , because of 3PCC, connections can migrate between end points, connecting, = disconnecting, and re-connecting multiple end points. For each end point th= is looks like a single connection to a 3PCC controller, but tls-id generate= d by multiple unrelated end points and should not collide between any of th= em.

I agree that 120 bits of randomness is exc= essive just to avoid collisions. Amount of randomness was increased in orde= r to securely identify TLS connection and DTLS associations.

=
Regards,

_____________
Roman Shpount

On Fri, Sep 1, 2017 at 11:22 AM, Cullen Jenn= ings <fluffy@iii.ca> wrote:
Th= ere is a bug where we are discussing if the the dtls-id needs to be globall= y unique or not. Can someone walk me though the logic of why it needs to be= globally unique? I'm not finding it in the previous list discussion.



=C2=A0


--94eb2c0b7fee7c0abc0558231227-- From nobody Fri Sep 1 10:28:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45C71342CC for ; Fri, 1 Sep 2017 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fDkDCZ0TjiJf for ; Fri, 1 Sep 2017 10:28:53 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 EE30C134461 for ; Fri, 1 Sep 2017 10:28:52 -0700 (PDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0B2F625940; Fri, 1 Sep 2017 13:28:52 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp25.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 97F542592D; Fri, 1 Sep 2017 13:28:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 01 Sep 2017 13:28:52 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 1 Sep 2017 11:28:50 -0600 Cc: mmusic Content-Transfer-Encoding: quoted-printable Message-Id: <09F593D8-CD5E-46FD-905E-49D351A74A7E@iii.ca> References: <28A313A2-AC1C-4E09-9604-C45AE63A37AF@iii.ca> To: Roman Shpount X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] Question about global uniqueness of dtls-id X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 17:28:55 -0000 Thank for helping my understand how we got where we are ... more inline = ... > On Sep 1, 2017, at 10:15 AM, Roman Shpount wrote: >=20 > Cullen, >=20 > Imagine that call is established between end points A and B through a = third party call control element 3PCC. > 3PCC then decides to connect end points A and C. 3PCC sends a request = for an offer to C (INVITE with no SDP in case of SIP).=20 > When 3PCC gets offer from C, 3PCC send this offer to A. > As far as A is concerned this is just a re-offer on an existing = connection, so if tls-id must be different if new DTLS association is = needed. If tls-id just happens to be the same due to collision, this = will either be treated as invalid offer, if fingerprints has changed, or = DTLS association will not be created when it should have. I don't think that works for a bunch of reasons but to start with the = 2nd offer to A would not have the right information in the o=3D lines of = the the original offer/answer. In many cases (including WebRTC) that = would cause it not to work as a re-offer. Other issues like it A was = receiving video, the old I frame state might end up getting used. If A = was sending, it would not know the the other end was now missing = reference frames.=20 SIP can deal with that by using the invite with replaces stuff from = rfc3891 so that the 2nd offer sent to A can clearly be a new session not = a reoffer on the old one. Similar things would be done by webrtc so it = could deal with it by just creating a new PC for the 2nd offer and = transfering the tracks over to the new PC.=20 Section 5.2.2. of JSEP discussed this a bit how the o=3D lines need to = be the same for a reoffer.=20 >=20 > Essentially, because of 3PCC, connections can migrate between end = points, connecting, disconnecting, and re-connecting multiple end = points. For each end point this looks like a single connection to a 3PCC = controller, but tls-id generated by multiple unrelated end points and = should not collide between any of them. >=20 > I agree that 120 bits of randomness is excessive just to avoid = collisions. Amount of randomness was increased in order to securely = identify TLS connection and DTLS associations. >=20 > Regards, >=20 >=20 >=20 > _____________ > Roman Shpount >=20 > On Fri, Sep 1, 2017 at 11:46 AM, Roman Shpount = wrote: > Cullen, >=20 > Imagine that call is established between end points A and B through a = third party call control element 3PCC. > 3PCC then decides to connect end points A and C. 3PCC sends a request = for an offer to C (INVITE with no SDP in case of SIP).=20 > When 3PCC gets offer from C, 3PCC send this offer to A. > As far as A is concerned this is just a re-offer on an existing = connection, so if tls-id must be different if new DTLS association is = needed. If tls-id just happens to be the same due to collision, this = will either be treated as invalid offer, if fingerprints has changed, or = DTLS association will not be created when it should have. >=20 > Essentially, because of 3PCC, connections can migrate between end = points, connecting, disconnecting, and re-connecting multiple end = points. For each end point this looks like a single connection to a 3PCC = controller, but tls-id generated by multiple unrelated end points and = should not collide between any of them. >=20 > I agree that 120 bits of randomness is excessive just to avoid = collisions. Amount of randomness was increased in order to securely = identify TLS connection and DTLS associations. >=20 > Regards, >=20 > _____________ > Roman Shpount >=20 > On Fri, Sep 1, 2017 at 11:22 AM, Cullen Jennings = wrote: > There is a bug where we are discussing if the the dtls-id needs to be = globally unique or not. Can someone walk me though the logic of why it = needs to be globally unique? I'm not finding it in the previous list = discussion. >=20 >=20 >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Sep 1 12:29:17 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4B0134284 for ; Fri, 1 Sep 2017 12:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TtP0iLYk5N_x for ; Fri, 1 Sep 2017 12:29:14 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE49132E0F for ; Fri, 1 Sep 2017 12:29:14 -0700 (PDT) X-AuditID: 12074412-1e5ff7000000748d-ce-59a9b5093297 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C9.41.29837.905B9A95; Fri, 1 Sep 2017 15:29:13 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v81JTANq028629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 1 Sep 2017 15:29:12 -0400 To: mmusic@ietf.org References: <28A313A2-AC1C-4E09-9604-C45AE63A37AF@iii.ca> <09F593D8-CD5E-46FD-905E-49D351A74A7E@iii.ca> From: Paul Kyzivat Message-ID: <9a0d0cfa-83c6-ec67-1a2f-2967ea1b052a@alum.mit.edu> Date: Fri, 1 Sep 2017 15:29:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <09F593D8-CD5E-46FD-905E-49D351A74A7E@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixO6iqMu5dWWkwbYtwhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpGWNywFbRwVc3fdYWlgXMXWxcjJISFgInFiXzdLFyMXh5DA DiaJk7POMkI435gknn88wARSJSzgKPHk4VuwDhEBYYkZb/+yQRR9Z5RYcn8FI0iCTUBLYs6h /ywgNq+AvcTPN8/AbBYBFYklE+6CDRIVSJP4t/ssI0SNoMTJmU/AajgFrCRmf5jHCmIzC5hJ zNv8kBnCFpe49WQ+E4QtL7H97RzmCYz8s5C0z0LSMgtJyywkLQsYWVYxyiXmlObq5iZm5hSn JusWJyfm5aUW6Zrp5WaW6KWmlG5ihASm0A7G9SflDjEKcDAq8fA2xK2MFGJNLCuuzD3EKMnB pCTKW+2/IlKILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+p9UDlvCmJlVWpRfkwKWkOFiVx3p+L 1f2EBNITS1KzU1MLUotgsjIcHEoSvEc3AzUKFqWmp1akZeaUIKSZODhBhvMADZ8GUsNbXJCY W5yZDpE/xWjM8Wvm1i9MHB0zfn5jEmLJy89LlRLn1QEpFQApzSjNg5sGSy6vGMWBnhPmZdkC VMUDTExw814BrWICWvXv8wqQVSWJCCmpBsYKtnTb2U0bb2+sin8wPYp1unNHyLavWw70J3Pt D+vr6mk49vfTtHNvjeb1WAqGfn9tf6a+Yp+BnY9B1bS5a5e1LrndFHwvc+qsSS/OLOdbrie8 eI732eQXjj/uuFj97b1mpms4ib9ErqKQU4FVyzwigTPrymKdZZanzzF/a3uXM+f5j9zbEzmU WIozEg21mIuKEwF4ctbHCQMAAA== Archived-At: Subject: Re: [MMUSIC] Question about global uniqueness of dtls-id X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 19:29:16 -0000 On 9/1/17 1:28 PM, Cullen Jennings wrote: > I don't think that works for a bunch of reasons but to start with the 2nd offer to A would not have the right information in the o= lines of the the original offer/answer. In many cases (including WebRTC) that would cause it not to work as a re-offer. Other issues like it A was receiving video, the old I frame state might end up getting used. If A was sending, it would not know the the other end was now missing reference frames. > > SIP can deal with that by using the invite with replaces stuff from rfc3891 so that the 2nd offer sent to A can clearly be a new session not a reoffer on the old one. Similar things would be done by webrtc so it could deal with it by just creating a new PC for the 2nd offer and transfering the tracks over to the new PC. In principle this can be fixed by the B2BUA fiddling with the answer - rewriting the o-line as needed. OTOH, if it is doing that it can perhaps also rewrite the tls-id value if it isn't unique. Thanks, Paul From nobody Sat Sep 2 13:36:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862E01241F3 for ; Sat, 2 Sep 2017 13:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqbiGH4hJwUi for ; Sat, 2 Sep 2017 13:36:40 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667C1132D7E for ; Sat, 2 Sep 2017 13:36:40 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id s187so12868035ywf.2 for ; Sat, 02 Sep 2017 13:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4A0WRYT+WHhBVuF73o1oM1th6AlqRTTyRe+rTk8TGik=; b=zJbk0YPwWex7lbcqMiUxFN1FqAuVfSNEX/WKY+RBmumz7izHXvxMpzTzUfCZCbcz8z tZbPX6FTu9w5vzCbkqQz8GHTsvQ0NC/OTQUgYBgj7ekBpZxIzQRcWTvNieV5mZdft+1a WajCmL5TKw9MeqmBpDz/8O/y0jLc1xnUHfsLxzQVUI8roG/NW3oFhbuAQK6/8TwnB1dj mJ1vQtZYPd2bBtYdyt494KPsZGb7W7xcdh8ynnfOcra6vul30aUVIpMBH5zyVfN57Kdz cQznYPvQ2wYQq3jNSsjQ5ryZIf4rR1GsQfCd+PE5Yx1A/BFSfjjuMcsPjb29PsTMLcwj YFGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4A0WRYT+WHhBVuF73o1oM1th6AlqRTTyRe+rTk8TGik=; b=cHjWuMY4XnROawFdJSfYXOiNx/qrLquYfsKqsF9pq3un6oiCWI4zE5TBVl+Tb12ctM fRCFhIMSldlPctdcTPFGVb04tVXwhfjWxUvoG3WqbieuB+xHhneozl+c2zyLJvGlrQ3V P3a2gXr80Tkof1wyspBX2j8fnYdxqT9NJTkhKjClKoVOEFbZ6wV1Tqw5u/ji6oCy/9OL hAOHdMK5HXw8H1iepfz0FMdjmHZMR98lV7z8yfYnQrrpimX3/ETEXYPf05oZkdxe30xV S15PefXrLS0HhrvKkWBzBSDUvg6Ge3+xFLzvMJYxzwlcV4BYPQLJBjxrPfI31rVZJY0e p99A== X-Gm-Message-State: AHPjjUjKQX4kyN16DI0GRDl9KobTh2N3gRHbr5TpRjspGaYqBSr+aGU8 ME5UWjqd1H7o/NQ9qnhm1nkwIjJplHmz X-Google-Smtp-Source: ADKCNb6FQUZHBkIzLU/bJwEVx9WgkjXpWJk/C8H5YzVniS+nD1UdwO1IuUjXO6l0eTl03l5CEP46+IQgugaxFOo7zDg= X-Received: by 10.37.208.195 with SMTP id h186mr5369420ybg.345.1504384599628; Sat, 02 Sep 2017 13:36:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sat, 2 Sep 2017 13:35:59 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 2 Sep 2017 14:35:59 -0600 Message-ID: To: Bernard Aboba Cc: Adam Roach , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05615aaab24205583ad542" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 20:36:44 -0000 --94eb2c05615aaab24205583ad542 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba wrote: > On Issue 1, Adam said: > > " > > 1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. While > it would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From that perspective, it > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > " > > [BA] Agree that for consistency, it is best for an ICE restart to > necessitate a new DTLS connection, since an ICE restart can result in > connection to a different device (and the need for a new DTLS connection). > I'm not persuaded by this: the primary reason for an ICE restart is not changing devices but rather trying to deal with topology changes and/or connectivity check failures. If you actually *do* change devices, then it's also quite probably you will have a new certificate fingerprint, in which case you will get a new DTLS connection in any case. In other words, tls-id should be used to say "I want a new DTLS connection in spite of the fingerprint being the same" (what JSEP says), not "I want to keep the DTLS connection even though I am doing an ICE restart" -Ekr > On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: > >> MMUSIC -- >> >> [I will be posting a separate message to RTCWEB directing interested >> parties to discuss this issue on the MMUSIC mailing list] >> >> During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some >> conflicts between the procedures in DTLS-SDP and JSEP were identified. This >> note is an attempt to summarize them. I have also made an initial proposal, >> for each conflict, regarding which document needs to change, in and which >> way. >> >> Issue 1 (quoting EKR), which raises a couple of additional sub-issues: >> >> 1. Assuming I understand this document correctly, it conflicts with >> the guidance in JSEP. Specifically, S 4 says: >> >> No default value is defined for the SDP 'tls-id' attribute. >> Implementations that wish to use the attribute MUST explicitly >> include it in SDP offers and answers. If an offer or answer does not >> contain a 'tls-id' attribute (this could happen if the offerer or >> answerer represents an existing implementation that has not been >> updated to support the 'tls-id' attribute), unless there is another >> mechanism to explicitly indicate that a new DTLS association is to be >> established, a modification of one or more of the following >> characteristics MUST be treated as an indication that an endpoint >> wants to establish a new DTLS association: >> >> o DTLS setup role; or >> >> o fingerprint set; or >> >> o local transport parameters; or >> >> o ICE ufrag value >> >> This seems to say that if there is no tls-id attribute, then an ICE restart >> (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't >> incredibly clear on this point, but 5.7.3 seems to say that tls-id >> need not be present: >> >> * tls-id value, which MUST be set according to >> [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer >> and the tls-id value is different from that presently in use, >> the DTLS connection is not being continued and the remote >> description MUST be part of an ICE restart, together with new >> ufrag and password values. If this is an answer, the tls-id >> value, if present, MUST be the same as in the offer. >> >> I believe that the first sentence is in error, as we clearly >> can't have JSEP implementations requiring that tls-id be present. >> >> ... >> >> o If the remote DTLS fingerprint has been changed or the tls-id has >> changed, tear down the DTLS connection. This includes the case >> when the PeerConnection state is "have-remote-pranswer". If a >> DTLS connection needs to be torn down but the answer does not >> indicate an ICE restart or, in the case of "have-remote-pranswer", >> new ICE credentials, an error MUST be generated. If an ICE >> restart is performed without a change in tls-id or fingerprint, >> then the same DTLS connection is continued over the new ICE >> channel. >> >> I think the best interpretation of this is that if tls-id is not present >> (and hence unchanged) then ICE restart does not cause DTLS restart. >> This is also my memory of the consensus in RTCWEB. In any case, these >> two documents clearly must match. >> >> >> My observations/recommendations: >> >> 1. (Issue 1a) EKR is correct that the first sentence of the bullet >> from JSEP needs to be removed so as to enable interoperation with non-JSEP >> implementations. >> >> 2. (Issue 1b) Additionally the final sentence of that bullet ("If >> this is an answer, the tls-id value, if present, MUST be the same as in the >> offer") conflicts with the definition of tls-id ("the offerer and answerer >> generate their own local 'tls-id' attribute values, and the combination of >> both values identify the DTLS association"). In this case, the DTLS-SDP >> document would appear to be correct (the fact that the two parties choose >> different IDs is integral to the mechanism's design), so JSEP needs to >> change. >> >> 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to >> restart? The primary rationale outlined in RFC5245 for restarting ICE is >> changing the destination (IP address or port) of an ongoing media stream -- >> which would commonly involve changing to a different physical device. While >> it would, in theory, be possible to transfer the TLS state associated with >> the connection between devices, this is rather cumbersome (and, as far as I >> know, not generally supported by TLS libraries). From that perspective, it >> is my opinion that the DTLS-SDP document is correct that an ICE restart >> necessitates a new DTLS connection; and I conclude that JSEP needs to >> change. >> >> >> Issue 2 (quoting EKR): >> >> 2. S 4 says: >> >> The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- >> id' attribute is 'IDENTICAL', which means that the attribute value >> must be identical across all media descriptions being multiplexed >> [I-D.ietf-mmusic-sdp-bundle-negotiation]. >> >> This is not actually what JSEP requires: >> >> different categories. To avoid unnecessary duplication when >> bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be >> repeated in bundled m= sections, repeating the guidance from >> [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes >> >> I suspect this is old text. >> >> >> (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, >> while DTLS-SDP does not. This is a largely aesthetic decision (although the >> JSEP/BUNDLE approach does save a tiny handful of bytes), but I think >> changing one document (DTLS-SDP) makes more sense than changing two. (I >> suspect the BUNDLE formulation more closely tracks consensus anyway). >> >> >> /a >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c05615aaab24205583ad542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:
On Issue 1, Adam said:=C2=A0

&quo= t;
  1. (Issu= e 1c) The crux of the matter: does ICE restart cause DTLS to restart? The p= rimary rationale outlined in RFC5245 for restarting ICE is changing the des= tination (IP address or port) of an ongoing media stream -- which would com= monly involve changing to a different physical device. While it would, in t= heory, be possible to transfer the TLS state associated with the connection= between devices, this is rather cumbersome (and, as far as I know, not gen= erally supported by TLS libraries). From that perspective, it is my opinion= that the DTLS-SDP document is correct that an ICE restart necessitates a n= ew DTLS connection; and I conclude that JSEP needs to change.
"

[BA] Agree that for consistency, it= is best for an ICE restart to necessitate a new DTLS connection, since an = ICE restart can result in connection to a different device (and the need fo= r a new DTLS connection).=C2=A0=C2=A0

I'm not persuaded by this: the primary reason for an ICE restart= is not changing devices but rather trying to deal with topology changes an= d/or connectivity check failures. If you actually *do* change devices, then= it's also quite probably you will have a new certificate fingerprint, = in which case you will get a new DTLS connection in any case. In other word= s, tls-id should be used to say "I want a new DTLS connection in spite= of the fingerprint being the same" (what JSEP says), not "I want= to keep the DTLS connection even though I am doing an ICE restart"

-Ekr


On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <= ;adam@nostrum.com= > wrote:
=20 =20 =20

MMUSIC --

[I will be posting a separate message to RTCWEB directing interested parties to discuss this issue on the MMUSIC mailing list]

During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some conflicts between the procedures in DTLS-SDP and JSEP were identified. This note is an attempt to summarize them. I have also made an initial proposal, for each conflict, regarding which document needs to change, in and which way.

Issue 1 (quoting EKR), which raises a couple of additional sub-issues:

1. Assuming I understand this=
 document correctly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:

   No default value is defined for the SDP 'tls-id' attribute.
   Implementations that wish to use the attribute MUST explicitly
   include it in SDP offers and answers.  If an offer or answer does not
   contain a 'tls-id' attribute (this could happen if the offerer o=
r
   answerer represents an existing implementation that has not been
   updated to support the 'tls-id' attribute), unless there is anot=
her
   mechanism to explicitly indicate that a new DTLS association is to be
   established, a modification of one or more of the following
   characteristics MUST be treated as an indication that an endpoint
   wants to establish a new DTLS association:

   o  DTLS setup role; or

   o  fingerprint set; or

   o  local transport parameters; or

   o  ICE ufrag value

This seems to say that if there is no tls-id attribute, then an ICE restart
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't
incredibly clear on this point, but 5.7.3 seems to say that tls-id
need not be present:

      *  tls-id value, which MUST be set according to
         [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
         and the tls-id value is different from that presently in use,
         the DTLS connection is not being continued and the remote
         description MUST be part of an ICE restart, together with new
         ufrag and password values.  If this is an answer, the tls-id
         value, if present, MUST be the same as in the offer.

I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.

   ...
  =20
   o  If the remote DTLS fingerprint has been changed or the tls-id has
      changed, tear down the DTLS connection.  This includes the case
      when the PeerConnection state is "have-remote-pranswer".  I=
f a
      DTLS connection needs to be torn down but the answer does not
      indicate an ICE restart or, in the case of "have-remote-pranswer=
",
      new ICE credentials, an error MUST be generated.  If an ICE
      restart is performed without a change in tls-id or fingerprint,
      then the same DTLS connection is continued over the new ICE
      channel.
     =20
I think the best interpretation of this is that if tls-id is not present
(and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.


My observations/recommendations:

  1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP needs to be removed so as to enable interoperation with non-JSEP implementations.

  2. (Issue 1b) Additionally the final sentence of that bullet ("= If this is an answer, the tls-id value, if present, MUST be the same as in the offer") conflicts with the definition of tls-id ("the offerer and answerer generate their own local 'tls-i= d' attribute values, and the combination of both values identify the DTLS association"). In this case, the DTLS-SDP document would appear to be correct (the fact that the two parties choose different IDs is integral to the mechanism's design), so JSEP needs to change.

  3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change.


Issue 2 (quoting EKR):

2. S 4 says:

   The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the '=
tls-
   id' attribute is 'IDENTICAL', which means that the attribute=
 value
   must be identical across all media descriptions being multiplexed
   [I-D.ietf-mmusic-sdp-bundle-negotiation].

This is not actually what JSEP requires:

   different categories.  To avoid unnecessary duplication when
   bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be
   repeated in bundled m=3D sections, repeating the guidance from
   [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1.  This includ=
es

I suspect this is old text.


(Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, while DTLS-SDP does not. This is a largely aesthetic decision (although the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more closely tracks consensus anyway).


/a


_____________________________________= __________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic


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

--94eb2c05615aaab24205583ad542-- From nobody Sat Sep 2 14:32:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F508132EF5 for ; Sat, 2 Sep 2017 14:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 gpey0-WZ1h9k for ; Sat, 2 Sep 2017 14:32:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 394F4132EF1 for ; Sat, 2 Sep 2017 14:32:05 -0700 (PDT) X-AuditID: c1b4fb2d-103ff700000057a4-1f-59ab2339dc3d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.BF.22436.9332BA95; Sat, 2 Sep 2017 23:31:38 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sat, 2 Sep 2017 23:31:37 +0200 From: Christer Holmberg To: Eric Rescorla , Bernard Aboba CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKbMmOAgAbGf4CAADCNsA== Date: Sat, 2 Sep 2017 21:31:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B562818F7ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7tK6V8upIg2uzuSw27PvPbLHi9Tl2 i6nLH7M4MHvsnHWX3WPJkp9MHpMftzEHMEdx2aSk5mSWpRbp2yVwZRxZ3sRccGMaU8XOmw4N jBv6mboYOTkkBEwkdi3tYgaxhQSOMEosPmjcxcgFZC9mlFjy4SlbFyMHB5uAhUT3P22QGhEB T4kpf3czgYSZBdQlri4OAjGFBQwlTt83gqgwkrh8/AEzhO0kcWvPbbBNLAIqEvvX7WADsXkF fCW23d/BDLHpDKPEkf/XwBKcAoES55ofsYLYjAJiEt9PrQFrZhYQl7j1ZD7UyQISS/acZ4aw RSVePv7HCmErSazYfokRoj5f4u66D4wQywQlTs58wjKBUWQWklGzkJTNQlI2C+wzTYn1u/Qh ShQlpnQ/ZIewNSRa58xlRxZfwMi+ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwzg5u+a27 g3H1a8dDjAIcjEo8vIG8qyOFWBPLiitzDzFKcDArifDyyQOFeFMSK6tSi/Lji0pzUosPMUpz sCiJ8zrsuxAhJJCeWJKanZpakFoEk2Xi4JRqYOx6EqdZmjTp22OfXr7KDs8DUtcnde+58Xfy 9bvKZcmfGTOWrr+3Tvtyu+w0aYXHPB/Kj54Qanh5VGnhJianq9PyjNbteHsrKD3vdVFcl92r I99+b1U4/X3x4lLpfQ2m0SUzr03VjV1t883Ub0KmSc+ivfO3s6ivKtBZvfnb6ZWW54zk2Q/8 Cc5XYinOSDTUYi4qTgQAnOGbf68CAAA= Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 21:32:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562818F7ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpXaGF0IGlmIHRoZSByZW1vdGUgcGVlciBkb2VzIG5vdCBzdXBwb3J0L2luY2x1 ZGUgdGhlIHRscy1pZCBhdHRyaWJ1dGU/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206 IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJp YyBSZXNjb3JsYQ0KU2VudDogMDIgU2VwdGVtYmVyIDIwMTcgMjI6MzYNClRvOiBCZXJuYXJkIEFi b2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4NCkNjOiBtbXVzaWNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbTU1VU0lDXSBEVExTLVNEUCBhbmQgSlNFUCBDb25mbGljdHMNCg0KDQoNCk9uIFR1 ZSwgQXVnIDI5LCAyMDE3IGF0IDc6MDcgQU0sIEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFA Z21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gSXNz dWUgMSwgQWRhbSBzYWlkOg0KDQoiDQoxLiAgICAgIChJc3N1ZSAxYykgVGhlIGNydXggb2YgdGhl IG1hdHRlcjogZG9lcyBJQ0UgcmVzdGFydCBjYXVzZSBEVExTIHRvIHJlc3RhcnQ/IFRoZSBwcmlt YXJ5IHJhdGlvbmFsZSBvdXRsaW5lZCBpbiBSRkM1MjQ1IGZvciByZXN0YXJ0aW5nIElDRSBpcyBj aGFuZ2luZyB0aGUgZGVzdGluYXRpb24gKElQIGFkZHJlc3Mgb3IgcG9ydCkgb2YgYW4gb25nb2lu ZyBtZWRpYSBzdHJlYW0gLS0gd2hpY2ggd291bGQgY29tbW9ubHkgaW52b2x2ZSBjaGFuZ2luZyB0 byBhIGRpZmZlcmVudCBwaHlzaWNhbCBkZXZpY2UuIFdoaWxlIGl0IHdvdWxkLCBpbiB0aGVvcnks IGJlIHBvc3NpYmxlIHRvIHRyYW5zZmVyIHRoZSBUTFMgc3RhdGUgYXNzb2NpYXRlZCB3aXRoIHRo ZSBjb25uZWN0aW9uIGJldHdlZW4gZGV2aWNlcywgdGhpcyBpcyByYXRoZXIgY3VtYmVyc29tZSAo YW5kLCBhcyBmYXIgYXMgSSBrbm93LCBub3QgZ2VuZXJhbGx5IHN1cHBvcnRlZCBieSBUTFMgbGli cmFyaWVzKS4gRnJvbSB0aGF0IHBlcnNwZWN0aXZlLCBpdCBpcyBteSBvcGluaW9uIHRoYXQgdGhl IERUTFMtU0RQIGRvY3VtZW50IGlzIGNvcnJlY3QgdGhhdCBhbiBJQ0UgcmVzdGFydCBuZWNlc3Np dGF0ZXMgYSBuZXcgRFRMUyBjb25uZWN0aW9uOyBhbmQgSSBjb25jbHVkZSB0aGF0IEpTRVAgbmVl ZHMgdG8gY2hhbmdlLg0KIg0KDQpbQkFdIEFncmVlIHRoYXQgZm9yIGNvbnNpc3RlbmN5LCBpdCBp cyBiZXN0IGZvciBhbiBJQ0UgcmVzdGFydCB0byBuZWNlc3NpdGF0ZSBhIG5ldyBEVExTIGNvbm5l Y3Rpb24sIHNpbmNlIGFuIElDRSByZXN0YXJ0IGNhbiByZXN1bHQgaW4gY29ubmVjdGlvbiB0byBh IGRpZmZlcmVudCBkZXZpY2UgKGFuZCB0aGUgbmVlZCBmb3IgYSBuZXcgRFRMUyBjb25uZWN0aW9u KS4NCg0KSSdtIG5vdCBwZXJzdWFkZWQgYnkgdGhpczogdGhlIHByaW1hcnkgcmVhc29uIGZvciBh biBJQ0UgcmVzdGFydCBpcyBub3QgY2hhbmdpbmcgZGV2aWNlcyBidXQgcmF0aGVyIHRyeWluZyB0 byBkZWFsIHdpdGggdG9wb2xvZ3kgY2hhbmdlcyBhbmQvb3IgY29ubmVjdGl2aXR5IGNoZWNrIGZh aWx1cmVzLiBJZiB5b3UgYWN0dWFsbHkgKmRvKiBjaGFuZ2UgZGV2aWNlcywgdGhlbiBpdCdzIGFs c28gcXVpdGUgcHJvYmFibHkgeW91IHdpbGwgaGF2ZSBhIG5ldyBjZXJ0aWZpY2F0ZSBmaW5nZXJw cmludCwgaW4gd2hpY2ggY2FzZSB5b3Ugd2lsbCBnZXQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGlu IGFueSBjYXNlLiBJbiBvdGhlciB3b3JkcywgdGxzLWlkIHNob3VsZCBiZSB1c2VkIHRvIHNheSAi SSB3YW50IGEgbmV3IERUTFMgY29ubmVjdGlvbiBpbiBzcGl0ZSBvZiB0aGUgZmluZ2VycHJpbnQg YmVpbmcgdGhlIHNhbWUiICh3aGF0IEpTRVAgc2F5cyksIG5vdCAiSSB3YW50IHRvIGtlZXAgdGhl IERUTFMgY29ubmVjdGlvbiBldmVuIHRob3VnaCBJIGFtIGRvaW5nIGFuIElDRSByZXN0YXJ0Ig0K DQotRWtyDQoNCg0KT24gRnJpLCBBdWcgMjUsIDIwMTcgYXQgNDozMCBQTSwgQWRhbSBSb2FjaCA8 YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+IHdyb3RlOg0KDQpNTVVT SUMgLS0NCg0KW0kgd2lsbCBiZSBwb3N0aW5nIGEgc2VwYXJhdGUgbWVzc2FnZSB0byBSVENXRUIg ZGlyZWN0aW5nIGludGVyZXN0ZWQgcGFydGllcyB0byBkaXNjdXNzIHRoaXMgaXNzdWUgb24gdGhl IE1NVVNJQyBtYWlsaW5nIGxpc3RdDQoNCkR1cmluZyB0aGUgSUVTRyByZXZpZXcgb2YgZHJhZnQt aWV0Zi1tbXVzaWMtZHRscy1zZHAsIEVLUiBpZGVudGlmaWVkIHNvbWUgY29uZmxpY3RzIGJldHdl ZW4gdGhlIHByb2NlZHVyZXMgaW4gRFRMUy1TRFAgYW5kIEpTRVAgd2VyZSBpZGVudGlmaWVkLiBU aGlzIG5vdGUgaXMgYW4gYXR0ZW1wdCB0byBzdW1tYXJpemUgdGhlbS4gSSBoYXZlIGFsc28gbWFk ZSBhbiBpbml0aWFsIHByb3Bvc2FsLCBmb3IgZWFjaCBjb25mbGljdCwgcmVnYXJkaW5nIHdoaWNo IGRvY3VtZW50IG5lZWRzIHRvIGNoYW5nZSwgaW4gYW5kIHdoaWNoIHdheS4NCg0KSXNzdWUgMSAo cXVvdGluZyBFS1IpLCB3aGljaCByYWlzZXMgYSBjb3VwbGUgb2YgYWRkaXRpb25hbCBzdWItaXNz dWVzOg0KDQoxLiBBc3N1bWluZyBJIHVuZGVyc3RhbmQgdGhpcyBkb2N1bWVudCBjb3JyZWN0bHks IGl0IGNvbmZsaWN0cyB3aXRoDQoNCnRoZSBndWlkYW5jZSBpbiBKU0VQLiBTcGVjaWZpY2FsbHks IFMgNCBzYXlzOg0KDQoNCg0KICAgTm8gZGVmYXVsdCB2YWx1ZSBpcyBkZWZpbmVkIGZvciB0aGUg U0RQICd0bHMtaWQnIGF0dHJpYnV0ZS4NCg0KICAgSW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0 byB1c2UgdGhlIGF0dHJpYnV0ZSBNVVNUIGV4cGxpY2l0bHkNCg0KICAgaW5jbHVkZSBpdCBpbiBT RFAgb2ZmZXJzIGFuZCBhbnN3ZXJzLiAgSWYgYW4gb2ZmZXIgb3IgYW5zd2VyIGRvZXMgbm90DQoN CiAgIGNvbnRhaW4gYSAndGxzLWlkJyBhdHRyaWJ1dGUgKHRoaXMgY291bGQgaGFwcGVuIGlmIHRo ZSBvZmZlcmVyIG9yDQoNCiAgIGFuc3dlcmVyIHJlcHJlc2VudHMgYW4gZXhpc3RpbmcgaW1wbGVt ZW50YXRpb24gdGhhdCBoYXMgbm90IGJlZW4NCg0KICAgdXBkYXRlZCB0byBzdXBwb3J0IHRoZSAn dGxzLWlkJyBhdHRyaWJ1dGUpLCB1bmxlc3MgdGhlcmUgaXMgYW5vdGhlcg0KDQogICBtZWNoYW5p c20gdG8gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGF0IGEgbmV3IERUTFMgYXNzb2NpYXRpb24gaXMg dG8gYmUNCg0KICAgZXN0YWJsaXNoZWQsIGEgbW9kaWZpY2F0aW9uIG9mIG9uZSBvciBtb3JlIG9m IHRoZSBmb2xsb3dpbmcNCg0KICAgY2hhcmFjdGVyaXN0aWNzIE1VU1QgYmUgdHJlYXRlZCBhcyBh biBpbmRpY2F0aW9uIHRoYXQgYW4gZW5kcG9pbnQNCg0KICAgd2FudHMgdG8gZXN0YWJsaXNoIGEg bmV3IERUTFMgYXNzb2NpYXRpb246DQoNCg0KDQogICBvICBEVExTIHNldHVwIHJvbGU7IG9yDQoN Cg0KDQogICBvICBmaW5nZXJwcmludCBzZXQ7IG9yDQoNCg0KDQogICBvICBsb2NhbCB0cmFuc3Bv cnQgcGFyYW1ldGVyczsgb3INCg0KDQoNCiAgIG8gIElDRSB1ZnJhZyB2YWx1ZQ0KDQoNCg0KVGhp cyBzZWVtcyB0byBzYXkgdGhhdCBpZiB0aGVyZSBpcyBubyB0bHMtaWQgYXR0cmlidXRlLCB0aGVu IGFuIElDRSByZXN0YXJ0DQoNCih3aGljaCBuZWNlc3NpdGF0ZXMgYSB1ZnJhZyBjaGFuZ2UpIHJl cXVpcmVzIGEgRFRMUyByZXN0YXJ0LiBKU0VQIGlzbid0DQoNCmluY3JlZGlibHkgY2xlYXIgb24g dGhpcyBwb2ludCwgYnV0IDUuNy4zIHNlZW1zIHRvIHNheSB0aGF0IHRscy1pZA0KDQpuZWVkIG5v dCBiZSBwcmVzZW50Og0KDQoNCg0KICAgICAgKiAgdGxzLWlkIHZhbHVlLCB3aGljaCBNVVNUIGJl IHNldCBhY2NvcmRpbmcgdG8NCg0KICAgICAgICAgW0ktRC5pZXRmLW1tdXNpYy1kdGxzLXNkcF0s IFNlY3Rpb24gNS4gIElmIHRoaXMgaXMgYSByZS1vZmZlcg0KDQogICAgICAgICBhbmQgdGhlIHRs cy1pZCB2YWx1ZSBpcyBkaWZmZXJlbnQgZnJvbSB0aGF0IHByZXNlbnRseSBpbiB1c2UsDQoNCiAg ICAgICAgIHRoZSBEVExTIGNvbm5lY3Rpb24gaXMgbm90IGJlaW5nIGNvbnRpbnVlZCBhbmQgdGhl IHJlbW90ZQ0KDQogICAgICAgICBkZXNjcmlwdGlvbiBNVVNUIGJlIHBhcnQgb2YgYW4gSUNFIHJl c3RhcnQsIHRvZ2V0aGVyIHdpdGggbmV3DQoNCiAgICAgICAgIHVmcmFnIGFuZCBwYXNzd29yZCB2 YWx1ZXMuICBJZiB0aGlzIGlzIGFuIGFuc3dlciwgdGhlIHRscy1pZA0KDQogICAgICAgICB2YWx1 ZSwgaWYgcHJlc2VudCwgTVVTVCBiZSB0aGUgc2FtZSBhcyBpbiB0aGUgb2ZmZXIuDQoNCg0KDQpJ IGJlbGlldmUgdGhhdCB0aGUgZmlyc3Qgc2VudGVuY2UgaXMgaW4gZXJyb3IsIGFzIHdlIGNsZWFy bHkNCg0KY2FuJ3QgaGF2ZSBKU0VQIGltcGxlbWVudGF0aW9ucyByZXF1aXJpbmcgdGhhdCB0bHMt aWQgYmUgcHJlc2VudC4NCg0KDQoNCiAgIC4uLg0KDQoNCg0KICAgbyAgSWYgdGhlIHJlbW90ZSBE VExTIGZpbmdlcnByaW50IGhhcyBiZWVuIGNoYW5nZWQgb3IgdGhlIHRscy1pZCBoYXMNCg0KICAg ICAgY2hhbmdlZCwgdGVhciBkb3duIHRoZSBEVExTIGNvbm5lY3Rpb24uICBUaGlzIGluY2x1ZGVz IHRoZSBjYXNlDQoNCiAgICAgIHdoZW4gdGhlIFBlZXJDb25uZWN0aW9uIHN0YXRlIGlzICJoYXZl LXJlbW90ZS1wcmFuc3dlciIuICBJZiBhDQoNCiAgICAgIERUTFMgY29ubmVjdGlvbiBuZWVkcyB0 byBiZSB0b3JuIGRvd24gYnV0IHRoZSBhbnN3ZXIgZG9lcyBub3QNCg0KICAgICAgaW5kaWNhdGUg YW4gSUNFIHJlc3RhcnQgb3IsIGluIHRoZSBjYXNlIG9mICJoYXZlLXJlbW90ZS1wcmFuc3dlciIs DQoNCiAgICAgIG5ldyBJQ0UgY3JlZGVudGlhbHMsIGFuIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVk LiAgSWYgYW4gSUNFDQoNCiAgICAgIHJlc3RhcnQgaXMgcGVyZm9ybWVkIHdpdGhvdXQgYSBjaGFu Z2UgaW4gdGxzLWlkIG9yIGZpbmdlcnByaW50LA0KDQogICAgICB0aGVuIHRoZSBzYW1lIERUTFMg Y29ubmVjdGlvbiBpcyBjb250aW51ZWQgb3ZlciB0aGUgbmV3IElDRQ0KDQogICAgICBjaGFubmVs Lg0KDQoNCg0KSSB0aGluayB0aGUgYmVzdCBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIGlzIHRoYXQg aWYgdGxzLWlkIGlzIG5vdCBwcmVzZW50DQoNCihhbmQgaGVuY2UgdW5jaGFuZ2VkKSB0aGVuIElD RSByZXN0YXJ0IGRvZXMgbm90IGNhdXNlIERUTFMgcmVzdGFydC4NCg0KVGhpcyBpcyBhbHNvIG15 IG1lbW9yeSBvZiB0aGUgY29uc2Vuc3VzIGluIFJUQ1dFQi4gSW4gYW55IGNhc2UsIHRoZXNlDQoN CnR3byBkb2N1bWVudHMgY2xlYXJseSBtdXN0IG1hdGNoLg0KDQoNCg0KTXkgb2JzZXJ2YXRpb25z L3JlY29tbWVuZGF0aW9uczoNCg0KICAxLiAgKElzc3VlIDFhKSBFS1IgaXMgY29ycmVjdCB0aGF0 IHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgYnVsbGV0IGZyb20gSlNFUCBuZWVkcyB0byBiZSBy ZW1vdmVkIHNvIGFzIHRvIGVuYWJsZSBpbnRlcm9wZXJhdGlvbiB3aXRoIG5vbi1KU0VQIGltcGxl bWVudGF0aW9ucy4NCiAgMi4gIChJc3N1ZSAxYikgQWRkaXRpb25hbGx5IHRoZSBmaW5hbCBzZW50 ZW5jZSBvZiB0aGF0IGJ1bGxldCAoIklmIHRoaXMgaXMgYW4gYW5zd2VyLCB0aGUgdGxzLWlkIHZh bHVlLCBpZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBzYW1lIGFzIGluIHRoZSBvZmZlciIpIGNvbmZs aWN0cyB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIHRscy1pZCAoInRoZSBvZmZlcmVyIGFuZCBhbnN3 ZXJlciBnZW5lcmF0ZSB0aGVpciBvd24gbG9jYWwgJ3Rscy1pZCcgYXR0cmlidXRlIHZhbHVlcywg YW5kIHRoZSBjb21iaW5hdGlvbiBvZiBib3RoIHZhbHVlcyBpZGVudGlmeSB0aGUgRFRMUyBhc3Nv Y2lhdGlvbiIpLiBJbiB0aGlzIGNhc2UsIHRoZSBEVExTLVNEUCBkb2N1bWVudCB3b3VsZCBhcHBl YXIgdG8gYmUgY29ycmVjdCAodGhlIGZhY3QgdGhhdCB0aGUgdHdvIHBhcnRpZXMgY2hvb3NlIGRp ZmZlcmVudCBJRHMgaXMgaW50ZWdyYWwgdG8gdGhlIG1lY2hhbmlzbSdzIGRlc2lnbiksIHNvIEpT RVAgbmVlZHMgdG8gY2hhbmdlLg0KICAzLiAgKElzc3VlIDFjKSBUaGUgY3J1eCBvZiB0aGUgbWF0 dGVyOiBkb2VzIElDRSByZXN0YXJ0IGNhdXNlIERUTFMgdG8gcmVzdGFydD8gVGhlIHByaW1hcnkg cmF0aW9uYWxlIG91dGxpbmVkIGluIFJGQzUyNDUgZm9yIHJlc3RhcnRpbmcgSUNFIGlzIGNoYW5n aW5nIHRoZSBkZXN0aW5hdGlvbiAoSVAgYWRkcmVzcyBvciBwb3J0KSBvZiBhbiBvbmdvaW5nIG1l ZGlhIHN0cmVhbSAtLSB3aGljaCB3b3VsZCBjb21tb25seSBpbnZvbHZlIGNoYW5naW5nIHRvIGEg ZGlmZmVyZW50IHBoeXNpY2FsIGRldmljZS4gV2hpbGUgaXQgd291bGQsIGluIHRoZW9yeSwgYmUg cG9zc2libGUgdG8gdHJhbnNmZXIgdGhlIFRMUyBzdGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNv bm5lY3Rpb24gYmV0d2VlbiBkZXZpY2VzLCB0aGlzIGlzIHJhdGhlciBjdW1iZXJzb21lIChhbmQs IGFzIGZhciBhcyBJIGtub3csIG5vdCBnZW5lcmFsbHkgc3VwcG9ydGVkIGJ5IFRMUyBsaWJyYXJp ZXMpLiBGcm9tIHRoYXQgcGVyc3BlY3RpdmUsIGl0IGlzIG15IG9waW5pb24gdGhhdCB0aGUgRFRM Uy1TRFAgZG9jdW1lbnQgaXMgY29ycmVjdCB0aGF0IGFuIElDRSByZXN0YXJ0IG5lY2Vzc2l0YXRl cyBhIG5ldyBEVExTIGNvbm5lY3Rpb247IGFuZCBJIGNvbmNsdWRlIHRoYXQgSlNFUCBuZWVkcyB0 byBjaGFuZ2UuDQoNCg0KDQpJc3N1ZSAyIChxdW90aW5nIEVLUik6DQoNCjIuIFMgNCBzYXlzOg0K DQoNCg0KICAgVGhlIG11eCBjYXRlZ29yeSBbSS1ELmlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmli dXRlc10gZm9yIHRoZSAndGxzLQ0KDQogICBpZCcgYXR0cmlidXRlIGlzICdJREVOVElDQUwnLCB3 aGljaCBtZWFucyB0aGF0IHRoZSBhdHRyaWJ1dGUgdmFsdWUNCg0KICAgbXVzdCBiZSBpZGVudGlj YWwgYWNyb3NzIGFsbCBtZWRpYSBkZXNjcmlwdGlvbnMgYmVpbmcgbXVsdGlwbGV4ZWQNCg0KICAg W0ktRC5pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLW5lZ290aWF0aW9uXS4NCg0KDQoNClRoaXMgaXMg bm90IGFjdHVhbGx5IHdoYXQgSlNFUCByZXF1aXJlczoNCg0KDQoNCiAgIGRpZmZlcmVudCBjYXRl Z29yaWVzLiAgVG8gYXZvaWQgdW5uZWNlc3NhcnkgZHVwbGljYXRpb24gd2hlbg0KDQogICBidW5k bGluZywgYXR0cmlidXRlcyBvZiBjYXRlZ29yeSBJREVOVElDQUwgb3IgVFJBTlNQT1JUIE1VU1Qg Tk9UIGJlDQoNCiAgIHJlcGVhdGVkIGluIGJ1bmRsZWQgbT0gc2VjdGlvbnMsIHJlcGVhdGluZyB0 aGUgZ3VpZGFuY2UgZnJvbQ0KDQogICBbSS1ELmlldGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3Rp YXRpb25dLCBTZWN0aW9uIDguMS4gIFRoaXMgaW5jbHVkZXMNCg0KDQoNCkkgc3VzcGVjdCB0aGlz IGlzIG9sZCB0ZXh0Lg0KDQooSXNzdWUgMikgSlNFUCBpcyBhbGlnbmVkIHdpdGggZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbi0zOCwgd2hpbGUgRFRMUy1TRFAgZG9lcyBu b3QuIFRoaXMgaXMgYSBsYXJnZWx5IGFlc3RoZXRpYyBkZWNpc2lvbiAoYWx0aG91Z2ggdGhlIEpT RVAvQlVORExFIGFwcHJvYWNoIGRvZXMgc2F2ZSBhIHRpbnkgaGFuZGZ1bCBvZiBieXRlcyksIGJ1 dCBJIHRoaW5rIGNoYW5naW5nIG9uZSBkb2N1bWVudCAoRFRMUy1TRFApIG1ha2VzIG1vcmUgc2Vu c2UgdGhhbiBjaGFuZ2luZyB0d28uIChJIHN1c3BlY3QgdGhlIEJVTkRMRSBmb3JtdWxhdGlvbiBt b3JlIGNsb3NlbHkgdHJhY2tzIGNvbnNlbnN1cyBhbnl3YXkpLg0KDQoNCg0KL2ENCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5n IGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11 c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B562818F7ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCO30NCnNwYW4ubS05MjIwNjExNTkyMzk4NjI1ODk5aG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOm1fLTkyMjA2MTE1OTIzOTg2MjU4OTlob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM1ODE2NjkxNDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6OTUzMDUxNTY7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6Njgz NzUzNjI4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTU5NjkyNTMwNDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEVrciw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldoYXQgaWYgdGhlIHJlbW90ZSBwZWVyIGRv ZXMgbm90IHN1cHBvcnQvaW5jbHVkZSB0aGUgdGxzLWlkIGF0dHJpYnV0ZT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IDAyIFNlcHRlbWJlciAy MDE3IDIyOjM2PGJyPg0KPGI+VG86PC9iPiBCZXJuYXJkIEFib2JhICZsdDtiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gRFRMUy1TRFAgYW5kIEpTRVAgQ29uZmxpY3RzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgMjksIDIwMTcgYXQgNzowNyBBTSwgQmVy bmFyZCBBYm9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g SXNzdWUgMSwgQWRhbSBzYWlkOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny4yNXB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS41cHQiPihJc3N1ZSAxYykgVGhlIGNydXggb2YgdGhlIG1hdHRlcjog ZG9lcyBJQ0UgcmVzdGFydCBjYXVzZSBEVExTIHRvIHJlc3RhcnQ/IFRoZSBwcmltYXJ5IHJhdGlv bmFsZSBvdXRsaW5lZCBpbiBSRkM1MjQ1IGZvciByZXN0YXJ0aW5nIElDRSBpcyBjaGFuZ2luZyB0 aGUgZGVzdGluYXRpb24gKElQIGFkZHJlc3Mgb3IgcG9ydCkgb2YgYW4gb25nb2luZw0KIG1lZGlh IHN0cmVhbSAtLSB3aGljaCB3b3VsZCBjb21tb25seSBpbnZvbHZlIGNoYW5naW5nIHRvIGEgZGlm ZmVyZW50IHBoeXNpY2FsIGRldmljZS4gV2hpbGUgaXQgd291bGQsIGluIHRoZW9yeSwgYmUgcG9z c2libGUgdG8gdHJhbnNmZXIgdGhlIFRMUyBzdGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNvbm5l Y3Rpb24gYmV0d2VlbiBkZXZpY2VzLCB0aGlzIGlzIHJhdGhlciBjdW1iZXJzb21lIChhbmQsIGFz IGZhciBhcyBJIGtub3csIG5vdCBnZW5lcmFsbHkNCiBzdXBwb3J0ZWQgYnkgVExTIGxpYnJhcmll cykuIEZyb20gdGhhdCBwZXJzcGVjdGl2ZSwgaXQgaXMgbXkgb3BpbmlvbiB0aGF0IHRoZSBEVExT LVNEUCBkb2N1bWVudCBpcyBjb3JyZWN0IHRoYXQgYW4gSUNFIHJlc3RhcnQgbmVjZXNzaXRhdGVz IGEgbmV3IERUTFMgY29ubmVjdGlvbjsgYW5kIEkgY29uY2x1ZGUgdGhhdCBKU0VQIG5lZWRzIHRv IGNoYW5nZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPltCQV0gQWdyZWUgdGhhdCBmb3IgY29uc2lzdGVuY3ksIGl0IGlzIGJlc3QgZm9yIGFu IElDRSByZXN0YXJ0IHRvIG5lY2Vzc2l0YXRlIGEgbmV3IERUTFMgY29ubmVjdGlvbiwgc2luY2Ug YW4gSUNFIHJlc3RhcnQgY2FuIHJlc3VsdCBpbiBjb25uZWN0aW9uIHRvIGEgZGlmZmVyZW50IGRl dmljZSAoYW5kIHRoZSBuZWVkIGZvciBhIG5ldyBEVExTIGNvbm5lY3Rpb24pLiZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3QgcGVyc3VhZGVkIGJ5IHRoaXM6IHRoZSBwcmlt YXJ5IHJlYXNvbiBmb3IgYW4gSUNFIHJlc3RhcnQgaXMgbm90IGNoYW5naW5nIGRldmljZXMgYnV0 IHJhdGhlciB0cnlpbmcgdG8gZGVhbCB3aXRoIHRvcG9sb2d5IGNoYW5nZXMgYW5kL29yIGNvbm5l Y3Rpdml0eSBjaGVjayBmYWlsdXJlcy4gSWYgeW91IGFjdHVhbGx5ICpkbyogY2hhbmdlIGRldmlj ZXMsIHRoZW4gaXQncyBhbHNvIHF1aXRlIHByb2JhYmx5DQogeW91IHdpbGwgaGF2ZSBhIG5ldyBj ZXJ0aWZpY2F0ZSBmaW5nZXJwcmludCwgaW4gd2hpY2ggY2FzZSB5b3Ugd2lsbCBnZXQgYSBuZXcg RFRMUyBjb25uZWN0aW9uIGluIGFueSBjYXNlLiBJbiBvdGhlciB3b3JkcywgdGxzLWlkIHNob3Vs ZCBiZSB1c2VkIHRvIHNheSAmcXVvdDtJIHdhbnQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGluIHNw aXRlIG9mIHRoZSBmaW5nZXJwcmludCBiZWluZyB0aGUgc2FtZSZxdW90OyAod2hhdCBKU0VQIHNh eXMpLCBub3QgJnF1b3Q7SSB3YW50DQogdG8ga2VlcCB0aGUgRFRMUyBjb25uZWN0aW9uIGV2ZW4g dGhvdWdoIEkgYW0gZG9pbmcgYW4gSUNFIHJlc3RhcnQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBGcmksIEF1ZyAyNSwgMjAxNyBhdCA0OjMwIFBNLCBBZGFtIFJvYWNoICZsdDs8YSBocmVm PSJtYWlsdG86YWRhbUBub3N0cnVtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFkYW1Abm9zdHJ1bS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+TU1VU0lDIC0tPG86cD48L286cD48L3A+DQo8 cD5bSSB3aWxsIGJlIHBvc3RpbmcgYSBzZXBhcmF0ZSBtZXNzYWdlIHRvIFJUQ1dFQiBkaXJlY3Rp bmcgaW50ZXJlc3RlZCBwYXJ0aWVzIHRvIGRpc2N1c3MgdGhpcyBpc3N1ZSBvbiB0aGUgTU1VU0lD IG1haWxpbmcgbGlzdF08bzpwPjwvbzpwPjwvcD4NCjxwPkR1cmluZyB0aGUgSUVTRyByZXZpZXcg b2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAsIEVLUiBpZGVudGlmaWVkIHNvbWUgY29uZmxp Y3RzIGJldHdlZW4gdGhlIHByb2NlZHVyZXMgaW4gRFRMUy1TRFAgYW5kIEpTRVAgd2VyZSBpZGVu dGlmaWVkLiBUaGlzIG5vdGUgaXMgYW4gYXR0ZW1wdCB0byBzdW1tYXJpemUgdGhlbS4gSSBoYXZl IGFsc28gbWFkZSBhbiBpbml0aWFsIHByb3Bvc2FsLCBmb3IgZWFjaCBjb25mbGljdCwgcmVnYXJk aW5nDQogd2hpY2ggZG9jdW1lbnQgbmVlZHMgdG8gY2hhbmdlLCBpbiBhbmQgd2hpY2ggd2F5Ljxv OnA+PC9vOnA+PC9wPg0KPHA+SXNzdWUgMSAocXVvdGluZyBFS1IpLCB3aGljaCByYWlzZXMgYSBj b3VwbGUgb2YgYWRkaXRpb25hbCBzdWItaXNzdWVzOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjEu IEFzc3VtaW5nIEkgdW5kZXJzdGFuZCB0aGlzIGRvY3VtZW50IGNvcnJlY3RseSwgaXQgY29uZmxp Y3RzIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgZ3VpZGFuY2UgaW4gSlNFUC4gU3Bl Y2lmaWNhbGx5LCBTIDQgc2F5czo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgTm8gZGVmYXVsdCB2YWx1ZSBpcyBkZWZpbmVk IGZvciB0aGUgU0RQICd0bHMtaWQnIGF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgSW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0byB1c2UgdGhlIGF0dHJpYnV0 ZSBNVVNUIGV4cGxpY2l0bHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW5j bHVkZSBpdCBpbiBTRFAgb2ZmZXJzIGFuZCBhbnN3ZXJzLiZuYnNwOyBJZiBhbiBvZmZlciBvciBh bnN3ZXIgZG9lcyBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY29udGFp biBhICd0bHMtaWQnIGF0dHJpYnV0ZSAodGhpcyBjb3VsZCBoYXBwZW4gaWYgdGhlIG9mZmVyZXIg b3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYW5zd2VyZXIgcmVwcmVzZW50 cyBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiB0aGF0IGhhcyBub3QgYmVlbjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB1cGRhdGVkIHRvIHN1cHBvcnQgdGhlICd0bHMtaWQn IGF0dHJpYnV0ZSksIHVubGVzcyB0aGVyZSBpcyBhbm90aGVyPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IG1lY2hhbmlzbSB0byBleHBsaWNpdGx5IGluZGljYXRlIHRoYXQgYSBu ZXcgRFRMUyBhc3NvY2lhdGlvbiBpcyB0byBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyBlc3RhYmxpc2hlZCwgYSBtb2RpZmljYXRpb24gb2Ygb25lIG9yIG1vcmUgb2YgdGhl IGZvbGxvd2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjaGFyYWN0ZXJp c3RpY3MgTVVTVCBiZSB0cmVhdGVkIGFzIGFuIGluZGljYXRpb24gdGhhdCBhbiBlbmRwb2ludDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB3YW50cyB0byBlc3RhYmxpc2ggYSBu ZXcgRFRMUyBhc3NvY2lhdGlvbjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBEVExTIHNldHVwIHJvbGU7IG9y PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IG8mbmJzcDsgZmluZ2VycHJpbnQgc2V0OyBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDtvJm5ic3A7IGxv Y2FsIHRyYW5zcG9ydCBwYXJhbWV0ZXJzOyBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvJm5ic3A7IElDRSB1ZnJhZyB2 YWx1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PlRoaXMgc2VlbXMgdG8gc2F5IHRoYXQgaWYgdGhlcmUgaXMgbm8gdGxzLWlkIGF0dHJpYnV0ZSwg dGhlbiBhbiBJQ0UgcmVzdGFydDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPih3aGljaCBuZWNlc3Np dGF0ZXMgYSB1ZnJhZyBjaGFuZ2UpIHJlcXVpcmVzIGEgRFRMUyByZXN0YXJ0LiBKU0VQIGlzbid0 PG86cD48L286cD48L3ByZT4NCjxwcmU+aW5jcmVkaWJseSBjbGVhciBvbiB0aGlzIHBvaW50LCBi dXQgNS43LjMgc2VlbXMgdG8gc2F5IHRoYXQgdGxzLWlkPG86cD48L286cD48L3ByZT4NCjxwcmU+ bmVlZCBub3QgYmUgcHJlc2VudDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyB0 bHMtaWQgdmFsdWUsIHdoaWNoIE1VU1QgYmUgc2V0IGFjY29yZGluZyB0bzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBbSS1ELmlldGYtbW11c2ljLWR0bHMtc2RwXSwgU2VjdGlvbiA1LiZuYnNwOyBJZiB0aGlzIGlz IGEgcmUtb2ZmZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIHRoZSB0bHMtaWQgdmFsdWUgaXMgZGlmZmVy ZW50IGZyb20gdGhhdCBwcmVzZW50bHkgaW4gdXNlLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgRFRMUyBj b25uZWN0aW9uIGlzIG5vdCBiZWluZyBjb250aW51ZWQgYW5kIHRoZSByZW1vdGU8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGVzY3JpcHRpb24gTVVTVCBiZSBwYXJ0IG9mIGFuIElDRSByZXN0YXJ0LCB0b2dldGhl ciB3aXRoIG5ldzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1ZnJhZyBhbmQgcGFzc3dvcmQgdmFsdWVzLiZuYnNw OyBJZiB0aGlzIGlzIGFuIGFuc3dlciwgdGhlIHRscy1pZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSwg aWYgcHJlc2VudCwgTVVTVCBiZSB0aGUgc2FtZSBhcyBpbiB0aGUgb2ZmZXIuPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBiZWxpZXZlIHRoYXQg dGhlIGZpcnN0IHNlbnRlbmNlIGlzIGluIGVycm9yLCBhcyB3ZSBjbGVhcmx5PG86cD48L286cD48 L3ByZT4NCjxwcmU+Y2FuJ3QgaGF2ZSBKU0VQIGltcGxlbWVudGF0aW9ucyByZXF1aXJpbmcgdGhh dCB0bHMtaWQgYmUgcHJlc2VudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO28m bmJzcDsgSWYgdGhlIHJlbW90ZSBEVExTIGZpbmdlcnByaW50IGhhcyBiZWVuIGNoYW5nZWQgb3Ig dGhlIHRscy1pZCBoYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY2hhbmdlZCwgdGVhciBkb3duIHRoZSBEVExTIGNvbm5lY3Rpb24uJm5ic3A7 IFRoaXMgaW5jbHVkZXMgdGhlIGNhc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hlbiB0aGUgUGVlckNvbm5lY3Rpb24gc3RhdGUgaXMgJnF1 b3Q7aGF2ZS1yZW1vdGUtcHJhbnN3ZXImcXVvdDsuJm5ic3A7IElmIGE8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRFRMUyBjb25uZWN0aW9uIG5l ZWRzIHRvIGJlIHRvcm4gZG93biBidXQgdGhlIGFuc3dlciBkb2VzIG5vdDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRpY2F0ZSBhbiBJQ0Ug cmVzdGFydCBvciwgaW4gdGhlIGNhc2Ugb2YgJnF1b3Q7aGF2ZS1yZW1vdGUtcHJhbnN3ZXImcXVv dDssPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5ldyBJQ0UgY3JlZGVudGlhbHMsIGFuIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkLiZuYnNwOyBJ ZiBhbiBJQ0U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcmVzdGFydCBpcyBwZXJmb3JtZWQgd2l0aG91dCBhIGNoYW5nZSBpbiB0bHMtaWQgb3Ig ZmluZ2VycHJpbnQsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZW4gdGhlIHNhbWUgRFRMUyBjb25uZWN0aW9uIGlzIGNvbnRpbnVlZCBvdmVy IHRoZSBuZXcgSUNFPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNoYW5uZWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkgdGhpbmsgdGhlIGJlc3Qg aW50ZXJwcmV0YXRpb24gb2YgdGhpcyBpcyB0aGF0IGlmIHRscy1pZCBpcyBub3QgcHJlc2VudDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPihhbmQgaGVuY2UgdW5jaGFuZ2VkKSB0aGVuIElDRSByZXN0 YXJ0IGRvZXMgbm90IGNhdXNlIERUTFMgcmVzdGFydC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5U aGlzIGlzIGFsc28gbXkgbWVtb3J5IG9mIHRoZSBjb25zZW5zdXMgaW4gUlRDV0VCLiBJbiBhbnkg Y2FzZSwgdGhlc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50d28gZG9jdW1lbnRzIGNsZWFybHkg bXVzdCBtYXRjaC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cD5NeSBvYnNlcnZhdGlvbnMvcmVjb21tZW5kYXRpb25zOjxvOnA+PC9v OnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPg0KKElzc3VlIDFhKSBFS1IgaXMgY29ycmVjdCB0aGF0IHRoZSBm aXJzdCBzZW50ZW5jZSBvZiB0aGUgYnVsbGV0IGZyb20gSlNFUCBuZWVkcyB0byBiZSByZW1vdmVk IHNvIGFzIHRvIGVuYWJsZSBpbnRlcm9wZXJhdGlvbiB3aXRoIG5vbi1KU0VQIGltcGxlbWVudGF0 aW9ucy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDttc28tbGlzdDpsMSBsZXZlbDEg bGZvMiI+DQooSXNzdWUgMWIpIEFkZGl0aW9uYWxseSB0aGUgZmluYWwgc2VudGVuY2Ugb2YgdGhh dCBidWxsZXQgKCZxdW90O0lmIHRoaXMgaXMgYW4gYW5zd2VyLCB0aGUgdGxzLWlkIHZhbHVlLCBp ZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBzYW1lIGFzIGluIHRoZSBvZmZlciZxdW90OykgY29uZmxp Y3RzIHdpdGggdGhlIGRlZmluaXRpb24gb2YgdGxzLWlkICgmcXVvdDt0aGUgb2ZmZXJlciBhbmQg YW5zd2VyZXIgZ2VuZXJhdGUgdGhlaXIgb3duIGxvY2FsICd0bHMtaWQnIGF0dHJpYnV0ZQ0KIHZh bHVlcywgYW5kIHRoZSBjb21iaW5hdGlvbiBvZiBib3RoIHZhbHVlcyBpZGVudGlmeSB0aGUgRFRM UyBhc3NvY2lhdGlvbiZxdW90OykuIEluIHRoaXMgY2FzZSwgdGhlIERUTFMtU0RQIGRvY3VtZW50 IHdvdWxkIGFwcGVhciB0byBiZSBjb3JyZWN0ICh0aGUgZmFjdCB0aGF0IHRoZSB0d28gcGFydGll cyBjaG9vc2UgZGlmZmVyZW50IElEcyBpcyBpbnRlZ3JhbCB0byB0aGUgbWVjaGFuaXNtJ3MgZGVz aWduKSwgc28gSlNFUCBuZWVkcyB0byBjaGFuZ2UuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KKElzc3VlIDFjKSBUaGUgY3J1 eCBvZiB0aGUgbWF0dGVyOiBkb2VzIElDRSByZXN0YXJ0IGNhdXNlIERUTFMgdG8gcmVzdGFydD8g VGhlIHByaW1hcnkgcmF0aW9uYWxlIG91dGxpbmVkIGluIFJGQzUyNDUgZm9yIHJlc3RhcnRpbmcg SUNFIGlzIGNoYW5naW5nIHRoZSBkZXN0aW5hdGlvbiAoSVAgYWRkcmVzcyBvciBwb3J0KSBvZiBh biBvbmdvaW5nIG1lZGlhIHN0cmVhbSAtLSB3aGljaCB3b3VsZCBjb21tb25seSBpbnZvbHZlIGNo YW5naW5nIHRvIGENCiBkaWZmZXJlbnQgcGh5c2ljYWwgZGV2aWNlLiBXaGlsZSBpdCB3b3VsZCwg aW4gdGhlb3J5LCBiZSBwb3NzaWJsZSB0byB0cmFuc2ZlciB0aGUgVExTIHN0YXRlIGFzc29jaWF0 ZWQgd2l0aCB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIGRldmljZXMsIHRoaXMgaXMgcmF0aGVyIGN1 bWJlcnNvbWUgKGFuZCwgYXMgZmFyIGFzIEkga25vdywgbm90IGdlbmVyYWxseSBzdXBwb3J0ZWQg YnkgVExTIGxpYnJhcmllcykuIEZyb20gdGhhdCBwZXJzcGVjdGl2ZSwNCiBpdCBpcyBteSBvcGlu aW9uIHRoYXQgdGhlIERUTFMtU0RQIGRvY3VtZW50IGlzIGNvcnJlY3QgdGhhdCBhbiBJQ0UgcmVz dGFydCBuZWNlc3NpdGF0ZXMgYSBuZXcgRFRMUyBjb25uZWN0aW9uOyBhbmQgSSBjb25jbHVkZSB0 aGF0IEpTRVAgbmVlZHMgdG8gY2hhbmdlLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHA+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cD5Jc3N1ZSAyIChxdW90aW5nIEVLUik6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwcmU+Mi4gUyA0IHNheXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBtdXggY2F0ZWdvcnkgW0ktRC5pZXRm LW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXNdIGZvciB0aGUgJ3Rscy08bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgaWQnIGF0dHJpYnV0ZSBpcyAnSURFTlRJQ0FMJywgd2hpY2gg bWVhbnMgdGhhdCB0aGUgYXR0cmlidXRlIHZhbHVlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IG11c3QgYmUgaWRlbnRpY2FsIGFjcm9zcyBhbGwgbWVkaWEgZGVzY3JpcHRpb25z IGJlaW5nIG11bHRpcGxleGVkPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFtJ LUQuaWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbl0uPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBpcyBub3QgYWN0dWFsbHkg d2hhdCBKU0VQIHJlcXVpcmVzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgY2F0ZWdvcmllcy4mbmJzcDsg VG8gYXZvaWQgdW5uZWNlc3NhcnkgZHVwbGljYXRpb24gd2hlbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBidW5kbGluZywgYXR0cmlidXRlcyBvZiBjYXRlZ29yeSBJREVOVElD QUwgb3IgVFJBTlNQT1JUIE1VU1QgTk9UIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHJlcGVhdGVkIGluIGJ1bmRsZWQgbT0gc2VjdGlvbnMsIHJlcGVhdGluZyB0aGUgZ3Vp ZGFuY2UgZnJvbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBbSS1ELmlldGYt bW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpb25dLCBTZWN0aW9uIDguMS4mbmJzcDsgVGhpcyBp bmNsdWRlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPkkgc3VzcGVjdCB0aGlzIGlzIG9sZCB0ZXh0LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cD48YnI+DQooSXNzdWUgMikgSlNFUCBpcyBhbGlnbmVkIHdpdGggZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbi0zOCwgd2hpbGUgRFRMUy1TRFAgZG9lcyBu b3QuIFRoaXMgaXMgYSBsYXJnZWx5IGFlc3RoZXRpYyBkZWNpc2lvbiAoYWx0aG91Z2ggdGhlIEpT RVAvQlVORExFIGFwcHJvYWNoIGRvZXMgc2F2ZSBhIHRpbnkgaGFuZGZ1bCBvZiBieXRlcyksIGJ1 dCBJIHRoaW5rIGNoYW5naW5nIG9uZSBkb2N1bWVudCAoRFRMUy1TRFApIG1ha2VzDQogbW9yZSBz ZW5zZSB0aGFuIGNoYW5naW5nIHR3by4gKEkgc3VzcGVjdCB0aGUgQlVORExFIGZvcm11bGF0aW9u IG1vcmUgY2xvc2VseSB0cmFja3MgY29uc2Vuc3VzIGFueXdheSkuPG86cD48L286cD48L3A+DQo8 cD48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi9hPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B562818F7ESESSMB109erics_-- From nobody Sat Sep 2 15:01:00 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7914133087 for ; Sat, 2 Sep 2017 15:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRJrx9UCiiLC for ; Sat, 2 Sep 2017 15:00:56 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F030F133075 for ; Sat, 2 Sep 2017 15:00:55 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h127so13156148ywf.3 for ; Sat, 02 Sep 2017 15:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZiBVG8yPwnM5+3AEm0Tk46B59I8VoRLQev4KO0fRST4=; b=OaVXLcrfZlsEVPdYLGyuR7g8NmkLjtXcpjqzT/USoJ2CZ6zH8QlG82LIAe0hFE2oKw K37AxSt9WFzbS9Y2DUwjuaCl8+84UH0MiMMSdGs2zIaFOLpLmpPfdUYmFDdyqDcZ0NJP FhZWveXudvqdrhhPkdWV0wZBCvvkHwTzs/3uqffNCELLGm6rvZxCQtBxwVZ+ghrgPfni c3zZ7OilpIXHzZvdCs0T5CqN8PhxzdT939Y8tOLUV1hRYaR1QAdTz6jW+MVTZp/2jLPn yQGlI8HXkgMrT23Bydbwm+/fBr+roohBP6WbyeWYLGA+O2qwykafGae+m6ISO+27iKyS 4iew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZiBVG8yPwnM5+3AEm0Tk46B59I8VoRLQev4KO0fRST4=; b=rz2wjsGNPALj2jEKC/n9v/Sdygu2gxLeKcZ/Mfdx37P9BxI+VXJWgSqcZ/gkvZueFm IE2bVzhZhpb6EAnww0QMSot3eSaby24//pp3JmniCyvszAaiJECEETHFPAtoT7qy44qw YSSYCD++CwNRWDRci/Cq9eCylXl/5Vqfw5By8J5HZuz4uTXPq8pXyEroLMPLkTWDPtoN 1nUiJLJLVzaNkg/7XrEttdsn0GKuqw254wLJE4+GMMQxfb5+qd65FKC1rgYvNQ0yRXHL KS+sjPH9Nm71CuCTH0MVFepEtg5MqPGovKkM3IARtt2tUu4UWOsWEYPnLeSRsgKkYU+O 4zaA== X-Gm-Message-State: AHPjjUiO66wtVUez6ilGJx76mn1u+x58hD910l/QnDSUWJrBIEP2+s6t +z3APEX4/xSSYHmK9B5rBgvJf3Y3UN5m X-Google-Smtp-Source: ADKCNb4XMA/bAy9tcKigsD+ERYvQTOww20LNwmBLomw2GBzpUcmnxSn12Hv01JM2n7edjYv5kAmm6iiTvj1NN1TjrL0= X-Received: by 10.13.204.66 with SMTP id o63mr5869276ywd.321.1504389653635; Sat, 02 Sep 2017 15:00:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sat, 2 Sep 2017 15:00:13 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Sat, 2 Sep 2017 16:00:13 -0600 Message-ID: To: Christer Holmberg Cc: Bernard Aboba , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a114f25d2e8bc0405583c02e1" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 22:00:59 -0000 --001a114f25d2e8bc0405583c02e1 Content-Type: text/plain; charset="UTF-8" Yes. Indeed, that's the crux of the disagreement between JSEP and this document -Ekr On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Ekr, > > > > What if the remote peer does not support/include the tls-id attribute? > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* 02 September 2017 22:36 > *To:* Bernard Aboba > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] DTLS-SDP and JSEP Conflicts > > > > > > > > On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba > wrote: > > On Issue 1, Adam said: > > > > " > > 1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. While > it would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From that perspective, it > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > " > > > > [BA] Agree that for consistency, it is best for an ICE restart to > necessitate a new DTLS connection, since an ICE restart can result in > connection to a different device (and the need for a new DTLS connection). > > > > I'm not persuaded by this: the primary reason for an ICE restart is not > changing devices but rather trying to deal with topology changes and/or > connectivity check failures. If you actually *do* change devices, then it's > also quite probably you will have a new certificate fingerprint, in which > case you will get a new DTLS connection in any case. In other words, tls-id > should be used to say "I want a new DTLS connection in spite of the > fingerprint being the same" (what JSEP says), not "I want to keep the DTLS > connection even though I am doing an ICE restart" > > > > -Ekr > > > > > > On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: > > MMUSIC -- > > [I will be posting a separate message to RTCWEB directing interested > parties to discuss this issue on the MMUSIC mailing list] > > During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some > conflicts between the procedures in DTLS-SDP and JSEP were identified. This > note is an attempt to summarize them. I have also made an initial proposal, > for each conflict, regarding which document needs to change, in and which > way. > > Issue 1 (quoting EKR), which raises a couple of additional sub-issues: > > 1. Assuming I understand this document correctly, it conflicts with > > the guidance in JSEP. Specifically, S 4 says: > > > > No default value is defined for the SDP 'tls-id' attribute. > > Implementations that wish to use the attribute MUST explicitly > > include it in SDP offers and answers. If an offer or answer does not > > contain a 'tls-id' attribute (this could happen if the offerer or > > answerer represents an existing implementation that has not been > > updated to support the 'tls-id' attribute), unless there is another > > mechanism to explicitly indicate that a new DTLS association is to be > > established, a modification of one or more of the following > > characteristics MUST be treated as an indication that an endpoint > > wants to establish a new DTLS association: > > > > o DTLS setup role; or > > > > o fingerprint set; or > > > > o local transport parameters; or > > > > o ICE ufrag value > > > > This seems to say that if there is no tls-id attribute, then an ICE restart > > (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't > > incredibly clear on this point, but 5.7.3 seems to say that tls-id > > need not be present: > > > > * tls-id value, which MUST be set according to > > [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer > > and the tls-id value is different from that presently in use, > > the DTLS connection is not being continued and the remote > > description MUST be part of an ICE restart, together with new > > ufrag and password values. If this is an answer, the tls-id > > value, if present, MUST be the same as in the offer. > > > > I believe that the first sentence is in error, as we clearly > > can't have JSEP implementations requiring that tls-id be present. > > > > ... > > > > o If the remote DTLS fingerprint has been changed or the tls-id has > > changed, tear down the DTLS connection. This includes the case > > when the PeerConnection state is "have-remote-pranswer". If a > > DTLS connection needs to be torn down but the answer does not > > indicate an ICE restart or, in the case of "have-remote-pranswer", > > new ICE credentials, an error MUST be generated. If an ICE > > restart is performed without a change in tls-id or fingerprint, > > then the same DTLS connection is continued over the new ICE > > channel. > > > > I think the best interpretation of this is that if tls-id is not present > > (and hence unchanged) then ICE restart does not cause DTLS restart. > > This is also my memory of the consensus in RTCWEB. In any case, these > > two documents clearly must match. > > > > My observations/recommendations: > > 1. (Issue 1a) EKR is correct that the first sentence of the bullet > from JSEP needs to be removed so as to enable interoperation with non-JSEP > implementations. > 2. (Issue 1b) Additionally the final sentence of that bullet ("If this > is an answer, the tls-id value, if present, MUST be the same as in the > offer") conflicts with the definition of tls-id ("the offerer and answerer > generate their own local 'tls-id' attribute values, and the combination of > both values identify the DTLS association"). In this case, the DTLS-SDP > document would appear to be correct (the fact that the two parties choose > different IDs is integral to the mechanism's design), so JSEP needs to > change. > 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. While > it would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From that perspective, it > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > > > Issue 2 (quoting EKR): > > 2. S 4 says: > > > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- > > id' attribute is 'IDENTICAL', which means that the attribute value > > must be identical across all media descriptions being multiplexed > > [I-D.ietf-mmusic-sdp-bundle-negotiation]. > > > > This is not actually what JSEP requires: > > > > different categories. To avoid unnecessary duplication when > > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > > repeated in bundled m= sections, repeating the guidance from > > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes > > > > I suspect this is old text. > > > (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, > while DTLS-SDP does not. This is a largely aesthetic decision (although the > JSEP/BUNDLE approach does save a tiny handful of bytes), but I think > changing one document (DTLS-SDP) makes more sense than changing two. (I > suspect the BUNDLE formulation more closely tracks consensus anyway). > > > > /a > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --001a114f25d2e8bc0405583c02e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. Indeed, that's the crux of the disagreement = between JSEP and this document

-Ekr

=

On Sa= t, Sep 2, 2017 at 3:31 PM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:

Hi Ekr,

=C2=A0

What if the remote peer does not supp= ort/include the tls-id attribute?

=C2=A0

Regards,

=C2=A0

Christer

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:

On Issue 1, Adam said:=C2=A0

=C2=A0

"

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Issue 1c) The = crux of the matter: does ICE restart cause DTLS to restart? The primary rat= ionale outlined in RFC5245 for restarting ICE is changing the destination (= IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physi= cal device. While it would, in theory, be possible to transfer the TLS stat= e associated with the connection between devices, this is rather cumbersome= (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that = the DTLS-SDP document is correct that an ICE restart necessitates a new DTL= S connection; and I conclude that JSEP needs to change.

"

=C2=A0

[BA] Agree that for consistency, it is best for an I= CE restart to necessitate a new DTLS connection, since an ICE restart can r= esult in connection to a different device (and the need for a new DTLS conn= ection).=C2=A0=C2=A0

=C2=A0

I'm not persuaded by this: the primary reason fo= r an ICE restart is not changing devices but rather trying to deal with top= ology changes and/or connectivity check failures. If you actually *do* chan= ge devices, then it's also quite probably you will have a new certificate fingerprint, in which case you will get a = new DTLS connection in any case. In other words, tls-id should be used to s= ay "I want a new DTLS connection in spite of the fingerprint being the= same" (what JSEP says), not "I want to keep the DTLS connection even though I am doing an ICE restart"=

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <adam@nostrum.com> = wrote:

MMUSIC --

[I will be posting a separate message to RTCWEB directing interested par= ties to discuss this issue on the MMUSIC mailing list]

During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified som= e conflicts between the procedures in DTLS-SDP and JSEP were identified. Th= is note is an attempt to summarize them. I have also made an initial propos= al, for each conflict, regarding which document needs to change, in and which way.

Issue 1 (quoting EKR), which raises a couple of additional sub-issues:

1. Assuming I understand this document correctly, it conflicts with=

the guidance in JSEP. Specifically, S 4 says:
=C2=A0
=C2=A0=C2=A0 No default value is defined for the SDP 'tls-id' =
attribute.
=C2=A0=C2=A0 Implementations that wish to use the attribute MUST expli=
citly
=C2=A0=C2=A0 include it in SDP offers and answers.=C2=A0 If an offer o=
r answer does not
=C2=A0=C2=A0 contain a 'tls-id' attribute (this could happen i=
f the offerer or
=C2=A0=C2=A0 answerer represents an existing implementation that has n=
ot been
=C2=A0=C2=A0 updated to support the 'tls-id' attribute), unles=
s there is another
=C2=A0=C2=A0 mechanism to explicitly indicate that a new DTLS associat=
ion is to be
=C2=A0=C2=A0 established, a modification of one or more of the followi=
ng
=C2=A0=C2=A0 characteristics MUST be treated as an indication that an =
endpoint
=C2=A0=C2=A0 wants to establish a new DTLS association:<=
/pre>

=C2=A0


=C2=A0=C2=A0 o=C2=A0 DTLS setup role; or


=C2=A0


=C2=A0=C2=A0 o=C2=A0 fingerprint set; or


=C2=A0


 =C2=A0=C2=A0o=C2=A0 local transport parameters; or

=C2=A0


=C2=A0=C2=A0 o=C2=A0 ICE ufrag value


=C2=A0


This seems to say that if there is no tls-id attribute, then an ICE re=
start


(which necessitates a ufrag change) requires a DTLS restart. JSEP isn&=
#39;t


incredibly clear on this point, but 5.7.3 seems to say that tls-id<=
/u>


need not be present:


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 tls-id value, which MUST be set=
 according to


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [I-D.ietf-mmusic-dtls=
-sdp], Section 5.=C2=A0 If this is a re-offer


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the tls-id value =
is different from that presently in use,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the DTLS connection i=
s not being continued and the remote


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description MUST be p=
art of an ICE restart, together with new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ufrag and password va=
lues.=C2=A0 If this is an answer, the tls-id


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value, if present, MU=
ST be the same as in the offer.


=C2=A0


I believe that the first sentence is in error, as we clearly=



can't have JSEP implementations requiring that tls-id be present.<=
u>


=C2=A0


=C2=A0=C2=A0 ...


=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0o=C2=A0 If the remote DTLS fingerprint has been chan=
ged or the tls-id has


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 changed, tear down the DTLS connection.=
=C2=A0 This includes the case


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when the PeerConnection state is "=
have-remote-pranswer".=C2=A0 If a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DTLS connection needs to be torn down b=
ut the answer does not


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indicate an ICE restart or, in the case=
 of "have-remote-pranswer",


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 new ICE credentials, an error MUST be g=
enerated.=C2=A0 If an ICE


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 restart is performed without a change i=
n tls-id or fingerprint,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then the same DTLS connection is contin=
ued over the new ICE


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 channel.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 


I think the best interpretation of this is that if tls-id is not prese=
nt


(and hence unchanged) then ICE restart does not cause DTLS restart.=



This is also my memory of the consensus in RTCWEB. In any case, these<=
u>


two documents clearly must match.

=C2=A0

My observations/recommendations:

  1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP n= eeds to be removed so as to enable interoperation with non-JSEP implementat= ions.
  2. (Issue 1b) Additionally the final sentence of that bullet ("If this is= an answer, the tls-id value, if present, MUST be the same as in the offer&= quot;) conflicts with the definition of tls-id ("the offerer and answe= rer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association&q= uot;). In this case, the DTLS-SDP document would appear to be correct (the = fact that the two parties choose different IDs is integral to the mechanism= 's design), so JSEP needs to change.
  3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? = The primary rationale outlined in RFC5245 for restarting ICE is changing th= e destination (IP address or port) of an ongoing media stream -- which woul= d commonly involve changing to a different physical device. While it would, in theory, be possible to trans= fer the TLS state associated with the connection between devices, this is r= ather cumbersome (and, as far as I know, not generally supported by TLS lib= raries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart= necessitates a new DTLS connection; and I conclude that JSEP needs to chan= ge.

=C2=A0

Issue 2 (quoting EKR):

2. S 4 says:
=C2=A0
=C2=A0=C2=A0 The mux category [I-D.ietf-mmusic-sdp-mux-attributes=
] for the 'tls-
=C2=A0=C2=A0 id' attribute is 'IDENTICAL', which means tha=
t the attribute value
=C2=A0=C2=A0 must be identical across all media descriptions being mul=
tiplexed
=C2=A0=C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiation].<=
/u>
=C2=A0
This is not actually what JSEP requires:
=C2=A0
=C2=A0=C2=A0 different categories.=C2=A0 To avoid unnecessary duplicat=
ion when
=C2=A0=C2=A0 bundling, attributes of category IDENTICAL or TRANSPORT M=
UST NOT be
=C2=A0=C2=A0 repeated in bundled m=3D sections, repeating the guidance=
 from
=C2=A0=C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.=
1.=C2=A0 This includes
=C2=A0
I suspect this is old text.


(Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiatio= n-38, while DTLS-SDP does not. This is a largely aesthetic decision (althou= gh the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think= changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more close= ly tracks consensus anyway).

=C2=A0

/a

=C2=A0

_____________________= __________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

=C2=A0


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

=C2=A0


--001a114f25d2e8bc0405583c02e1-- From nobody Sat Sep 2 22:51:51 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5158126D0C for ; Sat, 2 Sep 2017 22:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fEHFwsnl94XQ for ; Sat, 2 Sep 2017 22:51:46 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 E10AD126BFD for ; Sat, 2 Sep 2017 22:51:45 -0700 (PDT) X-AuditID: c1b4fb2d-103ff700000057a4-e0-59ab986f47c0 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.F6.22436.F689BA95; Sun, 3 Sep 2017 07:51:43 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Sun, 3 Sep 2017 07:51:42 +0200 From: Christer Holmberg To: Eric Rescorla CC: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKbMmOAgAbGf4CAADCNsP//5vyAgACksAA= Date: Sun, 3 Sep 2017 05:51:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B56282B43ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7n27+jNWRBrdnilps2Pef2WLF63Ps FlOXP2ZxYPbYOesuu8eSJT+ZPCY/bmMOYI7isklJzcksSy3St0vgyvi2aDVjwZsjTBWTz11l amBcs4epi5GTQ0LARGLr609ANheHkMARRollnT9YIJzFjBLTtl1h7mLk4GATsJDo/qcN0iAi oCDx688JFhCbWSBIoql/IQtIibCAocTp+0YQJUYSl48/AOsUEfCTePxUBCTMIqAi8eflU7C1 vAK+EqsaDzFCbLrOJLF6QT8zSIJTIFDi1aIvYOMZBcQkvp9awwSxSlzi1pP5UDcLSCzZc54Z whaVePn4HyuErSSxYvslRoj6fIn+O99YIZYJSpyc+YRlAqPILCSjZiEpm4WkbBbQ2cwCmhLr d+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgrB3c 8lt3B+Pq146HGAU4GJV4eFnrVkcKsSaWFVfmHmKU4GBWEuHdNAUoxJuSWFmVWpQfX1Sak1p8 iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dUAyPjjqDSNRfzxSrztlTwbF6kaZJW8/Gw 9PkZkU9Kjzeo7ylYrXkoLLP3zKV6TqljImwFq+pkb7wNWiNoJGuT/PbdhyWCk5zcbk+anf7x zKNdpTFfHtt2Gc93X/7K94i1+C/BrwkyClt42oW52vab2izlEtoqz5IRf+3ybxOL1Kk5EZoH kyZvvK3EUpyRaKjFXFScCAB66fYSsQIAAA== Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 05:51:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B56282B43ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5ZZXMuIEluZGVlZCwgdGhhdCdzIHRoZSBjcnV4IG9mIHRoZSBkaXNhZ3JlZW1lbnQg YmV0d2VlbiBKU0VQIGFuZCB0aGlzIGRvY3VtZW50DQoNClNvLCBqdXN0IHRvIGNsYXJpZnk6IGlu IHlvdXIgb3BpbmlvbiwgaWYgYW4gZW5kcG9pbnQgcmVjZWl2ZXMgYW4gb2ZmZXIvYW5zd2VyIFdJ VEhPVVQgYSB0bHMtaWQsIGJ1dCB3aXRoIGEgTkVXIHVmcmFnIChyZWFkOiBJQ0UgcmVzdGFydCks IHRoZSBuZXcgdXJmYWcgd2lsbCBOT1QgdHJpZ2dlciBhIG5ldyBEVExTIGFzc29jaWF0aW9uLiBS aWdodD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIFNhdCwgU2VwIDIsIDIwMTcg YXQgMzozMSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBF a3IsDQoNCldoYXQgaWYgdGhlIHJlbW90ZSBwZWVyIGRvZXMgbm90IHN1cHBvcnQvaW5jbHVkZSB0 aGUgdGxzLWlkIGF0dHJpYnV0ZT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogbW11 c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpYy1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IDAyIFNlcHRlbWJl ciAyMDE3IDIyOjM2DQpUbzogQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208 bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj4NCkNjOiBtbXVzaWNAaWV0Zi5vcmc8bWFp bHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEVExTLVNEUCBhbmQg SlNFUCBDb25mbGljdHMNCg0KDQoNCk9uIFR1ZSwgQXVnIDI5LCAyMDE3IGF0IDc6MDcgQU0sIEJl cm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gSXNzdWUgMSwgQWRhbSBzYWlkOg0KDQoiDQoxLiAgICAg IChJc3N1ZSAxYykgVGhlIGNydXggb2YgdGhlIG1hdHRlcjogZG9lcyBJQ0UgcmVzdGFydCBjYXVz ZSBEVExTIHRvIHJlc3RhcnQ/IFRoZSBwcmltYXJ5IHJhdGlvbmFsZSBvdXRsaW5lZCBpbiBSRkM1 MjQ1IGZvciByZXN0YXJ0aW5nIElDRSBpcyBjaGFuZ2luZyB0aGUgZGVzdGluYXRpb24gKElQIGFk ZHJlc3Mgb3IgcG9ydCkgb2YgYW4gb25nb2luZyBtZWRpYSBzdHJlYW0gLS0gd2hpY2ggd291bGQg Y29tbW9ubHkgaW52b2x2ZSBjaGFuZ2luZyB0byBhIGRpZmZlcmVudCBwaHlzaWNhbCBkZXZpY2Uu IFdoaWxlIGl0IHdvdWxkLCBpbiB0aGVvcnksIGJlIHBvc3NpYmxlIHRvIHRyYW5zZmVyIHRoZSBU TFMgc3RhdGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gZGV2aWNlcywg dGhpcyBpcyByYXRoZXIgY3VtYmVyc29tZSAoYW5kLCBhcyBmYXIgYXMgSSBrbm93LCBub3QgZ2Vu ZXJhbGx5IHN1cHBvcnRlZCBieSBUTFMgbGlicmFyaWVzKS4gRnJvbSB0aGF0IHBlcnNwZWN0aXZl LCBpdCBpcyBteSBvcGluaW9uIHRoYXQgdGhlIERUTFMtU0RQIGRvY3VtZW50IGlzIGNvcnJlY3Qg dGhhdCBhbiBJQ0UgcmVzdGFydCBuZWNlc3NpdGF0ZXMgYSBuZXcgRFRMUyBjb25uZWN0aW9uOyBh bmQgSSBjb25jbHVkZSB0aGF0IEpTRVAgbmVlZHMgdG8gY2hhbmdlLg0KIg0KDQpbQkFdIEFncmVl IHRoYXQgZm9yIGNvbnNpc3RlbmN5LCBpdCBpcyBiZXN0IGZvciBhbiBJQ0UgcmVzdGFydCB0byBu ZWNlc3NpdGF0ZSBhIG5ldyBEVExTIGNvbm5lY3Rpb24sIHNpbmNlIGFuIElDRSByZXN0YXJ0IGNh biByZXN1bHQgaW4gY29ubmVjdGlvbiB0byBhIGRpZmZlcmVudCBkZXZpY2UgKGFuZCB0aGUgbmVl ZCBmb3IgYSBuZXcgRFRMUyBjb25uZWN0aW9uKS4NCg0KSSdtIG5vdCBwZXJzdWFkZWQgYnkgdGhp czogdGhlIHByaW1hcnkgcmVhc29uIGZvciBhbiBJQ0UgcmVzdGFydCBpcyBub3QgY2hhbmdpbmcg ZGV2aWNlcyBidXQgcmF0aGVyIHRyeWluZyB0byBkZWFsIHdpdGggdG9wb2xvZ3kgY2hhbmdlcyBh bmQvb3IgY29ubmVjdGl2aXR5IGNoZWNrIGZhaWx1cmVzLiBJZiB5b3UgYWN0dWFsbHkgKmRvKiBj aGFuZ2UgZGV2aWNlcywgdGhlbiBpdCdzIGFsc28gcXVpdGUgcHJvYmFibHkgeW91IHdpbGwgaGF2 ZSBhIG5ldyBjZXJ0aWZpY2F0ZSBmaW5nZXJwcmludCwgaW4gd2hpY2ggY2FzZSB5b3Ugd2lsbCBn ZXQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGluIGFueSBjYXNlLiBJbiBvdGhlciB3b3JkcywgdGxz LWlkIHNob3VsZCBiZSB1c2VkIHRvIHNheSAiSSB3YW50IGEgbmV3IERUTFMgY29ubmVjdGlvbiBp biBzcGl0ZSBvZiB0aGUgZmluZ2VycHJpbnQgYmVpbmcgdGhlIHNhbWUiICh3aGF0IEpTRVAgc2F5 cyksIG5vdCAiSSB3YW50IHRvIGtlZXAgdGhlIERUTFMgY29ubmVjdGlvbiBldmVuIHRob3VnaCBJ IGFtIGRvaW5nIGFuIElDRSByZXN0YXJ0Ig0KDQotRWtyDQoNCg0KT24gRnJpLCBBdWcgMjUsIDIw MTcgYXQgNDozMCBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBu b3N0cnVtLmNvbT4+IHdyb3RlOg0KDQpNTVVTSUMgLS0NCg0KW0kgd2lsbCBiZSBwb3N0aW5nIGEg c2VwYXJhdGUgbWVzc2FnZSB0byBSVENXRUIgZGlyZWN0aW5nIGludGVyZXN0ZWQgcGFydGllcyB0 byBkaXNjdXNzIHRoaXMgaXNzdWUgb24gdGhlIE1NVVNJQyBtYWlsaW5nIGxpc3RdDQoNCkR1cmlu ZyB0aGUgSUVTRyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAsIEVLUiBpZGVu dGlmaWVkIHNvbWUgY29uZmxpY3RzIGJldHdlZW4gdGhlIHByb2NlZHVyZXMgaW4gRFRMUy1TRFAg YW5kIEpTRVAgd2VyZSBpZGVudGlmaWVkLiBUaGlzIG5vdGUgaXMgYW4gYXR0ZW1wdCB0byBzdW1t YXJpemUgdGhlbS4gSSBoYXZlIGFsc28gbWFkZSBhbiBpbml0aWFsIHByb3Bvc2FsLCBmb3IgZWFj aCBjb25mbGljdCwgcmVnYXJkaW5nIHdoaWNoIGRvY3VtZW50IG5lZWRzIHRvIGNoYW5nZSwgaW4g YW5kIHdoaWNoIHdheS4NCg0KSXNzdWUgMSAocXVvdGluZyBFS1IpLCB3aGljaCByYWlzZXMgYSBj b3VwbGUgb2YgYWRkaXRpb25hbCBzdWItaXNzdWVzOg0KDQoxLiBBc3N1bWluZyBJIHVuZGVyc3Rh bmQgdGhpcyBkb2N1bWVudCBjb3JyZWN0bHksIGl0IGNvbmZsaWN0cyB3aXRoDQoNCnRoZSBndWlk YW5jZSBpbiBKU0VQLiBTcGVjaWZpY2FsbHksIFMgNCBzYXlzOg0KDQoNCg0KICAgTm8gZGVmYXVs dCB2YWx1ZSBpcyBkZWZpbmVkIGZvciB0aGUgU0RQICd0bHMtaWQnIGF0dHJpYnV0ZS4NCg0KICAg SW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0byB1c2UgdGhlIGF0dHJpYnV0ZSBNVVNUIGV4cGxp Y2l0bHkNCg0KICAgaW5jbHVkZSBpdCBpbiBTRFAgb2ZmZXJzIGFuZCBhbnN3ZXJzLiAgSWYgYW4g b2ZmZXIgb3IgYW5zd2VyIGRvZXMgbm90DQoNCiAgIGNvbnRhaW4gYSAndGxzLWlkJyBhdHRyaWJ1 dGUgKHRoaXMgY291bGQgaGFwcGVuIGlmIHRoZSBvZmZlcmVyIG9yDQoNCiAgIGFuc3dlcmVyIHJl cHJlc2VudHMgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdGhhdCBoYXMgbm90IGJlZW4NCg0K ICAgdXBkYXRlZCB0byBzdXBwb3J0IHRoZSAndGxzLWlkJyBhdHRyaWJ1dGUpLCB1bmxlc3MgdGhl cmUgaXMgYW5vdGhlcg0KDQogICBtZWNoYW5pc20gdG8gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGF0 IGEgbmV3IERUTFMgYXNzb2NpYXRpb24gaXMgdG8gYmUNCg0KICAgZXN0YWJsaXNoZWQsIGEgbW9k aWZpY2F0aW9uIG9mIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcNCg0KICAgY2hhcmFjdGVy aXN0aWNzIE1VU1QgYmUgdHJlYXRlZCBhcyBhbiBpbmRpY2F0aW9uIHRoYXQgYW4gZW5kcG9pbnQN Cg0KICAgd2FudHMgdG8gZXN0YWJsaXNoIGEgbmV3IERUTFMgYXNzb2NpYXRpb246DQoNCg0KDQog ICBvICBEVExTIHNldHVwIHJvbGU7IG9yDQoNCg0KDQogICBvICBmaW5nZXJwcmludCBzZXQ7IG9y DQoNCg0KDQogICBvICBsb2NhbCB0cmFuc3BvcnQgcGFyYW1ldGVyczsgb3INCg0KDQoNCiAgIG8g IElDRSB1ZnJhZyB2YWx1ZQ0KDQoNCg0KVGhpcyBzZWVtcyB0byBzYXkgdGhhdCBpZiB0aGVyZSBp cyBubyB0bHMtaWQgYXR0cmlidXRlLCB0aGVuIGFuIElDRSByZXN0YXJ0DQoNCih3aGljaCBuZWNl c3NpdGF0ZXMgYSB1ZnJhZyBjaGFuZ2UpIHJlcXVpcmVzIGEgRFRMUyByZXN0YXJ0LiBKU0VQIGlz bid0DQoNCmluY3JlZGlibHkgY2xlYXIgb24gdGhpcyBwb2ludCwgYnV0IDUuNy4zIHNlZW1zIHRv IHNheSB0aGF0IHRscy1pZA0KDQpuZWVkIG5vdCBiZSBwcmVzZW50Og0KDQoNCg0KICAgICAgKiAg dGxzLWlkIHZhbHVlLCB3aGljaCBNVVNUIGJlIHNldCBhY2NvcmRpbmcgdG8NCg0KICAgICAgICAg W0ktRC5pZXRmLW1tdXNpYy1kdGxzLXNkcF0sIFNlY3Rpb24gNS4gIElmIHRoaXMgaXMgYSByZS1v ZmZlcg0KDQogICAgICAgICBhbmQgdGhlIHRscy1pZCB2YWx1ZSBpcyBkaWZmZXJlbnQgZnJvbSB0 aGF0IHByZXNlbnRseSBpbiB1c2UsDQoNCiAgICAgICAgIHRoZSBEVExTIGNvbm5lY3Rpb24gaXMg bm90IGJlaW5nIGNvbnRpbnVlZCBhbmQgdGhlIHJlbW90ZQ0KDQogICAgICAgICBkZXNjcmlwdGlv biBNVVNUIGJlIHBhcnQgb2YgYW4gSUNFIHJlc3RhcnQsIHRvZ2V0aGVyIHdpdGggbmV3DQoNCiAg ICAgICAgIHVmcmFnIGFuZCBwYXNzd29yZCB2YWx1ZXMuICBJZiB0aGlzIGlzIGFuIGFuc3dlciwg dGhlIHRscy1pZA0KDQogICAgICAgICB2YWx1ZSwgaWYgcHJlc2VudCwgTVVTVCBiZSB0aGUgc2Ft ZSBhcyBpbiB0aGUgb2ZmZXIuDQoNCg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgZmlyc3Qgc2VudGVu Y2UgaXMgaW4gZXJyb3IsIGFzIHdlIGNsZWFybHkNCg0KY2FuJ3QgaGF2ZSBKU0VQIGltcGxlbWVu dGF0aW9ucyByZXF1aXJpbmcgdGhhdCB0bHMtaWQgYmUgcHJlc2VudC4NCg0KDQoNCiAgIC4uLg0K DQoNCg0KICAgbyAgSWYgdGhlIHJlbW90ZSBEVExTIGZpbmdlcnByaW50IGhhcyBiZWVuIGNoYW5n ZWQgb3IgdGhlIHRscy1pZCBoYXMNCg0KICAgICAgY2hhbmdlZCwgdGVhciBkb3duIHRoZSBEVExT IGNvbm5lY3Rpb24uICBUaGlzIGluY2x1ZGVzIHRoZSBjYXNlDQoNCiAgICAgIHdoZW4gdGhlIFBl ZXJDb25uZWN0aW9uIHN0YXRlIGlzICJoYXZlLXJlbW90ZS1wcmFuc3dlciIuICBJZiBhDQoNCiAg ICAgIERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSB0b3JuIGRvd24gYnV0IHRoZSBhbnN3ZXIg ZG9lcyBub3QNCg0KICAgICAgaW5kaWNhdGUgYW4gSUNFIHJlc3RhcnQgb3IsIGluIHRoZSBjYXNl IG9mICJoYXZlLXJlbW90ZS1wcmFuc3dlciIsDQoNCiAgICAgIG5ldyBJQ0UgY3JlZGVudGlhbHMs IGFuIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkLiAgSWYgYW4gSUNFDQoNCiAgICAgIHJlc3RhcnQg aXMgcGVyZm9ybWVkIHdpdGhvdXQgYSBjaGFuZ2UgaW4gdGxzLWlkIG9yIGZpbmdlcnByaW50LA0K DQogICAgICB0aGVuIHRoZSBzYW1lIERUTFMgY29ubmVjdGlvbiBpcyBjb250aW51ZWQgb3ZlciB0 aGUgbmV3IElDRQ0KDQogICAgICBjaGFubmVsLg0KDQoNCg0KSSB0aGluayB0aGUgYmVzdCBpbnRl cnByZXRhdGlvbiBvZiB0aGlzIGlzIHRoYXQgaWYgdGxzLWlkIGlzIG5vdCBwcmVzZW50DQoNCihh bmQgaGVuY2UgdW5jaGFuZ2VkKSB0aGVuIElDRSByZXN0YXJ0IGRvZXMgbm90IGNhdXNlIERUTFMg cmVzdGFydC4NCg0KVGhpcyBpcyBhbHNvIG15IG1lbW9yeSBvZiB0aGUgY29uc2Vuc3VzIGluIFJU Q1dFQi4gSW4gYW55IGNhc2UsIHRoZXNlDQoNCnR3byBkb2N1bWVudHMgY2xlYXJseSBtdXN0IG1h dGNoLg0KDQoNCg0KTXkgb2JzZXJ2YXRpb25zL3JlY29tbWVuZGF0aW9uczoNCg0KICAxLiAgKElz c3VlIDFhKSBFS1IgaXMgY29ycmVjdCB0aGF0IHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgYnVs bGV0IGZyb20gSlNFUCBuZWVkcyB0byBiZSByZW1vdmVkIHNvIGFzIHRvIGVuYWJsZSBpbnRlcm9w ZXJhdGlvbiB3aXRoIG5vbi1KU0VQIGltcGxlbWVudGF0aW9ucy4NCiAgMi4gIChJc3N1ZSAxYikg QWRkaXRpb25hbGx5IHRoZSBmaW5hbCBzZW50ZW5jZSBvZiB0aGF0IGJ1bGxldCAoIklmIHRoaXMg aXMgYW4gYW5zd2VyLCB0aGUgdGxzLWlkIHZhbHVlLCBpZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBz YW1lIGFzIGluIHRoZSBvZmZlciIpIGNvbmZsaWN0cyB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIHRs cy1pZCAoInRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlciBnZW5lcmF0ZSB0aGVpciBvd24gbG9jYWwg J3Rscy1pZCcgYXR0cmlidXRlIHZhbHVlcywgYW5kIHRoZSBjb21iaW5hdGlvbiBvZiBib3RoIHZh bHVlcyBpZGVudGlmeSB0aGUgRFRMUyBhc3NvY2lhdGlvbiIpLiBJbiB0aGlzIGNhc2UsIHRoZSBE VExTLVNEUCBkb2N1bWVudCB3b3VsZCBhcHBlYXIgdG8gYmUgY29ycmVjdCAodGhlIGZhY3QgdGhh dCB0aGUgdHdvIHBhcnRpZXMgY2hvb3NlIGRpZmZlcmVudCBJRHMgaXMgaW50ZWdyYWwgdG8gdGhl IG1lY2hhbmlzbSdzIGRlc2lnbiksIHNvIEpTRVAgbmVlZHMgdG8gY2hhbmdlLg0KICAzLiAgKElz c3VlIDFjKSBUaGUgY3J1eCBvZiB0aGUgbWF0dGVyOiBkb2VzIElDRSByZXN0YXJ0IGNhdXNlIERU TFMgdG8gcmVzdGFydD8gVGhlIHByaW1hcnkgcmF0aW9uYWxlIG91dGxpbmVkIGluIFJGQzUyNDUg Zm9yIHJlc3RhcnRpbmcgSUNFIGlzIGNoYW5naW5nIHRoZSBkZXN0aW5hdGlvbiAoSVAgYWRkcmVz cyBvciBwb3J0KSBvZiBhbiBvbmdvaW5nIG1lZGlhIHN0cmVhbSAtLSB3aGljaCB3b3VsZCBjb21t b25seSBpbnZvbHZlIGNoYW5naW5nIHRvIGEgZGlmZmVyZW50IHBoeXNpY2FsIGRldmljZS4gV2hp bGUgaXQgd291bGQsIGluIHRoZW9yeSwgYmUgcG9zc2libGUgdG8gdHJhbnNmZXIgdGhlIFRMUyBz dGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBkZXZpY2VzLCB0aGlz IGlzIHJhdGhlciBjdW1iZXJzb21lIChhbmQsIGFzIGZhciBhcyBJIGtub3csIG5vdCBnZW5lcmFs bHkgc3VwcG9ydGVkIGJ5IFRMUyBsaWJyYXJpZXMpLiBGcm9tIHRoYXQgcGVyc3BlY3RpdmUsIGl0 IGlzIG15IG9waW5pb24gdGhhdCB0aGUgRFRMUy1TRFAgZG9jdW1lbnQgaXMgY29ycmVjdCB0aGF0 IGFuIElDRSByZXN0YXJ0IG5lY2Vzc2l0YXRlcyBhIG5ldyBEVExTIGNvbm5lY3Rpb247IGFuZCBJ IGNvbmNsdWRlIHRoYXQgSlNFUCBuZWVkcyB0byBjaGFuZ2UuDQoNCg0KDQpJc3N1ZSAyIChxdW90 aW5nIEVLUik6DQoNCjIuIFMgNCBzYXlzOg0KDQoNCg0KICAgVGhlIG11eCBjYXRlZ29yeSBbSS1E LmlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlc10gZm9yIHRoZSAndGxzLQ0KDQogICBpZCcg YXR0cmlidXRlIGlzICdJREVOVElDQUwnLCB3aGljaCBtZWFucyB0aGF0IHRoZSBhdHRyaWJ1dGUg dmFsdWUNCg0KICAgbXVzdCBiZSBpZGVudGljYWwgYWNyb3NzIGFsbCBtZWRpYSBkZXNjcmlwdGlv bnMgYmVpbmcgbXVsdGlwbGV4ZWQNCg0KICAgW0ktRC5pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLW5l Z290aWF0aW9uXS4NCg0KDQoNClRoaXMgaXMgbm90IGFjdHVhbGx5IHdoYXQgSlNFUCByZXF1aXJl czoNCg0KDQoNCiAgIGRpZmZlcmVudCBjYXRlZ29yaWVzLiAgVG8gYXZvaWQgdW5uZWNlc3Nhcnkg ZHVwbGljYXRpb24gd2hlbg0KDQogICBidW5kbGluZywgYXR0cmlidXRlcyBvZiBjYXRlZ29yeSBJ REVOVElDQUwgb3IgVFJBTlNQT1JUIE1VU1QgTk9UIGJlDQoNCiAgIHJlcGVhdGVkIGluIGJ1bmRs ZWQgbT0gc2VjdGlvbnMsIHJlcGVhdGluZyB0aGUgZ3VpZGFuY2UgZnJvbQ0KDQogICBbSS1ELmll dGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpb25dLCBTZWN0aW9uIDguMS4gIFRoaXMgaW5j bHVkZXMNCg0KDQoNCkkgc3VzcGVjdCB0aGlzIGlzIG9sZCB0ZXh0Lg0KDQooSXNzdWUgMikgSlNF UCBpcyBhbGlnbmVkIHdpdGggZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlv bi0zOCwgd2hpbGUgRFRMUy1TRFAgZG9lcyBub3QuIFRoaXMgaXMgYSBsYXJnZWx5IGFlc3RoZXRp YyBkZWNpc2lvbiAoYWx0aG91Z2ggdGhlIEpTRVAvQlVORExFIGFwcHJvYWNoIGRvZXMgc2F2ZSBh IHRpbnkgaGFuZGZ1bCBvZiBieXRlcyksIGJ1dCBJIHRoaW5rIGNoYW5naW5nIG9uZSBkb2N1bWVu dCAoRFRMUy1TRFApIG1ha2VzIG1vcmUgc2Vuc2UgdGhhbiBjaGFuZ2luZyB0d28uIChJIHN1c3Bl Y3QgdGhlIEJVTkRMRSBmb3JtdWxhdGlvbiBtb3JlIGNsb3NlbHkgdHJhY2tzIGNvbnNlbnN1cyBh bnl3YXkpLg0KDQoNCg0KL2ENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoN Cg== --_000_7594FB04B1934943A5C02806D1A2204B56282B43ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxNDUxNzAzOTEwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3Nzg3NjI1 MzA7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5I aSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+WWVzLiBJbmRlZWQsIHRoYXQncyB0aGUgY3J1 eCBvZiB0aGUgZGlzYWdyZWVtZW50IGJldHdlZW4gSlNFUCBhbmQgdGhpcyBkb2N1bWVudDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPlNvLCBqdXN0IHRvIGNsYXJpZnk6IGluIHlvdXIgb3BpbmlvbiwgaWYgYW4gZW5kcG9pbnQg cmVjZWl2ZXMgYW4gb2ZmZXIvYW5zd2VyIFdJVEhPVVQgYSB0bHMtaWQsIGJ1dCB3aXRoIGEgTkVX IHVmcmFnIChyZWFkOiBJQ0UgcmVzdGFydCksIHRoZSBuZXcgdXJmYWcgd2lsbCBOT1QgdHJpZ2dl ciBhIG5ldw0KIERUTFMgYXNzb2NpYXRpb24uIFJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgU2VwIDIs IDIwMTcgYXQgMzozMSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEVrciw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5XaGF0IGlmIHRoZSByZW1vdGUgcGVlciBkb2VzIG5vdCBzdXBwb3J0 L2luY2x1ZGUgdGhlIHRscy1pZCBhdHRyaWJ1dGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tMTg1NjE1NTQ5NTkzNTQwMDkxM19fTWFpbEVu ZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IG1tdXNpYw0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IDAyIFNlcHRl bWJlciAyMDE3IDIyOjM2PGJyPg0KPGI+VG86PC9iPiBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVm PSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZXJuYXJk LmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gRFRMUy1TRFAgYW5kIEpTRVAgQ29uZmxpY3Rz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEF1ZyAyOSwgMjAxNyBh dCA3OjA3IEFNLCBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9i YUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBJc3N1 ZSAxLCBBZGFtIHNhaWQ6Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny4yNXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij4oSXNzdWUgMWMpIFRoZSBjcnV4IG9mIHRoZSBtYXR0ZXI6IGRvZXMgSUNFIHJlc3RhcnQgY2F1 c2UgRFRMUyB0byByZXN0YXJ0PyBUaGUgcHJpbWFyeSByYXRpb25hbGUgb3V0bGluZWQgaW4gUkZD NTI0NSBmb3IgcmVzdGFydGluZyBJQ0UgaXMgY2hhbmdpbmcgdGhlIGRlc3RpbmF0aW9uIChJUCBh ZGRyZXNzIG9yIHBvcnQpIG9mIGFuIG9uZ29pbmcgbWVkaWEgc3RyZWFtIC0tIHdoaWNoIHdvdWxk DQogY29tbW9ubHkgaW52b2x2ZSBjaGFuZ2luZyB0byBhIGRpZmZlcmVudCBwaHlzaWNhbCBkZXZp Y2UuIFdoaWxlIGl0IHdvdWxkLCBpbiB0aGVvcnksIGJlIHBvc3NpYmxlIHRvIHRyYW5zZmVyIHRo ZSBUTFMgc3RhdGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gZGV2aWNl cywgdGhpcyBpcyByYXRoZXIgY3VtYmVyc29tZSAoYW5kLCBhcyBmYXIgYXMgSSBrbm93LCBub3Qg Z2VuZXJhbGx5IHN1cHBvcnRlZCBieSBUTFMgbGlicmFyaWVzKS4NCiBGcm9tIHRoYXQgcGVyc3Bl Y3RpdmUsIGl0IGlzIG15IG9waW5pb24gdGhhdCB0aGUgRFRMUy1TRFAgZG9jdW1lbnQgaXMgY29y cmVjdCB0aGF0IGFuIElDRSByZXN0YXJ0IG5lY2Vzc2l0YXRlcyBhIG5ldyBEVExTIGNvbm5lY3Rp b247IGFuZCBJIGNvbmNsdWRlIHRoYXQgSlNFUCBuZWVkcyB0byBjaGFuZ2UuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPltCQV0gQWdyZWUgdGhhdCBmb3IgY29uc2lzdGVuY3ksIGl0IGlzIGJlc3QgZm9yIGFu IElDRSByZXN0YXJ0IHRvIG5lY2Vzc2l0YXRlIGEgbmV3IERUTFMgY29ubmVjdGlvbiwgc2luY2Ug YW4gSUNFIHJlc3RhcnQgY2FuIHJlc3VsdCBpbiBjb25uZWN0aW9uIHRvIGEgZGlmZmVyZW50IGRl dmljZSAoYW5kIHRoZQ0KIG5lZWQgZm9yIGEgbmV3IERUTFMgY29ubmVjdGlvbikuJm5ic3A7Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkknbSBub3QgcGVyc3VhZGVkIGJ5IHRoaXM6IHRoZSBwcmltYXJ5IHJlYXNvbiBmb3IgYW4gSUNF IHJlc3RhcnQgaXMgbm90IGNoYW5naW5nIGRldmljZXMgYnV0IHJhdGhlciB0cnlpbmcgdG8gZGVh bCB3aXRoIHRvcG9sb2d5IGNoYW5nZXMgYW5kL29yIGNvbm5lY3Rpdml0eSBjaGVjayBmYWlsdXJl cy4gSWYgeW91DQogYWN0dWFsbHkgKmRvKiBjaGFuZ2UgZGV2aWNlcywgdGhlbiBpdCdzIGFsc28g cXVpdGUgcHJvYmFibHkgeW91IHdpbGwgaGF2ZSBhIG5ldyBjZXJ0aWZpY2F0ZSBmaW5nZXJwcmlu dCwgaW4gd2hpY2ggY2FzZSB5b3Ugd2lsbCBnZXQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGluIGFu eSBjYXNlLiBJbiBvdGhlciB3b3JkcywgdGxzLWlkIHNob3VsZCBiZSB1c2VkIHRvIHNheSAmcXVv dDtJIHdhbnQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGluIHNwaXRlIG9mIHRoZQ0KIGZpbmdlcnBy aW50IGJlaW5nIHRoZSBzYW1lJnF1b3Q7ICh3aGF0IEpTRVAgc2F5cyksIG5vdCAmcXVvdDtJIHdh bnQgdG8ga2VlcCB0aGUgRFRMUyBjb25uZWN0aW9uIGV2ZW4gdGhvdWdoIEkgYW0gZG9pbmcgYW4g SUNFIHJlc3RhcnQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgQXVnIDI1LCAyMDE3IGF0IDQ6MzAg UE0sIEFkYW0gUm9hY2ggJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0uY29tIiB0YXJn ZXQ9Il9ibGFuayI+YWRhbUBub3N0cnVtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+TU1VU0lDIC0tPG86cD48L286cD48 L3A+DQo8cD5bSSB3aWxsIGJlIHBvc3RpbmcgYSBzZXBhcmF0ZSBtZXNzYWdlIHRvIFJUQ1dFQiBk aXJlY3RpbmcgaW50ZXJlc3RlZCBwYXJ0aWVzIHRvIGRpc2N1c3MgdGhpcyBpc3N1ZSBvbiB0aGUg TU1VU0lDIG1haWxpbmcgbGlzdF08bzpwPjwvbzpwPjwvcD4NCjxwPkR1cmluZyB0aGUgSUVTRyBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAsIEVLUiBpZGVudGlmaWVkIHNvbWUg Y29uZmxpY3RzIGJldHdlZW4gdGhlIHByb2NlZHVyZXMgaW4gRFRMUy1TRFAgYW5kIEpTRVAgd2Vy ZSBpZGVudGlmaWVkLiBUaGlzIG5vdGUgaXMgYW4gYXR0ZW1wdCB0byBzdW1tYXJpemUgdGhlbS4g SSBoYXZlIGFsc28gbWFkZSBhbiBpbml0aWFsIHByb3Bvc2FsLCBmb3IgZWFjaCBjb25mbGljdCwg cmVnYXJkaW5nDQogd2hpY2ggZG9jdW1lbnQgbmVlZHMgdG8gY2hhbmdlLCBpbiBhbmQgd2hpY2gg d2F5LjxvOnA+PC9vOnA+PC9wPg0KPHA+SXNzdWUgMSAocXVvdGluZyBFS1IpLCB3aGljaCByYWlz ZXMgYSBjb3VwbGUgb2YgYWRkaXRpb25hbCBzdWItaXNzdWVzOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cHJlPjEuIEFzc3VtaW5nIEkgdW5kZXJzdGFuZCB0aGlzIGRvY3VtZW50IGNvcnJlY3RseSwgaXQg Y29uZmxpY3RzIHdpdGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgZ3VpZGFuY2UgaW4gSlNF UC4gU3BlY2lmaWNhbGx5LCBTIDQgc2F5czo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgTm8gZGVmYXVsdCB2YWx1ZSBpcyBk ZWZpbmVkIGZvciB0aGUgU0RQICd0bHMtaWQnIGF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgSW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0byB1c2UgdGhlIGF0 dHJpYnV0ZSBNVVNUIGV4cGxpY2l0bHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgaW5jbHVkZSBpdCBpbiBTRFAgb2ZmZXJzIGFuZCBhbnN3ZXJzLiZuYnNwOyBJZiBhbiBvZmZl ciBvciBhbnN3ZXIgZG9lcyBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg Y29udGFpbiBhICd0bHMtaWQnIGF0dHJpYnV0ZSAodGhpcyBjb3VsZCBoYXBwZW4gaWYgdGhlIG9m ZmVyZXIgb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYW5zd2VyZXIgcmVw cmVzZW50cyBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiB0aGF0IGhhcyBub3QgYmVlbjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB1cGRhdGVkIHRvIHN1cHBvcnQgdGhlICd0 bHMtaWQnIGF0dHJpYnV0ZSksIHVubGVzcyB0aGVyZSBpcyBhbm90aGVyPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG1lY2hhbmlzbSB0byBleHBsaWNpdGx5IGluZGljYXRlIHRo YXQgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbiBpcyB0byBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBlc3RhYmxpc2hlZCwgYSBtb2RpZmljYXRpb24gb2Ygb25lIG9yIG1vcmUg b2YgdGhlIGZvbGxvd2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjaGFy YWN0ZXJpc3RpY3MgTVVTVCBiZSB0cmVhdGVkIGFzIGFuIGluZGljYXRpb24gdGhhdCBhbiBlbmRw b2ludDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB3YW50cyB0byBlc3RhYmxp c2ggYSBuZXcgRFRMUyBhc3NvY2lhdGlvbjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBEVExTIHNldHVwIHJv bGU7IG9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgZmluZ2VycHJpbnQgc2V0OyBvcjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsmbmJzcDtvJm5i c3A7IGxvY2FsIHRyYW5zcG9ydCBwYXJhbWV0ZXJzOyBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvJm5ic3A7IElDRSB1 ZnJhZyB2YWx1ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPlRoaXMgc2VlbXMgdG8gc2F5IHRoYXQgaWYgdGhlcmUgaXMgbm8gdGxzLWlkIGF0dHJp YnV0ZSwgdGhlbiBhbiBJQ0UgcmVzdGFydDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPih3aGljaCBu ZWNlc3NpdGF0ZXMgYSB1ZnJhZyBjaGFuZ2UpIHJlcXVpcmVzIGEgRFRMUyByZXN0YXJ0LiBKU0VQ IGlzbid0PG86cD48L286cD48L3ByZT4NCjxwcmU+aW5jcmVkaWJseSBjbGVhciBvbiB0aGlzIHBv aW50LCBidXQgNS43LjMgc2VlbXMgdG8gc2F5IHRoYXQgdGxzLWlkPG86cD48L286cD48L3ByZT4N CjxwcmU+bmVlZCBub3QgYmUgcHJlc2VudDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZu YnNwOyB0bHMtaWQgdmFsdWUsIHdoaWNoIE1VU1QgYmUgc2V0IGFjY29yZGluZyB0bzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBbSS1ELmlldGYtbW11c2ljLWR0bHMtc2RwXSwgU2VjdGlvbiA1LiZuYnNwOyBJZiB0 aGlzIGlzIGEgcmUtb2ZmZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIHRoZSB0bHMtaWQgdmFsdWUgaXMg ZGlmZmVyZW50IGZyb20gdGhhdCBwcmVzZW50bHkgaW4gdXNlLDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUg RFRMUyBjb25uZWN0aW9uIGlzIG5vdCBiZWluZyBjb250aW51ZWQgYW5kIHRoZSByZW1vdGU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gTVVTVCBiZSBwYXJ0IG9mIGFuIElDRSByZXN0YXJ0LCB0 b2dldGhlciB3aXRoIG5ldzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1ZnJhZyBhbmQgcGFzc3dvcmQgdmFsdWVz LiZuYnNwOyBJZiB0aGlzIGlzIGFuIGFuc3dlciwgdGhlIHRscy1pZDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2 YWx1ZSwgaWYgcHJlc2VudCwgTVVTVCBiZSB0aGUgc2FtZSBhcyBpbiB0aGUgb2ZmZXIuPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SSBiZWxpZXZl IHRoYXQgdGhlIGZpcnN0IHNlbnRlbmNlIGlzIGluIGVycm9yLCBhcyB3ZSBjbGVhcmx5PG86cD48 L286cD48L3ByZT4NCjxwcmU+Y2FuJ3QgaGF2ZSBKU0VQIGltcGxlbWVudGF0aW9ucyByZXF1aXJp bmcgdGhhdCB0bHMtaWQgYmUgcHJlc2VudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwO28mbmJzcDsgSWYgdGhlIHJlbW90ZSBEVExTIGZpbmdlcnByaW50IGhhcyBiZWVuIGNoYW5n ZWQgb3IgdGhlIHRscy1pZCBoYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgY2hhbmdlZCwgdGVhciBkb3duIHRoZSBEVExTIGNvbm5lY3Rpb24u Jm5ic3A7IFRoaXMgaW5jbHVkZXMgdGhlIGNhc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hlbiB0aGUgUGVlckNvbm5lY3Rpb24gc3RhdGUg aXMgJnF1b3Q7aGF2ZS1yZW1vdGUtcHJhbnN3ZXImcXVvdDsuJm5ic3A7IElmIGE8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRFRMUyBjb25uZWN0 aW9uIG5lZWRzIHRvIGJlIHRvcm4gZG93biBidXQgdGhlIGFuc3dlciBkb2VzIG5vdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmRpY2F0ZSBh biBJQ0UgcmVzdGFydCBvciwgaW4gdGhlIGNhc2Ugb2YgJnF1b3Q7aGF2ZS1yZW1vdGUtcHJhbnN3 ZXImcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG5ldyBJQ0UgY3JlZGVudGlhbHMsIGFuIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkLiZu YnNwOyBJZiBhbiBJQ0U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcmVzdGFydCBpcyBwZXJmb3JtZWQgd2l0aG91dCBhIGNoYW5nZSBpbiB0bHMt aWQgb3IgZmluZ2VycHJpbnQsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZW4gdGhlIHNhbWUgRFRMUyBjb25uZWN0aW9uIGlzIGNvbnRpbnVl ZCBvdmVyIHRoZSBuZXcgSUNFPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGNoYW5uZWwuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkgdGhpbmsgdGhl IGJlc3QgaW50ZXJwcmV0YXRpb24gb2YgdGhpcyBpcyB0aGF0IGlmIHRscy1pZCBpcyBub3QgcHJl c2VudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPihhbmQgaGVuY2UgdW5jaGFuZ2VkKSB0aGVuIElD RSByZXN0YXJ0IGRvZXMgbm90IGNhdXNlIERUTFMgcmVzdGFydC48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5UaGlzIGlzIGFsc28gbXkgbWVtb3J5IG9mIHRoZSBjb25zZW5zdXMgaW4gUlRDV0VCLiBJ biBhbnkgY2FzZSwgdGhlc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50d28gZG9jdW1lbnRzIGNs ZWFybHkgbXVzdCBtYXRjaC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD5NeSBvYnNlcnZhdGlvbnMvcmVjb21tZW5kYXRpb25zOjxv OnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KKElzc3VlIDFhKSBFS1IgaXMgY29ycmVjdCB0aGF0 IHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgYnVsbGV0IGZyb20gSlNFUCBuZWVkcyB0byBiZSBy ZW1vdmVkIHNvIGFzIHRvIGVuYWJsZSBpbnRlcm9wZXJhdGlvbiB3aXRoIG5vbi1KU0VQIGltcGxl bWVudGF0aW9ucy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQooSXNzdWUgMWIpIEFkZGl0aW9uYWxseSB0aGUgZmluYWwgc2VudGVuY2Ug b2YgdGhhdCBidWxsZXQgKCZxdW90O0lmIHRoaXMgaXMgYW4gYW5zd2VyLCB0aGUgdGxzLWlkIHZh bHVlLCBpZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBzYW1lIGFzIGluIHRoZSBvZmZlciZxdW90Oykg Y29uZmxpY3RzIHdpdGggdGhlIGRlZmluaXRpb24gb2YgdGxzLWlkICgmcXVvdDt0aGUgb2ZmZXJl ciBhbmQgYW5zd2VyZXIgZ2VuZXJhdGUgdGhlaXIgb3duIGxvY2FsICd0bHMtaWQnIGF0dHJpYnV0 ZQ0KIHZhbHVlcywgYW5kIHRoZSBjb21iaW5hdGlvbiBvZiBib3RoIHZhbHVlcyBpZGVudGlmeSB0 aGUgRFRMUyBhc3NvY2lhdGlvbiZxdW90OykuIEluIHRoaXMgY2FzZSwgdGhlIERUTFMtU0RQIGRv Y3VtZW50IHdvdWxkIGFwcGVhciB0byBiZSBjb3JyZWN0ICh0aGUgZmFjdCB0aGF0IHRoZSB0d28g cGFydGllcyBjaG9vc2UgZGlmZmVyZW50IElEcyBpcyBpbnRlZ3JhbCB0byB0aGUgbWVjaGFuaXNt J3MgZGVzaWduKSwgc28gSlNFUCBuZWVkcyB0byBjaGFuZ2UuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KKElzc3VlIDFjKSBU aGUgY3J1eCBvZiB0aGUgbWF0dGVyOiBkb2VzIElDRSByZXN0YXJ0IGNhdXNlIERUTFMgdG8gcmVz dGFydD8gVGhlIHByaW1hcnkgcmF0aW9uYWxlIG91dGxpbmVkIGluIFJGQzUyNDUgZm9yIHJlc3Rh cnRpbmcgSUNFIGlzIGNoYW5naW5nIHRoZSBkZXN0aW5hdGlvbiAoSVAgYWRkcmVzcyBvciBwb3J0 KSBvZiBhbiBvbmdvaW5nIG1lZGlhIHN0cmVhbSAtLSB3aGljaCB3b3VsZCBjb21tb25seSBpbnZv bHZlIGNoYW5naW5nIHRvIGENCiBkaWZmZXJlbnQgcGh5c2ljYWwgZGV2aWNlLiBXaGlsZSBpdCB3 b3VsZCwgaW4gdGhlb3J5LCBiZSBwb3NzaWJsZSB0byB0cmFuc2ZlciB0aGUgVExTIHN0YXRlIGFz c29jaWF0ZWQgd2l0aCB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIGRldmljZXMsIHRoaXMgaXMgcmF0 aGVyIGN1bWJlcnNvbWUgKGFuZCwgYXMgZmFyIGFzIEkga25vdywgbm90IGdlbmVyYWxseSBzdXBw b3J0ZWQgYnkgVExTIGxpYnJhcmllcykuIEZyb20gdGhhdCBwZXJzcGVjdGl2ZSwNCiBpdCBpcyBt eSBvcGluaW9uIHRoYXQgdGhlIERUTFMtU0RQIGRvY3VtZW50IGlzIGNvcnJlY3QgdGhhdCBhbiBJ Q0UgcmVzdGFydCBuZWNlc3NpdGF0ZXMgYSBuZXcgRFRMUyBjb25uZWN0aW9uOyBhbmQgSSBjb25j bHVkZSB0aGF0IEpTRVAgbmVlZHMgdG8gY2hhbmdlLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5Jc3N1ZSAyIChxdW90aW5nIEVLUik6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwcmU+Mi4gUyA0IHNheXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBtdXggY2F0ZWdvcnkgW0kt RC5pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXNdIGZvciB0aGUgJ3Rscy08bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaWQnIGF0dHJpYnV0ZSBpcyAnSURFTlRJQ0FMJywg d2hpY2ggbWVhbnMgdGhhdCB0aGUgYXR0cmlidXRlIHZhbHVlPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IG11c3QgYmUgaWRlbnRpY2FsIGFjcm9zcyBhbGwgbWVkaWEgZGVzY3Jp cHRpb25zIGJlaW5nIG11bHRpcGxleGVkPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IFtJLUQuaWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbl0uPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBpcyBub3QgYWN0 dWFsbHkgd2hhdCBKU0VQIHJlcXVpcmVzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgY2F0ZWdvcmllcy4m bmJzcDsgVG8gYXZvaWQgdW5uZWNlc3NhcnkgZHVwbGljYXRpb24gd2hlbjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBidW5kbGluZywgYXR0cmlidXRlcyBvZiBjYXRlZ29yeSBJ REVOVElDQUwgb3IgVFJBTlNQT1JUIE1VU1QgTk9UIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IHJlcGVhdGVkIGluIGJ1bmRsZWQgbT0gc2VjdGlvbnMsIHJlcGVhdGluZyB0 aGUgZ3VpZGFuY2UgZnJvbTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBbSS1E LmlldGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpb25dLCBTZWN0aW9uIDguMS4mbmJzcDsg VGhpcyBpbmNsdWRlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkkgc3VzcGVjdCB0aGlzIGlzIG9sZCB0ZXh0LjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cD48YnI+DQooSXNzdWUgMikgSlNFUCBpcyBhbGlnbmVkIHdpdGggZHJh ZnQtaWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbi0zOCwgd2hpbGUgRFRMUy1TRFAg ZG9lcyBub3QuIFRoaXMgaXMgYSBsYXJnZWx5IGFlc3RoZXRpYyBkZWNpc2lvbiAoYWx0aG91Z2gg dGhlIEpTRVAvQlVORExFIGFwcHJvYWNoIGRvZXMgc2F2ZSBhIHRpbnkgaGFuZGZ1bCBvZiBieXRl cyksIGJ1dCBJIHRoaW5rIGNoYW5naW5nIG9uZSBkb2N1bWVudCAoRFRMUy1TRFApIG1ha2VzDQog bW9yZSBzZW5zZSB0aGFuIGNoYW5naW5nIHR3by4gKEkgc3VzcGVjdCB0aGUgQlVORExFIGZvcm11 bGF0aW9uIG1vcmUgY2xvc2VseSB0cmFja3MgY29uc2Vuc3VzIGFueXdheSkuPG86cD48L286cD48 L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi9hPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNp Y0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B56282B43ESESSMB109erics_-- From nobody Sun Sep 3 13:00:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5103B13240D for ; Sun, 3 Sep 2017 13:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh8FS_5vmwfX for ; Sun, 3 Sep 2017 13:00:16 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95781323B8 for ; Sun, 3 Sep 2017 13:00:15 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id s187so17979796ywf.2 for ; Sun, 03 Sep 2017 13:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mAxWhR5FEHX7qNLzDwRLl0SpdJp7vfvZvRHqnPHNHho=; b=OqdKEVlHvgk6QO0O+kZYp8lkCYC0qTDMW/3lhprI9N6fldkyuUSiB4H7Xx7RxNL+g1 q+Obn5Bqbqp29f/epXBEjqOyBhzc0gfgng4UAlZVUYnWNw6xNWcxJGp8QFKZ0+YAEzj1 KAJ3j8cZTY891Kzd0p46JLqiw3U5HKEhFdG7swtNhsh8vEtgcfhtQTz/qS7h1qCuFT26 A5oCe0dinG/X5aXnFTqwXfLdS28wMKhQ7FW0pmRG4DTSNIQZCViP1tWf+k7/Q5C9VWO2 SPwJ5CAmyVvTmCHGIGCoSYoPuJeeubuQxruKL+5Eujj+lVkrP9j+V0MAMnjAInq5S1Wc 0Fvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mAxWhR5FEHX7qNLzDwRLl0SpdJp7vfvZvRHqnPHNHho=; b=M1CwWwNSH7YehvN6KR3OBRwQqHCKbT+KHE519S3a96BWhf6HJZjvDQ+X8hmGGYrE5X jhyGjJhaM1Bx3Dg7VdndG/xhtXWYcggM3DT6MabPvvrHemZoQQUJovyjRiT6TB/tpKu7 KS2GmWyjvsLxIlh7DnYCRTMQTIVLgwHk9I5AYscy8NliapsnECajmS2Z/6YyD40MMI8G 1gk0NkVTuIcbuVfEkwgwru1enrY1vadx3c0XEbKKzDgjbS3va6s4V++t1Zlp7WV4Q8BC uOq0+ov14mIpPF7q0ej4xrErTA1mWw90Qg0fl6yjZvl1Ir2AVsL1kHUDJtQmFGrfZLeB VL/w== X-Gm-Message-State: AHPjjUgpEvu6O//4maLhdujIVnO/qntwmXu1L49o4fkVdTUHlJWAcw2h RBIhNbylvl9IOJeZmqQ6b4Q8uyWeblaS X-Google-Smtp-Source: ADKCNb66DEia2zdm2avgy86SCn3M7IvpPpnzUvjHtURcjDLEJOlPfWq6/VclzRbtQLe75CpuJNUa6pCHiiqUtAhyRFo= X-Received: by 10.13.204.66 with SMTP id o63mr7985919ywd.321.1504468814941; Sun, 03 Sep 2017 13:00:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sun, 3 Sep 2017 12:59:34 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Sun, 3 Sep 2017 12:59:34 -0700 Message-ID: To: Christer Holmberg Cc: Bernard Aboba , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a114f25d24a611005584e712c" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 20:00:19 -0000 --001a114f25d24a611005584e712c Content-Type: text/plain; charset="UTF-8" In my opinion, things should behave as follows. The semantics of the indicators are: tls-id old ufrag new ufrag ------ -------------------------------------------------- none No change ICE restart, same DTLS old ICE restart ICE restart, same DTLS new Error ICE restart, new DTLS However, in all cases but one, the answer MUST match the offer. I.e., the answer must do an ICE restart iff the offer had one and a new DTLS connection iff the offer had one. However, if the answerer does not support tls-id, then it might respond to a new tls-id with no tls-id, which means it does not intend to make a new DTLS connection. The offerer can either accept that or tear everything down. I agree that the specs do not currently make this clear -Ekr On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >Yes. Indeed, that's the crux of the disagreement between JSEP and this > document > > > > So, just to clarify: in your opinion, if an endpoint receives an > offer/answer WITHOUT a tls-id, but with a NEW ufrag (read: ICE restart), > the new urfag will NOT trigger a new DTLS association. Right? > > > > Regards, > > > > Christer > > > > > > > > On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi Ekr, > > > > What if the remote peer does not support/include the tls-id attribute? > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* 02 September 2017 22:36 > *To:* Bernard Aboba > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] DTLS-SDP and JSEP Conflicts > > > > > > > > On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba > wrote: > > On Issue 1, Adam said: > > > > " > > 1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. While > it would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From that perspective, it > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > " > > > > [BA] Agree that for consistency, it is best for an ICE restart to > necessitate a new DTLS connection, since an ICE restart can result in > connection to a different device (and the need for a new DTLS connection). > > > > I'm not persuaded by this: the primary reason for an ICE restart is not > changing devices but rather trying to deal with topology changes and/or > connectivity check failures. If you actually *do* change devices, then it's > also quite probably you will have a new certificate fingerprint, in which > case you will get a new DTLS connection in any case. In other words, tls-id > should be used to say "I want a new DTLS connection in spite of the > fingerprint being the same" (what JSEP says), not "I want to keep the DTLS > connection even though I am doing an ICE restart" > > > > -Ekr > > > > > > On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: > > MMUSIC -- > > [I will be posting a separate message to RTCWEB directing interested > parties to discuss this issue on the MMUSIC mailing list] > > During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some > conflicts between the procedures in DTLS-SDP and JSEP were identified. This > note is an attempt to summarize them. I have also made an initial proposal, > for each conflict, regarding which document needs to change, in and which > way. > > Issue 1 (quoting EKR), which raises a couple of additional sub-issues: > > 1. Assuming I understand this document correctly, it conflicts with > > the guidance in JSEP. Specifically, S 4 says: > > > > No default value is defined for the SDP 'tls-id' attribute. > > Implementations that wish to use the attribute MUST explicitly > > include it in SDP offers and answers. If an offer or answer does not > > contain a 'tls-id' attribute (this could happen if the offerer or > > answerer represents an existing implementation that has not been > > updated to support the 'tls-id' attribute), unless there is another > > mechanism to explicitly indicate that a new DTLS association is to be > > established, a modification of one or more of the following > > characteristics MUST be treated as an indication that an endpoint > > wants to establish a new DTLS association: > > > > o DTLS setup role; or > > > > o fingerprint set; or > > > > o local transport parameters; or > > > > o ICE ufrag value > > > > This seems to say that if there is no tls-id attribute, then an ICE restart > > (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't > > incredibly clear on this point, but 5.7.3 seems to say that tls-id > > need not be present: > > > > * tls-id value, which MUST be set according to > > [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer > > and the tls-id value is different from that presently in use, > > the DTLS connection is not being continued and the remote > > description MUST be part of an ICE restart, together with new > > ufrag and password values. If this is an answer, the tls-id > > value, if present, MUST be the same as in the offer. > > > > I believe that the first sentence is in error, as we clearly > > can't have JSEP implementations requiring that tls-id be present. > > > > ... > > > > o If the remote DTLS fingerprint has been changed or the tls-id has > > changed, tear down the DTLS connection. This includes the case > > when the PeerConnection state is "have-remote-pranswer". If a > > DTLS connection needs to be torn down but the answer does not > > indicate an ICE restart or, in the case of "have-remote-pranswer", > > new ICE credentials, an error MUST be generated. If an ICE > > restart is performed without a change in tls-id or fingerprint, > > then the same DTLS connection is continued over the new ICE > > channel. > > > > I think the best interpretation of this is that if tls-id is not present > > (and hence unchanged) then ICE restart does not cause DTLS restart. > > This is also my memory of the consensus in RTCWEB. In any case, these > > two documents clearly must match. > > > > My observations/recommendations: > > 1. (Issue 1a) EKR is correct that the first sentence of the bullet > from JSEP needs to be removed so as to enable interoperation with non-JSEP > implementations. > 2. (Issue 1b) Additionally the final sentence of that bullet ("If this > is an answer, the tls-id value, if present, MUST be the same as in the > offer") conflicts with the definition of tls-id ("the offerer and answerer > generate their own local 'tls-id' attribute values, and the combination of > both values identify the DTLS association"). In this case, the DTLS-SDP > document would appear to be correct (the fact that the two parties choose > different IDs is integral to the mechanism's design), so JSEP needs to > change. > 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream -- > which would commonly involve changing to a different physical device. While > it would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From that perspective, it > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > > > Issue 2 (quoting EKR): > > 2. S 4 says: > > > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- > > id' attribute is 'IDENTICAL', which means that the attribute value > > must be identical across all media descriptions being multiplexed > > [I-D.ietf-mmusic-sdp-bundle-negotiation]. > > > > This is not actually what JSEP requires: > > > > different categories. To avoid unnecessary duplication when > > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > > repeated in bundled m= sections, repeating the guidance from > > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes > > > > I suspect this is old text. > > > (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, > while DTLS-SDP does not. This is a largely aesthetic decision (although the > JSEP/BUNDLE approach does save a tiny handful of bytes), but I think > changing one document (DTLS-SDP) makes more sense than changing two. (I > suspect the BUNDLE formulation more closely tracks consensus anyway). > > > > /a > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > --001a114f25d24a611005584e712c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my opinion, things should behave as follows. The semant= ics of the indicators are:

tls-id =C2=A0 =C2=A0 old ufrag= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0new u= frag=C2=A0
------ =C2=A0 =C2=A0 ---------------------------------= -----------------
none =C2=A0 =C2=A0 =C2=A0 No change =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart, sam= e DTLS
old =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart, same DTLS
new =C2=A0 =C2=A0 =C2=A0 =C2=A0Error =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart, new DTLS

However, in all cases but one, the answer MUST matc= h the offer. I.e., the answer must
do an ICE restart iff the offe= r had one and a new DTLS connection iff the offer had one.
Howeve= r, if the answerer does not support tls-id, then it might respond to a new = tls-id
with no tls-id, which means it does not intend to make a n= ew DTLS connection. The offerer
can either accept that or tear ev= erything down.

I agree that the specs do not curre= ntly make this clear

-Ekr




=

On Sat, Sep= 2, 2017 at 10:51 PM, Christer Holmberg <christer.holmberg@er= icsson.com> wrote:

Hi,

=C2=A0

>Yes. Indeed= , that's the crux of the disagreement between JSEP and this document=

=C2=A0

So, just to clarify: in your opinion, if an = endpoint receives an offer/answer WITHOUT a tls-id, but with a NEW ufrag (r= ead: ICE restart), the new urfag will NOT trigger a new DTLS association. Right?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi Ekr,

=C2=A0

What if the remote peer does not supp= ort/include the tls-id attribute?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:

On Issue 1, Adam said:=C2=A0

=C2=A0

"

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Issue 1c) The crux of the matter: does ICE= restart cause DTLS to restart? The primary rationale outlined in RFC5245 f= or restarting ICE is changing the destination (IP address or port) of an on= going media stream -- which would commonly involve changing to a different physical device. While it would, = in theory, be possible to transfer the TLS state associated with the connec= tion between devices, this is rather cumbersome (and, as far as I know, not= generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is corr= ect that an ICE restart necessitates a new DTLS connection; and I conclude = that JSEP needs to change.

"

=C2=A0

[BA] Agree that for consistency, it is best for an I= CE restart to necessitate a new DTLS connection, since an ICE restart can r= esult in connection to a different device (and the need for a new DTLS connection).=C2=A0=C2=A0

=C2=A0

I'm not persuaded by this: the primary reason fo= r an ICE restart is not changing devices but rather trying to deal with top= ology changes and/or connectivity check failures. If you actually *do* change devices, then it's also quite probably you will h= ave a new certificate fingerprint, in which case you will get a new DTLS co= nnection in any case. In other words, tls-id should be used to say "I = want a new DTLS connection in spite of the fingerprint being the same" (what JSEP says), not "I want to kee= p the DTLS connection even though I am doing an ICE restart"=

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <adam@nostrum.com> = wrote:

MMUSIC --

[I will be posting a separate message to RTCWEB directing interested par= ties to discuss this issue on the MMUSIC mailing list]

During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified som= e conflicts between the procedures in DTLS-SDP and JSEP were identified. Th= is note is an attempt to summarize them. I have also made an initial propos= al, for each conflict, regarding which document needs to change, in and which way.

Issue 1 (quoting EKR), which raises a couple of additional sub-issues:

1. Assuming I understand this document correctly, it conflicts with=

the guidance in JSEP. Specifically, S 4 says:
=C2=A0
=C2=A0=C2=A0 No default value is defined for the SDP 'tls-id' =
attribute.
=C2=A0=C2=A0 Implementations that wish to use the attribute MUST expli=
citly
=C2=A0=C2=A0 include it in SDP offers and answers.=C2=A0 If an offer o=
r answer does not
=C2=A0=C2=A0 contain a 'tls-id' attribute (this could happen i=
f the offerer or
=C2=A0=C2=A0 answerer represents an existing implementation that has n=
ot been
=C2=A0=C2=A0 updated to support the 'tls-id' attribute), unles=
s there is another
=C2=A0=C2=A0 mechanism to explicitly indicate that a new DTLS associat=
ion is to be
=C2=A0=C2=A0 established, a modification of one or more of the followi=
ng
=C2=A0=C2=A0 characteristics MUST be treated as an indication that an =
endpoint
=C2=A0=C2=A0 wants to establish a new DTLS association:<=
/pre>

=C2=A0


=C2=A0=C2=A0 o=C2=A0 DTLS setup role; or


=C2=A0


=C2=A0=C2=A0 o=C2=A0 fingerprint set; or


=C2=A0


 =C2=A0=C2=A0o=C2=A0 local transport parameters; or

=C2=A0


=C2=A0=C2=A0 o=C2=A0 ICE ufrag value


=C2=A0


This seems to say that if there is no tls-id attribute, then an ICE re=
start


(which necessitates a ufrag change) requires a DTLS restart. JSEP isn&=
#39;t


incredibly clear on this point, but 5.7.3 seems to say that tls-id<=
/u>


need not be present:


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 tls-id value, which MUST be set=
 according to


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [I-D.ietf-mmusic-dtls=
-sdp], Section 5.=C2=A0 If this is a re-offer


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the tls-id value =
is different from that presently in use,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the DTLS connection i=
s not being continued and the remote


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description MUST be p=
art of an ICE restart, together with new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ufrag and password va=
lues.=C2=A0 If this is an answer, the tls-id


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value, if present, MU=
ST be the same as in the offer.


=C2=A0


I believe that the first sentence is in error, as we clearly=



can't have JSEP implementations requiring that tls-id be present.<=
u>


=C2=A0


=C2=A0=C2=A0 ...


=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0o=C2=A0 If the remote DTLS fingerprint has been chan=
ged or the tls-id has


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 changed, tear down the DTLS connection.=
=C2=A0 This includes the case


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when the PeerConnection state is "=
have-remote-pranswer".=C2=A0 If a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DTLS connection needs to be torn down b=
ut the answer does not


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indicate an ICE restart or, in the case=
 of "have-remote-pranswer",


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 new ICE credentials, an error MUST be g=
enerated.=C2=A0 If an ICE


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 restart is performed without a change i=
n tls-id or fingerprint,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then the same DTLS connection is contin=
ued over the new ICE


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 channel.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 


I think the best interpretation of this is that if tls-id is not prese=
nt


(and hence unchanged) then ICE restart does not cause DTLS restart.=



This is also my memory of the consensus in RTCWEB. In any case, these<=
u>


two documents clearly must match.

=C2=A0

My observations/recommendations:

  1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP n= eeds to be removed so as to enable interoperation with non-JSEP implementat= ions.
  2. (Issue 1b) Additionally the final sentence of that bullet ("If this is= an answer, the tls-id value, if present, MUST be the same as in the offer&= quot;) conflicts with the definition of tls-id ("the offerer and answe= rer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association&q= uot;). In this case, the DTLS-SDP document would appear to be correct (the = fact that the two parties choose different IDs is integral to the mechanism= 's design), so JSEP needs to change.
  3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? = The primary rationale outlined in RFC5245 for restarting ICE is changing th= e destination (IP address or port) of an ongoing media stream -- which woul= d commonly involve changing to a different physical device. While it would, in theory, be possible to trans= fer the TLS state associated with the connection between devices, this is r= ather cumbersome (and, as far as I know, not generally supported by TLS lib= raries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart= necessitates a new DTLS connection; and I conclude that JSEP needs to chan= ge.

=C2=A0

Issue 2 (quoting EKR):

2. S 4 says:
=C2=A0
=C2=A0=C2=A0 The mux category [I-D.ietf-mmusic-sdp-mux-attributes=
] for the 'tls-
=C2=A0=C2=A0 id' attribute is 'IDENTICAL', which means tha=
t the attribute value
=C2=A0=C2=A0 must be identical across all media descriptions being mul=
tiplexed
=C2=A0=C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiation].<=
/u>
=C2=A0
This is not actually what JSEP requires:
=C2=A0
=C2=A0=C2=A0 different categories.=C2=A0 To avoid unnecessary duplicat=
ion when
=C2=A0=C2=A0 bundling, attributes of category IDENTICAL or TRANSPORT M=
UST NOT be
=C2=A0=C2=A0 repeated in bundled m=3D sections, repeating the guidance=
 from
=C2=A0=C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.=
1.=C2=A0 This includes
=C2=A0
I suspect this is old text.


(Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiatio= n-38, while DTLS-SDP does not. This is a largely aesthetic decision (althou= gh the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think= changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more close= ly tracks consensus anyway).

=C2=A0

/a

=C2=A0

_____________________= __________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

=C2=A0


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

=C2=A0

=C2=A0


--001a114f25d24a611005584e712c-- From nobody Sun Sep 3 13:31:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADF0132139 for ; Sun, 3 Sep 2017 13:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VJEo8jQ8aRLo for ; Sun, 3 Sep 2017 13:31:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B316D1323B5 for ; Sun, 3 Sep 2017 13:31:41 -0700 (PDT) X-AuditID: c1b4fb30-597ff70000005897-57-59ac66abe3e4 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.C8.22679.BA66CA95; Sun, 3 Sep 2017 22:31:39 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Sun, 3 Sep 2017 22:31:38 +0200 From: Christer Holmberg To: Eric Rescorla CC: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKbMmOAgAbGf4CAADCNsP//5vyAgACksACAAMvvAIAAKExw Date: Sun, 3 Sep 2017 20:31:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.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_7594FB04B1934943A5C02806D1A2204B562869A2ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2J7uO7qtDWRBocPyVps2Pef2WLF63Ps FlOXP2ZxYPbYOesuu8eSJT+ZPCY/bmMOYI7isklJzcksSy3St0vgyui8v5ep4NYs5oq595+w NzA2TGDuYuTgkBAwkZjfrNHFyMUhJHCEUWLa9U9MEM5iRokL/76wgBSxCVhIdP/T7mLk5BAR UJD49ecEC4jNLBAk0dS/EKxEWMBQ4vR9I4gSI4nLxx8wQ9hREss6brCB2CwCKhLvf0xnB7F5 BXwl+jc+hVr1iFliRdcMsCJOgUCJ3oZTrCA2o4CYxPdTa5ggdolL3HoyH8yWEBCQWLLnPDOE LSrx8vE/VghbSWLt4e1Qt+VL/Fq+lRlimaDEyZlPWCYwisxCMmoWkrJZSMpmAb3DLKApsX6X PkSJosSU7ofsELaGROucuezI4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbawS2/ DXYwvnzueIhRgINRiYe3JXVNpBBrYllxZe4hRgkOZiUR3oPJQCHelMTKqtSi/Pii0pzU4kOM 0hwsSuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoYOeTMPcQv/5SrKvux0Ha23sVNEyqd3jer W017v3lD6dUU64QDk687sf44oPMjrcPgevK5Oyrhjwo1Jy9Zo1ic6rLdY9s1M5E6icqn80xt v0YvX7roecb/918KTLf8qdiicma6z58by14LuM1tV9y1Wyy5mbkyvPwoQ9Y9MYuctFeHQjU+ zrvircRSnJFoqMVcVJwIAOehCsixAgAA Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 20:31:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562869A2ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JbiBteSBvcGluaW9uLCB0aGluZ3Mgc2hvdWxkIGJlaGF2ZSBhcyBmb2xsb3dzLiBU aGUgc2VtYW50aWNzIG9mIHRoZSBpbmRpY2F0b3JzIGFyZToNCj4NCj50bHMtaWQgICAgIG9sZCB1 ZnJhZyAgICAgICAgICAgICAgICAgICAgbmV3IHVmcmFnDQo+LS0tLS0tICAgICAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPm5vbmUgICAgICAgTm8g Y2hhbmdlICAgICAgICAgICAgICAgICAgICBJQ0UgcmVzdGFydCwgc2FtZSBEVExTDQo+b2xkICAg ICAgICBJQ0UgcmVzdGFydCAgICAgICAgICAgICAgICAgIElDRSByZXN0YXJ0LCBzYW1lIERUTFMN Cj5uZXcgICAgICAgIEVycm9yICAgICAgICAgICAgICAgICAgICAgICAgSUNFIHJlc3RhcnQsIG5l dyBEVExTDQo+DQo+SG93ZXZlciwgaW4gYWxsIGNhc2VzIGJ1dCBvbmUsIHRoZSBhbnN3ZXIgTVVT VCBtYXRjaCB0aGUgb2ZmZXIuIEkuZS4sIHRoZSBhbnN3ZXIgbXVzdA0KPmRvIGFuIElDRSByZXN0 YXJ0IGlmZiB0aGUgb2ZmZXIgaGFkIG9uZSBhbmQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGlmZiB0 aGUgb2ZmZXIgaGFkIG9uZS4NCj5Ib3dldmVyLCBpZiB0aGUgYW5zd2VyZXIgZG9lcyBub3Qgc3Vw cG9ydCB0bHMtaWQsIHRoZW4gaXQgbWlnaHQgcmVzcG9uZCB0byBhIG5ldyB0bHMtaWQNCj53aXRo IG5vIHRscy1pZCwgd2hpY2ggbWVhbnMgaXQgZG9lcyBub3QgaW50ZW5kIHRvIG1ha2UgYSBuZXcg RFRMUyBjb25uZWN0aW9uLiBUaGUgb2ZmZXJlcg0KPmNhbiBlaXRoZXIgYWNjZXB0IHRoYXQgb3Ig dGVhciBldmVyeXRoaW5nIGRvd24uDQo+DQo+SSBhZ3JlZSB0aGF0IHRoZSBzcGVjcyBkbyBub3Qg Y3VycmVudGx5IG1ha2UgdGhpcyBjbGVhcg0KDQpCZWNhdXNlIHRoYXTigJlzIG5vdCBob3cgdGhl IHByb2NlZHVyZXMgYXJlIGN1cnJlbnRseSB3cml0dGVuLg0KDQpOb3csIGJhc2VkIG9uIHlvdXIg c3VnZ2VzdGlvbiwgaWYgdGhlIG9mZmVyZXIgZG9lc27igJl0IGtub3cgd2hldGhlciB0aGUgYW5z d2VyZXIgc3VwcG9ydHMgdGxzLWlkLCBkb2VzIHRoYXQgbWVhbiB0aGF0IHRoZSBvbmx5IHdheSBm b3IgdGhlIG9mZmVyZXIgdG8gZW5zdXJlIHRoYXQgdGhlIHJlLW9mZmVyIHdpbGwgdHJpZ2dlciBh IG5ldyBEVExTIGFzc29jaWF0aW9uIGlzIGJ5IG1vZGlmeWluZyB0aGUgZmluZ2VycHJpbnQgc2V0 IGluIHRoZSBvZmZlcj8NCg0KQW5kLCBpZiB0aGUgb2ZmZXJlciBkb2VzIG5vdCBjaGFuZ2UgdGhl IGZpbmdlcnByaW50IHNldCwgZG9lcyBub3QgcmVjZWl2ZSB0bHMtaWQgaW4gdGhlIGFuc3dlciwg YW5kIGNob29zZXMgdG8g4oCcYWNjZXB04oCdIGl0LCB3b3VsZCB0aGUgb2ZmZXJlciB0aGVuIHN0 aWxsIHN0YXJ0IHVzaW5nIChpbiBzdWJzZXF1ZW50IG9mZmVycy9hbnN3ZXJzIGV0YykgdGhlIG5l dyB0bHMtaWQsIGV2ZW4gaWYgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbiB3YXMgbm90IGNyZWF0ZWQ/ DQoNCk9SLCB3b3VsZCB0aGUgb2ZmZXJlciBjb25zaWRlciB0aGUgbmV3IHRscy1pZCDigJxyZWpl Y3RlZOKAnSBieSB0aGUgYW5zd2VyZXIsIGFuZCBjb250aW51ZSB1c2luZyB0aGUgb2xkIHRscy1p ZD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCk9uIFNhdCwgU2VwIDIsIDIw MTcgYXQgMTA6NTEgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K SGksDQoNCj5ZZXMuIEluZGVlZCwgdGhhdCdzIHRoZSBjcnV4IG9mIHRoZSBkaXNhZ3JlZW1lbnQg YmV0d2VlbiBKU0VQIGFuZCB0aGlzIGRvY3VtZW50DQoNClNvLCBqdXN0IHRvIGNsYXJpZnk6IGlu IHlvdXIgb3BpbmlvbiwgaWYgYW4gZW5kcG9pbnQgcmVjZWl2ZXMgYW4gb2ZmZXIvYW5zd2VyIFdJ VEhPVVQgYSB0bHMtaWQsIGJ1dCB3aXRoIGEgTkVXIHVmcmFnIChyZWFkOiBJQ0UgcmVzdGFydCks IHRoZSBuZXcgdXJmYWcgd2lsbCBOT1QgdHJpZ2dlciBhIG5ldyBEVExTIGFzc29jaWF0aW9uLiBS aWdodD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIFNhdCwgU2VwIDIsIDIwMTcg YXQgMzozMSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBF a3IsDQoNCldoYXQgaWYgdGhlIHJlbW90ZSBwZWVyIGRvZXMgbm90IHN1cHBvcnQvaW5jbHVkZSB0 aGUgdGxzLWlkIGF0dHJpYnV0ZT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogbW11 c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpYy1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IDAyIFNlcHRlbWJl ciAyMDE3IDIyOjM2DQpUbzogQmVybmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208 bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj4NCkNjOiBtbXVzaWNAaWV0Zi5vcmc8bWFp bHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEVExTLVNEUCBhbmQg SlNFUCBDb25mbGljdHMNCg0KDQoNCk9uIFR1ZSwgQXVnIDI5LCAyMDE3IGF0IDc6MDcgQU0sIEJl cm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gSXNzdWUgMSwgQWRhbSBzYWlkOg0KDQoiDQoxLiAgICAg IChJc3N1ZSAxYykgVGhlIGNydXggb2YgdGhlIG1hdHRlcjogZG9lcyBJQ0UgcmVzdGFydCBjYXVz ZSBEVExTIHRvIHJlc3RhcnQ/IFRoZSBwcmltYXJ5IHJhdGlvbmFsZSBvdXRsaW5lZCBpbiBSRkM1 MjQ1IGZvciByZXN0YXJ0aW5nIElDRSBpcyBjaGFuZ2luZyB0aGUgZGVzdGluYXRpb24gKElQIGFk ZHJlc3Mgb3IgcG9ydCkgb2YgYW4gb25nb2luZyBtZWRpYSBzdHJlYW0gLS0gd2hpY2ggd291bGQg Y29tbW9ubHkgaW52b2x2ZSBjaGFuZ2luZyB0byBhIGRpZmZlcmVudCBwaHlzaWNhbCBkZXZpY2Uu IFdoaWxlIGl0IHdvdWxkLCBpbiB0aGVvcnksIGJlIHBvc3NpYmxlIHRvIHRyYW5zZmVyIHRoZSBU TFMgc3RhdGUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gZGV2aWNlcywg dGhpcyBpcyByYXRoZXIgY3VtYmVyc29tZSAoYW5kLCBhcyBmYXIgYXMgSSBrbm93LCBub3QgZ2Vu ZXJhbGx5IHN1cHBvcnRlZCBieSBUTFMgbGlicmFyaWVzKS4gRnJvbSB0aGF0IHBlcnNwZWN0aXZl LCBpdCBpcyBteSBvcGluaW9uIHRoYXQgdGhlIERUTFMtU0RQIGRvY3VtZW50IGlzIGNvcnJlY3Qg dGhhdCBhbiBJQ0UgcmVzdGFydCBuZWNlc3NpdGF0ZXMgYSBuZXcgRFRMUyBjb25uZWN0aW9uOyBh bmQgSSBjb25jbHVkZSB0aGF0IEpTRVAgbmVlZHMgdG8gY2hhbmdlLg0KIg0KDQpbQkFdIEFncmVl IHRoYXQgZm9yIGNvbnNpc3RlbmN5LCBpdCBpcyBiZXN0IGZvciBhbiBJQ0UgcmVzdGFydCB0byBu ZWNlc3NpdGF0ZSBhIG5ldyBEVExTIGNvbm5lY3Rpb24sIHNpbmNlIGFuIElDRSByZXN0YXJ0IGNh biByZXN1bHQgaW4gY29ubmVjdGlvbiB0byBhIGRpZmZlcmVudCBkZXZpY2UgKGFuZCB0aGUgbmVl ZCBmb3IgYSBuZXcgRFRMUyBjb25uZWN0aW9uKS4NCg0KSSdtIG5vdCBwZXJzdWFkZWQgYnkgdGhp czogdGhlIHByaW1hcnkgcmVhc29uIGZvciBhbiBJQ0UgcmVzdGFydCBpcyBub3QgY2hhbmdpbmcg ZGV2aWNlcyBidXQgcmF0aGVyIHRyeWluZyB0byBkZWFsIHdpdGggdG9wb2xvZ3kgY2hhbmdlcyBh bmQvb3IgY29ubmVjdGl2aXR5IGNoZWNrIGZhaWx1cmVzLiBJZiB5b3UgYWN0dWFsbHkgKmRvKiBj aGFuZ2UgZGV2aWNlcywgdGhlbiBpdCdzIGFsc28gcXVpdGUgcHJvYmFibHkgeW91IHdpbGwgaGF2 ZSBhIG5ldyBjZXJ0aWZpY2F0ZSBmaW5nZXJwcmludCwgaW4gd2hpY2ggY2FzZSB5b3Ugd2lsbCBn ZXQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGluIGFueSBjYXNlLiBJbiBvdGhlciB3b3JkcywgdGxz LWlkIHNob3VsZCBiZSB1c2VkIHRvIHNheSAiSSB3YW50IGEgbmV3IERUTFMgY29ubmVjdGlvbiBp biBzcGl0ZSBvZiB0aGUgZmluZ2VycHJpbnQgYmVpbmcgdGhlIHNhbWUiICh3aGF0IEpTRVAgc2F5 cyksIG5vdCAiSSB3YW50IHRvIGtlZXAgdGhlIERUTFMgY29ubmVjdGlvbiBldmVuIHRob3VnaCBJ IGFtIGRvaW5nIGFuIElDRSByZXN0YXJ0Ig0KDQotRWtyDQoNCg0KT24gRnJpLCBBdWcgMjUsIDIw MTcgYXQgNDozMCBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBu b3N0cnVtLmNvbT4+IHdyb3RlOg0KDQpNTVVTSUMgLS0NCg0KW0kgd2lsbCBiZSBwb3N0aW5nIGEg c2VwYXJhdGUgbWVzc2FnZSB0byBSVENXRUIgZGlyZWN0aW5nIGludGVyZXN0ZWQgcGFydGllcyB0 byBkaXNjdXNzIHRoaXMgaXNzdWUgb24gdGhlIE1NVVNJQyBtYWlsaW5nIGxpc3RdDQoNCkR1cmlu ZyB0aGUgSUVTRyByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAsIEVLUiBpZGVu dGlmaWVkIHNvbWUgY29uZmxpY3RzIGJldHdlZW4gdGhlIHByb2NlZHVyZXMgaW4gRFRMUy1TRFAg YW5kIEpTRVAgd2VyZSBpZGVudGlmaWVkLiBUaGlzIG5vdGUgaXMgYW4gYXR0ZW1wdCB0byBzdW1t YXJpemUgdGhlbS4gSSBoYXZlIGFsc28gbWFkZSBhbiBpbml0aWFsIHByb3Bvc2FsLCBmb3IgZWFj aCBjb25mbGljdCwgcmVnYXJkaW5nIHdoaWNoIGRvY3VtZW50IG5lZWRzIHRvIGNoYW5nZSwgaW4g YW5kIHdoaWNoIHdheS4NCg0KSXNzdWUgMSAocXVvdGluZyBFS1IpLCB3aGljaCByYWlzZXMgYSBj b3VwbGUgb2YgYWRkaXRpb25hbCBzdWItaXNzdWVzOg0KDQoxLiBBc3N1bWluZyBJIHVuZGVyc3Rh bmQgdGhpcyBkb2N1bWVudCBjb3JyZWN0bHksIGl0IGNvbmZsaWN0cyB3aXRoDQoNCnRoZSBndWlk YW5jZSBpbiBKU0VQLiBTcGVjaWZpY2FsbHksIFMgNCBzYXlzOg0KDQoNCg0KICAgTm8gZGVmYXVs dCB2YWx1ZSBpcyBkZWZpbmVkIGZvciB0aGUgU0RQICd0bHMtaWQnIGF0dHJpYnV0ZS4NCg0KICAg SW1wbGVtZW50YXRpb25zIHRoYXQgd2lzaCB0byB1c2UgdGhlIGF0dHJpYnV0ZSBNVVNUIGV4cGxp Y2l0bHkNCg0KICAgaW5jbHVkZSBpdCBpbiBTRFAgb2ZmZXJzIGFuZCBhbnN3ZXJzLiAgSWYgYW4g b2ZmZXIgb3IgYW5zd2VyIGRvZXMgbm90DQoNCiAgIGNvbnRhaW4gYSAndGxzLWlkJyBhdHRyaWJ1 dGUgKHRoaXMgY291bGQgaGFwcGVuIGlmIHRoZSBvZmZlcmVyIG9yDQoNCiAgIGFuc3dlcmVyIHJl cHJlc2VudHMgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdGhhdCBoYXMgbm90IGJlZW4NCg0K ICAgdXBkYXRlZCB0byBzdXBwb3J0IHRoZSAndGxzLWlkJyBhdHRyaWJ1dGUpLCB1bmxlc3MgdGhl cmUgaXMgYW5vdGhlcg0KDQogICBtZWNoYW5pc20gdG8gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGF0 IGEgbmV3IERUTFMgYXNzb2NpYXRpb24gaXMgdG8gYmUNCg0KICAgZXN0YWJsaXNoZWQsIGEgbW9k aWZpY2F0aW9uIG9mIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcNCg0KICAgY2hhcmFjdGVy aXN0aWNzIE1VU1QgYmUgdHJlYXRlZCBhcyBhbiBpbmRpY2F0aW9uIHRoYXQgYW4gZW5kcG9pbnQN Cg0KICAgd2FudHMgdG8gZXN0YWJsaXNoIGEgbmV3IERUTFMgYXNzb2NpYXRpb246DQoNCg0KDQog ICBvICBEVExTIHNldHVwIHJvbGU7IG9yDQoNCg0KDQogICBvICBmaW5nZXJwcmludCBzZXQ7IG9y DQoNCg0KDQogICBvICBsb2NhbCB0cmFuc3BvcnQgcGFyYW1ldGVyczsgb3INCg0KDQoNCiAgIG8g IElDRSB1ZnJhZyB2YWx1ZQ0KDQoNCg0KVGhpcyBzZWVtcyB0byBzYXkgdGhhdCBpZiB0aGVyZSBp cyBubyB0bHMtaWQgYXR0cmlidXRlLCB0aGVuIGFuIElDRSByZXN0YXJ0DQoNCih3aGljaCBuZWNl c3NpdGF0ZXMgYSB1ZnJhZyBjaGFuZ2UpIHJlcXVpcmVzIGEgRFRMUyByZXN0YXJ0LiBKU0VQIGlz bid0DQoNCmluY3JlZGlibHkgY2xlYXIgb24gdGhpcyBwb2ludCwgYnV0IDUuNy4zIHNlZW1zIHRv IHNheSB0aGF0IHRscy1pZA0KDQpuZWVkIG5vdCBiZSBwcmVzZW50Og0KDQoNCg0KICAgICAgKiAg dGxzLWlkIHZhbHVlLCB3aGljaCBNVVNUIGJlIHNldCBhY2NvcmRpbmcgdG8NCg0KICAgICAgICAg W0ktRC5pZXRmLW1tdXNpYy1kdGxzLXNkcF0sIFNlY3Rpb24gNS4gIElmIHRoaXMgaXMgYSByZS1v ZmZlcg0KDQogICAgICAgICBhbmQgdGhlIHRscy1pZCB2YWx1ZSBpcyBkaWZmZXJlbnQgZnJvbSB0 aGF0IHByZXNlbnRseSBpbiB1c2UsDQoNCiAgICAgICAgIHRoZSBEVExTIGNvbm5lY3Rpb24gaXMg bm90IGJlaW5nIGNvbnRpbnVlZCBhbmQgdGhlIHJlbW90ZQ0KDQogICAgICAgICBkZXNjcmlwdGlv biBNVVNUIGJlIHBhcnQgb2YgYW4gSUNFIHJlc3RhcnQsIHRvZ2V0aGVyIHdpdGggbmV3DQoNCiAg ICAgICAgIHVmcmFnIGFuZCBwYXNzd29yZCB2YWx1ZXMuICBJZiB0aGlzIGlzIGFuIGFuc3dlciwg dGhlIHRscy1pZA0KDQogICAgICAgICB2YWx1ZSwgaWYgcHJlc2VudCwgTVVTVCBiZSB0aGUgc2Ft ZSBhcyBpbiB0aGUgb2ZmZXIuDQoNCg0KDQpJIGJlbGlldmUgdGhhdCB0aGUgZmlyc3Qgc2VudGVu Y2UgaXMgaW4gZXJyb3IsIGFzIHdlIGNsZWFybHkNCg0KY2FuJ3QgaGF2ZSBKU0VQIGltcGxlbWVu dGF0aW9ucyByZXF1aXJpbmcgdGhhdCB0bHMtaWQgYmUgcHJlc2VudC4NCg0KDQoNCiAgIC4uLg0K DQoNCg0KICAgbyAgSWYgdGhlIHJlbW90ZSBEVExTIGZpbmdlcnByaW50IGhhcyBiZWVuIGNoYW5n ZWQgb3IgdGhlIHRscy1pZCBoYXMNCg0KICAgICAgY2hhbmdlZCwgdGVhciBkb3duIHRoZSBEVExT IGNvbm5lY3Rpb24uICBUaGlzIGluY2x1ZGVzIHRoZSBjYXNlDQoNCiAgICAgIHdoZW4gdGhlIFBl ZXJDb25uZWN0aW9uIHN0YXRlIGlzICJoYXZlLXJlbW90ZS1wcmFuc3dlciIuICBJZiBhDQoNCiAg ICAgIERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSB0b3JuIGRvd24gYnV0IHRoZSBhbnN3ZXIg ZG9lcyBub3QNCg0KICAgICAgaW5kaWNhdGUgYW4gSUNFIHJlc3RhcnQgb3IsIGluIHRoZSBjYXNl IG9mICJoYXZlLXJlbW90ZS1wcmFuc3dlciIsDQoNCiAgICAgIG5ldyBJQ0UgY3JlZGVudGlhbHMs IGFuIGVycm9yIE1VU1QgYmUgZ2VuZXJhdGVkLiAgSWYgYW4gSUNFDQoNCiAgICAgIHJlc3RhcnQg aXMgcGVyZm9ybWVkIHdpdGhvdXQgYSBjaGFuZ2UgaW4gdGxzLWlkIG9yIGZpbmdlcnByaW50LA0K DQogICAgICB0aGVuIHRoZSBzYW1lIERUTFMgY29ubmVjdGlvbiBpcyBjb250aW51ZWQgb3ZlciB0 aGUgbmV3IElDRQ0KDQogICAgICBjaGFubmVsLg0KDQoNCg0KSSB0aGluayB0aGUgYmVzdCBpbnRl cnByZXRhdGlvbiBvZiB0aGlzIGlzIHRoYXQgaWYgdGxzLWlkIGlzIG5vdCBwcmVzZW50DQoNCihh bmQgaGVuY2UgdW5jaGFuZ2VkKSB0aGVuIElDRSByZXN0YXJ0IGRvZXMgbm90IGNhdXNlIERUTFMg cmVzdGFydC4NCg0KVGhpcyBpcyBhbHNvIG15IG1lbW9yeSBvZiB0aGUgY29uc2Vuc3VzIGluIFJU Q1dFQi4gSW4gYW55IGNhc2UsIHRoZXNlDQoNCnR3byBkb2N1bWVudHMgY2xlYXJseSBtdXN0IG1h dGNoLg0KDQoNCg0KTXkgb2JzZXJ2YXRpb25zL3JlY29tbWVuZGF0aW9uczoNCg0KICAxLiAgKElz c3VlIDFhKSBFS1IgaXMgY29ycmVjdCB0aGF0IHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgYnVs bGV0IGZyb20gSlNFUCBuZWVkcyB0byBiZSByZW1vdmVkIHNvIGFzIHRvIGVuYWJsZSBpbnRlcm9w ZXJhdGlvbiB3aXRoIG5vbi1KU0VQIGltcGxlbWVudGF0aW9ucy4NCiAgMi4gIChJc3N1ZSAxYikg QWRkaXRpb25hbGx5IHRoZSBmaW5hbCBzZW50ZW5jZSBvZiB0aGF0IGJ1bGxldCAoIklmIHRoaXMg aXMgYW4gYW5zd2VyLCB0aGUgdGxzLWlkIHZhbHVlLCBpZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBz YW1lIGFzIGluIHRoZSBvZmZlciIpIGNvbmZsaWN0cyB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIHRs cy1pZCAoInRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlciBnZW5lcmF0ZSB0aGVpciBvd24gbG9jYWwg J3Rscy1pZCcgYXR0cmlidXRlIHZhbHVlcywgYW5kIHRoZSBjb21iaW5hdGlvbiBvZiBib3RoIHZh bHVlcyBpZGVudGlmeSB0aGUgRFRMUyBhc3NvY2lhdGlvbiIpLiBJbiB0aGlzIGNhc2UsIHRoZSBE VExTLVNEUCBkb2N1bWVudCB3b3VsZCBhcHBlYXIgdG8gYmUgY29ycmVjdCAodGhlIGZhY3QgdGhh dCB0aGUgdHdvIHBhcnRpZXMgY2hvb3NlIGRpZmZlcmVudCBJRHMgaXMgaW50ZWdyYWwgdG8gdGhl IG1lY2hhbmlzbSdzIGRlc2lnbiksIHNvIEpTRVAgbmVlZHMgdG8gY2hhbmdlLg0KICAzLiAgKElz c3VlIDFjKSBUaGUgY3J1eCBvZiB0aGUgbWF0dGVyOiBkb2VzIElDRSByZXN0YXJ0IGNhdXNlIERU TFMgdG8gcmVzdGFydD8gVGhlIHByaW1hcnkgcmF0aW9uYWxlIG91dGxpbmVkIGluIFJGQzUyNDUg Zm9yIHJlc3RhcnRpbmcgSUNFIGlzIGNoYW5naW5nIHRoZSBkZXN0aW5hdGlvbiAoSVAgYWRkcmVz cyBvciBwb3J0KSBvZiBhbiBvbmdvaW5nIG1lZGlhIHN0cmVhbSAtLSB3aGljaCB3b3VsZCBjb21t b25seSBpbnZvbHZlIGNoYW5naW5nIHRvIGEgZGlmZmVyZW50IHBoeXNpY2FsIGRldmljZS4gV2hp bGUgaXQgd291bGQsIGluIHRoZW9yeSwgYmUgcG9zc2libGUgdG8gdHJhbnNmZXIgdGhlIFRMUyBz dGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBkZXZpY2VzLCB0aGlz IGlzIHJhdGhlciBjdW1iZXJzb21lIChhbmQsIGFzIGZhciBhcyBJIGtub3csIG5vdCBnZW5lcmFs bHkgc3VwcG9ydGVkIGJ5IFRMUyBsaWJyYXJpZXMpLiBGcm9tIHRoYXQgcGVyc3BlY3RpdmUsIGl0 IGlzIG15IG9waW5pb24gdGhhdCB0aGUgRFRMUy1TRFAgZG9jdW1lbnQgaXMgY29ycmVjdCB0aGF0 IGFuIElDRSByZXN0YXJ0IG5lY2Vzc2l0YXRlcyBhIG5ldyBEVExTIGNvbm5lY3Rpb247IGFuZCBJ IGNvbmNsdWRlIHRoYXQgSlNFUCBuZWVkcyB0byBjaGFuZ2UuDQoNCg0KDQpJc3N1ZSAyIChxdW90 aW5nIEVLUik6DQoNCjIuIFMgNCBzYXlzOg0KDQoNCg0KICAgVGhlIG11eCBjYXRlZ29yeSBbSS1E LmlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlc10gZm9yIHRoZSAndGxzLQ0KDQogICBpZCcg YXR0cmlidXRlIGlzICdJREVOVElDQUwnLCB3aGljaCBtZWFucyB0aGF0IHRoZSBhdHRyaWJ1dGUg dmFsdWUNCg0KICAgbXVzdCBiZSBpZGVudGljYWwgYWNyb3NzIGFsbCBtZWRpYSBkZXNjcmlwdGlv bnMgYmVpbmcgbXVsdGlwbGV4ZWQNCg0KICAgW0ktRC5pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLW5l Z290aWF0aW9uXS4NCg0KDQoNClRoaXMgaXMgbm90IGFjdHVhbGx5IHdoYXQgSlNFUCByZXF1aXJl czoNCg0KDQoNCiAgIGRpZmZlcmVudCBjYXRlZ29yaWVzLiAgVG8gYXZvaWQgdW5uZWNlc3Nhcnkg ZHVwbGljYXRpb24gd2hlbg0KDQogICBidW5kbGluZywgYXR0cmlidXRlcyBvZiBjYXRlZ29yeSBJ REVOVElDQUwgb3IgVFJBTlNQT1JUIE1VU1QgTk9UIGJlDQoNCiAgIHJlcGVhdGVkIGluIGJ1bmRs ZWQgbT0gc2VjdGlvbnMsIHJlcGVhdGluZyB0aGUgZ3VpZGFuY2UgZnJvbQ0KDQogICBbSS1ELmll dGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpb25dLCBTZWN0aW9uIDguMS4gIFRoaXMgaW5j bHVkZXMNCg0KDQoNCkkgc3VzcGVjdCB0aGlzIGlzIG9sZCB0ZXh0Lg0KDQooSXNzdWUgMikgSlNF UCBpcyBhbGlnbmVkIHdpdGggZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlv bi0zOCwgd2hpbGUgRFRMUy1TRFAgZG9lcyBub3QuIFRoaXMgaXMgYSBsYXJnZWx5IGFlc3RoZXRp YyBkZWNpc2lvbiAoYWx0aG91Z2ggdGhlIEpTRVAvQlVORExFIGFwcHJvYWNoIGRvZXMgc2F2ZSBh IHRpbnkgaGFuZGZ1bCBvZiBieXRlcyksIGJ1dCBJIHRoaW5rIGNoYW5naW5nIG9uZSBkb2N1bWVu dCAoRFRMUy1TRFApIG1ha2VzIG1vcmUgc2Vuc2UgdGhhbiBjaGFuZ2luZyB0d28uIChJIHN1c3Bl Y3QgdGhlIEJVTkRMRSBmb3JtdWxhdGlvbiBtb3JlIGNsb3NlbHkgdHJhY2tzIGNvbnNlbnN1cyBh bnl3YXkpLg0KDQoNCg0KL2ENCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoN Cg0K --_000_7594FB04B1934943A5C02806D1A2204B562869A2ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk1MjUwMDQ4Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMjI2MzQ5MTk4O30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0O0luIG15IG9waW5pb24sIHRoaW5ncyBzaG91bGQgYmVoYXZlIGFz IGZvbGxvd3MuIFRoZSBzZW1hbnRpY3Mgb2YgdGhlIGluZGljYXRvcnMgYXJlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O3Rscy1pZCAmbmJzcDsg Jm5ic3A7IG9sZCB1ZnJhZyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuZXcgdWZyYWcmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDstLS0tLS0gJm5ic3A7 ICZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 O25vbmUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTm8gY2hhbmdlICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lDRSByZXN0 YXJ0LCBzYW1lIERUTFM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDtvbGQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SUNFIHJlc3RhcnQg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtJQ0UgcmVzdGFydCwgc2FtZSBEVExTPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7bmV3ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0Vycm9yICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SUNFIHJlc3RhcnQsIG5ldyBEVExTPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7SG93ZXZlciwgaW4gYWxsIGNhc2VzIGJ1dCBvbmUsIHRoZSBhbnN3ZXIgTVVTVCBtYXRjaCB0 aGUgb2ZmZXIuIEkuZS4sIHRoZSBhbnN3ZXIgbXVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O2RvIGFuIElDRSByZXN0YXJ0IGlmZiB0aGUg b2ZmZXIgaGFkIG9uZSBhbmQgYSBuZXcgRFRMUyBjb25uZWN0aW9uIGlmZiB0aGUgb2ZmZXIgaGFk IG9uZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDtIb3dldmVyLCBpZiB0aGUgYW5zd2VyZXIgZG9lcyBub3Qgc3VwcG9ydCB0bHMtaWQsIHRo ZW4gaXQgbWlnaHQgcmVzcG9uZCB0byBhIG5ldyB0bHMtaWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDt3aXRoIG5vIHRscy1pZCwgd2hpY2gg bWVhbnMgaXQgZG9lcyBub3QgaW50ZW5kIHRvIG1ha2UgYSBuZXcgRFRMUyBjb25uZWN0aW9uLiBU aGUgb2ZmZXJlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0O2NhbiBlaXRoZXIgYWNjZXB0IHRoYXQgb3IgdGVhciBldmVyeXRoaW5nIGRvd24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7SSBhZ3JlZSB0aGF0IHRoZSBzcGVjcyBkbyBub3QgY3VycmVudGx5IG1ha2UgdGhpcyBj bGVhcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkJlY2F1c2UgdGhhdOKAmXMgbm90IGhvdyB0aGUgcHJvY2VkdXJlcyBhcmUgY3VycmVudGx5 IHdyaXR0ZW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdywgYmFzZWQgb24geW91ciBzdWdnZXN0aW9uLCBp ZiB0aGUgb2ZmZXJlciBkb2VzbuKAmXQga25vdyB3aGV0aGVyIHRoZSBhbnN3ZXJlciBzdXBwb3J0 cyB0bHMtaWQsIGRvZXMgdGhhdCBtZWFuIHRoYXQgdGhlIG9ubHkgd2F5IGZvciB0aGUgb2ZmZXJl ciB0byBlbnN1cmUgdGhhdCB0aGUgcmUtb2ZmZXINCiB3aWxsIHRyaWdnZXIgYSBuZXcgRFRMUyBh c3NvY2lhdGlvbiBpcyBieSBtb2RpZnlpbmcgdGhlIGZpbmdlcnByaW50IHNldCBpbiB0aGUgb2Zm ZXI/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kLCBpZiB0aGUgb2ZmZXJlciBkb2VzIG5vdCBjaGFuZ2Ug dGhlIGZpbmdlcnByaW50IHNldCwgZG9lcyBub3QgcmVjZWl2ZSB0bHMtaWQgaW4gdGhlIGFuc3dl ciwgYW5kIGNob29zZXMgdG8g4oCcYWNjZXB04oCdIGl0LCB3b3VsZCB0aGUgb2ZmZXJlciB0aGVu IHN0aWxsIHN0YXJ0IHVzaW5nIChpbiBzdWJzZXF1ZW50DQogb2ZmZXJzL2Fuc3dlcnMgZXRjKSB0 aGUgbmV3IHRscy1pZCwgZXZlbiBpZiBhIG5ldyBEVExTIGFzc29jaWF0aW9uIHdhcyBub3QgY3Jl YXRlZD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PUiwgd291bGQgdGhlIG9mZmVyZXIgY29uc2lkZXIgdGhl IG5ldyB0bHMtaWQg4oCccmVqZWN0ZWTigJ0gYnkgdGhlIGFuc3dlcmVyLCBhbmQgY29udGludWUg dXNpbmcgdGhlIG9sZCB0bHMtaWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgU2VwIDIsIDIwMTcgYXQgMTA6NTEgUE0s IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPlllcy4gSW5kZWVkLCB0aGF0J3Mg dGhlIGNydXggb2YgdGhlIGRpc2FncmVlbWVudCBiZXR3ZWVuIEpTRVAgYW5kIHRoaXMgZG9jdW1l bnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+U28sIGp1c3QgdG8gY2xhcmlmeTogaW4geW91ciBvcGluaW9uLCBpZiBh biBlbmRwb2ludCByZWNlaXZlcyBhbiBvZmZlci9hbnN3ZXIgV0lUSE9VVCBhIHRscy1pZCwgYnV0 IHdpdGggYSBORVcgdWZyYWcNCiAocmVhZDogSUNFIHJlc3RhcnQpLCB0aGUgbmV3IHVyZmFnIHdp bGwgTk9UIHRyaWdnZXIgYSBuZXcgRFRMUyBhc3NvY2lhdGlvbi4gUmlnaHQ/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izg4ODg4OCI+Q2hyaXN0ZXI8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM4ODg4ODgiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+T24gU2F0LCBTZXAgMiwgMjAxNyBhdCAzOjMxIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhpIEVrciw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5XaGF0IGlmIHRoZSByZW1vdGUgcGVlciBkb2VzIG5vdCBzdXBwb3J0L2lu Y2x1ZGUgdGhlIHRscy1pZCBhdHRyaWJ1dGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tNDQ1ODg1MjI5NjU5MDg1MjEzMl9tXy0xODU2MTU1 NDk1OTM1NCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gbW11c2ljDQogW21haWx0bzo8YSBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gMDIgU2VwdGVt YmVyIDIwMTcgMjI6MzY8YnI+DQo8Yj5Ubzo8L2I+IEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9 Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlcm5hcmQu YWJvYmFAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBEVExTLVNEUCBhbmQgSlNFUCBDb25mbGljdHM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgQXVnIDI5LCAyMDE3IGF0 IDc6MDcgQU0sIEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2Jh QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIElzc3Vl IDEsIEFkYW0gc2FpZDombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjQ3LjI1cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+MS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQi PihJc3N1ZSAxYykgVGhlIGNydXggb2YgdGhlIG1hdHRlcjogZG9lcyBJQ0UgcmVzdGFydCBjYXVz ZSBEVExTIHRvIHJlc3RhcnQ/IFRoZSBwcmltYXJ5IHJhdGlvbmFsZSBvdXRsaW5lZCBpbiBSRkM1 MjQ1IGZvciByZXN0YXJ0aW5nIElDRSBpcyBjaGFuZ2luZyB0aGUgZGVzdGluYXRpb24gKElQIGFk ZHJlc3Mgb3IgcG9ydCkgb2YgYW4gb25nb2luZyBtZWRpYSBzdHJlYW0gLS0gd2hpY2ggd291bGQN CiBjb21tb25seSBpbnZvbHZlIGNoYW5naW5nIHRvIGEgZGlmZmVyZW50IHBoeXNpY2FsIGRldmlj ZS4gV2hpbGUgaXQgd291bGQsIGluIHRoZW9yeSwgYmUgcG9zc2libGUgdG8gdHJhbnNmZXIgdGhl IFRMUyBzdGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiBkZXZpY2Vz LCB0aGlzIGlzIHJhdGhlciBjdW1iZXJzb21lIChhbmQsIGFzIGZhciBhcyBJIGtub3csIG5vdCBn ZW5lcmFsbHkgc3VwcG9ydGVkIGJ5IFRMUyBsaWJyYXJpZXMpLg0KIEZyb20gdGhhdCBwZXJzcGVj dGl2ZSwgaXQgaXMgbXkgb3BpbmlvbiB0aGF0IHRoZSBEVExTLVNEUCBkb2N1bWVudCBpcyBjb3Jy ZWN0IHRoYXQgYW4gSUNFIHJlc3RhcnQgbmVjZXNzaXRhdGVzIGEgbmV3IERUTFMgY29ubmVjdGlv bjsgYW5kIEkgY29uY2x1ZGUgdGhhdCBKU0VQIG5lZWRzIHRvIGNoYW5nZS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+W0JBXSBBZ3JlZSB0aGF0IGZvciBjb25zaXN0ZW5jeSwgaXQgaXMgYmVzdCBmb3IgYW4g SUNFIHJlc3RhcnQgdG8gbmVjZXNzaXRhdGUgYSBuZXcgRFRMUyBjb25uZWN0aW9uLCBzaW5jZSBh biBJQ0UgcmVzdGFydCBjYW4gcmVzdWx0IGluIGNvbm5lY3Rpb24gdG8gYSBkaWZmZXJlbnQgZGV2 aWNlIChhbmQgdGhlDQogbmVlZCBmb3IgYSBuZXcgRFRMUyBjb25uZWN0aW9uKS4mbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSdtIG5vdCBwZXJzdWFkZWQgYnkgdGhpczogdGhlIHByaW1hcnkgcmVhc29uIGZvciBhbiBJQ0Ug cmVzdGFydCBpcyBub3QgY2hhbmdpbmcgZGV2aWNlcyBidXQgcmF0aGVyIHRyeWluZyB0byBkZWFs IHdpdGggdG9wb2xvZ3kgY2hhbmdlcyBhbmQvb3IgY29ubmVjdGl2aXR5IGNoZWNrIGZhaWx1cmVz LiBJZiB5b3UNCiBhY3R1YWxseSAqZG8qIGNoYW5nZSBkZXZpY2VzLCB0aGVuIGl0J3MgYWxzbyBx dWl0ZSBwcm9iYWJseSB5b3Ugd2lsbCBoYXZlIGEgbmV3IGNlcnRpZmljYXRlIGZpbmdlcnByaW50 LCBpbiB3aGljaCBjYXNlIHlvdSB3aWxsIGdldCBhIG5ldyBEVExTIGNvbm5lY3Rpb24gaW4gYW55 IGNhc2UuIEluIG90aGVyIHdvcmRzLCB0bHMtaWQgc2hvdWxkIGJlIHVzZWQgdG8gc2F5ICZxdW90 O0kgd2FudCBhIG5ldyBEVExTIGNvbm5lY3Rpb24gaW4gc3BpdGUgb2YgdGhlDQogZmluZ2VycHJp bnQgYmVpbmcgdGhlIHNhbWUmcXVvdDsgKHdoYXQgSlNFUCBzYXlzKSwgbm90ICZxdW90O0kgd2Fu dCB0byBrZWVwIHRoZSBEVExTIGNvbm5lY3Rpb24gZXZlbiB0aG91Z2ggSSBhbSBkb2luZyBhbiBJ Q0UgcmVzdGFydCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBBdWcgMjUsIDIwMTcgYXQgNDozMCBQ TSwgQWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iIHRhcmdl dD0iX2JsYW5rIj5hZGFtQG5vc3RydW0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD5NTVVTSUMgLS08bzpwPjwvbzpwPjwv cD4NCjxwPltJIHdpbGwgYmUgcG9zdGluZyBhIHNlcGFyYXRlIG1lc3NhZ2UgdG8gUlRDV0VCIGRp cmVjdGluZyBpbnRlcmVzdGVkIHBhcnRpZXMgdG8gZGlzY3VzcyB0aGlzIGlzc3VlIG9uIHRoZSBN TVVTSUMgbWFpbGluZyBsaXN0XTxvOnA+PC9vOnA+PC9wPg0KPHA+RHVyaW5nIHRoZSBJRVNHIHJl dmlldyBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcCwgRUtSIGlkZW50aWZpZWQgc29tZSBj b25mbGljdHMgYmV0d2VlbiB0aGUgcHJvY2VkdXJlcyBpbiBEVExTLVNEUCBhbmQgSlNFUCB3ZXJl IGlkZW50aWZpZWQuIFRoaXMgbm90ZSBpcyBhbiBhdHRlbXB0IHRvIHN1bW1hcml6ZSB0aGVtLiBJ IGhhdmUgYWxzbyBtYWRlIGFuIGluaXRpYWwgcHJvcG9zYWwsIGZvciBlYWNoIGNvbmZsaWN0LCBy ZWdhcmRpbmcNCiB3aGljaCBkb2N1bWVudCBuZWVkcyB0byBjaGFuZ2UsIGluIGFuZCB3aGljaCB3 YXkuPG86cD48L286cD48L3A+DQo8cD5Jc3N1ZSAxIChxdW90aW5nIEVLUiksIHdoaWNoIHJhaXNl cyBhIGNvdXBsZSBvZiBhZGRpdGlvbmFsIHN1Yi1pc3N1ZXM6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw cmU+MS4gQXNzdW1pbmcgSSB1bmRlcnN0YW5kIHRoaXMgZG9jdW1lbnQgY29ycmVjdGx5LCBpdCBj b25mbGljdHMgd2l0aDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBndWlkYW5jZSBpbiBKU0VQ LiBTcGVjaWZpY2FsbHksIFMgNCBzYXlzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBObyBkZWZhdWx0IHZhbHVlIGlzIGRl ZmluZWQgZm9yIHRoZSBTRFAgJ3Rscy1pZCcgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgdGhhdCB3aXNoIHRvIHVzZSB0aGUgYXR0 cmlidXRlIE1VU1QgZXhwbGljaXRseTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBpbmNsdWRlIGl0IGluIFNEUCBvZmZlcnMgYW5kIGFuc3dlcnMuJm5ic3A7IElmIGFuIG9mZmVy IG9yIGFuc3dlciBkb2VzIG5vdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBj b250YWluIGEgJ3Rscy1pZCcgYXR0cmlidXRlICh0aGlzIGNvdWxkIGhhcHBlbiBpZiB0aGUgb2Zm ZXJlciBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhbnN3ZXJlciByZXBy ZXNlbnRzIGFuIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIHRoYXQgaGFzIG5vdCBiZWVuPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHVwZGF0ZWQgdG8gc3VwcG9ydCB0aGUgJ3Rs cy1pZCcgYXR0cmlidXRlKSwgdW5sZXNzIHRoZXJlIGlzIGFub3RoZXI8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtIHRvIGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhh dCBhIG5ldyBEVExTIGFzc29jaWF0aW9uIGlzIHRvIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IGVzdGFibGlzaGVkLCBhIG1vZGlmaWNhdGlvbiBvZiBvbmUgb3IgbW9yZSBv ZiB0aGUgZm9sbG93aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNoYXJh Y3RlcmlzdGljcyBNVVNUIGJlIHRyZWF0ZWQgYXMgYW4gaW5kaWNhdGlvbiB0aGF0IGFuIGVuZHBv aW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHdhbnRzIHRvIGVzdGFibGlz aCBhIG5ldyBEVExTIGFzc29jaWF0aW9uOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvJm5ic3A7IERUTFMgc2V0dXAgcm9s ZTsgb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBmaW5nZXJwcmludCBzZXQ7IG9yPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwO28mbmJz cDsgbG9jYWwgdHJhbnNwb3J0IHBhcmFtZXRlcnM7IG9yPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgSUNFIHVm cmFnIHZhbHVlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmU+VGhpcyBzZWVtcyB0byBzYXkgdGhhdCBpZiB0aGVyZSBpcyBubyB0bHMtaWQgYXR0cmli dXRlLCB0aGVuIGFuIElDRSByZXN0YXJ0PG86cD48L286cD48L3ByZT4NCjxwcmU+KHdoaWNoIG5l Y2Vzc2l0YXRlcyBhIHVmcmFnIGNoYW5nZSkgcmVxdWlyZXMgYSBEVExTIHJlc3RhcnQuIEpTRVAg aXNuJ3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbmNyZWRpYmx5IGNsZWFyIG9uIHRoaXMgcG9p bnQsIGJ1dCA1LjcuMyBzZWVtcyB0byBzYXkgdGhhdCB0bHMtaWQ8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5uZWVkIG5vdCBiZSBwcmVzZW50OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5i c3A7IHRscy1pZCB2YWx1ZSwgd2hpY2ggTVVTVCBiZSBzZXQgYWNjb3JkaW5nIHRvPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFtJLUQuaWV0Zi1tbXVzaWMtZHRscy1zZHBdLCBTZWN0aW9uIDUuJm5ic3A7IElmIHRo aXMgaXMgYSByZS1vZmZlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQgdGhlIHRscy1pZCB2YWx1ZSBpcyBk aWZmZXJlbnQgZnJvbSB0aGF0IHByZXNlbnRseSBpbiB1c2UsPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBE VExTIGNvbm5lY3Rpb24gaXMgbm90IGJlaW5nIGNvbnRpbnVlZCBhbmQgdGhlIHJlbW90ZTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkZXNjcmlwdGlvbiBNVVNUIGJlIHBhcnQgb2YgYW4gSUNFIHJlc3RhcnQsIHRv Z2V0aGVyIHdpdGggbmV3PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVmcmFnIGFuZCBwYXNzd29yZCB2YWx1ZXMu Jm5ic3A7IElmIHRoaXMgaXMgYW4gYW5zd2VyLCB0aGUgdGxzLWlkPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZh bHVlLCBpZiBwcmVzZW50LCBNVVNUIGJlIHRoZSBzYW1lIGFzIGluIHRoZSBvZmZlci48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIGJlbGlldmUg dGhhdCB0aGUgZmlyc3Qgc2VudGVuY2UgaXMgaW4gZXJyb3IsIGFzIHdlIGNsZWFybHk8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5jYW4ndCBoYXZlIEpTRVAgaW1wbGVtZW50YXRpb25zIHJlcXVpcmlu ZyB0aGF0IHRscy1pZCBiZSBwcmVzZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAuLi48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7byZuYnNwOyBJZiB0aGUgcmVtb3RlIERUTFMgZmluZ2VycHJpbnQgaGFzIGJlZW4gY2hhbmdl ZCBvciB0aGUgdGxzLWlkIGhhczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBjaGFuZ2VkLCB0ZWFyIGRvd24gdGhlIERUTFMgY29ubmVjdGlvbi4m bmJzcDsgVGhpcyBpbmNsdWRlcyB0aGUgY2FzZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVuIHRoZSBQZWVyQ29ubmVjdGlvbiBzdGF0ZSBp cyAmcXVvdDtoYXZlLXJlbW90ZS1wcmFuc3dlciZxdW90Oy4mbmJzcDsgSWYgYTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEVExTIGNvbm5lY3Rp b24gbmVlZHMgdG8gYmUgdG9ybiBkb3duIGJ1dCB0aGUgYW5zd2VyIGRvZXMgbm90PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZGljYXRlIGFu IElDRSByZXN0YXJ0IG9yLCBpbiB0aGUgY2FzZSBvZiAmcXVvdDtoYXZlLXJlbW90ZS1wcmFuc3dl ciZxdW90Oyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbmV3IElDRSBjcmVkZW50aWFscywgYW4gZXJyb3IgTVVTVCBiZSBnZW5lcmF0ZWQuJm5i c3A7IElmIGFuIElDRTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyByZXN0YXJ0IGlzIHBlcmZvcm1lZCB3aXRob3V0IGEgY2hhbmdlIGluIHRscy1p ZCBvciBmaW5nZXJwcmludCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlbiB0aGUgc2FtZSBEVExTIGNvbm5lY3Rpb24gaXMgY29udGludWVk IG92ZXIgdGhlIG5ldyBJQ0U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY2hhbm5lbC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+SSB0aGluayB0aGUg YmVzdCBpbnRlcnByZXRhdGlvbiBvZiB0aGlzIGlzIHRoYXQgaWYgdGxzLWlkIGlzIG5vdCBwcmVz ZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+KGFuZCBoZW5jZSB1bmNoYW5nZWQpIHRoZW4gSUNF IHJlc3RhcnQgZG9lcyBub3QgY2F1c2UgRFRMUyByZXN0YXJ0LjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoaXMgaXMgYWxzbyBteSBtZW1vcnkgb2YgdGhlIGNvbnNlbnN1cyBpbiBSVENXRUIuIElu IGFueSBjYXNlLCB0aGVzZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnR3byBkb2N1bWVudHMgY2xl YXJseSBtdXN0IG1hdGNoLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwPk15IG9ic2VydmF0aW9ucy9yZWNvbW1lbmRhdGlvbnM6PG86 cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooSXNzdWUgMWEpIEVLUiBpcyBjb3JyZWN0IHRoYXQg dGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRoZSBidWxsZXQgZnJvbSBKU0VQIG5lZWRzIHRvIGJlIHJl bW92ZWQgc28gYXMgdG8gZW5hYmxlIGludGVyb3BlcmF0aW9uIHdpdGggbm9uLUpTRVAgaW1wbGVt ZW50YXRpb25zLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0O21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCihJc3N1ZSAxYikgQWRkaXRpb25hbGx5IHRoZSBmaW5hbCBzZW50ZW5jZSBv ZiB0aGF0IGJ1bGxldCAoJnF1b3Q7SWYgdGhpcyBpcyBhbiBhbnN3ZXIsIHRoZSB0bHMtaWQgdmFs dWUsIGlmIHByZXNlbnQsIE1VU1QgYmUgdGhlIHNhbWUgYXMgaW4gdGhlIG9mZmVyJnF1b3Q7KSBj b25mbGljdHMgd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiB0bHMtaWQgKCZxdW90O3RoZSBvZmZlcmVy IGFuZCBhbnN3ZXJlciBnZW5lcmF0ZSB0aGVpciBvd24gbG9jYWwgJ3Rscy1pZCcgYXR0cmlidXRl DQogdmFsdWVzLCBhbmQgdGhlIGNvbWJpbmF0aW9uIG9mIGJvdGggdmFsdWVzIGlkZW50aWZ5IHRo ZSBEVExTIGFzc29jaWF0aW9uJnF1b3Q7KS4gSW4gdGhpcyBjYXNlLCB0aGUgRFRMUy1TRFAgZG9j dW1lbnQgd291bGQgYXBwZWFyIHRvIGJlIGNvcnJlY3QgKHRoZSBmYWN0IHRoYXQgdGhlIHR3byBw YXJ0aWVzIGNob29zZSBkaWZmZXJlbnQgSURzIGlzIGludGVncmFsIHRvIHRoZSBtZWNoYW5pc20n cyBkZXNpZ24pLCBzbyBKU0VQIG5lZWRzIHRvIGNoYW5nZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooSXNzdWUgMWMpIFRo ZSBjcnV4IG9mIHRoZSBtYXR0ZXI6IGRvZXMgSUNFIHJlc3RhcnQgY2F1c2UgRFRMUyB0byByZXN0 YXJ0PyBUaGUgcHJpbWFyeSByYXRpb25hbGUgb3V0bGluZWQgaW4gUkZDNTI0NSBmb3IgcmVzdGFy dGluZyBJQ0UgaXMgY2hhbmdpbmcgdGhlIGRlc3RpbmF0aW9uIChJUCBhZGRyZXNzIG9yIHBvcnQp IG9mIGFuIG9uZ29pbmcgbWVkaWEgc3RyZWFtIC0tIHdoaWNoIHdvdWxkIGNvbW1vbmx5IGludm9s dmUgY2hhbmdpbmcgdG8gYQ0KIGRpZmZlcmVudCBwaHlzaWNhbCBkZXZpY2UuIFdoaWxlIGl0IHdv dWxkLCBpbiB0aGVvcnksIGJlIHBvc3NpYmxlIHRvIHRyYW5zZmVyIHRoZSBUTFMgc3RhdGUgYXNz b2NpYXRlZCB3aXRoIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gZGV2aWNlcywgdGhpcyBpcyByYXRo ZXIgY3VtYmVyc29tZSAoYW5kLCBhcyBmYXIgYXMgSSBrbm93LCBub3QgZ2VuZXJhbGx5IHN1cHBv cnRlZCBieSBUTFMgbGlicmFyaWVzKS4gRnJvbSB0aGF0IHBlcnNwZWN0aXZlLA0KIGl0IGlzIG15 IG9waW5pb24gdGhhdCB0aGUgRFRMUy1TRFAgZG9jdW1lbnQgaXMgY29ycmVjdCB0aGF0IGFuIElD RSByZXN0YXJ0IG5lY2Vzc2l0YXRlcyBhIG5ldyBEVExTIGNvbm5lY3Rpb247IGFuZCBJIGNvbmNs dWRlIHRoYXQgSlNFUCBuZWVkcyB0byBjaGFuZ2UuPG86cD48L286cD48L2xpPjwvb2w+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPklzc3VlIDIgKHF1b3RpbmcgRUtSKTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT4yLiBTIDQgc2F5czo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlIG11eCBjYXRlZ29yeSBbSS1E LmlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlc10gZm9yIHRoZSAndGxzLTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpZCcgYXR0cmlidXRlIGlzICdJREVOVElDQUwnLCB3 aGljaCBtZWFucyB0aGF0IHRoZSBhdHRyaWJ1dGUgdmFsdWU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgbXVzdCBiZSBpZGVudGljYWwgYWNyb3NzIGFsbCBtZWRpYSBkZXNjcmlw dGlvbnMgYmVpbmcgbXVsdGlwbGV4ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgW0ktRC5pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLW5lZ290aWF0aW9uXS48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGlzIG5vdCBhY3R1 YWxseSB3aGF0IEpTRVAgcmVxdWlyZXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRpZmZlcmVudCBjYXRlZ29yaWVzLiZu YnNwOyBUbyBhdm9pZCB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbiB3aGVuPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGJ1bmRsaW5nLCBhdHRyaWJ1dGVzIG9mIGNhdGVnb3J5IElE RU5USUNBTCBvciBUUkFOU1BPUlQgTVVTVCBOT1QgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgcmVwZWF0ZWQgaW4gYnVuZGxlZCBtPSBzZWN0aW9ucywgcmVwZWF0aW5nIHRo ZSBndWlkYW5jZSBmcm9tPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFtJLUQu aWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbl0sIFNlY3Rpb24gOC4xLiZuYnNwOyBU aGlzIGluY2x1ZGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+SSBzdXNwZWN0IHRoaXMgaXMgb2xkIHRleHQuPG86cD48L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwPjxicj4NCihJc3N1ZSAyKSBKU0VQIGlzIGFsaWduZWQgd2l0aCBkcmFm dC1pZXRmLW1tdXNpYy1zZHAtYnVuZGxlLW5lZ290aWF0aW9uLTM4LCB3aGlsZSBEVExTLVNEUCBk b2VzIG5vdC4gVGhpcyBpcyBhIGxhcmdlbHkgYWVzdGhldGljIGRlY2lzaW9uIChhbHRob3VnaCB0 aGUgSlNFUC9CVU5ETEUgYXBwcm9hY2ggZG9lcyBzYXZlIGEgdGlueSBoYW5kZnVsIG9mIGJ5dGVz KSwgYnV0IEkgdGhpbmsgY2hhbmdpbmcgb25lIGRvY3VtZW50IChEVExTLVNEUCkgbWFrZXMNCiBt b3JlIHNlbnNlIHRoYW4gY2hhbmdpbmcgdHdvLiAoSSBzdXNwZWN0IHRoZSBCVU5ETEUgZm9ybXVs YXRpb24gbW9yZSBjbG9zZWx5IHRyYWNrcyBjb25zZW5zdXMgYW55d2F5KS48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+L2E8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2lj QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t dXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B562869A2ESESSMB109erics_-- From nobody Sun Sep 3 13:57:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EF31241F3 for ; Sun, 3 Sep 2017 13:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0KtCHn_j90i for ; Sun, 3 Sep 2017 13:57:06 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842E513233D for ; Sun, 3 Sep 2017 13:57:06 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id s187so18209688ywf.2 for ; Sun, 03 Sep 2017 13:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/hD00zfeDKArOhLLA1EPxEa6UP6gyxzuAf7BRKLJFms=; b=n0pR4VtFgq74+lk4iM8aL5zJoV7IqTAA6P86qWd3VXsQtNnct4AEPWffp+dDTl/DZJ 5OO55O8SAqf7CfT3YGjoO6FClNHzN6PONAHTmi3ZCB++GKf2/FjGTHdWODU8wu5e6cEz ptnIrjs22otK+QK5vjIegSZ2W1qmP+rwr4Iw9uGUGGz83KseR4Z0UtEP1kf/oIaKWK2B yt8jlzzPb43ksK20AOLI3iNc+1E7VNACQiun0R4iJEEKHU4RogtnN08iH8mXUzzEyYIh YZaR2PUAbXxqiaEnSG0Sf+DBwq1CC85p1nfrWbZ9wwL1eKHpPN2op1Tjsavb+/OIGn31 Ho4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/hD00zfeDKArOhLLA1EPxEa6UP6gyxzuAf7BRKLJFms=; b=fYyLx2kvMmLjyzteAM/kWnsryK4EKKCj00A8No0hem7gdKQBAALm2WKvybmsDiO5N3 J/v0ivwEQwsXsjDkHwd1z70jGOSKYuEE6ppe8cC+f/cL0yUcQ6DyAMgCQhqCKHKhPbbx D1ppbLvClwNuu/f9evRxeiIKoGHKPjcbgayXzQQftDRfZcR8SQZjmd03lEv604ifSQbh fFxCSnbIcEv4aEWkk3N2u8A21c0uavSUe2CEbSac4EZnnxwYj8YcN3K+Ykv18gvqu2Cv KJFtKJqqRdXKooke7k/g705F6vZXmkT09wa2L/WmDe3BBUwZLeSme6krpL1H7YwUvwHC IwGw== X-Gm-Message-State: AHPjjUhwoVFawlicwbjvp7/zaE3xSbe/huNSK5apPNfg2pzBqGfoQD2k lsHDCcJffUK0Q5mkJqrDXSbBqpkzvCeLgAo= X-Google-Smtp-Source: ADKCNb6Z002T8mWFoRn0R/aRcrURUplShJrXM6n9jjrFJ6iOXIZQdsA1vVy+lwgLWmQSEaUTnKQrN0r5BqF8XawM8a0= X-Received: by 10.37.160.144 with SMTP id y16mr1920028ybh.339.1504472225769; Sun, 03 Sep 2017 13:57:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sun, 3 Sep 2017 13:56:25 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Sun, 3 Sep 2017 13:56:25 -0700 Message-ID: To: Christer Holmberg Cc: Bernard Aboba , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="089e08289998978b3e05584f3c1a" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 20:57:10 -0000 --089e08289998978b3e05584f3c1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Sep 3, 2017 at 1:31 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >In my opinion, things should behave as follows. The semantics of the > indicators are: > > > > > >tls-id old ufrag new ufrag > > >------ -------------------------------------------------- > > >none No change ICE restart, same DTLS > > >old ICE restart ICE restart, same DTLS > > >new Error ICE restart, new DTLS > > > > > >However, in all cases but one, the answer MUST match the offer. I.e., th= e > answer must > > >do an ICE restart iff the offer had one and a new DTLS connection iff th= e > offer had one. > > >However, if the answerer does not support tls-id, then it might respond > to a new tls-id > > >with no tls-id, which means it does not intend to make a new DTLS > connection. The offerer > > >can either accept that or tear everything down. > > > > > >I agree that the specs do not currently make this clear > > > > Because that=E2=80=99s not how the procedures are currently written. > Again, JSEP and this document are in conflict, hence it's unclear. > Now, based on your suggestion, if the offerer doesn=E2=80=99t know whethe= r the > answerer supports tls-id, does that mean that the only way for the offere= r > to ensure that the re-offer will trigger a new DTLS association is by > modifying the fingerprint set in the offer? > That's true in any case, because we have implementations which behave that way and we can't change them. > And, if the offerer does not change the fingerprint set, does not receive > tls-id in the answer, and chooses to =E2=80=9Caccept=E2=80=9D it, would t= he offerer then > still start using (in subsequent offers/answers etc) the new tls-id, even > if a new DTLS association was not created? > I'm not sure it matters, as in this case the answerer doesn't care about tls-id. -Ekr > OR, would the offerer consider the new tls-id =E2=80=9Crejected=E2=80=9D = by the answerer, > and continue using the old tls-id? > > > > Regards, > > > > Christer > > > > > > > > > > > > > > On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > >Yes. Indeed, that's the crux of the disagreement between JSEP and this > document > > > > So, just to clarify: in your opinion, if an endpoint receives an > offer/answer WITHOUT a tls-id, but with a NEW ufrag (read: ICE restart), > the new urfag will NOT trigger a new DTLS association. Right? > > > > Regards, > > > > Christer > > > > > > > > On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi Ekr, > > > > What if the remote peer does not support/include the tls-id attribute? > > > > Regards, > > > > Christer > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Eric > Rescorla > *Sent:* 02 September 2017 22:36 > *To:* Bernard Aboba > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] DTLS-SDP and JSEP Conflicts > > > > > > > > On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba > wrote: > > On Issue 1, Adam said: > > > > " > > 1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream = -- > which would commonly involve changing to a different physical device. Whi= le > it would, in theory, be possible to transfer the TLS state associated wit= h > the connection between devices, this is rather cumbersome (and, as far as= I > know, not generally supported by TLS libraries). From that perspective, i= t > is my opinion that the DTLS-SDP document is correct that an ICE restart > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > " > > > > [BA] Agree that for consistency, it is best for an ICE restart to > necessitate a new DTLS connection, since an ICE restart can result in > connection to a different device (and the need for a new DTLS connection)= . > > > > I'm not persuaded by this: the primary reason for an ICE restart is not > changing devices but rather trying to deal with topology changes and/or > connectivity check failures. If you actually *do* change devices, then it= 's > also quite probably you will have a new certificate fingerprint, in which > case you will get a new DTLS connection in any case. In other words, tls-= id > should be used to say "I want a new DTLS connection in spite of the > fingerprint being the same" (what JSEP says), not "I want to keep the DTL= S > connection even though I am doing an ICE restart" > > > > -Ekr > > > > > > On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: > > MMUSIC -- > > [I will be posting a separate message to RTCWEB directing interested > parties to discuss this issue on the MMUSIC mailing list] > > During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some > conflicts between the procedures in DTLS-SDP and JSEP were identified. Th= is > note is an attempt to summarize them. I have also made an initial proposa= l, > for each conflict, regarding which document needs to change, in and which > way. > > Issue 1 (quoting EKR), which raises a couple of additional sub-issues: > > 1. Assuming I understand this document correctly, it conflicts with > > the guidance in JSEP. Specifically, S 4 says: > > > > No default value is defined for the SDP 'tls-id' attribute. > > Implementations that wish to use the attribute MUST explicitly > > include it in SDP offers and answers. If an offer or answer does not > > contain a 'tls-id' attribute (this could happen if the offerer or > > answerer represents an existing implementation that has not been > > updated to support the 'tls-id' attribute), unless there is another > > mechanism to explicitly indicate that a new DTLS association is to be > > established, a modification of one or more of the following > > characteristics MUST be treated as an indication that an endpoint > > wants to establish a new DTLS association: > > > > o DTLS setup role; or > > > > o fingerprint set; or > > > > o local transport parameters; or > > > > o ICE ufrag value > > > > This seems to say that if there is no tls-id attribute, then an ICE resta= rt > > (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't > > incredibly clear on this point, but 5.7.3 seems to say that tls-id > > need not be present: > > > > * tls-id value, which MUST be set according to > > [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer > > and the tls-id value is different from that presently in use, > > the DTLS connection is not being continued and the remote > > description MUST be part of an ICE restart, together with new > > ufrag and password values. If this is an answer, the tls-id > > value, if present, MUST be the same as in the offer. > > > > I believe that the first sentence is in error, as we clearly > > can't have JSEP implementations requiring that tls-id be present. > > > > ... > > > > o If the remote DTLS fingerprint has been changed or the tls-id has > > changed, tear down the DTLS connection. This includes the case > > when the PeerConnection state is "have-remote-pranswer". If a > > DTLS connection needs to be torn down but the answer does not > > indicate an ICE restart or, in the case of "have-remote-pranswer", > > new ICE credentials, an error MUST be generated. If an ICE > > restart is performed without a change in tls-id or fingerprint, > > then the same DTLS connection is continued over the new ICE > > channel. > > > > I think the best interpretation of this is that if tls-id is not present > > (and hence unchanged) then ICE restart does not cause DTLS restart. > > This is also my memory of the consensus in RTCWEB. In any case, these > > two documents clearly must match. > > > > My observations/recommendations: > > 1. (Issue 1a) EKR is correct that the first sentence of the bullet > from JSEP needs to be removed so as to enable interoperation with non-= JSEP > implementations. > 2. (Issue 1b) Additionally the final sentence of that bullet ("If this > is an answer, the tls-id value, if present, MUST be the same as in the > offer") conflicts with the definition of tls-id ("the offerer and answ= erer > generate their own local 'tls-id' attribute values, and the combinatio= n of > both values identify the DTLS association"). In this case, the DTLS-SD= P > document would appear to be correct (the fact that the two parties cho= ose > different IDs is integral to the mechanism's design), so JSEP needs to > change. > 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE = is > changing the destination (IP address or port) of an ongoing media stre= am -- > which would commonly involve changing to a different physical device. = While > it would, in theory, be possible to transfer the TLS state associated = with > the connection between devices, this is rather cumbersome (and, as far= as I > know, not generally supported by TLS libraries). From that perspective= , it > is my opinion that the DTLS-SDP document is correct that an ICE restar= t > necessitates a new DTLS connection; and I conclude that JSEP needs to > change. > > > > Issue 2 (quoting EKR): > > 2. S 4 says: > > > > The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- > > id' attribute is 'IDENTICAL', which means that the attribute value > > must be identical across all media descriptions being multiplexed > > [I-D.ietf-mmusic-sdp-bundle-negotiation]. > > > > This is not actually what JSEP requires: > > > > different categories. To avoid unnecessary duplication when > > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > > repeated in bundled m=3D sections, repeating the guidance from > > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes > > > > I suspect this is old text. > > > (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-3= 8, > while DTLS-SDP does not. This is a largely aesthetic decision (although t= he > JSEP/BUNDLE approach does save a tiny handful of bytes), but I think > changing one document (DTLS-SDP) makes more sense than changing two. (I > suspect the BUNDLE formulation more closely tracks consensus anyway). > > > > /a > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > --089e08289998978b3e05584f3c1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Sep 3, 2017 at 1:31 PM, Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>In my opinion, things should behave as follows. = The semantics of the indicators are:

>=C2=A0

>tls-id =C2=A0 =C2=A0 old ufrag =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0new ufrag=C2=A0<= u>

>------ =C2=A0 =C2=A0 ---------------------------= -----------------------

>none =C2=A0 =C2=A0 =C2=A0 No change =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart, sam= e DTLS

>old =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart, sam= e DTLS

>new =C2=A0 =C2=A0 =C2=A0 =C2=A0Error =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IC= E restart, new DTLS

>=C2=A0

>However, in all cases but one, the answer MUST m= atch the offer. I.e., the answer must

>do an ICE restart iff the offer had one and a ne= w DTLS connection iff the offer had one.

>However, if the answerer does not support tls-id= , then it might respond to a new tls-id

>with no tls-id, which means it does not intend t= o make a new DTLS connection. The offerer

>can either accept that or tear everything down.<= u>

>=C2=A0

>I agree that the specs do not currently make thi= s clear

=C2=A0

Because that=E2=80=99s not how the procedures are c= urrently written.


Again, JSEP and this document are in conflict, hence = it's unclear.

=C2=A0
<= div lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">

Now, based on your suggestion, if the offerer doesn= =E2=80=99t know whether the answerer supports tls-id, does that mean that t= he only way for the offerer to ensure that the re-offer will trigger a new DTLS association is by modifying the fingerprint set in= the offer?


That's true in any case, because we have implementation= s which behave that way and we can't change them.

<= div>=C2=A0

And, if the offerer does not change the fingerprint= set, does not receive tls-id in the answer, and chooses to =E2=80=9Caccept= =E2=80=9D it, would the offerer then still start using (in subsequent offers/answers etc) the new tls-id, even if a new DTLS association was not= created?

<= br>
I'm not sure it matters, as in this case the answerer doe= sn't care about tls-id.

-Ekr


OR, would the offerer consider the new tls-id =E2= =80=9Crejected=E2=80=9D by the answerer, and continue using the old tls-id?=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>Yes. Indeed= , that's the crux of the disagreement between JSEP and this document=

=C2=A0

So, just to clarify: in your opinion, if an endpoin= t receives an offer/answer WITHOUT a tls-id, but with a NEW ufrag (read: ICE restart), the new urfag will NOT trigger a new DTLS association= . Right?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi Ekr,

=C2=A0

What if the remote peer does not supp= ort/include the tls-id attribute?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = mmusic [mailto:mmusi= c-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:

On Issue 1, Adam said:=C2=A0

=C2=A0

"

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (Issue 1c) The crux of the matter: does ICE= restart cause DTLS to restart? The primary rationale outlined in RFC5245 f= or restarting ICE is changing the destination (IP address or port) of an on= going media stream -- which would commonly involve changing to a different physical device. While it would, = in theory, be possible to transfer the TLS state associated with the connec= tion between devices, this is rather cumbersome (and, as far as I know, not= generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is corr= ect that an ICE restart necessitates a new DTLS connection; and I conclude = that JSEP needs to change.

"

=C2=A0

[BA] Agree that for consistency, it is best for an I= CE restart to necessitate a new DTLS connection, since an ICE restart can r= esult in connection to a different device (and the need for a new DTLS connection).=C2=A0=C2=A0

=C2=A0

I'm not persuaded by this: the primary reason fo= r an ICE restart is not changing devices but rather trying to deal with top= ology changes and/or connectivity check failures. If you actually *do* change devices, then it's also quite probably you will h= ave a new certificate fingerprint, in which case you will get a new DTLS co= nnection in any case. In other words, tls-id should be used to say "I = want a new DTLS connection in spite of the fingerprint being the same" (what JSEP says), not "I want to kee= p the DTLS connection even though I am doing an ICE restart"=

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <adam@nostrum.com> = wrote:

MMUSIC --

[I will be posting a separate message to RTCWEB directing interested par= ties to discuss this issue on the MMUSIC mailing list]

During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified som= e conflicts between the procedures in DTLS-SDP and JSEP were identified. Th= is note is an attempt to summarize them. I have also made an initial propos= al, for each conflict, regarding which document needs to change, in and which way.

Issue 1 (quoting EKR), which raises a couple of additional sub-issues:

1. Assuming I understand this document correctly, it conflicts with=

the guidance in JSEP. Specifically, S 4 says:
=C2=A0
=C2=A0=C2=A0 No default value is defined for the SDP 'tls-id' =
attribute.
=C2=A0=C2=A0 Implementations that wish to use the attribute MUST expli=
citly
=C2=A0=C2=A0 include it in SDP offers and answers.=C2=A0 If an offer o=
r answer does not
=C2=A0=C2=A0 contain a 'tls-id' attribute (this could happen i=
f the offerer or
=C2=A0=C2=A0 answerer represents an existing implementation that has n=
ot been
=C2=A0=C2=A0 updated to support the 'tls-id' attribute), unles=
s there is another
=C2=A0=C2=A0 mechanism to explicitly indicate that a new DTLS associat=
ion is to be
=C2=A0=C2=A0 established, a modification of one or more of the followi=
ng
=C2=A0=C2=A0 characteristics MUST be treated as an indication that an =
endpoint
=C2=A0=C2=A0 wants to establish a new DTLS association:<=
/pre>

=C2=A0


=C2=A0=C2=A0 o=C2=A0 DTLS setup role; or


=C2=A0


=C2=A0=C2=A0 o=C2=A0 fingerprint set; or


=C2=A0


 =C2=A0=C2=A0o=C2=A0 local transport parameters; or

=C2=A0


=C2=A0=C2=A0 o=C2=A0 ICE ufrag value


=C2=A0


This seems to say that if there is no tls-id attribute, then an ICE re=
start


(which necessitates a ufrag change) requires a DTLS restart. JSEP isn&=
#39;t


incredibly clear on this point, but 5.7.3 seems to say that tls-id<=
/u>


need not be present:


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 tls-id value, which MUST be set=
 according to


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [I-D.ietf-mmusic-dtls=
-sdp], Section 5.=C2=A0 If this is a re-offer


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the tls-id value =
is different from that presently in use,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the DTLS connection i=
s not being continued and the remote


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description MUST be p=
art of an ICE restart, together with new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ufrag and password va=
lues.=C2=A0 If this is an answer, the tls-id


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value, if present, MU=
ST be the same as in the offer.


=C2=A0


I believe that the first sentence is in error, as we clearly=



can't have JSEP implementations requiring that tls-id be present.<=
u>


=C2=A0


=C2=A0=C2=A0 ...


=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0o=C2=A0 If the remote DTLS fingerprint has been chan=
ged or the tls-id has


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 changed, tear down the DTLS connection.=
=C2=A0 This includes the case


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when the PeerConnection state is "=
have-remote-pranswer".=C2=A0 If a


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DTLS connection needs to be torn down b=
ut the answer does not


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indicate an ICE restart or, in the case=
 of "have-remote-pranswer",


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 new ICE credentials, an error MUST be g=
enerated.=C2=A0 If an ICE


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 restart is performed without a change i=
n tls-id or fingerprint,


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then the same DTLS connection is contin=
ued over the new ICE


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 channel.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 


I think the best interpretation of this is that if tls-id is not prese=
nt


(and hence unchanged) then ICE restart does not cause DTLS restart.=



This is also my memory of the consensus in RTCWEB. In any case, these<=
u>


two documents clearly must match.

=C2=A0

My observations/recommendations:

  1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP n= eeds to be removed so as to enable interoperation with non-JSEP implementat= ions.
  2. (Issue 1b) Additionally the final sentence of that bullet ("If this is= an answer, the tls-id value, if present, MUST be the same as in the offer&= quot;) conflicts with the definition of tls-id ("the offerer and answe= rer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association&q= uot;). In this case, the DTLS-SDP document would appear to be correct (the = fact that the two parties choose different IDs is integral to the mechanism= 's design), so JSEP needs to change.
  3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? = The primary rationale outlined in RFC5245 for restarting ICE is changing th= e destination (IP address or port) of an ongoing media stream -- which woul= d commonly involve changing to a different physical device. While it would, in theory, be possible to trans= fer the TLS state associated with the connection between devices, this is r= ather cumbersome (and, as far as I know, not generally supported by TLS lib= raries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart= necessitates a new DTLS connection; and I conclude that JSEP needs to chan= ge.

=C2=A0

Issue 2 (quoting EKR):

2. S 4 says:
=C2=A0
=C2=A0=C2=A0 The mux category [I-D.ietf-mmusic-sdp-mux-attributes=
] for the 'tls-
=C2=A0=C2=A0 id' attribute is 'IDENTICAL', which means tha=
t the attribute value
=C2=A0=C2=A0 must be identical across all media descriptions being mul=
tiplexed
=C2=A0=C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiation].<=
/u>
=C2=A0
This is not actually what JSEP requires:
=C2=A0
=C2=A0=C2=A0 different categories.=C2=A0 To avoid unnecessary duplicat=
ion when
=C2=A0=C2=A0 bundling, attributes of category IDENTICAL or TRANSPORT M=
UST NOT be
=C2=A0=C2=A0 repeated in bundled m=3D sections, repeating the guidance=
 from
=C2=A0=C2=A0 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.=
1.=C2=A0 This includes
=C2=A0
I suspect this is old text.


(Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiatio= n-38, while DTLS-SDP does not. This is a largely aesthetic decision (althou= gh the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think= changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more close= ly tracks consensus anyway).

=C2=A0

/a

=C2=A0

_____________________= __________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic

=C2=A0


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

=C2=A0

=C2=A0

=C2=A0


--089e08289998978b3e05584f3c1a-- From nobody Sun Sep 3 14:17:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0519D126B71 for ; Sun, 3 Sep 2017 14:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nw_SFI3c7VYO for ; Sun, 3 Sep 2017 14:17:17 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E631320B5 for ; Sun, 3 Sep 2017 14:17:17 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id r187so12927309pfr.3 for ; Sun, 03 Sep 2017 14:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P5oignV+0J89TswweC+JibNaS3Fu0trDXS9btDyDQZY=; b=saKJbu1aOu+XejMgo4sOT1gezfhS0a9n15ye3HzToDaYZppRTpJ/KzD5OmL98UEoJl rBtxAAeOF1mEK7pNpQky9+/1UgXEHhrmhn6GAq5Xfxd76uSys36qekOYuljUA2xesSFF DUg9hlzVasjjeXG7kvJd0dI4qPmWuSefCeN9MZSQhUsqojb4J/VubKlNLuir14lRQ53/ YVGZWGFjA28yZscAOYXODF6Gwr5FbHDbuYSDUZ2b96WaMPFafzd0dkuMk2dn9mBMmJ7L zYxvTIV8kyCAozfa5bsTREyEUfpL3q8lJcdJdZmfJxjWEcCcqZ8blLyc/GVgNi5/sWKS uf0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P5oignV+0J89TswweC+JibNaS3Fu0trDXS9btDyDQZY=; b=nl3NlO7SnVhzs3j/rtOwrOVen9We+eySA9Lm8lG8J5lNdsptbTWNFdvhujWUzybpFJ /QE8fWO1INp3rgaVyahxwsWsHfpGph0nWgeTm1dUESiJ3lEcTPj0K+pzUA304Vy+XVpL M6cm8NM0/j0PG8XYgn5rnMMw6/ERF/LES3E5jNr+o/XUWuXFuvepaqDP5Yw+vkW4NANq u1my07bP1xLFycEuWPd10HIqr7kHe+SUQqvNkQHN3KcQJLRf8X2gTSXORnnSWN/HOzh9 PW8yGWIJ1h+pqinBF6DgeIiziJ1KSfs+/0M3Fk/N8qxGrfSf5Pd68wrHicP8qXhb2Yqo Gs+A== X-Gm-Message-State: AHPjjUgVj762TtIBRELR6KB7mh6T39ana+8tIDiQUnueo0zpRMWXX6N8 2519mMVVMoadhThTPKg= X-Received: by 10.98.0.77 with SMTP id 74mr9638566pfa.132.1504473436571; Sun, 03 Sep 2017 14:17:16 -0700 (PDT) Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com. [209.85.192.173]) by smtp.gmail.com with ESMTPSA id s186sm8072749pfb.110.2017.09.03.14.17.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Sep 2017 14:17:15 -0700 (PDT) Received: by mail-pf0-f173.google.com with SMTP id n73so12975317pfj.0 for ; Sun, 03 Sep 2017 14:17:15 -0700 (PDT) X-Google-Smtp-Source: ADKCNb633hO1zVI8KgPmvvxpAdAD3yYrOzeBxJhrrsHWUFa4nWgxQFc8xZU7IRjKmz9XlQEP6mY9F3jB05vdqumd0Tc= X-Received: by 10.99.125.26 with SMTP id y26mr1413022pgc.413.1504473435141; Sun, 03 Sep 2017 14:17:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Sun, 3 Sep 2017 14:17:14 -0700 (PDT) Received: by 10.100.191.8 with HTTP; Sun, 3 Sep 2017 14:17:14 -0700 (PDT) In-Reply-To: <09F593D8-CD5E-46FD-905E-49D351A74A7E@iii.ca> References: <28A313A2-AC1C-4E09-9604-C45AE63A37AF@iii.ca> <09F593D8-CD5E-46FD-905E-49D351A74A7E@iii.ca> From: Roman Shpount Date: Sun, 3 Sep 2017 17:17:14 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: mmusic Content-Type: multipart/alternative; boundary="94eb2c1b6f48acfb2405584f84f5" Archived-At: Subject: Re: [MMUSIC] Question about global uniqueness of dtls-id X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Sep 2017 21:17:19 -0000 --94eb2c1b6f48acfb2405584f84f5 Content-Type: text/plain; charset="UTF-8" Hi, On Sep 1, 2017 1:28 PM, "Cullen Jennings" wrote: I don't think that works for a bunch of reasons but to start with the 2nd offer to A would not have the right information in the o= lines of the the original offer/answer. In many cases (including WebRTC) that would cause it not to work as a re-offer. Other issues like it A was receiving video, the old I frame state might end up getting used. If A was sending, it would not know the the other end was now missing reference frames. Third party call control is something that is widely used as well. You are correct that offer generation requires that information in o= line must be preserved, but I am not aware of any reason why offer with non matching o= line will not be processed if received from remote end point. This is very common and will likely cause interop problems if prohibited. I think new I frame should be always sent when new DTLS association is established. I need to double check but I think it is already required after ICE restart. If not, new I frame is a good idea after ICE restart or communication transport 5 tuple change. SIP can deal with that by using the invite with replaces stuff from rfc3891 so that the 2nd offer sent to A can clearly be a new session not a reoffer on the old one. Similar things would be done by webrtc so it could deal with it by just creating a new PC for the 2nd offer and transfering the tracks over to the new PC. Replaces header support is optional and it is not always enabled. In any case, despite the fact that some call scenarios can be implemented using other methods, third party call control is widely deployed and used, which means offer/answer compliant end points would have to deal with such scenarios. Section 5.2.2. of JSEP discussed this a bit how the o= lines need to be the same for a reoffer. This section describes how offer is generated by JSEP compliant end points. I do not think it puts those limitations on what offers should be processed when received from remote, not necessarily JSEP compliant, end points, such as WebRTC gateways. Regards, Roman Shpount --94eb2c1b6f48acfb2405584f84f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Sep 1, 2017 1:28 = PM, "Cullen Jennings" <fluffy= @iii.ca> wrote:
I don't think that works= for a bunch of reasons but to start with the 2nd offer to A would not have= the right information in the o=3D lines of the the original offer/answer. = In many cases (including WebRTC) that would cause it not to work as a re-of= fer. Other issues like it A was receiving video, the old I frame state migh= t end up getting used. If A was sending, it would not know the the other en= d was now missing reference frames.

Third party call control is someth= ing that is widely used as well. You are correct that offer generation requ= ires that information in o=3D line must be preserved, but I am not aware of= any reason why offer with non matching o=3D line will not be processed if = received from remote end point. This is very common and will likely cause i= nterop problems if prohibited.

I think new I frame should be always sent when new DTLS association = is established. I need to double check but I think it is already required a= fter ICE restart. If not, new I frame is a good idea after ICE restart or c= ommunication transport 5 tuple change.

SIP can deal with that by using the invite with replaces stuff from rfc3891= so that the 2nd offer sent to A can clearly be a new session not a reoffer= on the old one. Similar things would be done by webrtc so it could deal wi= th it by just creating a new PC for the 2nd offer and transfering the track= s over to the new PC.
<= br>
Replaces header support is optional and it is no= t always enabled. In any case, despite the fact that some call scenarios ca= n be implemented using other methods, third party call control is widely de= ployed and used, which means offer/answer compliant end points would have t= o deal with such scenarios.

Section 5.2.2. of JSEP discussed this a bit how the o=3D lines need to be t= he same for a reoffer.
=

This section describes how offer is gene= rated by JSEP compliant end points. I do not think it puts those limitation= s on what offers should be processed when received from remote, not necessa= rily JSEP compliant, end points, such as WebRTC gateways.

Regards,
Roman Shpount
--94eb2c1b6f48acfb2405584f84f5-- From nobody Mon Sep 4 03:14:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15335126E7A for ; Mon, 4 Sep 2017 03:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bJSXCpYUbkGy for ; Mon, 4 Sep 2017 03:14:31 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 2761F1241FC for ; Mon, 4 Sep 2017 03:14:30 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-d4-59ad2784335c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.81.20899.4872DA95; Mon, 4 Sep 2017 12:14:29 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Mon, 4 Sep 2017 12:14:28 +0200 From: Christer Holmberg To: Eric Rescorla CC: Bernard Aboba , "mmusic@ietf.org" Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKbMmOAgAbGf4CAADCNsP//5vyAgACksACAAMvvAIAAKExw///nloCAARKTgA== Date: Mon, 4 Sep 2017 10:14:28 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7t26r+tpIgxv3uC027PvPbLHi9Tl2 i6nLH7M4MHvsnHWX3WPJkp9MHpMftzEHMEdx2aSk5mSWpRbp2yVwZfzY8JK14HhgxYrle5kb GCc4dDFyckgImEjsfDKRFcQWEjjCKHHinG4XIxeQvZhRouXbEcYuRg4ONgELie5/2iA1IgIK Er/+nGABsZkFgiSa+heygJQICxhKnDjDAlFiJHH5+ANmCDtLYueeVawgJSwCKhLXu51BwrwC 1hIvN1xgg9j0lkXi5Kv9TCA1nAKBEtPmlYPUMAqISXw/tYYJYpO4xK0n85kgLhaQWLLnPDOE LSrx8vE/sPGiAnoS7/Z7gpgSAooSy/vlIDr1JG5MncIGEmYG2vqghxMirC2xbOFrZohjBCVO znzCMoFRfBaSXbOQdM9C6J6FpHsWku4FjKyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKj 7uCW31Y7GA8+dzzEKMDBqMTDayy7NlKINbGsuDL3EKMEB7OSCK8NL1CINyWxsiq1KD++qDQn tfgQozQHi5I4r8O+CxFCAumJJanZqakFqUUwWSYOTqkGxqjfN9L6tdMc1BU6+dM/lETw/+lw YWHpyyh6JHpKcbW85ZRMgY0CKn9S+J33G9YxrDl+e2e7ee4iH97zztOMJn9sa2udbWHkoejC sDzLasmtKbc+TI8/duJ837cQM8/a+ws9fVQO/RL8N7uTSVSeK5hBV/TK1a1xT+8cfGGoLhFb dXq5v8U7JZbijERDLeai4kQA/vfELLYCAAA= Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 10:14:34 -0000 Hi, >>> In my opinion, things should behave as follows. The semantics of the >>>indicators are >>> tls-id old ufrag new ufrag >>> >>> ------ -------------------------------------------------- >>> >>> none No change ICE restart, same DTLS >>> >>> old ICE restart ICE restart, same DTLS >>> >>> new Error ICE restart, new DTLS >>> >>> However, in all cases but one, the answer MUST match the offer. I.e., >>>the answer must >>> do an ICE restart iff the offer had one and a new DTLS connection iff >>>the offer had one. >>> However, if the answerer does not support tls-id, then it might >>>respond to a new tls-id >>> with no tls-id, which means it does not intend to make a new DTLS >>>connection. The offerer >>> can either accept that or tear everything down. >>> >>> I agree that the specs do not currently make this clear >> =20 >> Because that=B9s not how the procedures are currently written. > > Again, JSEP and this document are in conflict, hence it's unclear. > =20 >> Now, based on your suggestion, if the offerer doesn=B9t know whether the >>answerer supports tls-id, does that mean that the only way >> for the offerer to ensure that the re-offer will trigger a new DTLS >>association is by modifying the fingerprint set in the offer? > > That's true in any case, because we have implementations which behave >that way and we can't change them. On GitHub you also suggested (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer, even if it supports tls-id, shall not be able to trigger a new DTLS association (read: change the tls-id value). I assume that means the answerer would not be able to change its fingerprint set either, or do anything else that would trigger a new DTLS association? Regards, Christer =20 =20 =20 =20 On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg wrote: Hi, =20 >Yes. Indeed, that's the crux of the disagreement between JSEP and this >document =20 So, just to clarify: in your opinion, if an endpoint receives an offer/answer WITHOUT a tls-id, but with a NEW ufrag (read: ICE restart), the new urfag will NOT trigger a new DTLS association. Right? =20 Regards, =20 Christer =20 =20 =20 On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg wrote: Hi Ekr, =20 What if the remote peer does not support/include the tls-id attribute? =20 Regards, =20 Christer =20 From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: 02 September 2017 22:36 To: Bernard Aboba Cc: mmusic@ietf.org Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts =20 =20 =20 On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba wrote: On Issue 1, Adam said: =20 " 1. =20 (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change. " =20 [BA] Agree that for consistency, it is best for an ICE restart to necessitate a new DTLS connection, since an ICE restart can result in connection to a different device (and the need for a new DTLS connection). =20 =20 I'm not persuaded by this: the primary reason for an ICE restart is not changing devices but rather trying to deal with topology changes and/or connectivity check failures. If you actually *do* change devices, then it's also quite probably you will have a new certificate fingerprint, in which case you will get a new DTLS connection in any case. In other words, tls-id should be used to say "I want a new DTLS connection in spite of the fingerprint being the same" (what JSEP says), not "I want to keep the DTLS connection even though I am doing an ICE restart" =20 -Ekr =20 =20 On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: MMUSIC -- [I will be posting a separate message to RTCWEB directing interested parties to discuss this issue on the MMUSIC mailing list] During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some conflicts between the procedures in DTLS-SDP and JSEP were identified. This note is an attempt to summarize them. I have also made an initial proposal, for each conflict, regarding which document needs to change, in and which way. Issue 1 (quoting EKR), which raises a couple of additional sub-issues: 1. Assuming I understand this document correctly, it conflicts withthe guidance in JSEP. Specifically, S 4 says: No default value is defined for the SDP 'tls-id' attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain a 'tls-id' attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the 'tls-id' attribute), unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, a modification of one or more of the following characteristics MUST be treated as an indication that an endpoint wants to establish a new DTLS association: o DTLS setup role; or o fingerprint set; or o local transport parameters; or o ICE ufrag value This seems to say that if there is no tls-id attribute, then an ICE restart(which necessitates a ufrag change) requires a DTLS restart. JSEP isn'tincredibly clear on this point, but 5.7.3 seems to say that tls-idneed not be present: * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. I believe that the first sentence is in error, as we clearlycan't have JSEP implementations requiring that tls-id be present. ... o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. I think the best interpretation of this is that if tls-id is not present(and hence unchanged) then ICE restart does not cause DTLS restart.This is also my memory of the consensus in RTCWEB. In any case, thesetwo documents clearly must match. =20 My observations/recommendations: 1. (Issue 1a) EKR is correct that the first sentence of the bullet from JSEP needs to be removed so as to enable interoperation with non-JSEP implementations. 2. (Issue 1b) Additionally the final sentence of that bullet ("If this is an answer, the tls-id value, if present, MUST be the same as in the offer") conflicts with the definition of tls-id ("the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association"). In this case, the DTLS-SDP document would appear to be correct (the fact that the two parties choose different IDs is integral to the mechanism's design), so JSEP needs to change. 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS libraries). From that perspective, it is my opinion that the DTLS-SDP document is correct that an ICE restart necessitates a new DTLS connection; and I conclude that JSEP needs to change. =20 Issue 2 (quoting EKR): 2. S 4 says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- id' attribute is 'IDENTICAL', which means that the attribute value must be identical across all media descriptions being multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. This is not actually what JSEP requires: different categories. To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m=3D sections, repeating the guidance from [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes I suspect this is old text. (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38, while DTLS-SDP does not. This is a largely aesthetic decision (although the JSEP/BUNDLE approach does save a tiny handful of bytes), but I think changing one document (DTLS-SDP) makes more sense than changing two. (I suspect the BUNDLE formulation more closely tracks consensus anyway). =20 /a =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic =20 =20 =20 From nobody Mon Sep 4 04:08:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1DD128D0F for ; Mon, 4 Sep 2017 04:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDwFEj4rBCnR for ; Mon, 4 Sep 2017 04:08:30 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2B9126E64 for ; Mon, 4 Sep 2017 04:08:29 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id i66so771496ywc.0 for ; Mon, 04 Sep 2017 04:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c98RZdxK8JJ1SUPO3VXJtw5v0fMe0RW5utw2qiO9nw0=; b=t4lyuqx+F2w5fDmdNNypiIGuBkSinpo/RbVEYlxRvMhVEbHiyRHU5H0GB95VD+7R9D Bee/yaXE13q39V55paBhCgRm62SpEKN83XilpvOMmWsi05Y3rcYsxJ1kA5k7V8wdFado PiWL4uJGfMZ52Qprb/7OLYwwXXCqc9X9sM5dWbCMVUH19bd5HgGYWm3uJVbzf5HKpuxP WcxihweOqUb9s66iXq1wAvp26pT2gZXX7QnoRfwoVnZ02LoZPQcL0zevFIxei5HFnEJ8 446pcoq6A4/7Y0O30LO7DyyERoI99upiA27HvXG1rMrAOEqaldYBCJMqEfo2zK3p3uLq x8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c98RZdxK8JJ1SUPO3VXJtw5v0fMe0RW5utw2qiO9nw0=; b=MeWs4dlB9jbM8Nv3pIjD4kez3T2JNbV1OFhUEj4jADYaVpnL4P5xgZHDDY/jArZsZ4 757fam4x51ze0NjGmbEUJ0nn6P7M7BOme4PzCWaxN2iWxNgtQHs37A4ElwBiv6bjB3z6 sO3Hr5VTi7fqmroPtIjqIgKuL3Ap1dWnxtjTggQCfEDax+sa4uNV08zaO9h0Qut8o6PH AoWDqixNFsEi94WR5Y18rObx4QhwzE49KxrS/+E55+VT/tjRTVFPmfyL/wiIn5dn4dKN +cmwXty9uTVwvhiJFFXpNbneQQXdow7cejEr/mnAeajLCdjWfQZB7XJ1bDo0ZYCODcX0 msPw== X-Gm-Message-State: AHPjjUhO7i1MAwWwBxV/gBfKO5EF79TyDJpGdHh4ofn/y4LsrJqPA7Xq wWQtqHMODYINPw7ORNTmYlmZCqvL7PH8 X-Google-Smtp-Source: ADKCNb7J5jNJMkUV4QQk/x//3z1gDQPSXcnfRssvCjq7AoX2GUBnLxleWKpBxCc4JpxHkz2B9VXrRRB7a1u5ATXYb0A= X-Received: by 10.37.56.194 with SMTP id f185mr147817yba.249.1504523308997; Mon, 04 Sep 2017 04:08:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Mon, 4 Sep 2017 04:07:48 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Mon, 4 Sep 2017 04:07:48 -0700 Message-ID: To: Christer Holmberg Cc: Bernard Aboba , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c09336463b65605585b21ec" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 11:08:35 -0000 --94eb2c09336463b65605585b21ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, that seems like the logical extension of this. Note that this is only in the edge case where the offerer offers an ICE restart, because if the offerer does not, we all agree that you need to keep the existing fingerprint. -Ekr On Mon, Sep 4, 2017 at 3:14 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>> In my opinion, things should behave as follows. The semantics of the > >>>indicators are > >>> tls-id old ufrag new ufrag > >>> > >>> ------ -------------------------------------------------- > >>> > >>> none No change ICE restart, same DTLS > >>> > >>> old ICE restart ICE restart, same DTLS > >>> > >>> new Error ICE restart, new DTLS > >>> > >>> However, in all cases but one, the answer MUST match the offer. I.e., > >>>the answer must > >>> do an ICE restart iff the offer had one and a new DTLS connection iff > >>>the offer had one. > >>> However, if the answerer does not support tls-id, then it might > >>>respond to a new tls-id > >>> with no tls-id, which means it does not intend to make a new DTLS > >>>connection. The offerer > >>> can either accept that or tear everything down. > >>> > >>> I agree that the specs do not currently make this clear > >> > > >> Because that=C2=B9s not how the procedures are currently written. > > > > Again, JSEP and this document are in conflict, hence it's unclear. > > > > >> Now, based on your suggestion, if the offerer doesn=C2=B9t know whethe= r the > >>answerer supports tls-id, does that mean that the only way > >> for the offerer to ensure that the re-offer will trigger a new DTLS > >>association is by modifying the fingerprint set in the offer? > > > > That's true in any case, because we have implementations which behave > >that way and we can't change them. > > On GitHub you also suggested > (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer, > even if it supports tls-id, shall not be able to trigger a new DTLS > association (read: change the tls-id value). I assume that means the > answerer would not be able to change its fingerprint set either, or do > anything else that would trigger a new DTLS association? > > Regards, > > Christer > > > > > > > > > > > > > > On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg > wrote: > > Hi, > > >Yes. Indeed, that's the crux of the disagreement between JSEP and this > >document > > So, just to clarify: in your opinion, if an endpoint receives an > offer/answer WITHOUT a tls-id, but with a NEW ufrag (read: ICE restart), > the new urfag will NOT trigger a new > DTLS association. Right? > > Regards, > > Christer > > > > > > > On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg > wrote: > > Hi Ekr, > > What if the remote peer does not support/include the tls-id attribute? > > Regards, > > Christer > > From: mmusic [mailto:mmusic-bounces@ietf.org] > On Behalf Of Eric Rescorla > Sent: 02 September 2017 22:36 > To: Bernard Aboba > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts > > > > On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba > wrote: > > On Issue 1, Adam said: > > > " > > 1. > (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart= ? > The primary rationale outlined in RFC5245 for restarting ICE is changing > the destination (IP address or port) of an ongoing media stream -- which > would commonly involve changing to a different physical device. While it > would, in theory, be possible to transfer the TLS state associated with > the connection between devices, this is rather cumbersome (and, as far as > I know, not generally supported by TLS > libraries). From that perspective, it is my opinion that the DTLS-SDP > document is correct that an ICE restart necessitates a new DTLS > connection; and I conclude that JSEP needs to change. > " > > > > [BA] Agree that for consistency, it is best for an ICE restart to > necessitate a new DTLS connection, since an ICE restart can result in > connection to a different device (and the need for a new DTLS connection)= . > > > > > > > > > > I'm not persuaded by this: the primary reason for an ICE restart is not > changing devices but rather trying to deal with topology changes and/or > connectivity check failures. If you actually *do* change devices, then > it's also quite probably > you will have a new certificate fingerprint, in which case you will get = a > new DTLS connection in any case. In other words, tls-id should be used to > say "I want a new DTLS connection in spite of the fingerprint being the > same" (what JSEP says), not "I want > to keep the DTLS connection even though I am doing an ICE restart" > > > > -Ekr > > > > > > On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach wrote: > > > > MMUSIC -- > [I will be posting a separate message to RTCWEB directing interested > parties to discuss this issue on the MMUSIC mailing list] > During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some > conflicts between the procedures in DTLS-SDP and JSEP were identified. > This note is an attempt to summarize them. I have also made an initial > proposal, for each conflict, regarding > which document needs to change, in and which way. > Issue 1 (quoting EKR), which raises a couple of additional sub-issues: > > 1. Assuming I understand this document correctly, it conflicts withthe > guidance in JSEP. Specifically, S 4 says: No default value is defined > for the SDP 'tls-id' attribute. Implementations that wish to use the > attribute MUST explicitly include it in SDP offers and answers. If an > offer or answer does not contain a 'tls-id' attribute (this could happe= n > if the offerer or answerer represents an existing implementation that > has not been updated to support the 'tls-id' attribute), unless there i= s > another mechanism to explicitly indicate that a new DTLS association is > to be established, a modification of one or more of the following > characteristics MUST be treated as an indication that an endpoint wants > to establish a new DTLS association: o DTLS setup role; or o > fingerprint set; or o local transport parameters; or o ICE ufrag > value This seems to say that if there is no tls-id attribute, then an ICE > restart(which necessitates a ufrag change) requires a DTLS restart. JSEP > isn'tincredibly clear on this point, but 5.7.3 seems to say that > tls-idneed not be present: * tls-id value, which MUST be set > according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a > re-offer and the tls-id value is different from that presently in > use, the DTLS connection is not being continued and the remote > description MUST be part of an ICE restart, together with new > ufrag and password values. If this is an answer, the tls-id > value, if present, MUST be the same as in the offer. I believe that the > first sentence is in error, as we clearlycan't have JSEP implementations > requiring that tls-id be present. ... o If the remote DTLS > fingerprint has been changed or the tls-id has changed, tear down th= e > DTLS connection. This includes the case when the PeerConnection > state is "have-remote-pranswer". If a DTLS connection needs to be > torn down but the answer does not indicate an ICE restart or, in the > case of "have-remote-pranswer", new ICE credentials, an error MUST b= e > generated. If an ICE restart is performed without a change in tls-i= d > or fingerprint, then the same DTLS connection is continued over the > new ICE channel. I think the best interpretation of this is tha= t > if tls-id is not present(and hence unchanged) then ICE restart does not > cause DTLS restart.This is also my memory of the consensus in RTCWEB. In > any case, thesetwo documents clearly must match. > > > My observations/recommendations: > > 1. (Issue 1a) EKR is correct that the first sentence of the bullet from > JSEP needs to be removed so as to enable interoperation with non-JSEP > implementations. > 2. (Issue 1b) Additionally the final sentence of that bullet ("If this is > an answer, the tls-id value, if present, MUST be the same as in the > offer") conflicts with the definition of tls-id ("the offerer and answere= r > generate their own local 'tls-id' attribute values, and the combination > of both values identify the DTLS association"). In this case, the DTLS-SD= P > document would appear to be correct (the fact that the two parties choose > different IDs is integral to the mechanism's > design), so JSEP needs to change. > 3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to > restart? The primary rationale outlined in RFC5245 for restarting ICE is > changing the destination (IP address or port) of an ongoing media stream > -- which would commonly > involve changing to a different physical device. While it would, in > theory, be possible to transfer the TLS state associated with the > connection between devices, this is rather cumbersome (and, as far as I > know, not generally supported by TLS libraries). From > that perspective, it is my opinion that the DTLS-SDP document is correct > that an ICE restart necessitates a new DTLS connection; and I conclude > that JSEP needs to change. > > > Issue 2 (quoting EKR): > > 2. S 4 says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for > the 'tls- id' attribute is 'IDENTICAL', which means that the attribute > value must be identical across all media descriptions being multiplexed > [I-D.ietf-mmusic-sdp-bundle-negotiation]. This is not actually what JSEP > requires: different categories. To avoid unnecessary duplication when > bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be > repeated in bundled m=3D sections, repeating the guidance from > [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes I > suspect this is old text. > > > (Issue 2) JSEP is aligned with > draft-ietf-mmusic-sdp-bundle-negotiation-38, while DTLS-SDP does not. Thi= s > is a largely aesthetic decision (although the JSEP/BUNDLE approach does > save a tiny handful of bytes), but I think changing one document (DTLS-SD= P) > makes more sense than changing two. (I suspect the BUNDLE formulation > more closely tracks consensus anyway). > > /a > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --94eb2c09336463b65605585b21ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, that seems like the logical extension of this. Note t= hat this is only in the edge case
where the offerer offers an ICE resta= rt, because if the offerer does not, we all agree that
you need t= o keep the existing fingerprint.

-Ekr

On = Mon, Sep 4, 2017 at 3:14 AM, Christer Holmberg <christer.holm= berg@ericsson.com> wrote:
<= div class=3D"HOEnZb">
Hi,

>>> In my opinion, things should behave as follows. The semantics = of the
>>>indicators are
>>> tls-id=C2=A0 =C2=A0 =C2=A0old ufrag=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 new ufrag
>>>
>>> ------=C2=A0 =C2=A0 =C2=A0-------------------------------= -------------------
>>>
>>> none=C2=A0 =C2=A0 =C2=A0 =C2=A0No change=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ICE restart, same DTLS
>>>
>>> old=C2=A0 =C2=A0 =C2=A0 =C2=A0 ICE restart=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ICE restart, same DTLS
>>>
>>> new=C2=A0 =C2=A0 =C2=A0 =C2=A0 Error=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ICE restart, ne= w DTLS
>>>
>>> However, in all cases but one, the answer MUST match the offer= . I.e.,
>>>the answer must
>>> do an ICE restart iff the offer had one and a new DTLS connect= ion iff
>>>the offer had one.
>>> However, if the answerer does not support tls-id, then it migh= t
>>>respond to a new tls-id
>>> with no tls-id, which means it does not intend to make a new D= TLS
>>>connection. The offerer
>>> can either accept that or tear everything down.
>>>
>>> I agree that the specs do not currently make this clear
>>

>> Because that=C2=B9s not how the procedures are currently written.<= br> >
> Again, JSEP and this document are in conflict, hence it's unclear.=
>

>> Now, based on your suggestion, if the offerer doesn=C2=B9t know wh= ether the
>>answerer supports tls-id, does that mean that the only way
>> for the offerer to ensure that the re-offer will trigger a new DTL= S
>>association is by modifying the fingerprint set in the offer?
>
> That's true in any case, because we have implementations which beh= ave
>that way and we can't change them.

On GitHub you also suggested
(https://github.com/cdh4u/draft-dtls-sdp/issue= s/37) that the answerer,
even if it supports tls-id, shall not be able to trigger a new DTLS
association (read: change the tls-id value). I assume that means the
answerer would not be able to change its fingerprint set either, or do
anything else that would trigger a new DTLS association?

Regards,

Christer













On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg
<christer.holmberg@eri= csson.com> wrote:

Hi,

>Yes. Indeed, that's the crux of the disagreement between JSEP and t= his
>document

So, just to clarify: in your opinion, if an endpoint receives an
offer/answer WITHOUT a tls-id, but with a NEW ufrag (read: ICE restart), the new urfag will NOT trigger a new
=C2=A0DTLS association. Right?

Regards,

Christer






On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg
<christer.holmberg@eri= csson.com> wrote:

Hi Ekr,

What if the remote peer does not support/include the tls-id attribute?

Regards,

Christer

From: mmusic [mailto:mmusic-boun= ces@ietf.org]
On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <bernard.ab= oba@gmail.com>
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts



On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <bernard.aboba@gmail.com>
wrote:

On Issue 1, Adam said:


"

1.
(Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart?<= br> The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which =C2=A0would commonly involve changing to a different physical device. While= it
would, in theory, be possible to transfer the TLS state associated with
the connection between devices, this is rather cumbersome (and, as far as I know, not generally supported by TLS
=C2=A0libraries). From that perspective, it is my opinion that the DTLS-SDP=
document is correct that an ICE restart necessitates a new DTLS
connection; and I conclude that JSEP needs to change.
"



[BA] Agree that for consistency, it is best for an ICE restart to
necessitate a new DTLS connection, since an ICE restart can result in
connection to a different device (and the need for a new DTLS connection).<= br>








I'm not persuaded by this: the primary reason for an ICE restart is not=
changing devices but rather trying to deal with topology changes and/or
connectivity check failures. If you actually *do* change devices, then
it's also quite probably
=C2=A0you will have a new certificate fingerprint, in which case you will g= et a
new DTLS connection in any case. In other words, tls-id should be used to say "I want a new DTLS connection in spite of the fingerprint being th= e
same" (what JSEP says), not "I want
=C2=A0to keep the DTLS connection even though I am doing an ICE restart&quo= t;



-Ekr





On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <adam@nostrum.com> wrote:



MMUSIC --
[I will be posting a separate message to RTCWEB directing interested
parties to discuss this issue on the MMUSIC mailing list]
During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some conflicts between the procedures in DTLS-SDP and JSEP were identified.
This note is an attempt to summarize them. I have also made an initial
proposal, for each conflict, regarding
=C2=A0which document needs to change, in and which way.
Issue 1 (quoting EKR), which raises a couple of additional sub-issues:

1. Assuming I understand this document correctly, it conflicts withthe
guidance in JSEP. Specifically, S 4 says:=C2=A0 =C2=A0 No default value is = defined
for the SDP 'tls-id' attribute.=C2=A0 =C2=A0Implementations that wi= sh to use the
attribute MUST explicitly=C2=A0 =C2=A0include it in SDP offers and answers.= =C2=A0 If an
offer or answer does not=C2=A0 =C2=A0contain a 'tls-id' attribute (= this could happen
if the offerer or=C2=A0 =C2=A0answerer represents an existing implementatio= n that
has not been=C2=A0 =C2=A0updated to support the 'tls-id' attribute)= , unless there is
another=C2=A0 =C2=A0mechanism to explicitly indicate that a new DTLS associ= ation is
to be=C2=A0 =C2=A0established, a modification of one or more of the followi= ng
characteristics MUST be treated as an indication that an endpoint=C2=A0 =C2= =A0wants
to establish a new DTLS association:=C2=A0 =C2=A0 o=C2=A0 DTLS setup role; = or=C2=A0 =C2=A0 o
fingerprint set; or=C2=A0 =C2=A0 o=C2=A0 local transport parameters; or=C2= =A0 =C2=A0 o=C2=A0 ICE ufrag
value This seems to say that if there is no tls-id attribute, then an ICE
restart(which necessitates a ufrag change) requires a DTLS rest= art. JSEP
isn'tincredibly clear on this point, but 5.7.3 seems to say that
tls-idneed not be present:=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 tls-id value, = which MUST be set
according to=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-mm= usic-dtls-sdp], Section 5.=C2=A0 If this is a
re-offer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the tls-id value is different= from that presently in
use,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the DTLS connection is not being cont= inued and the remote
=C2=A0 =C2=A0 description MUST be part of an ICE restart, together with new=
ufrag and password values.=C2=A0 If this is an answer, the tls-id
value, if present, MUST be the same as in the offer. I believe that the
first sentence is in error, as we clearlycan't have JSEP impleme= ntations
requiring that tls-id be present.=C2=A0 =C2=A0 ...=C2=A0 = =C2=A0 =C2=A0 o=C2=A0 If the remote DTLS
fingerprint has been changed or the tls-id has=C2=A0 =C2=A0 =C2=A0 changed,= tear down the
DTLS connection.=C2=A0 This includes the case=C2=A0 =C2=A0 =C2=A0 when the = PeerConnection
state is "have-remote-pranswer".=C2=A0 If a=C2=A0 =C2=A0 =C2=A0 D= TLS connection needs to be
torn down but the answer does not=C2=A0 =C2=A0 =C2=A0 indicate an ICE resta= rt or, in the
case of "have-remote-pranswer",=C2=A0 =C2=A0 =C2=A0 new ICE crede= ntials, an error MUST be
generated.=C2=A0 If an ICE=C2=A0 =C2=A0 =C2=A0 restart is performed without= a change in tls-id
or fingerprint,=C2=A0 =C2=A0 =C2=A0 then the same DTLS connection is contin= ued over the
new ICE=C2=A0 =C2=A0 =C2=A0 channel.=C2=A0 =C2=A0 =C2=A0 I think the best i= nterpretation of this is that
if tls-id is not present(and hence unchanged) then ICE restart does = not
cause DTLS restart.This is also my memory of the consensus in RTCWEB. In any case, thesetwo documents clearly must match.


My observations/recommendations:

1. (Issue 1a) EKR is correct that the first sentence of the bullet from
JSEP needs to be removed so as to enable interoperation wi= th non-JSEP
implementations.
2. (Issue 1b) Additionally the final sentence of that bullet ("= If this is
an answer, the tls-id value, if present, MUST be the same = as in the
offer") conflicts with the definition of tls-id ("the offerer and= answerer
=C2=A0generate their own local 'tls-id' attribute values, and the c= ombination
of both values identify the DTLS association"). In this case, the DTLS= -SDP
document would appear to be correct (the fact that the two parties choose different IDs is integral to the mechanism's
=C2=A0design), so JSEP needs to change.
3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to=
restart? The primary rationale outl= ined in RFC5245 for restarting ICE is
changing the destination (IP address or port) of an ongoing media stream -- which would commonly
=C2=A0involve changing to a different physical device. While it would, in theory, be possible to transfer the TLS state associated with the
connection between devices, this is rather cumbersome (and, as far as I
know, not generally supported by TLS libraries). From
=C2=A0that perspective, it is my opinion that the DTLS-SDP document is corr= ect
that an ICE restart necessitates a new DTLS connection; and I conclude
that JSEP needs to change.


Issue 2 (quoting EKR):

2. S 4 says:=C2=A0 =C2=A0 The mux category [I-D.ietf-mmusic-sdp-mux-at= tributes] for
the 'tls-=C2=A0 =C2=A0id' attribute is 'IDENTICAL', which m= eans that the attribute
value=C2=A0 =C2=A0must be identical across all media descriptions being mul= tiplexed
=C2=A0[I-D.ietf-mmusic-sdp-bundle-negotiation]. This is not actually w= hat JSEP
requires:=C2=A0 =C2=A0 different categories.=C2=A0 To avoid unnecessary dup= lication when
=C2=A0bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m=3D sections, repeating the guidance from
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1.=C2=A0 This incl= udes I
suspect this is old text.


(Issue 2) JSEP is aligned with
draft-ietf-mmusic-sdp-bundle-negotiation-38, while DTLS-SDP does not. = This
is a largely aesthetic decision (although the JSEP/BUNDLE approach does
save a tiny handful of bytes), but I think changing one document (DTLS-SDP)=
=C2=A0makes more sense than changing two. (I suspect the BUNDLE formulation=
more closely tracks consensus anyway).

/a




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





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

































--94eb2c09336463b65605585b21ec-- From nobody Mon Sep 4 07:37:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156241321AF for ; Mon, 4 Sep 2017 07:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1p6-yTY92gML for ; Mon, 4 Sep 2017 07:37:25 -0700 (PDT) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id DFEE11321A6 for ; Mon, 4 Sep 2017 07:37:23 -0700 (PDT) X-AuditID: 12074414-0d3ff70000006ddf-ae-59ad65228983 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id CF.53.28127.2256DA95; Mon, 4 Sep 2017 10:37:22 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v84EbKRd009801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 4 Sep 2017 10:37:22 -0400 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Mon, 4 Sep 2017 10:37:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqKuUujbSoKPdymLq8scsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmLBhNmPBevaKk8e4Gxi/sXYxcnJICJhILN1ykLGLkYtDSGAH k8SlQ7tYIZxvTBJn1ixk6mLk4BAWMJQ4cYYFpEFEQFhixtu/bBA181klPj4/yQySYBPQkphz 6D9YEa+AvcSrj0/B4iwCKhIv1q0Cs0UF0iT+7T7LCFEjKHFy5hOwek4BG4kFnyeyg9jMAmYS 8zY/ZIawxSVuPZnPBGHLSzRvnc08gZF/FpL2WUhaZiFpmYWkZQEjyypGucSc0lzd3MTMnOLU ZN3i5MS8vNQiXQu93MwSvdSU0k2MkKAU2cF45KTcIUYBDkYlHt6I0LWRQqyJZcWVuYcYJTmY lER5j4YAhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwPksEyvGmJFZWpRblw6SkOViUxHm/LVb3 ExJITyxJzU5NLUgtgsnKcHAoSfD+TgZqFCxKTU+tSMvMKUFIM3FwggznARquD1LDW1yQmFuc mQ6RP8VozNH0YcsXJo5fM7d+YRJiycvPS5US5+UCKRUAKc0ozYObBkssrxjFgZ4T5n0AUsUD TEpw814BrWICWlX1cg3IqpJEhJRUA2Om0MdJOxS0G2/e23K2e/3v9/x5Yh1nW079kzaoOO7w N3baxIkWTUvnzSlgYNCxlM5InXRis8+flsLqY0snHLFl5A2ykre4eUNilnhd6cljPrNm2/pm bLZ4svyBo2yhuoZsxYEwPiuNtkcK0Z4ZbCLsmScONyfmZRdw6z6TXJVgYpoYWnH/qhJLcUai oRZzUXEiABNi3CQHAwAA Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:37:27 -0000 On 9/4/17 6:14 AM, Christer Holmberg wrote: >>> Now, based on your suggestion, if the offerer doesn¹t know whether the >>> answerer supports tls-id, does that mean that the only way >>> for the offerer to ensure that the re-offer will trigger a new DTLS >>> association is by modifying the fingerprint set in the offer? >> >> That's true in any case, because we have implementations which behave >> that way and we can't change them. > > On GitHub you also suggested > (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer, > even if it supports tls-id, shall not be able to trigger a new DTLS > association (read: change the tls-id value). I assume that means the > answerer would not be able to change its fingerprint set either, or do > anything else that would trigger a new DTLS association? Why would you want to *prevent* the answerer from triggering a new DTLS association??? Thanks, Paul From nobody Mon Sep 4 07:41:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC001321A6 for ; Mon, 4 Sep 2017 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgPPrM8Rr359 for ; Mon, 4 Sep 2017 07:41:42 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668661321AF for ; Mon, 4 Sep 2017 07:41:42 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w204so2825200ywg.3 for ; Mon, 04 Sep 2017 07:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vrV5iWF2upYv6oBdQAEoKTNYlsYnw5PwVjq8cmwtYGA=; b=0U/D8iGq1Hgdwok+J241uLGJM9s5i/lZSfA4LwSRkD3By+MRQBxzVeRzm/bJiuAOLn 9imjWtW6MCktwe6WdMud1LKJAgDTPFZqRoVTKTPE9A5GYBgQqzTkHoI9F6H7/Z7Go0s7 XUpA10tXK0uv1+fWrmjMCSLOmGjkjBRBAlb3RFMDDTBCm/ZdQxfH2TKnjetufDDbh0if OCNBJh9Mo39ot89x8F75yEikGiafq+TEduJ7yDXdEyq4J+nmKpUgYudMe4SyX+tsjrSm NwmVXO1edAf16qzDcxjR7dGUAdwKjfNMtlj8Ra0bcThQRNSFMHmwkUpDX8SYe2dvpi0p 6/Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vrV5iWF2upYv6oBdQAEoKTNYlsYnw5PwVjq8cmwtYGA=; b=J5ZE8GbJYLGTyyUXz+3485vEkn1NUdtGwVBMXJvaDPlU6RSGvz420c73S3EDicYOOw IBCWeU5VwHSS/op+EGI5wh/UttJZEcKYQmWGlV5QUd04t3yq+wL/P/GBrjAErQiwQp51 bZ9/7w4F8vAjK2be7lr6dA5tLHvFYXB2lYJEnDlFFEZMvb6WlU3nRlXAfVNkl9C14R7C jv5jpD3mcpn3CCQa5vJfUUQZk9wSNMqPYHXgMAKA7vxaWIisIWbelerRj9d5mPhWi9TU qEqA46EwS3CvKssxhb7RP0RFP0GTmAAzMsUb2x6y3KEJBg3fzJwuaqO9cF8WNM8/nDHs SPiQ== X-Gm-Message-State: AHPjjUggXr5z8wdlRfospSMQm+EASr2XtUj2/gKpIoeRApasJpKBstkg bAH+zMFBY/VV+nVdxxZoz9KCwF0VJlzlxU0= X-Google-Smtp-Source: ADKCNb4ZClLxYUn7cBw7IHVj+cLO4JfoVzOtfpc4nfPUQ8lfPY7NoGkaWh7qvo9vJrFNI31mlvYQkGBescnUG+rqhCU= X-Received: by 10.37.105.196 with SMTP id e187mr702038ybc.256.1504536101576; Mon, 04 Sep 2017 07:41:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Mon, 4 Sep 2017 07:41:00 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Mon, 4 Sep 2017 07:41:00 -0700 Message-ID: To: Paul Kyzivat Cc: mmusic WG Content-Type: multipart/alternative; boundary="001a114d841ce2f82905585e1b88" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:41:44 -0000 --001a114d841ce2f82905585e1b88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat wrote: > On 9/4/17 6:14 AM, Christer Holmberg wrote: > > Now, based on your suggestion, if the offerer doesn=C2=B9t know whether t= he >>>> answerer supports tls-id, does that mean that the only way >>>> for the offerer to ensure that the re-offer will trigger a new DTLS >>>> association is by modifying the fingerprint set in the offer? >>>> >>> >>> That's true in any case, because we have implementations which behave >>> that way and we can't change them. >>> >> >> On GitHub you also suggested >> (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer, >> even if it supports tls-id, shall not be able to trigger a new DTLS >> association (read: change the tls-id value). I assume that means the >> answerer would not be able to change its fingerprint set either, or do >> anything else that would trigger a new DTLS association? >> > > Why would you want to *prevent* the answerer from triggering a new DTLS > association??? > As noted previously, it's confusing and it's only possible at all in the edge case where the offerer offers an ICE restart but not a new DTLS association. -Ekr Thanks, > Paul > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114d841ce2f82905585e1b88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat <pkyzivat@alum.mit.ed= u> wrote:
= On 9/4/17 6:14 AM, Christer Holmberg wrote:

Now, based on your suggestion, if the offerer doesn=C2=B9t know whether the=
answerer supports tls-id, does that mean that the only way
for the offerer to ensure that the re-offer will trigger a new DTLS
association is by modifying the fingerprint set in the offer?

That's true in any case, because we have implementations which behave that way and we can't change them.

On GitHub you also suggested
(https://github.com/cdh4u/draft-dtls-sdp/issue= s/37) that the answerer,
even if it supports tls-id, shall not be able to trigger a new DTLS
association (read: change the tls-id value). I assume that means the
answerer would not be able to change its fingerprint set either, or do
anything else that would trigger a new DTLS association?

 Why would you want to *prevent* the answerer from triggering a new DTLS ass= ociation???

As noted previously, it'= ;s confusing and it's only possible at all in the edge case where the o= fferer offers an ICE restart but not a new DTLS association.

=
-Ekr

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

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

--001a114d841ce2f82905585e1b88-- From nobody Mon Sep 4 20:49:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4001321EB for ; Mon, 4 Sep 2017 20:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA_Uc3wIxDKG for ; Mon, 4 Sep 2017 20:48:58 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8781321D5 for ; Mon, 4 Sep 2017 20:48:57 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id v66so6010446pgb.5 for ; Mon, 04 Sep 2017 20:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nXc6N0EUPZS4swtB8eDTHo6qBocDsXHOaQeG6QOZpU8=; b=sCecWyx6uSQntu5tZ/8lquCn5qTkYSFEudjkD5OA2NpQOkQgT3twyXe96xThSesqpI X/cnHOqc5sPh+09Ma/oXrC+oMqYRpyWZsJrg4E73TzqBCCFjBfzmQZyopUbTEcUmErqQ 8IGkD81i4fCGs8olup5Y+kVP5dI1FKVd/YaJzKbADmkzTjcAPypZKUW2iqWfBzBR5MLY lFWGUykCNSeiz0DKbNSygqT5vvp7jNhgMndxtvY93lO9QaYQ/zjm8ToRKiQMAe5zSEGm j6m/2lujamqWhWRLnTxS+cg7K6DLOXr8256vnWjFB50pWA7vS9Rdw+6euEUOH79bdVAt sKgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nXc6N0EUPZS4swtB8eDTHo6qBocDsXHOaQeG6QOZpU8=; b=pnWegNzrEpPLjkgeSXH3olgFTMNwMgRT9OTw5wz8gUL8eMl7tbE3rzhCIRRnHzWpF7 GhPo0HOne3eMjYreq9WlfPa3I4kmtENP45pc0QZchIudqESyQOkoAj6dfIhC7jpgmp8E KY7F2hdc6/v9SIpqR2CeMoB37cvPAJKNedDcO33+tdR/ul0kL5+9D4Tr1eIqXrFnL2bi ftYniJXg8qaQGcixdffyCBO3ezccacZCWokpQppH6ENBkX4n02v/zjXo0vBVgY3pnS+l 7s1TPpz0ZYEOXkSjwUMKg/IEUJqUeMbP0oPq32KRvwl/qycv+dA6ZkfD4PazJvS+YdgI Y/xA== X-Gm-Message-State: AHPjjUjoBM1ZukO6lWQctL/WvMpHPgVFHf1kvi/MTXBtx9T8SPzwT7/s NSSe1R7lTO7JMY8BZdk= X-Received: by 10.98.1.69 with SMTP id 66mr2378889pfb.177.1504583337246; Mon, 04 Sep 2017 20:48:57 -0700 (PDT) Received: from mail-pg0-f53.google.com (mail-pg0-f53.google.com. [74.125.83.53]) by smtp.gmail.com with ESMTPSA id p1sm11653337pfe.129.2017.09.04.20.48.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 20:48:56 -0700 (PDT) Received: by mail-pg0-f53.google.com with SMTP id t3so6161237pgt.0 for ; Mon, 04 Sep 2017 20:48:55 -0700 (PDT) X-Google-Smtp-Source: ADKCNb4j/HlemXTt4O3cQxNm0e1C/OPxizgDtPnbbRetLufhwdrZ4VrK18gaV64htIpaYDbtnUlc1ut5K8kJFE2L0jY= X-Received: by 10.99.97.148 with SMTP id v142mr2630787pgb.413.1504583335387; Mon, 04 Sep 2017 20:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Mon, 4 Sep 2017 20:48:54 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 4 Sep 2017 23:48:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Paul Kyzivat , mmusic WG Content-Type: multipart/alternative; boundary="94eb2c0cc4843daa9f0558691b55" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 03:49:00 -0000 --94eb2c0cc4843daa9f0558691b55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla wrote: > > > On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat > wrote: > >> On 9/4/17 6:14 AM, Christer Holmberg wrote: >> >> Now, based on your suggestion, if the offerer doesn=C2=B9t know whether = the >>>>> answerer supports tls-id, does that mean that the only way >>>>> for the offerer to ensure that the re-offer will trigger a new DTLS >>>>> association is by modifying the fingerprint set in the offer? >>>>> >>>> >>>> That's true in any case, because we have implementations which behave >>>> that way and we can't change them. >>>> >>> >>> On GitHub you also suggested >>> (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer, >>> even if it supports tls-id, shall not be able to trigger a new DTLS >>> association (read: change the tls-id value). I assume that means the >>> answerer would not be able to change its fingerprint set either, or do >>> anything else that would trigger a new DTLS association? >>> >> >> Why would you want to *prevent* the answerer from triggering a new DTLS >> association??? >> > > As noted previously, it's confusing and it's only possible at all in the > edge case where the offerer offers an ICE restart but not a new DTLS > association. > > The main reason new DTLS association can started by the answering party is third party call control. The new DTLS association will be required if as a result of the offer/answer exchange two new end points ends up being connected with each other by a third party call control agent. This is a fairly common scenario. If it is not supported interoperability with existing implementations will be seriously affected. Please note that in existing specification new DTLS association can already be started by the answerer changing fingerprints, transport parameters, or setup role. As far as possible implementation options are concerned there are two possible solutions: a. Always require a new DTLS association whenever an offer is generated in the response to a request for a new offer (INVITE with no SDP in case of SIP). This will match ICE behavior where new ICE restart is required in such case. This is workable, but is excessive and will generate new DTLS association establishment when it is not required. This is why we preferred the currently described solution. b. Allow answering party to force a new DTLS association by changing dtls-id. This is something that will address third party call control case, since new end point will generate a new tls-id. This also removes unneeded DTLS associations if third party call control ends up connecting to the same end point (which happens more often then expected due to 3pcc agents doing connectivity checks). This is why I would strongly prefer to leave current specification as it is= . Regards, _____________ Roman Shpount --94eb2c0cc4843daa9f0558691b55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:

<= br>
On Mon, Sep 4, 2017 at= 7:37 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 9/4/17 6:14 AM,= Christer Holmberg wrote:

Now, based on your suggestion, if the offerer doesn=C2=B9t know whether the=
answerer supports tls-id, does that mean that the only way
for the offerer to ensure that the re-offer will trigger a new DTLS
association is by modifying the fingerprint set in the offer?

That's true in any case, because we have implementations which behave that way and we can't change them.

On GitHub you also suggested
(https://github.com/cdh4u/draft-dtls-sdp/issue= s/37) that the answerer,
even if it supports tls-id, shall not be able to trigger a new DTLS
association (read: change the tls-id value). I assume that means the
answerer would not be able to change its fingerprint set either, or do
anything else that would trigger a new DTLS association?

 Why would you want to *prevent* the answerer from triggering a new DTLS ass= ociation???

As noted previously,= it's confusing and it's only possible at all in the edge case wher= e the offerer offers an ICE restart but not a new DTLS association.


The main re= ason new DTLS association can started by the answering party is third party= call control. The new DTLS association will be required if as a result of = the offer/answer exchange two new end points ends up being connected with e= ach other by a third party call control agent. This is a fairly common scen= ario. If it is not supported interoperability with existing implementations= will be seriously affected. Please note that in existing specification new= DTLS association can already be started by the answerer changing fingerpri= nts, transport parameters, or setup role.

As far a= s possible implementation options are concerned there are two possible solu= tions:

a. Always require a new DTLS association wh= enever an offer is generated in the response to a request for a new offer (= INVITE with no SDP in case of SIP). This will match ICE behavior where new = ICE restart is required in such case. This is workable, but is excessive an= d will generate new DTLS association establishment when it is not required.= This is why we preferred the currently described solution.

<= /div>
b. Allow answering party to force a new DTLS association by chang= ing dtls-id. This is something that will address third party call control c= ase, since new end point will generate a new tls-id. This also removes unne= eded DTLS associations if third party call control ends up connecting to th= e same end point (which happens more often then expected due to 3pcc agents= doing connectivity checks).

This is why I would s= trongly prefer to leave current specification as it is.

Regards,
_____________
Ro= man Shpount
=C2=A0
--94eb2c0cc4843daa9f0558691b55-- From nobody Mon Sep 4 21:03:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42932132256 for ; Mon, 4 Sep 2017 21:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRj97eSQHinb for ; Mon, 4 Sep 2017 21:03:55 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5901321F5 for ; Mon, 4 Sep 2017 21:03:55 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id x144so8411934ywg.2 for ; Mon, 04 Sep 2017 21:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=igBs3Da58hYJ25EEDBURnc2tWOSzmTYh1nf5P3fpyL0=; b=edLqTynWyfRgkfayObJA0s1zBxFPsOduTcUQabX9kB061uGuuFdwJtHXnkm6BNII9D DNeZ5eCWkz5GEQf26BjPJ0Ww4R4Pm3YZ+nA7aE25o3eTpmY31MiiirHd5/U0JBqeaGK/ b8p5lA7KUCOOKmvpLY8wAyBXVf6xrPNj1fcOvpPISYZ88FX/DkOwEdEYqyOCKQOzaEFI ise7DjGftMwQz0hJ+qGC/gn/eTZcNaHnzQ+8shXZ3G8jDPkEZCMgz2Ofie6i/mZMHA36 UXJOUx5l+82J0DmJ6BWKnqlKAlbAmaz2RuAGGRnE071UwEc6gkjRvyNzhhtanDkALGaH csSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=igBs3Da58hYJ25EEDBURnc2tWOSzmTYh1nf5P3fpyL0=; b=jzTqLHb+HmmMsA6FNBv/gAlzxuQijWNUmWI4ngtvkSaM3C3ON0+9sElTocmQ+95O9E QIcNm7BbDg+P/MMBzmydR3fgSbqSPXmXORg/LDIfamWYK5JjMvZJsmAfccIA6F7Oom53 8EhE0uFcxDU6PkQZHQJu/1I0ZFfJroWETwiCrz6I+lmukeispE0bfFUTcETD1ibnjsea RG60t6vi7x6Fg2PcOBjzRWrEEtnSHndWEkUxVRKC2BTLzp9rrf9nb8X3Ai1h/WrGkOEH ao2J5vWNGEbf4LEmXCCYOuIseE9OuFHT6w85Hf5ptxz44Wwp33rKjwNyhgxG2CC69aV4 m9VA== X-Gm-Message-State: AHPjjUgD09+JeL0SiX/6UQY15426foTg33LuRNnjGErdtOmpBGbu1Cvg kSlhHfImw8ubfgv9Msw4zjrg0YRqCTrl X-Google-Smtp-Source: ADKCNb4m5wDSMof4lIIGrqgvicjYVVhvLCowZevpu3F+NpQKdk37K9RuIlLnYcXanBQr+B6GdOZ/dOFSb8lBT0r4dvs= X-Received: by 10.129.121.4 with SMTP id u4mr2140835ywc.71.1504584234321; Mon, 04 Sep 2017 21:03:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Mon, 4 Sep 2017 21:03:13 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Mon, 4 Sep 2017 21:03:13 -0700 Message-ID: To: Roman Shpount Cc: Paul Kyzivat , mmusic WG Content-Type: multipart/alternative; boundary="94eb2c0a8af4d261850558695044" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 04:03:57 -0000 --94eb2c0a8af4d261850558695044 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 4, 2017 at 8:48 PM, Roman Shpount wrote: > On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla wrote: > >> >> >> On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat >> wrote: >> >>> On 9/4/17 6:14 AM, Christer Holmberg wrote: >>> >>> Now, based on your suggestion, if the offerer doesn=C2=B9t know whether= the >>>>>> answerer supports tls-id, does that mean that the only way >>>>>> for the offerer to ensure that the re-offer will trigger a new DTLS >>>>>> association is by modifying the fingerprint set in the offer? >>>>>> >>>>> >>>>> That's true in any case, because we have implementations which behave >>>>> that way and we can't change them. >>>>> >>>> >>>> On GitHub you also suggested >>>> (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer, >>>> even if it supports tls-id, shall not be able to trigger a new DTLS >>>> association (read: change the tls-id value). I assume that means the >>>> answerer would not be able to change its fingerprint set either, or do >>>> anything else that would trigger a new DTLS association? >>>> >>> >>> Why would you want to *prevent* the answerer from triggering a new DTLS >>> association??? >>> >> >> As noted previously, it's confusing and it's only possible at all in the >> edge case where the offerer offers an ICE restart but not a new DTLS >> association. >> >> > The main reason new DTLS association can started by the answering party i= s > third party call control. The new DTLS association will be required if as= a > result of the offer/answer exchange two new end points ends up being > connected with each other by a third party call control agent. This is a > fairly common scenario. If it is not supported interoperability with > existing implementations will be seriously affected. Please note that in > existing specification new DTLS association can already be started by the > answerer changing fingerprints, transport parameters, or setup role. > Well, as has been noted, the current specification is fairly unclear (I feel comfortable saying that as one of the authors), but as a practical matter, this only works if you already are doing an ICE restart. Is that what is happening in this instance? -Ekr > As far as possible implementation options are concerned there are two > possible solutions: > > a. Always require a new DTLS association whenever an offer is generated i= n > the response to a request for a new offer (INVITE with no SDP in case of > SIP). This will match ICE behavior where new ICE restart is required in > such case. This is workable, but is excessive and will generate new DTLS > association establishment when it is not required. This is why we preferr= ed > the currently described solution. > > b. Allow answering party to force a new DTLS association by changing > dtls-id. This is something that will address third party call control cas= e, > since new end point will generate a new tls-id. This also removes unneede= d > DTLS associations if third party call control ends up connecting to the > same end point (which happens more often then expected due to 3pcc agents > doing connectivity checks). > > This is why I would strongly prefer to leave current specification as it > is. > > Regards, > _____________ > Roman Shpount > > --94eb2c0a8af4d261850558695044 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 8:48 PM, Roman Shpount <roman@telurix.com&g= t; wrote:
On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla <ekr@rtfm.com= > wrote:


On Mon, Sep 4, 2017 at 7:37 AM, Paul K= yzivat <pkyzivat@alum.mit.edu> wrote:
On 9/4/17 6:14 AM, Christer Holmbe= rg wrote:

Now, based on your suggestion, if the offerer doesn=C2=B9t know whether the=
answerer supports tls-id, does that mean that the only way
for the offerer to ensure that the re-offer will trigger a new DTLS
association is by modifying the fingerprint set in the offer?

That's true in any case, because we have implementations which behave that way and we can't change them.

On GitHub you also suggested
(https://github.com/cdh4u/draft-dtls-sdp/issue= s/37) that the answerer,
even if it supports tls-id, shall not be able to trigger a new DTLS
association (read: change the tls-id value). I assume that means the
answerer would not be able to change its fingerprint set either, or do
anything else that would trigger a new DTLS association?

 Why would you want to *prevent* the answerer from triggering a new DTLS ass= ociation???

As noted previously,= it's confusing and it's only possible at all in the edge case wher= e the offerer offers an ICE restart but not a new DTLS association.


The = main reason new DTLS association can started by the answering party is thir= d party call control. The new DTLS association will be required if as a res= ult of the offer/answer exchange two new end points ends up being connected= with each other by a third party call control agent. This is a fairly comm= on scenario. If it is not supported interoperability with existing implemen= tations will be seriously affected. Please note that in existing specificat= ion new DTLS association can already be started by the answerer changing fi= ngerprints, transport parameters, or setup role.

Well, as has been noted, the current specific= ation is fairly unclear (I feel comfortable saying that as one of the autho= rs), but as a practical matter, this only works if you already are doing an= ICE restart. Is that what is happening in this instance?

-Ekr

=C2=A0
As far as possible implementation options are concerned there are tw= o possible solutions:

a. Always require a new DTLS= association whenever an offer is generated in the response to a request fo= r a new offer (INVITE with no SDP in case of SIP). This will match ICE beha= vior where new ICE restart is required in such case. This is workable, but = is excessive and will generate new DTLS association establishment when it i= s not required. This is why we preferred the currently described solution.<= /div>

b. Allow answering party to force a new DTLS assoc= iation by changing dtls-id. This is something that will address third party= call control case, since new end point will generate a new tls-id. This al= so removes unneeded DTLS associations if third party call control ends up c= onnecting to the same end point (which happens more often then expected due= to 3pcc agents doing connectivity checks).

This i= s why I would strongly prefer to leave current specification as it is.

Regards,
_____________
Roman Shpount
=C2=A0
<= /div>

--94eb2c0a8af4d261850558695044-- From nobody Mon Sep 4 21:16:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970AE1321D5 for ; Mon, 4 Sep 2017 21:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnwptMA3TFAQ for ; Mon, 4 Sep 2017 21:16:17 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CE21241F3 for ; Mon, 4 Sep 2017 21:16:16 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id e199so5059090pfh.3 for ; Mon, 04 Sep 2017 21:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BEUDD2aPFMOMbBjbgZHmpm5n3BDZUDMt88jr/QBWF44=; b=k3g6pGaan9Nn9uzGxuJA8Ee3S5vS0etPiQAJsHKCPTjQ2clzKJqLnqCG6/J/57i6iu vYOogdVtJj4s8rGm8X5ymCpgykTMahWxIjq4G6NVYg33m9ZQvSPA+/RmdsicPIVjfGHx D5KqZTjLE36L+MS++0kYJis+bEWwwIMgdhpvYcql+qTyzHSdecRlT/718SgcPz2rIRRn tTysMrjFi7gIPv8miUqFyIqIXXziqW9er2WIf4lTlxQmu4oPUZd2UBgZyQIN7O6cfZUA gc3Yn+xooS+n93OQiPtkzSvSBlyuJvLjlzx2vLugwxiOO5wySuNVMX07w3hVf3NrpyzE Aeiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BEUDD2aPFMOMbBjbgZHmpm5n3BDZUDMt88jr/QBWF44=; b=jPbxofaEOb4x39tPei6LrMebnQyTmxYRwtw7CtJvPXwD52XZPdhRRD4RmsT2r2l8DY evZu1nkovyJYQuc8hadEgFlWRNuVW+s5VpYFeJC/o3e4KyhEV6p2cCVzBqLbjBU/ptOA cP8Nq/MSlFoCEfn78+SVJ/HQw7yOaFE3YvkoyA/EFGo/PpOYUl08LTzvKfMNHllpn4WJ HvvSF7GYW2j3wpAETg2AhyxTVm11HEXeJkewUsgNkBvyUx/kWB0vI9eqecY3BMnWyQc2 PsGhZ7ZRSPY7FspjdsOIUM7yhmPsYyaqOlw6bCfR7/THCrKh3FggYAPd8t939WJ+eJEv dsYA== X-Gm-Message-State: AHPjjUgDD+bMF8Bba14KVGh4I36eWPBxero7IC8s3LQK2b2lVZFLpEJ3 /0iTxGAZmadfJQtMVTc= X-Received: by 10.84.211.35 with SMTP id b32mr2839859pli.256.1504584976258; Mon, 04 Sep 2017 21:16:16 -0700 (PDT) Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com. [209.85.192.171]) by smtp.gmail.com with ESMTPSA id w15sm14981186pgo.63.2017.09.04.21.16.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 21:16:15 -0700 (PDT) Received: by mail-pf0-f171.google.com with SMTP id m1so5088366pfk.1 for ; Mon, 04 Sep 2017 21:16:15 -0700 (PDT) X-Google-Smtp-Source: ADKCNb52pgXS+4rpkhlB7GFoZzRnsyQpZmJrDLvnCD7XYxG1HxaXL5u4CWyRibXprcv8uQvH5+xC/80WjYeuHgvfbaM= X-Received: by 10.99.185.93 with SMTP id v29mr2780997pgo.32.1504584975188; Mon, 04 Sep 2017 21:16:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Mon, 4 Sep 2017 21:16:14 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 5 Sep 2017 00:16:14 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Paul Kyzivat , mmusic WG Content-Type: multipart/alternative; boundary="94eb2c1bac82fb09710558697cad" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 04:16:18 -0000 --94eb2c1bac82fb09710558697cad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 5, 2017 at 12:03 AM, Eric Rescorla wrote: > > > On Mon, Sep 4, 2017 at 8:48 PM, Roman Shpount wrote: > >> On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla wrote: >> >>> >>> >>> On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat >>> wrote: >>> >>>> On 9/4/17 6:14 AM, Christer Holmberg wrote: >>>> >>>> Now, based on your suggestion, if the offerer doesn=C2=B9t know whethe= r the >>>>>>> answerer supports tls-id, does that mean that the only way >>>>>>> for the offerer to ensure that the re-offer will trigger a new DTLS >>>>>>> association is by modifying the fingerprint set in the offer? >>>>>>> >>>>>> >>>>>> That's true in any case, because we have implementations which behav= e >>>>>> that way and we can't change them. >>>>>> >>>>> >>>>> On GitHub you also suggested >>>>> (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer= , >>>>> even if it supports tls-id, shall not be able to trigger a new DTLS >>>>> association (read: change the tls-id value). I assume that means the >>>>> answerer would not be able to change its fingerprint set either, or d= o >>>>> anything else that would trigger a new DTLS association? >>>>> >>>> >>>> Why would you want to *prevent* the answerer from triggering a new DTL= S >>>> association??? >>>> >>> >>> As noted previously, it's confusing and it's only possible at all in th= e >>> edge case where the offerer offers an ICE restart but not a new DTLS >>> association. >>> >>> >> The main reason new DTLS association can started by the answering party >> is third party call control. The new DTLS association will be required i= f >> as a result of the offer/answer exchange two new end points ends up bein= g >> connected with each other by a third party call control agent. This is a >> fairly common scenario. If it is not supported interoperability with >> existing implementations will be seriously affected. Please note that in >> existing specification new DTLS association can already be started by th= e >> answerer changing fingerprints, transport parameters, or setup role. >> > > Well, as has been noted, the current specification is fairly unclear (I > feel comfortable saying that as one of the authors), but as a practical > matter, this only works if you already are doing an ICE restart. Is that > what is happening in this instance? > > Current specification is not very specific about ICE. It does allow answerer to start a new DTLS association even if ICE restart is not initiated. I am not sure how this will work in all the cases, but it definitely works for third party call control, which, as far as I am concerned, is the only useful use case of answerer triggering a new DTLS association. ICE restart is required in case of the new offer generated in response to INVITE with no SDP. Because of this, answerer can successfullu establish a new DTLS association by changing fingerprints. And, since answerer is a new end point, ICE candidate pair nominated for transport will end up to be a new distinct 5-tuple so new and old DTLS associations can be easily demuxed. So, in some sense, current specification works almost by accident. I would really like for this to continue to work since this is being used. Regards, _____________ Roman Shpount --94eb2c1bac82fb09710558697cad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 5, 2017 at 12:03 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:

<= br>
On Mon, Sep 4, 2017 at= 8:48 PM, Roman Shpount <roman@telurix.com> wrote:
On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla= <ek= r@rtfm.com> wrote:


On Mon, Sep= 4, 2017 at 7:37 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 9/4/= 17 6:14 AM, Christer Holmberg wrote:

Now, based on your suggestion, if the offerer doesn=C2=B9t know whether the=
answerer supports tls-id, does that mean that the only way
for the offerer to ensure that the re-offer will trigger a new DTLS
association is by modifying the fingerprint set in the offer?

That's true in any case, because we have implementations which behave that way and we can't change them.

On GitHub you also suggested
(https://github.com/cdh4u/draft-dtls-sdp/issue= s/37) that the answerer,
even if it supports tls-id, shall not be able to trigger a new DTLS
association (read: change the tls-id value). I assume that means the
answerer would not be able to change its fingerprint set either, or do
anything else that would trigger a new DTLS association?

 Why would you want to *prevent* the answerer from triggering a new DTLS ass= ociation???

As noted previously,= it's confusing and it's only possible at all in the edge case wher= e the offerer offers an ICE restart but not a new DTLS association.


The = main reason new DTLS association can started by the answering party is thir= d party call control. The new DTLS association will be required if as a res= ult of the offer/answer exchange two new end points ends up being connected= with each other by a third party call control agent. This is a fairly comm= on scenario. If it is not supported interoperability with existing implemen= tations will be seriously affected. Please note that in existing specificat= ion new DTLS association can already be started by the answerer changing fi= ngerprints, transport parameters, or setup role.

Well, as has been noted, the current s= pecification is fairly unclear (I feel comfortable saying that as one of th= e authors), but as a practical matter, this only works if you already are d= oing an ICE restart. Is that what is happening in this instance?
=

Current specif= ication is not very specific about ICE. It does allow answerer to start a n= ew DTLS association even if ICE restart is not initiated. I am not sure how= this will work in all the cases, but it definitely works for third party c= all control, which, as far as I am concerned, is the only useful use case o= f answerer triggering a new DTLS association. ICE restart is required in ca= se of the new offer generated in response to INVITE with no SDP. Because of= this, answerer can successfullu establish a new DTLS association by changi= ng fingerprints. And, since answerer is a new end point, ICE candidate pair= nominated for transport will end up to be a new distinct 5-tuple so new an= d old DTLS associations can be easily demuxed. So, in some sense, current s= pecification works almost by accident.

I would rea= lly like for this to continue to work since this is being used.
<= br>
Regards,
___________= __
Roman Shpount
=C2=A0
--94eb2c1bac82fb09710558697cad-- From nobody Tue Sep 5 01:22:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38D6132715; Tue, 5 Sep 2017 01:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 q4JfyAF411eV; Tue, 5 Sep 2017 01:22:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 0C0061323B4; Tue, 5 Sep 2017 01:22:07 -0700 (PDT) X-AuditID: c1b4fb30-57fff70000005897-31-59ae5eae5516 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E2.99.22679.EAE5EA95; Tue, 5 Sep 2017 10:22:06 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Tue, 5 Sep 2017 10:22:05 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach , Ben Campbell , Eric Rescorla , Alexey Melnikov , =?Windows-1252?Q?Mirja_K=FChlewind?= , Roman Shpount CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed Thread-Index: AQHTIXLJNIlpz3f/yE6ODK9en612caKdECSAgAD+rQCACAB7AA== Date: Tue, 5 Sep 2017 08:22:04 +0000 Message-ID: References: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUyM2K7ou66uHWRBvtei1nsf3+IyWLP30Xs FvM7T7Nb/J84n9Vixetz7BYz/kxktnhx/SOzxfmd65kspi5/zGJx/ekuFgcuj52nDrB5LFny k8mj5eNCVo9ZO5+weEx+3MbssfXvX7YAtigum5TUnMyy1CJ9uwSujPevHzEXbOGvONl+hr2B cSFPFyMnh4SAicSmrr9MXYxcHEICRxglDjzoYIFwFjNKLP71jbmLkYODTcBCovufNkiDiMBq JolLj/hBapgFjjNKrFh9kg3EERZoZ5R49OIQO4gjItDBKLF3/SFGkG4RASeJ/1dLQEwWARWJ hbNlQAbxClhLTP36gRFi2SJGicZfC9hBEpwCNhK3905jA7EZBcQkvp9awwRiMwuIS9x6Mp8J 4mwBiSV7zjND2KISLx//YwWZLyqgJ/FuvydEWFGi/WkDI0SrgcT7c/OZIWxridkvP0PZ2hLL Fr5mhrhHUOLkzCcsExjFZyHZNgtJ+ywk7bOQtM9C0r6AkXUVo2hxanFSbrqRkV5qUWZycXF+ nl5easkmRmCkH9zy22AH48vnjocYBTgYlXh45cPXRQqxJpYVV+YeYpTgYFYS4e0IAwrxpiRW VqUW5ccXleakFh9ilOZgURLnddx3IUJIID2xJDU7NbUgtQgmy8TBKdXAWLt9n7rxc92fxfV8 Syz+J0W0pvHpcnPq7PC+6V6q8sBH350l6tOZrerNUlctC/7MUTE8+FjF8tL8eWve+Bs/Z11R U13yeebkp+lTYzrXbLz9iWlXOMcHE401GYF78q/7ndi4TmPpZWeD0E3JSRNn7jNT29n88bSS 4KMj3ZdjanIZLX5F67+ZoMRSnJFoqMVcVJwIAP6vZw/wAgAA Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 08:22:11 -0000 Hi, Some other issues have been raised, but I=92d like to double check whether someone has any issue with the suggestion to remove ufrag change as a trigger for a new DTLS association? Based on the comments received so far, I don=92t think anyone has objected. Regards, Christer On 31/08/17 09:10, "Christer Holmberg" wrote: >Hi, > >>>I have updated the PR. It should now address the IESG comments given by >>> Adam, Ekr, Alexey and Mirja. >>> >>> https://github.com/cdh4u/draft-dtls-sdp/pull/35 >>> >>> >>> In the latest commit (#7): >>> >>> - Section 7 (Transport Protocol Considerations) was removed. >>> - Text regarding correlation of SDP and TLS connection was added to the >>> Security Considerations (as requested by Mirja). >>> >>> Please let me know if there is something I=B9ve forgot. >> >>The list of issues I posted to MMUSIC included the question about >>whether ufrag change requires a DTLS restart in the absence of a >>'tls-id'. There was a bit of discussion on that list which seemed to >>conclude that it should *not*. I believe the document needs to reflect >>this -- but I'd specifically ask the MMUSIC chairs whether they see >>consensus on this point first. > > >Correct, I forgot to mention that the PR yet does not address the ufrag >issue, waiting for a WG consensus. > >Note that there is currently a discussion in RTCWEB on whether a ufrag >change should trigger an ICE restart. But, as an ICE restart does not >automatically trigger a DTLS restart I assume it won=92t affect >draft-dtls-sdp. Worth keeping in mind, though. > > >>On the topic of looking over your changes: it's still easier to read a >>text-form document than digging through XML source. Version numbers are >>free. I encourage you to drop a new version whenever you ask people to >>look at changes. > >I will submit a new version. > >Regards, > >Christer > From nobody Wed Sep 6 15:05:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD55132C23 for ; Wed, 6 Sep 2017 15:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=turbobridge.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcgDRyWJGwl9 for ; Wed, 6 Sep 2017 15:05:04 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5AC126B6E for ; Wed, 6 Sep 2017 15:05:04 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id e1so819605pfk.1 for ; Wed, 06 Sep 2017 15:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=turbobridge.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rKXtLP60bWfgODrXqXO3NAfUYGxzXV/lY3I0Myp4y9Y=; b=Zm8ItSucrLsbVx0AtOpYtPQ5Uc/cenGg1ysgaT4RYJWlBKcpaHXlV1Py7Y8M6KCKTi STnfNnSdZgX/Tcdg2kAbyBeUbgai/saFWjcva2jKlPnciIls9aOX7XnYCMKt+WtodgX3 uXe996SuzJQVikz38LVXbBbhL8yJjlzYGxxlA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rKXtLP60bWfgODrXqXO3NAfUYGxzXV/lY3I0Myp4y9Y=; b=nG3NYcEreiBI6OZru/wK2nRUxxs5rrrTPrZ0kH1WeL6hFqFp6wURduKW40Hg06uMe2 Y+MUF2nR4zh0PhfNLjpuPaIK0YCqnE8zshY8F0NYfzDaliNLVJiXsYNgFGQINGM18LAt mkKuAvKfE2xhmQj721g88UBlry+M8TLHbH86FEUrW6e+tnlGY1zQDlF/0T1VKaOBsxDt Qj8VuIq9QB63RGLLjyIX6k/eBb0TBeBuC7lojLaFBamfmPLd3vIJTWNfciPHjYFcL3yq HufLUESIWH+UUOFRVVWaY1oG04EX+pF/3j097u7x8WMuxnK2Kj21nde7sF4FU9p0oyEa 1JWQ== X-Gm-Message-State: AHPjjUjsrilbi9mUcY6uwUlPbpFKBUXguJlhNlLGt+JmbMlVq6u8QVqW vMMhCtuFm45FJUTs X-Received: by 10.98.70.136 with SMTP id o8mr594731pfi.241.1504735504259; Wed, 06 Sep 2017 15:05:04 -0700 (PDT) Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com. [74.125.83.47]) by smtp.gmail.com with ESMTPSA id o19sm795851pgn.76.2017.09.06.15.05.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Sep 2017 15:05:03 -0700 (PDT) Received: by mail-pg0-f47.google.com with SMTP id 188so14236327pgb.2; Wed, 06 Sep 2017 15:05:03 -0700 (PDT) X-Google-Smtp-Source: ADKCNb4fpSpT0vsRKWwnehry5juHES845UWeEfUtoImalruq115f3TyqqfmIRxkpxYhav5DSex/i3JrpP8YKivOtUYk= X-Received: by 10.84.133.99 with SMTP id 90mr652893plf.374.1504735503065; Wed, 06 Sep 2017 15:05:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Wed, 6 Sep 2017 15:05:02 -0700 (PDT) In-Reply-To: References: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> From: Roman Shpount Date: Wed, 6 Sep 2017 18:05:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Adam Roach , Ben Campbell , Eric Rescorla , Alexey Melnikov , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG Content-Type: multipart/alternative; boundary="94eb2c030c9824376005588c8933" Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 22:05:07 -0000 --94eb2c030c9824376005588c8933 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christer, I think we should spell this out a little bit more. If tls-id was present in both offer and and answer, end points should use the model specified in this draft and only setup new DTLS association when either of tls-id values changed. If tls-id was not present in either offer or answer, end points should the legacy mode defined in RFC 5763. In the legacy mode, new DTLS association is established when: a. transport parameters changed in either offer or answer b. fingerprints changed in either offer or answer c. setup roles, negotiated as a result of offer/answer exchange, are different from the setup roles before offer/answer exchange When ICE is used, transport parameters, including c=3D and m=3D SDP line values, as well as values of ice-ufrag, ice-pwd, or other ICE related SDP attributes have no effect on when new DTLS association is established, After ICE restart, new DTLS association is only established due to changes in fingerprints in either offer or answer, or due to change in negotiated setup role. Note that new DTLS association is not established due to change in tls-id in the offer if tls-id was not present in the answer and none of the other legacy mode requirements were satisfied. Also note, that in the legacy mode, new DTLS association can be established even if transport parameters, fingerprints and setup role in the answer are identical to previously received values from the same end point, if transport parameters or fingerprints changed in the offer. Regards, _____________ Roman Shpount On Tue, Sep 5, 2017 at 4:22 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > Some other issues have been raised, but I=E2=80=99d like to double check = whether > someone has any issue with the suggestion to remove ufrag change as a > trigger for a new DTLS association? > > Based on the comments received so far, I don=E2=80=99t think anyone has o= bjected. > > Regards, > > Christer > > > > > > > > > > > On 31/08/17 09:10, "Christer Holmberg" > wrote: > > >Hi, > > > >>>I have updated the PR. It should now address the IESG comments given b= y > >>> Adam, Ekr, Alexey and Mirja. > >>> > >>> https://github.com/cdh4u/draft-dtls-sdp/pull/35 > >>> > >>> > >>> In the latest commit (#7): > >>> > >>> - Section 7 (Transport Protocol Considerations) was removed. > >>> - Text regarding correlation of SDP and TLS connection was added to t= he > >>> Security Considerations (as requested by Mirja). > >>> > >>> Please let me know if there is something I=C2=B9ve forgot. > >> > >>The list of issues I posted to MMUSIC included the question about > >>whether ufrag change requires a DTLS restart in the absence of a > >>'tls-id'. There was a bit of discussion on that list which seemed to > >>conclude that it should *not*. I believe the document needs to reflect > >>this -- but I'd specifically ask the MMUSIC chairs whether they see > >>consensus on this point first. > > > > > >Correct, I forgot to mention that the PR yet does not address the ufrag > >issue, waiting for a WG consensus. > > > >Note that there is currently a discussion in RTCWEB on whether a ufrag > >change should trigger an ICE restart. But, as an ICE restart does not > >automatically trigger a DTLS restart I assume it won=E2=80=99t affect > >draft-dtls-sdp. Worth keeping in mind, though. > > > > > >>On the topic of looking over your changes: it's still easier to read a > >>text-form document than digging through XML source. Version numbers are > >>free. I encourage you to drop a new version whenever you ask people to > >>look at changes. > > > >I will submit a new version. > > > >Regards, > > > >Christer > > > > --94eb2c030c9824376005588c8933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christer,

I think we should spell this = out a little bit more.

If tls-id was present in bo= th offer and and answer, end points should use the model specified in this = draft and only setup new DTLS association when either of tls-id values chan= ged.

If tls-id was not present in either offer or answe= r, end points should the legacy mode defined in RFC 5763. In the legacy mod= e, new DTLS association is established when:

a. transport= parameters changed in either offer or answer
b. fingerprints cha= nged in either offer or answer
c. setup roles, negotiated as a re= sult of offer/answer exchange, are different from the setup roles before of= fer/answer exchange

When ICE is used, transport paramet= ers, including c=3D and m=3D=C2=A0 SDP line values, as well as values of ic= e-ufrag, ice-pwd, or other ICE related SDP attributes have no effect on whe= n new DTLS association is established,=C2=A0 After ICE restart, new DTLS as= sociation is only established due to changes in fingerprints in either offe= r or answer, or due to change in negotiated setup role.=C2=A0
Note that new DTLS association is not established due to change= in tls-id in the offer if tls-id was not present in the answer and none of= the other legacy mode requirements were satisfied.

Also note, that in the legacy mode, new DTLS association can be establish= ed even if transport parameters, fingerprints and setup role in the answer = are identical to previously received values from the same end point, if tra= nsport parameters or fingerprints changed in the offer.
Regards,

__= ___________
Roman Shpount

On Tue, Sep 5, 2017 at 4:22 AM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:

Hi,

Some other issues have been raised, but I=E2=80=99d like to double check wh= ether
someone has any issue with the suggestion to remove ufrag change as a
trigger for a new DTLS association?

Based on the comments received so far, I don=E2=80=99t think anyone has obj= ected.

Regards,

Christer










On 31/08/17 09:10, "Christer Holmberg" <christer.holmberg@ericsson.com>
wrote:

>Hi,
>
>>>I have updated the PR. It should now address the IESG comments = given by
>>> Adam, Ekr, Alexey and Mirja.
>>>
>>> https://github.com/cdh4u/draft-dtls= -sdp/pull/35
>>>
>>>
>>> In the latest commit (#7):
>>>
>>> - Section 7 (Transport Protocol Considerations) was removed. >>> - Text regarding correlation of SDP and TLS connection was add= ed to the
>>> Security Considerations (as requested by Mirja).
>>>
>>> Please let me know if there is something I=C2=B9ve forgot.
>>
>>The list of issues I posted to MMUSIC included the question about >>whether ufrag change requires a DTLS restart in the absence of a >>'tls-id'. There was a bit of discussion on that list which = seemed to
>>conclude that it should *not*. I believe the document needs to refl= ect
>>this -- but I'd specifically ask the MMUSIC chairs whether they= see
>>consensus on this point first.
>
>
>Correct, I forgot to mention that the PR yet does not address the ufrag=
>issue, waiting for a WG consensus.
>
>Note that there is currently a discussion in RTCWEB on whether a ufrag<= br> >change should trigger an ICE restart. But, as an ICE restart does not >automatically trigger a DTLS restart I assume it won=E2=80=99t affect >draft-dtls-sdp. Worth keeping in mind, though.
>
>
>>On the topic of looking over your changes: it's still easier to= read a
>>text-form document than digging through XML source. Version numbers= are
>>free. I encourage you to drop a new version whenever you ask people= to
>>look at changes.
>
>I will submit a new version.
>
>Regards,
>
>Christer
>


--94eb2c030c9824376005588c8933-- From nobody Wed Sep 6 22:17:05 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F2D132392; Wed, 6 Sep 2017 22:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 QY6BrpLV2Af6; Wed, 6 Sep 2017 22:16:57 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6CEC013219F; Wed, 6 Sep 2017 22:16:55 -0700 (PDT) X-AuditID: c1b4fb2d-4e93a9c0000057a4-64-59b0d64532fb Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.E5.22436.546D0B95; Thu, 7 Sep 2017 07:16:54 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 07:16:52 +0200 From: Christer Holmberg To: Roman Shpount CC: Adam Roach , Ben Campbell , "Eric Rescorla" , Alexey Melnikov , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "draft-ietf-mmusic-dtls-sdp@ietf.org" , "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , The IESG Thread-Topic: Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed Thread-Index: AQHTIXLJNIlpz3f/yE6ODK9en612caKdECSAgAD+rQCACAB7AIACRKcAgACYHfA= Date: Thu, 7 Sep 2017 05:16:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5629D167@ESESSMB109.ericsson.se> References: <244f9778-9cc4-eb99-bec1-f1905e7ec00e@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2K7k67btQ2RBos72S32vz/EZLHn7yJ2 i/mdp9kt/k+cz2qx4vU5dosZfyYyW7y4/pHZ4vzO9UwWU5c/ZrG4/nQXiwOXx85TB9g8liz5 yeTR8nEhq8esnU9YPCY/bmP22Pr3L1sAWxSXTUpqTmZZapG+XQJXxrJVi9kKDmlU7Dp8l7GB cY96FyMnh4SAicTSd+sYuxi5OIQEjjBK/D83hRXCWcwo8WXBVSCHg4NNwEKi+582SIOIgI7E hEmz2UFqmAUmMEt8mPmRDSQhLNDOKHH7UR1IQkSgg1Fi7/pDjBAdfhL9v9eyg9gsAioS/269 ZgKxeQV8JdrPvYXaNptJovHdabAEp0CgxIdpq1hAbEYBMYnvp9aAxZkFxCVuPZnPBHG3gMSS PeeZIWxRiZeP/7FC2EoSaw9vZwG5mllAU2L9Ln2IVkWJKd0P2SH2CkqcnPmEZQKj6CwkU2ch dMxC0jELSccCRpZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIERenDLb90djKtfOx5iFOBg VOLhdTm4IVKINbGsuDL3EKMEB7OSCO/LM0Ah3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQI CaQnlqRmp6YWpBbBZJk4OKUaGBV2bNfWaNvWcOyZ23fRnt51M8+66UY3/D/+3qmkqHD7ic/T rbaZmt/zmMKRfj1s2Q4+hSPVWzJ9b5+XEeHcf+5VntTVjb/U/26f0xOXKCUuLH3nm90511Vu Tq0HxFvDe5lameNTvXimdVVabjA5F38199D6RXN+KgrmzvEPaDRdmH0yKO8PuxJLcUaioRZz UXEiAHRPpfTMAgAA Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 05:16:59 -0000 SGksDQoNCj5JIHRoaW5rIHdlIHNob3VsZCBzcGVsbCB0aGlzIG91dCBhIGxpdHRsZSBiaXQgbW9y ZS4NCj4NCj5JZiB0bHMtaWQgd2FzIHByZXNlbnQgaW4gYm90aCBvZmZlciBhbmQgYW5kIGFuc3dl ciwgZW5kIHBvaW50cyBzaG91bGQgdXNlIHRoZSBtb2RlbA0KPnNwZWNpZmllZCBpbiB0aGlzIGRy YWZ0IGFuZCBvbmx5IHNldHVwIG5ldyBEVExTIGFzc29jaWF0aW9uIHdoZW4gZWl0aGVyIG9mIHRs cy1pZCB2YWx1ZXMgY2hhbmdlZC4NCg0KWWVzLg0KDQo+SWYgdGxzLWlkIHdhcyBub3QgcHJlc2Vu dCBpbiBlaXRoZXIgb2ZmZXIgb3IgYW5zd2VyLCBlbmQgcG9pbnRzIHNob3VsZCB0aGUgbGVnYWN5 IG1vZGUgZGVmaW5lZCBpbiBSRkMgNTc2My4gSW4gdGhlIGxlZ2FjeSBtb2RlLCBuZXcgRFRMUyBh c3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZCB3aGVuOg0KPg0KPmEuIHRyYW5zcG9ydCBwYXJhbWV0 ZXJzIGNoYW5nZWQgaW4gZWl0aGVyIG9mZmVyIG9yIGFuc3dlcg0KPmIuIGZpbmdlcnByaW50cyBj aGFuZ2VkIGluIGVpdGhlciBvZmZlciBvciBhbnN3ZXINCj5jLiBzZXR1cCByb2xlcywgbmVnb3Rp YXRlZCBhcyBhIHJlc3VsdCBvZiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UsIGFyZSBkaWZmZXJlbnQg ZnJvbSB0aGUgc2V0dXAgcm9sZXMgYmVmb3JlIG9mZmVyL2Fuc3dlciBleGNoYW5nZQ0KDQpZZXMu DQoNCj5XaGVuIElDRSBpcyB1c2VkLCB0cmFuc3BvcnQgcGFyYW1ldGVycywgaW5jbHVkaW5nIGM9 IGFuZCBtPcKgIFNEUCBsaW5lIHZhbHVlcywgYXMgd2VsbCBhcyB2YWx1ZXMgb2YgaWNlLXVmcmFn LCBpY2UtcHdkLCBvciBvdGhlciBJQ0UgcmVsYXRlZCBTRFAgYXR0cmlidXRlcyBoYXZlIG5vIGVm ZmVjdCBvbiA+d2hlbiBuZXcgRFRMUyBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZCwNCg0KQ3Vy cmVudGx5LCBpbiB0aGUgZHJhZnQsIHRoZSB1ZnJhZyBET0VTIGhhdmUgYW4gaW1wYWN0LCBidXQg dGhlIHN1Z2dlc3Rpb24gaXMgdG8gY2hhbmdlIHRoYXQuDQoNCj5BZnRlciBJQ0UgcmVzdGFydCwg bmV3IERUTFMgYXNzb2NpYXRpb24gaXMgb25seSBlc3RhYmxpc2hlZCBkdWUgdG8gY2hhbmdlcyBp biBmaW5nZXJwcmludHMgaW4gZWl0aGVyIG9mZmVyIG9yIGFuc3dlciwgb3IgZHVlIHRvIGNoYW5n ZSBpbiBuZWdvdGlhdGVkIHNldHVwIHJvbGUuwqANCg0KWWVzLg0KDQo+Tm90ZSB0aGF0IG5ldyBE VExTIGFzc29jaWF0aW9uIGlzIG5vdCBlc3RhYmxpc2hlZCBkdWUgdG8gY2hhbmdlIGluIHRscy1p ZCBpbiB0aGUgb2ZmZXIgaWYgdGxzLWlkIHdhcyBub3QgcHJlc2VudCBpbiB0aGUgYW5zd2VyIGFu ZCBub25lIG9mIHRoZSBvdGhlciBsZWdhY3kgbW9kZSByZXF1aXJlbWVudHMgPndlcmUgc2F0aXNm aWVkLg0KDQpZZXMuDQoNCj5BbHNvIG5vdGUsIHRoYXQgaW4gdGhlIGxlZ2FjeSBtb2RlLCBuZXcg RFRMUyBhc3NvY2lhdGlvbiBjYW4gYmUgZXN0YWJsaXNoZWQgZXZlbiBpZiB0cmFuc3BvcnQgcGFy YW1ldGVycywgZmluZ2VycHJpbnRzIGFuZCBzZXR1cCByb2xlIGluIHRoZSBhbnN3ZXIgYXJlIGlk ZW50aWNhbCB0byA+cHJldmlvdXNseSByZWNlaXZlZCB2YWx1ZXMgZnJvbSB0aGUgc2FtZSBlbmQg cG9pbnQsIGlmIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIG9yIGZpbmdlcnByaW50cyBjaGFuZ2VkIGlu IHRoZSBvZmZlci4NCg0KWWVzLg0KDQpTbywgdGhlIHN1Z2dlc3Rpb24gaXMgdG8gcmVtb3ZlICJJ Q0UgdWZyYWcgdmFsdWUiIGZyb20gdGhlIGJ1bGxldCBsaXN0IGluIHNlY3Rpb24gNC4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KSGksDQoN ClNvbWUgb3RoZXIgaXNzdWVzIGhhdmUgYmVlbiByYWlzZWQsIGJ1dCBJ4oCZZCBsaWtlIHRvIGRv dWJsZSBjaGVjayB3aGV0aGVyDQpzb21lb25lIGhhcyBhbnkgaXNzdWUgd2l0aCB0aGUgc3VnZ2Vz dGlvbiB0byByZW1vdmUgdWZyYWcgY2hhbmdlIGFzIGENCnRyaWdnZXIgZm9yIGEgbmV3IERUTFMg YXNzb2NpYXRpb24/DQoNCkJhc2VkIG9uIHRoZSBjb21tZW50cyByZWNlaXZlZCBzbyBmYXIsIEkg ZG9u4oCZdCB0aGluayBhbnlvbmUgaGFzIG9iamVjdGVkLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiAzMS8wOC8xNyAwOToxMCwgIkNocmlzdGVyIEhvbG1i ZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCj5IaSwNCj4N Cj4+PkkgaGF2ZSB1cGRhdGVkIHRoZSBQUi4gSXQgc2hvdWxkIG5vdyBhZGRyZXNzIHRoZSBJRVNH IGNvbW1lbnRzIGdpdmVuIGJ5DQo+Pj4gQWRhbSwgRWtyLCBBbGV4ZXkgYW5kIE1pcmphLg0KPj4+ DQo+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWR0bHMtc2RwL3B1bGwvMzUNCj4+ Pg0KPj4+DQo+Pj4gSW4gdGhlIGxhdGVzdCBjb21taXQgKCM3KToNCj4+Pg0KPj4+IC0gU2VjdGlv biA3IChUcmFuc3BvcnQgUHJvdG9jb2wgQ29uc2lkZXJhdGlvbnMpIHdhcyByZW1vdmVkLg0KPj4+ IC0gVGV4dCByZWdhcmRpbmcgY29ycmVsYXRpb24gb2YgU0RQIGFuZCBUTFMgY29ubmVjdGlvbiB3 YXMgYWRkZWQgdG8gdGhlDQo+Pj4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgKGFzIHJlcXVlc3Rl ZCBieSBNaXJqYSkuDQo+Pj4NCj4+PiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhlcmUgaXMgc29t ZXRoaW5nIEnCuXZlIGZvcmdvdC4NCj4+DQo+PlRoZSBsaXN0IG9mIGlzc3VlcyBJIHBvc3RlZCB0 byBNTVVTSUMgaW5jbHVkZWQgdGhlIHF1ZXN0aW9uIGFib3V0DQo+PndoZXRoZXIgdWZyYWcgY2hh bmdlIHJlcXVpcmVzIGEgRFRMUyByZXN0YXJ0IGluIHRoZSBhYnNlbmNlIG9mIGENCj4+J3Rscy1p ZCcuIFRoZXJlIHdhcyBhIGJpdCBvZiBkaXNjdXNzaW9uIG9uIHRoYXQgbGlzdCB3aGljaCBzZWVt ZWQgdG8NCj4+Y29uY2x1ZGUgdGhhdCBpdCBzaG91bGQgKm5vdCouIEkgYmVsaWV2ZSB0aGUgZG9j dW1lbnQgbmVlZHMgdG8gcmVmbGVjdA0KPj50aGlzIC0tIGJ1dCBJJ2Qgc3BlY2lmaWNhbGx5IGFz ayB0aGUgTU1VU0lDIGNoYWlycyB3aGV0aGVyIHRoZXkgc2VlDQo+PmNvbnNlbnN1cyBvbiB0aGlz IHBvaW50IGZpcnN0Lg0KPg0KPg0KPkNvcnJlY3QsIEkgZm9yZ290IHRvIG1lbnRpb24gdGhhdCB0 aGUgUFIgeWV0IGRvZXMgbm90IGFkZHJlc3MgdGhlIHVmcmFnDQo+aXNzdWUsIHdhaXRpbmcgZm9y IGEgV0cgY29uc2Vuc3VzLg0KPg0KPk5vdGUgdGhhdCB0aGVyZSBpcyBjdXJyZW50bHkgYSBkaXNj dXNzaW9uIGluIFJUQ1dFQiBvbiB3aGV0aGVyIGEgdWZyYWcNCj5jaGFuZ2Ugc2hvdWxkIHRyaWdn ZXIgYW4gSUNFIHJlc3RhcnQuIEJ1dCwgYXMgYW4gSUNFIHJlc3RhcnQgZG9lcyBub3QNCj5hdXRv bWF0aWNhbGx5IHRyaWdnZXIgYSBEVExTIHJlc3RhcnQgSSBhc3N1bWUgaXQgd29u4oCZdCBhZmZl Y3QNCj5kcmFmdC1kdGxzLXNkcC4gV29ydGgga2VlcGluZyBpbiBtaW5kLCB0aG91Z2guDQo+DQo+ DQo+Pk9uIHRoZSB0b3BpYyBvZiBsb29raW5nIG92ZXIgeW91ciBjaGFuZ2VzOiBpdCdzIHN0aWxs IGVhc2llciB0byByZWFkIGENCj4+dGV4dC1mb3JtIGRvY3VtZW50IHRoYW4gZGlnZ2luZyB0aHJv dWdoIFhNTCBzb3VyY2UuIFZlcnNpb24gbnVtYmVycyBhcmUNCj4+ZnJlZS4gSSBlbmNvdXJhZ2Ug eW91IHRvIGRyb3AgYSBuZXcgdmVyc2lvbiB3aGVuZXZlciB5b3UgYXNrIHBlb3BsZSB0bw0KPj5s b29rIGF0IGNoYW5nZXMuDQo+DQo+SSB3aWxsIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uLg0KPg0KPlJl Z2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCg0K From nobody Thu Sep 7 06:28:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF821132EF8; Thu, 7 Sep 2017 06:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pN-WtPGO6m6r; Thu, 7 Sep 2017 06:28:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 2C94E132EF9; Thu, 7 Sep 2017 06:28:17 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-1d-59b1496e389a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.A0.20899.E6941B95; Thu, 7 Sep 2017 15:28:15 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Thu, 7 Sep 2017 15:28:14 +0200 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , Ben Campbell , "mmusic@ietf.org" , Alexey Melnikov , =?Windows-1252?Q?Mirja_K=FChlewind?= , The IESG , "mmusic-chairs@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed Thread-Index: AQHTJ90n6CnVp9BEd0iNUDbGVs1KhA== Date: Thu, 7 Sep 2017 13:28:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: <119FAF2AE607104A9F407120F93EC437@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7tG6+58ZIg4NtTBb73x9ispjfeZrd 4v/E+awWM/5MZLZ4cf0js8X5neuZLKYuf8xicf3pLhYHDo+dpw6weSxZ8pPJo+XjQlaPWTuf sHhs/fuXLYA1issmJTUnsyy1SN8ugStjzZL/TAUrlSsOXFzO2MC4WqaLkZNDQsBE4uKuCYxd jFwcQgJHGCXmPvnDDuEsZpRYP2s7kMPBwSZgIdH9TxukQUQgSaJt5icWkBpmgYtMEu/nfGYF cYQFJjFKHHh9mAnEERGYzCix+O5FFogWPYl7BxezgdgsAioSH8/+ZgWxeQWsJZ4suwBWwygg JvH91BomEJtZQFzi1pP5TBD3CUgs2XOeGcIWlXj5+B8ryEWiQDPf7feECCtK7DzbzgzRaiDx /tx8ZpASZqDx87+lQIS1JZYtfM0MsVVQ4uTMJywTGEVnIVk2C0n3LITuWUi6ZyHpXsDIuopR tDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMDIPbvlttYPx4HPHQ4wCHIxKPLxxJhsjhVgTy4or cw8xSnAwK4nwxrgDhXhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl 4uCUamD0f/K8hG0d55fgKb0C116Vxpixv1hs803mcfcvhi/fLl1ZtiV2ydmf6esZ2z6v0ZBY Ibr4suEt7QSJqQelfwTusFnQVbxv0ZMM84/l/Qx84rN0/W49E71q+fPwB56d0nXBljceTHp0 iuGpQZHPj43mW5inWkxR9X07IzRTWvHDiaPHToSWuZZsVGIpzkg01GIuKk4EAMPmks3IAgAA Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 13:28:21 -0000 Hi, I have created a pull request, that removes the ufrag modification as a trigger for a new DTLS association (in case there is no tls-id). https://github.com/cdh4u/draft-dtls-sdp/pull/38 AFAIK, nobody has objected to change. Regards, Christer On 07/09/17 08:16, "mmusic on behalf of Christer Holmberg" wrote: >Hi, > >>I think we should spell this out a little bit more. >> >>If tls-id was present in both offer and and answer, end points should >>use the model >>specified in this draft and only setup new DTLS association when either >>of tls-id values changed. > >Yes. > >>If tls-id was not present in either offer or answer, end points should >>the legacy mode defined in RFC 5763. In the legacy mode, new DTLS >>association is established when: >> >>a. transport parameters changed in either offer or answer >>b. fingerprints changed in either offer or answer >>c. setup roles, negotiated as a result of offer/answer exchange, are >>different from the setup roles before offer/answer exchange > >Yes. > >>When ICE is used, transport parameters, including c=3D and m=3D SDP line >>values, as well as values of ice-ufrag, ice-pwd, or other ICE related >>SDP attributes have no effect on >when new DTLS association is >>established, > >Currently, in the draft, the ufrag DOES have an impact, but the >suggestion is to change that. > >>After ICE restart, new DTLS association is only established due to >>changes in fingerprints in either offer or answer, or due to change in >>negotiated setup role. > >Yes. > >>Note that new DTLS association is not established due to change in >>tls-id in the offer if tls-id was not present in the answer and none of >>the other legacy mode requirements >were satisfied. > >Yes. > >>Also note, that in the legacy mode, new DTLS association can be >>established even if transport parameters, fingerprints and setup role in >>the answer are identical to >previously received values from the same >>end point, if transport parameters or fingerprints changed in the offer. > >Yes. > >So, the suggestion is to remove "ICE ufrag value" from the bullet list in >section 4. > >Regards, > >Christer > > > > > > > > > > > > > > > > >Hi, > >Some other issues have been raised, but I=92d like to double check whether >someone has any issue with the suggestion to remove ufrag change as a >trigger for a new DTLS association? > >Based on the comments received so far, I don=92t think anyone has objected= . > >Regards, > >Christer > > > > > > > > > > >On 31/08/17 09:10, "Christer Holmberg" >wrote: > >>Hi, >> >>>>I have updated the PR. It should now address the IESG comments given by >>>> Adam, Ekr, Alexey and Mirja. >>>> >>>> https://github.com/cdh4u/draft-dtls-sdp/pull/35 >>>> >>>> >>>> In the latest commit (#7): >>>> >>>> - Section 7 (Transport Protocol Considerations) was removed. >>>> - Text regarding correlation of SDP and TLS connection was added to >>>>the >>>> Security Considerations (as requested by Mirja). >>>> >>>> Please let me know if there is something I=B9ve forgot. >>> >>>The list of issues I posted to MMUSIC included the question about >>>whether ufrag change requires a DTLS restart in the absence of a >>>'tls-id'. There was a bit of discussion on that list which seemed to >>>conclude that it should *not*. I believe the document needs to reflect >>>this -- but I'd specifically ask the MMUSIC chairs whether they see >>>consensus on this point first. >> >> >>Correct, I forgot to mention that the PR yet does not address the ufrag >>issue, waiting for a WG consensus. >> >>Note that there is currently a discussion in RTCWEB on whether a ufrag >>change should trigger an ICE restart. But, as an ICE restart does not >>automatically trigger a DTLS restart I assume it won=92t affect >>draft-dtls-sdp. Worth keeping in mind, though. >> >> >>>On the topic of looking over your changes: it's still easier to read a >>>text-form document than digging through XML source. Version numbers are >>>free. I encourage you to drop a new version whenever you ask people to >>>look at changes. >> >>I will submit a new version. >> >>Regards, >> >>Christer >> > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Sep 7 07:26:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41D6132F2A for ; Thu, 7 Sep 2017 07:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4moGm4xl0NSe for ; Thu, 7 Sep 2017 07:26:23 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52AA132968 for ; Thu, 7 Sep 2017 07:26:23 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id s62so15491088ywg.0 for ; Thu, 07 Sep 2017 07:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fsXCd2PDeWwE9nUqVIBikv5T5lUuVy8rr3AoerHvAjU=; b=KqXz6uJXidEhuq3Irf4n7nZPmMDCg8lprb9L8irQFeXnw842Of8/VWDbs1MVLWmg1K uYfbwK9Sva52JQFnWlxtvuD3ci0sRapTI6tYq+nwz55uz8nV3ye7uTw/5izlCMC/6C8m yP0DNGqXb6mO8Jr5MCQjDE8JHNHUJF0ChvAvrYXmnfsNM0kqJVkmhaskoxgAor5CQFKG Pg0213G5jb5+I5QlqSaCysJrqWBmgDrcuB8YQYquD5lUYPKYjVmc5G1DcW99m+wTLFp7 6g2YrCbNIS2i9UFEuujoIhaOcKumZbiO5uhMRtpZqNCk+06sI9VIEnjo3QE3IFcAuyE/ iMMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fsXCd2PDeWwE9nUqVIBikv5T5lUuVy8rr3AoerHvAjU=; b=MtAQYlSVGCFyQl4Ud7/yruvJRgSIVZSAzgK8ggWaw4YFIZZFPCWP/be0UBRaRyJqGn nyHKvSmLvRVTYcbjPickKzUu0UtML13DmDOkayheIkV7v/5uC/NZ/rBz0lZtge+xS0Ie ZY0AgmF7EC5Qjhl4xiTS/BEPNYmR1OucITtYFIeZ6enzTLkhkUU5TGKUhurcl6CQ6HN9 TnV3Uk41gaR1kVGyqob5ORF/7pe8KufAyD/QVXwz21H+3QHnCWXlsahHZQ6LFx8No0VA dlFXIHIHfZpP/zBrZuHiOqWk3nz/rfld/sfE8fCAX9RgBIfoatCc2gjFseiYvWzvF9E2 bn7g== X-Gm-Message-State: AHPjjUgMPkGzMEtoXScGbUWCp4HZF1SVKykUS+VoPSZ0+BL3Zrk3SC/t sJCzIReAhqkoiEl8RUpAEhHj465X+SVr X-Google-Smtp-Source: ADKCNb5gzv5W9f6Zf3qaIFGj5pzTbR9hoZ6+jT2oKHq/j9IuGU52MgW3eDk4TNeplyStlJ7T8xrMr/tow7r2siXnvpc= X-Received: by 10.37.190.76 with SMTP id d12mr2266821ybm.204.1504794382715; Thu, 07 Sep 2017 07:26:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Thu, 7 Sep 2017 07:25:42 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Thu, 7 Sep 2017 07:25:42 -0700 Message-ID: To: Roman Shpount Cc: Paul Kyzivat , mmusic WG Content-Type: multipart/alternative; boundary="089e08230cbca4705b05589a3eee" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 14:26:26 -0000 --089e08230cbca4705b05589a3eee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 4, 2017 at 9:16 PM, Roman Shpount wrote: > On Tue, Sep 5, 2017 at 12:03 AM, Eric Rescorla wrote: > >> >> >> On Mon, Sep 4, 2017 at 8:48 PM, Roman Shpount wrote: >> >>> On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat >>>> wrote: >>>> >>>>> On 9/4/17 6:14 AM, Christer Holmberg wrote: >>>>> >>>>> Now, based on your suggestion, if the offerer doesn=C2=B9t know wheth= er the >>>>>>>> answerer supports tls-id, does that mean that the only way >>>>>>>> for the offerer to ensure that the re-offer will trigger a new DTL= S >>>>>>>> association is by modifying the fingerprint set in the offer? >>>>>>>> >>>>>>> >>>>>>> That's true in any case, because we have implementations which beha= ve >>>>>>> that way and we can't change them. >>>>>>> >>>>>> >>>>>> On GitHub you also suggested >>>>>> (https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the >>>>>> answerer, >>>>>> even if it supports tls-id, shall not be able to trigger a new DTLS >>>>>> association (read: change the tls-id value). I assume that means the >>>>>> answerer would not be able to change its fingerprint set either, or = do >>>>>> anything else that would trigger a new DTLS association? >>>>>> >>>>> >>>>> Why would you want to *prevent* the answerer from triggering a new >>>>> DTLS association??? >>>>> >>>> >>>> As noted previously, it's confusing and it's only possible at all in >>>> the edge case where the offerer offers an ICE restart but not a new DT= LS >>>> association. >>>> >>>> >>> The main reason new DTLS association can started by the answering party >>> is third party call control. The new DTLS association will be required = if >>> as a result of the offer/answer exchange two new end points ends up bei= ng >>> connected with each other by a third party call control agent. This is = a >>> fairly common scenario. If it is not supported interoperability with >>> existing implementations will be seriously affected. Please note that i= n >>> existing specification new DTLS association can already be started by t= he >>> answerer changing fingerprints, transport parameters, or setup role. >>> >> >> Well, as has been noted, the current specification is fairly unclear (I >> feel comfortable saying that as one of the authors), but as a practical >> matter, this only works if you already are doing an ICE restart. Is that >> what is happening in this instance? >> >> > Current specification is not very specific about ICE. It does allow > answerer to start a new DTLS association even if ICE restart is not > initiated. I am not sure how this will work in all the cases, but it > definitely works for third party call control, which, as far as I am > concerned, is the only useful use case of answerer triggering a new DTLS > association. ICE restart is required in case of the new offer generated i= n > response to INVITE with no SDP. Because of this, answerer can successfull= u > establish a new DTLS association by changing fingerprints. > Well, to recap, ICE restart can only be initiated by the offerer: https://tools.ietf.org/rfcmarkup?doc=3D5245#section-9.2.2 And as we discussed in detail, there's no real way to demux without an ICE restart, so I'm not interested in trying to preserve that case in the situations when it happens to work. In general, the offerer can simply offer a new tls-id if it's willing to accept a new TLS connection. I appreciate that this will also cause a TLS association even when the endpoints haven't changed, but this just doesn't seem like that big a deal. If you have a specific case in mind that this causes a problem for, I'd need to see a call-flow diagram to understand it. -Ekr And, since answerer is a new end point, ICE candidate pair nominated for > transport will end up to be a new distinct 5-tuple so new and old DTLS > associations can be easily demuxed. So, in some sense, current > specification works almost by accident. > > I would really like for this to continue to work since this is being used= . > > Regards, > _____________ > Roman Shpount > > --089e08230cbca4705b05589a3eee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 9:16 PM, Roman Shpount <roman@telurix.com&g= t; wrote:
On Tue, Sep 5, 2017 at 12= :03 AM, Eric Rescorla <ekr@rtfm.com> wrote:

<= br>
On Mon, Sep 4, 2017 at 8:48 PM, Roman Shpount <roman@telurix.com&= gt; wrote:
On Mon, Sep 4, 2017 at 10:41 AM, Eric Rescorla &l= t;ekr@rtfm.com> wrote:


On = Mon, Sep 4, 2017 at 7:37 AM, Paul Kyzivat <pkyzivat@alum.mit.edu&g= t; wrote:
On 9/4/17 6:14 AM, Christer Holmberg wrote:

Now, based on your suggestion, if the offerer doesn=C2=B9t know whether the=
answerer supports tls-id, does that mean that the only way
for the offerer to ensure that the re-offer will trigger a new DTLS
association is by modifying the fingerprint set in the offer?

That's true in any case, because we have implementations which behave that way and we can't change them.

On GitHub you also suggested
(https://github.com/cdh4u/draft-dtls-sdp/issue= s/37) that the answerer,
even if it supports tls-id, shall not be able to trigger a new DTLS
association (read: change the tls-id value). I assume that means the
answerer would not be able to change its fingerprint set either, or do
anything else that would trigger a new DTLS association?

Why would you want to *prevent* the answerer from triggering a new DTLS ass= ociation???

As noted previously,= it's confusing and it's only possible at all in the edge case wher= e the offerer offers an ICE restart but not a new DTLS association.


The = main reason new DTLS association can started by the answering party is thir= d party call control. The new DTLS association will be required if as a res= ult of the offer/answer exchange two new end points ends up being connected= with each other by a third party call control agent. This is a fairly comm= on scenario. If it is not supported interoperability with existing implemen= tations will be seriously affected. Please note that in existing specificat= ion new DTLS association can already be started by the answerer changing fi= ngerprints, transport parameters, or setup role.

Well, as has been noted, the current s= pecification is fairly unclear (I feel comfortable saying that as one of th= e authors), but as a practical matter, this only works if you already are d= oing an ICE restart. Is that what is happening in this instance?
=

Current= specification is not very specific about ICE. It does allow answerer to st= art a new DTLS association even if ICE restart is not initiated. I am not s= ure how this will work in all the cases, but it definitely works for third = party call control, which, as far as I am concerned, is the only useful use= case of answerer triggering a new DTLS association. ICE restart is require= d in case of the new offer generated in response to INVITE with no SDP. Bec= ause of this, answerer can successfullu establish a new DTLS association by= changing fingerprints.

Well, to recap, ICE restart can only be initiated by the offerer:
And as we discussed in detail, there's no real way to= demux without an ICE restart, so I'm not interested in trying to prese= rve that case in the situations when it happens to work. In general, the of= ferer can simply offer a new tls-id if it's willing to accept a new TLS= connection. I appreciate that this will also cause a TLS association even = when the endpoints haven't changed, but this just doesn't seem like= that big a deal.

If you have a specific case in m= ind that this causes a problem for, I'd need to see a call-flow diagram= to understand it.

-Ekr

<= br>
And, since answ= erer is a new end point, ICE candidate pair nominated for transport will en= d up to be a new distinct 5-tuple so new and old DTLS associations can be e= asily demuxed. So, in some sense, current specification works almost by acc= ident.

I would really like for this to continue to= work since this is being used.

Regards,
_____________
Roman Shpount<= /span>
=C2=A0

--089e08230cbca4705b05589a3eee-- From nobody Thu Sep 7 11:10:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3A913292F for ; Thu, 7 Sep 2017 11:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJv0pxL2HRd4 for ; Thu, 7 Sep 2017 11:10:52 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA390132D40 for ; Thu, 7 Sep 2017 11:10:50 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id q68so842490pgq.1 for ; Thu, 07 Sep 2017 11:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HgOTA4J5HymbrWgASVY1RRfJMRYGfPHezcNMkmahzNY=; b=PvLZBZNHQ6coSWFZkLJBSmW/NKw6tyDwYVxRYBW1UgWs6ON/RCoot8fAcnpmgBNc3T onzgYbWM6nppXyGP4vu999pMfJYj2X2KWORVuiMtbB0aRETGL7OMJ/Q+U3gax8WQtBID zUFfYLnVfYNPS57cVc6wbcCwHNl1tFCSgcWTwfQJz/4l1nJgUsmGFkBx0/Gz+PZU0Fq0 ESZ/hK4RF8cy68ngDS309a479ZWDwzLgTaAB2IBZOH8/vRuQHyrIU3FdnuNXnUjCj1/M 46qWhGP6agHNWVi0Qm4lFFbtgSdh5e9MKk9dySZ0ZfvKQ4XBxvwO6HJClvgKBE9Df6Df G9tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HgOTA4J5HymbrWgASVY1RRfJMRYGfPHezcNMkmahzNY=; b=swj351Gp2nodd5S40y61rkWf54cdKiBqU5acEotkmyRTp2uhjmvGm/djQNsgKsd4tk Ez69Yif2vLt12QghCx+p/tbvJRbYwIp4jcN4W55vtu+NMRkP86jYWKi3srtKm9o1G+MG nkpkv1z3qdKtEF9PN4Oaghc6ce4/gR1JH1kVpEKMmD8gtYsCxDONdAeqAha9AYiVo+FG PLxDJQT+8y7li688MtsDKwP72zTrXLeeH2fuTDAS58mgvrojsHlWAXPUlm43Mn0OXvHR 6zyzzDPZQTaiC7OcvATsj8Eqpib6MOvhbGUcez0vyG6rXBhWf46d93ejPoXxapNWCMVp PU4g== X-Gm-Message-State: AHPjjUi5euU3kV1FATyKGmZQ98aTSmbmMhKQjviUOHBkbewh2HdixNs1 dD5sU8wEX7YTFJ+YYDc= X-Received: by 10.98.220.66 with SMTP id t63mr218578pfg.328.1504807850208; Thu, 07 Sep 2017 11:10:50 -0700 (PDT) Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com. [74.125.83.45]) by smtp.gmail.com with ESMTPSA id 62sm371537pfu.4.2017.09.07.11.10.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Sep 2017 11:10:49 -0700 (PDT) Received: by mail-pg0-f45.google.com with SMTP id v66so804369pgb.5 for ; Thu, 07 Sep 2017 11:10:49 -0700 (PDT) X-Google-Smtp-Source: ADKCNb49LnbS2CpfKgw7lsIBK6d468LWpBdvyriZfFFLQx8xXxeZxe0Tv/mfwAlBbyva3kgKIx3bri1yA6Xb54sfV/U= X-Received: by 10.84.238.135 with SMTP id v7mr224664plk.276.1504807849041; Thu, 07 Sep 2017 11:10:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Thu, 7 Sep 2017 11:10:48 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> From: Roman Shpount Date: Thu, 7 Sep 2017 14:10:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Paul Kyzivat , mmusic WG Content-Type: multipart/alternative; boundary="f403045fdf884c249305589d610b" Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 18:10:55 -0000 --f403045fdf884c249305589d610b Content-Type: text/plain; charset="UTF-8" On Thu, Sep 7, 2017 at 10:25 AM, Eric Rescorla wrote: > > Well, to recap, ICE restart can only be initiated by the offerer: > https://tools.ietf.org/rfcmarkup?doc=5245#section-9.2.2 > > And as we discussed in detail, there's no real way to demux without an ICE > restart, so I'm not interested in trying to preserve that case in the > situations when it happens to work. In general, the offerer can simply > offer a new tls-id if it's willing to accept a new TLS connection. I > appreciate that this will also cause a TLS association even when the > endpoints haven't changed, but this just doesn't seem like that big a deal. > > If you have a specific case in mind that this causes a problem for, I'd > need to see a call-flow diagram to understand it. > > There are two specific scenarios that concern me: 1. Third Party Call Control a. End point A is connected to end point B through third party call control agent 3PCC b. 3PCC sends a request for a new offer to A (using SIP INVITE with no SDP body). c. End point A sends an offer with ICE restart (required in response to INVITE with no SDP) and existing tls-id d. 3PCC agent sends this offer as a new call offer to end point C e. This is a new offer for C, so it sends an answer with a new tls-id to 3PCC f. 3PCC sends an answer to end point A g. Since A got an answer with a new tls-id, a new DTLS association is established between A and C This also has an optional case, when end point C is legacy and it does not send back tls-id attribute, but does send new fingerprint values. I would prefer that new implementations were allowed for the same scenario using tls-id. Note that in step d, 3PCC can also send the re-offer back to B, which will result in existing DTLS association reuse. This is very common when session timers are implemented by 3PCC agents. 2. Connection Recovery a. End point is connected to a service (like conference service) which is comprised from multiple redundant media servers behind a single signaling proxy b. End point detects a network connectivity disruption via keep-alive timeout c. End point initiates connection recovery process by generating an offer with ICE restart and existing DTLS association (and media settings) and sends it to the signaling proxy d. If the network connectivity is restored to the same media server via a different network path, for instance due to client address change, existing DTLS association and media are re-used e. If connectivity failure was due to media server failure, connectivity is restored but to a different media server. New DTLS association and media connection is established in this case. Please note that case d is much less common then case e. In both cases it is possible to make things work by forcing new tls-id value in the offer. This will result in extra DTLS association, local ICE candidate allocations (which are required if new DTLS association is requested via new tls-id), and new media setup. All of those things will waste resources and more importantly will increase connection setup time. Regards, _____________ Roman Shpount --f403045fdf884c249305589d610b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 7, 2017 at 10:25 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:

Wel= l, to recap, ICE restart can only be initiated by the offerer:
https://tools.ietf.org/rfcmarkup?doc=3D5245#section-9.2.2

And as we discussed in detail, there&= #39;s no real way to demux without an ICE restart, so I'm not intereste= d in trying to preserve that case in the situations when it happens to work= . In general, the offerer can simply offer a new tls-id if it's willing= to accept a new TLS connection. I appreciate that this will also cause a T= LS association even when the endpoints haven't changed, but this just d= oesn't seem like that big a deal.

If you have = a specific case in mind that this causes a problem for, I'd need to see= a call-flow diagram to understand it.


There are two specific scenarios that co= ncern me:

1. Third Party Call Control
a. End point A is connected to end point B through third party= call control agent 3PCC
b. 3PCC sends a request for a new offer = to A (using SIP INVITE with no SDP body).
c. End point A sends an= offer with ICE restart (required in response to INVITE with no SDP) and ex= isting tls-id
d. 3PCC agent sends this offer as a new call offer = to end point C
e. This is a new offer for C, so it sends an answe= r with a new tls-id to 3PCC
f. 3PCC sends an answer to end point = A
g. Since A got an answer with a new tls-id, a new DTLS associat= ion is established between A and C

This also has a= n optional case, when end point C is legacy and it does not send back tls-i= d attribute, but does send new fingerprint values. I would prefer that new = implementations were allowed for the same scenario using tls-id.
=
Note that in step d, 3PCC can also send the=C2=A0 re-offer b= ack to B, which will result in existing DTLS association reuse. This is ver= y common when session timers are implemented by 3PCC agents.

=
2. Connection Recovery

a. End point is = connected to a service (like conference service) which is comprised from mu= ltiple redundant media servers behind a single signaling proxy
b.= End point detects a network connectivity disruption via keep-alive timeout=
c. End point initiates connection recovery process by generating= an offer with ICE restart and existing DTLS association (and media setting= s) and sends it to the signaling proxy
d. If the network connecti= vity is restored to the same media server via a different network path, for= instance due to client address change, existing DTLS association and media= are re-used=C2=A0
e. If connectivity failure was due to media se= rver failure, connectivity is restored but to a different media server. New= DTLS=C2=A0=C2=A0association and media connection is established in this ca= se.

Please note that case d is much less common th= en case e.

In both cases it is possible to make th= ings work by forcing new tls-id value in the offer. This will result in ext= ra DTLS association, local ICE candidate allocations (which are required if= new DTLS association is requested via new tls-id), and new media setup. Al= l of those things will waste resources and more importantly will increase c= onnection setup time.

Regards,
_____________
Roman Shpount
=C2=A0=
--f403045fdf884c249305589d610b-- From nobody Thu Sep 7 16:26:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC46B1320CC for ; Thu, 7 Sep 2017 16:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tVYotEpXlEqM for ; Thu, 7 Sep 2017 16:26:15 -0700 (PDT) Received: from smtp90.ord1c.emailsrvr.com (smtp90.ord1c.emailsrvr.com [108.166.43.90]) (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 06D251320B5 for ; Thu, 7 Sep 2017 16:26:14 -0700 (PDT) Received: from smtp4.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id A9C6BA052A; Thu, 7 Sep 2017 19:26:09 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6D0F8A04F4; Thu, 7 Sep 2017 19:26:09 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 07 Sep 2017 19:26:09 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 7 Sep 2017 17:26:08 -0600 Message-Id: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> To: mmusic X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:26:16 -0000 Do we still need the "k=3D" line in SDP? Could we just remove all of = section 5.12 ? From nobody Fri Sep 8 00:14:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DC1133134 for ; Fri, 8 Sep 2017 00:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rua8xHZKfblU for ; Fri, 8 Sep 2017 00:14:27 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6608313219A for ; Fri, 8 Sep 2017 00:14:27 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id q80so5204360ywg.2 for ; Fri, 08 Sep 2017 00:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EG/SNYYc4VtaHIy8O1lpYWZZZxOnrgqsDEulZWZnU/4=; b=VprGK8wHS5ChFXDcOKHAwzfWibmKgX0gD8m94x7Gmmu7xMXyEgRVjK+fQSyt5jbCkE z193rx1xhtv9oQV1lroMKuIDyyDrrA4akjFJI2FNrwpaWFtiOX7iTY2wNKfyI8Qfv1k5 9JHabd1YS23P3YJ8sFFwhSNj/7nvQt7Nl2KflBUsI4g4Bc5ar3a0mnsOG27qa9hEWdYr jLfJ1EfuiCtd0sTS1uBfQPpJvlSnDnu87CozX0xOiv66YnG06zOrXTv8kylWpMLwqbIE uRBdkuWlUUgW81LjwgMO5vffEzTa/+q7Zsgnj2SoMIPbjmwqXYOg2HXawkArd0kiwQum KVTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EG/SNYYc4VtaHIy8O1lpYWZZZxOnrgqsDEulZWZnU/4=; b=DpFvpGwmLK/paCYrMDGU61w1pW0+lYWPeSqQBUhbz9z/IlPtlIDzugT50tVZM5spIG oRK8bEmBktJPC1v+JwBRknKocUfB+R8Zf1zGcpqCijVoOYdX+Lw9S0bjGGRbomGCCewN o7Np7JmKX9CrwyKikHDay8FLYc2hSZodYVEPdrbcpKWlQ9m8okEJ+ZqJ2Bn4fIk74Yr6 8mFUVxvyX7oZbCuk5LKGlFFzUKtVLd5w0bgkyHSDSAFQtWTc57ymXAL8qG4E+chMhEUM k5/KN1OW5uLc6qRvNjNASbIfsAxcNA19TLTOsn7aVdFSLRfT7zTUtZqmPzJyawi79N7a lBrQ== X-Gm-Message-State: AHPjjUhPVlhJxjMZ31vEKud8ITP9H8W3lSB9iOd6xLSyCChxXoFhQ/Gv zgzSYzVh1/OVDEqXL6YE92ok4HhexYLg X-Google-Smtp-Source: ADKCNb60zR/Qq8gs+mEoFDy6LOOmYpzCFXmKzmlG0LjT8ZzuTE7LN0aS10oks+vyGTWcshP19FnmjzvS5vGdSZYvsVo= X-Received: by 10.13.192.130 with SMTP id b124mr1663484ywd.370.1504854866572; Fri, 08 Sep 2017 00:14:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.80.133 with HTTP; Fri, 8 Sep 2017 00:14:26 -0700 (PDT) In-Reply-To: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> From: "Ali C. Begen" Date: Fri, 8 Sep 2017 10:14:26 +0300 Message-ID: To: Cullen Jennings Cc: mmusic Content-Type: multipart/alternative; boundary="001a114e46a0c2cab20558a853ce" Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 07:14:29 -0000 --001a114e46a0c2cab20558a853ce Content-Type: text/plain; charset="UTF-8" I have not seen it being used, but it could be just me who has not seen it. Will be happy to remove it, if everyone agrees. On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings wrote: > Do we still need the "k=" line in SDP? Could we just remove all of section > 5.12 ? > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a114e46a0c2cab20558a853ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have not seen it being used, but it could be just me who= has not seen it. Will be happy to remove it, if everyone agrees.

On Fri, Sep 8, 2017 a= t 2:26 AM, Cullen Jennings <fluffy@iii.ca> wrote:
Do we still need the "k=3D" line in SDP? Coul= d we just remove all of section 5.12 ?


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

--001a114e46a0c2cab20558a853ce-- From nobody Fri Sep 8 00:23:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3244C13313F; Fri, 8 Sep 2017 00:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ueBwS9YzyAWI; Fri, 8 Sep 2017 00:23:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 0D1E613219A; Fri, 8 Sep 2017 00:23:22 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-7c-59b245680a99 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D8.3A.22436.86542B95; Fri, 8 Sep 2017 09:23:21 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Fri, 8 Sep 2017 09:23:20 +0200 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: "draft-ietf-mmusic-dtls-sdp@ietf.org" , Ben Campbell , "mmusic@ietf.org" , Alexey Melnikov , =?Windows-1252?Q?Mirja_K=FChlewind?= , The IESG , "mmusic-chairs@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed Thread-Index: AQHTJ90n6CnVp9BEd0iNUDbGVs1KhKKqqRYA Date: Fri, 8 Sep 2017 07:23:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2A03554EE20391469441FD4F933E4668@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUyM2K7q26m66ZIg9uP2C32vz/EZDG/8zS7 xf+J81ktZvyZyGzx4vpHZovzO9czWUxd/pjF4vrTXSwOHB47Tx1g81iy5CeTR8vHhawes3Y+ YfHY+vcvWwBrFJdNSmpOZllqkb5dAlfG+s+bWQrmqVWc77/K0sD4Tq6LkZNDQsBEYtn5o2xd jFwcQgJHGCWerrrHDOEsZpQ4u7uHvYuRg4NNwEKi+582SIOIQJJE28xPLCA1zAIXmSTez/nM CuIIC0xilDjw+jATiCMiMJlRYvHdiywQLUYS7Yc3M4PYLAIqEn2/vzOC2LwC1hKfexeA2UJA 9prJ78FqOAVsJC4dnArWyyggJvH91BomEJtZQFzi1pP5TBB3C0gs2XOeGcIWlXj5+B8ryKWi AnoS7/Z7gpgSAkoS07amQXQaSLw/N58ZwraWWHV1IxuErS2xbOFrZohrBCVOznzCMoFRfBaS ZbOQtM9C0j4LSfssJO0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG8sEtv3V3MK5+ 7XiIUYCDUYmH94rWpkgh1sSy4srcQ4wSHMxKIry7HIBCvCmJlVWpRfnxRaU5qcWHGKU5WJTE eR32XYgQEkhPLEnNTk0tSC2CyTJxcEo1MDaGrdpi7x+yMnHuJ5aJy3nzfVvk1pQo97/az2cb /XHR1/0OOctvq5lw/712wizo/Gup9gXLdZROf5P7e2jxo9TursBg+5UFK7yuMOgeLDI1vrSz O/BVqE3+WyfxvyxbL90tLfWTPyY+dcHM3WsCj6fFXe78x7Mhqt6t8tA2fl/zh+bOXqXlGkos xRmJhlrMRcWJAI/zJyHhAgAA Archived-At: Subject: Re: [MMUSIC] Adam Roach's No Objection on draft-ietf-mmusic-dtls-sdp-28: (with COMMENT) - All comments should now have been addressed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 07:23:26 -0000 Hi,=20 I intend to merge the PR today, and submit a new version of the draft. Regards, Christer On 07/09/17 16:28, "Christer Holmberg" wrote: >Hi, > >I have created a pull request, that removes the ufrag modification as a >trigger for a new DTLS association (in case there is no tls-id). > >https://github.com/cdh4u/draft-dtls-sdp/pull/38 > > >AFAIK, nobody has objected to change. > >Regards, > >Christer > > > >On 07/09/17 08:16, "mmusic on behalf of Christer Holmberg" > >wrote: > >>Hi, >> >>>I think we should spell this out a little bit more. >>> >>>If tls-id was present in both offer and and answer, end points should >>>use the model >>>specified in this draft and only setup new DTLS association when either >>>of tls-id values changed. >> >>Yes. >> >>>If tls-id was not present in either offer or answer, end points should >>>the legacy mode defined in RFC 5763. In the legacy mode, new DTLS >>>association is established when: >>> >>>a. transport parameters changed in either offer or answer >>>b. fingerprints changed in either offer or answer >>>c. setup roles, negotiated as a result of offer/answer exchange, are >>>different from the setup roles before offer/answer exchange >> >>Yes. >> >>>When ICE is used, transport parameters, including c=3D and m=3D SDP lin= e >>>values, as well as values of ice-ufrag, ice-pwd, or other ICE related >>>SDP attributes have no effect on >when new DTLS association is >>>established, >> >>Currently, in the draft, the ufrag DOES have an impact, but the >>suggestion is to change that. >> >>>After ICE restart, new DTLS association is only established due to >>>changes in fingerprints in either offer or answer, or due to change in >>>negotiated setup role. >> >>Yes. >> >>>Note that new DTLS association is not established due to change in >>>tls-id in the offer if tls-id was not present in the answer and none of >>>the other legacy mode requirements >were satisfied. >> >>Yes. >> >>>Also note, that in the legacy mode, new DTLS association can be >>>established even if transport parameters, fingerprints and setup role in >>>the answer are identical to >previously received values from the same >>>end point, if transport parameters or fingerprints changed in the offer. >> >>Yes. >> >>So, the suggestion is to remove "ICE ufrag value" from the bullet list in >>section 4. >> >>Regards, >> >>Christer >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>Hi, >> >>Some other issues have been raised, but I=92d like to double check whethe= r >>someone has any issue with the suggestion to remove ufrag change as a >>trigger for a new DTLS association? >> >>Based on the comments received so far, I don=92t think anyone has objecte= d. >> >>Regards, >> >>Christer >> >> >> >> >> >> >> >> >> >> >>On 31/08/17 09:10, "Christer Holmberg" >>wrote: >> >>>Hi, >>> >>>>>I have updated the PR. It should now address the IESG comments given >>>>>by >>>>> Adam, Ekr, Alexey and Mirja. >>>>> >>>>> https://github.com/cdh4u/draft-dtls-sdp/pull/35 >>>>> >>>>> >>>>> In the latest commit (#7): >>>>> >>>>> - Section 7 (Transport Protocol Considerations) was removed. >>>>> - Text regarding correlation of SDP and TLS connection was added to >>>>>the >>>>> Security Considerations (as requested by Mirja). >>>>> >>>>> Please let me know if there is something I=B9ve forgot. >>>> >>>>The list of issues I posted to MMUSIC included the question about >>>>whether ufrag change requires a DTLS restart in the absence of a >>>>'tls-id'. There was a bit of discussion on that list which seemed to >>>>conclude that it should *not*. I believe the document needs to reflect >>>>this -- but I'd specifically ask the MMUSIC chairs whether they see >>>>consensus on this point first. >>> >>> >>>Correct, I forgot to mention that the PR yet does not address the ufrag >>>issue, waiting for a WG consensus. >>> >>>Note that there is currently a discussion in RTCWEB on whether a ufrag >>>change should trigger an ICE restart. But, as an ICE restart does not >>>automatically trigger a DTLS restart I assume it won=92t affect >>>draft-dtls-sdp. Worth keeping in mind, though. >>> >>> >>>>On the topic of looking over your changes: it's still easier to read a >>>>text-form document than digging through XML source. Version numbers are >>>>free. I encourage you to drop a new version whenever you ask people to >>>>look at changes. >>> >>>I will submit a new version. >>> >>>Regards, >>> >>>Christer >>> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Sep 8 03:24:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5708C132D7B for ; Fri, 8 Sep 2017 03:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Tf-02Xobg-AY for ; Fri, 8 Sep 2017 03:24:33 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2390B13247A for ; Fri, 8 Sep 2017 03:24:33 -0700 (PDT) Received: from [81.187.2.149] (port=45347 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dqGSb-00042q-Vs; Fri, 08 Sep 2017 11:24:30 +0100 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_95C98AEC-6DDD-4429-A050-4DB9ACC26B04" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 8 Sep 2017 11:24:13 +0100 In-Reply-To: Cc: Cullen Jennings , mmusic To: "Ali C. Begen" References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 10:24:35 -0000 --Apple-Mail=_95C98AEC-6DDD-4429-A050-4DB9ACC26B04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think we can remove it =E2=80=93 we need to document it = for legacy reasons, if nothing else =E2=80=93 but we can certainly = strengthen the warnings not to use it. Colin > On 8 Sep 2017, at 08:14, Ali C. Begen = wrote: >=20 > I have not seen it being used, but it could be just me who has not = seen it. Will be happy to remove it, if everyone agrees. >=20 > On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings > wrote: > Do we still need the "k=3D" line in SDP? Could we just remove all of = section 5.12 ? >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_95C98AEC-6DDD-4429-A050-4DB9ACC26B04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I don=E2=80=99t think we can remove it =E2=80=93 we need to = document it for legacy reasons, if nothing else =E2=80=93 but we can = certainly strengthen the warnings not to use it.

Colin



On = 8 Sep 2017, at 08:14, Ali C. Begen <ali.begen@networked.media> wrote:

I have not seen it being used, but it could be just me who = has not seen it. Will be happy to remove it, if everyone = agrees.

On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings = <fluffy@iii.ca> wrote:
Do we still need the = "k=3D" line in SDP? Could we just remove all of section 5.12 ?


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

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



-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_95C98AEC-6DDD-4429-A050-4DB9ACC26B04-- From nobody Fri Sep 8 11:49:31 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1A71243F6; Fri, 8 Sep 2017 11:49:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150489656313.17184.7949898766618524607@ietfa.amsl.com> Date: Fri, 08 Sep 2017 11:49:23 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-30.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 18:49:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-30.txt Pages : 27 Date : 2017-09-08 Abstract: This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-30 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-30 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-30 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 Sep 8 11:51:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CCF13292A for ; Fri, 8 Sep 2017 11:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fkh9Rcg4t7LP for ; Fri, 8 Sep 2017 11:51:51 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 205811243F6 for ; Fri, 8 Sep 2017 11:51:50 -0700 (PDT) X-AuditID: c1b4fb3a-617ff700000051a3-c1-59b2e6c44ddd Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4A.C5.20899.4C6E2B95; Fri, 8 Sep 2017 20:51:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Fri, 8 Sep 2017 20:51:47 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-dtls-sdp-30 Thread-Index: AdMo00sbWxZIf/sZR9OC9c320Ey/oQ== Date: Fri, 8 Sep 2017 18:51:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562A53A2@ESESSMB109.ericsson.se> 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_7594FB04B1934943A5C02806D1A2204B562A53A2ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2J7uO6RZ5siDa4d1rSYuvwxiwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mv6dfspUsE2s4s/E6SwNjN+Fuxg5OSQETCR6m38wdTFycQgJ HGGUuP7zABuEs5hRYufVHyxdjBwcbAIWEt3/tEEaRATUJb7u7WEGsYUFdCXWdtxhgYgbSXRN eckEYetJvJ24ixHEZhFQkTi8dwFYDa+Ar8Tq3stsIDajgJjE91NrwOqZBcQlbj2ZzwRxkIDE kj3nmSFsUYmXj/+xQthKEiu2X2KEqM+XaD65nRlipqDEyZlPWCYwCs5CMmoWkrJZSMog4joS C3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzA0D+4 5bfVDsaDzx0PMQpwMCrx8E68uClSiDWxrLgy9xCjBAezkgjvgqdAId6UxMqq1KL8+KLSnNTi Q4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhgXs2nkKDaFxgrvn7SpvHvVaQ/jSVF5 lnHXP1s++HmC+02luGId24XaWilZe7Yfre/snkwKtmkR06yZ6sWd2jk9e98imb2Rof9ZV7bf sWr7+lrOXGmm4rkbsfa/Hr0IVfjM63Op0jmeV+7e1O1MRnPNc9a6SKpPypGZfzX41w8OvVdz hH2mPVFiKc5INNRiLipOBAAmKKaQeQIAAA== Archived-At: Subject: [MMUSIC] Draft new version: draft-dtls-sdp-30 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 18:51:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562A53A2ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-30) of draft-ietf-mmusic-dtls-sdp. ufrag change has been removed from the list of events triggering a new DTLS= association (in case tls-id is not present). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B562A53A2ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-30) of draft-ie= tf-mmusic-dtls-sdp.

 

ufrag change has been removed from the list of event= s triggering a new DTLS association (in case tls-id is not present).

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B562A53A2ESESSMB109erics_-- From nobody Sun Sep 10 12:07:39 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B513219F; Sun, 10 Sep 2017 12:07:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150507045174.8191.870320335854373033@ietfa.amsl.com> Date: Sun, 10 Sep 2017 12:07:31 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-13.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 19:07:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-data-channel-sdpneg-13.txt Pages : 41 Date : 2017-09-10 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-13 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-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 Sun Sep 10 12:10:10 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE9129A89; Sun, 10 Sep 2017 12:10:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150507060237.8140.8384713317447655103@ietfa.amsl.com> Date: Sun, 10 Sep 2017 12:10:02 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-msrp-usage-data-channel-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 19:10:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : MSRP over Data Channels Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-msrp-usage-data-channel-07.txt Pages : 17 Date : 2017-09-10 Abstract: This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based generic data channel negotiation framework. Two network configurations are documented: a WebRTC end- to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-07 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-msrp-usage-data-channel-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msrp-usage-data-channel-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 12 00:21:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6CC1332E0 for ; Tue, 12 Sep 2017 00:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vQC8vYitoiP7 for ; Tue, 12 Sep 2017 00:21:03 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E427B1332DF for ; Tue, 12 Sep 2017 00:21:02 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-48-59b78adca22a Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F4.88.21299.CDA87B95; Tue, 12 Sep 2017 09:21:01 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Tue, 12 Sep 2017 09:21:00 +0200 From: Christer Holmberg To: Roman Shpount , Eric Rescorla CC: mmusic WG , Paul Kyzivat Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKbMmOAgAbGf4CAADCNsP//5vyAgACksACAAMvvAIAAKExw///nloCAARKTgIAAFdgAgAABBgCAANwjAIAABACAgAADowCAA87yAIAAPuUAgAdZzwA= Date: Tue, 12 Sep 2017 07:20:59 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B562818F7@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B56282B43@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B562869A2@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D5DD66072148Echristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2J7oO7dru2RBpcnslqseH2O3WLq8scs Fis2HGC1mHFhKrMDi8ff9x+YPJYs+cnkMflxG7PHrSkFASxRXDYpqTmZZalF+nYJXBknbl1m LZgWUrGybRZrA+NGty5GTg4JAROJaSevsXQxcnEICRxhlLi44wUjhLOEUWL9lYlADgcHm4CF RPc/bZAGEQFnia7ee6wgNrOAq8TEGb/BSoQFDCVOnGGBKDGSuHz8ATPIGBGBeYwSf9q3gtWz CKhKbG+/DmbzClhLHO17wQyx6z+HxJFJd5hBBnEKBEpsOpwPUsMoICbx/dQaJohd4hK3nsxn gjhaQGLJnvPMELaoxMvH/1hBWkUF9CTe7fcEMSUElCSmbU2D6EyQON0wjQ1iq6DEyZlPWCYw is5CMnQWkrJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhHCtpa40N3AhKxmASPHKkbR4tTi pNx0I2O91KLM5OLi/Dy9vNSSTYzASD245bfqDsbLbxwPMQpwMCrx8JqWbI8UYk0sK67MPcQo wcGsJMK7qwAoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNdx34UIIYH0xJLU7NTUgtQimCwTB6dU A6Njzy6W/M1qV62eTAsT2LDAvUU77NlU7rf6ERXl3Waq7ZNnCV7WlrDUXPzg/NT66unyIRc3 vtOsi9V+nce3sFZp4/5dVyQirvtavnpcE3rp38fT3hwulzle1a281VQayf3RLNOdMWn7Edst szl2Oc265vQi74eTBk9Kp/WqBglz4TOnWutfX1ViKc5INNRiLipOBACICzf70AIAAA== Archived-At: Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 07:21:06 -0000 --_000_D5DD66072148Echristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable OK, how do we move forward? Silence won=92t do it. Can people live with the= current text? (Version =9630 was submitted last week, with the ufrag change removed from = the list in section 4.) Regards, Christer From: mmusic > on b= ehalf of Roman Shpount > Date: Thursday 7 September 2017 at 21:10 To: Eric Rescorla > Cc: "mmusic@ietf.org" >, "pkyzivat@alum.mit.edu" > Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts On Thu, Sep 7, 2017 at 10:25 AM, Eric Rescorla > wrote: Well, to recap, ICE restart can only be initiated by the offerer: https://tools.ietf.org/rfcmarkup?doc=3D5245#section-9.2.2 And as we discussed in detail, there's no real way to demux without an ICE = restart, so I'm not interested in trying to preserve that case in the situa= tions when it happens to work. In general, the offerer can simply offer a n= ew tls-id if it's willing to accept a new TLS connection. I appreciate that= this will also cause a TLS association even when the endpoints haven't cha= nged, but this just doesn't seem like that big a deal. If you have a specific case in mind that this causes a problem for, I'd nee= d to see a call-flow diagram to understand it. There are two specific scenarios that concern me: 1. Third Party Call Control a. End point A is connected to end point B through third party call control= agent 3PCC b. 3PCC sends a request for a new offer to A (using SIP INVITE with no SDP = body). c. End point A sends an offer with ICE restart (required in response to INV= ITE with no SDP) and existing tls-id d. 3PCC agent sends this offer as a new call offer to end point C e. This is a new offer for C, so it sends an answer with a new tls-id to 3P= CC f. 3PCC sends an answer to end point A g. Since A got an answer with a new tls-id, a new DTLS association is estab= lished between A and C This also has an optional case, when end point C is legacy and it does not = send back tls-id attribute, but does send new fingerprint values. I would p= refer that new implementations were allowed for the same scenario using tls= -id. Note that in step d, 3PCC can also send the re-offer back to B, which will= result in existing DTLS association reuse. This is very common when sessio= n timers are implemented by 3PCC agents. 2. Connection Recovery a. End point is connected to a service (like conference service) which is c= omprised from multiple redundant media servers behind a single signaling pr= oxy b. End point detects a network connectivity disruption via keep-alive timeo= ut c. End point initiates connection recovery process by generating an offer w= ith ICE restart and existing DTLS association (and media settings) and send= s it to the signaling proxy d. If the network connectivity is restored to the same media server via a d= ifferent network path, for instance due to client address change, existing = DTLS association and media are re-used e. If connectivity failure was due to media server failure, connectivity is= restored but to a different media server. New DTLS association and media = connection is established in this case. Please note that case d is much less common then case e. In both cases it is possible to make things work by forcing new tls-id valu= e in the offer. This will result in extra DTLS association, local ICE candi= date allocations (which are required if new DTLS association is requested v= ia new tls-id), and new media setup. All of those things will waste resourc= es and more importantly will increase connection setup time. Regards, _____________ Roman Shpount --_000_D5DD66072148Echristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7413679EBBB4814F9C283577131A1ABF@ericsson.com> Content-Transfer-Encoding: quoted-printable
OK, how do we move forward? Silence won=92t do it. Can people live wit= h the current text?

(Version =9630 was submitted last week, with the ufrag change removed = from the list in section 4.)

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Roman= Shpount <roman@telurix.com>=
Date: Thursday 7 September 2017 at = 21:10
To: Eric Rescorla <ekr@rtfm.com>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>, "pky= zivat@alum.mit.edu" <p= kyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] DTLS-SDP and = JSEP Conflicts

On Thu, Sep 7, 2017 at 10:25 AM, Eric Rescor= la <ekr@rtfm.com><= /span> wrote:
Well, to recap, ICE restart can only be initiated by the offerer:

And as we discussed in detail, there's no real way to demux without an= ICE restart, so I'm not interested in trying to preserve that case in the = situations when it happens to work. In general, the offerer can simply offe= r a new tls-id if it's willing to accept a new TLS connection. I appreciate that this will also cause a TLS = association even when the endpoints haven't changed, but this just doesn't = seem like that big a deal.

If you have a specific case in mind that this causes a problem for, I'= d need to see a call-flow diagram to understand it.


There are two specific scenarios that concern me:

1. Third Party Call Control

a. End point A is connected to end point B through third party call co= ntrol agent 3PCC
b. 3PCC sends a request for a new offer to A (using SIP INVITE with no= SDP body).
c. End point A sends an offer with ICE restart (required in response t= o INVITE with no SDP) and existing tls-id
d. 3PCC agent sends this offer as a new call offer to end point C
e. This is a new offer for C, so it sends an answer with a new tls-id = to 3PCC
f. 3PCC sends an answer to end point A
g. Since A got an answer with a new tls-id, a new DTLS association is = established between A and C

This also has an optional case, when end point C is legacy and it does= not send back tls-id attribute, but does send new fingerprint values. I wo= uld prefer that new implementations were allowed for the same scenario usin= g tls-id.

Note that in step d, 3PCC can also send the  re-offer back to B, = which will result in existing DTLS association reuse. This is very common w= hen session timers are implemented by 3PCC agents.

2. Connection Recovery

a. End point is connected to a service (like conference service) which= is comprised from multiple redundant media servers behind a single signali= ng proxy
b. End point detects a network connectivity disruption via keep-alive = timeout
c. End point initiates connection recovery process by generating an of= fer with ICE restart and existing DTLS association (and media settings) and= sends it to the signaling proxy
d. If the network connectivity is restored to the same media server vi= a a different network path, for instance due to client address change, exis= ting DTLS association and media are re-used 
e. If connectivity failure was due to media server failure, connectivi= ty is restored but to a different media server. New DTLS  associa= tion and media connection is established in this case.

Please note that case d is much less common then case e.

In both cases it is possible to make things work by forcing new tls-id= value in the offer. This will result in extra DTLS association, local ICE = candidate allocations (which are required if new DTLS association is reques= ted via new tls-id), and new media setup. All of those things will waste resources and more importantly will = increase connection setup time.

Regards,
_____________
Roman Shpount
 
--_000_D5DD66072148Echristerholmbergericssoncom_-- From nobody Tue Sep 12 02:19:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAF5133021 for ; Tue, 12 Sep 2017 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUArkQxCDA5I for ; Tue, 12 Sep 2017 02:19:21 -0700 (PDT) Received: from know-smtprelay-omc-8.server.virginmedia.net (know-smtprelay-omc-8.server.virginmedia.net [80.0.253.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2873C133011 for ; Tue, 12 Sep 2017 02:19:20 -0700 (PDT) Received: from [192.168.0.10] ([81.97.229.170]) by know-smtprelay-8-imp with bizsmtp id 8ZKH1w00F3hDt9d01ZKJzH; Tue, 12 Sep 2017 10:19:18 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.1 cv=APW+KdU1 c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=x7bEGLp0ZPQA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=Nv--wQFjAAAA:8 a=48vgC7mUAAAA:8 a=vQ6dKL7GAAAA:8 a=A031uJZ7spyYwg6BhfoA:9 a=QEXdDO2ut3YA:10 a=8qpqNnEzile1kdqBD-gA:9 a=sqsceN9cjB04ZYjM:21 a=_W_S_7VecoQA:10 a=NZEjkz1c1RZEYMvUJ3LL:22 a=w1C3t2QeGrPiZgrLijVG:22 a=mJ0ar-z9p3RXkz0ikL7Z:22 To: mmusic@ietf.org References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> From: Keith Drage Message-ID: Date: Tue, 12 Sep 2017 10:19:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B9FD5EBDB94376C3DD3BF4F6" Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1505207958; bh=RYDXuZ5IIQ1685NiqVQ0+6G6WtYGWFAPG8uCFDk+csk=; h=Subject:To:References:From:Date:In-Reply-To; b=lE/Asa94VRwiAeonalvO3lpCyFG16OtZaOglDF78J+MJ3kUiG6o5sZpzN2aZBchzU W6I54w/TntL3JBFJRHGhyOCxyWsRFZQxgsVBqxfCGZ/jhuF8JI+H0q3YmwSvp1aAoB mhjfanL+d9LUPDDc3Q2jcicQ+yyoa0ZUVPWbG6jZKsRZArDTlLSsMLjs8dfFLSp/j0 07GwmpukO1v/eM0u7/9Nn4moumsm1ZDTWmv57awvXykQyUx1zY+W3WUqCbNrNjyT3l sQOkFPDfJDSsyPxsapdLGMWnYx30gA7wSh1L77MTQvNDTIyqz9kPR9PhjqAjmqMoKA qff9qJVRxWbAw== Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 09:19:24 -0000 This is a multi-part message in MIME format. --------------B9FD5EBDB94376C3DD3BF4F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yes, we do not want people to use it. It was regarded as an inappropriate inadequately defined security mechanism when it existed. But I agree with Colin in that straight removal is nor the answer. Among other things, we need to consider what we want to appear in the IANA lists in order to ensure that the name is not reused. Is that different from what appears now? Keith On 08-Sep-17 11:24 AM, Colin Perkins wrote: > I don’t think we can remove it – we need to document it for legacy > reasons, if nothing else – but we can certainly strengthen the > warnings not to use it. > > Colin > > > >> On 8 Sep 2017, at 08:14, Ali C. Begen > > wrote: >> >> I have not seen it being used, but it could be just me who has not >> seen it. Will be happy to remove it, if everyone agrees. >> >> On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings > > wrote: >> >> Do we still need the "k=" line in SDP? Could we just remove all >> of section 5.12 ? >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------B9FD5EBDB94376C3DD3BF4F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Yes, we do not want people to use it. It was regarded as an inappropriate inadequately defined security mechanism when it existed.

But I agree with Colin in that straight removal is nor the answer. Among other things, we need to consider what we want to appear in the IANA lists in order to ensure that the name is not reused. Is that different from what appears now?

Keith

On 08-Sep-17 11:24 AM, Colin Perkins wrote:
I don’t think we can remove it – we need to document it for legacy reasons, if nothing else – but we can certainly strengthen the warnings not to use it.

Colin



On 8 Sep 2017, at 08:14, Ali C. Begen <ali.begen@networked.media> wrote:

I have not seen it being used, but it could be just me who has not seen it. Will be happy to remove it, if everyone agrees.

On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings <fluffy@iii.ca> wrote:
Do we still need the "k=" line in SDP? Could we just remove all of section 5.12 ?


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

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



-- 
Colin Perkins
https://csperkins.org/






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


--------------B9FD5EBDB94376C3DD3BF4F6-- From nobody Tue Sep 12 05:54:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772EE132153 for ; Tue, 12 Sep 2017 05:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-NSql6I7Nkh for ; Tue, 12 Sep 2017 05:54:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2828613208E for ; Tue, 12 Sep 2017 05:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13417; q=dns/txt; s=iport; t=1505220847; x=1506430447; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=fslhSPv9irCZod11m88Mhez3YBFv6QjNJQFolA4DN+w=; b=Hsq+hw3hWpUWbPyAM+htT4Nmd0yKjCZqTFP7fAm8QW9adz9N1YxReeIq 5HXAK8mE/9boGYvVzbrlWShksoUKQInBpCIqrfm6CSMFnKVRxW+We6v4Q 8qVjZdm70VZ9eEJ4VLLkpgpuYJgtXRoiLqnxqZ+jSt8PLE5DLwFCGaYTG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgAJ2LdZ/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnBrZG4ng3eKIZAjgUkrkGqFP4EzA1wKGAEKhExPAoQ8PxgBAgE?= =?us-ascii?q?BAQEBAQFrKIUYAQEBBAEBIQpBBhULEQQBAQEnAwICJx8JCAYBDAYCAQGKIA0Qq?= =?us-ascii?q?w2CJyeLDAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyuCAoFQgg6CSDWFLYJdgmE?= =?us-ascii?q?Fin6Vd4dbjHeLVYcdlS2BOR84QQ0/UyQVSoUYHIIDJDYBigwBAQE?= X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="scan'208,217";a="297362533" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Sep 2017 12:54:06 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8CCs562021011; Tue, 12 Sep 2017 12:54:05 GMT To: Christer Holmberg , Taylor Brandstetter , mmusic WG References: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> From: Flemming Andreasen Message-ID: Date: Tue, 12 Sep 2017 08:53:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> Content-Type: multipart/alternative; boundary="------------7501C8C7DCEBBF482DC96514" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 12:54:09 -0000 This is a multi-part message in MIME format. --------------7501C8C7DCEBBF482DC96514 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit We need more list discussion and inputs to consider making such a change. Thanks -- Flemming & Bo (MMUSIC chairs) On 8/5/17 1:52 PM, Christer Holmberg wrote: > > Hi, > > Nothing prevents us from doing changes to a draft, even if it’s > already in the RFC editor’s queue. The question is whether we consider > the change essential enough at that stage. > > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Taylor > Brandstetter > *Sent:* 27 July 2017 02:23 > *To:* mmusic WG > *Subject:* Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with > WebRTC 1.0 > > Ping. Harald (the author of this document) is on sabbatical, so I'd > appreciate some guidance from someone else familiar with IETF > processes. It's already in the RFC editor queue, which seems like a > problem. > > On Thu, Jul 20, 2017 at 6:41 PM, Taylor Brandstetter > > wrote: > > In the current state of WebRTC 1.0, track IDs are not guaranteed > to be symmetrical between the sending and receiving > PeerConnection. This is because "addTrack" not only creates an > RtpSender, but a whole RtpTransceiver, which has an RtpReceiver, > which has a MediaStreamTrack with a generated ID. So if "addTrack" > is called, and a remote description is set later, it's the MID > that correlates the "m=" section with the track, not the track ID, > and the track ID in SDP is effectively ignored. > > This is all related to the "early media" functionality, and is > explained further in a blog post by Jan-Ivar; see the "Correlate > by transceiver.mid" section: > https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/ > > So, the question became "why signal track IDs at all?" This was > brought up in a May virtual interim > (https://www.w3.org/2011/04/webrtc/wiki/May_2_2017), and we > decided to investigate removing them. To my knowledge this topic > hasn't been brought up on this mailing list yet. > > Is this something still worth considering, or is it too late? > "a=msid" would switch to only containing the stream ID, not the > track ID. Implementers would presumably have a transitional period > where they support parsing both forms of "a=msid", after which > they start generating the new format, as we've done for other things. > > The benefits are that the SDP would be slightly smaller, and the > complexity of the standards could be slightly reduced. The > downside is that more applications that rely on track IDs would > need to be updated (though many will need to be updated anyway). > > Regardless of the outcome of this decision, "mmusic-msid" really > ought to be updated before publication. It's been out of sync with > WebRTC 1.0 for about a year; here's the first editor's draft that > broke the track ID symmetry: > https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------7501C8C7DCEBBF482DC96514 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit We need more list discussion and inputs to consider making such a change.

Thanks

-- Flemming & Bo (MMUSIC chairs)


On 8/5/17 1:52 PM, Christer Holmberg wrote:

Hi,

 

Nothing prevents us from doing changes to a draft, even if it’s already in the RFC editor’s queue. The question is whether we consider the change essential enough at that stage.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Taylor Brandstetter
Sent: 27 July 2017 02:23
To: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0

 

Ping. Harald (the author of this document) is on sabbatical, so I'd appreciate some guidance from someone else familiar with IETF processes. It's already in the RFC editor queue, which seems like a problem.

 

On Thu, Jul 20, 2017 at 6:41 PM, Taylor Brandstetter <deadbeef@google.com> wrote:

In the current state of WebRTC 1.0, track IDs are not guaranteed to be symmetrical between the sending and receiving PeerConnection. This is because "addTrack" not only creates an RtpSender, but a whole RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with a generated ID. So if "addTrack" is called, and a remote description is set later, it's the MID that correlates the "m=" section with the track, not the track ID, and the track ID in SDP is effectively ignored.

 

This is all related to the "early media" functionality, and is explained further in a blog post by Jan-Ivar; see the "Correlate by transceiver.mid" section: https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

 

So, the question became "why signal track IDs at all?" This was brought up in a May virtual interim (https://www.w3.org/2011/04/webrtc/wiki/May_2_2017), and we decided to investigate removing them. To my knowledge this topic hasn't been brought up on this mailing list yet.

 

Is this something still worth considering, or is it too late? "a=msid" would switch to only containing the stream ID, not the track ID. Implementers would presumably have a transitional period where they support parsing both forms of "a=msid", after which they start generating the new format, as we've done for other things.

 

The benefits are that the SDP would be slightly smaller, and the complexity of the standards could be slightly reduced. The downside is that more applications that rely on track IDs would need to be updated (though many will need to be updated anyway).

 

Regardless of the outcome of this decision, "mmusic-msid" really ought to be updated before publication. It's been out of sync with WebRTC 1.0 for about a year; here's the first editor's draft that broke the track ID symmetry: https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html

 



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

--------------7501C8C7DCEBBF482DC96514-- From nobody Tue Sep 12 06:21:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392FF132FA7 for ; Tue, 12 Sep 2017 06:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.622 X-Spam-Level: X-Spam-Status: No, score=-12.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hbaRUrrKNIE for ; Tue, 12 Sep 2017 06:21:23 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172761321C7 for ; Tue, 12 Sep 2017 06:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=383; q=dns/txt; s=iport; t=1505222483; x=1506432083; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=JDFy7VwxHpKYe83HRV9y1w1zDieU+K9g/9E6gYmZFP4=; b=HUqrmsvsDfBaYmk7QkY0rfikVABf8Ide8pOmvN9yUhspVFbPz91x+dHK n9qTmA1T56qcfDdZ4/M0fz0xbybOnjdNNOwWsOsVadEjqHafnzTmi7VFF 7ZzpJpca2Z3e2pKt3Vf82cRAQ/hnqi4xTVqK27mms3FhbiNGxNtQfa2Zk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcCgAk37dZ/5ldJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1uBUoQemkSBSQmON4UwhHUKhTWESFcBAgEBAQEBAmsohUIVdgImAl8NCAE?= =?us-ascii?q?BiiANqyuCJ4szAQEBAQYCASWBDoIdggKBUIIOC4Quhk6CYQEEoHSOAoZQgXsBF?= =?us-ascii?q?4Vog1qHHZUvgTlXgQ1TJBWFboITJIo/AQEB?= X-IronPort-AV: E=Sophos;i="5.42,383,1500940800"; d="scan'208";a="2351442" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 13:21:20 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8CDLJdA005423 for ; Tue, 12 Sep 2017 13:21:20 GMT To: mmusic From: Flemming Andreasen Message-ID: <1ea73f9d-2493-01dc-07ab-448fe19f15e4@cisco.com> Date: Tue, 12 Sep 2017 09:21:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MMUSIC] MMUSIC meet at IETF 100 (Singapore) ? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:21:24 -0000 Greetings Requests for WGs to meet at IETF 100 (Singapore) are due by September 29 and hence we wanted to prod the group at this point to see if anybody expects a need for MMUSIC to meet in Singapore. If you do, please let the chairs know sooner rather than later. If we do not hear from anybody, we do not expect to ask for a meeting slot. Thanks -- Flemming & Bo From nobody Tue Sep 12 06:53:00 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE8B13305E for ; Tue, 12 Sep 2017 06:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CYRl7H5WkTK7 for ; Tue, 12 Sep 2017 06:52:57 -0700 (PDT) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 5ED0713305D for ; Tue, 12 Sep 2017 06:52:57 -0700 (PDT) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EC04424F06; Tue, 12 Sep 2017 09:52:53 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 86FB224E33; Tue, 12 Sep 2017 09:52:53 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 12 Sep 2017 09:52:53 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> Date: Tue, 12 Sep 2017 07:52:52 -0600 Cc: Taylor Brandstetter , mmusic WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 13:52:58 -0000 >=20 > In the current state of WebRTC 1.0, track IDs are not guaranteed to be = symmetrical between the sending and receiving PeerConnection. This is = because "addTrack" not only creates an RtpSender, but a whole = RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack = with a generated ID. So if "addTrack" is called, and a remote = description is set later, it's the MID that correlates the "m=3D" = section with the track, not the track ID, and the track ID in SDP is = effectively ignored. I'm not following the problem here ... yes, webrtc ends up with the = track from A to B and B to A having different track IDs but the msid = draft clearly allows the offer and answer to have different app data in = the MSID line. What's the issue on this? PS - As side note, I've argued since before 2013 that we did not need to = signal track ID in SDP but I think that train left the station long ago = and I'd rather not change it at this point. The mostly compelling = argument I recall on why we need this was hangouts uses it.=20 From nobody Tue Sep 12 07:03:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6051326DF for ; Tue, 12 Sep 2017 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 aLFUftMj_Co9 for ; Tue, 12 Sep 2017 07:03:15 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 988B8132716 for ; Tue, 12 Sep 2017 07:03:15 -0700 (PDT) Received: from smtp17.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C9E05260F7; Tue, 12 Sep 2017 10:03:12 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp17.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7302726178; Tue, 12 Sep 2017 10:03:12 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 12 Sep 2017 10:03:12 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Tue, 12 Sep 2017 08:03:11 -0600 Cc: mmusic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> To: Keith Drage X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:03:18 -0000 First, I don't feel strongly about this and glad to go with whatever = Colin wants ... but what I was thinking .... k=3D is still defined by RFC4566 and things that implement RFC4566 still = use it. I don't think we have an IANA table for this but if we do, the = IANA registry still lists it with the reference for it as RFC4566.=20 This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k=3D = one way or another. If something that implements RFCAAAA receives a k=3D = line, it gets treated just like any other unknown line and is ignored.=20= There not enough advice on how to use the k=3D stuff to expect = interoperable implementation of any type of security that the IETF would = currently consider acceptable to publish as a standard. Anyone who uses = k=3D is very unlikely to be upgrading their software to RFCAAAA. I just = don't see anything good that comes of putting this in the new RFC and it = just adds to the confusion of how to secure RTP.=20 > On Sep 12, 2017, at 3:19 AM, Keith Drage wrote: >=20 > Yes, we do not want people to use it. It was regarded as an = inappropriate inadequately defined security mechanism when it existed. >=20 > But I agree with Colin in that straight removal is nor the answer. = Among other things, we need to consider what we want to appear in the = IANA lists in order to ensure that the name is not reused. Is that = different from what appears now? >=20 > Keith >=20 > On 08-Sep-17 11:24 AM, Colin Perkins wrote: >> I don=E2=80=99t think we can remove it =E2=80=93 we need to document = it for legacy reasons, if nothing else =E2=80=93 but we can certainly = strengthen the warnings not to use it. >>=20 >> Colin >>=20 >>=20 >>=20 >>> On 8 Sep 2017, at 08:14, Ali C. Begen = wrote: >>>=20 >>> I have not seen it being used, but it could be just me who has not = seen it. Will be happy to remove it, if everyone agrees. >>>=20 >>> On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings = wrote: >>> Do we still need the "k=3D" line in SDP? Could we just remove all of = section 5.12 ? >>>=20 >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >>=20 >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Sep 12 08:42:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B171321B6 for ; Tue, 12 Sep 2017 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RdeefPPBM0H7 for ; Tue, 12 Sep 2017 08:42:36 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8AB1320D9 for ; Tue, 12 Sep 2017 08:42:36 -0700 (PDT) X-AuditID: 12074411-f95ff70000007f0a-07-59b8006ab617 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id AD.05.32522.A6008B95; Tue, 12 Sep 2017 11:42:34 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8CFgX7s018713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 12 Sep 2017 11:42:34 -0400 To: mmusic@ietf.org References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> From: Paul Kyzivat Message-ID: <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> Date: Tue, 12 Sep 2017 11:42:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixO6iqJvFsCPSYOklSYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoErY8WaioLjkhUNW86yNzDeFeli5OSQEDCRuHvrBROILSSwg0ni 3zHBLkYuIPs7k8S8nUuYQRLCApYSkxcfBisSERCWmPH2LxtE0Vwmid4ZF1hAEmwCWhJzDv0H s3kF7CVeT30IZrMIqEosbf3JCmKLCqRJ/Nt9lhGiRlDi5MwnYDWcAlYSHfdPgtUwC5hJzNv8 kBnCFpe49WQ+E4QtL9G8dTbzBEb+WUjaZyFpmYWkZRaSlgWMLKsY5RJzSnN1cxMzc4pTk3WL kxPz8lKLdE31cjNL9FJTSjcxQoJScAfjjJNyhxgFOBiVeHhX3NkeKcSaWFZcmXuIUZKDSUmU V/k+UIgvKT+lMiOxOCO+qDQntfgQowQHs5II74lHQDnelMTKqtSifJiUNAeLkjgv3xJ1PyGB 9MSS1OzU1ILUIpisDAeHkgTvu39AjYJFqempFWmZOSUIaSYOTpDhPEDDbf6DDC8uSMwtzkyH yJ9i1OXo6bnxh0mIJS8/L1VKnFccZJAASFFGaR7cHFgyecUoDvSWMK85yCgeYCKCm/QKaAkT 0BKeS1tAlpQkIqSkGhjXxRfti23i75JdU9Dt9TI6cO4P7prw0JiOR1UKf7tlut7atk8WYLvP f/pwEt/KvuvvQvlf6E07tSfxrOjd8j0/ue96OAqK+f515lI/tmOlu/Gyw1/kpt4wW3bkxMVv Sz4zt7nZzfuh93/m9ldLtGXn218qlfT4YrZ7RWjCg/87FzpFxFx+uzNKiaU4I9FQi7moOBEA NlJFkgEDAAA= Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 15:42:38 -0000 On 9/12/17 10:03 AM, Cullen Jennings wrote: > First, I don't feel strongly about this and glad to go with whatever Colin wants ... but what I was thinking .... > > > k= is still defined by RFC4566 and things that implement RFC4566 still use it. I don't think we have an IANA table for this but if we do, the IANA registry still lists it with the reference for it as RFC4566. > > This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k= one way or another. If something that implements RFCAAAA receives a k= line, it gets treated just like any other unknown line and is ignored. > > There not enough advice on how to use the k= stuff to expect interoperable implementation of any type of security that the IETF would currently consider acceptable to publish as a standard. Anyone who uses k= is very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of putting this in the new RFC and it just adds to the confusion of how to secure RTP. One thing: if all mention of k= is removed from the bis, then in the (far) someone who is defining a new line might choose k= for it. (Admittedly this is pretty far fetched.) I think a cleaner way to handle this would be to deprecate k= in the bis. Thanks, Paul >> On Sep 12, 2017, at 3:19 AM, Keith Drage wrote: >> >> Yes, we do not want people to use it. It was regarded as an inappropriate inadequately defined security mechanism when it existed. >> >> But I agree with Colin in that straight removal is nor the answer. Among other things, we need to consider what we want to appear in the IANA lists in order to ensure that the name is not reused. Is that different from what appears now? >> >> Keith >> >> On 08-Sep-17 11:24 AM, Colin Perkins wrote: >>> I don’t think we can remove it – we need to document it for legacy reasons, if nothing else – but we can certainly strengthen the warnings not to use it. >>> >>> Colin >>> >>> >>> >>>> On 8 Sep 2017, at 08:14, Ali C. Begen wrote: >>>> >>>> I have not seen it being used, but it could be just me who has not seen it. Will be happy to remove it, if everyone agrees. >>>> >>>> On Fri, Sep 8, 2017 at 2:26 AM, Cullen Jennings wrote: >>>> Do we still need the "k=" line in SDP? Could we just remove all of section 5.12 ? >>>> >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Sep 12 08:49:08 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E825E1323B4 for ; Tue, 12 Sep 2017 08:49:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150523134694.17940.5562222691528256566.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 08:49:06 -0700 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 15:49:07 -0000 Changed milestone "Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Informational", added draft-ietf-mmusic-sdp-uks to milestone. URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Tue Sep 12 11:30:52 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031B3132ED1 for ; Tue, 12 Sep 2017 11:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go0vh4a64fIr for ; Tue, 12 Sep 2017 11:30:49 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A18126B6D for ; Tue, 12 Sep 2017 11:30:49 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i189so1469458wmf.1 for ; Tue, 12 Sep 2017 11:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PRu9ox2RUeDtP3biyQ6UA3s7VP562XmvsB4Ta+f1YT4=; b=qMVh+OrwX0Qu8+VKmQnXPnjEYmoowmiQYvT7QbJzJLCyJyCaoAG1NOo/TCdkM2ekTQ M+EXKvVkpg/Cz83ip92U0o6XNOYMK6AyEqR42la74lcbkPgRErba51C+8nE4lgzLVnAh OgTFLoVc3G2PcF+FWmxP82XLyXSOU9o/np9V1L+PpfM56mhMszYEhhZwurtxMgQs8YwO v9ISDHhzAqyttIwmpej065ja2ceyfivKfwexoDXhJK2VNzbTF/IcpnDbpwcy7yb97UoX g13gAb+F0CDA+qbsN3P0yK8hQjmg7Gtf/zivAcUsGGIh1LZsPckjSOvJdy7F5c8JgCDg c3ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PRu9ox2RUeDtP3biyQ6UA3s7VP562XmvsB4Ta+f1YT4=; b=Uztb6Zv/Rqk8DCiUe8IedXkPnptzjqPqx3+IFGqWAkq4YUGKwYV4EfvRMXMnnJARCm upvSXC2YVu2z29GUZv/SlVoJNzQ2l9uCzApsFql2rUo7mYGpQ/Dd6G9N1PenbOAn7gzp kE/xojvqMmcO6KzQjLTIqtMxXcGquZ2ITsJysGrL/ect0fJY6GpbnGxxii/zw86UcNfb mhLIKYSJT4fVsRzLyFahaYyiMkN09kKiSfZZ4+O+8D7YXWJxKXfYkgHSczc91hsBljhr zHqQcmFENdnA7GgFojvNVdUGX2OHkdx3QkZXQsPwu384zfXt3CuzR6fYp7CvM3hh3g3U r4HA== X-Gm-Message-State: AHPjjUgYClLviphKFOg+cx7xJ+aUOU2NYKlaFdig6RcE5pJ62gt5tOAK TcnsXKF9PXlJuzoWtahAd6dQUC60y+TA X-Google-Smtp-Source: AOwi7QCpkFJJnyCotO+7vACPbfJmL3phhqxdKOdtHCe41L90nlZgIZZ52xysso7yHZMMQtPpFSQLWzAYhwSdlKT3XS8= X-Received: by 10.28.145.11 with SMTP id t11mr355623wmd.66.1505241047142; Tue, 12 Sep 2017 11:30:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.54 with HTTP; Tue, 12 Sep 2017 11:30:46 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> From: Taylor Brandstetter Date: Tue, 12 Sep 2017 11:30:46 -0700 Message-ID: To: Cullen Jennings Cc: Christer Holmberg , mmusic WG Content-Type: multipart/alternative; boundary="001a1146a0f6eb2eb40559023d7a" Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:30:51 -0000 --001a1146a0f6eb2eb40559023d7a Content-Type: text/plain; charset="UTF-8" > > yes, webrtc ends up with the track from A to B and B to A having different > track IDs That's not what I'm talking about. I'm talking about the track ID in the remote description not matching the ID of the remote MediaStreamTrack. Maybe a detailed example will make this more clear: 1. Endpoint A ("Alice") creates PeerConnection, adds track to it. Suppose this track's ID is "trackA". 2. RTCRtpTransceiver is created, along with an RTCRtpReceiver that has a track with a randomly generated ID. Let's call it "generatedA". 3. Endpoint B ("Bob") does the same thing; suppose they added a track with ID "trackB", and a remote track was created with ID "generatedB". 4. Alice creates offer, signals to Bob. 5. Bob applies remote description. The SDP contains "a=msid:streamA trackA", but Bob's remote track ("generatedB") already exists. So it just gets added to a stream, and the ID "trackA" gets ignored. 6. Bob creates answer, signals to Alice. 7. Same thing. The SDP contains "a=msid:streamB trackB", but the track ("generatedA") already exists and the ID "trackB" is ignored. The MSID draft clearly doesn't align with this. It assumes a track is always created when a new track ID is seen in SDP. On Tue, Sep 12, 2017 at 6:52 AM, Cullen Jennings wrote: > > > > In the current state of WebRTC 1.0, track IDs are not guaranteed to be > symmetrical between the sending and receiving PeerConnection. This is > because "addTrack" not only creates an RtpSender, but a whole > RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with > a generated ID. So if "addTrack" is called, and a remote description is set > later, it's the MID that correlates the "m=" section with the track, not > the track ID, and the track ID in SDP is effectively ignored. > > I'm not following the problem here ... yes, webrtc ends up with the track > from A to B and B to A having different track IDs but the msid draft > clearly allows the offer and answer to have different app data in the MSID > line. What's the issue on this? > > > PS - As side note, I've argued since before 2013 that we did not need to > signal track ID in SDP but I think that train left the station long ago and > I'd rather not change it at this point. The mostly compelling argument I > recall on why we need this was hangouts uses it. > > > --001a1146a0f6eb2eb40559023d7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes, webrtc ends up with the track from A to B and= B to A having different track IDs

T= hat's not what I'm talking about. I'm talking about the track I= D in the remote description not matching the ID of the remote MediaStreamTr= ack.

Maybe a detailed example will make this more = clear:
  1. Endpoint A ("Alice") creates PeerConnect= ion, adds track to it. Suppose this track's ID is "trackA".
  2. RTCRtpTransceiver is created, along with an RTCRtpReceiver that has = a track with a randomly generated ID. Let's call it "generatedA&qu= ot;.
  3. Endpoint B ("Bob") does the same thing; suppose they= added a track with ID "trackB", and a remote track was created w= ith ID "generatedB".
  4. Alice creates offer, signals to Bob.=
  5. Bob applies remote description. The SDP contains "a=3Dmsid:st= reamA trackA", but Bob's remote track ("generatedB") alr= eady exists. So it just gets added to a stream, and the ID "trackA&quo= t; gets ignored.
  6. Bob creates answer, signals to Alice.
  7. Same= thing. The SDP contains "a=3Dmsid:streamB trackB", but the track= ("generatedA") already exists and the ID "trackB" is i= gnored.
The MSID draft clearly doesn't align with this. I= t assumes a track is always created when a new track ID is seen in SDP.
=C2=A0

On Tue, Sep 12, 2017 at 6:52 AM, Cullen Jennings <fluffy@iii.ca<= /a>> wrote:
&g= t;
> In the current state of WebRTC 1.0, track IDs are not guaranteed to be= symmetrical between the sending and receiving PeerConnection. This is beca= use "addTrack" not only creates an RtpSender, but a whole RtpTran= sceiver, which has an RtpReceiver, which has a MediaStreamTrack with a gene= rated ID. So if "addTrack" is called, and a remote description is= set later, it's the MID that correlates the "m=3D" section w= ith the track, not the track ID, and the track ID in SDP is effectively ign= ored.

I'm not following the problem here ... yes, webrtc ends up with = the track from A to B and B to A having different track IDs but the msid dr= aft clearly allows the offer and answer to have different app data in the M= SID line. What's the issue on this?


PS - As side note, I've argued since before 2013 that we did not need t= o signal track ID in SDP but I think that train left the station long ago a= nd I'd rather not change it at this point. The mostly compelling argume= nt I recall on why we need this was hangouts uses it.



--001a1146a0f6eb2eb40559023d7a-- From nobody Tue Sep 12 14:33:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4958133149 for ; Tue, 12 Sep 2017 14:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 p4itGtgEA4cz for ; Tue, 12 Sep 2017 14:33:01 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4298213247A for ; Tue, 12 Sep 2017 14:33:01 -0700 (PDT) Received: from [81.187.2.149] (port=44934 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1drsnj-00019x-Hh; Tue, 12 Sep 2017 22:32:59 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> Date: Tue, 12 Sep 2017 22:32:56 +0100 Cc: mmusic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 21:33:03 -0000 > On 12 Sep 2017, at 16:42, Paul Kyzivat wrote: >=20 > On 9/12/17 10:03 AM, Cullen Jennings wrote: >> First, I don't feel strongly about this and glad to go with whatever = Colin wants ... but what I was thinking .... >> k=3D is still defined by RFC4566 and things that implement RFC4566 = still use it. I don't think we have an IANA table for this but if we do, = the IANA registry still lists it with the reference for it as RFC4566. >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k=3D = one way or another. If something that implements RFCAAAA receives a k=3D = line, it gets treated just like any other unknown line and is ignored. >> There not enough advice on how to use the k=3D stuff to expect = interoperable implementation of any type of security that the IETF would = currently consider acceptable to publish as a standard. Anyone who uses = k=3D is very unlikely to be upgrading their software to RFCAAAA. I just = don't see anything good that comes of putting this in the new RFC and it = just adds to the confusion of how to secure RTP. >=20 > One thing: if all mention of k=3D is removed from the bis, then in the = (far) someone who is defining a new line might choose k=3D for it. = (Admittedly this is pretty far fetched.) >=20 > I think a cleaner way to handle this would be to deprecate k=3D in the = bis. I=E2=80=99d not object if the text in 4566bis was changed to: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.12. Encryption Keys ("k=3D") k=3D k=3D: The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. 5.13. Attributes (=E2=80=9Ca=3D=E2=80=9C) =E2=80=A6 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =E2=80=A6or something similar. I just don=E2=80=99t think we can remove = it entirely. --=20 Colin Perkins https://csperkins.org/ From nobody Tue Sep 12 15:34:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E274133169 for ; Tue, 12 Sep 2017 15:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF8h5l7TUSqB for ; Tue, 12 Sep 2017 15:34:06 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46B4133164 for ; Tue, 12 Sep 2017 15:34:05 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id z73so33112378oia.2 for ; Tue, 12 Sep 2017 15:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8U8YlFcuVMtLqRSnuNUWPKY73ABYMNG6h9VI1Lj8T8s=; b=WqNoz8lhmy6qGoZqKOcPVVXZNzGviA1ZgBzmQQP6orli07uClFwEyArZP2uEoDM5nN ctI92d2zLDyNpwOYtjSp0JhyP1Z4V/D67oXsIaYJd85DFqRnXs1fVS4TPF3FRBbPKFko CQfRrvl79Lu6w8gSbHFUlX6JUqS+4ztqtqb+voToadoEF5KW3sRAdcG93cn4RNffRd2J BeN3UpPLPNyB7b71bsi1nbSBDV9xf1oQQ7XuiztSEfb8pj56NMmNPqnyPI4eH5A3CC8j xsVZRJidowLcI7bPz5gSHbjBOc7nTCZORPsgzn15CksmxnUC1bi4SdmhNGlXt8UOI60a YW4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8U8YlFcuVMtLqRSnuNUWPKY73ABYMNG6h9VI1Lj8T8s=; b=QGkG/9XRc1rJRerTm2edUId1kR6sBXy5q97HxydxeCErxMQrKGijmJ8IzhQXX6GEY0 aoW0PyM9a8lNkStho/zYLLpBI6lBeRZLXmuV7U2Ta3GL39v6JTtI4ilEKnC7G+CFQott zvrXl5KkMen7ty4YnzZJ7JqgAsAGKi7e8qDU53BUuzWZiEegKvBO6MD7e5664SMJX+Yt QwSM3B2C+HusrmZ7yyvqISL+99N/kUvsWJusytwW/a7NAXmq6zDx58fB5LZLW+vJ2Pb7 8CBAuT3ESBjGVuhA19lhJjiPEXD/Hg6XAK47aT4H4+gvpHxbB3E5jyqbLF+lNehkv7em jQqw== X-Gm-Message-State: AHPjjUhHP8UOQSUZzgEJ1Bs8uEid6ZnolOCRgfVOsYd9iKf4Rk1Sxjf6 8AnbujvxF7/RvI4V9wNSlK1EaBH7Dsse X-Google-Smtp-Source: AOwi7QCSghfN3wVYmy5KAJeSd+eJ3bEqYRMYnrzoCsJFnnSOFNvZo2PYabuOpvJYZmjK4oXfZEuh5rPAuWAwns88A8Q= X-Received: by 10.202.224.130 with SMTP id x124mr15428755oig.100.1505255645267; Tue, 12 Sep 2017 15:34:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.10.71 with HTTP; Tue, 12 Sep 2017 15:33:24 -0700 (PDT) In-Reply-To: References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> From: Eric Rescorla Date: Tue, 12 Sep 2017 15:33:24 -0700 Message-ID: To: Colin Perkins Cc: Paul Kyzivat , mmusic WG Content-Type: multipart/alternative; boundary="001a113d376a085f10055905a4e4" Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 22:34:08 -0000 --001a113d376a085f10055905a4e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This seems like a fine resolution to me. On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins wrote: > > > On 12 Sep 2017, at 16:42, Paul Kyzivat wrote: > > > > On 9/12/17 10:03 AM, Cullen Jennings wrote: > >> First, I don't feel strongly about this and glad to go with whatever > Colin wants ... but what I was thinking .... > >> k=3D is still defined by RFC4566 and things that implement RFC4566 sti= ll > use it. I don't think we have an IANA table for this but if we do, the IA= NA > registry still lists it with the reference for it as RFC4566. > >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k=3D > one way or another. If something that implements RFCAAAA receives a k=3D > line, it gets treated just like any other unknown line and is ignored. > >> There not enough advice on how to use the k=3D stuff to expect > interoperable implementation of any type of security that the IETF would > currently consider acceptable to publish as a standard. Anyone who uses k= =3D > is very unlikely to be upgrading their software to RFCAAAA. I just don't > see anything good that comes of putting this in the new RFC and it just > adds to the confusion of how to secure RTP. > > > > One thing: if all mention of k=3D is removed from the bis, then in the > (far) someone who is defining a new line might choose k=3D for it. > (Admittedly this is pretty far fetched.) > > > > I think a cleaner way to handle this would be to deprecate k=3D in the = bis. > > I=E2=80=99d not object if the text in 4566bis was changed to: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5.12. Encryption Keys ("k=3D") > > k=3D > k=3D: > > > The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. > > 5.13. Attributes (=E2=80=9Ca=3D=E2=80=9C) > =E2=80=A6 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =E2=80=A6or something similar. I just don=E2=80=99t think we can remove i= t entirely. > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113d376a085f10055905a4e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems like a fine resolution to me.

On Tue, Sep 12, 2017 at 2:3= 2 PM, Colin Perkins <csp@csperkins.org> wrote:

> On 12 Sep 2017, at 16:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
> On 9/12/17 10:03 AM, Cullen Jennings wrote:
>> First, I don't feel strongly about this and glad to go with wh= atever Colin wants ... but what I was thinking ....
>> k=3D is still defined by RFC4566 and things that implement RFC4566= still use it. I don't think we have an IANA table for this but if we d= o, the IANA registry still lists it with the reference for it as RFC4566. >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention = k=3D one way or another. If something that implements RFCAAAA receives a k= =3D line, it gets treated just like any other unknown line and is ignored.<= br> >> There not enough advice on how to use the k=3D stuff to expect int= eroperable implementation of any type of security that the IETF would curre= ntly consider acceptable to publish as a standard. Anyone who uses k=3D is = very unlikely to be upgrading their software to RFCAAAA. I just don't s= ee anything good that comes of putting this in the new RFC and it just adds= to the confusion of how to secure RTP.
>
> One thing: if all mention of k=3D is removed from the bis, then in the= (far) someone who is defining a new line might choose k=3D for it. (Admitt= edly this is pretty far fetched.)
>
> I think a cleaner way to handle this would be to deprecate k=3D in the= bis.

I=E2=80=99d not object if the text in 4566bis was changed to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.12.=C2=A0 Encryption Keys ("k=3D")

=C2=A0 =C2=A0 =C2=A0 k=3D<method>
=C2=A0 =C2=A0 =C2=A0 k=3D<method>:<encryption key>


=C2=A0 The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used.
5.13.=C2=A0 Attributes (=E2=80=9Ca=3D=E2=80=9C)
=E2=80=A6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=E2=80=A6or something similar. I just don=E2=80=99t think we can remove it = entirely.


--
Colin Perkins
htt= ps://csperkins.org/




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

--001a113d376a085f10055905a4e4-- From nobody Tue Sep 12 20:34:53 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FB0132962 for ; Tue, 12 Sep 2017 20:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Qvb7zcJV9OmU for ; Tue, 12 Sep 2017 20:34:50 -0700 (PDT) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (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 4543912008A for ; Tue, 12 Sep 2017 20:34:50 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 314C55568; Tue, 12 Sep 2017 23:34:47 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BC0A35506; Tue, 12 Sep 2017 23:34:46 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 12 Sep 2017 23:34:47 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Tue, 12 Sep 2017 21:34:45 -0600 Cc: Christer Holmberg , mmusic WG Content-Transfer-Encoding: quoted-printable Message-Id: <4D740A1E-0F86-4D41-9ABE-134B2C588AC5@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> To: Taylor Brandstetter X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 03:34:51 -0000 > On Sep 12, 2017, at 12:30 PM, Taylor Brandstetter = wrote: >=20 > Maybe a detailed example will make this more clear: > =E2=80=A2 Endpoint A ("Alice") creates PeerConnection, adds = track to it. Suppose this track's ID is "trackA". > =E2=80=A2 RTCRtpTransceiver is created, along with an = RTCRtpReceiver that has a track with a randomly generated ID. Let's call = it "generatedA". > =E2=80=A2 Endpoint B ("Bob") does the same thing; suppose they = added a track with ID "trackB", and a remote track was created with ID = "generatedB". > =E2=80=A2 Alice creates offer, signals to Bob. > =E2=80=A2 Bob applies remote description. The SDP contains = "a=3Dmsid:streamA trackA", but Bob's remote track ("generatedB") already = exists. So it just gets added to a stream, and the ID "trackA" gets = ignored. > =E2=80=A2 Bob creates answer, signals to Alice. > =E2=80=A2 Same thing. The SDP contains "a=3Dmsid:streamB = trackB", but the track ("generatedA") already exists and the ID "trackB" = is ignored. > The MSID draft clearly doesn't align with this. It assumes a track is = always created when a new track ID is seen in SDP. > =20 >=20 Thanks - that makes it perfectly clear.=20 What I would have expected to happen in this case is when Bob applies = the remote description, the trackID of that track changes from = "generatedB" to "trackA". It seems like that track is being reused to = now carry "trackA" and is the only way the data survives. It also = mirrors what would have happened if the track was not created ahead of = time and just crated by Bob applying the remote offer.=20= From nobody Wed Sep 13 03:04:59 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE885134202 for ; Wed, 13 Sep 2017 03:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 F_O3IGvq_Yb0 for ; Wed, 13 Sep 2017 03:04:56 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 22138133018 for ; Wed, 13 Sep 2017 03:04:55 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-4c-59b902c62821 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2F.9C.20899.6C209B95; Wed, 13 Sep 2017 12:04:54 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Wed, 13 Sep 2017 11:58:36 +0200 From: Christer Holmberg To: Eric Rescorla , Colin Perkins CC: mmusic WG , Paul Kyzivat Thread-Topic: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis Thread-Index: AQHTKIyuJzGoax9hl0ur9AF8dFJN8aKw3csAgABPUICAABvEgIAAYeUAgAAQ5QCAAPMpAA== Date: Wed, 13 Sep 2017 09:58:35 +0000 Message-ID: References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.6.170621 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D5DEDCD521595christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7iu4xpp2RBneOSVksf3mC0WLF63Ps FlOXP2axWLHhAKsDi8ff9x+YPKbdv8/msWTJTyaPyY/bmANYorhsUlJzMstSi/TtErgy1l94 wVIw3bli3p8zbA2MrZZdjBwcEgImEnOWZ3YxcnEICRxhlJjcMpcFwlnCKPH+w2x2kCI2AQuJ 7n/aXYycHCICzhJnd65iBLGZBVwlJs74DWYLC1hKTF58mAmixkri99rHzBB2mMTm+/sYQcaw CKhKXD0TChLmFbCW+H/wJyPEqovMEv+fTQGr4RQIlDh/A2wMo4CYxPdTa5ggVolL3HoyH8yW EBCQWLLnPDOELSrx8vE/VhBbVEBPYvbGQywQcUWJj6/2QZ2ZINH59wYrxF5BiZMzn7BMYBSd hWTsLCRls5CUQcQNJN6fm88MYWtLLFv4GsrWl9j45SwjhG0t8XzTZ1ZkNQsYOVYxihanFhfn phsZ6aUWZSYXF+fn6eWllmxiBMbqwS2/rXYwHnzueIhRgINRiYd39fUdkUKsiWXFlbmHGCU4 mJVEeI99AgrxpiRWVqUW5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TBKdXA uJJ3zYqLlUm7LTldJ+7QCg6emN4rti378NbOhQ2Xzxw+q/HkY3pw1A3PJ/XfTp9kPvZ28Vfe wpMbvptHnXDv6dlR9ThCMSJ93/PvzT5lzP9lpUU1nv4V+rXs6G2VRTo8V7wOyHi937yt/MUx bo3dF4sqBBcGMK/YdofhttvthLdN7cc5DU8UrVRiKc5INNRiLipOBACxMJnL0QIAAA== Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 10:04:58 -0000 --_000_D5DEDCD521595christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I support the approach below too. However, I think we should have a little more text: saying that k=3D is inc= luded for legacy reasons, that one must not include it in SDP, and if recei= ved must accept and discard it. =85or something like that. Regards, Christer From: mmusic > on b= ehalf of Eric Rescorla > Date: Wednesday 13 September 2017 at 01:33 To: Colin Perkins > Cc: "mmusic@ietf.org" >, "pkyzivat@alum.mit.edu" > Subject: Re: [MMUSIC] k=3D and draft-ietf-mmusic-rfc4566bis This seems like a fine resolution to me. On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins > wrote: > On 12 Sep 2017, at 16:42, Paul Kyzivat > wrote: > > On 9/12/17 10:03 AM, Cullen Jennings wrote: >> First, I don't feel strongly about this and glad to go with whatever Col= in wants ... but what I was thinking .... >> k=3D is still defined by RFC4566 and things that implement RFC4566 still= use it. I don't think we have an IANA table for this but if we do, the IAN= A registry still lists it with the reference for it as RFC4566. >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k=3D o= ne way or another. If something that implements RFCAAAA receives a k=3D lin= e, it gets treated just like any other unknown line and is ignored. >> There not enough advice on how to use the k=3D stuff to expect interoper= able implementation of any type of security that the IETF would currently c= onsider acceptable to publish as a standard. Anyone who uses k=3D is very u= nlikely to be upgrading their software to RFCAAAA. I just don't see anythin= g good that comes of putting this in the new RFC and it just adds to the co= nfusion of how to secure RTP. > > One thing: if all mention of k=3D is removed from the bis, then in the (f= ar) someone who is defining a new line might choose k=3D for it. (Admittedl= y this is pretty far fetched.) > > I think a cleaner way to handle this would be to deprecate k=3D in the bi= s. I=92d not object if the text in 4566bis was changed to: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 5.12. Encryption Keys ("k=3D") k=3D k=3D: The =93k=3D=93 line is obsolete and MUST NOT be used. 5.13. Attributes (=93a=3D=93) =85 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =85or something similar. I just don=92t think we can remove it entirely. -- Colin Perkins https://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D5DEDCD521595christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I support the approach below too.

However, I think we should have a little more text: saying that k=3D i= s included for legacy reasons, that one must not include it in SDP, and if = received must accept and discard it.

=85or something like that.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Eric = Rescorla <ekr@rtfm.com>
Date: Wednesday 13 September 2017 a= t 01:33
To: Colin Perkins <csp@csperkins.org>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>, "pky= zivat@alum.mit.edu" <p= kyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] k=3D and draf= t-ietf-mmusic-rfc4566bis

This seems like a fine resolution to me.

On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <= span dir=3D"ltr"> <csp@csperkins.or= g> wrote:

> On 12 Sep 2017, at 16:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
> On 9/12/17 10:03 AM, Cullen Jennings wrote:
>> First, I don't feel strongly about this and glad to go with whatev= er Colin wants ... but what I was thinking ....
>> k=3D is still defined by RFC4566 and things that implement RFC4566= still use it. I don't think we have an IANA table for this but if we do, t= he IANA registry still lists it with the reference for it as RFC4566.
>> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention = k=3D one way or another. If something that implements RFCAAAA receives a k= =3D line, it gets treated just like any other unknown line and is ignored.<= br> >> There not enough advice on how to use the k=3D stuff to expect int= eroperable implementation of any type of security that the IETF would curre= ntly consider acceptable to publish as a standard. Anyone who uses k=3D is = very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of putting this in t= he new RFC and it just adds to the confusion of how to secure RTP.
>
> One thing: if all mention of k=3D is removed from the bis, then in the= (far) someone who is defining a new line might choose k=3D for it. (Admitt= edly this is pretty far fetched.)
>
> I think a cleaner way to handle this would be to deprecate k=3D in the= bis.

I=92d not object if the text in 4566bis was changed to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.12.  Encryption Keys ("k=3D")

      k=3D<method>
      k=3D<method>:<encryption key>


  The =93k=3D=93 line is obsolete and MUST NOT be used.

5.13.  Attributes (=93a=3D=93)
=85
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=85or something similar. I just don=92t think we can remove it entirely.


--
Colin Perkins
htt= ps://csperkins.org/




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

--_000_D5DEDCD521595christerholmbergericssoncom_-- From nobody Wed Sep 13 05:40:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358FD126DFE for ; Wed, 13 Sep 2017 05:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lL4HLg40XejP for ; Wed, 13 Sep 2017 05:40:25 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 553AB1241F3 for ; Wed, 13 Sep 2017 05:40:25 -0700 (PDT) X-AuditID: c1b4fb30-66bff70000007145-cb-59b92737ad21 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.37.28997.73729B95; Wed, 13 Sep 2017 14:40:23 +0200 (CEST) Received: from [100.94.42.7] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 13 Sep 2017 14:40:22 +0200 To: Ben Campbell CC: , , , Henning Schulzrinne , Flemming Andreasen References: <20170808165231.7B757B80E45@rfc-editor.org> <195f8cfb-9ee4-a13d-3703-cc51844899cd@ericsson.com> From: Magnus Westerlund Message-ID: <61622083-fef9-4abb-69d7-69d7ac66fb8e@ericsson.com> Date: Wed, 13 Sep 2017 14:40:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050400000208000806090202" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2K7q665+s5Ig3VrZSz2vz/EZDG/8zS7 xfsLuhZTlz9msXjde5LZ4tI/FQc2jym/N7J6fL11kMlj56kDbB47Z91l91iy5CeTx6ydT1gC 2KK4bFJSczLLUov07RK4Mq4+v8xS8DapYsnXzAbGJ+FdjJwcEgImEote/GTqYuTiEBI4wihx 5cxWRghnA6PExOa/bCBVwgIOEtMmXGQGsUUElCSeN29lASliFljKKHF38QcWiI5FjBLP1q0F 62ATsJC4+aMRzOYVsJe4c62REcRmEVCVWLhyO1hcVCBG4uelRywQNYISJ2c+AbM5geo7Ns1k h9jQzSjxfOc/JpCEkIC2RENTByvE4UoS1+ddZ5nAKDALSf8sZD0gCWYBM4l5mx8yQ9jaEssW voayxSWavqxkhbCtJWb8OsgGYStKTOl+yA5hm0q8PvqREcI2kni3p5F9ASPnKkbR4tTipNx0 IyO91KLM5OLi/Dy9vNSSTYzA2Du45bfBDsaXzx0PMQpwMCrx8Ooz74wUYk0sK67MPcSoAjTn 0YbVFxilWPLy81KVRHhVZIHSvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0t SC2CyTJxcEo1ME6ZaaW6dNKk+vqPNbol0oLPUjleSf+MevrvGRd73eewRTqpoqdrqiycH2ZN ybRrWPM8vChr/XyJgMb+rv73fqdehuWuShAwNijPieipffOJrdNq8ytdgZKNClENAgc3XdlR vev49fd5y/dtZon1/x+86poJ98tVEdkn53bbRc7fm/SnLUDrgRJLcUaioRZzUXEiAGuCFpnF AgAA Archived-At: Subject: Re: [MMUSIC] [Technical Errata Reported] RFC2326 (5079) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 12:40:28 -0000 --------------ms050400000208000806090202 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, I am fine with blocking this Errata with reference to the replacement=20 RFC. If this was one a really critical errata I might argue for it being = published anyway. Regarding RTSP 1.0 it is still in existing use, but that is not really=20 RFC 2326. It is implementations follows things like this combination:=20 RFC 2326 + 3GPP extensions and clarifications + IMTC Interop testing=20 agreements. RFC 2326 is simply to broken to implement from. Regarding RFC 7826 and the corresponding example. That is correct, and=20 has a Content-Length value of 26. See section 13.8: =C2=A0=C2=A0=C2=A0=C2=A0 S->C: GET_PARAMETER rtsp://example.com/fizzle/f= oo RTSP/2.0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CSeq: 431 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 User-Agent:= PhonyClient/1.2 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Session: Oc= cldOFFq23KwjYpAnBbUr =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Len= gth: 26 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Typ= e: text/parameters =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packets_rec= eived =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 jitter =C2=A0=C2=A0=C2=A0=C2=A0 C->S: RTSP/2.0 200 OK =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CSeq: 431 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Session: Oc= cldOFFq23KwjYpAnBbUr =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Server: Pho= nyServer/1.1 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Date: Mon, = 08 Mar 2010 13:43:23 GMT =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Len= gth: 38 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Typ= e: text/parameters =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 packets_rec= eived: 10 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 jitter: 0.3= 838 Cheers Magnus Den 2017-08-25 kl. 16:41, skrev Ben Campbell: > RFC 2326 is obsolete. I don=E2=80=99t think we normally accept errata = against obsolete drafts, do we? (If anyone still cares about RTSP 1.0, = maybe it should have been made historical instead,. But that=E2=80=99s wa= ter under the bridge.) > > I assume the content-length exampless in 7826 are correct? > > Ben. > >> On Aug 25, 2017, at 3:45 AM, Magnus Westerlund wrote: >> >> Hi, >> >> Thanks for reporting, however considering how many issues there are in= RFC 2326, and why RFC 7826 was produced, I frankly don't know if its wor= th accepting this errata or not. >> >> The errata is clearly right in that the RFC is wrong. If one follows t= he format for text/parameters defined in RTSP 2.0: https://datatracker.ie= tf.org/doc/rfc7826/ then there should be CRLF at the end of each line, an= d there are no EOF marker. Thus the length should be: 26. So maybe with t= hat edit it is simplest to accept it. >> >> Cheers >> >> Magnus Westerlund >> >> >> >> Den 2017-08-08 kl. 18:52, skrev RFC Errata System: >>> The following errata report has been submitted for RFC2326, >>> "Real Time Streaming Protocol (RTSP)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5079 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Vadim Zhukov >>> >>> Section: 10.8 >>> >>> Original Text >>> ------------- >>> S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 >>> CSeq: 431 >>> Content-Type: text/parameters >>> Session: 12345678 >>> Content-Length: 15 >>> >>> packets_received >>> jitter >>> >>> Corrected Text >>> -------------- >>> S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 >>> CSeq: 431 >>> Content-Type: text/parameters >>> Session: 12345678 >>> Content-Length: 24 >>> >>> packets_received >>> jitter >>> >>> Notes >>> ----- >>> The Content-Length value is wrong, it should be either 24 (as propose= d) or 26, depending on end-of-line marker used for message content. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC2326 (no draft string recorded) >>> -------------------------------------- >>> Title : Real Time Streaming Protocol (RTSP) >>> Publication Date : April 1998 >>> Author(s) : H. Schulzrinne, A. Rao, R. Lanphier >>> Category : PROPOSED STANDARD >>> Source : Multiparty Multimedia Session Control RAI >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> --=20 >> >> Magnus Westerlund >> >> ----------------------------------------------------------------------= >> Media Technologies, Ericsson Research >> ----------------------------------------------------------------------= >> Ericsson AB | Phone +46 10 7148287 >> Torshamnsgatan 23 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ----------------------------------------------------------------------= >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms050400000208000806090202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA5MTMxMjQwMDRaMC8GCSqGSIb3DQEJBDEiBCBRFFU+xUUOcir3npwU iSfVwOAFRKlNYUhwJU23Z4+gxjBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAjrt7nUvPulbUKq+Y3cnRYicGxqWmRCNJrlGDqKlvXcoMZrQ4 Lund0cVAK1m13mRHsS5Y/Rux3s3VgP3JD4/4iLq6A0Z0GJklG5DyRiOlyekMhY+WYhMEKsy9 mVpDpA5kdbsLvbbvO+7jjaQlgCpi3SKv7f5oGEQJdv/xWvEkXwdjCQjsv/PzkLADpJL15npl Nj7xxDKYes7po4pj/sYgKslUVu8VmehS0cwE4lB4jseT5gVuVaFbbu6k0yV/tAwLT66nbuo+ 5SeMZRmthIfCgYKb3OXrzkl9+nlEdJsHOMnXWxV0WJIOK4SDa+xyup3KKxb1ZrYz0LqLNsUm aTBgiwAAAAAAAA== --------------ms050400000208000806090202-- From nobody Wed Sep 13 10:01:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046F71321B6 for ; Wed, 13 Sep 2017 10:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjXiYqlLOvTT for ; Wed, 13 Sep 2017 10:01:08 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD96C1320D9 for ; Wed, 13 Sep 2017 10:01:07 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id i189so11792888wmf.1 for ; Wed, 13 Sep 2017 10:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dOsAcMWNArjikKi+ahuZ88kKu/J6rnXmIldQ/PX7pY0=; b=fSzqgYwMR1aYQtyRG5WtNTFoeUYzIDSC/EY9YXruNCewLhFX+23LGzDhUled3RcHv8 khf4vkFlBgNLyd2C8MAavgArFTNLPOyvcrxUdPb6/25iiqOC9m4jzh08TOJWKknbfb7N +L23q0Q3k2llF+FAdCHJHxgdp9+0n6/QrHBDA/DDTOf1pALJuc5e/NIC/VtkJXH8ONig 9sBtFJFKeczAXBnISiB+GJqsuT+J2vM+0LVeTGuoe4aWqoaEIHuq8oTjXN+E5Uxb3LlM AGLlvf4CqV0Z6Xki7VN3M/e7njCmZ8Z7TVRjxEJR7o946rTcrR0Q4baDYbuuU7dGTYnX /PUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dOsAcMWNArjikKi+ahuZ88kKu/J6rnXmIldQ/PX7pY0=; b=GKfmmITMjwwL0E8a67f9JfOtJzoQf3QtWoYLxas9GIYpPHJXv/TpLQZCMULbxg50gP NWqLQgSqPpd5dPmX4jJ69OQYiH4+XNJ0bQfFiNdjELu5IHHBRa291OqFMmoPxiwilMfU ql+7aQ9mQ6Fy8S+oLAopRjDyVtO8NhH3GNqzBaS44Sml/3YcamzbQEWAvAir7avP60EW xepmvKQ83VFXQV9gbZEFTvHzJkC2UfISRzxxlXf1Dd8hDd159XGzGrEJVUhCat3PGWc2 o1FgHzg6KhZEUnKgmR+YB2t+lNNTT3orrupdXw8NwJAVou3vqSTpXLi0VUiZH7G/cMb3 PPyQ== X-Gm-Message-State: AHPjjUgvExzs6KPvOVhTcyblCVe6NYYEImoAEo1uM3aSuPAfs/I7rmD0 G1zlTNqsst63xWVILE/OPvTYqwCkKqOB+AB+JkhRaA== X-Google-Smtp-Source: AOwi7QBffSDVcbpwrSq3Qk4t1fp6TNgcE0pusM8PE/HxBgZ/l+Wk+sTjYoXI0TtFsbVE6Tz5Pw0LEjf2WtEpcWlSK7k= X-Received: by 10.28.88.201 with SMTP id m192mr2869066wmb.111.1505322066020; Wed, 13 Sep 2017 10:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.154.54 with HTTP; Wed, 13 Sep 2017 10:01:05 -0700 (PDT) In-Reply-To: <4D740A1E-0F86-4D41-9ABE-134B2C588AC5@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se> <4D740A1E-0F86-4D41-9ABE-134B2C588AC5@iii.ca> From: Taylor Brandstetter Date: Wed, 13 Sep 2017 10:01:05 -0700 Message-ID: To: Cullen Jennings Cc: Christer Holmberg , mmusic WG Content-Type: multipart/alternative; boundary="001a114422740553560559151b92" Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 17:01:10 -0000 --001a114422740553560559151b92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > What I would have expected to happen in this case is when Bob applies the > remote description, the trackID of that track changes from "generatedB" t= o > "trackA". > That would mean that MediaStreamTrack IDs can change after creation, which seems dangerous. It's pretty normal to assume that IDs are immutable. Based on the conversation we just had in the WebRTC virtual interim , it sounds like the preferred path forward would be to go in the opposite direction, and say that the "msid-appdata" field is *always* ignored by WebRTC endpoints (when applying a remote description). We could also go a step further, and have JSEP never populate the field. Right now JSEP says: the "a=3Dmsid" lines MUST use [the RTCRtpSender's] track's ID. If no > MediaStreamTrack is attached, a valid ID MUST be generated > > As a JSEP author, do you have any thoughts on that, Cullen? On Tue, Sep 12, 2017 at 8:34 PM, Cullen Jennings wrote: > > > On Sep 12, 2017, at 12:30 PM, Taylor Brandstetter > wrote: > > > > Maybe a detailed example will make this more clear: > > =E2=80=A2 Endpoint A ("Alice") creates PeerConnection, adds track= to it. > Suppose this track's ID is "trackA". > > =E2=80=A2 RTCRtpTransceiver is created, along with an RTCRtpRecei= ver that > has a track with a randomly generated ID. Let's call it "generatedA". > > =E2=80=A2 Endpoint B ("Bob") does the same thing; suppose they ad= ded a > track with ID "trackB", and a remote track was created with ID "generated= B". > > =E2=80=A2 Alice creates offer, signals to Bob. > > =E2=80=A2 Bob applies remote description. The SDP contains "a=3Dm= sid:streamA > trackA", but Bob's remote track ("generatedB") already exists. So it just > gets added to a stream, and the ID "trackA" gets ignored. > > =E2=80=A2 Bob creates answer, signals to Alice. > > =E2=80=A2 Same thing. The SDP contains "a=3Dmsid:streamB trackB",= but the > track ("generatedA") already exists and the ID "trackB" is ignored. > > The MSID draft clearly doesn't align with this. It assumes a track is > always created when a new track ID is seen in SDP. > > > > > > Thanks - that makes it perfectly clear. > > What I would have expected to happen in this case is when Bob applies the > remote description, the trackID of that track changes from "generatedB" t= o > "trackA". It seems like that track is being reused to now carry "trackA" > and is the only way the data survives. It also mirrors what would have > happened if the track was not created ahead of time and just crated by Bo= b > applying the remote offer. --001a114422740553560559151b92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I would have expected to happen in this case = is when Bob applies the remote description, the trackID of that track chang= es from "generatedB" to "trackA".

That would mean that MediaStreamTrack IDs can change after= creation, which seems dangerous. It's pretty normal to assume that IDs= are immutable.

Based on the conversation we just had in= the W= ebRTC virtual interim, it sounds like the preferred path forward would = be to go in the opposite direction, and say that the "msid-appdata&quo= t; field is always=C2=A0ignored by WebRTC endpoints (when applying a= remote description). We could also go a step further, and have JSEP never = populate the field. Right now JSEP says:

the "a=
=3Dmsid" lines MUST use [the RTCRtpSender's] track's ID.  If n=
o
MediaStreamTrack is attached, a valid ID MUST be generated
As a JSEP author, do you have any thoughts on = that, Cullen?

On Tue, Sep 12, 2017 at 8:34 PM, Cullen Jennings <fluffy@iii.ca> wrote:

> On Sep 12, 2017, at 12:30 PM, Taylor Brandstetter <deadbeef@google.com> wrote:
>
> Maybe a detailed example will make this more clear:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Endpoint A ("Alice") cre= ates PeerConnection, adds track to it. Suppose this track's ID is "= ;trackA".
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RTCRtpTransceiver is created, alon= g with an RTCRtpReceiver that has a track with a randomly generated ID. Let= 's call it "generatedA".
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Endpoint B ("Bob") does = the same thing; suppose they added a track with ID "trackB", and = a remote track was created with ID "generatedB".
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Alice creates offer, signals to Bo= b.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Bob applies remote description. Th= e SDP contains "a=3Dmsid:streamA trackA", but Bob's remote tr= ack ("generatedB") already exists. So it just gets added to a str= eam, and the ID "trackA" gets ignored.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Bob creates answer, signals to Ali= ce.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Same thing. The SDP contains "= ;a=3Dmsid:streamB trackB", but the track ("generatedA") alre= ady exists and the ID "trackB" is ignored.
> The MSID draft clearly doesn't align with this. It assumes a track= is always created when a new track ID is seen in SDP.
>
>

Thanks - that makes it perfectly clear.

What I would have expected to happen in this case is when Bob applies the r= emote description, the trackID of that track changes from "generatedB&= quot; to "trackA". It seems like that track is being reused to no= w carry "trackA" and is the only way the data survives. It also m= irrors what would have happened if the track was not created ahead of time = and just crated by Bob applying the remote offer.

--001a114422740553560559151b92-- From nobody Wed Sep 13 15:04:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3713304E; Wed, 13 Sep 2017 15:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 bHXh-gUaVAQi; Wed, 13 Sep 2017 15:04:17 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517F5133074; Wed, 13 Sep 2017 15:04:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9A91DB81754; Wed, 13 Sep 2017 15:04:00 -0700 (PDT) To: persgray@gmail.com, schulzrinne@cs.columbia.edu, anup@netscape.com, robla@real.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ben@nostrum.com, iesg@ietf.org, mmusic@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170913220400.9A91DB81754@rfc-editor.org> Date: Wed, 13 Sep 2017 15:04:00 -0700 (PDT) Archived-At: Subject: [MMUSIC] [Errata Rejected] RFC2326 (5079) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 22:04:18 -0000 The following errata report has been rejected for RFC2326, "Real Time Streaming Protocol (RTSP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5079 -------------------------------------- Status: Rejected Type: Technical Reported by: Vadim Zhukov Date Reported: 2017-08-08 Rejected by: Ben Campbell (IESG) Section: 10.8 Original Text ------------- S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 431 Content-Type: text/parameters Session: 12345678 Content-Length: 15 packets_received jitter Corrected Text -------------- S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 431 Content-Type: text/parameters Session: 12345678 Content-Length: 24 packets_received jitter Notes ----- The Content-Length value is wrong, it should be either 24 (as proposed) or 26, depending on end-of-line marker used for message content. --VERIFIER NOTES-- RFC 2326 has been obsoleted by RFC 7826. The similar examples in RFC 7826 appear to have correct content-length field values. -------------------------------------- RFC2326 (no draft string recorded) -------------------------------------- Title : Real Time Streaming Protocol (RTSP) Publication Date : April 1998 Author(s) : H. Schulzrinne, A. Rao, R. Lanphier Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Thu Sep 14 09:03:49 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E501321C7; Thu, 14 Sep 2017 09:03:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150540502703.12603.17962279219166496882@ietfa.amsl.com> Date: Thu, 14 Sep 2017 09:03:47 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 16:03:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile Authors : Andrew Hutton Roland Jesske Alan Johnston Gonzalo Salgueiro Bernard Aboba Filename : draft-ietf-mmusic-opportunistic-negotiation-01.txt Pages : 7 Date : 2017-09-14 Abstract: This document describes how the use of the Secure Real-time transport protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio Video Profile) defined in [RFC3551]. Such a mechanism is used to provide a means for encrypted media to be used in environments where support for encryption is not known in advance, and not required. The same mechanism is also applied to negotiation of the Extended RTP Profile for Real-time Transport Control Protocol Based Feedback (RTP/ AVPF) [RFC4585]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-01 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-negotiation-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-opportunistic-negotiation-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 Sep 15 06:07:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C56133226 for ; Fri, 15 Sep 2017 06:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNv-UuwnMZmp for ; Fri, 15 Sep 2017 06:07:22 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F0C133076 for ; Fri, 15 Sep 2017 06:07:21 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i189so8186893wmf.1 for ; Fri, 15 Sep 2017 06:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ThuHoTcUDFoM5VslDw6Q6nsEkmeHSKdhPoJNGCeXa44=; b=sDLgttogYBzUnwQV4udCJ9KLPPXZO8plQvX/1EqJHyhf0pOl+x2tT9tq5mnxJUTG5c y9+1nlXoMDEoBKLLrFZ5S8QZqauQpc/L6y0lnqvJYM7kjfsvTGxEthQNVRq0uxdMib/r ibu8LfMlONdgIP/4ruoFUpcNZp3rewO9ZC5Nvn6horOV1B5ErrKncL7Pc/3cf1xFeU5s R6wr4N+5/G6q36iojp3FCBrRcXooO5+UykFP5CtlFkqIRMGpFOrYK8/Iki/Jhn4TDIxX 1dRezLmEYPaKI61BOpv8oQC1fIjOgb90cWD88YrlDfuuxwOVH7kpZ4hrrGzPkhJaLAfF CSrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ThuHoTcUDFoM5VslDw6Q6nsEkmeHSKdhPoJNGCeXa44=; b=I0aeX7WHtfM1I4+I8bcJdAzqi8xNOS9+1QdVKh/bzyLO8N64KmEdnuZd5XgZyi7xA4 27zwaNvEfxCTm+0AcelHOjfPNANqNKoBlfCXqhrR+84gKofQBgGjzD7qmOqU31FZrOwv Hdztvk4LWw3Eu37XYKipKNtqbK1Y6OBqmNYPI3fbNvvpX1n6uR4SNBTel81thk/YER+7 +5ouH2B4HhCjgaa1+Iq7qLLShAKSmYcR2HSE8b5mEXYtt4TH6uJywvGw+gAvNY+k9lsi JyE4eWi6ZbF7t//NqDZ8QFW8l5obyicGOx7FW06zBl1pH3qXBZnXxrPky8xWEhxhenFA zLNQ== X-Gm-Message-State: AHPjjUgB5Em18K708/TMayyiYVsNaH7vDOVLSEa2zTku7Jo4CBRWGPhq w01xqQoCqy/x3iEodkJdrp2JQq5kOEO/KvXo1WA= X-Google-Smtp-Source: AOwi7QBRND06dWt50PvfC1/Z49alYlZ/AIaurWHg0B5DCeAwYKLvk/wyeDU0poczavS2PDna6WEhbO5j/m5axWUIoJ8= X-Received: by 10.28.101.133 with SMTP id z127mr2780236wmb.123.1505480840028; Fri, 15 Sep 2017 06:07:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.172.46 with HTTP; Fri, 15 Sep 2017 06:07:19 -0700 (PDT) In-Reply-To: <150540502703.12603.17962279219166496882@ietfa.amsl.com> References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> From: Andy Hutton Date: Fri, 15 Sep 2017 14:07:19 +0100 Message-ID: To: "mmusic (E-mail)" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 13:07:24 -0000 The changes to this draft are editorial and address a previous comment from Colin Perkins that we needed to refer to RTP profiles by the full name. I am hoping we can now move this draft forward to WGLC and subsequently close the work in SIPBrandy as well. Regards Andy On Thu, Sep 14, 2017 at 5:03 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. > > Title : Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile > Authors : Andrew Hutton > Roland Jesske > Alan Johnston > Gonzalo Salgueiro > Bernard Aboba > Filename : draft-ietf-mmusic-opportunistic-negotiation-01.txt > Pages : 7 > Date : 2017-09-14 > > Abstract: > This document describes how the use of the Secure Real-time transport > protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio > Video Profile) defined in [RFC3551]. Such a mechanism is used to > provide a means for encrypted media to be used in environments where > support for encryption is not known in advance, and not required. > The same mechanism is also applied to negotiation of the Extended RTP > Profile for Real-time Transport Control Protocol Based Feedback (RTP/ > AVPF) [RFC4585]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiation/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-01 > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-negotiation-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-opportunistic-negotiation-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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Sep 15 06:19:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E056133226 for ; Fri, 15 Sep 2017 06:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9cSYS-O2CtVG for ; Fri, 15 Sep 2017 06:19:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 A8ABD120720 for ; Fri, 15 Sep 2017 06:19:43 -0700 (PDT) X-AuditID: c1b4fb25-967ff70000005333-64-59bbd36d493e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.B5.21299.D63DBB95; Fri, 15 Sep 2017 15:19:41 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Fri, 15 Sep 2017 15:19:41 +0200 From: Christer Holmberg To: Andy Hutton , "mmusic (E-mail)" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6K1yrGAgAA3NQA= Date: Fri, 15 Sep 2017 13:19:40 +0000 Message-ID: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7429C53B3E09D34BB26E51AABDD7BEFE@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7h27u5d2RBq3XtSwurdvKZDF1+WMW ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjxo7TLAV3JCq2XF3B3sDYLdzFyMkhIWAi 0XHyA3sXIxeHkMARRokvq64yQjhLGCV2n33M2sXIwcEmYCHR/U8bpEFEIEji06T5LCC2sECY xKnNx5gg4uESs98dBCsXEbCSeH9BEiTMIqAq8WnHHzYQm1fAWmLd+3MsEOO7GSWOtB1mBklw CgRKvNn1gx3EZhQQk/h+ag3YTGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wgtqiAnsSGE7fZ IeKKEh9f7WOE6NWTuDF1ChvIPcxAi3+2u0CEtSWWLXzNDHGPoMTJmU9YJjCKzUKybRaS7lkI 3bOQdM9C0r2AkXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBMHdzyW3UH4+U3jocYBTgY lXh4p57aHSnEmlhWXJl7iFGCg1lJhPfJGaAQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9FyKE BNITS1KzU1MLUotgskwcnFINjGISZx6efx+vLHZb7Ijtmrmsl/hSHQo4tgYd7ZBjLEn9f2Vl oLC6Tsmprdq//bZv7WeKPP/xYkHwLal/C9KKLVqYSh6XzP6UWnl/feCFum//vf68c7/Tmdpe 1D/rukb5l2W88hfcHq+MSco5ktlQtn1BmNDVgmtX9UJqb3du4tnMqTD3tc70g0osxRmJhlrM RcWJAMsD/UilAgAA Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 13:19:46 -0000 Hi, I sent some initial comments on the Abstract of the individual draft way back. I don=B9t think anyone ever replied, but it seems like my comments have been addressed. I do have some more comments, but they are mostly editorial so I can provide them as WGLC comments. Regards, Christer On 15/09/17 16:07, "mmusic on behalf of Andy Hutton" wrote: >The changes to this draft are editorial and address a previous comment >from Colin Perkins that we needed to refer to RTP profiles by the full >name. > >I am hoping we can now move this draft forward to WGLC and >subsequently close the work in SIPBrandy as well. > >Regards >Andy > >On Thu, Sep 14, 2017 at 5:03 PM, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Multiparty Multimedia Session Control >>WG of the IETF. >> >> Title : Negotiating SRTP and RTCP Feedback using the >>RTP/AVP Profile >> Authors : Andrew Hutton >> Roland Jesske >> Alan Johnston >> Gonzalo Salgueiro >> Bernard Aboba >> Filename : >>draft-ietf-mmusic-opportunistic-negotiation-01.txt >> Pages : 7 >> Date : 2017-09-14 >> >> Abstract: >> This document describes how the use of the Secure Real-time transport >> protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio >> Video Profile) defined in [RFC3551]. Such a mechanism is used to >> provide a means for encrypted media to be used in environments where >> support for encryption is not known in advance, and not required. >> The same mechanism is also applied to negotiation of the Extended RTP >> Profile for Real-time Transport Control Protocol Based Feedback (RTP/ >> AVPF) [RFC4585]. >> >> >> The IETF datatracker status page for this draft is: >>=20 >>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiat >>ion/ >> >> There are also htmlized versions available at: >>=20 >>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-0 >>1 >>=20 >>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-neg >>otiation-01 >> >> A diff from the previous version is available at: >>=20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-negot= ia >>tion-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/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Sep 15 06:28:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FD11332CE for ; Fri, 15 Sep 2017 06:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 RgafsZlA2UAL for ; Fri, 15 Sep 2017 06:28:47 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E647A1332CD for ; Fri, 15 Sep 2017 06:28:46 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 711F41EB849E; Fri, 15 Sep 2017 15:28:45 +0200 (CEST) Received: from MCHP03MSX.global-ad.net ([169.254.130.76]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0339.000; Fri, 15 Sep 2017 15:28:45 +0200 From: "Hutton, Andrew" To: Christer Holmberg , Andy Hutton , "mmusic (E-mail)" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6K1yrGAgAA3NQD//+/cQA== Date: Fri, 15 Sep 2017 13:28:44 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF2B654B41@MCHP03MSX.global-ad.net> References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 13:28:48 -0000 Christer,=20 I believe your comments actually referred to https://tools.ietf.org/html/dr= aft-ietf-sipbrandy-osrtp-02 and are still valid. I asked Alan to address th= em. Andy -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 15 September 2017 14:20 To: Andy Hutton; mmusic (E-mail) Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiati= on-01.txt Hi, I sent some initial comments on the Abstract of the individual draft way ba= ck. I don=B9t think anyone ever replied, but it seems like my comments have= been addressed. I do have some more comments, but they are mostly editorial so I can provid= e them as WGLC comments. Regards, Christer On 15/09/17 16:07, "mmusic on behalf of Andy Hutton" wrote: >The changes to this draft are editorial and address a previous comment=20 >from Colin Perkins that we needed to refer to RTP profiles by the full=20 >name. > >I am hoping we can now move this draft forward to WGLC and subsequently=20 >close the work in SIPBrandy as well. > >Regards >Andy > >On Thu, Sep 14, 2017 at 5:03 PM, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>directories. >> This draft is a work item of the Multiparty Multimedia Session=20 >>Control WG of the IETF. >> >> Title : Negotiating SRTP and RTCP Feedback using the >>RTP/AVP Profile >> Authors : Andrew Hutton >> Roland Jesske >> Alan Johnston >> Gonzalo Salgueiro >> Bernard Aboba >> Filename : >>draft-ietf-mmusic-opportunistic-negotiation-01.txt >> Pages : 7 >> Date : 2017-09-14 >> >> Abstract: >> This document describes how the use of the Secure Real-time transport >> protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio >> Video Profile) defined in [RFC3551]. Such a mechanism is used to >> provide a means for encrypted media to be used in environments where >> support for encryption is not known in advance, and not required. >> The same mechanism is also applied to negotiation of the Extended RTP >> Profile for Real-time Transport Control Protocol Based Feedback (RTP/ >> AVPF) [RFC4585]. >> >> >> The IETF datatracker status page for this draft is: >>=20 >>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negot >>iat >>ion/ >> >> There are also htmlized versions available at: >>=20 >>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiatio >>n-0 >>1 >>=20 >>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic- >>neg >>otiation-01 >> >> A diff from the previous version is available at: >>=20 >>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-nego >>tia >>tion-01 >> >> >> Please note that it may take a couple of minutes from the time of=20 >>submission until the htmlized version and diff are available at=20 >>tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Sep 15 06:32:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956F01332E1 for ; Fri, 15 Sep 2017 06:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IR916axgbkxG for ; Fri, 15 Sep 2017 06:32:47 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 92F071332DF for ; Fri, 15 Sep 2017 06:32:46 -0700 (PDT) X-AuditID: c1b4fb30-683ff70000007145-a4-59bbd67c4a8c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3A.0C.28997.C76DBB95; Fri, 15 Sep 2017 15:32:44 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Fri, 15 Sep 2017 15:32:44 +0200 From: Christer Holmberg To: "Hutton, Andrew" , Andy Hutton , "mmusic (E-mail)" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6K1yrGAgAA3NQD//+/cQIAAE8mA Date: Fri, 15 Sep 2017 13:32:43 +0000 Message-ID: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF2B654B41@MCHP03MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF2B654B41@MCHP03MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <062C0752FAC99D4A9D095B7983C0588D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2J7oG7Ntd2RBvvaLSy2bSi1uLRuK5PF 1OWPWRyYPXbOusvusWTJTyaP7T2PWQKYo7hsUlJzMstSi/TtErgy7nStYSvYoFmxb91XpgbG FRpdjBwcEgImEls35HQxcnEICRxhlDi5ZiELhLOEUWJu12Q2kCI2AQuJ7n/aXYycHCICdRJn vrazgNjCAmESpzYfY4KIh0vMfneQFcJ2k/jUOwushkVAVWLWhadsIDavgLVE/4JOZoj5TUwS 5/b8BiviFPCXuDX5D1gzo4CYxPdTa8CGMguIS9x6Mh/MlhAQkFiy5zwzhC0q8fLxP7B6UQE9 iQ0nbrNDPKMkMW1rGkSrlsSXH/vYIGxriYMXb0KNVJSY0v2QHeIeQYmTM5+wTGAUm4Vk2ywk 7bOQtM9C0j4LSfsCRtZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFxdnDLb4MdjC+fOx5i FOBgVOLh3X5id6QQa2JZcWXuIUYJDmYlEd4nZ4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33 XYgQEkhPLEnNTk0tSC2CyTJxcEo1MK6V9dv7bt2dYMeXkneV5hT/XvCssV5G189tzW/vovCt /qL9pdZ2P+9PWbxE663kLSv2ebdWfWI9PEWhnqeml/ODwi+t76ecr+g+aju2oCIkwuDq0XP5 L0wla/c+Pad0p0Djj/nJix8vexz7PsHtntGBkx931DU77uMWyhDMfy/05j2PtACTxholluKM REMt5qLiRAALLoKorwIAAA== Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 13:32:48 -0000 WW91IGFyZSBwcm9iYWJseSByaWdodCA6KSBUaGUgZS1tYWlsIHN1YmplY3QgY29uZnVzZWQgbWUu DQoNCk9uIDE1LzA5LzE3IDE2OjI4LCAiSHV0dG9uLCBBbmRyZXciIDxhbmRyZXcuaHV0dG9uQHVu aWZ5LmNvbT4gd3JvdGU6DQoNCj5DaHJpc3RlciwgDQo+DQo+SSBiZWxpZXZlIHlvdXIgY29tbWVu dHMgYWN0dWFsbHkgcmVmZXJyZWQgdG8NCj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1zaXBicmFuZHktb3NydHAtMDIgYW5kIGFyZSBzdGlsbA0KPnZhbGlkLiBJIGFza2Vk IEFsYW4gdG8gYWRkcmVzcyB0aGVtLg0KPg0KPkFuZHkNCj4NCj4NCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPlNlbnQ6IDE1IFNlcHRlbWJlciAyMDE3IDE0OjIwDQo+ VG86IEFuZHkgSHV0dG9uOyBtbXVzaWMgKEUtbWFpbCkNCj5TdWJqZWN0OiBSZTogW01NVVNJQ10g SS1EIEFjdGlvbjoNCj5kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9u LTAxLnR4dA0KPg0KPkhpLA0KPg0KPkkgc2VudCBzb21lIGluaXRpYWwgY29tbWVudHMgb24gdGhl IEFic3RyYWN0IG9mIHRoZSBpbmRpdmlkdWFsIGRyYWZ0IHdheQ0KPmJhY2suIEkgZG9uqfZ0IHRo aW5rIGFueW9uZSBldmVyIHJlcGxpZWQsIGJ1dCBpdCBzZWVtcyBsaWtlIG15IGNvbW1lbnRzDQo+ aGF2ZSBiZWVuIGFkZHJlc3NlZC4NCj4NCj5JIGRvIGhhdmUgc29tZSBtb3JlIGNvbW1lbnRzLCBi dXQgdGhleSBhcmUgbW9zdGx5IGVkaXRvcmlhbCBzbyBJIGNhbg0KPnByb3ZpZGUgdGhlbSBhcyBX R0xDIGNvbW1lbnRzLg0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCj4NCj4NCj4NCj4N Cj4NCj4NCj5PbiAxNS8wOS8xNyAxNjowNywgIm1tdXNpYyBvbiBiZWhhbGYgb2YgQW5keSBIdXR0 b24iDQo+PG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhbmR5aHV0dG9uLmll dGZAZ21haWwuY29tPiB3cm90ZToNCj4NCj4+VGhlIGNoYW5nZXMgdG8gdGhpcyBkcmFmdCBhcmUg ZWRpdG9yaWFsIGFuZCBhZGRyZXNzIGEgcHJldmlvdXMgY29tbWVudA0KPj5mcm9tIENvbGluIFBl cmtpbnMgdGhhdCB3ZSBuZWVkZWQgdG8gcmVmZXIgdG8gUlRQIHByb2ZpbGVzIGJ5IHRoZSBmdWxs DQo+Pm5hbWUuDQo+Pg0KPj5JIGFtIGhvcGluZyB3ZSBjYW4gbm93IG1vdmUgdGhpcyBkcmFmdCBm b3J3YXJkIHRvIFdHTEMgYW5kIHN1YnNlcXVlbnRseQ0KPj5jbG9zZSB0aGUgd29yayBpbiBTSVBC cmFuZHkgYXMgd2VsbC4NCj4+DQo+PlJlZ2FyZHMNCj4+QW5keQ0KPj4NCj4+T24gVGh1LCBTZXAg MTQsIDIwMTcgYXQgNTowMyBQTSwgIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0K Pj4+DQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzDQo+Pj5kaXJlY3Rvcmllcy4NCj4+PiBUaGlzIGRyYWZ0IGlzIGEg d29yayBpdGVtIG9mIHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lvbg0KPj4+Q29udHJv bCBXRyBvZiB0aGUgSUVURi4NCj4+Pg0KPj4+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogTmVn b3RpYXRpbmcgU1JUUCBhbmQgUlRDUCBGZWVkYmFjayB1c2luZyB0aGUNCj4+PlJUUC9BVlAgUHJv ZmlsZQ0KPj4+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQW5kcmV3IEh1dHRvbg0KPj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9sYW5kIEplc3NrZQ0KPj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgQWxhbiBKb2huc3Rvbg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg R29uemFsbyBTYWxndWVpcm8NCj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlcm5hcmQg QWJvYmENCj4+PiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6DQo+Pj5kcmFmdC1pZXRmLW1tdXNp Yy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9uLTAxLnR4dA0KPj4+ICAgICAgICAgUGFnZXMgICAg ICAgICAgIDogNw0KPj4+ICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNy0wOS0xNA0KPj4+ DQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRoZSB1 c2Ugb2YgdGhlIFNlY3VyZSBSZWFsLXRpbWUNCj4+PnRyYW5zcG9ydA0KPj4+ICAgIHByb3RvY29s IChTUlRQKSBbUkZDMzcxMV0uIGNhbiBiZSBuZWdvdGlhdGVkIHVzaW5nIHRoZSBSVFAvQVZQDQo+ Pj4oQXVkaW8NCj4+PiAgICBWaWRlbyBQcm9maWxlKSBkZWZpbmVkIGluIFtSRkMzNTUxXS4gIFN1 Y2ggYSBtZWNoYW5pc20gaXMgdXNlZCB0bw0KPj4+ICAgIHByb3ZpZGUgYSBtZWFucyBmb3IgZW5j cnlwdGVkIG1lZGlhIHRvIGJlIHVzZWQgaW4gZW52aXJvbm1lbnRzIHdoZXJlDQo+Pj4gICAgc3Vw cG9ydCBmb3IgZW5jcnlwdGlvbiBpcyBub3Qga25vd24gaW4gYWR2YW5jZSwgYW5kIG5vdCByZXF1 aXJlZC4NCj4+PiAgICBUaGUgc2FtZSBtZWNoYW5pc20gaXMgYWxzbyBhcHBsaWVkIHRvIG5lZ290 aWF0aW9uIG9mIHRoZSBFeHRlbmRlZA0KPj4+UlRQDQo+Pj4gICAgUHJvZmlsZSBmb3IgUmVhbC10 aW1lIFRyYW5zcG9ydCBDb250cm9sIFByb3RvY29sIEJhc2VkIEZlZWRiYWNrDQo+Pj4oUlRQLw0K Pj4+ICAgIEFWUEYpIFtSRkM0NTg1XS4NCj4+Pg0KPj4+DQo+Pj4gVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+Pj4gDQo+Pj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290 DQo+Pj5pYXQNCj4+Pmlvbi8NCj4+Pg0KPj4+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCj4+PiANCj4+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW8NCj4+Pm4tMA0KPj4+MQ0K Pj4+IA0KPj4+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LW1tdXNpYy1vcHBvcnR1bmlzdGljLQ0KPj4+bmVnDQo+Pj5vdGlhdGlvbi0wMQ0KPj4+DQo+Pj4g QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+IA0K Pj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLW9w cG9ydHVuaXN0aWMtbmVnbw0KPj4+dGlhDQo+Pj50aW9uLTAxDQo+Pj4NCj4+Pg0KPj4+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mDQo+Pj5zdWJtaXNzaW9uICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0DQo+Pj50b29scy5pZXRmLm9yZy4NCj4+Pg0KPj4+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+PiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+ Pj4gbW11c2ljQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pm1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+bW11c2ljQGlldGYub3JnDQo+Pmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+DQoNCg== From nobody Fri Sep 15 11:40:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7321335D1; Fri, 15 Sep 2017 11:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZFGoTU1Ra4V; Fri, 15 Sep 2017 11:40:40 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B38133044; Fri, 15 Sep 2017 11:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=952; q=dns/txt; s=iport; t=1505500840; x=1506710440; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=qckc0PYtA+ot/cxGSzcnCIkBLMOszNU4PZfDhcwjmMQ=; b=LSl6M+3j2P6G0qlSHveVZ0vBY4BPF6W46+S9p8ZivLXwLCLsvPRpgj2h GpwYYy29Y0CmfQpeHdOP9/Oi+xkNB1Gvcd7f/qbB0GtovUDvd+BKgmuxJ qKzcAMQ58bDiE73QdsriflMJic3f99xY595tHTQ1da5uxJuJEQbsiofFq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AQB2HbxZ/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieDdZoTgUkrmDkKGAuESk8ChCpXAQIBAQEBAQJrKIUZAQE?= =?us-ascii?q?BAwEBIQ8BBTYLEAsYAgImAgInMAYNBgIBAYoiDRCsBIIniy4BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEbBYEOgh2CAoFQgWMrgn2IC4JgBaEFlFWCE4Vqg1qFWIFJlTSBOVe?= =?us-ascii?q?BDVMkFUmFGRyCAyQ2AYkUAQEB?= X-IronPort-AV: E=Sophos;i="5.42,398,1500940800"; d="scan'208";a="3562440" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 18:40:39 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8FIec6a018328; Fri, 15 Sep 2017 18:40:38 GMT From: Flemming Andreasen To: mmusic Cc: "draft-ietf-mmusic-trickle-ice-sip@ietf.org" References: <50b57d8c-127d-419d-9da3-7141adf13402@cisco.com> Message-ID: Date: Fri, 15 Sep 2017 14:41:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <50b57d8c-127d-419d-9da3-7141adf13402@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-trickle-ice-sip-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 18:40:41 -0000 The WGLC has ended, however we did not receive any comments from anybody. If you reviewed the draft (or a recent version of it) and believe the draft is ready to move forward, please send a note to that effect. Thanks -- Flemming On 8/30/17 4:21 PM, Flemming Andreasen wrote: > Greetings MMUSIC > > This is to announce a 2 week WGLC on the  draft: > > https://www.ietf.org/id/draft-ietf-mmusic-trickle-ice-sip-08.txt > > as Proposed Standard. Please review and provide any comments you may > have on the document by Wednesday, September 13, 2017. Comments should > be sent to the document authors and the MMUSIC WG list. If you review > the document but do not have any comments, please send a note to that > effect as well. > > Thanks > > -- Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Sep 15 14:02:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607CB134217 for ; Fri, 15 Sep 2017 14:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxbGvV8F9Mz8 for ; Fri, 15 Sep 2017 14:02:18 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C293132A05 for ; Fri, 15 Sep 2017 14:02:18 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id v72so2165438ywa.3 for ; Fri, 15 Sep 2017 14:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CquBeZcFRJ67+sJIkYTeuVjYItqBfa3unp/1amYvrek=; b=um+aWCNHhLqiiEQDlEnW7mUHbBm0FbzbTLQc8hN7uiC3EMWWgBwKBnrWq5fi+ECKAL V43/CG9kE6sfzCMC8LZOnv4hxJcMCMOxutnEcc9ji32ssnjoZss4pZopEHMT5+LQMUNL k+1FXIaqhppTBzPpmIR5zMUOXk0fczyU+us8odPYi9eQQuguPXw3BEOG0DGXnYu0Z3j/ DKLMTCLNcZwh3x7BIez7zoIVFYVgt01w/763kJ641NgvXYifcjQ3nBioaISx8Sdern3O RQI86l1PjNQW+Ps7sS9wJaw47trrbnVN3uFE9UJDN8DvzZQ3+gxJVZ1NSw7/bpLrBjYV qjJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CquBeZcFRJ67+sJIkYTeuVjYItqBfa3unp/1amYvrek=; b=cMJT5IwWbItidxYPzX6WjKbWsty7VMsK5r7J0XpCDqnwO+KC/8a2TC0txGTwdYpcHR oA9vitON8I4KuzJ1P/yICH5Lcx20Sn68jGfsgZSpMJrSZSrtU/h2FXXA251DSyG/ItTE KmARtyCQt/1GrG0oOnLjmheGJqP4b9RLOXrMx7Nl0KyuKPt//XQeVpk8kk6LRmoW1UGq dFeQAHEKnFFYYSPwj2gB8wDJkLqiYUZ8ci24bn0Gwxjw7qA09pJcDbsE8V5fuy5akUIY DV8PYNoSl33YnjSUOVEc2V9QPt+iVIBPI4h7OxnFkTI3yLVTtLXI4zqmWwu6tfj79U2M YKGw== X-Gm-Message-State: AHPjjUi8m4F0rhz0MU2AoD6uYf1tSEVmYwFX2aeRoqCEY9vqkBQTfKsb RafD7OdFqP69peujnSyJW5IZHRO2qDVL4CEkECSdpg== X-Google-Smtp-Source: AOwi7QCAleZRx3NUSnWNb+leDNkpHvC/8XjYgaBFaRS2dksi653eAoXY1mF4NdJNipqdwOPYlCb6kZqGTfUqMwSYTvQ= X-Received: by 10.37.183.147 with SMTP id n19mr21072476ybh.269.1505509337046; Fri, 15 Sep 2017 14:02:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.80.133 with HTTP; Fri, 15 Sep 2017 14:02:16 -0700 (PDT) In-Reply-To: References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> From: "Ali C. Begen" Date: Sat, 16 Sep 2017 00:02:16 +0300 Message-ID: To: Christer Holmberg Cc: Eric Rescorla , Colin Perkins , mmusic WG , Paul Kyzivat Content-Type: multipart/alternative; boundary="089e082298483dc559055940b592" Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:02:20 -0000 --089e082298483dc559055940b592 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi guys, Here is the proposed text for 5.12 based on the comments so far: 5.12. Encryption Keys ("k=3D") k=3D k=3D: The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. It is inc= luded in this document for legacy reasons. One MUST NOT include a "k=3D" line in an SDP, and MUST discard it if it is received in an SDP. If we are good with this, I will revise the draft and we will go for WGLC. Thanks. -acbegen On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I support the approach below too. > > However, I think we should have a little more text: saying that k=3D is > included for legacy reasons, that one must not include it in SDP, and if > received must accept and discard it. > > =E2=80=A6or something like that. > > Regards, > > Christer > > From: mmusic on behalf of Eric Rescorla < > ekr@rtfm.com> > Date: Wednesday 13 September 2017 at 01:33 > To: Colin Perkins > Cc: "mmusic@ietf.org" , "pkyzivat@alum.mit.edu" < > pkyzivat@alum.mit.edu> > Subject: Re: [MMUSIC] k=3D and draft-ietf-mmusic-rfc4566bis > > This seems like a fine resolution to me. > > On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins wrote: > >> >> > On 12 Sep 2017, at 16:42, Paul Kyzivat wrote: >> > >> > On 9/12/17 10:03 AM, Cullen Jennings wrote: >> >> First, I don't feel strongly about this and glad to go with whatever >> Colin wants ... but what I was thinking .... >> >> k=3D is still defined by RFC4566 and things that implement RFC4566 st= ill >> use it. I don't think we have an IANA table for this but if we do, the I= ANA >> registry still lists it with the reference for it as RFC4566. >> >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k= =3D >> one way or another. If something that implements RFCAAAA receives a k=3D >> line, it gets treated just like any other unknown line and is ignored. >> >> There not enough advice on how to use the k=3D stuff to expect >> interoperable implementation of any type of security that the IETF would >> currently consider acceptable to publish as a standard. Anyone who uses = k=3D >> is very unlikely to be upgrading their software to RFCAAAA. I just don't >> see anything good that comes of putting this in the new RFC and it just >> adds to the confusion of how to secure RTP. >> > >> > One thing: if all mention of k=3D is removed from the bis, then in the >> (far) someone who is defining a new line might choose k=3D for it. >> (Admittedly this is pretty far fetched.) >> > >> > I think a cleaner way to handle this would be to deprecate k=3D in the >> bis. >> >> I=E2=80=99d not object if the text in 4566bis was changed to: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 5.12. Encryption Keys ("k=3D") >> >> k=3D >> k=3D: >> >> >> The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. >> >> 5.13. Attributes (=E2=80=9Ca=3D=E2=80=9C) >> =E2=80=A6 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> =E2=80=A6or something similar. I just don=E2=80=99t think we can remove = it entirely. >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e082298483dc559055940b592 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi guys,

Here is the proposed text for 5.12 based o= n the comments so far:

5.12.=C2=A0 Encryption Keys ("k=3D"= )

=C2=A0 =C2=A0 =C2=A0 k=3D<method>
=C2=A0 =C2=A0 =C2=A0 k= =3D<method>:<encryption key>

The =E2=80=9Ck=3D=E2=80=9C = line is obsolete and MUST NOT be used. It is included in this document for = legacy reasons. One MUST NOT include a "k=3D" line in an SDP, and= MUST discard it if it is received in an SDP.=C2=A0

If w= e are good with this, I will revise the draft and we will go for WGLC.

Thanks.
-acbegen

<= div class=3D"gmail_extra">
On Wed, Sep 13, 20= 17 at 12:58 PM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Hi,

I support the approach below too.

However, I think we should have a little more text: saying that k=3D i= s included for legacy reasons, that one must not include it in SDP, and if = received must accept and discard it.

=E2=80=A6or something like that.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Eric Rescorla <ekr@rtfm.com>
Date: Wednesday 13 September 2017 a= t 01:33
To: Colin Perkins <csp@csperkins.org>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pky= zivat@alum.mit.edu>
Subject: Re: [MMUSIC] k=3D and draf= t-ietf-mmusic-rfc4566bis

This seems like a fine resolution to me.

On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <= span dir=3D"ltr"> <csp@csperkins.or= g> wrote:

> On 12 Sep 2017, at 16:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
> On 9/12/17 10:03 AM, Cullen Jennings wrote:
>> First, I don't feel strongly about this and glad to go with wh= atever Colin wants ... but what I was thinking ....
>> k=3D is still defined by RFC4566 and things that implement RFC4566= still use it. I don't think we have an IANA table for this but if we d= o, the IANA registry still lists it with the reference for it as RFC4566. >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention = k=3D one way or another. If something that implements RFCAAAA receives a k= =3D line, it gets treated just like any other unknown line and is ignored.<= br> >> There not enough advice on how to use the k=3D stuff to expect int= eroperable implementation of any type of security that the IETF would curre= ntly consider acceptable to publish as a standard. Anyone who uses k=3D is = very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of putting this = in the new RFC and it just adds to the confusion of how to secure RTP.
>
> One thing: if all mention of k=3D is removed from the bis, then in the= (far) someone who is defining a new line might choose k=3D for it. (Admitt= edly this is pretty far fetched.)
>
> I think a cleaner way to handle this would be to deprecate k=3D in the= bis.

I=E2=80=99d not object if the text in 4566bis was changed to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.12.=C2=A0 Encryption Keys ("k=3D")

=C2=A0 =C2=A0 =C2=A0 k=3D<method>
=C2=A0 =C2=A0 =C2=A0 k=3D<method>:<encryption key>


=C2=A0 The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used.
5.13.=C2=A0 Attributes (=E2=80=9Ca=3D=E2=80=9C)
=E2=80=A6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=E2=80=A6or something similar. I just don=E2=80=99t think we can remove it = entirely.


--
Colin Perkins
htt= ps://csperkins.org/




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


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

--089e082298483dc559055940b592-- From nobody Fri Sep 15 14:13:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EBF133209 for ; Fri, 15 Sep 2017 14:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZyBke51bzGd for ; Fri, 15 Sep 2017 14:13:36 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 8CECC1341FD for ; Fri, 15 Sep 2017 14:13:36 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id sxvXdV0TOOFGWsxvbd0pQH; Fri, 15 Sep 2017 21:13:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1505510015; bh=Yow4QRWRBbnN+gd119TH296xqnprIBHNcGNPMnXWwTg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Y1qfE0TpVo9kQMv0R3TW9jQop9JqDrGnz9ofHstKoWIDqEEUqQEJt8C4AMfkbcGy0 q6Ox94BqpbTaxRj/VbAYonFpzlTNzEhbNWFQ1hrwGzCoZboxhYbrc+/aEVr/UlUOWM 41LIjiD84ZXDdjr4gg5fcQ2VeCw86pfqOlSNuFSda5w77EpcZ/LUPf9MyPd/BbFeHV BEJOqccDYf+nuGO+zcErjbx2dO2cxsx6KeeIrdbxyv3iYgiNEjQUGhE80VK85t4tkJ ObRTLmLIEDJQXDJ7C6DWlFx3z8Z2gnO6GsYbC/dRa+Ww/L0VW2ZHZVrJO0dNnojoKV LVpVyYyLqCj1w== Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-13v.sys.comcast.net with SMTP id sxvadX97lZOPRsxvbdvlwA; Fri, 15 Sep 2017 21:13:35 +0000 To: mmusic@ietf.org References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> From: Paul Kyzivat Message-ID: <02f5f5d4-f541-fd7a-3bb0-e45c0ea7af4a@comcast.net> Date: Fri, 15 Sep 2017 17:13:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFGzZIcA9nf/j8dwsap5WP0CbbsVlgHFj5NKy6U0umNrxDpiHM61/2gMffqGrxsagwSfMGtbLBonXZ9Ry7IfsIIwsPfAWHCvTpJHet0R0wJ8DfKnDMfC 2NzPuRxwC67cR+IPvXN9wLrNLjK63n8PG+yrl/g7ULzI5KD0wN5kk2qZI9yarb/na+TIoZwYOkaAYA== Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:13:38 -0000 WFM On 9/15/17 5:02 PM, Ali C. Begen wrote: > Hi guys, > > Here is the proposed text for 5.12 based on the comments so far: > > 5.12.  Encryption Keys ("k=") > >       k= >       k=: > > The “k=“ line is obsolete and MUST NOT be used. It is included in this > document for legacy reasons. One MUST NOT include a "k=" line in an SDP, > and MUST discard it if it is received in an SDP. > > If we are good with this, I will revise the draft and we will go for WGLC. > > Thanks. > -acbegen > > > On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg > > > wrote: > > Hi, > > I support the approach below too. > > However, I think we should have a little more text: saying that k= > is included for legacy reasons, that one must not include it in SDP, > and if received must accept and discard it. > > …or something like that. > > Regards, > > Christer > > From: mmusic > on behalf of Eric Rescorla > > > Date: Wednesday 13 September 2017 at 01:33 > To: Colin Perkins > > Cc: "mmusic@ietf.org " >, "pkyzivat@alum.mit.edu > " > > Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis > > This seems like a fine resolution to me. > > On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins > wrote: > > > > On 12 Sep 2017, at 16:42, Paul Kyzivat > wrote: > > > > On 9/12/17 10:03 AM, Cullen Jennings wrote: > >> First, I don't feel strongly about this and glad to go with whatever Colin wants ... but what I was thinking .... > >> k= is still defined by RFC4566 and things that implement RFC4566 still use it. I don't think we have an IANA table for this but if we do, the IANA registry still lists it with the reference for it as RFC4566. > >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k= one way or another. If something that implements RFCAAAA receives a k= line, it gets treated just like any other unknown line and is ignored. > >> There not enough advice on how to use the k= stuff to expect interoperable implementation of any type of security that the IETF would currently consider acceptable to publish as a standard. Anyone who uses k= is very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of > putting this in the new RFC and it just adds to the confusion of > how to secure RTP. > > > > One thing: if all mention of k= is removed from the bis, then in the (far) someone who is defining a new line might choose k= for it. (Admittedly this is pretty far fetched.) > > > > I think a cleaner way to handle this would be to deprecate k= in the bis. > > I’d not object if the text in 4566bis was changed to: > > ================ > 5.12.  Encryption Keys ("k=") > >       k= >       k=: > > >   The “k=“ line is obsolete and MUST NOT be used. > > 5.13.  Attributes (“a=“) > … > ================ > > …or something similar. I just don’t think we can remove it entirely. > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Sep 15 14:19:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C162A134217 for ; Fri, 15 Sep 2017 14:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4xu9Ris4RUo for ; Fri, 15 Sep 2017 14:19:06 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A09134216 for ; Fri, 15 Sep 2017 14:19:05 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id n69so11524044ioi.5 for ; Fri, 15 Sep 2017 14:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+tvODxgCgZmJcbL6N4fkyWe++THa/peImYupe5hGj3k=; b=RAtzlFtX2tDAwlLwGPHB5qkGQWTgrxLHbFCZfqnYdNsYiDEb6tuwEmNDKBkScu39NT fnLmJap5Uv7zSarv/DjDkUtnlu/q08QzhUpGijZm8XnXxwqobMAIf92Zor718T0rYfe8 1DDwI1COkV7E7lXg0i3MujbptoHmxHPOosS8Ii/Y7FdI9tNPvPe787Q/S8uhu2g+w3uK xPZZodnxI+3QTsGQ9aV8qtwXj5spTUDetagNQiMbG2JZ1FnWqLr1kfG3OhxWKAWm8USA UXxg2YNFSR8SBRxzD1/YvanMrMz69rtts32MQ2+g5D2ekyTtXk+zpvPxq3nSgxxa+fWT bzig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+tvODxgCgZmJcbL6N4fkyWe++THa/peImYupe5hGj3k=; b=hhmh2qVE69r+u9eZ7kRZihve6nPQZ2A4FsTSilm+NGyVIvM/m6vibZbj81Hy+GSZLE qqJ8h971e0VqPWtDSUs75cJLDguR3hM4ujLH0RE95D+iFhInO4WMmW2IO+Dc19P2wbs6 E/ijKgCpYV20MBiO/u+KQr4siyoEhMVcS91OJ+e2Cy498V0XtH9VNv6ciRZmhl2NDkAo vwS4ZOIJnjAh2QQeExRMwED0dN5nnQ2L+9KN6M8nvYTdGnj6hNb/5LjwNZvhqzAjGNDK 2hqPc72QxQb+O7ZC/1umVif3RJxzZU/vxwrJB4U9cMpJgxQWczNFy4FoqVhgJpBWdW2u lFMw== X-Gm-Message-State: AHPjjUidIZdna1hr11rdL/ouqU8ZLXiJTGfoywWYmst06X3LgGDE6ofP fdhXS5vDzNFTyOEPGGs67TtCNH7m1uxsDi8OjeUUrg== X-Google-Smtp-Source: AOwi7QA1l22f/90bo78ZrHkx7JsZ09ZH/au1xiZib89tybsuhWPM4B1//UwpLJy0uMNGS22nh0TneJTleYFHxp8XbiQ= X-Received: by 10.202.59.87 with SMTP id i84mr3457785oia.166.1505510344506; Fri, 15 Sep 2017 14:19:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.168.183.15 with HTTP; Fri, 15 Sep 2017 14:18:23 -0700 (PDT) In-Reply-To: References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> From: Eric Rescorla Date: Fri, 15 Sep 2017 14:18:23 -0700 Message-ID: To: "Ali C. Begen" Cc: Christer Holmberg , Colin Perkins , mmusic WG , Paul Kyzivat Content-Type: multipart/alternative; boundary="001a113cf8d04a65d8055940f126" Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:19:09 -0000 --001a113cf8d04a65d8055940f126 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable LGTM On Fri, Sep 15, 2017 at 2:02 PM, Ali C. Begen wrote: > Hi guys, > > Here is the proposed text for 5.12 based on the comments so far: > > 5.12. Encryption Keys ("k=3D") > > k=3D > k=3D: > > The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. It is i= ncluded in this > document for legacy reasons. One MUST NOT include a "k=3D" line in an SDP= , > and MUST discard it if it is received in an SDP. > > If we are good with this, I will revise the draft and we will go for WGLC= . > > Thanks. > -acbegen > > > On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> I support the approach below too. >> >> However, I think we should have a little more text: saying that k=3D is >> included for legacy reasons, that one must not include it in SDP, and if >> received must accept and discard it. >> >> =E2=80=A6or something like that. >> >> Regards, >> >> Christer >> >> From: mmusic on behalf of Eric Rescorla < >> ekr@rtfm.com> >> Date: Wednesday 13 September 2017 at 01:33 >> To: Colin Perkins >> Cc: "mmusic@ietf.org" , "pkyzivat@alum.mit.edu" < >> pkyzivat@alum.mit.edu> >> Subject: Re: [MMUSIC] k=3D and draft-ietf-mmusic-rfc4566bis >> >> This seems like a fine resolution to me. >> >> On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins wrote= : >> >>> >>> > On 12 Sep 2017, at 16:42, Paul Kyzivat wrote: >>> > >>> > On 9/12/17 10:03 AM, Cullen Jennings wrote: >>> >> First, I don't feel strongly about this and glad to go with whatever >>> Colin wants ... but what I was thinking .... >>> >> k=3D is still defined by RFC4566 and things that implement RFC4566 >>> still use it. I don't think we have an IANA table for this but if we do= , >>> the IANA registry still lists it with the reference for it as RFC4566. >>> >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k= =3D >>> one way or another. If something that implements RFCAAAA receives a k= =3D >>> line, it gets treated just like any other unknown line and is ignored. >>> >> There not enough advice on how to use the k=3D stuff to expect >>> interoperable implementation of any type of security that the IETF woul= d >>> currently consider acceptable to publish as a standard. Anyone who uses= k=3D >>> is very unlikely to be upgrading their software to RFCAAAA. I just don'= t >>> see anything good that comes of putting this in the new RFC and it just >>> adds to the confusion of how to secure RTP. >>> > >>> > One thing: if all mention of k=3D is removed from the bis, then in th= e >>> (far) someone who is defining a new line might choose k=3D for it. >>> (Admittedly this is pretty far fetched.) >>> > >>> > I think a cleaner way to handle this would be to deprecate k=3D in th= e >>> bis. >>> >>> I=E2=80=99d not object if the text in 4566bis was changed to: >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> 5.12. Encryption Keys ("k=3D") >>> >>> k=3D >>> k=3D: >>> >>> >>> The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. >>> >>> 5.13. Attributes (=E2=80=9Ca=3D=E2=80=9C) >>> =E2=80=A6 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> =E2=80=A6or something similar. I just don=E2=80=99t think we can remove= it entirely. >>> >>> >>> -- >>> Colin Perkins >>> https://csperkins.org/ >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --001a113cf8d04a65d8055940f126 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM

On Fri, Sep 15, 2017 at 2:02 PM, Ali C. Begen &= lt;ali.begen= @networked.media> wrote:
Hi guys,

Here is the proposed text for 5.12 based on = the comments so far:

5.12.=C2=A0 Encryption Keys (&= quot;k=3D")

=C2=A0 =C2=A0 =C2=A0 k=3D<method>
=C2=A0 = =C2=A0 =C2=A0 k=3D<method>:<encryption key>

The = =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. It is include= d in this document for legacy reasons. One MUST NOT include a "k=3D&qu= ot; line in an SDP, and MUST discard it if it is received in an SDP.=C2=A0<= div>
If we are good with this, I will revise the draft and we= will go for WGLC.

Thanks.
-acbegen


On Wed, Sep 13, 2017 at 12:58 = PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

I support the approach below too.

However, I think we should have a little more text: saying that k=3D i= s included for legacy reasons, that one must not include it in SDP, and if = received must accept and discard it.

=E2=80=A6or something like that.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Eric Rescorla <ekr@rtfm.com>
Date: Wednesday 13 September 2017 a= t 01:33
To: Colin Perkins <csp@csperkins.org>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pky= zivat@alum.mit.edu>
Subject: Re: [MMUSIC] k=3D and draf= t-ietf-mmusic-rfc4566bis

This seems like a fine resolution to me.

On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <= span dir=3D"ltr"> <csp@csperkins.or= g> wrote:

> On 12 Sep 2017, at 16:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
> On 9/12/17 10:03 AM, Cullen Jennings wrote:
>> First, I don't feel strongly about this and glad to go with wh= atever Colin wants ... but what I was thinking ....
>> k=3D is still defined by RFC4566 and things that implement RFC4566= still use it. I don't think we have an IANA table for this but if we d= o, the IANA registry still lists it with the reference for it as RFC4566. >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention = k=3D one way or another. If something that implements RFCAAAA receives a k= =3D line, it gets treated just like any other unknown line and is ignored.<= br> >> There not enough advice on how to use the k=3D stuff to expect int= eroperable implementation of any type of security that the IETF would curre= ntly consider acceptable to publish as a standard. Anyone who uses k=3D is = very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of putting this = in the new RFC and it just adds to the confusion of how to secure RTP.
>
> One thing: if all mention of k=3D is removed from the bis, then in the= (far) someone who is defining a new line might choose k=3D for it. (Admitt= edly this is pretty far fetched.)
>
> I think a cleaner way to handle this would be to deprecate k=3D in the= bis.

I=E2=80=99d not object if the text in 4566bis was changed to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.12.=C2=A0 Encryption Keys ("k=3D")

=C2=A0 =C2=A0 =C2=A0 k=3D<method>
=C2=A0 =C2=A0 =C2=A0 k=3D<method>:<encryption key>


=C2=A0 The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used.
5.13.=C2=A0 Attributes (=E2=80=9Ca=3D=E2=80=9C)
=E2=80=A6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=E2=80=A6or something similar. I just don=E2=80=99t think we can remove it = entirely.


--
Colin Perkins
htt= ps://csperkins.org/




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


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


--001a113cf8d04a65d8055940f126-- From nobody Sat Sep 16 01:17:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1913308C for ; Sat, 16 Sep 2017 01:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TStMbR3FMlzt for ; Sat, 16 Sep 2017 01:17:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7A9E2126B6D for ; Sat, 16 Sep 2017 01:17:29 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-1e-59bcde17a6de Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 03.3A.21299.71EDCB95; Sat, 16 Sep 2017 10:17:27 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Sat, 16 Sep 2017 10:17:27 +0200 From: Christer Holmberg To: "Ali C. Begen" CC: Eric Rescorla , Colin Perkins , mmusic WG , Paul Kyzivat Thread-Topic: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis Thread-Index: AQHTKIyuJzGoax9hl0ur9AF8dFJN8aKw3csAgABPUICAABvEgIAAYeUAgAAQ5QCAAPMpAIADql8AgADeH1A= Date: Sat, 16 Sep 2017 08:17:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562C2A53@ESESSMB109.ericsson.se> References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B562C2A53ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7pa74vT2RBgteGlgc/PaC2WL5yxOM Fiten2O3mLr8MYvFig0HWB1YPf6+/8DkMe3+fTaPJUt+MnnsWnaB3WPy4zbmANYoLpuU1JzM stQifbsErozFlycwFnxZx1jxvNexgXHBKsYuRk4OCQETidcXFzJ1MXJxCAkcYZT4+2ASG4Sz iFFixcnjQA4HB5uAhUT3P22QBhEBPYmJ12axgNQwC3QwSjxcNIMZJCEsYCnx8vc3RogiK4nf ax8zQ9hJEudPz2cFsVkEVCXaz/9hAbF5BXwl1r39DrXsFIvEplO97CDLOAUCJW4eqAGpYRQQ k/h+ag0TiM0sIC5x68l8JoirBSSW7DnPDGGLSrx8/I8VwlaSWLH9EiNEfb7E8l3nGSF2CUqc nPmEZQKjyCwko2YhKZuFpGwW0BXMApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFq cVJuupGxXmpRZnJxcX6eXl5qySZGYFQe3PJbdQfj5TeOhxgFOBiVeHgDb+yJFGJNLCuuzD3E KMHBrCTCm3UFKMSbklhZlVqUH19UmpNafIhRmoNFSZzXcd+FCCGB9MSS1OzU1ILUIpgsEwen VANjDE/uXG9317e5n4oMInZunbTpt/Ka2zpTajzazvR6L7N4xjBB+uUeIY2ticc63q7KlxPe ONVax/T6pzuTkqed1tzCOaFq4iUrRXbuVvX/Hxckf1PK156+hNnQ9RafFXsTwwbh16v3z4go O9RWcY25umbCu8mp++wadkqmPTPNuez6TcVdsEZNiaU4I9FQi7moOBEAg+65Q8YCAAA= Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 08:17:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562C2A53ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogQWxpIEMuIEJlZ2Vu IFttYWlsdG86YWxpLmJlZ2VuQG5ldHdvcmtlZC5tZWRpYV0NClNlbnQ6IDE1IFNlcHRlbWJlciAy MDE3IDIzOjAyDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4NCkNjOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBDb2xpbiBQZXJraW5z IDxjc3BAY3NwZXJraW5zLm9yZz47IG1tdXNpYyBXRyA8bW11c2ljQGlldGYub3JnPjsgUGF1bCBL eXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gaz0g YW5kIGRyYWZ0LWlldGYtbW11c2ljLXJmYzQ1NjZiaXMNCg0KSGkgZ3V5cywNCg0KSGVyZSBpcyB0 aGUgcHJvcG9zZWQgdGV4dCBmb3IgNS4xMiBiYXNlZCBvbiB0aGUgY29tbWVudHMgc28gZmFyOg0K DQo1LjEyLiAgRW5jcnlwdGlvbiBLZXlzICgiaz0iKQ0KDQogICAgICBrPTxtZXRob2Q+DQogICAg ICBrPTxtZXRob2Q+OjxlbmNyeXB0aW9uIGtleT4NCg0KVGhlIOKAnGs94oCcIGxpbmUgaXMgb2Jz b2xldGUgYW5kIE1VU1QgTk9UIGJlIHVzZWQuIEl0IGlzIGluY2x1ZGVkIGluIHRoaXMgZG9jdW1l bnQgZm9yIGxlZ2FjeSByZWFzb25zLiBPbmUgTVVTVCBOT1QgaW5jbHVkZSBhICJrPSIgbGluZSBp biBhbiBTRFAsIGFuZCBNVVNUIGRpc2NhcmQgaXQgaWYgaXQgaXMgcmVjZWl2ZWQgaW4gYW4gU0RQ Lg0KDQpJZiB3ZSBhcmUgZ29vZCB3aXRoIHRoaXMsIEkgd2lsbCByZXZpc2UgdGhlIGRyYWZ0IGFu ZCB3ZSB3aWxsIGdvIGZvciBXR0xDLg0KDQpUaGFua3MuDQotYWNiZWdlbg0KDQoNCk9uIFdlZCwg U2VwIDEzLCAyMDE3IGF0IDEyOjU4IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ PiB3cm90ZToNCkhpLA0KDQpJIHN1cHBvcnQgdGhlIGFwcHJvYWNoIGJlbG93IHRvby4NCg0KSG93 ZXZlciwgSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIGxpdHRsZSBtb3JlIHRleHQ6IHNheWluZyB0 aGF0IGs9IGlzIGluY2x1ZGVkIGZvciBsZWdhY3kgcmVhc29ucywgdGhhdCBvbmUgbXVzdCBub3Qg aW5jbHVkZSBpdCBpbiBTRFAsIGFuZCBpZiByZWNlaXZlZCBtdXN0IGFjY2VwdCBhbmQgZGlzY2Fy ZCBpdC4NCg0K4oCmb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KRnJvbTogbW11c2ljIDxtbXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bW11c2lj LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPG1haWx0bzpla3JAcnRmbS5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5IDEzIFNlcHRlbWJlciAy MDE3IGF0IDAxOjMzDQpUbzogQ29saW4gUGVya2lucyA8Y3NwQGNzcGVya2lucy5vcmc8bWFpbHRv OmNzcEBjc3BlcmtpbnMub3JnPj4NCkNjOiAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNA aWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+PiwgInBr eXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1PiIgPHBreXpp dmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4NClN1YmplY3Q6 IFJlOiBbTU1VU0lDXSBrPSBhbmQgZHJhZnQtaWV0Zi1tbXVzaWMtcmZjNDU2NmJpcw0KDQpUaGlz IHNlZW1zIGxpa2UgYSBmaW5lIHJlc29sdXRpb24gdG8gbWUuDQoNCk9uIFR1ZSwgU2VwIDEyLCAy MDE3IGF0IDI6MzIgUE0sIENvbGluIFBlcmtpbnMgPGNzcEBjc3BlcmtpbnMub3JnPG1haWx0bzpj c3BAY3NwZXJraW5zLm9yZz4+IHdyb3RlOg0KDQo+IE9uIDEyIFNlcCAyMDE3LCBhdCAxNjo0Miwg UGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0u bWl0LmVkdT4+IHdyb3RlOg0KPg0KPiBPbiA5LzEyLzE3IDEwOjAzIEFNLCBDdWxsZW4gSmVubmlu Z3Mgd3JvdGU6DQo+PiBGaXJzdCwgSSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IHRoaXMgYW5k IGdsYWQgdG8gZ28gd2l0aCB3aGF0ZXZlciBDb2xpbiB3YW50cyAuLi4gYnV0IHdoYXQgSSB3YXMg dGhpbmtpbmcgLi4uLg0KPj4gaz0gaXMgc3RpbGwgZGVmaW5lZCBieSBSRkM0NTY2IGFuZCB0aGlu Z3MgdGhhdCBpbXBsZW1lbnQgUkZDNDU2NiBzdGlsbCB1c2UgaXQuIEkgZG9uJ3QgdGhpbmsgd2Ug aGF2ZSBhbiBJQU5BIHRhYmxlIGZvciB0aGlzIGJ1dCBpZiB3ZSBkbywgdGhlIElBTkEgcmVnaXN0 cnkgc3RpbGwgbGlzdHMgaXQgd2l0aCB0aGUgcmVmZXJlbmNlIGZvciBpdCBhcyBSRkM0NTY2Lg0K Pj4gVGhpcyBiaXMgZHJhZnQgYmVjb21lcyBhIG5ldyBSRkNBQUFBIGFuZCBSRkNBQUFBIGRvZXMg bm90IG1lbnRpb24gaz0gb25lIHdheSBvciBhbm90aGVyLiBJZiBzb21ldGhpbmcgdGhhdCBpbXBs ZW1lbnRzIFJGQ0FBQUEgcmVjZWl2ZXMgYSBrPSBsaW5lLCBpdCBnZXRzIHRyZWF0ZWQganVzdCBs aWtlIGFueSBvdGhlciB1bmtub3duIGxpbmUgYW5kIGlzIGlnbm9yZWQuDQo+PiBUaGVyZSBub3Qg ZW5vdWdoIGFkdmljZSBvbiBob3cgdG8gdXNlIHRoZSBrPSBzdHVmZiB0byBleHBlY3QgaW50ZXJv cGVyYWJsZSBpbXBsZW1lbnRhdGlvbiBvZiBhbnkgdHlwZSBvZiBzZWN1cml0eSB0aGF0IHRoZSBJ RVRGIHdvdWxkIGN1cnJlbnRseSBjb25zaWRlciBhY2NlcHRhYmxlIHRvIHB1Ymxpc2ggYXMgYSBz dGFuZGFyZC4gQW55b25lIHdobyB1c2VzIGs9IGlzIHZlcnkgdW5saWtlbHkgdG8gYmUgdXBncmFk aW5nIHRoZWlyIHNvZnR3YXJlIHRvIFJGQ0FBQUEuIEkganVzdCBkb24ndCBzZWUgYW55dGhpbmcg Z29vZCB0aGF0IGNvbWVzIG9mIHB1dHRpbmcgdGhpcyBpbiB0aGUgbmV3IFJGQyBhbmQgaXQganVz dCBhZGRzIHRvIHRoZSBjb25mdXNpb24gb2YgaG93IHRvIHNlY3VyZSBSVFAuDQo+DQo+IE9uZSB0 aGluZzogaWYgYWxsIG1lbnRpb24gb2Ygaz0gaXMgcmVtb3ZlZCBmcm9tIHRoZSBiaXMsIHRoZW4g aW4gdGhlIChmYXIpIHNvbWVvbmUgd2hvIGlzIGRlZmluaW5nIGEgbmV3IGxpbmUgbWlnaHQgY2hv b3NlIGs9IGZvciBpdC4gKEFkbWl0dGVkbHkgdGhpcyBpcyBwcmV0dHkgZmFyIGZldGNoZWQuKQ0K Pg0KPiBJIHRoaW5rIGEgY2xlYW5lciB3YXkgdG8gaGFuZGxlIHRoaXMgd291bGQgYmUgdG8gZGVw cmVjYXRlIGs9IGluIHRoZSBiaXMuDQoNCknigJlkIG5vdCBvYmplY3QgaWYgdGhlIHRleHQgaW4g NDU2NmJpcyB3YXMgY2hhbmdlZCB0bzoNCg0KPT09PT09PT09PT09PT09PQ0KNS4xMi4gIEVuY3J5 cHRpb24gS2V5cyAoIms9IikNCg0KICAgICAgaz08bWV0aG9kPg0KICAgICAgaz08bWV0aG9kPjo8 ZW5jcnlwdGlvbiBrZXk+DQoNCg0KICBUaGUg4oCcaz3igJwgbGluZSBpcyBvYnNvbGV0ZSBhbmQg TVVTVCBOT1QgYmUgdXNlZC4NCg0KNS4xMy4gIEF0dHJpYnV0ZXMgKOKAnGE94oCcKQ0K4oCmDQo9 PT09PT09PT09PT09PT09DQoNCuKApm9yIHNvbWV0aGluZyBzaW1pbGFyLiBJIGp1c3QgZG9u4oCZ dCB0aGluayB3ZSBjYW4gcmVtb3ZlIGl0IGVudGlyZWx5Lg0KDQoNCi0tDQpDb2xpbiBQZXJraW5z DQpodHRwczovL2NzcGVya2lucy5vcmcvDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0 Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWls dG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B562C2A53ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Mb29rcyBnb29kLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gQWxpIEMuIEJlZ2VuIFttYWlsdG86YWxpLmJlZ2VuQG5ldHdvcmtlZC5tZWRp YV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxNSBTZXB0ZW1iZXIgMjAxNyAyMzowMjxicj4NCjxiPlRv OjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs7 IENvbGluIFBlcmtpbnMgJmx0O2NzcEBjc3BlcmtpbnMub3JnJmd0OzsgbW11c2ljIFdHICZsdDtt bXVzaWNAaWV0Zi5vcmcmZ3Q7OyBQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVk dSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIGs9IGFuZCBkcmFmdC1pZXRm LW1tdXNpYy1yZmM0NTY2YmlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgZ3V5cyw8YnI+DQo8YnI+DQpIZXJlIGlzIHRoZSBwcm9wb3NlZCB0ZXh0IGZvciA1LjEyIGJh c2VkIG9uIHRoZSBjb21tZW50cyBzbyBmYXI6PGJyPg0KPGJyPg0KNS4xMi4mbmJzcDsgRW5jcnlw dGlvbiBLZXlzICgmcXVvdDtrPSZxdW90Oyk8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBrPSZsdDttZXRob2QmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaz0mbHQ7bWV0aG9k Jmd0OzombHQ7ZW5jcnlwdGlvbiBrZXkmZ3Q7PGJyPg0KPGJyPg0KVGhlIOKAnGs94oCcIGxpbmUg aXMgb2Jzb2xldGUgYW5kIE1VU1QgTk9UIGJlIHVzZWQuIEl0IGlzIGluY2x1ZGVkIGluIHRoaXMg ZG9jdW1lbnQgZm9yIGxlZ2FjeSByZWFzb25zLiBPbmUgTVVTVCBOT1QgaW5jbHVkZSBhICZxdW90 O2s9JnF1b3Q7IGxpbmUgaW4gYW4gU0RQLCBhbmQgTVVTVCBkaXNjYXJkIGl0IGlmIGl0IGlzIHJl Y2VpdmVkIGluIGFuIFNEUC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPklmIHdlIGFyZSBnb29kIHdpdGggdGhpcywgSSB3aWxsIHJldmlzZSB0aGUg ZHJhZnQgYW5kIHdlIHdpbGwgZ28gZm9yIFdHTEMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1hY2JlZ2VuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBTZXAgMTMsIDIw MTcgYXQgMTI6NTggUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIHN1cHBvcnQgdGhlIGFwcHJvYWNoIGJlbG93 IHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+SG93ZXZlciwgSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIGxpdHRs ZSBtb3JlIHRleHQ6IHNheWluZyB0aGF0IGs9IGlzIGluY2x1ZGVkIGZvciBsZWdhY3kgcmVhc29u cywgdGhhdCBvbmUgbXVzdCBub3QgaW5jbHVkZSBpdCBpbiBTRFAsIGFuZCBpZiByZWNlaXZlZCBt dXN0IGFjY2VwdA0KIGFuZCBkaXNjYXJkIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7igKZvciBzb21ldGhpbmcg bGlrZSB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+bW11c2ljICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwv YT4mZ3Q7IG9uIGJlaGFsZiBvZiBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWty QHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+V2VkbmVzZGF5IDEzIFNlcHRlbWJlciAyMDE3IGF0IDAxOjMzPGJyPg0KPGI+VG86 IDwvYj5Db2xpbiBQZXJraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmci IHRhcmdldD0iX2JsYW5rIj5jc3BAY3NwZXJraW5zLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bW11c2ljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBo cmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+cGt5eml2 YXRAYWx1bS5taXQuZWR1PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFs dW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTU1VU0lDXSBrPSBhbmQgZHJhZnQtaWV0Zi1tbXVz aWMtcmZjNDU2NmJpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhp cyBzZWVtcyBsaWtlIGEgZmluZSByZXNvbHV0aW9uIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+T24gVHVlLCBTZXAgMTIs IDIwMTcgYXQgMjozMiBQTSwgQ29saW4gUGVya2lucyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNzcEBj c3BlcmtpbnMub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y3NwQGNzcGVya2lucy5vcmc8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQomZ3Q7IE9uIDEyIFNlcCAy MDE3LCBhdCAxNjo0MiwgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRA YWx1bS5taXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gOS8xMi8xNyAxMDowMyBBTSwgQ3VsbGVu IEplbm5pbmdzIHdyb3RlOjxicj4NCiZndDsmZ3Q7IEZpcnN0LCBJIGRvbid0IGZlZWwgc3Ryb25n bHkgYWJvdXQgdGhpcyBhbmQgZ2xhZCB0byBnbyB3aXRoIHdoYXRldmVyIENvbGluIHdhbnRzIC4u LiBidXQgd2hhdCBJIHdhcyB0aGlua2luZyAuLi4uPGJyPg0KJmd0OyZndDsgaz0gaXMgc3RpbGwg ZGVmaW5lZCBieSBSRkM0NTY2IGFuZCB0aGluZ3MgdGhhdCBpbXBsZW1lbnQgUkZDNDU2NiBzdGls bCB1c2UgaXQuIEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhbiBJQU5BIHRhYmxlIGZvciB0aGlzIGJ1 dCBpZiB3ZSBkbywgdGhlIElBTkEgcmVnaXN0cnkgc3RpbGwgbGlzdHMgaXQgd2l0aCB0aGUgcmVm ZXJlbmNlIGZvciBpdCBhcyBSRkM0NTY2Ljxicj4NCiZndDsmZ3Q7IFRoaXMgYmlzIGRyYWZ0IGJl Y29tZXMgYSBuZXcgUkZDQUFBQSBhbmQgUkZDQUFBQSBkb2VzIG5vdCBtZW50aW9uIGs9IG9uZSB3 YXkgb3IgYW5vdGhlci4gSWYgc29tZXRoaW5nIHRoYXQgaW1wbGVtZW50cyBSRkNBQUFBIHJlY2Vp dmVzIGEgaz0gbGluZSwgaXQgZ2V0cyB0cmVhdGVkIGp1c3QgbGlrZSBhbnkgb3RoZXIgdW5rbm93 biBsaW5lIGFuZCBpcyBpZ25vcmVkLjxicj4NCiZndDsmZ3Q7IFRoZXJlIG5vdCBlbm91Z2ggYWR2 aWNlIG9uIGhvdyB0byB1c2UgdGhlIGs9IHN0dWZmIHRvIGV4cGVjdCBpbnRlcm9wZXJhYmxlIGlt cGxlbWVudGF0aW9uIG9mIGFueSB0eXBlIG9mIHNlY3VyaXR5IHRoYXQgdGhlIElFVEYgd291bGQg Y3VycmVudGx5IGNvbnNpZGVyIGFjY2VwdGFibGUgdG8gcHVibGlzaCBhcyBhIHN0YW5kYXJkLiBB bnlvbmUgd2hvIHVzZXMgaz0gaXMgdmVyeSB1bmxpa2VseSB0byBiZSB1cGdyYWRpbmcgdGhlaXIg c29mdHdhcmUNCiB0byBSRkNBQUFBLiBJIGp1c3QgZG9uJ3Qgc2VlIGFueXRoaW5nIGdvb2QgdGhh dCBjb21lcyBvZiBwdXR0aW5nIHRoaXMgaW4gdGhlIG5ldyBSRkMgYW5kIGl0IGp1c3QgYWRkcyB0 byB0aGUgY29uZnVzaW9uIG9mIGhvdyB0byBzZWN1cmUgUlRQLjxicj4NCiZndDs8YnI+DQomZ3Q7 IE9uZSB0aGluZzogaWYgYWxsIG1lbnRpb24gb2Ygaz0gaXMgcmVtb3ZlZCBmcm9tIHRoZSBiaXMs IHRoZW4gaW4gdGhlIChmYXIpIHNvbWVvbmUgd2hvIGlzIGRlZmluaW5nIGEgbmV3IGxpbmUgbWln aHQgY2hvb3NlIGs9IGZvciBpdC4gKEFkbWl0dGVkbHkgdGhpcyBpcyBwcmV0dHkgZmFyIGZldGNo ZWQuKTxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgYSBjbGVhbmVyIHdheSB0byBoYW5kbGUg dGhpcyB3b3VsZCBiZSB0byBkZXByZWNhdGUgaz0gaW4gdGhlIGJpcy48YnI+DQo8YnI+DQpJ4oCZ ZCBub3Qgb2JqZWN0IGlmIHRoZSB0ZXh0IGluIDQ1NjZiaXMgd2FzIGNoYW5nZWQgdG86PGJyPg0K PGJyPg0KPT09PT09PT09PT09PT09PTxicj4NCjUuMTIuJm5ic3A7IEVuY3J5cHRpb24gS2V5cyAo JnF1b3Q7az0mcXVvdDspPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaz0mbHQ7bWV0 aG9kJmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGs9Jmx0O21ldGhvZCZndDs6Jmx0O2Vu Y3J5cHRpb24ga2V5Jmd0Ozxicj4NCjxicj4NCjxicj4NCiZuYnNwOyBUaGUg4oCcaz3igJwgbGlu ZSBpcyBvYnNvbGV0ZSBhbmQgTVVTVCBOT1QgYmUgdXNlZC48YnI+DQo8YnI+DQo1LjEzLiZuYnNw OyBBdHRyaWJ1dGVzICjigJxhPeKAnCk8YnI+DQrigKY8YnI+DQo9PT09PT09PT09PT09PT09PGJy Pg0KPGJyPg0K4oCmb3Igc29tZXRoaW5nIHNpbWlsYXIuIEkganVzdCBkb27igJl0IHRoaW5rIHdl IGNhbiByZW1vdmUgaXQgZW50aXJlbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxi cj4NCjxicj4NCi0tPGJyPg0KQ29saW4gUGVya2luczxicj4NCjxhIGhyZWY9Imh0dHBzOi8vY3Nw ZXJraW5zLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2NzcGVya2lucy5vcmcvPC9hPjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B562C2A53ESESSMB109erics_-- From nobody Sat Sep 16 04:38:06 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D95813219B; Sat, 16 Sep 2017 04:37:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150556187847.4892.13179419739455020059@ietfa.amsl.com> Date: Sat, 16 Sep 2017 04:37:58 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-23.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 11:37:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : SDP: Session Description Protocol Authors : Mark Handley Van Jacobson Colin Perkins Ali Begen Filename : draft-ietf-mmusic-rfc4566bis-23.txt Pages : 59 Date : 2017-09-16 Abstract: This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-23 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-23 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 Sat Sep 16 04:39:52 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FDF132D51 for ; Sat, 16 Sep 2017 04:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxtD40_aMfNI for ; Sat, 16 Sep 2017 04:39:47 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B08213292B for ; Sat, 16 Sep 2017 04:39:47 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id q80so2775746ywg.2 for ; Sat, 16 Sep 2017 04:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aTiWCQjhxw4cUtT7hAiSdRZETWNz2W9nyqWBUfP0cWY=; b=BzAWNnzgAl6mCRwmkeqOyRxtDpQvLpags31QlzTU94jvp8gY2nYow1YEmTjBl8LehK gU8SM/caLjXsFTFVHvRwlL3mJZjg9S7kgzOdMwaKOvLGwrrgz72EJedNlNXH/q6isDIK cfRMla1xsxFdkOsuC1iUGDeUVMo3PWyTl8OFg3O/qHJFbpJCh2tVDBsUv9Gcl/HIEIBs YX7XDwmDTErHZ0vtXcF55V/txZ17OLHHfSVzlSICDR5gxNQKRd6kix5G3qvt/YVs1BHp XjcNjpIaFjbZWDCetXFE1zMGxNOb4J82RA7rE3zUzyGDO/W+MtuKjeeuOhrDSJajMd6y tikQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aTiWCQjhxw4cUtT7hAiSdRZETWNz2W9nyqWBUfP0cWY=; b=PYeyzeO5OO3nr07yxoXfGwherd/QvYN2dgXNLf6VHegsdNTP5ssVUH8KMVaD2Mbrr+ issRGMtKX+dSzcAmXmHtDQQoaxsWBOavbW/7pyJlsYvtm6tvFJaz17KNebeofbm7Gx7s fLuEG7w4dpHU5y0qQa2nXZDsar0XwyPprxVFYfvWiYKu5DuMmmS957nfD/C78zgBzauq 0wu9QwGnuJfb60HUQSkMMG1Vwjp5hprwzL7ejOzHzot/pumvPdIu/JV7p9mIjUNrJ7Qq kHMwvNwzSXa2BB9rNz3Lkv0WxfltBAMth1ROUAfjewA7KQi4uGg5lLty/vchqX9rUPxN 3vFQ== X-Gm-Message-State: AHPjjUhLtf6bMIvF8zNrM+Gk+jTdt3HKdTH560ykfUSL9lugNifT9zUs gHMMZa/a9SoivesOV/J6SkUAIHaCFCogFxj4RqR00g== X-Google-Smtp-Source: ADKCNb5IKWsK3IoSq3g3e47kof2glcc6C6mBhjqzeW88chz4EK2HG9xG5DfDImRdwRSlw+xD7wTOY8EfUVpImddwBBs= X-Received: by 10.13.240.1 with SMTP id z1mr24131981ywe.331.1505561986855; Sat, 16 Sep 2017 04:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.80.133 with HTTP; Sat, 16 Sep 2017 04:39:46 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562C2A53@ESESSMB109.ericsson.se> References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B562C2A53@ESESSMB109.ericsson.se> From: "Ali C. Begen" Date: Sat, 16 Sep 2017 14:39:46 +0300 Message-ID: To: mmusic-chairs@tools.ietf.org Cc: Eric Rescorla , Colin Perkins , mmusic WG , Paul Kyzivat , Christer Holmberg Content-Type: multipart/alternative; boundary="94eb2c0327ac6a0bd305594cf786" Archived-At: Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 11:39:51 -0000 --94eb2c0327ac6a0bd305594cf786 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cool, we have a new version with the proposed text. Chairs, I think we are ready for WGLC. Thanks. -acbegen On Sat, Sep 16, 2017 at 11:17 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Looks good. > > > > Regards, > > > > Christer > > > > *From:* Ali C. Begen [mailto:ali.begen@networked.media] > *Sent:* 15 September 2017 23:02 > *To:* Christer Holmberg > *Cc:* Eric Rescorla ; Colin Perkins ; > mmusic WG ; Paul Kyzivat > > *Subject:* Re: [MMUSIC] k=3D and draft-ietf-mmusic-rfc4566bis > > > > Hi guys, > > Here is the proposed text for 5.12 based on the comments so far: > > 5.12. Encryption Keys ("k=3D") > > k=3D > k=3D: > > The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. It is i= ncluded in this > document for legacy reasons. One MUST NOT include a "k=3D" line in an SDP= , > and MUST discard it if it is received in an SDP. > > > > If we are good with this, I will revise the draft and we will go for WGLC= . > > > > Thanks. > > -acbegen > > > > > > On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > I support the approach below too. > > > > However, I think we should have a little more text: saying that k=3D is > included for legacy reasons, that one must not include it in SDP, and if > received must accept and discard it. > > > > =E2=80=A6or something like that. > > > > Regards, > > > > Christer > > > > *From: *mmusic on behalf of Eric Rescorla < > ekr@rtfm.com> > *Date: *Wednesday 13 September 2017 at 01:33 > *To: *Colin Perkins > *Cc: *"mmusic@ietf.org" , "pkyzivat@alum.mit.edu" < > pkyzivat@alum.mit.edu> > *Subject: *Re: [MMUSIC] k=3D and draft-ietf-mmusic-rfc4566bis > > > > This seems like a fine resolution to me. > > > > On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins wrote: > > > > On 12 Sep 2017, at 16:42, Paul Kyzivat wrote: > > > > On 9/12/17 10:03 AM, Cullen Jennings wrote: > >> First, I don't feel strongly about this and glad to go with whatever > Colin wants ... but what I was thinking .... > >> k=3D is still defined by RFC4566 and things that implement RFC4566 sti= ll > use it. I don't think we have an IANA table for this but if we do, the IA= NA > registry still lists it with the reference for it as RFC4566. > >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k=3D > one way or another. If something that implements RFCAAAA receives a k=3D > line, it gets treated just like any other unknown line and is ignored. > >> There not enough advice on how to use the k=3D stuff to expect > interoperable implementation of any type of security that the IETF would > currently consider acceptable to publish as a standard. Anyone who uses k= =3D > is very unlikely to be upgrading their software to RFCAAAA. I just don't > see anything good that comes of putting this in the new RFC and it just > adds to the confusion of how to secure RTP. > > > > One thing: if all mention of k=3D is removed from the bis, then in the > (far) someone who is defining a new line might choose k=3D for it. > (Admittedly this is pretty far fetched.) > > > > I think a cleaner way to handle this would be to deprecate k=3D in the = bis. > > I=E2=80=99d not object if the text in 4566bis was changed to: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 5.12. Encryption Keys ("k=3D") > > k=3D > k=3D: > > > The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. > > 5.13. Attributes (=E2=80=9Ca=3D=E2=80=9C) > =E2=80=A6 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =E2=80=A6or something similar. I just don=E2=80=99t think we can remove i= t entirely. > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --94eb2c0327ac6a0bd305594cf786 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Cool, we have a new version with the proposed text.
Chairs, I think we are ready for WGLC.

Thanks.
-acbegen

On Sat, Sep 16, 2017 at 11:17 AM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

Looks good.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Ali C. Begen [mailto:ali.begen@networked.media]
Sent: 15 September 2017 23:02
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Eric Rescorla <ekr@rtfm.com>; Colin Perkins <csp@csperkins.org>; mmusic WG <mmusic@ietf.org>; Paul Ky= zivat <pkyziv= at@alum.mit.edu>


Subject: Re: [MMUSIC] k=3D and draft-ietf-mmusic-rfc4566bis

=C2=A0

Hi guys,

Here is the proposed text for 5.12 based on the comments so far:

5.12.=C2=A0 Encryption Keys ("k=3D")

=C2=A0 =C2=A0 =C2=A0 k=3D<method>
=C2=A0 =C2=A0 =C2=A0 k=3D<method>:<encryption key>

The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used. It is inc= luded in this document for legacy reasons. One MUST NOT include a "k= =3D" line in an SDP, and MUST discard it if it is received in an SDP.= =C2=A0

=C2=A0

If we are good with this, I will revise the draft an= d we will go for WGLC.

=C2=A0

Thanks.

-acbegen

=C2=A0

=C2=A0

On Wed, Sep 13, 2017 at 12:58 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

I support the approach below too.

=C2=A0

However, I think we should have a littl= e more text: saying that k=3D is included for legacy reasons, that one must= not include it in SDP, and if received must accept and discard it.

=C2=A0

=E2=80=A6or something like that.=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: mmusic <mmusic-bounces@ietf.org> on behalf of Eric Resc= orla <ekr@rtfm.com= >
Date: Wednesday 13 September 2017 at 01:33
To: Colin Perkins <csp@csperkins.org>
Cc: "mmusi= c@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] k=3D and draft-ietf-mmusic-rfc4566bis

=C2=A0

This seems like a fine resolution to me= .

=C2=A0

On Tue, Sep 12, 2017 at 2:32 PM, Colin = Perkins <csp@cspe= rkins.org> wrote:


> On 12 Sep 2017, at 16:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
> On 9/12/17 10:03 AM, Cullen Jennings wrote:
>> First, I don't feel strongly about this and glad to go with wh= atever Colin wants ... but what I was thinking ....
>> k=3D is still defined by RFC4566 and things that implement RFC4566= still use it. I don't think we have an IANA table for this but if we d= o, the IANA registry still lists it with the reference for it as RFC4566. >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention = k=3D one way or another. If something that implements RFCAAAA receives a k= =3D line, it gets treated just like any other unknown line and is ignored.<= br> >> There not enough advice on how to use the k=3D stuff to expect int= eroperable implementation of any type of security that the IETF would curre= ntly consider acceptable to publish as a standard. Anyone who uses k=3D is = very unlikely to be upgrading their software to RFCAAAA. I just don't see anything good that comes of putting this = in the new RFC and it just adds to the confusion of how to secure RTP.
>
> One thing: if all mention of k=3D is removed from the bis, then in the= (far) someone who is defining a new line might choose k=3D for it. (Admitt= edly this is pretty far fetched.)
>
> I think a cleaner way to handle this would be to deprecate k=3D in the= bis.

I=E2=80=99d not object if the text in 4566bis was changed to:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.12.=C2=A0 Encryption Keys ("k=3D")

=C2=A0 =C2=A0 =C2=A0 k=3D<method>
=C2=A0 =C2=A0 =C2=A0 k=3D<method>:<encryption key>


=C2=A0 The =E2=80=9Ck=3D=E2=80=9C line is obsolete and MUST NOT be used.
5.13.=C2=A0 Attributes (=E2=80=9Ca=3D=E2=80=9C)
=E2=80=A6
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=E2=80=A6or something similar. I just don=E2=80=99t think we can remove it = entirely.



--
Colin Perkins
https://csperkins.org/=




_______________________________________________
mmusic mailing list
mmusic@ietf.org = https://www.ietf.org/mailman/listinfo/mmusic<= /p>

=C2=A0


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

=C2=A0


--94eb2c0327ac6a0bd305594cf786-- From nobody Sun Sep 17 21:15:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56C1326DF for ; Sun, 17 Sep 2017 21:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RElhriWNzZj2 for ; Sun, 17 Sep 2017 21:15:53 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E91132025 for ; Sun, 17 Sep 2017 21:15:53 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id s15so3784219uag.1 for ; Sun, 17 Sep 2017 21:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BSSS0+Vz/sdqd1wkVDOKHs6sbE85mbJ5tn8XHpdjrqw=; b=TFtsG7rRm5ECPTvo3yyDvkvnVPx4AEMRGY9exeYgtxrPCsjN3/cS9pwRdb8bt1eS5z RJOz/9BBJE7FXqmJMzTNse+sDyGGjYyJg4bj4zFabI5fmCnQBIFjAF1UCxkBrboyVd4N /9BnvMgYYHSfRJ0C9fn4DIt4r2xCp5OnAbatr5OadLDofKhbeS38jMK5xYRiUyKzxjaS cIUoRH9t2Kb2aQszGj2v+DYi9BBMD9H/jOKHAhpC9ci+erYVZ4gxVE0KaZEtlziMR2hY VPZYrCwgGEWh37cnk2+NTFZJZqRy3vY0bX3QOnC06MPfd9T97uAuMT9hsKbx5WcB9EqJ BcAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BSSS0+Vz/sdqd1wkVDOKHs6sbE85mbJ5tn8XHpdjrqw=; b=GwFmYeHnGohZsWpLPtPyvJJilaqPe3Ey+/ftgAF4PLhkP45ZMA1smeTY0t52oqST/4 aodNiIO+OP8yQ+4wxbRLd7kaz9VEoptjHuB3cl+4gn2JT4EBiZOlPpzP2W1jgEVJ090l D3vqFVIY4/Uhv1qH6WU+Y68a3LU8mfeOdqUUw2/V3DfuHJvl57dOzCZozKRqmAY0tHEB wlKwNyT5TuE3ki8ht5dQMzfz4kO1BGCaei51bZXtwt3Umwi6Gy1Kk0AveVuziN+tomFV KVmU78cjL3FSn9ulEVGj2av1nbeeSyp/yNMsA/0QAqAGw/aLJ0FM3OIfc3y1VyZ/9xcO nQBA== X-Gm-Message-State: AHPjjUgYeCf7j2GXREJmjGf8DySL8tkmy7rF8fEp6G8obCCPVWwRzMN8 6No5yj3ENkKxxqGG3KdnUxHHAAXu84EEwFl8Gut/9g== X-Google-Smtp-Source: ADKCNb6Hs9JLit0MZF1a2Md097hkAmNAOHUDM/f4gAQsVysGHL0nNW0BXwZC/CSWEkMy3t3eb69oRO9A0fNm6lYiWuA= X-Received: by 10.176.77.195 with SMTP id b3mr28739690uah.118.1505708152739; Sun, 17 Sep 2017 21:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.18.78 with HTTP; Sun, 17 Sep 2017 21:15:52 -0700 (PDT) From: Suhas Nandakumar Date: Sun, 17 Sep 2017 21:15:52 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary="f403043c3974945dc005596eff27" Archived-At: Subject: [MMUSIC] ICE-SIP-SDP updates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 04:15:55 -0000 --f403043c3974945dc005596eff27 Content-Type: text/plain; charset="UTF-8" Hello Roman and mmuscians Roman sent me the following things he would like to be addressed in the ice-sip-sdp draft. I have taken a stab at incorporating them here : https://github.com/suhasHere/ice-drafts/pull/3 Below i have tried to include responses to specific questions. ([Suhas]) 1. Handling of ICE mismatch Where is ICE mismatch currently defined? I cannot find this in either rfc5245bis or ICE-SIP-SDP. I think ICE mismatch should occur if address in c= line and port in m= line do not match any of the candidates and address in c= line is not dummy address IN IP4 0.0.0.0 and port in m= line is not dummy port 9 . This is needed to match https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-21#section-5.2.1 and trickle ICE [Suhas] ICE mismatch is discussed in 4.1.2.3, 4.1.3.1 and 11.2.2 2. Move general requirements from https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-26#section-12.2 into ICE-SIP-SDP. This section keeps repeating in protocol drafts and mostly represent generic ICE offer/answer requirements. Key points here are: a. any protocol running over ICE transport SHOULD implement UDP based protocol version b. when multiple candidates are sent in offer or answer during nomination process UDP based candidate SHOULD be included in the candidate list and SHOULD be selected as default candidate c. proto value MUST match the protocol of the default candidate d. for subsequent answer sent when ICE nomination process is not running, default candidate and proto in m= line MUST match the nominated candidate. [Suhas] Added the supporting text in the above PR. Also the repository has HTML file for easy reading. 3. ICE transport tag This is probably the most ambitious of all proposals. The idea is that instead of specifying, for example, UDP/TLS/RTP/SAVPF, specify ICE/TLS/RTP/SAVPF. Using ICE tag instead of UDP serves the following purposes: a. This indicates that ICE support is required. If remote end point does not support ICE, negotiation for this m-line fails. b. When ICE transport tag is used, only dummy address IN IP4 0.0.0.0 and dummy port 9 are used in c= and m= line and they are never updated. Transport of default or nominated candidate is irrelevant and does not affect proto tag in the m= line. This also means that c= and m= line are not updated when ICE nomination process completes and updated offer defined in https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13#section-4.1.5 is not sent. [Suhas] IIRC, this topic was brought to discussion several times in the WG and there was no consensus on defining a new ICE specific transport tag. Personally, I feel this will be a large undertaking and we should avoid doing this as part of this draft work. I am open to suggestions. Please let me know your thoughts. Cheers Suhas --f403043c3974945dc005596eff27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Roman and mmuscians

=C2=A0 Roman = sent me the following things he would like to be addressed in the ice-sip-s= dp draft. I have taken a stab at incorporating them here :


Be= low i have tried to include responses to specific questions. ([Suhas])

1. Handling of ICE mismatch

<= div>Where is ICE mismatch currently defined? I cannot find this in either r= fc5245bis or ICE-SIP-SDP.=C2=A0

I think ICE mismat= ch should occur if address in c=3D line and port in m=3D line do not match = any of the candidates and <new>address in c=3D line is not dummy addr= ess IN IP4 0.0.0.0 and port in m=3D line is not dummy port 9 </new>. = This is needed to match https://tools.ietf.org/html/draft-ietf-rtcweb-= jsep-21#section-5.2.1 and trickle ICE

[Suhas] = ICE mismatch is discussed in 4.1.2.3, =C2=A04.1.3.1 and 11.2.2
2. Move general requirements from https://tools.ietf.o= rg/html/draft-ietf-mmusic-sctp-sdp-26#section-12.2 into ICE-SIP-SDP.

This section keeps repeating in protocol drafts and = mostly represent generic ICE offer/answer requirements. Key points here are= :

a. any protocol running over ICE transport SHOUL= D implement UDP based protocol version

b. when mul= tiple candidates are sent in offer or answer during nomination process UDP = based candidate SHOULD be included in the candidate list and SHOULD be sele= cted as default candidate

c. proto value MUST matc= h the protocol of the default candidate

d. for sub= sequent answer sent when ICE nomination process is not running, default can= didate and proto in m=3D line MUST match the nominated candidate.

[Suhas] Added the supporting text in the above PR. Also the= repository has HTML file for easy reading.

3. ICE= transport tag

This is probably the most ambitious= of all proposals. The idea is that instead of specifying, for example, UDP= /TLS/RTP/SAVPF, specify ICE/TLS/RTP/SAVPF.

Using I= CE tag instead of UDP serves the following purposes:

a. This indicates that ICE support is required. If remote end point does= not support ICE, negotiation for this m-line fails.

b. When ICE transport tag is used, only dummy address IN IP4 0.0.0.0 and= dummy port 9 are used in c=3D and m=3D line and they are never updated. Tr= ansport of default or nominated candidate is irrelevant and does not affect= proto tag in the m=3D line. This also means that c=3D and m=3D line are no= t updated when ICE nomination process completes and updated offer defined i= n https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13#= section-4.1.5 is not sent.

[Suhas] IIRC,= this topic was brought to discussion several times in the WG and there was= no consensus on defining a new ICE specific transport tag. Personally, I f= eel this will be a large undertaking and we should avoid doing this as part= of this draft work. I am open to suggestions.

Ple= ase let me know your thoughts.

Cheers
Su= has

--f403043c3974945dc005596eff27-- From nobody Mon Sep 18 02:33:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA2132932 for ; Mon, 18 Sep 2017 02:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czLxEbu56_Me for ; Mon, 18 Sep 2017 02:33:45 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526621320CF for ; Mon, 18 Sep 2017 02:33:45 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id n24so4492831pfk.5 for ; Mon, 18 Sep 2017 02:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=KKdzPIYQzWKUmECi0+fQE1VNUUEMqDtQhI0WVmD/YAU=; b=yfRE98ML3fOsgJ81IN5RtU7ybakHI9L602dSj0QPo9xtgvrBD4p79Myt1+8vWGIZVs dIXNDPi44gWCghJZ4Hjkxiga6rVc6RuXyVOyhAiRL8+9jzFv48ppC4GAf5XDciHSDm4E +TPz7IA92WjnmuRj4i9dUVLcVFcPi7Bn2yxERuxy58733TX5PKOH9qkRMCWnfWb2dQdQ lKh+seNwNz7EaXHuRO2RB1SJ4/LasNt4jKE2CF84ki+Ulen01KmOB4ZkidY8LPoDEITp jzAFpJ+cfuTPwxefIE7iIGTcK9BkSkSbt9sip81j0du/wKK01DD6zCRiGHOf7SMfu+Qn nVCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=KKdzPIYQzWKUmECi0+fQE1VNUUEMqDtQhI0WVmD/YAU=; b=Lv3+7Hvq6jVhaZkdSSio5n69CyQhsrkkrYHpCOD5GllEiGSBhSsQBa+KZ4ntFJtiF8 dBr8xKJZUP6oYZsPEAX6Qv4wDahnLiW/87C3kNf3yps8cCpL9Uh2AhwJgftYcMJTZ48M zV3ysEp5GxYGgbtBkyQWYRYKF8RUu3Ptbo251SRItL86bqi0ISZ+EgUmDcT8NiJuQG+n 8MrJPB6swlAVV/wl6KLyvq9sjqg1r+Q/bWhR8Im+LDOiYV9GZLsmBUgH3gKbz5I4cf8u M7jryBIBewkldiA65wyW8uBPRfDjAG3VO937h31d0SQXk42l3MPX6TZkfwoNwKjmUzeY OfPg== X-Gm-Message-State: AHPjjUiBNh7X02ogh/xvL1Pt7Cu7rC/nM29EZ+K7KKiohQhJtVnsyGyp VH+L+BhqxT03l9BfAok= X-Received: by 10.98.18.73 with SMTP id a70mr32529912pfj.245.1505727224586; Mon, 18 Sep 2017 02:33:44 -0700 (PDT) Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com. [209.85.192.175]) by smtp.gmail.com with ESMTPSA id e27sm15702429pfk.41.2017.09.18.02.33.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 02:33:43 -0700 (PDT) Received: by mail-pf0-f175.google.com with SMTP id l188so4488129pfc.6 for ; Mon, 18 Sep 2017 02:33:43 -0700 (PDT) X-Google-Smtp-Source: ADKCNb5F/ZrUsIzKOsO4uaJg0gq5bJrljsyMaKoAYJ6WUl0/1NjTZ56jou+kHNy/4b527MKTUu0lq9qqGkKFltpUGV4= X-Received: by 10.84.231.9 with SMTP id f9mr35486326plk.155.1505727223314; Mon, 18 Sep 2017 02:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.191.8 with HTTP; Mon, 18 Sep 2017 02:33:42 -0700 (PDT) From: Roman Shpount Date: Mon, 18 Sep 2017 05:33:42 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Suhas Nandakumar Cc: mmusic WG Content-Type: multipart/alternative; boundary="94eb2c1baa064641ad0559737018" Archived-At: Subject: Re: [MMUSIC] ICE-SIP-SDP updates X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 09:33:46 -0000 --94eb2c1baa064641ad0559737018 Content-Type: text/plain; charset="UTF-8" Hi Suhas, On Mon, Sep 18, 2017 at 12:15 AM, Suhas Nandakumar wrote: > 1. Handling of ICE mismatch > > Where is ICE mismatch currently defined? I cannot find this in either > rfc5245bis or ICE-SIP-SDP. > > I think ICE mismatch should occur if address in c= line and port in m= > line do not match any of the candidates and address in c= line is not > dummy address IN IP4 0.0.0.0 and port in m= line is not dummy port 9 > . This is needed to match https://tools.ietf.org/html/ > draft-ietf-rtcweb-jsep-21#section-5.2.1 and trickle ICE > > [Suhas] ICE mismatch is discussed in 4.1.2.3, 4.1.3.1 and 11.2.2 > [roman] Section 4.1.2.3 should be modified to allow c= line with IN IP4 0.0.0.0 and port in m= line with port 9 not to be treated as ice-mismatch even if it does not match any of the candidates. Without this, trickle ICE and JSEP will cause ice-mismatch. Furthermore, rtcp attribute is optional, so the text needs to be modified to allow for this. 2. Move general requirements from https://tools.ietf.org/html/ > draft-ietf-mmusic-sctp-sdp-26#section-12.2 into ICE-SIP-SDP. > > [Suhas] Added the supporting text in the above PR. Also the repository has > HTML file for easy reading. > [roman] This looks good, but I will double check and provide comments if I find anything. > > 3. ICE transport tag > > [Suhas] IIRC, this topic was brought to discussion several times in the WG > and there was no consensus on defining a new ICE specific transport tag. > Personally, I feel this will be a large undertaking and we should avoid > doing this as part of this draft work. I am open to suggestions. > > [roman] I agree that this can be left out and handled in the future draft if there is enough support for it. Regards, _____________ Roman Shpount --94eb2c1baa064641ad0559737018 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Suhas,

=

On Mon, Sep 18, 2017 at 12:15 AM, Suhas Nandakumar &l= t;suhasietf@gmail.= com> wrote:
1. Handling of ICE mismatch
Where is ICE mismatch currently defined? I cannot find this in= either rfc5245bis or ICE-SIP-SDP.=C2=A0

I think I= CE mismatch should occur if address in c=3D line and port in m=3D line do n= ot match any of the candidates and <new>address in c=3D line is not d= ummy address IN IP4 0.0.0.0 and port in m=3D line is not dummy port 9 </= new>. This is needed to match https://tools.ietf.= org/html/draft-ietf-rtcweb-jsep-21#section-5.2.1 and trickle = ICE

[Suhas] ICE mismatch is discussed in 4.1.2.3, = =C2=A04.1.3.1 and 11.2.2

= [roman] Section 4.1.2.3 should be modified to allow c=3D line with IN IP4 0= .0.0.0 and port in m=3D line with port 9 not to be treated as ice-mismatch = even if it does not match any of the candidates. Without this, trickle ICE = and JSEP will cause ice-mismatch. Furthermore, rtcp attribute is optional, = so the text needs to be modified to allow for this.

2= . Move general requirements from https://tools.ie= tf.org/html/draft-ietf-mmusic-sctp-sdp-26#section-12.2 into I= CE-SIP-SDP.

[Suhas] Added the supporting text = in the above PR. Also the repository has HTML file for easy reading.

[roman] This looks good, bu= t I will double check and provide comments if I find anything.

3. ICE transport tag

[Suhas] = IIRC, this topic was brought to discussion several times in the WG and ther= e was no consensus on defining a new ICE specific transport tag. Personally= , I feel this will be a large undertaking and we should avoid doing this as= part of this draft work. I am open to suggestions.

=C2=A0[roman]=C2=A0 I agree t= hat this can be left out and handled in the future draft if there is enough= support for it.

Regards,
_____________
Roman Shpo= unt

--94eb2c1baa064641ad0559737018-- From nobody Mon Sep 18 06:58:59 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD161331DC; Mon, 18 Sep 2017 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RzM0CU7M9W2; Mon, 18 Sep 2017 06:58:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189A613217D; Mon, 18 Sep 2017 06:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=486; q=dns/txt; s=iport; t=1505743136; x=1506952736; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Aeyib6N/I5PHv+QU2Y0RvgeuSwEJJMYBeV/4BqIWgrQ=; b=FKgrBiKFIpnvDlmNyNVTFt+/3i9X9yATec7vtcSPTTuaU986jQBucwnK QI7oJd1diDaN48ppS+w+XxkDdZ4D125qUbg91wZwDS0Wh61iCGNPwHGy7 M8j/kHlcqRKVJ0JlP5Pb3UXzuwkXZHcBR3/7d6rZbn8cpS6HyNf9ylyt5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AgDP0L9Z/4cNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkbieDdZoWgUkJmFoKI4lgQxQBAgEBAQEBAQFrKIVCDwEFWhwCJgJ?= =?us-ascii?q?fAQwIAQGKIg0QjE2dZoIniyoBAQEBAQUBAQEBAQEdBYEOgh2CAoFQgWMrC4p9g?= =?us-ascii?q?mABBKEIlFWBexiFaoNahViBSZU1gTk2IYENUyQVSYc4JDYBiBIBAQE?= X-IronPort-AV: E=Sophos;i="5.42,413,1500940800"; d="scan'208";a="300442610" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Sep 2017 13:58:24 +0000 Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8IDwN00030046; Mon, 18 Sep 2017 13:58:24 GMT To: mmusic , draft-ietf-mmusic-rfc4566bis@ietf.org From: Flemming Andreasen Message-ID: <4694de2c-2f8c-7105-f994-be105bbc47f1@cisco.com> Date: Mon, 18 Sep 2017 09:58:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 13:58:57 -0000 Greetings MMUSIC This is to announce a 2 week WGLC on the draft:      https://www.ietf.org/id/draft-ietf-mmusic-rfc4566bis-23.txt as Proposed Standard. Please review and provide any comments you may have on the document by Monday, October 2, 2017. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well. Thanks -- Flemming (MMUSIC co-chair) From nobody Mon Sep 18 07:49:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5976A132F3E for ; Mon, 18 Sep 2017 07:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvcmHWB3HGgR for ; Mon, 18 Sep 2017 07:49:08 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 1E9C51321BB for ; Mon, 18 Sep 2017 07:49:08 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id txM6deCElm6EutxMBddYXn; Mon, 18 Sep 2017 14:49:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1505746147; bh=CviVGJLhN+h01sXN3SfZbIiJHeXxOpNkqS3mjb2k+Cw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gcaAHcxck9QhOAZC+bvHgcIpDnbQkTF8YGWLOe29O5CnXr2Chk2zTPe51hdoHBRWF ZEk7SbgFNj8sN5YhnCXQGhKs7Ph8NXxE8pgDz/dDs6entzKxjU0qLG0ACeL/jMSPF5 teFzlNMrtS60UmPQezUodYP37amVhTEjpZ1b5XTHTkZbN87D9BqDzgNwkUqCe6xH9e iwI/gryuRNJg0F+Q7UIXBjll5lqaVumnir3anZeAD4/KCCKmw8eLdRHfvACtYA9/Vu A8mtj9G7MkRcI8mqki690V0zhgZzedolD73mAq3GsKroUBdyciCyZvUsDCUf0qSoLO lHYgG97sPjw7Q== Received: from PaulKyzivatsMBP.localdomain ([24.62.227.142]) by resomta-ch2-09v.sys.comcast.net with SMTP id txMAdQePlwtG7txMAdYlOn; Mon, 18 Sep 2017 14:49:07 +0000 To: mmusic@ietf.org References: <4694de2c-2f8c-7105-f994-be105bbc47f1@cisco.com> From: Paul Kyzivat Message-ID: Date: Mon, 18 Sep 2017 10:49:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4694de2c-2f8c-7105-f994-be105bbc47f1@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJsJ3O3M+s1ESmZkwZgPVXUHXuzugKZL70EzmpDUb20XUpJ0T6xszUDVfFuIxjtlt3rjfc+Z0jX9nLh6GbeCPnPAVxikBrmBRdB+KZwCT88FJWnq2/7Y HSrEDOl7twGiI29Sjv0Vj5BQXkO1nlaofG87hDqKYPPf1Ec0PMaNnAKl9q6yE3v9/ufLH7ayFSUWKQ== Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 14:49:09 -0000 Looks good. Ship it! On 9/18/17 9:58 AM, Flemming Andreasen wrote: > Greetings MMUSIC > > This is to announce a 2 week WGLC on the draft: > >      https://www.ietf.org/id/draft-ietf-mmusic-rfc4566bis-23.txt > > as Proposed Standard. Please review and provide any comments you may > have on the document by Monday, October 2, 2017. Comments should be sent > to the document authors and the MMUSIC WG list. If you review the > document but do not have any comments, please send a note to that effect > as well. > > Thanks > > -- Flemming (MMUSIC co-chair) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Sep 18 15:06:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D35133352; Mon, 18 Sep 2017 15:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahrQ5zJDmdYY; Mon, 18 Sep 2017 15:06:06 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B52C133344; Mon, 18 Sep 2017 15:06:06 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id y126so190567itb.5; Mon, 18 Sep 2017 15:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sAanWJb+z9egwKvb5l5/boHF7triUJ8qV23/0cJD9AQ=; b=BGb2eTPRaWu6ajuS+4jzlVLm1C7L/i5h2vvvaBpM2mb1cS6DOzTKyUTS8O6GfTtZmQ LkYRYHCKCRxv2NdmorA4wOgTHO7/sFm82pKY2F85wHV628z8D8frlSqHSK5Jxmv5Xn35 TNq9k7IAl8ByYT2xbR83Bn6b6O6WdNWZpECSzIuR9hmXBHQYWHdZXziDj2ifXKINYhJw 7PDr1JS9UdtOZ0OE0JYk6NcZK111P/yHxMpY+oPVMPc8PN4JtR9Ncza9euKHpTihb4K5 gzUDMqFEiOMSpWFohzve+IU02sJ0ftyy3JvHw/ZXOMp8uHJjuA9I48PsrXI70S6YEYyF smhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sAanWJb+z9egwKvb5l5/boHF7triUJ8qV23/0cJD9AQ=; b=OaEHp6RNtwl6ocvXIBv6ewuY0TN56/wp3ahTXrK9UriFS9gTyTZYcrUpePQcD7Pcyp EAZFI7Wp9OuS91eP6Fg+TskONoDFTyBBzgIEM4iI3LevZatDBhKKIeOfWhWXRguPUHMS sQeUnjYNRF+zaCOTpR1vyAp7OVBQ+m04PTcj5J9qgODc0v9OHPhdvDazZJaI+JtyDrsL 4JG2So5JbYDHqGsuFC1SljKDs57atJLvhyNCNIAVbHRg6Z9u/YqMoLscLjqbWF7n7KxQ loQGUtK95/dy7eX+psyOyHI9Akx3gQJhWlBcoryVIn9JHCsd57uuRCWGIg5O/yPwB46H 1/6A== X-Gm-Message-State: AHPjjUjSgImadbSpMSQgWSZ2vCrDtry35Htkk8aFgibpJRBoDbsv19t/ NdrlbObgFSWTIeRLQ85/Nlgq5cUg0zU4E8fSncY= X-Google-Smtp-Source: AOwi7QDeXA/yV4YarZGcRKmGDBRlaGN/pckvVAqVKFWxSLko25/Jnp/F//u0IWmHc+Zq7dGLM5UEXqTq8wZiEa+p1Gk= X-Received: by 10.36.161.15 with SMTP id y15mr33675ite.34.1505772365170; Mon, 18 Sep 2017 15:06:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.51.79 with HTTP; Mon, 18 Sep 2017 15:06:03 -0700 (PDT) Received: by 10.2.51.79 with HTTP; Mon, 18 Sep 2017 15:06:03 -0700 (PDT) In-Reply-To: <150556187847.4892.13179419739455020059@ietfa.amsl.com> References: <150556187847.4892.13179419739455020059@ietfa.amsl.com> From: Yoshinori Matsui Date: Tue, 19 Sep 2017 07:06:03 +0900 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, mmusic@ietf.org Content-Type: multipart/alternative; boundary="f403045fbf04f04d6005597df24b" Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc4566bis-23.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 22:06:08 -0000 --f403045fbf04f04d6005597df24b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E3=81=AF 2017/09/16 20:38 : > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session Control WG > of the IETF. > > Title : SDP: Session Description Protocol > Authors : Mark Handley > Van Jacobson > Colin Perkins > Ali Begen > Filename : draft-ietf-mmusic-rfc4566bis-23.txt > Pages : 59 > Date : 2017-09-16 > > Abstract: > This memo defines the Session Description Protocol (SDP). SDP is > intended for describing multimedia sessions for the purposes of > session announcement, session invitation, and other forms of > multimedia session initiation. This document obsoletes RFC 4566. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-23 > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-23 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-23 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --f403045fbf04f04d6005597df24b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0=E3=81=AF

2017/09/16 20:38 <internet-drafts@ietf.org>:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Multiparty Multimedia Session Control WG o= f the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= SDP: Session Description Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mark= Handley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Van Jacobson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Colin Perkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ali Begen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-rfc4566bis-23.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 59
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-16

Abstract:
=C2=A0 =C2=A0This memo defines the Session Description Protocol (SDP).=C2= =A0 SDP is
=C2=A0 =C2=A0intended for describing multimedia sessions for the purposes o= f
=C2=A0 =C2=A0session announcement, session invitation, and other forms of =C2=A0 =C2=A0multimedia session initiation.=C2=A0 This document obsoletes R= FC 4566.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-mmusic-rfc4566bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-mmusic-rfc4566bis-23
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-rfc4566bis-23


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--f403045fbf04f04d6005597df24b-- From nobody Tue Sep 19 12:05:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915BA1342D9; Tue, 19 Sep 2017 12:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 N0JfbZd-v1SO; Tue, 19 Sep 2017 12:05:04 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 1C1BF126BF3; Tue, 19 Sep 2017 12:05:03 -0700 (PDT) X-AuditID: c1b4fb2d-a4dff700000019be-c1-59c16a5d3d11 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.21.06590.D5A61C95; Tue, 19 Sep 2017 21:05:02 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Tue, 19 Sep 2017 21:05:01 +0200 From: Christer Holmberg To: mmusic WG , "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: Doodle poll: Call to discuss DTLS-SDP issue on whether an SDP answerer can trigger a new DTLS association Thread-Index: AdMxejKSBVVB0hLET/W47web7N+qKw== Date: Tue, 19 Sep 2017 19:05:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B562E261D@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B562E261DESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7k25c1sFIg1NdXBbzO0+zW5zfuZ7J YuryxywOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8aMI/NYC1Z0MlYsuHybpYHxUUUX IyeHhICJxKd7b9lAbCGBI4wS67d7djFyAdmLGCUmtbxl6WLk4GATsJDo/qcNUiMiUCLxtuMl WL0wkP3q/GtGiHilxPTlz5khbD2JCd39YDaLgKrE3Y3HWUBsXgFfiTf/94HZjAJiEt9PrWEC sZkFxCVuPZnPBHGPgMSSPeeZIWxRiZeP/7FC2EoSi25/hqrPl2i8eZ0VYqagxMmZT1gmMArO QjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4uLcdCNjvdSizOTi 4vw8vbzUkk2MwMg4uOW37g7G1a8dDzEKcDAq8fBWxx2MFGJNLCuuzD3EKMHBrCTCqxULFOJN SaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNTqoExbHlwpdpN9z+n +ZPT5AKyrslwai1OzlaTvmpssuT4RuPNswwnL926e3GS2raJDr2PrzFePLcz/1J97y22RRvc Tgj+9T+Q8vuA2zlN7/2SKduWcYuop92bxO2ofGT3hdU3J0WxVa8o+LZb6k37BoXMua/Duvpk gmXy33jO7H54ZVpgV7nlzyMCSizFGYmGWsxFxYkA4tMTgIgCAAA= Archived-At: Subject: [MMUSIC] Doodle poll: Call to discuss DTLS-SDP issue on whether an SDP answerer can trigger a new DTLS association X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 19:05:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B562E261DESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am planning to set up a call to discuss the issue with draft-dtls-sdp on = whether an SDP answerer is allowed to trigger a new DTLS association. In case you are not familiar with the issue, below is a description (provid= ed by Roman) in a nutshell, followed by a doodle poll for a phone call to d= iscuss the issue. What do we want to discuss? If an SDP answerer can request a new DTLS association if the SDP offerer en= d point did not request it. When and why can this happen? This happens during third party call control (3PCC). Imagine a call being s= etup between end points A and B through the third party call control agent = 3PCC. 3PCC requests end point A for a new offer. This offer will always ini= tiate ICE restart (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sd= p-13#section-8.5) and it currently is not required to have a new tls-id. If= offer from end point A is generated with the current tls-id and sent by 3P= CC as a new offer to an end point C, a new DTLS association must be establi= shed between A and C. This will be detected by end point A, when it gets th= e answer from end point C which will contain a new tls-id, or, in legacy RF= C 5763 case, new fingerprints. How can this be implemented? Current draft allows an answerer to establish a new DTLS association in the= answer to any offer without ICE or any offer with ICE restart. The only wa= y I have managed to get the current specification to work is by monitoring = packets which are received over new ICE candidate pairs discovered after IC= E restart. If DTLS ClientHello packet is received, it is assumed that remot= e end point initiated a new DTLS association and received packets are queue= d until answer is received. If other DTLS packets or non-DTLS (SRTP) packet= s are received, they are processed as if they were part of the previous DTL= S association or SRTP flow established using a previous DTLS association. What are the arguments for allowing answering end point to establish new DT= LS associations? 1. This allows support for common 3PCC and B2BUA scenarios. Without 3PCC ca= ll scenario support, SIP end points could not be DTLS enabled 2. This is already allowed by RFC 5763 and is required for legacy interop 3. If DTLS extension is ever developed that allows de-mux multiple DTLS ass= ociations over the same underlying transport, then new DTLS associations ca= n be established and torn down independently of the underlying transport, s= o that it would be natural for either party to initiate it. How this can cause problems? 1. Any packets received from the time the offier is sent until the answer i= s received over a new transport 5-tuple are ambiguous in the sense that the= y can belong to the existing DTLS association or the new DTLS association e= stablished by the answering end point. There is no way to resolve this with= out an "ugly" solution that mixes several different protocol levels (DTLS C= lient Hello detector). This also requires buffering that is not ideal. 2. It is unclear if new DTLS association and new data channels (which need = to be re-established if DTLS association is re-established) would be create= d as a result of an offer/answer exchange when the offer is sent. This comp= licates API design 3. 3PCC is evil and confusing and should be avoided. There is no way to gen= erate o=3D lines, allocate payloads, etc across multiple end points in a wa= y that is consistent and compliant with JSEP. Because of this 3PCC agent ca= n never be a JSEP compliant end point. Implementations will be a lot simple= r if 3PCC scenarios were not supported and communications were always betwe= en two fixed end points. P.S. What do we agree upon and not discussing? ICE restart does not establish a new DTLS association on its own. ICE resta= rt is required when new DTLS association is established, but new DTLS assoc= iation MUST be explicitly requested by one of the parties. Doodle poll: https://doodle.com/poll/y9szwrn57a5b4k7h Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B562E261DESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am planning to set up a call to discu= ss the issue with draft-dtls-sdp on whether an SDP answerer is allowed to t= rigger a new DTLS association.

 

In case you are not familiar with the i= ssue, below is a description (provided by Roman) in a nutshell, followed by= a doodle poll for a phone call to discuss the issue.

 

What do we want to discuss?

 

If an SDP answerer can request a ne= w DTLS association if the SDP offerer end point did not request it.

 

When and why can this happen?

 

This happens during third party cal= l control (3PCC). Imagine a call being setup between end points A and B thr= ough the third party call control agent 3PCC. 3PCC requests end point A for a new offer. This offer will always initiate= ICE restart (https://tools.ietf.org/html/draft-ietf-mmusic-ice-s= ip-sdp-13#section-8.5) and it currently is not required to have a new tls-id. If offer from end point A = is generated with the current tls-id and sent by 3PCC as a new offer to an = end point C, a new DTLS association must be established between A and C. Th= is will be detected by end point A, when it gets the answer from end point C which will contain a new = tls-id, or, in legacy RFC 5763 case, new fingerprints.

 

How can this be implemented?

 

Current draft allows an answerer to= establish a new DTLS association in the answer to any offer without ICE or= any offer with ICE restart. The only way I have managed to get the current specification to work is by monitoring packets = which are received over new ICE candidate pairs discovered after ICE restar= t. If DTLS ClientHello packet is received, it is assumed that remote end po= int initiated a new DTLS association and received packets are queued until answer is received. If other DTLS pa= ckets or non-DTLS (SRTP) packets are received, they are processed as if the= y were part of the previous DTLS association or SRTP flow established using= a previous DTLS association.

 

What are the arguments for allow= ing answering end point to establish new DTLS associations?

 

1. This allows support for common 3= PCC and B2BUA scenarios. Without 3PCC call scenario support, SIP end points= could not be DTLS enabled 

 

2. This is already allowed by RFC 5= 763 and is required for legacy interop

 

3. If DTLS extension is ever develo= ped that allows de-mux multiple DTLS associations over the same underlying = transport, then new DTLS associations can be established and torn down independently of the underlying transport, so that it would = be natural for either party to initiate it.

 

How this can cause problems?

 

1. Any packets received from the ti= me the offier is sent until the answer is received over a new transport 5-t= uple are ambiguous in the sense that they can belong to the existing DTLS association or the new DTLS association establ= ished by the answering end point. There is no way to resolve this without a= n "ugly" solution that mixes several different protocol levels (D= TLS Client Hello detector). This also requires buffering that is not ideal.

 

2. It is unclear if new DTLS associ= ation and new data channels (which need to be re-established if DTLS associ= ation is re-established) would be created as a result of an offer/answer exchange when the offer is sent. This complicate= s API design

 

3. 3PCC is evil and confusing and s= hould be avoided. There is no way to generate o=3D lines, allocate payloads= , etc across multiple end points in a way that is consistent and compliant with JSEP. Because of this 3PCC agent can never b= e a JSEP compliant end point. Implementations will be a lot simpler if 3PCC= scenarios were not supported and communications were always between two fi= xed end points.

 

P.S. What do we agree upon = and not discussing?

 

ICE restart does not establish a ne= w DTLS association on its own. ICE restart is required when new DTLS associ= ation is established, but new DTLS association MUST be explicitly requested by one of the parties.

 

Doodle poll: https://doodle.com/poll/y9szwrn57a5b4k7= h

 

Regards,

 

Christer

 =

--_000_7594FB04B1934943A5C02806D1A2204B562E261DESESSMB109erics_-- From nobody Tue Sep 19 18:20:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491C71321AC for ; Tue, 19 Sep 2017 18:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93fQPay8UbrE for ; Tue, 19 Sep 2017 18:20:33 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B8A132199 for ; Tue, 19 Sep 2017 18:20:32 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id q132so1243429lfe.5 for ; Tue, 19 Sep 2017 18:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9FpDAhZzug6aTf+k40ld/KkhvIVzgLSLXhmrs70+TkE=; b=q4wlLnS3olV+wjbNpiTaowt/qmKDER2fXwMvwijMYxtBTvTxWgby/7NQ9aO/NJ3qSf IyaX9KZIRIQ2jbztWmawjm4DG2mCvDhmlM5wKbmwl+zpYxJ0MPZ3fU6HukFo2MGqixVC l8VzoRxxaX24hbkL1d4EIJcAPAy7p0rjInJSzrCunr2ugsMmDi1V4/Ju5yWKG0HWuSjP UvuFAtHk8uCiVMXVHv1JPnjt/LSd8aYmGducRimNc8RNrZ0jgroJhbbVTxypizydCuA5 0lZCXGhKz9uRWqh0MtJQf8ZFc3pdcxFtQfy+fZoSG5GiiSQkV1a44CKITq2r233TNGuX OVwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9FpDAhZzug6aTf+k40ld/KkhvIVzgLSLXhmrs70+TkE=; b=fhQ8bsvnT8DnYynotZwCYUUMgc6OSMrAXl8i5OEAuDP5ciVSSeJMgxzVuQ/zE5keZ2 UrQrEm/cKKH3MNhGfMO+T+OLWRYYjNStqFmdcxwjmqLoylo6iM/Zew73w2KdTRqJIX61 IhZp0xYUuYMgflJThybiJgTFAaNy90Mr2XXRvnHe4WaDYw2FYSGfgGSysK2OHmHwCFMj +2jXdFhLwiQ9lyrlj84JjMnN/41J06E7RZwVFzI+d1bi/WBYMOYyPmPkBtItwCQtW4yB wF62pRnIwzebdJ+X1NtiUFvs/N0GfyiQJj2PR1BYxL5uKNvebNoL5RtXAmgqZMnYp/FB PpHw== X-Gm-Message-State: AHPjjUhTxPqirq/lPnhHHoDZwjzPZ6Ae4GByC27WPoVf3y0+5kipgSiV TVsNp1NjFUraFY8xFzn9gJOb0rPLkHGlRYQtVt0= X-Google-Smtp-Source: AOwi7QDFMBAlvli5u2en0xsXSTfDfU10rBcPNywPc5nug535i7IFaQlVhAAMUmw/TB5cP9eJpyvHl9wEiTfMV3AIOOA= X-Received: by 10.46.66.22 with SMTP id p22mr1420020lja.18.1505870430687; Tue, 19 Sep 2017 18:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.29.193 with HTTP; Tue, 19 Sep 2017 18:20:29 -0700 (PDT) In-Reply-To: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> From: Alan Johnston Date: Tue, 19 Sep 2017 21:20:29 -0400 Message-ID: To: Christer Holmberg Cc: Andy Hutton , "mmusic (E-mail)" Content-Type: multipart/alternative; boundary="94eb2c1cdeea1958ed055994c8fa" Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 01:20:35 -0000 --94eb2c1cdeea1958ed055994c8fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christer, I just submitted the -03 version of the sipbrandy osrtp draft which should address your comments. https://www.ietf.org/id/draft-ietf-sipbrandy-osrtp-03.txt If you have further comments, please send them to sipbrandy so the authors will see them! Thanks! - Alan - On Fri, Sep 15, 2017 at 9:19 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I sent some initial comments on the Abstract of the individual draft way > back. I don=C2=B9t think anyone ever replied, but it seems like my commen= ts > have been addressed. > > I do have some more comments, but they are mostly editorial so I can > provide them as WGLC comments. > > Regards, > > Christer > > > > > > > > On 15/09/17 16:07, "mmusic on behalf of Andy Hutton" > wrote: > > >The changes to this draft are editorial and address a previous comment > >from Colin Perkins that we needed to refer to RTP profiles by the full > >name. > > > >I am hoping we can now move this draft forward to WGLC and > >subsequently close the work in SIPBrandy as well. > > > >Regards > >Andy > > > >On Thu, Sep 14, 2017 at 5:03 PM, wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >>directories. > >> This draft is a work item of the Multiparty Multimedia Session Control > >>WG of the IETF. > >> > >> Title : Negotiating SRTP and RTCP Feedback using the > >>RTP/AVP Profile > >> Authors : Andrew Hutton > >> Roland Jesske > >> Alan Johnston > >> Gonzalo Salgueiro > >> Bernard Aboba > >> Filename : > >>draft-ietf-mmusic-opportunistic-negotiation-01.txt > >> Pages : 7 > >> Date : 2017-09-14 > >> > >> Abstract: > >> This document describes how the use of the Secure Real-time transpo= rt > >> protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Aud= io > >> Video Profile) defined in [RFC3551]. Such a mechanism is used to > >> provide a means for encrypted media to be used in environments wher= e > >> support for encryption is not known in advance, and not required. > >> The same mechanism is also applied to negotiation of the Extended R= TP > >> Profile for Real-time Transport Control Protocol Based Feedback (RT= P/ > >> AVPF) [RFC4585]. > >> > >> > >> The IETF datatracker status page for this draft is: > >> > >>https://datatracker.ietf.org/doc/draft-ietf-mmusic- > opportunistic-negotiat > >>ion/ > >> > >> There are also htmlized versions available at: > >> > >>https://tools.ietf.org/html/draft-ietf-mmusic- > opportunistic-negotiation-0 > >>1 > >> > >>https://datatracker.ietf.org/doc/html/draft-ietf- > mmusic-opportunistic-neg > >>otiation-01 > >> > >> A diff from the previous version is available at: > >> > >>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf- > mmusic-opportunistic-negotia > >>tion-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/ > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c1cdeea1958ed055994c8fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christer,

I just submitted the -03 vers= ion of the sipbrandy osrtp draft which should address your comments.
<= div>

If you have further comments,= please send them to sipbrandy so the authors will see them!

=
Thanks!
- Alan -

<= div class=3D"gmail_quote">On Fri, Sep 15, 2017 at 9:19 AM, Christer Holmber= g <christer.holmberg@ericsson.com> wrote:
Hi,

I sent some initial comments on the Abstract of the individual draft way back. I don=C2=B9t think anyone ever replied, but it seems like my comments=
have been addressed.

I do have some more comments, but they are mostly editorial so I can
provide them as WGLC comments.

Regards,

Christer







On 15/09/17 16:07, "mmusic on behalf of Andy Hutton"
<mmusic-bounces@ietf.org = on behalf of andyhutton.ietf@g= mail.com> wrote:

>The changes to this draft are editorial and address a previous comment<= br> >from Colin Perkins that we needed to refer to RTP profiles by the full<= br> >name.
>
>I am hoping we can now move this draft forward to WGLC and
>subsequently close the work in SIPBrandy as well.
>
>Regards
>Andy
>
>On Thu, Sep 14, 2017 at 5:03 PM,=C2=A0 <internet-drafts@ietf.org> wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
>>directories.
>> This draft is a work item of the Multiparty Multimedia Session Con= trol
>>WG of the IETF.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Negotiating SRTP and RTCP Feedback using the
>>RTP/AVP Profile
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Andrew Hutton
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Roland Jesske
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alan Johnston
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Gonzalo Salgueiro
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bernard Aboba
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 :
>>draft-ietf-mmusic-opportunistic-negotiation-01.txt
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: 7
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2017-09-14
>>
>> Abstract:
>>=C2=A0 =C2=A0 This document describes how the use of the Secure Rea= l-time transport
>>=C2=A0 =C2=A0 protocol (SRTP) [RFC3711]. can be negotiated using th= e RTP/AVP (Audio
>>=C2=A0 =C2=A0 Video Profile) defined in [RFC3551].=C2=A0 Such a mec= hanism is used to
>>=C2=A0 =C2=A0 provide a means for encrypted media to be used in env= ironments where
>>=C2=A0 =C2=A0 support for encryption is not known in advance, and n= ot required.
>>=C2=A0 =C2=A0 The same mechanism is also applied to negotiation of = the Extended RTP
>>=C2=A0 =C2=A0 Profile for Real-time Transport Control Protocol Base= d Feedback (RTP/
>>=C2=A0 =C2=A0 AVPF) [RFC4585].
>>
>>
>> The IETF datatracker status page for this draft is:
>>
>>https://datatracker= .ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiat
>>ion/
>>
>> There are also htmlized versions available at:
>>
>>https://tools.ietf.= org/html/draft-ietf-mmusic-opportunistic-negotiation-0
>>1
>>
>>https://datatracker= .ietf.org/doc/html/draft-ietf-mmusic-opportunistic-neg
>>otiation-01
>>
>> A diff from the previous version is available at:
>>
>>https://www.ietf.= org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-negotia >>tion-01
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >>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/
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmus= ic
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic

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

--94eb2c1cdeea1958ed055994c8fa-- From nobody Wed Sep 20 03:48:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC0133087; Wed, 20 Sep 2017 03:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RxBrpvq3-PUf; Wed, 20 Sep 2017 03:48:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 A6899132355; Wed, 20 Sep 2017 03:48:23 -0700 (PDT) X-AuditID: c1b4fb30-683ff70000007145-23-59c2477556d1 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.D4.28997.57742C95; Wed, 20 Sep 2017 12:48:21 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 20 Sep 2017 12:48:21 +0200 From: Christer Holmberg To: Christer Holmberg , mmusic WG , "mmusic-chairs@ietf.org" , "Ben Campbell" Thread-Topic: [MMUSIC] Doodle poll: Call to discuss DTLS-SDP issue on whether an SDP answerer can trigger a new DTLS association Thread-Index: AQHTMf34aqnl+u00rUOJMo/bWdlv1g== Date: Wed, 20 Sep 2017 10:48:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D5E822B521DB2christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdS7fU/VCkwftWBYv5nafZLc7vXM9k MXX5YxYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK2PFlSnsBScXMFbs+m3ewNjSy9jF yMkhIWAisWHRetYuRi4OIYEjjBKXl2wGSwgJLGKUeHSzoouRg4NNwEKi+582SI2IwBpGiQc/ jjCBOMICjYwSLQfesEFkmhglZu75xALSLSKgJ7Hy7BdmEJtFQFWi43QPK4jNK2AtsXX7VrAa RgExie+n1jCB2MwC4hK3nsxngjhJQGLJnvPMELaoxMvH/8B6RYFmbjhxmx3kIgkBJYlpW9Mg WhMkLn+cCjVeUOLkzCcsExiFZiGZOgtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceAzVay1x pHcSE7KaBYwcqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECo+nglt8GOxhfPnc8xCjAwajE wzsr9mCkEGtiWXFl7iFGCQ5mJRFeBedDkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfddiBAS SE8sSc1OTS1ILYLJMnFwSjUwtt44crVG8IjLvgRXF/Uts/QXpdhlMwm0XeBRueF9+8ejzzlR B/cFOe+YFiNp1Ke8//Pt5PfV9RP//+nQPtu29f1+l1b2TdLyx9TTp0nN+XI9lz/Koitx26dt i2Z7zWLOua1pMb0/5UfnC2GNovMMG/4K3e3q2LNv0rzvm53Zt4eu9/6onx0VoMRSnJFoqMVc VJwIAKuNg1uiAgAA Archived-At: Subject: Re: [MMUSIC] Doodle poll: Call to discuss DTLS-SDP issue on whether an SDP answerer can trigger a new DTLS association X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 10:48:26 -0000 --_000_D5E822B521DB2christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the poll result, I will organise the call next week Thursday 28th. Unfortunately there was no option that was ok for everyone, but as I consid= er the participation of Ekr and Roman most essential, I picked a day that w= orks for both of them. Phone details will follow. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Tuesday 19 September 2017 at 22:05 To: "mmusic@ietf.org" >, "mmusic-chairs@ietf.org" >, Ben Campbell > Subject: [MMUSIC] Doodle poll: Call to discuss DTLS-SDP issue on whether an= SDP answerer can trigger a new DTLS association Hi, I am planning to set up a call to discuss the issue with draft-dtls-sdp on = whether an SDP answerer is allowed to trigger a new DTLS association. In case you are not familiar with the issue, below is a description (provid= ed by Roman) in a nutshell, followed by a doodle poll for a phone call to d= iscuss the issue. What do we want to discuss? If an SDP answerer can request a new DTLS association if the SDP offerer en= d point did not request it. When and why can this happen? This happens during third party call control (3PCC). Imagine a call being s= etup between end points A and B through the third party call control agent = 3PCC. 3PCC requests end point A for a new offer. This offer will always ini= tiate ICE restart (https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sd= p-13#section-8.5) and it currently is not required to have a new tls-id. If= offer from end point A is generated with the current tls-id and sent by 3P= CC as a new offer to an end point C, a new DTLS association must be establi= shed between A and C. This will be detected by end point A, when it gets th= e answer from end point C which will contain a new tls-id, or, in legacy RF= C 5763 case, new fingerprints. How can this be implemented? Current draft allows an answerer to establish a new DTLS association in the= answer to any offer without ICE or any offer with ICE restart. The only wa= y I have managed to get the current specification to work is by monitoring = packets which are received over new ICE candidate pairs discovered after IC= E restart. If DTLS ClientHello packet is received, it is assumed that remot= e end point initiated a new DTLS association and received packets are queue= d until answer is received. If other DTLS packets or non-DTLS (SRTP) packet= s are received, they are processed as if they were part of the previous DTL= S association or SRTP flow established using a previous DTLS association. What are the arguments for allowing answering end point to establish new DT= LS associations? 1. This allows support for common 3PCC and B2BUA scenarios. Without 3PCC ca= ll scenario support, SIP end points could not be DTLS enabled 2. This is already allowed by RFC 5763 and is required for legacy interop 3. If DTLS extension is ever developed that allows de-mux multiple DTLS ass= ociations over the same underlying transport, then new DTLS associations ca= n be established and torn down independently of the underlying transport, s= o that it would be natural for either party to initiate it. How this can cause problems? 1. Any packets received from the time the offier is sent until the answer i= s received over a new transport 5-tuple are ambiguous in the sense that the= y can belong to the existing DTLS association or the new DTLS association e= stablished by the answering end point. There is no way to resolve this with= out an "ugly" solution that mixes several different protocol levels (DTLS C= lient Hello detector). This also requires buffering that is not ideal. 2. It is unclear if new DTLS association and new data channels (which need = to be re-established if DTLS association is re-established) would be create= d as a result of an offer/answer exchange when the offer is sent. This comp= licates API design 3. 3PCC is evil and confusing and should be avoided. There is no way to gen= erate o=3D lines, allocate payloads, etc across multiple end points in a wa= y that is consistent and compliant with JSEP. Because of this 3PCC agent ca= n never be a JSEP compliant end point. Implementations will be a lot simple= r if 3PCC scenarios were not supported and communications were always betwe= en two fixed end points. P.S. What do we agree upon and not discussing? ICE restart does not establish a new DTLS association on its own. ICE resta= rt is required when new DTLS association is established, but new DTLS assoc= iation MUST be explicitly requested by one of the parties. Doodle poll: https://doodle.com/poll/y9szwrn57a5b4k7h Regards, Christer --_000_D5E822B521DB2christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Based on the poll result, I will organise the call next week Thursday = 28th.

Unfortunately there was no option that was ok for everyone, but as I c= onsider the participation of Ekr and Roman most essential, I picked a day t= hat works for both of them.

Phone details will follow.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Tuesday 19 September 2017 at = 22:05
To: "mmusic@ietf.org" <= mmusic@ietf.org>, "mm= usic-chairs@ietf.org" <mmusic-chairs@ietf.org>, Ben Campbell <ben@nostrum.com>= ;
Subject: [MMUSIC] Doodle poll: Call= to discuss DTLS-SDP issue on whether an SDP answerer can trigger a new DTL= S association

Hi,

 

I am planning to set up a call to discu= ss the issue with draft-dtls-sdp on whether an SDP answerer is allowed to t= rigger a new DTLS association.

 

In case you are not familiar with the i= ssue, below is a description (provided by Roman) in a nutshell, followed by= a doodle poll for a phone call to discuss the issue.

 

What do we want to discuss?

 

If an SDP answerer can request a ne= w DTLS association if the SDP offerer end point did not request it.

 

When and why can this happen?

 

This happens during third party cal= l control (3PCC). Imagine a call being setup between end points A and B thr= ough the third party call control agent 3PCC. 3PCC requests end point A for a new offer. This offer will always initiate= ICE restart (https://tools.ietf.org/html/draft-ietf-mmusic-ice-s= ip-sdp-13#section-8.5) and it currently is not required to have a new tls-id. If offer from end point A = is generated with the current tls-id and sent by 3PCC as a new offer to an = end point C, a new DTLS association must be established between A and C. Th= is will be detected by end point A, when it gets the answer from end point C which will contain a new = tls-id, or, in legacy RFC 5763 case, new fingerprints.

 

How can this be implemented?

 

Current draft allows an answerer to= establish a new DTLS association in the answer to any offer without ICE or= any offer with ICE restart. The only way I have managed to get the current specification to work is by monitoring packets = which are received over new ICE candidate pairs discovered after ICE restar= t. If DTLS ClientHello packet is received, it is assumed that remote end po= int initiated a new DTLS association and received packets are queued until answer is received. If other DTLS pa= ckets or non-DTLS (SRTP) packets are received, they are processed as if the= y were part of the previous DTLS association or SRTP flow established using= a previous DTLS association.

 

What are the arguments for allow= ing answering end point to establish new DTLS associations?

 

1. This allows support for common 3= PCC and B2BUA scenarios. Without 3PCC call scenario support, SIP end points= could not be DTLS enabled 

 

2. This is already allowed by RFC 5= 763 and is required for legacy interop

 

3. If DTLS extension is ever develo= ped that allows de-mux multiple DTLS associations over the same underlying = transport, then new DTLS associations can be established and torn down independently of the underlying transport, so that it would = be natural for either party to initiate it.

 

How this can cause problems?

 

1. Any packets received from the ti= me the offier is sent until the answer is received over a new transport 5-t= uple are ambiguous in the sense that they can belong to the existing DTLS association or the new DTLS association establ= ished by the answering end point. There is no way to resolve this without a= n "ugly" solution that mixes several different protocol levels (D= TLS Client Hello detector). This also requires buffering that is not ideal.

 

2. It is unclear if new DTLS associ= ation and new data channels (which need to be re-established if DTLS associ= ation is re-established) would be created as a result of an offer/answer exchange when the offer is sent. This complicate= s API design

 

3. 3PCC is evil and confusing and s= hould be avoided. There is no way to generate o=3D lines, allocate payloads= , etc across multiple end points in a way that is consistent and compliant with JSEP. Because of this 3PCC agent can never b= e a JSEP compliant end point. Implementations will be a lot simpler if 3PCC= scenarios were not supported and communications were always between two fi= xed end points.

 

P.S. What do we agree upon = and not discussing?

 

ICE restart does not establish a ne= w DTLS association on its own. ICE restart is required when new DTLS associ= ation is established, but new DTLS association MUST be explicitly requested by one of the parties.

 

Doodle poll: https://doodle.com/poll/y9szwrn57a5b4k7= h

 

Regards,

 

Christer

 =

--_000_D5E822B521DB2christerholmbergericssoncom_-- From nobody Wed Sep 20 04:20:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386A213234B for ; Wed, 20 Sep 2017 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 8vaRbW8oJaF2 for ; Wed, 20 Sep 2017 04:19:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1BD621342C5 for ; Wed, 20 Sep 2017 04:19:56 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-74-59c24eda51fb Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.97.21299.ADE42C95; Wed, 20 Sep 2017 13:19:55 +0200 (CEST) Received: from [100.94.33.127] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 20 Sep 2017 13:19:54 +0200 To: IETF MMUSIC WG From: Magnus Westerlund Message-ID: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com> Date: Wed, 20 Sep 2017 13:20:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080309050109010000000208" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7q+5tv0ORBldusFlMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGadPKBQsDqu4cvUrewPjBt8uRk4OCQETiSPfpzF3MXJxCAkc YZSYdKwLytnEKHH04D0WkCoRARWJf+8esIHYbAIWEjd/NILZwgJmEoeX72YEsXkF7CWa9u5l 72Lk4GARUJVoO+4OEhYViJH4eekRC0SJoMTJmU9YQOYzC3QzSpx6vZAZJCEkoC3R0NTBCnGR ksT1eddZJjDyzkLSMwtZD0iCWSBM4smTHawQtrhE05eVULatxJ25u6FqtCWWLXwNZetKLNq2 gh1T3Fpixq+DbBC2osSU7odQNaYSr49+ZISwjSTe7WlkX8DIs4pRtDi1OCk33chYL7UoM7m4 OD9PLy+1ZBMjMCoObvmtuoPx8hvHQ4wCHIxKPLxX4w9GCrEmlhVX5h5iVAGa82jD6guMUix5 +XmpSiK8i7wORQrxpiRWVqUW5ccXleakFh9ilOZgURLnddx3IUJIID2xJDU7NbUgtQgmy8TB KdXAqPSstFlusnDRj0qt+vtTT+oYbr/68N8R+Yg5pcz7LlreEE91mcs113xb+R3TFQcaNszQ aFBq49c4eEIv6lX8pleurWUf5GMmGgt8Cftjpjn7fnWh7PEjM/U4sk59rmbeHf/O0vMgw6Mo iXYHFXerLy+eRH6rmn1v4d/wjzJnuAzuve6/uOZ7uxJLcUaioRZzUXEiAHAvii2SAgAA Archived-At: Subject: [MMUSIC] Existing missmatch between SDP mux and BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 11:20:00 -0000 --------------ms080309050109010000000208 Content-Type: multipart/alternative; boundary="------------C0A2F42E62573179607817EA" Content-Language: en-GB This is a multi-part message in MIME format. --------------C0A2F42E62573179607817EA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which=20 references Bundle and SDP-Mux as it defines the mux category for its SDP = attributes. As we made some last minute changes to MUX catergory for the = extmap-allowed-mixed attribute we found some text needing changes. This=20 anyway resulted in us noticing a missmatch between BUNDLE and sdp-mux. So Bundle (-39) states: 8.1. Mux Category Considerations When an offerer or answerer associates SDP attributes with a bundled "m=3D" line (including any bundle-only "m=3D" line) associated with a= shared address, IDENTICAL and TRANSPORT mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=3D" line only if the "m=3D" line is also associated with the offerer/ answerer BUNDLE-tag. Otherwise the offerer/answerer MUST NOT associate such SDP attributes with the "m=3D" line. The rule above does not apply to a bundled "m=3D" line associated with a unique address. However, SDP-mux states: 4.3. Category: IDENTICAL The attributes and their associated values (if any) in the IDENTICAL category MUST be repeated across all the media descriptions under multiplexing. To my understanding the first is correct, but the change in BUNDLE has no= t been reflected into SDP-mux doc. I assume that is in part due to its approved = status. Has the authors tracked the set of changes that are needed due to changes= in BUNDLE? Do there exist a text change for this missmatch? Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------C0A2F42E62573179607817EA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which references Bundle and SDP-Mux as it defines the mux category for its SDP attributes. As we made some last minute changes to MUX catergory for the extmap-allowed-mixed attribute we found some text needing changes. This anyway resulted in us noticing a missmatch between BUNDLE and sdp-mux.

So Bundle (-39) states:

8.1. Mux Category Considerations 

   When an offerer or answerer associates SDP attributes with a bundled
   "m=3D" line (including any bundle-only "m=3D" line) associated with a
   shared address, IDENTICAL and TRANSPORT mux category SDP attributes
   [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=3D"
   line only if the "m=3D" line is also associated with the offerer/
   answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
   associate such SDP attributes with the "m=3D" line.  The rule above
   does not apply to a bundled "m=3D" line associated with a unique
   address.


However, SDP-mux states:

4.3.  Category: IDENTICAL

   The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

To my understanding the first is correct, but the change in BUNDLE has no=
t been=20
reflected into SDP-mux doc. I assume that is in part due to its approved =
status.=20
Has the authors tracked the set of changes that are needed due to changes=
 in BUNDLE?

Do there exist a text change for this missmatch?


Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------C0A2F42E62573179607817EA--

--------------ms080309050109010000000208
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzA5MjAxMTIwMjVaMC8GCSqGSIb3DQEJBDEiBCCiXBsJMcxfMb2fDZkG
m9YWWm8xgWJ+k0biWzXEJfjNPTBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAg23VR1ZxKh5IxsWTdKdGqyNha6Tgwr13VVhr0QFTOUYT0k8g
t/J7QJ7ICj3tylL0JL3ho/S3yT/hPMxOQhcrtCrwCzMq3swJQ0jmFNjHeAhQk1VwQ5UkRSC2
T6yV40AKW6zWOICGsyy/Vhpy6zbhQTsGFM6FH8hIVBattjpg5eKkXP63b7Wob/sjVyfDa7oN
KTmlNsXzcYUfeRTnIqarRXudkhVuLWm7grkltg3JpTV6ENcMX9gxVMfZxJ1gTXJbKS3Mh7iM
nkfMn3ynZMXpWw/Pc/4UGBsBHc7ZxjwFN6XTRPgWgfnR7NMgsGtt01gFhZWBDPtusLYjmCyH
hDnfAwAAAAAAAA==
--------------ms080309050109010000000208--


From nobody Thu Sep 21 15:21:38 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9837C133207; Thu, 21 Sep 2017 15:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnyR7dvUYpyi; Thu, 21 Sep 2017 15:21:36 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6581321D8; Thu, 21 Sep 2017 15:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=746; q=dns/txt; s=iport; t=1506032495; x=1507242095; h=to:from:subject:cc:message-id:date:mime-version: content-transfer-encoding; bh=V2Y7GqMh2TEyurLQWt4LRLFHyBkENIpDRKM0WODRpW0=; b=Zgr93zfK6tTXi3R4fO24/fTEK/NQt9E6g/ZM3qE8X9zz4w+uyWBtYZs/ rfhBjpoOmXyRxOVuL8H/qXfTb7ld87SWl6t6QNHR2/QDbuS/Y40i4hcWh lCWSKPo7zslTq91o4IkqQzdGmtOqlnyidLLTdRMone4Vxkdu1BjuZp+3H M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAQDxOcRZ/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieDdpobgUmOQoR0PYR0CiOFGIQWQxQBAgEBAQEBAQFrKIV?= =?us-ascii?q?CFUE1AiYCXw0IAQGKIg0Qp02CJ4sDAQEBAQEBAQMBAQEBAQEdBYEOgh2CAoFRg?= =?us-ascii?q?WQriwuCYAWhE4FtjBqGUYIThWuDWocmlT6BOTYhgQ1TJBVJhRkcggMkNgGLXwE?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.42,426,1500940800"; d="scan'208";a="296273753"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 22:21:35 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v8LMLYe6005750; Thu, 21 Sep 2017 22:21:34 GMT
To: mmusic 
From: Flemming Andreasen 
Cc: draft-ietf-mmusic-rid@ietf.org, draft-ietf-mmusic-sdp-simulcast@ietf.org
Message-ID: <70919c2b-6ca3-e79a-e0a8-8d272cb01c11@cisco.com>
Date: Thu, 21 Sep 2017 18:22:01 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [MMUSIC] Getting ready to PubReq rid and simulcast drafts
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 22:21:38 -0000

Greetings

We previously completed WGLC on the rid draft (now 
https://www.ietf.org/id/draft-ietf-mmusic-rid-11.txt) and the simulcast 
draft (now 
https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-10.txt). 
Comments from those WGLCs and (in the case of rid) a subsequent shepherd 
review have been addressed in the latest version of each draft and at 
this point we are planning to move forward with Publication Request.

We are hereby giving people one final chance to look at these documents 
before moving them forward. If you have any concern with either 
document, please send a note to that effect to the chairs, authors and 
the MMUSIC list no later than September 28, 2017.

Thanks

-- Flemming (MMUSIC co-chair)


From nobody Fri Sep 22 06:04:20 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCFC132F76 for ; Fri, 22 Sep 2017 06:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgvceOoLSb3D for ; Fri, 22 Sep 2017 06:04:16 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843F2134460 for ; Fri, 22 Sep 2017 06:04:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9001; q=dns/txt; s=iport; t=1506085447; x=1507295047; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=7yvOPKCwW5KRmoogVBFt2Uw/jPMBKjH6krhNzBRIP1A=; b=AVIbTHgBBMu/yd+jUnjDY23o0UEyWNZlizPakdxmmSj0l0yk7Dcb9fv5 Ek1ceWJOHlZyuGmo0OSQWCDRtHwzr6AC4KAuJsc+g1GJODJD3CLAdmUA2 7RRE2sl7nQmyxFHf1UspAt4bNXcorwHwzMg402qwf/+BcP3VnU870NWcd I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQAMCcVZ/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieDdpobgUkriD+IK4dRChgBCoRJTwKEI0MUAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEBAQMBASFLCxALGCcDAgIhBh8RBgEMBgIBAYoXAwgNEKZYgicnhwwNg?= =?us-ascii?q?z4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMrggKBUYFkK4J9glmFNYJgBaBZPId?= =?us-ascii?q?diAaEeYtbhyiMZIhfgTk2IYEOUyUVSYRhglgkNgEBiVUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,427,1500940800";  d="scan'208,217";a="301704908"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2017 13:04:06 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v8MD45DZ021432; Fri, 22 Sep 2017 13:04:06 GMT
To: Roman Shpount , Suhas Nandakumar 
Cc: mmusic WG 
References: 
From: Flemming Andreasen 
Message-ID: <5dd35b5a-dda7-a96d-e281-5e313d16b63e@cisco.com>
Date: Fri, 22 Sep 2017 09:04:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F395C7A147FB5743B8FC2D2F"
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] ICE-SIP-SDP updates
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 13:04:18 -0000

This is a multi-part message in MIME format.
--------------F395C7A147FB5743B8FC2D2F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Any further comments on this ? If not, when can we get the updates in so 
we can move forward with the document ?

Thanks

-- Flemming

On 9/18/17 5:33 AM, Roman Shpount wrote:
> Hi Suhas,
>
>
> On Mon, Sep 18, 2017 at 12:15 AM, Suhas Nandakumar 
> > wrote:
>
>     1. Handling of ICE mismatch
>
>     Where is ICE mismatch currently defined? I cannot find this in
>     either rfc5245bis or ICE-SIP-SDP.
>
>     I think ICE mismatch should occur if address in c= line and port
>     in m= line do not match any of the candidates and address in
>     c= line is not dummy address IN IP4 0.0.0.0 and port in m= line is
>     not dummy port 9 . This is needed to match
>     https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-21#section-5.2.1
>     
>     and trickle ICE
>
>     [Suhas] ICE mismatch is discussed in 4.1.2.3,  4.1.3.1 and 11.2.2
>
>
> [roman] Section 4.1.2.3 should be modified to allow c= line with IN 
> IP4 0.0.0.0 and port in m= line with port 9 not to be treated as 
> ice-mismatch even if it does not match any of the candidates. Without 
> this, trickle ICE and JSEP will cause ice-mismatch. Furthermore, rtcp 
> attribute is optional, so the text needs to be modified to allow for this.
>
>     2. Move general requirements from
>     https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-26#section-12.2
>     
>     into ICE-SIP-SDP.
>
>     [Suhas] Added the supporting text in the above PR. Also the
>     repository has HTML file for easy reading.
>
>
> [roman] This looks good, but I will double check and provide comments 
> if I find anything.
>
>
>     3. ICE transport tag
>
>     [Suhas] IIRC, this topic was brought to discussion several times
>     in the WG and there was no consensus on defining a new ICE
>     specific transport tag. Personally, I feel this will be a large
>     undertaking and we should avoid doing this as part of this draft
>     work. I am open to suggestions.
>
>
>  [roman]  I agree that this can be left out and handled in the future 
> draft if there is enough support for it.
>
> Regards,
> _____________
> Roman Shpount
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--------------F395C7A147FB5743B8FC2D2F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Any further comments on this ? If not, when can we get the updates
    in so we can move forward with the document ? 

    

    Thanks 

    

    -- Flemming 

    

    
On 9/18/17 5:33 AM, Roman Shpount
      wrote:

    

    

      
      
Hi Suhas,

        


          

            


            

          

          
On Mon, Sep 18, 2017 at 12:15 AM,
            Suhas Nandakumar <suhasietf@gmail.com>
            wrote:

            

              

                
1. Handling of ICE mismatch

                

                

                  


                  

                  
Where is ICE mismatch currently defined? I cannot
                    find this in either rfc5245bis or ICE-SIP-SDP. 

                  


                  

                  
I think ICE mismatch should occur if address in
                    c= line and port in m= line do not match any of the
                    candidates and <new>address in c= line is not
                    dummy address IN IP4 0.0.0.0 and port in m= line is
                    not dummy port 9 </new>. This is needed to
                    match https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-21#section-5.2.1
                    and trickle ICE

                  


                  

                  
[Suhas] ICE mismatch is discussed in 4.1.2.3,
                     4.1.3.1 and 11.2.2

                

              

            

            


            

            
[roman] Section 4.1.2.3 should be modified to allow c=
              line with IN IP4 0.0.0.0 and port in m= line with port 9
              not to be treated as ice-mismatch even if it does not
              match any of the candidates. Without this, trickle ICE and
              JSEP will cause ice-mismatch. Furthermore, rtcp attribute
              is optional, so the text needs to be modified to allow for
              this.

            


            

            

              

                

                  
2. Move general requirements from https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-26#section-12.2
                    into ICE-SIP-SDP.

                  

                  


                  

                  
[Suhas] Added the supporting text in the above
                    PR. Also the repository has HTML file for easy
                    reading.

                  

                

              

            

            


            

            
[roman] This looks good, but I will double check and
              provide comments if I find anything.

            

              

                

                  


                  

                  
3. ICE transport tag

                  


                  

                  
[Suhas] IIRC, this topic was brought to
                    discussion several times in the WG and there was no
                    consensus on defining a new ICE specific transport
                    tag. Personally, I feel this will be a large
                    undertaking and we should avoid doing this as part
                    of this draft work. I am open to suggestions.

                  

                

                


                

              

            

            


            

            
 [roman]  I agree that this can be left out and handled
              in the future draft if there is enough support for it.

            


            

            

              

                
Regards,

                
_____________

                  Roman Shpount

              

            

            


            

          

        

      

      

      

      

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


    

    

  


--------------F395C7A147FB5743B8FC2D2F--


From nobody Fri Sep 22 06:28:40 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EA81330B1 for ; Fri, 22 Sep 2017 06:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TO_rX4QZjWp for ; Fri, 22 Sep 2017 06:28:36 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AA5132F76 for ; Fri, 22 Sep 2017 06:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6916; q=dns/txt; s=iport; t=1506086916; x=1507296516; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=KNtkv4Q1QAgjdv2MEXuY+OAj1QJJUV7mmL1UsvaoqVc=; b=apRvNxaNcyhWlhIxONro8IohzbqKs0Bo7vbPu73Seb87qUEHVaXZN2uY 5L1u7rxpnjX094WkuZl9Oh4TFyfIqv1KktmGeFmgjDZXm3/SOFGcDQ83N NVPpJpnV/2KeVLTmlk4iXWkPwNbxMW6Bm44xZJTK4A2tlpp3l0KmuQE4Z 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeAQArD8VZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieeEYFJCSKQaoU/ghIKGAEKhElPAoQjQBcBAgEBAQEBAQF?= =?us-ascii?q?rKIUZAQEBAwEBbBkCCxgnBxsMHxEGAQwGAgEBiiINEKh7J4pXAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAUFgyaCAoFRgWQrC4Jyim4Fig+XBpRci1uHKJVDgTkhAjR?= =?us-ascii?q?CTFMlFUmHOSQ2iVcBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,427,1500940800";  d="scan'208,217";a="298734998"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2017 13:28:35 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8MDSYDq010596; Fri, 22 Sep 2017 13:28:34 GMT
To: Magnus Westerlund , IETF MMUSIC WG 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>
From: Flemming Andreasen 
Message-ID: 
Date: Fri, 22 Sep 2017 09:29:00 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>
Content-Type: multipart/alternative; boundary="------------4C10FD2229D3447304316ABF"
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 13:28:38 -0000

This is a multi-part message in MIME format.
--------------4C10FD2229D3447304316ABF
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Hi Magnus

Can you elaborate on the mismatch ? I understand they do not say the 
same thing, but it's not clear to me they are actually in conflict with 
each other.

How do you interpret the line ("associate" in particular)

Otherwise the offerer/answerer MUST NOT associate such SDP attributes 
with the "m=" line.


Is the issue that bundle is relaxing the MUST requirement in bundle ?

Thanks

-- Flemming

On 9/20/17 7:20 AM, Magnus Westerlund wrote:
>
> Hi,
>
> We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which 
> references Bundle and SDP-Mux as it defines the mux category for its 
> SDP attributes. As we made some last minute changes to MUX catergory 
> for the extmap-allowed-mixed attribute we found some text needing 
> changes. This anyway resulted in us noticing a missmatch between 
> BUNDLE and sdp-mux.
>
> So Bundle (-39) states:
>
> 8.1. Mux Category Considerations
>
>     When an offerer or answerer associates SDP attributes with a bundled
>     "m=" line (including any bundle-only "m=" line) associated with a
>     shared address, IDENTICAL and TRANSPORT mux category SDP attributes
>     [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
>     line only if the "m=" line is also associated with the offerer/
>     answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
>     associate such SDP attributes with the "m=" line.  The rule above
>     does not apply to a bundled "m=" line associated with a unique
>     address.
>
>
> However, SDP-mux states:
>
> 4.3. Category: IDENTICAL
>
>     The attributes and their associated values (if any) in the IDENTICAL
>     category MUST be repeated across all the media descriptions under
>     multiplexing.
>
> To my understanding the first is correct, but the change in BUNDLE has not been
> reflected into SDP-mux doc. I assume that is in part due to its approved status.
> Has the authors tracked the set of changes that are needed due to changes in BUNDLE?
>
> Do there exist a text change for this missmatch?
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--------------4C10FD2229D3447304316ABF
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi Magnus

    

    Can you elaborate on the mismatch ? I understand they do not say the
    same thing, but it's not clear to me they are actually in conflict
    with each other. 

    

    How do you interpret the line ("associate" in particular)

    <quote>

    Otherwise the offerer/answerer MUST NOT associate such SDP
    attributes with the "m=" line.
    

    <quote>

    

    Is the issue that bundle is relaxing the MUST requirement in bundle
    ? 

    

    Thanks

    

    -- Flemming 

    

    
On 9/20/17 7:20 AM, Magnus Westerlund
      wrote:

    

    

      
      
Hi,

      
We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis
        which references Bundle and SDP-Mux as it defines the mux
        category for its SDP attributes. As we made some last minute
        changes to MUX catergory for the extmap-allowed-mixed attribute
        we found some text needing changes. This anyway resulted in us
        noticing a missmatch between BUNDLE and sdp-mux.

      
So Bundle (-39) states: 

        

      
8.1. Mux Category Considerations 

      
   When an offerer or answerer associates SDP attributes with a bundled
   "m=" line (including any bundle-only "m=" line) associated with a
   shared address, IDENTICAL and TRANSPORT mux category SDP attributes
   [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
   line only if the "m=" line is also associated with the offerer/
   answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
   associate such SDP attributes with the "m=" line.  The rule above
   does not apply to a bundled "m=" line associated with a unique
   address.


However, SDP-mux states:

4.3.  Category: IDENTICAL

   The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

To my understanding the first is correct, but the change in BUNDLE has not been 
reflected into SDP-mux doc. I assume that is in part due to its approved status. 
Has the authors tracked the set of changes that are needed due to changes in BUNDLE?

Do there exist a text change for this missmatch?


Cheers 

Magnus Westerlund 

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

      

      

      

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


    

    

  


--------------4C10FD2229D3447304316ABF--


From nobody Fri Sep 22 06:40:33 2017
Return-Path: 
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6921342DE; Fri, 22 Sep 2017 06:40:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, mmusic@ietf.org, ben@nostrum.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150608763121.16498.14057447669967232574.idtracker@ietfa.amsl.com>
Date: Fri, 22 Sep 2017 06:40:31 -0700
Archived-At: 
Subject: [MMUSIC] mmusic - New Meeting Session Request for IETF 100
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 13:40:31 -0000

A new meeting session request has just been submitted by Flemming Andreasen, a Chair of the mmusic working group.


---------------------------------------------------------
Working Group Name: Multiparty Multimedia Session Control
Area Name: Applications and Real-Time Area
Session Requester: Flemming Andreasen

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 40
Conflicts to Avoid: 
 First Priority: quic perc tls ice httpbis rtcweb avtcore sipcore dispatch payload core dots sipbrandy
 Second Priority: clue xrblock rmcat stir tram sfc regext



People who must be present:
  Ben Campbell
  Flemming Andreasen
  Bo Burman

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Fri Sep 22 07:56:36 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE5B13447E for ; Fri, 22 Sep 2017 07:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wS_MtzoSE9lo for ; Fri, 22 Sep 2017 07:56:32 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1402A13447B for ; Fri, 22 Sep 2017 07:56:31 -0700 (PDT)
X-AuditID: c1b4fb25-d31059c000005333-5f-59c5249edeef
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 32.6F.21299.E9425C95; Fri, 22 Sep 2017 16:56:30 +0200 (CEST)
Received: from [100.94.57.210] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 22 Sep 2017 16:56:03 +0200
To: Flemming Andreasen , IETF MMUSIC WG 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com> 
From: Magnus Westerlund 
Message-ID: <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>
Date: Fri, 22 Sep 2017 16:56:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060203080109030002080901"
X-Originating-IP: [153.88.183.153]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7ge48laORBsce8lu8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK6N3RitjwedGxooHzVuZGxg353cxcnJICJhI fLl/l6WLkYtDSOAIo8TRn6egnE2MEp9brjN2MXJwCAs4SxxZGwnSICLgK/GpYR8LiC0kUCQx /d9URhCbTcBC4uaPRjYQm1fAXqJp529mkFYWAVWJM50OIGFRgRiJn5cesUCUCEqcnPkEzOYU sJV4cPYtO8haZoFuRonr0+5AzdeWaGjqYIU4VEni+rzrLBMY+Wch6Z+FrAckwSwQJjHv4X8m CFtcounLSlYI21biztzdzBC2tsSyha+hbF2JRdtWsGOKW0vM+HWQDcJWlJjS/RCqxlTi9dGP jBC2kcS7PY3sCxh5VjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERtbBLb9VdzBefuN4iFGA g1GJh9dN8GikEGtiWXFl7iFGFaA5jzasvsAoxZKXn5eqJMK7SR4ozZuSWFmVWpQfX1Sak1p8 iFGag0VJnNdx34UIIYH0xJLU7NTUgtQimCwTB6dUA2PsSnm/95OYjaTn/C1e1b+84F5X8uOG z5PfeZakuhf+Px/mcjD/sr2rYNzFZGenZ53hdgc+xfrvtpjxpGyJpIv9xKnH9t/92xCrZnaC a4PwhH/i6QcP9MSLCdp5uPxbJKxftPtLcknQ+iWrPt150yQeOlH+3vZGFfuTnnqq2XaruOMz Z+5NVVZiKc5INNRiLipOBAD6KuMQtAIAAA==
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 14:56:35 -0000

--------------ms060203080109030002080901
Content-Type: multipart/alternative;
 boundary="------------77986451CD3F5A8695A2E13A"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------77986451CD3F5A8695A2E13A
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

SDP Mux says:

The attributes and their associated values (if any) in the IDENTICAL
    category MUST be repeated across all the media descriptions under
    multiplexing.

This I interpret as you really MUST include it each and every m=3D sectio=
n that are bundled.
While BUNDLE with its updated text says, that you only should include the=
 SDP attribute in the m=3D sections
that are first on any a=3Dgroup:BUNDLE line, and not in another unless th=
ey have unique
transport information for the case of legacy fallback into individual lin=
es.

Thus, I see SDP-mux require inclusion of the SDP attribute on each m=3D s=
ection in all cases and BUNDLE to
forbid such includion with the m=3D section in some cases. Thus, in those=
 cases there is a conflict between
two different MUST statements.

Cheers

Magnus



Den 2017-09-22 kl. 15:29, skrev Flemming Andreasen:
> Hi Magnus
>
> Can you elaborate on the mismatch ? I understand they do not say the=20
> same thing, but it's not clear to me they are actually in conflict=20
> with each other.
>
> How do you interpret the line ("associate" in particular)
> 
> Otherwise the offerer/answerer MUST NOT associate such SDP attributes=20
> with the "m=3D" line.
> 
>
> Is the issue that bundle is relaxing the MUST requirement in bundle ?
>
> Thanks
>
> -- Flemming
>
> On 9/20/17 7:20 AM, Magnus Westerlund wrote:
>>
>> Hi,
>>
>> We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which=20
>> references Bundle and SDP-Mux as it defines the mux category for its=20
>> SDP attributes. As we made some last minute changes to MUX catergory=20
>> for the extmap-allowed-mixed attribute we found some text needing=20
>> changes. This anyway resulted in us noticing a missmatch between=20
>> BUNDLE and sdp-mux.
>>
>> So Bundle (-39) states:
>>
>> 8.1. Mux Category Considerations
>>
>>     When an offerer or answerer associates SDP attributes with a bundl=
ed
>>     "m=3D" line (including any bundle-only "m=3D" line) associated wit=
h a
>>     shared address, IDENTICAL and TRANSPORT mux category SDP attribute=
s
>>     [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=3D=
"
>>     line only if the "m=3D" line is also associated with the offerer/
>>     answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
>>     associate such SDP attributes with the "m=3D" line.  The rule abov=
e
>>     does not apply to a bundled "m=3D" line associated with a unique
>>     address.
>>
>>
>> However, SDP-mux states:
>>
>> 4.3. Category: IDENTICAL
>>
>>     The attributes and their associated values (if any) in the IDENTIC=
AL
>>     category MUST be repeated across all the media descriptions under
>>     multiplexing.
>>
>> To my understanding the first is correct, but the change in BUNDLE has=
 not been
>> reflected into SDP-mux doc. I assume that is in part due to its approv=
ed status.
>> Has the authors tracked the set of changes that are needed due to chan=
ges in BUNDLE?
>>
>> Do there exist a text change for this missmatch?
>>
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------=

>> Media Technologies, Ericsson Research
>> ----------------------------------------------------------------------=

>> Ericsson AB                 | Phone  +46 10 7148287
>> Torshamnsgatan 23           | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------=

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

--=20

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------77986451CD3F5A8695A2E13A
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Hi,

    

    SDP Mux says: 

    

    
The attributes and their ass=
ociated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

This I interpret as you really MUST include it each and every m=3D sectio=
n that are bundled.=20
While BUNDLE with its updated text says, that you only should include the=
 SDP attribute in the m=3D sections
that are first on any a=3Dgroup:BUNDLE line, and not in another unless th=
ey have unique=20
transport information for the case of legacy fallback into individual lin=
es.=20

Thus, I see SDP-mux require inclusion of the SDP attribute on each m=3D s=
ection in all cases and BUNDLE to=20
forbid such includion with the m=3D section in some cases. Thus, in those=
 cases there is a conflict between=20
two different MUST statements.

Cheers

Magnus=20


    

    

    
Den 2017-09-22 kl. 15:29, skrev
      Flemming Andreasen:

    

    

      
      Hi Magnus

      

      Can you elaborate on the mismatch ? I understand they do not say
      the same thing, but it's not clear to me they are actually in
      conflict with each other. 

      

      How do you interpret the line ("associate" in particular)

      <quote>

      Otherwise the offerer/answerer MUST NOT associate such SDP
      attributes with the "m=3D" line. 

      <quote>

      

      Is the issue that bundle is relaxing the MUST requirement in
      bundle ? 

      

      Thanks

      

      -- Flemming 

      

      
On 9/20/17 7:20 AM, Magnus Westerlun=
d
        wrote:

      

      

        
Hi,

        
We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis
          which references Bundle and SDP-Mux as it defines the mux
          category for its SDP attributes. As we made some last minute
          changes to MUX catergory for the extmap-allowed-mixed
          attribute we found some text needing changes. This anyway
          resulted in us noticing a missmatch between BUNDLE and
          sdp-mux.

        
So Bundle (-39) states: 

          

        
8.1. Mux Category Considerations 
        
   When an offerer or an=
swerer associates SDP attributes with a bundled
   "m=3D" line (including any bundle-only "m=3D" line) associated with a
   shared address, IDENTICAL and TRANSPORT mux category SDP attributes
   [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=3D"
   line only if the "m=3D" line is also associated with the offerer/
   answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
   associate such SDP attributes with the "m=3D" line.  The rule above
   does not apply to a bundled "m=3D" line associated with a unique
   address.


However, SDP-mux states:

4.3.  Category: IDENTICAL

   The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

To my understanding the first is correct, but the change in BUNDLE has no=
t been=20
reflected into SDP-mux doc. I assume that is in part due to its approved =
status.=20
Has the authors tracked the set of changes that are needed due to changes=
 in BUNDLE?

Do there exist a text change for this missmatch?


Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
        

        

        

        
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/mmusic


      

      

    

    

    
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------77986451CD3F5A8695A2E13A--

--------------ms060203080109030002080901
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzA5MjIxNDU2MzFaMC8GCSqGSIb3DQEJBDEiBCDQg0r2VqYTM4Acwu6F
g3PECwyn9wxeQwlEV973WU+w4zBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAYPrReyWdzouYknCkPsvNPU3mxO6jdoZuPp73SkhUujmC/IkH
56g3erU+PRPI9I3MxXWNL2qWTwOR9vL0xs18a/NZt7r5XvUOqaGviX17+xVh/ZSqS4XNIojt
ZQiZAQRGtHpxoGML9hxC/KFCke1amR2edWUZmnxqbEHB/qkeOGaDGSNM+C+xwyo0cyIbU/qZ
tZd5XBel1uu/c+/WzdZ7YFfk76q1TAEjsYuYkws6Ue5cz4XbqlqRuwPhNoaRT9962X0J9HsP
62jrl9mOh+h401OXavc6EV+4MYqC3AcgCdX0L4O/PRz8V+DwL/XCrxlsVxO6zSpH4FGY8Kgq
GpIutwAAAAAAAA==
--------------ms060203080109030002080901--


From nobody Fri Sep 22 09:19:56 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5939134518 for ; Fri, 22 Sep 2017 09:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGNE5ghXs7Bg for ; Fri, 22 Sep 2017 09:19:53 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF45134521 for ; Fri, 22 Sep 2017 09:19:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12083; q=dns/txt; s=iport; t=1506097193; x=1507306793; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=jZto3nnovHt9BeGEvUZ+SkN8eAV8tO0JprkE/6eZAFA=; b=WzBAt8tcGhfGQ2F/RU+B4BUWzE7YH/hrTPIn1xUDKWXMipl5qZjxwY4J 53uhbRlKCDU2INJDnRhl44VSGI181OR8xWzjYal5Bai7x/Ns29s06Oi26 hW8ZL5ho7D1FgLcAeyOT0md03mbetCmrv/mnhcksH7TU2f9jjQ726EGax M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAQANN8VZ/4MNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieeEIFJK5BqhT+CEgoYAQqESU8ChCRBFgECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBAWwQCQILGCcHGwwfEQYBDAYCAQGKIgUIEKkdJ4puAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAUFgyaCAoFRgWQrgn2KbgWKD446iEyUXItbhyiVQ4E?= =?us-ascii?q?5JgQtQkxTJRVJhzkkNolXAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,427,1500940800";  d="scan'208,217";a="302386845"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2017 16:19:52 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8MGJpfU005595; Fri, 22 Sep 2017 16:19:51 GMT
To: Magnus Westerlund , IETF MMUSIC WG , "Christer Holmberg (JO/LMF)" 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>
From: Flemming Andreasen 
Message-ID: 
Date: Fri, 22 Sep 2017 12:20:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>
Content-Type: multipart/alternative; boundary="------------54A561CCDD1FD34C8ADC7051"
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 16:19:55 -0000

This is a multi-part message in MIME format.
--------------54A561CCDD1FD34C8ADC7051
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



On 9/22/17 10:56 AM, Magnus Westerlund wrote:
> Hi,
>
> SDP Mux says:
>
> The attributes and their associated values (if any) in the IDENTICAL
>     category MUST be repeated across all the media descriptions under
>     multiplexing.
>
> This I interpret as you really MUST include it each and every m= section that are bundled.
Agreed.
> While BUNDLE with its updated text says, that you only should include the SDP attribute in the m= sections
> that are first on any a=group:BUNDLE line, and not in another unless they have unique
> transport information for the case of legacy fallback into individual lines.
It depends on how we interpret "associated with" - if it simply means 
"included as part of the media description" then I agree with you.


> Thus, I see SDP-mux require inclusion of the SDP attribute on each m= section in all cases and BUNDLE to
> forbid such includion with the m= section in some cases. Thus, in those cases there is a conflict between
> two different MUST statements.
I think you are right - maybe Christer can clarify the "associated with" 
term ?

Thanks

-- Flemming


> Cheers
>
> Magnus
>
>
> Den 2017-09-22 kl. 15:29, skrev Flemming Andreasen:
>> Hi Magnus
>>
>> Can you elaborate on the mismatch ? I understand they do not say the 
>> same thing, but it's not clear to me they are actually in conflict 
>> with each other.
>>
>> How do you interpret the line ("associate" in particular)
>> 
>> Otherwise the offerer/answerer MUST NOT associate such SDP attributes 
>> with the "m=" line.
>> 
>>
>> Is the issue that bundle is relaxing the MUST requirement in bundle ?
>>
>> Thanks
>>
>> -- Flemming
>>
>> On 9/20/17 7:20 AM, Magnus Westerlund wrote:
>>>
>>> Hi,
>>>
>>> We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which 
>>> references Bundle and SDP-Mux as it defines the mux category for its 
>>> SDP attributes. As we made some last minute changes to MUX catergory 
>>> for the extmap-allowed-mixed attribute we found some text needing 
>>> changes. This anyway resulted in us noticing a missmatch between 
>>> BUNDLE and sdp-mux.
>>>
>>> So Bundle (-39) states:
>>>
>>> 8.1. Mux Category Considerations
>>>
>>>     When an offerer or answerer associates SDP attributes with a bundled
>>>     "m=" line (including any bundle-only "m=" line) associated with a
>>>     shared address, IDENTICAL and TRANSPORT mux category SDP attributes
>>>     [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
>>>     line only if the "m=" line is also associated with the offerer/
>>>     answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
>>>     associate such SDP attributes with the "m=" line.  The rule above
>>>     does not apply to a bundled "m=" line associated with a unique
>>>     address.
>>>
>>>
>>> However, SDP-mux states:
>>>
>>> 4.3. Category: IDENTICAL
>>>
>>>     The attributes and their associated values (if any) in the IDENTICAL
>>>     category MUST be repeated across all the media descriptions under
>>>     multiplexing.
>>>
>>> To my understanding the first is correct, but the change in BUNDLE has not been
>>> reflected into SDP-mux doc. I assume that is in part due to its approved status.
>>> Has the authors tracked the set of changes that are needed due to changes in BUNDLE?
>>>
>>> Do there exist a text change for this missmatch?
>>>
>>>
>>> Cheers
>>>
>>> Magnus Westerlund
>>>
>>> ----------------------------------------------------------------------
>>> Media Technologies, Ericsson Research
>>> ----------------------------------------------------------------------
>>> Ericsson AB                 | Phone  +46 10 7148287
>>> Torshamnsgatan 23           | Mobile +46 73 0949079
>>> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
>>> ----------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> -- 
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------


--------------54A561CCDD1FD34C8ADC7051
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

    
On 9/22/17 10:56 AM, Magnus Westerlund
      wrote:

    

    

      
      Hi,

      

      SDP Mux says: 

      

      
The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

This I interpret as you really MUST include it each and every m= section that are bundled. 

    

    Agreed.

    

      
While BUNDLE with its updated text says, that you only should include the SDP attribute in the m= sections
that are first on any a=group:BUNDLE line, and not in another unless they have unique 
transport information for the case of legacy fallback into individual lines. 


    

    It depends on how we interpret "associated with" - if it simply
    means "included as part of the media description" then I agree with
    you. 

    

    

    

      
Thus, I see SDP-mux require inclusion of the SDP attribute on each m= section in all cases and BUNDLE to 
forbid such includion with the m= section in some cases. Thus, in those cases there is a conflict between 
two different MUST statements.


    

    I think you are right - maybe Christer can clarify the "associated
    with" term ? 

    

    Thanks 

    

    -- Flemming 

    

    

    

      
Cheers

Magnus 


      

      

      
Den 2017-09-22 kl. 15:29, skrev
        Flemming Andreasen:

      

      

        
        Hi Magnus

        

        Can you elaborate on the mismatch ? I understand they do not say
        the same thing, but it's not clear to me they are actually in
        conflict with each other. 

        

        How do you interpret the line ("associate" in particular)

        <quote>

        Otherwise the offerer/answerer MUST NOT associate such SDP
        attributes with the "m=" line. 

        <quote>

        

        Is the issue that bundle is relaxing the MUST requirement in
        bundle ? 

        

        Thanks

        

        -- Flemming 

        

        
On 9/20/17 7:20 AM, Magnus
          Westerlund wrote:

        

        

          
Hi,

          
We are currently in AUTH48 for
            draft-ietf-avtcore-rfc5285bis which references Bundle and
            SDP-Mux as it defines the mux category for its SDP
            attributes. As we made some last minute changes to MUX
            catergory for the extmap-allowed-mixed attribute we found
            some text needing changes. This anyway resulted in us
            noticing a missmatch between BUNDLE and sdp-mux.

          
So Bundle (-39) states: 

            

          
8.1. Mux Category Considerations 

          
   When an offerer or answerer associates SDP attributes with a bundled
   "m=" line (including any bundle-only "m=" line) associated with a
   shared address, IDENTICAL and TRANSPORT mux category SDP attributes
   [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
   line only if the "m=" line is also associated with the offerer/
   answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
   associate such SDP attributes with the "m=" line.  The rule above
   does not apply to a bundled "m=" line associated with a unique
   address.


However, SDP-mux states:

4.3.  Category: IDENTICAL

   The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

To my understanding the first is correct, but the change in BUNDLE has not been 
reflected into SDP-mux doc. I assume that is in part due to its approved status. 
Has the authors tracked the set of changes that are needed due to changes in BUNDLE?

Do there exist a text change for this missmatch?


Cheers 

Magnus Westerlund 

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

          

          

          

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


        

        

      

      

      
-- 

Magnus Westerlund 

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

    

    

  


--------------54A561CCDD1FD34C8ADC7051--


From nobody Fri Sep 22 10:25:27 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149F213452A for ; Fri, 22 Sep 2017 10:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHzbonJqN1Ql for ; Fri, 22 Sep 2017 10:25:22 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11922126B6E for ; Fri, 22 Sep 2017 10:25:22 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id a43so1431376wrc.0 for ; Fri, 22 Sep 2017 10:25:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=orlIN67nIHffPMvYDU52PP18cVEjK3JoAoKO8IGOJYg=; b=Kf/WEcNW58Cb3WQyeZuythFyQ/Azs5PqQtS9A8aNzOFo6mfNYN8qII7AUDwnI3/ge5 TyQc0u3hGJ/jsVyriU8pUg2C8JXWx717IMNDrag+O5xJoN4YmA5u3sVZ15caCqseHP25 Xaw/iYty6U/6Pt4HyzdunU0vF83Fe7b7ymime2OmYN+7OYfTyVappLA16EKQO0+bnzF0 LTSlrk3s0aR6dWypJkQG1fyh5F9MZR19tfBZq8vG58Iipu8qyoJg8MrnNSRk6axy2b4h m44V63hdK7farDDHZ/zwABuqrxoNlzFlLj6i9ptt2QnTBETy+Po+DUijQoHz4jySlveu sLlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=orlIN67nIHffPMvYDU52PP18cVEjK3JoAoKO8IGOJYg=; b=XME+UsCOX5dZ4USdGCAHcd7cQxAx5Uf0ZKZ4M1gTr7jj/9Ka9fjHDdxBJggbjs31l0 wFJZArig3wMJTFP+fEIpo//2nHp8lpI+fk7tXFe8thCUb3YEvgKORbW2CAKt74qJKAeD iyxTtI1n1+JIVt6Kwrmx0xAfjd1D4m82gg0W5luxpLJJcIyNf8UrPCRIahKLDIVN56Yz 0U69gFvkJUZzEMCF4Ww3qrPq9FbOR0VKMfufgUlV+upgX+xm4xbfu9ebrm/PdsTrcNiD 92WLMHGb0htHyQPUMhDrrutejK0ZVsNcTYQLOPUIbkgbRNI9+RYfntksiAAgjOT5/w+s Y2YQ==
X-Gm-Message-State: AHPjjUgRurTbahbq3yHLKUbTiRO0YwNJgFKRvRQ7KdzqwsJSsoNm4Sb8 svSqx3Q0HQc9jeU+ocOPtETHTx5515cOcm2feYPbgQ==
X-Google-Smtp-Source: AOwi7QDAvy5ogQbj1SiR4+kWqrralZI/eBmGibv+fQ91yuHNbXq03V5C/iq8sQPDN+6csEQuzEukvCLUZ6fJmOWrUnY=
X-Received: by 10.223.169.7 with SMTP id u7mr5857801wrc.37.1506101120233; Fri, 22 Sep 2017 10:25:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.54 with HTTP; Fri, 22 Sep 2017 10:25:19 -0700 (PDT)
In-Reply-To: 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com> 
From: Taylor Brandstetter 
Date: Fri, 22 Sep 2017 19:25:19 +0200
Message-ID: 
To: Flemming Andreasen 
Cc: Magnus Westerlund , IETF MMUSIC WG ,  "Christer Holmberg (JO/LMF)" 
Content-Type: multipart/alternative; boundary="f403045cf12c44cb3f0559ca7ec8"
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 17:25:26 -0000

--f403045cf12c44cb3f0559ca7ec8
Content-Type: text/plain; charset="UTF-8"

>
> It depends on how we interpret "associated with"


That's why I purged "associated with" from the BUNDLE spec:
https://github.com/taylor-b/draft-sdp-bundle/pull/1

It almost always can be interpreted in multiple ways. Unfortunately this
never got integrated, I assume because I was too late.

Anyway: the intention here, as can be found in the mailing list history,
was that IDENTICAL attributes are only placed in one m= section (the
BUNDLE-tag section) when there's no fallback to becoming un-bundled. This
avoids redundant information in SDP, wasting bytes in signaling messages.
Example:

*Initial offer (supports being received by non-BUNDLE endpoint):*

a=group:BUNDLE foo bar
m=...
a=identical:baz
a=mid:foo
m=...
a=identical:baz
a=mid:bar

*Answer:*

a=group:BUNDLE foo bar
m=...
a=identical:baz
a=mid:foo
m=...
a=mid:bar

*Subsequent offer:*

a=group:BUNDLE foo bar
m=...
a=identical:baz
a=mid:foo
m=...
a=mid:bar

So yes, sdp-mux-attributes needs to be updated.

On Fri, Sep 22, 2017 at 6:20 PM, Flemming Andreasen 
wrote:

>
>
> On 9/22/17 10:56 AM, Magnus Westerlund wrote:
>
> Hi,
>
> SDP Mux says:
>
> The attributes and their associated values (if any) in the IDENTICAL
>    category MUST be repeated across all the media descriptions under
>    multiplexing.
>
> This I interpret as you really MUST include it each and every m= section that are bundled.
>
> Agreed.
>
> While BUNDLE with its updated text says, that you only should include the SDP attribute in the m= sections
> that are first on any a=group:BUNDLE line, and not in another unless they have unique
> transport information for the case of legacy fallback into individual lines.
>
> It depends on how we interpret "associated with" - if it simply means
> "included as part of the media description" then I agree with you.
>
>
> Thus, I see SDP-mux require inclusion of the SDP attribute on each m= section in all cases and BUNDLE to
> forbid such includion with the m= section in some cases. Thus, in those cases there is a conflict between
> two different MUST statements.
>
> I think you are right - maybe Christer can clarify the "associated with"
> term ?
>
> Thanks
>
> -- Flemming
>
>
> Cheers
>
> Magnus
>
>
>
> Den 2017-09-22 kl. 15:29, skrev Flemming Andreasen:
>
> Hi Magnus
>
> Can you elaborate on the mismatch ? I understand they do not say the same
> thing, but it's not clear to me they are actually in conflict with each
> other.
>
> How do you interpret the line ("associate" in particular)
> 
> Otherwise the offerer/answerer MUST NOT associate such SDP attributes with
> the "m=" line.
> 
>
> Is the issue that bundle is relaxing the MUST requirement in bundle ?
>
> Thanks
>
> -- Flemming
>
> On 9/20/17 7:20 AM, Magnus Westerlund wrote:
>
> Hi,
>
> We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which
> references Bundle and SDP-Mux as it defines the mux category for its SDP
> attributes. As we made some last minute changes to MUX catergory for the
> extmap-allowed-mixed attribute we found some text needing changes. This
> anyway resulted in us noticing a missmatch between BUNDLE and sdp-mux.
>
> So Bundle (-39) states:
>
> 8.1. Mux Category Considerations
>
>    When an offerer or answerer associates SDP attributes with a bundled
>    "m=" line (including any bundle-only "m=" line) associated with a
>    shared address, IDENTICAL and TRANSPORT mux category SDP attributes
>    [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m="
>    line only if the "m=" line is also associated with the offerer/
>    answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
>    associate such SDP attributes with the "m=" line.  The rule above
>    does not apply to a bundled "m=" line associated with a unique
>    address.
>
>
> However, SDP-mux states:
> 4.3.  Category: IDENTICAL
>
>    The attributes and their associated values (if any) in the IDENTICAL
>    category MUST be repeated across all the media descriptions under
>    multiplexing.
>
> To my understanding the first is correct, but the change in BUNDLE has not been
> reflected into SDP-mux doc. I assume that is in part due to its approved status.
> Has the authors tracked the set of changes that are needed due to changes in BUNDLE?
>
> Do there exist a text change for this missmatch?
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287 <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079 <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
>
> _______________________________________________
> mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287 <+46%2010%20714%2082%2087>
> Torshamnsgatan 23           | Mobile +46 73 0949079 <+46%2073%20094%2090%2079>
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--f403045cf12c44cb3f0559ca7ec8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


It depends on how we interpret "associated=C2=A0with"
<=
div>
That's why I purged "associated with" from=
 the BUNDLE spec: https://github.com/taylor-b/draft-sdp-bundle/pull/1=C2=A0
<=
div>
It almost always can be interpreted in multiple ways. Un=
fortunately this never got integrated, I assume because I was too late.

Anyway: the intention here, as can be found in the ma=
iling list history, was that IDENTICAL attributes are only placed in one m=
=3D section (the BUNDLE-tag section) when there's no fallback to becomi=
ng un-bundled. This avoids redundant information in SDP, wasting bytes in s=
ignaling messages. Example:

Initial offer (supp=
orts being received by non-BUNDLE endpoint):

a=
=3Dgroup:BUNDLE foo bar
m=3D...
a=3Didentical:baz
=

a=3Dmid:foo
m=3D...
a=3Didentical:baz
a=
=3Dmid:bar

Answer:

a=3Dgroup:BUNDLE foo bar
m=3D...
a=3Dident=
ical:baz
a=3Dmid:foo
m=3D...
a=3Dmid:bar

Subsequent offer:

a=3Dgroup:BUNDLE foo bar
m=3D...
a=3Diden=
tical:baz
a=3Dmid:foo
m=3D...
a=3Dmid:bar

So yes, sdp-mux-attributes needs to be updated.=


On Fr=
i, Sep 22, 2017 at 6:20 PM, Flemming Andreasen <fandreas@cisco.com>=
; wrote:

 =20
   =20
 =20
  

    

    

    
On 9/22/17 10:56 A=
M, Magnus Westerlund
      wrote:

    

    

     =20
      Hi,

      

      SDP Mux says: 

      

      
The at=
tributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

This I interpret as you really MUST include it each and every m=3D section =
that are bundled. 

    

    Agreed.

    

      
While =
BUNDLE with its updated text says, that you only should include the SDP att=
ribute in the m=3D sections
that are first on any a=3Dgroup:BUNDLE line, and not in another unless they have unique=
=20
transport information for the case of legacy fallback into individual lines=
.=20


    

    It depends on how we interpret "associated with" - if it simp=
ly
    means "included as part of the media description" then I agre=
e with
    you. 

    

    

    

      
Thus, =
I see SDP-mux require inclusion of the SDP attribute on each m=3D section i=
n all cases and BUNDLE to=20
forbid such includion with the m=3D section in some cases. Thus, in those c=
ases there is a conflict between=20
two different MUST statements.


    

    I think you are right - maybe Christer can clarify the "associated
    with" term ? 

    

    Thanks 

    

    -- Flemming 

    

    

    

      
Cheers

Magnus=20


      

      

      
Den 2017-09-22 k=
l. 15:29, skrev
        Flemming Andreasen:

      

      

       =20
        Hi Magnus

        

        Can you elaborate on the mismatch ? I understand they do not say
        the same thing, but it's not clear to me they are actually in
        conflict with each other. 

        

        How do you interpret the line ("associate" in particular)=


        <quote>

        Otherwise the offerer/answerer MUST NOT associate such SDP
        attributes with the "m=3D" line. 

        <quote>

        

        Is the issue that bundle is relaxing the MUST requirement in
        bundle ? 

        

        Thanks

        

        -- Flemming 

        

        
On 9/20/17 7:2=
0 AM, Magnus
          Westerlund wrote:

        

        

          
Hi,

          
We are currently in AUTH48 for
            draft-ietf-avtcore-rfc5285bis which references Bundle and
            SDP-Mux as it defines the mux category for its SDP
            attributes. As we made some last minute changes to MUX
            catergory for the extmap-allowed-mixed attribute we found
            some text needing changes. This anyway resulted in us
            noticing a missmatch between BUNDLE and sdp-mux.

          
So Bundle (-39) states: 

            

          
8.1. Mux Category Co=
nsiderations 

          
  =
 When an offerer or answerer associates SDP attributes with a bundled
   "m=3D" line (including any bundle-only "m=3D" line) =
associated with a
   shared address, IDENTICAL and TRANSPORT mux category SDP attributes
   [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "=
m=3D"
   line only if the "m=3D" line is also associated with the offer=
er/
   answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
   associate such SDP attributes with the "m=3D" line.  The rule =
above
   does not apply to a bundled "m=3D" line associated with a uniq=
ue
   address.


However, SDP-mux states:

4.3.  Category: IDENTICAL

   The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

To my understanding the first is correct, but the change in BUNDLE has not =
been=20
reflected into SDP-mux doc. I assume that is in part due to its approved st=
atus.=20
Has the authors tracked the set of changes that are needed due to changes i=
n BUNDLE?

Do there exist a text change for this missmatch?


Cheers=20

Magnus Westerlund=20

-----------------------------------------------------------------=
-----
Media Technologies, Ericsson Research
-----------------------------------------------------------------=
-----
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------=
-----

          

          

          

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


        

        

      

      

      
--=20

Magnus Westerlund=20

-----------------------------------------------------------------=
-----
Media Technologies, Ericsson Research
-----------------------------------------------------------------=
-----
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------=
-----

    

    

  



_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic




--f403045cf12c44cb3f0559ca7ec8--


From nobody Fri Sep 22 12:38:28 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB61345B1 for ; Fri, 22 Sep 2017 12:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wl-TMNMDyrr7 for ; Fri, 22 Sep 2017 12:38:24 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 31D451345B0 for ; Fri, 22 Sep 2017 12:38:24 -0700 (PDT)
X-AuditID: c1b4fb30-66bff70000007145-08-59c566adfd11
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.FF.28997.DA665C95; Fri, 22 Sep 2017 21:38:22 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Fri, 22 Sep 2017 21:38:21 +0200
From: Christer Holmberg 
To: Flemming Andreasen , Magnus Westerlund , IETF MMUSIC WG 
Thread-Topic: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
Thread-Index: AQHTMgJpHMZ02x0tykSASSt9LrLCX6LAx/MAgAAYdICAABdngIAAV2mA
Date: Fri, 22 Sep 2017 19:38:21 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B562F08AD@ESESSMB109.ericsson.se>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7iu66tKORBlMOc1u8v6BrMXX5YxYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+NMF0vBYZWKJz97WRoY18l2MXJwSAiYSHy4 5djFyMUhJHCEUWLttj2MEM4iRokjvffYQIrYBCwkuv9pg8RFBJoZJXa+72TvYuTkEBZwlmh6 MpkFxBYRcJHY8vAZM4TtJrH0029WEJtFQFXi/vw5YDW8Ar4SN2eeZYNYcJtR4v79lUwgCU4B W4nXy/aADWUUEJP4fmoNWJxZQFzi1pP5YLaEgIDEkj3nmSFsUYmXj/+xQthKEotuf4aq15FY sPsTG4StLbFs4WtmiMWCEidnPmGZwCgyC8nYWUhaZiFpmYWkZQEjyypG0eLU4qTcdCMjvdSi zOTi4vw8vbzUkk2MwGg4uOW3wQ7Gl88dDzEKcDAq8fCuSz4aKcSaWFZcmXuIUYKDWUmEd28i UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6YklqdmpqQWpRTBZJg5OqQbGyPTITSa3 drzsOCjNsUhFtnrBoZ1aIk+PlF9yW/ZZMjhVgcv97LP+N4bu4V+lg55seq28XKd+StbGNc80 i7Ztjawz3HNNwWGnVaDRUzshF77mmuOzmZNzZBRXsy79rxf+1inqisibTbbXngqrXXjyf36L b+KD+3aX/lQcOWTT/Y+zb9LcT1vTlFiKMxINtZiLihMBm2vC74ICAAA=
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 19:38:26 -0000

Hi,

>> SDP Mux says:=20
>>
>>    The attributes and their associated values (if any) in the IDENTICAL
>>    category MUST be repeated across all the media descriptions under
>>    multiplexing.
>>
>> This I interpret as you really MUST include it each and every m=3D secti=
on that are bundled.=20
> Agreed.

Perhaps the text should say "applies to all media descriptions", and then a=
 sentence saying the individual usages need to define in which m- lines the=
 attribute must be explicitly included..

>> While BUNDLE with its updated text says, that you only should include th=
e SDP attribute in the m=3D sections
>> that are first on any a=3Dgroup:BUNDLE line, and not in another unless t=
hey have unique=20
>>transport information for the case of legacy fallback into individual lin=
es.=20
>
> It depends on how we interpret "associated with" - if it simply means "in=
cluded as part of the media description" then I agree with you.=20

That's what it means.

>> Thus, I see SDP-mux require inclusion of the SDP attribute on each m=3D =
section in all cases and BUNDLE to=20
>> forbid such includion with the m=3D section in some cases. Thus, in thos=
e cases there is a conflict between=20
>> two different MUST statements.
>
> I think you are right - maybe Christer can clarify the "associated with" =
term ?=20

Unless the DRAFT clarifies that to you, we really need to do something...

Regards,

Christer







Den 2017-09-22 kl. 15:29, skrev Flemming Andreasen:
Hi Magnus

Can you elaborate on the mismatch ? I understand they do not say the same t=
hing, but it's not clear to me they are actually in conflict with each othe=
r.=20

How do you interpret the line ("associate" in particular)

Otherwise the offerer/answerer MUST NOT associate such SDP attributes with =
the "m=3D" line.=20


Is the issue that bundle is relaxing the MUST requirement in bundle ?=20

Thanks

-- Flemming=20
On 9/20/17 7:20 AM, Magnus Westerlund wrote:
Hi,
We are currently in AUTH48 for draft-ietf-avtcore-rfc5285bis which referenc=
es Bundle and SDP-Mux as it defines the mux category for its SDP attributes=
. As we made some last minute changes to MUX catergory for the extmap-allow=
ed-mixed attribute we found some text needing changes. This anyway resulted=
 in us noticing a missmatch between BUNDLE and sdp-mux.
So Bundle (-39) states:=20
8.1. Mux Category Considerations=20
   When an offerer or answerer associates SDP attributes with a bundled
   "m=3D" line (including any bundle-only "m=3D" line) associated with a
   shared address, IDENTICAL and TRANSPORT mux category SDP attributes
   [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=3D"
   line only if the "m=3D" line is also associated with the offerer/
   answerer BUNDLE-tag.  Otherwise the offerer/answerer MUST NOT
   associate such SDP attributes with the "m=3D" line.  The rule above
   does not apply to a bundled "m=3D" line associated with a unique
   address.


However, SDP-mux states:

4.3.  Category: IDENTICAL

   The attributes and their associated values (if any) in the IDENTICAL
   category MUST be repeated across all the media descriptions under
   multiplexing.

To my understanding the first is correct, but the change in BUNDLE has not =
been=20
reflected into SDP-mux doc. I assume that is in part due to its approved st=
atus.=20
Has the authors tracked the set of changes that are needed due to changes i=
n BUNDLE?

Do there exist a text change for this missmatch?


Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------



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



--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Fri Sep 22 12:51:41 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6653F1345C3 for ; Fri, 22 Sep 2017 12:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GbaHrkyrnD-X for ; Fri, 22 Sep 2017 12:51:39 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C79FC1345C1 for ; Fri, 22 Sep 2017 12:51:38 -0700 (PDT)
X-AuditID: c1b4fb30-66bff70000007145-0c-59c569c8498a
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 05.21.28997.8C965C95; Fri, 22 Sep 2017 21:51:37 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Fri, 22 Sep 2017 21:51:36 +0200
From: Christer Holmberg 
To: Taylor Brandstetter , Flemming Andreasen 
CC: Magnus Westerlund , IETF MMUSIC WG 
Thread-Topic: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
Thread-Index: AQHTMgJpHMZ02x0tykSASSt9LrLCX6LAx/MAgAAYdICAABdngIAAEiyAgABG5CA=
Date: Fri, 22 Sep 2017 19:51:36 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdSfdk5tFIgzefuCwur3jIavH+gq7F 1OWPWRyYPab83sjqsWBTqceSJT+ZApijuGxSUnMyy1KL9O0SuDL+HLnOUvCGp+L7/XbmBsYD PF2MnBwSAiYSi892MncxcnEICRxhlHi35AcThLOIUeLPNJAMBwebgIVE9z9tkAYRgQiJ5+8f M4PYzAJREk8XzWIBsYUFnCWankxmgahxkdjy8BkzhO0nce3+GzCbRUBVonfeCrAaXgFfiRd7 Z7FB7WKS+HL6FBPILk6BQInFM/1AahgFxCS+n1rDBLFLXOLWk/lMEEcLSCzZc54ZwhaVePn4 HyuErSSx9vB2FpAxzAKaEut36UO0KkpM6X7IDrFWUOLkzCcsExhFZyGZOguhYxaSjllIOhYw sqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIyZg1t+G+xgfPnc8RCjAAejEg/vuuSjkUKs iWXFlbmHGCU4mJVEeIvSgEK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfddiBASSE8sSc1OTS1I LYLJMnFwSjUwcjA+E/8ZE/rY9LTxW0fhx5w3Zsq6Fjy+GvKDneu1AePn9RmsC2+pTJ12v3kn g0dziJ3aqUVXcy75NXzqcrh0Jt9u+0aH6c/e6Xius+jJOZhyX+hswQqjVWk3tpc43tuedq7Z t7on74pj0fk25tR9ts5OnjqTW/vtRBwbfeoO7rj78dnS87KblFiKMxINtZiLihMB7hsZpJUC AAA=
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 19:51:40 -0000

SGksDQoNCj4+IEl0IGRlcGVuZHMgb24gaG93IHdlIGludGVycHJldCAiYXNzb2NpYXRlZMKgd2l0
aCINCj4NCj4gVGhhdCdzIHdoeSBJIHB1cmdlZCAiYXNzb2NpYXRlZCB3aXRoIiBmcm9tIHRoZSBC
VU5ETEUgc3BlYzogaHR0cHM6Ly9naXRodWIuY29tL3RheWxvci1iL2RyYWZ0LXNkcC1idW5kbGUv
cHVsbC8xwqANCj4NCj4gSXQgYWxtb3N0IGFsd2F5cyBjYW4gYmUgaW50ZXJwcmV0ZWQgaW4gbXVs
dGlwbGUgd2F5cy4gVW5mb3J0dW5hdGVseSB0aGlzIG5ldmVyIGdvdCBpbnRlZ3JhdGVkLCBJIGFz
c3VtZSBiZWNhdXNlIEkgd2FzIHRvbyBsYXRlLg0KDQpObywgeW91IHdlcmUgbm90IDopIEkgaGF2
ZSBiZWVuIGxvb2tpbmcgYXQgeW91ciBDUiwgYW5kIGhhdmUgYmVlbiBjb25zaWRlcmluZyB0byBp
bnRlZ3JhdGUgaXQsIGJ1dCBJIGxhdGVseSBJIGhhdmUgYmVlbiBzbyBidXN5IHdpdGggZHJhZnQt
ZHRscy1zZHAgZXRjLg0KDQpIYXZpbmcgc2FpZCB0aGF0LCB3ZSBoYXZlIGNoYW5nZWQgdGhlIHRl
cm1pbm9sb2d5IGluIGJ1bmRsZSBhIG51bWJlciBvZiB0aW1lcyBhbHJlYWR5IC0gd2UgcmVhbGx5
IG5lZWQgdG8gc3RvcCBhdCBzb21lIHBvaW50Lg0KDQpUaGUgaGlzdG9yeSBvZiAiYXNzb2NpYXRl
ZCIgaXMgd2hlbiBwZW9wbGUgY29tbWVudGVkIHRoYXQgb25lIGNhbm5vdCBhZGQgYW4gYXR0cmli
dXRlLCBhZGRyZXNzIGV0YyB0byBhbiBtLSBsaW5lIChiZWNhdXNlIGF0dHJpYnV0ZXMsIGMtIGxp
bmVzIGFuZCBtLSBsaW5lcyBhcmUgc2VwYXJhdGUgU0RQIHByb3BlcnRpZXMpLiBTbywgaW5zdGVh
ZCBvZiB0YWxraW5nIGFib3V0IGFkZGluZyB0aG9zZSB0byBhbiBtLSBsaW5lIHRhbGsgYWJvdXQg
YXNzb2NpYXRpbmcgdGhvc2Ugd2l0aCBhbiBtLSBsaW5lLg0KDQpOb3csIGlmIEkgcmVtZW1iZXIg
dGhlIGNoYW5nZXMgaW4geW91ciBQUiBjb3JyZWN0bHksIHlvdSBhcmUgdGFsa2luZyBhYm91dCAi
bWVkaWEgZGVzY3JpcHRpb25zIiwgd2hpY2ggd291bGQgYmUgYW4gImVudmVsb3BlIiBjb250YWlu
aW5nIHRoZSBtLSBsaW5lLCB0aGUgYWRkcmVzcyBhbmQgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdp
dGggdGhhdCBtLSBsaW5lLiBUaGVuIHlvdSBjb3VsZCBzYXkgImFkZCBhdHRyaWJ1dGUgdG8gdGhl
IG1lZGlhIGRlc2NyaXB0aW9uIiwgZXRjLiBSaWdodD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN
Cg==


From nobody Fri Sep 22 13:08:36 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF2A132D67 for ; Fri, 22 Sep 2017 13:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azqK-hbrvowT for ; Fri, 22 Sep 2017 13:08:33 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F730132198 for ; Fri, 22 Sep 2017 13:08:33 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id w12so1682802wrc.7 for ; Fri, 22 Sep 2017 13:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=omgyLctYVxJKEp0WsgS51hx/H1ckI2rlO8NbxCCgIjQ=; b=HSuC5PPUsAqWdPpgf5NsQfjeYUnT0rTyN/ZRDTxzd2kDsU5rMvmFN1evnylPSTzgdx 8LLBu4x/2tijqLVRMu2tHcX2IeoEbbro/vI+k/OpGfGiXOUPxVeSAkbeZeaiRaIsxQ1/ IzF94dcssURiCqzb89KX3o5ygsa+uaSvyu4c34eV5JQiEX8bt+X3csJCrKFlNtr+Ub+9 3QGQhwJ0F0uma3Nece+Y53IlhltrKaw6OC3mrMgYc/jnv02RNYkAXp0bylNCH8r/oXwf lds4pPaITz3WIsVWI6LlPSAI5x0rqGFV+MdfHw5Z/0KVkJUiOMSkHDkKLF1XWGzz6pe3 gWxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=omgyLctYVxJKEp0WsgS51hx/H1ckI2rlO8NbxCCgIjQ=; b=eDRra0HCMvw4jLBZVI18UF4gFXTK0XBYhy+291sFg0aAQE4P6zjXr0gAU3g5aUmvsl WC/ZqI1GrdCnrm1EjPx+vs3HYLQyfWi9ITK/PipHBKG44gCizYhDhVTzPNegluQNhGeS KBVJAHijO/GQS0z71MEZgPmUSb/LHTfr/p41q5w1b+JDTmnt6tAfDpRlcl54aFd/IkEj VCp6mEynEJTo/KFJEm1F/vZ0fji1x5g2SQWY+sBBALYu3mge8u0njHGfdO14SXo5Rpbs 3klZjUclT2BRKX9Wa5RSUcvoUvnxUVMFCQD6vEJVrPBwXW63ydRUtLs1Ypmv/+kE403x eTOQ==
X-Gm-Message-State: AHPjjUgxhaKCDxhHfNnKOvR/gmjyBnmEqaY9aHNmvuUp34byZ1jQ92r2 tBBRx+2CxpN0Sji0f/rRybWKvLIIO89jshpbvO2eCA==
X-Google-Smtp-Source: AOwi7QCdKOI2bsiEfSmdsRhnCcLnsedZmscDldDZMnzbhVuDAXZN8g0ZGt/DXaglySsiE3MNh0NGjOFHmz9bkT1ZLK8=
X-Received: by 10.223.135.155 with SMTP id b27mr239237wrb.10.1506110911457; Fri, 22 Sep 2017 13:08:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.54 with HTTP; Fri, 22 Sep 2017 13:08:30 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>
From: Taylor Brandstetter 
Date: Fri, 22 Sep 2017 22:08:30 +0200
Message-ID: 
To: Christer Holmberg 
Cc: Flemming Andreasen , Magnus Westerlund ,  IETF MMUSIC WG 
Content-Type: multipart/alternative; boundary="001a11461a06deff1b0559ccc5ee"
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 20:08:36 -0000

--001a11461a06deff1b0559ccc5ee
Content-Type: text/plain; charset="UTF-8"

Right. I can only think of one possible interpretation of "add attribute to
media description". RFC4566 uses the following phrases:

   - "attributes ... may be added"
   - "attribute ... in the media description"
   - "attribute is present"
   - "a media description may have any number of attributes"
   - "attribute fields can ... be added"
   - "specifying the attribute"
   - "session description containing such attributes"
   - "attribute MUST be included"

So, the following would be consistent with the defined terminology:

   - "The offerer MUST add the foo attribute to the media description."
   - "The foo attribute MUST be [present|contained|specified|included] in
   the media description."
   - "The media description MUST have the foo attribute."

But "foo attribute MUST be associated with the m-line"? Not so much.

On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> >> It depends on how we interpret "associated with"
> >
> > That's why I purged "associated with" from the BUNDLE spec:
> https://github.com/taylor-b/draft-sdp-bundle/pull/1
> >
> > It almost always can be interpreted in multiple ways. Unfortunately this
> never got integrated, I assume because I was too late.
>
> No, you were not :) I have been looking at your CR, and have been
> considering to integrate it, but I lately I have been so busy with
> draft-dtls-sdp etc.
>
> Having said that, we have changed the terminology in bundle a number of
> times already - we really need to stop at some point.
>
> The history of "associated" is when people commented that one cannot add
> an attribute, address etc to an m- line (because attributes, c- lines and
> m- lines are separate SDP properties). So, instead of talking about adding
> those to an m- line talk about associating those with an m- line.
>
> Now, if I remember the changes in your PR correctly, you are talking about
> "media descriptions", which would be an "envelope" containing the m- line,
> the address and attributes associated with that m- line. Then you could say
> "add attribute to the media description", etc. Right?
>
> Regards,
>
> Christer
>

--001a11461a06deff1b0559ccc5ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Right. I can only think of one possible interpretation of =
"add attribute to media description". RFC4566 uses the following =
phrases:
  • "attributes ... may be added"
  • "=
attribute ... in the media description"
  • "attribute is pre=
sent"
  • "a media description may have any number of attribu=
tes"
  • "attribute fields can ... be added"
  • &qu=
ot;specifying the attribute"
  • "session description contain=
ing such attributes"
  • "attribute MUST be included"
So, the following would be consistent with the defined terminol=
ogy:
  • "The offerer MUST add the foo attribute t=
o the media description."
  • "The foo attribute MUST be [pre=
sent|contained|specified|included] in the media description."
  • =
"The media description MUST have the foo attribute."
    • But "foo attribute MUST be associated with the m-line"? Not=
 so much.

On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,



>> It depends on how we interpret "associated=C2=A0with"
>

> That's why I purged "associated with" from the BUNDLE sp=
ec: https://github.com/taylor-b/draft-sdp-bu=
ndle/pull/1=C2=A0

>

> It almost always can be interpreted in multiple ways. Unfortunately th=
is never got integrated, I assume because I was too late.



No, you were not :) I have been looking at your CR, and have been co=
nsidering to integrate it, but I lately I have been so busy with draft-dtls=
-sdp etc.



Having said that, we have changed the terminology in bundle a number of tim=
es already - we really need to stop at some point.



The history of "associated" is when people commented that one can=
not add an attribute, address etc to an m- line (because attributes, c- lin=
es and m- lines are separate SDP properties). So, instead of talking about =
adding those to an m- line talk about associating those with an m- line.


Now, if I remember the changes in your PR correctly, you are talking about =
"media descriptions", which would be an "envelope" cont=
aining the m- line, the address and attributes associated with that m- line=
. Then you could say "add attribute to the media description", et=
c. Right?



Regards,



Christer





--001a11461a06deff1b0559ccc5ee--


From nobody Mon Sep 25 19:38:50 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8031513464A for ; Mon, 25 Sep 2017 19:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez7KVjci6qEa for ; Mon, 25 Sep 2017 19:38:33 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A12813464B for ; Mon, 25 Sep 2017 19:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8065; q=dns/txt; s=iport; t=1506393513; x=1507603113; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jCO8fNDPZ4F2+6pj55PSRXJGHtKFov6XpGRoXdHL0xc=; b=YdeDSVXuJehuhSK7S16GKDw3jbyadZ8oYGAFs2OfCtIq1xJcO5hP/rJI ODQ8fGQLfC4+ptFVqaaP/CEcayhtXgmbAfGwQV3wjgwLtfyKOxRnJJz4A Sm54+xP3nTxv4kiWPLyGQ37aacUvjtxWNYReMIjLdNKeJQlgGIKrX3A54 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3AQCVvMlZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieDdpobgUsrkGyHUAojhRgChDdXAQIBAQEBAQJrKIUYAQE?= =?us-ascii?q?BAQIBI1YQCw4KJwMCAkYRBgEMBgIBAYoiBQgQqA+CJyeKegEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgyuCAoFRgWcrgn2IFoJgBaEfh12Mf4IThW+DWocqigqLPIE?= =?us-ascii?q?5V0JMUyUVhSo5HIIDJDaIaAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,438,1500940800"; d="scan'208,217";a="8622979"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2017 02:38:32 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8Q2cV9g023261; Tue, 26 Sep 2017 02:38:31 GMT
To: Taylor Brandstetter , Christer Holmberg 
Cc: Magnus Westerlund , IETF MMUSIC WG 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se> 
From: Flemming Andreasen 
Message-ID: <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>
Date: Mon, 25 Sep 2017 22:38:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8F72498766E551FE6B1C3BA7"
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 02:38:41 -0000

This is a multi-part message in MIME format.
--------------8F72498766E551FE6B1C3BA7
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

I much prefer use of the term "media description" as well since this is 
well-defined in 4566.

Having said that, I wholeheartedly agree with Christer's point about 
terminology change - we need people to agree to this before entertaining 
yet another update on this front.

So folks, please speak up and let us know if you are for, against, or 
indifferent in terms of said terminology change.

Thanks

-- Flemming

On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
> Right. I can only think of one possible interpretation of "add 
> attribute to media description". RFC4566 uses the following phrases:
>
>   * "attributes ... may be added"
>   * "attribute ... in the media description"
>   * "attribute is present"
>   * "a media description may have any number of attributes"
>   * "attribute fields can ... be added"
>   * "specifying the attribute"
>   * "session description containing such attributes"
>   * "attribute MUST be included"
>
> So, the following would be consistent with the defined terminology:
>
>   * "The offerer MUST add the foo attribute to the media description."
>   * "The foo attribute MUST be [present|contained|specified|included]
>     in the media description."
>   * "The media description MUST have the foo attribute."
>
> But "foo attribute MUST be associated with the m-line"? Not so much.
>
> On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg 
>  > wrote:
>
>     Hi,
>
>     >> It depends on how we interpret "associated with"
>     >
>     > That's why I purged "associated with" from the BUNDLE spec:
>     https://github.com/taylor-b/draft-sdp-bundle/pull/1
>     
>     >
>     > It almost always can be interpreted in multiple ways.
>     Unfortunately this never got integrated, I assume because I was
>     too late.
>
>     No, you were not :) I have been looking at your CR, and have been
>     considering to integrate it, but I lately I have been so busy with
>     draft-dtls-sdp etc.
>
>     Having said that, we have changed the terminology in bundle a
>     number of times already - we really need to stop at some point.
>
>     The history of "associated" is when people commented that one
>     cannot add an attribute, address etc to an m- line (because
>     attributes, c- lines and m- lines are separate SDP properties).
>     So, instead of talking about adding those to an m- line talk about
>     associating those with an m- line.
>
>     Now, if I remember the changes in your PR correctly, you are
>     talking about "media descriptions", which would be an "envelope"
>     containing the m- line, the address and attributes associated with
>     that m- line. Then you could say "add attribute to the media
>     description", etc. Right?
>
>     Regards,
>
>     Christer
>
>


--------------8F72498766E551FE6B1C3BA7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I much prefer use of the term "media description" as well since this
    is well-defined in 4566. 

    

    Having said that, I wholeheartedly agree with Christer's point about
    terminology change - we need people to agree to this before
    entertaining yet another update on this front. 

    

    So folks, please speak up and let us know if you are for, against,
    or indifferent in terms of said terminology change. 

    

    Thanks 

    

    -- Flemming 

    

    
On 9/22/17 4:08 PM, Taylor Brandstetter
      wrote:

    

    

      
      
Right. I can only think of one possible
        interpretation of "add attribute to media description". RFC4566
        uses the following phrases:
        

          
    
            
  • "attributes ... may be added"
    • 
            
  • "attribute ... in the media description"
    • 
            
  • "attribute is present"
    • 
            
  • "a media description may have any number of attributes"
    • 
            
  • "attribute fields can ... be added"
    • 
            
  • "specifying the attribute"
    • 
            
  • "session description containing such attributes"
    • 
            
  • "attribute MUST be included"
    • 
          

          
So, the following would be consistent with the defined
            terminology:

        

        

          
    
            
  • "The offerer MUST add the foo attribute to the media
              description."
    • 
            
  • "The foo attribute MUST be
              [present|contained|specified|included] in the media
              description."
    • 
            
  • "The media description MUST have the foo attribute."
    
            
    • 
          

          
But "foo attribute MUST be associated with the m-line"?
            Not so much.

        

      

      


        
On Fri, Sep 22, 2017 at 9:51 PM,
          Christer Holmberg <christer.holmberg@ericsson.com>
          wrote:

          
Hi,

            

              >> It depends on how we interpret "associated with"

              >

              > That's why I purged "associated with" from the BUNDLE
              spec: https://github.com/taylor-b/draft-sdp-bundle/pull/1 

              >

              > It almost always can be interpreted in multiple ways.
              Unfortunately this never got integrated, I assume because
              I was too late.

              

            No, you were not :) I have been looking at your CR,
            and have been considering to integrate it, but I lately I
            have been so busy with draft-dtls-sdp etc.

            

            Having said that, we have changed the terminology in bundle
            a number of times already - we really need to stop at some
            point.

            

            The history of "associated" is when people commented that
            one cannot add an attribute, address etc to an m- line
            (because attributes, c- lines and m- lines are separate SDP
            properties). So, instead of talking about adding those to an
            m- line talk about associating those with an m- line.

            

            Now, if I remember the changes in your PR correctly, you are
            talking about "media descriptions", which would be an
            "envelope" containing the m- line, the address and
            attributes associated with that m- line. Then you could say
            "add attribute to the media description", etc. Right?

            

            Regards,

            

            Christer

          

        

        

      

    

    

  


--------------8F72498766E551FE6B1C3BA7--


From nobody Mon Sep 25 19:53:26 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65025132D44 for ; Mon, 25 Sep 2017 19:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U6b6W5DRVsZ for ; Mon, 25 Sep 2017 19:53:14 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8433113219E for ; Mon, 25 Sep 2017 19:53:14 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id r85so6148672ywg.1 for ; Mon, 25 Sep 2017 19:53:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ULeNzU5rij5aFi3oyvYKxW+Kivpk0p25tgPM1a1VV7w=; b=YppmJTRzSoHEFBC5ZLUR8olPEFa0mdQ0f2WYgVicWRt5XtiCO02JnJgwK5C+v0Z5e3 2mtZ6n3o1d3oAjXVw1RBkhDLyUUCgoW30KGdTCuWlFsQ+WW38Nf+arnkAa+CoFUORGrA YgQ+3AIMI238KDUMS2w97lE/bfYsKK/qfXukKTfBCmicipV7xs3XbXvaOXuwtJ60z1es Cc+wL0S6SJTkgAcBVe0i5OFCYpD3VNv99zu3Ng3BOjTwE5lBGzQjqN6PPkN1h12niRg0 Ht8WBt2S3Qe1uJW6ZIlSrBRsN6kuskCdJ1jPCAg2I/JAbz0SEJrfA/qvcyZO8HvIloEn vbCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ULeNzU5rij5aFi3oyvYKxW+Kivpk0p25tgPM1a1VV7w=; b=kGlk6cEc0gqOpGkycsbyPmmPsQjuyDjlI8D17oP35rqc0COS6kSesNjaq1sh9N9d9a Fbu04wBSddftmYmnagGR5rTMwZOeNpc+q92Kt3nPYZikM1ud7MBe/2XQnB16POppi1Ur VnSoQTEmyQVZrkc946C17LNuAZ7DUGZ8O12g4/Lh2FuagbNYv8sHLSvFAzmLWbeHp7Wy 9/Yg7FkupFsXLyEyjYfoIuu0+9lpHgkXA4KZpJpyiIIvRhNK8jr+L3D86iKUU8fwRPzQ lsvIGZ+asov3cy6yn0HpfMGqqrZTq/Nn8SXEzKt8PjFU7e7Ltu6r8iXLku/A6xoTNU0U NWfw==
X-Gm-Message-State: AHPjjUjMNpsG7flcNjOjg+SCkkuPqgYoMbEzqfYW7QoR6JZFCgOOZtfh nfiupsJ3bNf/jalCs5qOg/6/U3TUm8fqrPVgWaICUQ==
X-Google-Smtp-Source: AOwi7QBIck1wOFO3M90LGmUaG8Lez3ijbgOAELs8iHjHVsQSuIfh6Xz+kOPlz3n/faZsLzdkU9Ud/9/cqwF7wJfQUUA=
X-Received: by 10.37.132.73 with SMTP id r9mr5719382ybm.165.1506394393788; Mon, 25 Sep 2017 19:53:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.17 with HTTP; Mon, 25 Sep 2017 19:52:33 -0700 (PDT)
In-Reply-To: <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>
From: Eric Rescorla 
Date: Mon, 25 Sep 2017 19:52:33 -0700
Message-ID: 
To: Flemming Andreasen 
Cc: Taylor Brandstetter , Christer Holmberg ,  Magnus Westerlund , IETF MMUSIC WG 
Content-Type: multipart/alternative; boundary="089e0826fee4bbe295055a0ec699"
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 02:53:19 -0000

--089e0826fee4bbe295055a0ec699
Content-Type: text/plain; charset="UTF-8"

I am in favor of the changes that Taylor proposes.

-Ekr


On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen 
wrote:

> I much prefer use of the term "media description" as well since this is
> well-defined in 4566.
>
> Having said that, I wholeheartedly agree with Christer's point about
> terminology change - we need people to agree to this before entertaining
> yet another update on this front.
>
> So folks, please speak up and let us know if you are for, against, or
> indifferent in terms of said terminology change.
>
> Thanks
>
> -- Flemming
>
> On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
>
> Right. I can only think of one possible interpretation of "add attribute
> to media description". RFC4566 uses the following phrases:
>
>    - "attributes ... may be added"
>    - "attribute ... in the media description"
>    - "attribute is present"
>    - "a media description may have any number of attributes"
>    - "attribute fields can ... be added"
>    - "specifying the attribute"
>    - "session description containing such attributes"
>    - "attribute MUST be included"
>
> So, the following would be consistent with the defined terminology:
>
>    - "The offerer MUST add the foo attribute to the media description."
>    - "The foo attribute MUST be [present|contained|specified|included] in
>    the media description."
>    - "The media description MUST have the foo attribute."
>
> But "foo attribute MUST be associated with the m-line"? Not so much.
>
> On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>> Hi,
>>
>> >> It depends on how we interpret "associated with"
>> >
>> > That's why I purged "associated with" from the BUNDLE spec:
>> https://github.com/taylor-b/draft-sdp-bundle/pull/1
>> >
>> > It almost always can be interpreted in multiple ways. Unfortunately
>> this never got integrated, I assume because I was too late.
>>
>> No, you were not :) I have been looking at your CR, and have been
>> considering to integrate it, but I lately I have been so busy with
>> draft-dtls-sdp etc.
>>
>> Having said that, we have changed the terminology in bundle a number of
>> times already - we really need to stop at some point.
>>
>> The history of "associated" is when people commented that one cannot add
>> an attribute, address etc to an m- line (because attributes, c- lines and
>> m- lines are separate SDP properties). So, instead of talking about adding
>> those to an m- line talk about associating those with an m- line.
>>
>> Now, if I remember the changes in your PR correctly, you are talking
>> about "media descriptions", which would be an "envelope" containing the m-
>> line, the address and attributes associated with that m- line. Then you
>> could say "add attribute to the media description", etc. Right?
>>
>> Regards,
>>
>> Christer
>>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--089e0826fee4bbe295055a0ec699
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I am in favor of the changes that Taylor proposes.
-Ekr


<=
div class=3D"gmail_quote">On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreas=
en <fandreas@cisco.com> wrote:

 =20
   =20
 =20
  

    I much prefer use of the term "media description" as well sin=
ce this
    is well-defined in 4566. 

    

    Having said that, I wholeheartedly agree with Christer's point abou=
t
    terminology change - we need people to agree to this before
    entertaining yet another update on this front. 

    

    So folks, please speak up and let us know if you are for, against,
    or indifferent in terms of said terminology change. 

    

    Thanks 

    

    -- Flemming 

    

    
On 9/22/17 4:08 PM=
, Taylor Brandstetter
      wrote:

    

    

     =20
      
Right. I can only think of one possible
        interpretation of "add attribute to media description". R=
FC4566
        uses the following phrases:
        

          
    
            
  • "attributes ... may be added"
    • 
            
  • "attribute ... in the media description"
    • 
            
  • "attribute is present"
    • 
            
  • "a media description may have any number of attributes=
"
    • 
            
  • "attribute fields can ... be added"
    • 
            
  • "specifying the attribute"
    • 
            
  • "session description containing such attributes"<=
/li>
            
  • "attribute MUST be included"
    • 
          

          
So, the following would be consistent with the defined
            terminology:

        

        

          
    
            
  • "The offerer MUST add the foo attribute to the media
              description."
    • 
            
  • "The foo attribute MUST be
              [present|contained|specified|included] in the media
              description."
    • 
            
  • "The media description MUST have the foo attribute.&qu=
ot;
    
            
    • 
          

          
But "foo attribute MUST be associated with the m-line&q=
uot;?
            Not so much.

        

      

      


        
On Fri, Sep 22, 2017 at 9:51 PM,
          Christer Holmberg <christer.holmberg@ericsson.=
com>
          wrote:

          
Hi,

            

              >> It depends on how we interpret "associated=C2=
=A0with"

              >

              > That's why I purged "associated with" from=
 the BUNDLE
              spec: https://github.com/taylor-b/d=
raft-sdp-bundle/pull/1=C2=A0

              >

              > It almost always can be interpreted in multiple ways.
              Unfortunately this never got integrated, I assume because
              I was too late.

              

            No, you were not :) I have been looking at your CR,
            and have been considering to integrate it, but I lately I
            have been so busy with draft-dtls-sdp etc.

            

            Having said that, we have changed the terminology in bundle
            a number of times already - we really need to stop at some
            point.

            

            The history of "associated" is when people commented =
that
            one cannot add an attribute, address etc to an m- line
            (because attributes, c- lines and m- lines are separate SDP
            properties). So, instead of talking about adding those to an
            m- line talk about associating those with an m- line.

            

            Now, if I remember the changes in your PR correctly, you are
            talking about "media descriptions", which would be an
            "envelope" containing the m- line, the address and
            attributes associated with that m- line. Then you could say
            "add attribute to the media description", etc. Right?=


            

            Regards,

            

            Christer

          

        

        

      

    

    

  



_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic




--089e0826fee4bbe295055a0ec699--


From nobody Tue Sep 26 06:24:16 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C871332CE for ; Tue, 26 Sep 2017 06:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.719
X-Spam-Level: 
X-Spam-Status: No, score=-3.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 DAvLt94noVnd for ; Tue, 26 Sep 2017 06:24:11 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 BAE65133321 for ; Tue, 26 Sep 2017 06:24:10 -0700 (PDT)
X-AuditID: c1b4fb2d-a65ff700000019be-af-59ca54f7c173
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 76.2C.06590.7F45AC95; Tue, 26 Sep 2017 15:24:07 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 15:24:07 +0200
From: Christer Holmberg 
To: Flemming Andreasen , Taylor Brandstetter 
CC: Magnus Westerlund , IETF MMUSIC WG 
Thread-Topic: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
Thread-Index: AQHTMgJpHMZ02x0tykSASSt9LrLCX6LAx/MAgAAYdICAABdngIAAEiyAgABG5CD//+a0AIAFJBOAgADoCIA=
Date: Tue, 26 Sep 2017 13:24:06 +0000
Message-ID: 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>
In-Reply-To: <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_D5F02E88229CBchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7uu73kFORBmc+WFtcXvGQ1eL9BV2L qcsfszgwe0z5vZHVY8GmUo8lS34yBTBHcdmkpOZklqUW6dslcGV83rqQqWBraEVj9y72BsbH 7l2MnBwSAiYSrWu2MXUxcnEICRxhlDjWtpIdwlnEKPH+TydzFyMHB5uAhUT3P22QBhGBCImH /c+ZQGxmgSiJp4tmsYCUCAs4SxxZGwlR4iKx5eEzZgg7SeL/uylgNouAqkTf3KPsIOW8AtYS HQujIDY9YJbYMmUtI0gNp4CtxOxb69lBbEYBMYnvp9ZArRKXuPVkPhPEzQISS/acZ4awRSVe Pv7HCmKLCuhJbDhxmx0iriix82w7M0RvgsSZJatYQGxeAUGJkzOfsExgFJ2FZOwsJGWzkJRB xA0k3p+bzwxha0ssW/gaytaX2PjlLCOEbS3RsHQ2C7KaBYwcqxhFi1OLi3PTjYz1Uosyk4uL 8/P08lJLNjECo/Lglt+6OxhXv3Y8xCjAwajEw7vA/FSkEGtiWXFl7iFGCQ5mJRFeoWCgEG9K YmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KLYLJMHJxSDYxThTfUd3Ou/eq6 RFTkaWtVg9xqP7fe6877d5j1PgozZFkVeuPui+33uH3DD7fzT7/O96t2T0r9nwge7n+f6y+o im6J/yHH1vPzgej2OsG+o818N9JXCFRNuHciKrM8cdvPfxKRVf5Lf34yvxuZXCl5SeqOlucC e6fzy0+JBbxnZ7rvsXRH2FwlluKMREMt5qLiRAAM0hgSxgIAAA==
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 13:24:13 -0000

--_000_D5F02E88229CBchristerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

>I much prefer use of the term "media description" as well since this is we=
ll-defined in 4566.

Actually, the PR suggests =93m=3D section=94. That is used in JSEP, but in =
4566 there is =93media description=94 and =93media-level section=94. I am n=
ot really sure that the difference is, because I find both:


        "Each media description starts with an "m=3D" field and is terminat=
ed by either the next "m=3D=93 field=94

=85and:

        "Each media-level section starts with an "m=3D" line and continues =
to the next media-level section"

So, it seems the RFC uses inconsistent terminology.

Now, I had a look at draft-4566bis, and it seems like =93m=3D=93 field has =
been removed. But, both =93media description=94 and =93media-level section=
=94 are still used.

Regards,

Christer




On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
Right. I can only think of one possible interpretation of "add attribute to=
 media description". RFC4566 uses the following phrases:

  *   "attributes ... may be added"
  *   "attribute ... in the media description"
  *   "attribute is present"
  *   "a media description may have any number of attributes"
  *   "attribute fields can ... be added"
  *   "specifying the attribute"
  *   "session description containing such attributes"
  *   "attribute MUST be included"

So, the following would be consistent with the defined terminology:

  *   "The offerer MUST add the foo attribute to the media description."
  *   "The foo attribute MUST be [present|contained|specified|included] in =
the media description."
  *   "The media description MUST have the foo attribute."

But "foo attribute MUST be associated with the m-line"? Not so much.

On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg > wrote:
Hi,

>> It depends on how we interpret "associated with"
>
> That's why I purged "associated with" from the BUNDLE spec: https://githu=
b.com/taylor-b/draft-sdp-bundle/pull/1
>
> It almost always can be interpreted in multiple ways. Unfortunately this =
never got integrated, I assume because I was too late.

No, you were not :) I have been looking at your CR, and have been consideri=
ng to integrate it, but I lately I have been so busy with draft-dtls-sdp et=
c.

Having said that, we have changed the terminology in bundle a number of tim=
es already - we really need to stop at some point.

The history of "associated" is when people commented that one cannot add an=
 attribute, address etc to an m- line (because attributes, c- lines and m- =
lines are separate SDP properties). So, instead of talking about adding tho=
se to an m- line talk about associating those with an m- line.

Now, if I remember the changes in your PR correctly, you are talking about =
"media descriptions", which would be an "envelope" containing the m- line, =
the address and attributes associated with that m- line. Then you could say=
 "add attribute to the media description", etc. Right?

Regards,

Christer



--_000_D5F02E88229CBchristerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <34A201FFDEB0F4459C89DA92EB52DA89@ericsson.com>
Content-Transfer-Encoding: quoted-printable








Hi,











>I much prefer use of the term=
 "media description" as well since this is well-defined in 4566.













Actually, the PR suggests =93m=3D section=94. That is used in JSEP, but in =
4566 there is =93media description=94 and =93media-level section=94. I am n=
ot really sure that the difference is, because I find both:










	"Each media description starts with an=
 "m=3D" field and is terminated by either the next "m=3D=
=93 field=94


=85and:


	"Each media-level section star=
ts with an "m=3D" line and continues to the next media-level =
section"











So, it seems the RFC uses inconsistent terminology.









Now, I had a look at draft-4566bis, and it seems like =93m=3D=93 field has =
been removed. But, both =93media description=94 and =93media-level section=
=94 are still used. 









Regards,









Christer


























On 9/22/17 4:08 PM, Taylor Brandstetter wrot=
e:






Right. I can only think of one possible interpretation of =
"add attribute to media description". RFC4566 uses the following =
phrases:



    

  • "attributes ... may be added" 
  • "attribute ... in=
 the media description" 
  • "attribute is present" 
  • "a media description may have any number of attributes" 
  • "attribute fields can ... be added" 
  • "specifyin=
g the attribute" 
  • "session description containing such at=
tributes" 
  • "attribute MUST be included" 


So, the following would be consistent with the defined terminology:





    

  • "The offerer MUST add the foo attribute to the media description.&=
quot; 
  • "The foo attribute MUST be [present|contained|specified=
|included] in the media description."

  • "The media description MUST have the foo attribute."
    



But "foo attribute MUST be associated with the m-line"? Not =
so much.









On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmbe=
rg 
<christer.holmberg@ericsson.com> wrote:<=
br>


Hi,



>> It depends on how we interpret "associated with"
>

> That's why I purged "associated with" from the BUNDLE spec: =

https://github.com/taylor-b/draft-sdp-bundle/pull/1 

>

> It almost always can be interpreted in multiple ways. Unfortunately th=
is never got integrated, I assume because I was too late.



No, you were not :) I have been looking at your CR, and have been co=
nsidering to integrate it, but I lately I have been so busy with draft-dtls=
-sdp etc.



Having said that, we have changed the terminology in bundle a number of tim=
es already - we really need to stop at some point.



The history of "associated" is when people commented that one can=
not add an attribute, address etc to an m- line (because attributes, c- lin=
es and m- lines are separate SDP properties). So, instead of talking about =
adding those to an m- line talk about associating
 those with an m- line.



Now, if I remember the changes in your PR correctly, you are talking about =
"media descriptions", which would be an "envelope" cont=
aining the m- line, the address and attributes associated with that m- line=
. Then you could say "add attribute to the media description",
 etc. Right?



Regards,



Christer





















--_000_D5F02E88229CBchristerholmbergericssoncom_--


From nobody Tue Sep 26 09:44:54 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297B31342DB for ; Tue, 26 Sep 2017 09:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ZNDEkfH8WYJg for ; Tue, 26 Sep 2017 09:44:47 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 23C351342E3 for ; Tue, 26 Sep 2017 09:44:47 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8QGiGOL020027; Tue, 26 Sep 2017 12:44:41 -0400
Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2d5jc8jgc5-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Sep 2017 12:44:41 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 26 Sep 2017 11:44:40 -0500
From: Jonathan Lennox 
To: Eric Rescorla 
CC: Flemming Andreasen , Magnus Westerlund , Christer Holmberg , mmusic 
Thread-Topic: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
Thread-Index: AQHTNuXIY4yDLKOtWkOrkNTeyCIETqLHs4OA
Date: Tue, 26 Sep 2017 16:44:39 +0000
Message-ID: <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.220.24]
Content-Type: multipart/alternative; boundary="_000_364B50F3810141E09693511A99CDA9D7vidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-26_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709260239
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 16:44:54 -0000

--_000_364B50F3810141E09693511A99CDA9D7vidyocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBoYXZlIG9uZSBxdWVzdGlvbiwgd2hpY2ggYWN0dWFsbHkgbWFrZXMgYSBwcmFjdGljYWwgZGlm
ZmVyZW5jZSB0byB0aGUgb24tdGhlLXdpcmUgU0RQIG9mIEJVTkRMRS4NCg0KRm9yIGEgc2Vzc2lv
bi0gYW5kIG1lZGlhLWxldmVsIGF0dHJpYnV0ZSB3aGljaCBoYXMgdGhlIGNvbW1vbiBwYXR0ZXJu
IHRoYXQgdGhlIHNlc3Npb24tbGV2ZWwgdmFsdWUgcHJvdmlkZXMgYSBkZWZhdWx0IGZvciB0aGUg
bWVkaWEgbGV2ZWwsIGEgbm9uLW92ZXJyaWRkZW4gc2Vzc2lvbi1sZXZlbCBhdHRyaWJ1dGUgaXMg
YXJndWFibHkg4oCcYXNzb2NpYXRlZOKAnSB3aXRoIGEgbWVkaWEgZGVzY3JpcHRpb24sIGJ1dCBp
dCBjbGVhcmx5IGlzbuKAmXQg4oCcaW5jbHVkZWTigJ0gaW4gaXQuDQoNClNob3VsZCB0aGlzIGJl
IHBlcm1pdHRlZD8NCg0KT24gU2VwIDI1LCAyMDE3LCBhdCAxMDo1MiBQTSwgRXJpYyBSZXNjb3Js
YSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KSSBhbSBpbiBm
YXZvciBvZiB0aGUgY2hhbmdlcyB0aGF0IFRheWxvciBwcm9wb3Nlcy4NCg0KLUVrcg0KDQoNCk9u
IE1vbiwgU2VwIDI1LCAyMDE3IGF0IDc6MzggUE0sIEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJl
YXNAY2lzY28uY29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PiB3cm90ZToNCkkgbXVjaCBw
cmVmZXIgdXNlIG9mIHRoZSB0ZXJtICJtZWRpYSBkZXNjcmlwdGlvbiIgYXMgd2VsbCBzaW5jZSB0
aGlzIGlzIHdlbGwtZGVmaW5lZCBpbiA0NTY2Lg0KDQpIYXZpbmcgc2FpZCB0aGF0LCBJIHdob2xl
aGVhcnRlZGx5IGFncmVlIHdpdGggQ2hyaXN0ZXIncyBwb2ludCBhYm91dCB0ZXJtaW5vbG9neSBj
aGFuZ2UgLSB3ZSBuZWVkIHBlb3BsZSB0byBhZ3JlZSB0byB0aGlzIGJlZm9yZSBlbnRlcnRhaW5p
bmcgeWV0IGFub3RoZXIgdXBkYXRlIG9uIHRoaXMgZnJvbnQuDQoNClNvIGZvbGtzLCBwbGVhc2Ug
c3BlYWsgdXAgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBhcmUgZm9yLCBhZ2FpbnN0LCBvciBpbmRp
ZmZlcmVudCBpbiB0ZXJtcyBvZiBzYWlkIHRlcm1pbm9sb2d5IGNoYW5nZS4NCg0KVGhhbmtzDQoN
Ci0tIEZsZW1taW5nDQoNCk9uIDkvMjIvMTcgNDowOCBQTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3
cm90ZToNClJpZ2h0LiBJIGNhbiBvbmx5IHRoaW5rIG9mIG9uZSBwb3NzaWJsZSBpbnRlcnByZXRh
dGlvbiBvZiAiYWRkIGF0dHJpYnV0ZSB0byBtZWRpYSBkZXNjcmlwdGlvbiIuIFJGQzQ1NjYgdXNl
cyB0aGUgZm9sbG93aW5nIHBocmFzZXM6DQoNCiAgKiAgICJhdHRyaWJ1dGVzIC4uLiBtYXkgYmUg
YWRkZWQiDQogICogICAiYXR0cmlidXRlIC4uLiBpbiB0aGUgbWVkaWEgZGVzY3JpcHRpb24iDQog
ICogICAiYXR0cmlidXRlIGlzIHByZXNlbnQiDQogICogICAiYSBtZWRpYSBkZXNjcmlwdGlvbiBt
YXkgaGF2ZSBhbnkgbnVtYmVyIG9mIGF0dHJpYnV0ZXMiDQogICogICAiYXR0cmlidXRlIGZpZWxk
cyBjYW4gLi4uIGJlIGFkZGVkIg0KICAqICAgInNwZWNpZnlpbmcgdGhlIGF0dHJpYnV0ZSINCiAg
KiAgICJzZXNzaW9uIGRlc2NyaXB0aW9uIGNvbnRhaW5pbmcgc3VjaCBhdHRyaWJ1dGVzIg0KICAq
ICAgImF0dHJpYnV0ZSBNVVNUIGJlIGluY2x1ZGVkIg0KDQpTbywgdGhlIGZvbGxvd2luZyB3b3Vs
ZCBiZSBjb25zaXN0ZW50IHdpdGggdGhlIGRlZmluZWQgdGVybWlub2xvZ3k6DQoNCiAgKiAgICJU
aGUgb2ZmZXJlciBNVVNUIGFkZCB0aGUgZm9vIGF0dHJpYnV0ZSB0byB0aGUgbWVkaWEgZGVzY3Jp
cHRpb24uIg0KICAqICAgIlRoZSBmb28gYXR0cmlidXRlIE1VU1QgYmUgW3ByZXNlbnR8Y29udGFp
bmVkfHNwZWNpZmllZHxpbmNsdWRlZF0gaW4gdGhlIG1lZGlhIGRlc2NyaXB0aW9uLiINCiAgKiAg
ICJUaGUgbWVkaWEgZGVzY3JpcHRpb24gTVVTVCBoYXZlIHRoZSBmb28gYXR0cmlidXRlLiINCg0K
QnV0ICJmb28gYXR0cmlidXRlIE1VU1QgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLWxpbmUiPyBO
b3Qgc28gbXVjaC4NCg0KT24gRnJpLCBTZXAgMjIsIDIwMTcgYXQgOTo1MSBQTSwgQ2hyaXN0ZXIg
SG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KPj4gSXQgZGVwZW5kcyBvbiBo
b3cgd2UgaW50ZXJwcmV0ICJhc3NvY2lhdGVkIHdpdGgiDQo+DQo+IFRoYXQncyB3aHkgSSBwdXJn
ZWQgImFzc29jaWF0ZWQgd2l0aCIgZnJvbSB0aGUgQlVORExFIHNwZWM6IGh0dHBzOi8vZ2l0aHVi
LmNvbS90YXlsb3ItYi9kcmFmdC1zZHAtYnVuZGxlL3B1bGwvMQ0KPg0KPiBJdCBhbG1vc3QgYWx3
YXlzIGNhbiBiZSBpbnRlcnByZXRlZCBpbiBtdWx0aXBsZSB3YXlzLiBVbmZvcnR1bmF0ZWx5IHRo
aXMgbmV2ZXIgZ290IGludGVncmF0ZWQsIEkgYXNzdW1lIGJlY2F1c2UgSSB3YXMgdG9vIGxhdGUu
DQoNCk5vLCB5b3Ugd2VyZSBub3QgOikgSSBoYXZlIGJlZW4gbG9va2luZyBhdCB5b3VyIENSLCBh
bmQgaGF2ZSBiZWVuIGNvbnNpZGVyaW5nIHRvIGludGVncmF0ZSBpdCwgYnV0IEkgbGF0ZWx5IEkg
aGF2ZSBiZWVuIHNvIGJ1c3kgd2l0aCBkcmFmdC1kdGxzLXNkcCBldGMuDQoNCkhhdmluZyBzYWlk
IHRoYXQsIHdlIGhhdmUgY2hhbmdlZCB0aGUgdGVybWlub2xvZ3kgaW4gYnVuZGxlIGEgbnVtYmVy
IG9mIHRpbWVzIGFscmVhZHkgLSB3ZSByZWFsbHkgbmVlZCB0byBzdG9wIGF0IHNvbWUgcG9pbnQu
DQoNClRoZSBoaXN0b3J5IG9mICJhc3NvY2lhdGVkIiBpcyB3aGVuIHBlb3BsZSBjb21tZW50ZWQg
dGhhdCBvbmUgY2Fubm90IGFkZCBhbiBhdHRyaWJ1dGUsIGFkZHJlc3MgZXRjIHRvIGFuIG0tIGxp
bmUgKGJlY2F1c2UgYXR0cmlidXRlcywgYy0gbGluZXMgYW5kIG0tIGxpbmVzIGFyZSBzZXBhcmF0
ZSBTRFAgcHJvcGVydGllcykuIFNvLCBpbnN0ZWFkIG9mIHRhbGtpbmcgYWJvdXQgYWRkaW5nIHRo
b3NlIHRvIGFuIG0tIGxpbmUgdGFsayBhYm91dCBhc3NvY2lhdGluZyB0aG9zZSB3aXRoIGFuIG0t
IGxpbmUuDQoNCk5vdywgaWYgSSByZW1lbWJlciB0aGUgY2hhbmdlcyBpbiB5b3VyIFBSIGNvcnJl
Y3RseSwgeW91IGFyZSB0YWxraW5nIGFib3V0ICJtZWRpYSBkZXNjcmlwdGlvbnMiLCB3aGljaCB3
b3VsZCBiZSBhbiAiZW52ZWxvcGUiIGNvbnRhaW5pbmcgdGhlIG0tIGxpbmUsIHRoZSBhZGRyZXNz
IGFuZCBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGF0IG0tIGxpbmUuIFRoZW4geW91IGNv
dWxkIHNheSAiYWRkIGF0dHJpYnV0ZSB0byB0aGUgbWVkaWEgZGVzY3JpcHRpb24iLCBldGMuIFJp
Z2h0Pw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0Bp
ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1h
aWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL21tdXNpYw0KDQo=

--_000_364B50F3810141E09693511A99CDA9D7vidyocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUg
b25lIHF1ZXN0aW9uLCB3aGljaCBhY3R1YWxseSBtYWtlcyBhIHByYWN0aWNhbCBkaWZmZXJlbmNl
IHRvIHRoZSBvbi10aGUtd2lyZSBTRFAgb2YgQlVORExFLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Rm9yIGEgc2Vzc2lvbi0gYW5kIG1l
ZGlhLWxldmVsIGF0dHJpYnV0ZSB3aGljaCBoYXMgdGhlIGNvbW1vbiBwYXR0ZXJuIHRoYXQgdGhl
IHNlc3Npb24tbGV2ZWwgdmFsdWUgcHJvdmlkZXMgYSBkZWZhdWx0IGZvciB0aGUgbWVkaWEgbGV2
ZWwsIGEgbm9uLW92ZXJyaWRkZW4gc2Vzc2lvbi1sZXZlbCBhdHRyaWJ1dGUgaXMgYXJndWFibHkg
4oCcYXNzb2NpYXRlZOKAnSB3aXRoIGEgbWVkaWEgZGVzY3JpcHRpb24sIGJ1dCBpdCBjbGVhcmx5
DQogaXNu4oCZdCDigJxpbmNsdWRlZOKAnSBpbiBpdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy
IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNob3VsZCB0aGlzIGJlIHBlcm1pdHRl
ZD88L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gU2VwIDI1LCAyMDE3LCBhdCAxMDo1MiBQTSwgRXJp
YyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgY2xhc3M9IiI+ZWty
QHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh
bmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPkkg
YW0gaW4gZmF2b3Igb2YgdGhlIGNoYW5nZXMgdGhhdCBUYXlsb3IgcHJvcG9zZXMuDQo8ZGl2IGNs
YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tRWtyPC9kaXY+DQo8
ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJn
bWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIE1v
biwgU2VwIDI1LCAyMDE3IGF0IDc6MzggUE0sIEZsZW1taW5nIEFuZHJlYXNlbiA8c3BhbiBkaXI9
Imx0ciIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmZhbmRyZWFzQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFu
PiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0
eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n
LWxlZnQ6MWV4Ij4NCjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgY2xhc3M9
IiI+SSBtdWNoIHByZWZlciB1c2Ugb2YgdGhlIHRlcm0gJnF1b3Q7bWVkaWEgZGVzY3JpcHRpb24m
cXVvdDsgYXMgd2VsbCBzaW5jZSB0aGlzIGlzIHdlbGwtZGVmaW5lZCBpbiA0NTY2Lg0KPGJyIGNs
YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGF2aW5nIHNhaWQgdGhhdCwgSSB3aG9sZWhlYXJ0ZWRs
eSBhZ3JlZSB3aXRoIENocmlzdGVyJ3MgcG9pbnQgYWJvdXQgdGVybWlub2xvZ3kgY2hhbmdlIC0g
d2UgbmVlZCBwZW9wbGUgdG8gYWdyZWUgdG8gdGhpcyBiZWZvcmUgZW50ZXJ0YWluaW5nIHlldCBh
bm90aGVyIHVwZGF0ZSBvbiB0aGlzIGZyb250Lg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi
Pg0KU28gZm9sa3MsIHBsZWFzZSBzcGVhayB1cCBhbmQgbGV0IHVzIGtub3cgaWYgeW91IGFyZSBm
b3IsIGFnYWluc3QsIG9yIGluZGlmZmVyZW50IGluIHRlcm1zIG9mIHNhaWQgdGVybWlub2xvZ3kg
Y2hhbmdlLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzIDxiciBjbGFzcz0i
Ij4NCjxzcGFuIGNsYXNzPSJIT0VuWmIiPjxmb250IGNvbG9yPSIjODg4ODg4IiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQotLSBGbGVtbWluZyA8YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9zcGFuPg0K
PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Img1Ij48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz
PSJtXy0xMzYxNjg3MjU1Mjk3NjAwMjE4bW96LWNpdGUtcHJlZml4Ij5PbiA5LzIyLzE3IDQ6MDgg
UE0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPlJp
Z2h0LiBJIGNhbiBvbmx5IHRoaW5rIG9mIG9uZSBwb3NzaWJsZSBpbnRlcnByZXRhdGlvbiBvZiAm
cXVvdDthZGQgYXR0cmlidXRlIHRvIG1lZGlhIGRlc2NyaXB0aW9uJnF1b3Q7LiBSRkM0NTY2IHVz
ZXMgdGhlIGZvbGxvd2luZyBwaHJhc2VzOg0KPGRpdiBjbGFzcz0iIj4NCjx1bCBjbGFzcz0iIj4N
CjxsaSBjbGFzcz0iIj4mcXVvdDthdHRyaWJ1dGVzIC4uLiBtYXkgYmUgYWRkZWQmcXVvdDsgPC9s
aT48bGkgY2xhc3M9IiI+JnF1b3Q7YXR0cmlidXRlIC4uLiBpbiB0aGUgbWVkaWEgZGVzY3JpcHRp
b24mcXVvdDsgPC9saT48bGkgY2xhc3M9IiI+JnF1b3Q7YXR0cmlidXRlIGlzIHByZXNlbnQmcXVv
dDsgPC9saT48bGkgY2xhc3M9IiI+JnF1b3Q7YSBtZWRpYSBkZXNjcmlwdGlvbiBtYXkgaGF2ZSBh
bnkgbnVtYmVyIG9mIGF0dHJpYnV0ZXMmcXVvdDsgPC9saT48bGkgY2xhc3M9IiI+JnF1b3Q7YXR0
cmlidXRlIGZpZWxkcyBjYW4gLi4uIGJlIGFkZGVkJnF1b3Q7IDwvbGk+PGxpIGNsYXNzPSIiPiZx
dW90O3NwZWNpZnlpbmcgdGhlIGF0dHJpYnV0ZSZxdW90OyA8L2xpPjxsaSBjbGFzcz0iIj4mcXVv
dDtzZXNzaW9uIGRlc2NyaXB0aW9uIGNvbnRhaW5pbmcgc3VjaCBhdHRyaWJ1dGVzJnF1b3Q7IDwv
bGk+PGxpIGNsYXNzPSIiPiZxdW90O2F0dHJpYnV0ZSBNVVNUIGJlIGluY2x1ZGVkJnF1b3Q7IDwv
bGk+PC91bD4NCjxkaXYgY2xhc3M9IiI+U28sIHRoZSBmb2xsb3dpbmcgd291bGQgYmUgY29uc2lz
dGVudCB3aXRoIHRoZSBkZWZpbmVkIHRlcm1pbm9sb2d5OjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSIiPg0KPHVsIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSIiPiZxdW90O1RoZSBvZmZlcmVyIE1V
U1QgYWRkIHRoZSBmb28gYXR0cmlidXRlIHRvIHRoZSBtZWRpYSBkZXNjcmlwdGlvbi4mcXVvdDsg
PC9saT48bGkgY2xhc3M9IiI+JnF1b3Q7VGhlIGZvbyBhdHRyaWJ1dGUgTVVTVCBiZSBbcHJlc2Vu
dHxjb250YWluZWR8c3BlY2lmaWVkfDx3YnIgY2xhc3M9IiI+aW5jbHVkZWRdIGluIHRoZSBtZWRp
YSBkZXNjcmlwdGlvbi4mcXVvdDsNCjwvbGk+PGxpIGNsYXNzPSIiPiZxdW90O1RoZSBtZWRpYSBk
ZXNjcmlwdGlvbiBNVVNUIGhhdmUgdGhlIGZvbyBhdHRyaWJ1dGUuJnF1b3Q7PGJyIGNsYXNzPSIi
Pg0KPC9saT48L3VsPg0KPGRpdiBjbGFzcz0iIj5CdXQgJnF1b3Q7Zm9vIGF0dHJpYnV0ZSBNVVNU
IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgbS1saW5lJnF1b3Q7PyBOb3Qgc28gbXVjaC48L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyIGNsYXNzPSIiPg0K
PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgU2VwIDIyLCAyMDE3IGF0IDk6NTEgUE0s
IENocmlzdGVyIEhvbG1iZXJnIDxzcGFuIGRpcj0ibHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVm
PSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayIg
Y2xhc3M9IiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uPHdiciBjbGFzcz0iIj5jb208L2E+
Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls
X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s
aWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpIaSw8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iIj48
YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBJdCBkZXBlbmRzIG9uIGhvdyB3ZSBpbnRlcnByZXQgJnF1
b3Q7YXNzb2NpYXRlZCZuYnNwO3dpdGgmcXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNz
PSIiPg0KJmd0OyBUaGF0J3Mgd2h5IEkgcHVyZ2VkICZxdW90O2Fzc29jaWF0ZWQgd2l0aCZxdW90
OyBmcm9tIHRoZSBCVU5ETEUgc3BlYzogPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3RheWxv
ci1iL2RyYWZ0LXNkcC1idW5kbGUvcHVsbC8xIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js
YW5rIiBjbGFzcz0iIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS90YXlsb3ItYi9kcjx3YnIgY2xhc3M9
IiI+YWZ0LXNkcC1idW5kbGUvcHVsbC8xPC9hPiZuYnNwOzxiciBjbGFzcz0iIj4NCiZndDs8YnIg
Y2xhc3M9IiI+DQomZ3Q7IEl0IGFsbW9zdCBhbHdheXMgY2FuIGJlIGludGVycHJldGVkIGluIG11
bHRpcGxlIHdheXMuIFVuZm9ydHVuYXRlbHkgdGhpcyBuZXZlciBnb3QgaW50ZWdyYXRlZCwgSSBh
c3N1bWUgYmVjYXVzZSBJIHdhcyB0b28gbGF0ZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQo8L3NwYW4+Tm8sIHlvdSB3ZXJlIG5vdCA6KSBJIGhhdmUgYmVlbiBsb29raW5nIGF0IHlvdXIg
Q1IsIGFuZCBoYXZlIGJlZW4gY29uc2lkZXJpbmcgdG8gaW50ZWdyYXRlIGl0LCBidXQgSSBsYXRl
bHkgSSBoYXZlIGJlZW4gc28gYnVzeSB3aXRoIGRyYWZ0LWR0bHMtc2RwIGV0Yy48YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQpIYXZpbmcgc2FpZCB0aGF0LCB3ZSBoYXZlIGNoYW5nZWQgdGhl
IHRlcm1pbm9sb2d5IGluIGJ1bmRsZSBhIG51bWJlciBvZiB0aW1lcyBhbHJlYWR5IC0gd2UgcmVh
bGx5IG5lZWQgdG8gc3RvcCBhdCBzb21lIHBvaW50LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NClRoZSBoaXN0b3J5IG9mICZxdW90O2Fzc29jaWF0ZWQmcXVvdDsgaXMgd2hlbiBwZW9wbGUg
Y29tbWVudGVkIHRoYXQgb25lIGNhbm5vdCBhZGQgYW4gYXR0cmlidXRlLCBhZGRyZXNzIGV0YyB0
byBhbiBtLSBsaW5lIChiZWNhdXNlIGF0dHJpYnV0ZXMsIGMtIGxpbmVzIGFuZCBtLSBsaW5lcyBh
cmUgc2VwYXJhdGUgU0RQIHByb3BlcnRpZXMpLiBTbywgaW5zdGVhZCBvZiB0YWxraW5nIGFib3V0
IGFkZGluZyB0aG9zZSB0byBhbiBtLSBsaW5lIHRhbGsgYWJvdXQgYXNzb2NpYXRpbmcNCiB0aG9z
ZSB3aXRoIGFuIG0tIGxpbmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTm93LCBpZiBJ
IHJlbWVtYmVyIHRoZSBjaGFuZ2VzIGluIHlvdXIgUFIgY29ycmVjdGx5LCB5b3UgYXJlIHRhbGtp
bmcgYWJvdXQgJnF1b3Q7bWVkaWEgZGVzY3JpcHRpb25zJnF1b3Q7LCB3aGljaCB3b3VsZCBiZSBh
biAmcXVvdDtlbnZlbG9wZSZxdW90OyBjb250YWluaW5nIHRoZSBtLSBsaW5lLCB0aGUgYWRkcmVz
cyBhbmQgYXR0cmlidXRlcyBhc3NvY2lhdGVkIHdpdGggdGhhdCBtLSBsaW5lLiBUaGVuIHlvdSBj
b3VsZCBzYXkgJnF1b3Q7YWRkIGF0dHJpYnV0ZSB0byB0aGUgbWVkaWEgZGVzY3JpcHRpb24mcXVv
dDssDQogZXRjLiBSaWdodD88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZWdhcmRzLDxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNocmlzdGVyPGJyIGNsYXNzPSIiPg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi
ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzx3YnIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX188
YnIgY2xhc3M9IiI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i
bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgY2xhc3M9IiI+bW11c2ljQGlldGYub3JnPC9hPjxiciBj
bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bW11c2ljIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnIgY2xhc3M9IiI+bGlzdGluZm8vbW11c2ljPC9hPjxi
ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8
YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8
L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t
bXVzaWM8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNs
YXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_364B50F3810141E09693511A99CDA9D7vidyocom_--


From nobody Tue Sep 26 10:13:09 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841EB1342DB for ; Tue, 26 Sep 2017 10:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GnrmsXfDBulf for ; Tue, 26 Sep 2017 10:13:05 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 68CE41342F5 for ; Tue, 26 Sep 2017 10:13:04 -0700 (PDT)
X-AuditID: c1b4fb25-967ff70000005333-03-59ca8a9ddc52
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.A7.21299.D9A8AC95; Tue, 26 Sep 2017 19:13:02 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 19:13:01 +0200
From: Christer Holmberg 
To: Jonathan Lennox , Eric Rescorla 
CC: Flemming Andreasen , Magnus Westerlund , mmusic 
Thread-Topic: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
Thread-Index: AQHTMgJpHMZ02x0tykSASSt9LrLCX6LAx/MAgAAYdICAABdngIAAEiyAgABG5CD//+a0AIAFJBOAgAADz4CAAOh9gIAAKRAw
Date: Tue, 26 Sep 2017 17:13:01 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>  <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com>
In-Reply-To: <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B562FDAB5ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7iu68rlORBs83ClmseH2O3eL9BV2L /YvPM1tMXf6YxYHFY8rvjaweS5b8ZPKY/LiN2aPt2R32AJYoLpuU1JzMstQifbsEroxZc/vZ C2acZ6yY+Ho+SwPjnZOMXYycHBICJhJbtm5h72Lk4hASOMIo8WV2LxuEs4hRYu6N2UAZDg42 AQuJ7n/aIA0iAm4Sc/5uZwOxmQWqJc58ucACYgsLOEs0PZnMAlHjIrHl4TNmCDtP4mP7CbB6 FgFVid0X34LZvAK+Et3bvkHtusUi8fb+G3aQBKeArcT3i4vBrmMUEJP4fmoNE8QycYlbT+Yz QVwtILFkz3lmCFtU4uXjf6wQtpLEotufoerzJXYe2M8EsUxQ4uTMJywTGEVmIRk1C0nZLCRl s4BeZhbQlFi/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGEWLU4uTctONjPVSizKTi4vz8/Ty Uks2MQIj8OCW36o7GC+/cTzEKMDBqMTDG1x1KlKINbGsuDL3EKMEB7OSCK9oE1CINyWxsiq1 KD++qDQntfgQozQHi5I4r+O+CxFCAumJJanZqakFqUUwWSYOTqkGxtKrwTHfmOZuspF57T7P 8EdNWf4Hm9Zv16X91I7serbb1vbKz61MpqbTW59OdVrRzfZsO4vvppM3SrVKYi0bIjp5y74Y FU77PG+jRJmHkV2XGWOEaZosx7qJDSdz2e5arFyzKvhHob1Qzte3S90KhZzXMbs2HOLab/Z2 jRjf+xr+xorUj3H3lViKMxINtZiLihMBBG2277wCAAA=
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 17:13:07 -0000

--_000_7594FB04B1934943A5C02806D1A2204B562FDAB5ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCj5JIGhhdmUgb25lIHF1ZXN0aW9uLCB3aGljaCBhY3R1YWxseSBtYWtlcyBhIHByYWN0
aWNhbCBkaWZmZXJlbmNlIHRvIHRoZSBvbi10aGUtPndpcmUgU0RQIG9mIEJVTkRMRS4NCj4NCj5G
b3IgYSBzZXNzaW9uLSBhbmQgbWVkaWEtbGV2ZWwgYXR0cmlidXRlIHdoaWNoIGhhcyB0aGUgY29t
bW9uIHBhdHRlcm4gdGhhdCB0aGUgPnNlc3Npb24tbGV2ZWwgdmFsdWUgcHJvdmlkZXMgYSBkZWZh
dWx0IGZvciB0aGUgbWVkaWEgbGV2ZWwsIGEgbm9uLW92ZXJyaWRkZW4gPnNlc3Npb24tbGV2ZWwg
YXR0cmlidXRlIGlzIGFyZ3VhYmx5IOKAnGFzc29jaWF0ZWTigJ0gd2l0aCBhIG1lZGlhIGRlc2Ny
aXB0aW9uLCBidXQgaXQgPmNsZWFybHkgaXNu4oCZdCDigJxpbmNsdWRlZOKAnSBpbiBpdC4NCj4N
Cj5TaG91bGQgdGhpcyBiZSBwZXJtaXR0ZWQ/DQoNCk5vdCBzdXJlIEkgdW5kZXJzdGFuZC4gU2hv
dWxkIHdoYXQgYmUgcGVybWl0dGVkPyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0K
T24gU2VwIDI1LCAyMDE3LCBhdCAxMDo1MiBQTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29t
PG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KSSBhbSBpbiBmYXZvciBvZiB0aGUgY2hh
bmdlcyB0aGF0IFRheWxvciBwcm9wb3Nlcy4NCg0KLUVrcg0KDQoNCk9uIE1vbiwgU2VwIDI1LCAy
MDE3IGF0IDc6MzggUE0sIEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPG1h
aWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PiB3cm90ZToNCkkgbXVjaCBwcmVmZXIgdXNlIG9mIHRo
ZSB0ZXJtICJtZWRpYSBkZXNjcmlwdGlvbiIgYXMgd2VsbCBzaW5jZSB0aGlzIGlzIHdlbGwtZGVm
aW5lZCBpbiA0NTY2Lg0KDQpIYXZpbmcgc2FpZCB0aGF0LCBJIHdob2xlaGVhcnRlZGx5IGFncmVl
IHdpdGggQ2hyaXN0ZXIncyBwb2ludCBhYm91dCB0ZXJtaW5vbG9neSBjaGFuZ2UgLSB3ZSBuZWVk
IHBlb3BsZSB0byBhZ3JlZSB0byB0aGlzIGJlZm9yZSBlbnRlcnRhaW5pbmcgeWV0IGFub3RoZXIg
dXBkYXRlIG9uIHRoaXMgZnJvbnQuDQoNClNvIGZvbGtzLCBwbGVhc2Ugc3BlYWsgdXAgYW5kIGxl
dCB1cyBrbm93IGlmIHlvdSBhcmUgZm9yLCBhZ2FpbnN0LCBvciBpbmRpZmZlcmVudCBpbiB0ZXJt
cyBvZiBzYWlkIHRlcm1pbm9sb2d5IGNoYW5nZS4NCg0KVGhhbmtzDQoNCi0tIEZsZW1taW5nDQoN
Ck9uIDkvMjIvMTcgNDowOCBQTSwgVGF5bG9yIEJyYW5kc3RldHRlciB3cm90ZToNClJpZ2h0LiBJ
IGNhbiBvbmx5IHRoaW5rIG9mIG9uZSBwb3NzaWJsZSBpbnRlcnByZXRhdGlvbiBvZiAiYWRkIGF0
dHJpYnV0ZSB0byBtZWRpYSBkZXNjcmlwdGlvbiIuIFJGQzQ1NjYgdXNlcyB0aGUgZm9sbG93aW5n
IHBocmFzZXM6DQoNCiAgKiAgICJhdHRyaWJ1dGVzIC4uLiBtYXkgYmUgYWRkZWQiDQogICogICAi
YXR0cmlidXRlIC4uLiBpbiB0aGUgbWVkaWEgZGVzY3JpcHRpb24iDQogICogICAiYXR0cmlidXRl
IGlzIHByZXNlbnQiDQogICogICAiYSBtZWRpYSBkZXNjcmlwdGlvbiBtYXkgaGF2ZSBhbnkgbnVt
YmVyIG9mIGF0dHJpYnV0ZXMiDQogICogICAiYXR0cmlidXRlIGZpZWxkcyBjYW4gLi4uIGJlIGFk
ZGVkIg0KICAqICAgInNwZWNpZnlpbmcgdGhlIGF0dHJpYnV0ZSINCiAgKiAgICJzZXNzaW9uIGRl
c2NyaXB0aW9uIGNvbnRhaW5pbmcgc3VjaCBhdHRyaWJ1dGVzIg0KICAqICAgImF0dHJpYnV0ZSBN
VVNUIGJlIGluY2x1ZGVkIg0KU28sIHRoZSBmb2xsb3dpbmcgd291bGQgYmUgY29uc2lzdGVudCB3
aXRoIHRoZSBkZWZpbmVkIHRlcm1pbm9sb2d5Og0KDQogICogICAiVGhlIG9mZmVyZXIgTVVTVCBh
ZGQgdGhlIGZvbyBhdHRyaWJ1dGUgdG8gdGhlIG1lZGlhIGRlc2NyaXB0aW9uLiINCiAgKiAgICJU
aGUgZm9vIGF0dHJpYnV0ZSBNVVNUIGJlIFtwcmVzZW50fGNvbnRhaW5lZHxzcGVjaWZpZWR8aW5j
bHVkZWRdIGluIHRoZSBtZWRpYSBkZXNjcmlwdGlvbi4iDQogICogICAiVGhlIG1lZGlhIGRlc2Ny
aXB0aW9uIE1VU1QgaGF2ZSB0aGUgZm9vIGF0dHJpYnV0ZS4iDQpCdXQgImZvbyBhdHRyaWJ1dGUg
TVVTVCBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIG0tbGluZSI/IE5vdCBzbyBtdWNoLg0KDQpPbiBG
cmksIFNlcCAyMiwgMjAxNyBhdCA5OjUxIFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j
b20+PiB3cm90ZToNCkhpLA0KDQo+PiBJdCBkZXBlbmRzIG9uIGhvdyB3ZSBpbnRlcnByZXQgImFz
c29jaWF0ZWQgd2l0aCINCj4NCj4gVGhhdCdzIHdoeSBJIHB1cmdlZCAiYXNzb2NpYXRlZCB3aXRo
IiBmcm9tIHRoZSBCVU5ETEUgc3BlYzogaHR0cHM6Ly9naXRodWIuY29tL3RheWxvci1iL2RyYWZ0
LXNkcC1idW5kbGUvcHVsbC8xDQo+DQo+IEl0IGFsbW9zdCBhbHdheXMgY2FuIGJlIGludGVycHJl
dGVkIGluIG11bHRpcGxlIHdheXMuIFVuZm9ydHVuYXRlbHkgdGhpcyBuZXZlciBnb3QgaW50ZWdy
YXRlZCwgSSBhc3N1bWUgYmVjYXVzZSBJIHdhcyB0b28gbGF0ZS4NCg0KTm8sIHlvdSB3ZXJlIG5v
dCA6KSBJIGhhdmUgYmVlbiBsb29raW5nIGF0IHlvdXIgQ1IsIGFuZCBoYXZlIGJlZW4gY29uc2lk
ZXJpbmcgdG8gaW50ZWdyYXRlIGl0LCBidXQgSSBsYXRlbHkgSSBoYXZlIGJlZW4gc28gYnVzeSB3
aXRoIGRyYWZ0LWR0bHMtc2RwIGV0Yy4NCg0KSGF2aW5nIHNhaWQgdGhhdCwgd2UgaGF2ZSBjaGFu
Z2VkIHRoZSB0ZXJtaW5vbG9neSBpbiBidW5kbGUgYSBudW1iZXIgb2YgdGltZXMgYWxyZWFkeSAt
IHdlIHJlYWxseSBuZWVkIHRvIHN0b3AgYXQgc29tZSBwb2ludC4NCg0KVGhlIGhpc3Rvcnkgb2Yg
ImFzc29jaWF0ZWQiIGlzIHdoZW4gcGVvcGxlIGNvbW1lbnRlZCB0aGF0IG9uZSBjYW5ub3QgYWRk
IGFuIGF0dHJpYnV0ZSwgYWRkcmVzcyBldGMgdG8gYW4gbS0gbGluZSAoYmVjYXVzZSBhdHRyaWJ1
dGVzLCBjLSBsaW5lcyBhbmQgbS0gbGluZXMgYXJlIHNlcGFyYXRlIFNEUCBwcm9wZXJ0aWVzKS4g
U28sIGluc3RlYWQgb2YgdGFsa2luZyBhYm91dCBhZGRpbmcgdGhvc2UgdG8gYW4gbS0gbGluZSB0
YWxrIGFib3V0IGFzc29jaWF0aW5nIHRob3NlIHdpdGggYW4gbS0gbGluZS4NCg0KTm93LCBpZiBJ
IHJlbWVtYmVyIHRoZSBjaGFuZ2VzIGluIHlvdXIgUFIgY29ycmVjdGx5LCB5b3UgYXJlIHRhbGtp
bmcgYWJvdXQgIm1lZGlhIGRlc2NyaXB0aW9ucyIsIHdoaWNoIHdvdWxkIGJlIGFuICJlbnZlbG9w
ZSIgY29udGFpbmluZyB0aGUgbS0gbGluZSwgdGhlIGFkZHJlc3MgYW5kIGF0dHJpYnV0ZXMgYXNz
b2NpYXRlZCB3aXRoIHRoYXQgbS0gbGluZS4gVGhlbiB5b3UgY291bGQgc2F5ICJhZGQgYXR0cmli
dXRlIHRvIHRoZSBtZWRpYSBkZXNjcmlwdGlvbiIsIGV0Yy4gUmlnaHQ/DQoNClJlZ2FyZHMsDQoN
CkNocmlzdGVyDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz
aWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp
Yw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11
c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo=

--_000_7594FB04B1934943A5C02806D1A2204B562FDAB5ESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x
DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3
Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0
IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTQ3MjgzODk4Ow0KCW1z
by1saXN0LXRlbXBsYXRlLWlkczo1OTE0NDkxNjA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt
ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw
dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw
dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6
bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX
aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K
QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt
Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2
ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MjA0NDQwNDQ1OTsN
Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0OTQ3MDU2MTA7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K
CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w
OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp
c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh
bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIx
Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu
Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwN
Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5JIGhhdmUgb25lIHF1
ZXN0aW9uLCB3aGljaCBhY3R1YWxseSBtYWtlcyBhIHByYWN0aWNhbCBkaWZmZXJlbmNlIHRvIHRo
ZSBvbi10aGUtPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+d2lyZSBTRFAg
b2YgQlVORExFLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5Gb3IgYSBzZXNzaW9uLSBhbmQgbWVkaWEtbGV2
ZWwgYXR0cmlidXRlIHdoaWNoIGhhcyB0aGUgY29tbW9uIHBhdHRlcm4gdGhhdCB0aGUNCjxzcGFu
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnNlc3Npb24tbGV2ZWwgdmFsdWUgcHJv
dmlkZXMgYSBkZWZhdWx0IGZvciB0aGUgbWVkaWEgbGV2ZWwsIGEgbm9uLW92ZXJyaWRkZW4NCjxz
cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnNlc3Npb24tbGV2ZWwgYXR0cmli
dXRlIGlzIGFyZ3VhYmx5IOKAnGFzc29jaWF0ZWTigJ0gd2l0aCBhIG1lZGlhIGRlc2NyaXB0aW9u
LCBidXQgaXQNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPmNsZWFybHkg
aXNu4oCZdCDigJxpbmNsdWRlZOKAnSBpbiBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7
PC9zcGFuPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+U2hvdWxkIHRo
aXMgYmUgcGVybWl0dGVkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
Pk5vdCBzdXJlIEkgdW5kZXJzdGFuZC4gU2hvdWxkIHdoYXQgYmUgcGVybWl0dGVkPyA6KTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk9uIFNlcCAyNSwgMjAxNywgYXQgMTA6NTIgUE0sIEVyaWMgUmVzY29ybGEgJmx0Ozxh
IGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBpbiBmYXZv
ciBvZiB0aGUgY2hhbmdlcyB0aGF0IFRheWxvciBwcm9wb3Nlcy4gPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBTZXAgMjUsIDIwMTcgYXQg
NzozOCBQTSwgRmxlbW1pbmcgQW5kcmVhc2VuICZsdDs8YSBocmVmPSJtYWlsdG86ZmFuZHJlYXNA
Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmFuZHJlYXNAY2lzY28uY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgbXVjaCBwcmVmZXIgdXNlIG9mIHRoZSB0ZXJtICZxdW90O21lZGlhIGRlc2NyaXB0aW9u
JnF1b3Q7IGFzIHdlbGwgc2luY2UgdGhpcyBpcyB3ZWxsLWRlZmluZWQgaW4gNDU2Ni4NCjxicj4N
Cjxicj4NCkhhdmluZyBzYWlkIHRoYXQsIEkgd2hvbGVoZWFydGVkbHkgYWdyZWUgd2l0aCBDaHJp
c3RlcidzIHBvaW50IGFib3V0IHRlcm1pbm9sb2d5IGNoYW5nZSAtIHdlIG5lZWQgcGVvcGxlIHRv
IGFncmVlIHRvIHRoaXMgYmVmb3JlIGVudGVydGFpbmluZyB5ZXQgYW5vdGhlciB1cGRhdGUgb24g
dGhpcyBmcm9udC4NCjxicj4NCjxicj4NClNvIGZvbGtzLCBwbGVhc2Ugc3BlYWsgdXAgYW5kIGxl
dCB1cyBrbm93IGlmIHlvdSBhcmUgZm9yLCBhZ2FpbnN0LCBvciBpbmRpZmZlcmVudCBpbiB0ZXJt
cyBvZiBzYWlkIHRlcm1pbm9sb2d5IGNoYW5nZS4NCjxicj4NCjxicj4NClRoYW5rcyA8YnI+DQo8
c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS0g
RmxlbW1pbmcgPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gOS8yMi8xNyA0OjA4IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5S
aWdodC4gSSBjYW4gb25seSB0aGluayBvZiBvbmUgcG9zc2libGUgaW50ZXJwcmV0YXRpb24gb2Yg
JnF1b3Q7YWRkIGF0dHJpYnV0ZSB0byBtZWRpYSBkZXNjcmlwdGlvbiZxdW90Oy4gUkZDNDU2NiB1
c2VzIHRoZSBmb2xsb3dpbmcgcGhyYXNlczoNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCB0
eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm
bzEiPg0KJnF1b3Q7YXR0cmlidXRlcyAuLi4gbWF5IGJlIGFkZGVkJnF1b3Q7IDxvOnA+PC9vOnA+
PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCiZx
dW90O2F0dHJpYnV0ZSAuLi4gaW4gdGhlIG1lZGlhIGRlc2NyaXB0aW9uJnF1b3Q7IDxvOnA+PC9v
OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N
CiZxdW90O2F0dHJpYnV0ZSBpcyBwcmVzZW50JnF1b3Q7IDxvOnA+PC9vOnA+PC9saT48bGkgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCiZxdW90O2EgbWVkaWEg
ZGVzY3JpcHRpb24gbWF5IGhhdmUgYW55IG51bWJlciBvZiBhdHRyaWJ1dGVzJnF1b3Q7IDxvOnA+
PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8x
Ij4NCiZxdW90O2F0dHJpYnV0ZSBmaWVsZHMgY2FuIC4uLiBiZSBhZGRlZCZxdW90OyA8bzpwPjwv
bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+
DQomcXVvdDtzcGVjaWZ5aW5nIHRoZSBhdHRyaWJ1dGUmcXVvdDsgPG86cD48L286cD48L2xpPjxs
aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KJnF1b3Q7c2Vz
c2lvbiBkZXNjcmlwdGlvbiBjb250YWluaW5nIHN1Y2ggYXR0cmlidXRlcyZxdW90OyA8bzpwPjwv
bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+
DQomcXVvdDthdHRyaWJ1dGUgTVVTVCBiZSBpbmNsdWRlZCZxdW90OyA8bzpwPjwvbzpwPjwvbGk+
PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgdGhlIGZvbGxvd2luZyB3b3Vs
ZCBiZSBjb25zaXN0ZW50IHdpdGggdGhlIGRlZmluZWQgdGVybWlub2xvZ3k6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KJnF1b3Q7VGhlIG9mZmVyZXIg
TVVTVCBhZGQgdGhlIGZvbyBhdHRyaWJ1dGUgdG8gdGhlIG1lZGlhIGRlc2NyaXB0aW9uLiZxdW90
OyA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZl
bDEgbGZvMiI+DQomcXVvdDtUaGUgZm9vIGF0dHJpYnV0ZSBNVVNUIGJlIFtwcmVzZW50fGNvbnRh
aW5lZHxzcGVjaWZpZWR8aW5jbHVkZWRdIGluIHRoZSBtZWRpYSBkZXNjcmlwdGlvbi4mcXVvdDsN
CjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVs
MSBsZm8yIj4NCiZxdW90O1RoZSBtZWRpYSBkZXNjcmlwdGlvbiBNVVNUIGhhdmUgdGhlIGZvbyBh
dHRyaWJ1dGUuJnF1b3Q7PG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+QnV0ICZxdW90O2ZvbyBhdHRyaWJ1dGUgTVVTVCBiZSBhc3NvY2lhdGVkIHdpdGgg
dGhlIG0tbGluZSZxdW90Oz8gTm90IHNvIG11Y2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMjIsIDIwMTcg
YXQgOTo1MSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rl
ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVy
Z0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBJdCBkZXBlbmRz
IG9uIGhvdyB3ZSBpbnRlcnByZXQgJnF1b3Q7YXNzb2NpYXRlZCZuYnNwO3dpdGgmcXVvdDs8YnI+
DQomZ3Q7PGJyPg0KJmd0OyBUaGF0J3Mgd2h5IEkgcHVyZ2VkICZxdW90O2Fzc29jaWF0ZWQgd2l0
aCZxdW90OyBmcm9tIHRoZSBCVU5ETEUgc3BlYzogPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t
L3RheWxvci1iL2RyYWZ0LXNkcC1idW5kbGUvcHVsbC8xIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw
czovL2dpdGh1Yi5jb20vdGF5bG9yLWIvZHJhZnQtc2RwLWJ1bmRsZS9wdWxsLzE8L2E+Jm5ic3A7
PGJyPg0KJmd0Ozxicj4NCiZndDsgSXQgYWxtb3N0IGFsd2F5cyBjYW4gYmUgaW50ZXJwcmV0ZWQg
aW4gbXVsdGlwbGUgd2F5cy4gVW5mb3J0dW5hdGVseSB0aGlzIG5ldmVyIGdvdCBpbnRlZ3JhdGVk
LCBJIGFzc3VtZSBiZWNhdXNlIEkgd2FzIHRvbyBsYXRlLjxicj4NCjxicj4NCk5vLCB5b3Ugd2Vy
ZSBub3QgOikgSSBoYXZlIGJlZW4gbG9va2luZyBhdCB5b3VyIENSLCBhbmQgaGF2ZSBiZWVuIGNv
bnNpZGVyaW5nIHRvIGludGVncmF0ZSBpdCwgYnV0IEkgbGF0ZWx5IEkgaGF2ZSBiZWVuIHNvIGJ1
c3kgd2l0aCBkcmFmdC1kdGxzLXNkcCBldGMuPGJyPg0KPGJyPg0KSGF2aW5nIHNhaWQgdGhhdCwg
d2UgaGF2ZSBjaGFuZ2VkIHRoZSB0ZXJtaW5vbG9neSBpbiBidW5kbGUgYSBudW1iZXIgb2YgdGlt
ZXMgYWxyZWFkeSAtIHdlIHJlYWxseSBuZWVkIHRvIHN0b3AgYXQgc29tZSBwb2ludC48YnI+DQo8
YnI+DQpUaGUgaGlzdG9yeSBvZiAmcXVvdDthc3NvY2lhdGVkJnF1b3Q7IGlzIHdoZW4gcGVvcGxl
IGNvbW1lbnRlZCB0aGF0IG9uZSBjYW5ub3QgYWRkIGFuIGF0dHJpYnV0ZSwgYWRkcmVzcyBldGMg
dG8gYW4gbS0gbGluZSAoYmVjYXVzZSBhdHRyaWJ1dGVzLCBjLSBsaW5lcyBhbmQgbS0gbGluZXMg
YXJlIHNlcGFyYXRlIFNEUCBwcm9wZXJ0aWVzKS4gU28sIGluc3RlYWQgb2YgdGFsa2luZyBhYm91
dCBhZGRpbmcgdGhvc2UgdG8gYW4gbS0gbGluZSB0YWxrIGFib3V0IGFzc29jaWF0aW5nDQogdGhv
c2Ugd2l0aCBhbiBtLSBsaW5lLjxicj4NCjxicj4NCk5vdywgaWYgSSByZW1lbWJlciB0aGUgY2hh
bmdlcyBpbiB5b3VyIFBSIGNvcnJlY3RseSwgeW91IGFyZSB0YWxraW5nIGFib3V0ICZxdW90O21l
ZGlhIGRlc2NyaXB0aW9ucyZxdW90Oywgd2hpY2ggd291bGQgYmUgYW4gJnF1b3Q7ZW52ZWxvcGUm
cXVvdDsgY29udGFpbmluZyB0aGUgbS0gbGluZSwgdGhlIGFkZHJlc3MgYW5kIGF0dHJpYnV0ZXMg
YXNzb2NpYXRlZCB3aXRoIHRoYXQgbS0gbGluZS4gVGhlbiB5b3UgY291bGQgc2F5ICZxdW90O2Fk
ZCBhdHRyaWJ1dGUgdG8gdGhlIG1lZGlhIGRlc2NyaXB0aW9uJnF1b3Q7LA0KIGV0Yy4gUmlnaHQ/
PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlz
dDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwv
YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t
dXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0Bp
ZXRmLm9yZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_7594FB04B1934943A5C02806D1A2204B562FDAB5ESESSMB109erics_--


From nobody Tue Sep 26 10:50:00 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E19E1342CE for ; Tue, 26 Sep 2017 10:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dSkvJ6V1Ao3w for ; Tue, 26 Sep 2017 10:49:56 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 2F53E1330AE for ; Tue, 26 Sep 2017 10:49:56 -0700 (PDT)
Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8QHnp62023868; Tue, 26 Sep 2017 13:49:51 -0400
Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 2d5gqjtrnh-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Sep 2017 13:49:50 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 26 Sep 2017 12:49:49 -0500
From: Jonathan Lennox 
To: Christer Holmberg 
CC: Eric Rescorla , Flemming Andreasen , Magnus Westerlund , mmusic 
Thread-Topic: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
Thread-Index: AQHTNuXIY4yDLKOtWkOrkNTeyCIETqLHs4OAgAAH7YCAAApGAA==
Date: Tue, 26 Sep 2017 17:49:49 +0000
Message-ID: <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>  <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com> <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [160.79.220.24]
Content-Type: multipart/alternative; boundary="_000_3667875B3EEC4745BFFB790B273DC458vidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-26_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709260252
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 17:49:58 -0000

--_000_3667875B3EEC4745BFFB790B273DC458vidyocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpPbiBTZXAgMjYsIDIwMTcsIGF0IDE6MTMgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl
ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KPkkgaGF2ZSBvbmUgcXVlc3Rpb24sIHdoaWNoIGFjdHVh
bGx5IG1ha2VzIGEgcHJhY3RpY2FsIGRpZmZlcmVuY2UgdG8gdGhlIG9uLXRoZS0+d2lyZSBTRFAg
b2YgQlVORExFLg0KPg0KPkZvciBhIHNlc3Npb24tIGFuZCBtZWRpYS1sZXZlbCBhdHRyaWJ1dGUg
d2hpY2ggaGFzIHRoZSBjb21tb24gcGF0dGVybiB0aGF0IHRoZSA+c2Vzc2lvbi1sZXZlbCB2YWx1
ZSBwcm92aWRlcyBhIGRlZmF1bHQgZm9yIHRoZSBtZWRpYSBsZXZlbCwgYSBub24tb3ZlcnJpZGRl
bj5zZXNzaW9uLWxldmVsIGF0dHJpYnV0ZSBpcyBhcmd1YWJseSDigJxhc3NvY2lhdGVk4oCdIHdp
dGggYSBtZWRpYSBkZXNjcmlwdGlvbiwgYnV0IGl0ID5jbGVhcmx5IGlzbuKAmXQg4oCcaW5jbHVk
ZWTigJ0gaW4gaXQuDQo+DQo+U2hvdWxkIHRoaXMgYmUgcGVybWl0dGVkPw0KDQpOb3Qgc3VyZSBJ
IHVuZGVyc3RhbmQuIFNob3VsZCB3aGF0IGJlIHBlcm1pdHRlZD8gOikNCg0KSWYgQlVORExFIHNh
eXMgdGhhdCBhbiBhdHRyaWJ1dGUgb2YgdGhpcyB0eXBlIOKAnE1VU1QgYmUgYXNzb2NpYXRlZCB3
aXRoIGEgbWVkaWEgZGVzY3JpcHRpb27igJ0sIGlzIGl0IHN1ZmZpY2llbnQgdG8gaGF2ZSB0aGUg
YXR0cmlidXRlIHNwZWNpZmllZCBhdCB0aGUgc2Vzc2lvbiBsZXZlbD8NCg0KDQpSZWdhcmRzLA0K
DQpDaHJpc3Rlcg0KDQoNCg0KT24gU2VwIDI1LCAyMDE3LCBhdCAxMDo1MiBQTSwgRXJpYyBSZXNj
b3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KSSBhbSBp
biBmYXZvciBvZiB0aGUgY2hhbmdlcyB0aGF0IFRheWxvciBwcm9wb3Nlcy4NCg0KLUVrcg0KDQoN
Ck9uIE1vbiwgU2VwIDI1LCAyMDE3IGF0IDc6MzggUE0sIEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFu
ZHJlYXNAY2lzY28uY29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PiB3cm90ZToNCkkgbXVj
aCBwcmVmZXIgdXNlIG9mIHRoZSB0ZXJtICJtZWRpYSBkZXNjcmlwdGlvbiIgYXMgd2VsbCBzaW5j
ZSB0aGlzIGlzIHdlbGwtZGVmaW5lZCBpbiA0NTY2Lg0KDQpIYXZpbmcgc2FpZCB0aGF0LCBJIHdo
b2xlaGVhcnRlZGx5IGFncmVlIHdpdGggQ2hyaXN0ZXIncyBwb2ludCBhYm91dCB0ZXJtaW5vbG9n
eSBjaGFuZ2UgLSB3ZSBuZWVkIHBlb3BsZSB0byBhZ3JlZSB0byB0aGlzIGJlZm9yZSBlbnRlcnRh
aW5pbmcgeWV0IGFub3RoZXIgdXBkYXRlIG9uIHRoaXMgZnJvbnQuDQoNClNvIGZvbGtzLCBwbGVh
c2Ugc3BlYWsgdXAgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBhcmUgZm9yLCBhZ2FpbnN0LCBvciBp
bmRpZmZlcmVudCBpbiB0ZXJtcyBvZiBzYWlkIHRlcm1pbm9sb2d5IGNoYW5nZS4NCg0KVGhhbmtz
DQoNCi0tIEZsZW1taW5nDQoNCk9uIDkvMjIvMTcgNDowOCBQTSwgVGF5bG9yIEJyYW5kc3RldHRl
ciB3cm90ZToNClJpZ2h0LiBJIGNhbiBvbmx5IHRoaW5rIG9mIG9uZSBwb3NzaWJsZSBpbnRlcnBy
ZXRhdGlvbiBvZiAiYWRkIGF0dHJpYnV0ZSB0byBtZWRpYSBkZXNjcmlwdGlvbiIuIFJGQzQ1NjYg
dXNlcyB0aGUgZm9sbG93aW5nIHBocmFzZXM6DQoNCiAgKiAgICJhdHRyaWJ1dGVzIC4uLiBtYXkg
YmUgYWRkZWQiDQogICogICAiYXR0cmlidXRlIC4uLiBpbiB0aGUgbWVkaWEgZGVzY3JpcHRpb24i
DQogICogICAiYXR0cmlidXRlIGlzIHByZXNlbnQiDQogICogICAiYSBtZWRpYSBkZXNjcmlwdGlv
biBtYXkgaGF2ZSBhbnkgbnVtYmVyIG9mIGF0dHJpYnV0ZXMiDQogICogICAiYXR0cmlidXRlIGZp
ZWxkcyBjYW4gLi4uIGJlIGFkZGVkIg0KICAqICAgInNwZWNpZnlpbmcgdGhlIGF0dHJpYnV0ZSIN
CiAgKiAgICJzZXNzaW9uIGRlc2NyaXB0aW9uIGNvbnRhaW5pbmcgc3VjaCBhdHRyaWJ1dGVzIg0K
ICAqICAgImF0dHJpYnV0ZSBNVVNUIGJlIGluY2x1ZGVkIg0KDQpTbywgdGhlIGZvbGxvd2luZyB3
b3VsZCBiZSBjb25zaXN0ZW50IHdpdGggdGhlIGRlZmluZWQgdGVybWlub2xvZ3k6DQoNCiAgKiAg
ICJUaGUgb2ZmZXJlciBNVVNUIGFkZCB0aGUgZm9vIGF0dHJpYnV0ZSB0byB0aGUgbWVkaWEgZGVz
Y3JpcHRpb24uIg0KICAqICAgIlRoZSBmb28gYXR0cmlidXRlIE1VU1QgYmUgW3ByZXNlbnR8Y29u
dGFpbmVkfHNwZWNpZmllZHxpbmNsdWRlZF0gaW4gdGhlIG1lZGlhIGRlc2NyaXB0aW9uLiINCiAg
KiAgICJUaGUgbWVkaWEgZGVzY3JpcHRpb24gTVVTVCBoYXZlIHRoZSBmb28gYXR0cmlidXRlLiIN
Cg0KQnV0ICJmb28gYXR0cmlidXRlIE1VU1QgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLWxpbmUi
PyBOb3Qgc28gbXVjaC4NCg0KT24gRnJpLCBTZXAgMjIsIDIwMTcgYXQgOTo1MSBQTSwgQ2hyaXN0
ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KPj4gSXQgZGVwZW5kcyBv
biBob3cgd2UgaW50ZXJwcmV0ICJhc3NvY2lhdGVkIHdpdGgiDQo+DQo+IFRoYXQncyB3aHkgSSBw
dXJnZWQgImFzc29jaWF0ZWQgd2l0aCIgZnJvbSB0aGUgQlVORExFIHNwZWM6IGh0dHBzOi8vZ2l0
aHViLmNvbS90YXlsb3ItYi9kcmFmdC1zZHAtYnVuZGxlL3B1bGwvMQ0KPg0KPiBJdCBhbG1vc3Qg
YWx3YXlzIGNhbiBiZSBpbnRlcnByZXRlZCBpbiBtdWx0aXBsZSB3YXlzLiBVbmZvcnR1bmF0ZWx5
IHRoaXMgbmV2ZXIgZ290IGludGVncmF0ZWQsIEkgYXNzdW1lIGJlY2F1c2UgSSB3YXMgdG9vIGxh
dGUuDQoNCk5vLCB5b3Ugd2VyZSBub3QgOikgSSBoYXZlIGJlZW4gbG9va2luZyBhdCB5b3VyIENS
LCBhbmQgaGF2ZSBiZWVuIGNvbnNpZGVyaW5nIHRvIGludGVncmF0ZSBpdCwgYnV0IEkgbGF0ZWx5
IEkgaGF2ZSBiZWVuIHNvIGJ1c3kgd2l0aCBkcmFmdC1kdGxzLXNkcCBldGMuDQoNCkhhdmluZyBz
YWlkIHRoYXQsIHdlIGhhdmUgY2hhbmdlZCB0aGUgdGVybWlub2xvZ3kgaW4gYnVuZGxlIGEgbnVt
YmVyIG9mIHRpbWVzIGFscmVhZHkgLSB3ZSByZWFsbHkgbmVlZCB0byBzdG9wIGF0IHNvbWUgcG9p
bnQuDQoNClRoZSBoaXN0b3J5IG9mICJhc3NvY2lhdGVkIiBpcyB3aGVuIHBlb3BsZSBjb21tZW50
ZWQgdGhhdCBvbmUgY2Fubm90IGFkZCBhbiBhdHRyaWJ1dGUsIGFkZHJlc3MgZXRjIHRvIGFuIG0t
IGxpbmUgKGJlY2F1c2UgYXR0cmlidXRlcywgYy0gbGluZXMgYW5kIG0tIGxpbmVzIGFyZSBzZXBh
cmF0ZSBTRFAgcHJvcGVydGllcykuIFNvLCBpbnN0ZWFkIG9mIHRhbGtpbmcgYWJvdXQgYWRkaW5n
IHRob3NlIHRvIGFuIG0tIGxpbmUgdGFsayBhYm91dCBhc3NvY2lhdGluZyB0aG9zZSB3aXRoIGFu
IG0tIGxpbmUuDQoNCk5vdywgaWYgSSByZW1lbWJlciB0aGUgY2hhbmdlcyBpbiB5b3VyIFBSIGNv
cnJlY3RseSwgeW91IGFyZSB0YWxraW5nIGFib3V0ICJtZWRpYSBkZXNjcmlwdGlvbnMiLCB3aGlj
aCB3b3VsZCBiZSBhbiAiZW52ZWxvcGUiIGNvbnRhaW5pbmcgdGhlIG0tIGxpbmUsIHRoZSBhZGRy
ZXNzIGFuZCBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGF0IG0tIGxpbmUuIFRoZW4geW91
IGNvdWxkIHNheSAiYWRkIGF0dHJpYnV0ZSB0byB0aGUgbWVkaWEgZGVzY3JpcHRpb24iLCBldGMu
IFJpZ2h0Pw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNp
Y0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxt
YWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tbXVzaWMNCg0K

--_000_3667875B3EEC4745BFFB790B273DC458vidyocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAg
MjYsIDIwMTcsIGF0IDE6MTMgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWls
dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xt
YmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt
aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNl
Y3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNh
OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4
dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3
aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs
YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli
cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+SGksPG86
cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw
Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t
YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs
YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+
Jmd0Ozwvc3Bhbj5JIGhhdmUgb25lIHF1ZXN0aW9uLCB3aGljaCBhY3R1YWxseSBtYWtlcyBhIHBy
YWN0aWNhbCBkaWZmZXJlbmNlIHRvIHRoZSBvbi10aGUtPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io
MzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jmd0Ozwvc3Bhbj53aXJlIFNEUCBvZiBCVU5ETEUuPG86
cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls
eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29s
b3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mZ3Q7PC9zcGFuPjxvOnAgY2xhc3M9IiI+
Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU
aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiBy
Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jmd0Ozwvc3Bhbj5Gb3IgYSBzZXNzaW9uLSBhbmQg
bWVkaWEtbGV2ZWwgYXR0cmlidXRlIHdoaWNoIGhhcyB0aGUgY29tbW9uIHBhdHRlcm4gdGhhdCB0
aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4g
c3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jmd0Ozwvc3Bhbj5zZXNz
aW9uLWxldmVsIHZhbHVlIHByb3ZpZGVzDQogYSBkZWZhdWx0IGZvciB0aGUgbWVkaWEgbGV2ZWws
IGEgbm9uLW92ZXJyaWRkZW48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj
bGFzcz0iIj4mZ3Q7PC9zcGFuPnNlc3Npb24tbGV2ZWwgYXR0cmlidXRlIGlzIGFyZ3VhYmx5IOKA
nGFzc29jaWF0ZWTigJ0gd2l0aCBhIG1lZGlhIGRlc2NyaXB0aW9uLCBidXQgaXQ8c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y
OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jmd0Ozwvc3Bhbj5jbGVhcmx5DQogaXNu4oCZ
dCDigJxpbmNsdWRlZOKAnSBpbiBpdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+
DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm
b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj
bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIi
PiZndDs8L3NwYW4+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z
aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9
IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mZ3Q7
PC9zcGFuPlNob3VsZCB0aGlzIGJlIHBlcm1pdHRlZD88bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi
Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBj
bGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj
bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg
Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp
OyIgY2xhc3M9IiI+Tm90IHN1cmUgSSB1bmRlcnN0YW5kLiBTaG91bGQgd2hhdCBiZSBwZXJtaXR0
ZWQ/IDopPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpJZiBCVU5ETEUgc2F5cyB0aGF0IGFuIGF0dHJpYnV0ZSBv
ZiB0aGlzIHR5cGUg4oCcTVVTVCBiZSBhc3NvY2lhdGVkIHdpdGggYSBtZWRpYSBkZXNjcmlwdGlv
buKAnSwgaXMgaXQgc3VmZmljaWVudCB0byBoYXZlIHRoZSBhdHRyaWJ1dGUgc3BlY2lmaWVkIGF0
IHRoZSBzZXNzaW9uIGxldmVsPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp
Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg
Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg
Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpw
IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj
bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h
bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250
LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj
bGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls
eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn
YigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5SZWdhcmRzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z
cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp
emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i
Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz
YW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9
IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt
IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu
Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt
ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs
YXNzPSIiPkNocmlzdGVyPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p
bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy
Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3Nw
YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh
bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i
Ij4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n
LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m
YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xh
c3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNz
PSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTog
NXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g
MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv
bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIFNlcCAyNSwgMjAxNywgYXQgMTA6NTIgUE0sIEVy
aWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHN0eWxlPSJjb2xv
cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmVrckBydGZt
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz
PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u
dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSSBhbSBpbiBm
YXZvciBvZiB0aGUgY2hhbmdlcyB0aGF0IFRheWxvciBwcm9wb3Nlcy48c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rp
dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7
IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi
IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z
aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9
IiI+DQotRWtyPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0
OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw
IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw
dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86
cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6
ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gTW9uLCBTZXAgMjUsIDIw
MTcgYXQgNzozOCBQTSwgRmxlbW1pbmcgQW5kcmVhc2VuICZsdDs8YSBocmVmPSJtYWlsdG86ZmFu
ZHJlYXNAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl
eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZmFuZHJlYXNAY2lzY28uY29tPC9h
PiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDog
MXB0OyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nOiAwY20g
MGNtIDBjbSA2cHQ7IG1hcmdpbi1sZWZ0OiA0LjhwdDsgbWFyZ2luLXJpZ2h0OiAwY207IiBjbGFz
cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx
cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp
ZjsiIGNsYXNzPSIiPg0KSSBtdWNoIHByZWZlciB1c2Ugb2YgdGhlIHRlcm0gJnF1b3Q7bWVkaWEg
ZGVzY3JpcHRpb24mcXVvdDsgYXMgd2VsbCBzaW5jZSB0aGlzIGlzIHdlbGwtZGVmaW5lZCBpbiA0
NTY2LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIg
Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIYXZpbmcgc2FpZCB0aGF0LCBJIHdob2xlaGVhcnRl
ZGx5IGFncmVlIHdpdGggQ2hyaXN0ZXIncyBwb2ludCBhYm91dCB0ZXJtaW5vbG9neSBjaGFuZ2Ug
LSB3ZSBuZWVkIHBlb3BsZSB0byBhZ3JlZSB0byB0aGlzIGJlZm9yZSBlbnRlcnRhaW5pbmcgeWV0
IGFub3RoZXIgdXBkYXRlIG9uIHRoaXMgZnJvbnQuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvIGZv
bGtzLCBwbGVhc2Ugc3BlYWsgdXAgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBhcmUgZm9yLCBhZ2Fp
bnN0LCBvciBpbmRpZmZlcmVudCBpbiB0ZXJtcyBvZiBzYWlkIHRlcm1pbm9sb2d5IGNoYW5nZS48
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhhbmtzPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDEzNiwgMTM2LCAxMzYpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9Imhv
ZW56YiI+LS0gRmxlbW1pbmc8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz
ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi
Pg0KT24gOS8yMi8xNyA0OjA4IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIHdyb3RlOjxvOnAgY2xh
c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpSaWdodC4gSSBj
YW4gb25seSB0aGluayBvZiBvbmUgcG9zc2libGUgaW50ZXJwcmV0YXRpb24gb2YgJnF1b3Q7YWRk
IGF0dHJpYnV0ZSB0byBtZWRpYSBkZXNjcmlwdGlvbiZxdW90Oy4gUkZDNDU2NiB1c2VzIHRoZSBm
b2xsb3dpbmcgcGhyYXNlczo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0i
Ij4NCjx1bCB0eXBlPSJkaXNjIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMGNtOyIgY2xhc3M9IiI+
DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg
Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+
DQomcXVvdDthdHRyaWJ1dGVzIC4uLiBtYXkgYmUgYWRkZWQmcXVvdDs8c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2xp
PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm
b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N
CiZxdW90O2F0dHJpYnV0ZSAuLi4gaW4gdGhlIG1lZGlhIGRlc2NyaXB0aW9uJnF1b3Q7PHNwYW4g
Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+
PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw
LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics
IHNlcmlmOyI+DQomcXVvdDthdHRyaWJ1dGUgaXMgcHJlc2VudCZxdW90OzxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv
bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7
IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi
Pg0KJnF1b3Q7YSBtZWRpYSBkZXNjcmlwdGlvbiBtYXkgaGF2ZSBhbnkgbnVtYmVyIG9mIGF0dHJp
YnV0ZXMmcXVvdDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PG86cCBjbGFzcz0iIj48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn
VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCiZxdW90O2F0dHJpYnV0ZSBmaWVsZHMgY2FuIC4u
LiBiZSBhZGRlZCZxdW90OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p
bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KJnF1b3Q7c3BlY2lmeWluZyB0aGUgYXR0
cmlidXRlJnF1b3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog
J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQomcXVvdDtzZXNzaW9uIGRlc2NyaXB0aW9uIGNv
bnRhaW5pbmcgc3VjaCBhdHRyaWJ1dGVzJnF1b3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48bGkgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx
MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQomcXVvdDthdHRy
aWJ1dGUgTVVTVCBiZSBpbmNsdWRlZCZxdW90OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PC91bD4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi
Pg0KU28sIHRoZSBmb2xsb3dpbmcgd291bGQgYmUgY29uc2lzdGVudCB3aXRoIHRoZSBkZWZpbmVk
IHRlcm1pbm9sb2d5OjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdiBjbGFzcz0iIj4NCjx1bCB0eXBlPSJkaXNjIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMGNt
OyIgY2xhc3M9IiI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBj
bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h
bicsIHNlcmlmOyI+DQomcXVvdDtUaGUgb2ZmZXJlciBNVVNUIGFkZCB0aGUgZm9vIGF0dHJpYnV0
ZSB0byB0aGUgbWVkaWEgZGVzY3JpcHRpb24uJnF1b3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48bGkgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQomcXVvdDtU
aGUgZm9vIGF0dHJpYnV0ZSBNVVNUIGJlIFtwcmVzZW50fGNvbnRhaW5lZHxzcGVjaWZpZWR8aW5j
bHVkZWRdIGluIHRoZSBtZWRpYSBkZXNjcmlwdGlvbi4mcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpw
PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx
cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp
ZjsiPg0KJnF1b3Q7VGhlIG1lZGlhIGRlc2NyaXB0aW9uIE1VU1QgaGF2ZSB0aGUgZm9vIGF0dHJp
YnV0ZS4mcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PC91bD4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg
Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KQnV0ICZx
dW90O2ZvbyBhdHRyaWJ1dGUgTVVTVCBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIG0tbGluZSZxdW90
Oz8gTm90IHNvIG11Y2guPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w
MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz
ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi
Pg0KT24gRnJpLCBTZXAgMjIsIDIwMTcgYXQgOTo1MSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0
OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0i
X2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7
IiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHls
ZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHQ7IGJvcmRlci1s
ZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDZwdDsg
bWFyZ2luLWxlZnQ6IDQuOHB0OyBtYXJnaW4tcmlnaHQ6IDBjbTsiIGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt
aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkhpLDxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEl0IGRlcGVuZHMgb24gaG93IHdlIGludGVycHJl
dCAmcXVvdDthc3NvY2lhdGVkJm5ic3A7d2l0aCZxdW90OzxiciBjbGFzcz0iIj4NCiZndDs8YnIg
Y2xhc3M9IiI+DQomZ3Q7IFRoYXQncyB3aHkgSSBwdXJnZWQgJnF1b3Q7YXNzb2NpYXRlZCB3aXRo
JnF1b3Q7IGZyb20gdGhlIEJVTkRMRSBzcGVjOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGF5bG9yLWIv
ZHJhZnQtc2RwLWJ1bmRsZS9wdWxsLzEiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1
cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL2dpdGh1
Yi5jb20vdGF5bG9yLWIvZHJhZnQtc2RwLWJ1bmRsZS9wdWxsLzE8L2E+Jm5ic3A7PGJyIGNsYXNz
PSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgSXQgYWxtb3N0IGFsd2F5cyBjYW4gYmUgaW50
ZXJwcmV0ZWQgaW4gbXVsdGlwbGUgd2F5cy4gVW5mb3J0dW5hdGVseSB0aGlzIG5ldmVyIGdvdCBp
bnRlZ3JhdGVkLCBJIGFzc3VtZSBiZWNhdXNlIEkgd2FzIHRvbyBsYXRlLjxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCk5vLCB5b3Ugd2VyZSBub3QgOikgSSBoYXZlIGJlZW4gbG9va2luZyBh
dCB5b3VyIENSLCBhbmQgaGF2ZSBiZWVuIGNvbnNpZGVyaW5nIHRvIGludGVncmF0ZSBpdCwgYnV0
IEkgbGF0ZWx5IEkgaGF2ZSBiZWVuIHNvIGJ1c3kgd2l0aCBkcmFmdC1kdGxzLXNkcCBldGMuPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGF2aW5nIHNhaWQgdGhhdCwgd2UgaGF2ZSBjaGFu
Z2VkIHRoZSB0ZXJtaW5vbG9neSBpbiBidW5kbGUgYSBudW1iZXIgb2YgdGltZXMgYWxyZWFkeSAt
IHdlIHJlYWxseSBuZWVkIHRvIHN0b3AgYXQgc29tZSBwb2ludC48YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpUaGUgaGlzdG9yeSBvZiAmcXVvdDthc3NvY2lhdGVkJnF1b3Q7IGlzIHdoZW4g
cGVvcGxlIGNvbW1lbnRlZCB0aGF0IG9uZSBjYW5ub3QgYWRkIGFuIGF0dHJpYnV0ZSwgYWRkcmVz
cyBldGMgdG8gYW4gbS0gbGluZSAoYmVjYXVzZSBhdHRyaWJ1dGVzLCBjLSBsaW5lcyBhbmQgbS0g
bGluZXMgYXJlIHNlcGFyYXRlIFNEUCBwcm9wZXJ0aWVzKS4gU28sIGluc3RlYWQgb2YgdGFsa2lu
ZyBhYm91dCBhZGRpbmcgdGhvc2UgdG8gYW4gbS0gbGluZSB0YWxrIGFib3V0IGFzc29jaWF0aW5n
DQogdGhvc2Ugd2l0aCBhbiBtLSBsaW5lLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk5v
dywgaWYgSSByZW1lbWJlciB0aGUgY2hhbmdlcyBpbiB5b3VyIFBSIGNvcnJlY3RseSwgeW91IGFy
ZSB0YWxraW5nIGFib3V0ICZxdW90O21lZGlhIGRlc2NyaXB0aW9ucyZxdW90Oywgd2hpY2ggd291
bGQgYmUgYW4gJnF1b3Q7ZW52ZWxvcGUmcXVvdDsgY29udGFpbmluZyB0aGUgbS0gbGluZSwgdGhl
IGFkZHJlc3MgYW5kIGF0dHJpYnV0ZXMgYXNzb2NpYXRlZCB3aXRoIHRoYXQgbS0gbGluZS4gVGhl
biB5b3UgY291bGQgc2F5ICZxdW90O2FkZCBhdHRyaWJ1dGUgdG8gdGhlIG1lZGlhIGRlc2NyaXB0
aW9uJnF1b3Q7LA0KIGV0Yy4gUmlnaHQ/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmVn
YXJkcyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDaHJpc3RlcjxvOnAgY2xhc3M9IiI+
PC9vOnA+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog
MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l
dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n
LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46
IDBjbSAwY20gMTJwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS
b21hbicsIHNlcmlmOyI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8
YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiBzdHlsZT0iY29s
b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tbXVzaWNA
aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1
cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu
MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg
c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp
dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0
OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N
Cm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bW11c2lj
QGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp
bmU7IiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHN0eWxlPSJjb2xv
cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3667875B3EEC4745BFFB790B273DC458vidyocom_--


From nobody Tue Sep 26 11:00:18 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9891330AD for ; Tue, 26 Sep 2017 11:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nsP1a-P3a32 for ; Tue, 26 Sep 2017 11:00:15 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92918132D4B for ; Tue, 26 Sep 2017 11:00:14 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id m127so10505973wmm.3 for ; Tue, 26 Sep 2017 11:00:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sqpT5iiPRxCTjl30k3fosxVkI+vHmqPdPkv+y1tpDrE=; b=HFbeeJ7Zy2MuTM9DODkVYKdCASwkWay1jy6JvqWPiK1LeGr5y8TQa4wjFNoH5G7uGO 9XvqmgAi5b3HxwRd1AcNVt97pIMEcyDtu6guOkKjV3OuI1bRSG9uoegLNdUaVKDu+IRx qAZJGw2lEPEhTsw6U2D3TIOR357eapOjzjSpuS3564p4YmrM8GS00H7zl9KUAGYlusv7 7nOaa3Tr4eMfPguWP7bDRZVUOUcul7jEyh+VqbJglrcviFKGNbEk+EtOJzOLQpOChNbs h9h+a1afAD0sbI22jbeN5ePnVgvld0bmsPOJajuzFRYREMJYvlSwgkvZokmpK5fC6bm0 FbZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sqpT5iiPRxCTjl30k3fosxVkI+vHmqPdPkv+y1tpDrE=; b=na3kswzdmY2ajf/wY8szHD/7zQ+fe4Q7sms8hLiCgAHv5NCo8XqjFAW1IzFyzhNBBy LuChntrQ/OL606QV3S28bfM5BLom8XszBRq5duJp/uTMwhb2+mCkuz3L1IkqDy+c4lzQ muBuH3SiNvV5OGBj/nMsBRxpA5nJwSKDsT6p9j+lkTAqcc+GHJCXnTi9HysOM1boCWDk B7Brdyk1faX/oJm9Q/P2cGpmxo+vzjTi/8I8ZtW+9tJqnOMPnDoLziant1qt3Dva82Wt +TBbD6bzuksIt+TGp2gC+ZzC0ES157gfps4g8m6bmGM0j/n+k8CCQ4ozDylhCLdq7K6m lh8A==
X-Gm-Message-State: AHPjjUj6MX9OimTSvb6qjUxjSEVW/08eKTSIVfBRy3K+HolXI8lcezJG OinBtug+ytjVLtzd5BuVgFhtTQhOkzawdXKPASz6Dw==
X-Google-Smtp-Source: AOwi7QBNg7Tfg8AlFYXit6toT65mjUL2vLQCbttMeTd/UTkm0hMTbtTzeGcPidOrXAI/yC/D2TUyli3ickXqDtlyE2g=
X-Received: by 10.28.109.77 with SMTP id i74mr4348611wmc.67.1506448812698; Tue, 26 Sep 2017 11:00:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.54 with HTTP; Tue, 26 Sep 2017 11:00:11 -0700 (PDT)
In-Reply-To: <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>  <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com> <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se> <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com>
From: Taylor Brandstetter 
Date: Tue, 26 Sep 2017 11:00:11 -0700
Message-ID: 
To: Jonathan Lennox 
Cc: Christer Holmberg , Flemming Andreasen ,  Magnus Westerlund , mmusic 
Content-Type: multipart/alternative; boundary="001a11466e725b5ca7055a1b7222"
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 18:00:18 -0000

--001a11466e725b5ca7055a1b7222
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Actually, the PR suggests =E2=80=9Cm=3D section=E2=80=9D. That is used in=
 JSEP, but in 4566
> there is =E2=80=9Cmedia description=E2=80=9D and =E2=80=9Cmedia-level sec=
tion=E2=80=9D. I am not really
> sure that the difference is.


"Media description" and "media-level section" are the same thing, by
definition. My PR defines "m=3D" section as another shorthand, mainly since
this is a phrase JSEP uses heavily. But I'd gladly just use "media
description", "media-level section" or "media section".

On Tue, Sep 26, 2017 at 10:49 AM, Jonathan Lennox 
wrote:

>
> On Sep 26, 2017, at 1:13 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> >I have one question, which actually makes a practical difference to the
> on-the->wire SDP of BUNDLE.
> >
> >For a session- and media-level attribute which has the common pattern
> that the >session-level value provides a default for the media level, a
> non-overridden>session-level attribute is arguably =E2=80=9Cassociated=E2=
=80=9D with a
> media description, but it >clearly isn=E2=80=99t =E2=80=9Cincluded=E2=80=
=9D in it.
> >
> >Should this be permitted?
>
> Not sure I understand. Should what be permitted? :)
>
>
> If BUNDLE says that an attribute of this type =E2=80=9CMUST be associated=
 with a
> media description=E2=80=9D, is it sufficient to have the attribute specif=
ied at the
> session level?
>
>
> Regards,
>
> Christer
>
>
>
>
> On Sep 25, 2017, at 10:52 PM, Eric Rescorla  wrote:
>
> I am in favor of the changes that Taylor proposes.
>
> -Ekr
>
>
> On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen 
> wrote:
>
> I much prefer use of the term "media description" as well since this is
> well-defined in 4566.
>
> Having said that, I wholeheartedly agree with Christer's point about
> terminology change - we need people to agree to this before entertaining
> yet another update on this front.
>
> So folks, please speak up and let us know if you are for, against, or
> indifferent in terms of said terminology change.
>
> Thanks
>
> -- Flemming
>
> On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
>
> Right. I can only think of one possible interpretation of "add attribute
> to media description". RFC4566 uses the following phrases:
>
>    - "attributes ... may be added"
>    - "attribute ... in the media description"
>    - "attribute is present"
>    - "a media description may have any number of attributes"
>    - "attribute fields can ... be added"
>    - "specifying the attribute"
>    - "session description containing such attributes"
>    - "attribute MUST be included"
>
> So, the following would be consistent with the defined terminology:
>
>    - "The offerer MUST add the foo attribute to the media description."
>    - "The foo attribute MUST be [present|contained|specified|included] in
>    the media description."
>    - "The media description MUST have the foo attribute."
>
> But "foo attribute MUST be associated with the m-line"? Not so much.
>
> On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> >> It depends on how we interpret "associated with"
> >
> > That's why I purged "associated with" from the BUNDLE spec:
> https://github.com/taylor-b/draft-sdp-bundle/pull/1
> >
> > It almost always can be interpreted in multiple ways. Unfortunately thi=
s
> never got integrated, I assume because I was too late.
>
> No, you were not :) I have been looking at your CR, and have been
> considering to integrate it, but I lately I have been so busy with
> draft-dtls-sdp etc.
>
> Having said that, we have changed the terminology in bundle a number of
> times already - we really need to stop at some point.
>
> The history of "associated" is when people commented that one cannot add
> an attribute, address etc to an m- line (because attributes, c- lines and
> m- lines are separate SDP properties). So, instead of talking about addin=
g
> those to an m- line talk about associating those with an m- line.
>
> Now, if I remember the changes in your PR correctly, you are talking abou=
t
> "media descriptions", which would be an "envelope" containing the m- line=
,
> the address and attributes associated with that m- line. Then you could s=
ay
> "add attribute to the media description", etc. Right?
>
> Regards,
>
> Christer
>
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

--001a11466e725b5ca7055a1b7222
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Actu=
ally, the PR suggests =E2=80=9Cm=3D section=E2=80=9D. That is used in JSEP,=
 but in 4566 there is =E2=80=9Cmedia description=E2=80=9D and =E2=80=9Cmedi=
a-level section=E2=80=9D. I am not really sure that the difference is.

"Media description" and "=
media-level section" are the same thing, by definition. My PR defines =
"m=3D" section as another shorthand, mainly since this is a phras=
e JSEP uses heavily. But I'd gladly just use "media description&qu=
ot;, "media-level section" or "media section".

On Tue, Sep 26=
, 2017 at 10:49 AM, Jonathan Lennox <jonathan@vidyo.com> wr=
ote:













On Sep 26, 2017, at 1:13 PM, Christer Holmberg <christer.holmberg@ericsson=
.com> wrote:









Hi,



=C2=A0





>I have one question, which =
actually makes a practical difference to the on-the->wire SDP of BUNDLE.







>=C2=A0







>For a session- and media-le=
vel attribute which has the common pattern that the=C2=A0>session-level value provides
 a default for the media level, a non-overridden>session-level attribute is arguably =E2=80=9Cassociate=
d=E2=80=9D with a media description, but it=C2=A0>clearly
 isn=E2=80=99t =E2=80=9Cincluded=E2=80=9D in it.







>=C2=A0







>Should this be permitted?





=C2=A0



Not sure I understand. Should what be permitted? :)












If BUNDLE says that an attribute of this type =E2=80=9CMUST be associated w=
ith a media description=E2=80=9D, is it sufficient to have the attribute sp=
ecified at the session level?
















=C2=A0



Regards,



=C2=A0



Christer



=C2=A0



=C2=A0



=C2=A0









On Sep 25, 2017, at 10:52 PM, Eric Rescorla <ekr=
@rtfm.com> wrote:





=C2=A0







I am in favor of the changes that Taylor proposes.=C2=A0





=C2=A0







-Ekr







=C2=A0









=C2=A0





On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen <fandreas@cisco.com> wrote:







I much prefer use of the term "media description" as well since t=
his is well-defined in 4566.=C2=A0



Having said that, I wholeheartedly agree with Christer's point about te=
rminology change - we need people to agree to this before entertaining yet =
another update on this front.=C2=A0



So folks, please speak up and let us know if you are for, against, or indif=
ferent in terms of said terminology change.=C2=A0



Thanks=C2=A0



-- Flemming=C2=A0=








=C2=A0





On 9/22/17 4:08 PM, Taylor Brandstetter wrote:









Right. I can only think of one possible interpretation of "add attribu=
te to media description". RFC4566 uses the following phrases:




    

  • 
"attributes ... may be added"=C2=A0
  • 
"attribute ... in the media description"=C2=A0
  • 
"attribute is present"=C2=A0
  • 
"a media description may have any number of attributes"=C2=A0
  • 
"attribute fields can ... be added"=C2=A0
  • 
"specifying the attribute"=C2=A0
  • 
"session description containing such attributes"=C2=A0
    • =

  • 
"attribute MUST be included"=C2=A0





So, the following would be consistent with the defined terminology:<=
u>








    

  • 
"The offerer MUST add the foo attribute to the media description."=
;=C2=A0<=
u>
  • 
"The foo attribute MUST be [present|contained|specified|included]=
 in the media description."
  • 
"The media description MUST have the foo attribute."





But "foo attribute MUST be associated with the m-line"? Not so mu=
ch.











=C2=A0





On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:=






Hi,



>> It depends on how we interpret "associated=C2=A0with"
>

> That's why I purged "associated with" from the BUNDLE sp=
ec:=C2=A0https://github.com=
/taylor-b/draft-sdp-bundle/pull/1=C2=A0

>

> It almost always can be interpreted in multiple ways. Unfortunately th=
is never got integrated, I assume because I was too late.



No, you were not :) I have been looking at your CR, and have been consideri=
ng to integrate it, but I lately I have been so busy with draft-dtls-sdp et=
c.



Having said that, we have changed the terminology in bundle a number of tim=
es already - we really need to stop at some point.



The history of "associated" is when people commented that one can=
not add an attribute, address etc to an m- line (because attributes, c- lin=
es and m- lines are separate SDP properties). So, instead of talking about =
adding those to an m- line talk about associating
 those with an m- line.



Now, if I remember the changes in your PR correctly, you are talking about =
"media descriptions", which would be an "envelope" cont=
aining the m- line, the address and attributes associated with that m- line=
. Then you could say "add attribute to the media description",
 etc. Right?



Regards,



Christer







=C2=A0







=C2=A0











_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailm=
an/listinfo/mmusic







=C2=A0





_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailm=
an/listinfo/mmusic





















_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic




--001a11466e725b5ca7055a1b7222--


From nobody Tue Sep 26 11:05:12 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FE7132D51 for ; Tue, 26 Sep 2017 11:05:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.72
X-Spam-Level: 
X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 c1RMWOixzRya for ; Tue, 26 Sep 2017 11:05:08 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 7B3C81330AE for ; Tue, 26 Sep 2017 11:05:08 -0700 (PDT)
X-AuditID: c1b4fb2d-e302b9c0000019be-16-59ca96d260f3
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 75.2A.06590.2D69AC95; Tue, 26 Sep 2017 20:05:06 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 20:04:52 +0200
From: Christer Holmberg 
To: Taylor Brandstetter , Jonathan Lennox 
CC: Flemming Andreasen , Magnus Westerlund , mmusic 
Thread-Topic: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
Thread-Index: AQHTMgJpHMZ02x0tykSASSt9LrLCX6LAx/MAgAAYdICAABdngIAAEiyAgABG5CD//+a0AIAFJBOAgAADz4CAAOh9gIAAKRAw///pJYCAAALlgIAAIpCQ
Date: Tue, 26 Sep 2017 18:04:51 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B562FDD06@ESESSMB109.ericsson.se>
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>  <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com> <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se> <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbE9SvfStFORBh3XdC0ur3jIavH+gq7F /sXnmS2mLn/M4sDiMeX3RlaPBZtKPZYs+cnk0fbsDnsASxSXTUpqTmZZapG+XQJXxrdbOQV3 DCtOHZnN1sC4w6CLkZNDQsBE4mzPE8YuRi4OIYEjjBLvb/QyQTiLGCXWr74GlOHgYBOwkOj+ pw3SICIQKnHqyGpWEJtZoFrizJcLLCC2sICzRNOTySwQNS4SWx4+Y4awmxglXq4XALFZBFQl mmcuZwOxeQV8JZY0XWKG2DWDTeLVhstgQzkFAiUO3H4A1swoICbx/dQaJohl4hK3nsxngrha QGLJnvPMELaoxMvH/1ghbCWJRbc/M4HczCygKbF+lz5Eq6LElO6H7BB7BSVOznzCMoFRdBaS qbMQOmYh6ZiFpGMBI8sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMA4Orjlt+4OxtWvHQ8x CnAwKvHw6k4+FSnEmlhWXJl7iFGCg1lJhNdgAlCINyWxsiq1KD++qDQntfgQozQHi5I4r8O+ CxFCAumJJanZqakFqUUwWSYOTqkGRsGTEocmCH2b8pjlIl+ALEvwpuPrGhns+53sfSdtmRsT uVD+yQ2r3R83mFae2332fcRUBmPDux8Sthp9FDzJ1PpDsMchbvMnrSDB28eevzLb/zCVUTGv zm7pxHp5ubkPqnim/Fp+YdnKovmG01XsJ/91XZUgz3bsZ1CSUPW1lMfxd08zCVxmfKLEUpyR aKjFXFScCACnx8XonwIAAA==
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 18:05:11 -0000

DQo+PkFjdHVhbGx5LCB0aGUgUFIgc3VnZ2VzdHMg4oCcbT0gc2VjdGlvbuKAnS4gVGhhdCBpcyB1
c2VkIGluIEpTRVAsIGJ1dCBpbiA0NTY2IHRoZXJlIGlzIOKAnG1lZGlhIGRlc2NyaXB0aW9u4oCd
IGFuZCDigJxtZWRpYS1sZXZlbCBzZWN0aW9u4oCdLiBJIGFtIA0KPj5ub3QgcmVhbGx5IHN1cmUg
dGhhdCB0aGUgZGlmZmVyZW5jZSBpcy4NCj4NCj4iTWVkaWEgZGVzY3JpcHRpb24iIGFuZCAibWVk
aWEtbGV2ZWwgc2VjdGlvbiIgYXJlIHRoZSBzYW1lIHRoaW5nLCBieSBkZWZpbml0aW9uLiBNeSBQ
UiBkZWZpbmVzICJtPSIgc2VjdGlvbiBhcyBhbm90aGVyIHNob3J0aGFuZCwgDQo+bWFpbmx5IHNp
bmNlIHRoaXMgaXMgYSBwaHJhc2UgSlNFUCB1c2VzIGhlYXZpbHkuIEJ1dCBJJ2QgZ2xhZGx5IGp1
c3QgdXNlICJtZWRpYSBkZXNjcmlwdGlvbiIsICJtZWRpYS1sZXZlbCBzZWN0aW9uIiBvciAibWVk
aWEgc2VjdGlvbiIuDQoNCkknZCBsaWtlIDQ1NjZiaXMgdG8gdXNlIE9ORSBkZWZpbml0aW9uLCBh
bmQgdGhlbiB3ZSB1c2UgdGhlIHNhbWUgZWxzZXdoZXJlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl
cg0KDQoNCg0KDQpPbiBTZXAgMjYsIDIwMTcsIGF0IDE6MTMgUE0sIENocmlzdGVyIEhvbG1iZXJn
IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQpIaSwNCsKgDQo+SSBo
YXZlIG9uZSBxdWVzdGlvbiwgd2hpY2ggYWN0dWFsbHkgbWFrZXMgYSBwcmFjdGljYWwgZGlmZmVy
ZW5jZSB0byB0aGUgb24tdGhlLT53aXJlIFNEUCBvZiBCVU5ETEUuDQo+wqANCj5Gb3IgYSBzZXNz
aW9uLSBhbmQgbWVkaWEtbGV2ZWwgYXR0cmlidXRlIHdoaWNoIGhhcyB0aGUgY29tbW9uIHBhdHRl
cm4gdGhhdCB0aGXCoD5zZXNzaW9uLWxldmVsIHZhbHVlIHByb3ZpZGVzIGEgZGVmYXVsdCBmb3Ig
dGhlIG1lZGlhIGxldmVsLCBhIG5vbi1vdmVycmlkZGVuPnNlc3Npb24tbGV2ZWwgYXR0cmlidXRl
IGlzIGFyZ3VhYmx5IOKAnGFzc29jaWF0ZWTigJ0gd2l0aCBhIG1lZGlhIGRlc2NyaXB0aW9uLCBi
dXQgaXTCoD5jbGVhcmx5IGlzbuKAmXQg4oCcaW5jbHVkZWTigJ0gaW4gaXQuDQo+wqANCj5TaG91
bGQgdGhpcyBiZSBwZXJtaXR0ZWQ/DQrCoA0KTm90IHN1cmUgSSB1bmRlcnN0YW5kLiBTaG91bGQg
d2hhdCBiZSBwZXJtaXR0ZWQ/IDopDQoNCklmIEJVTkRMRSBzYXlzIHRoYXQgYW4gYXR0cmlidXRl
IG9mIHRoaXMgdHlwZSDigJxNVVNUIGJlIGFzc29jaWF0ZWQgd2l0aCBhIG1lZGlhIGRlc2NyaXB0
aW9u4oCdLCBpcyBpdCBzdWZmaWNpZW50IHRvIGhhdmUgdGhlIGF0dHJpYnV0ZSBzcGVjaWZpZWQg
YXQgdGhlIHNlc3Npb24gbGV2ZWw/DQoNCg0KwqANClJlZ2FyZHMsDQrCoA0KQ2hyaXN0ZXINCsKg
DQrCoA0KwqANCk9uIFNlcCAyNSwgMjAxNywgYXQgMTA6NTIgUE0sIEVyaWMgUmVzY29ybGEgPGVr
ckBydGZtLmNvbT4gd3JvdGU6DQrCoA0KSSBhbSBpbiBmYXZvciBvZiB0aGUgY2hhbmdlcyB0aGF0
IFRheWxvciBwcm9wb3Nlcy7CoA0KwqANCi1Fa3INCsKgDQrCoA0KT24gTW9uLCBTZXAgMjUsIDIw
MTcgYXQgNzozOCBQTSwgRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5jb20+IHdy
b3RlOg0KSSBtdWNoIHByZWZlciB1c2Ugb2YgdGhlIHRlcm0gIm1lZGlhIGRlc2NyaXB0aW9uIiBh
cyB3ZWxsIHNpbmNlIHRoaXMgaXMgd2VsbC1kZWZpbmVkIGluIDQ1NjYuwqANCg0KSGF2aW5nIHNh
aWQgdGhhdCwgSSB3aG9sZWhlYXJ0ZWRseSBhZ3JlZSB3aXRoIENocmlzdGVyJ3MgcG9pbnQgYWJv
dXQgdGVybWlub2xvZ3kgY2hhbmdlIC0gd2UgbmVlZCBwZW9wbGUgdG8gYWdyZWUgdG8gdGhpcyBi
ZWZvcmUgZW50ZXJ0YWluaW5nIHlldCBhbm90aGVyIHVwZGF0ZSBvbiB0aGlzIGZyb250LsKgDQoN
ClNvIGZvbGtzLCBwbGVhc2Ugc3BlYWsgdXAgYW5kIGxldCB1cyBrbm93IGlmIHlvdSBhcmUgZm9y
LCBhZ2FpbnN0LCBvciBpbmRpZmZlcmVudCBpbiB0ZXJtcyBvZiBzYWlkIHRlcm1pbm9sb2d5IGNo
YW5nZS7CoA0KDQpUaGFua3PCoA0KDQotLSBGbGVtbWluZ8KgDQrCoA0KT24gOS8yMi8xNyA0OjA4
IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIHdyb3RlOg0KUmlnaHQuIEkgY2FuIG9ubHkgdGhpbmsg
b2Ygb25lIHBvc3NpYmxlIGludGVycHJldGF0aW9uIG9mICJhZGQgYXR0cmlidXRlIHRvIG1lZGlh
IGRlc2NyaXB0aW9uIi4gUkZDNDU2NiB1c2VzIHRoZSBmb2xsb3dpbmcgcGhyYXNlczoNCuKAoiAi
YXR0cmlidXRlcyAuLi4gbWF5IGJlIGFkZGVkIsKgDQrigKIgImF0dHJpYnV0ZSAuLi4gaW4gdGhl
IG1lZGlhIGRlc2NyaXB0aW9uIsKgDQrigKIgImF0dHJpYnV0ZSBpcyBwcmVzZW50IsKgDQrigKIg
ImEgbWVkaWEgZGVzY3JpcHRpb24gbWF5IGhhdmUgYW55IG51bWJlciBvZiBhdHRyaWJ1dGVzIsKg
DQrigKIgImF0dHJpYnV0ZSBmaWVsZHMgY2FuIC4uLiBiZSBhZGRlZCLCoA0K4oCiICJzcGVjaWZ5
aW5nIHRoZSBhdHRyaWJ1dGUiwqANCuKAoiAic2Vzc2lvbiBkZXNjcmlwdGlvbiBjb250YWluaW5n
IHN1Y2ggYXR0cmlidXRlcyLCoA0K4oCiICJhdHRyaWJ1dGUgTVVTVCBiZSBpbmNsdWRlZCLCoA0K
U28sIHRoZSBmb2xsb3dpbmcgd291bGQgYmUgY29uc2lzdGVudCB3aXRoIHRoZSBkZWZpbmVkIHRl
cm1pbm9sb2d5Og0K4oCiICJUaGUgb2ZmZXJlciBNVVNUIGFkZCB0aGUgZm9vIGF0dHJpYnV0ZSB0
byB0aGUgbWVkaWEgZGVzY3JpcHRpb24uIsKgDQrigKIgIlRoZSBmb28gYXR0cmlidXRlIE1VU1Qg
YmUgW3ByZXNlbnR8Y29udGFpbmVkfHNwZWNpZmllZHxpbmNsdWRlZF0gaW4gdGhlIG1lZGlhIGRl
c2NyaXB0aW9uLiINCuKAoiAiVGhlIG1lZGlhIGRlc2NyaXB0aW9uIE1VU1QgaGF2ZSB0aGUgZm9v
IGF0dHJpYnV0ZS4iDQpCdXQgImZvbyBhdHRyaWJ1dGUgTVVTVCBiZSBhc3NvY2lhdGVkIHdpdGgg
dGhlIG0tbGluZSI/IE5vdCBzbyBtdWNoLg0KwqANCk9uIEZyaSwgU2VwIDIyLCAyMDE3IGF0IDk6
NTEgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+
IHdyb3RlOg0KSGksDQoNCj4+IEl0IGRlcGVuZHMgb24gaG93IHdlIGludGVycHJldCAiYXNzb2Np
YXRlZMKgd2l0aCINCj4NCj4gVGhhdCdzIHdoeSBJIHB1cmdlZCAiYXNzb2NpYXRlZCB3aXRoIiBm
cm9tIHRoZSBCVU5ETEUgc3BlYzrCoGh0dHBzOi8vZ2l0aHViLmNvbS90YXlsb3ItYi9kcmFmdC1z
ZHAtYnVuZGxlL3B1bGwvMcKgDQo+DQo+IEl0IGFsbW9zdCBhbHdheXMgY2FuIGJlIGludGVycHJl
dGVkIGluIG11bHRpcGxlIHdheXMuIFVuZm9ydHVuYXRlbHkgdGhpcyBuZXZlciBnb3QgaW50ZWdy
YXRlZCwgSSBhc3N1bWUgYmVjYXVzZSBJIHdhcyB0b28gbGF0ZS4NCg0KTm8sIHlvdSB3ZXJlIG5v
dCA6KSBJIGhhdmUgYmVlbiBsb29raW5nIGF0IHlvdXIgQ1IsIGFuZCBoYXZlIGJlZW4gY29uc2lk
ZXJpbmcgdG8gaW50ZWdyYXRlIGl0LCBidXQgSSBsYXRlbHkgSSBoYXZlIGJlZW4gc28gYnVzeSB3
aXRoIGRyYWZ0LWR0bHMtc2RwIGV0Yy4NCg0KSGF2aW5nIHNhaWQgdGhhdCwgd2UgaGF2ZSBjaGFu
Z2VkIHRoZSB0ZXJtaW5vbG9neSBpbiBidW5kbGUgYSBudW1iZXIgb2YgdGltZXMgYWxyZWFkeSAt
IHdlIHJlYWxseSBuZWVkIHRvIHN0b3AgYXQgc29tZSBwb2ludC4NCg0KVGhlIGhpc3Rvcnkgb2Yg
ImFzc29jaWF0ZWQiIGlzIHdoZW4gcGVvcGxlIGNvbW1lbnRlZCB0aGF0IG9uZSBjYW5ub3QgYWRk
IGFuIGF0dHJpYnV0ZSwgYWRkcmVzcyBldGMgdG8gYW4gbS0gbGluZSAoYmVjYXVzZSBhdHRyaWJ1
dGVzLCBjLSBsaW5lcyBhbmQgbS0gbGluZXMgYXJlIHNlcGFyYXRlIFNEUCBwcm9wZXJ0aWVzKS4g
U28sIGluc3RlYWQgb2YgdGFsa2luZyBhYm91dCBhZGRpbmcgdGhvc2UgdG8gYW4gbS0gbGluZSB0
YWxrIGFib3V0IGFzc29jaWF0aW5nIHRob3NlIHdpdGggYW4gbS0gbGluZS4NCg0KTm93LCBpZiBJ
IHJlbWVtYmVyIHRoZSBjaGFuZ2VzIGluIHlvdXIgUFIgY29ycmVjdGx5LCB5b3UgYXJlIHRhbGtp
bmcgYWJvdXQgIm1lZGlhIGRlc2NyaXB0aW9ucyIsIHdoaWNoIHdvdWxkIGJlIGFuICJlbnZlbG9w
ZSIgY29udGFpbmluZyB0aGUgbS0gbGluZSwgdGhlIGFkZHJlc3MgYW5kIGF0dHJpYnV0ZXMgYXNz
b2NpYXRlZCB3aXRoIHRoYXQgbS0gbGluZS4gVGhlbiB5b3UgY291bGQgc2F5ICJhZGQgYXR0cmli
dXRlIHRvIHRoZSBtZWRpYSBkZXNjcmlwdGlvbiIsIGV0Yy4gUmlnaHQ/DQoNClJlZ2FyZHMsDQoN
CkNocmlzdGVyDQrCoA0KwqANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCsKgDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0K
bW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t
dXNpYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg==


From nobody Tue Sep 26 11:16:16 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3124F1330AE for ; Tue, 26 Sep 2017 11:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keR6pFk4cjqS for ; Tue, 26 Sep 2017 11:16:12 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B6E1329F9 for ; Tue, 26 Sep 2017 11:16:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39484; q=dns/txt; s=iport; t=1506449772; x=1507659372; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Of15aaT6OrrzfmWZZNd+IIzod3H13R5zCT9Nb7kAgwQ=; b=dwJ+fknTD4WcF7kH+YubhF5hxDR1cm7ynpPf6qY4iGP/v7NBT0QY75Zm nY11vDujr9lu0rSxcyQA8koVLDKUWWGkmq5O/vGPvbCvUhXpozHDL7pe/ PKoHeU8KAJ3Vr0LlRjM1n+E9gAPeKIez1qfMjXdM/Dbonpvz/sjkDFGwh A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQCrmMpZ/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9sZG4ng3aaG4FLK5Yqgg8DChgBCoRJTwKET0AXAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBIQRHCxALGCABBgMCAicfEQYBDAYCAQGKIQUIEKgrgW06J?= =?us-ascii?q?4p0AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDK4ICgVGBaiuCfYgXgmAFihaXCod?= =?us-ascii?q?ejH+CE4Vvg1qHKooLizyBOSECNEJMUyUVSYUaHIIDJDaKewEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,441,1500940800";  d="scan'208,217";a="300292481"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2017 18:16:11 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8QIG9Bt021884; Tue, 26 Sep 2017 18:16:10 GMT
To: Jonathan Lennox , Christer Holmberg 
Cc: Eric Rescorla , Magnus Westerlund , mmusic 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>  <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com> <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se> <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com>
From: Flemming Andreasen 
Message-ID: 
Date: Tue, 26 Sep 2017 14:16:33 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com>
Content-Type: multipart/alternative; boundary="------------4694B1D83D576E03E207C1EC"
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 18:16:15 -0000

This is a multi-part message in MIME format.
--------------4694B1D83D576E03E207C1EC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 9/26/17 1:49 PM, Jonathan Lennox wrote:
>
>> On Sep 26, 2017, at 1:13 PM, Christer Holmberg 
>> > > wrote:
>>
>> Hi,
>> >I have one question, which actually makes a practical difference to 
>> the on-the->wire SDP of BUNDLE.
>> >
>> >For a session- and media-level attribute which has the common pattern 
>> that the>session-level value provides a default for the media level, 
>> a non-overridden>session-level attribute is arguably “associated” 
>> with a media description, but it>clearly isn’t “included” in it.
>> >
>> >Should this be permitted?
>> Not sure I understand. Should what be permitted? :)
>
> If BUNDLE says that an attribute of this type “MUST be associated with 
> a media description”, is it sufficient to have the attribute specified 
> at the session level?
>
Yes - this is how SDP normally works and we shouldn't change that.

Thanks

-- Flemming (as individual)

>> Regards,
>> Christer
>>
>>     On Sep 25, 2017, at 10:52 PM, Eric Rescorla >     > wrote:
>>     I am in favor of the changes that Taylor proposes.
>>     -Ekr
>>     On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen
>>     > wrote:
>>
>>         I much prefer use of the term "media description" as well
>>         since this is well-defined in 4566.
>>
>>         Having said that, I wholeheartedly agree with Christer's
>>         point about terminology change - we need people to agree to
>>         this before entertaining yet another update on this front.
>>
>>         So folks, please speak up and let us know if you are for,
>>         against, or indifferent in terms of said terminology change.
>>
>>         Thanks
>>
>>         -- Flemming
>>         On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
>>
>>             Right. I can only think of one possible interpretation of
>>             "add attribute to media description". RFC4566 uses the
>>             following phrases:
>>
>>               * "attributes ... may be added"
>>               * "attribute ... in the media description"
>>               * "attribute is present"
>>               * "a media description may have any number of attributes"
>>               * "attribute fields can ... be added"
>>               * "specifying the attribute"
>>               * "session description containing such attributes"
>>               * "attribute MUST be included"
>>
>>             So, the following would be consistent with the defined
>>             terminology:
>>
>>               * "The offerer MUST add the foo attribute to the media
>>                 description."
>>               * "The foo attribute MUST be
>>                 [present|contained|specified|included] in the media
>>                 description."
>>               * "The media description MUST have the foo attribute."
>>
>>             But "foo attribute MUST be associated with the m-line"?
>>             Not so much.
>>             On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg
>>             >             > wrote:
>>
>>                 Hi,
>>
>>                 >> It depends on how we interpret "associated with"
>>                 >
>>                 > That's why I purged "associated with" from the
>>                 BUNDLE
>>                 spec:https://github.com/taylor-b/draft-sdp-bundle/pull/1
>>                 >
>>                 > It almost always can be interpreted in multiple
>>                 ways. Unfortunately this never got integrated, I
>>                 assume because I was too late.
>>
>>                 No, you were not :) I have been looking at your CR,
>>                 and have been considering to integrate it, but I
>>                 lately I have been so busy with draft-dtls-sdp etc.
>>
>>                 Having said that, we have changed the terminology in
>>                 bundle a number of times already - we really need to
>>                 stop at some point.
>>
>>                 The history of "associated" is when people commented
>>                 that one cannot add an attribute, address etc to an
>>                 m- line (because attributes, c- lines and m- lines
>>                 are separate SDP properties). So, instead of talking
>>                 about adding those to an m- line talk about
>>                 associating those with an m- line.
>>
>>                 Now, if I remember the changes in your PR correctly,
>>                 you are talking about "media descriptions", which
>>                 would be an "envelope" containing the m- line, the
>>                 address and attributes associated with that m- line.
>>                 Then you could say "add attribute to the media
>>                 description", etc. Right?
>>
>>                 Regards,
>>
>>                 Christer
>>
>>
>>         _______________________________________________
>>         mmusic mailing list
>>         mmusic@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/mmusic
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     mmusic@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>
>


--------------4694B1D83D576E03E207C1EC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    

    
On 9/26/17 1:49 PM, Jonathan Lennox
      wrote:

    

    

      
      

      

        

          
On Sep 26, 2017, at 1:13 PM, Christer Holmberg
            <christer.holmberg@ericsson.com>
            wrote:

          

          

            

              

                Hi,

              

                 

              

                

                  >I
                  have one question, which actually makes a practical
                  difference to the on-the->wire SDP of BUNDLE.

              

              

                

                  > 

              

              

                

                  >For
                  a session- and media-level attribute which has the
                  common pattern that the >session-level
                  value provides a default for the media level, a
                  non-overridden>session-level attribute is
                  arguably “associated” with a media description, but it >clearly
                  isn’t “included” in it.

              

              

                

                  > 

              

              

                

                  >Should
                  this be permitted?

              

              

                 

              

                Not
                  sure I understand. Should what be permitted? :)

            

          

        

        


        

        If BUNDLE says that an attribute of this type “MUST be
        associated with a media description”, is it sufficient to have
        the attribute specified at the session level?

      


      

    

    Yes - this is how SDP normally works and we shouldn't change that. 

    

    Thanks 

    

    -- Flemming (as individual)

    

    

      

        

          

            

              

                

              

                 

              

                Regards,

              

                 

              

                Christer

              

                 

              

                 

              

                 

              

                

                  

                    

                      On Sep 25, 2017, at 10:52 PM, Eric Rescorla <ekr@rtfm.com>
                      wrote:

                  

                  

                     

                  

                    

                      

                        I am in favor of the changes that Taylor
                        proposes. 

                      

                        

                           

                      

                      

                        

                          -Ekr

                      

                      

                        

                           

                      

                    

                    

                      

                         

                      

                        

                          On Mon, Sep 25, 2017 at 7:38 PM, Flemming
                          Andreasen <fandreas@cisco.com>
                          wrote:

                        

                          

                            

                              I much prefer use of the term "media
                              description" as well since this is
                              well-defined in 4566. 

                              

                              Having said that, I wholeheartedly agree
                              with Christer's point about terminology
                              change - we need people to agree to this
                              before entertaining yet another update on
                              this front. 

                              

                              So folks, please speak up and let us know
                              if you are for, against, or indifferent in
                              terms of said terminology change. 

                              

                              Thanks 

                              

                                -- Flemming 

                            

                              

                                

                                   

                                

                                  

                                    On 9/22/17 4:08 PM, Taylor
                                    Brandstetter wrote:

                                

                                

                                  

                                    

                                      Right. I can only think of one
                                      possible interpretation of "add
                                      attribute to media description".
                                      RFC4566 uses the following
                                      phrases:

                                    

                                      
    
                                        
  • 
                                          "attributes ... may be added" 
    • 
                                        
  • 
                                          "attribute ... in the media
                                          description" 
    • 
                                        
  • 
                                          "attribute is present" 
    • 
                                        
  • 
                                          "a media description may have
                                          any number of attributes" 
    • 
                                        
  • 
                                          "attribute fields can ... be
                                          added" 
    • 
                                        
  • 
                                          "specifying the attribute" 
    • 
                                        
  • 
                                          "session description
                                          containing such attributes" 
    • 
                                        
  • 
                                          "attribute MUST be included" 
    • 
                                      

                                      

                                        

                                          So, the following would be
                                          consistent with the defined
                                          terminology:

                                      

                                    

                                    

                                      
    
                                        
  • 
                                          "The offerer MUST add the foo
                                          attribute to the media
                                          description." 
    • 
                                        
  • 
                                          "The foo attribute MUST be
                                          [present|contained|specified|included]
                                          in the media description."
    • 
                                        
  • 
                                          "The media description MUST
                                          have the foo attribute."
    • 
                                      

                                      

                                        

                                          But "foo attribute MUST be
                                          associated with the m-line"?
                                          Not so much.

                                      

                                    

                                  

                                  

                                    

                                       

                                    

                                      

                                        On Fri, Sep 22, 2017 at 9:51 PM,
                                        Christer Holmberg <christer.holmberg@ericsson.com>
                                        wrote:

                                      

                                        

                                          Hi,

                                          

                                          >> It depends on how we
                                          interpret "associated with"

                                          >

                                          > That's why I purged
                                          "associated with" from the
                                          BUNDLE spec: https://github.com/taylor-b/draft-sdp-bundle/pull/1 

                                          >

                                          > It almost always can be
                                          interpreted in multiple ways.
                                          Unfortunately this never got
                                          integrated, I assume because I
                                          was too late.

                                          

                                          No, you were not :) I have
                                          been looking at your CR, and
                                          have been considering to
                                          integrate it, but I lately I
                                          have been so busy with
                                          draft-dtls-sdp etc.

                                          

                                          Having said that, we have
                                          changed the terminology in
                                          bundle a number of times
                                          already - we really need to
                                          stop at some point.

                                          

                                          The history of "associated" is
                                          when people commented that one
                                          cannot add an attribute,
                                          address etc to an m- line
                                          (because attributes, c- lines
                                          and m- lines are separate SDP
                                          properties). So, instead of
                                          talking about adding those to
                                          an m- line talk about
                                          associating those with an m-
                                          line.

                                          

                                          Now, if I remember the changes
                                          in your PR correctly, you are
                                          talking about "media
                                          descriptions", which would be
                                          an "envelope" containing the
                                          m- line, the address and
                                          attributes associated with
                                          that m- line. Then you could
                                          say "add attribute to the
                                          media description", etc.
                                          Right?

                                          

                                          Regards,

                                          

                                          Christer

                                      

                                    

                                    

                                       

                                  

                                

                                

                                   

                              

                            

                          

                          

                            

_______________________________________________

                            mmusic mailing list

                            mmusic@ietf.org

                            https://www.ietf.org/mailman/listinfo/mmusic

                        

                      

                      

                         

                    

                    

                      _______________________________________________

                      mmusic mailing list

                      mmusic@ietf.org

                      https://www.ietf.org/mailman/listinfo/mmusic

                  

                

              

            

          

        

      

      

    

    

  


--------------4694B1D83D576E03E207C1EC--


From nobody Tue Sep 26 11:18:04 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05E11342D1 for ; Tue, 26 Sep 2017 11:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHrLppG5Mi3n for ; Tue, 26 Sep 2017 11:18:01 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB821320CF for ; Tue, 26 Sep 2017 11:18:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5005; q=dns/txt; s=iport; t=1506449880; x=1507659480; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=sVhJWXn05dxaPemXrIGYdClhkOwQlsW3cOivZILj8w4=; b=id6/a+luGvb00RVYJhjAviQd8+JCz/pHP/pfZQhspNHHJ2AHvGiAXPd0 SSpsyNh0g1O4oBFj679bD/fOqSNvXRb+WmgHvkXOo8IKw6jM0/KFT1qt8 jBFs5kwCMdadel6rqBr4JXg7VLxHn2J6os0Ds5OieSexwUW1naLkk+lbY Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQCrmMpZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1tkbieDdpobgUsrliqCEgoYC4RJTwKET0EWAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBIQQLAQU2CwULCxgCAiYCAicwBgEMBgIBAYohBQgQqCuBbTqLG?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBGQWBDoIdggKBUYFqK4J9iBeCYAEEihaXCod?= =?us-ascii?q?ejH+CE4Vvg1qHKooLizyBOSYGK4EOUyUVSYUaHIIDJDaKewEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,441,1500940800"; d="scan'208";a="300293082"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Sep 2017 18:17:58 +0000
Received: from [10.118.10.21] (rtp-fandreas-2-8814.cisco.com [10.118.10.21]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8QIHvV7022385; Tue, 26 Sep 2017 18:17:58 GMT
To: Christer Holmberg , Taylor Brandstetter , Jonathan Lennox 
Cc: Magnus Westerlund , mmusic 
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>  <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com> <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se> <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com>  <7594FB04B1934943A5C02806D1A2204B562FDD06@ESESSMB109.ericsson.se>
From: Flemming Andreasen 
Message-ID: <193fe486-3a06-030e-95e2-db62bbc1b70c@cisco.com>
Date: Tue, 26 Sep 2017 14:18:21 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562FDD06@ESESSMB109.ericsson.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 18:18:03 -0000

On 9/26/17 2:04 PM, Christer Holmberg wrote:
>>> Actually, the PR suggests “m= section”. That is used in JSEP, but in 4566 there is “media description” and “media-level section”. I am
>>> not really sure that the difference is.
>> "Media description" and "media-level section" are the same thing, by definition. My PR defines "m=" section as another shorthand,
>> mainly since this is a phrase JSEP uses heavily. But I'd gladly just use "media description", "media-level section" or "media section".
> I'd like 4566bis to use ONE definition, and then we use the same elsewhere.

4566bis is currently in WGLC - can you provide that feedback to the WGLC 
thread (as well as any other comments you may have on 4566bis) ?

Thanks

-- Flemming


> Regards,
>
> Christer
>
>
>
>
> On Sep 26, 2017, at 1:13 PM, Christer Holmberg  wrote:
>
> Hi,
>   
>> I have one question, which actually makes a practical difference to the on-the->wire SDP of BUNDLE.
>>   
>> For a session- and media-level attribute which has the common pattern that the >session-level value provides a default for the media level, a non-overridden>session-level attribute is arguably “associated” with a media description, but it >clearly isn’t “included” in it.
>>   
>> Should this be permitted?
>   
> Not sure I understand. Should what be permitted? :)
>
> If BUNDLE says that an attribute of this type “MUST be associated with a media description”, is it sufficient to have the attribute specified at the session level?
>
>
>   
> Regards,
>   
> Christer
>   
>   
>   
> On Sep 25, 2017, at 10:52 PM, Eric Rescorla  wrote:
>   
> I am in favor of the changes that Taylor proposes.
>   
> -Ekr
>   
>   
> On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen  wrote:
> I much prefer use of the term "media description" as well since this is well-defined in 4566.
>
> Having said that, I wholeheartedly agree with Christer's point about terminology change - we need people to agree to this before entertaining yet another update on this front.
>
> So folks, please speak up and let us know if you are for, against, or indifferent in terms of said terminology change.
>
> Thanks
>
> -- Flemming
>   
> On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
> Right. I can only think of one possible interpretation of "add attribute to media description". RFC4566 uses the following phrases:
> • "attributes ... may be added"
> • "attribute ... in the media description"
> • "attribute is present"
> • "a media description may have any number of attributes"
> • "attribute fields can ... be added"
> • "specifying the attribute"
> • "session description containing such attributes"
> • "attribute MUST be included"
> So, the following would be consistent with the defined terminology:
> • "The offerer MUST add the foo attribute to the media description."
> • "The foo attribute MUST be [present|contained|specified|included] in the media description."
> • "The media description MUST have the foo attribute."
> But "foo attribute MUST be associated with the m-line"? Not so much.
>   
> On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg  wrote:
> Hi,
>
>>> It depends on how we interpret "associated with"
>> That's why I purged "associated with" from the BUNDLE spec: https://github.com/taylor-b/draft-sdp-bundle/pull/1
>>
>> It almost always can be interpreted in multiple ways. Unfortunately this never got integrated, I assume because I was too late.
> No, you were not :) I have been looking at your CR, and have been considering to integrate it, but I lately I have been so busy with draft-dtls-sdp etc.
>
> Having said that, we have changed the terminology in bundle a number of times already - we really need to stop at some point.
>
> The history of "associated" is when people commented that one cannot add an attribute, address etc to an m- line (because attributes, c- lines and m- lines are separate SDP properties). So, instead of talking about adding those to an m- line talk about associating those with an m- line.
>
> Now, if I remember the changes in your PR correctly, you are talking about "media descriptions", which would be an "envelope" containing the m- line, the address and attributes associated with that m- line. Then you could say "add attribute to the media description", etc. Right?
>
> Regards,
>
> Christer
>   
>   
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>   
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Tue Sep 26 11:39:28 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1447C1323F7; Tue, 26 Sep 2017 11:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7F1_CMzNW6jo; Tue, 26 Sep 2017 11:39:26 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 7A2DA13305E; Tue, 26 Sep 2017 11:39:22 -0700 (PDT)
X-AuditID: c1b4fb3a-9e1d49c0000051a3-a8-59ca9ed89215
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0F.0E.20899.8DE9AC95; Tue, 26 Sep 2017 20:39:20 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Tue, 26 Sep 2017 20:39:19 +0200
From: Christer Holmberg 
To: Flemming Andreasen , mmusic , "draft-ietf-mmusic-rfc4566bis@ietf.org" 
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23: media description vs media-level section
Thread-Index: AdM29qzx1SUj0Rn9Rk+eetpSJxUupQ==
Date: Tue, 26 Sep 2017 18:39:19 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B562FDDE3@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2K7se6NeaciDR481bZYu+4ys8X7C7oW U5c/ZnFg9pjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4Mk7v389UcIe/YunPuSwNjCv4uxg5 OSQETCR+Nh5j62Lk4hASOMIo0dGwlB3CWcQo8XznJJYuRg4ONgELie5/2iBxEYFZjBILlm9j AukWFsiUuLtkExNIjYhAlsS7bn2QsIiAnkTfrx9sIDaLgKrEii9vWEBsXgFfiS07OsBsRgEx ie+n1oCNYRYQl7j1ZD4TxEECEkv2nGeGsEUlXj7+xwphK0ksuv0ZbBWzgKbE+l36EK2KElO6 H7JDjBeUODnzCcsERqFZSKbOQuiYhaRjFpKOBYwsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJL NjECQ/zglt9WOxgPPnc8xCjAwajEw/ty4qlIIdbEsuLK3EOMEhzMSiK8BhOAQrwpiZVVqUX5 8UWlOanFhxilOViUxHkd9l2IEBJITyxJzU5NLUgtgskycXBKNTBOU1dXnMS5bZOd5txLPl3r JI8+knhxhvP5Ga/Ih2rfUze8+hRhIvtN1sFT6cQ/Te2MgMkSwn98HLUXMWwrcXj5bXfXQ813 rxZWLz/39PPx61d+lfI2f8l9sf/F38m8k46yVXrE/9ryduaDDk6VVTNk9848/PNKuNNMFSa5 TdbNy6PFbkSsnSwgpMRSnJFoqMVcVJwIAKfL7aptAgAA
Archived-At: 
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23: media description vs media-level section
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 18:39:27 -0000

SGksDQoNCk9uZSBlZGl0b3JpYWwgY29tbWVudDoNCg0KVGhlIGRyYWZ0IHVzZXMgYm90aCAibWVk
aWEgZGVzY3JpcHRpb24iIGFuZCAibWVkaWEtbGV2ZWwgc2VjdGlvbiIgdGVybWlub2xvZ3ksIGJ1
dCBhdCBsZWFzdCBJIGNhbid0IHNlZSBhbnkgZGlmZmVyZW5jZS4gVGhlIGRlZmluaXRpb24gb2Yg
dGhvc2UgdGVybXMgYXJlIGFsc28gaWRlbnRpY2FsOg0KDQoJIkVhY2ggbWVkaWEgZGVzY3JpcHRp
b24gc3RhcnRzIHdpdGggYW4gIm09IiBsaW5lIGFuZCBpcyB0ZXJtaW5hdGVkIGJ5IGVpdGhlciB0
aGUgbmV4dCAibT0iIGxpbmUuLi4iCQkoc2VjdGlvbiA1LjE0KQ0KDQouLi5hbmQ6DQoNCgkiRWFj
aCBtZWRpYS1sZXZlbCBzZWN0aW9uIHN0YXJ0cyB3aXRoIGFuICJtPSIgbGluZSBhbmQgY29udGlu
dWVzIHRvIHRoZSBuZXh0IG1lZGlhLWxldmVsIHNlY3Rpb24uLi4iCShzZWN0aW9uIDUpDQoNCiJt
ZWRpYS1sZXZlbCBzZWN0aW9uIiBvbmx5IGFwcGVhcnMgaW4gb25lIHBhcmFncmFwaCBvZiB0aGUg
d2hvbGUgZG9jdW1lbnQuIA0KDQpEbyB3ZSBuZWVkIGJvdGg/DQoNClJlZ2FyZHMsDQoNCkNocmlz
dGVyDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW11c2lj
IFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGbGVtbWluZyBB
bmRyZWFzZW4NClNlbnQ6IDE4IFNlcHRlbWJlciAyMDE3IDE1OjU5DQpUbzogbW11c2ljIDxtbXVz
aWNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW1tdXNpYy1yZmM0NTY2YmlzQGlldGYub3JnDQpTdWJq
ZWN0OiBbTU1VU0lDXSBXR0xDIG9uIGRyYWZ0LWlldGYtbW11c2ljLXJmYzQ1NjZiaXMtMjMNCg0K
R3JlZXRpbmdzIE1NVVNJQw0KDQpUaGlzIGlzIHRvIGFubm91bmNlIGEgMiB3ZWVrIFdHTEMgb24g
dGhlIGRyYWZ0Og0KDQogwqDCoMKgwqAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0
Zi1tbXVzaWMtcmZjNDU2NmJpcy0yMy50eHQNCg0KYXMgUHJvcG9zZWQgU3RhbmRhcmQuIFBsZWFz
ZSByZXZpZXcgYW5kIHByb3ZpZGUgYW55IGNvbW1lbnRzIHlvdSBtYXkgaGF2ZSBvbiB0aGUgZG9j
dW1lbnQgYnkgTW9uZGF5LCBPY3RvYmVyIDIsIDIwMTcuIENvbW1lbnRzIHNob3VsZCBiZSBzZW50
IHRvIHRoZSBkb2N1bWVudCBhdXRob3JzIGFuZCB0aGUgTU1VU0lDIFdHIGxpc3QuIElmIHlvdSBy
ZXZpZXcgdGhlIGRvY3VtZW50IGJ1dCBkbyBub3QgaGF2ZSBhbnkgY29tbWVudHMsIHBsZWFzZSBz
ZW5kIGEgbm90ZSB0byB0aGF0IGVmZmVjdCBhcyB3ZWxsLg0KDQpUaGFua3MNCg0KLS0gRmxlbW1p
bmcgKE1NVVNJQyBjby1jaGFpcikNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg==


From nobody Tue Sep 26 11:59:46 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377D6134314 for ; Tue, 26 Sep 2017 11:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4Btm9m_EQ9d for ; Tue, 26 Sep 2017 11:59:43 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::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 8C1181342D3 for ; Tue, 26 Sep 2017 11:59:43 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id r71so5978263pfe.12 for ; Tue, 26 Sep 2017 11:59:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UlPg1uoF2FXh5D54fEkDPc759RPLt33PgxeykXR1p8c=; b=1cilUC0vZeVh/Fh5fbf51NtpQd7E/6dC+JYcPS1QyG8Xoeam0CHR2APERwU63oJM3B /yve2I/R+p4hpAhQc21gThOQV0FSzt9E6/wVPApIMAgK5KVOFMSPnCApiYU3g4jyfp/I SqLJ0pzLQqZ69Wux1PtwhsVFS3uE9p5ePBWumWAXxf0jI4LUxB63jSGnmxkGY/m1wI0o wUWIzIMNMbfrwjT/FH7yh9kfYO6B+BuTsOVCDEpOxU5p4X2rs9crASwykO7fkem4vJYz Off4h+LewVvo84EGDTJxSn1LlsYZTZDiUXtB9k2BQMrCceWpsZlw8ikRtMemBND/pHXU ckWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UlPg1uoF2FXh5D54fEkDPc759RPLt33PgxeykXR1p8c=; b=CfFxvIHe3gjdSjnZJ1JSRjukb64JImADpqPF1Bbr4kOG9CpJNYr5qOAzQzc4E6kKP6 3pqbmmRI61gWy3udwT49pXmZiWXZfN2esLdyut97qGFJAgQd8g8QPG+bbSIgsZZHPMY7 WwJgWVF55yR64rrdIR1hldTtaNLvTV65BcNjjFqH17O+byev+gzgIhn6b+lONYYLgnMj VSlu/bSc5qcK2EVao4fj8l8RtaaObsHTWtCaf2WiHvA7otmv1fH+3jh0y6JIdpI45YgU iFTxUMaG2hQi2bt0IJQBrE+NAAdGtEvE2XfkM1Ylh7VMaQvl08I8XQJUvVfxcMNZauex 9bbw==
X-Gm-Message-State: AHPjjUhOrbfPY0Fz3H1EmUUV9uFyd6/JiWbd/vl05QJ1d7cOwxo6Tcef T+2F7M/Y/78mzpTRcG2CCJafuQWg
X-Received: by 10.99.119.133 with SMTP id s127mr12126469pgc.271.1506452382836;  Tue, 26 Sep 2017 11:59:42 -0700 (PDT)
Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id z26sm18759373pfa.49.2017.09.26.11.59.41 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Sep 2017 11:59:41 -0700 (PDT)
Received: by mail-pf0-f179.google.com with SMTP id d187so5981279pfg.11 for ; Tue, 26 Sep 2017 11:59:41 -0700 (PDT)
X-Google-Smtp-Source: AOwi7QAgDqV8wLR43kqR+hdUujFDa1XhOtFZpjRxtXgl7LBNTWGfGhNnU/MZnlVhYjcGPD3SeTy0tErnmvIxuwrFDHo=
X-Received: by 10.101.75.136 with SMTP id t8mr11798579pgq.282.1506452381148; Tue, 26 Sep 2017 11:59:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.189.2 with HTTP; Tue, 26 Sep 2017 11:59:40 -0700 (PDT)
From: Roman Shpount 
Date: Tue, 26 Sep 2017 14:59:40 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "mmusic@ietf.org" 
Content-Type: multipart/alternative; boundary="089e082344200cab77055a1c4719"
Archived-At: 
Subject: [MMUSIC] Call to discuss DTLS-SDP issue on whether an SDP answerer can trigger a new DTLS association
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 18:59:45 -0000

--089e082344200cab77055a1c4719
Content-Type: text/plain; charset="UTF-8"

Hi All,

I have allocated the following bridge for the conference call on Thursday,
September 28, 2017 12:00 PM EDT.

I have tried to invite all participants who indicated interest in this
call, but wanted to provide the conference call information on the list as
well

*Join the meeting: join.me/112-807-485 *

Thursday, September 28, 2017 12:00 PM
Eastern Time (US & Canada)
In my time zone? 
*To dial in by phone:*

United States - Los Angeles, CA
*+1.213.226.1066 <+1.213.226.1066,,112807485#>*

United States - New York, NY
*+1.646.307.1990 <+1.646.307.1990,,112807485#>*

United States - San Francisco, CA
*+1.415.594.5500 <+1.415.594.5500,,112807485#>*

United States - Washington, DC
*+1.202.602.1295 <+1.202.602.1295,,112807485#>*

Australia - Sydney
*+61.2.9191.6319 <+61.2.9191.6319,,112807485#>*

France - Paris
*+33.1.8288.3590 <+33.1.8288.3590,,112807485#>*

Germany - Berlin
*+49.30.2240.3071 <+49.30.2240.3071,,112807485#>*

Singapore - national
*+65.3158.1842 <+65.3158.1842,,112807485#>*

United Kingdom - London
*+44.20.3582.4515 <+44.20.3582.4515,,112807485#>*

More phone numbers 

Conference ID:
*112-807-485 #*

Need to share screen?  Download the app 
_____________
Roman Shpount

--089e082344200cab77055a1c4719
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

I have allocated the following bridge for the conference=
 call on Thursday, September 28, 2017 12:00 PM EDT.

I have tried to =
invite all participants who indicated interest in this call, but wanted to =
provide the conference call information on the list as well



=09



	=20
    
Join the meeting: joi=
n.me/112-807-485

		

		Thursday, September=
 28, 2017 12:00 PM 

		Eastern Time (US &a=
mp; Canada) 

		In my time zone?
	

			To dial in by phone:
						

					United States - Los Angeles, CA 

					+1.213.226.1066
				

							

					United States - New York, NY 

					+1.646.307.1990
				

							

					United States - San Francisco, CA 

					+1.415.594.5500
				

							

					United States - Washington, DC 

					+1.202.602.1295
				

							

					Australia - Sydney 

					+61.2.9191.6319
				

							

					France - Paris 

					+33.1.8288.3590
				

							

					Germany - Berlin 

					+49.30.2240.3071
				

							

					Singapore - national 

					+65.3158.1842
				

							

					United Kingdom - London 

					+44.20.3582.4515
				

						

				More phone numbers
			

				
=20
					Conference ID: 

			112-807-485 #
				

		

		Need to share screen?=C2=A0=C2=A0Download the app
	




_____________
Roma=
n Shpount



--089e082344200cab77055a1c4719--


From nobody Wed Sep 27 06:09:31 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38067134AFF for ; Wed, 27 Sep 2017 06:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 N8-m8kQywlj7 for ; Wed, 27 Sep 2017 06:09:28 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 81548134BAA for ; Wed, 27 Sep 2017 06:07:26 -0700 (PDT)
X-AuditID: c1b4fb2d-e302b9c0000019be-d7-59cba28c631a
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.81.06590.C82ABC95; Wed, 27 Sep 2017 15:07:24 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 15:07:23 +0200
From: Christer Holmberg 
To: Alan Johnston 
CC: Andy Hutton , "mmusic (E-mail)" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6K1yrGAgAA3NQCABt73gIAL+bYA
Date: Wed, 27 Sep 2017 13:07:23 +0000
Message-ID: 
References: <150540502703.12603.17962279219166496882@ietfa.amsl.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_D5F17E6422C14christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2J7lG7PotORBsf2GFnMbG1lsbi0biuT xdTlj1kcmD12zrrL7rFkyU+mAKYoLpuU1JzMstQifbsErox9Z6exFaxJqNjz+idzA2NzUBcj J4eEgInE7rd3WEFsIYEjjBJXP+p2MXIB2YsYJe59+AuU4OBgE7CQ6P6nDVIjIqArsXbVM3YQ m1kgSOLMjRnMILawQJjEqc3HmCBqwiVmvzvICmG7Sbz70w9WzyKgKnH06k02EJtXwFqi+/oV Noi9LUwSGx7Eg6ziFAiU2NZRAxJmFBCT+H5qDRPEKnGJW0/mM0GcLCCxZM95ZghbVOLl439g q0QF9CQ2nLjNDhFXlPj4ah8jRG+CxKc3PYwQawUlTs58wjKBUXQWkrGzkJTNQlIGETeQeH9u PjOErS2xbOFrKFtfYuOXs4wQtrXEqc5lTMhqFjByrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st 2cQIjMaDW37r7mBc/drxEKMAB6MSD2/l1NORQqyJZcWVuYcYJTiYlUR4w+cAhXhTEiurUovy 44tKc1KLDzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamA0OKtySq2TK+NFG0v79Qs/ /a7u29jlEdPGaGRbHiK6X8jTTffrng8bf7EUmeqsPR9fWjX7a+KbG3NNfr4Rrvs6Y4rj04il X59rNK95L3gqO7xIYo9vVcrOk+djHl6uamr58qgySv5d0+93QoZmh1l556kprfkl9+rod3uz I+6hM+cwfF/vYR6txFKckWioxVxUnAgAgMrNysICAAA=
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 13:09:30 -0000

--_000_D5F17E6422C14christerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Alan,

>I just submitted the -03 version of the sipbrandy osrtp draft which should=
 address your comments.
>
>     https://www.ietf.org/id/draft-ietf-sipbrandy-osrtp-03.txt
>
> If you have further comments, please send them to sipbrandy so the author=
s will see them!

I will take a look, and send any comments to SIPBRANDY. Seems like I mixed =
up the drafts =96 sorry for that.

Regards,

Christer


On Fri, Sep 15, 2017 at 9:19 AM, Christer Holmberg > wrote:
Hi,

I sent some initial comments on the Abstract of the individual draft way
back. I don=B9t think anyone ever replied, but it seems like my comments
have been addressed.

I do have some more comments, but they are mostly editorial so I can
provide them as WGLC comments.

Regards,

Christer







On 15/09/17 16:07, "mmusic on behalf of Andy Hutton"
 on behalf of andyh=
utton.ietf@gmail.com> wrote:

>The changes to this draft are editorial and address a previous comment
>from Colin Perkins that we needed to refer to RTP profiles by the full
>name.
>
>I am hoping we can now move this draft forward to WGLC and
>subsequently close the work in SIPBrandy as well.
>
>Regards
>Andy
>
>On Thu, Sep 14, 2017 at 5:03 PM,  > wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the Multiparty Multimedia Session Control
>>WG of the IETF.
>>
>>         Title           : Negotiating SRTP and RTCP Feedback using the
>>RTP/AVP Profile
>>         Authors         : Andrew Hutton
>>                           Roland Jesske
>>                           Alan Johnston
>>                           Gonzalo Salgueiro
>>                           Bernard Aboba
>>         Filename        :
>>draft-ietf-mmusic-opportunistic-negotiation-01.txt
>>         Pages           : 7
>>         Date            : 2017-09-14
>>
>> Abstract:
>>    This document describes how the use of the Secure Real-time transport
>>    protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio
>>    Video Profile) defined in [RFC3551].  Such a mechanism is used to
>>    provide a means for encrypted media to be used in environments where
>>    support for encryption is not known in advance, and not required.
>>    The same mechanism is also applied to negotiation of the Extended RTP
>>    Profile for Real-time Transport Control Protocol Based Feedback (RTP/
>>    AVPF) [RFC4585].
>>
>>
>> The IETF datatracker status page for this draft is:
>>
>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiat
>>ion/
>>
>> There are also htmlized versions available at:
>>
>>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-0
>>1
>>
>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-neg
>>otiation-01
>>
>> A diff from the previous version is available at:
>>
>>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-negot=
ia
>>tion-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/
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic

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


--_000_D5F17E6422C14christerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <6F98CBC8E8F49D4AA228B301002FB0C4@ericsson.com>
Content-Transfer-Encoding: quoted-printable







Hi Alan,














>I just submitted the -03 version of the sipbrandy osrtp draft whic=
h should address your comments.


>



>


> If you have further comments, please send them to sipbrandy so th=
e authors will see them!














I will take a look, and send any comments to SIPBRANDY. Seems like I m=
ixed up the drafts =96 sorry for that.







Regards,







Christer





















On Fri, Sep 15, 2017 at 9:19 AM, Christer Holmbe=
rg 
<chr=
ister.holmberg@ericsson.com> wrote:



Hi,



I sent some initial comments on the Abstract of the individual draft way
back. I don=B9t think anyone ever replied, but it seems like my comments
have been addressed.



I do have some more comments, but they are mostly editorial so I can

provide them as WGLC comments.



Regards,



Christer















On 15/09/17 16:07, "mmusic on behalf of Andy Hutton"

<mmusic-bounces@ietf.org =
on behalf of
andyhutton.ietf@gmail.com&=
gt; wrote:



>The changes to this draft are editorial and address a previous comment<=
br>
>from Colin Perkins that we needed to refer to RTP profiles by the full<=
br>
>name.

>

>I am hoping we can now move this draft forward to WGLC and

>subsequently close the work in SIPBrandy as well.

>

>Regards

>Andy

>

>On Thu, Sep 14, 2017 at 5:03 PM,  <internet-drafts@ietf.org> wrote:

>>

>> A New Internet-Draft is available from the on-line Internet-Drafts=


>>directories.

>> This draft is a work item of the Multiparty Multimedia Session Con=
trol

>>WG of the IETF.

>>

>>         Title        =
   : Negotiating SRTP and RTCP Feedback using the

>>RTP/AVP Profile

>>         Authors       =
;  : Andrew Hutton

>>                  &nbs=
p;        Roland Jesske

>>                  &nbs=
p;        Alan Johnston

>>                  &nbs=
p;        Gonzalo Salgueiro

>>                  &nbs=
p;        Bernard Aboba

>>         Filename      &nbs=
p; :

>>draft-ietf-mmusic-opportunistic-negotiation-01.txt

>>         Pages        =
   : 7

>>         Date        &=
nbsp;   : 2017-09-14

>>

>> Abstract:

>>    This document describes how the use of the Secure Rea=
l-time transport

>>    protocol (SRTP) [RFC3711]. can be negotiated using th=
e RTP/AVP (Audio

>>    Video Profile) defined in [RFC3551].  Such a mec=
hanism is used to

>>    provide a means for encrypted media to be used in env=
ironments where

>>    support for encryption is not known in advance, and n=
ot required.

>>    The same mechanism is also applied to negotiation of =
the Extended RTP

>>    Profile for Real-time Transport Control Protocol Base=
d Feedback (RTP/

>>    AVPF) [RFC4585].

>>

>>

>> The IETF datatracker status page for this draft is:

>>

>>https://datatracker=
.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiat

>>ion/

>>

>> There are also htmlized versions available at:

>>

>>https://tools.ietf.=
org/html/draft-ietf-mmusic-opportunistic-negotiation-0

>>1

>>

>>https://datatracker=
.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-neg

>>otiation-01

>>

>> A diff from the previous version is available at:

>>

>>https://www.ietf.=
org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-negotia
>>tion-01

>>

>>

>> Please note that it may take a couple of minutes from the time of<=
br>
>>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/

>>

>> _______________________________________________

>> mmusic mailing list

>> mmusic@ietf.org

>> 
https://www.ietf.org/mailman/listinfo/mmusic

>

>_______________________________________________

>mmusic mailing list

>mmusic@ietf.org

>https://www.ietf.org/mailman/listinfo/mmusic



_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic


















--_000_D5F17E6422C14christerholmbergericssoncom_--


From nobody Wed Sep 27 06:21:38 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6EE134B8F for ; Wed, 27 Sep 2017 06:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tWdeQcaJ4UKX for ; Wed, 27 Sep 2017 06:21:35 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 15D5D134BAE for ; Wed, 27 Sep 2017 06:19:30 -0700 (PDT)
X-AuditID: c1b4fb30-cbdff70000001911-e8-59cba561dc10
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F0.7A.06417.165ABC95; Wed, 27 Sep 2017 15:19:29 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 15:19:28 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUA
Date: Wed, 27 Sep 2017 13:19:28 +0000
Message-ID: 
References: <150540502703.12603.17962279219166496882@ietfa.amsl.com>
In-Reply-To: <150540502703.12603.17962279219166496882@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <317E79AC0CD1024D8928704E2ED966CE@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbE9RDdx6elIg6YN4hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtyPs1gLVohWfD/yj7WB8a5AFyMnh4SAicSVf+cZuxi5OIQE jjBK7PnwnBEkISSwiFHi852SLkYODjYBC4nuf9ogYREBdYmve3uYQWxhgTCJU5uPMUHEwyVm vzvIClIuImAkcX1zCUiYRUBV4uCuVrASXgFribsdK6Gmu0i833GPFcTmFHCV+LJ4KVicUUBM 4vupNWD1zALiEreezGeCOFNAYsme88wQtqjEy8f/wHpFBfQkNpy4zQ4RV5Rof9rACNGrJ3Fj 6hQ2CBto74fFUHFtiWULXzND3CMocXLmE5YJjGKzkKybhaR9FpL2WUjaZyFpX8DIuopRtDi1 OCk33chIL7UoM7m4OD9PLy+1ZBMjMH4ObvltsIPx5XPHQ4wCHIxKPLwrp56OFGJNLCuuzD3E KMHBrCTCGz4HKMSbklhZlVqUH19UmpNafIhRmoNFSZzXcd+FCCGB9MSS1OzU1ILUIpgsEwen VANjCGOtDufKiOXWKovT2EMf9Ew4fHLVBh2ZGE0PP9tlrlkrDnKavDq5ToTJK75nitU147vH GjdmHP74cKa5G7fq34lXZ1qvOz7f7dajriMTTkTPOvvKanstX7Gh5xvJPt3ry5Q6v504wDrj QT/XMs6iUOl2ZY871ywL65OCF7H4hDdwfNJeqZiuxFKckWioxVxUnAgAP2/Z0ZsCAAA=
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 13:21:37 -0000

Hi,

I am currently reviewing draft-ietf-sipbrandy-osrtp-03, and the following
question comes to my mind: do we really need
draft-ietf-mmusic-opportunistic-negotiation? :)

Section 3 of draft-ietf-sipbrandy-osrtp-03 already more or less contains
SDP Offer/Answer procedures for OSRTP. We can change the name of section 3
in that draft to =B3SDP Offer/Answer Procedures=B2, modify the structure a
little, and add whatever might be missing.

Or, am I missing something?

Regards,

Christer





On 14/09/17 19:03, "mmusic on behalf of internet-drafts@ietf.org"
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>This draft is a work item of the Multiparty Multimedia Session Control WG
>of the IETF.
>
>        Title           : Negotiating SRTP and RTCP Feedback using the
>RTP/AVP Profile
>        Authors         : Andrew Hutton
>                          Roland Jesske
>                          Alan Johnston
>                          Gonzalo Salgueiro
>                          Bernard Aboba
>	Filename        : draft-ietf-mmusic-opportunistic-negotiation-01.txt
>	Pages           : 7
>	Date            : 2017-09-14
>
>Abstract:
>   This document describes how the use of the Secure Real-time transport
>   protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio
>   Video Profile) defined in [RFC3551].  Such a mechanism is used to
>   provide a means for encrypted media to be used in environments where
>   support for encryption is not known in advance, and not required.
>   The same mechanism is also applied to negotiation of the Extended RTP
>   Profile for Real-time Transport Control Protocol Based Feedback (RTP/
>   AVPF) [RFC4585].
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiati
>on/
>
>There are also htmlized versions available at:
>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-01
>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-nego
>tiation-01
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-negoti=
at
>ion-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/
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www.ietf.org/mailman/listinfo/mmusic


From nobody Wed Sep 27 07:43:41 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6A7134CAD for ; Wed, 27 Sep 2017 07:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yqmcO5AwplhS for ; Wed, 27 Sep 2017 07:43:33 -0700 (PDT)
Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id A0E6C134E21 for ; Wed, 27 Sep 2017 07:34:47 -0700 (PDT)
X-AuditID: 12074412-1e5ff7000000748d-5a-59cbb705e015
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 63.A8.29837.507BBC95; Wed, 27 Sep 2017 10:34:45 -0400 (EDT)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v8REYihW030262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 27 Sep 2017 10:34:45 -0400
To: mmusic@ietf.org
References: <94b38e17-3fbe-2861-cc3a-55ef679a4e64@ericsson.com>  <29a6f779-383c-60d8-db97-c5c63bc7a5d4@ericsson.com>   <7594FB04B1934943A5C02806D1A2204B562F08F0@ESESSMB109.ericsson.se>  <90b9f317-d554-cbcd-9edf-78c9d379d205@cisco.com>  <364B50F3-8101-41E0-9693-511A99CDA9D7@vidyo.com> <7594FB04B1934943A5C02806D1A2204B562FDAB5@ESESSMB109.ericsson.se> <3667875B-3EEC-4745-BFFB-790B273DC458@vidyo.com> 
From: Paul Kyzivat 
Message-ID: <89b29a85-6f3c-9c9b-b64f-3327fb33381f@alum.mit.edu>
Date: Wed, 27 Sep 2017 10:34:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqMu6/XSkwcyt+hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxp1zr1gKvulWXDx5mKmBcaF8FyMnh4SAicSp8xdZuhi5OIQE djBJzLj0nRXC+c4ksfnhYaAMB4ewgLPEkbWRIA0iAsISM97+ZYOoaWGTOPVjPitIgk1AS2LO of8sIDavgL3Esk+rwOIsAqoSG3ZdYgOxRQXSJP7tPssIUSMocXLmE7B6TgFbiR1vb4DVMwuY Sczb/JAZwhaXuPVkPhOELS/RvHU28wRG/llI2mchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OK U5N1i5MT8/JSi3TN9HIzS/RSU0o3MULCUmgH4/qTcocYBTgYlXh4Lyw4HSnEmlhWXJl7iFGS g0lJlDdxDVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK/WeqAcb0piZVVqUT5MSpqDRUmc9+di dT8hgfTEktTs1NSC1CKYrAwHh5IEb8g2oEbBotT01Iq0zJwShDQTByfIcB6g4c4gNbzFBYm5 xZnpEPlTjLocPT03/jAJseTl56VKifMagxQJgBRllObBzYGlk1eM4kBvCfMuAaniAaYiuEmv gJYwAS3pnXoCZElJIkJKqoFxws7c3ufdQVUPGpc0tM1POZ/H03nm35c5Kxf+ati/eXmczp3o pRtFIqMm+aZcFNhW9sVEbfK/x0251s7NoW1bAitDros8T3o1qW2ugn/fAtcLBlJVLvkzWJk0 zryP3/lBXtj4VYnNtdwvf2NnuTusP61xavtfTRdn4xP/FJ8eTqqpE/Mtl7dSYinOSDTUYi4q TgQA2VdpngIDAAA=
Archived-At: 
Subject: Re: [MMUSIC] Existing missmatch between SDP mux and BUNDLE
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 14:43:40 -0000

On 9/26/17 2:16 PM, Flemming Andreasen wrote:
> 
> 
> On 9/26/17 1:49 PM, Jonathan Lennox wrote:
>>
>>> On Sep 26, 2017, at 1:13 PM, Christer Holmberg 
>>> >> > wrote:
>>>
>>> Hi,
>>> >I have one question, which actually makes a practical difference to 
>>> the on-the->wire SDP of BUNDLE.
>>> >
>>> >For a session- and media-level attribute which has the common pattern 
>>> that the>session-level value provides a default for the media level, 
>>> a non-overridden>session-level attribute is arguably “associated” 
>>> with a media description, but it>clearly isn’t “included” in it.
>>> >
>>> >Should this be permitted?
>>> Not sure I understand. Should what be permitted? :)
>>
>> If BUNDLE says that an attribute of this type “MUST be associated with 
>> a media description”, is it sufficient to have the attribute specified 
>> at the session level?
>>
> Yes - this is how SDP normally works and we shouldn't change that.

+1

	Thanks,
	Paul

> Thanks
> 
> -- Flemming (as individual)
> 
>>> Regards,
>>> Christer
>>>
>>>     On Sep 25, 2017, at 10:52 PM, Eric Rescorla >>     > wrote:
>>>     I am in favor of the changes that Taylor proposes.
>>>     -Ekr
>>>     On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen
>>>     > wrote:
>>>
>>>         I much prefer use of the term "media description" as well
>>>         since this is well-defined in 4566.
>>>
>>>         Having said that, I wholeheartedly agree with Christer's
>>>         point about terminology change - we need people to agree to
>>>         this before entertaining yet another update on this front.
>>>
>>>         So folks, please speak up and let us know if you are for,
>>>         against, or indifferent in terms of said terminology change.
>>>
>>>         Thanks
>>>
>>>         -- Flemming
>>>         On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
>>>
>>>             Right. I can only think of one possible interpretation of
>>>             "add attribute to media description". RFC4566 uses the
>>>             following phrases:
>>>
>>>               * "attributes ... may be added"
>>>               * "attribute ... in the media description"
>>>               * "attribute is present"
>>>               * "a media description may have any number of attributes"
>>>               * "attribute fields can ... be added"
>>>               * "specifying the attribute"
>>>               * "session description containing such attributes"
>>>               * "attribute MUST be included"
>>>
>>>             So, the following would be consistent with the defined
>>>             terminology:
>>>
>>>               * "The offerer MUST add the foo attribute to the media
>>>                 description."
>>>               * "The foo attribute MUST be
>>>                 [present|contained|specified|included] in the media
>>>                 description."
>>>               * "The media description MUST have the foo attribute."
>>>
>>>             But "foo attribute MUST be associated with the m-line"?
>>>             Not so much.
>>>             On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg
>>>             >>             > wrote:
>>>
>>>                 Hi,
>>>
>>>                 >> It depends on how we interpret "associated with"
>>>                 >
>>>                 > That's why I purged "associated with" from the
>>>                 BUNDLE
>>>                 spec:https://github.com/taylor-b/draft-sdp-bundle/pull/1
>>>                 >
>>>                 > It almost always can be interpreted in multiple
>>>                 ways. Unfortunately this never got integrated, I
>>>                 assume because I was too late.
>>>
>>>                 No, you were not :) I have been looking at your CR,
>>>                 and have been considering to integrate it, but I
>>>                 lately I have been so busy with draft-dtls-sdp etc.
>>>
>>>                 Having said that, we have changed the terminology in
>>>                 bundle a number of times already - we really need to
>>>                 stop at some point.
>>>
>>>                 The history of "associated" is when people commented
>>>                 that one cannot add an attribute, address etc to an
>>>                 m- line (because attributes, c- lines and m- lines
>>>                 are separate SDP properties). So, instead of talking
>>>                 about adding those to an m- line talk about
>>>                 associating those with an m- line.
>>>
>>>                 Now, if I remember the changes in your PR correctly,
>>>                 you are talking about "media descriptions", which
>>>                 would be an "envelope" containing the m- line, the
>>>                 address and attributes associated with that m- line.
>>>                 Then you could say "add attribute to the media
>>>                 description", etc. Right?
>>>
>>>                 Regards,
>>>
>>>                 Christer
>>>
>>>
>>>         _______________________________________________
>>>         mmusic mailing list
>>>         mmusic@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>     _______________________________________________
>>>     mmusic mailing list
>>>     mmusic@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 


From nobody Wed Sep 27 12:57:49 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EDE134FE1 for ; Wed, 27 Sep 2017 12:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fnxR_D0dvqh for ; Wed, 27 Sep 2017 12:57:46 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152B1134FE7 for ; Wed, 27 Sep 2017 12:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13148; q=dns/txt; s=iport; t=1506542265; x=1507751865; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7VbdYGOtY8pCVJJYJO03wcoZ0I7qzDatXMnXIFcXY5E=; b=hr/JIkQ0LgWptwQLX/2q8/DceOwDLCa8fldC7VS2TGO7ZtZCFoIKGN0G AV0P1GnHp91oSfWq+hkbhA3mqjw0kxZNkDK/OxUBcLncp9e/SvUQRUJ9d RLxVUDzkMUANPCuTPRGEWuCMsT3m1NYJek+gc/V+T6UY7o4s9ombaPf1G g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAgBqAsxZ/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1xkbicHg3GZfYFUkQ+HUAoYAQyER08CGoRCVwECAQEBAQECayi?= =?us-ascii?q?FGQIBAwEBIUsLEAIBCD8DAgICJQsUEQIEDgWJTWQQp2yCJ4sCAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYMrgWIggVGBaisLgnKDMoFpJ4JVL4IxBZE7j2gCh1yNAYI?= =?us-ascii?q?TW4UTiwWVHAIRGQGBOAFXQkx4FR8qEgGHCnaHRoEQAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,446,1500940800"; d="scan'208,217";a="9572451"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 19:57:41 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8RJvf01027642 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Sep 2017 19:57:41 GMT
Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 27 Sep 2017 14:57:40 -0500
Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1320.000; Wed, 27 Sep 2017 14:57:40 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: Christer Holmberg 
CC: "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUAgACwtIA=
Date: Wed, 27 Sep 2017 19:57:40 +0000
Message-ID: <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com>
References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.178.127]
Content-Type: multipart/alternative; boundary="_000_2833E3F5964640CD995E8A7F61DA77CAciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 19:57:48 -0000

--_000_2833E3F5964640CD995E8A7F61DA77CAciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ2hyaXN0ZXIgLQ0KDQpTZWUgdGhpczogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h
cmNoL21zZy9tbXVzaWMvd292MnlFcnJndFVaVVJ5UnlWdVZaNkstbkxJDQoNCkNoZWVycywNCg0K
LUcNCg0KT24gU2VwIDI3LCAyMDE3LCBhdCA5OjE5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy
aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj
c3Nvbi5jb20+PiB3cm90ZToNCg0KSGksDQoNCkkgYW0gY3VycmVudGx5IHJldmlld2luZyBkcmFm
dC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wMywgYW5kIHRoZSBmb2xsb3dpbmcNCnF1ZXN0aW9uIGNv
bWVzIHRvIG15IG1pbmQ6IGRvIHdlIHJlYWxseSBuZWVkDQpkcmFmdC1pZXRmLW1tdXNpYy1vcHBv
cnR1bmlzdGljLW5lZ290aWF0aW9uPyA6KQ0KDQpTZWN0aW9uIDMgb2YgZHJhZnQtaWV0Zi1zaXBi
cmFuZHktb3NydHAtMDMgYWxyZWFkeSBtb3JlIG9yIGxlc3MgY29udGFpbnMNClNEUCBPZmZlci9B
bnN3ZXIgcHJvY2VkdXJlcyBmb3IgT1NSVFAuIFdlIGNhbiBjaGFuZ2UgdGhlIG5hbWUgb2Ygc2Vj
dGlvbiAzDQppbiB0aGF0IGRyYWZ0IHRvIMKzU0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVzwrIs
IG1vZGlmeSB0aGUgc3RydWN0dXJlIGENCmxpdHRsZSwgYW5kIGFkZCB3aGF0ZXZlciBtaWdodCBi
ZSBtaXNzaW5nLg0KDQpPciwgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KUmVnYXJkcywNCg0K
Q2hyaXN0ZXINCg0KDQoNCg0KDQpPbiAxNC8wOS8xNyAxOTowMywgIm1tdXNpYyBvbiBiZWhhbGYg
b2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmc+Ig0KPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRm
Lm9yZz4gb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJu
ZXQtZHJhZnRzQGlldGYub3JnPj4gd3JvdGU6DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg
YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQpkaXJlY3Rvcmllcy4N
ClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE11bHRpcGFydHkgTXVsdGltZWRpYSBT
ZXNzaW9uIENvbnRyb2wgV0cNCm9mIHRoZSBJRVRGLg0KDQogICAgICBUaXRsZSAgICAgICAgICAg
OiBOZWdvdGlhdGluZyBTUlRQIGFuZCBSVENQIEZlZWRiYWNrIHVzaW5nIHRoZQ0KUlRQL0FWUCBQ
cm9maWxlDQogICAgICBBdXRob3JzICAgICAgICAgOiBBbmRyZXcgSHV0dG9uDQogICAgICAgICAg
ICAgICAgICAgICAgICBSb2xhbmQgSmVzc2tlDQogICAgICAgICAgICAgICAgICAgICAgICBBbGFu
IEpvaG5zdG9uDQogICAgICAgICAgICAgICAgICAgICAgICBHb256YWxvIFNhbGd1ZWlybw0KICAg
ICAgICAgICAgICAgICAgICAgICAgQmVybmFyZCBBYm9iYQ0KRmlsZW5hbWUgICAgICAgIDogZHJh
ZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMS50eHQNClBhZ2VzICAg
ICAgICAgICA6IDcNCkRhdGUgICAgICAgICAgICA6IDIwMTctMDktMTQNCg0KQWJzdHJhY3Q6DQog
VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRoZSB1c2Ugb2YgdGhlIFNlY3VyZSBSZWFsLXRp
bWUgdHJhbnNwb3J0DQogcHJvdG9jb2wgKFNSVFApIFtSRkMzNzExXS4gY2FuIGJlIG5lZ290aWF0
ZWQgdXNpbmcgdGhlIFJUUC9BVlAgKEF1ZGlvDQogVmlkZW8gUHJvZmlsZSkgZGVmaW5lZCBpbiBb
UkZDMzU1MV0uICBTdWNoIGEgbWVjaGFuaXNtIGlzIHVzZWQgdG8NCiBwcm92aWRlIGEgbWVhbnMg
Zm9yIGVuY3J5cHRlZCBtZWRpYSB0byBiZSB1c2VkIGluIGVudmlyb25tZW50cyB3aGVyZQ0KIHN1
cHBvcnQgZm9yIGVuY3J5cHRpb24gaXMgbm90IGtub3duIGluIGFkdmFuY2UsIGFuZCBub3QgcmVx
dWlyZWQuDQogVGhlIHNhbWUgbWVjaGFuaXNtIGlzIGFsc28gYXBwbGllZCB0byBuZWdvdGlhdGlv
biBvZiB0aGUgRXh0ZW5kZWQgUlRQDQogUHJvZmlsZSBmb3IgUmVhbC10aW1lIFRyYW5zcG9ydCBD
b250cm9sIFByb3RvY29sIEJhc2VkIEZlZWRiYWNrIChSVFAvDQogQVZQRikgW1JGQzQ1ODVdLg0K
DQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0
dW5pc3RpYy1uZWdvdGlhdGkNCm9uLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u
cyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t
bXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ28NCnRp
YXRpb24tMDENCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl
IGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2lj
LW9wcG9ydHVuaXN0aWMtbmVnb3RpYXQNCmlvbi0wMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg
bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQpzdWJtaXNzaW9u
DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv
b2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu
b255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1h
aWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL21tdXNpYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzpt
bXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t
dXNpYw0KDQo=

--_000_2833E3F5964640CD995E8A7F61DA77CAciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIENocmlzdGVyIC0mbmJzcDsNCjxkaXYgY2xh
c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNlZSB0aGlzOiZuYnNw
OzxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbW11c2ljL3dv
djJ5RXJyZ3RVWlVSeVJ5VnVWWjZLLW5MSSIgY2xhc3M9IiI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5p
ZXRmLm9yZy9hcmNoL21zZy9tbXVzaWMvd292MnlFcnJndFVaVVJ5UnlWdVZaNkstbkxJPC9hPg0K
PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2hlZXJz
LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9
IiI+LUc8YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9
ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMjcsIDIwMTcsIGF0IDk6MTkg
QU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl
cmdAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208
L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu
ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IaSw8YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpJIGFtIGN1cnJlbnRseSByZXZpZXdpbmcgZHJhZnQtaWV0Zi1zaXBicmFuZHkt
b3NydHAtMDMsIGFuZCB0aGUgZm9sbG93aW5nPGJyIGNsYXNzPSIiPg0KcXVlc3Rpb24gY29tZXMg
dG8gbXkgbWluZDogZG8gd2UgcmVhbGx5IG5lZWQ8YnIgY2xhc3M9IiI+DQpkcmFmdC1pZXRmLW1t
dXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9uPyA6KTxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NClNlY3Rpb24gMyBvZiBkcmFmdC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wMyBhbHJlYWR5
IG1vcmUgb3IgbGVzcyBjb250YWluczxiciBjbGFzcz0iIj4NClNEUCBPZmZlci9BbnN3ZXIgcHJv
Y2VkdXJlcyBmb3IgT1NSVFAuIFdlIGNhbiBjaGFuZ2UgdGhlIG5hbWUgb2Ygc2VjdGlvbiAzPGJy
IGNsYXNzPSIiPg0KaW4gdGhhdCBkcmFmdCB0byDCs1NEUCBPZmZlci9BbnN3ZXIgUHJvY2VkdXJl
c8KyLCBtb2RpZnkgdGhlIHN0cnVjdHVyZSBhPGJyIGNsYXNzPSIiPg0KbGl0dGxlLCBhbmQgYWRk
IHdoYXRldmVyIG1pZ2h0IGJlIG1pc3NpbmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
T3IsIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
UmVnYXJkcyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpDaHJpc3RlcjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDE0LzA5LzE3IDE5OjAzLCAmcXVvdDttbXVzaWMgb24g
YmVoYWxmIG9mIDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNz
PSIiPg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZxdW90OzxiciBjbGFzcz0iIj4NCiZs
dDs8YSBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm1tdXNp
Yy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzppbnRl
cm5ldC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwv
YT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlz
IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0czxiciBjbGFzcz0iIj4N
CmRpcmVjdG9yaWVzLjxiciBjbGFzcz0iIj4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg
dGhlIE11bHRpcGFydHkgTXVsdGltZWRpYSBTZXNzaW9uIENvbnRyb2wgV0c8YnIgY2xhc3M9IiI+
DQpvZiB0aGUgSUVURi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaXRsZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IE5lZ290aWF0aW5nIFNSVFAgYW5kIFJU
Q1AgRmVlZGJhY2sgdXNpbmcgdGhlPGJyIGNsYXNzPSIiPg0KUlRQL0FWUCBQcm9maWxlPGJyIGNs
YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXV0aG9ycyAmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEFuZHJldyBIdXR0
b248YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSb2xhbmQgSmVz
c2tlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QWxhbiBKb2hu
c3RvbjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0dvbnphbG8g
U2FsZ3VlaXJvPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QmVy
bmFyZCBBYm9iYTxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5
bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1u
ZWdvdGlhdGlvbi0wMS50eHQ8YnIgY2xhc3M9IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw
YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5QYWdlcyAmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDc8YnIgY2xhc3M9
IiI+DQo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi
Pjwvc3Bhbj5EYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxNy0wOS0xNDxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3Jp
YmVzIGhvdyB0aGUgdXNlIG9mIHRoZSBTZWN1cmUgUmVhbC10aW1lIHRyYW5zcG9ydDxiciBjbGFz
cz0iIj4NCiZuYnNwO3Byb3RvY29sIChTUlRQKSBbUkZDMzcxMV0uIGNhbiBiZSBuZWdvdGlhdGVk
IHVzaW5nIHRoZSBSVFAvQVZQIChBdWRpbzxiciBjbGFzcz0iIj4NCiZuYnNwO1ZpZGVvIFByb2Zp
bGUpIGRlZmluZWQgaW4gW1JGQzM1NTFdLiAmbmJzcDtTdWNoIGEgbWVjaGFuaXNtIGlzIHVzZWQg
dG88YnIgY2xhc3M9IiI+DQombmJzcDtwcm92aWRlIGEgbWVhbnMgZm9yIGVuY3J5cHRlZCBtZWRp
YSB0byBiZSB1c2VkIGluIGVudmlyb25tZW50cyB3aGVyZTxiciBjbGFzcz0iIj4NCiZuYnNwO3N1
cHBvcnQgZm9yIGVuY3J5cHRpb24gaXMgbm90IGtub3duIGluIGFkdmFuY2UsIGFuZCBub3QgcmVx
dWlyZWQuPGJyIGNsYXNzPSIiPg0KJm5ic3A7VGhlIHNhbWUgbWVjaGFuaXNtIGlzIGFsc28gYXBw
bGllZCB0byBuZWdvdGlhdGlvbiBvZiB0aGUgRXh0ZW5kZWQgUlRQPGJyIGNsYXNzPSIiPg0KJm5i
c3A7UHJvZmlsZSBmb3IgUmVhbC10aW1lIFRyYW5zcG9ydCBDb250cm9sIFByb3RvY29sIEJhc2Vk
IEZlZWRiYWNrIChSVFAvPGJyIGNsYXNzPSIiPg0KJm5ic3A7QVZQRikgW1JGQzQ1ODVdLjxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBJRVRGIGRhdGF0cmFj
a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9
Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLW9wcG9y
dHVuaXN0aWMtbmVnb3RpYXRpIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aTwvYT48YnIgY2xh
c3M9IiI+DQpvbi88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBhcmUgYWxzbyBo
dG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRp
b24tMDE8YnIgY2xhc3M9IiI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s
L2RyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnbzxiciBjbGFzcz0iIj4NCnRpYXRp
b24tMDE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlv
dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3Rp
YXQ8YnIgY2xhc3M9IiI+DQppb24tMDE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0
ZXMgZnJvbSB0aGUgdGltZSBvZjxiciBjbGFzcz0iIj4NCnN1Ym1pc3Npb248YnIgY2xhc3M9IiI+
DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv
b2xzLmlldGYub3JnLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkludGVybmV0LURyYWZ0
cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnIgY2xhc3M9IiI+DQpm
dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
IGNsYXNzPSIiPg0KbW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCm1tdXNpY0BpZXRm
Lm9yZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bW11c2ljPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpt
bXVzaWMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0Bp
ZXRmLm9yZyIgY2xhc3M9IiI+bW11c2ljQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_2833E3F5964640CD995E8A7F61DA77CAciscocom_--


From nobody Wed Sep 27 13:35:18 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEBA135052 for ; Wed, 27 Sep 2017 13:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XoFiQYUV7MdO for ; Wed, 27 Sep 2017 13:35:14 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 1934C13443E for ; Wed, 27 Sep 2017 13:35:13 -0700 (PDT)
X-AuditID: c1b4fb3a-617ff700000051a3-29-59cc0b80eb3e
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.F2.20899.08B0CC95; Wed, 27 Sep 2017 22:35:12 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Wed, 27 Sep 2017 22:35:08 +0200
From: Christer Holmberg 
To: "Gonzalo Salgueiro (gsalguei)" 
CC: "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUAgACwtID//7EEIA==
Date: Wed, 27 Sep 2017 20:35:07 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se>
References: <150540502703.12603.17962279219166496882@ietfa.amsl.com>  <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com>
In-Reply-To: <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com>
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_7594FB04B1934943A5C02806D1A2204B56302CF2ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7tG4D95lIg00N4hZzp/hZTF3+mMWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyujYdY6xYN5txoqDPa9ZGhh3XGXsYuTkkBAw kfg95zdLFyMXh5DAEUaJvycfs0I4ixglJt1dz9TFyMHBJmAh0f1PG6RBRMBcYs/vFjaQMLOA usTVxUEgYWGBMIltF1pYIErCJWa/O8gKUiIi4CRxakcOSJhFQFVievd9RpAwr4CvxPnDihCL VjJKHLnQyA5SwylgKzF33Wc2EJtRQEzi+6k1TCA2s4C4xK0n85kgThaQWLLnPDOELSrx8vE/ VghbSWLt4e0sEPX5ErvbNoPN4RUQlDg58wnLBEaRWUhGzUJSNgtJ2SywxzQl1u/ShyhRlJjS /ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwJg6uOW31Q7Gg88d DzEKcDAq8fCyfjodKcSaWFZcmXuIUYKDWUmE9zzzmUgh3pTEyqrUovz4otKc1OJDjNIcLEri vA77LkQICaQnlqRmp6YWpBbBZJk4OKUaGMu4nlh4Vh7gFJdjZElbdWPuY5eLm23NtklvWa8s 9Wbm++/aDKtPpciennEtoifs/t7bTv+SvmkdFEyYbTN1Xa/QsdbapoUr522ewnHe/ybjnqBn C6Us1G0+zmrriKtwzm1xCdR7Lih+++6plrCUcC/hwJUXihrvHg9WeNva/itC7A934JtXp5VY ijMSDbWYi4oTAYDA00ilAgAA
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 20:35:17 -0000

--_000_7594FB04B1934943A5C02806D1A2204B56302CF2ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkluIHRoZSBtYWlsIHlvdSByZWZlcmVuY2VkIHRoZSBmb2xsb3dpbmcgaXMgc2FpZDoN
Cg0K4oCcSSBzZWUgeW91ciBwb2ludCBidXQgQ3VycmVudGx5IFNJUEJSQU5EWSBpcyBjaGFydGVy
ZWQgdG8gcHJvZHVjZSBPcHBvcnR1bmlzdGljIFNSVFAgYXMgYSBCQ1AuIFRoZXJlIGlzIGFsc28g
YSBtaWxlc3RvbmUgdG8NCmluZm9ybSBNTVVTSUMgb3Igb3RoZXIgYXBwcm9wcmlhdGUgV0dzIG9m
IGFueSBjaGFuZ2VzIG5lZWRlZCB0byBzdXBwb3J0IE9wcG9ydHVuaXN0aWMgU1JUUCAoTm90IGV4
cGVjdGVkIHRvIGJlIHB1Ymxpc2hlZA0KYXMgYW4gUkZDKS4gIEkgdGhpbmsgU0lQQlJBTkRZIGlz
IGp1c3QgY2Fycnlpbmcgb3V0IHdoYXQgdGhleSBhcmUgY2hhcnRlcmVkIHRvIGRvLuKAnQ0KDQpC
dXQsIGRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24gZG9lc27igJl0
IHJlYWxseSBkZWZpbmUgYW55IHByb2NlZHVyZXMg4oCTIGl0IHJlZmVyZW5jZXMgdGhlIFNJUEJS
QU5EWSBkcmFmdCBmb3IgZXZlcnl0aGluZy4NCg0K4oCcW0ktRC5pZXRmLXNpcGJyYW5keS1vc3J0
cF0gZGVzY3JpYmVzIGhvdyBTZWN1cmUgUmVhbC10aW1lIHRyYW5zcG9ydA0KICAgICAgICAgICAg
ICBwcm90b2NvbCAoU1JUUCkgY2FuIGJlIG5lZ290aWF0ZWQgb3Bwb3J0dW5pc3RpY2FsbHku4oCd
DQoNCkJ1dCwgYXMgdGhlIFNJUEJSQU5EWSBpcyBvbmx5IEluZm9ybWF0aW9uYWwsIHdoZXJlIGFy
ZSB0aGUgbm9ybWF0aXZlIHByb2NlZHVyZXM/DQoNCuKAnFRoZSBleGFjdCBuZWdvdGlhdGlvbiBt
ZWNoYW5pc20gaXMgaG93ZXZlciBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LA0K
ICAgICAgICAgICAgICBhbiBleGFtcGxlIG1lY2hhbmlzbSBjYW4gYmUgZm91bmQgaW4gW0ktRC5p
ZXRmLXNpcGJyYW5keS1vc3J0cF0u4oCdDQoNCkhvdyBjYW4gbmVnb3RpYXRpb24gYmUgb3V0c2lk
ZSB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50LCB3aGVuIHRoZSB0aXRsZSBvZiB0aGUgZG9jdW1l
bnQgY29udGFpbnMg4oCcbmVnb3RpYXRpbmfigJ0/DQoNCkluIGFkZGl0aW9uLCB0aGUgdGV4dCBz
YXlzIHRoYXQgdGhlIHNpcGJyYW5keSBvbmx5IGNvbnRhaW5zIOKAnGFuIGV4YW1wbGUgbWVjaGFu
aXNt4oCdLg0KDQpJZiB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSB0aGlzIGRvY3VtZW50LCBJIHRoaW5r
IHdlIHNoYWxsIGluY2x1ZGUgbm9ybWF0aXZlIG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVzLiBUaGUg
ZHJhZnQgRE9FUyBjb250YWluIHNvbWUgbm9ybWF0aXZlIHByb2NlZHVyZXMsIGJ1dCBJIHRoaW5r
IHdlIHNoYWxsIGhhdmUgaXQgYWxsIGluIG9uZSBwbGFjZS4gT25lIHNoYWxsIG5vdCBoYXZlIHRv
IHJlYWQgYm90aCBkb2N1bWVudHMganVzdCB0byBmaWd1cmUgb3V0IHRoZSBvZmZlci9hbnN3ZXIg
cHJvY2VkdXJlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoNCkZyb206IEdv
bnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSkgW21haWx0bzpnc2FsZ3VlaUBjaXNjby5jb21dDQpT
ZW50OiAyNyBTZXB0ZW1iZXIgMjAxNyAyMTo1OA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp
c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0
OiBSZTogW01NVVNJQ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3Rp
Yy1uZWdvdGlhdGlvbi0wMS50eHQNCg0KSGkgQ2hyaXN0ZXIgLQ0KDQpTZWUgdGhpczogaHR0cHM6
Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9tbXVzaWMvd292MnlFcnJndFVaVVJ5UnlW
dVZaNkstbkxJDQoNCkNoZWVycywNCg0KLUcNCg0KDQpPbiBTZXAgMjcsIDIwMTcsIGF0IDk6MTkg
QU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFp
bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KSSBh
bSBjdXJyZW50bHkgcmV2aWV3aW5nIGRyYWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwLTAzLCBhbmQg
dGhlIGZvbGxvd2luZw0KcXVlc3Rpb24gY29tZXMgdG8gbXkgbWluZDogZG8gd2UgcmVhbGx5IG5l
ZWQNCmRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24/IDopDQoNClNl
Y3Rpb24gMyBvZiBkcmFmdC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wMyBhbHJlYWR5IG1vcmUgb3Ig
bGVzcyBjb250YWlucw0KU0RQIE9mZmVyL0Fuc3dlciBwcm9jZWR1cmVzIGZvciBPU1JUUC4gV2Ug
Y2FuIGNoYW5nZSB0aGUgbmFtZSBvZiBzZWN0aW9uIDMNCmluIHRoYXQgZHJhZnQgdG8gwrNTRFAg
T2ZmZXIvQW5zd2VyIFByb2NlZHVyZXPCsiwgbW9kaWZ5IHRoZSBzdHJ1Y3R1cmUgYQ0KbGl0dGxl
LCBhbmQgYWRkIHdoYXRldmVyIG1pZ2h0IGJlIG1pc3NpbmcuDQoNCk9yLCBhbSBJIG1pc3Npbmcg
c29tZXRoaW5nPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCk9uIDE0LzA5LzE3
IDE5OjAzLCAibW11c2ljIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFp
bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4iDQo8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8
bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0K
DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu
dGVybmV0LURyYWZ0cw0KZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m
IHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lvbiBDb250cm9sIFdHDQpvZiB0aGUgSUVU
Ri4NCg0KICAgICAgVGl0bGUgICAgICAgICAgIDogTmVnb3RpYXRpbmcgU1JUUCBhbmQgUlRDUCBG
ZWVkYmFjayB1c2luZyB0aGUNClJUUC9BVlAgUHJvZmlsZQ0KICAgICAgQXV0aG9ycyAgICAgICAg
IDogQW5kcmV3IEh1dHRvbg0KICAgICAgICAgICAgICAgICAgICAgICAgUm9sYW5kIEplc3NrZQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgQWxhbiBKb2huc3Rvbg0KICAgICAgICAgICAgICAgICAg
ICAgICAgR29uemFsbyBTYWxndWVpcm8NCiAgICAgICAgICAgICAgICAgICAgICAgIEJlcm5hcmQg
QWJvYmENCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMt
bmVnb3RpYXRpb24tMDEudHh0DQpQYWdlcyAgICAgICAgICAgOiA3DQpEYXRlICAgICAgICAgICAg
OiAyMDE3LTA5LTE0DQoNCkFic3RyYWN0Og0KIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0
aGUgdXNlIG9mIHRoZSBTZWN1cmUgUmVhbC10aW1lIHRyYW5zcG9ydA0KIHByb3RvY29sIChTUlRQ
KSBbUkZDMzcxMV0uIGNhbiBiZSBuZWdvdGlhdGVkIHVzaW5nIHRoZSBSVFAvQVZQIChBdWRpbw0K
IFZpZGVvIFByb2ZpbGUpIGRlZmluZWQgaW4gW1JGQzM1NTFdLiAgU3VjaCBhIG1lY2hhbmlzbSBp
cyB1c2VkIHRvDQogcHJvdmlkZSBhIG1lYW5zIGZvciBlbmNyeXB0ZWQgbWVkaWEgdG8gYmUgdXNl
ZCBpbiBlbnZpcm9ubWVudHMgd2hlcmUNCiBzdXBwb3J0IGZvciBlbmNyeXB0aW9uIGlzIG5vdCBr
bm93biBpbiBhZHZhbmNlLCBhbmQgbm90IHJlcXVpcmVkLg0KIFRoZSBzYW1lIG1lY2hhbmlzbSBp
cyBhbHNvIGFwcGxpZWQgdG8gbmVnb3RpYXRpb24gb2YgdGhlIEV4dGVuZGVkIFJUUA0KIFByb2Zp
bGUgZm9yIFJlYWwtdGltZSBUcmFuc3BvcnQgQ29udHJvbCBQcm90b2NvbCBCYXNlZCBGZWVkYmFj
ayAoUlRQLw0KIEFWUEYpIFtSRkM0NTg1XS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0
dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpDQpvbi8NCg0KVGhl
cmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRp
b24tMDENCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1t
bXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvDQp0aWF0aW9uLTAxDQoNCkEgZGlmZiBmcm9tIHRoZSBw
cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm
Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0DQppb24t
MDENCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg
ZnJvbSB0aGUgdGltZSBvZg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g
YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJh
ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxt
YWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9tbXVzaWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2lj
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMN
Cg0K

--_000_7594FB04B1934943A5C02806D1A2204B56302CF2ESESSMB109erics_
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
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFu
DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5
cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt
c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gdGhlIG1haWwgeW91IHJlZmVyZW5jZWQgdGhl
IGZvbGxvd2luZyBpcyBzYWlkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+4oCcSSBzZWUgeW91ciBwb2ludCBidXQgQ3VycmVudGx5IFNJUEJSQU5EWSBpcyBjaGFydGVy
ZWQgdG8gcHJvZHVjZSBPcHBvcnR1bmlzdGljIFNSVFAgYXMgYSBCQ1AuIFRoZXJlIGlzIGFsc28g
YSBtaWxlc3RvbmUgdG8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj5pbmZvcm0gTU1VU0lDIG9yIG90aGVyIGFwcHJvcHJpYXRlIFdHcyBvZiBhbnkgY2hhbmdl
cyBuZWVkZWQgdG8gc3VwcG9ydCBPcHBvcnR1bmlzdGljIFNSVFAgKE5vdCBleHBlY3RlZCB0byBi
ZSBwdWJsaXNoZWQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij5hcyBhbiBSRkMpLiZuYnNwOyBJIHRoaW5rIFNJUEJSQU5EWSBpcyBqdXN0IGNhcnJ5aW5nIG91
dCB3aGF0IHRoZXkgYXJlIGNoYXJ0ZXJlZCB0byBkby7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1dCwgZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1u
ZWdvdGlhdGlvbiBkb2VzbuKAmXQgcmVhbGx5IGRlZmluZSBhbnkgcHJvY2VkdXJlcyDigJMgaXQg
cmVmZXJlbmNlcyB0aGUgU0lQQlJBTkRZIGRyYWZ0IGZvciBldmVyeXRoaW5nLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MzYuMHB0Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
4oCcW0ktRC5pZXRmLXNpcGJyYW5keS1vc3J0cF0gZGVzY3JpYmVzIGhvdyBTZWN1cmUgUmVhbC10
aW1lIHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3RvY29sIChTUlRQKSBjYW4gYmUgbmVnb3RpYXRlZCBvcHBv
cnR1bmlzdGljYWxseS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PkJ1dCwgYXMgdGhlIFNJUEJSQU5EWSBpcyBvbmx5IEluZm9ybWF0aW9uYWwsIHdoZXJlIGFyZSB0
aGUgbm9ybWF0aXZlIHByb2NlZHVyZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igJxUaGUgZXhhY3QgbmVnb3RpYXRp
b24gbWVjaGFuaXNtIGlzIGhvd2V2ZXIgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu
dCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5i
c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBhbiBleGFtcGxlIG1lY2hhbmlzbSBjYW4gYmUgZm91bmQgaW4gW0ktRC5pZXRmLXNp
cGJyYW5keS1vc3J0cF0u4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6
RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij5Ib3cgY2FuIG5lZ290aWF0aW9uIGJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVu
dCwgd2hlbiB0aGUgdGl0bGUgb2YgdGhlIGRvY3VtZW50IGNvbnRhaW5zIOKAnG5lZ290aWF0aW5n
4oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gYWRkaXRpb24s
IHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgc2lwYnJhbmR5IG9ubHkgY29udGFpbnMg4oCcYW4gZXhh
bXBsZSBtZWNoYW5pc23igJ0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPklmIHdlIGFyZSBnb2luZyB0byBoYXZlIHRoaXMgZG9jdW1lbnQsIEkgdGhpbmsgd2Ugc2hh
bGwgaW5jbHVkZSBub3JtYXRpdmUgb2ZmZXIvYW5zd2VyIHByb2NlZHVyZXMuIFRoZSBkcmFmdCBE
T0VTIGNvbnRhaW4gc29tZSBub3JtYXRpdmUNCiBwcm9jZWR1cmVzLCBidXQgSSB0aGluayB3ZSBz
aGFsbCBoYXZlIGl0IGFsbCBpbiBvbmUgcGxhY2UuIE9uZSBzaGFsbCBub3QgaGF2ZSB0byByZWFk
IGJvdGggZG9jdW1lbnRzIGp1c3QgdG8gZmlndXJlIG91dCB0aGUgb2ZmZXIvYW5zd2VyIHByb2Nl
ZHVyZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz
b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBHb256YWxvIFNhbGd1ZWlybyAoZ3Nh
bGd1ZWkpIFttYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI3
IFNlcHRlbWJlciAyMDE3IDIxOjU4PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAm
bHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbW11
c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9u
OiBkcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9uLTAxLnR4dDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIENocmlzdGVyIC0m
bmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUg
dGhpczombmJzcDs8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn
L21tdXNpYy93b3YyeUVycmd0VVpVUnlSeVZ1Vlo2Sy1uTEkiPmh0dHBzOi8vbWFpbGFyY2hpdmUu
aWV0Zi5vcmcvYXJjaC9tc2cvbW11c2ljL3dvdjJ5RXJyZ3RVWlVSeVJ5VnVWWjZLLW5MSTwvYT4N
CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRzxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2VwIDI3LCAy
MDE3LCBhdCA5OjE5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo
cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5IaSw8YnI+DQo8YnI+DQpJIGFtIGN1cnJlbnRseSByZXZpZXdpbmcgZHJhZnQtaWV0
Zi1zaXBicmFuZHktb3NydHAtMDMsIGFuZCB0aGUgZm9sbG93aW5nPGJyPg0KcXVlc3Rpb24gY29t
ZXMgdG8gbXkgbWluZDogZG8gd2UgcmVhbGx5IG5lZWQ8YnI+DQpkcmFmdC1pZXRmLW1tdXNpYy1v
cHBvcnR1bmlzdGljLW5lZ290aWF0aW9uPyA6KTxicj4NCjxicj4NClNlY3Rpb24gMyBvZiBkcmFm
dC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wMyBhbHJlYWR5IG1vcmUgb3IgbGVzcyBjb250YWluczxi
cj4NClNEUCBPZmZlci9BbnN3ZXIgcHJvY2VkdXJlcyBmb3IgT1NSVFAuIFdlIGNhbiBjaGFuZ2Ug
dGhlIG5hbWUgb2Ygc2VjdGlvbiAzPGJyPg0KaW4gdGhhdCBkcmFmdCB0byDCs1NEUCBPZmZlci9B
bnN3ZXIgUHJvY2VkdXJlc8KyLCBtb2RpZnkgdGhlIHN0cnVjdHVyZSBhPGJyPg0KbGl0dGxlLCBh
bmQgYWRkIHdoYXRldmVyIG1pZ2h0IGJlIG1pc3NpbmcuPGJyPg0KPGJyPg0KT3IsIGFtIEkgbWlz
c2luZyBzb21ldGhpbmc/PGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxi
cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDE0LzA5LzE3IDE5OjAzLCAmcXVv
dDttbXVzaWMgb24gYmVoYWxmIG9mIDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmciPg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZxdW90Ozxicj4NCiZsdDs8YSBo
cmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1ib3VuY2VzQGlldGYu
b3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBIE5l
dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E
cmFmdHM8YnI+DQpkaXJlY3Rvcmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9m
IHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lvbiBDb250cm9sIFdHPGJyPg0Kb2YgdGhl
IElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGl0
bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7OiBOZWdvdGlhdGluZyBTUlRQIGFuZCBSVENQIEZlZWRiYWNrIHVzaW5nIHRoZTxicj4N
ClJUUC9BVlAgUHJvZmlsZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O0F1dGhvcnMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
OiBBbmRyZXcgSHV0dG9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Um9sYW5k
IEplc3NrZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FsYW4gSm9obnN0b248
YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtHb256YWxvIFNhbGd1ZWlybzxicj4N
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0Jlcm5hcmQgQWJvYmE8YnI+DQpGaWxlbmFt
ZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IGRyYWZ0LWlldGYt
bW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24tMDEudHh0PGJyPg0KUGFnZXMgJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiA3
PGJyPg0KRGF0ZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDs6IDIwMTctMDktMTQ8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+
DQombmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlIHVzZSBvZiB0aGUgU2VjdXJl
IFJlYWwtdGltZSB0cmFuc3BvcnQ8YnI+DQombmJzcDtwcm90b2NvbCAoU1JUUCkgW1JGQzM3MTFd
LiBjYW4gYmUgbmVnb3RpYXRlZCB1c2luZyB0aGUgUlRQL0FWUCAoQXVkaW88YnI+DQombmJzcDtW
aWRlbyBQcm9maWxlKSBkZWZpbmVkIGluIFtSRkMzNTUxXS4gJm5ic3A7U3VjaCBhIG1lY2hhbmlz
bSBpcyB1c2VkIHRvPGJyPg0KJm5ic3A7cHJvdmlkZSBhIG1lYW5zIGZvciBlbmNyeXB0ZWQgbWVk
aWEgdG8gYmUgdXNlZCBpbiBlbnZpcm9ubWVudHMgd2hlcmU8YnI+DQombmJzcDtzdXBwb3J0IGZv
ciBlbmNyeXB0aW9uIGlzIG5vdCBrbm93biBpbiBhZHZhbmNlLCBhbmQgbm90IHJlcXVpcmVkLjxi
cj4NCiZuYnNwO1RoZSBzYW1lIG1lY2hhbmlzbSBpcyBhbHNvIGFwcGxpZWQgdG8gbmVnb3RpYXRp
b24gb2YgdGhlIEV4dGVuZGVkIFJUUDxicj4NCiZuYnNwO1Byb2ZpbGUgZm9yIFJlYWwtdGltZSBU
cmFuc3BvcnQgQ29udHJvbCBQcm90b2NvbCBCYXNlZCBGZWVkYmFjayAoUlRQLzxicj4NCiZuYnNw
O0FWUEYpIFtSRkM0NTg1XS48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBz
dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290
aWF0aSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMt
b3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGk8L2E+PGJyPg0Kb24vPGJyPg0KPGJyPg0KVGhlcmUgYXJl
IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5l
Z290aWF0aW9uLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVz
aWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMTwvYT48YnI+DQo8YSBocmVmPSJodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVu
aXN0aWMtbmVnbyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p
ZXRmLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ288L2E+PGJyPg0KdGlhdGlvbi0wMTxicj4NCjxi
cj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1t
bXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm
Zj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXQ8L2E+PGJyPg0K
aW9uLTAxPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv
dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Y8YnI+DQpzdWJtaXNzaW9uPGJyPg0KdW50
aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p
ZXRmLm9yZy48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5
IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4N
Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v
cmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_7594FB04B1934943A5C02806D1A2204B56302CF2ESESSMB109erics_--


From nobody Wed Sep 27 22:37:56 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9591352CF for ; Wed, 27 Sep 2017 22:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.128
X-Spam-Level: 
X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w47cUvBirikb for ; Wed, 27 Sep 2017 22:37:53 -0700 (PDT)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B661E1344ED for ; Wed, 27 Sep 2017 22:37:53 -0700 (PDT)
Received: by mail-pg0-x234.google.com with SMTP id p5so344298pgn.7 for ; Wed, 27 Sep 2017 22:37:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=yWHoOIV89QRzImucU+kDenq8n/52giAjWMOWxt+tVZY=; b=HIM+Vbxcq2DaQiFwzNhvf7Z27YbZX9Wn/AGghw0/TieZUPTH2FjL4Q8/8AWP9b+Fmr S/HHr/g0OAPcMWzq11SEm1bkNqj6rfPlWOGIXQoNzC6PVm6i8y4K6+JUr4PJZjcwkkvz pZ4OMx1XdA2iCReW+TtL7wYi7qXuHKcbZ7HHZD0l7fy+dcQGZcskZlmiadkjyctf83gd 8co349SsDO4a2wRaPon2zW5gpjepmrUO46q+6btxzdyntr8Gg23fBk4O7KgNrIPf5NxU I8Js38J5XewtYkA0Sn7slZsrSRs3xxuSj8X311/pTgpXtJ0gqEU4Q+qoRcAQF39H1AGN w3TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yWHoOIV89QRzImucU+kDenq8n/52giAjWMOWxt+tVZY=; b=Nos+bJUoTq6RKhkDGIpWkQ9lOVAHbR3AWpBdVwv5vZLFkcEz+jne5TmJD7ME4XWwJ6 hrU2gHyoHOVhvxzQB7KV0sTyLc3d0rP5XeK5iUupJek2bsoKy2uPeTvnOyN/rhLWJV4V JhuKiu/CcooHWsqUnBdNHJOBx8LefjVIts99WfrmnaxfLl8jxCM+/WqIMsv2V2c7Qr0e oBoqtHc+SJNWMsD9uFvetMCWSNXt+evwkHv1F/0NVHH0it3Oy6bhcOcdf9/3u+GNGxpC yU6sAPux2BFuUgf49oWiFEoORvan4P0nZTX2MfCDSKSY+uWnxzjCiJF6MHBxQIEi8AZP dGCg==
X-Gm-Message-State: AHPjjUg37fmAhGN8I8eEVplaaW7huAzIDEWLxDl5kbTDy0Uzwe4rFHfD Pe1QyKwvPUz9cpLVfyEFb016c5tG
X-Received: by 10.98.189.26 with SMTP id a26mr3403640pff.260.1506577073027; Wed, 27 Sep 2017 22:37:53 -0700 (PDT)
Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com. [74.125.83.52]) by smtp.gmail.com with ESMTPSA id n2sm1020139pgq.30.2017.09.27.22.37.51 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 22:37:52 -0700 (PDT)
Received: by mail-pg0-f52.google.com with SMTP id k193so342362pgc.8 for ; Wed, 27 Sep 2017 22:37:51 -0700 (PDT)
X-Google-Smtp-Source: AOwi7QCpZvxSYXkP/Bg/M/AhJYFWFSoWg3xe5hiAq964YJhiVFccKeiAgPBWrhgZEPl4LJtO2zUXVPl1eyfrpdXUoIg=
X-Received: by 10.84.178.195 with SMTP id z61mr3174626plb.374.1506577071624; Wed, 27 Sep 2017 22:37:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.189.2 with HTTP; Wed, 27 Sep 2017 22:37:50 -0700 (PDT)
From: Roman Shpount 
Date: Thu, 28 Sep 2017 01:37:50 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg , Adam Roach ,  Ben Campbell , Bernard Aboba ,  Bo Burman , Eric Rescorla ,  lemming Andreasen , Jonathan Lennox ,  Justin Uberti , Paul Kyzivat ,  "mmusic@ietf.org" 
Content-Type: multipart/mixed; boundary="94eb2c11a66c2e8324055a394f73"
Archived-At: 
Subject: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 05:37:55 -0000

--94eb2c11a66c2e8324055a394f73
Content-Type: multipart/alternative; boundary="94eb2c11a66c2e8320055a394f71"

--94eb2c11a66c2e8320055a394f71
Content-Type: text/plain; charset="UTF-8"

Hi All,

Attached is the presentation for the call tomorrow (or later today)

Once again, conference call information:

*Join the meeting: join.me/112-807-485 *

Thursday, September 28, 2017 12:00 PM
Eastern Time (US & Canada)
In my time zone? 
*To dial in by phone:*

United States - Los Angeles, CA
*+1.213.226.1066 <+1.213.226.1066,,112807485#>*

United States - New York, NY
*+1.646.307.1990 <+1.646.307.1990,,112807485#>*

United States - San Francisco, CA
*+1.415.594.5500 <+1.415.594.5500,,112807485#>*

United States - Washington, DC
*+1.202.602.1295 <+1.202.602.1295,,112807485#>*

Australia - Sydney
*+61.2.9191.6319 <+61.2.9191.6319,,112807485#>*

France - Paris
*+33.1.8288.3590 <+33.1.8288.3590,,112807485#>*

Germany - Berlin
*+49.30.2240.3071 <+49.30.2240.3071,,112807485#>*

Singapore - national
*+65.3158.1842 <+65.3158.1842,,112807485#>*

United Kingdom - London
*+44.20.3582.4515 <+44.20.3582.4515,,112807485#>*

More phone numbers 

Conference ID:
*112-807-485 #*

Need to share screen?  Download the app 

Regards,

_____________
Roman Shpount

--94eb2c11a66c2e8320055a394f71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

Attached is the presentation fo=
r the call tomorrow (or later today)

Once again, c=
onference call information:
Join the meeting:=C2=A0join.me/112-807-485
=
Thursday, September 28, 2017 12:00 PM=C2=A0
Eastern Time (US & Canada)=C2=A0
In my time =
zone?
To dial in by phone:
United States - Los Angeles, CA<=
/span>=C2=A0
+1.213.2=
26.1066
United States - New York, NY=C2=
=A0
+1.646.307.1990
United States - San Francisco, CA=C2=A0+1.415.594.5500
United States - Washington, DC=C2=A0
<=
a href=3D"tel:+1.202.602.1295,,112807485#" target=3D"_blank" style=3D"color=
:rgb(69,140,225);text-decoration-line:none">+1.202.602.1295
Australia - Sydney=C2=A0
+61.2.9191.6319
France - =
Paris=C2=A0
+3=
3.1.8288.3590
Germany - Berlin=C2=A0
<=
b style=3D"font-family:tahoma,verdana,arial;font-size:14px;color:rgb(36,36,=
36)">+49.30.2240.3071
Singapore - national=C2=A0
+65.3158.1842
U=
nited Kingdom - London=C2=A0
+44.20.3582.4515
More phone numbers
Conference ID:=C2=
=A0
112-807-485 #
Need to share screen?=C2=A0=C2=A0Download the app
Regards,
__=
___________
R=
oman Shpount






--94eb2c11a66c2e8320055a394f71--

--94eb2c11a66c2e8324055a394f73
Content-Type: application/pdf; name="DTLS-SDP-call.pdf"
Content-Disposition: attachment; filename="DTLS-SDP-call.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_j840xp0r0

JVBERi0xLjcNCiWhs8XXDQoxIDAgb2JqDQo8PC9QYWdlcyAyIDAgUiAvVHlwZS9DYXRhbG9nPj4N
CmVuZG9iag0KMiAwIG9iag0KPDwvQ291bnQgOC9LaWRzWyA0IDAgUiAgMTQgMCBSICAyNCAwIFIg
IDI2IDAgUiAgMjggMCBSICAzMCAwIFIgIDMyIDAgUiAgNDEgMCBSIF0vVHlwZS9QYWdlcz4+DQpl
bmRvYmoNCjMgMCBvYmoNCjw8L0NyZWF0aW9uRGF0ZShEOjIwMTcwOTI4MDEyNzM3KS9DcmVhdG9y
KFBERml1bSkvUHJvZHVjZXIoUERGaXVtKT4+DQplbmRvYmoNCjQgMCBvYmoNCjw8L0NvbnRlbnRz
IDUgMCBSIC9NZWRpYUJveFsgMCAwIDk2MCA1NDBdL1BhcmVudCAyIDAgUiAvUmVzb3VyY2VzPDwv
Rm9udDw8L0YxIDYgMCBSIC9GMiAxMCAwIFIgPj4+Pi9UeXBlL1BhZ2U+Pg0KZW5kb2JqDQo1IDAg
b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQxND4+c3RyZWFtDQp4nK2UQU/cMBCF
7/4Vc7SR1sx47Ng50RZKpYpDSyL1UHFYICmLIOlms6I/v+MNi1iQKpXlEiv25H1+8+wsFQJaRCTn
MEJZIASPMDTqx4HqFMGvbQEWhByeV7QH6rtaqmmVPGMAfKXwqRaBLPJFkY0U4EEdnhIU8pXzULfK
QT0oLqJlcIktEtTX6qc+MVTq2kR9ZoKuzAXUX9Xn+t2APjlb+B3i7N0hAfElpDJltsb629toh6cO
GDOBPFkvPWO20U/ix/MOusYU+gGE4XR9VsHH1ao3M9ZXi7lJelz0HRjWl408YJU3MhoiPR82Q3Od
pxfG6xa6foQhFzRLmVznD1a55nmhaO3pwju0BA6TDY8mxpsG+tYQ6ta4oJvhaB/GNg/OeRdAkS2n
CXSeT1h/P9/PxBbgY7CYdgDVze9+LX3qJPNx30ZxiLb0QJwslZO+pBOzATNzuvsw5pY1d5LdesgJ
/rFXEnh//59gGzhm+GacNkBuazIlOdBJ4rKlezRJO/okC3IXEGa5MVymp1+KvD5xNtcGbv9RVona
X2I8+h8NCmVuZHN0cmVhbQ0KZW5kb2JqDQo2IDAgb2JqDQo8PC9CYXNlRm9udC9CQUxWV0UrQ2Fs
aWJyaS1MaWdodC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRmlyc3RDaGFyIDMyL0ZvbnREZXNj
cmlwdG9yIDcgMCBSIC9MYXN0Q2hhciAxMjEvU3VidHlwZS9UcnVlVHlwZS9UeXBlL0ZvbnQvV2lk
dGhzIDkgMCBSID4+DQplbmRvYmoNCjcgMCBvYmoNCjw8L0FzY2VudCA3NTAvQXZnV2lkdGggNTIw
L0NhcEhlaWdodCA3NTAvRGVzY2VudCAtMjUwL0ZsYWdzIDMyL0ZvbnRCQm94WyAtNTExIC0yNTAg
MTIwOCA3NTBdL0ZvbnRGaWxlMiA4IDAgUiAvRm9udE5hbWUvQkFMVldFK0NhbGlicmktTGlnaHQv
Rm9udFdlaWdodCAzMDAvSXRhbGljQW5nbGUgMC9NYXhXaWR0aCAxNzIwL1N0ZW1WIDUyL1R5cGUv
Rm9udERlc2NyaXB0b3IvWEhlaWdodCAyNTA+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9GaWx0ZXIv
RmxhdGVEZWNvZGUvTGVuZ3RoIDg3NzkvTGVuZ3RoMSAxODYyMD4+c3RyZWFtDQp4nO18CXQbx5Vg
VXU3GvcNkABINkCA4AGS4H2JJCAe4E3xgkyKpnhIog6LInVRhyVbVmwdtBzLsR07jq9EtJ2Jnh1A
jh2Zjmc8lJIozkjO5mmcTSbWep3sziSzHCeTeHcimeT+agAUKVG+Ju9t3lt3sdG/fv06/lG//m9A
QhghpEKHEIPaVnV680aYR78JmF/BPbBuZHAsife/jxAuh/p768Z32QtO565HiCQA7ofDYxtHxj68
9yBCzG8QkpzbuHXfsP2drHMIyb+FkFC+acPgepxy9E8IpUM7KtoECFWvrAWhDOiPXJtGdu39H3/M
3Qd1P0I66dbRdYOPnDr3FkIr6hGSHhkZ3DvGM1I1QtU/BXr7tsGRDY6Bsq9A/fcw/7fHRnfumptD
mxCqfZK2j+3YMHbwy53/AfXvwxpnEcOm40zEISn3NS4feiRFnsxP0RGCpIhoGEIIyxD2WUQ+8CP7
nSh6tXTa7XREu1aC5hA+zz9N3HaEn6FtzBlOTdsQC58Y5EYlqITaZcqTiGfhMwuVoQrkQzWoGbWh
LnQb2ox2oz1oH3oWvWjXzs+LY8SoVopUnUA1iO5YTDX/a6aWSWRZBuac/3fEQ69EugrciFvn15Ef
/HpInD92WcXPBPHORIsvFumQHsWjtWg9JliDtdiKk3AabsNrcB/eikfxbjyOD+Lj+H58Ap/ET+BX
+Ke5Eebs3MO0O6ee/SX6PFcdzDiOTqEOtPNz9Y9e3DhSMGEkQQaQw9X5mbnn4T4LmriOEdfJJgJG
F+kzL5v/N6AwiDiNSPUHSjV3lqlCErGvYvZHgP0Q2lIYGdRV80VQ/yM5SuFID/7pue/MvSC2Kthi
/HWQQydojWqsC3gLon7Q2F1QbwR4CO2HZy/aCro+jKpRE1oN7cNoBGRwN3oS5PAm+hn0DELPjWgM
NH0XOopOosfQafRj1IfWA+UudCeaQN9Ab4Blb4fxvoROoMehvS86zovwHAMLOYSOo4fQE9BSD210
xlVAvxfGmEBbYLaT0G8P0CK/f0N3sKuzo71tVWtLc1NjQ31doLamumql31dZUb6irLSkuKjQm52V
meZOcTmThXijTqtRKeQyKS/hYHtglFnrDAzYQ+6BEOt21tdn0bpzEBCDixADITugAktpQvYBkcy+
lNIPlMM3UPojlP4FSqy1l6PyrEx7rdMeuljjtJ/Fa9q7AX6gxtljD82IcIsIs26xooKKwwE97LXx
m2rsITxgrw0FxjdN1A7UwHhhhbzaWb1BnpWJwnIFgAqAQmnOsTBOq8QiQNJqy8LgHFR02hCTUju4
PtTW3l1bY3M4ekQcqhbHCkmqQ7w4ln0zXTO63x7OfHPixFktGhrwKNc71w/e3h1iBqHTBFM7MXE0
pPOE0p01ofT9v4kHljeEMp01tSGPEwZr6liYAIe4FK3TPvEhgsU7Z/7XUsxgFCNJ0X6IKEhZXBAT
tMdgBGuDFQJ/Dgddy/1n/WgIKqFD7d2Ruh0N2c4gv9fTEyIDtOXNWIspSFsOxVoWug84HVRVtQPR
v/FN8aFDQ/asTJC++JcCf9BuDzHugaF1m+hzcMOEs6YmIreu7pC/BgD/YJTX2nCOF+gHB4CJzVQM
7d0hr3MsZHRWRQgAYac62NzZLXaJdgsZq0NwOkV7hby1NXRd9tqJgZrIAulYzvbu11D+/HvhArvt
5XxUgHroOkLmalCKu3aie/1wSBiwrQf7HLZ32xwhfw+Ir8fZvaGHasmpDaW/B9M5xBnFXsDbDdQx
Yso5nyK1dxMb00O1BQh7AD6cVeXQoAV1iVWq0apyeze2oRgZzBKloNCScaDCpFTX0yaGdq2utzl6
HJHrY5Zki66JSwlJF42lBcTCmiLz3HJpEWq6oHR77YaaRQtcMigXXWB0tOXXSagsohNDDylVZ32s
iUmBnQs4AsOIKKrFeHsItdm7nRucPU6wIX9bN+WNylrUb1Ons6l9Tbeo7aiVdC2pRdpLFtqiUIhU
gwEGPLaYTsV6nVhfqNbf0NwQa7ZPSJ1NnRN0ZGd0QGSH7QMcS9wNg/eX6AtgXwbAtTkDg0671h6Y
GDw7f2hoIuz3T4zVDmwqo2M4G9ZPODu7y23i0jq6D9r206n0qAk3dVVlZYLjqQo78bH2sB8f61zT
/ZoWYoRjXd1nCCbVA1U9YRe0db9mB5cuYgnFUiSt2GmFjtQBFalIb3vNj9AhsZUVEWJ93VmMRJw0
hsNo3VkSwWljOAI4NoLzizh6gYbiN4F8wdfW2tdT3Rzo2TQx0EN3FjKDHuEPh7CzEoWIszKMiUQZ
kjs3VIUUziqK91G8L4KXUDwPVoHNGKRZu8kZk5WzdtPghjMIY5PBWRLGSFeUReOXbIi9LsKpzUAU
VIpaUKPflcWTsjM16hfjaqAQbH9JymIiSDHjLJQw7RZdg4/FyPvulXevXPTBrdOXlmLvu+9emaGQ
16udgfLupZxcrHPoxNuoJjxvlDiTs0lhakFRfn5eJSkscDuT1UTEFRQVVzL5eUmEMcYwlUSsX/xo
kOn86H+Te1wruws4s0mulnOs1WTMXZmm6x5K9eXYeYbnGE7KpxVXO2qHq5Pfk6jjdPp4jUSiidfr
4tQQkVz9d059rYQ9fO0uxly+1u/E35byhOXYC3EmW7bf1Xa7zqRjZBql0iDlDXqVu2rN7IHYCNEn
BL4obf4qu4YzomTkRqdfdjux8+z87/0Kpbaec2LpeDJOPjv/H/5WpaZ+bzx2K+ROebLTqUxxqVyq
c2a/udi0x0RMLrv8HMYlZC+YWbzg6ncRl8vpTnlNqVAmxyc65SozZpVOKPrEDn2QCyKfzydKVRdX
SsWry9fO5OnyscXbl3++Ly9eO2O1aC/25VkB0h48ev48zgcSeIL4+zx9a+FOMUeEmso4GDVDoWIc
EXcc72QcbJcEq2wmk0XNMwdmL+whUrXFYEpQYQn+AaM02HR6m0HBdOE/4Q/SNQY5w0jkPO6Z+xte
zrOsXK9h35YqJIBVSEdmIcFgIMKCzAUsKgl5UAkq8Se686cVwjmrwmRSoHOZCmvqVG4u75rSthdM
8V3IN+Ob0Zd6Z8CGfjWjK/XqS8F+8mD5RjXrdCS7C3VgMQ5YrYmaURLDFGQTp1NHbcgQAR0AMr+x
5dX3bgnMhfVutx6bt5/ozTJl+DwFt9emvZNQMdTx1pWGNWUJXemrdq3+LbZW9jd48JbSobZKj9nm
Yk+6bNnBfY3ZXfVlRnlx1ygx5neusM/lpFbdNvu2f6gqeY4XKnphR98x/0dWydlgp6T6jQnIc05d
Fv+6wz1l6GSnCnNel61GvtnLM/TG2iszl0ELKUa1ZJFJS0xRE6fGbzImEcoH1QWrJCxv8A/e1bz/
h/c3tT30kzvLRm5vsPEsYUDS6vzOvZ29j49UlGx5cl37vtXFGomUY0IKvVpp8GQkBSd//8TT177T
Z07OtCk1BqXapJGm56U3fPmnR++5cLweQE5lpjYMumF3gW70SEAJfrXhHLJOy+Kn1O22KS6iCuyd
uTwjSh9Eu0j6/HWxs7s6nv3XU/OioLXP/fprrV8q3fPqAz+6cO/39leQJ079+VurIyJd89w/P7L9
70+suvYPK4+9TbM6ahkB2EFWZPbLTdNIpukwTUnEebH34owoLBLVeUQqJh2dmwmwUqV09m29W6KO
1+lhU+MPAMGWqI0aHuZ6XSKXsCx8XNvNq0win/NXmeeBzwSUjtx+g0syrUs8h3QpUxKJ0jllalfS
jSWaHfZeXrA3ymDMA0X5ZhfxzTxfsWNy17fAweh18WoJcM+nNq7bWJ96T1X/xuyzoeCO1nTm62u+
urV8ThdbEfu6y8bH+Xp3t3ftLtXMXvI030El0Tz/AdPMCagBdfg9K6ddea48pe0cUjY6beXZrxfL
p3T2YlysK9aZy6cazCtX2rj0TvMUt5qKinoB2CQ66hX6qLOFGljb5RnRT8R0l5zNxrxoxN1mS25h
ghKmuXLsid7KbatXmOUsr5Co89u3N1UMN6YXBLdu3xosKBo63pHe1bTCwIExSmQSRVbN2vIV3WWJ
BatHto+sLsBrVx/rz4uzO+KEOJ1ZzTnTnY7K3rLy1SsLCys7x1qa9nRmai2CQaY2qFVgmYmuRHtx
Y3r56qrCworOUSoPHeiLnkLJyOpXIsl0vE6in0qMqikPe8/PXozy5biuIUdsW4k2chFshJ+7i1oI
1c7cXVKFlGXhg7mLB1th31EZVfy1nQuKeYAHhNqk5nm1CVZQN39Vch5ssxy1+t1euRKV5+Qo86bL
lXHxqhTw48nT8crijoyOHKeCWeyb40p9PvDGl+NB/BZvaam+VBuF9QCXgk1HfG4qduIY5C4oKhL9
L86PeeIFiOfaGZXJptcnmFTM3CUy9y9EYbAZjIlmqD7EqWxms1XNEVyLsYdINDazzqTiCQ4QXEE4
dbzJbFVh1hxzyWzqtV8swG9r9RH3fe0hdpSXS5bA1JXTnbMJLNPBTKN85EeDrzxW8kIJyaXnXKFc
VZ9mKDEQucFqIFJNPNRlcQVhlJoqgPjKzuhWZjyf7EyczC48ZTZnN1ZMKlvYZqo+H+wy7eyfRI94
vq8U4oM8EItnbR89m4wS8I5ud2Gh5LqXzC8siBhnFMOKnoCPmKs5P6+omHGoTLAHVRUPr6rb3ppR
uePZoZPxRasrywfqvXJgipFY/J0DOX2HViXvea5+a71z3Zq6O2uNcgXHKeQbqupTaocqmkYbU1rL
esqTwBxZhU5psliSE/VZXXe2vmbNC2S19jU0U3m8APJ4g9uBMlAFWuXP37fi+AqyL/t4NuHSTGlk
kwxzjIkhUrmjKGzynEEmeVGhg+VyJt2NtoC2uXSSa6F7ljqbuNKorwHugXm4ohuVpJque52Y34ta
Q1QSvM5sFl3QG3nrHlqbUVdTly4B56cxqTiOxjtxKomntbEhdej+29IOxpcN1Dtr61s8Tfc31Q5V
JuDf7HrtcEDnLkvfHdM6V0OlBCeLZPYnWRUp2ubDL+1u/vK2amN2Q9HceO9g9dZjoNT1wLsAtlCI
NvhrhjPGM45kMMMp4ylHUhiF1qYljyu+pSAKhU0hvrmUotQz6iJmMtcyKeTk+nOJT1glkFwhV8h0
TRoaM5+TiaKIOi7Rc4kmsbYPvK8oj5vPSknET0kWn5SMACeltaK527v2oaF837aHu7I6aossMo7o
5Op0f6/v8APuumF/+e01WQrwVswTSoNaYU1LMvjufHn3vd/fW6pLcFlUWoMqMc7lcV14o//Bfq87
281rxJPjDuD5Hm4EYrxStMevLE4zmlHzeN6RPJIF2+BlM2rJomFeuQm1jGceySRpWhMQbLRimcli
IjKtRUukCltpWF2QEc8i7xlDmSOgKE21seqMyfjGgkl1CxfZFdQgfGKUEFe6YBOePg/8pcTMYfGu
yDPHLVgH43Yvjh+KYcUqo0YLnqD+id6hidvS8oZO9nccq4rZxp6m+5upJVDLcNXUt2QaY4ZwuLWn
+fB3hnaCgTTUEUfMO8629g5UbT0WaPryqGgTMc9wHKzBA2n/Ov/K8dwjuWRvNn4s/YV08tW059OI
zGlxEplgEYh0mB/nicHgyDyDPNhTwJ5xFGaeYtkEL+yL+El1smwyAYwBnEL0EAYx5L3bR2Ewhcjm
gN0hcToW6d201DqIKbVIlALPHHfrZx9zNO/v8a1voPtfwsA5JS/oGvVv/ua20hXbvt4/fLLPcycz
cW/Nxjo3Q3iXrevYYIHZZpaA2HiVQi63WIy+O1/du/PVu6trdj7epTj5zfyu0XLYA575q+QAtxfO
BZ8/Nd8uVdabtVpkRzkQ6drCOZoMnOFLwSnyyaI6q3syp8HerG2gB8NMHo2l+s735c/CDYGgBy8+
dk0RjiSLIw4abkX9n8ghSw4wHM9JzY6spIwyl+YKL5eyWtUViQqOuDg1d0ytgeOaP5Zcu6k22e9Q
8AwnqHVyVq6U21b0Vd0hURlUFstHP4oplSm1WAAl2dh/pMut0ii0JuCheu5h5gBotRK1on405T+Y
XlhaSJS5CbnEk7Mih3jtkOAoPQkeIi1Na0gjJc56J7E6M5wkLjE1kRRZAhZisqTAhyxFRvShrLpw
vu8MvypsYzU5TD6flc/bbHx+FkuP+e5wRsqAJodnShonlZ2TJtNACTNZ3pBhr5osaeydtK+KZgM+
GtN4Z94Rnab2Sh6cG3HgNCALAoSYX0KJOo0+McmJmIvTbI64UneqBHyGOS4uiTEtyimL4aSBZNPt
ju0oR56ZKXAvnCw0pXCnwokdrTEH9OoHMxy5aw40VWwTjNaGsg8rRzpycjc+O7rl0X6P1pFrz8/J
SU605/UcaEytTcQKnea/bd9U2FZg3T5c1F5g7b9jzdyfXdk2+aP3dW0PJDF3J5g9G0pa9nZmJluM
BcnuAiInSStWl5Vv68xNWdmd76wsKbBZGzMq+93uNb7mfV1ZMt46968bd7kqO7LX73RVtM+uqwow
soQ8b1ZcY7OjKEDF+gJET/fBGZWHKvxut7fIG/AyyKv1EmmdBwf0WBHOyzCGkzIs2smsRlfA0iy6
IDEAhnA/77IoyrWi/40dQ6LX5XU3n0uRyMXE3CdRRXyLtaC9qHaiGao03V44jhofaezZ3+QwxoyP
WLo2N6UP9c/uiWEWn0EdLeXDxwaol3lk/irOgcjYhBzI5leZX0kwheXC31i0DeKir8QSlJSblmag
pwXVLygWJ924Hn1yVqaD3gsrYo7H5se5OckO0KMjKssekGUBqvOnm3Nx7nvJyrDZ+Yo1C2dlmeXf
tQCNOS4ZxylwsoJLa0gI6GLihHAPzNB7WfRjfRDz5P0mJxctSDUVLyPOaNQHnoDH2GxmeiB+NRit
sEvnum9kAR+U6oxWnc6ilSo1c1/FX1HJzTQLp36ckNm5mwX70Zv4Hhn4BSKR8XKDZu7bc3aNNmox
OAm4NCHtqygs1wZEFrB3WcHeLEzjzVNFR+XC4Eva4ORsq2vB7paiFoJatC2EqzXVktSa4hoiqTHX
gF36cJE74CZgnAFDOCkpTx4W2la1EdSG2ypTw3nayaZG1+TKxspAVklDVrNlkYijSWrp5b4++rpg
plT0A9Ez4+Ms+FYmbYoG41FNcOGIZau5uNymfN89LbRKmY8Xq4sM3aTTmZVc64na0p6aHI23symQ
HNxdJ1w3+Sz/DSZ/M+a6ER66rdWWW5NeUOcxwF5oXtjXIM88tNKfzuQYcojU7KX7mynSB/QkAySn
CPuAMIlu7AyLqyEmKOpCRUvURuSz9tPsbdMn7+0oy1/9pL29hC1xaxMxmrwA3BhQKrrd79+csi+F
DDvGHWTYNm4jm+P2xZGjevyYDkt0R3REqsLHpFjGH+fhgMdS4xn6QjXpjDzNMqlpdD4XCasjb1n6
ZmIBdd+SsDoWKMSC6Fi4xFwoGX1+25Zn7igsHn1+dMszW4ruSgqMd7ePN7liT/z+1lePNFUfPDO2
9dX7GqsOntnfcuIOX9nGE+2tD2ypLBs+QTMDODnfAH5oZtDgz968Yt8K0r0Cb87eR5MDyAuwo0h+
U1LQoF11q6RgaU6wjH5ulRPkr/vK2rRAdXXKgqIgzdZAuJTR3NyWBfFg6sH40v56V219q6fpeFPt
uspE/D93TR2u07mK3HNZMVWxv49FhV/y+DKMTYdf3N38wLaqhZxg5DiNj4Hre6JcQz40XnSkiIzn
HMkhw0lYEWeLI0p9gp5IBYUnnJF/xlSZ0qCo8AisNnvS2lgyqW3hVt0Q/S6TDxXqIplyTIFxCyEf
f1PgG9usmWL6Ew19M+pqA+m8yqTVGFXcTcHv3IsLjv/9rEqa/EQCYF3KiusZ0keRADiWFEV2I3lK
zIxT/Aa3JtwPOKv8OU+jW2OyN5jovhPdE/ae76O7bnG8t9xuE7UpIU8RjpfI4u3uOFtBqc99415L
rSovTVIlpwpKlsHMKGR8vEwui8vvqph98ubd9mBpIFXNSBUyXmGgHiQ4/wF5HdbcgIb9lUfrH6sn
VjdWuLGJYJbglSGXKy9PaQtTUmVj9mSx/DndQPFYMWnTRd8+TdJXT43mqMUCfzekb5HDLs87s9R8
P/W7J/J6Ts+BJm9Xjdcsp6woMny3lWY3lwhpKztv61yZ5mra3ZZcXZxm4hnx3ZPUXlDv9dZlx6VV
dd3WVQXbbOXGercmzmpMsqiMaj7BkWBM82VklHkczozyrhXe3vpMhd6kVSh1SsgDebPVbE4rsmeW
ZyYnp5e1U8ZT5/9AetlvozIU9JfItSptvUe+Qt4kZ1TyRDlxZoXjkEqrIiqVLj0daXSCzqdbpWOl
uqxJZ0OiajKuIXeSj3iji1T5a/vO53lpAJA/I+a1NJtjlw/wl6YB5liiQ3p5TaI7w1i9ttx2VK1l
pQr+aOzkvcorpKxOdXVFa3xqkknKSTmm0WTVqGScq2GsmeRHIvwrMXu4EskBZt/duBWyAlahA35P
0QyX+R6cKpDRyHVWHUnXlmqJmNFLFanigSKEDVkNqQrO0uC6nrFS66bRl2jdaxeftrE89XpcI27Q
ouLrGes9nNqs1dPD41Hx8IgxJB4xx1s4+lJ1cWRBz42NxwaIcyFI/JeuLfSQIQvGDuv0QcTRDbzU
oq/4e0u1kKpYSzNKiYdqMc2DLR5cn4CLErBbj+vVOF2NS1mckKjPzszUZoQTtSVqXAICZsrKtOWh
MdhfXm2/lti0WLuyIb+hLFPLxKU0xDXLmhe/6uvru9y36A1fn3bRu7+FnIRm8pgGddF3fkwqzyy8
/nMvODZDXLEh+gbwOggcia/99IlGU5JBQX5GyHmiBNCYYJCTud+BfwJZmqwqCfmAkF8QnroMs1pC
fkfwvxFebTFqjeAtnuFU0o8elMLxLAaIb0mls0WxGrOdV3O8nBMrH/2O5xnzguNbqEHUSPdHOnj8
tSBjF+r252227LMQfMYuwzKZGlltYb/Lapdb48941XeriVpj7bcSqVVosMgNDfImdhVqisZtVHJr
o5KzWrTvWikgxskgMwcTMaBig9t9w+tRmqaZjRAE3MXZnfp4FeEOSZVk7nucwmIyWzUQG9hYbOZ0
CUaDRcnNvajQ0Jd5eCWj5pmdkA1HeWLMahnDynUqmmM8OP9npp3rhhi/HlX6hcJXfVxY44OSbg2j
dJdLkBlPcVyOrKasWZjMQd4Z37uXaKhJk1J6XC98zRlx8jwT/W6TETd3xOPd9ALzxqiEaS/oO7xK
Ei9ozCoJJ9NZdNb69RW25NrN9RV9NR45ZPYsZ1zRMZS/4eEB79wUb3RYrA4jD0+rBZ7Me2vuHyhg
5j5UqcSjLJN+VZnVtL64cmNTus1hozGA3mSwJxjKho9/lJGQYpbJzCkJCW6TTGZygxTemv8z3s0c
FeOxeL8cGV+VJzkhgNQg70XfRezNX/hWZNGqdTfU8W66Hqudrstuja1vcZ1x2yJT2xIjz1nzjWvB
qBFfIGkkE2mQ+ruIV0yyiH4zI77zl4hfCEW/hSJpWtVcn0qnU+FT9JU2vppoMickmDmlgUaYuJF5
nClGKmQTOVLzJsVzrO65eETfJQBHF/NuGNGsW1JjHo9TzGoUZoOa/EFtXAyTOXt8vD0xIWFuYxQQ
fyFInD/fmvbojn5N+YdIIRV/H/fjXz01Rp8/e+RA8bXfzv5Sdpp/GqoyWF/kgn6R3z/Kn73224+2
yE4v+a0h/bVdFaum38tHyd8GzGGU9ll/28fWozfgvmPZtn+i38V99ot56ZP74T99vrHF8dcs31cy
/fnHvPFitbcei3kGNS+LvxL79ePnu3glqvu8fZkf0t9ifsY+/4xCzE/QnuXa2BYUWkK7d2n9lmM2
oxC76+Yx2fXX++NffPxY0K66adxvRfqQ/7J8X+59cd5l29iTaPTj5rtprucj47BfQ6PM2zfIoeIW
uq8Tf/l7fc4D6KXPMqfEiCqXHXfNJ+uVOU9/h/3ZLjYNvcBsROuXa+MBL/kBWs9djbQD7RL/wPzp
081H1iOP5F7kkZ5FHvYxgO+Lwg7k+TT9JV2fjm7xxf0a5oi7eQ46FvvOdRwvRx7mTVR9Y/8beY3i
XojB+Dx65JPWADQvLIeHU/SFT6KBdb6weL6b1pK5vM5uSR8di/JFppeOy8Sj4HJ9uK8txZNvwNm/
eMy3USobXIpbdm6gYa+iVD4NpUpe/GR6SgPrPPVJdEvW+hjyLYcHWad/lnGAx2byK7SbdKJGeLaR
EGrFr6F08ggqIO+h3Xg12iLSHQK4He1mG4GW0l+J9oM++A/wzEAB/HOUSvuI6/g5ZFC0326IjP8/
uMCuxfuL64vri+uL66/hIl/HSTGYeQU9uKStF5Isit+IDi/BW9FbtxqPCaAn4S6IPf/T69sJZw7c
/9lx/pIXo/jkOOeL66/jIv+I+v5f9P1ruJiPxHj40UjB6bcsj+H/c72Qor9gueMzl9cXF6Z6Ubn3
4wsr/aLcspy8VeHU3LGbi8QULSdvLjz6C5f3by7SerEc+9hyjRaZe1G5JC9cUp5avijioTyq+CBS
lPcsU/78eYqqf/mi1i0q+78oX5Qvilhmby6a6s9Vhr8of8Xl6cJR+g0NW4W+gVi0FzGIIC3y0v8D
gKyUnIMa/f6GR2vo/1rBygDeRcMXEcYoDWoRmCA1ejIKM8iPvh2FWaD5XRTmkBnro7AEpeE01IU2
oc1oJ7JHPwfhHkajaBuMa0d7xNZ18Blr34U2oBE0BhQ7gHYHYLeifWLrNmjfBbitUDZAbJUN2Bqg
s0PLqDjabqDYgByoSvx/GFaj21At8qBqsc9mNCSOlgUtm9FGmHEX6gDqjdBrqzhTG4wWQGWfuncZ
yoGSC+vIEcun7bcaZt0BK90sSsEeHeHT9qaaEa+5a8u/6/Y/IXt/cl747+F54Z8e2S784ufZwi/f
2Sz818tPCT9/J1P4x3eKhZ9esgpvX9okXLz0kvAPlw4Jmkt4RLiE4bHirQuHhR9fOCH86EKR8MPp
VuEH093C+el+4dz0sPD30yPCm9OHBDStnbZPMyP26ZxpQkFCMWSFfRr/3ZRb+NupMuGNqQ7h+1Mj
wutTO4XXpr4knJ3aJ7RN4bPzb748tf9wQHxu2hZ5BtdEnlUB+vTPT3nzAq+Em4TvhvuEl8PrhDPh
LUIovEf4Tviw8FK4V3h+crvw3OR+4dTkCeGZpxKFp58qFZ586mHha48HhcdP5AgT+HjwPsYj3MvU
CYd7DwXvOX0oeHfvweBdpw8GvQex96Dv4OjBZw6+fXD+oGRf757g3tN7gsKeB/c8s4fZg/cHD/Tu
D955en9wbD8+1nskePT0kaBw5MEjzxxhjjA7gm3jA+NkHIBtwyPB0AjuHxkduXuEGQHMrt4dwZ2n
dwT9OwZ2jO04tIPdQUaD23tHg2OnR4OjEixsgUVtrtsY3HR6Y3C4bn1ww+n1wXV1Q8HBuoGgfwDf
Xrcm2Ht6jb8heBsQrq7rCgZPdwU769qDHafbg+2SgLCqrjXYyqQILXVNwebTTcHGuvpgw+n6YD3x
CHV1gWAAewRXslxwJscLiMHSsxi9bMYcPotPhrs6PZ6ms/x8R1NI2tYbwsdCKZ3009++JiQ5FkLB
Nb3dYYy/3HPGikl1l/jP5cX6fQ88gKoSm0KJnd2hZxN7mkKHAPBTYB4AlBg2o6qetTs9N187b4B3
7qTPndEK/O1aaMZwo+jTE4U9nlg73r12567dsTlEOkBE6mihM/bErwX7/79DlbVODQplbmRzdHJl
YW0NCmVuZG9iag0KOSAwIG9iag0KWyAyMjYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzA2IDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDI2MyAwIDAgNDk4IDAgNDYzIDAgNTYzIDUzNSA1MzUgNjA3
IDAgMCAwIDAgMCAwIDAgNDE5IDAgMCAwIDUwOCAwIDAgNDUzIDQ4MyAwIDAgODgxIDAgMCAwIDAg
MCAwIDAgMCAwIDQ3MSA1MjAgNDI1IDUyMCA0OTQgMjk5IDQ2OSA1MjAgMjIxIDAgNDQxIDIyMSA3
OTEgNTIwIDUyMSA1MjAgNTIwIDM0NSAzODcgMzI5IDUyMCAwIDY5OSAwIDQ0MV0NCmVuZG9iag0K
MTAgMCBvYmoNCjw8L0Jhc2VGb250L0FRUUhRUStDYWxpYnJpL0VuY29kaW5nL1dpbkFuc2lFbmNv
ZGluZy9GaXJzdENoYXIgMzIvRm9udERlc2NyaXB0b3IgMTEgMCBSIC9MYXN0Q2hhciAxMjIvU3Vi
dHlwZS9UcnVlVHlwZS9UeXBlL0ZvbnQvV2lkdGhzIDEzIDAgUiA+Pg0KZW5kb2JqDQoxMSAwIG9i
ag0KPDwvQXNjZW50IDc1MC9BdmdXaWR0aCA1MjEvQ2FwSGVpZ2h0IDc1MC9EZXNjZW50IC0yNTAv
RmxhZ3MgMzIvRm9udEJCb3hbIC01MDMgLTI1MCAxMjQwIDc1MF0vRm9udEZpbGUyIDEyIDAgUiAv
Rm9udE5hbWUvQVFRSFFRK0NhbGlicmkvRm9udFdlaWdodCA0MDAvSXRhbGljQW5nbGUgMC9NYXhX
aWR0aCAxNzQzL1N0ZW1WIDUyL1R5cGUvRm9udERlc2NyaXB0b3IvWEhlaWdodCAyNTA+Pg0KZW5k
b2JqDQoxMiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxOTA5NS9MZW5ndGgx
IDM4Nzc2Pj5zdHJlYW0NCnic7b0JfFXF3Tc+c87d13P3LXfLzb03yc2+J4TkZiUrkIRAEggkhF32
XUBEUVSUumtxt7VqxSUJIEG0Yh9aay1qrUtt6/Z0calYba1VMMn/N2fOZAG09nnf//u8z+ftPXzv
7ztz5syd+c3Mb34z55yAMEJIj3YhHs2c0ZaZ8+VXr78PMb8D9PSt6l27vtFsQwiXAux9mzcG+m8/
8TJC3CyE5AlL1i5d9fnnzTqElGsRUruXrrxwSWlg1XGEhGsQmpazbHHvor9dGb0FoTkQhwqWQYT+
EeVuCH8B4aRlqzZuvXlHSyJCHQkImVQr1/T1Lrzt2J8RWp6EkGrPqt6ta+2t4WUIrXsY0gdW965a
nPB4QRaEfwHl2bZ2zYaNox60B6ENdeT82vWL117wGDcCYbgmSUC8LIavQ3Kkku+X58IVPir5l9Ae
DqkQZ5RzHCfjOdk7iBuNo4dHIReiD9TcFgigOAoEBAUaQfiE8i4uEkD4bnKOPyI3kF8DjZHUvHiF
DsmwBmQE4mVIgYIohFJQJipCJWgqqkUNqAnNRO1oDlqOtqF70CMBYXRUzCWEklEayhLTlaM6SDcd
tUK6XnTBeDr+Jn42fD/Je2UyUobRv5Jv5BV5H/eT3y+EUkTEuCSEJJkD33lQAoRKIVf24fkGvp1f
z3fwK/lm/nYorQmZkRMlwPVpUOISVIMa4fe70Hy0CC3DHDZiAbuxDyfjmbgLd+OVeA3ehDfji/BV
+Gp8Db4O34YP4+P4GfxT/Cz+BfkR5V0IjdyIJn5mohVoA/SzXdBe+9CN6Gn0W7QQ7Qa2H+p5P/oh
6kfPoOfQ6+h/42fkQvkqpOOPQItYQFOnR0+N3A8YghYcj7kRQhZZYDxmVBj9+Ky4j0duHBVGhhRm
pBGv1XMvQ+zf8PDoaa6chEcLSJi7ArhRvOJT5V0jj408cJYOWkCvc9E81I16oIUXEg1Dj1gBbb0S
rUKrxdBqOLcUvpdAaAGk6oNUhI+nWoPWAtajjWgT2gzHWuAbpBA5t04Mb0Jb4NiKLoQetx3tQBdJ
31vEmB1wZpsY3grYiS6GlrkEXSoyJmnMbnQZuhxa7Qp0JbrqG0NXjbG96Gp0DbTzd9C1X8v3TQpd
B8f16AboDzehm9Et6LvQL25Hd5wVe6sYfxu6C90NfYacuxli7hYZOfsk+ik6jB5Fj6HHRV32gdao
Rphelog6XAs62AE13D2hxFR/W8a0tRPqTuq2V6rpVoi/dMIVmyU9kpS7ISXNhbYDyeWiszRxHdSB
8vEa0dDNYv3HYydq5ZtimT7umKCZ28UQYWfHfh2/Bd0JI/Be+CZaJex7wCm7W+QT4+8aS3uPGP4+
ug/9ANriAZExSWPuB/4AehDG9kPoAHoYjnE+kVH5KHpEbLl+NIAG0UF0CFrycXQEDYnx33TufPEH
pfjBsZij6Al0DHrIj9BxsDQ/hoPFPAVxT0uxJ8Q4Gv4x+g8Ik1Q09FP0LFion6Pn0S/Qi+gnEHpB
/P4ZhF5CL6NfodexHtgv0QfwPYxekv8BGVAFzJVPgJ7vAIs6Pz5t0YL53fPmdnV2tM9qa22ZOWN6
c1NjQ33dtNqa6qrKinh52dTSKSXFRYUF+ZkZ6WnJkXBSKNHvtJoEo16rUauUCjnMWBil1YRqewL9
kZ5+WSRUV5dOwqFeiOidENHTH4Co2slp+gM9YrLA5JRxSLnkrJRxmjI+lhILgVJUmp4WqAkF+k9W
hwJDuKulA/i+6lBnoP+UyJtFLouIAT0EgkG4IlDjXFYd6Mc9gZr+2s3L9tb0VEN+A1pNVahqsSY9
DQ1otEC1wPqTQ2sHcHIZFgmXXFMyAPO1nvxsPx+u6V3UP7Olo6baEwx2inGoSsyrX1HVrxTzCiwn
ZUZXBwbSju+9ZkhAC3tiukWhRb3zOvr5XrhoL1+zd+8V/aZYf0qouj9l2x+cUOXF/Wmh6pr+WAgy
a2wd+wHcLw8LocDevyMofOjUR5NjeqUYRVj4OyKUVHFMTXCecQRlgxJC/YJBUparh+JoIQT6d7V0
0HAALfQMonhmrLOf6yFnjrMztnZyZhc7M3Z5TyhImqqmR/q3eZmzf9fCQHoaaF/8F4Z/cD7Qz0d6
FvYtI7J38d5QdTXV26yO/ng1kHivVNeagaxMSN/bA5VYTtTQ0tGfGVrbbw1V0gQQESBtsLytQ7xE
uqzfWtUPDqN0VX9mTTUpV6Bmb081LSDJK9TScRTljr4zkBfwHMwF36STlKPfXgWNEqnZ27FoSb+/
x7MI+ueSQIcn2B/vBPV1hjoWd5JWCgn9Ke/AzwXFXxSvgrqdlZolJjVXhlWBDs7Dd5LWgohALXyF
KkvhhADNJQZJi1aWBjqwB7Fk8CtSCsIm5QMBPlxVR07x5NKqOk+wM0g/31Akj1QmebhfNSEvASLG
ykR/52uLRlOTAqUEahZXTyjgpEzlUgGl3M5fTo7oQvphuEJFmrOOneLDMHIhjoNsxCjSis5AP5oZ
6AgtDnWGoA/FZ3aQuhFdi+3b2BZqbOnqEFtb6iWzJoXo+SIa6kdBOM0CXBX0wdqYhzWrGJ4mhseC
dWedrmenA3tVoca2vSTzkJQhCsAIgkorIvW9VxeZ82Bo1oJ1C9X2hgJCoHZv79DoroV7B+LxvWtr
epaVkDxC9Yv2hto6Sj1iWVs7LvJsIz9lRo24cVZlehrYnsqBEL6yZSCOr2zr6jgqgN9+5ayOQQ5z
VT2VnQNJcK7jaAChuBjLkVgSSQIBEiA5tUJAJab3HI0jtEs8KxMjxHDfEEZinIrFYdQ3xNE4gcVx
ECejcXExjnygkZzLQMVgbmsCi0jz7OhctrenkwwuZIemhH+4H4fKUD8XKhvAnELXrwktruzXhipJ
fDmJL6fxChKvhI6B7RiUQ2zS3p4Q2CnoUB3Ig2lX5EmWgaHR0VkdwZOeU51B6GrzAF0d/eoY2H55
uAHSTSPogehp/bv6ekk5UHsHuVYZru/rhG7LMoQk9f1qyEEt5QApasVrSHeEi/qgbaABxet3QaB/
V2d/Z4z8aMfyTrE7C/2oLlQCzU7zlEfID2V27jWHcsSxCUNBE76CCDWUDbV10BgPBOHHOqmSlDoo
eV8ITvX1BEDbMtTXBl2d2lKNh8YsBpMoiywWofFIJxGpFh/W6jX96gzIEP4Rrs0gQ1IeVnZ20sKL
oSukBPDbQr8WShSZoErpAtAOnKonZYF/V0BRSdJnSDYtQ6g1tBUsCym0mJMSTvfrw/W9YPzp9VqI
CRWxi1XERmilPE7QWCWpuQ70zodnDY0+ELowOOGTnhYikwPpmMhzFDo26tx7dkT/3Fh6mursWL0Y
vXevSn/+C6i+VPoxSSIDNTBrQEI5rNg28C/DCotHSlSMmmEtPPdJpMetyI5K8OHDtupqVbryR7gK
BkIAz4I1PMZVcaOM0x9xu8tDR/IV+3hT/RBOP1Su3MdxqHz4reEXMoffOmUuzjyFM9989613hU9f
MBVn5r77yrvZWdgUNImwGjil0qoIJWZw+dFIQW5uThmXnxcJJRo4MS6voLCMz83xcbyVxZRxJIz5
l7/q4mcMK7idofLZuXKf22jVK+RcgtOcXhoW2uaGSzO8Sl6p4OUqZXJhZWLjyprE3yhNXpvda1ap
zF67zWtSDv9Wbjj9V7nhTJVs5ZmbeMWUeeVJ/Hc1Kk6mUAz5nK7UKcH62UaLINNaBJNdpTSbdMnV
84b32BJIHgk2G81ruBnUEho9Ldspt6JEWM/feRQljb5/SCfgptCQRCJDo58c0gLRMqIBEncTFhbI
t1781onf8WQcJqfTtLg5KRQJf6bT6pyJ3pBGj+0yHdIJOu6x0NOhF0N8SBfSmb2t5nZ5OyovLzcX
F2dmdnebHMUmoKZc4VSOKRc0HuuOiR8Ui4XtdoWo8igf5A18KDESKSjEVM8OZYgPyjapsBD2+8MW
tWzN8J9W8BpLKMEbNmIVHpTpXVFfINVtkG3Hb+MfT7V7DDJeqVPjKSPPqfVqmdzgscsGtQYVz6uM
2n3D2xH0qYcRkmHoXT4UQ0XoZ3G33yngZr9gJF96+HLq4CsAdfUPcRnxZLctDudtcThvs2nTSOI0
kjiNJE4jidNI4rQnuBxY8x8/DBxFckHTByElyE8OGiWpF+XnB3WifP+glkhOiOvv0R7Xclp39LPs
bGXSEFYPCi15Q1g7oJyFyk+Vi/22GGd2vysqLeeVGCUQHYsVUw5KtRpkoWBiJN+UV5AbBO3ZSH/2
8TgvgwuFTKQzW8apDPuLZvStqx951JGS4sCRjTf15dhjFan582qSR4bdRV0NgyeqWgtc08PTLmh5
4fSUjqoI3jB1aWtZqs0flV0a9afN2tacMWtakVmT37qaw5lN+Qkj3aEpM4bfLOko9Y8UJRS2wtzV
O/qJTCf3wSheeDABTYlJWolJWgH5EdEKyI+JVmKSVmI/4nJhzeTEmSiIIjht0NImO4ZTUT7KwhkD
6tkwpF85RYAzafWF105kZ4WtBsWEYamwScOUDGCb1ceRepNuJdNxcpU1vmB7/c7nr21uu+WXFxet
6Kr1qOS8TKVVGXJmrJsxe9+iwvy+6+Y2b2jJMyo1Cv6I4DQbrClRz6z7Pr3z3q8em2cLpHoMFrfZ
mmBRRzOjNXue2bH9qYsrIpkRhckHI5D0smuhl5mRH22Je8uD2EJ6joX0HIsV6mwxQ4UtTqit5Rjp
OchNdeOWdOOWeoxb6jFuSTfuY5wJqUE3ukFDi2cIRwbktJcwXbzCekQ3sWiTuoRyQge4dvYPPrl/
5GOx+cMPvn9ny+G8NQ/teWxgx0Pri7nbHjzzg1ba0HO+//7+5Ycva/jKVLbrGbLXCTXjd0DN0tDm
AXdUatGoVOqoVOqoVOqoVOroEGeKq9WWgCUAhXcPYVVcvyuCj0fwSxEciShcQ1AffUsUxIBirNd3
r1sP1coUzYgg9X6xnblzenooaDqL8jtkGr1q+EZSQ26JSq+Sy+FrRIEHVWAaZGrg0zms0mtk08we
s4rWVmX2WM0ek2pkhVpIsJjdgnIkW2XyiPUePc3PgnpH0bwBpUWqt0Wqt0Wqt0Wqt0WqtwXqfVjv
RT6vEqp20GJxKYZw8sHEFhcxkNKMlHnCVDxWO3xOZdhsw6rLz4KKKUdAe0oovMjjKmvA7Uy0qqCq
tWLsCUsC1KJOKXhsFo9JPfxHpV4pl8OX7FFSS69UI9lMmCUy0dCh8mwc0kmV0kmV0kmV0kmV0kmV
0pHGTHAkaUmP1pIerSW2UKuBNFrSo7XEqjlQ3AamMG4hX4IJN6E4nEeOodHjB+EEkY/DOUdqK5i8
tLjxuA6/pMO6yfMHdIFT5Rjs3CtEPZKSxrtCd3hMORP1RMe5DeIYlc1UWYNOd8CqGj4IzEV0pbIm
Ol1Bq4prFrUHzK3SESXpVFzZ8I8Zl/2GseHTnIJxSX+4A/RnQzOPlDtmOB5z8EhSIZJUiCQVIkmF
SFIhegJGsWb0+BHQhEZoFasL1RwbuuFzKoM7WLnVtqDDNbG04yUkpVKOfoz/AKVKRrDQRv9CcbxQ
HBNu9hpCrepjOAdZwMhkDMglawvdNDZhriGlUzAHSPSUxkv6h4TqNa0JhRmJWqWc48GmqlyhDH9i
VkCgVbCocW3zrq5stdGk05lcZjt4P0az0ZTRUsHfReojg/pIlqYRauJGdUeRjdbEJtXEJtXEJtXE
JtXEBn3zEFIbW21DOCaZEpx5kpV8gu0Y6yRkSDWCPVAPn3CksE6BXyIORKPVY1GDZXiUKfjMvWpT
Ahs7O+UmNBVdfjBqNFqldhelUZJ6UX5CimeVimclQ8fn02Rk5JDBk+M0ki9ImCPoCIMkOSSJgHxF
rZoMY1TmIraC1AOGg6MY6iLZd/Ck2DjIzJUqJvpRYE6jIbvdNsluiO4U9vGO3MiEust26m1ufaE7
GgrZRpYFKhJg2aqy+J1Ov1mV5m71Rv1eEy7xFuRkOzGYSovfZQ+YVdOs4HFqvTlR7p3ii6bU3dLw
1d/GjMtDyYkaR4p/+Gd5fT3dmTMOzOB+BP4YWFtoULJuHT0le18ehK4VRTvibivRgZUYECuZEq1k
SrQ6qZpy4+oAyhLvSfok5fqktvdJboNPcht8knJ9x8Bt0CAXThk0toVI+5POO3Fq7D6rB4+58OLM
OMFPkL3fcONbN93w6tXVDTe9ddO1r+yrORyd+921a7+7ICXSdev6dbfNT+ZuufOrgQVz7v/8nv2n
H1sw+wd/++Hqp66ePuuaY0vXH7+6eda1TxIvAOaMZ2HOSEApaOtAkkKqiEKqiELqxAqpEyukiihI
F3CYvEQ9XqIer6DT4yYv8TO9Q1zOIDKFh7DmoEKhg2pqD9padBOmE9pBhMkzSujsaUQ2wRngn41v
eWTrjWpL0EX6fqob21Kbl69qSjk8ZU532t23T19am8Tf2HvH6tKRjDGjA02tdJTPu3DOjBV5huEv
k6f1IVpjmRZqXICq0fVxn5BhKlRBqQtJLQrFWhSSWhWSVi6EVj6SQrzrlHITUQUwk6Qak6Qak6Qa
k6QaE6hmMCFDAA/i8bVxHI87poIGDgdbHNKcIfoNxF0+x1sulkaJuNjI4M9Rid3h4yWn2WGx23Fe
JBqJMHdJq7Am+dxBq1a2xZZeNmvKBqYscJ8s2RXuxg3To6HKecWBvPRk60aDamS4eqarPPf6B6v7
Kv1gqcGoqWGIZ+fNKQ8NvzGmRJiM5by+aPaaqoqlM0qshljp9OyR3yd5+cubljuUipGm4JSZYG2m
jZ7i+2Dc1KP3jqIKWMQZYVlWIamoQlJdhWRrKiRVVQxxafFYTtxixU05cbDsSTlJOTqPk1zrIRO2
RxDIF1ziIc3heYLLJiuYgx5xYjh+0CVJK5WPG8kkrss4hqOoEGlwJK41BQpxYVyrw03QPsfjGsIK
TYUmeyl4O4crPPKUNvsQTpHGITTBKRPx5WKxbuGUQLrq+KxupifOGqCySVNM3tiUc7Zzr+D7qrbc
212xZs4UhxamD5Uhd+a6hqLuqqSc1uWrl7XmTll+/azYnOZSi0LG8QqtUptZ3V1SMDPPndO2YvWK
tlx8wdzvwBIokOgM+2FVrkxMDvkKZ+YWTp+SnVs2a92MlotnpxtdfovW5LSYwedPCHm9WZXhguml
OblT29ZBGxlhrL8OPT8RLT7ijIN6nSaitUNkuv3WA5/MwyZYRJKerzATV9Erje0ccA8+FZXzk5hw
IjbmKI47QMyciRPa66KDexPzGYBJDjB/mej+iv7hmbvGOuJClSnBYqFbCGR+ewgs9YUw98bQ/ri3
Jx0HyKgNkFEcIF0nQHy9AOk1AeLrmSb6etDTkF2qsF2qsF2qsF2qsF2qsP0JTiB+EPEINaQLqSEL
TaRVaPWM9xvRAZQseGy8i3Tjcz0+69nOiOzCml1Dmy7o31lNXWSLKq1tU33jppaYqJog+CJvbT66
q7Lswse38CGmjq/+2rWnMz2t49I5vGOibzV19LTiHdBKKVp6MFKKc4ZGv4hXkU4fhuZREZKcicOC
GBPGiU5CUhKxM0BIejZOz8LpSTg9hAtbU1tDWVp+orMLs3s51Ao+ZINEOsJkT4TM6iGesUikoIDO
57lso0RidrtCKd8tExJSfP5YgkE28il3mje4UwLBtAQjP/KQApsiAX+SRcnhEMZWXm0N+xKCVjWP
Uzjs5RWWkNcXErA8YjCROdtk4H/5VSbjsgMOt0HGqwzaMydkJVojcdOM2jM/lU3RAJcb3A5i/+eB
pSrnf45yURz1xwPGSn9lZiWvVTvydNDseaTv5JFukycQM5Q3hP8RhyVV1IiwDpHehUokK1YieVAl
Uk8hUjR7JUOcKm41OX6C8oQ8bsrxPIzycF5eRkXqEPbEjS8l4sREmffDjIapv9M1y1AmW0ueMonL
ifndzB04EZvfXSytK3NgcpgPXjfZiwIPKV8xvpOQmy/5BlKMTOxXSmp47Lk5BYV8uZDgcfsNU65v
mbahJb1s44PLd9izpxdP7a3P1qnA/VF6Kmcvyeu9clbkvn3Viyr9nTMr1kx16nQwf+u6ymvDtUsq
mtY2hGvzZuZ7vCGvSnAZXV53yGtJa98564QjvTyltq2yGrS7H7T7qnwdSiV+52EYGJpggTSiCqQR
ViDpi4RFfRUM4S/iHluMOFexANltIfqPkfEcE8RNGE4TVyObpiA/KJNnDWH545EGT63QVAx0QN4s
jkBQoaN4zPcc19nYGIzazh2MtHMy10ppsttFZ+PV3L7rumP1tbVRWG3bwJlUKC0Bpws8y+TGurrk
hVfPSX7Uljc7HiiL10Srd1SVdRS68Hubjl1Wa4qUpKyG8SiTwXiUF6noUkE1/MeUopAwfXf/pppL
F001p1bmjOxvm1Patx1GbBdoLMA/h/LRVQMJ4mxGl0PvSMug9w+R5c95tjE+nrx9Mfoh3dbgtHF9
pgEbXO/54xp9nR/WrtwhSwP/52xi69X6uuy0IawYUDeTVVPslPg1tnV3YmwD46yNKgWdyhQTt6n4
ACdXukobOzJ7b1mcX7Fuf2espTrfqVZwZr0xWtpesuXiYLy7tHh2eUyn1Cj575lcJr0r7DXHtx/c
dPnT26YI7kSnweI0R/3B5OCRR+fs7oglxUIqi5eM0x7Qyx3yVSiCitHVcX/5FKz1FJPRWUwsezHx
DIpJ7ygmnaX4GP4SIZRJtZYpKStTUlamNGIzJWVlkg6lsQRrtcVRj8wAw1I+6GyAoS47aGiWN5HJ
TOxO5WftWIn9aWzhO3EIgms21qv4SGSio17I36E0JVjJJvi0/XP7rpmTnLPw+gUzdseVVj/pU+r7
qy6qLoceBD2qIjg1Xht1sQ60pXl28+6BhRuPXTatporTsjXMcA30nYU74tWXLoa+VJVNtNUN2toP
Vi2G8tCj8dTMgvKCNQW8hYwmS4Bs/1iCacSPSiPaohvDon2DvvDl4erYfTGObHkeJqMtTyZ1PpnU
x8SwVpTUwMmI/oLBtGd3ya6Tccdl+CUZlskSMn8XaXB+2GNYa+AM6g8TxA7WPXGfjA7KN2O0s4m7
w+IAVYSCE7qVbXLn42zRAlGhSn5/1DU86Ktd2xJfVJ+pU2oVPMcrtQWz18XXPLC+pHTdPX0rbu5J
v5+/cMvUeWWJsFSMBhu3zs6wuW1Kg8ustxh1WpfTUrZtaNvGo5fUVG+4vcNy6U0ZTYsLycwZHj3N
7ZFvhZlz0aBdIANQHHgeyWp5mLXySObMI3UmcAO+HMxKDQ+NvhQ3k12ksOZUwTR35FRWXaBJqBM9
/hyywoudyP2UjrHcE+PrO7Gr2Gi9FRM9fjDzzLqLepBxe2RylUJp86V4wnkBw3MqrVpuNj6nAtPk
DFhUFwsCMTUXh+pWNYQqk3QqXm60OAxytVbtzG0pWag0uS1Jga/+rNISm6RV8bZAksVtUnbPv2J2
it6os3jIvYf8kRv5q/ifoTI0HS1AL8Vt5vRpZJRNU0GVpwUEC26allsOXgVRQbk0vkC+8zg5Va6c
ATSuN5px0wyPzJjF5yqVpPcIor6Ox/VA0nOVHo8yN11GdBzPI0ruID/RERDgso7UcFwLMmzMUvJF
Db/Rtb1vs/UU8R+U1qUGKt8oapj7RmCGtP1aLs6Yp16jpj+We5Io1wFeOvHTTRApnIzBvxj7IloH
HdvtdCqIRBVgz+wOaVXF+lwhTK95BeI3Hdmw8MJ5kbHplNymiESjBl4K8VdZjJeEEnK6d00v7POY
HRUFf65a25qRd8H961btX5gmBLMD2Zk5YX9S3rxLmlKm+bFgMo2MLO7OmpbpWDw3uy7T0bag5YNA
ilN92ebGxWUefmPInzQnc/rWtjSv3ZzhC2VwGi44tXNK2dr27HC8My9YVpTrcjWlTe2JhLsrm7fN
SlergiOfzlsaKKpP7lziL6wbnl9Szqlc6SnJtooqb1YZ6d/7wfu/B2bmHHThofI8nDq+ASx17Ak7
w9JOMUzLDh/dNBW3T8WdU9FsaMk5Dd0v9aW6YLGrOJLekFTrahLNp7jIHduPo5Nx8eRNQ3E2UZ5n
S5S6jjb+HpWZzrnOjPqssh3VEHRBP1eyqXjadfVd25uCLtafOWPz/Oqkjvbhq1nMxPm3sX7qkqt6
iaW8fPQ0bpFnIhsKomuOlIdmhNaEeLvky03y/i2ifOesVQJdFRzj1qEEZPu6LT5JpTZQ0+MaP7kz
5x/CZYdcQr2on9dOxSRrKM0s599RtZBpl3RG6IW47GwFWNKmlMQIxlTAX8b2JnFWSWpKMYC1/A5o
+Tx0c1xXXoBTsnF23IybwSF4SSxmtmTws4kToROlaPCzj3FRWC3qpNp8/W47dAa3PT0dkYrSTmFP
1MqT6xNqTaxDwOoZZ4J7Af6saAVz3mH1Hqt4FJ+nO0gLCDCOSoztdn6HypLo9oScRsXIZWdrBM9S
mV2JTleiTa03jjyBV+u14sYGr9Sr8V9H9Od2jK9exps1ejUP04ha5xRGnhgJm2ySznAZ6MyG4uLO
+Rpx5/z8W9OstRHo4ZBGqBVrLLXv+XfKz2lL17lFk0ohfwlm9Znow7jHLGil+3ERcf0WFRdva1tx
7bn3dOh+y4R7Px+OjWifz052Jn05GjKwNWRga0imGnFga2A2OzKTrJBnlp17i4xme86ttGP4CzAr
AlYMNjaAu6mI6ysaymrTi+rTm1wT2n/iRmextOtlKmab9sQ+IEK+yUh8ndWwSQtOqbPIX6LGw6Ky
plVnFG+oIZOkI2hR2tOqMoo3jtkShTnBYfcKyqZr64s6q7OE9JbGaUlzNtf7x61KqPgsq3JuDH8Z
TMU8r9aqtrTPcGdWJGdXp1rA3DQxqwstmINuihtpC5IvyQCf3Upfc4eOLI98WkFgdli8oTXhXhb+
4ohkiokhjmvSG1JdSfVM9WSeHL83IkzS9rcwyLZ/ZpDHlHhr8z8xyJMUBQrqIfaYrH/eAg2RHfcH
4wnlKTjZjFNMOKLHER2OqHBEiVPF9f95dtnfOe8uO3FPfZkarJmwfR+YvH3/BKchO4lHjKh5LTST
awjjQWNDCNZK0oKSrIkklWWObcp3s88/253n3yrZ8Mj6NT9YXVC84eENIAsf9ZStmFG/vDroKV8x
o25FdQD/cfXRPY2VOw+tB9kAckf9pQuL8xZc2txwaW9x3vxLyWp65Cb+VdANWU3vIqvpYIFG6iUa
qZdomPXRSLXXiNO2jS6kxSW1uJ9K19TnXUnXCzO+diV9voX0efrI1y+kb5ifXF0RT5rQWaw2j1mZ
0tTckr5wL1lI54oL6dpo9baqss5CN/5g85O7pwmJeaGRMmYLZR9An+F56D0Xppal2Joue2xTzSWL
Si0pVdkjt7V1lC7aIa4YQVt3SNraE/eAuvzaGBkwMY2ObSqIRi5GVoupKJd2mwlPwHwoPQHDnoxh
T8DAatEWrtdOjfllQgZZLbobishqUWiWz/i61eIkneWb6N4Y6y+O/K9fLarJMPNblSkNdfVRoqKc
vusXJNfWTEslD1FZE0zKc1aMI4eYpvDJlOKQka0aTeEpKauY6kb+TpeNdAsClo2ideIeEPfC+g6t
zccRo9SpjFLVjaxzGaVeZySdyzxhG5X0MuSGPheOq2MNEaMtUG8jVkc09+KEHxvz/iYuec5naMRO
pOAe4BRqlcrhTbK5svJLQmebmXBFSbFXH0zy6mQ85hfafSa1Wq2yZjQVDvefa2h2F1RHjbxKo1Eb
xGckWkZPcS9AjevRC3FdZmN544zGixsfa5RPuFXxuXSLQuwUFWRDxnLWLQzx1gX+XdxP71eIdypI
F5NuV5BFIbE5nifw58TIxDXELdLFRVcJghHIr1z3mI7TZbxZqPmzaaapx7TWxNPbEr8l9yQa7O/T
wTh2Q0K6HdFNNpgn3I4Y9x7/1dsR3Au58y+dnjWnJsuukZHbDbHy2UWp1TmeaHxme0s8mtK6vTWp
riTFpuTBO9Io1IkF9Zmp8RRbcry1vS0exYaaldDeDpc1yW9xC0pPwGMOFYQjecn+xFjZ7NL83vo0
ndkm6Ix2weQSlHaX3RLKSojmJwcSU0tnkbYIjv6FWyV7BJWgeYdSkCmULuk8XWqLdKkt0qUBmS71
ynTSCXUOffqpUJ1Xf8pRlw1jcUBJzfZJ0u1ypf2akyfoZpbs/EvqyQtvO9uA4FaphEBKhqN2Udy7
02gm9yQuYo7ae2S31Gx8r3CaIynBqpKr5bK53kTBoFaEGzdM5wx0Tf0au6X8Gl11j2i6F6g1arnB
Sep9E9nZ4p8En+CGuB88AW2U9KAo6UFRcisyKhqpqCC6XPjLx+lI80ta8UtaAfmFODYJOSg+DCgN
Vr/UR2HJ8WVcbUmvj2rlrnpwzOTj21tkfDJ7Ndalzru9ddati4LC8Y2uO5Rmr83hNSmabxGnfqWV
bkU4MuuyyrbXKK1+GLlm9ZhHsKV9eunSqxZyiWx0Dn82Y0FVuKOd28RiiH4SwWfaDvpJQ78/ikKj
MJsRR9cv3r0I+7GPEh+2S/W0SdI67v6K0jx2R3b0k3ghuZ0LXoUJRwWcLMeJyRAxNREnJeIgoeVB
nBTEATE2gJMCOGrEm4M4SLZ11CZbXTAAoxZC78fV0BWDZE+NhEhLBEn+OrgwmFwf1LrrtdQAijeF
YuQZ0m7Rc4jRf5j4D1Tv5P5JTHyqF7NbJxOmCIuj0CI9zrsdczw3clKmdyf7fMkug2zkBZmcPO7g
8IYsatmIjD/DaSxBj8NnUvJ3y9QanfKrH5KnSmUqg4afozOreVgUcvClHnbrdNyf1DoVz6m0RNv5
sMa4DLRdg946iqaBeZoKVSsi2z0pRbiQyHAGjgRxJIAjfhzx4YgXRxNwsgyn8LhkCp5Sgqek41Ly
zpUNNwvSgpnIuAa6qxCAHASjFE1kXEcmEhJtrKgX0xFllgszhDXCxYJMiJvtdUJufbi+5Lo0nEbO
pRGrKVjsdUvTtqRxNRDraFITJb9KNNl9orz8JGiS6juT2kMkemlj/hpVtGJMz3xUOeFu1XlUPoHK
L5PJR/7B6x3JPn+qS8c/xXGP8Xp3is8fhdDIl3IZrC4cCYlmFf8Gxz3Lqc3Q7f1mFfc6h1/j1Jag
2+klzaK0GscbhdunVg9vGG8io1Wp1kILwUp12K1WQwvpwfCSR7qcLMSpNKS9UmB0NEJ7ZaI9R1E2
KMZEdrSJ3cggFmNKBnZCf3yc3MFyYodkG+wsyo7VpLemknUruaYU4aIQLtBibYAsL0iraLXZWSn1
Ia3JW28aW0IUl5vMmG7YIqJY0nlp/42F7Vb2gPT489Hj9wAtFnbjD/NVKkvU7wvZtLJfvy7T2hIT
vGETVmPnyD9U2BINeENWjezkSzKNye/xhs2ceuTLNINFJ4fVuRIvHrkdBC/XWQz4CH7AYNHLeIVG
OTKAZ4DgZVqrcWQ+sR7gBe4A/SSh1qPIA3XNJyPfg1M82Ckunp04YigwcFE1dpMpucSNXUVEcS7s
r3dpLPWaRtkM1CgtWsn9zhgdtGTwBnla1UJLJAI9J2/sPqdF3Cq0W5Vc7lZFdo47YOIUO9QCP/K0
Skjy+RKtajnG/BcKU2IgIcmkGDksmOQ6qwEXy8wafp7NaZDzKqN+OIN7zaKVwzxhhpp0glP7On8E
xdCUo0iAmtjJ0ykR8RmVTDifp65Wc+qwCRYtB111xqi4eIGCk+3mHPAVToLdkZZ45IEycW8TB6U5
UHx8U3yYBBPKva5QGVTDr9k8pD/ifSMXCxbyxBkn05p0ShI3sgnfr9KrFbUWj0mZEEw02O0ugVsR
DJshrDDYTQGD0+EWhm9RCuBpcVgz+jn+nXw+sqEUZDgsD3uahVpQ6psvTHi2iY+M7XSd9cLCU0ry
wkCCWWnCKlsowROyqQxqV7LfnwLjwZni9ye71HgT83r5J3RmnVyhM+nOFAdjHq3WEwsG011arStd
3PH7nJ8DJclDdaj+KJTNfNjtNqakyIfwS4NGY/4QtzhuLE9K8qutB+XyLHV1CZk68UBWLfEo3iQv
YogbzTjzVC75Z4JvWomxtzHEikgu1zm3Ys9eLPJzcrp2NitDUZvPrFJgtTnBbK+YV+wOxHsrS+bE
UzRKmC8V1uKW3rwLbluUNXICKuwLQIVBAQEfKIB/u+PKngL5p0YjsRAYpmCLMqV6Xk7xgpqIy+dU
mLx2p8vid5unLrvmqylnKwR6TurIW3gDegd5kGZQ60hAwisn6aNHSiW1ioWWsZbYoDA4TFfJ9RaX
xeTQYNnlWmeS25Xk0F7rz8tId72g1KhEQ4UtuzwBQaEQAmQtdmz0H3gff7O4qvcMIOsQt/2Ixhdy
NcmNdaj8ZPlJ4qTlnPuYm+nsjrCPtHogmbR6csBPlTApzAcCaaSCaYHEdCLTh5ODNAJqDJOdW6zx
rVCe1VBjLXIMkIddjj9OHmpR82DeoCixZ0j1J2y2rs4sK80gWDUtM6MGQPLAI+/xGvmPoEerBgQ5
yszMznJI6pJ2KZUPyvRWr80VNMsUXLdMb/HZwGmUyT/VG1Uypd6iV2zXG9WgLase8qvBh7gMbioy
IsMhpNSekiHycJx0lyJIyyKOzQyzaWS+GT74ezAC5fjLqM8fifgUJjfkcvnIA/hv8qtRCCXGbTyZ
Aniy+OBFM8Hb/NrLUTl03Vz60JICvF2zY+yVlgxetAq09PgvC7oXzJVjg9dldlt0fEFrUYK/uDUX
q4UEuyNB4OQLnxvpfO31ka7ndSatnFOo5Et++es316373RsvL5UpFGCOBaKnbVCi96BEQZR7FJmp
b2aWfHsiD5OSmcUHtrTi6pGWMJYz9lyVks0jBeb8PC4qWQmH3YzfSyhqKeB1FrfZ7dVj+bz58+fL
OCHBYUswqbilmzjXujd//cslcpWCk4Ph+jl+4PXX8APPqQUNlE4hOzkyg/w9lFG9Yqs8A60V/y7E
ioPrdjvDQ3hVPDtD50wvQtud7c52VNu38V1/sj9758emro9nzmxU6nZnrEuSm/xwzJ/68crLWhr/
Mh8arPyVU+JKzOwoziGGQnyDiCzVnjlBop8RfvkaLODeNZGH+7C0EomKvUbG7IOjkE4jSl5B1iAy
yYZMutdOb4omib6KQvRKxH0DmXQPqhArtpoiZV1bmlNqC8LK5Ma6mmCsMjfJqTEEitrWNwWmFOS4
TbKEiNllkHOdQlZVSmVOol2Tuf7p6zYPXbOoJtWuzN35yr31m+cUwFpPzmGZUlfce+n0YyPD36/T
+os6L37k7X33/eWOpuEnIzNzYZ0Ysqvzy505ReWRM1/xuPo7e7Z05VqSisPJxUmCKZhVWpcaW7N5
XWehMZAV7DAYZEqYqvPmtKXUdi9dmTPnzi3T8jo37r7q4rXRNUN7GkwWk9LoMBnMRp3GajV03Pen
7+Rdsf/u716xuGTGdS8ej1enVLTObvE3zDSFiqN8K9iXJPFZNivMkd2oOO6d2Tp7av3bXfmKrjzl
3Ld9qSZfFxxJVa1J7Y7xF71MueQFrxxJlLMHT4l7YqOMWb/gGBtbM1ok65AruYU2PigxJclADkEo
EThqu5M3Gi0KlV55eSpWQNd0+AQFTh35MJWTGxMcThJKEVPoVHtSLjRaLMYrU7DS5HM4E4yyVGyP
YpXgczq8BjlO3mC0DA8kY1sqv9nkNCpHDvkSRfkQcYVEt2j2RO4lZ1W4yRcI+XAFRMlkSq1i5EcT
ub9n5BBuIjb6AliHPiUPiPPi/qOoAXxJh5Fr7mnAsU3leEk5rirHeeU4qRyXD3FVcasuIUG3LR+v
yMeN+bgkH8fyMcydVY+vRTgAw564+PQJ/vePQDYoS4d1Q6On4xoI6EpGs7LkkSGMBi2d1UPYNiBf
MPbmGAz97lfAm+x+V/TVzeSRJ5GR9ydiEzY2ZGdvZCjP2ndku69P5a28f13LjnlTw4I5Y8aW+1eH
m+JpBqWMw0qtWhspaM7t3tOewrsrmmdnL7+uM/Koo6CrMtxQU+4Ols8vj88v8+Lvt999YX1yw8q9
981ve+iuq5eWqo1mrd5oMZjdgspgMjTt+uE8o89pLF58VU/JgsokvcNvvuTR5elZLYvJffRW0O0T
8iAiD6JOw5ceRQVkcW4iDzsBIQYwf0iKyWcxeSwmj8WIW5Om8S3KevEhV2iiepzF0mSxZf/EGPH2
XdYQ54q7rMniTJAsbipInDymnTzEOeNunzHk85Fn/K3il8/q0xSJaYrIwtfmhaWgeKEUSS4seoKr
Ahv6ykHSyOONPvYUrvT80nHpXtlx8TGKSrLq0JA8KrMg00pW6EpW6Eqp0JWkq5k0xDPX5E+Vpw+7
OmuGxzpL8dgrKK/QJfSkR3NBCBN2rUnvQTHpM9HRKKTTXu74O4h83tjTTY6CAvIaIru/X8A/Ubru
/gsW3bW6JLlxdU3pvHgwu2//koXXdqeRh5umrWmM/tpb1Ja/co2neE7p4pWpiTVLq8sXTPVfftmu
3bhp1u6ujNTWrc1Tl8xuTPTXtMwrqN7SkZvZsro8d/6s+kCooX0BtyC1Osu1sD1aVVrsz9s5/L2M
xoqpQX9ZZX1a74oLYJzWQV96VnwnIYY+jLvOuj0SZrdH0skqOUx6RzqecOOD3O2zkr0lK2k8K3kd
1HqMI+8xB+i2WkDqXAFp/zsgbTCBfJ94SUkBHBji0uNqDXndIY548U1cNXmuSjNDwyFxh8Qo3kAU
O8RxccQjDdKkp3mGsGbQ2EbeBWCvOpB1pNhaZPkIA33iXSmxyb7hHotswla5jH82c1X/JdseWBLL
Wtm/azvIfoMnVtqc1b5iqt1XsbiuqH0q+Inc3ps/H+id88N/3HPTP0T5cO9tm9sLXTOveXLl9c/v
Kkmqmr/+cjBfj8KwvVvuQBnoj/GkJB9O8uKkBBzy4CQ3TnJhsmx04BRR92ayVs4Sn2ch6s7CiKgW
pUj7lCmSQlOkHbsUSaEp0mI8hbw8YfA5yUVOLfnWmqRxBFIcVyZpHE2IPy69ZACqhyvuMWGTxTyE
yw+GWlOEIaykbxLllA+fFHeJyeckedSIPZFNB8P4jki3tC5kj2TDGk5Bd0IKw9IEZxIXK3crNHrl
8DylTqtQqPUqbDhNniriFVo1TpXpzE6zM2BWfAirM3k12QdWCm6L2W1S87++WSPT+xwmp6BTPM3L
ZJhMP2euVYPTCtpeD9q+A/p0Gboprk8pwDEfTvGS3aX4EJuG4thOerFdtDz2gLiLwaU/nhuGAxVL
ui5+grsYaalytGQvSUvujZqKigOBYuh8GY/n2hUZbULxEE5mGqJ76pnUmIABOTn28qaoI3HXaJJy
yEbQWes6xZjtUIoPs98hVxvVw/kGm1HJa4y6M3OWF5sT8mfmiQ/YkrmXk6ucUzovmDJ/X3eGfdqe
NSe5XJVRK28gT+orBZ/d6nM49Fgz74atC2Ox5pLExOREldlnM9oFgy0p5Myft62mbPu1j61/TW0W
72MsBZtwA+ivA8uPoi5QWQJRWRfOVoFSssnAzxb1lk30lj3E5cc109si06c7Lbg5TnYxI5AkQjbX
4hAbifMGj0pg9y3EKz0B8eE22mU9oPnD4oaR+EQqGd8GqWsapN5uIA1ngWYwTCGPgUyJi9sUU7DY
daUuTGeAKaYpJnvBENbGNfVtaX8LBOT15CUM7dhLGJmnioWx9zDAdGdSey/ZevEBL/LogLl43M6P
v/BXMOHuB33hjPpv5y7OxxvRBjPADWUbH7qgYl1HiVGl4A16dX7bmurKRdWJsbYLm7dDWykVWoN6
XeXy+qg7ryW/pLcpR0McL1gFWUra18S7rpybHijrmlK1ZmY6Xt957ZJCm9dvMMBqMCkhEA4klrXn
FHbEE2F42CwuozIx3lmYXF/gDyWH5EaPnTi/FmjnjFmbpk1d3lKs5ZT5M4ntzwI/91fg56aCXToT
LyFbsek4moaTojgpgsMJOOLBIdFAhZ047MARO47YcMSKIwKGJk6S4yQZjnmwaK3M1Fql251A7AFB
er6JPtf0zhHy3FNCRoYwNPpV3AspBDL8BNIjBHKDQiCTiEAWmAJ5wzuKZNRWyWACYI+JxjXkOVFZ
VmbUkyE2sCwWFARNsFXTLu6Jw6jLJR443UuMSfdpyKuCJ0U5PgLP+uDJD0eODU08bqvsOISD/K+s
5htUVnrLcPhDnaCHdapGiV+WW3xpvmC2T7jBZBu5lxuZix/Aa4ORkU/YzQksKMDttvhcDj1vJntK
clhrf/XTEPfBcAkZcYthxN0iN4DFeiaujxbiaIH4cAIvWqzHqcEqlKxSofhHK8irZOR1mWRQfTLE
JpNxkWyYkbMm5+IcPuf8L889weWK78RKc+lh8YkqyxB5VIE8o2dxFpB3kXVpJZ8FyHsE8rQW56Sh
032KDJ3MGBZek0bMie5X6OChyiXaPe/rsdQFCk16bV0RCkoP5PG31O4aWFm6claBUSG+M6vUpE5b
Xle1tiUj2rJj9tSOSILT7+WmqowaudU84g3VZ625f00xvmfZ99aUmFxOg87kNps8JpXL6w5UL20o
W1Du17nDnDEYUIMRTEoeuVnO5ffuHR1l6xJOwf8cEc33wRh4DDTvR68fRSawXRpTEDeZBEF66W7y
y3jvS/PkF2Jf3Cje8hGG2FWCQG9OiFcJ0lXiaS25q7RJIANHId1QCrKWDeIJju2vRYfWJs3IE575
e1967fedw3CNTW4awukH3S3asZejxClZbIWYdAeI3Qgavwckbp5P3KPlH+PlasVIhtzoSHInRkyc
An84fKPFItcY1NxfDTatQnbC7PW4DGde0BnVvEJv0csakpMsMK8ozAmgTWklAtokf/OUQ/NxEX8n
X4/0yIO8h5BBadM+iTXkD6zCtxORx2lxZu7JnLO2oeymSSH+TodxWGe0W03cZ2brRM7zyX5/clJi
4sgccrMqnJiIbFbxr8/Kf//6nYqNaQuMpX9HapX4p0aP/XmH+JdYX75pR96Z08NXqz9SFUBQDeWk
H7iO/m1bzT1nTp++R/0R/cu34x9ZpcwwHsIvQsy9KPSv/gVWWRd6WFaNes977iPynvf4h39/cvjr
Pvwj508n+2o8npN9u7zEtPuQclL+3ee/VvE6elieev5z8ibU921/j3xkieP5yDrO0sMjaNr5ruH/
RP627ITfTEQP/Su/qfShqf9K+km//RkS/tVrZDJ0L/88WnXec4vRvZPy3zU5/LXlmInulV2KVp6T
39bx6/FH35wXnDcxzpVJ+T5Hr+HeOf+1CgX87vXnPyd7CC35NmVnH/4nNB/ZAFrCnzpLDzNQ/Xmv
6UQJk35zH7r7W//eMAoqylDhOfG/QAX87nPblV+OqieFX0Xzvu1vjZUvD+3nF6Ku851TrkFdijcB
mJ6HtD2Tfu8M6v42v8GtQ2HFbSisehWFZQeA3y7xUhT+NtcrNn+7dJOuUcNvVJ37GyQv2anxOGUy
CvMnUP7Z159dVyluP+P4NXT5PysDpNl/vnj++5PyOW8axSK0f+LvnVOWovO32deml/Ii9eJ+Pjlf
PohazneN/NHJ8dyjKDgpzz+hoGzT5Ljz/jakkVtQUNkI/fuNf56epIFy3vTP0rEPfydKlA+d24b8
FpTC340Sz4lPIXeWz//hHkbV3B/RSm66KOu4ITQNP4OSuFtRKvcBWon76BwJ4ZV4Plopmw1p/ySi
RrwOrsGfg8xClfj3KESu4S5Hfv4vKI3biZK5PcjPFaLKb1u3/6kf6NcIv/DfXYp/f/79+ffn3x/6
4W4X/+8P8cMfnjx/cz3olBi/CG0jEo+iVDE+CR3j5OjW8+UHvt6VgBiT37YcvANh7m1YzZ9dvg0w
hwC+bT7cKnQ5YNs58XF0GWDbP0v3rcqaj66eGFZGAaVU/p/48F/R/ylFZkJe2U1oAfc8CvEfoYWA
Flk7SuRfB1mAdvKDKB+kuLaD9XAd4FHAesBSQACwGHABoA/QKqarQkthTeniL0Hz+A2ok38YRfhl
qJc/glbz9SgT+kijWIa70UzAPsBiwEJACWApoBcwHyD6SeeUL/lbly/rfOUDv6wOfwE+RD9q5B5B
FdxvUZi7H/rI22gudz3K4d6l5WMf7iU0Bz+JegAd/yvXcneiIvx3lM21olKuHqVzDcjK1cI1LSiL
K0KJ3BzqP3/rdAOjk37r/48P9JP5IO6lB8782uOP3MIJx4v04BvPcxwaP2SzxOPu8x1ymXS0TjpO
jR+KxV9zvEUO5VX0UM2dcPyYHurmrzne+vfxdYdm39cd2oh28NxDVy8dH5576Ff97z0MXec53iKH
cc43Hp+SQ8gbP0w20/0TD3Pe1xzPm5+3LLK8SQ/r9889bP7/0vHY+Q77EkfZ2PGCM3fsuOHfx7+P
/0eP18nh6jnruB6ON1xnvt3hDk04ar/muNb99n/t8DzzXzsS+r7N4TV5Tb7C/8XjQ/+9gYpgfvB0
4mOJR0KzQ/P/rz32L/0NuUMjqwQ/RA5rDB5xSECZaDFCpuuSBAiR+zdK1EX+R0KZGvhG4r6IHKME
CFHOIQO6TuI8ykN3SVwGaV6WuBzZ0ccSV6AELEOzxP9NbQMKSN+9gCVoDVoN+QbQFun/Wls2dn4j
lGuV9L/U9QKWo5XoQvHsavF/SOuF8EpIswhlQGw1pAuI/68dyW0TpFiMgqgCvN8WVCd+x1CVeM1y
tFDMrRVSLIWUK8XcZ0IOtajkG68oQVlwZMPvZYnHN6WdDbmT/0FvuVjDgHTVN12BxP8NEj6jTvL/
UZ77GVTzgSHuskNqJ24AspuRSxm5hJFdjFzMyE5GLmJkByPbGdnGyIWMbGVkCyObGdnEyEZGNjCy
jpG1jKxhZDUjqxhZycgFjKxgZDkjyxhZysgSRhYzsoiRPkYWMtLLSA8jCxiZz0g3I/MYmctIFyOd
jHQwMoeR2Yy0MzKLkTZGWhlpYWQmIzMYmc5IMyNNjDQy0sBIPSN1jExjpJaRGkaqGalipJKRCkbi
jJQzUsbIVEZKGZnCSAkjxYwUMVLISAEj+YzkMZLLSA4j2YxkMZLJSAYj6YykMRJjJJWRFEaSGYky
EmEkzEgSIyFGEhkJMhJgxM+IjxEvIwmMeBhxM+JixMmIgxE7IzZGrIxYGDEzYmJEYMTIiIERPSM6
RrSMaBhRM6JiRMmIghE5IzJGeEY4RjAjSCJ4lJERRoYZ+YqRM4ycZuRLRr5g5B+MfM7I3xn5jJG/
MfJXRj5l5BNG/sLIx4ycYuQjRv7MyIeMfMDI+4y8x8ifGPkjI39g5PeM/Ccj7zLyDiNvM/IWI28y
8jtGfsvIbxh5g5FfM/I6I68x8iojrzDyK0ZeZuSXjLzEyIuMvMDISUZ+wcjzjPyckecY+RkjzzLy
U0Z+wsgJRv6DkR8z8gwjxxl5mpEfMfIUI08ycoyRJxg5ysgQI0cYeZyRw4wcYuQgI4OMDDDSz8hj
jDzKyCOMPMzIAUYeYuSHjDzIyAOM3M/IDxi5j5HvM/I9Ru5l5B5G7mbkLkbuZOQORm5n5DZG9jPy
XUZuZeQWRm5m5CZGbmTkBkauZ+Q6Rq5l5DuM7GPkGkauZmQvI1cxciUjVzCyh5HLGWFuD2ZuD2Zu
D2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD2ZuD17PCPN/MPN/MPN/
MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/
MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MPN/MHN7MHN7MHN7MPN2MPN2MPN2MPN2MPN2MPN2
MPN2MPN2MPN2cNVBQsBrHvSV+cFnHvTZQFxKQ5cM+kpA7KKhi6nYOejTgbiIhnZQsZ2KbVRcOOit
ALF10FsFYgsVm6nYRM9tpKENVKynkesGvZUg1lKxhorVNMkqKlZSccFgQg2IFVQsp2IZFUupWDKY
UA1iMQ0toqKPioVU9FLRQ8UCKubT67ppaB4Vc6nooqKTig4q5lAxm4p2KmZR0UZFKxUtVMykYgYV
06lopqKJikYqGgY99SDqqagb9DSAmEZF7aCnEUTNoKcJRDUVVVRU0nMV9Lo4FeX0ujIqplJRSlNO
oaKEXl5MRREVhVQUUJFPM8ujIpfmkkNFNhVZNLNMKjLodelUpFERoyKVihQqkqmI0qwjVIRpnklU
hKhIpFkHqQjQ6/xU+KjwUpFAhYcK96B7OggXFc5B9wwQDirsNNJGhZVGWqgwU2Gi5wQqjDTSQIWe
Ch09p6VCQ4WanlNRoaRCMeiaCUI+6GoBIaOCp5EcDWEqkCjwKBUjYhI8TENfUXGGitP03Jc09AUV
/6Dicyr+PuicBeKzQWcbiL/R0F+p+JSKT+i5v9DQx1ScouIjeu7PVHxIIz+g4n0q3qPiTzTJH2no
DzT0exr6TyrepeIdeu5tKt6ikW9S8TsqfkvFb2iSN2jo11S8PuiYA+K1QcdsEK9S8QqN/BUVL1Px
SypeoklepOIFGnmSil9Q8TwVP6dJnqPiZzTyWSp+SsVPqDhBxX/QlD+moWeoOE7F0/Tcj6h4ikY+
ScUxKp6g4igVQzTlERp6nIrDVByi4uCgvRzE4KB9LogBKvqpeIyKR6l4hIqHqThAxUODdrDX+Ic0
lwepeICeu5+KH1BxHxXfp+J7VNxLxT1U3E0zu4vmcicVd9Bzt1NxGxX7qfguveBWGrqFipupuIme
u5HmcgMV19Nz11FxLRXfoWIfFdfQlFfT0F4qrqLiSiquoGLPoK0XxOWDtoUgLqNi96BtCYhLqbhk
0NYOYtegDYwxvnjQVgBiJxUX0ct30Ou2U7Ft0LYIxIX08q1UbKFiMxWbqNhIxQaa9Xp6+Toq1g7a
+kCsoZmtpilXUbGSiguoWEHFcnrdMiqW0pItoZcvpmIRTdlHxUIqeqnooWIBFfNppbtpyeZRMZdW
uotm3Ul/qIOKObS4s+kPtdNcZlHRRkUrFS2D1jiImYNW8gszBq2ke08ftO4G0TxoTQfRRJM0UtEw
aAW/ANfTUB0V02hk7aB1J4iaQesVIKoHrReDqBq07gJROWiuBVFBRZyKcirKBs0wv+OpNFQ6aOoE
MYWKkkET6RrFVBQNmqaBKBw0dYAoGDR1gcin5/KoyB00pYHIoSmzB02kYlmDJjI2M6nIoJen019I
oyJGM0ulIoVmlkxFlIoIFeFBE9FSEhUhmmcizTNIMwvQXPxU+Oh1XioSqPBQ4abCNSh0g3AOCvNB
OAaFBSDsVNiosFJhocJMLzDRCwQaaaTCQIWeCh1NqaUpNTRSTYWKCiUVCppSTlPKaCRPBUcFpgLF
R40L/QQjxj7/sHGR/yvgZwCnAV9C3BcQ9w/A54C/Az6D+L8B/grnPoXwJ4C/AD4GnIL4jwB/hnMf
QvgDwPuA9wB/Miz1/9GwzP8HwO8B/wl4F+LeAfk24C3AmxD+HcjfAn4DeAPwa/0F/tf12f7XQL6q
X+l/RR/x/wrwMvBf6mP+lwAvAl6A8ych7hf6Vf7ngf8c+HPAf6Zf4X9Wv9z/U/0y/0/0S/0n4Nr/
gPx+DHgGEB89Dt9PA34EeEq3zv+kbr3/mG6D/wndRv9RwBDgCMQ/DjgM5w7BuYMQNwgYAPQDHtNe
6H9Uu83/iHaH/2HtRf4D2p3+hwA/BDwIeABwP+AH2nT/fSC/D/geXHMvyHu0F/jvBn4X8DsBdwC/
HfK6DfLaD3l9F+JuBdwCuBlwE+BGwA1w3fWQ33Wa6f5rNTP839Es9e/T/MB/jeYB/+V82H8ZX+Tf
jYv8l7bvar/kwK72i9svat954KJ27UVYe5HnosaLtl904KLfXhQ3KzQ72re1bz+wrf3C9i3tWw9s
aX+C24OWcJfHS9s3H9jULttk3bRxE//ZJnxgE67ehLM2YQ5tEjYFNvG6je3r2zccWN+O1s9cv2t9
/3rZlP7176zn0HpM/lOkg+s9vlryhuGO9Xqhdl37mva1B9a0r16yqn0FFHB50dL2ZQeWti8pWtS+
+MCi9r6ihe29RT3tC4q62+cf6G6fV9TVPvdAV3tnUUf7HEg/u2hWe/uBWe1tRS3trQda2mcUTW+f
DvHNRY3tTQca2xuK6trrD9S1Tyuqba+ByqMEISGQwAukANMToCTIgyuzPHHPO55PPDLk6fcc9/Bm
o9vv5lKMLlw1w4XXuC52Xevijc4XnVzcmZJWa3S86Hjb8ReHzBJ3pGTUIrtgD9h58SUve/OsWlGW
V1OZnS/WtdkeitQabdho89u4Gr8NI9M7pk9MvO1p4UWBMxqx0Thq5OJGSG40+A0c+Ro18HFDdmGt
Ue/Xc+RrVM/b43qIITlGdTNn1Rq1fi3XXq6doeXi2vKq2rg2PasW8TiAMcICCF5FSoFt/loY1wft
WI5hPh+Y1RaLNQ6pUGtjv2rm3H58ZX+4jXzHW7r6FVf2o/auuR0DGH+ncwBzVbP6rY0tXTR8+b59
qNLb2O9t6+i/x9vZ2L8LSJyQUSDIO2BHlZ2x+Rs2bYjFNs6Hr/kbNsbEfxDCm0goRiLJvw0bIUyO
TWJ47I8vnP9Dk4FYsAE+G1nkxm++6v/2D/7vLsD//M8Agi7aUTHKXYYWcbsBlwIuAewCXAzYCbgI
sAOwHbANcCFgK2ALYDNgE2AjYANgHWAtYA1gNWAVYCXgAsAKwHLAMsBSwBLAYsAiQB9gIaAX0ANY
AJgP6AbMA8wFdAE6AR2AOYDZgHbALEAboBXQApgJmAGYDmgGNAEaAQ2AekAdYBqgFlADqAZUASoB
FYA4oBxQBpgKKAVMAZQAigFFgEJAASAfkAfIBeQAsgFZgExABiAdkAaIAVIBKYBkQBQQAYQBSYAQ
IBEQBAQAfoAP4AUkADwAN8AFcAIcADvABrACLAAzwAQQAEaAAaAH6ABagAagBqgASoACIAfIKkbh
mwdwAAxAaBGGODwCGAZ8BTgDOA34EvAF4B+AzwF/B3wG+Bvgr4BPAZ8A/gL4GHAK8BHgz4APAR8A
3ge8B/gT4I+APwB+D/hPwLuAdwBvA94CvAn4HeC3gN8A3gD8GvA64DXAq4BXAL8CvAz4JeAlwIuA
FwAnAb8APA/4OeA5wM8AzwJ+CvgJ4ATgPwA/BjwDOA54GvAjwFOAJwHHAE8AjgKGAEcAjwMOAw4B
DgIGAQOAfsBjgEcBjwAeBhwAPAT4IeBBwAOA+wE/ANwH+D7ge4B7AfcA7gbcBbgTcAfgdsBtgP2A
7wJuBdwCuBlwE+BGwA2A6wHXAa4FfAewD3AN4GrAXsBVgCsBVwD2AC5Hiyp2YRj/GMY/hvGPYfxj
GP8Yxj+G8Y9h/GMY/xjGP4bxj2H8Yxj/GMY/hvGPYfxjGP8Yxj9eDwAbgMEGYLABGGwABhuAwQZg
sAEYbAAGG4DBBmCwARhsAAYbgMEGYLABGGwABhuAwQZgsAEYbAAGG4DBBmCwARhsAAYbgMEGYLAB
GGwABhuAwQZgsAEYbACG8Y9h/GMY/xjGPoaxj2HsYxj7GMY+hrGPYexjGPsYxj6Gsf/fbYf/h386
/7sL8D/841ww//8DutsFKg0KZW5kc3RyZWFtDQplbmRvYmoNCjEzIDAgb2JqDQpbIDIyNiAzMjYg
MCA0OTggMCAwIDAgMCAzMDMgMzAzIDAgMCAyNTAgMzA2IDI1MiAzODYgNTA3IDUwNyA1MDcgNTA3
IDUwNyA1MDcgNTA3IDUwNyA1MDcgMCAyNjggMCAwIDQ5OCAwIDQ2MyA4OTQgNTc5IDU0NCA1MzMg
NjE1IDQ4OCA0NTkgMCA2MjMgMjUyIDMxOSAwIDQyMCAwIDY0NiA2NjIgNTE3IDAgNTQzIDQ1OSA0
ODcgNjQyIDAgODkwIDAgMCAwIDAgMCAwIDAgMCAwIDQ3OSA1MjUgNDIzIDUyNSA0OTggMzA1IDQ3
MSA1MjUgMjMwIDAgNDU1IDIzMCA3OTkgNTI1IDUyNyA1MjUgNTI1IDM0OSAzOTEgMzM1IDUyNSA0
NTIgNzE1IDQzMyA0NTMgMzk1XQ0KZW5kb2JqDQoxNCAwIG9iag0KPDwvQ29udGVudHMgMTUgMCBS
IC9NZWRpYUJveFsgMCAwIDk2MCA1NDBdL1BhcmVudCAyIDAgUiAvUmVzb3VyY2VzPDwvRm9udDw8
L0YxIDYgMCBSIC9GMiAxMCAwIFIgL0YzIDE2IDAgUiA+Pj4+L1R5cGUvUGFnZT4+DQplbmRvYmoN
CjE1IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE5NjQ+PnN0cmVhbQ0KeJy9
WVmP3DYSftev4KMUYGjexyLZxXjsBAmCJAs34IcgD51utaWNIsXqHs/6329VkeqWfGUzLedhjhKL
H+tmkXxdCCa4EEIqJTyLTjBrBBvr4uUXRV9I9mpiEE4Kbecchy+KfxevizQqjRaWifcQnm4AAEG+
KSRXNrKH4snXkhnDhTNscygU24yFDtwBabzgLrLNvvi5vKt8ua1C2cMPq6Shf+pKqvKhkjp9elbJ
WG4qV35f2fJFFdPXW5h5hI/4M8DPDia28HeL3CfgbGkgAmICkuWvhO3T/GMlPfABM64/wgQgHIzH
co/MNKOtdHlg+B3lwmUQmVW/sM13xfPNX7dM0DPTvG8Zpbk0yTJjJVFaV76upCjv8RfKdkzqXSQV
KKkmSbMRJQnZVGk6jaLkBwQ8VNrSzBHs8K/H6fHka82Uy+I7y6V2TAfFrSTJvxQi+H8+ElldkIN+
F7n84cdK+XLz/B+sMuUPqN0Dg1/PQJfN9y8Y/Lk9HqsbVQ67dgtKntqhZ/C3PeKEfjixY0XWU+V2
PMHMeo/DD+2pYd/eVTe6fI6MI5qsnrOy9oDoiFBj8Pz3j67dtSec0b19ZDh8UFnrubXnAAApXt+D
ICEJUu+vc5hbeEwp7vRaHnMLLS7Q5ctmSxGJdj3u6n47tgOjdIXEA+fY8g9SdNjf72pG5mb9+54N
5fZ4JK9CwCe3Yqrb8nACoHpEoOGA0w+VMvDhCUb7tj/C9wcUoIZ/xhU9paLnLnsqhUSldLlrtv0r
TDwqMQ9NTRr2uPi7kTrpE7I6Zhal77g+kPR7GCTYtmenpmYD0Ac0R9b4r2Yzt9qjgvQ3KSnP9Tr4
yD1oLbhWIWmpHm88aXl0CGsFzItMOsFN3gFuj7+RYjdUoWI5jIkERX88oIPxYz2usLiJljvPpIbt
JxeUxQqPLuyLVWCW1WDDXWG14t4u1jt1xzWsaAKXcgF8swas1VzoBWyLxXT/lbwCPZDpreIKkib9
IejnPdTem1D+hNE7tBj5uAez22vXshE2WgNrgRp5Lf0TwN/dXYvsvOZeL5A/psXT5Vq0+1sHe//P
DoUz3AX2C6y7L0wwHBLNOB7Z70DBbheYjWAnxbrixZ/Od0LxiOpabhQgZBoQtA7/F4KHLAcFJxG8
ktiEYI4KlwHQFigofFcK5A3AZ6ECxonszqTCutFduDPdAIMjhsDtJCZQGqhuGpOBqKY4XFVhoIQp
LbnRf0uSeyqUs/VWSnLMxrAAXifJl5gfyPApomAOWBICQjruJ7I7kwbF6y7cmW6AwRJD5MHleEr8
wdF0GhUxkdf42knPjaUggi3s8/vaWYPd2Xy9dXztXORRLoDX8LXzYHO9gP2guyUH/WQQWBewBHks
QZnuzrQPWDK6M/9EN8AR0gzDjbsUMQk9hHGEkMa9STT6nKoMTHE8GCoHPglBdHehbaouE3smG2AI
iSFilUr1JANQ1TqP60RfFWcKloXGAYqUzGlz26/h93loQZ0MiyXWCq1A1XwGvE5okV3nsDm01mkT
DTbXMsJ0+XkMjs2ZXC6xVnPm8bw6B16nbius2XPYFQxObY2HrBKpYZp8+bG2Zt5CBdj5HIPUFoHy
D9oKyyD9rPSUfw5bPSgJ0SJN3JLGVU5gz5VmoI83qQJImgC7AzShqQKoyEIaPyfwJ/qYoKFrwlZK
8ogiZRp7KR9zI+ME1ELIM7CmSMUucqcmurvQcEBJxS7zZxqKHUhMHKTf79ToEE3id+dx4xKNck88
eC421DoFQk10d6Fl2kPP/HLaU7G7Ig6XNtVJLuCgbXQal26FbRXqNsSYhKonw9+wrWJDgYfC2Xrr
pKLHPscugNdIRa8d7qdz2I93URKmpWCEfjhmsruQJm2yZ+5MN8ChiQOac6FyNGcAoQghjUuR6Ed6
PKQ7IUg7SCo4IJvoViq4CRmmGZvdrDHH5mtc7ea0hoczxRL4SjdnWLCwVgvcdo+O/kov/Cww0T1s
J4rKAVS4THUTJdC43Zk1k01qrZh32KngVIkUdVe57WLOJeq6IxH1RIAeQvhcuymc48xiifWuOuIC
d62bjqAWsDmD9WPRoc2moIlwDLJ40yGxn1vjdpVgpVTowxlsuWnaEd8BcKfWuFPTTfVbJPCq8W6L
GnUdPQjcDT1dnI54fzh0aykJBwu/vo5nVApTur8VuO/gDfiISrF9u2c93n/ihT58PiEHXtPjXf/p
mlteEuQGSyrFtbZUj2ci3VwRfwld4zFoDvl0ODVXyZykvRhQXO6nbumeHLq5O7xzPjVt/xurdAkr
wu96ZMd2XyNL27enNt3Uk7X3VxsxCyM9dompIjQ1m26909vMSnEoTcQ+au1AnMFSQwwpJqEZ7ini
GFl26Lu3bF9jJJLZdph9p2OyNWm5mh2h88t27Gvw3QN7ht7CxwSwKbp0/uQV8DGhr2sQDQS6zpnv
RJeEztNmSeiBAx9ZQn5kGVlLylOdQWtAyrZvaOiat6u5sz1sx3n9NZ09g8XKihaluorPyumdatsd
B8ydX2s27Hb341Ro9/dj279ay894zJNZDlx76Pt6Nz14TWbFh21fvpkqoi/fLlaH84+CA5JgVMh0
DOcnf2wVJynoKMX+8wk2PDD9D+keyesNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNiAwIG9iag0KPDwv
QmFzZUZvbnQvQVNKSEVWK0FyaWFsTVQvRGVzY2VuZGFudEZvbnRzIDE3IDAgUiAvRW5jb2Rpbmcv
SWRlbnRpdHktSC9TdWJ0eXBlL1R5cGUwL1RvVW5pY29kZSAyMyAwIFIgL1R5cGUvRm9udD4+DQpl
bmRvYmoNCjE3IDAgb2JqDQpbIDE4IDAgUiBdDQplbmRvYmoNCjE4IDAgb2JqDQo8PC9CYXNlRm9u
dC9BU0pIRVYrQXJpYWxNVC9DSURTeXN0ZW1JbmZvIDE5IDAgUiAvQ0lEVG9HSURNYXAvSWRlbnRp
dHkvRFcgMTAwMC9Gb250RGVzY3JpcHRvciAyMCAwIFIgL1N1YnR5cGUvQ0lERm9udFR5cGUyL1R5
cGUvRm9udC9XIDIyIDAgUiA+Pg0KZW5kb2JqDQoxOSAwIG9iag0KPDwvT3JkZXJpbmcoSWRlbnRp
dHkpL1JlZ2lzdHJ5KEFkb2JlKS9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQoyMCAwIG9iag0KPDwv
QXNjZW50IDkwNS9BdmdXaWR0aCA0NDEvQ2FwSGVpZ2h0IDcyOC9EZXNjZW50IC0yMTAvRmxhZ3Mg
MzIvRm9udEJCb3hbIC02NjUgLTIxMCAyMDAwIDcyOF0vRm9udEZpbGUyIDIxIDAgUiAvRm9udE5h
bWUvQVNKSEVWK0FyaWFsTVQvRm9udFdlaWdodCA0MDAvSXRhbGljQW5nbGUgMC9MZWFkaW5nIDMz
L01heFdpZHRoIDI2NjUvU3RlbVYgNDQvVHlwZS9Gb250RGVzY3JpcHRvci9YSGVpZ2h0IDI1MD4+
DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUxMDMvTGVu
Z3RoMSA4NTA0Pj5zdHJlYW0NCnic7Vh7eFTVtV977zOPvIcASSCTzJkMGSSTEAggENJk8piARiSB
ADM0SEKIJAgmkiCgCEMVxVGEepEKraK2VapXOZkgnQC9oLS2Iq+q1ZZaQaUX7VcK9rtqfeXc3z4z
ieTW6+13v/vH/e53z57fWmuvtfZr7XX2nHOIEVEiBUmQd9acwiJb0R1PQ3McaGy+tUt9+u63biZi
+UTmBTd2LF3x8qEzJiLLZuCFpcvX3ug+Pn8HUcp18I+0tjQtuXDtr98nsimoX90KReqEuDrUS1Af
1bqia82Ym0xZqDcScXV5e3NT8vphHxGlBjFG6oqmNR2mnsSZREO3w1+9uWlFi71s0hHU98F+W0d7
Z5eeRxhv+Dhp71jZ0rHFebEc9VqihAskxGa2jUxkNe0yTUCLzCgXv6YbearVxBPMCpeXco7y9CO0
phK9xAFUP7NSJS851RzTa311bIKllIW9xHRdJ1LcpoNyNBpuOkAjgJGmp2iE4qYMIv0C8L7kfW36
+9IuOf+TjEYMRHvoWdZGz9JhepFdRqu91Ev76FeUTlX0A1pH2+keMtMCaO6l2Sgm6LezEfo+KqTH
sS+P0wn4zqf1dIDSWIb+AW2gTeI1tNpESZRD5VRL7bSFXaevogY6q9xJk+k6upk6WFD36w/oD+o/
oh9Tr/iV/iUl0EhqRjmh/8X0W/0tKkCLh2gnnWUPxj2PCMxHJvSKR2gl7RILFaYv1T/DDJy0GnNQ
aCadYEe4B7230AWWwdaJSvTyQ13Tfw4vOy2kVtpFB9gkNp07TQ36TP0EpWGMNeh1J4VpP0qEfkZn
WKLpsv4j/TKNoHy6BuvZRyfZEdH35ca+MkTMhCiNoamwtNO/0C/pNHOxF3i7KdFUZPKabtNfp2E0
nuZitk+h5b+yT/h6lA3iJaVar6BkxOW7Mtr0C3qHjWSFbBabx8fwdv6oWElWjDgeZQm1Id4Po/e3
mYft54n8lPih8ozyuTmr75yejB1x0/fpEXqBJWGlKutk32FvsPd4JV/Ev8/fFduVnyivWpqw6hto
BW2hZ+gTlsqmsDr2bdbK1rF72HfZTnaCnWbv83Jez2/il0SruEX8TKlAmaN0Knea7jbdZ36/z9/3
875f932iF+l3Ux3yYSNm/xA9ipX10in6HcpZepeZWAJLRlGZk81lt6OsZ1vYE2wP+wnbh1FOs3fZ
B+yv7CP2OScUM8/kTp6D4uIr+Wq+nf+An0I5zf/MPxXpIkd4xCRRIgKiHbO6R2xDeV68o4xUTik6
4lxk2mHabdpjesb0oumyOdHyHStZj3/xwy/zvny7j/o29+3oC/ft09+h4djDkYiCg0ow+yaUZdjv
Hci4vfQaS0TsRrI8VsquQ2QWsWXsFrYGkbyL7WI/Nub+HDuEKL3JLmHOSdxuzHksn8Qr+CyUG3gL
v4Vv4w/yffwN/pmwiASRIoaLPDFdLBQtokusFTuEJo6LP4h3xcfiCxRdiVccSo7iVjzKdGWRskp5
VLmgXDA1mF4x/dEcb15hvtscMX9oudpSaqm11FkWWrZa9ltetzYiO4/S8/RTuuJi58RG4RPP0wN8
gjKCn+Qnkc+LaImYyZGpfA/bzO9g+/go0xrzND6NXU+XFTdi/RLfzT/m08RMVsPm0DI+PtqbeZgi
T9cS5ShdVA5hbSfR8xpzIlvPL5kTKcyIT8WYvxDjFI94hc6Is8yiPE6/V+JZOrvInxK1yIKfKaUm
PznFD+g5cQu7g57nPqL4z633I4+vZ0/jXKhnRexvQifBr0cWTRbv0Z10E/8tXcR9vJm+x5YoS+kB
msDW0QV6EnfFGNPN5jzzcPYyb1NCfCjbR1z5CVY3lY1iwjSM7mILxS7zJf47WkWnlHh6W/wzZn+K
PydmKpdNs1kr7oA76G66Rd9Ia01+5VW2lASbR7k4aLfTOlGkOME34FRpwJm2H3f3AZwD5WImNBnI
nOuQF3NxQuxCeRjnhIIMasM9Ph+n2EnaZ67nEVpqSmY4dXAev9I3mxboT9JOfSndrD9IBTgP7tHX
occ99EfaSnvYpr7bqYOycee8za4zVfNTpmq9gIf47/gcvmPw/iLauSyD/oTyHCqlOOtDyps0h8r0
+/XfILuvwgm7kxbTtXQeq/wLRpghjtCEvut5t14tOrDes1SnP6U7WDy16stpFh2iH1tM1GTxYI81
9irWezu18Nl6l2jpa0MctiIKXkRrFc6fe5VblDuVT4m81f758+bWl3vLSr9VMq146pTJkyZOKBo/
rnBsQb4nb8xVo925o1w5TtWRnWXPHDkiIz1t+LChqUNsKclJiQnxcVaL2aQIzijf56puVDV3o6a4
XTNmFMi6qwmKpisUjZoKVfVgH01tNNzUwZ5eeN74Hzy9UU/vgCezqSVUUpCv+lyqdqLKpUbYgjo/
5C1VroCqXTTkmYa8zZCTIDudaKD6MlqrVI01qj6t+tbWkK+xCt11J8RXuipb4gvyqTs+AWICJC3d
1dHN0kuZIfB0X3E3J2sSJqWNdFX5tBGuKjkDTeT6mpZotXV+X1Wm0xkoyNdYZbNrsUauCi3FY7hQ
pTGMZq7ULMYwaptcDd2nducfCd0fsdHiRk/iEteSpga/JpoCcowhHoxbpaXfdj7jqyo6T63033Ol
NVOEfBltqqyGQveo2mN1/iutTkkDAfSBtjy3ujFUjaHvRxBr5qgYjW8K+DW2CUOqciVyVdH1tbh8
UtO4TNXiXBWu1tCyRmzNyJBGs9c6wyNHenv1czTSp4bq/S6nVpbpCjRV2buHUWj22p4RXnXEYEtB
frdtSDSw3ckpMSEx6UqhZcBmSIa7lGpmD0SWyRm5rkFCaGqzipn4XVjTFElaplCoeQrccAUYWmlL
sCNtWlxlY8hWLPWyvWbKtbnU0EeEDHBd/PNgTVNMY861fURSlHkykGqw98uax6Pl5ckUsVRiTzHH
UqM+qSD/1gh3uTpsKhjCR7WIbVOguBDhdzrlBt8X8dJiVLRgnT9aV2lxZpi8hZ6Axhul5Ui/Zfhc
aQn2WwaaN7qQyftIPkkP16zugV+KLW2or7VYY2nfYG6J2mvmuGrqFvhVX6gxFtua+kG1qH3KgC0m
aUMr/SKTxySeKQwrkrJhwFlW/Imakouf2UjqJRGLFVlpaJhardkaZ0RpIN7p/AcbRfTLspXBvmoW
m6ZW7BlcnzaoPmh6iSGBCeNfs6Z+QSgUP8iGVIsOeE2MIeOp3u9UKzWaizszF7+IfmSKRCBT8yJk
ldIB+RdVxaqDHDNjcgCXzM6C/GocdKFQtUutDjWGmiJ6cLFLtblCvfxF/mKow9fYnzgR/cB9mVr1
/QHEqpUV46bgVNHtYpvrur1s85wF/l4bXhQ21/vDnPHKxopA9yjY/L0qzndDy6VWKmVFlRWqYVhk
mFsN/8xeL1HQsCqGwqg3RxgZOmu/jlFzhEd1tuhAbmMgL578miNK1OLt91ags0Z1waj3VTFvKyw2
aTlA+O8gwxi95OFUWe+/Mu2Me1ka5nv8iTxUMwebJo3xUzLjrzCrsqHGXNoi1xpnN/rU5rnWOqF0
aSoOODh103R7IBRSUVwYvnmeP0qlieXb0VNACy7u9820B1xXVBPR1NiKHru87QZGu71/tJUYTQqh
/uG05q8dDbPX2LclNX7G9LuvJld0fPyxRQcNNYQWuJw4N7PkwLF5oJpsDxg9YCYPy5nIRwkZQ7y8
4AVZkIUq9nF23myJ8J3eoWRSzguKtyjnGY2wmk3nuTiEh8I4vCKMpQyP7eOSL0uut/1bycwvS6gM
su0LkPHjnEOcQ3JBGPbwC1Uc+cJros9JVfBKzGgFO81b8ZSYQI5ePG7N8SbHmY+rNA45sCpx/lOy
14UXqfDi+HFDJ149oQgPDGZXjnvFQ61tDz3U1voQP9m2fXsbZDKOJvN7b0bOPPLkopSSj6wJVuPJ
6In3RudJ/ur2deM/2/vlUhtZ64w3Ztb/6ERkKe27nipt9Nnez26z0YCl/9psjqnkc22Ma/xNvDP9
L7hMv8Rb1n9xmZ/GE+nft3v8f2J8pZOq/zvt+NN4w/0/cPETeKImuvr/yxWlwfyIcctspkm4kY0w
kQ1vTQHky+GEC7HQWWgBzhhS5NerLqKYzPAe3hWTOSXTtpgsaCIyPSor8Hk1JpsoDW80UdlMdqZQ
PbXizauT1BhtAm6kdryHdUFabVibQfvtXdSCPeyAx0r4roR2Oa01rDfD3gXdcpQWWkJjoa2CnwpL
u9HbKni0kJPK8bZ1Lc0gH80jD2qyF9luJmYzGx5L4bnc6L0WPVRT8Te2KMYBOI7GY7xxRvkm33no
fSVm0WasUI21+qYWRqTlpY+W3yH//ipPpHqRLwvPoSxyCI/IoxLwvLA5yxERV/W4MxynD4kxdA7g
YkzYk+XoFaNFVniawxsRrp7U4UUp5QVCxW4WGlQFbQf2AocBhRaJbOhtoBuAILAXOAycBsyYZLZh
VYF2YDdwTlpElrCHVYetfLQYgbYjkCUpIp0uATogMM90jJpOs4BFwFZgN2A2/KSmHdgAHAYuGxav
SA8/OAFzTw/fZ7CeZcuLjGpTtNqw0Kj2zA9E+cy6KK+6JupWHHUbPzGqHlsR5aPzozw1tygoeXxS
0ZHyNJGGRaZh4h2gjP+cUhgjBz0mhpMGcGGOabwitWeUu2j3YaEQE1wwJKFDPyJYOGlIUXk81/kl
SiUH/wu/GLXwiz3JQ4p2l1/L36W9wGFA8HdR3uHv0AZ+TsYctAzYDRwGTgGXADM/h3IW5W3+NqXw
P1AhUAYsAnYDh4FLgIX/AdTG35J3uUGlXAZw/haojf8ey/o9aAo/A+kMP4OpvRaePLWo1xA8hTHB
kRsT0jNjQmpaUYS/Gv50DDLKjZ1GRh0UOVRKE0ROOHc80i8jXNLmiPD3elSP47Hycfx1/Bu/Ls8Z
UBugArVAI9ABmCG9AekNCgLbgMcADUCWgdoAlR8DjgNv0DjAC9QCVn46jGEi/FTYXeEoT+Mn+S8p
HRE/wX9l8OP8JYO/wn9h8JfBs8GP8ZfC2Q4qT4Cd0MYGbgMvhN3EX+gZlerQy4fww4idA7QQKANm
AYuArYCZH+Y54SWOVHRykI7hecbBw/SBwZ+kJ6zkXebwuiuRgKok7uJvQQLZre52c697x05UJXE/
8CAkSdx33Q9JEvdtGyFJ4l5+KyRJ3EuWQZLEvWARJEncs+ohgUT4oz8dNdoxedZNTC1P4asRpdWI
0mpEaTUpfLUs9Kki5/b9cF4eIrbL6xmT5wgeYMFDLDibBZ9gwRYWXM+CG1mwhAVvYEEPC9pZMJsF
vSx4kE1BKILMu29Qdao3gwWPseCzLNjJgm4WzGXBUSyossneCHeGr5lgMJ/BesrlTQf+rVKcPinc
iYg6kfNOnAmHQU8BulHzwknNiTqPyJY8pyevLFofW1zUjtvnKBoexTYcpbOAgg06ijQ6ik6OooMU
0DJgEXAEuATogBneOZj4VoOmgBYCZcAiYANwCTAb07kEcGqPTXGvMTE56cLYxGcBCj+KIj+AO7nT
m2Wz2zy2GWKrnaVks1nZejafTGlpOLFTh1iHRFjS/k+S/vZJEsWVx/EH+FZ5dPNtMb41/CmObvZw
2H3QUT6cfY+yFWQem0pulgs+hTqN+iSyWyWfSHb+DHhR2D4PzVLC7nzHAZYsW+13fGo/7/jAHuEQ
37cfdLypRhQWdvwGmmf2O1633+t4uTBiheaQO8LADqiGa699iuPZY4brRhh2hR3rJdvvuMM+3XGT
3TC0RA03dKLmTXHMdi9wzEB/VfbFDm8n+tzvKLPf4CiJek2SbfY7xmEKnqiYh8mOsRuDurKNDudO
jrBWb75lh8VvmWW52lJkybc4LQ5LliXTMsyaarVZk62J1nir1Wq2KlZuJeuwiH7O65FvAcPMNsnM
iqSKIdu4pPKRRh58zMrxJ6sNFTW8Zk4Fq9GONFPNYlX7eI4rwuLrFmgmVwXTUmuopr5Cm+KpiVj0
2dpkT41mqf22v5uxBwLQanwzXo3r/RGmS9WmTPkxrpcYG7JpS6bkV23aEghQRtqtZRllqaVDplZX
fQ1pjFHPV1fGIDlL21Ezx689nRXQiqSgZwVqtH+SX+t62V/ZZV9VL/tQsoC/V5Syv/pmS70orQoE
aiJsnuFHKvsQfsiYDw0/K/6cpR+p1uyo366oXy7aw2+UZPCLi6Ncwy83Ls7wU5j06+4c5avqHjXK
8ElXqdPw6UxXr/Q5lguf3FzDJy1IxwyfY2lB6aOVGi52O1yy7YYLG0l2w8XORhou875yKYy53Dvg
cq8xkmBf+dijPknn+n2SzsHH849eLRUeD+uZFmhukF86G12+FqBRu+/W1gz51q12Nwdin0DdjYub
WyVvatECrpYqrdlVpXZPa/gac4M0T3NVdVODr97f3eBtqQpP807zuZqqAj3TaydOHjTWvQNjTaz9
ms5qZWcT5VjTJ3+NebI0T5djTZZjTZZjTfdON8YiI8dr/d1WqghUNkR5D0+IR742ZjoDFWm2jlIj
eac5M9ZnHsATyx5K8AS0RFeFlgRIU0F5Qbk04Z6SpmT5OTtmylg/zZl5gO2JmWxQD3FVkKdrVecq
yvC1VUV/nbig6lolAx6lns7/7ILNp3mbqjrxflGj5c2p0crqFvi7LRZoG+WStOJ+XUKCL6IfiSrH
QlkslUIMOEpdidTFxcUc/37/V8V4pbwLgvxgD/Nmsy7qDAgtu6ae4yioj303PIDnKfkX0RnAAjuZ
h3X29xGbtsdD0TrJNfeja1VMisWiK8ajLdGksz8kA5cMlmcgYl1Gt0Y4PfTvXeMA1A0KZW5kc3Ry
ZWFtDQplbmRvYmoNCjIyIDAgb2JqDQpbIDBbIDc1MF0gMTM1WyAzNTBdXQ0KZW5kb2JqDQoyMyAw
IG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjY+PnN0cmVhbQ0KeJxdkMFqwzAM
hu9+Ch3bQ3Gay3YIgdEyyGHdWLYHcGwlMyyyUZxD3n6yFzqYwAb5/z/xW/rSXTvyCfQbB9tjgtGT
Y1zCyhZhwMmTOlfgvE17V247m6i0wP22JJw7GoNqGtDvIi6JNzg8uTDgUelXdsieJjh8Xnrp+zXG
b5yRElSqbcHhKINeTLyZGUEX7NQ50X3aTsL8OT62iFCX/vwbxgaHSzQW2dCEqqmkWmiepVqF5P7p
OzWM9stwdj8+iLuu6rq49/fM5e/dQ9mVWfKUHZQgOYInvK8phpipfH4AB/xvJw0KZW5kc3RyZWFt
DQplbmRvYmoNCjI0IDAgb2JqDQo8PC9Db250ZW50cyAyNSAwIFIgL01lZGlhQm94WyAwIDAgOTYw
IDU0MF0vUGFyZW50IDIgMCBSIC9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNiAwIFIgL0YyIDEwIDAg
UiAvRjMgMTYgMCBSID4+Pj4vVHlwZS9QYWdlPj4NCmVuZG9iag0KMjUgMCBvYmoNCjw8L0ZpbHRl
ci9GbGF0ZURlY29kZS9MZW5ndGggMTcyNT4+c3RyZWFtDQp4nMVZ32/bRhJ+51+x97Yszpv9xeXy
0DsgcZJDiwJxYQF5KPrA2pTFCy2lpByj/32/mSUlqkWTq0W3L5GGO5qdH998M3R+zrTQSmttrNWl
qIIWhdeib7L3X2XbzIi7SUEHo10x11h/lX2f/ZylU+OdLoT+nYVXKxggI//NjLJFJR6zF2+N8F7p
4MVqnVmx6rPSKYtnQVVOrG6zH+Tr3ES5yoP8Li/kdf6jWH2bvVktdp8pSlX5kxsvlr+kNMqcXnKd
VxSak1e50VLkxstXeSnrPMobBPsBn3dQ6XNbyR2+PJDuNjdG3j7NvRdvnbCINZBXKcvaKVeyO19r
Hcv/PNGuPdqtkATr55YpSC9X3z2xcifWDfLnTow/sVSnVguv4kk25PXrq9yhKBeA3iPlvB7EY37h
ZN/mXu6pFHvUpNmKdW6t3PVi/4ii7USfGyubethth3+dUSagxzJ6jK6QUOGAH+cWqdTRNBJwalpe
PSDqvai7TgB+rylwFE4g5HdrihnBFrLpX+TOy5fbARFzcpoemSrktrlDh+72LYzUyM6+3eHbVgDV
/UPXDKLFdyd3W/zTiI9dfdOck6J5erxWzi+Tnnlqjmbl9a77RCmA4z197n7qmnuAot1vKMDVpsXj
IG8FoeSKQFH3+19IEJSiyzq/sJLyGuQlMoCW3/fUGLtuqW52mnrvObp5Zlm+QwcU8q7d1h1gwXV/
m9sg67ZDWR84CY24vqFwm23N/bL7s62gCjTi3fiZfDIHQo1lpUo4idrYmJxyZ+TQTLHigiIIW7il
sjhZNsbC97nlES4WcDlARRBEnEytd7njhiLkEExKTACCz4Jhosbw6TnCPFqWb7YUoKmS++2WQt4P
3CKvRI3DSwbQps5NIT8RoYo98LJp8LiUAyfkHsJZzkU/904XNO3Zu4+JrBex7g2ZnVs/ZzLN7EYV
fu818PCpHdrdtgHfgEpApF72+3bd3lD/1Uwvia2Wg4xB38X4HJCZWZbfXL5hfLSDeBiac1ad37qP
9iufpbFnluX7DXYCAi9BH0VBe+sT9IuXDPmeStRw3dpP/P1W1GlaLOeXs2psxKG5IS5hR7Z8k5eY
347mN+7u81jKfwp62u5FtyNHWPcD+Tywx137IXcFdSi3p5VrorBCDqCr/ZItaoxRfkRDPTlp2MnI
Tjo5sIeCFwkM30c8pHWl4m2FJ+0wcAw3bc0cilYROAaolktvhQHkxvxud3t2rBlo76HOq3/q2mGz
JICDV6Z8FsqeWaZhXtIwf0gI/cfT80UTm+tagL1sIUywypt0y0suzwfahta8BfUJ+9bId2iJNT+3
jor+9PsjXe4LqywNX/44TCUCDHoTN9OCssVKg848966C9iVMgUITaafN5ArmLy/PtRyw4ZXuxPIf
RfHq9C5+LwV6HrMfAjnnVYjiR9x7m/noFW28eCcV95CsKqIosFAHK7rs+ou/D9ry0CsK5S0sjDIs
OBf/LwslljgEOLlQWn5LNkETKpMBygU5iudYRRU2vnvkGQvqJHYH0RILd0ftUd5AIbBCVMXkJiQH
qZvOTGRpk62fDHMfS2ykwjq8RhbjsnyKZcHvUC2TME7o9b7pP9LobtMbwb/x3czqN2XYFAq7LxJk
gionsTuI8IDycNAe5Q0UClbAeA1jfpN+DPxzPtVVEin2gE0fbzwmaqrUPccEUIxyd5DLSEXsDvqT
vIFGTL/wyocjrGjE+8AW0nnpk0y3ct3xk6Ci5wKVyQmWu6NcpHpP6qO4gUJkBbSfDmOFRwOMo+k8
miSfU+VgnIol7oog5ZHMMKTOZ8nggOLqxPCXoGLPpZUSOdSJsIz7PK3MKSzC1SBQSB0524HoHcku
TMnZDkS1AEBVkMzahs/tWC68XTuan6VP9Tb8A6BRu7HethIxnR/K9RkeiY7/DGBpCyeXRpm4rKxG
Ign05x0AD4NAJ2hXCkQ3yt1R1rR9dEf9UQa04TFrcHz3TDQss/vd4dyHJJPfkw7IiDu4QHnJapK7
o2xSzx70zdTDxG6sEVITT35Bg9t2Ojdh3sbMBAYNntIBRqxGsTuKPjX1QXuUN9BwrAF61nbM52hA
W7aQzo1OcrpTU9ilVcZyclDvUeomSVP9uoPqKG4SrYgyUJfSTw1JzCwj5YgQknRe62omaMyNUC1D
0E+eFZVTnhipVOWSJIIOpJzO7D4nhxyj4bXEONSt/HsTG0JU0U399fe6UvLKWYVFpwTWFSzRk9G/
prqO+duAmPzSYMVSOzf85+IB21uMAy0uiIdcFQ//a0W0NF3Pg0P87zNqNB5+BZpjscoNCmVuZHN0
cmVhbQ0KZW5kb2JqDQoyNiAwIG9iag0KPDwvQ29udGVudHMgMjcgMCBSIC9NZWRpYUJveFsgMCAw
IDk2MCA1NDBdL1BhcmVudCAyIDAgUiAvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDYgMCBSIC9GMiAx
MCAwIFIgL0YzIDE2IDAgUiA+Pj4+L1R5cGUvUGFnZT4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9G
aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIyMDQ+PnN0cmVhbQ0KeJzFWtluI8cVfedX9GO3AZVr
XwZ2grFhBwiCxMEI8IPhB1mkhkx6yFhkIMzf59zauttRRh6yqDwI4mHdvreWu9Vh/7riHWeccyEl
d12wvDOad4+b1Y9frPYr0b0vAtwKrsxc4uGL1d9Xv67SqNCKm47/l4ZvbqGAlPxpJZg0oXtaffm9
6LRm3Oru9mElu9vHlVNM4jvLgupu16uf+h8HofvtoHj/cfB9N/zc3f559d1tM4PCCmb0wuRpMP04
qP7Y3Jjkksnl+m7aGxHmtyvaDbZfD0Jg/7Cbd9jIPf7WcUPxBYEDRGjhVeLr5hPTWjIrFhM7wupm
cPE//dFED0PAjITq3ww6fdgMwvRPzedjjWLBL+bzx/OMfPm96qRjwZLu5MJcMeWi0q849+4PZ+qV
k96ApUg919yfxjN9dKFYCMe8XSg+0yuXaqVlyi/U7tY40m64wZk+kTveHbu74Ub16/Umj4T+F5w2
7x8GKfvDYzz9bnfqSKo8cg/Rw/64Q4iuNxCBC61JqYQDh/7Q7dYbuA3Q7uEjvvf97V/eDTeyJ1uy
Px4P9zty8NPusG913MoqxuU1jnumue1xzxU3PO652t9z3OnI1rsjxfhpt8f37/8NpPotxqXoT0/I
D4futN3Fo17HE/3X3ePpY1Jh+nsI3I2UseEaBq4BlScIQ/EIAWSX+83+7nF3+NzdYwaO+z7/T8sV
NYV4F5jD+jlT0qf16vO3ETk7bSNkmBadgHZrk9q3x3+mpVqEBa3qMW+r7v/2gAXHLxEIFxn3cVFG
4WPAKgPzIlmHCbIrOZmw51bgpRk8plGibu9XBuGDdmNu8CIvny3Fe6bVQvMFbj7TGxT5+Vwv/ByJ
5WtxgXpPqnWQzHiElGBaJ9Xf7ZPD/zBIJL1drIiIk+7tJbYQoHEpVolozwZKCNGe+gHqv/22hXZH
seIW2tNqbF2NwWrQdnTfLO3Fsm0sqvZPllHJY9Z3P8P2emWkZgZRZy0T3QdAyULncNJWduPq3YvP
W410bbHFUIPnMyQFOILfo8BZxGeoE3DGMy+XM6DtoHlq2IF+7cmQ8tT5ZTxOWLBAz1X5jLeQcEnC
MVdmSlACjnVUuQi3q4eLMg4+ScOpOysxP6UVc2nM2xzyRuWQh4vohb2LQ96WyFzqvTDgs1aPDL9Q
u6NwXy/ivfiV0lQUyC8clcGMxwkrJiydX5HPeAsJmyQ8C5o0WFmeAB7ruPQJn3nkKYlZTMeF6E3G
vUaet0Ez7xYGG+V5JziTaqG5SZ53+CjMQu8zed4iYFGnRQiUsikhoR8qcKwQHVeM+iKd8RYCOE40
EYq+L/lMwOWsjY/7CFWCdOQO91VNbYelIKK84Ggw43HCOiWaKp8xEouO2iXtm40aZHrCEB7rOOcJ
X5JbrDUMeZGupPmG9XbfItSnbGKxOWJuoE0ucdzHfDzpbZFLnIi9w0xrTiWySeeoqXeTPDDhr7PZ
xkmm3cJEo9TtERFqobhN7ka1NAu1z2x4rOGmEwiAFA8WNTWhsSKdwqvKZryNAUcCgfqADzHEk7yX
ORxdF0JCFEqU+SGAHk+mhBEon2c8VoyuyfpcKNwEkTEUTw8YctAPsXOImBMe67g1CZPNIoO5eZ27
EVfgWCEC3udeJEpnnHoREkCOsbkXSY9zm3sRQGUTvChfmEDclYArK/sKvYgNllmzsNcofwhUb7FQ
3CaBRK5qrvZ/NyNCmdiJaOJfCIwTUKk+VcmMqQ1RSSJQf0mPh4Q14bGOy5DwZdXBMoVNwkXBuuuV
B4Te3ESrAhFzylxxmwPWbLkjzyQsi8jEvY0YopgALC0xorEgj3yRDjiKFriNHQlJG+oK6GERISc4
llFvErzsWhH5IMFjlrhSOVJ0tZybaFWO4N1mobhNOcLhuoXahvUfc+b6/0UceTis1K9IHAkZ62x7
3kigmuF0mvNGVC7DlXgjgVSkX483Ep4zEa7FG0lcfK1vzBshU+BWNdE2kfj6DN5IIL0GXXmjDD+D
N1KpXpQJKNy+RIrWeMkiBTRHPVFGwlu6GhbGqMBMEBXhyhcJJO1Q6aI4wcoW5bEGZBGSjKHDeS2y
iH5VQCVsTxYJbA1Xzdki6pGDeYktKt5U2CLYwMlUsqjAzA1V6coVKVwv3EQVkTO5iSnKo02IIuIV
9CvyRNndr8ATSbq52fY8kbS4DPmXeCKBDgseXXkiZykBVZ6owMwLVenKEzkXmfrCE6X8VXmiNLrg
iWKCmWgigYsONFaaqOJMCxXxyhKRbRIoLBE5YXwgs0RlvAVLJEW8XFyRJZLxVt6cJZIm9gqNWSJp
Y6dwHZaIfOSqHBE1ZtxfgSMigkHb5hwR9WXKv8QRndWXKRTpkPok9em2bN44aZQ8lAHBHdEvFHkm
3ripKMgYeSZdrHQqB1FeTePbFNwmclIhBT8vT4Qc+1oQKRX0rEB8onnRMv1aZanRhMKMqf1xIXcv
IshopBBbGERvVXmtDAuPVaQnXovuLXKitbB1EWZWK4/OSa0sUTgt4V36XTaTWhVnFquIV1KLGqoo
kFmtMqVCa5XxFryWtPE1iVfjtaiD4EserU0QKokDaU5rKWnoN7YXaK3cByVaS0vq6DOtVUGmsapk
pbW0lEki01rkwRFnWquMt6C14iXhurSW4iK+p9Gc1lLCxdTRmNZS2F7pnuO11PyAfbwNZV4LmcAU
Vit+LiRWFps4LeqeKqOFjGEqnxVHWrBZ0M6FvSqbJbBH5gpkFhEav2HJ2tRNSX3vM2SWOl+7tOX1
KtxtNAwp+h3OJPXv7jdkIL7K1aF0ijfdXze4gjx1yJ9v83t9Nr7X1w2h3x1JaL/Z0Ntm589IF15C
p6acLvJazGakyox8L990g+sxKUOTcnFS+FzfNxwgS99jant8PpzqDOPOLWYZL/ZPmMcN5itV8PWl
bHoNoMw2Vu3uH58Qo9r8HwPmbxINCmVuZHN0cmVhbQ0KZW5kb2JqDQoyOCAwIG9iag0KPDwvQ29u
dGVudHMgMjkgMCBSIC9NZWRpYUJveFsgMCAwIDk2MCA1NDBdL1BhcmVudCAyIDAgUiAvUmVzb3Vy
Y2VzPDwvRm9udDw8L0YxIDYgMCBSIC9GMiAxMCAwIFIgL0YzIDE2IDAgUiA+Pj4+L1R5cGUvUGFn
ZT4+DQplbmRvYmoNCjI5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDk5NT4+
c3RyZWFtDQp4nL1XTY/bNhC961fwSAY1wy99ECgSJLubNkWBooiBHIoetDa9VqOlNhIdN/++M6Ts
lbBAgWTlHHYlkuMhZ96bN9TnTBDBhRBSKVESWwiSG0F6l318kflMkruTgSik0PnUYvci+zP7nKVV
abTIiXji4e0aHKCTXzLJVW7JMXv5ThJjuCgMWe8yRdZ9VmquYK7gVpP1NvuLXrGS1qyiHv4Ik4YG
ltM9DBqm6cCKNHkLEw4sYSDjyj2Tij7gqAUbxyzOmPjimVLgRabpLdq8Zn+T9W/Zzfrb4nj5ThNV
clvg8dPJRcGFjCf/WYiqfPWdftWjXwvZUmbqmd7g4esNW2m6J6FnStPaDw9dHwhbQTj594Yz2VaV
JS/kbNvVEm6rgks9cxsODwBY6/DsOd0g3p50vv3KDOC5yuktLml6GNwWDOHd0h1i2PXwbmhNhgZM
/R24uEY0179/YCuVflsPQxcT1dQAdmg6vxTUurBcmktAPfFM37Qt8D2GsgSq0gheVrMdlkBVGsv1
zOsJ1CEhJiu6RZAGhLeDuS9MCur6WJNbMIB69ie8HVJbAbXfX92QwQ0Ab047j270U35Y5McjN8Dk
TI7nBwa/MiUI0yarBIQ4z1y9xA4nzI3iqkh+h5iKuzbR/hpz9IMoLXKuL8Los2P6ce8AKB8h73Yg
24AWKDGgZWgzANwo9CHiWu8CqjiuWYpcALoAOwYGGAf8V0fBg/KISlDQ4975KAloHOkWR74L8TkV
kINHpQhNqq5nBVqZSaSqrLhRIz889qcjEBZDAPiaASnb49HdxjVf4sv2pxPvU3iPC+Sh3nxiWkKf
ymmA3Oy7A9i226QIskzKqOh95xvYKUCauseSKs6FcI2OgUIL8lXlkudjnFctZLUB4BCXX12LZ+yW
4qSShhfVJUg58Uzf75bIjZQaLjMzx4vmZtpHjeblPAaonh5JPTJIIgvC/lQGliJ9kO7IDSirsauG
RJgaWIr8QeZASx0if7xD/kaKzVVouXqRVcnH80dda/CuF/AGt5ysyVxwe5FOPfFM/wh71x+bwUVp
i33OR31GMT+k2VihBMoSMn6qb4U3V4P1jRqVLBwW7L8gF/BIDu4QNPEjmwGS2V6k8Cae6bUbhctt
AqYMhFLTY4NV00bitdj8QQXhtgAdH4TviJeB/hO5jaqYeoFFhW12UfN9ylrsDy36Ge8Xk25inuZx
BsUo0QuUaWkLns8jfuZ9a1Y9UDzCFufycfe3qC9fv3EHnusSd4nPtJM8f5VVpeVwA1KCazVGML+I
Sm4VfMsJsoKdlLbV+eMRhud94mcf+ed/zD6At/8AY4MxXQ0KZW5kc3RyZWFtDQplbmRvYmoNCjMw
IDAgb2JqDQo8PC9Db250ZW50cyAzMSAwIFIgL01lZGlhQm94WyAwIDAgOTYwIDU0MF0vUGFyZW50
IDIgMCBSIC9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNiAwIFIgL0YyIDEwIDAgUiAvRjMgMTYgMCBS
ID4+Pj4vVHlwZS9QYWdlPj4NCmVuZG9iag0KMzEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggNjE1Pj5zdHJlYW0NCnictVVNj9owEL37V/hor4rXH7ETS1WrQkvVqodtScWh6iGQ
AKkghgBa8e93bAMbVKlSt+khimc8fjPzZsbeIY4545wLKXmKreFYJxy3FZreoQYJvLwYcCO40l2L
xR36inYo7opEcY35bwjDHAA8yEckmNQWP6L7scBJwrhJcL5AEuctShWToDPMKpyX6AeZUpGQFc1I
QYUlB6oJ9poCNC0VGalo6jUibHm7q+JqsqSWHL1m409WIDVUSjiQkT01YPwT55/Rh7y3JDQ3LElv
0jhQYYgL3rIQ2Zqq8Dkf0yMVKuZ1yaKGLR/c25cFdz9WWKbMGh9T5JQrptIQzGvOs/TNC3HlM64F
CmTSRSb5qt6/kM8baLBn6ga5WEe2FJCVEnAySMj+uAV569oDiFDfhS+ra8PeHKzcZuOaIKmHEViO
YA3sN2XQDeXwu2+PdyBZsp9XTdHWbt8X4cooxuX/ILyDTKY1haZZueOZgudEIwWRNhyyowNJWm/v
YNt02HvlTeB4RiafHsLRCjjaurqhgpODJxv6MzB69HBl4LFxh2A7q/qo+CU3JVmaxdze+4HIv0x8
3L00lQ7YXRfAymwNjFTlv5U9S651l1YynfVV9wh8JqcDHSYtlk0TWCVxVaxbf9FURXnyKqi+g6r5
ialKPIPfKZT+2xiWI6xTo+JJKG8cC9kBAyhNqt0R5BrWAeNmztYVRLD0Dov5qccmkEYydW5w34MK
rkVLqta/AG77l36Yhitkef5Hf+J6XWepZSkEwMHfmVhzgy+YlXDJczwAT1LZ7Po0+hG8+AnvAf71
B7MJoD0BaOGXyA0KZW5kc3RyZWFtDQplbmRvYmoNCjMyIDAgb2JqDQo8PC9Db250ZW50cyAzMyAw
IFIgL01lZGlhQm94WyAwIDAgOTYwIDU0MF0vUGFyZW50IDIgMCBSIC9SZXNvdXJjZXM8PC9Gb250
PDwvRjEgNiAwIFIgL0YyIDEwIDAgUiAvRjMgMTYgMCBSIC9GNCAzNCAwIFIgPj4+Pi9UeXBlL1Bh
Z2U+Pg0KZW5kb2JqDQozMyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNDMz
Pj5zdHJlYW0NCnicrVhLj9tGDL7rV8xRCrCTeWg0GmDhItnstgl6SBEDOTQ9aGXZnkKWNpYcZ/99
SY5kW0laoLEuesyD/MghP1L6HAkmuBBCKiUsc5lgJhVsX0UfX0RNJNlmXCAyKbS5XLF+Ef0RfY7C
rEy1MEx8J+H1EgSgkF8jyZVx7Bi9fJAsTbnIUrZcR4ot95HVXMFYxp1my1X0Z/wxkWm8TfK4SKSL
+8TEDEcKGNknMo+rxOKIpClcdxo4LdkkLj7gyA53VvDWJErBhjzukgwW/8WW76L75WxGGJHx1E7M
QDCbRBl68IkGCACom9g0WoDTCOyXnwP28kEzlXFBeII/heM2ALkVIreLn5SrznIdmK/SS8nxXduA
a3tweRYXK1/2yY2KOwZj7z7cv7/SmOxsjbZ2dOtV1qQXggdzpqLNq4XMb4WU90Lmr4V8bYQ0b+D5
biHTYdyhOr2QBt6FEtJm+A75cQ95ksN6sdAwlT0IeWcXN1rcwtwD7XG3QZwFsbkLa1CkNQszSLfZ
QsIO6QCJJg20y70adr4hhdrYAEIhaLtQ6QBGgieyu4WWJI6k4tYB81VBENxmMsWNvHQbZpyOq7Ly
XzDAqxVEtonXe4zvdoeR3m8rBvfe7+BuY3qdLR61QWwBSbtOpIrXiYKc38+hQ6aW26kOD/Gdxl3V
QNr2DC4HygFfs5ns0tJwoyc6i6YDgjgmUoBdc6hwludmqmKPrqtYsXv0m0MLJh7IUN/glUzTaHUH
D3Dc/bbAk8RBmIPrMxFwiazdzHm6OoV7gPhY1W2zoQgCNe0YVhUG2lff4Xl4nAd4b2DR8vcPuLbo
urb0Bc22ZEwLoXGjR5uaCmQcGZDvaRNWkm92zWeQVFznwaCqw8hBvxePte+2lDpZ/AgYnxHQgHBy
+mShi6tmhaY8tb7B8Z7PAdFIy6WZQHy7e6qrXdWEcotIKdjRJS5Aag/1Co8BAgIK7xdCycIBXQdp
QtPKCW7SgGnnv7KuSkZlVPCLehZtCnJPT5St/Bq1DJxC3UTwOMXZE3Ff25MjSnRSW7P6jK2GHIL7
J4itbIgtHd/VviLOQB/+VtU1ZhuF5KrCU8eOpiQPXpnrwSbYphRkeRlZY7ic+vJTwudqOZTJuVWz
thywS1uH0IGwJIxd6Ijf9rMwvMyRYC4FB4Y/NGVdAStCR4Ph7dd4/QFZzMDGRvFMTiB8T1oXuTZD
okNZy/RE4yNxaRmqACU5huEqdN4dK1iY6Q51j6zartmsPK90xvP8B1X8JfWWlwxIORRIP1E6LrdF
s0GsBPW4rRrqNZA6828bgnRavTlbbnEgp7oFvQokdO1LLBqjA6iZffX+7ZymAseIkV2qzm+a2fpk
mWsuZ0vBCQFfiI71+7u7UxECzgtVCAoEObcI/SBrWmwOGH4JYMKUsIHaQXBxQfR3bc0aGlIFAPUE
33JbDRiwE4UTblp2xAH6oHxmga5n0W6l40Cul9oLIPQyfI0OQTRj8MhMoj5S9EQV97lui1WHHi4w
e6ECdd0cChU2+vlE4Q6S30M/gBlDZ+/ODUjHoFMs0M3YIyAuhj2iCz0inAGmVdt0vhu90tAHMGVz
0cxCa6OPtOPpcBiXiQ1RN7SsR99vKTBnUHquUcrlyOOX6n8+xL+trlIAZc9bXUd3nSX/e7s3T0hZ
IHk3UXj0dc2w9ri4gBYojeu2Z51HGHsMMyi7gW3yuCurJtRj34a2avwgCqkO1bm9tiWYUF5uuLVD
6HeHp6d23yPphe9bCllzZrXdofHnrA8eyxChHNtGStH6GNYgD9HvIBTySG3fEYVj9ZLDS8vWHkqc
DSplSLnZjj3T3I2Udc7i/9sNwpeqRSV0D4rk6c9Ybh32F0pwrYbabifyJXeKHQHiDTap2uWnv5Dw
etJDv97Y3/+x7ANI+wegTpzUDQplbmRzdHJlYW0NCmVuZG9iag0KMzQgMCBvYmoNCjw8L0Jhc2VG
b250L0FJVkZNVCtDYWxpYnJpL0Rlc2NlbmRhbnRGb250cyAzNSAwIFIgL0VuY29kaW5nL0lkZW50
aXR5LUgvU3VidHlwZS9UeXBlMC9Ub1VuaWNvZGUgNDAgMCBSIC9UeXBlL0ZvbnQ+Pg0KZW5kb2Jq
DQozNSAwIG9iag0KWyAzNiAwIFIgXQ0KZW5kb2JqDQozNiAwIG9iag0KPDwvQmFzZUZvbnQvQUlW
Rk1UK0NhbGlicmkvQ0lEU3lzdGVtSW5mbyAxOSAwIFIgL0NJRFRvR0lETWFwL0lkZW50aXR5L0RX
IDEwMDAvRm9udERlc2NyaXB0b3IgMzcgMCBSIC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0Zv
bnQvVyAzOSAwIFIgPj4NCmVuZG9iag0KMzcgMCBvYmoNCjw8L0FzY2VudCA3NTAvQXZnV2lkdGgg
NTIxL0NhcEhlaWdodCA3NTAvRGVzY2VudCAtMjUwL0ZsYWdzIDMyL0ZvbnRCQm94WyAtNTAzIC0y
NTAgMTI0MCA3NTBdL0ZvbnRGaWxlMiAzOCAwIFIgL0ZvbnROYW1lL0FJVkZNVCtDYWxpYnJpL0Zv
bnRXZWlnaHQgNDAwL0l0YWxpY0FuZ2xlIDAvTWF4V2lkdGggMTc0My9TdGVtViA1Mi9UeXBlL0Zv
bnREZXNjcmlwdG9yL1hIZWlnaHQgMjUwPj4NCmVuZG9iag0KMzggMCBvYmoNCjw8L0ZpbHRlci9G
bGF0ZURlY29kZS9MZW5ndGggMTE5OTAvTGVuZ3RoMSAyNjk4ND4+c3RyZWFtDQp4nO18B1hcVdr/
OfdOL0xvDDAzDDDAUEMnBIYOAUIITAJJSCCQpukJaSYRk6gxGnuLupa1rtE4TBJD1F2jG9dVNxpd
y1o3rr1gW7sC33vuuYcAKet+z/979r/P47385vc79Z7z3nPe+94JAWGEkAb1Ih4FGpvTJ/zwZvgN
yPkLoKNr7Rp36MYjLyCEUxCSRi1YsXDpt982aBCS1SCkjFy4ZMOCzKNfPoaQrhsh17WL5nd2/3OH
71qE0n6G9rmLIEN7v+w2hNKzIR23aOma9bYvMwog3YqQtnfJ8q7On/bmXYVQ0d+gz8eXdq5fYVkR
vwih8pugvntZ59L5UbfnxkH6ERjDxhXLV68ZdqILEKrMJ+UrVs1fcfYD3BCkob84PeIlfnw5kiKF
dLc0C1rEUOaPoQs4pECcTspxnITnJMcRNxxA9w1DL2T+qKHZ7UYBhH6SyNAQwkfkN3MJboRvIWX8
QWkEuRpYCMlvRmjoKjT6mIrOQqvBfr0wrl3oKvQoeh3NQ9tA7Ua3orvQ71AIPYaeQq+g/4fH0Abp
UqThDyIZMiE0/OPwwNBdgH4Y6YmcqyBlkrhP5Azrhz8bl/fZ0FXD+qF+mRGphLZa7gXI/SceHP6R
KyHp4VyS5i4ErRNafCm/eeiBobvH2aAJzUSz0GzUjjpQJ8y/Gy1Ci8EyZ6MlaClaJqSWQdlC+FwA
qblQqwtqEX2i1nK0ArAKrUE9aC2cK0CvFlOkbKWQ7kHr4FyPNqCN6By0CW0WP9cJOZugZKOQXg/Y
gs6FO3Me2iooxjRnG9qOzoe7diHagS46Y+qiEbUTXYwugft8KbrstHrXmNTlcF6BroT1cDW6Bl2L
rod1cSO6aVzudUL+DehmdAusGVJ2DeTcIihS+gj6EzqA9qIH0IOCLbvAatQizC4LBBuuABtsghlu
GzViar91I9baAnMnc9spznQ95G8d1WKtaEdScxvUpL3Q+0B62TzOEpfDHKg+MSOaukaY/4nc0VY5
Uy6zx02jLHOjkCJqfO7p9LXoN7ADb4NPYlWifguaqlsEPTr/5pG6twrp29Ed6E64F3cLijHNuQv0
3ege2Nv3oj3oPjhP6NGK8l50v3DnQqgPhdE+tB/u5IPoIOoX8s9Udqr8fWJ+eCTnEHoIPQwr5A/o
MHiax+FkOb+HvEfF3CNCHk0/jv4IaVKLpv6EngQP9TR6Bvz+c+gJSD0rfP4ZUsfQC+iv6BWsBfU8
+gg+B9Ex6bsoApXCM+EhsPNNaA6aE6junjunffasmW2twZbmaU1TG6c01NdNrq2prqqsKC8rDZQU
TyqaWFiQn5ebk56WmpKYEB/njXXZzQa9TqtWKRVymRQ8M0Ypld6qDncooSMkSfDW1KSStLcTMjpH
ZXSE3JBVNbZOyN0hVHOPrRmAmgvG1QzQmoGRmljvLkJFqSnuSq87dLTC6+7HM5taQe+q8La5QwOC
bhC0JEFIaCHh8UALd6V9UYU7hDvclaGqtYt2VnZUQH99alW5t3y+KjUF9anUINWgQoneFX04sRgL
gkusLOyD55KWXDbEx1d2doemNrVWVjg9njYhD5ULfYVk5SG50Jd7MRkzutjdl3J45yX9ejSvw6/p
9nZ3zm4N8Z3QaCdfuXPnhSGDP5TkrQglbXzXDlOeH0rxVlSG/F7orG7ayAVwSBqv97p3foNg8N6B
T8fmdIo5snj9N4hIMsURM0E50wjGBiOE+Xk8ZCwX9wfQPEiEeptaadqN5jnDKJDubwtxHaTkMCux
BElJLysZad7h9ZBbVdkh/qxdZA/1znOnpoD1hZ94+IFyd4hP6JjXtYhw5/yd3ooKareW1lCgAkSg
U5xrZV9GOtTv7IBJLCZmaGoNpXtXhMzeMloBMtzkHixubhWaiM1C5vIQBEJiq1B6ZQUZl7tyZ0cF
HSDpy9vUeghlDR/vy3Y792WhbNRGxhGylsNNSajc2dq9IOTqcHbD+lzgbnV6QoE2MF+bt3V+G7lL
Xn0o6ThcziNcUWgFcxtXm1UmM5fHK9ytnJNvI3cLMtxV8OEtK4ICPdwuIUnuaFmRuxU7EasGVxFr
EDWmH0jw8eU1pIgnTctrnJ42Dz3OMCSnOCZpfEgxqi89ZIyMiV7ntEOjtcmAktyV8ytGDXBMp1Jx
gGJvpx4nR2whXhhaKMjtrGFFfDzsXMjjoBshi9xFuzuEprpbvfO9bV5YQ4GprWRuxNbC/a1r9tY1
zWwV7ra4SlrGpGh5Pk2FkAeKWYIrhzVY5Xey2yqkq4X0SLJmXHEtK3bvVHjrmneSzr1ih8gNOwgm
LUuo7bw435gNW7MKvJu3qtPr1rurdnb2D/fO29kXCOxcUdmxqJD04a3t3ultbi1yCmOd1rrZuZFc
yojqcF1LWWoK+J6yPi/e0dQXwDuaZ7Ye0kOUu6OlNcxhrryjrK0vDspaD7kRCgi5HMklmSThJgnS
0zRIKIT6zkMQQfcKpRIhQ0h39WMk5ClYHkZd/RzN07M8DvIkNC8g5JEDbpJ9EZgY3G2lu5vcnk1t
i3Z2tJHNhaxwK+EHh7C3GIU4b3Ef5mSakMo7vyyk9paR/BKSX0LzZSRfDgsDWzEYh/iknR1e8FOw
oFqRE9OlyJMu3f3Dwy2tnqPOgTYPLLXZgJmtIaUffL80fjLUqybogOzqUG9XJxkHCraStvL42q42
WLasQ6hSG1JCD0qxB6hRJbQhyxEadcG9gRsotO+FRKi3LdTmJxdtXdwmLGd9CNV4C+G20z6lCeRC
6W07jd4Jwt6EraCKv5CQEsaGmltpjhOScLE2aiS5Bkbe5YWirg43WFuCupphqVNfqnLSnPngEiUJ
8wWonGIhItPi49VaVUiZBh3CD9HqNLIlpfHytjY6eCF1oVgBrq0PqWFECaNMKTYA60BRLRkL/FwI
QyVVHyPdNPWjad714FnIoIWe5FAc0sbXdoLzp+3VkOPNZ40VxEeoxT6O0Fw5mbkG7M7Ht/QP3+3d
4Bl1pKZ4ycOBLEzkPAQLG7XtHJ8RmuVPTVGMz9UK2Tt3KrSnbkDtpdCOMMl0V8JTAypK4Y1tNf8C
vGHxSI4KUAOagmY9grR4GrKiQnzggKWiQpEq/wMuh43gxi3wropxeUAn4bQHIyNLvAdzZLt4Q20/
Tt1fIt/Fcahk8K3BZ9MH3xowFqQP4PQ3337rbf2XzxoK0rPefvHtzAxs8BgEmCM4udws88amcTm+
hNysrAnFXE52gjc2ghPysnPzivmsCTEcb2Y5xRxJY/6Fn2fyjYMybou3ZHqWNCZSZ9bKpFyU3Zha
FK9vnhVflBYt5+UyXqqQJ+aVxdYtqYx9TW6ItlijjQqFMdpqiTbIB1+XRvz4lTTip3LJkp+u5mUT
Z5fE8derFJxEJuuPsTuSJ3pqp+tMeonapDdYFXKjQZNYMXvwAksU6SPKYqF9DTaAz7hv+EfcKjUj
C5p6sMTWaHvAxqP+4Q/36XED8Bf7dCJrBf52n0bgD/epgR/iDEg1fPigBTeo9NOkQVRSgtP9b/vJ
kZnRHs8mbxBnb8GtCrPHYY81K5QWj83hMSsiFRq5VCrXKCSvMUW+O7gPIb4ORhWJag4hCx2ORRyO
RRyORRyORRyOpZ8z7EdK3TRLP/b3yVpQyQAM5ygbjjAaT2zCidEYPOQO1UmUWuXgEVuSwhxrJ0PC
xyBDUmd2mpQun2QvG9ZPtykNUQgWEliMfxLWXBRKQuv74mSitWTi8GTi8GTi8GTi8GQwvIDNEG2H
utF6HfnQaHF9tBvKovu5CWFkiO/Hqn0ymcbbj9X7LE0aYlBxKb4oTENPJzMBliKZjddwwsK5WTAb
iTw7jWST9cg/GVh3//qrlCaPg8wqORJbkhsWL61POjBxRnvKLTdOWVgVx1/VedOyoqG0kZtwb2Ks
3FYye8OMxrOyIwZ/SKzuEmcsUcOMc1EFuiIQo08z5Clg1HlkFnnCLPLIrPLsJLOfyzqYFIBkUomB
mAKUQTSNQTSNQTSNQTSNAUwTjkrT92PFgysCOBCwTQILHPA02YLCohKM0D5QgNPF+b8oLjJjQYF4
Y8EIPj6NP8kkVlsMbyHbNYa3maxWnJ3gS0gQLSRRy8xxMZEes1qyzpJa3DJxNTNWkg2bMksj61ZP
8XnLZhe4s1MTzWsiFEODFVMdJVlX3FPRVeaClauQSJR6Dc7MnlHiHXx1xIh7fS4pr82fvry8dGFj
oTnCXzQlc+iduGj+/PrFNrlsqN4zcSqs8XuHByQbYI370e5AdEcqdhMbuolN3XowklsFFnITk7r7
OX3AgAKwzVDARD4M8GEV151VNK5VNK5VNK5VNK71IU5Pduk+skv7hw8HlNCFKmGafpqzHyf1SaeT
fUL2rWjTF/3+E1sYn7SFDeYYTnB3IzmSDZW9/T1nh7ZUKMzuSHusSZHS3FNb19PkFza7x6TEb609
1FtWvOHBdbyXWennr2ZeAJFI69YZvO3EzufQ7OEBvoR/GmXBIyAUcOvKXGXpZbxaacvWwKSyiWWy
iVGy9To9rs/ux98FIpDPp0NYg4jtUCGxA1QtJPPXiqymvJ+0KeznFAGzwfYEytZncxMPZ2OUjbOz
00qT+7EzoDsWi2NjJdEfp02e9IamQYLSwTx0/RnI58o57QPiOjzin9NekE735ARYiHPA48ngoZCQ
kJMjk424/awcsilHHg3FEsFqcpJjMVuzJuTm8SX6KGekK2LiFU3Vq5tSi9fcs3iTNXNKwaTO2kyN
QqOUyJ1l0xdkd+5oSbhjV0V3mattaunySXaNBnyFZmZJVXzVgtL6FZPjq7Kn5jijvdEKvUPniI70
RptSgltajthSS5KqmssqYM3NBOu6+adQDrqoLwr8+GHRzx8X/fuH+4lf94lLyycuLeDPiEl9oimB
PyYNfP2cOqBNj8ARjg9cAZW2xhXXj7n9psn8J5nQ936ltiYzpR/L+pQN8Gh90T8gfOD0drq+jlBX
BvtXNuoZKbPQB6s3FhRda8KT1M1J5Y6iutb0zmvn55Su3N3mb6rIsStlnFGr8xUFC9ed6wm0FxVM
L/Fr5Co5/1uDw6B1xEcbA+fs6zn/0Y0T9ZGx9giT3ehzeRI9B/fO2Nbqj/N7FaZosurawS67YdX5
4S1zbyA5Pbckd3kub3LDJE1usIDJ5EmBnd6QQpZeClmEKcL6g9n9cKDCf4ef84OtDkBNf7ZENKdE
tJqQVgtMF6Ckn1MFPJ6UJ3sll0u4wxJ8TIIlkqj0NxIm2z/uiFgRwUUoP44STNYurr2Vq9iim/Cm
n5oPssUtKvN6RhnKMtacnMWXKwQmcn63zzEYjqla0RTork3XyNUynuPl6tzpKwPL715VWLTy1q6z
rulIvYvfsG7S7OJYeC/xeerWT0+zRFrkEQ6j1qTTqB12U/HG/o1rDp1XWbH6xlbT1qvT6ufnwcMa
5QxdxV/E/xkVQww2Fx0LWIyp1WQ/VivABNVuvQnXV2eV9A9/T0xSIi4s4OMPkqISeSPIgFZnxPWN
Tokug8+Sy4ndYBU6idPSgkjNkjud8qxUCVmwgWyyUlvJJVrdemjWmhwfUAPH6zLkfP7k1zTNH1os
Hfn8R0U1ye6yV/Mnz3rV3YjoZi4R9vLAywNGGzxU/FlHyWK0FaTD4fcbIFN/1A8/fvZBnrcyr9dq
tQj+MMEng7VptYnPFmbtPNj4EPmRT2J6qw0eP5hGhcJGL+ZM8PjxRfBiir/IpDvPGzWhvXdKXpfT
aCvN/aR8xbS07LPvWrl097wUvSfTnZk+Id4Vlz37vPqkahfWGwxDQ/PbM6rTbfNnZdak25rnNn3k
TrIrt6+tm1/s5Nd4XXEz0qesb06JthrTYrxpnIrzTGqbWLwimBkfaMv2FOdnORz1KZM6EuLbyxo2
tqQqFZ6hL2cvdOfXJrYtcOXVDM4pLOEUjtSkREtpeXRGMYnFdkO8c6t0JZqANuwvycbJJtELAH8h
rGeT+MQxiU8gUz/+PmCLUZMHmJrsFTXZNWphw6hJmQoFSBgZk+yAR77sYOrkuCpHvbSePOnJ3cHp
YhBJXWvB2FBS8Axyw8kPptxcgflbFUa33eE2KuxptRnFmyog6bC7TXK5iWZXX14785x6j0Ohhuc3
fHC6hjkVca3BwYtZjjRfeLbDx+B7dbWTFlzUSXzE+RApN0nTIVL2oEsOlngbvcu9vFV8yox56poE
Pj7u6Uyfxg9zKyFytJwuhBVNCiHs9w+qXAFo6erHxfsd+lrBPi8P+EU/QAPC08TZJuJCyWKEVYiL
xxvAlDKx0E8wYgJ+u5xOWI4zCpOTCgDszm+CO5+NrgloSnJxUibODBhxAzj3Y8IwM0VXl0keCBqB
BVeX+TDnQ7FII85GIy4MjThdjThdDVkMkdbUVEQmSheFNVYtTayNqjKwBQExHk6HRwU8ab8UHOBx
Nu+RifvwKZYDpm9g8DSRY2y18psUpthIp9eukw1tH28R3KIwOiD6j7Uotbqhh/AyrVoI73i5Vom/
GtKevDB+fgGvVWmVPDhQpcauH3poKN5gEW2Gi8FmFhQQ3qeWC+9Tp35/YncbgR32q/RVwozF+3vq
96eT7qXj5KGJo5Aeg+fZVPRxwGnUk91K9mCCXq3B9T47+VwxDVeN2rkjW5qsWpO4ak3ig17Y0TEx
VpAxMRNUZGOryMZWkU5VwsZWwZPw4FQSmU4t9ondjooXvhgXTwgG8T2Mvwe3oseycN1kCB1kAW3p
5OKq1Pza1HrHqPtPnDaL/QvE2B9eysUwlfgHRMSZnMTpvIaFeg2buFikx6jzMCnMKRVpBasrFWBn
m8ckt6aUpxWsGfElMmOUzRqtl9dfVpvfVpGhT22qq46bsbbWdcKreAvGeZWTc/jtCjUsIaVasS7Y
GJlemphZkWwCd1PPvC7cwQno6oCO3kHyITrg8XdJ9Lvj7ybcNWeMWq9nfpg8LalbFjwylB8UXTFx
xAFV6uRkR1wtMz15To74YvbuKVr7Fzhky79yyCNGvK7hXzjkMYYCA3UQf0xi2bfAQibkQ/cEokqS
cKIRJxlwghYnaHCCAifIcTKPkzgcI8azMaLBYkS3FSNGaDGiwWJIYBaTrsIqM3kXMxNzmUkMaDZC
LTOxmfkhToXQ8OGDOtSwAm6Tox/jsG4yvLFzfdIGRFdqu2gyFugSXyUeeNwXQnLx3YCFuvxbhavv
X7X8zmW5BavvWw2ct9dZfFZj7eIKj7PkrMaasyrc+L1lhy6oK9uyfxXwZOBNtVvnFWTP3doweWtn
QfacrWCb3UNX8y+BbZLRJNR7AJyKJ1clrhKVuEpUzPuoxNmrhMe2xU8m7CcT9ttJsZ9M208so0QW
VW6ORyLN6MfSBxMmO2v1jQUgxYmTZzcJp0Z/VUFei0bm7DvFGqH7jllBbrDSyOilrK4r5yRWlAbi
Ri0Ws8VplCfVNzSlzts5I3GvJWt6wF0cqPJVbCwvbsuLxB+tfWRbtT422ztUzHyh5CNYMzwPq2dD
cnGSpX77Az2V53UXmZLKM4duaG4t6t5EVlIHWOsm0VoXBJxgLpfaTzaMXyWYgRhAcHL+h/EPUCuL
LpsscTlliV4yS1xmWaJBs4jRVJb4WvUkv0uiTwNThSMn5/djyT59g7SRfLkjmIy5fPGZPsZmOYYI
fvR6sY2E9XxCwuiFk8ffpCTbzGWWJ02uqfURE03oumJuYlVldTL50s8cZZDfVb65oqQ1z2HJnl7q
mQSmG9rPLIWPJhV4dQ3b+uateXh7tSF+YtJSZrqhb5pnFM3bFKjc2j3JmFyeSb0Td7fwlt61f0UO
TtCJi0onTl3HFpdOXHU6sriMo76+IKsMRcKaiw8o/ZMTdBZ3rYV4HcHdCw98/0j0x4xBl8hpFpGM
u5uTKRUKW3ScxZGRU+gd72biSwsLorWeuGiNhMf8PGuMQalUKsxp9XmDoZMdzbbcCp+OV6hUyggn
eaI2DQ9wz8KMa9GzAU16XUldY925dQ/USUvFCZaKFigVF0Upebk2iWm9yGrC+I2AK25C3ASNkywx
J1liTuKincS/O4nPcT6EvyVOJqAiYZEmIIRKkEyA/ko0D2g4TdqbeapPDFMNHYYVBj7PkGewFr1e
6pQmTbZ+SDcjmHHAUABvNO36Ab3gkvyjvjRLTz8RPYrGlbCFRb/LTpOdeB0/YXxYbDLu2aw5W6dk
zKjMsKokMrVc7S+Znp9cMcHpC0wNNgV8SdPOmRZXU5hkkfMQHalkytjc2vTkQJIlMTAt2Bzw4YjK
JXC/bQ5znMsUqZc73U6jNzc+ITvRFesvnl6U01mbojFa9BqdVW9w6OVWh9XkzYjy5SS6Y5OLWsi9
8Ax/zi2V3I8K0ez9ScjgTRVtnirei1TxXqSKGzJVXJWpZBFqbNrUAW9NtHbAVpMJe7FPTt32UbLs
ssQvGI8eoV9MSOhKE4Jp+lUOW3NibEm+cLSyV29uqULvTkqzVXUHorfojFKFVrGZBWofkO9xjLoP
8qptcVFmhVQplcyKjtVHKGXxdauncBHuOFOkQf6yHGpJlBoQhkhTnHtI1T5XqVJKI+xk3lfDE+8m
/hGICa4MuCASUPvICvKRFeQjX8j6BCfl0wshF/7hQbrTXKJVXKJVgL8X9iYRxCwutlld4hqFV44f
AkpTaq1PLXXUQmAm3RfRIMQEwsIa8VcjS2rMKxr77mvcV4a5eSMZ/E1yY7TFFm2QNVwrPPrlZrcd
tqrCll6TUXxOpdzsgp1rVI5EBOuCU4oWXjSPi2W7c/Drxrnl8a1BroflEPvkQNS7HexTid46hKph
w0yCRZFPvoBIysd5hOPTcIIHJ7hxggsnxOCEaOyLwokSnMTjwol4YiGemIqLyG+tWHCDXnyFIxxQ
gQH1buhBrxOzCQc0xLWRbF1prVCPfFlUom/UL9efq5foA0ZrjT6rNr628PIUnELKUsg+1pusNQtT
1qVwlZBrq1cSy77UDlu0/UhJyVF/u1/4OtafTncoEuKGkQgCiv2YvNTQB4OP98l5UWL21QM8J0y2
PBN9uI6S0u0S6dB3vNaWGONKdmj433PcA7w2MinG5YPU0A9SCcS7tqhYo4J/leOe5JRGuBEuo4J7
hcMvc0qTJ9IebZDzt8jNup9/p45Q8BJFhIrbpVQOrmYpfobOLFeq5Rx5dxqMVCq595VacAXwgjlo
ZylOoSL3Kwli3Dq4X+nogkMoEwxjgMWXTlZyGlnDE9OwHVbkg+TbXju2iavVyrKsWAkykEzepEib
IoTzvThXjdVuEvCSu6JWZ2Yk1XrVhuhaw0hQW1BiMGL65RkihvX7hZ928gZhNdPF6+MFmyYk5OZh
sKr4kmASzGi1gvH5coXJ54rxWtSSv70iUVtio6LjDViJ7UPfKbDJ5472mlWSo8ckKoPLGR1v5JRD
P6REmDRSeF+U4/lDNwLxUo0pAh/Ed0eYtBJeppIP9eFGIF6iNuuG5oB9YiEu2QT2iUPTDiEnzDWH
/AOLEyc5sV14nbPjhIjcCM6nxJHkIVEYiR35xHAO7Kp1qEy1qjpJI6oTX6NKYJPCLLGwhtr9Hp5O
Nc+UkAArJ1ucI84yCV9eWc1yLmu9LHNCpNvAyTYp9fzQowp9XExMrFkpxZj/XmaIdUfFGWRDB/QG
qcYcgQskRhU/22KPkPIKnXYwjXvZpJaC5zJChPXw8Hd4F3+NEKs7+5C5nzvnoCrGC28auhpUcrTk
KHG97J+1RoU7hvH/frpL6Uh0uRNhJdkT3a5Eh3J8mne7U5xqtTPFHZtKOHUw0UMzPJ7USI0mMpVE
fDv4dXyadD1yojyk3S+LtU6oRiVZR8kIxnyjJ/4zrvwUuYKF7lLbvHZ7rFUt09r0F0o1RodRb1Vh
6ZDtFAWwViTVWyLdRpnM6I6MyUpLdRxVqOQSsjeGBk5TQEbr59dxz4+MVu2zZY2MVviXaLpUs/NM
zEzSkWxyf1ku9zwZzA6J1mgng+G3q2xeh81rVQ/dMKoAhi8RSsjopT4XjMZ+VKGG0cATDBvOhfUg
kxnckacr2Pqc8Lvf0ndeOfKU4925uqJvkFIh/Drzw59sIr//jl64elP2Tz8OXqz8VJELSSXMkB7Q
jv6euOrWn3788Vblp/S3yE8cfIck4kQKP4eQ5Dbk/Xd/y1syE90nqUCdpyz7lPzb86grfjg2fbqD
v//U9SQ/n8jnJL+sL6HuLiQf03/7qdvKXkH3SZNPXQYOr+uXXo8cktgT/Uhax9nhflR9qjb8++T3
10ddMxbd++9cUx4D71z/y4P/Gun/3TYSCbqNfwYtPWXZfHTbmP57x6ZPO46p6DbJVrTkpP7Wn2iP
Pz1zX1BuYJorFvt9irbhjp+6rUwG173i1GWSe9GCXzJ2dvBP0H4kfWgBPzDODo3w1nOqNm0oasw1
d6FbfvH1BpFHVgz+bHz+X1Auv+3k+8ovRhVj0i+h2b/0WiPjy0a7+Xlo5qnK5MvRTNmbAEzLoW7H
mOv9hNp/yTW4lShedgOKV7yE4iV7QN8o6iIU/0vay9b+snpj2ijhGuUnX4P0JRk4kSdPRPH8EZQz
vv34uYp5u5nGL6Pz/9UYoM7uU+Xzt4/p55R1ZN1o9+jrnTSW/FPfs9PWF/si8+KeHtsv70FNp2oj
3Ts2n9uLPGP6fB95JD1j8055bagjNSGPvA7W96v/uj6pA+O8+l/VYwf/GxQr7T/5HvLrUBJ/C4o9
KT8JtZ2uL+4+VMG9h5ZwUwSu4fpRNX4MxXHXoWTuI7QEd9FnJKSX4DloiWQ61H1fQKXQDtrgb4Ez
UBl+B3lJG+585OI/RyncFpTIXYBcXB4q+6Vz+289YF0j/Ox/ehS/Hr8evx6/HvTgbsQqpvkDY5/f
XAcaEPK70UbCeBglC/lx6GFOiq47VX8Q6+0A+EHe9n96fnqmExf+2+c+cnJzznB+9Ov575789ac/
JXFnOJ/4vz+l4ZNPWa5wPnCmU14rnJecOBVLFUOjT+Ulpz5VXjgfUeeI508nn5p1/5tTKz/N+Xd2
RiyPePHX89fz1/N0py5qzLla90zZeeRbRb4DnjVSeC7yiEN6lI7mI2S4PE4PKfKdoxzeOHl4m1OC
XkMef4LGKApSVHMoAl0uah5lo5tFLYE6L4haiqzoM1HLUBSWoBbhrwysRm7xsxOwAC1Hy6BfN1on
/g2CRSPla2BcS8W/3tAJWIyWoA1C6TLhLwd0QnoJ1OlGaZBbAfXcwt97IL31QI358AZaimrRdFSF
GuDqflQutFmM5gm9TYMaC6HmEqH3qdBDFSo8Y4tClAFnJlwvQzjPVHc69E7+ssRiYYZusdWZWgiW
Jsewnfw9kpOPsJJ393Pb9yvteDKIbUxsZeI8JnqZOJeJLUxsZmITE+cwsZGJDUysZ2IdE2uZ6GFi
DROrmVjJxAomljOxjImlTCxh4mwmzmJiMROLmFjIxAIm5jPRzUQXE/OY6GSig4m5TMxhop2J2UzM
YmImE21MtDIxg4npTASZaGGimYlpTDQxMZWJRiamMNHARD0TdUxMZqKWiRomqpmoYqKSiQomypko
Y6KUiQATJUwUMzGJiSImJjJRyEQBE/lM5DGRy0QOE9lMZDExgYlMJjKYSGcijYlUJlKY8DORzEQS
E4lM+JhIYCKeiTgmvEzEMuFhws2Ei4kYJqKZiGLCyUQkEw4m7EzYmLAyYWHCzISJCSMTBib0TOiY
iGBCy4SGCTUTKiaUTCiYkDMhY0LKhIQJngmOCcwEEgUeZmKIiUEmfmbiJyZ+ZOIHJr5n4jsmvmXi
Gya+ZuKfTHzFxJdMfMHE50x8xsQAE58y8QkTHzPxERMfMvEBE+8z8R4T7zLxDhP/YOJtJo4z8Xcm
3mLiTSbeYOJ1Jl5j4lUm/sbEK0y8zMRLTLzIxF+ZeIGJ55k4xsRzTDzLxFEm/sLEM0w8zcRTTPyZ
iSeZ+BMTTzBxhIk/MvE4E48xcZiJR5n4AxO/Z+IRJh5m4iEmDjHRz8RBJh5k4gAT+5nYx0SYiT4m
Qkw8wMReJu5n4j4m9jBxLxO/Y+IeJu5m4i4m7mTiDiZuZ+K3TNzGxK1M3MLEzUz8hombmLiRiRuY
2M3E9Uxcx8S1TFzDxNVMXMXElUxcwcTlTFzGxKVM7GLiEiYuZmInExcxsYOJC5m4gInzmWBhD2Zh
D2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD2ZhD17FBIt/MIt/
MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/
MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MIt/MAt7MAt7MAt7MIt2MIt2MIt2MIt2MIt2
MIt2MIt2MIt2MIt2cPk+IiBqDscUuyBmDsdYgLbS1HnhmEKgXpo6l9KWcIwGaDNNbaJ0DqWNlDaE
o0uB1oejy4HWUVpLqYeWraGp1ZRW0cyV4egyoBWUllNaRqsspbSE0tnhqEqgsygtprSI0kJKC8JR
FUDzaaqbUheleZQ6KXVQmktpDm3XTlOzKc2iNJNSG6VWSjMoTacUpNRCqZnSNEpNlKZSaqQ0hVID
pXpKdZQmh521QLWUasLOyUDVlKrCzjqgyrCzHqiCUjmlMlpWStsFKJXQdsWUJlEqojUnUiqkzQso
5VPKo5RLKYd2lk0pi/YygVImpQzaWTqlNNoulVIKJT+lZEpJlBIp+WjXCZTiaZ9xlLyUYmnXHkpu
2s5FKYZSNKUoSk5KkeHIKUAOSvZwZCOQjZKVZloomWmmiZKRkoGW6SnpaGYEJS0lDS1TU1JRUtIy
BSU5JVnYMRVIGnY0AUko8TSToylMCQmEhykNCVXwIE39TOknSj/Ssh9o6ntK31H6ltI3YXsL0Ndh
ezPQP2nqK0pfUvqCln1OU59RGqD0KS37hNLHNPMjSh9S+oDS+7TKezT1Lk29Q1P/oPQ2peO07O+U
3qKZb1J6g9LrlF6jVV6lqb9ReiVsmwH0ctg2HeglSi/SzL9SeoHS85SO0SrPUXqWZh6l9BdKz1B6
mlZ5itKfaeaTlP5E6QlKRyj9kdZ8nKYeo3SY0qO07A+Ufk8zH6H0MKWHKB2i1E9rHqSpBykdoLSf
0r6wtQQoHLbOAuqjFKL0AKW9lO6ndB+lPZTuDVvBX+Pf0V7uoXQ3LbuL0p2U7qB0O6XfUrqN0q2U
bqGd3Ux7+Q2lm2jZjZRuoLSb0vW0wXU0dS2layhdTcuuor1cSekKWnY5pcsoXUppF6VLaM2LaWon
pYso7aB0IaULwpZOoPPDlnlA2yltC1sWAG2ldF7YEgTqDVvAGeNzw5ZcoC2UNtPmm2i7cyhtDFu6
gTbQ5uspraO0llIPpTWUVtOuV9HmKymtCFu6gJbTzpbRmkspLaF0NqWzKC2m7RZRWkhHtoA2n0+p
m9bsojSPUielDkpzKc2hk26nI5tNaRad9EzadRu9UCulGXS40+mFgrSXFkrNlKZRagqbA0BTw2Zy
hcawmSzvKWHzNqCGsDkVqJ5WqaM0OWyGuADX0lQNpWqaWRU2bwGqDJsvBKoIm88FKg+be4HKwsYq
oFJKAUollIrDRni+40k0VRQ2tAFNpFQYNpClUUApP2yoBsoLG1qBcsOGmUA5tCybUlbYkAI0gdbM
DBvIxDLCBrI30yml0eap9AoplPy0s2RKSbSzREo+SgmU4sMGYqU4Sl7aZyzt00M7c9NeXJRiaLto
SlGUnJQiKTnC+nYge1g/B8gW1s8FslKyUDJTMlEy0gYG2kBPM3WUIihpKWloTTWtqaKZSkoKSnJK
MlpTSmtKaCZPiaOEKaHAsG6ei2BI1+Ua1HW7fgb9E+BHwA+Q9z3kfQf4FvAN4GvI/yfgKyj7EtJf
AD4HfAYYgPxPAZ9A2ceQ/gjwIeADwPsRC13vRSxyvQt4B/APwNuQdxz474C3AG9C+g3g1wGvAV4F
/E17tusVbabrZeCXtEtcL2oTXH8FvAD6ea3fdQzwHOBZKD8KeX/RLnU9A/pp0E+B/rP2LNeT2sWu
P2kXuZ7QLnQdgbZ/hP4eBzwGCAwfhs9HAX8A/F6z0vWIZpXrYc1q10OaNa5DgH7AQch/EHAAyvZD
2T7ICwP6ACHAA+oNrr3qja771Ztc96k3u/aot7juBfwOcA/gbsBdgDvVqa47gG8H/Bba3AZ8q/ps
1y2gbwb9G8BNoG+Evm6AvnZDX9dD3nWAawHXAK4GXAW4EtpdAf1drpriukzV6LpUtdC1S3Wn6xLV
3a7z+XjXdj7ftQ3nu7YGe4Pn7ekNnhvcHNyyZ3NQvRmrNzs3120+Z/Oeza9vDhhlqk3BjcFz9mwM
bgiuC67fsy74EHcBWsCdHygKrt3TE5T0mHvW9PBf9+A9PbiiB2f0YA716HvcPbxmTXBVcPWeVUG0
auqq3lWhVZKJoVXHV3FoFSZ/9GjfKmdMFfmvN5tWafVVK4PLgyv2LA8uW7A0eBYMcHH+wuCiPQuD
C/K7g/P3dAe78ucFO/M7gnPz24Nz9rQHZ+fPDM7aMzPYlt8anAH1p+e3BIN7WoLN+U3BaXuago35
U4JTIL8hvy5Yv6cuODm/Jli7pyZYnV8VrITJoyh9lDuK15MBTImCkSAnLstwBpzHnV84JcgZch52
8kZdpCuSS9I5cHmjAy93nOu4zMHr7M/ZuYA9KaVKZ3vO9nfb5zaJKWBLSqtCVr3VbeUtZG7WhpYq
gUsqKGfmCHNtsHoTqnQWrLO4LFyly4KR4bjhCwNveVT/nJ7T6bBON6zjAjqorotwRXDkYziCD0Rk
5lXptC4tRz6Gtbw1oIUc0qNPM7WlSqd2qblgibpRzQXUJeVVAXVqRhXisRtjhPVAvIKMAltcVbCv
91mxFMPzvK+l2e+v61egaXUhxdRZIbwjFN9MPgNNM0OyHSEUnDmrtQ/jS9v6MFfeEjKTv9IppM/f
tQuVRdeFoptbQ7dGt9WFekEEiBgGgaL7rKiszT9ndc9qv3/NHPiYs3qNX/iBFO4hKT/JJD+r10Ca
nD1CGvnPeNBqQHNXw7GGZa45c6v/3w/8nx7Af//Rh8gfli0d5rajbm4bYCvgPEAv4FzAFsBmwCbA
OYCNgA2A9YB1gLWAHsAawGrASsAKwHLAMsBSwBLA2YCzAIsBiwALAQsA8wHdgC7APEAnoAMwFzAH
0A6YDZgFmAloA7QCZgCmA4KAFkAzYBqgCTAV0AiYAmgA1APqAJMBtYAaQDWgClAJqACUA8oApYAA
oARQDJgEKAJMBBQCCgD5gDxALiAHkA3IAkwAZAIyAOmANEAqIAXgByQDkgCJAB8gARAPiAN4AbEA
D8ANcAFiANGAKIATEAlwAOwAG8AKsADMABPACDAA9AAdIAKgBWgAaoAKoAQoAHKADCAFSEqH4ZMH
cAAMQKgbQx4eAgwCfgb8BPgR8APge8B3gG8B3wC+BvwT8BXgS8AXgM8BnwEGAJ8CPgF8DPgI8CHg
A8D7gPcA7wLeAfwD8DbgOODvgLcAbwLeALwOeA3wKuBvgFcALwNeArwI+CvgBcDzgGOA5wDPAo4C
/gJ4BvA04CnAnwFPAv4EeAJwBPBHwOOAxwCHAY8C/gD4PeARwMOAhwCHAP2Ag4AHAQcA+wH7AGFA
HyAEeACwF3A/4D7AHsC9gN8B7gHcDbgLcCfgDsDtgN8CbgPcCrgFcDPgN4CbADcCbgDsBlwPuA5w
LeAawNWAqwBXAq4AXA64DHApYBfgEsDFgJ2AiwA7ABcCLgCcj7pLezHsfwz7H8P+x7D/Mex/DPsf
w/7HsP8x7H8M+x/D/sew/zHsfwz7H8P+x7D/Mex/DPsfrwKAD8DgAzD4AAw+AIMPwOADMPgADD4A
gw/A4AMw+AAMPgCDD8DgAzD4AAw+AIMPwOADMPgADD4Agw/A4AMw+AAMPgCDD8DgAzD4AAw+AIMP
wOADMPgADD4Aw/7HsP8x7H8Mex/D3sew9zHsfQx7H8Pex7D3Mex9DHsfw97/T/vh//Kj7T89gP/y
wz53zv8AXcr1Jg0KZW5kc3RyZWFtDQplbmRvYmoNCjM5IDAgb2JqDQpbIDBbIDUwN10gM1sgMjI2
IDU3OV0gMTdbIDU0NCA1MzNdIDI0WyA2MTVdIDI4WyA0ODhdIDM4WyA0NTldIDQ0WyA2MjNdIDQ3
WyAyNTJdIDU4WyAzMTldIDYyWyA0MjBdIDY5WyA2NDZdIDc1WyA2NjJdIDg3WyA1MTddIDkwWyA1
NDNdIDk0WyA0NTldIDEwMFsgNDg3XSAxMDRbIDY0Ml0gMTE2WyA4OTBdIDI1OFsgNDc5XSAyNzFb
IDUyNSA0MjNdIDI4MlsgNTI1XSAyODZbIDQ5OF0gMjk2WyAzMDVdIDMzNlsgNDcxXSAzNDZbIDUy
NV0gMzQ5WyAyMzBdIDM2NFsgNDU1XSAzNjdbIDIzMF0gMzczWyA3OTkgNTI1XSAzODFbIDUyN10g
MzkzWyA1MjVdIDM5NVsgNTI1IDM0OV0gNDAwWyAzOTFdIDQxMFsgMzM1XSA0MzdbIDUyNV0gNDQ4
WyA0NTIgNzE1XSA0NTRbIDQzMyA0NTNdIDQ2MFsgMzk1XSA4NDJbIDMyNl0gODQ1WyA0NjNdIDg1
M1sgMjUwXSA4NTVbIDI2OCAyNTJdIDg2MlsgNDE4IDQxOF0gODc2WyAzODZdIDg4MlsgMzA2XSA4
OTRbIDMwMyAzMDNdIDkyM1sgODk0XSA5NTFbIDQ5OF0gMTAwNFsgNTA3IDUwNyA1MDcgNTA3IDUw
NyA1MDcgNTA3IDUwNyA1MDddIDEwODlbIDQ5OF1dDQplbmRvYmoNCjQwIDAgb2JqDQo8PC9GaWx0
ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM5ND4+c3RyZWFtDQp4nH2TS26DMBCG95zCy3YRgSHGICGk
hDQSiz5U2gMQGFKkYpAhC25fe4akCosggfQx/zw9drP8kKt2Yu6H7qsCJta0qtYw9hddATvBuVUO
l6xuq2kh/FZdOTiucS7mcYIuV03vJAlzP41xnPTMnnZ1f4Jnx33XNehWndnTd1YYLi7D8AsdqIl5
TpqyGhoT6LUc3soOmItum7w29naaN8bnX/E1D8B8ZE7FVH0N41BWoEt1BifxzJOy5Gie1AFVr+x8
S26npvopNcoDI/c830st+UekbYwUvBBlSEIiCVKKHZGPFEZEwhL3fKSQI3GPKCCimCEpxWKTRBTT
BEM6EGEtPMyI9kRUp/lpm1y64dferrPgUlgZlyGpD4ua7P5qFFwuCY+YIoqRpPc4RbTHFBGVJ/ld
ivW0eUz9SppFTP3KLdJeENFkMk4kH6fPsDWe0dnI6C49X6UPliMMdg+DBgLPKBB2yL4JfhfULpXd
/dvGVhetzbLiBcEttfvZKrjdoaEfrJd9/wDUaPWZDQplbmRzdHJlYW0NCmVuZG9iag0KNDEgMCBv
YmoNCjw8L0FydEJveFsgMCAwIDk2MCA1NDBdL0NvbnRlbnRzIDUyIDAgUiAvTWVkaWFCb3hbIDAg
MCA5NjAgNTQwXS9QYXJlbnQgMiAwIFIgL1Jlc291cmNlczw8L0ZvbnQ8PC9GMiAxMCAwIFIgL0Yz
IDE2IDAgUiAvRjQgMzQgMCBSIC9GNSA0NCAwIFIgPj4vWE9iamVjdDw8L0ZGVDAgNTEgMCBSID4+
Pj4vVHlwZS9QYWdlPj4NCmVuZG9iag0KNDIgMCBvYmoNCjw8L0E8PC9TL1VSSS9UeXBlL0FjdGlv
bi9VUkkoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZvc3NhdGktdGxzLWlvdC1v
cHRpbWl6YXRpb25zLTAwI3NlY3Rpb24tNCk+Pi9CUzw8L1cgMD4+L0YgNC9SZWN0WyA5MS4yMjQg
MTU2LjcgNzg4LjUgMjEyLjA0XS9TdWJ0eXBlL0xpbms+Pg0KZW5kb2JqDQo0MyAwIG9iag0KPDwv
RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMTg3Pj5zdHJlYW0NCnicxVhNj9s2EL3rVxDohQpi
mt8UC0PAxvYWKQq0SQz0UPTgrOWP1rYcW1sn/fWdIWVbyiZFdu11LpaGGr2ZefNIkf6QfEg44Yxz
LqTkjnjLidGcbIvk9xfJOhFkdnDgVnBlmh7TF8kbBAhPhVbcEP4A4dUIABDkp0QwaTzZJ91bQ7Rm
3GoymiaSjLaJU0zCmGVekdEk+aPHudO50D0uzE2uOFz7Ls9gmKtcCBwe5Aounuc2jmanQWdyIeGa
+ehrb9FJiGHu66euYdpcorO/yQXaXMYr2CZC4rtuECHBGyFDGvoYHx/bU3LKDMPoKxOz4iFQnQXU
0ZHB6TY660H+Jxn9nAxHj6Oze6uIdMxbZDESyBVT7kBg5p6Kq0+4Hpom9WfIaojshcKEDZSBzfOO
CuUFGqBgLm8DXzWZvhdfyvqRXzfABgXnDjLZF0g2umLP47iMbQrt6tv6OQQ1vdpvECIEmfD4iuCB
fyQ/DALtNec2cB69XGhdTAIdoFOqiRlxL9QWZRXj8vy2yEZbHDOZbiLTQSo0Hf3yLu1IStKOoYsd
WZcV3Do6KXaL1NDZupgEu0o9Lck+1bTc/k32i2oOw4qW0zSj01RaWmy7qcjoeL0Dn33qYCB4jNcI
oOnr/jC9FDtSsuzC7ETRNpDpr9NU8FNtytIbqM2easuatZHxFtksSLlOFV1+Au7gkf9WHjfbVHJa
VsBmeQdByuWOPJWuWFamG3VJL6H7sa79fAEZ3s1DendQzHhN3hchi9U95l7Bz2IDSS8LTOpjYACz
F4KWkPg/yAswUM3BsQgE7MarglRQg0YBbGC83FYv4YJvOQoUaLrCnyXQpKLYIhNvIc7ot0spQxrJ
lH0OZTSQ6espNNBD6XtkYryGplVkHBh8X0DzqlSoUB6QtCuX91B3tQi6eIl8yCghsobxIhALs4Tg
JAQ8QcepMPQTSQ8MTYrzhBCqsEYw366icwlYy5m2LdjV/cdY5Op+iTWAkqDtxZlqbrUCJqn42hI2
XZb1HN2REpQqo1Kjvo8yFUGmoNGoanOB5IzQzKpWcpdg2EjFhGnBVvc4wc6mtLVACLhmcYHoyawx
bQBWQCacKXjMmTOObGeJ98xJIrKMAcoqkQ7e9gd7meiwVzvZVlgm1cl2cKMfmo7xlndtH9Fq+xit
tg/J1OYcd5nfwscXK/vC6NsHnEFA3eKMznEliPN+g9r7sQtfjDiBYSlnuPQVOBumqTWUlVv0nIEk
Ne3Wr+LyuwS3Lt5NokYBYlo9sstPrkrDXPauVdVjBXxGbM+MaMWGD6+k5S5OW1xhF9dKxmjYIn0n
Igys03DiacaulrurRXcwEb9X5Rkc5dqVL8qrid8K9znvV6vcSstEW/wlbqo2uJVYrHC39m/YWsPC
UqFVrq+mCOc83H6VF/x6EGEsAxc4ijtYpeE2HvSfKa/mTkBYwWz9VeT8h11xF/ZZz85NyEEKw1Qr
hSsoJkaGPQGcUpqh9QW2GlK50OsTbE/6R+6gmYEz/6y+Rnxx/N8mc+FLLaE2WYspa+UNe1RJ9pBZ
ByJJ5bPj30t4Zj3ECX8Mkb/+x+0doCVv/gMhnfZGDQplbmRzdHJlYW0NCmVuZG9iag0KNDQgMCBv
YmoNCjw8L0Jhc2VGb250L0FIQ0RUUytDYWxpYnJpLUxpZ2h0L0Rlc2NlbmRhbnRGb250cyA0NSAw
IFIgL0VuY29kaW5nL0lkZW50aXR5LUgvU3VidHlwZS9UeXBlMC9Ub1VuaWNvZGUgNTAgMCBSIC9U
eXBlL0ZvbnQ+Pg0KZW5kb2JqDQo0NSAwIG9iag0KWyA0NiAwIFIgXQ0KZW5kb2JqDQo0NiAwIG9i
ag0KPDwvQmFzZUZvbnQvQUhDRFRTK0NhbGlicmktTGlnaHQvQ0lEU3lzdGVtSW5mbyAxOSAwIFIg
L0NJRFRvR0lETWFwL0lkZW50aXR5L0RXIDEwMDAvRm9udERlc2NyaXB0b3IgNDcgMCBSIC9TdWJ0
eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvVyA0OSAwIFIgPj4NCmVuZG9iag0KNDcgMCBvYmoN
Cjw8L0FzY2VudCA3NTAvQXZnV2lkdGggNTIwL0NhcEhlaWdodCA3NTAvRGVzY2VudCAtMjUwL0Zs
YWdzIDMyL0ZvbnRCQm94WyAtNTExIC0yNTAgMTIwOCA3NTBdL0ZvbnRGaWxlMiA0OCAwIFIgL0Zv
bnROYW1lL0FIQ0RUUytDYWxpYnJpLUxpZ2h0L0ZvbnRXZWlnaHQgMzAwL0l0YWxpY0FuZ2xlIDAv
TWF4V2lkdGggMTcyMC9TdGVtViA1Mi9UeXBlL0ZvbnREZXNjcmlwdG9yL1hIZWlnaHQgMjUwPj4N
CmVuZG9iag0KNDggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjIwMi9MZW5n
dGgxIDEzNTY4Pj5zdHJlYW0NCnic7XpreFvXceDcc+/Fk3gSAAmC5AV4SfABkuBLfIkiwAfAB0iJ
FAkbJEMJlPiSLIq0HtTDkk0rsR60XDtrJ46T+JGYsVqzdgGmdmml7rqM6zpNJWf7ufYmrbTebL/d
trvcNLvxfhvZInfOBUCJEhXL/tFvv68+B8CdMzNnzpyZOXPOAQAMACTBDLDg3dbjLtv3D1PfRMxf
4zu8e/qQvWK+dBiAKcT3O6NTYxNTH3/tJAD5DYDsx2P7jo16ptO/D6BcBDBcHB8ZGmZyziDNdgj7
V44jQjOguA/bf4jt7PGJQ0cv/ax4N7Z/BqCZ2Te5eyh1R5sIkN+F8pYmho5OyRwKLUCJCfnt+4cm
Rhy+2gexXYHjvzw1efDQygqMA5R+ROlTB0amTv5ez/8FKMMmuQ4sl4+a8qDgn+HLsUdm7Mn+DE4T
UADRsYQQjiXcC0B+5QX7AxAvnT12O31+wslgBZi35c8Rpx2Y5ymOXeC1dDTg5M/xE+ziypMUy2uv
/wK+SGmBHTANL8J2OPiF+scLPw1qNgoySAZYvba6vPISvhdR0xsYSU8uAzGGWJ9V5er/RI5kCaeT
uH5NuVYW2UaQSX3V1/8SsR8jLYdVYluzWont/03OUDjWQ/7cyh+tXJCoaq6K+Q7aoQdqoQE6oBfn
FoSdcB88iO12hHfBcXwOwD44DKegCQJwD9JHYQJt8BB8F+3wFvwN9gxizzGYgiPY8ww8AU/DPPwE
BmEYOQ/BAzAL34M30fP3o7yvwnn4FtIH43JewecUHMMYPgdfh28jpRVpdMRtyH8UZczCXhztCex3
BHnB6x0JBXt7tnd3bdva2RFob2tt8fuamxobvJ76LXWba2uqqyo3uYuLCvOcOdlilpBqMuh1GrVK
qZDLeAwfBgp9oj9sjzjDEc4ptrYW0bY4hIihmxDhiB1R/vU8EXtYYrOv5/Qi5+gtnN4Yp3eNk9Hb
66CuqNDuE+2RS82ifZHp7w4h/Fiz2GePLEtwpwRzTqmhwYbDgT3svtTxZnuECdt9Ef/0+Kwv3Izy
ompVk9g0oioqhKhKjaAaoUieOBVl8uoZCSB5vtooLh4NHTbC5viGhiNd3SFfs83h6JNw0CTJisia
InJJln0P1RketUcL35o9v6iHXWFX0rA4PPSVUIQdwk6zrG929kzE4Irki82R/OP/kIpTHokUis2+
iEtEYYHtawMwET5HL9pnPwZUXlz+H+sxQ3GMLEf/MVCQTnHNTEhPwIC6oYY4P4eD6vLoohd2YSMy
0x2Kte2wy7YAXrerL0LClPJWgmIOUspMgrLWPSw6qKt84fhrejw1MrPLXlSI1pdeOfhCuj3COsO7
do/T59DIrNjcHLNbbyjibUbAOxSfqy9a4kb+oTBOYg81Q3co4hanIiaxMcaACDv1wZ6ekNQl3i1i
aopgto73irh9zVQvu2823BxTkMoSu0NvQPnqR9EKu+2H5VABfVSPiKUJneL0zYaGRyNC2DaM8Tlq
D9kcEW8fmq9PDI30US+J+kj+RzicQxpR6oVzu4U7wUxnLs9R2EPExvZRbyHC7scPsbEOCXp0l9Sk
Hm2ss4cYGyTYcJQ4B4XWycEGm9PUSkks7drUanP0OWLld6hki+vE50QUN8nSI2JNp9g4d1Qtxk0V
yrf7RppvUnCdUD6uYFzaxnoSaov4wNhDQd3ZmiCxObhyEUdQjISiXky1R6DLHhJHxD4RY8jbFaJz
o7aW/BvoEQPd/SHJ2/Eo6V3XitGr12hxKEKaMAD9LlvCp1K7RWqvNVtvIbclyPZZhRjomaWSxbhA
sOPywRnLnG1Dj1YbK3Bd+jG1if4h0a63+2eHFldnds1Gvd7ZKV94vJbKENuGZ8WeUJ1NUm176KTt
OB3KCAEm0NtYVIiJpzEqMme7o17mbE9/6A097sNne0MLhCFN4ca+aDbSQm/g1u2VsIRiKZI27LRB
JW3HhkLit73hBZiRqJyEkNq7FxmQcIoEjoHdiySG0ydwBHFcDOeVcLSgh1LH0b6Ya332YeqbE33j
s+E+urLAgn7EFxNhxHqIELE+yhBZUkQljjRG1GIjxXso3hPDyyhejlHBWBi0pm9cTNhK9I0PjSwA
w5iTxeooA4bKItzYoRjPJpdw12ZBDjXQCe3e7CI5qV1o1r6S0oyVMPZXFRxDBAXDiptkbLfV0Obh
GHBfuXrl6iUPvg3GmhrGfeXK1WUKud36ZaxXLpeUMgaHQXqbtEQuN8nErGKyKbeisry8rJ5sqnCK
WVoi4Soqq+rZ8rJMwpoSmHoitS99OsT2fPp/yMPZDaEK3mJWaVU8l2Y2lTbkGUK7cj0ldjkr51le
Ic+ranL4RpuyPpJpUwzGVJ1Mpks1GlK0eCK59r947SfV3KlPHmQtdTu8IvOyQk44nns3xWwr9mZ3
fcVgNrBKXVJSskKebNQ4G/uvn0hIiD/xGAgtq9dkb/MmqIOtXqdblQR1JSVJZUt1SSmpmhxRTMpa
Sk2q2l6wvURUs8aM7cYgHwSPx2NMqfF4GKv7/dRlY43VXVNjrNHHYSPCNSWlOVqWTjqXEZkE5Kyo
rKQGSGHKmZhpbkByvpvVmG1GY7pZw65cJiv/SNTJtmRThgWbX+c1NoslTcsTxscwLiLT2SwGs0ZO
GD9hthBem2q2pGkYzqJQy1hWplZwuZ/8fA1+T29UIaSSf/J1blKukq2DOZURj3sExld/xTrYJSgH
Lwy99nT1hWpSurj6L95NKk1rXnJ1MlElpyUThS4V28qUiijk5gpovtoFQ0PBS1lixlzxphctluL2
LXNJnVwHmmjZU+Ne1l//zTKjv7r89mANRlAZmsW1Y3DQNZhjkmHgOJ2bNslka6FRvqmimNwIn3qO
2sUspxizyVJeVlnFOjRmoyFVs+XJbS33by2oP/DCridSK++prwu3ulU4KVZm9faESwZntmUd+UHr
vlZxd3/LAz6TSs3zatVIY2uOb9eWwGR7ztbavrrMjOwMTm1IMlutWRnGot4Htr6RVuYv2jrY1pGw
xzm0hwu3w93ehunS06XkaDHzdP6FfPLNvJfyiFK0ikQpWAWiGJVPy0lysqNwAVyMq4JbcGwqfJHj
0t1zzvbUOW2Wci69EzxoCg8GiFsySNmVQQqXlA6iPWhhcCU5TJmEriJp3iat7OZFY86tlJaWnD3n
NF5/2tFxvM8z3EZnLWMJOrSid9K75/v7azbv/87O0ScGXQ+ws19rHmtxskSebes9O1RhsVlkGpNO
jodVldVq8jzw+tGDrz/U1HzwW73qJ75f3jtZh9miaeVJ9gTOuh624ln8ovdk/qaaTSSpNL2UuEo2
lxC3PUnfmuRKdxFFTV5bHqkWW0WSJhaIJCUjN4NUWv1WYrbm4IcyR0mMkaKWaLlnQb4tauN0JWy5
vKhcbrPJy4s4uvRC0YKcsK5Ezla3zyX1zJnN4Wp2rq6twN44V90+MGffBh7JYh6agtzLHyzjokPb
lWE0pWBGcrsNiJDyEla0ZKzswPCKmVO0WMxS6nHmymQYQSkpmaz5plxUhfGHSYp+UhtbUhxlFjaW
wKR4qyfJFc5cXMfxFnvCqH28wFHafyKwZb9gSmur/bh+YntJ6dgLk3u/sdOld5Tay0tKsjLsZX0n
2nN9GYzaoPtP949v6qpIu3+0srsibed9/Su/zS62qb7xSO/9/kz2oXSLa6S682hPYZbVVJHlrCAq
krn5ntq6/T2lOQ2hcrG+usKW1l5Qv9Pp7Pd0HOstUsrTVv772KHs+u3Fwwezt3Rf393oZ5XpZe6i
lPYOR6WfmvXC6jX2Ef4AXny3eJ1Od6Xb72bBrXcTRYuL8RsZdbSswBTNLLDq54ras/3WDp4uVw+1
NONeLntfMiVGZU7CVAZpWcrkhhuIeEwaYvnMzD4i02B+TtHI0iq6K32zHdikaZrntTF0+1PtfccD
DhNGK8fhB7H27gnk79p5/UgCwzfT9ctiSrr+0+2ddaNnw3QVPrV6jSnhBTCDA2xejeW1dHNUJfyB
Vd8mKX11GTWmCufcploy3Zmof9GxTOat+hiz8BhP32sasecS4zOlJVkO9KMjZksmE21pBv3reA/S
+6VhcdCNhrx9GNPts4t7iI/iKuuCI96ulk7G2VnZSaBT30l4n9lHcpurmoms2dKMHvMwlU6/k6Db
/MnRzMwyVVTo2tZFoIvpqs+NlunnAu3Zcw3t9f6i6raijjVf4g5E1w4qWvP+4OCyAZdPjbRC4tnm
d/n2Ts42xzev2H5l5qMxn2v5lNJAuefhTtqkk0+VmjeFgNlgsCTxW8/7avqaS3TunoA/K3i4RbgR
DEXeW4LhdswN98zcu9VW2pxf0eJKxijpWIt4tGcZNHjz2ZLkEqKwuGnks5VGv5EUoOXUUQ8yZtKQ
L7BmtyUMRZML435/EBNITSzs7yLqzZ8d9fEpf/Ozon7dtKSgJzCMO8+7OJtkyIWveL17co7lkFHH
tIOM2qZtZE/KsRRyxsg8bWBkhtMGotAwZxWMUn5OjlsDozAt0CNq5oIqzzqnaxd/wHdKSZRuOTjL
ktK4/+NbzvpzmTy+/Zrj2xD7bvXkS/v3Pn/fpqrJlyb3Pr+38sFM/3SoezqQnXgyv9z3+ulA08mF
qX2vP9LeeHLheOf5+zy1Y+e7tz62t7529DzO5wLuKW/ifApgC7R5i/dsPraZhDYze4qPFRM+j+FZ
xlGpippdC2BWVW5ycHwJbpu2Nv22mrmY9jQ1YeZ3v78cO0KsUz53A//ET1Tx6cgNllj6frN897/b
kedvaspZc5TGrNPhRlvQ0dFVtGv23tyTqTU7W7N9rVtdgXMB3+76DOa/Hrp4qsWQXelcKUq4ivuX
xCHqqy5PgSlw6pXDHY/tbzQVt1WuTA8MNU2cQxcEV39FfoSzboNRb/2Z1qdbSZqTUTsZM2E4wjRE
srPLypJsURq+Se3Fc1WqHxjCVVNVpMvAVBmqDJa6uQYbn99uidsAFzSuYtz1Bgfpbof+fF86QJS5
l9cbhEt4M3YcL5bF27LEzhf3sIz8qKTvRMDd2+y2qGgoqgs899YUd1QLeQ099/Y05GUHDndlNVXl
meX0fKGUKewVrW53S3FKXmPvvb2N6LiGsVanLiXNlGnVmLTydEe6Kc9TUFDrcogFdb2b3QOthWqj
Wa9OMuAZXCu3pFkseZX2wrrCrKz82m468dzVX5MB7mWohaC3WqXX6Ftdqs2qgIrVqDJURCyKpoBG
ryEajSE/H3QGweAxbDNwCkPRnNiWoZlLaSudk8fi+xJdxjsG3y7D07d7sHy5jBrFhWuZi4WGtBXE
jpiJIIkdsvCUYIjt7rRNBuS6DGeBqWlHne2MVs8p1PIziVx+TY5HaYPm2uatqbmZZgWv4Nl2c5pO
o+Sz26Y6SLnVqknWyK4mguSqDJtW6/UrY/tUSSo8aOJ8X8SV/TD7J5inPN5clSHNQPL1NXqi1tv0
RKHOlVKUEE0uastV89a27DltJx87SdN0Tne6QZqldtycvxPn5xtbsrR4K6vWEOzDvNaiN9J09A0p
HSUmJCWtc53YxLVw015FM9HY2TAR1zbkf+zdS9MWWUtWqGc+ruodOJdsCHnL9liPWQmzYFcySqUW
0mxRb3aaXZWWuuDWPqQlWl3azjSiSBParKrkNlWA2waB+C5Fr1A7Bt8fpDenNKv+ShoFqAtpVDvY
2OSqkp3OWy5P9LhmMWHKe5C3i8ZUDeFnFElk5U94tRVvQjrMhDaOsfCGdFOyNYlfeUWto0d9poHV
ytmDWkPsOvTpP7MWrRJvQAYNPWs8vvpbtpsP4Xm/Feq9wqbXPXxU58GanxaF/OxsQWl6kedLlM21
HcJcCbiXPVcu042VHk5pclq7JuMdmd6N2fjdmJUCL7Yab7ve3JqD2e6KwVPbZKmCzqKR8UqD1ZDW
OrzFluXb07plsNmlkqvlHG/avH1X+ciTYffKRbnJYU1zmPAi7kiz4pP9qP/RcAW78rFGI51lCulV
tygwXFU/Fsi3OWw04xnNyfb05NrRc58WpOdYlEpLTnq606xUmp1ohe+yz7BG/ijYoAoyvBobvKau
yn0tXZZlKWsBT/mlMozDSx9cfwcnue4sHb/ryzfASp76qtKYnpycblTySSbdo5xKZ9ap9XKGW8na
gKBTsFznpMWm43m86aYV5uVZPsAUxBKZUr6yfAcC9WEF+wx5Oa694NUWFr+WrofXjOnq3JTyhPof
LL+jl/SXvsCgd3Ons6IqOeEBfg1NIy+BRamSemqdSVLvUYURYwu1XnnlJgKd0BqFL5f0+1vphobh
xhjXK74BQUuA/uZGxA9/O3n66E5d3cegVki/z/zk75+dos+/eepE1Sf/dP0Xynn5c9hU4pxjBfvF
fp9SvfDJP326VzkvSbqpsGFOS78XirO/B8CdgrzP+9sS1wpv4vu+DWl/B29+XnmSZq9+dj/mN19M
tiS/f+O+sqUvLvPWwunvLIt9Hjo2xF9N/Pr2xYo8CVq+aF/2Hfpb4Ofs898gwv4UjmxE4zohso73
6Pr2HWV2QIQ7dLtMbvhGf+bnv1sW0jW3yf39WB/yHzbuy/9SGndDGvcETP6u8W4b66WYHO4ZmGTf
u8UOW+7g+xZIXzfmCXj184wpM0H9hnL7P9uv7Nv0d/LPV7g8uMCOwfBGNDniZX8Bw/y1GB151+UH
9jd3Nx4ZBpfsa+BSLIKLexrhR+KwA1x301/We3d8Nxf+v+AYKbePQWVxH9zAyVXgYt+Cplv73zrX
OO5CAmbehqc+SwfkubARnj2zTs6GPKjnhZvHu02Xwo19dkf+uCw6L7K0Xi6bCsGN+vDPrMeT7+HN
9WaZ70EuF1yP23Bs5OGuQa48D3Jlr3w2P+VBPV/8LL51uj4Nno3waOv8zyMH59hB/h4Okx5ox2cX
icBW5g3IJ09BBfkIDjP3wF6JbwbhbjjMtSMv5b8a74d9mF/jswD8zIeQS/tIenwo/WEFyGE8Wf8b
KBjX0vvL8mX5snxZ/n8o5DtMZgJmX4PH19EG8JJF8WNwah0+Df7qTvJYP96q/VCB4Df+bVTG+mW9
Y/3eF6sk/V+hrtxe2WGpzt1Ffe9G5Y5wV2+uvP8O9c9vrrKeDepPv0iVl95F/faX9cv6ZaVVkfGZ
9YTiSsU0/VaRDcP3gIOjwAIBPbjp/6ZJg+zHEPv2Ug79SAFOiTD9r38MZiAPWzGYgBa+G4dZ8MLL
cZhDnn+OwzxYGGMclkEekwe9MA574CDY459D+B6FSdiPcu1wRKLuxs8E/RCMwARMIccB5D2A2H1w
TKLuR/ohxO3DOoL342LENiOfHSmTkrTDyDECDmiAVrzzN+PYPeBCiPbZA7skaUXQgZ9jOOIh2I7c
Y9hrnzRSF/bwS/97v7vetVCCtRT1KJHq3fa7B0c9gJrukaxgj0u4296SZ2hZ+WTj72e831b+cm5V
+M/RVeHvnrpf+PmHxcIvPtgj/Mf3nxU+/KBQ+NsPqoSfXU4T3rs8Lly6/Krw15dnBN1lZkK4zOBj
81+9e0r4ybvnhb98t1J4Z2mr8BdLIeHtpZ3Cj5dGhT9fmhDeWpoRYEm/ZF9iJ+xLJUuEgoRiyGb7
EvPvLzqFP7tYK7x5cbvwpxcnhB9dPCi8cfGrwuLFY0LXRWZx9a0fXjx+yi89x/fHnsH+2LPRT5/e
1YvuMv9r0YDwx9FB4YfR3cJCdK8QiR4R/ih6Sng1OiC8NHe/8IO548KLc+eF55/NEJ57tkb47rNP
Cs98Kyh863yJMMucCz7CuoSvsS3CqYGZ4MPzM8GHBk4GH5w/GXSfZNwnPScnTz5/8r2TqydlxwaO
BI/OHwkKRx4/8vwR9ghzPHhi4HjwgfnjwanjzNmB08Ez86eDwunHTz9/mj3NHgh2TYenyTQC+0cn
gpEJZufE5MRDE+wEYg4NHAgenD8Q9B4IH5g6MHOAO0Amg/cPTAan5ieDkzJG2ItK7WkZC47PjwVH
W4aDI/PDwd0tu4JDLeGgN8x8paU/ODDf720L3ouM97T0BoPzvcGelu7g9vnuYLfML2xr2RrcyuYI
nS2BYMd8INje0hpsm28NthKX0NLiD/oZl5CdpRLErFQBWEaxyMAPLQzPLDJPRHt7XK7Aonx1eyCi
6BqIMGcjOT3009vdH5GdjUCwfyAUZZjf61tIY0hTr/QXY6n9yGOPQWNGIJLRE4q8kNEXiMwg4KXA
KgKQEbVAY9+Og67by8Fb4IMH6fNgvIGvQ2tkBt8Qf7risMuVoDOHdxw8dDgxhsSHiFgb1jozrtQd
GP//D5EhhIINCmVuZHN0cmVhbQ0KZW5kb2JqDQo0OSAwIG9iag0KWyAwWyA1MDddIDNbIDIyNiA1
NjNdIDE3WyA1MzUgNTM1XSAyNFsgNjA3XSA2MlsgNDE5XSA4N1sgNTA4XSA5NFsgNDUzXSAxMDBb
IDQ4M10gMTE2WyA4ODFdIDI1OFsgNDcxXSAyNzFbIDUyMCA0MjVdIDI4MlsgNTIwXSAyODZbIDQ5
NF0gMjk2WyAyOTldIDMzNlsgNDY5XSAzNDZbIDUyMF0gMzQ5WyAyMjFdIDM2NFsgNDQxXSAzNjdb
IDIyMV0gMzczWyA3OTEgNTIwXSAzODFbIDUyMV0gMzkzWyA1MjBdIDM5NVsgNTIwIDM0NV0gNDAw
WyAzODddIDQxMFsgMzI5XSA0MzdbIDUyMF0gNDQ5WyA2OTldIDQ1NVsgNDQxXSA4NDVbIDQ2M10g
ODU1WyAyNjNdIDg2MlsgNDA5IDQwOV0gODgyWyAzMDZdIDEwODlbIDQ5OF1dDQplbmRvYmoNCjUw
IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMzOT4+c3RyZWFtDQp4nH2Sz26D
MAzG7zxFjt2hgkDTtBJC6uiQOOyPxvYAlJgOaYQo0ANvv8SmndbDIoH0kz/bn+OEeXksdTex8M0O
TQUTazutLIzDxTbATnDudMATprpmWgj/TV+bIHTJ1TxO0Je6HYI0ZeG7C46TndnqoIYTPAThq1Vg
O31mq8+8clxdjPmGHvTEoiDLmILWFXquzUvdAwsxbV0qF++mee1yfhUfswEWI3My0wwKRlM3YGt9
hiCN3MlYWriTBaDVXXxHWae2+aotqhOnjqI4yjzJDZKQnngUI205En8iEkgiIiKlOBDtiI5Ee6Rt
QZSjn6Uzv/q42uZSeBmXW1IfFzXF5Z1tLpcWBbbY7ZEkDsH3ZE0mRGTNTebpURDRELkkQqPJhmom
xb9GE4H3kAg/Vuxq/DHqb9w/jNs6m4u1bpP4enCFfnmdhtsDM4PxWf77AXN0uSwNCmVuZHN0cmVh
bQ0KZW5kb2JqDQo1MSAwIG9iag0KPDwvQkJveFsgMCAwIDk2MCA1NDBdL0ZpbHRlci9GbGF0ZURl
Y29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA4L1Jlc291cmNlczw8Pj4vU3VidHlwZS9Gb3JtL1R5cGUv
WE9iamVjdD4+c3RyZWFtDQp4nAMAAAAAAQ0KZW5kc3RyZWFtDQplbmRvYmoNCjUyIDAgb2JqDQpb
IDQzIDAgUiAgNTMgMCBSIF0NCmVuZG9iag0KNTMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29k
ZS9MZW5ndGggMjk+PnN0cmVhbQ0KeJwrVDBUMABCCJmcq6Dv5hZioOCSrxAIAE0rBecNCmVuZHN0
cmVhbQ0KZW5kb2JqDQp4cmVmDQowIDU0DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTcg
MDAwMDAgbg0KMDAwMDAwMDA2NiAwMDAwMCBuDQowMDAwMDAwMTc4IDAwMDAwIG4NCjAwMDAwMDAy
NjUgMDAwMDAgbg0KMDAwMDAwMDM5NSAwMDAwMCBuDQowMDAwMDAwODgxIDAwMDAwIG4NCjAwMDAw
MDEwNDggMDAwMDAgbg0KMDAwMDAwMTI5MiAwMDAwMCBuDQowMDAwMDEwMTU4IDAwMDAwIG4NCjAw
MDAwMTA0MzEgMDAwMDAgbg0KMDAwMDAxMDU5NSAwMDAwMCBuDQowMDAwMDEwODM1IDAwMDAwIG4N
CjAwMDAwMzAwMTkgMDAwMDAgbg0KMDAwMDAzMDM1MyAwMDAwMCBuDQowMDAwMDMwNDk2IDAwMDAw
IG4NCjAwMDAwMzI1MzQgMDAwMDAgbg0KMDAwMDAzMjY2OCAwMDAwMCBuDQowMDAwMDMyNjk4IDAw
MDAwIG4NCjAwMDAwMzI4NjEgMDAwMDAgbg0KMDAwMDAzMjkzMyAwMDAwMCBuDQowMDAwMDMzMTg0
IDAwMDAwIG4NCjAwMDAwMzgzNzQgMDAwMDAgbg0KMDAwMDAzODQxNCAwMDAwMCBuDQowMDAwMDM4
NzEzIDAwMDAwIG4NCjAwMDAwMzg4NTYgMDAwMDAgbg0KMDAwMDA0MDY1NSAwMDAwMCBuDQowMDAw
MDQwNzk4IDAwMDAwIG4NCjAwMDAwNDMwNzYgMDAwMDAgbg0KMDAwMDA0MzIxOSAwMDAwMCBuDQow
MDAwMDQ0Mjg3IDAwMDAwIG4NCjAwMDAwNDQ0MzAgMDAwMDAgbg0KMDAwMDA0NTExOCAwMDAwMCBu
DQowMDAwMDQ1MjcyIDAwMDAwIG4NCjAwMDAwNDY3NzkgMDAwMDAgbg0KMDAwMDA0NjkxMyAwMDAw
MCBuDQowMDAwMDQ2OTQzIDAwMDAwIG4NCjAwMDAwNDcxMDYgMDAwMDAgbg0KMDAwMDA0NzM0NiAw
MDAwMCBuDQowMDAwMDU5NDI1IDAwMDAwIG4NCjAwMDAwNjAwMDQgMDAwMDAgbg0KMDAwMDA2MDQ3
MSAwMDAwMCBuDQowMDAwMDYwNjcyIDAwMDAwIG4NCjAwMDAwNjA4NjMgMDAwMDAgbg0KMDAwMDA2
MjEyNCAwMDAwMCBuDQowMDAwMDYyMjY0IDAwMDAwIG4NCjAwMDAwNjIyOTQgMDAwMDAgbg0KMDAw
MDA2MjQ2MyAwMDAwMCBuDQowMDAwMDYyNzA5IDAwMDAwIG4NCjAwMDAwNjg5OTkgMDAwMDAgbg0K
MDAwMDA2OTM2NyAwMDAwMCBuDQowMDAwMDY5Nzc5IDAwMDAwIG4NCjAwMDAwNjk5MjggMDAwMDAg
bg0KMDAwMDA2OTk2NiAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1Jvb3QgMSAwIFINCi9JbmZvIDMg
MCBSDQovU2l6ZSA1NC9JRFs8OTIxNzIxMzAxRTc1Qzc5NEU1NEExRUFBNkZEOEI5QTg+PDkyMTcy
MTMwMUU3NUM3OTRFNTRBMUVBQTZGRDhCOUE4Pl0+Pg0Kc3RhcnR4cmVmDQo3MDA2Nw0KJSVFT0YN
Cg==
--94eb2c11a66c2e8324055a394f73--


From nobody Wed Sep 27 23:22:43 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4A9132F6C for ; Wed, 27 Sep 2017 23:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 lg6PPlt5VSVn for ; Wed, 27 Sep 2017 23:22:40 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 7591B1321CB for ; Wed, 27 Sep 2017 23:22:39 -0700 (PDT)
X-AuditID: c1b4fb2d-a4dff700000019be-04-59cc952d38f7
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5A.EC.06590.D259CC95; Thu, 28 Sep 2017 08:22:37 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 08:22:36 +0200
From: Christer Holmberg 
To: Roman Shpount , Adam Roach , "Ben Campbell" , Bernard Aboba , "Bo Burman" , Eric Rescorla , "lemming Andreasen" , Jonathan Lennox , "Justin Uberti" , Paul Kyzivat , "mmusic@ietf.org" 
Thread-Topic: Presentation for a call if DTLS Association be started if not requested in the offer
Thread-Index: AQHTOBvxh7e1K2Boh0yXov/6g550d6LJ5oGA
Date: Thu, 28 Sep 2017 06:22:36 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_D5F2701A22CB4christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUyM2J7oK7u1DORBnsOCVjs+buI3WJ+52l2 i6W97ewWK16fY7d4f0HXYv/i88wWW6cKWUxd/pjFYsWGA6wWMy5MZXbg8vj7/gOTx5TfG1k9 Fmwq9Viy5CeTR+uOv+wes3Y+YfGY/LiN2ePWlAKPtmd32AM4o7hsUlJzMstSi/TtErgyPkzx LTiUWPHs9mHmBsa1kV2MnBwSAiYSO969Y+xi5OIQEjjCKPFp/kIoZxGjxPI7J1m7GDk42AQs JLr/aYPERQQWMUv8vNLPBtItLJAssWnvWhYQW0QgReL4xatg9SICRhLz58aDhFkEVCWmT3vD DGLzClhLrFr9ggnEFhIIkPh9ZAoriM0pECixeW8zmM0oICbx/dQasBpmAXGJW0/mM0EcKiCx ZM95ZghbVOLl439g9aICehIbTtxmh4grSnx8tY8RojdB4tvko+wQewUlTs58wjKBUWQWkrGz kJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHQL0cQLa1xPtZYchKFjByrGIULU4tLs5NNzLW Sy3KTC4uzs/Ty0st2cQIjPyDW37r7mBc/drxEKMAB6MSD29f05lIIdbEsuLK3EOMEhzMSiK8 KT1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhhZJug+ fXMu8nLlBG3BWb9f6sX7igW8jT3vltIfKXq20OEfQ0LTnMIp/2TYDlSZL9JxfFK4vyBOd2Xe oteTarZ66tomhxttz/BvbJuXmsB07Pltf4vvu28W/tFsjbies/7+P3kdrbPMUUqmp705TflT F1szzxSO5Rd0S+yvFHkgs5W37s/URUosxRmJhlrMRcWJAOL9zsj4AgAA
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 06:22:42 -0000

--_000_D5F2701A22CB4christerholmbergericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Roman!

I would request those that do NOT want to allow an answerer to trigger a ne=
w DTLS association to prepare a description (verbally or using slides) on h=
ow they suggest handling interoperability with legacy peers that may trigge=
r a new DTLS association in the answer.

Regards,

Christer

From: Roman Shpount >
Date: Thursday 28 September 2017 at 08:37
To: Christer Holmberg >, "adam@nostrum.com" >, Ben Campbell >, Bernard Aboba >, Bo Burman >, Eric Rescorla >, Flemming An=
dreasen >, Jonathan Lennox >, Justin Uberti >, "pkyzivat@alum.mit.edu" >, "mmusi=
c@ietf.org" >
Subject: Presentation for a call if DTLS Association be started if not requ=
ested in the offer

Hi All,

Attached is the presentation for the call tomorrow (or later today)

Once again, conference call information:

Join the meeting: join.me/112-807-485

Thursday, September 28, 2017 12:00 PM
Eastern Time (US & Canada)
In my time zone?

To dial in by phone:

United States - Los Angeles, CA
+1.213.226.1066

United States - New York, NY
+1.646.307.1990

United States - San Francisco, CA
+1.415.594.5500

United States - Washington, DC
+1.202.602.1295

Australia - Sydney
+61.2.9191.6319

France - Paris
+33.1.8288.3590

Germany - Berlin
+49.30.2240.3071

Singapore - national
+65.3158.1842

United Kingdom - London
+44.20.3582.4515

More phone numbers

Conference ID:
112-807-485 #

Need to share screen?  Download the app

Regards,

_____________

Roman Shpount

--_000_D5F2701A22CB4christerholmbergericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <92872EAABB13274E95F978FD3152D0AF@ericsson.com>
Content-Transfer-Encoding: quoted-printable







Thanks Roman!







I would request those that do NOT want to allow an answerer to trigger=
 a new DTLS association to prepare a description (verbally or using slides)=
 on how they suggest handling interoperability with legacy peers that may t=
rigger a new DTLS association in
 the answer. 







Regards,







Christer









From: Roman Shpount <roman@telurix.com>

Date: Thursday 28 September 2017 at=
 08:37

To: Christer Holmberg <christer.holmberg@ericsson.com>, "adam@nostrum.com"=
; <adam@nostrum.com>,
 Ben Campbell <ben@nostrum.com>=
;, Bernard Aboba <Bernard=
.Aboba@microsoft.com>, Bo Burman <bo.burman@ericsson.com>, Eric Rescorla
 <ekr@rtfm.com>, Flemming Andreas=
en <fandreas@cisco.com>, Jo=
nathan Lennox <jonathan@vidyo.com<=
/a>>, Justin Uberti <juberti@go=
ogle.com>,
 "pkyzivat@alum.mit.edu&q=
uot; <pkyzivat@alum.mit.edu=
>, "mmusic@ietf.org" &l=
t;mmusic@ietf.org>

Subject: Presentation for a call if=
 DTLS Association be started if not requested in the offer













Hi All,






Attached is the presentation for the call tomorrow (or later today)






Once again, conference call information:









Roman Shpount

















--_000_D5F2701A22CB4christerholmbergericssoncom_--


From nobody Thu Sep 28 01:58:01 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D706813462E for ; Thu, 28 Sep 2017 01:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr5EawUG24qk for ; Thu, 28 Sep 2017 01:57:58 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BF8134626 for ; Thu, 28 Sep 2017 01:57:57 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id q124so793138wmb.0 for ; Thu, 28 Sep 2017 01:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=orUdYYl4NNc/rsr8hyJUEhK86lugjfjsF0gQwCjSQLE=; b=XFf4s1fmNhoQbNRhNNkOsHdeLu6l2dkM5NOrDDHfxqZijdDBv+62bV4T4RrT0htCnZ cMo6CkChXkVc6vXFcOEri9gSiq/dtuKt36cQDIEHJyabZgcZCQ9n06UnvV6ZkePSe0WR Kg6SiGIBfOWH6G4dmyb/SvGDDBd7EcO79MSC4aMv5dm0gxTEcPYw/numcoT3qzVHKdZS hOoyegOx+PCFdt6XMDU0VfUbx/ZFxWt1CHseQXtrDGirSfr5v1VVO00cjQxCamfWgpRd qqQdT+dXSVuzwcafQ+hEeyDXE/hb74oFYbViABTtkhTxvRirYrTFFWEDQktKQQaxiUqV qdgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=orUdYYl4NNc/rsr8hyJUEhK86lugjfjsF0gQwCjSQLE=; b=RK7bP5x/UgQJ+Y4bo188MFvMF+yUFo76BMfkUxrGM0+v7V2AZ6gxdtOZEVgh2B2rW0 c/Wqum3f8LzBy3ztyp6TxrH8aZUHQpBLdgEtEE3PnZxz2+3VnA7a9gNt+rUowHuguuJ9 X6LXRIB52Qq+Fab2IbAlj8hDNJBqBpqCqAVutDmCY7LfuSemQsKuMpi3R33p9YEy9WdH WRak5u0Ov/UhDtCHJahr6QDl68aDEk4caf2dER7oCyko5fD4pBFTr4VUfyvKiM162ax6 maTAK5zwL8ZnJhYZopZQulIMsUTDMcxi4j0kw0SnoBwj6JLAem5ACx3IyXEZZOvMKAY9 S54Q==
X-Gm-Message-State: AMCzsaVid0BN/f3bCdYOSPDPEnRiMEqRm+JHPqgYDAYHxLWgAYhQ8IBV DfnxbO0yOiQXiWNS/s5YqGnJEyNKudsGwYMJBS0=
X-Google-Smtp-Source: AOwi7QCAn3pGEBL7T2cL+0prYi3EvE/D8wiejDNBsxkFHgrD8IAZ7lRZ7VAzX5WWcu96hEeVjUBC2POAVJ+N1aG7jVE=
X-Received: by 10.28.87.147 with SMTP id l141mr408515wmb.144.1506589076138; Thu, 28 Sep 2017 01:57:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.150.10 with HTTP; Thu, 28 Sep 2017 01:57:55 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se>
References: <150540502703.12603.17962279219166496882@ietfa.amsl.com>  <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se>
From: Andy Hutton 
Date: Thu, 28 Sep 2017 09:57:55 +0100
Message-ID: 
To: Christer Holmberg 
Cc: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 08:58:00 -0000

Christer,

I agree that ideally we should have all the associated procedures in
one place and having two specs is not ideal however we have been going
round this circle for a couple of years now and just need to get this
done.

Originally we wanted this work to be done in MMUSIC but it got
dispatched to SIPBrandy but it was later discovered that an update to
RFC 4568 was needed and that the SIPBrandy charter did not allow this
so we were told an MMUSIC draft was needed after all to update the RFC
before the SIPBrandy work could be completed.

I do not want to start again and waste another couple of years lets
just get it finished.

Regards
Andy



On Wed, Sep 27, 2017 at 9:35 PM, Christer Holmberg
 wrote:
> Hi,
>
>
>
> In the mail you referenced the following is said:
>
>
>
> =E2=80=9CI see your point but Currently SIPBRANDY is chartered to produce
> Opportunistic SRTP as a BCP. There is also a milestone to
>
> inform MMUSIC or other appropriate WGs of any changes needed to support
> Opportunistic SRTP (Not expected to be published
>
> as an RFC).  I think SIPBRANDY is just carrying out what they are charter=
ed
> to do.=E2=80=9D
>
>
>
> But, draft-ietf-mmusic-opportunistic-negotiation doesn=E2=80=99t really d=
efine any
> procedures =E2=80=93 it references the SIPBRANDY draft for everything.
>
>
>
> =E2=80=9C[I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time transp=
ort
>
>               protocol (SRTP) can be negotiated opportunistically.=E2=80=
=9D
>
>
>
> But, as the SIPBRANDY is only Informational, where are the normative
> procedures?
>
>
>
> =E2=80=9CThe exact negotiation mechanism is however outside the scope of =
this
> document,
>
>               an example mechanism can be found in
> [I-D.ietf-sipbrandy-osrtp].=E2=80=9D
>
>
>
> How can negotiation be outside the scope of the document, when the title =
of
> the document contains =E2=80=9Cnegotiating=E2=80=9D?
>
>
>
> In addition, the text says that the sipbrandy only contains =E2=80=9Can e=
xample
> mechanism=E2=80=9D.
>
>
>
> If we are going to have this document, I think we shall include normative
> offer/answer procedures. The draft DOES contain some normative procedures=
,
> but I think we shall have it all in one place. One shall not have to read
> both documents just to figure out the offer/answer procedures.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]
> Sent: 27 September 2017 21:58
> To: Christer Holmberg 
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] I-D Action:
> draft-ietf-mmusic-opportunistic-negotiation-01.txt
>
>
>
> Hi Christer -
>
>
>
> See this:
> https://mailarchive.ietf.org/arch/msg/mmusic/wov2yErrgtUZURyRyVuVZ6K-nLI
>
>
>
> Cheers,
>
>
>
> -G
>
>
>
> On Sep 27, 2017, at 9:19 AM, Christer Holmberg
>  wrote:
>
>
>
> Hi,
>
> I am currently reviewing draft-ietf-sipbrandy-osrtp-03, and the following
> question comes to my mind: do we really need
> draft-ietf-mmusic-opportunistic-negotiation? :)
>
> Section 3 of draft-ietf-sipbrandy-osrtp-03 already more or less contains
> SDP Offer/Answer procedures for OSRTP. We can change the name of section =
3
> in that draft to =C2=B3SDP Offer/Answer Procedures=C2=B2, modify the stru=
cture a
> little, and add whatever might be missing.
>
> Or, am I missing something?
>
> Regards,
>
> Christer
>
>
>
>
>
> On 14/09/17 19:03, "mmusic on behalf of internet-drafts@ietf.org"
>  wrote:
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Multiparty Multimedia Session Control WG
> of the IETF.
>
>       Title           : Negotiating SRTP and RTCP Feedback using the
> RTP/AVP Profile
>       Authors         : Andrew Hutton
>                         Roland Jesske
>                         Alan Johnston
>                         Gonzalo Salgueiro
>                         Bernard Aboba
> Filename        : draft-ietf-mmusic-opportunistic-negotiation-01.txt
> Pages           : 7
> Date            : 2017-09-14
>
> Abstract:
>  This document describes how the use of the Secure Real-time transport
>  protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP (Audio
>  Video Profile) defined in [RFC3551].  Such a mechanism is used to
>  provide a means for encrypted media to be used in environments where
>  support for encryption is not known in advance, and not required.
>  The same mechanism is also applied to negotiation of the Extended RTP
>  Profile for Real-time Transport Control Protocol Based Feedback (RTP/
>  AVPF) [RFC4585].
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-negotiat=
i
> on/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-0=
1
> https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-neg=
o
> tiation-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-opportunistic-negot=
iat
> ion-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/
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From nobody Thu Sep 28 02:14:32 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74B8134580 for ; Thu, 28 Sep 2017 02:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bqsu885_Wd1 for ; Thu, 28 Sep 2017 02:14:19 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D287E134575 for ; Thu, 28 Sep 2017 02:14:18 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id p87so563951pfj.9 for ; Thu, 28 Sep 2017 02:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ttdw2yWIYuDp4zp4YiEbGRvLg6ja/dm6aNNpCPzt3z4=; b=yjFfh5XBqTvSHx4B/TQuPGBxhSYKid0Lkx1KQGFCfjr52TbXRQw9zwYRVfNzp2E1SO rc65MdAsJJv2N5aHlgRl6b0d9bvV5FcZatNNLjOlYV11BF7ANRUhxGhTOlNnc91RhFST ju05Mq3aRdQq602/SeHmGF2lvjRlsys6pT3G3U42Rn5Ai/kMW8fR1wN2WjNSxxOEaUXJ +iNzdEirSUMnRfor873Ui1DGJ3tFU2z1FUXv5DEhIYa2IODV/Sp4PUyFOq4Gzl2WKGi/ E/G6T/gv3qxObR+BDjPfeajpA05JKlzqYoFAPQORAOl0Il8qwS58dIoW+kRNp18fEbh/ vE1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ttdw2yWIYuDp4zp4YiEbGRvLg6ja/dm6aNNpCPzt3z4=; b=FDytSi/HtuxcefMsjKoGqOQUwwE+QIM79msLsWSSyFG3ZcbJmSRH0HuFNtoOoipwdY b/xFmBmUXyDAIEtMbiODWFn7BzeNjq7t2GRuCiOSLlvzKNXyC1si9yThHyFWu1XyIGjC 8YMc5xCE5vqIMRiPa6K0ElW5eN1T1TPGZdejy+42WothGFfxTy0uH5Ru73g+I5Z7jhVS lo8XxXQA0LVyZQtrARNtB5fk8cKRmnewl22GCy9MUeHzs+4k44jy9F9oTqu7NACgmzi0 Byc/kf4RhZFxosYm4LLf2gVs5OhuDZ5TZanF7FLDHS0Fzih01vu77EwUH4fj5Ks5VcPc cEyQ==
X-Gm-Message-State: AHPjjUim4vowhguyZJF+NK69eEp5uj1a0RqQPOrjK0odzhM9M5txnu1A WZjlCVX8cGmuoJ0vjnEV3SwzqY+w
X-Received: by 10.159.253.148 with SMTP id q20mr3561803pls.308.1506590058327;  Thu, 28 Sep 2017 02:14:18 -0700 (PDT)
Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com. [209.85.192.182]) by smtp.gmail.com with ESMTPSA id k78sm2325966pfb.157.2017.09.28.02.14.16 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 02:14:17 -0700 (PDT)
Received: by mail-pf0-f182.google.com with SMTP id m63so564414pfk.7 for ; Thu, 28 Sep 2017 02:14:16 -0700 (PDT)
X-Google-Smtp-Source: AOwi7QB0imaPzoFm818qPN0bvfqLkE+c4ct2K4nHq77rvUWlyNUiZ3DZwfy8d45hBhJraHhCj1Qw5iQefyQwjsHSY5A=
X-Received: by 10.101.75.136 with SMTP id t8mr3671359pgq.282.1506590056413; Thu, 28 Sep 2017 02:14:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.189.2 with HTTP; Thu, 28 Sep 2017 02:14:15 -0700 (PDT)
Received: by 10.100.189.2 with HTTP; Thu, 28 Sep 2017 02:14:15 -0700 (PDT)
In-Reply-To: 
References:  
From: Roman Shpount 
Date: Thu, 28 Sep 2017 05:14:15 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Justin Uberti , lemming Andreasen , Bernard Aboba , Eric Rescorla ,  "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell ,  Adam Roach , Jonathan Lennox ,  Bo Burman 
Content-Type: multipart/alternative; boundary="089e08234420228144055a3c556d"
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 09:14:26 -0000

--089e08234420228144055a3c556d
Content-Type: text/plain; charset="UTF-8"

Hi All,

I would also like to see if and how exactly allowing new DTLS association
when not requested in the offer, contradicts JSEP.

Roman Shpount


On Sep 28, 2017 02:22, "Christer Holmberg" 
wrote:

Thanks Roman!

I would request those that do NOT want to allow an answerer to trigger a
new DTLS association to prepare a description (verbally or using slides) on
how they suggest handling interoperability with legacy peers that may
trigger a new DTLS association in the answer.

Regards,

Christer

From: Roman Shpount 
Date: Thursday 28 September 2017 at 08:37
To: Christer Holmberg , "adam@nostrum.com" <
adam@nostrum.com>, Ben Campbell , Bernard Aboba <
Bernard.Aboba@microsoft.com>, Bo Burman , Eric
Rescorla , Flemming Andreasen , Jonathan
Lennox , Justin Uberti , "
pkyzivat@alum.mit.edu" , "mmusic@ietf.org" <
mmusic@ietf.org>
Subject: Presentation for a call if DTLS Association be started if not
requested in the offer

Hi All,

Attached is the presentation for the call tomorrow (or later today)

Once again, conference call information:

*Join the meeting: join.me/112-807-485 *

Thursday, September 28, 2017 12:00 PM
Eastern Time (US & Canada)
In my time zone? 
*To dial in by phone:*

United States - Los Angeles, CA
*+1.213.226.1066 <+1.213.226.1066,,112807485#>*

United States - New York, NY
*+1.646.307.1990 <+1.646.307.1990,,112807485#>*

United States - San Francisco, CA
*+1.415.594.5500 <+1.415.594.5500,,112807485#>*

United States - Washington, DC
*+1.202.602.1295 <+1.202.602.1295,,112807485#>*

Australia - Sydney
*+61.2.9191.6319 <+61.2.9191.6319,,112807485#>*

France - Paris
*+33.1.8288.3590 <+33.1.8288.3590,,112807485#>*

Germany - Berlin
*+49.30.2240.3071 <+49.30.2240.3071,,112807485#>*

Singapore - national
*+65.3158.1842 <+65.3158.1842,,112807485#>*

United Kingdom - London
*+44.20.3582.4515 <+44.20.3582.4515,,112807485#>*

More phone numbers 

Conference ID:
*112-807-485 #*

Need to share screen?  Download the app 

Regards,

_____________
Roman Shpount

--089e08234420228144055a3c556d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi All,

I would also like to see if and how exactly allowing new DTLS association =
when not requested in the offer, contradicts JSEP.

Roman Shpount


On Sep 28, 2017 02:22, &quo=
t;Christer Holmberg" <christer.holmberg@ericsson.com> wrote:
=








Thanks Roman!







I would request those that do NOT want to allow an answerer to trigger=
 a new DTLS association to prepare a description (verbally or using slides)=
 on how they suggest handling interoperability with legacy peers that may t=
rigger a new DTLS association in
 the answer.=C2=A0







Regards,







Christer









From: Roman Shpount <roman@telurix.com>

Date: Thursday 28 September 2017 at=
 08:37

To: Christer Holmberg <christer.holmb=
erg@ericsson.com>, "adam@nostrum.com" <adam@nostrum.com>,
 Ben Campbell <ben@=
nostrum.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>, Bo Burman=
 <bo.burman@=
ericsson.com>, Eric Rescorla
 <ekr@rtfm.com>=
, Flemming Andreasen <fandreas@cisco.com>, Jonathan Lennox <jonathan@vidyo.com>, Justin Ubert=
i <juberti@googl=
e.com>,
 "pkyzivat@=
alum.mit.edu" <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>

Subject: Presentation for a call if=
 DTLS Association be started if not requested in the offer













Hi All,






Attached is the presentation for the call tomorrow (or later today)






Once again, conference call information:




Join the meeting:=C2=
=A0join.me/112-807-485




Thursday, September 2=
8, 2017 12:00 PM=C2=A0

Eastern Time (US & Cana=
da)=C2=A0

In my time zone?

To dial in by phone:

United States - Los Angeles, CA=C2=A0

+1.213.226.1066<=
/p>

United States - New York, NY=C2=A0

+1.646.307.1990<=
/p>

United States - San Francisco, CA=C2=A0

+1.415.594.5500<=
/p>

United States - Washington, DC=C2=A0

+1.202.602.1295<=
/p>

Australia - Sydney=C2=A0

+61.2.9191.6319<=
/p>

France - Paris=C2=A0

+33.1.8288.3590<=
/p>

Germany - Berlin=C2=A0

+49.30.2240.3071


Singapore - national=C2=A0

+65.3158.1842


United Kingdom - London=C2=A0

+44.20.3582.4515


More phone numbers<=
/a>


Conference ID:=C2=A0

112-807-485 #


Need to share scr=
een?=C2=A0=C2=A0Download
 the app


Regards,


_____________










Roman Shpount






















--089e08234420228144055a3c556d--


From nobody Thu Sep 28 02:22:43 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00501345AB for ; Thu, 28 Sep 2017 02:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNLL0W2l1GJo for ; Thu, 28 Sep 2017 02:22:40 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF139134571 for ; Thu, 28 Sep 2017 02:22:39 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id i6so563521ywc.9 for ; Thu, 28 Sep 2017 02:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=flZht4UNG6JRiRfN30jxRYrHEUMnCC9wZNWW+xIkM88=; b=1CWopgANGQlc8s9018bSmZEDiVqgrB/5PvuaOwo/PH5gKqUh2LTMZkObeSlg+dlyu+ i1SzzB4/9lLOXn2STiBP1q64haf/rqqHT8KYMswbsjckuoUgRmo2U7MF3ALj5YfTVUQT 2//wSV3+jFfit4QOUtAZsulZbO9gPtD7BFQFlIoU0zvQ09zRBS4sL23DKmasAzJHWk7F OGWb/II3Qf2sEaaca2IrbIgcVdTr9jm6Z1xtx8nmMJwvlJaa+FZqLVSw08ZT5WPHy3Xm 5BU29SFtetvrDYZY+Pe4biaYRFYzzQzxOMDU/Vfxtq6fpGwnCau5FaMnlJTNbmNcgYa3 SLrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=flZht4UNG6JRiRfN30jxRYrHEUMnCC9wZNWW+xIkM88=; b=rXXbZHXZUChRAPly+VHSEiQStyIgUUheez9t4kciy8DqoPggaKCwR65dTwOkHT+Gy6 JYedfWkUpqUH8TgtW0akVTslXpcUq3Pfz7u5YJ46lMCJ4KsLd+Knm6oAWYCCd3SehX64 HwVDO+RkWT92D6V3jx8oG/QeUuXJie9OXyITRs7LV1z22PZK7TbOOZWFXamh24+vg02b vre9pHbDD4IsSE+LBJbqEfkEBbYvwyfk4i+v4MgymHNH6krL2HbleciRc0gV9DKHuHZ9 0WpGLBsZT/npTRkWRCioxBLYyPb5wT+xgkJF7897ugYrN5yLIqGc5fCZG0tYoabSCkUt J8bA==
X-Gm-Message-State: AHPjjUjAySkWwPI8wonpafWsydI3ScqZqVCYTO7wEO7Yebbh1fUvifna R+v17dPEeCLU5BRD9Yu1WV/EgpNelfWZCG1KmGEtIg==
X-Google-Smtp-Source: AOwi7QDeFHxFm/XezTotbylmUQPgnJ1/AJtKn8/GoqDUPc+L9xYtYGb61FD9XATq1mHiBKaVcMadIJ0wXjURHvd/jrQ=
X-Received: by 10.37.201.193 with SMTP id z184mr1631640ybf.468.1506590559044;  Thu, 28 Sep 2017 02:22:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.80.133 with HTTP; Thu, 28 Sep 2017 02:22:38 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B562FDDE3@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B562FDDE3@ESESSMB109.ericsson.se>
From: "Ali C. Begen" 
Date: Thu, 28 Sep 2017 12:22:38 +0300
Message-ID: 
To: Christer Holmberg 
Cc: Flemming Andreasen , mmusic ,  "draft-ietf-mmusic-rfc4566bis@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c056e2a181fce055a3c73cc"
Archived-At: 
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23: media description vs media-level section
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 09:22:42 -0000

--94eb2c056e2a181fce055a3c73cc
Content-Type: text/plain; charset="UTF-8"

I think we should removee the media-level section, seems redundant and
stick with media description.

On Tue, Sep 26, 2017 at 9:39 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> One editorial comment:
>
> The draft uses both "media description" and "media-level section"
> terminology, but at least I can't see any difference. The definition of
> those terms are also identical:
>
>         "Each media description starts with an "m=" line and is terminated
> by either the next "m=" line..."             (section 5.14)
>
> ...and:
>
>         "Each media-level section starts with an "m=" line and continues
> to the next media-level section..."    (section 5)
>
> "media-level section" only appears in one paragraph of the whole document.
>
> Do we need both?
>
> Regards,
>
> Christer
>
>
>
>
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming
> Andreasen
> Sent: 18 September 2017 15:59
> To: mmusic ; draft-ietf-mmusic-rfc4566bis@ietf.org
> Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23
>
> Greetings MMUSIC
>
> This is to announce a 2 week WGLC on the draft:
>
>       https://www.ietf.org/id/draft-ietf-mmusic-rfc4566bis-23.txt
>
> as Proposed Standard. Please review and provide any comments you may have
> on the document by Monday, October 2, 2017. Comments should be sent to the
> document authors and the MMUSIC WG list. If you review the document but do
> not have any comments, please send a note to that effect as well.
>
> Thanks
>
> -- Flemming (MMUSIC co-chair)
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

--94eb2c056e2a181fce055a3c73cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think we should removee the media-level section, seems r=
edundant and stick with media description.
=

On Tue, Sep 26, 2017 at 9:39 PM, Christer Ho=
lmberg <christer.holmberg@ericsson.com> wrote:<=
br>
Hi,



One editorial comment:



The draft uses both "media description" and "media-level sec=
tion" terminology, but at least I can't see any difference. The de=
finition of those terms are also identical:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Each media description starts with an &qu=
ot;m=3D" line and is terminated by either the next "m=3D" li=
ne..."=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(section 5.14)


...and:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Each media-level section starts with an &=
quot;m=3D" line and continues to the next media-level section..."=
=C2=A0 =C2=A0 (section 5)



"media-level section" only appears in one paragraph of the whole =
document.



Do we need both?



Regards,



Christer













-----Original Message-----

From: mmusic [mailto:mmusic-boun=
ces@ietf.org] On Behalf Of Flemming Andreasen

Sent: 18 September 2017 15:59

To: mmusic <mmusic@ietf.org>; =
draft-ietf-mmusic-=
rfc4566bis@ietf.org

Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23



Greetings MMUSIC



This is to announce a 2 week WGLC on the draft:



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://ww=
w.ietf.org/id/draft-ietf-mmusic-rfc4566bis-23.txt



as Proposed Standard. Please review and provide any comments you may have o=
n the document by Monday, October 2, 2017. Comments should be sent to the d=
ocument authors and the MMUSIC WG list. If you review the document but do n=
ot have any comments, please send a note to that effect as well.



Thanks



-- Flemming (MMUSIC co-chair)



_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic




--94eb2c056e2a181fce055a3c73cc--


From nobody Thu Sep 28 02:29:46 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9E2134585 for ; Thu, 28 Sep 2017 02:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eGf4i3-pFOI for ; Thu, 28 Sep 2017 02:29:42 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB761321A6 for ; Thu, 28 Sep 2017 02:29:41 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id w22so569349ywa.13 for ; Thu, 28 Sep 2017 02:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ka0pfcfSRIHJpUGVr89+COvGaPrVeDvhoD2G7U+S1FE=; b=jzh0CFSpLK+LtdJHBtvguZzAXF7qZxeUpyk6WPdJfov5OC5TfobnDFYnPUt3SObiWW dxIB8Ee0JaHo3K8Nr7TeV5I1k9BzmYevLqRN8UfPnd89q0nfFb9fetPS3a8P7E8nM7dg iQADXsQJ+t2Fvr1GJgYD9kOIG1dSO8UxGl9vxAQ3RPVVBYRg6+npeX9pCkI5NRyGEa3s AkC1CoTvrMq5gAicCGHiM+MgLJcYOqwLt03KMSFYvbdct8NdExa+qJcFeERsVSq1WNQO XeOMwgmiRbJCzEop5YMSORUoWqmMhmXFMnAApE3b2D+UEvpdbrA+WHMzDkMnm2ueIi2y ovuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ka0pfcfSRIHJpUGVr89+COvGaPrVeDvhoD2G7U+S1FE=; b=QaVnQv1jV+HC3QZEop7ZQP7b0BHUkXkM0krkOP8dAXAd1BiWjUAoMcI4Rzxg6M91fq Q7LyAuGf38lpGOYcGxn/I9LamqARSBtGk6bbDwihgHwggD2HSPVjk/nzNf03YAfWyYo8 LSsrDOJq2w+Y0+TM3J/Gm3/HWkkpqIlcs7jzOmQHLpntOnBtMMzz4ZA+B7N33486ox7l ugzZ2OAWNtyL3hAj4/ZhGyDUWRDigK9esldhsXJ11R3KMjCbU7cI6H1Z0gsAKTEEJOw9 lROIajPWrxb/mTfimdFgg+KZ5FcjR+FZbIe6Au/EAj8brksvG34NsQZW0rUbexLPWBQx CJIg==
X-Gm-Message-State: AHPjjUgmG8e6yYraua+adibJt/KU4PAyXyNCnJkP6NwWd211J6/JaI2m UYco/gTt7DyLLKX334dXJuxpt+png+PZYAbZaI8uDg==
X-Google-Smtp-Source: AOwi7QBmxI36uoN2teb5Bygr53STt82WggEH+gr7delsG2dbcvDir3vE+uV2v0xrot34aH7SNs9iRFR8tvGY1btx/hg=
X-Received: by 10.129.94.133 with SMTP id s127mr2951191ywb.101.1506590981037;  Thu, 28 Sep 2017 02:29:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.17 with HTTP; Thu, 28 Sep 2017 02:29:00 -0700 (PDT)
In-Reply-To: 
References:   
From: Eric Rescorla 
Date: Thu, 28 Sep 2017 11:29:00 +0200
Message-ID: 
To: Roman Shpount 
Cc: Christer Holmberg , Justin Uberti ,  lemming Andreasen , Bernard Aboba ,  "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell ,  Adam Roach , Jonathan Lennox ,  Bo Burman 
Content-Type: multipart/alternative; boundary="001a1149173c3f3756055a3c8c58"
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 09:29:44 -0000

--001a1149173c3f3756055a3c8c58
Content-Type: text/plain; charset="UTF-8"

The relevant text is here
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-23#section-5.8.3

         tls-id value, which MUST be set according to
         [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
         and the tls-id value is different from that presently in use,
         the DTLS connection is not being continued and the remote
         description MUST be part of an ICE restart, together with new
         ufrag and password values.  If this is an answer, the tls-id
         value, if present, MUST be the same as in the offer.

This is no longer precisely correct because you've made the answerer
provide its own tls-id,
but the clear implication is that the answerer cannot unilaterally restart
DTLS. It's when
we went to update it to handle the newer syntax, we found the conflict.

-Ekr


On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount  wrote:

> Hi All,
>
> I would also like to see if and how exactly allowing new DTLS association
> when not requested in the offer, contradicts JSEP.
>
> Roman Shpount
>
>
> On Sep 28, 2017 02:22, "Christer Holmberg" 
> wrote:
>
> Thanks Roman!
>
> I would request those that do NOT want to allow an answerer to trigger a
> new DTLS association to prepare a description (verbally or using slides) on
> how they suggest handling interoperability with legacy peers that may
> trigger a new DTLS association in the answer.
>
> Regards,
>
> Christer
>
> From: Roman Shpount 
> Date: Thursday 28 September 2017 at 08:37
> To: Christer Holmberg , "adam@nostrum.com"
> , Ben Campbell , Bernard Aboba <
> Bernard.Aboba@microsoft.com>, Bo Burman , Eric
> Rescorla , Flemming Andreasen ,
> Jonathan Lennox , Justin Uberti ,
> "pkyzivat@alum.mit.edu" , "mmusic@ietf.org" <
> mmusic@ietf.org>
> Subject: Presentation for a call if DTLS Association be started if not
> requested in the offer
>
> Hi All,
>
> Attached is the presentation for the call tomorrow (or later today)
>
> Once again, conference call information:
>
> *Join the meeting: join.me/112-807-485 *
>
> Thursday, September 28, 2017 12:00 PM
> Eastern Time (US & Canada)
> In my time zone? 
> *To dial in by phone:*
>
> United States - Los Angeles, CA
> *+1.213.226.1066 <+1.213.226.1066,,112807485#>*
>
> United States - New York, NY
> *+1.646.307.1990 <+1.646.307.1990,,112807485#>*
>
> United States - San Francisco, CA
> *+1.415.594.5500 <+1.415.594.5500,,112807485#>*
>
> United States - Washington, DC
> *+1.202.602.1295 <+1.202.602.1295,,112807485#>*
>
> Australia - Sydney
> *+61.2.9191.6319 <+61.2.9191.6319,,112807485#>*
>
> France - Paris
> *+33.1.8288.3590 <+33.1.8288.3590,,112807485#>*
>
> Germany - Berlin
> *+49.30.2240.3071 <+49.30.2240.3071,,112807485#>*
>
> Singapore - national
> *+65.3158.1842 <+65.3158.1842,,112807485#>*
>
> United Kingdom - London
> *+44.20.3582.4515 <+44.20.3582.4515,,112807485#>*
>
> More phone numbers 
>
> Conference ID:
> *112-807-485 #*
>
> Need to share screen?  Download the app 
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>

--001a1149173c3f3756055a3c8c58
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The relevant text is here https://tools.ietf.org/html=
/draft-ietf-rtcweb-jsep-23#section-5.8.3

=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0tls-id value, which MUST be set according to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-mmusic-dtls-sdp], Secti=
on 5.=C2=A0 If this is a re-offer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0and the tls-id value is different from that presently in use,
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the DTLS connection is not being continue=
d and the remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description MU=
ST be part of an ICE restart, together with new
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0ufrag and password values.=C2=A0 If this is an answer, the=
 tls-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value, if present, MUST=
 be the same as in the offer.

This is no lon=
ger precisely correct because you've made the answerer provide its own =
tls-id,
but the clear implication is that the answerer cannot uni=
laterally restart DTLS. It's when
we went to update it to han=
dle the newer syntax, we found the conflict.

-Ekr<=
/div>


On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount =
<roman@telurix.co=
m> wrote:
Hi All,

I would also lik=
e to see if and how exactly allowing new DTLS association when not requeste=
d in the offer, contradicts JSEP.

Roman Shp=
ount


On Sep 28, 2017 02:22, "Christ=
er Holmberg" <christer.holmberg@ericsson.com> wrote:







Thanks Roman!







I would request those that do NOT want to allow an answerer to trigger=
 a new DTLS association to prepare a description (verbally or using slides)=
 on how they suggest handling interoperability with legacy peers that may t=
rigger a new DTLS association in
 the answer.=C2=A0







Regards,







Christer









From: Roman Shpount <roman@telurix.com>

Date: Thursday 28 September 2017 at=
 08:37

To: Christer Holmberg <christer.holmb=
erg@ericsson.com>, "adam@nostrum.com" <adam@nostrum.com>,
 Ben Campbell <ben@=
nostrum.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>, Bo Burman=
 <bo.burman@=
ericsson.com>, Eric Rescorla
 <ekr@rtfm.com>=
, Flemming Andreasen <fandreas@cisco.com>, Jonathan Lennox <jonathan@vidyo.com>, Justin Ubert=
i <juberti@googl=
e.com>,
 "pkyzivat@=
alum.mit.edu" <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>

Subject: Presentation for a call if=
 DTLS Association be started if not requested in the offer













Hi All,






Attached is the presentation for the call tomorrow (or later today)






Once again, conference call information:




Join the meeting:=C2=
=A0join.me/112-807-485




=
Thursday, September 28, 2017 12:00 PM=C2=A0

Easter=
n Time (US & Canada)=C2=A0

In my time zone?
To dial in by phone:

United States - Los Angeles, CA=C2=A0

+1.213.226.1066<=
/p>

United States - New York, NY=C2=A0

+1.646.307.1990<=
/p>

United States - San Francisco, CA=C2=A0

+1.415.594.5500<=
/p>

United States - Washington, DC=C2=A0

+1.202.602.1295<=
/p>

Australia - Sydney=C2=A0

+61.2.9191.6319<=
/p>

France - Paris=C2=A0

+33.1.8288.3590<=
/p>

Germany - Berlin=C2=A0

+49.30.2240.3071


Singapore - national=C2=A0

+65.3158.1842


United Kingdom - London=C2=A0

+44.20.3582.4515


More phone numbers<=
/a>


Conference ID:=C2=A0

112-807-485 #


Need to share scr=
een?=C2=A0=C2=A0Download
 the app


Regards,


_____________










Ro=
man Shpount

























--001a1149173c3f3756055a3c8c58--


From nobody Thu Sep 28 02:35:57 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286941345BF for ; Thu, 28 Sep 2017 02:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aDnfdKrpSKdN for ; Thu, 28 Sep 2017 02:35:53 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 AF7DB1321A6 for ; Thu, 28 Sep 2017 02:35:52 -0700 (PDT)
X-AuditID: c1b4fb25-94fff70000005333-d4-59ccc276a421
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.29.21299.672CCC95; Thu, 28 Sep 2017 11:35:50 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 11:35:50 +0200
From: Christer Holmberg 
To: Andy Hutton 
CC: "Gonzalo Salgueiro (gsalguei)" , "mmusic@ietf.org" 
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUAgACwtID//7EEIIAAs6WAgAA+fYA=
Date: Thu, 28 Sep 2017 09:35:50 +0000
Message-ID: 
References: <150540502703.12603.17962279219166496882@ietfa.amsl.com>  <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <169AAE0899FEF84FB261FDA3CE7FD273@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7jW7ZoTORBoun6lhcWreVyWLuFD+L qcsfszgwe0z5vZHVY+esu+weS5b8ZApgjuKySUnNySxLLdK3S+DKWLO0vGCHe8WMZYYNjGdc uxg5OCQETCR+zHfvYuTiEBI4wigxrfkKaxcjJ5CziFGi7VQUSA2bgIVE9z9tkLCIgLbEuyk7 wEqYBeIkDq+dzA5iCwuESZzafIwJoiZcYva7g6wQtp/Ex5snWEHGsAioSvzYngVi8gpYS6zd 7QOxaAuTRFcPM4jNKRAoMevqQjYQm1FATOL7qTVMEJvEJW49mQ9mSwgISCzZc54ZwhaVePn4 H9gmUQE9iQ0nbrNDxBUldp5tZ4bo1ZL48mMfG8haZqC179oTIcKKElO6H4KV8woISpyc+YRl AqP4LCTbZiHpnoXQPQtJ9ywk3QsYWVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbcwS2/ VXcwXn7jeIhRgINRiYeXfdGZSCHWxLLiytxDjBIczEoivI27gUK8KYmVValF+fFFpTmpxYcY pTlYlMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwurgkn3taHZHYZ3mgRLQx5UnQ7ZQE7evp 6xaueq6tYT3ly95Qt38VT3caL4o93Rcf5mhsu/rT1AfFmkwO+e2aqdbP6j5cm5zFVaVR2GOz 63DH1147he2RTTJfQr/f5WhYUbSFP9Zg4l/x9eefPYifeHbG0m3b9j+dZePMkfPkm9+X4oa9 gQoZSizFGYmGWsxFxYkAnFd1arQCAAA=
Archived-At: 
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 09:35:55 -0000

SGksDQoNCj5JIGFncmVlIHRoYXQgaWRlYWxseSB3ZSBzaG91bGQgaGF2ZSBhbGwgdGhlIGFzc29j
aWF0ZWQgcHJvY2VkdXJlcyBpbg0KPm9uZSBwbGFjZSBhbmQgaGF2aW5nIHR3byBzcGVjcyBpcyBu
b3QgaWRlYWwgaG93ZXZlciB3ZSBoYXZlIGJlZW4gZ29pbmcNCj5yb3VuZCB0aGlzIGNpcmNsZSBm
b3IgYSBjb3VwbGUgb2YgeWVhcnMgbm93IGFuZCBqdXN0IG5lZWQgdG8gZ2V0IHRoaXMNCj5kb25l
Lg0KPg0KPk9yaWdpbmFsbHkgd2Ugd2FudGVkIHRoaXMgd29yayB0byBiZSBkb25lIGluIE1NVVNJ
QyBidXQgaXQgZ290DQo+ZGlzcGF0Y2hlZCB0byBTSVBCcmFuZHkgYnV0IGl0IHdhcyBsYXRlciBk
aXNjb3ZlcmVkIHRoYXQgYW4gdXBkYXRlIHRvDQo+UkZDIDQ1Njggd2FzIG5lZWRlZCBhbmQgdGhh
dCB0aGUgU0lQQnJhbmR5IGNoYXJ0ZXIgZGlkIG5vdCBhbGxvdyB0aGlzDQo+c28gd2Ugd2VyZSB0
b2xkIGFuIE1NVVNJQyBkcmFmdCB3YXMgbmVlZGVkIGFmdGVyIGFsbCB0byB1cGRhdGUgdGhlIFJG
Qw0KPmJlZm9yZSB0aGUgU0lQQnJhbmR5IHdvcmsgY291bGQgYmUgY29tcGxldGVkLg0KPg0KPkkg
ZG8gbm90IHdhbnQgdG8gc3RhcnQgYWdhaW4gYW5kIHdhc3RlIGFub3RoZXIgY291cGxlIG9mIHll
YXJzIGxldHMNCj5qdXN0IGdldCBpdCBmaW5pc2hlZC4NCg0KSSBzdWdnZXN0IHRoYXQgd2U6DQoN
CjEpCUtlZXAgdGhlIFNJUEJSQU5EWSBkcmFmdCBhcyBpdCBpcy4gUGVyaGFwcyB0aGV5IGNvdWxk
IGFkZCBhIHNlbnRlbmNlDQpwb2ludGluZyBvdXQgdGhhdCB0aGF0IHRoZSBub3JtYXRpdmUgcHJv
Y2VkdXJlcyB3aWxsIGJlIGRlc2NyaWJlZA0KZWxzZXdoZXJlLg0KMikJS2VlcCB0aGUgTU1VU0lD
IGRyYWZ0LCBidXQgd2UgYWRkIGEgcHJvcGVyICdTRFAgT2ZmZXIvQW5zd2VyDQpDb25zaWRlcmF0
aW9uc6GvIHNlY3Rpb24sIHdoZXJlIHdlIGluY2x1ZGUgdGhlIG5vcm1hbCBzdWJzZWN0aW9ucyAo
Y3JlYXRlDQppbml0aWFsIG9mZmVyLCBwcm9jZXNzIG9mZmVyLCBwcm9jZXNzIGFuc3dlciBldGMp
Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQo+T24gV2VkLCBTZXAgMjcsIDIwMTcg
YXQgOTozNSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcNCj48Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz
b24uY29tPiB3cm90ZToNCj4+IEhpLA0KPj4NCj4+DQo+Pg0KPj4gSW4gdGhlIG1haWwgeW91IHJl
ZmVyZW5jZWQgdGhlIGZvbGxvd2luZyBpcyBzYWlkOg0KPj4NCj4+DQo+Pg0KPj4gobBJIHNlZSB5
b3VyIHBvaW50IGJ1dCBDdXJyZW50bHkgU0lQQlJBTkRZIGlzIGNoYXJ0ZXJlZCB0byBwcm9kdWNl
DQo+PiBPcHBvcnR1bmlzdGljIFNSVFAgYXMgYSBCQ1AuIFRoZXJlIGlzIGFsc28gYSBtaWxlc3Rv
bmUgdG8NCj4+DQo+PiBpbmZvcm0gTU1VU0lDIG9yIG90aGVyIGFwcHJvcHJpYXRlIFdHcyBvZiBh
bnkgY2hhbmdlcyBuZWVkZWQgdG8gc3VwcG9ydA0KPj4gT3Bwb3J0dW5pc3RpYyBTUlRQIChOb3Qg
ZXhwZWN0ZWQgdG8gYmUgcHVibGlzaGVkDQo+Pg0KPj4gYXMgYW4gUkZDKS4gIEkgdGhpbmsgU0lQ
QlJBTkRZIGlzIGp1c3QgY2Fycnlpbmcgb3V0IHdoYXQgdGhleSBhcmUNCj4+Y2hhcnRlcmVkDQo+
PiB0byBkby6hsQ0KPj4NCj4+DQo+Pg0KPj4gQnV0LCBkcmFmdC1pZXRmLW1tdXNpYy1vcHBvcnR1
bmlzdGljLW5lZ290aWF0aW9uIGRvZXNuoa90IHJlYWxseSBkZWZpbmUNCj4+YW55DQo+PiBwcm9j
ZWR1cmVzIKGpIGl0IHJlZmVyZW5jZXMgdGhlIFNJUEJSQU5EWSBkcmFmdCBmb3IgZXZlcnl0aGlu
Zy4NCj4+DQo+Pg0KPj4NCj4+IKGwW0ktRC5pZXRmLXNpcGJyYW5keS1vc3J0cF0gZGVzY3JpYmVz
IGhvdyBTZWN1cmUgUmVhbC10aW1lIHRyYW5zcG9ydA0KPj4NCj4+ICAgICAgICAgICAgICAgcHJv
dG9jb2wgKFNSVFApIGNhbiBiZSBuZWdvdGlhdGVkIG9wcG9ydHVuaXN0aWNhbGx5LqGxDQo+Pg0K
Pj4NCj4+DQo+PiBCdXQsIGFzIHRoZSBTSVBCUkFORFkgaXMgb25seSBJbmZvcm1hdGlvbmFsLCB3
aGVyZSBhcmUgdGhlIG5vcm1hdGl2ZQ0KPj4gcHJvY2VkdXJlcz8NCj4+DQo+Pg0KPj4NCj4+IKGw
VGhlIGV4YWN0IG5lZ290aWF0aW9uIG1lY2hhbmlzbSBpcyBob3dldmVyIG91dHNpZGUgdGhlIHNj
b3BlIG9mIHRoaXMNCj4+IGRvY3VtZW50LA0KPj4NCj4+ICAgICAgICAgICAgICAgYW4gZXhhbXBs
ZSBtZWNoYW5pc20gY2FuIGJlIGZvdW5kIGluDQo+PiBbSS1ELmlldGYtc2lwYnJhbmR5LW9zcnRw
XS6hsQ0KPj4NCj4+DQo+Pg0KPj4gSG93IGNhbiBuZWdvdGlhdGlvbiBiZSBvdXRzaWRlIHRoZSBz
Y29wZSBvZiB0aGUgZG9jdW1lbnQsIHdoZW4gdGhlDQo+PnRpdGxlIG9mDQo+PiB0aGUgZG9jdW1l
bnQgY29udGFpbnMgobBuZWdvdGlhdGluZ6GxPw0KPj4NCj4+DQo+Pg0KPj4gSW4gYWRkaXRpb24s
IHRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgc2lwYnJhbmR5IG9ubHkgY29udGFpbnMgobBhbiBleGFt
cGxlDQo+PiBtZWNoYW5pc22hsS4NCj4+DQo+Pg0KPj4NCj4+IElmIHdlIGFyZSBnb2luZyB0byBo
YXZlIHRoaXMgZG9jdW1lbnQsIEkgdGhpbmsgd2Ugc2hhbGwgaW5jbHVkZQ0KPj5ub3JtYXRpdmUN
Cj4+IG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVzLiBUaGUgZHJhZnQgRE9FUyBjb250YWluIHNvbWUg
bm9ybWF0aXZlDQo+PnByb2NlZHVyZXMsDQo+PiBidXQgSSB0aGluayB3ZSBzaGFsbCBoYXZlIGl0
IGFsbCBpbiBvbmUgcGxhY2UuIE9uZSBzaGFsbCBub3QgaGF2ZSB0bw0KPj5yZWFkDQo+PiBib3Ro
IGRvY3VtZW50cyBqdXN0IHRvIGZpZ3VyZSBvdXQgdGhlIG9mZmVyL2Fuc3dlciBwcm9jZWR1cmVz
Lg0KPj4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+Pg0KPj4NCj4+IENocmlzdGVyDQo+Pg0K
Pj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gRnJvbTog
R29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVpKSBbbWFpbHRvOmdzYWxndWVpQGNpc2NvLmNvbV0N
Cj4+IFNlbnQ6IDI3IFNlcHRlbWJlciAyMDE3IDIxOjU4DQo+PiBUbzogQ2hyaXN0ZXIgSG9sbWJl
cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+IENjOiBtbXVzaWNAaWV0Zi5v
cmcNCj4+IFN1YmplY3Q6IFJlOiBbTU1VU0lDXSBJLUQgQWN0aW9uOg0KPj4gZHJhZnQtaWV0Zi1t
bXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMS50eHQNCj4+DQo+Pg0KPj4NCj4+IEhp
IENocmlzdGVyIC0NCj4+DQo+Pg0KPj4NCj4+IFNlZSB0aGlzOg0KPj4gaHR0cHM6Ly9tYWlsYXJj
aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9tbXVzaWMvd292MnlFcnJndFVaVVJ5UnlWdVZaNkstbkxJ
DQo+Pg0KPj4NCj4+DQo+PiBDaGVlcnMsDQo+Pg0KPj4NCj4+DQo+PiAtRw0KPj4NCj4+DQo+Pg0K
Pj4gT24gU2VwIDI3LCAyMDE3LCBhdCA5OjE5IEFNLCBDaHJpc3RlciBIb2xtYmVyZw0KPj4gPGNo
cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pg0KPj4NCj4+DQo+PiBIaSwN
Cj4+DQo+PiBJIGFtIGN1cnJlbnRseSByZXZpZXdpbmcgZHJhZnQtaWV0Zi1zaXBicmFuZHktb3Ny
dHAtMDMsIGFuZCB0aGUNCj4+Zm9sbG93aW5nDQo+PiBxdWVzdGlvbiBjb21lcyB0byBteSBtaW5k
OiBkbyB3ZSByZWFsbHkgbmVlZA0KPj4gZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1u
ZWdvdGlhdGlvbj8gOikNCj4+DQo+PiBTZWN0aW9uIDMgb2YgZHJhZnQtaWV0Zi1zaXBicmFuZHkt
b3NydHAtMDMgYWxyZWFkeSBtb3JlIG9yIGxlc3MgY29udGFpbnMNCj4+IFNEUCBPZmZlci9BbnN3
ZXIgcHJvY2VkdXJlcyBmb3IgT1NSVFAuIFdlIGNhbiBjaGFuZ2UgdGhlIG5hbWUgb2YNCj4+c2Vj
dGlvbiAzDQo+PiBpbiB0aGF0IGRyYWZ0IHRvIKn4U0RQIE9mZmVyL0Fuc3dlciBQcm9jZWR1cmVz
qfcsIG1vZGlmeSB0aGUgc3RydWN0dXJlIGENCj4+IGxpdHRsZSwgYW5kIGFkZCB3aGF0ZXZlciBt
aWdodCBiZSBtaXNzaW5nLg0KPj4NCj4+IE9yLCBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KPj4N
Cj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gT24g
MTQvMDkvMTcgMTk6MDMsICJtbXVzaWMgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRm
Lm9yZyINCj4+IDxtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCj4+DQo+Pg0KPj4NCj4+IEEgTmV3IEludGVybmV0LURy
YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4gZGly
ZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXBhcnR5
IE11bHRpbWVkaWEgU2Vzc2lvbiBDb250cm9sDQo+PldHDQo+PiBvZiB0aGUgSUVURi4NCj4+DQo+
PiAgICAgICBUaXRsZSAgICAgICAgICAgOiBOZWdvdGlhdGluZyBTUlRQIGFuZCBSVENQIEZlZWRi
YWNrIHVzaW5nIHRoZQ0KPj4gUlRQL0FWUCBQcm9maWxlDQo+PiAgICAgICBBdXRob3JzICAgICAg
ICAgOiBBbmRyZXcgSHV0dG9uDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICBSb2xhbmQgSmVz
c2tlDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICBBbGFuIEpvaG5zdG9uDQo+PiAgICAgICAg
ICAgICAgICAgICAgICAgICBHb256YWxvIFNhbGd1ZWlybw0KPj4gICAgICAgICAgICAgICAgICAg
ICAgICAgQmVybmFyZCBBYm9iYQ0KPj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tbXVz
aWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMS50eHQNCj4+IFBhZ2VzICAgICAgICAgICA6
IDcNCj4+IERhdGUgICAgICAgICAgICA6IDIwMTctMDktMTQNCj4+DQo+PiBBYnN0cmFjdDoNCj4+
ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlIHVzZSBvZiB0aGUgU2VjdXJlIFJlYWwt
dGltZSB0cmFuc3BvcnQNCj4+ICBwcm90b2NvbCAoU1JUUCkgW1JGQzM3MTFdLiBjYW4gYmUgbmVn
b3RpYXRlZCB1c2luZyB0aGUgUlRQL0FWUCAoQXVkaW8NCj4+ICBWaWRlbyBQcm9maWxlKSBkZWZp
bmVkIGluIFtSRkMzNTUxXS4gIFN1Y2ggYSBtZWNoYW5pc20gaXMgdXNlZCB0bw0KPj4gIHByb3Zp
ZGUgYSBtZWFucyBmb3IgZW5jcnlwdGVkIG1lZGlhIHRvIGJlIHVzZWQgaW4gZW52aXJvbm1lbnRz
IHdoZXJlDQo+PiAgc3VwcG9ydCBmb3IgZW5jcnlwdGlvbiBpcyBub3Qga25vd24gaW4gYWR2YW5j
ZSwgYW5kIG5vdCByZXF1aXJlZC4NCj4+ICBUaGUgc2FtZSBtZWNoYW5pc20gaXMgYWxzbyBhcHBs
aWVkIHRvIG5lZ290aWF0aW9uIG9mIHRoZSBFeHRlbmRlZCBSVFANCj4+ICBQcm9maWxlIGZvciBS
ZWFsLXRpbWUgVHJhbnNwb3J0IENvbnRyb2wgUHJvdG9jb2wgQmFzZWQgRmVlZGJhY2sgKFJUUC8N
Cj4+ICBBVlBGKSBbUkZDNDU4NV0uDQo+Pg0KPj4NCj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0
YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4gDQo+Pmh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXQNCj4+
aQ0KPj4gb24vDQo+Pg0KPj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxh
YmxlIGF0Og0KPj4gDQo+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1t
dXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9uLTANCj4+MQ0KPj4gDQo+Pmh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3Rp
Yy1uZWcNCj4+bw0KPj4gdGlhdGlvbi0wMQ0KPj4NCj4+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91
cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4+IA0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9y
ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhDQo+PnQN
Cj4+IGlvbi0wMQ0KPj4NCj4+DQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291
cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4gc3VibWlzc2lvbg0KPj4gdW50aWwg
dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm
Lm9yZy4NCj4+DQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255
bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4N
Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBt
bXVzaWMgbWFpbGluZyBsaXN0DQo+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtbXVzaWMgbWFpbGluZyBsaXN0
DQo+PiBtbXVzaWNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbW11c2ljDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+IG1tdXNp
Y0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz
aWMNCj4+DQoNCg==


From nobody Thu Sep 28 05:48:25 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F489134719 for ; Thu, 28 Sep 2017 05:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YR8XHupjhiuF for ; Thu, 28 Sep 2017 05:48:20 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 5709F1345AE for ; Thu, 28 Sep 2017 05:48:20 -0700 (PDT)
X-AuditID: c1b4fb3a-617ff700000051a3-00-59ccef920e22
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BD.78.20899.29FECC95; Thu, 28 Sep 2017 14:48:18 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 14:48:18 +0200
From: Christer Holmberg 
To: Eric Rescorla , Roman Shpount 
CC: Justin Uberti , lemming Andreasen , Bernard Aboba , "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell , Adam Roach , "Jonathan Lennox" , Bo Burman 
Thread-Topic: Presentation for a call if DTLS Association be started if not requested in the offer
Thread-Index: AQHTOBvxh7e1K2Boh0yXov/6g550d6LJ5oGA///8D4CAAAQfAIAAa5YA
Date: Thu, 28 Sep 2017 12:48:17 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_D5F2CACF22DFDchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUyM2K7lu6k92ciDdZP0rLY83cRu8X8ztPs Fkt729ktVrw+x27x/oKuxf7F55kttk4Vspi6/DGLxYoNB1gtZlyYyuzA5fH3/Qcmjym/N7J6 LNhU6rFkyU8mj9Ydf9k9Zu18wuIx+XEbs8etKQUebc/usAdwRnHZpKTmZJalFunbJXBl/F3+ jalgST9jxcIFe5gbGL/VdzFycEgImEh0bDbpYuTkEBI4wijxuceli5ELyF7EKDF/2WE2kBo2 AQuJ7n/aIDUiAs4SJ9pesIHYzAI3mSSudseB2MICyRKb9q5lgahJkTh+8SorhO0mcfnfViYQ m0VAVWLftnuMIDavgLXEjxN72SF2TWCS6LpxHqyZUyBQ4teSvWBFjAJiEt9PrWGCWCYucevJ fDBbQkBAYsme88wQtqjEy8f/wJaJCuhJbDhxmx0irihxdfpyJpD7mQUSJGYdLILYKyhxcuYT lgmMorOQTJ2FUDULSRVEiYHE+3PzmSFsbYllC19D2foSG7+cZYSwrSVeLLvHhKxmASPHKkbR 4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAhHBwy2+rHYwHnzseYhTgYFTi4d33+EykEGtiWXFl 7iFGCQ5mJRHenFdAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZ ODilGhi9p89v/uMmutsr98WZ/abPpL3+lQkG3bD1SeU4Nlvq+ZOqpzLH+wVCbpc8F5p4b4up R4Tvgk2Ptnk9XaXQcPGstPiNsBeeLtMuCzzo7WOSOaAx4eibcmYDq66C1Q4X/wtmOnhbteYt bDK6nOSWtKfOc+v2hYueH68t3bdQ9/vzXNHV5fO1G0yUWIozEg21mIuKEwGPq2SwBAMAAA==
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 12:48:24 -0000

--_000_D5F2CACF22DFDchristerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

>The relevant text is here https://tools.ietf.org/html/draft-ietf-rtcweb-js=
ep-23#section-5.8.3
>
>         tls-id value, which MUST be set according to
>         [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
>         and the tls-id value is different from that presently in use,
>         the DTLS connection is not being continued and the remote
>         description MUST be part of an ICE restart, together with new
>         ufrag and password values.  If this is an answer, the tls-id
>         value, if present, MUST be the same as in the offer.
>
> This is no longer precisely correct because you've made the answerer prov=
ide its own tls-id,
> but the clear implication is that the answerer cannot unilaterally restar=
t DTLS. It's when
> we went to update it to handle the newer syntax, we found the conflict.

It=92s true that the answerer provides its own tls-id, but I don=92t unders=
tand why that would imply that it can=92t restart DTLS.

Also, I=92d like to hear your suggestion on how to handle backward compatib=
ility with endpoints that don=92t support tls-id (read: endpoints that may =
trigger new DTLS association in the answer). Maybe the problem will go away=
 one day, but I don=92t think we can just close our eyes and wait for that =
day to come=85

Regards,

Christer



On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount > wrote:
Hi All,

I would also like to see if and how exactly allowing new DTLS association w=
hen not requested in the offer, contradicts JSEP.

Roman Shpount


On Sep 28, 2017 02:22, "Christer Holmberg" > wrote:
Thanks Roman!

I would request those that do NOT want to allow an answerer to trigger a ne=
w DTLS association to prepare a description (verbally or using slides) on h=
ow they suggest handling interoperability with legacy peers that may trigge=
r a new DTLS association in the answer.

Regards,

Christer

From: Roman Shpount >
Date: Thursday 28 September 2017 at 08:37
To: Christer Holmberg >, "adam@nostrum.com" >, Ben Campbell >, Bernard Aboba >, Bo Burman >, Eric Rescorla >, Flemming An=
dreasen >, Jonathan Lennox >, Justin Uberti >, "pkyzivat@alum.mit.edu" >, "mmusi=
c@ietf.org" >
Subject: Presentation for a call if DTLS Association be started if not requ=
ested in the offer

Hi All,

Attached is the presentation for the call tomorrow (or later today)

Once again, conference call information:

Join the meeting: join.me/112-807-485

Thursday, September 28, 2017 12:00 PM
Eastern Time (US & Canada)
In my time zone?

To dial in by phone:

United States - Los Angeles, CA
+1.213.226.1066

United States - New York, NY
+1.646.307.1990

United States - San Francisco, CA
+1.415.594.5500

United States - Washington, DC
+1.202.602.1295

Australia - Sydney
+61.2.9191.6319

France - Paris
+33.1.8288.3590

Germany - Berlin
+49.30.2240.3071

Singapore - national
+65.3158.1842

United Kingdom - London
+44.20.3582.4515

More phone numbers

Conference ID:
112-807-485 #

Need to share screen?  Download the app

Regards,

_____________

Roman Shpount



--_000_D5F2CACF22DFDchristerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <7C0528921237794B9E39B6D28C8EDB3B@ericsson.com>
Content-Transfer-Encoding: quoted-printable







Hi,












>The relevant text is here 
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-23#section-5.8.3

>




>         tls-id value, which MUST be set accor=
ding to


>         [I-D.ietf-mmusic-dtls-sdp], Section 5=
.  If this is a re-offer


>         and the tls-id value is different fro=
m that presently in use,


>         the DTLS connection is not being cont=
inued and the remote


>         description MUST be part of an ICE re=
start, together with new


>         ufrag and password values.  If t=
his is an answer, the tls-id


>         value, if present, MUST be the same a=
s in the offer.




>


> This is no longer precisely correct because you've made the answe=
rer provide its own tls-id,


> but the clear implication is that the answerer cannot unilaterall=
y restart DTLS. It's when


> we went to update it to handle the newer syntax, we found the con=
flict.














It=92s true that the answerer provides its own tls-id, but I don=92t u=
nderstand why that would imply that it can=92t restart DTLS.







Also, I=92d like to hear your suggestion on how to handle backward com=
patibility with endpoints that don=92t support tls-id (read: endpoints that=
 may trigger new DTLS association in the answer). Maybe the problem will go=
 away one day, but I don=92t think we
 can just close our eyes and wait for that day to come=85







Regards,







Christer
























On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount =

<roman@telurix.co=
m> wrote:






Hi All,






I would also like to see if and how exactly allowing new =
DTLS association when not requested in the offer, contradicts JSEP.




Roman Shpount












On Sep 28, 2017 02:22, "Christer Holmberg&q=
uot; <christer.holmberg@ericsson.com> wrote:






Thanks Roman!







I would request those that do NOT want to allow an answerer to trigger=
 a new DTLS association to prepare a description (verbally or using slides)=
 on how they suggest handling interoperability with legacy peers that may t=
rigger a new DTLS association in
 the answer. 







Regards,







Christer









From: Roman Shpount <roman@telurix.com>

Date: Thursday 28 September 2017 at=
 08:37

To: Christer Holmberg <christer.holmb=
erg@ericsson.com>, "adam@nostrum.com" <adam@nostrum.com>,
 Ben Campbell <ben@=
nostrum.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>, Bo Burman=
 <bo.burman@=
ericsson.com>,
 Eric Rescorla <ekr@rt=
fm.com>, Flemming Andreasen <fandreas@cisco.com>, Jonathan Lennox <jonathan@vidyo.com>=
,
 Justin Uberti <=
juberti@google.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>,
 "mmusic@ietf.org=
" <mmusic@=
ietf.org>

Subject: Presentation for a call if=
 DTLS Association be started if not requested in the offer















Hi All,






Attached is the presentation for the call tomorrow (or later today)






Once again, conference call information:









Ro=
man Shpount

















































--_000_D5F2CACF22DFDchristerholmbergericssoncom_--


From nobody Thu Sep 28 05:58:19 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89B134724; Thu, 28 Sep 2017 05:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9Ur5rneayg3J; Thu, 28 Sep 2017 05:58:05 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 1F1BE134720; Thu, 28 Sep 2017 05:58:04 -0700 (PDT)
X-AuditID: c1b4fb2d-e302b9c0000019be-10-59ccf1dab800
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.9A.06590.AD1FCC95; Thu, 28 Sep 2017 14:58:03 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 14:57:56 +0200
From: Christer Holmberg 
To: "Ali C. Begen" 
CC: Flemming Andreasen , mmusic , "draft-ietf-mmusic-rfc4566bis@ietf.org" 
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23: media description vs media-level section
Thread-Index: AdM29qzx1SUj0Rn9Rk+eetpSJxUupQBM+MUAAA4B0QA=
Date: Thu, 28 Sep 2017 12:57:56 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B562FDDE3@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_D5F2CCF522E07christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7hO7tj2ciDRoWslsc/PaC2WLtusvM Fu8v6FpMXf6YxYHFY8rvjaweS5b8ZPLYtewCewBzFJdNSmpOZllqkb5dAlfG/8+LGQsmuFZc vrafqYFxqXUXIyeHhICJxOG298wgtpDAEUaJe5srIOxFjBInJmh1MXJwsAlYSHT/0wYJiwjo SUy8Nouli5GLg1lgFqPEpcm/2EBqhAUyJaYuMwQxRQSyJN5160OUW0m8eD2RCcRmEVCVWHz2 DyuIzStgLdHxsRVsjJDAFEaJ1+9usoP0cgoESrRs1gCpYRQQk/h+ag1YL7OAuMStJ/OZIC4W kFiy5zwzhC0q8fLxP7CZokCnbThxmx0irihxdfpyqN4Eif/dd5gh9gpKnJz5hGUCo+gsJGNn ISmbhaQMIm4g8f7cfGYIW1ti2cLXULa+xMYvZxkhbGuJl5Ofo6hZwMixilG0OLW4ODfdyFgv tSgzubg4P08vL7VkEyMwOg9u+a27g3H1a8dDjAIcjEo8vKpPz0QKsSaWFVfmHmKU4GBWEuHN eQUU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgbHx6Qov 7v2pIg/XZ1Y5hp0212q92Dgr7Mju0qQ7v97fD2NblPhZIuPPu527jhiyy37as5JvqcrvIr9X aQ08Vmkdc932fJtwK9GWzWKTaapD0xHVPkePb93HmSeu2/V06m4BswbBW+Vbb6VEm7BMr/PV e8izN2XbRj4dTv1oHj4zywmejutmOSuxFGckGmoxFxUnAgDMtmd5ygIAAA==
Archived-At: 
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23: media description vs media-level section
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 12:58:08 -0000

--_000_D5F2CCF522E07christerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

>I think we should removee the media-level section, seems redundant and sti=
ck with media description.

Sounds good, because I think media description is more widely used.

Also, unless it is already clear, we need to make sure that the difference =
between =93session description=94 and =93session-level section=94. =93Sessi=
on description=94 refers to the whole body, while =93session-level section=
=94 does only refer to the non-media description parts. Maybe =93media desc=
ription=94 and =93session-level section=94 should be added to the Glossary?

In Section 5, you can also replace "session-level part=94with =93session-le=
vel section=94. =93session-level part=94is only used in one place.

Regards,

Christer


On Tue, Sep 26, 2017 at 9:39 PM, Christer Holmberg > wrote:
Hi,

One editorial comment:

The draft uses both "media description" and "media-level section" terminolo=
gy, but at least I can't see any difference. The definition of those terms =
are also identical:

        "Each media description starts with an "m=3D" line and is terminate=
d by either the next "m=3D" line..."             (section 5.14)

...and:

        "Each media-level section starts with an "m=3D" line and continues =
to the next media-level section..."    (section 5)

"media-level section" only appears in one paragraph of the whole document.

Do we need both?

Regards,

Christer






-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Flemming Andreasen
Sent: 18 September 2017 15:59
To: mmusic >; draft-ietf-mmusic-rfc=
4566bis@ietf.org
Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23

Greetings MMUSIC

This is to announce a 2 week WGLC on the draft:

      https://www.ietf.org/id/draft-ietf-mmusic-rfc4566bis-23.txt

as Proposed Standard. Please review and provide any comments you may have o=
n the document by Monday, October 2, 2017. Comments should be sent to the d=
ocument authors and the MMUSIC WG list. If you review the document but do n=
ot have any comments, please send a note to that effect as well.

Thanks

-- Flemming (MMUSIC co-chair)

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


--_000_D5F2CCF522E07christerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <43D3DD86A5AD51458BC3FA20423BEEFC@ericsson.com>
Content-Transfer-Encoding: quoted-printable








Hi,













>I think we should removee the media-level section, see=
ms redundant and stick with media description.














Sounds good, because I think media description is more widely used.









Also, unless it is already clear, we need to make sure that the difference =
between =93session description=94 and =93session-level section=94. =93Sessi=
on description=94 refers to the whole body, while =93session-level section=
=94 does only refer to the non-media description
 parts. Maybe =93media description=94 and =93session-level section=94 shoul=
d be added to the Glossary?








In =
Section 5, you can also replace "session-level part=94with =93session-level section=94.
 =93session-level part=94is only used in one place.

=





=
Regards,


=





=
Christer
















On Tue, Sep 26, 2017 at 9:39 PM, Christer Holmbe=
rg 
<chr=
ister.holmberg@ericsson.com> wrote:



Hi,



One editorial comment:



The draft uses both "media description" and "media-level sec=
tion" terminology, but at least I can't see any difference. The defini=
tion of those terms are also identical:



        "Each media description starts with an &qu=
ot;m=3D" line and is terminated by either the next "m=3D" li=
ne..."             (section 5.14)


...and:



        "Each media-level section starts with an &=
quot;m=3D" line and continues to the next media-level section..."=
    (section 5)



"media-level section" only appears in one paragraph of the whole =
document.



Do we need both?



Regards,



Christer













-----Original Message-----

From: mmusic [mailto:mmusic-boun=
ces@ietf.org] On Behalf Of Flemming Andreasen

Sent: 18 September 2017 15:59

To: mmusic <mmusic@ietf.org>; =

draft-ietf-mmusic-rfc4566bis@ietf.org

Subject: [MMUSIC] WGLC on draft-ietf-mmusic-rfc4566bis-23



Greetings MMUSIC



This is to announce a 2 week WGLC on the draft:



      
https://www.ietf.org/id/draft-ietf-mmusic-rfc4566bis-23.txt



as Proposed Standard. Please review and provide any comments you may have o=
n the document by Monday, October 2, 2017. Comments should be sent to the d=
ocument authors and the MMUSIC WG list. If you review the document but do n=
ot have any comments, please send
 a note to that effect as well.



Thanks



-- Flemming (MMUSIC co-chair)



_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www.ietf.org/mailman/listinfo/mmusic
















--_000_D5F2CCF522E07christerholmbergericssoncom_--


From nobody Thu Sep 28 06:20:09 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380B113304D for ; Thu, 28 Sep 2017 06:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnzAXhVCrBUU for ; Thu, 28 Sep 2017 06:20:05 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8943A13301C for ; Thu, 28 Sep 2017 06:19:58 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id s62so963221ywg.0 for ; Thu, 28 Sep 2017 06:19:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZmeKwyMMWxSOCyKtqffE8bWtXjlF7MnGeCDbJFIB7EY=; b=IljOjYTS6U0Y1HcIA4VEgaiCiTEioNtZ3/3cr5JXLBiJJL70qSrNCNYHcdUWp/Fy8m AAQdQr7OCJSY9qwTnpJoufB/jmxBABGEz7aKttUhwOOf0YnLaeikto+bxNuUcdA7jIlQ X/NqJypquXGxtF+BF2M8HNwrM57YsqHHaIrsu6dHmtq5Rh2NUBCjSBe6xv9FTMED8tmN d7o4ah7J/Leeft3/JWno7lyfN0WLHRhoGDIMa15csOQgNDXvJDcbMuttI5Fg6Wb1yv+P E9goB7EQNWJp2MNzT0P/ZB57yRoSMf5S51+B8pzSwfovizrVKpGztnuUTwzvqR0Zoz2U hLvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZmeKwyMMWxSOCyKtqffE8bWtXjlF7MnGeCDbJFIB7EY=; b=ORmkZEtI77i00jsZLvrTzOV7jMtSW9he0jp9cbpEJgBds5c7OFVZQuX7+Mq5mnwCg5 dQGPmPsisL24b6Kqc/J/b8WATiXPrt4B5UKHK2C3Rsu1jVkILz2UwvkQYIpCbHnCt8xu MSqXDlvH6bDCRdKw2KqHR3N7tbbD/XKOMd0GMeQvaYRGF4hxksqmzKB1XrCoyRsX/BUQ mHn4EbpGDviEw84ODLjWGPE7gxcBUeKzf/uEaYhRyiQ9MECFhy7L7bHyXFoHF5KptCLJ 8R06aJxkdiTJf+9d70AM5LI/j07ttBSY0DHPnCWk3pXBtbYK1RGYIMhUK3iosSNXUGap hkrg==
X-Gm-Message-State: AHPjjUifvxmroQr16sn2nMbP084QWtdjDEGzsWYHf/Cc9+BhsUgFWEXX OYhTGtqua5QD5wBBzf1o5hcR9K2MH4nC7dAbpjhvtw==
X-Google-Smtp-Source: AOwi7QD/fISBSqN+X46UZe+C8Uv516Hq2Nmap+P2eIt23z/DKNjrYoJhvF1nMLLzHoOSICDosoSed8TdlX8Ov9/mq2k=
X-Received: by 10.129.101.8 with SMTP id z8mr3352851ywb.266.1506604797762; Thu, 28 Sep 2017 06:19:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.17 with HTTP; Thu, 28 Sep 2017 06:19:17 -0700 (PDT)
In-Reply-To: 
References:     
From: Eric Rescorla 
Date: Thu, 28 Sep 2017 15:19:17 +0200
Message-ID: 
To: Christer Holmberg 
Cc: Roman Shpount , Justin Uberti ,  lemming Andreasen , Bernard Aboba ,  "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell ,  Adam Roach , Jonathan Lennox ,  Bo Burman 
Content-Type: multipart/alternative; boundary="001a114c7d7ec9d18d055a3fc3fa"
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 13:20:08 -0000

--001a114c7d7ec9d18d055a3fc3fa
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 28, 2017 at 2:48 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> >The relevant text is here https://tools.ietf.org/html/
> draft-ietf-rtcweb-jsep-23#section-5.8.3
> >
> >         tls-id value, which MUST be set according to
> >         [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
> >         and the tls-id value is different from that presently in use,
> >         the DTLS connection is not being continued and the remote
> >         description MUST be part of an ICE restart, together with new
> >         ufrag and password values.  If this is an answer, the tls-id
> >         value, if present, MUST be the same as in the offer.
> >
> > This is no longer precisely correct because you've made the answerer
> provide its own tls-id,
> > but the clear implication is that the answerer cannot unilaterally
> restart DTLS. It's when
> > we went to update it to handle the newer syntax, we found the conflict.
>
> It=E2=80=99s true that the answerer provides its own tls-id, but I don=E2=
=80=99t
> understand why that would imply that it can=E2=80=99t restart DTLS.
>

As I said, the original text assumed that the answerer *copied* the TLS-ID
and that is because we assumed that the answerer couldn't, so just because
we've changed the syntax doesn't mean we think the logic should change.


Also, I=E2=80=99d like to hear your suggestion on how to handle backward
> compatibility with endpoints that don=E2=80=99t support tls-id (read: end=
points
> that may trigger new DTLS association in the answer). Maybe the problem
> will go away one day, but I don=E2=80=99t think we can just close our eye=
s and wait
> for that day to come=E2=80=A6
>

Which endpoints do that? Because that's absolutely going to be forbidden by
JSEP.

-Ekr


>
> Regards,
>
> Christer
>
>
>
> On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount  wrote=
:
>
>> Hi All,
>>
>> I would also like to see if and how exactly allowing new DTLS associatio=
n
>> when not requested in the offer, contradicts JSEP.
>>
>> Roman Shpount
>>
>>
>> On Sep 28, 2017 02:22, "Christer Holmberg" > m> wrote:
>>
>> Thanks Roman!
>>
>> I would request those that do NOT want to allow an answerer to trigger a
>> new DTLS association to prepare a description (verbally or using slides)=
 on
>> how they suggest handling interoperability with legacy peers that may
>> trigger a new DTLS association in the answer.
>>
>> Regards,
>>
>> Christer
>>
>> From: Roman Shpount 
>> Date: Thursday 28 September 2017 at 08:37
>> To: Christer Holmberg , "adam@nostrum.co=
m"
>> , Ben Campbell , Bernard Aboba <
>> Bernard.Aboba@microsoft.com>, Bo Burman , Eric
>> Rescorla , Flemming Andreasen ,
>> Jonathan Lennox , Justin Uberti =
,
>> "pkyzivat@alum.mit.edu" , "mmusic@ietf.org" <
>> mmusic@ietf.org>
>> Subject: Presentation for a call if DTLS Association be started if not
>> requested in the offer
>>
>> Hi All,
>>
>> Attached is the presentation for the call tomorrow (or later today)
>>
>> Once again, conference call information:
>>
>> *Join the meeting: join.me/112-807-485 *
>>
>> Thursday, September 28, 2017 12:00 PM
>> Eastern Time (US & Canada)
>> In my time zone? 
>> *To dial in by phone:*
>>
>> United States - Los Angeles, CA
>> *+1.213.226.1066 <+1.213.226.1066,,112807485#>*
>>
>> United States - New York, NY
>> *+1.646.307.1990 <+1.646.307.1990,,112807485#>*
>>
>> United States - San Francisco, CA
>> *+1.415.594.5500 <+1.415.594.5500,,112807485#>*
>>
>> United States - Washington, DC
>> *+1.202.602.1295 <+1.202.602.1295,,112807485#>*
>>
>> Australia - Sydney
>> *+61.2.9191.6319 <+61.2.9191.6319,,112807485#>*
>>
>> France - Paris
>> *+33.1.8288.3590 <+33.1.8288.3590,,112807485#>*
>>
>> Germany - Berlin
>> *+49.30.2240.3071 <+49.30.2240.3071,,112807485#>*
>>
>> Singapore - national
>> *+65.3158.1842 <+65.3158.1842,,112807485#>*
>>
>> United Kingdom - London
>> *+44.20.3582.4515 <+44.20.3582.4515,,112807485#>*
>>
>> More phone numbers 
>>
>> Conference ID:
>> *112-807-485 #*
>>
>> Need to share screen?  Download the app 
>>
>> Regards,
>>
>> _____________
>> Roman Shpount
>>
>>
>>
>

--001a114c7d7ec9d18d055a3fc3fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Sep 28, 2017 at 2:48 PM, Christer Holmberg &l=
t;chris=
ter.holmberg@ericsson.com> wrote:







Hi,












>The relevant text is here 
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-23#section-5.8=
.3

>




> =C2=A0 =C2=A0 =C2=A0 =C2=A0 tls-id value, which MUST be set accor=
ding to


> =C2=A0 =C2=A0 =C2=A0 =C2=A0 [I-D.ietf-mmusic-dtls-sdp], Section 5=
.=C2=A0 If this is a re-offer


> =C2=A0 =C2=A0 =C2=A0 =C2=A0 and the tls-id value is different fro=
m that presently in use,


> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the DTLS connection is not being cont=
inued and the remote


> =C2=A0 =C2=A0 =C2=A0 =C2=A0 description MUST be part of an ICE re=
start, together with new


> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ufrag and password values.=C2=A0 If t=
his is an answer, the tls-id


> =C2=A0 =C2=A0 =C2=A0 =C2=A0 value, if present, MUST be the same a=
s in the offer.




>


> This is no longer precisely correct because you've made the a=
nswerer provide its own tls-id,


> but the clear implication is that the answerer cannot unilaterall=
y restart DTLS. It's when


> we went to update it to handle the newer syntax, we found the con=
flict.














It=E2=80=99s true that the answerer provides its own tls-id, bu=
t I don=E2=80=99t understand why that would imply that it can=E2=80=99t res=
tart DTLS.

As I said, the origi=
nal text assumed that the answerer *copied* the TLS-ID and that is because =
we assumed that the answerer couldn't, so just because we've change=
d the syntax doesn't mean we think the logic should change.
<=
br>



Also, I=E2=80=99d like to hear your suggestion on how to handle backwa=
rd compatibility with endpoints that don=E2=80=99t support tls-id (read: en=
dpoints that may trigger new DTLS association in the answer). Maybe the pro=
blem will go away one day, but I don=E2=80=99t think we
 can just close our eyes and wait for that day to come=E2=80=A6
=


Which endpoints do that? Because that'=
s absolutely going to be forbidden by JSEP.

-Ekr
=C2=A0







Regards,







Christer
























On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount =

<roman@telurix.co=
m> wrote:






Hi All,






I would also like to see if and how exactly allowing new =
DTLS association when not requested in the offer, contradicts JSEP.




Roman Shpount












On Sep 28, 2017 02:22, "Christer Holmberg&q=
uot; <christer.holmberg@ericsson.com> wrote:






Thanks Roman!







I would request those that do NOT want to allow an answerer to trigger=
 a new DTLS association to prepare a description (verbally or using slides)=
 on how they suggest handling interoperability with legacy peers that may t=
rigger a new DTLS association in
 the answer.=C2=A0







Regards,







Christer









From: Roman Shpount <roman@telurix.com>

Date: Thursday 28 September 2017 at=
 08:37

To: Christer Holmberg <christer.holmb=
erg@ericsson.com>, "adam@nostrum.com" <adam@nostrum.com>,
 Ben Campbell <ben@=
nostrum.com>, Bernard Aboba <Bernard.Aboba@microsoft.com>, Bo Burman=
 <bo.burman@=
ericsson.com>,
 Eric Rescorla <ekr@rt=
fm.com>, Flemming Andreasen <fandreas@cisco.com>, Jonathan Lennox <jonathan@vidyo.com>=
,
 Justin Uberti <=
juberti@google.com>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>,
 "mmusic@ietf.org=
" <mmusic@=
ietf.org>

Subject: Presentation for a call if=
 DTLS Association be started if not requested in the offer















Hi All,






Attached is the presentation for the call tomorrow (or later today)






Once again, conference call information:




Join the meeting:=C2=
=A0join.me/112-807-485




Thursday, September 28, 2017 12:00 PM=C2=A0
Eastern Time (US & Canada)=C2=A0

=
In
 my time zone?

To dial in by phone:

United States - Los Angeles, CA=C2=A0

+1.213.226.1066<=
/p>

United States - New York, NY=C2=A0

+1.646.307.1990<=
/p>

United States - San Francisco, CA=C2=A0

+1.415.594.5500<=
/p>

United States - Washington, DC=C2=A0

+1.202.602.1295<=
/p>

Australia - Sydney=C2=A0

+61.2.9191.6319<=
/p>

France - Paris=C2=A0

+33.1.8288.3590<=
/p>

Germany - Berlin=C2=A0

+49.30.2240.3071


Singapore - national=C2=A0

+65.3158.1842


United Kingdom - London=C2=A0

+44.20.3582.4515


More phone numbers<=
/a>


Conference ID:=C2=A0

112-807-485 #


Need to share scr=
een?=C2=A0=C2=A0Download
 the app


Regards,


_____________










Roman Shpount





















































--001a114c7d7ec9d18d055a3fc3fa--


From nobody Thu Sep 28 06:36:40 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DD3133059 for ; Thu, 28 Sep 2017 06:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 M7xNvCcS7V64 for ; Thu, 28 Sep 2017 06:36:36 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A6468133061 for ; Thu, 28 Sep 2017 06:36:33 -0700 (PDT)
X-AuditID: c1b4fb3a-9e1d49c0000051a3-3f-59ccfadf0d2f
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DC.92.20899.FDAFCC95; Thu, 28 Sep 2017 15:36:31 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 15:36:31 +0200
From: Christer Holmberg 
To: Eric Rescorla 
CC: Roman Shpount , Justin Uberti , lemming Andreasen , Bernard Aboba , "mmusic@ietf.org" , "Paul Kyzivat" , Ben Campbell , Adam Roach , Jonathan Lennox , Bo Burman 
Thread-Topic: Presentation for a call if DTLS Association be started if not requested in the offer
Thread-Index: AQHTOBvxh7e1K2Boh0yXov/6g550d6LJ5oGA///8D4CAAAQfAIAAa5YA///UwYCAADi4gA==
Date: Thu, 28 Sep 2017 13:36:30 +0000
Message-ID: 
References:      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2389D470B3A0F34EAFAE73D52691A2BF@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUyM2J7iO79X2ciDR4/0bHY83cRu8X8ztPs Fkt729ktVrw+x27x/oKuxf7F55kttk4Vspi6/DGLxYoNB1gtZlyYyuzA5fH3/Qcmjym/N7J6 LNhU6rFkyU8mj9Ydf9k9Zu18wuIx+XEbs8etKQUebc/usAdwRnHZpKTmZJalFunbJXBlbLr/ gaXgukTF69/rWBsYZ4l0MXJySAiYSBybP5Wpi5GLQ0jgCKPE5AttUM4iRoklfW/Zuxg5ONgE LCS6/2mDNIgIKEj8+nOCBaSGWeAfk8TbvutMIAlhgWSJTXvXskAUpUgcv3iVFcIOk9jZeRMs ziKgKnHo5TJWkJm8AtYSm1eFgISFBDqZJf4fqgOxOQUCJb6tfQzWyiggJvH91Bqw8cwC4hK3 nsxngjhaQGLJnvPMELaoxMvH/8DqRQX0JDacuM0OEVeU+PhqHyNEr4HE+3PzmSFsa4lXyxdB 2doSyxa+BrN5BQQlTs58wjKBUXwWknWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWF+emGxnppRZl JhcX5+fp5aWWbGIERv/BLb+tdjAefO54iFGAg1GJh3ff4zORQqyJZcWVuYcYJTiYlUR4b3wG CvGmJFZWpRblxxeV5qQWH2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cC4fkGA+7LC 3Ngde/6XnitIuL1zS4rL4SOb103lCkuU+Vs8cemb0CP3HVlm5dyxmN+7SY8xb2XCYamL7wpn Xf303X/dzKOeLl6cV261cE1/3qdQLJj3YsOfZzv1yuaWRu1m0N7tmXbnbBpTzOpFpgYLVP+s Cqnusf3WZPr+qbDWS7N1n0KVV9f8VGIpzkg01GIuKk4EAPVWTd/6AgAA
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 13:36:38 -0000

Hi,

=8A


>> Also, I=B9d like to hear your suggestion on how to handle backward
>>compatibility with endpoints that don=B9t support tls-id
>> (read: endpoints that may trigger new DTLS association in the answer).
>>Maybe the problem will go away one day, but I don=B9t think we
>> can just close our eyes and wait for that day to come=8A
>
> Which endpoints do that? Because that's absolutely going to be forbidden
>by JSEP.

=B3Legacy=B2 RFC 5763-compliant endpoints that don=B9t support tls-id.

Regards,

Christer









On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount
 wrote:

Hi All,

I would also like to see if and how exactly allowing new DTLS association
when not requested in the offer, contradicts JSEP.

Roman Shpount



On Sep 28, 2017 02:22, "Christer Holmberg"
 wrote:

Thanks Roman!

I would request those that do NOT want to allow an answerer to trigger a
new DTLS association to prepare a description (verbally or using slides)
on how they suggest handling interoperability with legacy peers that may
trigger a new DTLS association in
 the answer.=20

Regards,

Christer

From: Roman Shpount 
Date: Thursday 28 September 2017 at 08:37
To: Christer Holmberg , "adam@nostrum.com"
,
 Ben Campbell , Bernard Aboba
, Bo Burman ,
 Eric Rescorla , Flemming Andreasen ,
Jonathan Lennox ,
 Justin Uberti , "pkyzivat@alum.mit.edu"
,
 "mmusic@ietf.org" 
Subject: Presentation for a call if DTLS Association be started if not
requested in the offer


Hi All,

Attached is the presentation for the call tomorrow (or later today)

Once again, conference call information:
Join the meeting: join.me/112-807-485 

Thursday, September
 28, 2017 12:00 PM=20
Eastern Time (US & Canada)
In
 my time zone? 
To dial in by phone:United States - Los Angeles, CA
+1.213.226.1066 
United States - New York, NY
+1.646.307.1990 
United States - San Francisco, CA
+1.415.594.5500 
United States - Washington, DC
+1.202.602.1295 
Australia - Sydney=20
+61.2.9191.6319 
France - Paris=20
+33.1.8288.3590 
Germany - Berlin=20
+49.30.2240.3071 
Singapore - national
+65.3158.1842 
United Kingdom - London
+44.20.3582.4515 
More phone numbers 
Conference ID:=20
112-807-485 #
Need to share screen?  Download
 the app 
Regards,
_____________

Roman Shpount

































From nobody Thu Sep 28 06:55:16 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3DD13472D for ; Thu, 28 Sep 2017 06:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQgCdJqN2bVX for ; Thu, 28 Sep 2017 06:55:12 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF5A13319E for ; Thu, 28 Sep 2017 06:55:12 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id v72so1042595ywa.3 for ; Thu, 28 Sep 2017 06:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OZeJ6BYPzbF6tRsxKVHqeSyGPc5VfXcZyjb0nenWYsg=; b=DExZgPwjnYsVzLg4LYxMk4HPUP/EOeeTeNXePQTVQkMkun5Lger/jbotZ8Y26U3z71 7FVMygK7Lk2OVLPTjy7+zxed8nAB6TbMtSL6A5uKf0ek0ZnQ0dDZFqLvTrsl95pfgeBY tANqnyscdHuqsFLy2A6IVENVaBbo/hlgaymaPTiyJQ1UmBbzeMbIgY2hj92WVu5uf0rw 00hHquAe1zJJKsUvqQjCzjP3dZnmQucbkjmX/iZmV7aO+USE0QQF3mtBi7e36CGbGyCa 0WFk8vDw6LjqV0Gdrs9lrLlS1tZlIvN9s+/1h1XU9y8F8AW/GJzbWOh9LnUmC3jLyc7T Lsrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OZeJ6BYPzbF6tRsxKVHqeSyGPc5VfXcZyjb0nenWYsg=; b=B8LLPy2uLnsUFBC5oUmohL/WeJ/BOeLfMOqFE/XwHGpeQ1YURnDV0foTNkOv1rp93B wwNRD+GTUOJtqZ0yX2D+mQeyhGUXNdGqBcVaNctfObKhsqvsf2zSvMZaMx/FfgguIDSE xgFluBZkA6QoqHhkh4W/pVbiCkkhDT0hdMQmm6Hte9njKSX579gU7eUFv9AIjT3lJQ+G byQ9Ex8cDONybTPUvQWRebpquabDB6w3BpTZJG9fIsBfmmXLTniQH8Yi2LRPoK9vJd5N vu9hmbW9HOcJihaOrlQKfKarHB20f+5/4ernw97GkGZyr75QZciOsl9FZ2fLdsuXyhZc Ltbw==
X-Gm-Message-State: AHPjjUhY7k6jTCTc+/6VGCmUy5JoikVtFrvmCG2F7CC9NLjYRTLmFtAs APiKxKaru4BF4ktTDcjUmzIEUw+BFWBJl1a5M0NxGA==
X-Google-Smtp-Source: AOwi7QCSbAP6JEQftAZijcyM/p4Q0t6zzPCG9QCvhTUUKgKM8z2P+PmrWu8W5UZLFlPDeZoXmZz6cHHCL9+4llVI30Y=
X-Received: by 10.129.101.8 with SMTP id z8mr3429531ywb.266.1506606911773; Thu, 28 Sep 2017 06:55:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.17 with HTTP; Thu, 28 Sep 2017 06:54:31 -0700 (PDT)
In-Reply-To: 
References:       
From: Eric Rescorla 
Date: Thu, 28 Sep 2017 15:54:31 +0200
Message-ID: 
To: Christer Holmberg 
Cc: Roman Shpount , Justin Uberti ,  lemming Andreasen , Bernard Aboba ,  "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell ,  Adam Roach , Jonathan Lennox ,  Bo Burman 
Content-Type: multipart/alternative; boundary="001a114c7d7ecaf156055a40410e"
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 13:55:15 -0000

--001a114c7d7ecaf156055a40410e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 28, 2017 at 3:36 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> =C5=A0
>
>
> >> Also, I=C2=B9d like to hear your suggestion on how to handle backward
> >>compatibility with endpoints that don=C2=B9t support tls-id
> >> (read: endpoints that may trigger new DTLS association in the answer).
> >>Maybe the problem will go away one day, but I don=C2=B9t think we
> >> can just close our eyes and wait for that day to come=C5=A0
> >
> > Which endpoints do that? Because that's absolutely going to be forbidde=
n
> >by JSEP.
>
> =C2=B3Legacy=C2=B2 RFC 5763-compliant endpoints that don=C2=B9t support t=
ls-id.
>

Sorry, I was asking "which actual implementations do this"?

-Ekr


> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
> On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount
>  wrote:
>
> Hi All,
>
> I would also like to see if and how exactly allowing new DTLS association
> when not requested in the offer, contradicts JSEP.
>
> Roman Shpount
>
>
>
> On Sep 28, 2017 02:22, "Christer Holmberg"
>  wrote:
>
> Thanks Roman!
>
> I would request those that do NOT want to allow an answerer to trigger a
> new DTLS association to prepare a description (verbally or using slides)
> on how they suggest handling interoperability with legacy peers that may
> trigger a new DTLS association in
>  the answer.
>
> Regards,
>
> Christer
>
> From: Roman Shpount 
> Date: Thursday 28 September 2017 at 08:37
> To: Christer Holmberg , "adam@nostrum.com=
"
> ,
>  Ben Campbell , Bernard Aboba
> , Bo Burman ,
>  Eric Rescorla , Flemming Andreasen ,
> Jonathan Lennox ,
>  Justin Uberti , "pkyzivat@alum.mit.edu"
> ,
>  "mmusic@ietf.org" 
> Subject: Presentation for a call if DTLS Association be started if not
> requested in the offer
>
>
> Hi All,
>
> Attached is the presentation for the call tomorrow (or later today)
>
> Once again, conference call information:
> Join the meeting: join.me/112-807-485 
>
> Thursday, September
>  28, 2017 12:00 PM
> Eastern Time (US & Canada)
> In
>  my time zone? 
> To dial in by phone:United States - Los Angeles, CA
> +1.213.226.1066 
> United States - New York, NY
> +1.646.307.1990 
> United States - San Francisco, CA
> +1.415.594.5500 
> United States - Washington, DC
> +1.202.602.1295 
> Australia - Sydney
> +61.2.9191.6319 
> France - Paris
> +33.1.8288.3590 
> Germany - Berlin
> +49.30.2240.3071 
> Singapore - national
> +65.3158.1842 
> United Kingdom - London
> +44.20.3582.4515 
> More phone numbers 
> Conference ID:
> 112-807-485 #
> Need to share screen?  Download
>  the app 
> Regards,
> _____________
>
> Roman Shpount
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

--001a114c7d7ecaf156055a40410e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Sep 28, 2017 at 3:36 PM, Christer Holmberg &l=
t;chris=
ter.holmberg@ericsson.com> wrote:
Hi,



=C5=A0





>> Also, I=C2=B9d like to hear your suggestion on how to handle backw=
ard

>>compatibility with endpoints that don=C2=B9t support tls-id

>> (read: endpoints that may trigger new DTLS association in the answ=
er).

>>Maybe the problem will go away one day, but I don=C2=B9t think we
>> can just close our eyes and wait for that day to come=C5=A0=


>

> Which endpoints do that? Because that's absolutely going to be for=
bidden

>by JSEP.



=C2=B3Legacy=C2=B2 RFC 5763-compliant endpoints that don=C2=B9t supp=
ort tls-id.

Sorry, I was asking "w=
hich actual implementations do this"?

-Ekr





Regards,



Christer



















On Thu, Sep 28, 2017 at 11:14 AM, Roman Shpount

<roman@telurix.com> wrote:


Hi All,



I would also like to see if and how exactly allowing new DTLS association
when not requested in the offer, contradicts JSEP.



Roman Shpount







On Sep 28, 2017 02:22, "Christer Holmberg"

<christer.holmberg@eri=
csson.com> wrote:



Thanks Roman!



I would request those that do NOT want to allow an answerer to trigger a
new DTLS association to prepare a description (verbally or using slides)
on how they suggest handling interoperability with legacy peers that may
trigger a new DTLS association in

=C2=A0the answer.



Regards,



Christer



From: Roman Shpount <roman@telurix.=
com>

Date: Thursday 28 September 2017 at 08:37

To: Christer Holmberg <christer.holmberg@ericsson.com>, "adam@nostrum.com"

<adam@nostrum.com>,

=C2=A0Ben Campbell <ben@nostrum.com>, Bernard Aboba

<Bernard.Aboba@microsoft.=
com>, Bo Burman <bo.bur=
man@ericsson.com>,

=C2=A0Eric Rescorla <ekr@rtfm.com>=
;, Flemming Andreasen <fandreas@ci=
sco.com>,

Jonathan Lennox <jonathan@vidyo.co=
m>,

=C2=A0Justin Uberti <juberti@googl=
e.com>, "pkyzivat@alum=
.mit.edu"

<pkyzivat@alum.mit.edu>,=


=C2=A0"mmusic@ietf.org" &l=
t;mmusic@ietf.org>

Subject: Presentation for a call if DTLS Association be started if not

requested in the offer





Hi All,



Attached is the presentation for the call tomorrow (or later today)



Once again, conference call information:


Join the meeting: join.me/112-807-485 <https://join.m=
e/112-807-485>



Thursday, September

=C2=A028, 2017 12:00 PM

Eastern Time (US & Canada)

In

=C2=A0my time zone? <https://join.me/t=
imezone/1506614400000/1506621600000>

To dial in by phone:United States - Los Angeles, CA

+1.213.226.=
1066=C2=A0<tel:+1.213.226.1066,,112807485#>

United States - New York, NY

+1.646.307.=
1990=C2=A0<tel:+1.646.307.1990,,112807485#>

United States - San Francisco, CA

+1.415.594.=
5500=C2=A0<tel:+1.415.594.5500,,112807485#>

United States - Washington, DC

+1.202.602.=
1295=C2=A0<tel:+1.202.602.1295,,112807485#>

Australia - Sydney

+61.2.9191.6319=C2=A0<tel:+61=
.2.9191.6319,,112807485#>

France - Paris

+33.1.8288.3590=C2=A0<tel:+33=
.1.8288.3590,,112807485#>

Germany - Berlin

+49.30.2240.3071 <tel:+49.30.2240.3071,,112807485#>

Singapore - national

+65.3158.1842 <tel:+65.3158.1842,,112807485#>

United Kingdom - London

+44.20.3582.4515 <tel:+44.20.3582.4515,,112807485#>

More phone numbers <https://join.me/intphone/112807485/0=
>

Conference ID:

112-807-485 #

Need to share screen?=C2=A0 Download

=C2=A0the app <https://join.me/app>

Regards,

_____________



Roman Shpount





































































--001a114c7d7ecaf156055a40410e--


From nobody Thu Sep 28 07:29:19 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4C31331E7 for ; Thu, 28 Sep 2017 07:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VTe3R75OulhS for ; Thu, 28 Sep 2017 07:29:14 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 E487C1331D9 for ; Thu, 28 Sep 2017 07:29:13 -0700 (PDT)
X-AuditID: c1b4fb25-967ff70000005333-12-59cd073794f0
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 77.EB.21299.7370DC95; Thu, 28 Sep 2017 16:29:12 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 16:29:11 +0200
From: Christer Holmberg 
To: Eric Rescorla 
CC: Roman Shpount , Justin Uberti , lemming Andreasen , Bernard Aboba , "mmusic@ietf.org" , "Paul Kyzivat" , Ben Campbell , Adam Roach , Jonathan Lennox , Bo Burman 
Thread-Topic: Presentation for a call if DTLS Association be started if not requested in the offer
Thread-Index: AQHTOBvxh7e1K2Boh0yXov/6g550d6LJ5oGA///8D4CAAAQfAIAAa5YA///UwYCAADi4gP//0SCAAAey7IA=
Date: Thu, 28 Sep 2017 14:29:10 +0000
Message-ID: 
References:        
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="utf-8"
Content-ID: <340D9C392162AD40B41BEFA11AAA3D82@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUyM2J7uK4F+9lIg5VXuC32/F3EbjG/8zS7 xdLednaLFa/PsVu8v6BrsX/xeWaLrVOFLKYuf8xisWLDAVaLGRemMjtwefx9/4HJY8rvjawe CzaVeixZ8pPJo3XHX3aPWTufsHhMftzG7HFrSoFH27M77AGcUVw2Kak5mWWpRfp2CVwZZz4+ ZCo4oFZx98kexgbGA6pdjJwcEgImEk0951m7GLk4hASOMEpMXfgbylnEKDHjZSdzFyMHB5uA hUT3P22QBhEBBYlff06wgNQwC/xjknjbd50JJCEskCyxae9aFoiiFInjF6+yQthJEhO+/ACr YRFQlfjb3MEGYvMKWEts2fuMBWJZE4vEx/lz2EESnAKBEnfX3AErYhQQk/h+ag1YM7OAuMSt J/OZIM4WkFiy5zwzhC0q8fLxP7BlogJ6EhtO3GYHOVpCQFFieb8ciMksoCmxfpc+xBRriQe7 LzBD2IoSU7ofskOcIyhxcuYTlgmM4rOQLJuF0D0LSfcsJN2zkHQvYGRdxShanFqclJtuZKyX WpSZXFycn6eXl1qyiREY+we3/FbdwXj5jeMhRgEORiUe3jCms5FCrIllxZW5hxglOJiVRHh/ MgKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYGSbuDMo eYuLhrnLjrrQx69fSrsz671XTAn2V0g145BU903NYPgZMTv8bO+1p+uf32A+pesd+GKqdnva st5vH17dvrnL2K5ua/tc9gtaUvt6Fr7/tlaxVzMpSDdOne+3+1apUv+7zcKX/FL37fJ7zpwn WZnF3Bz+ZUdCnYPSobx9B/0ctqv1KLEUZyQaajEXFScCAEJpRP75AgAA
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 14:29:17 -0000

SGksDQoNCi4uLg0KDQo+Pj4+QWxzbywgScK5ZCBsaWtlIHRvIGhlYXIgeW91ciBzdWdnZXN0aW9u
IG9uIGhvdyB0byBoYW5kbGUgYmFja3dhcmQNCj4+Pj5jb21wYXRpYmlsaXR5IHdpdGggZW5kcG9p
bnRzIHRoYXQgZG9uwrl0IHN1cHBvcnQgdGxzLWlkDQo+Pj4+KHJlYWQ6IGVuZHBvaW50cyB0aGF0
IG1heSB0cmlnZ2VyIG5ldyBEVExTIGFzc29jaWF0aW9uIGluIHRoZSBhbnN3ZXIpLg0KPj4+Pk1h
eWJlIHRoZSBwcm9ibGVtIHdpbGwgZ28gYXdheSBvbmUgZGF5LCBidXQgSSBkb27CuXQgdGhpbmsg
d2UNCj4+Pj5hbiBqdXN0IGNsb3NlIG91ciBleWVzIGFuZCB3YWl0IGZvciB0aGF0IGRheSB0byBj
b21lxaANCj4+Pg0KPj4+V2hpY2ggZW5kcG9pbnRzIGRvIHRoYXQ/IEJlY2F1c2UgdGhhdCdzIGFi
c29sdXRlbHkgZ29pbmcgdG8gYmUgZm9yYmlkZGVuDQo+Pj5ieSBKU0VQLg0KPj4NCj4+4oCYTGVn
YWN5JyBSRkMgNTc2My1jb21wbGlhbnQgZW5kcG9pbnRzIHRoYXQgZG9uwrl0IHN1cHBvcnQgdGxz
LWlkLg0KPj4NCj4gU29ycnksIEkgd2FzIGFza2luZyAid2hpY2ggYWN0dWFsIGltcGxlbWVudGF0
aW9ucyBkbyB0aGlzIj8NCg0KSSBkb27igJl0IGtub3cgLSBwZXJoYXBzIFJvbWFuIGtub3dzPw0K
DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIFRodSwgU2Vw
IDI4LCAyMDE3IGF0IDExOjE0IEFNLCBSb21hbiBTaHBvdW50DQo8cm9tYW5AdGVsdXJpeC5jb20+
IHdyb3RlOg0KDQpIaSBBbGwsDQoNCkkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSBpZiBhbmQgaG93
IGV4YWN0bHkgYWxsb3dpbmcgbmV3IERUTFMgYXNzb2NpYXRpb24NCndoZW4gbm90IHJlcXVlc3Rl
ZCBpbiB0aGUgb2ZmZXIsIGNvbnRyYWRpY3RzIEpTRVAuDQoNClJvbWFuIFNocG91bnQNCg0KDQoN
Ck9uIFNlcCAyOCwgMjAxNyAwMjoyMiwgIkNocmlzdGVyIEhvbG1iZXJnIg0KPGNocmlzdGVyLmhv
bG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNClRoYW5rcyBSb21hbiENCg0KSSB3b3VsZCBy
ZXF1ZXN0IHRob3NlIHRoYXQgZG8gTk9UIHdhbnQgdG8gYWxsb3cgYW4gYW5zd2VyZXIgdG8gdHJp
Z2dlciBhDQpuZXcgRFRMUyBhc3NvY2lhdGlvbiB0byBwcmVwYXJlIGEgZGVzY3JpcHRpb24gKHZl
cmJhbGx5IG9yIHVzaW5nIHNsaWRlcykNCm9uIGhvdyB0aGV5IHN1Z2dlc3QgaGFuZGxpbmcgaW50
ZXJvcGVyYWJpbGl0eSB3aXRoIGxlZ2FjeSBwZWVycyB0aGF0IG1heQ0KdHJpZ2dlciBhIG5ldyBE
VExTIGFzc29jaWF0aW9uIGluDQogdGhlIGFuc3dlci4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN
Cg0KRnJvbTogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+DQpEYXRlOiBUaHVyc2Rh
eSAyOCBTZXB0ZW1iZXIgMjAxNyBhdCAwODozNw0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp
c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+LCAiYWRhbUBub3N0cnVtLmNvbSINCjxhZGFtQG5v
c3RydW0uY29tPiwNCiBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4sIEJlcm5hcmQgQWJv
YmENCjxCZXJuYXJkLkFib2JhQG1pY3Jvc29mdC5jb20+LCBCbyBCdXJtYW4gPGJvLmJ1cm1hbkBl
cmljc3Nvbi5jb20+LA0KIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4sIEZsZW1taW5nIEFu
ZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPiwNCkpvbmF0aGFuIExlbm5veCA8am9uYXRoYW5A
dmlkeW8uY29tPiwNCiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20+LCAicGt5eml2
YXRAYWx1bS5taXQuZWR1Ig0KPHBreXppdmF0QGFsdW0ubWl0LmVkdT4sDQogIm1tdXNpY0BpZXRm
Lm9yZyIgPG1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFByZXNlbnRhdGlvbiBmb3IgYSBjYWxs
IGlmIERUTFMgQXNzb2NpYXRpb24gYmUgc3RhcnRlZCBpZiBub3QNCnJlcXVlc3RlZCBpbiB0aGUg
b2ZmZXINCg0KDQpIaSBBbGwsDQoNCkF0dGFjaGVkIGlzIHRoZSBwcmVzZW50YXRpb24gZm9yIHRo
ZSBjYWxsIHRvbW9ycm93IChvciBsYXRlciB0b2RheSkNCg0KT25jZSBhZ2FpbiwgY29uZmVyZW5j
ZSBjYWxsIGluZm9ybWF0aW9uOg0KDQoNCkpvaW4gdGhlIG1lZXRpbmc6IA0Kam9pbi5tZS8xMTIt
ODA3LTQ4NSA8aHR0cDovL2pvaW4ubWUvMTEyLTgwNy00ODU+DQo8aHR0cHM6Ly9qb2luLm1lLzEx
Mi04MDctNDg1Pg0KDQpUaHVyc2RheSwgU2VwdGVtYmVyDQogMjgsIDIwMTcgMTI6MDAgUE0NCkVh
c3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpDQpJbg0KIG15IHRpbWUgem9uZT8gPGh0dHBzOi8vam9p
bi5tZS90aW1lem9uZS8xNTA2NjE0NDAwMDAwLzE1MDY2MjE2MDAwMDA+DQpUbyBkaWFsIGluIGJ5
IHBob25lOlVuaXRlZCBTdGF0ZXMgLSBMb3MgQW5nZWxlcywgQ0ENCisxLjIxMy4yMjYuMTA2NiA8
dGVsOiUyQjEuMjEzLjIyNi4xMDY2PiA8dGVsOisxLjIxMy4yMjYuMTA2Ng0KPHRlbDolMkIxLjIx
My4yMjYuMTA2Nj4sLDExMjgwNzQ4NSM+DQpVbml0ZWQgU3RhdGVzIC0gTmV3IFlvcmssIE5ZDQor
MS42NDYuMzA3LjE5OTAgPHRlbDolMkIxLjY0Ni4zMDcuMTk5MD4gPHRlbDorMS42NDYuMzA3LjE5
OTANCjx0ZWw6JTJCMS42NDYuMzA3LjE5OTA+LCwxMTI4MDc0ODUjPg0KVW5pdGVkIFN0YXRlcyAt
IFNhbiBGcmFuY2lzY28sIENBDQorMS40MTUuNTk0LjU1MDAgPHRlbDolMkIxLjQxNS41OTQuNTUw
MD4gPHRlbDorMS40MTUuNTk0LjU1MDANCjx0ZWw6JTJCMS40MTUuNTk0LjU1MDA+LCwxMTI4MDc0
ODUjPg0KVW5pdGVkIFN0YXRlcyAtIFdhc2hpbmd0b24sIERDDQorMS4yMDIuNjAyLjEyOTUgPHRl
bDolMkIxLjIwMi42MDIuMTI5NT4gPHRlbDorMS4yMDIuNjAyLjEyOTUNCjx0ZWw6JTJCMS4yMDIu
NjAyLjEyOTU+LCwxMTI4MDc0ODUjPg0KQXVzdHJhbGlhIC0gU3lkbmV5DQorNjEuMi45MTkxLjYz
MTkgPHRlbDolMkI2MS4yLjkxOTEuNjMxOT4gPHRlbDorNjEuMi45MTkxLjYzMTkNCjx0ZWw6JTJC
NjEuMi45MTkxLjYzMTk+LCwxMTI4MDc0ODUjPg0KRnJhbmNlIC0gUGFyaXMNCiszMy4xLjgyODgu
MzU5MCA8dGVsOiUyQjMzLjEuODI4OC4zNTkwPiA8dGVsOiszMy4xLjgyODguMzU5MA0KPHRlbDol
MkIzMy4xLjgyODguMzU5MD4sLDExMjgwNzQ4NSM+DQpHZXJtYW55IC0gQmVybGluDQorNDkuMzAu
MjI0MC4zMDcxIDx0ZWw6KzQ5LjMwLjIyNDAuMzA3MSwsMTEyODA3NDg1Iz4NClNpbmdhcG9yZSAt
IG5hdGlvbmFsDQorNjUuMzE1OC4xODQyIDx0ZWw6KzY1LjMxNTguMTg0MiwsMTEyODA3NDg1Iz4N
ClVuaXRlZCBLaW5nZG9tIC0gTG9uZG9uDQorNDQuMjAuMzU4Mi40NTE1IDx0ZWw6KzQ0LjIwLjM1
ODIuNDUxNSwsMTEyODA3NDg1Iz4NCk1vcmUgcGhvbmUgbnVtYmVycyA8aHR0cHM6Ly9qb2luLm1l
L2ludHBob25lLzExMjgwNzQ4NS8wPg0KQ29uZmVyZW5jZSBJRDoNCjExMi04MDctNDg1ICMNCk5l
ZWQgdG8gc2hhcmUgc2NyZWVuPyAgRG93bmxvYWQNCiB0aGUgYXBwIDxodHRwczovL2pvaW4ubWUv
YXBwPg0KUmVnYXJkcywNCl9fX19fX19fX19fX18NCg0KUm9tYW4gU2hwb3VudA0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQo=


From nobody Thu Sep 28 08:01:01 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9C713307F for ; Thu, 28 Sep 2017 08:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xnV3OqWcKSAT for ; Thu, 28 Sep 2017 08:00:53 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 37BDD1332E3 for ; Thu, 28 Sep 2017 08:00:53 -0700 (PDT)
X-AuditID: c1b4fb30-cbdff70000001911-d8-59cd0ea3076d
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.08.06417.3AE0DC95; Thu, 28 Sep 2017 17:00:51 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.6]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 17:00:50 +0200
From: Christer Holmberg 
To: Roman Shpount 
CC: Justin Uberti , lemming Andreasen , Bernard Aboba , "Eric Rescorla" , "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell , Adam Roach , Jonathan Lennox , Bo Burman 
Thread-Topic: Presentation for a call if DTLS Association be started if not requested in the offer - ehterpad
Thread-Index: AdM4ao9afDgTwKaITE6A2c+hPKagVA==
Date: Thu, 28 Sep 2017 15:00:50 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B56305018@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B56305018ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUyM2K7n+5ivrORBptaJC32/F3EbjG/8zS7 xdLednaLFa/PsVu8v6BrsX/xeWaLrVOFLKYuf8xisWLDAVaLGRemMjtwefx9/4HJY8rvjawe CzaVeixZ8pPJo3XHX3aPWTufsHhMftzG7HFrSoFH27M77AGcUVw2Kak5mWWpRfp2CVwZDbeu sBQs0q6YtrmbpYGxQauLkZNDQsBEYkrHa/YuRi4OIYEjjBK/jx5ig3AWMUr8f97E3MXIwcEm YCHR/U8bpEFEQFXi7/fJTCA1zAI/mSS+HjjLDpIQFsiTmHn/AQtEUb7Eu0mnoWw9iRuzb7CC 2CxAzW3fjrGAzOQV8JV4d6wCJMwoICbx/dQaJhCbWUBc4taT+UwQxwlILNlznhnCFpV4+fgf K4StJNG45AkrRH2+xLwvf8BO4BUQlDg58wnLBEahWUhGzUJSNgtJ2SygK5gFNCXW79KHKFGU mNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAmD245bfBDsaX zx0PMQpwMCrx8B5nPhspxJpYVlyZe4hRgoNZSYQ3hRsoxJuSWFmVWpQfX1Sak1p8iFGag0VJ nNdx34UIIYH0xJLU7NTUgtQimCwTB6dUA+Oqe6e+cLfahjB3x55es8GsPIlh373DKuvaQttT poTdD/z28UqFhEntbS7Dx3tau9yv8sY8CHBjm1WgOOv3ukm+O9pdnvAVCD4TVaj7n9P+1ODF 01qVf7tZXdsjJuzK77BpqSz928/88d5liZJDxTuvzsl+upFrUvz7Kd2KiQWTNVouN8/OFlJi Kc5INNRiLipOBAAqb2tw1QIAAA==
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer - ehterpad
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 15:01:00 -0000

--_000_7594FB04B1934943A5C02806D1A2204B56305018ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RXRoZXJwYWQgZm9yIHRoZSBtZWV0aW5nOg0KDQpodHRwczovL2V0aGVycGFkLnRvb2xzLmlldGYu
b3JnL3AvZHRscy1zZHANCg0KRXZlcnlvbmUganVzdCB2b2x1bnRlZXJlZCB0byB0YWtlIG5vdGVz
IDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg==

--_000_7594FB04B1934943A5C02806D1A2204B56305018ESESSMB109erics_
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
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K
CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u
RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNl
Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy
LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkV0aGVy
cGFkIGZvciB0aGUgbWVldGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxhIGhyZWY9Imh0dHBzOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmcvcC9kdGxzLXNkcCI+
aHR0cHM6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZy9wL2R0bHMtc2RwPC9hPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+RXZlcnlvbmUganVzdCB2b2x1bnRlZXJlZCB0
byB0YWtlIG5vdGVzIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5S
ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_7594FB04B1934943A5C02806D1A2204B56305018ESESSMB109erics_--


From nobody Thu Sep 28 09:54:34 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFAC134732 for ; Thu, 28 Sep 2017 09:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51mKofc2Ps3o for ; Thu, 28 Sep 2017 09:54:31 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43011134231 for ; Thu, 28 Sep 2017 09:54:29 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id p10so1444900ywh.8 for ; Thu, 28 Sep 2017 09:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vGD18ClNh+Oe/PkhUUN6bYe250dltPL80kI1xvv7gig=; b=GmHIIIN3kiDvGur8VsdvAIaDY8UJGh25SXSAI3cnAHMqAEYribys/PfQe6Q2MV0uxH S9aCpMy0O8GZXp1kyYOKXGu4Mk15htzWcvLPTwePhRU4NxF64RwJ6GRB5wN4tzNQLnPt JwUMQo5iwkuC2fNxx47RyJNO1q3Q9g8+vk2cQWgQ5QIiFDXpJrYlbCM6G2jiR+1ZArVd Dt48h62W1z6MaYSN9q6y7LMoCg5mtzd8rnOVa4B9CroFH8y3Iq3FNePEl4lAakcGw12E Mqa0OLW032Mert6/PTNbwgGtVUdgC+702a1oEi+junOfpbDpNXsXIaiAW0YGvz3oMtBF 8QeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vGD18ClNh+Oe/PkhUUN6bYe250dltPL80kI1xvv7gig=; b=cMeNq2CKJMtKJ09PJ9+Re1hQGYR5CxNXZC+hhI+Qbai9uoHeFW/YQsSsuO6d6ytUt8 0Q6eLgkww9FsYIKDzm1VvPuRPNaTjFMXOORaFQ9cwKxg1+afijf1Hy2ol0EbHUgZvvw1 +P9zTE5QUDw4uZ65OZSVm2AOPebXi3FA6OkLQHToRaSoF/FufM0XKb/TgXYrqWsD6r6V hA2/eJ24ZJz227i3WubpsQ+GZFSX7FocTugUBErgcvi/Ji+/x/cAq9rLFHRaRZHPRPp6 abeT2eXYk/YG4wfWvbtzzVLIiT61ytAveBqoIP9UzQypL9bnyVjp7+VNBdL4eM0Tvhiv xziA==
X-Gm-Message-State: AHPjjUjf0/9btHtWOz1FRKd7J9OpYUPzDOLzUI1y7lQSrDMy+j6rdOYj DV5OVexQuKQ4+kn5sLX867Dl1SqV8K6zBMbl9N6AEA==
X-Google-Smtp-Source: AOwi7QA3goGlf0bAD/lIhCz/96xq1+fIVl0ccVlE8IQW7A6faGZm3pn5RDHKiXJYH813whk6msNX4qK6Lf5FWsreR3Q=
X-Received: by 10.129.108.201 with SMTP id h192mr3941855ywc.161.1506617668493;  Thu, 28 Sep 2017 09:54:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.17 with HTTP; Thu, 28 Sep 2017 09:53:47 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B56305018@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B56305018@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Thu, 28 Sep 2017 18:53:47 +0200
Message-ID: 
To: Christer Holmberg 
Cc: Roman Shpount , Justin Uberti ,  lemming Andreasen , Bernard Aboba ,  "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell ,  Adam Roach , Jonathan Lennox ,  Bo Burman 
Content-Type: multipart/alternative; boundary="001a114dad96f18b87055a42c21e"
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer - ehterpad
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 16:54:34 -0000

--001a114dad96f18b87055a42c21e
Content-Type: text/plain; charset="UTF-8"

Summarizing my proposal on today's call:

As an offerer:
If the answerer changes either {fingerprint, tls-id} then {
  if (!doing ICE restart) {
    error
  } else {
    do a new DTLS negotiation
  }
}

There is a race condition on the offerer if you are in ICE lite or
something where you might receive DTLS packets before the Answer. The
DTLS-SDP spec requires an ICE restart under these conditions, so you will
not be receiving anything from the old connection on the new 5-tuples.
Thus, you only need to disambiguate between: {RTP or SCTP on the current
DTLS association} and {ClientHello from the new association}. This can be
dealt with by (a) latching on the first thing that looks like it matches
one or the other pattern, i.e., it's either a ClientHello or it decrypts
successfully or (b) discarding everything until you get the answer, which
is something that happens automatically in most ICE scenarios.

As an answerer, JSEP implementations MUST NOT change the TLS-ID or the
Fingerprint unless the offerer sent a new TLS-ID

-Ekr



On Thu, Sep 28, 2017 at 5:00 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Etherpad for the meeting:
>
>
>
> https://etherpad.tools.ietf.org/p/dtls-sdp
>
>
>
> Everyone just volunteered to take notes :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>

--001a114dad96f18b87055a42c21e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Summarizing my proposal on today's call:

As an offerer:
If the answerer changes either {fingerprint,=
 tls-id} then {
=C2=A0 if (!doing ICE restart) {
=C2=A0=
 =C2=A0 error
=C2=A0 } else {
=C2=A0 =C2=A0 do a new DT=
LS negotiation
=C2=A0 }
}

<=
div>There is a race condition on the offerer if you are in ICE lite or some=
thing where you might receive DTLS packets before the Answer. The DTLS-SDP =
spec requires an ICE restart under these conditions, so you will not be rec=
eiving anything from the old connection on the new 5-tuples. Thus, you only=
 need to disambiguate between: {RTP or SCTP on the current DTLS association=
} and {ClientHello from the new association}. This can be dealt with by (a)=
 latching on the first thing that looks like it matches one or the other pa=
ttern, i.e., it's either a ClientHello or it decrypts successfully or (=
b) discarding everything until you get the answer, which is something that =
happens automatically in most ICE scenarios.

As an=
 answerer, JSEP implementations MUST NOT change the TLS-ID or the Fingerpri=
nt unless the offerer sent a new TLS-ID

-Ekr
=




On Thu, Sep 28, 2017 at 5:00 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:











Etherpad for the meeting:


=C2=A0


https://etherpad.tools.ietf.org/p/=
dtls-sdp


=C2=A0


Everyone just volunteered to take not=
es :)


=C2=A0


Regards,


=C2=A0


Christer


=C2=A0










--001a114dad96f18b87055a42c21e--


From nobody Thu Sep 28 10:27:11 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA41342D2 for ; Thu, 28 Sep 2017 10:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKZNej1xxWXg for ; Thu, 28 Sep 2017 10:27:07 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21231342C2 for ; Thu, 28 Sep 2017 10:27:06 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id v3so1307994pgv.3 for ; Thu, 28 Sep 2017 10:27:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VIRRR8NhHvNwH8O1IibK7C66ssxMmK1LI1uYt0tmR5E=; b=KykYml8GMfy2BbSwrPDP+5AehtbXNn8VPHpvrf9TbkHbcr18eZHHjPoi7HQo7O4PcT 5YSGVGvUy+tnpBX+V9HyBMlDUjdrGAfwbcn1YRBZlufNaTWsc/JqPRZlzhZlmRacvaAX JoFdEWDGJuaKaTNwmmHe6CErhJIdV9Ca17y8EAQpljxUAlQBQ+jWNRR1fh+wfdgB9HXu qk9u1n7IjRjCNImkQCLu3JaGDJRe14M6ANpATWsHIF7wOtYrjv3yg9Mzt1VIIAAjBn6D H0Lw7tWzgUkpbGjTxHd6qu128vGmAqLDcLAgMXuvSzrqMC/5ULzMIHLEHoOxAoeXq843 pqzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VIRRR8NhHvNwH8O1IibK7C66ssxMmK1LI1uYt0tmR5E=; b=CLK/6L6cd84LxxPNKxsJhrKgzlXBO7INh8CB3UwEcIpRACyFxHbkmWUhb99w1aKS4Z d2lesh8H/0L4xi5s5WjSdWoaULsNflALu0vX++wKQiXtHxB+acA7uBaHqtvLhGhr9LZ4 oWIlLx7km+9wBtmiUlbLFyeaaU8VN1OB/yI5vDMbV9YBtHARsa9Mb3965TfxqPE/iQ/f 44ED4lE+jWXcIEMZa6eEcUyRjdLVTOID2NchuJKxSV+yKav6TjS0kheYn5L/PQjB9Oxr kKLjhbdnoSvjl1EARL0Near9KSkd0htVZvkxCMKL4khfPz6CkermOV2hAyCbBfWHzquh PsxA==
X-Gm-Message-State: AHPjjUjV6SQUCAbWYULxSFpGKYOeUMX/O9iWq/hhTCyrpQgFHpVEXe8r kEpVUoOycb4cIRjPTetyOYYSvo81
X-Received: by 10.98.102.20 with SMTP id a20mr5004125pfc.208.1506619626106; Thu, 28 Sep 2017 10:27:06 -0700 (PDT)
Received: from mail-pg0-f54.google.com (mail-pg0-f54.google.com. [74.125.83.54]) by smtp.gmail.com with ESMTPSA id r12sm3493038pgp.81.2017.09.28.10.27.05 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 10:27:05 -0700 (PDT)
Received: by mail-pg0-f54.google.com with SMTP id u18so1309989pgo.0 for ; Thu, 28 Sep 2017 10:27:05 -0700 (PDT)
X-Google-Smtp-Source: AOwi7QB5f27lL0fYan1bOP4hoZqv+MqwyUPkLHria/Jm7QBYo8TVEYv/pkh9fVv3QktEKVBCXu5J5So45oTnytJrpio=
X-Received: by 10.99.185.93 with SMTP id v29mr4952779pgo.32.1506619624768; Thu, 28 Sep 2017 10:27:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.189.2 with HTTP; Thu, 28 Sep 2017 10:27:04 -0700 (PDT)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B56305018@ESESSMB109.ericsson.se> 
From: Roman Shpount 
Date: Thu, 28 Sep 2017 13:27:04 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Eric Rescorla 
Cc: Christer Holmberg , Justin Uberti ,  lemming Andreasen , Bernard Aboba ,  "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell ,  Adam Roach , Jonathan Lennox ,  Bo Burman 
Content-Type: multipart/alternative; boundary="94eb2c1bac828bd24b055a4337df"
Archived-At: 
Subject: Re: [MMUSIC] Presentation for a call if DTLS Association be started if not requested in the offer - ehterpad
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 17:27:09 -0000

--94eb2c1bac828bd24b055a4337df
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 28, 2017 at 12:53 PM, Eric Rescorla  wrote:

> Summarizing my proposal on today's call:
>
> As an offerer:
> If the answerer changes either {fingerprint, tls-id} then {
>   if (!doing ICE restart) {
>     error
>   } else {
>     do a new DTLS negotiation
>   }
> }
>

Agreed

There is a race condition on the offerer if you are in ICE lite or
> something where you might receive DTLS packets before the Answer. The
> DTLS-SDP spec requires an ICE restart under these conditions, so you will
> not be receiving anything from the old connection on the new 5-tuples.
> Thus, you only need to disambiguate between: {RTP or SCTP on the current
> DTLS association} and {ClientHello from the new association}. This can be
> dealt with by (a) latching on the first thing that looks like it matches
> one or the other pattern, i.e., it's either a ClientHello or it decrypts
> successfully or (b) discarding everything until you get the answer, which
> is something that happens automatically in most ICE scenarios.
>

This all looks good, except for potential fragmented ClientHello message
with fragments received out of order. Another potential failure scenario is
SRTP from the old dead call being sent over the new 5-tuple. My proposal
was not to latch on things that cannot be decoded as current DTLS
association or SRTP.


> As an answerer, JSEP implementations MUST NOT change the TLS-ID or the
> Fingerprint unless the offerer sent a new TLS-ID
>

Agreed
_____________
Roman Shpount

--94eb2c1bac828bd24b055a4337df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=
On Thu, Sep 28, 2017 at 12:53 PM, Eric Rescorla <ekr@rtfm.com> wr=
ote:
=
Summarizing my proposal on today's call:

As an offer=
er:
If the answerer changes either {fingerprint, tls-id} then {
=C2=A0 if (!doing ICE restart) {
=C2=A0 =C2=A0 error
=C2=A0 } else {
=C2=A0 =C2=A0 do a new DTLS negotiation
=C2=A0 }
}
=C2=A0
<=
div>Agreed

There is a race condition on the off=
erer if you are in ICE lite or something where you might receive DTLS packe=
ts before the Answer. The DTLS-SDP spec requires an ICE restart under these=
 conditions, so you will not be receiving anything from the old connection =
on the new 5-tuples. Thus, you only need to disambiguate between: {RTP or S=
CTP on the current DTLS association} and {ClientHello from the new associat=
ion}. This can be dealt with by (a) latching on the first thing that looks =
like it matches one or the other pattern, i.e., it's either a ClientHel=
lo or it decrypts successfully or (b) discarding everything until you get t=
he answer, which is something that happens automatically in most ICE scenar=
ios.

This all looks good, excep=
t for potential fragmented ClientHello message with fragments received out =
of order. Another potential failure scenario is SRTP from the old dead call=
 being sent over the new 5-tuple. My proposal was not to latch on things th=
at cannot be decoded as current DTLS association or SRTP.
=C2=
=A0
As an answerer, JSEP implementations MUST NOT change the TLS-ID o=
r the Fingerprint unless the offerer sent a new TLS-ID

Agreed=C2=A0
<=
div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0


--94eb2c1bac828bd24b055a4337df--


From nobody Fri Sep 29 15:13:56 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0260134303; Fri, 29 Sep 2017 15:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx0dakyJGdtb; Fri, 29 Sep 2017 15:13:52 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316F6134302; Fri, 29 Sep 2017 15:13:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1403; q=dns/txt; s=iport; t=1506723232; x=1507932832; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xVkeGiGZ8gfQTLw7VJkkN2DSxYlcHg3kf89QHLA7glw=; b=EGslvnwkEMpG2OEGtvbYTRaN499x2wS7Yha71iaAB6YY9AAWyZ6f9ka5 Jl2a5oJuSFllPvWphNAjnh/VJeMgHJpWuXTepYN4J7oRvotbKxHC2EjX+ KMJropdDAkWqnbNVKkguwwZN+zbmMPO+AfFVu5nwUYyw2ZqLEp4L6iun7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQBKxM5Z/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1xkbieDeJoCgXaYPgoYC4RJTwKEM0IVAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?BAQMBASEPAQU2CxALGAICJgICJzAGDQYCAQGKIA0QpX2CJ4tAAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGwWBDoIfggKBUYFqK4J9iBeCYAEEoS+UZIIUhW6DWoVggUuVUIE?= =?us-ascii?q?5NSKBDlMlFUmFGhyCAyQ2AYlQAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,454,1500940800"; d="scan'208";a="305352165"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Sep 2017 22:13:50 +0000
Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8TMDoiW018419; Fri, 29 Sep 2017 22:13:50 GMT
From: Flemming Andreasen 
To: mmusic 
Cc: "draft-ietf-mmusic-trickle-ice-sip@ietf.org" 
References: <50b57d8c-127d-419d-9da3-7141adf13402@cisco.com> 
Message-ID: <5730b701-2e55-9aee-faa1-c7f1d06af74f@cisco.com>
Date: Fri, 29 Sep 2017 18:14:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-trickle-ice-sip-08
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 22:13:55 -0000

Folks

We really need some feedback on this document. I don't know how we can 
progress a document that has seemingly received no review or feedback 
from the group.

Thanks

-- Flemming (with chair-hat on)



On 9/15/17 2:41 PM, Flemming Andreasen wrote:
> The WGLC has ended, however we did not receive any comments from 
> anybody. If you reviewed the draft (or a recent version of it) and 
> believe the draft is ready to move forward, please send a note to that 
> effect.
>
> Thanks
>
> -- Flemming
>
>
> On 8/30/17 4:21 PM, Flemming Andreasen wrote:
>> Greetings MMUSIC
>>
>> This is to announce a 2 week WGLC on the  draft:
>>
>> https://www.ietf.org/id/draft-ietf-mmusic-trickle-ice-sip-08.txt
>>
>> as Proposed Standard. Please review and provide any comments you may 
>> have on the document by Wednesday, September 13, 2017. Comments 
>> should be sent to the document authors and the MMUSIC WG list. If you 
>> review the document but do not have any comments, please send a note 
>> to that effect as well.
>>
>> Thanks
>>
>> -- Flemming (MMUSIC co-chair)
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


From nobody Sat Sep 30 14:07:20 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D86134239 for ; Sat, 30 Sep 2017 14:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUDpCbX2tFag for ; Sat, 30 Sep 2017 14:07:17 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61180124B18 for ; Sat, 30 Sep 2017 14:07:17 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id m72so4610799wmc.1 for ; Sat, 30 Sep 2017 14:07:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=juNmx14tQYy9DtYahpsHIp90QtAdbCJ0+at4ztEh6y8=; b=h/a/+36XOzIPiIY7AL5vG1HXNmYuclqNSCJeVSheAdPHbfPypV8Hyg/GH/ng5Hjnkk 9uAXw1apOZDqgheSqic3T8MTlYgsAsAErSWBPAbWN3GqGEssgqybXezYM39d3Wh9FMdS nnvfp2YwmU+fJl6bCEXxQLpQOXK7VUzMtbtoOXjAWmhtFqlrQVJoGYVTGkfxNiu0g+5m 655lnmHxqGvwwxYBMsJZ6oCaD17kPF6/x4V13AIEh5ULy8Y/RuW49EVZ8lHadliTHiRb mWbCEXhvSW3PHq7WAqBxN66yxjZMlkcJ6MeelaOvEx3wW0iA1HfpCmg4UnY3nkxrBxuh vTZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=juNmx14tQYy9DtYahpsHIp90QtAdbCJ0+at4ztEh6y8=; b=apR+b2A1vixr0eV+0TvGB6J/qoEAsWz+IL70Erc516TrZCMR8rS8xptjupinoxMLUt RT3C2ZQybLFGgi1CbEIHEWXExSIIzZE3hxZazGAuavYsC/saN/rFlt/wz9enC96ZnCHk AZ0E28SPq9H37iZ6OXDdhTcwVyzpe1TMV6B/8nEtiKhlu2ODZUMiMhf2q2q3UsWO7OqY 7RtUMjXe4Qm/HOnWNV4a1H3LsIcO7BpZhbOSZYl9URWUkE4Uxvd0+P89YK5ETmdpEZzr e9H1qeUqxu7FS/fpdX90snkQmlZhX2B55Q9714g1h94u7Pt31DoPBg4lHsH46xp853KS PypQ==
X-Gm-Message-State: AHPjjUjsHoR9vy/ltcTWUUhQXyydNrcnlUG9KEicPwNpomirI8NUH1kv Zhpe7KRU8pMaIRf7U+ko+VjcTxAKax8+OU0GAJ3V4iol
X-Google-Smtp-Source: AOwi7QDQ1+Qvu7J0sH2dPokf6vo1QjVl+vshcUcTqsQcyq96SPMRfAe7DdCNs9rrZx8YcAbthMR65z6GX8QALFNC28A=
X-Received: by 10.28.67.197 with SMTP id q188mr6633564wma.66.1506805635380; Sat, 30 Sep 2017 14:07:15 -0700 (PDT)
MIME-Version: 1.0
From: Peter Thatcher 
Date: Sat, 30 Sep 2017 21:07:04 +0000
Message-ID: 
To: "mmusic@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0d4b66a50514055a6e86d3"
Archived-At: 
Subject: [MMUSIC] WGLC for draft-ietf-ice-rfc5245bis-12
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Sep 2017 21:07:19 -0000

--94eb2c0d4b66a50514055a6e86d3
Content-Type: text/plain; charset="UTF-8"

FYI, in the ICE WG we've just begun the WGLC for
draft-ietf-ice-rfc5245bis-12. It will be 3 weeks and end on Oct 21, 2017
(not 2018 :).  Please direct review comments to the ICE WG mailing list.

If possible, we would like a dedicated reviewer from mmusic to perform a
"consistent check in depth" with the mmusic documents.   If you're willing
to be that dedicate reviewer, please let me know.

--94eb2c0d4b66a50514055a6e86d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


FYI, in the ICE WG we've just begun the WGLC for draft=
-ietf-ice-rfc5245bis-12. It will be 3 weeks and end on Oct 21, 2017 (not 20=
18 :).=C2=A0 Please direct review comments to the ICE WG mailing list.=C2=
=A0=C2=A0

If possible, we would like a dedicated reviewer from mmusi=
c to perform a "consistent check in depth" with the mmusic docume=
nts.=C2=A0 =C2=A0If you're willing to be that dedicate reviewer, please=
 let me know.=C2=A0=C2=A0



--94eb2c0d4b66a50514055a6e86d3--


From nobody Sat Sep 30 15:46:53 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C1E1342DD for ; Sat, 30 Sep 2017 15:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.798
X-Spam-Level: 
X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_lXiJLFCuIv for ; Sat, 30 Sep 2017 15:46:49 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9588C13247A for ; Sat, 30 Sep 2017 15:46:49 -0700 (PDT)
Received: by mail-vk0-x22b.google.com with SMTP id w23so1391741vkw.2 for ; Sat, 30 Sep 2017 15:46:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KsShzBCh6L+VFJdvg91TMbSE744xxhPWOSK60jhs/HM=; b=Ltf/sl4+MNnc1n/TFRhkQcXpiIyQXuUQ8vVlUHhLKzBibc35xNEjwPfnnwtPKtBWZn sq/eyHzqBPtzEtVT5DTTf2V4MfAiLEQh16HA8Ps48rxDOziSkn4K4gUJ+81nTiZxbyK2 Ys3ZNV1mkKhkzoBvyuBayN4ohr95zA/pYdcxuRPgfBdaPKQdEGvaFzBcAnErZlot4H0o O/+KgUeQG5Gmd3heE6ZXTC+zj+MXDxolH2nMN++CH5dhuqUgo7kutUV68kh0nEIWjB/m akKyP1v7PcTTsGdYB91ysDMGjqnxoNdhn2v5KM8GTcUAGuLqUkjmudS3Nhg0LvFDVvam gpdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KsShzBCh6L+VFJdvg91TMbSE744xxhPWOSK60jhs/HM=; b=VSeTdKpOS2ZzTA68IaD4hKhsrmiZZF4HlC4qjg+Xf8cQ4QNasnNbdlU+UPwQnopotq TL9rMWX6XoBzitYPt1O3NERKUoMe8RGrUjvJCPNUeee/CgplDsLo4rd7zx4J5nANCcF8 QyqJwE8iMwDhyqpeXz0ZSxI0ZkmZLiYSUqenRowRBnj6pSRvhM2urq286xLRmC2xDobW FUbS6IFd9wwJt1uzhNLoDqU/Rk9vaWZ96JppC6AIH/LjoksOt1ATHUAoPd9OBrJRXQtg VB5JSGKUra6DWFNymY5PFDyKUUrGwGPGsiVBU+DGcwW9WN1OLoBPPvdWsxxkeEoUaxVs POsg==
X-Gm-Message-State: AMCzsaVwPmbvO3NJzsOWgqcRIGzKOQQLy7aLsjct6d1Svw6twOPZ9ajG IP31wGO16P3M/WdTESKJnw7GiyT1wIxhdzTdW3k=
X-Google-Smtp-Source: AOwi7QAMk0QYVtqlAwvH7J1/EMEjWfg0LsEIUBr5YgYt6thT7ZruEpM1lM+nXm3P9C+MlJ/feFYKt9RCiB5ET883aA0=
X-Received: by 10.31.61.11 with SMTP id k11mr360318vka.105.1506811608639; Sat, 30 Sep 2017 15:46:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.10.12 with HTTP; Sat, 30 Sep 2017 15:46:48 -0700 (PDT)
In-Reply-To: 
References: 
From: Suhas Nandakumar 
Date: Sat, 30 Sep 2017 15:46:48 -0700
Message-ID: 
To: Roman Shpount 
Cc: mmusic WG 
Content-Type: multipart/alternative; boundary="001a114da45aad2ea1055a6feac1"
Archived-At: 
Subject: Re: [MMUSIC] ICE-SIP-SDP updates
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Sep 2017 22:46:51 -0000

--001a114da45aad2ea1055a6feac1
Content-Type: text/plain; charset="UTF-8"

Hello Roman

  Just checking back on the above PR and if the changes look good. Also few
comments inline


Thanks
Suhas

On Mon, Sep 18, 2017 at 2:33 AM, Roman Shpount  wrote:

> Hi Suhas,
>
>
> On Mon, Sep 18, 2017 at 12:15 AM, Suhas Nandakumar 
> wrote:
>
>> 1. Handling of ICE mismatch
>>
>> Where is ICE mismatch currently defined? I cannot find this in either
>> rfc5245bis or ICE-SIP-SDP.
>>
>> I think ICE mismatch should occur if address in c= line and port in m=
>> line do not match any of the candidates and address in c= line is not
>> dummy address IN IP4 0.0.0.0 and port in m= line is not dummy port 9
>> . This is needed to match https://tools.ietf.org/html/dr
>> aft-ietf-rtcweb-jsep-21#section-5.2.1 and trickle ICE
>>
>> [Suhas] ICE mismatch is discussed in 4.1.2.3,  4.1.3.1 and 11.2.2
>>
>
> [roman] Section 4.1.2.3 should be modified to allow c= line with IN IP4
> 0.0.0.0 and port in m= line with port 9 not to be treated as ice-mismatch
> even if it does not match any of the candidates. Without this, trickle ICE
> and JSEP will cause ice-mismatch. Furthermore, rtcp attribute is optional,
> so the text needs to be modified to allow for this.
>

[Suhas] I am not sure if ice-sip-sdp needs to define trickle ice
requirements for ice-mismatch. Trickle ICE spec should be handling IP4
0.0.0.0 and port 9 text and have a requirement to mention that it's no
ice-mismatch. This is very similar to ICE-BIS not speaking about trickle-ice


>
> 2. Move general requirements from https://tools.ietf.org/html/dr
>> aft-ietf-mmusic-sctp-sdp-26#section-12.2 into ICE-SIP-SDP.
>>
>> [Suhas] Added the supporting text in the above PR. Also the repository
>> has HTML file for easy reading.
>>
>
> [roman] This looks good, but I will double check and provide comments if I
> find anything.
>

[Suhas] If the changes look good here,I would want to generate a new
version for submission.


>
>> 3. ICE transport tag
>>
>> [Suhas] IIRC, this topic was brought to discussion several times in the
>> WG and there was no consensus on defining a new ICE specific transport tag.
>> Personally, I feel this will be a large undertaking and we should avoid
>> doing this as part of this draft work. I am open to suggestions.
>>
>>
>  [roman]  I agree that this can be left out and handled in the future
> draft if there is enough support for it.
>

[Suhas] Thanks and agree with you


>
> Regards,
> _____________
> Roman Shpount
>
>

--001a114da45aad2ea1055a6feac1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello Roman

=C2=A0 Just checking back o=
n the above PR and if the changes look good. Also few comments inline=C2=A0=



Thanks
Suhas

On Mon, Sep 18, 2017 at=
 2:33 AM, Roman Shpount <roman@telurix.com> wrote:
Hi Suhas,


On Mon,=
 Sep 18, 2017 at 12:15 AM, Suhas Nandakumar <suhasietf@gmail.com&g=
t; wrote:
1. Handling of ICE mismatch

<=
div>Where is ICE mismatch currently defined? I cannot find this in either r=
fc5245bis or ICE-SIP-SDP.=C2=A0

I think ICE mismat=
ch should occur if address in c=3D line and port in m=3D line do not match =
any of the candidates and <new>address in c=3D line is not dummy addr=
ess IN IP4 0.0.0.0 and port in m=3D line is not dummy port 9 </new>. =
This is needed to match https://tools.ietf.org/html/=
draft-ietf-rtcweb-jsep-21#section-5.2.1 and trickle ICE
=


[Suhas] ICE mismatch is discussed in 4.1.2.3, =C2=A04.1=
.3.1 and 11.2.2

[r=
oman] Section 4.1.2.3 should be modified to allow c=3D line with IN IP4 0.0=
.0.0 and port in m=3D line with port 9 not to be treated as ice-mismatch ev=
en if it does not match any of the candidates. Without this, trickle ICE an=
d JSEP will cause ice-mismatch. Furthermore, rtcp attribute is optional, so=
 the text needs to be modified to allow for this.

[Suhas] I am not sure if ice-sip-sdp needs t=
o define trickle ice requirements for ice-mismatch. Trickle ICE spec should=
 be handling IP4 0.0.0.0 and port 9 text and have a requirement to mention =
that it's no ice-mismatch. This is very similar to ICE-BIS not speaking=
 about trickle-ice
=C2=A0
=

2. Move general requirements from https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-26#=
section-12.2 into ICE-SIP-SDP.

[Suhas] Added the supporting text in the above PR. Also t=
he repository has HTML file for easy reading.
<=
/blockquote>

[roman] This looks good, but I will double =
check and provide comments if I find anything.

[Suhas] If the changes look good here,I would w=
ant to generate a new version for submission.
=C2=A0

3. ICE transport tag
<=
span class=3D"">

[Suhas] IIRC, this topic was brought to=
 discussion several times in the WG and there was no consensus on defining =
a new ICE specific transport tag. Personally, I feel this will be a large u=
ndertaking and we should avoid doing this as part of this draft work. I am =
open to suggestions.


=C2=A0[roman]=C2=A0 I agree that this can be left out=
 and handled in the future draft if there is enough support for it.

[Suhas] Thanks and agree w=
ith you
=C2=A0

Regards,
<=
div class=3D"m_-6882536595745355718gmail_signature">_____________
Roman Shpount
<=
/div>






--001a114da45aad2ea1055a6feac1--