From nobody Fri Jun 2 23:48:05 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7200126C0F for ; Fri, 2 Jun 2017 23:48:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 dsGCj8fwDNBm for ; Fri, 2 Jun 2017 23:48:02 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 A50E2124217 for ; Fri, 2 Jun 2017 23:48:02 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id f185so1169862pgc.0 for ; Fri, 02 Jun 2017 23:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=sJRdIGCO2xnxpos0Ds7M4W63O5qryiSge+sc1ZSdRLg=; b=DkX7sKCXcC0sNbvDCrLIjgPpsF0RgxnRk1tvpjCLA9o2arz42oZDqdF4yZTwNsZSjW nYbjz+ad0sVQJX/rlBaOz4g5tHQE/Mq60d8aoP4tKFHa0klyd9lQ2aHMqlbdg0V6pQjz 7c6/qaTjdrMgEHuzLMEyjFOdJ/0UBuqqPc7s4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=sJRdIGCO2xnxpos0Ds7M4W63O5qryiSge+sc1ZSdRLg=; b=SgibThaMI52E/Uw1jNiMzmJxVBNyBKm6VZYcKMT0r15LRgzd1k79NcG6h5z+RKQHQM OWaMvL8aCSr0GGXvX2r2dqDR0j5pqJf6JA82GFNmPbb36EcZsjxvDQGfJzzAhIBVzgph NsJ0rUYlrjFRYpEQMqpJkrUneYDsoSVY4HNKJTrSxKvTc1mpy9qr0QfKvLUy6y1CeeX4 H4coXvjIpMeh8yR+zKFgAPjdjtt7C2KvPUjaJ/jW/MsvSXTDlS2/NcZn5mg10zBLylOY a7YqbJkOVsQDWJCE3KI+2Z4m0j8jEXXLJAylqx5Mpp/o7c9UtopBjZ5nON96QxwaYntF hbVQ== X-Gm-Message-State: AODbwcA5CuaFThu5OxqXA0XKtq941+qAVElzARe7+TuBefkMPsbchmTe TFR7pak+X7jcWQ4XCbjyMA== X-Received: by 10.84.217.152 with SMTP id p24mr3690920pli.206.1496472481789; Fri, 02 Jun 2017 23:48:01 -0700 (PDT) Received: from ?IPv6:2601:647:4601:ec84:c095:f810:f782:e9cf? ([2601:647:4601:ec84:c095:f810:f782:e9cf]) by smtp.gmail.com with ESMTPSA id 69sm111988pft.41.2017.06.02.23.48.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 23:48:00 -0700 (PDT) From: Nils Ohlmeier Content-Type: multipart/signed; boundary="Apple-Mail=_EE3CB0EC-2BED-46CB-9C3F-EFA35E792114"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Fri, 2 Jun 2017 23:47:58 -0700 To: "perc@ietf.org" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Perc] Canceling 2nd virtual interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 06:48:04 -0000 --Apple-Mail=_EE3CB0EC-2BED-46CB-9C3F-EFA35E792114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Thank you to the people who shared their availability in the Doodle poll = for a 2nd virtual interim meeting. We have seen only a little bit of discussion on the mailing list. And turn out from the Doodle poll is more sparse then we hoped for. Therefor the chairs decided to not have a second virtual interim, but = instead have a hopefully well prepared discussion in Prague. Please continue to discuss the options on the mailing list until then. Best regards The perc WG --Apple-Mail=_EE3CB0EC-2BED-46CB-9C3F-EFA35E792114 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZMlufAAoJEJ3NnGfOORkkc94P/1OlxwdrwJulxKGU/o8s6Jna b3qRDlAAf43fFFqhv53p5bK7EYLs5sontSpOkz2p5/pNsrhqlsaYcTkqvkEumc47 tTtkD3WSRtIIIEtjfjwtylMXJ1j4YphIv6aGTKwAnCaD48vrNernl937BnwUgb2A eWjIdR4i1s36GqscoFqPpCmYpV6a0D+LgZOzavKumy5UOJoacz6iG7NIMjZAyJ8P Lq2+mgQ8Zyt0+qVNO3uPI8VK1eAHca00Q8rgNQT24NaE1+DS+84C1mXsO/cv+XoD xhzdtmLssYZf6UdtlsAulliULm/oFw1aYuc/8c8V0RWm/Z52yACtrWWafcXEaImz vACUqiSyom6NqW6tuN+Hhh28zW/YRynxQwkqQ+yfhdBMYGOEwHgxe9xlRmlJvCZd Ja79ki+/0IwfOsvPoxjJyD4K3ITRZOPMNLg0y0Yo4X3wO2KC4IaezN8Nq3m57ZLa mYdJk/TKwOC5dx+K/cafFEo0Ze+6f14v4TWByg7rS2csPeAM1EatiXaLSKy8A584 WYam64Vblrf3FkAGwiQN6lGjdDWXqtAJoSIIH6snAX00kUYi8geoeszhX6+qUajT d4RAYkinuvsiJONB+FtEPcziDrZrCjzzFX53ZM55znccsIuPzEk/0XxzfLYrL4FF keQlBlTZMu6q51aZGt6i =Sr+h -----END PGP SIGNATURE----- --Apple-Mail=_EE3CB0EC-2BED-46CB-9C3F-EFA35E792114-- From nobody Sat Jun 3 00:46:08 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0C8127078 for ; Sat, 3 Jun 2017 00:46:06 -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 jGFMFT-EiK2I for ; Sat, 3 Jun 2017 00:46:04 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 B2B5B127843 for ; Sat, 3 Jun 2017 00:46:04 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id p62so14438396vkp.0 for ; Sat, 03 Jun 2017 00:46:04 -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=mYImqPjvSW6LeUreCL7BdEVg3XxvMqle8TkrDoAIZ1Y=; b=D+zTr8kKRpoMies3RnmhyyVVTIBpe9jC/uGN58ae0H2y7+tm+UTvS1tdMcFOgiwlOQ kpXVdeUht0YeMurX55oi8Ff0hZzq/sYxEHvgS6gQLJooi93poTNRZ67NRGzYBtkV/82S EXQ3gVu2XA4/ptvRDQzKvLjElPkMAycwcO41n4rd0r/3YuUBVoiwQWMD+5no+v/9keWB +eEpsf9kw3iIJ39I10p/KfJ6/ssDZcnUZFMAuBkK1/7EdieXMYmNt/rAjKQ3btH+9s5e DSnTPibZ+0DN5nMmUvU7Wz86RLiOOxoh/F1QybQmy5VSAc+2fetPdwiGmsN/uOFvsh8B mHqQ== 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=mYImqPjvSW6LeUreCL7BdEVg3XxvMqle8TkrDoAIZ1Y=; b=ts2GHeP7mCEHTII+RGgyejpvQVLW9U/tCsoD0tKgcAv4PqSLxoCMgBEQTbsi3SDhtl HAmHDaKdfqPm+PMey5APGkIMgQDz++tvN2CtEnRoc8GNf6nDEb0xjZJPnQDJoeBqu9a+ NCYlLQyBsYleaGcCpmhFOLVSG+vj6mml0LywRDhsdG1RbwrHhxRKpI4l2bJ9beUkhK9q sy2edR/8ZZb20nDXmjgnrTPUMCnIuPSbTKcgeGMtBwZ1rti5MccuUwszZHcwgSQkJnxP lCyGAM8Nt4lgC81HDhbvftHDk+9muEiorXgtbINW2IZK5p75xUWRQOTNtTvJe3+oTbrS 1uqQ== X-Gm-Message-State: AODbwcDhsoVqKwfDHBjflMlPZcbmXlKlcVLd+7Xs/vk9stg3/9vq7+Rh vf0bnX1EeU3C+4ub0WcUO9CoWobAt1un X-Received: by 10.31.220.68 with SMTP id t65mr5199834vkg.145.1496475963745; Sat, 03 Jun 2017 00:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.49.73 with HTTP; Sat, 3 Jun 2017 00:46:03 -0700 (PDT) In-Reply-To: References: From: Alexandre GOUAILLARD Date: Sat, 3 Jun 2017 15:46:03 +0800 Message-ID: To: Nils Ohlmeier Cc: "perc@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c07bb183beb9405510976cf" Archived-At: Subject: Re: [Perc] Canceling 2nd virtual interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 07:46:07 -0000 --94eb2c07bb183beb9405510976cf Content-Type: text/plain; charset="UTF-8" Nils, chairs, 1. There is a day in the doodle with at least 8 persons committed. It looks almost equal to the number of participating individual in last interim meeting: https://www.ietf.org/proceedings/interim-2017-perc-01/minutes/minutes-interim-2017-perc-01-201705240800-00 2. In the previous meeting it was stated explicitly that people would go back and write documents for next meeting. It is thus not entirely unexpected not to have activity on the mailing list, everybody waiting for the written document to discuss from. 3. Not having the discussion now, and waiting for IETF 99 mid-july put us at risk of either delaying the gula post (originally in June), or taking a decision by default by lack of time, both of which are less than ideal. Question 1: could the chair reconsider Question 2: could we at least commit to have those documents QUICKLY available (no later than the original proposed meeting frame), and discuss them on the mailing list? I would not want someone looking at the archives, and thinking that the process was slowed down by some always objecting without providing examples or better alternative, and last minutes decisions to either not accepting items from the agenda (however intense the corresponding discussion on the mailing list was) or cancel meetings altogether. While I'm sure this is not the intend and everybody here is acting in good faith, I am concerned about how it could be perceived. Regards, Alex. On Sat, Jun 3, 2017 at 2:47 PM, Nils Ohlmeier wrote: > Hello, > > Thank you to the people who shared their availability in the Doodle poll > for a 2nd virtual interim meeting. > > We have seen only a little bit of discussion on the mailing list. > And turn out from the Doodle poll is more sparse then we hoped for. > > Therefor the chairs decided to not have a second virtual interim, but > instead have a hopefully well prepared discussion in Prague. > > Please continue to discuss the options on the mailing list until then. > > Best regards > > The perc WG > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ President - CoSMo Software Consulting, Singapore ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --94eb2c07bb183beb9405510976cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nils, chairs,

1. There is a day in the = doodle with at least 8 persons committed. It looks almost equal to the numb= er of participating individual in last interim meeting:

2. In the previous meeting it was stated explici= tly that people would go back and write documents for next meeting. It is t= hus not entirely unexpected not to have activity on the mailing list, every= body waiting for the written document to discuss from.

=
3. Not having the discussion now, and waiting for IETF 99 mid-july put= us at risk of either delaying the gula post (originally in June), or takin= g a decision by default by lack of time, both of which are less than ideal.=

Question 1: could the chair reconsider
=
Question 2: could we at least commit to have those documents= QUICKLY available (no later than the original proposed meeting frame), and= discuss them on the mailing list?

I would not wan= t someone looking at the archives, and thinking that the process was slowed= down by some always objecting without providing examples or better alterna= tive, and last minutes decisions to either not accepting items from the age= nda (however intense the corresponding discussion on the mailing list was) = or cancel meetings altogether. While I'm sure this is not the intend an= d everybody here is acting in good faith, I am concerned about how it could= be perceived.

Regards,

A= lex.


On Sat, Jun 3, 2017 at 2:47 PM, Nils Ohlmeier = <nohlmeier@mozilla.com> wrote:
Hello,

Thank you to the people who shared their availability in the Doodle poll fo= r a 2nd virtual interim meeting.

We have seen only a little bit of discussion on the mailing list.
And turn out from the Doodle poll is more sparse then we hoped for.

Therefor the chairs decided to not have a second virtual interim, but inste= ad have a hopefully well prepared discussion in Prague.

Please continue to discuss the options on the mailing list until then.

Best regards

The perc WG

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




--
=
Alex. Gouaillard, P= hD, PhD, MBA
----------------------------------------------------------= --------------------------
President - CoSMo Software Consulting,= Singapore
------------------------------------------------------= ------------------------------

    • --94eb2c07bb183beb9405510976cf-- From nobody Tue Jun 6 16:29:06 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6942E126579 for ; Tue, 6 Jun 2017 16:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 Y4xEVjmxtyWM for ; Tue, 6 Jun 2017 16:29:02 -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 10511127867 for ; Tue, 6 Jun 2017 16:29:02 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v18so29813783pgb.1 for ; Tue, 06 Jun 2017 16:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4o7McPxoCRzN54KW+Tdl4SAPIGK9QE5uh1D1+oNwljE=; b=R3YryrDr9JDDTY+2ZtmcKLxfrcKPU8tmp22Z5CQ3NMdyfGalGh1AILZ1THnEWrQUYB vprBlvvE1XjE6fRVm6eKxnpXak24s7p7w8tdMLATKdMMWqxFJ18R2HyetcmzL7XVcqUF AGhl+Q0pNqZZG0B29p9osJvlx0m2NOsPvcnnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4o7McPxoCRzN54KW+Tdl4SAPIGK9QE5uh1D1+oNwljE=; b=nGJ5KRmgr17fGMF+CkQRVfpdRDRxr3+UU25szfxNKLafAzqRznGKcdiQDA53TBcI4Q pN4RDdw1pQyJvu1IEVr2+ZovzCOpfleT1F+1KFqARJtPAw5mCTejuFJ6Zlxb/kjEvoSb vQOUaucDzvJrLN7ZcbJGI9WYxORfSPSbSaEonufP9oNoMv+zcFHBWM+L1xKW8cDb7Mn1 /la6RCp8kR82eKT91ntHbwg5AJsFtwqezpL+e3J7AaCDfSs+o+qaU3mcSHyJVDcupeKQ s9DcBlJeCAyKg7GzFFLVm2g6ulOI2wHhx+f+Leg1S8unLxfA/UuzCrGdk2J6X5VIftsw JFUQ== X-Gm-Message-State: AODbwcBbC5bKYeZPKMbXx9EG6F1BURJWXtkd6KyVgJhmcqUBIsoO0tmE V6PoR8Dy8zYWsFb8 X-Received: by 10.98.110.138 with SMTP id j132mr27871078pfc.51.1496791741439; Tue, 06 Jun 2017 16:29:01 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:3d60:2507:d140:672f? ([2620:101:80fc:224:3d60:2507:d140:672f]) by smtp.gmail.com with ESMTPSA id z66sm30387316pfl.13.2017.06.06.16.28.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 16:28:59 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_31C1F744-08F8-4EF4-8D80-0F9D96B07F9E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 6 Jun 2017 16:28:56 -0700 In-Reply-To: Cc: "perc@ietf.org" , Emil Ivov , Cullen Jennings To: Alexandre GOUAILLARD References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Canceling 2nd virtual interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:29:04 -0000 --Apple-Mail=_31C1F744-08F8-4EF4-8D80-0F9D96B07F9E Content-Type: multipart/alternative; boundary="Apple-Mail=_4F59D8DF-487F-4DB8-8C27-1892C6CE09DD" --Apple-Mail=_4F59D8DF-487F-4DB8-8C27-1892C6CE09DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alex, > On Jun 3, 2017, at 00:46, Alexandre GOUAILLARD = wrote: [=E2=80=A6] > 2. In the previous meeting it was stated explicitly that people would = go back and write documents for next meeting. It is thus not entirely = unexpected not to have activity on the mailing list, everybody waiting = for the written document to discuss from. During the last interim meeting we requested discussion to happen on the = mailing list. Even though I admit that I failed to cover that in the = meeting minutes. =46rom the action items covered by the meeting minutes I have seen so = far Sergio writing up his concerns regarding end-to-end repair not = working. Neither have we received any write-ups or pull requests from Cullen or = Emil regarding the main concern of to accomplish hob-by-hop repair. We saw a little bit of discussion around Sergio=E2=80=99s PERC lite = proposal on the list. But I=E2=80=99m failing to see how this proposal = fits into the PERC requirements. Once it is clear how this affects all the aspects of PERC we can = certainly arrange for an interim or give it agenda time in Prague. [=E2=80=A6] > Question 2: could we at least commit to have those documents QUICKLY = available (no later than the original proposed meeting frame), and = discuss them on the mailing list? I would really appreciate it if Emil and Cullen could deliver their = write-ups as soon as possible. I have cc=E2=80=99ed both in the hope this serves as a reminder. Best regards Nils Ohlmeier > I would not want someone looking at the archives, and thinking that = the process was slowed down by some always objecting without providing = examples or better alternative, and last minutes decisions to either not = accepting items from the agenda (however intense the corresponding = discussion on the mailing list was) or cancel meetings altogether. While = I'm sure this is not the intend and everybody here is acting in good = faith, I am concerned about how it could be perceived. >=20 > Regards, >=20 > Alex. >=20 >=20 >=20 > On Sat, Jun 3, 2017 at 2:47 PM, Nils Ohlmeier > wrote: > Hello, >=20 > Thank you to the people who shared their availability in the Doodle = poll for a 2nd virtual interim meeting. >=20 > We have seen only a little bit of discussion on the mailing list. > And turn out from the Doodle poll is more sparse then we hoped for. >=20 > Therefor the chairs decided to not have a second virtual interim, but = instead have a hopefully well prepared discussion in Prague. >=20 > Please continue to discuss the options on the mailing list until then. >=20 > Best regards >=20 > The perc WG >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = >=20 >=20 >=20 >=20 > -- > Alex. Gouaillard, PhD, PhD, MBA > = --------------------------------------------------------------------------= ---------- > President - CoSMo Software Consulting, Singapore > = --------------------------------------------------------------------------= ---------- > sg.linkedin.com/agouaillard >=20 --Apple-Mail=_4F59D8DF-487F-4DB8-8C27-1892C6CE09DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Alex,

    On = Jun 3, 2017, at 00:46, Alexandre GOUAILLARD <agouaillard@gmail.com> wrote:

    [=E2=80=A6]

    2. = In the previous meeting it was stated explicitly that people would go = back and write documents for next meeting. It is thus not entirely = unexpected not to have activity on the mailing list, everybody waiting = for the written document to discuss = from.

    During the last interim meeting we = requested discussion to happen on the mailing list. Even though I admit = that I failed to cover that in the meeting minutes.

    =46rom the action items = covered by the meeting minutes I have seen so far Sergio writing up his = concerns regarding end-to-end repair not working.
    Neither have we received any write-ups or pull requests from = Cullen or Emil regarding the main concern of to accomplish hob-by-hop = repair.

    We saw = a little bit of discussion around Sergio=E2=80=99s PERC lite proposal on = the list. But I=E2=80=99m failing to see how this proposal fits into the = PERC requirements.
    Once it is clear how this = affects all the aspects of PERC we can certainly arrange for an interim = or give it agenda time in Prague.

    [=E2=80=A6]

    Question 2: could we at least = commit to have those documents QUICKLY available (no later than the = original proposed meeting frame), and discuss them on the mailing = list?

    I = would really appreciate it if Emil and Cullen could deliver their = write-ups as soon as possible.
    I have cc=E2=80=99ed both in = the hope this serves as a reminder.

    Best regards
      Nils = Ohlmeier

    I would not want = someone looking at the archives, and thinking that the process was = slowed down by some always objecting without providing examples or = better alternative, and last minutes decisions to either not accepting = items from the agenda (however intense the corresponding discussion on = the mailing list was) or cancel meetings altogether. While I'm sure this = is not the intend and everybody here is acting in good faith, I am = concerned about how it could be perceived.

    Regards,

    Alex.



    On Sat, = Jun 3, 2017 at 2:47 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
    Hello,

    Thank you to the people who shared their availability in the Doodle poll = for a 2nd virtual interim meeting.

    We have seen only a little bit of discussion on the mailing list.
    And turn out from the Doodle poll is more sparse then we hoped for.

    Therefor the chairs decided to not have a second virtual interim, but = instead have a hopefully well prepared discussion in Prague.

    Please continue to discuss the options on the mailing list until = then.

    Best regards

    The perc WG

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




    --
    Alex. Gouaillard, = PhD, PhD, MBA
    ---------------------------------------------------------------= ---------------------
    President - CoSMo Software = Consulting, Singapore
    ---------------------------------------------------------------= ---------------------
    sg.linkedin.com/agouaillard


    = --Apple-Mail=_4F59D8DF-487F-4DB8-8C27-1892C6CE09DD-- --Apple-Mail=_31C1F744-08F8-4EF4-8D80-0F9D96B07F9E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZNzq5AAoJEJ3NnGfOORkkm98P/0Ck9Mrm7nrcdHYka9b6zA5k aJ5qP9wP3VfMBGPe9zKzHQvyo2F2DrxMsm2FmMDNlakpFKfSRo+1e8eLXT5oedxn kdTRV2/ldvCb7cZnh/58UBA22LgU3lfum/obYaVWdwS+0eBXeGi+LJg3Io7PMnBo Mad+Uxv689YIaENIDibrt+f6fwZNFkofQlM2IA6jPQusKklIAOzyBqkI3jRInmIs IVvqGfBWF9p75GkEWx3F/ULqgNOd3CZAR/SGvXxDxQaguY1zKwkQuGVOfbzxCzHD AqT6bIgIndrDy57JT5a7a3jC7I3nvf8uUIWD9MowancUgCkr8V6suJ+7LqoeXDbF QknA5I1qGnJVyCSz6hgj+17ssDdcz4ocsUwpzjvQih3AHqZT4uzdbmMjaF5R4gd2 GlQxKUYhB2ZIk/KamZ0WeCzE4a98BLjfhqPPjE3jhvo0SzJ+Pu2AsWb05EhSdk3l 11X8dr5NC/5h00b0RbVlJ4Aaz3hgUc0ev5HV1V5NlSCFBgqUYOhHk4WEqTq7r1ol hoIm9EQQEXN4w9f5o13YfnUJv0BoxPlnfZ0hjBRxIdfxTNLgd8RP0l66sMn8AVAr u+aWRd+BJn7xcKxbCRdochCux4Os0wdIldgdR/1Irmrn4NqOIO1zPVno1pnBTYWn VJ77Pr1Jh+acomGvyUNu =NG6i -----END PGP SIGNATURE----- --Apple-Mail=_31C1F744-08F8-4EF4-8D80-0F9D96B07F9E-- From nobody Tue Jun 6 16:55:49 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9087A126DD9 for ; Tue, 6 Jun 2017 16:55:47 -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 xc5BKAFSBjzg for ; Tue, 6 Jun 2017 16:55:46 -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 E1C0D120721 for ; Tue, 6 Jun 2017 16:55:45 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id q97so60501142wrb.2 for ; Tue, 06 Jun 2017 16:55:45 -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=dMq56psp1H2pU8kIt7VrXi9GqSDTHIX5zWLVpb6kJTw=; b=dF0ZhnOAMWEOhdzS6pJ0ww88oEudfDO8IIlp/U+dpEBsl70m/elXlju+vX5WXLfbTb 5DXNGjXBPXgpVs+eRh0+xt0DHK7h4j77di9aV5D+ykfSx3tSAVkdh9Y6CAq4m11asdWH b0cZtIWIRSPSZeoiMB1DTN8pPzOkViAywe1iIIk5gFOXCq7j9y0eaj/O5LBlRaEqYmtp tDvY9Ktax2EEUTIH4HtkwScDErafqJoZy7+kDsP+4gMEqm92pgkpozpP+bJShoCC8GRB OrSQgeq21B5XyWJ9XwwUhDw5tX24khYgaRcDgrQ9VLGvj84Tn0tgm+v13F9tqOKCqSBE gDPw== 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=dMq56psp1H2pU8kIt7VrXi9GqSDTHIX5zWLVpb6kJTw=; b=L7ZflaTjn3+cL1KJe5ZzYssldzaAljjB+EjUGXhEPyMJVgw/BpY9TVot7EsxBTVcDa 5jvzrj1DzH2Gu6kxrlU65sFPvjb4eSYeFTiMpxpSC/wmx+i5F+ZDX6vn3hbLeYAFgJua q9BGbABo4i+hnuQrE8q13gJxWoPLQ83ljQpPw+OS/OJNTviuBhtFyPqRBn+ipKTkQcmT L1lab2YcRJmTDtmibDnkUcYDrVBOiX5e/4ePHXBVaa2BPs4rb1atTMqre1oiCsEkb2IM 8L8sc5lN/uCRAH1aSaKV2fNrytMP/RoWt4TAeQYyVerb4L62DOjXhDuZ3iU7shCI6Cxc MZ9w== X-Gm-Message-State: AODbwcAoWjaN5D60O9jCiCMg6Z0ickQ1/DoKGk2W4j4cND5fXoFCLehb Np2LIb3vMnrBJv5TPtFm+P+ifWHh4w== X-Received: by 10.223.168.75 with SMTP id l69mr22814386wrc.127.1496793344486; Tue, 06 Jun 2017 16:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.139.20 with HTTP; Tue, 6 Jun 2017 16:55:43 -0700 (PDT) Received: by 10.28.139.20 with HTTP; Tue, 6 Jun 2017 16:55:43 -0700 (PDT) In-Reply-To: References: From: Sergio Garcia Murillo Date: Wed, 7 Jun 2017 01:55:43 +0200 Message-ID: To: Nils Ohlmeier Cc: Alexandre GOUAILLARD , perc@ietf.org, Cullen Jennings , Emil Ivov Content-Type: multipart/alternative; boundary="f403045f4c2e99b2100551535b65" Archived-At: Subject: Re: [Perc] Canceling 2nd virtual interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 23:55:47 -0000 --f403045f4c2e99b2100551535b65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El 7/6/2017 1:29, "Nils Ohlmeier" We saw a little bit of discussion around Sergio=E2=80=99s PERC lite proposa= l on the list. But I=E2=80=99m failing to see how this proposal fits into the PERC requirements. [..] Once it is clear how this affects all the aspects of PERC we can certainly arrange for an interim or give it agenda time in Prague. This of not acceptable. You have not raised your concerns about my proposal on the mailing list and then you reject it because there had been no discussion? You cancel an interim meeting so I can explain further my proposal and at the same time you say it is not clear how it can affect all aspects of PERC and argue if it can even be presented in Prague? Regards Sergio --f403045f4c2e99b2100551535b65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    El 7/6/2017 1:29, "Nils Ohlmeier" <nohlmeier@mozilla.com>

    <= div>We saw a little bit of discussion around Sergio=E2=80=99s PERC lite pro= posal on the list. But I=E2=80=99m failing to see how this proposal fits in= to the PERC requirements.
    <= div dir=3D"auto">
    [..]
    Once it is clear ho= w this affects all the aspects of PERC we can certainly arrange for an inte= rim or give it agenda time in Prague.
    <= /div>


    This of not acceptable.

    You have not raised your concerns about my proposal on the mailing list= and then you reject it because there had been no discussion?=C2=A0

    You cancel an interim meeting s= o I can explain further my proposal and at the same time you say it is not = clear how it can affect all aspects of PERC and argue if it can even be pre= sented in Prague?

    Regard= s
    Sergio



    --f403045f4c2e99b2100551535b65-- From nobody Tue Jun 6 18:25:32 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614A712954E for ; Tue, 6 Jun 2017 18:25:31 -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 249bqFkVO30e for ; Tue, 6 Jun 2017 18:25:29 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804E812953F for ; Tue, 6 Jun 2017 18:25:29 -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=1496798729; x=1498008329; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pvB6ivfrPZPHZmDr/juKCPn5TLZnYigv9tg82O6XB3E=; b=LWumwFVI7lWCQUKdu06r3TRhoUw76+Fypl1HU4wRcCtu9i5a2b4ylx7J 7X7Rp/+KKRn5Nr3Q6qQo/VD7pUZHbbuE4+M/IEzFIQULIRTywxJSSohCg 3BjNsJaZ/4LJ/HNgq6vHTmKvHdCZf9SRYqVZmIHrWVxW1+mK8wmq+/XT1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAABcVTdZ/5BdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1iBbweDbIoYkgaVf4IQhiQCGoJNPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBIxFFBQsCAQgOCgICJgICAjAVEAIEDgWKIwiuE4ImjAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBH4ELhzYrgnWHfDCCMQEEiTyUeAKTMoFuAZAQiSuLNQEfOIEKdBV?= =?us-ascii?q?YAYZzdocNBIEugQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.39,309,1493683200"; d="scan'208";a="252651079" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2017 01:25:28 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v571PSdj024723 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Jun 2017 01:25:28 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 6 Jun 2017 21:25:28 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Tue, 6 Jun 2017 21:25:27 -0400 From: "Cullen Jennings (fluffy)" To: Nils Ohlmeier CC: Alexandre GOUAILLARD , "perc@ietf.org" , Emil Ivov Thread-Topic: [Perc] Canceling 2nd virtual interim Thread-Index: AQHS3xy35mqrYT7yHkC/Eb5I6UdM3aIY3rYA Date: Wed, 7 Jun 2017 01:25:27 +0000 Message-ID: <5C3BA3AA-BBA8-437A-A83B-3947F62D7B16@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Perc] Canceling 2nd virtual interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 01:25:31 -0000 DQo+IE9uIEp1biA2LCAyMDE3LCBhdCA1OjI4IFBNLCBOaWxzIE9obG1laWVyIDxub2hsbWVpZXJA bW96aWxsYS5jb20+IHdyb3RlOg0KPiANCj4gDQo+IEkgd291bGQgcmVhbGx5IGFwcHJlY2lhdGUg aXQgaWYgRW1pbCBhbmQgQ3VsbGVuIGNvdWxkIGRlbGl2ZXIgdGhlaXIgd3JpdGUtdXBzIGFzIHNv b24gYXMgcG9zc2libGUuDQo+IEkgaGF2ZSBjY+KAmWVkIGJvdGggaW4gdGhlIGhvcGUgdGhpcyBz ZXJ2ZXMgYXMgYSByZW1pbmRlci4NCj4gDQo+IEJlc3QgcmVnYXJkcw0KPiAgIE5pbHMgT2hsbWVp ZXINCg0KdGhhbmtzIGZvciByZW1pbmRlciAtIEkgaGF2ZSBiZWVuIHdvcmtpbmcgb24gc3R1ZmYg YnV0IHRoZSBKU0VQIHN0dWZmIGhhcyBwcmlvcml0eSBvdmVyIHRoaXMgcmlnaHQgbm93IHNvIG5v dCBleGFjdGx5IHN1cmUgd2hlbiBJIHdpbGwgaGF2ZSBpdC4gQ3VsbGVuDQoNCg0K From nobody Tue Jun 6 21:13:45 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B19129C01 for ; Tue, 6 Jun 2017 21:13:42 -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 lL0inwAi2L4g for ; Tue, 6 Jun 2017 21:13:40 -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 99793129BF2 for ; Tue, 6 Jun 2017 21:13:40 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id u19so999962qta.3 for ; Tue, 06 Jun 2017 21:13: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=LbnZY5iFxyQMvf9AxdpL5G02IizsbeJ8BbM+4TfK/I0=; b=cAugghawpofh7HXgkxMkummkDESl7fw0i+a/2wVa5yQmpeL9BacSa4TUz3YybrU/C1 Dm9ua47q1297bGhqR4uSZnvAv6wOWGuAgRALAdPjPJ58nSWxH6/avx2Jg5HFFWazcq0/ 9GFqo5veJNqNQvV0U/PpwHtJErCJDxzXxpB+8BZ0WiVwUeE6KisJ/Tv4mpbIBWuBS9Lc EouEU1oDEmNL2VJABo1nzF6H4+3aCIIUYNk3ZSh4qymY6xvbEnzM0gkzhW6t7v4nDzjF p5oH0HF8L1XizeSIvbSquaBGD/MRoPJ3UD+pgrXvRVBDySOeir9OWOwBGycoc65WfZo7 fBBg== 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=LbnZY5iFxyQMvf9AxdpL5G02IizsbeJ8BbM+4TfK/I0=; b=QHQTwFjKHcmVJzNcwW6OQ9W2IaymcqpyQgPgzfa76x7bwRh7BeSS8DCuMECSC4cdLf CwBdloNT0rx6a7C/0dN3GoacIhxuYRJ4of8o7P1qbf2ioaS2EjHwvQPP60MZpmYdhUtO qM7lKmNdOiWoSBTNfTRyA41gLS6y7Tn6gEq/CsDNZPzprSPbKpKU4QOUKO3mPmiMVMg1 GylAktKc6+5Gr9OxwxViW5wmB7qnqh8a3oPRa+XQTe5k2LQ6kQLnoKq/+x0anu+jveMu 1xJqercNEIctzkFkWLBJFrofRQ1g09Fa4DybzvHOXDWqvRWd19xkckpeq1LK1ca6jRFS NDCQ== X-Gm-Message-State: AODbwcC31BbomyPFotZef+iqJhLA3ccVK84SzOAp99FOpVSVyH0gBwae aGXq9Cqf/QupkRZ7z/P1eWUyBogZ6A== X-Received: by 10.200.32.138 with SMTP id 10mr11026587qtd.99.1496808819637; Tue, 06 Jun 2017 21:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.140.8 with HTTP; Tue, 6 Jun 2017 21:13:39 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Tue, 6 Jun 2017 21:13:39 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Nils Ohlmeier , Cullen Jennings , Alexandre GOUAILLARD , Emil Ivov , perc@ietf.org Content-Type: multipart/alternative; boundary="f403045ee626fdc3a5055156f5c2" Archived-At: Subject: Re: [Perc] Canceling 2nd virtual interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 04:13:43 -0000 --f403045ee626fdc3a5055156f5c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Sergio On Tue, Jun 6, 2017 at 4:55 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > > > El 7/6/2017 1:29, "Nils Ohlmeier" > > > We saw a little bit of discussion around Sergio=E2=80=99s PERC lite propo= sal on > the list. But I=E2=80=99m failing to see how this proposal fits into the = PERC > requirements. > > > [..] > > Once it is clear how this affects all the aspects of PERC we can certainl= y > arrange for an interim or give it agenda time in Prague. > > > > This of not acceptable. > > You have not raised your concerns about my proposal on the mailing list > and then you reject it because there had been no discussion? > [Suhas] I don't think it is unfair for chairs to ask the authors of drafts to have a mailing list discussion on how any new proposal affects/impacts/relates to the already accepted WG documents. On a personal level, I feel such a discussion is needed to provide due respect to the hours of productive discussions time (IETF meetings/Design meetings and Interims) that went in to accept the proposals by the WG. >From the chairs perspective, typically one would want to prioritize the progress of accepted WG documents thus ensuring the WG works on the open issues to get them to completion. At the same time, we should be open to proposals for those open issues, to help make such a progress possible and having a mailing list discussion would help in this regard. As requested by Nils, the chairs looks forward to having productive discussions on the concerns raised during the last interim. > You cancel an interim meeting so I can explain further my proposal and at > the same time you say it is not clear how it can affect all aspects of PE= RC > and argue if it can even be presented in Prague? > > Regards > Sergio > > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --f403045ee626fdc3a5055156f5c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello Sergio

    On Tue, Jun 6, 2017 at 4:55 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:


    El 7/6/2017 1:29, "Nils Ohl= meier" <= nohlmeier@mozilla.com>

    We saw a little bit of discussion around Sergio=E2=80=99s PERC lite= proposal on the list. But I=E2=80=99m failing to see how this proposal fit= s into the PERC requirements.

    [..]
    =
    Once it is clear how this affects all the asp= ects of PERC we can certainly arrange for an interim or give it agenda time= in Prague.

    This of not acc= eptable.

    You have not ra= ised your concerns about my proposal on the mailing list and then you rejec= t it because there had been no discussion?=C2=A0


    [Suhas] I don't think it is unfair for= chairs to ask the authors of drafts to have a mailing list discussion on h= ow any new proposal affects/impacts/relates to the already accepted WG docu= ments. On a personal level, I feel such a discussion is needed to provide d= ue respect to the hours of productive discussions time (IETF meetings/Desig= n meetings and Interims) that went in to accept the proposals by the WG.=C2= =A0

    From the chairs perspective, typically one wou= ld want to prioritize the progress of accepted WG documents thus ensuring t= he WG works on the open issues to get them to completion.=C2=A0 At the same= time, we should be open to proposals for those open issues, to help make s= uch a progress possible and having a mailing list discussion would help in = this regard.

    As requested by Nils, the chairs look= s forward to having productive discussions on the concerns raised during th= e last interim.




    You cancel an interim meeting so I can explain further my propos= al and at the same time you say it is not clear how it can affect all aspec= ts of PERC and argue if it can even be presented in Prague?

    Regards
    <= font color=3D"#888888">
    Sergio

    =



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


    --f403045ee626fdc3a5055156f5c2-- From nobody Wed Jun 7 02:09:56 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76DA12EB28 for ; Wed, 7 Jun 2017 02:09:54 -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 3Gvi6676jc1k for ; Wed, 7 Jun 2017 02:09:53 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF607128D8B for ; Wed, 7 Jun 2017 02:09:52 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id x70so53282888wme.0 for ; Wed, 07 Jun 2017 02:09:52 -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=Zi8I2hn2n5u7qi4m9wb6grBwcIzz0TuM0HNduTMclQk=; b=Ew7/pRH8P7Y2eo33uuRtd70w7s/CbO2mCtxVNtkM/tAXq0Pum8QvwusLmDu8HZ5AKZ fCpCpjXqwz6a0nsHPc4b+/R3AahR2lWw0ngjSenHz7ZJRJ/GH9vR0jZE8RzPCnHvfCnY DKjsHX7GUIhXUi1TVDrgVtFPdkXrcXxsOEkdGPRhWWcO7YZpFhGssijHVT0XgeMMRqrD LqjNfRyFfpjV6kBoierS6YPgWxzDA82Zq0pSsPdHqlucSKxi2m1XAfxSznSDE8ipDWSw Sms5ph2wBlGWroGdcDC85J/61CkyOq8ph6Ra1b/EpQ3+iGjRMx/KI7Ktp/DYfEIhUBng stdQ== 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=Zi8I2hn2n5u7qi4m9wb6grBwcIzz0TuM0HNduTMclQk=; b=nL9m8dRsGGwfNEdJEJnWDIl7nDXmDVsRi+YDQCwdxUNSvc1MpfYjGyCMokTM4Q1GW/ 4z8f/T5MuTLyaM+Nq1NwuxtIBmIgEqN3qAZjKfb+5dc0tghnPKgY6OUZAiZQPVJD27Ai xwmjDejqAcIAHNtecZjd0LvM9Cs05lNKOpZVbtmlIHo/LvBW0Lz06wkc6I8Rwo8kI6tf q7wwJK7iZbuOnBp+YrowZA6QfklgbPEL5VXU3slyCkCBocTRfGb1FJ/vrc3eWmkdeLK8 6OYb6W5r9VuU5IWMztY5/LElBCq6qFx14V2ohHSO/zrqB3uV0FuC2UZqeT5uMq/Ijb8z Rb1g== X-Gm-Message-State: AODbwcBPRwA79IzGNEIvJpEODjs+lYORS70r4YeooWRtIK66OEAJ/Ea5 V3o0SNB9WUl8UN5u1sxc/QERjUXcGw== X-Received: by 10.28.23.131 with SMTP id 125mr1358325wmx.42.1496826591334; Wed, 07 Jun 2017 02:09:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.139.20 with HTTP; Wed, 7 Jun 2017 02:09:50 -0700 (PDT) Received: by 10.28.139.20 with HTTP; Wed, 7 Jun 2017 02:09:50 -0700 (PDT) In-Reply-To: References: From: Sergio Garcia Murillo Date: Wed, 7 Jun 2017 11:09:50 +0200 Message-ID: To: Suhas Nandakumar Cc: perc@ietf.org, Emil Ivov , Alexandre GOUAILLARD , Nils Ohlmeier , Cullen Jennings Content-Type: multipart/alternative; boundary="001a114709d444568c05515b194f" Archived-At: Subject: Re: [Perc] Canceling 2nd virtual interim X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 09:09:55 -0000 --001a114709d444568c05515b194f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El 7/6/2017 6:13, "Suhas Nandakumar" escribi=C3=B3: Hello Sergio On Tue, Jun 6, 2017 at 4:55 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > > > El 7/6/2017 1:29, "Nils Ohlmeier" > > > We saw a little bit of discussion around Sergio=E2=80=99s PERC lite propo= sal on > the list. But I=E2=80=99m failing to see how this proposal fits into the = PERC > requirements. > > > [..] > > Once it is clear how this affects all the aspects of PERC we can certainl= y > arrange for an interim or give it agenda time in Prague. > > > > This of not acceptable. > > You have not raised your concerns about my proposal on the mailing list > and then you reject it because there had been no discussion? > [Suhas] I don't think it is unfair for chairs to ask the authors of drafts to have a mailing list discussion on how any new proposal affects/impacts/relates to the already accepted WG documents. No, it is unfair for chairs to block that discussion from taking place and then rejecting the proposal because there has been no discussion. On a personal level, I feel such a discussion is needed to provide due respect to the hours of productive discussions time (IETF meetings/Design meetings and Interims) that went in to accept the proposals by the WG. I feel that this is needed also and I am more than willing to discuss them, and solve any issue that may raise, having sent several emails to the list, written a document with extend proposal and provided slides to try to explain it. If the chairs feel that anything more specific needs to be done, please ask me and I will provide. Regards Sergio --001a114709d444568c05515b194f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    El 7/6/2017 6:13, "Suhas Nandakumar" <suhasietf@gmail.com> escribi=C3=B3:=
    Hello Se= rgio

    On Tue, Jun 6, 2017 at 4:55 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
    =


    El 7/6/2017 1:29, "Ni= ls Ohlmeier" <nohlmeier@mozilla.com>
    =

    We saw a little bit of discussion around Sergio=E2= =80=99s PERC lite proposal on the list. But I=E2=80=99m failing to see how = this proposal fits into the PERC requirements.

    [.= .]
    <= div style=3D"word-wrap:break-word">
    Once it is clear = how this affects all the aspects of PERC we can certainly arrange for an in= terim or give it agenda time in Prague.


    This of not acceptable.

    You have not raised your concerns about my proposal on the mai= ling list and then you reject it because there had been no discussion?=C2= =A0


    [Suhas= ] I don't think it is unfair for chairs to ask the authors of drafts to= have a mailing list discussion on how any new proposal affects/impacts/rel= ates to the already accepted WG documents.


    No, it is unfair for chairs to block that discussion from t= aking place and then rejecting the proposal because there has been no discu= ssion.

    <= div class=3D"gmail_extra">
    On a personal lev= el, I feel such a discussion is needed to provide due respect to the hours = of productive discussions time (IETF meetings/Design meetings and Interims)= that went in to accept the proposals by the WG.=C2=A0

    <= br>
    I feel that this is needed also and I am more th= an willing to discuss them, and solve any issue that may raise, having sent= several emails to the list, written a document with extend proposal and pr= ovided slides to try to explain it.

    If the chairs feel that anything more specific needs to be done= , please ask me and I will provide.=C2=A0

    =
    Regards
    Sergio
    <= div>
    --001a114709d444568c05515b194f-- From nobody Mon Jun 12 13:01:52 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB41C128616 for ; Mon, 12 Jun 2017 13:01:50 -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=ipv-sx.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 m5u7k6hpXEqe for ; Mon, 12 Jun 2017 13:01:48 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 A4384127076 for ; Mon, 12 Jun 2017 13:01:48 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id v111so111472041wrc.3 for ; Mon, 12 Jun 2017 13:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=WtC9sdQk5cZyQ8qA1g3CeA5SHdsmMDTqUK4F5TuTzvs=; b=hUJ5hvgHWsVs0xRHbYGi6YT9VYXZnV8qNFg3h3s5O1NszWLulMQOc7LaCSAnar6HTi zgwRWZdCB5yrIsIRQPu8wVTmNvbnHhL8rtkXetCAWme2zHyqpoz834LGiYZgC2/toZ0O MySiWkicrEB9Gs5hqY4eWo8UY4BImUbdW5YbBccUay8Rwfs0/+T8L+82A1pSeevWrEJm w3tBgd3ADqjYBqrVNp//kaUu8uUPEJI09eUNRBigoipt0sDDF2pVS77lxmpHW9NXKIXl RWzNtJ6QUxDQT2CSaWNS9yatOlSQ0Fukr4ZYLwYQFvHK6XsYtfmzqz0+delFKhkwH1Z2 yYVQ== 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=WtC9sdQk5cZyQ8qA1g3CeA5SHdsmMDTqUK4F5TuTzvs=; b=TZBz0SkNHCRysHRrbGSEbArR8Hr6W2+aZoUdKM2F2QJ41QY8rOXwWTSz8iT1enyGCM UXGw++dX2U+xh7EHbdHbhxn6syqtUkgUvL6ryQrNEC/j/8BNglWaV9SaHtICC6GGx3uu V3/LIw2i7+K1Kd65px3DUDR9GIyxzWekY96870+QV4lapm9kbc0o3e7HDus4uWEew+0B cCEG+3P6zONLFSJd/KpmHAqVDzR2sJJrvrqgIGzgZ8P3TnUy7APn/6kyVtGAXHfqD8Nc fgMEkAQUgxGlakiuOyff/U3hyCdFUo7W6C3LjdF+odbk8vt9xaZ9PoXjOZCjOAwcEoHi sx4w== X-Gm-Message-State: AKS2vOzVuqUdjDUGbbhFWcsMi9VecacIcsBtfxiak1kXyVPKnWkyd2v0 WQp9F4KwiZVmDAUkuNCNQCUIiDrVArfX1ivP3w== X-Received: by 10.28.26.135 with SMTP id a129mr378910wma.11.1497297706242; Mon, 12 Jun 2017 13:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Mon, 12 Jun 2017 13:01:45 -0700 (PDT) From: Richard Barnes Date: Mon, 12 Jun 2017 16:01:45 -0400 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="001a114cd8cce7acfa0551c8c942" Archived-At: Subject: [Perc] Being explicit about E2E extensions X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:01:51 -0000 --001a114cd8cce7acfa0551c8c942 Content-Type: text/plain; charset="UTF-8" Hey all, I've just posted a PR for -double that proposes that rather than relying on the position of the OHB in the extensions block to signal which extensions are E2E and which aren't , we have an explicit "E2E Extensions Length" extension that says how long the E2E extensions are. https://github.com/ietf/perc-wg/pull/117 Being explicit in this way is necessary if we're going to allow -double to be implemented internally to SRTP libraries. Those libraries typically don't know which extensions have which IDs (they've never had a reason to), so if the OHB is in an unpredictable place, then the SRTP library can't find it. Instead, we need to put the OHB in a predictable place -- as the first extension if there are no E2E extensions, or after the E2E (with a signaled length) if there are. ----- As an aside, the way I came across this issue was that I was implementing -double in libsrtp: https://github.com/cisco/libsrtp/pull/311 The interesting stuff is all in the AAD handling, which is where you run into the difference between inner and outer, locating the OHB, etc.: https://github.com/cisco/libsrtp/pull/311/files#diff-da888ab5c58ee201661c2dcca58a0022R404 That code hasn't landed in libsrtp yet (since the spec isn't stable yet), but this should provide a good foundation for proving out ideas in -double. It also provides a nice way to get PERC deployed in browsers quickly. Since both Chrome and Firefox depend on libsrtp, once we have -double in libsrtp, the browsers only things the browser need to do are (1) update libsrtp, and (2) advertise support for -double and OHB. Cheers, --Richard --001a114cd8cce7acfa0551c8c942 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey all,

    I've just poste= d a PR for -double that proposes that rather than relying on the position o= f the OHB in the extensions block to signal which extensions are E2E and wh= ich aren't , we have an explicit "E2E Extensions Length" exte= nsion that says how long the E2E extensions are.

    <= a href=3D"https://github.com/ietf/perc-wg/pull/117">https://github.com/ietf= /perc-wg/pull/117

    Being explicit in this w= ay is necessary if we're going to allow -double to be implemented inter= nally to SRTP libraries.=C2=A0 Those libraries typically don't know whi= ch extensions have which IDs (they've never had a reason to), so if the= OHB is in an unpredictable place, then the SRTP library can't find it.= =C2=A0 Instead, we need to put the OHB in a predictable place -- as the fir= st extension if there are no E2E extensions, or after the E2E (with a signa= led length) if there are.

    -----

    =
    As an aside, the way I came across this issue was that I was imp= lementing -double in libsrtp:


    The interesting stuff is all in the AAD handl= ing, which is where you run into the difference between inner and outer, lo= cating the OHB, etc.:


    That code hasn't landed = in libsrtp yet (since the spec isn't stable yet), but this should provi= de a good foundation for proving out ideas in -double.

    =
    It also provides a nice way to get PERC deployed in browsers quickly.= =C2=A0 Since both Chrome and Firefox depend on libsrtp, once we have -doubl= e in libsrtp, the browsers only things the browser need to do are (1) updat= e libsrtp, and (2) advertise support for -double and OHB.

    Cheers,
    --Richard
    --001a114cd8cce7acfa0551c8c942-- From nobody Thu Jun 22 03:31:01 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D0B129353 for ; Thu, 22 Jun 2017 03:31:00 -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 Xblm0SHAtg_x for ; Thu, 22 Jun 2017 03:30:58 -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 55EF81292C5 for ; Thu, 22 Jun 2017 03:30:58 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p21so8347044qke.3 for ; Thu, 22 Jun 2017 03:30:58 -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=L9f6lgS3uvOA8uA+CdYNpeZWQE76dKfh6kesKEmuIw0=; b=f/Gi7Wm3D7mDLTKd9U7wrduZcCj+VWLJtXDiIXH74tEhbNjaBnz6OcBNOQnebx/phm vDSPPqy+RNTZqvBYJJdnr9MR12bzSQNYO9uFs7JinXPYdDdyC/9KnImqJBa+GcTCpSfU x8grxxrfMVjAWnkAa+fkMgGJOlfuhi+V5lO1titU3FSVC12aVs5KQ7vI+eyuZ/605GBW qtEUI0HLatj2SrbbHIO5TLjsD8AY8Ms2Dsd03DsUHjpwI87dzcKBNSbDtU/hS+RO+Qqa VBGRBZ4iF20DjcE4nsAMz7HlRueroHC8p7Ke7ZqfYjAP2w7tgzfrAuM1CMGepa2eUetF G0oA== 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=L9f6lgS3uvOA8uA+CdYNpeZWQE76dKfh6kesKEmuIw0=; b=f+rPVfy6zvEzI1UxfbQTduJkOzOa6gPOG4rk2o7gT2fJqo7u+oO97NX4OnoFTSxTp9 BUNoxEpAHlkQmTchoPvkR/NXcII2j10iJK4N4zkblYlpu8ROmASG6zdLacbmUOahEJ/E XXv5QGNNk2t31qvgeDqPdb/4BECCPHAQTewazvlkPXNbzvRyH1lx8SfWjvL0EsOV+zmS k0wOgoHUxFwSmyRM6XkUQu9EfGu735FKZWig7KfaHNoItXLMr0YyyPjHq9tri+9wTW/C nCo4CgNmZSbnm4vahaxQkDrzvtyJr9SFWeI5GAbcb/ByFhNaMALJlvc4GGsbhBf4rcsQ Ckkw== X-Gm-Message-State: AKS2vOw8KJFEimUUQ4OKBWmju0x8KKgkp09TXzyV3QAMtACedC+T6xq6 hzb9Hfyx8iyVEv7yPxkAuoj6B19AZLuR X-Received: by 10.55.68.20 with SMTP id r20mr1940925qka.31.1498127457355; Thu, 22 Jun 2017 03:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.146.123 with HTTP; Thu, 22 Jun 2017 03:30:56 -0700 (PDT) From: Suhas Nandakumar Date: Thu, 22 Jun 2017 03:30:56 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="001a11489786ec8c08055289fa95" Archived-At: Subject: [Perc] IETF 99 Agenda Time X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 10:31:00 -0000 --001a11489786ec8c08055289fa95 Content-Type: text/plain; charset="UTF-8" Hi Everyone, IETF99 in Prague is almost here and the PERC WG has been allotted a 2.5 hour slot on the July 18th (Tuesday) at 9:30 AM. Draft submissions and WG agendas are both due in less than 2 weeks, so the chairs would like to collect agenda requests for items to be discussed at the meeting. Please submit your draft/updates before the 3rd of July to give reviewers sufficient time to prepare. In order to ensure productive meeting time, we would request the presenters to come prepared to discuss open issues that have been already raised on the mailing list and received some feedback. Please include the following details in your agenda request: - draft author and the presenter - time requested - open issue(s) that requires addressing Thanks Suhas/Nils --001a11489786ec8c08055289fa95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Everyone,

    IETF99 in Prague is almost here and the PERC = WG has been allotted a 2.5 hour slot on =C2=A0the July 18th (Tuesday) at 9:= 30 AM.=C2=A0

    Draft submissions an= d WG agendas are both due in less than 2 weeks, so the chairs would like to= collect agenda requests for items to be discussed at the=C2=A0meeting.=C2=A0

    Please submit your draft/updates before the 3rd of =C2=A0Ju= ly to give reviewers sufficient time to prepare.

    In order to= ensure productive meeting time, we would request the presenters to come pr= epared to discuss open issues that have been already raised on the mailing = list and received some feedback.=C2=A0

    Please include the following details in your agenda request:

    =C2=A0 - draft author and the presenter

    =C2=A0 - time req= uested

    =C2=A0 - open issue(s) that requires addressing

    =C2= =A0

    Thanks

    Suhas/Nils

    --001a11489786ec8c08055289fa95-- From nobody Fri Jun 23 17:17:38 2017 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D5612EBA7; Fri, 23 Jun 2017 17:07:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ben@nostrum.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283902.7840.2494643364899896107.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:19 -0700 Archived-At: Subject: [Perc] perc - Requested session has been scheduled for IETF 99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:21 -0000 Dear Suhas Nandakumar, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. perc Session 1 (2:30:00) Tuesday, Morning Session I 0930-1200 Room Name: Berlin/Brussels size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Privacy Enhanced RTP Conferencing Area Name: Applications and Real-Time Area Session Requester: Suhas Nandakumar Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: quic sipbrandy rtcweb tls avtcore avtext clue netvc acme dispatch mmusic Second Priority: ice saag modern uta xrblock payload stir sipcore oauth tcpinc Third Priority: kitten insipid codec People who must be present: Ben Campbell Richard Barnes Suhas Nandakumar Nils Ohlmeier Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 29 12:21:49 2017 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1921250B8; Thu, 29 Jun 2017 12:21:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149876410310.27892.8135117136563707149@ietfa.amsl.com> Date: Thu, 29 Jun 2017 12:21:43 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-double-05.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:21:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : SRTP Double Encryption Procedures Authors : Cullen Jennings Paul E. Jones Adam Roach Filename : draft-ietf-perc-double-05.txt Pages : 15 Date : 2017-06-29 Abstract: In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines SRTP procedures that use two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-double-05 https://datatracker.ietf.org/doc/html/draft-ietf-perc-double-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-05 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 Jun 29 12:31:11 2017 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C033129B55; Thu, 29 Jun 2017 12:31:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149876466334.27888.18079917871669758066@ietfa.amsl.com> Date: Thu, 29 Jun 2017 12:31:03 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-05.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:31:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : Encrypted Key Transport for DTLS and Secure RTP Authors : Cullen Jennings John Mattsson David A. McGrew Dan Wing Filename : draft-ietf-perc-srtp-ekt-diet-05.txt Pages : 23 Date : 2017-06-29 Abstract: Encrypted Key Transport (EKT) is an extension to DTLS and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-05 https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-05 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 Jun 29 12:47:03 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0328C129562 for ; Thu, 29 Jun 2017 12:47:02 -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 y9s9esJwlXsY for ; Thu, 29 Jun 2017 12:47:00 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A54129B35 for ; Thu, 29 Jun 2017 12:46:59 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i127so25566165wma.0 for ; Thu, 29 Jun 2017 12:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=RZCfpHZQRtR9d3UyuYZUDGB/18th7SyybfgRj4II75k=; b=NARoqvLLADpl6ekfkZmSCDoNsEjleaz/tv3QPFEGw/fWvBBDCnlzru0enPTdOCzB27 OY/8vIl+wQ/825c84c6VUzw5jUlQXxw0qiDuC+Z01QWFl8ZtbNSqd6sIU+O78iqN1dpI LUbvR/w3oBvWCjFbHXyH4UWByWpGNYhCZgDJ5i9NMxCh5U9Qi7trl5UmAUkEjyvXShHd qKmUTIp7SQJ9PTYFxrw4NxooiRlqEwM8QdlB+oKu3GVl/IYWlKSERrfLL5oP0w8237zu hBsnCdV0ZLXQVqTiQ/A7/pclxP0Nz/OR1cBikwJ/Bs+S+G9DiNCrS7mRtV20+qmwik9W UlUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=RZCfpHZQRtR9d3UyuYZUDGB/18th7SyybfgRj4II75k=; b=MSm8oGEziwAEEshyQKLUZZgf1G+oUFjA95oz1Xopj1hqpVfpnex8vHq6fhslUwHBcx NgmpD35mCmL5cmrKkGji8X5/Nbe0Q8QMDyMtmuAoCuYJ2iHdLI/yMoydcQrGCkByP1YV 1GozvUp70vTbe4YAHdLSBiMlpyBQS46l8+0VmTBSmzKKVnhGiJ5JVq3u9O7QILlBRp+k oaDVpx5CnIA8GePJ70VGDD+DnvHs5Am6gSi/aRyyoP473uDx5+yW6VveDk94JVVj5AuO Hog/AXNbx9+kW0LRfD+QdCiBFp0uNIvtdx1FFcwfr6iwGRIqv2fmXpdGONOrrv5UQDdi k9QQ== X-Gm-Message-State: AKS2vOyRWWrYevuwmDSrNlTIKyBDwWqzRTqdO1vNvPeMcVlDvvBq0CRN qqByUXtBVVKccrn/YOs= X-Received: by 10.28.148.67 with SMTP id w64mr11651971wmd.55.1498765618247; Thu, 29 Jun 2017 12:46:58 -0700 (PDT) Received: from [192.168.0.199] ([47.62.8.218]) by smtp.googlemail.com with ESMTPSA id 137sm9691625wmm.29.2017.06.29.12.46.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 12:46:57 -0700 (PDT) To: "perc@ietf.org" From: Sergio Garcia Murillo Message-ID: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> Date: Thu, 29 Jun 2017 21:46:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------D84E631E0E1F1F9C66403BAD" Content-Language: en-US Archived-At: Subject: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 19:47:02 -0000 This is a multi-part message in MIME format. --------------D84E631E0E1F1F9C66403BAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, In the new double encryption draft that Cullen has just submitted, it is says: 7.3. FEC The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work with no additional considerations. But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for redundant audio data. The problem is that RED only protects the payload, and any RTP header extension will not be protected. That will prevent RED to work HBH as the receiver end will not be able to recover the OHB and perform the inner crypto on the recovered packet. Best regards Sergop --------------D84E631E0E1F1F9C66403BAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    Hi all,

    In the new double encryption draft that Cullen has just submitted, it is says:

    7.3.  FEC

   The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work
   with no additional considerations.

    But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for redundant audio data. The problem is that RED only protects the payload, and any RTP header extension will not be protected. That will prevent RED to work HBH as the receiver end will not be able to recover the OHB and perform the inner crypto on the recovered packet.

    Best regards

    Sergop


    --------------D84E631E0E1F1F9C66403BAD-- From nobody Thu Jun 29 13:11:55 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7B129B25 for ; Thu, 29 Jun 2017 13:11:54 -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 oKLglQBTFjlc for ; Thu, 29 Jun 2017 13:11:52 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 EBFF6126DED for ; Thu, 29 Jun 2017 13:11:51 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id r126so56373983vkg.0 for ; Thu, 29 Jun 2017 13:11: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 :cc; bh=ZWT7Po+EdB07PqPY9NyIo/JnhDDHQfnTEeUdgERMF2g=; b=tyJ+AP03fiDvDu3dlld29bgfcRiQIO+SubDvlAvekHurZs0XMGxyv/PvtSwAHbb/fd YW+MF5gn9tSjgKW8sAcRStadSG3QXg9OkqCphHBToKfrVjywqg4qsA4eQ6ta90c3shn8 pT8eOEZ6JgrKcZQ/PiDBDxTfte7H5dqsGqKA+cLuORPbTCKqPQjMNdj+QOmS8koG9hvT HeM/Td2YI03nkvx1uieOnoJxZPjqipIoFZqEypQuWflCC3tpXphCU9o4t9UYSUb2hIjp nbvGiCa6THU+zDXPln+OhMen6L7Yubcfkjnyujvkjto9WgjQ+Azasgi4ytPzEnGDU42e v5JA== 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=ZWT7Po+EdB07PqPY9NyIo/JnhDDHQfnTEeUdgERMF2g=; b=HKyS9We7ckNxoQOK4LRoarkjNszjusgOz1cGTp6WjHewPvOrIxToH7aro7W0Nfkte9 Z73KK2c1mBN7QYZCnkeWnenQn60zQt2a0tkshvdwVtdZQ2rUoE2bSmXe4vWXJm+ZabQo KWHX26o8jAQLwGLGFv6tcDEOxg7i7jNZFf5FsIdMm7QBXk7Ng4h4kBpAFKhQwNWLtZH8 Au86LokA4gxVmB0EOqSOOs1m6iIHfHSeCm0gpmmhMWL0YvHc/9yO+VT+euL1YVOtPJDy 4wB/0bbZnY7c0eeZ7ic2lr+8xsPtDxtR8TEqzvup8DD5XiomuddfKbSdfeOZWXuTYyzc 4AHg== X-Gm-Message-State: AKS2vOwqAsBONp5sqGGBL56zkJnf+e5TQTbocBXMMFDg7CoWoa0VZzqb Vn87TFKJGD/dNfBqeXs6tS+oADCSYA== X-Received: by 10.31.218.196 with SMTP id r187mr9400802vkg.96.1498767110856; Thu, 29 Jun 2017 13:11:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.6.199 with HTTP; Thu, 29 Jun 2017 13:11:50 -0700 (PDT) In-Reply-To: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> From: Alexandre GOUAILLARD Date: Thu, 29 Jun 2017 13:11:50 -0700 Message-ID: To: Sergio murillo Cc: "perc@ietf.org" , "Cullen Jennings (fluffy)" , Adam Roach Content-Type: multipart/alternative; boundary="94eb2c07c5623e67c805531ee952" Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 20:11:54 -0000 --94eb2c07c5623e67c805531ee952 Content-Type: text/plain; charset="UTF-8" Dear all, The new double document is great and propose a lot of improvements. Thanks for its author for the hard work (*). I like the fact that a new section for RTX, DMTF, and other RTCP mechanisms has been added to reflect the recent discussion on the mailing list. The relaxing of the end- to end constraints and OHB usage to include and accommodate cases where end-to-end RTP header extensions are not needed is a welcome improvement. I am not sure that I want one big key with two half, each being used as a separate key. Maybe we could propose this as one way to do it, to accommodate the other drafts on key management and retrieval, but not mandatory to implement perc-compliant double encryption not to restrict people who would want to use double with their own key management and retrieval. I do not feel too strongly about this, and could live with the current text as is. As the document states, the proposed solution does not propose a solution for supporting RTX, and has Sergio pointed out, would not support RED (for the same reasons it does not support RTX) and in turn, FEC. We believe that it would be unlikely for an SFU to provide the same quality of service without those mechanisms. We believe we also have a potential solution to this problem with only a small twist around how to, and to what, apply the end-to-end encryption. Instead of going ahead and rewriting the document Sergio provided before on the mailing list as a separate draft, we would prefer to speak with the authors of the double draft and see if the solution we propose for the inner encryption would be acceptable since it would allow support of RTX/FEC/RED at, we believe, no cost and no tradeoff compared to the current solution. Cullen, Adam, P. Jones, would you be open to a quick chat this week? I am on Pacific time right now, and Sergio is CET. If us 5 could reach consensus here, and present a common document, from my point of view, that would remove any remaining discussion point for the WG. Best regards, Dr Alex. (*) Some typos left e.g.: " 5.2. Relaying a Packet The Media Distributor does not have a notion of outer or inner The Media Distributor *does has* *"* On Thu, Jun 29, 2017 at 12:46 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi all, > > In the new double encryption draft that Cullen has just submitted, it is > says: > > 7.3. FEC > > The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work > with no additional considerations. > > But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for > redundant audio data. The problem is that RED only protects the payload, > and any RTP header extension will not be protected. That will prevent RED > to work HBH as the receiver end will not be able to recover the OHB and > perform the inner crypto on the recovered packet. > > Best regards > > Sergop > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ President - CoSMo Software Consulting, Singapore ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --94eb2c07c5623e67c805531ee952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear all,

    The new double document is gr= eat and propose a lot of improvements. Thanks for its author for the hard w= ork (*).

    I like the fact that a new section for RT= X, DMTF, and other RTCP mechanisms has been added to reflect the recent dis= cussion on the mailing list. The relaxing of the end- to end constraints an= d OHB usage to include and accommodate cases where end-to-end RTP header ex= tensions are not needed is a welcome improvement.

    = I am not sure that I want one big key with two half, each being used as a s= eparate key. Maybe we could propose this as one way to do it, to accommodat= e the other drafts on key management and retrieval, but not mandatory to im= plement perc-compliant double encryption not to restrict people who would w= ant to use double with their own key management and retrieval. I do not fee= l too strongly about this, and could live with the current text as is.

    As the document states, the proposed solution does not= propose a solution for supporting RTX, and has Sergio pointed out, would n= ot support RED (for the same reasons it does not support RTX) and in turn, = FEC. We believe that it would be unlikely for an SFU to provide the same qu= ality of service without those mechanisms. We believe we also have a potent= ial solution to this problem with only a small twist around how to, and to = what, apply the end-to-end encryption.

    Instead of = going ahead and rewriting the document Sergio provided before on the mailin= g list as a separate draft, we would prefer to speak with the authors of th= e double draft and see if the solution we propose for the inner encryption = would be acceptable since it would allow support of RTX/FEC/RED at, we beli= eve, no cost and no tradeoff compared to the current solution.
    Cullen, Adam, P. Jones, would you be open to a quick chat this= week? I am on Pacific time right now, and Sergio is CET.

    If us 5 could reach consensus here, and present a common document, = from my point of view, that would remove any remaining discussion point for= the WG.

    Best regards,

    Dr= Alex.

    (*) Some typos left e.g.:

    "
    5.2. Relaying a Packet
    The Media Distribut= or does not have a notion of outer or inner The Media Distributor=C2=A0does has
    "

    On Thu, Jun 29, 2017 at 12:46 PM, Sergio Garcia Muri= llo <sergio.garcia.murillo@gmail.com> wrote:
    =20 =20 =20

    Hi all,

    In the new double encryption draft that Cullen has just submitted, it is says:

    7.3.  FEC

   The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work
   with no additional considerations.

    But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for redundant audio data. The problem is that RED only protects the payload, and any RTP header extension will not be protected. That will prevent RED to work HBH as the receiver end will not be able to recover the OHB and perform the inner crypto on the recovered packet.

    Best regards

    Sergop



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




    --
    =
    Alex. Gouaillard, P= hD, PhD, MBA
    ----------------------------------------------------------= --------------------------
    President - CoSMo Software Consulting,= Singapore
    ------------------------------------------------------= ------------------------------

    • --94eb2c07c5623e67c805531ee952-- From nobody Thu Jun 29 15:01:05 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B25129B1A for ; Thu, 29 Jun 2017 15:01:03 -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 PfpuO2mU4CAV for ; Thu, 29 Jun 2017 15:01:02 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0327212700F for ; Thu, 29 Jun 2017 15:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=492; q=dns/txt; s=iport; t=1498773662; x=1499983262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0opVqdfGX+79i9AXlObEawWYVNXHgfy9lqm7XbwqZPQ=; b=C3fV+r4WvnlLkyMAo2A0Ph2C+T9dbmSPXGd63uaFdzNXEMwNko5Kbime lBwha8g7EoilIw7AXATuuWswlejpT4ijV8msD6JlsryTLrUpIGTgtmPk5 LQPuD/V6vxUhsGYSgXb7zg4uwGFDGdGl6JUdxEF8YoX+gqJtXCo450aCn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AABAeFVZ/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1mBcQeNfpFIIogqjVGCEYYcAoMQPxgBAgEBAQEBAQFrKIUYAQEBAQI?= =?us-ascii?q?BOj8FCwIBCBgeECERJQIEDgWKFwMNCLRYhzENhAABAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEggyeFLSsLgm6CV4ITg0OCMQEEnjs7Ao8LhGeBcpAli2uJPgEfOIEKdBVbAYc?= =?us-ascii?q?AdogbgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,283,1496102400"; d="scan'208";a="447778335" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2017 22:00:51 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v5TM0pvH011638 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Jun 2017 22:00:51 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Jun 2017 18:00:50 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Thu, 29 Jun 2017 18:00:50 -0400 From: "Cullen Jennings (fluffy)" To: Alexandre GOUAILLARD CC: Sergio murillo , "perc@ietf.org" , Adam Roach Thread-Topic: [Perc] Double PERC draft 5 and webrtc audio FEC Thread-Index: AQHS8RPzJAT7jb1zt0m5gTIR2XyS56I8pzwA Date: Thu, 29 Jun 2017 22:00:50 +0000 Message-ID: <8747F617-81BB-4A65-9165-C90D46C9388E@cisco.com> References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.228.210] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:01:03 -0000 > On Jun 29, 2017, at 2:11 PM, Alexandre GOUAILLARD = wrote: >=20 > Cullen, Adam, P. Jones, would you be open to a quick chat this week? I am= on Pacific time right now, and Sergio is CET. Totally agree that a call would be the best way to make some progress. Unfo= rtunately I am traveling all next week and it is booked pretty solid but If= we could pick a time on July 10, 11, or 12, I think I could make just abou= t any time work on those days.=20 From nobody Thu Jun 29 15:13:18 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D677129B1A for ; Thu, 29 Jun 2017 15:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_HK_NAME_FM_DR=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=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 ILWB5lcLCFAH for ; Thu, 29 Jun 2017 15:13:15 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 0C6F3129AA3 for ; Thu, 29 Jun 2017 15:13:15 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id e199so14655109pfh.0 for ; Thu, 29 Jun 2017 15:13:15 -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=y5gTMRKQPsVroew7tr1mb7++81LzTQqrB/rN7ql4eX8=; b=mVU1qegW4lLJWsPJBuT71N/y7oUxbV4FIiXE6Uc7+yxa1nv9DuDC0gmrqnxWRDHld9 VnpA96pUP1ylPwWYULTdtIWeQqxikramr1ldrSEpOj9+L0n6uzs+34n0tSvOWlZcBMaN yATwzfnphU5TwFiG5kdVTr2+EzqeHFHlW+VSqUpF8ftBAAaNtgRXp3CM0dBYWWV9Smdz WOhhEDXSWapkC8Mt6Y35YPOVLXzJROWy6BTfdpUER2K8hXoPsBx3DUXDIa3kMzdN+9E9 yIYCs+ZIqwQ2XfFdaeFyP1uNsQ4kk3OBqmm1ZsXMTch83AdRBk4OJmSyIvLClUzKHRw7 HyiA== 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=y5gTMRKQPsVroew7tr1mb7++81LzTQqrB/rN7ql4eX8=; b=azHn4Q5g7AJ38O+BH4zKGH6i3WlcVSe+IIW41ACORPdM8asNMcApQN043ORW+yqqzK ANe6FA73K+GBx5uurQTM8RLaQOKJdhSLjQ7fTygtav/L3c8Gsqpegdxt+KIFMPXTcBIg l7MAEAgzOvyzQfbCes6C6KWaEDUhM3kPnKiZCQko4213jVypoxxDR3W3xZ2UACH9WcoA xCApsSpH8a90rlWcLeHr6sagolkDAsLuCEK19Y/+oP/82MS/2773qURmvPyqv1fa5jJ1 l1B9vI2wGJ0cl5Ba/O1hGd7tbT3+nVuhYmxI0hvPcRoEgN38DmTf3lcaRVgZr3qZdZXB O2sg== X-Gm-Message-State: AKS2vOwk7r4UzqiMpMRcGBB+62jI0mpcsrOQZ3kl1NplbrSr02kMoqzQ Tztl9kN78/12+w== X-Received: by 10.99.123.74 with SMTP id k10mr17786815pgn.226.1498774394700; Thu, 29 Jun 2017 15:13:14 -0700 (PDT) Received: from [10.126.67.209] ([183.90.37.67]) by smtp.gmail.com with ESMTPSA id u17sm15854610pfa.133.2017.06.29.15.13.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 29 Jun 2017 15:13:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dr Alex Gouaillard X-Mailer: iPhone Mail (12B440) In-Reply-To: <8747F617-81BB-4A65-9165-C90D46C9388E@cisco.com> Date: Thu, 29 Jun 2017 15:13:08 -0700 Cc: Sergio murillo , "perc@ietf.org" , Adam Roach Content-Transfer-Encoding: quoted-printable Message-Id: References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> <8747F617-81BB-4A65-9165-C90D46C9388E@cisco.com> To: "Cullen Jennings (fluffy)" Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:13:16 -0000 I m flying back to Singapore on 10, but will find a slot to make it happen. Calendar invite to come soon. Sent from my iPhone > On 29 Jun 2017, at 3:00 pm, Cullen Jennings (fluffy) wr= ote: >=20 >=20 >> On Jun 29, 2017, at 2:11 PM, Alexandre GOUAILLARD = wrote: >>=20 >> Cullen, Adam, P. Jones, would you be open to a quick chat this week? I am= on Pacific time right now, and Sergio is CET. >=20 > Totally agree that a call would be the best way to make some progress. Unf= ortunately I am traveling all next week and it is booked pretty solid but If= we could pick a time on July 10, 11, or 12, I think I could make just about= any time work on those days.=20 >=20 >=20 From nobody Thu Jun 29 15:43:55 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0618312EAF2 for ; Thu, 29 Jun 2017 15:43:53 -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_H4=-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 jcOXUd-hxzOU for ; Thu, 29 Jun 2017 15:43:51 -0700 (PDT) Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) (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 10121129B31 for ; Thu, 29 Jun 2017 15:43:50 -0700 (PDT) Received: from smtp7.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5DBE9A03D7; Thu, 29 Jun 2017 18:43:45 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 17976A03C4; Thu, 29 Jun 2017 18:43:45 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 29 Jun 2017 18:43:45 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> Date: Thu, 29 Jun 2017 16:43:44 -0600 Cc: "perc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4C7F07F1-E4C9-474C-97E5-1CB5D9B9A9AB@iii.ca> References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> To: Sergio Garcia Murillo X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:43:53 -0000 > On Jun 29, 2017, at 1:46 PM, Sergio Garcia Murillo = wrote: >=20 > Hi all, >=20 > In the new double encryption draft that Cullen has just submitted, it = is says: >=20 > 7.3. FEC >=20 > The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work > with no additional considerations. >=20 > But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for = redundant audio data. The problem is that RED only protects the payload, = and any RTP header extension will not be protected. That will prevent = RED to work HBH as the receiver end will not be able to recover the OHB = and perform the inner crypto on the recovered packet. > Best regards >=20 Let me just ignore for a second that we disagree on best way to do RED = when using SRTP (never mind PERC). My read of draft-ietf-rtcweb-fec was = that 2198 is a "MAY" be used but that the "RECOMMENDED" approach for = opus in hybrid mode (which is preferred for WebRTC) was just to use the = FEC that is build into Opus. All the data I have seen suggests that = opus FEC outperforms RED in pretty much all ways RED typically gets used = so this seems somewhat reasonable.=20 But that said, if you think the draft should mention RED, glad to add = it. Plus the sentence in the draft probably needs to explain what works = means in this context.=20 > Sergop >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Thu Jun 29 15:57:58 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9412EB01 for ; Thu, 29 Jun 2017 15:57:56 -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 5QuDbifPjFSa for ; Thu, 29 Jun 2017 15:57:54 -0700 (PDT) Received: from smtp77.ord1c.emailsrvr.com (smtp77.ord1c.emailsrvr.com [108.166.43.77]) (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 A428B128C81 for ; Thu, 29 Jun 2017 15:57:54 -0700 (PDT) Received: from smtp2.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 1FCA4C03C0; Thu, 29 Jun 2017 18:57:54 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E3412C02F5; Thu, 29 Jun 2017 18:57:53 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 29 Jun 2017 18:57:54 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 29 Jun 2017 16:57:53 -0600 Message-Id: <3922728F-99FA-4560-A169-9B2BF212A1EC@iii.ca> To: perc@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Perc] FEC Proposal X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 22:57:56 -0000 Here is a straw man of proposal for dealing with Flex FEC that I'd like = to discuss in Prague.=20 The algorithm recommend in [@I-D.ietf-rtcweb-fec] for repair of video is Flex FEC [@I-D.ietf-payload-flexible-fec-scheme]. The repair packets for Flex FEC MUST be handled like RTCP packets instead of RTP packets in that only the hop-by-hop cryptographic algorithms are applied when using the double transform and not the end-to-end algorithms. When using Flex FEC, the negotiation of double for the crypto is the out of band signaling that indicates that the repair packets MUST use the order of operations of SRTP followed by FEC when encrypting. This is to ensure that the original media is not reveled to the Media Distributor but at the same time allow the Media Distributor to repair media. The PR is at https://github.com/ietf/perc-wg/pull/120 There are some details I don't like about that approach but at a broad = brush, it is one way we could solve this.=20 From nobody Thu Jun 29 16:45:32 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D2212EAFA for ; Thu, 29 Jun 2017 16:45: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 CGrJCJLQjJg6 for ; Thu, 29 Jun 2017 16:45:28 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 B3F8D126BF7 for ; Thu, 29 Jun 2017 16:45:28 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id z22so66493401uah.1 for ; Thu, 29 Jun 2017 16:45:28 -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=amzWvZWHZqLRi7Xi+zopew4IHOh5w4se01WDLooWsTM=; b=VrnmnD+ZfdGXfpWSDJAZloxL2soR5WRGxNGNHZ6HDobOC2UoXVJvooz8h18mNfhwDC AhMnVJNizeu+p5AQevFkB8Yp16hqKC0qjcbwKclyiL7gwbZ0JuFcpPkXF1rsnmg+2A0A PuK1xWwtEMY3nAN77EzdwouGGB8zLqtFgH8azWNLmklIzTq0fUckIBRXJ2AOKHO3aZUs YBKTfHul2fvAAcK/q/bHJxMHHzWIgZE+ZasjfeQ21xBIOUuRDitc5xrKnmnPJtnAUK29 eiYWxWcOyXdB2X87Prdnh5Yfo1hy1PBG0c7PeEk7e3ebx0dyqbJRJric65jPzYZXASUJ oOfw== 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=amzWvZWHZqLRi7Xi+zopew4IHOh5w4se01WDLooWsTM=; b=WUfRyxQ+Ta3OIav+Aq3X4WfQFi0VhU0ZQ/tsz0AO4I9nYw6YJHrtxjZmmN8ppUaSJI YO3FLCfMSIttLLuak6APwhqb8bXWtOVRb0+5r6D7W77Aj6SymclOQG85EN3dIucG5Ml8 tMV9fzM4iBozSiJApMbMLE26wMgTtXvP8aDozkHPLzIvtSA4YX1vyiOCewBCXbI+SoV1 +1x0CFTFNgsGbJZv79G95AQQ/+0aFYbQnWCnn35+dL3rUTd4XPX5Yc79he8eswCfDFp/ lQUYcAEzKrRscOvAsCx2ep+U4JlifOjpimjibR0oB25AuTCy6LUYuhMQCBwQ1vnYfJIj 89zA== X-Gm-Message-State: AKS2vOx1yX0QzzXEmV89WkGihKYztHI+E1zyRNVqaLZlFioKKH9+R4wd jDRl/06V4LsSFfjxzwUQ6tUTLgteog== X-Received: by 10.176.18.200 with SMTP id o8mr11354983uac.132.1498779927696; Thu, 29 Jun 2017 16:45:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.202 with HTTP; Thu, 29 Jun 2017 16:45:07 -0700 (PDT) In-Reply-To: <4C7F07F1-E4C9-474C-97E5-1CB5D9B9A9AB@iii.ca> References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> <4C7F07F1-E4C9-474C-97E5-1CB5D9B9A9AB@iii.ca> From: Bernard Aboba Date: Thu, 29 Jun 2017 16:45:07 -0700 Message-ID: To: Cullen Jennings Cc: Sergio Garcia Murillo , "perc@ietf.org" Content-Type: multipart/alternative; boundary="f403043612ba2fdb90055321e59a" Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 23:45:31 -0000 --f403043612ba2fdb90055321e59a Content-Type: text/plain; charset="UTF-8" Cullen said: "Let me just ignore for a second that we disagree on best way to do RED when using SRTP (never mind PERC). My read of draft-ietf-rtcweb-fec was that 2198 is a "MAY" be used but that the "RECOMMENDED" approach for opus in hybrid mode (which is preferred for WebRTC) was just to use the FEC that is build into Opus. All the data I have seen suggests that opus FEC outperforms RED in pretty much all ways RED typically gets used so this seems somewhat reasonable." [BA] Opus FEC can't handle burst loss, but RED can. So if you have burst loss (quite likely on wireless networks), RED can substantially outperform Opus FEC. I realize this would involve use of RED in an *atypical* way, though. Also, it's important to compare Opus FEC against concealment. When that is done, its benefits do not stand out. On Thu, Jun 29, 2017 at 3:43 PM, Cullen Jennings wrote: > > > On Jun 29, 2017, at 1:46 PM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > > > Hi all, > > > > In the new double encryption draft that Cullen has just submitted, it is > says: > > > > 7.3. FEC > > > > The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work > > with no additional considerations. > > > > But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for > redundant audio data. The problem is that RED only protects the payload, > and any RTP header extension will not be protected. That will prevent RED > to work HBH as the receiver end will not be able to recover the OHB and > perform the inner crypto on the recovered packet. > > Best regards > > > > Let me just ignore for a second that we disagree on best way to do RED > when using SRTP (never mind PERC). My read of draft-ietf-rtcweb-fec was > that 2198 is a "MAY" be used but that the "RECOMMENDED" approach for opus > in hybrid mode (which is preferred for WebRTC) was just to use the FEC that > is build into Opus. All the data I have seen suggests that opus FEC > outperforms RED in pretty much all ways RED typically gets used so this > seems somewhat reasonable. > > But that said, if you think the draft should mention RED, glad to add it. > Plus the sentence in the draft probably needs to explain what works means > in this context. > > > > Sergop > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --f403043612ba2fdb90055321e59a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Cullen said:=C2=A0

    "Let me just ignore for a second that we disagree on best= way to do RED when using SRTP (never mind PERC).=C2=A0 My read of draft-ie= tf-rtcweb-fec was that 2198 is a "MAY" be used but that the "= ;RECOMMENDED" approach for opus in hybrid mode (which is preferred for= WebRTC) was just to use the FEC that is build into Opus.=C2=A0 All the dat= a I have seen suggests that opus FEC outperforms RED in pretty much all way= s RED typically gets used so this seems somewhat reasonable."

    [BA] =C2=A0Opus FEC can't handle burst loss, bu= t RED can.=C2=A0 So if you have burst loss (quite likely on wireless networ= ks), RED can substantially outperform Opus FEC.=C2=A0 I realize this would = involve use of RED in an *atypical* way, though.

    A= lso, it's important to compare Opus FEC against concealment.=C2=A0 When= that is done, its benefits do not stand out.

    On Thu, Jun 29, 2017 at 3:43 PM, Cu= llen Jennings <fluffy@iii.ca> wrote:

    > On Jun 29, 2017, at 1:46 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
    >
    > Hi all,
    >
    > In the new double encryption draft that Cullen has just submitted, it = is says:
    >
    > 7.3.=C2=A0 FEC
    >
    >=C2=A0 =C2=A0 The algorithms recommended in [I-D.ietf-rtcweb-fec] for a= udio work
    >=C2=A0 =C2=A0 with no additional considerations.
    >
    > But in ietf-rtcweb-fec it recommends to use rfc 2198 RTP payload for r= edundant audio data. The problem is that RED only protects the payload, and= any RTP header extension will not be protected. That will prevent RED to w= ork HBH as the receiver end will not be able to recover the OHB and perform= the inner crypto on the recovered packet.
    > Best regards
    >

    Let me just ignore for a second that we disagree on best way to do R= ED when using SRTP (never mind PERC).=C2=A0 My read of draft-ietf-rtcweb-fe= c was that 2198 is a "MAY" be used but that the "RECOMMENDED= " approach for opus in hybrid mode (which is preferred for WebRTC) was= just to use the FEC that is build into Opus.=C2=A0 All the data I have see= n suggests that opus FEC outperforms RED in pretty much all ways RED typica= lly gets used so this seems somewhat reasonable.

    But that said, if you think the draft should mention RED, glad to add it. P= lus the sentence in the draft probably needs to explain what works means in= this context.


    > Sergop
    >
    > _______________________________________________
    > Perc mailing list
    >     Perc@ietf.org
    > https://www.ietf.org/mailman/listinfo/perc
    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc

    --f403043612ba2fdb90055321e59a-- From nobody Thu Jun 29 17:03:09 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939D0124C27 for ; Thu, 29 Jun 2017 17:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 yI7n4yxY5K7R for ; Thu, 29 Jun 2017 17:03:05 -0700 (PDT) Received: from smtp125.ord1d.emailsrvr.com (smtp125.ord1d.emailsrvr.com [184.106.54.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 5ED9A1200F3 for ; Thu, 29 Jun 2017 17:03:05 -0700 (PDT) Received: from smtp8.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp8.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id AC902C0066; Thu, 29 Jun 2017 20:03:04 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp8.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5F40DC0076; Thu, 29 Jun 2017 20:03:04 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Thu, 29 Jun 2017 20:03:04 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 29 Jun 2017 18:03:03 -0600 Cc: Sergio Garcia Murillo , "perc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> <4C7F07F1-E4C9-474C-97E5-1CB5D9B9A9AB@iii.ca> To: Bernard Aboba X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 00:03:08 -0000 > On Jun 29, 2017, at 5:45 PM, Bernard Aboba = wrote: >=20 > [BA] Opus FEC can't handle burst loss, but RED can. So if you have = burst loss (quite likely on wireless networks), RED can substantially = outperform Opus FEC. I realize this would involve use of RED in an = *atypical* way, though. I realize some people want to use RED so I'm not arguing that we don't = need to worry about it. It seems with RED for burst loss you have to = decide how long a delay you want on the RED packets - more delay gives = better burst loss protection but worse latency. When you implement FEC = in opus, you have to decide more or less the same thing of how much = delay to put in the redundant coding. So I see them somewhat similar to = burst loss. But not sure it matters much because I'm fine with trying to = have a solution that works for RED.=20= From nobody Fri Jun 30 01:17:45 2017 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028A5120725 for ; Fri, 30 Jun 2017 01:17:44 -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 1O8op8Ew2I7J for ; Fri, 30 Jun 2017 01:17:42 -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 D4DD7124BE8 for ; Fri, 30 Jun 2017 01:17:41 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id c11so200474132wrc.3 for ; Fri, 30 Jun 2017 01:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=meAnEDlqzingKsyJVeMoDU1+zgF3I39p6qZvM2THCZA=; b=EaxtMHcQnusKaQYuNME38VNzCN09OwlHdOZ5+gFAseN5JukDeZ1RIzSnYz2XRcNm8l IdIyXEdI+M1fyfhqXTnfU+Tr8KP71fUm8Vjh1rjh7ShAicxCssWgD0qs7fQ2dOIV6gyr rt5VxEO4S02h2Rccx66/NugbRKySSwJ/3p1OzpnB0woWu+wZ63LEQoCbUg4q5ZLjj9C6 PqRH1ii3vyuIzh/micGjwv2chksgcAwAxDQkaqwT4ZlrzhjuKbBH7nyF+H4LoZ5Y3kib lAs3K+iLI8chSk458gCWn6cNIeGYECMraa//Xx4iU/qSCJ9qc5ztMlJS9hZUVjHjZCU9 4MXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=meAnEDlqzingKsyJVeMoDU1+zgF3I39p6qZvM2THCZA=; b=LsuU+TyDnr23gkXV7Xq+A20JuKrY2emj4bMnQp2wsgtJ/BJayUC/KbeAFZhlXOztCu Lh3dFI73psaM/HM77EnHLxUenndN23Ud1AoxQBmxWK3UnhPOTMDOMHzpn6bPJcmhtwlV UUh4Cg0V1KdzzTK8dBPyXq8hXGy/Nd2hb8ypUBpunI11QI7Zx+a3aLOJrhIZ0Bm1yWMc TAeyJmaJCI35S6mI6qQd4rdOv9LS6o7bxv5+z2vyA3K2nTOmx44UyqLPgA/PTVwZ52X1 orqT9S+Em6PbFFGbujqHXNTTyZP3bgF4ZNHoQoKdpBu0Oqcw5kqBxXhLP4z1ixrfT0Xd kTLg== X-Gm-Message-State: AKS2vOyc3OlkAlTIhdPG4MBhlkq6aZtrLYXTzVJDDsQmkYpF2KCg9ULI AThRUAESAGkRUG7QtKw= X-Received: by 10.223.146.195 with SMTP id 61mr11787791wrn.134.1498810660230; Fri, 30 Jun 2017 01:17:40 -0700 (PDT) Received: from [192.168.1.43] (84.red-83-36-143.dynamicip.rima-tde.net. [83.36.143.84]) by smtp.googlemail.com with ESMTPSA id v96sm5835168wrc.53.2017.06.30.01.17.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 01:17:39 -0700 (PDT) To: Cullen Jennings , Bernard Aboba Cc: "perc@ietf.org" References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> <4C7F07F1-E4C9-474C-97E5-1CB5D9B9A9AB@iii.ca> From: Sergio Garcia Murillo Message-ID: <669b3819-83de-f27e-9214-73c2ac808f0e@gmail.com> Date: Fri, 30 Jun 2017 10:17:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9D57C205702A2A7F20C819EB" Content-Language: en-US Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 08:17:44 -0000 This is a multi-part message in MIME format. --------------9D57C205702A2A7F20C819EB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 30/06/2017 2:03, Cullen Jennings wrote: > >> On Jun 29, 2017, at 5:45 PM, Bernard Aboba wrote: >> >> [BA] Opus FEC can't handle burst loss, but RED can. So if you have burst loss (quite likely on wireless networks), RED can substantially outperform Opus FEC. I realize this would involve use of RED in an *atypical* way, though. > I realize some people want to use RED so I'm not arguing that we don't need to worry about it. It seems with RED for burst loss you have to decide how long a delay you want on the RED packets - more delay gives better burst loss protection but worse latency. When you implement FEC in opus, you have to decide more or less the same thing of how much delay to put in the redundant coding. So I see them somewhat similar to burst loss. But not sure it matters much because I'm fine with trying to have a solution that works for RED. Hi Cullen, Bernard, I am not against or in favor on RED. My point was just that in the new draft when it addresses the FEC part, it says: The algorithms recommended in [I-D.ietf-rtcweb-fec ] for audio work with no additional considerations. which is incorrect as RED cannot be supported HBH for the reasons mentioned on my original mail, and the draft should be updated to reflect that fact. Deciding if RED is a good FEC mechanism for webrtc or not, while being a very interesting topic, I think it is outside of the scope of this group. Best regards Sergio --------------9D57C205702A2A7F20C819EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
    On 30/06/2017 2:03, Cullen Jennings wrote:

    On Jun 29, 2017, at 5:45 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

[BA]  Opus FEC can't handle burst loss, but RED can.  So if you have burst loss (quite likely on wireless networks), RED can substantially outperform Opus FEC.  I realize this would involve use of RED in an *atypical* way, though.

    I realize some people want to use RED so I'm not arguing that we don't need to worry about it. It seems with RED for burst loss you have to decide how long a delay you want on the RED packets - more delay gives better burst loss protection but worse latency. When you implement FEC in opus, you have to decide more or less the same thing of how much delay to put in the redundant coding. So I see them somewhat similar to burst loss. But not sure it matters much because I'm fine with trying to have a solution that works for RED.

    Hi Cullen, Bernard,

    I am not against or in favor on RED. My point was just that in the new draft when it addresses the FEC part, it says: 

       The algorithms recommended in [I-D.ietf-rtcweb-fec] for audio work with no additional considerations.

    which is incorrect as RED cannot be supported HBH for the reasons mentioned on my original mail, and the draft should be updated to reflect that fact.

    Deciding if RED is a good FEC mechanism for webrtc or not, while being a very interesting topic, I think it is outside of the scope of this group.

    Best regards

    Sergio

    --------------9D57C205702A2A7F20C819EB--