From nobody Wed Mar 1 18:57: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 A1751129793; Wed, 1 Mar 2017 18:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 D8m23rXgpigO; Wed, 1 Mar 2017 18:57:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C901D129452; Wed, 1 Mar 2017 18:57:49 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v222vhCW044270 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Mar 2017 20:57:44 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 01 Mar 2017 20:57:43 -0600 Message-ID: <6366ADF1-E3E4-4C91-8579-85246D3E3714@nostrum.com> In-Reply-To: References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , Roman Shpount , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Mar 2017 02:57:50 -0000 Hi all, It seems like this conversation has not completed. What do we need to get to closure? A few thoughts of my own: - I'm not adverse to making non-ICE implementors look at the ICE specs for framing information, as long as the citations are precise enough that they don't need to read the entirety of ICE. (And the information is really there.) - I am adverse to repeating normative text. I'm okay with adding informational text about non-ICE usage, as long as it is general enough to avoid confusion about where the authoritative text resides. - If people think that ICE is not sufficiently specified, we can work on that. But I don't think the burden of doing that belongs to this draft. - The draft is in fact IESG approved in its current state. Material changes should be kept to the minimum. On 27 Feb 2017, at 7:06, Christer Holmberg wrote: > Hi, > > ... > >> Also I¹m not sure if the ICE part is fully specified. In your >> previously >> mail you wrote >> >> "As far as TCP/DTLS/SCTP transport tag is concerned, please note that >> ICE >> end points are supposed to send a re-INVITE after nomination process >> is >> completed with the selected candidate address in the m= line. So, if >> tcp >> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP >> transport tag in the m= line. Also, any offers/answers after the ICE >> nomination is complete, are supposed to send the currently selected >> candidate in the m= line, which will also be TCP/DTLS/SCTP in case >> tcp >> candidate is selected.³ >> >> From what I understood from ekr, you might not in any case send an >> re-invite; but maybe I understood this wrongly. I guess that could >> also >> be further explained in the draft. > > Ekr was talking about the specific re-INVITE that is sent directly > after > ICE nomination. *Other* re-INVITEs can always be sent during the > session. > But, that is not specific to this draft. > > Regards, > > Christer From nobody Wed Mar 1 21:25: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 C2956129499 for ; Wed, 1 Mar 2017 21:25:07 -0800 (PST) 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=unavailable 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 g5uGgc8unC_n for ; Wed, 1 Mar 2017 21:25:05 -0800 (PST) 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 A8E07129678 for ; Wed, 1 Mar 2017 21:25:05 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id w189so18284889pfb.0 for ; Wed, 01 Mar 2017 21:25:05 -0800 (PST) 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=Rk2/IV4AAgXoSsEVkB76YrlmeO6EQQGCKfLgAzWTz+w=; b=hNXMujDM4HbVWSUwAV44SaBSgh0YPDxrEWkaaZEITSYQo1ElUZDR7MYCVDjWmM7G6E oFPMAvI8HlMaFoUbx/DAshDESLBWou5vfYsl6Nz6nFkbD8Y4mih99KhRL7w0gnTuI6xA Ari3YhGFPbXg5NyYxQKgZRarXHMP/wssOb2Os= 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=Rk2/IV4AAgXoSsEVkB76YrlmeO6EQQGCKfLgAzWTz+w=; b=MDqvyodJGqdtM3NhbFrHvDYUg0+BtgLCqy6uwH7Ip6+vczw5E/2LMrwahn5V2C7CrD eH300MnisDhKm+UQpQa/YOgIPK778u1mtLzmYpHgrpyyg+/UeAumZ1DKZLbEzBQJ5RGJ EytHH1Rf/CmDiqQ1g6LuCvUJeAWDG1Mxb5RfZLi+xJe6aN4BlbhBk2n/w7vNu4DPfn4s TZmZ2QtJs2OuZYgzAItLz/BjnjxL/tGqmsisdX2A0wqKvrRyfxYkdILlHL8IE+AMzbbV ir6ctk+n6mrCpF26hb+ZiEunMgshdCX/0NHs/d5I3MhlPQtLYJBBY5Ij4F6oYLkZu0XF k2zQ== X-Gm-Message-State: AMke39kEqh+wYkzu+ptzVa62XntBWXQyQCMRQbk/KLKyuCKaSrp798yA26vJuUYKanlR2w== X-Received: by 10.84.229.2 with SMTP id b2mr15162521plk.154.1488432305149; Wed, 01 Mar 2017 21:25:05 -0800 (PST) Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com. [209.85.192.175]) by smtp.gmail.com with ESMTPSA id o24sm13795149pfj.78.2017.03.01.21.25.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 21:25:03 -0800 (PST) Received: by mail-pf0-f175.google.com with SMTP id b5so11276636pfa.1; Wed, 01 Mar 2017 21:25:02 -0800 (PST) X-Received: by 10.99.138.202 with SMTP id y193mr13240719pgd.60.1488432302759; Wed, 01 Mar 2017 21:25:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.161.144 with HTTP; Wed, 1 Mar 2017 21:25:02 -0800 (PST) In-Reply-To: <6366ADF1-E3E4-4C91-8579-85246D3E3714@nostrum.com> References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> <6366ADF1-E3E4-4C91-8579-85246D3E3714@nostrum.com> From: Roman Shpount Date: Thu, 2 Mar 2017 00:25:02 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c03aefaadc4ac0549b8a6b2 Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , Christer Holmberg , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-mmusic-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Mar 2017 05:25:08 -0000 --94eb2c03aefaadc4ac0549b8a6b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ben, I have submitted the pull request to address these comments: https://github.com/cdh4u/draft-sctp-sdp/pull/11 I hope that after Christer reviews and merges the pull request, we should have the latest set of comments addressed. If we need more information about framing, I believe it should go into TCP/DTLS related draft, since all that draft-sctp-sdp is doing is reusing the same framing for exactly the same reasons. Regards, _____________ Roman Shpount On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell wrote: > Hi all, > > It seems like this conversation has not completed. What do we need to get > to closure? > > A few thoughts of my own: > > - I'm not adverse to making non-ICE implementors look at the ICE specs fo= r > framing information, as long as the citations are precise enough that the= y > don't need to read the entirety of ICE. (And the information is really > there.) > > - I am adverse to repeating normative text. I'm okay with adding > informational text about non-ICE usage, as long as it is general enough t= o > avoid confusion about where the authoritative text resides. > > - If people think that ICE is not sufficiently specified, we can work on > that. But I don't think the burden of doing that belongs to this draft. > > - The draft is in fact IESG approved in its current state. Material > changes should be kept to the minimum. > > > On 27 Feb 2017, at 7:06, Christer Holmberg wrote: > > Hi, >> >> ... >> >> Also I=C2=B9m not sure if the ICE part is fully specified. In your previ= ously >>> mail you wrote >>> >>> "As far as TCP/DTLS/SCTP transport tag is concerned, please note that I= CE >>> end points are supposed to send a re-INVITE after nomination process is >>> completed with the selected candidate address in the m=3D line. So, if = tcp >>> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP >>> transport tag in the m=3D line. Also, any offers/answers after the ICE >>> nomination is complete, are supposed to send the currently selected >>> candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tc= p >>> candidate is selected.=C2=B3 >>> >>> From what I understood from ekr, you might not in any case send an >>> re-invite; but maybe I understood this wrongly. I guess that could also >>> be further explained in the draft. >>> >> >> Ekr was talking about the specific re-INVITE that is sent directly after >> ICE nomination. *Other* re-INVITEs can always be sent during the session= . >> But, that is not specific to this draft. >> >> Regards, >> >> Christer >> > --94eb2c03aefaadc4ac0549b8a6b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ben,

I have submitted the pull request = to address these comments:=C2=A0https://github.com/cdh4u/draft-sctp-sdp/pull/11
<= div>
I hope that after Christer reviews and merges the pull r= equest, we should have the latest set of comments addressed.

=
If we need more information about framing, I believe it should g= o into TCP/DTLS related draft, since all that draft-sctp-sdp is doing is re= using the same framing for exactly the same reasons.

Regards,

___________= __
Roman Shpount

On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell= <ben@nostrum.com> wrote:
Hi= all,

It seems like this conversation has not completed. What do we need to get t= o closure?

A few thoughts of my own:

- I'm not adverse to making non-ICE implementors look at the ICE specs = for framing information, as long as the citations are precise enough that t= hey don't need to read the entirety of ICE. (And the information is rea= lly there.)

- I am adverse to repeating normative text. I'm okay with adding inform= ational text about non-ICE usage, as long as it is general enough to avoid = confusion about where the authoritative text resides.

- If people think that ICE is not sufficiently specified, we can work on th= at. But I don't think the burden of doing that belongs to this draft.
- The draft is in fact IESG approved in its current state. Material changes= should be kept to the minimum.


On 27 Feb 2017, at 7:06, Christer Holmberg wrote:

Hi,

...

Also I=C2=B9m not sure if the ICE part is fully specified. In your previous= ly
mail you wrote

"As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE
end points are supposed to send a re-INVITE after nomination process is
completed with the selected candidate address in the m=3D line. So, if tcp<= br> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP
transport tag in the m=3D line. Also, any offers/answers after the ICE
nomination is complete, are supposed to send the currently selected
candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.=C2=B3

>From what I understood from ekr, you might not in any case send an
re-invite; but maybe I understood this wrongly. I guess that could also
be further explained in the draft.

Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft.

Regards,

Christer

--94eb2c03aefaadc4ac0549b8a6b2-- From nobody Thu Mar 2 02:28: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 3C5471294C6; Thu, 2 Mar 2017 02:28:26 -0800 (PST) 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 hT7lRQtMK0pK; Thu, 2 Mar 2017 02:28:24 -0800 (PST) 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 A1879129473; Thu, 2 Mar 2017 02:28:23 -0800 (PST) X-AuditID: c1b4fb3a-6f7ff70000007c1e-e8-58b7f3c4dd90 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 29.18.31774.4C3F7B85; Thu, 2 Mar 2017 11:28:21 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Thu, 2 Mar 2017 11:28:20 +0100 From: Christer Holmberg To: Roman Shpount , Ben Campbell Thread-Topic: =?windows-1254?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-mmusic-sctp-sd?= =?windows-1254?Q?p-23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAAAH3gIAAE4kggAAVhACABDfnAIAAQksAgAAt4QCAAR3EAIAAFWGAgAtEKQCAA+rWgIAAKSkAgAB2+4A= Date: Thu, 2 Mar 2017 10:28:20 +0000 Message-ID: References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> <6366ADF1-E3E4-4C91-8579-85246D3E3714@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.1.161129 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D4DDC0BE18935christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUyM2K7me7Rz9sjDLadU7WY33ma3eLVuvnM Fiten2O3eH9B12LGn4nMFi+uf2S2OL9zPZPF1OWPWSyuP93F4sDpMeX3RlaPJUt+Mnm0fFzI 6jFr5xMWj8mP25g9tv79yxbAFsVlk5Kak1mWWqRvl8CV8f/bc7aC9/4V/6cJNzDOdeli5OSQ EDCRWLXsEHsXIxeHkMA6RolvT/YwQziLGCVurrjG0sXIwcEmYCHR/U8bpEFEwEdi/btWFpAa ZoFdTBJXvtwF6xYWaGKU2LLyEVi3iEAzo8S6b3vZIVrmMUp8WFoGYrMIqEicW32WGcTmFbCW uHbhKCvEug0cEuuajrGDrOMUCJT4fZQFpIZRQEzi+6k1TCA2s4C4xK0n85kg7haQWLLnPDOE LSrx8vE/VhBbVEBPYvnzNVBxRYn2pw2MEL0JEit//WSC2CsocXLmE5YJjKKzkIydhaRsFpIy iLiBxJFzN1khbG2JZQtfM0PY+hLzFmyAqrGWmNA6E0XNAkaOVYyixanFxbnpRkZ6qUWZycXF +Xl6eaklmxiBcX9wy2+rHYwHnzseYhTgYFTi4TWQ2h4hxJpYVlyZe4hRgoNZSYTXAJg0hHhT EiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamDM2iR2v0Zw3dYm sdf5KlO3Jn452Rx9/cLmZ2d4O26d9NqS+nJ1q+nTgnS9q1dbpie7iyQJnl05K71czfGiK49r /zb32nuflu77X3h5scxLD5ZAq9UreyMutPkd3rt08dNDU/vtZJXn+xaZXu2sirjauMz9WK+p 3WrZAM/mKZ/rC6tEQhme65sqsRRnJBpqMRcVJwIAh9r+0/cCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?cp1254?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ietf-m?= =?cp1254?q?music-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Mar 2017 10:28:26 -0000 --_000_D4DDC0BE18935christerholmbergericssoncom_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable Hi, There may be some minor editorial nits, but in general I am ok with the pul= l request. Regards, Christer From: Roman Shpount > Date: Thursday 2 March 2017 at 07:25 To: Ben Campbell > Cc: Christer Holmberg >, Mirja Kuehlewind >, "mmusic-chairs@ietf.org" >, Eric Rescorla >, "mmusic@ietf.org" >, Flemming Andreasen >, "iesg@ietf.org" >, "draft-ietf-mmusic-sctp-sdp@ietf.org" > Subject: Re: Mirja K=FChlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: = (with DISCUSS) Ben, I have submitted the pull request to address these comments: https://github= .com/cdh4u/draft-sctp-sdp/pull/11 I hope that after Christer reviews and merges the pull request, we should h= ave the latest set of comments addressed. If we need more information about framing, I believe it should go into TCP/= DTLS related draft, since all that draft-sctp-sdp is doing is reusing the s= ame framing for exactly the same reasons. Regards, _____________ Roman Shpount On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell > wrote: Hi all, It seems like this conversation has not completed. What do we need to get t= o closure? A few thoughts of my own: - I'm not adverse to making non-ICE implementors look at the ICE specs for = framing information, as long as the citations are precise enough that they = don't need to read the entirety of ICE. (And the information is really ther= e.) - I am adverse to repeating normative text. I'm okay with adding informatio= nal text about non-ICE usage, as long as it is general enough to avoid conf= usion about where the authoritative text resides. - If people think that ICE is not sufficiently specified, we can work on th= at. But I don't think the burden of doing that belongs to this draft. - The draft is in fact IESG approved in its current state. Material changes= should be kept to the minimum. On 27 Feb 2017, at 7:06, Christer Holmberg wrote: Hi, ... Also I=B9m not sure if the ICE part is fully specified. In your previously mail you wrote "As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m=3D line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m=3D line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.=B3 >From what I understood from ekr, you might not in any case send an re-invite; but maybe I understood this wrongly. I guess that could also be further explained in the draft. Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft. Regards, Christer --_000_D4DDC0BE18935christerholmbergericssoncom_ Content-Type: text/html; charset="windows-1254" Content-ID: <486FED4BCBFDB941AF6AC5F948B1C511@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

There may be some minor editorial nits, but in general I am ok with th= e pull request.

Regards,

Christer

From: Roman Shpount <rshpount@turbobridge.com>
Date: Thursday 2 March 2017 at 07:2= 5
To: Ben Campbell <ben@nostrum.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Mirja Kuehlewind <ietf@ku= ehlewind.net>, "mmusi= c-chairs@ietf.org" <mmusic-chairs@ietf.org&g= t;, Eric Rescorla <ekr@rtfm.com>,= "mmusic@ietf.org" <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>, &quo= t;iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmus= ic-sctp-sdp@ietf.org>
Subject: Re: Mirja K=FChlewind's Di= scuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

Ben,

I have submitted the pull request to address these comments: https://github.com/= cdh4u/draft-sctp-sdp/pull/11

I hope that after Christer reviews and merges the pull request, we sho= uld have the latest set of comments addressed.

If we need more information about framing, I believe it should go into= TCP/DTLS related draft, since all that draft-sctp-sdp is doing is reusing = the same framing for exactly the same reasons.

Regards,

_________= ____
Roman Shpount

On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell <ben@nostrum.com> wrote:
Hi all,

It seems like this conversation has not completed. What do we need to get t= o closure?

A few thoughts of my own:

- I'm not adverse to making non-ICE implementors look at the ICE specs for = framing information, as long as the citations are precise enough that they = don't need to read the entirety of ICE. (And the information is really ther= e.)

- I am adverse to repeating normative text. I'm okay with adding informatio= nal text about non-ICE usage, as long as it is general enough to avoid conf= usion about where the authoritative text resides.

- If people think that ICE is not sufficiently specified, we can work on th= at. But I don't think the burden of doing that belongs to this draft.

- The draft is in fact IESG approved in its current state. Material changes= should be kept to the minimum.


On 27 Feb 2017, at 7:06, Christer Holmberg wrote:

Hi,

...

Also I=B9m not sure if the ICE part is fully specified. In your previously<= br> mail you wrote

"As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE
end points are supposed to send a re-INVITE after nomination process is
completed with the selected candidate address in the m=3D line. So, if tcp<= br> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP
transport tag in the m=3D line. Also, any offers/answers after the ICE
nomination is complete, are supposed to send the currently selected
candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.=B3

>From what I understood from ekr, you might not in any case send an
re-invite; but maybe I understood this wrongly. I guess that could also
be further explained in the draft.

Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft.

Regards,

Christer

 --_000_D4DDC0BE18935christerholmbergericssoncom_-- From nobody Thu Mar 2 04:47: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 8E3BD120727; Thu, 2 Mar 2017 04:47:21 -0800 (PST) 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 p4_wawRKcma1; Thu, 2 Mar 2017 04:47:20 -0800 (PST) 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 B3DBE1299EB; Thu, 2 Mar 2017 04:47:19 -0800 (PST) X-AuditID: c1b4fb30-677ff70000001a00-e6-58b814542ba4 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 4D.8B.06656.45418B85; Thu, 2 Mar 2017 13:47:17 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Thu, 2 Mar 2017 13:47:16 +0100 From: Christer Holmberg To: "Cullen Jennings (fluffy)" , Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSfaJ5jrr91gBvrE2+PKFOpdD0GaFojxEAgAF+gQCAF67hgA== Date: Thu, 2 Mar 2017 12:47:16 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.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.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7BCE6202729D6841BFE781B4F0359B05@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7rm6oyI4Igw3LtCymz3rHZjG/Yx2b RcdkNoupyx+zWKz9187uwOox5fdGVo8lS34yeXy5/JktgDmKyyYlNSezLLVI3y6BK6O1axpr wUz9ipZZx5kaGBerdjFyckgImEjsur2BsYuRi0NIYB2jxNarqxlBEkICixglvh6M7WLk4GAT sJDo/qcNEhYRSJdof/CIGcRmFuhgkri0QgHEFhaoljgway8jRE2NxJrVV1ghbCeJ8/sns4HY LAIqEo+mfWYHsXkFrCW6/t6H2juRSWLv7BVgCU4BW4lV96cwgdiMAmIS30+tYYJYJi5x68l8 JoijBSSW7DnPDGGLSrx8/A9smaiAnsTy52ug4koSPzZcYoHo1ZO4MXUKG4RtLXH//AWoB7Ql li18zQxxkKDEyZlPWCYwis9Csm4WkvZZSNpnIWmfhaR9ASPrKkbR4tTipNx0IyO91KLM5OLi /Dy9vNSSTYzAqDy45bfBDsaXzx0PMQpwMCrx8BpIbY8QYk0sK67MPcQowcGsJMKbxb8jQog3 JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGHFaPGd3X/kfP 3RDw5N2cC3FBfEILT916/ZG/JMrsQ8VNY9Y/lf9UxV/FaDlWVrzexXSUwZqtVbw+aGt2eGwJ Z9GxGT+f6lYu/SCWVz9r3peOQCVeI72vr3cyr89ZMcnRsLVSSSslsf5dM2sLw2HGd9sC3h4S itp12UjuarjCktct4abVtaeVWIozEg21mIuKEwG7FenGxgIAAA== Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Mar 2017 12:47:21 -0000 Hi, Where are we on this? I see Cullen=B9s pull requests, but I don=B9t think think there are many agreements. Or? Regards, Christer On 15/02/17 15:09, "Cullen Jennings (fluffy)" wrote: > >To try and help get you text merged in, I separated your text up into a >bunch of PRs so that the diffs were all clear and each PR tried to deal >with one issue. There are all in github now and commenting on theses >would probably be the easies way to get to some combined text. > > >> On Feb 14, 2017, at 7:20 AM, Magnus Westerlund >> wrote: >>=20 >> Hi, >>=20 >> Thanks for the feedback. Sorry for my delay in responding, a cold have >> kept from work. >>=20 >> Den 2017-02-02 kl. 23:19, skrev Cullen Jennings (fluffy): >>>=20 >>> So I much prefer the current text and think there are a bunch of >>> problems with this text. If we actually had emails explaining what >>> problems in the current text this was trying to fix, with individual >>> PRs for those, this would be much easier to resolve each of them and >>> get them fixed. >>>=20 >>> 1) we have been trying to avoid the use of "RTP session" as it has >>> been very unclear to implementors what it is. I think this would be >>> better if we could rephrase to not use that >>=20 >> Okay, but the RTP session is very easy to make clear in the context in >> of BUNDLE, where this text is intended to be. I can improve that. >>=20 >>>=20 >>> 2) both the proposed and current text seem lacking in dealing with >>> multiple bundle groups >>=20 >> Okay, that can be fixed by clarifying that each bundle group results in >> its own RTP session, thus the procedures in this is per bundle group. >>=20 >>>=20 >>> 3) Stats are typically maintained by things after the packet is >>> routed - not before. >>=20 >> So this comes a question of ones view of RTP stack and the question of >> layering. And this is exactly why I think the current text is >> problematic. It takes one very particular view, why I attempted to be >> much more neutral on which order things happens. There are a number of >> functions that are in the RTP protocol layer, not in the higher layers. >> There are however some things, like XR VoIP metrcis that are metrics in >> the higher layers. So, yes this is not clear cut. I think ones view of >> this depends on if one have a very integrated RTP implementation, then >> what you say makes sense, but if one has a very layered and modularized >> design, then my viewpoint makes more sense. >>=20 >> From my perspective the most important thing here is that this text if >> it contains any RFC 2119 words can't prevent some possible >> implementation choices of the RTP stack. >>=20 >>>=20 >>> 4) Need to explain how the SDES in compound RTCP causes updates >>>=20 >>=20 >> I can attempt to clarify this. However, there is a potential issue here >> in that some implementations may not be able to force the receiver to >> process the content of the SDES RTCP packet prior to some or even all >> the other RTCP packets in a compound packet. >>=20 >> What in the current text: >>=20 >> On reception of any compound RTCP packet prior to dispatching the >> received information and data, if there is an RTCP SDES packet >> included that SHOULD be processed first. If that SDES packet >> contains SDES MID entries, this can results in updates and additions >> to the RTP stream to "m=3D" line mapping table. Thus each of the SDE= S >> MID items are processed and the current table entries are checked if >> the corresponding MID value matches the current RTP stream to "m=3D" >> line mapping, else the entry is updated. If there is no RTP stream >> to "m=3D" line table mapping entry for the received SDES item's SSRC, >> such an entry is created. Note, that in the process of updating the >> table entries, update flap suppression as discussed in Section 4.2.6 >> of [RFC7941] should be considered. >>=20 >> Is insufficient in that regards. Is it only the placement prior to the >> individual RTCP packet types that is the issue? Should with the >> exception of the first sentence be moved under the SDES text? >>=20 >>> 5) given this removes the outgoing SSRC table, not clear how it >>> routes RTCP reports. I think this needs to be clarified. >>>=20 >>=20 >> Okay, I think I understand that. I have an implicit assumption that the >> implementation knows how its local (outgoing) RTP Streams are related to >> the media sources and thus the related RTPsender. I can update the text >> to address this. >>=20 >>> 6) I don't think most implementers are going to have a clue what to >>> do for the "Third Party Targeted Reports or Feedback" section >>>=20 >>=20 >> I can understand that, but I think it is important to call out that this >> bucket do exist, and if you don't know what to do I think it is fine to >> ignore these. >>=20 >>> I will try and take your PR and break it up into some bit size pieces >>> so we can try and see if we can get the easy ones out of the way and >>> focus on the parts that are key changes. >>>=20 >>=20 >> Ok, I have seen that you generated a lot of individual issues, I will >>attempt to look through them and comment if there are things that was >>unintentional or where I have additional aspects to add. >>=20 >> I intend to update my PR based on the feedback I received. >>=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >>=20 > From nobody Thu Mar 2 13:41: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 B66BD129686 for ; Thu, 2 Mar 2017 13:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 9IytVF5d775c for ; Thu, 2 Mar 2017 13:41:14 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 27219129684 for ; Thu, 2 Mar 2017 13:41:14 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id u108so61866161wrb.3 for ; Thu, 02 Mar 2017 13:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rtAMEZgh9sErb6urvGoKoVO84rnSJFS67MdeAbgBrDc=; b=NrQRyBoKo5WIEItmMqJ5azPqn7Ex5rfcQM+s17veBQX3qP53YZow0CA5rR2sKQ/n5p JkJiQkxg6ZLCzvuNZySXHjoXDE3cWfMHeNLrYPuBf0V8jG0G9aAMBeoPA4asr7Ix2lhC HkTFxDHrcJnNT7ECtVrAg6Zb6Iu9A+yl2Z6si8m7NZOIilw3rfigjHKIEzAMSd0RdvOe Ns7ETguinZKtnpvJZU2eyhDtDc8P/WhPziWhSinAXqbW60fphxqxYymwGLUYY6lCBEYN b6jFlT2PRDNnU9ObxRQGBJwGpEa05fZn/r+BjcmMLMEpwTgF5C+g3iPzPqFnq25t5jFn +y+Q== 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=rtAMEZgh9sErb6urvGoKoVO84rnSJFS67MdeAbgBrDc=; b=pxbhQMvOfp0Yg1Egd5hTkdn2Ehx8gTaA8tMGVLWb7dLc+rwA3Ft7bytI0f4F72v/JG wqjYeCCFW8g46Vj89T+p+QN5wUOPapeb/2bwh5rMAagiJa08ccjLMC4uilBt+xDuY+S5 vvRzXJtBhRh68Lucg0kBFjUIpzpxihiDU3wHkHY/owegYO9SEtyLepMMtRQLDnIPGR36 mDuZM+FmtwfTpPTX/wmyeiYb7nu6RSITwrX+1nlOngIb+KO+5jonYjXNR2QfKDXrsS2N umOJFVzyLX/A/yFmRhLfzW4J01/3pzVgirTfEKk9/rPSqeuGIly/LGuuZyzxIdMiivIJ FnXQ== X-Gm-Message-State: AMke39ma/Y7tkCWhjYfSmDnQc8j/Y2Q8qR75+QkOloLjgSbGoJc1N+Z3E8q9WQasiRcidlwYPHIbvsFXU+iy6w== X-Received: by 10.223.178.9 with SMTP id u9mr13254566wra.121.1488490872669; Thu, 02 Mar 2017 13:41:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Thu, 2 Mar 2017 13:40:52 -0800 (PST) In-Reply-To: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> References: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 2 Mar 2017 22:40:52 +0100 Message-ID: To: Flemming Andreasen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: mmusic , draft-ietf-mmusic-sdp-simulcast@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Mar 2017 21:41:16 -0000 2017-02-09 0:09 GMT+01:00 Flemming Andreasen : > This is to announce a 2 week WGLC on the draft: > > https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-07.txt Hi, the draft shows as example: a=3Drid:1 pt=3D97 send a=3Drid:2 pt=3D98 send a=3Drid:3 pt=3D97 recv but according to https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 it seems that "direction" (send/recv) should be placed *before* "pt=3Dxx": a=3Drid: [pt=3D;]=3D... The ABNF grammar confirms this: https://tools.ietf.org/html/draft-ietf-mmusic-rid-09#section-10 So may be the example SDPs in draft-ietf-mmusic-sdp-simulcast-07 are wrong? --=20 I=C3=B1aki Baz Castillo From nobody Thu Mar 2 13:44: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 ABB8012968F for ; Thu, 2 Mar 2017 13:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 NWArv4PhnCNI for ; Thu, 2 Mar 2017 13:44:19 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 E175D12968C for ; Thu, 2 Mar 2017 13:44:18 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id g10so61897568wrg.2 for ; Thu, 02 Mar 2017 13:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ofatz7RB8NkpGWy3lbLGrq5oqQy/iI6vBSlWVESxsMo=; b=MgCc0X2Z0Hwv7mEJf4dwfxJeTPpdb5TjXo8pZgm+OEDDTmJRQEBvqSczYqyZUL4swR sXiZylYCxQs8pLWU+rwGS2w0KeBNh7PGQUPyr4kil/J5drl0Sm5KvAmxvYP4Vt8u1eqS l8ud2e/fLDaM+BJc4LbU1S4RlIxIi/jgZw5dJqVN5xWIVqp6jxLFfTuqN/txlSVJTyt0 2/j+Rxgy/HRAxSOYfGZFxrlGvv98ihv+O0Tjud6OO6w2HEmXRn/TFbn3ZLwZ+n2IF7JQ rCVAGImkXAHX2ZXApHu5oL+D+1VoS3m0y8yShnQgsNYmM+ANCPFleVnEH1fsOtKUuxmC eJCQ== 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=Ofatz7RB8NkpGWy3lbLGrq5oqQy/iI6vBSlWVESxsMo=; b=JltgC7nEsKTuy3BmTh+hCGE66nUO6hVLB6Je9nld9v0LIU/mIJwTN0H3tAuqkMFXWR SLRsfMx2NG8eEAeLuwIhOfJAGDaERLA9kLvSRyYrULl5rQS6FWZmcuaqN+vwh1g7Lu0b 7myRyAFtG8Md9fz63mCH2T7XNvD/rkecdoixpA+CQFRJ4BkUdHl8JTJLXnv3CURsuibG QQlR5FWYv6yleqrCkhCTA401Rn3BRIrOcx/RhN1j/ceEC/15Q5727sNxb/fP4cDdDXV2 nQT0i+9DgZNDCAxqD1bDkvrDzjPk8xYUJ0f/SLb3qZRyHGbVIDLaNPdUDT7LPvD1ZZci D5og== X-Gm-Message-State: AMke39kr03/mBNGO3AN9nsUubVm9uhydlJ70j5jSc6tEtPZ6NgWcpSZIXp3SiH5i6Z6LRtcqVz2Oor5SkDu4Fg== X-Received: by 10.223.178.9 with SMTP id u9mr13262695wra.121.1488491057467; Thu, 02 Mar 2017 13:44:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.182.85 with HTTP; Thu, 2 Mar 2017 13:43:57 -0800 (PST) In-Reply-To: References: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 2 Mar 2017 22:43:57 +0100 Message-ID: To: Flemming Andreasen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: mmusic , draft-ietf-mmusic-sdp-simulcast@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Mar 2017 21:44:22 -0000 2017-03-02 22:40 GMT+01:00 I=C3=B1aki Baz Castillo : > but according to https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 > it seems that "direction" (send/recv) should be placed *before* > "pt=3Dxx": > > a=3Drid: [pt=3D;]=3D... In fact, pt=3Dxx seems to be yet another "param". --=20 I=C3=B1aki Baz Castillo From nobody Fri Mar 3 02:22:05 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 D13831294C7; Fri, 3 Mar 2017 02:22:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148853652185.10129.12189179066255487274.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 02:22:01 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-sip-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 10:22: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 of the IETF. Title : A Session Initiation Protocol (SIP) usage for Trickle ICE Authors : Emil Ivov Thomas Stach Enrico Marocco Christer Holmberg Filename : draft-ietf-mmusic-trickle-ice-sip-07.txt Pages : 38 Date : 2017-03-03 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-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 Fri Mar 3 02:30: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 5B78C1294C7 for ; Fri, 3 Mar 2017 02:30:18 -0800 (PST) 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 r9uayXWoHg1R for ; Fri, 3 Mar 2017 02:30:16 -0800 (PST) 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 8D46312947A for ; Fri, 3 Mar 2017 02:30:16 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id v186so11829500wmd.0 for ; Fri, 03 Mar 2017 02:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=dVQCalio1MhuvJx3d9AvGCQ+wazb6wVlbRiegz2KkMc=; b=MEErYO1QNAXf2fi87BKRXaueXJcWk6nW8b+RFT8beD9IgDnojYIFGycuAYR2LIg9zD A3OdIcn88SC1EClesnSjt3nhidKx8iN+eSZ2+sLjdt0Aj6p/jSJo+1kQe0mhMvlXDPie 3f4jsLlL1ncUvfyxnZ3fnPSegfd0KRHmHvVVp8/Hof79KL20OGxm44d/83XQ71KHvSXW CwTRMTytY/qQSfZKpi5aCnxPY2VyFMAiTCTXvXYLksGy8cCVbDfeiw2wLnOipp4dC4sH F03/18PP/KCiC4HxJYHCSr/o+LpNL2oKPRtfuYPw4h61VaNgcBhcqpXz89MTi8raGA2z jUUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dVQCalio1MhuvJx3d9AvGCQ+wazb6wVlbRiegz2KkMc=; b=RZsm5ZjU8V9Y4dgsFIr0iUCru5J/7QY4wNNql17lNiWy602wkrRN8AcKUruOnPxtJm M0xnQpwsOedIoFUFDXX3X4ma9oRcpi0QGhNHFB3Ril053bMKrMD/1zNiqGsVoEDmNRmf pBBxmQbmZPAsj110HP2U2qTM2RQ9F2OdCgEVnDbrJrPflCv+ptQ10xReiBEeQNL1QSwp WECO7xXwNEbQG+Lcuz25nXyP3Dvom92A4aJ5yDbS26Fg8NT3LRSgN3hymVVZAL1wvjDZ YjjRg4fEiPpmzWTFwkKlSthFMAJuk6pfH10P8B8GcEJ5MITk0CwlAxVGVEtVx0T0gG7S 74ug== X-Gm-Message-State: AMke39kFgL5qyHfqux+s7qCwRYKz83Xf2eL7rjFz6GmubxlBHCJNA5/318g/6rL5Ztbf5Q== X-Received: by 10.28.93.194 with SMTP id r185mr1251267wmb.47.1488537014865; Fri, 03 Mar 2017 02:30:14 -0800 (PST) Received: from [192.168.2.114] (dsl-linz7-19-68.utaonline.at. [81.189.19.68]) by smtp.googlemail.com with ESMTPSA id o2sm2469861wmb.28.2017.03.03.02.30.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 02:30:14 -0800 (PST) References: <148853652192.10129.6722900597539039991.idtracker@ietfa.amsl.com> To: MMUSIC From: Thomas Stach X-Forwarded-Message-Id: <148853652192.10129.6722900597539039991.idtracker@ietfa.amsl.com> Message-ID: <6fc87ffe-99e0-94ef-ae02-16dd166b8387@gmail.com> Date: Fri, 3 Mar 2017 11:30:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148853652192.10129.6722900597539039991.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 10:30:18 -0000 All, this version includes Changes from draft-ietf-mmusic-trickle-ice-sip-06 o editorial fixes o additional text on the content of the INFO messages. o recommendation on what to do if a previously sent candidate is unexpectedly missing in a subsequent INFO o terminology alignment with draft-ietf-ice-trickle-07 Comments welcome. I believe this is ready for WGLC, unless there are substantial changes in draft- ietf-ice-trickle in the ICE WG. Provide there are no substantial comments on this version of our draft, I propose to sync up with the ICE WG and do a WGLC of both drafts in parallel. Regards Thomas -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-07.txt Date: Fri, 03 Mar 2017 02:22:01 -0800 From: internet-drafts@ietf.org To: Christer Holmberg , Enrico Marocco , Thomas Stach , Emil Ivov A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-07.txt has been successfully submitted by Thomas Stach and posted to the IETF repository. Name: draft-ietf-mmusic-trickle-ice-sip Revision: 07 Title: A Session Initiation Protocol (SIP) usage for Trickle ICE Document date: 2017-03-03 Group: mmusic Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-07 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Fri Mar 3 05:24: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 F22EF12952D; Fri, 3 Mar 2017 05:24:39 -0800 (PST) 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 VSkrzuOhYgOe; Fri, 3 Mar 2017 05:24:33 -0800 (PST) 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 E2CEE129874; Fri, 3 Mar 2017 05:24:32 -0800 (PST) X-AuditID: c1b4fb30-a6b9198000001a00-e1-58b96e8e05d4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 40.76.06656.E8E69B85; Fri, 3 Mar 2017 14:24:30 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.319.2; Fri, 3 Mar 2017 14:24:17 +0100 From: Magnus Westerlund To: "mmusic (E-mail)" Message-ID: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> Date: Fri, 3 Mar 2017 14:24:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM2J7iG5f3s4IgxVTzSymLn/MYrH2Xzu7 A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyOluSCw5aVixbupWlgfG7dhcjJ4eEgInEsc/r2LoY uTiEBNYxSky9fIsdwlnGKLH9+womkCo2AQuJmz8a2UBsYQFbiVdrX4PZIgLqEq2b+1hBbGYg +87ic+wgNq+AvcSzvrksIDaLgIrEgc67YHFRgRiJvf33mSBqBCVOznwCVMMB1Gsv8WBrGcQY eYnmrbOZQWwhAW2JhqYO1gmMfLOQdMxC6JiFpGMBI/MqRtHi1OKk3HQjI73Uoszk4uL8PL28 1JJNjMDAOrjlt8EOxpfPHQ8xCnAwKvHwbsjeESHEmlhWXJl7iFGCg1lJhDdtL1CINyWxsiq1 KD++qDQntfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGxtZmFe19r6fk5qc06f01 r5gbHCijsfflIYuSst19n2P6NytqnJ5xxiS1Nz77x+/Xa6KW1b3Xcdl5Y8eZQz8nPiqauGBv t7BI9vU9KuxR286Uc5odDCnfP7lvqVxmouSi+jTdcJOJSvwrLhx9fdYyZOdB/QdarDtyT2yY xsf3PfJ2Y2rzG50LS5VYijMSDbWYi4oTAcZXZpgoAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: [MMUSIC] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 13:24:40 -0000 Hi, Last IETF meeting we had discussions regarding the security considerations for the MID RTP header extensions regarding the need for encrypting the RTP header. On Christer's request I have attempted to capture what I believed was the outcome of this discussion into a text proposal. So the intention of the text is to capture the security considerations, i.e. known risks and what we believe is necessary to mitigate these risks. The conclusion of the discussion was that encrypting the MID in RTP header extensions is not necessary, and thus we have a conflict with the requirements in RFC 7941. I have attempted to motivate and on that basis wavier this requirement for this particular RTP SDES header extension. This is captured in last paragraph of section 16. The risk of implementation tracking lead us into a discussion around a algorithm for generating MID Values. I have drafted a proposal for such an algorithm in a new Section 14.1 inserted prior to the existing one. I note that in RTCWeb WG we did discuss that the encryption wavier would be done in the security architecture. However, I believe in retrospect that not covering this in BUNDLE in a common fashion would be confusing and likely cause questions in regards to the requirements of RFC 7941 when BUNDLE is used in other context than WebRTC. So please review and provide feedback. I know Christer wants to close this issue. 14.1. Generating Identification-tags The identification-tag is exposed on the network layer due to the SDES item and RTP header extension defined below. As this exposes the identification-tag beyond contexts where it is normally exposed, i.e. signalling layer additional potential for implementation identification exists. To avoid such risks a RECOMMENDED to be used algorithm for how the identification-tag value is generated is specified below. Using this one will ensure that one can't identify which of the implementations using this algorithm it is. The algorithm is also designed to keep down the length of the MID SDES item to preserve the MTU in RTP packets. The value of the identification-tag for a particular media description is generated by first determining the unsigned integer index of the corresponding m= line in the SDP. The first m= line in the SDP gets index 0, then each subsequent m= line present in the SDP gets an index value one value higher the previous line. The index value is then encoded to create the identification-tag value. The encoding is done in following the algorithm. The integer reminder of a division by 64 of the index, i.e. MOD 64, is determined. The reminder is encoded into an UTF-8 (ASCII) character by looking up the character from the reminder using Table 1 in [RFC4648]. This character is added to the front of the output string. After that the index is updated to the result of the index divided by 64. If the index becomes 0, then conclude the encoding. If not, then go back and the step calculating the reminder. This algorithm is below described using pseudo code. # Initialization work-index = index # index is the index value to encode as unsigned integer output = "" # Output string # The below must be performed once to encode index=0 do { reminder = work-index MOD 64 next-char = TableLookup(reminder) output = concat(next-char,output) work-index = work-index / 64 } while (work-index >0) Examples of input and output: Input Output 0 A 1 B 42 q 56 4 63 / 64 BA 65 BB 256 EA 4095 // 16. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information flows over the network but only changes which addresses and ports that information is flowing on and thus has very little impact on the security of the RTP sessions. When the BUNDLE extension is used, a single set of security credentials might be used for all media streams specified by a BUNDLE group. When the BUNDLE extension is used, the number of SSRC values within a single RTP session increases, which increases the risk of SSRC collision. [RFC4568] describes how SSRC collision may weaken SRTP and SRTCP encryption in certain situations. The identfication-tag, when included in the RTP MID SDES item, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag MUST NOT contain any user related information. However, the implementation's method for generating identfication-tags could enable fingerprinting of the implementation making it vulnerable to targeted attacks. The identication-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduct from the RTP streams without the MID SDES header extensions. As the identification-tag is also used to route the media stream to the right application functionality it is also important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. At least to prevent third parties from modifying the identification-tag value. To avoid the security risks associated with tracking of implementations, there is RECOMMENDED algorithm for generating identification-tags in Section 14.1. "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] security consideration requires that when RTCP is confidentiality protected that any SDES RTP header extension carrying an SDES item, like the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 3 05:50: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 C2BA512954A for ; Fri, 3 Mar 2017 05:50:37 -0800 (PST) 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 KVxCi3Vpg0f9 for ; Fri, 3 Mar 2017 05:50:35 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF461294F5 for ; Fri, 3 Mar 2017 05:50:35 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id p77so80214247ywg.1 for ; Fri, 03 Mar 2017 05:50:35 -0800 (PST) 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=8/TsnpgZ1G/2Q/35JG20NwD5K0pL/mQOAp9YgiSB9ss=; b=gFfI07u9dmfZjI0/Cgo80wSr/MUqjmi7rTw0RJwv5fUtFO2sHcfnEYs7ZKuQPr1cT7 47kYCMybIhzmuu8K2MfNTehQgbhc1JUn7JWAc5RwXm1K4HI9TXUzfR2h29FaC2Djc6b6 NndLe/vOjXXG1aCwEq2iB9JS+HVhkNXPCy81PucQN5Ee5AFh6x52KsPfi6QZYr3iVNoN QN4bls3IC6bOLjVjub4FQaaKXWkP+LYhW94QNaQdR2JD3VuUzrPhofnFq0HW7tUshoPq nMJy/FEGiSTP8LrUo5Yv/ZA0aooAbYzJgOT9H5XrAHtHekHWCJQLvwmkNEYXhgwxW9lB epAQ== 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=8/TsnpgZ1G/2Q/35JG20NwD5K0pL/mQOAp9YgiSB9ss=; b=hYTgb/HPM0tGbCh0k1WT6CJ3cBHVYH9kCxhSu+PlApWpWMxF+hnhL816XIqY2EXNFF kIYLxdwYQ+TizukB0CSY+dgjqtCn2srB9ohMTUtCX2qHV9Ss4u+TJ+RupvuUNIEl9FMj Z+/CW0Q7IduYurcoWtYcrWLEkPAOo9G64oYITiD9KpmxaeqnxuuezNHNU2k6m9MIEzNf PBEsczt3bdpmxrj1+bzeUSrn9c7x2h6kbjI9M91cQepOxAmRw7O3ubbpPnscwYXvQOmK 6uZBTyM3J3fk17qBl3oMOiozsMUg/xJpqFkAGvFThO+7pKscWWUSnWhEBWu6JkBwmyIN 1QkQ== X-Gm-Message-State: AMke39lmmiSPnyr/nu5S5cFEjGGSDx8e7qLq54UydQxY0thwC+vUt2J3f6EmkRVd+n8jXSc2lb72pR/JFtm62Q== X-Received: by 10.37.171.66 with SMTP id u60mr1811257ybi.64.1488549034369; Fri, 03 Mar 2017 05:50:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 3 Mar 2017 05:49:53 -0800 (PST) In-Reply-To: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> From: Eric Rescorla Date: Fri, 3 Mar 2017 08:49:53 -0500 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c0c30f06cc1400549d3d42a Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 13:50:38 -0000 --94eb2c0c30f06cc1400549d3d42a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Last IETF meeting we had discussions regarding the security consideration= s > for the MID RTP header extensions regarding the need for encrypting the R= TP > header. On Christer's request I have attempted to capture what I believed > was the outcome of this discussion into a text proposal. > > So the intention of the text is to capture the security considerations, > i.e. known risks and what we believe is necessary to mitigate these risks= . > The conclusion of the discussion was that encrypting the MID in RTP heade= r > extensions is not necessary, and thus we have a conflict with the > requirements in RFC 7941. I have attempted to motivate and on that basis > wavier this requirement for this particular RTP SDES header extension. Th= is > is captured in last paragraph of section 16. > > The risk of implementation tracking lead us into a discussion around a > algorithm for generating MID Values. I have drafted a proposal for such a= n > algorithm in a new Section 14.1 inserted prior to the existing one. > > I note that in RTCWeb WG we did discuss that the encryption wavier would > be done in the security architecture. However, I believe in retrospect th= at > not covering this in BUNDLE in a common fashion would be confusing and > likely cause questions in regards to the requirements of RFC 7941 when > BUNDLE is used in other context than WebRTC. > > So please review and provide feedback. I know Christer wants to close thi= s > issue. > > > 14.1. Generating Identification-tags > > The identification-tag is exposed on the network layer due to the > SDES item and RTP header extension defined below. As this exposes > the identification-tag beyond contexts where it is normally exposed, > i.e. signalling layer additional potential for implementation > identification exists. To avoid such risks a RECOMMENDED to be used > algorithm for how the identification-tag value is generated is > specified below. Using this one will ensure that one can't identify > which of the implementations using this algorithm it is. If you mean which stack, I do not believe that this is actually that useful a design consideration. There are going to be a very large number of ways to fingerprint stacks. As the rest of the text seems predicated on that design objective, I do not think we should make this change. -Ekr The > algorithm is also designed to keep down the length of the MID SDES > item to preserve the MTU in RTP packets. > > The value of the identification-tag for a particular media > description is generated by first determining the unsigned integer > index of the corresponding m=3D line in the SDP. The first m=3D line = in > the SDP gets index 0, then each subsequent m=3D line present in the SD= P > gets an index value one value higher the previous line. The index > value is then encoded to create the identification-tag value. The > encoding is done in following the algorithm. The integer reminder of > a division by 64 of the index, i.e. MOD 64, is determined. The > reminder is encoded into an UTF-8 (ASCII) character by looking up the > character from the reminder using Table 1 in [RFC4648]. This > character is added to the front of the output string. After that the > index is updated to the result of the index divided by 64. If the > index becomes 0, then conclude the encoding. If not, then go back > and the step calculating the reminder. This algorithm is below > described using pseudo code. > > # Initialization > work-index =3D index > # index is the index value to encode as unsigned integer > output =3D "" # Output string > > # The below must be performed once to encode index=3D0 > do { > reminder =3D work-index MOD 64 > next-char =3D TableLookup(reminder) > output =3D concat(next-char,output) > work-index =3D work-index / 64 > } while (work-index >0) > > Examples of input and output: > > Input Output > 0 A > 1 B > 42 q > 56 4 > 63 / > 64 BA > 65 BB > 256 EA > 4095 // > This seems way over-prescriptive. > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information > flows over the network but only changes which addresses and ports > that information is flowing on and thus has very little impact on the > security of the RTP sessions. > > When the BUNDLE extension is used, a single set of security > credentials might be used for all media streams specified by a BUNDLE > group. > > When the BUNDLE extension is used, the number of SSRC values within a > single RTP session increases, which increases the risk of SSRC > collision. [RFC4568] describes how SSRC collision may weaken SRTP > and SRTCP encryption in certain situations. > > The identfication-tag, when included in the RTP MID SDES item, > independent of transport, RTCP SDES packet or RTP header extension, > can expose the value to parties beyond the signaling chain. > Therefore, the identification-tag MUST NOT contain any user related > information. However, the implementation's method for generating > identfication-tags could enable fingerprinting of the implementation > making it vulnerable to targeted attacks. The identication-tag is > exposed on the RTP stream level when included in the RTP header > extensions, however what it reveals of the RTP media stream structure > of the endpoint and application was already possible to deduct from > the RTP streams without the MID SDES header extensions. As the > identification-tag is also used to route the media stream to the > right application functionality it is also important that the value > received is the one intended by the sender, thus integrity and the > authenticity of the source are important to prevent denial of service > on the application. At least to prevent third parties from modifying > the identification-tag value. > > To avoid the security risks associated with tracking of > implementations, there is RECOMMENDED algorithm for generating > identification-tags in Section 14.1. "RTP Header Extension for the > RTP Control Protocol (RTCP) Source Description Items" [RFC7941] > security consideration requires that when RTCP is confidentiality > protected that any SDES RTP header extension carrying an SDES item, > like the MID RTP header extension, is also protected using > commensurate strength algorithms. However, assuming the above > requirements and recommendations are followed there are no known > significant security risks with leaving the MID RTP header extension > without confidentiality protection. Thus, the requirements in RFC > 7941 MAY be ignored for the MID RTP header extension. Security > mechanisms for RTP/RTCP are discussed in Options for Securing RTP > Sessions [RFC7201], for example SRTP [RFC3711] can provide the > necessary security functions of ensuring the integrity and source > authenticity. > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --94eb2c0c30f06cc1400549d3d42a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund <= ;magnus= .westerlund@ericsson.com> wrote:
Hi,

Last IETF meeting we had discussions regarding the security considerations = for the MID RTP header extensions regarding the need for encrypting the RTP= header. On Christer's request I have attempted to capture what I belie= ved was the outcome of this discussion into a text proposal.

So the intention of the text is to capture the security considerations, i.e= . known risks and what we believe is necessary to mitigate these risks. The= conclusion of the discussion was that encrypting the MID in RTP header ext= ensions is not necessary, and thus we have a conflict with the requirements= in RFC 7941. I have attempted to motivate and on that basis wavier this re= quirement for this particular RTP SDES header extension. This is captured i= n last paragraph of section 16.

The risk of implementation tracking lead us into a discussion around a algo= rithm for generating MID Values. I have drafted a proposal for such an algo= rithm in a new Section 14.1 inserted prior to the existing one.

I note that in RTCWeb WG we did discuss that the encryption wavier would be= done in the security architecture. However, I believe in retrospect that n= ot covering this in BUNDLE in a common fashion would be confusing and likel= y cause questions in regards to the requirements of RFC 7941 when BUNDLE is= used in other context than WebRTC.

So please review and provide feedback. I know Christer wants to close this = issue.


14.1.=C2=A0 Generating Identification-tags

=C2=A0 =C2=A0The identification-tag is exposed on the network layer due to = the
=C2=A0 =C2=A0SDES item and RTP header extension defined below.=C2=A0 As thi= s exposes
=C2=A0 =C2=A0the identification-tag beyond contexts where it is normally ex= posed,
=C2=A0 =C2=A0i.e.=C2=A0 signalling layer additional potential for implement= ation
=C2=A0 =C2=A0identification exists.=C2=A0 To avoid such risks a RECOMMENDED= to be used
=C2=A0 =C2=A0algorithm for how the identification-tag value is generated is=
=C2=A0 =C2=A0specified below.=C2=A0 Using this one will ensure that one can= 't identify
=C2=A0 =C2=A0which of the implementations using this algorithm it is.=C2=A0=

If you mean which stack, I do not believe = that this is actually that useful a design
consideration. There a= re going to be a very large number of ways to fingerprint
stacks.= As the rest of the text seems predicated on that design objective, I do
not think we should make this change.

-Ekr=




The
=C2=A0 =C2=A0algorithm is also designed to keep down the length of the MID = SDES
=C2=A0 =C2=A0item to preserve the MTU in RTP packets.

=C2=A0 =C2=A0The value of the identification-tag for a particular media
=C2=A0 =C2=A0description is generated by first determining the unsigned int= eger
=C2=A0 =C2=A0index of the corresponding m=3D line in the SDP.=C2=A0 The fir= st m=3D line in
=C2=A0 =C2=A0the SDP gets index 0, then each subsequent m=3D line present i= n the SDP
=C2=A0 =C2=A0gets an index value one value higher the previous line.=C2=A0 = The index
=C2=A0 =C2=A0value is then encoded to create the identification-tag value.= =C2=A0 The
=C2=A0 =C2=A0encoding is done in following the algorithm.=C2=A0 The integer= reminder of
=C2=A0 =C2=A0a division by 64 of the index, i.e. MOD 64, is determined.=C2= =A0 The
=C2=A0 =C2=A0reminder is encoded into an UTF-8 (ASCII) character by looking= up the
=C2=A0 =C2=A0character from the reminder using Table 1 in [RFC4648].=C2=A0 = This
=C2=A0 =C2=A0character is added to the front of the output string.=C2=A0 Af= ter that the
=C2=A0 =C2=A0index is updated to the result of the index divided by 64.=C2= =A0 If the
=C2=A0 =C2=A0index becomes 0, then conclude the encoding.=C2=A0 If not, the= n go back
=C2=A0 =C2=A0and the step calculating the reminder.=C2=A0 This algorithm is= below
=C2=A0 =C2=A0described using pseudo code.

=C2=A0 =C2=A0# Initialization
=C2=A0 =C2=A0work-index =3D index
=C2=A0 =C2=A0# index is the index value to encode as unsigned integer
=C2=A0 =C2=A0output =3D "" # Output string

=C2=A0 =C2=A0# The below must be performed once to encode index=3D0
=C2=A0 =C2=A0do {
=C2=A0 =C2=A0 =C2=A0 reminder =3D work-index MOD 64
=C2=A0 =C2=A0 =C2=A0 next-char =3D TableLookup(reminder)
=C2=A0 =C2=A0 =C2=A0 output =3D concat(next-char,output)
=C2=A0 =C2=A0 =C2=A0 work-index =3D work-index / 64
=C2=A0 =C2=A0} while (work-index >0)

=C2=A0 =C2=A0Examples of input and output:

=C2=A0 =C2=A0Input=C2=A0 =C2=A0 =C2=A0Output
=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A
=C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B
=C2=A0 =C2=A042=C2=A0 =C2=A0 =C2=A0 =C2=A0 q
=C2=A0 =C2=A056=C2=A0 =C2=A0 =C2=A0 =C2=A0 4
=C2=A0 =C2=A063=C2=A0 =C2=A0 =C2=A0 =C2=A0 /
=C2=A0 =C2=A064=C2=A0 =C2=A0 =C2=A0 =C2=A0 BA
=C2=A0 =C2=A065=C2=A0 =C2=A0 =C2=A0 =C2=A0 BB
=C2=A0 =C2=A0256=C2=A0 =C2=A0 =C2=A0 =C2=A0EA
=C2=A0 =C2=A04095=C2=A0 =C2=A0 =C2=A0 //

This seems way over-prescriptive.



16.=C2=A0 Security Considerations

=C2=A0 =C2=A0The security considerations defined in [RFC3264] and [RFC5888]= apply
=C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not change which in= formation
=C2=A0 =C2=A0flows over the network but only changes which addresses and po= rts
=C2=A0 =C2=A0that information is flowing on and thus has very little impact= on the
=C2=A0 =C2=A0security of the RTP sessions.

=C2=A0 =C2=A0When the BUNDLE extension is used, a single set of security =C2=A0 =C2=A0credentials might be used for all media streams specified by a= BUNDLE
=C2=A0 =C2=A0group.

=C2=A0 =C2=A0When the BUNDLE extension is used, the number of SSRC values w= ithin a
=C2=A0 =C2=A0single RTP session increases, which increases the risk of SSRC=
=C2=A0 =C2=A0collision.=C2=A0 [RFC4568] describes how SSRC collision may we= aken SRTP
=C2=A0 =C2=A0and SRTCP encryption in certain situations.

=C2=A0 =C2=A0The identfication-tag, when included in the RTP MID SDES item,=
=C2=A0 =C2=A0independent of transport, RTCP SDES packet or RTP header exten= sion,
=C2=A0 =C2=A0can expose the value to parties beyond the signaling chain. =C2=A0 =C2=A0Therefore, the identification-tag MUST NOT contain any user re= lated
=C2=A0 =C2=A0information.=C2=A0 However, the implementation's method fo= r generating
=C2=A0 =C2=A0identfication-tags could enable fingerprinting of the implemen= tation
=C2=A0 =C2=A0making it vulnerable to targeted attacks.=C2=A0 The identicati= on-tag is
=C2=A0 =C2=A0exposed on the RTP stream level when included in the RTP heade= r
=C2=A0 =C2=A0extensions, however what it reveals of the RTP media stream st= ructure
=C2=A0 =C2=A0of the endpoint and application was already possible to deduct= from
=C2=A0 =C2=A0the RTP streams without the MID SDES header extensions.=C2=A0 = As the
=C2=A0 =C2=A0identification-tag is also used to route the media stream to t= he
=C2=A0 =C2=A0right application functionality it is also important that the = value
=C2=A0 =C2=A0received is the one intended by the sender, thus integrity and= the
=C2=A0 =C2=A0authenticity of the source are important to prevent denial of = service
=C2=A0 =C2=A0on the application.=C2=A0 At least to prevent third parties fr= om modifying
=C2=A0 =C2=A0the identification-tag value.

=C2=A0 =C2=A0To avoid the security risks associated with tracking of
=C2=A0 =C2=A0implementations, there is RECOMMENDED algorithm for generating=
=C2=A0 =C2=A0identification-tags in Section 14.1.=C2=A0 "RTP Header Ex= tension for the
=C2=A0 =C2=A0RTP Control Protocol (RTCP) Source Description Items" [RF= C7941]
=C2=A0 =C2=A0security consideration requires that when RTCP is confidential= ity
=C2=A0 =C2=A0protected that any SDES RTP header extension carrying an SDES = item,
=C2=A0 =C2=A0like the MID RTP header extension, is also protected using
=C2=A0 =C2=A0commensurate strength algorithms.=C2=A0 However, assuming the = above
=C2=A0 =C2=A0requirements and recommendations are followed there are no kno= wn
=C2=A0 =C2=A0significant security risks with leaving the MID RTP header ext= ension
=C2=A0 =C2=A0without confidentiality protection.=C2=A0 Thus, the requiremen= ts in RFC
=C2=A0 =C2=A07941 MAY be ignored for the MID RTP header extension.=C2=A0 Se= curity
=C2=A0 =C2=A0mechanisms for RTP/RTCP are discussed in Options for Securing = RTP
=C2=A0 =C2=A0Sessions [RFC7201], for example SRTP [RFC3711] can provide the=
=C2=A0 =C2=A0necessary security functions of ensuring the integrity and sou= rce
=C2=A0 =C2=A0authenticity.



--

Magnus Westerlund

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

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

--94eb2c0c30f06cc1400549d3d42a-- From nobody Fri Mar 3 07:06: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 D1DCB1298AD; Fri, 3 Mar 2017 07:06:27 -0800 (PST) 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 Sq_5IsgzFrqM; Fri, 3 Mar 2017 07:06:26 -0800 (PST) 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 D829B1298AA; Fri, 3 Mar 2017 07:06:25 -0800 (PST) X-AuditID: c1b4fb3a-6f7ff70000007c1e-27-58b9866e3d67 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 7A.F6.31774.E6689B85; Fri, 3 Mar 2017 16:06:23 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.319.2; Fri, 3 Mar 2017 16:06:21 +0100 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> From: Magnus Westerlund Message-ID: <0827af95-b755-9730-6605-5146967760e7@ericsson.com> Date: Fri, 3 Mar 2017 16:06:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2K7k25+284Ig+Vb9CxWvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8bkyy+YC9ZLV/z9+YOlgfG/SBcj J4eEgInExLYjbF2MXBxCAusYJRYd/MEM4SxjlDhyaxEbSJWwgJdE27aJzCC2iICCxK8/J1gg itoYJW7uugRUxMHBLOAjsfBZIkgNm4CFxM0fjWBhXgF7ia9zM0DCLAIqEiePtICNERWIkdjb f58JxOYVEJQ4OfMJC4jNKRAo8fZTL1gNM9CYmfPPM0LY8hLNW2eDxYUEtCUamjpYJzAKzELS PgtJyywkLQsYmVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBAbowS2/rXYwHnzueIhRgINR iYd3Q/aOCCHWxLLiytxDjBIczEoivK2VOyOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8u JJCeWJKanZpakFoEk2Xi4JRqYJxof0cpTWP/pjknvsp1Lc1bl8Fq+1n/YsC8ScyrD66+tzfc o2zrgz9vdy/edtb0eNT0y49y9Ocof08vb7XWmZ53uO78j2/HfeN+c10viRMQaPyf+GTjr+tb 87/uUJvm91KqXnlShkJdwN3SJW52JdX3XmbfT9rpU+CcUP3rHt960ZJ175X+8c1XYinOSDTU Yi4qTgQA1cCpd0wCAAA= Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 15:06:28 -0000 Den 2017-03-03 kl. 14:49, skrev Eric Rescorla: > > > On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund > > > wrote: > > Hi, > > Last IETF meeting we had discussions regarding the security > considerations for the MID RTP header extensions regarding the need > for encrypting the RTP header. On Christer's request I have > attempted to capture what I believed was the outcome of this > discussion into a text proposal. > > So the intention of the text is to capture the security > considerations, i.e. known risks and what we believe is necessary to > mitigate these risks. The conclusion of the discussion was that > encrypting the MID in RTP header extensions is not necessary, and > thus we have a conflict with the requirements in RFC 7941. I have > attempted to motivate and on that basis wavier this requirement for > this particular RTP SDES header extension. This is captured in last > paragraph of section 16. > > The risk of implementation tracking lead us into a discussion around > a algorithm for generating MID Values. I have drafted a proposal for > such an algorithm in a new Section 14.1 inserted prior to the > existing one. > > I note that in RTCWeb WG we did discuss that the encryption wavier > would be done in the security architecture. However, I believe in > retrospect that not covering this in BUNDLE in a common fashion > would be confusing and likely cause questions in regards to the > requirements of RFC 7941 when BUNDLE is used in other context than > WebRTC. > > So please review and provide feedback. I know Christer wants to > close this issue. > > > 14.1. Generating Identification-tags > > The identification-tag is exposed on the network layer due to the > SDES item and RTP header extension defined below. As this exposes > the identification-tag beyond contexts where it is normally exposed, > i.e. signalling layer additional potential for implementation > identification exists. To avoid such risks a RECOMMENDED to be used > algorithm for how the identification-tag value is generated is > specified below. Using this one will ensure that one can't identify > which of the implementations using this algorithm it is. > > > If you mean which stack, I do not believe that this is actually that > useful a design > consideration. There are going to be a very large number of ways to > fingerprint > stacks. As the rest of the text seems predicated on that design > objective, I do > not think we should make this change. > Okay, what is your view on Section 16, if we remove the first sentence of the last paragraph that references 14.1? We need to get the security considerations in BUNDLE into reasonable shape so that we actually can get BUNDLE published. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 3 07:57: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 3BCF01294F3 for ; Fri, 3 Mar 2017 07:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, 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 45joEMXZbgz8 for ; Fri, 3 Mar 2017 07:57:02 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 2D43B1294CC for ; Fri, 3 Mar 2017 07:57:02 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-10v.sys.comcast.net with SMTP id jpZBcRPcrILPAjpZlcZ6Ww; Fri, 03 Mar 2017 15:57:01 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id jpZjcXpOrVYHEjpZkcUPa0; Fri, 03 Mar 2017 15:57:01 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v23Fux0g018820; Fri, 3 Mar 2017 10:56:59 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v23FuwEO018817; Fri, 3 Mar 2017 10:56:58 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: =?utf-8?Q?I=C3=B1aki?= Baz Castillo In-Reply-To: (ibc@aliax.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 03 Mar 2017 10:56:58 -0500 Message-ID: <87mvd2fj5h.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfGiO8d2C0075bcc69qrQxOHldmqjIIcUimVswvUnPFfl0CR88cXiMXZd0FS9BxINKx/BKV2Vyrtq1/inWdWykujCMFtRmwkI+pfUcC1aHT5ORoxCdhm/ aQBrDVgfQlRjEoV1pFmG+T6gl/7IdyY6WS/ZcxLgqra4sy8VZrRs9GXQTL3AV9zh90Z6j4ILJc7LjARg83/HLkUq4vUSfkcgSe3TIz3zJx/tg81JoTOOUJrB LxaI9Ok93hnAixlxplLVPlzWdO2++80WTqJc8tyIh7M= Archived-At: Cc: fandreas@cisco.com, mmusic@ietf.org, draft-ietf-mmusic-sdp-simulcast@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 15:57:03 -0000 I=C3=B1aki Baz Castillo writes: >> but according to https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 >> it seems that "direction" (send/recv) should be placed *before* >> "pt=3Dxx": >> >> a=3Drid: [pt=3D;]=3D... > > In fact, pt=3Dxx seems to be yet another "param". That purported BNF is really bizarre, since it generates the clearly incorrect form: a=3Drid: =3D=3D A correct description is: a=3Drid: ( pt=3D | =3D= ) *( ; =3D ) The problem is that BNF doesn't allow you to directly specify what you want to say: (1) pt is like a parameter, but if it's present, it must be first, and (2) there must be at least one pt or restriction. And there's no simple construction for "a list of one or more X's separated by Y's". Dale From nobody Fri Mar 3 08:42: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 C91EC1298C8 for ; Fri, 3 Mar 2017 08:42:10 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 XMSJEHVgvC4j for ; Fri, 3 Mar 2017 08:42:09 -0800 (PST) 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 C9FAB1298AE for ; Fri, 3 Mar 2017 08:42:08 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id n11so19650143wma.1 for ; Fri, 03 Mar 2017 08:42:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WVwtafZXM9y0zyrWw2U/UItUl7k5GAnEXIKAg4dcb50=; b=a0pK0aPWLXXwq+u/YIHqL0E3fXe4bxaslcox+PIyoQ80NQSF659XyyGt+X3EyVQT9W s6sjKuDjPY29YGSMiDeqYU3jnQOJzNPAGBAMfVydSXEixBwGQ70g9VX/2nMvQWQRfLxr paeJyldSmuyWadkEiXFh3RFf/hf98SRdq/uU3+obpPY9oUWgM4a6Hh+o+UnsXJXyOAP4 zWhbNQZ2+Iuu+ptj+Ju+HC6tIvCeLjfrLot4Bw737UbLv2Sd7G9Gxk3d0BYP5cURXjsR TYYQjI1n5RHj2V+sxssPTRH8X+1lt/Sr0lLmXts5tML0t20xM/lGoHQIWy6Eoc3VKNkZ tWqA== 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=WVwtafZXM9y0zyrWw2U/UItUl7k5GAnEXIKAg4dcb50=; b=UC4dWukX7yZFCrlmoY8vI0CknEtruWN1TRML+ptn5wcNbwU2Bqd5lxT6A2KlQHaYdQ EqloZqj/PWhTkNFVgqc19563GaJw2KP9Hnq1x/WKGU3jcZF5+KadqLIn1wlrDO1kUIUL o0Ycu/legsHctcGK8e6TtrRErJrgZ1heQRhaZ3/6CoHlWOVSbekoFGBy3LOPVjdXA7QK 3mNw8LemHXHCs7fGZi1O9EfZCzH5L3ArYYjExjeDLvONJqf+RvLmqhKYhffmmTXN/cLX UEBfRY+hJz8cODGAD+WjJwW9T4Vf819IhhX36GJbgohRdY7zsaRzV3PLQHaF56eg1pj2 ddhQ== X-Gm-Message-State: AMke39mNEw7N8Y+uiYoaugMo5/AZysdGsOGYCCNbN4Sp5LrhZQ7Z9yVrXzWiqAyMyYy/gUq+sPEb6EaxOQ0Odw== X-Received: by 10.28.139.134 with SMTP id n128mr3992819wmd.125.1488559327297; Fri, 03 Mar 2017 08:42:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Fri, 3 Mar 2017 08:41:46 -0800 (PST) In-Reply-To: <87mvd2fj5h.fsf@hobgoblin.ariadne.com> References: <87mvd2fj5h.fsf@hobgoblin.ariadne.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 3 Mar 2017 17:41:46 +0100 Message-ID: To: "Dale R. Worley" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Flemming Andreasen , "mmusic@ietf.org" , draft-ietf-mmusic-sdp-simulcast@ietf.org Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 16:42:11 -0000 2017-03-03 16:56 GMT+01:00 Dale R. Worley : > That purported BNF is really bizarre, since it generates the clearly > incorrect form: > > a=3Drid: =3D=3D > > A correct description is: > > a=3Drid: ( pt=3D | =3D ) *( ; =3D ) > > The problem is that BNF doesn't allow you to directly specify what you > want to say: (1) pt is like a parameter, but if it's present, it must > be first, and (2) there must be at least one pt or restriction. And > there's no simple construction for "a list of one or more X's separated > by Y's". Understood. But, anyhow, the a=3Drid lines in draft-ietf-mmusic-sdp-simulcast-07 are wrong, right? --=20 I=C3=B1aki Baz Castillo From nobody Fri Mar 3 11:06:06 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 2989F129994 for ; Fri, 3 Mar 2017 11:06:05 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, 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 FkrrJajU33MF for ; Fri, 3 Mar 2017 11:06:04 -0800 (PST) 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 E19991295AE for ; Fri, 3 Mar 2017 11:06:03 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-12v.sys.comcast.net with SMTP id jsWhcHueyUZfBjsWhcp0Ku; Fri, 03 Mar 2017 19:06:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1488567963; bh=KZP6iKW2f0a+Snr7v4XUdYKhCP7HpTCGXgQlintw+CQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LDr1FY5VoIW3F+Euf0lH9AMXMvmDFuW1uZwJ9cMMTPJKb/53uxAqfvxw0bqgZ964q XHK74MDCbdqEKIJQHPTvVd9eRdw079nFvG2eQ706W+VKE4mLWjRD4Wq119KT/mTvzK cBwFp8rB5cWkaJdB1ZO+bx/ahuJxbpAKLOkzXKpso2Ma7i3o3BHzqaPwNe1r4ZrPVy 2jhTQTZHqsy5wD/q+CZ3ckDPhilLAYaGttJ7eEB/Fy5NsBF5YLgnLlfJm0HO6FW1WL n/huW2GxV+C6DGn+IdWXK2c1+pfkNVRLvltocoML3HLO0rjOXdEaCU/fhwbpvBkPqx e3OVHghyfYwDw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-18v.sys.comcast.net with SMTP id jsWgcgBm1YKLwjsWgcW0k7; Fri, 03 Mar 2017 19:06:03 +0000 To: mmusic@ietf.org References: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> From: Paul Kyzivat Message-ID: <4bb9cede-7f95-8a8e-5206-5139c5755e32@comcast.net> Date: Fri, 3 Mar 2017 14:06:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfHIiT1rxGThNuSsBlRbyLDGPwrBlC8KJa+5i1oBTeC2FUUt0fvCXPkpVAQZXHk9dNEoXYjuL0PHFmqXrZB7n/+wbjbg+ooutnJM1QbQRvLAE+5skr+w+ mjrLRnNPuL2qXFkf3MrdF4mpqKHpjO+Uep9isf11B1WUwMFsZRY1HrhCZEWoITLvznkft3up1Wb8XQ== Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 19:06:05 -0000 On 3/2/17 4:40 PM, Iñaki Baz Castillo wrote: > 2017-02-09 0:09 GMT+01:00 Flemming Andreasen : >> This is to announce a 2 week WGLC on the draft: >> >> https://www.ietf.org/id/draft-ietf-mmusic-sdp-simulcast-07.txt > > Hi, the draft shows as example: > > a=rid:1 pt=97 send > a=rid:2 pt=98 send > a=rid:3 pt=97 recv > > but according to https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 > it seems that "direction" (send/recv) should be placed *before* > "pt=xx": > > a=rid: [pt=;]=... > > The ABNF grammar confirms this: > > https://tools.ietf.org/html/draft-ietf-mmusic-rid-09#section-10 > > So may be the example SDPs in draft-ietf-mmusic-sdp-simulcast-07 are wrong? It appears that all the examples of this in section 6.6.1 are wrong, while the examples elsewhere are ok. Thanks, Paul From nobody Fri Mar 3 11:07: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 483D012998F for ; Fri, 3 Mar 2017 11:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 3-embu0tlRqn for ; Fri, 3 Mar 2017 11:07:42 -0800 (PST) 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 C692212998E for ; Fri, 3 Mar 2017 11:07:42 -0800 (PST) X-AuditID: 12074412-4bbff70000000b04-09-58b9befd36bd 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 68.CE.02820.DFEB9B85; Fri, 3 Mar 2017 14:07:41 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v23J7eI8013355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 3 Mar 2017 14:07:41 -0500 To: mmusic@ietf.org References: <87mvd2fj5h.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: Date: Fri, 3 Mar 2017 14:07:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <87mvd2fj5h.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixO6iqPt3384Ig7ZJmhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq9VZ5gKLgtUXPv5jamBcQpvFyMnh4SAicS03ztYuhi5OIQE djBJLLmxhg3CecMkseDIVmaQKmEBB4knzf+ZQGwRAWGJGW//soHYQgJGEh9+L2IEsdkEtCTm HPoPNImDg1fAXmLKdAOQMIuAisT3oxfAxogKpEk8bfwOZvMKCEqcnPmEBcTmFDCW2PFsGyuI zSxgJjFv80NmCFteonnrbOYJjHyzkLTMQlI2C0nZAkbmVYxyiTmlubq5iZk5xanJusXJiXl5 qUW6Znq5mSV6qSmlmxghQSa0g3H9SblDjAIcjEo8vAyTd0YIsSaWFVfmHmKU5GBSEuVdMA0o xJeUn1KZkVicEV9UmpNafIhRgoNZSYS3bzdQjjclsbIqtSgfJiXNwaIkzvtzsbqfkEB6Yklq dmpqQWoRTFaGg0NJglcRGE1CgkWp6akVaZk5JQhpJg5OkOE8QMM37gUZXlyQmFucmQ6RP8Wo KCXO+34PUEIAJJFRmgfXC0sCrxjFgV4R5l0A0s4DTCBw3a+ABjMBDfaTARtckoiQkmpg9JWR 5qjf+uVhqW9+tMNVl13Nhw8qv3tyWT134ozlTz9t4SroP3BBwy6mLOriAa30rSwnZ4v8XNV8 4P2x5L0Zsk/vzlHwfmR6JXVS70zBCeVekrKfXEqmP2L5Vzd/Qf5kHUXmIs9XK4TWizsfYS7S ywy82CF6frHot6mf/ju1PN/m9vLMwvqyrUosxRmJhlrMRcWJAL4yC/zdAgAA Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 19:07:44 -0000 Dale, On 3/3/17 10:56 AM, Dale R. Worley wrote: > Iñaki Baz Castillo writes: >>> but according to https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 >>> it seems that "direction" (send/recv) should be placed *before* >>> "pt=xx": >>> >>> a=rid: [pt=;]=... >> >> In fact, pt=xx seems to be yet another "param". > > That purported BNF is really bizarre, since it generates the clearly > incorrect form: IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not in draft-ietf-mmusic-sdp-simulcast-07, right? > a=rid: == I'm not seeing how the ABNF generates that. > A correct description is: > > a=rid: ( pt= | = ) *( ; = ) ISTM the ABNF in the draft is equivalent to what you have written. (Though yours is clearer.) Meanwhile, the ABNF of draft-ietf-mmusic-sdp-simulcast-07 does some small problems: 1) it allows either one or two 'sc-str-list's. I presume this is so you can have both send and recv lists, but it also allows two send lists or two recv lists. 2) it references rid-identifier from draft-ietf-mmusic-rid-08, but that isn't defined there. I guess it means to reference rid-id. 3) this syntax defines the syntax of the entire attribute, including "a=" and the separation between attribute name and value. We are trying to get away from that as part of the cleanup in rfc4566bis. (Because people keep getting it wrong, so that it doesn't match with the generic syntax of an attribute.) I suggest a better syntax for this would be: sc-value = sc-send [SP sc-recv] / sc-recv [SP sc-send] sc-send = "send" sc-str-list sc-recv = "recv" sc-str-list sc-str-list = SP sc-alt-list *( ";" sc-alt-list ) sc-alt-list = sc-id *( "," sc-id ) sc-id-paused = "~" sc-id = [sc-id-paused] rid-id ; SP defined in [RFC5234] ; rid-id defined in [I-D.ietf-mmusic-rid] Thanks, Paul From nobody Fri Mar 3 15:57:28 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 72852129598; Fri, 3 Mar 2017 15:55:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532346.15846.148145341868020291.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:23 -0800 Archived-At: Cc: ben@nostrum.com, mmusic@ietf.org Subject: [MMUSIC] mmusic - Requested session has been scheduled for IETF 98 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:55:23 -0000 Dear Flemming Andreasen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. mmusic Session 1 (2:00:00) Thursday, Afternoon Session I 1300-1500 Room Name: Montreux 3 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- 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): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: quic perc tls ice httpbis rtcweb avtcore avtext sipcore dispatch payload core dots sipbrandy Second Priority: clue straw xrblock rmcat stir tram sfc People who must be present: Ben Campbell Flemming Andreasen Bo Burman Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Sat Mar 4 12:29: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 CFE2D1295AE for ; Sat, 4 Mar 2017 12:29:28 -0800 (PST) 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 X7_PIKnzEABE for ; Sat, 4 Mar 2017 12:29:26 -0800 (PST) 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 9AAF6129510 for ; Sat, 4 Mar 2017 12:29:26 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id v76so92961ywg.0 for ; Sat, 04 Mar 2017 12:29:26 -0800 (PST) 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=Zza6O6iuzfBF6BZ/TXAzSrSCWgnILcuIDZDebBhjtBM=; b=RFpyElTkORNbOxwihY2AaN4x3hTBpctpO+k+BZq5OSjoT+HOpv6xHFBrYKhaLC0yIo EwZ3v6+J4q1+h5QaHebs7Vk7VfZblKA0g59jd1XYUnos5rJ23/YblVkcgGZXAxRjMZmH A5A9etFfmPYMLGP4qgvvHq0VI/LeIC3feXQKmqDpwUXdgpZL6DnE5w9ikRy2Oyx3mKTE IUDKr/0CAYSVK9jsoQI/bP1TNoyredLhNW4i8e6RN29iDF4Sqzz+EUaF1/Rj7P83Vma+ /JIo0CmufdBIt+vYK9/HnydQ827rMTu96PtZxhOtjF2uq3PmdkcyWsYhy6MRQ80QD5mh RorQ== 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=Zza6O6iuzfBF6BZ/TXAzSrSCWgnILcuIDZDebBhjtBM=; b=j0CBMtE0pw8VuoXsS0PvVTftmYFZ3QBsy1bY+roP+Wqun3EwEhZ4G7HuQ0EgV+eWJp 7zcd/uVd+bZWvOvVNhlXPzYYKMzarUJwlA6GgopMC5UGSwzotW5BbDQ1idd8htrm3/g5 2JseSznZGmvw1o1kJzyqutpVe4K60nUw1c77GGOIQUVNHPwCB1PwPzPBNnoeBYvwbQCW kCiSp8bBzIrSgDJ8m+ocjChAVk+DEsGOqLLD/KY6HpKXfNeqlNfPlbplULgDfcyUqxno b7andT8IR/BQ/PoaV5Ubl2YYr1zcOnUSxPRwFd5qBiQdh1YyeP1NEUfFiuw/ZPx1hDvL im4Q== X-Gm-Message-State: AMke39kerGeYUMbwuXWRw9C0skBfy4dpcc/pTzo9xNSp0jQCXFbemuHxCWVfib1ZtQ4G5xihpD1+qJsHPXCe7A== X-Received: by 10.13.250.67 with SMTP id k64mr6085229ywf.125.1488659365570; Sat, 04 Mar 2017 12:29:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sat, 4 Mar 2017 12:28:45 -0800 (PST) In-Reply-To: <0827af95-b755-9730-6605-5146967760e7@ericsson.com> References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> From: Eric Rescorla Date: Sat, 4 Mar 2017 12:28:45 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c07f34aaed0770549ed8415 Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 04 Mar 2017 20:29:29 -0000 --94eb2c07f34aaed0770549ed8415 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I certainly think we have to remove the 14.1 reference. Other comments below. With these comments, I would find this text acceptable. 16. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information flows over the network but only changes which addresses and ports that information is flowing on and thus has very little impact on the security of the RTP sessions. When the BUNDLE extension is used, a single set of security credentials might be used for all media streams specified by a BUNDLE group. Isn't this actually required? Both a=3Dfingerprint and a=3Dcrypto are of type TRANSPORT. When the BUNDLE extension is used, the number of SSRC values within a single RTP session increases, which increases the risk of SSRC collision. [RFC4568] describes how SSRC collision may weaken SRTP and SRTCP encryption in certain situations. This seems like it's only true in a very limited sense of situations. In both SDES and DTLS-SRTP, keys are directional, so an SSRC collision would require that one direction generate colliding SSRCs. That's certainly possible, but should be straightforward to avoid in most architectures. In any case, the base rate SSRC collision is far to high to rely on statistics to prevent it. The identfication-tag, when included in the RTP MID SDES item, This is at typo. independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag MUST NOT contain any user related information. You should just use the JSEP language here. o An "a=3Dmid" line, as specified in [RFC5888], Section 4. All MID values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-PeerConnection counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the RTP header extension defined in However, the implementation's method for generating identfication-tags could enable fingerprinting of the implementation typo in "identification" making it vulnerable to targeted attacks. The identication-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduct from I assume you mean "deduce" the RTP streams without the MID SDES header extensions. As the identification-tag is also used to route the media stream to the right application functionality it is also important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. Is there any condition when you are using SRTP that these values are not integrity protected? If not, what is the issue here? At least to prevent third parties from modifying the identification-tag value. This is not a sentence. To avoid the security risks associated with tracking of implementations, there is RECOMMENDED algorithm for generating identification-tags in Section 14.1. See above. "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] security consideration requires that when RTCP is confidentiality protected that any SDES RTP header extension carrying an SDES item, like the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. On Fri, Mar 3, 2017 at 7:06 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-03-03 kl. 14:49, skrev Eric Rescorla: > >> >> >> On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund >> > >> >> wrote: >> >> Hi, >> >> Last IETF meeting we had discussions regarding the security >> considerations for the MID RTP header extensions regarding the need >> for encrypting the RTP header. On Christer's request I have >> attempted to capture what I believed was the outcome of this >> discussion into a text proposal. >> >> So the intention of the text is to capture the security >> considerations, i.e. known risks and what we believe is necessary to >> mitigate these risks. The conclusion of the discussion was that >> encrypting the MID in RTP header extensions is not necessary, and >> thus we have a conflict with the requirements in RFC 7941. I have >> attempted to motivate and on that basis wavier this requirement for >> this particular RTP SDES header extension. This is captured in last >> paragraph of section 16. >> >> The risk of implementation tracking lead us into a discussion around >> a algorithm for generating MID Values. I have drafted a proposal for >> such an algorithm in a new Section 14.1 inserted prior to the >> existing one. >> >> I note that in RTCWeb WG we did discuss that the encryption wavier >> would be done in the security architecture. However, I believe in >> retrospect that not covering this in BUNDLE in a common fashion >> would be confusing and likely cause questions in regards to the >> requirements of RFC 7941 when BUNDLE is used in other context than >> WebRTC. >> >> So please review and provide feedback. I know Christer wants to >> close this issue. >> >> >> 14.1. Generating Identification-tags >> >> The identification-tag is exposed on the network layer due to the >> SDES item and RTP header extension defined below. As this expose= s >> the identification-tag beyond contexts where it is normally >> exposed, >> i.e. signalling layer additional potential for implementation >> identification exists. To avoid such risks a RECOMMENDED to be >> used >> algorithm for how the identification-tag value is generated is >> specified below. Using this one will ensure that one can't >> identify >> which of the implementations using this algorithm it is. >> >> >> If you mean which stack, I do not believe that this is actually that >> useful a design >> consideration. There are going to be a very large number of ways to >> fingerprint >> stacks. As the rest of the text seems predicated on that design >> objective, I do >> not think we should make this change. >> >> > Okay, what is your view on Section 16, if we remove the first sentence of > the last paragraph that references 14.1? > > We need to get the security considerations in BUNDLE into reasonable shap= e > so that we actually can get BUNDLE published. > > Cheers > > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c07f34aaed0770549ed8415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I certainly think we have to remove the 14.1 reference. Ot= her comments below.
With these comments, I would find this text accepta= ble.

16.=C2=A0 Security Considerations
<= div>
=C2=A0 =C2=A0The security considerations defined in [RFC= 3264] and [RFC5888] apply
=C2=A0 =C2=A0to the BUNDLE extension.= =C2=A0 Bundle does not change which information
=C2=A0 =C2=A0flow= s over the network but only changes which addresses and ports
=C2= =A0 =C2=A0that information is flowing on and thus has very little impact on= the
=C2=A0 =C2=A0security of the RTP sessions.

=C2=A0 =C2=A0When the BUNDLE extension is used, a single set of sec= urity
=C2=A0 =C2=A0credentials might be used for all media stream= s specified by a BUNDLE
=C2=A0 =C2=A0group.

<= div>Isn't this actually required? Both a=3Dfingerprint and a=3Dcrypto a= re
of type TRANSPORT.


=C2= =A0 =C2=A0When the BUNDLE extension is used, the number of SSRC values with= in a
=C2=A0 =C2=A0single RTP session increases, which increases t= he risk of SSRC
=C2=A0 =C2=A0collision. =C2=A0[RFC4568] describes= how SSRC collision may weaken SRTP
=C2=A0 =C2=A0and SRTCP encryp= tion in certain situations.

This seems like it'= ;s only true in a very limited sense of situations.
In both SDES = and DTLS-SRTP, keys are directional, so an SSRC collision
would r= equire that one direction generate colliding SSRCs. That's
ce= rtainly possible, but should be straightforward to avoid in most
= architectures. In any case, the base rate SSRC collision is far to
high to rely on statistics to prevent it.


=C2=A0 =C2=A0The identfication-tag, when included in the RTP MID S= DES item,

This is at typo.

=C2=A0 =C2=A0independent of transport, RTCP SDES packet or RTP header ext= ension,
=C2=A0 =C2=A0can expose the value to parties beyond the s= ignaling chain.
=C2=A0 =C2=A0Therefore, the identification-tag MU= ST NOT contain any user related
=C2=A0 =C2=A0information.

You should just use the JSEP language here.
=C2=A0 =C2=A0o =C2=A0An "a=3Dmid" line, as specified = in [RFC5888], Section 4.=C2=A0 All MID
=C2=A0 =C2=A0 =C2=A0 value= s MUST be generated in a fashion that does not leak user
=C2=A0 = =C2=A0 =C2=A0 information, e.g., randomly or using a per-PeerConnection cou= nter,
=C2=A0 =C2=A0 =C2=A0 and SHOULD be 3 bytes or less, to allo= w them to efficiently fit
=C2=A0 =C2=A0 =C2=A0 into the RTP heade= r extension defined in

=C2=A0 =C2=A0However, the i= mplementation's method for generating
=C2=A0 =C2=A0identficat= ion-tags could enable fingerprinting of the implementation

typo in "identification"


=C2=A0 =C2=A0making it vulnerable to targeted attacks.=C2=A0 The i= dentication-tag is
=C2=A0 =C2=A0exposed on the RTP stream level w= hen included in the RTP header
=C2=A0 =C2=A0extensions, however w= hat it reveals of the RTP media stream structure
=C2=A0 =C2=A0of = the endpoint and application was already possible to deduct from
=
I assume you mean "deduce"

=C2=A0 =C2=A0the RTP streams without the MID SDES header extensions.=C2= =A0 As the
=C2=A0 =C2=A0identification-tag is also used to route = the media stream to the
=C2=A0 =C2=A0right application functional= ity it is also important that the value
=C2=A0 =C2=A0received is = the one intended by the sender, thus integrity and the
=C2=A0 =C2= =A0authenticity of the source are important to prevent denial of service
=C2=A0 =C2=A0on the application.

Is there = any condition when you are using SRTP that these values are
not i= ntegrity protected? If not, what is the issue here?


=C2=A0 =C2=A0At least to prevent third parties from modify= ing
=C2=A0 =C2=A0the identification-tag value.

This is not a sentence.

=C2=A0 =C2=A0To avo= id the security risks associated with tracking of
=C2=A0 =C2=A0im= plementations, there is RECOMMENDED algorithm for generating
=C2= =A0 =C2=A0identification-tags in Section 14.1.

See= above.

=C2=A0 =C2=A0"RTP Header Extension fo= r the
=C2=A0 =C2=A0RTP Control Protocol (RTCP) Source Description= Items" [RFC7941]
=C2=A0 =C2=A0security consideration requir= es that when RTCP is confidentiality
=C2=A0 =C2=A0protected that = any SDES RTP header extension carrying an SDES item,
=C2=A0 =C2= =A0like the MID RTP header extension, is also protected using
=C2= =A0 =C2=A0commensurate strength algorithms.=C2=A0 However, assuming the abo= ve
=C2=A0 =C2=A0requirements and recommendations are followed the= re are no known
=C2=A0 =C2=A0significant security risks with leav= ing the MID RTP header extension
=C2=A0 =C2=A0without confidentia= lity protection.=C2=A0 Thus, the requirements in RFC
=C2=A0 =C2= =A07941 MAY be ignored for the MID RTP header extension.=C2=A0 Security
=C2=A0 =C2=A0mechanisms for RTP/RTCP are discussed in Options for Se= curing RTP
=C2=A0 =C2=A0Sessions [RFC7201], for example SRTP [RFC= 3711] can provide the
=C2=A0 =C2=A0necessary security functions o= f ensuring the integrity and source
=C2=A0 =C2=A0authenticity.


On Fri, Mar 3, 2017 at 7:06 AM, Magnus Westerlu= nd <magnus.westerlund@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Den 2017-03-03 kl. 14:49, sk= rev Eric Rescorla:


On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund
 <mag= nus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.co= m>>

wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 Last IETF meeting we had discussions regarding the security =C2=A0 =C2=A0 considerations for the MID RTP header extensions regarding th= e need
=C2=A0 =C2=A0 for encrypting the RTP header. On Christer's request I ha= ve
=C2=A0 =C2=A0 attempted to capture what I believed was the outcome of this<= br> =C2=A0 =C2=A0 discussion into a text proposal.

=C2=A0 =C2=A0 So the intention of the text is to capture the security
=C2=A0 =C2=A0 considerations, i.e. known risks and what we believe is neces= sary to
=C2=A0 =C2=A0 mitigate these risks. The conclusion of the discussion was th= at
=C2=A0 =C2=A0 encrypting the MID in RTP header extensions is not necessary,= and
=C2=A0 =C2=A0 thus we have a conflict with the requirements in RFC 7941. I = have
=C2=A0 =C2=A0 attempted to motivate and on that basis wavier this requireme= nt for
=C2=A0 =C2=A0 this particular RTP SDES header extension. This is captured i= n last
=C2=A0 =C2=A0 paragraph of section 16.

=C2=A0 =C2=A0 The risk of implementation tracking lead us into a discussion= around
=C2=A0 =C2=A0 a algorithm for generating MID Values. I have drafted a propo= sal for
=C2=A0 =C2=A0 such an algorithm in a new Section 14.1 inserted prior to the=
=C2=A0 =C2=A0 existing one.

=C2=A0 =C2=A0 I note that in RTCWeb WG we did discuss that the encryption w= avier
=C2=A0 =C2=A0 would be done in the security architecture. However, I believ= e in
=C2=A0 =C2=A0 retrospect that not covering this in BUNDLE in a common fashi= on
=C2=A0 =C2=A0 would be confusing and likely cause questions in regards to t= he
=C2=A0 =C2=A0 requirements of RFC 7941 when BUNDLE is used in other context= than
=C2=A0 =C2=A0 WebRTC.

=C2=A0 =C2=A0 So please review and provide feedback. I know Christer wants = to
=C2=A0 =C2=A0 close this issue.


=C2=A0 =C2=A0 14.1.=C2=A0 Generating Identification-tags

=C2=A0 =C2=A0 =C2=A0 =C2=A0The identification-tag is exposed on the network= layer due to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0SDES item and RTP header extension defined below= .=C2=A0 As this exposes
=C2=A0 =C2=A0 =C2=A0 =C2=A0the identification-tag beyond contexts where it = is normally exposed,
=C2=A0 =C2=A0 =C2=A0 =C2=A0i.e.=C2=A0 signalling layer additional potential= for implementation
=C2=A0 =C2=A0 =C2=A0 =C2=A0identification exists.=C2=A0 To avoid such risks= a RECOMMENDED to be used
=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm for how the identification-tag value i= s generated is
=C2=A0 =C2=A0 =C2=A0 =C2=A0specified below.=C2=A0 Using this one will ensur= e that one can't identify
=C2=A0 =C2=A0 =C2=A0 =C2=A0which of the implementations using this algorith= m it is.


If you mean which stack, I do not believe that this is actually that
useful a design
consideration. There are going to be a very large number of ways to
fingerprint
stacks. As the rest of the text seems predicated on that design
objective, I do
not think we should make this change.


Okay, what is your view on Section 16, if we remove the first sentence of t= he last paragraph that references 14.1?

We need to get the security considerations in BUNDLE into reasonable shape = so that we actually can get BUNDLE published.

Cheers


Magnus Westerlund

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


--94eb2c07f34aaed0770549ed8415-- From nobody Mon Mar 6 00:31:44 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 A463612944F; Mon, 6 Mar 2017 00:31:42 -0800 (PST) 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 q7Bid9-mGtS4; Mon, 6 Mar 2017 00:31:40 -0800 (PST) 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 86BF112945C; Mon, 6 Mar 2017 00:31:39 -0800 (PST) X-AuditID: c1b4fb3a-29b639800000484c-92-58bd1e69fd89 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 22.AD.18508.96E1DB85; Mon, 6 Mar 2017 09:31:37 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Mon, 6 Mar 2017 09:31:33 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount , Ben Campbell Thread-Topic: =?windows-1254?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-mmusic-sctp-sd?= =?windows-1254?Q?p-23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAAAH3gIAAE4kggAAVhACABDfnAIAAQksAgAAt4QCAAR3EAIAAFWGAgAtEKQCAA+rWgIAAKSkAgAB2+4CABii+AA== Date: Mon, 6 Mar 2017 08:31:33 +0000 Message-ID: References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> <6366ADF1-E3E4-4C91-8579-85246D3E3714@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.1.161129 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D4E2EB5A18CC8christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUyM2K7hG6m3N4IgyVfJC3md55mt3i1bj6z xYrX59gt3l/QtZjxZyKzxYvrH5ktzu9cz2QxdfljFovrT3exOHB6TPm9kdVjyZKfTB4tHxey esza+YTFY/LjNmaPrX//sgWwRXHZpKTmZJalFunbJXBlLJ7fw1rQWFJxd8NPtgbGGaldjJwc EgImEkv+b2LuYuTiEBJYxyjRs/UdI4SziFFi3vJXbF2MHBxsAhYS3f+0QeIiAk2MEpe2vGED cZgFdjFJXPlylx3EEQbJbFn5iBmirJlRYt23vewQzjJGiU3TbjKCbGQRUJGYO2cXE4jNK2At ce7tQTaIhY84JPZ3nmcBSXAK2Ei8v98JZjMKiEl8P7UGrIFZQFzi1pP5TBCnC0gs2XOeGcIW lXj5+B8riC0qoCex/PkaqLiixMdX+xhBnmAWSJBYdssUYq+gxMmZT1gmMIrOQjJ1FkLVLCRV ECUGEkfO3WSFsLUlli18zQxh60vMW7ABqsZa4t63aShqFjByrGIULU4tLs5NNzLSSy3KTC4u zs/Ty0st2cQIjP2DW35b7WA8+NzxEKMAB6MSD2/BjD0RQqyJZcWVuYcYJTiYlUR4D24BCvGm JFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cCYo7XiZ4rW/Oms mkvVbwbIpHgWsx2dne53RqRrR9wqtyOZdpXZ/Zv54x+9V+2L+fj+9JaHa2s7OvgE/rjqsEh1 TnKtu5A7favG0rfzt99tPWvp+3LKmtKeCTzxnprhvQdcTi9cUPDulebDrcXuTgIZurl7rKSk z+XK1u4x4noh5uWhWzTX/J8SS3FGoqEWc1FxIgCOynOO+QIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?cp1254?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ietf-m?= =?cp1254?q?music-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 08:31:43 -0000 --_000_D4E2EB5A18CC8christerholmbergericssoncom_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable Hi, I haven=92t seen any objections to Roman=92s pull request, so I intend to m= erge it and submit a new version of the draft. Regards, Christer From: Christer Holmberg > Date: Thursday 2 March 2017 at 12:28 To: Roman Shpount >, Ben Campbell > Cc: Mirja Kuehlewind >, "mm= usic-chairs@ietf.org" >, Eric Rescorla >, "mmusic@ietf.org" >, Flemming Andreasen >, "iesg@ietf.org" >, "draft-ietf-mmusic-sctp-sdp@ietf.org" > Subject: Re: Mirja K=FChlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: = (with DISCUSS) Resent-From: > Resent-To: Gonzalo Camarillo >, Salvatore Loreto >, Christer Holmberg > Resent-Date: Thursday 2 March 2017 at 12:28 Hi, There may be some minor editorial nits, but in general I am ok with the pul= l request. Regards, Christer From: Roman Shpount > Date: Thursday 2 March 2017 at 07:25 To: Ben Campbell > Cc: Christer Holmberg >, Mirja Kuehlewind >, "mmusic-chairs@ietf.org" >, Eric Rescorla >, "mmusic@ietf.org" >, Flemming Andreasen >, "iesg@ietf.org" >, "draft-ietf-mmusic-sctp-sdp@ietf.org" > Subject: Re: Mirja K=FChlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: = (with DISCUSS) Ben, I have submitted the pull request to address these comments: https://github= .com/cdh4u/draft-sctp-sdp/pull/11 I hope that after Christer reviews and merges the pull request, we should h= ave the latest set of comments addressed. If we need more information about framing, I believe it should go into TCP/= DTLS related draft, since all that draft-sctp-sdp is doing is reusing the s= ame framing for exactly the same reasons. Regards, _____________ Roman Shpount On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell > wrote: Hi all, It seems like this conversation has not completed. What do we need to get t= o closure? A few thoughts of my own: - I'm not adverse to making non-ICE implementors look at the ICE specs for = framing information, as long as the citations are precise enough that they = don't need to read the entirety of ICE. (And the information is really ther= e.) - I am adverse to repeating normative text. I'm okay with adding informatio= nal text about non-ICE usage, as long as it is general enough to avoid conf= usion about where the authoritative text resides. - If people think that ICE is not sufficiently specified, we can work on th= at. But I don't think the burden of doing that belongs to this draft. - The draft is in fact IESG approved in its current state. Material changes= should be kept to the minimum. On 27 Feb 2017, at 7:06, Christer Holmberg wrote: Hi, ... Also I=B9m not sure if the ICE part is fully specified. In your previously mail you wrote "As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m=3D line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m=3D line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.=B3 >From what I understood from ekr, you might not in any case send an re-invite; but maybe I understood this wrongly. I guess that could also be further explained in the draft. Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft. Regards, Christer --_000_D4E2EB5A18CC8christerholmbergericssoncom_ Content-Type: text/html; charset="windows-1254" Content-ID: <0A14C8EE4EE6214AAD6A8AF4A35DD217@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I haven=92t seen any objections to Roman=92s pull request, so I intend= to merge it and submit a new version of the draft.

Regards,

Christer

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thursday 2 March 2017 at 12:2= 8
To: Roman Shpount <rshpount@turbobridge.com>, Ben Campbe= ll <ben@nostrum.com>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, Eric Rescorla <ekr@rtfm.com>, &q= uot;mmusic@ietf.org" <mmusic@ietf.org>, Flemming Andreasen &l= t;fandreas@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org&= quot; <draft-ietf= -mmusic-sctp-sdp@ietf.org>
Subject: Re: Mirja K=FChlewind's Di= scuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)
Resent-From: <alias-bounces@ietf.org>
Resent-To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.= com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Christer Holmberg <christer.ho= lmberg@ericsson.com>
Resent-Date: Thursday 2 March 2017 = at 12:28

Hi,

There may be some minor editorial nits, but in general I am ok with th= e pull request.

Regards,

Christer

From: Roman Shpount <rshpount@turbobridge.com>
Date: Thursday 2 March 2017 at 07:2= 5
To: Ben Campbell <ben@nostrum.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Mirja Kuehlewind <ietf@ku= ehlewind.net>, "mmusi= c-chairs@ietf.org" <mmusic-chairs@ietf.org&g= t;, Eric Rescorla <ekr@rtfm.com>,= "mmusic@ietf.org" <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>, &quo= t;iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmus= ic-sctp-sdp@ietf.org>
Subject: Re: Mirja K=FChlewind's Di= scuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

Ben,

I have submitted the pull request to address these comments: https://github.com/= cdh4u/draft-sctp-sdp/pull/11

I hope that after Christer reviews and merges the pull request, we sho= uld have the latest set of comments addressed.

If we need more information about framing, I believe it should go into= TCP/DTLS related draft, since all that draft-sctp-sdp is doing is reusing = the same framing for exactly the same reasons.

Regards,

_________= ____
Roman Shpount

On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell <ben@nostrum.com> wrote:
Hi all,

It seems like this conversation has not completed. What do we need to get t= o closure?

A few thoughts of my own:

- I'm not adverse to making non-ICE implementors look at the ICE specs for = framing information, as long as the citations are precise enough that they = don't need to read the entirety of ICE. (And the information is really ther= e.)

- I am adverse to repeating normative text. I'm okay with adding informatio= nal text about non-ICE usage, as long as it is general enough to avoid conf= usion about where the authoritative text resides.

- If people think that ICE is not sufficiently specified, we can work on th= at. But I don't think the burden of doing that belongs to this draft.

- The draft is in fact IESG approved in its current state. Material changes= should be kept to the minimum.


On 27 Feb 2017, at 7:06, Christer Holmberg wrote:

Hi,

...

Also I=B9m not sure if the ICE part is fully specified. In your previously<= br> mail you wrote

"As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE
end points are supposed to send a re-INVITE after nomination process is
completed with the selected candidate address in the m=3D line. So, if tcp<= br> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP
transport tag in the m=3D line. Also, any offers/answers after the ICE
nomination is complete, are supposed to send the currently selected
candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.=B3

>From what I understood from ekr, you might not in any case send an
re-invite; but maybe I understood this wrongly. I guess that could also
be further explained in the draft.

Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft.

Regards,

Christer

 --_000_D4E2EB5A18CC8christerholmbergericssoncom_-- From nobody Mon Mar 6 05:07: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 A54A712967F; Mon, 6 Mar 2017 05:07:26 -0800 (PST) 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 WyRA9BmZhbqw; Mon, 6 Mar 2017 05:07:25 -0800 (PST) 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 04C11129677; Mon, 6 Mar 2017 05:07:24 -0800 (PST) X-AuditID: c1b4fb3a-29b639800000484c-a1-58bd5f0b7415 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id B5.26.18508.A0F5DB85; Mon, 6 Mar 2017 14:07:23 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Mon, 6 Mar 2017 14:07:07 +0100 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> From: Magnus Westerlund Message-ID: Date: Mon, 6 Mar 2017 14:07:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM2J7lC53/N4Ig+ad/BYrXp9jt5i6/DGL xdp/7ewOzB5Llvxk8pj8uI05gCmKyyYlNSezLLVI3y6BK+PikpiCXfYVbxatZmpgPG/YxcjJ ISFgIjG5cwNzFyMXh5DAOkaJF7d+soMkhASWMUrM3JELYgsLeEm0bZvIDGKLCChI/PpzggWi oZlJ4ljjNcYuRg4OZgEfiYXPEkFq2AQsJG7+aGQDsXkF7CX+bnsF1ssioCJx+OxCRhBbVCBG Ym//fSaIGkGJkzOfsICM4RQIlPjZlA0SZgYaM3P+eUYIW16ieetsZojTtCUamjpYJzAKzELS PQtJyywkLQsYmVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBAbnwS2/rXYwHnzueIhRgINR iYe3YMaeCCHWxLLiytxDjBIczEoivIa+eyOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8u JJCeWJKanZpakFoEk2Xi4JRqYJRgCLy10UUi4yRHt9Legp/7WHdmcaT3rty38PM01pgDqyau +HLvqtDyOMdL2u1cyRLsd5d171pS1Tpx6aEVZQteSe0VqUsU7F/yX2a9f4nkj6lvpuoqzFf1 zHM9XpPE4F5jvd2SoynCtXvJjtbZbyX9hdsf3LDd0897Njr0yM9Ns+4KH1knOlOJpTgj0VCL uag4EQDAhcWASgIAAA== Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 13:07:26 -0000 Thanks, I have updated the text, new text at the bottom after replies. Den 2017-03-04 kl. 21:28, skrev Eric Rescorla: > I certainly think we have to remove the 14.1 reference. Other comments > below. > With these comments, I would find this text acceptable. > > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information > flows over the network but only changes which addresses and ports > that information is flowing on and thus has very little impact on the > security of the RTP sessions. > > When the BUNDLE extension is used, a single set of security > credentials might be used for all media streams specified by a BUNDLE > group. > > Isn't this actually required? Both a=fingerprint and a=crypto are > of type TRANSPORT. I think you are correct assuming that one is using SRTP. All the IETF key-management scheme follows this, although a=mikey is IDENTICAL. If one uses other security mechanisms, then this is still relevant to capture. > > > When the BUNDLE extension is used, the number of SSRC values within a > single RTP session increases, which increases the risk of SSRC > collision. [RFC4568] describes how SSRC collision may weaken SRTP > and SRTCP encryption in certain situations. > > This seems like it's only true in a very limited sense of situations. > In both SDES and DTLS-SRTP, keys are directional, so an SSRC collision > would require that one direction generate colliding SSRCs. That's > certainly possible, but should be straightforward to avoid in most > architectures. In any case, the base rate SSRC collision is far to > high to rely on statistics to prevent it. I don't think this paragraph is that relevant. I would lean towards removing it. With DTLS-SRTP that per direction specific transport keys even an SSRC collision is not an issue, assuming that crypto end-point is not actually trying to forward two different RTP streams using the same SSRC, which would be so broken also on RTP level, in addition to revealing the plaintext for some ciphers. We actually don't have a mechanism that always work for preventing SSRC collisions by ensuring agreement of SSRC usage. > > > The identfication-tag, when included in the RTP MID SDES item, > > This is at typo. > > independent of transport, RTCP SDES packet or RTP header extension, > can expose the value to parties beyond the signaling chain. > Therefore, the identification-tag MUST NOT contain any user related > information. > > You should just use the JSEP language here. > > o An "a=mid" line, as specified in [RFC5888], Section 4. All MID > values MUST be generated in a fashion that does not leak user > information, e.g., randomly or using a per-PeerConnection counter, > and SHOULD be 3 bytes or less, to allow them to efficiently fit > into the RTP header extension defined in > > However, the implementation's method for generating > identfication-tags could enable fingerprinting of the implementation > > typo in "identification" > Fixed > > making it vulnerable to targeted attacks. The identication-tag is > exposed on the RTP stream level when included in the RTP header > extensions, however what it reveals of the RTP media stream structure > of the endpoint and application was already possible to deduct from > > I assume you mean "deduce" Yes. > > the RTP streams without the MID SDES header extensions. As the > identification-tag is also used to route the media stream to the > right application functionality it is also important that the value > received is the one intended by the sender, thus integrity and the > authenticity of the source are important to prevent denial of service > on the application. > > Is there any condition when you are using SRTP that these values are > not integrity protected? If not, what is the issue here? > Applies to other security mechanisms than SRTP. > > At least to prevent third parties from modifying > the identification-tag value. > > This is not a sentence. I will repeat it, the requirement is clear from previous sentence. > > To avoid the security risks associated with tracking of > implementations, there is RECOMMENDED algorithm for generating > identification-tags in Section 14.1. > > See above. > 16. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information flows over the network but only changes which addresses and ports that information is flowing on and thus has very little impact on the security of the RTP sessions. When the BUNDLE extension is used, a single set of security credentials might be used for all media streams specified by a BUNDLE group. When using SRTP this is further required at least for the IETF defined key-management solutions due to their SDP attributes (a=crypto, a=fingerprint, a=mikey) classification in [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security solutions, this may require further consideration. The identfication-tag, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-bundle group counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension. However, the implementation's method for generating identification-tags could enable fingerprinting of the implementation making it vulnerable to targeted attacks. The identication-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduce from the RTP streams without the MID SDES header extensions. As the identification-tag is also used to route the media stream to the right application functionality it is also important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. Existing SRTP configurations requires integrity protection of both RTCP and RTP header extensions. "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] security consideration requires that when RTCP is confidentiality protected that any SDES RTP header extension carrying an SDES item, like the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 6 05:36: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 0CEAC1296E5 for ; Mon, 6 Mar 2017 05:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 TdV2Hc0_Us_D for ; Mon, 6 Mar 2017 05:36:03 -0800 (PST) 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 930A41296E7 for ; Mon, 6 Mar 2017 05:36:03 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id n11so64063485wma.1 for ; Mon, 06 Mar 2017 05:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0B0zx30IkoiBw8tEYxABPMC2rx5DZBSNSDHymtLDLiQ=; b=tilQtjAIp1VePLTmKyYFa8rNKuyUw+XB5KGxD86mcMfduH5LTTPlLT+D8gLRRmvoai aY7ky6M4poVl7i1JJtcV1/cX6QfYLjKaHBeAOZgI18teGTyXOHy+7+C182njBkGjZNMc K8MvBNl9Ixa6sNNuHQPEoiRrTjjQQ/VC19LAz2sKFC8IEIQOJ8Z3KdMSpeRCCmt5B1/K myzM4RVM6uP4ubgi0l9hAIIKCrQ4LaGqNgS4H6MPtFoNpdryPHNPkLd5M8d1v5McZ/oV yFJTtQi/lAvTjjqwS4z1l4p2/KKGRnI6bBuDp4UpzTj0wHtCdwwI9VzB8Qe1tXcxS9u0 TyRg== 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=0B0zx30IkoiBw8tEYxABPMC2rx5DZBSNSDHymtLDLiQ=; b=UT1M8PexO5/zJDnyeLApyskhHAWaMUDIEF6KKNGDndX428myycU1SPE2eGBkPMb4kl IPG5IOlH3F/9XuBrwhCGbzBPg74lyLRTm2xy9EH+YD5WRezWTeKg9tUAUtkSIGL7gPAJ h4OlEodjI1bmJ0KEUA8LkljtilK9w5Gb/QpkDt8CYGO/F5zxWNoXVpMhpOH0ySEjaDvQ AUhHnr8CgU0Rju1QIahu5XxaIbhphqVviy7KQdUZNWwlNhprlTxVSHukvf5/TnN/WoSz 4CJ8CzlLwHVZb0HxDxv6iJJI+JE82XwhdMQs6imKbjruaVphaNdMKYi8/98/LrgNgdQv seWA== X-Gm-Message-State: AMke39n0HEbxksHMAE5m17hi2mbMkfr2YkSnW9utAeAHPFnejaiXoXefRNviEOskIaxPupEJT00q3oLUS123Ag== X-Received: by 10.28.97.2 with SMTP id v2mr14431879wmb.3.1488807362027; Mon, 06 Mar 2017 05:36:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 6 Mar 2017 05:35:41 -0800 (PST) In-Reply-To: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 6 Mar 2017 14:35:41 +0100 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 13:36:06 -0000 2017-03-03 14:24 GMT+01:00 Magnus Westerlund : > When the BUNDLE extension is used, the number of SSRC values within a sin= gle RTP session increases, which increases the risk of SSRC collision This is relevant when there are ~100000000 streams within a single RTP session. If there are 10 streams, the exact risk is 10 / 2^32 =3D 2.32e-09. I think we can live without having to mention this "issue" in every RTP related specification. To be clear: stating that "BUNDLE increases the risk of SSRC collision" is a no sense IMHO. --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 6 05:37:03 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 E9FCF1296F0 for ; Mon, 6 Mar 2017 05:37:00 -0800 (PST) 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 7ib-gZ_KHL3u for ; Mon, 6 Mar 2017 05:36:57 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 E455A1296ED for ; Mon, 6 Mar 2017 05:36:55 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id v76so19450137ywg.0 for ; Mon, 06 Mar 2017 05:36:55 -0800 (PST) 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=miDHS0peHBcBfuU7wJR+l1kzi0cEfv7VWSGDQE/tbCY=; b=pTl8XFK2NrP8vNqVuHfAET0GSBc9zyxYnM2jEA1fF/Rwf3aAACFJ9FDTADOhxQUjgU sDCvZURGCmhsiKWBx126B+0Op/aVQVQheYO27+tOg6/nswA29v1uIWWDcjRU4LVYDkoQ VXriBnQ4ljE3oQoNIXjJN6ITz5ExSggEawq45MxfnwtyA3YyqBebmX1by4Pn4KslBkZy 34wwcooMlpzgI2IZtnRba8kVxsVseusX/8sobIDauJFVvaNzLEOFZfvcOs85ilg7lf2v OjzSAXh7RvjugY8inTsCAolzf3zJ72+a5Q8pZKNinlocd0muEGwZivujcJ0vxPUzojw9 TtCA== 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=miDHS0peHBcBfuU7wJR+l1kzi0cEfv7VWSGDQE/tbCY=; b=Op1o3A3lWPuA92s/Ip+tuaxKlRjtRuGh0UzeOiBltIjptyCyysXNpjOZA/lnbq6b7j ZvMniLItKNlMVQy3qioVzYIjKXt45SrASWQaehQ+d486/NCK91bZfrOK29KrHPeHZnib cJJ+EIt196eOe6dAcpBYsiBb0N+D8ZZT+l9YFhDW3MJznNVHFZl0frunM25v6Au4qhpF zgNWbpOT1GRpk7w5G9Cwr7NSX7F038ZNAq4CU0dlmx+mZ4G4FWrZ34Hco9T3cFLxZTxk QODJqjhVxRWQnl6q60XVla8TE/hw7K/BmDQenxyhJj7VMXe1DDLVFHcYoGZ9rfsbH17j Cvtw== X-Gm-Message-State: AMke39lG5itrf8MiV6EhAnR7ILXkL71wGmYNIivpBAW5YGHhEI7jg54AS0fjG1Bgb337CsQ7Rzgr5eKzwfaCng== X-Received: by 10.37.224.81 with SMTP id x78mr10699989ybg.80.1488807414986; Mon, 06 Mar 2017 05:36:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Mon, 6 Mar 2017 05:36:14 -0800 (PST) In-Reply-To: References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> From: Eric Rescorla Date: Mon, 6 Mar 2017 05:36:14 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c0873581c370d054a0ffdb8 Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 13:37:01 -0000 --94eb2c0873581c370d054a0ffdb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 6, 2017 at 5:07 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Thanks, > > I have updated the text, new text at the bottom after replies. > > > Den 2017-03-04 kl. 21:28, skrev Eric Rescorla: > >> I certainly think we have to remove the 14.1 reference. Other comments >> below. >> With these comments, I would find this text acceptable. >> >> 16. Security Considerations >> >> The security considerations defined in [RFC3264] and [RFC5888] apply >> to the BUNDLE extension. Bundle does not change which information >> flows over the network but only changes which addresses and ports >> that information is flowing on and thus has very little impact on the >> security of the RTP sessions. >> >> When the BUNDLE extension is used, a single set of security >> credentials might be used for all media streams specified by a BUNDLE >> group. >> >> Isn't this actually required? Both a=3Dfingerprint and a=3Dcrypto are >> of type TRANSPORT. >> > > I think you are correct assuming that one is using SRTP. All the IETF > key-management scheme follows this, although a=3Dmikey is IDENTICAL. If o= ne > uses other security mechanisms, then this is still relevant to capture. Which security mechanisms are you thinking of here? When the BUNDLE extension is used, the number of SSRC values within a >> single RTP session increases, which increases the risk of SSRC >> collision. [RFC4568] describes how SSRC collision may weaken SRTP >> and SRTCP encryption in certain situations. >> >> This seems like it's only true in a very limited sense of situations. >> In both SDES and DTLS-SRTP, keys are directional, so an SSRC collision >> would require that one direction generate colliding SSRCs. That's >> certainly possible, but should be straightforward to avoid in most >> architectures. In any case, the base rate SSRC collision is far to >> high to rely on statistics to prevent it. >> > > I don't think this paragraph is that relevant. I would lean towards > removing it. With DTLS-SRTP that per direction specific transport keys ev= en > an SSRC collision is not an issue, assuming that crypto end-point is not > actually trying to forward two different RTP streams using the same SSRC, > which would be so broken also on RTP level, in addition to revealing the > plaintext for some ciphers. > > We actually don't have a mechanism that always work for preventing SSRC > collisions by ensuring agreement of SSRC usage. I am fine to remove this paragraph. >> making it vulnerable to targeted attacks. The identication-tag is >> exposed on the RTP stream level when included in the RTP header >> extensions, however what it reveals of the RTP media stream structure >> of the endpoint and application was already possible to deduct from >> >> I assume you mean "deduce" >> > > Yes. > > >> the RTP streams without the MID SDES header extensions. As the >> identification-tag is also used to route the media stream to the >> right application functionality it is also important that the value >> received is the one intended by the sender, thus integrity and the >> authenticity of the source are important to prevent denial of service >> on the application. >> >> Is there any condition when you are using SRTP that these values are >> not integrity protected? If not, what is the issue here? >> >> > Applies to other security mechanisms than SRTP. What such mechanisms are there? The only ones I know of that people have proposed just encapsulate the entire packet. To avoid the security risks associated with tracking of >> implementations, there is RECOMMENDED algorithm for generating >> identification-tags in Section 14.1. >> >> See above. >> >> > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information > flows over the network but only changes which addresses and ports > that information is flowing on and thus has very little impact on the > security of the RTP sessions. > Is this precisely true? Do you ever use the MID extension w/o BUNDLE? It certainly changes which ICE checks you do. > > When the BUNDLE extension is used, a single set of security > credentials might be used for all media streams specified by a BUNDLE > group. When using SRTP this is further required at least for the > IETF defined key-management solutions due to their SDP attributes > (a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) classification in > [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security > solutions, this may require further consideration. > > The identfication-tag, independent of transport, RTCP SDES packet or > RTP header extension, can expose the value to parties beyond the > signaling chain. Therefore, the identification-tag values MUST be > generated in a fashion that does not leak user information, e.g., > randomly or using a per-bundle group counter, and SHOULD be 3 bytes > or less, to allow them to efficiently fit into the MID RTP header > extension. However, the implementation's method for generating > identification-tags could enable fingerprinting of the implementation > making it vulnerable to targeted attacks. I would say "Note that if implementations use different methods for generating ... this could..." > The identication-tag is > Still misspelled. -Ekr > exposed on the RTP stream level when included in the RTP header > extensions, however what it reveals of the RTP media stream structure > of the endpoint and application was already possible to deduce from > the RTP streams without the MID SDES header extensions. As the > identification-tag is also used to route the media stream to the > right application functionality it is also important that the value > received is the one intended by the sender, thus integrity and the > authenticity of the source are important to prevent denial of service > on the application. Existing SRTP configurations requires integrity > protection of both RTCP and RTP header extensions. > > "RTP Header Extension for the RTP Control Protocol (RTCP) Source > Description Items" [RFC7941] security consideration requires that > when RTCP is confidentiality protected that any SDES RTP header > extension carrying an SDES item, like the MID RTP header extension, > is also protected using commensurate strength algorithms. However, > assuming the above requirements and recommendations are followed > there are no known significant security risks with leaving the MID > RTP header extension without confidentiality protection. Thus, the > requirements in RFC 7941 MAY be ignored for the MID RTP header > extension. Security mechanisms for RTP/RTCP are discussed in Options > for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can > provide the necessary security functions of ensuring the integrity > and source authenticity. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c0873581c370d054a0ffdb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 6, 2017 at 5:07 AM, Magnus Westerlund <= ;magnus= .westerlund@ericsson.com> wrote:
Thanks,

I have updated the text, new text at the bottom after replies.


Den 2017-03-04 kl. 21:28, skrev Eric Rescorla:
I certainly think we have to remove the 14.1 reference. Other comments
below.
With these comments, I would find this text acceptable.

16.=C2=A0 Security Considerations

=C2=A0 =C2=A0The security considerations defined in [RFC3264] and [RFC5888]= apply
=C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not change which in= formation
=C2=A0 =C2=A0flows over the network but only changes which addresses and po= rts
=C2=A0 =C2=A0that information is flowing on and thus has very little impact= on the
=C2=A0 =C2=A0security of the RTP sessions.

=C2=A0 =C2=A0When the BUNDLE extension is used, a single set of security =C2=A0 =C2=A0credentials might be used for all media streams specified by a= BUNDLE
=C2=A0 =C2=A0group.

Isn't this actually required? Both a=3Dfingerprint and a=3Dcrypto are of type TRANSPORT.

 I think you are correct assuming that one is using SRTP. All the IETF key-m= anagement scheme follows this, although a=3Dmikey is IDENTICAL. If one uses= other security mechanisms, then this is still relevant to capture.

Which security mechanisms are you thinking of here= ?


=C2=A0 =C2=A0When the BUNDLE extension is used, the number of SSRC values w= ithin a
=C2=A0 =C2=A0single RTP session increases, which increases the risk of SSRC=
=C2=A0 =C2=A0collision.=C2=A0 [RFC4568] describes how SSRC collision may we= aken SRTP
=C2=A0 =C2=A0and SRTCP encryption in certain situations.

This seems like it's only true in a very limited sense of situations. In both SDES and DTLS-SRTP, keys are directional, so an SSRC collision
would require that one direction generate colliding SSRCs. That's
certainly possible, but should be straightforward to avoid in most
architectures. In any case, the base rate SSRC collision is far to
high to rely on statistics to prevent it.

 I don't think this paragraph is that relevant. I would lean towards rem= oving it. With DTLS-SRTP that per direction specific transport keys even an= SSRC collision is not an issue, assuming that crypto end-point is not actu= ally trying to forward two different RTP streams using the same SSRC, which= would be so broken also on RTP level, in addition to revealing the plainte= xt for some ciphers.

We actually don't have a mechanism that always work for preventing SSRC= collisions by ensuring agreement of SSRC usage.

I am fine to remove this paragraph.=C2=A0

=C2=A0 =C2=A0making it vulnerable to targeted attacks.=C2=A0 The identicati= on-tag is
=C2=A0 =C2=A0exposed on the RTP stream level when included in the RTP heade= r
=C2=A0 =C2=A0extensions, however what it reveals of the RTP media stream st= ructure
=C2=A0 =C2=A0of the endpoint and application was already possible to deduct= from

I assume you mean "deduce"

 Yes.


=C2=A0 =C2=A0the RTP streams without the MID SDES header extensions.=C2=A0 = As the
=C2=A0 =C2=A0identification-tag is also used to route the media stream to t= he
=C2=A0 =C2=A0right application functionality it is also important that the = value
=C2=A0 =C2=A0received is the one intended by the sender, thus integrity and= the
=C2=A0 =C2=A0authenticity of the source are important to prevent denial of = service
=C2=A0 =C2=A0on the application.

Is there any condition when you are using SRTP that these values are
not integrity protected? If not, what is the issue here?


 Applies to other security mechanisms than SRTP.

=
What such mechanisms are there? The only ones I know of that people ha= ve proposed
just encapsulate the entire packet.
=C2=A0<= /div>


=C2=A0 =C2=A0To avoid the security risks associated with tracking of
=C2=A0 =C2=A0implementations, there is RECOMMENDED algorithm for generating=
=C2=A0 =C2=A0identification-tags in Section 14.1.

See above.


 16.=C2=A0 Security Considerations

=C2=A0 =C2=A0The security considerations defined in [RFC3264] and [RFC5888]= apply
=C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not change which in= formation
=C2=A0 =C2=A0flows over the network but only changes which addresses and po= rts
=C2=A0 =C2=A0that information is flowing on and thus has very little impact= on the
=C2=A0 =C2=A0security of the RTP sessions.

=
Is this precisely true? Do you ever use the MID extension w/o BU= NDLE?
It certainly changes which ICE checks you do.
=C2= =A0

=C2=A0 =C2=A0When the BUNDLE extension is used, a single set of security =C2=A0 =C2=A0credentials might be used for all media streams specified by a= BUNDLE
 =C2=A0 =C2=A0group.=C2=A0 When using SRTP this is further required at least= for the
=C2=A0 =C2=A0IETF defined key-management solutions due to their SDP attribu= tes
=C2=A0 =C2=A0(a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) classification in
=C2=A0 =C2=A0[I-D.ietf-mmusic-sdp-mux-attributes].=C2=A0 But for other= security
=C2=A0 =C2=A0solutions, this may require further consideration.

=C2=A0 =C2=A0The identfication-tag, independent of transport, RTCP SDES pac= ket or
=C2=A0 =C2=A0RTP header extension, can expose the value to parties beyond t= he
 =C2=A0 =C2=A0signaling chain.=C2=A0 Therefore, the identification-tag value= s MUST be
=C2=A0 =C2=A0generated in a fashion that does not leak user information, e.= g.,
 =C2=A0 =C2=A0randomly or using a per-bundle group counter, and SHOULD be 3 = bytes
=C2=A0 =C2=A0or less, to allow them to efficiently fit into the MID RTP hea= der
=C2=A0 =C2=A0extension.=C2=A0 However, the implementation's method for = generating
=C2=A0 =C2=A0identification-tags could enable fingerprinting of the impleme= ntation
=C2=A0 =C2=A0making it vulnerable to targeted attacks.
<= div>
I would say "Note that if implementations use diffe= rent methods for generating
... this could..."
=C2= =A0
=C2=A0 The identic= ation-tag is

Still misspelled.

-Ekr
=C2=A0
=C2=A0 =C2=A0exposed on the RTP stream level when included in the RTP heade= r
=C2=A0 =C2=A0extensions, however what it reveals of the RTP media stream st= ructure
 =C2=A0 =C2=A0of the endpoint and application was already possible to deduce= from
=C2=A0 =C2=A0the RTP streams without the MID SDES header extensions.=C2=A0 = As the
=C2=A0 =C2=A0identification-tag is also used to route the media stream to t= he
=C2=A0 =C2=A0right application functionality it is also important that the = value
=C2=A0 =C2=A0received is the one intended by the sender, thus integrity and= the
=C2=A0 =C2=A0authenticity of the source are important to prevent denial of = service
 =C2=A0 =C2=A0on the application.=C2=A0 Existing SRTP configurations require= s integrity
=C2=A0 =C2=A0protection of both RTCP and RTP header extensions.

=C2=A0 =C2=A0"RTP Header Extension for the RTP Control Protocol (RTCP)= Source
=C2=A0 =C2=A0Description Items" [RFC7941] security consideration requi= res that
=C2=A0 =C2=A0when RTCP is confidentiality protected that any SDES RTP heade= r
=C2=A0 =C2=A0extension carrying an SDES item, like the MID RTP header exten= sion,
=C2=A0 =C2=A0is also protected using commensurate strength algorithms.=C2= =A0 However,
=C2=A0 =C2=A0assuming the above requirements and recommendations are follow= ed
=C2=A0 =C2=A0there are no known significant security risks with leaving the= MID
=C2=A0 =C2=A0RTP header extension without confidentiality protection.=C2=A0= Thus, the
=C2=A0 =C2=A0requirements in RFC 7941 MAY be ignored for the MID RTP header=
=C2=A0 =C2=A0extension.=C2=A0 Security mechanisms for RTP/RTCP are discusse= d in Options
=C2=A0 =C2=A0for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711= ] can
=C2=A0 =C2=A0provide the necessary security functions of ensuring the integ= rity
=C2=A0 =C2=A0and source authenticity.


Cheers

Magnus Westerlund

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


--94eb2c0873581c370d054a0ffdb8-- From nobody Mon Mar 6 05:49: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 1A2A112973A for ; Mon, 6 Mar 2017 05:49:52 -0800 (PST) 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 xXKOCHrum9kh for ; Mon, 6 Mar 2017 05:49:50 -0800 (PST) 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 85C661294DD for ; Mon, 6 Mar 2017 05:49:50 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id p77so119357014ywg.1 for ; Mon, 06 Mar 2017 05:49:50 -0800 (PST) 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=ziAWIjDEATtQGC4o0cbGkUtILqr5z1MHlvMFTUeHN2M=; b=izHlREigTA+f5kjiazIecCfYE3qwWB2a5RyatUUAYf+hOP2x+zH01Z0PB51Ym9hzJE DrGDXLpNMORIbd8IH0xJpCtcggvmOiLTB97zFTS5SgwcXQGhkpFMMUpFQp3kENXbQPQA IhTUvHJZEepSb4/++xM4dMHYX9mvYZzt2+H11XSFlmkBczcFGDBTpSUtF4cw8rbwiDla At7KLQN3pPo2CGY08YzFc+RiDx/6UPdOtQVDcKji1nectDhm0hHSBACYFuG7VXdvRuMv 7ZIx0+SITBaHCXDrMp3cv3JhfCIg0tbeXwwoyFqlk2qIUEvjEvGXHt9r7zsaYMI9IfDt 3y3A== 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=ziAWIjDEATtQGC4o0cbGkUtILqr5z1MHlvMFTUeHN2M=; b=ATxGfM0uJlCqZFe2w9AsEEmnEzcv6Jc6gRSISKW9/Vl7QGYWvBIJbhLcYcNIqeQb9z gjoi5jR+pgvp5ygrf39686MwObHK29ZqS/EPY7tt0iibDBlslJPRfLj4JQ9aJ43EPc8T JUA71NfqyJAtYIxN8UXfJlT/d+bETLTqxMnK+WobL5BEpZxq4kfaNgwm9lVvABA2QuXa iQTYa22pMwlQa8786Z1QIMyphMudXVZq2jCsCms6/qKOO++N7d9ZJuolRNMY9wh1RbQ9 9+wB7yetnBI3KPE5Egk//bCYhx+RoQbu2jvLnZ7vch9PV2mAlok14HYjDMVskH36eh2q ooAw== X-Gm-Message-State: AMke39lzi1ZmJR5AiI14A3y22LgT4zihfvqHmnyPAKyAXRhlN9b4eqjf5BaZWa4VNSjTRzUqT5gllRQcXDztqQ== X-Received: by 10.37.173.82 with SMTP id l18mr11845081ybe.107.1488808189688; Mon, 06 Mar 2017 05:49:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Mon, 6 Mar 2017 05:49:09 -0800 (PST) In-Reply-To: References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> From: Eric Rescorla Date: Mon, 6 Mar 2017 05:49:09 -0800 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f403045eb8ea4917d3054a102b10 Archived-At: Cc: Magnus Westerlund , "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 13:49:52 -0000 --f403045eb8ea4917d3054a102b10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 6, 2017 at 5:35 AM, I=C3=B1aki Baz Castillo wro= te: > 2017-03-03 14:24 GMT+01:00 Magnus Westerlund < > magnus.westerlund@ericsson.com>: > > When the BUNDLE extension is used, the number of SSRC values within a > single RTP session increases, which increases the risk of SSRC collision > > This is relevant when there are ~100000000 streams within a single RTP > session. If there are 10 streams, the exact risk is 10 / 2^32 =3D > 2.32e-09. > This actually isn't quite correct (this is just the usual birthday paradox math) Assuming I haven't made a mistake, the correct formula is: 1 - (\prod_{i=3D0}^{9} 2^{32} - i) I think we can live without having to mention this "issue" in every > RTP related specification. > I agree with you that this is a relatively small number, but that doesn't mean we don't need to consider it. For instance, if SRTP did not use directional keys and we allowed each side to choose SSRCs w/o any attempts to suppress collisions, there would be a small but non-zero number of calls which used a two-time pad on a daily basis. -Ekr > > To be clear: stating that "BUNDLE increases the risk of SSRC > collision" is a no sense IMHO. > > > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f403045eb8ea4917d3054a102b10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 6, 2017 at 5:35 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net= > wrote:
2017-03-03 14:24= GMT+01:00 Magnus Westerlund <magnus.westerlund@ericsson.com>:
> When the BUNDLE extension is used, the number of SSRC values within a = single RTP session increases, which increases the risk of SSRC collision
This is relevant when there are ~100000000 streams within a single R= TP
session. If there are 10 streams, the exact risk is 10 / 2^32 =3D
2.32e-09.

This actually isn't quite= correct (this is just the usual birthday paradox math)
Assuming = I haven't made a mistake, the correct formula is:

<= div>1 - (\prod_{i=3D0}^{9} 2^{32} - i)


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I think we can live without having to mention this "issue" in eve= ry
RTP related specification.

I agree with= you that this is a relatively small number, but that doesn't mean we d= on't
need to consider it. For instance, if SRTP did not use d= irectional keys and we allowed
each side to choose SSRCs w/o any = attempts to suppress collisions, there would
be a small but non-z= ero number of calls which used a two-time pad on a daily basis.
<= br>
-Ekr
=C2=A0

To be clear: stating that "BUNDLE increases the risk of SSRC
collision" is a no sense IMHO.




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

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

--f403045eb8ea4917d3054a102b10-- From nobody Mon Mar 6 07:23: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 064E41297ED for ; Mon, 6 Mar 2017 07:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 QRnraVFOiGQl for ; Mon, 6 Mar 2017 07:23:38 -0800 (PST) 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 C4ADC1293FB for ; Mon, 6 Mar 2017 07:23:37 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id v186so66801756wmd.0 for ; Mon, 06 Mar 2017 07:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3cGBPYB2zm9bzEQxgZ8C4iqEeTPLKXbVogAFd3T1uhA=; b=GXld69gvr+3cRvKBWp32LbVoXBbiJGPFm4s+S0X9aDoQ1IAbZ5PFpKrqed3XybBbpU B7Am3hk+eGbOeFYqJsqy1aLUiS6WP0VVuqtrw8PkrtFSxjTRtqeUv1FxyaL6iGk9hx5q nkCRAt3ZDR2boPWFpsmjxPJM2rGXVldsJB0h6H7eahMiN8zvX87Wtj38jOFim5T4SQSU 6wyxnRXjySzMITDZxBRFFkQVvToRBPrLSdhOyuHRrZZUJdOzQb6xFOQAMrUYcmRfg0GP rvhElZx6WZibCom6+96yq8a7plHJ+um17P53IhxoRq6qWx/oFiCPv120Q7QrFQdg4EqN k1jw== 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=3cGBPYB2zm9bzEQxgZ8C4iqEeTPLKXbVogAFd3T1uhA=; b=gAM43pxMl4KAB5DD28lxVMVVU4mfj7P1Tt3c82BprcgFc+bKzmIxVEm2DPvog+F2D6 0HW5U9iqfSYCtc5ob4xx2vvuJQHf3w/4l0eDscQAY4D1AftyyqKZKWRHJ/6+oRlN3wLn U9FfPHRTaFfjg4n3unnsNqEoHSCXqWCZENBYJ1pNH7BsxNYACwOuMt/iyVdUFqvFmVED nOmdUPgYBTE5IPqOCLYjAxxtJRR88mdNucnPsu6Jcb+kEOidgEKy5XPfa/90FaM0oZuy bNVQIFxls5tyW01cceLMTZ81pV53om67xWrc9/QCTKCQHU7l4UOlqgM0+yISLr2g21Kp njOw== X-Gm-Message-State: AMke39l4gWu1tYI5q2bsqdYOGpc2Gnp1UdkSjAWyTWMfxYgr7Q+7iebLW++IvSOS0COk10uhlWsQ6xgGgGxdXw== X-Received: by 10.28.48.67 with SMTP id w64mr14439381wmw.125.1488813816344; Mon, 06 Mar 2017 07:23:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 6 Mar 2017 07:23:15 -0800 (PST) In-Reply-To: References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 6 Mar 2017 16:23:15 +0100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Magnus Westerlund , "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 15:23:40 -0000 2017-03-06 14:49 GMT+01:00 Eric Rescorla : >> This is relevant when there are ~100000000 streams within a single RTP >> session. If there are 10 streams, the exact risk is 10 / 2^32 = >> 2.32e-09. > > > This actually isn't quite correct (this is just the usual birthday paradox > math) > Assuming I haven't made a mistake, the correct formula is: > > 1 - (\prod_{i=0}^{9} 2^{32} - i) Right :) From nobody Mon Mar 6 11:50: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 5F9AB1299BB for ; Mon, 6 Mar 2017 11:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 IEJf-mHgsbGl for ; Mon, 6 Mar 2017 11:50:16 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 062FB1299C0 for ; Mon, 6 Mar 2017 11:50:14 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-06v.sys.comcast.net with SMTP id kydmcmXLik7AGkye6ctKWg; Mon, 06 Mar 2017 19:50:14 +0000 Received: from hobgoblin.ariadne.com ([24.60.114.4]) by resomta-ch2-16v.sys.comcast.net with SMTP id kye4cWjH05g3vkye5cloX2; Mon, 06 Mar 2017 19:50:13 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v26JoCmM027415; Mon, 6 Mar 2017 14:50:12 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v26JoBof027412; Mon, 6 Mar 2017 14:50:11 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-Reply-To: (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 06 Mar 2017 14:50:11 -0500 Message-ID: <87zigychho.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfNv2NjJyN13BYzwRxIVE8ly10ow1TN0IBhI/JiE+mPJK/NG0mIkej1UqgTfTaoyUcM3t4oRFFkwDc1JjcQr5OA1U4leWY0uhDbqhpKmtCPHGn5pot4M1 MZ2U6Du+HbPgMFh6SGYDqX1tHaebNF2fIfJO+SXc+qLyxIV0UIqBqI5e3t7e8MuscOp18Tiv5lBYlDtfAbzv+9xhYDbChD5tC9w= Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] Definition of a=rid in draft-ietf-mmusic-rid-09 (was WGLC on draft-ietf-mmusic-sdp-simulcast-07) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Mar 2017 19:50:17 -0000 Paul Kyzivat writes: > On 3/3/17 10:56 AM, Dale R. Worley wrote: >> Inaki Baz Castillo writes: >>>> but according to https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 >>>> it seems that "direction" (send/recv) should be placed *before* >>>> "pt=xx": >>>> >>>> a=rid: [pt=;]=... >>> >>> In fact, pt=xx seems to be yet another "param". >> >> That purported BNF is really bizarre, since it generates the clearly >> incorrect form: > > IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not in > draft-ietf-mmusic-sdp-simulcast-07, right? > >> a=rid: == > > I'm not seeing how the ABNF generates that. What I'm commenting on is this line way back in the innermost quoted message >>>> a=rid: [pt=;]=... which was in turn quoted from draft-ietf-mmusic-rid-09. In BNF-like notations, "..." means "repetition of the preceding thing", which I took to mean repetition of "=". Although that's probably not the correct interpretation, and rather it means repetition of "". >> A correct description is: >> >> a=rid: ( pt= | = ) *( ; = ) > > ISTM the ABNF in the draft is equivalent to what you have written. > (Though yours is clearer.) What I don't see is why mmusic-rid-09 requires the pt restriction to be in first position. I'm not read into it, but it seems that there's no semantic reason why it must be first, and it makes the grammar messier to force it to be so. Without that restriction, you could just say >> a=rid: = *( ; = ) and allow pt to be one of the s. Dale From nobody Tue Mar 7 01:46: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 BEE85129477; Tue, 7 Mar 2017 01:46:19 -0800 (PST) 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 N7wHv02395NE; Tue, 7 Mar 2017 01:46:18 -0800 (PST) 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 9892E129466; Tue, 7 Mar 2017 01:46:17 -0800 (PST) X-AuditID: c1b4fb30-84e7298000007a5b-a4-58be8167da3b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 92.6F.31323.7618EB85; Tue, 7 Mar 2017 10:46:16 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.319.2; Tue, 7 Mar 2017 10:45:53 +0100 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> From: Magnus Westerlund Message-ID: Date: Tue, 7 Mar 2017 10:45:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2J7lG5G474Ig4+zmS1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8bbBomCvQ4V88+9ZmpgfGDYxcjJ ISFgIvH442kmEFtIYB2jxPtL6l2MXED2MkaJ/k9NbCAJYQEvibZtE5lBbBEBBYlff06wQBQ1 MEs8/jIZqIiDg1nAR2Lhs0SQGjYBC4mbPxrBenkF7CUmfD0GtoBFQEWivecAK4gtKhAjsbf/ PhNEjaDEyZlPWEBsToFAiW/fb4LVMAPNmTn/PCOELS/RvHU2M8Sh2hINTR2sExgFZiFpn4Wk ZRaSlgWMzKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAsPz4JbfBjsYXz53PMQowMGoxMNb ULk3Qog1say4MvcQowQHs5II756sfRFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhP LEnNTk0tSC2CyTJxcEo1MG7tn/Cz36vsA0/V8qULeNK2l8x7uzTTNXv2vds8xo/aM19V6Zw/ 9Z2rI5Upq+74Qm+JqYX+Dpz/nruf/Fl/de2x+Smv/F3mvH50wan1Vt+llPCdWrpbWFlqVkzt etd5MtWR65z3gfnFa3lFN0Rt23B3dolKhE32tudXSjbZu7w2/DBbOU87NluJpTgj0VCLuag4 EQBRRqQDSwIAAA== Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 09:46:20 -0000 Hi, Please see inline. Den 2017-03-06 kl. 14:36, skrev Eric Rescorla: > > I think you are correct assuming that one is using SRTP. All the > IETF key-management scheme follows this, although a=mikey is > IDENTICAL. If one uses other security mechanisms, then this is still > relevant to capture. > > > Which security mechanisms are you thinking of here? I didn't have any specific security mechanism in mind. I simply want to make clear the requirements that arises due to the new mechanisms that BUNDLE creates. As you commented I can only think of mechanism that protects the whole packet. > > > To avoid the security risks associated with tracking of > implementations, there is RECOMMENDED algorithm for generating > identification-tags in Section 14.1. > > See above. > > > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information > flows over the network but only changes which addresses and ports > that information is flowing on and thus has very little impact on the > security of the RTP sessions. > > > Is this precisely true? Do you ever use the MID extension w/o BUNDLE? > It certainly changes which ICE checks you do. > So lets start with the question of MID without using BUNDLE. As MID is used in grouping of media lines use cases, i.e. RFC 5888 there are certainly uses. However, there exist no need to signal MIDs on RTP session level in those cases as there already exist a one to one mapping between the MID and the transport addresses used for that RTP session. Only with BUNDLE do the RTP streams from the different m= lines start sharing transport context. So strictly the above is incorrect. What was multiple security context due to different RTP sessions, or other sessions are now moved into a single context. I think we could reformulate this to say: The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information, e.g. RTP streams, that flows over the network. Primarily it changes which addresses and ports, and thus in which (RTP) sessions that the information is flowing in. This affects the security contexts being used and can cause previously separated information flows to share security context. This has very little impact on the performance of the security mechanism of the RTP sessions, however which actors that are present in a particular security context may require additional thoughts when applying Bundle. Is this better? > > > When the BUNDLE extension is used, a single set of security > credentials might be used for all media streams specified by a BUNDLE > group. When using SRTP this is further required at least for the > IETF defined key-management solutions due to their SDP attributes > (a=crypto, a=fingerprint, a=mikey) classification in > [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security > solutions, this may require further consideration. > > The identfication-tag, independent of transport, RTCP SDES packet or > RTP header extension, can expose the value to parties beyond the > signaling chain. Therefore, the identification-tag values MUST be > generated in a fashion that does not leak user information, e.g., > randomly or using a per-bundle group counter, and SHOULD be 3 bytes > or less, to allow them to efficiently fit into the MID RTP header > extension. However, the implementation's method for generating > identification-tags could enable fingerprinting of the implementation > making it vulnerable to targeted attacks. > > > I would say "Note that if implementations use different methods for > generating > ... this could..." > Yes, I will use this. > > The identication-tag is > > > Still misspelled. Yes, there was actually two misspelled instances left, and I had corrected one. Full section text after corrections: 16. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information, e.g. RTP streams, that flows over the network. Primarily it changes which addresses and ports, and thus in which (RTP) sessions that the information is flowing in. This affects the security contexts being used and can cause previously separated information flows to share security context. This has very little impact on the performance of the security mechanism of the RTP sessions, however which actors that are present in a particular security context may require additional thoughts when applying Bundle. When the BUNDLE extension is used, a single set of security credentials might be used for all media streams specified by a BUNDLE group. When using SRTP this is further required at least for the IETF defined key-management solutions due to their SDP attributes (a=crypto, a=fingerprint, a=mikey) classification in [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security solutions, this may require further consideration. The identification-tag, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-bundle group counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension. Note that if implementations use different methods for generating identification-tags this could enable fingerprinting of the implementation making it vulnerable to targeted attacks. The identification-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduce from the RTP streams without the MID SDES header extensions. As the identification-tag is also used to route the media stream to the right application functionality it is also important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. Existing SRTP configurations requires integrity protection of both RTCP and RTP header extensions. "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] security consideration requires that when RTCP is confidentiality protected that any SDES RTP header extension carrying an SDES item, like the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Mar 7 09:47: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 A352F1295EF for ; Tue, 7 Mar 2017 09:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 R02Vsrxu4iFm for ; Tue, 7 Mar 2017 09:47:49 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 1C5D01295EE for ; Tue, 7 Mar 2017 09:47:49 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id i1so11106715ota.3 for ; Tue, 07 Mar 2017 09:47:49 -0800 (PST) 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=0tBl0k/L5+Z97F15HoA4dPpXAG6g35kmgVfN6biFrpw=; b=tpG9+MB07zigrnrif4tvQo3vbDEcs0okipgmUc8MpGI9gpNCWB80Xku75xs0cjkXBu TtwGLB/j6pZpsc8losPKP/m0b83dcjLQCZ+oVU7nqgNamjVbqCMhYs+JaLNPM/e0USyl 2oq1gsxXdVAuOWlFMHFA0Tdo/2581IW/3q0rK3ZIepisHyfs+izdenL0fhaKZ3MrLFoX cM9iWr6HsauWoUtLgfBcKI87b6GZwLQ7Mo/BlxPJm/RCYzdx6DGkGSc4oXcnkk/6xqeq jFtC1GzxiN+hLMo6FdSPx2VM+jM4SjUOlCcjGUFC9FUnFKbi0OgBP5KvnquK90/eFPsq /jhA== 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=0tBl0k/L5+Z97F15HoA4dPpXAG6g35kmgVfN6biFrpw=; b=izAOZLljO/fZ7pDGaQ24M19DlMKFy5fpb7u2pK441IyBol0NeMYPvAtYV95XiFzMj1 rAR3+oUT0+9kgLGtgk4O0DLe2WnkaZLMzPaxbAATmlRczhDFfOfydz/TDcEwkM4g+Ncm pJVTAvb9TyV2JuV1SJkKt3q64Eot9Aw003qcyPrxGE1rcS8DJM96fSt8Kex7GvFquXM2 zk238rbznle3MQj7bowvOtTpsL5MFRnlhhZ2q0iRyJn18RaKeoNBhbmYvp0Rqk4/lIbH VRJz9+imzRNPrnfoPRlyDoRmJfo32uNMhr3TpP7hJTjd2X115Og4r0XKysVxci/O1Au2 K2Tw== X-Gm-Message-State: AMke39kCevCnUDsKRTlYhgrISg/MkYqO8C4i0EIJQznBJajR9MYjZsUT8VRiLKt6DsRIv/sclIOlEOk/saUigg== X-Received: by 10.129.177.8 with SMTP id p8mr431038ywh.327.1488908868404; Tue, 07 Mar 2017 09:47:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 7 Mar 2017 09:47:07 -0800 (PST) In-Reply-To: References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> From: Eric Rescorla Date: Tue, 7 Mar 2017 09:47:07 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c13ce38346e50054a279cce Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 17:47:50 -0000 --94eb2c13ce38346e50054a279cce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Please see inline. > > Den 2017-03-06 kl. 14:36, skrev Eric Rescorla: > >> >> I think you are correct assuming that one is using SRTP. All the >> IETF key-management scheme follows this, although a=3Dmikey is >> IDENTICAL. If one uses other security mechanisms, then this is still >> relevant to capture. >> >> >> Which security mechanisms are you thinking of here? >> > > I didn't have any specific security mechanism in mind. I simply want to > make clear the requirements that arises due to the new mechanisms that > BUNDLE creates. As you commented I can only think of mechanism that > protects the whole packet. Yeah, this seems more confusing than illuminating. There are lots of theoretical risks that might happen if we had some new security mechanism with unknown properties. Is this precisely true? Do you ever use the MID extension w/o BUNDLE? >> It certainly changes which ICE checks you do. >> >> > So lets start with the question of MID without using BUNDLE. As MID is > used in grouping of media lines use cases, i.e. RFC 5888 there are > certainly uses. However, there exist no need to signal MIDs on RTP sessio= n > level in those cases as there already exist a one to one mapping between > the MID and the transport addresses used for that RTP session. Only with > BUNDLE do the RTP streams from the different m=3D lines start sharing > transport context. > That's what I meant by "MID extension". Sorry for the confusion. So strictly the above is incorrect. What was multiple security context due > to different RTP sessions, or other sessions are now moved into a single > context. I think we could reformulate this to say: > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information, > e.g. RTP streams, that flows over the network. Primarily it changes > which addresses and ports, and thus in which (RTP) sessions that the > information is flowing in. This affects the security contexts being > used and can cause previously separated information flows to share > security context. This has very little impact on the performance of > the security mechanism of the RTP sessions, however which actors that > are present in a particular security context may require additional > thoughts when applying Bundle. > > Is this better? But it still seems to be false because of the MID signaling in SDP. I also don't understand the last line. -Ekr > The identication-tag is >> >> >> Still misspelled. >> > > Yes, there was actually two misspelled instances left, and I had correcte= d > one. > > Full section text after corrections: > > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information, > e.g. RTP streams, that flows over the network. Primarily it changes > which addresses and ports, and thus in which (RTP) sessions that the > information is flowing in. This affects the security contexts being > used and can cause previously separated information flows to share > security context. This has very little impact on the performance of > the security mechanism of the RTP sessions, however which actors that > are present in a particular security context may require additional > thoughts when applying Bundle. > > When the BUNDLE extension is used, a single set of security > credentials might be used for all media streams specified by a BUNDLE > group. When using SRTP this is further required at least for the > IETF defined key-management solutions due to their SDP attributes > (a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) classification in > [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security > solutions, this may require further consideration. > > The identification-tag, independent of transport, RTCP SDES packet or > RTP header extension, can expose the value to parties beyond the > signaling chain. Therefore, the identification-tag values MUST be > generated in a fashion that does not leak user information, e.g., > randomly or using a per-bundle group counter, and SHOULD be 3 bytes > or less, to allow them to efficiently fit into the MID RTP header > extension. Note that if implementations use different methods for > generating identification-tags this could enable fingerprinting of > the implementation making it vulnerable to targeted attacks. The > identification-tag is exposed on the RTP stream level when included > in the RTP header extensions, however what it reveals of the RTP > media stream structure of the endpoint and application was already > possible to deduce from the RTP streams without the MID SDES header > extensions. As the identification-tag is also used to route the > media stream to the right application functionality it is also > important that the value received is the one intended by the sender, > thus integrity and the authenticity of the source are important to > prevent denial of service on the application. Existing SRTP > configurations requires integrity protection of both RTCP and RTP > header extensions. > > "RTP Header Extension for the RTP Control Protocol (RTCP) Source > Description Items" [RFC7941] security consideration requires that > when RTCP is confidentiality protected that any SDES RTP header > extension carrying an SDES item, like the MID RTP header extension, > is also protected using commensurate strength algorithms. However, > assuming the above requirements and recommendations are followed > there are no known significant security risks with leaving the MID > RTP header extension without confidentiality protection. Thus, the > requirements in RFC 7941 MAY be ignored for the MID RTP header > extension. Security mechanisms for RTP/RTCP are discussed in Options > for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can > provide the necessary security functions of ensuring the integrity > and source authenticity. > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c13ce38346e50054a279cce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund <= ;magnus= .westerlund@ericsson.com> wrote:
Hi,

Please see inline.

Den 2017-03-06 kl. 14:36, skrev Eric Rescorla:

=C2=A0 =C2=A0 I think you are correct assuming that one is using SRTP. All = the
=C2=A0 =C2=A0 IETF key-management scheme follows this, although a=3Dmikey i= s
=C2=A0 =C2=A0 IDENTICAL. If one uses other security mechanisms, then this i= s still
=C2=A0 =C2=A0 relevant to capture.


Which security mechanisms are you thinking of here?

 I didn't have any specific security mechanism in mind. I simply want to= make clear the requirements that arises due to the new mechanisms that BUN= DLE creates. As you commented I can only think of mechanism that protects t= he whole packet.

Yeah, this seems more conf= using than illuminating. There are lots of theoretical
risks that= might happen if we had some new security mechanism with unknown
= properties.



Is this precisely true? Do you ever use the MID extension w/o BUNDLE?
It certainly changes which ICE checks you do.


 So lets start with the question of MID without using BUNDLE. As MID is used= in grouping of media lines use cases, i.e. RFC 5888 there are certainly us= es. However, there exist no need to signal MIDs on RTP session level in tho= se cases as there already exist a one to one mapping between the MID and th= e transport addresses used for that RTP session. Only with BUNDLE do the RT= P streams from the different m=3D lines start sharing transport context.

That's what I meant by "MID exte= nsion". Sorry for the confusion.



So strictly the above is incorrect. What was multiple security context due = to different RTP sessions, or other sessions are now moved into a single co= ntext. I think we could reformulate this to say:

=C2=A0 =C2=A0The security considerations defined in [RFC3264] and [RFC5888]= apply
 =C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not change which in= formation,
=C2=A0 =C2=A0e.g.=C2=A0 RTP streams, that flows over the network.=C2=A0 Pri= marily it changes
=C2=A0 =C2=A0which addresses and ports, and thus in which (RTP) sessions th= at the
=C2=A0 =C2=A0information is flowing in.=C2=A0 This affects the security con= texts being
=C2=A0 =C2=A0used and can cause previously separated information flows to s= hare
=C2=A0 =C2=A0security context.=C2=A0 This has very little impact on the per= formance of
=C2=A0 =C2=A0the security mechanism of the RTP sessions, however which acto= rs that
=C2=A0 =C2=A0are present in a particular security context may require addit= ional
=C2=A0 =C2=A0thoughts when applying Bundle.

Is this better?

But it still seems to be fa= lse because of the MID signaling in SDP.
=C2=A0
I also = don't understand the last line.=C2=A0

-Ekr
=C2=A0
=C2=A0 =C2=A0 =C2=A0 The identication-tag is


Still misspelled.

 Yes, there was actually two misspelled instances left, and I had corrected = one.

Full section text after corrections:

16.=C2=A0 Security Considerations

=C2=A0 =C2=A0The security considerations defined in [RFC3264] and [RFC5888]= apply
 =C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not change which in= formation,
=C2=A0 =C2=A0e.g.=C2=A0 RTP streams, that flows over the network.=C2=A0 Pri= marily it changes
=C2=A0 =C2=A0which addresses and ports, and thus in which (RTP) sessions th= at the
=C2=A0 =C2=A0information is flowing in.=C2=A0 This affects the security con= texts being
=C2=A0 =C2=A0used and can cause previously separated information flows to s= hare
=C2=A0 =C2=A0security context.=C2=A0 This has very little impact on the per= formance of
=C2=A0 =C2=A0the security mechanism of the RTP sessions, however which acto= rs that
=C2=A0 =C2=A0are present in a particular security context may require addit= ional
=C2=A0 =C2=A0thoughts when applying Bundle.

=C2=A0 =C2=A0When the BUNDLE extension is used, a single set of security =C2=A0 =C2=A0credentials might be used for all media streams specified by a= BUNDLE
=C2=A0 =C2=A0group.=C2=A0 When using SRTP this is further required at least= for the
=C2=A0 =C2=A0IETF defined key-management solutions due to their SDP attribu= tes
=C2=A0 =C2=A0(a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) classification in
=C2=A0 =C2=A0[I-D.ietf-mmusic-sdp-mux-attributes].=C2=A0 But for other= security
=C2=A0 =C2=A0solutions, this may require further consideration.

 =C2=A0 =C2=A0The identification-tag, independent of transport, RTCP SDES pa= cket or
=C2=A0 =C2=A0RTP header extension, can expose the value to parties beyond t= he
=C2=A0 =C2=A0signaling chain.=C2=A0 Therefore, the identification-tag value= s MUST be
=C2=A0 =C2=A0generated in a fashion that does not leak user information, e.= g.,
=C2=A0 =C2=A0randomly or using a per-bundle group counter, and SHOULD be 3 = bytes
=C2=A0 =C2=A0or less, to allow them to efficiently fit into the MID RTP hea= der
 =C2=A0 =C2=A0extension.=C2=A0 Note that if implementations use different me= thods for
=C2=A0 =C2=A0generating identification-tags this could enable fingerprintin= g of
=C2=A0 =C2=A0the implementation making it vulnerable to targeted attacks.= =C2=A0 The
=C2=A0 =C2=A0identification-tag is exposed on the RTP stream level when inc= luded
=C2=A0 =C2=A0in the RTP header extensions, however what it reveals of the R= TP
=C2=A0 =C2=A0media stream structure of the endpoint and application was alr= eady
 =C2=A0 =C2=A0possible to deduce from the RTP streams without the MID SDES h= eader
=C2=A0 =C2=A0extensions.=C2=A0 As the identification-tag is also used to ro= ute the
=C2=A0 =C2=A0media stream to the right application functionality it is also=
=C2=A0 =C2=A0important that the value received is the one intended by the s= ender,
=C2=A0 =C2=A0thus integrity and the authenticity of the source are importan= t to
=C2=A0 =C2=A0prevent denial of service on the application.=C2=A0 Existing S= RTP
=C2=A0 =C2=A0configurations requires integrity protection of both RTCP and = RTP
=C2=A0 =C2=A0header extensions.

=C2=A0 =C2=A0"RTP Header Extension for the RTP Control Protocol (RTCP)= Source
=C2=A0 =C2=A0Description Items" [RFC7941] security consideration requi= res that
=C2=A0 =C2=A0when RTCP is confidentiality protected that any SDES RTP heade= r
=C2=A0 =C2=A0extension carrying an SDES item, like the MID RTP header exten= sion,
=C2=A0 =C2=A0is also protected using commensurate strength algorithms.=C2= =A0 However,
=C2=A0 =C2=A0assuming the above requirements and recommendations are follow= ed
=C2=A0 =C2=A0there are no known significant security risks with leaving the= MID
=C2=A0 =C2=A0RTP header extension without confidentiality protection.=C2=A0= Thus, the
=C2=A0 =C2=A0requirements in RFC 7941 MAY be ignored for the MID RTP header=
=C2=A0 =C2=A0extension.=C2=A0 Security mechanisms for RTP/RTCP are discusse= d in Options
=C2=A0 =C2=A0for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711= ] can
=C2=A0 =C2=A0provide the necessary security functions of ensuring the integ= rity
=C2=A0 =C2=A0and source authenticity.


 --

Magnus Westerlund

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


--94eb2c13ce38346e50054a279cce-- From nobody Wed Mar 8 21:07: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 30AEC1293E1 for ; Wed, 8 Mar 2017 21:07:00 -0800 (PST) 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, 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=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 zxm1Tkq-K5jP for ; Wed, 8 Mar 2017 21:06:59 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 247D4124281 for ; Wed, 8 Mar 2017 21:06:59 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id v125so101056620qkh.2 for ; Wed, 08 Mar 2017 21:06:59 -0800 (PST) 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=yQc+HicpkIcBdWfaZPBsPI44C3BFvl8xYSqv0ijkQjg=; b=GUxUY2FJyJg6vlQtFkh86Ke+l40hQl9hpviukya+Isa/wPKb1DDcSdu3ltNZpHgKOm HN0mGmbVpiJontbTrIm0zzu5ctL612yaVWP9uM/X5q9Y1YIJVJm6/WE51FysTQJATS6t cuIM4IAumo8z2Oq0de/APbZDrctynMQdB6vKw4MeHRd+BU7J3HK0ZaxRREDp02vvDqQ5 nUbA84Fd39WoR2W3bz4KEny1EywTsauuRYwNxbe0XeGNDCFv/J7iHTQGHZ4khtC7ZSYU VkYLDR+ihvLMIy7JVuABHni+mMHcl4qIBIvATnj3H2lnv9ysGeQTbQ60AxiVii2ekKk5 NI2A== 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=yQc+HicpkIcBdWfaZPBsPI44C3BFvl8xYSqv0ijkQjg=; b=VODvSkKlD0rmGLgFcvRhI55D71XzNrY+9PDlc3I+c+EKq00waf8TBcoOtYQt4jXVe4 G4xOi38zK5iPSMrd7wLhIEsJC5kcybbIQS5Kot+o5P4WVZGlfOwKHhTfKZ6ODblGqxIi gnkNEDjqAp/wp+wlIFWXeKcKCsMJLecrqRAastH5cipWZstxt1G+cEfMi3wPRrC+rVOG 5ml2juLqgWr6ZVYtaC3r7akiH6SSnumCUp09BrwCizZBwQoF8gqQmpPYTPonPMUWbz2X A/1T9JUgpW7/BCILmdle0toVoL0FeBGTafl50/9JZTRMx79UQg/oVAXCtAkQrgh3su3m mA/A== X-Gm-Message-State: AFeK/H1I4j76AuEBx7gnLoCabfQehiTaiC6EDOPUT/1JUsYa8AQmd92zuaAT7Odm5jI4QGvUbqU1Wz6lod35Hw== X-Received: by 10.55.27.219 with SMTP id m88mr11383143qkh.147.1489036018215; Wed, 08 Mar 2017 21:06:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Mar 2017 21:06:57 -0800 (PST) From: Martin Thomson Date: Thu, 9 Mar 2017 16:06:57 +1100 Message-ID: To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 05:07:00 -0000 Can I request the following change to the dtls-sdp doc: OLD: dtls-id-value = 6*256(dtls-id-char) NEW: dtls-id-value = 6*255(dtls-id-char) I want to put this in a DTLS extension (see draft-thomson-avtcore-sdp-uks; it would replace the session id that I originally used) and a value that tops out at 256 requires a whole extra length byte. From nobody Wed Mar 8 22:30:55 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 37D811293F9 for ; Wed, 8 Mar 2017 22:30:54 -0800 (PST) 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 HktnYfUXiKEX for ; Wed, 8 Mar 2017 22:30:53 -0800 (PST) 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 B7589126D73 for ; Wed, 8 Mar 2017 22:30:52 -0800 (PST) X-AuditID: c1b4fb3a-29b639800000484c-02-58c0f69a187a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 58.6D.18508.A96F0C85; Thu, 9 Mar 2017 07:30:50 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 07:31:00 +0100 From: Christer Holmberg To: Martin Thomson , "mmusic@ietf.org" Thread-Topic: [MMUSIC] late dtls-id request Thread-Index: AQHSmJL+8NznZvzlM0+mOBw/rTGY+6GMHceA Date: Thu, 9 Mar 2017 06:30:48 +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.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-ID: <856FC9A6EF1E4B4CAD9468BD4F590B50@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7t+6sbwciDFpn21hcO/OP0WLq8scs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAldG07/5bAXL2Cr+H8psYGxi7WLk5JAQMJE4 +fIDYxcjF4eQwDpGiRO/FjFDOIsYJa69bwZyODjYBCwkuv9pgzSICIRITHy+jAXEFhbQktjx fzYTRFxb4uCsDnYI20ji0OHNjCCtLAIqEr9WiIKYvALWEjce6IFUCAkESBw/fZ4RxOYUCJS4 s30SWCejgJjE91NrwCYyC4hL3HoynwniTAGJJXvOM0PYohIvH/8DO19UQE9i+fM1UHEliR8b LrFA9OpILNj9iQ3CtpY4cuQYlK0tsWzha7B6XgFBiZMzn7BMYBSbhWTdLCTts5C0z0LSPgtJ +wJG1lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgRF1cMtvqx2MB587HmIU4GBU4uEtkDkQ IcSaWFZcmXuIUYKDWUmEd9cloBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNT UwtSi2CyTBycUg2MjL0zdJ7k7ZQK4lzo2OB36ciXDi/zcqt5surzTkYpLmKao+/AYmOjc1A6 f4W1mmD1m/cdlQbL3W5uSFNjt+ZtMPdZpjfr/qdXD5VSagq4hBKlPZZGmP+bWuYpkn1rZ0DO XR6pf5ckUvelHH+SzufWed2IYf+k2hixql3T34tblN3ZXWVq46vEUpyRaKjFXFScCADtxAjf pAIAAA== Archived-At: Subject: Re: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 06:30:54 -0000 Hi Martin, I have received the same request off-line, so unless someone objects I am ok to do the change. Regards, Christer On 09/03/17 07:06, "mmusic on behalf of Martin Thomson" wrote: >Can I request the following change to the dtls-sdp doc: > >OLD: > dtls-id-value =3D 6*256(dtls-id-char) >NEW: > dtls-id-value =3D 6*255(dtls-id-char) > >I want to put this in a DTLS extension (see >draft-thomson-avtcore-sdp-uks; it would replace the session id that I >originally used) and a value that tops out at 256 requires a whole >extra length byte. > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Mar 8 22:57: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 1085C127078 for ; Wed, 8 Mar 2017 22:57:40 -0800 (PST) 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 leXVdRKmv6hu for ; Wed, 8 Mar 2017 22:57:38 -0800 (PST) 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 E8797126B6D for ; Wed, 8 Mar 2017 22:57:37 -0800 (PST) X-AuditID: c1b4fb2d-2eaca9800000290a-05-58c0fcdfb358 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id B8.96.10506.FDCF0C85; Thu, 9 Mar 2017 07:57:36 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 07:57:33 +0100 From: Christer Holmberg To: Christer Holmberg , Martin Thomson , "mmusic@ietf.org" Thread-Topic: [MMUSIC] late dtls-id request Thread-Index: AQHSmJL+8NznZvzlM0+mOBw/rTGY+6GMHceAgAAHeYA= Date: Thu, 9 Mar 2017 06:57:32 +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.1.161129 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <5CDF8270F3B3804C99A8E07F65392E0F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7tO6DPwciDG7tYLW4duYfo8XU5Y9Z HJg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6M21P/Mhfc46rY1vqGpYHxDkcXIyeHhICJ xIVJ71m7GLk4hATWMUqs3b6cESQhJLCIUWLKL9EuRg4ONgELie5/2iA1IgIdjBILrl1nAakR FtCS2PF/NhOILSKgLXFwVgc7hG0lsfjeDbAaFgEViUXzDjOD2LwC1hLTPzewQyxrYpRY/PAZ 2DJOARuJuXvbwJoZBcQkvp9aAzaUWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4gtKqAnsfz5 Gqi4okT70wZGiF4diQW7P7FB2NYSbXvWQMW1JZYtfA11kKDEyZlPWCYwis1Csm4WkvZZSNpn IWmfhaR9ASPrKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAyDq45bfuDsbVrx0PMQpwMCrx 8BbIHIgQYk0sK67MPcQowcGsJMK76xJQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLp iSWp2ampBalFMFkmDk6pBkZ/37j11j+fKl/RsDuV80Us0UXh3ta+wIijH26uPPJoooL7MQuF +TfYFs5MSmbL9wiw0vnE1cfdJTV5YsMvodtrywJOvuuvY+dSUq9I1/T7MrMy44Gkj/j1D2lr pvd5rpNYdm3Tp3dxgS/msfeFn9+tc0gm8vOzq3ItLOcd38Svm1F+yyXz5xElluKMREMt5qLi RADwjxvOqAIAAA== Archived-At: Subject: Re: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 06:57:40 -0000 Hi, Just some background: the reason we used 256 was because that is what ICE uses for the password and ufrag, as it is assumed to provide good enough uniqueness. But, I assume we can make that assumption also with 255. Regards, Chorister On 09/03/17 08:30, "mmusic on behalf of Christer Holmberg" wrote: >Hi Martin, > >I have received the same request off-line, so unless someone objects I am >ok to do the change. > >Regards, > >Christer > > >On 09/03/17 07:06, "mmusic on behalf of Martin Thomson" > wrote: > >>Can I request the following change to the dtls-sdp doc: >> >>OLD: >> dtls-id-value =3D 6*256(dtls-id-char) >>NEW: >> dtls-id-value =3D 6*255(dtls-id-char) >> >>I want to put this in a DTLS extension (see >>draft-thomson-avtcore-sdp-uks; it would replace the session id that I >>originally used) and a value that tops out at 256 requires a whole >>extra length byte. >> >>_______________________________________________ >>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 Mar 8 23:15: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 0A4A9129412 for ; Wed, 8 Mar 2017 23:15:10 -0800 (PST) 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 gdR9BrxSZN2s for ; Wed, 8 Mar 2017 23:15:08 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C63129406 for ; Wed, 8 Mar 2017 23:15:08 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id p64so106200340qke.1 for ; Wed, 08 Mar 2017 23:15:08 -0800 (PST) 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=4Y3rToVTJQdxNuFEk/NzCqwkKZiQcfsNhPaVC+UBN3Q=; b=CM6TBFTT4aVf8teoj/k88u/439JzjUEW3yy1SG8ArojDkPrf0zRFN7Oy/WBpyVGUSR 5webbER/sAh2Y+AXI68d8mSwBBu2JGbJmz/FweJow8GALHHCoZMphqhnNliRTl/y2jlM Y2mKsjPah8j+MURoGFekpWBXEkZxeg2pqhZ25sPcGTG2rnPOzUCW4gqNiKP267rr+yWu +lWjWD2C56jepMZcxZDr4+jpD0pKE85mc6K3T1Op3OW6k7f0lGaKFsxaffDX0MJaTg2i +Ih0S6E6ssHRqUUMprC90bI6X/s6uhOaC8tr2UOKJzCZwfqlEUWQchkLB0FLD7BN+56+ gQSA== 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=4Y3rToVTJQdxNuFEk/NzCqwkKZiQcfsNhPaVC+UBN3Q=; b=L1Z2rCda8UOL+oodvSNgksKg0NTNCoHPwzMR04rLPboS+SS7lkgw0dUk2MVvedsf8C 5xRYJon/0fz/81zv65/VJYRP/DorjRbAiGrhGySOS9GAzFavstTCF1lJNEvQ5kfk+8eg pWwc2HrVXDrdDrvy3eja/d2yvUgc1Jj9f3rTArMnjbMnxGztY5OQcOov2moVjit3zQUy LE0znw+3PIINm95dJ8VWfnn5X4J1R6YYKG8WH+Oy5mInMCvLYgJAVk0rQh8xC2VazKxU 2INLp+38Hq2kSPAhkCqALNUWspX6W0s26tBIOhjPUkZ00ps2aX8ltxLzi2iVsSZkp40F hHhA== X-Gm-Message-State: AMke39kR47WyFyc5LJLVurRpy8rI2zaNkZSgkZLTx7c7bIC5Mihjf5aGPRHkEG/wpQA5R0DcmWDMvLzN/qciFQ== X-Received: by 10.237.41.100 with SMTP id s91mr13309966qtd.143.1489043707869; Wed, 08 Mar 2017 23:15:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Mar 2017 23:15:07 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 9 Mar 2017 18:15:07 +1100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 07:15:10 -0000 On 9 March 2017 at 17:57, Christer Holmberg wrote: > But, I assume we can make that assumption also with 255. For that, 20 would be plenty. Note that you only require 32 bits of randomness (which fits in the minimum of 6 characters), which is not quite enough to provide global-scale uniqueness. 20 pretty much is going to do that (assuming 6 bits per character, which base64 would allow). FWIW, I would be happier if you moved the 32 bit requirement to 120 and raised the minimum to 20, but that's a much bigger change. From nobody Thu Mar 9 03:20:25 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 92A0A12950A; Thu, 9 Mar 2017 03:20:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148905842456.5718.7149383510837307885@ietfa.amsl.com> Date: Thu, 09 Mar 2017 03:20:24 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-24.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:20:24 -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 of the IETF. Title : Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. Authors : Christer Holmberg Roman Shpount Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-24.txt Pages : 26 Date : 2017-03-09 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 9 03:21: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 A0B7D129537; Thu, 9 Mar 2017 03:21:33 -0800 (PST) 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 EhW3sbZ76pQ4; Thu, 9 Mar 2017 03:21:31 -0800 (PST) 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 EF5E712950A; Thu, 9 Mar 2017 03:21:30 -0800 (PST) X-AuditID: c1b4fb2d-2eaca9800000290a-98-58c13ab8edd6 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 46.39.10506.8BA31C85; Thu, 9 Mar 2017 12:21:29 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 12:21:27 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount , Ben Campbell Thread-Topic: =?windows-1254?Q?Mirja_K=FChlewind's_Discuss_on_draft-ietf-mmusic-sctp-sd?= =?windows-1254?Q?p-23:_(with_DISCUSS)?= Thread-Index: AQHSiEaxS+qNKsn/A0y+WNY+OfKww6Frs1fQ///1IwCAABFeUP//8EEAgAAA4YCAAAH3gIAAE4kggAAVhACABDfnAIAAQksAgAAt4QCAAR3EAIAAFWGAgAtEKQCAA+rWgIAAKSkAgAB2+4CABii+AIAE5n+A Date: Thu, 9 Mar 2017 11:21:27 +0000 Message-ID: References: <148724403323.15929.1432579178871938006.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4C0040D6@ESESSMB209.ericsson.se> <9F29D433-0AE1-43B0-B13E-AEC2861DFE75@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00438C@ESESSMB209.ericsson.se> <81A8D5E0-6641-4136-AFE6-74D3C49C7707@kuehlewind.net> <7594FB04B1934943A5C02806D1A2204B4C00443C@ESESSMB209.ericsson.se> <41D72B07-0B15-47A9-A118-5C67670F9F4F@kuehlewind.net> <1E30B705-9E74-4460-87D8-1395925B74F8@kuehlewind.net> <86C5D8B5-40B6-4228-BF10-00BF9DFEB93C@nostrum.com> <492F1BF9-2F1C-4D16-8B9B-B9FD13592E13@kuehlewind.net> <6366ADF1-E3E4-4C91-8579-85246D3E3714@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.1.161129 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D4E707E519117christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUyM2K7uu5Oq4MRBt27OS3md55mt3i1bj6z xYrX59gt3l/QtZjxZyKzxYvrH5ktzu9cz2QxdfljFovrT3exOHB6TPm9kdVjyZKfTB4tHxey esza+YTFY/LjNmaPrX//sgWwRXHZpKTmZJalFunbJXBlrP/xnLlgzUTGit1zj7A3MP6o72Lk 5JAQMJG4fWk9WxcjF4eQwDpGiScfvrBCOIsYJa49fs/SxcjBwSZgIdH9TxskLiLQxChxacsb sA5mgV1MEle+3GUHcYRBMltWPmKGKGtmlFj3bS87hLOKUeLj6sssIBtZBFQk/izexA5i8wpY S0xq2QUWFxKYwinx5acaiM0pYCPx/EEfM4jNKCAm8f3UGiYQm1lAXOLWk/lMEJcLSCzZc54Z whaVePn4HyuILSqgJ7H8+RqouKJE+9MGRojeBIm2p+9YIfYKSpyc+YRlAqPoLCRjZyEpm4Wk DCJuIHHk3E1WCFtbYtnC18wQtr7EvAUboGqsJZasf8SOrGYBI8cqRtHi1OLi3HQjY73Uoszk 4uL8PL281JJNjMD4P7jlt+4OxtWvHQ8xCnAwKvHwFsgciBBiTSwrrsw9xCjBwawkwrvrElCI NyWxsiq1KD++qDQntfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGRrZbSS853gg+ D1laO1/tUIjte/d9dhb/n5174+Rs+HfL2lNX1VKu89Y1sE6puXKup8k6WNHW5+Jx2aUdM3YV SF5cMTXp8fXujlq5tZkLt107tkRPcGqy9bNtbHsWPmSS8f36cMWnTSzLT7xSMf1fYfnAcZpq W8cdzbqYI8eeO2psvZBX9C3ssqESS3FGoqEWc1FxIgAW//4E+wIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" , "mmusic@ietf.org" , "fandreas@cisco.com" , Mirja Kuehlewind , The IESG , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: Re: [MMUSIC] =?cp1254?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ietf-m?= =?cp1254?q?music-sctp-sdp-23=3A_=28with_DISCUSS=29?= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 11:21:33 -0000 --_000_D4E707E519117christerholmbergericssoncom_ Content-Type: text/plain; charset="windows-1254" Content-Transfer-Encoding: quoted-printable Hi, Based on Roman=92s pull request, I have submitted a new version (-24) of dr= aft-ietf-mmusic-sctp-sdp. Regards, Christer From: Christer Holmberg > Date: Monday 6 March 2017 at 10:31 To: Christer Holmberg >, Roman Shpount >, Ben Campbell > Cc: Mirja Kuehlewind >, "mm= usic-chairs@ietf.org" >, Eric Rescorla >, "mmusic@ietf.org" >, Flemming Andreasen >, "iesg@ietf.org" >, "draft-ietf-mmusic-sctp-sdp@ietf.org" > Subject: Re: Mirja K=FChlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: = (with DISCUSS) Hi, I haven=92t seen any objections to Roman=92s pull request, so I intend to m= erge it and submit a new version of the draft. Regards, Christer From: Christer Holmberg > Date: Thursday 2 March 2017 at 12:28 To: Roman Shpount >, Ben Campbell > Cc: Mirja Kuehlewind >, "mm= usic-chairs@ietf.org" >, Eric Rescorla >, "mmusic@ietf.org" >, Flemming Andreasen >, "iesg@ietf.org" >, "draft-ietf-mmusic-sctp-sdp@ietf.org" > Subject: Re: Mirja K=FChlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: = (with DISCUSS) Resent-From: > Resent-To: Gonzalo Camarillo >, Salvatore Loreto >, Christer Holmberg > Resent-Date: Thursday 2 March 2017 at 12:28 Hi, There may be some minor editorial nits, but in general I am ok with the pul= l request. Regards, Christer From: Roman Shpount > Date: Thursday 2 March 2017 at 07:25 To: Ben Campbell > Cc: Christer Holmberg >, Mirja Kuehlewind >, "mmusic-chairs@ietf.org" >, Eric Rescorla >, "mmusic@ietf.org" >, Flemming Andreasen >, "iesg@ietf.org" >, "draft-ietf-mmusic-sctp-sdp@ietf.org" > Subject: Re: Mirja K=FChlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: = (with DISCUSS) Ben, I have submitted the pull request to address these comments: https://github= .com/cdh4u/draft-sctp-sdp/pull/11 I hope that after Christer reviews and merges the pull request, we should h= ave the latest set of comments addressed. If we need more information about framing, I believe it should go into TCP/= DTLS related draft, since all that draft-sctp-sdp is doing is reusing the s= ame framing for exactly the same reasons. Regards, _____________ Roman Shpount On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell > wrote: Hi all, It seems like this conversation has not completed. What do we need to get t= o closure? A few thoughts of my own: - I'm not adverse to making non-ICE implementors look at the ICE specs for = framing information, as long as the citations are precise enough that they = don't need to read the entirety of ICE. (And the information is really ther= e.) - I am adverse to repeating normative text. I'm okay with adding informatio= nal text about non-ICE usage, as long as it is general enough to avoid conf= usion about where the authoritative text resides. - If people think that ICE is not sufficiently specified, we can work on th= at. But I don't think the burden of doing that belongs to this draft. - The draft is in fact IESG approved in its current state. Material changes= should be kept to the minimum. On 27 Feb 2017, at 7:06, Christer Holmberg wrote: Hi, ... Also I=B9m not sure if the ICE part is fully specified. In your previously mail you wrote "As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m=3D line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m=3D line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.=B3 >From what I understood from ekr, you might not in any case send an re-invite; but maybe I understood this wrongly. I guess that could also be further explained in the draft. Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft. Regards, Christer --_000_D4E707E519117christerholmbergericssoncom_ Content-Type: text/html; charset="windows-1254" Content-ID: <069619E42D2FDC49BE9C1647C8390F5B@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on Roman=92s pull request, I have submitted a new version (-24) = of draft-ietf-mmusic-sctp-sdp.

Regards,

Christer


Hi,

I haven=92t seen any objections to Roman=92s pull request, so I intend= to merge it and submit a new version of the draft.

Regards,

Christer

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thursday 2 March 2017 at 12:2= 8
To: Roman Shpount <rshpount@turbobridge.com>, Ben Campbe= ll <ben@nostrum.com>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, Eric Rescorla <ekr@rtfm.com>, &q= uot;mmusic@ietf.org" <mmusic@ietf.org>, Flemming Andreasen &l= t;fandreas@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org&= quot; <draft-ietf= -mmusic-sctp-sdp@ietf.org>
Subject: Re: Mirja K=FChlewind's Di= scuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)
Resent-From: <alias-bounces@ietf.org>
Resent-To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.= com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Christer Holmberg <christer.ho= lmberg@ericsson.com>
Resent-Date: Thursday 2 March 2017 = at 12:28

Hi,

There may be some minor editorial nits, but in general I am ok with th= e pull request.

Regards,

Christer

From: Roman Shpount <rshpount@turbobridge.com>
Date: Thursday 2 March 2017 at 07:2= 5
To: Ben Campbell <ben@nostrum.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, Mirja Kuehlewind <ietf@ku= ehlewind.net>, "mmusi= c-chairs@ietf.org" <mmusic-chairs@ietf.org&g= t;, Eric Rescorla <ekr@rtfm.com>,= "mmusic@ietf.org" <mmusic@ietf.org>, Flemming Andreasen <fandreas@cisco.com>, &quo= t;iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmus= ic-sctp-sdp@ietf.org>
Subject: Re: Mirja K=FChlewind's Di= scuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

Ben,

I have submitted the pull request to address these comments: https://github.com/= cdh4u/draft-sctp-sdp/pull/11

I hope that after Christer reviews and merges the pull request, we sho= uld have the latest set of comments addressed.

If we need more information about framing, I believe it should go into= TCP/DTLS related draft, since all that draft-sctp-sdp is doing is reusing = the same framing for exactly the same reasons.

Regards,

_________= ____
Roman Shpount

On Wed, Mar 1, 2017 at 9:57 PM, Ben Campbell <ben@nostrum.com> wrote:
Hi all,

It seems like this conversation has not completed. What do we need to get t= o closure?

A few thoughts of my own:

- I'm not adverse to making non-ICE implementors look at the ICE specs for = framing information, as long as the citations are precise enough that they = don't need to read the entirety of ICE. (And the information is really ther= e.)

- I am adverse to repeating normative text. I'm okay with adding informatio= nal text about non-ICE usage, as long as it is general enough to avoid conf= usion about where the authoritative text resides.

- If people think that ICE is not sufficiently specified, we can work on th= at. But I don't think the burden of doing that belongs to this draft.

- The draft is in fact IESG approved in its current state. Material changes= should be kept to the minimum.


On 27 Feb 2017, at 7:06, Christer Holmberg wrote:

Hi,

...

Also I=B9m not sure if the ICE part is fully specified. In your previously<= br> mail you wrote

"As far as TCP/DTLS/SCTP transport tag is concerned, please note that = ICE
end points are supposed to send a re-INVITE after nomination process is
completed with the selected candidate address in the m=3D line. So, if tcp<= br> candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP
transport tag in the m=3D line. Also, any offers/answers after the ICE
nomination is complete, are supposed to send the currently selected
candidate in the m=3D line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.=B3

>From what I understood from ekr, you might not in any case send an
re-invite; but maybe I understood this wrongly. I guess that could also
be further explained in the draft.

Ekr was talking about the specific re-INVITE that is sent directly after ICE nomination. *Other* re-INVITEs can always be sent during the session. But, that is not specific to this draft.

Regards,

Christer

 --_000_D4E707E519117christerholmbergericssoncom_-- From nobody Thu Mar 9 04:39: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 EDE401295E9 for ; Thu, 9 Mar 2017 04:39:20 -0800 (PST) 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 ASC3l33jr8_Q for ; Thu, 9 Mar 2017 04:39:19 -0800 (PST) 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 577AB12955F for ; Thu, 9 Mar 2017 04:39:19 -0800 (PST) X-AuditID: c1b4fb30-45bff70000007a5b-60-58c14cf4590c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id B1.6C.31323.4FC41C85; Thu, 9 Mar 2017 13:39:17 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Thu, 9 Mar 2017 13:39:16 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] late dtls-id request Thread-Index: AQHSmJL+8NznZvzlM0+mOBw/rTGY+6GMHceAgAAHeYD//+KZgIAAfOIA Date: Thu, 9 Mar 2017 12:39:16 +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.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7lu5Xn4MRBi/uqVhcO/OP0WLq8scs DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGlbMPmAqWsFZcnHSWqYFxIksXIweHhICJ xMuGgC5GLg4hgXWMEvu7DzBBOIsYJZrXTGEDKWITsJDo/qfdxcjJISKgK7Ho7AN2kDCzgLrE 1cVBIGFhAS2JHf9nM0GUaEscnNXBDmG7SWyY9wwsziKgItF2fC5YnFfAWmJGP4gNsuo3o8Tz lutgRZwCgRIr3m5nBLEZBcQkvp9aAxZnFhCXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rCC2qICe xPLna6DiihIfX+1jhOjVk7gxFeQVENtaYsruKVAztSWWLXzNDHGQoMTJmU9YJjCKz0KybhaS 9llI2mchaZ+FpH0BI+sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMBoO7jlt8EOxpfPHQ8x CnAwKvHwFsgciBBiTSwrrsw9xCjBwawkwpvjfDBCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/Z yvvhQgLpiSWp2ampBalFMFkmDk6pBsY5HzacE/Uw3qZbrJ2Rxrn+VtbctXsuaHed8Dj9h/ur VYnXvrXn5nBoiVxpUjrGd3vrJ6PyY6YyIgt+Kf7KbbsSae6smLx0R9Cs/euuONYZa7XvufSo WvaX6qnZsv0MYf7Mk06uSVVhnd6+5enJF1k/rMW2Bdc2P3D688lHY/lDMd5qX8Pp8wuVWIoz Eg21mIuKEwHQTucGsgIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 12:39:21 -0000 Hi, >>But, I assume we can make that assumption also with 255. > >For that, 20 would be plenty. > >Note that you only require 32 bits of randomness (which fits in the >minimum of 6 characters), which is not quite enough to provide >global-scale uniqueness. 20 pretty much is going to do that (assuming >6 bits per character, which base64 would allow). > >FWIW, I would be happier if you moved the 32 bit requirement to 120 >and raised the minimum to 20, but that's a much bigger change. If people think such change would be useful I personally have no problem implementing it. But, I=B9d like to hear what Roman & others think. Regards, Christer From nobody Thu Mar 9 12:10: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 6851C1293E1 for ; Thu, 9 Mar 2017 12:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 u-9Eas8y5rep for ; Thu, 9 Mar 2017 12:10:22 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 ECF59126D74 for ; Thu, 9 Mar 2017 12:10:21 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id u30so94031538uau.0 for ; Thu, 09 Mar 2017 12:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=WI5/qcRItyoDamML7K/uxDWYNKduLKJtt9b+Pdmd3/k=; b=Zp2TZlEZRD3/sIzIkOITKIdWirQx1bfG9VWvFH3zlHi2vbS5FAZHfTFoLGUk+OMEuC VWb1DqCLL/SHImPZBKiekGfvW4u70xv79JeHPiNGfkUS3oV2AmY41pvMwZCaBQ1bs4pC 87CIQMXbIkW/furgAOvG9otmskFfgtQ0AiMAyffq72+8y6G0EGB3P7RgwmLDHzoU4HM4 6sGcO/aN3KccksHD1wUH/qSajGuDjXqIhIs0P1GrS3oM9H6kyF+P8PxRgRrcGKEFUe1g S1HarW9PvKkWx0QH+uEmz9dRYDxaZItkKvtWFsz25lQryBxCy+Tf4yvn9BTHhkcnhAaY 8yDA== 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=WI5/qcRItyoDamML7K/uxDWYNKduLKJtt9b+Pdmd3/k=; b=WtG79fiOqUQm8QXYoLBtDBFrD7YmmzxgwdCh44mS2wvJswmKz3IpySnfBhOo/crIrB s+MZLLPBnG7kkByqYhWJyg6z+VgpM86QX6fwVCiIuN3JHGOvgkFiTd1OLHa4qoUpArBd CWoB2tgdjAqKlZyOA7l31HwR8rsvOM35BCcqzsP6s2j5Wrbcr8cgowUOKTMzvX+71+0e ji3QoD1u6FgxOdtb65etIth6VDfH09iQ11kmJlOZx7OMiM81kLJEVsN2SwDzrdG40hGv xHYhdVxvMpEENipHkguqKuCcKiJ46Dm4/nEJmCc5GS2pP1/k6ZdnyuonyCIhI+Wv/BFH f+ag== X-Gm-Message-State: AMke39mqBGArup/Qnn3C1qpTR20LHKcR0aTycQYkm+SCSFDDO0bCVeOeNshD9/BfFO9n98OypEJ6RowP1rw08g== X-Received: by 10.176.83.142 with SMTP id k14mr6550839uaa.64.1489090220954; Thu, 09 Mar 2017 12:10:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Thu, 9 Mar 2017 12:10:00 -0800 (PST) From: Bernard Aboba Date: Thu, 9 Mar 2017 12:10:00 -0800 Message-ID: To: Bo Burman , Flemming Andreasen , mmusic WG Content-Type: multipart/alternative; boundary=f403045e2274a8a124054a51d568 Archived-At: Cc: "hta@google.com" Subject: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 20:10:23 -0000 --f403045e2274a8a124054a51d568 Content-Type: text/plain; charset=UTF-8 In the W3C WEBRTC WG, an issue has been submitted relating to playout of unverified media: https://github.com/w3c/webrtc-pc/issues/849 It has been suggested that if the browser is configured to do so, that playout be allowed for a limited period (e.g. 5 seconds) prior to fingerprint verification: https://github.com/w3c/webrtc-pc/pull/1026 Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text, carried over from RFC 4572: Note that when the offer/answer model is being used, it is possible for a media connection to outrace the answer back to the offerer. Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' role, it MUST (as specified in RFC 4145 [7]) begin listening for an incoming connection as soon as it sends its offer. However, it MUST NOT assume that the data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer. If the fingerprint, once it arrives, does not match the client's certificate, the server endpoint MUST terminate the media connection with a bad_certificate error, as stated in the previous paragraph. Given the outstanding issue relating to handling of unverified media, the Chairs of the W3C WEBRTC WG would like to request clarification from the IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above paragraph. In particular, what is it permitted for an implementation to do with received data and media prior to verification? For example: 1. May data received over the data channel be provided to the application prior to verification? a. If the answer to the above is "no", may unverified received data be delivered by the DTLS transport to SCTP, which may buffer it? 2. May received media be played out prior to verification? Bernard Aboba On behalf of the W3C WEBRTC WG --f403045e2274a8a124054a51d568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the W3C WEBRTC WG, an issue has been submitted relating to playou= t of unverified media:

It has been suggested t= hat if the browser is configured to do so, that playout be allowed for a li= mited period (e.g. 5 seconds) prior to fingerprint verification:


=C2=A0 =C2=A0until it has received a matching f= ingerprint in an SDP answer.=C2=A0 If


=C2=A0 =C2=A0 =C2=A01. May data received = over the data channel be provided to the application prior to verification?=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a. = If the answer to the above is "no", may unverified received data = be delivered by the DTLS transport to SCTP, which may buffer it?
=C2=A0 =C2=A0 =C2=A02. May received media be pla= yed out prior to verification?

Bernard Aboba
On behalf of the W3C WEBRTC WG
--f403045e2274a8a124054a51d568-- From nobody Thu Mar 9 18:42:48 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 55A8A1294E0 for ; Thu, 9 Mar 2017 18:42:47 -0800 (PST) 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, 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=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 N0aukYRnvcYP for ; Thu, 9 Mar 2017 18:42:45 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 6330D1294D6 for ; Thu, 9 Mar 2017 18:42:45 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id y76so149789261qkb.0 for ; Thu, 09 Mar 2017 18:42:45 -0800 (PST) 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=ks4AnI2sgYPEYKN4RKK2ZGWxi8B7ooE0C/Ktu6Col1s=; b=NdJfLwU1tLv0y5jiHmsrcyDRJ794cU7evngdQqHcfugMxwUKRLIDkDoNADU2op8d5A iMMru1fB/DsEUVEEhDh/J8m5e/nG64+fzmjV/d85TZBYKq0mg8wujqagudwOQfl0RGJ/ Fpc51G67Wfj1cfon3rKqEWqEAWqfyheMk20aB0SJ48PSTVhp6ArFeJgbuvvRtUSbshIq t+wvVVn3BGTm+taZRyzpx8QC7JnrOwD3HxUP2JEmY8sIy4emmguVjWSKDLjffsAQJR41 a0rznHHEs6o/742MDnjVDcWIghim2ELUWFEXGBNxCOwUiq5xyPhXQZatcNiGRlgFcxjk zb9w== 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=ks4AnI2sgYPEYKN4RKK2ZGWxi8B7ooE0C/Ktu6Col1s=; b=nYGhCZASITATEOiwLJ4IkcysoilgivoI2Ga7FwrsfyQCPavmy5R4YZTZG5xqasAqFC HYGl5V7Zc+VqkWL7YFteEbPzThI4cdXzv9RDZRaP+CMvgX9fi+dR+yMWP8f6G+pu3JxA 0nc8ivDOidovD07FLt5APMCTkmPzjHPMiRs8KW1uOCq11oTEhKe9fZdmZ8n+ctNziCsX N212dpkEZ6DRt+tnQ2SoLGPHWwFFCbteQ/1xLAGUfb8Gm9snAUAxy11yoDbrMM6nkkKd zSIc+Z9M/kt8FfJFCdTXzZZ2xJqmqbVmp1Zi3ry2kZiAI1/qB9O0kvmSTaRu/9Hci1CZ te8g== X-Gm-Message-State: AFeK/H2KPF0ca2fi/espobHTOSfUSrZEH3zcy8RLYbp5VAdg5x0XlbtF4p+tqckz/iYAxREG/s17/pNAbZsGzw== X-Received: by 10.55.151.7 with SMTP id z7mr16679291qkd.316.1489103881041; Thu, 09 Mar 2017 15:58:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Mar 2017 15:58:00 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 10 Mar 2017 10:58:00 +1100 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 02:42:47 -0000 I think that the data channel question is easy, anything other than a "no" is not acceptable. Data in that form enters the security boundary for an origin and it doesn't make any sense to risk attack there. (It's also likely unnecessary, if a half a round trip of signaling is slower than 5 round trips on the media path, then something is messed up.) I'm in two minds about the media part. For media, you could also reasonably make the same origin-purity argument. I'm inclined to say that. But we CAN isolate media from the origin (and we definitely should if we allow this). So, the media that arrives had to comply with your offer. The DTLS handshake also has to complete, which tells the receiver whether the media needs to be confidential or not (at which point you can disable this feature). It's also possible that a receiver can require that an ICE connectivity check was made (though this is inbound only, and I'm unclear on whether having received an inbound check would normally prevent the receiver from accepting a packet). All told, that's a lot of information about the negotiated session for an attacker to have. The odds of this being an attack would *seem* to be low. On the other hand, we don't assume confidentiality of signaling; the security model assumes that all this information is effectively public and the protection we have against attack is the certificate fingerprint. This would remove that protection, albeit for a short duration. I have an extra question: does anyone plan to implement this? It's non-trivial. I think that I know what I'd need to do in Firefox and it would be quite disruptive. Before committing to do that work (which I will leave to others closer to this to decide), I'd probably want more information on the actual advantage that it provides. On 10 March 2017 at 07:10, Bernard Aboba wrote: > In the W3C WEBRTC WG, an issue has been submitted relating to playout of > unverified media: > https://github.com/w3c/webrtc-pc/issues/849 > > It has been suggested that if the browser is configured to do so, that > playout be allowed for a limited period (e.g. 5 seconds) prior to > fingerprint verification: > https://github.com/w3c/webrtc-pc/pull/1026 > > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text, > carried over from RFC 4572: > > Note that when the offer/answer model is being used, it is possible > for a media connection to outrace the answer back to the offerer. > Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' > role, it MUST (as specified in RFC 4145 [7]) begin listening for an > incoming connection as soon as it sends its offer. However, it MUST > NOT assume that the data transmitted over the TLS connection is valid > until it has received a matching fingerprint in an SDP answer. If > the fingerprint, once it arrives, does not match the client's > certificate, the server endpoint MUST terminate the media connection > with a bad_certificate error, as stated in the previous paragraph. > > Given the outstanding issue relating to handling of unverified media, the > Chairs of the W3C WEBRTC WG would like to request clarification from the > IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above paragraph. > In particular, what is it permitted for an implementation to do with > received data and media prior to verification? For example: > > 1. May data received over the data channel be provided to the > application prior to verification? > a. If the answer to the above is "no", may unverified received data > be delivered by the DTLS transport to SCTP, which may buffer it? > 2. May received media be played out prior to verification? > > Bernard Aboba > On behalf of the W3C WEBRTC WG > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Mar 9 20:07: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 3F1881295B9 for ; Thu, 9 Mar 2017 20:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 5SWmYe_EmZXW for ; Thu, 9 Mar 2017 20:07:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 0BF4B1295B7 for ; Thu, 9 Mar 2017 20:07:40 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v2A47bgp026708 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Mar 2017 23:07:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1489118858; bh=J/1ICB70gX+QoD6uS3uHt5dEnpjTCAcN+8tEzfsZgaQ=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=XxuoG9GOQCaO5jt6cxvGw5POAAEcykbGHZOvTZLmHUxNnLTtgEzra8qFngdAX55Pg dPfb3ILzj6aNnwuKcbjSd7AUAnBT1GlEXfsQ/KBl87ObBZRbE/xWZFjM95pfWvAHGn IcQODZ8S+DmZQQaDcym7t+Dn92q2W/IyflH1/gns= From: "Paul E. Jones" To: "Christer Holmberg" , "Martin Thomson" Date: Fri, 10 Mar 2017 04:07:37 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Thu, 09 Mar 2017 23:07:38 -0500 (EST) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 04:07:42 -0000 Christer, >>FWIW, I would be happier if you moved the 32 bit requirement to 120 >>and raised the minimum to 20, but that's a much bigger change. > >If people think such change would be useful I personally have no=20 >problem >implementing it. Given there are uniqueness requirements for different applications (one=20 I'm proposing is in PERC), more than 32 bits might be better. We know=20 SSRC collisions happen, so more randomness would likely help in many use=20 cases. Paul From nobody Thu Mar 9 23:43: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 A97E9129660 for ; Thu, 9 Mar 2017 23:43:51 -0800 (PST) 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 B3Bnt3JUuFqF for ; Thu, 9 Mar 2017 23:43:50 -0800 (PST) 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 455CB12961B for ; Thu, 9 Mar 2017 23:43:50 -0800 (PST) X-AuditID: c1b4fb25-a57ff70000004cad-53-58c2593190a1 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 37.74.19629.13952C85; Fri, 10 Mar 2017 08:43:48 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Fri, 10 Mar 2017 08:43:56 +0100 From: Christer Holmberg To: "Paul E. Jones" , Martin Thomson Thread-Topic: [MMUSIC] late dtls-id request Thread-Index: AQHSmJL+8NznZvzlM0+mOBw/rTGY+6GMHceAgAAHeYD//+KZgIAAfOIAgADhD4CAAF6zgA== Date: Fri, 10 Mar 2017 07:43:43 +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.1.161129 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <65C62CB8157EA64B828BDD5EE1200C65@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7t65J5KEIg3s7JCyunfnHaDF1+WMW i/MXNjA5MHvsnHWX3WPJkp9MHg37jrIHMEdx2aSk5mSWpRbp2yVwZfxv+MpW0MxacWirZAPj P+YuRk4OCQETif9/e9i7GLk4hATWMUrc2rGDDSQhJLCYUeLNnZouRg4ONgELie5/2iBhEYEI iQWbfrOBhJkF1CWuLg4CCQsLaEns+D+bCaJEW+LgrA52CDtMYsXyrWA2i4CqxNyW4ywgNq+A tcTsP5vYITbdZ5L4/kASZCSngI3E2uMKIGFGATGJ76fWgI1kFhCXuPVkPhPExQISS/ach7pe VOLl43+sILaogJ7E8udrmEHGSAgoSUzbmgbRqiOxYPcnNgjbWuLHgR52CFtbYtnC18wQ1whK nJz5hGUCo/gsJNtmIWmfhaR9FpL2WUjaFzCyrmIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQI jLyDW36r7mC8/MbxEKMAB6MSD++H3IMRQqyJZcWVuYcYJTiYlUR4S/UORQjxpiRWVqUW5ccX leakFh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAaLNoNffON65/xQ78apzmFrbD XfFXuOuuyU9yjeb8jQqsvtv24/eu2BaVi691jvpvncptyKg9n8fsxm5b28Oa9lJcVzo2rbM4 ceIvk/GT5DiZ7tnrIpYFHSq4fDNwj07ikjVurW+TvH6scXdxe9McOYfH9WfI7O4+FpavX7cf rtmUdCr3l5eQhRJLcUaioRZzUXEiAPLckt64AgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 07:43:51 -0000 So, who will create the pull request? :) Regards, Christer On 10/03/17 06:07, "Paul E. Jones" wrote: >Christer, > >>>FWIW, I would be happier if you moved the 32 bit requirement to 120 >>>and raised the minimum to 20, but that's a much bigger change. >> >>If people think such change would be useful I personally have no >>problem >>implementing it. > >Given there are uniqueness requirements for different applications (one >I'm proposing is in PERC), more than 32 bits might be better. We know >SSRC collisions happen, so more randomness would likely help in many use >cases. > >Paul > From nobody Fri Mar 10 01:51: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 B114C129869; Fri, 10 Mar 2017 01:51:16 -0800 (PST) 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 2T3a208ELTbF; Fri, 10 Mar 2017 01:51:14 -0800 (PST) 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 3059A129759; Fri, 10 Mar 2017 01:51:13 -0800 (PST) X-AuditID: c1b4fb25-a57ff70000004cad-5d-58c2770f1587 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id F7.A2.19629.F0772C85; Fri, 10 Mar 2017 10:51:12 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.319.2; Fri, 10 Mar 2017 10:51:10 +0100 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> From: Magnus Westerlund Message-ID: <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> Date: Fri, 10 Mar 2017 10:51:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2K7oq5A+aEIg+ObZCxWvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV0bT/YWMBduTK/5NO8DawLjOu4uR g0NCwERiw8SCLkYuDiGBdYwSHRuPskE4yxklpj7pBXI4OYQFvCTatk1kBrFFBBQkfv05wQJR 9JdZYtfu02wgk5gFfCQWPksEqWETsJC4+aMRrJdXwF6i/dxpJhCbRUBV4vGZa2C2qECMRMuS D4wQNYISJ2c+YQGxOQUCJbZ93AZWwww0Z+b884wQtrxE89bZYDcICWhLNDR1sE5gFJiFpH0W kpZZSFoWMDKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAgM0INbfqvuYLz8xvEQowAHoxIP 74fcgxFCrIllxZW5hxglOJiVRHhlSw9FCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEgg PbEkNTs1tSC1CCbLxMEp1cCYGbE95L1FR6XLXelbdTIRB1Sdy9Q07p+4dHmivf/WreYqKabT Guw4C7M19laLXkp/8Oyq16u++UFRqs+XHJT/cPrn8qWvXDavuH7N947LGmHT/e1Hk948fX8+ cEVPm16Txu6PD6sq50zKP3rrlvH/l/MSPx462mZ9fcfxRc0FPK/1Cxk0mBccVGIpzkg01GIu Kk4EAPv3nVxMAgAA Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 09:51:16 -0000 Hi, EKR, I think I understood your issue with the SDP MID usage. I restructured the section to move the issues with moving the MID into RTP layer as the second paragraph and made it clear that this is a new security consideration compared to before in the introduction. Regarding the integrity and authenticity I have made some small changes. I don't see how removing the requirements help, even if they are normally resolved when using an existing mechanism. I guess this is is a matter of view. I am not comfortable with simple assuming that people will use a security mechanism and therefore this is not an issue. And it makes future work to analyses potential mechanism a bit harder as one have to redo more analysis, such as in PERC. Anyway here is an updated text. I have sent the XML of this one to Christer and he has told me he will update the PR he already have. 16. Security Considerations The security considerations defined in [RFC3264] and [RFC5888] apply to the BUNDLE extension. Bundle does not change which information, e.g. RTP streams, that flows over the network, with the exception of the usage of the MID SDES item as discussed below. Primarily it changes which addresses and ports, and thus in which (RTP) sessions that the information is flowing in. This affects the security contexts being used and can cause previously separated information flows to share security context. This has very little impact on the performance of the security mechanism of the RTP sessions. In cases where one would have applied different security policies on the different RTP streams being bundled, or where the parties having access to the security contexts would have differed between the RTP stream additional analysis of the implications are needed before selecting to apply BUNDLE. The identification-tag, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag values MUST be generated in a fashion that does not leak user information, e.g., randomly or using a per-bundle group counter, and SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension. Note that if implementations use different methods for generating identification-tags this could enable fingerprinting of the implementation making it vulnerable to targeted attacks. The identification-tag is exposed on the RTP stream level when included in the RTP header extensions, however what it reveals of the RTP media stream structure of the endpoint and application was already possible to deduce from the RTP streams without the MID SDES header extensions. As the identification-tag is also used to route the media stream to the right application functionality it is also important that the value received is the one intended by the sender, thus integrity and the authenticity of the source are important to prevent denial of service on the application. Existing SRTP configurations and other security mechanisms protecting the whole RTP/RTCP packets will provide the necessary protection. When the BUNDLE extension is used, a single set of security credentials over the bundled media descriptions will need to be used, at least per direction or endpoint. When using SRTP this will be the case, at least for the IETF defined key-management solutions due to their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their classification in [I-D.ietf-mmusic-sdp-mux-attributes]. "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items" [RFC7941] security consideration requires that when RTCP is confidentiality protected that any SDES RTP header extension carrying an SDES item, like the MID RTP header extension, is also protected using commensurate strength algorithms. However, assuming the above requirements and recommendations are followed there are no known significant security risks with leaving the MID RTP header extension without confidentiality protection. Thus, the requirements in RFC 7941 MAY be ignored for the MID RTP header extension. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can provide the necessary security functions of ensuring the integrity and source authenticity. Den 2017-03-07 kl. 18:47, skrev Eric Rescorla: > > > On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund > > > wrote: > > Hi, > > Please see inline. > > Den 2017-03-06 kl. 14:36, skrev Eric Rescorla: > > > I think you are correct assuming that one is using SRTP. All the > IETF key-management scheme follows this, although a=mikey is > IDENTICAL. If one uses other security mechanisms, then this > is still > relevant to capture. > > > Which security mechanisms are you thinking of here? > > > I didn't have any specific security mechanism in mind. I simply want > to make clear the requirements that arises due to the new mechanisms > that BUNDLE creates. As you commented I can only think of mechanism > that protects the whole packet. > > > Yeah, this seems more confusing than illuminating. There are lots of > theoretical > risks that might happen if we had some new security mechanism with unknown > properties. > > > > Is this precisely true? Do you ever use the MID extension w/o > BUNDLE? > It certainly changes which ICE checks you do. > > > So lets start with the question of MID without using BUNDLE. As MID > is used in grouping of media lines use cases, i.e. RFC 5888 there > are certainly uses. However, there exist no need to signal MIDs on > RTP session level in those cases as there already exist a one to one > mapping between the MID and the transport addresses used for that > RTP session. Only with BUNDLE do the RTP streams from the different > m= lines start sharing transport context. > > > That's what I meant by "MID extension". Sorry for the confusion. > > > > So strictly the above is incorrect. What was multiple security > context due to different RTP sessions, or other sessions are now > moved into a single context. I think we could reformulate this to say: > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information, > e.g. RTP streams, that flows over the network. Primarily it changes > which addresses and ports, and thus in which (RTP) sessions that the > information is flowing in. This affects the security contexts being > used and can cause previously separated information flows to share > security context. This has very little impact on the performance of > the security mechanism of the RTP sessions, however which actors that > are present in a particular security context may require additional > thoughts when applying Bundle. > > Is this better? > > > But it still seems to be false because of the MID signaling in SDP. > > I also don't understand the last line. > > -Ekr > > > The identication-tag is > > > Still misspelled. > > > Yes, there was actually two misspelled instances left, and I had > corrected one. > > Full section text after corrections: > > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information, > e.g. RTP streams, that flows over the network. Primarily it changes > which addresses and ports, and thus in which (RTP) sessions that the > information is flowing in. This affects the security contexts being > used and can cause previously separated information flows to share > security context. This has very little impact on the performance of > the security mechanism of the RTP sessions, however which actors that > are present in a particular security context may require additional > thoughts when applying Bundle. > > When the BUNDLE extension is used, a single set of security > credentials might be used for all media streams specified by a BUNDLE > group. When using SRTP this is further required at least for the > IETF defined key-management solutions due to their SDP attributes > (a=crypto, a=fingerprint, a=mikey) classification in > [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security > solutions, this may require further consideration. > > The identification-tag, independent of transport, RTCP SDES packet or > RTP header extension, can expose the value to parties beyond the > signaling chain. Therefore, the identification-tag values MUST be > generated in a fashion that does not leak user information, e.g., > randomly or using a per-bundle group counter, and SHOULD be 3 bytes > or less, to allow them to efficiently fit into the MID RTP header > extension. Note that if implementations use different methods for > generating identification-tags this could enable fingerprinting of > the implementation making it vulnerable to targeted attacks. The > identification-tag is exposed on the RTP stream level when included > in the RTP header extensions, however what it reveals of the RTP > media stream structure of the endpoint and application was already > possible to deduce from the RTP streams without the MID SDES header > extensions. As the identification-tag is also used to route the > media stream to the right application functionality it is also > important that the value received is the one intended by the sender, > thus integrity and the authenticity of the source are important to > prevent denial of service on the application. Existing SRTP > configurations requires integrity protection of both RTCP and RTP > header extensions. > > "RTP Header Extension for the RTP Control Protocol (RTCP) Source > Description Items" [RFC7941] security consideration requires that > when RTCP is confidentiality protected that any SDES RTP header > extension carrying an SDES item, like the MID RTP header extension, > is also protected using commensurate strength algorithms. However, > assuming the above requirements and recommendations are followed > there are no known significant security risks with leaving the MID > RTP header extension without confidentiality protection. Thus, the > requirements in RFC 7941 MAY be ignored for the MID RTP header > extension. Security mechanisms for RTP/RTCP are discussed in Options > for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can > provide the necessary security functions of ensuring the integrity > and source authenticity. > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 10 05:47: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 E8F131295AA for ; Fri, 10 Mar 2017 05:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 7Kcqkf7eGvCu for ; Fri, 10 Mar 2017 05:47:24 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3830A12956A for ; Fri, 10 Mar 2017 05:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5171; q=dns/txt; s=iport; t=1489153644; x=1490363244; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=4XLx1RGuD5uc6cMlW99nlYEhW++5hujHHfd496SmXjE=; b=czETKu+jr3B7iQMg13HhWw9dwC/2uCjd3l6AeIaDTrJSFhBhJ29QVSxv O25WDoXCK/2vtKDyGQDjZibbnazESJGuYdz/BXEO0p5+b8SwIwwvfBDN+ h8NeYw8LykpvadJdC09GId76ANwvAw9uxO1M5rY2Fgr4sYBT1ntmHzGAt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAQDvrcJY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhKmCNbpExH5ALhS2CDh8BCoUuSgKCPD8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBbAsFCwsYJwcnHxEGAQwGAgEBiW8FCA6zViuKPAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhk6CBQiCYoo5BYkSh0VMixeSOIF7iFaGUYhEhluEIR8?= =?us-ascii?q?4gQM4HxU/hBxvgWgiNYoaAQEB?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="scan'208,217";a="394400448" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2017 13:47:23 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2ADlMa0012134; Fri, 10 Mar 2017 13:47:22 GMT To: "Ali C. Begen" , Cullen Jennings References: <5136C735-5EF5-4E4E-A748-B3F1507A5CB4@iii.ca> From: Flemming Andreasen Message-ID: Date: Fri, 10 Mar 2017 08:47:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------44473C985C85F853B13F6B3D" Archived-At: Cc: mmusic Subject: Re: [MMUSIC] References to iana-charset-reg-procedure in draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 13:47:26 -0000 This is a multi-part message in MIME format. --------------44473C985C85F853B13F6B3D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/23/16 12:17 AM, Ali C. Begen wrote: > Was there a decision on this during the meeting? I can make the change > if it has been agreed to. > I don't believe we decided on this during the meeting, but it seems reasonable to me, not least considering that the charset-reg draft expired quite a while ago. Also, do note, that we are trying to ensure that RTCWeb does not have any normative dependencies on 4566bis, so from that point of view, there may not be an issue here. Thanks -- Flemming > On Wed, Nov 16, 2016 at 5:51 AM, Cullen Jennings > wrote: > > > draft-ietf-mmusic-rfc4566bis has a normative references to > draft-iana-charset-reg-procedure. draft-iana-charset-reg is an > update of RFC2978 and will obsolete RFC2978 when it is published. > > When I look at what parts of iana-charset-reg-procedure that > 4566bis uses, I think it would be perfectly reasonable to instead > have 4566bis reference RFC2978. > > I'd like to propose we make this change so that publication of > 4566bis is not blocked by iana-charset-reg-procedure > > > _______________________________________________ > 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 --------------44473C985C85F853B13F6B3D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 11/23/16 12:17 AM, Ali C. Begen wrote:
Was there a decision on this during the meeting? I can make the change if it has been agreed to.

I don't believe we decided on this during the meeting, but it seems reasonable to me, not least considering that the charset-reg draft expired quite a while ago. Also, do note, that we are trying to ensure that RTCWeb does not have any normative dependencies on 4566bis, so from that point of view, there may not be an issue here.

Thanks

-- Flemming


On Wed, Nov 16, 2016 at 5:51 AM, Cullen Jennings <fluffy@iii.ca> wrote:

draft-ietf-mmusic-rfc4566bis has a normative references to draft-iana-charset-reg-procedure. draft-iana-charset-reg is an update of RFC2978 and will obsolete RFC2978 when it is published.

When I look at what parts of iana-charset-reg-procedure that 4566bis uses, I think it would be perfectly reasonable to instead have 4566bis reference RFC2978.

I'd like to propose we make this change so that publication of 4566bis is not blocked by iana-charset-reg-procedure


_______________________________________________
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

--------------44473C985C85F853B13F6B3D-- From nobody Fri Mar 10 06:36: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 4736F1295FE for ; Fri, 10 Mar 2017 06:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 PwM6RjF-fFMP for ; Fri, 10 Mar 2017 06:36:03 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302541295A5 for ; Fri, 10 Mar 2017 06:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=319; q=dns/txt; s=iport; t=1489156563; x=1490366163; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=glpBtT5h45MDDis9cJNCUUxg+ekZYz5mEvy1yNPEqe0=; b=a3hbeFFHUfXPIKWhBtZ8wmkk8RSwi3b6Mnz0ees/1z+ivcVBL/dQz2Bu mL/UoqtbHxW6vU0SF6Y52aA6fASXg5AdaodouxWNhvsgJJWnVFTyA0A3R 2Zy5VoZUqhQOX+uPVpOBrfdR3/oAAhjqwz0qTfTYC550yrFLcU5MUO1SI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyBAAnucJY/5ldJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1FhKoRAig6RMYw1gS6EVzNbgg+CDiqINj8YAQIBAQEBAQEBayiFPxV2AiY?= =?us-ascii?q?CXw0IAQGJbw0OoS2QBoImimkBAQEBBgEBAQEBHgWBC4VDggUIijyCXwWQV4tjj?= =?us-ascii?q?EyFCWOBYwGIbYZRk0AfOIEDOB8VhzIiik8BAQE?= X-IronPort-AV: E=Sophos;i="5.36,141,1486425600"; d="scan'208";a="218737761" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2017 14:36:02 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2AEa1b4025928 for ; Fri, 10 Mar 2017 14:36:02 GMT To: mmusic From: Flemming Andreasen Message-ID: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> Date: Fri, 10 Mar 2017 09:36:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 14:36:04 -0000 Greetings The initial draft agenda for the MMUSIC meeting in Chicago has now been uploaded to: https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00 We still have a bit of room on the agenda, so let us know of any additional agenda requests (before March 15) Thanks Flemming & Bo From nobody Fri Mar 10 07:32: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 EB34712963D for ; Fri, 10 Mar 2017 07:32:24 -0800 (PST) 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 LdDf5b8O0SIF for ; Fri, 10 Mar 2017 07:32:22 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3F3129638 for ; Fri, 10 Mar 2017 07:32:18 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id p77so25761075ywg.1 for ; Fri, 10 Mar 2017 07:32:18 -0800 (PST) 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=EEWcB5beUBuyZfULiiI+Z67JRElyruFFoFjK7jzcZi4=; b=H+B6EhR13hHxGpN92wK02WgJ8WT7ZE7KCUjh0aBBjixcnvhVGlfjLwGVF1T+s2gtVV lO6mcG9XfK0Mi7j3MriWMgsNJXbRBA2MJWtQ2hYMgpduXHNRkUQXnUGL/5l0aw/4UjPS PipZdI+S7Yo/33IfstSYgj7Xx0tbnkKvXuyrU0BaflyaFuYVp/zlUBE23oNCbBsj2NS0 THIS1NyhJuoO8Z7rAfKtv1DbB6tpw7ZeQbZBzFnWcVXGwQlEgdFb4THp6kKrQurnlYUj QfykyUkCmyHosYJJ0k0MH82lvJAX+B2KPzFggIzxim54h7N/pOu7exkGwduymW2gUi3x xOmA== 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=EEWcB5beUBuyZfULiiI+Z67JRElyruFFoFjK7jzcZi4=; b=NkK5VLeWr5EpR0cqYEQWx3z9iJ9rQKYN0Fr21bpxp0W6LLDZxLyhPjp2HES3NPOPfc JGJAdzTWn0GbjeHWkI7x5Wp2aFSs2rmoAfE0+0770SBHDhkQu7DcDvYZy7MZ3o6S9ezM gyH5QznCD70iHO5+k7Z1K1+o4dUEiuQCRaz9UGwAtyV7ZgbGLcEBVzhOEZ1+dp4wVkLv acFbmtNrcy5n/CNlN74kkHkfltI15ZyzNS9ETmJ6835rPKKwmEEgtiC9NgELip+O9Pn/ hHz0jVRCeDoXtlg8YGvwzmmdR3tXIsNFybpQ69z3eth7euat8ZV6hsslu0+E+ZJ55KOH xyXw== X-Gm-Message-State: AMke39kkELkQyqIODUrI03cPpRTLvd2s1KlnfBwaUiZjvMkDAO1B8F7/10flKHwwIKNMyah34XHlH4LKQOS3Mg== X-Received: by 10.13.240.196 with SMTP id z187mr8529443ywe.337.1489159937973; Fri, 10 Mar 2017 07:32:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 07:31:37 -0800 (PST) In-Reply-To: <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> From: Eric Rescorla Date: Fri, 10 Mar 2017 07:31:37 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c034eb01e0238054a621136 Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:32:25 -0000 --94eb2c034eb01e0238054a621136 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 10, 2017 at 1:51 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > EKR, I think I understood your issue with the SDP MID usage. I > restructured the section to move the issues with moving the MID into RTP > layer as the second paragraph and made it clear that this is a new securi= ty > consideration compared to before in the introduction. > > Regarding the integrity and authenticity I have made some small changes. = I > don't see how removing the requirements help, even if they are normally > resolved when using an existing mechanism. I guess this is is a matter of > view. I am not comfortable with simple assuming that people will use a > security mechanism and therefore this is not an issue. And it makes futur= e > work to analyses potential mechanism a bit harder as one have to redo mor= e > analysis, such as in PERC. > What I am trying to do is to avoid confusing people who think that SRTP is fine but some other mechanism which they might actually use is not fine. With that said, I consider your current text to be clear enogh on this point. > > Anyway here is an updated text. I have sent the XML of this one to > Christer and he has told me he will update the PR he already have. > > > 16. Security Considerations > > The security considerations defined in [RFC3264] and [RFC5888] apply > to the BUNDLE extension. Bundle does not change which information, > e.g. RTP streams, that flows over the network, with the exception of > e.g. has a comma after it. > the usage of the MID SDES item as discussed below. Primarily it > changes which addresses and ports, and thus in which (RTP) sessions > that the information is flowing in. This affects the security > contexts being used and can cause previously separated information > flows to share security context. This has very little impact on the > performance of the security mechanism of the RTP sessions. In cases > where one would have applied different security policies on the > different RTP streams being bundled, or where the parties having > access to the security contexts would have differed between the RTP > stream additional analysis of the implications are needed before > selecting to apply BUNDLE. > > The identification-tag, independent of transport, RTCP SDES packet or > RTP header extension, can expose the value to parties beyond the > signaling chain. Therefore, the identification-tag values MUST be > generated in a fashion that does not leak user information, e.g., > randomly or using a per-bundle group counter, and SHOULD be 3 bytes > or less, to allow them to efficiently fit into the MID RTP header > extension. Note that if implementations use different methods for > generating identification-tags this could enable fingerprinting of > the implementation making it vulnerable to targeted attacks. The > identification-tag is exposed on the RTP stream level when included > in the RTP header extensions, however what it reveals of the RTP > media stream structure of the endpoint and application was already > possible to deduce from the RTP streams without the MID SDES header > extensions. As the identification-tag is also used to route the > media stream to the right application functionality it is also > important that the value received is the one intended by the sender, > thus integrity and the authenticity of the source are important to > prevent denial of service on the application. Existing SRTP > configurations and other security mechanisms protecting the whole > RTP/RTCP packets will provide the necessary protection. > > When the BUNDLE extension is used, a single set of security > credentials over the bundled media descriptions will need to be used, > at least per direction or endpoint. Actually, why does this have to be the case? I mean, we require it, but if you have the MID extension, you could easily not do this. > When using SRTP this will be the > case, at least for the IETF defined key-management solutions due to > their SDP attributes (a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) and thei= r > classification in [I-D.ietf-mmusic-sdp-mux-attributes]. > > "RTP Header Extension for the RTP Control Protocol (RTCP) Source > Description Items" [RFC7941] security consideration requires that > when RTCP is confidentiality protected that any SDES RTP header > extension carrying an SDES item, like the MID RTP header extension, > is also protected using commensurate strength algorithms. However, > assuming the above requirements and recommendations are followed > there are no known significant security risks with leaving the MID > RTP header extension without confidentiality protection. Thus, the > requirements in RFC 7941 MAY be ignored for the MID RTP header > extension. Security mechanisms for RTP/RTCP are discussed in Options > for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] can > provide the necessary security functions of ensuring the integrity > and source authenticity. > > > Den 2017-03-07 kl. 18:47, skrev Eric Rescorla: > >> >> >> On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund >> > >> >> wrote: >> >> Hi, >> >> Please see inline. >> >> Den 2017-03-06 kl. 14:36, skrev Eric Rescorla: >> >> >> I think you are correct assuming that one is using SRTP. All >> the >> IETF key-management scheme follows this, although a=3Dmikey = is >> IDENTICAL. If one uses other security mechanisms, then this >> is still >> relevant to capture. >> >> >> Which security mechanisms are you thinking of here? >> >> >> I didn't have any specific security mechanism in mind. I simply want >> to make clear the requirements that arises due to the new mechanisms >> that BUNDLE creates. As you commented I can only think of mechanism >> that protects the whole packet. >> >> >> Yeah, this seems more confusing than illuminating. There are lots of >> theoretical >> risks that might happen if we had some new security mechanism with unkno= wn >> properties. >> >> >> >> Is this precisely true? Do you ever use the MID extension w/o >> BUNDLE? >> It certainly changes which ICE checks you do. >> >> >> So lets start with the question of MID without using BUNDLE. As MID >> is used in grouping of media lines use cases, i.e. RFC 5888 there >> are certainly uses. However, there exist no need to signal MIDs on >> RTP session level in those cases as there already exist a one to one >> mapping between the MID and the transport addresses used for that >> RTP session. Only with BUNDLE do the RTP streams from the different >> m=3D lines start sharing transport context. >> >> >> That's what I meant by "MID extension". Sorry for the confusion. >> >> >> >> So strictly the above is incorrect. What was multiple security >> context due to different RTP sessions, or other sessions are now >> moved into a single context. I think we could reformulate this to sa= y: >> >> The security considerations defined in [RFC3264] and [RFC5888] >> apply >> to the BUNDLE extension. Bundle does not change which informatio= n, >> e.g. RTP streams, that flows over the network. Primarily it >> changes >> which addresses and ports, and thus in which (RTP) sessions that >> the >> information is flowing in. This affects the security contexts >> being >> used and can cause previously separated information flows to shar= e >> security context. This has very little impact on the performance >> of >> the security mechanism of the RTP sessions, however which actors >> that >> are present in a particular security context may require addition= al >> thoughts when applying Bundle. >> >> Is this better? >> >> >> But it still seems to be false because of the MID signaling in SDP. >> >> I also don't understand the last line. >> >> -Ekr >> >> >> The identication-tag is >> >> >> Still misspelled. >> >> >> Yes, there was actually two misspelled instances left, and I had >> corrected one. >> >> Full section text after corrections: >> >> 16. Security Considerations >> >> The security considerations defined in [RFC3264] and [RFC5888] >> apply >> to the BUNDLE extension. Bundle does not change which informatio= n, >> e.g. RTP streams, that flows over the network. Primarily it >> changes >> which addresses and ports, and thus in which (RTP) sessions that >> the >> information is flowing in. This affects the security contexts >> being >> used and can cause previously separated information flows to shar= e >> security context. This has very little impact on the performance >> of >> the security mechanism of the RTP sessions, however which actors >> that >> are present in a particular security context may require addition= al >> thoughts when applying Bundle. >> >> When the BUNDLE extension is used, a single set of security >> credentials might be used for all media streams specified by a >> BUNDLE >> group. When using SRTP this is further required at least for the >> IETF defined key-management solutions due to their SDP attributes >> (a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) classification in >> [I-D.ietf-mmusic-sdp-mux-attributes]. But for other security >> solutions, this may require further consideration. >> >> The identification-tag, independent of transport, RTCP SDES packe= t >> or >> RTP header extension, can expose the value to parties beyond the >> signaling chain. Therefore, the identification-tag values MUST b= e >> generated in a fashion that does not leak user information, e.g., >> randomly or using a per-bundle group counter, and SHOULD be 3 byt= es >> or less, to allow them to efficiently fit into the MID RTP header >> extension. Note that if implementations use different methods fo= r >> generating identification-tags this could enable fingerprinting o= f >> the implementation making it vulnerable to targeted attacks. The >> identification-tag is exposed on the RTP stream level when includ= ed >> in the RTP header extensions, however what it reveals of the RTP >> media stream structure of the endpoint and application was alread= y >> possible to deduce from the RTP streams without the MID SDES head= er >> extensions. As the identification-tag is also used to route the >> media stream to the right application functionality it is also >> important that the value received is the one intended by the >> sender, >> thus integrity and the authenticity of the source are important t= o >> prevent denial of service on the application. Existing SRTP >> configurations requires integrity protection of both RTCP and RTP >> header extensions. >> >> "RTP Header Extension for the RTP Control Protocol (RTCP) Source >> Description Items" [RFC7941] security consideration requires that >> when RTCP is confidentiality protected that any SDES RTP header >> extension carrying an SDES item, like the MID RTP header extensio= n, >> is also protected using commensurate strength algorithms. Howeve= r, >> assuming the above requirements and recommendations are followed >> there are no known significant security risks with leaving the MI= D >> RTP header extension without confidentiality protection. Thus, t= he >> requirements in RFC 7941 MAY be ignored for the MID RTP header >> extension. Security mechanisms for RTP/RTCP are discussed in >> Options >> for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711] c= an >> provide the necessary security functions of ensuring the integrit= y >> and source authenticity. >> >> >> -- >> >> Magnus Westerlund >> >> ------------------------------------------------------------ >> ---------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ------------------------------------------------------------ >> ---------- >> Ericsson AB | Phone +46 10 7148287 >> >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> ------------------------------------------------------------ >> ---------- >> >> >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c034eb01e0238054a621136 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 10, 2017 at 1:51 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Hi,

EKR, I think I understood your issue with the SDP MID usage. I restructured= the section to move the issues with moving the MID into RTP layer as the s= econd paragraph and made it clear that this is a new security consideration= compared to before in the introduction.

Regarding the integrity and authenticity I have made some small changes. I = don't see how removing the requirements help, even if they are normally= resolved when using an existing mechanism. I guess this is is a matter of = view. I am not comfortable with simple assuming that people will use a secu= rity mechanism and therefore this is not an issue. And it makes future work= to analyses potential mechanism a bit harder as one have to redo more anal= ysis, such as in PERC.

What I am trying= to do is to avoid confusing people who think that SRTP is fine but
some other mechanism which they might actually use is not fine. With tha= t said,
I consider your current text to be clear enogh on this po= int.
=C2=A0

Anyway here is an updated text. I have sent the XML of this one to Christer= and he has told me he will update the PR he already have.=


16.=C2=A0 Security Considerations

=C2=A0 =C2=A0The security considerations defined in [RFC3264] and [RFC5888]= apply
=C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not change which in= formation,
 =C2=A0 =C2=A0e.g.=C2=A0 RTP streams, that flows over the network, with the = exception of

e.g. has a comma after it.=

=C2=A0
=C2=A0 =C2=A0the usage of the MID SDES item as discussed below.=C2=A0 Prima= rily it
=C2=A0 =C2=A0changes which addresses and ports, and thus in which (RTP) ses= sions
=C2=A0 =C2=A0that the information is flowing in.=C2=A0 This affects the sec= urity
=C2=A0 =C2=A0contexts being used and can cause previously separated informa= tion
=C2=A0 =C2=A0flows to share security context.=C2=A0 This has very little im= pact on the
 =C2=A0 =C2=A0performance of the security mechanism of the RTP sessions.=C2= =A0 In cases
=C2=A0 =C2=A0where one would have applied different security policies on th= e
=C2=A0 =C2=A0different RTP streams being bundled, or where the parties havi= ng
=C2=A0 =C2=A0access to the security contexts would have differed between th= e RTP
=C2=A0 =C2=A0stream additional analysis of the implications are needed befo= re
=C2=A0 =C2=A0selecting to apply BUNDLE.

=C2=A0 =C2=A0The identification-tag, independent of transport, RTCP SDES pa= cket or
=C2=A0 =C2=A0RTP header extension, can expose the value to parties beyond t= he
=C2=A0 =C2=A0signaling chain.=C2=A0 Therefore, the identification-tag value= s MUST be
=C2=A0 =C2=A0generated in a fashion that does not leak user information, e.= g.,
=C2=A0 =C2=A0randomly or using a per-bundle group counter, and SHOULD be 3 = bytes
=C2=A0 =C2=A0or less, to allow them to efficiently fit into the MID RTP hea= der
=C2=A0 =C2=A0extension.=C2=A0 Note that if implementations use different me= thods for
=C2=A0 =C2=A0generating identification-tags this could enable fingerprintin= g of
=C2=A0 =C2=A0the implementation making it vulnerable to targeted attacks.= =C2=A0 The
=C2=A0 =C2=A0identification-tag is exposed on the RTP stream level when inc= luded
=C2=A0 =C2=A0in the RTP header extensions, however what it reveals of the R= TP
=C2=A0 =C2=A0media stream structure of the endpoint and application was alr= eady
=C2=A0 =C2=A0possible to deduce from the RTP streams without the MID SDES h= eader
=C2=A0 =C2=A0extensions.=C2=A0 As the identification-tag is also used to ro= ute the
=C2=A0 =C2=A0media stream to the right application functionality it is also=
=C2=A0 =C2=A0important that the value received is the one intended by the s= ender,
=C2=A0 =C2=A0thus integrity and the authenticity of the source are importan= t to
=C2=A0 =C2=A0prevent denial of service on the application.=C2=A0 Existing S= RTP
 =C2=A0 =C2=A0configurations and other security mechanisms protecting the wh= ole
=C2=A0 =C2=A0RTP/RTCP packets will provide the necessary protection.

=C2=A0 =C2=A0When the BUNDLE extension is used, a single set of security =C2=A0 =C2=A0credentials over the bundled media descriptions will need to b= e used,
=C2=A0 =C2=A0at least per direction or endpoint.=C2=A0
Actually, why does this have to be the case? I mean, we requir= e it, but
if you have the MID extension, you could easily not do = this.

=C2=A0
W= hen using SRTP this will be the
=C2=A0 =C2=A0case, at least for the IETF defined key-management solutions d= ue to
=C2=A0 =C2=A0their SDP attributes (a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) = and their
=C2=A0 =C2=A0classification in [I-D.ietf-mmusic-sdp-mux-attributes].

=C2=A0 =C2=A0"RTP Header Extension for the RTP Control Protocol (RTCP)= Source
=C2=A0 =C2=A0Description Items" [RFC7941] security consideration requi= res that
=C2=A0 =C2=A0when RTCP is confidentiality protected that any SDES RTP heade= r
=C2=A0 =C2=A0extension carrying an SDES item, like the MID RTP header exten= sion,
=C2=A0 =C2=A0is also protected using commensurate strength algorithms.=C2= =A0 However,
=C2=A0 =C2=A0assuming the above requirements and recommendations are follow= ed
=C2=A0 =C2=A0there are no known significant security risks with leaving the= MID
=C2=A0 =C2=A0RTP header extension without confidentiality protection.=C2=A0= Thus, the
=C2=A0 =C2=A0requirements in RFC 7941 MAY be ignored for the MID RTP header=
=C2=A0 =C2=A0extension.=C2=A0 Security mechanisms for RTP/RTCP are discusse= d in Options
=C2=A0 =C2=A0for Securing RTP Sessions [RFC7201], for example SRTP [RFC3711= ] can
=C2=A0 =C2=A0provide the necessary security functions of ensuring the integ= rity
=C2=A0 =C2=A0and source authenticity.


Den 2017-03-07 kl. 18:47, skrev Eric Rescorla:


On Tue, Mar 7, 2017 at 1:45 AM, Magnus Westerlund
 <mag= nus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.co= m>>

wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 Please see inline.

=C2=A0 =C2=A0 Den 2017-03-06 kl. 14:36, skrev Eric Rescorla:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think you are correct assuming = that one is using SRTP. All the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF key-management scheme follow= s this, although a=3Dmikey is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IDENTICAL. If one uses other secu= rity mechanisms, then this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is still
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 relevant to capture.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Which security mechanisms are you thinking of h= ere?


=C2=A0 =C2=A0 I didn't have any specific security mechanism in mind. I = simply want
=C2=A0 =C2=A0 to make clear the requirements that arises due to the new mec= hanisms
=C2=A0 =C2=A0 that BUNDLE creates. As you commented I can only think of mec= hanism
=C2=A0 =C2=A0 that protects the whole packet.


Yeah, this seems more confusing than illuminating. There are lots of
theoretical
risks that might happen if we had some new security mechanism with unknown<= br> properties.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is this precisely true? Do you ever use the MID= extension w/o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BUNDLE?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 It certainly changes which ICE checks you do.

=C2=A0 =C2=A0 So lets start with the question of MID without using BUNDLE. = As MID
=C2=A0 =C2=A0 is used in grouping of media lines use cases, i.e. RFC 5888 t= here
=C2=A0 =C2=A0 are certainly uses. However, there exist no need to signal MI= Ds on
=C2=A0 =C2=A0 RTP session level in those cases as there already exist a one= to one
=C2=A0 =C2=A0 mapping between the MID and the transport addresses used for = that
=C2=A0 =C2=A0 RTP session. Only with BUNDLE do the RTP streams from the dif= ferent
=C2=A0 =C2=A0 m=3D lines start sharing transport context.


That's what I meant by "MID extension". Sorry for the confusi= on.



=C2=A0 =C2=A0 So strictly the above is incorrect. What was multiple securit= y
=C2=A0 =C2=A0 context due to different RTP sessions, or other sessions are = now
=C2=A0 =C2=A0 moved into a single context. I think we could reformulate thi= s to say:

=C2=A0 =C2=A0 =C2=A0 =C2=A0The security considerations defined in [RFC3264]= and [RFC5888] apply
=C2=A0 =C2=A0 =C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not c= hange which information,
=C2=A0 =C2=A0 =C2=A0 =C2=A0e.g.=C2=A0 RTP streams, that flows over the netw= ork.=C2=A0 Primarily it changes
=C2=A0 =C2=A0 =C2=A0 =C2=A0which addresses and ports, and thus in which (RT= P) sessions that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0information is flowing in.=C2=A0 This affects th= e security contexts being
=C2=A0 =C2=A0 =C2=A0 =C2=A0used and can cause previously separated informat= ion flows to share
=C2=A0 =C2=A0 =C2=A0 =C2=A0security context.=C2=A0 This has very little imp= act on the performance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the security mechanism of the RTP sessions, howe= ver which actors that
=C2=A0 =C2=A0 =C2=A0 =C2=A0are present in a particular security context may= require additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0thoughts when applying Bundle.

=C2=A0 =C2=A0 Is this better?


But it still seems to be false because of the MID signaling in SDP.

I also don't understand the last line.

-Ekr


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The identication-tag is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Still misspelled.


=C2=A0 =C2=A0 Yes, there was actually two misspelled instances left, and I = had
=C2=A0 =C2=A0 corrected one.

=C2=A0 =C2=A0 Full section text after corrections:

=C2=A0 =C2=A0 16.=C2=A0 Security Considerations

=C2=A0 =C2=A0 =C2=A0 =C2=A0The security considerations defined in [RFC3264]= and [RFC5888] apply
=C2=A0 =C2=A0 =C2=A0 =C2=A0to the BUNDLE extension.=C2=A0 Bundle does not c= hange which information,
=C2=A0 =C2=A0 =C2=A0 =C2=A0e.g.=C2=A0 RTP streams, that flows over the netw= ork.=C2=A0 Primarily it changes
=C2=A0 =C2=A0 =C2=A0 =C2=A0which addresses and ports, and thus in which (RT= P) sessions that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0information is flowing in.=C2=A0 This affects th= e security contexts being
=C2=A0 =C2=A0 =C2=A0 =C2=A0used and can cause previously separated informat= ion flows to share
=C2=A0 =C2=A0 =C2=A0 =C2=A0security context.=C2=A0 This has very little imp= act on the performance of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the security mechanism of the RTP sessions, howe= ver which actors that
=C2=A0 =C2=A0 =C2=A0 =C2=A0are present in a particular security context may= require additional
=C2=A0 =C2=A0 =C2=A0 =C2=A0thoughts when applying Bundle.

=C2=A0 =C2=A0 =C2=A0 =C2=A0When the BUNDLE extension is used, a single set = of security
=C2=A0 =C2=A0 =C2=A0 =C2=A0credentials might be used for all media streams = specified by a BUNDLE
=C2=A0 =C2=A0 =C2=A0 =C2=A0group.=C2=A0 When using SRTP this is further req= uired at least for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0IETF defined key-management solutions due to the= ir SDP attributes
=C2=A0 =C2=A0 =C2=A0 =C2=A0(a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) classif= ication in
=C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-mmusic-sdp-mux-attributes].=C2=A0= But for other security
=C2=A0 =C2=A0 =C2=A0 =C2=A0solutions, this may require further consideratio= n.

=C2=A0 =C2=A0 =C2=A0 =C2=A0The identification-tag, independent of transport= , RTCP SDES packet or
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP header extension, can expose the value to pa= rties beyond the
=C2=A0 =C2=A0 =C2=A0 =C2=A0signaling chain.=C2=A0 Therefore, the identifica= tion-tag values MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0generated in a fashion that does not leak user i= nformation, e.g.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0randomly or using a per-bundle group counter, an= d SHOULD be 3 bytes
=C2=A0 =C2=A0 =C2=A0 =C2=A0or less, to allow them to efficiently fit into t= he MID RTP header
=C2=A0 =C2=A0 =C2=A0 =C2=A0extension.=C2=A0 Note that if implementations us= e different methods for
=C2=A0 =C2=A0 =C2=A0 =C2=A0generating identification-tags this could enable= fingerprinting of
=C2=A0 =C2=A0 =C2=A0 =C2=A0the implementation making it vulnerable to targe= ted attacks.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0identification-tag is exposed on the RTP stream = level when included
=C2=A0 =C2=A0 =C2=A0 =C2=A0in the RTP header extensions, however what it re= veals of the RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0media stream structure of the endpoint and appli= cation was already
=C2=A0 =C2=A0 =C2=A0 =C2=A0possible to deduce from the RTP streams without = the MID SDES header
=C2=A0 =C2=A0 =C2=A0 =C2=A0extensions.=C2=A0 As the identification-tag is a= lso used to route the
=C2=A0 =C2=A0 =C2=A0 =C2=A0media stream to the right application functional= ity it is also
=C2=A0 =C2=A0 =C2=A0 =C2=A0important that the value received is the one int= ended by the sender,
=C2=A0 =C2=A0 =C2=A0 =C2=A0thus integrity and the authenticity of the sourc= e are important to
=C2=A0 =C2=A0 =C2=A0 =C2=A0prevent denial of service on the application.=C2= =A0 Existing SRTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0configurations requires integrity protection of = both RTCP and RTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0header extensions.

=C2=A0 =C2=A0 =C2=A0 =C2=A0"RTP Header Extension for the RTP Control P= rotocol (RTCP) Source
=C2=A0 =C2=A0 =C2=A0 =C2=A0Description Items" [RFC7941] security consi= deration requires that
=C2=A0 =C2=A0 =C2=A0 =C2=A0when RTCP is confidentiality protected that any = SDES RTP header
=C2=A0 =C2=A0 =C2=A0 =C2=A0extension carrying an SDES item, like the MID RT= P header extension,
=C2=A0 =C2=A0 =C2=A0 =C2=A0is also protected using commensurate strength al= gorithms.=C2=A0 However,
=C2=A0 =C2=A0 =C2=A0 =C2=A0assuming the above requirements and recommendati= ons are followed
=C2=A0 =C2=A0 =C2=A0 =C2=A0there are no known significant security risks wi= th leaving the MID
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP header extension without confidentiality pro= tection.=C2=A0 Thus, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0requirements in RFC 7941 MAY be ignored for the = MID RTP header
=C2=A0 =C2=A0 =C2=A0 =C2=A0extension.=C2=A0 Security mechanisms for RTP/RTC= P are discussed in Options
=C2=A0 =C2=A0 =C2=A0 =C2=A0for Securing RTP Sessions [RFC7201], for example= SRTP [RFC3711] can
=C2=A0 =C2=A0 =C2=A0 =C2=A0provide the necessary security functions of ensu= ring the integrity
=C2=A0 =C2=A0 =C2=A0 =C2=A0and source authenticity.


=C2=A0 =C2=A0 --

=C2=A0 =C2=A0 Magnus Westerlund

=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 Services, Media and Network features, Ericsson Research EAB/T= XM
=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
=C2=A0 =C2=A0 <tel:%2B46%2010%207148287>
=C2=A0 =C2=A0 F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0949079
 =C2=A0 =C2=A0 <tel:%2B46%2073%200949079>
=C2=A0 =C2=A0 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=
=C2=A0 =C2=A0 <mailto:magnus.westerlund@ericsson.com>
=C2=A0 =C2=A0 --------------------------------------------------------= --------------




--

Magnus Westerlund

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

-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----


--94eb2c034eb01e0238054a621136-- From nobody Fri Mar 10 11:31:55 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 DD949129554 for ; Fri, 10 Mar 2017 11:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 l_gNRnPo0S8v for ; Fri, 10 Mar 2017 11:31:52 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 8F83C1295B7 for ; Fri, 10 Mar 2017 11:31:52 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id v2AJVm1V007781 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Mar 2017 14:31:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1489174309; bh=AdICVvYVrrFViLGAdNamODFJlnM1B45A2wdPBa9scXI=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=INab9FfFY7fVlcSzZjAQl5BRk6EJG5Lt5jfKhE3dU1e3zd+LB3d6LeE0lCNVZ6d3M q+rp7dN1B1HmUyoWuhZZUMYo/7DWBx5yD4uBGqpYZRdugZ1MD1NTY2Gn8sz1z7qtK+ QqZwpK4Zz6fPU+rDzR0GFcsQUd7hCF4KRxs3s0LA= From: "Paul E. Jones" To: "Christer Holmberg" , "Martin Thomson" Date: Fri, 10 Mar 2017 19:31:50 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.28492.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.1 (dublin.packetizer.com [10.165.122.250]); Fri, 10 Mar 2017 14:31:49 -0500 (EST) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] late dtls-id request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 19:31:54 -0000 I submitted a PR. Paul ------ Original Message ------ From: "Christer Holmberg" To: "Paul E. Jones" ; "Martin Thomson"=20 Cc: "mmusic@ietf.org" Sent: 3/10/2017 2:43:43 AM Subject: Re: [MMUSIC] late dtls-id request >So, who will create the pull request? :) > >Regards, > >Christer > >On 10/03/17 06:07, "Paul E. Jones" wrote: > >>Christer, >> >>>>FWIW, I would be happier if you moved the 32 bit requirement to 120 >>>>and raised the minimum to 20, but that's a much bigger change. >>> >>>If people think such change would be useful I personally have no >>>problem >>>implementing it. >> >>Given there are uniqueness requirements for different applications=20 >>(one >>I'm proposing is in PERC), more than 32 bits might be better. We know >>SSRC collisions happen, so more randomness would likely help in many=20 >>use >>cases. >> >>Paul >> > From nobody Fri Mar 10 14:47: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 5365912940F for ; Fri, 10 Mar 2017 14:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_SORBS_SPAM=0.5] 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 VoOYPTAWuMvk for ; Fri, 10 Mar 2017 14:47:46 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66DE1293E8 for ; Fri, 10 Mar 2017 14:47:46 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id j5so46871298pfb.2 for ; Fri, 10 Mar 2017 14:47:46 -0800 (PST) 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=fHFZLs28GhD6VqUiWAy91IPsIZ3An9foSsNMrjmrQ/Y=; b=QlAQnUy/n0162eQb0C4XqrBIYiAU167q0Wxpl8TXpUpIJbSZvRiwWY7jCj19f4BweX M5KJEnYgfhJWf+MynyJyeduzySahAGD1D7PLHQi3giTeiZ5Ve6+YxhzjQ10tEnTbyvhI bU4NK6fPtn9xWhg5/PKO/YYq5/GdXkufWhGiuUTzxvC8SJdynJO3jkhmf11OKTYA/dxi FfLz+NPaS1qQTdG8ohSo3UwkYK3fNLYc95Vpo6WFOJRInSfv8Y7wSndENSC5RNkT+VdW tMYk/kn0bCcWwUPPIBi2ZdXnZ1rdHkQMT4IXiMIbnGZ5k3nJeG3ldZbpALmhx8AnQ87t rX+Q== 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=fHFZLs28GhD6VqUiWAy91IPsIZ3An9foSsNMrjmrQ/Y=; b=YMcXEtl+AA+makShe8DMRuDAHM3vo7d8Tu2lOzAEuIAhrrF6/OCZIrbFImYVWyQCud suA+AE8dUCQ7xX2hZEKQzrzNxkT1m38KvE1ml+UUtosS1x2ag8Po9smTeOokY3PYihyh aVoVQGOivkrbMkZyMmnm5qivEcJRemXtqjyPjUIy11n1zR610WMTpLSrQYFJS2ahttPR 55u9xhPIye9r2Q9PRRCxRrAaaAjFd/8mLmWnQ99ETNxRInoEnnhLxgHJyzmnybg3d7D1 nf+BJp2ISvwccQ3GTqB2DZ+n+JArdMvnGbfYWqrYnYhljE6dDx0yek7BDkk9BVzF25t9 VEcA== X-Gm-Message-State: AMke39ls2JdM9rr46J0KJ1+FPfxfyysCy1vXZtcOf62A5jZrkIOtXpzGeMHqQjIYTFh4SA== X-Received: by 10.84.217.215 with SMTP id d23mr29191233plj.33.1489186066267; Fri, 10 Mar 2017 14:47:46 -0800 (PST) Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com. [209.85.192.178]) by smtp.gmail.com with ESMTPSA id d66sm20472552pfe.90.2017.03.10.14.47.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 14:47:45 -0800 (PST) Received: by mail-pf0-f178.google.com with SMTP id j5so46871060pfb.2 for ; Fri, 10 Mar 2017 14:47:45 -0800 (PST) X-Received: by 10.99.138.202 with SMTP id y193mr23012617pgd.60.1489186064622; Fri, 10 Mar 2017 14:47:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.161.144 with HTTP; Fri, 10 Mar 2017 14:47:44 -0800 (PST) In-Reply-To: References: From: Roman Shpount Date: Fri, 10 Mar 2017 17:47:44 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c03aefa62f5ae054a6826af Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 22:47:48 -0000 --94eb2c03aefa62f5ae054a6826af Content-Type: text/plain; charset=UTF-8 My assumption always was that data is received, decoded and discarded until fingerprint is received and verified. This way DTLS handshake completes, key frames are decoded, but user is nor presented with any unverified media. Regards, _____________ Roman Shpount On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson wrote: > I think that the data channel question is easy, anything other than a > "no" is not acceptable. Data in that form enters the security > boundary for an origin and it doesn't make any sense to risk attack > there. (It's also likely unnecessary, if a half a round trip of > signaling is slower than 5 round trips on the media path, then > something is messed up.) > > I'm in two minds about the media part. For media, you could also > reasonably make the same origin-purity argument. I'm inclined to say > that. But we CAN isolate media from the origin (and we definitely > should if we allow this). > > So, the media that arrives had to comply with your offer. The DTLS > handshake also has to complete, which tells the receiver whether the > media needs to be confidential or not (at which point you can disable > this feature). > > It's also possible that a receiver can require that an ICE > connectivity check was made (though this is inbound only, and I'm > unclear on whether having received an inbound check would normally > prevent the receiver from accepting a packet). > > All told, that's a lot of information about the negotiated session for > an attacker to have. The odds of this being an attack would *seem* to > be low. > > On the other hand, we don't assume confidentiality of signaling; the > security model assumes that all this information is effectively public > and the protection we have against attack is the certificate > fingerprint. This would remove that protection, albeit for a short > duration. > > I have an extra question: does anyone plan to implement this? It's > non-trivial. I think that I know what I'd need to do in Firefox and > it would be quite disruptive. Before committing to do that work > (which I will leave to others closer to this to decide), I'd probably > want more information on the actual advantage that it provides. > > On 10 March 2017 at 07:10, Bernard Aboba wrote: > > In the W3C WEBRTC WG, an issue has been submitted relating to playout of > > unverified media: > > https://github.com/w3c/webrtc-pc/issues/849 > > > > It has been suggested that if the browser is configured to do so, that > > playout be allowed for a limited period (e.g. 5 seconds) prior to > > fingerprint verification: > > https://github.com/w3c/webrtc-pc/pull/1026 > > > > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following > text, > > carried over from RFC 4572: > > > > Note that when the offer/answer model is being used, it is possible > > for a media connection to outrace the answer back to the offerer. > > Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' > > role, it MUST (as specified in RFC 4145 [7]) begin listening for an > > incoming connection as soon as it sends its offer. However, it MUST > > NOT assume that the data transmitted over the TLS connection is valid > > until it has received a matching fingerprint in an SDP answer. If > > the fingerprint, once it arrives, does not match the client's > > certificate, the server endpoint MUST terminate the media connection > > with a bad_certificate error, as stated in the previous paragraph. > > > > Given the outstanding issue relating to handling of unverified media, the > > Chairs of the W3C WEBRTC WG would like to request clarification from the > > IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above > paragraph. > > In particular, what is it permitted for an implementation to do with > > received data and media prior to verification? For example: > > > > 1. May data received over the data channel be provided to the > > application prior to verification? > > a. If the answer to the above is "no", may unverified received > data > > be delivered by the DTLS transport to SCTP, which may buffer it? > > 2. May received media be played out prior to verification? > > > > Bernard Aboba > > On behalf of the W3C WEBRTC WG > > > > _______________________________________________ > > 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 > --94eb2c03aefa62f5ae054a6826af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My assumption always was that data is received, decoded an= d discarded until fingerprint is received and verified. This way DTLS hands= hake completes, key frames are decoded, but user is nor presented with any = unverified media.

Regards,

_____________
Roman Shpount

On Thu, Mar 9, 2017 at 6:58 PM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
I think that the data channel question is easy, anything = other than a
"no" is not acceptable.=C2=A0 Data in that form enters the securi= ty
boundary for an origin and it doesn't make any sense to risk attack
there.=C2=A0 (It's also likely unnecessary, if a half a round trip of signaling is slower than 5 round trips on the media path, then
something is messed up.)

I'm in two minds about the media part. For media, you could also
reasonably make the same origin-purity argument.=C2=A0 I'm inclined to = say
that.=C2=A0 But we CAN isolate media from the origin (and we definitely
should if we allow this).

So, the media that arrives had to comply with your offer.=C2=A0 The DTLS handshake also has to complete, which tells the receiver whether the
media needs to be confidential or not (at which point you can disable
this feature).

It's also possible that a receiver can require that an ICE
connectivity check was made (though this is inbound only, and I'm
unclear on whether having received an inbound check would normally
prevent the receiver from accepting a packet).

All told, that's a lot of information about the negotiated session for<= br> an attacker to have.=C2=A0 The odds of this being an attack would *seem* to=
be low.

On the other hand, we don't assume confidentiality of signaling; the security model assumes that all this information is effectively public
and the protection we have against attack is the certificate
fingerprint.=C2=A0 This would remove that protection, albeit for a short duration.

I have an extra question: does anyone plan to implement this?=C2=A0 It'= s
non-trivial.=C2=A0 I think that I know what I'd need to do in Firefox a= nd
it would be quite disruptive.=C2=A0 Before committing to do that work
(which I will leave to others closer to this to decide), I'd probably want more information on the actual advantage that it provides.

On 10 March 2017 at 07:10, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> In the W3C WEBRTC WG, an issue has been submitted relating to playout = of
> unverified media:
> https://github.com/w3c/webrtc-pc/issues/849=
>
> It has been suggested that if the browser is configured to do so, that=
> playout be allowed for a limited period (e.g. 5 seconds) prior to
> fingerprint verification:
> https://github.com/w3c/webrtc-pc/pull/1026 >
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the foll= owing text,
> carried over from RFC 4572:
>
>=C2=A0 =C2=A0 Note that when the offer/answer model is being used, it i= s possible
>=C2=A0 =C2=A0 for a media connection to outrace the answer back to the = offerer.
>=C2=A0 =C2=A0 Thus, if the offerer has offered a 'setup:passive'= ; or 'setup:actpass'
>=C2=A0 =C2=A0 role, it MUST (as specified in RFC 4145 [7]) begin listen= ing for an
>=C2=A0 =C2=A0 incoming connection as soon as it sends its offer.=C2=A0 = However, it MUST
>=C2=A0 =C2=A0 NOT assume that the data transmitted over the TLS connect= ion is valid
>=C2=A0 =C2=A0 until it has received a matching fingerprint in an SDP an= swer.=C2=A0 If
>=C2=A0 =C2=A0 the fingerprint, once it arrives, does not match the clie= nt's
>=C2=A0 =C2=A0 certificate, the server endpoint MUST terminate the media= connection
>=C2=A0 =C2=A0 with a bad_certificate error, as stated in the previous p= aragraph.
>
> Given the outstanding issue relating to handling of unverified media, = the
> Chairs of the W3C WEBRTC WG would like to request clarification from t= he
> IETF MMUSIC WG as to the meaning of the "MUST NOT" in the ab= ove paragraph.
> In particular, what is it permitted for an implementation to do with > received data and media prior to verification? For example:
>
>=C2=A0 =C2=A0 =C2=A0 1. May data received over the data channel be prov= ided to the
> application prior to verification?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a. If the answer to the above is &qu= ot;no", may unverified received data
> be delivered by the DTLS transport to SCTP, which may buffer it?
>=C2=A0 =C2=A0 =C2=A0 2. May received media be played out prior to verif= ication?
>
> Bernard Aboba
> On behalf of the W3C WEBRTC WG
>
> _______________________________________________
> 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

--94eb2c03aefa62f5ae054a6826af-- From nobody Fri Mar 10 16:01:55 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 B8186129495 for ; Fri, 10 Mar 2017 16:01:53 -0800 (PST) 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 Gx1-ivUODF8r for ; Fri, 10 Mar 2017 16:01:51 -0800 (PST) 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 8E5B31289C4 for ; Fri, 10 Mar 2017 16:01:51 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id v198so33354692ywc.2 for ; Fri, 10 Mar 2017 16:01:51 -0800 (PST) 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=d6vcsAYVjTizPQzZBxoVEu+Ra8OYLid6lG2Q5BXOxLo=; b=BRc9dbyB7XhnwZyfaM2a7brPWaryjfU5LXAh+WeAgGgYNJ42Pz2QWKSZ2s0mO5CbgF E6jCCm+BYNRg1hQzV06rmmCICv3WW1rAJPz77ntcTDUGjFkBqfDR2UlCgTv9zZIE6mow sxjRduYdFvhqKNj8qQE9PF9oKiRMAWLo7oGpVgAtohGTysfh6YwfSimr9l2SKZ4jZyop t6TCTkP3MF74gYeBLItuIFVQpfkPw8AtRime5I6JlM5U/sAKx3viDvIG6mYgZWx2ySNZ SMwfl6Nn94819xzVLXf1a/GXyg8+LFzkuUnZ7PFYWUjMFgcE6h3scfYSU2qwJF7rM6J/ mJEQ== 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=d6vcsAYVjTizPQzZBxoVEu+Ra8OYLid6lG2Q5BXOxLo=; b=FYkviyF6bKhE5+i4a3sUoPSvou0mLPvUbdeXh8v9ajpriie4ieCu+EGBV6KS9TMc7i XWD+/tY4Aoo521isnCACmrkC6iL0LJFm9Zpwj4hDf1K5fihJ+w6FLQDYi2cW6ied+KhC YBGWKD1Eurg675IxPQmujWVe/OHYX9eI6IZECyoDvWWSifvtScocqScvqVNh0WrKr1Zs M1BvfoiFqKTPTqFzf4dnzI0PYsnsvJGdI9DalQvWpesiSqF6MZWFjs4KgF1Syt5Wq3D4 +A0rs3/NWUtRXNuCV3Dx8B9FPsBYHClBxdXVXOHQ16fC76NW3WLITpodoN7qGjqjmHSw iWSA== X-Gm-Message-State: AMke39lyqGIC5c5ho3Af9AKMFndYHKZeaW90nW6b0evsn4aIL431Cd/xhlVuULrEYcVlJUbrCQuQWsnS9rIjYA== X-Received: by 10.37.53.138 with SMTP id c132mr9732277yba.105.1489190510741; Fri, 10 Mar 2017 16:01:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 16:01:10 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 10 Mar 2017 16:01:10 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a114bbb32655e93054a692f5e Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 00:01:54 -0000 --001a114bbb32655e93054a692f5e Content-Type: text/plain; charset=UTF-8 I haven't spent too much time on it, but it seems like it ought to be safe to hold anything you receive prior to getting the fingerprint. It might be better, as MT suggests, to discard the datachannel data, but I'm not sure why it would be necessary. -Ekr On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount wrote: > My assumption always was that data is received, decoded and discarded > until fingerprint is received and verified. This way DTLS handshake > completes, key frames are decoded, but user is nor presented with any > unverified media. > > Regards, > > _____________ > Roman Shpount > > On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson > wrote: > >> I think that the data channel question is easy, anything other than a >> "no" is not acceptable. Data in that form enters the security >> boundary for an origin and it doesn't make any sense to risk attack >> there. (It's also likely unnecessary, if a half a round trip of >> signaling is slower than 5 round trips on the media path, then >> something is messed up.) >> >> I'm in two minds about the media part. For media, you could also >> reasonably make the same origin-purity argument. I'm inclined to say >> that. But we CAN isolate media from the origin (and we definitely >> should if we allow this). >> >> So, the media that arrives had to comply with your offer. The DTLS >> handshake also has to complete, which tells the receiver whether the >> media needs to be confidential or not (at which point you can disable >> this feature). >> >> It's also possible that a receiver can require that an ICE >> connectivity check was made (though this is inbound only, and I'm >> unclear on whether having received an inbound check would normally >> prevent the receiver from accepting a packet). >> >> All told, that's a lot of information about the negotiated session for >> an attacker to have. The odds of this being an attack would *seem* to >> be low. >> >> On the other hand, we don't assume confidentiality of signaling; the >> security model assumes that all this information is effectively public >> and the protection we have against attack is the certificate >> fingerprint. This would remove that protection, albeit for a short >> duration. >> >> I have an extra question: does anyone plan to implement this? It's >> non-trivial. I think that I know what I'd need to do in Firefox and >> it would be quite disruptive. Before committing to do that work >> (which I will leave to others closer to this to decide), I'd probably >> want more information on the actual advantage that it provides. >> >> On 10 March 2017 at 07:10, Bernard Aboba wrote: >> > In the W3C WEBRTC WG, an issue has been submitted relating to playout of >> > unverified media: >> > https://github.com/w3c/webrtc-pc/issues/849 >> > >> > It has been suggested that if the browser is configured to do so, that >> > playout be allowed for a limited period (e.g. 5 seconds) prior to >> > fingerprint verification: >> > https://github.com/w3c/webrtc-pc/pull/1026 >> > >> > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following >> text, >> > carried over from RFC 4572: >> > >> > Note that when the offer/answer model is being used, it is possible >> > for a media connection to outrace the answer back to the offerer. >> > Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' >> > role, it MUST (as specified in RFC 4145 [7]) begin listening for an >> > incoming connection as soon as it sends its offer. However, it MUST >> > NOT assume that the data transmitted over the TLS connection is valid >> > until it has received a matching fingerprint in an SDP answer. If >> > the fingerprint, once it arrives, does not match the client's >> > certificate, the server endpoint MUST terminate the media connection >> > with a bad_certificate error, as stated in the previous paragraph. >> > >> > Given the outstanding issue relating to handling of unverified media, >> the >> > Chairs of the W3C WEBRTC WG would like to request clarification from the >> > IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above >> paragraph. >> > In particular, what is it permitted for an implementation to do with >> > received data and media prior to verification? For example: >> > >> > 1. May data received over the data channel be provided to the >> > application prior to verification? >> > a. If the answer to the above is "no", may unverified received >> data >> > be delivered by the DTLS transport to SCTP, which may buffer it? >> > 2. May received media be played out prior to verification? >> > >> > Bernard Aboba >> > On behalf of the W3C WEBRTC WG >> > >> > _______________________________________________ >> > 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 > > --001a114bbb32655e93054a692f5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I haven't spent too much ti= me on it, but it seems like it ought to be safe to hold
anything you receive prior to getting the fingerprint. It migh= t be better, as MT
suggests, to discard the= datachannel data, but I'm not sure why it would be
necessary.

-Ekr

On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount <roman@telurix.c= om> wrote:
My assumption always was that data is received, decoded and discarded unti= l fingerprint is received and verified. This way DTLS handshake completes, = key frames are decoded, but user is nor presented with any unverified media= .

Regards,

_____________
Roman Shpount

On Thu, Mar 9, 2017 at 6:58 PM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
I think that the data channel question is easy, anything = other than a
"no" is not acceptable.=C2=A0 Data in that form enters the securi= ty
boundary for an origin and it doesn't make any sense to risk attack
there.=C2=A0 (It's also likely unnecessary, if a half a round trip of signaling is slower than 5 round trips on the media path, then
something is messed up.)

I'm in two minds about the media part. For media, you could also
reasonably make the same origin-purity argument.=C2=A0 I'm inclined to = say
that.=C2=A0 But we CAN isolate media from the origin (and we definitely
should if we allow this).

So, the media that arrives had to comply with your offer.=C2=A0 The DTLS handshake also has to complete, which tells the receiver whether the
media needs to be confidential or not (at which point you can disable
this feature).

It's also possible that a receiver can require that an ICE
connectivity check was made (though this is inbound only, and I'm
unclear on whether having received an inbound check would normally
prevent the receiver from accepting a packet).

All told, that's a lot of information about the negotiated session for<= br> an attacker to have.=C2=A0 The odds of this being an attack would *seem* to=
be low.

On the other hand, we don't assume confidentiality of signaling; the security model assumes that all this information is effectively public
and the protection we have against attack is the certificate
fingerprint.=C2=A0 This would remove that protection, albeit for a short duration.

I have an extra question: does anyone plan to implement this?=C2=A0 It'= s
non-trivial.=C2=A0 I think that I know what I'd need to do in Firefox a= nd
it would be quite disruptive.=C2=A0 Before committing to do that work
(which I will leave to others closer to this to decide), I'd probably want more information on the actual advantage that it provides.

On 10 March 2017 at 07:10, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> In the W3C WEBRTC WG, an issue has been submitted relating to playout = of
> unverified media:
> https://github.com/w3c/webrtc-pc/issues/849=
>
> It has been suggested that if the browser is configured to do so, that=
> playout be allowed for a limited period (e.g. 5 seconds) prior to
> fingerprint verification:
> https://github.com/w3c/webrtc-pc/pull/1026 >
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the foll= owing text,
> carried over from RFC 4572:
>
>=C2=A0 =C2=A0 Note that when the offer/answer model is being used, it i= s possible
>=C2=A0 =C2=A0 for a media connection to outrace the answer back to the = offerer.
>=C2=A0 =C2=A0 Thus, if the offerer has offered a 'setup:passive'= ; or 'setup:actpass'
>=C2=A0 =C2=A0 role, it MUST (as specified in RFC 4145 [7]) begin listen= ing for an
>=C2=A0 =C2=A0 incoming connection as soon as it sends its offer.=C2=A0 = However, it MUST
>=C2=A0 =C2=A0 NOT assume that the data transmitted over the TLS connect= ion is valid
>=C2=A0 =C2=A0 until it has received a matching fingerprint in an SDP an= swer.=C2=A0 If
>=C2=A0 =C2=A0 the fingerprint, once it arrives, does not match the clie= nt's
>=C2=A0 =C2=A0 certificate, the server endpoint MUST terminate the media= connection
>=C2=A0 =C2=A0 with a bad_certificate error, as stated in the previous p= aragraph.
>
> Given the outstanding issue relating to handling of unverified media, = the
> Chairs of the W3C WEBRTC WG would like to request clarification from t= he
> IETF MMUSIC WG as to the meaning of the "MUST NOT" in the ab= ove paragraph.
> In particular, what is it permitted for an implementation to do with > received data and media prior to verification? For example:
>
>=C2=A0 =C2=A0 =C2=A0 1. May data received over the data channel be prov= ided to the
> application prior to verification?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a. If the answer to the above is &qu= ot;no", may unverified received data
> be delivered by the DTLS transport to SCTP, which may buffer it?
>=C2=A0 =C2=A0 =C2=A0 2. May received media be played out prior to verif= ication?
>
> Bernard Aboba
> On behalf of the W3C WEBRTC WG
>
> _______________________________________________
> 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

--001a114bbb32655e93054a692f5e-- From nobody Fri Mar 10 16:06: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 5D8D3129495 for ; Fri, 10 Mar 2017 16:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 xX5x26x9-tNC for ; Fri, 10 Mar 2017 16:06:13 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 AE35812948A for ; Fri, 10 Mar 2017 16:06:12 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id q7so113593610uaf.2 for ; Fri, 10 Mar 2017 16:06:12 -0800 (PST) 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=0cwNJPXqY132sJ+Ktm9daPcPO3EvVcAk+u8RmloQtVw=; b=RjY9UAiR1t3wQtt2zSSOQsxCz1PzeKq2FpvSM+GOns3wRWsYwe9yQUAtNtZUPiSl3d ngu18YcQ23aRu35VvtKldPoxBmZaF3+oUMd2HQWCRM+XhQZTJxxnBAUUWOyioSPKRWQN 8A3xJ1UvfwCoYw8nKAxBN5Iea4FYFL1uos8wmgzGrAZEzZstUVpv5b9T1c5BuTr3JCoU brzQpf9hjiFsLXknSl7XSzUbWC/s7KH2SUhIY7kI2/dt0BSextT0w0Otes1JAg/sXTgf n8m2HjEVl/BuoV+/9end56gt8Iz6VW8U/WiZRRdvrTU0WZErriM7bzjGP4wJ0BuERUB0 0/5Q== 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=0cwNJPXqY132sJ+Ktm9daPcPO3EvVcAk+u8RmloQtVw=; b=KHIP9kGyQSEs2CcX3QO797/j2a6elrXEs1JLKOonZBG4PGS9xTvBssytCvhNcw5mCQ VQVh88Pdm9xbkPq6et3PSDa8O1wIcW+32TP7phZ//Gan1b8D/TwhdSj4doHHWi/RD34u GwyQC7jF/cvufdUnfIFydf3B1RBJDZVqF6vAuoaimDmxx30NQ8T3/Qaj8OqROvHWd9x3 AHj1e6omjvy7xkZmgffqd3L1cY2x8ev64+8gnisNdgOWvmQJJLIi155ObutR+xdoIa8e s3kTxhmtq8DUcvrswIML5t1OQYPQuiiYHzAYDtZXt0dP40OgSOBixWEWegBcta4QYjJ2 +Dcw== X-Gm-Message-State: AMke39lQ4sut7AnfgDHymGE6n67wClHxTEDP+tpJ0MJi7TwP8U8DfIbARPSwl74uUS7npeeO8YbGhk+J5FHzBA== X-Received: by 10.176.5.136 with SMTP id e8mr11217783uae.108.1489190771648; Fri, 10 Mar 2017 16:06:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Fri, 10 Mar 2017 16:05:51 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Fri, 10 Mar 2017 16:05:51 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c124874f2751f054a693eca Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 00:06:15 -0000 --94eb2c124874f2751f054a693eca Content-Type: text/plain; charset=UTF-8 EKR said: "I haven't spent too much time on it, but it seems like it ought to be safe to hold anything you receive prior to getting the fingerprint. It might be better, as MT suggests, to discard the datachannel data, but I'm not sure why it would be necessary." [BA] So you are saying that the MUST NOT allows the browser to buffer data/media but not to pass it to the application (in the case of the data channel) or to play it out? On Fri, Mar 10, 2017 at 4:01 PM, Eric Rescorla wrote: > I haven't spent too much time on it, but it seems like it ought to be safe > to hold > anything you receive prior to getting the fingerprint. It might be better, > as MT > suggests, to discard the datachannel data, but I'm not sure why it would be > necessary. > > -Ekr > > On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount wrote: > >> My assumption always was that data is received, decoded and discarded >> until fingerprint is received and verified. This way DTLS handshake >> completes, key frames are decoded, but user is nor presented with any >> unverified media. >> >> Regards, >> >> _____________ >> Roman Shpount >> >> On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson >> wrote: >> >>> I think that the data channel question is easy, anything other than a >>> "no" is not acceptable. Data in that form enters the security >>> boundary for an origin and it doesn't make any sense to risk attack >>> there. (It's also likely unnecessary, if a half a round trip of >>> signaling is slower than 5 round trips on the media path, then >>> something is messed up.) >>> >>> I'm in two minds about the media part. For media, you could also >>> reasonably make the same origin-purity argument. I'm inclined to say >>> that. But we CAN isolate media from the origin (and we definitely >>> should if we allow this). >>> >>> So, the media that arrives had to comply with your offer. The DTLS >>> handshake also has to complete, which tells the receiver whether the >>> media needs to be confidential or not (at which point you can disable >>> this feature). >>> >>> It's also possible that a receiver can require that an ICE >>> connectivity check was made (though this is inbound only, and I'm >>> unclear on whether having received an inbound check would normally >>> prevent the receiver from accepting a packet). >>> >>> All told, that's a lot of information about the negotiated session for >>> an attacker to have. The odds of this being an attack would *seem* to >>> be low. >>> >>> On the other hand, we don't assume confidentiality of signaling; the >>> security model assumes that all this information is effectively public >>> and the protection we have against attack is the certificate >>> fingerprint. This would remove that protection, albeit for a short >>> duration. >>> >>> I have an extra question: does anyone plan to implement this? It's >>> non-trivial. I think that I know what I'd need to do in Firefox and >>> it would be quite disruptive. Before committing to do that work >>> (which I will leave to others closer to this to decide), I'd probably >>> want more information on the actual advantage that it provides. >>> >>> On 10 March 2017 at 07:10, Bernard Aboba >>> wrote: >>> > In the W3C WEBRTC WG, an issue has been submitted relating to playout >>> of >>> > unverified media: >>> > https://github.com/w3c/webrtc-pc/issues/849 >>> > >>> > It has been suggested that if the browser is configured to do so, that >>> > playout be allowed for a limited period (e.g. 5 seconds) prior to >>> > fingerprint verification: >>> > https://github.com/w3c/webrtc-pc/pull/1026 >>> > >>> > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the >>> following text, >>> > carried over from RFC 4572: >>> > >>> > Note that when the offer/answer model is being used, it is possible >>> > for a media connection to outrace the answer back to the offerer. >>> > Thus, if the offerer has offered a 'setup:passive' or >>> 'setup:actpass' >>> > role, it MUST (as specified in RFC 4145 [7]) begin listening for an >>> > incoming connection as soon as it sends its offer. However, it MUST >>> > NOT assume that the data transmitted over the TLS connection is >>> valid >>> > until it has received a matching fingerprint in an SDP answer. If >>> > the fingerprint, once it arrives, does not match the client's >>> > certificate, the server endpoint MUST terminate the media connection >>> > with a bad_certificate error, as stated in the previous paragraph. >>> > >>> > Given the outstanding issue relating to handling of unverified media, >>> the >>> > Chairs of the W3C WEBRTC WG would like to request clarification from >>> the >>> > IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above >>> paragraph. >>> > In particular, what is it permitted for an implementation to do with >>> > received data and media prior to verification? For example: >>> > >>> > 1. May data received over the data channel be provided to the >>> > application prior to verification? >>> > a. If the answer to the above is "no", may unverified >>> received data >>> > be delivered by the DTLS transport to SCTP, which may buffer it? >>> > 2. May received media be played out prior to verification? >>> > >>> > Bernard Aboba >>> > On behalf of the W3C WEBRTC WG >>> > >>> > _______________________________________________ >>> > 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 >> >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c124874f2751f054a693eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
EKR said:=C2=A0

"I haven't spent too much time on it, but it seems like = it ought to be safe to hold
anything you receive prior to getting the fingerprint. I= t might be better, as MT
suggests, to discard the datachannel data, but I'm not sure wh= y it would be
necessary.&= quot;

[BA] So you are saying that the MUST NOT all= ows the browser to buffer data/media but not to pass it to the application = (in the case of the data channel) or to play it out?

On Fri, Mar 10, 2017 at 4:0= 1 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I haven't spent = too much time on it, but it seems like it ought to be safe to hold
anything you receive prior to getting the fingerpri= nt. It might be better, as MT
suggests, to = discard the datachannel data, but I'm not sure why it would be
necessary.

-Ekr

On Fri, Mar 10, 2017 at 2:47 P= M, Roman Shpount <roman@telurix.com> wrote:
My assumption always was that data is re= ceived, decoded and discarded until fingerprint is received and verified. T= his way DTLS handshake completes, key frames are decoded, but user is nor p= resented with any unverified media.

Regards,
=

_____________
Roman Shpount

On Thu, Mar 9, 2017 at 6:58 PM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
I think that the data channel question is easy, anything = other than a
"no" is not acceptable.=C2=A0 Data in that form enters the securi= ty
boundary for an origin and it doesn't make any sense to risk attack
there.=C2=A0 (It's also likely unnecessary, if a half a round trip of signaling is slower than 5 round trips on the media path, then
something is messed up.)

I'm in two minds about the media part. For media, you could also
reasonably make the same origin-purity argument.=C2=A0 I'm inclined to = say
that.=C2=A0 But we CAN isolate media from the origin (and we definitely
should if we allow this).

So, the media that arrives had to comply with your offer.=C2=A0 The DTLS handshake also has to complete, which tells the receiver whether the
media needs to be confidential or not (at which point you can disable
this feature).

It's also possible that a receiver can require that an ICE
connectivity check was made (though this is inbound only, and I'm
unclear on whether having received an inbound check would normally
prevent the receiver from accepting a packet).

All told, that's a lot of information about the negotiated session for<= br> an attacker to have.=C2=A0 The odds of this being an attack would *seem* to=
be low.

On the other hand, we don't assume confidentiality of signaling; the security model assumes that all this information is effectively public
and the protection we have against attack is the certificate
fingerprint.=C2=A0 This would remove that protection, albeit for a short duration.

I have an extra question: does anyone plan to implement this?=C2=A0 It'= s
non-trivial.=C2=A0 I think that I know what I'd need to do in Firefox a= nd
it would be quite disruptive.=C2=A0 Before committing to do that work
(which I will leave to others closer to this to decide), I'd probably want more information on the actual advantage that it provides.

On 10 March 2017 at 07:10, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> In the W3C WEBRTC WG, an issue has been submitted relating to playout = of
> unverified media:
> https://github.com/w3c/webrtc-pc/issues/849=
>
> It has been suggested that if the browser is configured to do so, that=
> playout be allowed for a limited period (e.g. 5 seconds) prior to
> fingerprint verification:
> https://github.com/w3c/webrtc-pc/pull/1026 >
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the foll= owing text,
> carried over from RFC 4572:
>
>=C2=A0 =C2=A0 Note that when the offer/answer model is being used, it i= s possible
>=C2=A0 =C2=A0 for a media connection to outrace the answer back to the = offerer.
>=C2=A0 =C2=A0 Thus, if the offerer has offered a 'setup:passive'= ; or 'setup:actpass'
>=C2=A0 =C2=A0 role, it MUST (as specified in RFC 4145 [7]) begin listen= ing for an
>=C2=A0 =C2=A0 incoming connection as soon as it sends its offer.=C2=A0 = However, it MUST
>=C2=A0 =C2=A0 NOT assume that the data transmitted over the TLS connect= ion is valid
>=C2=A0 =C2=A0 until it has received a matching fingerprint in an SDP an= swer.=C2=A0 If
>=C2=A0 =C2=A0 the fingerprint, once it arrives, does not match the clie= nt's
>=C2=A0 =C2=A0 certificate, the server endpoint MUST terminate the media= connection
>=C2=A0 =C2=A0 with a bad_certificate error, as stated in the previous p= aragraph.
>
> Given the outstanding issue relating to handling of unverified media, = the
> Chairs of the W3C WEBRTC WG would like to request clarification from t= he
> IETF MMUSIC WG as to the meaning of the "MUST NOT" in the ab= ove paragraph.
> In particular, what is it permitted for an implementation to do with > received data and media prior to verification? For example:
>
>=C2=A0 =C2=A0 =C2=A0 1. May data received over the data channel be prov= ided to the
> application prior to verification?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a. If the answer to the above is &qu= ot;no", may unverified received data
> be delivered by the DTLS transport to SCTP, which may buffer it?
>=C2=A0 =C2=A0 =C2=A0 2. May received media be played out prior to verif= ication?
>
> Bernard Aboba
> On behalf of the W3C WEBRTC WG
>
> _______________________________________________
> 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


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

--94eb2c124874f2751f054a693eca-- From nobody Fri Mar 10 16:18: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 0B4E11294DA for ; Fri, 10 Mar 2017 16:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 2Oi1RaX8VZiJ for ; Fri, 10 Mar 2017 16:18:16 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 BE8B31294CF for ; Fri, 10 Mar 2017 16:18:16 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id u30so131282353uau.0 for ; Fri, 10 Mar 2017 16:18:16 -0800 (PST) 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=FuljHNS8qlzaJbox3o66RHmcSZxBrLHn95USzDADBeo=; b=bm7TXb5j0vQtlDIOkWnx7rNOVzRTp8pqPU85/ax5Xl2dM/SNJL6UtwSiE43wfrhGtO YSI36VZ1uV9aTyBlIK6xMTlehH++ihbua30A+2iTYNZUIg4pdfXL5jVVOZlhojmE0Wuf zpALPBiO3XQ+x0nxByyMqQvZdQhnAdMzsim8Af9cR85qXWYC4s1eRqqhHhUiIA/AKH2F wJxU5PzAuH3d61VqpxzBu7FAzNKVNtJts+pwVrY2FkuUEaxjGRDO5SErv0ufaZz/1PnQ MhTeSmFsats8F0Fottf8P7i9VOpGaMo5XkZVCfxqthHSe/JSrtwkfbP5stbD+AX7cmvf EaQQ== 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=FuljHNS8qlzaJbox3o66RHmcSZxBrLHn95USzDADBeo=; b=paoyg0X1ZvSIf3tbgsM+JTQpsraKkU14VGUx5a3Ty0GLR7952hHsNKmyGpf451IJpf bjkszFV1HBskSdV0rd6Tn09Dh8j2zAaJ5jdBTqRkVclER/Bg7gEWdJbdl7bHDryY+iWx d9iaA6zlXN/DNZXyCyhotXtmCuq6S1vpxO+q1gJk5hnefQNxq4y9yYn5MxcFKsF/quru k+Ga9LNpAh/yBL0bF0Vx/Qolu0iMfTffjRqIQEpgpdrAHHgVUw0k6PZp/QmRkS0DD3YS 69dlE3GZliuiOoctVBJwIVFJnCvGDsjsQQYZ0ycgRaj7QvLOmq8aljU5n/AfF4qIoNbH bvfQ== X-Gm-Message-State: AMke39mPXN+qnx0tzrcv1fMv5FNYWm7+MmTDo6Z/y37wLF39vv9cwPZJMEnA0QtYjbkcPdEDgK+8h8qxqypcMw== X-Received: by 10.176.66.66 with SMTP id i60mr11422750uai.131.1489191495793; Fri, 10 Mar 2017 16:18:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Fri, 10 Mar 2017 16:17:55 -0800 (PST) In-Reply-To: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> From: Bernard Aboba Date: Fri, 10 Mar 2017 16:17:55 -0800 Message-ID: To: Flemming Andreasen Content-Type: multipart/alternative; boundary=94eb2c0939ce1c0bf3054a696a26 Archived-At: Cc: "hta@google.com" , mmusic , stefan hakansson Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 00:18:18 -0000 --94eb2c0939ce1c0bf3054a696a26 Content-Type: text/plain; charset=UTF-8 I would like a short slot (10 minutes?) relating to interpretation of draft-ietf-mmusic-4572-update with respect to "Unverified data/media". On Fri, Mar 10, 2017 at 6:36 AM, Flemming Andreasen wrote: > Greetings > > The initial draft agenda for the MMUSIC meeting in Chicago has now been > uploaded to: > > https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00 > > We still have a bit of room on the agenda, so let us know of any > additional agenda requests (before March 15) > > Thanks > > Flemming & Bo > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c0939ce1c0bf3054a696a26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like a short slot (10 minutes?) relating to interp= retation of draft-ietf-mmusic-4572-update with respect to "Unverified = data/media".=C2=A0


On Fri, Mar 10, 2017 at 6:36 AM, Flem= ming Andreasen <fandreas@cisco.com> wrote:
Greetings

The initial draft agenda for the MMUSIC meeting in Chicago has now been upl= oaded to:

=C2=A0 =C2=A0 https://www.ietf.org/pro= ceedings/98/agenda/agenda-98-mmusic-00

We still have a bit of room on the agenda, so let us know of any additional= agenda requests (before March 15)

Thanks

=C2=A0 =C2=A0 Flemming & Bo

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

--94eb2c0939ce1c0bf3054a696a26-- From nobody Fri Mar 10 16:31: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 3749C1289C4; Fri, 10 Mar 2017 16:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 F4aWVEzulqgf; Fri, 10 Mar 2017 16:31:55 -0800 (PST) Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) (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 45AF9129495; Fri, 10 Mar 2017 16:31:55 -0800 (PST) Received: by mail-wr0-f179.google.com with SMTP id l37so74106777wrc.1; Fri, 10 Mar 2017 16:31:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xXtYOteH60pVABS19KSWxmCzyP8TSATaU/qqtJZ2Cgc=; b=dcK28e97/5e5JcNtX15js7t1j2RPFVWudwlgyrr+sRV+Gm80x+TosvJj8RVYDeGKIW CjsE1qCTYtqRF3bIgCEJWhOGTic58qrSmpEyGWPJ/FRh2zayyM3iCHfbruZOQy/q8EIR +q92Qmr3gJvMRRMvBM9UXtE0CWkmspyKNafaXPT+z5kzmjbVMnkLFtDnP/rWAhSAyIZr ZltJYBIrALSQQnKKQBztjSgHZ2uIGQN29BLecG3TGNric6ckV5UncoiDURBmv983WPND 6JyOBClmgE4F0ot/Pz8P3jA6jLwErB+ddOroZCUBz/yQkX/9ovESagI5a/QpwdB4jQR3 IYoQ== X-Gm-Message-State: AMke39nid/H9tvOgk11JIclwkhgZWzBzeIsfrxsbgW4i2iWrKTntLTbdjtguli2MEshkizVUutVdfnLz9LbUBA== X-Received: by 10.223.150.205 with SMTP id u71mr17898189wrb.195.1489192313749; Fri, 10 Mar 2017 16:31:53 -0800 (PST) MIME-Version: 1.0 References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> <0e84fe0e-8e50-7b9f-bede-76ebf293a0d8@ericsson.com> In-Reply-To: From: Justin Uberti Date: Sat, 11 Mar 2017 00:31:42 +0000 Message-ID: To: Christer Holmberg , "Cullen Jennings (fluffy)" , Magnus Westerlund Content-Type: multipart/alternative; boundary=f403045f584edd0640054a699ad1 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , RTCWeb IETF , "mmusic \(E-mail\)" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 00:31:57 -0000 --f403045f584edd0640054a699ad1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The new jsep-19 draft incorporates the outcome of said PRs. Please take a look at the new Appendix C. On Thu, Mar 2, 2017 at 4:49 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: Hi, Where are we on this? I see Cullen=C2=B9s pull requests, but I don=C2=B9t t= hink think there are many agreements. Or? Regards, Christer On 15/02/17 15:09, "Cullen Jennings (fluffy)" wrote: > >To try and help get you text merged in, I separated your text up into a >bunch of PRs so that the diffs were all clear and each PR tried to deal >with one issue. There are all in github now and commenting on theses >would probably be the easies way to get to some combined text. > > >> On Feb 14, 2017, at 7:20 AM, Magnus Westerlund >> wrote: >> >> Hi, >> >> Thanks for the feedback. Sorry for my delay in responding, a cold have >> kept from work. >> >> Den 2017-02-02 kl. 23:19, skrev Cullen Jennings (fluffy): >>> >>> So I much prefer the current text and think there are a bunch of >>> problems with this text. If we actually had emails explaining what >>> problems in the current text this was trying to fix, with individual >>> PRs for those, this would be much easier to resolve each of them and >>> get them fixed. >>> >>> 1) we have been trying to avoid the use of "RTP session" as it has >>> been very unclear to implementors what it is. I think this would be >>> better if we could rephrase to not use that >> >> Okay, but the RTP session is very easy to make clear in the context in >> of BUNDLE, where this text is intended to be. I can improve that. >> >>> >>> 2) both the proposed and current text seem lacking in dealing with >>> multiple bundle groups >> >> Okay, that can be fixed by clarifying that each bundle group results in >> its own RTP session, thus the procedures in this is per bundle group. >> >>> >>> 3) Stats are typically maintained by things after the packet is >>> routed - not before. >> >> So this comes a question of ones view of RTP stack and the question of >> layering. And this is exactly why I think the current text is >> problematic. It takes one very particular view, why I attempted to be >> much more neutral on which order things happens. There are a number of >> functions that are in the RTP protocol layer, not in the higher layers. >> There are however some things, like XR VoIP metrcis that are metrics in >> the higher layers. So, yes this is not clear cut. I think ones view of >> this depends on if one have a very integrated RTP implementation, then >> what you say makes sense, but if one has a very layered and modularized >> design, then my viewpoint makes more sense. >> >> From my perspective the most important thing here is that this text if >> it contains any RFC 2119 words can't prevent some possible >> implementation choices of the RTP stack. >> >>> >>> 4) Need to explain how the SDES in compound RTCP causes updates >>> >> >> I can attempt to clarify this. However, there is a potential issue here >> in that some implementations may not be able to force the receiver to >> process the content of the SDES RTCP packet prior to some or even all >> the other RTCP packets in a compound packet. >> >> What in the current text: >> >> On reception of any compound RTCP packet prior to dispatching the >> received information and data, if there is an RTCP SDES packet >> included that SHOULD be processed first. If that SDES packet >> contains SDES MID entries, this can results in updates and additions >> to the RTP stream to "m=3D" line mapping table. Thus each of the SDE= S >> MID items are processed and the current table entries are checked if >> the corresponding MID value matches the current RTP stream to "m=3D" >> line mapping, else the entry is updated. If there is no RTP stream >> to "m=3D" line table mapping entry for the received SDES item's SSRC, >> such an entry is created. Note, that in the process of updating the >> table entries, update flap suppression as discussed in Section 4.2.6 >> of [RFC7941] should be considered. >> >> Is insufficient in that regards. Is it only the placement prior to the >> individual RTCP packet types that is the issue? Should with the >> exception of the first sentence be moved under the SDES text? >> >>> 5) given this removes the outgoing SSRC table, not clear how it >>> routes RTCP reports. I think this needs to be clarified. >>> >> >> Okay, I think I understand that. I have an implicit assumption that the >> implementation knows how its local (outgoing) RTP Streams are related to >> the media sources and thus the related RTPsender. I can update the text >> to address this. >> >>> 6) I don't think most implementers are going to have a clue what to >>> do for the "Third Party Targeted Reports or Feedback" section >>> >> >> I can understand that, but I think it is important to call out that this >> bucket do exist, and if you don't know what to do I think it is fine to >> ignore these. >> >>> I will try and take your PR and break it up into some bit size pieces >>> so we can try and see if we can get the easy ones out of the way and >>> focus on the parts that are key changes. >>> >> >> Ok, I have seen that you generated a lot of individual issues, I will >>attempt to look through them and comment if there are things that was >>unintentional or where I have additional aspects to add. >> >> I intend to update my PR based on the feedback I received. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 <+46%2010%20714%2082%2087> >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 <+46%2073%20094%2090%2079> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> > --f403045f584edd0640054a699ad1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The new=C2=A0jsep-19 draft incorporates the outcome of said PRs. Please take a look at the new Appen= dix C.

On Thu, Mar 2, 2017 at 4:49 AM Christer = Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

Where are we on this? I see Cullen=C2=B9s pull requests, but I don=C2=B9t t= hink
think there are many agreements. Or?

Regards,

Christer


On 15/02/17 15:09, "Cullen Jennings (fluffy)" <fluffy@cisco.com= > wrote:

>
>To try and help get you text merged in, I separated your text up into a=
>bunch of PRs so that the diffs were all clear and each PR tried to deal=
>with one issue. There are all in github now and commenting on theses >would probably be the easies way to get to some combined text.
>
>
>> On Feb 14, 2017, at 7:20 AM, Magnus Westerlund
>><magnus.westerlund@ericsson.com> wrote:
>>
>> Hi,
>>
>> Thanks for the feedback. Sorry for my delay in responding, a cold = have
>> kept from work.
>>
>> Den 2017-02-02 kl. 23:19, skrev Cullen Jennings (fluffy):
>>>
>>> So I much prefer the current text and think there are a bunch = of
>>> problems with this text. If we actually had emails explaining = what
>>> problems in the current text this was trying to fix, with indi= vidual
>>> PRs for those, this would be much easier to resolve each of th= em and
>>> get them fixed.
>>>
>>> 1) we have been trying to avoid the use of "RTP session&q= uot; as it has
>>> been very unclear to implementors what it is. I think this wou= ld be
>>> better if we could rephrase to not use that
>>
>> Okay, but the RTP session is very easy to make clear in the contex= t in
>> of BUNDLE, where this text is intended to be. I can improve that.<= br class=3D"gmail_msg"> >>
>>>
>>> 2) both the proposed and current text seem lacking in dealing = with
>>> multiple bundle groups
>>
>> Okay, that can be fixed by clarifying that each bundle group resul= ts in
>> its own RTP session, thus the procedures in this is per bundle gro= up.
>>
>>>
>>> 3) Stats are typically maintained by things after the packet i= s
>>> routed - not before.
>>
>> So this comes a question of ones view of RTP stack and the questio= n of
>> layering. And this is exactly why I think the current text is
>> problematic. It takes one very particular view, why I attempted to= be
>> much more neutral on which order things happens. There are a numbe= r of
>> functions that are in the RTP protocol layer, not in the higher la= yers.
>> There are however some things, like XR VoIP metrcis that are metri= cs in
>> the higher layers. So, yes this is not clear cut. I think ones vie= w of
>> this depends on if one have a very integrated RTP implementation, = then
>> what you say makes sense, but if one has a very layered and modula= rized
>> design, then my viewpoint makes more sense.
>>
>> From my perspective the most important thing here is that this tex= t if
>> it contains any RFC 2119 words can't prevent some possible
>> implementation choices of the RTP stack.
>>
>>>
>>> 4) Need to explain how the SDES in compound RTCP causes update= s
>>>
>>
>> I can attempt to clarify this. However, there is a potential issue= here
>> in that some implementations may not be able to force the receiver= to
>> process the content of the SDES RTCP packet prior to some or even = all
>> the other RTCP packets in a compound packet.
>>
>> What in the current text:
>>
>>=C2=A0 =C2=A0 On reception of any compound RTCP packet prior to dis= patching the
>>=C2=A0 =C2=A0 received information and data, if there is an RTCP SD= ES packet
>>=C2=A0 =C2=A0 included that SHOULD be processed first.=C2=A0 If tha= t SDES packet
>>=C2=A0 =C2=A0 contains SDES MID entries, this can results in update= s and additions
>>=C2=A0 =C2=A0 to the RTP stream to "m=3D" line mapping ta= ble.=C2=A0 Thus each of the SDES
>>=C2=A0 =C2=A0 MID items are processed and the current table entries= are checked if
>>=C2=A0 =C2=A0 the corresponding MID value matches the current RTP s= tream to "m=3D"
>>=C2=A0 =C2=A0 line mapping, else the entry is updated.=C2=A0 If the= re is no RTP stream
>>=C2=A0 =C2=A0 to "m=3D" line table mapping entry for the = received SDES item's SSRC,
>>=C2=A0 =C2=A0 such an entry is created.=C2=A0 Note, that in the pro= cess of updating the
>>=C2=A0 =C2=A0 table entries, update flap suppression as discussed i= n Section 4.2.6
>>=C2=A0 =C2=A0 of [RFC7941] should be considered.
>>
>> Is insufficient in that regards. Is it only the placement prior to= the
>> individual RTCP packet types that is the issue? Should with the >> exception of the first sentence be moved under the SDES text?
>>
>>> 5) given this removes the outgoing SSRC table, not clear how i= t
>>> routes RTCP reports. I think this needs to be clarified.
>>>
>>
>> Okay, I think I understand that. I have an implicit assumption tha= t the
>> implementation knows how its local (outgoing) RTP Streams are rela= ted to
>> the media sources and thus the related RTPsender. I can update the= text
>> to address this.
>>
>>> 6) I don't think most implementers are going to have a clu= e what to
>>> do for the "Third Party Targeted Reports or Feedback"= ; section
>>>
>>
>> I can understand that, but I think it is important to call out tha= t this
>> bucket do exist, and if you don't know what to do I think it i= s fine to
>> ignore these.
>>
>>> I will try and take your PR and break it up into some bit size= pieces
>>> so we can try and see if we can get the easy ones out of the w= ay and
>>> focus on the parts that are key changes.
>>>
>>
>> Ok, I have seen that you generated a lot of individual issues, I w= ill
>>attempt to look through them and comment if there are things that w= as
>>unintentional or where I have additional aspects to add.
>>
>> I intend to update my PR based on the feedback I received.
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ------------------------------------------------------------------= ----
>> Services, Media and Network features, Ericsson Research EAB/TXM >> ------------------------------------------------------------------= ----
>> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| Phone=C2=A0 +46 10 7148287
>> F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlu= nd@ericsson.com
>> ------------------------------------------------------------------= ----
>>
>

--f403045f584edd0640054a699ad1-- From nobody Fri Mar 10 16:57:23 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 0FCE8129436 for ; Fri, 10 Mar 2017 16:57:22 -0800 (PST) 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 MypsMrlytfDy for ; Fri, 10 Mar 2017 16:57:20 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002: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 3D7161289C4 for ; Fri, 10 Mar 2017 16:57:20 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id p77so33809369ywg.1 for ; Fri, 10 Mar 2017 16:57:20 -0800 (PST) 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=wILVOjxFeM0F6d80fMowP3v/ynXwOd/bKQvntsWWOwo=; b=uczFv8KAexKKX6MFlu0PpSOuGQqPnCQZf9irLftVWTk9Ft2qWxGjf6li8+Q25Tchve Vaz8oHppO+8HCkGfla7O2ZRenGpcl5EGxo30VJ+sooiISkW3bi5gg7hIvnVMjapuAD49 q8TGWcIZ14gxw1tmH0jiENOtTvsYJv9CQKDLxOo1WDHTdIq5emSm9Nsfa4JiJed1ax6z Rt+/UyDWp7X4MfCwoGg6PZRnWIF7HpKz0v83j7UAvO/zxzt1VrqxZeITrFCxeZWzfXui pPv5GWq3TTctBTlbTRU0ToU3upgH4fn9L4As1nHkNcO1AloKcGIGxcdHMtPwkqRFNFKd yeYQ== 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=wILVOjxFeM0F6d80fMowP3v/ynXwOd/bKQvntsWWOwo=; b=tfHsjgbQ6SlC1zqddWoTk+qucYO5g5ERCCkHDhb0cKFjBlz3qMA+GyXi9fECcg/lhq ABGUYhzlB7HblYM09KyaiTFsTpov768TiNlzNgjGJuk8p/FzntpUUp/ZcvjJdN1jISgj 6Fcsn28dEAfutg4UwALFN+TxUuJXrwdkKkUD1DUEnJAT3/FnKV4BjK82NSDuIt4+68S8 owmBkYVHFMSqs13fRt4CZIVIEuCbUxUNt2DzWLQVC/srcG8f37C4WlNn/wxrJC3yBJH+ UUvikHzpG4udbL8oYEtv4+T8ZMu3kwzbd1KpSZQAeNnTS79+kjpD/6eo/6zaH4qGPFny ToUA== X-Gm-Message-State: AMke39nJUrfpBg7luU6u9C7VXSITXhS0qxpzy883M6F37WSP4wiHGcBk7J/l5NAPxLxo1oya13z+6DMFy6iHpA== X-Received: by 10.129.125.5 with SMTP id y5mr9563023ywc.120.1489193839505; Fri, 10 Mar 2017 16:57:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 10 Mar 2017 16:56:38 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 10 Mar 2017 16:56:38 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a11493644ce54aa054a69f5b6 Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 00:57:22 -0000 --001a11493644ce54aa054a69f5b6 Content-Type: text/plain; charset=UTF-8 Sorry, no, I was just talking about what might or might not be safe.... The doc text is a different question. -Ekr On Fri, Mar 10, 2017 at 4:05 PM, Bernard Aboba wrote: > EKR said: > > "I haven't spent too much time on it, but it seems like it ought to be > safe to hold > anything you receive prior to getting the fingerprint. It might be better, > as MT > suggests, to discard the datachannel data, but I'm not sure why it would be > necessary." > > [BA] So you are saying that the MUST NOT allows the browser to buffer > data/media but not to pass it to the application (in the case of the data > channel) or to play it out? > > On Fri, Mar 10, 2017 at 4:01 PM, Eric Rescorla wrote: > >> I haven't spent too much time on it, but it seems like it ought to be >> safe to hold >> anything you receive prior to getting the fingerprint. It might be >> better, as MT >> suggests, to discard the datachannel data, but I'm not sure why it would >> be >> necessary. >> >> -Ekr >> >> On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount wrote: >> >>> My assumption always was that data is received, decoded and discarded >>> until fingerprint is received and verified. This way DTLS handshake >>> completes, key frames are decoded, but user is nor presented with any >>> unverified media. >>> >>> Regards, >>> >>> _____________ >>> Roman Shpount >>> >>> On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson >> > wrote: >>> >>>> I think that the data channel question is easy, anything other than a >>>> "no" is not acceptable. Data in that form enters the security >>>> boundary for an origin and it doesn't make any sense to risk attack >>>> there. (It's also likely unnecessary, if a half a round trip of >>>> signaling is slower than 5 round trips on the media path, then >>>> something is messed up.) >>>> >>>> I'm in two minds about the media part. For media, you could also >>>> reasonably make the same origin-purity argument. I'm inclined to say >>>> that. But we CAN isolate media from the origin (and we definitely >>>> should if we allow this). >>>> >>>> So, the media that arrives had to comply with your offer. The DTLS >>>> handshake also has to complete, which tells the receiver whether the >>>> media needs to be confidential or not (at which point you can disable >>>> this feature). >>>> >>>> It's also possible that a receiver can require that an ICE >>>> connectivity check was made (though this is inbound only, and I'm >>>> unclear on whether having received an inbound check would normally >>>> prevent the receiver from accepting a packet). >>>> >>>> All told, that's a lot of information about the negotiated session for >>>> an attacker to have. The odds of this being an attack would *seem* to >>>> be low. >>>> >>>> On the other hand, we don't assume confidentiality of signaling; the >>>> security model assumes that all this information is effectively public >>>> and the protection we have against attack is the certificate >>>> fingerprint. This would remove that protection, albeit for a short >>>> duration. >>>> >>>> I have an extra question: does anyone plan to implement this? It's >>>> non-trivial. I think that I know what I'd need to do in Firefox and >>>> it would be quite disruptive. Before committing to do that work >>>> (which I will leave to others closer to this to decide), I'd probably >>>> want more information on the actual advantage that it provides. >>>> >>>> On 10 March 2017 at 07:10, Bernard Aboba >>>> wrote: >>>> > In the W3C WEBRTC WG, an issue has been submitted relating to playout >>>> of >>>> > unverified media: >>>> > https://github.com/w3c/webrtc-pc/issues/849 >>>> > >>>> > It has been suggested that if the browser is configured to do so, that >>>> > playout be allowed for a limited period (e.g. 5 seconds) prior to >>>> > fingerprint verification: >>>> > https://github.com/w3c/webrtc-pc/pull/1026 >>>> > >>>> > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the >>>> following text, >>>> > carried over from RFC 4572: >>>> > >>>> > Note that when the offer/answer model is being used, it is possible >>>> > for a media connection to outrace the answer back to the offerer. >>>> > Thus, if the offerer has offered a 'setup:passive' or >>>> 'setup:actpass' >>>> > role, it MUST (as specified in RFC 4145 [7]) begin listening for an >>>> > incoming connection as soon as it sends its offer. However, it >>>> MUST >>>> > NOT assume that the data transmitted over the TLS connection is >>>> valid >>>> > until it has received a matching fingerprint in an SDP answer. If >>>> > the fingerprint, once it arrives, does not match the client's >>>> > certificate, the server endpoint MUST terminate the media >>>> connection >>>> > with a bad_certificate error, as stated in the previous paragraph. >>>> > >>>> > Given the outstanding issue relating to handling of unverified media, >>>> the >>>> > Chairs of the W3C WEBRTC WG would like to request clarification from >>>> the >>>> > IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above >>>> paragraph. >>>> > In particular, what is it permitted for an implementation to do with >>>> > received data and media prior to verification? For example: >>>> > >>>> > 1. May data received over the data channel be provided to the >>>> > application prior to verification? >>>> > a. If the answer to the above is "no", may unverified >>>> received data >>>> > be delivered by the DTLS transport to SCTP, which may buffer it? >>>> > 2. May received media be played out prior to verification? >>>> > >>>> > Bernard Aboba >>>> > On behalf of the W3C WEBRTC WG >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --001a11493644ce54aa054a69f5b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, no, I was just talking about what might or might no= t be safe.... The doc text is
a different question.

-Ekr


On Fri, Mar 10, 2017 at 4:05 PM, Bernard Aboba &l= t;bernard.abob= a@gmail.com> wrote:
EKR said:=C2=A0

"I haven't spent too much time on it, but it s= eems like it ought to be safe to hold
anything you receive prior to getting the fing= erprint. It might be better, as MT
suggests, to discard the datachannel data, but I'm n= ot sure why it would be
necessar= y."

[BA] So you are saying that= the MUST NOT allows the browser to buffer data/media but not to pass it to= the application (in the case of the data channel) or to play it out?
=
On Fri, Mar 10, 2017 at 4:01 PM, Eric Rescorla= <ek= r@rtfm.com> wrote:
I haven't spent too much time on it= , but it seems like it ought to be safe to hold
anything you receive prior to getting the fingerprint. It might be bet= ter, as MT
suggests, to discard the datacha= nnel data, but I'm not sure why it would be
necessary.

-Ekr

On Fri, Mar 10, 2017 at 2:4= 7 PM, Roman Shpount <roman@telurix.com> wrote:
My assumption always was that data is= received, decoded and discarded until fingerprint is received and verified= . This way DTLS handshake completes, key frames are decoded, but user is no= r presented with any unverified media.

Regards,

_____________
Roman Sh= pount

On Thu, Mar 9, 2017 at 6:58 PM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
I think that the data channel question is easy, anything = other than a
"no" is not acceptable.=C2=A0 Data in that form enters the securi= ty
boundary for an origin and it doesn't make any sense to risk attack
there.=C2=A0 (It's also likely unnecessary, if a half a round trip of signaling is slower than 5 round trips on the media path, then
something is messed up.)

I'm in two minds about the media part. For media, you could also
reasonably make the same origin-purity argument.=C2=A0 I'm inclined to = say
that.=C2=A0 But we CAN isolate media from the origin (and we definitely
should if we allow this).

So, the media that arrives had to comply with your offer.=C2=A0 The DTLS handshake also has to complete, which tells the receiver whether the
media needs to be confidential or not (at which point you can disable
this feature).

It's also possible that a receiver can require that an ICE
connectivity check was made (though this is inbound only, and I'm
unclear on whether having received an inbound check would normally
prevent the receiver from accepting a packet).

All told, that's a lot of information about the negotiated session for<= br> an attacker to have.=C2=A0 The odds of this being an attack would *seem* to=
be low.

On the other hand, we don't assume confidentiality of signaling; the security model assumes that all this information is effectively public
and the protection we have against attack is the certificate
fingerprint.=C2=A0 This would remove that protection, albeit for a short duration.

I have an extra question: does anyone plan to implement this?=C2=A0 It'= s
non-trivial.=C2=A0 I think that I know what I'd need to do in Firefox a= nd
it would be quite disruptive.=C2=A0 Before committing to do that work
(which I will leave to others closer to this to decide), I'd probably want more information on the actual advantage that it provides.

On 10 March 2017 at 07:10, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> In the W3C WEBRTC WG, an issue has been submitted relating to playout = of
> unverified media:
> https://github.com/w3c/webrtc-pc/issues/849=
>
> It has been suggested that if the browser is configured to do so, that=
> playout be allowed for a limited period (e.g. 5 seconds) prior to
> fingerprint verification:
> https://github.com/w3c/webrtc-pc/pull/1026 >
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the foll= owing text,
> carried over from RFC 4572:
>
>=C2=A0 =C2=A0 Note that when the offer/answer model is being used, it i= s possible
>=C2=A0 =C2=A0 for a media connection to outrace the answer back to the = offerer.
>=C2=A0 =C2=A0 Thus, if the offerer has offered a 'setup:passive'= ; or 'setup:actpass'
>=C2=A0 =C2=A0 role, it MUST (as specified in RFC 4145 [7]) begin listen= ing for an
>=C2=A0 =C2=A0 incoming connection as soon as it sends its offer.=C2=A0 = However, it MUST
>=C2=A0 =C2=A0 NOT assume that the data transmitted over the TLS connect= ion is valid
>=C2=A0 =C2=A0 until it has received a matching fingerprint in an SDP an= swer.=C2=A0 If
>=C2=A0 =C2=A0 the fingerprint, once it arrives, does not match the clie= nt's
>=C2=A0 =C2=A0 certificate, the server endpoint MUST terminate the media= connection
>=C2=A0 =C2=A0 with a bad_certificate error, as stated in the previous p= aragraph.
>
> Given the outstanding issue relating to handling of unverified media, = the
> Chairs of the W3C WEBRTC WG would like to request clarification from t= he
> IETF MMUSIC WG as to the meaning of the "MUST NOT" in the ab= ove paragraph.
> In particular, what is it permitted for an implementation to do with > received data and media prior to verification? For example:
>
>=C2=A0 =C2=A0 =C2=A0 1. May data received over the data channel be prov= ided to the
> application prior to verification?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a. If the answer to the above is &qu= ot;no", may unverified received data
> be delivered by the DTLS transport to SCTP, which may buffer it?
>=C2=A0 =C2=A0 =C2=A0 2. May received media be played out prior to verif= ication?
>
> Bernard Aboba
> On behalf of the W3C WEBRTC WG
>
> _______________________________________________
> 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


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


--001a11493644ce54aa054a69f5b6-- From nobody Sat Mar 11 07:00: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 594F3129504 for ; Sat, 11 Mar 2017 07:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[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=unavailable 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 aw97j-Ci9JQB for ; Sat, 11 Mar 2017 07:00:50 -0800 (PST) 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 470CE129491 for ; Sat, 11 Mar 2017 06:52:25 -0800 (PST) X-AuditID: c1b4fb25-a57ff70000004cad-fb-58c40f23845b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 21.F2.19629.32F04C85; Sat, 11 Mar 2017 15:52:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Sat, 11 Mar 2017 15:52:19 +0100 From: Christer Holmberg To: Eric Rescorla , Bernard Aboba Thread-Topic: [MMUSIC] Handling of unverified data and media Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGOsIkAgAABT4CAAA4wAIAA+Mdg Date: Sat, 11 Mar 2017 14:52:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB06D6CESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7q646/5EIg+fL2Cw27PvPbLHi9Tl2 i/cXdC1O3DjNbDF1+WMWB1aPKb83snrsnHWX3WPBplKPJUt+MnlMftzGHMAaxWWTkpqTWZZa pG+XwJWxZnIje0HTZ8aKOe9OsjcwXnjD2MXIySEhYCLx98Z/IJuLQ0hgHaPE3SnXmCCcxYwS q360sXUxcnCwCVhIdP/TBmkQEfCUmPJ3NxNImFkgV2J9YwiIKSxgLXGlnxXEFBGwkVj5qxai 2E1i8ZW9YJtYBFQl3ix8zAxi8wr4Suy6ewhq62Zmib13fjCBJDgFAiXW3pjODmIzCohJfD+1 BizOLCAucevJfCaIkwUkluw5zwxhi0q8fPyPFcJWklh7eDsLRH2+xIn9v9ghlglKnJz5hGUC o8gsJKNmISmbhaRsFthjmhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxUm66kbFe alFmcnFxfp5eXmrJJkZgNB7c8lt1B+PlN46HGAU4GJV4eAv2H4oQYk0sK67MPcQowcGsJMLr MR8oxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA+PEGjVu dYGI1xxL5+k1Fx4tOZbp1bV9ulyvZ7Qjx51rF2R4wi8azZtkYrFNfor+7MmCOf4ikuuqjoYU Xs83m9Zos71JozR/ofaEIPtzb+b21Z2becxGtfJTeZJ0s+EPSx+RuVzf++9rhFZ/z94ersIk sNY2ubNToilfxc6yyD/N2Nt+/0lHJZbijERDLeai4kQAB6djqsICAAA= Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 15:00:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB06D6CESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklzIHRoaXMgYSB0aGVvcmV0aWNhbCBpc3N1ZT8NCg0KQXQgbGVhc3QgaWYgeW91IHVz ZSBJQ0UsIHlvdSBhcmUgZ29pbmcgdG8gcmVjZWl2ZSB0aGUgYW5zd2VyIGJlZm9yZSB5b3UgcmVj ZWl2ZSBhbnkgbWVkaWEsIGFzIHlvdSBhcmUgZ29pbmcgdG8gZG8gdGhlIGNvbm5lY3Rpdml0eSBj aGVja3MgZXRjLg0KDQpBbHNvLCBpbiByZWFsaXR5IHNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwg bm90IGFjY2VwdCBjb250ZW50IGJlZm9yZSB0aGUgYW5zd2VyIGFycml2ZXMg4oCTIG5vIG1hdHRl ciBpZiBEVExTIGlzIHVzZWQgb3Igbm90IOKAkyBzbyB0aGUgYmVzdCB0aGluZyBpcyB0bywgb25j ZSB0aGUgYW5zd2VyIGhhcyBiZWVuIHNlbnQsIGp1c3Qgd2FpdCBmb3IgYSB3aGlsZSBiZWZvcmUg c2VuZGluZyBhbnkgY29udGVudC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogbW11 c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJl c2NvcmxhDQpTZW50OiAxMSBNYXJjaCAyMDE3IDAyOjU3DQpUbzogQmVybmFyZCBBYm9iYSA8YmVy bmFyZC5hYm9iYUBnbWFpbC5jb20+DQpDYzogRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0Bj aXNjby5jb20+OyBodGFAZ29vZ2xlLmNvbTsgbW11c2ljIFdHIDxtbXVzaWNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW01NVVNJQ10gSGFuZGxpbmcgb2YgdW52ZXJpZmllZCBkYXRhIGFuZCBtZWRp YQ0KDQpTb3JyeSwgbm8sIEkgd2FzIGp1c3QgdGFsa2luZyBhYm91dCB3aGF0IG1pZ2h0IG9yIG1p Z2h0IG5vdCBiZSBzYWZlLi4uLiBUaGUgZG9jIHRleHQgaXMNCmEgZGlmZmVyZW50IHF1ZXN0aW9u Lg0KDQotRWtyDQoNCg0KT24gRnJpLCBNYXIgMTAsIDIwMTcgYXQgNDowNSBQTSwgQmVybmFyZCBB Ym9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwu Y29tPj4gd3JvdGU6DQpFS1Igc2FpZDoNCg0KIkkgaGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0aW1l IG9uIGl0LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBvdWdodCB0byBiZSBzYWZlIHRvIGhvbGQNCmFu eXRoaW5nIHlvdSByZWNlaXZlIHByaW9yIHRvIGdldHRpbmcgdGhlIGZpbmdlcnByaW50LiBJdCBt aWdodCBiZSBiZXR0ZXIsIGFzIE1UDQpzdWdnZXN0cywgdG8gZGlzY2FyZCB0aGUgZGF0YWNoYW5u ZWwgZGF0YSwgYnV0IEknbSBub3Qgc3VyZSB3aHkgaXQgd291bGQgYmUNCm5lY2Vzc2FyeS4iDQoN CltCQV0gU28geW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgTVVTVCBOT1QgYWxsb3dzIHRoZSBicm93 c2VyIHRvIGJ1ZmZlciBkYXRhL21lZGlhIGJ1dCBub3QgdG8gcGFzcyBpdCB0byB0aGUgYXBwbGlj YXRpb24gKGluIHRoZSBjYXNlIG9mIHRoZSBkYXRhIGNoYW5uZWwpIG9yIHRvIHBsYXkgaXQgb3V0 Pw0KDQpPbiBGcmksIE1hciAxMCwgMjAxNyBhdCA0OjAxIFBNLCBFcmljIFJlc2NvcmxhIDxla3JA cnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KSSBoYXZlbid0IHNwZW50IHRv byBtdWNoIHRpbWUgb24gaXQsIGJ1dCBpdCBzZWVtcyBsaWtlIGl0IG91Z2h0IHRvIGJlIHNhZmUg dG8gaG9sZA0KYW55dGhpbmcgeW91IHJlY2VpdmUgcHJpb3IgdG8gZ2V0dGluZyB0aGUgZmluZ2Vy cHJpbnQuIEl0IG1pZ2h0IGJlIGJldHRlciwgYXMgTVQNCnN1Z2dlc3RzLCB0byBkaXNjYXJkIHRo ZSBkYXRhY2hhbm5lbCBkYXRhLCBidXQgSSdtIG5vdCBzdXJlIHdoeSBpdCB3b3VsZCBiZQ0KbmVj ZXNzYXJ5Lg0KDQotRWtyDQoNCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0IDI6NDcgUE0sIFJvbWFu IFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdy b3RlOg0KTXkgYXNzdW1wdGlvbiBhbHdheXMgd2FzIHRoYXQgZGF0YSBpcyByZWNlaXZlZCwgZGVj b2RlZCBhbmQgZGlzY2FyZGVkIHVudGlsIGZpbmdlcnByaW50IGlzIHJlY2VpdmVkIGFuZCB2ZXJp ZmllZC4gVGhpcyB3YXkgRFRMUyBoYW5kc2hha2UgY29tcGxldGVzLCBrZXkgZnJhbWVzIGFyZSBk ZWNvZGVkLCBidXQgdXNlciBpcyBub3IgcHJlc2VudGVkIHdpdGggYW55IHVudmVyaWZpZWQgbWVk aWEuDQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVGh1 LCBNYXIgOSwgMjAxNyBhdCA2OjU4IFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25A Z21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCkkgdGhp bmsgdGhhdCB0aGUgZGF0YSBjaGFubmVsIHF1ZXN0aW9uIGlzIGVhc3ksIGFueXRoaW5nIG90aGVy IHRoYW4gYQ0KIm5vIiBpcyBub3QgYWNjZXB0YWJsZS4gIERhdGEgaW4gdGhhdCBmb3JtIGVudGVy cyB0aGUgc2VjdXJpdHkNCmJvdW5kYXJ5IGZvciBhbiBvcmlnaW4gYW5kIGl0IGRvZXNuJ3QgbWFr ZSBhbnkgc2Vuc2UgdG8gcmlzayBhdHRhY2sNCnRoZXJlLiAgKEl0J3MgYWxzbyBsaWtlbHkgdW5u ZWNlc3NhcnksIGlmIGEgaGFsZiBhIHJvdW5kIHRyaXAgb2YNCnNpZ25hbGluZyBpcyBzbG93ZXIg dGhhbiA1IHJvdW5kIHRyaXBzIG9uIHRoZSBtZWRpYSBwYXRoLCB0aGVuDQpzb21ldGhpbmcgaXMg bWVzc2VkIHVwLikNCg0KSSdtIGluIHR3byBtaW5kcyBhYm91dCB0aGUgbWVkaWEgcGFydC4gRm9y IG1lZGlhLCB5b3UgY291bGQgYWxzbw0KcmVhc29uYWJseSBtYWtlIHRoZSBzYW1lIG9yaWdpbi1w dXJpdHkgYXJndW1lbnQuICBJJ20gaW5jbGluZWQgdG8gc2F5DQp0aGF0LiAgQnV0IHdlIENBTiBp c29sYXRlIG1lZGlhIGZyb20gdGhlIG9yaWdpbiAoYW5kIHdlIGRlZmluaXRlbHkNCnNob3VsZCBp ZiB3ZSBhbGxvdyB0aGlzKS4NCg0KU28sIHRoZSBtZWRpYSB0aGF0IGFycml2ZXMgaGFkIHRvIGNv bXBseSB3aXRoIHlvdXIgb2ZmZXIuICBUaGUgRFRMUw0KaGFuZHNoYWtlIGFsc28gaGFzIHRvIGNv bXBsZXRlLCB3aGljaCB0ZWxscyB0aGUgcmVjZWl2ZXIgd2hldGhlciB0aGUNCm1lZGlhIG5lZWRz IHRvIGJlIGNvbmZpZGVudGlhbCBvciBub3QgKGF0IHdoaWNoIHBvaW50IHlvdSBjYW4gZGlzYWJs ZQ0KdGhpcyBmZWF0dXJlKS4NCg0KSXQncyBhbHNvIHBvc3NpYmxlIHRoYXQgYSByZWNlaXZlciBj YW4gcmVxdWlyZSB0aGF0IGFuIElDRQ0KY29ubmVjdGl2aXR5IGNoZWNrIHdhcyBtYWRlICh0aG91 Z2ggdGhpcyBpcyBpbmJvdW5kIG9ubHksIGFuZCBJJ20NCnVuY2xlYXIgb24gd2hldGhlciBoYXZp bmcgcmVjZWl2ZWQgYW4gaW5ib3VuZCBjaGVjayB3b3VsZCBub3JtYWxseQ0KcHJldmVudCB0aGUg cmVjZWl2ZXIgZnJvbSBhY2NlcHRpbmcgYSBwYWNrZXQpLg0KDQpBbGwgdG9sZCwgdGhhdCdzIGEg bG90IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZWdvdGlhdGVkIHNlc3Npb24gZm9yDQphbiBh dHRhY2tlciB0byBoYXZlLiAgVGhlIG9kZHMgb2YgdGhpcyBiZWluZyBhbiBhdHRhY2sgd291bGQg KnNlZW0qIHRvDQpiZSBsb3cuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCB3ZSBkb24ndCBhc3N1bWUg Y29uZmlkZW50aWFsaXR5IG9mIHNpZ25hbGluZzsgdGhlDQpzZWN1cml0eSBtb2RlbCBhc3N1bWVz IHRoYXQgYWxsIHRoaXMgaW5mb3JtYXRpb24gaXMgZWZmZWN0aXZlbHkgcHVibGljDQphbmQgdGhl IHByb3RlY3Rpb24gd2UgaGF2ZSBhZ2FpbnN0IGF0dGFjayBpcyB0aGUgY2VydGlmaWNhdGUNCmZp bmdlcnByaW50LiAgVGhpcyB3b3VsZCByZW1vdmUgdGhhdCBwcm90ZWN0aW9uLCBhbGJlaXQgZm9y IGEgc2hvcnQNCmR1cmF0aW9uLg0KDQpJIGhhdmUgYW4gZXh0cmEgcXVlc3Rpb246IGRvZXMgYW55 b25lIHBsYW4gdG8gaW1wbGVtZW50IHRoaXM/ICBJdCdzDQpub24tdHJpdmlhbC4gIEkgdGhpbmsg dGhhdCBJIGtub3cgd2hhdCBJJ2QgbmVlZCB0byBkbyBpbiBGaXJlZm94IGFuZA0KaXQgd291bGQg YmUgcXVpdGUgZGlzcnVwdGl2ZS4gIEJlZm9yZSBjb21taXR0aW5nIHRvIGRvIHRoYXQgd29yaw0K KHdoaWNoIEkgd2lsbCBsZWF2ZSB0byBvdGhlcnMgY2xvc2VyIHRvIHRoaXMgdG8gZGVjaWRlKSwg SSdkIHByb2JhYmx5DQp3YW50IG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIGFjdHVhbCBhZHZhbnRh Z2UgdGhhdCBpdCBwcm92aWRlcy4NCg0KT24gMTAgTWFyY2ggMjAxNyBhdCAwNzoxMCwgQmVybmFy ZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21h aWwuY29tPj4gd3JvdGU6DQo+IEluIHRoZSBXM0MgV0VCUlRDIFdHLCBhbiBpc3N1ZSBoYXMgYmVl biBzdWJtaXR0ZWQgcmVsYXRpbmcgdG8gcGxheW91dCBvZg0KPiB1bnZlcmlmaWVkIG1lZGlhOg0K PiBodHRwczovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9pc3N1ZXMvODQ5DQo+DQo+IEl0IGhh cyBiZWVuIHN1Z2dlc3RlZCB0aGF0IGlmIHRoZSBicm93c2VyIGlzIGNvbmZpZ3VyZWQgdG8gZG8g c28sIHRoYXQNCj4gcGxheW91dCBiZSBhbGxvd2VkIGZvciBhIGxpbWl0ZWQgcGVyaW9kIChlLmcu IDUgc2Vjb25kcykgcHJpb3IgdG8NCj4gZmluZ2VycHJpbnQgdmVyaWZpY2F0aW9uOg0KPiBodHRw czovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9wdWxsLzEwMjYNCj4NCj4gU2VjdGlvbiA2LjIg b2YgZHJhZnQtaWV0Zi1tbXVzaWMtNDU3Mi11cGRhdGUtMTMgY29udGFpbnMgdGhlIGZvbGxvd2lu ZyB0ZXh0LA0KPiBjYXJyaWVkIG92ZXIgZnJvbSBSRkMgNDU3MjoNCj4NCj4gICAgTm90ZSB0aGF0 IHdoZW4gdGhlIG9mZmVyL2Fuc3dlciBtb2RlbCBpcyBiZWluZyB1c2VkLCBpdCBpcyBwb3NzaWJs ZQ0KPiAgICBmb3IgYSBtZWRpYSBjb25uZWN0aW9uIHRvIG91dHJhY2UgdGhlIGFuc3dlciBiYWNr IHRvIHRoZSBvZmZlcmVyLg0KPiAgICBUaHVzLCBpZiB0aGUgb2ZmZXJlciBoYXMgb2ZmZXJlZCBh ICdzZXR1cDpwYXNzaXZlJyBvciAnc2V0dXA6YWN0cGFzcycNCj4gICAgcm9sZSwgaXQgTVVTVCAo YXMgc3BlY2lmaWVkIGluIFJGQyA0MTQ1IFs3XSkgYmVnaW4gbGlzdGVuaW5nIGZvciBhbg0KPiAg ICBpbmNvbWluZyBjb25uZWN0aW9uIGFzIHNvb24gYXMgaXQgc2VuZHMgaXRzIG9mZmVyLiAgSG93 ZXZlciwgaXQgTVVTVA0KPiAgICBOT1QgYXNzdW1lIHRoYXQgdGhlIGRhdGEgdHJhbnNtaXR0ZWQg b3ZlciB0aGUgVExTIGNvbm5lY3Rpb24gaXMgdmFsaWQNCj4gICAgdW50aWwgaXQgaGFzIHJlY2Vp dmVkIGEgbWF0Y2hpbmcgZmluZ2VycHJpbnQgaW4gYW4gU0RQIGFuc3dlci4gIElmDQo+ICAgIHRo ZSBmaW5nZXJwcmludCwgb25jZSBpdCBhcnJpdmVzLCBkb2VzIG5vdCBtYXRjaCB0aGUgY2xpZW50 J3MNCj4gICAgY2VydGlmaWNhdGUsIHRoZSBzZXJ2ZXIgZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUg dGhlIG1lZGlhIGNvbm5lY3Rpb24NCj4gICAgd2l0aCBhIGJhZF9jZXJ0aWZpY2F0ZSBlcnJvciwg YXMgc3RhdGVkIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguDQo+DQo+IEdpdmVuIHRoZSBvdXRz dGFuZGluZyBpc3N1ZSByZWxhdGluZyB0byBoYW5kbGluZyBvZiB1bnZlcmlmaWVkIG1lZGlhLCB0 aGUNCj4gQ2hhaXJzIG9mIHRoZSBXM0MgV0VCUlRDIFdHIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBj bGFyaWZpY2F0aW9uIGZyb20gdGhlDQo+IElFVEYgTU1VU0lDIFdHIGFzIHRvIHRoZSBtZWFuaW5n IG9mIHRoZSAiTVVTVCBOT1QiIGluIHRoZSBhYm92ZSBwYXJhZ3JhcGguDQo+IEluIHBhcnRpY3Vs YXIsIHdoYXQgaXMgaXQgcGVybWl0dGVkIGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0byBkbyB3aXRo DQo+IHJlY2VpdmVkIGRhdGEgYW5kIG1lZGlhIHByaW9yIHRvIHZlcmlmaWNhdGlvbj8gRm9yIGV4 YW1wbGU6DQo+DQo+ICAgICAgMS4gTWF5IGRhdGEgcmVjZWl2ZWQgb3ZlciB0aGUgZGF0YSBjaGFu bmVsIGJlIHByb3ZpZGVkIHRvIHRoZQ0KPiBhcHBsaWNhdGlvbiBwcmlvciB0byB2ZXJpZmljYXRp b24/DQo+ICAgICAgICAgIGEuIElmIHRoZSBhbnN3ZXIgdG8gdGhlIGFib3ZlIGlzICJubyIsIG1h eSB1bnZlcmlmaWVkIHJlY2VpdmVkIGRhdGENCj4gYmUgZGVsaXZlcmVkIGJ5IHRoZSBEVExTIHRy YW5zcG9ydCB0byBTQ1RQLCB3aGljaCBtYXkgYnVmZmVyIGl0Pw0KPiAgICAgIDIuIE1heSByZWNl aXZlZCBtZWRpYSBiZSBwbGF5ZWQgb3V0IHByaW9yIHRvIHZlcmlmaWNhdGlvbj8NCj4NCj4gQmVy bmFyZCBBYm9iYQ0KPiBPbiBiZWhhbGYgb2YgdGhlIFczQyBXRUJSVEMgV0cNCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW11c2ljIG1haWxp bmcgbGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxp c3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2lj QGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB06D6CESESSMB109erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm0tNTQzNDMxOTEwODU1 NjYwOTQxOW0tNjg1NjU2MzI3MzY2NDAzNTQzNWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy01 NDM0MzE5MTA4NTU2NjA5NDE5bV8tNjg1NjU2MzI3MzY2NDAzNTQzNWhvZW56Yjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JcyB0aGlzIGEgdGhlb3JldGljYWwgaXNzdWU/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BdCBsZWFzdCBpZiB5b3Ug dXNlIElDRSwgeW91IGFyZSBnb2luZyB0byByZWNlaXZlIHRoZSBhbnN3ZXIgYmVmb3JlIHlvdSBy ZWNlaXZlIGFueSBtZWRpYSwgYXMgeW91IGFyZSBnb2luZyB0byBkbyB0aGUgY29ubmVjdGl2aXR5 DQogY2hlY2tzIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFs c28sIGluIHJlYWxpdHkgc29tZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3QgYWNjZXB0IGNvbnRl bnQgYmVmb3JlIHRoZSBhbnN3ZXIgYXJyaXZlcyDigJMgbm8gbWF0dGVyIGlmIERUTFMgaXMgdXNl ZCBvciBub3Qg4oCTIHNvIHRoZQ0KIGJlc3QgdGhpbmcgaXMgdG8sIG9uY2UgdGhlIGFuc3dlciBo YXMgYmVlbiBzZW50LCBqdXN0IHdhaXQgZm9yIGEgd2hpbGUgYmVmb3JlIHNlbmRpbmcgYW55IGNv bnRlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6 PC9iPiAxMSBNYXJjaCAyMDE3IDAyOjU3PGJyPg0KPGI+VG86PC9iPiBCZXJuYXJkIEFib2JhICZs dDtiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEZsZW1taW5nIEFu ZHJlYXNlbiAmbHQ7ZmFuZHJlYXNAY2lzY28uY29tJmd0OzsgaHRhQGdvb2dsZS5jb207IG1tdXNp YyBXRyAmbHQ7bW11c2ljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01N VVNJQ10gSGFuZGxpbmcgb2YgdW52ZXJpZmllZCBkYXRhIGFuZCBtZWRpYTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvcnJ5LCBubywgSSB3YXMganVzdCB0YWxraW5nIGFi b3V0IHdoYXQgbWlnaHQgb3IgbWlnaHQgbm90IGJlIHNhZmUuLi4uIFRoZSBkb2MgdGV4dCBpczxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgZGlmZmVyZW50IHF1 ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IE1hciAxMCwgMjAxNyBhdCA0OjA1IFBNLCBCZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWls dG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZXJuYXJkLmFib2Jh QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FS1Igc2FpZDombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OzxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQiPkkgaGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0aW1lIG9uIGl0LCBidXQgaXQgc2Vl bXMgbGlrZSBpdCBvdWdodCB0byBiZSBzYWZlIHRvIGhvbGQ8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0Ij5hbnl0aGluZyB5b3UgcmVjZWl2ZSBwcmlvciB0byBnZXR0aW5nIHRoZSBmaW5n ZXJwcmludC4gSXQgbWlnaHQgYmUgYmV0dGVyLCBhcyBNVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQiPnN1Z2dlc3RzLCB0byBkaXNjYXJkIHRoZSBkYXRhY2hhbm5lbCBkYXRhLCBidXQg SSdtIG5vdCBzdXJlIHdoeSBpdCB3b3VsZCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQiPm5lY2Vzc2FyeS48L3NwYW4+JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCQV0gU28geW91IGFyZSBzYXlpbmcgdGhhdCB0aGUg TVVTVCBOT1QgYWxsb3dzIHRoZSBicm93c2VyIHRvIGJ1ZmZlciBkYXRhL21lZGlhIGJ1dCBub3Qg dG8gcGFzcyBpdCB0byB0aGUgYXBwbGljYXRpb24gKGluIHRoZSBjYXNlIG9mIHRoZSBkYXRhIGNo YW5uZWwpIG9yIHRvIHBsYXkgaXQgb3V0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDEwLCAyMDE3 IGF0IDQ6MDEgUE0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5j b20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0aW1lIG9uIGl0LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBv dWdodCB0byBiZSBzYWZlIHRvIGhvbGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmFueXRoaW5nIHlvdSByZWNlaXZlIHByaW9yIHRvIGdldHRpbmcg dGhlIGZpbmdlcnByaW50LiBJdCBtaWdodCBiZSBiZXR0ZXIsIGFzIE1UPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zdWdnZXN0cywgdG8gZGlzY2Fy ZCB0aGUgZGF0YWNoYW5uZWwgZGF0YSwgYnV0IEknbSBub3Qgc3VyZSB3aHkgaXQgd291bGQgYmU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5lY2Vz c2FyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGcmksIE1hciAxMCwgMjAxNyBhdCAyOjQ3IFBNLCBSb21hbiBTaHBvdW50 ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5y b21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBhc3N1bXB0aW9uIGFsd2F5cyB3YXMg dGhhdCBkYXRhIGlzIHJlY2VpdmVkLCBkZWNvZGVkIGFuZCBkaXNjYXJkZWQgdW50aWwgZmluZ2Vy cHJpbnQgaXMgcmVjZWl2ZWQgYW5kIHZlcmlmaWVkLiBUaGlzIHdheSBEVExTIGhhbmRzaGFrZSBj b21wbGV0ZXMsIGtleSBmcmFtZXMgYXJlIGRlY29kZWQsIGJ1dCB1c2VyIGlzIG5vciBwcmVzZW50 ZWQgd2l0aCBhbnkgdW52ZXJpZmllZCBtZWRpYS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19f PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJtLTU0MzQzMTkx MDg1NTY2MDk0MTltLTY4NTY1NjMyNzM2NjQwMzU0MzVob2VuemIiPlJvbWFuIFNocG91bnQ8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgOSwgMjAxNyBhdCA2OjU4IFBNLCBNYXJ0aW4gVGhv bXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhhdCB0 aGUgZGF0YSBjaGFubmVsIHF1ZXN0aW9uIGlzIGVhc3ksIGFueXRoaW5nIG90aGVyIHRoYW4gYTxi cj4NCiZxdW90O25vJnF1b3Q7IGlzIG5vdCBhY2NlcHRhYmxlLiZuYnNwOyBEYXRhIGluIHRoYXQg Zm9ybSBlbnRlcnMgdGhlIHNlY3VyaXR5PGJyPg0KYm91bmRhcnkgZm9yIGFuIG9yaWdpbiBhbmQg aXQgZG9lc24ndCBtYWtlIGFueSBzZW5zZSB0byByaXNrIGF0dGFjazxicj4NCnRoZXJlLiZuYnNw OyAoSXQncyBhbHNvIGxpa2VseSB1bm5lY2Vzc2FyeSwgaWYgYSBoYWxmIGEgcm91bmQgdHJpcCBv Zjxicj4NCnNpZ25hbGluZyBpcyBzbG93ZXIgdGhhbiA1IHJvdW5kIHRyaXBzIG9uIHRoZSBtZWRp YSBwYXRoLCB0aGVuPGJyPg0Kc29tZXRoaW5nIGlzIG1lc3NlZCB1cC4pPGJyPg0KPGJyPg0KSSdt IGluIHR3byBtaW5kcyBhYm91dCB0aGUgbWVkaWEgcGFydC4gRm9yIG1lZGlhLCB5b3UgY291bGQg YWxzbzxicj4NCnJlYXNvbmFibHkgbWFrZSB0aGUgc2FtZSBvcmlnaW4tcHVyaXR5IGFyZ3VtZW50 LiZuYnNwOyBJJ20gaW5jbGluZWQgdG8gc2F5PGJyPg0KdGhhdC4mbmJzcDsgQnV0IHdlIENBTiBp c29sYXRlIG1lZGlhIGZyb20gdGhlIG9yaWdpbiAoYW5kIHdlIGRlZmluaXRlbHk8YnI+DQpzaG91 bGQgaWYgd2UgYWxsb3cgdGhpcykuPGJyPg0KPGJyPg0KU28sIHRoZSBtZWRpYSB0aGF0IGFycml2 ZXMgaGFkIHRvIGNvbXBseSB3aXRoIHlvdXIgb2ZmZXIuJm5ic3A7IFRoZSBEVExTPGJyPg0KaGFu ZHNoYWtlIGFsc28gaGFzIHRvIGNvbXBsZXRlLCB3aGljaCB0ZWxscyB0aGUgcmVjZWl2ZXIgd2hl dGhlciB0aGU8YnI+DQptZWRpYSBuZWVkcyB0byBiZSBjb25maWRlbnRpYWwgb3Igbm90IChhdCB3 aGljaCBwb2ludCB5b3UgY2FuIGRpc2FibGU8YnI+DQp0aGlzIGZlYXR1cmUpLjxicj4NCjxicj4N Ckl0J3MgYWxzbyBwb3NzaWJsZSB0aGF0IGEgcmVjZWl2ZXIgY2FuIHJlcXVpcmUgdGhhdCBhbiBJ Q0U8YnI+DQpjb25uZWN0aXZpdHkgY2hlY2sgd2FzIG1hZGUgKHRob3VnaCB0aGlzIGlzIGluYm91 bmQgb25seSwgYW5kIEknbTxicj4NCnVuY2xlYXIgb24gd2hldGhlciBoYXZpbmcgcmVjZWl2ZWQg YW4gaW5ib3VuZCBjaGVjayB3b3VsZCBub3JtYWxseTxicj4NCnByZXZlbnQgdGhlIHJlY2VpdmVy IGZyb20gYWNjZXB0aW5nIGEgcGFja2V0KS48YnI+DQo8YnI+DQpBbGwgdG9sZCwgdGhhdCdzIGEg bG90IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZWdvdGlhdGVkIHNlc3Npb24gZm9yPGJyPg0K YW4gYXR0YWNrZXIgdG8gaGF2ZS4mbmJzcDsgVGhlIG9kZHMgb2YgdGhpcyBiZWluZyBhbiBhdHRh Y2sgd291bGQgKnNlZW0qIHRvPGJyPg0KYmUgbG93Ljxicj4NCjxicj4NCk9uIHRoZSBvdGhlciBo YW5kLCB3ZSBkb24ndCBhc3N1bWUgY29uZmlkZW50aWFsaXR5IG9mIHNpZ25hbGluZzsgdGhlPGJy Pg0Kc2VjdXJpdHkgbW9kZWwgYXNzdW1lcyB0aGF0IGFsbCB0aGlzIGluZm9ybWF0aW9uIGlzIGVm ZmVjdGl2ZWx5IHB1YmxpYzxicj4NCmFuZCB0aGUgcHJvdGVjdGlvbiB3ZSBoYXZlIGFnYWluc3Qg YXR0YWNrIGlzIHRoZSBjZXJ0aWZpY2F0ZTxicj4NCmZpbmdlcnByaW50LiZuYnNwOyBUaGlzIHdv dWxkIHJlbW92ZSB0aGF0IHByb3RlY3Rpb24sIGFsYmVpdCBmb3IgYSBzaG9ydDxicj4NCmR1cmF0 aW9uLjxicj4NCjxicj4NCkkgaGF2ZSBhbiBleHRyYSBxdWVzdGlvbjogZG9lcyBhbnlvbmUgcGxh biB0byBpbXBsZW1lbnQgdGhpcz8mbmJzcDsgSXQnczxicj4NCm5vbi10cml2aWFsLiZuYnNwOyBJ IHRoaW5rIHRoYXQgSSBrbm93IHdoYXQgSSdkIG5lZWQgdG8gZG8gaW4gRmlyZWZveCBhbmQ8YnI+ DQppdCB3b3VsZCBiZSBxdWl0ZSBkaXNydXB0aXZlLiZuYnNwOyBCZWZvcmUgY29tbWl0dGluZyB0 byBkbyB0aGF0IHdvcms8YnI+DQood2hpY2ggSSB3aWxsIGxlYXZlIHRvIG90aGVycyBjbG9zZXIg dG8gdGhpcyB0byBkZWNpZGUpLCBJJ2QgcHJvYmFibHk8YnI+DQp3YW50IG1vcmUgaW5mb3JtYXRp b24gb24gdGhlIGFjdHVhbCBhZHZhbnRhZ2UgdGhhdCBpdCBwcm92aWRlcy48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gMTAgTWFyY2gg MjAxNyBhdCAwNzoxMCwgQmVybmFyZCBBYm9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQu YWJvYmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEluIHRoZSBXM0MgV0VCUlRDIFdHLCBhbiBpc3N1ZSBo YXMgYmVlbiBzdWJtaXR0ZWQgcmVsYXRpbmcgdG8gcGxheW91dCBvZjxicj4NCiZndDsgdW52ZXJp ZmllZCBtZWRpYTo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2Vi cnRjLXBjL2lzc3Vlcy84NDkiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vdzNj L3dlYnJ0Yy1wYy9pc3N1ZXMvODQ5PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IGhhcyBiZWVu IHN1Z2dlc3RlZCB0aGF0IGlmIHRoZSBicm93c2VyIGlzIGNvbmZpZ3VyZWQgdG8gZG8gc28sIHRo YXQ8YnI+DQomZ3Q7IHBsYXlvdXQgYmUgYWxsb3dlZCBmb3IgYSBsaW1pdGVkIHBlcmlvZCAoZS5n LiA1IHNlY29uZHMpIHByaW9yIHRvPGJyPg0KJmd0OyBmaW5nZXJwcmludCB2ZXJpZmljYXRpb246 PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9wdWxs LzEwMjYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9w dWxsLzEwMjY8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlvbiA2LjIgb2YgZHJhZnQtaWV0 Zi1tbXVzaWMtNDU3Mi11cGRhdGUtMTMgY29udGFpbnMgdGhlIGZvbGxvd2luZyB0ZXh0LDxicj4N CiZndDsgY2FycmllZCBvdmVyIGZyb20gUkZDIDQ1NzI6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7IE5vdGUgdGhhdCB3aGVuIHRoZSBvZmZlci9hbnN3ZXIgbW9kZWwgaXMgYmVpbmcg dXNlZCwgaXQgaXMgcG9zc2libGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBmb3IgYSBtZWRpYSBj b25uZWN0aW9uIHRvIG91dHJhY2UgdGhlIGFuc3dlciBiYWNrIHRvIHRoZSBvZmZlcmVyLjxicj4N CiZndDsmbmJzcDsgJm5ic3A7IFRodXMsIGlmIHRoZSBvZmZlcmVyIGhhcyBvZmZlcmVkIGEgJ3Nl dHVwOnBhc3NpdmUnIG9yICdzZXR1cDphY3RwYXNzJzxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHJv bGUsIGl0IE1VU1QgKGFzIHNwZWNpZmllZCBpbiBSRkMgNDE0NSBbN10pIGJlZ2luIGxpc3Rlbmlu ZyBmb3IgYW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBpbmNvbWluZyBjb25uZWN0aW9uIGFzIHNv b24gYXMgaXQgc2VuZHMgaXRzIG9mZmVyLiZuYnNwOyBIb3dldmVyLCBpdCBNVVNUPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgTk9UIGFzc3VtZSB0aGF0IHRoZSBkYXRhIHRyYW5zbWl0dGVkIG92ZXIg dGhlIFRMUyBjb25uZWN0aW9uIGlzIHZhbGlkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdW50aWwg aXQgaGFzIHJlY2VpdmVkIGEgbWF0Y2hpbmcgZmluZ2VycHJpbnQgaW4gYW4gU0RQIGFuc3dlci4m bmJzcDsgSWY8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgZmluZ2VycHJpbnQsIG9uY2UgaXQg YXJyaXZlcywgZG9lcyBub3QgbWF0Y2ggdGhlIGNsaWVudCdzPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgY2VydGlmaWNhdGUsIHRoZSBzZXJ2ZXIgZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUgdGhlIG1l ZGlhIGNvbm5lY3Rpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB3aXRoIGEgYmFkX2NlcnRpZmlj YXRlIGVycm9yLCBhcyBzdGF0ZWQgaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBHaXZlbiB0aGUgb3V0c3RhbmRpbmcgaXNzdWUgcmVsYXRpbmcgdG8gaGFuZGxp bmcgb2YgdW52ZXJpZmllZCBtZWRpYSwgdGhlPGJyPg0KJmd0OyBDaGFpcnMgb2YgdGhlIFczQyBX RUJSVEMgV0cgd291bGQgbGlrZSB0byByZXF1ZXN0IGNsYXJpZmljYXRpb24gZnJvbSB0aGU8YnI+ DQomZ3Q7IElFVEYgTU1VU0lDIFdHIGFzIHRvIHRoZSBtZWFuaW5nIG9mIHRoZSAmcXVvdDtNVVNU IE5PVCZxdW90OyBpbiB0aGUgYWJvdmUgcGFyYWdyYXBoLjxicj4NCiZndDsgSW4gcGFydGljdWxh ciwgd2hhdCBpcyBpdCBwZXJtaXR0ZWQgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRvIGRvIHdpdGg8 YnI+DQomZ3Q7IHJlY2VpdmVkIGRhdGEgYW5kIG1lZGlhIHByaW9yIHRvIHZlcmlmaWNhdGlvbj8g Rm9yIGV4YW1wbGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAxLiBN YXkgZGF0YSByZWNlaXZlZCBvdmVyIHRoZSBkYXRhIGNoYW5uZWwgYmUgcHJvdmlkZWQgdG8gdGhl PGJyPg0KJmd0OyBhcHBsaWNhdGlvbiBwcmlvciB0byB2ZXJpZmljYXRpb24/PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYS4gSWYgdGhlIGFuc3dlciB0byB0aGUg YWJvdmUgaXMgJnF1b3Q7bm8mcXVvdDssIG1heSB1bnZlcmlmaWVkIHJlY2VpdmVkIGRhdGE8YnI+ DQomZ3Q7IGJlIGRlbGl2ZXJlZCBieSB0aGUgRFRMUyB0cmFuc3BvcnQgdG8gU0NUUCwgd2hpY2gg bWF5IGJ1ZmZlciBpdD88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMi4gTWF5IHJlY2Vp dmVkIG1lZGlhIGJlIHBsYXllZCBvdXQgcHJpb3IgdG8gdmVyaWZpY2F0aW9uPzxicj4NCiZndDs8 YnI+DQomZ3Q7IEJlcm5hcmQgQWJvYmE8YnI+DQomZ3Q7IE9uIGJlaGFsZiBvZiB0aGUgVzNDIFdF QlJUQyBXRzxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJmd0OyBtbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3Jn PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21tdXNpYzwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1t dXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv Om1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11 c2ljPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB06D6CESESSMB109erics_-- From nobody Sat Mar 11 07:12:44 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 4DBB91294EF for ; Sat, 11 Mar 2017 07:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 CWjJlEbQbspR for ; Sat, 11 Mar 2017 07:12:41 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 B947E12940D for ; Sat, 11 Mar 2017 07:12:40 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id u48so80455926wrc.0 for ; Sat, 11 Mar 2017 07:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=blwjIL6vtGU6z2WAgUJHRdPqpPj8JezsO0tUyVvnvrk=; b=sgpsGeK69M5PBEq/mNgzdhizjZAlmtFzfivhAMr8FfYEnNqHqP8Rmo5oBMjY/79WQ7 7DuARsgMb1Tz8dax2XamZL3RPLSzYkzu0y0tH7PX9fedpI+p2K7pxfiy8gAVwL3U1Edo B9017UjQLXt7I+DdEPzwl5HJVSA4tK0SzU9fzgzmUlxhC0vy0laaktuTwDWw5hcdvb7p MmVkNMYmkILs1ASaT+4vXK7vul6SC+sALDhAV+XCCLrT578iyUXBtTtmoEy32vs6tG8d Y4if3z/Ej99NB742gsjIVj9IkSrvKY7SakJYlr9ZuhE/V/KxpQmR0FNz+sJqJOoVgJ/b jU2A== 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=blwjIL6vtGU6z2WAgUJHRdPqpPj8JezsO0tUyVvnvrk=; b=LKqiMT7OcQ88vGhrFm0+pFmXyZMxhiMkDMtbOLRA9oD1I+iLKpJZylcXFF0jZacIdQ 6Ju9XqRM5ylU9rP9mfTEyUc2HlIgskltp+Bez9V42UiTgzjevnkjyejEgTeVvlZVPdwi HAL9UslGVqrT4ilcNb9fsCnGeEqim7GH7qg0yHoU00jDS+Gm292rp4ueJ+JrLco6qULr 0sLXgZjze6Lwz0Tg+aelsXIVt8po3fSffN7z1e1bny/G1L1p0DeuLOoRBezvIQ4yITWT hlCTqRuFMplBhYMT69g5x1emUcnt64P94U/A3YoOj8PHgODvufMUU4M/sp7FOwDkCCuS ge+g== X-Gm-Message-State: AMke39lcXyb7HUw6SXnK4V653V1h3pp6olFDeNdNlkSoBEqNyc84+ySJqumaqvEPgwDViEd9sU5S47GozmaGbw== X-Received: by 10.223.172.135 with SMTP id o7mr19177169wrc.121.1489245159226; Sat, 11 Mar 2017 07:12:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Sat, 11 Mar 2017 07:12:18 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 11 Mar 2017 16:12:18 +0100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 15:12:42 -0000 2017-03-10 23:47 GMT+01:00 Roman Shpount : > My assumption always was that data is received, decoded and discarded unt= il > fingerprint is received and verified. This way DTLS handshake completes, = key > frames are decoded, but user is nor presented with any unverified media. Just imagine an app (running in a computer with public IP) which sends the SDP offer to a server, DTLS handshake is done, and the server sends DataChannel messages to the browser *before* the browser receives the SDP answer. Do you mean that such a DataChannel messages should be discarded? I consider that catastrophic as the server may not know whether the browser has yet received the answer or not. Apps should implement some kind of 3-way signaling handshake (send offer, receive answer, send ACK) before the server sends any DataChannel message. --=20 I=C3=B1aki Baz Castillo From nobody Sat Mar 11 07:24: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 07C6B129524 for ; Sat, 11 Mar 2017 07:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 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, 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 HCTlhLqkbMGr for ; Sat, 11 Mar 2017 07:24:27 -0800 (PST) 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 767FB129529 for ; Sat, 11 Mar 2017 07:24:27 -0800 (PST) X-AuditID: c1b4fb3a-9b1d39800000539f-78-58c416a9dee4 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id A6.98.21407.6A614C85; Sat, 11 Mar 2017 16:24:25 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Sat, 11 Mar 2017 16:24:21 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Roman Shpount Thread-Topic: [MMUSIC] Handling of unverified data and media Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGPrxoAgAATT2A= Date: Sat, 11 Mar 2017 15:24:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB06EB1@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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2J7oO5KsSMRBouP6lq8v6BrceLGaWaL 6ftsLKYuf8xiMePCVGYHVo9zDe/ZPab83sjqsWBTqceSJT+ZPG5NKQhgjeKySUnNySxLLdK3 S+DKmHjkJ2vBJIGK7nn6DYx3+LsYOTkkBEwkfly7z9bFyMUhJLCOUeLNzZvsEM5iRonm39tY uhg5ONgELCS6/2mDNIgIJEosmTmbHSTMLJArsb4xBMQUFrCWuNLPCmKKCNhIrPxVC1FsJbFt wUlGkDCLgKrEp38sIGFeAV+JHVc7mCH2LGWS2PZ/IztIglMgUKK1ezUjiM0oICbx/dQaJhCb WUBc4taT+UwQFwtILNlznhnCFpV4+fgfK4StJLH28HYWiMM0Jdbv0odoVZSY0v2QHWKvoMTJ mU9YJjCKzkIydRZCxywkHbOQdCxgZFnFKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERhPB7f8 ttrBePC54yFGAQ5GJR7egv2HIoRYE8uKK3MPMUpwMCuJ8E7lPBIhxJuSWFmVWpQfX1Sak1p8 iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA+MKTpmpz0zyI9Y9KE/w6bLN2c0S+8Rp OeOzc+wWQoxh2XF7N4vfX7+0xvGMt9bjwpX9Xh8vvPnzJWHWTZfjr8uq318sOGgaV5vjMp2R +94vf4MLp9Me1WvlFbaafHebuE+v5PfPle6cgp9r+DbsOHx7ctbs2MWHL+S1Z81gU9jONLlr woei0olKLMUZiYZazEXFiQDlgRy+owIAAA== Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 15:24:29 -0000 SGksDQoNCkluIGNhc2Ugb2YgYSBEYXRhIENoYW5uZWwsIHlvdSBhbHNvIG5lZWQgdG8gZXN0YWJs aXNoIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGJlZm9yZSB5b3UgY2FuIHNlbmQgYW55IGNvbnRlbnQu DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEnDsWFraSBCYXogQ2FzdGlsbG8NClNlbnQ6IDExIE1hcmNoIDIwMTcgMTc6MTINClRvOiBSb21h biBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZh bmRyZWFzQGNpc2NvLmNvbT47IGh0YUBnb29nbGUuY29tOyBtbXVzaWMgV0cgPG1tdXNpY0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBIYW5kbGluZyBvZiB1bnZlcmlmaWVkIGRhdGEg YW5kIG1lZGlhDQoNCjIwMTctMDMtMTAgMjM6NDcgR01UKzAxOjAwIFJvbWFuIFNocG91bnQgPHJv bWFuQHRlbHVyaXguY29tPjoNCj4gTXkgYXNzdW1wdGlvbiBhbHdheXMgd2FzIHRoYXQgZGF0YSBp cyByZWNlaXZlZCwgZGVjb2RlZCBhbmQgZGlzY2FyZGVkIA0KPiB1bnRpbCBmaW5nZXJwcmludCBp cyByZWNlaXZlZCBhbmQgdmVyaWZpZWQuIFRoaXMgd2F5IERUTFMgaGFuZHNoYWtlIA0KPiBjb21w bGV0ZXMsIGtleSBmcmFtZXMgYXJlIGRlY29kZWQsIGJ1dCB1c2VyIGlzIG5vciBwcmVzZW50ZWQg d2l0aCBhbnkgdW52ZXJpZmllZCBtZWRpYS4NCg0KSnVzdCBpbWFnaW5lIGFuIGFwcCAocnVubmlu ZyBpbiBhIGNvbXB1dGVyIHdpdGggcHVibGljIElQKSB3aGljaCBzZW5kcyB0aGUgU0RQIG9mZmVy IHRvIGEgc2VydmVyLCBEVExTIGhhbmRzaGFrZSBpcyBkb25lLCBhbmQgdGhlIHNlcnZlciBzZW5k cyBEYXRhQ2hhbm5lbCBtZXNzYWdlcyB0byB0aGUgYnJvd3NlciAqYmVmb3JlKiB0aGUgYnJvd3Nl ciByZWNlaXZlcyB0aGUgU0RQIGFuc3dlci4NCg0KRG8geW91IG1lYW4gdGhhdCBzdWNoIGEgRGF0 YUNoYW5uZWwgbWVzc2FnZXMgc2hvdWxkIGJlIGRpc2NhcmRlZD8gSSBjb25zaWRlciB0aGF0IGNh dGFzdHJvcGhpYyBhcyB0aGUgc2VydmVyIG1heSBub3Qga25vdyB3aGV0aGVyIHRoZSBicm93c2Vy IGhhcyB5ZXQgcmVjZWl2ZWQgdGhlIGFuc3dlciBvciBub3QuIEFwcHMgc2hvdWxkIGltcGxlbWVu dCBzb21lIGtpbmQgb2YgMy13YXkgc2lnbmFsaW5nIGhhbmRzaGFrZSAoc2VuZCBvZmZlciwgcmVj ZWl2ZSBhbnN3ZXIsIHNlbmQNCkFDSykgYmVmb3JlIHRoZSBzZXJ2ZXIgc2VuZHMgYW55IERhdGFD aGFubmVsIG1lc3NhZ2UuDQoNCg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgu bmV0Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K From nobody Sat Mar 11 07:25: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 AB4D1129518 for ; Sat, 11 Mar 2017 07:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[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=aliax-net.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 MtqosqNGtZJA for ; Sat, 11 Mar 2017 07:25:49 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 E785A129524 for ; Sat, 11 Mar 2017 07:25:48 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id t189so13585944wmt.1 for ; Sat, 11 Mar 2017 07:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vpiY7qPDyu7V6nQ+XzzS2arqa1OPsc6CggCRrCRC+TQ=; b=HdE6vCik1MPTMpSFAanznwfwSWsNndCWvSwc2wXGf2BlUUDCo6XZB42eAh/DruiP4A XwfE2Ecf3d1ZW4alwOO/uAt+PfYoBeiehkQo+CIOKCr0d26XksswiBTfLLuM6oEJWTqy J4V0BHWZ+pbeexmyMQBNLWPF+W0fVR9+EnjWWOSjvFVqzhFR8CSDUKlFa+bwu1lX81Hr a460KqMORvr1/wE90+2nVD5/r21l7C3G4gswKgXkYEq5rbM+q6xcXWLwrlxee6IZlkP+ 0vL6oNGcCPwxITbtMMPs3IgOO0Cz7Np92dTebCLDo6eMzlEUvRlLhyREkvUiXsMtO6g8 qS0Q== 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=vpiY7qPDyu7V6nQ+XzzS2arqa1OPsc6CggCRrCRC+TQ=; b=gac+TDsSPUoNnpzYwrVMjgvsQ8Zuwwz053ZLvadt9a4fWTZBjukjwSA2FW/Zuenq0Q 4qajbyKqnpa9dnDMgtHqlcQtaXGPe30OfQrkxfIq2CDnF/vuyhZsrxXJVu9sBpvnxiie CANF7SCsjJ/s8SIQjZF1gRGHewI05yElsLxkbg3GhyvFMVrTapHsyJlFgV98wWWJMIB/ +Qka6iABz+HgbA2/EZa3HAx/8A0ojdqzZX8BNKVJzdwdYuIsju4YgE+rNjtktPkoGEJK HkPyntuG5MDLaUPWo3WL6LJEVA5mQfYDi2EA909vs8nWDnSq4XNxIO3vaougracX+FNy xRgw== X-Gm-Message-State: AFeK/H23LEpCJcJiwbU9OAO6G4ZhvFttl/fMTrN/OjRqyfQ+OREBpBm5fl/UODpVKzNI8Kc7Xll7f+ofOJQp+g== X-Received: by 10.28.19.78 with SMTP id 75mr3813613wmt.108.1489245947392; Sat, 11 Mar 2017 07:25:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Sat, 11 Mar 2017 07:25:46 -0800 (PST) Received: by 10.80.138.222 with HTTP; Sat, 11 Mar 2017 07:25:46 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB06EB1@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB06EB1@ESESSMB109.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 11 Mar 2017 16:25:46 +0100 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1146ee9ead90cf054a7617b6 Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic@ietf.org Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 15:25:50 -0000 --001a1146ee9ead90cf054a7617b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable AFAIK you dont need a SDP aswer for that. El 11/3/2017 16:24, "Christer Holmberg" escribi=C3=B3: > Hi, > > In case of a Data Channel, you also need to establish the SCTP associatio= n > before you can send any content. > > Regards, > > Christer > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of I=C3=B1aki Baz > Castillo > Sent: 11 March 2017 17:12 > To: Roman Shpount > Cc: Flemming Andreasen ; hta@google.com; mmusic WG < > mmusic@ietf.org> > Subject: Re: [MMUSIC] Handling of unverified data and media > > 2017-03-10 23:47 GMT+01:00 Roman Shpount : > > My assumption always was that data is received, decoded and discarded > > until fingerprint is received and verified. This way DTLS handshake > > completes, key frames are decoded, but user is nor presented with any > unverified media. > > Just imagine an app (running in a computer with public IP) which sends th= e > SDP offer to a server, DTLS handshake is done, and the server sends > DataChannel messages to the browser *before* the browser receives the SDP > answer. > > Do you mean that such a DataChannel messages should be discarded? I > consider that catastrophic as the server may not know whether the browser > has yet received the answer or not. Apps should implement some kind of > 3-way signaling handshake (send offer, receive answer, send > ACK) before the server sends any DataChannel message. > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1146ee9ead90cf054a7617b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AFAIK you dont need a SDP aswer for that.

El 11/3/2017 16:24, "C= hrister Holmberg" <christer.holmberg@ericsson.com> escribi=C3=B3:
Hi,

In case of a Data Channel, you also need to establish the SCTP association = before you can send any content.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-boun= ces@ietf.org] On Behalf Of I=C3=B1aki Baz Castillo
Sent: 11 March 2017 17:12
To: Roman Shpount <roman@telurix.co= m>
Cc: Flemming Andreasen <fandreas@c= isco.com>; hta@google.com; mmu= sic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Handling of unverified data and media

2017-03-10 23:47 GMT+01:00 Roman Shpount <roman@telurix.com>:
> My assumption always was that data is received, decoded and discarded<= br> > until fingerprint is received and verified. This way DTLS handshake > completes, key frames are decoded, but user is nor presented with any = unverified media.

Just imagine an app (running in a computer with public IP) which sends the = SDP offer to a server, DTLS handshake is done, and the server sends DataCha= nnel messages to the browser *before* the browser receives the SDP answer.<= br>
Do you mean that such a DataChannel messages should be discarded? I conside= r that catastrophic as the server may not know whether the browser has yet = received the answer or not. Apps should implement some kind of 3-way signal= ing handshake (send offer, receive answer, send
ACK) before the server sends any DataChannel message.


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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
--001a1146ee9ead90cf054a7617b6-- From nobody Sat Mar 11 07:30:35 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 0910E12951E for ; Sat, 11 Mar 2017 07:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[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 QKafL-rx-6UW for ; Sat, 11 Mar 2017 07:30:31 -0800 (PST) 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 5D852129484 for ; Sat, 11 Mar 2017 07:30:31 -0800 (PST) X-AuditID: c1b4fb25-e49bd98000004cad-8b-58c41815a0b6 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 2F.86.19629.51814C85; Sat, 11 Mar 2017 16:30:29 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Sat, 11 Mar 2017 16:30:28 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] Handling of unverified data and media Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGPrxoAgAATT2D///B1AIAAEW+A Date: Sat, 11 Mar 2017 15:30:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB06F0E@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB06EB1@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_7594FB04B1934943A5C02806D1A2204B4CB06F0EESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2K7k66oxJEIg3XT9CzeX9C1OHHjNLPF 9H02FlOXP2axmHFhKrMDq8e5hvfsHlN+b2T1WLCp1GPJkp9MHremFASwRnHZpKTmZJalFunb JXBlTP3KV3AttKJnz0m2BsYVwV2MnBwSAiYSM05PZeli5OIQEljHKHH47xooZzGjxKeLk9m6 GDk42AQsJLr/aYM0iAjYSPy7cIEdpIZZYBajxNYt3awgNcIC1hJX+sFMkJqVv2ohyt0kzl1+ zQ5iswioSvw42ARm8wr4Smyf3MIGsWoDs8Sr62cZQRKcAoESqyd2s4DYjAJiEt9PrWECsZkF xCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC2EoSaw9vZ4Goz5d4dWwpG8QyQYmTM5+wTGAUmYVk 1CwkZbOQlM0CeoFZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tTspNNzLWSy3K TC4uzs/Ty0st2cQIjMODW36r7mC8/MbxEKMAB6MSD2/B/kMRQqyJZcWVuYcYJTiYlUR4PeYD hXhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamAsPSjRGen1 TLxJrKji2h+BeWs4Ju6ZdOrKUTuXdpnSQ9umyXTq7J5R317VtzeNaYVlt/0pZ+a6Uw+Nwkof 9sVK67a9iSsPiH73tuL0x2OFDMELD9grZqTdS3uTXjzvYPXZv8s5/DbZBvl+mTVnRdKHQ+yn 9uw+yeQ9S9Pip6/H41IGc56rBiVKLMUZiYZazEXFiQDTThcpvwIAAA== Archived-At: Cc: Flemming Andreasen , "hta@google.com" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 15:30:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB06F0EESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5BRkFJSyB5b3UgZG9udCBuZWVkIGEgU0RQIGFzd2VyIGZvciB0aGF0Lg0KDQpQZXJo YXBzIG5vdCwgYnV0IGl0IHdpbGwgc3RpbGwgdGFrZSBzb21lIHRpbWUgdG8gZG8sIHNvIG1heWJl IHRoZSBvZmZlcmVyIHdpbGwgaGF2ZSByZWNlaXZlZCB0aGUgYW5zd2VyIG9uY2UgaXTigJlzIGRv bmUgYW5kIGl0IGlzIHBvc3NpYmxlIHRvIHN0YXJ0IHNlbmRpbmcgYW55IG1lZGlhPw0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkVsIDExLzMvMjAxNyAxNjoyNCwgIkNocmlzdGVyIEhvbG1i ZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+PiBlc2NyaWJpw7M6DQpIaSwNCg0KSW4gY2FzZSBvZiBhIERhdGEg Q2hhbm5lbCwgeW91IGFsc28gbmVlZCB0byBlc3RhYmxpc2ggdGhlIFNDVFAgYXNzb2NpYXRpb24g YmVmb3JlIHlvdSBjYW4gc2VuZCBhbnkgY29udGVudC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBJw7Fha2kgQmF6IENhc3RpbGxvDQpTZW50OiAxMSBNYXJjaCAyMDE3IDE3OjEyDQpU bzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tPj4NCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbTxtYWlsdG86 ZmFuZHJlYXNAY2lzY28uY29tPj47IGh0YUBnb29nbGUuY29tPG1haWx0bzpodGFAZ29vZ2xlLmNv bT47IG1tdXNpYyBXRyA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtNTVVTSUNdIEhhbmRsaW5nIG9mIHVudmVyaWZpZWQgZGF0YSBhbmQgbWVk aWENCg0KMjAxNy0wMy0xMCAyMzo0NyBHTVQrMDE6MDAgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVs dXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj46DQo+IE15IGFzc3VtcHRpb24gYWx3 YXlzIHdhcyB0aGF0IGRhdGEgaXMgcmVjZWl2ZWQsIGRlY29kZWQgYW5kIGRpc2NhcmRlZA0KPiB1 bnRpbCBmaW5nZXJwcmludCBpcyByZWNlaXZlZCBhbmQgdmVyaWZpZWQuIFRoaXMgd2F5IERUTFMg aGFuZHNoYWtlDQo+IGNvbXBsZXRlcywga2V5IGZyYW1lcyBhcmUgZGVjb2RlZCwgYnV0IHVzZXIg aXMgbm9yIHByZXNlbnRlZCB3aXRoIGFueSB1bnZlcmlmaWVkIG1lZGlhLg0KDQpKdXN0IGltYWdp bmUgYW4gYXBwIChydW5uaW5nIGluIGEgY29tcHV0ZXIgd2l0aCBwdWJsaWMgSVApIHdoaWNoIHNl bmRzIHRoZSBTRFAgb2ZmZXIgdG8gYSBzZXJ2ZXIsIERUTFMgaGFuZHNoYWtlIGlzIGRvbmUsIGFu ZCB0aGUgc2VydmVyIHNlbmRzIERhdGFDaGFubmVsIG1lc3NhZ2VzIHRvIHRoZSBicm93c2VyICpi ZWZvcmUqIHRoZSBicm93c2VyIHJlY2VpdmVzIHRoZSBTRFAgYW5zd2VyLg0KDQpEbyB5b3UgbWVh biB0aGF0IHN1Y2ggYSBEYXRhQ2hhbm5lbCBtZXNzYWdlcyBzaG91bGQgYmUgZGlzY2FyZGVkPyBJ IGNvbnNpZGVyIHRoYXQgY2F0YXN0cm9waGljIGFzIHRoZSBzZXJ2ZXIgbWF5IG5vdCBrbm93IHdo ZXRoZXIgdGhlIGJyb3dzZXIgaGFzIHlldCByZWNlaXZlZCB0aGUgYW5zd2VyIG9yIG5vdC4gQXBw cyBzaG91bGQgaW1wbGVtZW50IHNvbWUga2luZCBvZiAzLXdheSBzaWduYWxpbmcgaGFuZHNoYWtl IChzZW5kIG9mZmVyLCByZWNlaXZlIGFuc3dlciwgc2VuZA0KQUNLKSBiZWZvcmUgdGhlIHNlcnZl ciBzZW5kcyBhbnkgRGF0YUNoYW5uZWwgbWVzc2FnZS4NCg0KDQotLQ0KScOxYWtpIEJheiBDYXN0 aWxsbw0KPGliY0BhbGlheC5uZXQ8bWFpbHRvOmliY0BhbGlheC5uZXQ+Pg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlz dA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0K --_000_7594FB04B1934943A5C02806D1A2204B4CB06F0EESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwv c3Bhbj5BRkFJSyB5b3UgZG9udCBuZWVkIGEgU0RQIGFzd2VyIGZvciB0aGF0LjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlBlcmhhcHMgbm90LCBidXQgaXQgd2lsbCBzdGlsbCB0YWtlIHNvbWUgdGltZSB0byBkbywg c28gbWF5YmUgdGhlIG9mZmVyZXIgd2lsbCBoYXZlIHJlY2VpdmVkIHRoZSBhbnN3ZXIgb25jZSBp dOKAmXMgZG9uZSBhbmQgaXQgaXMgcG9zc2libGUgdG8gc3RhcnQgc2VuZGluZyBhbnkNCiBtZWRp YT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5FbCAxMS8zLzIwMTcgMTY6MjQsICZxdW90O0NocmlzdGVyIEhvbG1iZXJn JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Ij5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyBlc2NyaWJpw7M6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJy Pg0KSW4gY2FzZSBvZiBhIERhdGEgQ2hhbm5lbCwgeW91IGFsc28gbmVlZCB0byBlc3RhYmxpc2gg dGhlIFNDVFAgYXNzb2NpYXRpb24gYmVmb3JlIHlvdSBjYW4gc2VuZCBhbnkgY29udGVudC48YnI+ DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBtbXVzaWMgW21haWx0bzo8YSBocmVmPSJtYWls dG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0g T24gQmVoYWxmIE9mIEnDsWFraSBCYXogQ2FzdGlsbG88YnI+DQpTZW50OiAxMSBNYXJjaCAyMDE3 IDE3OjEyPGJyPg0KVG86IFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbSI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCkNjOiBGbGVtbWluZyBB bmRyZWFzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20iPmZhbmRyZWFz QGNpc2NvLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmh0YUBnb29nbGUuY29tIj5odGFA Z29vZ2xlLmNvbTwvYT47IG1tdXNpYyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10g SGFuZGxpbmcgb2YgdW52ZXJpZmllZCBkYXRhIGFuZCBtZWRpYTxicj4NCjxicj4NCjIwMTctMDMt MTAgMjM6NDcgR01UJiM0MzswMTowMCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs6PGJyPg0KJmd0OyBN eSBhc3N1bXB0aW9uIGFsd2F5cyB3YXMgdGhhdCBkYXRhIGlzIHJlY2VpdmVkLCBkZWNvZGVkIGFu ZCBkaXNjYXJkZWQ8YnI+DQomZ3Q7IHVudGlsIGZpbmdlcnByaW50IGlzIHJlY2VpdmVkIGFuZCB2 ZXJpZmllZC4gVGhpcyB3YXkgRFRMUyBoYW5kc2hha2U8YnI+DQomZ3Q7IGNvbXBsZXRlcywga2V5 IGZyYW1lcyBhcmUgZGVjb2RlZCwgYnV0IHVzZXIgaXMgbm9yIHByZXNlbnRlZCB3aXRoIGFueSB1 bnZlcmlmaWVkIG1lZGlhLjxicj4NCjxicj4NCkp1c3QgaW1hZ2luZSBhbiBhcHAgKHJ1bm5pbmcg aW4gYSBjb21wdXRlciB3aXRoIHB1YmxpYyBJUCkgd2hpY2ggc2VuZHMgdGhlIFNEUCBvZmZlciB0 byBhIHNlcnZlciwgRFRMUyBoYW5kc2hha2UgaXMgZG9uZSwgYW5kIHRoZSBzZXJ2ZXIgc2VuZHMg RGF0YUNoYW5uZWwgbWVzc2FnZXMgdG8gdGhlIGJyb3dzZXIgKmJlZm9yZSogdGhlIGJyb3dzZXIg cmVjZWl2ZXMgdGhlIFNEUCBhbnN3ZXIuPGJyPg0KPGJyPg0KRG8geW91IG1lYW4gdGhhdCBzdWNo IGEgRGF0YUNoYW5uZWwgbWVzc2FnZXMgc2hvdWxkIGJlIGRpc2NhcmRlZD8gSSBjb25zaWRlciB0 aGF0IGNhdGFzdHJvcGhpYyBhcyB0aGUgc2VydmVyIG1heSBub3Qga25vdyB3aGV0aGVyIHRoZSBi cm93c2VyIGhhcyB5ZXQgcmVjZWl2ZWQgdGhlIGFuc3dlciBvciBub3QuIEFwcHMgc2hvdWxkIGlt cGxlbWVudCBzb21lIGtpbmQgb2YgMy13YXkgc2lnbmFsaW5nIGhhbmRzaGFrZSAoc2VuZCBvZmZl ciwgcmVjZWl2ZQ0KIGFuc3dlciwgc2VuZDxicj4NCkFDSykgYmVmb3JlIHRoZSBzZXJ2ZXIgc2Vu ZHMgYW55IERhdGFDaGFubmVsIG1lc3NhZ2UuPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+DQpJw7Fh a2kgQmF6IENhc3RpbGxvPGJyPg0KJmx0OzxhIGhyZWY9Im1haWx0bzppYmNAYWxpYXgubmV0Ij5p YmNAYWxpYXgubmV0PC9hPiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB06F0EESESSMB109erics_-- From nobody Sat Mar 11 13:40: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 E15221295DD for ; Sat, 11 Mar 2017 13:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 EnVClMRCMO70 for ; Sat, 11 Mar 2017 13:40:37 -0800 (PST) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (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 11EAE1295DF for ; Sat, 11 Mar 2017 13:40:35 -0800 (PST) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 196FC5762; Sat, 11 Mar 2017 16:40:35 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5FA1A56F7; Sat, 11 Mar 2017 16:40:34 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.61] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sat, 11 Mar 2017 16:40:35 -0500 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: Sat, 11 Mar 2017 14:40:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51B1CC11-ABD7-4600-8962-D62715E856F2@iii.ca> References: To: Bernard Aboba X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Flemming Andreasen , Harald Alvestrand , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 21:40:39 -0000 Seem like this question is way out of scope for MMUSIC. This is about = some policy question at the application layer. Cleary the MMUSIC specs = support things that play unverified media as well as applications that = would not want to play it.=20 > On Mar 9, 2017, at 1:10 PM, Bernard Aboba = wrote: >=20 > In the W3C WEBRTC WG, an issue has been submitted relating to playout = of unverified media: > https://github.com/w3c/webrtc-pc/issues/849 >=20 > It has been suggested that if the browser is configured to do so, that = playout be allowed for a limited period (e.g. 5 seconds) prior to = fingerprint verification: > https://github.com/w3c/webrtc-pc/pull/1026 >=20 > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following = text, carried over from RFC 4572: >=20 > Note that when the offer/answer model is being used, it is possible > for a media connection to outrace the answer back to the offerer. > Thus, if the offerer has offered a 'setup:passive' or = 'setup:actpass' > role, it MUST (as specified in RFC 4145 [7]) begin listening for an > incoming connection as soon as it sends its offer. However, it = MUST > NOT assume that the data transmitted over the TLS connection is = valid > until it has received a matching fingerprint in an SDP answer. If > the fingerprint, once it arrives, does not match the client's > certificate, the server endpoint MUST terminate the media = connection > with a bad_certificate error, as stated in the previous paragraph. >=20 > Given the outstanding issue relating to handling of unverified media, = the Chairs of the W3C WEBRTC WG would like to request clarification from = the IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above = paragraph. In particular, what is it permitted for an implementation to = do with received data and media prior to verification? For example: >=20 > 1. May data received over the data channel be provided to the = application prior to verification? > a. If the answer to the above is "no", may unverified = received data be delivered by the DTLS transport to SCTP, which may = buffer it? > 2. May received media be played out prior to verification? >=20 > Bernard Aboba > On behalf of the W3C WEBRTC WG > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Sun Mar 12 12:18:58 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 3F6B9128B38; Sun, 12 Mar 2017 12:18:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148934633723.24730.4436854038726184651@ietfa.amsl.com> Date: Sun, 12 Mar 2017 12:18:57 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:18:57 -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 of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-21.txt Pages : 26 Date : 2017-03-12 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a 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, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-21 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 Mar 12 12:25: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 054EC1294C0; Sun, 12 Mar 2017 12:25:29 -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 9DEq6oiCLiBm; Sun, 12 Mar 2017 12:25:28 -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 75A441294AB; Sun, 12 Mar 2017 12:25:27 -0700 (PDT) X-AuditID: c1b4fb25-e49bd98000004cad-5d-58c5a0a51750 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id FC.27.19629.5A0A5C85; Sun, 12 Mar 2017 20:25:25 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Sun, 12 Mar 2017 20:24:59 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-ietf-mmusic-dtls-sdp-21 Thread-Index: AdKbZaPajQwTNRuhRsuO0SHjC2mREg== Date: Sun, 12 Mar 2017 19:24:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB08B6E@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_7594FB04B1934943A5C02806D1A2204B4CB08B6EESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2K7je7SBUcjDBYul7c4v3M9k8XU5Y9Z HJg8liz5yRTAGMVlk5Kak1mWWqRvl8CVsaUnsWCCVMWjzedZGhh/iHUxcnJICJhIbHt6m72L kYtDSGAdo8Si66uYIJzFjBL7jh9j6WLk4GATsJDo/qcN0iAioC7xdW8PM4jNLGAq8fDVGkYQ W1jAUmLT4flMEDV2Evd2bmWHsPUkWpZPBatnEVCV6P/yngXE5hXwlZg14RBYDaOAmMT3U2uY IGaKS9x6AjFHQkBAYsme88wQtqjEy8f/WCFsJYnGJU9YIerzJU6++MoKMVNQ4uTMJywTGIVm IRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcVJuupGxXmpRZnJx cX6eXl5qySZGYGwc3PJbdQfj5TeOhxgFOBiVeHg3zDoaIcSaWFZcmXuIUYKDWUmE12UmUIg3 JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQZG57WqOkHzbd8K Xj59tIol7ti/4xLVt/tDV09jfX7GtIPxIL91YmUvm5kvv3ucUUyQ8Y8np9nUpTue17M90zl9 p8I2p4HT1jB304sHR70X3G6NCQ7z0GPw0So5e2k+q3WUrPBpTanQaZfOXrim8knxea9bvkb9 udTtz++X/6z4ePzjsd+7p+5UYinOSDTUYi4qTgQAOedm9okCAAA= Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-21 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Mar 2017 19:25:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB08B6EESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments from Martin T and Paul J regarding the length of the = dtls-id attribute value, I've submitted a new version (-21) of draft-ietf-m= music-dtls-sdp. The min length of the value has been increased to 20 octets (from 6), and t= he max length has been decreased to 255 octets (from 256). There are no other technical changes. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB08B6EESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the comments from Martin T and Paul J regar= ding the length of the dtls-id attribute value, I’ve submitted a new = version (-21) of draft-ietf-mmusic-dtls-sdp.

 

The min length of the value has been increased to 20= octets (from 6), and the max length has been decreased to 255 octets (from= 256).

 

There are no other technical changes.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB08B6EESESSMB109erics_-- From nobody Sun Mar 12 17:33: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 92E3C12944D for ; Sun, 12 Mar 2017 17:33:31 -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 jYp5dBmmuOHf for ; Sun, 12 Mar 2017 17:33:30 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 8C7BE129410 for ; Sun, 12 Mar 2017 17:33:30 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id v125so208012904qkh.2 for ; Sun, 12 Mar 2017 17:33:30 -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=Fvi98iJ5qnx92E6lmvQuhFYPREyZd/HA7Ih/VLcRmj8=; b=M9BkZwvGhXQyQpvRQFhPD/31shqDlY9O18Fm2gez5PNMGHhsLiAMPCLSKWXRRxDhIu Qu9ydomNa74lqNulOVELWCy0mND9rDjXh4WwaefmfzhHk1LvJDVF+QznxEDoHILoShv5 E82alfy2QL2A7OMYsAzpiuEVeAGM/Qdp3Hj0/5PfIgVgcgu8C/4ZPlv+yY/ypyu4KMBY LsHWLAI/KGv6CgUfzuf/YaRRE89A1jCJOC7bFLbP20jmU7MWRelOjMrLgTkZflQLETE7 TayG0xRr1O+vxZ0rGkreuCssCVpBnoiPZ7e4rtzVTN2GoXLfJ+ps7TiGnckS7qS1g6fp HccQ== 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=Fvi98iJ5qnx92E6lmvQuhFYPREyZd/HA7Ih/VLcRmj8=; b=X4cyLRDTri3dQeleRErQqlkXDatftRLW5GFOWmpcCk9sSyvIfMohHT4+4wyKxN4gyk zTyPo5otJQ7eSxfg2KT5RXyBtWFFNS8FNG3mmF+fH93RlcTu3RmbqmygFlA3i8rl291+ 48pM89p0YA1N4EOnFLa7upnwIP/DCTFcMY/U5neFhUJ3WVNU0Jz9gTW8oTI4qIMJS9pg XYizF9Znp+0hWLTa6K1UJeAmItKuIJ3M5r7fCa87N4Mf58szxVJvKuszQIgqve7AXAYa f7eLlgxlB2u2vlCnM1YWgvFUySd5LPi3is8cjwa6/oQamWJKIclkPEudf8yvI3i7A/22 fiFw== X-Gm-Message-State: AMke39m8bQmCRuH86ZE/xrDAY+HdQ8fbA2vju+wocgxZ+Sti6/eet2AtIfBBw61/z7BtUGVClG45+D5IiHe99A== X-Received: by 10.55.185.131 with SMTP id j125mr28633192qkf.115.1489365209738; Sun, 12 Mar 2017 17:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Sun, 12 Mar 2017 17:33:29 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 13 Mar 2017 11:33:29 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Flemming Andreasen , "hta@google.com" , mmusic WG Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 00:33:31 -0000 On 11 March 2017 at 11:01, Eric Rescorla wrote: > I haven't spent too much time on it, but it seems like it ought to be safe > to hold > anything you receive prior to getting the fingerprint. It might be better, > as MT > suggests, to discard the datachannel data, but I'm not sure why it would be > necessary. I didn't consider holding data, which should be fine. If the fingerprint later turns out to be bad, then it's easy to pretend you were hit by a spate of packet loss than hold arbitrary amounts of (potential) junk. From nobody Sun Mar 12 18:52: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 E789C129494 for ; Sun, 12 Mar 2017 18:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 VKpH0oA6t-A3 for ; Sun, 12 Mar 2017 18:52:22 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999B2129483 for ; Sun, 12 Mar 2017 18:52:22 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id D3C58111D259D; Mon, 13 Mar 2017 01:52:20 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id v2D1qLYL011474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Mar 2017 01:52:21 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id v2D1qKEk015163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Mar 2017 01:52:20 GMT Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Sun, 12 Mar 2017 21:52:20 -0400 From: "Makaraju, Raju (Nokia - US)" To: Bo Burman , "mmusic (mmusic@ietf.org)" Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AdKR1myZplopSuFrSp2L99aM0eEZvwJvXIow Date: Mon, 13 Mar 2017 01:52:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A178201530CFCC4US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 01:52:25 -0000 --_000_E1FE4C082A89A246A11D7F32A95A178201530CFCC4US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bo Burman, Christian Groves, Paul Kyzivat, Thank you so much for your time in making this document better, we apprecia= te it. Sorry for the extended delay. I accepted all the comments. Please see my comments inserted below. Thanks again Raju From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: Tuesday, February 28, 2017 10:11 AM To: mmusic (mmusic@ietf.org) Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-= sdpneg-11 Authors, WG, I think this document is getting ready for publication request. As part of = making the shepherd's write-up, I have the following comments, to be addres= sed in an updated document: Issues: 1) In section 1: add that also BFCP (Binary Floor Control Protocol) i= s used in the same way as MSRP in examples. [Raju] Will add BFCP. 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite length of t= his identifier, which seems inappropriate. I suggest providing a maximum le= ngth, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960)= , in which case 1*5DIGIT should be sufficient. [Raju] Will change as suggested. 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" af= ter "%" when defining hex characters. Change to: quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % [Raju] Will change as suggested. 4) In 5.1.2.1, text below the example makes reference to MSRP subproto= col, but the example does not explicitly include any MSRP. The single examp= le line uses "accept-types", which is admittedly related to MSRP, but I thi= nk this should be clarified to avoid confusion for readers not familiar wit= h MSRP. [Raju] Will change "Example" to "Example (other MSRP related SDP attributes= are omitted for brevity):" 5) In 5.2.2: It is unclear why you differentiate handling of offers an= d answers that contain both "max-retr" and "max-time", mandating to reject = the offer but allowing it in the answer. I think allowing this asymmetry sh= ould either be motivated, or handling should be aligned between offer and a= nswer. [Raju] I think it was thought giving a bit of flexibility to offerer while = receiving answer is probably good but I see your point on aligning both. Wi= ll change text to align both. 6) In section 6: several examples uses IP addresses that are not align= ed with RFC 6890 (10.10.10.x), which must be changed. Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3). [Raju] Will change as suggested. 7) In Appendix A: same IP address issue as above, change from 79.97.21= 5.79 to an address in the allowed range. [Raju] Will change as suggested. Nits: 1) The date line in the document header is one character too long (bey= ond column 72) [Raju] Good catch! Hmmm... not sure how it is getting messed up as the it i= s supposed to be an auto generated line. Anyway, I just checked the new upd= ated draft at https://xml2rfc.tools.ietf.org and output looks good. 2) In section 1: s/In future data channels could/In the future, data c= hannels could/ [Raju] Will change as suggested. 3) In section 3: s/sending and receive data/sending and receiving data= / [Raju] Will change as suggested. 4) At the very end of section 5.1.2.1: s/in the same document, which r= egisters/in the same document that registers/ [Raju] Will change as suggested. 5) In 5.2.4: s/other data channels which are now not included/other da= ta channels that are now not included/ [Raju] Will change as suggested. 6) In 5.2.5: s/channels are expected be closed now/channels are expect= ed to be closed now/ [Raju] Will change as suggested. 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHA= LL use/ [Raju] Will change as suggested. 8) In Appendix A.1: s/either pass to the data channel stack the stream= identifier to assign/either pass the stream identifier to the data channel= stack to assign/ [Raju] Will change as suggested. 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? Comments from others that are not addressed in -11: 1) Christian Groves commented on Jan 20 that the example in Appendix A= should contain an "a=3Ddtls-id:..." attribute as per other examples in the= draft. [Raju] Will add a=3Ddtls-id. 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 sho= uld be changed to: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. [Raju] Will change as suggested. Thanks raju Cheers, /Bo MMUSIC co-chair --_000_E1FE4C082A89A246A11D7F32A95A178201530CFCC4US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bo Burman, Christian Groves, Paul Kyzivat,

 

Thank you so much for your time in making this docum= ent better, we appreciate it. Sorry for the extended delay.

I accepted all the comments.

Please see my comments inserted below.

 

Thanks again

Raju

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org]= On Behalf Of Bo Burman
Sent: Tuesday, February 28, 2017 10:11 AM
To: mmusic (mmusic@ietf.org) <mmusic@ietf.org>
Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-c= hannel-sdpneg-11

 

Authors, WG,

 

I think this document is getting ready for publicati= on request. As part of making the shepherd’s write-up, I have the fol= lowing comments, to be addressed in an updated document:

 

Issues:

1)      In section 1: add that also BFCP (Binary Floor Cont= rol Protocol)  is used in the same way as MSRP in examples.=

[Raju] Will add BFCP.

2)      In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infi= nite length of this identifier, which seems inappropriate. I suggest provid= ing a maximum length, maybe matching this to the unsigned 16 bit integer in= SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

[Raju] Will change as suggested.<= /o:p>

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect= , missing “x” after “%” when defining hex character= s. Change to:
quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or= %

[Raju] Will change as suggested.<= /o:p>

4)      In 5.1.2.1, text below the example makes reference = to MSRP subprotocol, but the example does not explicitly include any MSRP. = The single example line uses “accept-types”, which is admittedl= y related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

[Raju] Will change “Example” to &#= 8220;Example (other MSRP related SDP attributes are omitted for brevity):&#= 8221;

5)      In 5.2.2: It is unclear why you differentiate handl= ing of offers and answers that contain both “max-retr” and R= 20;max-time”, mandating to reject the offer but allowing it in the an= swer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

[Raju] I think it was thought giving a bit of = flexibility to offerer while receiving answer is probably good but I see yo= ur point on aligning both. Will change text to align both.

6)      In section 6: several examples uses IP addresses th= at are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3).

[Raju] Will change as suggested. =

7)      In Appendix A: same IP address issue as above, chan= ge from 79.97.215.79 to an address in the allowed range.

[Raju] Will change as suggested. =

 

Nits:

1)      The date line in the document header is one charact= er too long (beyond column 72)

[Raju] Good catch! Hmmm… not sure how it= is getting messed up as the it is supposed to be an auto generated line. A= nyway, I just checked the new updated draft at https://xml2rfc.tools.ietf.org and output l= ooks good.

2)      In section 1: s/In future data channels could/In th= e future, data channels could/

[Raju] Will change as suggested. =

3)      In section 3: s/sending and receive data/sending an= d receiving data/

[Raju] Will change as suggested. =

4)      At the very end of section 5.1.2.1: s/in the same d= ocument, which registers/in the same document that registers/

[Raju] Will change as suggested. =

5)      In 5.2.4: s/other data channels which are now not i= ncluded/other data channels that are now not included/

[Raju] Will change as suggested.<= /o:p>

6)      In 5.2.5: s/channels are expected be closed now/cha= nnels are expected to be closed now/

[Raju] Will change as suggested.<= /o:p>

7)      In 8.3: s/dcsa usage level only shall use/dcsa usag= e level only SHALL use/

[Raju] Will change as suggested.<= /o:p>

8)      In Appendix A.1: s/either pass to the data channel = stack the stream identifier to assign/either pass the stream identifier to = the data channel stack to assign/

[Raju] Will change as suggested.<= /o:p>

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

Comments from others that are not addressed in -11:<= o:p>

1)      Christian Groves commented on Jan 20 that the examp= le in Appendix A should contain an “a=3Ddtls-id:…” attrib= ute as per other examples in the draft.

[Raju] Will add a= =3Ddtls-id.

2)      Paul Kyzivat commented on Jan 21 that a bullet in s= ection 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and    channel parameters contained in the SDP offer.=

[Raju] Will change as suggested.

 

Thanks

raju

 

Cheers,

/Bo

MMUSIC co-chair

 

--_000_E1FE4C082A89A246A11D7F32A95A178201530CFCC4US70UWXCHMBA0_-- From nobody Mon Mar 13 00:49: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 76D6012954A for ; Mon, 13 Mar 2017 00:49:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 YC0JQ9F6c7BL for ; Mon, 13 Mar 2017 00:49:04 -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 0A9B0129555 for ; Mon, 13 Mar 2017 00:49:02 -0700 (PDT) X-AuditID: c1b4fb30-3623498000006a1c-4a-58c64eec1db4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id C3.97.27164.CEE46C85; Mon, 13 Mar 2017 08:49:01 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 08:49:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GQGx9FGxr6HOe156mqBNwPLkeQ3bY7D/xNMAsU+PjP4=; b=dG+ztCvHMrF5ZsfKMP584k/YY2S0I/SXySoQMDnvv7ieCtoTnBJpsHJ7ELEMBpne4s4O3kWZlIeE4h/Zl1v76kw7Ffue/8qmDKlWxMqyLJmeJTAdej8El9cgr2kxx0vntvmavFF+6/RaM6bWUKc/fcG9ECJra1LmhI+atNAm6PY= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2580.eurprd07.prod.outlook.com (10.173.92.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Mon, 13 Mar 2017 07:48:59 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 07:48:59 +0000 From: Bo Burman To: "Dale R. Worley" , Paul Kyzivat Thread-Topic: [MMUSIC] Definition of a=rid in draft-ietf-mmusic-rid-09 (was WGLC on draft-ietf-mmusic-sdp-simulcast-07) Thread-Index: AQHSlrL4esDi3DOgc0yWhkgaTA0R2KGSaVWA Date: Mon, 13 Mar 2017 07:48:58 +0000 Message-ID: References: (pkyzivat@alum.mit.edu) <87zigychho.fsf@hobgoblin.ariadne.com> In-Reply-To: <87zigychho.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2580; 7:sF4nDur9DVk+HIG8j7UNOd7Io7lEY5TA6D9oBqPAw0Pz6W0L72uaX4PjW5itnWny5yS8gqVhEEGRQs4vVhPZi8PnaKeQOjO00L56aRQKJCXg4t+h1bxxRD4jI6vfT6rNll/6vLNMnkQruC5sxVhavp4BEhsFCFHileAJu5LV6dnDwS/dJoKZNIo5XtGpHiLXpFU52hCG86bGqmb8zp6WqX4cKYEFU3wwcyqaVAdd4l/gUnhLjlp1hCyJd6fVhfcfQTK7vxTdcliyhFtcKuVPC2IsuemA+eHolgDr4Vm80+Ks7Z8j1MrxhhZqfKo0daQ4GV6Ysoa4CQBtAD5axD1LXA== x-ms-office365-filtering-correlation-id: 8f01a692-32f0-4c1a-561a-08d469e568ba x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2580; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM5PR0701MB2580; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2580; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(377454003)(24454002)(13464003)(33656002)(6506006)(8936002)(31430400001)(2171002)(9686003)(38730400002)(6246003)(53936002)(50986999)(76176999)(66066001)(54356999)(99286003)(3660700001)(230783001)(6306002)(2950100002)(55016002)(4326008)(106116001)(122556002)(7696004)(305945005)(229853002)(25786008)(3280700002)(86362001)(2900100001)(5660300001)(81166006)(74316002)(6436002)(53546006)(189998001)(102836003)(77096006)(2906002)(6116002)(8676002)(3846002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2580; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 07:48:58.9560 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2580 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42KZGbHdQPet37EIg5avzBZTlz9msVix4QCr xcsTZQ7MHn/ff2DymLz/K7PHkiU/mQKYo7hsUlJzMstSi/TtErgyPkycyFjQoFTxdPMBtgbG N5JdjJwcEgImEp+XLGTrYuTiEBJYxyjRdvs2lHOCUeLooimsIFUsAr3MEguXMEMkZjBJfPj8 gRmu6vislYwgVWwCGhLzd9wFs0UEAiW2dZ0G6ubgYBZQl7i6OAgkLCxQIbHxzE9WiJJKiXO3 QYaC2EYSb08tZ4FYpipxZOMXsDivQILE3p/boC5qYJSYtusn2HxOAWOJL6+72UBsRgExie+n 1jCB2MwC4hK3nsxngvhNQGLJnvPMELaoxMvH/1gh6icyStxqNICIK0i86m4AWyAh0McscXTB ZVaIhK/E+/2zoZr9JZYt/MAI8oyEQL7EtOXZEGEtiY4js5ggeucxSfSveQRVLyOxaEcrG4Td yyoxfaIwxPdSEnevdDJC2DISL+7sZZ3AqDkLyd0Qto7Egt2f2CBsbaDVr5lngQNDUOLkzCcs CxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIEJpKDW34b7GB8+dzxEKMAB6MSD++GWUcj hFgTy4orcw8xSnAwK4nwpgLTkBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNT UwtSi2CyTBycUg2MOd8Pv5x78ra54rxCju0Ktf+X5S541b8ormzrRe7KCU/eTnveGFCsZpns G7aO6fH1Bx3vLy4TvnMhkWnth/QQ306v19ZJq+YlF6z5qylfV5eiL/k41z/luNynhfvKLUIq foT/r/9R6N97ObiDZXuQ5mox9XO6SS+j/HP1LWXW9y7rPFm5Lvu2EktxRqKhFnNRcSIA1KZT aiADAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Definition of a=rid in draft-ietf-mmusic-rid-09 (was WGLC on draft-ietf-mmusic-sdp-simulcast-07) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 07:49:07 -0000 Dale, The "a=3Drid" line syntax you are quoting from -mmusic-rid-09 below is not = the formal definition and it is therefore not meant to interpret formally, = specifically not the "..." at the end, but only meant to provide an example= . The text in -mmusic-rid-09 just above that quoted line also refers to sec= tion 10 for the formal definition. ISTM that the formal definition is entir= ely correct, not lacking the ";" between rid parameters that formal interpr= etation of "..." would imply: rid-syntax =3D "a=3Drid:" rid-id SP rid-dir [ rid-pt-param-list / rid-param-list ] rid-id =3D 1*(alpha-numeric / "-" / "_") alpha-numeric =3D < as defined in {{RFC4566}} > rid-dir =3D "send" / "recv" rid-pt-param-list =3D SP rid-fmt-list *(";" rid-param) rid-param-list =3D SP rid-param *(";" rid-param) rid-fmt-list =3D "pt=3D" fmt *( "," fmt ) fmt =3D < as defined in {{RFC4566}} > rid-param =3D rid-width-param / rid-height-param / rid-fps-param / rid-fs-param / rid-br-param / rid-pps-param / rid-bpp-param / rid-depend-param / rid-param-other It is probably unfortunate that the quoted "a=3Drid" line is not 100% compl= iant ABNF, but I don't see the point in having (different) formal definitio= ns in two places in the document and the text already says that this is not= the formal definition. /Bo (as individual) > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Dale R. Worley > Sent: den 6 mars 2017 20:50 > To: Paul Kyzivat > Cc: mmusic@ietf.org > Subject: [MMUSIC] Definition of a=3Drid in draft-ietf-mmusic-rid-09 (was = WGLC on draft-ietf-mmusic-sdp-simulcast-07) >=20 > Paul Kyzivat writes: > > On 3/3/17 10:56 AM, Dale R. Worley wrote: > >> Inaki Baz Castillo writes: > >>>> but according to > >>>> https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 > >>>> it seems that "direction" (send/recv) should be placed *before* > >>>> "pt=3Dxx": > >>>> > >>>> a=3Drid: [pt=3D;]=3D... > >>> > >>> In fact, pt=3Dxx seems to be yet another "param". > >> > >> That purported BNF is really bizarre, since it generates the clearly > >> incorrect form: > > > > IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not > > in draft-ietf-mmusic-sdp-simulcast-07, right? > > > >> a=3Drid: > >> =3D=3D > > > > I'm not seeing how the ABNF generates that. >=20 > What I'm commenting on is this line way back in the innermost quoted mess= age >=20 > >>>> a=3Drid: [pt=3D;]=3D... >=20 > which was in turn quoted from draft-ietf-mmusic-rid-09. >=20 > In BNF-like notations, "..." means "repetition of the preceding thing", w= hich I took to mean repetition of > "=3D". Although that's probably not the correct inte= rpretation, and rather it means repetition of > "". >=20 > >> A correct description is: > >> > >> a=3Drid: ( pt=3D | =3D > >> ) *( ; =3D ) > > > > ISTM the ABNF in the draft is equivalent to what you have written. > > (Though yours is clearer.) >=20 > What I don't see is why mmusic-rid-09 requires the pt restriction to be i= n first position. I'm not read into it, but it seems > that there's no semantic reason why it must be first, and it makes the gr= ammar messier to force it to be so. Without that > restriction, you could just say >=20 > >> a=3Drid: =3D *( ; > >> =3D ) >=20 > and allow pt to be one of the s. >=20 > Dale >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Mar 13 01:48:03 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 4D6EE128AB0; Mon, 13 Mar 2017 01:48:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148939488127.16827.6722127323469391602@ietfa.amsl.com> Date: Mon, 13 Mar 2017 01:48:01 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 08:48:01 -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 of the IETF. Title : Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt Pages : 43 Date : 2017-03-13 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 01:51: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 7425B1294DB for ; Mon, 13 Mar 2017 01:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 N5JnzTY5N6W3 for ; Mon, 13 Mar 2017 01:51:40 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 4A6F1127ABE for ; Mon, 13 Mar 2017 01:51:40 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id r45so26581721qte.3 for ; Mon, 13 Mar 2017 01:51:40 -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=kfFwZ98JQa5RDUQNq5RSo5lPLdq0wzTAKBw8YAIzFww=; b=TliT4g2udqY+cgsiqkjBi8rZMiYHTm420bREuHfaXWSOZ5lV8jYHDUOjXKsub9AreD amUACA4BifIcLZKviF7qxYmS3nJQnjuwqEuBziHgGBTnwttHISC4Rzq+ZW6bLO68/jDb Hvc+q0pWBluJ7c2dRjAlS/fBGepEgUwGT3E8sZHTcST7GA8qzlbKyc5ygcgyiM9RqEyn iEj27O3tEWe1DXlDEajDBJS8lGCmK/+jbGitsxXXDJe8HVYMsPYRoAm6OBkjHHQwyA88 KVsWjopPSoRDK62an+t/StCaJ0UDf4GSyxak3Y/oZas1ANSouMbOjrVwWK6zAtzdXeYF bzEw== 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=kfFwZ98JQa5RDUQNq5RSo5lPLdq0wzTAKBw8YAIzFww=; b=ONw5pZyP9jqR1Lkb1NE/71ZcRwzsTurG2hj32n/cynzjt8yebqsS9RcKhrKCNG1A3v /Rd/0njqSloHWbHAtIPpYsiO+/2Iei1qNyF6HLkIkNWppSKpxfLw8Eg/UfHwRmhnrPZR QPxqwXOsWqnJrUIB9REHm4X+rdqbQ24A1PVPOvfzTn0DTbUuZjKq8T+CbqkoFwCTz5J1 NAVYektzl9AyAgWVhNJqmnHhFiQsoIq4Tqq4Lczp7a5beVfT4R60a/6iLoliBYfy/Udd xTxgKHM3XwzsCRpqxx053DvGmCZqRKBshVRDP+WXzdrii7cj+rRKrtxHnqKXcD4MuDDO RJ6w== X-Gm-Message-State: AMke39m3POCL/GYgfDJgc78YL5EmPWxF73FSq5yOjlGqCcUeK0DSV+K5Nqzyi3PZOb2SB9Xc6ABAeu7DBRb+0w== X-Received: by 10.237.42.1 with SMTP id c1mr31263023qtd.219.1489395099293; Mon, 13 Mar 2017 01:51:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Mon, 13 Mar 2017 01:51:38 -0700 (PDT) In-Reply-To: <739e4cfc-8baf-0979-8d23-ec3a605f8a3a@nostrum.com> References: <739e4cfc-8baf-0979-8d23-ec3a605f8a3a@nostrum.com> From: Suhas Nandakumar Date: Mon, 13 Mar 2017 01:51:38 -0700 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a113e0ad2d2e9ae054a98d13e Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-ice-sip-sdp-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 08:51:44 -0000 --001a113e0ad2d2e9ae054a98d13e Content-Type: text/plain; charset=UTF-8 Hello Adam Many thanks for your detailed review and apologies for the delayed response. The authors discussed on your Big Picture questions and we need help from the WG to decide on the next steps. I will be following this email with separate emails on this topic reaching out for more information. I have submitted version-12 that incorporates most of editorial and technical comments. Please let us know if there were any omissions. However, here are few comments that need more inputs from you. I have included them below for ease of readability. Section 8.1.1, final paragraph: "it's a localized decision" is extremely informal and doesn't match the general style for RFCs. Please rephrase. [Suhas] - Could you suggest a viable rephrase. Section 8.1.2, first paragraph describes a kind of difficult-to-follow situation in which an INVITE contains an offer, and the answer is provided in a PRACK response, resulting in an empty "200 OK." Two comments: (1) this would really benefit from a sequence diagram; and (2) are SBCs and ALGs likely to do the right thing with empty 200s? [Suhas] - On (2), I am not well versed with SBCs and ALGs behavior. Not sure, what is recommended that we do here. Any thoughts ? Section 4.2.2.2.3 specifies, during offer processing, that the implementation "SHOULD wait for [ICE] checks to complete" before sending an answer. Keeping in mind that these updates typically happen with the SIP UPDATE method, and given that RFC 3261 specifies "TUs SHOULD respond immediately to non-INVITE requests" (cf. RFC3261 section 17.1), I'm concerned about the timing implications here. We should minimally point out that we're explicitly telling UAs to ignore this normative statement in RFC3261, and make sure that we've done the analysis to ensure that we're not going to cause problems for the SIP state machine (I'm concerned, in particular, about unnecessary SIP retransmissions here). [Suhas] - I am not aware of any analysis being done. What do you suggest we need to do ? Thanks Suhas On Thu, Jan 12, 2017 at 2:46 PM, Adam Roach wrote: > I've done a review of draft-ietf-mmusic-ice-sip-sdp-10, and have a > handful of comments. I've broken these down into three sections: > big-picture questions, technical comments, and editorial comments. I > apologize for the lateness in posting this review; the comments are > substantial, and converting them into email form took far longer than I > anticipated. > > > Big Picture Questions > > The text in section 9, read literally, deprecates RFCs 4091 and 4092. If > that is the actual intention, the abstract and "obsoletes" metadata need to > be updated to reflect this fact. If the deprecation is qualified (e.g., the > RFCs are still okay in other contexts, but should not be used in > conjunction with ICE), then the text in section 9 needs to be much clearer. > > It's not clear to me what the relationship is between this document and > RFC 5245 (and, for that matter, 6544). Is this supposed to obsolete RFC > 5245? That appears to be the intention. It's also not clear why we would > obsolete 5245 without also incorporating 6544 -- it seems that doing so > leaves the use of ICE TCP with SIP to be kind of in limbo. > > Assuming the intention *is* to replace RFC 5245, the structure of this > document seems to leave non-SIP uses of RFC3264 (e.g., WebRTC) stranded. If > the intention is *not* to replace RFC 5245, the replication of all of the > SDP syntax seems to be problematic: the the case of a conflict, which > specification is intended to govern? > > In short, I think the relationship between this document, the contemporary > work (e.g., ICE-BIS), and the historical work on which it is based needs to > be made much clearer in the document itself, and we need to have a clear > picture about how to handle SDP for non-SIP uses of ICE (e.g., by splitting > this document into an SDP part and a SIP part, similar to how we split 3264 > from 3261). > > > Technical Comments > > I believe that the RECOMMENDED-strength normative statement in the final > paragraph of 4.1.1.1 overstates things a bit. While this guidance makes set > in certain circumstances. For example, for devices that are known to > typically known to be on a single network with mutual routability, using a > relayed candidate as a default will lead to calls being unnecessarily sent > out of network and back. I strongly suggest that this paragraph be reworked > to be a considered discussion of the different trade-offs involved in using > each kind of candidate, with a non-normative suggestion to make the > behavior configurable in user agents. What I want to avoid here is guidance > which leads to devices behind a single ALG necessarily going through two > relays by default when talking to each other (which is what the current > guidance can lead to -- I can sketch this out in more detail if it's not > obvious how this happens). > > Section 4.1.1.2 uses the word "media stream" in a way that's not > consistent with the way that term is defined by RFC 7656, which could lead > to confusion. In RFC 7656 terminology, "media stream" is an alias for "RTP > stream," which is identified by a single SSRC. With technologies such as > simulcast. A single m-line can contain multiple media streams. I think you > want the term "source stream," with a citation of that term in RFC 7656. > > Section 4.1.1.2 discusses ice-options attributes in the terms of > "support", without any discussion of activation. Although this is treated > (somewhat lightly) later in the document, this smells like the same kind of > potential morass we ran into with SIP options tags: the patchwork means of > indicating feature *support* versus feature *activation* made it very > difficult to specify and implement things in a consistent fashion. I > strongly recommend that this document spend a bit more text discussing this > distinction, and maybe even consider a formal syntax for distinguishing > between supported and activated features. > > Section 4.1.3 should probably point out that, in the case of forking, the > same local candidates are used for all branches of the fork. > > Section 4.2, section paragraph: replace "be rejected" with "fail" -- there > are more ways to fail than rejection, and the action should be the same for > rejection as for other failures. > > Section 4.2.1.2 should add motivation for the requirement imposed by its > second paragraph, or the requirement should be removed. The need to do this > is not obvious, and I suspect it may be unnecessary. > > Section 4.2.2.2.3 specifies, during offer processing, that the > implementation "SHOULD wait for [ICE] checks to complete" before sending an > answer. Keeping in mind that these updates typically happen with the SIP > UPDATE method, and given that RFC 3261 specifies "TUs SHOULD respond > immediately to non-INVITE requests" (cf. RFC3261 section 17.1), I'm > concerned about the timing implications here. We should minimally point out > that we're explicitly telling UAs to ignore this normative statement in > RFC3261, and make sure that we've done the analysis to ensure that we're > not going to cause problems for the SIP state machine (I'm concerned, in > particular, about unnecessary SIP retransmissions here). > > Section 4.2.4.1.4: the final paragraph seems to reiterate behavior > described in ICE-BIS. It's probably not ideal to describe this in two > places, as any subtle difference can result in interop problems. > > Given the state of ICE today, I think the definition of "candidate" in > section 5.1 should also include the syntax for TCP transports. > > Section 5.1, : the language in here that states "If > the DNS query returns more than on IP address, on is chosen," implying that > one is chosen at random. There are specific procedures for how this is done > (especially with IPv6); the statement should point to the selection > mechanisms. > > Section 11.2.1, final paragraph: We should have text in here addressing > the fact that user agents that are not willing to receive non-ICE answers > need to include "Require: ice" in their offer; and that clients that reject > non-ICE offers should use the 421 response code to do so, and should > indicate "Require: ice" in their rejections. > > > > Editorial Comments (of varying severity) > > The final sentence of the definition of "Default Destination/Candidate" is > a bit difficult to follow. Suggest: ' For the RTCP component, the address > and port are indicated using the "a=rtcp" attribute defined in [RFC3605], > if present; otherwise, the RTCP component address is the same as the > address of the RTP component, and its port is one greater than the port of > the RTP component.' > > Section 3, final paragraph: remove "the" before "[ICE-BIS]". > > Section 4.1.3, second paragraph: eliminate the space before the first > comma. Place a comma between "its role" and "and processes" > > Section 4.1.3, final paragraph: replace "complaint" with "compliant". > > The contents of section 4.1.5 appear to be completely redundant with the > contents of section 4.1.5.1.1. I would recommend eliminating section 4.1.5. > Also, the section numbering here is really baroque and unnecessarily deep. > For example, section 4.1.5.1 contains no text and only one subsection; this > is also true of section 4.1.5.2. The more I look at this, the more bizarre > it appears. I think the correct thing to do here is: > (a) Remove all the text currently in section 4.1.5. > (b) Move the paragraph in section 4.1.5.1.1 and the two paragraphs in > 4.1.5.2.1 into section 4.1.5 > (c) Eliminate the (now empty) sections 4.1.5.1, 4.1.5.1.1, 4.1.5.2, and > 4.1.5.2.1. > > Section 4.2.1.2.1, second paragraph says "The agent MAY include additional > candidates it did not offer previously" before we explain how this can > happen. I recommend adding a "(see section 4.2.4.1.1)" after "previously". > > Section 4.2.2.3, final paragraph: The second line has an "i" that has been > separated from the rest of its word (which appears on the following line). > > Section 4.2.3: add commas: "being ICE-unaware, a subsequent" ... "this is > done, this could result" ... "ICE-unaware, that answer would not" > > Section 4.2.3.1.1 should not rely on the section header exclusively for > context here. The first sentence should read "If ICE support is indicated > int he SIP answer and the offer was a restart..." Ditto for sections > 4.2.3.1.3 (add "and ICE is running") and 4.2.3.1.3 ("and ICE is completed"). > > Section 5.1 indicates that ABNF is used for "candidate," but this is not > repeated for (e.g.) sections 5.3. and 5.4. I would suggest moving the > statement from 5.1 (and 5.2) into section 5 so that it applies to all > syntax definitions. > > In all of section 5, the attributes really should include examples. > > Also, section 5 should indicate which exernally-defined ABNF constructs > are being used in the document. This is done in some locations, but not > others. Running the ABNF through a validator will highlight all > externally-defined elements; it will also help uncover any other issues > with the ABNF. > > All attributes are defined with ABNF of the form: "attribute-name" ":" -- > this is unnecessary, and should be shortened to "attribute-name:". > > Section 5.1, under : change "using an A" to "using an > A record." > > Section 5.1, under refers to specification of TCP with ICE in > the future tense rather than the past. This should be reworked. > > Section 5.1, under , "...in the Frozen algorithm" should be > followed by "defined in" and then a citation for where the Frozen algorithm > is defined. > > Section 5.1, -- this just says it's an integer, without > describing its meaning. Either explain what it means, or cite something > that does so. > > Section 5.1, and : replace " and > is equal" with " and are equal". > > Section 5.2, in the ABNF for "remote-candidate", indicate that > component-ID is defined in RFC 4566. > > Section 5.4, final paragraph: this indicates that the grammar allows for > "6 bits of randomness per character" -- this should indicate that it allows > for "6 bits of information per character". > > Section 6: rewrite the first sentence using active voice so as to > positively identify which entities the requirements apply to. > > Section 7.1: "Note that" is an awkward way to start a section; I suggest > striking it. > > Section 7.1, first line: replace "may not" with "might not." I had to read > this several times to realize that the intended meaning here was "might > not." In colloquial usage, "may not" is a prohibition (e.g., "you may not > take more than two cookies.") > > Section 8.1, first paragraph refers to "ringing the phone of the called > party." Old-style telephones are only one use case for SIP; this should > instead read "alerting the called user agent." > > Section 8.1.1 second paragraph is HUGE. Consider how to split it up to be > less "wall of text"y. > > Section 8.1.1, fourth paragraph replace "each candidate" with "every > candidate." > > Section 8.1.1, final paragraph: "it's a localized decision" is extremely > informal and doesn't match the general style for RFCs. Please rephrase. > > Section 8.1.2, first paragraph describes a kind of difficult-to-follow > situation in which an INVITE contains an offer, and the answer is provided > in a PRACK response, resulting in an empty "200 OK." Two comments: (1) this > would really benefit from a sequence diagram; and (2) are SBCs and ALGs > likely to do the right thing with empty 200s? > > Section 8.1.2, second paragraph indicates that placing an offer in an > INVITE the 2xx can cause substantial PDD and clipping; this is true > regardless of whether ICE is in use. I think you mean to say that ICE can > exacerbate PDD and clipping in this case rather than causing it. > > Sections 8.4, 9, and 11.1 -- remove the redundant RFC numbers (as in > "defined in RFC 3312 [RFC3312]"). > > Section 10 refers to timer Ta without indicating where it is defined. > > Section 11.1: Replace "SIPS" with "TLS". As Olle is fond of noting, there > are circumstances in which TLS is feasible but SIPS is not, and specifying > "TLS" here is sufficient. > > Section 11.2: replace "stun" with "STUN." > > Section 11.2.1, final paragraph: replace "if its not used" with "if it's > not used." > > Section 11.2.2 -- expand the acronym "NAT" on first use. > > Section 11.2.2, first paragraph: replace "application layer SIP" with > "application-layer SIP" > > Section 12.1: Insert "The" at the very beginning of the first sentence. > > Section 12.2: Make "RFC 5245" a reference. > > Section 12.2, third paragraph should start "[RFC6679] defines the..." (add > the word "the") > > Section 13: make "RFC 5245" and "RFC 6336" references. > > > /a > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113e0ad2d2e9ae054a98d13e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Adam

=C2=A0 Many thanks for your = detailed review and apologies for the delayed response.=C2=A0
The authors discussed on your Big Picture questions and we need= help from the WG to decide on the next steps. I will be following this ema= il with separate emails on this topic reaching out for more information.

I have submitted version-12 that incorporates most o= f editorial and technical comments. Please let us know if there were any om= issions.

However, here are few comments that =C2= =A0need more inputs from you. I have included them below for ease of readab= ility.

Section 8.1.1, final paragraph: "it= 9;s a localized decision" is extremely informal and doesn't match = the general style for RFCs. Please rephrase.

[Suha= s] - Could you suggest a viable rephrase.

Section = 8.1.2, first paragraph describes a kind of difficult-to-follow situation in= which an INVITE contains an offer, and the answer is provided in a PRACK r= esponse, resulting in an empty "200 OK." Two comments: (1) this w= ould really benefit from a sequence diagram; and (2) are SBCs and ALGs like= ly to do the right thing with empty 200s?

[Suh= as] =C2=A0- On (2), I am not well versed with SBCs and ALGs behavior. Not s= ure, what is recommended that we do here. Any thoughts ?

Section 4.2.2.2.3 specifies, during offer processing, that the imple= mentation "SHOULD wait for [ICE] checks to complete" before sendi= ng an answer. Keeping in mind that these updates typically happen with the = SIP UPDATE method, and given that RFC 3261 specifies "TUs SHOULD respo= nd immediately to non-INVITE requests" (cf. RFC3261 section 17.1), I&#= 39;m concerned about the timing implications here. We should minimally poin= t out that we're explicitly telling UAs to ignore this normative statem= ent in RFC3261, and make sure that we've done the analysis to ensure th= at we're not going to cause problems for the SIP state machine (I'm= concerned, in particular, about unnecessary SIP retransmissions here).
=

[Suhas] - I am not aware of any analysis being do= ne. What do you suggest we need to do ?


=

Thanks
Suhas



On = Thu, Jan 12, 2017 at 2:46 PM, Adam Roach <adam@nostrum.com> w= rote:
I've done a = review of draft-ietf-mmusic-ice-sip-sdp-10, and have a handful of comm= ents. I've broken these down into three sections: big-picture questions= , technical comments, and editorial comments. I apologize for the lateness = in posting this review; the comments are substantial, and converting them i= nto email form took far longer than I anticipated.


Big Picture Questions

The text in section 9, read literally, deprecates RFCs 4091 and 4092. If th= at is the actual intention, the abstract and "obsoletes" metadata= need to be updated to reflect this fact. If the deprecation is qualified (= e.g., the RFCs are still okay in other contexts, but should not be used in = conjunction with ICE), then the text in section 9 needs to be much clearer.=

It's not clear to me what the relationship is between this document and= RFC 5245 (and, for that matter, 6544). Is this supposed to obsolete RFC 52= 45? That appears to be the intention. It's also not clear why we would = obsolete 5245 without also incorporating 6544 -- it seems that doing so lea= ves the use of ICE TCP with SIP to be kind of in limbo.

Assuming the intention *is* to replace RFC 5245, the structure of this docu= ment seems to leave non-SIP uses of RFC3264 (e.g., WebRTC) stranded. If the= intention is *not* to replace RFC 5245, the replication of all of the SDP = syntax seems to be problematic: the the case of a conflict, which specifica= tion is intended to govern?

In short, I think the relationship between this document, the contemporary = work (e.g., ICE-BIS), and the historical work on which it is based needs to= be made much clearer in the document itself, and we need to have a clear p= icture about how to handle SDP for non-SIP uses of ICE (e.g., by splitting = this document into an SDP part and a SIP part, similar to how we split 3264= from 3261).


Technical Comments

I believe that the RECOMMENDED-strength normative statement in the final pa= ragraph of 4.1.1.1 overstates things a bit. While this guidance makes set i= n certain circumstances. For example, for devices that are known to typical= ly known to be on a single network with mutual routability, using a relayed= candidate as a default will lead to calls being unnecessarily sent out of = network and back. I strongly suggest that this paragraph be reworked to be = a considered discussion of the different trade-offs involved in using each = kind of candidate, with a non-normative suggestion to make the behavior con= figurable in user agents. What I want to avoid here is guidance which leads= to devices behind a single ALG necessarily going through two relays by def= ault when talking to each other (which is what the current guidance can lea= d to -- I can sketch this out in more detail if it's not obvious how th= is happens).

Section 4.1.1.2 uses the word "media stream" in a way that's = not consistent with the way that term is defined by RFC 7656, which could l= ead to confusion. In RFC 7656 terminology, "media stream" is an a= lias for "RTP stream," which is identified by a single SSRC. With= technologies such as simulcast. A single m-line can contain multiple media= streams. I think you want the term "source stream," with a citat= ion of that term in RFC 7656.

Section 4.1.1.2 discusses ice-options attributes in the terms of "supp= ort", without any discussion of activation. Although this is treated (= somewhat lightly) later in the document, this smells like the same kind of = potential morass we ran into with SIP options tags: the patchwork means of = indicating feature *support* versus feature *activation* made it very diffi= cult to specify and implement things in a consistent fashion. I strongly re= commend that this document spend a bit more text discussing this distinctio= n, and maybe even consider a formal syntax for distinguishing between suppo= rted and activated features.

Section 4.1.3 should probably point out that, in the case of forking, the s= ame local candidates are used for all branches of the fork.

Section 4.2, section paragraph: replace "be rejected" with "= fail" -- there are more ways to fail than rejection, and the action sh= ould be the same for rejection as for other failures.

Section 4.2.1.2 should add motivation for the requirement imposed by its se= cond paragraph, or the requirement should be removed. The need to do this i= s not obvious, and I suspect it may be unnecessary.

Section 4.2.2.2.3 specifies, during offer processing, that the implementati= on "SHOULD wait for [ICE] checks to complete" before sending an a= nswer. Keeping in mind that these updates typically happen with the SIP UPD= ATE method, and given that RFC 3261 specifies "TUs SHOULD respond imme= diately to non-INVITE requests" (cf. RFC3261 section 17.1), I'm co= ncerned about the timing implications here. We should minimally point out t= hat we're explicitly telling UAs to ignore this normative statement in = RFC3261, and make sure that we've done the analysis to ensure that we&#= 39;re not going to cause problems for the SIP state machine (I'm concer= ned, in particular, about unnecessary SIP retransmissions here).

Section 4.2.4.1.4: the final paragraph seems to reiterate behavior describe= d in ICE-BIS. It's probably not ideal to describe this in two places, a= s any subtle difference can result in interop problems.

Given the state of ICE today, I think the definition of "candidate&quo= t; in section 5.1 should also include the syntax for TCP transports.

Section 5.1, <connection-address>: the language in here that states &= quot;If the DNS query returns more than on IP address, on is chosen," = implying that one is chosen at random. There are specific procedures for ho= w this is done (especially with IPv6); the statement should point to the se= lection mechanisms.

Section 11.2.1, final paragraph: We should have text in here addressing the= fact that user agents that are not willing to receive non-ICE answers need= to include "Require: ice" in their offer; and that clients that = reject non-ICE offers should use the 421 response code to do so, and should= indicate "Require: ice" in their rejections.



Editorial Comments (of varying severity)

The final sentence of the definition of "Default Destination/Candidate= " is a bit difficult to follow. Suggest: ' For the RTCP component,= the address and port are indicated using the "a=3Drtcp" attribut= e defined in [RFC3605], if present; otherwise, the RTCP component address i= s the same as the address of the RTP component, and its port is one greater= than the port of the RTP component.'

Section 3, final paragraph: remove "the" before "[ICE-BIS]&q= uot;.

Section 4.1.3, second paragraph: eliminate the space before the first comma= . Place a comma between "its role" and "and processes"<= br>
Section 4.1.3, final paragraph: replace "complaint" with "co= mpliant".

The contents of section 4.1.5 appear to be completely redundant with the co= ntents of section 4.1.5.1.1. I would recommend eliminating section 4.1.5. A= lso, the section numbering here is really baroque and unnecessarily deep. F= or example, section 4.1.5.1 contains no text and only one subsection; this = is also true of section 4.1.5.2. The more I look at this, the more bizarre = it appears. I think the correct thing to do here is:
(a) Remove all the text currently in section 4.1.5.
(b) Move the paragraph in section 4.1.5.1.1 and the two paragraphs in 4.1.5= .2.1 into section 4.1.5
(c) Eliminate the (now empty) sections 4.1.5.1, 4.1.5.1.1, 4.1.5.2, and 4.1= .5.2.1.

Section 4.2.1.2.1, second paragraph says "The agent MAY include additi= onal candidates it did not offer previously" before we explain how thi= s can happen. I recommend adding a "(see section 4.2.4.1.1)" afte= r "previously".

Section 4.2.2.3, final paragraph: The second line has an "i" that= has been separated from the rest of its word (which appears on the followi= ng line).

Section 4.2.3: add commas: "being ICE-unaware, a subsequent" ... = "this is done, this could result" ... "ICE-unaware, that ans= wer would not"

Section 4.2.3.1.1 should not rely on the section header exclusively for con= text here. The first sentence should read "If ICE support is indicated= int he SIP answer and the offer was a restart..." Ditto for sections = 4.2.3.1.3 (add "and ICE is running") and 4.2.3.1.3 ("and ICE= is completed").

Section 5.1 indicates that ABNF is used for "candidate," but this= is not repeated for (e.g.) sections 5.3. and 5.4. I would suggest moving t= he statement from 5.1 (and 5.2) into section 5 so that it applies to all sy= ntax definitions.

In all of section 5, the attributes really should include examples.

Also, section 5 should indicate which exernally-defined ABNF constructs are= being used in the document. This is done in some locations, but not others= . Running the ABNF through a validator will highlight all externally-define= d elements; it will also help uncover any other issues with the ABNF.

All attributes are defined with ABNF of the form: "attribute-name"= ; ":" -- this is unnecessary, and should be shortened to "at= tribute-name:".

Section 5.1, under <connection-address>: change "using an A"= ; to "using an A record."

Section 5.1, under <transport> refers to specification of TCP with IC= E in the future tense rather than the past. This should be reworked.

Section 5.1, under <foundation>, "...in the Frozen algorithm&quo= t; should be followed by "defined in" and then a citation for whe= re the Frozen algorithm is defined.

Section 5.1, <priority> -- this just says it's an integer, withou= t describing its meaning. Either explain what it means, or cite something t= hat does so.

Section 5.1, <rel-addr> and <rel-port>: replace "<rel-a= ddr> and <rel-port> is equal" with "<rel-addr> and= <rel-port> are equal".

Section 5.2, in the ABNF for "remote-candidate", indicate that co= mponent-ID is defined in RFC 4566.

Section 5.4, final paragraph: this indicates that the grammar allows for &q= uot;6 bits of randomness per character" -- this should indicate that i= t allows for "6 bits of information per character".

Section 6: rewrite the first sentence using active voice so as to positivel= y identify which entities the requirements apply to.

Section 7.1: "Note that" is an awkward way to start a section; I = suggest striking it.

Section 7.1, first line: replace "may not" with "might not.&= quot; I had to read this several times to realize that the intended meaning= here was "might not." In colloquial usage, "may not" i= s a prohibition (e.g., "you may not take more than two cookies.")=

Section 8.1, first paragraph refers to "ringing the phone of the calle= d party." Old-style telephones are only one use case for SIP; this sho= uld instead read "alerting the called user agent."

Section 8.1.1 second paragraph is HUGE. Consider how to split it up to be l= ess "wall of text"y.

Section 8.1.1, fourth paragraph replace "each candidate" with &qu= ot;every candidate."

Section 8.1.1, final paragraph: "it's a localized decision" i= s extremely informal and doesn't match the general style for RFCs. Plea= se rephrase.

Section 8.1.2, first paragraph describes a kind of difficult-to-follow situ= ation in which an INVITE contains an offer, and the answer is provided in a= PRACK response, resulting in an empty "200 OK." Two comments: (1= ) this would really benefit from a sequence diagram; and (2) are SBCs and A= LGs likely to do the right thing with empty 200s?

Section 8.1.2, second paragraph indicates that placing an offer in an INVIT= E the 2xx can cause substantial PDD and clipping; this is true regardless o= f whether ICE is in use. I think you mean to say that ICE can exacerbate PD= D and clipping in this case rather than causing it.

Sections 8.4, 9, and 11.1 -- remove the redundant RFC numbers (as in "= defined in RFC 3312 [RFC3312]").

Section 10 refers to timer Ta without indicating where it is defined.

Section 11.1: Replace "SIPS" with "TLS". As Olle is fon= d of noting, there are circumstances in which TLS is feasible but SIPS is n= ot, and specifying "TLS" here is sufficient.

Section 11.2: replace "stun" with "STUN."

Section 11.2.1, final paragraph: replace "if its not used" with &= quot;if it's not used."

Section 11.2.2 -- expand the acronym "NAT" on first use.

Section 11.2.2, first paragraph: replace "application layer SIP" = with "application-layer SIP"

Section 12.1: Insert "The" at the very beginning of the first sen= tence.

Section 12.2: Make "RFC 5245" a reference.

Section 12.2, third paragraph should start "[RFC6679] defines the...&q= uot; (add the word "the")

Section 13: make "RFC 5245" and "RFC 6336" references.<= br>

/a

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

--001a113e0ad2d2e9ae054a98d13e-- From nobody Mon Mar 13 01:53: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 5E2541294DB for ; Mon, 13 Mar 2017 01:53:30 -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 5_8QMSIexUO3 for ; Mon, 13 Mar 2017 01:53:29 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E51128AB0 for ; Mon, 13 Mar 2017 01:53:28 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id n21so26630543qta.1 for ; Mon, 13 Mar 2017 01:53:28 -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=6Yg+gNDOgj5tjbMy1Fto0YVff0nZdu23QrjfAd6BxZ8=; b=nSvEmy4WdDOekjcDdJHRylpV6Ck2e9MATRWEEW4tS8EKwGwo9YVQRFgcWv8O2ssASq fJjVbEZ3YphrVqT8s09EYRqFJhePRuzXGasooGMqNLm3/ybmJW/P7gvMAVtc0S8y0SNe QoZxgO9IOleFjWxysyj8tnZDXLbmns/s4aQB/obZ5eZ8dApqvKu8YuWUXwP9bmhHzvo3 B9XtwYwEmYxcOo+sAhIyIjv47LJdR9m/2sj/iFS94KWQIHJn2R0X8IEnLcj/vBgrcHCc gMwKm/saYmNqiGm7keFyqUn15atRiB0GSR4+aoV2/ZvKY5Zw4ETjh8gaue82KmC35LFn T+LA== 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=6Yg+gNDOgj5tjbMy1Fto0YVff0nZdu23QrjfAd6BxZ8=; b=pApMkj8Ui3usZGOd8Q0zYuEjP4E1cSGzOKtXegvYv5h30+58kMHLKASk4WFlVKO7RS kbAwu+dROWRdlfcnJSr2FGpjWrT1eE/usdzPZWmNrzt7tndgLA9rTHeb1hGklIXnfsWR gKvYJoz4nKW+pkKYKcLUwo6Oww2/u+5yMai8dc+64wcXWU2QP5fv3aTSAfgFVhE8w03p xl8/U7gsHGvo/ubB3DajrrVEoOTwbomX/FCcCDOiyz4R5nFJoQrCr6BqiLg+xEKqHiRz jNCk+UV8i9QbJdZP3PKJb/wV3BV+DgCAG4M+OqxIPUTZhDoIvARqrHg1aLtLuJdgEJZx gpiw== X-Gm-Message-State: AMke39mCO5zUrNNMnnw+O4uBelsZVYhGuIUcSW5yjaw+xVw+h0KCLMLXCbozMgNzs2pcs1A8kvRADAHY7sWcnQ== X-Received: by 10.200.57.71 with SMTP id t7mr29735480qtb.99.1489395208148; Mon, 13 Mar 2017 01:53:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Mon, 13 Mar 2017 01:53:27 -0700 (PDT) From: Suhas Nandakumar Date: Mon, 13 Mar 2017 01:53:27 -0700 Message-ID: To: Adam Roach , mmusic WG Content-Type: multipart/alternative; boundary=001a113eddc24fe3af054a98d8f0 Archived-At: Subject: [MMUSIC] ICE-SIP-SDP and RFC6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 08:53:30 -0000 --001a113eddc24fe3af054a98d8f0 Content-Type: text/plain; charset=UTF-8 Adam raised a valid point on the scope of RFC6544 in the context of ice-sip-sdp. We the authors did consider couple of options and would like the WG's inputs to decide the next steps 1. Merge in RFC6544 into ice-sip-sdp and ice-bis This includes bringing in appropriate text from rfc6544 into ice-bis for ice processing detail and ice-sip-sdp for candidate encoding + offer/answer specifics 2. RFC6544bis Do a bis version of RFC6544 and make it refer to ICE-BIS and ICE-SIP-SDP wherever appropriate. 3. Any other option ? We prefer option 2 given the magnitude of RFC6544 merge plan , but are open to suggestions from either or a new option altogether please advise. Cheers Suhas --001a113eddc24fe3af054a98d8f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adam raised a valid point on the scope of RFC6544 in = the context of ice-sip-sdp.

We the authors did con= sider couple of options and would like the WG's inputs to decide the ne= xt steps

1. Merge in RFC6544 into ice-sip-sdp and = ice-bis
=C2=A0 =C2=A0This includes bringing in appropriate text f= rom rfc6544 into ice-bis for ice processing detail and ice-sip-sdp for cand= idate encoding + offer/answer specifics

2. RFC6544= bis
=C2=A0 =C2=A0Do a bis version of RFC6544 and make it refer to= ICE-BIS and ICE-SIP-SDP wherever appropriate.

3. = Any other option ?

We prefer option 2 given the ma= gnitude of RFC6544 merge plan , but are open to suggestions from either or = a new option altogether

please advise.
<= br>

Cheers
Suhas

--001a113eddc24fe3af054a98d8f0-- From nobody Mon Mar 13 01:55: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 538BC1294DB for ; Mon, 13 Mar 2017 01:55:06 -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 aJd4r3EkW4TY for ; Mon, 13 Mar 2017 01:55:05 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 242E9128AB0 for ; Mon, 13 Mar 2017 01:55:04 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id x35so26613219qtc.2 for ; Mon, 13 Mar 2017 01:55:04 -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=oD5dDhddcwWltOCtD3phYPLWc2FYUXm8LcijptEFxVs=; b=PK/x8OSBgy/CsaO6Mjr47hYVhX82NrO82bQ96L7S6wquN+SKxmfD74v3CShxpW2TRf n71abjWCnkJWbMeY0xinrUIw/UdkV5jwEJ97xWtqIdKAjabXvSJi2/aiTmZuYauzBL/m w4tasoKEAUOs5SwSXKuUEWXXwjv7RmCqZ9AuPbJPD3D7hFMax7vqaiOPoLhP0alaoCsM bjPcIbJpmnEedahhwUNNouRxfiNjcsOQ8jUQM9E2U0hFFf3F9mM2xWFj+zXt9W1CHRE1 yx0BrOocjaShp+/RdSqlpcn4OzawENwZS3Y05gtOMEXx/kfT0BNLP6sNYzqyTSqFCS81 8n9A== 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=oD5dDhddcwWltOCtD3phYPLWc2FYUXm8LcijptEFxVs=; b=bxGOc34M2wTift24c1PNMlo1utuQyblmnRmJsYfO3RuFlXw5tam9YgkRju2igeE0HF MmCYSZS5CsczRF3iRrL25vY5mOytuwDp5vkuHIZNhE1hJfkvBI1p/bqnmcyVfYblISWD Aw8KHQXbXvRLowToKzc7DwkRiR0whSRFqOEAwK7oBwxGMc37+qNLMr7hEXWkqbXrKash 41ZXAJx3RioYNCQJY4rMUpm+SkRpD4VlLjwsxvB7Ih51kbfowpW8Som9BtJ2jJGuvfZS X1M8PxIsdQ+E5iZXDzoLLJ/12qBRhpZMd/WnXHhVqr1ffjdywcE7VpTI3mVjru3yg3pB h1OA== X-Gm-Message-State: AMke39mXtRg+GpIEcrbsThSrRRi9spSjS2H0oC4JsgIXAUfvS0sPScfZJUQKSecvRypG1hcyQx5QBeh2DYX/ig== X-Received: by 10.237.42.1 with SMTP id c1mr31270993qtd.219.1489395304156; Mon, 13 Mar 2017 01:55:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Mon, 13 Mar 2017 01:55:03 -0700 (PDT) From: Suhas Nandakumar Date: Mon, 13 Mar 2017 01:55:03 -0700 Message-ID: To: mmusic WG , Adam Roach Content-Type: multipart/alternative; boundary=001a113e0ad208e3c6054a98dec6 Archived-At: Subject: [MMUSIC] ICE-SDP for SIP/WEBRTC signaling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 08:55:06 -0000 --001a113e0ad208e3c6054a98dec6 Content-Type: text/plain; charset=UTF-8 One of the major points Adam raised was dealing with non-Sip signaling (such as WeRTC) in ICE-SIP-SDP draft which focus on SIP signaling alone. Since SDP applies for both SIP and WebRTC use cases, there are couple of options to slice this cake: 1. Add a section in the current draft for "WebRTC Usage". But I am not sure what to say here though? 2. Split ICE-SIP-SDP draft into ICE-SDP, ICE-SIP drafts and in future have ICE-WEBRTC draft to define WebRTC specific details. This will leave the ICE-SDP draft to focus on SDP and ICE interactions alone. Any thoughts ? Cheers Suhas --001a113e0ad208e3c6054a98dec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One of the major points Adam raised was dealing with non-S= ip signaling (such as WeRTC) in ICE-SIP-SDP draft which focus on SIP signal= ing alone.=C2=A0

Since SDP applies for both SIP and= WebRTC use cases, there are couple of options to slice this cake:

1. Add a section in the current draft for "WebRTC Usa= ge". But I am not sure what to say here though?


2. Split ICE-SIP-SDP draft into ICE-SDP, ICE-SIP drafts a= nd in future have ICE-WEBRTC draft to define WebRTC specific details. This = will leave the ICE-SDP draft to focus on SDP and ICE interactions alone.


Any thoughts ?

Cheers
Suhas

--001a113e0ad208e3c6054a98dec6-- From nobody Mon Mar 13 01:55: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 6EB5D12955C for ; Mon, 13 Mar 2017 01:55:36 -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 ShUngjruuloF for ; Mon, 13 Mar 2017 01:55:35 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 B3133127ABE for ; Mon, 13 Mar 2017 01:55:34 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id v125so212944193qkh.2 for ; Mon, 13 Mar 2017 01:55:34 -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=Rsxz1BdjQRRBiuRseA77FR8bv+ncmPfEt7Zb8mOYGGU=; b=buOOOWtoOO4b0kL3np8RGxnH0yHMIyOnPVg6JVeheM520RinUO1aI+Sy64vT2sHhhp JYa99TN7OBmsy+NCBOTeNvs+9nbM01aHTl/DuRPyE0O+i7hqjc19uJVzVHLRKZca5urb WkQYmGxTt9sGLDVz1Ev5RTJKIDFytYKtjukgYRLsY0vMZRbOiEftIMp/accgr54e2wNB 8PpXIxV+2qON0x+aVaUr1eERNWGVKvphFeXPVPuGxP/7AGeFHn79vCprzDRRAGq+v27e D6/DKgpfBWDhyxoh3EStdTsQhqTNaJs4+fzlns8P02yFhj6fVZD/or+E+TiQIMKkATTp JE7w== 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=Rsxz1BdjQRRBiuRseA77FR8bv+ncmPfEt7Zb8mOYGGU=; b=JiUlS6MJmU7PHB2QZzGkFsldQu9+VyKHZ46VVL5aoJ+08XyNdc43qMlhm1r7bCbxFL NQmeeexBH8uq/WmRJDM488Fz2+cSOcfVuelTh399D2DQqXmaB39Zz9upLdDUm6w+nkO4 kYhcgcrYOTouF8PS/Cjz8grGCslvx1CIhE5jUh/1F6AcFNkNTGpYgW5dtHHOy6sEs37d 6+FBIicORiHxWfLwYc8mUpKqD0wkvsQvRfBI39JVNgjQwpjrKMqBYCTLB8iyw/VW4dPZ pun6z8lKH7oxKvPrFRDXrgt5lCQOisbqMs11qpeKv5b4rSYb+Tny0rAcfrHEs6Qn4Bha qVrA== X-Gm-Message-State: AFeK/H3HKRpmKqJgZiT+em/BEBi7Kqwns6z87wJ2yGMb6/mWj2jBMqjnb4AKPCetwFfFXcEUCktBedF3uW2cgQ== X-Received: by 10.55.19.197 with SMTP id 66mr28944413qkt.73.1489395333638; Mon, 13 Mar 2017 01:55:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Mon, 13 Mar 2017 01:55:33 -0700 (PDT) From: Suhas Nandakumar Date: Mon, 13 Mar 2017 01:55:33 -0700 Message-ID: To: mmusic WG , Adam Roach Content-Type: multipart/alternative; boundary=001a113fcf6ccab1fb054a98dffe Archived-At: Subject: [MMUSIC] ICE-SIP-SDP : ice-options support vs activation framework X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 08:55:37 -0000 --001a113fcf6ccab1fb054a98dffe Content-Type: text/plain; charset=UTF-8 Original Comment from Adam "Section 4.1.1.2 discusses ice-options attributes in the terms of "support", without any discussion of activation. Although this is treated (somewhat lightly) later in the document, this smells like the same kind of potential morass we ran into with SIP options tags: the patchwork means of indicating feature *support* versus feature *activation* made it very difficult to specify and implement things in a consistent fashion. I strongly recommend that this document spend a bit more text discussing this distinction, and maybe even consider a formal syntax for distinguishing between supported and activated features" [Suhas] I am not sure how deep we need to go in defining a formal syntax. Would love to get some text to accommodate the above request or thoughts on how do we go about ... Thanks Suhas --001a113fcf6ccab1fb054a98dffe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Original Comment from Adam

&= quot;Section 4.1.1.2 discusses ice-options attributes in the terms of "= ;support", without any discussion of activation. Although this is trea= ted (somewhat lightly) later in the document, this smells like the same kin= d of potential morass we ran into with SIP options tags: the patchwork mean= s of indicating feature *support* versus feature *activation* made it very = difficult to specify and implement things in a consistent fashion. I strong= ly recommend that this document spend a bit more text discussing this disti= nction, and maybe even consider a formal syntax for distinguishing between = supported and activated features"

[Suhas]
I am not sure how deep we need to go in defining a formal syntax. Wo= uld love to get some text to accommodate the above request or thoughts on h= ow do we go about ...

Thanks
Suhas
=
--001a113fcf6ccab1fb054a98dffe-- From nobody Mon Mar 13 01:56:55 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 3FB2E12953D for ; Mon, 13 Mar 2017 01:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 f9TomlIZoLBt for ; Mon, 13 Mar 2017 01:56:51 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 44B48127ABE for ; Mon, 13 Mar 2017 01:56:51 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id y76so217367190qkb.0 for ; Mon, 13 Mar 2017 01:56:51 -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=sXKwLb7NCbAaV71u+KeylR7s6lYqulqGFz26D83Kh2A=; b=HeeWVBdudnvMDp2Vmf+iAvgdrRWePb+IdT5odtcFCan8lnKIJlqNb1M0TJ9Ixysulh xUYo6glYEqe58RMXzigMk8qNDhKVC4oldcoLf4bYQq/cEb1zlpswzfCwpBZbACIYv86l LrdVkCoXalES0wH18ZEoCoGOgUR2d1vPBCk++GHcIU8U2RLriPsKxl51voWLYI1nS4f8 dO2gyrd9vhfv5cFoI0V2UIhfh2MSPH0/QG1Pk0RaNwJkIyR6jYtDVCwTQ9EKRsINPH5v 7VyNbjvk+k2ZxOurznSXQf8DirrSYtXR0/C3/5TlHwnqX3hFQ8qXupynbmj5ZKHjgkuD lKvg== 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=sXKwLb7NCbAaV71u+KeylR7s6lYqulqGFz26D83Kh2A=; b=AGuXNNFpPXAWe4Nf+Xuq7/RyUpXdG35v+p4VgS5hZ1sBYXDJEMyoRPq0B6yg9zVbjY BdUa/qlGQ0EbDRx/mGWmXSKGTssz6EW/S/BpqdLYR4FiumGgAVORBakYyiUuFnP9fN38 EZdwg4N0g+/vSV5vydNoUBGnfNAXbd6U9MS7k5tq7HD13jY+Rdv4mJ4H7NxyiGrYXoIs 3q2KVqupb1o9zDLl8P478bxSKCuhOyLmmKviZHAASaSHnNUah3H0IkCi2nPI3Uz9Qj57 8Ku4P1I69GgBmAFwicoQ9/dN68VWFTJONPCAuIUq2r4mT3Vx48FBynVkpB+W+cm7+XJQ UTYA== X-Gm-Message-State: AFeK/H1swu2X2BLt0CiHwTR3btS12vYWwBah5MIR7bv3+0xv94w2sQQ4le6IkLgXckZXhUU42coL1RgbpIYJFw== X-Received: by 10.55.18.144 with SMTP id 16mr31220066qks.5.1489395410312; Mon, 13 Mar 2017 01:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Mon, 13 Mar 2017 01:56:49 -0700 (PDT) In-Reply-To: <148939488127.16827.6722127323469391602@ietfa.amsl.com> References: <148939488127.16827.6722127323469391602@ietfa.amsl.com> From: Suhas Nandakumar Date: Mon, 13 Mar 2017 01:56:49 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a113ad64a5ca739054a98e46f Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 08:56:53 -0000 --001a113ad64a5ca739054a98e46f Content-Type: text/plain; charset=UTF-8 Version-12 address most of the review comments from Adam. For the questions that needs more attention from the WG, I have sent individual issues as emails Cheers Suhas On Mon, Mar 13, 2017 at 1:48 AM, 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 of > the IETF. > > Title : Using Interactive Connectivity Establishment > (ICE) with Session Description Protocol (SDP) offer/answer and Session > Initiation Protocol (SIP) > Authors : Marc Petit-Huguenin > Ari Keranen > Suhas Nandakumar > Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt > Pages : 43 > Date : 2017-03-13 > > Abstract: > This document describes how Interactive Connectivity Establishment > (ICE) is used with Session Description Protocol (SDP) offer/answer > and Session Initiation Protocol (SIP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-12 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113ad64a5ca739054a98e46f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Version-12 address most of the review comments from Adam. = For the questions that needs more attention from the WG, I have sent indivi= dual issues as emails

Cheers
Suhas
=

On Mon, Mar 13, 2= 017 at 1:48 AM, <internet-drafts@ietf.org> wrote:

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 of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-13

Abstract:
=C2=A0 =C2=A0This document describes how Interactive Connectivity Establish= ment
=C2=A0 =C2=A0(ICE) is used with Session Description Protocol (SDP) offer/an= swer
=C2=A0 =C2=A0and Session Initiation Protocol (SIP).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-12

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


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/

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

--001a113ad64a5ca739054a98e46f-- From nobody Mon Mar 13 02:08: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 599CC1294F7 for ; Mon, 13 Mar 2017 02:08:04 -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 Qc3NC258pwuK for ; Mon, 13 Mar 2017 02:08:02 -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 5E3CB129400 for ; Mon, 13 Mar 2017 02:08:01 -0700 (PDT) X-AuditID: c1b4fb30-f83fb70000006a1c-5b-58c6616e94d0 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 81.C2.27164.E6166C85; Mon, 13 Mar 2017 10:07:59 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Mon, 13 Mar 2017 10:06:59 +0100 From: Christer Holmberg To: Suhas Nandakumar , mmusic WG Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt Thread-Index: AQHSm9aIInxQrzT8TEGdqpSnF8KmuaGSZw+AgAAlKAA= Date: Mon, 13 Mar 2017 09:06:58 +0000 Message-ID: References: <148939488127.16827.6722127323469391602@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.1.161129 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D4EC2E15194D3christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7vW5+4rEIgwfLxCymLn/MYrFzbgez A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUx99Y39oJTjhWPNtxmbWDcbNHFyMkhIWAi se91E2sXIxeHkMA6RoltH98yQziLGSUWndrF0sXIwcEmYCHR/U8bpEFEwF1i3/XPrCC2sICb xMqJa9lh4i82tbNA2FYSHzduYAOxWQRUJbonvGMEsXkFrCXOnJvKBjG/i1Hi7crHYEWcAoES S888AhvKKCAm8f3UGiYQm1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4H1i9qICexPLna5hB7pQQ UJRY3i8H0Zog8WL3ZRaIvYISJ2c+YZnAKDILydRZSMpmISmDiBtIvD83nxnC1pZYtvA1lK0v sfHLWUYI21riZcMBVmQ1Cxg5VjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIExtvBLb8NdjC+ fO54iFGAg1GJh3fDrKMRQqyJZcWVuYcYJTiYlUR4XaOPRQjxpiRWVqUW5ccXleakFh9ilOZg URLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAWPTm7gIr7gcqbz6JRqxYstv4faxoWMMyLylj 7ZkVm61YpY17s6afCTL7bfS/8oHKqvOeGpLHvr1cqPLknarPmutLGYv/14soVvo+tpoQejv8 6Lp17Q3RqlsKfkv0fTI6+NpO7ZqAoSvPtC1v5/ZaRZ6Nzj32ob116oWYpb25Pq+7rk49kXDC S4mlOCPRUIu5qDgRAFZNNuezAgAA Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 09:08:04 -0000 --_000_D4EC2E15194D3christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Note that some decisions/actions also came out of Seoul. https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00 Regarding the =92Transport Switch and O/A=92 issue, I guess we can use more= or less the same text (authored by Roman) that was added to draft-ietf-mmu= sic-sctp-sdp. Regards, Christer From: mmusic > on b= ehalf of Suhas Nandakumar > Date: Monday 13 March 2017 at 10:56 To: "mmusic@ietf.org" > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt Version-12 address most of the review comments from Adam. For the questions= that needs more attention from the WG, I have sent individual issues as em= ails Cheers Suhas On Mon, Mar 13, 2017 at 1:48 AM, > wrote: 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 of t= he IETF. Title : Using Interactive Connectivity Establishment (ICE= ) with Session Description Protocol (SDP) offer/answer and Session Initiati= on Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt Pages : 43 Date : 2017-03-13 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-12 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/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D4EC2E15194D3christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Note that some decisions/actions also came out of Seoul.


Regarding the =92Transport Switch and O/A=92 issue, I guess we can use= more or less the same text (authored by Roman) that was added to draft-iet= f-mmusic-sctp-sdp.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Suhas= Nandakumar <suhasietf@gmail.com<= /a>>
Date: Monday 13 March 2017 at 10:56=
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: d= raft-ietf-mmusic-ice-sip-sdp-12.txt

Version-12 address most of the review comments from Adam. = For the questions that needs more attention from the WG, I have sent indivi= dual issues as emails

Cheers
Suhas

On Mon, Mar 13, 2017 at 1:48 AM, <intern= et-drafts@ietf.org> wrote:

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 of t= he IETF.

        Title           := Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
        Authors         : Marc= Petit-Huguenin
                     = ;     Ari Keranen
                     = ;     Suhas Nandakumar
        Filename        : draft-iet= f-mmusic-ice-sip-sdp-12.txt
        Pages           := 43
        Date            := 2017-03-13

Abstract:
   This document describes how Interactive Connectivity Establish= ment
   (ICE) is used with Session Description Protocol (SDP) offer/an= swer
   and Session Initiation Protocol (SIP).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-12

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


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/

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

--_000_D4EC2E15194D3christerholmbergericssoncom_-- From nobody Mon Mar 13 02:15:06 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 3F78B12956B for ; Mon, 13 Mar 2017 02:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 XoZOaGuXh21v for ; Mon, 13 Mar 2017 02:15:02 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8E5129400 for ; Mon, 13 Mar 2017 02:15:01 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id y76so217631712qkb.0 for ; Mon, 13 Mar 2017 02:15:01 -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=0VPtYcu0J5s0Va3f0K8t/GkRncSgPqxITUKYW6UIS+E=; b=YDpyWe/MmL+lvfWJ236wGXeJ9av9qoxRtp56QqDXEn3N1uaqbfEx+Odb/55AgT9wGh F/BQusyhcuaKMBz/GrqAQ71zWUBu3K4jNFLThTymbeoWxNvRNJ6mg8Kcxx+Ye5thBiH0 3Y2MQnfgEoVcOi9lWz/6M5vmqEOyamRl1kgmjUcwrbV9k2yxEp1+Klqh1MpWMJIjkpS+ H032KsT3RUQTutpOYF97/eVhT5/jI+WLZ8gMjU2FyNkq9srbdYHVvgZ2D5lraFZtfSW+ mVGdL8koHKmHZnLGAwwBwMgyNHYmTwbPNvAaJWYzQHPCSjJg8tN9nnWorJWCleaJykUt XZDw== 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=0VPtYcu0J5s0Va3f0K8t/GkRncSgPqxITUKYW6UIS+E=; b=jMJy5OJihsfVRhdrEz1xdz6YFwLDLWr2pBkmyIr+68wkLbY1iNJskVAbtNdk0QSWet V4b8x6sCH9Oca2oXWO8scEPbY7TN8YVvIxGfIGgxCTHurwZfxVDI49y3GBxHAYMmMGZz gYtLGHXGhQbzpSDO2JmoH9Tste1LT+e1q29jr9Lvnezi+uPzmYJgRnzU41Y6+Kx+dJZe olwI9s4B5Y563AgxsKybgIq48xJhlTgVC0QdzvF/j1e9FuOvBXcfpZjIGc9g4iu5Pgou u911yuSBSqo76jP4GsfcClYExpbirl2at6y9fVJwgYNGSVEmzBoQlNsLVmZOSsjTqF6o dNAg== X-Gm-Message-State: AFeK/H07xu6xycBXTlTDASHLLsWcyQHnNdWgfPkat8EFk3yaxSctILQ6bUVm/luJ/Z/pXCin5pSGNAoCPZ5zdg== X-Received: by 10.55.23.31 with SMTP id i31mr32503768qkh.139.1489396500926; Mon, 13 Mar 2017 02:15:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Mon, 13 Mar 2017 02:15:00 -0700 (PDT) In-Reply-To: References: <148939488127.16827.6722127323469391602@ietfa.amsl.com> From: Suhas Nandakumar Date: Mon, 13 Mar 2017 02:15:00 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1147123e5e183e054a9925ee Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 09:15:04 -0000 --001a1147123e5e183e054a9925ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Christer. Are you referring to use text from this section: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-23#section-12.2 Thanks Suhas On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Note that some decisions/actions also came out of Seoul. > > https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00 > > Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I guess w= e can use more or > less the same text (authored by Roman) that was added to > draft-ietf-mmusic-sctp-sdp. > > Regards, > > Christer > > From: mmusic on behalf of Suhas Nandakumar < > suhasietf@gmail.com> > Date: Monday 13 March 2017 at 10:56 > To: "mmusic@ietf.org" > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt > > Version-12 address most of the review comments from Adam. For the > questions that needs more attention from the WG, I have sent individual > issues as emails > > Cheers > Suhas > > On Mon, Mar 13, 2017 at 1:48 AM, 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 o= f >> the IETF. >> >> Title : Using Interactive Connectivity Establishment >> (ICE) with Session Description Protocol (SDP) offer/answer and Session >> Initiation Protocol (SIP) >> Authors : Marc Petit-Huguenin >> Ari Keranen >> Suhas Nandakumar >> Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt >> Pages : 43 >> Date : 2017-03-13 >> >> Abstract: >> This document describes how Interactive Connectivity Establishment >> (ICE) is used with Session Description Protocol (SDP) offer/answer >> and Session Initiation Protocol (SIP). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-12 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > --001a1147123e5e183e054a9925ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Christer. Are you referring to use text from this s= ection:=C2=A0https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp= -23#section-12.2

Thanks
Suhas
<= div class=3D"gmail_extra">
On Mon, Mar 13, 20= 17 at 2:06 AM, Christer Holmberg <christer.holmberg@ericsson.= com> wrote:
Hi,

Note that some decisions/actions also came out of Seoul.


Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I gues= s we can use more or less the same text (authored by Roman) that was added = to draft-ietf-mmusic-sctp-sdp.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Monday 13 March 2017 at 10:56=
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: d= raft-ietf-mmusic-ice-sip-sdp-12.txt

Version-12 address most of the review comments from Adam. = For the questions that needs more attention from the WG, I have sent indivi= dual issues as emails

Cheers
Suhas

On Mon, Mar 13, 2017 at 1:48 AM, <intern= et-drafts@ietf.org> wrote:

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 of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-13

Abstract:
=C2=A0 =C2=A0This document describes how Interactive Connectivity Establish= ment
=C2=A0 =C2=A0(ICE) is used with Session Description Protocol (SDP) offer/an= swer
=C2=A0 =C2=A0and Session Initiation Protocol (SIP).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-12

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


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/

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


--001a1147123e5e183e054a9925ee-- From nobody Mon Mar 13 02:18: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 3F65512954F for ; Mon, 13 Mar 2017 02:18:03 -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 eUjdILStn7iX for ; Mon, 13 Mar 2017 02:18:01 -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 978C0129567 for ; Mon, 13 Mar 2017 02:17:54 -0700 (PDT) X-AuditID: c1b4fb3a-9b1d39800000539f-79-58c663c0b363 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 84.2B.21407.0C366C85; Mon, 13 Mar 2017 10:17:53 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Mon, 13 Mar 2017 10:17:52 +0100 From: Christer Holmberg To: Suhas Nandakumar Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt Thread-Index: AQHSm9aIInxQrzT8TEGdqpSnF8KmuaGSZw+AgAAlKAD//9/tAIAAIx4A Date: Mon, 13 Mar 2017 09:17:51 +0000 Message-ID: References: <148939488127.16827.6722127323469391602@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.1.161129 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D4EC30EF194DCchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7ru7B5GMRBs/vMVlMXf6YxWLn3A5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj/7257AXX/SqWf/rM1sDY4tLFyMkhIWAi 8XvbJ7YuRi4OIYF1jBIr+w8wgSSEBBYzSlxfm9DFyMHBJmAh0f1PGyQsIqAlsXrxXLASZgF5 iQtL1oDZwgJuEisnrmWHqHGXeLGpnQWkVQQofvhIFEiYRUBV4seerWwgYV4Ba4mt2wIhtjYz Sby5O58FpIZTIFBiz5SbjCA2o4CYxPdTa6BWiUvcejKfCeJkAYkle84zQ9iiEi8f/2MFsUUF 9CSWP18DFVeU+PhqHyNEb4LE9H/b2EBsXgFBiZMzn7BMYBSdhWTsLCRls5CUQcQNJN6fm88M YWtLLFv4GsrWl9j45SwjhG0tMe3yZzZkNQsYOVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxi BMbgwS2/rXYwHnzueIhRgINRiYd3w6yjEUKsiWXFlbmHGCU4mJVEeGcmHosQ4k1JrKxKLcqP LyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1OqgXF96IMZ3k+Uf0klnM+wafQ9 snrducvL3Lr767Kfnpq2M/n0mfQTsUpWt38f1Grfc+Vd4M3LnXptij/bz56RLn26p5ddvfao RnHv02fXzsWalvIXmPqZfpg8q/Je29e9+78fkwh6z3PaZ3PC9dU6zio+5d8jZudzbWqqZ2Dz 0+6sXVPmHrkv00+JpTgj0VCLuag4EQAIaENSvQIAAA== Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 09:18:03 -0000 --_000_D4EC30EF194DCchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >Thanks Christer. Are you referring to use text from this section: https://= tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-23#section-12.2 Wrong version =96 correct section :) Regards, Christer On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmberg > wrote: Hi, Note that some decisions/actions also came out of Seoul. https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00 Regarding the =92Transport Switch and O/A=92 issue, I guess we can use more= or less the same text (authored by Roman) that was added to draft-ietf-mmu= sic-sctp-sdp. Regards, Christer From: mmusic > on b= ehalf of Suhas Nandakumar > Date: Monday 13 March 2017 at 10:56 To: "mmusic@ietf.org" > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt Version-12 address most of the review comments from Adam. For the questions= that needs more attention from the WG, I have sent individual issues as em= ails Cheers Suhas On Mon, Mar 13, 2017 at 1:48 AM, > wrote: 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 of t= he IETF. Title : Using Interactive Connectivity Establishment (ICE= ) with Session Description Protocol (SDP) offer/answer and Session Initiati= on Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt Pages : 43 Date : 2017-03-13 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-12 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/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D4EC30EF194DCchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>Thanks Christer. Are you referring to use text from th= is section: https://tools.ietf.org/html/draft-ietf-mmusic-sctp= -sdp-23#section-12.2

Wrong version =96 correct section :)

Regards,

Christer


On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Note that some decisions/actions also came out of Seoul.


Regarding the =92Transport Switch and O/A=92 issue, I guess we can use= more or less the same text (authored by Roman) that was added to draft-iet= f-mmusic-sctp-sdp.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Monday 13 March 2017 at 10:56=
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: d= raft-ietf-mmusic-ice-sip-sdp-12.txt

Version-12 address most of the review comments from Adam. = For the questions that needs more attention from the WG, I have sent indivi= dual issues as emails

Cheers
Suhas

On Mon, Mar 13, 2017 at 1:48 AM, <intern= et-drafts@ietf.org> wrote:

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 of t= he IETF.

        Title           := Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
        Authors         : Marc= Petit-Huguenin
                     = ;     Ari Keranen
                     = ;     Suhas Nandakumar
        Filename        : draft-iet= f-mmusic-ice-sip-sdp-12.txt
        Pages           := 43
        Date            := 2017-03-13

Abstract:
   This document describes how Interactive Connectivity Establish= ment
   (ICE) is used with Session Description Protocol (SDP) offer/an= swer
   and Session Initiation Protocol (SIP).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-12

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


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/

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


--_000_D4EC30EF194DCchristerholmbergericssoncom_-- From nobody Mon Mar 13 02:56: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 D4D4312954B; Mon, 13 Mar 2017 02:56:43 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 uicZnbLxQqIp; Mon, 13 Mar 2017 02:56: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 226D5129400; Mon, 13 Mar 2017 02:56:40 -0700 (PDT) X-AuditID: c1b4fb30-3623498000006a1c-93-58c66cd7547f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 53.05.27164.7DC66C85; Mon, 13 Mar 2017 10:56:39 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 10:56:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=e16f+CC6yx7f1hd1J/FtBqGya6GprIAeMxfgbWO3nxI=; b=LqdwLstrOnYPHKSjg0ZXTseRTEtlBTYsaITkVdQsWOL5o7WHl0yLMSjcqKTr2XI0nSwijFjmnM12rZp9qnzNCdh0GthLsVCJceRH1B821xXOjVnpJgN+PjyLw9tTXbSyFzYLsHKkB4GqAjzk3KO48dQAGKdrrjZ7BgJnT/mzotc= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2579.eurprd07.prod.outlook.com (10.173.92.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 09:56:37 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 09:56:37 +0000 From: Bo Burman To: "mmusic (mmusic@ietf.org)" , "Taylor Brandstetter (deadbeef@google.com)" Thread-Topic: [rtcweb] How to signal RTX SSRCs with simulcast Thread-Index: AQHSmSRXaXEak/rxUUuXLqrZPXzB4qGOeTSAgAADuwCAADM6gIAAAMcAgAAFxYCAA7fx4A== Date: Mon, 13 Mar 2017 09:56:36 +0000 Message-ID: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2579; 7:kWCp0l3S0lWRmQp5UqYKMpO8ifoZjfPlyWe2PQTO9hoOCM2D3xbzhApTKb+AAzRxUaRTlo/oBeDNzwr8w84qq8BT2UhORdlKYgVeV/aby84zP3/95Pyvonr3Yt2Y4l2ylqcoBpEo122EKbTR9vVb222v39fqZt063+coGb4YprrexJMfdBqHY0QN6rpmB1Wc7j+7CPUTLeYlCA1hlwM16IBiJ7Cq1dId0GX+UH4jd4GA1hgOgxh0FNoMYEBpeD5QHKO4/0qUHDYx9k9/4MvDXWbOVND8/grHMTRp3nJbCyNicqb0MWx6JXWf0Xp1N6jlbeT0U+PePFMwSShnR4Fp/g== x-ms-office365-filtering-correlation-id: c3613b36-61b3-4f19-5d1c-08d469f73d4d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2579; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:AM5PR0701MB2579; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2579; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(51444003)(377454003)(377424004)(24454002)(6116002)(790700001)(66066001)(3660700001)(3846002)(122556002)(3280700002)(102836003)(561944003)(33656002)(99936001)(189998001)(54356999)(5660300001)(50986999)(76176999)(2900100001)(9686003)(606005)(99286003)(6306002)(54896002)(236005)(106116001)(6436002)(25786008)(93886004)(2906002)(53936002)(2950100002)(7696004)(77096006)(6506006)(229853002)(74316002)(81166006)(8936002)(19609705001)(55016002)(4326008)(8676002)(86362001)(38730400002)(53546006)(7906003)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2579; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 09:56:37.0039 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2579 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0iTURjHOe9lvpqL09J8sIJchZaZNSxGaRT1wbCL9iFHFG3pmxNts81J hYRiZrkumpk6NUUHWprKMDbDRK20qZCmzS7elXRRlKFoKNV83xVB337n//zP/3nOhSFFeoE3 E6tKZDUqRbxY4EYVyMwRAf3xbbJtVsN6aW/lKC3Nrq0hpJOGKUqaWzFO7aVCS026UKPxBxFO nHALjmbjY5NYTeAeuZuyN/O1ICGtgrhw+3GnSwpKLSEykSsDOAie5VbRmciNEeEaBNW5zS78 4iWC8uIhcmlB4ZskWBusAr6SR0Bx+Qjx12YwztNLYQLsByWWQbTEHlgHH2yzXDCJSxHcaOvm CitxMJj7RkjeFAK/miwUz8chp2GGYwpvhJv55ZxHiOVgMX90tk4nYeZNNze6K44Ac/ZXLhTh VTDXUc3pJPaC9xN/jucBoz2dAp49wT7+k5sIYT2Cb/dtTtM6+KRP4ToAvkVCzpSe5guHob26 meL5KMxlpDuYcbAaCvPW8vIuuJbdTvN7HxAw19Pu9K+BMku6M7SeBtPDRef5vWGw77qT18DU wFM6C/kZ/pmc51h4dGUaGbgrWAHWggmK19WQYesUGBxzkHgT1D4J5GUfuKsfdeHZD9KLil3+ 1wPg+au2v/pVc5ojZul5KhF8mbURfGYoVDWq/t1bioQPkaeW1Z45FyORbGU1sVFarVq1VcUm mpDjW7bUL2yzIPvkvlaEGSR2F9YZXshEtCJJe/FcK9rgyBmrq+pG3pRKrWLFHsKGqDaZSBit uHiJ1ahPa3TxrLYVrWYosZdw54PhSBGOUSSycSybwGr+VAnG1TsFLS8Jb5ruar93bExubPhs 9y8MSlayA7S/tMN9MeZ8ztAw3ZXs23/5Sj+RzwaX78+6HmIM2HHkq5y+0zjm/m78eZE9JGzS 15R8aO5s2e6hjDidxGf8YGWQjF1nWGZbCBs+UNfZmNqS+l2pO+nZN6/s2GJhTJGnorzskrct 2YGSRTGlVSq2byY1WsVvgN+5Mp4DAAA= Archived-At: Cc: "draft-ietf-mmusic-rid@ietf.org" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Subject: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 09:56:44 -0000 --_004_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_ Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_" --_000_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpUaGlzIGlzIGZvcndhcmRpbmcgYSBkaXNjdXNzaW9uIHRoYXQgc3RhcnRlZCBpbiBS VENXRUIgdGhhdCBtYWlubHkgYXBwbGllcyB0byAtbW11c2ljLXJpZCBhbmQgLW1tdXNpYy1zZHAt c2ltdWxjYXN0LiBJIHN1Z2dlc3Qgd2UgY29udGludWUgdGhlIGRldGFpbGVkIGRpc2N1c3Npb24g aGVyZSBpbiBNTVVTSUMuDQoNCkFzIHRoZSBmb3J3YXJkZWQgbWFpbCBzYXlzLCBpdCBpcyBzdGls bCBzb21ld2hhdCB1bmNsZWFyIHdoYXQgcXVlc3Rpb24gdGhhdCBuZWVkcyBhbiBhbnN3ZXIsIGJ1 dCBpdCBpcyBjbGVhcmx5IHJlbGF0ZWQgdG8gam9pbnQgdXNlIG9mIOKAnGE9cmlk4oCdLCDigJxh PXNpbXVsY2FzdOKAnSwgYW5kIHVzZSBvZiByZXRyYW5zbWlzc2lvbiAo4oCccnR44oCdIGZvcm1h dCBmcm9tIFJGQyA0NTg4KS4gSSB0aGluayBzdWNoIHVzYWdlIG1heSBiZSBzbGlnaHRseSB1bmRl ci1zcGVjaWZpZWQgaW4gb25lIG9yIGJvdGggb2YgdGhlIGFib3ZlIGRyYWZ0cy4NCg0KSSB0aGlu ayB3aGF0IFRheWxvciBzdWdnZXN0cyBiZWxvdyBpcyBhIHZlcnkgZ29vZCBzdGFydCBhbmQgbWF5 IGFjdHVhbGx5IHByb3ZpZGUgdGhlIHNvbHV0aW9uIHdlIHdhbnQgKGFuZCBzaG91bGQgdGhlbiBk b2N1bWVudCBiZXR0ZXIpLg0KDQpJIGhvd2V2ZXIgbm90ZSB0aGF0Og0KDQrCtyAgICAgICAgIFJG QyA0NTg4IChzZWN0aW9uIDQpIHNheXMgdGhhdCBSVFAgSGVhZGVyIEV4dGVuc2lvbnMgKHN1Y2gg YXMgUnRwU3RyZWFtSWQsIHVzZWQgZm9yIOKAnGE9cmlk4oCdKSBTSE9VTEQgYmUgcmVwZWF0ZWQg YnkgdGhlIHJldHJhbnNtaXR0ZWQgcGFja2V0Og0KICAg4oCcSWYgdGhlIG9yaWdpbmFsIFJUUCBo ZWFkZXIgY2FycmllZCBhbiBSVFAgaGVhZGVyIGV4dGVuc2lvbiwgdGhlDQogICByZXRyYW5zbWlz c2lvbiBwYWNrZXQgU0hPVUxEIGNhcnJ5IHRoZSBzYW1lIGhlYWRlciBleHRlbnNpb24uICBUaGlz DQogICBoZWFkZXIgZXh0ZW5zaW9uIE1VU1QgYmUgcGxhY2VkIHJpZ2h0IGFmdGVyIHRoZSBmaXhl ZCBSVFAgaGVhZGVyLCBhcw0KICAgc3BlY2lmaWVkIGluIFJUUCBbM10uICBJbiB0aGlzIGNhc2Us IHRoZSByZXRyYW5zbWlzc2lvbiBwYXlsb2FkDQogICBoZWFkZXIgTVVTVCBiZSBwbGFjZWQgYWZ0 ZXIgdGhlIGhlYWRlciBleHRlbnNpb24u4oCdDQoNCsK3ICAgICAgICAgSXQgaXMgbm90IHNlbGYt ZXZpZGVudCB0aGF0IHRoZSByZXRyYW5zbWlzc2lvbiByZWR1bmRhbmN5IFJUUCBzdHJlYW0gKFJG QyA3NjU2KSBzaG91bGQgYmUgYXNzaWduZWQgdGhlIHNhbWUgUnRwU3RyZWFtSWQgYXMgdGhlIFJU UCBzdHJlYW0gaXQgcHJvdGVjdHMsIGVzcGVjaWFsbHkgc2luY2UgdGhhdCB3b3VsZCBwcmV2ZW50 IGFzc2lnbmluZyBhIHNlcGFyYXRlIFJ0cFN0cmVhbUlkIHRvIHRoZSByZWR1bmRhbmN5IFJUUCBz dHJlYW0gaXRzZWxmIChpZiB0aGF0IGlzIGV2ZXIgbmVlZGVkKQ0KDQrCtyAgICAgICAgIC1hdnRl eHQtcmlkIGFscmVhZHkgcHJvdmlkZXMgYSB3YXkgdG8gZGVhbCB3aXRoIHRoaXMgYnkgZGVmaW5p bmcgUmVwYWlyZWRSdHBTdHJlYW1JZCwgYnV0IC1tbXVzaWMtcmlkIGN1cnJlbnRseSBkb2VzIG5v dCBpbiBhbnkgd2F5IGRldGFpbCBpdHMgdXNhZ2UNCg0KSSBiZWxpZXZlIHdlIG5lZWQgdG8gZGVj aWRlIG9uIGFuZCBkb2N1bWVudDoNCg0KwrcgICAgICAgICBXaGV0aGVyIHRvIHVzZSBSdHBTdHJl YW1JZCBvciBSZXBhaXJlZFJ0cFN0cmVhbUlkIGluIHRoZSBydHggcmVkdW5kYW5jeSBSVFAgc3Ry ZWFtIHRvIGluZGljYXRlIHdoYXQgUnRwU3RyZWFtSWQgdGhlIG9yaWdpbmFsIFJUUCBzdHJlYW0g aGFzDQoNCsK3ICAgICAgICAgSWYgdXNpbmcgdGhlIHNhbWUgUnRwU3RyZWFtSWQgaW4gdGhlIHJ0 eCByZWR1bmRhbmN5IFJUUCBzdHJlYW0gYXMgaW4gdGhlIG9yaWdpbmFsIFJUUCBzdHJlYW0gKGJh c2ljYWxseSBUYXlsb3LigJlzIHByb3Bvc2FsKToNCg0KbyAgIFRoYXQgaXQgaXMgYWxpZ25lZCB3 aXRoIHRoZSBSRkMgNDU4OCByZWNvbW1lbmRhdGlvbiB0byBjb3B5IG9yaWdpbmFsIFJUUCBIRSAo dmVyYmF0aW0pIGludG8gcmV0cmFuc21pdHRlZCBwYWNrZXQNCg0KbyAgIFRoYXQg4oCcYT1yaWTi gJ0gc3BlY2lmaWVzIGJvdGggb3JpZ2luYWwgZm9ybWF0IGFuZCBydHggZm9ybWF0IGZvciB0aGUg 4oCccHQ94oCdIHBhcmFtZXRlciAoYXMgVGF5bG9yIHN1Z2dlc3RzIGJlbG93KQ0KDQpvICAgVGhh dCB0aGlzIGNsZWFybHkgaW5kaWNhdGVzIGluIFNEUCB3aGljaCDigJxhPXJpZOKAnSB1c2VzIHJl dHJhbnNtaXNzaW9uIChieSBwb2ludGluZyBhbHNvIHRvIGEgcnR4IFBUKQ0KDQpvICAgVGhhdCBp ZiB0aGUgcnR4IHJlZHVuZGFuY3kgUlRQIHN0cmVhbSBpdHNlbGYgbmVlZHMgYW4gUnRwU3RyZWFt SWQsIFJlcGFpcmVkUnRwU3RyZWFtSWQgaXMgaW5zdGVhZCB1c2VkIHRvIHJlbGF0ZSB0byB0aGUg b3JpZ2luYWwgUlRQIHN0cmVhbTsgSSBub3RlIHRoYXQgdGhlcmXigJlzIGEgcmlzayB0aGF0IGFu IGltcGxlbWVudGF0aW9uIHRoYXQgZG9lcyBub3Qga25vdyBvZiBSZXBhaXJlZFJ0cFN0cmVhbUlk IHdpbGwgdGhlbiBub3QgZmluZCB0aGUgcmVsYXRpb24gYmV0d2VlbiBvcmlnaW5hbCBhbmQgcnR4 IFJUUCBzdHJlYW0NCg0KwrcgICAgICAgICBJZiBhbHdheXMgdXNpbmcgUmVwYWlyZWRSdHBTdHJl YW1JZCBpbiB0aGUgcnR4IHJlZHVuZGFuY3kgUlRQIHN0cmVhbSB0byByZWxhdGUgdG8gdGhlIG9y aWdpbmFsIFJUUCBzdHJlYW06DQoNCm8gICBUaGF0IGl0IGlzIGFuIChpbnRlbnRpb25hbCkgZGV2 aWF0aW9uIGZyb20gdGhlIFJGQyA0NTg4IHJlY29tbWVuZGF0aW9uIHRvIHJlcGVhdCBSVFAgSGVh ZGVyIEV4dGVuc2lvbiB2ZXJiYXRpbSwgYnV0IGluc3RlYWQgdXNlcyBhIGZvcm1hdCB0aGF0IOKA nHBvaW50c+KAnSB0byB3aGF0IHRoZSBvcmlnaW5hbCBIRSB3YXMNCg0KbyAgIFRoYXQg4oCcYT1y aWTigJ0gc3BlY2lmaWVzIG9ubHkgdGhlIG9yaWdpbmFsIGZvcm1hdCBpbiDigJxwdD3igJ0gKGJl Y2F1c2UgdGhlIHJ0eCBzdHJlYW0gZG9lcyBub3QgdXNlIHRoYXQgUnRwU3RyZWFtSWQsIGJ1dCB1 c2VzIFJlcGFpcmVkUnRwU3RyZWFtSWQgaW5zdGVhZCkNCg0KbyAgIFRoYXQgdGhpcyBkb2VzIG5v dCBpbmRpY2F0ZSBpbiBTRFAgd2hpY2gg4oCcYT1yaWTigJ0gdXNlcyByZXRyYW5zbWlzc2lvbiwg YnV0IHRoYXQgdGhlIHJlbGF0aW9uIGNhbiBvbmx5IGJlIGZvdW5kIGluIHRoZSBydHggcmVkdW5k YW5jeSBSVFAgc3RyZWFtIHRocm91Z2ggUmVwYWlyZWRSdHBTdHJlYW1JZCAoSEUgYW5kIFJUQ1Ag U1IpDQoNCm8gICBUaGF0IHRoZSBydHggcmVkdW5kYW5jeSBSVFAgc3RyZWFtIG1heSwgYnV0IG5l ZWQgbm90LCBoYXZlIGFuIFJ0cFN0cmVhbUlkIG9mIGl0cyBvd247IGluIHRoaXMgY2FzZSwgdGhl cmUgc2hvdWxkIGJlIG5vIHJpc2sgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBrbm93 IG9mIFJlcGFpcmVkUnRwU3RyZWFtSWQgb3IgdGhhdCBpdCBpcyB1c2VkIHRvIHJlbGF0ZSB0byB0 aGUgb3JpZ2luYWwgUlRQIHN0cmVhbSBSdHBTdHJlYW1JZA0KDQrCtyAgICAgICAgIEluIGJvdGgg Y2FzZXMgYWJvdmUsIFJUQ1AgU1Igd2l0aCBTREVTIFJ0cFN0cmVhbUlkIGFuZC9vciBSZXBhaXJl ZFJ0cFN0cmVhbUlkIGZvciB0aGUgcnR4IHJlZHVuZGFuY3kgUlRQIHN0cmVhbSBjYW4gYmUgdXNl ZCBieSB0aGUgUlRQIHJlY2VpdmVyIHRvIGxlYXJuIHdoaWNoIFNTUkMgdGhlIHJldHJhbnNtaXR0 ZWQgc3RyZWFtIGhhcywgZXZlbiBiZWZvcmUgcmVjZWl2aW5nIHRoZSBmaXJzdCByZXRyYW5zbWl0 dGVkIFJUUCBwYWNrZXQNCg0KSeKAmW0gcGVyc29uYWxseSBzbGlnaHRseSBpbmNsaW5lZCB0byBz dWdnZXN0IGFsd2F5cyB1c2luZyBSZXBhaXJlZFJ0cFN0cmVhbUlkIGluIHRoZSBydHggcmVkdW5k YW5jeSBSVFAgc3RyZWFtIHRvIHJlbGF0ZSBpdCB0byB0aGUgb3JpZ2luYWwgUlRQIHN0cmVhbSAo c2Vjb25kIOKAnGlm4oCdIGJ1bGxldCBhYm92ZSksIG1haW5seSB0byBhdm9pZCBoYXZpbmcgdG8g Y2hhbmdlIGludGVycHJldGF0aW9uIG9mIFJ0cFN0cmVhbUlkIGJhc2VkIG9uIHRoZSBvcHRpb25h bCBwcmVzZW5jZSBvZiBSZXBhaXJlZFJ0cFN0cmVhbUlkLiBJ4oCZbSBvZiBjb3Vyc2Ugb3BlbiB0 byBhcmd1bWVudHMuDQoNCkkgYWxzbyBwcm9wb3NlIHRoYXQgdGhpcyByZWxhdGlvbiBiZXR3ZWVu IOKAnGE9cmlk4oCdIGFuZCByZXRyYW5zbWlzc2lvbiBpcyBkb2N1bWVudGVkIGluIC1tbXVzaWMt cmlkIHJhdGhlciB0aGFuIGluIC1tbXVzaWMtc2RwLXNpbXVsY2FzdCwgc2luY2UgSSBmaW5kIG5v dGhpbmcgaW4gdGhpcyB0aGF0IGlzIHNwZWNpZmljIHRvIHNpbXVsY2FzdC4NCg0KL0JvDQooYXMg aW5kaXZpZHVhbCkNCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBUYXlsb3IgQnJhbmRzdGV0dGVyDQpTZW50OiBkZW4gMTEgbWFycyAy MDE3IDAwOjE4DQpUbzogScOxYWtpIEJheiBDYXN0aWxsbyA8aWJjQGFsaWF4Lm5ldD4NCkNjOiBS VENXZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVs Y2FzdEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEhvdyB0byBzaWduYWwgUlRYIFNT UkNzIHdpdGggc2ltdWxjYXN0DQoNCldoYXQgcXVlc3Rpb24gYXJlIHdlIHN0aWxsIHRyeWluZyB0 byBhbnN3ZXI/ICJIb3cgZG8gd2Uga25vdyB0aGF0IFJUWCBpcyBhY3RpdmUiPyBJIHRoaW5rIEnD sWFraSBhbHJlYWR5IGdhdmUgdGhlIHJpZ2h0IGFuc3dlciBlYXJsaWVyOiBpZiB0aGUgZW5kcG9p bnRzIG5lZ290aWF0ZSBhbiBSVFggIm1lZGlhIGZvcm1hdCIgKCJhPXJ0cG1hcDo5NiBydHgvOTAw MDAiKSwgZWFjaCBlbmRwb2ludCBzaG91bGQgYmUgcHJlcGFyZWQgdG8gcmVjZWl2ZSBSVFggcGFj a2V0cyBmb3IgYW55IGVuY29kaW5nLg0KDQpBbmQgaWYgdGhlICJyaWQiIGxpbmUgZXhwbGljaXRs eSBzcGVjaWZpZXMgd2hhdCBwYXlsb2FkIHR5cGVzIGFyZSBhbGxvd2VkIHRvIGJlIHVzZWQgd2l0 aCB0aGF0IFJJRCwgaXQganVzdCBuZWVkcyB0byBpbmNsdWRlIHRoZSBSVFggcGF5bG9hZCB0eXBl IHRvIGFsbG93IFJUWCB0byBiZSB1c2VkLiBMaWtlIHNvOg0KDQphPXJ0cG1hcDo5NiBWUDgvOTAw MDANCmE9cnRwbWFwOjk3IHJ0eC85MDAwMA0KYT1mbXRwOjk3IGFwdD05Ng0KYT1yaWQ6Zm9vIHNl bmQgcHQ9OTYsOTcNCg0KQnV0IEpTRVAgZG9lc24ndCBzYXkgInB0PSIgc2hvdWxkIGJlIHVzZWQs IHNvIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBldmVuIGEgY29uY2Vybi4NCg0KDQpPbiBGcmksIE1h ciAxMCwgMjAxNyBhdCAyOjU2IFBNLCBJw7Fha2kgQmF6IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0 PG1haWx0bzppYmNAYWxpYXgubmV0Pj4gd3JvdGU6DQoyMDE3LTAzLTEwIDIzOjU0IEdNVCswMTow MCBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZmeUBpaWkuY2E+PjoN Cj4+IElmIG5vIHNpbXVsY2FzdCwgdGhvc2UgdHdvIHZpZGVvIHN0cmVhbXMgYXJlIGluIGRpZmZl cmVudCBtPXZpZGVvIHNlY3Rpb25zLCByaWdodD8NCg0KPiB5ZXMNCg0KSSB0aGluayB0aGF0IHlv dXIgZXhhbXBsZSBkb2VzIG5vdCAid29yayIgd2VsbCBzaW5jZSBzaW11bGNhc3QgaXMNCmFjaGll dmVkIHdpdGhpbiBhIHNpbmdsZSBtPXZpZGVvIHNlY3Rpb24uDQoNCg0KLS0NCknDsWFraSBCYXog Q2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0PG1haWx0bzppYmNAYWxpYXgubmV0Pj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBs aXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5pbQ0KCXttc28tc3R5bGUtbmFtZTppbTt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDo4MTEzNjExNDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjIyMTI2NTc2IC0xMzgzNzAxODU4IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIGZvcndhcmRpbmcgYSBkaXNjdXNzaW9uIHRo YXQgc3RhcnRlZCBpbiBSVENXRUIgdGhhdCBtYWlubHkgYXBwbGllcyB0byAtbW11c2ljLXJpZCBh bmQgLW1tdXNpYy1zZHAtc2ltdWxjYXN0LiBJIHN1Z2dlc3Qgd2UgY29udGludWUgdGhlIGRldGFp bGVkIGRpc2N1c3Npb24gaGVyZSBpbiBNTVVTSUMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFzIHRoZSBmb3J3 YXJkZWQgbWFpbCBzYXlzLCBpdCBpcyBzdGlsbCBzb21ld2hhdCB1bmNsZWFyIHdoYXQgcXVlc3Rp b24gdGhhdCBuZWVkcyBhbiBhbnN3ZXIsIGJ1dCBpdCBpcyBjbGVhcmx5IHJlbGF0ZWQgdG8gam9p bnQgdXNlIG9mIOKAnGE9cmlk4oCdLCDigJxhPXNpbXVsY2FzdOKAnSwgYW5kIHVzZSBvZiByZXRy YW5zbWlzc2lvbg0KICjigJxydHjigJ0gZm9ybWF0IGZyb20gUkZDIDQ1ODgpLiBJIHRoaW5rIHN1 Y2ggdXNhZ2UgbWF5IGJlIHNsaWdodGx5IHVuZGVyLXNwZWNpZmllZCBpbiBvbmUgb3IgYm90aCBv ZiB0aGUgYWJvdmUgZHJhZnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIHdoYXQgVGF5bG9yIHN1 Z2dlc3RzIGJlbG93IGlzIGEgdmVyeSBnb29kIHN0YXJ0IGFuZA0KPGk+bWF5PC9pPiBhY3R1YWxs eSBwcm92aWRlIHRoZSBzb2x1dGlvbiB3ZSB3YW50IChhbmQgc2hvdWxkIHRoZW4gZG9jdW1lbnQg YmV0dGVyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBob3dldmVyIG5vdGUgdGhhdDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+UkZDIDQ1ODggKHNlY3Rpb24gNCkgc2F5cyB0aGF0IFJUUCBIZWFkZXIgRXh0ZW5zaW9ucyAo c3VjaCBhcyBSdHBTdHJlYW1JZCwgdXNlZCBmb3Ig4oCcYT1yaWTigJ0pIFNIT1VMRCBiZSByZXBl YXRlZCBieSB0aGUgcmV0cmFuc21pdHRlZCBwYWNrZXQ6PGJyPg0KJm5ic3A7Jm5ic3A7IOKAnElm IHRoZSBvcmlnaW5hbCBSVFAgaGVhZGVyIGNhcnJpZWQgYW4gUlRQIGhlYWRlciBleHRlbnNpb24s IHRoZTxicj4NCiZuYnNwOyZuYnNwOyByZXRyYW5zbWlzc2lvbiBwYWNrZXQgU0hPVUxEIGNhcnJ5 IHRoZSBzYW1lIGhlYWRlciBleHRlbnNpb24uJm5ic3A7IFRoaXM8YnI+DQombmJzcDsmbmJzcDsg aGVhZGVyIGV4dGVuc2lvbiBNVVNUIGJlIHBsYWNlZCByaWdodCBhZnRlciB0aGUgZml4ZWQgUlRQ IGhlYWRlciwgYXM8YnI+DQombmJzcDsmbmJzcDsgc3BlY2lmaWVkIGluIFJUUCBbM10uJm5ic3A7 IEluIHRoaXMgY2FzZSwgdGhlIHJldHJhbnNtaXNzaW9uIHBheWxvYWQ8YnI+DQombmJzcDsmbmJz cDsgaGVhZGVyIE1VU1QgYmUgcGxhY2VkIGFmdGVyIHRoZSBoZWFkZXIgZXh0ZW5zaW9uLuKAnTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JdCBpcyBub3Qgc2VsZi1ldmlkZW50IHRoYXQgdGhlIHJldHJhbnNtaXNz aW9uIHJlZHVuZGFuY3kgUlRQIHN0cmVhbSAoUkZDIDc2NTYpIHNob3VsZCBiZSBhc3NpZ25lZCB0 aGUgc2FtZSBSdHBTdHJlYW1JZCBhcyB0aGUgUlRQIHN0cmVhbSBpdCBwcm90ZWN0cywgZXNwZWNp YWxseQ0KIHNpbmNlIHRoYXQgd291bGQgcHJldmVudCBhc3NpZ25pbmcgYSBzZXBhcmF0ZSBSdHBT dHJlYW1JZCB0byB0aGUgcmVkdW5kYW5jeSBSVFAgc3RyZWFtIGl0c2VsZiAoaWYgdGhhdCBpcyBl dmVyIG5lZWRlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LWF2dGV4dC1yaWQgYWxyZWFkeSBwcm92aWRlcyBh IHdheSB0byBkZWFsIHdpdGggdGhpcyBieSBkZWZpbmluZyBSZXBhaXJlZFJ0cFN0cmVhbUlkLCBi dXQgLW1tdXNpYy1yaWQgY3VycmVudGx5IGRvZXMgbm90IGluIGFueSB3YXkgZGV0YWlsIGl0cyB1 c2FnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5JIGJlbGlldmUgd2UgbmVlZCB0byBkZWNpZGUgb24gYW5kIGRv Y3VtZW50OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaGV0aGVyIHRvIHVzZSBSdHBTdHJlYW1JZCBvciBSZXBh aXJlZFJ0cFN0cmVhbUlkIGluIHRoZSBydHggcmVkdW5kYW5jeSBSVFAgc3RyZWFtIHRvIGluZGlj YXRlIHdoYXQgUnRwU3RyZWFtSWQgdGhlIG9yaWdpbmFsIFJUUCBzdHJlYW0gaGFzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPklmIHVzaW5nIHRoZSBzYW1lIFJ0cFN0cmVhbUlkIGluIHRoZSBydHggcmVkdW5kYW5j eSBSVFAgc3RyZWFtIGFzIGluIHRoZSBvcmlnaW5hbCBSVFAgc3RyZWFtIChiYXNpY2FsbHkgVGF5 bG9y4oCZcyBwcm9wb3NhbCk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGF0IGl0IGlzIGFsaWduZWQgd2l0 aCB0aGUgUkZDIDQ1ODggcmVjb21tZW5kYXRpb24gdG8gY29weSBvcmlnaW5hbCBSVFAgSEUgKHZl cmJhdGltKSBpbnRvIHJldHJhbnNtaXR0ZWQgcGFja2V0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGF0IOKA nGE9cmlk4oCdIHNwZWNpZmllcyBib3RoIG9yaWdpbmFsIGZvcm1hdCBhbmQgcnR4IGZvcm1hdCBm b3IgdGhlIOKAnHB0PeKAnSBwYXJhbWV0ZXIgKGFzIFRheWxvciBzdWdnZXN0cyBiZWxvdyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBs Zm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoYXQgdGhpcyBjbGVhcmx5IGluZGljYXRlcyBpbiBTRFAgd2hpY2gg4oCc YT1yaWTigJ0gdXNlcyByZXRyYW5zbWlzc2lvbiAoYnkgcG9pbnRpbmcgYWxzbyB0byBhIHJ0eCBQ VCkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAg bGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCBpZiB0aGUgcnR4IHJlZHVuZGFuY3kgUlRQIHN0cmVh bSBpdHNlbGYgbmVlZHMgYW4gUnRwU3RyZWFtSWQsIFJlcGFpcmVkUnRwU3RyZWFtSWQgaXMgaW5z dGVhZCB1c2VkIHRvIHJlbGF0ZSB0byB0aGUgb3JpZ2luYWwgUlRQIHN0cmVhbTsgSSBub3RlIHRo YXQgdGhlcmXigJlzIGENCiByaXNrIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBkb2VzIG5v dCBrbm93IG9mIFJlcGFpcmVkUnRwU3RyZWFtSWQgd2lsbCB0aGVuIG5vdCBmaW5kIHRoZSByZWxh dGlvbiBiZXR3ZWVuIG9yaWdpbmFsIGFuZCBydHggUlRQIHN0cmVhbTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J ZiBhbHdheXMgdXNpbmcgUmVwYWlyZWRSdHBTdHJlYW1JZCBpbiB0aGUgcnR4IHJlZHVuZGFuY3kg UlRQIHN0cmVhbSB0byByZWxhdGUgdG8gdGhlIG9yaWdpbmFsIFJUUCBzdHJlYW06PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGF0IGl0IGlzIGFuIChpbnRlbnRpb25hbCkgZGV2aWF0aW9uIGZyb20gdGhlIFJG QyA0NTg4IHJlY29tbWVuZGF0aW9uIHRvIHJlcGVhdCBSVFAgSGVhZGVyIEV4dGVuc2lvbg0KPGk+ dmVyYmF0aW08L2k+LCBidXQgaW5zdGVhZCB1c2VzIGEgZm9ybWF0IHRoYXQg4oCccG9pbnRz4oCd IHRvIHdoYXQgdGhlIG9yaWdpbmFsIEhFIHdhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCDigJxhPXJp ZOKAnSBzcGVjaWZpZXMgb25seSB0aGUgb3JpZ2luYWwgZm9ybWF0IGluIOKAnHB0PeKAnSAoYmVj YXVzZSB0aGUgcnR4IHN0cmVhbSBkb2VzIG5vdCB1c2UgdGhhdCBSdHBTdHJlYW1JZCwgYnV0IHVz ZXMgUmVwYWlyZWRSdHBTdHJlYW1JZCBpbnN0ZWFkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQt aW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCB0aGlz IGRvZXMgbm90IGluZGljYXRlIGluIFNEUCB3aGljaCDigJxhPXJpZOKAnSB1c2VzIHJldHJhbnNt aXNzaW9uLCBidXQgdGhhdCB0aGUgcmVsYXRpb24gY2FuIG9ubHkgYmUgZm91bmQgaW4gdGhlIHJ0 eCByZWR1bmRhbmN5IFJUUCBzdHJlYW0gdGhyb3VnaCBSZXBhaXJlZFJ0cFN0cmVhbUlkDQogKEhF IGFuZCBSVENQIFNSKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhdCB0aGUgcnR4IHJlZHVuZGFuY3kgUlRQ IHN0cmVhbSBtYXksIGJ1dCBuZWVkIG5vdCwgaGF2ZSBhbiBSdHBTdHJlYW1JZCBvZiBpdHMgb3du OyBpbiB0aGlzIGNhc2UsIHRoZXJlIHNob3VsZCBiZSBubyByaXNrIHRoYXQgYW4gaW1wbGVtZW50 YXRpb24gZG9lcyBub3Qga25vdyBvZg0KIFJlcGFpcmVkUnRwU3RyZWFtSWQgb3IgdGhhdCBpdCBp cyB1c2VkIHRvIHJlbGF0ZSB0byB0aGUgb3JpZ2luYWwgUlRQIHN0cmVhbSBSdHBTdHJlYW1JZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5JbiBib3RoIGNhc2VzIGFib3ZlLCBSVENQIFNSIHdpdGggU0RFUyBSdHBT dHJlYW1JZCBhbmQvb3IgUmVwYWlyZWRSdHBTdHJlYW1JZCBmb3IgdGhlIHJ0eCByZWR1bmRhbmN5 IFJUUCBzdHJlYW0gY2FuIGJlIHVzZWQgYnkgdGhlIFJUUCByZWNlaXZlciB0byBsZWFybiB3aGlj aCBTU1JDDQogdGhlIHJldHJhbnNtaXR0ZWQgc3RyZWFtIGhhcywgZXZlbiBiZWZvcmUgcmVjZWl2 aW5nIHRoZSBmaXJzdCByZXRyYW5zbWl0dGVkIFJUUCBwYWNrZXQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SeKA mW0gcGVyc29uYWxseSBzbGlnaHRseSBpbmNsaW5lZCB0byBzdWdnZXN0IGFsd2F5cyB1c2luZyBS ZXBhaXJlZFJ0cFN0cmVhbUlkIGluIHRoZSBydHggcmVkdW5kYW5jeSBSVFAgc3RyZWFtIHRvIHJl bGF0ZSBpdCB0byB0aGUgb3JpZ2luYWwgUlRQIHN0cmVhbSAoc2Vjb25kIOKAnGlm4oCdIGJ1bGxl dCBhYm92ZSksDQogbWFpbmx5IHRvIGF2b2lkIGhhdmluZyB0byBjaGFuZ2UgaW50ZXJwcmV0YXRp b24gb2YgUnRwU3RyZWFtSWQgYmFzZWQgb24gdGhlIG9wdGlvbmFsIHByZXNlbmNlIG9mIFJlcGFp cmVkUnRwU3RyZWFtSWQuIEnigJltIG9mIGNvdXJzZSBvcGVuIHRvIGFyZ3VtZW50cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SSBhbHNvIHByb3Bvc2UgdGhhdCB0aGlzIHJlbGF0aW9uIGJldHdlZW4g4oCcYT1y aWTigJ0gYW5kIHJldHJhbnNtaXNzaW9uIGlzIGRvY3VtZW50ZWQgaW4gLW1tdXNpYy1yaWQgcmF0 aGVyIHRoYW4gaW4gLW1tdXNpYy1zZHAtc2ltdWxjYXN0LCBzaW5jZSBJIGZpbmQgbm90aGluZyBp biB0aGlzIHRoYXQgaXMNCiBzcGVjaWZpYyB0byBzaW11bGNhc3QuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi9C bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+KGFzIGluZGl2aWR1YWwpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+VGF5bG9yIEJyYW5kc3RldHRlcjxicj4NCjxiPlNlbnQ6PC9i PiBkZW4gMTEgbWFycyAyMDE3IDAwOjE4PGJyPg0KPGI+VG86PC9iPiBJw7Fha2kgQmF6IENhc3Rp bGxvICZsdDtpYmNAYWxpYXgubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUlRDV2ViIElFVEYgJmx0 O3J0Y3dlYkBpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3RAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIEhvdyB0byBzaWduYWwgUlRY IFNTUkNzIHdpdGggc2ltdWxjYXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hhdCBxdWVzdGlvbiBhcmUgd2Ugc3RpbGwgdHJ5aW5nIHRvIGFuc3dlcj8gJnF1b3Q7SG93 IGRvIHdlIGtub3cgdGhhdCBSVFggaXMgYWN0aXZlJnF1b3Q7PyBJIHRoaW5rIEnDsWFraSBhbHJl YWR5IGdhdmUgdGhlIHJpZ2h0IGFuc3dlciBlYXJsaWVyOiBpZiB0aGUgZW5kcG9pbnRzIG5lZ290 aWF0ZSBhbiBSVFggJnF1b3Q7bWVkaWEgZm9ybWF0JnF1b3Q7ICgmcXVvdDthPXJ0cG1hcDo5NiBy dHgvOTAwMDAmcXVvdDspLCBlYWNoIGVuZHBvaW50IHNob3VsZCBiZSBwcmVwYXJlZA0KIHRvIHJl Y2VpdmUgUlRYIHBhY2tldHMgZm9yIGFueSBlbmNvZGluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBpZiB0aGUgJnF1b3Q7cmlkJnF1b3Q7IGxpbmUg ZXhwbGljaXRseSBzcGVjaWZpZXMgd2hhdCBwYXlsb2FkIHR5cGVzIGFyZSBhbGxvd2VkIHRvIGJl IHVzZWQgd2l0aCB0aGF0IFJJRCwgaXQganVzdCBuZWVkcyB0byBpbmNsdWRlIHRoZSBSVFggcGF5 bG9hZCB0eXBlIHRvIGFsbG93IFJUWCB0byBiZSB1c2VkLiBMaWtlIHNvOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hPXJ0cG1hcDo5NiBWUDgv OTAwMDA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PmE9cnRwbWFwOjk3IHJ0eC85MDAwMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+YT1mbXRwOjk3IGFwdD05Njwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5hPXJpZDpmb28gc2VuZCBwdD05 Niw5Nzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkJ1dCBKU0VQIGRvZXNuJ3Qgc2F5ICZxdW90O3B0PSZxdW90OyBzaG91bGQgYmUgdXNl ZCwgc28gSSBkb24ndCB0aGluayB0aGlzIGlzIGV2ZW4gYSBjb25jZXJuLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IE1hciAxMCwgMjAxNyBhdCAyOjU2IFBNLCBJw7Fha2kgQmF6IENhc3RpbGxvICZsdDs8YSBocmVm PSJtYWlsdG86aWJjQGFsaWF4Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmliY0BhbGlheC5uZXQ8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjIwMTctMDMtMTAgMjM6NTQgR01UJiM0 MzswMTowMCBDdWxsZW4gSmVubmluZ3MgJmx0OzxhIGhyZWY9Im1haWx0bzpmbHVmZnlAaWlpLmNh Ij5mbHVmZnlAaWlpLmNhPC9hPiZndDs6PGJyPg0KJmd0OyZndDsgSWYgbm8gc2ltdWxjYXN0LCB0 aG9zZSB0d28gdmlkZW8gc3RyZWFtcyBhcmUgaW4gZGlmZmVyZW50IG09dmlkZW8gc2VjdGlvbnMs IHJpZ2h0Pzxicj4NCjxicj4NCiZndDsgeWVzPGJyPg0KPGJyPg0KSSB0aGluayB0aGF0IHlvdXIg ZXhhbXBsZSBkb2VzIG5vdCAmcXVvdDt3b3JrJnF1b3Q7IHdlbGwgc2luY2Ugc2ltdWxjYXN0IGlz PGJyPg0KYWNoaWV2ZWQgd2l0aGluIGEgc2luZ2xlIG09dmlkZW8gc2VjdGlvbi48YnI+DQo8YnI+ DQo8YnI+DQo8c3BhbiBjbGFzcz0iaW0iPi0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+ ScOxYWtpIEJheiBDYXN0aWxsbzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPiZsdDs8YSBo cmVmPSJtYWlsdG86aWJjQGFsaWF4Lm5ldCI+aWJjQGFsaWF4Lm5ldDwvYT4mZ3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_-- --_004_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Fri, 10 Mar 2017 23:17:46 GMT"; modification-date="Fri, 10 Mar 2017 23:17:46 GMT" Content-ID: <3842028AD71E9E49ABEFE04EDB1104AD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBt YWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCg== --_004_AM5PR0701MB2577FD1D3E43697C4672F80C8D250AM5PR0701MB2577_-- From nobody Mon Mar 13 03:46: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 1309B12954B for ; Mon, 13 Mar 2017 03:46:26 -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, 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=aliax-net.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 GlKAFfJxPSEN for ; Mon, 13 Mar 2017 03:46:24 -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 A6E3512945D for ; Mon, 13 Mar 2017 03:46:23 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id n11so36529005wma.0 for ; Mon, 13 Mar 2017 03:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EMUKBSE1cbUHhyjbH1zwvKJt854GTwTAz0Rhm+usAT4=; b=X/DA8QBEKLTw5PNnwqlgT1lainf/d8jXHyZL8g/DsqgeAAMAD3qv/p+qazX3FQEgi1 sUAgbMgueL9XIjjW9cMbnhDUq5a5pNWjWzR0ZXO7waF7JZ/1nuWFHYC1YDYETBMpJf2R GuyI0/ZlhGN3gLI3BhofINZmAINBMAMMiLfDk+XjdisUXTfov0CE9Of5o/oLqXVcG4fU 8aTI4fXZrIhqPdHcjLrUvfS9lqgVBIqS0B+RkBWMNVOPUUmad6z9VKs7JuDV2DE+iw69 Jcb+OsZx6xzeKVw445OQrOHD+ujs5XfLF7T88Y+KW/SFaGBTkr323du0UW1PevUAb+GS vU7Q== 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=EMUKBSE1cbUHhyjbH1zwvKJt854GTwTAz0Rhm+usAT4=; b=Zxipb0E8zYpUc5onIwDo1+VRykqaQc/FOqkfO1SA9A540kNSg7UosAVimCobaELXuT T9qBcpNxjaVD8i3t/0bOiokVU5IqcOLiPZTw85lq6Yj6qTfMS5aeutkE7XuWhXq4C5g+ ffxoO985jq6YLI7T05samiOnc3/Hk+VL7jSW1i2WFV2qpV5+xuQf33ZqiSOQwxOkI6hp PPDlMFdH/STwpYWaBfhIJpgNO5EH0IUexjDFN6ZcSb5/0JPkM9PtcpbI32N8RTGQINC6 BzIaMGUVPEjQV2luXNZyXT43u0vSCta55N7tKZKDmQSlL0GWv0CGyICTIbxw2fmhY+Qj QqBA== X-Gm-Message-State: AFeK/H3VcAhf1WmsVIx7htPuKvaeFlQvJSmqn7OcTlzsqwzPRGt5A95vE+TTyKaJ2tPbUQ55IYyPY/Gae44j4A== X-Received: by 10.28.182.7 with SMTP id g7mr9912186wmf.108.1489401982136; Mon, 13 Mar 2017 03:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 13 Mar 2017 03:46:01 -0700 (PDT) In-Reply-To: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 13 Mar 2017 11:46:01 +0100 Message-ID: To: Bo Burman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-mmusic-rid@ietf.org" , "mmusic \(mmusic@ietf.org\)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:46:26 -0000 2017-03-13 10:56 GMT+01:00 Bo Burman : > I=E2=80=99m personally slightly inclined to suggest always using Repaired= RtpStreamId > in the rtx redundancy RTP stream to relate it to the original RTP stream > (second =E2=80=9Cif=E2=80=9D bullet above), mainly to avoid having to cha= nge interpretation > of RtpStreamId based on the optional presence of RepairedRtpStreamId. I= =E2=80=99m of > course open to arguments. Personally I prefer option A (use a shared RtpStreamId). My rationale: If we go with option B (RepairedRtpStreamId) then we will need something similar when it comes to FLEX-FEC [*]: v=3D0 o=3Dali 1122334455 1122334466 IN IP4 fec.example.com s=3D2-D Parity FEC with no in band signalling Example t=3D0 0 m=3Dvideo 30000 RTP/AVP 100 110 c=3DIN IP4 233.252.0.1/127 a=3Drtpmap:100 MP2T/90000 a=3Drtpmap:110 flexfec/90000 a=3Dfmtp:110 L:5; D:10; ToP:2; repair-window:200000 a=3Dssrc:1234 a=3Dssrc:2345 a=3Dssrc-group:FEC-FR 1234 2345 For me it's to think in RtpStreamId as "the identificator of a media stream and, optionally, also the identificator of the RTX stream and FEC stream of such a media stream". [*] https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-03 --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 13 03:47: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 1BF1512945D for ; Mon, 13 Mar 2017 03:46:59 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 sds13kKbet71 for ; Mon, 13 Mar 2017 03:46:58 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 2E676129543 for ; Mon, 13 Mar 2017 03:46:57 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n11so36540498wma.0 for ; Mon, 13 Mar 2017 03:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pph3OH30O2JNSgiZaze4nISgbnUa98NO5dFcfX8ZsDs=; b=hqEganJMpfiFTY94vybAwBp93V8mXtoWPfAFo5mGZ+SX0jsjT61Z2kjh7vxdamOii3 Bay0470hqWEIKZ1ONxbzUfLcB7OjB0nSH2dK7qnES6HWLWMoeq7d2g8PPuvAaPiMnRXM iudGSLko/AhggOgYeBsMqxsFHoOARy57ogY8210JsIPMZ/OuoMiIHliCXd65L2Um9/c0 kJpvhxIcXiaytAN0+aNeehiR4lJQb8Y/pPWWZbzHHJQZgRme0h+wkz/4F4N8W1pZpaEB ir4UxCoVy7RSObmkRb2dq7YNgePp/W5CJ4UI93eYSftBcQSCprDpsQ2PsJ+blVNrVDdZ uFaA== 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=Pph3OH30O2JNSgiZaze4nISgbnUa98NO5dFcfX8ZsDs=; b=PtoE2MQ9jtt+1Mk12tJggZUciaLgY648VK0l7MNsyqgnJZqCAUluxEfP2pFi5LTqzo lVFJRQzrc257cnvv8/f8m3x26MaxpB5oOaPFGzqGeHMsTR2M6H/vMDXRM90r7VoA4vQg hcl2qYuxqxjrw2noRR7/2jYrTzM521CGLx77s9T07AhqSGvQmTeSYHgVuUDYXo/zwK7V 1z/Wo0YZRInRR/tX2hXDuDRtG2RVr5eSR4ZaXSin6yorikk5kmtqQJJkhs/sRtIkXjCK 6knUcI7iUSRG3TmUytSQjUjjrK0OaKaghj2Rx+vdNX9Gyqzez5rxv1U0alCkZ91ogIix hDUA== X-Gm-Message-State: AFeK/H1GoHSmD9Xbruhjk49+3MjZxdC4xSoddt0REtWNV0gfMjob3bO9lS3oUoJ1cFJAhPfyPkMBg78kYwK7dg== X-Received: by 10.28.48.67 with SMTP id w64mr9746530wmw.125.1489402015709; Mon, 13 Mar 2017 03:46:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 13 Mar 2017 03:46:35 -0700 (PDT) In-Reply-To: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 13 Mar 2017 11:46:35 +0100 Message-ID: To: Bo Burman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-mmusic-rid@ietf.org" , "mmusic \(mmusic@ietf.org\)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 10:46:59 -0000 2017-03-13 11:46 GMT+01:00 I=C3=B1aki Baz Castillo : > For me it's to think in RtpStreamId as "the identificator of a media > stream and, optionally, also the identificator of the RTX stream and > FEC stream of such a media stream". Sorry, I meant "For me it's OK to think in...". --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 13 04:31: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 8894D1294E1 for ; Mon, 13 Mar 2017 04:31:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 rZBWl6bT39Ni for ; Mon, 13 Mar 2017 04:31:14 -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 2F2DC129400 for ; Mon, 13 Mar 2017 04:31:14 -0700 (PDT) X-AuditID: c1b4fb30-3623498000006a1c-90-58c68300cd5e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id FB.48.27164.00386C85; Mon, 13 Mar 2017 12:31:12 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 12:30:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MPpOhJcpA+kGmX80OFXQ3V1TISqsjjeQUF6m1fGVMr0=; b=ktNNbTKhZBOvQs8Z6Nso9R2zvnXTj/MtvLpkGkq7OA3V+t3jdX55bEeKIiRimeiZu64UiHKZD75my/Uzk/HH3PF/4XgGlKRr+dv6uBA4WzFeiZNrCUBa13bYtEJg+DWHcmCRkfowWTZd0wuEVd6FJO+RuE8pLizzJVq5UYyhHyM= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2578.eurprd07.prod.outlook.com (10.173.92.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 11:30:20 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 11:30:20 +0000 From: Bo Burman To: "Makaraju, Raju (Nokia - US)" , "mmusic (mmusic@ietf.org)" Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AQHSm5yGz6G1c3++IkS/LRYJALgIgaGSn/ow Date: Mon, 13 Mar 2017 11:30:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2578; 7:OFSR8ojfDHfVv+6TEl78Ljn7s6cofrXudO9SkvICrMYCQhy16siNUwDkDkqJYVJW6euMsGi+RPRpFb13lahIEbDN4uegyJTfWl/p8n9S6ZYWMni3t3On4xsYO/xfEmvdZlHDTJebV6GaC7NBbFrVkFJ8b7MEVVe7R9tiihClT4/7Oo7g7NJO22HgYPQtsTk4XAuAYEYfRHSEPKZZRHWDmXKs9ZlmvgA5ii5a2LdCu/Elne5PgGMpdmWbvYk+FMAPi5maxpks/gNBu/Fyoi2qwqjyr9f020+JH92METfnDcpxJ7i02bnQhqpWS1YT98N5o5atWTgKuvmeiuE40OymvA== x-ms-office365-filtering-correlation-id: 3c4d2cc5-899e-48df-d7b7-08d46a045518 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2578; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM5PR0701MB2578; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2578; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(377454003)(229853002)(66066001)(106116001)(9326002)(81166006)(77096006)(6506006)(55016002)(25786008)(606005)(6436002)(8936002)(236005)(76176999)(54356999)(50986999)(5660300001)(33656002)(8676002)(6306002)(54896002)(9686003)(2900100001)(122556002)(3280700002)(2950100002)(6246003)(230783001)(38730400002)(2906002)(53546006)(790700001)(6116002)(189998001)(3846002)(102836003)(7906003)(7736002)(7696004)(74316002)(86362001)(53936002)(3660700001)(19609705001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2578; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2577DC8BA44DF93665AC621C8D250AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 11:30:20.5566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2578 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUyM2K7vS5D87EIgzcNKhZTlz9msVi/+x6L A5PHkiU/mTzu3rrEFMAUxWWTkpqTWZZapG+XwJUxde4M9oIXDxgr9p9fwdLA+PUwYxcjJ4eE gIlE//p5bF2MXBxCAusYJXq+TGaFcE4wSiy4u40dxGER6GWWaL93ggUiM51JYs3nHja4slf3 b7OADGMT0JCYv+Mu2GARgWyJ3Wv/sIPYwgJREmeOzmGFiEdL/On+zw5hG0mc6b/EBmKzCKhK tC/pAevlFUiQ2PLtGzvEgq2MEhs7XoM1cArES7z+eQ2siFFATOL7qTVMIDazgLjErSfzmSA+ EpBYsuc8M4QtKvHy8T+whxgFehklpv7pZoFIKEi86m4Ae0FCoI9Z4u+6n9Dw8JV4e2YfUBEH kO0vsehbLEQ4X2LuihZWCDtK4sU2kMUgvfOYJJ60fWKDSMhILNrRCjW0gVWi+88lJoj/pSTu XulkhLBlJF7c2csKcXa+xOG5j5kmMKrPQvLFLCSpWeDgEJQ4OfMJC0RcR2LB7k9sELa2xLKF r5lh7DMHHjMhiy9gZF/FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZiKDm75bbCD8eVzx0OM AhyMSjy8G2YdjRBiTSwrrsw9xCjBwawkwmtUfSxCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/Z yvvhQgLpiSWp2ampBalFMFkmDk6pBka1zKKcStHTOprqV9tnxTjzb722gze68dsjDf33EcVn z7jHHdp1zVZ2i8DKvR2O7Hl7Nhgrceg90b3k//y1YsRUnfsr5MJOPTv/2f7i5itpF11+MHRt 70v7y/PvZV/g+eNqq/YF/n5pwzjDiOE5Y0L1ovkLGvqX1nTM/mlX3Plz49Yva9vLz9xVYinO SDTUYi4qTgQAc7FlbUEDAAA= Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 11:31:17 -0000 --_000_AM5PR0701MB2577DC8BA44DF93665AC621C8D250AM5PR0701MB2577_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raju, Regarding: 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? It was a bit unclear if it was some kind of quote from somewhere, which is = also commonly indicated by such indentation. I suggest just making it expli= cit that it is a note, starting the first line with "Note: ". /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 02:52 To: Bo Burman ; mmusic (mmusic@ietf.org) Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo Burman, Christian Groves, Paul Kyzivat, Thank you so much for your time in making this document better, we apprecia= te it. Sorry for the extended delay. I accepted all the comments. Please see my comments inserted below. Thanks again Raju From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: Tuesday, February 28, 2017 10:11 AM To: mmusic (mmusic@ietf.org) > Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-= sdpneg-11 Authors, WG, I think this document is getting ready for publication request. As part of = making the shepherd's write-up, I have the following comments, to be addres= sed in an updated document: Issues: 1) In section 1: add that also BFCP (Binary Floor Control Protocol) i= s used in the same way as MSRP in examples. [Raju] Will add BFCP. 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite length of t= his identifier, which seems inappropriate. I suggest providing a maximum le= ngth, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960)= , in which case 1*5DIGIT should be sufficient. [Raju] Will change as suggested. 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" af= ter "%" when defining hex characters. Change to: quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % [Raju] Will change as suggested. 4) In 5.1.2.1, text below the example makes reference to MSRP subproto= col, but the example does not explicitly include any MSRP. The single examp= le line uses "accept-types", which is admittedly related to MSRP, but I thi= nk this should be clarified to avoid confusion for readers not familiar wit= h MSRP. [Raju] Will change "Example" to "Example (other MSRP related SDP attributes= are omitted for brevity):" 5) In 5.2.2: It is unclear why you differentiate handling of offers an= d answers that contain both "max-retr" and "max-time", mandating to reject = the offer but allowing it in the answer. I think allowing this asymmetry sh= ould either be motivated, or handling should be aligned between offer and a= nswer. [Raju] I think it was thought giving a bit of flexibility to offerer while = receiving answer is probably good but I see your point on aligning both. Wi= ll change text to align both. 6) In section 6: several examples uses IP addresses that are not align= ed with RFC 6890 (10.10.10.x), which must be changed. Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3). [Raju] Will change as suggested. 7) In Appendix A: same IP address issue as above, change from 79.97.21= 5.79 to an address in the allowed range. [Raju] Will change as suggested. Nits: 1) The date line in the document header is one character too long (bey= ond column 72) [Raju] Good catch! Hmmm... not sure how it is getting messed up as the it i= s supposed to be an auto generated line. Anyway, I just checked the new upd= ated draft at https://xml2rfc.tools.ietf.org and output looks good. 2) In section 1: s/In future data channels could/In the future, data c= hannels could/ [Raju] Will change as suggested. 3) In section 3: s/sending and receive data/sending and receiving data= / [Raju] Will change as suggested. 4) At the very end of section 5.1.2.1: s/in the same document, which r= egisters/in the same document that registers/ [Raju] Will change as suggested. 5) In 5.2.4: s/other data channels which are now not included/other da= ta channels that are now not included/ [Raju] Will change as suggested. 6) In 5.2.5: s/channels are expected be closed now/channels are expect= ed to be closed now/ [Raju] Will change as suggested. 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHA= LL use/ [Raju] Will change as suggested. 8) In Appendix A.1: s/either pass to the data channel stack the stream= identifier to assign/either pass the stream identifier to the data channel= stack to assign/ [Raju] Will change as suggested. 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? Comments from others that are not addressed in -11: 1) Christian Groves commented on Jan 20 that the example in Appendix A= should contain an "a=3Ddtls-id:..." attribute as per other examples in the= draft. [Raju] Will add a=3Ddtls-id. 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 sho= uld be changed to: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. [Raju] Will change as suggested. Thanks raju Cheers, /Bo MMUSIC co-chair --_000_AM5PR0701MB2577DC8BA44DF93665AC621C8D250AM5PR0701MB2577_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Raju,

 

Regarding:

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

It was a bit unclear if it was some kind of quote fr= om somewhere, which is also commonly indicated by such indentation. I sugge= st just making it explicit that it is a note, starting the first line with = “Note: ”.

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raj= u.makaraju@nokia.com]
Sent: den 13 mars 2017 02:52
To: Bo Burman <bo.burman@ericsson.com>; mmusic (mmusic@ietf.or= g) <mmusic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo Burman, Christian Groves, Paul Kyzivat,

 

Thank you so much for your time in making this docum= ent better, we appreciate it. Sorry for the extended delay.

I accepted all the comments.

Please see my comments inserted below.

 

Thanks again

Raju

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: Tuesday, February 28, 2017 10:11 AM
To: mmusic (mmusic@ietf.org) = <mmusic@ietf.org>
Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-c= hannel-sdpneg-11

 

Authors, WG,

 

I think this document is getting ready for publicati= on request. As part of making the shepherd’s write-up, I have the fol= lowing comments, to be addressed in an updated document:

 

Issues:

1)      In section 1: add that also BFCP (Binary Floor Cont= rol Protocol)  is used in the same way as MSRP in examples.=

[Raju] Will add BFCP.

2)      In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infi= nite length of this identifier, which seems inappropriate. I suggest provid= ing a maximum length, maybe matching this to the unsigned 16 bit integer in= SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

[Raju] Will change as suggested.<= /o:p>

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect= , missing “x” after “%” when defining hex character= s. Change to:
quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or= %

[Raju] Will change as suggested.<= /o:p>

4)      In 5.1.2.1, text below the example makes reference = to MSRP subprotocol, but the example does not explicitly include any MSRP. = The single example line uses “accept-types”, which is admittedl= y related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

[Raju] Will change “Example” to &#= 8220;Example (other MSRP related SDP attributes are omitted for brevity):&#= 8221;

5)      In 5.2.2: It is unclear why you differentiate handl= ing of offers and answers that contain both “max-retr” and R= 20;max-time”, mandating to reject the offer but allowing it in the an= swer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

[Raju] I think it was thought giving a bit of = flexibility to offerer while receiving answer is probably good but I see yo= ur point on aligning both. Will change text to align both.

6)      In section 6: several examples uses IP addresses th= at are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3).

[Raju] Will change as suggested. =

7)      In Appendix A: same IP address issue as above, chan= ge from 79.97.215.79 to an address in the allowed range.

[Raju] Will change as suggested. =

 

Nits:

1)      The date line in the document header is one charact= er too long (beyond column 72)

[Raju] Good catch! Hmmm… not sure how it= is getting messed up as the it is supposed to be an auto generated line. A= nyway, I just checked the new updated draft at https://xml2rfc.tools.ietf.org and output l= ooks good.

2)      In section 1: s/In future data channels could/In th= e future, data channels could/

[Raju] Will change as suggested. =

3)      In section 3: s/sending and receive data/sending an= d receiving data/

[Raju] Will change as suggested. =

4)      At the very end of section 5.1.2.1: s/in the same d= ocument, which registers/in the same document that registers/

[Raju] Will change as suggested. =

5)      In 5.2.4: s/other data channels which are now not i= ncluded/other data channels that are now not included/

[Raju] Will change as suggested.<= /o:p>

6)      In 5.2.5: s/channels are expected be closed now/cha= nnels are expected to be closed now/

[Raju] Will change as suggested.<= /o:p>

7)      In 8.3: s/dcsa usage level only shall use/dcsa usag= e level only SHALL use/

[Raju] Will change as suggested.<= /o:p>

8)      In Appendix A.1: s/either pass to the data channel = stack the stream identifier to assign/either pass the stream identifier to = the data channel stack to assign/

[Raju] Will change as suggested.<= /o:p>

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

Comments from others that are not addressed in -11:<= o:p>

1)      Christian Groves commented on Jan 20 that the examp= le in Appendix A should contain an “a=3Ddtls-id:…” attrib= ute as per other examples in the draft.

[Raju] Will add a= =3Ddtls-id.

2)      Paul Kyzivat commented on Jan 21 that a bullet in s= ection 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and    channel parameters contained in the SDP offer.=

[Raju] Will change as suggested.

 

Thanks

raju

 

Cheers,

/Bo

MMUSIC co-chair

 

--_000_AM5PR0701MB2577DC8BA44DF93665AC621C8D250AM5PR0701MB2577_-- From nobody Mon Mar 13 04:41: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 20E72129587; Mon, 13 Mar 2017 04:41:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 mq39X3ljuuww; Mon, 13 Mar 2017 04:41:14 -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 C7214129586; Mon, 13 Mar 2017 04:41:13 -0700 (PDT) X-AuditID: c1b4fb30-3623498000006a1c-27-58c68557ac46 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id F2.CB.27164.75586C85; Mon, 13 Mar 2017 12:41:12 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 12:41:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lA8FzDsJrYVMTZ3kqB3LbaAynp8gLnCHpmJ05GWUWEA=; b=hVzI5+iPMqOGEFAurNpC+mDer1ovuTd1hZFQAU5HgN8fySG9lxKtYQG2zwgUCePOKneEGn1kpdnQCOe3p4uFkB05QBV6WysqWYsdUGFMPFxMK1FJsZvppWxoqNHn7XvCsucWdlEEWMJt4IIrKXaoaN2QNGx3ID/OMha1q39FiPE= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2578.eurprd07.prod.outlook.com (10.173.92.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 11:41:10 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 11:41:10 +0000 From: Bo Burman To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast Thread-Index: AQHSmSRXaXEak/rxUUuXLqrZPXzB4qGOeTSAgAADuwCAADM6gIAAAMcAgAAFxYCAA7fx4IAALRSAgAANzbA= Date: Mon, 13 Mar 2017 11:41:10 +0000 Message-ID: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: aliax.net; dkim=none (message not signed) header.d=none;aliax.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2578; 7:zGPMHEJu0UZj7gDiQW11ozWRNznjHWWKkvU/9P4TPyigQkBmGRDWKnEGGdFGBn97A+qHATW5pj5o7X1MbVP5FlUf1vCVWqVJsieJaVt1yZ/6PFJws2zydhiCGHxl80wcL2R5XLXirO+UNTi8uW28lpX9GAn3LAHkb4OSJ/m6rLz9SUjl0UI4x0d5jILbVMYgJmRHrgOB/zjdGmjUwMCmGj0IPYKNaNRsK9ieVLH5d7Aj4rR7c8h0gD311p2MOfjKEQRGtycew5t4gb2s2qgKAQSENl6yTh4onHpR39i3/6xYNnTUUOtc22IYiJ+7QE1p2xYD80/GwSyI+4QJuWR4GQ== x-ms-office365-filtering-correlation-id: 8a25c60f-b94d-4a53-6fde-08d46a05d87b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2578; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM5PR0701MB2578; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2578; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(377424004)(13464003)(93886004)(2906002)(110136004)(38730400002)(6246003)(3280700002)(2950100002)(6916009)(74316002)(53936002)(86362001)(7696004)(3660700001)(189998001)(6116002)(53546006)(305945005)(7736002)(3846002)(102836003)(77096006)(54906002)(6506006)(55016002)(106116001)(81166006)(6436002)(25786008)(229853002)(66066001)(6306002)(9686003)(122556002)(4326008)(2900100001)(50986999)(8936002)(76176999)(54356999)(5660300001)(8676002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2578; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 11:41:10.3239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2578 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUyM2K7rm5E67EIg4df+Cwur3jIajFx/Tom i+ezXrBYTN9nYzF1+WMWB1aPcw3v2T0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxoOV89kK tkhWrD40naWB8YFEFyMnh4SAicTtFVNZQWwhgXWMEi2/vLsYuYDsE4wS29/+ZwVxWAR6mSU2 rD/NBJGZziSxeM8Fdriyi7dPsYH0swloSMzfcZcRxBYRsJH4dwGkiJODWWAqk8T3Fj8QW1jA U2LCp8tsEDVeEh/af0LZSRJPrk4C62URUJWY8G8xmM0rkCDx+fM2qGWLWSTO337JApLgFAiU WPjvK1gzo4CYxPdTa5gglolL3HoynwniOQGJJXvOM0PYohIvH/8D+4dRoJdRovn7FxaIhILE q+4GNpCEhEAfs0TfvK1ADgeQ4yvxsjUMwvSXWPQtFqI8X6Lrehc7RNhbovOpMkTnPCaJJ22f 2CBqZCQW7WiFGtnAKvG26xU7xPdSEnevdDJC2DISL+7sZZ3AqDkLyd2zgOYyC2hKrN+lDxFW lJjS/ZB9FjgsBCVOznzCsoCRZRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYGo5uOW3wQ7G l88dDzEKcDAq8fBumHU0Qog1say4MvcQowQHs5II76yWYxFCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MG4xOtM3m/vHl6McBeVO+za5V9jfe8N3JFBF 0u7qd426z4lzLDLf8gh9MGJbtuJKUIuWk7BYeKPqJrk34Qfk2j+G3T/PYKJlHNf9RG++i26y vfCZszOcnPZPurTO9MwP/w+b9mXHL+2zueivE7uHbWfwiS92AuzW0XJlvS9aX53Yf2PT72N8 3kosxRmJhlrMRcWJAK6rA9ApAwAA Archived-At: Cc: "draft-ietf-mmusic-rid@ietf.org" , "mmusic \(mmusic@ietf.org\)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 11:41:16 -0000 Q291bGQgeW91IGVsYWJvcmF0ZSBhIGJpdCB0byBoZWxwIG1lIHVuZGVyc3RhbmQgd2h5IHRoYXQg d291bGQgYmUgbmVlZGVkIGZvciBGTEVYLUZFQyB3aGVuIHVzaW5nIFJlcGFpcmVkUnRwU3RyZWFt SWQ/DQoNCklzIGl0IHRoYXQgeW91IGdldCBleHBsaWNpdCBpbmRpY2F0aW9uIGluIFNEUCwgbGlr ZSAiYT1yaWQ6PHJpZC1pZD4gc2VuZCBwdD08bWVkaWEtZm10Piw8cmVkdW5kYW5jeS1mbXQ+IC4u LiIgd2hlbiB1c2luZyBSdHBTdHJlYW1JZCBmb3IgYm90aCBvcmlnaW5hbCBhbmQgcmVkdW5kYW5j eSBSVFAgc3RyZWFtPw0KDQpJIGd1ZXNzIHRoYXQgdXNlIG9mIFJ0cFN0cmVhbUlkIG9yIFJlcGFp cmVkUnRwU3RyZWFtSWQgb24gUlRQIGxldmVsIChpbiB0aGUgUlRQIGFuZCBSVENQIHBhY2tldHMp IHNob3VsZCBub3QgbWF0dGVyIG11Y2gsIG5laXRoZXIgZm9yIEZMRVgtRkVDIG5vciBSVFgsIGFz IGxvbmcgYXMgaXQgaXMgY2xlYXJseSBkZWZpbmVkIHdoYXQgaXQgbWVhbnM/DQoNCi9Cbw0KKGFz IGluZGl2aWR1YWwpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogScOx YWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+IFNlbnQ6IGRlbiAxMyBt YXJzIDIwMTcgMTE6NDYNCj4gVG86IEJvIEJ1cm1hbiA8Ym8uYnVybWFuQGVyaWNzc29uLmNvbT4N Cj4gQ2M6IG1tdXNpYyAobW11c2ljQGlldGYub3JnKSA8bW11c2ljQGlldGYub3JnPjsgVGF5bG9y IEJyYW5kc3RldHRlciAoZGVhZGJlZWZAZ29vZ2xlLmNvbSkNCj4gPGRlYWRiZWVmQGdvb2dsZS5j b20+OyBkcmFmdC1pZXRmLW1tdXNpYy1yaWRAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbW11c2ljLXNk cC1zaW11bGNhc3RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIEZXOiBbcnRjd2Vi XSBIb3cgdG8gc2lnbmFsIFJUWCBTU1JDcyB3aXRoIHNpbXVsY2FzdA0KPiANCj4gMjAxNy0wMy0x MyAxMDo1NiBHTVQrMDE6MDAgQm8gQnVybWFuIDxiby5idXJtYW5AZXJpY3Nzb24uY29tPjoNCj4g PiBJ4oCZbSBwZXJzb25hbGx5IHNsaWdodGx5IGluY2xpbmVkIHRvIHN1Z2dlc3QgYWx3YXlzIHVz aW5nDQo+ID4gUmVwYWlyZWRSdHBTdHJlYW1JZCBpbiB0aGUgcnR4IHJlZHVuZGFuY3kgUlRQIHN0 cmVhbSB0byByZWxhdGUgaXQgdG8NCj4gPiB0aGUgb3JpZ2luYWwgUlRQIHN0cmVhbSAoc2Vjb25k IOKAnGlm4oCdIGJ1bGxldCBhYm92ZSksIG1haW5seSB0byBhdm9pZA0KPiA+IGhhdmluZyB0byBj aGFuZ2UgaW50ZXJwcmV0YXRpb24gb2YgUnRwU3RyZWFtSWQgYmFzZWQgb24gdGhlIG9wdGlvbmFs DQo+ID4gcHJlc2VuY2Ugb2YgUmVwYWlyZWRSdHBTdHJlYW1JZC4gSeKAmW0gb2YgY291cnNlIG9w ZW4gdG8gYXJndW1lbnRzLg0KPiANCj4gUGVyc29uYWxseSBJIHByZWZlciBvcHRpb24gQSAodXNl IGEgc2hhcmVkIFJ0cFN0cmVhbUlkKS4gTXkgcmF0aW9uYWxlOg0KPiANCj4gSWYgd2UgZ28gd2l0 aCBvcHRpb24gQiAoUmVwYWlyZWRSdHBTdHJlYW1JZCkgdGhlbiB3ZSB3aWxsIG5lZWQgc29tZXRo aW5nIHNpbWlsYXIgd2hlbiBpdCBjb21lcyB0byBGTEVYLUZFQyBbKl06DQo+IA0KPiAgICAgICAg IHY9MA0KPiAgICAgICAgIG89YWxpIDExMjIzMzQ0NTUgMTEyMjMzNDQ2NiBJTiBJUDQgZmVjLmV4 YW1wbGUuY29tDQo+ICAgICAgICAgcz0yLUQgUGFyaXR5IEZFQyB3aXRoIG5vIGluIGJhbmQgc2ln bmFsbGluZyBFeGFtcGxlDQo+ICAgICAgICAgdD0wIDANCj4gICAgICAgICBtPXZpZGVvIDMwMDAw IFJUUC9BVlAgMTAwIDExMA0KPiAgICAgICAgIGM9SU4gSVA0IDIzMy4yNTIuMC4xLzEyNw0KPiAg ICAgICAgIGE9cnRwbWFwOjEwMCBNUDJULzkwMDAwDQo+ICAgICAgICAgYT1ydHBtYXA6MTEwIGZs ZXhmZWMvOTAwMDANCj4gICAgICAgICBhPWZtdHA6MTEwIEw6NTsgRDoxMDsgVG9QOjI7IHJlcGFp ci13aW5kb3c6MjAwMDAwDQo+ICAgICAgICAgYT1zc3JjOjEyMzQNCj4gICAgICAgICBhPXNzcmM6 MjM0NQ0KPiAgICAgICAgIGE9c3NyYy1ncm91cDpGRUMtRlIgMTIzNCAyMzQ1DQo+IA0KPiANCj4g Rm9yIG1lIGl0J3MgdG8gdGhpbmsgaW4gUnRwU3RyZWFtSWQgYXMgInRoZSBpZGVudGlmaWNhdG9y IG9mIGEgbWVkaWEgc3RyZWFtIGFuZCwgb3B0aW9uYWxseSwgYWxzbyB0aGUgaWRlbnRpZmljYXRv ciBvZiB0aGUgUlRYDQo+IHN0cmVhbSBhbmQgRkVDIHN0cmVhbSBvZiBzdWNoIGEgbWVkaWEgc3Ry ZWFtIi4NCj4gDQo+IA0KPiANCj4gWypdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZS0wMw0KPiANCj4gDQo+IC0tDQo+IEnD sWFraSBCYXogQ2FzdGlsbG8NCj4gPGliY0BhbGlheC5uZXQ+DQo= From nobody Mon Mar 13 04:46:03 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 99E84129578 for ; Mon, 13 Mar 2017 04:46:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 2y1sWGN-zlXt for ; Mon, 13 Mar 2017 04:46:00 -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 A0D67127A90 for ; Mon, 13 Mar 2017 04:46:00 -0700 (PDT) X-AuditID: c1b4fb25-e49bd98000004cad-66-58c686589f87 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id A2.E6.19629.85686C85; Mon, 13 Mar 2017 12:45:29 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 12:45:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gSMXv6qFp3VgYbaxlDkGn4lXcXAAuubHA+JkAnqCTNA=; b=Or+CP7kLSCCZOpW4DdLwfijXmcxKsTGVvmOLL57QzNUS36GHS7v4n9KHFnFqOgJecdyT38/eNXP5iIHZbb7sF2AB3dQ3XhileNGvwfRgIg3srhfIUyms69U58ObxR1RlkNUhvevcoTDengRPeGPJJfBrMksJ87UAP6ABA6bmu4k= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2578.eurprd07.prod.outlook.com (10.173.92.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 11:45:26 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 11:45:26 +0000 From: Bo Burman To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 Thread-Index: AQHSgmCKfjnKZKJ0EUCxPpj/B3NcoKGCNpMAgAFnEYCADzu70A== Date: Mon, 13 Mar 2017 11:45:26 +0000 Message-ID: References: <01a352cf-9adc-18bb-3cd0-ce82d39e5490@cisco.com> <4bb9cede-7f95-8a8e-5206-5139c5755e32@comcast.net> In-Reply-To: <4bb9cede-7f95-8a8e-5206-5139c5755e32@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: comcast.net; dkim=none (message not signed) header.d=none;comcast.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2578; 7:EtZ0qQUANH/3UjTefBhJruyLl3mjsiWTYmT7MkvA8orUDwVnWKKj5RG908DJxmDYP+yJe7qh+e2EU5WAyhI3cjVxhfaGEWBH802gLGnSaSWgyqADX03QNU1Ujfp+bYGAGNg84xIC88fRwPjakePzoT4ZTzPmUMRryioeC0v0oxA0vXfJ+Cta/PPLNb2+N1daVTb2cKGM7CIEFR7w+rU9Oq5sXJoQgIOWwcDI6UqvRYnWpe//CCrl7wcza32XRAByWxbHV37OB+YNHkLEjW6HRJIZxff8/udYSU/Do3NJo9zMOKnPYqyyKQz0b7tVn18dPi4d8Q089hK5+99+jgn2uw== x-ms-office365-filtering-correlation-id: 488b8ded-763d-44db-21fc-08d46a067141 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2578; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM5PR0701MB2578; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2578; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(377454003)(377424004)(13464003)(24454002)(2906002)(38730400002)(6246003)(230783001)(3280700002)(2950100002)(74316002)(53936002)(86362001)(7696004)(3660700001)(189998001)(6116002)(53546006)(305945005)(7736002)(3846002)(102836003)(77096006)(6506006)(55016002)(106116001)(81166006)(6436002)(8666007)(25786008)(229853002)(66066001)(6306002)(9686003)(122556002)(2501003)(2900100001)(50986999)(8936002)(76176999)(54356999)(5660300001)(8676002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2578; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 11:45:26.6472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2578 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KZGbHdUjey7ViEwd+dbBZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4cWsZc8Ea/ornf36wNjD+4Oti5OSQEDCR eNvQztbFyMUhJLCOUeLVjk4o5wSjRO+5nawgVSwCvcwSu/5nQCSmM0k82fGbCa5q3oNXTCBV bAIaEvN33GUEsUUEgiTmNn4BiwsLOEh8uLOFFSLuKPH6TwMLhO0kMbmpgwlig6rE2js7wHp5 BRIkTl1dzAixYAejxI2OOUANHBycAvYSU+YIg9QwCohJfD+1BqyXWUBc4taT+UwQ/whILNlz nhnCFpV4+fgfK8gcRoGJjBKX79+HSihIvOpuAPtTQqCPWaJ9bzMLRMJX4nTjYnaQZRIC/hKL vsVChPMlDl/fAbXASmLT7hZWiN55wKBo+8QGkZCRWLSjFWpoI6vEyWsX2SHel5K4e6WTEcKW kXhxZy8ryAJmAU2J9bv0JzBqzELyxCyEDERYUWJK90P2WeBwEZQ4OfMJywJGllWMosWpxUm5 6UbGeqlFmcnFxfl5enmpJZsYgWnj4JbfqjsYL79xPMQowMGoxMO7YdbRCCHWxLLiytxDjBIc zEoivC4zgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUw ik3O0kh51tUhPcPKUZppm5NR/Ka0dBaev0kK7/yfvn1mHHJvm0xt3MXeq9v6F5oWxmm7yWxY xXljqe6l5Ud+HuvnmLKJKXXWswOGFc9nFChqxiklXbL7J1e7rCy27Jvhg/Omn67mLI9cdHCm wQFpYADa2XzJCKiYubfpbO9r1sR9Buapm2qVWIozEg21mIuKEwFagNL5FwMAAA== Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 11:46:02 -0000 QWdyZWUgdGhhdCBleGFtcGxlcyBpbiA2LjYuMSBhcmUgd3Jvbmc7IHdpbGwgYmUgY29ycmVjdGVk IGluIC0wOC4NCg0KL0JvDQooYXMgaW5kaXZpZHVhbCkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFBhdWwgS3l6aXZhdA0KPiBTZW50OiBkZW4gMyBtYXJzIDIwMTcgMjA6MDYN Cj4gVG86IG1tdXNpY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW01NVVNJQ10gV0dMQyBvbiBk cmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA3DQo+IA0KPiBPbiAzLzIvMTcgNDo0MCBQ TSwgScOxYWtpIEJheiBDYXN0aWxsbyB3cm90ZToNCj4gPiAyMDE3LTAyLTA5IDA6MDkgR01UKzAx OjAwIEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPjoNCj4gPj4gVGhpcyBp cyB0byBhbm5vdW5jZSBhIDIgd2VlayBXR0xDIG9uIHRoZSAgZHJhZnQ6DQo+ID4+DQo+ID4+ICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0 LTA3LnR4dA0KPiA+DQo+ID4gSGksIHRoZSBkcmFmdCBzaG93cyBhcyBleGFtcGxlOg0KPiA+DQo+ ID4gICAgYT1yaWQ6MSBwdD05NyBzZW5kDQo+ID4gICAgYT1yaWQ6MiBwdD05OCBzZW5kDQo+ID4g ICAgYT1yaWQ6MyBwdD05NyByZWN2DQo+ID4NCj4gPiBidXQgYWNjb3JkaW5nIHRvIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1yaWQtMDkNCj4gPiBpdCBzZWVt cyB0aGF0ICJkaXJlY3Rpb24iIChzZW5kL3JlY3YpIHNob3VsZCBiZSBwbGFjZWQgKmJlZm9yZSoN Cj4gPiAicHQ9eHgiOg0KPiA+DQo+ID4gYT1yaWQ6PHJpZC1pZD4gPGRpcmVjdGlvbj4gW3B0PTxm bXQtbGlzdD47XTxyZXN0cmljdGlvbj49PHZhbHVlPi4uLg0KPiA+DQo+ID4gVGhlIEFCTkYgZ3Jh bW1hciBjb25maXJtcyB0aGlzOg0KPiA+DQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbW11c2ljLXJpZC0wOSNzZWN0aW9uLTEwDQo+ID4NCj4gPiBTbyBtYXkgYmUg dGhlIGV4YW1wbGUgU0RQcyBpbiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA3IGFy ZSB3cm9uZz8NCj4gDQo+IEl0IGFwcGVhcnMgdGhhdCBhbGwgdGhlIGV4YW1wbGVzIG9mIHRoaXMg aW4gc2VjdGlvbiA2LjYuMSBhcmUgd3JvbmcsIHdoaWxlIHRoZSBleGFtcGxlcyBlbHNld2hlcmUg YXJlIG9rLg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4g bW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW11c2ljDQo= From nobody Mon Mar 13 04:49: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 BD6DD129574 for ; Mon, 13 Mar 2017 04:49:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 svzSnj1zc5HK for ; Mon, 13 Mar 2017 04:49:58 -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 15C6C129578 for ; Mon, 13 Mar 2017 04:49:57 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id l37so101892501wrc.1 for ; Mon, 13 Mar 2017 04:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0LITCIF4L3hoXuME7MRQJQzaNrwrrJv1c/5+yOyh0Po=; b=D8JhpAPLE8fJ5XElVMMs4RGiRFMN89ioNU669beqikv4Fl8pQMhjNywmQM7ws71qr5 LYOOB7OZSTpBx+/1kvEvnwvYOTsAJbyxj/uUFGX/vKgF/VM40MkQC/sFuYNDHmuu3Eql l8ulM21P33s6nAHtF3yLmx8QaqS778Ua1ESh02p3EwhY/xA1Dm8FMwba9nO6rzcEjPCp v9yqafxPpxYWr/Xkojf1RT75hw3kl64W+db9bkIAUp2J5j4VfA3TKmcndfpoy2O9gIUj KWX7OQrPPXkCSx6gLu1Rh7ePbSgUVgrNBnzJuJ9Hz0wPoJQ1mI7g07eIETn4I/+nlkNC WgRQ== 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=0LITCIF4L3hoXuME7MRQJQzaNrwrrJv1c/5+yOyh0Po=; b=rIu0X41kHaPYsjXTyiNvXxANbz1vuMYopVy0vACuCXpJReQ/SiYj7VnFRJI+clnRU9 2h9HnYzuL8GS+TbR3t8gFCgdP013dCRqu8U8EWr//yNnfwHr10FVaU7fY+Yc7O0tF9dr OQAyA64Hejwu+Wf/CxiRzkr89mt+GR7CzwFqoAPi5wL3ZAG5nWu64ohAcxvqrT4mwRuS XwCzfj6ubbWNWuWiI2hnUmqWvAuPm+K1/0cjo3/c129zkkEFbiZa2OZfbHEjeU7Z3GQR f2eSaOecG6fm/hcDZAnwUlIgSmDJB/94fckbL54kOvmH+zYAYZUwuJZKQ8xJ19n56JGW vQbQ== X-Gm-Message-State: AMke39kXzFKo3aWgUWW4CUPJXXW9sWdRHYFPUJ4jrOvplpZNaMmSm4bn0mjT7TqIpZoRiDSBemgVKgFuGFbiwQ== X-Received: by 10.223.152.83 with SMTP id v77mr27652336wrb.109.1489405795588; Mon, 13 Mar 2017 04:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 13 Mar 2017 04:49:35 -0700 (PDT) In-Reply-To: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 13 Mar 2017 12:49:35 +0100 Message-ID: To: Bo Burman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-mmusic-rid@ietf.org" , "mmusic \(mmusic@ietf.org\)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 11:49:58 -0000 2017-03-13 12:41 GMT+01:00 Bo Burman : > Could you elaborate a bit to help me understand why that would be needed = for FLEX-FEC when using RepairedRtpStreamId? I just meant that, in case of option A above, FLEX-FEC would require the same as RTX (when RID is in use and ssrcs are therefore not signaled). > I guess that use of RtpStreamId or RepairedRtpStreamId on RTP level (in t= he RTP and RTCP packets) should not matter much, neither for FLEX-FEC nor R= TX, as long as it is clearly defined what it means? I'm not against it. It's just that this requires a new draft about RID and "complementary streams" (or include it into existing ones). --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 13 06:42: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 D0F62128824; Mon, 13 Mar 2017 06:42: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 m-gByyDDYYox; Mon, 13 Mar 2017 06:42:09 -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 01823129622; Mon, 13 Mar 2017 06:42:08 -0700 (PDT) X-AuditID: c1b4fb3a-9b1d39800000539f-4d-58c6a1af5a2c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 05.97.21407.FA1A6C85; Mon, 13 Mar 2017 14:42:07 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 14:41:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LG8J6ff7IaehkzCyGjcgcZgtnfeVnHI0VTYysipXXxg=; b=A9xRTizPTI2/FqkZxwHC+Se3N9hU7V/LDcnLg+lJQlYm+KByCamswItuoeD+ae+I8obSBHvLm6usGh/TZreEMGjMql4n6MnfZZJUb2zgWMFTUxvUPN/W5Ensv+IDlK+Z8VjXNasGnP3kE542yX4WX3mVIqFJIiyU+0PEY+Ioniw= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 13:41:14 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 13:41:14 +0000 From: Bo Burman To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast Thread-Index: AQHSmSRXaXEak/rxUUuXLqrZPXzB4qGOeTSAgAADuwCAADM6gIAAAMcAgAAFxYCAA7fx4IAALRSAgAANzbCAAAP1gIAAG7mw Date: Mon, 13 Mar 2017 13:41:14 +0000 Message-ID: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: aliax.net; dkim=none (message not signed) header.d=none;aliax.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2577; 7:LrIHeO77pjA809aonfVcXunTMLZsG5x1ivzOCybEOGPyOhTfc5oSWHnrdcJJUt1lwxoKlhGcl417Upg7ZhGp97HJ+XIglcRW2qI833mURmia7s+Xb7ju9XHjFNuFqqIV4+Sm18sb+9Br0T7sGY4F424sgTi4wFAbzLEyh/FmLYEeDC65ur/2C1cKBLlGm8aujTqBEgL6R9114FYk5RIFbYcsHYhmh2VB2A2ssigyAS3wqiBrAK8fNfl6afUPUN+W8T0fFDfAwinR56M7ptbN0e4/ASZmL+bh37WH9ZiwfIMRL5sCKg3z0FyQgaG4hQyMtsvCAY4uKw8rlzkmtgYziA== x-ms-office365-filtering-correlation-id: e164949e-39d8-4c37-038e-08d46a169e5f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2577; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:AM5PR0701MB2577; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2577; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(13464003)(377424004)(229853002)(6116002)(122556002)(3846002)(102836003)(77096006)(189998001)(6436002)(76176999)(54356999)(2900100001)(106116001)(6506006)(50986999)(8676002)(5660300001)(305945005)(74316002)(81166006)(7736002)(2906002)(53936002)(8936002)(66066001)(4326008)(93886004)(33656002)(9686003)(6916009)(110136004)(38730400002)(3280700002)(3660700001)(25786008)(2950100002)(86362001)(7696004)(6246003)(55016002)(54906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2577; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 13:41:14.3773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2577 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUiTURTGu+/H9iourlPzZAo1Ej9ATYtYKqUQYV9mULTsy6Uvas4pe1Uy KiaZ0cRatTI3mFaGabKFhA7RwuFHhamgEpUuxpaaaYZFYsXI7V3Rf797n/Occ57LZUhxLR3C 5CtLWJVSrpAIfKk6WUdEjPlev2xTuzZIOvrITktvmE2EdFo/Q0lrnyVLbzc5qBQ6bUi9IExr aCtNa2xcJjLITN/kHFaRX8aq4rZn+ebpbB+J4inR2TtLWI0sIg3yYQBvgU6DRqhBvowYmxD8 6LYj/vACwcLEFOk+ULiGBMdgM80rtQS81y0K/pWNTRlodzMBjoR6yyRycyBOBtfIiNDNJL5N wFJlupsD8G7QLo4K+Jo98PXKspeVYByxerwUDoc6+0PSzSKcBYuDExQ/rIeG9orfK00Zxgcf BJtF5a5BeA0svWol+FnB8M5ZT/DhMDR2DZM8B8Enh8uTAOEaBJeWvlO8sB5mq9WeNICvkfC4 wUbzwn4YNo4jng+AdVbtNRRB/81hwr0E4EQwDp7gvUYCujVOrzcU7lsue5vOU9D3xoD4+CEw OXbVy6EwM9FNa1GU/r/N9St9SRwF5s44/noD6KrtQr3nMfzhZZ2TakBUCwriWI4rzE1IiGVV +dkcV6SMVbIlbWjlu/Q8/ZVoQT3TqVaEGSTxEz3R98nEtLyMKy+0ImBISaBolbFfJhblyMvP saqiU6pSBctZ0TqGkgSLtjZ/OCLGufIStoBli1nVX5VgfELU6OLzzvNJh46ZBkKyb8W2pm7s KdgsEMU7I3p3sIpYzbg5c05hyE1xPCgKOmyUf6vSsulrZ0tGhk5el1X17fOfCzRXZB8vDosW ZuyKiXOdrvQbaNJNBOOozr0tYXdNleXzF74E6Fxn3n7uiHy9mvqpqN15NIkIxbYu/20FmtDe cIWE4vLk8dGkipP/AWkEB1sqAwAA Archived-At: Cc: "draft-ietf-mmusic-rid@ietf.org" , "mmusic \(mmusic@ietf.org\)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 13:42:11 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxv IFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj4gU2VudDogZGVuIDEzIG1hcnMgMjAxNyAxMjo1MA0K PiANCj4gMjAxNy0wMy0xMyAxMjo0MSBHTVQrMDE6MDAgQm8gQnVybWFuIDxiby5idXJtYW5AZXJp Y3Nzb24uY29tPjoNCj4gPiBDb3VsZCB5b3UgZWxhYm9yYXRlIGEgYml0IHRvIGhlbHAgbWUgdW5k ZXJzdGFuZCB3aHkgdGhhdCB3b3VsZCBiZSBuZWVkZWQgZm9yIEZMRVgtRkVDIHdoZW4gdXNpbmcN Cj4gUmVwYWlyZWRSdHBTdHJlYW1JZD8NCj4gDQo+IEkganVzdCBtZWFudCB0aGF0LCBpbiBjYXNl IG9mIG9wdGlvbiBBIGFib3ZlLCBGTEVYLUZFQyB3b3VsZCByZXF1aXJlIHRoZSBzYW1lIGFzIFJU WCAod2hlbiBSSUQgaXMgaW4gdXNlIGFuZCBzc3JjcyBhcmUNCj4gdGhlcmVmb3JlIG5vdCBzaWdu YWxlZCkuDQpbQm9CXSBPSw0KDQo+IA0KPiANCj4gPiBJIGd1ZXNzIHRoYXQgdXNlIG9mIFJ0cFN0 cmVhbUlkIG9yIFJlcGFpcmVkUnRwU3RyZWFtSWQgb24gUlRQIGxldmVsIChpbiB0aGUgUlRQIGFu ZCBSVENQIHBhY2tldHMpIHNob3VsZCBub3QgbWF0dGVyDQo+IG11Y2gsIG5laXRoZXIgZm9yIEZM RVgtRkVDIG5vciBSVFgsIGFzIGxvbmcgYXMgaXQgaXMgY2xlYXJseSBkZWZpbmVkIHdoYXQgaXQg bWVhbnM/DQo+IA0KPiBJJ20gbm90IGFnYWluc3QgaXQuIEl0J3MganVzdCB0aGF0IHRoaXMgcmVx dWlyZXMgYSBuZXcgZHJhZnQgYWJvdXQgUklEIGFuZCAiY29tcGxlbWVudGFyeSBzdHJlYW1zIiAo b3IgaW5jbHVkZSBpdCBpbnRvDQo+IGV4aXN0aW5nIG9uZXMpLg0KW0JvQl0gVXNhZ2Ugb2YgUmVw YWlyZWRSdHBTdHJlYW1JZCBhbmQgUnRwU3RyZWFtSWQgYXJlIGFscmVhZHkgZGVmaW5lZCBvbiBS VFAgbGV2ZWwgYnkgLWF2dGV4dC1yaWQuIElmIHdlIGhhdmUgcHJlZmVyZW5jZXMgb24gaG93IHRv IGJlc3QgdXNlIHRoZW0gd2l0aCByZWR1bmRhbmN5IFJUUCBzdHJlYW1zIGluIGdlbmVyYWwsIEkg c3VnZ2VzdCB3ZSBhZGQgdGV4dCB0byAtbW11c2ljLXJpZCBhYm91dCBpdC4gVGhpcyB3b3VsZCBi ZSByZWdhcmRsZXNzIGlmIHdlIGdvIGZvciBvcHRpb24gQSBvciBCLCBidXQgZGVjaWRlZCBvbmNl IGFuZCBmb3IgYWxsLCB0aHVzIGFwcGxpY2FibGUgdG8gUkZDIDQ1ODggcnR4IGFuZCBGTEVYLUZF QyBhbGlrZS4NCg0KL0JvDQooYXMgaW5kaXZpZHVhbCkNCg0KPiANCj4gDQo+IC0tDQo+IEnDsWFr aSBCYXogQ2FzdGlsbG8NCj4gPGliY0BhbGlheC5uZXQ+DQo= From nobody Mon Mar 13 06:43: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 54169129606 for ; Mon, 13 Mar 2017 06:43:31 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 qNj0iznw1lCy for ; Mon, 13 Mar 2017 06:43:30 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 B5B0C129448 for ; Mon, 13 Mar 2017 06:43:29 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t189so40255123wmt.1 for ; Mon, 13 Mar 2017 06:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OWC/ogtelukb7h803Ntsd8LXQn0pYU+OvtnMjtQVAko=; b=S6egRA6f6R40Ukt61LZTrfYTUfLQ4tQFK5qnldfAlQc0tJ8N04VKYywQr5/DwZ73lj fZL+lGex30q/ECvUKQTZoiaRPr8S2bP6loOLoe40ZXpOcCDCgI3k15vNV8A+ElQOQxey WjE4pznwp6lVmsbVoVVQh/roq/vtblOrAeXLXVKYHrdEoOzHeF5THEZxorvE4m0JKgIl Pvjre/pn/4UEeERsyvF2eeT8hOymC7tGIRLYE5waeAoklYCZjo4KQgvL6vD2W2Nn9zdJ Ijf5bGU+4fADbQ4KD0PbQtXU2W/+MZHqpwieJHbIicJGH7ZBzT6fQk0vvtjRDVfyJkIw D8Ig== 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=OWC/ogtelukb7h803Ntsd8LXQn0pYU+OvtnMjtQVAko=; b=Pf7oDm07lkW9W3ncS2/0i+9oVdlC116Li2noIKelT3zeSL67fIoT51ZXFo9VtNnXMu XpmLjQZJefUl24tFQvMF1Nn50bVaxTEMrutPf+FJLuPhXPDg90ggF9OLr+6e5nuQbYvq hg+ubhyIY4ttytyJKTru79W/Pz2p46ZpHesByxTj37tisyuj/6H70wOaWWwgCpvU+aFR Z/fO+YSOnoV9V/RvqMSHuxbvxcoSjfP46tFVoRoKqtSZAzuqMoj5DPIwu9LeP/Ce6o5q tGLQ/z4NRnKxCSuQbKTTbSQCCK7iodiFHTgHXdd58+DvTtFbp1cH0+L8j684V8ZwagHJ BnYg== X-Gm-Message-State: AFeK/H0yYxkUc1BVgdka+sL4vAHuhi7DIIcrAQyBW/ZEPs4KO0xJEvX487+9WtD4iOjPY9uAtNqQpmtpHg/rNw== X-Received: by 10.28.182.7 with SMTP id g7mr10638143wmf.108.1489412608200; Mon, 13 Mar 2017 06:43:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 13 Mar 2017 06:43:07 -0700 (PDT) In-Reply-To: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 13 Mar 2017 14:43:07 +0100 Message-ID: To: Bo Burman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "draft-ietf-mmusic-rid@ietf.org" , "mmusic \(mmusic@ietf.org\)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 13:43:31 -0000 2017-03-13 14:41 GMT+01:00 Bo Burman : > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already defined on= RTP level by -avtext-rid. If we have preferences on how to best use them w= ith redundancy RTP streams in general, I suggest we add text to -mmusic-rid= about it. This would be regardless if we go for option A or B, but decided= once and for all, thus applicable to RFC 4588 rtx and FLEX-FEC alike. Agreed. --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 13 07:49: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 001A21296AC for ; Mon, 13 Mar 2017 07:49: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 lOgXC1OALKZ9 for ; Mon, 13 Mar 2017 07:49: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 5A827129517 for ; Mon, 13 Mar 2017 07:49:30 -0700 (PDT) X-AuditID: c1b4fb25-e49bd98000004cad-25-58c6b1788be5 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 90.13.19629.871B6C85; Mon, 13 Mar 2017 15:49:28 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 15:48:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zCIW7Edpju4uS2+rol9OiGrolw+M12tBwxz2LuRnxlg=; b=M4NibfrMdX7HzOYEB45vVRM342xpknHIbmGWALJhy79YNlEVLxYfnvGsTk1q01M8jRfojMyXZwGV1L1RZKBOpZ6xcHv2GubH9njx2QPKguwn20mqYM2mGwX086QRlsDDp4QS7wKNfcqIKnJgXui+/tzJQVABH/cUbeiF2L1mNbE= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2578.eurprd07.prod.outlook.com (10.173.92.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.8; Mon, 13 Mar 2017 14:48:53 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0961.021; Mon, 13 Mar 2017 14:48:53 +0000 From: Bo Burman To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 Thread-Index: AQHSlDbJfjnKZKJ0EUCxPpj/B3NcoKGDem0AgA89gDA= Date: Mon, 13 Mar 2017 14:48:53 +0000 Message-ID: References: <87mvd2fj5h.fsf@hobgoblin.ariadne.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.84] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2578; 7:sYN1Fr/EHo9+THMZTu7uHocbrn0Y8tSG6SoEuelsPIOW6XHmXA+JtqmQfjC8Od5mnzmWpZWTNElKN3gEbYX8wtvUqEa71nzUqn1bR941qbO3Y2irVB5HnW5E1QUmKGNXFAQVw/5DAjm4mtNL7V0EWJI/Pr2AlPD53H1jK8IlTKJWKUnLpYqjgoIVpAaiDJRrYl6LTV7RXY2QzJdxxxNRtVaPAtWawreILeVcn0XlmvsdVry2GIkP1GvGvWgOZ/DBOpr4jAILj4vwRwEm4RQNnhW3Ib9fpUT4Mk/vHoodkhews0/5oJazCMiCcOHXPAYBdSvDkcBALB01Ndg3sbQ65w== x-ms-office365-filtering-correlation-id: fbc636b0-ea7e-43f4-297e-08d46a2011cc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2578; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:AM5PR0701MB2578; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2578; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(377454003)(24454002)(2171002)(38730400002)(2906002)(230783001)(6246003)(3280700002)(2950100002)(74316002)(53936002)(86362001)(7696004)(3660700001)(189998001)(6116002)(53546006)(305945005)(7736002)(3846002)(102836003)(77096006)(99286003)(55016002)(6506006)(106116001)(81166006)(6436002)(25786008)(229853002)(66066001)(6306002)(9686003)(122556002)(2501003)(2900100001)(50986999)(8936002)(76176999)(54356999)(5660300001)(8676002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2578; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 14:48:53.4911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2578 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUyM2K7lm7FxmMRBnu7jCymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuje9EG9oJ56hXX/9xma2Cco9bFyMEhIWAi sW+naBcjJ4eQwDpGiePz3LoYuYDsE4wSN8+8YwNxWAR6mSX2L33HCFE1nUmio1sLwgapuuwA YrMJaEjM33EXrEZEwFfi2ePbbCC2sICDxIc7W1gh4o4Sr/80sIAsFhGwklh8wB0kzCKgKtE/ dztYCa9AgsSzKyAlIOMzJM7c6AOzOYHGbD93D2w8o4CYxPdTa5hAbGYBcYlbT+aD2RICAhJL 9pxnhrBFJV4+/scKcj+jwGRGiY75V1ghEgoSr7ob2CDsPmaJFb8YIWxfib1rX7NAAsVfYtG3 WIhwvsT9xvVQJVoSHUdmMYHMlBCYxyTxpO0T1BwZiUU7WtkgEt9YJLrbfzBDPC8lcfdKJyOE LSPx4s5eVpAFzAKaEut36U9g1JiF5IdZCBmIsKLElO6H7LPAwSIocXLmE5YFjCyrGEWLU4uT ctONjPVSizKTi4vz8/TyUks2MQKTxcEtv1V3MF5+43iIUYCDUYmHd8OsoxFCrIllxZW5hxgl OJiVRHhdZgKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRq YPRv08xsldGyW3xGavqlRRHtCT8NgywOxNbNPPzNOqEwom3x9qyHvZE8h/JnOXoYN4bpPt0Z Ezkn7+THa31xh60OpLCduZjH93qJLU+MprCDmB7LFIm4hzsNt6lfvN114oHEzb+cl2VXm/Fe S7055Uthck1glfWDKWkzdJMsv6ht/m+ynNHFRYmlOCPRUIu5qDgRAG6f8xMSAwAA Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 14:49:32 -0000 UGF1bCwgdGhhbmtzIGZvciBnb29kIGNvbW1lbnRzLA0KDQpQbGVhc2Ugc2VlIG15IHJlc3BvbnNl cyBpbmxpbmUuDQoNCi9Cbw0KKGFzIGluZGl2aWR1YWwpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNCj4gU2VudDogZGVuIDMgbWFycyAyMDE3IDIwOjA4 DQo+IFRvOiBtbXVzaWNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIFdHTEMgb24g ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wNw0KPiANCj4gRGFsZSwNCj4gDQo+IE9u IDMvMy8xNyAxMDo1NiBBTSwgRGFsZSBSLiBXb3JsZXkgd3JvdGU6DQo+ID4gScOxYWtpIEJheiBD YXN0aWxsbyA8aWJjQGFsaWF4Lm5ldD4gd3JpdGVzOg0KPiA+Pj4gYnV0IGFjY29yZGluZyB0bw0K PiA+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXJpZC0w OQ0KPiA+Pj4gaXQgc2VlbXMgdGhhdCAiZGlyZWN0aW9uIiAoc2VuZC9yZWN2KSBzaG91bGQgYmUg cGxhY2VkICpiZWZvcmUqDQo+ID4+PiAicHQ9eHgiOg0KPiA+Pj4NCj4gPj4+IGE9cmlkOjxyaWQt aWQ+IDxkaXJlY3Rpb24+IFtwdD08Zm10LWxpc3Q+O108cmVzdHJpY3Rpb24+PTx2YWx1ZT4uLi4N Cj4gPj4NCj4gPj4gSW4gZmFjdCwgcHQ9eHggc2VlbXMgdG8gYmUgeWV0IGFub3RoZXIgInBhcmFt Ii4NCj4gPg0KPiA+IFRoYXQgcHVycG9ydGVkIEJORiBpcyByZWFsbHkgYml6YXJyZSwgc2luY2Ug aXQgZ2VuZXJhdGVzIHRoZSBjbGVhcmx5DQo+ID4gaW5jb3JyZWN0IGZvcm06DQo+IA0KPiBJSVVD IHlvdSBhcmUgY29tbWVudGluZyBvbiB0aGUgQUJORiBpbiBkcmFmdC1pZXRmLW1tdXNpYy1yaWQt MDgsIG5vdCBpbiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA3LCByaWdodD8NCj4g DQo+ID4gICAgYT1yaWQ6PHJpZC1pZD4gPGRpcmVjdGlvbj4NCj4gPiA8cmVzdHJpY3Rpb24+PTx2 YWx1ZT48cmVzdHJpY3Rpb24+PTx2YWx1ZT4NCj4gDQo+IEknbSBub3Qgc2VlaW5nIGhvdyB0aGUg QUJORiBnZW5lcmF0ZXMgdGhhdC4NCj4gDQo+ID4gQSBjb3JyZWN0IGRlc2NyaXB0aW9uIGlzOg0K PiA+DQo+ID4gICAgYT1yaWQ6PHJpZC1pZD4gPGRpcmVjdGlvbj4gKCBwdD08Zm10LWxpc3Q+IHwg PHJlc3RyaWN0aW9uPj08dmFsdWU+DQo+ID4gKSAqKCA7IDxyZXN0cmljdGlvbj49PHZhbHVlPiAp DQo+IA0KPiBJU1RNIHRoZSBBQk5GIGluIHRoZSBkcmFmdCBpcyBlcXVpdmFsZW50IHRvIHdoYXQg eW91IGhhdmUgd3JpdHRlbi4NCj4gKFRob3VnaCB5b3VycyBpcyBjbGVhcmVyLikNCj4gDQo+IE1l YW53aGlsZSwgdGhlIEFCTkYgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wNyBk b2VzIHNvbWUgc21hbGwgcHJvYmxlbXM6DQo+IA0KPiAxKSBpdCBhbGxvd3MgZWl0aGVyIG9uZSBv ciB0d28gJ3NjLXN0ci1saXN0J3MuIEkgcHJlc3VtZSB0aGlzIGlzIHNvIHlvdSBjYW4gaGF2ZSBi b3RoIHNlbmQgYW5kIHJlY3YgbGlzdHMsIGJ1dCBpdCBhbHNvIGFsbG93cyB0d28NCj4gc2VuZCBs aXN0cyBvciB0d28gcmVjdiBsaXN0cy4NCltCb0JdIFRoYXQgaXMgdG8gYWxsb3cgZm9yIGhhdmlu ZyBib3RoIHNlbmQgYW5kIHJlY2VpdmUgZGlyZWN0aW9ucyBvbiB0aGUgc2FtZSBsaW5lLCBiZWNh dXNlIHVzZSBvZiBtdWx0aXBsZSBsaW5lcyBhcmUgbm90IGRlZmluZWQgKHNlY3Rpb24gNi4yIHNh eXMgIlRoZSBtZWFuaW5nIG9mIGluY2x1ZGluZyBtdWx0aXBsZSAiYT1zaW11bGNhc3QiIGxpbmVz IGluIGEgc2luZ2xlIFNEUCBtZWRpYSBkZXNjcmlwdGlvbiBpcyB1bmRlZmluZWQsIE1VU1QgTk9U IGJlIHVzZWQgYnkgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgYW55 IGFkZGl0aW9uYWwgJ2E9c2ltdWxjYXN0JyBsaW5lcyBiZXlvbmQgdGhlIGZpcnN0IGluIGEgbWVk aWEgZGVzY3JpcHRpb24gTVVTVCBiZSBpZ25vcmVkIGlmIHJlY2VpdmVkIikuIFRoZSBjdXJyZW50 IEFCTkYgdGh1cyBhbGxvd3MgbGlzdGluZyB0aGUgc2FtZSBkaXJlY3Rpb24gdHdpY2UsIGJ1dCB0 aGlzIGlzIGV4cGxpY2l0bHkgZGlzYWxsb3dlZCBieSB0ZXh0IGluIHNlY3Rpb24gNi4yICgiZWFj aCBkaXJlY3Rpb24gTVVTVCBOT1Qgb2NjdXIgbW9yZSB0aGFuIG9uY2Ugb24gdGhlIHNhbWUgbGlu ZSIpLg0KDQo+IA0KPiAyKSBpdCByZWZlcmVuY2VzIHJpZC1pZGVudGlmaWVyIGZyb20gZHJhZnQt aWV0Zi1tbXVzaWMtcmlkLTA4LCBidXQgdGhhdCBpc24ndCBkZWZpbmVkIHRoZXJlLiBJIGd1ZXNz IGl0IG1lYW5zIHRvIHJlZmVyZW5jZSByaWQtDQo+IGlkLg0KW0JvQl0gWWVzLCB0aGlzIHNob3Vs ZCBiZSBhbGlnbmVkOyB0byBiZSBpbmNsdWRlZCBpbiAtMDguDQoNCj4gDQo+IDMpIHRoaXMgc3lu dGF4IGRlZmluZXMgdGhlIHN5bnRheCBvZiB0aGUgZW50aXJlIGF0dHJpYnV0ZSwgaW5jbHVkaW5n ICJhPSIgYW5kIHRoZSBzZXBhcmF0aW9uIGJldHdlZW4gYXR0cmlidXRlIG5hbWUgYW5kDQo+IHZh bHVlLiBXZSBhcmUgdHJ5aW5nIHRvIGdldCBhd2F5IGZyb20gdGhhdCBhcyBwYXJ0IG9mIHRoZSBj bGVhbnVwIGluIHJmYzQ1NjZiaXMuIChCZWNhdXNlIHBlb3BsZSBrZWVwIGdldHRpbmcgaXQgd3Jv bmcsIHNvDQo+IHRoYXQgaXQgZG9lc24ndCBtYXRjaCB3aXRoIHRoZSBnZW5lcmljIHN5bnRheCBv ZiBhbiBhdHRyaWJ1dGUuKQ0KPiANCj4gSSBzdWdnZXN0IGEgYmV0dGVyIHN5bnRheCBmb3IgdGhp cyB3b3VsZCBiZToNCj4gDQo+ICAgICBzYy12YWx1ZSAgICAgPSBzYy1zZW5kIFtTUCBzYy1yZWN2 XSAvIHNjLXJlY3YgW1NQIHNjLXNlbmRdDQpbQm9CXSBPSywgdGhhdCB3b3JrcyBhbmQgaXMgYSBt b3JlIGNsZWFyIGRlc2NyaXB0aW9uIG9mIHdoYXQgd2FzIGFscmVhZHkgaW50ZW5kZWQuIEkgY2Fu IG1ha2UgdGhhdCBjaGFuZ2UgaW4gLTA4LiANCg0KPiAgICAgc2Mtc2VuZCAgICAgID0gInNlbmQi IHNjLXN0ci1saXN0DQo+ICAgICBzYy1yZWN2ICAgICAgPSAicmVjdiIgc2Mtc3RyLWxpc3QNCj4g ICAgIHNjLXN0ci1saXN0ICA9IFNQIHNjLWFsdC1saXN0ICooICI7IiBzYy1hbHQtbGlzdCApDQpb Qm9CXSBJcyB0aGVyZSBhbnkgc3BlY2lmaWMgcmVhc29uIHlvdSBpbmNsdWRlIFNQIGFzIGZpcnN0 IHBhcnQgb2Ygc2Mtc3RyLWxpc3Q/IEkgd291bGQgdGhpbmsgaXQgY2xlYXJlciB0byBoYXZlIFNQ IGFzIHNlcGFyYXRvciBpbiBzYy1zZW5kIGFuZCBzYy1yZWN2IGRlZmluaXRpb25zLg0KDQo+ICAg ICBzYy1hbHQtbGlzdCAgPSBzYy1pZCAqKCAiLCIgc2MtaWQgKQ0KPiAgICAgc2MtaWQtcGF1c2Vk ID0gIn4iDQo+ICAgICBzYy1pZCAgICAgICAgPSBbc2MtaWQtcGF1c2VkXSByaWQtaWQNCj4gICAg IDsgU1AgZGVmaW5lZCBpbiBbUkZDNTIzNF0NCj4gICAgIDsgcmlkLWlkIGRlZmluZWQgaW4gW0kt RC5pZXRmLW1tdXNpYy1yaWRdDQo+IA0KPiAJVGhhbmtzLA0KPiAJUGF1bA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW11c2ljIG1haWxp bmcgbGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== From nobody Mon Mar 13 07:56:23 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 575A91294F1 for ; Mon, 13 Mar 2017 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, 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 Ou4oxO31yRAu for ; Mon, 13 Mar 2017 07:56:20 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 A083B12945B for ; Mon, 13 Mar 2017 07:56:20 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-06v.sys.comcast.net with SMTP id nRNrcwjxgk7AGnROVcC0SJ; Mon, 13 Mar 2017 14:56:19 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-09v.sys.comcast.net with SMTP id nROUckNpUQcYynROVcwK8J; Mon, 13 Mar 2017 14:56:19 +0000 To: Bo Burman , "mmusic@ietf.org" References: <87mvd2fj5h.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <8ac6f395-da07-58e1-4859-f16d15ed9e85@alum.mit.edu> Date: Mon, 13 Mar 2017 10:56:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfB1yniBY5EFnvsMLbLZ3DWTklOUnJUrTRyDaeDtr7kaZas66ciakph3AoVMJEvUo4Afn2xut0VnJKJ4q+nuxWcFKBdvqTsihSftfcuTNp/7NxcI//zxS w3qOz4wCMToaCgXhBXzUCFFXDRrrwtxj1C/kVQbrKgsmt87fWWhLvONnIWcFUqfWgP9UHe6wjqUrLJ50EZKWrusgTo2GWMCMCGg= Archived-At: Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 14:56:22 -0000 Bo, On 3/13/17 10:48 AM, Bo Burman wrote: > Paul, thanks for good comments, > > Please see my responses inline. > > /Bo > (as individual) > >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: den 3 mars 2017 20:08 >> To: mmusic@ietf.org >> Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-sdp-simulcast-07 >> >> Dale, >> >> On 3/3/17 10:56 AM, Dale R. Worley wrote: >>> Iñaki Baz Castillo writes: >>>>> but according to >>>>> https://tools.ietf.org/html/draft-ietf-mmusic-rid-09 >>>>> it seems that "direction" (send/recv) should be placed *before* >>>>> "pt=xx": >>>>> >>>>> a=rid: [pt=;]=... >>>> >>>> In fact, pt=xx seems to be yet another "param". >>> >>> That purported BNF is really bizarre, since it generates the clearly >>> incorrect form: >> >> IIUC you are commenting on the ABNF in draft-ietf-mmusic-rid-08, not in draft-ietf-mmusic-sdp-simulcast-07, right? >> >>> a=rid: >>> == >> >> I'm not seeing how the ABNF generates that. >> >>> A correct description is: >>> >>> a=rid: ( pt= | = >>> ) *( ; = ) >> >> ISTM the ABNF in the draft is equivalent to what you have written. >> (Though yours is clearer.) >> >> Meanwhile, the ABNF of draft-ietf-mmusic-sdp-simulcast-07 does some small problems: >> >> 1) it allows either one or two 'sc-str-list's. I presume this is so you can have both send and recv lists, but it also allows two >> send lists or two recv lists. > [BoB] That is to allow for having both send and receive directions on the same line, because use of multiple lines are not defined (section 6.2 says "The meaning of including multiple "a=simulcast" lines in a single SDP media description is undefined, MUST NOT be used by implementations of this specification and any additional 'a=simulcast' lines beyond the first in a media description MUST be ignored if received"). The current ABNF thus allows listing the same direction twice, but this is explicitly disallowed by text in section 6.2 ("each direction MUST NOT occur more than once on the same line"). > >> >> 2) it references rid-identifier from draft-ietf-mmusic-rid-08, but that isn't defined there. I guess it means to reference rid- >> id. > [BoB] Yes, this should be aligned; to be included in -08. > >> >> 3) this syntax defines the syntax of the entire attribute, including "a=" and the separation between attribute name and >> value. We are trying to get away from that as part of the cleanup in rfc4566bis. (Because people keep getting it wrong, so >> that it doesn't match with the generic syntax of an attribute.) >> >> I suggest a better syntax for this would be: >> >> sc-value = sc-send [SP sc-recv] / sc-recv [SP sc-send] > [BoB] OK, that works and is a more clear description of what was already intended. I can make that change in -08. > >> sc-send = "send" sc-str-list >> sc-recv = "recv" sc-str-list >> sc-str-list = SP sc-alt-list *( ";" sc-alt-list ) > [BoB] Is there any specific reason you include SP as first part of sc-str-list? I would think it clearer to have SP as separator in sc-send and sc-recv definitions. Either way works. This way it is only specified once. Its really a matter of taste. Thanks, Paul >> sc-alt-list = sc-id *( "," sc-id ) >> sc-id-paused = "~" >> sc-id = [sc-id-paused] rid-id >> ; SP defined in [RFC5234] >> ; rid-id defined in [I-D.ietf-mmusic-rid] >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Mar 13 11:37: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 87ECE129A19 for ; Mon, 13 Mar 2017 11:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=2.035, SPF_PASS=-0.001, 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 A8FkSi-ff-Tl for ; Mon, 13 Mar 2017 11:37:36 -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 5A3B4129A2C for ; Mon, 13 Mar 2017 11:37:36 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2DIYd8R001897; Mon, 13 Mar 2017 14:37:29 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 294b7q9g6a-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Mar 2017 14:37:28 -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; Mon, 13 Mar 2017 13:37:27 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] Handling of unverified data and media Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGOsIkAgAABT4CAAA4wAIAA+MdggAO42wA= Date: Mon, 13 Mar 2017 18:37:27 +0000 Message-ID: <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_67E58DC289CB45AB9452C6A7DFEA34A4vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-13_12:, , 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-1702020001 definitions=main-1703130145 Archived-At: Cc: Flemming Andreasen , Harald Alvestrand , mmusic Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 18:37:38 -0000 --_000_67E58DC289CB45AB9452C6A7DFEA34A4vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBNYXIgMTEsIDIwMTcsIGF0IDk6NTIgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KSXMgdGhpcyBhIHRoZW9yZXRpY2FsIGlzc3VlPw0KDQpB dCBsZWFzdCBpZiB5b3UgdXNlIElDRSwgeW91IGFyZSBnb2luZyB0byByZWNlaXZlIHRoZSBhbnN3 ZXIgYmVmb3JlIHlvdSByZWNlaXZlIGFueSBtZWRpYSwgYXMgeW91IGFyZSBnb2luZyB0byBkbyB0 aGUgY29ubmVjdGl2aXR5IGNoZWNrcyBldGMuDQoNCk5vLCBldmVuIHdpdGggSUNFIGl04oCZcyBw b3NzaWJsZSBmb3IgbWVkaWEgb3IgdGhlIERUTFMgaGFuZHNoYWtlIHRvIG91dHJhY2UgdGhlIGFu c3dlci4NCg0KVGhpcyBpcyBiZWNhdXNlIElDRSBvZmZlcmluZyBlbmRwb2ludHMgcmVzcG9uZCB0 byBjb25uZWN0aXZpdHkgY2hlY2tzIGJlZm9yZSB0aGV5IHJlY2VpdmUgYW4gYW5zd2VyLiAgV2hl biB0aGUgYW5zd2VyZXIgcmVjZWl2ZXMgdGhpcyBzdWNjZXNzZnVsIGNvbm5lY3Rpdml0eSBjaGVj ayByZXNwb25zZSwgaXQgcHV0cyB0aGUgcmVsZXZhbnQgcGFpciBpbiB0aGUgVmFsaWQgbGlzdCwg YW5kIHRoZW4gKGlmIGl0IGhhcyB0aGUgYWN0aXZlIHJvbGUsIGFzIHJlY29tbWVuZGVkKSBjYW4g bGVnaXRpbWF0ZWx5IGluaXRpYXRlIERUTFMgb24gdGhpcyBwYWlyLg0KDQpJZiB0d28gSUNFIGVu ZHBvaW50cyBoYXZlIGEgc2hvcnQgUlRUIGFuZCBjbGVhciBjb25uZWN0aXZpdHkgYmV0d2VlbiB0 aGVtLCBidXQgYSBsb25nIFJUVCB0byB0aGVpciBzaWduYWxpbmcgc2VydmVyLCB0aGlzIGNhbiBo YXBwZW4gcXVpdGUgZWFzaWx5Lg0KDQpBbHNvLCBpbiByZWFsaXR5IHNvbWUgaW1wbGVtZW50YXRp b25zIHdpbGwgbm90IGFjY2VwdCBjb250ZW50IGJlZm9yZSB0aGUgYW5zd2VyIGFycml2ZXMg4oCT IG5vIG1hdHRlciBpZiBEVExTIGlzIHVzZWQgb3Igbm90IOKAkyBzbyB0aGUgYmVzdCB0aGluZyBp cyB0bywgb25jZSB0aGUgYW5zd2VyIGhhcyBiZWVuIHNlbnQsIGp1c3Qgd2FpdCBmb3IgYSB3aGls ZSBiZWZvcmUgc2VuZGluZyBhbnkgY29udGVudC4NCg0KRm9ydHVuYXRlbHksIERUTFMgaGFzIHJl dHJhbnNtaXNzaW9ucywgc28gdGhpcyBzaG91bGRu4oCZdCBjYXVzZSBmYWlsdXJlLCBqdXN0IGEg YnJpZWYgc2V0dXAgZGVsYXkuDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogbW11 c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJl c2NvcmxhDQpTZW50OiAxMSBNYXJjaCAyMDE3IDAyOjU3DQpUbzogQmVybmFyZCBBYm9iYSA8YmVy bmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tPj4NCkNj OiBGbGVtbWluZyBBbmRyZWFzZW4gPGZhbmRyZWFzQGNpc2NvLmNvbTxtYWlsdG86ZmFuZHJlYXNA Y2lzY28uY29tPj47IGh0YUBnb29nbGUuY29tPG1haWx0bzpodGFAZ29vZ2xlLmNvbT47IG1tdXNp YyBXRyA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtNTVVTSUNdIEhhbmRsaW5nIG9mIHVudmVyaWZpZWQgZGF0YSBhbmQgbWVkaWENCg0KU29y cnksIG5vLCBJIHdhcyBqdXN0IHRhbGtpbmcgYWJvdXQgd2hhdCBtaWdodCBvciBtaWdodCBub3Qg YmUgc2FmZS4uLi4gVGhlIGRvYyB0ZXh0IGlzDQphIGRpZmZlcmVudCBxdWVzdGlvbi4NCg0KLUVr cg0KDQoNCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0IDQ6MDUgUE0sIEJlcm5hcmQgQWJvYmEgPGJl cm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+IHdy b3RlOg0KRUtSIHNhaWQ6DQoNCiJJIGhhdmVuJ3Qgc3BlbnQgdG9vIG11Y2ggdGltZSBvbiBpdCwg YnV0IGl0IHNlZW1zIGxpa2UgaXQgb3VnaHQgdG8gYmUgc2FmZSB0byBob2xkDQphbnl0aGluZyB5 b3UgcmVjZWl2ZSBwcmlvciB0byBnZXR0aW5nIHRoZSBmaW5nZXJwcmludC4gSXQgbWlnaHQgYmUg YmV0dGVyLCBhcyBNVA0Kc3VnZ2VzdHMsIHRvIGRpc2NhcmQgdGhlIGRhdGFjaGFubmVsIGRhdGEs IGJ1dCBJJ20gbm90IHN1cmUgd2h5IGl0IHdvdWxkIGJlDQpuZWNlc3NhcnkuIg0KDQpbQkFdIFNv IHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIE1VU1QgTk9UIGFsbG93cyB0aGUgYnJvd3NlciB0byBi dWZmZXIgZGF0YS9tZWRpYSBidXQgbm90IHRvIHBhc3MgaXQgdG8gdGhlIGFwcGxpY2F0aW9uIChp biB0aGUgY2FzZSBvZiB0aGUgZGF0YSBjaGFubmVsKSBvciB0byBwbGF5IGl0IG91dD8NCg0KT24g RnJpLCBNYXIgMTAsIDIwMTcgYXQgNDowMSBQTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29t PG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCkkgaGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0 aW1lIG9uIGl0LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBvdWdodCB0byBiZSBzYWZlIHRvIGhvbGQN CmFueXRoaW5nIHlvdSByZWNlaXZlIHByaW9yIHRvIGdldHRpbmcgdGhlIGZpbmdlcnByaW50LiBJ dCBtaWdodCBiZSBiZXR0ZXIsIGFzIE1UDQpzdWdnZXN0cywgdG8gZGlzY2FyZCB0aGUgZGF0YWNo YW5uZWwgZGF0YSwgYnV0IEknbSBub3Qgc3VyZSB3aHkgaXQgd291bGQgYmUNCm5lY2Vzc2FyeS4N Cg0KLUVrcg0KDQpPbiBGcmksIE1hciAxMCwgMjAxNyBhdCAyOjQ3IFBNLCBSb21hbiBTaHBvdW50 IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCk15 IGFzc3VtcHRpb24gYWx3YXlzIHdhcyB0aGF0IGRhdGEgaXMgcmVjZWl2ZWQsIGRlY29kZWQgYW5k IGRpc2NhcmRlZCB1bnRpbCBmaW5nZXJwcmludCBpcyByZWNlaXZlZCBhbmQgdmVyaWZpZWQuIFRo aXMgd2F5IERUTFMgaGFuZHNoYWtlIGNvbXBsZXRlcywga2V5IGZyYW1lcyBhcmUgZGVjb2RlZCwg YnV0IHVzZXIgaXMgbm9yIHByZXNlbnRlZCB3aXRoIGFueSB1bnZlcmlmaWVkIG1lZGlhLg0KDQpS ZWdhcmRzLA0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFRodSwgTWFyIDks IDIwMTcgYXQgNjo1OCBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpJIHRoaW5rIHRoYXQg dGhlIGRhdGEgY2hhbm5lbCBxdWVzdGlvbiBpcyBlYXN5LCBhbnl0aGluZyBvdGhlciB0aGFuIGEN CiJubyIgaXMgbm90IGFjY2VwdGFibGUuICBEYXRhIGluIHRoYXQgZm9ybSBlbnRlcnMgdGhlIHNl Y3VyaXR5DQpib3VuZGFyeSBmb3IgYW4gb3JpZ2luIGFuZCBpdCBkb2Vzbid0IG1ha2UgYW55IHNl bnNlIHRvIHJpc2sgYXR0YWNrDQp0aGVyZS4gIChJdCdzIGFsc28gbGlrZWx5IHVubmVjZXNzYXJ5 LCBpZiBhIGhhbGYgYSByb3VuZCB0cmlwIG9mDQpzaWduYWxpbmcgaXMgc2xvd2VyIHRoYW4gNSBy b3VuZCB0cmlwcyBvbiB0aGUgbWVkaWEgcGF0aCwgdGhlbg0Kc29tZXRoaW5nIGlzIG1lc3NlZCB1 cC4pDQoNCkknbSBpbiB0d28gbWluZHMgYWJvdXQgdGhlIG1lZGlhIHBhcnQuIEZvciBtZWRpYSwg eW91IGNvdWxkIGFsc28NCnJlYXNvbmFibHkgbWFrZSB0aGUgc2FtZSBvcmlnaW4tcHVyaXR5IGFy Z3VtZW50LiAgSSdtIGluY2xpbmVkIHRvIHNheQ0KdGhhdC4gIEJ1dCB3ZSBDQU4gaXNvbGF0ZSBt ZWRpYSBmcm9tIHRoZSBvcmlnaW4gKGFuZCB3ZSBkZWZpbml0ZWx5DQpzaG91bGQgaWYgd2UgYWxs b3cgdGhpcykuDQoNClNvLCB0aGUgbWVkaWEgdGhhdCBhcnJpdmVzIGhhZCB0byBjb21wbHkgd2l0 aCB5b3VyIG9mZmVyLiAgVGhlIERUTFMNCmhhbmRzaGFrZSBhbHNvIGhhcyB0byBjb21wbGV0ZSwg d2hpY2ggdGVsbHMgdGhlIHJlY2VpdmVyIHdoZXRoZXIgdGhlDQptZWRpYSBuZWVkcyB0byBiZSBj b25maWRlbnRpYWwgb3Igbm90IChhdCB3aGljaCBwb2ludCB5b3UgY2FuIGRpc2FibGUNCnRoaXMg ZmVhdHVyZSkuDQoNCkl0J3MgYWxzbyBwb3NzaWJsZSB0aGF0IGEgcmVjZWl2ZXIgY2FuIHJlcXVp cmUgdGhhdCBhbiBJQ0UNCmNvbm5lY3Rpdml0eSBjaGVjayB3YXMgbWFkZSAodGhvdWdoIHRoaXMg aXMgaW5ib3VuZCBvbmx5LCBhbmQgSSdtDQp1bmNsZWFyIG9uIHdoZXRoZXIgaGF2aW5nIHJlY2Vp dmVkIGFuIGluYm91bmQgY2hlY2sgd291bGQgbm9ybWFsbHkNCnByZXZlbnQgdGhlIHJlY2VpdmVy IGZyb20gYWNjZXB0aW5nIGEgcGFja2V0KS4NCg0KQWxsIHRvbGQsIHRoYXQncyBhIGxvdCBvZiBp bmZvcm1hdGlvbiBhYm91dCB0aGUgbmVnb3RpYXRlZCBzZXNzaW9uIGZvcg0KYW4gYXR0YWNrZXIg dG8gaGF2ZS4gIFRoZSBvZGRzIG9mIHRoaXMgYmVpbmcgYW4gYXR0YWNrIHdvdWxkICpzZWVtKiB0 bw0KYmUgbG93Lg0KDQpPbiB0aGUgb3RoZXIgaGFuZCwgd2UgZG9uJ3QgYXNzdW1lIGNvbmZpZGVu dGlhbGl0eSBvZiBzaWduYWxpbmc7IHRoZQ0Kc2VjdXJpdHkgbW9kZWwgYXNzdW1lcyB0aGF0IGFs bCB0aGlzIGluZm9ybWF0aW9uIGlzIGVmZmVjdGl2ZWx5IHB1YmxpYw0KYW5kIHRoZSBwcm90ZWN0 aW9uIHdlIGhhdmUgYWdhaW5zdCBhdHRhY2sgaXMgdGhlIGNlcnRpZmljYXRlDQpmaW5nZXJwcmlu dC4gIFRoaXMgd291bGQgcmVtb3ZlIHRoYXQgcHJvdGVjdGlvbiwgYWxiZWl0IGZvciBhIHNob3J0 DQpkdXJhdGlvbi4NCg0KSSBoYXZlIGFuIGV4dHJhIHF1ZXN0aW9uOiBkb2VzIGFueW9uZSBwbGFu IHRvIGltcGxlbWVudCB0aGlzPyAgSXQncw0Kbm9uLXRyaXZpYWwuICBJIHRoaW5rIHRoYXQgSSBr bm93IHdoYXQgSSdkIG5lZWQgdG8gZG8gaW4gRmlyZWZveCBhbmQNCml0IHdvdWxkIGJlIHF1aXRl IGRpc3J1cHRpdmUuICBCZWZvcmUgY29tbWl0dGluZyB0byBkbyB0aGF0IHdvcmsNCih3aGljaCBJ IHdpbGwgbGVhdmUgdG8gb3RoZXJzIGNsb3NlciB0byB0aGlzIHRvIGRlY2lkZSksIEknZCBwcm9i YWJseQ0Kd2FudCBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBhY3R1YWwgYWR2YW50YWdlIHRoYXQg aXQgcHJvdmlkZXMuDQoNCk9uIDEwIE1hcmNoIDIwMTcgYXQgMDc6MTAsIEJlcm5hcmQgQWJvYmEg PGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbT4+ IHdyb3RlOg0KPiBJbiB0aGUgVzNDIFdFQlJUQyBXRywgYW4gaXNzdWUgaGFzIGJlZW4gc3VibWl0 dGVkIHJlbGF0aW5nIHRvIHBsYXlvdXQgb2YNCj4gdW52ZXJpZmllZCBtZWRpYToNCj4gaHR0cHM6 Ly9naXRodWIuY29tL3czYy93ZWJydGMtcGMvaXNzdWVzLzg0OQ0KPg0KPiBJdCBoYXMgYmVlbiBz dWdnZXN0ZWQgdGhhdCBpZiB0aGUgYnJvd3NlciBpcyBjb25maWd1cmVkIHRvIGRvIHNvLCB0aGF0 DQo+IHBsYXlvdXQgYmUgYWxsb3dlZCBmb3IgYSBsaW1pdGVkIHBlcmlvZCAoZS5nLiA1IHNlY29u ZHMpIHByaW9yIHRvDQo+IGZpbmdlcnByaW50IHZlcmlmaWNhdGlvbjoNCj4gaHR0cHM6Ly9naXRo dWIuY29tL3czYy93ZWJydGMtcGMvcHVsbC8xMDI2DQo+DQo+IFNlY3Rpb24gNi4yIG9mIGRyYWZ0 LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLTEzIGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgdGV4dCwN Cj4gY2FycmllZCBvdmVyIGZyb20gUkZDIDQ1NzI6DQo+DQo+ICAgIE5vdGUgdGhhdCB3aGVuIHRo ZSBvZmZlci9hbnN3ZXIgbW9kZWwgaXMgYmVpbmcgdXNlZCwgaXQgaXMgcG9zc2libGUNCj4gICAg Zm9yIGEgbWVkaWEgY29ubmVjdGlvbiB0byBvdXRyYWNlIHRoZSBhbnN3ZXIgYmFjayB0byB0aGUg b2ZmZXJlci4NCj4gICAgVGh1cywgaWYgdGhlIG9mZmVyZXIgaGFzIG9mZmVyZWQgYSAnc2V0dXA6 cGFzc2l2ZScgb3IgJ3NldHVwOmFjdHBhc3MnDQo+ICAgIHJvbGUsIGl0IE1VU1QgKGFzIHNwZWNp ZmllZCBpbiBSRkMgNDE0NSBbN10pIGJlZ2luIGxpc3RlbmluZyBmb3IgYW4NCj4gICAgaW5jb21p bmcgY29ubmVjdGlvbiBhcyBzb29uIGFzIGl0IHNlbmRzIGl0cyBvZmZlci4gIEhvd2V2ZXIsIGl0 IE1VU1QNCj4gICAgTk9UIGFzc3VtZSB0aGF0IHRoZSBkYXRhIHRyYW5zbWl0dGVkIG92ZXIgdGhl IFRMUyBjb25uZWN0aW9uIGlzIHZhbGlkDQo+ICAgIHVudGlsIGl0IGhhcyByZWNlaXZlZCBhIG1h dGNoaW5nIGZpbmdlcnByaW50IGluIGFuIFNEUCBhbnN3ZXIuICBJZg0KPiAgICB0aGUgZmluZ2Vy cHJpbnQsIG9uY2UgaXQgYXJyaXZlcywgZG9lcyBub3QgbWF0Y2ggdGhlIGNsaWVudCdzDQo+ICAg IGNlcnRpZmljYXRlLCB0aGUgc2VydmVyIGVuZHBvaW50IE1VU1QgdGVybWluYXRlIHRoZSBtZWRp YSBjb25uZWN0aW9uDQo+ICAgIHdpdGggYSBiYWRfY2VydGlmaWNhdGUgZXJyb3IsIGFzIHN0YXRl ZCBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBoLg0KPg0KPiBHaXZlbiB0aGUgb3V0c3RhbmRpbmcg aXNzdWUgcmVsYXRpbmcgdG8gaGFuZGxpbmcgb2YgdW52ZXJpZmllZCBtZWRpYSwgdGhlDQo+IENo YWlycyBvZiB0aGUgVzNDIFdFQlJUQyBXRyB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgY2xhcmlmaWNh dGlvbiBmcm9tIHRoZQ0KPiBJRVRGIE1NVVNJQyBXRyBhcyB0byB0aGUgbWVhbmluZyBvZiB0aGUg Ik1VU1QgTk9UIiBpbiB0aGUgYWJvdmUgcGFyYWdyYXBoLg0KPiBJbiBwYXJ0aWN1bGFyLCB3aGF0 IGlzIGl0IHBlcm1pdHRlZCBmb3IgYW4gaW1wbGVtZW50YXRpb24gdG8gZG8gd2l0aA0KPiByZWNl aXZlZCBkYXRhIGFuZCBtZWRpYSBwcmlvciB0byB2ZXJpZmljYXRpb24/IEZvciBleGFtcGxlOg0K Pg0KPiAgICAgIDEuIE1heSBkYXRhIHJlY2VpdmVkIG92ZXIgdGhlIGRhdGEgY2hhbm5lbCBiZSBw cm92aWRlZCB0byB0aGUNCj4gYXBwbGljYXRpb24gcHJpb3IgdG8gdmVyaWZpY2F0aW9uPw0KPiAg ICAgICAgICBhLiBJZiB0aGUgYW5zd2VyIHRvIHRoZSBhYm92ZSBpcyAibm8iLCBtYXkgdW52ZXJp ZmllZCByZWNlaXZlZCBkYXRhDQo+IGJlIGRlbGl2ZXJlZCBieSB0aGUgRFRMUyB0cmFuc3BvcnQg dG8gU0NUUCwgd2hpY2ggbWF5IGJ1ZmZlciBpdD8NCj4gICAgICAyLiBNYXkgcmVjZWl2ZWQgbWVk aWEgYmUgcGxheWVkIG91dCBwcmlvciB0byB2ZXJpZmljYXRpb24/DQo+DQo+IEJlcm5hcmQgQWJv YmENCj4gT24gYmVoYWxmIG9mIHRoZSBXM0MgV0VCUlRDIFdHDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QN Cj4gbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVz aWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzpt bXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t dXNpYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== --_000_67E58DC289CB45AB9452C6A7DFEA34A4vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <89FB6A5918AB984BA7D42540DFEB9755@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIg MTEsIDIwMTcsIGF0IDk6NTIgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5IaSw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5J cyB0aGlzIGEgdGhlb3JldGljYWwgaXNzdWU/PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ QXQgbGVhc3QgaWYgeW91IHVzZSBJQ0UsIHlvdSBhcmUgZ29pbmcgdG8gcmVjZWl2ZSB0aGUgYW5z d2VyIGJlZm9yZSB5b3UgcmVjZWl2ZSBhbnkgbWVkaWEsIGFzIHlvdSBhcmUgZ29pbmcgdG8gZG8g dGhlIGNvbm5lY3Rpdml0eSBjaGVja3MgZXRjLjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5ObywgZXZl biB3aXRoIElDRSBpdOKAmXMgcG9zc2libGUgZm9yIG1lZGlhIG9yIHRoZSBEVExTIGhhbmRzaGFr ZSB0byBvdXRyYWNlIHRoZSBhbnN3ZXIuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj5UaGlzIGlzIGJlY2F1c2UgSUNFIG9mZmVyaW5nIGVuZHBvaW50cyByZXNwb25kIHRv IGNvbm5lY3Rpdml0eSBjaGVja3MgYmVmb3JlIHRoZXkgcmVjZWl2ZSBhbiBhbnN3ZXIuICZuYnNw O1doZW4gdGhlIGFuc3dlcmVyIHJlY2VpdmVzIHRoaXMgc3VjY2Vzc2Z1bCBjb25uZWN0aXZpdHkg Y2hlY2sgcmVzcG9uc2UsIGl0IHB1dHMgdGhlIHJlbGV2YW50IHBhaXIgaW4gdGhlIFZhbGlkIGxp c3QsIGFuZCB0aGVuIChpZiBpdCBoYXMgdGhlIGFjdGl2ZSByb2xlLA0KIGFzIHJlY29tbWVuZGVk KSBjYW4gbGVnaXRpbWF0ZWx5IGluaXRpYXRlIERUTFMgb24gdGhpcyBwYWlyLjwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SWYgdHdvIElDRSBlbmRwb2ludHMgaGF2ZSBh IHNob3J0IFJUVCBhbmQgY2xlYXIgY29ubmVjdGl2aXR5IGJldHdlZW4gdGhlbSwgYnV0IGEgbG9u ZyBSVFQgdG8gdGhlaXIgc2lnbmFsaW5nIHNlcnZlciwgdGhpcyBjYW4gaGFwcGVuIHF1aXRlIGVh c2lseS48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24x OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0i Ij5BbHNvLCBpbiByZWFsaXR5IHNvbWUgaW1wbGVtZW50YXRpb25zIHdpbGwgbm90IGFjY2VwdCBj b250ZW50IGJlZm9yZSB0aGUgYW5zd2VyIGFycml2ZXMg4oCTIG5vIG1hdHRlciBpZiBEVExTIGlz IHVzZWQgb3Igbm90IOKAkyBzbyB0aGUgYmVzdCB0aGluZyBpcyB0bywgb25jZSB0aGUNCiBhbnN3 ZXIgaGFzIGJlZW4gc2VudCwganVzdCB3YWl0IGZvciBhIHdoaWxlIGJlZm9yZSBzZW5kaW5nIGFu eSBjb250ZW50Ljwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCkZvcnR1bmF0ZWx5LCBEVExTIGhhcyByZXRyYW5zbWlzc2lvbnMs IHNvIHRoaXMgc2hvdWxkbuKAmXQgY2F1c2UgZmFpbHVyZSwganVzdCBhIGJyaWVmIHNldHVwIGRl bGF5LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0 aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xh c3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+UmVnYXJkcyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFz cz0iIj5DaHJpc3RlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxhIG5hbWU9Il9NYWlsRW5k Q29tcG9zZSIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+bW11c2ljIFs8YSBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIi Pm1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPk9uDQogQmVoYWxmIE9mPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5FcmljIFJl c2NvcmxhPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjExIE1hcmNoIDIwMTcgMDI6NTc8YnIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpi ZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L2E+Jmd0 OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RmxlbW1pbmcgQW5kcmVhc2VuICZsdDs8YSBocmVm PSJtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5mYW5kcmVhc0BjaXNjby5jb208L2E+Jmd0 Ozs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmh0YUBnb29nbGUuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odGFAZ29vZ2xlLmNvbTwvYT47DQogbW11c2lj IFdHICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5v cmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW01NVVNJQ10gSGFu ZGxpbmcgb2YgdW52ZXJpZmllZCBkYXRhIGFuZCBtZWRpYTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClNvcnJ5LCBubywg SSB3YXMganVzdCB0YWxraW5nIGFib3V0IHdoYXQgbWlnaHQgb3IgbWlnaHQgbm90IGJlIHNhZmUu Li4uIFRoZSBkb2MgdGV4dCBpczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCmEg ZGlmZmVyZW50IHF1ZXN0aW9uLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQot RWtyPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQpPbiBGcmksIE1hciAxMCwgMjAxNyBhdCA0OjA1IFBNLCBCZXJuYXJk IEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBu b25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0 KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNnB0OyBtYXJn aW4tbGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDogMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkVL UiBzYWlkOiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJnF1b3Q7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOS41cHQ7IiBjbGFzcz0iIj5JIGhhdmVuJ3Qgc3BlbnQgdG9vIG11Y2gg dGltZSBvbiBpdCwgYnV0IGl0IHNlZW1zIGxpa2UgaXQgb3VnaHQgdG8gYmUgc2FmZSB0byBob2xk PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOS41cHQ7IiBjbGFzcz0iIj5hbnl0aGluZyB5b3UgcmVjZWl2ZSBw cmlvciB0byBnZXR0aW5nIHRoZSBmaW5nZXJwcmludC4gSXQgbWlnaHQgYmUgYmV0dGVyLCBhcyBN VDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDkuNXB0OyIgY2xhc3M9IiI+c3VnZ2VzdHMsIHRvIGRpc2NhcmQg dGhlIGRhdGFjaGFubmVsIGRhdGEsIGJ1dCBJJ20gbm90IHN1cmUgd2h5IGl0IHdvdWxkIGJlPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOS41cHQ7IiBjbGFzcz0iIj5uZWNlc3NhcnkuPC9zcGFuPiZxdW90Ozxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpbQkFdIFNvIHlvdSBhcmUgc2F5aW5n IHRoYXQgdGhlIE1VU1QgTk9UIGFsbG93cyB0aGUgYnJvd3NlciB0byBidWZmZXIgZGF0YS9tZWRp YSBidXQgbm90IHRvIHBhc3MgaXQgdG8gdGhlIGFwcGxpY2F0aW9uIChpbiB0aGUgY2FzZSBvZiB0 aGUgZGF0YSBjaGFubmVsKSBvciB0byBwbGF5IGl0IG91dD88bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpPbiBGcmksIE1h ciAxMCwgMjAxNyBhdCA0OjAxIFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86 ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3Jv dGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXIt c3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogcmdiKDIwNCwg MjA0LCAyMDQpOyBib3JkZXItbGVmdC13aWR0aDogMXB0OyBwYWRkaW5nOiAwY20gMGNtIDBjbSA2 cHQ7IG1hcmdpbi1sZWZ0OiA0LjhwdDsgbWFyZ2luLXJpZ2h0OiAwY207IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCkkgaGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0aW1lIG9uIGl0 LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBvdWdodCB0byBiZSBzYWZlIHRvIGhvbGQ8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCmFueXRoaW5nIHlvdSByZWNlaXZlIHBy aW9yIHRvIGdldHRpbmcgdGhlIGZpbmdlcnByaW50LiBJdCBtaWdodCBiZSBiZXR0ZXIsIGFzIE1U PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpzdWdnZXN0cywgdG8g ZGlzY2FyZCB0aGUgZGF0YWNoYW5uZWwgZGF0YSwgYnV0IEknbSBub3Qgc3VyZSB3aHkgaXQgd291 bGQgYmU8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCm5lY2Vzc2Fy eS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KLUVrcjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpPbiBGcmksIE1h ciAxMCwgMjAxNyBhdCAyOjQ3IFBNLCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5yb21hbkB0ZWx1cml4LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6 IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFwdDsgcGFkZGluZzogMGNt IDBjbSAwY20gNnB0OyBtYXJnaW4tbGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDogMGNtOyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCk15IGFzc3VtcHRpb24gYWx3YXlzIHdhcyB0aGF0IGRhdGEgaXMgcmVj ZWl2ZWQsIGRlY29kZWQgYW5kIGRpc2NhcmRlZCB1bnRpbCBmaW5nZXJwcmludCBpcyByZWNlaXZl ZCBhbmQgdmVyaWZpZWQuIFRoaXMgd2F5IERUTFMgaGFuZHNoYWtlIGNvbXBsZXRlcywga2V5IGZy YW1lcyBhcmUgZGVjb2RlZCwgYnV0IHVzZXIgaXMgbm9yIHByZXNlbnRlZCB3aXRoIGFueSB1bnZl cmlmaWVkIG1lZGlhLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KUmVnYXJkcyw8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsZWFyPSJh bGwiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCl9fX19fX19fX19fX188c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMzYsIDEzNiwg MTM2KTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJtLTU0MzQzMTkxMDg1 NTY2MDk0MTltLTY4NTY1NjMyNzM2NjQwMzU0MzVob2VuemIiPlJvbWFuIFNocG91bnQ8L3NwYW4+ PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KT24gVGh1LCBNYXIgOSwgMjAxNyBhdCA2OjU4IFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIi Pm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9u ZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxl ZnQtd2lkdGg6IDFwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNnB0OyBtYXJnaW4tbGVmdDogNC44 cHQ7IG1hcmdpbi1yaWdodDogMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSSB0aGluayB0aGF0IHRoZSBkYXRhIGNoYW5uZWwg cXVlc3Rpb24gaXMgZWFzeSwgYW55dGhpbmcgb3RoZXIgdGhhbiBhPGJyIGNsYXNzPSIiPg0KJnF1 b3Q7bm8mcXVvdDsgaXMgbm90IGFjY2VwdGFibGUuJm5ic3A7IERhdGEgaW4gdGhhdCBmb3JtIGVu dGVycyB0aGUgc2VjdXJpdHk8YnIgY2xhc3M9IiI+DQpib3VuZGFyeSBmb3IgYW4gb3JpZ2luIGFu ZCBpdCBkb2Vzbid0IG1ha2UgYW55IHNlbnNlIHRvIHJpc2sgYXR0YWNrPGJyIGNsYXNzPSIiPg0K dGhlcmUuJm5ic3A7IChJdCdzIGFsc28gbGlrZWx5IHVubmVjZXNzYXJ5LCBpZiBhIGhhbGYgYSBy b3VuZCB0cmlwIG9mPGJyIGNsYXNzPSIiPg0Kc2lnbmFsaW5nIGlzIHNsb3dlciB0aGFuIDUgcm91 bmQgdHJpcHMgb24gdGhlIG1lZGlhIHBhdGgsIHRoZW48YnIgY2xhc3M9IiI+DQpzb21ldGhpbmcg aXMgbWVzc2VkIHVwLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJJ20gaW4gdHdvIG1p bmRzIGFib3V0IHRoZSBtZWRpYSBwYXJ0LiBGb3IgbWVkaWEsIHlvdSBjb3VsZCBhbHNvPGJyIGNs YXNzPSIiPg0KcmVhc29uYWJseSBtYWtlIHRoZSBzYW1lIG9yaWdpbi1wdXJpdHkgYXJndW1lbnQu Jm5ic3A7IEknbSBpbmNsaW5lZCB0byBzYXk8YnIgY2xhc3M9IiI+DQp0aGF0LiZuYnNwOyBCdXQg d2UgQ0FOIGlzb2xhdGUgbWVkaWEgZnJvbSB0aGUgb3JpZ2luIChhbmQgd2UgZGVmaW5pdGVseTxi ciBjbGFzcz0iIj4NCnNob3VsZCBpZiB3ZSBhbGxvdyB0aGlzKS48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpTbywgdGhlIG1lZGlhIHRoYXQgYXJyaXZlcyBoYWQgdG8gY29tcGx5IHdpdGgg eW91ciBvZmZlci4mbmJzcDsgVGhlIERUTFM8YnIgY2xhc3M9IiI+DQpoYW5kc2hha2UgYWxzbyBo YXMgdG8gY29tcGxldGUsIHdoaWNoIHRlbGxzIHRoZSByZWNlaXZlciB3aGV0aGVyIHRoZTxiciBj bGFzcz0iIj4NCm1lZGlhIG5lZWRzIHRvIGJlIGNvbmZpZGVudGlhbCBvciBub3QgKGF0IHdoaWNo IHBvaW50IHlvdSBjYW4gZGlzYWJsZTxiciBjbGFzcz0iIj4NCnRoaXMgZmVhdHVyZSkuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSXQncyBhbHNvIHBvc3NpYmxlIHRoYXQgYSByZWNlaXZl ciBjYW4gcmVxdWlyZSB0aGF0IGFuIElDRTxiciBjbGFzcz0iIj4NCmNvbm5lY3Rpdml0eSBjaGVj ayB3YXMgbWFkZSAodGhvdWdoIHRoaXMgaXMgaW5ib3VuZCBvbmx5LCBhbmQgSSdtPGJyIGNsYXNz PSIiPg0KdW5jbGVhciBvbiB3aGV0aGVyIGhhdmluZyByZWNlaXZlZCBhbiBpbmJvdW5kIGNoZWNr IHdvdWxkIG5vcm1hbGx5PGJyIGNsYXNzPSIiPg0KcHJldmVudCB0aGUgcmVjZWl2ZXIgZnJvbSBh Y2NlcHRpbmcgYSBwYWNrZXQpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFsbCB0b2xk LCB0aGF0J3MgYSBsb3Qgb2YgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5lZ290aWF0ZWQgc2Vzc2lv biBmb3I8YnIgY2xhc3M9IiI+DQphbiBhdHRhY2tlciB0byBoYXZlLiZuYnNwOyBUaGUgb2RkcyBv ZiB0aGlzIGJlaW5nIGFuIGF0dGFjayB3b3VsZCAqc2VlbSogdG88YnIgY2xhc3M9IiI+DQpiZSBs b3cuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gdGhlIG90aGVyIGhhbmQsIHdlIGRv bid0IGFzc3VtZSBjb25maWRlbnRpYWxpdHkgb2Ygc2lnbmFsaW5nOyB0aGU8YnIgY2xhc3M9IiI+ DQpzZWN1cml0eSBtb2RlbCBhc3N1bWVzIHRoYXQgYWxsIHRoaXMgaW5mb3JtYXRpb24gaXMgZWZm ZWN0aXZlbHkgcHVibGljPGJyIGNsYXNzPSIiPg0KYW5kIHRoZSBwcm90ZWN0aW9uIHdlIGhhdmUg YWdhaW5zdCBhdHRhY2sgaXMgdGhlIGNlcnRpZmljYXRlPGJyIGNsYXNzPSIiPg0KZmluZ2VycHJp bnQuJm5ic3A7IFRoaXMgd291bGQgcmVtb3ZlIHRoYXQgcHJvdGVjdGlvbiwgYWxiZWl0IGZvciBh IHNob3J0PGJyIGNsYXNzPSIiPg0KZHVyYXRpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSSBoYXZlIGFuIGV4dHJhIHF1ZXN0aW9uOiBkb2VzIGFueW9uZSBwbGFuIHRvIGltcGxlbWVu dCB0aGlzPyZuYnNwOyBJdCdzPGJyIGNsYXNzPSIiPg0Kbm9uLXRyaXZpYWwuJm5ic3A7IEkgdGhp bmsgdGhhdCBJIGtub3cgd2hhdCBJJ2QgbmVlZCB0byBkbyBpbiBGaXJlZm94IGFuZDxiciBjbGFz cz0iIj4NCml0IHdvdWxkIGJlIHF1aXRlIGRpc3J1cHRpdmUuJm5ic3A7IEJlZm9yZSBjb21taXR0 aW5nIHRvIGRvIHRoYXQgd29yazxiciBjbGFzcz0iIj4NCih3aGljaCBJIHdpbGwgbGVhdmUgdG8g b3RoZXJzIGNsb3NlciB0byB0aGlzIHRvIGRlY2lkZSksIEknZCBwcm9iYWJseTxiciBjbGFzcz0i Ij4NCndhbnQgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGUgYWN0dWFsIGFkdmFudGFnZSB0aGF0IGl0 IHByb3ZpZGVzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAxMCBNYXJjaCAyMDE3IGF0IDA3OjEwLCBCZXJuYXJkIEFi b2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFz cz0iIj4NCiZndDsgSW4gdGhlIFczQyBXRUJSVEMgV0csIGFuIGlzc3VlIGhhcyBiZWVuIHN1Ym1p dHRlZCByZWxhdGluZyB0byBwbGF5b3V0IG9mPGJyIGNsYXNzPSIiPg0KJmd0OyB1bnZlcmlmaWVk IG1lZGlhOjxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3czYy93ZWJydGMt cGMvaXNzdWVzLzg0OSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS93M2Mv d2VicnRjLXBjL2lzc3Vlcy84NDk8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4N CiZndDsgSXQgaGFzIGJlZW4gc3VnZ2VzdGVkIHRoYXQgaWYgdGhlIGJyb3dzZXIgaXMgY29uZmln dXJlZCB0byBkbyBzbywgdGhhdDxiciBjbGFzcz0iIj4NCiZndDsgcGxheW91dCBiZSBhbGxvd2Vk IGZvciBhIGxpbWl0ZWQgcGVyaW9kIChlLmcuIDUgc2Vjb25kcykgcHJpb3IgdG88YnIgY2xhc3M9 IiI+DQomZ3Q7IGZpbmdlcnByaW50IHZlcmlmaWNhdGlvbjo8YnIgY2xhc3M9IiI+DQomZ3Q7PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2VicnRjLXBjL3B1bGwvMTAyNiIgdGFyZ2V0PSJfYmxhbmsi IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz PSIiPmh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2VicnRjLXBjL3B1bGwvMTAyNjwvYT48YnIgY2xh c3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyBTZWN0aW9uIDYuMiBvZiBkcmFmdC1pZXRm LW1tdXNpYy00NTcyLXVwZGF0ZS0xMyBjb250YWlucyB0aGUgZm9sbG93aW5nIHRleHQsPGJyIGNs YXNzPSIiPg0KJmd0OyBjYXJyaWVkIG92ZXIgZnJvbSBSRkMgNDU3Mjo8YnIgY2xhc3M9IiI+DQom Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgTm90ZSB0aGF0IHdoZW4gdGhlIG9m ZmVyL2Fuc3dlciBtb2RlbCBpcyBiZWluZyB1c2VkLCBpdCBpcyBwb3NzaWJsZTxiciBjbGFzcz0i Ij4NCiZndDsmbmJzcDsgJm5ic3A7IGZvciBhIG1lZGlhIGNvbm5lY3Rpb24gdG8gb3V0cmFjZSB0 aGUgYW5zd2VyIGJhY2sgdG8gdGhlIG9mZmVyZXIuPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAm bmJzcDsgVGh1cywgaWYgdGhlIG9mZmVyZXIgaGFzIG9mZmVyZWQgYSAnc2V0dXA6cGFzc2l2ZScg b3IgJ3NldHVwOmFjdHBhc3MnPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgcm9sZSwg aXQgTVVTVCAoYXMgc3BlY2lmaWVkIGluIFJGQyA0MTQ1IFs3XSkgYmVnaW4gbGlzdGVuaW5nIGZv ciBhbjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IGluY29taW5nIGNvbm5lY3Rpb24g YXMgc29vbiBhcyBpdCBzZW5kcyBpdHMgb2ZmZXIuJm5ic3A7IEhvd2V2ZXIsIGl0IE1VU1Q8YnIg Y2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBOT1QgYXNzdW1lIHRoYXQgdGhlIGRhdGEgdHJh bnNtaXR0ZWQgb3ZlciB0aGUgVExTIGNvbm5lY3Rpb24gaXMgdmFsaWQ8YnIgY2xhc3M9IiI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgYSBtYXRjaGluZyBmaW5nZXJw cmludCBpbiBhbiBTRFAgYW5zd2VyLiZuYnNwOyBJZjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsg Jm5ic3A7IHRoZSBmaW5nZXJwcmludCwgb25jZSBpdCBhcnJpdmVzLCBkb2VzIG5vdCBtYXRjaCB0 aGUgY2xpZW50J3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBjZXJ0aWZpY2F0ZSwg dGhlIHNlcnZlciBlbmRwb2ludCBNVVNUIHRlcm1pbmF0ZSB0aGUgbWVkaWEgY29ubmVjdGlvbjxi ciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IHdpdGggYSBiYWRfY2VydGlmaWNhdGUgZXJy b3IsIGFzIHN0YXRlZCBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBoLjxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7IEdpdmVuIHRoZSBvdXRzdGFuZGluZyBpc3N1ZSByZWxhdGlu ZyB0byBoYW5kbGluZyBvZiB1bnZlcmlmaWVkIG1lZGlhLCB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7 IENoYWlycyBvZiB0aGUgVzNDIFdFQlJUQyBXRyB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgY2xhcmlm aWNhdGlvbiBmcm9tIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgSUVURiBNTVVTSUMgV0cgYXMgdG8g dGhlIG1lYW5pbmcgb2YgdGhlICZxdW90O01VU1QgTk9UJnF1b3Q7IGluIHRoZSBhYm92ZSBwYXJh Z3JhcGguPGJyIGNsYXNzPSIiPg0KJmd0OyBJbiBwYXJ0aWN1bGFyLCB3aGF0IGlzIGl0IHBlcm1p dHRlZCBmb3IgYW4gaW1wbGVtZW50YXRpb24gdG8gZG8gd2l0aDxiciBjbGFzcz0iIj4NCiZndDsg cmVjZWl2ZWQgZGF0YSBhbmQgbWVkaWEgcHJpb3IgdG8gdmVyaWZpY2F0aW9uPyBGb3IgZXhhbXBs ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7IDEuIE1heSBkYXRhIHJlY2VpdmVkIG92ZXIgdGhlIGRhdGEgY2hhbm5lbCBiZSBwcm92aWRl ZCB0byB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7IGFwcGxpY2F0aW9uIHByaW9yIHRvIHZlcmlmaWNh dGlvbj88YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBhLiBJZiB0aGUgYW5zd2VyIHRvIHRoZSBhYm92ZSBpcyAmcXVvdDtubyZxdW90OywgbWF5IHVu dmVyaWZpZWQgcmVjZWl2ZWQgZGF0YTxiciBjbGFzcz0iIj4NCiZndDsgYmUgZGVsaXZlcmVkIGJ5 IHRoZSBEVExTIHRyYW5zcG9ydCB0byBTQ1RQLCB3aGljaCBtYXkgYnVmZmVyIGl0PzxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAyLiBNYXkgcmVjZWl2ZWQgbWVkaWEgYmUg cGxheWVkIG91dCBwcmlvciB0byB2ZXJpZmljYXRpb24/PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBj bGFzcz0iIj4NCiZndDsgQmVybmFyZCBBYm9iYTxiciBjbGFzcz0iIj4NCiZndDsgT24gYmVoYWxm IG9mIHRoZSBXM0MgV0VCUlRDIFdHPGJyIGNsYXNzPSIiPg0KJmd0OzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQomZ3Q7IG1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIg Y2xhc3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xv cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxiciBjbGFzcz0iIj4NCiZn dDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+bW11c2ljQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQptbXVz aWMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIg dGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bW11c2ljPC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAxMnB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxi ciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyIGNsYXNzPSIiPg0KbW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhy ZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tbXVzaWNAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5v bmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+bW11c2ljDQogbWFpbGlu ZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_67E58DC289CB45AB9452C6A7DFEA34A4vidyocom_-- From nobody Mon Mar 13 11:38:44 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 E00A71294A0 for ; Mon, 13 Mar 2017 11:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cWZGKMUjHyEn for ; Mon, 13 Mar 2017 11:38:41 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 32FE4129A05 for ; Mon, 13 Mar 2017 11:38:41 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 77so67014994pgc.1 for ; Mon, 13 Mar 2017 11:38:41 -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=fy3paa16Kam89eSwYkip4JByTyDgsaAATvA6X/0nT+8=; b=tZsFlyxSBpoqduanvL93UrHFC6eRiO5bGctDfB+G7xSVWLm5MJw355CFK2D1cHKJYT Gkqem8rAlDyzP9jZ9ujcR4FjX7gI+wTa8Fb67zTCTXEZTa8SASWIbrPxn5TfPondcBpo wy4fgOUFedEa4ag9Ox2bdFHiXiP5nkZQMOdIpScun2vQgHGkWxrFXJYFKvHLjEMvxvR2 POjAn0tXLnjYOLAGwQ/CB4+fhmrCMReX4eP6WmZu4f4e7LptGGvs/nWL0WMd7r1cqBr4 VjDzkknqwVbTfT4BI444Z4cY0R9vuybYopjFyt6N4lDbtvZOScYufoFPntTh/ngl3C6X sNKA== 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=fy3paa16Kam89eSwYkip4JByTyDgsaAATvA6X/0nT+8=; b=afX+oXK0NSbhYxXWdjtI6CxuI3QKu/4eHp00Jw/45af0REP//BcWqKYpm7M0KGkVPn k3RPZyXDASE+K+GvtWs6Thbng9F0kBIW6lBP533vjNrAXkbEPimY7vvuQCpGpb1PP3uh PtguLNOC9Fk6Q4d5xd/6iPuK3RJNZG2IjhR5J/SWL9PeuozMxI2SlXu1jhJ84tp3W/xt 2zBBj0BtI1pfc7SpuUe7eq49WMzLsAkPVGq39BPYa1FKYcsgL8lR6YkHh9UQJ0NoDMbI 8y1/R+257XqkMub26oLgypQ35xuV0tvCUsG4/2/1RJFOgKPAvDjS72eQ7lAD8lmUCU3L biWw== X-Gm-Message-State: AMke39miKZ3ezzAWrblBkW+rlyK4zdZ41ofak4aIHLG7iJ6SCNZ6mIOtAaZ3mtkhy/SChA== X-Received: by 10.98.19.12 with SMTP id b12mr39238039pfj.150.1489430320453; Mon, 13 Mar 2017 11:38:40 -0700 (PDT) Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com. [74.125.83.43]) by smtp.gmail.com with ESMTPSA id m6sm34238316pgn.58.2017.03.13.11.38.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:38:39 -0700 (PDT) Received: by mail-pg0-f43.google.com with SMTP id b129so67238408pgc.2 for ; Mon, 13 Mar 2017 11:38:39 -0700 (PDT) X-Received: by 10.99.225.5 with SMTP id z5mr37978371pgh.145.1489430319503; Mon, 13 Mar 2017 11:38:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.161.144 with HTTP; Mon, 13 Mar 2017 11:38:39 -0700 (PDT) In-Reply-To: References: <148939488127.16827.6722127323469391602@ietfa.amsl.com> From: Roman Shpount Date: Mon, 13 Mar 2017 14:38:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114e93a41ca267054aa105b5 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 18:38:43 -0000 --001a114e93a41ca267054aa105b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Suhas, One more thing that was discussed with Christer but did not make to sctp-sdp was what should be specified in session descriptions m=3D line during the ICE nomination process. Christer correctly pointed out that this belongs to ice-sip-sdp. As it stands right not it is unclear if default candidates should attempt to match currently selected candidate pair or continue to send the original default candidate. Trying to match currently selected pair can be difficult, especially since it can change during the signaling exchange and you can end up with m=3D line transport mismatch. My proposal was: Session descriptions sent during the ICE nomination process SHOULD include all the candidates discovered during the ICE nomination process, ICE candidates present in the session description that started the ICE nomination MUST not be removed from the session description and the default candidate MUST not change until ICE nomination process is complete. Finally, there was a bunch of calls for defining ICE/ transport tag. Should I propose the language for this for draft-ietf-mmusic-ice-sip-sdp or should it go into the separate draft? Regards, _____________ Roman Shpount On Mon, Mar 13, 2017 at 5:17 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >Thanks Christer. Are you referring to use text from this section: > https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-23#section-12.2 > > Wrong version =E2=80=93 correct section :) > > Regards, > > Christer > > > On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> Note that some decisions/actions also came out of Seoul. >> >> https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00 >> >> Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I guess = we can use more >> or less the same text (authored by Roman) that was added to >> draft-ietf-mmusic-sctp-sdp. >> >> Regards, >> >> Christer >> >> From: mmusic on behalf of Suhas Nandakumar < >> suhasietf@gmail.com> >> Date: Monday 13 March 2017 at 10:56 >> To: "mmusic@ietf.org" >> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt >> >> Version-12 address most of the review comments from Adam. For the >> questions that needs more attention from the WG, I have sent individual >> issues as emails >> >> Cheers >> Suhas >> >> On Mon, Mar 13, 2017 at 1:48 AM, 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 >>> of the IETF. >>> >>> Title : Using Interactive Connectivity Establishment >>> (ICE) with Session Description Protocol (SDP) offer/answer and Session >>> Initiation Protocol (SIP) >>> Authors : Marc Petit-Huguenin >>> Ari Keranen >>> Suhas Nandakumar >>> Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt >>> Pages : 43 >>> Date : 2017-03-13 >>> >>> Abstract: >>> This document describes how Interactive Connectivity Establishment >>> (ICE) is used with Session Description Protocol (SDP) offer/answer >>> and Session Initiation Protocol (SIP). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-12 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 > > --001a114e93a41ca267054aa105b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Suhas,

One more thing that was discu= ssed with Christer but did not make to sctp-sdp was what should be specifie= d in session descriptions m=3D line during the ICE nomination process. Chri= ster correctly pointed out that this belongs to ice-sip-sdp.=C2=A0As it stands right not it is uncle= ar if default candidates should attempt to match currently selected candida= te pair or continue to send the original default candidate. Trying to match= currently selected pair can be difficult, especially since it can change d= uring the signaling exchange and you can end up with m=3D line transport mi= smatch.=C2=A0My proposal was:

Session descriptions sent during the= ICE nomination process SHOULD include all the=C2=A0candidates=C2=A0discovered during the ICE nomination process, ICE=C2=A0candidates=C2=A0present in the session description that started the = ICE nomination MUST not be removed from the session description and the=C2= =A0default=C2=A0candida= te=C2=A0MUST not c= hange until ICE nomination process is complete.=C2=A0

=

Finally, there was a bunch of calls for defining ICE/ tran= sport tag. Should I propose the language for this for draft-ietf-mmusic-ice= -sip-sdp or should it go into the separate draft?

Regard= s,

_____________
Ro= man Shpount

On Mon, Mar 13, 2017 at 5:17 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

>Thanks Christer. Are you referring to use text from th= is section:=C2=A0https://tools.ietf.org/html= /draft-ietf-mmusic-sctp-sdp-23#section-12.2

Wrong version =E2=80=93 correct section :)

Regards,

Christer


On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Note that some decisions/actions also came out of Seoul.


Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I gues= s we can use more or less the same text (authored by Roman) that was added = to draft-ietf-mmusic-sctp-sdp.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Monday 13 March 2017 at 10:56=
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: d= raft-ietf-mmusic-ice-sip-sdp-12.txt

Version-12 address most of the review comments from Adam. = For the questions that needs more attention from the WG, I have sent indivi= dual issues as emails

Cheers
Suhas

On Mon, Mar 13, 2017 at 1:48 AM, <intern= et-drafts@ietf.org> wrote:

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 of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-13

Abstract:
=C2=A0 =C2=A0This document describes how Interactive Connectivity Establish= ment
=C2=A0 =C2=A0(ICE) is used with Session Description Protocol (SDP) offer/an= swer
=C2=A0 =C2=A0and Session Initiation Protocol (SIP).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-12

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


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/

_______________________________________________
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

--001a114e93a41ca267054aa105b5-- From nobody Mon Mar 13 11:47: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 12BB41298A3 for ; Mon, 13 Mar 2017 11:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, 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 Jkdjg_CiGj1q for ; Mon, 13 Mar 2017 11:46:58 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDEE129500 for ; Mon, 13 Mar 2017 11:46:58 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id 77so67182029pgc.1 for ; Mon, 13 Mar 2017 11:46:58 -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=RbnR5hsaei2OLS+Mtz/AouqE0KjLpaBanxmV4rcimq0=; b=PkAtS3K+UfdtJs2YHIXlRlptcpG8Y3PPwM1VnGC7t/eZiBQVZ4KMprsqEAx3/s/rgB RQNOsjP7PKQNso6L7Wo6/z7i2iaFTaQ1bPV7gbx95Lyk5/6+VoKgttQzAL01wr83Q4qW ZdFH6tnT5lAXo+0mpOggp0CgUcjRQZdwDPLgOWDR79+abNU4DNS2hO7HabuBoq6B1rDr Zm1KS2qHivYzJ7/DISxjTjBXOM56YIrFHcMvx2TJmMcmq1dYRgutlivfjPHe2c2WE5wL TZkvM2ZC7LftmLB/JqWhO1i9bt43cHa0WkTegEDY1evlRHR03mygRt4lgGbc0CfOKWWo 9MMQ== 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=RbnR5hsaei2OLS+Mtz/AouqE0KjLpaBanxmV4rcimq0=; b=gGTyjAhQWdvp4vQFAa00wJQpQplJkZsKEDILXsoJJ5QNhmy81R+YbmjrOk1a/OiARa G8WqqDsvnQ6S14QPtmYjGbt6cnPJwrxsY+vj+ymN+DzaahkdP7KvVpsiO3GtPk1ty+/m hGdofBk++IUtgV4MxoiVQGHCSIufJ0V2qMZnMnMia7d9Thf8BXNmZMsAnhdLOTyQU3fa mCkc1tM49crkpxu3E/eeI26lXLe5tnrGq4BKMZgYsA/e3p49l+QhQQdb0yKvn6RJtr+T 3bxjetoqwmz7u9EQlOPdbhssNvGJah1KJWbLycmlfOYzMDd20H8aRtFqnY03FdTQ/oax kutA== X-Gm-Message-State: AMke39mAG4hq6OVOrmoMc3GY4BUJKAJiGo+Q7i5PEKg7vtlygS7dF69laiZDXXpt2LOInA== X-Received: by 10.84.137.106 with SMTP id 97mr49431430plm.68.1489430817512; Mon, 13 Mar 2017 11:46:57 -0700 (PDT) Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com. [74.125.83.46]) by smtp.gmail.com with ESMTPSA id y67sm34002449pfa.96.2017.03.13.11.46.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:46:56 -0700 (PDT) Received: by mail-pg0-f46.google.com with SMTP id g2so50042810pge.3 for ; Mon, 13 Mar 2017 11:46:56 -0700 (PDT) X-Received: by 10.98.217.140 with SMTP id b12mr39833117pfl.136.1489430816253; Mon, 13 Mar 2017 11:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.161.144 with HTTP; Mon, 13 Mar 2017 11:46:55 -0700 (PDT) In-Reply-To: <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> From: Roman Shpount Date: Mon, 13 Mar 2017 14:46:55 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=94eb2c124ab8b871d9054aa1222f Archived-At: Cc: Flemming Andreasen , Harald Alvestrand , mmusic , Christer Holmberg Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 18:46:59 -0000 --94eb2c124ab8b871d9054aa1222f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 13, 2017 at 2:37 PM, Jonathan Lennox wrote= : > > On Mar 11, 2017, at 9:52 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > Is this a theoretical issue? > > At least if you use ICE, you are going to receive the answer before you > receive any media, as you are going to do the connectivity checks etc. > > > No, even with ICE it=E2=80=99s possible for media or the DTLS handshake t= o outrace > the answer. > > This is because ICE offering endpoints respond to connectivity checks > before they receive an answer. When the answerer receives this successfu= l > connectivity check response, it puts the relevant pair in the Valid list, > and then (if it has the active role, as recommended) can legitimately > initiate DTLS on this pair. > > If two ICE endpoints have a short RTT and clear connectivity between them= , > but a long RTT to their signaling server, this can happen quite easily. > > Also, in reality some implementations will not accept content before the > answer arrives =E2=80=93 no matter if DTLS is used or not =E2=80=93 so th= e best thing is > to, once the answer has been sent, just wait for a while before sending a= ny > content. > > > Fortunately, DTLS has retransmissions, so this shouldn=E2=80=99t cause fa= ilure, > just a brief setup delay. > > I think what specification says right now is that DTLS ClientHello should be processed before answer arrives ( https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-21#section-5.2 ). I think this clearly means DTLS handshake should complete. What should happen with data received after DTLS handshake before fingerprint arrives is a different issue. Without processing DTLS handshake before signaling answer, end point effectively slows down the connection setup by 5 sec (DTLS re transmit timer). In practice this is enough for substantial number of calls being hanged up by the caller or called party saying that call ended up in dead air. Regards, _____________ Roman Shpount --94eb2c124ab8b871d9054aa1222f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 13, 2017 at 2:37 PM, Jonathan Lennox <= ;jonathan@vidyo.com= > wrote:

On Mar 11, 2017, at 9:52 AM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:
Is this a theoretical issue?
=C2=A0
At least if you use ICE, you are going to receive the answer before= you receive any media, as you are going to do the connectivity checks etc.=

No, even with ICE it=E2=80=99s possible for media or the DTLS h= andshake to outrace the answer.

This is because ICE offering endpoints respond to connectivity checks = before they receive an answer.=C2=A0 When the answerer receives this succes= sful connectivity check response, it puts the relevant pair in the Valid li= st, and then (if it has the active role, as recommended) can legitimately initiate DTLS on this pair.

If two ICE endpoints have a short RTT and clear connectivity between t= hem, but a long RTT to their signaling server, this can happen quite easily= .

Also, in reality some implementations will not accept content befor= e the answer arrives =E2=80=93 no matter if DTLS is used or not =E2=80=93 s= o the best thing is to, once the answer has been sent, just wait for a while before sending any content.

 Fortunately, DTLS has retransmissions, so this shouldn=E2=80=99t cause fail= ure, just a brief setup delay.


I think w= hat specification says right now is that DTLS ClientHello should be process= ed before answer arrives (https://tools.ietf.org/html/draft-ietf-mmu= sic-dtls-sdp-21#section-5.2 ). I think this clearly means DTLS handshak= e should complete. What should happen with data received after DTLS handsha= ke before fingerprint arrives is a different issue.

Without processing DTLS handshake before signaling answer, end point effe= ctively slows down the connection setup by 5 sec (DTLS re transmit timer). = In practice this is enough for substantial number of calls being hanged up = by the caller or called party saying that call ended up in dead air.
<= div>
Regards,
______= _______
Roman Shpount
=C2=A0
--94eb2c124ab8b871d9054aa1222f-- From nobody Mon Mar 13 12:01:13 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 0E1A0129A9E for ; Mon, 13 Mar 2017 12:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, 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 wKX1Lxn2EGsI for ; Mon, 13 Mar 2017 12:01:12 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 521A01299FA for ; Mon, 13 Mar 2017 11:54:03 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id b129so67547365pgc.2 for ; Mon, 13 Mar 2017 11:54:03 -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=cpVp7TJWyPDgxF8pi+a6RzNWHuitBeLAfypLJP5PIHk=; b=n5iMVxLkA1GgBPq6YKCh1iD2BwiQWNkmRFgx5lnyfmnkDjy/HHR9U5uUQ31fuqq1BR u4dZFLWyuzm52cgGuAPXFofr9xaFzJ01eqKJB+Ntf+LRRaqo3BE/qvCS2m8stlpFNOSs NXs8OC4vv8FAnEVQjQLqeVvL68RrMRqo9NLIXpcl5tC4oHVQlpGYfI65mQEktxWXlAIR PgTtBqjCTZ2KWX6HFf22dnBVEdJW3mhRQqt70AwIhlyIpf0cjkfAqtnyPMaOGhwZGYOn JW5aB9qy5QibeQGjqi/cnr8yFJvAcWM1+VC/kQpAH5HOjWTG+CFn8+2QsWko0qCvwGFh ueQA== 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=cpVp7TJWyPDgxF8pi+a6RzNWHuitBeLAfypLJP5PIHk=; b=mFCT2d+ozwfzpDwVdgrIx8/2uOvDUyFcl7szl+ewhZrChehoroYry1jfiXToEOjU/x 88U2A5l38UaoiqirOdM/ea+2L9/ttLoHMF7ipm89pXmQzmysS96bkjZz5L3dQ1/msJmi cyDwUlIqSBQHLEcSQy6LEJmL++huTAHNlQCYvSVg/0UZ0eDrBpK4qk2T2tckvPcO7XH+ GQY97nfHZ57SQWS0sIGkwuTbi5nHhtJaQJRXgMAENvgIUm0EKUmYIpoKJxgkz6db3dEX Dw7k1B/FaU4e9z8WeUclV+ePNE2uQdZX6ti01thiep6b4QuAhxAc9tYlqPny6TStrZC3 ag9g== X-Gm-Message-State: AMke39mIfdiNpAFqaW0bhC1ShrdT0YT0LNWE19IbYd2q7butQmFuv17CJHentiWut/dHEQ== X-Received: by 10.84.241.10 with SMTP id a10mr49940678pll.47.1489431242742; Mon, 13 Mar 2017 11:54:02 -0700 (PDT) Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com. [74.125.83.46]) by smtp.gmail.com with ESMTPSA id x10sm34101349pfi.21.2017.03.13.11.54.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 11:54:02 -0700 (PDT) Received: by mail-pg0-f46.google.com with SMTP id g2so50187935pge.3 for ; Mon, 13 Mar 2017 11:54:01 -0700 (PDT) X-Received: by 10.99.138.202 with SMTP id y193mr38484771pgd.60.1489431241711; Mon, 13 Mar 2017 11:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.161.144 with HTTP; Mon, 13 Mar 2017 11:54:01 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Mon, 13 Mar 2017 14:54:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=94eb2c03aefa146a53054aa13c4a Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] ICE-SIP-SDP and RFC6544 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 19:01:13 -0000 --94eb2c03aefa146a53054aa13c4a Content-Type: text/plain; charset=UTF-8 It would probably be a good idea to have RFC6544bis. We can also use this draft to define TLS ICE candidates. One question I wanted to ask is do we need to maintain the same scope to ICE TCP candidates? Do we really need simultaneous open TCP candidates? Are there any plans of using TCP candidates to directly connection two end points behind NAT or is it only going to be used in scenarios where one of the end points is on the public IP? I think based on current usage patterns RFC 6544 can be greatly simplified. Regards, _____________ Roman Shpount On Mon, Mar 13, 2017 at 4:53 AM, Suhas Nandakumar wrote: > Adam raised a valid point on the scope of RFC6544 in the context of > ice-sip-sdp. > > We the authors did consider couple of options and would like the WG's > inputs to decide the next steps > > 1. Merge in RFC6544 into ice-sip-sdp and ice-bis > This includes bringing in appropriate text from rfc6544 into ice-bis > for ice processing detail and ice-sip-sdp for candidate encoding + > offer/answer specifics > > 2. RFC6544bis > Do a bis version of RFC6544 and make it refer to ICE-BIS and > ICE-SIP-SDP wherever appropriate. > > 3. Any other option ? > > We prefer option 2 given the magnitude of RFC6544 merge plan , but are > open to suggestions from either or a new option altogether > > please advise. > > > Cheers > Suhas > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c03aefa146a53054aa13c4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It would probably be a good idea to have=C2=A0RFC6544bis. We can also use this dra= ft to define TLS ICE candidates.

One question I wanted to ask is do we need to mainta= in the same scope to ICE TCP candidates? Do we really need simultaneous=C2= =A0open TCP candidates? Are there any plans of using TCP candidates to dire= ctly connection two end points behind NAT or is it only going to be used in= scenarios where one of the end points is on the public IP? I think based o= n current usage patterns RFC 6544 can be greatly simplified.<= /div>

Regards,

_____________
Roman Shpount

On Mon, Mar 13, 2017 at 4:53 AM, Suhas Nanda= kumar <suhasietf@gmail.com> wrote:
Adam raised a valid point on the scope = of RFC6544 in the context of ice-sip-sdp.

We the a= uthors did consider couple of options and would like the WG's inputs to= decide the next steps

1. Merge in RFC6544 into ic= e-sip-sdp and ice-bis
=C2=A0 =C2=A0This includes bringing in appr= opriate text from rfc6544 into ice-bis for ice processing detail and ice-si= p-sdp for candidate encoding + offer/answer specifics

<= div>2. RFC6544bis
=C2=A0 =C2=A0Do a bis version of RFC6544 and ma= ke it refer to ICE-BIS and ICE-SIP-SDP wherever appropriate.

=
3. Any other option ?

We prefer option = 2 given the magnitude of RFC6544 merge plan , but are open to suggestions f= rom either or a new option altogether

please advis= e.


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

--94eb2c03aefa146a53054aa13c4a-- From nobody Mon Mar 13 12:01: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 ACF0D129A78 for ; Mon, 13 Mar 2017 12:01:56 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 3LPezxeSh2XM for ; Mon, 13 Mar 2017 12:01:54 -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 289D7129889 for ; Mon, 13 Mar 2017 12:01:16 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id g2so50333428pge.3 for ; Mon, 13 Mar 2017 12:01: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=+ZTYfv6hRw07bv2cNyj+raDGfRtPwcQd8NrOrayA8JA=; b=pEEJW92WQc/qYWbdooCERSMhN1l4z6qOmeb24gPlNah0eZfy7+U8EsmgS5NqS48tNF T3/ENbMeudaRvy1IH/DSybccN0W3uaGMaQMkTYC8Lg609Nr0afnqgjzEOF1RGUx2z0Po 0i4lr8euGEKIfeFoXR1tLPex+gdLpQ/uQuYPhfS0+ciVXR8I5WAdvW89aCyqrWRRDnaN xRUioS4l1T2ROwq4wjvTw+DXxg2luH3MGpivoL97SMy1ZJ/BPBJsQ8b+amVd4dVfzfK1 XdNtcQgEV+oO0YYj6w1eRV1Abbry8knEDs+/IlDHAPzUwiXqU/MNQE2AlxLbmkc55mi8 Bzjw== 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=+ZTYfv6hRw07bv2cNyj+raDGfRtPwcQd8NrOrayA8JA=; b=dpBd/Rgi9Xv7OkLq/0fPnsGNbZDSiYmM893Cxn0o+2d/tdpN79qGt1/7QQ7FU2A0BW rpK/0HYjA2i2Gt1gXSB9tMQ7OYD9hQswcD/tNSuyrsjOzPhq09U+m6yqoLgGOWZyhMOK vMtG3vzUL0I3UVvxGuMGqmkbQx5VfVtiQR+yFT6WeB2sMNu9K3DEfS+8fOfnx9KYa2Rl da6grA3c+zlSJ6ilfb6kRMMuFrwe1UierDbTALJIsJ1nhT18SqPXuuIAvChjOfXGio2L 2FYC/pNwFyXppF6GlbRTSb6Q3gm3SyVpg6vYm3ygUXNWSVpNqapfM8kPzrO2WTWUupzb UYeQ== X-Gm-Message-State: AMke39ljPvd7kTk6QMHrKysZaCLk9qgEJiyB+WKW0PJANZiVtP9rRZXCbQU7q8Nl/7uyCw== X-Received: by 10.99.167.74 with SMTP id w10mr39082067pgo.2.1489431675494; Mon, 13 Mar 2017 12:01:15 -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 s21sm34072774pfs.87.2017.03.13.12.01.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 12:01:14 -0700 (PDT) Received: by mail-pg0-f45.google.com with SMTP id g2so50332980pge.3 for ; Mon, 13 Mar 2017 12:01:14 -0700 (PDT) X-Received: by 10.84.247.23 with SMTP id n23mr49661246pll.39.1489431674611; Mon, 13 Mar 2017 12:01:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.161.144 with HTTP; Mon, 13 Mar 2017 12:01:14 -0700 (PDT) In-Reply-To: References: <739e4cfc-8baf-0979-8d23-ec3a605f8a3a@nostrum.com> From: Roman Shpount Date: Mon, 13 Mar 2017 15:01:14 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Suhas Nandakumar Content-Type: multipart/alternative; boundary=f40304360834e1f8ea054aa155bb Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-ice-sip-sdp-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 19:01:57 -0000 --f40304360834e1f8ea054aa155bb Content-Type: text/plain; charset=UTF-8 On Mon, Mar 13, 2017 at 4:51 AM, Suhas Nandakumar wrote: > > Section 4.2.2.2.3 specifies, during offer processing, that the > implementation "SHOULD wait for [ICE] checks to complete" before sending an > answer. Keeping in mind that these updates typically happen with the SIP > UPDATE method, and given that RFC 3261 specifies "TUs SHOULD respond > immediately to non-INVITE requests" (cf. RFC3261 section 17.1), I'm > concerned about the timing implications here. We should minimally point out > that we're explicitly telling UAs to ignore this normative statement in > RFC3261, and make sure that we've done the analysis to ensure that we're > not going to cause problems for the SIP state machine (I'm concerned, in > particular, about unnecessary SIP retransmissions here). > > [Suhas] - I am not aware of any analysis being done. What do you suggest > we need to do ? > > I think current draft assumes that answers to session updates are note sent until ICE nomination is complete. I do not think this is realistic, especially when continuous nomination is used. My suggestion is to allow offer/answer exchanges in while ICE nomination is in process. I would also suggest that complete current list of ICE candidates should be sent in each of those of exchanges. I have sent the suggestion regarding this in earlier email today. Regards, _____________ Roman Shpount --f40304360834e1f8ea054aa155bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 13, 2017 at 4:51 AM, Suhas Nandakumar &l= t;suhasietf@gmail.= com> wrote:

=
Section 4.2.2.2.3 specifies, during offer processing, that the impleme= ntation "SHOULD wait for [ICE] checks to complete" before sending= an answer. Keeping in mind that these updates typically happen with the SI= P UPDATE method, and given that RFC 3261 specifies "TUs SHOULD respond= immediately to non-INVITE requests" (cf. RFC3261 section 17.1), I'= ;m concerned about the timing implications here. We should minimally point = out that we're explicitly telling UAs to ignore this normative statemen= t in RFC3261, and make sure that we've done the analysis to ensure that= we're not going to cause problems for the SIP state machine (I'm c= oncerned, in particular, about unnecessary SIP retransmissions here).

[Suhas] - I am not aware of any analysis being done= . What do you suggest we need to do ?


I think current draft assumes that answers to session= updates are note sent until ICE nomination is complete. I do not think thi= s is realistic, especially when continuous nomination is used. My suggestio= n is to allow offer/answer exchanges in while ICE nomination is in process.= I would also suggest that complete current list of ICE candidates should b= e sent in each of those of exchanges. I have sent the suggestion regarding = this in earlier email today.

Regards,
_____________
Roman Shpount
=C2=A0
--f40304360834e1f8ea054aa155bb-- From nobody Mon Mar 13 14:06:23 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 AD3DF12942F; Mon, 13 Mar 2017 14:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943917767.20345.3859994881763997620@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:06:17 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:06:17 -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 of the IETF. Title : Using Simulcast in SDP and RTP Sessions Authors : Bo Burman Magnus Westerlund Suhas Nandakumar Mo Zanaty Filename : draft-ietf-mmusic-sdp-simulcast-08.txt Pages : 35 Date : 2017-03-13 Abstract: In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 14:12:29 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 003A2129B97 for ; Mon, 13 Mar 2017 14:12: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 OjZsuKipbxUE for ; Mon, 13 Mar 2017 14:12:19 -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 CA648129B93 for ; Mon, 13 Mar 2017 14:12:18 -0700 (PDT) X-AuditID: c1b4fb30-3623498000006a1c-91-58c70b308b1e Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 7B.E3.27164.03B07C85; Mon, 13 Mar 2017 22:12:17 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 13 Mar 2017 22:11:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UZkgMkJCsRXeRm6TWvFAi/4KWGQlYf+XBn3XwZvuklg=; b=PUMCpN+TDD2LN79c0JJoqlK+A646sSmuOiU2G5YtYP1U2jT/pQGqqrkZg+bfL0l2t7xktG+2P+U1A1QtM8uX0PaVov/GpEDJ+NY/PuJ0/K3nkceaurJ1gwUeYGx67tiSy4ykF4qjBJvj7gtUXzdBO9pVHGnM/NkbGip9QWIK8o8= Received: from HE1PR0701MB2586.eurprd07.prod.outlook.com (10.168.187.22) by HE1PR0701MB2588.eurprd07.prod.outlook.com (10.168.187.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Mon, 13 Mar 2017 21:11:09 +0000 Received: from HE1PR0701MB2586.eurprd07.prod.outlook.com ([10.168.187.22]) by HE1PR0701MB2586.eurprd07.prod.outlook.com ([10.168.187.22]) with mapi id 15.01.0977.010; Mon, 13 Mar 2017 21:11:09 +0000 From: Bo Burman To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt Thread-Index: AQHSnD3CZhq8ut+tN0WAWH0a+QDVEKGTQ3EA Date: Mon, 13 Mar 2017 21:11:08 +0000 Message-ID: References: <148943917767.20345.3859994881763997620@ietfa.amsl.com> In-Reply-To: <148943917767.20345.3859994881763997620@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.209.201.5] x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2588; 7:17I/a5U3NA7Oi2ES+NLQD9antlvWWaOhPSUa/sb7p9t2BwDxW19zSjq3nQPRwUPtiTP1p7gPk/M5oBpiXB+1JjrDm3ei0n1qnqrDAW6xBcp3c/1qT72fV1GYZ0YXDew1jGSNokSgbgUoc1dnFna0kJY1Sv3rg7DdlvecOOrxaW1RDyO8sTIwL2TuDUjVuliPn3gkTXV+jrYWI/6uRmnQZ9/DPU3J2r+Ljtjmv2XXo4y6FO2MbNI5b76KflyRJ6ktpUP2O9tE4n+qZrZ8YDyXITOWQ4SfNjbL04GOAzMe32znWWusRPXTSGXRx7zQjAb+GylwRUjsHZLE2H3drMJ09A== x-ms-office365-filtering-correlation-id: 38b21d65-38b8-4162-f5e5-08d46a55786c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0701MB2588; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:HE1PR0701MB2588; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2588; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(13464003)(377424004)(76176999)(7696004)(50986999)(54356999)(6246003)(2950100002)(966004)(6916009)(99286003)(55016002)(38730400002)(110136004)(66066001)(6306002)(5660300001)(7736002)(2900100001)(53936002)(74316002)(5640700003)(6506006)(53546007)(25786008)(6436002)(229853002)(77096006)(122556002)(33656002)(305945005)(3280700002)(3660700001)(86362001)(2501003)(8936002)(2351001)(189998001)(102836003)(6116002)(3846002)(2906002)(230783001)(106116001)(1730700003)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2588; H:HE1PR0701MB2586.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 21:11:08.5548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2588 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUyM2K7ja4h9/EIg/mLuSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKcfdrIVTBOrWHf/I2sD4zTBLkZODgkBE4lDTa1MXYxcHEIC 6xgl3v+4wQbhnGCU+LT/CTOIwyLQyyxxdss1qLI5TBLPj/YwQzinGCVeHjvJAjKMTUBDYv6O u4wgtoiAusTXvSBFnBzCAvYSx9b9YIOIO0gc33OeCcI2kph9dit7FyMH0ApViV+fTUHCvAIJ Erd694CNFBJwlniwfh/YGE4BF4k5i5exg9iMAmIS30+tARvDLCAucevJfCaIfwQkluw5zwxh i0q8fPyPFeRORoFuRokP865BFSlIPPo3DSwhIdDHLHHl2m52iISvxPWzv6C6/SW+dC5lgbDz JZomH4CKW0ucWHyTBaJ5HpPE0o2dUAkZiUU7Wtkg7IWsEh1nFCC+l5K4e6WTEcKWkXhxZy8r xNk6Egt2f2KbwKgxC8kXs5CkIGxtiWULXzPPAoeMoMTJmU9YFjCyrGIULU4tTspNNzLSSy3K TC4uzs/Ty0st2cQITBMHt/w22MH48rnjIUYBDkYlHt4Pm49FCLEmlhVX5h5ilOBgVhLhjeE4 HiHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs1NSC1CKYLBMHp1QD46o4j5v7 U30Xpyiy3wq/efRUieL+K06FeSs8c2Ke9OcuPb9Seo107jbDmp2PVpsaij3MkpqtNdeoTH/K s0qe33OK033jNY5qcN86s9+lRs0vTUArt0a7aEVsgMXu//JzFj42vXOuTGJJ4Ydwr27tU7UC z+bMU6nXCg3w2xu4zdMjIlIj5N9jJZbijERDLeai4kQAWxJ4Lw8DAAA= Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 21:12:28 -0000 This update addresses all received comments: o Correcting syntax of SDP examples in section 6.6.1, as found by Inaki Baz Castillo. o Changing ABNF to only define the sc-value, not the SDP attribute itself, as suggested by Paul Kyzivat. o Changing I-D reference to newly published RFC 8108. /Bo (as individual) > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 13 mars 2017 22:06 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control of= the IETF. >=20 > Title : Using Simulcast in SDP and RTP Sessions > Authors : Bo Burman > Magnus Westerlund > Suhas Nandakumar > Mo Zanaty > Filename : draft-ietf-mmusic-sdp-simulcast-08.txt > Pages : 35 > Date : 2017-03-13 >=20 > Abstract: > In some application scenarios it may be desirable to send multiple > differently encoded versions of the same media source in different > RTP streams. This is called simulcast. This document describes how > to accomplish simulcast in RTP and how to signal it in SDP. The > described solution uses an RTP/RTCP identification method to identify > RTP streams belonging to the same media source, and makes an > extension to SDP to relate those RTP streams as being different > simulcast formats of that media source. The SDP extension consists > of a new media level SDP attribute that expresses capability to send > and/or receive simulcast RTP streams. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-simulcast-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 From nobody Mon Mar 13 14:36:59 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 2DD4E1294C7; Mon, 13 Mar 2017 14:36:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944101417.20377.9552056298328980312@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:36:54 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-25.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 21:36:54 -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 of the IETF. Title : Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. Authors : Christer Holmberg Roman Shpount Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-25.txt Pages : 26 Date : 2017-03-13 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 14:45:48 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 B07CA127058 for ; Mon, 13 Mar 2017 14:45:47 -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 beuzWlBJreDb for ; Mon, 13 Mar 2017 14:45:45 -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 249C2129477 for ; Mon, 13 Mar 2017 14:45:44 -0700 (PDT) X-AuditID: c1b4fb25-e49bd98000004cad-3f-58c71307d235 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 36.83.19629.70317C85; Mon, 13 Mar 2017 22:45:43 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Mon, 13 Mar 2017 22:45:17 +0100 From: Christer Holmberg To: Jonathan Lennox Thread-Topic: [MMUSIC] Handling of unverified data and media Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGOsIkAgAABT4CAAA4wAIAA+MdggAO42wD//9++UA== Date: Mon, 13 Mar 2017 21:44:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> In-Reply-To: <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB0B034ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsUyM2K7li678PEIg6XflCw27PvPbLHi9Tl2 i/cXdC1O3DjNbLF/8Xlmi6nLH7M4sHlM+b2R1WPnrLvsHgs2lXosWfKTyWPy4zZmj7Znd9gD 2KK4bFJSczLLUov07RK4Mo79usBesOU6U8XvZ1kNjDvOMXUxcnJICJhITP38gBXEFhJYxyjx fZdbFyMXkL2YUWJazx3mLkYODjYBC4nuf9ogNSICGhIXn31gA6lhFtjCKNGwpIkJpEZYwFri Sj8riCkiYCOx8lctRHmYxKo5R1hAbBYBVYn2lXPYQWxeAV+J97seM0KsWsUicaf3CNg9nAK2 Ei9m7mMGsRkFxCS+n1oDFmcWEJe49WQ+1M0CEkv2nGeGsEUlXj7+xwphK0ms2H6JEaI+X+Lt oTdMEMsEJU7OfMIygVFkFpJRs5CUzUJSNgvoBWYBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZf wMi+ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwQg9u+a26g/HyG8dDjAIcjEo8vB82H4sQ Yk0sK67MPcQowcGsJMKrsxEoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTU gtQimCwTB6dUA6PaJN/e1leLVzHtsuI03ym1asr2nB+iG7YpXGINj5v2sSQ11fjn8nc153Q2 VLSu8Z4rXa3Qvfs7u+e7D7uudVRFxJ0UcN52MjBtEfNbe4OZhwsdozRVtwr/23uYVfTmRVlG +8hXkm/9D1x6e295JkPT7S2FU0pcLgiJixRwezjIHLWOu6pYO02JpTgj0VCLuag4EQCBJJCA zAIAAA== Archived-At: Cc: Flemming Andreasen , Harald Alvestrand , mmusic Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 21:45:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB0B034ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklmIHRoZSBhbnN3ZXJlciBpcyBpbiBzdWNoIGEg4oCcaHVycnnigJ0gdG8gc3RhcnQg c2VuZGluZyBtZWRpYSwgb25lIHdvdWxkIHRoaW5rIGl0IGFsc28gbWFrZXMgc3VyZSB0aGUgYW5z d2VyIGlzIHNlbnQgYXMgZWFybHkgYXMgcG9zc2libGUsIHNvIHRoYXQgbWVkaWEgY2FuIGZsb3cg aW4gYm90aCBkaXJlY3Rpb25zLg0KDQpNeSBxdWVzdGlvbiBpczogaXMgdGhpcyBzb21ldGhpbmcg dGhhdOKAmXMgY2F1c2luZyBwcm9ibGVtcyBpbiByZWFsIGRlcGxveW1lbnRzLCBhbmQgcmVxdWly ZXMgYSBjaGFuZ2UgaW4gdGhlIHN0YW5kYXJkPyBUbyBtZSBpdCBzZWVtcyBsaWtlIHNvbWV0aGlu ZyB0aGF0IGlzIHZlcnkgdW5saWtlbHkgdG8gb2NjdXIsIG9yIGF0IGxlYXN0IGxpa2Ugc29tZXRo aW5nIHRoYXQgY2FuIGVhc2lseSBiZSBhdm9pZGVkIGJ5IGltcGxlbWVudGF0aW9uIG1lYW5z4oCm DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEpvbmF0aGFuIExlbm5veCBbbWFpbHRv OmpvbmF0aGFuQHZpZHlvLmNvbV0NClNlbnQ6IDEzIE1hcmNoIDIwMTcgMjA6MzcNClRvOiBDaHJp c3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IEVyaWMg UmVzY29ybGEgPGVrckBydGZtLmNvbT47IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21h aWwuY29tPjsgRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5jb20+OyBIYXJhbGQg QWx2ZXN0cmFuZCA8aHRhQGdvb2dsZS5jb20+OyBtbXVzaWMgPG1tdXNpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbTU1VU0lDXSBIYW5kbGluZyBvZiB1bnZlcmlmaWVkIGRhdGEgYW5kIG1lZGlh DQoNCg0KT24gTWFyIDExLCAyMDE3LCBhdCA5OjUyIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+PiB3cm90ZToNCg0KSGksDQoNCklzIHRoaXMgYSB0aGVvcmV0aWNhbCBpc3N1ZT8N Cg0KQXQgbGVhc3QgaWYgeW91IHVzZSBJQ0UsIHlvdSBhcmUgZ29pbmcgdG8gcmVjZWl2ZSB0aGUg YW5zd2VyIGJlZm9yZSB5b3UgcmVjZWl2ZSBhbnkgbWVkaWEsIGFzIHlvdSBhcmUgZ29pbmcgdG8g ZG8gdGhlIGNvbm5lY3Rpdml0eSBjaGVja3MgZXRjLg0KDQpObywgZXZlbiB3aXRoIElDRSBpdOKA mXMgcG9zc2libGUgZm9yIG1lZGlhIG9yIHRoZSBEVExTIGhhbmRzaGFrZSB0byBvdXRyYWNlIHRo ZSBhbnN3ZXIuDQoNClRoaXMgaXMgYmVjYXVzZSBJQ0Ugb2ZmZXJpbmcgZW5kcG9pbnRzIHJlc3Bv bmQgdG8gY29ubmVjdGl2aXR5IGNoZWNrcyBiZWZvcmUgdGhleSByZWNlaXZlIGFuIGFuc3dlci4g IFdoZW4gdGhlIGFuc3dlcmVyIHJlY2VpdmVzIHRoaXMgc3VjY2Vzc2Z1bCBjb25uZWN0aXZpdHkg Y2hlY2sgcmVzcG9uc2UsIGl0IHB1dHMgdGhlIHJlbGV2YW50IHBhaXIgaW4gdGhlIFZhbGlkIGxp c3QsIGFuZCB0aGVuIChpZiBpdCBoYXMgdGhlIGFjdGl2ZSByb2xlLCBhcyByZWNvbW1lbmRlZCkg Y2FuIGxlZ2l0aW1hdGVseSBpbml0aWF0ZSBEVExTIG9uIHRoaXMgcGFpci4NCg0KSWYgdHdvIElD RSBlbmRwb2ludHMgaGF2ZSBhIHNob3J0IFJUVCBhbmQgY2xlYXIgY29ubmVjdGl2aXR5IGJldHdl ZW4gdGhlbSwgYnV0IGEgbG9uZyBSVFQgdG8gdGhlaXIgc2lnbmFsaW5nIHNlcnZlciwgdGhpcyBj YW4gaGFwcGVuIHF1aXRlIGVhc2lseS4NCg0KDQpBbHNvLCBpbiByZWFsaXR5IHNvbWUgaW1wbGVt ZW50YXRpb25zIHdpbGwgbm90IGFjY2VwdCBjb250ZW50IGJlZm9yZSB0aGUgYW5zd2VyIGFycml2 ZXMg4oCTIG5vIG1hdHRlciBpZiBEVExTIGlzIHVzZWQgb3Igbm90IOKAkyBzbyB0aGUgYmVzdCB0 aGluZyBpcyB0bywgb25jZSB0aGUgYW5zd2VyIGhhcyBiZWVuIHNlbnQsIGp1c3Qgd2FpdCBmb3Ig YSB3aGlsZSBiZWZvcmUgc2VuZGluZyBhbnkgY29udGVudC4NCg0KRm9ydHVuYXRlbHksIERUTFMg aGFzIHJldHJhbnNtaXNzaW9ucywgc28gdGhpcyBzaG91bGRu4oCZdCBjYXVzZSBmYWlsdXJlLCBq dXN0IGEgYnJpZWYgc2V0dXAgZGVsYXkuDQoNCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpG cm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEVyaWMgUmVzY29ybGENClNlbnQ6IDExIE1hcmNoIDIwMTcgMDI6NTcNClRvOiBCZXJuYXJkIEFi b2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5j b20+Pg0KQ2M6IEZsZW1taW5nIEFuZHJlYXNlbiA8ZmFuZHJlYXNAY2lzY28uY29tPG1haWx0bzpm YW5kcmVhc0BjaXNjby5jb20+PjsgaHRhQGdvb2dsZS5jb208bWFpbHRvOmh0YUBnb29nbGUuY29t PjsgbW11c2ljIFdHIDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW01NVVNJQ10gSGFuZGxpbmcgb2YgdW52ZXJpZmllZCBkYXRhIGFuZCBtZWRp YQ0KDQpTb3JyeSwgbm8sIEkgd2FzIGp1c3QgdGFsa2luZyBhYm91dCB3aGF0IG1pZ2h0IG9yIG1p Z2h0IG5vdCBiZSBzYWZlLi4uLiBUaGUgZG9jIHRleHQgaXMNCmEgZGlmZmVyZW50IHF1ZXN0aW9u Lg0KDQotRWtyDQoNCg0KT24gRnJpLCBNYXIgMTAsIDIwMTcgYXQgNDowNSBQTSwgQmVybmFyZCBB Ym9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwu Y29tPj4gd3JvdGU6DQpFS1Igc2FpZDoNCg0KIkkgaGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0aW1l IG9uIGl0LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBvdWdodCB0byBiZSBzYWZlIHRvIGhvbGQNCmFu eXRoaW5nIHlvdSByZWNlaXZlIHByaW9yIHRvIGdldHRpbmcgdGhlIGZpbmdlcnByaW50LiBJdCBt aWdodCBiZSBiZXR0ZXIsIGFzIE1UDQpzdWdnZXN0cywgdG8gZGlzY2FyZCB0aGUgZGF0YWNoYW5u ZWwgZGF0YSwgYnV0IEknbSBub3Qgc3VyZSB3aHkgaXQgd291bGQgYmUNCm5lY2Vzc2FyeS4iDQoN CltCQV0gU28geW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgTVVTVCBOT1QgYWxsb3dzIHRoZSBicm93 c2VyIHRvIGJ1ZmZlciBkYXRhL21lZGlhIGJ1dCBub3QgdG8gcGFzcyBpdCB0byB0aGUgYXBwbGlj YXRpb24gKGluIHRoZSBjYXNlIG9mIHRoZSBkYXRhIGNoYW5uZWwpIG9yIHRvIHBsYXkgaXQgb3V0 Pw0KDQpPbiBGcmksIE1hciAxMCwgMjAxNyBhdCA0OjAxIFBNLCBFcmljIFJlc2NvcmxhIDxla3JA cnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KSSBoYXZlbid0IHNwZW50IHRv byBtdWNoIHRpbWUgb24gaXQsIGJ1dCBpdCBzZWVtcyBsaWtlIGl0IG91Z2h0IHRvIGJlIHNhZmUg dG8gaG9sZA0KYW55dGhpbmcgeW91IHJlY2VpdmUgcHJpb3IgdG8gZ2V0dGluZyB0aGUgZmluZ2Vy cHJpbnQuIEl0IG1pZ2h0IGJlIGJldHRlciwgYXMgTVQNCnN1Z2dlc3RzLCB0byBkaXNjYXJkIHRo ZSBkYXRhY2hhbm5lbCBkYXRhLCBidXQgSSdtIG5vdCBzdXJlIHdoeSBpdCB3b3VsZCBiZQ0KbmVj ZXNzYXJ5Lg0KDQotRWtyDQoNCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0IDI6NDcgUE0sIFJvbWFu IFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdy b3RlOg0KTXkgYXNzdW1wdGlvbiBhbHdheXMgd2FzIHRoYXQgZGF0YSBpcyByZWNlaXZlZCwgZGVj b2RlZCBhbmQgZGlzY2FyZGVkIHVudGlsIGZpbmdlcnByaW50IGlzIHJlY2VpdmVkIGFuZCB2ZXJp ZmllZC4gVGhpcyB3YXkgRFRMUyBoYW5kc2hha2UgY29tcGxldGVzLCBrZXkgZnJhbWVzIGFyZSBk ZWNvZGVkLCBidXQgdXNlciBpcyBub3IgcHJlc2VudGVkIHdpdGggYW55IHVudmVyaWZpZWQgbWVk aWEuDQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVGh1 LCBNYXIgOSwgMjAxNyBhdCA2OjU4IFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25A Z21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCkkgdGhp bmsgdGhhdCB0aGUgZGF0YSBjaGFubmVsIHF1ZXN0aW9uIGlzIGVhc3ksIGFueXRoaW5nIG90aGVy IHRoYW4gYQ0KIm5vIiBpcyBub3QgYWNjZXB0YWJsZS4gIERhdGEgaW4gdGhhdCBmb3JtIGVudGVy cyB0aGUgc2VjdXJpdHkNCmJvdW5kYXJ5IGZvciBhbiBvcmlnaW4gYW5kIGl0IGRvZXNuJ3QgbWFr ZSBhbnkgc2Vuc2UgdG8gcmlzayBhdHRhY2sNCnRoZXJlLiAgKEl0J3MgYWxzbyBsaWtlbHkgdW5u ZWNlc3NhcnksIGlmIGEgaGFsZiBhIHJvdW5kIHRyaXAgb2YNCnNpZ25hbGluZyBpcyBzbG93ZXIg dGhhbiA1IHJvdW5kIHRyaXBzIG9uIHRoZSBtZWRpYSBwYXRoLCB0aGVuDQpzb21ldGhpbmcgaXMg bWVzc2VkIHVwLikNCg0KSSdtIGluIHR3byBtaW5kcyBhYm91dCB0aGUgbWVkaWEgcGFydC4gRm9y IG1lZGlhLCB5b3UgY291bGQgYWxzbw0KcmVhc29uYWJseSBtYWtlIHRoZSBzYW1lIG9yaWdpbi1w dXJpdHkgYXJndW1lbnQuICBJJ20gaW5jbGluZWQgdG8gc2F5DQp0aGF0LiAgQnV0IHdlIENBTiBp c29sYXRlIG1lZGlhIGZyb20gdGhlIG9yaWdpbiAoYW5kIHdlIGRlZmluaXRlbHkNCnNob3VsZCBp ZiB3ZSBhbGxvdyB0aGlzKS4NCg0KU28sIHRoZSBtZWRpYSB0aGF0IGFycml2ZXMgaGFkIHRvIGNv bXBseSB3aXRoIHlvdXIgb2ZmZXIuICBUaGUgRFRMUw0KaGFuZHNoYWtlIGFsc28gaGFzIHRvIGNv bXBsZXRlLCB3aGljaCB0ZWxscyB0aGUgcmVjZWl2ZXIgd2hldGhlciB0aGUNCm1lZGlhIG5lZWRz IHRvIGJlIGNvbmZpZGVudGlhbCBvciBub3QgKGF0IHdoaWNoIHBvaW50IHlvdSBjYW4gZGlzYWJs ZQ0KdGhpcyBmZWF0dXJlKS4NCg0KSXQncyBhbHNvIHBvc3NpYmxlIHRoYXQgYSByZWNlaXZlciBj YW4gcmVxdWlyZSB0aGF0IGFuIElDRQ0KY29ubmVjdGl2aXR5IGNoZWNrIHdhcyBtYWRlICh0aG91 Z2ggdGhpcyBpcyBpbmJvdW5kIG9ubHksIGFuZCBJJ20NCnVuY2xlYXIgb24gd2hldGhlciBoYXZp bmcgcmVjZWl2ZWQgYW4gaW5ib3VuZCBjaGVjayB3b3VsZCBub3JtYWxseQ0KcHJldmVudCB0aGUg cmVjZWl2ZXIgZnJvbSBhY2NlcHRpbmcgYSBwYWNrZXQpLg0KDQpBbGwgdG9sZCwgdGhhdCdzIGEg bG90IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZWdvdGlhdGVkIHNlc3Npb24gZm9yDQphbiBh dHRhY2tlciB0byBoYXZlLiAgVGhlIG9kZHMgb2YgdGhpcyBiZWluZyBhbiBhdHRhY2sgd291bGQg KnNlZW0qIHRvDQpiZSBsb3cuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCB3ZSBkb24ndCBhc3N1bWUg Y29uZmlkZW50aWFsaXR5IG9mIHNpZ25hbGluZzsgdGhlDQpzZWN1cml0eSBtb2RlbCBhc3N1bWVz IHRoYXQgYWxsIHRoaXMgaW5mb3JtYXRpb24gaXMgZWZmZWN0aXZlbHkgcHVibGljDQphbmQgdGhl IHByb3RlY3Rpb24gd2UgaGF2ZSBhZ2FpbnN0IGF0dGFjayBpcyB0aGUgY2VydGlmaWNhdGUNCmZp bmdlcnByaW50LiAgVGhpcyB3b3VsZCByZW1vdmUgdGhhdCBwcm90ZWN0aW9uLCBhbGJlaXQgZm9y IGEgc2hvcnQNCmR1cmF0aW9uLg0KDQpJIGhhdmUgYW4gZXh0cmEgcXVlc3Rpb246IGRvZXMgYW55 b25lIHBsYW4gdG8gaW1wbGVtZW50IHRoaXM/ICBJdCdzDQpub24tdHJpdmlhbC4gIEkgdGhpbmsg dGhhdCBJIGtub3cgd2hhdCBJJ2QgbmVlZCB0byBkbyBpbiBGaXJlZm94IGFuZA0KaXQgd291bGQg YmUgcXVpdGUgZGlzcnVwdGl2ZS4gIEJlZm9yZSBjb21taXR0aW5nIHRvIGRvIHRoYXQgd29yaw0K KHdoaWNoIEkgd2lsbCBsZWF2ZSB0byBvdGhlcnMgY2xvc2VyIHRvIHRoaXMgdG8gZGVjaWRlKSwg SSdkIHByb2JhYmx5DQp3YW50IG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIGFjdHVhbCBhZHZhbnRh Z2UgdGhhdCBpdCBwcm92aWRlcy4NCg0KT24gMTAgTWFyY2ggMjAxNyBhdCAwNzoxMCwgQmVybmFy ZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb208bWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21h aWwuY29tPj4gd3JvdGU6DQo+IEluIHRoZSBXM0MgV0VCUlRDIFdHLCBhbiBpc3N1ZSBoYXMgYmVl biBzdWJtaXR0ZWQgcmVsYXRpbmcgdG8gcGxheW91dCBvZg0KPiB1bnZlcmlmaWVkIG1lZGlhOg0K PiBodHRwczovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9pc3N1ZXMvODQ5DQo+DQo+IEl0IGhh cyBiZWVuIHN1Z2dlc3RlZCB0aGF0IGlmIHRoZSBicm93c2VyIGlzIGNvbmZpZ3VyZWQgdG8gZG8g c28sIHRoYXQNCj4gcGxheW91dCBiZSBhbGxvd2VkIGZvciBhIGxpbWl0ZWQgcGVyaW9kIChlLmcu IDUgc2Vjb25kcykgcHJpb3IgdG8NCj4gZmluZ2VycHJpbnQgdmVyaWZpY2F0aW9uOg0KPiBodHRw czovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9wdWxsLzEwMjYNCj4NCj4gU2VjdGlvbiA2LjIg b2YgZHJhZnQtaWV0Zi1tbXVzaWMtNDU3Mi11cGRhdGUtMTMgY29udGFpbnMgdGhlIGZvbGxvd2lu ZyB0ZXh0LA0KPiBjYXJyaWVkIG92ZXIgZnJvbSBSRkMgNDU3MjoNCj4NCj4gICAgTm90ZSB0aGF0 IHdoZW4gdGhlIG9mZmVyL2Fuc3dlciBtb2RlbCBpcyBiZWluZyB1c2VkLCBpdCBpcyBwb3NzaWJs ZQ0KPiAgICBmb3IgYSBtZWRpYSBjb25uZWN0aW9uIHRvIG91dHJhY2UgdGhlIGFuc3dlciBiYWNr IHRvIHRoZSBvZmZlcmVyLg0KPiAgICBUaHVzLCBpZiB0aGUgb2ZmZXJlciBoYXMgb2ZmZXJlZCBh ICdzZXR1cDpwYXNzaXZlJyBvciAnc2V0dXA6YWN0cGFzcycNCj4gICAgcm9sZSwgaXQgTVVTVCAo YXMgc3BlY2lmaWVkIGluIFJGQyA0MTQ1IFs3XSkgYmVnaW4gbGlzdGVuaW5nIGZvciBhbg0KPiAg ICBpbmNvbWluZyBjb25uZWN0aW9uIGFzIHNvb24gYXMgaXQgc2VuZHMgaXRzIG9mZmVyLiAgSG93 ZXZlciwgaXQgTVVTVA0KPiAgICBOT1QgYXNzdW1lIHRoYXQgdGhlIGRhdGEgdHJhbnNtaXR0ZWQg b3ZlciB0aGUgVExTIGNvbm5lY3Rpb24gaXMgdmFsaWQNCj4gICAgdW50aWwgaXQgaGFzIHJlY2Vp dmVkIGEgbWF0Y2hpbmcgZmluZ2VycHJpbnQgaW4gYW4gU0RQIGFuc3dlci4gIElmDQo+ICAgIHRo ZSBmaW5nZXJwcmludCwgb25jZSBpdCBhcnJpdmVzLCBkb2VzIG5vdCBtYXRjaCB0aGUgY2xpZW50 J3MNCj4gICAgY2VydGlmaWNhdGUsIHRoZSBzZXJ2ZXIgZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUg dGhlIG1lZGlhIGNvbm5lY3Rpb24NCj4gICAgd2l0aCBhIGJhZF9jZXJ0aWZpY2F0ZSBlcnJvciwg YXMgc3RhdGVkIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguDQo+DQo+IEdpdmVuIHRoZSBvdXRz dGFuZGluZyBpc3N1ZSByZWxhdGluZyB0byBoYW5kbGluZyBvZiB1bnZlcmlmaWVkIG1lZGlhLCB0 aGUNCj4gQ2hhaXJzIG9mIHRoZSBXM0MgV0VCUlRDIFdHIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBj bGFyaWZpY2F0aW9uIGZyb20gdGhlDQo+IElFVEYgTU1VU0lDIFdHIGFzIHRvIHRoZSBtZWFuaW5n IG9mIHRoZSAiTVVTVCBOT1QiIGluIHRoZSBhYm92ZSBwYXJhZ3JhcGguDQo+IEluIHBhcnRpY3Vs YXIsIHdoYXQgaXMgaXQgcGVybWl0dGVkIGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0byBkbyB3aXRo DQo+IHJlY2VpdmVkIGRhdGEgYW5kIG1lZGlhIHByaW9yIHRvIHZlcmlmaWNhdGlvbj8gRm9yIGV4 YW1wbGU6DQo+DQo+ICAgICAgMS4gTWF5IGRhdGEgcmVjZWl2ZWQgb3ZlciB0aGUgZGF0YSBjaGFu bmVsIGJlIHByb3ZpZGVkIHRvIHRoZQ0KPiBhcHBsaWNhdGlvbiBwcmlvciB0byB2ZXJpZmljYXRp b24/DQo+ICAgICAgICAgIGEuIElmIHRoZSBhbnN3ZXIgdG8gdGhlIGFib3ZlIGlzICJubyIsIG1h eSB1bnZlcmlmaWVkIHJlY2VpdmVkIGRhdGENCj4gYmUgZGVsaXZlcmVkIGJ5IHRoZSBEVExTIHRy YW5zcG9ydCB0byBTQ1RQLCB3aGljaCBtYXkgYnVmZmVyIGl0Pw0KPiAgICAgIDIuIE1heSByZWNl aXZlZCBtZWRpYSBiZSBwbGF5ZWQgb3V0IHByaW9yIHRvIHZlcmlmaWNhdGlvbj8NCj4NCj4gQmVy bmFyZCBBYm9iYQ0KPiBPbiBiZWhhbGYgb2YgdGhlIFczQyBXRUJSVEMgV0cNCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW11c2ljIG1haWxp bmcgbGlzdA0KPiBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxp c3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2lj QGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVz aWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB0B034ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt c3BhY2U7fQ0Kc3Bhbi5tLTU0MzQzMTkxMDg1NTY2MDk0MTltLTY4NTY1NjMyNzM2NjQwMzU0MzVo b2VuemINCgl7bXNvLXN0eWxlLW5hbWU6bS01NDM0MzE5MTA4NTU2NjA5NDE5bS02ODU2NTYzMjcz NjY0MDM1NDM1aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+SWYgdGhlIGFuc3dlcmVyIGlzIGluIHN1Y2ggYSDigJxodXJyeeKAnSB0byBzdGFy dCBzZW5kaW5nIG1lZGlhLCBvbmUgd291bGQgdGhpbmsgaXQgYWxzbyBtYWtlcyBzdXJlIHRoZSBh bnN3ZXIgaXMgc2VudCBhcyBlYXJseSBhcyBwb3NzaWJsZSwNCiBzbyB0aGF0IG1lZGlhIGNhbiBm bG93IGluIGJvdGggZGlyZWN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPk15IHF1ZXN0aW9uIGlzOiBpcyB0aGlzIHNvbWV0aGluZyB0aGF04oCZcyBjYXVzaW5n IHByb2JsZW1zIGluIHJlYWwgZGVwbG95bWVudHMsIGFuZCByZXF1aXJlcyBhIGNoYW5nZSBpbiB0 aGUgc3RhbmRhcmQ/IFRvIG1lIGl0IHNlZW1zDQogbGlrZSBzb21ldGhpbmcgdGhhdCBpcyB2ZXJ5 IHVubGlrZWx5IHRvIG9jY3VyLCBvciBhdCBsZWFzdCBsaWtlIHNvbWV0aGluZyB0aGF0IGNhbiBl YXNpbHkgYmUgYXZvaWRlZCBieSBpbXBsZW1lbnRhdGlvbiBtZWFuc+KApjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpvbmF0aGFuIExlbm5veCBb bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMyBNYXJjaCAy MDE3IDIwOjM3PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRXJpYyBSZXNjb3JsYSAm bHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgQmVybmFyZCBBYm9iYSAmbHQ7YmVybmFyZC5hYm9iYUBnbWFp bC5jb20mZ3Q7OyBGbGVtbWluZyBBbmRyZWFzZW4gJmx0O2ZhbmRyZWFzQGNpc2NvLmNvbSZndDs7 IEhhcmFsZCBBbHZlc3RyYW5kICZsdDtodGFAZ29vZ2xlLmNvbSZndDs7IG1tdXNpYyAmbHQ7bW11 c2ljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gSGFuZGxp bmcgb2YgdW52ZXJpZmllZCBkYXRhIGFuZCBtZWRpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAxMSwgMjAxNywgYXQgOTo1MiBBTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXMgdGhpcyBhIHRoZW9yZXRp Y2FsIGlzc3VlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QXQgbGVhc3QgaWYgeW91IHVzZSBJQ0UsIHlvdSBh cmUgZ29pbmcgdG8gcmVjZWl2ZSB0aGUgYW5zd2VyIGJlZm9yZSB5b3UgcmVjZWl2ZSBhbnkgbWVk aWEsIGFzIHlvdSBhcmUgZ29pbmcgdG8gZG8gdGhlIGNvbm5lY3Rpdml0eSBjaGVja3MgZXRjLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObywgZXZlbiB3aXRoIElDRSBpdOKAmXMgcG9zc2li bGUgZm9yIG1lZGlhIG9yIHRoZSBEVExTIGhhbmRzaGFrZSB0byBvdXRyYWNlIHRoZSBhbnN3ZXIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgaXMgYmVjYXVzZSBJQ0Ugb2ZmZXJpbmcgZW5kcG9pbnRzIHJlc3BvbmQgdG8gY29ubmVjdGl2 aXR5IGNoZWNrcyBiZWZvcmUgdGhleSByZWNlaXZlIGFuIGFuc3dlci4gJm5ic3A7V2hlbiB0aGUg YW5zd2VyZXIgcmVjZWl2ZXMgdGhpcyBzdWNjZXNzZnVsIGNvbm5lY3Rpdml0eSBjaGVjayByZXNw b25zZSwgaXQgcHV0cyB0aGUgcmVsZXZhbnQgcGFpciBpbiB0aGUgVmFsaWQgbGlzdCwgYW5kIHRo ZW4gKGlmIGl0IGhhcw0KIHRoZSBhY3RpdmUgcm9sZSwgYXMgcmVjb21tZW5kZWQpIGNhbiBsZWdp dGltYXRlbHkgaW5pdGlhdGUgRFRMUyBvbiB0aGlzIHBhaXIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHR3byBJQ0UgZW5kcG9pbnRzIGhh dmUgYSBzaG9ydCBSVFQgYW5kIGNsZWFyIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIHRoZW0sIGJ1dCBh IGxvbmcgUlRUIHRvIHRoZWlyIHNpZ25hbGluZyBzZXJ2ZXIsIHRoaXMgY2FuIGhhcHBlbiBxdWl0 ZSBlYXNpbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFsc28sIGluIHJlYWxpdHkgc29tZSBpbXBs ZW1lbnRhdGlvbnMgd2lsbCBub3QgYWNjZXB0IGNvbnRlbnQgYmVmb3JlIHRoZSBhbnN3ZXIgYXJy aXZlcyDigJMgbm8gbWF0dGVyIGlmIERUTFMgaXMgdXNlZCBvciBub3Qg4oCTIHNvIHRoZSBiZXN0 IHRoaW5nIGlzIHRvLCBvbmNlIHRoZQ0KIGFuc3dlciBoYXMgYmVlbiBzZW50LCBqdXN0IHdhaXQg Zm9yIGEgd2hpbGUgYmVmb3JlIHNlbmRpbmcgYW55IGNvbnRlbnQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvcnR1 bmF0ZWx5LCBEVExTIGhhcyByZXRyYW5zbWlzc2lvbnMsIHNvIHRoaXMgc2hvdWxkbuKAmXQgY2F1 c2UgZmFpbHVyZSwganVzdCBhIGJyaWVmIHNldHVwIGRlbGF5LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5tbXVzaWMNCiBbPGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjExIE1hcmNoIDIwMTcgMDI6NTc8 YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdt YWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVybmFyZC5hYm9iYUBnbWFpbC5j b208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZsZW1taW5nIEFuZHJlYXNlbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZmFu ZHJlYXNAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aHRhQGdvb2dsZS5jb20iPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0YUBnb29nbGUuY29tPC9zcGFuPjwvYT47DQogbW11 c2ljIFdHICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5tbXVzaWNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmU6IFtNTVVTSUNdIEhhbmRsaW5nIG9mIHVudmVyaWZpZWQgZGF0YSBhbmQgbWVkaWE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Tb3JyeSwgbm8sIEkgd2FzIGp1c3QgdGFsa2luZyBhYm91dCB3aGF0IG1pZ2h0IG9yIG1p Z2h0IG5vdCBiZSBzYWZlLi4uLiBUaGUgZG9jIHRleHQgaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIGRpZmZlcmVudCBxdWVzdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBNYXIgMTAsIDIwMTcgYXQgNDowNSBQTSwgQmVybmFyZCBBYm9iYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L3NwYW4+ PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5FS1Igc2FpZDombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OzxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPkkgaGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0aW1lIG9u IGl0LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBvdWdodCB0byBiZSBzYWZlIHRvIGhvbGQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5hbnl0aGluZyB5b3UgcmVj ZWl2ZSBwcmlvciB0byBnZXR0aW5nIHRoZSBmaW5nZXJwcmludC4gSXQgbWlnaHQgYmUgYmV0dGVy LCBhcyBNVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPnN1 Z2dlc3RzLCB0byBkaXNjYXJkIHRoZSBkYXRhY2hhbm5lbCBkYXRhLCBidXQgSSdtIG5vdCBzdXJl IHdoeSBpdCB3b3VsZCBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPm5lY2Vzc2FyeS48L3NwYW4+JnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PltCQV0gU28geW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgTVVTVCBOT1QgYWxsb3dzIHRoZSBicm93 c2VyIHRvIGJ1ZmZlciBkYXRhL21lZGlhIGJ1dCBub3QgdG8gcGFzcyBpdCB0byB0aGUgYXBwbGlj YXRpb24gKGluIHRoZSBjYXNlIG9mIHRoZSBkYXRhIGNoYW5uZWwpIG9yIHRvIHBsYXkgaXQgb3V0 PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDEw LCAyMDE3IGF0IDQ6MDEgUE0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JA cnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5la3JA cnRmbS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlbid0IHNwZW50IHRvbyBtdWNo IHRpbWUgb24gaXQsIGJ1dCBpdCBzZWVtcyBsaWtlIGl0IG91Z2h0IHRvIGJlIHNhZmUgdG8gaG9s ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YW55dGhpbmcgeW91IHJlY2VpdmUgcHJpb3IgdG8gZ2V0dGluZyB0aGUgZmlu Z2VycHJpbnQuIEl0IG1pZ2h0IGJlIGJldHRlciwgYXMgTVQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN1Z2dlc3RzLCB0 byBkaXNjYXJkIHRoZSBkYXRhY2hhbm5lbCBkYXRhLCBidXQgSSdtIG5vdCBzdXJlIHdoeSBpdCB3 b3VsZCBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+bmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t RWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgTWFyIDEwLCAyMDE3 IGF0IDI6NDcgUE0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJvbWFu QHRlbHVyaXguY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgYXNzdW1wdGlvbiBhbHdheXMgd2FzIHRo YXQgZGF0YSBpcyByZWNlaXZlZCwgZGVjb2RlZCBhbmQgZGlzY2FyZGVkIHVudGlsIGZpbmdlcnBy aW50IGlzIHJlY2VpdmVkIGFuZCB2ZXJpZmllZC4gVGhpcyB3YXkgRFRMUyBoYW5kc2hha2UgY29t cGxldGVzLCBrZXkgZnJhbWVzIGFyZSBkZWNvZGVkLCBidXQgdXNlciBpcyBub3IgcHJlc2VudGVk IHdpdGggYW55IHVudmVyaWZpZWQgbWVkaWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f XzxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0ibS01NDM0MzE5 MTA4NTU2NjA5NDE5bS02ODU2NTYzMjczNjY0MDM1NDM1aG9lbnpiIj5Sb21hbiBTaHBvdW50PC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTWFy IDksIDIwMTcgYXQgNjo1OCBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzpt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhh dCB0aGUgZGF0YSBjaGFubmVsIHF1ZXN0aW9uIGlzIGVhc3ksIGFueXRoaW5nIG90aGVyIHRoYW4g YTxicj4NCiZxdW90O25vJnF1b3Q7IGlzIG5vdCBhY2NlcHRhYmxlLiZuYnNwOyBEYXRhIGluIHRo YXQgZm9ybSBlbnRlcnMgdGhlIHNlY3VyaXR5PGJyPg0KYm91bmRhcnkgZm9yIGFuIG9yaWdpbiBh bmQgaXQgZG9lc24ndCBtYWtlIGFueSBzZW5zZSB0byByaXNrIGF0dGFjazxicj4NCnRoZXJlLiZu YnNwOyAoSXQncyBhbHNvIGxpa2VseSB1bm5lY2Vzc2FyeSwgaWYgYSBoYWxmIGEgcm91bmQgdHJp cCBvZjxicj4NCnNpZ25hbGluZyBpcyBzbG93ZXIgdGhhbiA1IHJvdW5kIHRyaXBzIG9uIHRoZSBt ZWRpYSBwYXRoLCB0aGVuPGJyPg0Kc29tZXRoaW5nIGlzIG1lc3NlZCB1cC4pPGJyPg0KPGJyPg0K SSdtIGluIHR3byBtaW5kcyBhYm91dCB0aGUgbWVkaWEgcGFydC4gRm9yIG1lZGlhLCB5b3UgY291 bGQgYWxzbzxicj4NCnJlYXNvbmFibHkgbWFrZSB0aGUgc2FtZSBvcmlnaW4tcHVyaXR5IGFyZ3Vt ZW50LiZuYnNwOyBJJ20gaW5jbGluZWQgdG8gc2F5PGJyPg0KdGhhdC4mbmJzcDsgQnV0IHdlIENB TiBpc29sYXRlIG1lZGlhIGZyb20gdGhlIG9yaWdpbiAoYW5kIHdlIGRlZmluaXRlbHk8YnI+DQpz aG91bGQgaWYgd2UgYWxsb3cgdGhpcykuPGJyPg0KPGJyPg0KU28sIHRoZSBtZWRpYSB0aGF0IGFy cml2ZXMgaGFkIHRvIGNvbXBseSB3aXRoIHlvdXIgb2ZmZXIuJm5ic3A7IFRoZSBEVExTPGJyPg0K aGFuZHNoYWtlIGFsc28gaGFzIHRvIGNvbXBsZXRlLCB3aGljaCB0ZWxscyB0aGUgcmVjZWl2ZXIg d2hldGhlciB0aGU8YnI+DQptZWRpYSBuZWVkcyB0byBiZSBjb25maWRlbnRpYWwgb3Igbm90IChh dCB3aGljaCBwb2ludCB5b3UgY2FuIGRpc2FibGU8YnI+DQp0aGlzIGZlYXR1cmUpLjxicj4NCjxi cj4NCkl0J3MgYWxzbyBwb3NzaWJsZSB0aGF0IGEgcmVjZWl2ZXIgY2FuIHJlcXVpcmUgdGhhdCBh biBJQ0U8YnI+DQpjb25uZWN0aXZpdHkgY2hlY2sgd2FzIG1hZGUgKHRob3VnaCB0aGlzIGlzIGlu Ym91bmQgb25seSwgYW5kIEknbTxicj4NCnVuY2xlYXIgb24gd2hldGhlciBoYXZpbmcgcmVjZWl2 ZWQgYW4gaW5ib3VuZCBjaGVjayB3b3VsZCBub3JtYWxseTxicj4NCnByZXZlbnQgdGhlIHJlY2Vp dmVyIGZyb20gYWNjZXB0aW5nIGEgcGFja2V0KS48YnI+DQo8YnI+DQpBbGwgdG9sZCwgdGhhdCdz IGEgbG90IG9mIGluZm9ybWF0aW9uIGFib3V0IHRoZSBuZWdvdGlhdGVkIHNlc3Npb24gZm9yPGJy Pg0KYW4gYXR0YWNrZXIgdG8gaGF2ZS4mbmJzcDsgVGhlIG9kZHMgb2YgdGhpcyBiZWluZyBhbiBh dHRhY2sgd291bGQgKnNlZW0qIHRvPGJyPg0KYmUgbG93Ljxicj4NCjxicj4NCk9uIHRoZSBvdGhl ciBoYW5kLCB3ZSBkb24ndCBhc3N1bWUgY29uZmlkZW50aWFsaXR5IG9mIHNpZ25hbGluZzsgdGhl PGJyPg0Kc2VjdXJpdHkgbW9kZWwgYXNzdW1lcyB0aGF0IGFsbCB0aGlzIGluZm9ybWF0aW9uIGlz IGVmZmVjdGl2ZWx5IHB1YmxpYzxicj4NCmFuZCB0aGUgcHJvdGVjdGlvbiB3ZSBoYXZlIGFnYWlu c3QgYXR0YWNrIGlzIHRoZSBjZXJ0aWZpY2F0ZTxicj4NCmZpbmdlcnByaW50LiZuYnNwOyBUaGlz IHdvdWxkIHJlbW92ZSB0aGF0IHByb3RlY3Rpb24sIGFsYmVpdCBmb3IgYSBzaG9ydDxicj4NCmR1 cmF0aW9uLjxicj4NCjxicj4NCkkgaGF2ZSBhbiBleHRyYSBxdWVzdGlvbjogZG9lcyBhbnlvbmUg cGxhbiB0byBpbXBsZW1lbnQgdGhpcz8mbmJzcDsgSXQnczxicj4NCm5vbi10cml2aWFsLiZuYnNw OyBJIHRoaW5rIHRoYXQgSSBrbm93IHdoYXQgSSdkIG5lZWQgdG8gZG8gaW4gRmlyZWZveCBhbmQ8 YnI+DQppdCB3b3VsZCBiZSBxdWl0ZSBkaXNydXB0aXZlLiZuYnNwOyBCZWZvcmUgY29tbWl0dGlu ZyB0byBkbyB0aGF0IHdvcms8YnI+DQood2hpY2ggSSB3aWxsIGxlYXZlIHRvIG90aGVycyBjbG9z ZXIgdG8gdGhpcyB0byBkZWNpZGUpLCBJJ2QgcHJvYmFibHk8YnI+DQp3YW50IG1vcmUgaW5mb3Jt YXRpb24gb24gdGhlIGFjdHVhbCBhZHZhbnRhZ2UgdGhhdCBpdCBwcm92aWRlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KT24gMTAgTWFyY2ggMjAxNyBhdCAwNzoxMCwgQmVybmFyZCBBYm9iYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L3NwYW4+PC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0OyBJbiB0aGUgVzNDIFdFQlJUQyBXRywgYW4gaXNzdWUgaGFzIGJl ZW4gc3VibWl0dGVkIHJlbGF0aW5nIHRvIHBsYXlvdXQgb2Y8YnI+DQomZ3Q7IHVudmVyaWZpZWQg bWVkaWE6PGJyPg0KJmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9pc3N1ZXMv ODQ5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9n aXRodWIuY29tL3czYy93ZWJydGMtcGMvaXNzdWVzLzg0OTwvc3Bhbj48L2E+PGJyPg0KJmd0Ozxi cj4NCiZndDsgSXQgaGFzIGJlZW4gc3VnZ2VzdGVkIHRoYXQgaWYgdGhlIGJyb3dzZXIgaXMgY29u ZmlndXJlZCB0byBkbyBzbywgdGhhdDxicj4NCiZndDsgcGxheW91dCBiZSBhbGxvd2VkIGZvciBh IGxpbWl0ZWQgcGVyaW9kIChlLmcuIDUgc2Vjb25kcykgcHJpb3IgdG88YnI+DQomZ3Q7IGZpbmdl cnByaW50IHZlcmlmaWNhdGlvbjo8YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2Vi cnRjLXBjL3B1bGwvMTAyNiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPmh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2VicnRjLXBjL3B1bGwvMTAyNjwvc3Bhbj48L2E+ PGJyPg0KJmd0Ozxicj4NCiZndDsgU2VjdGlvbiA2LjIgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtNDU3 Mi11cGRhdGUtMTMgY29udGFpbnMgdGhlIGZvbGxvd2luZyB0ZXh0LDxicj4NCiZndDsgY2Fycmll ZCBvdmVyIGZyb20gUkZDIDQ1NzI6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IE5v dGUgdGhhdCB3aGVuIHRoZSBvZmZlci9hbnN3ZXIgbW9kZWwgaXMgYmVpbmcgdXNlZCwgaXQgaXMg cG9zc2libGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBmb3IgYSBtZWRpYSBjb25uZWN0aW9uIHRv IG91dHJhY2UgdGhlIGFuc3dlciBiYWNrIHRvIHRoZSBvZmZlcmVyLjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7IFRodXMsIGlmIHRoZSBvZmZlcmVyIGhhcyBvZmZlcmVkIGEgJ3NldHVwOnBhc3NpdmUn IG9yICdzZXR1cDphY3RwYXNzJzxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHJvbGUsIGl0IE1VU1Qg KGFzIHNwZWNpZmllZCBpbiBSRkMgNDE0NSBbN10pIGJlZ2luIGxpc3RlbmluZyBmb3IgYW48YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBpbmNvbWluZyBjb25uZWN0aW9uIGFzIHNvb24gYXMgaXQgc2Vu ZHMgaXRzIG9mZmVyLiZuYnNwOyBIb3dldmVyLCBpdCBNVVNUPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgTk9UIGFzc3VtZSB0aGF0IHRoZSBkYXRhIHRyYW5zbWl0dGVkIG92ZXIgdGhlIFRMUyBjb25u ZWN0aW9uIGlzIHZhbGlkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgdW50aWwgaXQgaGFzIHJlY2Vp dmVkIGEgbWF0Y2hpbmcgZmluZ2VycHJpbnQgaW4gYW4gU0RQIGFuc3dlci4mbmJzcDsgSWY8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgZmluZ2VycHJpbnQsIG9uY2UgaXQgYXJyaXZlcywgZG9l cyBub3QgbWF0Y2ggdGhlIGNsaWVudCdzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgY2VydGlmaWNh dGUsIHRoZSBzZXJ2ZXIgZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUgdGhlIG1lZGlhIGNvbm5lY3Rp b248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB3aXRoIGEgYmFkX2NlcnRpZmljYXRlIGVycm9yLCBh cyBzdGF0ZWQgaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBH aXZlbiB0aGUgb3V0c3RhbmRpbmcgaXNzdWUgcmVsYXRpbmcgdG8gaGFuZGxpbmcgb2YgdW52ZXJp ZmllZCBtZWRpYSwgdGhlPGJyPg0KJmd0OyBDaGFpcnMgb2YgdGhlIFczQyBXRUJSVEMgV0cgd291 bGQgbGlrZSB0byByZXF1ZXN0IGNsYXJpZmljYXRpb24gZnJvbSB0aGU8YnI+DQomZ3Q7IElFVEYg TU1VU0lDIFdHIGFzIHRvIHRoZSBtZWFuaW5nIG9mIHRoZSAmcXVvdDtNVVNUIE5PVCZxdW90OyBp biB0aGUgYWJvdmUgcGFyYWdyYXBoLjxicj4NCiZndDsgSW4gcGFydGljdWxhciwgd2hhdCBpcyBp dCBwZXJtaXR0ZWQgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRvIGRvIHdpdGg8YnI+DQomZ3Q7IHJl Y2VpdmVkIGRhdGEgYW5kIG1lZGlhIHByaW9yIHRvIHZlcmlmaWNhdGlvbj8gRm9yIGV4YW1wbGU6 PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAxLiBNYXkgZGF0YSByZWNl aXZlZCBvdmVyIHRoZSBkYXRhIGNoYW5uZWwgYmUgcHJvdmlkZWQgdG8gdGhlPGJyPg0KJmd0OyBh cHBsaWNhdGlvbiBwcmlvciB0byB2ZXJpZmljYXRpb24/PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYS4gSWYgdGhlIGFuc3dlciB0byB0aGUgYWJvdmUgaXMgJnF1 b3Q7bm8mcXVvdDssIG1heSB1bnZlcmlmaWVkIHJlY2VpdmVkIGRhdGE8YnI+DQomZ3Q7IGJlIGRl bGl2ZXJlZCBieSB0aGUgRFRMUyB0cmFuc3BvcnQgdG8gU0NUUCwgd2hpY2ggbWF5IGJ1ZmZlciBp dD88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgMi4gTWF5IHJlY2VpdmVkIG1lZGlhIGJl IHBsYXllZCBvdXQgcHJpb3IgdG8gdmVyaWZpY2F0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IEJl cm5hcmQgQWJvYmE8YnI+DQomZ3Q7IE9uIGJlaGFsZiBvZiB0aGUgVzNDIFdFQlJUQyBXRzxicj4N CiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyBtbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQomZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWM8L3NwYW4+PC9hPjxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bXVzaWMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tbXVzaWNAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1 cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxp c3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpwdXJwbGUiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB0B034ESESSMB109erics_-- From nobody Mon Mar 13 14:57: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 9CA66129BDB for ; Mon, 13 Mar 2017 14:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 Y8TyaDMEMQp6 for ; Mon, 13 Mar 2017 14:57:18 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C8E129BDC for ; Mon, 13 Mar 2017 14:57:15 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id D844FE3A2CAA7; Mon, 13 Mar 2017 21:57:11 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v2DLvE4b020466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Mar 2017 21:57:14 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v2DLvE77018096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Mar 2017 21:57:14 GMT Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Mon, 13 Mar 2017 17:57:14 -0400 From: "Makaraju, Raju (Nokia - US)" To: Bo Burman , "mmusic (mmusic@ietf.org)" Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AdKR1myZplopSuFrSp2L99aM0eEZvwJvXIowAB62pQAADX77sA== Date: Mon, 13 Mar 2017 21:57:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A178201530D3A05US70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 21:57:20 -0000 --_000_E1FE4C082A89A246A11D7F32A95A178201530D3A05US70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bo, > It was a bit unclear if it was some kind of quote from somewhere, which i= s also commonly indicated by such indentation. I suggest just making it exp= licit that it is a note, starting the first line >with "Note: ". Will do. Thanks. BR Raju From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Monday, March 13, 2017 6:30 AM To: Makaraju, Raju (Nokia - US) ; mmusic (mmusic@i= etf.org) Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Raju, Regarding: 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? It was a bit unclear if it was some kind of quote from somewhere, which is = also commonly indicated by such indentation. I suggest just making it expli= cit that it is a note, starting the first line with "Note: ". /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 02:52 To: Bo Burman >; mmus= ic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo Burman, Christian Groves, Paul Kyzivat, Thank you so much for your time in making this document better, we apprecia= te it. Sorry for the extended delay. I accepted all the comments. Please see my comments inserted below. Thanks again Raju From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: Tuesday, February 28, 2017 10:11 AM To: mmusic (mmusic@ietf.org) > Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-= sdpneg-11 Authors, WG, I think this document is getting ready for publication request. As part of = making the shepherd's write-up, I have the following comments, to be addres= sed in an updated document: Issues: 1) In section 1: add that also BFCP (Binary Floor Control Protocol) i= s used in the same way as MSRP in examples. [Raju] Will add BFCP. 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite length of t= his identifier, which seems inappropriate. I suggest providing a maximum le= ngth, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960)= , in which case 1*5DIGIT should be sufficient. [Raju] Will change as suggested. 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" af= ter "%" when defining hex characters. Change to: quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % [Raju] Will change as suggested. 4) In 5.1.2.1, text below the example makes reference to MSRP subproto= col, but the example does not explicitly include any MSRP. The single examp= le line uses "accept-types", which is admittedly related to MSRP, but I thi= nk this should be clarified to avoid confusion for readers not familiar wit= h MSRP. [Raju] Will change "Example" to "Example (other MSRP related SDP attributes= are omitted for brevity):" 5) In 5.2.2: It is unclear why you differentiate handling of offers an= d answers that contain both "max-retr" and "max-time", mandating to reject = the offer but allowing it in the answer. I think allowing this asymmetry sh= ould either be motivated, or handling should be aligned between offer and a= nswer. [Raju] I think it was thought giving a bit of flexibility to offerer while = receiving answer is probably good but I see your point on aligning both. Wi= ll change text to align both. 6) In section 6: several examples uses IP addresses that are not align= ed with RFC 6890 (10.10.10.x), which must be changed. Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3). [Raju] Will change as suggested. 7) In Appendix A: same IP address issue as above, change from 79.97.21= 5.79 to an address in the allowed range. [Raju] Will change as suggested. Nits: 1) The date line in the document header is one character too long (bey= ond column 72) [Raju] Good catch! Hmmm... not sure how it is getting messed up as the it i= s supposed to be an auto generated line. Anyway, I just checked the new upd= ated draft at https://xml2rfc.tools.ietf.org and output looks good. 2) In section 1: s/In future data channels could/In the future, data c= hannels could/ [Raju] Will change as suggested. 3) In section 3: s/sending and receive data/sending and receiving data= / [Raju] Will change as suggested. 4) At the very end of section 5.1.2.1: s/in the same document, which r= egisters/in the same document that registers/ [Raju] Will change as suggested. 5) In 5.2.4: s/other data channels which are now not included/other da= ta channels that are now not included/ [Raju] Will change as suggested. 6) In 5.2.5: s/channels are expected be closed now/channels are expect= ed to be closed now/ [Raju] Will change as suggested. 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHA= LL use/ [Raju] Will change as suggested. 8) In Appendix A.1: s/either pass to the data channel stack the stream= identifier to assign/either pass the stream identifier to the data channel= stack to assign/ [Raju] Will change as suggested. 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? Comments from others that are not addressed in -11: 1) Christian Groves commented on Jan 20 that the example in Appendix A= should contain an "a=3Ddtls-id:..." attribute as per other examples in the= draft. [Raju] Will add a=3Ddtls-id. 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 sho= uld be changed to: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. [Raju] Will change as suggested. Thanks raju Cheers, /Bo MMUSIC co-chair --_000_E1FE4C082A89A246A11D7F32A95A178201530D3A05US70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bo,

> It was a bit unclear if it was some kind of quo= te from somewhere, which is also commonly indicated by such indentation. I = suggest just making it explicit that it is a note, starting the first line

>with “Note: ”.

 

Will do. Thanks.

 

BR

Raju

 

From: Bo Burman [mailto:bo.burman@ericsson.co= m]
Sent: Monday, March 13, 2017 6:30 AM
To: Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com>; mmu= sic (mmusic@ietf.org) <mmusic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Raju,

 

Regarding:

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

It was a bit unclear if it was some kind of quote fr= om somewhere, which is also commonly indicated by such indentation. I sugge= st just making it explicit that it is a note, starting the first line with = “Note: ”.

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com]
Sent: den 13 mars 2017 02:52
To: Bo Burman <bo.burma= n@ericsson.com>; mmusic (mmusic@i= etf.org) <mmusic@ietf.org>=
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo Burman, Christian Groves, Paul Kyzivat,

 

Thank you so much for your time in making this docum= ent better, we appreciate it. Sorry for the extended delay.

I accepted all the comments.

Please see my comments inserted below.

 

Thanks again

Raju

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: Tuesday, February 28, 2017 10:11 AM
To: mmusic (mmusic@ietf.org) = <mmusic@ietf.org>
Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-c= hannel-sdpneg-11

 

Authors, WG,

 

I think this document is getting ready for publicati= on request. As part of making the shepherd’s write-up, I have the fol= lowing comments, to be addressed in an updated document:

 

Issues:

1)      In section 1: add that also BFCP (Binary Floor Cont= rol Protocol)  is used in the same way as MSRP in examples.=

[Raju] Will add BFCP.

2)      In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infi= nite length of this identifier, which seems inappropriate. I suggest provid= ing a maximum length, maybe matching this to the unsigned 16 bit integer in= SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

[Raju] Will change as suggested.<= /o:p>

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect= , missing “x” after “%” when defining hex character= s. Change to:
quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or= %

[Raju] Will change as suggested.<= /o:p>

4)      In 5.1.2.1, text below the example makes reference = to MSRP subprotocol, but the example does not explicitly include any MSRP. = The single example line uses “accept-types”, which is admittedl= y related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

[Raju] Will change “Example” to &#= 8220;Example (other MSRP related SDP attributes are omitted for brevity):&#= 8221;

5)      In 5.2.2: It is unclear why you differentiate handl= ing of offers and answers that contain both “max-retr” and R= 20;max-time”, mandating to reject the offer but allowing it in the an= swer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

[Raju] I think it was thought giving a bit of = flexibility to offerer while receiving answer is probably good but I see yo= ur point on aligning both. Will change text to align both.

6)      In section 6: several examples uses IP addresses th= at are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3).

[Raju] Will change as suggested. =

7)      In Appendix A: same IP address issue as above, chan= ge from 79.97.215.79 to an address in the allowed range.

[Raju] Will change as suggested. =

 

Nits:

1)      The date line in the document header is one charact= er too long (beyond column 72)

[Raju] Good catch! Hmmm… not sure how it= is getting messed up as the it is supposed to be an auto generated line. A= nyway, I just checked the new updated draft at https://xml2rfc.tools.ietf.org and output l= ooks good.

2)      In section 1: s/In future data channels could/In th= e future, data channels could/

[Raju] Will change as suggested. =

3)      In section 3: s/sending and receive data/sending an= d receiving data/

[Raju] Will change as suggested. =

4)      At the very end of section 5.1.2.1: s/in the same d= ocument, which registers/in the same document that registers/

[Raju] Will change as suggested. =

5)      In 5.2.4: s/other data channels which are now not i= ncluded/other data channels that are now not included/

[Raju] Will change as suggested.<= /o:p>

6)      In 5.2.5: s/channels are expected be closed now/cha= nnels are expected to be closed now/

[Raju] Will change as suggested.<= /o:p>

7)      In 8.3: s/dcsa usage level only shall use/dcsa usag= e level only SHALL use/

[Raju] Will change as suggested.<= /o:p>

8)      In Appendix A.1: s/either pass to the data channel = stack the stream identifier to assign/either pass the stream identifier to = the data channel stack to assign/

[Raju] Will change as suggested.<= /o:p>

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

Comments from others that are not addressed in -11:<= o:p>

1)      Christian Groves commented on Jan 20 that the examp= le in Appendix A should contain an “a=3Ddtls-id:…” attrib= ute as per other examples in the draft.

[Raju] Will add a= =3Ddtls-id.

2)      Paul Kyzivat commented on Jan 21 that a bullet in s= ection 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and    channel parameters contained in the SDP offer.=

[Raju] Will change as suggested.

 

Thanks

raju

 

Cheers,

/Bo

MMUSIC co-chair

 

--_000_E1FE4C082A89A246A11D7F32A95A178201530D3A05US70UWXCHMBA0_-- From nobody Mon Mar 13 15:17: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 B5C02129518 for ; Mon, 13 Mar 2017 15:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=2.035, SPF_PASS=-0.001, 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 rmqVj48JIQKr for ; Mon, 13 Mar 2017 15:17:25 -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 DBF66129BB5 for ; Mon, 13 Mar 2017 15:17:21 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2DM956R005177; Mon, 13 Mar 2017 18:17:16 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 294cv89nuf-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Mar 2017 18:17:15 -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; Mon, 13 Mar 2017 17:17:15 -0500 From: Jonathan Lennox To: Christer Holmberg Thread-Topic: [MMUSIC] Handling of unverified data and media Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGOsIkAgAABT4CAAA4wAIAA+MdggAO42wD//9++UIAAXakA Date: Mon, 13 Mar 2017 22:17:14 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_B471CDFFD0E84644B8EB320694353412vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-13_16:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703130171 Archived-At: Cc: Flemming Andreasen , Harald Alvestrand , mmusic Subject: Re: [MMUSIC] Handling of unverified data and media X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 22:17:28 -0000 --_000_B471CDFFD0E84644B8EB320694353412vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBNYXIgMTMsIDIwMTcsIGF0IDU6NDQgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KSWYgdGhlIGFuc3dlcmVyIGlzIGluIHN1Y2ggYSDigJxo dXJyeeKAnSB0byBzdGFydCBzZW5kaW5nIG1lZGlhLCBvbmUgd291bGQgdGhpbmsgaXQgYWxzbyBt YWtlcyBzdXJlIHRoZSBhbnN3ZXIgaXMgc2VudCBhcyBlYXJseSBhcyBwb3NzaWJsZSwgc28gdGhh dCBtZWRpYSBjYW4gZmxvdyBpbiBib3RoIGRpcmVjdGlvbnMuDQoNCllvdSBjYW4gc2VuZCB0aGUg YW5zd2VyIGFzIGVhcmx5IGFzIHBvc3NpYmxlLCBidXQgaWYgdHdvIGVuZHBvaW50cyBvbiB0aGUg c2FtZSBzdWJuZXQgYXJlIHRhbGtpbmcgdmlhIGEgc2lnbmFsaW5nIHNlcnZlciBvbiB0aGUgb3Ro ZXIgc2lkZSBvZiB0aGUgcGxhbmV0LCB0aGVyZeKAmXMgb25seSBzbyBtdWNoIHlvdSBjYW4gZG8u DQoNCk15IHF1ZXN0aW9uIGlzOiBpcyB0aGlzIHNvbWV0aGluZyB0aGF04oCZcyBjYXVzaW5nIHBy b2JsZW1zIGluIHJlYWwgZGVwbG95bWVudHMsIGFuZCByZXF1aXJlcyBhIGNoYW5nZSBpbiB0aGUg c3RhbmRhcmQ/IFRvIG1lIGl0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgaXMgdmVyeSB1bmxp a2VseSB0byBvY2N1ciwgb3IgYXQgbGVhc3QgbGlrZSBzb21ldGhpbmcgdGhhdCBjYW4gZWFzaWx5 IGJlIGF2b2lkZWQgYnkgaW1wbGVtZW50YXRpb24gbWVhbnPigKYNCg0KSeKAmW0gcHJldHR5IHN1 cmUgdGhpcyBpcyBzb21ldGhpbmcgdGhhdOKAmXMgYWxyZWFkeSBhbGxvd2VkIGJ5IHRoZSBjdXJy ZW50IHN0YW5kYXJkcywgYnV0IHRoaXMgZmFjdCBpcyBzdWJzdGFudGlhbGx5IG5vbi1vYnZpb3Vz LiBTbyBJ4oCZbSBhZnJhaWQgdGhhdCB3ZeKAmWxsIGdldCBpbnRlcm9wIGZhaWx1cmVzIGlmIHdl IGRvbuKAmXQgcG9pbnQgaXQgb3V0Lg0KDQpOb3RlIHRoYXQgaW4gbW9zdCBjYXNlcyBpdCBjYW4g b25seSBoYXBwZW4gaWYgZW5kcG9pbnRzIHRha2UgYWR2YW50YWdlIG9mIHRoZSBmcmVlZG9tcyBn cmFudGVkIGJ5IFJGQyA1MjQ1Ymlz4oCZcyDigJxwYXNzaXZlLWFnZ3Jlc3NpdmXigJ0gYWxnb3Jp dGhtLCB3aGVyZSB3ZSBjbGFyaWZpZWQgdGhhdCBhbiBlbmRwb2ludCBpcyBhbGxvd2VkIHRvIHNl bmQgb24gYW55IHZhbGlkIHBhaXIsIG5vdCBqdXN0IHRoZSBzZWxlY3RlZCBub21pbmF0ZWQgcGFp ci4gIChJZiB5b3UgZG9u4oCZdCBzZW5kIHVudGlsIHlvdSBoYXZlIGEgbm9taW5hdGVkIHBhaXIs IEkgYmVsaWV2ZSB0aGUgb25seSB3YXkgdGhpcyByYWNlIGNhbiBvY2N1ciBpcyBpZiBhbiBJQ0Ut TGl0ZSBlbmRwb2ludCBjYWxscyBhIEZ1bGwgZW5kcG9pbnQ7IG90aGVyd2lzZSwgdGhlIG9mZmVy ZXIgaXMgdGhlIGNvbnRyb2xsaW5nIGVuZHBvaW50LikNCg0KSeKAmW0gbm90IHN1cmUgd2hhdCDi gJxpbXBsZW1lbnRhdGlvbiBtZWFuc+KAnSB5b3XigJlyZSB0aGlua2luZyBvZiwgdGhvdWdoLiAg QXZvaWRpbmcgc2VuZGluZyBtZWRpYS9EVExTIHVudGlsIHlvdSByZWNlaXZlIGFuIGluY29taW5n IGNvbm5lY3Rpdml0eSBjaGVjaz8NCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBK b25hdGhhbiBMZW5ub3ggW21haWx0bzpqb25hdGhhbkB2aWR5by5jb21dDQpTZW50OiAxMyBNYXJj aCAyMDE3IDIwOjM3DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiBF cmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBCZXJuYXJk IEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFp bC5jb20+PjsgRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0BjaXNjby5jb208bWFpbHRvOmZh bmRyZWFzQGNpc2NvLmNvbT4+OyBIYXJhbGQgQWx2ZXN0cmFuZCA8aHRhQGdvb2dsZS5jb208bWFp bHRvOmh0YUBnb29nbGUuY29tPj47IG1tdXNpYyA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIEhhbmRsaW5nIG9mIHVudmVyaWZp ZWQgZGF0YSBhbmQgbWVkaWENCg0KDQpPbiBNYXIgMTEsIDIwMTcsIGF0IDk6NTIgQU0sIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KSXMgdGhpcyBhIHRo ZW9yZXRpY2FsIGlzc3VlPw0KDQpBdCBsZWFzdCBpZiB5b3UgdXNlIElDRSwgeW91IGFyZSBnb2lu ZyB0byByZWNlaXZlIHRoZSBhbnN3ZXIgYmVmb3JlIHlvdSByZWNlaXZlIGFueSBtZWRpYSwgYXMg eW91IGFyZSBnb2luZyB0byBkbyB0aGUgY29ubmVjdGl2aXR5IGNoZWNrcyBldGMuDQoNCk5vLCBl dmVuIHdpdGggSUNFIGl04oCZcyBwb3NzaWJsZSBmb3IgbWVkaWEgb3IgdGhlIERUTFMgaGFuZHNo YWtlIHRvIG91dHJhY2UgdGhlIGFuc3dlci4NCg0KVGhpcyBpcyBiZWNhdXNlIElDRSBvZmZlcmlu ZyBlbmRwb2ludHMgcmVzcG9uZCB0byBjb25uZWN0aXZpdHkgY2hlY2tzIGJlZm9yZSB0aGV5IHJl Y2VpdmUgYW4gYW5zd2VyLiAgV2hlbiB0aGUgYW5zd2VyZXIgcmVjZWl2ZXMgdGhpcyBzdWNjZXNz ZnVsIGNvbm5lY3Rpdml0eSBjaGVjayByZXNwb25zZSwgaXQgcHV0cyB0aGUgcmVsZXZhbnQgcGFp ciBpbiB0aGUgVmFsaWQgbGlzdCwgYW5kIHRoZW4gKGlmIGl0IGhhcyB0aGUgYWN0aXZlIHJvbGUs IGFzIHJlY29tbWVuZGVkKSBjYW4gbGVnaXRpbWF0ZWx5IGluaXRpYXRlIERUTFMgb24gdGhpcyBw YWlyLg0KDQpJZiB0d28gSUNFIGVuZHBvaW50cyBoYXZlIGEgc2hvcnQgUlRUIGFuZCBjbGVhciBj b25uZWN0aXZpdHkgYmV0d2VlbiB0aGVtLCBidXQgYSBsb25nIFJUVCB0byB0aGVpciBzaWduYWxp bmcgc2VydmVyLCB0aGlzIGNhbiBoYXBwZW4gcXVpdGUgZWFzaWx5Lg0KDQoNCkFsc28sIGluIHJl YWxpdHkgc29tZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3QgYWNjZXB0IGNvbnRlbnQgYmVmb3Jl IHRoZSBhbnN3ZXIgYXJyaXZlcyDigJMgbm8gbWF0dGVyIGlmIERUTFMgaXMgdXNlZCBvciBub3Qg 4oCTIHNvIHRoZSBiZXN0IHRoaW5nIGlzIHRvLCBvbmNlIHRoZSBhbnN3ZXIgaGFzIGJlZW4gc2Vu dCwganVzdCB3YWl0IGZvciBhIHdoaWxlIGJlZm9yZSBzZW5kaW5nIGFueSBjb250ZW50Lg0KDQpG b3J0dW5hdGVseSwgRFRMUyBoYXMgcmV0cmFuc21pc3Npb25zLCBzbyB0aGlzIHNob3VsZG7igJl0 IGNhdXNlIGZhaWx1cmUsIGp1c3QgYSBicmllZiBzZXR1cCBkZWxheS4NCg0KDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogMTEgTWFyY2ggMjAxNyAwMjo1 Nw0KVG86IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmQuYWJvYmFAZ21haWwuY29tPG1haWx0bzpiZXJu YXJkLmFib2JhQGdtYWlsLmNvbT4+DQpDYzogRmxlbW1pbmcgQW5kcmVhc2VuIDxmYW5kcmVhc0Bj aXNjby5jb208bWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbT4+OyBodGFAZ29vZ2xlLmNvbTxtYWls dG86aHRhQGdvb2dsZS5jb20+OyBtbXVzaWMgV0cgPG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11 c2ljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBIYW5kbGluZyBvZiB1bnZlcmlm aWVkIGRhdGEgYW5kIG1lZGlhDQoNClNvcnJ5LCBubywgSSB3YXMganVzdCB0YWxraW5nIGFib3V0 IHdoYXQgbWlnaHQgb3IgbWlnaHQgbm90IGJlIHNhZmUuLi4uIFRoZSBkb2MgdGV4dCBpcw0KYSBk aWZmZXJlbnQgcXVlc3Rpb24uDQoNCi1Fa3INCg0KDQpPbiBGcmksIE1hciAxMCwgMjAxNyBhdCA0 OjA1IFBNLCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVy bmFyZC5hYm9iYUBnbWFpbC5jb20+PiB3cm90ZToNCkVLUiBzYWlkOg0KDQoiSSBoYXZlbid0IHNw ZW50IHRvbyBtdWNoIHRpbWUgb24gaXQsIGJ1dCBpdCBzZWVtcyBsaWtlIGl0IG91Z2h0IHRvIGJl IHNhZmUgdG8gaG9sZA0KYW55dGhpbmcgeW91IHJlY2VpdmUgcHJpb3IgdG8gZ2V0dGluZyB0aGUg ZmluZ2VycHJpbnQuIEl0IG1pZ2h0IGJlIGJldHRlciwgYXMgTVQNCnN1Z2dlc3RzLCB0byBkaXNj YXJkIHRoZSBkYXRhY2hhbm5lbCBkYXRhLCBidXQgSSdtIG5vdCBzdXJlIHdoeSBpdCB3b3VsZCBi ZQ0KbmVjZXNzYXJ5LiINCg0KW0JBXSBTbyB5b3UgYXJlIHNheWluZyB0aGF0IHRoZSBNVVNUIE5P VCBhbGxvd3MgdGhlIGJyb3dzZXIgdG8gYnVmZmVyIGRhdGEvbWVkaWEgYnV0IG5vdCB0byBwYXNz IGl0IHRvIHRoZSBhcHBsaWNhdGlvbiAoaW4gdGhlIGNhc2Ugb2YgdGhlIGRhdGEgY2hhbm5lbCkg b3IgdG8gcGxheSBpdCBvdXQ/DQoNCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0IDQ6MDEgUE0sIEVy aWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpJ IGhhdmVuJ3Qgc3BlbnQgdG9vIG11Y2ggdGltZSBvbiBpdCwgYnV0IGl0IHNlZW1zIGxpa2UgaXQg b3VnaHQgdG8gYmUgc2FmZSB0byBob2xkDQphbnl0aGluZyB5b3UgcmVjZWl2ZSBwcmlvciB0byBn ZXR0aW5nIHRoZSBmaW5nZXJwcmludC4gSXQgbWlnaHQgYmUgYmV0dGVyLCBhcyBNVA0Kc3VnZ2Vz dHMsIHRvIGRpc2NhcmQgdGhlIGRhdGFjaGFubmVsIGRhdGEsIGJ1dCBJJ20gbm90IHN1cmUgd2h5 IGl0IHdvdWxkIGJlDQpuZWNlc3NhcnkuDQoNCi1Fa3INCg0KT24gRnJpLCBNYXIgMTAsIDIwMTcg YXQgMjo0NyBQTSwgUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFu QHRlbHVyaXguY29tPj4gd3JvdGU6DQpNeSBhc3N1bXB0aW9uIGFsd2F5cyB3YXMgdGhhdCBkYXRh IGlzIHJlY2VpdmVkLCBkZWNvZGVkIGFuZCBkaXNjYXJkZWQgdW50aWwgZmluZ2VycHJpbnQgaXMg cmVjZWl2ZWQgYW5kIHZlcmlmaWVkLiBUaGlzIHdheSBEVExTIGhhbmRzaGFrZSBjb21wbGV0ZXMs IGtleSBmcmFtZXMgYXJlIGRlY29kZWQsIGJ1dCB1c2VyIGlzIG5vciBwcmVzZW50ZWQgd2l0aCBh bnkgdW52ZXJpZmllZCBtZWRpYS4NCg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0KUm9tYW4g U2hwb3VudA0KDQpPbiBUaHUsIE1hciA5LCAyMDE3IGF0IDY6NTggUE0sIE1hcnRpbiBUaG9tc29u IDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bT4+IHdyb3RlOg0KSSB0aGluayB0aGF0IHRoZSBkYXRhIGNoYW5uZWwgcXVlc3Rpb24gaXMgZWFz eSwgYW55dGhpbmcgb3RoZXIgdGhhbiBhDQoibm8iIGlzIG5vdCBhY2NlcHRhYmxlLiAgRGF0YSBp biB0aGF0IGZvcm0gZW50ZXJzIHRoZSBzZWN1cml0eQ0KYm91bmRhcnkgZm9yIGFuIG9yaWdpbiBh bmQgaXQgZG9lc24ndCBtYWtlIGFueSBzZW5zZSB0byByaXNrIGF0dGFjaw0KdGhlcmUuICAoSXQn cyBhbHNvIGxpa2VseSB1bm5lY2Vzc2FyeSwgaWYgYSBoYWxmIGEgcm91bmQgdHJpcCBvZg0Kc2ln bmFsaW5nIGlzIHNsb3dlciB0aGFuIDUgcm91bmQgdHJpcHMgb24gdGhlIG1lZGlhIHBhdGgsIHRo ZW4NCnNvbWV0aGluZyBpcyBtZXNzZWQgdXAuKQ0KDQpJJ20gaW4gdHdvIG1pbmRzIGFib3V0IHRo ZSBtZWRpYSBwYXJ0LiBGb3IgbWVkaWEsIHlvdSBjb3VsZCBhbHNvDQpyZWFzb25hYmx5IG1ha2Ug dGhlIHNhbWUgb3JpZ2luLXB1cml0eSBhcmd1bWVudC4gIEknbSBpbmNsaW5lZCB0byBzYXkNCnRo YXQuICBCdXQgd2UgQ0FOIGlzb2xhdGUgbWVkaWEgZnJvbSB0aGUgb3JpZ2luIChhbmQgd2UgZGVm aW5pdGVseQ0Kc2hvdWxkIGlmIHdlIGFsbG93IHRoaXMpLg0KDQpTbywgdGhlIG1lZGlhIHRoYXQg YXJyaXZlcyBoYWQgdG8gY29tcGx5IHdpdGggeW91ciBvZmZlci4gIFRoZSBEVExTDQpoYW5kc2hh a2UgYWxzbyBoYXMgdG8gY29tcGxldGUsIHdoaWNoIHRlbGxzIHRoZSByZWNlaXZlciB3aGV0aGVy IHRoZQ0KbWVkaWEgbmVlZHMgdG8gYmUgY29uZmlkZW50aWFsIG9yIG5vdCAoYXQgd2hpY2ggcG9p bnQgeW91IGNhbiBkaXNhYmxlDQp0aGlzIGZlYXR1cmUpLg0KDQpJdCdzIGFsc28gcG9zc2libGUg dGhhdCBhIHJlY2VpdmVyIGNhbiByZXF1aXJlIHRoYXQgYW4gSUNFDQpjb25uZWN0aXZpdHkgY2hl Y2sgd2FzIG1hZGUgKHRob3VnaCB0aGlzIGlzIGluYm91bmQgb25seSwgYW5kIEknbQ0KdW5jbGVh ciBvbiB3aGV0aGVyIGhhdmluZyByZWNlaXZlZCBhbiBpbmJvdW5kIGNoZWNrIHdvdWxkIG5vcm1h bGx5DQpwcmV2ZW50IHRoZSByZWNlaXZlciBmcm9tIGFjY2VwdGluZyBhIHBhY2tldCkuDQoNCkFs bCB0b2xkLCB0aGF0J3MgYSBsb3Qgb2YgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5lZ290aWF0ZWQg c2Vzc2lvbiBmb3INCmFuIGF0dGFja2VyIHRvIGhhdmUuICBUaGUgb2RkcyBvZiB0aGlzIGJlaW5n IGFuIGF0dGFjayB3b3VsZCAqc2VlbSogdG8NCmJlIGxvdy4NCg0KT24gdGhlIG90aGVyIGhhbmQs IHdlIGRvbid0IGFzc3VtZSBjb25maWRlbnRpYWxpdHkgb2Ygc2lnbmFsaW5nOyB0aGUNCnNlY3Vy aXR5IG1vZGVsIGFzc3VtZXMgdGhhdCBhbGwgdGhpcyBpbmZvcm1hdGlvbiBpcyBlZmZlY3RpdmVs eSBwdWJsaWMNCmFuZCB0aGUgcHJvdGVjdGlvbiB3ZSBoYXZlIGFnYWluc3QgYXR0YWNrIGlzIHRo ZSBjZXJ0aWZpY2F0ZQ0KZmluZ2VycHJpbnQuICBUaGlzIHdvdWxkIHJlbW92ZSB0aGF0IHByb3Rl Y3Rpb24sIGFsYmVpdCBmb3IgYSBzaG9ydA0KZHVyYXRpb24uDQoNCkkgaGF2ZSBhbiBleHRyYSBx dWVzdGlvbjogZG9lcyBhbnlvbmUgcGxhbiB0byBpbXBsZW1lbnQgdGhpcz8gIEl0J3MNCm5vbi10 cml2aWFsLiAgSSB0aGluayB0aGF0IEkga25vdyB3aGF0IEknZCBuZWVkIHRvIGRvIGluIEZpcmVm b3ggYW5kDQppdCB3b3VsZCBiZSBxdWl0ZSBkaXNydXB0aXZlLiAgQmVmb3JlIGNvbW1pdHRpbmcg dG8gZG8gdGhhdCB3b3JrDQood2hpY2ggSSB3aWxsIGxlYXZlIHRvIG90aGVycyBjbG9zZXIgdG8g dGhpcyB0byBkZWNpZGUpLCBJJ2QgcHJvYmFibHkNCndhbnQgbW9yZSBpbmZvcm1hdGlvbiBvbiB0 aGUgYWN0dWFsIGFkdmFudGFnZSB0aGF0IGl0IHByb3ZpZGVzLg0KDQpPbiAxMCBNYXJjaCAyMDE3 IGF0IDA3OjEwLCBCZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86 YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+PiB3cm90ZToNCj4gSW4gdGhlIFczQyBXRUJSVEMgV0cs IGFuIGlzc3VlIGhhcyBiZWVuIHN1Ym1pdHRlZCByZWxhdGluZyB0byBwbGF5b3V0IG9mDQo+IHVu dmVyaWZpZWQgbWVkaWE6DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2VicnRjLXBjL2lzc3Vl cy84NDkNCj4NCj4gSXQgaGFzIGJlZW4gc3VnZ2VzdGVkIHRoYXQgaWYgdGhlIGJyb3dzZXIgaXMg Y29uZmlndXJlZCB0byBkbyBzbywgdGhhdA0KPiBwbGF5b3V0IGJlIGFsbG93ZWQgZm9yIGEgbGlt aXRlZCBwZXJpb2QgKGUuZy4gNSBzZWNvbmRzKSBwcmlvciB0bw0KPiBmaW5nZXJwcmludCB2ZXJp ZmljYXRpb246DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2VicnRjLXBjL3B1bGwvMTAyNg0K Pg0KPiBTZWN0aW9uIDYuMiBvZiBkcmFmdC1pZXRmLW1tdXNpYy00NTcyLXVwZGF0ZS0xMyBjb250 YWlucyB0aGUgZm9sbG93aW5nIHRleHQsDQo+IGNhcnJpZWQgb3ZlciBmcm9tIFJGQyA0NTcyOg0K Pg0KPiAgICBOb3RlIHRoYXQgd2hlbiB0aGUgb2ZmZXIvYW5zd2VyIG1vZGVsIGlzIGJlaW5nIHVz ZWQsIGl0IGlzIHBvc3NpYmxlDQo+ICAgIGZvciBhIG1lZGlhIGNvbm5lY3Rpb24gdG8gb3V0cmFj ZSB0aGUgYW5zd2VyIGJhY2sgdG8gdGhlIG9mZmVyZXIuDQo+ICAgIFRodXMsIGlmIHRoZSBvZmZl cmVyIGhhcyBvZmZlcmVkIGEgJ3NldHVwOnBhc3NpdmUnIG9yICdzZXR1cDphY3RwYXNzJw0KPiAg ICByb2xlLCBpdCBNVVNUIChhcyBzcGVjaWZpZWQgaW4gUkZDIDQxNDUgWzddKSBiZWdpbiBsaXN0 ZW5pbmcgZm9yIGFuDQo+ICAgIGluY29taW5nIGNvbm5lY3Rpb24gYXMgc29vbiBhcyBpdCBzZW5k cyBpdHMgb2ZmZXIuICBIb3dldmVyLCBpdCBNVVNUDQo+ICAgIE5PVCBhc3N1bWUgdGhhdCB0aGUg ZGF0YSB0cmFuc21pdHRlZCBvdmVyIHRoZSBUTFMgY29ubmVjdGlvbiBpcyB2YWxpZA0KPiAgICB1 bnRpbCBpdCBoYXMgcmVjZWl2ZWQgYSBtYXRjaGluZyBmaW5nZXJwcmludCBpbiBhbiBTRFAgYW5z d2VyLiAgSWYNCj4gICAgdGhlIGZpbmdlcnByaW50LCBvbmNlIGl0IGFycml2ZXMsIGRvZXMgbm90 IG1hdGNoIHRoZSBjbGllbnQncw0KPiAgICBjZXJ0aWZpY2F0ZSwgdGhlIHNlcnZlciBlbmRwb2lu dCBNVVNUIHRlcm1pbmF0ZSB0aGUgbWVkaWEgY29ubmVjdGlvbg0KPiAgICB3aXRoIGEgYmFkX2Nl cnRpZmljYXRlIGVycm9yLCBhcyBzdGF0ZWQgaW4gdGhlIHByZXZpb3VzIHBhcmFncmFwaC4NCj4N Cj4gR2l2ZW4gdGhlIG91dHN0YW5kaW5nIGlzc3VlIHJlbGF0aW5nIHRvIGhhbmRsaW5nIG9mIHVu dmVyaWZpZWQgbWVkaWEsIHRoZQ0KPiBDaGFpcnMgb2YgdGhlIFczQyBXRUJSVEMgV0cgd291bGQg bGlrZSB0byByZXF1ZXN0IGNsYXJpZmljYXRpb24gZnJvbSB0aGUNCj4gSUVURiBNTVVTSUMgV0cg YXMgdG8gdGhlIG1lYW5pbmcgb2YgdGhlICJNVVNUIE5PVCIgaW4gdGhlIGFib3ZlIHBhcmFncmFw aC4NCj4gSW4gcGFydGljdWxhciwgd2hhdCBpcyBpdCBwZXJtaXR0ZWQgZm9yIGFuIGltcGxlbWVu dGF0aW9uIHRvIGRvIHdpdGgNCj4gcmVjZWl2ZWQgZGF0YSBhbmQgbWVkaWEgcHJpb3IgdG8gdmVy aWZpY2F0aW9uPyBGb3IgZXhhbXBsZToNCj4NCj4gICAgICAxLiBNYXkgZGF0YSByZWNlaXZlZCBv dmVyIHRoZSBkYXRhIGNoYW5uZWwgYmUgcHJvdmlkZWQgdG8gdGhlDQo+IGFwcGxpY2F0aW9uIHBy aW9yIHRvIHZlcmlmaWNhdGlvbj8NCj4gICAgICAgICAgYS4gSWYgdGhlIGFuc3dlciB0byB0aGUg YWJvdmUgaXMgIm5vIiwgbWF5IHVudmVyaWZpZWQgcmVjZWl2ZWQgZGF0YQ0KPiBiZSBkZWxpdmVy ZWQgYnkgdGhlIERUTFMgdHJhbnNwb3J0IHRvIFNDVFAsIHdoaWNoIG1heSBidWZmZXIgaXQ/DQo+ ICAgICAgMi4gTWF5IHJlY2VpdmVkIG1lZGlhIGJlIHBsYXllZCBvdXQgcHJpb3IgdG8gdmVyaWZp Y2F0aW9uPw0KPg0KPiBCZXJuYXJkIEFib2JhDQo+IE9uIGJlaGFsZiBvZiB0aGUgVzNDIFdFQlJU QyBXRw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBtbXVzaWMgbWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2lj QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp Yw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFp bGluZyBsaXN0DQptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QN Cm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGll dGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_B471CDFFD0E84644B8EB320694353412vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8608E825101CF0438B6B8BB7D4EFDA34@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIg MTMsIDIwMTcsIGF0IDU6NDQgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj5jaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5IaSw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5J ZiB0aGUgYW5zd2VyZXIgaXMgaW4gc3VjaCBhIOKAnGh1cnJ54oCdIHRvIHN0YXJ0IHNlbmRpbmcg bWVkaWEsIG9uZSB3b3VsZCB0aGluayBpdCBhbHNvIG1ha2VzIHN1cmUgdGhlIGFuc3dlciBpcyBz ZW50IGFzIGVhcmx5IGFzIHBvc3NpYmxlLCBzbyB0aGF0IG1lZGlhIGNhbiBmbG93DQogaW4gYm90 aCBkaXJlY3Rpb25zLjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Zb3UgY2FuIHNlbmQgdGhlIGFuc3dl ciBhcyBlYXJseSBhcyBwb3NzaWJsZSwgYnV0IGlmIHR3byBlbmRwb2ludHMgb24gdGhlIHNhbWUg c3VibmV0IGFyZSB0YWxraW5nIHZpYSBhIHNpZ25hbGluZyBzZXJ2ZXIgb24gdGhlIG90aGVyIHNp ZGUgb2YgdGhlIHBsYW5ldCwgdGhlcmXigJlzIG9ubHkgc28gbXVjaCB5b3UgY2FuIGRvLjwvZGl2 Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPk15IHF1ZXN0 aW9uIGlzOiBpcyB0aGlzIHNvbWV0aGluZyB0aGF04oCZcyBjYXVzaW5nIHByb2JsZW1zIGluIHJl YWwgZGVwbG95bWVudHMsIGFuZCByZXF1aXJlcyBhIGNoYW5nZSBpbiB0aGUgc3RhbmRhcmQ/IFRv IG1lIGl0IHNlZW1zIGxpa2Ugc29tZXRoaW5nIHRoYXQgaXMgdmVyeQ0KIHVubGlrZWx5IHRvIG9j Y3VyLCBvciBhdCBsZWFzdCBsaWtlIHNvbWV0aGluZyB0aGF0IGNhbiBlYXNpbHkgYmUgYXZvaWRl ZCBieSBpbXBsZW1lbnRhdGlvbiBtZWFuc+KApjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+SeKAmW0gcHJldHR5IHN1 cmUgdGhpcyBpcyBzb21ldGhpbmcgdGhhdOKAmXMgYWxyZWFkeSBhbGxvd2VkIGJ5IHRoZSBjdXJy ZW50IHN0YW5kYXJkcywgYnV0IHRoaXMgZmFjdCBpcyBzdWJzdGFudGlhbGx5IG5vbi1vYnZpb3Vz LiBTbyBJ4oCZbSBhZnJhaWQgdGhhdCB3ZeKAmWxsIGdldCBpbnRlcm9wIGZhaWx1cmVzIGlmIHdl IGRvbuKAmXQgcG9pbnQgaXQgb3V0LjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+Tm90ZSB0aGF0IGluIG1vc3QgY2FzZXMgaXQgY2FuIG9ubHkgaGFwcGVuIGlmIGVuZHBv aW50cyB0YWtlIGFkdmFudGFnZSBvZiB0aGUgZnJlZWRvbXMgZ3JhbnRlZCBieSBSRkMgNTI0NWJp c+KAmXMg4oCccGFzc2l2ZS1hZ2dyZXNzaXZl4oCdIGFsZ29yaXRobSwgd2hlcmUgd2UgY2xhcmlm aWVkIHRoYXQgYW4gZW5kcG9pbnQgaXMgYWxsb3dlZCB0byBzZW5kIG9uIGFueSB2YWxpZCBwYWly LCBub3QganVzdCB0aGUgc2VsZWN0ZWQgbm9taW5hdGVkIHBhaXIuDQogJm5ic3A7KElmIHlvdSBk b27igJl0IHNlbmQgdW50aWwgeW91IGhhdmUgYSBub21pbmF0ZWQgcGFpciwgSSBiZWxpZXZlIHRo ZSBvbmx5IHdheSB0aGlzIHJhY2UgY2FuIG9jY3VyIGlzIGlmIGFuIElDRS1MaXRlIGVuZHBvaW50 IGNhbGxzIGEgRnVsbCBlbmRwb2ludDsgb3RoZXJ3aXNlLCB0aGUgb2ZmZXJlciBpcyB0aGUgY29u dHJvbGxpbmcgZW5kcG9pbnQuKTwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+SeKAmW0gbm90IHN1cmUgd2hhdCDigJxpbXBsZW1lbnRhdGlvbiBtZWFuc+KAnSB5b3XigJly ZSB0aGlua2luZyBvZiwgdGhvdWdoLiAmbmJzcDtBdm9pZGluZyBzZW5kaW5nIG1lZGlhL0RUTFMg dW50aWwgeW91IHJlY2VpdmUgYW4gaW5jb21pbmcgY29ubmVjdGl2aXR5IGNoZWNrPzwvZGl2Pg0K PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rp b24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IiBjbGFzcz0iIj5SZWdhcmRzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkNocmlzdGVy PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGEgbmFtZT0iX01haWxFbmRDb21wb3NlIiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3AtY29sb3I6IHJn YigyMjUsIDIyNSwgMjI1KTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBwYWRkaW5nOiAzcHQgMGNt IDBjbTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Sm9uYXRoYW4gTGVubm94DQogWzxhIGhy ZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5by5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1haWx0bzpqb25hdGhhbkB2aWR5by5j b208L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MTMgTWFyY2ggMjAxNyAyMDozNzxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5FcmljIFJlc2NvcmxhICZsdDs8 YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5la3JAcnRmbS5jb208L2E+Jmd0OzsgQmVy bmFyZCBBYm9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5iZXJuYXJkLmFib2JhQGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KIEZsZW1taW5nIEFuZHJlYXNlbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZmFuZHJlYXNAY2lzY28u Y29tPC9hPiZndDs7IEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWlsdG86aHRhQGdv b2dsZS5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiIGNsYXNzPSIiPmh0YUBnb29nbGUuY29tPC9hPiZndDs7DQogbW11c2ljICZsdDs8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0OzxiciBj bGFzcz0iIj4NCjxiIGNsYXNzPSIiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW01NVVNJQ10gSGFuZGxpbmcgb2YgdW52ZXJp ZmllZCBkYXRhIGFuZCBtZWRpYTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVw dDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIE1hciAxMSwgMjAx NywgYXQgOTo1MiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+SGksPC9zcGFuPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+ SXMgdGhpcyBhIHRoZW9yZXRpY2FsIGlzc3VlPzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkF0IGxlYXN0 IGlmIHlvdSB1c2UgSUNFLCB5b3UgYXJlIGdvaW5nIHRvIHJlY2VpdmUgdGhlIGFuc3dlciBiZWZv cmUgeW91IHJlY2VpdmUgYW55IG1lZGlhLCBhcyB5b3UgYXJlIGdvaW5nIHRvIGRvIHRoZSBjb25u ZWN0aXZpdHkgY2hlY2tzIGV0Yy48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KTm8sIGV2ZW4gd2l0aCBJQ0UgaXTigJlzIHBv c3NpYmxlIGZvciBtZWRpYSBvciB0aGUgRFRMUyBoYW5kc2hha2UgdG8gb3V0cmFjZSB0aGUgYW5z d2VyLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpUaGlzIGlzIGJlY2F1c2Ug SUNFIG9mZmVyaW5nIGVuZHBvaW50cyByZXNwb25kIHRvIGNvbm5lY3Rpdml0eSBjaGVja3MgYmVm b3JlIHRoZXkgcmVjZWl2ZSBhbiBhbnN3ZXIuICZuYnNwO1doZW4gdGhlIGFuc3dlcmVyIHJlY2Vp dmVzIHRoaXMgc3VjY2Vzc2Z1bCBjb25uZWN0aXZpdHkgY2hlY2sgcmVzcG9uc2UsIGl0IHB1dHMg dGhlIHJlbGV2YW50IHBhaXIgaW4gdGhlIFZhbGlkIGxpc3QsIGFuZCB0aGVuIChpZiBpdCBoYXMg dGhlIGFjdGl2ZSByb2xlLCBhcw0KIHJlY29tbWVuZGVkKSBjYW4gbGVnaXRpbWF0ZWx5IGluaXRp YXRlIERUTFMgb24gdGhpcyBwYWlyLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQpJZiB0d28gSUNFIGVuZHBvaW50cyBoYXZlIGEgc2hvcnQgUlRUIGFuZCBjbGVhciBjb25uZWN0 aXZpdHkgYmV0d2VlbiB0aGVtLCBidXQgYSBsb25nIFJUVCB0byB0aGVpciBzaWduYWxpbmcgc2Vy dmVyLCB0aGlzIGNhbiBoYXBwZW4gcXVpdGUgZWFzaWx5LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTog NXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPkFsc28sIGluIHJlYWxpdHkgc29tZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBub3Qg YWNjZXB0IGNvbnRlbnQgYmVmb3JlIHRoZSBhbnN3ZXIgYXJyaXZlcyDigJMgbm8gbWF0dGVyIGlm IERUTFMgaXMgdXNlZCBvciBub3Qg4oCTIHNvIHRoZSBiZXN0IHRoaW5nIGlzIHRvLCBvbmNlIHRo ZQ0KIGFuc3dlciBoYXMgYmVlbiBzZW50LCBqdXN0IHdhaXQgZm9yIGEgd2hpbGUgYmVmb3JlIHNl bmRpbmcgYW55IGNvbnRlbnQuPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCkZvcnR1bmF0ZWx5LCBEVExTIGhhcyByZXRyYW5zbWlzc2lvbnMsIHNvIHRoaXMgc2hvdWxk buKAmXQgY2F1c2UgZmFpbHVyZSwganVzdCBhIGJyaWVmIHNldHVwIGRlbGF5LjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5SZWdhcmRzLDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkNocmlz dGVyPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+bW11c2ljDQogWzxhIGhy ZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9y OiBwdXJwbGU7IiBjbGFzcz0iIj5tYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+ PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIg Y2xhc3M9IiI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5FcmljDQogUmVzY29ybGE8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0i Ij5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+MTEgTWFyY2ggMjAxNyAwMjo1NzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QmVybmFyZCBB Ym9iYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcm5hcmQuYWJvYmFAZ21haWwuY29tIiBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPmJlcm5hcmQuYWJvYmFAZ21haWwuY29t PC9zcGFuPjwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5GbGVtbWluZyBBbmRyZWFz ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20iIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+ZmFuZHJlYXNAY2lzY28uY29tPC9zcGFuPjwvYT4m Z3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86aHRhQGdvb2dsZS5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxl OyIgY2xhc3M9IiI+aHRhQGdvb2dsZS5jb208L3NwYW4+PC9hPjsNCiBtbXVzaWMgV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVy cGxlOyIgY2xhc3M9IiI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbTU1VU0lDXSBIYW5kbGluZyBvZiB1bnZlcmlmaWVkIGRh dGEgYW5kIG1lZGlhPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KU29ycnksIG5vLCBJIHdhcyBqdXN0IHRhbGtpbmcgYWJvdXQgd2hhdCBt aWdodCBvciBtaWdodCBub3QgYmUgc2FmZS4uLi4gVGhlIGRvYyB0ZXh0IGlzPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KYSBkaWZmZXJl bnQgcXVlc3Rpb24uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCi1Fa3I8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZu YnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0IDQ6MDUgUE0sIEJlcm5hcmQg QWJvYmEgJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+YmVybmFy ZC5hYm9iYUBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBu b25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJv cmRlci1sZWZ0LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDZwdDsgbWFyZ2luOiA1 cHQgMGNtIDVwdCA0LjhwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KRUtS IHNhaWQ6Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQomcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1z aXplOiA5LjVwdDsiIGNsYXNzPSIiPkkgaGF2ZW4ndCBzcGVudCB0b28gbXVjaCB0aW1lIG9uIGl0 LCBidXQgaXQgc2VlbXMgbGlrZSBpdCBvdWdodCB0byBiZSBzYWZlIHRvIGhvbGQ8L3NwYW4+PG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjVwdDsiIGNsYXNzPSIiPmFueXRoaW5n IHlvdSByZWNlaXZlIHByaW9yIHRvIGdldHRpbmcgdGhlIGZpbmdlcnByaW50LiBJdCBtaWdodCBi ZSBiZXR0ZXIsIGFzIE1UPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog OS41cHQ7IiBjbGFzcz0iIj5zdWdnZXN0cywgdG8gZGlzY2FyZCB0aGUgZGF0YWNoYW5uZWwgZGF0 YSwgYnV0IEknbSBub3Qgc3VyZSB3aHkgaXQgd291bGQgYmU8L3NwYW4+PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOiA5LjVwdDsiIGNsYXNzPSIiPm5lY2Vzc2FyeS48L3NwYW4+JnF1 b3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCltCQV0gU28geW91IGFyZSBzYXlpbmcgdGhh dCB0aGUgTVVTVCBOT1QgYWxsb3dzIHRoZSBicm93c2VyIHRvIGJ1ZmZlciBkYXRhL21lZGlhIGJ1 dCBub3QgdG8gcGFzcyBpdCB0byB0aGUgYXBwbGljYXRpb24gKGluIHRoZSBjYXNlIG9mIHRoZSBk YXRhIGNoYW5uZWwpIG9yIHRvIHBsYXkgaXQgb3V0PzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0 IDQ6MDEgUE0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20i IHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIi PmVrckBydGZtLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUg bm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgYm9yZGVy LWxlZnQtd2lkdGg6IDFwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNnB0OyBtYXJnaW46IDVwdCAw Y20gNXB0IDQuOHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KSSBoYXZlbid0IHNwZW50IHRvbyBtdWNoIHRpbWUgb24gaXQsIGJ1dCBpdCBzZWVt cyBsaWtlIGl0IG91Z2h0IHRvIGJlIHNhZmUgdG8gaG9sZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KYW55dGhpbmcgeW91 IHJlY2VpdmUgcHJpb3IgdG8gZ2V0dGluZyB0aGUgZmluZ2VycHJpbnQuIEl0IG1pZ2h0IGJlIGJl dHRlciwgYXMgTVQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCnN1Z2dlc3RzLCB0byBkaXNjYXJkIHRoZSBkYXRhY2hhbm5l bCBkYXRhLCBidXQgSSdtIG5vdCBzdXJlIHdoeSBpdCB3b3VsZCBiZTxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KbmVjZXNz YXJ5LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQotRWtyPG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIEZyaSwgTWFyIDEwLCAyMDE3IGF0IDI6 NDcgUE0sIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNv bSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9 IiI+cm9tYW5AdGVsdXJpeC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9u ZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7 IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDZwdDsgbWFyZ2lu OiA1cHQgMGNtIDVwdCA0LjhwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K TXkgYXNzdW1wdGlvbiBhbHdheXMgd2FzIHRoYXQgZGF0YSBpcyByZWNlaXZlZCwgZGVjb2RlZCBh bmQgZGlzY2FyZGVkIHVudGlsIGZpbmdlcnByaW50IGlzIHJlY2VpdmVkIGFuZCB2ZXJpZmllZC4g VGhpcyB3YXkgRFRMUyBoYW5kc2hha2UgY29tcGxldGVzLCBrZXkgZnJhbWVzIGFyZSBkZWNvZGVk LCBidXQgdXNlciBpcyBub3IgcHJlc2VudGVkIHdpdGggYW55IHVudmVyaWZpZWQgbWVkaWEuPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQpSZWdhcmRzLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YnIgY2xlYXI9ImFs bCIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KX19fX19fX19fX19fXzxzcGFuIHN0eWxl PSJjb2xvcjogcmdiKDEzNiwgMTM2LCAxMzYpOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPHNw YW4gY2xhc3M9Im0tNTQzNDMxOTEwODU1NjYwOTQxOW0tNjg1NjU2MzI3MzY2NDAzNTQzNWhvZW56 YiI+Um9tYW4gU2hwb3VudDwvc3Bhbj48L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQpPbiBUaHUsIE1hciA5LCAyMDE3IGF0IDY6NTggUE0sIE1hcnRpbiBU aG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5tYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9u ZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7 IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDZwdDsgbWFyZ2lu OiA1cHQgMGNtIDVwdCA0LjhwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpJIHRoaW5rIHRoYXQgdGhl IGRhdGEgY2hhbm5lbCBxdWVzdGlvbiBpcyBlYXN5LCBhbnl0aGluZyBvdGhlciB0aGFuIGE8YnIg Y2xhc3M9IiI+DQomcXVvdDtubyZxdW90OyBpcyBub3QgYWNjZXB0YWJsZS4mbmJzcDsgRGF0YSBp biB0aGF0IGZvcm0gZW50ZXJzIHRoZSBzZWN1cml0eTxiciBjbGFzcz0iIj4NCmJvdW5kYXJ5IGZv ciBhbiBvcmlnaW4gYW5kIGl0IGRvZXNuJ3QgbWFrZSBhbnkgc2Vuc2UgdG8gcmlzayBhdHRhY2s8 YnIgY2xhc3M9IiI+DQp0aGVyZS4mbmJzcDsgKEl0J3MgYWxzbyBsaWtlbHkgdW5uZWNlc3Nhcnks IGlmIGEgaGFsZiBhIHJvdW5kIHRyaXAgb2Y8YnIgY2xhc3M9IiI+DQpzaWduYWxpbmcgaXMgc2xv d2VyIHRoYW4gNSByb3VuZCB0cmlwcyBvbiB0aGUgbWVkaWEgcGF0aCwgdGhlbjxiciBjbGFzcz0i Ij4NCnNvbWV0aGluZyBpcyBtZXNzZWQgdXAuKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CkknbSBpbiB0d28gbWluZHMgYWJvdXQgdGhlIG1lZGlhIHBhcnQuIEZvciBtZWRpYSwgeW91IGNv dWxkIGFsc288YnIgY2xhc3M9IiI+DQpyZWFzb25hYmx5IG1ha2UgdGhlIHNhbWUgb3JpZ2luLXB1 cml0eSBhcmd1bWVudC4mbmJzcDsgSSdtIGluY2xpbmVkIHRvIHNheTxiciBjbGFzcz0iIj4NCnRo YXQuJm5ic3A7IEJ1dCB3ZSBDQU4gaXNvbGF0ZSBtZWRpYSBmcm9tIHRoZSBvcmlnaW4gKGFuZCB3 ZSBkZWZpbml0ZWx5PGJyIGNsYXNzPSIiPg0Kc2hvdWxkIGlmIHdlIGFsbG93IHRoaXMpLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNvLCB0aGUgbWVkaWEgdGhhdCBhcnJpdmVzIGhhZCB0 byBjb21wbHkgd2l0aCB5b3VyIG9mZmVyLiZuYnNwOyBUaGUgRFRMUzxiciBjbGFzcz0iIj4NCmhh bmRzaGFrZSBhbHNvIGhhcyB0byBjb21wbGV0ZSwgd2hpY2ggdGVsbHMgdGhlIHJlY2VpdmVyIHdo ZXRoZXIgdGhlPGJyIGNsYXNzPSIiPg0KbWVkaWEgbmVlZHMgdG8gYmUgY29uZmlkZW50aWFsIG9y IG5vdCAoYXQgd2hpY2ggcG9pbnQgeW91IGNhbiBkaXNhYmxlPGJyIGNsYXNzPSIiPg0KdGhpcyBm ZWF0dXJlKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCdzIGFsc28gcG9zc2libGUg dGhhdCBhIHJlY2VpdmVyIGNhbiByZXF1aXJlIHRoYXQgYW4gSUNFPGJyIGNsYXNzPSIiPg0KY29u bmVjdGl2aXR5IGNoZWNrIHdhcyBtYWRlICh0aG91Z2ggdGhpcyBpcyBpbmJvdW5kIG9ubHksIGFu ZCBJJ208YnIgY2xhc3M9IiI+DQp1bmNsZWFyIG9uIHdoZXRoZXIgaGF2aW5nIHJlY2VpdmVkIGFu IGluYm91bmQgY2hlY2sgd291bGQgbm9ybWFsbHk8YnIgY2xhc3M9IiI+DQpwcmV2ZW50IHRoZSBy ZWNlaXZlciBmcm9tIGFjY2VwdGluZyBhIHBhY2tldCkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KQWxsIHRvbGQsIHRoYXQncyBhIGxvdCBvZiBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmVn b3RpYXRlZCBzZXNzaW9uIGZvcjxiciBjbGFzcz0iIj4NCmFuIGF0dGFja2VyIHRvIGhhdmUuJm5i c3A7IFRoZSBvZGRzIG9mIHRoaXMgYmVpbmcgYW4gYXR0YWNrIHdvdWxkICpzZWVtKiB0bzxiciBj bGFzcz0iIj4NCmJlIGxvdy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiB0aGUgb3Ro ZXIgaGFuZCwgd2UgZG9uJ3QgYXNzdW1lIGNvbmZpZGVudGlhbGl0eSBvZiBzaWduYWxpbmc7IHRo ZTxiciBjbGFzcz0iIj4NCnNlY3VyaXR5IG1vZGVsIGFzc3VtZXMgdGhhdCBhbGwgdGhpcyBpbmZv cm1hdGlvbiBpcyBlZmZlY3RpdmVseSBwdWJsaWM8YnIgY2xhc3M9IiI+DQphbmQgdGhlIHByb3Rl Y3Rpb24gd2UgaGF2ZSBhZ2FpbnN0IGF0dGFjayBpcyB0aGUgY2VydGlmaWNhdGU8YnIgY2xhc3M9 IiI+DQpmaW5nZXJwcmludC4mbmJzcDsgVGhpcyB3b3VsZCByZW1vdmUgdGhhdCBwcm90ZWN0aW9u LCBhbGJlaXQgZm9yIGEgc2hvcnQ8YnIgY2xhc3M9IiI+DQpkdXJhdGlvbi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJIGhhdmUgYW4gZXh0cmEgcXVlc3Rpb246IGRvZXMgYW55b25lIHBs YW4gdG8gaW1wbGVtZW50IHRoaXM/Jm5ic3A7IEl0J3M8YnIgY2xhc3M9IiI+DQpub24tdHJpdmlh bC4mbmJzcDsgSSB0aGluayB0aGF0IEkga25vdyB3aGF0IEknZCBuZWVkIHRvIGRvIGluIEZpcmVm b3ggYW5kPGJyIGNsYXNzPSIiPg0KaXQgd291bGQgYmUgcXVpdGUgZGlzcnVwdGl2ZS4mbmJzcDsg QmVmb3JlIGNvbW1pdHRpbmcgdG8gZG8gdGhhdCB3b3JrPGJyIGNsYXNzPSIiPg0KKHdoaWNoIEkg d2lsbCBsZWF2ZSB0byBvdGhlcnMgY2xvc2VyIHRvIHRoaXMgdG8gZGVjaWRlKSwgSSdkIHByb2Jh Ymx5PGJyIGNsYXNzPSIiPg0Kd2FudCBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBhY3R1YWwgYWR2 YW50YWdlIHRoYXQgaXQgcHJvdmlkZXMuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ck9uIDEwIE1hcmNoIDIwMTcgYXQgMDc6MTAsIEJlcm5hcmQgQWJvYmEgJmx0OzxhIGhyZWY9Im1h aWx0bzpiZXJuYXJkLmFib2JhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xv cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+YmVybmFyZC5hYm9iYUBnbWFpbC5jb208L3Nw YW4+PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OyBJbiB0aGUgVzNDIFdFQlJUQyBX RywgYW4gaXNzdWUgaGFzIGJlZW4gc3VibWl0dGVkIHJlbGF0aW5nIHRvIHBsYXlvdXQgb2Y8YnIg Y2xhc3M9IiI+DQomZ3Q7IHVudmVyaWZpZWQgbWVkaWE6PGJyIGNsYXNzPSIiPg0KJmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9pc3N1ZXMvODQ5IiB0YXJnZXQ9Il9ibGFuayIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5odHRwczovL2dpdGh1Yi5j b20vdzNjL3dlYnJ0Yy1wYy9pc3N1ZXMvODQ5PC9zcGFuPjwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyBJdCBoYXMgYmVlbiBzdWdnZXN0ZWQgdGhhdCBpZiB0aGUgYnJv d3NlciBpcyBjb25maWd1cmVkIHRvIGRvIHNvLCB0aGF0PGJyIGNsYXNzPSIiPg0KJmd0OyBwbGF5 b3V0IGJlIGFsbG93ZWQgZm9yIGEgbGltaXRlZCBwZXJpb2QgKGUuZy4gNSBzZWNvbmRzKSBwcmlv ciB0bzxiciBjbGFzcz0iIj4NCiZndDsgZmluZ2VycHJpbnQgdmVyaWZpY2F0aW9uOjxiciBjbGFz cz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3czYy93ZWJydGMtcGMvcHVsbC8xMDI2IiB0 YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5o dHRwczovL2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9wdWxsLzEwMjY8L3NwYW4+PC9hPjxiciBj bGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IFNlY3Rpb24gNi4yIG9mIGRyYWZ0LWll dGYtbW11c2ljLTQ1NzItdXBkYXRlLTEzIGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgdGV4dCw8YnIg Y2xhc3M9IiI+DQomZ3Q7IGNhcnJpZWQgb3ZlciBmcm9tIFJGQyA0NTcyOjxiciBjbGFzcz0iIj4N CiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBOb3RlIHRoYXQgd2hlbiB0aGUg b2ZmZXIvYW5zd2VyIG1vZGVsIGlzIGJlaW5nIHVzZWQsIGl0IGlzIHBvc3NpYmxlPGJyIGNsYXNz PSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgZm9yIGEgbWVkaWEgY29ubmVjdGlvbiB0byBvdXRyYWNl IHRoZSBhbnN3ZXIgYmFjayB0byB0aGUgb2ZmZXJlci48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyBUaHVzLCBpZiB0aGUgb2ZmZXJlciBoYXMgb2ZmZXJlZCBhICdzZXR1cDpwYXNzaXZl JyBvciAnc2V0dXA6YWN0cGFzcyc8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyByb2xl LCBpdCBNVVNUIChhcyBzcGVjaWZpZWQgaW4gUkZDIDQxNDUgWzddKSBiZWdpbiBsaXN0ZW5pbmcg Zm9yIGFuPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgaW5jb21pbmcgY29ubmVjdGlv biBhcyBzb29uIGFzIGl0IHNlbmRzIGl0cyBvZmZlci4mbmJzcDsgSG93ZXZlciwgaXQgTVVTVDxi ciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IE5PVCBhc3N1bWUgdGhhdCB0aGUgZGF0YSB0 cmFuc21pdHRlZCBvdmVyIHRoZSBUTFMgY29ubmVjdGlvbiBpcyB2YWxpZDxiciBjbGFzcz0iIj4N CiZndDsmbmJzcDsgJm5ic3A7IHVudGlsIGl0IGhhcyByZWNlaXZlZCBhIG1hdGNoaW5nIGZpbmdl cnByaW50IGluIGFuIFNEUCBhbnN3ZXIuJm5ic3A7IElmPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNw OyAmbmJzcDsgdGhlIGZpbmdlcnByaW50LCBvbmNlIGl0IGFycml2ZXMsIGRvZXMgbm90IG1hdGNo IHRoZSBjbGllbnQnczxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IGNlcnRpZmljYXRl LCB0aGUgc2VydmVyIGVuZHBvaW50IE1VU1QgdGVybWluYXRlIHRoZSBtZWRpYSBjb25uZWN0aW9u PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgd2l0aCBhIGJhZF9jZXJ0aWZpY2F0ZSBl cnJvciwgYXMgc3RhdGVkIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguPGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgR2l2ZW4gdGhlIG91dHN0YW5kaW5nIGlzc3VlIHJlbGF0 aW5nIHRvIGhhbmRsaW5nIG9mIHVudmVyaWZpZWQgbWVkaWEsIHRoZTxiciBjbGFzcz0iIj4NCiZn dDsgQ2hhaXJzIG9mIHRoZSBXM0MgV0VCUlRDIFdHIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBjbGFy aWZpY2F0aW9uIGZyb20gdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyBJRVRGIE1NVVNJQyBXRyBhcyB0 byB0aGUgbWVhbmluZyBvZiB0aGUgJnF1b3Q7TVVTVCBOT1QmcXVvdDsgaW4gdGhlIGFib3ZlIHBh cmFncmFwaC48YnIgY2xhc3M9IiI+DQomZ3Q7IEluIHBhcnRpY3VsYXIsIHdoYXQgaXMgaXQgcGVy bWl0dGVkIGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0byBkbyB3aXRoPGJyIGNsYXNzPSIiPg0KJmd0 OyByZWNlaXZlZCBkYXRhIGFuZCBtZWRpYSBwcmlvciB0byB2ZXJpZmljYXRpb24/IEZvciBleGFt cGxlOjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgMS4gTWF5IGRhdGEgcmVjZWl2ZWQgb3ZlciB0aGUgZGF0YSBjaGFubmVsIGJlIHByb3Zp ZGVkIHRvIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgYXBwbGljYXRpb24gcHJpb3IgdG8gdmVyaWZp Y2F0aW9uPzxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGEuIElmIHRoZSBhbnN3ZXIgdG8gdGhlIGFib3ZlIGlzICZxdW90O25vJnF1b3Q7LCBtYXkg dW52ZXJpZmllZCByZWNlaXZlZCBkYXRhPGJyIGNsYXNzPSIiPg0KJmd0OyBiZSBkZWxpdmVyZWQg YnkgdGhlIERUTFMgdHJhbnNwb3J0IHRvIFNDVFAsIHdoaWNoIG1heSBidWZmZXIgaXQ/PGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IDIuIE1heSByZWNlaXZlZCBtZWRpYSBi ZSBwbGF5ZWQgb3V0IHByaW9yIHRvIHZlcmlmaWNhdGlvbj88YnIgY2xhc3M9IiI+DQomZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyBCZXJuYXJkIEFib2JhPGJyIGNsYXNzPSIiPg0KJmd0OyBPbiBiZWhh bGYgb2YgdGhlIFczQyBXRUJSVEMgV0c8YnIgY2xhc3M9IiI+DQomZ3Q7PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZn dDsgbW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZndDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIg Y2xhc3M9IiI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFu ayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvc3Bhbj48L2E+PGJyIGNsYXNzPSIiPg0K Jmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbW11c2ljIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPm1tdXNpY0Bp ZXRmLm9yZzwvc3Bhbj48L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljPC9zcGFuPjwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAxMnB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxiciBjbGFzcz0iIj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KbW11c2ljIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpt bXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsiIGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PGJyIGNsYXNzPSIiPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRh cmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9zcGFuPjwvYT48bzpw IGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJz cDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MTJwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5tbXVzaWNAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9y OiBwdXJwbGU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYzwvc3Bhbj48L2E+PG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxiciBjbGFzcz0iIj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xv cjogcHVycGxlOyIgY2xhc3M9IiI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlw dDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgY29sb3I6IHB1cnBsZTsiIGNs YXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9zcGFu PjwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B471CDFFD0E84644B8EB320694353412vidyocom_-- From nobody Mon Mar 13 15:47:53 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 BA17C129684; Mon, 13 Mar 2017 15:47:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944526673.20417.16075723424184971165@ietfa.amsl.com> Date: Mon, 13 Mar 2017 15:47:46 -0700 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 22:47: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 of the IETF. Title : RTP Payload Format Restrictions Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-10.txt Pages : 25 Date : 2017-03-13 Abstract: In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 16:49: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 3AB6E129C37 for ; Mon, 13 Mar 2017 16:49:03 -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 mnU1KYS8F6V9 for ; Mon, 13 Mar 2017 16:49:01 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 508AB129C2C for ; Mon, 13 Mar 2017 16:48:47 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id 1so235334453qkl.3 for ; Mon, 13 Mar 2017 16:48:47 -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=Yv52WcYQztng9FYVzhpX5sJakKAGgP2FyTSatEv3E0M=; b=Hjasz8NJIHDnatW2TcCq5dyR/xN7Qolc64VlY+GwilKw0DaagF5vExedJaqsOFJ1VW KaPI7Y4IxPDm+kjwecEwOFkO8+gmiStkOwU0sgnBXifqoROFT2T5Aw4+xsjGkcqcZE1K V+4Ut5gCRkxElc7uJFCvlZqpXGWuPC40QiRXkXs5yBXvHTXMh0wF5KqdgdVEbdCPzj0N VbSnhXSbp+DZHoy8BLZ7YZDEj/fWdW1KMotZdcJqoym3uEK2TVy1NsMI+Rze8N10EPW2 ur1PAOO0r7M42Qj8A+89YwxZ5nltO4aj/We+n+5d/OpJrEr4FhU7hug8l4R8LwqYKOrC QHBA== 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=Yv52WcYQztng9FYVzhpX5sJakKAGgP2FyTSatEv3E0M=; b=j16/Jw2FnMyska3cCxKxSvDqUI7TKX6UAUru6/CfPGEeVKtoTHUcUSBGu6OWmEld0Y EEkNTU/H2zvmvA5OJ1jFgIkh7FxcjcuyiaavKvTyD1AE4VkTqJG1eUZhUs6NxxB4XS6i hfKTZEOYEywfBeZdgvhqftzzd5fp2LXEoAnD6iflvoxhf4s3XW3TmK3oeOWv5gaX2795 3oKA/HMcj7VemEgujjRr4at+aTo5agsJeRAGNhC1Q0H5KY7icHZl2nsd5NnXl7qoRd5L Sq8DxBN3Q2Mnc2u3DwDjQ1hDi+Jkt7yxZtjxmKGDHS5sNWTsHdGVz9CTt8mNUlD45Ktv +CJg== X-Gm-Message-State: AFeK/H1CJigI3guFF8EXZGvgGkaBY2gzls0y27gK9eb+Viq2ybsjia4yJWTEsjvWU77U9Gmg5L0pErut81LZuQ== X-Received: by 10.55.18.144 with SMTP id 16mr34988646qks.5.1489448923655; Mon, 13 Mar 2017 16:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 16:48:43 -0700 (PDT) From: Martin Thomson Date: Tue, 14 Mar 2017 10:48:43 +1100 Message-ID: To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [MMUSIC] Unknown key shares in MMUSIC X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 23:49:03 -0000 After completely failing to remember and take into account feedback during the avtcore meeting last time (thanks for the reminder Jonathan), I would like to draw the attention of this group to this draft: https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ The latest version builds on the a=dtls-id work in this group. However, Jonathan's reminder highlighted a critical shortcoming of that: it only works for DTLS. We still have uses of TLS-over-TCP that would not be addressed by the current iteration of the draft (though they would have for the previous version). One relatively simple solution is to define dtls-id as tls-id instead, but that's disruptive. I'd like to discuss this issue with an eye to resolving it before or at Chicago; I realize that there is a probably a tight agenda, but the outcome of that discussion might affect a very-far-advanced draft-ietf-mmusic-dtls-sdp-21. From nobody Mon Mar 13 18:51: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 D26E11294E6; Mon, 13 Mar 2017 18:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 CDXMG8hVAlqS; Mon, 13 Mar 2017 18:51:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F6E12946A; Mon, 13 Mar 2017 18:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8914; q=dns/txt; s=iport; t=1489456267; x=1490665867; h=subject:references:to:from:cc:message-id:date: mime-version:in-reply-to; bh=BCeDHlUUIdwJ94Z4FIhWgre1EQH2gSdirPo9qnS2iXk=; b=cCHKu5QFk97W33znCSsGgBkE+yhk+7vi/kCLxWRoxmGlCahqZDLthhOj XT/Rs077dCf/2vnthXaQPJc0+rU2vVTqywNIOqnHC8iGNJ5Vt9c1q9YBU RoYd0E+1e8/gO1+n3Zwp1/6Zof/Hq7ib3097LBnwGIp0nLXAO84rNMbUe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAwAlTMdY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhKmCDYIoNkTIfkA6FLYIOLIV2AoJiPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQMDI1QCEBwDAQIrAgJPCAYNBgIBAYlvDQ6tToImK4o3AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYZOggUIhXmBXYJmgl8Fj1uMZoFShSSLQ4F7VIRRgzKGU5NDHzi?= =?us-ascii?q?BBDkfFRiFNoFmJDUBiWEBAQE?= X-IronPort-AV: E=Sophos;i="5.36,162,1486425600"; d="scan'208,217";a="209566655" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Mar 2017 01:51:06 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2E1p4WM009247; Tue, 14 Mar 2017 01:51:05 GMT References: <148944101434.20377.3462000433914478523.idtracker@ietfa.amsl.com> To: mmusic From: Flemming Andreasen X-Forwarded-Message-Id: <148944101434.20377.3462000433914478523.idtracker@ietfa.amsl.com> Message-ID: <4d7fd0a3-dc9a-1354-b95c-1640879d33cf@cisco.com> Date: Mon, 13 Mar 2017 21:51:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <148944101434.20377.3462000433914478523.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BE94DCFF1EB873CE1A167B56" Archived-At: Cc: Ben Campbell , "mmusic-chairs@tools.ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" Subject: [MMUSIC] Changes in sctp-sdp [Was Fwd: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 01:51:10 -0000 This is a multi-part message in MIME format. --------------BE94DCFF1EB873CE1A167B56 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Folks In case you didn't follow the e-mail discussions from the IESG review, we just wanted to make you aware of a few changes that were made in the sctp-sdp draft as a result of that (most notably in Section 12.2 - ICE Considerations). See https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sctp-sdp-23&url2=draft-ietf-mmusic-sctp-sdp-25 for details and let the chairs know no later than March 17 (this Friday) if you have any concerns with this. Thanks -- Flemming & Bo (MMUSIC chairs) -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt Resent-Date: Mon, 13 Mar 2017 14:36:54 -0700 Resent-From: alias-bounces@ietf.org Resent-To: fandreas@cisco.com, bo.burman@ericsson.com Date: Mon, 13 Mar 2017 14:36:54 -0700 From: internet-drafts@ietf.org To: mmusic-chairs@ietf.org, Roman Shpount , Christer Holmberg , Salvatore Loreto , Gonzalo Camarillo , Gonzalo Camarillo A new version of I-D, draft-ietf-mmusic-sctp-sdp-25.txt has been successfully submitted by Christer Holmberg and posted to the IETF repository. Name: draft-ietf-mmusic-sctp-sdp Revision: 25 Title: Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. Document date: 2017-03-13 Group: mmusic Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-25.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-25 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-25 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat . --------------BE94DCFF1EB873CE1A167B56 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks

In case you didn't follow the e-mail discussions from the IESG review, we just wanted to make you aware of a few changes that were made in the sctp-sdp draft as a result of that (most notably in Section 12.2 - ICE Considerations). See

    https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sctp-sdp-23&url2=draft-ietf-mmusic-sctp-sdp-25

for details and let the chairs know no later than March 17 (this Friday) if you have any concerns with this.

Thanks

-- Flemming & Bo (MMUSIC chairs)




-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt
Resent-Date: Mon, 13 Mar 2017 14:36:54 -0700
Resent-From: alias-bounces@ietf.org
Resent-To: fandreas@cisco.com, bo.burman@ericsson.com
Date: Mon, 13 Mar 2017 14:36:54 -0700
From: internet-drafts@ietf.org
To: mmusic-chairs@ietf.org, Roman Shpount <rshpount@turbobridge.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Salvatore Loreto <Salvatore.Loreto@ericsson.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> 


A new version of I-D, draft-ietf-mmusic-sctp-sdp-25.txt
has been successfully submitted by Christer Holmberg and posted to the
IETF repository.

Name:		draft-ietf-mmusic-sctp-sdp
Revision:	25
Title:		Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.
Document date:	2017-03-13
Group:		mmusic
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-25.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-25
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-25

Abstract:
   The Stream Control Transmission Protocol (SCTP) is a transport
   protocol used to establish associations between two endpoints.
   draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used
   on top of the Datagram Transport Layer Security (DTLS) protocol,
   referred to as SCTP-over-DTLS.

   This specification defines the following new Session Description
   Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP'
   and 'TCP/DTLS/SCTP'.  This specification also specifies how to use
   the new proto values with the SDP Offer/Answer mechanism for
   negotiating SCTP-over-DTLS associations.

                                                                                  


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

The IETF Secretariat

.
--------------BE94DCFF1EB873CE1A167B56-- From nobody Mon Mar 13 20:05:21 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 C64D6129BD5; Mon, 13 Mar 2017 20:05:19 -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 h-8BqfdH8IZx; Mon, 13 Mar 2017 20:05:17 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 99F4A129BBD; Mon, 13 Mar 2017 20:05:17 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p64so238449288qke.1; Mon, 13 Mar 2017 20:05:17 -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=bh1KgZzdW9ViToSa/d4cd6WxgMEU5tSMKeAQfGSI390=; b=iPg+EK/T4cJbOdPmvo2DgdXaazsiEqqwUobY6RAuIiTfpU8OnOvjNdCWZfql4hI4E+ aG4SoGi9qnFe08OxOYWHjhuM6fbYTxgzUTwO7WRGOszbDD0ArbOULYty3YYlMhxtlv4/ mi2IAPoM7S+Dex1e36uVx/Va1Bkm1kUDVfgj629WbUDWyw4M0OtgqXVbspH0hZJsIP/x 6nByX1HQif0lYzR1kSVhMBGJ5wAb77Rub+d+F/R4TULiRmfdvexFQqU3rZAaConQmMwT mHxLq0cJKc/8Suca7aemoACHByVA37pxgo+XHjkZt8VtvaxvQ7dHnF9j+AGAgBB0D/8W Urcw== 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=bh1KgZzdW9ViToSa/d4cd6WxgMEU5tSMKeAQfGSI390=; b=RmxjCaFTSo3SGx5iElm3oEYH6uZVDi1YELvhbE5RzMeoaCvTI9K06HtjNSMf/4eJEk C2SmcSt/GtPaXoqv1B9WLp13EbCUmLlIVCT1RlcEMn3n0hSPg/XJYcnAVFG4xuivECIu MXYZWMqcyotOIM52463NlSUCvvnmRhVowduIDGTk8GUy8PHWbiaSPvOa8XngXIHQ9+By p48LbPBrt1BMHAxCfOo75n2aAsuQXBcqBng9blhiCmp7AsvF5pXJk2AVkJyiBCTG4d0J kIUnIgSAAKFofq4X5xCEUAuyubWD8pYxD1gc4OEv6/j1HZC6EObibI7sqPd080a/7gQt yzCA== X-Gm-Message-State: AFeK/H2P2jki5mEsqOyR5xp+luaI/y9DNIsUJ9Mh5i5jnAWFa4Lnmjce+pQeBVGjnfTIQazfY97U2ScrwgslsA== X-Received: by 10.55.5.146 with SMTP id 140mr35750480qkf.202.1489460716752; Mon, 13 Mar 2017 20:05:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Mon, 13 Mar 2017 20:05:16 -0700 (PDT) In-Reply-To: <4d7fd0a3-dc9a-1354-b95c-1640879d33cf@cisco.com> References: <148944101434.20377.3462000433914478523.idtracker@ietfa.amsl.com> <4d7fd0a3-dc9a-1354-b95c-1640879d33cf@cisco.com> From: Martin Thomson Date: Tue, 14 Mar 2017 14:05:16 +1100 Message-ID: To: Flemming Andreasen Content-Type: multipart/alternative; boundary=001a11488338edd693054aa8188e Archived-At: Cc: Ben Campbell , "mmusic-chairs@tools.ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , mmusic Subject: Re: [MMUSIC] Changes in sctp-sdp [Was Fwd: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 03:05:19 -0000 --001a11488338edd693054aa8188e Content-Type: text/plain; charset=UTF-8 grammar: "between UDP to TCP candidate pairs" should be "and". On 14 March 2017 at 12:51, Flemming Andreasen wrote: > Folks > > In case you didn't follow the e-mail discussions from the IESG review, we > just wanted to make you aware of a few changes that were made in the > sctp-sdp draft as a result of that (most notably in Section 12.2 - ICE > Considerations). See > > https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sctp- > sdp-23&url2=draft-ietf-mmusic-sctp-sdp-25 > > for details and let the chairs know no later than March 17 (this Friday) > if you have any concerns with this. > > Thanks > > -- Flemming & Bo (MMUSIC chairs) > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt > Resent-Date: Mon, 13 Mar 2017 14:36:54 -0700 > Resent-From: alias-bounces@ietf.org > Resent-To: fandreas@cisco.com, bo.burman@ericsson.com > Date: Mon, 13 Mar 2017 14:36:54 -0700 > From: internet-drafts@ietf.org > To: mmusic-chairs@ietf.org, Roman Shpount > , Christer Holmberg com> , Salvatore Loreto > , Gonzalo > Camarillo > , Gonzalo Camarillo > > > A new version of I-D, draft-ietf-mmusic-sctp-sdp-25.txt > has been successfully submitted by Christer Holmberg and posted to the > IETF repository. > > Name: draft-ietf-mmusic-sctp-sdp > Revision: 25 > Title: Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. > Document date: 2017-03-13 > Group: mmusic > Pages: 26 > URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp-sdp-25.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-25 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-25 > > Abstract: > The Stream Control Transmission Protocol (SCTP) is a transport > protocol used to establish associations between two endpoints. > draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used > on top of the Datagram Transport Layer Security (DTLS) protocol, > referred to as SCTP-over-DTLS. > > This specification defines the following new Session Description > Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' > and 'TCP/DTLS/SCTP'. This specification also specifies how to use > the new proto values with the SDP Offer/Answer mechanism for > negotiating SCTP-over-DTLS associations. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > . > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11488338edd693054aa8188e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
grammar: "between UDP to= TCP candidate pairs" should be "and".

On 14 March 2017 at 12= :51, Flemming Andreasen <fandreas@cisco.com> wrote:
=20 =20 =20
Folks

In case you didn't follow the e-mail discussions from the IESG review, we just wanted to make you aware of a few changes that were made in the sctp-sdp draft as a result of that (most notably in Section 12.2 - ICE Considerations). See

=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdiff?u= rl1=3Ddraft-ietf-mmusic-sctp-sdp-23&url2=3Ddraft-ietf-mmusic-= sctp-sdp-25

for details and let the chairs know no later than March 17 (this Friday) if you have any concerns with this.

Thanks

-- Flemming & Bo (MMUSIC chairs)




-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt
Resent-Date: Mon, 13 Mar 2017 14:36:54 -0700
Resent-From: alias-bounces@ietf= .org
Resent-To: fandreas@cisco.com= , bo.burman@ericsson.com
Date: Mon, 13 Mar 2017 14:36:54 -0700
From: internet-drafts@= ietf.org
To: mmusic-chairs@ietf= .org, Roman Shpount <rshpount@turbobr= idge.com>, Christer Holmberg <christer.h= olmberg@ericsson.com>, Salvatore Loreto <Salvatore.L= oreto@ericsson.com>, Gonzalo Camarillo <Gonzalo.Ca= marillo@ericsson.com>, Gonzalo Camarillo <gonzalo.ca= marillo@ericsson.com> 


A new version of I-D, draft-ietf-mmusic-sctp-sdp-25.txt
has been successfully submitted by Christer Holmberg and posted to the
IETF repository.

Name:		draft-ietf-mmusic-sctp-sdp
Revision:	25
Title:		Session Description Protocol (SDP) Offer/Answer Procedures For Stre=
am Control Transmission Protocol (SCTP) over Datagram Transport Layer Secur=
ity (DTLS) Transport.
Document date:	2017-03-13
Group:		mmusic
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-ietf-mm=
usic-sctp-sdp-25.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-25
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-s=
ctp-sdp-25

Abstract:
   The Stream Control Transmission Protocol (SCTP) is a transport
   protocol used to establish associations between two endpoints.
   draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used
   on top of the Datagram Transport Layer Security (DTLS) protocol,
   referred to as SCTP-over-DTLS.

   This specification defines the following new Session Description
   Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP=
9;
   and 'TCP/DTLS/SCTP'.  This specification also specifies how to u=
se
   the new proto values with the SDP Offer/Answer mechanism for
   negotiating SCTP-over-DTLS associations.

                                                                           =
      =20


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

The IETF Secretariat

.

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

--001a11488338edd693054aa8188e-- From nobody Mon Mar 13 20:58:29 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 BC959129622; Mon, 13 Mar 2017 20:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 mTHGcmwDOo7O; Mon, 13 Mar 2017 20:58:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289C512948A; Mon, 13 Mar 2017 20:58:27 -0700 (PDT) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2E3wPOj066611 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Mar 2017 22:58:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: draft-ietf-mmusic-dtls-sdp.all@ietf.org, mmusic Date: Mon, 13 Mar 2017 22:58:25 -0500 Message-ID: <9EB253C7-ED36-4D00-BCC7-20EC6E4441B4@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 03:58:29 -0000 Hi, This is my AD Evaluation of draft-ietf-mmusic-dtls-sdp-20. I'd like to resolve my substantive comments and questions prior to IETF last call. Thanks! Ben. --------------------- Substantive Comments: - section 4: "If an offer or answer does not contain a ’dtls-id’ attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the ’dtls-id’ attribute), the offer or answer MUST be treated as if no ’dtls-id’ attribute is included. " That seems to say that if dtls-id is not included, the offer or answer must be treated as if it's not included. Since that's tautologically true, I suspect you meant to say something more? -8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision a scenario where it would make sense to not follow them? -9.2, new text for section 5, 5th paragraph: Since we are touching this section, shouldn't we update the 4474 reference to 4474bis, and update the language about what gets signed in 4474bis? And can we take this opportunity for a MUST level requirement for some kind of integrity protection of fingerprints, even if not 4474/4474bis? (At least when not considering opportunistic crypto cases.) -- 4th paragraph from end of new text: should "the certificate fingerprint" say "a certificate fingerprint"? (Since you can have multiple fingerprints now...) -10: If you accept my suggestion to move from 4474 to 4474bis in the updated text for 5763, that will create changes that should probably be mentioned here. For example, 4474bis signatures cover fewer things than do 4474 signatures. The hope that 4474bis may be more deployable than 4474, and therefore really used, may also be worth a mention here. Editorial Comments: - Throughout the document, I found it confusing whether a "new" association means an initial association or a replacement association. In some places it doesn't matter (and I was happy to see that it really doesn't matter for much of the normative guidance), but for example 5.4 talks about replacing an old association even though IIUC the section talks about the answer to an initial offer. If the intent is for new to mean "initial or replacement" in all cases, then a sentence to that effect early in the document would be helpful. - 3.1, "A new DOTLS association MUST be estlablished ...": Established by what? (Please consider active voice.) Also, that MUST seems redundant to the 2119 language in the much more detailed procedure sections that follow; maybe this should be lower case? "The intent to establish a new DTLS association is explicitly signaled ...": Likewise, signaled by what? - 3.2: Are the 2119 keywords here redundant with those in the more detailed procedure sections that follow? - 3.2, paragraph 2: I don't think the word "explicitly" constrains anything. Also, s/"... to span ..." / "... from spanning ..." - 4: "a modification of one or more of the following characteristics MUST be treated as an indication": Treated as an indication by what? (Please consider active voice when using 2119 keywords.) - 5.1, paragraph 4: "a new transport (3-tuple) MUST be allocated by at least one of the end points so that DTLS packets can be de-multiplexed.": That seems redundant with the more detailed procedures that follow. Please consider it descriptively here, and saving the 2119 words for the more detailed procedures. -6, 2nd paragraph: Can you offer a citation for the deprecation of aggressive nomination? -- 3rd paragraph: "at least one of the endpoints MUST allocate": I suspect that's redundant to 2119 language in the detailed procedures. But if it's not, please restate with specific procedure for the offerer and answer. It's vague to assign a 2119 MUST to "at least one". -8, first paragraph: "If forking occurs, separate DTLS associations MUST be established between the caller and each callee.": This seems like a statement of fact. That is, how could they _not_ establish a separate association, since I assume you would end up with a unique 5-tuple for each branch. -9.2, paragraph 5: "The SIP message containing the offer SHOULD be sent to the offerer’s SIP proxy over an integrity protected channel": This seems redundant with a previous statement 2 sentences back. (Yes, this was in the original text...) -- Last paragraph in new text for section 5: Do you intend for "RFCXXXX" to refer to _this_ document? If so, a note to the RFC editor to that effect would be helpful. (There are multiple occurrences.) From nobody Tue Mar 14 01:00: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 3C5551294B3; Tue, 14 Mar 2017 01:00: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 xEuslRu_LqIj; Tue, 14 Mar 2017 01:00:43 -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 44B5D126CD8; Tue, 14 Mar 2017 01:00:42 -0700 (PDT) X-AuditID: c1b4fb2d-2dacd98000006193-29-58c7a328b69c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id E7.18.24979.823A7C85; Tue, 14 Mar 2017 09:00:40 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 09:00:39 +0100 From: Christer Holmberg To: Martin Thomson , Flemming Andreasen Thread-Topic: [MMUSIC] Changes in sctp-sdp [Was Fwd: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt] Thread-Index: AQHSnGV13zTS2iSG0ke2DHZG5UIAc6GTlg0AgAB02YA= Date: Tue, 14 Mar 2017 08:00:39 +0000 Message-ID: References: <148944101434.20377.3462000433914478523.idtracker@ietfa.amsl.com> <4d7fd0a3-dc9a-1354-b95c-1640879d33cf@cisco.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.1.161129 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D4ED706219682christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyM2K7ga7G4uMRBiu61C3md55mt3i1bj6z xfsLuhbXzvxjtPi3N8li6vLHLA5sHlN+b2T12DnrLrvHkiU/mTxm7XzC4vHl8me2ANYoLpuU 1JzMstQifbsEroz7v2azFpzNr+h5voCtgfFFYhcjJ4eEgInEpn2PmLsYuTiEBNYxSuxrmwbl LGaUuNx2Esjh4GATsJDo/qcN0iAiECFx99VmJpAaZoEzjBKnH65gA0kIC5RKvHp5nxmiqEzi 2dpPTBC2lcTq2ZtYQWwWAVWJ7S3HWUBsXgFriUXzHzJCLDvOKNGxejNYM6dAoMTKjZ8ZQWxG ATGJ76fWgA1iFhCXuPVkPhPE2QISS/acZ4awRSVePv4HtkBUQE9i+fM1UHFFiavTlzOBPMAs kCDxe6skxF5BiZMzn7BMYBSdhWTqLISqWUiqIEp0JBbs/sQGYWtLLFv4mhnGPnPgMROEbS0x 6+dmRmQ1Cxg5VjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERvLBLb91dzCufu14iFGAg1GJ h/fD5mMRQqyJZcWVuYcYJTiYlUR4tzUdjxDiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQ QHpiSWp2ampBahFMlomDU6qBsf9Hv9gLkQUTp7/bGHZt5dGQLZLLWNuLDvz4U9dr9jB4m2fS 8pDvPl8b7Zz3qSjsdFgdUJdcY3GxKFTv554bmql/fmy7evvh5PWaMddPJvH0hu9fbyFdob1d 0Exh9o/ME8u3670QPh3J17ekZbLfDX+XLZWXKi5vcPm+gl1Ya9vV6d/T0xfnPFNiKc5INNRi LipOBACYqJf34AIAAA== Archived-At: Cc: Ben Campbell , "mmusic-chairs@tools.ietf.org" , "draft-ietf-mmusic-sctp-sdp@ietf.org" , mmusic Subject: Re: [MMUSIC] Changes in sctp-sdp [Was Fwd: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 08:00:45 -0000 --_000_D4ED706219682christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will be fixed. Thanks! Regards, Christer From: Martin Thomson > Date: Tuesday 14 March 2017 at 05:05 To: Flemming Andreasen > Cc: "mmusic@ietf.org" >, Ben Campbell >, "mmus= ic-chairs@tools.ietf.org" >, "draft-ietf-mmusic= -sctp-sdp@ietf.org" > Subject: Re: [MMUSIC] Changes in sctp-sdp [Was Fwd: New Version Notificatio= n for draft-ietf-mmusic-sctp-sdp-25.txt] Resent-From: > Resent-To: Gonzalo Camarillo >, Salvatore Loreto >, Christer Holmberg > Resent-Date: Tuesday 14 March 2017 at 05:05 grammar: "between UDP to TCP candidate pairs" should be "and". On 14 March 2017 at 12:51, Flemming Andreasen > wrote: Folks In case you didn't follow the e-mail discussions from the IESG review, we j= ust wanted to make you aware of a few changes that were made in the sctp-sd= p draft as a result of that (most notably in Section 12.2 - ICE Considerati= ons). See https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sctp-sdp-23&url2= =3Ddraft-ietf-mmusic-sctp-sdp-25 for details and let the chairs know no later than March 17 (this Friday) if= you have any concerns with this. Thanks -- Flemming & Bo (MMUSIC chairs) -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.= txt Resent-Date: Mon, 13 Mar 2017 14:36:54 -0700 Resent-From: alias-bounces@ietf.org Resent-To: fandreas@cisco.com, bo.burman@er= icsson.com Date: Mon, 13 Mar 2017 14:36:54 -0700 From: internet-drafts@ietf.org To: mmusic-chairs@ietf.org, Roman Shpoun= t , Christer Hol= mberg , Salvatore Loreto , Gonzalo Camarillo , Gonzalo Camarillo A new version of I-D, draft-ietf-mmusic-sctp-sdp-25.txt has been successfully submitted by Christer Holmberg and posted to the IETF repository. Name: draft-ietf-mmusic-sctp-sdp Revision: 25 Title: Session Description Protocol (SDP) Offer/Answer Procedures = For Stream Control Transmission Protocol (SCTP) over Datagram Transport Lay= er Security (DTLS) Transport. Document date: 2017-03-13 Group: mmusic Pages: 26 URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-sctp= -sdp-25.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp= / Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-25 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sctp-= sdp-25 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D4ED706219682christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6441A8833FDE8A438516C6C666383BC5@ericsson.com> Content-Transfer-Encoding: quoted-printable
Will be fixed.

Thanks!

Regards,

Christer

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tuesday 14 March 2017 at 05:0= 5
To: Flemming Andreasen <fandreas@cisco.com>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>, Ben Campbell <ben@nostrum.com>, "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ie= tf.org>, "draft-ietf-mmusic-sctp-sdp@ietf.org" <draft-ietf-mmusic-sctp-sdp@ietf.org>=
Subject: Re: [MMUSIC] Changes in sc= tp-sdp [Was Fwd: New Version Notification for draft-ietf-mmusic-sctp-sdp-25= .txt]
Resent-From: <alias-bounces@ietf.org>
Resent-To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.= com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, Christer Holmberg <christer.ho= lmberg@ericsson.com>
Resent-Date: Tuesday 14 March 2017 = at 05:05

grammar: "between UDP to= TCP candidate pairs" should be "and".

On 14 March 2017 at 12:51, Flemming Andreasen <fandreas@cisco.= com> wrote:
Folks

In case you didn't follow the e-mail discussions from the IESG review, we j= ust wanted to make you aware of a few changes that were made in the sctp-sd= p draft as a result of that (most notably in Section 12.2 - ICE Considerati= ons). See

    https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-sctp-sdp-23= &url2=3Ddraft-ietf-mmusic-sctp-sdp-25

for details and let the chairs know no later than March 17 (this Friday) if= you have any concerns with this.

Thanks

-- Flemming & Bo (MMUSIC chairs)




-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-mmusic-sctp-sdp-25.txt
Resent-Date: Mon, 13 Mar 2017 14:36:54 -0700
Resent-From: alias-bounces@ietf.org
Resent-To: fandreas@cisco.com, bo.burman@ericsson.com
Date: Mon, 13 Mar 2017 14:36:54 -0700
From: internet-drafts@ietf.org=
To: mmusic-chairs@ietf.org, Ro= man Shpount <rshpount@turbobridge.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Salvatore Loreto <Salvatore.Loreto@ericsson.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> 


A new version of I-D, draft-ietf-mmusic-sctp-sdp-25.txt
has been successfully submitted by Christer Holmberg and posted to the
IETF repository.

Name:		draft-ietf-mmusic-sctp-sdp
Revision:	25
Title:		Session Description Protocol (SDP) Offer/Answer Procedures For Stre=
am Control Transmission Protocol (SCTP) over Datagram Transport Layer Secur=
ity (DTLS) Transport.
Document date:	2017-03-13
Group:		mmusic
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-ietf-mm=
usic-sctp-sdp-25.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-25
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-s=
ctp-sdp-25

Abstract:
   The Stream Control Transmission Protocol (SCTP) is a transport
   protocol used to establish associations between two endpoints.
   draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used
   on top of the Datagram Transport Layer Security (DTLS) protocol,
   referred to as SCTP-over-DTLS.

   This specification defines the following new Session Description
   Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP'
   and 'TCP/DTLS/SCTP'.  This specification also specifies how to use
   the new proto values with the SDP Offer/Answer mechanism for
   negotiating SCTP-over-DTLS associations.

                                                                           =
      =20


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

The IETF Secretariat
--_000_D4ED706219682christerholmbergericssoncom_-- From nobody Tue Mar 14 01:47: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 7BC75129469; Tue, 14 Mar 2017 01:47:12 -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 vNwj-VYqXwrb; Tue, 14 Mar 2017 01:47:11 -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 8D053129441; Tue, 14 Mar 2017 01:47:10 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-b8-58c7ae0cba36 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 1A.EE.11640.B0EA7C85; Tue, 14 Mar 2017 09:47:08 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.319.2; Tue, 14 Mar 2017 09:47:06 +0100 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> From: Magnus Westerlund Message-ID: <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> Date: Tue, 14 Mar 2017 09:47:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM2J7oC7PuuMRBku3yFiseH2O3WLq8scs Fmv/tbM7MHssWfKTyWPy4zbmAKYoLpuU1JzMstQifbsEroxHv5+zFnzjrVjw5xRrA+N3ri5G Tg4JAROJDxdOMHcxcnEICaxjlHi37RYThLOcUeLf1O/sIFXCAl4SbdsmMoPYIgIKEr/+nGCB KPrFIrH5zF6gIg4OZgEfiYXPEkFq2AQsJG7+aGQDsXkF7CWWPTvAAmKzCKhK7Fn0hgnEFhWI kWhZ8oERokZQ4uTMJ2A1nAKBEjNfHWEFsZmB5sycf54RwpaXaN46G+wGIQFtiYamDtYJjAKz kLTPQtIyC0nLAkbmVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBIXpwy2/VHYyX3zgeYhTg YFTi4f2w+ViEEGtiWXFl7iFGCQ5mJRHebU3HI4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28 Hy4kkJ5YkpqdmlqQWgSTZeLglGpglGBheF5iLHa8J39C9f0dgr/bkvrLu8o39m9udniXs/Pv nnULynfxnNpeImu8L9P2rMf+rifJ/3K/qZptYUrlvxDyWKcwdH3YV6H/W677hvBOld555i9D 7rX1tvM+repRbW1neOaYVlFYellRlG/bVh2WELtbaxudHi+v2rhx88cDcf3Py0/ZKLEUZyQa ajEXFScCAMjezidNAgAA Archived-At: Cc: "rtcweb@ietf.org" , "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 08:47:12 -0000 Den 2017-03-10 kl. 16:31, skrev Eric Rescorla: > > When the BUNDLE extension is used, a single set of security > credentials over the bundled media descriptions will need to be used, > at least per direction or endpoint. > > > Actually, why does this have to be the case? I mean, we require it, but > if you have the MID extension, you could easily not do this. > You are correct, this is actually misstating the problem. It is not the security credentials that need to be a single set. Any SDP level security configuration used on individual media description MUST be possible to use when creating a bundle group across the full or a sub-set of the media description offered as a bundle group. This works fine for the below listed ones by following the limiations indicated in SDP MUX attributes, i.e. transport or identical. But for a future mechanism that is defined with bundle in mind from the start could have individual configurations. > > > When using SRTP this will be the > case, at least for the IETF defined key-management solutions due to > their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their > classification in [I-D.ietf-mmusic-sdp-mux-attributes]. > I will have to think on how to re-write this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Mar 14 01:59: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 384A3129441; Tue, 14 Mar 2017 01:59:31 -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 wnbIrnka0n2k; Tue, 14 Mar 2017 01:59:29 -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 5997B12943B; Tue, 14 Mar 2017 01:59:29 -0700 (PDT) X-AuditID: c1b4fb2d-2dacd98000006193-f9-58c7b0ef6fa0 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id ED.56.24979.FE0B7C85; Tue, 14 Mar 2017 09:59:27 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 09:59:26 +0100 From: Christer Holmberg To: Ben Campbell , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , mmusic Thread-Topic: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments Thread-Index: AQHSnKFIZPUXLA+RFUGrIb2KhDlggg== Date: Tue, 14 Mar 2017 08:59:26 +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.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7h+77DccjDLYs0rOY33ma3WLH3R1s FlOXP2ZxYPZYsuQnk8esnU9YApiiuGxSUnMyy1KL9O0SuDKOXt7CVNAgWrFjQTtjA+MlgS5G Dg4JAROJv685uhi5OIQE1jFKvD/znRHCWcwosfnRWhaQIjYBC4nuf9ogcRGByYwS/btamUDi wgJREjcmcnUxcgLFoyXunf3CCmHrSey5+pQNxGYRUJU4eeMcmM0rYC2x/MB7FhCbUUBM4vup NUwgNrOAuMStJ/PBbAkBAYkle84zQ9iiEi8f/wObKQo0c/nzNVBxJYkfGy6xQPQaSLw/N58Z 5BxmoPnvp9dDhLUlli18zQyxVlDi5MwnLBMYRWYh2TYLSfcshO5ZSLpnIelewMi6ilG0OLW4 ODfdyFgvtSgzubg4P08vL7VkEyMwVg5u+a27g3H1a8dDjAIcjEo8vB82H4sQYk0sK67MPcQo wcGsJML7d+XxCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4 pRoY1TnUClrNSm9vcrkv8frOOo4Zwss6dszu02NM82RWeet81M6f19yY127TmqAfee2m59Wf 7vE4KdK72O1RaY+JrZCZ1YRZiYv75qw4rbmZI6nS+9DewF/H11+S5lcraNh96Xiq6IujlUw5 tz4e0WTIkHdZOj+Mc7HP53euQkqvb87aWyuezc2kxFKckWioxVxUnAgAwKlEjZECAAA= Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 08:59:31 -0000 Hi Ben, Thanks for your review! Please see inline. >This is my AD Evaluation of draft-ietf-mmusic-dtls-sdp-20. I'd like to >resolve my substantive comments and questions prior to IETF last call. > >Thanks! > >Ben. > >--------------------- > >Substantive Comments: > >- section 4: "If an offer or answer does not > contain a =B9dtls-id=B9 attribute (this could happen if the offerer >or > answerer represents an existing implementation that has not been > updated to support the =B9dtls-id=B9 attribute), the offer or answer >MUST > be treated as if no =B9dtls-id=B9 attribute is included. " > >That seems to say that if dtls-id is not included, the offer or answer >must be treated as if it's not included. Since that's tautologically >true, I suspect you meant to say something more? This is related to the first sentence, saying that there is no default value defined for the attribute. I could say =B3Hence, if an offer or answer does not contain=8A=B2, if it m= akes the text more clear. ---- >-8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision a >scenario where it would make sense to not follow them? I can=B9t think of any scenario, so I am happy to use MUST. ---- >-9.2, new text for section 5, 5th paragraph: >Since we are touching this section, shouldn't we update the 4474 >reference to 4474bis, and update the language about what gets signed in >4474bis? And can we take this opportunity for a MUST level requirement >for some kind of integrity protection of fingerprints, even if not >4474/4474bis? (At least when not considering opportunistic crypto >cases.) See my reply to your comment on section 10. ---- >-- 4th paragraph from end of new text: >should "the certificate fingerprint" say "a certificate fingerprint"? >(Since you can have multiple fingerprints now...) Yes. I will fix that. ---- >-10: > >If you accept my suggestion to move from 4474 to 4474bis in the updated >text for 5763, that will create changes that should probably be >mentioned here. For example, 4474bis signatures cover fewer things than >do 4474 signatures. The hope that 4474bis may be more deployable than >4474, and therefore really used, may also be worth a mention here. RFC 5763 contains 20+ references to RFC 4474, in a number of different sections.=20 We would have to update all of those sections (at least the reference, possibly also normative text), because I don=B9t think we should mix 4474 and 4474bis. In my opinion, that should be done as a separate task. (I will reply to your editorial comments in a separate e-mail) Regards, Christer From nobody Tue Mar 14 05:02: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 3C202129555; Tue, 14 Mar 2017 05:02: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 NBkrW6awlDG3; Tue, 14 Mar 2017 05:02:39 -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 ACD4A12951B; Tue, 14 Mar 2017 05:02:38 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-44-58c7dbdc5c3a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id B4.6F.11640.CDBD7C85; Tue, 14 Mar 2017 13:02:36 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 13:01:47 +0100 From: Christer Holmberg To: Ben Campbell , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , mmusic Thread-Topic: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's editorial comments Thread-Index: AQHSnLrBauqclGvw5EeBiU2voC55FQ== Date: Tue, 14 Mar 2017 12:01:47 +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.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6FC384EF01BBA64681F09DA2905FC8E1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbFdXffO7eMRBs9vmlrM7zzNbrHj7g42 i6nLH7M4MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBknf99iLzisVtF+6Dl7A+MzuS5G Tg4JAROJvVuvsILYQgLrGCWuN3h1MXIB2YsZJaYfmMDexcjBwSZgIdH9TxskLiIwmVGif1cr E0iDsECERNfLRSwgtohApMS/a6eZIWw9iWerG9lAbBYBVYnpL06B1fMKWEvsWHoNLM4oICbx /dQasDizgLjErSfzmSAOEpBYsuc8M4QtKvHy8T+w40SBZi5/vgYqriTxY8MlFoheA4n35+Yz Q9jWEvf/fGeDsLUlli18zQyxV1Di5MwnLBMYRWYhWTcLSfssJO2zkLTPQtK+gJF1FaNocWpx Um66kbFealFmcnFxfp5eXmrJJkZgxBzc8lt1B+PlN46HGAU4GJV4eD9sPhYhxJpYVlyZe4hR goNZSYR3W9PxCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4 pRoYWdPWp8u811+5Q19HQ02la+GxucxuytvXBEdPO/uIeWnhlrOnI3Uq/yh/ijrQvPJjX6Hg js6a4xter+3vZGXarFsRKFRQsq0r+9vzRLWs/pmcRZt3nen8NXFPyp4w6Sn1Vd9qc7VCV7zR tTwnkpfANkWWgYG16kfZip/bm7Xj7i3k38YXtdBOiaU4I9FQi7moOBEATStWkpQCAAA= Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's editorial comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 12:02:40 -0000 Hi, Editorial Comments: >- Throughout the document, I found it confusing whether a "new" >association means an initial association or a replacement association. >In some places it doesn't matter (and I was happy to see that it really >doesn't matter for much of the normative guidance), but for example 5.4 >talks about replacing an old association even though IIUC the section >talks about the answer to an initial offer. > >If the intent is for new to mean "initial or replacement" in all cases, >then a sentence to that effect early in the document would be helpful. In general, the procedures apply both to initial and replacement. However, in some sentences (e.g, section 5.4) the text explicitly talks about replacing an existing association. I could add the following text to the beginning of section 3.1. =B3In this document, a =B3new DTLS association=B2 between two endpoints ref= ers to either an initial DTLS association (when no DTLS association is currently established between the endpoints) or an DTLS association replacing a previously established DTLS association." >- 3.1, "A new DOTLS association MUST be estlablished ...": Established >by what? (Please consider active voice.) Also, that MUST seems redundant >to the 2119 language in the much more detailed procedure sections that >follow; maybe this should be lower case? I can use lower case. And, I could say =B3must be established between two endpoints=B2. >"The intent to establish a new DTLS association is explicitly signaled >...": Likewise, signaled by what? I could say =B3explicitly signaled with SDP, using the=8A" ---- >- 3.2: Are the 2119 keywords here redundant with those in the more >detailed procedure sections that follow? I can s/MUST/must. >- 3.2, paragraph 2: I don't think the word "explicitly" constrains >anything. Also, s/"... to span ..." / "... from spanning ..." I can remove =B3explicitly=B2 and s/=B3to span=B2/=B3from spanning=B2. ---- >- 4: "a modification of one or more of the following characteristics >MUST be treated as an indication": Treated as an indication by what? >(Please consider active voice when using 2119 keywords.) Indication by the peer. I could re-write the sentence e.g., in the following way: OLD: "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:=B2 NEW: =B3Unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, if an endpoint modifies one or more of the following characteristics in an offer or answer the peer MUST treat it as indication that the endpoint wants to establish a new DTLS association." ---- >- 5.1, paragraph 4: "a new > transport (3-tuple) MUST be allocated by at least one of the end > points so that DTLS packets can be de-multiplexed.": > >That seems redundant with the more detailed procedures that follow. >Please consider it descriptively here, and saving the 2119 words for the >more detailed procedures. I can s/MUST/must. ---- >-6, 2nd paragraph: Can you offer a citation for the deprecation of >aggressive nomination? I guess I could add a reference to 5245bis, because it contains a note which talks about the deprecation. >-- 3rd paragraph: "at least one of the endpoints MUST allocate": I >suspect that's redundant to 2119 language in the detailed procedures. >But if it's not, please restate with specific procedure for the offerer >and answer. It's vague to assign a 2119 MUST to "at least one". I don=B9t think specific procedures is needed in this case, because the tex= t only says that at least one endpoint needs to allocate a new set of candidates. ---- > >-8, first paragraph: "If forking occurs, separate DTLS associations MUST >be established between the caller and each callee.": This seems like a >statement of fact. That is, how could they _not_ establish a separate >association, since I assume you would end up with a unique 5-tuple for >each branch. I could say =B3will be=B2 instead of =B3MUST be=B2. ---- >-9.2, paragraph 5: "The SIP message containing the offer SHOULD be sent >to > the offerer=B9s SIP proxy over an integrity protected channel": > >This seems redundant with a previous statement 2 sentences back. (Yes, >this was in the original text...) I can remove the sentence from the new text. >-- Last paragraph in new text for section 5: Do you intend for "RFCXXXX" >to refer to _this_ document? If so, a note to the RFC editor to that >effect would be helpful. (There are multiple occurrences.) RFCXXXX refers to this document. I will add a note. Regards, Christer From nobody Tue Mar 14 07:46: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 B3A2B131E3F; Tue, 14 Mar 2017 07:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 rFxZEwQCuvFe; Tue, 14 Mar 2017 07:46:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF91131E2A; Tue, 14 Mar 2017 07:46:44 -0700 (PDT) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2EEkcEH033307 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Mar 2017 09:46:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 14 Mar 2017 09:46:38 -0500 Message-ID: <87576B8B-DD3A-4DC6-8A75-265728BF477A@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 14:46:51 -0000 On 14 Mar 2017, at 3:59, Christer Holmberg wrote: > Hi Ben, > > Thanks for your review! Please see inline. > > >> This is my AD Evaluation of draft-ietf-mmusic-dtls-sdp-20. I'd like >> to >> resolve my substantive comments and questions prior to IETF last >> call. >> >> Thanks! >> >> Ben. >> >> --------------------- >> >> Substantive Comments: >> >> - section 4: "If an offer or answer does not >> contain a ¹dtls-id¹ attribute (this could happen if the offerer >> or >> answerer represents an existing implementation that has not been >> updated to support the ¹dtls-id¹ attribute), the offer or answer >> MUST >> be treated as if no ¹dtls-id¹ attribute is included. " >> >> That seems to say that if dtls-id is not included, the offer or >> answer >> must be treated as if it's not included. Since that's tautologically >> true, I suspect you meant to say something more? > > This is related to the first sentence, saying that there is no default > value defined for the attribute. > > I could say ³Hence, if an offer or answer does not containŠ², if it > makes > the text more clear. You would still get a sentence of the form "If not foo, then not foo." Perhaps the predicate clause could be recast as the consequences or (high level) receiver behavior when dtls-id not being present? Does the absence mean that the session is not setup? That the receiver assumes the sender is a legacy implementation? > > ---- > >> -8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision >> a >> scenario where it would make sense to not follow them? > > > I can¹t think of any scenario, so I am happy to use MUST. Okay > > ---- > >> -9.2, new text for section 5, 5th paragraph: >> Since we are touching this section, shouldn't we update the 4474 >> reference to 4474bis, and update the language about what gets signed >> in >> 4474bis? And can we take this opportunity for a MUST level >> requirement >> for some kind of integrity protection of fingerprints, even if not >> 4474/4474bis? (At least when not considering opportunistic crypto >> cases.) > > See my reply to your comment on section 10. Seeing :-) > > ---- > >> -- 4th paragraph from end of new text: >> should "the certificate fingerprint" say "a certificate fingerprint"? >> (Since you can have multiple fingerprints now...) > > Yes. I will fix that. Okay > > ---- > >> -10: >> >> If you accept my suggestion to move from 4474 to 4474bis in the >> updated >> text for 5763, that will create changes that should probably be >> mentioned here. For example, 4474bis signatures cover fewer things >> than >> do 4474 signatures. The hope that 4474bis may be more deployable than >> 4474, and therefore really used, may also be worth a mention here. > > RFC 5763 contains 20+ references to RFC 4474, in a number of different > sections. > > We would have to update all of those sections (at least the reference, > possibly also normative text), because I don¹t think we should mix > 4474 > and 4474bis. In my opinion, that should be done as a separate task. I scanned 5763 for the references to see if we could reasonably say that all references should be updated. But there's some text on the limitations of identity for phone numbers that might become obsolete if we did that. SO I can be convinced to leave that out of scope for this update. But it's still a bit unfortunate :-) Would it make sense for this document to contain a paragraph somewhere mentioning that, since the publication of 5763, RFC4474 is being updated to address some of those issues, and that implementors should at least consider moving to it? The reason I push on this is that I have hopes that 4474bis can enable the dtls-srtp framework to be used in a more secure fashion that typical for now, since we have such limited deployment of 4474. > > > (I will reply to your editorial comments in a separate e-mail) > > Regards, > > Christer From nobody Tue Mar 14 08:29: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 3394D129549; Tue, 14 Mar 2017 08:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 8oN6hhXTZ2S8; Tue, 14 Mar 2017 08:29:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F6F128DF6; Tue, 14 Mar 2017 08:29:28 -0700 (PDT) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2EFTOZ8037975 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Mar 2017 10:29:24 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Christer Holmberg" Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , mmusic Date: Tue, 14 Mar 2017 10:29:23 -0500 Message-ID: <4A0126D3-FF95-4B84-96A5-2DE8B03CFD68@nostrum.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's editorial comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 15:29:29 -0000 Thanks Christer, this all looks good to me. Ben. On 14 Mar 2017, at 7:01, Christer Holmberg wrote: > Hi, > > Editorial Comments: > > >> - Throughout the document, I found it confusing whether a "new" >> association means an initial association or a replacement association. >> In some places it doesn't matter (and I was happy to see that it really >> doesn't matter for much of the normative guidance), but for example 5.4 >> talks about replacing an old association even though IIUC the section >> talks about the answer to an initial offer. >> >> If the intent is for new to mean "initial or replacement" in all cases, >> then a sentence to that effect early in the document would be helpful. > > In general, the procedures apply both to initial and replacement. > > However, in some sentences (e.g, section 5.4) the text explicitly talks > about replacing an existing association. > > I could add the following text to the beginning of section 3.1. > > ³In this document, a ³new DTLS association² between two endpoints refers > to either an initial DTLS association (when no DTLS association is > currently established between the endpoints) or an DTLS association > replacing a previously established DTLS association." > >> - 3.1, "A new DOTLS association MUST be estlablished ...": Established >> by what? (Please consider active voice.) Also, that MUST seems redundant >> to the 2119 language in the much more detailed procedure sections that >> follow; maybe this should be lower case? > > I can use lower case. > > And, I could say ³must be established between two endpoints². > >> "The intent to establish a new DTLS association is explicitly signaled >> ...": Likewise, signaled by what? > > I could say ³explicitly signaled with SDP, using theŠ" > > ---- > >> - 3.2: Are the 2119 keywords here redundant with those in the more >> detailed procedure sections that follow? > > I can s/MUST/must. > >> - 3.2, paragraph 2: I don't think the word "explicitly" constrains >> anything. Also, s/"... to span ..." / "... from spanning ..." > > I can remove ³explicitly² and s/³to span²/³from spanning². > > ---- > >> - 4: "a modification of one or more of the following characteristics >> MUST be treated as an indication": Treated as an indication by what? >> (Please consider active voice when using 2119 keywords.) > > Indication by the peer. > > I could re-write the sentence e.g., in the following way: > > OLD: > > "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:² > > NEW: > > ³Unless there is another mechanism to explicitly indicate that a new DTLS > association is to be established, if an endpoint modifies one or more of > the following characteristics in an offer or answer the peer MUST treat > it as indication that the endpoint wants to establish a new DTLS > association." > > ---- > > >> - 5.1, paragraph 4: "a new >> transport (3-tuple) MUST be allocated by at least one of the end >> points so that DTLS packets can be de-multiplexed.": >> >> That seems redundant with the more detailed procedures that follow. >> Please consider it descriptively here, and saving the 2119 words for the >> more detailed procedures. > > I can s/MUST/must. > > ---- > >> -6, 2nd paragraph: Can you offer a citation for the deprecation of >> aggressive nomination? > > I guess I could add a reference to 5245bis, because it contains a note > which talks about the deprecation. > >> -- 3rd paragraph: "at least one of the endpoints MUST allocate": I >> suspect that's redundant to 2119 language in the detailed procedures. >> But if it's not, please restate with specific procedure for the offerer >> and answer. It's vague to assign a 2119 MUST to "at least one". > > I don¹t think specific procedures is needed in this case, because the text > only says that at least one > endpoint needs to allocate a new set of candidates. > > ---- > >> >> -8, first paragraph: "If forking occurs, separate DTLS associations MUST >> be established between the caller and each callee.": This seems like a >> statement of fact. That is, how could they _not_ establish a separate >> association, since I assume you would end up with a unique 5-tuple for >> each branch. > > I could say ³will be² instead of ³MUST be². > > ---- > >> -9.2, paragraph 5: "The SIP message containing the offer SHOULD be sent >> to >> the offerer¹s SIP proxy over an integrity protected channel": >> >> This seems redundant with a previous statement 2 sentences back. (Yes, >> this was in the original text...) > > I can remove the sentence from the new text. > >> -- Last paragraph in new text for section 5: Do you intend for "RFCXXXX" >> to refer to _this_ document? If so, a note to the RFC editor to that >> effect would be helpful. (There are multiple occurrences.) > > RFCXXXX refers to this document. I will add a note. > > > Regards, > > Christer From nobody Tue Mar 14 13:08: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 D372B1314A1; Tue, 14 Mar 2017 13:08:01 -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 kG5_Oiz-92d1; Tue, 14 Mar 2017 13:08:00 -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 6994A13149D; Tue, 14 Mar 2017 13:08:00 -0700 (PDT) X-AuditID: c1b4fb30-e63ff70000007738-c0-58c84d9e03d3 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id AA.C9.30520.E9D48C85; Tue, 14 Mar 2017 21:07:58 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 21:07:58 +0100 From: Christer Holmberg To: Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , mmusic Thread-Topic: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments Thread-Index: AQHSnKFIZPUXLA+RFUGrIb2KhDlggqGUWYsAgABUfLA= Date: Tue, 14 Mar 2017 20:07:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB0D18D@ESESSMB109.ericsson.se> References: <87576B8B-DD3A-4DC6-8A75-265728BF477A@nostrum.com> In-Reply-To: <87576B8B-DD3A-4DC6-8A75-265728BF477A@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7iu483xMRBiseG1vM7zzNbrHj7g42 i6nLH7M4MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBndt46xFlzTrOh/pNnAeEaji5GT Q0LARGJ772+WLkYuDiGBdYwSWzfvYYJwFjNKbJ61mbmLkYODTcBCovufNkiDiICSxPPmrSwg NrNAscTyb19YQWxhgSiJhY8PMULUREvcOwsRFxGwkmi7dYkdZAyLgKrEmxsuIGFeAV+JXbOm go0REiiQ2HHqGVg5p4C9xKbXr8FsRgExie+n1jBBrBKXuPVkPhPEzQISS/acZ4awRSVePv7H CmErSTQuecIKsopZQFNi/S59iFZFiSndD9kh1gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nHAkaW VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBkXJwy2+DHYwvnzseYhTgYFTi4S1gPREhxJpY VlyZe4hRgoNZSYT3tA9QiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalF MFkmDk6pBkauJRKTV9r9dvX98fXSa3Wv4EfLPKqEEuImXAj2NvdvvjBJonPq+a5nzLl75s/f f9vpdMpL7YTE92luRpqP2OTPL9/GdPc3lx2DHvcy77qfKj0NMdYcfRujjbXlG9h25dsHTnv2 uNXe/dnORx1enJssf9aWLyvav/esqcAhl79hgUuuOpRZX1BiKc5INNRiLipOBAD25FThkAIA AA== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments 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, 14 Mar 2017 20:08:02 -0000 SGksDQoNClN1YnN0YW50aXZlIENvbW1lbnRzOg0KDQo+Pj4gLSBzZWN0aW9uIDQ6ICJJZiBhbiBv ZmZlciBvciBhbnN3ZXIgZG9lcyBub3QNCj4+PiAgICBjb250YWluIGEgwrlkdGxzLWlkwrkgYXR0 cmlidXRlICh0aGlzIGNvdWxkIGhhcHBlbiBpZiB0aGUgb2ZmZXJlciBvcg0KPj4+ICAgIGFuc3dl cmVyIHJlcHJlc2VudHMgYW4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb24gdGhhdCBoYXMgbm90IGJl ZW4NCj4+PiAgICB1cGRhdGVkIHRvIHN1cHBvcnQgdGhlIMK5ZHRscy1pZMK5IGF0dHJpYnV0ZSks IHRoZSBvZmZlciBvciBhbnN3ZXIgDQo+Pj4gICAgTVVTVCBiZSB0cmVhdGVkIGFzIGlmIG5vIMK5 ZHRscy1pZMK5IGF0dHJpYnV0ZSBpcyBpbmNsdWRlZC4gIg0KPj4+DQo+Pj4gVGhhdCBzZWVtcyB0 byBzYXkgdGhhdCBpZiBkdGxzLWlkIGlzIG5vdCBpbmNsdWRlZCwgdGhlIG9mZmVyIG9yIA0KPj4+ IGFuc3dlciBtdXN0IGJlIHRyZWF0ZWQgYXMgaWYgaXQncyBub3QgaW5jbHVkZWQuIFNpbmNlIHRo YXQncyANCj4+PiB0YXV0b2xvZ2ljYWxseSB0cnVlLCBJIHN1c3BlY3QgeW91IG1lYW50IHRvIHNh eSBzb21ldGhpbmcgbW9yZT8NCj4+DQo+PiBUaGlzIGlzIHJlbGF0ZWQgdG8gdGhlIGZpcnN0IHNl bnRlbmNlLCBzYXlpbmcgdGhhdCB0aGVyZSBpcyBubyBkZWZhdWx0IA0KPj4gdmFsdWUgZGVmaW5l ZCBmb3IgdGhlIGF0dHJpYnV0ZS4NCj4+DQo+PiBJIGNvdWxkIHNheSAiSGVuY2UsIGlmIGFuIG9m ZmVyIG9yIGFuc3dlciBkb2VzIG5vdCBjb250YWluIiwgaWYgaXQgDQo+PiBtYWtlcyB0aGUgdGV4 dCBtb3JlIGNsZWFyLg0KPg0KPiBZb3Ugd291bGQgc3RpbGwgZ2V0IGEgc2VudGVuY2Ugb2YgdGhl IGZvcm0gIklmIG5vdCBmb28sIHRoZW4gbm90IGZvby4iIA0KPiBQZXJoYXBzIHRoZSBwcmVkaWNh dGUgY2xhdXNlIGNvdWxkIGJlIHJlY2FzdCBhcyB0aGUgY29uc2VxdWVuY2VzIG9yIChoaWdoIGxl dmVsKSByZWNlaXZlciBiZWhhdmlvciANCj4gd2hlbiBkdGxzLWlkIG5vdCBiZWluZyBwcmVzZW50 PyBEb2VzIHRoZSBhYnNlbmNlIG1lYW4gdGhhdCB0aGUgc2Vzc2lvbiBpcyBub3Qgc2V0dXA/IFRo YXQgdGhlIHJlY2VpdmVyIGFzc3VtZXMgDQo+IHRoZSBzZW5kZXIgaXMgYSBsZWdhY3kgaW1wbGVt ZW50YXRpb24/DQoNClRoYXQgdGhlIHJlY2VpdmVyIGFzc3VtZXMgdGhlIHNlbmRlciBpcyBhIGxl Z2FjeSBpbXBsZW1lbnRhdGlvbi4NCg0KTWF5YmUgc29tZXRoaW5nIGxpa2U6DQoNCiAgICJObyBk ZWZhdWx0IHZhbHVlIGlzIGRlZmluZWQgZm9yIHRoZSBTRFAgJ2R0bHMtaWQnIGF0dHJpYnV0ZS4N CiAgIEltcGxlbWVudGF0aW9ucyB0aGF0IHdpc2ggdG8gdXNlIHRoZSBhdHRyaWJ1dGUgTVVTVCBl eHBsaWNpdGx5DQogICBpbmNsdWRlIGl0IGluIFNEUCBvZmZlcnMgYW5kIGFuc3dlcnMuICBJZiBh biBvZmZlciBvciBhbnN3ZXIgZG9lcyBub3QNCiAgIGNvbnRhaW4gYSAnZHRscy1pZCcgYXR0cmli dXRlICh0aGlzIGNvdWxkIGhhcHBlbiBpZiB0aGUgb2ZmZXJlciBvcg0KICAgYW5zd2VyZXIgcmVw cmVzZW50cyBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiB0aGF0IGhhcyBub3QgYmVlbg0KICAg dXBkYXRlZCB0byBzdXBwb3J0IHRoZSAnZHRscy1pZCcgYXR0cmlidXRlKSwgdW5sZXNzIHRoZXJl IGlzDQogICBhbm90aGVyIG1lY2hhbmlzbSB0byBleHBsaWNpdGx5IGluZGljYXRlIHRoYXQgYSBu ZXcgRFRMUyBhc3NvY2lhdGlvbg0KICAgaXMgdG8gYmUgZXN0YWJsaXNoZWQsIGEgbW9kaWZpY2F0 aW9uIG9mIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xsb3dpbmcNCiAgIGNoYXJhY3RlcmlzdGljcyBN VVNUIGJlIHRyZWF0ZWQgYXMgYW4gaW5kaWNhdGlvbiB0aGF0IGFuIGVuZHBvaW50DQogICB3YW50 cyB0byBlc3RhYmxpc2ggYSBuZXcgRFRMUyBhc3NvY2lhdGlvbjoiIA0KDQouLi4NCg0KPj4+IC0x MDoNCj4+Pg0KPj4+IElmIHlvdSBhY2NlcHQgbXkgc3VnZ2VzdGlvbiB0byBtb3ZlIGZyb20gNDQ3 NCB0byA0NDc0YmlzIGluIHRoZSANCj4+PiB1cGRhdGVkIHRleHQgZm9yIDU3NjMsIHRoYXQgd2ls bCBjcmVhdGUgY2hhbmdlcyB0aGF0IHNob3VsZCBwcm9iYWJseSANCj4+PiBiZSBtZW50aW9uZWQg aGVyZS4gRm9yIGV4YW1wbGUsIDQ0NzRiaXMgc2lnbmF0dXJlcyBjb3ZlciBmZXdlciB0aGluZ3Mg DQo+Pj4gdGhhbiBkbyA0NDc0IHNpZ25hdHVyZXMuIFRoZSBob3BlIHRoYXQgNDQ3NGJpcyBtYXkg YmUgbW9yZSBkZXBsb3lhYmxlIA0KPj4+IHRoYW4gNDQ3NCwgYW5kIHRoZXJlZm9yZSByZWFsbHkg dXNlZCwgbWF5IGFsc28gYmUgd29ydGggYSBtZW50aW9uIA0KPj4+IGhlcmUuDQo+Pg0KPj4gUkZD IDU3NjMgY29udGFpbnMgMjArIHJlZmVyZW5jZXMgdG8gUkZDIDQ0NzQsIGluIGEgbnVtYmVyIG9m IGRpZmZlcmVudCANCj4+IHNlY3Rpb25zLg0KPj4NCj4+IFdlIHdvdWxkIGhhdmUgdG8gdXBkYXRl IGFsbCBvZiB0aG9zZSBzZWN0aW9ucyAoYXQgbGVhc3QgdGhlIHJlZmVyZW5jZSwgDQo+PiBwb3Nz aWJseSBhbHNvIG5vcm1hdGl2ZSB0ZXh0KSwgYmVjYXVzZSBJIGRvbsK5dCB0aGluayB3ZSBzaG91 bGQgbWl4DQo+PiA0NDc0IGFuZCA0NDc0YmlzLiBJbiBteSBvcGluaW9uLCB0aGF0IHNob3VsZCBi ZSBkb25lIGFzIGEgc2VwYXJhdGUgdGFzay4NCj4NCj4gSSBzY2FubmVkIDU3NjMgZm9yIHRoZSBy ZWZlcmVuY2VzIHRvIHNlZSBpZiB3ZSBjb3VsZCByZWFzb25hYmx5IHNheSB0aGF0IGFsbCByZWZl cmVuY2VzIHNob3VsZCBiZSB1cGRhdGVkLiANCj4gQnV0IHRoZXJlJ3Mgc29tZSB0ZXh0IG9uIHRo ZSBsaW1pdGF0aW9ucyBvZiBpZGVudGl0eSBmb3IgcGhvbmUgbnVtYmVycyB0aGF0IG1pZ2h0IGJl Y29tZSBvYnNvbGV0ZSBpZiB3ZSBkaWQgdGhhdC4NCj4gU08gSSBjYW4gYmUgY29udmluY2VkIHRv IGxlYXZlIHRoYXQgb3V0IG9mIHNjb3BlIGZvciB0aGlzIHVwZGF0ZS4gQnV0IGl0J3Mgc3RpbGwg YSBiaXQgdW5mb3J0dW5hdGUgOi0pDQo+DQo+IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgZm9yIHRoaXMg ZG9jdW1lbnQgdG8gY29udGFpbiBhIHBhcmFncmFwaCBzb21ld2hlcmUgbWVudGlvbmluZyB0aGF0 LCBzaW5jZSB0aGUgcHVibGljYXRpb24gDQo+IG9mIDU3NjMsIFJGQzQ0NzQgaXMgYmVpbmcgdXBk YXRlZCB0byBhZGRyZXNzIHNvbWUgb2YgdGhvc2UgaXNzdWVzLCBhbmQgdGhhdCBpbXBsZW1lbnRv cnMgc2hvdWxkIGF0IGxlYXN0IGNvbnNpZGVyIA0KPiBtb3ZpbmcgdG8gaXQ/IFRoZSByZWFzb24g SSBwdXNoIG9uIHRoaXMgaXMgdGhhdCBJIGhhdmUgaG9wZXMgdGhhdCA0NDc0YmlzIGNhbiBlbmFi bGUgdGhlIGR0bHMtc3J0cCBmcmFtZXdvcmsgdG8gYmUgDQo+IHVzZWQgaW4gYSBtb3JlIHNlY3Vy ZSBmYXNoaW9uIHRoYXQgdHlwaWNhbCBmb3Igbm93LCBzaW5jZSB3ZSBoYXZlIHN1Y2ggbGltaXRl ZCBkZXBsb3ltZW50IG9mIDQ0NzQuDQoNCiJOT1RFOiBTaW5jZSB0aGUgcHVibGljYXRpb24gb2Yg UkZDIDU3NjMsIFJGQyA0NDc0IGhhcyBiZWVuIG9ic29sZXRlZCBieSBkcmFmdC1pZXRmLXN0aXIt NDQ3NGJpcy4gVGhlIHVwZGF0aW5nIG9mIHRoZSByZWZlcmVuY2VzIChhbmQgdGhlDQphc3NvY2lh dGVkIHByb2NlZHVyZXMpIHdpdGhpbiBSRkMgNTc2MyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIGRvY3VtZW50LiBIb3dldmVyLCBpbXBsZW1lbnRlcnMgb2YgUkZDIDU3NjMgYXBwbGljYXRp b25zIGFyZSANCmVuY291cmFnZWQgdG8gaW1wbGVtZW50IGRyYWZ0LWlldGYtc3Rpci00NDc0Ymlz IGluc3RlYWQgb2YgUkZDIDQ0NzQuIg0KDQpGZWVsIGZyZWUgdG8gbW9kaWZ5LCBpZiB5b3UgZS5n Liwgd2FudCB0byBnaXZlIG1vcmUgYmFja2dyb3VuZCBldGMgYWJvdXQgNDQ3NGJpcy4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Tue Mar 14 13:12: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 D67761298A9; Tue, 14 Mar 2017 13:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 cQzVoDpd6b4E; Tue, 14 Mar 2017 13:12:28 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA961296F7; Tue, 14 Mar 2017 13:12:28 -0700 (PDT) Received: from [10.0.1.51] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2EKCOGQ067602 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Mar 2017 15:12:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.51] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (14D27) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB0D18D@ESESSMB109.ericsson.se> Date: Tue, 14 Mar 2017 15:12:24 -0500 Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , mmusic Content-Transfer-Encoding: quoted-printable Message-Id: References: <87576B8B-DD3A-4DC6-8A75-265728BF477A@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CB0D18D@ESESSMB109.ericsson.se> To: Christer Holmberg Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments 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, 14 Mar 2017 20:12:30 -0000 Both work for me. Thanks! Ben. > On Mar 14, 2017, at 3:07 PM, Christer Holmberg wrote: >=20 > Hi, >=20 > Substantive Comments: >=20 >>>> - section 4: "If an offer or answer does not >>>> contain a =C2=B9dtls-id=C2=B9 attribute (this could happen if the off= erer or >>>> answerer represents an existing implementation that has not been >>>> updated to support the =C2=B9dtls-id=C2=B9 attribute), the offer or a= nswer=20 >>>> MUST be treated as if no =C2=B9dtls-id=C2=B9 attribute is included. "= >>>>=20 >>>> That seems to say that if dtls-id is not included, the offer or=20 >>>> answer must be treated as if it's not included. Since that's=20 >>>> tautologically true, I suspect you meant to say something more? >>>=20 >>> This is related to the first sentence, saying that there is no default=20= >>> value defined for the attribute. >>>=20 >>> I could say "Hence, if an offer or answer does not contain", if it=20 >>> makes the text more clear. >>=20 >> You would still get a sentence of the form "If not foo, then not foo."=20= >> Perhaps the predicate clause could be recast as the consequences or (high= level) receiver behavior=20 >> when dtls-id not being present? Does the absence mean that the session is= not setup? That the receiver assumes=20 >> the sender is a legacy implementation? >=20 > That the receiver assumes the sender is a legacy implementation. >=20 > Maybe something like: >=20 > "No default value is defined for the SDP 'dtls-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 'dtls-id' attribute (this could happen if the offerer or > answerer represents an existing implementation that has not been > updated to support the 'dtls-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:"=20 >=20 > ... >=20 >>>> -10: >>>>=20 >>>> If you accept my suggestion to move from 4474 to 4474bis in the=20 >>>> updated text for 5763, that will create changes that should probably=20= >>>> be mentioned here. For example, 4474bis signatures cover fewer things=20= >>>> than do 4474 signatures. The hope that 4474bis may be more deployable=20= >>>> than 4474, and therefore really used, may also be worth a mention=20 >>>> here. >>>=20 >>> RFC 5763 contains 20+ references to RFC 4474, in a number of different=20= >>> sections. >>>=20 >>> We would have to update all of those sections (at least the reference,=20= >>> possibly also normative text), because I don=C2=B9t think we should mix >>> 4474 and 4474bis. In my opinion, that should be done as a separate task.= >>=20 >> I scanned 5763 for the references to see if we could reasonably say that a= ll references should be updated.=20 >> But there's some text on the limitations of identity for phone numbers th= at might become obsolete if we did that. >> SO I can be convinced to leave that out of scope for this update. But it'= s still a bit unfortunate :-) >>=20 >> Would it make sense for this document to contain a paragraph somewhere me= ntioning that, since the publication=20 >> of 5763, RFC4474 is being updated to address some of those issues, and th= at implementors should at least consider=20 >> moving to it? The reason I push on this is that I have hopes that 4474bis= can enable the dtls-srtp framework to be=20 >> used in a more secure fashion that typical for now, since we have such li= mited deployment of 4474. >=20 > "NOTE: Since the publication of RFC 5763, RFC 4474 has been obsoleted by d= raft-ietf-stir-4474bis. The updating of the references (and the > associated procedures) within RFC 5763 is outside the scope of this docume= nt. However, implementers of RFC 5763 applications are=20 > encouraged to implement draft-ietf-stir-4474bis instead of RFC 4474." >=20 > Feel free to modify, if you e.g., want to give more background etc about 4= 474bis. >=20 > Regards, >=20 > Christer >=20 From nobody Tue Mar 14 14:40: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 68EDD129B4F; Tue, 14 Mar 2017 14:40:07 -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 uQsdRDbIHFAp; Tue, 14 Mar 2017 14:40: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 27662129B4D; Tue, 14 Mar 2017 14:40:04 -0700 (PDT) X-AuditID: c1b4fb25-0b71498000002d78-6c-58c863336e6c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 9B.9B.11640.33368C85; Tue, 14 Mar 2017 22:40:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 22:38:54 +0100 From: Christer Holmberg To: Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , mmusic Thread-Topic: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments Thread-Index: AQHSnKFIZPUXLA+RFUGrIb2KhDlggqGUWYsAgABUfLCAAAaJAIAAKKag Date: Tue, 14 Mar 2017 21:38:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB0D37C@ESESSMB109.ericsson.se> References: <87576B8B-DD3A-4DC6-8A75-265728BF477A@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CB0D18D@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7hK5x8okIg5tr5C3md55mt9hxdweb xdTlj1kcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxvWx+yFLQZVTyYv4O9gfGBQRcj J4eEgInE5GO7WEFsIYF1jBLX5op0MXIB2YsZJU4e3M7UxcjBwSZgIdH9TxukRkRASeJ581YW EJtZoFhi+bcvYL3CAlESCx8fYoSoiZa4dxYiLiLgJjH96DKwOIuAqsTk1/OZQUbyCvhK7Fvt CbH2JaPEnGMaIDangL3EnX+fwcoZBcQkvp9awwSxSlzi1pP5TBAnC0gs2XOeGcIWlXj5+B8r hK0k0bjkCSvIeGYBTYn1u/QhWhUlpnQ/ZAexeQUEJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEj yypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwEg5uOW36g7Gy28cDzEKcDAq8fAWsJ6IEGJN LCuuzD3EKMHBrCTC+5oBKMSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILU IpgsEwenVAPjpGz9YpM/9/rmsn3zOBf2e0LbyfmBWTxM22MuuSxWfKfymucA90qLP59jrleU Xzgr0Ps+cOe3F6VJ1fxzDp1aoX/Q5MmGFXt9Wz6xlNrfbSyS37CoKP6b/w2WjwJb/Ras07vG Kft8acv2VaJr438/fBC8Je+C60yDv9P516S6bNpn5OykpOXircRSnJFoqMVcVJwIAKFsoQWQ AgAA Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments 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, 14 Mar 2017 21:40:07 -0000 SGkgQmVuLA0KDQpJJ3ZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3Qgd2l0aCBhbGwgdGhlIGNoYW5n ZXMgYmFzZWQgb24geW91ciBjb21tZW50cyAoc3Vic3RhbnRpdmUgYW5kIGVkaXRvcmlhbCkuIFBs ZWFzZSB0YWtlIGEgbG9vay4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWR0bHMt c2RwL3B1bGwvMjUNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0gDQpT ZW50OiAxNCBNYXJjaCAyMDE3IDIyOjEyDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC5h bGxAaWV0Zi5vcmc7IG1tdXNpYyA8bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEFEIEV2 YWx1YXRpb24gb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjAgLSBCZW4ncyBzdWJzdGFu dGl2ZSBjb21tZW50cw0KDQpCb3RoIHdvcmsgZm9yIG1lLg0KDQpUaGFua3MhDQpCZW4uDQoNCj4g T24gTWFyIDE0LCAyMDE3LCBhdCAzOjA3IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gU3Vic3RhbnRp dmUgQ29tbWVudHM6DQo+IA0KPj4+PiAtIHNlY3Rpb24gNDogIklmIGFuIG9mZmVyIG9yIGFuc3dl ciBkb2VzIG5vdA0KPj4+PiAgIGNvbnRhaW4gYSDCuWR0bHMtaWTCuSBhdHRyaWJ1dGUgKHRoaXMg Y291bGQgaGFwcGVuIGlmIHRoZSBvZmZlcmVyIG9yDQo+Pj4+ICAgYW5zd2VyZXIgcmVwcmVzZW50 cyBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiB0aGF0IGhhcyBub3QgYmVlbg0KPj4+PiAgIHVw ZGF0ZWQgdG8gc3VwcG9ydCB0aGUgwrlkdGxzLWlkwrkgYXR0cmlidXRlKSwgdGhlIG9mZmVyIG9y IGFuc3dlciANCj4+Pj4gICBNVVNUIGJlIHRyZWF0ZWQgYXMgaWYgbm8gwrlkdGxzLWlkwrkgYXR0 cmlidXRlIGlzIGluY2x1ZGVkLiAiDQo+Pj4+IA0KPj4+PiBUaGF0IHNlZW1zIHRvIHNheSB0aGF0 IGlmIGR0bHMtaWQgaXMgbm90IGluY2x1ZGVkLCB0aGUgb2ZmZXIgb3IgDQo+Pj4+IGFuc3dlciBt dXN0IGJlIHRyZWF0ZWQgYXMgaWYgaXQncyBub3QgaW5jbHVkZWQuIFNpbmNlIHRoYXQncyANCj4+ Pj4gdGF1dG9sb2dpY2FsbHkgdHJ1ZSwgSSBzdXNwZWN0IHlvdSBtZWFudCB0byBzYXkgc29tZXRo aW5nIG1vcmU/DQo+Pj4gDQo+Pj4gVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBmaXJzdCBzZW50ZW5j ZSwgc2F5aW5nIHRoYXQgdGhlcmUgaXMgbm8gDQo+Pj4gZGVmYXVsdCB2YWx1ZSBkZWZpbmVkIGZv ciB0aGUgYXR0cmlidXRlLg0KPj4+IA0KPj4+IEkgY291bGQgc2F5ICJIZW5jZSwgaWYgYW4gb2Zm ZXIgb3IgYW5zd2VyIGRvZXMgbm90IGNvbnRhaW4iLCBpZiBpdCANCj4+PiBtYWtlcyB0aGUgdGV4 dCBtb3JlIGNsZWFyLg0KPj4gDQo+PiBZb3Ugd291bGQgc3RpbGwgZ2V0IGEgc2VudGVuY2Ugb2Yg dGhlIGZvcm0gIklmIG5vdCBmb28sIHRoZW4gbm90IGZvby4iIA0KPj4gUGVyaGFwcyB0aGUgcHJl ZGljYXRlIGNsYXVzZSBjb3VsZCBiZSByZWNhc3QgYXMgdGhlIGNvbnNlcXVlbmNlcyBvciANCj4+ IChoaWdoIGxldmVsKSByZWNlaXZlciBiZWhhdmlvciB3aGVuIGR0bHMtaWQgbm90IGJlaW5nIHBy ZXNlbnQ/IERvZXMgDQo+PiB0aGUgYWJzZW5jZSBtZWFuIHRoYXQgdGhlIHNlc3Npb24gaXMgbm90 IHNldHVwPyBUaGF0IHRoZSByZWNlaXZlciBhc3N1bWVzIHRoZSBzZW5kZXIgaXMgYSBsZWdhY3kg aW1wbGVtZW50YXRpb24/DQo+IA0KPiBUaGF0IHRoZSByZWNlaXZlciBhc3N1bWVzIHRoZSBzZW5k ZXIgaXMgYSBsZWdhY3kgaW1wbGVtZW50YXRpb24uDQo+IA0KPiBNYXliZSBzb21ldGhpbmcgbGlr ZToNCj4gDQo+ICAgIk5vIGRlZmF1bHQgdmFsdWUgaXMgZGVmaW5lZCBmb3IgdGhlIFNEUCAnZHRs cy1pZCcgYXR0cmlidXRlLg0KPiAgIEltcGxlbWVudGF0aW9ucyB0aGF0IHdpc2ggdG8gdXNlIHRo ZSBhdHRyaWJ1dGUgTVVTVCBleHBsaWNpdGx5DQo+ICAgaW5jbHVkZSBpdCBpbiBTRFAgb2ZmZXJz IGFuZCBhbnN3ZXJzLiAgSWYgYW4gb2ZmZXIgb3IgYW5zd2VyIGRvZXMgbm90DQo+ICAgY29udGFp biBhICdkdGxzLWlkJyBhdHRyaWJ1dGUgKHRoaXMgY291bGQgaGFwcGVuIGlmIHRoZSBvZmZlcmVy IG9yDQo+ICAgYW5zd2VyZXIgcmVwcmVzZW50cyBhbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiB0 aGF0IGhhcyBub3QgYmVlbg0KPiAgIHVwZGF0ZWQgdG8gc3VwcG9ydCB0aGUgJ2R0bHMtaWQnIGF0 dHJpYnV0ZSksIHVubGVzcyB0aGVyZSBpcw0KPiAgIGFub3RoZXIgbWVjaGFuaXNtIHRvIGV4cGxp Y2l0bHkgaW5kaWNhdGUgdGhhdCBhIG5ldyBEVExTIGFzc29jaWF0aW9uDQo+ICAgaXMgdG8gYmUg ZXN0YWJsaXNoZWQsIGEgbW9kaWZpY2F0aW9uIG9mIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xsb3dp bmcNCj4gICBjaGFyYWN0ZXJpc3RpY3MgTVVTVCBiZSB0cmVhdGVkIGFzIGFuIGluZGljYXRpb24g dGhhdCBhbiBlbmRwb2ludA0KPiAgIHdhbnRzIHRvIGVzdGFibGlzaCBhIG5ldyBEVExTIGFzc29j aWF0aW9uOiIgDQo+IA0KPiAuLi4NCj4gDQo+Pj4+IC0xMDoNCj4+Pj4gDQo+Pj4+IElmIHlvdSBh Y2NlcHQgbXkgc3VnZ2VzdGlvbiB0byBtb3ZlIGZyb20gNDQ3NCB0byA0NDc0YmlzIGluIHRoZSAN Cj4+Pj4gdXBkYXRlZCB0ZXh0IGZvciA1NzYzLCB0aGF0IHdpbGwgY3JlYXRlIGNoYW5nZXMgdGhh dCBzaG91bGQgDQo+Pj4+IHByb2JhYmx5IGJlIG1lbnRpb25lZCBoZXJlLiBGb3IgZXhhbXBsZSwg NDQ3NGJpcyBzaWduYXR1cmVzIGNvdmVyIA0KPj4+PiBmZXdlciB0aGluZ3MgdGhhbiBkbyA0NDc0 IHNpZ25hdHVyZXMuIFRoZSBob3BlIHRoYXQgNDQ3NGJpcyBtYXkgYmUgDQo+Pj4+IG1vcmUgZGVw bG95YWJsZSB0aGFuIDQ0NzQsIGFuZCB0aGVyZWZvcmUgcmVhbGx5IHVzZWQsIG1heSBhbHNvIGJl IA0KPj4+PiB3b3J0aCBhIG1lbnRpb24gaGVyZS4NCj4+PiANCj4+PiBSRkMgNTc2MyBjb250YWlu cyAyMCsgcmVmZXJlbmNlcyB0byBSRkMgNDQ3NCwgaW4gYSBudW1iZXIgb2YgDQo+Pj4gZGlmZmVy ZW50IHNlY3Rpb25zLg0KPj4+IA0KPj4+IFdlIHdvdWxkIGhhdmUgdG8gdXBkYXRlIGFsbCBvZiB0 aG9zZSBzZWN0aW9ucyAoYXQgbGVhc3QgdGhlIA0KPj4+IHJlZmVyZW5jZSwgcG9zc2libHkgYWxz byBub3JtYXRpdmUgdGV4dCksIGJlY2F1c2UgSSBkb27CuXQgdGhpbmsgd2UgDQo+Pj4gc2hvdWxk IG1peA0KPj4+IDQ0NzQgYW5kIDQ0NzRiaXMuIEluIG15IG9waW5pb24sIHRoYXQgc2hvdWxkIGJl IGRvbmUgYXMgYSBzZXBhcmF0ZSB0YXNrLg0KPj4gDQo+PiBJIHNjYW5uZWQgNTc2MyBmb3IgdGhl IHJlZmVyZW5jZXMgdG8gc2VlIGlmIHdlIGNvdWxkIHJlYXNvbmFibHkgc2F5IHRoYXQgYWxsIHJl ZmVyZW5jZXMgc2hvdWxkIGJlIHVwZGF0ZWQuIA0KPj4gQnV0IHRoZXJlJ3Mgc29tZSB0ZXh0IG9u IHRoZSBsaW1pdGF0aW9ucyBvZiBpZGVudGl0eSBmb3IgcGhvbmUgbnVtYmVycyB0aGF0IG1pZ2h0 IGJlY29tZSBvYnNvbGV0ZSBpZiB3ZSBkaWQgdGhhdC4NCj4+IFNPIEkgY2FuIGJlIGNvbnZpbmNl ZCB0byBsZWF2ZSB0aGF0IG91dCBvZiBzY29wZSBmb3IgdGhpcyB1cGRhdGUuIEJ1dCANCj4+IGl0 J3Mgc3RpbGwgYSBiaXQgdW5mb3J0dW5hdGUgOi0pDQo+PiANCj4+IFdvdWxkIGl0IG1ha2Ugc2Vu c2UgZm9yIHRoaXMgZG9jdW1lbnQgdG8gY29udGFpbiBhIHBhcmFncmFwaCANCj4+IHNvbWV3aGVy ZSBtZW50aW9uaW5nIHRoYXQsIHNpbmNlIHRoZSBwdWJsaWNhdGlvbiBvZiA1NzYzLCBSRkM0NDc0 IGlzIA0KPj4gYmVpbmcgdXBkYXRlZCB0byBhZGRyZXNzIHNvbWUgb2YgdGhvc2UgaXNzdWVzLCBh bmQgdGhhdCBpbXBsZW1lbnRvcnMgDQo+PiBzaG91bGQgYXQgbGVhc3QgY29uc2lkZXIgbW92aW5n IHRvIGl0PyBUaGUgcmVhc29uIEkgcHVzaCBvbiB0aGlzIGlzIHRoYXQgSSBoYXZlIGhvcGVzIHRo YXQgNDQ3NGJpcyBjYW4gZW5hYmxlIHRoZSBkdGxzLXNydHAgZnJhbWV3b3JrIHRvIGJlIHVzZWQg aW4gYSBtb3JlIHNlY3VyZSBmYXNoaW9uIHRoYXQgdHlwaWNhbCBmb3Igbm93LCBzaW5jZSB3ZSBo YXZlIHN1Y2ggbGltaXRlZCBkZXBsb3ltZW50IG9mIDQ0NzQuDQo+IA0KPiAiTk9URTogU2luY2Ug dGhlIHB1YmxpY2F0aW9uIG9mIFJGQyA1NzYzLCBSRkMgNDQ3NCBoYXMgYmVlbiBvYnNvbGV0ZWQg DQo+IGJ5IGRyYWZ0LWlldGYtc3Rpci00NDc0YmlzLiBUaGUgdXBkYXRpbmcgb2YgdGhlIHJlZmVy ZW5jZXMgKGFuZCB0aGUgDQo+IGFzc29jaWF0ZWQgcHJvY2VkdXJlcykgd2l0aGluIFJGQyA1NzYz IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuIEhvd2V2ZXIsIGltcGxlbWVu dGVycyBvZiBSRkMgNTc2MyBhcHBsaWNhdGlvbnMgYXJlIGVuY291cmFnZWQgdG8gaW1wbGVtZW50 IGRyYWZ0LWlldGYtc3Rpci00NDc0YmlzIGluc3RlYWQgb2YgUkZDIDQ0NzQuIg0KPiANCj4gRmVl bCBmcmVlIHRvIG1vZGlmeSwgaWYgeW91IGUuZy4sIHdhbnQgdG8gZ2l2ZSBtb3JlIGJhY2tncm91 bmQgZXRjIGFib3V0IDQ0NzRiaXMuDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4g DQoNCg== From nobody Tue Mar 14 20: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 E684812949F for ; Tue, 14 Mar 2017 20:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 lK_I6uPX4Po6 for ; Tue, 14 Mar 2017 20:49:07 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 D40451293F5 for ; Tue, 14 Mar 2017 20:49:06 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id v127so4029096qkb.2 for ; Tue, 14 Mar 2017 20:49: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=2uqrY9vbUZSODfT65R09dScYx1xMDrnNIJstQDDyUyU=; b=S40hDurpnavyFLV/maWRK4xwA/C/N8jNjYLzx77Xr0QM9h2nuP6JJpf3Cq6zDuRZJL IF3aUloIab0C87gF8qTF62xo9YzY8GtLyizcSGLMy/68Dg2GwkeD0K3YyOiG+C7mhotQ +C3EdqnyY3ji7k/Feq+E5/N/IEbO/FMkkxXaBnl9uM/zTNDPeq7auxdydfDOg7Ltvs0M DzIMv7Fv2M4nrOYXIoI2FJocc8m2Ap8ice1TLyruGGVFAaaP8/0Px4IT0ReIkBKddzTl 2IFN6kkvJvOa41/n6d2bHVsVXfoQlfoDwcEfNh9+1Lf9nY7nrMxfCujEfnRsmTpk4e0F UF3Q== 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=2uqrY9vbUZSODfT65R09dScYx1xMDrnNIJstQDDyUyU=; b=fp7zTmM4rCVLZIxMVEmDpZn9SEfx4TINCphYEGrvdK3WSWoA/Ir0bTjkfaRSSyAWQX hAMILFAX7JEH+8B2E23Ew6D62v9zhpnGZDXpe48tiv301oaV+BpRONqUoFJ1paXe6F86 CMCsgqpOmPHkQyxx38XDl5fMAl2QTFSLNfimgL/sUuhOtPIZpJVl9x9uYYJo+bJfXNBZ RaUQln0KnEv1Mq/Ct9u77DaBgrKXkd6ko2HUgH6NCEv8ErY+nvnxp4z90Gu3QFAoNx2h 20I9w5TfUnswvxLIKxlifZtu8VZDY9uWhtEeJvTq2sfZPY+MqgU/lcSCJe73KActw9xy xheA== X-Gm-Message-State: AFeK/H2XBFjmqjqqIaFI5W9xY4ZWbrbfxSH5ZSMyAt7xqh0lfVDb1byrQbEuGoLJkzLWSD3aEaanYl53mNylWg== X-Received: by 10.55.19.197 with SMTP id 66mr820504qkt.73.1489549746028; Tue, 14 Mar 2017 20:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.163 with HTTP; Tue, 14 Mar 2017 20:49:05 -0700 (PDT) In-Reply-To: References: <148939488127.16827.6722127323469391602@ietfa.amsl.com> From: Suhas Nandakumar Date: Tue, 14 Mar 2017 20:49:05 -0700 Message-ID: To: Roman Shpount Cc: Christer Holmberg , mmusic WG Content-Type: multipart/alternative; boundary=001a113fcf6c7cc7d9054abcd3f8 Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.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, 15 Mar 2017 03:49:10 -0000 --001a113fcf6c7cc7d9054abcd3f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Roman Please see inline Cheers Suhas On Mon, Mar 13, 2017 at 11:38 AM, Roman Shpount wrote: > Hi Suhas, > > One more thing that was discussed with Christer but did not make to > sctp-sdp was what should be specified in session descriptions m=3D line > during the ICE nomination process. Christer correctly pointed out that th= is > belongs to ice-sip-sdp. As it stands right not it is unclear if default > candidates should attempt to match currently selected candidate pair or > continue to send the original default candidate. Trying to match currentl= y > selected pair can be difficult, especially since it can change during the > signaling exchange and you can end up with m=3D line transport mismatch. = My > proposal was: > > Session descriptions sent during the ICE nomination process SHOULD includ= e > all the candidates discovered during the ICE nomination process, ICE > candidates present in the session description that started the ICE > nomination MUST not be removed from the session description and the > default candidate MUST not change until ICE nomination process is > complete. > > > Finally, there was a bunch of calls for defining ICE/ transport tag. > Should I propose the language for this for draft-ietf-mmusic-ice-sip-sdp = or > should it go into the separate draft? > [Suhas] . It would be great if you can propose text to the ice-sip-sdp draft since it needs to clarify on the transport tag and the default candidate related issues that Christer brought out during IETF97. I have the latest XML version pushed to github here https://github.com/suhasHere/ice-drafts/tree/master/ice-sdp Could you provide your proposals as PR here. I am happy to work with you to incorporate them. > > Regards, > > _____________ > Roman Shpount > > On Mon, Mar 13, 2017 at 5:17 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >Thanks Christer. Are you referring to use text from this section: >> https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-23#section-12.2 >> >> Wrong version =E2=80=93 correct section :) >> >> Regards, >> >> Christer >> >> >> On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> Note that some decisions/actions also came out of Seoul. >>> >>> https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00 >>> >>> Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I guess= we can use more >>> or less the same text (authored by Roman) that was added to >>> draft-ietf-mmusic-sctp-sdp. >>> >>> Regards, >>> >>> Christer >>> >>> From: mmusic on behalf of Suhas Nandakumar < >>> suhasietf@gmail.com> >>> Date: Monday 13 March 2017 at 10:56 >>> To: "mmusic@ietf.org" >>> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt >>> >>> Version-12 address most of the review comments from Adam. For the >>> questions that needs more attention from the WG, I have sent individual >>> issues as emails >>> >>> Cheers >>> Suhas >>> >>> On Mon, Mar 13, 2017 at 1:48 AM, 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 >>>> of the IETF. >>>> >>>> Title : Using Interactive Connectivity Establishment >>>> (ICE) with Session Description Protocol (SDP) offer/answer and Session >>>> Initiation Protocol (SIP) >>>> Authors : Marc Petit-Huguenin >>>> Ari Keranen >>>> Suhas Nandakumar >>>> Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt >>>> Pages : 43 >>>> Date : 2017-03-13 >>>> >>>> Abstract: >>>> This document describes how Interactive Connectivity Establishment >>>> (ICE) is used with Session Description Protocol (SDP) offer/answer >>>> and Session Initiation Protocol (SIP). >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ >>>> >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-12 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> 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 >> >> > --001a113fcf6c7cc7d9054abcd3f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Roman

=C2=A0 Please see inline<= /div>

Cheers=
Suhas

=
On Mon, Mar 13, 2017 at 11:38 AM, Roman Shpount = <roman@telurix.com> wrote:
Hi Suhas,

One more = thing that was discussed with Christer but did not make to sctp-sdp was wha= t should be specified in session descriptions m=3D line during the ICE nomi= nation process. Christer correctly pointed out that this belongs to ice-sip= -sdp.=C2=A0As it stands r= ight not it is unclear if default candidates should attempt to match curren= tly selected candidate pair or continue to send the original default candid= ate. Trying to match currently selected pair can be difficult, especially s= ince it can change during the signaling exchange and you can end up with m= =3D line transport mismatch.=C2=A0My proposal was:

Session descripti= ons sent during the ICE nomination process SHOULD include all the=C2=A0candidates= =C2=A0discovered during t= he ICE nomination process, ICE=C2=A0candidates=C2=A0present in the session description that started the IC= E nomination MUST not be removed from the session description and the=C2=A0= default=C2=A0candidate=C2=A0MUST not change until ICE nominati= on process is complete.=C2=A0


Final= ly, there was a bunch of calls for defining ICE/ transport tag. Should I pr= opose the language for this for draft-ietf-mmusic-ice-sip-sdp or should it = go into the separate draft?

[Suhas] .= It would be great if you can propose text to the ice-sip-sdp draft since i= t needs to clarify on the transport tag and the default candidate related i= ssues that Christer brought out during IETF97. I have the latest XML versio= n pushed to github here=C2=A0


Could you= provide your proposals as PR here. I am happy to work with you to incorpor= ate them.


=C2=A0

R= egards,

_____________
Roman Shpount<= /div>

On Mon, Mar 13, 2017 at 5:17 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

>Thanks Christer. Are you referring to use text from th= is section:=C2=A0https://tools.ietf.org/html= /draft-ietf-mmusic-sctp-sdp-23#section-12.2

Wrong version =E2=80=93 correct section :)

Regards,

Christer


On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Note that some decisions/actions also came out of Seoul.


Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I gues= s we can use more or less the same text (authored by Roman) that was added = to draft-ietf-mmusic-sctp-sdp.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Monday 13 March 2017 at 10:56=
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: d= raft-ietf-mmusic-ice-sip-sdp-12.txt

Version-12 address most of the review comments from Adam. = For the questions that needs more attention from the WG, I have sent indivi= dual issues as emails

Cheers
Suhas

On Mon, Mar 13, 2017 at 1:48 AM, <intern= et-drafts@ietf.org> wrote:

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 of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-13

Abstract:
=C2=A0 =C2=A0This document describes how Interactive Connectivity Establish= ment
=C2=A0 =C2=A0(ICE) is used with Session Description Protocol (SDP) offer/an= swer
=C2=A0 =C2=A0and Session Initiation Protocol (SIP).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-12

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


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/

_______________________________________________
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


--001a113fcf6c7cc7d9054abcd3f8-- From nobody Wed Mar 15 04:17: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 11855129BAB for ; Wed, 15 Mar 2017 04:17:34 -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 1diXdUUcvH7B for ; Wed, 15 Mar 2017 04:17:30 -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 31076129B5D for ; Wed, 15 Mar 2017 04:17:30 -0700 (PDT) X-AuditID: c1b4fb30-25b3698000007738-03-58c922c81bf7 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id B5.47.30520.8C229C85; Wed, 15 Mar 2017 12:17:28 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 12:17:26 +0100 From: Christer Holmberg To: Eric Rescorla CC: Paul Kyzivat , Taylor Brandstetter , IETF MMUSIC WG Thread-Topic: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections Thread-Index: AQHSiMV0wsnKqkRmGEuVhuugjvh/xaFtWdeAgAEo62CAAF3NgIAAK2mAgAAwa4CAAA3rAIANq1KA///01ACAGREAAA== Date: Wed, 15 Mar 2017 11:17:26 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4C0045CB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0045FE@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4C0076FE@ESESSMB209.ericsson.se> <66341809-4c3e-2989-5039-a3369c0fa503@alum.mit.edu> <7df97f84-613d-2f5c-2290-aca82621f5ba@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.1.161129 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D4EEEFE619C62christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2J7lO4JpZMRBisuq1hcXvGQ1WLF63Ps FlOXP2axWLHhAKsDi8ff9x+YPBZsKvVYsuQnk8fkx23MASxRXDYpqTmZZalF+nYJXBnHP6xm K2h8wFTxZHtkA2P3bKYuRk4OCQETiV2LbrF0MXJxCAmsY5TYt+EIO4SzmFHiyuvzrF2MHBxs AhYS3f+0QRpEBBQkfv05wQISZhYol9gxQR8kLCwQIjF/SgcjSFhEIFRiy5FKiOosid0rNrCD 2CwCqhLbZy5gAbF5Bawlbl1vYIbYdIhNYuWL22AJToFAiSstD8BuYxQQk/h+ag2YzSwgLnHr yXyomwUkluw5zwxhi0q8fPyPFcQWFdCTWP58DVRcSeLHhktQZyZI7FsZAbFXUOLkzCcsExhF ZyGZOguhahaSKogSA4n35+YzQ9jaEssWvoay9SU2fjnLCGFbS+zetZgNWc0CRo5VjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIGRenDLb4MdjC+fOx5iFOBgVOLhLWA9ESHEmlhWXJl7iFGC g1lJhNdD5mSEEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxS DYysy5d/XtqmPOMa8+75OmcKTXcf57nREyGwIvUcq5vW+x3F64sUk24v0085U8/fbG7+LvDv 8n33Z+/6kXsu6oRnTFrIL4EDF2epTRT4nfvs+Nwz/KvOd730vRGcG/XWuEw57++RMobHe6/O 4nqe3vqzTHPT1N+Ljp3WFrPVuFYcc2jdg9ulhTkeSizFGYmGWsxFxYkA4V9LgdACAAA= Archived-At: Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m= sections 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, 15 Mar 2017 11:17:34 -0000 --_000_D4EEEFE619C62christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Nobody has objected to this, so assuming we are moving forward with this I = am not sure there is anything to discuss in Chicago? Regards, Christer From: Eric Rescorla > Date: Monday 27 February 2017 at 16:32 To: Christer Holmberg > Cc: "pkyzivat@alum.mit.edu" >, Taylor Brandstetter >, "mmusic@ietf.org"= > Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m=3D= sections Yes, I think we do On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmberg > wrote: Hi, Do people think we need to discuss this face-to-face in Chicago? Note that = I have currently NOT requested agenda time for BUNDLE. As far as document changes are concerned, we would AT LEAST need some clari= fication text in BUNDLE and/or draft-mux-attributes. Regards, Christer From: Eric Rescorla > Date: Sunday 19 February 2017 at 00:28 To: "pkyzivat@alum.mit.edu" > Cc: Christer Holmberg >, Taylor Brandstetter >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m=3D= sections On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat > wrote: On 2/18/17 1:45 PM, Eric Rescorla wrote: On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat >> wrote: On 2/18/17 4:35 AM, Christer Holmberg wrote: Hi, I invite anyone who has a suggestion on text that needs to be modified/added/removed to provide a pull request (or send text to the list) to do so; in draft-bundle, draft-mux-attributes, and/or any other specification... IMO it doesn't make sense to put attributes on one bundled m-line that only apply to some other bundled m-line - current or future. Why? The whole principle is that they are supposed to span all the m=3D lin= es. They are supposed to span all the m-lines in the bundle that it is meaningf= ul for them to be used with. Yes, and so it doesn't matter which one they are attached to. The closest thing we currently have to this situation is session-level attr= ibutes. Some of those are defined as valid at both session and media level,= and that the value at session level is a default for media level. These in= some sense need to be evaluated in the context of every m-line, even the o= nes where they aren't defined. But we have no standard rule for these. Every attribute needs to say if it = is defined at session level and if that should be treated as a default for = a value at media level. And in the process it is specifying (at least impli= citly) which m-lines it applies to. In principle this could also be done for all the attributes that are to be = identical in bundles. But that means making all the changes to do that, and= maintain it in the future. Huh? We already have a document that analyzes every single attribute and te= lls you how it is to be handled (https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-att= ributes-16) and tells you how to hoist stuff from one m=3D line to all of them. And we're a= lready handling it that way if the m=3D line associated with the bundle tag is a media sect= ion. The only difference is how it's handled if it's a data section. -Ekr As an alternative, how about picking the first tag in the bundle attribute that identifies an m-line of an appropriate type to carry the attribute? Seems much more complicated to implement and specify. To conserve e-mails, responding to Christer as well here: I don't think we need to update any of the relevant RFCs (other than potentially putting them in some useless Updates: line at the top of the doc). The idea here is that BUNDLE overrides them for cases where it applies. Again, maybe it is possible to craft some words that clearly and precisely = state how this is to work, in a general way without taking it one attribute= at a time. But I want to see them. Then we can discuss whether that is simpler than what I suggested above. Thanks, Paul -Ekr Thanks, Paul Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu >] Sent: 17 February 2017 18:51 To: Taylor Brandstetter >> Cc: Christer Holmberg >>; IETF MMUSIC WG >> Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP attributes in non-media m=3D sections On 2/16/17 9:27 PM, Taylor Brandstetter wrote: So, to make this work I think it will be necessary to ammend the definitions of the particular attributes to specify this usage. And then future new attributes that pertain to RTP would also need to address this. sdp-mux-attributes already amends the definitions of these attributes, such that a TRANSPORT attribute in m=3D section "A" can be used for media described by m=3D section "B". So, I don't see why it couldn't go a step further, and explicitly allow TRANSPORT and IDENTICAL category attributes to appear in m=3D sections with proto values not normally used with those attributes. I will reserve judgement until I see specific text. Thanks, Paul On Thu, Feb 16, 2017 at 3:50 PM, Paul Kyzivat > >>> = wrote: On 2/16/17 12:10 PM, Christer Holmberg wrote: Hi Paul, I assume you have an opinion on this :) The suggestion is to allow RTP-specific parameters (SDP rtcp-mux attributes etc) in non-RTP m=3D lines (e.g., data channel). This is a nasty issue. The problem with allowing this is: what do these parameters *mean* when so attached? And where do I look to find out? I'm not certain if they are currently permitted or not. AFAIK there is no *general* mechanism for specifying with which proto values a particular attribute may be used. I haven't studied the definitions of the "RTP-related" attributes to see if they make a specific statement about this. My guess is that they don't, but that they only define the meaning in the context of an RTP session. If that is so, perhaps the rule that unknown attributes are to be ignored should apply to those attributes when used with a non-RTP media section. But if that rule were to apply, then we would expect that with O/A the rules for how these attributes in an offer affect what goes in the answer would not apply. I guess that won't be sufficient here. So, to make this work I think it will be necessary to ammend the definitions of the particular attributes to specify this usage. And then future new attributes that pertain to RTP would also need to address this. IMO this is a can of worms. So my opinion is that these should *not* be used with non-RTP m-lines, with or without bundle. Note that data channel is a special case. While we have agreed not to consider it for now, it is possible, in principle, to run RTP over a data channel. If that were defined then these attributes would also be needed. But then they would not be used as media-level attributes. Instead, they would be dcsa attributes. Thanks, Paul *From:*mmusic [mailto:mmusic-bounces@ietf.org = > = >>] *On Behalf Of *Christer Holmberg *Sent:* 16 February 2017 19:07 *To:* Eric Rescorla > >>>; mmusic WG > >>> *Subject:* Re: [MMUSIC] Issue #27: Allow RTP attributes in non-media m=3D sections Hi, * * *>*See: https://github.com/cdh4u/draft-sdp-bundle/issues/27 > https://github.com/rtcweb-wg/jsep/issues/528 > The basic issue is that it's possible to have a situation where you have both media and data m=3D sections but the BUNDLE tag is associated with the data m=3D section and now you need to put the TRANSPORT = and IDENTICAL attributes somewhere. The JSEP editors discussed this and came to the conclusion that it should go with the BUNDLE tag (i.e., in the data m=3D section) and that BUNDLE should forbid this, but it requires a change to BUNDLE. Did you mean to say that BUNDLE should NOT forbid this? Based on your GitHub discussion, my understanding is that you want to allow to include RTP-specific parameters (=91rtcp-mux=92, =91rtcp=92, =91rtcp-mux-only=92 attributes etc) in the data m=3D se= ction. To repeat what I said on GitHub: This has been discussed in the past, and the outcome has been to now allow RTP-specific parameters in non-RTP m=3D sections. A solution would be to simply change the bundle tag when the RTP m=3D sections are added. =85OR, we change the mux category for the RTP-specific parameters. But, that of course means they have to be added to every RTP m=3D section. 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 --_000_D4EEEFE619C62christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <93F3807AA7C2B94DB761A0285DF21E08@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Nobody has objected to this, so assuming we are moving forward with th= is I am not sure there is anything to discuss in Chicago?

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Monday 27 February 2017 at 16= :32
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>, Taylor Brandstetter <deadbeef@google.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] FW: Issue #27= : Allow RTP attributes in non-media m=3D sections

Yes, I think we do

On Mon, Feb 27, 2017 at 5:10 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Do people think we need to discuss this face-to-face in Chicago? Note = that I have currently NOT requested agenda time for BUNDLE.

As far as document changes are concerned, we would AT LEAST need some = clarification text in BUNDLE and/or draft-mux-attributes.

Regards,

Christer

From: Eric Rescorla <ekr@rtfm.com>
Date: Sunday 19 February 2017 at 00= :28
To: "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu= >
Cc: Christer Holmberg <christer.holmb= erg@ericsson.com>, Taylor Brandstetter <deadbeef@google.com>, "mmusic@ietf.org= " <mmusic@= ietf.org>

Subject: Re: [MMUSIC] FW: Issue #27= : Allow RTP attributes in non-media m=3D sections



On Sat, Feb 18, 2017 at 1:38 PM, Paul Kyzivat <pkyzivat@alu= m.mit.edu> wrote:
On 2/18/17 1:45 PM, Eric Rescor= la wrote:


On Sat, Feb 18, 2017 at 8:09 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzivat@alum.mit.edu>= > wrote:

    On 2/18/17 4:35 AM, Christer Holmberg wrote:

        Hi,

        I invite anyone who has a suggestion on text th= at needs to be
        modified/added/removed to provide a pull reques= t (or send text
        to the list) to do so; in draft-bundle, draft-m= ux-attributes,
        and/or any other specification...


    IMO it doesn't make sense to put attributes on one bundled m-= line
    that only apply to some other bundled m-line - current or fut= ure.


Why? The whole principle is that they are supposed to span all the m=3D lin= es.

They are supposed to span all the m-lines in the bundle that it is meaningf= ul for them to be used with.

Yes, and so it doesn't matter which one they are attached to.


The closest thing we currently have to this situation is session-level attr= ibutes. Some of those are defined as valid at both session and media level,= and that the value at session level is a default for media level. These in= some sense need to be evaluated in the context of every m-line, even the ones where they aren't defined.
But we have no standard rule for these. Every attribute needs to say if it = is defined at session level and if that should be treated as a default for = a value at media level. And in the process it is specifying (at least impli= citly) which m-lines it applies to.

In principle this could also be done for all the attributes that are to be = identical in bundles. But that means making all the changes to do that, and= maintain it in the future.

Huh? We already have a document that analyzes every single attribute a= nd tells you how it
tells you how to hoist stuff from one m=3D line to all of them. And we= 're already handling
it that way if the m=3D line associated with the bundle tag is a media= section. The only
difference is how it's handled if it's a data section.

-Ekr

    As an alternative, how about picking the first tag in the bun= dle
    attribute that identifies an m-line of an appropriate type to= carry
    the attribute?

Seems much more complicated to implement and specify.

To conserve e-mails, responding to Christer as well here: I don't think
we need to update any of the relevant RFCs (other than potentially
putting them in some
useless Updates: line at the top of the doc). The idea here is that
BUNDLE overrides them for cases where it applies.

Again, maybe it is possible to craft some words that clearly and pre= cisely state how this is to work, in a general way without taking it one at= tribute at a time. But I want to see them.

Then we can discuss whether that is simpler than what I suggested above.
        Thanks,
        Paul

-Ekr


            Thanks,
            Paul


        Regards,

        Christer

        -----Original Message-----
        From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu
        <mailto:pkyzivat@alum.mit.edu>]
        Sent: 17 February 2017 18:51
        To: Taylor Brandstetter <deadbeef@google.com
      &nb= sp; <mailto:dea= dbeef@google.com>>
        Cc: Christer Holmberg <christer.holmberg@ericsson.c= om
        &l= t;mailto:christer.holmberg@ericsson.com>>; IETF MMUSIC WG
        <mmusic@ietf.org <mailto:mmusic@ietf.org>>
        Subject: Re: [MMUSIC] FW: Issue #27: Allow RTP = attributes in
        non-media m=3D sections

        On 2/16/17 9:27 PM, Taylor Brandstetter wrote:<= br>
                So, to make this wo= rk I think it will be necessary to
            ammend the
                definitions of the = particular attributes to specify this
            usage. And
                then future new att= ributes that pertain to RTP would
            also need to
                address this.


            sdp-mux-attributes already amends= the definitions of these
            attributes,
            such that a TRANSPORT attribute i= n m=3D section "A" can be
            used for
            media described by m=3D section &= quot;B". So, I don't see why it
            couldn't go
            a step further, and explicitly al= low TRANSPORT and IDENTICAL
            category
            attributes to appear in m=3D sect= ions with proto values not
            normally
            used with those attributes.


        I will reserve judgement until I see specific t= ext.

                Thanks,
                Paul

            On Thu, Feb 16, 2017 at 3:50 PM, = Paul Kyzivat
            <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>
            <mailto:pkyzivat@alum.mit.edu

            <mailto:pkyzivat@alum.mit.edu>>= > wrote:

                On 2/16/17 12:10 PM= , Christer Holmberg wrote:

                    Hi Pa= ul,

                    I ass= ume you have an opinion on this :)

                    The s= uggestion is to allow RTP-specific parameters
            (SDP rtcp-mux
                    attri= butes etc) in non-RTP m=3D lines (e.g., data
            channel).


                This is a nasty iss= ue.

                The problem with al= lowing this is: what do these
            parameters *mean*
                when so attached? A= nd where do I look to find out?

                I'm not certain if = they are currently permitted or not.
            AFAIK there
                is no *general* mec= hanism for specifying with which
            proto values a
                particular attribut= e may be used. I haven't studied the
            definitions
                of the "RTP-re= lated" attributes to see if they make a
            specific
                statement about thi= s. My guess is that they don't, but
            that they
                only define the mea= ning in the context of an RTP session.

                If that is so, perh= aps the rule that unknown attributes
            are to be
                ignored should appl= y to those attributes when used with
            a non-RTP
                media section. But = if that rule were to apply, then we
            would expect
                that with O/A the r= ules for how these attributes in an
            offer affect
                what goes in the an= swer would not apply. I guess that
            won't be
                sufficient here.
                So, to make this wo= rk I think it will be necessary to
            ammend the
                definitions of the = particular attributes to specify this
            usage. And
                then future new att= ributes that pertain to RTP would
            also need to
                address this.

                IMO this is a can o= f worms. So my opinion is that these
            should *not*
                be used with non-RT= P m-lines, with or without bundle.

                Note that data chan= nel is a special case. While we have
            agreed not
                to consider it for = now, it is possible, in principle, to
            run RTP
                over a data channel= . If that were defined then these
            attributes
                would also be neede= d. But then they would not be used as
            media-level
                attributes. Instead= , they would be dcsa attributes.

                     = ;   Thanks,
                     = ;   Paul

                    *From= :*mmusic [mailto:mmusic-bounces@ietf.org
            <mailto:mmusic-bounces@ietf.org>=
                    <m= ailto:mmusic-b= ounces@ietf.org
            <mailto:mmusic-bounces@ietf.org>= >] *On Behalf Of *Christer
                    Holmb= erg
                    *Sent= :* 16 February 2017 19:07
                    *To:*= Eric Rescorla <ekr@rt= fm.com
            <mailto:ekr@rtfm.com> <mailto:ekr@rtfm.com
            <mailto:ekr@rtfm.com>>>; mmusic
                    WG &l= t;mmusic@ietf.org = <mailto:mmusic@ietf= .org>
            <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>&= gt;

                    *Subj= ect:* Re: [MMUSIC] Issue #27: Allow RTP
            attributes in
                    non-m= edia m=3D
                    secti= ons



                    Hi,
                    * *
                    *>= *See:


            https://github.com/cdh4u/draft-sdp-bundle/issues/27
            <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>

            <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27
            <htt= ps://github.com/cdh4u/draft-sdp-bundle/issues/27>>


                     = ;   https://github.com/rtcweb-wg/jsep/issues/528
            <https://gi= thub.com/rtcweb-wg/jsep/issues/528>
                     = ;   <https://github.com/rtcweb-wg/jsep/is= sues/528
            <https://gi= thub.com/rtcweb-wg/jsep/issues/528>>




                     = ;   The basic issue is that it's possible to have a
            situation
                     = ;   where you

                    have = both

                     = ;   media and data m=3D sections but the BUNDLE tag is
            associated
                     = ;   with the data


                     = ;   m=3D section and now you need to put the TRANSPORT and
            IDENTICAL


                     = ;   attributes somewhere. The JSEP editors discussed
            this and
                     = ;   came to the


                     = ;   conclusion that it should go with the BUNDLE tag
            (i.e., in
                     = ;   the data m=3D

                    secti= on)

                     = ;   and that BUNDLE should forbid this, but it
            requires a change
                     = ;   to BUNDLE.




                    Did y= ou mean to say that BUNDLE should NOT forbid this?



                    Based= on your GitHub discussion, my understanding is
            that you
                    want = to
                    allow= to include RTP-specific parameters
            (=91rtcp-mux=92, =91rtcp=92,
                    =91rt= cp-mux-only=92 attributes etc) in the data m=3D section.



                    To re= peat what I said on GitHub:



                    This = has been discussed in the past, and the outcome
            has been to now
                    allow= RTP-specific parameters in non-RTP m=3D sections.



                    A sol= ution would be to simply change the bundle tag
            when the RTP m=3D
                    secti= ons are added.



                    =85OR= , we change the mux category for the RTP-specific
            parameters.
                    But,<= br>                     that = of course means they have to be added to every
            RTP m=3D section.



                    Regar= ds,



                    Chris= ter


                ___________________= ____________________________
                mmusic mailing list=
                mmusic@ietf.org <mailto:mmusic@ietf.org>
            <mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>>
                https://www.ietf.org/mailman/listinfo/mmusic
            <https://ww= w.ietf.org/mailman/listinfo/mmusic>
                <https://www.ietf.org/mailman/listinfo/mmusic
            <https://ww= w.ietf.org/mailman/listinfo/mmusic>>




    _______________________________________________
    mmusic mailing list
    mmusic@i= etf.org <mailto:mmusic@ietf.org>
    https://www.ietf.org/mailman/listinfo/mmusic
    <https://www.ietf.org/mailman/list= info/mmusic>





 --_000_D4EEEFE619C62christerholmbergericssoncom_-- From nobody Wed Mar 15 05:44: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 221FC131472 for ; Wed, 15 Mar 2017 05:44:36 -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 5fi9tXWIabdI for ; Wed, 15 Mar 2017 05:44:33 -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 9C608131471 for ; Wed, 15 Mar 2017 05:44:32 -0700 (PDT) X-AuditID: c1b4fb2d-eebff70000006193-54-58c9372eb6dd Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id D1.58.24979.E2739C85; Wed, 15 Mar 2017 13:44:30 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Wed, 15 Mar 2017 13:44:45 +0100 From: Christer Holmberg To: Jonathan Lennox CC: Eric Rescorla , Bernard Aboba , Flemming Andreasen , Harald Alvestrand , mmusic Thread-Topic: [MMUSIC] Handling of unverified data and media Thread-Index: AQHSmfBaeuX9ya5EIEOzUwYnxet2SaGOsIkAgAABT4CAAA4wAIAA+MdggAO42wD//9++UIAAXakAgAJCX4A= Date: Wed, 15 Mar 2017 12:44:29 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@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.1.161129 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D4EF043019C8Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUyM2K7t66e+ckIgx3rzS027PvPbLHi9Tl2 i/cXdC1O3DjNbLF/8Xlmi6nLH7M4sHlM+b2R1WPnrLvsHgs2lXosWfKTyWPy4zZmj7Znd9gD 2KK4bFJSczLLUov07RK4MuZNnsJccOgaU8XyUx/YGhhXLWPqYuTgkBAwkWh7GtHFyMUhJLCO UeLhk3tsEM5iRokJ306zgBSxCVhIdP/T7mLk5BAR0JC4+OwDWA2zwBZGiYYlTUwgCWEBa4mj v36wgdSLCNhIrPxVC1GfJLG75QcriM0ioCrxqqsTrJwXqPze6iYWiF0LWSV+HW8GS3AK2ErM vrwBzGYUEJP4fmoNmM0sIC5x68l8MFtCQEBiyZ7zzBC2qMTLx//AFogK6Eksf76GGeIxJYlp W9MgWhMkbjy9zgyxV1Di5MwnLBMYRWchmToLSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45 ywhhW0ssfzeBEVnNAkaOVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBUX1wy2/dHYyrXzse YhTgYFTi4S1gPREhxJpYVlyZe4hRgoNZSYT3NQNQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/Z yvvhQgLpiSWp2ampBalFMFkmDk6pBkaD4EA/xtdpTm99v5r3HEqqWGPqp6+YUbPzQ6+MdEfj z5fF6zk2ntLoMvQTTJ3mcKTUw/hxStXpqlUnOzYlcu5/4ffjwqL0SZmXNZWOLbm502Kv/uKD xi/UdGftk83/kB8oaRZz4LHcwcY7XLx/Pnq+PvDC2frRis+r7Ty/nNat7LyrkHaptUqJpTgj 0VCLuag4EQCSd+935gIAAA== Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 15 Mar 2017 12:44:36 -0000 --_000_D4EF043019C8Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, =85 >I=92m not sure what =93implementation means=94 you=92re thinking of, thoug= h. Avoiding sending media/DTLS until you receive an incoming connectivity = check? Something like that. Regards, Christer From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: 13 March 2017 20:37 To: Christer Holmberg > Cc: Eric Rescorla >; Bernard Aboba >; Flemming Andreasen >; Harald Alvestrand >; mmusic > Subject: Re: [MMUSIC] Handling of unverified data and media On Mar 11, 2017, at 9:52 AM, Christer Holmberg > wrote: Hi, Is this a theoretical issue? At least if you use ICE, you are going to receive the answer before you rec= eive any media, as you are going to do the connectivity checks etc. No, even with ICE it=92s possible for media or the DTLS handshake to outrac= e the answer. This is because ICE offering endpoints respond to connectivity checks befor= e they receive an answer. When the answerer receives this successful conne= ctivity check response, it puts the relevant pair in the Valid list, and th= en (if it has the active role, as recommended) can legitimately initiate DT= LS on this pair. If two ICE endpoints have a short RTT and clear connectivity between them, = but a long RTT to their signaling server, this can happen quite easily. Also, in reality some implementations will not accept content before the an= swer arrives =96 no matter if DTLS is used or not =96 so the best thing is = to, once the answer has been sent, just wait for a while before sending any= content. Fortunately, DTLS has retransmissions, so this shouldn=92t cause failure, j= ust a brief setup delay. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla Sent: 11 March 2017 02:57 To: Bernard Aboba > Cc: Flemming Andreasen >; hta= @google.com; mmusic WG > Subject: Re: [MMUSIC] Handling of unverified data and media Sorry, no, I was just talking about what might or might not be safe.... The= doc text is a different question. -Ekr On Fri, Mar 10, 2017 at 4:05 PM, Bernard Aboba > wrote: EKR said: "I haven't spent too much time on it, but it seems like it ought to be safe= to hold anything you receive prior to getting the fingerprint. It might be better, = as MT suggests, to discard the datachannel data, but I'm not sure why it would be necessary." [BA] So you are saying that the MUST NOT allows the browser to buffer data/= media but not to pass it to the application (in the case of the data channe= l) or to play it out? On Fri, Mar 10, 2017 at 4:01 PM, Eric Rescorla > wrote: I haven't spent too much time on it, but it seems like it ought to be safe = to hold anything you receive prior to getting the fingerprint. It might be better, = as MT suggests, to discard the datachannel data, but I'm not sure why it would be necessary. -Ekr On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount > wrote: My assumption always was that data is received, decoded and discarded until= fingerprint is received and verified. This way DTLS handshake completes, k= ey frames are decoded, but user is nor presented with any unverified media. Regards, _____________ Roman Shpount On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson > wrote: I think that the data channel question is easy, anything other than a "no" is not acceptable. Data in that form enters the security boundary for an origin and it doesn't make any sense to risk attack there. (It's also likely unnecessary, if a half a round trip of signaling is slower than 5 round trips on the media path, then something is messed up.) I'm in two minds about the media part. For media, you could also reasonably make the same origin-purity argument. I'm inclined to say that. But we CAN isolate media from the origin (and we definitely should if we allow this). So, the media that arrives had to comply with your offer. The DTLS handshake also has to complete, which tells the receiver whether the media needs to be confidential or not (at which point you can disable this feature). It's also possible that a receiver can require that an ICE connectivity check was made (though this is inbound only, and I'm unclear on whether having received an inbound check would normally prevent the receiver from accepting a packet). All told, that's a lot of information about the negotiated session for an attacker to have. The odds of this being an attack would *seem* to be low. On the other hand, we don't assume confidentiality of signaling; the security model assumes that all this information is effectively public and the protection we have against attack is the certificate fingerprint. This would remove that protection, albeit for a short duration. I have an extra question: does anyone plan to implement this? It's non-trivial. I think that I know what I'd need to do in Firefox and it would be quite disruptive. Before committing to do that work (which I will leave to others closer to this to decide), I'd probably want more information on the actual advantage that it provides. On 10 March 2017 at 07:10, Bernard Aboba > wrote: > In the W3C WEBRTC WG, an issue has been submitted relating to playout of > unverified media: > https://github.com/w3c/webrtc-pc/issues/849 > > It has been suggested that if the browser is configured to do so, that > playout be allowed for a limited period (e.g. 5 seconds) prior to > fingerprint verification: > https://github.com/w3c/webrtc-pc/pull/1026 > > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following te= xt, > carried over from RFC 4572: > > Note that when the offer/answer model is being used, it is possible > for a media connection to outrace the answer back to the offerer. > Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' > role, it MUST (as specified in RFC 4145 [7]) begin listening for an > incoming connection as soon as it sends its offer. However, it MUST > NOT assume that the data transmitted over the TLS connection is valid > until it has received a matching fingerprint in an SDP answer. If > the fingerprint, once it arrives, does not match the client's > certificate, the server endpoint MUST terminate the media connection > with a bad_certificate error, as stated in the previous paragraph. > > Given the outstanding issue relating to handling of unverified media, the > Chairs of the W3C WEBRTC WG would like to request clarification from the > IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above paragraph= . > In particular, what is it permitted for an implementation to do with > received data and media prior to verification? For example: > > 1. May data received over the data channel be provided to the > application prior to verification? > a. If the answer to the above is "no", may unverified received d= ata > be delivered by the DTLS transport to SCTP, which may buffer it? > 2. May received media be played out prior to verification? > > Bernard Aboba > On behalf of the W3C WEBRTC WG > > _______________________________________________ > 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 _______________________________________________ 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_D4EF043019C8Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

=85

>I=92m not sure what =93implementation means=94 you=92re thinking o= f, though.  Avoiding sending media/DTLS until you receive an incoming = connectivity check?

Something like that.

Regards,

Christer



 
From: Jonathan Lennox [mailto:jonathan@vidyo.com] 
Sent: 1= 3 March 2017 20:37
To: Chr= ister Holmberg <christer.holmber= g@ericsson.com>
Cc: Eri= c Rescorla <ekr@rtfm.com>; Bernard Aboba <= ;bernard.aboba@gmail.com>; Flemming Andreasen <fandreas@cisco.com&g= t;; Harald Alvestrand <hta@google.com>; mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Handling of unverified data and media<= /span>
 
 
On Mar 11, 2017, at 9:52 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
 
Hi,
 
Is this a theoretical issue?
 
At least if you use ICE, you are going to recei= ve the answer before you receive any media, as you are going to do the conn= ectivity checks etc.
 
No, even with ICE it=92s possible for media or the DTLS handshake to outrac= e the answer.
 
This is because ICE offering endpoints respond to connectivity checks befor= e they receive an answer.  When the answerer receives this successful = connectivity check response, it puts the relevant pair in the Valid list, a= nd then (if it has the active role, as recommended) can legitimately initiate DTLS on this pair.<= /o:p>
 
If two ICE endpoints have a short RTT and clear connectivity between them, = but a long RTT to their signaling server, this can happen quite easily.


Also, in reality some implementations will not = accept content before the answer arrives =96 no matter if DTLS is used or n= ot =96 so the best thing is to, once the answer has been sent, just wait for a while before sending any content.
 
Fortunately, DTLS has retransmissions, so this shouldn=92t cause failure, j= ust a brief setup delay.


 
Regards,
 
Christer
 
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 1= 1 March 2017 02:57
To: Ber= nard Aboba <bernard.aboba@gmail.com>
Cc: Fle= mming Andreasen <fandreas@cisco.com>; hta@google.com; mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Handling of unverified data and media=
 
Sorry, no, I was just talking about what might or might not be safe.... The= doc text is
a different question.
 
-Ekr
 
 
On Fri, Mar 10, 2017 at 4:05 PM, Bernard Aboba <bernard= .aboba@gmail.com> wrote:
EKR said: 
 
"I haven't spent too much= time on it, but it seems like it ought to be safe to hold
anything you receive prior to = getting the fingerprint. It might be better, as MT
suggests, to discard the datac= hannel data, but I'm not sure why it would be<= /div>
necessary."
 
[BA] So you are saying that the MUST NOT allows the browser to buffer data/= media but not to pass it to the application (in the case of the data channe= l) or to play it out?
 
On Fri, Mar 10, 2017 at 4:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I haven't spent too much time on it, but it seems like it ought to be safe = to hold
anything you receive prior to getting the fingerprint. It might be better, = as MT
suggests, to discard the datachannel data, but I'm not sure why it would be=
necessary.
 
-Ekr
 
On Fri, Mar 10, 2017 at 2:47 PM, Roman Shpount <roman@telurix= .com> wrote:
My assumption always was that data is received, decoded and discarded until= fingerprint is received and verified. This way DTLS handshake completes, k= ey frames are decoded, but user is nor presented with any unverified media.=
 
Regards,

_____________
Roman Shpo= unt
 
On Thu, Mar 9, 2017 at 6:58 PM, Martin Thomson <martin= .thomson@gmail.com> wrote:
I think that the data channel question is easy, anything other than a
"no" is not acceptable.  Data in that form enters the securi= ty
boundary for an origin and it doesn't make any sense to risk attack
there.  (It's also likely unnecessary, if a half a round trip of
signaling is slower than 5 round trips on the media path, then
something is messed up.)

I'm in two minds about the media part. For media, you could also
reasonably make the same origin-purity argument.  I'm inclined to say<= br class=3D""> that.  But we CAN isolate media from the origin (and we definitely
should if we allow this).

So, the media that arrives had to comply with your offer.  The DTLS handshake also has to complete, which tells the receiver whether the
media needs to be confidential or not (at which point you can disable
this feature).

It's also possible that a receiver can require that an ICE
connectivity check was made (though this is inbound only, and I'm
unclear on whether having received an inbound check would normally
prevent the receiver from accepting a packet).

All told, that's a lot of information about the negotiated session for
an attacker to have.  The odds of this being an attack would *seem* to=
be low.

On the other hand, we don't assume confidentiality of signaling; the
security model assumes that all this information is effectively public
and the protection we have against attack is the certificate
fingerprint.  This would remove that protection, albeit for a short duration.

I have an extra question: does anyone plan to implement this?  It's non-trivial.  I think that I know what I'd need to do in Firefox and it would be quite disruptive.  Before committing to do that work
(which I will leave to others closer to this to decide), I'd probably
want more information on the actual advantage that it provides.

On 10 March 2017 at 07:10, Bernard Aboba <bernard.aboba= @gmail.com> wrote:
> In the W3C WEBRTC WG, an issue has been submitted relating to playout = of
> unverified media:
> https://github.com/w3c/webrtc-pc/issues/849
>
> It has been suggested that if the browser is configured to do so, that=
> playout be allowed for a limited period (e.g. 5 seconds) prior to
> fingerprint verification:
> https://github.com/w3c/webrtc-pc/pull/1026
>
> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following= text,
> carried over from RFC 4572:
>
>    Note that when the offer/answer model is being used, it i= s possible
>    for a media connection to outrace the answer back to the = offerer.
>    Thus, if the offerer has offered a 'setup:passive' or 'se= tup:actpass'
>    role, it MUST (as specified in RFC 4145 [7]) begin listen= ing for an
>    incoming connection as soon as it sends its offer.  = However, it MUST
>    NOT assume that the data transmitted over the TLS connect= ion is valid
>    until it has received a matching fingerprint in an SDP an= swer.  If
>    the fingerprint, once it arrives, does not match the clie= nt's
>    certificate, the server endpoint MUST terminate the media= connection
>    with a bad_certificate error, as stated in the previous p= aragraph.
>
> Given the outstanding issue relating to handling of unverified media, = the
> Chairs of the W3C WEBRTC WG would like to request clarification from t= he
> IETF MMUSIC WG as to the meaning of the "MUST NOT" in the ab= ove paragraph.
> In particular, what is it permitted for an implementation to do with > received data and media prior to verification? For example:
>
>      1. May data received over the data channel be prov= ided to the
> application prior to verification?
>          a. If the answer to the above is &qu= ot;no", may unverified received data
> be delivered by the DTLS transport to SCTP, which may buffer it?
>      2. May received media be played out prior to verif= ication?
>
> Bernard Aboba
> On behalf of the W3C WEBRTC WG
>
> _______________________________________________
> 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=

 


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

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

 --_000_D4EF043019C8Cchristerholmbergericssoncom_-- From nobody Wed Mar 15 09:11: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 3086C1316CD for ; Wed, 15 Mar 2017 09:11:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 qNaSA1_y9ZPv for ; Wed, 15 Mar 2017 09:11:22 -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 E1C9E1316B7 for ; Wed, 15 Mar 2017 09:11:21 -0700 (PDT) X-AuditID: c1b4fb2d-eebff70000006193-28-58c967a6480d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id FB.C5.24979.6A769C85; Wed, 15 Mar 2017 17:11:20 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 15 Mar 2017 17:11:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=93QNPuK8MVdtBRXUMhsWdxNnAnNsiUeoTrUQGTBQLzA=; b=SEos9fvPabj8jCDtkmQkEfsUvJvJnGZl/U4veFceoFpF/hMrsFy+8IZgyXcXaFry0QXzFtsnKd2ATpMcQI/oa8KOeAe5OE+3hF1l/GVoVncUeFqzKKijRX3TNDz3qaTybi+aDFy1jDCB1BSuiEjP0cUgYosyJRuf0BdvWN9b6So= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Wed, 15 Mar 2017 16:11:16 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0977.010; Wed, 15 Mar 2017 16:11:16 +0000 From: Bo Burman To: "Makaraju, Raju (Nokia - US)" , "mmusic (mmusic@ietf.org)" Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AQHSm5yGz6G1c3++IkS/LRYJALgIgaGSn/owgACyV4CAAsGt4A== Date: Wed, 15 Mar 2017 16:11:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.87] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2577; 7:JRscEwxOZUc6ngnzZghv5k0wLWVoBIiGR6bqVNztH3wNWzBDJR0IGXpGqRVAhLxvAkAhod/AhlXh10CNzdtVVTOqWBQsV0diwwL0gC24PR8CbfBYEs+GY8RgTDaWjjSZ8ORCYye656DpwFvopayCcds54hDgvn3UfzRuCNe/fICaVbK+pYbE55WgDNF6BqOCnFyEHbsoXxR3ask12PbGXctlYOhO19s/a2uPzqN2eA7ZOGzyzbMzLvuYwn2zoHwTFxYzV2/ROL+s2LqM0RIGnK5k6O+Q6qCZDHNiNJhWP2T8KRawfqwd3K/5C8zBKUa9uhbcx+TV3KFHjpiweGNCKg== x-ms-office365-filtering-correlation-id: 91ca1baf-ae58-43b3-3d94-08d46bbde8f0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254022); SRVR:AM5PR0701MB2577; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:AM5PR0701MB2577; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2577; x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(52314003)(377454003)(43784003)(50986999)(25786008)(77096006)(606005)(6436002)(86362001)(6506006)(6246003)(9326002)(93886004)(76176999)(38730400002)(229853002)(6116002)(54356999)(102836003)(790700001)(66066001)(236005)(2906002)(7906003)(5660300001)(3846002)(81166006)(53936002)(122556002)(3280700002)(54896002)(7696004)(74316002)(230783001)(7736002)(9686003)(55016002)(53546007)(33656002)(2950100002)(99286003)(189998001)(3660700001)(2900100001)(8676002)(6306002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2577; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25776CE33B7A7E6DAF3FC6A38D270AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2017 16:11:16.5740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2577 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURzGOe9lexUHp+XcXzOISRSVd8kFKVaQfukiUZlCOvPNiZfZXjOt LxMrcmaosEQxLzHUlpWMSmVJzlScGGIaknnBvGsfsi9pzmzbyfDbj+d5/rfD4WhpI+vDpWXl 8NosVYZC5M5UxrXK/JtSbXFBDRseSkPjDKN8ZZlkoqgYo3GdipkY+0Sdp+Ldj6fwGWm5vDYw Msld3a67lb1RSOWNttiQDs19Q3rkxgEOA52hgXKyFL9EsHFfrUfuDu5D0F/bzDoNBpfQMGQX SKiCgiGz9n9IvzjsConwQahtm3B19cTpYHlhFzt5N46HgZ5qlugJYC/eEhM+Cfq+cQdzjgH7 4d663ClLcBIsmOoo0n+agsYyM+M03HAiNFdMu2oR9oJf/c2urWksh7HZWopcg8H4bpAmLIOl mT+ssxHCJQgM9mLGOQzwPjBuejt1wI9o2JweFpGCM/Bg7b2IZK5Cx5qSoAYWPiaTRDwsvm2m SGkNBVumkn9zfWFzfIQlRikLBdbHDDneByZGihBhX1gc72DJ0hroXuqmStGBqh03VO2wqlyP sQtslbMM0Y9AneWniPBhaKhfobd5oHOG2qnXIbEJyQReEDJTQ0IDeG3aNUHQZAVk8Tlm5Pg+ 1tcb/m3o+cqJLoQ5pPCQ/Lhki5OyqlwhP7MLAUcrPCXWiw5JkqLKv81rNYnamxm80IX2cIxC Ljn6bOqyFKeqcvh0ns/mtdsuxbn56NCdc8dq7q5WJg6ebjCUly8HK8WFs6fYuTfrepu8/kno Q/Nqhaxpvt4w5REdVZS51tL5vfxstNWCI5a9Y41R1cber5M6o9oUMtD+5UNE+Gjy7+QbMcaw pwW9uXFP8/2utwXNe/mVzeRFV8cyXKT1c8EVumhib2DChcnWqvCeBDujYAS1KvgQrRVUfwGQ ilQaOgMAAA== Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 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, 15 Mar 2017 16:11:25 -0000 --_000_AM5PR0701MB25776CE33B7A7E6DAF3FC6A38D270AM5PR0701MB2577_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raju, I should probably have remembered also this in my "unaddressed" list below,= but I put a question to the list to change 4566bis from normative to infor= mative reference (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKe= wDqgHCv1HmURC-I), which seemed acceptable to Paul K, but so far no one else= answered. What is the author's view on this? /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 22:57 To: Bo Burman ; mmusic (mmusic@ietf.org) Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo, > It was a bit unclear if it was some kind of quote from somewhere, which i= s also commonly indicated by such indentation. I suggest just making it exp= licit that it is a note, starting the first line >with "Note: ". Will do. Thanks. BR Raju From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Monday, March 13, 2017 6:30 AM To: Makaraju, Raju (Nokia - US) >; mmusic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Raju, Regarding: 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? It was a bit unclear if it was some kind of quote from somewhere, which is = also commonly indicated by such indentation. I suggest just making it expli= cit that it is a note, starting the first line with "Note: ". /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 02:52 To: Bo Burman >; mmus= ic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo Burman, Christian Groves, Paul Kyzivat, Thank you so much for your time in making this document better, we apprecia= te it. Sorry for the extended delay. I accepted all the comments. Please see my comments inserted below. Thanks again Raju From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: Tuesday, February 28, 2017 10:11 AM To: mmusic (mmusic@ietf.org) > Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-= sdpneg-11 Authors, WG, I think this document is getting ready for publication request. As part of = making the shepherd's write-up, I have the following comments, to be addres= sed in an updated document: Issues: 1) In section 1: add that also BFCP (Binary Floor Control Protocol) i= s used in the same way as MSRP in examples. [Raju] Will add BFCP. 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite length of t= his identifier, which seems inappropriate. I suggest providing a maximum le= ngth, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960)= , in which case 1*5DIGIT should be sufficient. [Raju] Will change as suggested. 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" af= ter "%" when defining hex characters. Change to: quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % [Raju] Will change as suggested. 4) In 5.1.2.1, text below the example makes reference to MSRP subproto= col, but the example does not explicitly include any MSRP. The single examp= le line uses "accept-types", which is admittedly related to MSRP, but I thi= nk this should be clarified to avoid confusion for readers not familiar wit= h MSRP. [Raju] Will change "Example" to "Example (other MSRP related SDP attributes= are omitted for brevity):" 5) In 5.2.2: It is unclear why you differentiate handling of offers an= d answers that contain both "max-retr" and "max-time", mandating to reject = the offer but allowing it in the answer. I think allowing this asymmetry sh= ould either be motivated, or handling should be aligned between offer and a= nswer. [Raju] I think it was thought giving a bit of flexibility to offerer while = receiving answer is probably good but I see your point on aligning both. Wi= ll change text to align both. 6) In section 6: several examples uses IP addresses that are not align= ed with RFC 6890 (10.10.10.x), which must be changed. Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3). [Raju] Will change as suggested. 7) In Appendix A: same IP address issue as above, change from 79.97.21= 5.79 to an address in the allowed range. [Raju] Will change as suggested. Nits: 1) The date line in the document header is one character too long (bey= ond column 72) [Raju] Good catch! Hmmm... not sure how it is getting messed up as the it i= s supposed to be an auto generated line. Anyway, I just checked the new upd= ated draft at https://xml2rfc.tools.ietf.org and output looks good. 2) In section 1: s/In future data channels could/In the future, data c= hannels could/ [Raju] Will change as suggested. 3) In section 3: s/sending and receive data/sending and receiving data= / [Raju] Will change as suggested. 4) At the very end of section 5.1.2.1: s/in the same document, which r= egisters/in the same document that registers/ [Raju] Will change as suggested. 5) In 5.2.4: s/other data channels which are now not included/other da= ta channels that are now not included/ [Raju] Will change as suggested. 6) In 5.2.5: s/channels are expected be closed now/channels are expect= ed to be closed now/ [Raju] Will change as suggested. 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHA= LL use/ [Raju] Will change as suggested. 8) In Appendix A.1: s/either pass to the data channel stack the stream= identifier to assign/either pass the stream identifier to the data channel= stack to assign/ [Raju] Will change as suggested. 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? Comments from others that are not addressed in -11: 1) Christian Groves commented on Jan 20 that the example in Appendix A= should contain an "a=3Ddtls-id:..." attribute as per other examples in the= draft. [Raju] Will add a=3Ddtls-id. 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 sho= uld be changed to: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. [Raju] Will change as suggested. Thanks raju Cheers, /Bo MMUSIC co-chair --_000_AM5PR0701MB25776CE33B7A7E6DAF3FC6A38D270AM5PR0701MB2577_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Raju,

 

I should probably have remembered also this in my &#= 8220;unaddressed” list below, but I put a question to the list to cha= nge 4566bis from normative to informative reference (https://mail= archive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1HmURC-I), which seemed acceptable to Paul K, but so far no one else answered. What i= s the author’s view on this?

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raj= u.makaraju@nokia.com]
Sent: den 13 mars 2017 22:57
To: Bo Burman <bo.burman@ericsson.com>; mmusic (mmusic@ietf.or= g) <mmusic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo,

> It was a bit unclear if it was some kind of quo= te from somewhere, which is also commonly indicated by such indentation. I = suggest just making it explicit that it is a note, starting the first line

>with “Note: ”.

 

Will do. Thanks.

 

BR

Raju

 

From: Bo Burman [mailto:bo.burman@ericsson.com]
Sent: Monday, March 13, 2017 6:30 AM
To: Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com>; mmusic (mmusic@ietf.org) <mmu= sic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Raju,

 

Regarding:

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

It was a bit unclear if it was some kind of quote fr= om somewhere, which is also commonly indicated by such indentation. I sugge= st just making it explicit that it is a note, starting the first line with = “Note: ”.

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com]
Sent: den 13 mars 2017 02:52
To: Bo Burman <bo.burma= n@ericsson.com>; mmusic (mmusic@i= etf.org) <mmusic@ietf.org>=
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo Burman, Christian Groves, Paul Kyzivat,

 

Thank you so much for your time in making this docum= ent better, we appreciate it. Sorry for the extended delay.

I accepted all the comments.

Please see my comments inserted below.

 

Thanks again

Raju

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: Tuesday, February 28, 2017 10:11 AM
To: mmusic (mmusic@ietf.org) = <mmusic@ietf.org>
Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-c= hannel-sdpneg-11

 

Authors, WG,

 

I think this document is getting ready for publicati= on request. As part of making the shepherd’s write-up, I have the fol= lowing comments, to be addressed in an updated document:

 

Issues:

1)      In section 1: add that also BFCP (Binary Floor Cont= rol Protocol)  is used in the same way as MSRP in examples.=

[Raju] Will add BFCP.

2)      In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infi= nite length of this identifier, which seems inappropriate. I suggest provid= ing a maximum length, maybe matching this to the unsigned 16 bit integer in= SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

[Raju] Will change as suggested.<= /o:p>

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect= , missing “x” after “%” when defining hex character= s. Change to:
quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or= %

[Raju] Will change as suggested.<= /o:p>

4)      In 5.1.2.1, text below the example makes reference = to MSRP subprotocol, but the example does not explicitly include any MSRP. = The single example line uses “accept-types”, which is admittedl= y related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

[Raju] Will change “Example” to &#= 8220;Example (other MSRP related SDP attributes are omitted for brevity):&#= 8221;

5)      In 5.2.2: It is unclear why you differentiate handl= ing of offers and answers that contain both “max-retr” and R= 20;max-time”, mandating to reject the offer but allowing it in the an= swer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

[Raju] I think it was thought giving a bit of = flexibility to offerer while receiving answer is probably good but I see yo= ur point on aligning both. Will change text to align both.

6)      In section 6: several examples uses IP addresses th= at are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3).

[Raju] Will change as suggested. =

7)      In Appendix A: same IP address issue as above, chan= ge from 79.97.215.79 to an address in the allowed range.

[Raju] Will change as suggested. =

 

Nits:

1)      The date line in the document header is one charact= er too long (beyond column 72)

[Raju] Good catch! Hmmm… not sure how it= is getting messed up as the it is supposed to be an auto generated line. A= nyway, I just checked the new updated draft at https://xml2rfc.tools.ie= tf.org and output looks good.

2)      In section 1: s/In future data channels could/In th= e future, data channels could/

[Raju] Will change as suggested. =

3)      In section 3: s/sending and receive data/sending an= d receiving data/

[Raju] Will change as suggested. =

4)      At the very end of section 5.1.2.1: s/in the same d= ocument, which registers/in the same document that registers/

[Raju] Will change as suggested. =

5)      In 5.2.4: s/other data channels which are now not i= ncluded/other data channels that are now not included/

[Raju] Will change as suggested.<= /o:p>

6)      In 5.2.5: s/channels are expected be closed now/cha= nnels are expected to be closed now/

[Raju] Will change as suggested.<= /o:p>

7)      In 8.3: s/dcsa usage level only shall use/dcsa usag= e level only SHALL use/

[Raju] Will change as suggested.<= /o:p>

8)      In Appendix A.1: s/either pass to the data channel = stack the stream identifier to assign/either pass the stream identifier to = the data channel stack to assign/

[Raju] Will change as suggested.<= /o:p>

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

Comments from others that are not addressed in -11:<= o:p>

1)      Christian Groves commented on Jan 20 that the examp= le in Appendix A should contain an “a=3Ddtls-id:…” attrib= ute as per other examples in the draft.

[Raju] Will add a= =3Ddtls-id.

2)      Paul Kyzivat commented on Jan 21 that a bullet in s= ection 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and    channel parameters contained in the SDP offer.=

[Raju] Will change as suggested.

 

Thanks

raju

 

Cheers,

/Bo

MMUSIC co-chair

 

--_000_AM5PR0701MB25776CE33B7A7E6DAF3FC6A38D270AM5PR0701MB2577_-- From nobody Wed Mar 15 10:21: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 9E268131739 for ; Wed, 15 Mar 2017 10:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 cUb-G-Js4kvI for ; Wed, 15 Mar 2017 10:20:49 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C37131734 for ; Wed, 15 Mar 2017 10:20:49 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 8A0038460C7B5; Wed, 15 Mar 2017 17:20:44 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id v2FHKlQ8030965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Mar 2017 17:20:48 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id v2FHKlYG020076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Mar 2017 17:20:47 GMT Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.24]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Wed, 15 Mar 2017 13:20:47 -0400 From: "Makaraju, Raju (Nokia - US)" To: Bo Burman , "mmusic (mmusic@ietf.org)" Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AdKR1myZplopSuFrSp2L99aM0eEZvwJvXIowAB62pQAADX77sABg5fcAAAYwgfA= Date: Wed, 15 Mar 2017 17:20:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A178201530DB9BEUS70UWXCHMBA0_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 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, 15 Mar 2017 17:20:53 -0000 --_000_E1FE4C082A89A246A11D7F32A95A178201530DB9BEUS70UWXCHMBA0_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bo, Paul, Since I don't have a strong preference one way or other, I slightly lean to= wards to keeping 4566bis as a normative reference for the mentioned reason = 'use of new template defined by 4566bis'. I assume the impact of this being both must get RFC status simultaneously!? Do you know if 4566bis is close to RFC status? Bo, really appreciate bringing these comments to our attention! Thanks Raju From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Wednesday, March 15, 2017 11:11 AM To: Makaraju, Raju (Nokia - US) ; mmusic (mmusic@i= etf.org) Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Raju, I should probably have remembered also this in my "unaddressed" list below,= but I put a question to the list to change 4566bis from normative to infor= mative reference (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKe= wDqgHCv1HmURC-I), which seemed acceptable to Paul K, but so far no one else= answered. What is the author's view on this? /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 22:57 To: Bo Burman >; mmus= ic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo, > It was a bit unclear if it was some kind of quote from somewhere, which i= s also commonly indicated by such indentation. I suggest just making it exp= licit that it is a note, starting the first line >with "Note: ". Will do. Thanks. BR Raju From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Monday, March 13, 2017 6:30 AM To: Makaraju, Raju (Nokia - US) >; mmusic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Raju, Regarding: 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? It was a bit unclear if it was some kind of quote from somewhere, which is = also commonly indicated by such indentation. I suggest just making it expli= cit that it is a note, starting the first line with "Note: ". /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 02:52 To: Bo Burman >; mmus= ic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo Burman, Christian Groves, Paul Kyzivat, Thank you so much for your time in making this document better, we apprecia= te it. Sorry for the extended delay. I accepted all the comments. Please see my comments inserted below. Thanks again Raju From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: Tuesday, February 28, 2017 10:11 AM To: mmusic (mmusic@ietf.org) > Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-= sdpneg-11 Authors, WG, I think this document is getting ready for publication request. As part of = making the shepherd's write-up, I have the following comments, to be addres= sed in an updated document: Issues: 1) In section 1: add that also BFCP (Binary Floor Control Protocol) i= s used in the same way as MSRP in examples. [Raju] Will add BFCP. 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite length of t= his identifier, which seems inappropriate. I suggest providing a maximum le= ngth, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960)= , in which case 1*5DIGIT should be sufficient. [Raju] Will change as suggested. 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" af= ter "%" when defining hex characters. Change to: quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % [Raju] Will change as suggested. 4) In 5.1.2.1, text below the example makes reference to MSRP subproto= col, but the example does not explicitly include any MSRP. The single examp= le line uses "accept-types", which is admittedly related to MSRP, but I thi= nk this should be clarified to avoid confusion for readers not familiar wit= h MSRP. [Raju] Will change "Example" to "Example (other MSRP related SDP attributes= are omitted for brevity):" 5) In 5.2.2: It is unclear why you differentiate handling of offers an= d answers that contain both "max-retr" and "max-time", mandating to reject = the offer but allowing it in the answer. I think allowing this asymmetry sh= ould either be motivated, or handling should be aligned between offer and a= nswer. [Raju] I think it was thought giving a bit of flexibility to offerer while = receiving answer is probably good but I see your point on aligning both. Wi= ll change text to align both. 6) In section 6: several examples uses IP addresses that are not align= ed with RFC 6890 (10.10.10.x), which must be changed. Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3). [Raju] Will change as suggested. 7) In Appendix A: same IP address issue as above, change from 79.97.21= 5.79 to an address in the allowed range. [Raju] Will change as suggested. Nits: 1) The date line in the document header is one character too long (bey= ond column 72) [Raju] Good catch! Hmmm... not sure how it is getting messed up as the it i= s supposed to be an auto generated line. Anyway, I just checked the new upd= ated draft at https://xml2rfc.tools.ietf.org and output looks good. 2) In section 1: s/In future data channels could/In the future, data c= hannels could/ [Raju] Will change as suggested. 3) In section 3: s/sending and receive data/sending and receiving data= / [Raju] Will change as suggested. 4) At the very end of section 5.1.2.1: s/in the same document, which r= egisters/in the same document that registers/ [Raju] Will change as suggested. 5) In 5.2.4: s/other data channels which are now not included/other da= ta channels that are now not included/ [Raju] Will change as suggested. 6) In 5.2.5: s/channels are expected be closed now/channels are expect= ed to be closed now/ [Raju] Will change as suggested. 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHA= LL use/ [Raju] Will change as suggested. 8) In Appendix A.1: s/either pass to the data channel stack the stream= identifier to assign/either pass the stream identifier to the data channel= stack to assign/ [Raju] Will change as suggested. 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? Comments from others that are not addressed in -11: 1) Christian Groves commented on Jan 20 that the example in Appendix A= should contain an "a=3Ddtls-id:..." attribute as per other examples in the= draft. [Raju] Will add a=3Ddtls-id. 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 sho= uld be changed to: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. [Raju] Will change as suggested. Thanks raju Cheers, /Bo MMUSIC co-chair --_000_E1FE4C082A89A246A11D7F32A95A178201530DB9BEUS70UWXCHMBA0_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bo, Paul,

Since I don’t have a strong preference one way= or other, I slightly lean towards to keeping 4566bis as a normative refere= nce for the mentioned reason ‘use of new template defined by 4566bis&= #8217;.

I assume the impact of this being both must get RFC = status simultaneously!?

Do you know if 4566bis is close to RFC status?<= /o:p>

 

Bo, really appreciate bringing these comments to our= attention!

 

Thanks

Raju

 

From: Bo Burman [mailto:bo.burman@ericsson.co= m]
Sent: Wednesday, March 15, 2017 11:11 AM
To: Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com>; mmu= sic (mmusic@ietf.org) <mmusic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Raju,

 

I should probably have remembered also this in my &#= 8220;unaddressed” list below, but I put a question to the list to cha= nge 4566bis from normative to informative reference (https://mail= archive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1HmURC-I), which seemed acceptable to Paul K, but so far no one else answered. What i= s the author’s view on this?

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com]
Sent: den 13 mars 2017 22:57
To: Bo Burman <bo.burma= n@ericsson.com>; mmusic (mmusic@i= etf.org) <mmusic@ietf.org>=
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo,

> It was a bit unclear if it was some kind of quo= te from somewhere, which is also commonly indicated by such indentation. I = suggest just making it explicit that it is a note, starting the first line

>with “Note: ”.

 

Will do. Thanks.

 

BR

Raju

 

From: Bo Burman [mailto:bo.burman@ericsson.com]
Sent: Monday, March 13, 2017 6:30 AM
To: Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com>; mmusic (mmusic@ietf.org) <mmu= sic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Raju,

 

Regarding:

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

It was a bit unclear if it was some kind of quote fr= om somewhere, which is also commonly indicated by such indentation. I sugge= st just making it explicit that it is a note, starting the first line with = “Note: ”.

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com]
Sent: den 13 mars 2017 02:52
To: Bo Burman <bo.burma= n@ericsson.com>; mmusic (mmusic@i= etf.org) <mmusic@ietf.org>=
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo Burman, Christian Groves, Paul Kyzivat,

 

Thank you so much for your time in making this docum= ent better, we appreciate it. Sorry for the extended delay.

I accepted all the comments.

Please see my comments inserted below.

 

Thanks again

Raju

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: Tuesday, February 28, 2017 10:11 AM
To: mmusic (mmusic@ietf.org) = <mmusic@ietf.org>
Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-c= hannel-sdpneg-11

 

Authors, WG,

 

I think this document is getting ready for publicati= on request. As part of making the shepherd’s write-up, I have the fol= lowing comments, to be addressed in an updated document:

 

Issues:

1)      In section 1: add that also BFCP (Binary Floor Cont= rol Protocol)  is used in the same way as MSRP in examples.=

[Raju] Will add BFCP.

2)      In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infi= nite length of this identifier, which seems inappropriate. I suggest provid= ing a maximum length, maybe matching this to the unsigned 16 bit integer in= SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

[Raju] Will change as suggested.<= /o:p>

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect= , missing “x” after “%” when defining hex character= s. Change to:
quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or= %

[Raju] Will change as suggested.<= /o:p>

4)      In 5.1.2.1, text below the example makes reference = to MSRP subprotocol, but the example does not explicitly include any MSRP. = The single example line uses “accept-types”, which is admittedl= y related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

[Raju] Will change “Example” to &#= 8220;Example (other MSRP related SDP attributes are omitted for brevity):&#= 8221;

5)      In 5.2.2: It is unclear why you differentiate handl= ing of offers and answers that contain both “max-retr” and R= 20;max-time”, mandating to reject the offer but allowing it in the an= swer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

[Raju] I think it was thought giving a bit of = flexibility to offerer while receiving answer is probably good but I see yo= ur point on aligning both. Will change text to align both.

6)      In section 6: several examples uses IP addresses th= at are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3).

[Raju] Will change as suggested. =

7)      In Appendix A: same IP address issue as above, chan= ge from 79.97.215.79 to an address in the allowed range.

[Raju] Will change as suggested. =

 

Nits:

1)      The date line in the document header is one charact= er too long (beyond column 72)

[Raju] Good catch! Hmmm… not sure how it= is getting messed up as the it is supposed to be an auto generated line. A= nyway, I just checked the new updated draft at https://xml2rfc.tools.ie= tf.org and output looks good.

2)      In section 1: s/In future data channels could/In th= e future, data channels could/

[Raju] Will change as suggested. =

3)      In section 3: s/sending and receive data/sending an= d receiving data/

[Raju] Will change as suggested. =

4)      At the very end of section 5.1.2.1: s/in the same d= ocument, which registers/in the same document that registers/

[Raju] Will change as suggested. =

5)      In 5.2.4: s/other data channels which are now not i= ncluded/other data channels that are now not included/

[Raju] Will change as suggested.<= /o:p>

6)      In 5.2.5: s/channels are expected be closed now/cha= nnels are expected to be closed now/

[Raju] Will change as suggested.<= /o:p>

7)      In 8.3: s/dcsa usage level only shall use/dcsa usag= e level only SHALL use/

[Raju] Will change as suggested.<= /o:p>

8)      In Appendix A.1: s/either pass to the data channel = stack the stream identifier to assign/either pass the stream identifier to = the data channel stack to assign/

[Raju] Will change as suggested.<= /o:p>

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

Comments from others that are not addressed in -11:<= o:p>

1)      Christian Groves commented on Jan 20 that the examp= le in Appendix A should contain an “a=3Ddtls-id:…” attrib= ute as per other examples in the draft.

[Raju] Will add a= =3Ddtls-id.

2)      Paul Kyzivat commented on Jan 21 that a bullet in s= ection 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and    channel parameters contained in the SDP offer.=

[Raju] Will change as suggested.

 

Thanks

raju

 

Cheers,

/Bo

MMUSIC co-chair

 

--_000_E1FE4C082A89A246A11D7F32A95A178201530DB9BEUS70UWXCHMBA0_-- From nobody Wed Mar 15 10:47: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 3F09A13175C for ; Wed, 15 Mar 2017 10:47:06 -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 UBHuXAVINoS8 for ; Wed, 15 Mar 2017 10:47:03 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 3367C131756 for ; Wed, 15 Mar 2017 10:47:03 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id g2so12306308pge.3 for ; Wed, 15 Mar 2017 10:47:03 -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=8YHo6qMsF3ArA6PBCqyy3Te73O4zr5GasGhJRcv/OYY=; b=Vzwwh5BxVTiXDWhLcCnlSF1xsynbCzIocmhc2KVyQ6AXJGEH0gSlTa/SbwpFKe/OJl CvjVqc49bBSKiKpklPKFfbi9Xlhk5m1CrQDll6wwhAKMZWz8O/JLXyi/JQOGGGETY6pl 6uhKewK6RETeRCMsNAdEw+869ETxPZVRoc0y6zTtfm5MPBjN6WN2hPvJDMPgiwKY5F0L 3ECptBcf4CHewVbRCbkjB0imh6+TxcABUbwHv+2tJPNSXQubQ1yaK5CYlg7On6/Z1XjA +nPb5Lqlq8v/EfPAI+bJSU4XsnRYdgKX+ycRMA2MywYOY/T2axjisE61RqMirAv1SjNv OVxw== 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=8YHo6qMsF3ArA6PBCqyy3Te73O4zr5GasGhJRcv/OYY=; b=Jtdt6BWAC2vs4104SsBUD2HsmdWZM9JL8YT9eJQaccX3OSPYlO6PoGw5COMtFDD3Uk /zgSXNyER8ABotkbBP7CCL0kk+upuYF0PtA9hZpxY+cNJEMm8VtbmlebO64HGWc7KHyz 4KsMpG4ugBdMwZdI3eu3MXn4qsaUbU/wiBUGgfSok/WnW9I41sUz7f5HrG0gmfp+4OyG gS+/hiM3Oz6f/MwfopvaCBCbA+aXTkS6feGMld8dy2oPeCP9FBHtyXVKChE5J7I8Dbha cOyJ5btT7sRezNlsy9JfDHLb8gpLKRoT4qwV5YfeqaW69CK/49AUix/9Gl8rfZtcGkMo k6gw== X-Gm-Message-State: AFeK/H24Xddmh9fYNsRuSrFHzVDpj026o+0f8Uq06lGD9CiNoaK1X0ECzXq2YZ21u6lsZA== X-Received: by 10.98.214.4 with SMTP id r4mr4930789pfg.185.1489600022366; Wed, 15 Mar 2017 10:47:02 -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 i127sm5576206pfe.15.2017.03.15.10.47.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 10:47:01 -0700 (PDT) Received: by mail-pg0-f54.google.com with SMTP id g2so12305960pge.3 for ; Wed, 15 Mar 2017 10:47:01 -0700 (PDT) X-Received: by 10.99.225.5 with SMTP id z5mr4934150pgh.145.1489600021140; Wed, 15 Mar 2017 10:47:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Wed, 15 Mar 2017 10:47:00 -0700 (PDT) In-Reply-To: References: <148939488127.16827.6722127323469391602@ietfa.amsl.com> From: Roman Shpount Date: Wed, 15 Mar 2017 13:47:00 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Suhas Nandakumar Cc: Christer Holmberg , mmusic WG Content-Type: multipart/alternative; boundary=001a114e93a41e23b5054ac88808 Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.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, 15 Mar 2017 17:47:06 -0000 --001a114e93a41e23b5054ac88808 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Suhas, I will try to provide the default candidate proposals in the pull request. Regards, _____________ Roman Shpount On Tue, Mar 14, 2017 at 11:49 PM, Suhas Nandakumar wrote: > Hello Roman > > Please see inline > > Cheers > Suhas > > On Mon, Mar 13, 2017 at 11:38 AM, Roman Shpount wrote= : > >> Hi Suhas, >> >> One more thing that was discussed with Christer but did not make to >> sctp-sdp was what should be specified in session descriptions m=3D line >> during the ICE nomination process. Christer correctly pointed out that t= his >> belongs to ice-sip-sdp. As it stands right not it is unclear if default >> candidates should attempt to match currently selected candidate pair or >> continue to send the original default candidate. Trying to match current= ly >> selected pair can be difficult, especially since it can change during th= e >> signaling exchange and you can end up with m=3D line transport mismatch.= My >> proposal was: >> >> Session descriptions sent during the ICE nomination process SHOULD >> include all the candidates discovered during the ICE nomination process, >> ICE candidates present in the session description that started the ICE >> nomination MUST not be removed from the session description and the >> default candidate MUST not change until ICE nomination process is >> complete. >> >> >> Finally, there was a bunch of calls for defining ICE/ transport tag. >> Should I propose the language for this for draft-ietf-mmusic-ice-sip-sdp= or >> should it go into the separate draft? >> > > [Suhas] . It would be great if you can propose text to the ice-sip-sdp > draft since it needs to clarify on the transport tag and the default > candidate related issues that Christer brought out during IETF97. I have > the latest XML version pushed to github here > > https://github.com/suhasHere/ice-drafts/tree/master/ice-sdp > > Could you provide your proposals as PR here. I am happy to work with you > to incorporate them. > > > > >> >> Regards, >> >> _____________ >> Roman Shpount >> >> On Mon, Mar 13, 2017 at 5:17 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Hi, >>> >>> >Thanks Christer. Are you referring to use text from this section: >>> https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-23#section-12.2 >>> >>> Wrong version =E2=80=93 correct section :) >>> >>> Regards, >>> >>> Christer >>> >>> >>> On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmberg < >>> christer.holmberg@ericsson.com> wrote: >>> >>>> Hi, >>>> >>>> Note that some decisions/actions also came out of Seoul. >>>> >>>> https://www.ietf.org/proceedings/97/minutes/minutes-97-mmusic-00 >>>> >>>> Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I gues= s we can use more >>>> or less the same text (authored by Roman) that was added to >>>> draft-ietf-mmusic-sctp-sdp. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> From: mmusic on behalf of Suhas Nandakumar < >>>> suhasietf@gmail.com> >>>> Date: Monday 13 March 2017 at 10:56 >>>> To: "mmusic@ietf.org" >>>> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-12.txt >>>> >>>> Version-12 address most of the review comments from Adam. For the >>>> questions that needs more attention from the WG, I have sent individua= l >>>> issues as emails >>>> >>>> Cheers >>>> Suhas >>>> >>>> On Mon, Mar 13, 2017 at 1:48 AM, 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 Contro= l >>>>> of the IETF. >>>>> >>>>> Title : Using Interactive Connectivity Establishmen= t >>>>> (ICE) with Session Description Protocol (SDP) offer/answer and Sessio= n >>>>> Initiation Protocol (SIP) >>>>> Authors : Marc Petit-Huguenin >>>>> Ari Keranen >>>>> Suhas Nandakumar >>>>> Filename : draft-ietf-mmusic-ice-sip-sdp-12.txt >>>>> Pages : 43 >>>>> Date : 2017-03-13 >>>>> >>>>> Abstract: >>>>> This document describes how Interactive Connectivity Establishment >>>>> (ICE) is used with Session Description Protocol (SDP) offer/answer >>>>> and Session Initiation Protocol (SIP). >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-12 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-12 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> > --001a114e93a41e23b5054ac88808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suhas,

I will try to provide the defaul= t candidate proposals in the =C2=A0pull request.

R= egards,

_____________Roman Shpount

On Tue, Mar 14, 2017 at 11:49 PM, Suhas Nand= akumar <suhasietf@gmail.com> wrote:
Hello Roman
=

=C2=A0 Plea= se see inline

Cheers
Suhas

On Mon, Mar 13, 2= 017 at 11:38 AM, Roman Shpount <roman@telurix.com> wrote:
Hi Suha= s,

One more thing that was discussed with Christer but d= id not make to sctp-sdp was what should be specified in session description= s m=3D line during the ICE nomination process. Christer correctly pointed o= ut that this belongs to ice-sip-sdp.=C2=A0As it stands right not it is unclear if default candidates= should attempt to match currently selected candidate pair or continue to s= end the original default candidate. Trying to match currently selected pair= can be difficult, especially since it can change during the signaling exch= ange and you can end up with m=3D line transport mismatch.=C2=A0My p= roposal was:

Session descriptions sent during the ICE nomination process SH= OULD include all the=C2=A0candidates=C2=A0discovered during the ICE nomination proce= ss, ICE=C2=A0candidates=C2=A0present in the session description that started the ICE= nomination MUST not be removed from the session description and the=C2=A0<= /span>default=C2= =A0candidate=C2=A0MUST not change until ICE nomination process is complete.=C2=A0


Finally, there was a bunch of calls for= defining ICE/ transport tag. Should I propose the language for this for dr= aft-ietf-mmusic-ice-sip-sdp or should it go into the separate draft?
<= /blockquote>

[Suhas] . It would be great if you c= an propose text to the ice-sip-sdp draft since it needs to clarify on the t= ransport tag and the default candidate related issues that Christer brought= out during IETF97. I have the latest XML version pushed to github here=C2= =A0


Could you pr= ovide your proposals as PR here. I am happy to work with you to incorporate= them.


=C2= =A0

Regards,

_____________
Roman Shpount

On Mon, Mar 13, 2017 at 5:17 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wr= ote:
Hi,

>Thanks Christer. Are you referring to use text from th= is section:=C2=A0https://tools.ietf.org/html= /draft-ietf-mmusic-sctp-sdp-23#section-12.2

Wrong version =E2=80=93 correct section :)

Regards,

Christer


On Mon, Mar 13, 2017 at 2:06 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Note that some decisions/actions also came out of Seoul.


Regarding the =E2=80=99Transport Switch and O/A=E2=80=99 issue, I gues= s we can use more or less the same text (authored by Roman) that was added = to draft-ietf-mmusic-sctp-sdp.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Suhas Nandakumar <suhasietf@gmail.com>
Date: Monday 13 March 2017 at 10:56=
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: d= raft-ietf-mmusic-ice-sip-sdp-12.txt

Version-12 address most of the review comments from Adam. = For the questions that needs more attention from the WG, I have sent indivi= dual issues as emails

Cheers
Suhas

On Mon, Mar 13, 2017 at 1:48 AM, <intern= et-drafts@ietf.org> wrote:

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 of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ari Keranen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 43
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-03-13

Abstract:
=C2=A0 =C2=A0This document describes how Interactive Connectivity Establish= ment
=C2=A0 =C2=A0(ICE) is used with Session Description Protocol (SDP) offer/an= swer
=C2=A0 =C2=A0and Session Initiation Protocol (SIP).


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-12

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


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/

_______________________________________________
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



--001a114e93a41e23b5054ac88808-- From nobody Wed Mar 15 13:22: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 463801317F9 for ; Wed, 15 Mar 2017 13:22:32 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 jptfuD6YbuV4 for ; Wed, 15 Mar 2017 13:22:30 -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 882DD13181A for ; Wed, 15 Mar 2017 13:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4086; q=dns/txt; s=iport; t=1489609350; x=1490818950; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=7l0rlKDPun2URvmy6huKjnT4F6HhM4olefkSlkEdjrE=; b=QsUW4zKHcI9hvsyHNTESZLe9MFvTCATq+ibKuJMdOAkG8bEJkcJTABAm gMZUZWCpqIAWtIdSN/BE2LHhbAx6O5P0z5uacM585CHv/n3YnDBdvVUba ixA68jsFGSCJ0t+EdAvMRyuxGnnYWwtsuloPgJrAYRicPMtSnVpfQBwtw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAgAEoslY/5xdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhKmCDYIoNkVeNSIJHghAzgmqCDh8BCoUuSgKCdD8YAQIBAQE?= =?us-ascii?q?BAQEBayiFFgEBAQMBASFLCxALBBQnAwICJx8RBg0GAgEBiW8NDq8pgiYrijUBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGgWGToIFgmqHWoJfBZxDjEyFb4F7iFeGU4hGiwE?= =?us-ascii?q?fOIEEOR8VQYQeglUkNYkyAQEB?= X-IronPort-AV: E=Sophos;i="5.36,170,1486425600"; d="scan'208,217";a="223848104" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2017 20:22:29 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2FKMScp008524; Wed, 15 Mar 2017 20:22:29 GMT To: Bernard Aboba References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> Cc: mmusic , "hta@google.com" , stefan hakansson From: Flemming Andreasen Message-ID: Date: Wed, 15 Mar 2017 16:22:28 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5D9786680A4F2F90591EE625" Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 15 Mar 2017 20:22:32 -0000 This is a multi-part message in MIME format. --------------5D9786680A4F2F90591EE625 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ok - I have added a 10-minute slot for now, but based on the mailing list discussion, do you still want to discuss this in the meeting ? Thanks -- Flemming On 3/10/17 7:17 PM, Bernard Aboba wrote: > I would like a short slot (10 minutes?) relating to interpretation of > draft-ietf-mmusic-4572-update with respect to "Unverified data/media". > > > On Fri, Mar 10, 2017 at 6:36 AM, Flemming Andreasen > > wrote: > > Greetings > > The initial draft agenda for the MMUSIC meeting in Chicago has now > been uploaded to: > > https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00 > > > We still have a bit of room on the agenda, so let us know of any > additional agenda requests (before March 15) > > Thanks > > Flemming & Bo > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --------------5D9786680A4F2F90591EE625 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ok - I have added a 10-minute slot for now, but based on the mailing list discussion, do you still want to discuss this in the meeting ?

Thanks

-- Flemming

On 3/10/17 7:17 PM, Bernard Aboba wrote:
I would like a short slot (10 minutes?) relating to interpretation of draft-ietf-mmusic-4572-update with respect to "Unverified data/media". 


On Fri, Mar 10, 2017 at 6:36 AM, Flemming Andreasen <fandreas@cisco.com> wrote:
Greetings

The initial draft agenda for the MMUSIC meeting in Chicago has now been uploaded to:

    https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00

We still have a bit of room on the agenda, so let us know of any additional agenda requests (before March 15)

Thanks

    Flemming & Bo

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


--------------5D9786680A4F2F90591EE625-- From nobody Wed Mar 15 13:35: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 16F9A13183B for ; Wed, 15 Mar 2017 13:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 SCQCwEI1kWT8 for ; Wed, 15 Mar 2017 13:35:34 -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 38F2D131825 for ; Wed, 15 Mar 2017 13:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=772; q=dns/txt; s=iport; t=1489610134; x=1490819734; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=9Mf3k3znhbZ2Kf4cVIZVfvztsA9n/uDqxAVkFM+lAb4=; b=dsq8YNn7EILubLnfZJMMAT6EpOqI2kLp1WN7uDPYJGJ0O86Ny963LP+J j174+y+Dn28+dsp+QRR0ORxZwlfe52FHaX1p/4NJ01kRi2cvtTuGhGmsj vm0dDctxF+GwEdbax/lA72jPP0fJfnkU7D8Fg/2LrKX4S0O7nfY+Ikf+c A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAQBHpclY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhKmCNbZE4H5U8gg4fC4UuSgKCdD8YAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?BAQMBATY2GwsYLicwBg0GAgEBiW8NDrFUimABAQEBAQEBAQEBAQEBAQEBARwFh?= =?us-ascii?q?k6CBQiCYoo5AQScQ5I7ilKGU5NHHziBBDkfFUGGcyQ1iTIBAQE?= X-IronPort-AV: E=Sophos;i="5.36,170,1486425600"; d="scan'208";a="398625548" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2017 20:35:10 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2FKZAt5012337 for ; Wed, 15 Mar 2017 20:35:10 GMT To: mmusic References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> From: Flemming Andreasen Message-ID: <5367d767-4233-2709-3547-1eb6542792b4@cisco.com> Date: Wed, 15 Mar 2017 16:35:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 15 Mar 2017 20:35:36 -0000 The MMUSIC draft agenda has been updated: https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-01 The agenda is full at this point, but let us know if you have any comments. Thanks Flemming & Bo On 3/10/17 9:36 AM, Flemming Andreasen wrote: > Greetings > > The initial draft agenda for the MMUSIC meeting in Chicago has now > been uploaded to: > > https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00 > > We still have a bit of room on the agenda, so let us know of any > additional agenda requests (before March 15) > > Thanks > > Flemming & Bo > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Wed Mar 15 20:37: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 9D367131446 for ; Wed, 15 Mar 2017 20:37:05 -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, 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=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 qrH71PXmQGU5 for ; Wed, 15 Mar 2017 20:37:04 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA00130141 for ; Wed, 15 Mar 2017 20:37:03 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id r45so28351945qte.3 for ; Wed, 15 Mar 2017 20:37:03 -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=mVxrFXWT419/DLjPjcgbIW9kJiEjCT8G0bneegB8AsM=; b=X7L1ciz085y9b0PqK8eQYwvjT0jwgm3iOqWqBdDZEl4xFKiO0niS6zRYJhL+Shu2pe D0144rdntMjHU7tsCaKAt4Om0hP6lg20dHmq3P2feQJtQa7ws10YoDcSH5IqHY2XXL+D fSrorvCcnfdsQZOMBknSvZg8sODNrlPhXDQHsUgQD0rGVoUIdjjBssbCXgPJkkbIw8IX 4C98nj/d5nqYbhhaq2lNZ0ihmMxXEY+CDUZhtWSx65hsQvvH3wuzo1PIJ1socvEfde0U R/gRgSnc4Y+nZ8Dr9lFfTsADDCaZ7NqhL3nOTo6PNJID0d/xO2C35IIxe9mOk189J260 zLWQ== 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=mVxrFXWT419/DLjPjcgbIW9kJiEjCT8G0bneegB8AsM=; b=Kx1KqKPBAR1gjaVdYdSjpsbbN2Pxhsdg+Vf+cC0cQFeCqACK7kWR5GpQCW2Ny4jtIN qajMNoE1P7Fblwnt7NsqcK7JQkbAq2Ed9Q3UJPQZMzBLQqs8/gv6Qbvbfq6DPWb/ldIO 86PBXo5wxES2ZpUwpBmlypjnpdlBItrQ1/3gmbJGEPgJLdv1T8Q5ZOKrF3nHb4jSMRPb 2pusl443FhGeixVijXxmx0F0eYcS7JjAPDfoy4ZuJ4FRGbCicCEiGfJGOJz3vua0FbtJ iFK8+PvxNQcbkFsnxm9MOdCTegaZ3+iXrbTrw9HCzWrJfaUEgI9Uq9NSBxeB6oqT3KJV Qp4w== X-Gm-Message-State: AFeK/H3Orm29zt1FEf+PPb9ocA5+HkFAVoZBHgvv1IZ92XGJFreZwr1DltJ/kdLitWa6YDVf+Exyc3kSh+wGtw== X-Received: by 10.237.34.250 with SMTP id q55mr6403551qtc.144.1489635423208; Wed, 15 Mar 2017 20:37:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Wed, 15 Mar 2017 20:37:02 -0700 (PDT) In-Reply-To: <5367d767-4233-2709-3547-1eb6542792b4@cisco.com> References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> <5367d767-4233-2709-3547-1eb6542792b4@cisco.com> From: Martin Thomson Date: Thu, 16 Mar 2017 14:37:02 +1100 Message-ID: To: Flemming Andreasen Cc: mmusic Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 16 Mar 2017 03:37:06 -0000 On 16 March 2017 at 07:35, Flemming Andreasen wrote: > https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-01 > > The agenda is full at this point, but let us know if you have any comments. My request for agenda time was clearly too heavily cloaked. Can I request that we discuss draft-thomson-avtcore-sdp-uks ? From nobody Thu Mar 16 06:23:03 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 163CB1294E8 for ; Thu, 16 Mar 2017 06:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 nBL1-QFYVi7E for ; Thu, 16 Mar 2017 06:22:59 -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 AE41C1294D1 for ; Thu, 16 Mar 2017 06:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=612; q=dns/txt; s=iport; t=1489670579; x=1490880179; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ER4lJrudyutdUV5cSCkNUP9pgR3Rp2FdLVyLtxZXdlM=; b=NbZzZ5t4bpPw0AzxfW0ErSs10V0MVlmjnYN2mzr6ZPA99IPKlquUE4oo 6kFsahIqBJamvns7872chzBykRQvEvqcg2Kv5qc56yfFlkzrkBlJ7wc7a UtZq2lGgAdGIUcf18VJuf3/6ToP+9kgOUTBT93/WhRXtHj+2g7hyRxEHl o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AQAVkcpY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhKmCDYYoPkViTMIIPgg4qhW4KAoMDPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WAQUjFUEQCxgCAiYCAlcGDQYCAQGJbw0OsF6CJopTAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARoFgQuFQ4IFgmqHWoJfAQScRZI+gWOIc4ZTk00fOIEEOR8VhzQkNYlIAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.36,172,1486425600"; d="scan'208";a="221124683" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 13:22:58 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v2GDMwR9032453; Thu, 16 Mar 2017 13:22:58 GMT To: Martin Thomson References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> <5367d767-4233-2709-3547-1eb6542792b4@cisco.com> Cc: mmusic From: Flemming Andreasen Message-ID: <4df6c384-4a09-8d0e-42a6-08ac11588562@cisco.com> Date: Thu, 16 Mar 2017 09:22:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 16 Mar 2017 13:23:02 -0000 On 3/15/17 11:37 PM, Martin Thomson wrote: > On 16 March 2017 at 07:35, Flemming Andreasen wrote: >> https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-01 >> >> The agenda is full at this point, but let us know if you have any comments. > My request for agenda time was clearly too heavily cloaked. Can I > request that we discuss draft-thomson-avtcore-sdp-uks ? > . Ok - will 15 minutes suffice (Christer has agreed to give up some time on bundle, but experience shows bundle tends to consume time and we really want it completed) ? Thanks -- Flemming From nobody Thu Mar 16 06:23: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 F3F8D1294D1 for ; Thu, 16 Mar 2017 06:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 vcMdtMxbmuqT for ; Thu, 16 Mar 2017 06:23:34 -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 42ADD1294C7 for ; Thu, 16 Mar 2017 06:23:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1266; q=dns/txt; s=iport; t=1489670614; x=1490880214; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=QCH1DPqnGGK1WPhxN8Bc+iVDv52LAgDBizixQ4A/ajY=; b=g+jGB0DXsJQw1Eiruw88N0q2iUhcl0cUXTZyOgLlQOqUGpdjDtTeMUnE J7qWCzBdLfxhicyaXYsmK6SCMCAeri3wNjfrLOz17AaXTxMgpC87mPs+0 ye8icHZUhG+O9PpTS/l9TeOimxfIeAwTDQCLg06fgNVbDH4E7SMGc8Kin c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSAQAVkcpY/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1FhKmCNcJE5H5U/gg4fC4UuSgKDAz8YAQIBAQEBAQEBayiFFgE?= =?us-ascii?q?BAQMBATY2GwsYFRknMAYBDAYCAQEXiVgNDrMEilMBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEbBYZOggUIgmKEJW6FJgEEhmmVXIZ3hk6EeYF7hSiDM4ZTk00fOIEEOR8VQYZ?= =?us-ascii?q?zJDWJSAEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,172,1486425600"; d="scan'208";a="398955891" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 13:23:33 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2GDNW0W017001; Thu, 16 Mar 2017 13:23:33 GMT To: Martin Thomson , "mmusic@ietf.org" References: From: Flemming Andreasen Message-ID: Date: Thu, 16 Mar 2017 09:23:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 16 Mar 2017 13:23:36 -0000 Folks Please take a look at this and comment before the Chicago meeting. Thanks -- Flemming On 3/13/17 7:48 PM, Martin Thomson wrote: > After completely failing to remember and take into account feedback > during the avtcore meeting last time (thanks for the reminder > Jonathan), I would like to draw the attention of this group to this > draft: > > https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ > > The latest version builds on the a=dtls-id work in this group. > However, Jonathan's reminder highlighted a critical shortcoming of > that: it only works for DTLS. We still have uses of TLS-over-TCP that > would not be addressed by the current iteration of the draft (though > they would have for the previous version). > > One relatively simple solution is to define dtls-id as tls-id instead, > but that's disruptive. > > I'd like to discuss this issue with an eye to resolving it before or > at Chicago; I realize that there is a probably a tight agenda, but the > outcome of that discussion might affect a very-far-advanced > draft-ietf-mmusic-dtls-sdp-21. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Thu Mar 16 06:42:03 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 CBBD31294ED for ; Thu, 16 Mar 2017 06:42:00 -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 IU_JxTtli6RZ for ; Thu, 16 Mar 2017 06:41:59 -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 345621294F9 for ; Thu, 16 Mar 2017 06:41:59 -0700 (PDT) X-AuditID: c1b4fb25-ccfff70000002d78-f2-58ca9623a6d3 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 9A.52.11640.3269AC85; Thu, 16 Mar 2017 14:41:57 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Thu, 16 Mar 2017 14:41:54 +0100 From: Christer Holmberg To: Flemming Andreasen , Martin Thomson CC: mmusic Thread-Topic: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago Thread-Index: AQHSmaunsmsD2FK58kWwtfAH3DpGOqGWUyuAgAB14ACAAKO1AIAAJ5kA Date: Thu, 16 Mar 2017 13:41:54 +0000 Message-ID: References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> <5367d767-4233-2709-3547-1eb6542792b4@cisco.com> <4df6c384-4a09-8d0e-42a6-08ac11588562@cisco.com> In-Reply-To: <4df6c384-4a09-8d0e-42a6-08ac11588562@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7371C55FE731614D8707DA1856FB3E51@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7tK7qtFMRBi/OCFq8v6Brce3MP0aL qcsfszgwe0z5vZHVY+esu+weS5b8ZApgjuKySUnNySxLLdK3S+DKuLR5P3vBT46K+2/eszYw zmPvYuTkkBAwkbjxfTlbFyMXh5DAOkaJf1vfsUI4ixklphzcxNjFyMHBJmAh0f1PG6RBRCBC YvLJ5awgNrOAjMSMs41MILawgJ3En+4F7BA19hINHaeYIGw3iTdtjWBxFgFViRObroLZvALW EnNPvGaG2PWSUaL56U82kASngK3EzUVdYEWMAmIS30+tYYJYJi5x68l8JoirBSSW7DnPDGGL Srx8/A/sIFEBPYnlz9cwg9wsIaAkMW1rGkSrnsSNqVPYQMLMQHu/LXSGCGtLLFv4mhniHEGJ kzOfsExgFJ+FZNksJN2zELpnIemehaR7ASPrKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA 6Du45bfqDsbLbxwPMQpwMCrx8H4IOxkhxJpYVlyZe4hRgoNZSYT3YChQiDclsbIqtSg/vqg0 J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBkYJa5VIr9w0yd6Uei4JRY/1mYfN rs5cxPgzQ+7/x9ei526lP7x5fW6Jmsyy1JXbkvNESgP2S07Wfl/9dVvch9txco+m28ZEsU/1 j93MuqAmbWrPG75VbdYJLS9av97ODUi9XlTQVRnXPJUja0XGsUPnpL3r1y16f8f7069r7bYL z3L63e9t0ldiKc5INNRiLipOBADCT+pZugIAAA== Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 16 Mar 2017 13:42:01 -0000 Hi, >On 3/15/17 11:37 PM, Martin Thomson wrote: >> On 16 March 2017 at 07:35, Flemming Andreasen >>wrote: >>> https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-01 >>> >>> The agenda is full at this point, but let us know if you have any >>>comments. >> My request for agenda time was clearly too heavily cloaked. Can I >> request that we discuss draft-thomson-avtcore-sdp-uks ? >> . >Ok - will 15 minutes suffice (Christer has agreed to give up some time >on bundle, but experience shows bundle tends to consume time and we >really want it completed) ? That is true.=20 But, the main remaining issues in BUNDLE is to get the rtp-to-m-line-mapping text and the mid-security-text done, and I don=B9t think agenda time is needed for that - it would just end up in a behind-the-microphone argument. People should instead work on producing text that is agreeable to everyone. So, I intend to focus on the using-rtp-attributes-in-non-rtp-m-lines issue. Anyone having issues with that should have raised those on the list weeks ago - not wait until Chicago. Regards, Christer From nobody Thu Mar 16 09:15:02 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 12754129663 for ; Thu, 16 Mar 2017 09:15:01 -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 C69aHJBJjIxC for ; Thu, 16 Mar 2017 09:14:57 -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 B7B15129680 for ; Thu, 16 Mar 2017 09:14:57 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 141so27394608pgd.1 for ; Thu, 16 Mar 2017 09:14: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=mF8qGutcTtOvkh79HM1NKSGLr7DXqZsigtXnivLRyLE=; b=NusOkHEZTW/sp2r3FilFAWqZv+CS4EL8jH2t1epDp4PBGCZ5RMk0JrEpRHjrMPZHpa ZXVT7ePqtXDfNmC0vWk0AODqdojv/BEXl5tQ6zl6Tx/AezsI7JgDPmJD9Egonklt3fh6 OJF+G6+DcKXaH2hAbVkfNYAGO4VSa0JP4aT8Cv3NGHuoqPyPmJd6NlHlThTGVr4vNHDS saVQzJAsnO3ZL/2LjVSjoW1EZw1P2bK3hNxfb1lHj8yuolILdSwWY8n2JVW4M7V7SkrF GN6bNXYhBZ8Iw78u/wcsRF9Ms/sRUuU7Gdxv6GmJ0CLTyWrmU/dGB6er9R3gn2UA5Koi MQVQ== 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=mF8qGutcTtOvkh79HM1NKSGLr7DXqZsigtXnivLRyLE=; b=tR9Y2Sao5W7Bd31noEJ2RERqYoj0svQ3gRS3URvTA/+zGRECPZQrKwcsMdAQjAF4LV TeDNkOE5WWDImgL8fyOdkLxYEeLHZyVZUaX4hrwZlc/Pstp338DP4RBSA7mo//7EaMTW YexpJ0W+VZuWpPQB3VY4pJNSD+rB5U4548a3fwc9cazsQlEg72S+24CNanDGHH5cjU9p 2wnxmhRDkeMyNmuiyCIseEk36uYQcRQApgZTBm15MeThyxJTONS5LlVetXnXxdA0NqLk 1a4DedvtWqy83JTetXIx0ViHFooe5qeQhYrmhy1weAtA/InFbQqR0B3GLS6QlgRYpHGr D4+A== X-Gm-Message-State: AFeK/H3sVuy/OvmrPzdargKt8rnc1LnT0YqhTyESGBga0U3G4ScUcypSrywHD7zxTTzUBg== X-Received: by 10.99.42.78 with SMTP id q75mr10894614pgq.144.1489680896917; Thu, 16 Mar 2017 09:14:56 -0700 (PDT) Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com. [209.85.192.180]) by smtp.gmail.com with ESMTPSA id e70sm11499160pfh.84.2017.03.16.09.14.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 09:14:56 -0700 (PDT) Received: by mail-pf0-f180.google.com with SMTP id x63so21090531pfx.2 for ; Thu, 16 Mar 2017 09:14:56 -0700 (PDT) X-Received: by 10.99.146.73 with SMTP id s9mr11173104pgn.185.1489680896012; Thu, 16 Mar 2017 09:14:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Thu, 16 Mar 2017 09:14:55 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Thu, 16 Mar 2017 12:14:55 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1b6a3ca2bef3054adb5ca5 Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 16 Mar 2017 16:15:01 -0000 --94eb2c1b6a3ca2bef3054adb5ca5 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 13, 2017 at 7:48 PM, Martin Thomson wrote: > After completely failing to remember and take into account feedback > during the avtcore meeting last time (thanks for the reminder > Jonathan), I would like to draw the attention of this group to this > draft: > > https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ > > The latest version builds on the a=dtls-id work in this group. > However, Jonathan's reminder highlighted a critical shortcoming of > that: it only works for DTLS. We still have uses of TLS-over-TCP that > would not be addressed by the current iteration of the draft (though > they would have for the previous version). > > One relatively simple solution is to define dtls-id as tls-id instead, > but that's disruptive. > > I'd like to discuss this issue with an eye to resolving it before or > at Chicago; I realize that there is a probably a tight agenda, but the > outcome of that discussion might affect a very-far-advanced > draft-ietf-mmusic-dtls-sdp-21. > Alternatively we can keep dtls-id the way it is currently defined and define tls-id to be used for TLS-over-TCP in the new draft. I would also prefer a more generic name for the TLS extension itself. It does not have to be related to SDP, so some sort of endpoint_id would work better then sdp_dtls_id. Regards, _____________ Roman Shpount --94eb2c1b6a3ca2bef3054adb5ca5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 13, 2017 at 7:48 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
After completely failing to remember and take into account feedback during the avtcore meeting last time (thanks for the reminder
Jonathan), I would like to draw the attention of this group to this
draft:

https://datatracker.ietf.org/doc= /draft-thomson-avtcore-sdp-uks/

The latest version builds on the a=3Ddtls-id work in this group.
However, Jonathan's reminder highlighted a critical shortcoming of
that: it only works for DTLS.=C2=A0 We still have uses of TLS-over-TCP that=
would not be addressed by the current iteration of the draft (though
they would have for the previous version).

One relatively simple solution is to define dtls-id as tls-id instead,
but that's disruptive.

I'd like to discuss this issue with an eye to resolving it before or at Chicago; I realize that there is a probably a tight agenda, but the
outcome of that discussion might affect a very-far-advanced
draft-ietf-mmusic-dtls-sdp-21.

Alternat= ively we can keep dtls-id the way it is currently defined and define tls-id= to be used for TLS-over-TCP =C2=A0in the new draft.

I = would also prefer a more generic name for the TLS extension itself. It does= not have to be related to SDP, so some sort of endpoint_id would work bett= er then sdp_dtls_id.

Regards,
_____________
Roman Shpount
=C2=A0
<= /div>
--94eb2c1b6a3ca2bef3054adb5ca5-- From nobody Thu Mar 16 15:52:54 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 50066129B0F; Thu, 16 Mar 2017 15:52:52 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148970477218.14169.419075593372917827@ietfa.amsl.com> Date: Thu, 16 Mar 2017 15:52:52 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-22.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, 16 Mar 2017 22:52:52 -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 of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-22.txt Pages : 27 Date : 2017-03-16 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a 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, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 16 18: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 48802129BB5 for ; Thu, 16 Mar 2017 18:33:46 -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 3Lh-aArDOq9J for ; Thu, 16 Mar 2017 18:33:45 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97010129BB3 for ; Thu, 16 Mar 2017 18:33:44 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p64so54288906qke.1 for ; Thu, 16 Mar 2017 18:33:44 -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=2rI2XiEjkHAzFb0ZsQjLopMukksxr9d+Ru21Vh+j4fo=; b=WbUKxW8TexyzIS17XVjTLElz8q0lV8SJtqKBp8O641AjtTrW33FhXAjN24IHRuuyzS 5+AuQa+QfDDQX6Z+IBxML/1bbVXwigPayL7cHmYzChvSNxy6mZzzqTInNWhz90wDy9vC fESftlOI1xx79PRR3t/j947sU8ldq4JBFP0ItyvhnumOVn0IYcN/3hQpbhqTovlg/Emp 28tYMVGoKE4OWYcxLZLbpGN34ZN+fFAN3qtuxTDbSQU/Mf4eqnOP2IFmTjjFz+VH1pK9 2SQM373brtQqZswz0X+PwsJh3g5GsaLH5yRBkv8ywWQqM7FJVB2HhDP5bYPFg9TuwW5p aFuQ== 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=2rI2XiEjkHAzFb0ZsQjLopMukksxr9d+Ru21Vh+j4fo=; b=CLrhHRZyro7xD8o4udjuXsdEZj38R+xu/f8PB7B9aqfmS1P6KdBe2USDo59P+I22NW nauieQ9QGE7FcZzY6BHm+BfZaxqQ3ueUnhuQ/v1hfM2rwiPOXq4miqWklCSDlyJHbG89 9SoQz4u/vHsebBc5mYCOcfuLTYo9lIrxyDpr8xty+YVypBMOJYC9D1kyr/mKFVZ5qi+A lpzL5eObcDBlZoWwIPN8pbuZSsaBIJwWdkTdps3g+Kp/YK7OR4temXSfnM5ga0hRHrru 63IIV8xuQ2orqI/NJbqC5wtHJn1KceYNr5qbZ7A3GaVylEtYiOANNMUd5t/bJbUWgoOL lLQA== X-Gm-Message-State: AFeK/H1DniQifB2o5l0InnidrXllJvtm37OBtwYhCCXWHs6f5FOq5Nz+sMMBfpTxPiVI0yFjZr7IDxQbv3UCZw== X-Received: by 10.55.5.146 with SMTP id 140mr11897700qkf.202.1489714423812; Thu, 16 Mar 2017 18:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Thu, 16 Mar 2017 18:33:43 -0700 (PDT) In-Reply-To: <4df6c384-4a09-8d0e-42a6-08ac11588562@cisco.com> References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> <5367d767-4233-2709-3547-1eb6542792b4@cisco.com> <4df6c384-4a09-8d0e-42a6-08ac11588562@cisco.com> From: Martin Thomson Date: Fri, 17 Mar 2017 12:33:43 +1100 Message-ID: To: Flemming Andreasen Cc: mmusic Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 17 Mar 2017 01:33:46 -0000 On 17 March 2017 at 00:22, Flemming Andreasen wrote: > Ok - will 15 minutes suffice (Christer has agreed to give up some time on > bundle, but experience shows bundle tends to consume time and we really want > it completed) ? I think that we could be done in 10 if we keep on task. I really, really want bundle done, so let's give Christer his time and if I get bumped I will be sad, but it won't be too bad as long as we close on the bundle issues. From nobody Thu Mar 16 18:40: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 DB1AC129B9B for ; Thu, 16 Mar 2017 18:40:57 -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 IfNLWxwPjEN1 for ; Thu, 16 Mar 2017 18:40:56 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d: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 1B4DF129BB5 for ; Thu, 16 Mar 2017 18:40:56 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id 1so54332559qkl.3 for ; Thu, 16 Mar 2017 18:40:56 -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=wLnyoZOaOtR+eIrnDr3Wc6YLJASu41XXLbZPY6PCqA8=; b=jxS547s+x8+bLkV9gVCjbo0i67Xv1+ZBf+4X9cJmiuOwWgeIzJgRX7A8/1+IVgvWRP ZTsfbyZvqLqRUy3VyTLrgQam0CnUSknHTkOQ+0eOSs7I+LOgj3OBbwXGQjmVxPw+q6+S hUPvOfpjEzszhhql/lUo3BvWw0+BsfijaetwlSrKx1FazV5CWaqqimkoFGv6+MNM0Czv muvUFb+/g257X5k1IKrSzcqc+tYAsICilYcM/vDfxJneRn1zfXvmF5U+ogd+9USPWQ+8 +DTSdCx1Vi9P7UQzZM1hNlppqE1Ebat3c4yPoon583BHv+7kR3scpIr0y1wLNhVT9FAN KrWQ== 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=wLnyoZOaOtR+eIrnDr3Wc6YLJASu41XXLbZPY6PCqA8=; b=aJBEkI9ulZuyFIWNsFuXELeMABDNtjuDMrhIZ5OPfBlURAOfAwK4MPK64a5BiHqaM/ LPGDag61HkOL/mXYBlTtUoEJ564VTiL3nu6W2GWA8zyObrCiuD2NmkdkqPiW5Tp2qAV3 cMpdRUMwh/vL/bWCAu9sP1FemKfuJwwgeIkIazELiQeAyk/luVgWMjL96VzrViKqz7q6 9ZaIl6CyI0Vm4ocvq/UO1oZU3vhFmcbojklW+kVFiny8a28pZgQ9sJRC9qtXyKThpQBe Y04vaQyXniM/b8BhxI95JIBSAhCQ0+scI5qyg3UXTOlgIDVsWaRadablGs+cntHt7UDZ E+Uw== X-Gm-Message-State: AFeK/H0ovg7y7Lj1w43jjLOFkyXFRZmwUsHjADjvIzYPN+4iIANQu0YveA4xG1Ot0cxJaZlOJtCGcTLk2Fo1vg== X-Received: by 10.55.136.2 with SMTP id k2mr7685578qkd.316.1489714855318; Thu, 16 Mar 2017 18:40:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Thu, 16 Mar 2017 18:40:54 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 17 Mar 2017 12:40:54 +1100 Message-ID: To: Roman Shpount Cc: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 17 Mar 2017 01:40:58 -0000 On 17 March 2017 at 03:14, Roman Shpount wrote: > Alternatively we can keep dtls-id the way it is currently defined and define > tls-id to be used for TLS-over-TCP in the new draft. I could accept tls-id. But if tls-id and dtls-id are the same and have similar semantics, then one attribute makes more sense. Using a "tls"-named attribute in DTLS isn't going to cause any real problems. > I would also prefer a more generic name for the TLS extension itself. It > does not have to be related to SDP, so some sort of endpoint_id would work > better then sdp_dtls_id. The point is to explicitly tie the TLS negotiation to the SDP. I was operating on the basis that SDP has a somewhat unique authentication arrangement and that there weren't many other examples like it. If you think that this could be made more general and applied to protocols that don't use SDP, that's probably true. But I can't think of a protocol that uses the same basic mechanisms for authentication. I'd be open to a change if you could name an example. I don't like building a general purpose mechanism with exactly one user; an example would help in choosing the right semantics. From nobody Thu Mar 16 20:24:13 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 EFE91129BCE for ; Thu, 16 Mar 2017 20:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 qAkhmiaJjr3g for ; Thu, 16 Mar 2017 20:24:09 -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 35B87129BC8 for ; Thu, 16 Mar 2017 20:24:09 -0700 (PDT) Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E26EB56B2; Thu, 16 Mar 2017 23:24:01 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9CB3C543D; Thu, 16 Mar 2017 23:24:01 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.116.117] ([UNAVAILABLE]. [128.107.241.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Thu, 16 Mar 2017 23:24:01 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Thu, 16 Mar 2017 21:24:00 -0600 Cc: "mmusic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 17 Mar 2017 03:24:11 -0000 One ID for both TLS and DTLS make sense to me.=20 The one thing that is key for perc, is that in the Client Hello, this = need to not be encrypted so that the MDD can use it to recognize which = KDD is meant to be routed to. Effectively you can think as the MDD as a = load balancers for all the KDDs that act as the TLS server and it is = using this field much like a normal load balancer might use SNI. So I = want to make sure we preserver this property.=20 This is probably crazy, but, I wonder if it would make sense to just use = the SNI.=20 > On Mar 13, 2017, at 5:48 PM, Martin Thomson = wrote: >=20 > After completely failing to remember and take into account feedback > during the avtcore meeting last time (thanks for the reminder > Jonathan), I would like to draw the attention of this group to this > draft: >=20 > https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/ >=20 > The latest version builds on the a=3Ddtls-id work in this group. > However, Jonathan's reminder highlighted a critical shortcoming of > that: it only works for DTLS. We still have uses of TLS-over-TCP that > would not be addressed by the current iteration of the draft (though > they would have for the previous version). >=20 > One relatively simple solution is to define dtls-id as tls-id instead, > but that's disruptive. >=20 > I'd like to discuss this issue with an eye to resolving it before or > at Chicago; I realize that there is a probably a tight agenda, but the > outcome of that discussion might affect a very-far-advanced > draft-ietf-mmusic-dtls-sdp-21. >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Mar 16 20:38:48 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 5C110129BD4 for ; Thu, 16 Mar 2017 20:38:46 -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 Pg73kjWkXb6H for ; Thu, 16 Mar 2017 20:38:44 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 85434129BDA for ; Thu, 16 Mar 2017 20:38:44 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id x35so53797151qtc.2 for ; Thu, 16 Mar 2017 20:38:44 -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=evnTSxqhAgql6n6hXgiD9fk4rYFMCfj+kNWsVKlRgE4=; b=hINB6cCaOB7gq8m904yn2EtWjd2QBqKjV47W9aCFMb86uyvnotNUjWhk5laogSUvLe BdOKVKe5U7F4F/sB7BKotdGcu1TdfSaIYzrvX8cqu03HXauxDJRAxnUx6H7nXjKWNDFe eWnij6bq64U7KhN2CW3fkgP1F2yMNrweqW7HPeXPVBCBBSHFkB6cNFY92kNxQkOQ9NQq 2aggbf50jsqBDPfHntCc/b2yhMECHkST5/eEIgyZTRaqvdjXhyKLVtsCp9tz1q0BfTJD wntT6HhBIiJxJxDjGsUoAxcKY9LbfmMmsy4cQ9Idbc/owBnlel1gVBMNV5ZpemGoJfT9 fr5w== 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=evnTSxqhAgql6n6hXgiD9fk4rYFMCfj+kNWsVKlRgE4=; b=QpgWJg32RU1r4zuQosmcMbdHytGmITxblaoZLOfjMlqPXAYLzaBlOZ5FrDj/vZkp63 NhiJWMAf0A61YIQ9oiY9H0KMn8A4/nP9xerF4NRivsk7tA6D0gjsy9sO4CJcKCy7bnWz VVU3EZ4iwJNduUL8iWNeitzLjY0p94AMm3UM9or8a8C4dmmN+IcHzDz+3H8tYvXJ9JK8 OvW7QWapE1dyy1rqg9YM9YyTGV351pki66QZtogrYqiMufBJLX9SS4IrplnVtkYsTmpk LylHXq7zx5oB0u2Ltqlapo1bPR5nAc21OLfI2bl1UTi8GqouPC7odJjjqeQtWHEbmPtv Hvpg== X-Gm-Message-State: AFeK/H0uHjFFWCzuIzXeDRfUJHBVerVvsY6jjt/wQPx4yNjm8Ag2Hk+XQqaTkI+isngs5w4zlc9jarkHFPvsOQ== X-Received: by 10.200.46.208 with SMTP id i16mr11718179qta.13.1489721923715; Thu, 16 Mar 2017 20:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Thu, 16 Mar 2017 20:38:43 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 17 Mar 2017 14:38:43 +1100 Message-ID: To: Cullen Jennings Cc: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 17 Mar 2017 03:38:46 -0000 On 17 March 2017 at 14:24, Cullen Jennings wrote: > The one thing that is key for perc, is that in the Client Hello, this nee= d to not be encrypted so that the MDD can use it to recognize which KDD is = meant to be routed to. Effectively you can think as the MDD as a load balan= cers for all the KDDs that act as the TLS server and it is using this field= much like a normal load balancer might use SNI. So I want to make sure we = preserver this property. Yes, the design keeps the value in the clear (in the ClientHello at least). That's the easiest possible design. The client can't start encrypting until it has talked to the server. We could add extra messages to carry this in an encrypted form, but as you say that would screw with routing and there is no major value in providing confidentiality for this value. > This is probably crazy, but, I wonder if it would make sense to just use = the SNI. It's not crazy, though it might be suboptimal for a few reasons. The design I chose has both peers include the extension as well as independently checking the value they receive. Servers don't typically send SNI so SNI wouldn't be symmetrical in this fashion. Servers are permitted to send SNI, but I don't know any that do (and would be worried that this is wrong). A different a=3Ddtls-id value is required from both offerer and answerer, so you would have to concatenate the two in some unambiguous form to have it work as intended. Then the value we use probably needs to look like a domain name. Despite being ostensibly extensible, SNI effectively means domain name [1]. The biggest concern for me is that you don't get redundant checks with SNI. The client has to trust that the server is checking and gets no positive indication that the server even supports the feature. The benefit of pretending that it is SNI is that you can feed it through existing APIs and hook into existing load balancer code paths. On balance, I'd prefer to keep this as a custom extension. [1] https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc From nobody Fri Mar 17 06:18:13 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 9E7A41293DB; Fri, 17 Mar 2017 06:18:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-mmusic-dtls-sdp@ietf.org, ben@nostrum.com, fandreas@cisco.com, mmusic@ietf.org, mmusic-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148975668560.14209.10746850325933103667.idtracker@ietfa.amsl.com> Date: Fri, 17 Mar 2017 06:18:05 -0700 Archived-At: Subject: [MMUSIC] Last Call: (Using the SDP Offer/Answer Mechanism for DTLS) to Proposed Standard 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, 17 Mar 2017 13:18:05 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Using the SDP Offer/Answer Mechanism for DTLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the SDP offer/answer procedures for negotiating and establishing a 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, 'dtls-id'. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 17 07:04: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 8675F128DF3 for ; Fri, 17 Mar 2017 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 pEzAWxazchJe for ; Fri, 17 Mar 2017 07:04:04 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC75B12943D for ; Fri, 17 Mar 2017 07:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=614; q=dns/txt; s=iport; t=1489759443; x=1490969043; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=n5KOjc5BxjFfo6BChD6G9Em1nSgUQe7123dXh+4MB0Q=; b=gG0aHuDM39GE098NRRCxliwxp86o2OzPOMH5hhKn7h2aqbhObD+yoa1u 6Exlk9MfSZ1FXcfjAW4TBKbiNNjeN479m+ZQtHApGC0TKAQbgGCCAv/9q nqw/YCMb87KzRdIUHIZoXE4g6IePAhZ+hRrEoV0NOEH1sFenWd2EWCtTx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHBQCC68tY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBC2CDYptIH5MzhB2GIgKDAEIVAQIBAQEBAQEBayiFFgEFIxV?= =?us-ascii?q?BEAsYAgImAgJXBg0GAgEBiW8NsheCJopSAQEBAQEBAQEBAQEBAQEBAQEhgQuFQ?= =?us-ascii?q?4IFCIJih1qCXwEEnEmSQoFjiHOGVZNTNSKBBDkfFYc0JDWJVwEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,176,1486425600"; d="scan'208";a="398371350" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 14:04:03 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2HE429g024042; Fri, 17 Mar 2017 14:04:02 GMT To: Martin Thomson References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> <5367d767-4233-2709-3547-1eb6542792b4@cisco.com> <4df6c384-4a09-8d0e-42a6-08ac11588562@cisco.com> Cc: mmusic From: Flemming Andreasen Message-ID: Date: Fri, 17 Mar 2017 10:04:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 17 Mar 2017 14:04:10 -0000 Sounds good - agenda updated accordingly. Thanks -- Flemming On 3/16/17 9:33 PM, Martin Thomson wrote: > On 17 March 2017 at 00:22, Flemming Andreasen wrote: >> Ok - will 15 minutes suffice (Christer has agreed to give up some time on >> bundle, but experience shows bundle tends to consume time and we really want >> it completed) ? > I think that we could be done in 10 if we keep on task. I really, > really want bundle done, so let's give Christer his time and if I get > bumped I will be sad, but it won't be too bad as long as we close on > the bundle issues. > . > From nobody Fri Mar 17 09:11:06 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 C68F01294D1 for ; Fri, 17 Mar 2017 09:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, 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 pFeJSHhTC6GG for ; Fri, 17 Mar 2017 09:11:04 -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 17D661294CD for ; Fri, 17 Mar 2017 09:11:04 -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 6F436A0342; Fri, 17 Mar 2017 12:11:03 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 24C81A0377; Fri, 17 Mar 2017 12:11:03 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.22.253] ([UNAVAILABLE]. [128.107.241.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Fri, 17 Mar 2017 12:11:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 17 Mar 2017 10:11:00 -0600 Cc: "mmusic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 17 Mar 2017 16:11:06 -0000 > On Mar 16, 2017, at 9:38 PM, Martin Thomson = wrote: >=20 > On 17 March 2017 at 14:24, Cullen Jennings wrote: >> The one thing that is key for perc, is that in the Client Hello, this = need to not be encrypted so that the MDD can use it to recognize which = KDD is meant to be routed to. Effectively you can think as the MDD as a = load balancers for all the KDDs that act as the TLS server and it is = using this field much like a normal load balancer might use SNI. So I = want to make sure we preserver this property. >=20 > Yes, the design keeps the value in the clear (in the ClientHello at > least). That's the easiest possible design. The client can't start > encrypting until it has talked to the server. We could add extra > messages to carry this in an encrypted form, but as you say that would > screw with routing and there is no major value in providing > confidentiality for this value. >=20 perfect >> This is probably crazy, but, I wonder if it would make sense to just = use the SNI. >=20 > It's not crazy, though it might be suboptimal for a few reasons. >=20 > The design I chose has both peers include the extension as well as > independently checking the value they receive. Servers don't > typically send SNI so SNI wouldn't be symmetrical in this fashion. > Servers are permitted to send SNI, but I don't know any that do (and > would be worried that this is wrong). A different a=3Ddtls-id value = is > required from both offerer and answerer, so you would have to > concatenate the two in some unambiguous form to have it work as > intended. >=20 > Then the value we use probably needs to look like a domain name. > Despite being ostensibly extensible, SNI effectively means domain name > [1]. >=20 > The biggest concern for me is that you don't get redundant checks with > SNI. The client has to trust that the server is checking and gets no > positive indication that the server even supports the feature. >=20 > The benefit of pretending that it is SNI is that you can feed it > through existing APIs and hook into existing load balancer code paths. >=20 > On balance, I'd prefer to keep this as a custom extension. >=20 That's very convincing - sounds good to me.=20 > [1] = https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Mar 17 09:22: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 C49C71294CC for ; Fri, 17 Mar 2017 09:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-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 2FadUW3zwDXe for ; Fri, 17 Mar 2017 09:21:58 -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 146F61294A5 for ; Fri, 17 Mar 2017 09:21:58 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2HGJ0Qk018184; Fri, 17 Mar 2017 12:21:54 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 294cv8cm72-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Fri, 17 Mar 2017 12:21:54 -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; Fri, 17 Mar 2017 11:21:53 -0500 From: Jonathan Lennox To: Martin Thomson CC: Roman Shpount , mmusic Thread-Topic: [MMUSIC] Unknown key shares in MMUSIC Thread-Index: AQHSnzjjfyvKZCgF2E6ty0IZaQSz7aGZiosA Date: Fri, 17 Mar 2017 16:21:53 +0000 Message-ID: <44E3DEA7-165B-4B9F-822B-C1349A0D984D@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <1CA05117E4F2134496863B0A4737C12F@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-17_13:, , 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-1702020001 definitions=main-1703170136 Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 17 Mar 2017 16:21:59 -0000 DQo+IE9uIE1hciAxNiwgMjAxNywgYXQgOTo0MCBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBJZiB5b3UgdGhpbmsgdGhhdCB0aGlzIGNv dWxkIGJlIG1hZGUgbW9yZSBnZW5lcmFsIGFuZCBhcHBsaWVkIHRvDQo+IHByb3RvY29scyB0aGF0 IGRvbid0IHVzZSBTRFAsIHRoYXQncyBwcm9iYWJseSB0cnVlLiAgQnV0IEkgY2FuJ3QgdGhpbmsN Cj4gb2YgYSBwcm90b2NvbCB0aGF0IHVzZXMgdGhlIHNhbWUgYmFzaWMgbWVjaGFuaXNtcyBmb3Ig YXV0aGVudGljYXRpb24uDQo+IA0KPiBJJ2QgYmUgb3BlbiB0byBhIGNoYW5nZSBpZiB5b3UgY291 bGQgbmFtZSBhbiBleGFtcGxlLiAgSSBkb24ndCBsaWtlDQo+IGJ1aWxkaW5nIGEgZ2VuZXJhbCBw dXJwb3NlIG1lY2hhbmlzbSB3aXRoIGV4YWN0bHkgb25lIHVzZXI7IGFuIGV4YW1wbGUNCj4gd291 bGQgaGVscCBpbiBjaG9vc2luZyB0aGUgcmlnaHQgc2VtYW50aWNzLg0KDQpUaGUgZXhhbXBsZSB0 aGF0IGNvbWVzIHRvIG1pbmQgaXMgSmluZ2xlIOKAlCBYRVAtMDMyMCBkZWZpbmVzIHRoZSB1c2Ug b2YgRFRMUy1TUlRQIGFuZCBGaW5nZXJwcmludCB3aXRoIEppbmdsZS4NCg0KSW4gZ2VuZXJhbCwg YW55dGhpbmcgdGhhdOKAmXMgaGlnaC1sZXZlbCBzZW1hbnRpY2FsbHkgZXF1aXZhbGVudCB0byBT RFAsIGJ1dCB0cmllcyB0byBiZSBsZXNzIGF3ZnVsIGluIGl0cyBzeW50YXggKGxvdyBiYXIpLCB3 aWxsIHdhbnQgdG8gdXNlIHRoaXMgbWVjaGFuaXNtLiA= From nobody Fri Mar 17 09:24: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 BFB861294DC for ; Fri, 17 Mar 2017 09:24:16 -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 LLZjPVJ-CLrt for ; Fri, 17 Mar 2017 09:24:15 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 EB45B1294D7 for ; Fri, 17 Mar 2017 09:24:14 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id g2so44733496pge.3 for ; Fri, 17 Mar 2017 09:24:14 -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=982cjjBfXBleP+Tzhid969Oe5NgLTlDCQ69pC78Cdkc=; b=gSotg+0vtNeQewb0jEUiOyTxB0FaMGWaFC6LIU26S8A30Y9n7BJ87nKXmfNIOHsmG+ MyUr7bOUr/OcrM4SsXtafxG75ibDwy05shJd9h2M39RgAcS6rjaiGkpH28QTT5a9UT1H jSL9Df8gcQ6TUEP69UcEUbJ1TASaEAY6VN88FHtqcaUrpr8QnAMoQugczZN+SxzbwMR4 T6KILMwB3ih8UNQHDxxT+Gk2fdsZARaqvHCJd9aV0mRwidVLUbQYTG5sBODxzdbvK4TB BFqn6/Yy7vulvc5MM2eVkb0izK2OYIXXPKGPIOaZIJznrm69WGBktthwp5ADTxzTFvJ7 SVzw== 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=982cjjBfXBleP+Tzhid969Oe5NgLTlDCQ69pC78Cdkc=; b=BDBf0jdUVY8xU+cpng0zr+fptZInECex9HymgAnbqut2OUipyTHl0c0bQxWw72WZNC vZKNnPJfIczOIKb+TMCu5+CF2MzrGysBv4ZO5T3iC98zNIhEFC22EMp9hNOHdTVPJliM bqnmW0K9KOoeRrUOWVby/kS89D0qBZaIzf9/pV5zaBMh+yV8uYYyNzixudk9HvZaZ+NA Jo1F4pVpueayDA3Ehlk55OTtQHN8seu3KzrEyW23KwST4RWx5ZaLhMwU0qhd0f02DViy OhmQBnZAL7tsDuC7s2Z/CrWaOLdSaSJ/IlZFWBowSinBDH5dbgfCUvaPwPp3PYEhF2EA +gbg== X-Gm-Message-State: AFeK/H3Mqo4AY6ivYS937Rl0cT77/tmdMYpCoi0yZ5PxkpEwQwRmwR1EuzKieSaCNcyjYw== X-Received: by 10.99.51.76 with SMTP id z73mr17113133pgz.137.1489767854345; Fri, 17 Mar 2017 09:24:14 -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 y6sm17933301pgc.1.2017.03.17.09.24.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 09:24:13 -0700 (PDT) Received: by mail-pg0-f45.google.com with SMTP id n190so44965378pga.0 for ; Fri, 17 Mar 2017 09:24:13 -0700 (PDT) X-Received: by 10.99.225.5 with SMTP id z5mr16819141pgh.145.1489767853205; Fri, 17 Mar 2017 09:24:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.5 with HTTP; Fri, 17 Mar 2017 09:24:12 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Fri, 17 Mar 2017 12:24:12 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a114e93a4b03a8c054aef9b0f Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 17 Mar 2017 16:24:17 -0000 --001a114e93a4b03a8c054aef9b0f Content-Type: text/plain; charset=UTF-8 On Thu, Mar 16, 2017 at 9:40 PM, Martin Thomson wrote: > On 17 March 2017 at 03:14, Roman Shpount wrote: > > Alternatively we can keep dtls-id the way it is currently defined and > define > > tls-id to be used for TLS-over-TCP in the new draft. > > I could accept tls-id. But if tls-id and dtls-id are the same and > have similar semantics, then one attribute makes more sense. Using a > "tls"-named attribute in DTLS isn't going to cause any real problems. > The reason I am thinking different names can make sense is interaction of dtls-id/tls-id with new connection establishment. The change in dtls-id values is used to signal new DTLS association establishment. In case of TLS-over-TCP, new connection establishment is signaled using a=connection:new/existing SDP attribute. Do you want tls-id overwrite connection attribute? Only allow to change tls-id when a=connection:new is present? I understand that tls-id and dtls-id carry similar meaning in your newly proposed extension. Are they going to carry the same meaning in new connection negotiation? > I would also prefer a more generic name for the TLS extension itself. It > > does not have to be related to SDP, so some sort of endpoint_id would > work > > better then sdp_dtls_id. > > The point is to explicitly tie the TLS negotiation to the SDP. I was > operating on the basis that SDP has a somewhat unique authentication > arrangement and that there weren't many other examples like it. > > If you think that this could be made more general and applied to > protocols that don't use SDP, that's probably true. But I can't think > of a protocol that uses the same basic mechanisms for authentication. > > I'd be open to a change if you could name an example. I don't like > building a general purpose mechanism with exactly one user; an example > would help in choosing the right semantics. > One thing I can think of is ORTC. No SDP there, but the same issue that you described is present there. Alternatively connection can be negotiated using jingle. I do not think the issue you raised is specific to SDP, as a format used to encode media stream description. This issue is specific to identifying certificates by fingerprint, no matter how this fingerprint is transmitted. Regards, _____________ Roman Shpount --001a114e93a4b03a8c054aef9b0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 16, 2017 at 9:40 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
O= n 17 March 2017 at 03:14, Roman Shpount <roman@telurix.com> wrote:
> Alternatively we can keep dtls-id the way it is currently defined and = define
> tls-id to be used for TLS-over-TCP=C2=A0 in the new draft.

I could accept tls-id.=C2=A0 But if tls-id and dtls-id are the same = and
have similar semantics, then one attribute makes more sense.=C2=A0 Using a<= br> "tls"-named attribute in DTLS isn't going to cause any real p= roblems.

The reason I am thinking diffe= rent names can make sense is interaction of dtls-id/tls-id with new connect= ion establishment. The change in dtls-id values is used to signal new DTLS = association establishment. In case of TLS-over-TCP, new connection establis= hment is signaled using a=3Dconnection:new/existing SDP attribute. Do you w= ant tls-id overwrite connection attribute? Only allow to change tls-id when= =C2=A0a=3Dconnection:new is present? I understand that tls-id and dtls-id = carry similar meaning in your newly proposed extension. Are they going to c= arry the same meaning in new connection negotiation?

>= I would also prefer a more generic name for the TLS extension itself. It > does not have to be related to SDP, so some sort of endpoint_id would = work
> better then sdp_dtls_id.

The point is to explicitly tie the TLS negotiation to the SDP.=C2=A0= I was
operating on the basis that SDP has a somewhat unique authentication
arrangement and that there weren't many other examples like it.

If you think that this could be made more general and applied to
protocols that don't use SDP, that's probably true.=C2=A0 But I can= 't think
of a protocol that uses the same basic mechanisms for authentication.

I'd be open to a change if you could name an example.=C2=A0 I don't= like
building a general purpose mechanism with exactly one user; an example
would help in choosing the right semantics.

One thing I can thi= nk of is ORTC. No SDP there, but the same issue that you described is prese= nt there. Alternatively connection can be negotiated using jingle. I do not= think the issue you raised is specific to SDP, as a format used to encode = media stream description. This issue is specific to identifying certificate= s by fingerprint, no matter how this fingerprint is transmitted.

Regards,
_____________<= br>Roman Shpount

--001a114e93a4b03a8c054aef9b0f-- From nobody Fri Mar 17 12:06: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 7F3C41273E2 for ; Fri, 17 Mar 2017 12:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, 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 wg0kl5MLKrF7 for ; Fri, 17 Mar 2017 12:06:19 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 D6777129401 for ; Fri, 17 Mar 2017 12:06:18 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-08v.sys.comcast.net with SMTP id oxBjc13tny4bMoxCccx5mr; Fri, 17 Mar 2017 19:06:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1489777578; bh=YqpQtDW4YIHdUlk1Wg+OqgDinCBf17K6e8S/Ywy9jeI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MPG0DcE8tiL52AJoEtV9YVF+4ta4PBF/4mApLjt9WzPhMALJ9sm+Ek0jsmKbhX1Vg rbJaMnuzkMnxYlsEFic1B9DJmkyVl4Wjowc/g2BvHjdw/wwWwuZhuP/ZDA+27py9HD T04OID9wPV6woIudIIyjcLjAV3gkclai5RlK7BWLXXhLrPi0Y4+wzgIVxZT5qYebF6 0mMjfM/z2vYcguFZokLI0LknRNmTrADdqn2OTUV0yYGqasPeTVhVEaZARYwyb0xIc8 v1cReZ91/isfAiOObc+6OPYHl/RyBCz3DvRm9wctJ2m+3e5h0REF0mDxWjz2usRhs+ egont7M43dA/w== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-12v.sys.comcast.net with SMTP id oxCbcRhlLQybtoxCbcneqJ; Fri, 17 Mar 2017 19:06:18 +0000 To: mmusic@ietf.org References: <44E3DEA7-165B-4B9F-822B-C1349A0D984D@vidyo.com> From: Paul Kyzivat Message-ID: <650e6749-ed1b-6486-caac-674c5862c6ca@comcast.net> Date: Fri, 17 Mar 2017 15:06:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <44E3DEA7-165B-4B9F-822B-C1349A0D984D@vidyo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfJ5JOxan7mPxWV4G1lQKfTf82JTPmJfdke0KgyycQ6PFSAOtUALKur3cBfxZ+m5Qgdv6sy+NmKi3PsehrrT1UtZJRO4ym6jMV5O/oencs5hLxy5SDiLm b5SYxTSTwvzZfxIwkVN1FbOW7j8/Ciblyj4zdYdQUfcwRg+rYNzrC//z+sUj76CIt2zG35uCRph/hA== Archived-At: Subject: [MMUSIC] SDP syntax 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, 17 Mar 2017 19:06:20 -0000 On 3/17/17 12:21 PM, Jonathan Lennox wrote: > In general, anything that’s high-level semantically equivalent to SDP, but tries to be less awful in its syntax (low bar), will want to use this mechanism. Are you casting aspersions on the pristine syntax of SDP? From nobody Fri Mar 17 16:12: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 C6630129677; Fri, 17 Mar 2017 16:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 jtasHHYqvZGV; Fri, 17 Mar 2017 16:12:06 -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 BAB3E129693; Fri, 17 Mar 2017 16:11:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C2BD9B80DC7; Fri, 17 Mar 2017 16:11:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, mmusic@ietf.org Message-Id: <20170317231112.C2BD9B80DC7@rfc-editor.org> Date: Fri, 17 Mar 2017 16:11:12 -0700 (PDT) Archived-At: Subject: [MMUSIC] RFC 8122 on Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) 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, 17 Mar 2017 23:12:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8122 Title: Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) Author: J. Lennox, C. Holmberg Status: Standards Track Stream: IETF Date: March 2017 Mailbox: jonathan@vidyo.com, christer.holmberg@ericsson.com Pages: 18 Characters: 42792 Obsoletes: RFC 4572 I-D Tag: draft-ietf-mmusic-4572-update-13.txt URL: https://www.rfc-editor.org/info/rfc8122 DOI: 10.17487/RFC8122 This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Mar 19 16:11: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 9408C120025 for ; Sun, 19 Mar 2017 16:11:50 -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 bJzIqWVRAGO5 for ; Sun, 19 Mar 2017 16:11:49 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 E18BC126B7F for ; Sun, 19 Mar 2017 16:11:48 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id 1so98481790qkl.3 for ; Sun, 19 Mar 2017 16:11:48 -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=fCbjPXbMOLZlItvznu573DPpcfVxtRDCrUBEnpp2MGw=; b=HpY2AYzK0147utMATOH+/F3XI9LI/U01icfe0WssOM0OvUW2IcDwo9mM16EH5FKlyY yDWY9mJ6r1AMUuSUiJdc9yaBtNReTiSbhNn0IRmvT1aHzufECHc/JH2dTAN0fRU8w7ng NrsS0dyLuXLLoDNWPZqStAiDC4UrzxWPXejmYhTtk9coVbV6mti54XzZ5wowKCu/VxVV sXMnNpkqMXbapEp7YswTIIRvah2IJ2XEPzeUiuDC360pckhmjHdKXi8aiOsiHkRi50Vv 9DX8eYy+j7awnG/0UfqWG82uQ4ygotJscBg6dS8rpcP+RaNQ0bdwQof6si0g9qj8YP6D nhcA== 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=fCbjPXbMOLZlItvznu573DPpcfVxtRDCrUBEnpp2MGw=; b=bbl7pnaXAcoSvPCts+miZpumfU6r2QqR60PWJKCspDQgHboVd2qIwa7QUq0qJHG/ql mp/cTXoPVxX/U2UaB7Bgdggws90ggdV1nXnjLZr83rmmgYESsNsBXJh5l7IrPe94T8Sv Rkly8Kl7JJfe4Eb6YMODx6CMEQ2xB3/E2uWkjQZCk0rIDzmLBq4sprTgjWsvXlpPkaTp 1yakTXrt8xEXcS50vmdyDoho+4FEXiNgCYFaXd87pOeoVqQhNufL6y46aGie2Pgu5Kna Ipg4lDHRPvJXaD3OMXvthmqqkjnUg/B/JYextiAOTP3RQXFfzPA6p+0cjLiNpnZqPWMO /WBQ== X-Gm-Message-State: AFeK/H1Qbr1xbMbRxf9IQhLSKQk01Gv5UaniN7jn5HDAeghso48eAUAOMdlGFMor4iJbFwWr6dxhZEMaPmwlSw== X-Received: by 10.55.27.219 with SMTP id m88mr21627134qkh.147.1489965108052; Sun, 19 Mar 2017 16:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Sun, 19 Mar 2017 16:11:47 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 20 Mar 2017 10:11:47 +1100 Message-ID: To: Roman Shpount Cc: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] Unknown key shares in MMUSIC 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, 19 Mar 2017 23:11:51 -0000 On 18 March 2017 at 03:24, Roman Shpount wrote: >> I could accept tls-id. But if tls-id and dtls-id are the same and >> have similar semantics, then one attribute makes more sense. Using a >> "tls"-named attribute in DTLS isn't going to cause any real problems. > > > The reason I am thinking different names can make sense is interaction of > dtls-id/tls-id with new connection establishment. The change in dtls-id > values is used to signal new DTLS association establishment. In case of > TLS-over-TCP, new connection establishment is signaled using > a=connection:new/existing SDP attribute. Do you want tls-id overwrite > connection attribute? Only allow to change tls-id when a=connection:new is > present? I understand that tls-id and dtls-id carry similar meaning in your > newly proposed extension. Are they going to carry the same meaning in new > connection negotiation? I was thinking that tls-id would apply in both situations, but only carry the "new connection" semantics for DTLS. From franz.edler@a1telekom.at Sun Mar 19 08:54: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 966C61289C3 for ; Sun, 19 Mar 2017 08:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 zgxcm54igFlK for ; Sun, 19 Mar 2017 08:54:15 -0700 (PDT) Received: from mxout.a1telekom.at (mxout.a1telekom.at [193.187.235.26]) (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 C0D5E127A90 for ; Sun, 19 Mar 2017 08:54:14 -0700 (PDT) From: Edler Franz To: "mmusic@ietf.org" Thread-Topic: Question regarding RFC 6871 Thread-Index: AdKgyLmwucQseBx0SSqT6JVn7yyxJg== Date: Sun, 19 Mar 2017 15:54:11 +0000 Message-ID: <043c4e142e2a4b32b72f12b7440a9f23@a1telekom.at> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.16.35.26] Content-Type: multipart/alternative; boundary="_000_043c4e142e2a4b32b72f12b7440a9f23ntxchxp006austrialocal_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 20 Mar 2017 11:49:16 -0700 Subject: [MMUSIC] Question regarding RFC 6871 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, 19 Mar 2017 15:55:27 -0000 --_000_043c4e142e2a4b32b72f12b7440a9f23ntxchxp006austrialocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear experts, We are actually struggling with voiceband data (ITU-T recommendation V.152)= support. I recognize that V.152 assumes some SDP parameters/attributes like "vbd", "= maxmptime" and "pmft" which are not officially registered at IANA. What is the status of support of this V.152 specific parameters/attributes? Is there any acticity towards support of IETF about this? Best regards Franz Edler Technology Voice Core A1 Telekom Austria AG Lassallestra=DFe 9 1020 Wien M +43 664 3459781 T +43 50 664 35704 @ franz.edler@A1telekom.at --_000_043c4e142e2a4b32b72f12b7440a9f23ntxchxp006austrialocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear experts,

 

W= e are actually struggling with voiceband data (ITU-T recommendation V.152) = support.
I recognize that V.152 assumes some SDP parameters/attributes like “v= bd”, “maxmptime” and “pmft” which are not off= icially registered at IANA.

W= hat is the status of support of this V.152 specific parameters/attributes?<= br> Is there any acticity towards support of IETF about this?=

Best regards

 <= /p>

Franz Edler
Technology
Voice Core

A1 Tele= kom Austria AG
Lassallestra=DFe 9 1020 Wien
M &nb= sp; +43 664 = 3459781
T &nb= sp; +43 50 6= 64 35704
@ &nb= sp; franz.edler@A1telekom.at


 

--_000_043c4e142e2a4b32b72f12b7440a9f23ntxchxp006austrialocal_-- From nobody Mon Mar 20 12:26: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 66C48131480 for ; Mon, 20 Mar 2017 12:26:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 EgyxpIY9fa_p for ; Mon, 20 Mar 2017 12:26:28 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0126.outbound.protection.outlook.com [104.47.0.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A938312951B for ; Mon, 20 Mar 2017 12:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zUGEJplydoWZFVjIcdIkwSWUnXEzILcKSXBdix0869s=; b=mOmRO4TkdKm/7XPITz+DG8XslEYZhCsQ4XUPLYsfc+1+AARwNeYxS1b7Nu0ZTZsltJRV7ZczIxLfx/ji5Bg31s/Uu+WxOarctANnYAuTxY1qcnBnDkmtlKmpgF7sDRY/loHRCIguAfzPtzV/hk5hPbVjE6sOiKNOqNhhYv2WAV0= Received: from DB5PR07MB1480.eurprd07.prod.outlook.com (10.165.212.10) by DB5PR07MB1478.eurprd07.prod.outlook.com (10.165.212.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Mon, 20 Mar 2017 19:26:25 +0000 Received: from DB5PR07MB1480.eurprd07.prod.outlook.com ([fe80::f8ee:4cd:212f:cfc4]) by DB5PR07MB1480.eurprd07.prod.outlook.com ([fe80::f8ee:4cd:212f:cfc4%14]) with mapi id 15.01.0991.011; Mon, 20 Mar 2017 19:26:25 +0000 From: "Drage, Keith (Nokia - GB)" To: Edler Franz , "mmusic@ietf.org" Thread-Topic: Question regarding RFC 6871 Thread-Index: AdKgyLmwucQseBx0SSqT6JVn7yyxJgA5qQhQ Date: Mon, 20 Mar 2017 19:26:25 +0000 Message-ID: References: <043c4e142e2a4b32b72f12b7440a9f23@a1telekom.at> In-Reply-To: <043c4e142e2a4b32b72f12b7440a9f23@a1telekom.at> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: a1telekom.at; dkim=none (message not signed) header.d=none;a1telekom.at; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.29] x-microsoft-exchange-diagnostics: 1; DB5PR07MB1478; 7:3sBIMT5K4paGHN5AN3n8FUWl0qzlCiIWHXhonJESc2i2JhUJekjeN/uYrNvJXpFOFWcdRP5cMWRtHGBPv0eL+sn/7z7bsO83tzcYH7CtmN9qCW5vAeMGNf7znePEEz6nbR5vNcSdgJ4a1D1cwRthefatH1WQkB88vqF4ASKbyh0xsmikITh4zcBXiZQo1TqLiCIpcZzNYBPlIMo4JpNgN/1xgnKaapuGhkY4kQYmDqzUfVXohqODTHv4xrPQ1NZ2WCqd3yh9WexcYWT4ZKjoPOJhYOVl7E6WVLDO/HdCeA6Gjmrk/iH8dv5xILsMk2TpxuEZvbfW/0t0Sbl5OFsyxg== x-ms-office365-filtering-correlation-id: 7817b086-48ec-4d8e-5c25-08d46fc6ffd2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DB5PR07MB1478; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:DB5PR07MB1478; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1478; x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39450400003)(39850400002)(39840400002)(39860400002)(189998001)(2501003)(3660700001)(55016002)(99286003)(2900100001)(9686003)(236005)(6506006)(6306002)(54896002)(2950100002)(3280700002)(6436002)(53546008)(54356999)(50986999)(6116002)(790700001)(5250100002)(5660300001)(7116003)(229853002)(76176999)(3846002)(102836003)(7696004)(38730400002)(53936002)(33656002)(2906002)(86362001)(7736002)(74316002)(8676002)(8936002)(66066001)(6246003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1478; H:DB5PR07MB1480.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB14801454DB2AC75BAA888A9AF73A0DB5PR07MB1480eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 19:26:25.0674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1478 Archived-At: Subject: Re: [MMUSIC] Question regarding RFC 6871 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, 20 Mar 2017 19:26:30 -0000 --_000_DB5PR07MB14801454DB2AC75BAA888A9AF73A0DB5PR07MB1480eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For those parameters / attributes that are specification required, the simp= lest mechanism of gaining registration is for someone from ITU (either the = secretariat or the rapporteur - who does it is up to the process in ITU) to= register the parameters directly with IANA, quoting the ITU-T recommendati= on as the specification. The only required involvement of IETF will be by designated experts called = in by IANA to review against registration requirements for that table. Keith From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Edler Franz Sent: 19 March 2017 15:54 To: mmusic@ietf.org Subject: [MMUSIC] Question regarding RFC 6871 Dear experts, We are actually struggling with voiceband data (ITU-T recommendation V.152)= support. I recognize that V.152 assumes some SDP parameters/attributes like "vbd", "= maxmptime" and "pmft" which are not officially registered at IANA. What is the status of support of this V.152 specific parameters/attributes? Is there any acticity towards support of IETF about this? Best regards Franz Edler Technology Voice Core A1 Telekom Austria AG Lassallestra=DFe 9 1020 Wien M +43 664 3459781 T +43 50 664 35704 @ franz.edler@A1telekom.at --_000_DB5PR07MB14801454DB2AC75BAA888A9AF73A0DB5PR07MB1480eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For those parameters / attribut= es that are specification required, the simplest mechanism of gaining regis= tration is for someone from ITU (either the secretariat or the rapporteur &= #8211; who does it is up to the process in ITU) to register the parameters directly with IANA, quoting the ITU-T reco= mmendation as the specification.

 

The only required involvement o= f IETF will be by designated experts called in by IANA to review against re= gistration requirements for that table.

 

Keith

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Edler Franz
Sent: 19 March 2017 15:54
To: mmusic@ietf.org
Subject: [MMUSIC] Question regarding RFC 6871

 

Dear experts,<= /span>

 <= /p>

We are actually strugg= ling with voiceband data (ITU-T recommendation V.152) support.
I recognize that V.152 assumes some SDP parameters/attributes like “v= bd”, “maxmptime” and “pmft” which are not off= icially registered at IANA.

What is the status of = support of this V.152 specific parameters/attributes?
Is there any acticity towards support of IETF about this?

Best regards

 <= /p>

<= span lang=3D"DE-AT" style=3D"font-size:8.0pt;line-height:105%;font-family:&= quot;Verdana",sans-serif;color:black;mso-fareast-language:DE-AT">Franz= Edler
Technology
Voice Core

A1 Telekom Austria AG
Lassallestra=DFe 9 1020 Wien
M   +43 664 3459781
T   +43 50 664 35704
@   franz.edler@A1telekom.at

 

--_000_DB5PR07MB14801454DB2AC75BAA888A9AF73A0DB5PR07MB1480eurp_-- From nobody Mon Mar 20 15:01:03 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 8B6BB126DFB; Mon, 20 Mar 2017 15:00:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.2 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, mmusic@ietf.org, The IESG , fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-sctp-sdp@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <149004725256.25098.8286370813018427917.idtracker@ietfa.amsl.com> Date: Mon, 20 Mar 2017 15:00:52 -0700 Archived-At: Subject: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.' to Proposed Standard (draft-ietf-mmusic-sctp-sdp-25.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: Mon, 20 Mar 2017 22:00:53 -0000 The IESG has approved the following document: - 'Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.' (draft-ietf-mmusic-sctp-sdp-25.txt) as Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ Technical Summary The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values): 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. Working Group Summary Nothing in particular to note. The document has seen decent WG participation and no particular “roughness” in terms of consensus. Document Quality There are existing implementations of earlier versions of the document and those implementations are expected to be updated. The specification is required in order to use SDP for negotiating WebRTC data channels and hence is expected to see significant vendor adoption. MIB Doctor, etc. review is Not Applicable. A TSV-ART review would be helpful. Personnel Flemming Andreasen is the Document Shepherd Ben Campbell is the Area Director. RFC Editor Note Please make the following change in Section 12.2, paragraph 4, 2nd sentence: OLD: “... including switching between UDP to TCP candidate pairs ... ” NEW: “... including switching between UDP and TCP candidate pairs ...” From nobody Fri Mar 24 03:49: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 A2823129466; Fri, 24 Mar 2017 03:49: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 k8NdwE0wSfE8; Fri, 24 Mar 2017 03:49:25 -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 BB36C12940A; Fri, 24 Mar 2017 03:49:24 -0700 (PDT) X-AuditID: c1b4fb3a-0dfff70000003958-f6-58d4f9b274a3 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 5D.C1.14680.2B9F4D85; Fri, 24 Mar 2017 11:49:23 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.319.2; Fri, 24 Mar 2017 11:49:21 +0100 To: Ted Hardie , "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , "mmusic (E-mail)" References: From: Magnus Westerlund Message-ID: Date: Fri, 24 Mar 2017 11:49:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7qO7mn1ciDA7OZrXomMxmMXX5YxaL tf/a2S2urGpktmica+fA6jHl90ZWj52z7rJ7LFnyk8nj4EHGAJYoLpuU1JzMstQifbsEroyV vx+yFzyTqfjx6Q5bA+MJsS5GTg4JAROJpSfOsHcxcnEICaxjlHi2t58JwlnOKLF/2i0mkCph gWiJLVOmsIIkRAQ2M0psedHPCJIQEgiQ+D3jFCuIzSZgIXHzRyMbiM0rYC+x/tt+dhCbRUBV 4uvNQ8wgtqhAjETLkg+MEDWCEidnPmEBsTkFAiXuXHoKtIyDgxmo98HWMpAws4C8RPPW2cwQ q7QlGpo6WCcw8s9C0j0LoWMWko4FjMyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQJD9eCW 31Y7GA8+dzzEKMDBqMTDWzDxUoQQa2JZcWXuIUYJDmYlEV7RFVcihHhTEiurUovy44tKc1KL DzFKc7AoifM67LsQISSQnliSmp2aWpBaBJNl4uCUamBcrf+z3fmTteB+f5GIzn6RqTPyL7o/ Fq26fpdd32rRjZ7WeuMJN79OeseZJeQhNGmZoXO4x22LqqWPXar5bi2qnxduWHy45vHcEx3n tZjuqKdKc7Jze3uIm87/3ij1upg1WqC6SozzU/3nSW1WW50OxfBckfZ5VX404iP3E43k7vVz Jty8JqDEUpyRaKjFXFScCADqvM+ZUQIAAA== Archived-At: Subject: Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B 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, 24 Mar 2017 10:49:27 -0000 Hi, This email is specifically concerning Appendix B and I CC MMUSIC as the text is being transfered to BUNDLE. First Issues that I think needs to be addressed. 1. PT based mapping: If the packet's SSRC is in the incoming SSRC mapping table, check that the packet's PT matches a PT included on the associated "m=" line. If so, route the packet to that associated "m=" line and stop; otherwise drop the packet and stop. I think the text should be clearer on the limitation of PT based mapping versus MID based, that following this algorithm, an SSRC is not possible to move from one media description (m=) to another after the initial mapping. This probably belong to the earlier discussion of PT based mapping, but the above quote is the reason for that limitation. 2. RTCP BYE handling: If the packet is of type BYE, it indicates that the RTP streams referenced in the packet are ending. Therefore, for each SSRC indicated in the packet that is found in the incoming SSRC table, first deliver a copy of the packet to the "m=" line associated with that SSRC, but then remove the entry for that SSRC from the incoming SSRC table. This has been discussed on the list, but I want to reinforce that the more reasonable action is to mark the entry for removal, and then after a short timeout (some seconds), allowing any re-ordered or delayed packet to arrive and be processed, remove the entry. 3. I think it is time that this text is moved into bundle and removed from JSEP document. Then I have a reservation against this text. I call it a reservation as it is something I do not require a text change for, but which I wished was addressed. But at the same time I have been unable to properly engage and work on an updated text that helps address the issue. My reservation is that the text is written from a very RTP/RTCP packet centric way, and from the perspective of a highly integrated implementation. I would much have preferred that it was written in an RTP stream centric way and from the perspective of a modularized RTP stack implementation with some abstract API between the higher layers consuming the RTP streams and handling any RTCP feedback messages. That way the focus could have been on when to create and update the RTP stream to higher layer "m=" association. RTCP handling is unfortunately very dependent on what API model one has, and is therefore tricky to describe as it is dependent on the API, and what it provides versus hides. The risk with the text as it is currently written is that the implementers of WebRTC endpoints that uses generic RTP/RTCP implementation modules may have significant issues with mapping the current text to the API they will see. The second aspect of the text which may be problematic is how future proofing of it in regards to RTCP. If new RTCP feedback messages, Extended Reports (XR) or other new RTCP functionality is introduced it may be challenging to map that to the new messages. However, I thank the authors for especially improving this aspect in regards to RTCP feedback messages. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Mar 24 07:21: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 7272B13147B for ; Fri, 24 Mar 2017 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 R1K-mv-IdLqj for ; Fri, 24 Mar 2017 07:21:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C71A13147F for ; Fri, 24 Mar 2017 07:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6460; q=dns/txt; s=iport; t=1490365265; x=1491574865; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=VZ0Ns9XI/Q2xuur5t4DbbXguqDRr7QbMIRl7DCKrL3w=; b=YZ8EzZnmets9giU+1ibAyDnzGGbqj7acQnrbI0tMri+Kj5hCegzvmDmc adH7Wz/redHAMGEjf7DW8Y4ItmAxDUKdlzAepP85wlrF8FQ9huWLd+2Hi EXKsxJq1YMpHaIAHF9u4f5FA2CoO+eeD600kfIH/7A6HYXVIBp4a+NOEe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDwKtVY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQuNcZFNkBmFMIIOHwEKhS5KAoMmPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WAQEBAwEBbAsQCxgnBycfEQYBDAYCAQGJdg0OrCErihQBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZOggWCaoo5BYkWiBeLLJJLgXyIXoZWiFeGaIQmHziBBDofFUG?= =?us-ascii?q?EH2+BZiQ1iW4BAQE?= X-IronPort-AV: E=Sophos;i="5.36,215,1486425600"; d="scan'208,217";a="214011816" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2017 14:21:04 +0000 Received: from [10.98.149.202] (bxb-fandreas-8819.cisco.com [10.98.149.202]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v2OEL3tW022587; Fri, 24 Mar 2017 14:21:03 GMT To: "Ali C. Begen" , Cullen Jennings References: <5136C735-5EF5-4E4E-A748-B3F1507A5CB4@iii.ca> Cc: mmusic From: Flemming Andreasen Message-ID: Date: Fri, 24 Mar 2017 10:21:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8DFE87773833642BD9EFBE46" Archived-At: Subject: Re: [MMUSIC] References to iana-charset-reg-procedure in 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, 24 Mar 2017 14:21:08 -0000 This is a multi-part message in MIME format. --------------8DFE87773833642BD9EFBE46 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Any further opinions on this (positive or negative) ? Thanks -- Flemming On 3/10/17 8:47 AM, Flemming Andreasen wrote: > > > On 11/23/16 12:17 AM, Ali C. Begen wrote: >> Was there a decision on this during the meeting? I can make the >> change if it has been agreed to. >> > I don't believe we decided on this during the meeting, but it seems > reasonable to me, not least considering that the charset-reg draft > expired quite a while ago. Also, do note, that we are trying to ensure > that RTCWeb does not have any normative dependencies on 4566bis, so > from that point of view, there may not be an issue here. > > Thanks > > -- Flemming > > >> On Wed, Nov 16, 2016 at 5:51 AM, Cullen Jennings > > wrote: >> >> >> draft-ietf-mmusic-rfc4566bis has a normative references to >> draft-iana-charset-reg-procedure. draft-iana-charset-reg is an >> update of RFC2978 and will obsolete RFC2978 when it is published. >> >> When I look at what parts of iana-charset-reg-procedure that >> 4566bis uses, I think it would be perfectly reasonable to instead >> have 4566bis reference RFC2978. >> >> I'd like to propose we make this change so that publication of >> 4566bis is not blocked by iana-charset-reg-procedure >> >> >> _______________________________________________ >> 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 --------------8DFE87773833642BD9EFBE46 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Any further opinions on this (positive or negative) ?

Thanks

-- Flemming

On 3/10/17 8:47 AM, Flemming Andreasen wrote:


On 11/23/16 12:17 AM, Ali C. Begen wrote:
Was there a decision on this during the meeting? I can make the change if it has been agreed to.

I don't believe we decided on this during the meeting, but it seems reasonable to me, not least considering that the charset-reg draft expired quite a while ago. Also, do note, that we are trying to ensure that RTCWeb does not have any normative dependencies on 4566bis, so from that point of view, there may not be an issue here.

Thanks

-- Flemming


On Wed, Nov 16, 2016 at 5:51 AM, Cullen Jennings <fluffy@iii.ca> wrote:

draft-ietf-mmusic-rfc4566bis has a normative references to draft-iana-charset-reg-procedure. draft-iana-charset-reg is an update of RFC2978 and will obsolete RFC2978 when it is published.

When I look at what parts of iana-charset-reg-procedure that 4566bis uses, I think it would be perfectly reasonable to instead have 4566bis reference RFC2978.

I'd like to propose we make this change so that publication of 4566bis is not blocked by iana-charset-reg-procedure


_______________________________________________
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

--------------8DFE87773833642BD9EFBE46-- From nobody Fri Mar 24 10:28: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 AAE2E1297D6 for ; Fri, 24 Mar 2017 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 NB02clc206yb for ; Fri, 24 Mar 2017 10:28:43 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 C3A1B1294AE for ; Fri, 24 Mar 2017 10:19:01 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id r45so7677070qte.3 for ; Fri, 24 Mar 2017 10:19:01 -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=cQJ2c28JsCc14xPONtkOPAiTAYnrSGQSuYR33cAbKxI=; b=AADvp89gIFE9JBn4d5vanC60C9nyNOkjg1xam4yXjwdLvy54aISbagfS3OajtdfCZr 7IV4fK4Wigob0Ft1U7vzZJHDEUMOMID2fbLMTibDxd7d6S2ct3ubvSZW31Tn1vgQVxbN O63LUd+rSzaBh+Dag5EAu19VnUvgh5mimOKDYcc3JYpkg1/Cjw4wyJK1FKGZt8PC+tkt MRlO3l8fQP0/vJTxM5HHsNrKmRSkW9C0QEhw/UaSyMHsIbWJqYusDiRiKyrl434rZm1r a/dog95HVCpbWmJhjiPh1T8b4I7vGxp8gKszu+ckyLxwlQoIdufVnqaJauILMR+G9ITh IA3A== 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=cQJ2c28JsCc14xPONtkOPAiTAYnrSGQSuYR33cAbKxI=; b=MUi+ZzxEavoaibPiyxF/K3rzVD28ZiqTWJEb6RCa3y0Umz/4xp3oF59BI+KoGH9pId yX7RElc7TOQlhhe4WrowxZgiKb2Gp87B+0iXVthRqrjUA/VxfoONCNC7SSxHtfpx8joX qChdI/g9BlX7/6xk3Ach+eeTDZ/WuP1i82VEU6v3Sq3ukz/9v9wZSUARtmCtPdRZiWR8 On7TwwAUxZzGdiNJh6PWAkrM8D+lggvFb8UmRn9aFGfXOaty7SeILn0KqIJj3aBF0bUb kZsEhwroYmiDQnHbR8zwQlMM1KRaAjOaaXBCbSeWuuvPW9L9egxmWZ2zJl5dVKaYCgvF 3Ovg== X-Gm-Message-State: AFeK/H2X+4lDozc0v56Fjvs4uoA1NwljUNTugTC4pmf47Jp8jxeU2UAFMfdPkzvXN1kzqf8ZCf55/oaBfQPWtu2t X-Received: by 10.200.50.112 with SMTP id y45mr8659301qta.75.1490375940694; Fri, 24 Mar 2017 10:19:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Fri, 24 Mar 2017 10:19:00 -0700 (PDT) From: Taylor Brandstetter Date: Fri, 24 Mar 2017 10:19:00 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a11403d68873660054b7d309d Archived-At: Subject: [MMUSIC] "a=extmap" with 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, 24 Mar 2017 17:28:45 -0000 --001a11403d68873660054b7d309d Content-Type: text/plain; charset=UTF-8 Is there any document that defines the general semantics of "a=extmap" when "m=" sections are bundled? I assumed there was a restriction that multiple bundled "m=" sections must not use the same ID to refer to different header extensions, but I haven't found this anywhere. If it's needed, should it go in sdp-mux-attributes, with something similar to "IDENTICAL-PER-PT"? --001a11403d68873660054b7d309d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there any document that defines the general semantics o= f "a=3Dextmap" when "m=3D" sections are bundled? I assu= med there was a restriction that multiple bundled "m=3D" sections= must not use the same ID to refer to different header extensions, but I ha= ven't found this anywhere.

If it's needed, shoul= d it go in sdp-mux-attributes, with something similar to "IDENTICAL-PE= R-PT"?
--001a11403d68873660054b7d309d-- From nobody Fri Mar 24 11:00: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 482F4126DEE for ; Fri, 24 Mar 2017 11:00:24 -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 hoc58fpD9Wb5 for ; Fri, 24 Mar 2017 11:00:22 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 28EA81294C8 for ; Fri, 24 Mar 2017 11:00:22 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id x35so8625414qtc.2 for ; Fri, 24 Mar 2017 11:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=D1n07Tmohoa4MRuknfLxd3c/U8V8Y0wqpBaCrqNR9LA=; b=VIuIx4oJnrYyy9l2TUZHjVD3t+4+S9lK6iMtqQ/z1Z7UHncSAePH/khhurWOwIsrQg 4h0mYebHcICnbu5nNfEXZhoWXoO3K0d+K9/0lL5v7ezwqU0zDgzvIHPOIWVQ7XoJRMGV Z/FTHi1DYFp6eF4Ih1WpY/zc7oyZp5hcvdPz2vTbdCX2YjTJ/c9HgXhYrat2Ui/G0TDx p5ImRqS5zv4z7r2gKdfKAPBdO1DANh0r7byCnbHuXbFvK+iKbiFrpJJRKOBmRuKwBJcz drveq5d6jpH8QEh5+L8u3VZXHZKVOQztrvwK5v6hXZfv88KbaE+MjncUFNsVa9ZD93cL Ov6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=D1n07Tmohoa4MRuknfLxd3c/U8V8Y0wqpBaCrqNR9LA=; b=bzpmaRWhMmJZFlJpKFlVTE3VEvmiOI1XaIg1J7fuEyjmYvV2H2DQiV9u8VDSLyZJo6 +zmZOzE+EYBkhFgZmwle9p71Xf8V/OL19OAldWRqHoEVFUIi/ETvYtcILVR6yLjvYOgp OsxMEYh3tmE3uASKlJUKboVWrQ2OnEE1+TB4yNA63Mhn24ncc70gD4HZz96aNE2HneXp trc2C3hAYhAE03bfYusvQrBArthK5IBvM5vOn88SZaCAU3X2iVKVHPui/E7M0r1HiSBF uliR7NEWSMoURnj5u4Cfpbde+amToh0H4PCH08E+ifhs4YxOB8rR1Be19qC2JuNZ+umV y2ug== X-Gm-Message-State: AFeK/H3C3zq3wlJ4H+A68wSS+9GM5x67qlt+TKjUj4JUI6+AZrL0HSIqR24U2d/5xOoLJyw6fI9UGwAT7Ayj1w== X-Received: by 10.200.48.244 with SMTP id w49mr9357542qta.77.1490378421194; Fri, 24 Mar 2017 11:00:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suhas Nandakumar Date: Fri, 24 Mar 2017 18:00:10 +0000 Message-ID: To: Taylor Brandstetter , mmusic WG Content-Type: multipart/alternative; boundary=001a113f40f46055c9054b7dc464 Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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, 24 Mar 2017 18:00:24 -0000 --001a113f40f46055c9054b7dc464 Content-Type: text/plain; charset=UTF-8 Hi Taylor https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-16#section-5.13 Mux attributes classifies it under SPECIAL category Thanks Suhas On Fri, Mar 24, 2017 at 10:28 AM Taylor Brandstetter wrote: > Is there any document that defines the general semantics of "a=extmap" > when "m=" sections are bundled? I assumed there was a restriction that > multiple bundled "m=" sections must not use the same ID to refer to > different header extensions, but I haven't found this anywhere. > > If it's needed, should it go in sdp-mux-attributes, with something similar > to "IDENTICAL-PER-PT"? > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113f40f46055c9054b7dc464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Taylor


Mux attributes classifies it under SPECIAL cate= gory=C2=A0


Thanks
Suhas= =C2=A0
=C2=A0=C2=A0
On Fri, Ma= r 24, 2017 at 10:28 AM Taylor Brandstetter <deadbeef@google.com> wrote:
Is there any document that defines the = general semantics of "a=3Dextmap" when "m=3D" sections = are bundled? I assumed there was a restriction that multiple bundled "= m=3D" sections must not use the same ID to refer to different header e= xtensions, but I haven't found this anywhere.
<= br class=3D"gmail_msg">
If it's needed, s= hould it go in sdp-mux-attributes, with something similar to "IDENTICA= L-PER-PT"?
_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic
--001a113f40f46055c9054b7dc464-- From nobody Fri Mar 24 11: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 D38901294B1 for ; Fri, 24 Mar 2017 11:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, 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 0LeSl0k013Mb for ; Fri, 24 Mar 2017 11:28:46 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d: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 884F7129488 for ; Fri, 24 Mar 2017 11:28:46 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id f11so9583998qkb.0 for ; Fri, 24 Mar 2017 11:28:46 -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=pKbvrINLH1Ly3CEv5C9JekF9AwuGtyzhbeBqX3XoZoQ=; b=goITT2YS/IJknJI+lmiF1Mv7sdPS5Z9iptwpwO6e/CSSkfT8BmOZ7jJ6qtS0bZSIZl 2u2cS2d6inNFRK4sIcQH3TIyXmgMulGkja9ECLDcwm094gjY2YzuwIEsDkKc0lVXUyFx wXZeOO6mkRMOt8LGaOOsR5zRw75buBv8yw0BUPc35mLifesaQYJ4QJJQkjAMGrg4Nv9I foQ0bQJFXpfZV3QAUkX+rhtChoKzBz7v8RFwMMT1z424qiPHk9Id1cHrnaqoNBLoNROX Rhinzv2NCIWczainfpqmn18HJByPUby+HHAwvh/5d/ZV4xD1Lb6n+rEg1NtPQ6sOmXj0 6kfQ== 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=pKbvrINLH1Ly3CEv5C9JekF9AwuGtyzhbeBqX3XoZoQ=; b=RcqEAemaYTSK83By4fAz3o/CqHy78dKK20OhyV6Ff7rmRGzG7afQnglGiw3OitiIQ7 stPK2KInOZQxQ7qLjP2byJ3ZM3cgXwitE5EjoL5b/2/SG04Zw08kKRZJatyTt04++K5L yq2ywYRmEfLrIVzBgsjVxQw1lzrGnyviT70rWm/KyRlO3VRmqHDtdj3Zfdn50uBDHu7C Wpkh2lxxm4KDc31pND82BVnzOgCSM+jOBVItmRjEALHpyblYC7fvCKdl+xhT6FEtFA++ B5MPDEb5L8USjm6wwwhmw/Eh/Mad5W8HCdaRJWvcwxTz5bEmf3vbO9kwgB9C8K50g4IM hGWQ== X-Gm-Message-State: AFeK/H25oRQ8jQnqbMe9WhtG4fchscAYhKsLwop1tKAFExhatLCNfu4oABGXkcdGEOX3uKS65fhdy6eM9LV2rve7 X-Received: by 10.55.155.141 with SMTP id d135mr2892272qke.75.1490380125556; Fri, 24 Mar 2017 11:28:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Fri, 24 Mar 2017 11:28:45 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Fri, 24 Mar 2017 11:28:45 -0700 Message-ID: To: Suhas Nandakumar Cc: mmusic WG Content-Type: multipart/alternative; boundary=94eb2c07684af72b03054b7e2986 Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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, 24 Mar 2017 18:28:49 -0000 --94eb2c07684af72b03054b7e2986 Content-Type: text/plain; charset=UTF-8 I saw that. Which means that individual documents are responsible for defining how their extensions work with BUNDLE. But something still would need to define the *general* restrictions for using "extmap" with BUNDLE, such as the ID restriction. Or is that just something that's common sense and doesn't need to be specified? On Fri, Mar 24, 2017 at 11:00 AM, Suhas Nandakumar wrote: > Hi Taylor > > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux- > attributes-16#section-5.13 > > Mux attributes classifies it under SPECIAL category > > > Thanks > Suhas > > On Fri, Mar 24, 2017 at 10:28 AM Taylor Brandstetter > wrote: > >> Is there any document that defines the general semantics of "a=extmap" >> when "m=" sections are bundled? I assumed there was a restriction that >> multiple bundled "m=" sections must not use the same ID to refer to >> different header extensions, but I haven't found this anywhere. >> >> If it's needed, should it go in sdp-mux-attributes, with something >> similar to "IDENTICAL-PER-PT"? >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > --94eb2c07684af72b03054b7e2986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I saw that. Which means that individual documents are resp= onsible for defining how their extensions work with BUNDLE.

<= div>But something still would need to define the general restriction= s for using "extmap" with BUNDLE, such as the ID restriction. Or = is that just something that's common sense and doesn't need to be s= pecified?

On Fri, Mar 24, 2017 at 11:00 AM, Suhas Nandakumar &l= t;suhasietf@gmail.= com> wrote:
Hi Taylor<= /div>


Mux attributes classifies it under= SPECIAL category=C2=A0


Thanks
Suhas=C2=A0
=C2=A0=C2=A0
On Fri, Mar 24, 2017 at 10:28 AM Taylor Brandstetter <= deadbeef@google.co= m> wrote:
Is there any document = that defines the general semantics of "a=3Dextmap" when "m= =3D" sections are bundled? I assumed there was a restriction that mult= iple bundled "m=3D" sections must not use the same ID to refer to= different header extensions, but I haven't found this anywhere.

If it's= needed, should it go in sdp-mux-attributes, with something similar to &quo= t;IDENTICAL-PER-PT"?
 _______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ie= tf.org/mailman/listinfo/mmusic

--94eb2c07684af72b03054b7e2986-- From nobody Fri Mar 24 12:39:48 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 A70C71298AF; Fri, 24 Mar 2017 12:39:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Pignataro To: Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149038438654.11890.13127119697139266198@ietfa.amsl.com> Date: Fri, 24 Mar 2017 12:39:46 -0700 Archived-At: Subject: [MMUSIC] Review of draft-ietf-mmusic-dtls-sdp-22 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, 24 Mar 2017 19:39:47 -0000 Reviewer: Carlos Pignataro Review result: Has Nits This document is very comprehensive. Operational Considerations are adequately covered. In reviewing this document, I did find two adjacent issues that I thought useful to comment on: 1. Clarity and Readability of Section 9 I appreciate the explicit OLD/NEW details and specifics on what is changed on the updated RFCs. I wish more documents would do this! However, the way in which this is done is very confusing and not really optimizing clarity and readability. It is an operational issue an implementor not understanding the spec :-) The issue, in my view, is with the labels and markers. Subsections of Section 9.2 do not follow the semantic structure of the document. Instead they are included as follows: " Update to section 5: -------------------- " Which are then followed by OLD/NEW chunks. However, these chunks: * include Section numbers and titles, * do not have extra indentation, and * include only BEGIN marker but not END marker. Like: 9.2. Update to RFC 5763 Update to section 5: -------------------- OLD TEXT: 5. Establishing a Secure Channel [... and then, two pages later ...] NEW TEXT: 5. Establishing a Secure Channel I'd suggest: a. Using Section 9.2.1, 9.2.2, etc. for each change. b. Use more explicit chunk demarkators c. Use beginning and ending markers. 2. The second issue, and likely this was discussed, relates to the use of RFC 4572. A reference to RFC 4572 is Normative, and it is cited within "NEW" text (not only "OLD" text). However RFC 4572 has been Obsoleted by RFC 8122! This is because draft-ietf-mmusic-4572-update published as RFC 8122, which should be updated. But for example, why does NEW text here still points to RFC 4572? --->8--- NEW TEXT: 5. Establishing a Secure Channel The two endpoints in the exchange present their identities as part of the DTLS handshake procedure using certificates. This document uses certificates in the same style as described in "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)" [RFC4572]. --->8--- And why RFC 4572 is Normatively referenced? Thanks, Carlos Pignataro. From nobody Fri Mar 24 14:46:21 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 B452F12999F for ; Fri, 24 Mar 2017 14:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 SQ92FNCmrWbD for ; Fri, 24 Mar 2017 14:46:17 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 7BBA71299B2 for ; Fri, 24 Mar 2017 14:46:17 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id r45so2218483qte.3 for ; Fri, 24 Mar 2017 14:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dXuI/guVECndCPp7ydTtpGJofjj6CaN2TU1VLzZ0u5k=; b=deEIih1KUqehSP9gu60Kmu+BawBYF6LFovVF84L0CpujAJBu/GD8KbD1vKEn3sssCz 1OCbDYv0HoIfyz1Yq8dBGjZtmZMvAQcnngPLH/ebXOtDgnAipaP8n2/hdVtpudZ1p+Yp wQJOjLnXmqWDW3lhPpay5a2wTZU6YG5GQvI8wngtMwAoishdeIlT9hB7axMMK52xn2DE sFGeGYwT+3Nh70g9HfyZo59fVCpwxeVfh3iYWFbJPr9AvP+ULA/qtFRxBz+kX8iCNWtl ARREl6bwDcwjEpvMLfVS88CdmTXvVL+/JO7fa9h5pP/IC46vQP3eLZogwDTjjOmpn4Kl ZrlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dXuI/guVECndCPp7ydTtpGJofjj6CaN2TU1VLzZ0u5k=; b=SoR+mft+PYtYgKmYMlSMepaDZIRdoAQcfAm2WKQ1OOJA2HhA0XoMvDtPs4Y9ILwbPz tRfI+gsxkmwaTDj2n0jES+TnAkENFddTjqf/E14svZSX2iplS5G452a3HSEq+8wmzPbK yV8ig9jiwb/iaMzFz9Lw+WKt25RT65tWm53INEgWHYTm86eB93HZeABzVFPWqR+H1Iaz KD5MAOyRes+16ksx+qilsXPgjq1K25/oMBR5qEkqBJsXMi/qHO0CgWZ+Nm4Pu8K8ulWV ai8d/ANqouwwpqScsTWooFpD3clS0ViE2W8qjmqVRPoROQYdgkU4VRrNkgJgaeyIia17 wEaQ== X-Gm-Message-State: AFeK/H28XQQOHjBUHbGcxUML3Mk7iF2QC9YfiY7PFb+ICbnmRKPHO65uqhRyCcz8eC2hk11CEkygWddgvtM/DKmy X-Received: by 10.237.55.99 with SMTP id i90mr9650051qtb.262.1490391976477; Fri, 24 Mar 2017 14:46:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Fri, 24 Mar 2017 21:46:06 +0000 Message-ID: To: Magnus Westerlund , Ted Hardie , "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , "mmusic (E-mail)" Content-Type: multipart/alternative; boundary=001a1140584e55e37b054b80ec13 Archived-At: Subject: Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B 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, 24 Mar 2017 21:46:20 -0000 --001a1140584e55e37b054b80ec13 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To address your first two issues, I have made two PRs for JSEP: https://github.com/rtcweb-wg/jsep/pull/627 https://github.com/rtcweb-wg/jsep/pull/628 Please take a look and see what you think. On the issue of being a packet-based algorithm, I think the existing text addresses that fairly well: Applications can implement RTP stacks in many different ways. The algorithm below details one way that demultiplexing can be accomplished, but is not meant to be prescriptive about exactly how an RTP stack needs to be implemented. Applications MAY use any algorithm that achieves equivalent results to those described in the algorithm below. On the issue of future extensions of RTCP, I feell confident that the authors of future extensions can write their text in a way that works well with this algorithm if it's necessary. On Fri, Mar 24, 2017 at 3:49 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > This email is specifically concerning Appendix B and I CC MMUSIC as the > text is being transfered to BUNDLE. > > First Issues that I think needs to be addressed. > > 1. PT based mapping: > > If the packet's SSRC is in the incoming SSRC mapping table, check > that the packet's PT matches a PT included on the associated "m=3D= " > line. If so, route the packet to that associated "m=3D" line and > stop; otherwise drop the packet and stop. > > I think the text should be clearer on the limitation of PT based mapping > versus MID based, that following this algorithm, an SSRC is not possible > to move from one media description (m=3D) to another after the initial > mapping. This probably belong to the earlier discussion of PT based > mapping, but the above quote is the reason for that limitation. > > 2. RTCP BYE handling: > > If the packet is of type BYE, it indicates that the RTP streams > referenced in the packet are ending. Therefore, for each SSRC > indicated in the packet that is found in the incoming SSRC table, > first deliver a copy of the packet to the "m=3D" line associated > with that SSRC, but then remove the entry for that SSRC from the > incoming SSRC table. > > This has been discussed on the list, but I want to reinforce that the > more reasonable action is to mark the entry for removal, and then after > a short timeout (some seconds), allowing any re-ordered or delayed > packet to arrive and be processed, remove the entry. > > 3. I think it is time that this text is moved into bundle and removed > from JSEP document. > > > Then I have a reservation against this text. I call it a reservation as > it is something I do not require a text change for, but which I wished > was addressed. But at the same time I have been unable to properly > engage and work on an updated text that helps address the issue. > > My reservation is that the text is written from a very RTP/RTCP packet > centric way, and from the perspective of a highly integrated > implementation. I would much have preferred that it was written in an > RTP stream centric way and from the perspective of a modularized RTP > stack implementation with some abstract API between the higher layers > consuming the RTP streams and handling any RTCP feedback messages. That > way the focus could have been on when to create and update the RTP > stream to higher layer "m=3D" association. RTCP handling is unfortunately > very dependent on what API model one has, and is therefore tricky to > describe as it is dependent on the API, and what it provides versus hides= . > > The risk with the text as it is currently written is that the > implementers of WebRTC endpoints that uses generic RTP/RTCP > implementation modules may have significant issues with mapping the > current text to the API they will see. > > The second aspect of the text which may be problematic is how future > proofing of it in regards to RTCP. If new RTCP feedback messages, > Extended Reports (XR) or other new RTCP functionality is introduced it > may be challenging to map that to the new messages. However, I thank the > authors for especially improving this aspect in regards to RTCP feedback > messages. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087> > F=C3=A4r=C3=B6gatan 6 | 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 > --001a1140584e55e37b054b80ec13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To address your first two issues, I have made two PRs for = JSEP:


https://github.com= /rtcweb-wg/jsep/pull/628


Please= take a look and see what you think.=C2=A0



On the issue of being a packet-based algorithm, I th= ink the existing text addresses that fairly well:

=
=C2=A0 =C2=A0 =C2=A0 Applications can implement RTP stacks in many dif= ferent ways.
=C2=A0 =C2=A0 =C2=A0 The algorithm below details one= way that demultiplexing can be
=C2=A0 =C2=A0 =C2=A0 accomplished= , but is not meant to be prescriptive about exactly
=C2=A0 =C2=A0= =C2=A0 how an RTP stack needs to be implemented. Applications MAY use
=C2=A0 =C2=A0 =C2=A0 any algorithm that achieves equivalent results t= o those described
=C2=A0 =C2=A0 =C2=A0 in the algorithm below.


On the issue of future extensio= ns of RTCP, I feell confident that the authors of future extensions can wri= te their text in a way that works well with this algorithm if it's nece= ssary.

On Fri, M= ar 24, 2017 at 3:49 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
=
Hi,

This email is specifically concerning Appendix B and I CC MMUSIC as the
text is being transfered to BUNDLE.

First Issues that I think needs to be addressed.

1. PT based mapping:

=C2=A0 =C2=A0 =C2=A0 =C2=A0If the packet's SSRC is in the incoming SSRC= mapping table, check
=C2=A0 =C2=A0 =C2=A0 =C2=A0that the packet's PT matches a PT included o= n the associated "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line.=C2=A0 If so, route the packet to that asso= ciated "m=3D" line and
=C2=A0 =C2=A0 =C2=A0 =C2=A0stop; otherwise drop the packet and stop.

I think the text should be clearer on the limitation of PT based mapping versus MID based, that following this algorithm, an SSRC is not possible to move from one media description (m=3D) to another after the initial
mapping. This probably belong to the earlier discussion of PT based
mapping, but the above quote is the reason for that limitation.

2. RTCP BYE handling:

=C2=A0 =C2=A0 If the packet is of type BYE, it indicates that the RTP strea= ms
=C2=A0 =C2=A0 =C2=A0 =C2=A0referenced in the packet are ending.=C2=A0 There= fore, for each SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0indicated in the packet that is found in the inc= oming SSRC table,
=C2=A0 =C2=A0 =C2=A0 =C2=A0first deliver a copy of the packet to the "= m=3D" line associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0with that SSRC, but then remove the entry for th= at SSRC from the
=C2=A0 =C2=A0 =C2=A0 =C2=A0incoming SSRC table.

This has been discussed on the list, but I want to reinforce that the
more reasonable action is to mark the entry for removal, and then after
a short timeout (some seconds), allowing any re-ordered or delayed
packet to arrive and be processed, remove the entry.

3. I think it is time that this text is moved into bundle and removed
from JSEP document.


Then I have a reservation against this text. I call it a reservation as
it is something I do not require a text change for, but which I wished
was addressed. But at the same time I have been unable to properly
engage and work on an updated text that helps address the issue.

My reservation is that the text is written from a very RTP/RTCP packet
centric way, and from the perspective of a highly integrated
implementation. I would much have preferred that it was written in an
RTP stream centric way and from the perspective of a modularized RTP
stack implementation with some abstract API between the higher layers
consuming the RTP streams and handling any RTCP feedback messages. That
way the focus could have been on when to create and update the RTP
stream to higher layer "m=3D" association. RTCP handling is unfor= tunately
very dependent on what API model one has, and is therefore tricky to
describe as it is dependent on the API, and what it provides versus hides.<= br class=3D"gmail_msg">
The risk with the text as it is currently written is that the
implementers of WebRTC endpoints that uses generic RTP/RTCP
implementation modules may have significant issues with mapping the
current text to the API they will see.

The second aspect of the text which may be problematic is how future
proofing of it in regards to RTCP. If new RTCP feedback messages,
Extended Reports (XR) or other new RTCP functionality is introduced it
may be challenging to map that to the new messages. However, I thank the authors for especially improving this aspect in regards to RTCP feedback messages.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericss= on.com
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic
--001a1140584e55e37b054b80ec13-- From nobody Sat Mar 25 13:01: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 AC760127871 for ; Sat, 25 Mar 2017 13:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 B3Fjm6LixMyg for ; Sat, 25 Mar 2017 13:01:49 -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 08A1712422F for ; Sat, 25 Mar 2017 13:01:48 -0700 (PDT) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8EA4F5A81; Sat, 25 Mar 2017 16:01:45 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3F3845938; Sat, 25 Mar 2017 16:01:45 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn3-150.cisco.com ([UNAVAILABLE]. [173.38.117.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Sat, 25 Mar 2017 16:01:45 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D7CE65A9-7F18-4B57-91D1-CF5AFD989265" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> Date: Sat, 25 Mar 2017 14:01:44 -0600 Cc: mmusic , Peter Thatcher Message-Id: <4FB4EBAE-B044-4CB8-B74C-318EAAE88160@iii.ca> References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> To: Flemming Andreasen , Bo Burman X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 25 Mar 2017 20:01:51 -0000 --Apple-Mail=_D7CE65A9-7F18-4B57-91D1-CF5AFD989265 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As one of the co-authors of bundle, could I request some time for myself = and Peter Thatcher to talk about=20 https://github.com/cdh4u/draft-sdp-bundle/pull/28 = (this is the PR to bundle from Appendix B of JSEP) Christer has expected to mention it in his presentation but I think we = need a bit more than a mention and we need to do our best to close out = this issue.=20 Thanks, Cullen=20 > On Mar 10, 2017, at 7:36 AM, Flemming Andreasen = wrote: >=20 > Greetings >=20 > The initial draft agenda for the MMUSIC meeting in Chicago has now = been uploaded to: >=20 > https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00 >=20 > We still have a bit of room on the agenda, so let us know of any = additional agenda requests (before March 15) >=20 > Thanks >=20 > Flemming & Bo >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_D7CE65A9-7F18-4B57-91D1-CF5AFD989265 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

As one of the co-authors = of bundle, could I request some time for myself and Peter Thatcher to = talk about 

https://github.com/cdh4u/draft-sdp-bundle/pull/28

(this is the PR to = bundle from Appendix B of JSEP)

Christer has expected to mention it in = his presentation but I think we need a bit more than a mention and we = need to do our best to close out this issue. 

Thanks, = Cullen 

On = Mar 10, 2017, at 7:36 AM, Flemming Andreasen <fandreas@cisco.com> = wrote:

Greetings

The initial draft = agenda for the MMUSIC meeting in Chicago has now been uploaded to:

   https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00<= /a>

We still have a bit of room on the = agenda, so let us know of any additional agenda requests (before March = 15)

Thanks

=    Flemming & Bo

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

= --Apple-Mail=_D7CE65A9-7F18-4B57-91D1-CF5AFD989265-- From nobody Sat Mar 25 13:12:15 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 01A82127011 for ; Sat, 25 Mar 2017 13:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 M4SbPpUIYMqQ for ; Sat, 25 Mar 2017 13:12:11 -0700 (PDT) Received: from smtp138.dfw.emailsrvr.com (smtp138.dfw.emailsrvr.com [67.192.241.138]) (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 C1DAC12422F for ; Sat, 25 Mar 2017 13:12:11 -0700 (PDT) Received: from smtp18.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id EEB0BC01B1; Sat, 25 Mar 2017 16:12:10 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp18.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id AC5B0C00C9; Sat, 25 Mar 2017 16:12:10 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn3-150.cisco.com ([UNAVAILABLE]. [173.38.117.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Sat, 25 Mar 2017 16:12:10 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_1BFF9604-3E05-47BC-A411-213B536F7E0D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> Date: Sat, 25 Mar 2017 14:12:09 -0600 Cc: mmusic Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 25 Mar 2017 20:12:14 -0000 --Apple-Mail=_1BFF9604-3E05-47BC-A411-213B536F7E0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 13, 2017, at 3:44 PM, Christer Holmberg = wrote: >=20 > My question is: is this something that=E2=80=99s causing problems in = real deployments, and requires a change in the standard?=20 1-800 go fedex. See webrtc requirements documents from many years ago.=20= --Apple-Mail=_1BFF9604-3E05-47BC-A411-213B536F7E0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 13, 2017, at 3:44 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

My question is: is this something = that=E2=80=99s causing problems in real deployments, and requires a = change in the standard? 

1-800 go fedex. See webrtc = requirements documents from many years ago. 
= --Apple-Mail=_1BFF9604-3E05-47BC-A411-213B536F7E0D-- From nobody Sat Mar 25 14:14:55 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 703E9127ABE for ; Sat, 25 Mar 2017 14:14:54 -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 JcO6nwpVN55y for ; Sat, 25 Mar 2017 14:14:52 -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 83F84127BA3 for ; Sat, 25 Mar 2017 14:14:52 -0700 (PDT) X-AuditID: c1b4fb3a-4d72198000003958-b8-58d6ddcafd81 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 0E.F9.14680.ACDD6D85; Sat, 25 Mar 2017 22:14:50 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Sat, 25 Mar 2017 22:14:49 +0100 From: Christer Holmberg To: Cullen Jennings , Flemming Andreasen , Bo Burman CC: mmusic Thread-Topic: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago Thread-Index: AQHSmaunsmsD2FK58kWwtfAH3DpGOqGmASUAgAAk6UA= Date: Sat, 25 Mar 2017 21:14:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB2C59C@ESESSMB109.ericsson.se> References: <47e4d768-9274-d7a5-b4c9-e588ce8ca34e@cisco.com> <4FB4EBAE-B044-4CB8-B74C-318EAAE88160@iii.ca> In-Reply-To: <4FB4EBAE-B044-4CB8-B74C-318EAAE88160@iii.ca> 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_7594FB04B1934943A5C02806D1A2204B4CB2C59CESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7ge6pu9ciDLb161m8v6Br8WH9D0aL qcsfszgwe0z5vZHVY8mSn0wel89/ZAxgjuKySUnNySxLLdK3S+DKWLdrFlvBNLuKA1sfsTQw tpp3MXJySAiYSCyauJG5i5GLQ0hgHaPEwu7f7BDOEkaJlxcfMXYxcnCwCVhIdP/TBmkQESiS eHX/DzuIzSwgIzHjbCMTiC0sYCcxZ9F2dogae4mGjlNMIK0iAlYSKy7Jg4RZBFQlNjy8xgZi 8wr4Smw+tJAFpERIIEficZMGSJgTqHr+i/NgUxgFxCS+n1rDBLFJXOLWk/lMECcLSCzZc54Z whaVePn4HyuErSSx6PZnqPp8ib0nNjJBrBKUODnzCcsERpFZSEbNQlI2C0kZRFxHYsHuT2wQ trbEsoWvmWHsMwceMyGLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGGUHt/y22sF4 8LnjIUYBDkYlHl6DfdcihFgTy4orcw8xSnAwK4nwXqwECvGmJFZWpRblxxeV5qQWH2KU5mBR Eud12HchQkggPbEkNTs1tSC1CCbLxMEp1cDId9T8aWST85bAuRtmdzb8rNM7ekShdFOHVP8R M5n2acna5XFdi1m/Ttz6JHaaUKecx7p92uJdsnZrrpySqMl7mK8t1Zx97LnmrAc3K9sq3OOT V2zU/XVyIov9ZQVh963n3dfcfHZvEUfXjI1nez+8KGg0bTR40trwY9P1r4rvWgU9jx1/3SCj xFKckWioxVxUnAgAILbvgq4CAAA= Archived-At: Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago 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, 25 Mar 2017 21:14:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB2C59CESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have no problem is Cullen wants to cover it. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 25 March 2017 22:02 To: Flemming Andreasen ; Bo Burman Cc: mmusic Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago As one of the co-authors of bundle, could I request some time for myself an= d Peter Thatcher to talk about https://github.com/cdh4u/draft-sdp-bundle/pull/28 (this is the PR to bundle from Appendix B of JSEP) Christer has expected to mention it in his presentation but I think we need= a bit more than a mention and we need to do our best to close out this iss= ue. Thanks, Cullen On Mar 10, 2017, at 7:36 AM, Flemming Andreasen > wrote: Greetings The initial draft agenda for the MMUSIC meeting in Chicago has now been upl= oaded to: https://www.ietf.org/proceedings/98/agenda/agenda-98-mmusic-00 We still have a bit of room on the agenda, so let us know of any additional= agenda requests (before March 15) Thanks Flemming & Bo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_7594FB04B1934943A5C02806D1A2204B4CB2C59CESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I have no = problem is Cullen wants to cover it.

 = ;

Regards,

 = ;

Christer

 

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Cullen Jennings
Sent: 25 March 2017 22:02
To: Flemming Andreasen <fandreas@cisco.com>; Bo Burman <bo.= burman@ericsson.com>
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] MMUSIC Draft Agenda for IETF98 - Chicago<= /o:p>

 

 

As one of the co-authors of bundle, could I request = some time for myself and Peter Thatcher to talk about 

 

 

(this is the PR to bundle from Appendix B of JSEP)

 

Christer has expected to mention it in his presentat= ion but I think we need a bit more than a mention and we need to do our bes= t to close out this issue. 

 

Thanks, Cullen 

 

 

On Mar 10, 2017, at 7:36 AM, Flemming Andreasen <= fandreas@cisco.com> wrote:

 

Greetings

The initial draft agenda for the MMUSIC meeting in Chicago has now been upl= oaded to:

   https://www.ietf.org/proceedings/98/agenda/agenda-98-mmus= ic-00

We still have a bit of room on the agenda, so let us know of any additional= agenda requests (before March 15)

Thanks

   Flemming & Bo

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

 

--_000_7594FB04B1934943A5C02806D1A2204B4CB2C59CESESSMB109erics_-- From nobody Sat Mar 25 18:36: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 A3C031293DB for ; Sat, 25 Mar 2017 18:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 5v7y9aqZMT2k for ; Sat, 25 Mar 2017 18:36:16 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5BB126C83 for ; Sat, 25 Mar 2017 18:36:16 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id u1so13979028wra.2 for ; Sat, 25 Mar 2017 18:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=17Jy7D6rI8zknVx2p+9aJZ4FGtvzwB6qIG8sdTZqLRE=; b=yEXFYfLz+3wxUKLL+2/sbQrvjsq3Gs8qgm7HYpiOd+ANtWHkwvXW5zgftcgwslwNR5 WanfUDB4Zbc05y+PPUWmqRxp7QqYENM4xAcIeebEgHqBWOg3YAuAPplmcYgmWZ2uUwYH OgqYAKPemaYnLwCDki2lMTMSJCljkDGzoEk28/0PGwQw8GqyeJrrvaqEcfDGzknv+VZ6 cN40uKTylWHWFZL/O+h8ZRGvK4bWuR8tjhXjBpCxo14p5Zah3WyJO0AmNG513VRob6b4 0FttGLknk8BMNFZ4q6nMgukGu1i2NxfriyiVWgEgJ2rEPsCMjApladNNo9LFsscJY+eU mE7A== 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=17Jy7D6rI8zknVx2p+9aJZ4FGtvzwB6qIG8sdTZqLRE=; b=stpig9Zo0jKKspC1LXFWDqaQlAoHywvwJ9n66iw1+sf8g0bMk5Vn+PI14ZUqiyIA4N 3dklCiOmm8h36KT3+TRW/bP2B/7MGITUVZHQEYVQt39tKIOQQpnHVG8aWRJKjsjGwgI7 Z3NrojQcCHx86Vt4uLJlQpgT66MtngbUDFWnCO/LlcBHgSe+0zOyobsXy9xaDATmifik oUrIBMXu0ohSZt8YxPgLS1xmCfGbvg1X1W5Uky+Qcoegc3FFVIhZo3BZb4A86V0tXWKQ oesk5tgl2ph2/xIBVj9ssWm1b0PkS9m3Zc953q+5P+qBS0Q6C2NUKiDNaPlAYOZt1j0Y Fz2A== X-Gm-Message-State: AFeK/H0BT0/CFWmK0n8SxObjCcqMNGKlayVOCZVBgov8XLsFqijnvUQGdP1eZfV3QhLZwmb5W1smXIBj3ZQwvQ== X-Received: by 10.223.135.252 with SMTP id c57mr14146930wrc.109.1490492175172; Sat, 25 Mar 2017 18:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Sat, 25 Mar 2017 18:35:54 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 26 Mar 2017 03:35:54 +0200 Message-ID: To: Taylor Brandstetter Cc: Suhas Nandakumar , mmusic WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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: Sun, 26 Mar 2017 01:36:19 -0000 2017-03-24 19:28 GMT+01:00 Taylor Brandstetter : > saw that. Which means that individual documents are responsible for defin= ing > how their extensions work with BUNDLE. > > But something still would need to define the general restrictions for usi= ng > "extmap" with BUNDLE, such as the ID restriction. Or is that just somethi= ng > that's common sense and doesn't need to be specified? https://tools.ietf.org/html/rfc5285#section-6 just mandates that the IDs must be unique within a m=3D section, but at the end, all the WebRC implementations use unique ID values across the entire SDP. There are some RTP extensions, such as http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01, that work at *transport* level (rather than at m=3D section level), but nothing prevents such a spec to work even if its ID is not unique within the m=3D sections. This is, IMHO we don't need a global behavior/requirement for the ID values within bundled m=3D sections. --=20 I=C3=B1aki Baz Castillo From nobody Sun Mar 26 08:45:03 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 8E58712947C; Sun, 26 Mar 2017 08:45:01 -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 5C04osQ4itSy; Sun, 26 Mar 2017 08:45:00 -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 A5C5E129479; Sun, 26 Mar 2017 08:44:59 -0700 (PDT) X-AuditID: c1b4fb30-3dbff7000000628e-eb-58d7e1f7b365 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id D8.29.25230.7F1E7D85; Sun, 26 Mar 2017 17:44:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.339.0; Sun, 26 Mar 2017 17:44:54 +0200 To: Peter Thatcher , Ted Hardie , "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , "mmusic (E-mail)" References: From: Magnus Westerlund Message-ID: Date: Sun, 26 Mar 2017 10:44:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7tO6vh9cjDN5MZ7bomMxmMXX5YxaL a8tfs1qs/dfObnFlVSOzReNcOwc2jym/N7J67Jx1l91jwaZSjyVLfjJ5HDzIGMAaxWWTkpqT WZZapG+XwJXxfc8F9oIjRhXr975mamCcodbFyMkhIWAi0fdxETuILSSwnlHizZv6LkYuIHs5 o8St22/BEsICKRKNN9czgSREBG4xSpyYuoUFouMso0TDxDwQm03AQuLmj0Y2EJtXwF5iUW8H E4jNIqAqsWjNS2YQW1QgRqJlyQdGiBpBiZMzn4DN4RQIlJi94w1YnBlozsz556FseYnmrbOZ IXZpSzQ0dbBOYOSfhaR9FpKWWUhaFjAyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIDN+D W34b7GB8+dzxEKMAB6MSD6/BvmsRQqyJZcWVuYcYJTiYlUR4l1+9HiHEm5JYWZValB9fVJqT WnyIUZqDRUmc13HfhQghgfTEktTs1NSC1CKYLBMHp1QDY7OP/FmbqP28PWYFvV3OCm1Nmbt5 5qYavP6kt2nbHs516/t4RSvPpIjuZiiK89+b/XTTwhsHt+f+ZmoN4V8obHIvr1oyYV670MJz t1/nczxa91ZcpO45k3F6X5NEVWVF0dbop58uy/aEfus23b07e3/COoHNDj1Tarhnzbz2rCUt 6tF0b9ENSizFGYmGWsxFxYkA+pUvrFsCAAA= Archived-At: Subject: Re: [MMUSIC] [rtcweb] Working Group Last Call: draft-ietf-rtcweb-jsep-19.txt - Appendix B 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, 26 Mar 2017 15:45:01 -0000 Den 2017-03-24 kl. 16:46, skrev Peter Thatcher: > To address your first two issues, I have made two PRs for JSEP: > > https://github.com/rtcweb-wg/jsep/pull/627 > > https://github.com/rtcweb-wg/jsep/pull/628 > > > Please take a look and see what you think. > See other thread and on these PRs. > > > On the issue of being a packet-based algorithm, I think the existing > text addresses that fairly well: > > Applications can implement RTP stacks in many different ways. > The algorithm below details one way that demultiplexing can be > accomplished, but is not meant to be prescriptive about exactly > how an RTP stack needs to be implemented. Applications MAY use > any algorithm that achieves equivalent results to those described > in the algorithm below. > Yes, that is what I required for being okay with this. And as I said, I accept that is looks like it does, but I would very much have preferred another way of expressing it, that is RTP stream centric. > > On the issue of future extensions of RTCP, I feell confident that the > authors of future extensions can write their text in a way that works > well with this algorithm if it's necessary. Most likely, but there can clearly be cases which doesn't match existing patterns. And I think part of my issue here is there might exist an expectation that an RTP/RTCP extension also needs to update BUNDLE. Which I think is unfortunate. Cheers Magnus > > On Fri, Mar 24, 2017 at 3:49 AM Magnus Westerlund > > > wrote: > > Hi, > > This email is specifically concerning Appendix B and I CC MMUSIC as the > text is being transfered to BUNDLE. > > First Issues that I think needs to be addressed. > > 1. PT based mapping: > > If the packet's SSRC is in the incoming SSRC mapping table, check > that the packet's PT matches a PT included on the associated "m=" > line. If so, route the packet to that associated "m=" line and > stop; otherwise drop the packet and stop. > > I think the text should be clearer on the limitation of PT based mapping > versus MID based, that following this algorithm, an SSRC is not possible > to move from one media description (m=) to another after the initial > mapping. This probably belong to the earlier discussion of PT based > mapping, but the above quote is the reason for that limitation. > > 2. RTCP BYE handling: > > If the packet is of type BYE, it indicates that the RTP streams > referenced in the packet are ending. Therefore, for each SSRC > indicated in the packet that is found in the incoming SSRC table, > first deliver a copy of the packet to the "m=" line associated > with that SSRC, but then remove the entry for that SSRC from the > incoming SSRC table. > > This has been discussed on the list, but I want to reinforce that the > more reasonable action is to mark the entry for removal, and then after > a short timeout (some seconds), allowing any re-ordered or delayed > packet to arrive and be processed, remove the entry. > > 3. I think it is time that this text is moved into bundle and removed > from JSEP document. > > > Then I have a reservation against this text. I call it a reservation as > it is something I do not require a text change for, but which I wished > was addressed. But at the same time I have been unable to properly > engage and work on an updated text that helps address the issue. > > My reservation is that the text is written from a very RTP/RTCP packet > centric way, and from the perspective of a highly integrated > implementation. I would much have preferred that it was written in an > RTP stream centric way and from the perspective of a modularized RTP > stack implementation with some abstract API between the higher layers > consuming the RTP streams and handling any RTCP feedback messages. That > way the focus could have been on when to create and update the RTP > stream to higher layer "m=" association. RTCP handling is unfortunately > very dependent on what API model one has, and is therefore tricky to > describe as it is dependent on the API, and what it provides versus > hides. > > The risk with the text as it is currently written is that the > implementers of WebRTC endpoints that uses generic RTP/RTCP > implementation modules may have significant issues with mapping the > current text to the API they will see. > > The second aspect of the text which may be problematic is how future > proofing of it in regards to RTCP. If new RTCP feedback messages, > Extended Reports (XR) or other new RTCP functionality is introduced it > may be challenging to map that to the new messages. However, I thank the > authors for especially improving this aspect in regards to RTCP feedback > messages. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | 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 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Sun Mar 26 11:42:02 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 A315D1274D0; Sun, 26 Mar 2017 11:42:01 -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 BR7S-A1Fujil; Sun, 26 Mar 2017 11:42:00 -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 B1174124217; Sun, 26 Mar 2017 11:41:59 -0700 (PDT) X-AuditID: c1b4fb30-3efff7000000628e-35-58d80b757523 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 02.16.25230.57B08D85; Sun, 26 Mar 2017 20:41:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.339.0; Sun, 26 Mar 2017 20:41:56 +0200 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> CC: "rtcweb@ietf.org" , "mmusic (E-mail)" From: Magnus Westerlund Message-ID: <8743844f-3294-ec11-47d5-d642adf5fffc@ericsson.com> Date: Sun, 26 Mar 2017 13:41:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2K7om4Z940Ig5nzOC1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8aEH5vYCg5LVMzfsZqtgXGHcBcj J4eEgInEjpfnGLsYuTiEBNYzSnQ0HWECSQgJLGeU2HNNG8QWFvCSaNs2kRnEFhFQkPj15wQL RMMGVomJW66zgCSYBXwkrmxYxQ5iswlYSNz80cgGYvMK2Ess3tcAZrMIqEr873wHVi8qECPR suQDI0SNoMTJmU+A4hwcnAIOEpvPqEOMtJCYOf88I4QtL9G8dTYzxG3aEg1NHawTGAVmIeme haRlFpKWBYzMqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECA/Tglt8GOxhfPnc8xCjAwajE w2uw71qEEGtiWXFl7iFGCQ5mJRHe3Sw3IoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzOu67ECEk kJ5YkpqdmlqQWgSTZeLglGpgDJkz0cH658oL9v7B1Zsn5th8ORr5kDWBbV6UjFXV1t6DW4/O /8d5TtJy24N0rX3NW54lqb3/X5S91YDd7oO9zG7Bi0suH9m46l3T0Wc7Zvse9Tb9fiRe4PCq Jp2rwesZ9mh6HeIsK6jviSnYcaIy2LCj5KWDAfO+Y++tHkgJn/c2CNFx+bJughJLcUaioRZz UXEiAJhzXntMAgAA Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration 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, 26 Mar 2017 18:42:01 -0000 Hi, I have attempted to address the issue discussed below by reformulating that paragraph to read: When the BUNDLE extension is used, the set of configurations of the security mechanism used in all the bundled media descriptions will need to be compatible for simultaneously use, at least per direction or endpoint. When using SRTP this will be the case, at least for the IETF defined key-management solutions due to their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their classification in [I-D.ietf-mmusic-sdp-mux-attributes]. So, does this work? Cheers Magnus Den 2017-03-14 kl. 03:47, skrev Magnus Westerlund: > Den 2017-03-10 kl. 16:31, skrev Eric Rescorla: >> >> When the BUNDLE extension is used, a single set of security >> credentials over the bundled media descriptions will need to be >> used, >> at least per direction or endpoint. >> >> >> Actually, why does this have to be the case? I mean, we require it, but >> if you have the MID extension, you could easily not do this. >> > > You are correct, this is actually misstating the problem. It is not the > security credentials that need to be a single set. Any SDP level > security configuration used on individual media description MUST be > possible to use when creating a bundle group across the full or a > sub-set of the media description offered as a bundle group. > > This works fine for the below listed ones by following the limiations > indicated in SDP MUX attributes, i.e. transport or identical. But for a > future mechanism that is defined with bundle in mind from the start > could have individual configurations. > >> >> >> When using SRTP this will be the >> case, at least for the IETF defined key-management solutions >> due to >> their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their >> classification in [I-D.ietf-mmusic-sdp-mux-attributes]. >> > > I will have to think on how to re-write this. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 27 00:43: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 612C212949B; Mon, 27 Mar 2017 00:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 hrF-n98k-5Il; Mon, 27 Mar 2017 00:43:08 -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 4B86C129463; Mon, 27 Mar 2017 00:43:08 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id d191so25405478ywe.2; Mon, 27 Mar 2017 00:43:08 -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=mPS8lcSH7pHRAn+YUDZ+BvYETb2lGky+LgtesjZqq6Y=; b=W7zoochEFOQ5gg2kS98hxxbFm9YjOXSX8HwElq/Jt9AanZUhxdibPws9yL+aqUpqWB ydH3K0weuQGuXBzN9tTwodDn4qUu+X0Kj7e8gkQ9QRqimkYaREnZaNDA1l4RMy9svkrU jLyDzFWUgP4qUioO8HonagZpHUVXKqUp8Gow0C3Ceg2gcj2POIqvIFKQ6r1r+KHdahhb HiiVXrcBz/EgTDlrXNUDvgrm6DmPbybWBuWOF4FgIH+UTLmugCWg+IvX75Z+ITfIcQb5 vBGIRVeC64dyyTIjgmi2adUZVSvqjFFFbIDNKnRI0qSqQrKoUBkwLuAu9p9Wb+HI4eZH 66sg== 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=mPS8lcSH7pHRAn+YUDZ+BvYETb2lGky+LgtesjZqq6Y=; b=aoadpdLHBres+1QaomgmdSUHKBPso+d+VtaZpZv7XU9tgkecfQjWY07vnZSgyuJSdM Xr0cUfzaif4+6HSBgx6pjOenmesz/2qh730/guKtlPpqry910bZEw4hhAS2RtxyBgrHL ajS5k39aNZ+bigO5guDHaM4Y2NmW54L/qtkzFnd4vjlfNa7K+0yi1n8jVkWqws57FEEE MwC4kl5C/UluhPoCeYazaYGicCyrtZZfvxmDy0gchssj8XDteUcgMYB6f5WfAJzGNpAC pHPiuH3Qg+TLiRCVHBSBSSlwZCA9/sq9RMjNWkVuc5yvn5jmTaOHctFmJeVwLP0F4je6 lp+Q== X-Gm-Message-State: AFeK/H3+k7WdZxzmI1+9VPibNWG4pmQRDrnZ2c/lYH74S+HNFVULJzPks5GfBhhjhqr3vgoYSIshJ3KrvpHPhw== X-Received: by 10.129.125.5 with SMTP id y5mr15437149ywc.120.1490600587208; Mon, 27 Mar 2017 00:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.73 with HTTP; Mon, 27 Mar 2017 00:43:06 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Mon, 27 Mar 2017 09:43:06 +0200 Message-ID: To: Jonathan Lennox Cc: "Paul E. Jones" , "avtext@ietf.org" , mmusic Content-Type: multipart/alternative; boundary=001a1149364480cfa5054bb17ee0 Archived-At: Subject: Re: [MMUSIC] [avtext] framemarking: add frame size info 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, 27 Mar 2017 07:43:11 -0000 --001a1149364480cfa5054bb17ee0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello again, is there anybody considering this proposal, or nobody see the benefits? Kind regards!! 2016-11-10 15:18 GMT+01:00 Miguel Par=C3=ADs D=C3=ADaz : > Hello, > in the new draft of sdp-simulcast an "RTP Aspect" section [1] has been > added, which explains how the media is handled on RTP level. > > Specifically, In the Media-Switching Mixer section [2] the same thoughts = I > exposed are said: > > This section discusses the behavior in cases where the RTP middlebox > behaves like the Media-Switching Mixer (Section 3.6.2 ) in RTP > Topologies [RFC7667 ]. The funda= mental aspect here is that the media > sources delivered from the middlebox will be the mixer's conceptual > or functional ones. For example, one media source may be the main > speaker in high resolution video, while a number of other media > sources are thumbnails of each participant. > > The above results in that the RTP stream produced by the mixer is one > that switches between a number of received incoming RTP streams for > different media sources and in different simulcast versions. The > mixer selects the media source to be sent as one of the RTP streams, > and then selects among the available simulcast streams for the most > appropriate one. The selection criteria include available bandwidth > on the mixer to receiver path and restrictions based on the > functional usage of the RTP stream delivered to the receiver. An > example of the latter, is that it is unnecessary to forward a full HD > video to a receiver if the display area is just a thumbnail. Thus, > restrictions may exist to not allow some simulcast streams to be > forwarded for some of the mixer's media sources. > > > In our case to provide this feature, currently we have to depay the RTP > packets, and apply different types of parses (depending on the codec) to > read the frame size, which reduces the scalability of the system and hind= er > the implementation a lot. > Because of that, I think that having frame size (width and height) info i= n > the Frame Marking RTP header extension is quite interesting to implement > this kind of use cases in a easy and efficient way (the same that an > audio-level extension header is provided to avoid analysing it in the > middlebox side). > > I am adding MMUSIC group in the thread, because I think that this also > should be discussed in the context of the simulcast case. > > Best!! > > Refs > [1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp- > simulcast-06#section-7.2 > [2] https://tools.ietf.org/html/draft-ietf-mmusic-sdp- > simulcast-06#section-7.2.1 > > > 2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz : > >> I assume that the media distributor has the information from the SDP (it >> performs the SDP negotiation which each "client"), but the point is that >> encoders may change the video size depending on the available bandwidth, >> the complexivity of the video source, etc., unless the sender forces the >> encoders' configuration with a fix frame size... >> >> >> 2016-08-26 19:07 GMT+02:00 Jonathan Lennox : >> >>> (As an individual.) >>> >>> In the latest version of simulcast the media distributor would need the >>> RID values, not the PT values, but the idea is the same =E2=80=94 it ne= eds the SDP. >>> >>> Note that if the media distributor doesn=E2=80=99t have information fro= m the SDP >>> it can=E2=80=99t reliably identify the frame marking header extension a= t all, since >>> header extension IDs are negotiated. So I=E2=80=99m not sure how much b= enefit there >>> is to putting the size in the header extension. >>> >>> That said, if we envision a scenario where encoders might be frequently >>> changing their video size (in response to available network bandwidth, = or >>> the like), it might be useful for encoders to be able to indicate the >>> current size they=E2=80=99re encoding without needing to send updated S= DP all the >>> time. >>> >>> On Aug 26, 2016, at 12:52 PM, Paul E. Jones >>> wrote: >>> >>> Miguel, >>> >>> You make the assumption that the media distributor will not see the SDP= , >>> I suppose. While certainly a valid model, I'll admit that I had person= ally >>> assumed any media forwarding function would see the SDP (or at least be >>> told the PT values and any relevant flow information similar to what RF= C >>> 6236 provides) and would thus know which PT values correspond to what v= ideo >>> resolutions if simulcast is employed. >>> >>> Paul >>> >>> ------ Original Message ------ >>> From: "Miguel Par=C3=ADs D=C3=ADaz" >>> To: avtext@ietf.org >>> Sent: 8/25/2016 10:12:48 AM >>> Subject: [avtext] framemarking: add frame size info >>> >>> Hello, >>> it would be great having frame size (width and height) info in the Fram= e >>> Marking RTP header extension [1]. >>> >>> Why? >>> For example, in the case of using simulcast in an SFU, selecting the >>> stream by the size would ease the application development and improve t= he >>> experience of the users. >>> Application developers don't usually have deep knowledge about media >>> like bitrate, etc., but they know which video size has to be rendered i= n >>> the GUI, which may depend on the client where the app is running: a mob= ile, >>> a PC with a 13"=C2=B7 screen, a PC with 27" screen, etc. >>> >>> In this way and taking a videoconference app as example, if a >>> participant select another participant to be rendered as main video, th= e >>> app could ask the SFU to select the video quality that better matches t= o >>> 800x600 size. >>> >>> What do you think about this idea? >>> >>> Thanks and best regards!! >>> >>> Refs >>> [1] https://tools.ietf.org/html/draft-ietf-avtext-framemarking-02 >>> >>> -- >>> Miguel Par=C3=ADs D=C3=ADaz >>> -----------------------------------------------------------------------= - >>> Computer/Software engineer. >>> Researcher and architect in http://www.kurento.org >>> http://twitter.com/mparisdiaz >>> -----------------------------------------------------------------------= - >>> >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>> >>> >>> >> >> >> -- >> Miguel Par=C3=ADs D=C3=ADaz >> ------------------------------------------------------------------------ >> Computer/Software engineer. >> Researcher and architect in http://www.kurento.org >> http://twitter.com/mparisdiaz >> ------------------------------------------------------------------------ >> > > > > -- > Miguel Par=C3=ADs D=C3=ADaz > ------------------------------------------------------------------------ > Computer/Software engineer. > Researcher and architect in http://www.kurento.org > http://twitter.com/mparisdiaz > ------------------------------------------------------------------------ > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a1149364480cfa5054bb17ee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello again,
is there anybody consideri= ng this proposal, or nobody see the benefits?

Kind regards!!

2016-11-1= 0 15:18 GMT+01:00 Miguel Par=C3=ADs D=C3=ADaz <mparisdiaz@gmail.com= >:
Hello,
in the new draft = of sdp-simulcast an "RTP Aspect" section [1] has been added, whic= h explains how the media is handled on RTP level.

Specifically= , In the Media-Switching Mixer section [2] the same thoughts I exposed are = said:
   This section=
 discusses the behavior in cases where the RTP middlebox
   behaves like the Media-Switching Mixer (=
Section 3.6.2) in RTP
   Topologies [RFC7667].  The fundamental a=
spect here is that the media
   sources delivered from the middlebox will be the mixer's conceptual
   or functional ones.  For example, one media source may be the main
   speaker in high resolution video, while a number of other media
   sources are thumbnails of each participant.

   The above results in that the RTP stream produced by the mixer is one
   that switches between a number of received incoming RTP streams for
   different media sources and in different simulcast versions.  The
   mixer selects the media source to be sent as one of the RTP streams,
   and then selects among the available simulcast streams for the most
   appropriate one.  The selection criteria include available bandwidth
   on the mixer to receiver path and restrictions based on the
   functional usage of the RTP stream delivered to the receiver.  An
   example of the latter, is that it is unnecessary to forward a full HD
   video to a receiver if the display area is just a thumbnail.  Thus,
   restrictions may exist to not allow some simulcast streams to be
   forwarded for some of the mixer's media sources.
=
In our case to provide this feature, currently we have to de= pay the RTP packets, and apply different types of parses (depending on the = codec) to read the frame size, which reduces the scalability of the system = and hinder the implementation a lot.
Because of that, I think= that having frame size (width and height) info in the=20 Frame Marking RTP header extension is quite interesting to implement=20 this kind of use cases in a easy and efficient way (the same that an audio-= level extension header is provided to avoid analysing it in the middlebox s= ide).

I am adding MMUSIC group in the thread, = because I think that this also should be discussed in the context of the si= mulcast case.

Best!!


2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz = <mparisdiaz@gm= ail.com>:
= I assume that the media distributor has the information from the SDP (it pe= rforms the SDP negotiation which each "client"), but the point is= that encoders may change the video size depending on the available bandwid= th, the complexivity of the video source, etc., unless the sender forces th= e encoders' configuration with a fix frame size...


2016-08-26 19:0= 7 GMT+02:00 Jonathan Lennox <jonathan@vidyo.com>:
(As an individual.)

In the latest version of simulcast the media distributor would need th= e RID values, not the PT values, but the idea is the same =E2=80=94 it need= s the SDP.

Note that if the media distributor doesn=E2=80=99t have information fr= om the SDP it can=E2=80=99t reliably identify the frame marking header exte= nsion at all, since header extension IDs are negotiated. So I=E2=80=99m not= sure how much benefit there is to putting the size in the header extension.

That said, if we envision a scenario where encoders might be frequentl= y changing their video size (in response to available network bandwidth, or= the like), it might be useful for encoders to be able to indicate the curr= ent size they=E2=80=99re encoding without needing to send updated SDP all the time.

On Aug 26, 2016, at 12:52 PM, Paul E. Jones <paulej@packetizer.com> wrote:
Miguel,

You make the assumption that the media distributor will not see the SDP, I = suppose.=C2=A0 While certainly a valid model, I'll admit that I had per= sonally assumed any media forwarding function would see the SDP (or at leas= t be told the PT values and any relevant flow information similar to what RFC 6236 provides) and would thus know wh= ich PT values correspond to what video resolutions if simulcast is employed= .

Paul

------ Original Message ------
From: "Miguel Par=C3=ADs D=C3=ADaz" <mparisdiaz@gmail.com>
Sent: 8/25/2016 10:12:48 AM
Subject: [avtext] framemarking: add frame size info

Hello,
it would be great having frame size (width and height) info in the Fra= me Marking RTP header extension [1].

Why?
For example, in the case of using simulcast in an SFU, selecting the s= tream by the size would ease the application development and improve the ex= perience of the users.
Application developers don't usually have deep knowledge about med= ia like bitrate, etc., but they know which video size has to be rendered in= the GUI, which may depend on the client where the app is running: a mobile= , a PC with a 13"=C2=B7 screen, a PC with 27" screen, etc.

In this way and taking a videoconference app as example, if a particip= ant select another participant to be rendered as main video, the app could = ask the SFU to select the video quality that better matches to 800x600 size= .

What do you think about this idea?

Thanks and best regards!!

Refs
[1]=C2=A0https://tools.ietf.org/html/dra= ft-ietf-avtext-framemarking-02

--=C2=A0
Miguel Par=C3=ADs D=C3=ADaz
-----------------------------------------------------------------= -------
Computer/Software engineer.
Researcher and architect in=C2=A0http://www.kurento.org
http://twitter.= com/mparisdiaz
-----------------------------------------------------------------= -------
_______________________________________________<= /span>
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext




--
Miguel Par=C3=ADs D=C3=ADaz
---------------= ---------------------------------------------------------
Comp= uter/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdi= az
------------------------------------------------------------= ------------



--
Miguel Par=C3=ADs D=C3=ADaz
------------------------= ------------------------------------------------
Computer/Soft= ware engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz----------------------------------------------------------------= --------



--
Mi= guel Par=C3=ADs D=C3=ADaz
----------------------------------------------= --------------------------
Computer/Software engineer.
Researcher and= architect in http://w= ww.kurento.org
http://twitter.com/mparisdiaz
-------------------------------= -----------------------------------------
--001a1149364480cfa5054bb17ee0-- From nobody Mon Mar 27 05:41:00 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 A0EE1127449; Mon, 27 Mar 2017 05:40:57 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149061845761.30529.8339066851217214935@ietfa.amsl.com> Date: Mon, 27 Mar 2017 05:40:57 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-12.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: Mon, 27 Mar 2017 12:40: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 of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju (Raju) Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-data-channel-sdpneg-12.txt Pages : 40 Date : 2017-03-27 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 07:21:02 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 2E7C0129557; Mon, 27 Mar 2017 07:21:01 -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 kCteSpZzhYjR; Mon, 27 Mar 2017 07:20:59 -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 C489412942F; Mon, 27 Mar 2017 07:20:58 -0700 (PDT) X-AuditID: c1b4fb25-ccfff70000002d78-01-58d91fc83a6b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id AA.BC.11640.8CF19D85; Mon, 27 Mar 2017 16:20:57 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.339.0; Mon, 27 Mar 2017 16:20:55 +0200 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> <8743844f-3294-ec11-47d5-d642adf5fffc@ericsson.com> CC: "rtcweb@ietf.org" , "mmusic (E-mail)" From: Magnus Westerlund Message-ID: <31bdea76-61b2-9c8f-78ff-0936c4bc2d13@ericsson.com> Date: Mon, 27 Mar 2017 09:20:52 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8743844f-3294-ec11-47d5-d642adf5fffc@ericsson.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM2K7h+5J+ZsRBueW8luseH2O3WLq8scs Fmv/tbM7MHssWfKTyWPy4zbmAKYoLpuU1JzMstQifbsEroy7+5YyFXySqli/4ihLA+MG0S5G Tg4JAROJx90PmbsYuTiEBNYzSpzpO8YC4SxnlLg4ZxMzSJWwQKhE06QeMFtEQEHi158TUEXP WCV2r7/GCJJgFvCRuLJhFTuIzSZgIXHzRyMbiM0rYC+x9NMtMJtFQFVictNVsBpRgRiJliUf GCFqBCVOznzCAmJzCjhITDt0iA1ipoXEzPnnoebLSzRvnQ12hJCAtkRDUwfrBEaBWUjaZyFp mYWkZQEj8ypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwCA9uOW36g7Gy28cDzEKcDAq8fA+ kLoZIcSaWFZcmXuIUYKDWUmE9xs3UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6Ykl qdmpqQWpRTBZJg5OqQZG+4a+s+vltp39+NVaRfDZyaDLGy/Ha3+/smvFYeZeMbUrbZVKLgLH m/mWsa8QClK/I2YvtKlX97WUpbiKAXuaeuS/KXMWvHP58/jFlaY97VKqtyRSJE7XRDjcfCLQ 3ZFpdkmky7Y+Rk44/9jmDbPu8O759eTskrNOWxJi2oLOaK3pN007PP2hEktxRqKhFnNRcSIA 7FaW404CAAA= Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration 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, 27 Mar 2017 14:21:01 -0000 Hi, I have created a PR for the proposed update of the security consideration text. https://github.com/cdh4u/draft-sdp-bundle/pull/30 Cheers Magnus Den 2017-03-26 kl. 13:41, skrev Magnus Westerlund: > Hi, > > I have attempted to address the issue discussed below by reformulating > that paragraph to read: > > When the BUNDLE extension is used, the set of configurations of the > security mechanism used in all the bundled media descriptions will > need to be compatible for simultaneously use, at least per direction > or endpoint. When using SRTP this will be the case, at least for the > IETF defined key-management solutions due to their SDP attributes > (a=crypto, a=fingerprint, a=mikey) and their classification in > [I-D.ietf-mmusic-sdp-mux-attributes]. > > > So, does this work? > > Cheers > > Magnus > > > Den 2017-03-14 kl. 03:47, skrev Magnus Westerlund: >> Den 2017-03-10 kl. 16:31, skrev Eric Rescorla: >>> >>> When the BUNDLE extension is used, a single set of security >>> credentials over the bundled media descriptions will need to be >>> used, >>> at least per direction or endpoint. >>> >>> >>> Actually, why does this have to be the case? I mean, we require it, but >>> if you have the MID extension, you could easily not do this. >>> >> >> You are correct, this is actually misstating the problem. It is not the >> security credentials that need to be a single set. Any SDP level >> security configuration used on individual media description MUST be >> possible to use when creating a bundle group across the full or a >> sub-set of the media description offered as a bundle group. >> >> This works fine for the below listed ones by following the limiations >> indicated in SDP MUX attributes, i.e. transport or identical. But for a >> future mechanism that is defined with bundle in mind from the start >> could have individual configurations. >> >>> >>> >>> When using SRTP this will be the >>> case, at least for the IETF defined key-management solutions >>> due to >>> their SDP attributes (a=crypto, a=fingerprint, a=mikey) and their >>> classification in [I-D.ietf-mmusic-sdp-mux-attributes]. >>> >> >> I will have to think on how to re-write this. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Media Technologies, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > -- Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 27 07:53: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 DB870129712 for ; Mon, 27 Mar 2017 07:53:40 -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 Y-efXvQWvIGx for ; Mon, 27 Mar 2017 07:53:38 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DEEB1296FA for ; Mon, 27 Mar 2017 07:53:38 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id i203so32996800ywc.3 for ; Mon, 27 Mar 2017 07:53:38 -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=tB0fL/rWMok9ZxSFD3E1cZc9iz7/MIAirdLjgjyIhY4=; b=s0anfcrL//TaAKtkvq8T8/7QvrbLDEamBnq2NTT4gUPjr+k8yDhjrgNyWZ/J3dij8+ 4O2vnuhFgWVcL4yBfxOSJcEBx9mltqMWFi7Q2tVs6XSeFgDkBX5r4hvxBJne+RcxZEkt FuMPMGNT5DkJaE2qmIQ9SoudLFfZFJ123vSyyfRPSHgFt0xqWN5KUlnZC55UBrYswVLD x67IBVCm+JM/WG4ZQ44DVFxUytZ+/wPLib/XxB+v8TJSgE3YHeG1JfYASsqzfsIbcKpE u/AS+livmrkrVAL5xa0DflXvslB2exo7eKS2OX6ZXAsf9ap/n5oHP3J/xSQN8GzGHXV8 zSTw== 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=tB0fL/rWMok9ZxSFD3E1cZc9iz7/MIAirdLjgjyIhY4=; b=Dze9VKZbqS7+kT3Fj4VW9IIWRNAtzd4mxAv3aPHFFBJSKZNceSJfsmy7cSSJB4lrg1 jMHZWkeWPSfvJPW578f01SN6LiP/zqkY9a/IAj0JS8I/xU6m2hmEUCpYsstypwy4psQ1 6R5hkfCPvt09/wgW+OrZnwF3JuXCVoGOXc041A5O6H2Y/iKLvH/jD4uHWW0Xvb61jJTP vE7Lp3642R+5yJXEFkiiey8sSI90CkAdkvnOIMgOZcjDZha7pXvVxStG2L63qcC1mLyn n9kMMs0d2doRvSTzBNG2l501OwFUlNuj3VsZr06aqTsGxJSprqWW48q/cyD5vdEQ6kZI sZuA== X-Gm-Message-State: AFeK/H2C1uCZWfDZno2SOBvNbWCy9ODq4HZtwuRYiptcRCph8gk5IKXL7t5gHkWv1tcmteR5jNWIlv05cydl5g== X-Received: by 10.129.172.23 with SMTP id k23mr17674730ywh.337.1490626417246; Mon, 27 Mar 2017 07:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Mon, 27 Mar 2017 07:52:56 -0700 (PDT) In-Reply-To: <8743844f-3294-ec11-47d5-d642adf5fffc@ericsson.com> References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> <8743844f-3294-ec11-47d5-d642adf5fffc@ericsson.com> From: Eric Rescorla Date: Mon, 27 Mar 2017 09:52:56 -0500 Message-ID: To: Magnus Westerlund Cc: "rtcweb@ietf.org" , "mmusic (E-mail)" Content-Type: multipart/alternative; boundary=94eb2c1bae0017f3d7054bb7829b Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration 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, 27 Mar 2017 14:53:41 -0000 --94eb2c1bae0017f3d7054bb7829b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I have attempted to address the issue discussed below by reformulating > that paragraph to read: > > When the BUNDLE extension is used, the set of configurations of the > security mechanism used in all the bundled media descriptions will > need to be compatible for simultaneously use, at least per direction > or endpoint. I'm not sure I understand what "compatible for simultaneously use" means. -Ekr When using SRTP this will be the case, at least for the > IETF defined key-management solutions due to their SDP attributes > (a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) and their classification in > [I-D.ietf-mmusic-sdp-mux-attributes]. > > > So, does this work? > > Cheers > > Magnus > > > > Den 2017-03-14 kl. 03:47, skrev Magnus Westerlund: > >> Den 2017-03-10 kl. 16:31, skrev Eric Rescorla: >> >>> >>> When the BUNDLE extension is used, a single set of security >>> credentials over the bundled media descriptions will need to be >>> used, >>> at least per direction or endpoint. >>> >>> >>> Actually, why does this have to be the case? I mean, we require it, but >>> if you have the MID extension, you could easily not do this. >>> >>> >> You are correct, this is actually misstating the problem. It is not the >> security credentials that need to be a single set. Any SDP level >> security configuration used on individual media description MUST be >> possible to use when creating a bundle group across the full or a >> sub-set of the media description offered as a bundle group. >> >> This works fine for the below listed ones by following the limiations >> indicated in SDP MUX attributes, i.e. transport or identical. But for a >> future mechanism that is defined with bundle in mind from the start >> could have individual configurations. >> >> >>> >>> When using SRTP this will be the >>> case, at least for the IETF defined key-management solutions >>> due to >>> their SDP attributes (a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) an= d their >>> classification in [I-D.ietf-mmusic-sdp-mux-attributes]. >>> >>> >> I will have to think on how to re-write this. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Media Technologies, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c1bae0017f3d7054bb7829b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Hi,

I have attempted to address the issue discussed below by reformulating that= paragraph to read:

=C2=A0 =C2=A0When the BUNDLE extension is used, the set of configurations o= f the
=C2=A0 =C2=A0security mechanism used in all the bundled media descriptions = will
=C2=A0 =C2=A0need to be compatible for simultaneously use, at least per dir= ection
=C2=A0 =C2=A0or endpoint.=C2=A0

I'm no= t sure I understand what "compatible for simultaneously use" mean= s.

-Ekr

When using SRTP this will be the case, at least for the
=C2=A0 =C2=A0IETF defined key-management solutions due to their SDP attribu= tes
=C2=A0 =C2=A0(a=3Dcrypto, a=3Dfingerprint, a=3Dmikey) and their classificat= ion in
=C2=A0 =C2=A0[I-D.ietf-mmusic-sdp-mux-attributes].


 So, does this work?

Cheers

Magnus



Den 2017-03-14 kl. 03:47, skrev Magnus Westerlund:
Den 2017-03-10 kl. 16:31, skrev Eric Rescorla:

=C2=A0 =C2=A0 =C2=A0 =C2=A0When the BUNDLE extension is used, a single set = of security
=C2=A0 =C2=A0 =C2=A0 =C2=A0credentials over the bundled media descriptions = will need to be
used,
=C2=A0 =C2=A0 =C2=A0 =C2=A0at least per direction or endpoint.


Actually, why does this have to be the case? I mean, we require it, but
if you have the MID extension, you could easily not do this.


You are correct, this is actually misstating the problem. It is not the
security credentials that need to be a single set. Any SDP level
security configuration used on individual media description MUST be
possible to use when creating a bundle group across the full or a
sub-set of the media description offered as a bundle group.

This works fine for the below listed ones by following the limiations
indicated in SDP MUX attributes, i.e. transport or identical. But for a
future mechanism that is defined with bundle in mind from the start
could have individual configurations.



=C2=A0 =C2=A0 When using SRTP this will be the
=C2=A0 =C2=A0 =C2=A0 =C2=A0case, at least for the IETF defined key-manageme= nt solutions
due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0their SDP attributes (a=3Dcrypto, a=3Dfingerprin= t, a=3Dmikey) and their
=C2=A0 =C2=A0 =C2=A0 =C2=A0classification in [I-D.ietf-mmusic-sdp-mux-attri= butes].


I will have to think on how to re-write this.

Cheers

Magnus Westerlund

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

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


--

Magnus Westerlund

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


--94eb2c1bae0017f3d7054bb7829b-- From nobody Mon Mar 27 08:10: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 DF870129739; Mon, 27 Mar 2017 08:10:48 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 UKSKk0FVCwQM; Mon, 27 Mar 2017 08:10:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E4B129452; Mon, 27 Mar 2017 08:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35008; q=dns/txt; s=iport; t=1490627445; x=1491837045; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yokPB9x+mOsNyzalEbA86NnY5E47reCOnpbrmu7jk2A=; b=GSfZWNJ1tzUVAMiyEBrlXELO2zkYWggDqKhLwYLLpP8XiRNCSYib//LH fR3R0n9HLwMhQ2dk1d3Jj2bLzX82vrq7R7zZljd3ofz14zlIV2t15lIKe rYukzOErucTn5vRxvAGTiS5jTJ4fbIsS4CQ1BZPgYiwr94ZgR3Utj9Pzf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAQAvKtlY/51dJa1SCgEYAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCbjsrYYELB4NbY4kskU2IF400gg4fAQyCQIJsSgIagns/GAE?= =?us-ascii?q?CAQEBAQEBAWsohRUBAQEBAwEBITIZCwwEAgEIEQMBAQEhBwMCAgIfBgsUCQgCB?= =?us-ascii?q?AENBQkSiVQDFQ6rX4Imhy8NgwMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhk6DZoE?= =?us-ascii?q?JglGBWyQUBwkegkiCXwWJHgeMZ4YVOgGGeocbhDaBfFSBC4cihjSKbQIkhCyEJ?= =?us-ascii?q?QEfOIEEWRVBhB85HYFjdQEBiCaBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,232,1486425600"; d="scan'208,217";a="214964986" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 15:10:43 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2RFAhlD016944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 15:10:44 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 10:10:43 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Mon, 27 Mar 2017 10:10:42 -0500 From: "Mo Zanaty (mzanaty)" To: =?utf-8?B?TWlndWVsIFBhcsOtcyBEw61heg==?= , "Jonathan Lennox" CC: "avtext@ietf.org" , mmusic Thread-Topic: [MMUSIC] [avtext] framemarking: add frame size info Thread-Index: AQHSpwxN7LteRg2zYk6+J0YoGnCPzQ== Date: Mon, 27 Mar 2017 15:10:42 +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.2.170228 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.211.33] Content-Type: multipart/alternative; boundary="_000_D4FEA22D6B914mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] [avtext] framemarking: add frame size info 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, 27 Mar 2017 15:10:49 -0000 --_000_D4FEA22D6B914mzanatyciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlndWVsLA0KDQpUaGlzIHdhcyBkaXNjdXNzZWQgaW4gSUVURiA5NyBkdXJpbmcgdGhlIEFW VEVYVCBzZXNzaW9uIG9uIEZyYW1lIE1hcmtpbmcuDQpTZWUgdGhlIHNsaWRlcyBhbmQgbWludXRl cy4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85Ny9zZXNzaW9uL2F2dGV4 dA0KDQpUaGUgcmVjb21tZW5kZWQgYW5kIGFncmVlZCBzb2x1dGlvbiB3YXMgdG8gdXNlIFJJRCBy YXRoZXIgdGhhbiBhZGQgZnJhbWUgc2l6ZQ0KaW4gdGhlIEZyYW1lIE1hcmtpbmcgaGVhZGVyIGV4 dGVuc2lvbi4NCg0KVGhhbmtzLA0KTW8NCg0KDQpGcm9tOiBtbXVzaWMgPG1tdXNpYy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBN aWd1ZWwgUGFyw61zIETDrWF6IDxtcGFyaXNkaWF6QGdtYWlsLmNvbTxtYWlsdG86bXBhcmlzZGlh ekBnbWFpbC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBNYXJjaCAyNywgMjAxNyBhdCAzOjQzIEFNDQpU bzogSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZp ZHlvLmNvbT4+DQpDYzogImF2dGV4dEBpZXRmLm9yZzxtYWlsdG86YXZ0ZXh0QGlldGYub3JnPiIg PGF2dGV4dEBpZXRmLm9yZzxtYWlsdG86YXZ0ZXh0QGlldGYub3JnPj4sICJtbXVzaWNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gW2F2dGV4dF0gZnJhbWVtYXJraW5n OiBhZGQgZnJhbWUgc2l6ZSBpbmZvDQoNCkhlbGxvIGFnYWluLA0KaXMgdGhlcmUgYW55Ym9keSBj b25zaWRlcmluZyB0aGlzIHByb3Bvc2FsLCBvciBub2JvZHkgc2VlIHRoZSBiZW5lZml0cz8NCg0K S2luZCByZWdhcmRzISENCg0KMjAxNi0xMS0xMCAxNToxOCBHTVQrMDE6MDAgTWlndWVsIFBhcsOt cyBEw61heiA8bXBhcmlzZGlhekBnbWFpbC5jb208bWFpbHRvOm1wYXJpc2RpYXpAZ21haWwuY29t Pj46DQpIZWxsbywNCmluIHRoZSBuZXcgZHJhZnQgb2Ygc2RwLXNpbXVsY2FzdCBhbiAiUlRQIEFz cGVjdCIgc2VjdGlvbiBbMV0gaGFzIGJlZW4gYWRkZWQsIHdoaWNoIGV4cGxhaW5zIGhvdyB0aGUg bWVkaWEgaXMgaGFuZGxlZCBvbiBSVFAgbGV2ZWwuDQoNClNwZWNpZmljYWxseSwgSW4gdGhlIE1l ZGlhLVN3aXRjaGluZyBNaXhlciBzZWN0aW9uIFsyXSB0aGUgc2FtZSB0aG91Z2h0cyBJIGV4cG9z ZWQgYXJlIHNhaWQ6DQoNCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgdGhlIGJlaGF2aW9yIGlu IGNhc2VzIHdoZXJlIHRoZSBSVFAgbWlkZGxlYm94DQogICBiZWhhdmVzIGxpa2UgdGhlIE1lZGlh LVN3aXRjaGluZyBNaXhlciAoU2VjdGlvbiAzLjYuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wNiNzZWN0aW9uLTMuNi4yPikgaW4g UlRQDQogICBUb3BvbG9naWVzIFtSRkM3NjY3PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NjY3Pl0uICBUaGUgZnVuZGFtZW50YWwgYXNwZWN0IGhlcmUgaXMgdGhhdCB0aGUgbWVkaWEN CiAgIHNvdXJjZXMgZGVsaXZlcmVkIGZyb20gdGhlIG1pZGRsZWJveCB3aWxsIGJlIHRoZSBtaXhl cidzIGNvbmNlcHR1YWwNCiAgIG9yIGZ1bmN0aW9uYWwgb25lcy4gIEZvciBleGFtcGxlLCBvbmUg bWVkaWEgc291cmNlIG1heSBiZSB0aGUgbWFpbg0KICAgc3BlYWtlciBpbiBoaWdoIHJlc29sdXRp b24gdmlkZW8sIHdoaWxlIGEgbnVtYmVyIG9mIG90aGVyIG1lZGlhDQogICBzb3VyY2VzIGFyZSB0 aHVtYm5haWxzIG9mIGVhY2ggcGFydGljaXBhbnQuDQoNCiAgIFRoZSBhYm92ZSByZXN1bHRzIGlu IHRoYXQgdGhlIFJUUCBzdHJlYW0gcHJvZHVjZWQgYnkgdGhlIG1peGVyIGlzIG9uZQ0KICAgdGhh dCBzd2l0Y2hlcyBiZXR3ZWVuIGEgbnVtYmVyIG9mIHJlY2VpdmVkIGluY29taW5nIFJUUCBzdHJl YW1zIGZvcg0KICAgZGlmZmVyZW50IG1lZGlhIHNvdXJjZXMgYW5kIGluIGRpZmZlcmVudCBzaW11 bGNhc3QgdmVyc2lvbnMuICBUaGUNCiAgIG1peGVyIHNlbGVjdHMgdGhlIG1lZGlhIHNvdXJjZSB0 byBiZSBzZW50IGFzIG9uZSBvZiB0aGUgUlRQIHN0cmVhbXMsDQogICBhbmQgdGhlbiBzZWxlY3Rz IGFtb25nIHRoZSBhdmFpbGFibGUgc2ltdWxjYXN0IHN0cmVhbXMgZm9yIHRoZSBtb3N0DQogICBh cHByb3ByaWF0ZSBvbmUuICBUaGUgc2VsZWN0aW9uIGNyaXRlcmlhIGluY2x1ZGUgYXZhaWxhYmxl IGJhbmR3aWR0aA0KICAgb24gdGhlIG1peGVyIHRvIHJlY2VpdmVyIHBhdGggYW5kIHJlc3RyaWN0 aW9ucyBiYXNlZCBvbiB0aGUNCiAgIGZ1bmN0aW9uYWwgdXNhZ2Ugb2YgdGhlIFJUUCBzdHJlYW0g ZGVsaXZlcmVkIHRvIHRoZSByZWNlaXZlci4gIEFuDQogICBleGFtcGxlIG9mIHRoZSBsYXR0ZXIs IGlzIHRoYXQgaXQgaXMgdW5uZWNlc3NhcnkgdG8gZm9yd2FyZCBhIGZ1bGwgSEQNCiAgIHZpZGVv IHRvIGEgcmVjZWl2ZXIgaWYgdGhlIGRpc3BsYXkgYXJlYSBpcyBqdXN0IGEgdGh1bWJuYWlsLiAg VGh1cywNCiAgIHJlc3RyaWN0aW9ucyBtYXkgZXhpc3QgdG8gbm90IGFsbG93IHNvbWUgc2ltdWxj YXN0IHN0cmVhbXMgdG8gYmUNCiAgIGZvcndhcmRlZCBmb3Igc29tZSBvZiB0aGUgbWl4ZXIncyBt ZWRpYSBzb3VyY2VzLg0KDQpJbiBvdXIgY2FzZSB0byBwcm92aWRlIHRoaXMgZmVhdHVyZSwgY3Vy cmVudGx5IHdlIGhhdmUgdG8gZGVwYXkgdGhlIFJUUCBwYWNrZXRzLCBhbmQgYXBwbHkgZGlmZmVy ZW50IHR5cGVzIG9mIHBhcnNlcyAoZGVwZW5kaW5nIG9uIHRoZSBjb2RlYykgdG8gcmVhZCB0aGUg ZnJhbWUgc2l6ZSwgd2hpY2ggcmVkdWNlcyB0aGUgc2NhbGFiaWxpdHkgb2YgdGhlIHN5c3RlbSBh bmQgaGluZGVyIHRoZSBpbXBsZW1lbnRhdGlvbiBhIGxvdC4NCkJlY2F1c2Ugb2YgdGhhdCwgSSB0 aGluayB0aGF0IGhhdmluZyBmcmFtZSBzaXplICh3aWR0aCBhbmQgaGVpZ2h0KSBpbmZvIGluIHRo ZSBGcmFtZSBNYXJraW5nIFJUUCBoZWFkZXIgZXh0ZW5zaW9uIGlzIHF1aXRlIGludGVyZXN0aW5n IHRvIGltcGxlbWVudCB0aGlzIGtpbmQgb2YgdXNlIGNhc2VzIGluIGEgZWFzeSBhbmQgZWZmaWNp ZW50IHdheSAodGhlIHNhbWUgdGhhdCBhbiBhdWRpby1sZXZlbCBleHRlbnNpb24gaGVhZGVyIGlz IHByb3ZpZGVkIHRvIGF2b2lkIGFuYWx5c2luZyBpdCBpbiB0aGUgbWlkZGxlYm94IHNpZGUpLg0K DQpJIGFtIGFkZGluZyBNTVVTSUMgZ3JvdXAgaW4gdGhlIHRocmVhZCwgYmVjYXVzZSBJIHRoaW5r IHRoYXQgdGhpcyBhbHNvIHNob3VsZCBiZSBkaXNjdXNzZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhl IHNpbXVsY2FzdCBjYXNlLg0KDQpCZXN0ISENCg0KUmVmcw0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA2I3NlY3Rpb24tNy4y DQpbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1z aW11bGNhc3QtMDYjc2VjdGlvbi03LjIuMQ0KDQoNCjIwMTYtMDgtMzAgMTI6MzcgR01UKzAyOjAw IE1pZ3VlbCBQYXLDrXMgRMOtYXogPG1wYXJpc2RpYXpAZ21haWwuY29tPG1haWx0bzptcGFyaXNk aWF6QGdtYWlsLmNvbT4+Og0KSSBhc3N1bWUgdGhhdCB0aGUgbWVkaWEgZGlzdHJpYnV0b3IgaGFz IHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBTRFAgKGl0IHBlcmZvcm1zIHRoZSBTRFAgbmVnb3Rp YXRpb24gd2hpY2ggZWFjaCAiY2xpZW50IiksIGJ1dCB0aGUgcG9pbnQgaXMgdGhhdCBlbmNvZGVy cyBtYXkgY2hhbmdlIHRoZSB2aWRlbyBzaXplIGRlcGVuZGluZyBvbiB0aGUgYXZhaWxhYmxlIGJh bmR3aWR0aCwgdGhlIGNvbXBsZXhpdml0eSBvZiB0aGUgdmlkZW8gc291cmNlLCBldGMuLCB1bmxl c3MgdGhlIHNlbmRlciBmb3JjZXMgdGhlIGVuY29kZXJzJyBjb25maWd1cmF0aW9uIHdpdGggYSBm aXggZnJhbWUgc2l6ZS4uLg0KDQoNCjIwMTYtMDgtMjYgMTk6MDcgR01UKzAyOjAwIEpvbmF0aGFu IExlbm5veCA8am9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PjoN CihBcyBhbiBpbmRpdmlkdWFsLikNCg0KSW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHNpbXVsY2Fz dCB0aGUgbWVkaWEgZGlzdHJpYnV0b3Igd291bGQgbmVlZCB0aGUgUklEIHZhbHVlcywgbm90IHRo ZSBQVCB2YWx1ZXMsIGJ1dCB0aGUgaWRlYSBpcyB0aGUgc2FtZSDigJQgaXQgbmVlZHMgdGhlIFNE UC4NCg0KTm90ZSB0aGF0IGlmIHRoZSBtZWRpYSBkaXN0cmlidXRvciBkb2VzbuKAmXQgaGF2ZSBp bmZvcm1hdGlvbiBmcm9tIHRoZSBTRFAgaXQgY2Fu4oCZdCByZWxpYWJseSBpZGVudGlmeSB0aGUg ZnJhbWUgbWFya2luZyBoZWFkZXIgZXh0ZW5zaW9uIGF0IGFsbCwgc2luY2UgaGVhZGVyIGV4dGVu c2lvbiBJRHMgYXJlIG5lZ290aWF0ZWQuIFNvIEnigJltIG5vdCBzdXJlIGhvdyBtdWNoIGJlbmVm aXQgdGhlcmUgaXMgdG8gcHV0dGluZyB0aGUgc2l6ZSBpbiB0aGUgaGVhZGVyIGV4dGVuc2lvbi4N Cg0KVGhhdCBzYWlkLCBpZiB3ZSBlbnZpc2lvbiBhIHNjZW5hcmlvIHdoZXJlIGVuY29kZXJzIG1p Z2h0IGJlIGZyZXF1ZW50bHkgY2hhbmdpbmcgdGhlaXIgdmlkZW8gc2l6ZSAoaW4gcmVzcG9uc2Ug dG8gYXZhaWxhYmxlIG5ldHdvcmsgYmFuZHdpZHRoLCBvciB0aGUgbGlrZSksIGl0IG1pZ2h0IGJl IHVzZWZ1bCBmb3IgZW5jb2RlcnMgdG8gYmUgYWJsZSB0byBpbmRpY2F0ZSB0aGUgY3VycmVudCBz aXplIHRoZXnigJlyZSBlbmNvZGluZyB3aXRob3V0IG5lZWRpbmcgdG8gc2VuZCB1cGRhdGVkIFNE UCBhbGwgdGhlIHRpbWUuDQoNCk9uIEF1ZyAyNiwgMjAxNiwgYXQgMTI6NTIgUE0sIFBhdWwgRS4g Sm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNvbTxtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29t Pj4gd3JvdGU6DQoNCk1pZ3VlbCwNCg0KWW91IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUg bWVkaWEgZGlzdHJpYnV0b3Igd2lsbCBub3Qgc2VlIHRoZSBTRFAsIEkgc3VwcG9zZS4gIFdoaWxl IGNlcnRhaW5seSBhIHZhbGlkIG1vZGVsLCBJJ2xsIGFkbWl0IHRoYXQgSSBoYWQgcGVyc29uYWxs eSBhc3N1bWVkIGFueSBtZWRpYSBmb3J3YXJkaW5nIGZ1bmN0aW9uIHdvdWxkIHNlZSB0aGUgU0RQ IChvciBhdCBsZWFzdCBiZSB0b2xkIHRoZSBQVCB2YWx1ZXMgYW5kIGFueSByZWxldmFudCBmbG93 IGluZm9ybWF0aW9uIHNpbWlsYXIgdG8gd2hhdCBSRkMgNjIzNiBwcm92aWRlcykgYW5kIHdvdWxk IHRodXMga25vdyB3aGljaCBQVCB2YWx1ZXMgY29ycmVzcG9uZCB0byB3aGF0IHZpZGVvIHJlc29s dXRpb25zIGlmIHNpbXVsY2FzdCBpcyBlbXBsb3llZC4NCg0KUGF1bA0KDQotLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0NCkZyb206ICJNaWd1ZWwgUGFyw61zIETDrWF6IiA8bXBhcmlzZGlh ekBnbWFpbC5jb208bWFpbHRvOm1wYXJpc2RpYXpAZ21haWwuY29tPj4NClRvOiBhdnRleHRAaWV0 Zi5vcmc8bWFpbHRvOmF2dGV4dEBpZXRmLm9yZz4NClNlbnQ6IDgvMjUvMjAxNiAxMDoxMjo0OCBB TQ0KU3ViamVjdDogW2F2dGV4dF0gZnJhbWVtYXJraW5nOiBhZGQgZnJhbWUgc2l6ZSBpbmZvDQoN CkhlbGxvLA0KaXQgd291bGQgYmUgZ3JlYXQgaGF2aW5nIGZyYW1lIHNpemUgKHdpZHRoIGFuZCBo ZWlnaHQpIGluZm8gaW4gdGhlIEZyYW1lIE1hcmtpbmcgUlRQIGhlYWRlciBleHRlbnNpb24gWzFd Lg0KDQpXaHk/DQpGb3IgZXhhbXBsZSwgaW4gdGhlIGNhc2Ugb2YgdXNpbmcgc2ltdWxjYXN0IGlu IGFuIFNGVSwgc2VsZWN0aW5nIHRoZSBzdHJlYW0gYnkgdGhlIHNpemUgd291bGQgZWFzZSB0aGUg YXBwbGljYXRpb24gZGV2ZWxvcG1lbnQgYW5kIGltcHJvdmUgdGhlIGV4cGVyaWVuY2Ugb2YgdGhl IHVzZXJzLg0KQXBwbGljYXRpb24gZGV2ZWxvcGVycyBkb24ndCB1c3VhbGx5IGhhdmUgZGVlcCBr bm93bGVkZ2UgYWJvdXQgbWVkaWEgbGlrZSBiaXRyYXRlLCBldGMuLCBidXQgdGhleSBrbm93IHdo aWNoIHZpZGVvIHNpemUgaGFzIHRvIGJlIHJlbmRlcmVkIGluIHRoZSBHVUksIHdoaWNoIG1heSBk ZXBlbmQgb24gdGhlIGNsaWVudCB3aGVyZSB0aGUgYXBwIGlzIHJ1bm5pbmc6IGEgbW9iaWxlLCBh IFBDIHdpdGggYSAxMyLCtyBzY3JlZW4sIGEgUEMgd2l0aCAyNyIgc2NyZWVuLCBldGMuDQoNCklu IHRoaXMgd2F5IGFuZCB0YWtpbmcgYSB2aWRlb2NvbmZlcmVuY2UgYXBwIGFzIGV4YW1wbGUsIGlm IGEgcGFydGljaXBhbnQgc2VsZWN0IGFub3RoZXIgcGFydGljaXBhbnQgdG8gYmUgcmVuZGVyZWQg YXMgbWFpbiB2aWRlbywgdGhlIGFwcCBjb3VsZCBhc2sgdGhlIFNGVSB0byBzZWxlY3QgdGhlIHZp ZGVvIHF1YWxpdHkgdGhhdCBiZXR0ZXIgbWF0Y2hlcyB0byA4MDB4NjAwIHNpemUuDQoNCldoYXQg ZG8geW91IHRoaW5rIGFib3V0IHRoaXMgaWRlYT8NCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMh IQ0KDQpSZWZzDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0 ZXh0LWZyYW1lbWFya2luZy0wMg0KDQotLQ0KTWlndWVsIFBhcsOtcyBEw61heg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpDb21wdXRlci9Tb2Z0d2FyZSBlbmdpbmVlci4NClJlc2VhcmNoZXIgYW5kIGFyY2hp dGVjdCBpbiBodHRwOi8vd3d3Lmt1cmVudG8ub3JnPGh0dHA6Ly93d3cua3VyZW50by5vcmcvPg0K aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmF2dGV4dCBtYWlsaW5nIGxp c3QNCmF2dGV4dEBpZXRmLm9yZzxtYWlsdG86YXZ0ZXh0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCg0KDQoNCg0KLS0NCk1pZ3VlbCBQYXLD rXMgRMOtYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuDQpS ZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0cDovL3d3dy5rdXJlbnRvLm9yZw0KaHR0cDov L3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KLS0NCk1pZ3Vl bCBQYXLDrXMgRMOtYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5l ZXIuDQpSZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0cDovL3d3dy5rdXJlbnRvLm9yZw0K aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KLS0N Ck1pZ3VlbCBQYXLDrXMgRMOtYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tcHV0ZXIvU29mdHdhcmUg ZW5naW5lZXIuDQpSZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0cDovL3d3dy5rdXJlbnRv Lm9yZw0KaHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_D4FEA22D6B914mzanatyciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7C7004262ECE84439DB2EF0FD48358D7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGkgTWlndWVsLDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyB3YXMgZGlzY3Vzc2VkIGluIElFVEYg OTcgZHVyaW5nIHRoZSBBVlRFWFQgc2Vzc2lvbiBvbiBGcmFtZSBNYXJraW5nLjwvZGl2Pg0KPGRp dj5TZWUgdGhlIHNsaWRlcyBhbmQgbWludXRlcy48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk3L3Nlc3Npb24vYXZ0ZXh0Ij5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTcvc2Vzc2lvbi9hdnRleHQ8L2E+PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcmVjb21tZW5kZWQgYW5kIGFncmVlZCBzb2x1 dGlvbiB3YXMgdG8gdXNlIFJJRCByYXRoZXIgdGhhbiBhZGQgZnJhbWUgc2l6ZTwvZGl2Pg0KPGRp dj5pbiB0aGUgRnJhbWUgTWFya2luZyBoZWFkZXIgZXh0ZW5zaW9uLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5NbzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQt YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+bW11c2ljICZsdDs8YSBocmVmPSJtYWls dG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIE1pZ3VlbCBQYXLDrXMgRMOtYXogJmx0OzxhIGhyZWY9Im1haWx0bzpt cGFyaXNkaWF6QGdtYWlsLmNvbSI+bXBhcmlzZGlhekBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBNYXJjaCAy NywgMjAxNyBhdCAzOjQzIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+Sm9uYXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5Admlk eW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzphdnRleHRAaWV0 Zi5vcmciPmF2dGV4dEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphdnRl eHRAaWV0Zi5vcmciPmF2dGV4dEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtNTVVTSUNd IFthdnRleHRdIGZyYW1lbWFya2luZzogYWRkIGZyYW1lIHNpemUgaW5mbzxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0K PGRpdj5IZWxsbyBhZ2Fpbiw8YnI+DQo8L2Rpdj4NCmlzIHRoZXJlIGFueWJvZHkgY29uc2lkZXJp bmcgdGhpcyBwcm9wb3NhbCwgb3Igbm9ib2R5IHNlZSB0aGUgYmVuZWZpdHM/PGJyPg0KPGJyPg0K PC9kaXY+DQpLaW5kIHJlZ2FyZHMhITxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE2LTExLTEwIDE1OjE4IEdNVCYj NDM7MDE6MDAgTWlndWVsIFBhcsOtcyBEw61heiA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOm1wYXJpc2RpYXpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXBhcmlzZGlh ekBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj46PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PHNwYW4gY2xhc3M9 Im1fLTU4Nzk0OTg5MzcyODg1ODAxNzZnbWFpbC1nSSI+PC9zcGFuPkhlbGxvLDxicj4NCmluIHRo ZSBuZXcgZHJhZnQgb2Ygc2RwLXNpbXVsY2FzdCBhbiAmcXVvdDtSVFAgQXNwZWN0JnF1b3Q7IHNl Y3Rpb24gWzFdIGhhcyBiZWVuIGFkZGVkLCB3aGljaCBleHBsYWlucyBob3cgdGhlIG1lZGlhIGlz IGhhbmRsZWQgb24gUlRQIGxldmVsLjxicj4NCjxicj4NCjwvZGl2Pg0KU3BlY2lmaWNhbGx5LCBJ biB0aGUgTWVkaWEtU3dpdGNoaW5nIE1peGVyIHNlY3Rpb24gWzJdIHRoZSBzYW1lIHRob3VnaHRz IEkgZXhwb3NlZCBhcmUgc2FpZDo8YnI+DQo8cHJlIGNsYXNzPSJtXy01ODc5NDk4OTM3Mjg4NTgw MTc2Z21haWwtbmV3cGFnZSI+ICAgVGhpcyBzZWN0aW9uIGRpc2N1c3NlcyB0aGUgYmVoYXZpb3Ig aW4gY2FzZXMgd2hlcmUgdGhlIFJUUCBtaWRkbGVib3gNCiAgIGJlaGF2ZXMgbGlrZSB0aGUgTWVk aWEtU3dpdGNoaW5nIE1peGVyICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wNiNzZWN0aW9uLTMuNi4yIiB0YXJnZXQ9 Il9ibGFuayI+U2VjdGlvbiAzLjYuMjwvYT4pIGluIFJUUA0KICAgVG9wb2xvZ2llcyBbPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NjciIHRpdGxlPSImcXVvdDtSVFAg VG9wb2xvZ2llcyZxdW90OyIgdGFyZ2V0PSJfYmxhbmsiPlJGQzc2Njc8L2E+XS4gIFRoZSBmdW5k YW1lbnRhbCBhc3BlY3QgaGVyZSBpcyB0aGF0IHRoZSBtZWRpYQ0KICAgc291cmNlcyBkZWxpdmVy ZWQgZnJvbSB0aGUgbWlkZGxlYm94IHdpbGwgYmUgdGhlIG1peGVyJ3MgY29uY2VwdHVhbA0KICAg b3IgZnVuY3Rpb25hbCBvbmVzLiAgRm9yIGV4YW1wbGUsIG9uZSBtZWRpYSBzb3VyY2UgbWF5IGJl IHRoZSBtYWluDQogICBzcGVha2VyIGluIGhpZ2ggcmVzb2x1dGlvbiB2aWRlbywgd2hpbGUgYSBu dW1iZXIgb2Ygb3RoZXIgbWVkaWENCiAgIHNvdXJjZXMgYXJlIHRodW1ibmFpbHMgb2YgZWFjaCBw YXJ0aWNpcGFudC4NCg0KICAgVGhlIGFib3ZlIHJlc3VsdHMgaW4gdGhhdCB0aGUgUlRQIHN0cmVh bSBwcm9kdWNlZCBieSB0aGUgbWl4ZXIgaXMgb25lDQogICB0aGF0IHN3aXRjaGVzIGJldHdlZW4g YSBudW1iZXIgb2YgcmVjZWl2ZWQgaW5jb21pbmcgUlRQIHN0cmVhbXMgZm9yDQogICBkaWZmZXJl bnQgbWVkaWEgc291cmNlcyBhbmQgaW4gZGlmZmVyZW50IHNpbXVsY2FzdCB2ZXJzaW9ucy4gIFRo ZQ0KICAgbWl4ZXIgc2VsZWN0cyB0aGUgbWVkaWEgc291cmNlIHRvIGJlIHNlbnQgYXMgb25lIG9m IHRoZSBSVFAgc3RyZWFtcywNCiAgIGFuZCB0aGVuIHNlbGVjdHMgYW1vbmcgdGhlIGF2YWlsYWJs ZSBzaW11bGNhc3Qgc3RyZWFtcyBmb3IgdGhlIG1vc3QNCiAgIGFwcHJvcHJpYXRlIG9uZS4gIFRo ZSBzZWxlY3Rpb24gY3JpdGVyaWEgaW5jbHVkZSBhdmFpbGFibGUgYmFuZHdpZHRoDQogICBvbiB0 aGUgbWl4ZXIgdG8gcmVjZWl2ZXIgcGF0aCBhbmQgcmVzdHJpY3Rpb25zIGJhc2VkIG9uIHRoZQ0K ICAgZnVuY3Rpb25hbCB1c2FnZSBvZiB0aGUgUlRQIHN0cmVhbSBkZWxpdmVyZWQgdG8gdGhlIHJl Y2VpdmVyLiAgQW4NCiAgIGV4YW1wbGUgb2YgdGhlIGxhdHRlciwgaXMgdGhhdCBpdCBpcyB1bm5l Y2Vzc2FyeSB0byBmb3J3YXJkIGEgZnVsbCBIRA0KICAgdmlkZW8gdG8gYSByZWNlaXZlciBpZiB0 aGUgZGlzcGxheSBhcmVhIGlzIGp1c3QgYSB0aHVtYm5haWwuICBUaHVzLA0KICAgcmVzdHJpY3Rp b25zIG1heSBleGlzdCB0byBub3QgYWxsb3cgc29tZSBzaW11bGNhc3Qgc3RyZWFtcyB0byBiZQ0K ICAgZm9yd2FyZGVkIGZvciBzb21lIG9mIHRoZSBtaXhlcidzIG1lZGlhIHNvdXJjZXMuPGJyPjwv cHJlPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIG91ciBjYXNlIHRvIHByb3Zp ZGUgdGhpcyBmZWF0dXJlLCBjdXJyZW50bHkgd2UgaGF2ZSB0byBkZXBheSB0aGUgUlRQIHBhY2tl dHMsIGFuZCBhcHBseSBkaWZmZXJlbnQgdHlwZXMgb2YgcGFyc2VzIChkZXBlbmRpbmcgb24gdGhl IGNvZGVjKSB0byByZWFkIHRoZSBmcmFtZSBzaXplLCB3aGljaCByZWR1Y2VzIHRoZSBzY2FsYWJp bGl0eSBvZiB0aGUgc3lzdGVtIGFuZCBoaW5kZXIgdGhlIGltcGxlbWVudGF0aW9uIGEgbG90Ljxi cj4NCjwvZGl2Pg0KPGRpdj5CZWNhdXNlIG9mIHRoYXQsIEkgdGhpbmsgdGhhdCBoYXZpbmcgZnJh bWUgc2l6ZSAod2lkdGggYW5kIGhlaWdodCkgaW5mbyBpbiB0aGUgRnJhbWUgTWFya2luZyBSVFAg aGVhZGVyIGV4dGVuc2lvbiBpcyBxdWl0ZSBpbnRlcmVzdGluZyB0byBpbXBsZW1lbnQgdGhpcyBr aW5kIG9mIHVzZSBjYXNlcyBpbiBhIGVhc3kgYW5kIGVmZmljaWVudCB3YXkgKHRoZSBzYW1lIHRo YXQgYW4gYXVkaW8tbGV2ZWwgZXh0ZW5zaW9uIGhlYWRlciBpcyBwcm92aWRlZA0KIHRvIGF2b2lk IGFuYWx5c2luZyBpdCBpbiB0aGUgbWlkZGxlYm94IHNpZGUpLjxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+SSBhbSBhZGRpbmcgTU1VU0lDIGdyb3VwIGluIHRoZSB0aHJlYWQs IGJlY2F1c2UgSSB0aGluayB0aGF0IHRoaXMgYWxzbyBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRo ZSBjb250ZXh0IG9mIHRoZSBzaW11bGNhc3QgY2FzZS48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+ QmVzdCEhPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWZzPGJyPg0KWzFd IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1z ZHAtc2ltdWxjYXN0LTA2I3NlY3Rpb24tNy4yIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvPHdicj5kcmFmdC1pZXRmLW1tdXNpYy1zZHAtPHdicj5zaW11bGNh c3QtMDYjc2VjdGlvbi03LjI8L2E+PGJyPg0KWzJdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA2I3NlY3Rpb24tNy4y LjEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC88d2JyPmRy YWZ0LWlldGYtbW11c2ljLXNkcC08d2JyPnNpbXVsY2FzdC0wNiNzZWN0aW9uLTcuMi4xPC9hPjxi cj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8 ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPjIwMTYtMDgtMzAgMTI6MzcgR01UJiM0MzswMjowMCBNaWd1ZWwgUGFy w61zIETDrWF6IDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86bXBhcmlzZGlh ekBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGFyaXNkaWF6QGdtYWlsLmNvbTwvYT4mZ3Q7 PC9zcGFuPjo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXYgZGlyPSJsdHIiPkkgYXNzdW1lIHRoYXQgdGhlIG1lZGlhIGRpc3RyaWJ1dG9yIGhh cyB0aGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgU0RQIChpdCBwZXJmb3JtcyB0aGUgU0RQIG5lZ290 aWF0aW9uIHdoaWNoIGVhY2ggJnF1b3Q7Y2xpZW50JnF1b3Q7KSwgYnV0IHRoZSBwb2ludCBpcyB0 aGF0IGVuY29kZXJzIG1heSBjaGFuZ2UgdGhlIHZpZGVvIHNpemUgZGVwZW5kaW5nIG9uIHRoZSBh dmFpbGFibGUgYmFuZHdpZHRoLCB0aGUgY29tcGxleGl2aXR5IG9mIHRoZQ0KIHZpZGVvIHNvdXJj ZSwgZXRjLiwgdW5sZXNzIHRoZSBzZW5kZXIgZm9yY2VzIHRoZSBlbmNvZGVycycgY29uZmlndXJh dGlvbiB3aXRoIGEgZml4IGZyYW1lIHNpemUuLi48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9Im1fLTU4Nzk0OTg5MzcyODg1ODAxNzZIT0VuWmIiPg0KPGRpdiBjbGFzcz0ibV8tNTg3OTQ5 ODkzNzI4ODU4MDE3Nmg1Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+MjAxNi0wOC0yNiAxOTowNyBHTVQmIzQzOzAyOjAwIEpvbmF0aGFu IExlbm5veCA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZp ZHlvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvbmF0aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7PC9zcGFu Pjo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXY+KEFzIGFuIGluZGl2aWR1YWwu KTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9m IHNpbXVsY2FzdCB0aGUgbWVkaWEgZGlzdHJpYnV0b3Igd291bGQgbmVlZCB0aGUgUklEIHZhbHVl cywgbm90IHRoZSBQVCB2YWx1ZXMsIGJ1dCB0aGUgaWRlYSBpcyB0aGUgc2FtZSDigJQgaXQgbmVl ZHMgdGhlIFNEUC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdGUgdGhhdCBpZiB0 aGUgbWVkaWEgZGlzdHJpYnV0b3IgZG9lc27igJl0IGhhdmUgaW5mb3JtYXRpb24gZnJvbSB0aGUg U0RQIGl0IGNhbuKAmXQgcmVsaWFibHkgaWRlbnRpZnkgdGhlIGZyYW1lIG1hcmtpbmcgaGVhZGVy IGV4dGVuc2lvbiBhdCBhbGwsIHNpbmNlIGhlYWRlciBleHRlbnNpb24gSURzIGFyZSBuZWdvdGlh dGVkLiBTbyBJ4oCZbSBub3Qgc3VyZSBob3cgbXVjaCBiZW5lZml0IHRoZXJlIGlzIHRvIHB1dHRp bmcgdGhlIHNpemUgaW4gdGhlDQogaGVhZGVyIGV4dGVuc2lvbi48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYXQgc2FpZCwgaWYgd2UgZW52aXNpb24gYSBzY2VuYXJpbyB3aGVyZSBl bmNvZGVycyBtaWdodCBiZSBmcmVxdWVudGx5IGNoYW5naW5nIHRoZWlyIHZpZGVvIHNpemUgKGlu IHJlc3BvbnNlIHRvIGF2YWlsYWJsZSBuZXR3b3JrIGJhbmR3aWR0aCwgb3IgdGhlIGxpa2UpLCBp dCBtaWdodCBiZSB1c2VmdWwgZm9yIGVuY29kZXJzIHRvIGJlIGFibGUgdG8gaW5kaWNhdGUgdGhl IGN1cnJlbnQgc2l6ZSB0aGV54oCZcmUgZW5jb2Rpbmcgd2l0aG91dA0KIG5lZWRpbmcgdG8gc2Vu ZCB1cGRhdGVkIFNEUCBhbGwgdGhlIHRpbWUuPC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ibV8tNTg3OTQ5ODkzNzI4ODU4MDE3 Nm1fLTcwODU5MTQ5OTMzMjY5NzEzNjhoNSI+DQo8ZGl2Pk9uIEF1ZyAyNiwgMjAxNiwgYXQgMTI6 NTIgUE0sIFBhdWwgRS4gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXpl ci5jb20iIHRhcmdldD0iX2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9 Im1fLTU4Nzk0OTg5MzcyODg1ODAxNzZtXy03MDg1OTE0OTkzMzI2OTcxMzY4aDUiPg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1h bDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFs O3dvcmQtc3BhY2luZzowcHgiPg0KTWlndWVsLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpu b3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6 MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzow cHgiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQt c2l6ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3Bh Y2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zv cm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQpZb3UgbWFrZSB0 aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBtZWRpYSBkaXN0cmlidXRvciB3aWxsIG5vdCBzZWUgdGhl IFNEUCwgSSBzdXBwb3NlLiZuYnNwOyBXaGlsZSBjZXJ0YWlubHkgYSB2YWxpZCBtb2RlbCwgSSds bCBhZG1pdCB0aGF0IEkgaGFkIHBlcnNvbmFsbHkgYXNzdW1lZCBhbnkgbWVkaWEgZm9yd2FyZGlu ZyBmdW5jdGlvbiB3b3VsZCBzZWUgdGhlIFNEUCAob3IgYXQgbGVhc3QgYmUgdG9sZCB0aGUgUFQg dmFsdWVzIGFuZCBhbnkgcmVsZXZhbnQNCiBmbG93IGluZm9ybWF0aW9uIHNpbWlsYXIgdG8gd2hh dCBSRkMgNjIzNiBwcm92aWRlcykgYW5kIHdvdWxkIHRodXMga25vdyB3aGljaCBQVCB2YWx1ZXMg Y29ycmVzcG9uZCB0byB3aGF0IHZpZGVvIHJlc29sdXRpb25zIGlmIHNpbXVsY2FzdCBpcyBlbXBs b3llZC48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1 cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25l O3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5v cm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9y bWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4+UGF1bDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3Jt YWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4 O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgi Pg0KLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2Vp Z2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWlu ZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFj aW5nOjBweCI+DQpGcm9tOiAmcXVvdDtNaWd1ZWwgUGFyw61zIETDrWF6JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bXBhcmlzZGlhekBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGFyaXNk aWF6QGdtYWlsLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts ZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQpU bzo8c3Bhbj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmF2dGV4dEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmF2dGV4dEBpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWln aHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5k ZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNp bmc6MHB4Ij4NClNlbnQ6IDgvMjUvMjAxNiAxMDoxMjo0OCBBTTwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KU3ViamVjdDogW2F2dGV4dF0gZnJhbWVtYXJraW5nOiBhZGQgZnJhbWUg c2l6ZSBpbmZvPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6 ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2lu Zzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06 bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxl PSJtYXJnaW4tbGVmdDo1cHg7bWFyZ2luLXJpZ2h0OjBweDtwYWRkaW5nLWxlZnQ6MTBweDtwYWRk aW5nLXJpZ2h0OjBweDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29s aWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTttYXJnaW4tdG9wOjNweDtwYWRk aW5nLXRvcDowcHgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj5IZWxsbyw8YnI+DQo8 L2Rpdj4NCjxkaXY+aXQgd291bGQgYmUgZ3JlYXQgaGF2aW5nIGZyYW1lIHNpemUgKHdpZHRoIGFu ZCBoZWlnaHQpIGluZm8gaW4gdGhlIEZyYW1lIE1hcmtpbmcgUlRQIGhlYWRlciBleHRlbnNpb24g WzFdLjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj5XaHk/PGJyPg0KPC9kaXY+DQo8ZGl2PkZvciBl eGFtcGxlLCBpbiB0aGUgY2FzZSBvZiB1c2luZyBzaW11bGNhc3QgaW4gYW4gU0ZVLCBzZWxlY3Rp bmcgdGhlIHN0cmVhbSBieSB0aGUgc2l6ZSB3b3VsZCBlYXNlIHRoZSBhcHBsaWNhdGlvbiBkZXZl bG9wbWVudCBhbmQgaW1wcm92ZSB0aGUgZXhwZXJpZW5jZSBvZiB0aGUgdXNlcnMuPGJyPg0KPC9k aXY+DQo8ZGl2PkFwcGxpY2F0aW9uIGRldmVsb3BlcnMgZG9uJ3QgdXN1YWxseSBoYXZlIGRlZXAg a25vd2xlZGdlIGFib3V0IG1lZGlhIGxpa2UgYml0cmF0ZSwgZXRjLiwgYnV0IHRoZXkga25vdyB3 aGljaCB2aWRlbyBzaXplIGhhcyB0byBiZSByZW5kZXJlZCBpbiB0aGUgR1VJLCB3aGljaCBtYXkg ZGVwZW5kIG9uIHRoZSBjbGllbnQgd2hlcmUgdGhlIGFwcCBpcyBydW5uaW5nOiBhIG1vYmlsZSwg YSBQQyB3aXRoIGEgMTMmcXVvdDvCtyBzY3JlZW4sIGEgUEMgd2l0aA0KIDI3JnF1b3Q7IHNjcmVl biwgZXRjLjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gdGhpcyB3YXkg YW5kIHRha2luZyBhIHZpZGVvY29uZmVyZW5jZSBhcHAgYXMgZXhhbXBsZSwgaWYgYSBwYXJ0aWNp cGFudCBzZWxlY3QgYW5vdGhlciBwYXJ0aWNpcGFudCB0byBiZSByZW5kZXJlZCBhcyBtYWluIHZp ZGVvLCB0aGUgYXBwIGNvdWxkIGFzayB0aGUgU0ZVIHRvIHNlbGVjdCB0aGUgdmlkZW8gcXVhbGl0 eSB0aGF0IGJldHRlciBtYXRjaGVzIHRvIDgwMHg2MDAgc2l6ZS48YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgZG8geW91IHRoaW5rIGFib3V0IHRoaXMgaWRlYT88YnI+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMhITxicj4NCjxi cj4NClJlZnM8YnI+DQpbMV08c3Bhbj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LWZyYW1lbWFya2luZy0wMiIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtPHdicj5sL2RyYWZ0LWlldGYtYXZ0 ZXh0LWZyYW1lbWFya2k8d2JyPm5nLTAyPC9hPg0KPGRpdj4NCjxkaXY+PGJyPg0KLS08c3Bhbj4m bmJzcDs8L3NwYW4+PGJyPg0KPGRpdiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj4N CjxkaXYgZGlyPSJsdHIiPk1pZ3VlbCBQYXLDrXMgRMOtYXo8YnI+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0t LS0tLS0tLS0tPGJyPg0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuPGJyPg0KUmVzZWFyY2hl ciBhbmQgYXJjaGl0ZWN0IGluPHNwYW4+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cu a3VyZW50by5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5rdXJlbnRvLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vbXBhcmlzZGlheiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4t LS0tLS0tLS0tLS08YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWln aHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5k ZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNp bmc6MHB4O2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmUhaW1wb3J0YW50Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXpl OjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5n Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpu b25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2Zsb2F0Om5vbmU7ZGlzcGxh eTppbmxpbmUhaW1wb3J0YW50Ij5hdnRleHQgbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPGEgaHJlZj0ibWFpbHRvOmF2dGV4dEBpZXRmLm9yZyIgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13 ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQt aW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNw YWNpbmc6MHB4IiB0YXJnZXQ9Il9ibGFuayI+YXZ0ZXh0QGlldGYub3JnPC9hPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hdnRleHQiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxNXB4O2Zv bnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0 ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbDx3YnI+aXN0aW5mby9hdnRleHQ8L2E+PC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8YnI+DQo8ZGl2IGNsYXNzPSJtXy01ODc5 NDk4OTM3Mjg4NTgwMTc2bV8tNzA4NTkxNDk5MzMyNjk3MTM2OGdtYWlsX3NpZ25hdHVyZSIgZGF0 YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+DQo8ZGl2IGRpcj0ibHRyIj5NaWd1ZWwgUGFy w61zIETDrWF6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLTxicj4NCkNvbXB1dGVyL1Nv ZnR3YXJlIGVuZ2luZWVyLjxicj4NClJlc2VhcmNoZXIgYW5kIGFyY2hpdGVjdCBpbiA8YSBocmVm PSJodHRwOi8vd3d3Lmt1cmVudG8ub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5rdXJl bnRvLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vbXBhcmlzZGlheiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6PC9hPjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPHdicj4tLS0tLS0tLS0tLS08YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+ DQo8YnI+DQotLSA8YnI+DQo8ZGl2IGNsYXNzPSJtXy01ODc5NDk4OTM3Mjg4NTgwMTc2Z21haWxf c2lnbmF0dXJlIiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj4NCjxkaXYgZGlyPSJs dHIiPk1pZ3VlbCBQYXLDrXMgRMOtYXo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08d2JyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tPGJy Pg0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuPGJyPg0KUmVzZWFyY2hlciBhbmQgYXJjaGl0 ZWN0IGluIDxhIGhyZWY9Imh0dHA6Ly93d3cua3VyZW50by5vcmciIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3Lmt1cmVudG8ub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNv bS9tcGFyaXNkaWF6IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2Rp YXo8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLTxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVy ZSIgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+DQo8ZGl2IGRpcj0ibHRyIj5NaWd1 ZWwgUGFyw61zIETDrWF6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ29tcHV0ZXIvU29mdHdh cmUgZW5naW5lZXIuPGJyPg0KUmVzZWFyY2hlciBhbmQgYXJjaGl0ZWN0IGluIDxhIGhyZWY9Imh0 dHA6Ly93d3cua3VyZW50by5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmt1cmVudG8u b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXo8L2E+PGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv c3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D4FEA22D6B914mzanatyciscocom_-- From nobody Mon Mar 27 08:21: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 031C7128954; Mon, 27 Mar 2017 08:21:37 -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 G0iuSfzw6sEB; Mon, 27 Mar 2017 08: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 C79711243F3; Mon, 27 Mar 2017 08:21:34 -0700 (PDT) X-AuditID: c1b4fb30-7db199800000628e-b6-58d92dfcb5a6 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 0C.8D.25230.CFD29D85; Mon, 27 Mar 2017 17:21:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.339.0; Mon, 27 Mar 2017 17:21:13 +0200 To: Eric Rescorla References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> <8743844f-3294-ec11-47d5-d642adf5fffc@ericsson.com> CC: "rtcweb@ietf.org" , "mmusic (E-mail)" From: Magnus Westerlund Message-ID: Date: Mon, 27 Mar 2017 10:21:09 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM2K7ou5f3ZsRBvf3cFuseH2O3WLq8scs Fmv/tbM7MHssWfKTyWPy4zbmAKYoLpuU1JzMstQifbsErowr356xFzTwVPxdX93AuImzi5GT Q0LARGLP6x/sXYxcHEIC6xklFh6dxQSSEBJYzihxpjkZxBYW8JJo2zaRGcQWEVCQ+PXnBAtE w1o2iUn/W9hBEswCPhJXNqwCs9kELCRu/mhkA7F5Bewl2q9vAbNZBFQl2jY8YQSxRQViJFqW fGCEqBGUODnzCQuIzSkQKNHfvpsJYqaFxMz55xkhbHmJ5q2zmSGO05ZoaOpgncAoMAtJ+ywk LbOQtCxgZF7FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERigB7f8NtjB+PK54yFGAQ5GJR7e B1I3I4RYE8uKK3MPMUpwMCuJ8H7jBgrxpiRWVqUW5ccXleakFh9ilOZgURLnddx3IUJIID2x JDU7NbUgtQgmy8TBKQUM5wOFum0OLX675q47UHk5j/kz5xImqfm311ul22z4+6+yxb3nv9LS R5IrtN273Kc0L44T8z0Ws0NpYtn8eQzeCh/5GTJDRMQn7rB0d64LTUxQtp4SWJ+fdsww4lT1 2Y8OloldSe3cfi63f7z8cYAjJOl+boEQS8bt3hf8cqXC3E68UZ2lSUosxRmJhlrMRcWJANFC oKhMAgAA Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration 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, 27 Mar 2017 15:21:37 -0000 Den 2017-03-27 kl. 09:52, skrev Eric Rescorla: > > > On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund > > > wrote: > > Hi, > > I have attempted to address the issue discussed below by > reformulating that paragraph to read: > > When the BUNDLE extension is used, the set of configurations of the > security mechanism used in all the bundled media descriptions will > need to be compatible for simultaneously use, at least per direction > or endpoint. > > > I'm not sure I understand what "compatible for simultaneously use" means. > That if one have multiple configurations they can co-exist in the same BUNDLED context beging used in parallel. Is this better? When the BUNDLE extension is used, the set of configurations of the security mechanism used in all the bundled media descriptions will need to be compatible so that they can simultaneously used in parallel, at least per direction or endpoint. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Mar 27 09:03: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 0EA0B1297CB for ; Mon, 27 Mar 2017 09:03:15 -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 EC0YLzfejAEA for ; Mon, 27 Mar 2017 09:03:13 -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 1B30C1297CC for ; Mon, 27 Mar 2017 09:03:11 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id i203so34753753ywc.3 for ; Mon, 27 Mar 2017 09:03:11 -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=1JCPy3YH9naBFZblMLrVrgOD+W3VFZClg3CJzABERX4=; b=DZsaSQprbNiUbAYDNAf+/w8PZ7aprOB1MUmuI7YIfjujv4sIy9RD0FzR/+H1E0deHJ HpD2G5b6uVyh8iOADuTauVpBAqGdyK8erfLiqn/qxMNK/diwbwrjNU/o61VTt1n/ujWY Ys7LO0FIJy2ifSS+gQDKEJMRRCV4/0+z6YLl5Lp2Vf9Z4D65rNtMyK1kIAKi3pMzt7YT Cs9SMPnROYltkImau5sYBrDo9URI3zQa41yp1UOdEdlDaSWumCWWWucAomdQBQznmxFh 7pjYORKgwEcLe2+LlImrYj+Do4oJxU/xfjJtFs/0Vph63mNnsuPfV+LQdIn9MXL9xNtM e1zA== 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=1JCPy3YH9naBFZblMLrVrgOD+W3VFZClg3CJzABERX4=; b=TUWTBmdhZtsW1IBS13cGQRDcmmEQ+ZzCxsFEUXkxVr3T/k1iM3VK0KGQwTAbcZCmJ4 xnxqVZOnXmJeIQRVULs8nkTDmJsE6VA4mcqB5NfjpPCpUYYGf1MW1Dd6oVBBV2t6fYHx bM8AJGvL3uof8ae3cQ1nWtQqqcqYWNbWTJ8hcZC7YyVSlCv/WUlTlXlY8+WePxRVNgp5 OhJvq05YF0rPN6b27ht3n8VHqNzrThzOt1PsvLp/ZEdNWa1dgnIM8eyan+JrGBSd5qsU dWGK4I8J38mvx7fkK32mH86WRxD5ISYfIivf0c+PXSVsef7Pf2Lth/FTAI8yOxdzLYDW rIqg== X-Gm-Message-State: AFeK/H21D+cxbnfblcwZHsfpGmtIW0DyNztT227mkqebDmkx3JHv9MZIdS5PRNLczPETvbQxyAP5VNPQmUfg9Q== X-Received: by 10.37.78.195 with SMTP id c186mr16976582ybb.180.1490630590073; Mon, 27 Mar 2017 09:03:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Mon, 27 Mar 2017 09:02:29 -0700 (PDT) In-Reply-To: References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> <8743844f-3294-ec11-47d5-d642adf5fffc@ericsson.com> From: Eric Rescorla Date: Mon, 27 Mar 2017 11:02:29 -0500 Message-ID: To: Magnus Westerlund Cc: "rtcweb@ietf.org" , "mmusic (E-mail)" Content-Type: multipart/alternative; boundary=001a113e88fad07c06054bb87a06 Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration 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, 27 Mar 2017 16:03:15 -0000 --001a113e88fad07c06054bb87a06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable LGTM On Mon, Mar 27, 2017 at 10:21 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-03-27 kl. 09:52, skrev Eric Rescorla: > >> >> >> On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund >> > >> wrote: >> >> Hi, >> >> I have attempted to address the issue discussed below by >> reformulating that paragraph to read: >> >> When the BUNDLE extension is used, the set of configurations of t= he >> security mechanism used in all the bundled media descriptions wil= l >> need to be compatible for simultaneously use, at least per >> direction >> or endpoint. >> >> >> I'm not sure I understand what "compatible for simultaneously use" means= . >> >> > That if one have multiple configurations they can co-exist in the same > BUNDLED context beging used in parallel. Is this better? > > When the BUNDLE extension is used, the set of configurations of the > security mechanism used in all the bundled media descriptions will > need to be compatible so that they can simultaneously used in > parallel, at least per direction or endpoint. > > > > Cheers > > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a113e88fad07c06054bb87a06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
LGTM

On Mon, Mar 27, 2017 at 10:21 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Den 2017-03-27 kl. 09:52, skrev Eric Rescorl= a:


On Sun, Mar 26, 2017 at 1:41 PM, Magnus Westerlund
 <mag= nus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.co= m>>
wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 I have attempted to address the issue discussed below by
=C2=A0 =C2=A0 reformulating that paragraph to read:

=C2=A0 =C2=A0 =C2=A0 =C2=A0When the BUNDLE extension is used, the set of co= nfigurations of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0security mechanism used in all the bundled media= descriptions will
=C2=A0 =C2=A0 =C2=A0 =C2=A0need to be compatible for simultaneously use, at= least per direction
=C2=A0 =C2=A0 =C2=A0 =C2=A0or endpoint.


I'm not sure I understand what "compatible for simultaneously use&= quot; means.


That if one have multiple configurations they can co-exist in the same BUND= LED context beging used in parallel. Is this better?

=C2=A0 =C2=A0When the BUNDLE extension is used, the set of configurations o= f the
=C2=A0 =C2=A0security mechanism used in all the bundled media descriptions = will
 =C2=A0 =C2=A0need to be compatible so that they can simultaneously used in<= br> =C2=A0 =C2=A0parallel, at least per direction or endpoint.



Cheers


Magnus Westerlund

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


--001a113e88fad07c06054bb87a06-- From nobody Mon Mar 27 10:44: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 9A249129442 for ; Mon, 27 Mar 2017 10:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 vYTf_L1z8m6F for ; Mon, 27 Mar 2017 10:44:47 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 634B1129438 for ; Mon, 27 Mar 2017 10:44:47 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id n21so44108217qta.1 for ; Mon, 27 Mar 2017 10:44:47 -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=33Xp8GI6EqowEQzpH/s3C8ndOvAfW25kMjBjFL4yBFY=; b=q/VUDD/xX2+xL62v3Sv3dCl2926L6YF/bDV/Y181VV06h+1UVDHJQv+0dC4ACOYzQ8 kgXxVnFmsIZD1Rxs1YyRnOTGDFxpCyQIwRM/5oPXzmz7R9S6y1Rv0MFDijNbO1/ymAPh /ZDLs7iPOUX85rILwwzAgQDf8KVcdFOn4sogBDg/omTkUezVJRMjLrYYQkE1HQg1fdu4 +/U/Up8C1UwKCeXdq1/3JGVQYAZPOwlBgBnO3MTTAXjOxghyqVl141llOfxoZPVqLSzY dXAykJWEQE2gE+FM7ra5bgGicmZWRqIYBIOXsAxZyHel80uZ/hsXBn93FzVbTFUbAMZO /+dA== 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=33Xp8GI6EqowEQzpH/s3C8ndOvAfW25kMjBjFL4yBFY=; b=BOSJHAROr3+wVYgIZ0ldzmg4/d3ZkNerYD5PzgiT5FBzF3NFogEJvRFzFuM1vMcc57 omzHDVzwV3stP1sK+WH3P1CX33pTjrEl+bePKOw58ipiHdt+7a1297CzSu7xhphniWfw LbMtIb3s9wzryRvRTjq/fI8srjONyHXyqRZT01d2wQo4x3DpC1nKwzYbjxgwYoyQmeBg 0yZdGUU4yei7mcJk5J3RAVgU7Uoy5+OK2kdYNRMk1ksADicvnlSLBNZ0gXuU618F5o61 QbQ6nv5K7lRl6fyBp22xmVVLHau89y3r7hGaf3pHUseTPfANtZDMejo4Wv6a8hcfnESy yxEg== X-Gm-Message-State: AFeK/H378pnog7k+8nieSEy2kJdsis5/AoQIHqFBjeSvLbbvgEX16mtgO9PQQMfLZ1a6PIkZnjisgx4zQVljcyev X-Received: by 10.237.55.229 with SMTP id j92mr20983043qtb.43.1490636686149; Mon, 27 Mar 2017 10:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Mon, 27 Mar 2017 10:44:45 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Mon, 27 Mar 2017 10:44:45 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Suhas Nandakumar , mmusic WG Content-Type: multipart/alternative; boundary=001a113d1a742b449f054bb9e6c7 Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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: Mon, 27 Mar 2017 17:44:50 -0000 --001a113d1a742b449f054bb9e6c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If extension IDs aren't unique across bundled m=3D sections, then on receiving a packet, an implementation may need to determine which m=3D section it's "associated" with before knowing how to interpret the extension IDs. To do this, it may need to use the MID, which means that at a minimum, the MID extension must be using a unique ID. But this increases implementation complexity without much benefit (the benefit being that by sharing IDs, you could more easily avoid running out of spare IDs). So I'd be in favor of just requiring them to be unique. On Sat, Mar 25, 2017 at 6:35 PM, I=C3=B1aki Baz Castillo wr= ote: > 2017-03-24 19:28 GMT+01:00 Taylor Brandstetter : > > saw that. Which means that individual documents are responsible for > defining > > how their extensions work with BUNDLE. > > > > But something still would need to define the general restrictions for > using > > "extmap" with BUNDLE, such as the ID restriction. Or is that just > something > > that's common sense and doesn't need to be specified? > > https://tools.ietf.org/html/rfc5285#section-6 just mandates that the > IDs must be unique within a m=3D section, but at the end, all the WebRC > implementations use unique ID values across the entire SDP. > > There are some RTP extensions, such as > http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01= , > that work at *transport* level (rather than at m=3D section level), but > nothing prevents such a spec to work even if its ID is not unique > within the m=3D sections. > > This is, IMHO we don't need a global behavior/requirement for the ID > values within bundled m=3D sections. > > > -- > I=C3=B1aki Baz Castillo > > --001a113d1a742b449f054bb9e6c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If extension IDs aren't unique across bundled m=3D sec= tions, then on receiving a packet, an implementation may need to determine = which m=3D section it's "associated" with before knowing how = to interpret the extension IDs. To do this, it may need to use the MID, whi= ch means that at a minimum, the MID extension must be using a unique ID.
But this increases implementation complexity without much = benefit (the benefit being that by sharing IDs, you could more easily avoid= running out of spare IDs). So I'd be in favor of just requiring them t= o be unique.

On Sat, Mar 25, 2017 at 6:35 PM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2017-03-24 19:28 GMT+01:00 Taylor Brandstetter <deadbeef@google.com>:
> saw that. Which means that individual documents are responsible for de= fining
> how their extensions work with BUNDLE.
>
> But something still would need to define the general restrictions for = using
> "extmap" with BUNDLE, such as the ID restriction. Or is that= just something
> that's common sense and doesn't need to be specified?

https://tools.ietf.org/html/rfc5285#section= -6 just mandates that the
IDs must be unique within a m=3D section, but at the end, all the WebRC
implementations use unique ID values across the entire SDP.

There are some RTP extensions, such as
http://www.ietf.org/id/draf= t-holmer-rmcat-transport-wide-cc-extensions-01,
that work at *transport* level (rather than at m=3D section level), but
nothing prevents such a spec to work even if its ID is not unique
within the m=3D sections.

This is, IMHO we don't need a global behavior/requirement for the ID values within bundled m=3D sections.


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

--001a113d1a742b449f054bb9e6c7-- From nobody Mon Mar 27 10:55: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 7A0621294BE for ; Mon, 27 Mar 2017 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tFbDUbb9lDxV for ; Mon, 27 Mar 2017 10:55:29 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 82168129482 for ; Mon, 27 Mar 2017 10:55:29 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id a5so36043881oth.1 for ; Mon, 27 Mar 2017 10:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=xSENfN2hANUoabUZ4D+1zTPLSHHNnG8WPN5xHm4Q6g4=; b=jU0d5lpTqi6CTaSoSAzdWOWTB5WktcEfbHNPdroH6iCtzilrPT4Ueg2WTYsSTWw+o3 9tAcw6WFBBESjnzVcRtcF4U/T3cfBVTqH1aHgsIuiYHXHGDZgusjxIqHxfQfBwAfWzPw Cd659uiABMenUroOnMvyIy3duHcIP45+0Ewiz8ct8nxzWc3FpqjjDZVmDIzzMmtqnkOb rgT8/JnjaFRfXtS9UL/eTEevBQ7z0hk60yMZ0YbRIlEF1kJAZ1xajcoQpVvnnN0XU3FT CzHdTGaD97jrz1JE/M+JHlAOitiQ3h8cUgXYgb8OC1XqxPvKFD2SyLkY59bJ/BOohe2n tIbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xSENfN2hANUoabUZ4D+1zTPLSHHNnG8WPN5xHm4Q6g4=; b=fsIU//PBR6g1FxrYkChlYwRlBJ5Ou2+zyVw8udBsyt36MZ6KygTDTgdlaNml8j/8jr O0w9M/QZus82WLBNHuS5c2hK4e6ThbFR6HOBFFGG0em99cqWXkT/Onmki8fGmcrsueXJ ad6RnXA6awLmE2Uk+Urhlmio+cwcKFhpdWs7+KNVpIAs5T0XOR101H6VrDFnaTt80alh Tr3qrizQAtX1UfF2gixFkp9oLyvnfAp9IWbTB7xaxcpLhV/XuoCahp49fO0v/USOk1av vnfw9gFqjeVXdF0+MeUUSJF5In5chsIIOPiSDVL7Qwuajza4uoaee9m9z426JZAOAdr+ AR4w== X-Gm-Message-State: AFeK/H0/0TGiCzmrPzIwLjcESNqE9+zcQSr3ywLZypnG2WA/t29U1ZQiOLA+8QrfuPTOOQ== X-Received: by 10.157.83.27 with SMTP id g27mr13282466oth.160.1490637328931; Mon, 27 Mar 2017 10:55:28 -0700 (PDT) Received: from ?IPv6:2602:301:77fd:e0a0:5477:d084:ffa2:a5de? ([2602:301:77fd:e0a0:5477:d084:ffa2:a5de]) by smtp.googlemail.com with ESMTPSA id s133sm512814oif.9.2017.03.27.10.55.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 10:55:28 -0700 (PDT) To: Taylor Brandstetter , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= References: Cc: mmusic WG From: Byron Campen Message-ID: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> Date: Mon, 27 Mar 2017 12:55:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8927E9E8F87B8C979DC8E983" Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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: Mon, 27 Mar 2017 17:55:31 -0000 This is a multi-part message in MIME format. --------------8927E9E8F87B8C979DC8E983 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Would it not be sufficient to specify that bundled m-sections not use the same identifier for _different_ extensions? There's no ambiguity if you use '3' for mid on every m-section, which is the kind of thing implementations do now anyway. Best regards, Byron Campen On 3/27/17 12:44 PM, Taylor Brandstetter wrote: > If extension IDs aren't unique across bundled m= sections, then on > receiving a packet, an implementation may need to determine which m= > section it's "associated" with before knowing how to interpret the > extension IDs. To do this, it may need to use the MID, which means > that at a minimum, the MID extension must be using a unique ID. > > But this increases implementation complexity without much benefit (the > benefit being that by sharing IDs, you could more easily avoid running > out of spare IDs). So I'd be in favor of just requiring them to be unique. > > On Sat, Mar 25, 2017 at 6:35 PM, Iaki Baz Castillo > wrote: > > 2017-03-24 19:28 GMT+01:00 Taylor Brandstetter > >: > > saw that. Which means that individual documents are responsible > for defining > > how their extensions work with BUNDLE. > > > > But something still would need to define the general > restrictions for using > > "extmap" with BUNDLE, such as the ID restriction. Or is that > just something > > that's common sense and doesn't need to be specified? > > https://tools.ietf.org/html/rfc5285#section-6 > just mandates that the > IDs must be unique within a m= section, but at the end, all the WebRC > implementations use unique ID values across the entire SDP. > > There are some RTP extensions, such as > http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 > , > that work at *transport* level (rather than at m= section level), but > nothing prevents such a spec to work even if its ID is not unique > within the m= sections. > > This is, IMHO we don't need a global behavior/requirement for the ID > values within bundled m= sections. > > > -- > Iaki Baz Castillo > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------8927E9E8F87B8C979DC8E983 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Would it not be sufficient to specify that bundled m-sections not use the same identifier for _different_ extensions? There's no ambiguity if you use '3' for mid on every m-section, which is the kind of thing implementations do now anyway.

Best regards,
Byron Campen

On 3/27/17 12:44 PM, Taylor Brandstetter wrote:
If extension IDs aren't unique across bundled m= sections, then on receiving a packet, an implementation may need to determine which m= section it's "associated" with before knowing how to interpret the extension IDs. To do this, it may need to use the MID, which means that at a minimum, the MID extension must be using a unique ID.

But this increases implementation complexity without much benefit (the benefit being that by sharing IDs, you could more easily avoid running out of spare IDs). So I'd be in favor of just requiring them to be unique.

On Sat, Mar 25, 2017 at 6:35 PM, Iaki Baz Castillo <ibc@aliax.net> wrote:
2017-03-24 19:28 GMT+01:00 Taylor Brandstetter <deadbeef@google.com>:
> saw that. Which means that individual documents are responsible for defining
> how their extensions work with BUNDLE.
>
> But something still would need to define the general restrictions for using
> "extmap" with BUNDLE, such as the ID restriction. Or is that just something
> that's common sense and doesn't need to be specified?

https://tools.ietf.org/html/rfc5285#section-6 just mandates that the
IDs must be unique within a m= section, but at the end, all the WebRC
implementations use unique ID values across the entire SDP.

There are some RTP extensions, such as
http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01,
that work at *transport* level (rather than at m= section level), but
nothing prevents such a spec to work even if its ID is not unique
within the m= sections.

This is, IMHO we don't need a global behavior/requirement for the ID
values within bundled m= sections.


--
Iaki Baz Castillo
<ibc@aliax.net>



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


--------------8927E9E8F87B8C979DC8E983-- From nobody Mon Mar 27 11:09: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 B1FFE126CE8 for ; Mon, 27 Mar 2017 11:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, 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 5oEtQ_UoM2fG for ; Mon, 27 Mar 2017 11:09:34 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (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 28A7712943C for ; Mon, 27 Mar 2017 11:09:33 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-09v.sys.comcast.net with SMTP id sZ4ZcN8SQQe9csZ5AcxJwJ; Mon, 27 Mar 2017 18:09:32 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-01v.sys.comcast.net with SMTP id sZ59cJEM6Y10NsZ59cdb5y; Mon, 27 Mar 2017 18:09:32 +0000 From: Paul Kyzivat To: draft-ietf-mmusic-dtls-sdp.all@ietf.org Cc: General Area Review Team , IETF MMUSIC WG Message-ID: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> Date: Mon, 27 Mar 2017 14:09:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfFinlWj36mVuxQyL/fQvW8tq/nPfcoyb65Qgxi7Wdq9TRplqxaDqf17vYQTqPnB+eA1rNulTmVMfBFeoBZLnzk+Hr1V3NRO9iHxPg5F3o8iEmQX7HGSX SXhGxtVhJTHuODWbI7N2cyOmbM5UhS7e02CuZZWmonb1ti3ztCxmcFZrLAMMAOmWnBRpPLzmWyE7FhaA1WJvOxIFwCdUl2trUTDGjFg+nAtiujv5JU2sE0Fv rcvF7afJwQ1D8t78EtLmsw== Archived-At: Subject: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 27 Mar 2017 18:09:36 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mmusic-dtls-sdp-22 Reviewer: Paul Kyzivat Review Date: 2017-03-27 IETF LC End Date: 2017-04-06 IESG Telechat date: TBD Summary: This draft is basically ready for publication, but has some minor issues and nits that should be fixed before publication. (I reviewed this previously as part of LC and had no comments. After being asked to do a Gen-Art review I went through it more carefully. I surprised myself by finding a few thing, though nothing major. This confirms my feeling that I can *always* find *something* to improve in a draft.) Issues: Major: 0 Minor: 1 Nits: 3 (1) Nit: Regarding the following in section 5.1: When an offerer or answerer indicates that it wants to establish a new DTLS association, it needs to make sure that media packets in the existing DTLS association and new DTLS association can be de- multiplexed. This text presumes there is an existing association. To explicitly cover the case where there is not, I suggest the following: When an offerer or answerer indicates that it wants to establish a new DTLS association to replace an existing association, it needs to ensure that media packets in the existing DTLS association and new DTLS association can be de-multiplexed. Later in the section there is a language error is the following: The certificate received during the DTLS handshake MUST match a certificate fingerprints received in SDP 'fingerprint' attributes according to the procedures defined in [I-D.ietf-mmusic-4572-update]. s/match a/match the/ OR s/certificate fingerprints/certificate fingerprint/ (2) Nit: In Section 5.4 there is again a presumption of an existing association in the following: If the answer does not establish a new DTLS association, the offerer will continue using the previously established DTLS association. To fix, I suggest: If the offer indicated a desire to reuse an existing DTLS association and the answer does not request establishment of a new DTLS association, the offerer will continue using the previously established DTLS association. (3) Minor: I concur with the comments in the ops-dir review by Carlos Pignataro regarding the formatting of section 9. He didn't suggest a fix. Perhaps some special marker (e.g. "|" or "<" and ">") can be placed in every line to indicate it is test from or for another document - either at the beginning or end of every line. (4) Nit: In Section 9: The following text is repeated multiple times: [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document.] It would be sufficient and less distracting to the user to simply state this once for the entire document. From nobody Mon Mar 27 13:59: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 8AE80129659 for ; Mon, 27 Mar 2017 13:59:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 OMSzEPBanUN1 for ; Mon, 27 Mar 2017 13:59:23 -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 26243129669 for ; Mon, 27 Mar 2017 13:59:23 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id w43so62379244wrb.0 for ; Mon, 27 Mar 2017 13:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Oi6NZcV1DVpLI8zJlKquYqTfTDbu3S4NNXvXvPIf75I=; b=vOKttJ4MSjy4gPZ8GbnfZrmEGSBGNVOkdf8lbNtl1C8B1Ghw+Ajv/g5O9WyP5O2iXG Mgk2MTRbrlCd8cWuvELp9Y/f0h1Y0Ko7LQcmpg/Q5Lx9LUneySRAYp+vltOwJCQqRCku RJurHqN3H+ZjSeJrLJZG43DQIPoCBbPeKcoqn/mJ9dBL1fQjZfYX0BzU8uTKoHQEAb0q 6ZKjzjNv7W//5MAGh344E9mz9NG4lC7KcKze9mSzKM2edr3n0XebsLrDrO+YcS3HgBll LD+NzmhQdF/MRLFiz+hM2XHX8pHr63APF4QkXIrfuP6phjf4lEZWgFt210puQvNctce4 rhPw== 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=Oi6NZcV1DVpLI8zJlKquYqTfTDbu3S4NNXvXvPIf75I=; b=H1pqgFQR7ZwV6VVYxiw7pWJSDdSvuo3s0ESVQXj2dw4feJcfg3HbTj9+Aw76ZGYzue dLBj3UxrlMQdO8NmNnAF4V1D57nq3MLK8BDnG2lsU+Gd8+7zUQG/glRc2VElytJ4WbtP qT8KkT1A7wFQc9Gu7sDIuFh6WLZPjx6TmOaHc7+EmKLLlCEBjdHqICdmmd9doxs4Vre5 wnmUwVRt3VV++WHmcAU7vYrOufoTyFJISaxJLTmTbva70gld0xp+T4yR5kNIYqX1wizk IuN8sFPYN9hvIamVxFGS6IG3Dq28SQUkF+6bJ+41mzw8RWl2qzauKLkmbfhI3t4OlngW zfXw== X-Gm-Message-State: AFeK/H15TTaNlxeQ7zP2E9FICNZivdhLzKbkVW2POjPYJH9nsMRxnSoLZyU57wNvrFUTviYZg7huJM+pq1ViGw== X-Received: by 10.28.182.7 with SMTP id g7mr11760333wmf.108.1490648361597; Mon, 27 Mar 2017 13:59:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 27 Mar 2017 13:59:01 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 27 Mar 2017 22:59:01 +0200 Message-ID: To: Taylor Brandstetter Cc: Suhas Nandakumar , mmusic WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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: Mon, 27 Mar 2017 20:59:26 -0000 2017-03-27 19:44 GMT+02:00 Taylor Brandstetter : > If extension IDs aren't unique across bundled m=3D sections, then on rece= iving > a packet, an implementation may need to determine which m=3D section it's > "associated" with before knowing how to interpret the extension IDs. Yes. > To do > this, it may need to use the MID, which means that at a minimum, the MID > extension must be using a unique ID. Oh no, not at all. It's just about getting the appropriate RtpReceiver associated to the current RTP packet (this can be done by MID, RID, SSRC or even PT, as the ORTC and JSEP "RTP Matching Rules" define). Once we have the proper RtpReceiver, pass the packet to it so it can set the corresponding RTP extension ID mappings (because those params belong to each RtpReceiver), and later, let the transport get transport related IDs (such as REMB or transport-cc) from the RTP packet. Well, I implemented it yesterday so... :) https://github.com/ibc/mediasoup/blob/master/worker/src/RTC/Transport.cpp https://github.com/ibc/mediasoup/blob/master/worker/src/RTC/RtpStreamRecv.c= pp#L57 > But this increases implementation complexity without much benefit (the > benefit being that by sharing IDs, you could more easily avoid running ou= t > of spare IDs). So I'd be in favor of just requiring them to be unique. Me too. --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 27 14:00: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 EB567120727 for ; Mon, 27 Mar 2017 14:00:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 8sCFuxFoiWNh for ; Mon, 27 Mar 2017 14:00:55 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 5154B1279EB for ; Mon, 27 Mar 2017 14:00:55 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id u1so75570428wra.2 for ; Mon, 27 Mar 2017 14:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9gmnJAZnH9wmT0X/u3qOizb5/PaWcGu/39hvqgxzfGk=; b=sSwAjMDKzPeve9PiEc009lax1YiI06JQ58vRnTUCys0HTsPp2q3itQEMpK+6ux376D A2rpGi9Xq3nE6wUMSovb/S904un9/cZSQ6FdLhoTI1t1SrBsxo1GkD7a9EZ8ULI039hU FgS9c+HsUM4CZ5q5d/kQ8+4Vx4/OfxdXg5RMojhYJXSn9wTyKWPGcCQY4CElVfeKwVA+ bY5yigYudFt/rjuhPKOKi3F4SQGoCbrEYr4ouS4oDtuY5oXwqd1qiPIxoCdbNIfph/Pz nIV3j05SRu2xl1P4q/aZI2D30hAH/gGJmKB0CVwf+WM8AflIGLF2wVEeGkzjQrqtcPgr Kbow== 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=9gmnJAZnH9wmT0X/u3qOizb5/PaWcGu/39hvqgxzfGk=; b=FK9ehXMYu+WPe+JPtdM0B0jtjDJDrlO53xFo2ypjTWvJL78+oXjW+Ds4isgvuL2FdC eDgBmfIbRxoWy+4OUVbkR4xhNSEuDFX0obDuzuAyxizjSq8jeos/XSxlVAzyrYJl5VYO LfVks+l3ij0nnqdwyxkTeCVZAS2UjvmthlNS2iASS3R3XJVk0aKhH/ir9GXtUgtbroxs zneL3tBCbQIwsdEapZsJDq7vunV8o/MUWNhZlvIrFHXQ8frE5scpocY977jKzYU1YYIW +VbldXLT0bIqzKyuGyVtjxqjobtYBmaqOfg8vxvwv2pWdv9nr2G5WTpFHT+rN6Vov371 +VXg== X-Gm-Message-State: AFeK/H13+xxQVAoXsBzexDZNCQQRNYD0IcbBGyi5RieXrAiOWF4BYT3jf0T2HDRs3TAqTcEq68N2qGCouWxSsA== X-Received: by 10.223.172.135 with SMTP id o7mr20392474wrc.121.1490648453850; Mon, 27 Mar 2017 14:00:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 27 Mar 2017 14:00:33 -0700 (PDT) In-Reply-To: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> References: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 27 Mar 2017 23:00:33 +0200 Message-ID: To: Byron Campen Cc: Taylor Brandstetter , mmusic WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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: Mon, 27 Mar 2017 21:00:57 -0000 2017-03-27 19:55 GMT+02:00 Byron Campen : > Would it not be sufficient to specify that bundled m-sections not use t= he > same identifier for _different_ extensions? There's no ambiguity if you u= se > '3' for mid on every m-section, which is the kind of thing implementation= s > do now anyway. Still one may use '3' for MID within a m=3Daudio line and '4' for MID within a m=3Dvideo line. And that's legal. Anyhow, current browsers use unique IDs across the whole SDP. --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 27 15:24: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 D9929126E3A for ; Mon, 27 Mar 2017 15:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 BV4UXgXGLoAe for ; Mon, 27 Mar 2017 15:24:24 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 EAB90126BFD for ; Mon, 27 Mar 2017 15:24:23 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id f11so51622563qkb.0 for ; Mon, 27 Mar 2017 15:24:23 -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=JhTJuTSmp1w5383fmDXKd+bwKollYzUISQFO71pX53A=; b=D1iqV3nGzKBHHMrk+9FxL3ul9b7UmLaeYC2zWwsNZGfk4KR9nacH2IGqHcHBASsmjV l88hvgomcSnK9cQaSLP42NLNiNUIpaVlxn9BMNxsaxm5UkzQxQ1TjsRqO88H4MZZXhTS ADMq+Jj05LF33m/+B06cI6VjXQq5IUfC+GGrywrljh8JXDMbiW9OvqFnQnFuYr79Wjtn +778mXIY5Jz5YAIBiDkLGw8Pt3T9CEvXe4tHBdmcHj/4810kw24u3aDidGCBdLEDTwa4 +6GTX0QIGMoxU8R8n3emi5ZhNWh5Rg6nvK51SjbL2YL+bcYB58vJJFDlM4Mn5mktGoRr 64uA== 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=JhTJuTSmp1w5383fmDXKd+bwKollYzUISQFO71pX53A=; b=C/0fD7uoqjaMHm8R7yBIBHBlro3PAtirpR1/LJF4s3j4763NE5i6ur3i63BwkYDQrT lCzqWaVyC+fyDt5YUqSRMSPC2rElT+JyEBhNer2qZagRJnBGPOofyk5tWyzjterL5Qpl ULMziucwMhCjZRqcn1bQE6WF2X6KF5CYddig80I3kOY+3+sjmAn/oqs7tGAsAgrC7nyu c+3yqSOdw6bFcCIIImhSXRpMRsz4xaIOzersIEv//B7K7BaL6BL7FuJnLGn7ZNHLRNEK yV6G9GKtg5Wk1bjNUU1J4XXrrdDAKoyHV+E7kW3GzwWGbGGsAEmtFk3RWmf11jvsRRd8 GozQ== X-Gm-Message-State: AFeK/H1WLTjXy6UXdkqENH2JsaeJUPjrj3Hl447wjHU97ZHRue0wNbt3B6SFHzFaK9Kg8yrBvUEtooz6rlibVI7R X-Received: by 10.55.155.141 with SMTP id d135mr16076816qke.75.1490653462865; Mon, 27 Mar 2017 15:24:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.209 with HTTP; Mon, 27 Mar 2017 15:24:22 -0700 (PDT) In-Reply-To: References: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> From: Taylor Brandstetter Date: Mon, 27 Mar 2017 15:24:22 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: Byron Campen , mmusic WG Content-Type: multipart/alternative; boundary=94eb2c07684a23d5d8054bbdcec5 Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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: Mon, 27 Mar 2017 22:24:26 -0000 --94eb2c07684a23d5d8054bbdcec5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Would it not be sufficient to specify that bundled m-sections not use the > same identifier for _different_ extensions? Yes, that's what I meant to describe. It's just about getting the appropriate RtpReceiver > associated to the current RTP packet (this can be done by MID, RID, > SSRC or even PT, as the ORTC and JSEP "RTP Matching Rules" define). Right. So, if you *can't* get the appropriate RtpReceiver with RID, SSRC or PT, then you must do it with MID. And if the MID extension shares an ID with another extension, it becomes impossible to know the MID. For example: m=3Daudio ... a=3Dextmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=3Dextmap:2 urn:foo m=3Dvideo ... a=3Dextmap:1 urn:bar a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid I know it would be crazy to generate SDP like that, but there's nothing I've found that disallows it. On Mon, Mar 27, 2017 at 2:00 PM, I=C3=B1aki Baz Castillo wr= ote: > 2017-03-27 19:55 GMT+02:00 Byron Campen : > > Would it not be sufficient to specify that bundled m-sections not use > the > > same identifier for _different_ extensions? There's no ambiguity if you > use > > '3' for mid on every m-section, which is the kind of thing > implementations > > do now anyway. > > Still one may use '3' for MID within a m=3Daudio line and '4' for MID > within a m=3Dvideo line. And that's legal. > Anyhow, current browsers use unique IDs across the whole SDP. > > > -- > I=C3=B1aki Baz Castillo > > --94eb2c07684a23d5d8054bbdcec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would it not be sufficient to specify that bundled= m-sections not use the same identifier for _different_ extensions?<= /blockquote>

Yes, that's what I meant to describe.

It's just about getting the appropriate RtpR= eceiver
associated to the current RTP packet (this can be done by MID, RID,
SSRC or e= ven PT, as the ORTC and JSEP "RTP Matching Rules" define).=

Right. So, if you can't=C2=A0ge= t the appropriate RtpReceiver with RID, SSRC or PT, then you must do it wit= h MID. And if the MID extension shares an ID with another extension, it bec= omes impossible to know the MID. For example:

m=3Daudio ...
a=3Dextmap:1 urn:ietf:params:rtp-hdrext:sdes:mid<= br>
a=3Dextmap:2 = urn:foo
m=3Dvide= o ...
a=3Dextmap:1 urn:bar<= /font>
a=3Dextmap:2 urn:ietf:params= :rtp-hdrext:sdes:mid

I know it would be cra= zy to generate SDP like that, but there's nothing I've found that d= isallows it.

On Mon, Mar 27, 2017 at 2:00 PM, I=C3=B1aki Baz Castillo <ibc@aliax.n= et> wrote:
2017-03-27 19:55 GMT+02:00 Byron Campen <docfaraday@gmail.com>:
>=C2=A0 =C2=A0Would it not be sufficient to specify that bundled m-secti= ons not use the
> same identifier for _different_ extensions? There's no ambiguity i= f you use
> '3' for mid on every m-section, which is the kind of thing imp= lementations
> do now anyway.

Still one may use '3' for MID within a m=3Daudio line and &#= 39;4' for MID
within a m=3Dvideo line. And that's legal.
Anyhow, current browsers use unique IDs across the whole SDP.


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

--94eb2c07684a23d5d8054bbdcec5-- From nobody Mon Mar 27 16:09: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 CED121296CF for ; Mon, 27 Mar 2017 16:09:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 mst3JL2m9KFD for ; Mon, 27 Mar 2017 16:09:01 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 8EA3E1296C5 for ; Mon, 27 Mar 2017 16:08:57 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id l43so78688465wre.1 for ; Mon, 27 Mar 2017 16:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=joidKPU4J/w4mREzeZnSCt1rwx6tvBDXlllULywrY74=; b=aMLfgBM53Odl/Dpfcg6rlHbt8BzywC43HTdBbqeYbw0zut/iMbryBhVAMW1agy05Dl 3mld4naILTyAOOxpKKIhddguKWo0MA3JN/skK3JLdJwFTcAsk5OUOL9C6SmnseadqM1s JRAELfC8vaITGsY1ReuKuuVXQEgK37W2FMCTQ3hdOBTx8533VT875dTohfr94i+GWI7q 7P4rrBgv4D+MbHdzmX5I3+pucSmEy7GPIOpwH5zXbqUnlL6nadNKgPDQVdiLj97z+v5i RWl/iScLSWh/vSxNdt18H7o7GgK5+mSZcnOeHs5sg1231gPlK+kYcW+59LwqUScQRgfs MS6g== 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=joidKPU4J/w4mREzeZnSCt1rwx6tvBDXlllULywrY74=; b=AClvMyObRU+duF16Fme5y7POZjoGagn/+1fLAV9NchqjnmOMS+Z7B44B3HsdZIyxJv AblPraK1unroLgYeZGGrUjcd8j6Kr6DN4lmKXh3FNx3m7cJInX2CtxF2//Vsk3hfjJjz F+Lg6c0CnwQdX4WYrz2ZiHpwEzbkPZhqwusU5v+oXy92MgqtZ7GI05DHbZbfKNdpohAe jrBqlX81JJwdqYUGUpox0szNvFthhI12INHbeOLktnvRW9wepPRKhZjSlnxA7geqtTBf oBuyTrmP5uIZlc5fQOlaUOLHmbEIDwtH45lrVSCVL/3BrH6k1OT2h1CABMgnGyz1o0Sp OBOw== X-Gm-Message-State: AFeK/H0fXg8sCtc3GnImy+OdKT/kuyYlsry4aN758xDGQTUw9p/Us8DZYI/wOpIK6+9My2uFI1aLtCdNg02UIw== X-Received: by 10.223.173.82 with SMTP id p76mr20965286wrc.137.1490656136122; Mon, 27 Mar 2017 16:08:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Mon, 27 Mar 2017 16:08:35 -0700 (PDT) In-Reply-To: References: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 28 Mar 2017 01:08:35 +0200 Message-ID: To: Taylor Brandstetter Cc: Byron Campen , mmusic WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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: Mon, 27 Mar 2017 23:09:04 -0000 2017-03-28 0:24 GMT+02:00 Taylor Brandstetter : >> It's just about getting the appropriate RtpReceiver >> associated to the current RTP packet (this can be done by MID, RID, >> SSRC or even PT, as the ORTC and JSEP "RTP Matching Rules" define). > > > Right. So, if you can't get the appropriate RtpReceiver with RID, SSRC or > PT, then you must do it with MID. And if the MID extension shares an ID w= ith > another extension, it becomes impossible to know the MID. For example: > > m=3Daudio ... > a=3Dextmap:1 urn:ietf:params:rtp-hdrext:sdes:mid > a=3Dextmap:2 urn:foo > m=3Dvideo ... > a=3Dextmap:1 urn:bar > a=3Dextmap:2 urn:ietf:params:rtp-hdrext:sdes:mid > > I know it would be crazy to generate SDP like that, but there's nothing I= 've > found that disallows it. And you are 100% right here. MID ID must be unique across all the m=3D lines, otherwise it is useless. To make things even uglier, the RFC 5285 states: The mapping may be provided per media stream (in the media-level section(s) of SDP, i.e., after an "m=3D" line) or globally for all streams (i.e., before the first "m=3D" line, at session level). The definitions MUST be either all session level or all media level; it is not permitted to mix the two styles. In addition, as noted above, the IDs used MUST be unique for each stream type for a given media, or for the session for session-level declarations. So a solution may be using just global a=3Dextmap lines at SDP session level. That would work, but it's a hack, because not all the IDs are to be used within all the m=3D lines, not even across all the m=3D lines of the same kind (audio, video). Anyhow, the key of your argument is the "just MID for m=3Dline identification". It clearly requires the MID ID to be unique across all the m=3D lines. One "solution" would be for the BUNDLE spec [*] to mandate having a single MID ID, but it does not. I still prefer to mandate that the same ID always references the same extension URI, and that the same extension URI is just referenced by a single and unique ID in the entire SDP, but that "breaks" RFC 5285... So IMHO, the immediate issue is in BUNDLE spec [*] which defines the MID stuff but does not mandate the MID ID to be unique in the whole SDP. [*] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-36 --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 27 16:44: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 2E736127275; Mon, 27 Mar 2017 16:43:49 -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 NLOfY6NBMYB0; Mon, 27 Mar 2017 16:43:47 -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 21E091296C9; Mon, 27 Mar 2017 16:43:42 -0700 (PDT) X-AuditID: c1b4fb25-ce3ff70000002d78-cf-58d9a3aabd15 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id F5.72.11640.AA3A9D85; Tue, 28 Mar 2017 01:43:41 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 01:42:05 +0200 From: Christer Holmberg To: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AQHSpyVL2Q+bDZUak0uY64aahiGNt6GpLWXA Date: Mon, 27 Mar 2017 23:42:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se> References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> In-Reply-To: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbFdXXft4psRBs/PilvsuLuDzeLqq88s FlOXP2axWLHhAKsDi8ff9x+YPJYs+ckUwBTFZZOSmpNZllqkb5fAlfFkURtjwQeZilMNj1gb GCfIdDFycEgImEg8P53ZxcjFISSwnlFi+o19LBDOEkaJj88fMYEUsQlYSHT/0waJiwg0Mko0 Tt/P3MXIycEsECyxd/82RhBbWCBIYn7rWrC4CFD806sWFgjbSOLBo24wm0VAVeLKsUYwm1fA V+L0u7dsILaQgL3Eux0nwOKcAg4SO/+eZAWxGQXEJL6fWsMEsUtc4taT+WC2hICAxJI955kh bFGJl4//sULYShIrtl9iBLmZWUBTYv0ufYhWRYkp3Q/ZIdYKSpyc+YRlAqPoLCRTZyF0zELS MQtJxwJGllWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgXFzcMtv1R2Ml984HmIU4GBU4uF9 IHUzQog1say4MvcQowQHs5II7zduoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFex30XIoQE0hNL UrNTUwtSi2CyTBycUg2M4aI95oxCO3+9389W8Cb/olbx78a2qNT8jUvLj4nWLubeqsMRtdM6 N3TjkzmTZVepHpqy7gDXiyXl/3awTmt0uXtopQ9rY9Xc7UzHbmmeXaX4cYfKTv/zIu0KB1ft 7PWXr83fnjdj4SXeV+bzJmbu/rqON0j8sJupsNlD4Zb6h6qMz9XSTMq3KrEUZyQaajEXFScC AHtaDtaXAgAA Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 27 Mar 2017 23:43:49 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyEgUGxlYXNlIHNlZSBpbmxpbmUuDQoN CigxKSBOaXQ6DQoNCj5SZWdhcmRpbmcgdGhlIGZvbGxvd2luZyBpbiBzZWN0aW9uIDUuMToNCj4N Cj4gICAgV2hlbiBhbiBvZmZlcmVyIG9yIGFuc3dlcmVyIGluZGljYXRlcyB0aGF0IGl0IHdhbnRz IHRvIGVzdGFibGlzaCBhDQo+ICAgIG5ldyBEVExTIGFzc29jaWF0aW9uLCBpdCBuZWVkcyB0byBt YWtlIHN1cmUgdGhhdCBtZWRpYSBwYWNrZXRzIGluIHRoZQ0KPiAgICBleGlzdGluZyBEVExTIGFz c29jaWF0aW9uIGFuZCBuZXcgRFRMUyBhc3NvY2lhdGlvbiBjYW4gYmUgZGUtDQo+ICAgIG11bHRp cGxleGVkLg0KPg0KPlRoaXMgdGV4dCBwcmVzdW1lcyB0aGVyZSBpcyBhbiBleGlzdGluZyBhc3Nv Y2lhdGlvbi4gVG8gZXhwbGljaXRseSBjb3ZlciB0aGUgY2FzZSB3aGVyZSB0aGVyZSBpcyBub3Qs IEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nOg0KPg0KPiAgICBXaGVuIGFuIG9mZmVyZXIgb3IgYW5z d2VyZXIgaW5kaWNhdGVzIHRoYXQgaXQgd2FudHMgdG8gZXN0YWJsaXNoIGENCj4gICAgbmV3IERU TFMgYXNzb2NpYXRpb24gdG8gcmVwbGFjZSBhbiBleGlzdGluZyBhc3NvY2lhdGlvbiwgaXQgbmVl ZHMgdG8NCj4gICAgZW5zdXJlIHRoYXQgbWVkaWEgcGFja2V0cyBpbiB0aGUgZXhpc3RpbmcgRFRM UyBhc3NvY2lhdGlvbiBhbmQgbmV3DQo+ICAgIERUTFMgYXNzb2NpYXRpb24gY2FuIGJlIGRlLW11 bHRpcGxleGVkLg0KDQpJIGNvdWxkIGRvIHRoYXQuIE9yLCBJIGNvdWxkIHVzZSBzYXkgIm1ha2Ug c3VyZSB0aGF0IG1lZGlhIHBhY2tldHMgaW4gKmFueSogZXhpc3RpbmcgRFRMUyBhc3NvY2lhdGlv biINCg0KDQo+TGF0ZXIgaW4gdGhlIHNlY3Rpb24gdGhlcmUgaXMgYSBsYW5ndWFnZSBlcnJvciBp cyB0aGUgZm9sbG93aW5nOg0KPg0KPiAgICBUaGUgY2VydGlmaWNhdGUgcmVjZWl2ZWQgZHVyaW5n IHRoZSBEVExTIGhhbmRzaGFrZSBNVVNUIG1hdGNoIGENCj4gICAgY2VydGlmaWNhdGUgZmluZ2Vy cHJpbnRzIHJlY2VpdmVkIGluIFNEUCAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZXMNCj4gICAgYWNj b3JkaW5nIHRvIHRoZSBwcm9jZWR1cmVzIGRlZmluZWQgaW4gW0ktRC5pZXRmLW1tdXNpYy00NTcy LXVwZGF0ZV0uDQo+DQo+cy9tYXRjaCBhL21hdGNoIHRoZS8NCj4NCj5PUg0KPg0KPnMvY2VydGlm aWNhdGUgZmluZ2VycHJpbnRzL2NlcnRpZmljYXRlIGZpbmdlcnByaW50Lw0KDQpUaGF0IHdhcyB0 aGUgaW50ZW50aW9uLCBzbyBJIHdpbGwgZml4IGl0IChzL2NlcnRpZmljYXRlIGZpbmdlcnByaW50 cy9jZXJ0aWZpY2F0ZSBmaW5nZXJwcmludC8pLg0KDQoNCigyKSBOaXQ6DQoNCj5JbiBTZWN0aW9u IDUuNCB0aGVyZSBpcyBhZ2FpbiBhIHByZXN1bXB0aW9uIG9mIGFuIGV4aXN0aW5nIGFzc29jaWF0 aW9uIGluIHRoZSBmb2xsb3dpbmc6DQo+DQo+ICAgIElmIHRoZSBhbnN3ZXIgZG9lcyBub3QgZXN0 YWJsaXNoIGEgbmV3IERUTFMgYXNzb2NpYXRpb24sIHRoZSBvZmZlcmVyDQo+ICAgIHdpbGwgY29u dGludWUgdXNpbmcgdGhlIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgRFRMUyBhc3NvY2lhdGlvbi4N Cj4NCj5UbyBmaXgsIEkgc3VnZ2VzdDoNCj4NCj4gICAgSWYgdGhlIG9mZmVyIGluZGljYXRlZCBh IGRlc2lyZSB0byByZXVzZSBhbiBleGlzdGluZyBEVExTIGFzc29jaWF0aW9uDQo+ICAgIGFuZCB0 aGUgYW5zd2VyIGRvZXMgbm90IHJlcXVlc3QgZXN0YWJsaXNobWVudCBvZiBhIG5ldyBEVExTDQo+ ICAgIGFzc29jaWF0aW9uLCB0aGUgb2ZmZXJlciB3aWxsIGNvbnRpbnVlIHVzaW5nIHRoZSBwcmV2 aW91c2x5DQo+ICAgIGVzdGFibGlzaGVkIERUTFMgYXNzb2NpYXRpb24uDQoNCkkgd2lsbCBmaXgg YXMgc3VnZ2VzdGVkLg0KDQoNCigzKSBNaW5vcjoNCg0KPkkgY29uY3VyIHdpdGggdGhlIGNvbW1l bnRzIGluIHRoZSBvcHMtZGlyIHJldmlldyBieSBDYXJsb3MgUGlnbmF0YXJvIHJlZ2FyZGluZyB0 aGUgZm9ybWF0dGluZyBvZiANCj5zZWN0aW9uIDkuIEhlIGRpZG4ndCBzdWdnZXN0IGEgZml4LiBQ ZXJoYXBzIHNvbWUgc3BlY2lhbCBtYXJrZXIgKGUuZy4gInwiIG9yICI8IiBhbmQgIj4iKSBjYW4g YmUgcGxhY2VkIA0KPmluIGV2ZXJ5IGxpbmUgdG8gaW5kaWNhdGUgaXQgaXMgdGVzdCBmcm9tIG9y IGZvciBhbm90aGVyIGRvY3VtZW50IC0gZWl0aGVyIGF0IHRoZSBiZWdpbm5pbmcgb3IgZW5kIG9m IGV2ZXJ5IGxpbmUuDQoNCkkgaGF2ZSBuZXZlciBzZWVuIHRoYXQgYmVlbiB1c2VkIGJlZm9yZSAt IG5vdCBpbiBkb2N1bWVudHMgSSBoYXZlIGF1dGhvcmVkLCBvciBpbiBkb2N1bWVudHMgd3JpdHRl biBieSBvdGhlcnMuDQoNCg0KKDQpIE5pdDoNCg0KPkluIFNlY3Rpb24gOToNCj4NCj5UaGUgZm9s bG93aW5nIHRleHQgaXMgcmVwZWF0ZWQgbXVsdGlwbGUgdGltZXM6DQo+DQo+ICAgIFtSRkMgRURJ VE9SIE5PVEU6IFBsZWFzZSByZXBsYWNlIFJGQ1hYWFggd2l0aCB0aGUgUkZDIG51bWJlcg0KPiAg ICBvZiB0aGlzIGRvY3VtZW50Ll0NCj4NCj5JdCB3b3VsZCBiZSBzdWZmaWNpZW50IGFuZCBsZXNz IGRpc3RyYWN0aW5nIHRvIHRoZSB1c2VyIHRvIHNpbXBseSBzdGF0ZSB0aGlzIG9uY2UgZm9yIHRo ZSBlbnRpcmUgZG9jdW1lbnQuDQoNCkkgd2lsbCBmaXggYXMgc3VnZ2VzdGVkLg0KDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Mon Mar 27 16:58: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 64D851296D2 for ; Mon, 27 Mar 2017 16:58:07 -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 5QGVHyC8OA4t for ; Mon, 27 Mar 2017 16:58:01 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 5042D1296CD for ; Mon, 27 Mar 2017 16:58:01 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id n5so47360587pgh.0 for ; Mon, 27 Mar 2017 16:58:01 -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=VS6tXlET4Yl8Rxop1jUTtMffHxKtrW5QxkB5iXs/Ej8=; b=a4e+KYVZXK3y5a7+xMmPOP0o1gW70ak+CwKJSGCBOcWqFd/0x4bZReWVcWTeQBnvbi KCs57nWzsi7DEmHJ8nYzb5AjWclFyjfxvVVYF/igrQCsgS6b4+XUeUwHcFE6kQUT+arS noGZ5VxZxwh6A90MJ9WRaWAqdts15iJboNd0Zd5jJ6Z7cujr3OkiG2FVYqpAFQq5ENFW HisT5FBH2gpbAERaIM2YQyaEARYFe9WCfBCrPfJ6VrVrmAlE3PI/mSQG6KXpGw8/S80i jt1DNihs2DshvbxJCYP0lKiwKWq+3BDrn0NmZmlCnfnz/7CsUUaxZn98ywLklrVAS9tW jZhw== 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=VS6tXlET4Yl8Rxop1jUTtMffHxKtrW5QxkB5iXs/Ej8=; b=lODMBUMc33Ow5cuLX6MDjTxY8Vwn4/ydGZ6CXuh2PSroo3v51B30agKLy6Lfwu4wu5 FP/Kxi+6UVE2mXXdzLTV3uNGjqCkENx+YMUvRxsSIub1sNHT2UK5NO0/h8mlh1+49wmS u9Mfg1ExIc+5ZrAOKwXkAa7sHNWItpJ1KxdzhiKYndG8yLXFlnh3cRm3YsaQunZLdgfQ XvEIbXRozpSO9+BTuu5rsgrnIhe4HTvAa4lO1l4ZYCCtbjwo4fnkWCY9kUIt3nIgqv7Y 0SlscWDNyDRdGLL1TwzQTL9mOdXUmNq1h+LoZQVFTp3kAf38R0uIZm8ER/5rjYmqgwxP US6Q== X-Gm-Message-State: AFeK/H1pBh34O+12/IyX/vuO6WddsKInfOKYF5F2zWWIiVaD+O9ZqHM/3+ypO96YFh9VwA== X-Received: by 10.98.141.138 with SMTP id p10mr27506006pfk.111.1490659080919; Mon, 27 Mar 2017 16:58:00 -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 l9sm3188183pfi.97.2017.03.27.16.58.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Mar 2017 16:58:00 -0700 (PDT) Received: by mail-pg0-f45.google.com with SMTP id 81so40493274pgh.2; Mon, 27 Mar 2017 16:58:00 -0700 (PDT) X-Received: by 10.84.174.129 with SMTP id r1mr20196678plb.173.1490659080073; Mon, 27 Mar 2017 16:58:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Mon, 27 Mar 2017 16:57:59 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se> References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se> From: Roman Shpount Date: Mon, 27 Mar 2017 19:57:59 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Content-Type: multipart/alternative; boundary=94eb2c11b7b6f2ff93054bbf1c56 Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 27 Mar 2017 23:58:07 -0000 --94eb2c11b7b6f2ff93054bbf1c56 Content-Type: text/plain; charset=UTF-8 Hi All, On Mon, Mar 27, 2017 at 7:42 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >Regarding the following in section 5.1: > > > > When an offerer or answerer indicates that it wants to establish a > > new DTLS association, it needs to make sure that media packets in the > > existing DTLS association and new DTLS association can be de- > > multiplexed. > > > >This text presumes there is an existing association. To explicitly cover > the case where there is not, I suggest the following: > > > > When an offerer or answerer indicates that it wants to establish a > > new DTLS association to replace an existing association, it needs to > > ensure that media packets in the existing DTLS association and new > > DTLS association can be de-multiplexed. > > I could do that. Or, I could use say "make sure that media packets in > *any* existing DTLS association" > If we are nitpicking we need to define what "existing" DTLS association means here. In this particular case this means any DTLS association for which it still possible to receive packets. This includes currently established DTLS associations as well as any DTLS association which were closed but can still receive packets due to network transmission delays. Regards, _____________ Roman Shpount --94eb2c11b7b6f2ff93054bbf1c56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,


On Mon, Mar 27, 2017 at 7:42 PM, Christer Holmberg <= christe= r.holmberg@ericsson.com> wrote:
>Regarding the following = in section 5.1:
>
>=C2=A0 =C2=A0 When an offerer or answerer indicates that it wants to es= tablish a
>=C2=A0 =C2=A0 new DTLS association, it needs to make sure that media pa= ckets in the
>=C2=A0 =C2=A0 existing DTLS association and new DTLS association can be= de-
>=C2=A0 =C2=A0 multiplexed.
>
>This text presumes there is an existing association. To explicitly cove= r the case where there is not, I suggest the following:
>
>=C2=A0 =C2=A0 When an offerer or answerer indicates that it wants to es= tablish a
>=C2=A0 =C2=A0 new DTLS association to replace an existing association, = it needs to
>=C2=A0 =C2=A0 ensure that media packets in the existing DTLS associatio= n and new
>=C2=A0 =C2=A0 DTLS association can be de-multiplexed.

I could do that. Or, I could use say "make sure that media pack= ets in *any* existing DTLS association"

If we are nitpicking we need to define what "existing" DTLS= association means here. In this particular case this means any DTLS associ= ation for which it still possible to receive packets. This includes current= ly established DTLS associations as well as any DTLS association which were= closed but can still receive packets due to network transmission delays.

Regards,
_= ____________
Roman Shpount
=C2=A0
--94eb2c11b7b6f2ff93054bbf1c56-- From nobody Mon Mar 27 20:38: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 A5D9E128990 for ; Mon, 27 Mar 2017 20:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, 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 G5GWyWPAyZ3W for ; Mon, 27 Mar 2017 20:38:31 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 78E30126DED for ; Mon, 27 Mar 2017 20:38:31 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-06v.sys.comcast.net with SMTP id shxmcVkMzl4eqshxmcEOeF; Tue, 28 Mar 2017 03:38:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1490672310; bh=CJrK3DHK8DVniTlMWHMnWY+RWguKypb3/vD6W09K5rs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hQkPp9yvXJS5TqVsFATeGdyPpUomZ2P4Uz9HPC8CBdHc32hV8wWT8eIwqn3BKxbo3 GFEmJruZ9kUzM/WcQ7gw6xDnqzAqh1cPXPXCpdYZf5praOoJiuWNPLsPtIHyADQJGB DDkprT63eV8z/7wamCKfD5/i2Gh3o8ZK/LiR0+glQetPRrzgXRZl5Bc4zi+FRz/vOT +IDAM9CHG6NpH2ncujsALf3YW180bSBRxDvmX/Y5dMiIbtFQoNYrsgZ78si57aOILE yxI7Uyh4lBC4w4pJkY/GuBntb3+aqfAjAJ1tKNQe6irfF2oI3zDrUjbVFUegoulAL3 D9Og8N0xt/zyQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-15v.sys.comcast.net with SMTP id shxmcJFD0XTPjshxmcQa56; Tue, 28 Mar 2017 03:38:30 +0000 To: mmusic@ietf.org References: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> From: Paul Kyzivat Message-ID: <59edda63-a02a-b685-fede-91f4cc292037@comcast.net> Date: Mon, 27 Mar 2017 23:38:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfNsso3+Jpp6GnvpkMpzD27ZlF44R+XA5wdu326rIh5dqS2k1FYPt7iPyfdVZtnZiqWJ8f4ZUNaIg85gVLKNdi4oWVX7Dx/3XlNynyWFAnLDZIctlgt3A FbxdGQ+CvzhEqxKSjonOjXXynD3tpp8ivcZB4s97XmIZ6pc21qWirg7C Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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, 28 Mar 2017 03:38:33 -0000 On 3/27/17 7:08 PM, Iñaki Baz Castillo wrote: > So IMHO, the immediate issue is in BUNDLE spec [*] which defines the > MID stuff but does not mandate the MID ID to be unique in the whole > SDP. This is already required by section 4 of RFC5888: The identification-tag MUST be unique within an SDP session description. Thanks, Paul From nobody Mon Mar 27 20:55: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 E871612025C for ; Mon, 27 Mar 2017 20:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 cVEMbj2XDfef for ; Mon, 27 Mar 2017 20:55:23 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 B7A851275C5 for ; Mon, 27 Mar 2017 20:55:23 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-08v.sys.comcast.net with SMTP id siE2cBXcNAfZssiE7cg3ek; Tue, 28 Mar 2017 03:55:23 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-15v.sys.comcast.net with SMTP id siE5cJISFXTPjsiE6cQbNP; Tue, 28 Mar 2017 03:55:22 +0000 To: Christer Holmberg , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se> Cc: General Area Review Team , IETF MMUSIC WG From: Paul Kyzivat Message-ID: Date: Mon, 27 Mar 2017 23:55:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfN3D4IC3cv+/bBIQmfIVvHcsXf/3O1o/SIhzE14N60fVlUG+KG0csSiaKcX0e6YOf724Kp6Y8ZpJFcTGCowPQR91FL7PMVlh1m8GsZii5quVbY+5SVvV IB54wB7PJbs9E3lwpX13ZHMT1GtHYQqeynSiH5QOv3m5aX3vL04tUMnR1QF5uXWTRYt63s9TtkTFuaUjRgUtYC2YPvMx18vptQlDb9ykVB842PU/Ur1AySG9 DernHihVKml/C9GQtgmEPTElVWvh7hfCKxiz5z+0BUmtdlk+SZtipADp6CIF7PG2 Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 28 Mar 2017 03:55:25 -0000 Hi Christer, [trimming] On 3/27/17 7:42 PM, Christer Holmberg wrote: > Hi Paul, > > Thanks for your review! Please see inline. > > (1) Nit: > >> Regarding the following in section 5.1: >> >> When an offerer or answerer indicates that it wants to establish a >> new DTLS association, it needs to make sure that media packets in the >> existing DTLS association and new DTLS association can be de- >> multiplexed. >> >> This text presumes there is an existing association. To explicitly cover the case where there is not, I suggest the following: >> >> When an offerer or answerer indicates that it wants to establish a >> new DTLS association to replace an existing association, it needs to >> ensure that media packets in the existing DTLS association and new >> DTLS association can be de-multiplexed. > > I could do that. Or, I could use say "make sure that media packets in *any* existing DTLS association" That would also be fine. I have no preference. > (3) Minor: > >> I concur with the comments in the ops-dir review by Carlos Pignataro regarding the formatting of >> section 9. He didn't suggest a fix. Perhaps some special marker (e.g. "|" or "<" and ">") can be placed >> in every line to indicate it is test from or for another document - either at the beginning or end of every line. > > I have never seen that been used before - not in documents I have authored, or in documents written by others. Yes, I know. I was just trying to be constructive by suggesting *something*. My first thought was to indent. But that would require reflowing all the text to avoid exceeding line length. That seemed like a bad idea. I'm not attached to this solution. I've complained about the same problem in other drafts, but nobody came up with a solution so they didn't get resolved. Here I'm not the only one who sees a problem, so maybe it is worth trying to find a solution. Thanks, Paul From nobody Mon Mar 27 23:21: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 52121126C89 for ; Mon, 27 Mar 2017 23:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 4QAf0btg2YIB for ; Mon, 27 Mar 2017 23:21:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D53C126579 for ; Mon, 27 Mar 2017 23:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=688; q=dns/txt; s=iport; t=1490682066; x=1491891666; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yqs7D8ontEmBAwwG2icZvzhXRDkfu/esrNube3kWcLc=; b=I16HLeXZu15VEMD7B9KfiMhHKHoe6cCb0t0rJIGxB92SAf0ywPrPsgQK oJylA9Xj2BcFoCRDc4qoGpsnCyG+0Hx5d9EogiW9xrMhG973i491B4hKL 3r//TNQFmROXXSM1t8+TrJWkuvD2lz1sEMKD2ACaCmDy8lOwRkb5bTGuV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAwANpY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQuNcZFQlUuCDh8LhS5KAoMjPxgBAgEBAQEBAQFrKIUWAQE?= =?us-ascii?q?BAgEBAWwLBQsCAQhGJwslAgQOBYlvAw0IDq45hzcIgxABAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZOggWCaoRUgzSCMQWQIYw8AZJNgWSPTpNlAR84gQRZFUERAYR?= =?us-ascii?q?GHYFjdYltAQEB?= X-IronPort-AV: E=Sophos;i="5.36,235,1486425600"; d="scan'208";a="7659556" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2017 06:20:38 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2S6KbRc019990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 06:20:37 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 01:20:37 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Tue, 28 Mar 2017 01:20:36 -0500 From: "Mo Zanaty (mzanaty)" To: Paul Kyzivat CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] "a=extmap" with BUNDLE Thread-Index: AQHSpyHZ4q4b3x2mx0uxz0OXpHNXvqGpTC+AgAAzuICAABdrAIAABAMwgAAtO+g= Date: Tue, 28 Mar 2017 06:20:36 +0000 Message-ID: References: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> , <59edda63-a02a-b685-fede-91f4cc292037@comcast.net> In-Reply-To: <59edda63-a02a-b685-fede-91f4cc292037@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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, 28 Mar 2017 06:21:08 -0000 The issue is uniqueness of the extmap id for mid not the mid value itself (= identification-tag).=20 Mo On Mar 27, 2017, at 10:38 PM, Paul Kyzivat wrote= : On 3/27/17 7:08 PM, I=F1aki Baz Castillo wrote: > So IMHO, the immediate issue is in BUNDLE spec [*] which defines the > MID stuff but does not mandate the MID ID to be unique in the whole > SDP. This is already required by section 4 of RFC5888: The identification-tag MUST be unique within an SDP session description. Thanks, Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Mar 27 23:43: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 4A462128DF6 for ; Mon, 27 Mar 2017 23:43:25 -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 lMU70Hxwspqg for ; Mon, 27 Mar 2017 23:43:23 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 1E542126C89 for ; Mon, 27 Mar 2017 23:43:23 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p22so57725450qka.3 for ; Mon, 27 Mar 2017 23:43:23 -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=xSJbo4Zuyr448kFhoIENHpe9XuzZmHAaX6TWlQ0jr4Y=; b=rcBdBQ9mnqEdUAV7FVI7NoL5DeWdwOpEHvKY20MJD2brvcqkUakWtXu+DGN2Gf9Xcq OriMq8tQuwWH2wAgAQoyn+OPmWbyhDHYck2UneMANUJMOqBchs/7wq3DBlPPRj+VdWFA z5BfNmV4U6RmmQut/B1+OdxLVvsP9h6AaKk+8S+cA+/WozqajDv2t0W3Eb0o01Ee3G91 2R5wrqRrrtUkw3UB2Oi4oLK49jgCbfJ/jYzO/9YrwNV4a/c+ZtwMDNsizMfZdspIt0jP wkKORiELuAtCX0KrkKNlTJh8k4a6OKdkN47FakO2MZpz5SMdsYU9rR/GR11IYRWYi22g kBrQ== 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=xSJbo4Zuyr448kFhoIENHpe9XuzZmHAaX6TWlQ0jr4Y=; b=O7aVMhSfADwdrDvlAujgmyARtZeUNUxUyD3axfhw4QwxZf693AETkhbXLLb92/5wWd nKPAxoi6PCaZXEQ07Lnbm5A8yQ/15kCPJt+AizberXJDUV8getvGt0n7B+ZkydMGhPfQ M/Q9PMAbvniyBOksynJkZQ3XzR8jfTnfTeY5hseM7c+dU6VzhDL+sll+0LFIRh+ki5jb St9xjGhQy8BxQe0qEX52NjPJQKJ8NkvsW9kAoQK1bciq8SkI6KlpCrLYlCwhJl8/Xgb1 wEaZMkUveOW4flvFWrZ/DcYH2Fz9LTXQQEnNSK+vcQFgeZFT0oj0OoSqOKRgmBdjL2ei CySw== X-Gm-Message-State: AFeK/H0Dd3AAjKIBNbi5zd03ZBqfz+2PlLpakIkt9hhR9BA9f5IWeGEiCVRH22TtV66/LSDyfUsal2oBQsJdGw== X-Received: by 10.55.105.6 with SMTP id e6mr22866574qkc.252.1490683402201; Mon, 27 Mar 2017 23:43:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.165 with HTTP; Mon, 27 Mar 2017 23:43:21 -0700 (PDT) In-Reply-To: References: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> <59edda63-a02a-b685-fede-91f4cc292037@comcast.net> From: Suhas Nandakumar Date: Tue, 28 Mar 2017 01:43:21 -0500 Message-ID: To: "Mo Zanaty (mzanaty)" Cc: Paul Kyzivat , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a11487338a96c3f054bc4c664 Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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, 28 Mar 2017 06:43:25 -0000 --001a11487338a96c3f054bc4c664 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since extmap is currently categorized under category of SPECIAL, at the minimum we need BUNDLE draft to describe its behavior for MID RTP Header extension under multiplexing, if it is not already doing so On Tue, Mar 28, 2017 at 1:20 AM, Mo Zanaty (mzanaty) wrote: > The issue is uniqueness of the extmap id for mid not the mid value itself > (identification-tag). > > Mo > > On Mar 27, 2017, at 10:38 PM, Paul Kyzivat > wrote: > > On 3/27/17 7:08 PM, I=C3=B1aki Baz Castillo wrote: > > > So IMHO, the immediate issue is in BUNDLE spec [*] which defines the > > MID stuff but does not mandate the MID ID to be unique in the whole > > SDP. > > This is already required by section 4 of RFC5888: > > The identification-tag MUST be unique within an SDP session > description. > > Thanks, > Paul > > _______________________________________________ > 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 > --001a11487338a96c3f054bc4c664 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since extmap is currently categorized under category of SP= ECIAL, at the minimum we need BUNDLE draft to describe its behavior for MID= RTP Header extension under multiplexing, if it is not already doing so


On Tue, Mar 28, 2017 at 1:20 AM, Mo Zanaty (mzanaty) <mza= naty@cisco.com> wrote:
The = issue is uniqueness of the extmap id for mid not the mid value itself (iden= tification-tag).

Mo

On Mar 27, 2017, at 10:38 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:

On 3/27/17 7:08 PM, I=C3=B1aki Baz Castillo wrote:

> So IMHO, the immediate issue is in BUNDLE spec [*] which defines the > MID stuff but does not mandate the MID ID to be unique in the whole > SDP.

This is already required by section 4 of RFC5888:

=C2=A0 The identification-tag MUST be unique within an SDP session
=C2=A0 description.

=C2=A0 =C2=A0Thanks,
=C2=A0 =C2=A0Paul

_______________________________________________
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

--001a11487338a96c3f054bc4c664-- From nobody Tue Mar 28 06:37: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 C03D81299BB for ; Tue, 28 Mar 2017 06:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 ul8n2BOwEeM4 for ; Tue, 28 Mar 2017 06:37:43 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 9CD79129541 for ; Tue, 28 Mar 2017 06:37:42 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id w43so91232466wrb.0 for ; Tue, 28 Mar 2017 06:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HNZ5f6vdTv2b5SLWSuQpuD+2TmAjBk0QmCK8JnKUMRQ=; b=CiAIof0mr03DNcHwUXciqKC+cLLxD6Sx97Fsr+14GxsIQG/aaY6S4cjXf2u03EJjg/ fbyP/FsFB4xgUpOcDMcZs4ZHoSO0WAD0ApRbzyMLCvUWLkyL8x2a7tr0J0UNVaZ2OyB7 A0S+y7ia022wGA0RbaiwahH2709vAhS3XCt89AC3pyBSN4n6fsFA2DMyZNpWcWunJZEe jkfJVK/B/e9mAVZYxR4CLmoJaHQzCvxsEf8WjSk82KzDluAil/E2rEQ6P4qpUo3rWPw/ MF9vBoDD3Lxva5qGYF9OWWtC015s3CKNrWE5K/tnxQBvYuxio0oleLHRIi7XQr3q8KQt F1YA== 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=HNZ5f6vdTv2b5SLWSuQpuD+2TmAjBk0QmCK8JnKUMRQ=; b=Vm8hWG8JbXLOXWGEv9g1sLwFUkDRgFXVRsU164yHS+rVXRbWzM1QCmN1llvVxkFW7c 0UCSSi3YdGBXhWEP3EH+IINDOO0xi87+pdbkxSBMGHNRzzeZCuC8GdiF0UT39Neae+Ss 5pRo8wONg7K6YUPcxKCVTZdLazWEaFel+bLfM7/+mYbjd/PjGCYIcGH8MNIRv5MEv2oH xXls/KX7tc9NAywquOao7BXEIOwZH1oR0TMkJ0LAFQuVzEtbuW0loBqE9zo3zs4ee/Hy oytaRdn6pr9YGr4kyHC3A0VLBePWgVT4G54Z2pWsRYXzk+E60VpzHLYghehNJ7urI2iJ WnNQ== X-Gm-Message-State: AFeK/H3a08s9UYeQHdvcTLESkc7NJM95v9V79u7w8MeSIIm4t45KekfNamXG2SPvSBYb+lofdTfkEZGhz3EWpg== X-Received: by 10.223.135.252 with SMTP id c57mr25551703wrc.109.1490708260548; Tue, 28 Mar 2017 06:37:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.222 with HTTP; Tue, 28 Mar 2017 06:37:19 -0700 (PDT) In-Reply-To: References: <279829dc-201f-25ab-0d1b-9958fb98682f@gmail.com> <59edda63-a02a-b685-fede-91f4cc292037@comcast.net> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 28 Mar 2017 15:37:19 +0200 Message-ID: To: Suhas Nandakumar Cc: "Mo Zanaty (mzanaty)" , Paul Kyzivat , "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] "a=extmap" with 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, 28 Mar 2017 13:37:45 -0000 2017-03-28 8:43 GMT+02:00 Suhas Nandakumar : > Since extmap is currently categorized under category of SPECIAL, at the > minimum we need BUNDLE draft to describe its behavior for MID RTP Header > extension under multiplexing, if it is not already doing so It does not do it. I mean, BUNDLE draft does not state that the ID for MID must be unique across all the m=3D sections. And it MUST be (otherwise it does not make sense at all). --=20 I=C3=B1aki Baz Castillo From nobody Tue Mar 28 07:40: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 12956129543; Tue, 28 Mar 2017 07:40:51 -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 N_vQlanc0ydD; Tue, 28 Mar 2017 07:40:49 -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 225B51296CA; Tue, 28 Mar 2017 07:40:46 -0700 (PDT) X-AuditID: c1b4fb3a-0dfff70000003958-6e-58da75eac2ab Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 03.83.14680.AE57AD85; Tue, 28 Mar 2017 16:40:45 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 16:40:42 +0200 From: Christer Holmberg To: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AQHSpyVL2Q+bDZUak0uY64aahiGNt6GpLWXAgABRB4CAANUEoA== Date: Tue, 28 Mar 2017 14:40:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB324DF@ESESSMB109.ericsson.se> References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CB31018@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbHdQPdt6a0Ig02b5Sx23N3BZnH11WcW i6nLH7NYrNhwgNWBxePv+w9MHkuW/GQKYIrisklJzcksSy3St0vgyth1X7hgG0/FoqmfmBsY e3i6GDk5JARMJJ6+ucDexcjFISSwnlFi+/KlLCAJIYEljBL7Gwy7GDk42AQsJLr/aYPUiAg0 Mko0Tt/PDFLDLBAssXf/NkYQW1ggSGJ+61qwuAhQ/NOrFhaQXhEBJ4kHS5VBwiwCqhIrznWB lfMK+Eq8uDiBEWLvTkaJN2efgSU4BRwkTp2ezApiMwqISXw/tYYJYpe4xK0n85kgjhaQWLLn PDOELSrx8vE/VghbSaJxyRNWkL3MApoS63fpQ7QqSkzpfsgOsVdQ4uTMJywTGEVnIZk6C6Fj FpKOWUg6FjCyrGIULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjJqDW35b7WA8+NzxEKMAB6MS D+8DqZsRQqyJZcWVuYcYJTiYlUR4v3EDhXhTEiurUovy44tKc1KLDzFKc7AoifM67LsQISSQ nliSmp2aWpBaBJNl4uCUamAs2+RpIHfVUF1eSEBk49yIdRtf83IlTT7yr7tWOpFvwYpTJkEW ZyUPczVnMy0NiOhr/VXty5QteZlfc+nGVa8CnroYnDLNkVl6lDU9c8/6dyFPl8zo/W17eiur WpUaE1tQn47MtbTWvHzHb0yuLHE7DdsaPfL/Gu/u+3p3zw6ZDMcVGTt1ryuxFGckGmoxFxUn AgBXc4R+lgIAAA== Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 28 Mar 2017 14:40:51 -0000 SGksDQoNCi4uLg0KDQooMykgTWlub3I6DQoNCj4+PiBJIGNvbmN1ciB3aXRoIHRoZSBjb21tZW50 cyBpbiB0aGUgb3BzLWRpciByZXZpZXcgYnkgQ2FybG9zIFBpZ25hdGFybyANCj4+PiByZWdhcmRp bmcgdGhlIGZvcm1hdHRpbmcgb2Ygc2VjdGlvbiA5LiBIZSBkaWRuJ3Qgc3VnZ2VzdCBhIGZpeC4g DQo+Pj4gUGVyaGFwcyBzb21lIHNwZWNpYWwgbWFya2VyIChlLmcuICJ8IiBvciAiPCIgYW5kICI+ IikgY2FuIGJlIHBsYWNlZCBpbiBldmVyeSBsaW5lIHRvIGluZGljYXRlIGl0IA0KPj4+IGlzIHRl c3QgZnJvbSBvciBmb3IgYW5vdGhlciBkb2N1bWVudCAtIGVpdGhlciBhdCB0aGUgYmVnaW5uaW5n IG9yIGVuZCBvZiBldmVyeSBsaW5lLg0KPj4NCj4+IEkgaGF2ZSBuZXZlciBzZWVuIHRoYXQgYmVl biB1c2VkIGJlZm9yZSAtIG5vdCBpbiBkb2N1bWVudHMgSSBoYXZlIGF1dGhvcmVkLCBvciBpbiBk b2N1bWVudHMgd3JpdHRlbiBieSBvdGhlcnMuDQo+DQo+IFllcywgSSBrbm93LiBJIHdhcyBqdXN0 IHRyeWluZyB0byBiZSBjb25zdHJ1Y3RpdmUgYnkgc3VnZ2VzdGluZyAqc29tZXRoaW5nKi4gTXkg Zmlyc3QgdGhvdWdodCB3YXMgdG8gaW5kZW50LiANCj4NCj4gQnV0IHRoYXQgd291bGQgcmVxdWly ZSByZWZsb3dpbmcgYWxsIHRoZSB0ZXh0IHRvIGF2b2lkIGV4Y2VlZGluZyBsaW5lIGxlbmd0aC4g VGhhdCBzZWVtZWQgbGlrZSBhIGJhZCBpZGVhLg0KPg0KPiBJJ20gbm90IGF0dGFjaGVkIHRvIHRo aXMgc29sdXRpb24uIEkndmUgY29tcGxhaW5lZCBhYm91dCB0aGUgc2FtZSBwcm9ibGVtIGluIG90 aGVyIGRyYWZ0cywgYnV0IG5vYm9keSBjYW1lDQo+IHVwIHdpdGggYSBzb2x1dGlvbiBzbyB0aGV5 IGRpZG4ndCBnZXQgcmVzb2x2ZWQuIEhlcmUgSSdtIG5vdCB0aGUgb25seSBvbmUgd2hvIHNlZXMg YSBwcm9ibGVtLCBzbyBtYXliZSBpdCBpcyANCj4gd29ydGggdHJ5aW5nIHRvIGZpbmQgYSBzb2x1 dGlvbi4NCg0KSSBkb24ndCBoYXZlIGEgcHJvYmxlbSB0byBhZGQgZS5nLiAifCIsIGlmIHRoYXQn cyB3aGF0IHBlb3BsZSB3YW50IHRvIGRvLCBidXQgbXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBu b3QgZG8gYW55dGhpbmcgaW4gdGhpcyBkcmFmdCwgYXQgdGhpcyBwb2ludCBvZiB0aW1lLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Tue Mar 28 07:45: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 BA455129543; Tue, 28 Mar 2017 07:45:09 -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 diHqIbF9Eo4K; Tue, 28 Mar 2017 07:45: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 E7AD71299FA; Tue, 28 Mar 2017 07:45:00 -0700 (PDT) X-AuditID: c1b4fb2d-25fff70000005be8-30-58da76ea9b18 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 3B.49.23528.AE67AD85; Tue, 28 Mar 2017 16:44:59 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 16:44:57 +0200 From: Christer Holmberg To: Roman Shpount CC: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Thread-Topic: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AQHSpyVL2Q+bDZUak0uY64aahiGNt6GpLWXAgAAOtYCAARh6EA== Date: Tue, 28 Mar 2017 14:44:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB3251B@ESESSMB109.ericsson.se> References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CB31018@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB3251BESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7ge7rslsRBhf3ClvsuLuDzeLqq88s FlOXP2axWLHhAKvFjAtTmR1YPf6+/8DksWTJTyaPW1MKApijuGxSUnMyy1KL9O0SuDJm/b/F UvAqvWL/r2WsDYwNqV2MnBwSAiYSfSevs3YxcnEICaxnlFj3+hQThLOEUeLikhlsXYwcHGwC FhLd/7RBGkQEVCX+fp8MVsMscIlRoqmthwWkRlggWuJJNytETYzEz/8TWSBsJ4mFk/eBxVmA elvW3mEDsXkFfCXmnj0JtfgUo8TmdYeYQRKcAoESB1Z8ZgSxGQXEJL6fWsMEYjMLiEvcejKf CeJqAYkle84zQ9iiEi8f/2OFsJUkGpc8YYWoz5d4uHod1DJBiZMzn7BMYBSZhWTULCRls5CU zQJ6h1lAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PL Sy3ZxAiMvoNbfuvuYFz92vEQowAHoxIP7wOpmxFCrIllxZW5hxglOJiVRHi/cQOFeFMSK6tS i/Lji0pzUosPMUpzsCiJ8zrsuxAhJJCeWJKanZpakFoEk2Xi4JRqYGy13Jj39LpTI0tsqXK8 ockUAe9vPpzsm6Re/GSTW+3p+tlj76q01yt2ZqR99HsV7X7nOsPZ+TmPZJqEtZq/S2wo4Zn9 cfVE9j0tRZfjrhVIztz4tr/e/POLP2mFQteaq18uM2W4G3Zl7qlrwhNDa7gOailPWTftyWoJ ye0XnqyR76th2Oi/b7YSS3FGoqEWc1FxIgBopNVFugIAAA== Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 28 Mar 2017 14:45:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB3251BESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCldoYXQgYWJvdXQ6DQoNCuKAnOKApm1lZGlhIHBhY2tldHMgaW4gdGhlIGFu eSBwcmV2aW91c2x5IGVzdGFibGlzaGVkIERUTFMgYXNzb2NpYXRpb24gYW5k4oCm4oCdDQoNClRo YXQgY292ZXJzIGJvdGggdGhlIGN1cnJlbnRseSBlc3RhYmxpc2hlZCBhbmQgYWxyZWFkeSBjbG9z ZWQgYXNzb2NpYXRpb25zLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IFJvbWFu IFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDI4IE1hcmNoIDIwMTcg MDI6NTgNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPg0KQ2M6IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgZHJhZnQtaWV0 Zi1tbXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnOyBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0g PGdlbi1hcnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyA8bW11c2ljQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtNTVVTSUNdIFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjINCg0KSGkgQWxsLA0KDQoNCk9uIE1vbiwgTWFy IDI3LCAyMDE3IGF0IDc6NDIgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KPlJlZ2FyZGluZyB0aGUgZm9sbG93aW5nIGluIHNlY3Rpb24gNS4xOg0KPg0KPiAgICBX aGVuIGFuIG9mZmVyZXIgb3IgYW5zd2VyZXIgaW5kaWNhdGVzIHRoYXQgaXQgd2FudHMgdG8gZXN0 YWJsaXNoIGENCj4gICAgbmV3IERUTFMgYXNzb2NpYXRpb24sIGl0IG5lZWRzIHRvIG1ha2Ugc3Vy ZSB0aGF0IG1lZGlhIHBhY2tldHMgaW4gdGhlDQo+ICAgIGV4aXN0aW5nIERUTFMgYXNzb2NpYXRp b24gYW5kIG5ldyBEVExTIGFzc29jaWF0aW9uIGNhbiBiZSBkZS0NCj4gICAgbXVsdGlwbGV4ZWQu DQo+DQo+VGhpcyB0ZXh0IHByZXN1bWVzIHRoZXJlIGlzIGFuIGV4aXN0aW5nIGFzc29jaWF0aW9u LiBUbyBleHBsaWNpdGx5IGNvdmVyIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGlzIG5vdCwgSSBzdWdn ZXN0IHRoZSBmb2xsb3dpbmc6DQo+DQo+ICAgIFdoZW4gYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBp bmRpY2F0ZXMgdGhhdCBpdCB3YW50cyB0byBlc3RhYmxpc2ggYQ0KPiAgICBuZXcgRFRMUyBhc3Nv Y2lhdGlvbiB0byByZXBsYWNlIGFuIGV4aXN0aW5nIGFzc29jaWF0aW9uLCBpdCBuZWVkcyB0bw0K PiAgICBlbnN1cmUgdGhhdCBtZWRpYSBwYWNrZXRzIGluIHRoZSBleGlzdGluZyBEVExTIGFzc29j aWF0aW9uIGFuZCBuZXcNCj4gICAgRFRMUyBhc3NvY2lhdGlvbiBjYW4gYmUgZGUtbXVsdGlwbGV4 ZWQuDQoNCkkgY291bGQgZG8gdGhhdC4gT3IsIEkgY291bGQgdXNlIHNheSAibWFrZSBzdXJlIHRo YXQgbWVkaWEgcGFja2V0cyBpbiAqYW55KiBleGlzdGluZyBEVExTIGFzc29jaWF0aW9uIg0KDQpJ ZiB3ZSBhcmUgbml0cGlja2luZyB3ZSBuZWVkIHRvIGRlZmluZSB3aGF0ICJleGlzdGluZyIgRFRM UyBhc3NvY2lhdGlvbiBtZWFucyBoZXJlLiBJbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSB0aGlzIG1l YW5zIGFueSBEVExTIGFzc29jaWF0aW9uIGZvciB3aGljaCBpdCBzdGlsbCBwb3NzaWJsZSB0byBy ZWNlaXZlIHBhY2tldHMuIFRoaXMgaW5jbHVkZXMgY3VycmVudGx5IGVzdGFibGlzaGVkIERUTFMg YXNzb2NpYXRpb25zIGFzIHdlbGwgYXMgYW55IERUTFMgYXNzb2NpYXRpb24gd2hpY2ggd2VyZSBj bG9zZWQgYnV0IGNhbiBzdGlsbCByZWNlaXZlIHBhY2tldHMgZHVlIHRvIG5ldHdvcmsgdHJhbnNt aXNzaW9uIGRlbGF5cy4NCg0KUmVnYXJkcywNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQN Cg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB3251BESESSMB109erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLQ0KCXttc28t c3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgUm9tYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5XaGF0IGFib3V0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iZ21haWwtIj7igJzigKZtZWRpYSBwYWNrZXRzIGluIHRoZTwv c3Bhbj4gYW55IHByZXZpb3VzbHkgZXN0YWJsaXNoZWQ8c3BhbiBjbGFzcz0iZ21haWwtIj4gRFRM UyBhc3NvY2lhdGlvbiBhbmTigKbigJ08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VGhhdCBjb3ZlcnMgYm90aCB0aGUgY3VycmVudGx5IGVzdGFibGlzaGVk IGFuZCBhbHJlYWR5IGNsb3NlZCBhc3NvY2lhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hw b3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI4IE1h cmNoIDIwMTcgMDI6NTg8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQYXVsIEt5eml2 YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVkdSZndDs7IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMt c2RwLmFsbEBpZXRmLm9yZzsgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtICZsdDtnZW4tYXJ0QGll dGYub3JnJmd0OzsgSUVURiBNTVVTSUMgV0cgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyNywgMjAx NyBhdCA3OjQyIFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbC0iPiZndDtSZWdhcmRp bmcgdGhlIGZvbGxvd2luZyBpbiBzZWN0aW9uIDUuMTo8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImdtYWlsLSI+Jmd0Ozwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7Jm5ic3A7 ICZuYnNwOyBXaGVuIGFuIG9mZmVyZXIgb3IgYW5zd2VyZXIgaW5kaWNhdGVzIHRoYXQgaXQgd2Fu dHMgdG8gZXN0YWJsaXNoIGE8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyZu YnNwOyAmbmJzcDsgbmV3IERUTFMgYXNzb2NpYXRpb24sIGl0IG5lZWRzIHRvIG1ha2Ugc3VyZSB0 aGF0IG1lZGlhIHBhY2tldHMgaW4gdGhlPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0i PiZndDsmbmJzcDsgJm5ic3A7IGV4aXN0aW5nIERUTFMgYXNzb2NpYXRpb24gYW5kIG5ldyBEVExT IGFzc29jaWF0aW9uIGNhbiBiZSBkZS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+ Jmd0OyZuYnNwOyAmbmJzcDsgbXVsdGlwbGV4ZWQuPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJn bWFpbC0iPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0O1RoaXMgdGV4 dCBwcmVzdW1lcyB0aGVyZSBpcyBhbiBleGlzdGluZyBhc3NvY2lhdGlvbi4gVG8gZXhwbGljaXRs eSBjb3ZlciB0aGUgY2FzZSB3aGVyZSB0aGVyZSBpcyBub3QsIEkgc3VnZ2VzdCB0aGUgZm9sbG93 aW5nOjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7PC9zcGFuPjxicj4NCjxz cGFuIGNsYXNzPSJnbWFpbC0iPiZndDsmbmJzcDsgJm5ic3A7IFdoZW4gYW4gb2ZmZXJlciBvciBh bnN3ZXJlciBpbmRpY2F0ZXMgdGhhdCBpdCB3YW50cyB0byBlc3RhYmxpc2ggYTwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7Jm5ic3A7ICZuYnNwOyBuZXcgRFRMUyBhc3NvY2lh dGlvbiB0byByZXBsYWNlIGFuIGV4aXN0aW5nIGFzc29jaWF0aW9uLCBpdCBuZWVkcyB0bzwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0iZ21haWwtIj4mZ3Q7Jm5ic3A7ICZuYnNwOyBlbnN1cmUgdGhh dCBtZWRpYSBwYWNrZXRzIGluIHRoZSBleGlzdGluZyBEVExTIGFzc29jaWF0aW9uIGFuZCBuZXc8 L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyZuYnNwOyAmbmJzcDsgRFRMUyBh c3NvY2lhdGlvbiBjYW4gYmUgZGUtbXVsdGlwbGV4ZWQuPC9zcGFuPjxicj4NCjxicj4NCkkgY291 bGQgZG8gdGhhdC4gT3IsIEkgY291bGQgdXNlIHNheSAmcXVvdDttYWtlIHN1cmUgdGhhdCBtZWRp YSBwYWNrZXRzIGluICphbnkqIGV4aXN0aW5nIERUTFMgYXNzb2NpYXRpb24mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklm IHdlIGFyZSBuaXRwaWNraW5nIHdlIG5lZWQgdG8gZGVmaW5lIHdoYXQgJnF1b3Q7ZXhpc3Rpbmcm cXVvdDsgRFRMUyBhc3NvY2lhdGlvbiBtZWFucyBoZXJlLiBJbiB0aGlzIHBhcnRpY3VsYXIgY2Fz ZSB0aGlzIG1lYW5zIGFueSBEVExTIGFzc29jaWF0aW9uIGZvciB3aGljaCBpdCBzdGlsbCBwb3Nz aWJsZSB0byByZWNlaXZlIHBhY2tldHMuIFRoaXMgaW5jbHVkZXMgY3VycmVudGx5IGVzdGFibGlz aGVkIERUTFMgYXNzb2NpYXRpb25zDQogYXMgd2VsbCBhcyBhbnkgRFRMUyBhc3NvY2lhdGlvbiB3 aGljaCB3ZXJlIGNsb3NlZCBidXQgY2FuIHN0aWxsIHJlY2VpdmUgcGFja2V0cyBkdWUgdG8gbmV0 d29yayB0cmFuc21pc3Npb24gZGVsYXlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21h biBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB3251BESESSMB109erics_-- From nobody Tue Mar 28 08:10: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 84254128B88; Tue, 28 Mar 2017 08:10: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 FM80YjOarC-c; Tue, 28 Mar 2017 08:09:58 -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 C203A126DC2; Tue, 28 Mar 2017 08:09:57 -0700 (PDT) X-AuditID: c1b4fb3a-4d72198000003958-73-58da7cc360cb Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id 2C.B9.14680.3CC7AD85; Tue, 28 Mar 2017 17:09:56 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 17:09:54 +0200 From: Christer Holmberg To: Eric Rescorla , Magnus Westerlund CC: "rtcweb@ietf.org" , "mmusic (E-mail)" Thread-Topic: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration Thread-Index: AQHSnJ+WU4+3m4pcF0qxfvJ7Gpxl/aGnZncAgAFSZQCAAAfjgIAAC4yAgAGlD6A= Date: Tue, 28 Mar 2017 15:09:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB32788@ESESSMB109.ericsson.se> References: <8b2b8754-b10c-6f8e-6262-95cd25374a18@ericsson.com> <0827af95-b755-9730-6605-5146967760e7@ericsson.com> <29d1f31b-402c-5f31-8eee-f1f066ddce29@ericsson.com> <314d5af9-018d-8d15-7629-dbcc62fe5a2e@ericsson.com> <8743844f-3294-ec11-47d5-d642adf5fffc@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB32788ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7ge6RmlsRBkdW8lqseH2O3WLq8scs Fmv/tbM7MHssWfKTyWPy4zbmAKYoLpuU1JzMstQifbsErox5+1azFKxKrpg3fRJTA+OFhC5G Tg4JAROJY79esXUxcnEICaxnlFh85xwzhLOEUWLFhh1AGQ4ONgELie5/2iANIgJhEqtvnWEE sZkFfCSubFjFDmILC4RKPDt+lgWm5siNHUwQtp/E50+zwOpZBFQlzi/bBRbnFfCV6Nq3nBVi 1yp2ibtHWsGaOQUCJfb9OARWxCggJvH91BomiGXiEreezGeCuFpAYsme88wQtqjEy8f/WCFs JYnGJU9YIerzJU7v/McCsUxQ4uTMJywTGEVmIRk1C0nZLCRls4BeZhbQlFi/Sx+iRFFiSvdD dghbQ6J1zlx2ZPEFjOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQIj7OCW31Y7GA8+dzzE KMDBqMTD+0DqZoQQa2JZcWXuIUYJDmYlEd5v3EAh3pTEyqrUovz4otKc1OJDjNIcLErivA77 LkQICaQnlqRmp6YWpBbBZJk4OKUaGBX5rvUaaLzdsVqdbdXdQ8xPn7WlvPQ+Yt9RGa9uv+OB UGp4osf1xZXxGwVXs3cKn2gLCrfeGpfoX+/rbOH9JPZz3u3qvI+3OE/UfPt+IlelZLJiQH/d /tvVf5TeNN3LjJ1WviPonajJRzPGNecO7z320zUhcIKJbsjU27ruJ6qEg7d6Mv53VWIpzkg0 1GIuKk4EAMvMqPCsAgAA Archived-At: Subject: Re: [MMUSIC] [rtcweb] BUNDLE: Attempting to resolve security consideration 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, 28 Mar 2017 15:10:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB32788ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQpKdXN0IHRvIHZlcmlmeSwgYXJlIHlvdSBub3cgb2sgd2l0aCB0aGUgdGV4dCBp biB0aGUgUFI/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IG1tdXNpYyBbbWFpbHRv Om1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2Vu dDogMjcgTWFyY2ggMjAxNyAxOTowMg0KVG86IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb20+DQpDYzogcnRjd2ViQGlldGYub3JnOyBtbXVzaWMgKEUtbWFp bCkgPG1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbcnRjd2ViXSBCVU5E TEU6IEF0dGVtcHRpbmcgdG8gcmVzb2x2ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uDQoNCkxHVE0N Cg0KT24gTW9uLCBNYXIgMjcsIDIwMTcgYXQgMTA6MjEgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVy aWNzc29uLmNvbT4+IHdyb3RlOg0KRGVuIDIwMTctMDMtMjcga2wuIDA5OjUyLCBza3JldiBFcmlj IFJlc2NvcmxhOg0KDQoNCk9uIFN1biwgTWFyIDI2LCAyMDE3IGF0IDE6NDEgUE0sIE1hZ251cyBX ZXN0ZXJsdW5kDQo8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IDxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz b24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+Pj4NCndyb3RlOg0K DQogICAgSGksDQoNCiAgICBJIGhhdmUgYXR0ZW1wdGVkIHRvIGFkZHJlc3MgdGhlIGlzc3VlIGRp c2N1c3NlZCBiZWxvdyBieQ0KICAgIHJlZm9ybXVsYXRpbmcgdGhhdCBwYXJhZ3JhcGggdG8gcmVh ZDoNCg0KICAgICAgIFdoZW4gdGhlIEJVTkRMRSBleHRlbnNpb24gaXMgdXNlZCwgdGhlIHNldCBv ZiBjb25maWd1cmF0aW9ucyBvZiB0aGUNCiAgICAgICBzZWN1cml0eSBtZWNoYW5pc20gdXNlZCBp biBhbGwgdGhlIGJ1bmRsZWQgbWVkaWEgZGVzY3JpcHRpb25zIHdpbGwNCiAgICAgICBuZWVkIHRv IGJlIGNvbXBhdGlibGUgZm9yIHNpbXVsdGFuZW91c2x5IHVzZSwgYXQgbGVhc3QgcGVyIGRpcmVj dGlvbg0KICAgICAgIG9yIGVuZHBvaW50Lg0KDQoNCkknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQg d2hhdCAiY29tcGF0aWJsZSBmb3Igc2ltdWx0YW5lb3VzbHkgdXNlIiBtZWFucy4NCg0KVGhhdCBp ZiBvbmUgaGF2ZSBtdWx0aXBsZSBjb25maWd1cmF0aW9ucyB0aGV5IGNhbiBjby1leGlzdCBpbiB0 aGUgc2FtZSBCVU5ETEVEIGNvbnRleHQgYmVnaW5nIHVzZWQgaW4gcGFyYWxsZWwuIElzIHRoaXMg YmV0dGVyPw0KDQogICBXaGVuIHRoZSBCVU5ETEUgZXh0ZW5zaW9uIGlzIHVzZWQsIHRoZSBzZXQg b2YgY29uZmlndXJhdGlvbnMgb2YgdGhlDQogICBzZWN1cml0eSBtZWNoYW5pc20gdXNlZCBpbiBh bGwgdGhlIGJ1bmRsZWQgbWVkaWEgZGVzY3JpcHRpb25zIHdpbGwNCiAgIG5lZWQgdG8gYmUgY29t cGF0aWJsZSBzbyB0aGF0IHRoZXkgY2FuIHNpbXVsdGFuZW91c2x5IHVzZWQgaW4NCiAgIHBhcmFs bGVsLCBhdCBsZWFzdCBwZXIgZGlyZWN0aW9uIG9yIGVuZHBvaW50Lg0KDQoNCg0KQ2hlZXJzDQoN Cg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTWVkaWEgVGVjaG5vbG9naWVz LCBFcmljc3NvbiBSZXNlYXJjaA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAg ICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3PHRlbDolMkI0NiUyMDEwJTIwNzE0ODI4Nz4N CkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5PHRl bDolMkI0NiUyMDczJTIwMDk0OTA3OT4NClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1h aWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB32788ESESSMB109erics_ 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 cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBFa3IsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5KdXN0IHRvIHZlcmlmeSwgYXJlIHlvdSBub3cg b2sgd2l0aCB0aGUgdGV4dCBpbiB0aGUgUFI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMgW21h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBS ZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiAyNyBNYXJjaCAyMDE3IDE5OjAyPGJyPg0KPGI+VG86 PC9iPiBNYWdudXMgV2VzdGVybHVuZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gcnRjd2ViQGlldGYub3JnOyBtbXVzaWMgKEUtbWFpbCkgJmx0 O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIFty dGN3ZWJdIEJVTkRMRTogQXR0ZW1wdGluZyB0byByZXNvbHZlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MR1RNPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciAyNywgMjAxNyBh dCAxMDoyMSBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZW4gMjAxNy0wMy0yNyBrbC4gMDk6NTIsIHNrcmV2IEVy aWMgUmVzY29ybGE6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpPbiBTdW4sIE1h ciAyNiwgMjAxNyBhdCAxOjQxIFBNLCBNYWdudXMgV2VzdGVybHVuZDxicj4NCiZsdDs8YSBocmVm PSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+Jmd0OyZndDs8YnI+DQp3cm90ZTo8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IEhpLDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBoYXZlIGF0 dGVtcHRlZCB0byBhZGRyZXNzIHRoZSBpc3N1ZSBkaXNjdXNzZWQgYmVsb3cgYnk8YnI+DQombmJz cDsgJm5ic3A7IHJlZm9ybXVsYXRpbmcgdGhhdCBwYXJhZ3JhcGggdG8gcmVhZDo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtXaGVuIHRoZSBCVU5ETEUgZXh0ZW5zaW9uIGlz IHVzZWQsIHRoZSBzZXQgb2YgY29uZmlndXJhdGlvbnMgb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7c2VjdXJpdHkgbWVjaGFuaXNtIHVzZWQgaW4gYWxsIHRoZSBidW5kbGVk IG1lZGlhIGRlc2NyaXB0aW9ucyB3aWxsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 bmVlZCB0byBiZSBjb21wYXRpYmxlIGZvciBzaW11bHRhbmVvdXNseSB1c2UsIGF0IGxlYXN0IHBl ciBkaXJlY3Rpb248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvciBlbmRwb2ludC48 YnI+DQo8YnI+DQo8YnI+DQpJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgJnF1b3Q7Y29t cGF0aWJsZSBmb3Igc2ltdWx0YW5lb3VzbHkgdXNlJnF1b3Q7IG1lYW5zLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhhdCBpZiBvbmUg aGF2ZSBtdWx0aXBsZSBjb25maWd1cmF0aW9ucyB0aGV5IGNhbiBjby1leGlzdCBpbiB0aGUgc2Ft ZSBCVU5ETEVEIGNvbnRleHQgYmVnaW5nIHVzZWQgaW4gcGFyYWxsZWwuIElzIHRoaXMgYmV0dGVy Pzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtXaGVuIHRoZSBCVU5ETEUgZXh0ZW5zaW9uIGlzIHVz ZWQsIHRoZSBzZXQgb2YgY29uZmlndXJhdGlvbnMgb2YgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3Nl Y3VyaXR5IG1lY2hhbmlzbSB1c2VkIGluIGFsbCB0aGUgYnVuZGxlZCBtZWRpYSBkZXNjcmlwdGlv bnMgd2lsbDxicj4NCiZuYnNwOyAmbmJzcDtuZWVkIHRvIGJlIGNvbXBhdGlibGUgc28gdGhhdCB0 aGV5IGNhbiBzaW11bHRhbmVvdXNseSB1c2VkIGluPGJyPg0KJm5ic3A7ICZuYnNwO3BhcmFsbGVs LCBhdCBsZWFzdCBwZXIgZGlyZWN0aW9uIG9yIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCjxicj4NCjxicj4NCkNoZWVyczxicj4NCjxicj4NCjxicj4NCk1hZ251cyBXZXN0 ZXJsdW5kPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCk1lZGlhIFRlY2hub2xvZ2llcywg RXJpY3Nzb24gUmVzZWFyY2g8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KRXJpY3Nzb24gQUImbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3wgUGhvbmUmbmJzcDsgPGEgaHJlZj0idGVsOiUyQjQ2JTIwMTAlMjA3MTQ4Mjg3IiB0YXJnZXQ9 Il9ibGFuayI+DQomIzQzOzQ2IDEwIDcxNDgyODc8L2E+PGJyPg0KRsOkcsO2Z2F0YW4gNiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 fCBNb2JpbGUgPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzMlMjAwOTQ5MDc5IiB0YXJnZXQ9Il9ibGFu ayI+DQomIzQzOzQ2IDczIDA5NDkwNzk8L2E+PGJyPg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dl ZGVuIHwgbWFpbHRvOiA8YSBocmVmPSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tIiB0YXJnZXQ9Il9ibGFuayI+DQptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+ PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB32788ESESSMB109erics_-- From nobody Tue Mar 28 08:26: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 85FA512940E for ; Tue, 28 Mar 2017 08:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] 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 s6AcQIiy8tM6 for ; Tue, 28 Mar 2017 08:26:39 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 2D2B6129686 for ; Tue, 28 Mar 2017 08:26:39 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-06v.sys.comcast.net with SMTP id st11cWOh7l4eqst14cFR2e; Tue, 28 Mar 2017 15:26:38 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-12v.sys.comcast.net with SMTP id st13c95LnqoNEst14cWvrD; Tue, 28 Mar 2017 15:26:38 +0000 To: Christer Holmberg , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB324DF@ESESSMB109.ericsson.se> Cc: General Area Review Team , IETF MMUSIC WG From: Paul Kyzivat Message-ID: <396d9a7d-892c-2731-5e56-e42836a43072@alum.mit.edu> Date: Tue, 28 Mar 2017 11:26:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB324DF@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDEok2DvLbIGNqkekiXvZD48eBcDTFnaPX/yNl8FcviriDY1jz4lDvOWETVAwhHEh+UuIx8E/+nvvIoVmlhfHyiImLihz0L1H0LdCkrITDC6hJ7zaQkp nq/ANfRxO7gUthZzqESSUR25djgPXmcF9IsFhMs2BC2+6jPm8eH9VXzMJyFpy4q66Mut7oPkNPS7//qKIGWTaFRY3K0Poq+mVPx1Ly4+99w6k4WSs3RVo8vG uM3/+fX0GR8ULvIrd1V7E+Ceb2LgYAg9TzWkl0IF14dw+3HFwz/Zs86H1jRAZFDi Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 28 Mar 2017 15:26:40 -0000 On 3/28/17 10:40 AM, Christer Holmberg wrote: > Hi, > > ... > > (3) Minor: > >>>> I concur with the comments in the ops-dir review by Carlos Pignataro >>>> regarding the formatting of section 9. He didn't suggest a fix. >>>> Perhaps some special marker (e.g. "|" or "<" and ">") can be placed in every line to indicate it >>>> is test from or for another document - either at the beginning or end of every line. >>> >>> I have never seen that been used before - not in documents I have authored, or in documents written by others. >> >> Yes, I know. I was just trying to be constructive by suggesting *something*. My first thought was to indent. >> >> But that would require reflowing all the text to avoid exceeding line length. That seemed like a bad idea. >> >> I'm not attached to this solution. I've complained about the same problem in other drafts, but nobody came >> up with a solution so they didn't get resolved. Here I'm not the only one who sees a problem, so maybe it is >> worth trying to find a solution. > > I don't have a problem to add e.g. "|", if that's what people want to do, but my preference would be to not do anything in this draft, at this point of time. Since Carlos Pignataro also commented on this in a different review, it would be good to see what he thinks. (He isn't on *this* thread.) Also, what do others in the WG think? Thanks, Paul From nobody Tue Mar 28 09:01: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 1342C127871; Tue, 28 Mar 2017 09:01:18 -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 QxvDPyQfZzPk; Tue, 28 Mar 2017 09:01:16 -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 C3A9C1294CE; Tue, 28 Mar 2017 09:01:10 -0700 (PDT) X-AuditID: c1b4fb3a-4d72198000003958-dd-58da88c4b64f Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 9F.C2.14680.4C88AD85; Tue, 28 Mar 2017 18:01:08 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:00:52 +0200 From: Christer Holmberg To: "cpignata@cisco.com" CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Re: Review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AdKn2P/3kP9b7RTPScO/+C/SvNdcJg== Date: Tue, 28 Mar 2017 16:00:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB3298B@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7hO6RjlsRBhP7zC0+vdvBYrHj7g42 i2cb57NYTF3+mMWBxWPK742sHkuW/GQKYIrisklJzcksSy3St0vgypi79CljwUrJiimHtzA3 MHaIdDFyckgImEhMvdHA3sXIxSEksJ5R4uXiH4wQzhJGiXdHJ7B2MXJwsAlYSHT/0wZpEBHQ lTjbfpEZpIZZYCGjxPeznxhBEsJAkz4sXsoIUWQp8WfKZhYIW0+id88KJhCbRUBVYtfph2wg Nq+Ar8T6/mawOKOAmMT3U2vAbGYBcYlbT+YzQVwnILFkz3lmCFtU4uXjf6wQtpJE45InrBD1 OhILdn9ig7C1JZYtfM0MMV9Q4uTMJywTGIVnIRk7C0nLLCQts5C0LGBkWcUoWpxaXJybbmSk l1qUmVxcnJ+nl5dasokRGA0Ht/y22sF48LnjIUYBDkYlHt4HUjcjhFgTy4orcw8xSnAwK4nw fuMGCvGmJFZWpRblxxeV5qQWH2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cC4oful z/7zn+odlosF1Ww1uM4SIlHnm7Hwb9yNxIVFuZn+Hzt+PdzmEddvxCxVzHfiloLsMYNk/7s5 rtlX9TObOne/cpQJLCtYcC8tWWRaZmPE54KkzUuX7ngpf7TKObShx8835OwmJSGXtkkH333e v8RmS/NkhswNu//PrPYW0J9tZxZn/VmJpTgj0VCLuag4EQA7DDyhggIAAA== Archived-At: Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-dtls-sdp-22 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, 28 Mar 2017 16:01:18 -0000 Hi Carlos, Thanks for your review! Please see inline. >Reviewer: Carlos Pignataro >Review result: Has Nits > >This document is very comprehensive. Operational Considerations are >adequately covered. > >In reviewing this document, I did find two adjacent issues that I >thought useful to comment on: > >1. Clarity and Readability of Section 9 > >I appreciate the explicit OLD/NEW details and specifics on what is >changed on the updated RFCs. I wish more documents would do this! > >However, the way in which this is done is very confusing and not >really optimizing clarity and readability. It is an operational issue >an implementor not understanding the spec :-) > >The issue, in my view, is with the labels and markers. Subsections of >Section 9.2 do not follow the semantic structure of the document. >Instead they are included as follows: >" >Update to section 5: >-------------------- >" >Which are then followed by OLD/NEW chunks. However, these chunks: >* include Section numbers and titles,=20 >* do not have extra indentation, and >* include only BEGIN marker but not END marker. > >Like: > >9.2. Update to RFC 5763 >Update to section 5: >-------------------- >OLD TEXT: >5. Establishing a Secure Channel > >[... and then, two pages later ...] > >NEW TEXT: >5. Establishing a Secure Channel > >I'd suggest: >a. Using Section 9.2.1, 9.2.2, etc. for each change. I can put each section change in a separate section. 9.2.1 Update to section 5 9.2.2 Update to section 6.6 ... Or, do you want to have the old and new text in different sections too? Per= sonally I would like to keep the old and new text in the same section. >b. Use more explicit chunk demarkators It was been suggested to use "|".=20 >c. Use beginning and ending markers. [BEGIN] Blah blah blah... [END] ---------- >2. The second issue, and likely this was discussed, relates to the use >of RFC 4572. A reference to RFC 4572 is Normative, and it is cited >within "NEW" text (not only "OLD" text). However RFC 4572 has been >Obsoleted by RFC 8122! > >This is because draft-ietf-mmusic-4572-update published as RFC 8122, >which should be updated.=20 Correct. I will do that in the next version. >But for example, why does NEW text here still points to RFC 4572? The reason is probably that, initially draft-4572-update did not obsolete R= FC 4572 - it simply updated it. But, later it was agreed that draft-4572-up= date will obsolete RFC 4572, but that was not reflected in draft-dtls-sdp. So, you are correct, the new text shall point to RFC 8122. I will fix that = in the next version. --------- >--->8--- >NEW TEXT: > >5. Establishing a Secure Channel > > The two endpoints in the exchange present their identities as part > of the DTLS handshake procedure using certificates. This document > uses certificates in the same style as described in "Connection-Oriente= d > Media Transport over the Transport Layer Security (TLS) Protocol > in the Session Description Protocol (SDP)" [RFC4572]. > --->8--- > > And why RFC 4572 is Normatively referenced? I will make the reference Informative. Thanks! Regards, Christer From nobody Tue Mar 28 10:00: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 4758E1296FB for ; Tue, 28 Mar 2017 10:00:44 -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=unavailable 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 4kVV0QXJVQbE for ; Tue, 28 Mar 2017 10:00:37 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 189741296D8 for ; Tue, 28 Mar 2017 10:00:31 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id n5so70507426pgh.0 for ; Tue, 28 Mar 2017 10:00:31 -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=YdQ8xwnvw7ymOvLu8KYcwOhx3A2RfB6Lk48u0PMhWIQ=; b=I7wePxP5nNZfQx3OIN+5o0TK2klZxNJsnNWNLZqXOH3x0Uz7ni520oMIZJySG7lUL0 shQPtlpgXqzS5UR4WsDW/XiEcTYZBzGycClPhBdfdpWTlXTn36+fwryeqCvnyi/6mVjz 8W62ueT/30hdqFUiAHl7ThvPf9x9yJfn4MEZgLYpuYnd669A79TpBh51EWpvzX6M/JCM 0lFjARB9E8KwyVFQsLy9snG2BCFPi9gOl7czR7owNm+iZTlnNvSBpIbal2xFDxVdvlHQ SuM/CvBqSQHfl36lCeOWPSbcf1tSrTseDRPNm+EiEQuYiiqt6BPcjAg63VvcazpEW/ns B2Vw== 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=YdQ8xwnvw7ymOvLu8KYcwOhx3A2RfB6Lk48u0PMhWIQ=; b=O/9YS11IMdnCa2vl0MQe8AnLlpKDJQuL5kkiDFwIlFYrj9byUVvx+F1Nk6h1qXlHID HD4m/LcO5Tlp+MkMJ/hIBr9rVzrZZkmXoH5+h+3CnCgvlOIXVlXtlQjUTJbYl7G2hvC/ pVTlz5e8y9ci19Ggcxt/MYoNZxuW2KMXrDv/j3oQ46tmcJ0ShQEknkpZlJjh0emoKjyN 7vcmDjiSN/e+dqTfTG4BxhZa1bMgQ4YWBpYS9LodXyDedE8FA3WavnXSq61JVU8KxHG1 xLuK9CIJfH8s4wDOWZM/UikjOdn28425hIrZgeFOIPd/50GMqCTHByGhD6xgOb7t3hRi tMaA== X-Gm-Message-State: AFeK/H0OdCAmS0DATnWInBmC1FhmtX+dEKrUOIC/MErMLsVbg2BpGJGJSQjRItzIo7Bx5g== X-Received: by 10.99.61.201 with SMTP id k192mr31669643pga.68.1490720430654; Tue, 28 Mar 2017 10:00:30 -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 d3sm8566907pfd.57.2017.03.28.10.00.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 10:00:29 -0700 (PDT) Received: by mail-pg0-f52.google.com with SMTP id n5so70506934pgh.0; Tue, 28 Mar 2017 10:00:29 -0700 (PDT) X-Received: by 10.99.127.12 with SMTP id a12mr2654438pgd.5.1490720429608; Tue, 28 Mar 2017 10:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Tue, 28 Mar 2017 10:00:28 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB3251B@ESESSMB109.ericsson.se> References: <60b45113-8012-9a6c-2019-dea5b57ca7bb@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CB31018@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB3251B@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 28 Mar 2017 13:00:28 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Content-Type: multipart/alternative; boundary=f403045e2b6eaa9b4f054bcd65ae Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-22 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, 28 Mar 2017 17:00:44 -0000 --f403045e2b6eaa9b4f054bcd65ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Christer, This sounds good to me. Regards, _____________ Roman Shpount On Tue, Mar 28, 2017 at 10:44 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Roman, > > > > What about: > > > > =E2=80=9C=E2=80=A6media packets in the any previously established DTLS as= sociation and=E2=80=A6=E2=80=9D > > > > That covers both the currently established and already closed association= s. > > > > Regards, > > > > Christer > > > > > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* 28 March 2017 02:58 > *To:* Christer Holmberg > *Cc:* Paul Kyzivat ; draft-ietf-mmusic-dtls-sdp. > all@ietf.org; General Area Review Team ; IETF MMUSIC WG > > *Subject:* Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of > draft-ietf-mmusic-dtls-sdp-22 > > > > Hi All, > > > > > On Mon, Mar 27, 2017 at 7:42 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > >Regarding the following in section 5.1: > > > > When an offerer or answerer indicates that it wants to establish a > > new DTLS association, it needs to make sure that media packets in th= e > > existing DTLS association and new DTLS association can be de- > > multiplexed. > > > >This text presumes there is an existing association. To explicitly cover > the case where there is not, I suggest the following: > > > > When an offerer or answerer indicates that it wants to establish a > > new DTLS association to replace an existing association, it needs to > > ensure that media packets in the existing DTLS association and new > > DTLS association can be de-multiplexed. > > I could do that. Or, I could use say "make sure that media packets in > *any* existing DTLS association" > > > > If we are nitpicking we need to define what "existing" DTLS association > means here. In this particular case this means any DTLS association for > which it still possible to receive packets. This includes currently > established DTLS associations as well as any DTLS association which were > closed but can still receive packets due to network transmission delays. > > > > Regards, > > _____________ > Roman Shpount > > > --f403045e2b6eaa9b4f054bcd65ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christer,

This sounds good to = me.

Regards,

_____________
Roman Shpount

On Tue, Mar 28, 2017 at 10:44 AM, Christer H= olmberg <christer.holmberg@ericsson.com> wrote:=

Hi Roman,

=C2=A0

What about:

=C2=A0

=E2=80= =9C=E2=80=A6media packets in the any previously established DTLS association and=E2=80=A6=E2=80=9D=

=C2=A0

That covers both the currently establ= ished and already closed associations.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

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

From: = Roman Shpount [mailto:roman@telurix.com]
Sent: 28 March 2017 02:58
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; draft-ietf-mmusic-dtls-sdp.all@ietf.org; General Area Review Team <gen-art@ietf.org>; IETF MMUSIC WG <mmusic@ietf.org><= br> Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ie= tf-mmusic-dtls-sdp-22

=C2=A0

Hi All,


=C2=A0

On Mon, Mar 27, 2017 at 7:42 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

>Reg= arding the following in section 5.1:
>
>=C2=A0 =C2=A0 When an offe= rer or answerer indicates that it wants to establish a
>=C2=A0 =C2=A0 new DTLS ass= ociation, it needs to make sure that media packets in the
>=C2=A0 =C2=A0 existing DTL= S association and new DTLS association can be de-
>=C2=A0 =C2=A0 multiplexed.=
>
>This text presumes there i= s an existing association. To explicitly cover the case where there is not,= I suggest the following:
>
>=C2=A0 =C2=A0 When an offe= rer or answerer indicates that it wants to establish a
>=C2=A0 =C2=A0 new DTLS ass= ociation to replace an existing association, it needs to
>=C2=A0 =C2=A0 ensure that = media packets in the existing DTLS association and new
>=C2=A0 =C2=A0 DTLS associa= tion can be de-multiplexed.

I could do that. Or, I could use say "make sure that media packets in = *any* existing DTLS association"

=C2=A0

If we are nitpicking we need to define what "ex= isting" DTLS association means here. In this particular case this mean= s any DTLS association for which it still possible to receive packets. This= includes currently established DTLS associations as well as any DTLS association which were closed but can still receive pa= ckets due to network transmission delays.

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0


--f403045e2b6eaa9b4f054bcd65ae-- From nobody Thu Mar 30 09:14: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 B61F9129631; Thu, 30 Mar 2017 09:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 szimti7CGMRy; Thu, 30 Mar 2017 09:13:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C829612997E; Thu, 30 Mar 2017 09:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5288; q=dns/txt; s=iport; t=1490890432; x=1492100032; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rJB4pQa5I/S7VqwMNoWxZOViQg5tF/Mp+EXm5eOD+lc=; b=avY70Sh7Df6t3ZfbNUyW6a65ZIGjHx0cL+eT/7yZcbgGkJ0mEomeQcLU TCe/cWRp5FKUC884stiGS2pUEHpFP0G2tlW1N7YBKs8Pi/pZM5OnkEHJG phibfTa22MGZ5PnNXglmooaE3Y+SAqxv2CCzASGsV4JDPc+6H7MqZxVge Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAgBoLt1Y/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1aBbAeDW4oRkTMflVCCDoYiAhqDHD8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQECASMEDUUFCwIBCBgCAiYCAgIwFRABAQQOBYoDCK4KgWw6ilUBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgQuFQ4IFCIFZgQmHWi6CMQEEiSKMdoZSAZJPgXyFKoo?= =?us-ascii?q?RiFmLEwEfOIEFWxVSAYRHHYFjdYgHgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,247,1486425600"; d="scan'208";a="405245993" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2017 16:13:36 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v2UGDa6k022073 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Mar 2017 16:13:36 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 12:13:35 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 12:13:35 -0400 From: "Carlos Pignataro (cpignata)" To: Christer Holmberg CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AdKn2P/3kP9b7RTPScO/+C/SvNdcJgBuRuYA Date: Thu, 30 Mar 2017 16:13:35 +0000 Message-ID: <8F8DC522-9FF6-4414-9E02-95211155A87C@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B4CB3298B@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB3298B@ESESSMB109.ericsson.se> 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.82.169.56] Content-Type: text/plain; charset="utf-8" Content-ID: <92CD995A2BABA04794D28942B85EE1CC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-dtls-sdp-22 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, 30 Mar 2017 16:13:57 -0000 SGksIENocmlzdGVyLA0KDQo+IE9uIE1hciAyOCwgMjAxNywgYXQgMTI6MDAgUE0sIENocmlzdGVy IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4g SGkgQ2FybG9zLA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIHJldmlldyEgUGxlYXNlIHNlZSBpbmxp bmUuDQoNCkFueXRpbWUg4oCUIHRoYW5rcyBmb3IgdGhlIGZvbGxvdy11cCENCg0KPiANCj4+IFJl dmlld2VyOiBDYXJsb3MgUGlnbmF0YXJvDQo+PiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KPj4g DQo+PiBUaGlzIGRvY3VtZW50IGlzIHZlcnkgY29tcHJlaGVuc2l2ZS4gT3BlcmF0aW9uYWwgQ29u c2lkZXJhdGlvbnMgYXJlDQo+PiBhZGVxdWF0ZWx5IGNvdmVyZWQuDQo+PiANCj4+IEluIHJldmll d2luZyB0aGlzIGRvY3VtZW50LCBJIGRpZCBmaW5kIHR3byBhZGphY2VudCBpc3N1ZXMgdGhhdCBJ DQo+PiB0aG91Z2h0IHVzZWZ1bCB0byBjb21tZW50IG9uOg0KPj4gDQo+PiAxLiBDbGFyaXR5IGFu ZCBSZWFkYWJpbGl0eSBvZiBTZWN0aW9uIDkNCj4+IA0KPj4gSSBhcHByZWNpYXRlIHRoZSBleHBs aWNpdCBPTEQvTkVXIGRldGFpbHMgYW5kIHNwZWNpZmljcyBvbiB3aGF0IGlzDQo+PiBjaGFuZ2Vk IG9uIHRoZSB1cGRhdGVkIFJGQ3MuIEkgd2lzaCBtb3JlIGRvY3VtZW50cyB3b3VsZCBkbyB0aGlz IQ0KPj4gDQo+PiBIb3dldmVyLCB0aGUgd2F5IGluIHdoaWNoIHRoaXMgaXMgZG9uZSBpcyB2ZXJ5 IGNvbmZ1c2luZyBhbmQgbm90DQo+PiByZWFsbHkgb3B0aW1pemluZyBjbGFyaXR5IGFuZCByZWFk YWJpbGl0eS4gSXQgaXMgYW4gb3BlcmF0aW9uYWwgaXNzdWUNCj4+IGFuIGltcGxlbWVudG9yIG5v dCB1bmRlcnN0YW5kaW5nIHRoZSBzcGVjIDotKQ0KPj4gDQo+PiBUaGUgaXNzdWUsIGluIG15IHZp ZXcsIGlzIHdpdGggdGhlIGxhYmVscyBhbmQgbWFya2Vycy4gU3Vic2VjdGlvbnMgb2YNCj4+IFNl Y3Rpb24gOS4yIGRvIG5vdCBmb2xsb3cgdGhlIHNlbWFudGljIHN0cnVjdHVyZSBvZiB0aGUgZG9j dW1lbnQuDQo+PiBJbnN0ZWFkIHRoZXkgYXJlIGluY2x1ZGVkIGFzIGZvbGxvd3M6DQo+PiAiDQo+ PiBVcGRhdGUgdG8gc2VjdGlvbiA1Og0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ICINCj4+ IFdoaWNoIGFyZSB0aGVuIGZvbGxvd2VkIGJ5IE9MRC9ORVcgY2h1bmtzLiBIb3dldmVyLCB0aGVz ZSBjaHVua3M6DQo+PiAqIGluY2x1ZGUgU2VjdGlvbiBudW1iZXJzIGFuZCB0aXRsZXMsIA0KPj4g KiBkbyBub3QgaGF2ZSBleHRyYSBpbmRlbnRhdGlvbiwgYW5kDQo+PiAqIGluY2x1ZGUgb25seSBC RUdJTiBtYXJrZXIgYnV0IG5vdCBFTkQgbWFya2VyLg0KPj4gDQo+PiBMaWtlOg0KPj4gDQo+PiA5 LjIuICBVcGRhdGUgdG8gUkZDIDU3NjMNCj4+IFVwZGF0ZSB0byBzZWN0aW9uIDU6DQo+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPj4gT0xEIFRFWFQ6DQo+PiA1LiAgRXN0YWJsaXNoaW5nIGEgU2Vj dXJlIENoYW5uZWwNCj4+IA0KPj4gWy4uLiBhbmQgdGhlbiwgdHdvIHBhZ2VzIGxhdGVyIC4uLl0N Cj4+IA0KPj4gTkVXIFRFWFQ6DQo+PiA1LiAgRXN0YWJsaXNoaW5nIGEgU2VjdXJlIENoYW5uZWwN Cj4+IA0KPj4gSSdkIHN1Z2dlc3Q6DQo+PiBhLiBVc2luZyBTZWN0aW9uIDkuMi4xLCA5LjIuMiwg ZXRjLiBmb3IgZWFjaCBjaGFuZ2UuDQo+IA0KPiBJIGNhbiBwdXQgZWFjaCBzZWN0aW9uIGNoYW5n ZSBpbiBhIHNlcGFyYXRlIHNlY3Rpb24uDQo+IA0KPiA5LjIuMSBVcGRhdGUgdG8gc2VjdGlvbiA1 DQo+IDkuMi4yIFVwZGF0ZSB0byBzZWN0aW9uIDYuNg0KPiAuLi4NCj4gDQo+IE9yLCBkbyB5b3Ug d2FudCB0byBoYXZlIHRoZSBvbGQgYW5kIG5ldyB0ZXh0IGluIGRpZmZlcmVudCBzZWN0aW9ucyB0 b28/IFBlcnNvbmFsbHkgSSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIG9sZCBhbmQgbmV3IHRleHQg aW4gdGhlIHNhbWUgc2VjdGlvbi4NCg0KSSBhZ3JlZS4gSGF2aW5nIGEgc2VjdGlvbiBmb3IgZWFj aCBjaGFuZ2UgY2h1bmsgKE9MRC9ORVcpIHNlZW1zIG1vc3QgY2xlYW4gYW5kIGNsZWFyLg0KDQo+ IA0KPj4gYi4gVXNlIG1vcmUgZXhwbGljaXQgY2h1bmsgZGVtYXJrYXRvcnMNCj4gDQo+IEl0IHdh cyBiZWVuIHN1Z2dlc3RlZCB0byB1c2UgInwiLiANCj4gDQo+PiBjLiBVc2UgYmVnaW5uaW5nIGFu ZCBlbmRpbmcgbWFya2Vycy4NCj4gDQo+IFtCRUdJTl0NCj4gQmxhaCBibGFoIGJsYWguLi4NCj4g W0VORF0NCj4gDQo+IC0tLS0tLS0tLS0NCg0KVGhhbmsgeW91IOKAlCBhbnkgZm9ybWF0IHRoYXQg eW91IGZlZWwgd2lsbCBhZGQgY2xhcml0eS4gUmlnaHQgbm93IGl0IHdhcyBhIGJpdCBjaGFsbGVu Z2luZyB0byBwYXJzZS4NCg0KPiANCj4+IDIuIFRoZSBzZWNvbmQgaXNzdWUsIGFuZCBsaWtlbHkg dGhpcyB3YXMgZGlzY3Vzc2VkLCByZWxhdGVzIHRvIHRoZSB1c2UNCj4+IG9mIFJGQyA0NTcyLiBB IHJlZmVyZW5jZSB0byBSRkMgNDU3MiBpcyBOb3JtYXRpdmUsIGFuZCBpdCBpcyBjaXRlZA0KPj4g d2l0aGluICJORVciIHRleHQgKG5vdCBvbmx5ICJPTEQiIHRleHQpLiBIb3dldmVyIFJGQyA0NTcy IGhhcyBiZWVuDQo+PiBPYnNvbGV0ZWQgYnkgUkZDIDgxMjIhDQo+PiANCj4+IFRoaXMgaXMgYmVj YXVzZSBkcmFmdC1pZXRmLW1tdXNpYy00NTcyLXVwZGF0ZSBwdWJsaXNoZWQgYXMgUkZDIDgxMjIs DQo+PiB3aGljaCBzaG91bGQgYmUgdXBkYXRlZC4gDQo+IA0KPiBDb3JyZWN0LiBJIHdpbGwgZG8g dGhhdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpBY2suIFRoYW5rcy4NCg0KPiANCj4+IEJ1dCBm b3IgZXhhbXBsZSwgd2h5IGRvZXMgTkVXIHRleHQgaGVyZSBzdGlsbCBwb2ludHMgdG8gUkZDIDQ1 NzI/DQo+IA0KPiBUaGUgcmVhc29uIGlzIHByb2JhYmx5IHRoYXQsIGluaXRpYWxseSBkcmFmdC00 NTcyLXVwZGF0ZSBkaWQgbm90IG9ic29sZXRlIFJGQyA0NTcyIC0gaXQgc2ltcGx5IHVwZGF0ZWQg aXQuIEJ1dCwgbGF0ZXIgaXQgd2FzIGFncmVlZCB0aGF0IGRyYWZ0LTQ1NzItdXBkYXRlIHdpbGwg b2Jzb2xldGUgUkZDIDQ1NzIsIGJ1dCB0aGF0IHdhcyBub3QgcmVmbGVjdGVkIGluIGRyYWZ0LWR0 bHMtc2RwLg0KPiANCj4gU28sIHlvdSBhcmUgY29ycmVjdCwgdGhlIG5ldyB0ZXh0IHNoYWxsIHBv aW50IHRvIFJGQyA4MTIyLiBJIHdpbGwgZml4IHRoYXQgaW4gdGhlIG5leHQgdmVyc2lvbi4NCj4g DQoNClBlcmZlY3QuDQoNCj4gLS0tLS0tLS0tDQo+IA0KPj4gLS0tPjgtLS0NCj4+IE5FVyBURVhU Og0KPj4gDQo+PiA1LiAgRXN0YWJsaXNoaW5nIGEgU2VjdXJlIENoYW5uZWwNCj4+IA0KPj4gIFRo ZSB0d28gZW5kcG9pbnRzIGluIHRoZSBleGNoYW5nZSBwcmVzZW50IHRoZWlyIGlkZW50aXRpZXMg YXMgcGFydA0KPj4gIG9mIHRoZSBEVExTIGhhbmRzaGFrZSBwcm9jZWR1cmUgdXNpbmcgY2VydGlm aWNhdGVzLiBUaGlzIGRvY3VtZW50DQo+PiAgdXNlcyBjZXJ0aWZpY2F0ZXMgaW4gdGhlIHNhbWUg c3R5bGUgYXMgZGVzY3JpYmVkIGluICJDb25uZWN0aW9uLU9yaWVudGVkDQo+PiAgTWVkaWEgVHJh bnNwb3J0IG92ZXIgdGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQcm90b2NvbA0K Pj4gIGluIHRoZSBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIiBbUkZDNDU3Ml0u DQo+PiAtLS0+OC0tLQ0KPj4gDQo+PiBBbmQgd2h5IFJGQyA0NTcyIGlzIE5vcm1hdGl2ZWx5IHJl ZmVyZW5jZWQ/DQo+IA0KPiBJIHdpbGwgbWFrZSB0aGUgcmVmZXJlbmNlIEluZm9ybWF0aXZlLg0K PiANCg0KTG9va3MgZ29vZCDigJQgdGhhbmtzIGFnYWluLA0KDQrigJQgQ2FybG9zLg0KDQo+IFRo YW5rcyENCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCg0K From nobody Thu Mar 30 12:14: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 512F1126B6D for ; Thu, 30 Mar 2017 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, 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 tJoj0np3gt2B for ; Thu, 30 Mar 2017 12:14:40 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 02D16126B72 for ; Thu, 30 Mar 2017 12:14:39 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id d201so19156617qkc.0 for ; Thu, 30 Mar 2017 12:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y98aApw3WqICzHZ0C9UODhP9r36V3IXoXMJTgbrY7Lk=; b=Om6ZkRmRrdqW3mImAf7FznN04+OwrCsIDjpW4pWduUP+H3OFWsRdVQF50wDWO62ZXp 47kaQWONusd4KW8jBCWKQ2pR45oZe6AKjThn6V8oKV0vyk3nbfvjtHa4n9lRVzMZujii 6sJ0jn43x/Ewvf5N2UTx2fBF1Rm5oS12KW4gTPPuppKQdI1PCtF4crV8hT4tCPuvNQia qXn4WLZN6abzn8A2WBfSDQfGG3YWsXEQCrVku3OPRprEi7e0WjAW2dQ+mHoZVCaimS2S lJNFXgdgjlTCbpB93kMsO1c2EnWlf9powwWy5gbb9tu2oGp/zHAq/yCOmVl+2nYzjUDf 0r/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y98aApw3WqICzHZ0C9UODhP9r36V3IXoXMJTgbrY7Lk=; b=FTNr2CaE+cdfNeKnjenRLTVdCOJaAzcdxQDTT/EjDA0fmpyYpBCEMbInL+DgxVuwH9 pYSQLdnt0k7AD5ziyIxuEx5DJGYrXkuKosPXvzm4MyGLX1Y63sl1/JWVZ/E2jRrqQ33K uP+aO/XhI3OvuwfHZWjcnwSuOTXhttKFcvsKNK5cMe+qT/tVAQ+R/cn6qh8sjQv9yDpN rKenEFcuGawTeDS7jFhIs9P5biLqDgc3ZBdnNb4TWjsQmALQLmMHer4neqyyS+nwFt/o 3O31OAvSuk1nyeMF3Ed47hl1vPyXNzS+fZ2WmTIdPB0PE1DzAEm40T/OkyoU0VNFSTn1 SOJQ== X-Gm-Message-State: AFeK/H15JQP9fA5xdGPYVLnfpQ0a1hvFhZpl0eo1I8qgyV6I97YDkbBjKgSp5RVKUgiO+LiT5C8INqCX4jDMuYX6 X-Received: by 10.55.183.133 with SMTP id h127mr1430002qkf.121.1490901277726; Thu, 30 Mar 2017 12:14:37 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Thu, 30 Mar 2017 19:14:26 +0000 Message-ID: To: Cullen Jennings , Christer Holmberg Cc: mmusic Content-Type: multipart/alternative; boundary=94eb2c0600560e4ed3054bf781aa Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 30 Mar 2017 19:14:42 -0000 --94eb2c0600560e4ed3054bf781aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We have a mailing list discussion (here), a bug ( https://github.com/w3c/webrtc-pc/issues/849) and a PR ( https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about this. I've copied the following comments to the latter two, so I'm adding them here as well. TL;DR: I don't think unverified media is compatible with ICE+DTLS. Here is why (you can go see the bug, too): 1. You can *receive* DTLS from the remote side before receiving the remote description (and thus fingerprint). This happens if the remote side send= s an ICE connectivity check and the local side sends a response and then t= he remote side sends a DTLS packet. 2. You cannot *send* DTLS from the local side before receiving the remote description (and thus fingerprint). This is because you can't send an IC= E connectivity check until you have the remote ICE ufrag and pwd, and thus can't get an ICE connectivity check response, and thus can't send DTLS. This is because you can't send anything other than ICE until you get an = ICE connectivity check response. 3. Since you can't send DTLS, you can't complete the handshake, and thus can't extract the SRTP key. Maybe I'm missing something, but I think this is impossible. On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: > > On Mar 13, 2017, at 3:44 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > My question is: is this something that=E2=80=99s causing problems in real > deployments, and requires a change in the standard? > > > 1-800 go fedex. See webrtc requirements documents from many years ago. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c0600560e4ed3054bf781aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We have a mailing list discussion (here), a bug (https://github.com/w3c/web= rtc-pc/issues/849) and a PR (https://github.com/w3c/webrtc-pc/pull/1= 026#issuecomment-279238215) about this.=C2=A0 I've copied the follo= wing comments to the latter two, so I'm adding them here as well.
<= br>
TL;DR: I don't think unverified media is compatible with = ICE+DTLS.=C2=A0 Here is why (you can go see the bug, too):

    =

  1. You can=C2=A0receive=C2=A0DTLS from the remote side before receiving the remote description (and th= us fingerprint). This happens if the remote side sends an ICE connectivity = check and the local side sends a response and then the remote side sends a = DTLS packet.

  2. You cannot=C2= =A0send=C2=A0DTLS from the local side before = receiving the remote description (and thus fingerprint). This is because yo= u can't send an ICE connectivity check until you have the remote ICE uf= rag and pwd, and thus can't get an ICE connectivity check response, and= thus can't send DTLS. This is because you can't send anything othe= r than ICE until you get an ICE connectivity check response.

  3. Since you can'= ;t send DTLS, you can't complete the handshake, and thus can't extr= act the SRTP key.


Maybe I'm missing something, but I think this is imp= ossible.

On Sat,= Mar 25, 2017 at 1:12 PM Cullen Jennings <fluffy@iii.ca> wrote:

On Mar 13, 2017, at 3:44 PM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" class=3D"gmail_msg" target= =3D"_blank">christer.holmberg@ericsson.com> wrote:

My question is: is this something that=E2=80=99s caus= ing problems in real deployments, and requires a change in the standard?=C2=A0

1-= 800 go fedex. See webrtc requirements documents from many years ago.=C2=A0<= /div>
_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic
--94eb2c0600560e4ed3054bf781aa-- From nobody Thu Mar 30 13:33:48 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 81AAB1293D9 for ; Thu, 30 Mar 2017 13:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Te1nm4W-hCXP for ; Thu, 30 Mar 2017 13:33:45 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 1D3CF1270A7 for ; Thu, 30 Mar 2017 13:33:44 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id r45so49830811qte.3 for ; Thu, 30 Mar 2017 13:33:44 -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=/wOlV8JmJfnd7V/hzt1zapN7t0kPHcWzYOS5+cCMOiI=; b=L4X+iJrODzECwc1aO9IhH2JIA6iDhyS0COo64FgnqD60rjcVGNDaEfQl7Ye/Rmk9OS cWKtl1444OjEknbjut6NNGSGjKALTq1jFOoeppldL3zbh0O3zAAPC6xHPW8MB0PeqIQQ FHqEO+tISyE7v5D3u/JzQVwQ/f6aHQZOgPlsY4bAWG6H1u40TGSkUYIUeu0JxwIwcIF+ s7ZURD32768eRLLP2jdEwOOT/oSPJ8oprc5k+L1fgRNfN3/nYDcMX043pFdzMnhwYiV4 2uDo4OxfZ/OiPmli3nwuSAG1aIuteztEiY1m/y3m0rwNxdxsKHBKr8qlnQf0DhUTr6sJ vatw== 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=/wOlV8JmJfnd7V/hzt1zapN7t0kPHcWzYOS5+cCMOiI=; b=I1dIetEqYsyWxsJUqIVetIB69BTVk8EBpdoHtOZJv/4BxSVYRKHH73BeXP0BDPMDQb nij3Cjmk3SnaKVi6+Knu2Jr+NO2UzuIwdIt5yhPaEZ5mkO2HQF2s1VZIMd3d+jst1z1o 1LnaCh/pwrj1GUhPtrFYeElNgQH5xPpx9PwYT+FHH5hXIqSUIV6wonx44esPh9AyRw+Z zzsvhv4F4EFA+HD8iB8MHXOi3lJIcUvU4LUwrDOUXr04Gby7Y5Kz6uPri0LH4suR5nNA nSEDi1g6dFkYh4ipgj/RIomaDLua7cMmcjGrvor5IV6f325VgeXwENcCeKx2wnJkOxhD Nzdw== X-Gm-Message-State: AFeK/H1sn1VP34TXXkTCJa/IG0WBH/PirO8xqgvXY6If//G+nXYY9nOXs+uvfvOeAJFmMsG7lxsmP2ZiIRftTQ== X-Received: by 10.237.60.3 with SMTP id t3mr1999163qte.86.1490906023110; Thu, 30 Mar 2017 13:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.46.165 with HTTP; Thu, 30 Mar 2017 13:33:42 -0700 (PDT) From: Suhas Nandakumar Date: Thu, 30 Mar 2017 15:33:42 -0500 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=94eb2c0e61dae6acfa054bf89bcd Archived-At: Subject: [MMUSIC] PR for extmap handling in 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: Thu, 30 Mar 2017 20:33:46 -0000 --94eb2c0e61dae6acfa054bf89bcd Content-Type: text/plain; charset=UTF-8 here it is: https://github.com/cdh4u/draft-sdp-bundle/pull/32 cheers Suhas --94eb2c0e61dae6acfa054bf89bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
cheers
Suhas
--94eb2c0e61dae6acfa054bf89bcd-- From nobody Thu Mar 30 13:50: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 542DC129569 for ; Thu, 30 Mar 2017 13:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 eNllJPn836l4 for ; Thu, 30 Mar 2017 13:50:46 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A97129544 for ; Thu, 30 Mar 2017 13:50:43 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id r45so50195143qte.3 for ; Thu, 30 Mar 2017 13:50:43 -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=2qrrFXjw5W/3pJMfSIhgZAbO0znszDwx44t0mxBvH6E=; b=YCcyV9iBdt7l2U/Mtg+08hw2J1GFg4PHsUm+GuAU0NdOGX1oBy5ydfIYfpRdXmdP6o 155bQInHFjLuRjLuVQcP381Q3jppo3pYVz2ZKjoj5zZOmbq/5YwNlYYBofVV6eav7bLk p5HulgQAO5utvKOTg1lHiJYMChF5PdrA2RNWXYIwMGzld8em8+2WY2XRkmv1gy6CzCyJ GUkPwcV8AuxdM9dD1HWPuNLxbDY8D1qz8NESwdiM4zuxssCrlmKBPnDRrv2ylCcZGLWC h+ALNuuTXd6vhGQKlkjYh4jUQQ+cli6Kc+xQDbT3KS4xcrIl1XPrhAunzKQ7lDpEhzc2 J1hg== 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=2qrrFXjw5W/3pJMfSIhgZAbO0znszDwx44t0mxBvH6E=; b=tFzLA+O4uJrSklFy0CZCT4U9AfPbL1A16uxs7MgFTOp6OaPxG9/VwRxm4ld/wQguAz zl7AjMLwxQpTIzCkGUP1Pr45Pucbl9UdWNzQEpQSJPCaMJfvNsqXqADTIdvrWTqsmYhq UBW9uINZwPkHG66RakixIsM46qTczPGgvqkOYo/m0xgdJO78HW5fUAEippNP0Oq+Va+5 FKVy8KX5E1g3Kgty0Bnjpx1IRjz1mOde6trIAj9KfyMCeWoZa57WfT3VOrZep+j9b379 Xwlm6VJ3dxeIr51d27u6lHRTpDERzJCskjQTmKbxFM2+Cse3pP9IBwHcG0PRvjgnk6bN lA4g== X-Gm-Message-State: AFeK/H0zyI2iRc5n8xLQON3DXUuRVVXer5T36Y8YwMtPwSD0RS50qwdqwC26nss9TKKBpIAb4oZPWx35mDEOQQ== X-Received: by 10.200.46.91 with SMTP id s27mr1987572qta.278.1490907042496; Thu, 30 Mar 2017 13:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Thu, 30 Mar 2017 13:50:42 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> From: Martin Thomson Date: Thu, 30 Mar 2017 15:50:42 -0500 Message-ID: To: Peter Thatcher Cc: Cullen Jennings , Christer Holmberg , mmusic Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 30 Mar 2017 20:50:49 -0000 Tim had a comment that didn't make it due to time, but I thought that it was worth forwarding here: What I was getting up to say was, I think it's "acceptable" to provide the data to the application if and only if the application has a way to know that it's (potentially) invalid (and when it becomes valid). What would _not_ be acceptable would be to provide the data to the application in a way that's indistinguishable from receving valid data. In terms of what policy the *browser* application takes towards this data, it would seem unwise to pass anything concrete to the origin. Media might be isolated, but that leads to it being essentially equivalent to mixed content. the W3C might be ... let me just say reluctant ... to add new ways of adding mixed content to the web. On 30 March 2017 at 14:14, Peter Thatcher wrote: > We have a mailing list discussion (here), a bug > (https://github.com/w3c/webrtc-pc/issues/849) and a PR > (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about > this. I've copied the following comments to the latter two, so I'm addin= g > them here as well. > > TL;DR: I don't think unverified media is compatible with ICE+DTLS. Here = is > why (you can go see the bug, too): > > You can receive DTLS from the remote side before receiving the remote > description (and thus fingerprint). This happens if the remote side sends= an > ICE connectivity check and the local side sends a response and then the > remote side sends a DTLS packet. > > You cannot send DTLS from the local side before receiving the remote > description (and thus fingerprint). This is because you can't send an ICE > connectivity check until you have the remote ICE ufrag and pwd, and thus > can't get an ICE connectivity check response, and thus can't send DTLS. T= his > is because you can't send anything other than ICE until you get an ICE > connectivity check response. > > Since you can't send DTLS, you can't complete the handshake, and thus can= 't > extract the SRTP key. > > > Maybe I'm missing something, but I think this is impossible. > > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: >> >> >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg >> wrote: >> >> My question is: is this something that=E2=80=99s causing problems in rea= l >> deployments, and requires a change in the standard? >> >> >> 1-800 go fedex. See webrtc requirements documents from many years ago. >> _______________________________________________ >> 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 Mar 30 15:11: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 79C91127863 for ; Thu, 30 Mar 2017 15:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 ylI96zucKTXa for ; Thu, 30 Mar 2017 15:11:20 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 00D7E12426E for ; Thu, 30 Mar 2017 15:11:19 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id l7so28903431ioe.3 for ; Thu, 30 Mar 2017 15:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GPS2apr1Yfj4MGk49KgcMbRPzJSby7xmA2ZjuvMKWmw=; b=CNtycJABYlAskIhwLRihcnHKMWduTbJXstI6+ISyPnhNrAlkft9JpUH2kNrCxoPrCO JFT8zCjrqh1Wwbg8tkYQ+gWGO+ccdu0wEQFSVraWxRsy1/jSTCHL2IgxrsflfGGfwS0i XtIjAz2XXbh9S5baLF3m6twjCl48NZu/Dv+XQm5u6829EmjVPb1+bOyuDc4FDDXeiss5 3hCPDObQUkS6UoRWh0Fovqsu/cX6pHYO60VWfQReMP+lyAu/BMfa4N0XFFGmvv6f0kzy HyGuzoXgJFOQJTWSNAw22gThuq0oUINiq35/6FvTq5VZOsw6D8PqmH0WWRIFpwG8y00n TJ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GPS2apr1Yfj4MGk49KgcMbRPzJSby7xmA2ZjuvMKWmw=; b=Kx9vx463U8BQnizlCMCpSVhlbTyiM3c4SY5xh5RcpURAQ0LvdCnxcFAaMEXJ+a0+pV 0mUI1lHagf2FAqtC+vccBknk85cUQfEqdqIzQe79iAQH6nCkoKvD/IsIC3p9nXShjBax is5BvcBmJzptoIaFddjw0soJnUOIygYtPBoGOibNPdcz0UsgzxNTlgblMK2Qm44WCMaO /58vGMR8T1FYZ84oEkUtbCxsLTanh6MmPMBaAMp95YI7qZ4dwFB1giwrWeCOdgW7/iHl UdNh/Tq9zZ5tfQeU4++aCDg1RVSw2SpbQU3pZr/qKx3iVrezXfial/HoVmcBMomuiFVZ tu3A== X-Gm-Message-State: AFeK/H0QVTHu/vai7A8BTocEhklEk71Bi16edxwMFdNMPqEjGi78thUr4SrfmioMiUjLoQ== X-Received: by 10.107.19.142 with SMTP id 14mr3336327iot.188.1490911879295; Thu, 30 Mar 2017 15:11:19 -0700 (PDT) Received: from [31.133.150.38] (dhcp-9626.meeting.ietf.org. [31.133.150.38]) by smtp.gmail.com with ESMTPSA id p198sm224786itg.31.2017.03.30.15.11.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 15:11:18 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A847AEEA-3DD6-490F-BCF2-F5A0B89A0EC5 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (14D27) In-Reply-To: Date: Thu, 30 Mar 2017 17:11:17 -0500 Cc: Cullen Jennings , Christer Holmberg , mmusic Content-Transfer-Encoding: 7bit Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> To: Peter Thatcher Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 30 Mar 2017 22:11:22 -0000 --Apple-Mail-A847AEEA-3DD6-490F-BCF2-F5A0B89A0EC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The unverified media scenarios seem to depend on ICE connectivity being bi-d= irectionally enabled so as to permit the DTLS negotiation to proceed in adva= nce of remote fingerprint arrival. If ICE candidates are signaled separately= from the DTLS fingerprint exchange it might be feasible, such as in ORTC si= gnaling where the ICE parameters are exchanged before the DtlsParameters. At the last WebRTC interim a scenario involving PRANSWER and Trickle ICE was= presented. In the scenario, the PRANSWER included a fingerprint, but possib= ly one which did not match the certificate provided in DTLS unlike the final= answer. I do not see how this could work but perhaps I am missing something= . > On Mar 30, 2017, at 14:14, Peter Thatcher wrote: >=20 > We have a mailing list discussion (here), a bug (https://github.com/w3c/we= brtc-pc/issues/849) and a PR (https://github.com/w3c/webrtc-pc/pull/1026#iss= uecomment-279238215) about this. I've copied the following comments to the l= atter two, so I'm adding them here as well. >=20 > TL;DR: I don't think unverified media is compatible with ICE+DTLS. Here i= s why (you can go see the bug, too): >=20 > You can receive DTLS from the remote side before receiving the remote desc= ription (and thus fingerprint). This happens if the remote side sends an ICE= connectivity check and the local side sends a response and then the remote s= ide sends a DTLS packet. >=20 > You cannot send DTLS from the local side before receiving the remote descr= iption (and thus fingerprint). This is because you can't send an ICE connect= ivity check until you have the remote ICE ufrag and pwd, and thus can't get a= n ICE connectivity check response, and thus can't send DTLS. This is because= you can't send anything other than ICE until you get an ICE connectivity ch= eck response. >=20 > Since you can't send DTLS, you can't complete the handshake, and thus can'= t extract the SRTP key. >=20 >=20 > Maybe I'm missing something, but I think this is impossible. >=20 >> On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: >>=20 >>> On Mar 13, 2017, at 3:44 PM, Christer Holmberg wrote: >>>=20 >>> My question is: is this something that=E2=80=99s causing problems in rea= l deployments, and requires a change in the standard?=20 >>=20 >> 1-800 go fedex. See webrtc requirements documents from many years ago.=20= >> _______________________________________________ >> 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 --Apple-Mail-A847AEEA-3DD6-490F-BCF2-F5A0B89A0EC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The unverified media scenar= ios seem to depend on ICE connectivity being bi-directionally enabled so as t= o permit the DTLS negotiation to proceed in advance of remote fingerprint ar= rival. If ICE candidates are signaled separately from the DTLS fingerprint e= xchange it might be feasible, such as in ORTC signaling where the ICE parame= ters are exchanged before the DtlsParameters.

At th= e last WebRTC interim a scenario involving PRANSWER and Trickle ICE was pres= ented. In the scenario, the PRANSWER included a fingerprint, but possibly on= e which did not match the certificate provided in DTLS unlike the final answ= er. I do not see how this could work but perhaps I am missing something.

On Mar 30, 2017, at 14:14, Peter Thatcher <pthatcher@google.com> wrote:

We have a mailing list discussion (= here), a bug (https:= //github.com/w3c/webrtc-pc/issues/849) and a PR (https://github.com/w3= c/webrtc-pc/pull/1026#issuecomment-279238215) about this.  I've cop= ied the following comments to the latter two, so I'm adding them here as wel= l.

TL;DR: I don't think unverified media is compatible wi= th ICE+DTLS.  Here is why (you can go see the bug, too):

=

    You can rec= eive DTLS= from the remote side before receiving the remote description (and thus fing= erprint). This happens if the remote side sends an ICE connectivity check an= d the local side sends a response and then the remote side sends a DTLS pack= et.

  1. Y= ou cannot send DTLS from the local side before receiving the rem= ote description (and thus fingerprint). This is because you can't send an IC= E connectivity check until you have the remote ICE ufrag and pwd, and thus c= an't get an ICE connectivity check response, and thus can't send DTLS. This i= s because you can't send anything other than ICE until you get an ICE connec= tivity check response.

  2. Since you can't send DTLS, you can't complete the handshak= e, and thus can't extract the SRTP key.


Maybe I'm missing something, but I t= hink this is impossible.

On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <fluffy@iii.ca> wrote:

On Mar 13, 2017, at 3:44 PM, Christer Holmber= g <christer.holmberg@ericsson.com> wrote:

My question is: is this something that=E2=80=99s causing p= roblems in real deployments, and requires a change in the standard? 

1-800 go fe= dex. See webrtc requirements documents from many years ago. 
_______________________________________________
mmusic mailing list
mmu= sic@ietf.org
https://www.ietf.org/mailman/listinfo/m= music
____________________= ___________________________
mmusic mailing list
mmusic@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mmusic">https://www.ietf.org= /mailman/listinfo/mmusic
= --Apple-Mail-A847AEEA-3DD6-490F-BCF2-F5A0B89A0EC5-- From nobody Thu Mar 30 15:50: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 4348B1296CD for ; Thu, 30 Mar 2017 15:50:48 -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, 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=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 hj8rpqSsuvzL for ; Thu, 30 Mar 2017 15:50:46 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF83912945D for ; Thu, 30 Mar 2017 15:50:38 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id r142so53592552qke.2 for ; Thu, 30 Mar 2017 15:50:38 -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=MDUz8K9wiBAA9Q9NaY0LPbjNamnAPuLtiPM+0XvQ+78=; b=ogufXd7k22a7BTaC7GlbUEQt1qmnqs8t/+Bad5UQnDecMUSlfsq3AYwaxOsfyKOyve wB+HqBtIq8JNn34RZofotWQfi+lZ4GfUirLKCztD0zhS62dCvLAorEm+ZGI+W+LuRqyR U8TG/pmcHEeMH5uLd7/lCYzGxjWaZncjMq5FmsIi5PtDY15MowNrryDV/5GxKPWkP9UJ IEXfy4pSv0pp5Ti/sK2NFL0v67nlZqRR1aSClgXmVUrOiT0p8a8fUV7vn3f2up0O/gEm oPrNNGs93L6z+LUWeyAsfoty9jl6Kbb7JNgRevTvzOlTIczrF7VgtwU0Fd/ryHSRGR5/ 8tyQ== 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=MDUz8K9wiBAA9Q9NaY0LPbjNamnAPuLtiPM+0XvQ+78=; b=IbZa/tnHtu6eaMq8a0xMGUZDgIrOCXOPr2HBYaDpL8a/ypnOZmtLo4Hw4Hme9lRPy8 7ZE4taR0bfWFqe+4cNGajUq/xxQoH0QM7g/5KLxlcAB3ujiCPX4FROaBQXuHLAHYOMSj jrntRu3yQkM42cHvaMBtHFYxW6B6WI4+HAVfbyFM4E1O1R6fJzdiv+WFquf0fV1bl2pz 6sY8HBVH8KO78ppEDi/SQvtYKcHEYjTLHBjykrzSdPGo/LeA5OlqnrcdnPFHZS6xhJ8g z/SLl4ut53OkcEQ56enqSvX2r2Xh3NGA/FunsKiNeI72a9NCNeNolPOqzMrU9IkJPLBY xSlw== X-Gm-Message-State: AFeK/H1AEv3ztbW7EaDK3qPUwvmL7tTHtcveTux+bMSXWCjYcb85OVdwC94Os+VlpxPM88FiZv+iFxgp/6Dngw== X-Received: by 10.55.126.195 with SMTP id z186mr2352453qkc.144.1490914237900; Thu, 30 Mar 2017 15:50:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Thu, 30 Mar 2017 15:50:37 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> From: Martin Thomson Date: Thu, 30 Mar 2017 17:50:37 -0500 Message-ID: To: Bernard Aboba Cc: Peter Thatcher , mmusic , Cullen Jennings , Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 30 Mar 2017 22:50:48 -0000 These both sound like legitimate cases where ICE can precede signaling. I would recommend that the W3C think carefully about whether they might like to accept (potentially) invalid data before we spend a whole lot more time on the issue. On 30 March 2017 at 17:11, Bernard Aboba wrote: > The unverified media scenarios seem to depend on ICE connectivity being > bi-directionally enabled so as to permit the DTLS negotiation to proceed = in > advance of remote fingerprint arrival. If ICE candidates are signaled > separately from the DTLS fingerprint exchange it might be feasible, such = as > in ORTC signaling where the ICE parameters are exchanged before the > DtlsParameters. > > At the last WebRTC interim a scenario involving PRANSWER and Trickle ICE = was > presented. In the scenario, the PRANSWER included a fingerprint, but > possibly one which did not match the certificate provided in DTLS unlike = the > final answer. I do not see how this could work but perhaps I am missing > something. > > On Mar 30, 2017, at 14:14, Peter Thatcher wrote: > > We have a mailing list discussion (here), a bug > (https://github.com/w3c/webrtc-pc/issues/849) and a PR > (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about > this. I've copied the following comments to the latter two, so I'm addin= g > them here as well. > > TL;DR: I don't think unverified media is compatible with ICE+DTLS. Here = is > why (you can go see the bug, too): > > You can receive DTLS from the remote side before receiving the remote > description (and thus fingerprint). This happens if the remote side sends= an > ICE connectivity check and the local side sends a response and then the > remote side sends a DTLS packet. > > You cannot send DTLS from the local side before receiving the remote > description (and thus fingerprint). This is because you can't send an ICE > connectivity check until you have the remote ICE ufrag and pwd, and thus > can't get an ICE connectivity check response, and thus can't send DTLS. T= his > is because you can't send anything other than ICE until you get an ICE > connectivity check response. > > Since you can't send DTLS, you can't complete the handshake, and thus can= 't > extract the SRTP key. > > > Maybe I'm missing something, but I think this is impossible. > > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: >> >> >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg >> wrote: >> >> My question is: is this something that=E2=80=99s causing problems in rea= l >> deployments, and requires a change in the standard? >> >> >> 1-800 go fedex. See webrtc requirements documents from many years ago. >> _______________________________________________ >> 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 Mar 30 16:40: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 02ED4126CC7 for ; Thu, 30 Mar 2017 16:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RP_MATCHES_RCVD=-0.001, 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 58iMs48insGd for ; Thu, 30 Mar 2017 16:40:41 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 413C0129510 for ; Thu, 30 Mar 2017 16:40:37 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id d201so24332565qkc.0 for ; Thu, 30 Mar 2017 16:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hyRv8IlHXP43zx2lArZrO3maYxoo0hbAl6pmixDyihA=; b=QYWZSugPhJuP01uVeTQTEdNfYjD26veLFJwqqbqtuYnPjcI3tsM7KlBA1po4ZrMcYA s1XGJ+206yUS0OPl6s4nsk5K3ZIvq2QqspW/4R4o9UyRIWkSVpAxktHaevRh7vVWZ2Bl tROoPOSrJdHEXjar3dswqF4pFQ2AKSCx7Psf21ue3gCBZv2Ut6fGW+X2Q2+sCkJRlP5t axyOwny4G8Rb6jmBroEAhqknHlqFfHptGS0kLhKyTFxE0Thm5+BRUB40XzFu7YNsmBlY wGjo+sKCa429e6PJD9XpjJCzy1cB6/P7J8XjrvsMvtJardv6X4KFEyDfy817WK6alDBU EYOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hyRv8IlHXP43zx2lArZrO3maYxoo0hbAl6pmixDyihA=; b=LHv869q1UAWl+wupqzQJmF3rPE9kN4m6rDXuwPObOcJijtu1A3IbfKxm3DsT/QYyzZ F90x2tuWYrOJQf4IKbc8vv/4twVmneaFauVfJWHSVvcOj3+Gd2suvinBD9LwXiRnh5QI xCCWooqk5pG6EpK279M4T6f5Pxo7e02RiG1LM39yxMYHPxvxtWXR1KhGh0E6SzOUghQY 6sdGkal+kt/q/3a+VOEkY0g4OQgkcfGxmtaJEMyPXqAzfi10zP+CQ1psTZAvW57Kn1s6 lDzgeodeJucxKRnZTS9wtMXZtlunjUZXXEqsZJgOs3yUcq2mBZ+21W2yDfIhiHlFCZFV wkdQ== X-Gm-Message-State: AFeK/H30LfvdurT/F/stNO+YfoFP9cBp/L7+3IJR5N/6hawpf+ufGcl8Xrb6l4JS+4a+NfgztxkjGq6jXZuH318E X-Received: by 10.55.75.146 with SMTP id y140mr56190qka.200.1490917236190; Thu, 30 Mar 2017 16:40:36 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Thu, 30 Mar 2017 23:40:25 +0000 Message-ID: To: Martin Thomson , Bernard Aboba Cc: mmusic , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary=001a1148194441308d054bfb385d Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 30 Mar 2017 23:40:44 -0000 --001a1148194441308d054bfb385d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bernard, you are right that this is possible with ORTC, even though I think it's impossible with WebRTC. But that's clearly out of scope for the MMUSIC WG. Perhaps the right forum to discuss Cullen's 1-800-fedex use case is in the context of ORTC (or WebRTC NV). On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson wrote: > These both sound like legitimate cases where ICE can precede > signaling. I would recommend that the W3C think carefully about > whether they might like to accept (potentially) invalid data before we > spend a whole lot more time on the issue. > > On 30 March 2017 at 17:11, Bernard Aboba wrote: > > The unverified media scenarios seem to depend on ICE connectivity being > > bi-directionally enabled so as to permit the DTLS negotiation to procee= d > in > > advance of remote fingerprint arrival. If ICE candidates are signaled > > separately from the DTLS fingerprint exchange it might be feasible, suc= h > as > > in ORTC signaling where the ICE parameters are exchanged before the > > DtlsParameters. > > > > At the last WebRTC interim a scenario involving PRANSWER and Trickle IC= E > was > > presented. In the scenario, the PRANSWER included a fingerprint, but > > possibly one which did not match the certificate provided in DTLS unlik= e > the > > final answer. I do not see how this could work but perhaps I am missing > > something. > > > > On Mar 30, 2017, at 14:14, Peter Thatcher wrote: > > > > We have a mailing list discussion (here), a bug > > (https://github.com/w3c/webrtc-pc/issues/849) and a PR > > (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) > about > > this. I've copied the following comments to the latter two, so I'm > adding > > them here as well. > > > > TL;DR: I don't think unverified media is compatible with ICE+DTLS. Her= e > is > > why (you can go see the bug, too): > > > > You can receive DTLS from the remote side before receiving the remote > > description (and thus fingerprint). This happens if the remote side > sends an > > ICE connectivity check and the local side sends a response and then the > > remote side sends a DTLS packet. > > > > You cannot send DTLS from the local side before receiving the remote > > description (and thus fingerprint). This is because you can't send an I= CE > > connectivity check until you have the remote ICE ufrag and pwd, and thu= s > > can't get an ICE connectivity check response, and thus can't send DTLS. > This > > is because you can't send anything other than ICE until you get an ICE > > connectivity check response. > > > > Since you can't send DTLS, you can't complete the handshake, and thus > can't > > extract the SRTP key. > > > > > > Maybe I'm missing something, but I think this is impossible. > > > > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: > >> > >> > >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg > >> wrote: > >> > >> My question is: is this something that=E2=80=99s causing problems in r= eal > >> deployments, and requires a change in the standard? > >> > >> > >> 1-800 go fedex. See webrtc requirements documents from many years ago. > >> _______________________________________________ > >> 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 > > > --001a1148194441308d054bfb385d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bernard, you are right that this is possible with ORTC, ev= en though I think it's impossible with WebRTC.=C2=A0 But that's cle= arly out of scope for the MMUSIC WG.=C2=A0 Perhaps the right forum to discu= ss Cullen's 1-800-fedex use case is in the context of ORTC (or WebRTC N= V).

On Thu, Mar 30, 20= 17 at 3:50 PM Martin Thomson <martin.thomson@gmail.com> wrote:
These both sound like legitimate cases where ICE can precede
signaling.=C2=A0 I would recommend that the W3C think carefully about
whether they might like to accept (potentially) invalid data before we
spend a whole lot more time on the issue.

On 30 March 2017 at 17:11, Bernard Aboba <bernard.aboba@gmail.com<= /a>> wrote:
> The unverified media scenarios seem to depend on ICE connectivity bein= g
> bi-directionally enabled so as to permit the DTLS negotiation to proce= ed in
> advance of remote fingerprint arrival. If ICE candidates are signaled<= br class=3D"gmail_msg"> > separately from the DTLS fingerprint exchange it might be feasible, su= ch as
> in ORTC signaling where the ICE parameters are exchanged before the > DtlsParameters.
>
> At the last WebRTC interim a scenario involving PRANSWER and Trickle I= CE was
> presented. In the scenario, the PRANSWER included a fingerprint, but > possibly one which did not match the certificate provided in DTLS unli= ke the
> final answer. I do not see how this could work but perhaps I am missin= g
> something.
>
> On Mar 30, 2017, at 14:14, Peter Thatcher <pthatcher@google.com<= /a>> wrote:
>
> We have a mailing list discussion (here), a bug
> (https://github.com/w3c/webrtc-p= c/issues/849) and a PR
> (https://g= ithub.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about
> this.=C2=A0 I've copied the following comments to the latter two, = so I'm adding
> them here as well.
>
> TL;DR: I don't think unverified media is compatible with ICE+DTLS.= =C2=A0 Here is
> why (you can go see the bug, too):
>
> You can receive DTLS from the remote side before receiving the remote<= br class=3D"gmail_msg"> > description (and thus fingerprint). This happens if the remote side se= nds an
> ICE connectivity check and the local side sends a response and then th= e
> remote side sends a DTLS packet.
>
> You cannot send DTLS from the local side before receiving the remote > description (and thus fingerprint). This is because you can't send= an ICE
> connectivity check until you have the remote ICE ufrag and pwd, and th= us
> can't get an ICE connectivity check response, and thus can't s= end DTLS. This
> is because you can't send anything other than ICE until you get an= ICE
> connectivity check response.
>
> Since you can't send DTLS, you can't complete the handshake, a= nd thus can't
> extract the SRTP key.
>
>
> Maybe I'm missing something, but I think this is impossible.
>
> On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <fluffy@iii.ca> = wrote:
>>
>>
>> On Mar 13, 2017, at 3:44 PM, Christer Holmberg
>> <christer.holmberg@ericsson.com> wrote:
>>
>> My question is: is this something that=E2=80=99s causing problems = in real
>> deployments, and requires a change in the standard?
>>
>>
>> 1-800 go fedex. See webrtc requirements documents from many years = ago.
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailma= n/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/li= stinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/li= stinfo/mmusic
>
--001a1148194441308d054bfb385d-- From nobody Thu Mar 30 18:11:13 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 7FFC2129541 for ; Thu, 30 Mar 2017 18:11:11 -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 i1zZ5qhx_iCG for ; Thu, 30 Mar 2017 18:11:10 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 E27841294D7 for ; Thu, 30 Mar 2017 18:11:09 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id x125so54914185pgb.0 for ; Thu, 30 Mar 2017 18:11:09 -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=iZli35Z70FTQrMfcGpyOst9VCf4rY5xmENKDVME5A0U=; b=QiCR7l9EBbqeNnkdSijxcGmxj+mYs2GhMZpy7Wh7qcKQPh63vrkflpkeUru4FctMWq +A0TQ2Tac1TPvfRf8/68pE3ObffJMwrWJ8xFw4JXn405vNMP+IfgqdfQYNNNNor1fDaD /BcankRya8xghGEubN7iP1t31hyG0Pkb6usnERi33sCisYNGn8vX70/wYcCvJLXCWlBO 1dQEaLQrnHAC07zb2BCDDt3nnExgGFnpdW8ThJDiUgfzo+qWF5oLXhaD+mBWGH5ZZHSs sV1DJunBNHWXd/UyzltwjOZE7wjBTtrT72+1/UHkuSwhMwKpyor4NFwAkz1DEZX7AS0d lB1w== 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=iZli35Z70FTQrMfcGpyOst9VCf4rY5xmENKDVME5A0U=; b=J7SXyJGS8wuwXWB42g+kbh9AjRMoMOtPi3bGQV1MdQEnecICcy8gqlC95zf3ItSQ4H 07pkcj1lG138doJVRZ8o6q5ysRiLfWepJ1eM/uM7CogHiWdKhRVhVme61yDNctvQTdgI OgGdkgy7PiBYWW6qHIx0rh7yyHlTUsou2pFJ1iTUszvgVjkZI4PXZm34lxsgCkRvHDtE fxooib+ncD+Jp4TRex/Z8++0i80VDAfEfkEyouGUQ18QhSja6yMzxvndBAkYPOIQikqZ pcbc2b9iCqlspu+4+MJuifySnDbO65M+Q1ZCcDuSH3mIUKxjfWQWRpoqw/Vcnj5M9XCn k4OQ== X-Gm-Message-State: AFeK/H3Cuxylh5oO5+wsv5lpzveiy+vQABuFJuE5mxnnzEXXfLBK3NWStMs59baM6HFnzg== X-Received: by 10.98.80.93 with SMTP id e90mr257277pfb.7.1490922669241; Thu, 30 Mar 2017 18:11:09 -0700 (PDT) Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com. [74.125.83.48]) by smtp.gmail.com with ESMTPSA id v186sm6589607pgv.44.2017.03.30.18.11.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Mar 2017 18:11:08 -0700 (PDT) Received: by mail-pg0-f48.google.com with SMTP id 81so54941063pgh.2 for ; Thu, 30 Mar 2017 18:11:08 -0700 (PDT) X-Received: by 10.84.217.68 with SMTP id e4mr287727plj.99.1490922668014; Thu, 30 Mar 2017 18:11:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Thu, 30 Mar 2017 18:11:07 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> From: Roman Shpount Date: Thu, 30 Mar 2017 21:11:07 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Peter Thatcher Cc: Martin Thomson , Bernard Aboba , mmusic , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c19f53803c657054bfc7cb9 Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 31 Mar 2017 01:11:11 -0000 --94eb2c19f53803c657054bfc7cb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter, What about ICE lite? If ICE lite sends an offer to WebRTC end point, it can get DTLS ClientHello before it got the answer response from the WebRTC end point. Since ICE lite client does not send ICE requests before sending data, it will respond with ServerHello and establish the connection. At this point data can be sent to it before the answer arrives and fingerprint can be verified. I think the right answer to this situation is not to send ServerHello until answer and fingerprint is received. ClientHello should be buffered and only handled when answer is received. Regards, _____________ Roman Shpount On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatcher wrote: > Bernard, you are right that this is possible with ORTC, even though I > think it's impossible with WebRTC. But that's clearly out of scope for t= he > MMUSIC WG. Perhaps the right forum to discuss Cullen's 1-800-fedex use > case is in the context of ORTC (or WebRTC NV). > > On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson > wrote: > >> These both sound like legitimate cases where ICE can precede >> signaling. I would recommend that the W3C think carefully about >> whether they might like to accept (potentially) invalid data before we >> spend a whole lot more time on the issue. >> >> On 30 March 2017 at 17:11, Bernard Aboba wrote= : >> > The unverified media scenarios seem to depend on ICE connectivity bein= g >> > bi-directionally enabled so as to permit the DTLS negotiation to >> proceed in >> > advance of remote fingerprint arrival. If ICE candidates are signaled >> > separately from the DTLS fingerprint exchange it might be feasible, >> such as >> > in ORTC signaling where the ICE parameters are exchanged before the >> > DtlsParameters. >> > >> > At the last WebRTC interim a scenario involving PRANSWER and Trickle >> ICE was >> > presented. In the scenario, the PRANSWER included a fingerprint, but >> > possibly one which did not match the certificate provided in DTLS >> unlike the >> > final answer. I do not see how this could work but perhaps I am missin= g >> > something. >> > >> > On Mar 30, 2017, at 14:14, Peter Thatcher wrote= : >> > >> > We have a mailing list discussion (here), a bug >> > (https://github.com/w3c/webrtc-pc/issues/849) and a PR >> > (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) >> about >> > this. I've copied the following comments to the latter two, so I'm >> adding >> > them here as well. >> > >> > TL;DR: I don't think unverified media is compatible with ICE+DTLS. >> Here is >> > why (you can go see the bug, too): >> > >> > You can receive DTLS from the remote side before receiving the remote >> > description (and thus fingerprint). This happens if the remote side >> sends an >> > ICE connectivity check and the local side sends a response and then th= e >> > remote side sends a DTLS packet. >> > >> > You cannot send DTLS from the local side before receiving the remote >> > description (and thus fingerprint). This is because you can't send an >> ICE >> > connectivity check until you have the remote ICE ufrag and pwd, and th= us >> > can't get an ICE connectivity check response, and thus can't send DTLS= . >> This >> > is because you can't send anything other than ICE until you get an ICE >> > connectivity check response. >> > >> > Since you can't send DTLS, you can't complete the handshake, and thus >> can't >> > extract the SRTP key. >> > >> > >> > Maybe I'm missing something, but I think this is impossible. >> > >> > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: >> >> >> >> >> >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg >> >> wrote: >> >> >> >> My question is: is this something that=E2=80=99s causing problems in = real >> >> deployments, and requires a change in the standard? >> >> >> >> >> >> 1-800 go fedex. See webrtc requirements documents from many years ago= . >> >> _______________________________________________ >> >> 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 >> > >> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c19f53803c657054bfc7cb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter,

What about ICE lite? If ICE lite= sends an offer to WebRTC end point, it can get DTLS ClientHello before it = got the answer response from the WebRTC end point. Since ICE lite client do= es not send ICE requests before sending data, it will respond with ServerHe= llo and establish the connection. At this point data can be sent to it befo= re the answer arrives and fingerprint can be verified.

=
I think the right answer to this situation is not to send ServerHello = until answer and fingerprint is received. ClientHello should be buffered an= d only handled when answer is received.

Regards,

_____________
Roman S= hpount

On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatc= her <pthatcher@google.com> wrote:
Bernard, you are right that this is possible wi= th ORTC, even though I think it's impossible with WebRTC.=C2=A0 But tha= t's clearly out of scope for the MMUSIC WG.=C2=A0 Perhaps the right for= um to discuss Cullen's 1-800-fedex use case is in the context of ORTC (= or WebRTC NV).

On Thu, Mar 30, 2017 at 3:50 PM Martin Th= omson <mar= tin.thomson@gmail.com> wrote:
signaling.=C2=A0 I would recommend that the W3C think carefully about
whether they might like to accept (potentially) invalid data before we
spend a whole lot more time on the issue.

On 30 March 2017 at 17:11, Bernard Aboba <ber= nard.aboba@gmail.com> wrote:
> The unverified media scenarios seem to depend on ICE connectivity bein= g
> bi-directionally enabled so as to permit the DTLS negotiation to proce= ed in
> advance of remote fingerprint arrival. If ICE candidates are signaled<= br class=3D"m_5127523717455880218gmail_msg"> > separately from the DTLS fingerprint exchange it might be feasible, su= ch as
> in ORTC signaling where the ICE parameters are exchanged before the > DtlsParameters.
>
> At the last WebRTC interim a scenario involving PRANSWER and Trickle I= CE was
> presented. In the scenario, the PRANSWER included a fingerprint, but > possibly one which did not match the certificate provided in DTLS unli= ke the
> final answer. I do not see how this could work but perhaps I am missin= g
> something.
>
> On Mar 30, 2017, at 14:14, Peter Thatcher <= pthatcher@google.com> wrote:
>
> We have a mailing list discussion (here), a bug
> (https://gi= thub.com/w3c/webrtc-pc/issues/849) and a PR
> (https://github.com/w3c/webrtc-pc/pull/1026#issuecomme= nt-279238215) about
> this.=C2=A0 I've copied the following comments to the latter two, = so I'm adding
> them here as well.
>
> TL;DR: I don't think unverified media is compatible with ICE+DTLS.= =C2=A0 Here is
> why (you can go see the bug, too):
>
> You can receive DTLS from the remote side before receiving the remote<= br class=3D"m_5127523717455880218gmail_msg"> > description (and thus fingerprint). This happens if the remote side se= nds an
> ICE connectivity check and the local side sends a response and then th= e
> remote side sends a DTLS packet.
>
> You cannot send DTLS from the local side before receiving the remote > description (and thus fingerprint). This is because you can't send= an ICE
> connectivity check until you have the remote ICE ufrag and pwd, and th= us
> can't get an ICE connectivity check response, and thus can't s= end DTLS. This
> is because you can't send anything other than ICE until you get an= ICE
> connectivity check response.
>
> Since you can't send DTLS, you can't complete the handshake, a= nd thus can't
> extract the SRTP key.
>
>
> Maybe I'm missing something, but I think this is impossible.
>
> On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <f= luffy@iii.ca> wrote:
>>
>>
>> On Mar 13, 2017, at 3:44 PM, Christer Holmberg
>> <christer.holmberg@ericsson.<= wbr>com> wrote:
>>
>> My question is: is this something that=E2=80=99s causing problems = in real
>> deployments, and requires a change in the standard?
>>
>>
>> 1-800 go fedex. See webrtc requirements documents from many years = ago.
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https:= //www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/mmusic
>

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

--94eb2c19f53803c657054bfc7cb9-- From nobody Fri Mar 31 07:36:25 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 D67061297ED; Fri, 31 Mar 2017 07:36: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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149097098383.4316.14003098521283049209@ietfa.amsl.com> Date: Fri, 31 Mar 2017 07:36:23 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-37.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, 31 Mar 2017 14:36:24 -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 of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-37.txt Pages : 63 Date : 2017-03-31 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejected. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-37 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-37 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-37 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 Mar 31 07:42: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 225CE1298B7 for ; Fri, 31 Mar 2017 07:42:17 -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 sn2ZYCQi2gGu for ; Fri, 31 Mar 2017 07:42:15 -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 5B502129508 for ; Fri, 31 Mar 2017 07:42:15 -0700 (PDT) X-AuditID: c1b4fb30-ea83298000006667-34-58de6ac5349f Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 3D.4D.26215.5CA6ED85; Fri, 31 Mar 2017 16:42:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Fri, 31 Mar 2017 16:42:11 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-37 Thread-Index: AdKqLD+PaElcoEcNRse+yN4lZGQ/EA== Date: Fri, 31 Mar 2017 14:42:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB3A68B@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_7594FB04B1934943A5C02806D1A2204B4CB3A68BESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7uu7RrHsRBlMeG1pMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGZO3LWItuGBfMWdOF1sD4wGLLkZODgkBE4kpG2cydTFycQgJ rGeUWPV/GSOEs4RRovHtVdYuRg4ONgELie5/2iANIgLqEl/39jCD2MICqhJLJjxlgYhrSTxr WMgMYetJnJ7dChZnAaqZ9PUCE4jNK+Ar8eDPTjCbUUBM4vupNWA2s4C4xK0n85kgDhKQWLLn PDOELSrx8vE/VghbSWLF9kuMEPX5EpsaDkDNFJQ4OfMJywRGwVlIRs1CUjYLSRlEXEdiwe5P bBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREY+ge3/DbY wfjyueMhRgEORiUe3gcJ9yKEWBPLiitzDzFKcDArifAyxQGFeFMSK6tSi/Lji0pzUosPMUpz sCiJ8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYGT/a3eqyN+058oV6WfBjxr/KlhyLdnZ+25b cJ20DePXsMut01O2bpp3zGrH4iUsnmWh7pekQmQStET2bK/qMDxwMe5hu7v5fGO58sQzwl7m sYs4jpRFKtodDhPZG3XjkoZH3AfriyWPM96/7vsiaPTU3iF7uyHzzsrSx43icm3qe5Yd1Klq VGIpzkg01GIuKk4EAIVdZAB5AgAA Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-37 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, 31 Mar 2017 14:42:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB3A68BESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-37) of BUNDLE. The following additions/changes are included: - Appendix B moved from JSEP - MID security update - extmap handling text Please base your comments/pull requests on the new version. https://github.com/cdh4u/draft-sdp-bundle Thank You to everyone who provide input and comments! Still missing: - Text regarding usage of media specific attributes - Taylor's editorial comments - Ekr's editorial comments Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB3A68BESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-37) of BUNDLE.<= o:p>

The following additions/changes are included:

 

-     &= nbsp;    Appendix B moved from JSEP

-     &= nbsp;    MID security update

-     &= nbsp;    extmap handling text

 

Please base your comments/pull requests on the new v= ersion.

 

https://github.com/cdh4u/draft-sdp-bundle

 

Thank You to everyone who provide input and comments= !

 

Still missing:

 

-     &= nbsp;    Text regarding usage of media specific attributes

-     &= nbsp;    Taylor’s editorial comments

-     &= nbsp;    Ekr’s editorial comments

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB3A68BESESSMB109erics_-- From nobody Fri Mar 31 08:52: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 E4FE71299BD for ; Fri, 31 Mar 2017 08:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.695 X-Spam-Level: X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 EVnA83mah7sJ for ; Fri, 31 Mar 2017 08:52:43 -0700 (PDT) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.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 D94211294C0 for ; Fri, 31 Mar 2017 08:52:42 -0700 (PDT) Received: from smtp4.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3CDA657E7; Fri, 31 Mar 2017 11:52:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BFF2159A1; Fri, 31 Mar 2017 11:52:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn3-184.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Fri, 31 Mar 2017 11:52:39 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_B8202525-3F1C-4305-BEEA-C08E79738311" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 31 Mar 2017 10:52:37 -0500 Cc: Christer Holmberg , mmusic Message-Id: <04A030AC-0323-42D5-AE7D-33EAB8EC8A30@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> To: Peter Thatcher X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 31 Mar 2017 15:52:51 -0000 --Apple-Mail=_B8202525-3F1C-4305-BEEA-C08E79738311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Imagine a WebRTC browser called A sends an offer to a SBC called S. S = sends PR offer accepting data channel but not others. ICE comes up = between A and S. A TLS channel comes up between A and S. S forwards the = offer to gateway called G over SIP with no ICE. G sends a TLS connection = to A that is relayed via G. So this new connection is in the same ICE = context. The ICE goes between A and S. But the 2nd TLS goes between A = and G but gateway by S.=20 I realize a more complete description would be useful but hopefully that = is enough to think about a bit.=20 > On Mar 30, 2017, at 2:14 PM, Peter Thatcher = wrote: >=20 > We have a mailing list discussion (here), a bug = (https://github.com/w3c/webrtc-pc/issues/849 = ) and a PR = (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215 = ) = about this. I've copied the following comments to the latter two, so = I'm adding them here as well. >=20 > TL;DR: I don't think unverified media is compatible with ICE+DTLS. = Here is why (you can go see the bug, too): >=20 > You can receive DTLS from the remote side before receiving the remote = description (and thus fingerprint). This happens if the remote side = sends an ICE connectivity check and the local side sends a response and = then the remote side sends a DTLS packet. >=20 > You cannot send DTLS from the local side before receiving the remote = description (and thus fingerprint). This is because you can't send an = ICE connectivity check until you have the remote ICE ufrag and pwd, and = thus can't get an ICE connectivity check response, and thus can't send = DTLS. This is because you can't send anything other than ICE until you = get an ICE connectivity check response. >=20 > Since you can't send DTLS, you can't complete the handshake, and thus = can't extract the SRTP key. >=20 >=20 > Maybe I'm missing something, but I think this is impossible. >=20 > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings > wrote: >=20 >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg = > = wrote: >>=20 >> My question is: is this something that=E2=80=99s causing problems in = real deployments, and requires a change in the standard?=20 >=20 > 1-800 go fedex. See webrtc requirements documents from many years ago.=20= > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic = --Apple-Mail=_B8202525-3F1C-4305-BEEA-C08E79738311 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Imagine a WebRTC browser = called A sends an offer to a SBC called S.  S sends PR offer = accepting data channel but not others. ICE comes up between A and S. A = TLS channel comes up between A and S. S forwards the offer to gateway = called G over SIP with no ICE. G sends a TLS connection to A that is = relayed via G. So this new connection is in the same ICE context. The = ICE goes between A and S. But the 2nd TLS goes between A and G but = gateway by S. 

I = realize a more complete description would be useful but hopefully that = is enough to think about a bit. 


On = Mar 30, 2017, at 2:14 PM, Peter Thatcher <pthatcher@google.com> wrote:

We have a mailing list discussion (here), a bug (https://github.com/w3c/webrtc-pc/issues/849) and a PR (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-2792382= 15) about this.  I've copied the following comments to the = latter two, so I'm adding them here as well.

TL;DR: I don't think unverified media = is compatible with ICE+DTLS.  Here is why (you can go see the bug, = too):

  1. You can receive DTLS from the = remote side before receiving the remote description (and thus = fingerprint). This happens if the remote side sends an ICE connectivity = check and the local side sends a response and then the remote side sends = a DTLS packet.

  2. You cannot send DTLS from the = local side before receiving the remote description (and thus = fingerprint). This is because you can't send an ICE connectivity check = until you have the remote ICE ufrag and pwd, and thus can't get an ICE = connectivity check response, and thus can't send DTLS. This is because = you can't send anything other than ICE until you get an ICE connectivity = check response.

  3. Since you can't send DTLS, you can't complete the handshake, = and thus can't extract the SRTP key.


Maybe I'm missing something, but I think this is = impossible.

On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings = <fluffy@iii.ca> = wrote:

On Mar 13, 2017, at 3:44 PM, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

My question is: is this something that=E2=80=99s = causing problems in real deployments, and requires a change in the = standard? 

1-800 go fedex. See webrtc requirements documents = from many years = ago. 
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

= --Apple-Mail=_B8202525-3F1C-4305-BEEA-C08E79738311-- From nobody Fri Mar 31 08:54: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 6F4CE1294FC for ; Fri, 31 Mar 2017 08:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.696 X-Spam-Level: X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, 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 QS-AiwthI7hQ for ; Fri, 31 Mar 2017 08:54:19 -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 BD5FC1294C0 for ; Fri, 31 Mar 2017 08:54:18 -0700 (PDT) Received: from smtp37.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp37.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F39A9653F; Fri, 31 Mar 2017 11:54:15 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 91E026521; Fri, 31 Mar 2017 11:54:15 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from rtp-vpn3-184.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Fri, 31 Mar 2017 11:54:15 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_1CD97F62-8760-49B0-A37C-0E87284F9FBA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 31 Mar 2017 10:54:14 -0500 Cc: Bernard Aboba , Christer Holmberg , mmusic Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 31 Mar 2017 15:54:20 -0000 --Apple-Mail=_1CD97F62-8760-49B0-A37C-0E87284F9FBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 30, 2017, at 5:50 PM, Martin Thomson = wrote: >=20 > I would recommend that the W3C think carefully about > whether they might like to accept (potentially) invalid data before we > spend a whole lot more time on the issue. I realize the topic of playing out the data is very complicated, but the = topic I think should be though about first is buffering the video i = frames so they are not lost.=20 --Apple-Mail=_1CD97F62-8760-49B0-A37C-0E87284F9FBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 30, 2017, at 5:50 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

I would recommend that the W3C think carefully = about
whether they might like to accept (potentially) = invalid data before we
spend a whole lot more time on the = issue.

I = realize the topic of playing out the data is very complicated, but the = topic I think should be though about first is buffering the video i = frames so they are not lost. 


= --Apple-Mail=_1CD97F62-8760-49B0-A37C-0E87284F9FBA-- From nobody Fri Mar 31 08:58: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 2F5BB12952C for ; Fri, 31 Mar 2017 08:58:07 -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 ZXygIJrRoVeM for ; Fri, 31 Mar 2017 08:58:04 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 1EE6D1296CC for ; Fri, 31 Mar 2017 08:58:02 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p22so70320575qka.3 for ; Fri, 31 Mar 2017 08:58:02 -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=pw/6sPXzkIECD8O5vkaXVM8S1oC7wa4SwlDgXBAYMTY=; b=RMMfNhnq0swqmTy2ez6h+x6uZ7yo0nkQRJIxMiwHTgEyGgvsnpOUpv2d1llaeZ8nhG OxRASKEEpUaeOOEEyeWh0yECd6Si7joOdG7htA4z9zmJDWXimD8w83GRTjOgkiriHmeG UlB2Bgmisdi5+PFNSIbZSCxwdlqiEn89xRtDAuIBvCtflvtlMl4VWRK23Vbcpp682CjR xjbsirF1RZyE5xP5RGWK2nIlhxlxo7mIkXLUUNXB5mOB2yW33gDbhhBklfQ4bXrVddhL UVIXRuecQTlFmVXYlkt9iuc5ZnufEiQFDDsIXmA2JM19jzoMrxV/hqKK5mpinuVFNnxt DW7A== 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=pw/6sPXzkIECD8O5vkaXVM8S1oC7wa4SwlDgXBAYMTY=; b=EhzOAx5CKjGqOaxPQjsjKE7VH1jZYN3FmA+G05H6tothbotYZBgAfWlIAAbWPDPluv NciKsgC3HlxidLNqlutjKyw3yiSJsVBARt5FWBgJRwhsdAUtnZRlxgJ6UIiZDuaLXZT1 uwkxovaMicicbYtwCm0h70K/szZeeOHMnJACvJutwF7ttIJdntSmVinzbyyr2TJ3/iMt 3RhJfRWw3kWRjzVX2Ai1AGqNloeYeo+rSkQKEpCPq/sMGsyK22n+sKgxVMYWok4Ywqkh fibBY/+zPORi/RVHGxue3U4vWE2fzcv/LtSbuMmfMqNOg59tj9SbKovM3pQLz8TmLU6f 246g== X-Gm-Message-State: AFeK/H2tH1rZkwcRQPgFTy2aHc+zoxfkqBRk7V5MYdbxgUOd8TTADWVp7xuaSWpblnUqkyasiSR6T3aLz+llsg== X-Received: by 10.55.46.71 with SMTP id u68mr3267439qkh.115.1490975881296; Fri, 31 Mar 2017 08:58:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.27.194 with HTTP; Fri, 31 Mar 2017 08:58:00 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> From: Martin Thomson Date: Fri, 31 Mar 2017 10:58:00 -0500 Message-ID: To: Cullen Jennings Cc: Bernard Aboba , Christer Holmberg , mmusic Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 31 Mar 2017 15:58:07 -0000 On 31 March 2017 at 10:54, Cullen Jennings wrote: > I realize the topic of playing out the data is very complicated, but the > topic I think should be though about first is buffering the video i frames > so they are not lost. That is something I am quite comfortable with. Any data that is received doesn't need to be discarded outright, some of it can be held for a short time in anticipation of being able to authenticate it. That's likely critical for early call performance. This is especially bad for video where a) you can't send a lot, b) you need to send a lot, and c) everything else that follows is dependent on that early data. From nobody Fri Mar 31 10:36:14 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 F1596129869 for ; Fri, 31 Mar 2017 10:36:12 -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, RP_MATCHES_RCVD=-0.001, 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 y4fO5haz-au2 for ; Fri, 31 Mar 2017 10:36:10 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 07B941299A1 for ; Fri, 31 Mar 2017 10:36:10 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id n21so71452535qta.1 for ; Fri, 31 Mar 2017 10:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lqtfg/oZs9deqqaMpZe7xRhXY2QMzbenC6jCNJo+sFY=; b=SAKygK8l22/5Oy5CYONSCiTZvqpKnDJYUwQSoDmKg9r8OPdn6bmbmFCBue/Aa5Ugd0 fUhNYGYuB4aa0BEtR4+GnJ/bYtcmCp5O82VVq8XS+B3VPcwJbk45CkdKMn0Ma2liJfBd /0CbHRAvAKT7UFjjdJY5AFj5UMUpff7KoYxzk3I2rXW2Um+lo9DObXLr4hKAMAUYm94W TM39g9edn03cBjFE227keD+uXKCS/fi8UCa/zy/+OrBxK/oWCEh22TI3PDSR4oeh0KOM CX+7dG5VNakbI2TDkdod8GOYN7q9qvz+l6fjTSpF7j26d+3znPjIvxCzrGmsOHKcElhr 5edA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lqtfg/oZs9deqqaMpZe7xRhXY2QMzbenC6jCNJo+sFY=; b=HUrD7IpQc2GCoRfi7I3xx2l6RuaAuKZcZTL5CUg5W95NOFVGJufXcEUlUkALqqNsUu uoFlZRyMEqRWNtRCSAAwIXq895xiZ4sl99K/Vn/qzHS93/XULKFvMNPO+kYmnfUuoeMq YylbTUWvC2IYPWctiAo1kFxiajD0WK2+BldEl+5o0Pf9zBX0KAONxOFl7BylUyOb/q2e qxfwLM/Lb4rSAeHihnILulDSfeuCR4sbBSVu2dZi47bo6kayAHi7IHA3K8/uk1TUVe3M qLEgLBZq92vhWDY806j7TVasQ7YDf13H0YNFlQW5ZZx5vTFcypUmKDyJTg4KmbvJEBMs TOvA== X-Gm-Message-State: AFeK/H1byYspcpNukRPhNSeoZwAUB0hpMXhGBtnu0X8HS2Fmd3anGr703oo2KblT56SLqaa0htLmGNJ9ShUtQhg+ X-Received: by 10.237.36.53 with SMTP id r50mr4383178qtc.46.1490981768875; Fri, 31 Mar 2017 10:36:08 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> <04A030AC-0323-42D5-AE7D-33EAB8EC8A30@iii.ca> In-Reply-To: <04A030AC-0323-42D5-AE7D-33EAB8EC8A30@iii.ca> From: Peter Thatcher Date: Fri, 31 Mar 2017 17:35:58 +0000 Message-ID: To: Cullen Jennings Cc: Christer Holmberg , mmusic Content-Type: multipart/alternative; boundary=001a113c7148b3b090054c0a3e6c Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 31 Mar 2017 17:36:13 -0000 --001a113c7148b3b090054c0a3e6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How did ICE+TLS "come up" butween A and S without A knowing S's ICE ufrag/pwd, and thus S's fingerprint? I assume it does know S's fingerprint before it can decrypt any media from/through S. Now are you suggesting that the remote fingerprint be changed to G's fingerprint? In that case, a new DTLS handshake would take place, but only after A know's G's fingerprint. In both cases, A knows the fingerprint before being able to decrypt incoming media. The only way to be able to decrypt media before having the remote fingerprint is if you can receive the ICE ufrag/pwd before the DTLS fingerprint. And with WebRTC/JSEP, it's impossible to get the ICE ufrag/pwd before the DTLS fingerprint. Changing to a second/different fingerprint after that doesn't change anything. On Fri, Mar 31, 2017 at 8:52 AM Cullen Jennings wrote: > > Imagine a WebRTC browser called A sends an offer to a SBC called S. S > sends PR offer accepting data channel but not others. ICE comes up betwee= n > A and S. A TLS channel comes up between A and S. S forwards the offer to > gateway called G over SIP with no ICE. G sends a TLS connection to A that > is relayed via G. So this new connection is in the same ICE context. The > ICE goes between A and S. But the 2nd TLS goes between A and G but gatewa= y > by S. > > I realize a more complete description would be useful but hopefully that > is enough to think about a bit. > > > > On Mar 30, 2017, at 2:14 PM, Peter Thatcher wrote: > > We have a mailing list discussion (here), a bug ( > https://github.com/w3c/webrtc-pc/issues/849) and a PR ( > https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about > this. I've copied the following comments to the latter two, so I'm addin= g > them here as well. > > TL;DR: I don't think unverified media is compatible with ICE+DTLS. Here > is why (you can go see the bug, too): > > > 1. > > You can *receive* DTLS from the remote side before receiving the > remote description (and thus fingerprint). This happens if the remote = side > sends an ICE connectivity check and the local side sends a response an= d > then the remote side sends a DTLS packet. > 2. > > You cannot *send* DTLS from the local side before receiving the remote > description (and thus fingerprint). This is because you can't send an = ICE > connectivity check until you have the remote ICE ufrag and pwd, and th= us > can't get an ICE connectivity check response, and thus can't send DTLS= . > This is because you can't send anything other than ICE until you get a= n ICE > connectivity check response. > 3. > > Since you can't send DTLS, you can't complete the handshake, and thus > can't extract the SRTP key. > > > Maybe I'm missing something, but I think this is impossible. > > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: > > > On Mar 13, 2017, at 3:44 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > My question is: is this something that=E2=80=99s causing problems in real > deployments, and requires a change in the standard? > > > 1-800 go fedex. See webrtc requirements documents from many years ago. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --001a113c7148b3b090054c0a3e6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How did ICE+TLS "come up" butween A and S withou= t A knowing S's ICE ufrag/pwd, and thus S's fingerprint?=C2=A0 I as= sume it does know S's fingerprint before it can decrypt any media from/= through S.

Now are you suggesting that the remote finger= print be changed to G's fingerprint?=C2=A0 In that case, a new DTLS han= dshake would take place, but only after A know's G's fingerprint. = =C2=A0

In both cases, A knows the fingerprint befo= re being able to decrypt incoming media.


The only way to be able to decrypt media before having the remote fin= gerprint is if you can receive the ICE ufrag/pwd before the =C2=A0DTLS fing= erprint.=C2=A0 And with WebRTC/JSEP, it's impossible to get the ICE ufr= ag/pwd before the DTLS fingerprint.=C2=A0 Changing to a second/different fi= ngerprint after that doesn't change anything.

=


On = Fri, Mar 31, 2017 at 8:52 AM Cullen Jennings <fluffy@iii.ca> wrote:

Imagine a WebRTC browser called A send= s an offer to a SBC called S.=C2=A0 S sends PR offer accepting data channel= but not others. ICE comes up between A and S. A TLS channel comes up betwe= en A and S. S forwards the offer to gateway called G over SIP with no ICE. = G sends a TLS connection to A that is relayed via G. So this new connection= is in the same ICE context. The ICE goes between A and S. But the 2nd TLS = goes between A and G but gateway by S.=C2=A0

I realize a more complete = description would be useful but hopefully that is enough to think about a b= it.=C2=A0



On Mar 30, 2017, at 2:14= PM, Peter Thatcher <pthatcher@google.com> wrote:

We have a mailing list = discussion (here), a bug (https://github.com/w3c/webrtc-= pc/issues/849) and a PR (https= ://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) about thi= s.=C2=A0 I've copied the following comments to the latter two, so I'= ;m adding them here as well.

TL;DR: I don't think unverified media = is compatible with ICE+DTLS.=C2=A0 Here is why (you can go see the bug, too= ):

  1. You can=C2=A0receive=C2=A0DTLS from the remote side before receiving the remote description (and = thus fingerprint). This happens if the remote side sends an ICE connectivit= y check and the local side sends a response and then the remote side sends = a DTLS packet.

  2. You cannot=C2= =A0send= =C2=A0DTLS from the local side before receiving the remote de= scription (and thus fingerprint). This is because you can't send an ICE= connectivity check until you have the remote ICE ufrag and pwd, and thus c= an't get an ICE connectivity check response, and thus can't send DT= LS. This is because you can't send anything other than ICE until you ge= t an ICE connectivity check response.

  3. = Since you can't send DTLS, you can't complete the handshake, and th= us can't extract the SRTP key.


Maybe I'm missing something, but I think this is impossi= ble.

On Sat, Mar 25, 2017 at 1:12 PM Cull= en Jennings <fluffy@iii.ca> wrote:

On Mar 13, 20= 17, at 3:44 PM, Christer Holmberg <christer.holmberg@ericss= on.com> wrote:

My question is: is this something that=E2=80=99s causing problems i= n real deployments, and requires a change in the standard?= =C2=A0

=
1-800 go fedex. See webrtc requirements documents from many years ago= .=C2=A0
_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic

--001a113c7148b3b090054c0a3e6c-- From nobody Fri Mar 31 10:53: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 0242312778E for ; Fri, 31 Mar 2017 10:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Cs-26tLDDmEB for ; Fri, 31 Mar 2017 10:53:50 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 9E056126D74 for ; Fri, 31 Mar 2017 10:53:50 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id 21so77808810pgg.1 for ; Fri, 31 Mar 2017 10:53: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=d2u6MOhf1fECrCqa7KWDwzFRHD8khCSaPxGkCBVhJSg=; b=LkgO4glVHBTXL2RaNkAo5NB80I7pUwJBp0IFQetzljv1cYKgNLk8CkpByL1yGV9Tab 2RNfh04H1M2VUDE4cSYKkAtMXmHIscq0vBeaeNaQOe3Y8K+3/s6qyw5oRW8pmhZ4J49Q HkzZZQZgSAAjmWqof7+DIO+79ldDMiOJBq4m1WZBwp37LPKLR1FMZYQZdPByL4UBNzJy XJV9rtuSJvTBapECmjgsVg6jg4ZmnK3KmLAmrXqyRyIgz8KlKp2VYEQnp074+b3uCiyU nkFoV+EUfzmGynpYKmTULP6oNR04od+9KGZKEGiwMpI21UzxRNiEBZgd4tSPdiuASV4j tyXw== 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=d2u6MOhf1fECrCqa7KWDwzFRHD8khCSaPxGkCBVhJSg=; b=gHVc/d4Hj4LKQ6QT+Y1MRPeBek59b4bkj166mvxj1AW9qwuVsySN9b0tktiDN9/xKw 5vR9SOXDxb4mORTBDqp9FGHqEPeRDcVWgjxzjaeNxAQTh30U3tVqCK3YvdDi0wdotciQ PyKzlxd36EX2r7RlcBuPwLq1JPNZlQaoIyPXs+Qo7QceDSfLbh6s9BqYWnJou+Ru2zZ1 GfhnsXfYEhe3+RGYnqH7nqxX222hA7/HuVzoO8q7H0eiaVGD6i6KtNVZ3D2+3clawJ31 +RnKpGAwx9RfQcVQSC4gVHamI4LQw0RGyhW95D2O8MmQJFKdBtzKw59Z0QBeqQphgiXe Iuxg== X-Gm-Message-State: AFeK/H3aM5ZuCsDShwd4OLFIX6ez/8VWEEpEUqF/WivHQc7TrQ/EzQ006a2/e6d/dP5b/g== X-Received: by 10.99.181.25 with SMTP id y25mr4280442pge.214.1490982830046; Fri, 31 Mar 2017 10:53:50 -0700 (PDT) Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com. [74.125.83.46]) by smtp.gmail.com with ESMTPSA id g75sm11800944pfj.107.2017.03.31.10.53.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 10:53:49 -0700 (PDT) Received: by mail-pg0-f46.google.com with SMTP id 21so77808355pgg.1 for ; Fri, 31 Mar 2017 10:53:49 -0700 (PDT) X-Received: by 10.99.122.78 with SMTP id j14mr4272634pgn.52.1490982829107; Fri, 31 Mar 2017 10:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Fri, 31 Mar 2017 10:53:48 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> From: Roman Shpount Date: Fri, 31 Mar 2017 13:53:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Peter Thatcher Cc: Martin Thomson , Bernard Aboba , mmusic , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary=f403045c5df4e53c23054c0a7d89 Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 31 Mar 2017 17:53:53 -0000 --f403045c5df4e53c23054c0a7d89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter, Any comments on the ICE Lite scenario? I did see it in the wild. Regards, _____________ Roman Shpount On Thu, Mar 30, 2017 at 9:11 PM, Roman Shpount wrote: > Peter, > > What about ICE lite? If ICE lite sends an offer to WebRTC end point, it > can get DTLS ClientHello before it got the answer response from the WebRT= C > end point. Since ICE lite client does not send ICE requests before sendin= g > data, it will respond with ServerHello and establish the connection. At > this point data can be sent to it before the answer arrives and fingerpri= nt > can be verified. > > I think the right answer to this situation is not to send ServerHello > until answer and fingerprint is received. ClientHello should be buffered > and only handled when answer is received. > > Regards, > > _____________ > Roman Shpount > > On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatcher > wrote: > >> Bernard, you are right that this is possible with ORTC, even though I >> think it's impossible with WebRTC. But that's clearly out of scope for = the >> MMUSIC WG. Perhaps the right forum to discuss Cullen's 1-800-fedex use >> case is in the context of ORTC (or WebRTC NV). >> >> On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson >> wrote: >> >>> These both sound like legitimate cases where ICE can precede >>> signaling. I would recommend that the W3C think carefully about >>> whether they might like to accept (potentially) invalid data before we >>> spend a whole lot more time on the issue. >>> >>> On 30 March 2017 at 17:11, Bernard Aboba >>> wrote: >>> > The unverified media scenarios seem to depend on ICE connectivity bei= ng >>> > bi-directionally enabled so as to permit the DTLS negotiation to >>> proceed in >>> > advance of remote fingerprint arrival. If ICE candidates are signaled >>> > separately from the DTLS fingerprint exchange it might be feasible, >>> such as >>> > in ORTC signaling where the ICE parameters are exchanged before the >>> > DtlsParameters. >>> > >>> > At the last WebRTC interim a scenario involving PRANSWER and Trickle >>> ICE was >>> > presented. In the scenario, the PRANSWER included a fingerprint, but >>> > possibly one which did not match the certificate provided in DTLS >>> unlike the >>> > final answer. I do not see how this could work but perhaps I am missi= ng >>> > something. >>> > >>> > On Mar 30, 2017, at 14:14, Peter Thatcher >>> wrote: >>> > >>> > We have a mailing list discussion (here), a bug >>> > (https://github.com/w3c/webrtc-pc/issues/849) and a PR >>> > (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) >>> about >>> > this. I've copied the following comments to the latter two, so I'm >>> adding >>> > them here as well. >>> > >>> > TL;DR: I don't think unverified media is compatible with ICE+DTLS. >>> Here is >>> > why (you can go see the bug, too): >>> > >>> > You can receive DTLS from the remote side before receiving the remote >>> > description (and thus fingerprint). This happens if the remote side >>> sends an >>> > ICE connectivity check and the local side sends a response and then t= he >>> > remote side sends a DTLS packet. >>> > >>> > You cannot send DTLS from the local side before receiving the remote >>> > description (and thus fingerprint). This is because you can't send an >>> ICE >>> > connectivity check until you have the remote ICE ufrag and pwd, and >>> thus >>> > can't get an ICE connectivity check response, and thus can't send >>> DTLS. This >>> > is because you can't send anything other than ICE until you get an IC= E >>> > connectivity check response. >>> > >>> > Since you can't send DTLS, you can't complete the handshake, and thus >>> can't >>> > extract the SRTP key. >>> > >>> > >>> > Maybe I'm missing something, but I think this is impossible. >>> > >>> > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote= : >>> >> >>> >> >>> >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg >>> >> wrote: >>> >> >>> >> My question is: is this something that=E2=80=99s causing problems in= real >>> >> deployments, and requires a change in the standard? >>> >> >>> >> >>> >> 1-800 go fedex. See webrtc requirements documents from many years ag= o. >>> >> _______________________________________________ >>> >> 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 >>> > >>> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --f403045c5df4e53c23054c0a7d89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter,

Any comments on the ICE Lite sce= nario? I did see it in the wild.

Regards,

_____________
Roman Shpount<= /div>

On Thu, Mar 30, 2017 at 9:11 PM, Roman Shpou= nt <roman@telurix.com> wrote:
Peter,

What about ICE lite? If ICE = lite sends an offer to WebRTC end point, it can get DTLS ClientHello before= it got the answer response from the WebRTC end point. Since ICE lite clien= t does not send ICE requests before sending data, it will respond with Serv= erHello and establish the connection. At this point data can be sent to it = before the answer arrives and fingerprint can be verified.

I think the right answer to this situation is not to send ServerHe= llo until answer and fingerprint is received. ClientHello should be buffere= d and only handled when answer is received.

Regard= s,

_____________
Roman Shp= ount

On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatc= her <pthatcher@google.com> wrote:
Bernard, you are right that this is possible wi= th ORTC, even though I think it's impossible with WebRTC.=C2=A0 But tha= t's clearly out of scope for the MMUSIC WG.=C2=A0 Perhaps the right for= um to discuss Cullen's 1-800-fedex use case is in the context of ORTC (= or WebRTC NV).

On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson <martin.thomson@gmail.com> wr= ote:
These both sound like legitima= te cases where ICE can precede
signaling.=C2=A0 I would recommend that the W3C think carefully about
whether they might like to accept (potentially) invalid data before we
spend a whole lot more time on the issue.

On 30 March 2017 at 17:11, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> The unverified media scenarios seem to depend on ICE connectivity bein= g
> bi-directionally enabled so as to permit the DTLS negotiation to proce= ed in
> advance of remote fingerprint arrival. If ICE candidates are signaled<= br class=3D"m_2025298449121699190m_5127523717455880218gmail_msg"> > separately from the DTLS fingerprint exchange it might be feasible, su= ch as
> in ORTC signaling where the ICE parameters are exchanged before the > DtlsParameters.
>
> At the last WebRTC interim a scenario involving PRANSWER and Trickle I= CE was
> presented. In the scenario, the PRANSWER included a fingerprint, but > possibly one which did not match the certificate provided in DTLS unli= ke the
> final answer. I do not see how this could work but perhaps I am missin= g
> something.
>
> On Mar 30, 2017, at 14:14, Peter Thatcher <pthatcher@google.com> wrote:
>
> We have a mailing list discussion (here), a bug
> (https://github.com/w3c/webrtc-pc/issues/849) and a PR<= br class=3D"m_2025298449121699190m_5127523717455880218gmail_msg"> > (https://github.com/w3c/webrtc-pc/pull= /1026#issuecomment-279238215) about
> this.=C2=A0 I've copied the following comments to the latter two, = so I'm adding
> them here as well.
>
> TL;DR: I don't think unverified media is compatible with ICE+DTLS.= =C2=A0 Here is
> why (you can go see the bug, too):
>
> You can receive DTLS from the remote side before receiving the remote<= br class=3D"m_2025298449121699190m_5127523717455880218gmail_msg"> > description (and thus fingerprint). This happens if the remote side se= nds an
> ICE connectivity check and the local side sends a response and then th= e
> remote side sends a DTLS packet.
>
> You cannot send DTLS from the local side before receiving the remote > description (and thus fingerprint). This is because you can't send= an ICE
> connectivity check until you have the remote ICE ufrag and pwd, and th= us
> can't get an ICE connectivity check response, and thus can't s= end DTLS. This
> is because you can't send anything other than ICE until you get an= ICE
> connectivity check response.
>
> Since you can't send DTLS, you can't complete the handshake, a= nd thus can't
> extract the SRTP key.
>
>
> Maybe I'm missing something, but I think this is impossible.
>
> On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <fluffy@iii.ca> wrote:
>>
>>
>> On Mar 13, 2017, at 3:44 PM, Christer Holmberg
>> <christe= r.holmberg@ericsson.com> wrote:
>>
>> My question is: is this something that=E2=80=99s causing problems = in real
>> deployments, and requires a change in the standard?
>>
>>
>> 1-800 go fedex. See webrtc requirements documents from many years = ago.
>> _______________________________________________
>> 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
>

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


--f403045c5df4e53c23054c0a7d89-- From nobody Fri Mar 31 10:59: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 8A2281243F3 for ; Fri, 31 Mar 2017 10:59:41 -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, RP_MATCHES_RCVD=-0.001, 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 nCeXJ-NowEEe for ; Fri, 31 Mar 2017 10:59:38 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F83129435 for ; Fri, 31 Mar 2017 10:59:37 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p22so73225829qka.3 for ; Fri, 31 Mar 2017 10:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lyVlGQjF3+lKyZg28YOufvyPo0IBdOq6H1xvGrCE9eo=; b=O5qpzQgVqtvzTQFwfIjvVYy00uo3x8b8iuYd5P3oENHrKQGiq4BCzd5TZwZGB4BTL+ 7CMN4fsWOSEAO1T1PwuFe1ytCGGx1z4s+fx2RweWS5mXxkQeSdKZqaDQBcgFThKadJLX n4rY+Dc1GB+aXK0qpDFW2nI1yVeAW65ZDQ/s+lQfrxqak6yz1CV0S8bB+DCk/ZZuMF4J YUYB54rZqm868WMpovEBNGXV5KJ6xX8yNrsqlAz3auAZUBKfcOFwmvjTJP8sRUMiQWLr Y/Av4cbic6valSI1f5wzMH5AelcBcQRFUH7GZG8mgxw7yozgl8lrue4JIVLh29iXeHCa YLWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lyVlGQjF3+lKyZg28YOufvyPo0IBdOq6H1xvGrCE9eo=; b=RUFP5HWG/4EtKZywkAzS1kBiZspzC/zzc4bT7IE64kfsf51cr2is3RCVb0LbAn2l2h wpIH/Crm/51shA5uzYh9evVlXGk/YEHx8I7wpvQYBzwCQ9aOqQyfcmavQLOWiQ72KzGd 3hp1o9u6t9dK5elUFbTyKOQ+GNxnp4iWz6JZfm4GClMfyfRTjBTjTOVv30HPGvaYGFcE 6vHcyA0FAVMUNGdZcaklo594NWMSw4zriUDp5rXbnFRUMYeCUiQ3yel2xkaXtbYrmyMo 8pVkHq70G3dl4OStqUMQAM0dRH1U2rILEveDQ6sS73MYXfBhwIAnlpJm98G/Q8naYtH2 oo+w== X-Gm-Message-State: AFeK/H10+wyXprE/Ulttfp+cHr3oUDeYJMNZ1X8V7qLOAX5Y4e3iAe561vZd8RdTweDoXPRdpKXm37hxZq1vm9Bd X-Received: by 10.55.20.234 with SMTP id 103mr3648632qku.200.1490983176850; Fri, 31 Mar 2017 10:59:36 -0700 (PDT) MIME-Version: 1.0 References: <7594FB04B1934943A5C02806D1A2204B4CB06D6C@ESESSMB109.ericsson.se> <67E58DC2-89CB-45AB-9452-C6A7DFEA34A4@vidyo.com> <7594FB04B1934943A5C02806D1A2204B4CB0B034@ESESSMB109.ericsson.se> In-Reply-To: From: Peter Thatcher Date: Fri, 31 Mar 2017 17:59:25 +0000 Message-ID: To: Roman Shpount Cc: Martin Thomson , Bernard Aboba , mmusic , Cullen Jennings , Christer Holmberg Content-Type: multipart/alternative; boundary=001a11400ff09fb6a4054c0a9296 Archived-At: Subject: Re: [MMUSIC] Handling of unverified data and media 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, 31 Mar 2017 17:59:41 -0000 --001a11400ff09fb6a4054c0a9296 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If the full ice endpoint receives an offer, it has the remote DTLS fingerprint, so no problem on that It's true that the ice lite endpoint will be able to receive media from the full ice endpoint before it receives the DTLS fingerprint of the full ICE endpoint. So you are correct that this is an issue for ice lite endpoints, just as it is for non-ICE endpoints. On Thu, Mar 30, 2017 at 6:11 PM Roman Shpount wrote: > Peter, > > What about ICE lite? If ICE lite sends an offer to WebRTC end point, it > can get DTLS ClientHello before it got the answer response from the WebRT= C > end point. Since ICE lite client does not send ICE requests before sendin= g > data, it will respond with ServerHello and establish the connection. At > this point data can be sent to it before the answer arrives and fingerpri= nt > can be verified. > > I think the right answer to this situation is not to send ServerHello > until answer and fingerprint is received. ClientHello should be buffered > and only handled when answer is received. > > Regards, > > _____________ > > Roman Shpount > > On Thu, Mar 30, 2017 at 7:40 PM, Peter Thatcher > wrote: > > Bernard, you are right that this is possible with ORTC, even though I > think it's impossible with WebRTC. But that's clearly out of scope for t= he > MMUSIC WG. Perhaps the right forum to discuss Cullen's 1-800-fedex use > case is in the context of ORTC (or WebRTC NV). > > On Thu, Mar 30, 2017 at 3:50 PM Martin Thomson > wrote: > > These both sound like legitimate cases where ICE can precede > signaling. I would recommend that the W3C think carefully about > whether they might like to accept (potentially) invalid data before we > spend a whole lot more time on the issue. > > On 30 March 2017 at 17:11, Bernard Aboba wrote: > > The unverified media scenarios seem to depend on ICE connectivity being > > bi-directionally enabled so as to permit the DTLS negotiation to procee= d > in > > advance of remote fingerprint arrival. If ICE candidates are signaled > > separately from the DTLS fingerprint exchange it might be feasible, suc= h > as > > in ORTC signaling where the ICE parameters are exchanged before the > > DtlsParameters. > > > > At the last WebRTC interim a scenario involving PRANSWER and Trickle IC= E > was > > presented. In the scenario, the PRANSWER included a fingerprint, but > > possibly one which did not match the certificate provided in DTLS unlik= e > the > > final answer. I do not see how this could work but perhaps I am missing > > something. > > > > On Mar 30, 2017, at 14:14, Peter Thatcher wrote: > > > > We have a mailing list discussion (here), a bug > > (https://github.com/w3c/webrtc-pc/issues/849) and a PR > > (https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-279238215) > about > > this. I've copied the following comments to the latter two, so I'm > adding > > them here as well. > > > > TL;DR: I don't think unverified media is compatible with ICE+DTLS. Her= e > is > > why (you can go see the bug, too): > > > > You can receive DTLS from the remote side before receiving the remote > > description (and thus fingerprint). This happens if the remote side > sends an > > ICE connectivity check and the local side sends a response and then the > > remote side sends a DTLS packet. > > > > You cannot send DTLS from the local side before receiving the remote > > description (and thus fingerprint). This is because you can't send an I= CE > > connectivity check until you have the remote ICE ufrag and pwd, and thu= s > > can't get an ICE connectivity check response, and thus can't send DTLS. > This > > is because you can't send anything other than ICE until you get an ICE > > connectivity check response. > > > > Since you can't send DTLS, you can't complete the handshake, and thus > can't > > extract the SRTP key. > > > > > > Maybe I'm missing something, but I think this is impossible. > > > > On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings wrote: > >> > >> > >> On Mar 13, 2017, at 3:44 PM, Christer Holmberg > >> wrote: > >> > >> My question is: is this something that=E2=80=99s causing problems in r= eal > >> deployments, and requires a change in the standard? > >> > >> > >> 1-800 go fedex. See webrtc requirements documents from many years ago. > >> _______________________________________________ > >> 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 > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --001a11400ff09fb6a4054c0a9296 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the full ice endpoint receives an offer, it has the rem= ote DTLS fingerprint, so no problem on that=C2=A0

It'= ;s true that the ice lite endpoint will be able to receive media from the f= ull ice endpoint before it receives the DTLS fingerprint of the full ICE en= dpoint.=C2=A0 So you are correct that this is an issue for ice lite endpoin= ts, just as it is for non-ICE endpoints.




On Thu, Mar 30, 2017 at 6:11 PM Roman Shpount <roman@telurix.com> wrote:
Peter,

What about I= CE lite? If ICE lite sends an offer to WebRTC end point, it can get DTLS Cl= ientHello before it got the answer response from the WebRTC end point. Sinc= e ICE lite client does not send ICE requests before sending data, it will r= espond with ServerHello and establish the connection. At this point data ca= n be sent to it before the answer arrives and fingerprint can be verified.<= /div>

I think the right answer to this situation is not to send ServerH= ello until answer and fingerprint is received. ClientHello should be buffer= ed and only handled when answer is received.
=
Regards,
=

=
_____________

Roman Shpount

On Thu, Mar 30= , 2017 at 7:40 PM, Peter Thatcher <= ;pthatcher@google.com> wrote:
Be= rnard, you are right that this is possible with ORTC, even though I think i= t's impossible with WebRTC.=C2=A0 But that's clearly out of scope f= or the MMUSIC WG.=C2=A0 Perhaps the right forum to discuss Cullen's 1-8= 00-fedex use case is in the context of ORTC (or WebRTC NV).

On Thu, Mar 30, 2017 at 3:50 PM M= artin Thomson <martin.thomson@gmail.com> wrote:
These both so= und like legitimate cases where ICE can precede
signaling.=C2=A0 I would recommend that the W3C think carefully about
whether they might like to accept (potentially) invalid data before we
spend a whole lot more time on the issue.

bernard.aboba@gmail.com> wrote:
> The unverified media scenarios seem to depend on ICE connectivity bein= g
> bi-directionally enabled so as to permit the DTLS negotiation to proce= ed in
> advance of remote fingerprint arrival. If ICE candidates are signaled<= br class=3D"m_-9111553311775435657m_5127523717455880218gmail_msg gmail_msg"= > > separately from the DTLS fingerprint exchange it might be feasible, su= ch as
> in ORTC signaling where the ICE parameters are exchanged before the > DtlsParameters.
>
> At the last WebRTC interim a scenario involving PRANSWER and Trickle I= CE was
> presented. In the scenario, the PRANSWER included a fingerprint, but > possibly one which did not match the certificate provided in DTLS unli= ke the
> final answer. I do not see how this could work but perhaps I am missin= g
> something.
>
> On Mar 30, 2017, at 14:14, Peter Thatcher <pthatcher@google.com> wrote:
>
> We have a mailing list discussion (here), a bug
> (https://github.com/w3c/webrtc-pc/issues/849) and = a PR
> (https://github.com/w3c/webrtc-p= c/pull/1026#issuecomment-279238215) about
> this.=C2=A0 I've copied the following comments to the latter two, = so I'm adding
> them here as well.
>
> TL;DR: I don't think unverified media is compatible with ICE+DTLS.= =C2=A0 Here is
> why (you can go see the bug, too):
>
> You can receive DTLS from the remote side before receiving the remote<= br class=3D"m_-9111553311775435657m_5127523717455880218gmail_msg gmail_msg"= > > description (and thus fingerprint). This happens if the remote side se= nds an
> ICE connectivity check and the local side sends a response and then th= e
> remote side sends a DTLS packet.
>
> You cannot send DTLS from the local side before receiving the remote > description (and thus fingerprint). This is because you can't send= an ICE
> connectivity check until you have the remote ICE ufrag and pwd, and th= us
> can't get an ICE connectivity check response, and thus can't s= end DTLS. This
> is because you can't send anything other than ICE until you get an= ICE
> connectivity check response.
>
> Since you can't send DTLS, you can't complete the handshake, a= nd thus can't
> extract the SRTP key.
>
>
> Maybe I'm missing something, but I think this is impossible.
>
> On Sat, Mar 25, 2017 at 1:12 PM Cullen Jennings <fluffy@iii.ca> wrote:
>>
>>
>> On Mar 13, 2017, at 3:44 PM, Christer Holmberg
>> <christer.holmberg@ericsson.com> wrote:
>>
>> My question is: is this something that=E2=80=99s causing problems = in real
>> deployments, and requires a change in the standard?
>>
>>
>> 1-800 go fedex. See webrtc requirements documents from many years = ago.
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org=
>> https://www.ietf.org/mailman/listinfo/mmusic<= br class=3D"m_-9111553311775435657m_5127523717455880218gmail_msg gmail_msg"= > >
> _______________________________________________
> 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
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic


--001a11400ff09fb6a4054c0a9296-- From nobody Fri Mar 31 14:19:44 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 2C2CD1299F4 for ; Fri, 31 Mar 2017 14:19:43 -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 liy2ElkWn15x for ; Fri, 31 Mar 2017 14:19:41 -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 CFB9F129A0C for ; Fri, 31 Mar 2017 14:19:38 -0700 (PDT) X-AuditID: c1b4fb3a-7bbff70000005492-9b-58dec7e84985 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 1E.CD.21650.8E7CED85; Fri, 31 Mar 2017 23:19:37 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.242]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Fri, 31 Mar 2017 23:19:35 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: BUNDLE: Usage of media specific SDP attributes Thread-Index: AdKqZGTNEOMx2KwMQm+nSZqR8GzTWA== Date: Fri, 31 Mar 2017 21:19:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB3B720@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_7594FB04B1934943A5C02806D1A2204B4CB3B720ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7pe7L4/ciDM7VWUxd/pjFgdFjyZKf TAGMUVw2Kak5mWWpRfp2CVwZHzpWsxS8k6iYPuEXewPjdLEuRk4OCQETiZ7vF5i6GLk4hATW M0p8n7+bGSQhJLCEUWLeB6AEBwebgIVE9z9tkLCIgLrE1709YCXCAuYSKz43s0LEbSS+7pnG DmHrSez/fQYsziKgKvFs4RqwOK+Ar0TTka9gvYwCYhLfT61hArGZBcQlbj2ZzwRxj4DEkj3n mSFsUYmXj/+xQthKEiu2X2KEqM+X+H9sERPETEGJkzOfsExgFJyFZNQsJGWzkJRBxHUkFuz+ xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBYX9wy2+r HYwHnzseYhTgYFTi4X2QcC9CiDWxrLgy9xCjBAezkggvUxxQiDclsbIqtSg/vqg0J7X4EKM0 B4uSOK/DvgsRQgLpiSWp2ampBalFMFkmDk6pBsbyKbf3981d35S7ZbfVvNXuct3fmMpqY5uq Q7ZOfrlYuDCOsywv7OKBtYd3XcwXWLJf/ti3ZN/cOxk1Xa7aaTq3LPMW3JyVy+7Yt0Y1W+5f w4HwY27JpT8SPkd5hFdq8HF/Uu5Sl/W+ksxp88C2enpnSN+dzt2GaRNZs+ZLsvzgNd/yKOPm MiWW4oxEQy3mouJEAO7C4od3AgAA Archived-At: Subject: [MMUSIC] BUNDLE: Usage of media specific SDP attributes 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, 31 Mar 2017 21:19:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB3B720ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've created a PR adding text regarding the usage of media specific SDP att= ributes with "m=3D" lines representing a different media type. Feel free to add/modify/comment. https://github.com/cdh4u/draft-sdp-bundle/pull/33 Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB3B720ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve created a PR adding text regarding the us= age of media specific SDP attributes with “m=3D” lines represen= ting a different media type.

 

Feel free to add/modify/comment.

 

https://github.com/cdh4u/draft-sdp-bundle/pull/33<= /p>

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB3B720ESESSMB109erics_--