From nobody Tue Jul 2 20:05:11 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5FF120044; Tue, 2 Jul 2019 20:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <156212310899.23895.5820771631529661067@ietfa.amsl.com> Date: Tue, 02 Jul 2019 20:05:09 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 03:05:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC IP Address Handling Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-ip-handling-12.txt Pages : 12 Date : 2019-07-02 Abstract: This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-12 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 3 00:23:44 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0901201CC for ; Wed, 3 Jul 2019 00:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_NONE=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 KaUgg6D0Ot7L for ; Wed, 3 Jul 2019 00:23:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA2EB1201D9 for ; Wed, 3 Jul 2019 00:23:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D400E7C36F5 for ; Wed, 3 Jul 2019 09:23:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsznwJ4Q82AL for ; Wed, 3 Jul 2019 09:23:35 +0200 (CEST) Received: from [192.168.3.218] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id D8FF27C360A for ; Wed, 3 Jul 2019 09:23:34 +0200 (CEST) To: "rtcweb@ietf.org" From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= mQINBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABtC9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPokCPgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryG5Ag0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAGJAiUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Wed, 3 Jul 2019 09:23:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Archived-At: Subject: [rtcweb] Request for status update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 07:23:43 -0000 WG chairs - can you give the WG a status update on the WG's documents? As far as I can tell from https://www.rfc-editor.org/cluster_info.php?cid=3DC238 the critical piece= s not in the RFC Editor queue are still the security documents and FEC, but -4566bis, -clue-protocol, -rmcat-eval-criteria and -ice-sip-sdp are also listed. What is the status of these documents? Are there others? At the moment, the responsibility of the chairs is (in my opinion) to make sure publication happens. It's been a while. Harald --=20 Surveillance is pervasive. Go Dark. From nobody Wed Jul 3 16:13:33 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA811200D7 for ; Wed, 3 Jul 2019 16:13:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 xcQsIjmpr7Pt for ; Wed, 3 Jul 2019 16:13:29 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 0036D120096 for ; Wed, 3 Jul 2019 16:13:28 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id r21so3950177qke.2 for ; Wed, 03 Jul 2019 16:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Y/70pNn0j11/ksVtfFZ+koceRqfU2Z8WF36DN/SRRHA=; b=gNlcPQnqNKCsVrgYJzyBlyiLVX9KLKZNjC1/c4Ga/RuT6zUUCseurEd+AZd1MxVov5 ZOk1YSrknrI5mRLY440HcLt3EXjbNdGMZVllepzNFavse8KJldgwxHm1mphs8589srqm Doi/vqEu0OjHVoLC7J5kDyB8XJu/1HkTctOQU= 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=Y/70pNn0j11/ksVtfFZ+koceRqfU2Z8WF36DN/SRRHA=; b=VqPnRHyG5KryacByP4epGljqB/MVQnvyG47Znotlnx5+1YVIxGsG3ousLXdjd2LBpy CYN9dG61Nw7XKtbpBgF923TroAN+2JwRsYX5Ssn1ncTjqrRIJIxIDGRVPdFLTUQ+1ljT WwIvPab783kWdodZ8orxLmHW5FXkwGEobEWK/fof8chiGQ9PMRcUfIss8NbU4fn3sw+m eLdJ+ITAighByfyFn1mHSWvsuMeb1OEK10JrcFmsoY4CZpOoZdr+FrKq5FL8/DXn4fT5 02AiTtp1BULpwivXWTYjX/DbraPf91HF3+HbJXbhYmEjvZsOqSb2HzHZQ+BsWWKf6cRt rHlw== X-Gm-Message-State: APjAAAVKBzZFPgPbq4voGqI7gQh7wdAIu7pXVU5ENUq86Dm1rW854dNA l5FKIB4AdKeBXCqlfFWXNAfNk/y0WSM= X-Google-Smtp-Source: APXvYqz6OzMkzacRQRXKwVlfVIB+MZIg26xgvLhMmcefu8li0qZSE2ZOmZi0bU7MmvCbVqizz8LCGQ== X-Received: by 2002:a37:bd7:: with SMTP id 206mr4264116qkl.440.1562195608121; Wed, 03 Jul 2019 16:13:28 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id u18sm1542061qkj.98.2019.07.03.16.13.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 16:13:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Wed, 3 Jul 2019 19:13:26 -0400 Cc: "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [rtcweb] Request for status update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 23:13:32 -0000 A fair question Harald. Here=E2=80=99s the status of the WGs as of = today: draft-ietf-rtcweb-ip-handling: New version spun yesterday. Awaiting = Adam=E2=80=99s concurrence on one change, then he will get state moved = to approved. draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch: Held a = conference call with Ben, Ted, ekr, and myself to address Ben=E2=80=99s = discusses and comments. ekr filed new issues and needs to generate some = PRs. Once a new version is spun, Ben, Adam, and I will review and = hopefully we=E2=80=99re done with these two drafts. draft-ietf-rtcweb-fec: I am getting emails now from GitHub showing = Justin is diligently working through the outstanding comments. I hope a = revised draft will hit tonight or no later than Monday=E2=80=99s = submission deadline. draft-ietf-rtcweb-mdns-ice-candidates: It is my understanding that Adam = is going to AD sponsor this one, but not until the other four move on. spt > On Jul 3, 2019, at 03:23, Harald Alvestrand = wrote: >=20 > WG chairs - can you give the WG a status update on the WG's documents? >=20 > As far as I can tell from > https://www.rfc-editor.org/cluster_info.php?cid=3DC238 the critical = pieces > not in the RFC Editor queue are still the security documents and FEC, > but -4566bis, -clue-protocol, -rmcat-eval-criteria and -ice-sip-sdp = are > also listed. >=20 > What is the status of these documents? >=20 > Are there others? >=20 > At the moment, the responsibility of the chairs is (in my opinion) to > make sure publication happens. It's been a while. >=20 > Harald >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jul 3 16:25:59 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20334120173 for ; Wed, 3 Jul 2019 16:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-iSl15wHfHv for ; Wed, 3 Jul 2019 16:25:56 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 2F2F91200EC for ; Wed, 3 Jul 2019 16:25:56 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id j2so1996556pfe.6 for ; Wed, 03 Jul 2019 16:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3xrTJgqHjZzft0J8pKgKqJKM62wP9UObC7rcPWQ50K4=; b=kMmGtl4X+sqoU1cSYQKCrw3wtR7QQucdcE4ukia37K6xAs8v6XbWo0VRWp934RmRFb Ucak049Vf5Wz8lebT5YoCE4XAC7Nn4HM0q7AA+lUTMzDYWW/v0xcT2CPtSYZFq+8HImZ 4bMt19aFXxIYmqQRQygDKONSc0NUqVT90jvOob86VX2xwgbz5DR1ZaSLNkrC0B1QjS0G qgivpNJfmC72rbY9mCxWGK0nCkac+qf1Nwr5obip1Ibmw1NQBu5Qjsc33Mnub1VQD7nG 99ajSOnaidJeAx6s3Ee+d3RB7Ze0XRC3/DLdRoCSdQqJnlZmOwQsyjUbuR5q3WWIaYkm CfBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3xrTJgqHjZzft0J8pKgKqJKM62wP9UObC7rcPWQ50K4=; b=NQOmHTFeOdC3jw+YhqxLxdporZzxzUTD28ph3PUZvvQtTa+Fa03fkGanI16+5tl33p +PH+NwuwolXxLTJvNGF/0tq8BS0QY/xj9UVdh5gAfh/ncJX47EuGmqhbbVVuEUVbSp0C SNZ5IsemggwLsBTkidi8ypxrET7qoV2vBKvEUFrtkZ0DD2T3ANQqqBJwmib43bSze9cC hVx783JjzEVBq2asTkxwdVc3tNOU4yEAqfc28JTdeEpns7mAmTcJg9qMuHSOM+UU4p0E waQNra1wb4+MuNl7OlTyT3ZGGbLh7Daqf3bCLK0EUinkNuY8XKcKhWIMZdP451PMMVSw 62Qw== X-Gm-Message-State: APjAAAX3WeYN0Ym8UOE3wBTC4ZYZxgR9/K1pNYuKMBgv9Yg5XLbQg9XQ F5XaaiHfGx0qkmOlmwEqE1HuBgZF X-Google-Smtp-Source: APXvYqyY44KvGBLP+X3vQK8T7udUWLSw2uOfJ4qnv7PDh52QTE1dOJMXvNm93bSSD2/SJnPRO429oA== X-Received: by 2002:a17:90a:9905:: with SMTP id b5mr16042630pjp.70.1562196355249; Wed, 03 Jul 2019 16:25:55 -0700 (PDT) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id b3sm5738994pfp.65.2019.07.03.16.25.54 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 16:25:54 -0700 (PDT) Received: by mail-pl1-f181.google.com with SMTP id w24so2036498plp.2 for ; Wed, 03 Jul 2019 16:25:54 -0700 (PDT) X-Received: by 2002:a17:902:bd0a:: with SMTP id p10mr45646008pls.134.1562196353859; Wed, 03 Jul 2019 16:25:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Wed, 3 Jul 2019 19:25:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bdc7a4058ccf2e15" Archived-At: Subject: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 23:25:58 -0000 --000000000000bdc7a4058ccf2e15 Content-Type: text/plain; charset="UTF-8" Hi All, Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also, there are significant interop implications for this draft between browser and non-browser end points which probably warrant larger discussion outside of rtcweb group. I would think mmusic would be a much better place for this draft. I know there is an incentive to complete this draft quickly but this has a potential to break a lot of things (it already did break interop with almost every existing ICE implementation). Regards, _____________ Roman Shpount --000000000000bdc7a4058ccf2e15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

<= div dir=3D"ltr">Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-ca= ndidates? This entire draft seems to be ICE/SDP specific and not limited to= rtcweb. Also, there are significant interop implications for this draft be= tween=C2=A0browser and non-browser end points which probably warrant larger= discussion outside of rtcweb group. I would think mmusic would be a much b= etter place for this draft. I know there is an incentive to complete this d= raft quickly but this has a potential to break a lot of things (it already = did break interop with almost every existing ICE implementation).

Regards,
_= ____________
Roman Shpount
--000000000000bdc7a4058ccf2e15-- From nobody Wed Jul 3 16:55:27 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A313A120096; Wed, 3 Jul 2019 16:55:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <156219812456.12668.3348558240451025966@ietfa.amsl.com> Date: Wed, 03 Jul 2019 16:55:24 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 23:55:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-09.txt Pages : 13 Date : 2019-07-03 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-09 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 3 17:28:46 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9B01200D7 for ; Wed, 3 Jul 2019 17:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqn967YXKu0k for ; Wed, 3 Jul 2019 17:28:41 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 B5BFF12007C for ; Wed, 3 Jul 2019 17:28:41 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id m23so940658vso.1 for ; Wed, 03 Jul 2019 17:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mEYbBio/y/jgTb9nJeY0a8NvQBHHAvMKgOY2I5Bgb2M=; b=E/julHYBoUAPjpSRAp0sqXiSXs/sz33u8R5wgAWaskeOPDSCKM/Tp/DaQLdo3Ozws9 deUO9QLpOYFBs3Zuu2NlCEExbaJdwJnl2Hv7SqODQsg1Rly2/Mn76WLKqRstV49STITA EvQT9KWaGcD771MBq6ZsLJKX4lAaCIct0Mye92UNYI+G+MoD0tzbTi+7tNrTQCRxMq4s 6CD3rEiHHg5n4og0pZ0clG0Z0VnTiX6+1GLhjAUM+gHATSSl/Nv/HuaMEZf+YevaIM9N a9lCsgGTQqhFWR98MKFfI7MqeXQlBmvSInp9kR+ksH+gYNr+BRqSTCCwxQ7ajHrEZPbu Z7gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mEYbBio/y/jgTb9nJeY0a8NvQBHHAvMKgOY2I5Bgb2M=; b=egHzsLd4GLuz4p7x5nzuQa+prO02VqBWGe5kdRLOrT4+ErYr59CGf8M64yPFqWkHM3 1+6+RytoMu3Pbtb4U7Qvw2sRfTlwXFbEZIPy0F2etXG8poRGQH9oV1d+Ko5IuDNiMqe/ tYeEjef9/lAQO4eDnotx0fYgUcgMFFLnT7s8psLybvos+eOKCcfoyjCowYORhGGxZ8+f zCivQOavJZZAPV9BlYUwdWC7vH1Wu4UqnltgHlF5FLWkBQN0YdFBRqMPylUQp4j4EfRN 0mfqywnq1BK7xHKCyVQSMc7xACQuKXzUrFhCsThE/fe43RZ3VYARz4tQzuHk7Vk6VRxT e2Sg== X-Gm-Message-State: APjAAAXsra+GgPdxF7PLXg1if3F1Vq2tcGHkWBP62H4hdo4U+PSY69e8 dmhENicXVP05qmAiaF3xS/l6U+Y/3Udx9yBbkptPJIgW2bE= X-Google-Smtp-Source: APXvYqwngLW0/g9LMDI7iXhh3EuElrKcAEnaO3oUHxyJfOZdCpOwgHUSbqBU/DSJlgqvGCf1OXftomp287mlF3S/BFs= X-Received: by 2002:a67:eb19:: with SMTP id a25mr19470590vso.109.1562200120172; Wed, 03 Jul 2019 17:28:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 3 Jul 2019 17:28:28 -0700 Message-ID: To: Roman Shpount Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003be503058cd00f98" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 00:28:44 -0000 --0000000000003be503058cd00f98 Content-Type: text/plain; charset="UTF-8" The problem this draft is trying to solve is fairly RTCWEB-specific. If there are individual issues to resolve, we can send them out to mmusic for discussion, but AFAIK no changes to existing ICE specs are needed. On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: > Hi All, > > Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This > entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also, > there are significant interop implications for this draft between browser > and non-browser end points which probably warrant larger discussion outside > of rtcweb group. I would think mmusic would be a much better place for this > draft. I know there is an incentive to complete this draft quickly but this > has a potential to break a lot of things (it already did break interop with > almost every existing ICE implementation). > > Regards, > _____________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000003be503058cd00f98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The problem this draft is trying to solve is fairly RTCWEB= -specific. If there are individual issues to resolve, we can send them out = to mmusic=C2=A0for discussion, but AFAIK no changes to existing ICE specs a= re needed.

On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
Hi = All,

Is rtcweb the right p= lace for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to = be ICE/SDP specific and not limited to rtcweb. Also, there are significant = interop implications for this draft between=C2=A0browser and non-browser en= d points which probably warrant larger discussion outside of rtcweb group. = I would think mmusic would be a much better place for this draft. I know th= ere is an incentive to complete this draft quickly but this has a potential= to break a lot of things (it already did break interop with almost every e= xisting ICE implementation).

Regards,
_____________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000003be503058cd00f98-- From nobody Wed Jul 3 17:40:23 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A46812067A for ; Wed, 3 Jul 2019 17:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKeYeoVa08wm for ; Wed, 3 Jul 2019 17:40:14 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 161A9120629 for ; Wed, 3 Jul 2019 17:40:14 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id u14so880753pfn.2 for ; Wed, 03 Jul 2019 17:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z5BKqdR0B68cDQrtYGc/sv00hpjs7HEsSHb5/QMzNTQ=; b=g773ugBuODJy1NC2TRGvA5+FdSmYB9Fm3540u+TuU1t4KyCJEzSuLfv2HohXnVHSjG Znd2p5l+ZK7RTzZt7Xf2mnX8e7Yu4e9icfT5+6Oo8ZiNXH2uTNYYc05ZuvV5GKkG0ixy zdH+Xijm9vsnNVqIehT749nEuO1iX72ldO9g/lxoGYgj0Cqlef2bYLVxkiTVQ2erMWco UvCZ2Zzo/HBpT4rMs3iBXWr+2MaZ7/7vX/ftH2XdCiAfPnS94IDDaiM5LXNYNOEUZPfW zd+SdTlXsrAmkaHOWAq18fdvjHg4Xy7rBMkIWRXQ5FOtw0RuNOh9P7Hy3gyIFxU8O42v YVJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z5BKqdR0B68cDQrtYGc/sv00hpjs7HEsSHb5/QMzNTQ=; b=BlIw/HQonlSdDlB9OY2YqZHcx0FP/2pLxS3a5mYYrOyb1QwVr/RRTaHx1kZZaGM1WF fEX/ke3DrBAQgNJpZKd2gH0jbDjumOQujIccK239aEXiSTFbYHMtjLRrDuVE2WtOnvd2 DeCEfp1jxBdtBpyTUc3cbgt8Nhukr5WM3OWFB493wUReBtSUUVBRFQL/OXpqZwl5fAOn E4xL/ta/Ke1BGb2L6uFVudflE3pYqQ/2EflZw4OIir+DHMkfGRR+jAbQJ9sl/7zQDaDN I/fk+tbVwn+5F+IVySq87YLgWAQR+igIYLFDhA5y1RutRKN6e2RlfXDFeHnppAa0R9iH ji0w== X-Gm-Message-State: APjAAAUosN5K3rN+oyJ7ytUJNb7x49LzF/ucSfpuucgjFXTpNbyAzfIJ y803+ZlEjq+73lDwggCiJO23DLhvZG4= X-Google-Smtp-Source: APXvYqxejRBQacdxlgYA98rEC2zJ2n3fGWSanqLhCCKVDpyofgcJn+xZU/iao2xFVLfMWPRhJjASnQ== X-Received: by 2002:a17:90a:1c1:: with SMTP id 1mr16116029pjd.72.1562200813168; Wed, 03 Jul 2019 17:40:13 -0700 (PDT) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com. [209.85.210.175]) by smtp.gmail.com with ESMTPSA id m101sm2907133pjb.7.2019.07.03.17.40.11 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 17:40:12 -0700 (PDT) Received: by mail-pf1-f175.google.com with SMTP id x15so2084333pfq.0 for ; Wed, 03 Jul 2019 17:40:11 -0700 (PDT) X-Received: by 2002:a63:7c0e:: with SMTP id x14mr39543007pgc.65.1562200811289; Wed, 03 Jul 2019 17:40:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Wed, 3 Jul 2019 20:40:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006cc218058cd03863" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 00:40:22 -0000 --0000000000006cc218058cd03863 Content-Type: text/plain; charset="UTF-8" Part of the problem is that mmusic have decided to punt on the FQDN support. In the current mmusic-ice-sip-sdp the final language that was included: : is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. *An agent generating local candidates MUST NOT use FQDN addresses. An agent processing remote candidates MUST ignore candidate lines that include candidates with FQDN *or IP address versions that are not supported or recognized. *The procedures for generation and handling of FQDN candidates, as well as, how agents indicate support for such procedures, need to be specified in an extension specification.* So, at this point we have two options: 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define how FQDN candidates generated by mdns are handled 2. write a new draft in mmusic which defines FQDN handling In any case some sort of mmusic discussion is needed to reconcile this. Best Regards, _____________ Roman Shpount On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote: > The problem this draft is trying to solve is fairly RTCWEB-specific. If > there are individual issues to resolve, we can send them out to mmusic for > discussion, but AFAIK no changes to existing ICE specs are needed. > > On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: > >> Hi All, >> >> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This >> entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also, >> there are significant interop implications for this draft between browser >> and non-browser end points which probably warrant larger discussion outside >> of rtcweb group. I would think mmusic would be a much better place for this >> draft. I know there is an incentive to complete this draft quickly but this >> has a potential to break a lot of things (it already did break interop with >> almost every existing ICE implementation). >> >> Regards, >> _____________ >> Roman Shpount >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --0000000000006cc218058cd03863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Part of the problem is that mmusic have d= ecided to punt on the FQDN support. In the current mmusic-ice-sip-sdp the f= inal language that was included:

<connection-address>: =C2=A0is taken from RFC 4566 [RFC4566]= .=C2=A0 It is the IP address of the candidate, allowing for IPv4 addresses,= IPv6 addresses, and fully qualified domain names (FQDNs).=C2=A0 When parsi= ng=C2=A0this field, an agent can differentiate an IPv4 address and an IPv6= =C2=A0address by presence of a colon in its value - the presence of a=C2=A0= colon indicates IPv6. =C2=A0An agent generating local candidates MUST=C2= =A0NOT use FQDN addresses.=C2=A0 An agent processing remote candidates=C2= =A0MUST ignore candidate lines that include candidates with FQDN or=C2= =A0IP address versions that are not supported or recognized. =C2=A0The= =C2=A0procedures for generation and handling of FQDN candidates, as well=C2= =A0as, how agents indicate support for such procedures, need to be=C2=A0spe= cified in an extension specification.

So, at this point we have two options:=C2=A0
1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp= and define how FQDN candidates generated by mdns are handled
2. = write a new draft in mmusic which defines FQDN handling

In any case some sort of mmusic discussion is needed to reconcile thi= s.

Best Regards,
___= __________
Roman Shpount


On Wed, Jul 3, 2019 at 8:28 PM J= ustin Uberti <juberti@google.com> wrote:
The problem this draft is trying to solve is fairly RTCWEB-s= pecific. If there are individual issues to resolve, we can send them out to= mmusic=C2=A0for discussion, but AFAIK no changes to existing ICE specs are= needed.

On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
Hi All,

Is rt= cweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire= draft seems to be ICE/SDP specific and not limited to rtcweb. Also, there = are significant interop implications for this draft between=C2=A0browser an= d non-browser end points which probably warrant larger discussion outside o= f rtcweb group. I would think mmusic would be a much better place for this = draft. I know there is an incentive to complete this draft quickly but this= has a potential to break a lot of things (it already did break interop wit= h almost every existing ICE implementation).

Regards,
__= ___________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000006cc218058cd03863-- From nobody Wed Jul 3 17:58:54 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A11D1206A4 for ; Wed, 3 Jul 2019 17:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNuBC4Z6ygvh for ; Wed, 3 Jul 2019 17:58:42 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 35A4F120629 for ; Wed, 3 Jul 2019 17:58:42 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id m8so976141vsj.0 for ; Wed, 03 Jul 2019 17:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UWHSldNF4DF1VRBS0nHbTyG4adXpK7+4hxTK8RxN5Bc=; b=TQyp+VtKxyvIv911X7SJe0qyW7Xx7idtFV0DbwBSMLIJIq40RbMbFd3P72nLWwngFu nkvJ9jEp4HfcN8b4L0EyDyg5V26TcYQ/MgOi+J/0STDVXWcagUQOVo797omSvnqft4bv QkbTDSbNVTcuymo6FzqxwP4pKdd9ZEEcym/ib0/q1okDDAwfY/zLaoe3+ERh92Pxm3Kf GqahIcTGPOoYeFE7qpLfcOdAQF1xuKjkP3XlbtsBahEbtH3o47Z6f/Ro5/x7LRduwVFR oFbu7JgTinvFaP8sNBARzg5EKWlbbeYDxlO7AuZrrn4nl+BEymAuDtOl/K+bZrdc/3Pe DWBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UWHSldNF4DF1VRBS0nHbTyG4adXpK7+4hxTK8RxN5Bc=; b=G335omSYK1kZ82AavCHdU804O++ukWmtXs1qMuQbtYVAf3R4RjQ4m59HQbYjAbsNdz UWrjSipyEVTSuY49ZPurb0pdvBZvFlN99k+nFPVRItZVv5BfP8Khk7dbMV2Gk6S3hloG 0kzWyv4+0CuNStBN+o1iGHCCBgABjXwKymzUTLb6D3jTV82wRt/CBSDqkNyFgljx7x2Q +QrS97ZRNAXmg/lf357GHeyrF0gcwcpDsrXtzMv81yHnF/YYFjijT2WqCV0RHQgD5n3Z fJVLbR+K3YTCzinBX8fQRHdTUgxLWBJXbNVl/KGEDnhwhWH04O2cgvlUuYKbWyj2KZuT C4dQ== X-Gm-Message-State: APjAAAXI8r88h4KG0yAra7RJ2SbP4qKRugO4snpK75LvQ+HOnkeBsYJA 0CyCSQ+zAewU3GbJLCMAUcnkmyYJfIsuW1kByBf9aA== X-Google-Smtp-Source: APXvYqwi+E4c/x8vz63YbpcLA/l41tXxDaSaetiMMt0d4O8IAE0FDtisa+iOKicNRJkYdaBBG2Yi78YLb4/dqmMt36A= X-Received: by 2002:a67:8d8a:: with SMTP id p132mr19465472vsd.103.1562201920450; Wed, 03 Jul 2019 17:58:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 3 Jul 2019 17:58:28 -0700 Message-ID: To: Roman Shpount Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000898db5058cd07ac6" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 00:58:51 -0000 --000000000000898db5058cd07ac6 Content-Type: text/plain; charset="UTF-8" Hmm, that's unfortunate. I think this is a mistake, given that we are about to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this extension spec is written. ice-sip-sdp isn't published yet, so it seems an update to that document could still be a possibility. If that's not an option, putting forth #1 as a specific extension that allows FQDN candidates to be generated in certain situations seems like the right path. On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: > Part of the problem is that mmusic have decided to punt on the FQDN > support. In the current mmusic-ice-sip-sdp the final language that was > included: > > : is taken from RFC 4566 [RFC4566]. It is the IP > address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and > fully qualified domain names (FQDNs). When parsing this field, an agent > can differentiate an IPv4 address and an IPv6 address by presence of a > colon in its value - the presence of a colon indicates IPv6. *An agent > generating local candidates MUST NOT use FQDN addresses. An agent > processing remote candidates MUST ignore candidate lines that include > candidates with FQDN *or IP address versions that are not supported or > recognized. *The procedures for generation and handling of FQDN > candidates, as well as, how agents indicate support for such procedures, > need to be specified in an extension specification.* > > So, at this point we have two options: > 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define > how FQDN candidates generated by mdns are handled > 2. write a new draft in mmusic which defines FQDN handling > > In any case some sort of mmusic discussion is needed to reconcile this. > > Best Regards, > _____________ > Roman Shpount > > > On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote: > >> The problem this draft is trying to solve is fairly RTCWEB-specific. If >> there are individual issues to resolve, we can send them out to mmusic for >> discussion, but AFAIK no changes to existing ICE specs are needed. >> >> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: >> >>> Hi All, >>> >>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? >>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb. >>> Also, there are significant interop implications for this draft >>> between browser and non-browser end points which probably warrant larger >>> discussion outside of rtcweb group. I would think mmusic would be a much >>> better place for this draft. I know there is an incentive to complete this >>> draft quickly but this has a potential to break a lot of things (it already >>> did break interop with almost every existing ICE implementation). >>> >>> Regards, >>> _____________ >>> Roman Shpount >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> --000000000000898db5058cd07ac6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmm, that's unfortunate. I think this is a mistake, gi= ven that we are about to throw the switch to enable mDNS for 100% of Chrome= endpoints; Chrome (and soon all browsers) will have to ignore ice-sip-sdp = until this extension spec is written.

ice-sip-sdp isn= 9;t published yet, so it seems an update to that document could still be a = possibility. If that's not an option, putting forth #1 as a specific ex= tension that allows FQDN candidates to be generated in certain situations s= eems like the right path.



=
On Wed, Ju= l 3, 2019 at 5:40 PM Roman Shpount <roman@telurix.com> wrote:
Part = of the problem is that mmusic have decided to punt on the FQDN support. In = the current mmusic-ice-sip-sdp the final language that was included:
<= div dir=3D"ltr">
<connection-address>: =C2= =A0is taken from RFC 4566 [RFC4566].=C2=A0 It is the IP address of the cand= idate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified dom= ain names (FQDNs).=C2=A0 When parsing=C2=A0this field, an agent can differe= ntiate an IPv4 address and an IPv6=C2=A0address by presence of a colon in i= ts value - the presence of a=C2=A0colon indicates IPv6. =C2=A0An agent g= enerating local candidates MUST=C2=A0NOT use FQDN addresses.=C2=A0 An agent= processing remote candidates=C2=A0MUST ignore candidate lines that include= candidates with FQDN or=C2=A0IP address versions that are not supporte= d or recognized. =C2=A0The=C2=A0procedures for generation and handling o= f FQDN candidates, as well=C2=A0as, how agents indicate support for such pr= ocedures, need to be=C2=A0specified in an extension specification.
<= /div>

So, at this point we have = two options:=C2=A0
1. draft-ietf-rtcweb-mdns-ice-cand= idates can update ice-sip-sdp and define how FQDN candidates generated by m= dns are handled
2. write a new draft in mmusic which defines FQDN= handling

In any case some sort of mmusic discussi= on is needed to reconcile this.

Best Regards,
_____________
Roman Shpou= nt


On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <juberti@google.com>= wrote:
The problem this draft is trying to solve is fairly RTCWEB-specifi= c. If there are individual issues to resolve, we can send them out to mmusi= c=C2=A0for discussion, but AFAIK no changes to existing ICE specs are neede= d.

On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
Hi All,

Is rtcweb= the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire dra= ft seems to be ICE/SDP specific and not limited to rtcweb. Also, there are = significant interop implications for this draft between=C2=A0browser and no= n-browser end points which probably warrant larger discussion outside of rt= cweb group. I would think mmusic would be a much better place for this draf= t. I know there is an incentive to complete this draft quickly but this has= a potential to break a lot of things (it already did break interop with al= most every existing ICE implementation).

Regards,
_____________
Roman Sh= pount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000898db5058cd07ac6-- From nobody Wed Jul 3 18:15:20 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9BC1201A0 for ; Wed, 3 Jul 2019 18:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaNaJzMrszZO for ; Wed, 3 Jul 2019 18:15:15 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 8279012010F for ; Wed, 3 Jul 2019 18:15:15 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id s27so2075734pgl.2 for ; Wed, 03 Jul 2019 18:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Sj9FVzTDGbFfpHphlVNDdgQMHAYfbmoEKVSZ5d5cbg=; b=JWWyCFnkpUUqKap8kPBQoWPqSvahaWJks5q14lgKSACMEkUgspPTjzXiGxgZ6Pr5It RHKK4Xfj19QP+Mm5YaeSuu23nzYfzKAoBvWxGF/1K+fkoQfV8MTKFPWJf8XzVz6YJ+yf TMdp5CsCa4j8NcI2yaAh9irFiA4vhRTT6FiHG0I/vE/W9kGLSv81+qpxT+8SYC5COODW 5RMBu9ZrvkcUZTzMpAS382qMFHeXUGItixNJK4VVSjAFKvvD9Bc16FGgN5UpIvVsd/J0 ReiazK1g71WsphGRKymS5kfhen3gtVxn7CuF1kw9bUccu0hh2ig0F+wZBg2XIS5tlAjO nXJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Sj9FVzTDGbFfpHphlVNDdgQMHAYfbmoEKVSZ5d5cbg=; b=HItiL1uwx22uGHv2Qmzdi5qsQ7AhDK0tYVTTr0twBP9tqYRhhLF/ORKW1kP2P3Aynp VFjE9uGJqBJXdMQ8zd3FvnPQrTMC7n4tKzIDxNLlk2AvcHHfBWZbwQ7Kn3+t6ddiUKOL 88gL4qhqENoJ8FlGzlOW3P3bAQo5PG/k0Qd/EhSnQeN/W11IdXmo4sd0IlvSYDXmQ3AS 5peieTrAXKmJ2oIZEn27PQxWSTIrDNdvhklDn2QrkfKFu6kCadl6c8VfaNIi7Lvou08M K5vyB+dB2qHyo5z5wPfsfKzRLB5riK30PbGAru/yHB1sp8oJyp2J4AZYoiP5MQa1daFt 1KtA== X-Gm-Message-State: APjAAAUvLlZ7KA/dy3QW31dAqHaqNikBcourilrPBrkgAU5iY5H2KUiB Hgn37JV7VRNoRV+zaz3/yAc+NmRo X-Google-Smtp-Source: APXvYqzXQidbts+Zg2UlGMVX/MJrtOPpVKZeZkBsmvl+sq7dSjcgb3KU5kp3ikmfhzeOQBi/GqCqIQ== X-Received: by 2002:a17:90a:f498:: with SMTP id bx24mr16374834pjb.91.1562202914583; Wed, 03 Jul 2019 18:15:14 -0700 (PDT) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com. [209.85.214.171]) by smtp.gmail.com with ESMTPSA id u21sm7172322pfm.70.2019.07.03.18.15.13 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 18:15:13 -0700 (PDT) Received: by mail-pl1-f171.google.com with SMTP id c14so2162483plo.0 for ; Wed, 03 Jul 2019 18:15:13 -0700 (PDT) X-Received: by 2002:a17:902:20c8:: with SMTP id v8mr45901592plg.284.1562202912728; Wed, 03 Jul 2019 18:15:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Wed, 3 Jul 2019 21:15:03 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ae2fdf058cd0b5f1" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 01:15:19 -0000 --000000000000ae2fdf058cd0b5f1 Content-Type: text/plain; charset="UTF-8" This direction was taken since mmusic got no feedback regarding the specifics of FQDN support. I did try to get mdns authors, including you, to participate in the discussion, since I was afraid this can be a problem, but no one responded at that time. As it stands, there are significant issues with just putting FQDN in candidate. The gist of the issue is that due to things like DNS64 there is no way to enforce that FQDN will resolve to the same address family to which FQDN was originally pointed to. So, end points will end up either with different address families or with multiple addresses for the same candidate even when FQDN in candidate originally only pointed to a single IP. Connectivity checks will likely succeed on some of those address pairs, but figuring out priority for the candidate pairs becomes confusing and under-specified. No one wanted to discuss or deal with this before ice-sip-sdp was published so the current language was put in place. I know the browsers are trying to address what they perceive is a significant issue, but I would think that current mdns draft is fairly raw and turning this option on is likely premature. It might lead to multiple, non-backwards compatible versions of this feature. _____________ Roman Shpount On Wed, Jul 3, 2019 at 8:58 PM Justin Uberti wrote: > Hmm, that's unfortunate. I think this is a mistake, given that we are > about to throw the switch to enable mDNS for 100% of Chrome endpoints; > Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this > extension spec is written. > > ice-sip-sdp isn't published yet, so it seems an update to that document > could still be a possibility. If that's not an option, putting forth #1 as > a specific extension that allows FQDN candidates to be generated in certain > situations seems like the right path. > > > > On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: > >> Part of the problem is that mmusic have decided to punt on the FQDN >> support. In the current mmusic-ice-sip-sdp the final language that was >> included: >> >> : is taken from RFC 4566 [RFC4566]. It is the IP >> address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and >> fully qualified domain names (FQDNs). When parsing this field, an agent >> can differentiate an IPv4 address and an IPv6 address by presence of a >> colon in its value - the presence of a colon indicates IPv6. *An agent >> generating local candidates MUST NOT use FQDN addresses. An agent >> processing remote candidates MUST ignore candidate lines that include >> candidates with FQDN *or IP address versions that are not supported or >> recognized. *The procedures for generation and handling of FQDN >> candidates, as well as, how agents indicate support for such procedures, >> need to be specified in an extension specification.* >> >> So, at this point we have two options: >> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and >> define how FQDN candidates generated by mdns are handled >> 2. write a new draft in mmusic which defines FQDN handling >> >> In any case some sort of mmusic discussion is needed to reconcile this. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote: >> >>> The problem this draft is trying to solve is fairly RTCWEB-specific. If >>> there are individual issues to resolve, we can send them out to mmusic for >>> discussion, but AFAIK no changes to existing ICE specs are needed. >>> >>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: >>> >>>> Hi All, >>>> >>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? >>>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb. >>>> Also, there are significant interop implications for this draft >>>> between browser and non-browser end points which probably warrant larger >>>> discussion outside of rtcweb group. I would think mmusic would be a much >>>> better place for this draft. I know there is an incentive to complete this >>>> draft quickly but this has a potential to break a lot of things (it already >>>> did break interop with almost every existing ICE implementation). >>>> >>>> Regards, >>>> _____________ >>>> Roman Shpount >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> --000000000000ae2fdf058cd0b5f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This direction was taken since mmusic got no feedback rega= rding the specifics of FQDN support. I did try to get mdns authors, includi= ng you, to participate in the discussion, since I was afraid this can be a = problem, but no one responded at that time.

As it stands= , there are significant issues with just putting FQDN in candidate. The gis= t of the issue is that due to things like DNS64 there is no way to enforce = that FQDN will resolve to the same address family to which FQDN was origina= lly pointed to. So, end points will end up either with different address fa= milies or with multiple addresses for the same candidate even when FQDN in = candidate originally only pointed to a single IP. Connectivity checks will = likely succeed on some of those address pairs, but figuring out priority fo= r the candidate pairs becomes confusing and under-specified. No one wanted = to discuss or deal with this before ice-sip-sdp was published so the curren= t language was put in place.

I know the browsers are try= ing to address what they perceive is a significant issue, but I would think= that current mdns draft is fairly raw and turning this option on is likely= premature. It might lead to multiple, non-backwards compatible versions of= this feature.
_____________
Roman Shpount


On Wed, Jul 3, 2019 at 8:58 PM Justin Uberti <juberti@google.com> wrote:
Hmm, = that's unfortunate. I think this is a mistake, given that we are about = to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (an= d soon all browsers) will have to ignore ice-sip-sdp until this extension s= pec is written.

ice-sip-sdp isn't published yet, so = it seems an update to that document could still be a possibility. If that&#= 39;s not an option, putting forth #1 as a specific extension that allows FQ= DN candidates to be generated in certain situations seems like the right pa= th.



On Wed, Jul 3, 2019 at 5:40 PM R= oman Shpount <rom= an@telurix.com> wrote:
Part of the problem is that= mmusic have decided to punt on the FQDN support. In the current mmusic-ice= -sip-sdp the final language that was included:

<connection-address>: =C2=A0is taken from RFC 45= 66 [RFC4566].=C2=A0 It is the IP address of the candidate, allowing for IPv= 4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs).=C2= =A0 When parsing=C2=A0this field, an agent can differentiate an IPv4 addres= s and an IPv6=C2=A0address by presence of a colon in its value - the presen= ce of a=C2=A0colon indicates IPv6. =C2=A0An agent generating local candi= dates MUST=C2=A0NOT use FQDN addresses.=C2=A0 An agent processing remote ca= ndidates=C2=A0MUST ignore candidate lines that include candidates with FQDN= or=C2=A0IP address versions that are not supported or recognized. =C2= =A0The=C2=A0procedures for generation and handling of FQDN candidates, a= s well=C2=A0as, how agents indicate support for such procedures, need to be= =C2=A0specified in an extension specification.

So, at this point we have two options:=C2=A0
1. draft-ietf-rtcweb-mdns-ice-candidates can update ic= e-sip-sdp and define how FQDN candidates generated by mdns are handled
2. write a new draft in mmusic which defines FQDN handling
=
In any case some sort of mmusic discussion is needed to reco= ncile this.

Best Regards,
_____________
Roma= n Shpount


On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
The problem this draft is trying to solve is fairly RTCWEB-s= pecific. If there are individual issues to resolve, we can send them out to= mmusic=C2=A0for discussion, but AFAIK no changes to existing ICE specs are= needed.

On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
Hi All,

Is rt= cweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire= draft seems to be ICE/SDP specific and not limited to rtcweb. Also, there = are significant interop implications for this draft between=C2=A0browser an= d non-browser end points which probably warrant larger discussion outside o= f rtcweb group. I would think mmusic would be a much better place for this = draft. I know there is an incentive to complete this draft quickly but this= has a potential to break a lot of things (it already did break interop wit= h almost every existing ICE implementation).

Regards,
_____________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000ae2fdf058cd0b5f1-- From nobody Wed Jul 3 18:37:03 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3F81200E7 for ; Wed, 3 Jul 2019 18:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6Bj-zSLkeMG for ; Wed, 3 Jul 2019 18:36:58 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 838401200D7 for ; Wed, 3 Jul 2019 18:36:58 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id 9so2180481ple.5 for ; Wed, 03 Jul 2019 18:36:58 -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=+YuY0DdHILnLO0Pqy/iKJAbXQd25cbPGbyhQ7DdaDBA=; b=UPyytai1qjWuGz0vxKDa/smV4PEszjkNMVTR0RNDLdMe3/UndXY0eV+aEeY44smatB I4QEsOGaYNQBqe54LbQ3CUz6+wvIJNm8zuouopMNxur6BwETV68zepBvWH6Dl9MuMbLc 2STvPQxx3jmls8h1PsnoZxQRrb9iE8NvMNJya6kWzrx5KW8TXdocxL1L+MLelcJuI6nA LMjkGBLGXdY0ONQx72corCH6h174Kosp5DxZwpgGPekAMfwoVPOA8UqLmkEr6u0GeG/S /SDaZUlJBG0mxVmRzhanAXMXZKfqD8P78faTXTjIPif8CXZz0kHWgDd+NXMQNUQ7FMbW YrDg== 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=+YuY0DdHILnLO0Pqy/iKJAbXQd25cbPGbyhQ7DdaDBA=; b=Hu36b5ZzGFv3GcwWCQM8E9uD4ZVViczoH99Z8762qFIjTteBPxpNdhkiQ8yirq0HX3 Dha3OKZJ8ppOVvlcE4ZqdqHHZCMAJYZLGAEoymS0EvWiqHyLrlUhyAeHoMOMvFeNHIwE 9tPyC+M1mbrtWR0x3QpeSTuKxQ+tOFYPowqoZc/8m22W+QIldBYHK4evpMkHnOfMJ9Ar Z99y3n4VIAPmGy/OgZk9QKtVEJA/BLY8zp/xtoyoAWU+Yi+9bBnyqMRhZNkwh4pqV6hE JySXrNIrlUCG1ETYF/zDlV6UnLfZaYvEGBjJyVhhRpyiEdNMv98+4GMyRbzgW03rB9/T +Agg== X-Gm-Message-State: APjAAAXk1FcHu1UXANur2MPX4hDZ1lUPrw1C/L9kudcoTSjCsFmvbcNR XlPXyuomKj9I0AmoZyM7AM3R6Iuw X-Google-Smtp-Source: APXvYqwcnIj4OiR5ymK3UTthsjVC8y0FLYNuKL96M2noioC/54lUq7MDjPv7JnWht5b7rWqWLcfZIg== X-Received: by 2002:a17:902:4283:: with SMTP id h3mr12074956pld.15.1562204214684; Wed, 03 Jul 2019 18:36:54 -0700 (PDT) Received: from ?IPv6:2600:380:7066:c0e9:4866:1543:5359:9d3b? ([2600:380:7066:c0e9:4866:1543:5359:9d3b]) by smtp.gmail.com with ESMTPSA id 85sm3546183pfv.130.2019.07.03.18.36.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 18:36:53 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-726E8203-F349-48FD-A065-7FA39BEC75E6 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (16F250) In-Reply-To: Date: Wed, 3 Jul 2019 18:36:51 -0700 Cc: Roman Shpount , "rtcweb@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <8FB2B040-852C-44E5-82F8-6A7391EB2F53@gmail.com> References: To: Justin Uberti Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 01:37:02 -0000 --Apple-Mail-726E8203-F349-48FD-A065-7FA39BEC75E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don=E2=80=99t see them as contradictory. ice-sip-sdp requires implementati= ons not suporting rtcweb-mdns-ice to ignore the .local candidates. This comb= ined with ice-pac should enable interop of with implementations of rtcweb-md= ns-ice via server reflexive candidates. The one remaining piece is legacy handling of c=3D lines with mDNS names.=20= > On Jul 3, 2019, at 5:58 PM, Justin Uberti wrote: >=20 > Hmm, that's unfortunate. I think this is a mistake, given that we are abou= t to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (a= nd soon all browsers) will have to ignore ice-sip-sdp until this extension s= pec is written. >=20 > ice-sip-sdp isn't published yet, so it seems an update to that document co= uld still be a possibility. If that's not an option, putting forth #1 as a s= pecific extension that allows FQDN candidates to be generated in certain sit= uations seems like the right path. >=20 >=20 >=20 >> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: >> Part of the problem is that mmusic have decided to punt on the FQDN suppo= rt. In the current mmusic-ice-sip-sdp the final language that was included: >>=20 >> : is taken from RFC 4566 [RFC4566]. It is the IP ad= dress of the candidate, allowing for IPv4 addresses, IPv6 addresses, and ful= ly qualified domain names (FQDNs). When parsing this field, an agent can di= fferentiate an IPv4 address and an IPv6 address by presence of a colon in it= s value - the presence of a colon indicates IPv6. An agent generating local= candidates MUST NOT use FQDN addresses. An agent processing remote candida= tes MUST ignore candidate lines that include candidates with FQDN or IP addr= ess versions that are not supported or recognized. The procedures for gener= ation and handling of FQDN candidates, as well as, how agents indicate suppo= rt for such procedures, need to be specified in an extension specification. >>=20 >> So, at this point we have two options:=20 >> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and defin= e how FQDN candidates generated by mdns are handled >> 2. write a new draft in mmusic which defines FQDN handling >>=20 >> In any case some sort of mmusic discussion is needed to reconcile this. >>=20 >> Best Regards, >> _____________ >> Roman Shpount >>=20 >>=20 >>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote:= >>> The problem this draft is trying to solve is fairly RTCWEB-specific. If t= here are individual issues to resolve, we can send them out to mmusic for di= scussion, but AFAIK no changes to existing ICE specs are needed. >>>=20 >>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote:= >>>> Hi All, >>>>=20 >>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? Th= is entire draft seems to be ICE/SDP specific and not limited to rtcweb. Also= , there are significant interop implications for this draft between browser a= nd non-browser end points which probably warrant larger discussion outside o= f rtcweb group. I would think mmusic would be a much better place for this d= raft. I know there is an incentive to complete this draft quickly but this h= as a potential to break a lot of things (it already did break interop with a= lmost every existing ICE implementation). >>>>=20 >>>> Regards, >>>> _____________ >>>> Roman Shpount >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-726E8203-F349-48FD-A065-7FA39BEC75E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I d= on=E2=80=99t see them as contradictory. ice-sip-sdp requires implementations= not suporting rtcweb-mdns-ice to ignore the .local candidates. This combine= d with ice-pac should enable interop of with implementations of rtcweb-mdns-= ice via server reflexive candidates.

The one remaining piece is legacy handling of c=3D lines with mDNS= names. 



On Jul 3, 2019, at 5:58 PM, Justin Uberti <juberti=3D40google.com@dmarc.ie= tf.org> wrote:

Hmm, that's unfortunate. I think this is a mistake, given= that we are about to throw the switch to enable mDNS for 100% of Chrome end= points; Chrome (and soon all browsers) will have to ignore ice-sip-sdp until= this extension spec is written.

ice-sip-sdp isn't publis= hed yet, so it seems an update to that document could still be a possibility= . If that's not an option, putting forth #1 as a specific extension that all= ows FQDN candidates to be generated in certain situations seems like the rig= ht path.



On Wed, Jul 3, 2019 at 5:40 P= M Roman Shpount <r= oman@telurix.com> wrote:
Part of the problem is that m= music have decided to punt on the FQDN support. In the current mmusic-ice-si= p-sdp the final language that was included:

=
<connection-address>:  is taken from RFC 4566 [R= FC4566].  It is the IP address of the candidate, allowing for IPv4 addr= esses, IPv6 addresses, and fully qualified domain names (FQDNs).  When p= arsing this field, an agent can differentiate an IPv4 address and an IP= v6 address by presence of a colon in its value - the presence of a = ;colon indicates IPv6.  An agent generating local candidates MUST&nb= sp;NOT use FQDN addresses.  An agent processing remote candidates = MUST ignore candidate lines that include candidates with FQDN or IP= address versions that are not supported or recognized.  The pr= ocedures for generation and handling of FQDN candidates, as well as, ho= w agents indicate support for such procedures, need to be specified in a= n extension specification.

So, at this point we have two options: 
1. d= raft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define how FQ= DN candidates generated by mdns are handled
2. write a new draft i= n mmusic which defines FQDN handling

In any case so= me sort of mmusic discussion is needed to reconcile this.

Best Regards,
_____= ________
Roman Shpount


On Wed, Jul 3, 2019 at 8:28 PM Justi= n Uberti <juberti= @google.com> wrote:
The problem this draft is trying to solve is fairly R= TCWEB-specific. If there are individual issues to resolve, we can send them o= ut to mmusic for discussion, but AFAIK no changes to existing ICE specs= are needed.

On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
<= /div>
Hi All,

Is rtcwe= b the right place for draft-ietf-rtcweb-mdns-ice-candidates? This entire dra= ft seems to be ICE/SDP specific and not limited to rtcweb. Also, there are s= ignificant interop implications for this draft between browser and non-= browser end points which probably warrant larger discussion outside of rtcwe= b group. I would think mmusic would be a much better place for this draft. I= know there is an incentive to complete this draft quickly but this has a po= tential to break a lot of things (it already did break interop with almost e= very existing ICE implementation).

Regards,
_____________
Roman Shpount
<= /div>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
________= _______________________________________
rtcweb mailing list<= /span>
rtcweb@ietf.org
https://= www.ietf.org/mailman/listinfo/rtcweb
= --Apple-Mail-726E8203-F349-48FD-A065-7FA39BEC75E6-- From nobody Wed Jul 3 21:33:36 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BDD1202AD for ; Wed, 3 Jul 2019 21:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJrWx3mgO8Do for ; Wed, 3 Jul 2019 21:33:32 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 C7C7F120176 for ; Wed, 3 Jul 2019 21:33:31 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id r3so1192693vsr.13 for ; Wed, 03 Jul 2019 21:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ixNBAJcsk2XvhVLHahXKN+NXOlosxx3iYgRlVYeaWgs=; b=KBfuNebNULIY+1WkoHWIu+oo8ouqqhF1q7je3YUTd/RLn7vpJCpEwll9a0ENaXfA1C 0GpsOd7rQGfx54PyR/zi1G7145WUIdapELW28E/U/PX7a9iQmvbX1yDFiWqjLihtrLn4 a+Ud6jo/rcf0tR9DG71DwjkwZYnU2SpHs7ldYihinSSynqkcx0uz/qwMXIsMTBGLnryl bSpqD4xExqrysIHlK0/TMUAvbui412q7xuOYcR7U4kZLqALEELwyE5UU0ciV4pePgDJI ieB3FvROabd0L1exZmxofOAani7s5b+VecKQujq+u/SLPY5Zomzc05tk//ERHA/kg4BE oI0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ixNBAJcsk2XvhVLHahXKN+NXOlosxx3iYgRlVYeaWgs=; b=mmPK9nWYASWNBcBYZqTVPEcTlCH890xpFIQdSF9xtuljabVDYV4XPB6LKUlhrB60r5 99gYkXUQo7v40kk9y9GbZqw+96f27r9wNdTNYNnZd9GNOl6CeDg0ObAAvupoltY9P1il hXxLRbBABpxFu8rc+QTEqSYYVTiPCmex+gBExFER/gKzEaenL5leKI5I2yjkBoYg6Te+ MXKdEQ37A4sEHpbOsXnxBLYGNS7ATwJwLiIGbuqUvASuSPK2IJWE633gm7YNMw4C8Myw 1+2SfxTSw86F4NUHH6Pz1hYg+JmM+6hWQeCB2FQXU+v8mFqH9gOVJlv6Mkffchd1527i QHMg== X-Gm-Message-State: APjAAAWMWB0oQF81HIX5fVaA9u8HcTdpA4sj2z9XlPbIpp30W4pcM4j6 6ktsz6ztrOnrQm+jz3QMlffmcQN65WkuVjNR69u6hg== X-Google-Smtp-Source: APXvYqy44+y0cUktkiSUmwQKaKTpd7BmnW6UwI1yOloQcM6S3w0l3YJHLsP55BotoO71uYPyC52607HOLTgWJz6+ro8= X-Received: by 2002:a67:ff0a:: with SMTP id v10mr21896912vsp.1.1562214810474; Wed, 03 Jul 2019 21:33:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 3 Jul 2019 21:33:19 -0700 Message-ID: To: Roman Shpount Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d7b862058cd37a0f" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 04:33:35 -0000 --000000000000d7b862058cd37a0f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 3, 2019 at 6:15 PM Roman Shpount wrote: > This direction was taken since mmusic got no feedback regarding the > specifics of FQDN support. I did try to get mdns authors, including you, to > participate in the discussion, since I was afraid this can be a problem, > but no one responded at that time. > Sorry, I haven't been reading mmusic regularly lately and missed your outreach. > As it stands, there are significant issues with just putting FQDN in > candidate. The gist of the issue is that due to things like DNS64 there is > no way to enforce that FQDN will resolve to the same address family to > which FQDN was originally pointed to. So, end points will end up either > with different address families or with multiple addresses for the same > candidate even when FQDN in candidate originally only pointed to a single > IP. Connectivity checks will likely succeed on some of those address pairs, > but figuring out priority for the candidate pairs becomes confusing and > under-specified. No one wanted to discuss or deal with this before > ice-sip-sdp was published so the current language was put in place. > I need to understand the DNS64 issue better, I'm not sure how this would pose a problem in practice. > I know the browsers are trying to address what they perceive is a > significant issue, but I would think that current mdns draft is fairly raw > and turning this option on is likely premature. It might lead to multiple, > non-backwards compatible versions of this feature. > If anything, I think we've been too slow here. The initial mDNS draft was posted over a year ago. > > > On Wed, Jul 3, 2019 at 8:58 PM Justin Uberti wrote: > >> Hmm, that's unfortunate. I think this is a mistake, given that we are >> about to throw the switch to enable mDNS for 100% of Chrome endpoints; >> Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this >> extension spec is written. >> >> ice-sip-sdp isn't published yet, so it seems an update to that document >> could still be a possibility. If that's not an option, putting forth #1 as >> a specific extension that allows FQDN candidates to be generated in certain >> situations seems like the right path. >> >> >> >> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: >> >>> Part of the problem is that mmusic have decided to punt on the FQDN >>> support. In the current mmusic-ice-sip-sdp the final language that was >>> included: >>> >>> : is taken from RFC 4566 [RFC4566]. It is the IP >>> address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and >>> fully qualified domain names (FQDNs). When parsing this field, an agent >>> can differentiate an IPv4 address and an IPv6 address by presence of a >>> colon in its value - the presence of a colon indicates IPv6. *An agent >>> generating local candidates MUST NOT use FQDN addresses. An agent >>> processing remote candidates MUST ignore candidate lines that include >>> candidates with FQDN *or IP address versions that are not supported or >>> recognized. *The procedures for generation and handling of FQDN >>> candidates, as well as, how agents indicate support for such procedures, >>> need to be specified in an extension specification.* >>> >>> So, at this point we have two options: >>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and >>> define how FQDN candidates generated by mdns are handled >>> 2. write a new draft in mmusic which defines FQDN handling >>> >>> In any case some sort of mmusic discussion is needed to reconcile this. >>> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote: >>> >>>> The problem this draft is trying to solve is fairly RTCWEB-specific. If >>>> there are individual issues to resolve, we can send them out to mmusic for >>>> discussion, but AFAIK no changes to existing ICE specs are needed. >>>> >>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: >>>> >>>>> Hi All, >>>>> >>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? >>>>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb. >>>>> Also, there are significant interop implications for this draft >>>>> between browser and non-browser end points which probably warrant larger >>>>> discussion outside of rtcweb group. I would think mmusic would be a much >>>>> better place for this draft. I know there is an incentive to complete this >>>>> draft quickly but this has a potential to break a lot of things (it already >>>>> did break interop with almost every existing ICE implementation). >>>>> >>>>> Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> --000000000000d7b862058cd37a0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 3, 2019 at 6:15 PM Roman = Shpount <roman@telurix.com> = wrote:
This direction was taken since mmusic got no feedback regarding th= e specifics of FQDN support. I did try to get mdns authors, including you, = to participate in the discussion, since I was afraid this can be a problem,= but no one responded at that time.=C2=A0

=
Sorry, I haven't been reading mmusic=C2=A0regularly lately and mis= sed your outreach.
=C2=A0
As it stands, there ar= e significant issues with just putting FQDN in candidate. The gist of the i= ssue is that due to things like DNS64 there is no way to enforce that FQDN = will resolve to the same address family to which FQDN was originally pointe= d to. So, end points will end up either with different address families or = with multiple addresses for the same candidate even when FQDN in candidate = originally only pointed to a single IP. Connectivity checks will likely suc= ceed on some of those address pairs, but figuring out priority for the cand= idate pairs becomes confusing and under-specified. No one wanted to discuss= or deal with this before ice-sip-sdp was published so the current language= was put in place.

I need to u= nderstand the DNS64 issue better, I'm not sure how this would pose a pr= oblem in practice.=C2=A0


I know the browser= s are trying to address what they perceive is a significant issue, but I wo= uld think that current mdns draft is fairly raw and turning this option on = is likely premature. It might lead to multiple, non-backwards compatible ve= rsions of this feature.

If = anything, I think we've been too slow here. The initial mDNS draft was = posted over a year ago.


On Wed, Jul 3, 2019 at 8:58 PM Justin U= berti <juberti@g= oogle.com> wrote:
Hmm, that's unfortunate. I think this is a = mistake, given that we are about to throw the switch to enable mDNS for 100= % of Chrome endpoints; Chrome (and soon all browsers) will have to ignore i= ce-sip-sdp until this extension spec is written.

ice-sip= -sdp isn't published yet, so it seems an update to that document could = still be a possibility. If that's not an option, putting forth #1 as a = specific extension that allows FQDN candidates to be generated in certain s= ituations seems like the right path.



On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <roman@telurix.com> wrote:
Part of the problem is that mmusic have decided to punt on the FQDN s= upport. In the current mmusic-ice-sip-sdp the final language that was inclu= ded:

<connection-addres= s>: =C2=A0is taken from RFC 4566 [RFC4566].=C2=A0 It is the IP address o= f the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qua= lified domain names (FQDNs).=C2=A0 When parsing=C2=A0this field, an agent c= an differentiate an IPv4 address and an IPv6=C2=A0address by presence of a = colon in its value - the presence of a=C2=A0colon indicates IPv6. =C2=A0= An agent generating local candidates MUST=C2=A0NOT use FQDN addresses.=C2= =A0 An agent processing remote candidates=C2=A0MUST ignore candidate lines = that include candidates with FQDN or=C2=A0IP address versions that are = not supported or recognized. =C2=A0The=C2=A0procedures for generation an= d handling of FQDN candidates, as well=C2=A0as, how agents indicate support= for such procedures, need to be=C2=A0specified in an extension specificati= on.

So, at this po= int we have two options:=C2=A0
1. draft-ietf-rtcweb-m= dns-ice-candidates can update ice-sip-sdp and define how FQDN candidates ge= nerated by mdns are handled
2. write a new draft in mmusic which = defines FQDN handling

In any case some sort of mmu= sic discussion is needed to reconcile this.

Best R= egards,
_____________
Roman Shpount
<= /div>

On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <juberti@google.com> wrote:
T= he problem this draft is trying to solve is fairly RTCWEB-specific. If ther= e are individual issues to resolve, we can send them out to mmusic=C2=A0for= discussion, but AFAIK no changes to existing ICE specs are needed.
On Wed, = Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
Hi = All,

Is rtcweb the right p= lace for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to = be ICE/SDP specific and not limited to rtcweb. Also, there are significant = interop implications for this draft between=C2=A0browser and non-browser en= d points which probably warrant larger discussion outside of rtcweb group. = I would think mmusic would be a much better place for this draft. I know th= ere is an incentive to complete this draft quickly but this has a potential= to break a lot of things (it already did break interop with almost every e= xisting ICE implementation).

Regards,
_____________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000d7b862058cd37a0f-- From nobody Wed Jul 3 21:50:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31A91200DE for ; Wed, 3 Jul 2019 21:50:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 3Nv7rBn9-O2H for ; Wed, 3 Jul 2019 21:50:23 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 B75ED120088 for ; Wed, 3 Jul 2019 21:50:23 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id t7so2394521plr.11 for ; Wed, 03 Jul 2019 21:50:23 -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=h77aPwLh2Jqtn5S5UXu7DbJLnxztytkBR5G7/RL6hJo=; b=Uo7HdbeBnjh0vSK3Rwl8Dlv90bCn5iVH+GXCuRsDQ3Da01rKdKXZ0AVzJYQrAeNVJU K8oC/tH+I6a1FfmIutNDK9T+DXWj7t9+p8z1pw8XZUl0uVRexSAlqlFzasWWZYUcRJye h79GURFMYjxJc9Ol1U8uqOL4nWCea5QYux4UY= 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=h77aPwLh2Jqtn5S5UXu7DbJLnxztytkBR5G7/RL6hJo=; b=maG31xGB7Axur4+yXheOQWYLN8Zdc1fbPwas29wf9U02Hplt6+0fBnutfenzUazVtq y0ulOLVN7a7y06bMs/FfCJIR42Oc8NehAfUwPdcVOo227bU2eJGzbmkkqeljU1lr7sr1 j9kEa8cT4+vHsSc7v8YNwj8B0sKS3xXLqNjjrX7zME6uEfxEcSwXVPxxA4ansAbH9U1u wflr+DO5aUzlSJ73q59xNwm5UCsgTw/JC2rFXyfvxzTmaJ4UayzXhus11SJIxIwmYNKE lTkiw8vZPzRQelJkIZyCj7mL1zCgbAcNEbtwbgH+PKRQhoZE61xMObDj1wDGUHw4Cwsb PK4g== X-Gm-Message-State: APjAAAVBAKglic+7P094uzWEUbdsWaTQkV4aHt90kr1rO2WUOBpfGQdp sOfgn60f5j0I26fUmrVtWWlTCA== X-Google-Smtp-Source: APXvYqx04U7Pl00r2xmKpSgt6y0O+b04ZA4grny7b+OfaWO/ktb8vOaXjo0lM8BtpelhE4zHQy/zHw== X-Received: by 2002:a17:902:7787:: with SMTP id o7mr43240018pll.120.1562215822923; Wed, 03 Jul 2019 21:50:22 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:3126:36db:8c73:b0d5? ([2601:647:4600:3f31:3126:36db:8c73:b0d5]) by smtp.gmail.com with ESMTPSA id b15sm3933555pfi.141.2019.07.03.21.50.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 21:50:22 -0700 (PDT) From: Nils Ohlmeier Message-Id: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF7AB50-8C40-4811-9FF7-312A9F7CABEA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 3 Jul 2019 21:50:20 -0700 In-Reply-To: Cc: Roman Shpount , "rtcweb@ietf.org" To: Justin Uberti References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 04:50:28 -0000 --Apple-Mail=_4CF7AB50-8C40-4811-9FF7-312A9F7CABEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Probably not the ideal forum to point this out, but I hope the Chrome = team is aware that rolling out this feature, assuming it includes using = mDNS in the connection line, will break interop with Firefox. So I have to concur that rolling this out appears to be premature to me. Best Nils Ohlmeier > On 3Jul, 2019, at 17:58, Justin Uberti = wrote: >=20 > Hmm, that's unfortunate. I think this is a mistake, given that we are = about to throw the switch to enable mDNS for 100% of Chrome endpoints; = Chrome (and soon all browsers) will have to ignore ice-sip-sdp until = this extension spec is written. >=20 > ice-sip-sdp isn't published yet, so it seems an update to that = document could still be a possibility. If that's not an option, putting = forth #1 as a specific extension that allows FQDN candidates to be = generated in certain situations seems like the right path. >=20 >=20 >=20 > On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount > wrote: > Part of the problem is that mmusic have decided to punt on the FQDN = support. In the current mmusic-ice-sip-sdp the final language that was = included: >=20 > : is taken from RFC 4566 [RFC4566]. It is the IP = address of the candidate, allowing for IPv4 addresses, IPv6 addresses, = and fully qualified domain names (FQDNs). When parsing this field, an = agent can differentiate an IPv4 address and an IPv6 address by presence = of a colon in its value - the presence of a colon indicates IPv6. An = agent generating local candidates MUST NOT use FQDN addresses. An agent = processing remote candidates MUST ignore candidate lines that include = candidates with FQDN or IP address versions that are not supported or = recognized. The procedures for generation and handling of FQDN = candidates, as well as, how agents indicate support for such procedures, = need to be specified in an extension specification. >=20 > So, at this point we have two options:=20 > 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and = define how FQDN candidates generated by mdns are handled > 2. write a new draft in mmusic which defines FQDN handling >=20 > In any case some sort of mmusic discussion is needed to reconcile = this. >=20 > Best Regards, > _____________ > Roman Shpount >=20 >=20 > On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti > wrote: > The problem this draft is trying to solve is fairly RTCWEB-specific. = If there are individual issues to resolve, we can send them out to = mmusic for discussion, but AFAIK no changes to existing ICE specs are = needed. >=20 > On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount > wrote: > Hi All, >=20 > Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? = This entire draft seems to be ICE/SDP specific and not limited to = rtcweb. Also, there are significant interop implications for this draft = between browser and non-browser end points which probably warrant larger = discussion outside of rtcweb group. I would think mmusic would be a much = better place for this draft. I know there is an incentive to complete = this draft quickly but this has a potential to break a lot of things (it = already did break interop with almost every existing ICE = implementation). >=20 > Regards, > _____________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_4CF7AB50-8C40-4811-9FF7-312A9F7CABEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Probably not the ideal forum to point this out, but I hope = the Chrome team is aware that rolling out this feature, assuming it = includes using mDNS in the connection line, will break interop with = Firefox.
So I have to concur that rolling this out = appears to be premature to me.

Best
  Nils = Ohlmeier

On 3Jul, 2019, at 17:58, Justin = Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

Hmm, that's unfortunate. I think this is a mistake, given = that we are about to throw the switch to enable mDNS for 100% of Chrome = endpoints; Chrome (and soon all browsers) will have to ignore = ice-sip-sdp until this extension spec is written.

ice-sip-sdp isn't published yet, so it = seems an update to that document could still be a possibility. If that's = not an option, putting forth #1 as a specific extension that allows FQDN = candidates to be generated in certain situations seems like the right = path.



On Wed, Jul = 3, 2019 at 5:40 PM Roman Shpount <roman@telurix.com> wrote:
Part of the problem is that mmusic have decided = to punt on the FQDN support. In the current mmusic-ice-sip-sdp the final = language that was included:

<connection-address>: =  is taken from RFC 4566 [RFC4566].  It is the IP address of = the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully = qualified domain names (FQDNs).  When parsing this field, an = agent can differentiate an IPv4 address and an IPv6 address by = presence of a colon in its value - the presence of a colon = indicates IPv6.  An agent generating local candidates = MUST NOT use FQDN addresses.  An agent processing remote = candidates MUST ignore candidate lines that include candidates with = FQDN or IP address versions that are not supported or = recognized.  The procedures for generation and = handling of FQDN candidates, as well as, how agents indicate = support for such procedures, need to be specified in an extension = specification.

So, at this point we have = two options: 
1. = draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and define = how FQDN candidates generated by mdns are handled
2. = write a new draft in mmusic which defines FQDN handling

In any case some sort of = mmusic discussion is needed to reconcile this.

Best Regards,
_____________
Roman Shpount


On Wed, Jul 3, 2019 at 8:28 PM Justin = Uberti <juberti@google.com> wrote:
The = problem this draft is trying to solve is fairly RTCWEB-specific. If = there are individual issues to resolve, we can send them out to = mmusic for discussion, but AFAIK no changes to existing ICE specs = are needed.

On Wed, Jul 3, 2019 at 4:26 PM Roman = Shpount <roman@telurix.com> wrote:
Hi All,

Is rtcweb the right place = for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to be = ICE/SDP specific and not limited to rtcweb. Also, there are significant = interop implications for this draft between browser and non-browser = end points which probably warrant larger discussion outside of rtcweb = group. I would think mmusic would be a much better place for this draft. = I know there is an incentive to complete this draft quickly but this has = a potential to break a lot of things (it already did break interop with = almost every existing ICE implementation).

Regards,
___________= __
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_4CF7AB50-8C40-4811-9FF7-312A9F7CABEA-- From nobody Wed Jul 3 22:26:47 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D951200CE for ; Wed, 3 Jul 2019 22:26:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 edikojVJBnz3 for ; Wed, 3 Jul 2019 22:26:43 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 10D33120088 for ; Wed, 3 Jul 2019 22:26:42 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id m30so2358317pff.8 for ; Wed, 03 Jul 2019 22:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=cEPgc+6r9NWfaXGQC9XCSo/R0+wySHhcBUkZIspzdBU=; b=gUOBJevDGG0ESxrNnVggeqdlIt7afHGTLidv/iYoJDz0UBKInh8+dEmU0z6NGAS1zq rakdO9fELhchCy3bSqUPBIU11GNd5IwuNCq8XuUmBiKoSYFgYMzKDZAszt95H5lcZcUf x3/7TvJTabAGZeeVmYMgPLnVhetrgLq834WDI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=cEPgc+6r9NWfaXGQC9XCSo/R0+wySHhcBUkZIspzdBU=; b=l4DEKtzxvVj/5ZkZD5JJ9Zbs7bn1mARWMwZLaL/lzz2PqiO0MuMPvBhqNlQTrSmg79 ehVo85/UBRLycnR0tmNNEJ9PCM2oOzwVigVXVY9SDwB3wSkBfLsD75aoH2WoiflBrqPu CZMFd++GaRCx9Uy6cw8UWh6gQVugEN5t1/OK9BwC0L7bk826zR0yJLv8ZUYCMwR4htcG H+8CKuNhhEVIWK2XGoHzvuFS+OEhmKkW+ife/N/eNh1bQ0Ls0JjBIXJmBYJWCxxnXZqD /1VRNrHlovmbmvXr4tr7pA8mPHHA+abBOzd75O0jX1ANwc/V26zyt14XDKulCfbfbWH6 uRvA== X-Gm-Message-State: APjAAAVuaXE9zhLyfPT9w18cVldaJXsg8va9A6S9IHX4R+4VRZ5DG5nz lVtUizfUJXPyKvZw0FEekNAORT0D67Q= X-Google-Smtp-Source: APXvYqwLIspCKs/xYagafm7qxj06aEZ00bY2WFDJHeR6OAPBY0HO7FQSx48HKxYRIZAOJ97pL/E4EQ== X-Received: by 2002:a65:5888:: with SMTP id d8mr40500270pgu.124.1562218002020; Wed, 03 Jul 2019 22:26:42 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:3126:36db:8c73:b0d5? ([2601:647:4600:3f31:3126:36db:8c73:b0d5]) by smtp.gmail.com with ESMTPSA id q10sm3543028pgg.35.2019.07.03.22.26.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 22:26:41 -0700 (PDT) From: Nils Ohlmeier Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> Date: Wed, 3 Jul 2019 22:26:40 -0700 To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 05:26:46 -0000 Hello, I have concerns regarding the current recommendations in = draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP = addresses in the =E2=80=9Cc=3D=E2=80=9C lines. Section 3.1.2.3 recommends to use mDNS for the connection-address. I = think we should reconsider this advice as some SPD parsers handle = parsing failures differently depending on line type. In case of Firefox a parsing failure for the connection line is treated = as terminal failure. Where parsing failures for a=3D lines are expected, = as these might contain unknown new features. Section 4.3 mentions that hostnames in ICE candidates can result in ICE = failures, but it does not cover backward compatibility in regards to the = c=3D line. My recommendation is to change the draft so that it recommends to always = use a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in = use. Obviously it could also be recommended to use an IP4 address = instead. The important point is only to use the same IP consistently in = all c=3D lines and across all instances. I think the advantage of this is better backwards compatibility, and it = will not reveal any more details about the user agent compared to using = mDNS names in c=3D lines. Best regards Nils Ohlmeier= From nobody Wed Jul 3 22:41:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668212014B for ; Wed, 3 Jul 2019 22:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjqjbwLjGvrj for ; Wed, 3 Jul 2019 22:41:34 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 45D8912012A for ; Wed, 3 Jul 2019 22:41:33 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id j2so725340uaq.5 for ; Wed, 03 Jul 2019 22:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FBXKNQpN98BawmhyarmGYd+8NU2WNWrZK5d3jBTXlrE=; b=aF8egkTZGh+r3x1oyIJWTbn+WFXaLmM8lYA+gwbzapiKgOHA0TBb6ONJ0qMtxlTc/G OOutt9sfDdjx0n2wNLdvzX2+GNm+v3DsIayVeevWLcBck99Lwl04fV4h6mDApPZCXytE +xthLUTsW7GxwFtRLjSwy9VaTqpCIQml9sVZRO928StPX7kqVuOpit3QOmqVp9Tpee77 3uypzxVB5kjY1pE8hdpET9RyQG8apU+ku8+c9C8apbGY91SV86m+YdmR5Q2T+JEmnyL9 tyA3o73fO6wi+LaqJaQzY1k7KrMQj5i0NSEN4/7WSWPVM3Zj9x8PJmCLjZVhPGo4EgY1 3jeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FBXKNQpN98BawmhyarmGYd+8NU2WNWrZK5d3jBTXlrE=; b=QLLQkL3v6/ATSv1nKawPOxbQ1UAA+aQKrMrmu+95JI82tKGIQryFqgM2PdqLfRrzv2 Ai5s7JaalQLkTmVqWIpVVp28L1EWHF53Frm0Y1wrt91UUpXJWN/dlSWl/9UROR4egJFf 8PCD5DlZh0UV/OhgWbJjbUemzmSaNuALYJsw3/wwb8TM6OEFQ+MsX0pFMpDPOum8jryC 34AQWMJdG6QpUK7tD5e8cqOnotkdJHMJzeM7OkI4RSrVADi1KtDQn3HAhA3peBdwWpyT GQKmPuatPqALFS1thwGzTnKgeZH1KlF9kioR3eJKx76dlSV7GauQdpbSoOOEEkZotsG5 YYug== X-Gm-Message-State: APjAAAVrvWAQtZop7qrznOu0H+bms6wb3JYZRxVbUuDU5FamiMO+9f4+ yay6HwPsRBwPhv5Q8w9TjLOzvp9bejpGFm+3UbKOAg== X-Google-Smtp-Source: APXvYqzWzKv98utgXzyE+a00mBvIOyEUn720M7WICKOoDVZYbTz99VV8JT8zp0hAjP9ZMyyRekiJ2soFdzbA23wK6b4= X-Received: by 2002:ab0:5922:: with SMTP id n31mr19527954uad.103.1562218891873; Wed, 03 Jul 2019 22:41:31 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> In-Reply-To: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> From: Justin Uberti Date: Wed, 3 Jul 2019 22:41:20 -0700 Message-ID: To: Nils Ohlmeier Cc: Roman Shpount , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001cfe26058cd46e86" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 05:41:37 -0000 --0000000000001cfe26058cd46e86 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I understand it, mdns in the c=3D line will only occur in edge cases, i.e., when there are no other candidates. As such I don=E2=80=99t see this = as a showstopper. We have measured the connectivity impact of this change in significant detail and feel increasingly confident there are no egregious latent issues= . On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier wrote: > Probably not the ideal forum to point this out, but I hope the Chrome tea= m > is aware that rolling out this feature, assuming it includes using mDNS i= n > the connection line, will break interop with Firefox. > So I have to concur that rolling this out appears to be premature to me. > > Best > Nils Ohlmeier > > On 3Jul, 2019, at 17:58, Justin Uberti < > juberti=3D40google.com@dmarc.ietf.org> wrote: > > Hmm, that's unfortunate. I think this is a mistake, given that we are > about to throw the switch to enable mDNS for 100% of Chrome endpoints; > Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this > extension spec is written. > > ice-sip-sdp isn't published yet, so it seems an update to that document > could still be a possibility. If that's not an option, putting forth #1 a= s > a specific extension that allows FQDN candidates to be generated in certa= in > situations seems like the right path. > > > > On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: > >> Part of the problem is that mmusic have decided to punt on the FQDN >> support. In the current mmusic-ice-sip-sdp the final language that was >> included: >> >> : is taken from RFC 4566 [RFC4566]. It is the IP >> address of the candidate, allowing for IPv4 addresses, IPv6 addresses, a= nd >> fully qualified domain names (FQDNs). When parsing this field, an agent >> can differentiate an IPv4 address and an IPv6 address by presence of a >> colon in its value - the presence of a colon indicates IPv6. *An agent >> generating local candidates MUST NOT use FQDN addresses. An agent >> processing remote candidates MUST ignore candidate lines that include >> candidates with FQDN *or IP address versions that are not supported or >> recognized. *The procedures for generation and handling of FQDN >> candidates, as well as, how agents indicate support for such procedures, >> need to be specified in an extension specification.* >> >> So, at this point we have two options: >> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and >> define how FQDN candidates generated by mdns are handled >> 2. write a new draft in mmusic which defines FQDN handling >> >> In any case some sort of mmusic discussion is needed to reconcile this. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote: >> >>> The problem this draft is trying to solve is fairly RTCWEB-specific. If >>> there are individual issues to resolve, we can send them out to mmusic = for >>> discussion, but AFAIK no changes to existing ICE specs are needed. >>> >>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: >>> >>>> Hi All, >>>> >>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? >>>> This entire draft seems to be ICE/SDP specific and not limited to rtcw= eb. >>>> Also, there are significant interop implications for this draft >>>> between browser and non-browser end points which probably warrant larg= er >>>> discussion outside of rtcweb group. I would think mmusic would be a mu= ch >>>> better place for this draft. I know there is an incentive to complete = this >>>> draft quickly but this has a potential to break a lot of things (it al= ready >>>> did break interop with almost every existing ICE implementation). >>>> >>>> Regards, >>>> _____________ >>>> Roman Shpount >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --0000000000001cfe26058cd46e86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I understand it, mdns in the c=3D line will only = occur in edge cases, i.e., when there are no other candidates. As such I do= n=E2=80=99t see this as a showstopper.

We have measured the connectivity impact of this = change in significant detail and feel increasingly confident there are no e= gregious latent issues.

On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Probably not the ideal forum to point this out, but I hope the Chr= ome team is aware that rolling out this feature, assuming it includes using= mDNS in the connection line, will break interop with Firefox.
So I hav= e to concur that rolling this out appears to be premature to me.
=
Best
=C2=A0 Nils Ohlmeier

On 3Jul, 2019, at 17:58, Justin Uberti <juberti=3D= 40google.com@dmarc.ietf.org> wrote:

Hmm, that's un= fortunate. I think this is a mistake, given that we are about to throw the = switch to enable mDNS for 100% of Chrome endpoints; Chrome (and soon all br= owsers) will have to ignore ice-sip-sdp until this extension spec is writte= n.

ice-sip-sdp isn't published yet, so it seems an u= pdate to that document could still be a possibility. If that's not an o= ption, putting forth #1 as a specific extension that allows FQDN candidates= to be generated in certain situations seems like the right path.
<= br>


On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount = <roman@telurix.co= m> wrote:
Part of the problem is that mmusic have = decided to punt on the FQDN support. In the current mmusic-ice-sip-sdp the = final language that was included:

<connection-address>: =C2=A0is taken from RFC 4566 [RFC4566]= .=C2=A0 It is the IP address of the candidate, allowing for IPv4 addresses,= IPv6 addresses, and fully qualified domain names (FQDNs).=C2=A0 When parsi= ng=C2=A0this field, an agent can differentiate an IPv4 address and an IPv6= =C2=A0address by presence of a colon in its value - the presence of a=C2=A0= colon indicates IPv6. =C2=A0An agent generating local candidates MUST=C2= =A0NOT use FQDN addresses.=C2=A0 An agent processing remote candidates=C2= =A0MUST ignore candidate lines that include candidates with FQDN or=C2= =A0IP address versions that are not supported or recognized. =C2=A0The= =C2=A0procedures for generation and handling of FQDN candidates, as well=C2= =A0as, how agents indicate support for such procedures, need to be=C2=A0spe= cified in an extension specification.

So, at this point we have two options:=C2=A0
1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp= and define how FQDN candidates generated by mdns are handled
2. = write a new draft in mmusic which defines FQDN handling

In any case some sort of mmusic discussion is needed to reconcile thi= s.

Best Regards,
_____________
Roman Shpount


On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <juberti@google.com> wrote:<= br>
The problem this draft is trying to solve is fairly RTCWEB-specific. If th= ere are individual issues to resolve, we can send them out to mmusic=C2=A0f= or discussion, but AFAIK no changes to existing ICE specs are needed.
=
On Wed= , Jul 3, 2019 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
H= i All,

Is rtcweb the right= place for draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems t= o be ICE/SDP specific and not limited to rtcweb. Also, there are significan= t interop implications for this draft between=C2=A0browser and non-browser = end points which probably warrant larger discussion outside of rtcweb group= . I would think mmusic would be a much better place for this draft. I know = there is an incentive to complete this draft quickly but this has a potenti= al to break a lot of things (it already did break interop with almost every= existing ICE implementation).

Regards,
_____________=
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

--0000000000001cfe26058cd46e86-- From nobody Wed Jul 3 23:08:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1AC120128 for ; Wed, 3 Jul 2019 23:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmLgjesbI7nS for ; Wed, 3 Jul 2019 23:08:35 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A79120111 for ; Wed, 3 Jul 2019 23:08:34 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id v24so4881966ljg.13 for ; Wed, 03 Jul 2019 23:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bkVGGmJ0XaXsPy5xTHud+Jf4tqP0tcFdk41etIPmv2U=; b=UmvvyTQRI7lBuoQTYWiPIFMtEOrjoOfkwGBdoDGU6DOVxys3Ikr8IpVBqzLLBFle2U lipRqq4J5vK17LJuB4Hvehk6PlRKZ8DDmLA50UDF3CKyIaxdr8dm0Z5NlNHhBMMbOfOQ uqIko9XzIsbhuDC6Am/F1Sbq4dGp8LaYDYEQwOHYAbQYzRjx3m89n3Vbz7n+8NU2wSHR hazKCpvCZ7/ZuY52KkVYNzKp3HoUEMv1Gl+kp8wlEe2F4b/J4YOD7DOOymNRdV+X6yMP vai7LfSTuBe3xpWA0Fh+caxCQiwQvpXMPFbfm/yZ2jY9wsejrmWOGPUTSDUGqZxBmW3D 6vNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bkVGGmJ0XaXsPy5xTHud+Jf4tqP0tcFdk41etIPmv2U=; b=fwka1gHPMd0NW5jkpvvhZ7QfLfh/1nok80M/ZcKM/M7+FKxxkTmLotQ0/Zh/g8PEBQ L1xJp+/RNN+PNIb6+HPHR6W4xomDCi1EC1EiHuFwOXKH9zGC6R19h+liW6a8DYyp7R3O +bvyKJHubvnrx/qjN7LjBSBba5zh2rykvRkBW8UGEGxIlrdEwu9oRASI90/rC+C7Ktr6 8Z9T62FQgrk7ypDEJe+wYrGnbX3WRAg4xWjBx+OXnfX84sbBUueqNsVP868c1yxz33wZ cg+D0KiKZ7lcn3GEdnQYDQ7VpO3sq/RJ0rRtQe/Ey7MGNpBuSDUN3bkUIk/T3kUDMY3+ iZmA== X-Gm-Message-State: APjAAAWk0c8pByQ+hYFCF/zL0xG2zL58KUMxSB7bML2mWknhoXB80zwT bFK0QBG9M2wnHapfiZGT2pwK16YGWU+kGS5HT4M= X-Google-Smtp-Source: APXvYqwKb+tKnkHyAsNAplwezvHXOke8aqs8kKmw4k9ghDrNVo3xsvsSP35IqvWBC9MY/9qutpCqDhWAabpTP/wh/LI= X-Received: by 2002:a2e:124c:: with SMTP id t73mr23184837lje.190.1562220512391; Wed, 03 Jul 2019 23:08:32 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> In-Reply-To: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> From: Bernard Aboba Date: Wed, 3 Jul 2019 23:08:38 -0700 Message-ID: To: Nils Ohlmeier Cc: Justin Uberti , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b3b9f0058cd4cefc" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 06:08:38 -0000 --000000000000b3b9f0058cd4cefc Content-Type: text/plain; charset="UTF-8" Nils said: "assuming it includes using mDNS in the connection line, will break interop" [BA] Can someone provide a legacy citation relating to FQDNs in the connection line? I am struggling to find one. draft-ietf-mmusic-rfc4566bis Section 5.7 only talks about IPv4 and IPv6 addresses. I do not see mention of FQDNs. draft-ietf-mmusic-ice-sip-sdp does not mention FQDNs in the "c=" line and all examples show IPv4 or IPv6 addresses. RFC 3264 does not mention FQDNs in c= lines in the text, although it uses FQDNs within examples (such as Sections 10.1 and 10.2). JSEP does not mention FQDNs in "c=" lines as far as I can tell. Also in these documents, I do not see instructions on how a legacy implementation should gracefully react to FQDNs in the connection line (e.g. ignoring it). On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier wrote: > Probably not the ideal forum to point this out, but I hope the Chrome team > is aware that rolling out this feature, assuming it includes using mDNS in > the connection line, will break interop with Firefox. > So I have to concur that rolling this out appears to be premature to me. > > Best > Nils Ohlmeier > > On 3Jul, 2019, at 17:58, Justin Uberti < > juberti=40google.com@dmarc.ietf.org> wrote: > > Hmm, that's unfortunate. I think this is a mistake, given that we are > about to throw the switch to enable mDNS for 100% of Chrome endpoints; > Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this > extension spec is written. > > ice-sip-sdp isn't published yet, so it seems an update to that document > could still be a possibility. If that's not an option, putting forth #1 as > a specific extension that allows FQDN candidates to be generated in certain > situations seems like the right path. > > > > On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: > >> Part of the problem is that mmusic have decided to punt on the FQDN >> support. In the current mmusic-ice-sip-sdp the final language that was >> included: >> >> : is taken from RFC 4566 [RFC4566]. It is the IP >> address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and >> fully qualified domain names (FQDNs). When parsing this field, an agent >> can differentiate an IPv4 address and an IPv6 address by presence of a >> colon in its value - the presence of a colon indicates IPv6. *An agent >> generating local candidates MUST NOT use FQDN addresses. An agent >> processing remote candidates MUST ignore candidate lines that include >> candidates with FQDN *or IP address versions that are not supported or >> recognized. *The procedures for generation and handling of FQDN >> candidates, as well as, how agents indicate support for such procedures, >> need to be specified in an extension specification.* >> >> So, at this point we have two options: >> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and >> define how FQDN candidates generated by mdns are handled >> 2. write a new draft in mmusic which defines FQDN handling >> >> In any case some sort of mmusic discussion is needed to reconcile this. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote: >> >>> The problem this draft is trying to solve is fairly RTCWEB-specific. If >>> there are individual issues to resolve, we can send them out to mmusic for >>> discussion, but AFAIK no changes to existing ICE specs are needed. >>> >>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: >>> >>>> Hi All, >>>> >>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? >>>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb. >>>> Also, there are significant interop implications for this draft >>>> between browser and non-browser end points which probably warrant larger >>>> discussion outside of rtcweb group. I would think mmusic would be a much >>>> better place for this draft. I know there is an incentive to complete this >>>> draft quickly but this has a potential to break a lot of things (it already >>>> did break interop with almost every existing ICE implementation). >>>> >>>> Regards, >>>> _____________ >>>> Roman Shpount >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000b3b9f0058cd4cefc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nils said:=C2=A0

"assuming it incl= udes using mDNS in the connection line, will break interop"
=
[BA]=C2=A0 Can someone provide a legacy citation relating to= FQDNs in the connection line?=C2=A0 I am struggling to find one.=C2=A0

draft-ietf-mmusic-rfc4566bis=C2=A0 Section 5.7 only tal= ks about IPv4 and IPv6 addresses.=C2=A0 I do not see mention of FQDNs.=C2= =A0

draft-ietf-mmusic-ice-sip-sdp does not mention= FQDNs in the "c=3D" line and all examples show IPv4 or IPv6 addr= esses.=C2=A0

RFC 3264 does not mention FQDNs in c= =3D lines in the text, although it uses FQDNs within examples (such as Sect= ions 10.1 and 10.2).=C2=A0=C2=A0

JSEP does not= mention FQDNs in "c=3D" lines as far as I can tell.=C2=A0
<= div>
Also in these documents, I do not see instructions on ho= w a legacy implementation should gracefully react to FQDNs in the connectio= n line (e.g. ignoring it).=C2=A0

=
On Wed, Jul 3, 2019 at 9:50 PM Nils O= hlmeier <nohlmeier@mozilla.com<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">Probably not the ideal forum to po= int this out, but I hope the Chrome team is aware that rolling out this fea= ture, assuming it includes using mDNS in the connection line, will break in= terop with Firefox.
So I have to concur that rolling this out appears t= o be premature to me.

Best
=C2=A0 Nils O= hlmeier


Hmm, that's unfortunate. I think this is a mist= ake, given that we are about to throw the switch to enable mDNS for 100% of= Chrome endpoints; Chrome (and soon all browsers) will have to ignore ice-s= ip-sdp until this extension spec is written.

ice-sip-sdp= isn't published yet, so it seems an update to that document could stil= l be a possibility. If that's not an option, putting forth #1 as a spec= ific extension that allows FQDN candidates to be generated in certain situa= tions seems like the right path.



On = Wed, Jul 3, 2019 at 5:40 PM Roman Shpount <roman@telurix.com> wrote:
Part of the problem is that mmusic have decided to punt on the FQDN suppo= rt. In the current mmusic-ice-sip-sdp the final language that was included:=

<connection-address>= ;: =C2=A0is taken from RFC 4566 [RFC4566].=C2=A0 It is the IP address of th= e candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualifi= ed domain names (FQDNs).=C2=A0 When parsing=C2=A0this field, an agent can d= ifferentiate an IPv4 address and an IPv6=C2=A0address by presence of a colo= n in its value - the presence of a=C2=A0colon indicates IPv6. =C2=A0An a= gent generating local candidates MUST=C2=A0NOT use FQDN addresses.=C2=A0 An= agent processing remote candidates=C2=A0MUST ignore candidate lines that i= nclude candidates with FQDN or=C2=A0IP address versions that are not su= pported or recognized. =C2=A0The=C2=A0procedures for generation and hand= ling of FQDN candidates, as well=C2=A0as, how agents indicate support for s= uch procedures, need to be=C2=A0specified in an extension specification.

So, at this point we= have two options:=C2=A0
1. draft-ietf-rtcweb-mdns-ic= e-candidates can update ice-sip-sdp and define how FQDN candidates generate= d by mdns are handled
2. write a new draft in mmusic which define= s FQDN handling

In any case some sort of mmusic di= scussion is needed to reconcile this.

Best Regards= ,
_____________
Roman Shpount


On Wed, Jul 3, 2019 at = 8:28 PM Justin Uberti <juberti@google.com> wrote:
The problem this draft is trying = to solve is fairly RTCWEB-specific. If there are individual issues to resol= ve, we can send them out to mmusic=C2=A0for discussion, but AFAIK no change= s to existing ICE specs are needed.

On Wed, Jul 3, 2019 at 4:26 PM Roman Shp= ount <roman@telur= ix.com> wrote:
Hi All,

<= /div>
Is rtcweb the right place for draft-ietf-rtcweb-mdns-= ice-candidates? This entire draft seems to be ICE/SDP specific and not limi= ted to rtcweb. Also, there are significant interop implications for this dr= aft between=C2=A0browser and non-browser end points which probably warrant = larger discussion outside of rtcweb group. I would think mmusic would be a = much better place for this draft. I know there is an incentive to complete = this draft quickly but this has a potential to break a lot of things (it al= ready did break interop with almost every existing ICE implementation).

Regards,
_____________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000b3b9f0058cd4cefc-- From nobody Thu Jul 4 03:54:46 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9731201E0 for ; Thu, 4 Jul 2019 03:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 3o3yXOUxESiL for ; Thu, 4 Jul 2019 03:54:42 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09210120183 for ; Thu, 4 Jul 2019 03:54:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1D37F7C39F5; Thu, 4 Jul 2019 12:54:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIJXRu4lPPom; Thu, 4 Jul 2019 12:54:35 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 87FDE7C36FB; Thu, 4 Jul 2019 12:54:35 +0200 (CEST) To: Sean Turner Cc: "rtcweb@ietf.org" References: From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <02b5b7c2-dde2-6ff0-06fa-bcaf10a0030b@alvestrand.no> Date: Thu, 4 Jul 2019 12:54:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Request for status update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 10:54:45 -0000 Den 04.07.2019 01:13, skrev Sean Turner: > A fair question Harald. Here’s the status of the WGs as of today: > > draft-ietf-rtcweb-ip-handling: New version spun yesterday. Awaiting Adam’s concurrence on one change, then he will get state moved to approved. > > draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch: Held a conference call with Ben, Ted, ekr, and myself to address Ben’s discusses and comments. ekr filed new issues and needs to generate some PRs. Once a new version is spun, Ben, Adam, and I will review and hopefully we’re done with these two drafts. > > draft-ietf-rtcweb-fec: I am getting emails now from GitHub showing Justin is diligently working through the outstanding comments. I hope a revised draft will hit tonight or no later than Monday’s submission deadline. > > draft-ietf-rtcweb-mdns-ice-candidates: It is my understanding that Adam is going to AD sponsor this one, but not until the other four move on. Thank you! So we're "in progress" on ip-handling, security and fec, and mdns is waiting for the others (but I don't think it blocks the others, so while it's needed for Real Life, it's not needed for the formalities). Can you assure me that -4566bis, -clue-protocol, -rmcat-eval-criteria and -ice-sip-sdp are not blockers for pushing out the rest of the 238 cluster? > > spt > >> On Jul 3, 2019, at 03:23, Harald Alvestrand wrote: >> >> WG chairs - can you give the WG a status update on the WG's documents? >> >> As far as I can tell from >> https://www.rfc-editor.org/cluster_info.php?cid=C238 the critical pieces >> not in the RFC Editor queue are still the security documents and FEC, >> but -4566bis, -clue-protocol, -rmcat-eval-criteria and -ice-sip-sdp are >> also listed. >> >> What is the status of these documents? >> >> Are there others? >> >> At the moment, the responsibility of the chairs is (in my opinion) to >> make sure publication happens. It's been a while. >> >> Harald >> >> -- >> Surveillance is pervasive. Go Dark. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Jul 4 08:12:45 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252D312013C for ; Thu, 4 Jul 2019 08:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZzth8riQ_fn for ; Thu, 4 Jul 2019 08:12:39 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 5CC3612011A for ; Thu, 4 Jul 2019 08:12:38 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id c4so1237358uad.1 for ; Thu, 04 Jul 2019 08:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iv1GLuA0y4HBHw0g1dT8D2ofnsJQ2wBdYd1z2pQ8Kfo=; b=Oolp7ZPdNVyF87CrdJ5MD3vMFiIo/n1djMAL6sZVgndt+br9KynqASs7U+yj0W9RtB TlVqNw3Toz48/j917oGhNsTfIyKmtRbvoR+GlZeVOHOipT9fVbKepHOOuKWy4nVw8t/B N+RAu2v999kVNeokbPIo1APEEd257z9VQ4QLiHmi0N1WHc0knfBVJFCpPb8O8xXRWdgH voY2r1sDhH6KQVJBc0bq2+v9jL/Pp67oTYngqD12R5JkSlW8HS0BoVO7mbYaGaQ+HFaK LjyXVFmz677G1GVBDGnQNDAmQlP9lNxU5cpkjZTWCCPbQ+1VsynrXijKTnQ0TCZxDzMs EP/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iv1GLuA0y4HBHw0g1dT8D2ofnsJQ2wBdYd1z2pQ8Kfo=; b=mqi8ahjriubcbGvdZPGbEX+On7M3SGTxV4ocBdNWKWjB7tpXE3kfxf6VrDwBGKDnAv 63v5FRWtUegaSYOrUZLXmvcPoicPLfPOBy3VxASjRQpf6O2rNV27xSz5WCuWlj+PqzrN qD7lUOY/J4vKCAqKERudgnqdtX1uJCckqH/A/wajbiZaJC5C6QK/OapKyNIhkszSxog9 ZtFv+a6s9hhuE3oUsvXRR88D98B2aWj6fTU/B54P1XX+s9fyYSlvSR99VVSLJtTOymmo FWUz4S/nmU9BG1hh43k5/WuTCwlk0qI5/iCbsiFlhk/mO0Y+JCa7Do/V8pQ1WiD7sX3o VVdg== X-Gm-Message-State: APjAAAXb7ew+X2TLZopJFaKh8UiCKlUf+niJvHAP71Evy9EIDr0AzVce a7zGKKKFj5NpdcmJ34BszRe9881hrw8dSggePozWww== X-Google-Smtp-Source: APXvYqwB6Np5eJQED1urtFmlPAZ9aiwgv1ViA8dNEGKGoW1muA36IjIRsjKsKnCKW+ORq1YCXyoQECoNNVr2aMBZPyU= X-Received: by 2002:ab0:6198:: with SMTP id h24mr16187094uan.41.1562253157231; Thu, 04 Jul 2019 08:12:37 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> In-Reply-To: From: Justin Uberti Date: Thu, 4 Jul 2019 08:12:25 -0700 Message-ID: To: Bernard Aboba Cc: Nils Ohlmeier , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007cd40c058cdc6851" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 15:12:43 -0000 --0000000000007cd40c058cdc6851 Content-Type: text/plain; charset="UTF-8" https://tools.ietf.org/html/rfc4566#section-9 ; sub-rules of 'c=' connection-address = multicast-address / unicast-address ... unicast-address = IP4-address / IP6-address / FQDN / extn-addr On Wed, Jul 3, 2019 at 11:08 PM Bernard Aboba wrote: > Nils said: > > "assuming it includes using mDNS in the connection line, will break > interop" > > [BA] Can someone provide a legacy citation relating to FQDNs in the > connection line? I am struggling to find one. > > draft-ietf-mmusic-rfc4566bis > Section 5.7 > only talks about IPv4 and IPv6 addresses. I do not see mention of FQDNs. > > draft-ietf-mmusic-ice-sip-sdp does not mention FQDNs in the "c=" line and > all examples show IPv4 or IPv6 addresses. > > RFC 3264 does not mention FQDNs in c= lines in the text, although it uses > FQDNs within examples (such as Sections 10.1 and 10.2). > > JSEP does not mention FQDNs in "c=" lines as far as I can tell. > > Also in these documents, I do not see instructions on how a legacy > implementation should gracefully react to FQDNs in the connection line > (e.g. ignoring it). > > On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier > wrote: > >> Probably not the ideal forum to point this out, but I hope the Chrome >> team is aware that rolling out this feature, assuming it includes using >> mDNS in the connection line, will break interop with Firefox. >> So I have to concur that rolling this out appears to be premature to me. >> >> Best >> Nils Ohlmeier >> >> On 3Jul, 2019, at 17:58, Justin Uberti < >> juberti=40google.com@dmarc.ietf.org> wrote: >> >> Hmm, that's unfortunate. I think this is a mistake, given that we are >> about to throw the switch to enable mDNS for 100% of Chrome endpoints; >> Chrome (and soon all browsers) will have to ignore ice-sip-sdp until this >> extension spec is written. >> >> ice-sip-sdp isn't published yet, so it seems an update to that document >> could still be a possibility. If that's not an option, putting forth #1 as >> a specific extension that allows FQDN candidates to be generated in certain >> situations seems like the right path. >> >> >> >> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: >> >>> Part of the problem is that mmusic have decided to punt on the FQDN >>> support. In the current mmusic-ice-sip-sdp the final language that was >>> included: >>> >>> : is taken from RFC 4566 [RFC4566]. It is the IP >>> address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and >>> fully qualified domain names (FQDNs). When parsing this field, an agent >>> can differentiate an IPv4 address and an IPv6 address by presence of a >>> colon in its value - the presence of a colon indicates IPv6. *An agent >>> generating local candidates MUST NOT use FQDN addresses. An agent >>> processing remote candidates MUST ignore candidate lines that include >>> candidates with FQDN *or IP address versions that are not supported or >>> recognized. *The procedures for generation and handling of FQDN >>> candidates, as well as, how agents indicate support for such procedures, >>> need to be specified in an extension specification.* >>> >>> So, at this point we have two options: >>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and >>> define how FQDN candidates generated by mdns are handled >>> 2. write a new draft in mmusic which defines FQDN handling >>> >>> In any case some sort of mmusic discussion is needed to reconcile this. >>> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote: >>> >>>> The problem this draft is trying to solve is fairly RTCWEB-specific. If >>>> there are individual issues to resolve, we can send them out to mmusic for >>>> discussion, but AFAIK no changes to existing ICE specs are needed. >>>> >>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote: >>>> >>>>> Hi All, >>>>> >>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? >>>>> This entire draft seems to be ICE/SDP specific and not limited to rtcweb. >>>>> Also, there are significant interop implications for this draft >>>>> between browser and non-browser end points which probably warrant larger >>>>> discussion outside of rtcweb group. I would think mmusic would be a much >>>>> better place for this draft. I know there is an incentive to complete this >>>>> draft quickly but this has a potential to break a lot of things (it already >>>>> did break interop with almost every existing ICE implementation). >>>>> >>>>> Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --0000000000007cd40c058cdc6851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
https://tools.ietf.org/=
html/rfc4566#section-9
; sub-rules of 'c=3D=
9;
connection-address =3D  multicas=
t-address / unicast-address
...
unicast-address=
 =3D     IP4-address / IP6-address / FQDN / extn-addr

On Wed, Jul 3, 2= 019 at 11:08 PM Bernard Aboba <bernard.aboba@gmail.com> wrote:
Nils said:=C2=A0

"assuming it includes using mDNS in the connection line, will break= interop"

[BA]=C2=A0 Can someone provide a le= gacy citation relating to FQDNs in the connection line?=C2=A0 I am struggli= ng to find one.=C2=A0

draft-ietf-mmusi= c-rfc4566bis=C2=A0 Section 5.7 only talks about IPv4 and IPv6 addresses= .=C2=A0 I do not see mention of FQDNs.=C2=A0

draft= -ietf-mmusic-ice-sip-sdp does not mention FQDNs in the "c=3D" lin= e and all examples show IPv4 or IPv6 addresses.=C2=A0

<= div>RFC 3264 does not mention FQDNs in c=3D lines in the text, although it = uses FQDNs within examples (such as Sections 10.1 and 10.2).=C2=A0=C2=A0

JSEP does not mention FQDNs in "c=3D" = lines as far as I can tell.=C2=A0

Also in these do= cuments, I do not see instructions on how a legacy implementation should gr= acefully react to FQDNs in the connection line (e.g. ignoring it).=C2=A0

On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Probably not = the ideal forum to point this out, but I hope the Chrome team is aware that= rolling out this feature, assuming it includes using mDNS in the connectio= n line, will break interop with Firefox.
So I have to concur that rolli= ng this out appears to be premature to me.

Best
=C2=A0 Nils Ohlmeier

<= div>On 3Jul, 2019, at 17:58, Justin Uberti <juberti=3D40google.com@dmarc= .ietf.org> wrote:

Hmm= , that's unfortunate. I think this is a mistake, given that we are abou= t to throw the switch to enable mDNS for 100% of Chrome endpoints; Chrome (= and soon all browsers) will have to ignore ice-sip-sdp until this extension= spec is written.

ice-sip-sdp isn't published yet, s= o it seems an update to that document could still be a possibility. If that= 's not an option, putting forth #1 as a specific extension that allows = FQDN candidates to be generated in certain situations seems like the right = path.



On Wed, Jul 3, 2019 at 5:40 PM= Roman Shpount <r= oman@telurix.com> wrote:
Part of the problem is th= at mmusic have decided to punt on the FQDN support. In the current mmusic-i= ce-sip-sdp the final language that was included:

=
<connection-address>: =C2=A0is taken from RFC = 4566 [RFC4566].=C2=A0 It is the IP address of the candidate, allowing for I= Pv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs).=C2= =A0 When parsing=C2=A0this field, an agent can differentiate an IPv4 addres= s and an IPv6=C2=A0address by presence of a colon in its value - the presen= ce of a=C2=A0colon indicates IPv6. =C2=A0An agent generating local candi= dates MUST=C2=A0NOT use FQDN addresses.=C2=A0 An agent processing remote ca= ndidates=C2=A0MUST ignore candidate lines that include candidates with FQDN= or=C2=A0IP address versions that are not supported or recognized. =C2= =A0The=C2=A0procedures for generation and handling of FQDN candidates, a= s well=C2=A0as, how agents indicate support for such procedures, need to be= =C2=A0specified in an extension specification.

So, at this point we have two options:=C2=A0
1. draft-ietf-rtcweb-mdns-ice-candidates can update ic= e-sip-sdp and define how FQDN candidates generated by mdns are handled
2. write a new draft in mmusic which defines FQDN handling
=
In any case some sort of mmusic discussion is needed to reco= ncile this.

Best Regards,
_____________
Roman Shpount


On Wed, Jul 3, 2019 = at 8:28 PM Justin Uberti <juberti@google.com> wrote:
The problem this draft is tr= ying to solve is fairly RTCWEB-specific. If there are individual issues to = resolve, we can send them out to mmusic=C2=A0for discussion, but AFAIK no c= hanges to existing ICE specs are needed.

On Wed, Jul 3, 2019 at 4:26 PM Roma= n Shpount <roman@= telurix.com> wrote:
Hi All,
=
Is rtcweb the right place for draft-ietf-rtcweb-= mdns-ice-candidates? This entire draft seems to be ICE/SDP specific and not= limited to rtcweb. Also, there are significant interop implications for th= is draft between=C2=A0browser and non-browser end points which probably war= rant larger discussion outside of rtcweb group. I would think mmusic would = be a much better place for this draft. I know there is an incentive to comp= lete this draft quickly but this has a potential to break a lot of things (= it already did break interop with almost every existing ICE implementation)= .

Regards,
_________= ____
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000007cd40c058cdc6851-- From nobody Thu Jul 4 11:47:15 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32732120167 for ; Thu, 4 Jul 2019 11:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gh6iXJFPWr8a for ; Thu, 4 Jul 2019 11:47:10 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 B4DE5120141 for ; Thu, 4 Jul 2019 11:47:10 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id b7so3448705pls.6 for ; Thu, 04 Jul 2019 11:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IMEiTCU6RPYS/MJZvjUQw/512UONGY5mRxFsRS/M47o=; b=vIeWQK6QTEOJX+77vcDbPTf/ugYwguSmX+c4F9fAL6d0Nle/KeMJXFeKWxrzV6cm5y sbGydZkPRj8j7HwdXIOEhCzk180gUo+gsykixNxhy7h7Bwg147a4GRdX+SQa9mk3Kxw8 9DMNcZyn4hpMmrh4USrRPVoxosQyCeYlslNo6kJ2uaUG18hpIS1rzeFgp7DDNN/kleNi xuubol/qmPigPPDiBPN4Ilk/3YwIYa6cSP6Q+st+kbFB08eijd31PgI8IjpV/nunccQt olMJH0cXhksYE6+cCT58K8RStovrQR8zWoEGlBHhduAPxBlACv4Zvnt74D7bmtE/T2gb ZGFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IMEiTCU6RPYS/MJZvjUQw/512UONGY5mRxFsRS/M47o=; b=bHt2vz8TF10aXw9lF2BqjpTr0/t9/c23mdOoCBKrjoT4Qne3eQqEbtUgD9Te8vQgF+ In/fxRAauWa6+AyxEGbUNUp+ALexWtjdO63A4IsPjVSOfeAWzeoX0+3cvKAD6XCDlw8i 6OIr1Gs+1pnupyfDP/bm5/EU6ndFTAGSPLJ6BIeJP5aUdexh5duVrrQevXFJ6Rv2WeqZ CF3+XONz8KZ1mU6kgxxwINucC3CpmuHkVy7DzqlVDH8W1l884zEpEfIgPvX0WOEI/PGa AWfdgFKVc/GgCBOqXRGoQtBmcD7CjuYF7GRl9vEGtw+fuO8gl9ebIqn3h1u57UCAOZHT rFiA== X-Gm-Message-State: APjAAAVIL0GNUBnpDAl5ANBwuKQD+/CX0cWTktgDzOpZyERBNpdhHT6A 6RR9NpDVjsnm6bxXcRODPCoO6ASCrd8= X-Google-Smtp-Source: APXvYqyNnxbfBksbhmMriT9ZOTilc4ACl3AlF1piiGhxWEizfDn0Si38VY3FrPXMFic550jrJzf/EA== X-Received: by 2002:a17:902:da4:: with SMTP id 33mr46624678plv.209.1562266029480; Thu, 04 Jul 2019 11:47:09 -0700 (PDT) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com. [209.85.214.171]) by smtp.gmail.com with ESMTPSA id v184sm6900691pfb.82.2019.07.04.11.47.08 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 11:47:08 -0700 (PDT) Received: by mail-pl1-f171.google.com with SMTP id w24so3441913plp.2 for ; Thu, 04 Jul 2019 11:47:08 -0700 (PDT) X-Received: by 2002:a17:902:20c8:: with SMTP id v8mr51005856plg.284.1562266028068; Thu, 04 Jul 2019 11:47:08 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> In-Reply-To: From: Roman Shpount Date: Thu, 4 Jul 2019 14:46:59 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Nils Ohlmeier , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a5d44d058cdf6742" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 18:47:13 -0000 --000000000000a5d44d058cdf6742 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The FQDN in c=3D line and candidate address where in specs for a really lon= g time (RFC 4566 and RFC 5245 both define them). This being said, FQDN in c= =3D line was very infrequently used and FQDN in ICE candidate was never used. FQDN in ICE candidate was badly under defined and due to limited use there is no established practice on how it should work. Using FQDN for mDNS ICE candidates, as far as I know, is the first wide spread use of FQDN in ICE candidates. Almost every ICE implementation outside of Chrome was never tested against FQDN in c=3D lines and ICE candidates and likely would have issues. As it stands, ice-sip-sdp does not contradict using FQDN in ICE candidates, but is specifically leaves a big hole in the document regarding how exactly offers with FQDN are generated and how FQDN candidates are supposed to be processed. The only thing current draft defines is absolute minimum of what end point needs to do when receiving a session description with FQDN candidates and safely ignoring them.Things like FQDN resolution procedures, procedures for adding resolution results to the candidate list, and what is supposed to go into the c=3D line for FQDN default candidate were deliberately left out for the future document. If anybody wants to use FQDN in ICE candidates, these things need to be defined and verified to cause minimal disruption when deployed against existing end points. Since ICE and ICE session description related issues are normally discussed in mmusic, it probably should happen there to reach the proper audience. I understand that running experiments before proposing a solution is probably a good thing and this is what Chrome was doing up until this point. At the same time, rolling this feature into production before at least documenting it, will definitely cause interop problems. What we have now is a fairly major feature with a fairly outdated specification where all the interop issues weren't considered. As far as connectivity impact of Chrome experiment goes, we do see it causing issues with at least two scenarios: 1. Listen only connections to SBC/Media servers on public IP: We have a set of services which run SBC or Media Servers on public IPs with ICE TCP enabled. These services did not use STUN or TURN servers, since all the communications are between the browser end point and the server on public IP. In cases when microphone is not present on the client computer or client denies microphone access, client is still offered to connect in listen only mode. In this scenario, we ended up with FQDN in the c=3D line and only FQDN based candidates. As a quick work around we added STUN server, but this, in addition to slowing down the connection time, still prevented connections from hosts where UDP was blocked. We had to update software used to run our hosted services to support FQDN in c=3D line and I= CE candidates (which was actually done as a regex replacement). Our software which is installed at client premises is still not updated and will likely take our clients another 6 months to a year to update. As far as we could see, before update, 2-3% of all listen only connections where affected. This is not a huge number but caused customer complaints from clients who were able to connect before the experiment started. 2. Peer-to-peer connections within enterprise: We are working with a peer-to-peer web casting solution for webinars. We see the connectivity rate reduction within large enterprises, where IP based connection between two private IP is allowed but client browsers are not withing the same broadcast domain. In this case mDNS connectivity check fails when direct IP connectivity check would succeed. In these cases webcast client switches to streaming from the server, so this does no result in total failure but does decrease the P2P network efficiency. Having an ability to ask for Peer-to-Peer connectivity permission would really help in this case. Best Regards, _____________ Roman Shpount On Thu, Jul 4, 2019 at 1:41 AM Justin Uberti wrote: > As I understand it, mdns in the c=3D line will only occur in edge cases, > i.e., when there are no other candidates. As such I don=E2=80=99t see thi= s as a > showstopper. > > We have measured the connectivity impact of this change in significant > detail and feel increasingly confident there are no egregious latent issu= es. > > On Wed, Jul 3, 2019 at 9:50 PM Nils Ohlmeier > wrote: > >> Probably not the ideal forum to point this out, but I hope the Chrome >> team is aware that rolling out this feature, assuming it includes using >> mDNS in the connection line, will break interop with Firefox. >> So I have to concur that rolling this out appears to be premature to me. >> >> Best >> Nils Ohlmeier >> >> On 3Jul, 2019, at 17:58, Justin Uberti < >> juberti=3D40google.com@dmarc.ietf.org> wrote: >> >> Hmm, that's unfortunate. I think this is a mistake, given that we are >> about to throw the switch to enable mDNS for 100% of Chrome endpoints; >> Chrome (and soon all browsers) will have to ignore ice-sip-sdp until thi= s >> extension spec is written. >> >> ice-sip-sdp isn't published yet, so it seems an update to that document >> could still be a possibility. If that's not an option, putting forth #1 = as >> a specific extension that allows FQDN candidates to be generated in cert= ain >> situations seems like the right path. >> >> >> >> On Wed, Jul 3, 2019 at 5:40 PM Roman Shpount wrote: >> >>> Part of the problem is that mmusic have decided to punt on the FQDN >>> support. In the current mmusic-ice-sip-sdp the final language that was >>> included: >>> >>> : is taken from RFC 4566 [RFC4566]. It is the IP >>> address of the candidate, allowing for IPv4 addresses, IPv6 addresses, = and >>> fully qualified domain names (FQDNs). When parsing this field, an agen= t >>> can differentiate an IPv4 address and an IPv6 address by presence of a >>> colon in its value - the presence of a colon indicates IPv6. *An agent >>> generating local candidates MUST NOT use FQDN addresses. An agent >>> processing remote candidates MUST ignore candidate lines that include >>> candidates with FQDN *or IP address versions that are not supported or >>> recognized. *The procedures for generation and handling of FQDN >>> candidates, as well as, how agents indicate support for such procedures= , >>> need to be specified in an extension specification.* >>> >>> So, at this point we have two options: >>> 1. draft-ietf-rtcweb-mdns-ice-candidates can update ice-sip-sdp and >>> define how FQDN candidates generated by mdns are handled >>> 2. write a new draft in mmusic which defines FQDN handling >>> >>> In any case some sort of mmusic discussion is needed to reconcile this. >>> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Wed, Jul 3, 2019 at 8:28 PM Justin Uberti wrote= : >>> >>>> The problem this draft is trying to solve is fairly RTCWEB-specific. I= f >>>> there are individual issues to resolve, we can send them out to mmusic= for >>>> discussion, but AFAIK no changes to existing ICE specs are needed. >>>> >>>> On Wed, Jul 3, 2019 at 4:26 PM Roman Shpount wrote= : >>>> >>>>> Hi All, >>>>> >>>>> Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? >>>>> This entire draft seems to be ICE/SDP specific and not limited to rtc= web. >>>>> Also, there are significant interop implications for this draft >>>>> between browser and non-browser end points which probably warrant lar= ger >>>>> discussion outside of rtcweb group. I would think mmusic would be a m= uch >>>>> better place for this draft. I know there is an incentive to complete= this >>>>> draft quickly but this has a potential to break a lot of things (it a= lready >>>>> did break interop with almost every existing ICE implementation). >>>>> >>>>> Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>>> >>>> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> --000000000000a5d44d058cdf6742 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The FQDN in c=3D line and candidate addre= ss where in specs for a really long time (RFC 4566 and RFC 5245 both define= them). This being said, FQDN in c=3D line was very infrequently used and F= QDN in ICE candidate was never used. FQDN in ICE candidate was badly under = defined and due to limited use there is no established practice on how it s= hould work. Using FQDN for mDNS ICE candidates, as far as I know, is the fi= rst wide spread use of FQDN in ICE candidates. Almost every ICE implementat= ion outside of Chrome was never tested against FQDN in c=3D lines and ICE c= andidates and likely would have issues.

As it stands, ice-sip-sdp does not contradict using FQDN in I= CE candidates, but is specifically leaves a big hole in the document regard= ing how exactly offers with FQDN are generated and how FQDN candidates are = supposed to be processed. The only thing current draft defines is absolute = minimum of what end point needs to do when receiving a session description = with FQDN candidates and safely ignoring them.Things like FQDN resolution p= rocedures, procedures for adding resolution results to the candidate list, = and what is supposed to go into the c=3D line for FQDN default candidate we= re deliberately left out for the future document. If anybody wants to use F= QDN in ICE candidates, these things need to be defined and verified to caus= e minimal disruption when deployed against existing end points. Since ICE a= nd ICE session description related issues are normally discussed in mmusic,= it probably should happen there to reach the proper audience.

I understand that running experiments before propo= sing a solution is probably a good thing and this is what Chrome was doing = up until this point. At the same time, rolling this feature into production= before at least documenting it, will definitely cause interop problems. Wh= at we have now is a fairly major feature with a fairly outdated specificati= on where all the interop issues weren't considered.

As far as connectivity impact of Chrome experiment goes, we do see it= causing issues with at least two scenarios:

1. Li= sten only connections to SBC/Media servers on public IP: We have a set of s= ervices which run SBC or Media Servers on public IPs with ICE TCP enabled. = These services did not use STUN or TURN servers, since all the communicatio= ns are between the browser end point and the server on public IP. In cases = when microphone is not present on the client computer or client denies micr= ophone access, client is still offered to connect in listen only mode. In t= his scenario, we ended up with FQDN in the c=3D line and only FQDN based ca= ndidates. As a quick work around we added STUN server, but this, in additio= n to slowing down the connection time, still prevented connections from hos= ts where UDP was blocked. We had to update software used to run our hosted = services to support FQDN in c=3D line and ICE candidates (which was actuall= y done as a regex replacement). Our software which is installed at client p= remises is still not updated and will likely take our clients another 6 mon= ths to a year to update. As far as we could see, before update, 2-3% of all= listen only connections where affected. This is not a huge number but caus= ed customer complaints from clients who were able to connect before the exp= eriment started.

2. Peer-to-peer connections withi= n enterprise: We are working with a peer-to-peer web casting solution for w= ebinars. We see the connectivity rate reduction within large enterprises, w= here IP based connection between two private IP is allowed but client brows= ers are not withing the same broadcast domain. In this case mDNS connectivi= ty check fails when direct IP connectivity check would succeed. In these ca= ses webcast client switches to streaming from the server, so this does no r= esult in total failure but does decrease the P2P network efficiency. Having= an ability to ask for Peer-to-Peer connectivity permission would really he= lp in this case.

Best Regards,
_____________
Roman Shpount
=

On Thu, Jul 4, 2019 at 1:41 AM Justin Uberti <juberti@google.com> wrote:
= As I understand it, mdns in the c=3D line will only occur in edge cases, i.= e., when there are no other candidates. As such I don=E2=80=99t see this as= a showstopper.

We have measured the connectivity impact of this change in significant d= etail and feel increasingly confident there are no egregious latent issues.=

On Wed, Jul 3, 2019 a= t 9:50 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Probably not the ideal forum to point= this out, but I hope the Chrome team is aware that rolling out this featur= e, assuming it includes using mDNS in the connection line, will break inter= op with Firefox.
So I have to concur that rolling this out appears to b= e premature to me.

Best
=C2= =A0 Nils Ohlmeier

On 3Jul= , 2019, at 17:58, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

Hmm, that's unfortunate. I think this is a mistake, given that we are= about to throw the switch to enable mDNS for 100% of Chrome endpoints; Chr= ome (and soon all browsers) will have to ignore ice-sip-sdp until this exte= nsion spec is written.

ice-sip-sdp isn't published y= et, so it seems an update to that document could still be a possibility. If= that's not an option, putting forth #1 as a specific extension that al= lows FQDN candidates to be generated in certain situations seems like the r= ight path.



On Wed, Jul 3, 2019 at 5:= 40 PM Roman Shpount <roman@telurix.com> wrote:
Part of the problem = is that mmusic have decided to punt on the FQDN support. In the current mmu= sic-ice-sip-sdp the final language that was included:

<connection-address>: =C2=A0is taken from= RFC 4566 [RFC4566].=C2=A0 It is the IP address of the candidate, allowing = for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs= ).=C2=A0 When parsing=C2=A0this field, an agent can differentiate an IPv4 a= ddress and an IPv6=C2=A0address by presence of a colon in its value - the p= resence of a=C2=A0colon indicates IPv6. =C2=A0An agent generating local = candidates MUST=C2=A0NOT use FQDN addresses.=C2=A0 An agent processing remo= te candidates=C2=A0MUST ignore candidate lines that include candidates with= FQDN or=C2=A0IP address versions that are not supported or recognized.= =C2=A0The=C2=A0procedures for generation and handling of FQDN candidate= s, as well=C2=A0as, how agents indicate support for such procedures, need t= o be=C2=A0specified in an extension specification.

So, at this point we have two options:=C2= =A0
1. draft-ietf-rtcweb-mdns-ice-candidates can upda= te ice-sip-sdp and define how FQDN candidates generated by mdns are handled=
2. write a new draft in mmusic which defines FQDN handling
=

In any case some sort of mmusic discussion is needed to= reconcile this.

Best Regards,
_____________
Roman Shpount

<= /div>
O= n Wed, Jul 3, 2019 at 8:28 PM Justin Uberti <juberti@google.com> wrote:
The problem= this draft is trying to solve is fairly RTCWEB-specific. If there are indi= vidual issues to resolve, we can send them out to mmusic=C2=A0for discussio= n, but AFAIK no changes to existing ICE specs are needed.

On Wed, Jul 3, 201= 9 at 4:26 PM Roman Shpount <roman@telurix.com> wrote:
Hi All,

Is rtcweb the right place for = draft-ietf-rtcweb-mdns-ice-candidates? This entire draft seems to be ICE/SD= P specific and not limited to rtcweb. Also, there are significant interop i= mplications for this draft between=C2=A0browser and non-browser end points = which probably warrant larger discussion outside of rtcweb group. I would t= hink mmusic would be a much better place for this draft. I know there is an= incentive to complete this draft quickly but this has a potential to break= a lot of things (it already did break interop with almost every existing I= CE implementation).

Regard= s,
_____________
Roman Shpount
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

--000000000000a5d44d058cdf6742-- From nobody Thu Jul 4 12:27:11 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2361D12021F for ; Thu, 4 Jul 2019 12:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1lFHUD9sAyw for ; Thu, 4 Jul 2019 12:27:06 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 D4E611201EF for ; Thu, 4 Jul 2019 12:27:06 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id c13so3262007pgg.3 for ; Thu, 04 Jul 2019 12:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SM+dQ/GViR0w8uH2+QjD7Iltd3C3jd8zMRLL0SoIjpU=; b=puG2uLCf3SG6lwvpC0UZpKaxzIJxLXf600Y2RojTpL69d2AHzQ622SDLy9x6gSCHqx OGOChajLeSBn0xrrA+il9YanjN3cboTIJQv0D6Sbtw3IToyOOoBpnKhMVhAE5J/de2qL hXb95e8qpDIcBwd1a2UxHzfY2Q33Beo+JkRm/YAe2LyeEBtusjbgxlBd6wBQkYxjgXjv MLccmw/oRLsuw/4iPrIL0vHBGRbyKBmRiXgpcIjoUxdUTZm/4S93bkooch70QpiditIW i6/hwU5/3ZXpKfw8VsUAHzViYKqcAG7wLP0rOp4ackhJDdjL6VmdkFn3K7DaOExtrwEA rGXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SM+dQ/GViR0w8uH2+QjD7Iltd3C3jd8zMRLL0SoIjpU=; b=AG9P2iu+kjChRYnLTFC3q6ZIQComn2AccupmQd60iUwxAUdHoeYAv4VeGnBZfB21RQ AazSodpxVAGShV1mI4ApmLQkldD+/0pZasmDuj75mJFBaX9V63o+manuYin8SJcV9ZDd J5xuIqSUSL0ibaV+tp7LLK+L05+gTavyoC2Fx+yqgEOL9ZEHLVt3rWSwvoJxmI6y/Vev YU25NyMzbQ8ON1DH3GlCEWqf2QbLEtWn1GhHHU+KhWSDmBvxa/phLAqOrSxLt7DniEsx fqzGYfOUPsWr53Y+75/pCSAfTN0qRvHs/etB4CyC+r77WjOR2bImfkRx1PV12kuUKQUe 8fvg== X-Gm-Message-State: APjAAAW3kWgyUS/cCuMDY08a4ThpfoQFm2Vis12xohaiYnwXNPrRXY2l LZDhJ8PmGuf0KQKZNIbhYKvI6wCXSjk= X-Google-Smtp-Source: APXvYqwaVTUs1Ystw/qHJ/STyVJL6m1mSTdh4WRtXlrgpkqOKz+RFMm/GYnPlqfmzonYoR3KF0uM/w== X-Received: by 2002:a63:f146:: with SMTP id o6mr107528pgk.179.1562268425683; Thu, 04 Jul 2019 12:27:05 -0700 (PDT) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com. [209.85.214.177]) by smtp.gmail.com with ESMTPSA id j11sm8694145pfa.2.2019.07.04.12.27.04 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 12:27:04 -0700 (PDT) Received: by mail-pl1-f177.google.com with SMTP id k8so3491672plt.3 for ; Thu, 04 Jul 2019 12:27:04 -0700 (PDT) X-Received: by 2002:a17:902:bd0a:: with SMTP id p10mr51399591pls.134.1562268423934; Thu, 04 Jul 2019 12:27:03 -0700 (PDT) MIME-Version: 1.0 References: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> In-Reply-To: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> From: Roman Shpount Date: Thu, 4 Jul 2019 15:26:55 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Nils Ohlmeier Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="00000000000073d8a9058cdff6e6" Archived-At: Subject: Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 19:27:09 -0000 --00000000000073d8a9058cdff6e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nils, When writing ice-sip-sdp we have considered two possible options when using FQDN in ICE candidate lines: 1. Same FQDN as in default ICE candidate 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9" To deal with both, ice-sip-sdp specifies, that when verifying ICE support, both options should be accepted. Since RFC 5245 provided no guidance regarding handling FQDN in default candidate, both options would likely cause ICE support verification failures. Using FQDN in default candidate also raised the question of address family and address type in c=3D line since neither is specified in the ICE candidate. This being said, FQDN in c=3D line is allowed by RFC 4566: connection-field =3D [%x63 "=3D" nettype SP addrtype SP connection-address CRLF] ;a connection field must be present ;in every media description or at the ;session-level ; sub-rules of 'c=3D' connection-address =3D multicast-address / unicast-address unicast-address =3D IP4-address / IP6-address / FQDN / extn-addr Not being able to handle FQDN in the c=3D line is technically a bug. Best Regards, _____________ Roman Shpount On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier wrote: > Hello, > > I have concerns regarding the current recommendations in > draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP > addresses in the =E2=80=9Cc=3D=E2=80=9C lines. > > Section 3.1.2.3 recommends to use mDNS for the connection-address. I thin= k > we should reconsider this advice as some SPD parsers handle parsing > failures differently depending on line type. > In case of Firefox a parsing failure for the connection line is treated a= s > terminal failure. Where parsing failures for a=3D lines are expected, as > these might contain unknown new features. > > Section 4.3 mentions that hostnames in ICE candidates can result in ICE > failures, but it does not cover backward compatibility in regards to the = c=3D > line. > > My recommendation is to change the draft so that it recommends to always > use a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in u= se. > Obviously it could also be recommended to use an IP4 address instead. The > important point is only to use the same IP consistently in all c=3D lines= and > across all instances. > I think the advantage of this is better backwards compatibility, and it > will not reveal any more details about the user agent compared to using > mDNS names in c=3D lines. > > Best regards > Nils Ohlmeier > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000073d8a9058cdff6e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nils,

When writing ice-sip-sdp we have = considered two possible options when using FQDN in ICE candidate lines:

1. Same FQDN as in default ICE candidate
2.= IPv4/IPv6 address values "0.0.0.0"/"::" and port value= of "9"

To deal with both, ice-sip-sdp s= pecifies, that when verifying ICE support, both options should be accepted.=

Since RFC 5245 provided no guidance regarding han= dling FQDN in default candidate, both options would likely cause ICE suppor= t verification failures. Using FQDN in default candidate also raised the qu= estion of address family and address type in c=3D line since neither is spe= cified in the ICE candidate.=C2=A0
<= br>
This being said, FQDN in c=3D line is allowed by RFC 4566:=C2= =A0

connection-field =3D =C2=A0 =C2=A0[%x63 "= =3D" nettype SP addrtype SP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection-address CRLF= ]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0;a connection field must be present
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0;in every media description or at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;session-level

; sub-rules of 'c=3D'
connection-add= ress =3D =C2=A0multicast-address / unicast-address
unicast-ad= dress =3D =C2=A0 =C2=A0 IP4-address / IP6-address / FQDN / extn-addr
<= div>
Not being able to handle FQDN in the c=3D line is techni= cally a bug.

Best Regards,
_____= ________
Roman Shpount


On Thu, Jul 4, 2019 at 1:26 = AM Nils Ohlmeier <nohlmeier@moz= illa.com> wrote:
Hello,

I have concerns regarding the current recommendations in draft-ietf-rtcweb-= mdns-ice-candidates-03 regarding the handling of IP addresses in the =E2=80= =9Cc=3D=E2=80=9C lines.

Section 3.1.2.3 recommends to use mDNS for the connection-address. I think = we should reconsider this advice as some SPD parsers handle parsing failure= s differently depending on line type.
In case of Firefox a parsing failure for the connection line is treated as = terminal failure. Where parsing failures for a=3D lines are expected, as th= ese might contain unknown new features.

Section 4.3 mentions that hostnames in ICE candidates can result in ICE fai= lures, but it does not cover backward compatibility in regards to the c=3D = line.

My recommendation is to change the draft so that it recommends to always us= e a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in use. = Obviously it could also be recommended to use an IP4 address instead. The i= mportant point is only to use the same IP consistently in all c=3D lines an= d across all instances.
I think the advantage of this is better backwards compatibility, and it wil= l not reveal any more details about the user agent compared to using mDNS n= ames in c=3D lines.

Best regards
=C2=A0 Nils Ohlmeier
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000073d8a9058cdff6e6-- From nobody Thu Jul 4 14:23:59 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5DF1200D8 for ; Thu, 4 Jul 2019 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 XUMYd_uF8rwg for ; Thu, 4 Jul 2019 14:23:54 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5591200C1 for ; Thu, 4 Jul 2019 14:23:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7DB487C434E for ; Thu, 4 Jul 2019 23:23:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTIY8e9MkTgx for ; Thu, 4 Jul 2019 23:23:51 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id F15887C434B for ; Thu, 4 Jul 2019 23:23:50 +0200 (CEST) To: rtcweb@ietf.org References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Thu, 4 Jul 2019 23:23:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 21:23:57 -0000 Den 04.07.2019 20:46, skrev Roman Shpount: > I understand that running experiments before proposing a solution is > probably a good thing and this is what Chrome was doing up until this > point. At the same time, rolling this feature into production before at > least documenting it, will definitely cause interop problems. What we > have now is a fairly major feature with a fairly outdated specification > where all the interop issues weren't considered. > To be precise, we have documentation for the feature (draft-ietf-rtcweb-mdns-ice-candidates), it's been largely unchanged for quite some time, and it's what Chrome is in the process of shipping. It addresses a quite substantive issue (as in "millions of occurences per day" of the behavior we want to prevent). The fact that we're only getting the interoperability issues discovered as we roll out the feature to stable is sad; I don't know how to get other people's software tested earlier in the cycle, which is what would have given us more time to work through these issues. Given mmusic's traditional processing speed, I am not sure there's any point in formally moving the document at this point. Harald From nobody Fri Jul 5 01:43:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3BC120196 for ; Fri, 5 Jul 2019 01:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 ayYq9pizRtto for ; Fri, 5 Jul 2019 01:43:22 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA89120286 for ; Fri, 5 Jul 2019 01:43:21 -0700 (PDT) Received: from [192.168.2.100] (pD9E2CB4B.dip0.t-ipconnect.de [217.226.203.75]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id x658hLrL030389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Jul 2019 10:43:23 +0200 From: Philipp Hancke To: rtcweb@ietf.org References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> Message-ID: <14c2e495-ef68-3d85-0c2f-33f841c268de@goodadvice.pages.de> Date: Fri, 5 Jul 2019 10:43:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 08:43:37 -0000 Am 04.07.19 um 23:23 schrieb Harald Alvestrand: > Den 04.07.2019 20:46, skrev Roman Shpount: >> I understand that running experiments before proposing a solution is >> probably a good thing and this is what Chrome was doing up until this >> point. At the same time, rolling this feature into production before at >> least documenting it, will definitely cause interop problems. What we >> have now is a fairly major feature with a fairly outdated specification >> where all the interop issues weren't considered. >> > > To be precise, we have documentation for the feature > (draft-ietf-rtcweb-mdns-ice-candidates), it's been largely unchanged for > quite some time, and it's what Chrome is in the process of shipping Where has the plan to ship this in M75 been communicated? It doesn't even seem to be using the blink launch process? > It addresses a quite substantive issue (as in "millions of occurenes > per day" of the behavior we want to prevent). I think 3.5% of pageloads (from chromestatus' metric 1054) is a bit more than "millions". > The fact that we're only getting the interoperability issues discovered > as we roll out the feature to stable is sad; I don't know how to get > other people's software tested earlier in the cycle, which is what would > have given us more time to work through these issues. Have you tried talking to said other people? (this is rhetorical. I remember the dtls 1.0 deprecation and many other cases) in this particular case I reported that the previous choice of putting an empty string into c= was broken back in January: https://bugs.chromium.org/p/chromium/issues/detail?id=927309 I find it quite sad that this was fixed without verifying that Firefox (which I indicated as 'throws' in the second comment) is ok with this. (yes, I could have tested this myself; OTOH this isn't part of my job) I suspect the interop issue with Firefox is restriced to non-trickle usage where no stun/turn servers are used. Which might be uncommon in general (for P2P) but might be a highly relevant deployment scenario for some applications that talk to servers. This is a pattern that has broken things in the past (see for example the "unified plan breaks my cma" episode) because errors in those apps are not visible in the very noisy system that "chrome as a whole" represents. From nobody Fri Jul 5 09:39:01 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9873E1200FD; Fri, 5 Jul 2019 09:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <156234473957.21877.15973546163822232027@ietfa.amsl.com> Date: Fri, 05 Jul 2019 09:38:59 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 16:39:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : Security Considerations for WebRTC Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-12.txt Pages : 26 Date : 2019-07-05 Abstract: WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-12 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 6 13:16:10 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0891120077 for ; Sat, 6 Jul 2019 13:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgtFJO1Hy_GG for ; Sat, 6 Jul 2019 13:16:07 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 68D4412008B for ; Sat, 6 Jul 2019 13:16:07 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id c14so6167028plo.0 for ; Sat, 06 Jul 2019 13:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5KVZl+5phb9rkeChY5+DLk6aeFkeoRjrqQgYSCprBFM=; b=svTjYbni2V7cAritVR9JxFUUAydJ7TGUG4T/x9/mgIpHFkXrfkrNNYLWlgLXgh903D WE2acaqJX2YojGS0kFi98AzDix7/L4vMsr/nAR35gTDIidMcEZlKNz7aSHgAn46gWqdd KthbcSJMZHB6+BXLABFbx7eEl5PQu7cnfDzbUxR53nsQ7EsLYg9cH2R/U8abiGAflxUt TWtIU78SGXnMxF+vcA1antx89uS8pbW02Mm5eTwE043T7CjBid7eWH+kgGXWeHKHyFb4 sKqAo7E1CwvyOHmCEDIl2OvIvCFYCkGYqNGxE1ZByY36fTgF4BJschu0BEqxSwqIvzpa L2EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5KVZl+5phb9rkeChY5+DLk6aeFkeoRjrqQgYSCprBFM=; b=TVdCd1fTyNz839euJIRpXp4BzwvKvbXu/EyN6kre6NSmCD1A+GOwkjVAiJV7cCfKZc 1VDCfHIRUpMW/cKNk7gLOXPF+3xFLc/jMwF1YVCJhBxNNLdT2+/BWL7gAr9w2I9hQ0/T 4T7np7N+LlB6k+n6wsun35trRKZgK2y5n3smhP/lbLn4XrXjM/rARmyKvZc5PcYtiufx YoWEegTx5/kYV44xB51ItIg0u9H5C1sScjkDLng57dy53yW5OAak+8QjZn1ccZF6b+n5 3fyKNZZb/Ap7qNAPQzAGem6s5CSwVVIlaOL7oSaSSJ6Ho6H+fTaLetild3yzC0WQCkSD nweA== X-Gm-Message-State: APjAAAXKO+Ax4GhLJzBFNqQWqTP4dazXRcGVjsCDSZVwNeus4ONOt8/0 /T7OwuceukaVwDFQZyXJr3scuTk5/vA= X-Google-Smtp-Source: APXvYqyGuOm4Zo4FHGUEur/SNIYOMQkdGeY+c1fuSrUSpQ0csljTyOMd24xwyFP6qjjsVlKVo7LNaA== X-Received: by 2002:a17:902:8f87:: with SMTP id z7mr12893609plo.65.1562444166654; Sat, 06 Jul 2019 13:16:06 -0700 (PDT) Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com. [209.85.214.172]) by smtp.gmail.com with ESMTPSA id q4sm12414018pjq.27.2019.07.06.13.16.05 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 06 Jul 2019 13:16:05 -0700 (PDT) Received: by mail-pl1-f172.google.com with SMTP id c2so4601537plz.13 for ; Sat, 06 Jul 2019 13:16:05 -0700 (PDT) X-Received: by 2002:a17:902:a413:: with SMTP id p19mr7536437plq.134.1562444164958; Sat, 06 Jul 2019 13:16:04 -0700 (PDT) MIME-Version: 1.0 References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> In-Reply-To: From: Roman Shpount Date: Sat, 6 Jul 2019 16:15:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000006f0f5e058d08e1cb" Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 20:16:10 -0000 --0000000000006f0f5e058d08e1cb Content-Type: text/plain; charset="UTF-8" On Thu, Jul 4, 2019 at 5:24 PM Harald Alvestrand wrote: > Den 04.07.2019 20:46, skrev Roman Shpount: > > I understand that running experiments before proposing a solution is > > probably a good thing and this is what Chrome was doing up until this > > point. At the same time, rolling this feature into production before at > > least documenting it, will definitely cause interop problems. What we > > have now is a fairly major feature with a fairly outdated specification > > where all the interop issues weren't considered. > > > > To be precise, we have documentation for the feature > (draft-ietf-rtcweb-mdns-ice-candidates), it's been largely unchanged for > quite some time, and it's what Chrome is in the process of shipping. > Are you saying that draft-ietf-rtcweb-mdns-ice-candidates provides an accurate description of what is being shipped in Chrome? As far as I know this document is outdated. It also has implementation issues like stating "An ICE agent SHOULD ignore candidates where the hostname resolution returns more than one IP address". There are platforms which return both IPv6 and IPv4 for a DNS record which points to a single IPv4 address. There are two fundamental problems with FQDN in ICE candidates. First being legacy interop. Second being that handling FQDN is under-specified and FQDN in ICE candidate line is likely missing necessary information required to resolve it (address family). Dealing with the default candidate which is a FQDN is another are which has no existing specification leading to FQDN with unknown address family in the c= line. It addresses a quite substantive issue (as in "millions of occurences > per day" of the behavior we want to prevent). > I understand the desire to block one of the client fingerprinting methods. After all, there are few hundred others that will need to blocked after. The fact that we're only getting the interoperability issues discovered > as we roll out the feature to stable is sad; I don't know how to get > other people's software tested earlier in the cycle, which is what would > have given us more time to work through these issues. > The software was tested and issues were identified and fixed. Unfortunately not everyone has a luxury of simply pushing the software update to all customer. When dealing with telecom, it is common for them to deploy new software every 3-6 months and only after running a limited deployment for a few months before hand. It literally takes a year to push a new version to them, which is not usually a problem, unless some breaking protocol change is introduced, like unified plan or mdns. Given mmusic's traditional processing speed, I am not sure there's any > point in formally moving the document at this point. > It is especially slow when none of the people interested in the specific feature (FQDN in ICE candidates) participate in the discussion. So far this looks like this feature is going to be shipped regardless of what anybody thinks about it and without even attempting to discuss it in the group which is responsible for this functionality. Best Regards, _____________ Roman Shpount --0000000000006f0f5e058d08e1cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 4, 2019 at 5:24 PM Ha= rald Alvestrand <harald@alvestra= nd.no> wrote:
Den 04.07.2019 20:46, skrev Rom= an Shpount:
> I understand that running experiments before proposing a solution is > probably a good thing and this is what Chrome was doing up until this<= br> > point. At the same time, rolling this feature into production before a= t
> least documenting it, will definitely cause interop problems. What we<= br> > have now is a fairly major feature with a fairly outdated specificatio= n
> where all the interop issues weren't considered.
>

To be precise, we have documentation for the feature
(draft-ietf-rtcweb-mdns-ice-candidates), it's been largely unchanged fo= r
quite some time, and it's what Chrome is in the process of shipping.

Are you saying that draft-ietf-rtcweb-mdn= s-ice-candidates provides an accurate description of what is being shipped = in Chrome? As far as I know this document is outdated. It also has implemen= tation issues=C2=A0 like stating "An ICE agent SHOULD ignore candidates where the hostname r= esolution=C2=A0returns more than one IP address". There are platforms which re= turn both IPv6 and IPv4 for a DNS record which points to a single IPv4 addr= ess. There are two fundamental problems with FQDN in ICE candidates. First = being legacy interop. Second being that handling FQDN is under-specified=C2= =A0and=C2=A0 FQDN in ICE candidate line is likely missing necessary=C2=A0in= formation required to resolve it (address family). Dealing with the default= candidate which is a FQDN is another are which has no existing specificati= on leading to FQDN with unknown address family in the c=3D line.

I= t addresses a quite substantive issue (as in "millions of occurences per day" of the behavior we want to prevent).
=C2= =A0
I understand the desire to block one of the client fingerprin= ting methods. After all, there are few hundred others that will need to blo= cked after.

The fact that we're only getting the interoperability issues dis= covered
as we roll out the feature to stable is sad; I don't know how to get other people's software tested earlier in the cycle, which is what woul= d
have given us more time to work through these issues.
=
The software was tested and issues were identified and fixed= . Unfortunately not everyone has a luxury of simply pushing the software up= date to all customer. When dealing with telecom, it is common for them to d= eploy new software every 3-6 months and only after running a limited deploy= ment for a few months before hand. It literally takes a year to push a new = version to them, which is not usually a problem, unless some breaking proto= col change is introduced, like unified plan or mdns.=C2=A0

Given mmusic's tr= aditional processing speed, I am not sure there's any
point in formally moving the document at this point.
<= br>
It is especially slow when none of the people interested in t= he specific feature (FQDN in ICE candidates) participate in the discussion.= So far this looks like this feature is going to be shipped regardless of w= hat anybody thinks about it and without even attempting to discuss it in th= e group which is responsible for this functionality.

Best Regards,
_____________
Roman Shpount
=C2=A0
--0000000000006f0f5e058d08e1cb-- From nobody Sun Jul 7 00:29:33 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05DE12002E for ; Sun, 7 Jul 2019 00:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 KQm3-fk7OYtR for ; Sun, 7 Jul 2019 00:29:30 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9AD1200B6 for ; Sun, 7 Jul 2019 00:29:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CAC507C32BA for ; Sun, 7 Jul 2019 09:29:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIY3pkkk8k9W for ; Sun, 7 Jul 2019 09:29:27 +0200 (CEST) Received: from [192.168.8.108] (46.66.146.252.tmi.telenormobil.no [46.66.146.252]) by mork.alvestrand.no (Postfix) with ESMTPSA id DB3167C0775 for ; Sun, 7 Jul 2019 09:29:26 +0200 (CEST) References: <156240256137.15187.16756612054706510452.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= mQINBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABtC9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPokCPgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryG5Ag0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAGJAiUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= X-Forwarded-Message-Id: <156240256137.15187.16756612054706510452.idtracker@ietfa.amsl.com> Message-ID: Date: Sun, 7 Jul 2019 09:29:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <156240256137.15187.16756612054706510452.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------4C08116BB24A8122C2DE245B" Content-Language: en-GB Archived-At: Subject: [rtcweb] Fwd: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 07:29:33 -0000 This is a multi-part message in MIME format. --------------4C08116BB24A8122C2DE245B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I'm still in two minds about pursuing this, but wanted to make sure we had an updated version available if people want to bend my ear at the Montreal hackathon about it. -------- Forwarded Message -------- Subject: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-01.txt Date: Sat, 06 Jul 2019 01:42:41 -0700 From: internet-drafts@ietf.org To: Harald Alvestrand A new version of I-D, draft-alvestrand-mmusic-simulcast-ssrc-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Name: draft-alvestrand-mmusic-simulcast-ssrc Revision: 01 Title: Using SSRC with WebRTC Simulcast Document date: 2019-07-06 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-simulcast-ssrc-01.txt Status: https://datatracker.ietf.org/doc/draft-alvestrand-mmusic-simulcast-ssrc/ Htmlized: https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-alvestrand-mmusic-simulcast-ssrc Diff: https://www.ietf.org/rfcdiff?url2=draft-alvestrand-mmusic-simulcast-ssrc-01 Abstract: This document describes a convention for sending "a=ssrc" attributes in SDP together with "a=simulcast" attributes. This allows SFUs that need SSRC information to have this info easily accessible. Given that it is intended as an interim measure, it does not aim for being published as an RFC. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------4C08116BB24A8122C2DE245B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I'm still in two minds about pursuing this, but wanted to make sure we had an updated version available if people want to bend my ear at the Montreal hackathon about it.



-------- Forwarded Message --------
Subject: New Version Notification for draft-alvestrand-mmusic-simulcast-ssrc-01.txt
Date: Sat, 06 Jul 2019 01:42:41 -0700
From: internet-drafts@ietf.org
To: Harald Alvestrand <harald@alvestrand.no>



A new version of I-D, draft-alvestrand-mmusic-simulcast-ssrc-01.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name: draft-alvestrand-mmusic-simulcast-ssrc
Revision: 01
Title: Using SSRC with WebRTC Simulcast
Document date: 2019-07-06
Group: Individual Submission
Pages: 7
URL: https://www.ietf.org/internet-drafts/draft-alvestrand-mmusic-simulcast-ssrc-01.txt
Status: https://datatracker.ietf.org/doc/draft-alvestrand-mmusic-simulcast-ssrc/
Htmlized: https://tools.ietf.org/html/draft-alvestrand-mmusic-simulcast-ssrc-01
Htmlized: https://datatracker.ietf.org/doc/html/draft-alvestrand-mmusic-simulcast-ssrc
Diff: https://www.ietf.org/rfcdiff?url2=draft-alvestrand-mmusic-simulcast-ssrc-01

Abstract:
This document describes a convention for sending "a=ssrc" attributes
in SDP together with "a=simulcast" attributes. This allows SFUs that
need SSRC information to have this info easily accessible.

Given that it is intended as an interim measure, it does not aim for
being published as an RFC.



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

The IETF Secretariat

--------------4C08116BB24A8122C2DE245B-- From nobody Sun Jul 7 00:47:28 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D4712031C for ; Sun, 7 Jul 2019 00:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 CdzzCy0eqaV9 for ; Sun, 7 Jul 2019 00:47:16 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15CC120302 for ; Sun, 7 Jul 2019 00:47:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 2C5F17C32BA; Sun, 7 Jul 2019 09:47:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIu6IMKScM8Q; Sun, 7 Jul 2019 09:47:08 +0200 (CEST) Received: from [192.168.8.108] (46.66.146.252.tmi.telenormobil.no [46.66.146.252]) by mork.alvestrand.no (Postfix) with ESMTPSA id 99E657C0775; Sun, 7 Jul 2019 09:47:08 +0200 (CEST) To: Roman Shpount Cc: RTCWeb IETF References: <40E6F158-7AA1-42AD-9D18-1B4C335ECD64@mozilla.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= mQINBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABtC9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPokCPgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryG5Ag0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAGJAiUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: Date: Sun, 7 Jul 2019 09:47:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CF70E4C1D7B925C036C8799E" Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] Is rtcweb the right place for draft-ietf-rtcweb-mdns-ice-candidates? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 07:47:27 -0000 This is a multi-part message in MIME format. --------------CF70E4C1D7B925C036C8799E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/6/19 10:15 PM, Roman Shpount wrote: > > Given mmusic's traditional processing speed, I am not sure there's = any > point in formally moving the document at this point. > > > It is especially slow when none of the people interested in the > specific feature (FQDN in ICE candidates) participate in the > discussion. So far this looks like this feature is going to be shipped > regardless of what anybody thinks about it and without even attempting > to discuss it in the group which is responsible for this functionality.= My favorite examples are -msid (initial version May 2012, IESG evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May 2018); -bundle-negotiation (initial version October 2011, IESG evaluation February 2018). Each of these has its own history, but when a group is capable of discussing a draft for seven years before it is IESG-ready, I question the effectieness of moving drafts into that group. > Best Regards, > _____________ > Roman Shpount > =C2=A0 --=20 Surveillance is pervasive. Go Dark. --------------CF70E4C1D7B925C036C8799E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/6/19 10:15 PM, Roman Shpount wrote:

Given mmusic's traditional processing speed, I am not sure there's any
point in formally moving the document at this point.

It is especially slow when none of the people interested in the specific feature (FQDN in ICE candidates) participate in the discussion. So far this looks like this feature is going to be shipped regardless of what anybody thinks about it and without even attempting to discuss it in the group which is responsible for this functionality.

My favorite examples are -msid (initial version May 2012, IESG evaluation June 2016); -sdp-simulcast (initial version April 2015, IESG evaluation May 2018); -bundle-negotiation (initial version October 2011, IESG evaluation February 2018).

Each of these has its own history, but when a group is capable of discussing a draft for seven years before it is IESG-ready, I question the effectieness of moving drafts into that group.


Best Regards,
_____________
Roman Shpount
 


-- 
Surveillance is pervasive. Go Dark.
--------------CF70E4C1D7B925C036C8799E-- From nobody Sun Jul 7 14:26:50 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70C1201CA; Sun, 7 Jul 2019 14:26:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <156253479814.532.11241868729758290168@ietfa.amsl.com> Date: Sun, 07 Jul 2019 14:26:38 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-19.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2019 21:26:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-19.txt Pages : 43 Date : 2019-07-07 Abstract: This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-19 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-arch-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 16:55:52 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BCF1203AF for ; Mon, 8 Jul 2019 16:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 MWTiqM2IsCGS for ; Mon, 8 Jul 2019 16:55:41 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 2EDE61203CC for ; Mon, 8 Jul 2019 16:55:40 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id b13so3754598pfo.1 for ; Mon, 08 Jul 2019 16:55:40 -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=AYzL5Oe57Vg6Uuwt7ZFz0JyvlrS2HPLkmohT2liOIeg=; b=Mn1xGIIk8ILzYQnciYh6fRcI1KZiRE0kkCJ5W26ZcDYwtrXcDQBjrXkxINYSetlJTt wAt/ZW/QC1xRJUB1wRC+MjOHbPkeTPNMmVJXOKyxm0Xioihn8D37ULCiQrfQ0s5aNDzG tPNFmCIEfOkvVwdb6Fe7HLT3LbElZbO/Tbn8k= 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=AYzL5Oe57Vg6Uuwt7ZFz0JyvlrS2HPLkmohT2liOIeg=; b=qK5H38UY/crGWA4kvo8nbPY1Nm0dTI8qM6gZEFCYT4IJt/vl1o9Z5a14GFXt/5SOMX Hq7AoCrLxs/Ek888ei7FMSjPFzIgDN2T4FoJBTZI53VYUBAs/driSkut9BUqhrT4L86F DHmd9hoR3HHzS25asDXnITu2bOPUTwVp5K0cytw18PhoKltbnCnvR+DCTiEBcXDOa52D VfoKlL1079yiexZiodI7lhM1wjHHhBu1XgvO49fWMU9bZ9jYWNV9MHa++L938iaxe5HR gddfhW0deqlo0x/b4uwWsFSD0XliNpKWOCIZLz0P5zeKLa8rmWHBC+8yUwBA6WuIv48C QO1A== X-Gm-Message-State: APjAAAVMEGXkGHFYRx31U8IvQdLG94DqFvJMpX3o8Gm6227aXJBaz9Bp P1OQnpikfcvOz7jGZhFZZYsfag== X-Google-Smtp-Source: APXvYqy/d1l+rubFGdv7mABB6xVVlIO53ZWFx0/CxSh9PkBBSBxmyvmBRSqAgTyFpMuk5xqRiRRPRA== X-Received: by 2002:a63:1847:: with SMTP id 7mr27587428pgy.204.1562630139580; Mon, 08 Jul 2019 16:55:39 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:7cf2:850f:6b10:755e? ([2620:101:80fc:224:7cf2:850f:6b10:755e]) by smtp.gmail.com with ESMTPSA id 195sm10091286pfu.75.2019.07.08.16.55.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 16:55:38 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DB51A1D2-B9FC-4BB8-B629-68055F676D1A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 8 Jul 2019 16:55:37 -0700 In-Reply-To: Cc: "rtcweb@ietf.org" To: Roman Shpount References: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:55:50 -0000 --Apple-Mail=_DB51A1D2-B9FC-4BB8-B629-68055F676D1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roman, I know that not being able to handle FQDN in c-lines is a bug on the = Firefox side. And we are working on it to fix it: = https://bugzilla.mozilla.org/show_bug.cgi?id=3D1544770 = But my main question is: why does the draft right now recommend to use = the mDNS FQDN in the c-line, rather then a fake IPv4/IPv6 address? I fail to see the advantage of using the FQDN and it appears to cause = more interop issues. Best Nils Ohlmeier > On 4Jul, 2019, at 12:26, Roman Shpount wrote: >=20 > Nils, >=20 > When writing ice-sip-sdp we have considered two possible options when = using FQDN in ICE candidate lines: >=20 > 1. Same FQDN as in default ICE candidate > 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9" >=20 > To deal with both, ice-sip-sdp specifies, that when verifying ICE = support, both options should be accepted. >=20 > Since RFC 5245 provided no guidance regarding handling FQDN in default = candidate, both options would likely cause ICE support verification = failures. Using FQDN in default candidate also raised the question of = address family and address type in c=3D line since neither is specified = in the ICE candidate.=20 >=20 > This being said, FQDN in c=3D line is allowed by RFC 4566:=20 >=20 > connection-field =3D [%x63 "=3D" nettype SP addrtype SP > connection-address CRLF] > ;a connection field must be present > ;in every media description or at the > ;session-level >=20 > ; sub-rules of 'c=3D' > connection-address =3D multicast-address / unicast-address > unicast-address =3D IP4-address / IP6-address / FQDN / extn-addr >=20 > Not being able to handle FQDN in the c=3D line is technically a bug. >=20 > Best Regards, > _____________ > Roman Shpount >=20 >=20 > On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier > wrote: > Hello, >=20 > I have concerns regarding the current recommendations in = draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP = addresses in the =E2=80=9Cc=3D=E2=80=9C lines. >=20 > Section 3.1.2.3 recommends to use mDNS for the connection-address. I = think we should reconsider this advice as some SPD parsers handle = parsing failures differently depending on line type. > In case of Firefox a parsing failure for the connection line is = treated as terminal failure. Where parsing failures for a=3D lines are = expected, as these might contain unknown new features. >=20 > Section 4.3 mentions that hostnames in ICE candidates can result in = ICE failures, but it does not cover backward compatibility in regards to = the c=3D line. >=20 > My recommendation is to change the draft so that it recommends to = always use a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS = is in use. Obviously it could also be recommended to use an IP4 address = instead. The important point is only to use the same IP consistently in = all c=3D lines and across all instances. > I think the advantage of this is better backwards compatibility, and = it will not reveal any more details about the user agent compared to = using mDNS names in c=3D lines. >=20 > Best regards > Nils Ohlmeier > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_DB51A1D2-B9FC-4BB8-B629-68055F676D1A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Roman,

I know that = not being able to handle FQDN in c-lines is a bug on the Firefox = side.
And we are working on it to fix it: https://bugzilla.mozilla.org/show_bug.cgi?id=3D1544770

But my main = question is: why does the draft right now recommend to use the mDNS FQDN = in the c-line, rather then a fake IPv4/IPv6 address?
I fail to see the advantage of using the FQDN and it appears = to cause more interop issues.

Best
  Nils = Ohlmeier

On 4Jul, 2019, at 12:26, Roman Shpount <roman@telurix.com> = wrote:

Nils,

When writing ice-sip-sdp we have considered two possible = options when using FQDN in ICE candidate lines:

1. Same FQDN as in default ICE = candidate
2. IPv4/IPv6 address values = "0.0.0.0"/"::" and port value of "9"

To deal with both, ice-sip-sdp = specifies, that when verifying ICE support, both options should be = accepted.

Since = RFC 5245 provided no guidance regarding handling FQDN in default = candidate, both options would likely cause ICE support verification = failures. Using FQDN in default candidate also raised the question of = address family and address type in c=3D line since neither is specified = in the ICE candidate. 

This being said, FQDN in c=3D line is allowed by RFC = 4566: 

connection-field =3D    [%x63 "=3D" nettype SP = addrtype SP
            =              connection-address = CRLF]
              =            ;a connection field must be = present
              =            ;in every media description or = at the
              =            ;session-level

; = sub-rules of 'c=3D'
connection-address =3D =  multicast-address / unicast-address
unicast-address =3D     IP4-address / IP6-address / = FQDN / extn-addr

Not being able to handle FQDN in the c=3D line is technically = a bug.

Best = Regards,
_____________
Roman = Shpount


On Thu, Jul = 4, 2019 at 1:26 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Hello,

I have concerns regarding the current recommendations in = draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP = addresses in the =E2=80=9Cc=3D=E2=80=9C lines.

Section 3.1.2.3 recommends to use mDNS for the connection-address. I = think we should reconsider this advice as some SPD parsers handle = parsing failures differently depending on line type.
In case of Firefox a parsing failure for the connection line is treated = as terminal failure. Where parsing failures for a=3D lines are expected, = as these might contain unknown new features.

Section 4.3 mentions that hostnames in ICE candidates can result in ICE = failures, but it does not cover backward compatibility in regards to the = c=3D line.

My recommendation is to change the draft so that it recommends to always = use a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in = use. Obviously it could also be recommended to use an IP4 address = instead. The important point is only to use the same IP consistently in = all c=3D lines and across all instances.
I think the advantage of this is better backwards compatibility, and it = will not reveal any more details about the user agent compared to using = mDNS names in c=3D lines.

Best regards
  Nils Ohlmeier
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=

= --Apple-Mail=_DB51A1D2-B9FC-4BB8-B629-68055F676D1A-- From nobody Mon Jul 8 17:09:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADEA12039E for ; Mon, 8 Jul 2019 17:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.204 X-Spam-Level: X-Spam-Status: No, score=-16.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7V2Vty137UP for ; Mon, 8 Jul 2019 17:08:56 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 39874120399 for ; Mon, 8 Jul 2019 17:08:56 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id v129so9471036vsb.11 for ; Mon, 08 Jul 2019 17:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JetYU/DQqWzQSJkfOSPpxAx9xuC29GWDZkvKPt4jNCQ=; b=ka+r+Hl35jJyYm3FMlceXTyqqsUebF8sURezTTXmpojXtGA6107jiKKx/CEhy7/yZ4 Jc5SczeTa1TI7KumFketYwLikfnmwC32ZfJ41W5mSWGBVxtJmVA+V5ScKyw2N7vEvMik nxBNOK1b2QQ0n/r/U0mmqXWk/GGTSeb06jH7LSiSBfKe2tsnFAVt7khNTIphGQ8kbHKO BYNSXkq07pHo3MAqwwkmyztDszizVG7AldCPocaVTbDPGpGTuGahpBjTa1bsdpWvXDne bnULGBNjhxaUK2aEoZfl9W0RFeuuVsQwDQWTRwkoZxwTjDUp5bQhGeMPUHUDvHU86b/c jj8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JetYU/DQqWzQSJkfOSPpxAx9xuC29GWDZkvKPt4jNCQ=; b=L1/XI8+L1Ir6EuKpElCPCBjFtNnmP9kUxcH9rkAMxwJh1TYVuVLu8H/BSebKze9ALj iUEqYbwboPiWT+L1ANONPZ1AM6rx8AvugkRhjtHA4Jq3IK81qKH7scJ8CY42iuWC2ZYd bG/ADCLrV1M3J3UHyalklz8EJ86Ak5AlddEGetALrSyWGsuQkPuyAtGH0V2V9HouOcmP sizyx0TdoJJ1+pIqz96yNBjYBlRCa9SF1XbX6lxVKzAUSQn8psz5r4zIVH1FziHTgNB/ Dn3dOHphBg9FVnLejjwvvv4p95T/NmvMfZeHi6oyS/TeFlQwSzsIQljnby4/o/t/EKjT cwhw== X-Gm-Message-State: APjAAAXq/cKt2Ha82cp8vKpC1l8Zy+gYztzu21tVqtrs/Nv+4hwiPuG5 TcNcrOj9dLRMEZxDm2XJJ8Xn+KNaGrxYyCtKVWHt6w== X-Google-Smtp-Source: APXvYqwy1/XqHfB5qKpw7/UtoyB8484a7ACZ2/rOzQt89bJQpWWovhBqWt3LZfKcns99XuJVeTVXDnm6/epVIzNzQDo= X-Received: by 2002:a67:fd88:: with SMTP id k8mr12497610vsq.41.1562630934865; Mon, 08 Jul 2019 17:08:54 -0700 (PDT) MIME-Version: 1.0 References: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> In-Reply-To: From: Justin Uberti Date: Mon, 8 Jul 2019 17:08:43 -0700 Message-ID: To: Nils Ohlmeier Cc: Roman Shpount , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ca365d058d345de9" Archived-At: Subject: Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 00:09:10 -0000 --000000000000ca365d058d345de9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The FQDN seemed like the most straightforward option, since nothing new needed to be invented. It's now apparent that that might have been overly optimistic, and we're open to workarounds that are tolerated better and don't create issues of their own. On Mon, Jul 8, 2019 at 5:02 PM Nils Ohlmeier wrote: > Hi Roman, > > I know that not being able to handle FQDN in c-lines is a bug on the > Firefox side. > And we are working on it to fix it: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1544770 > > But my main question is: why does the draft right now recommend to use th= e > mDNS FQDN in the c-line, rather then a fake IPv4/IPv6 address? > I fail to see the advantage of using the FQDN and it appears to cause mor= e > interop issues. > > Best > Nils Ohlmeier > > On 4Jul, 2019, at 12:26, Roman Shpount wrote: > > Nils, > > When writing ice-sip-sdp we have considered two possible options when > using FQDN in ICE candidate lines: > > 1. Same FQDN as in default ICE candidate > 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9" > > To deal with both, ice-sip-sdp specifies, that when verifying ICE support= , > both options should be accepted. > > Since RFC 5245 provided no guidance regarding handling FQDN in default > candidate, both options would likely cause ICE support verification > failures. Using FQDN in default candidate also raised the question of > address family and address type in c=3D line since neither is specified i= n > the ICE candidate. > > This being said, FQDN in c=3D line is allowed by RFC 4566: > > connection-field =3D [%x63 "=3D" nettype SP addrtype SP > connection-address CRLF] > ;a connection field must be present > ;in every media description or at the > ;session-level > > ; sub-rules of 'c=3D' > connection-address =3D multicast-address / unicast-address > unicast-address =3D IP4-address / IP6-address / FQDN / extn-addr > > Not being able to handle FQDN in the c=3D line is technically a bug. > > Best Regards, > _____________ > Roman Shpount > > > On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier > wrote: > >> Hello, >> >> I have concerns regarding the current recommendations in >> draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP >> addresses in the =E2=80=9Cc=3D=E2=80=9C lines. >> >> Section 3.1.2.3 recommends to use mDNS for the connection-address. I >> think we should reconsider this advice as some SPD parsers handle parsin= g >> failures differently depending on line type. >> In case of Firefox a parsing failure for the connection line is treated >> as terminal failure. Where parsing failures for a=3D lines are expected,= as >> these might contain unknown new features. >> >> Section 4.3 mentions that hostnames in ICE candidates can result in ICE >> failures, but it does not cover backward compatibility in regards to the= c=3D >> line. >> >> My recommendation is to change the draft so that it recommends to always >> use a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in = use. >> Obviously it could also be recommended to use an IP4 address instead. Th= e >> important point is only to use the same IP consistently in all c=3D line= s and >> across all instances. >> I think the advantage of this is better backwards compatibility, and it >> will not reveal any more details about the user agent compared to using >> mDNS names in c=3D lines. >> >> Best regards >> Nils Ohlmeier >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000ca365d058d345de9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The FQDN seemed like the most straightforward option, sinc= e nothing new needed to be invented.

It's now appare= nt that that might have been overly optimistic, and we're open to worka= rounds that are tolerated better and don't create issues of their own.<= /div>

On Mon, Jul 8, 2019 at 5:02 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Hi Roman,

I know that not being able to handle F= QDN in c-lines is a bug on the Firefox side.
And we are working o= n it to fix it:=C2=A0https://bugzilla.mozilla.org/show_bug.cgi?id= =3D1544770

But my main question is: why does t= he draft right now recommend to use the mDNS FQDN in the c-line, rather the= n a fake IPv4/IPv6 address?
I fail to see the advantage of using = the FQDN and it appears to cause more interop issues.

<= div>Best
=C2=A0 Nils Ohlmeier

On 4Jul, 2019, at 12:26, Roman Shpount <roman@telurix.com> wrote:

Nils,

When writing ice-sip-sdp we have consider= ed two possible options when using FQDN in ICE candidate lines:
<= br>
1. Same FQDN as in default ICE candidate
2. IPv4/IP= v6 address values "0.0.0.0"/"::" and port value of &quo= t;9"

To deal with both, ice-sip-sdp specifies= , that when verifying ICE support, both options should be accepted.

Since RFC 5245 provided no guidance regarding handling FQ= DN in default candidate, both options would likely cause ICE support verifi= cation failures. Using FQDN in default candidate also raised the question o= f address family and address type in c=3D line since neither is specified i= n the ICE candidate.=C2=A0

This being said, FQDN in c=3D line is allowed by RFC 4566:=C2=A0

connection-field =3D =C2=A0 =C2=A0[%x63 "=3D"= ; nettype SP addrtype SP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0connection-address CRLF]
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0;a connection field must be present
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;i= n every media description or at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;session-level

; sub-rules of 'c=3D'
connection-address= =3D =C2=A0multicast-address / unicast-address
unicast-addres= s =3D =C2=A0 =C2=A0 IP4-address / IP6-address / FQDN / extn-addr
=
Not being able to handle FQDN in the c=3D line is technicall= y a bug.

Best Regards,
_____________
= Roman Shpount


On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlm= eier <nohlmei= er@mozilla.com> wrote:
Hello,

I have concerns regarding the current recommendations in draft-ietf-rtcweb-= mdns-ice-candidates-03 regarding the handling of IP addresses in the =E2=80= =9Cc=3D=E2=80=9C lines.

Section 3.1.2.3 recommends to use mDNS for the connection-address. I think = we should reconsider this advice as some SPD parsers handle parsing failure= s differently depending on line type.
In case of Firefox a parsing failure for the connection line is treated as = terminal failure. Where parsing failures for a=3D lines are expected, as th= ese might contain unknown new features.

Section 4.3 mentions that hostnames in ICE candidates can result in ICE fai= lures, but it does not cover backward compatibility in regards to the c=3D = line.

My recommendation is to change the draft so that it recommends to always us= e a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in use. = Obviously it could also be recommended to use an IP4 address instead. The i= mportant point is only to use the same IP consistently in all c=3D lines an= d across all instances.
I think the advantage of this is better backwards compatibility, and it wil= l not reveal any more details about the user agent compared to using mDNS n= ames in c=3D lines.

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

__________________________________= _____________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000ca365d058d345de9-- From nobody Mon Jul 8 18:01:19 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAD612024F for ; Mon, 8 Jul 2019 18:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKIEuls624DK for ; Mon, 8 Jul 2019 18:01:12 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 9FD76120090 for ; Mon, 8 Jul 2019 18:01:12 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id w10so8526693pgj.7 for ; Mon, 08 Jul 2019 18:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iu9rqA6Do8Zo5ErLiIxJhcM/sVC6LCnWvxub5a3bA4w=; b=cDgHqHEEUZ2hrUYr/YBhD4ORjFU+tpcAOSxs6l3oUnnNZxImDSUTp4h0A1bNVEOi/x 5sxoN3vQwQ7jKbslFj6JqWpKfx4k7uCNI+rjh5if6DjkPUt58KEko3XRX8Wag+BQgUAE vtslN+2Bf2vB1BN2CcCx8tqnedmbUxC2zJfGjeBNVJZtyFyNO5ZEX1Ot0yhMOtsg/jGl cs2nbXnY9FzwbY2zDARygIW4+jZ033F6KAqH04IRupVfM3BV86dHVC1hyKovpod8fj+g cTmP0dexIApLCYGlVm3Vm4g0/07eoQItAE+kLbT1CS56nO3qQtde0oKSa5r/QZC8dqdC DJkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iu9rqA6Do8Zo5ErLiIxJhcM/sVC6LCnWvxub5a3bA4w=; b=ircd1OrxgPlwwa3dmisCR1ApjKMqvQDI1vP7ftDTVmEJCNuIJJt8UNhRjZoDel4qjW Zsppg5SZ7iN7TEdwOp+MJb+l7tKrpwFuT8XcQDYyCDYTAW1IAgCJn5hNhQnI1WhNPBCC 2Yn5K1XELfupZGP6B1gpEVRxH5xMMHixT5AmNejDiytQLjnCeU5Cl2MV0XmxDGaY0Eis A6TdFaK8fXT1FMJCB12yIgh3nZU5T8cVZcXcqcM9HuBmDeSNOufFymGChth6Clo9MB6k COB93cl4q+cVnrXe2+JZ42LbTG3eOkrZjsyC2UgVzcweYQrP8F98twHQG2Nmk3B8F1nX yohA== X-Gm-Message-State: APjAAAV6FQT1WkdUHeSDhfkM5Sjg1CCCB5En+htbcYlhWfPH46K7AP/7 ue/SAGg7Y6EWC6htPPZs9LSqfZjDD0c= X-Google-Smtp-Source: APXvYqzAjtJTYmJd743RQx5LuDu3KdYr4eed0qDHEI7iWCZWlD8jbWqUkYg0OMHATgcqCdJs9knXyw== X-Received: by 2002:a17:90a:5288:: with SMTP id w8mr29505554pjh.61.1562634071563; Mon, 08 Jul 2019 18:01:11 -0700 (PDT) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id b26sm21923824pfo.129.2019.07.08.18.01.09 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 18:01:10 -0700 (PDT) Received: by mail-pl1-f181.google.com with SMTP id a93so9157287pla.7 for ; Mon, 08 Jul 2019 18:01:09 -0700 (PDT) X-Received: by 2002:a17:902:20c8:: with SMTP id v8mr28729231plg.284.1562634069028; Mon, 08 Jul 2019 18:01:09 -0700 (PDT) MIME-Version: 1.0 References: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> In-Reply-To: From: Roman Shpount Date: Mon, 8 Jul 2019 21:00:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Nils Ohlmeier Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009935e0058d351854" Archived-At: Subject: Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 01:01:16 -0000 --0000000000009935e0058d351854 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nils, Using FQDN was not my decision and it is certainly not uncontroversial. As I have mentioned, I see two possible options for address in c=3D line: 1. Same FQDN as in default ICE candidate 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9" The main argument for option 1, is that it should be compatible with legacy implementations based on RFC 4566/RFC 5245. There is a question of Verifying ICE Support (https://tools.ietf.org/html/rfc5245#section-5.1). It is unclear what matching default candidate to a=3Dcandidate supposed to mea= n when FQDN is used, but using the same literal value seemed like a safer option. The main argument against option 1 is that no one implemented or tested FQDN in a=3Dcandidate before chrome implemented mDNS candidates, so default candidate selection and verifying ICE support was not tested either. I did see multiple implementations using FQDN in c=3D line. There are multiple us= e cases for this which existed outside of ICE and mDNS. The main argument for option 2 is that end points that implemented trickle ICE support, would likely support "0.0.0.0"/"::" and port value of "9" in "c=3D"/"m=3D" lines. This option is documented in JSEP as well, so it seems safer for the WebRTC compatible end points. The main argument against option 2 is that legacy endpoints which are not WebRTC compatible will have no reason to support "0.0.0.0"/"::" and port value of "9" in "c=3D"/"m=3D" lines. This being said, FQDN in a=3Dcandidate is a breaking change either way, sin= ce nobody tested for this before mDNS. If legacy implementations do work with it, it is mostly by accident. I do not see how FQDN in a=3Dcandidate can be rolled out without causing so= me breakage. Finally, using FQDN in a=3Dcandidate was always broken/under-specified in R= FC 5245. The following things in RFC 5245 are missing or broken: 1. ICE Support Verification procedures -- was fixed in ice-sip-sdp by stating that FQDN on c=3D line must never cause the ICE verification failur= e 2. Default candidate selection procedures -- no guidance was provided what address value, address family and type should be specified in the "c=3D" line. mDNS draft specifies using FQDN literal value and always using IN IP4 regardless of the actual address used for FQDN. As we know this is causing breakage with Firefox and can potentially cause breakage with legacy implementations which implemented FQDN candidate support based on RFC 5245 (unclear if such implementations exist). 3. Candidate FQDN assignment procedures, i.e. do not assign FQDN which resolves to more then one address 4. Candidate FQDN resolution procedures in RFC 5245 are broken. Two end points can end up with different addresses if FQDN resolves to multiple addresses or if DNS64, 464XLAT or some other DNS based NAT firewall is present for one of the end points. I think, resolution problem is not fixable unless additional information about address family and type is added to a=3Dcandidate line which uses FQD= N. This will make a=3Dcandidate line orivude the same information as c=3D line= , ending up with something like: a=3Dcandidate:2 1 udp 2129033471 alice.comany.biz 60460 typ host addrype inipv4 a=3Dcandidate:1 1 udp 2129289471 alice.comany.biz 60454 typ host addrype inipv6 If anybody interested I can describe the problem and solution in more details. Best Regards, _____________ Roman Shpount On Mon, Jul 8, 2019 at 7:55 PM Nils Ohlmeier wrote: > Hi Roman, > > I know that not being able to handle FQDN in c-lines is a bug on the > Firefox side. > And we are working on it to fix it: > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1544770 > > But my main question is: why does the draft right now recommend to use th= e > mDNS FQDN in the c-line, rather then a fake IPv4/IPv6 address? > I fail to see the advantage of using the FQDN and it appears to cause mor= e > interop issues. > > Best > Nils Ohlmeier > > On 4Jul, 2019, at 12:26, Roman Shpount wrote: > > Nils, > > When writing ice-sip-sdp we have considered two possible options when > using FQDN in ICE candidate lines: > > 1. Same FQDN as in default ICE candidate > 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9" > > To deal with both, ice-sip-sdp specifies, that when verifying ICE support= , > both options should be accepted. > > Since RFC 5245 provided no guidance regarding handling FQDN in default > candidate, both options would likely cause ICE support verification > failures. Using FQDN in default candidate also raised the question of > address family and address type in c=3D line since neither is specified i= n > the ICE candidate. > > This being said, FQDN in c=3D line is allowed by RFC 4566: > > connection-field =3D [%x63 "=3D" nettype SP addrtype SP > connection-address CRLF] > ;a connection field must be present > ;in every media description or at the > ;session-level > > ; sub-rules of 'c=3D' > connection-address =3D multicast-address / unicast-address > unicast-address =3D IP4-address / IP6-address / FQDN / extn-addr > > Not being able to handle FQDN in the c=3D line is technically a bug. > > Best Regards, > _____________ > Roman Shpount > > > On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier > wrote: > >> Hello, >> >> I have concerns regarding the current recommendations in >> draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP >> addresses in the =E2=80=9Cc=3D=E2=80=9C lines. >> >> Section 3.1.2.3 recommends to use mDNS for the connection-address. I >> think we should reconsider this advice as some SPD parsers handle parsin= g >> failures differently depending on line type. >> In case of Firefox a parsing failure for the connection line is treated >> as terminal failure. Where parsing failures for a=3D lines are expected,= as >> these might contain unknown new features. >> >> Section 4.3 mentions that hostnames in ICE candidates can result in ICE >> failures, but it does not cover backward compatibility in regards to the= c=3D >> line. >> >> My recommendation is to change the draft so that it recommends to always >> use a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in = use. >> Obviously it could also be recommended to use an IP4 address instead. Th= e >> important point is only to use the same IP consistently in all c=3D line= s and >> across all instances. >> I think the advantage of this is better backwards compatibility, and it >> will not reveal any more details about the user agent compared to using >> mDNS names in c=3D lines. >> >> Best regards >> Nils Ohlmeier >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --0000000000009935e0058d351854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nils,

Using FQDN was not my decision= and it is certainly not uncontroversial. As I have mentioned, I see two po= ssible options for address in c=3D line:

1. Same FQDN as in default ICE candidate
2. IPv4/IPv6 address values "0.0.0.0"/&= quot;::" and port value of "9"

The main argument for opt= ion 1, is that it should be compatible with legacy implementations based on= =C2=A0RFC 4566/RFC 5245. There is a question of Verifying ICE Support (h= ttps://tools.ietf.org/html/rfc5245#section-5.1). It is unclear what mat= ching default candidate to a=3Dcandidate supposed to mean when FQDN is used= , but using the same literal value seemed like a safer option.

The main= argument against option 1 is that no one implemented or tested FQDN in a= =3Dcandidate before chrome implemented mDNS candidates, so default candidat= e selection and verifying ICE support was not tested either. I did see mult= iple implementations using FQDN in c=3D line. There are multiple use cases = for this which existed outside of ICE and mDNS.

The main argument for o= ption 2 is that end points that implemented trickle ICE support, would like= ly support=C2=A0 "0.0.0.0"/"::" and port value of "= ;9" in "c=3D"/"m=3D" lines. This option is documen= ted in JSEP as well, so it seems safer for the WebRTC compatible end points= .

The main argument against option 2 is that legacy endpoints which are= not WebRTC compatible will have no reason to support=C2=A0 =C2=A0"0.0.0.0"/"::" and port value of "9"=C2= =A0 =C2=A0in "c=3D"/"m=3D" lines.

This being said, FQDN= in a=3Dcandidate is a breaking change either way, since nobody tested for = this before mDNS. If legacy implementations do work with it, it is mostly b= y accident.

I do not see how FQDN in a=3Dcandidate can be rolled out wi= thout causing some breakage.

Finally, using FQDN in a=3Dcandidate was a= lways broken/under-specified in RFC 5245. The following things in RFC 5245 = are missing or broken:

1. ICE Support Verification procedures -- was fi= xed in ice-sip-sdp by stating that FQDN on c=3D line must never cause the I= CE verification failure

2. Default candidate selection procedures -- no= guidance was provided what address value, address family and type should b= e specified in the "c=3D" line. mDNS draft specifies using FQDN l= iteral value and always using IN IP4 regardless of the actual address used = for FQDN. As we know this is causing breakage with Firefox and can potentia= lly cause breakage with legacy implementations which implemented FQDN candi= date support based on RFC 5245 (unclear if such implementations exist).

3. Candidate FQDN assignment procedures, i.e. do not assign FQDN which res= olves to more then one address=C2=A0
<= br>
4. Candidate FQDN resolution proce= dures in RFC 5245 are broken. Two end points can end up with different addr= esses if FQDN resolves to multiple addresses or if DNS64, 464XLAT or some o= ther DNS based NAT firewall is present for one of the end points.=C2=A0

I think, resolution problem is not fixable unless additional information a= bout address family and type is added to a=3Dcandidate line which uses FQDN= . This will make a=3Dcandidate line orivude the same information as c=3D li= ne, ending up with something like:
a=3Dcandidate:2 1 udp=C2=A02129033471= =C2=A0alice.c= omany.biz=C2=A060460 typ host addrype inipv4
a=3Dcandidate:1 1 udp=C2=A02129289471=C2=A0alice.comany.biz=C2=A060454 typ host addrype=C2=A0inipv6=C2=A0 =C2= =A0

If anybody interested I ca= n describe the problem and solution in more details.

Bes= t Regards,
_____________
Roman Shpount

<= /div>
O= n Mon, Jul 8, 2019 at 7:55 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Hi Roman,
I know that not being able to handle FQDN in c-lines is a bug o= n the Firefox side.
And we are working on it to fix it:=C2=A0https://bugzilla.mozilla.org/show_bug.cgi?id=3D1544770
=
But my main question is: why does the draft right now recomm= end to use the mDNS FQDN in the c-line, rather then a fake IPv4/IPv6 addres= s?
I fail to see the advantage of using the FQDN and it appears t= o cause more interop issues.

Best
=C2=A0= Nils Ohlmeier

On 4Jul, 2019, at= 12:26, Roman Shpount <roman@telurix.com> wrote:

Nils,
When writing ice-sip-sdp we have considered two possible op= tions when using FQDN in ICE candidate lines:

1. S= ame FQDN as in default ICE candidate
2. IPv4/IPv6 address values = "0.0.0.0"/"::" and port value of "9"

To deal with both, ice-sip-sdp specifies, that when verify= ing ICE support, both options should be accepted.

= Since RFC 5245 provided no guidance regarding handling FQDN in default cand= idate, both options would likely cause ICE support verification failures. U= sing FQDN in default candidate also raised the question of address family a= nd address type in c=3D line since neither is specified in the ICE candidat= e.=C2=A0

This being s= aid, FQDN in c=3D line is allowed by RFC 4566:=C2=A0

connection-field =3D =C2=A0 =C2=A0[%x63 "=3D" nettype SP addrt= ype SP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0connection-address CRLF]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;a co= nnection field must be present
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;in every media descriptio= n or at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;session-level

= ; sub-rules of 'c=3D'
connection-address =3D =C2=A0multicast-add= ress / unicast-address
unicast-address =3D =C2=A0 =C2=A0 IP4-= address / IP6-address / FQDN / extn-addr

Not being= able to handle FQDN in the c=3D line is technically a bug.

<= /div>
Best Regards,
_____________
Roman Shpount


On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
He= llo,

I have concerns regarding the current recommendations in draft-ietf-rtcweb-= mdns-ice-candidates-03 regarding the handling of IP addresses in the =E2=80= =9Cc=3D=E2=80=9C lines.

Section 3.1.2.3 recommends to use mDNS for the connection-address. I think = we should reconsider this advice as some SPD parsers handle parsing failure= s differently depending on line type.
In case of Firefox a parsing failure for the connection line is treated as = terminal failure. Where parsing failures for a=3D lines are expected, as th= ese might contain unknown new features.

Section 4.3 mentions that hostnames in ICE candidates can result in ICE fai= lures, but it does not cover backward compatibility in regards to the c=3D = line.

My recommendation is to change the draft so that it recommends to always us= e a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in use. = Obviously it could also be recommended to use an IP4 address instead. The i= mportant point is only to use the same IP consistently in all c=3D lines an= d across all instances.
I think the advantage of this is better backwards compatibility, and it wil= l not reveal any more details about the user agent compared to using mDNS n= ames in c=3D lines.

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

--0000000000009935e0058d351854-- From nobody Mon Jul 8 19:10:16 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1055F120305 for ; Mon, 8 Jul 2019 19:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.204 X-Spam-Level: X-Spam-Status: No, score=-16.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzk555ugDCXR for ; Mon, 8 Jul 2019 19:10:11 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 553AA120395 for ; Mon, 8 Jul 2019 19:10:11 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id u64so2888684vku.8 for ; Mon, 08 Jul 2019 19:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fneUdbjYTpzrusgWILz0TGZAHoYYx3x4FR8N9VlnMv0=; b=VqgYjBg9oawZ7Cnawu+GfIyooZ5+SgWAO4WOSXCQpQ5S+GRghnREVRJ7rHLDinoi6x nK4NupaeXk3cC1Lg8SZeD8yacl1SggVlcF9/vQz7fpQIXgPNLN9FnTwYnjgssd3C7En6 BWCCgtUhavB0xekAM0PBSOkcTsVJNcNnD2ODCZAn7sXDif/FvQ8XqNvOHErP54m40ygQ 0hQ1nUKzhO+eqUfidM0s6Mmh3a4wYOHuLBArufNBCFNDoy2dETULB1Jwxz9lA226w3Gp aZRgx2/wO8z+WgE1B/p3KufXVdUlvRh4a3IVCApy5LvdpHmE9voboyikE11gVlQzqeTi 4iKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fneUdbjYTpzrusgWILz0TGZAHoYYx3x4FR8N9VlnMv0=; b=no8yu04wkUz00RR/NE2DsOFmDqGMRVq9ip9/sx8tNtWVh0B4oz1iAu6DaQNxCKlZgG mCRpabdbUPsJ9p8DmN8+k5H1Hv0ayzp5rGRYREWhznkgzoX1abXMu39YcNJA3mBUiy2w PKYJm4kPlE7fcTaTC8+SwicwMV+ttcfAHQjHBfEOh5O/ULkQYOSrHtW8xkDQuNiwCfeV 69MYTd2i4AJuRkN4uqbDDN5EAMN04V4LnNG7HPHaxjoeAAq5kwuQj0a3EYBW8BkUfXyD 5mVg/r+BK5fr81liEy4BVjzrw5qv9iah/nCPbxw6R4GYEAB4w9UaAvJOjwWgfDSmJ9xg Wt8g== X-Gm-Message-State: APjAAAVBYPuI/mnroqh4rN05VjVCQbxyf8tITvWRg1pQQMJ9pqKzvAha hTddWU802mua02PUcipENbGsq9y6StezZ5M+HYLJAA== X-Google-Smtp-Source: APXvYqzk7ny51k16r+WJUmJzSWaeqUAsfRf+j8L307DZPeU/iiyjhbi1WI6Ly6pyL21FyPMinpL/zeUAPsceO8uXdns= X-Received: by 2002:a1f:9b83:: with SMTP id d125mr7115489vke.76.1562638209846; Mon, 08 Jul 2019 19:10:09 -0700 (PDT) MIME-Version: 1.0 References: <29062AF1-579F-41F2-A2A6-633E4371BF1E@mozilla.com> In-Reply-To: From: Justin Uberti Date: Mon, 8 Jul 2019 19:09:58 -0700 Message-ID: To: Roman Shpount Cc: Nils Ohlmeier , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000698a4d058d360fa5" Archived-At: Subject: Re: [rtcweb] Feedback for draft-ietf-rtcweb-mdns-ice-candidates-03 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 02:10:15 -0000 --000000000000698a4d058d360fa5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2019 at 6:01 PM Roman Shpount wrote: > Hi Nils, > > Using FQDN was not my decision and it is certainly not uncontroversial. A= s > I have mentioned, I see two possible options for address in c=3D line: > > 1. Same FQDN as in default ICE candidate > 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9" > > The main argument for option 1, is that it should be compatible with > legacy implementations based on RFC 4566/RFC 5245. There is a question of > Verifying ICE Support (https://tools.ietf.org/html/rfc5245#section-5.1). > It is unclear what matching default candidate to a=3Dcandidate supposed t= o > mean when FQDN is used, but using the same literal value seemed like a > safer option. > > The main argument against option 1 is that no one implemented or tested > FQDN in a=3Dcandidate before chrome implemented mDNS candidates, so defau= lt > candidate selection and verifying ICE support was not tested either. I di= d > see multiple implementations using FQDN in c=3D line. There are multiple = use > cases for this which existed outside of ICE and mDNS. > > The main argument for option 2 is that end points that implemented trickl= e > ICE support, would likely support "0.0.0.0"/"::" and port value of "9" i= n > "c=3D"/"m=3D" lines. This option is documented in JSEP as well, so it see= ms > safer for the WebRTC compatible end points.. > > The main argument against option 2 is that legacy endpoints which are not > WebRTC compatible will have no reason to support "0.0.0.0"/"::" and por= t > value of "9" in "c=3D"/"m=3D" lines. > > This being said, FQDN in a=3Dcandidate is a breaking change either way, > since nobody tested for this before mDNS. If legacy implementations do wo= rk > with it, it is mostly by accident. > > I do not see how FQDN in a=3Dcandidate can be rolled out without causing > some breakage. > > Finally, using FQDN in a=3Dcandidate was always broken/under-specified in > RFC 5245. The following things in RFC 5245 are missing or broken: > > 1. ICE Support Verification procedures -- was fixed in ice-sip-sdp by > stating that FQDN on c=3D line must never cause the ICE verification fail= ure > > 2. Default candidate selection procedures -- no guidance was provided wha= t > address value, address family and type should be specified in the "c=3D" > line. mDNS draft specifies using FQDN literal value and always using IN I= P4 > regardless of the actual address used for FQDN. As we know this is causin= g > breakage with Firefox and can potentially cause breakage with legacy > implementations which implemented FQDN candidate support based on RFC 524= 5 > (unclear if such implementations exist). > > 3. Candidate FQDN assignment procedures, i.e. do not assign FQDN which > resolves to more then one address > > 4. Candidate FQDN resolution procedures in RFC 5245 are broken. Two end > points can end up with different addresses if FQDN resolves to multiple > addresses or if DNS64, 464XLAT or some other DNS based NAT firewall is > present for one of the end points. > > I think, resolution problem is not fixable unless additional information > about address family and type is added to a=3Dcandidate line which uses > FQDN.. This will make a=3Dcandidate line orivude the same information as = c=3D > line, ending up with something like: > > a=3Dcandidate:2 1 udp 2129033471 alice.comany.biz 60460 typ host addrype > inipv4 > a=3Dcandidate:1 1 udp 2129289471 alice.comany.biz 60454 typ host > addrype inipv6 > > > If anybody interested I can describe the problem and solution in more > details. > I would like to understand this issue better as it relates to mDNS. It's not clear to me that mDNS suffers from this problem. But let's discuss that in a separate email thread or in the mdns-candidates issue tracker, and keep this thread focused on the c=3D line issues. > > Best Regards, > _____________ > Roman Shpount > > > On Mon, Jul 8, 2019 at 7:55 PM Nils Ohlmeier > wrote: > >> Hi Roman, >> >> I know that not being able to handle FQDN in c-lines is a bug on the >> Firefox side. >> And we are working on it to fix it: >> https://bugzilla.mozilla.org/show_bug.cgi?id=3D1544770 >> >> But my main question is: why does the draft right now recommend to use >> the mDNS FQDN in the c-line, rather then a fake IPv4/IPv6 address? >> I fail to see the advantage of using the FQDN and it appears to cause >> more interop issues. >> >> Best >> Nils Ohlmeier >> >> On 4Jul, 2019, at 12:26, Roman Shpount wrote: >> >> Nils, >> >> When writing ice-sip-sdp we have considered two possible options when >> using FQDN in ICE candidate lines: >> >> 1. Same FQDN as in default ICE candidate >> 2. IPv4/IPv6 address values "0.0.0.0"/"::" and port value of "9" >> >> To deal with both, ice-sip-sdp specifies, that when verifying ICE >> support, both options should be accepted. >> >> Since RFC 5245 provided no guidance regarding handling FQDN in default >> candidate, both options would likely cause ICE support verification >> failures. Using FQDN in default candidate also raised the question of >> address family and address type in c=3D line since neither is specified = in >> the ICE candidate. >> >> This being said, FQDN in c=3D line is allowed by RFC 4566: >> >> connection-field =3D [%x63 "=3D" nettype SP addrtype SP >> connection-address CRLF] >> ;a connection field must be present >> ;in every media description or at the >> ;session-level >> >> ; sub-rules of 'c=3D' >> connection-address =3D multicast-address / unicast-address >> unicast-address =3D IP4-address / IP6-address / FQDN / extn-addr >> >> Not being able to handle FQDN in the c=3D line is technically a bug. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Thu, Jul 4, 2019 at 1:26 AM Nils Ohlmeier >> wrote: >> >>> Hello, >>> >>> I have concerns regarding the current recommendations in >>> draft-ietf-rtcweb-mdns-ice-candidates-03 regarding the handling of IP >>> addresses in the =E2=80=9Cc=3D=E2=80=9C lines. >>> >>> Section 3.1.2.3 recommends to use mDNS for the connection-address. I >>> think we should reconsider this advice as some SPD parsers handle parsi= ng >>> failures differently depending on line type. >>> In case of Firefox a parsing failure for the connection line is treated >>> as terminal failure. Where parsing failures for a=3D lines are expected= , as >>> these might contain unknown new features. >>> >>> Section 4.3 mentions that hostnames in ICE candidates can result in ICE >>> failures, but it does not cover backward compatibility in regards to th= e c=3D >>> line. >>> >>> My recommendation is to change the draft so that it recommends to alway= s >>> use a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in= use. >>> Obviously it could also be recommended to use an IP4 address instead. T= he >>> important point is only to use the same IP consistently in all c=3D lin= es and >>> across all instances. >>> I think the advantage of this is better backwards compatibility, and it >>> will not reveal any more details about the user agent compared to using >>> mDNS names in c=3D lines. >>> >>> Best regards >>> Nils Ohlmeier >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000698a4d058d360fa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 8, 2019 at 6:01 PM Roman = Shpount <roman@telurix.com> = wrote:
Hi Nils,

Using FQDN was not my decision and it = is certainly not uncontroversial. As I have mentioned, I see two possible o= ptions for address in c=3D line:

1. Same FQDN as in default ICE candidate
2. IPv4/IPv6 address values "0.0.0.0"/"::&= quot; and port value of "9"
=
The main argument for option 1, i= s that it should be compatible with legacy implementations based on=C2=A0RF= C 4566/RFC 5245. There is a question of Verifying ICE Support (https://t= ools.ietf.org/html/rfc5245#section-5.1). It is unclear what matching de= fault candidate to a=3Dcandidate supposed to mean when FQDN is used, but us= ing the same literal value seemed like a safer option.

The main argumen= t against option 1 is that no one implemented or tested FQDN in a=3Dcandida= te before chrome implemented mDNS candidates, so default candidate selectio= n and verifying ICE support was not tested either. I did see multiple imple= mentations using FQDN in c=3D line. There are multiple use cases for this w= hich existed outside of ICE and mDNS.
=
The main argument for option 2 is= that end points that implemented trickle ICE support, would likely support= =C2=A0 "0.0.0.0"/"::" and port value of "9" i= n "c=3D"/"m=3D" lines. This option is documented in JSE= P as well, so it seems safer for the WebRTC compatible end points..

The= main argument against option 2 is that legacy endpoints which are not WebR= TC compatible will have no reason to support=C2=A0 =C2=A0"0.0.0.0"/"::" and port value of "9"=C2= =A0 =C2=A0in "c=3D"/"m=3D" lines.

This being said, FQDN= in a=3Dcandidate is a breaking change either way, since nobody tested for = this before mDNS. If legacy implementations do work with it, it is mostly b= y accident.

I do not see how FQDN in a=3Dcandidate can be rolled out wi= thout causing some breakage.

Finally, using FQDN in a=3Dcandidate was a= lways broken/under-specified in RFC 5245. The following things in RFC 5245 = are missing or broken:

1. ICE Support Verification procedures -- was fi= xed in ice-sip-sdp by stating that FQDN on c=3D line must never cause the I= CE verification failure

2. Default candidate selection procedures -- no= guidance was provided what address value, address family and type should b= e specified in the "c=3D" line. mDNS draft specifies using FQDN l= iteral value and always using IN IP4 regardless of the actual address used = for FQDN. As we know this is causing breakage with Firefox and can potentia= lly cause breakage with legacy implementations which implemented FQDN candi= date support based on RFC 5245 (unclear if such implementations exist).

3. Candidate FQDN assignment procedures, i.e. do not assign FQDN which res= olves to more then one address=C2=A0
<= br>
4. Candidate FQDN resolution proce= dures in RFC 5245 are broken. Two end points can end up with different addr= esses if FQDN resolves to multiple addresses or if DNS64, 464XLAT or some o= ther DNS based NAT firewall is present for one of the end points.=C2=A0

I think, resolution problem is not fixable unless additional information a= bout address family and type is added to a=3Dcandidate line which uses FQDN= .. This will make a=3Dcandidate line orivude the same information as c=3D l= ine, ending up with something like:
a=3Dcandidate:2 1 udp=C2=A0212= 9033471=C2=A0= alice.comany.biz=C2=A060460 typ host addrype inipv4
a=3Dcandidate:1 1 udp=C2=A02129289471=C2=A0alice.comany.biz=C2=A060454 typ host addr= ype=C2=A0inipv6=C2=A0 =C2=A0

I= f anybody interested I can describe the problem and solution in more detail= s.

I would like to understand this is= sue better as it relates to mDNS. It's not clear to me that mDNS suffer= s from this problem. But let's discuss that in a separate email thread = or in the mdns-candidates issue tracker, and keep this thread focused on th= e c=3D line issues.=C2=A0

Best Regards,
_____________
Rom= an Shpount


=
On Mon, Jul 8, 2019 at 7:55 PM Nils O= hlmeier <nohl= meier@mozilla.com> wrote:
Hi Roman,

I know that not being ab= le to handle FQDN in c-lines is a bug on the Firefox side.
And we= are working on it to fix it:=C2=A0https://bugzilla.mozilla.org/s= how_bug.cgi?id=3D1544770

But my main question = is: why does the draft right now recommend to use the mDNS FQDN in the c-li= ne, rather then a fake IPv4/IPv6 address?
I fail to see the advan= tage of using the FQDN and it appears to cause more interop issues.

Best
=C2=A0 Nils Ohlmeier

On 4Jul, 2019, at 12:26, Roman Shpount <roman@telurix.com> wrot= e:

Nils,

When writing ice-sip-sdp we have considered two possible options wh= en using FQDN in ICE candidate lines:

1. Same FQDN= as in default ICE candidate
2. IPv4/IPv6 address values "0.= 0.0.0"/"::" and port value of "9"

To deal with both, ice-sip-sdp specifies, that when verifying ICE = support, both options should be accepted.

Since RF= C 5245 provided no guidance regarding handling FQDN in default candidate, b= oth options would likely cause ICE support verification failures. Using FQD= N in default candidate also raised the question of address family and addre= ss type in c=3D line since neither is specified in the ICE candidate.=C2=A0=

This being said, FQD= N in c=3D line is allowed by RFC 4566:=C2=A0

conne= ction-field =3D =C2=A0 =C2=A0[%x63 "=3D" nettype SP addrtype SP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0connection-address CRLF]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;a connection= field must be present
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;in every media description or at = the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0;session-level

; sub-r= ules of 'c=3D'
connection-address =3D =C2=A0multicast-address / = unicast-address
unicast-address =3D =C2=A0 =C2=A0 IP4-address= / IP6-address / FQDN / extn-addr

Not being able t= o handle FQDN in the c=3D line is technically a bug.

Best Regards,
____________= _
Roman Shpount


On Thu, Jul 4, 2019 at 1:26 AM Nils= Ohlmeier <no= hlmeier@mozilla.com> wrote:
Hello,

I have concerns regarding the current recommendations in draft-ietf-rtcweb-= mdns-ice-candidates-03 regarding the handling of IP addresses in the =E2=80= =9Cc=3D=E2=80=9C lines.

Section 3.1.2.3 recommends to use mDNS for the connection-address. I think = we should reconsider this advice as some SPD parsers handle parsing failure= s differently depending on line type.
In case of Firefox a parsing failure for the connection line is treated as = terminal failure. Where parsing failures for a=3D lines are expected, as th= ese might contain unknown new features.

Section 4.3 mentions that hostnames in ICE candidates can result in ICE fai= lures, but it does not cover backward compatibility in regards to the c=3D = line.

My recommendation is to change the draft so that it recommends to always us= e a fixed value, for example IP6 ::1 in all c=3D lines, if mDNS is in use. = Obviously it could also be recommended to use an IP4 address instead. The i= mportant point is only to use the same IP consistently in all c=3D lines an= d across all instances.
I think the advantage of this is better backwards compatibility, and it wil= l not reveal any more details about the user agent compared to using mDNS n= ames in c=3D lines.

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000698a4d058d360fa5-- From sean@pion.ly Wed Jul 10 11:06:27 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4B8120626 for ; Wed, 10 Jul 2019 11:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 Pl1QbqU5CWu8 for ; Wed, 10 Jul 2019 11:06:25 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 368071205CD for ; Wed, 10 Jul 2019 11:06:12 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id q4so1604562pgj.8 for ; Wed, 10 Jul 2019 11:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=b117qXXF4Ejqcn3OJ9QrXjFPFgFEjw6MO75OFVvTGEw=; b=cAF9ILkUftXQr++nKwnuMsZekGvBNp27OlL7zWjU/nQc47L8C/OYnE/sI5poCO4KUb /e/miywMbtR5iGmyPDeGe1/2hXP68vacOSLNPIhOtotJVL4bUJR+Fg+j2xpaLSyY+fI3 5ZTZCiazRHrm9YllaRUXwu1nbprWNhx+a4RArUoIXInjd9mpPHVLfaGsU9LAIsHfAd8Y B750Lccky0/MiWwZSrQoQiYiuSIhqktnWfebqOBrj2q9yL8V76eQ9LHwSQobtl8UA1MY rzbXZVAwepiR/JxKDauSW298SVC6UTx5fu3Xwp7SQaO9WIwBbTNHqv37oTot/OBGbMtC XUzA== 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=b117qXXF4Ejqcn3OJ9QrXjFPFgFEjw6MO75OFVvTGEw=; b=ZqPBkc4qSQV8d9keK4ztwoK0rsVcAEfwyNgTY1flVzCemKp2RtKnieqqsCP04gNCow b2tocFo3nDrZHAuPHmuxSqWl6W2p2MYEiucADTBtr5mA8qCn2BfZXBjMy9OVx69J0jKA 8UZPgP/6sMRjfnnxnpThMLNYamkFgHdZXLS+2XbQBYI4ijOnErO4ci2FzRtWVmUbeCEs /REUQKAb2QUHLdL1uBhC5mpPFhT/TtwTSrANYXrEim+rKEaEN0oZ0qWY2WwJEnyjWvtZ o2TLwYGVyGUuw7PaQqEBMmdCS3MBBe5Cx+HQYQlrK/zSvcfM2a7HkF63KoM/oNAmd5vQ WQVQ== X-Gm-Message-State: APjAAAWpaTvP0ntdu3fIjiv9dRa8aSNsRk9bTDetnxqgdmesGXjWWufy Tjh6LeL81vVJXr/VPCmuKiQ0rSUWhznMg6JwX5xfMGuh2r4YPQ== X-Google-Smtp-Source: APXvYqxIdgn7JTH1ZU9TkGHCWpCNWNMeSRA7xfQo7uFTy2sklrpzBCeWHMGd6I+/7KbCfjEgUFq3wForuBls0ujm0GE= X-Received: by 2002:a65:4cc4:: with SMTP id n4mr39752705pgt.307.1562781971251; Wed, 10 Jul 2019 11:06:11 -0700 (PDT) MIME-Version: 1.0 From: Sean DuBois Date: Wed, 10 Jul 2019 19:06:22 +0100 Message-ID: To: rtcweb@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 18:07:52 -0000 Hello, I am Sean DuBois, I work on Pion [0] a 100% Go implementation of WebRTC. I have a user that is trying to do a large deployment, and performance is very important to them. They see a 10x performance improvement when using AEAD GCM for SRTP (thanks to HW acceleration) and is the most obvious improvement we can make. Having this would be a pretty fantastic improvement for very little work. Especially for weak devices/scaling servers, AES-NI is a huge deal. Also great for security, avoids possible timing attacks from software implementation and just less for developers can mess up when implementing SRTP themselves! This also should be pretty painless change. * FireFox already supports it * Chromium is just behind a flag [1] * Most other implementations also use libsrtp (where it is already available) * Adding more protection profiles will have zero impact if they aren't supported. ---- I have never been involved with the IETF before, but this seems the best way to push implementations to support it. [0] https://github.com/pion/webrtc [0] https://bugs.chromium.org/p/chromium/issues/detail?id=713701#c20 From nobody Wed Jul 10 11:25:47 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402851206B0 for ; Wed, 10 Jul 2019 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1qsJFu5g7tor for ; Wed, 10 Jul 2019 11:25:44 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 2A2B81206AC for ; Wed, 10 Jul 2019 11:25:44 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id r1so1460909pfq.12 for ; Wed, 10 Jul 2019 11:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=btR5iKxyya4D2y3dtHviYSYKEWVht1ZTVZ8Dd3HuKzM=; b=CpFgpFZ9JYtXIfGfhAb+a0D1DU7ahHHvLCdPG2NcLZ1prQxnjWEa0sbyaXcNjH0yov 8kgjp5r6j79/SavYTUsR1w1ydReaMY602afHKTVgd3UJARbBo727hHJ7O0t0gzHo2hOH hlD7mOpQhW1sZyJtrw9pQI0lmbS2SQJbAxGHY= 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=btR5iKxyya4D2y3dtHviYSYKEWVht1ZTVZ8Dd3HuKzM=; b=G7I0rEYdMjsh2T5H1X/+zS7Xgf43CqB4v0g9SSob2PaXVOWzp2ZFjJe+X0f1SH2jXh T9KUcEOLsRrwxAqs9nIqbD5GjroCoeveemx6rm0Vn/ZJ6V8A2+ExsOYoit5f8GhqMOv0 1PZXmX7RECUEMLux3xs1cXv1HEkdP6RquaADInduW8g2MpUxfxOpuzc82pUkMxaLTxPJ HjkG9oUIzQ2lVqq/+tRL4g8SRFeJe7iBjKPqLPAYqMfZ9YtZQLj3ifQr8BN6oS3B+aeq r0269V1x5MVHqASLzDoifRrs/ax9ync0yaoP81tsGzNFtsJNlup32WvFl27ZCfTn9s2z Z/JA== X-Gm-Message-State: APjAAAVfyFuh6z5NdMjnJ27IsuX6uAXb+S0L8whHaZeKvocIYsFAWLvc cG2u+B3lKQyZWRD39QQzHd2xlQ== X-Google-Smtp-Source: APXvYqyGO45O2Qw3MTrAd6uarg7pIDUY2uJ61IE/02d/u2fJ74oidbgfuFcdXxfjuJLBJdNp2vtRuA== X-Received: by 2002:a17:90a:25c8:: with SMTP id k66mr8499938pje.129.1562783143408; Wed, 10 Jul 2019 11:25:43 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:4925:c718:26dd:1cd2? ([2620:101:80fc:224:4925:c718:26dd:1cd2]) by smtp.gmail.com with ESMTPSA id o14sm2561284pjp.19.2019.07.10.11.25.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 11:25:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Nils Ohlmeier In-Reply-To: Date: Wed, 10 Jul 2019 11:25:41 -0700 Cc: rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <385683CD-3B17-4A11-8B39-F300FB861964@mozilla.com> References: To: Sean DuBois X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 18:25:46 -0000 Hi Sean, > On 10Jul, 2019, at 11:06, Sean DuBois wrote: >=20 > Hello, > I am Sean DuBois, I work on Pion [0] a 100% Go implementation of > WebRTC. I have a user that is trying to do a large deployment, and > performance is very important to them. They see a 10x performance > improvement when using AEAD GCM for SRTP (thanks to HW acceleration) > and is the most obvious improvement we can make. >=20 > Having this would be a pretty fantastic improvement for very little > work. Especially for weak devices/scaling servers, AES-NI is a huge > deal. Also great for security, avoids possible timing attacks from > software implementation and just less for developers can mess up when > implementing SRTP themselves! >=20 > This also should be pretty painless change. > * FireFox already supports it > * Chromium is just behind a flag [1] > * Most other implementations also use libsrtp (where it is already = available) > * Adding more protection profiles will have zero impact if they aren't > supported. >=20 > ---- > I have never been involved with the IETF before, but this seems the > best way to push implementations to support it. >=20 > [0] https://github.com/pion/webrtc > [0] https://bugs.chromium.org/p/chromium/issues/detail?id=3D713701#c20 As Firefox supports GCM already I=E2=80=99m in favor of adding it to the = spec. AFAIK GCM support in Chrome is behind a flag because they ran into some = interop issues with early GCM implementations. But it is pretty late in the standardization process to make/request = such changes. I=E2=80=99ll leave it to other to judge this. Best Nils Ohlmeier= From nobody Wed Jul 10 13:20:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48AC12004A for ; Wed, 10 Jul 2019 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 sqON45WNyk3C for ; Wed, 10 Jul 2019 13:20:35 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12F512012A for ; Wed, 10 Jul 2019 13:20:34 -0700 (PDT) Received: from [192.168.2.100] (pD9E2CB4B.dip0.t-ipconnect.de [217.226.203.75]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id x6AKKgFE005935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 10 Jul 2019 22:20:44 +0200 To: rtcweb@ietf.org References: <385683CD-3B17-4A11-8B39-F300FB861964@mozilla.com> From: Philipp Hancke Message-ID: Date: Wed, 10 Jul 2019 22:20:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <385683CD-3B17-4A11-8B39-F300FB861964@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 20:20:38 -0000 Am 10.07.19 um 20:25 schrieb Nils Ohlmeier: > As Firefox supports GCM already I’m in favor of adding it to the spec. > > AFAIK GCM support in Chrome is behind a flag because they ran into some interop issues with early GCM implementations. > > But it is pretty late in the standardization process to make/request such changes. I’ll leave it to other to judge this. I don't think we need any mandatory requirement, we have negotiation built in. AES-NI does not require GCM though? I tested GCM with both Chrome and Firefox, found a small bug in the latter (which was quickly fixed by you) but other than that it worked like charm. How chrome solves their "stuff bitrotting behind flags forever" is not an IETF problem thankfully. From nobody Wed Jul 10 15:27:44 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D95112004F for ; Wed, 10 Jul 2019 15:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 EfnvZFviSBma for ; Wed, 10 Jul 2019 15:27:41 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 9C4D0120033 for ; Wed, 10 Jul 2019 15:27:41 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id n9so4095278wrr.4 for ; Wed, 10 Jul 2019 15:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=TS8guhEExd2CCdoY7KoYWF6fzNqS9esRu9UGc5ohgUs=; b=Ep4m3Unbeb5/7hqdGenLeOMJSXuUe3TprD+O1YqKQnAVTo3yqTGamn/b7PZ3pW+PoX 5w5w81TJjv/1QuTQn/OQR20mZLSSSB+y990Io0so2TfLIu8yAXVL/AASYN69l1TTxH2q q6SnTslTzayC05ZO4A613/gCMzRJKZ1GjAPLabEYHl25R++ohYwd3PTSbyTnLz6ewQ+l meaOLyh8JZNz5iqNU1YzyB/g8QOqEl71rMj3LN5o3phqlIfy8hwyE52W8GbRzTgWsAOo cbgIL3xv/187bh727wnsNSebS3TUx+pIjVMCJzyHzVC7OejKQYV7ZtEMSy6aePHn9KNg r6+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=TS8guhEExd2CCdoY7KoYWF6fzNqS9esRu9UGc5ohgUs=; b=kNFjFmDpoQrFqqfOrxfeM8iGUQvjiPwrO83t20hF1K3pr4bXCg+wX1tA7V5lR0pUkF Gy51YZuyfTsr3UXoCk2Gn4ztOclAXYvUVj4co/dZyt8VVpjs/mri6TyBDtMsrH2C8Gra cMGBn1aOWEPOxeUP/4JaS9AyVEGitvNkq44lYKWI4BaJZ1gDBaeHVaqCbM/Qw0hR7Vye tsFgHQjGlhnOeRfADfXz9W7saEsqpu8uoTviwc1EtPQ6aP0ySslNIxEvABjNlWpGNfSk pVTFwCHba3uWCYHDaEZFRHjh+YAYXV6/8ZJxDMztdUe07UiIzcV6psouIXkhECzx8ldQ BeNQ== X-Gm-Message-State: APjAAAXdJcWIsoXLDy+2NbIpVyEoazF1SiGIILPhtIgz7cEsifL35TOA /0rOFZBzxGFr1PDvXus0TpE= X-Google-Smtp-Source: APXvYqysJ7iSzOY4L93Wbw24WUNI6Sm3SsaDM4dRIJyFXLrhA/xk/0h2Rrqw8tuVmcYEvx/shxw4QQ== X-Received: by 2002:adf:f246:: with SMTP id b6mr44803wrp.92.1562797659921; Wed, 10 Jul 2019 15:27:39 -0700 (PDT) Received: from 38f9d359441f.ant.amazon.com ([217.158.151.117]) by smtp.gmail.com with ESMTPSA id 91sm6116033wrp.3.2019.07.10.15.27.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 15:27:38 -0700 (PDT) Date: Wed, 10 Jul 2019 23:28:00 +0100 From: Sean DuBois To: Philipp Hancke Cc: rtcweb@ietf.org Message-ID: <20190710222800.cyjvtkek7rbhy72k@38f9d359441f.ant.amazon.com> References: <385683CD-3B17-4A11-8B39-F300FB861964@mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 22:27:43 -0000 On Wed, Jul 10, 2019 at 10:20:24PM +0200, Philipp Hancke wrote: > Am 10.07.19 um 20:25 schrieb Nils Ohlmeier: > > > > As Firefox supports GCM already I’m in favor of adding it to the spec. > > > > AFAIK GCM support in Chrome is behind a flag because they ran into some interop issues with early GCM implementations. > > > > But it is pretty late in the standardization process to make/request such changes. I’ll leave it to other to judge this. > > I don't think we need any mandatory requirement, we have negotiation built > in. AES-NI does not require GCM though? Agree! I do get hw-accel right now when encrypting, but it is the HMAC-SHA1 for the authentication tag that takes up most of the time. Lots of calls to HMAC-SHA1 for both send/recv I don't know libsrtp well enough, but I assume the situation is the same? > > I tested GCM with both Chrome and Firefox, found a small bug in the latter > (which was quickly fixed by you) but other than that it worked like charm. > > How chrome solves their "stuff bitrotting behind flags forever" is not an > IETF problem thankfully. I am happy to help with this case! I am just hoping if I go the IETF route. It will make it easier to get things merged/enabled in projects. From nobody Wed Jul 10 16:03:17 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4F41200B9 for ; Wed, 10 Jul 2019 16:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.204 X-Spam-Level: X-Spam-Status: No, score=-16.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JqKIPgM7Kz2 for ; Wed, 10 Jul 2019 16:03:13 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 C73971200C7 for ; Wed, 10 Jul 2019 16:03:12 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id o19so1557005uap.13 for ; Wed, 10 Jul 2019 16:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DYmEHmYuqPZCN87lz7AfIx+piw0qe3wlG94JpzROkMs=; b=CZLyttiIqv6/f6tUB+dhVezxfKjprJu5bUV69d4uERe/KYqW88zUrjI6AXsd/LvpKV sv6mYxQDTeALdFiIfZ2bMK8wN2v7AdXFfjgyVyF5/exhFJea9S7o7ONVHPXdW3iHlo8D uYP9ZUcva1hLVLfEtCefrmKwtrkLdG2zmX/iibhlYactwpXgGDC/Z5Q9Sg4nZ1qpDjrm RN+n53RbdVae4utn8F1PZ+MfcQAmKVQTlgBoBZ1Q7rEVV/Ibx6VN0mTMZzXO5N+VRZl8 d/fvshcmesNb392xHZiBAa7QXp4SfH18nvqS2KyMAmzhq2JenXl6lmOEtVlzqOuDosoK t8KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DYmEHmYuqPZCN87lz7AfIx+piw0qe3wlG94JpzROkMs=; b=g93m5JIDuHx7byxb6hhlmIBEedS4+gy//bC9Z4tB9/PKfOisxmAoK2yQ+hIbZLhkXd mmys8DRFG6MhEdVVATpyVBx6WG5gVnxuRTEsOOJNde336bmlX53CuvhDX93z/lu6tysm DrhB6Iy1QxN0PJ0TORcsUdZLYE+tsurxMIUE3NzbP2isdYqrKeuwSxuWcNr6xNCozfrV VJ7KMkSawHcDMHzY+iPSL0qckKYMlndCP0cGVCrY/JL1h+up7ZEYhYg2HZaoxNCNtzah NsEYbmVlX7Uo6o0frkCyTzXdj2NcJ1HF25aYgU4wdOH8yqqTrzYVMr+VZmE48DJ0XMO8 ejFQ== X-Gm-Message-State: APjAAAXyUgusXdAgwISlcFwma8dKqsRUK4122B6aXIxpMjqTM9t+G+3d nmcXoE3zZLB2q0pdIwS4c3384+fKSK90uYO6noXU1A== X-Google-Smtp-Source: APXvYqxoZGRr9bg3LEEXo0UfyqLrcCo8eTAhCj0rhMRSJOj1CFMg+JamJuutcb/tr24ULEvMpe77G65kssR3OydVEgE= X-Received: by 2002:ab0:6e2:: with SMTP id g89mr311547uag.56.1562799791167; Wed, 10 Jul 2019 16:03:11 -0700 (PDT) MIME-Version: 1.0 References: <385683CD-3B17-4A11-8B39-F300FB861964@mozilla.com> <20190710222800.cyjvtkek7rbhy72k@38f9d359441f.ant.amazon.com> In-Reply-To: <20190710222800.cyjvtkek7rbhy72k@38f9d359441f.ant.amazon.com> From: Justin Uberti Date: Wed, 10 Jul 2019 16:02:59 -0700 Message-ID: To: Sean DuBois Cc: Philipp Hancke , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000068bcbb058d5bae1f" Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:03:15 -0000 --00000000000068bcbb058d5bae1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We looked into this in Chrome in https://bugs.chromium.org/p/chromium/issues/detail?id=3D713701, but we decided not to proceed because of the resultant blowup from using the non-truncatable AEAD MAC (16 bytes per packet vs 4/10 for HMAC-SHA1). I think we'd be open to revisiting this if there were obvious performance benefits, but your numbers for HMAC-SHA1 seem unusually bad. For example, "openssl speed sha1" yields 500 MB/s for 256-byte packets on my MacBook Pro, compared to the 28 MB/s that you noted in the bug. "openssl speed aes-128-gcm" does yield 1500 MB/s, so there's clearly some upside here, but it's hard to see this as a must-have. On Wed, Jul 10, 2019 at 3:27 PM Sean DuBois wrote: > On Wed, Jul 10, 2019 at 10:20:24PM +0200, Philipp Hancke wrote: > > Am 10.07.19 um 20:25 schrieb Nils Ohlmeier: > > > > > > > As Firefox supports GCM already I=E2=80=99m in favor of adding it to = the spec. > > > > > > AFAIK GCM support in Chrome is behind a flag because they ran into > some interop issues with early GCM implementations. > > > > > > But it is pretty late in the standardization process to make/request > such changes. I=E2=80=99ll leave it to other to judge this. > > > > I don't think we need any mandatory requirement, we have negotiation > built > > in. AES-NI does not require GCM though? > Agree! I do get hw-accel right now when encrypting, but it is the HMAC-SH= A1 > for the authentication tag that takes up most of the time. > > Lots of calls to HMAC-SHA1 for both send/recv > > I don't know libsrtp well enough, but I assume the situation is the same? > > > > > I tested GCM with both Chrome and Firefox, found a small bug in the > latter > > (which was quickly fixed by you) but other than that it worked like > charm. > > > > How chrome solves their "stuff bitrotting behind flags forever" is not = an > > IETF problem thankfully. > I am happy to help with this case! I am just hoping if I go the > IETF route. It will make it easier to get things merged/enabled in > projects. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000068bcbb058d5bae1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We looked into this in Chrome in=C2=A0ht= tps://bugs.chromium.org/p/chromium/issues/detail?id=3D713701, but we de= cided not to proceed because of the resultant blowup from using the non-tru= ncatable AEAD MAC (16 bytes per packet vs 4/10 for HMAC-SHA1).

I think we'd be open to revisiting this if there were obvious pe= rformance benefits, but your numbers for HMAC-SHA1 seem unusually bad. For = example, "openssl speed sha1" yields 500 MB/s for 256-byte packet= s on my MacBook Pro, compared to the 28 MB/s that you noted in the bug. &qu= ot;openssl speed aes-128-gcm" does yield 1500 MB/s, so there's cle= arly some upside here, but it's hard to see this as a must-have.
<= /div>
O= n Wed, Jul 10, 2019 at 3:27 PM Sean DuBois <sean@pion.ly> wrote:
On Wed, Jul 10, 2019 at 10:20:24PM +0200,= Philipp Hancke wrote:
> Am 10.07.19 um 20:25 schrieb Nils Ohlmeier:
> <snip/>
>
> > As Firefox supports GCM already I=E2=80=99m in favor of adding it= to the spec.
> >
> > AFAIK GCM support in Chrome is behind a flag because they ran int= o some interop issues with early GCM implementations.
> >
> > But it is pretty late in the standardization process to make/requ= est such changes. I=E2=80=99ll leave it to other to judge this.
>
> I don't think we need any mandatory requirement, we have negotiati= on built
> in. AES-NI does not require GCM though?
Agree! I do get hw-accel right now when encrypting, but it is the HMAC-SHA1=
for the authentication tag that takes up most of the time.

Lots of calls to HMAC-SHA1 for both send/recv

I don't know libsrtp well enough, but I assume the situation is the sam= e?

>
> I tested GCM with both Chrome and Firefox, found a small bug in the la= tter
> (which was quickly fixed by you) but other than that it worked like ch= arm.
>
> How chrome solves their "stuff bitrotting behind flags forever&qu= ot; is not an
> IETF problem thankfully.
I am happy to help with this case! I am just hoping if I go the
IETF route. It will make it easier to get things merged/enabled in projects= .

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000068bcbb058d5bae1f-- From nobody Wed Jul 10 16:13:01 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB884120222 for ; Wed, 10 Jul 2019 16:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 bW1d9NyTd2aB for ; Wed, 10 Jul 2019 16:12:56 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 62C79120019 for ; Wed, 10 Jul 2019 16:12:56 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id m14so3302228qka.10 for ; Wed, 10 Jul 2019 16:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=A0XHSpixICVbjRK0+bv6tivEPBsS0B6bFXoUVmUiV2o=; b=dXSdmsZJtFgu8XNGz/EeGL8FqDNn9dNrdeyvk1PukghjWCGCLc5tIUud5Q0m23Dyq9 1/z8cnLBacMMHYycONL+MAjVqg/IUrXEdgjp0F4E2Zovpgjcq1JFNSvUTtmOEuuWFf27 dQpizdALrqetAo1NWhHvJa4rDqu4U+3ptZl6E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=A0XHSpixICVbjRK0+bv6tivEPBsS0B6bFXoUVmUiV2o=; b=paRMPY0c/S8yf8VdsUBXD7AnG8QpLEycyv70iMyp+j6qngVme2C6WWc961RriSq9Rk KbIjB2tMGpz3HxIrHmhaw/zmmw0S173U6s0EN6Z2XrWDkUA8/5MoinuC0Y84TpZiOiLi CTdx0/Qq1lwlNIBsCOxJf4kSUwgiURryoPmMKAYyg+w3aIevLMiGkd/m/XIyd/7NIyK8 WWL2W3SihkxTryVybBPkOsNu4zNcC/WUek2yUeZ6nlfxhgIKZzSQKhufQbuoOg23POuj KG3CIusPINT4Rzj9y6mtDdruZ6cigB9zwd7BragCroMQKc2Du70qIUjHRJ55QODCv1G2 sczQ== X-Gm-Message-State: APjAAAWeN1svuuibGiY0zuyKH0ays3jMqJvaT2cefO0/qEXwHGApNrjw 9z6jegN3TnqZ6uO4fHePeTTZgJ6P X-Google-Smtp-Source: APXvYqwr5qO+SckZ9wYqzlFN664sNa+ZAj4n5DQGEPTpSm/e4t5ZgJ72gaX4DywZ6h86CTVuaFqebw== X-Received: by 2002:a37:a010:: with SMTP id j16mr641282qke.152.1562800374986; Wed, 10 Jul 2019 16:12:54 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id m4sm1610266qka.70.2019.07.10.16.12.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 16:12:54 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <545FC32C-D601-4888-80E9-BF615FE98BD0@sn3rd.com> Date: Wed, 10 Jul 2019 19:12:49 -0400 To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-security-arch: Final PRs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 23:12:58 -0000 Hi! ekr has spun a new version of draft-ietf-rtcweb-security-arc [0]. = All of the changes were to address the outstanding IESG DISCUSS = positions or were a result of following on discussions with Ben K = (Security AD). While I think all of these are good changes, there were = three changes that affected 2119-language and we need to get the WGs = take on these. Two of these changes are in s5.1.4 (SHOULD->MUST and = the addition of a new MUST) and one is in s7.6 (addition of a new = SHOULD). These are most easily seen by looking at the diffs [1]. If = you object to these changes, then please let the list know by July 22nd. Note that these are the last issues remaining before this draft as well = as draft-ietf-rtcweb-security and draft-ietf-rtcweb-ip-handling can move = into the RFC editor=E2=80=99s queue. At that point we will be = dangerously close to be done. Thanks, spt [0] https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ [1] = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-rtcweb-security-arch-18&url= 2=3Ddraft-ietf-rtcweb-security-arch-19= From nobody Thu Jul 11 00:21:47 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC944120045 for ; Thu, 11 Jul 2019 00:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=lowentropy.net header.b=S+s0jOcV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AMDxU4T7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrVaB8SMg_ha for ; Thu, 11 Jul 2019 00:21:43 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9AC5120018 for ; Thu, 11 Jul 2019 00:21:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 49EF322007 for ; Thu, 11 Jul 2019 03:21:41 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 11 Jul 2019 03:21:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=50I9wUsFYg+6IZAbcwMFVkiJrCC0eX1 FZCL5V7KVoUI=; b=S+s0jOcVBFCFqP4huUUbONouNzD5xHw5grPpGpqfiac1ig6 yLryRjjUE6iQwbFBU96n4DREoHSW0Hs3rGgDYOWXYsVVeSt2CKVEl68H8WzXX5WA 1SNJ6AwY9AgqrMrPSJOiqzorHRkOOwdElRV1u9W9HZTVYEWesUXIBbVW6PA1hU5x TqxMyYPo817z+ZsBFDOh1I64w4St6FHdM8NJx50Zz91ik4nK/EV/Pu6UMr/oA6G6 P2090nHH6MvI9z4Yw7Wdcb8bI6v206plXe59AM91QxgdSuPk7pCvMlqqGjLnG9Yj 6V60LjWnZjDyYfevlqG5qxvE8PRcIdB4AtZyJ9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=50I9wU sFYg+6IZAbcwMFVkiJrCC0eX1FZCL5V7KVoUI=; b=AMDxU4T7ZSl+ZDoOOLTRmL Lt1ZkcJH5yHV0xT15Kzy0oUJD6d19OFGTgvEPBkxKpWJLw9gebKb0PEDxUTHkF7T TmXhNBnYn1/mcvMw894tFUce8VXxK8WWWG+UBI77jJLSCifyR1Fpe223wQHya1I7 wMAWKyJpXnZAZdaRSu5jbTD8kf7X7Xnx9roERO27TRlg2v+pg3XPs/FQk+bhnUEK YL+9qRea+XeiGTHhU7yF2kXDZ8VLZSUd2uHt98TB9ic4EB8m1kBSWHjJtq2KLqRB UW7teD0eO/B9RaYRETl5uo1jpnwpMk85P/1G4td4xDkRTZUVaafjaD0AkDfADj4Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeejgdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinheptghhrhhomhhiuhhmrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C3392E0162; Thu, 11 Jul 2019 03:21:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <385683CD-3B17-4A11-8B39-F300FB861964@mozilla.com> <20190710222800.cyjvtkek7rbhy72k@38f9d359441f.ant.amazon.com> Date: Thu, 11 Jul 2019 17:21:40 +1000 From: "Martin Thomson" To: rtcweb@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:21:45 -0000 On Thu, Jul 11, 2019, at 09:03, Justin Uberti wrote: > We looked into this in Chrome in > https://bugs.chromium.org/p/chromium/issues/detail?id=713701, but we > decided not to proceed because of the resultant blowup from using the > non-truncatable AEAD MAC (16 bytes per packet vs 4/10 for HMAC-SHA1). I don't find the extra bytes that big of a deal, across an entire PMTU-sized packet, it's not significant. I'm sure you can say that it makes a difference in terms of responsiveness or number of packets, but it's <0.5% of a modest MTU for the 10 vs. 16 comparison. 32-bit auth tags are pretty ridiculous if you think that authenticity is a valid goal. We're considering turning them off entirely. That said, if we had a cipher with a shorter tag that wasn't awful, I'd probably concede that maybe we could have fewer than 128 bits of tag for time-sensitive applications. > I think we'd be open to revisiting this if there were obvious > performance benefits, but your numbers for HMAC-SHA1 seem unusually > bad. For example, "openssl speed sha1" yields 500 MB/s for 256-byte > packets on my MacBook Pro, compared to the 28 MB/s that you noted in > the bug. "openssl speed aes-128-gcm" does yield 1500 MB/s, so there's > clearly some upside here, but it's hard to see this as a must-have. Keep in mind that you are running AES in counter mode and HMAC-SHA1 will add an extra invocation per packet (which is small, but noticeable), so a better comparison would be GHASH with SHA1. With acceleration GHASH is much faster. Without, it's is slower, but most modern machines have carryless multiply instructions. AES-GCM runs at about a cycle per byte with native instruction support. SHA-1 can get close to that on the very latest CPUs, but even CPUs from last year are twice as slow. So add AES-CTR and that is consistent with your measurements. Only for the oldest machines (like a 2012 ARM chip, for instance) will AES-CTR+HMAC-SHA-1 start to be comparable to the performance of a constant-time AES-GCM. From nobody Thu Jul 11 00:22:24 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330E1120045 for ; Thu, 11 Jul 2019 00:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 KEGaEsW0IFI7 for ; Thu, 11 Jul 2019 00:22:21 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED15120018 for ; Thu, 11 Jul 2019 00:22:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 915FF7C0C77 for ; Thu, 11 Jul 2019 09:22:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqP6al7ZdqQg for ; Thu, 11 Jul 2019 09:22:17 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 313D47C0896 for ; Thu, 11 Jul 2019 09:22:17 +0200 (CEST) To: rtcweb@ietf.org References: From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <3f1e01bf-1119-a912-2449-1329ee253b00@alvestrand.no> Date: Thu, 11 Jul 2019 09:22:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 07:22:23 -0000 Once cluster 238 is published, I'm in favor of looking at the mandatory-to-implement ciphersuites in RTCWEB and consider updating them. It's been a few years since we went through that exercise. I am not in favor of proposing changes to the current documents. Den 10.07.2019 20:06, skrev Sean DuBois: > Hello, > I am Sean DuBois, I work on Pion [0] a 100% Go implementation of > WebRTC. I have a user that is trying to do a large deployment, and > performance is very important to them. They see a 10x performance > improvement when using AEAD GCM for SRTP (thanks to HW acceleration) > and is the most obvious improvement we can make. > > Having this would be a pretty fantastic improvement for very little > work. Especially for weak devices/scaling servers, AES-NI is a huge > deal. Also great for security, avoids possible timing attacks from > software implementation and just less for developers can mess up when > implementing SRTP themselves! > > This also should be pretty painless change. > * FireFox already supports it > * Chromium is just behind a flag [1] > * Most other implementations also use libsrtp (where it is already available) > * Adding more protection profiles will have zero impact if they aren't > supported. > > ---- > I have never been involved with the IETF before, but this seems the > best way to push implementations to support it. > > [0] https://github.com/pion/webrtc > [0] https://bugs.chromium.org/p/chromium/issues/detail?id=713701#c20 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Jul 11 04:00:27 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696A512011E for ; Thu, 11 Jul 2019 04:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pion-ly.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 ggRpS-e1yxca for ; Thu, 11 Jul 2019 04:00:23 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 7DD45120307 for ; Thu, 11 Jul 2019 04:00:23 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id u19so11512225ior.9 for ; Thu, 11 Jul 2019 04:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pion-ly.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AGx6can113ieyW2bllJlbhe1Vl9zt69JkXaELRnGzz0=; b=B0dy+giRHH5A0xEQZoRNZuAltajxo9jNFVqWk/hXCNoSm2/UTG++eVphpckojawB9s tEuMpCWjFaPyDP/1xJJbn1OGEEOw6ZYWzjUfLkI/s6LyLtodZgzw8Mo1T41emRwSL5L6 G/kDvvKwPT7ct/fg57UO9FNItelXsAdXzt/EdzUPIR0Nl1KBapOQo3CJv9sv3u8ofaMp OX9Fb4TnuMdE3zQ3ZWt7vnMCohSKzQVjb0r8phGZP7J7ghzoEuUVg/gG1ylA1FO+oZaf NDnLSpZUhhA4cehEczk3UO2BI2nkaeKw7efci997S+BT8KaXwzCdtE9suwl6FgD9OFTc VXBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AGx6can113ieyW2bllJlbhe1Vl9zt69JkXaELRnGzz0=; b=QuFR4vqcAmXgyzW7Y8jWzfhaCsbGzfwJ9yuFZFeee689j19ZiTT8RxpjWqXGIqgv53 ALeIGm60fyucHCIKMta9DXfiYukYHmElj3IU3V4DKjWhmEnB8y3QpywtdJtsvHr33W3n 7TAAJGj9oLZ3OEnfvGfgz5orBWTlvyPyZV1A1e6t0PjxEQ6RFEjfaiSMx9j7IHr9xqBN bnpEnujTLH2lHQJkIqAS8T4PzT/EPWJv1Lajzy/bj6t5d2Y1tU6dZxoRDVlKmBP+fxsu wid5ppPSWFHcoZV+2gL2mkq9u1EF7JtNbk6vIDM/ET4S5yrXathxfJsQ5pstnPHPMB9t U1VQ== X-Gm-Message-State: APjAAAXU9gBjT3248SjhYMy57wolL5WJCNxACHGL+gSjyatOAWWbKRJk bcca+GzUWOzxZZoGPtu+yoQ= X-Google-Smtp-Source: APXvYqzAUj/+KZFrudN7xGtvNrrU75Mx9tficJp5I37j5/s2QQjuw9q9DJSH1irgVpWcCMvTvLNRmQ== X-Received: by 2002:a6b:8f47:: with SMTP id r68mr3782748iod.204.1562842822610; Thu, 11 Jul 2019 04:00:22 -0700 (PDT) Received: from 38f9d359441f.ant.amazon.com ([8.46.76.46]) by smtp.gmail.com with ESMTPSA id b20sm4047524ios.44.2019.07.11.04.00.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 04:00:21 -0700 (PDT) Date: Thu, 11 Jul 2019 12:00:28 +0100 From: Sean DuBois To: Justin Uberti Cc: Philipp Hancke , RTCWeb IETF Message-ID: <20190711110028.oj3mv7mamafzrauj@38f9d359441f.ant.amazon.com> References: <385683CD-3B17-4A11-8B39-F300FB861964@mozilla.com> <20190710222800.cyjvtkek7rbhy72k@38f9d359441f.ant.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 11:00:26 -0000 On Wed, Jul 10, 2019 at 04:02:59PM -0700, Justin Uberti wrote: > We looked into this in Chrome in > https://bugs.chromium.org/p/chromium/issues/detail?id=713701, but we > decided not to proceed because of the resultant blowup from using the > non-truncatable AEAD MAC (16 bytes per packet vs 4/10 for HMAC-SHA1). > > I think we'd be open to revisiting this if there were obvious performance > benefits, but your numbers for HMAC-SHA1 seem unusually bad. For example, > "openssl speed sha1" yields 500 MB/s for 256-byte packets on my MacBook > Pro, compared to the 28 MB/s that you noted in the bug. "openssl speed > aes-128-gcm" does yield 1500 MB/s, so there's clearly some upside here, but > it's hard to see this as a must-have. > Here are my numbers using libsrtp, still pretty significant I think! People have fought a lot harder for much smaller improvements. -- aes_cm_128_hmac_sha1_32 ./a.out 1.83s user 0.01s system 99% cpu 1.843 total ./a.out 1.84s user 0.01s system 99% cpu 1.856 total ./a.out 1.83s user 0.00s system 99% cpu 1.837 total ./a.out 1.82s user 0.01s system 99% cpu 1.831 total ./a.out 2.04s user 0.01s system 99% cpu 2.065 total ./a.out 1.82s user 0.01s system 99% cpu 1.834 total ./a.out 1.84s user 0.01s system 99% cpu 1.857 total ./a.out 1.83s user 0.00s system 99% cpu 1.843 total ./a.out 1.85s user 0.01s system 99% cpu 1.860 total ./a.out 1.83s user 0.01s system 99% cpu 1.839 total -- aes_gcm_128_16 ./a.out 0.76s user 0.00s system 99% cpu 0.772 total ./a.out 0.81s user 0.00s system 99% cpu 0.814 total ./a.out 0.75s user 0.00s system 99% cpu 0.762 total ./a.out 0.75s user 0.01s system 99% cpu 0.760 total ./a.out 0.76s user 0.00s system 99% cpu 0.765 total ./a.out 0.76s user 0.00s system 99% cpu 0.765 total ./a.out 0.79s user 0.01s system 99% cpu 0.803 total ./a.out 0.77s user 0.01s system 99% cpu 0.780 total ./a.out 0.75s user 0.00s system 99% cpu 0.762 total ./a.out 0.79s user 0.01s system 99% cpu 0.796 total Hopefully my test is good, whipped it up while waiting for my flight. https://gist.github.com/Sean-Der/7a42bd70edfe1324ccc6ab399d653c0e From nobody Thu Jul 11 17:07:23 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C77120155 for ; Thu, 11 Jul 2019 17:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 fGqdNmUcoV_g for ; Thu, 11 Jul 2019 17:07:19 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 837A512011B for ; Thu, 11 Jul 2019 17:07:19 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id r6so2170974qtt.0 for ; Thu, 11 Jul 2019 17:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=oV/X+d/a2lPVuq6djEvIht5SIkQ5dUR71xuhAxu6T2Y=; b=FXvF5mspL+ULsCK39O1F+kfEV9Eqcl3Y4lshKc+bFOVsGHkZwU0xnUVjA2mbCQJib7 xeb2kkw4P4MFFk4c4gx/AcLM5d31fFqRQfUFYRq2d1tzi1Sq2Jjr08iic46bmgUJEAiu 1P3GLrP8JgJ15dZD5/v/7vNgmeRk3qkAJ6md8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=oV/X+d/a2lPVuq6djEvIht5SIkQ5dUR71xuhAxu6T2Y=; b=Y031Nn/lPkbfNgd+b6vGuIcUgf+XFP0C4e/ydRMeuiWeobX7S51QYy09uchzvXxCgv yGFTaeN5oGEX0aiV+AV273WwmgntziNLxCFRnv6MbAeiH98M87bVwUzmOQ/qqbNxJBK3 Z3SPAnYfrDJELv6uED1MYsoZXFvlepCieb/mXw/H0ozO7dhCYPOCI4qEusbWLqMDHO2Q BippD2NIGiR8FoGSk7RWKuUyoAqrvbBSOu0lCpcr5LE++z10RO5+zM1iVD3EPHKgLFap E/BfeVBzujS+Erf4hCxPB5u3Tq6cWw8OEbCUkTgyIr3XC/TnjFA07V6nE2hUczKuYE+x NBfw== X-Gm-Message-State: APjAAAVZFd9FC8rjmAdVZ5/WaaACFiMkDjAv6TziMITFzrAs5xpgQc+D nCEKhnp5HjdQuyEDaJBMMU2fSaLi X-Google-Smtp-Source: APXvYqwfnJYFNAUANklD7gyAKs6pWZxS7ripzk6PBtEE18XaRl3iPPexJEQFtrdiCvj7Wr6uOiYVPg== X-Received: by 2002:ac8:688:: with SMTP id f8mr3988979qth.130.1562890038442; Thu, 11 Jul 2019 17:07:18 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id z19sm3114553qkg.28.2019.07.11.17.07.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 17:07:17 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 20:07:17 -0400 References: <3f1e01bf-1119-a912-2449-1329ee253b00@alvestrand.no> To: RTCWeb IETF In-Reply-To: <3f1e01bf-1119-a912-2449-1329ee253b00@alvestrand.no> Message-Id: <9C56BC65-852C-406C-B1CB-AB692C25F522@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 00:07:21 -0000 Hi, I think there=E2=80=99s general consensus that we should be updating the = algorithm requirements every couple of years after the specifications = are published. But, we have not yet actually published cluster 238 yet. = We need to get that done first and then we should entertain updates; it = is never as easy as one thinks it is to update the MTIs. spt > On Jul 11, 2019, at 03:22, Harald Alvestrand = wrote: >=20 > Once cluster 238 is published, I'm in favor of looking at the > mandatory-to-implement ciphersuites in RTCWEB and consider updating > them. It's been a few years since we went through that exercise. >=20 > I am not in favor of proposing changes to the current documents. >=20 > Den 10.07.2019 20:06, skrev Sean DuBois: >> Hello, >> I am Sean DuBois, I work on Pion [0] a 100% Go implementation of >> WebRTC. I have a user that is trying to do a large deployment, and >> performance is very important to them. They see a 10x performance >> improvement when using AEAD GCM for SRTP (thanks to HW acceleration) >> and is the most obvious improvement we can make. >>=20 >> Having this would be a pretty fantastic improvement for very little >> work. Especially for weak devices/scaling servers, AES-NI is a huge >> deal. Also great for security, avoids possible timing attacks from >> software implementation and just less for developers can mess up when >> implementing SRTP themselves! >>=20 >> This also should be pretty painless change. >> * FireFox already supports it >> * Chromium is just behind a flag [1] >> * Most other implementations also use libsrtp (where it is already = available) >> * Adding more protection profiles will have zero impact if they = aren't >> supported. >>=20 >> ---- >> I have never been involved with the IETF before, but this seems the >> best way to push implementations to support it. >>=20 >> [0] https://github.com/pion/webrtc >> [0] https://bugs.chromium.org/p/chromium/issues/detail?id=3D713701#c20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jul 12 03:19:57 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5681120169 for ; Fri, 12 Jul 2019 03:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=lowentropy.net header.b=BxdRlFLe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ef7g/s6x Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG_oFh4ODkIJ for ; Fri, 12 Jul 2019 03:19:54 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A319B120113 for ; Fri, 12 Jul 2019 03:19:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9CC7022289 for ; Fri, 12 Jul 2019 06:19:52 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 12 Jul 2019 06:19:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=2cc2i 0euzVgNd4NeB2wMoK2+/Mx2TfAheNK6RQ0yRmY=; b=BxdRlFLewmWwUONmfyG7C 1sAbw8yIBII+Og4v3CbGROfz0jO4kstfhTsv/rXJuSnGASUgcjkHxXK0/+tJCeFL VNZ3iQS2YxNz+vbcI/ThLbSMCWZl1Nj/9nZGZKi7OzmU/Lv5Tqx16WqcL5n+HUsm cstRtosYI3PbyZQmveF0YLYByWlPYQPVlOqDL/rEkVqZGAbonozZcp1/sMaG1F1I RTxMpWw2h3mocJm/4oUEs0tgo4sKsvAxCUvHVlt3OnO2o6ea8WotNNcgPe9uI65F AOnu7LLUDOSVvoXQ5iBJaBYYyDf4B0ZiY0useeWK27ojIiHe8ze4tuHgnDQCnMRm g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=2cc2i0euzVgNd4NeB2wMoK2+/Mx2TfAheNK6RQ0yR mY=; b=ef7g/s6xaBJjYvMROolG+gxDRM3lzpBc2i/HyWwWg/DJX2PhNMrdqpzrH LWnrpJWp+e+drPRle4HLPgmeSaOkROg2JnhD+POMHh8684qxvzXOr8IimbQNZ/7K OQa7rwFzx1fm/ol38BZ4kWlcJqVV6EhjGklC851oLs0aGIfJ+t+GaKkMpRUDbVGQ jLaeuLx8NIlqvi4bDC2NlFQoP4Os+wUJaAVGgAhqYkmNOHScWmsGwRMBRWPr9hOL Rp4g01aa+wklZTdmc6e74wrnIyR2VBRE0RZSR+7rOGAvZshULQcrm45m2L18kc+G 6Tz5NR0KH2y/m5aiWJSjw4YUkH8Sw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrhedtgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3B054E0128; Fri, 12 Jul 2019 06:19:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <9C56BC65-852C-406C-B1CB-AB692C25F522@sn3rd.com> References: <3f1e01bf-1119-a912-2449-1329ee253b00@alvestrand.no> <9C56BC65-852C-406C-B1CB-AB692C25F522@sn3rd.com> Date: Fri, 12 Jul 2019 20:19:52 +1000 From: "Martin Thomson" To: rtcweb@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Require/Suggest AEAD GCM for SRTP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 10:19:56 -0000 On Fri, Jul 12, 2019, at 10:07, Sean Turner wrote: > I think there=E2=80=99s general consensus that we should be updating t= he=20 > algorithm requirements every couple of years after the specifications=20= > are published. But, we have not yet actually published cluster 238=20= > yet. We need to get that done first and then we should entertain=20 > updates; it is never as easy as one thinks it is to update the MTIs. This sounds like a great policy. 238 will take long enough that we shou= ld have some time to consider our options more fully. Maybe we also hav= e enough time to do something about finding an AEAD with a smaller authe= ntication tag that can be used here. From nobody Fri Jul 12 15:02:02 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF06E120043; Fri, 12 Jul 2019 15:02:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156296892097.5326.6767185585466717190.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2019 15:02:00 -0700 Archived-At: Subject: [rtcweb] Protocol Action: 'WebRTC IP Address Handling Requirements' to Proposed Standard (draft-ietf-rtcweb-ip-handling-12.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 22:02:01 -0000 The IESG has approved the following document: - 'WebRTC IP Address Handling Requirements' (draft-ietf-rtcweb-ip-handling-12.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ Technical Summary This draft provides information and requirements for how IP addresses should be handled by WebRTC implementations. This is a companion draft to the two security-related drafts, but it was kept separate to this draft to change more quickly. The security drafts are standards track and so is this one. Working Group Summary This document has been extensively reviewed both on the list at a numerous in-person WG meetings. This document is controversial because it deals with privacy and user consent issues related to Browsers. There are strong feelings about the draft’s contents and what we have arrived at is rough consensus. Document Quality WebRTC, including its underlying security and privacy model, has been implemented by all major web browsers. Personnel Sean Turner is the Shepherd. Adam Roach is the responsible AD. From nobody Fri Jul 12 15:04:00 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE5C120892; Fri, 12 Jul 2019 15:03:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , draft-ietf-rtcweb-security@ietf.org, rtcweb@ietf.org, sean@sn3rd.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156296902197.5372.8701455770966912792.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2019 15:03:41 -0700 Archived-At: Subject: [rtcweb] Protocol Action: 'Security Considerations for WebRTC' to Proposed Standard (draft-ietf-rtcweb-security-12.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 22:03:45 -0000 The IESG has approved the following document: - 'Security Considerations for WebRTC' (draft-ietf-rtcweb-security-12.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ Technical Summary This document describes the security considerations for WebRTC. This draft is bound standards track because it includes all of the WebRTC security considerations and will referred to from all WebRTC WG drafts. Working Group Summary This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. Document Quality WebRTC, including its underlying security and privacy model, has been implemented by all major web browsers. Personnel Sean Turner is the Shepherd. Adam Roach is the responsible AD. From nobody Fri Jul 12 16:00:03 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2812026D for ; Fri, 12 Jul 2019 16:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 AfUJhxz_Wh7o for ; Fri, 12 Jul 2019 16:00:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0B2120147 for ; Fri, 12 Jul 2019 16:00:00 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6CMxkQm090264 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Jul 2019 17:59:47 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562972390; bh=ZThPh1DQtPNLWLSNJySOujcLFv12flvpm27kHPL74+A=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PZpI0gL1sAaPek2VqEo1qW4sqlKb1hThiEqfl/WYFT/ikONDXZLfh3ehVa4k1lsuB GOOYfzz4m9UQ+QkNzF7qqsanbO32QX1cvHlRn2uVhRniA+v5+SKC5qs4QkSTPvy1YN KAZvV0PTir2mLWGd/BxUVmb6GcFpoP+yC04oQhN0= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Harald Alvestrand , Sean Turner Cc: "rtcweb@ietf.org" References: <02b5b7c2-dde2-6ff0-06fa-bcaf10a0030b@alvestrand.no> From: Adam Roach Message-ID: Date: Fri, 12 Jul 2019 17:59:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <02b5b7c2-dde2-6ff0-06fa-bcaf10a0030b@alvestrand.no> Content-Type: multipart/alternative; boundary="------------5FEEEEEF4E69B2741167E91E" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Request for status update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 23:00:02 -0000 This is a multi-part message in MIME format. --------------5FEEEEEF4E69B2741167E91E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/4/19 5:54 AM, Harald Alvestrand wrote: > Can you assure me that -4566bis, -clue-protocol, -rmcat-eval-criteria > and -ice-sip-sdp are not blockers for pushing out the rest of the 238 > cluster? As that's a bit outside a single WG's area, I'll answer this as AD. First, I'll discuss the CLUE subcluster: * The CLUE documents (both protocol and signaling) have dependencies into the cluster, but nothing outside of CLUE refers to them. They will remain in the cluster, but not block publication of anything except for other CLUE documents. * draft-ietf-mmusic-rfc4566bis only blocks draft-ietf-mmusic-data-channel-sdpneg, which is a part of the cluster by virtue of it being a CLUE dependency. The documents draft-rmcat-eval-criteria and draft-rmcat-wireless-tests are  dependencies for draft-ietf-rmcat-eval-test. That document, in turn, is part of the cluster because it has dependencies pointing into the cluster. No dependencies point outward towards draft-ietf-rmcat-eval-test, so these two documents do not block publication of the WebRTC portion of the cluster. Draft-ietf-mmusic-ice-sip SDP is a blocker for most documents in Cluster 238, as it is a strictly necessary normative dependency for BUNDLE [1]. It is on the August 8th IESG formal telechat. /a ____ [1] This structure may seem odd at first, and it is almost certainly not how one would have structured documents if one were to have designed the whole cluster up front. However, the current structure has been debated at length, with a conclusion that unwrapping this specific part of the Gordian knot would take substantial effort for little real long-term gain. Based on those conversations, my estimate is that an attempt to refactor documents to avoid this dependency would add 24 to 36 months to the effort, if begun today. --------------5FEEEEEF4E69B2741167E91E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/4/19 5:54 AM, Harald Alvestrand wrote:
Can you assure me that -4566bis, -clue-protocol, -rmcat-eval-criteria
and -ice-sip-sdp are not blockers for pushing out the rest of the 238
cluster?


As that's a bit outside a single WG's area, I'll answer this as AD.


First, I'll discuss the CLUE subcluster:

  • The CLUE documents (both protocol and signaling) have dependencies into the cluster, but nothing outside of CLUE refers to them. They will remain in the cluster, but not block publication of anything except for other CLUE documents.
  • draft-ietf-mmusic-rfc4566bis only blocks draft-ietf-mmusic-data-channel-sdpneg, which is a part of the cluster by virtue of it being a CLUE dependency.


The documents draft-rmcat-eval-criteria and draft-rmcat-wireless-tests are  dependencies for draft-ietf-rmcat-eval-test. That document, in turn, is part of the cluster because it has dependencies pointing into the cluster. No dependencies point outward towards draft-ietf-rmcat-eval-test, so these two documents do not block publication of the WebRTC portion of the cluster.

Draft-ietf-mmusic-ice-sip SDP is a blocker for most documents in Cluster 238, as it is a strictly necessary normative dependency for BUNDLE [1]. It is on the August 8th IESG formal telechat.

/a

____
[1] This structure may seem odd at first, and it is almost certainly not how one would have structured documents if one were to have designed the whole cluster up front. However, the current structure has been debated at length, with a conclusion that unwrapping this specific part of the Gordian knot would take substantial effort for little real long-term gain. Based on those conversations, my estimate is that an attempt to refactor documents to avoid this dependency would add 24 to 36 months to the effort, if begun today.

--------------5FEEEEEF4E69B2741167E91E-- From nobody Fri Jul 12 20:01:17 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8B3120075; Fri, 12 Jul 2019 20:01:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156298687631.5338.9177112247281960499.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2019 20:01:16 -0700 Archived-At: Subject: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-security-arch-19: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2019 03:01:17 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-rtcweb-security-arch-19: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my Discuss points! I'll leave the original Comment section below, as I note that at least one issue remains (I spot-checked the SDP Offer/Answer reference, that still points to RFC 6454, which is "the Web Origin Concept". I didn't make any attempt to trim points that did get addressed. Section 3 (My comment about TCB and the other browser from the companion document is probably relevant here, too.) Section 4.1 This message is sent to the signaling server, e.g., by XMLHttpRequest [XmlHttpRequest] or by WebSockets [RFC6455], preferably over TLS [RFC5246]. The signaling server processes the message from Alice's This is the optimistic "best security" case, and we already say we're talking to the signaling server over HTTPS, so it should be safe to just say "over TLS" and drop the "preferably". (Also, s/5246/8446.) call and to Alice's identity. In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no specific knowledge of the IdP) to verify the assertion. This allows the browser to display a trusted element in the browser chrome indicating that a call is coming in from Alice. [...] I think I'm confused. We're displaying trusted browser chrome based on an assertion from some IdP that we have no relationship with and no reason to trust? Section 4.3 Once the ICE checks have completed [more specifically, once some ICE checks have completed], [...] nit: that's not really more specific. Maybe "Once the requisite ICE checks have completed"? Section 5 I see that the 4566 includes the pad characters, though sometimes we will mention explicitly whether they are or are not included. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 5.1 This section defines the SDP Offer/Answer [RFC6454] considerations for the SDP 'identity' attribute. 6454 is "the Web Origin Concept"; presumably this is supposed to be 4566 (or 3264?). Section 5.1.3 I feel like we need some text here about the (non?)trustworthiness of the IdP. Section 5.1.4 I'm a bit confused at what's going on here. Is "MAY send the same" supposed to prevent changing it? If I don't send it, does that identity continue to apply to the existing DTLS connections but not any new ones generated by the session modification? Am I allowed to send a different one? Note that [I-D.ietf-rtcweb-jsep], Section 5.2.1 requires that each media section use the same set of fingerprints for every media section. nit: is this "each media section"/"every media section" redundant? Section 6.1 Also note that the security architecture depends on the keying material not being available to move between origins. But, it is assumed that the identity assertion can be passed to anyone that the page cares to. There may be some (weak) privacy considerations if this is literally anyone, since it would allow some observers (with weird abilities/restrictions) to associate "real" identities with keys in a way that they couldn't otherwise do. Section 6.2 Because HTTP origins cannot be securely established against network attackers, implementations MUST NOT allow the setting of permanent access permissions for HTTP origins. Implementations MUST refuse all permissions grants for HTTP origins. Just to check: this last sentence applies for one-time requets, too? The semantics of this request are that the media stream from the camera and microphone will only be routed through a connection which has been cryptographically verified (through the IdP mechanism or an X.509 certificate in the DTLS-SRTP handshake) as being associated with the stated identity. [...] Does this need to be an exhaustive list or can we leave it open-ended? Also, it may be appropriate to mention some concept of "IdP trusted to authenticate the stated identity". API Requirement: The API MUST provide a mechanism for the requesting JS to relinquish the ability to see or modify the media (e.g., via MediaStream.record()). [...] Do we need to say anything about that state transition being visible to the peer, here? UI Requirement: If the UI indication of camera/microphone use are [...] camera and microphone input when the indication is hidden. [Note: this may not be necessary in systems that are non-windows-based but that have good notifications support, such as phones.] nit: s/windows/window/? Clients MAY permit the formation of data channels without any direct user approval. Because sites can always tunnel data through the server, further restrictions on the data channel do not provide any additional security. (though see Section 6.3 for a related issue). Is there anything to say about why clients might not opt to do so (and what such approval might look like)? (My comments about "verified user" including the IdP in some way will apply here as well.) Section 6.3 While continuing consent is required, the ICE [RFC8445]; Section 10 keepalives use STUN Binding Indications which are one-way and therefore not sufficient. The current WG consensus is to use ICE Is the "the current WG consensus" language going to age well? Binding Requests for continuing consent freshness. ICE already requires that implementations respond to such requests, so this approach is maximally compatible. A separate document will profile the ICE timers to be used; see [RFC7675]. Is there a WIP draft for this separate document? Section 6.4 API Requirement: The API MUST provide a mechanism to allow the JS to suppress ICE negotiation (though perhaps to allow candidate gathering) until the user has decided to answer the call [note: determining when the call has been answered is a question for the JS.] This enables a user to prevent a peer from learning their IP address if they elect not to answer a call and also from learning whether the user is online. nit: maybe make it more clear that this only applies for incoming calls? Section 6.5 Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. [...] It's not clear to me that the "that is" reflects a strict equivalence; would "in particular" be more appropriate? (Also, "cipher suite" is a DTLS term, but do we want to disambiguate explicitly?) [obligatory "Perfect Forward Secrecy" vs. "Forward Secrecy" note] Implementations MUST NOT implement DTLS renegotiation and MUST reject it with a "no_renegotiation" alert if offered. "MUST NOT implement" isn't really something that 2119 language can enforce; "MUST NOT use" is the best we can get. Endpoints MUST NOT implement TLS False Start [RFC7918]. (7918 doesn't claim to be applicable to DTLS anyway) API Requirement: Unless the user specifically configures an external key pair, different key pairs MUST be used for each origin. (This avoids creating a super-cookie.) nit: might be appropriate to note why we care about a super-cookie (and what it is) * The "security characteristics" MUST indicate the cryptographic algorithms in use (For example: "AES-CBC".) However, if Null ciphers are used, that MUST be presented to the user at the top-level UI. I'm not sure I see anywhere that we allow the usage of null ciphers. Section 7 Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed. While the details vary, what these technologies share is that they have a Web-based (i.e., HTTP/HTTPS) identity provider which attests to your identity. For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was alice@example.org. [...] I agree with Alissa that the first person is not needed here. Section 7.1 Third-Party: IdPs which don't have control of their section of the [...] identity space. Probably the best-known example of a third-party identity provider is SSL/TLS certificates, where there are a large number of CAs all of whom can attest to any domain name. This probably needs some qualifier, given recent developments with CAA and similar mechanisms. If an AP is authenticating via an authoritative IdP, then the RP does not need to explicitly configure trust in the IdP at all. The The RP still needs to establish somehow that the IdP in use is in fact an authoritative IdP, though! Section 7.2 In order to provide security without trusting the calling site, the PeerConnection component of the browser must interact directly with the IdP. The details of the mechanism are described in the W3C API specification, but the general idea is that the PeerConnection A reference to that W3C API spec might be handy. Section 7.3 There are two parts to this work: o The precise information from the signaling message that must be cryptographically bound to the user's identity and a mechanism for carrying assertions in JSEP messages. This is specified in Section 7.4. nit: the grammar is a bit weird here, as the "information from the signaling message" isn't really a part of this work, but rather the specification for what information that is. Section 7.4 The indentation of the line with "}, {" is a bit confusing. This object is encoded in a JSON [RFC8259] string for passing to the IdP. The identity assertion returned by the IdP, which is encoded in I'm a little confused what this "encoded in a JSON string" is supposed to mean. This structure does not need to be interpreted by the IdP or the IdP proxy. It is consumed solely by the RP's browser. The IdP merely treats it as an opaque value to be attested to. Thus, new parameters can be added to the assertion without modifying the IdP. The IdP probably wants to know enough about its structure to not turn into a signing oracle for other protocols, though. Section 7.4.1 (RFC 8259 JSON inherently is UTF-8, so maybe we don't need to mention that.) It's a little surprising to see sha-1 fingerprint in use (since "examples are recommendations"), though I didn't find anything that would actually formally deprecate such usage yet. Note that long lines in the example are folded to meet the column width constraints of this document; the backslash ("\") at the end of a line and the carriage return that follows shall be ignored. leading whitespace, too, right? Section 7.5.2 (Still need to say how it's know than authoritative assertions are in fact authoritative for what they claim.) Section 7.6 The input to identity assertion is the JSON-encoded object described in Section 7.4 that contains the set of certificate fingerprints the browser intends to use. This string is treated as opaque from the perspective of the IdP. (IdP still doesn't want to become a signing oracle.) For use in signaling, the assertion is serialized into JSON, Base64-encoded [RFC4648], and used as the value of the "identity" attribute. nit: it's unclear that "serialized into JSON" adds any value, since the thing is defined to be a JSON object. Section 7.7 I think that the framing of HTTP Basic (7617) here is not great. RFC 7235 might be a better link for HTTP Authentication in general, and of course there are mechanisms that don't include sending the password in plaintext, like SCRAM (RFC7804). Section 8 The IdP proxy verifies the assertion. Depending on the identity protocol, the proxy might contact the IdP server or other servers. For instance, an OAuth-based protocol will likely require using the IdP as an oracle, whereas with a signature-based scheme might be able to verify the assertion without contacting the IdP, provided that it has cached the relevant public key. IMPORTANT: Do we need a freshness property for the assertion? Some of these schemes do not provide freshness. Figure 6 shows an example response formatted as JSON for illustrative purposes. (Doesn't the W3C API spec need to say how the response is formatted? Is the JSON formatting actually "illustrative" then, or is this just an example output?) Section 8.1 2. If the domain portion of the string is not equal to the domain name of the IdP proxy, then the PeerConnection object MUST reject the assertion unless: Reading closely, I think this is supposed to be "unless either", but it's easy to assume it should be read as "unless both", so I think clarification is in order. Any "@" or "%" characters in the "user" portion of the identity MUST be escaped according to the "Percent-Encoding" rules defined in We just said in the first paragraph that "user" has "any character except '@'", so this is a bit redundant. Section 9.1 Users who wish to assure themselves of security against a malicious identity provider can only do so by verifying peer credentials directly, e.g., by checking the peer's fingerprint against a value delivered out of band. I suppose an "untrustworthy" IdP is basically a malicious one, though there are perhaps some subtleties that could be distinguished here. In order to protect against malicious content JavaScript, that JavaScript MUST NOT be allowed to have direct access to---or perform computations with---DTLS keys. For instance, if content JS were able to compute digital signatures, then it would be possible for content JS to get an identity assertion for a browser's generated key and then use that assertion plus a signature by the key to authenticate a call protected under an ephemeral Diffie-Hellman (DH) key controlled by the content JS, thus violating the security guarantees otherwise provided by the IdP mechanism. I don't think I fully understand the scenario described in this last sentence. Is "compute digital signatures" supposed to be with some specific secret key, and/or is "a browser's generated key" one that is covered under the fingerprint in the IdP assertion? Section 9.2 Otherwise, the other side will learn linkable information. nit: "linkable information that would allow them to correlate the browser across multiple calls". Section 9.3 Consider the case of a call center which accepts calls via WebRTC. An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center. Note that this requires user consent in many cases but because the data channel does not need consent, he can use that directly. I think I'm missing a step here. How is the attacker using the data channel directly when the point is to get the multiple browsers to send the data on the data channel? Muxing multiple media flows over a single transport makes it harder to individually suppress a single flow by denying ICE keepalives. Either media-level (RTCP) mechanisms must be used or the implementation must deny responses entirely, thus terminating the call. nit: "must be used to suppress the misbehaving flow", I think. Section 9.4.3 The "origin" field of the signature request can be used to check that the user has agreed to disclose their identity to the calling site; because it is supplied by the PeerConnection it can be trusted to be correct. I don't see an "origin" field in the signature request; is this supposed to be the "domain"? Section 9.4.5.1 nit: it might be friendlier to the reader to prefix this with "When popup blocking is in use, ". Section 13.2 It's perhaps debatable that JSEP is only an informative reference. From nobody Mon Jul 15 04:01:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9793E1200CE for ; Mon, 15 Jul 2019 04:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5oKmx9S-5Vh for ; Mon, 15 Jul 2019 04:01:36 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 F299B1200C3 for ; Mon, 15 Jul 2019 04:01:35 -0700 (PDT) Received: from [81.187.2.149] (port=35288 helo=[192.168.0.81]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hmyjY-0007ID-Jl; Mon, 15 Jul 2019 12:01:32 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Colin Perkins In-Reply-To: Date: Mon, 15 Jul 2019 12:01:14 +0100 Cc: Harald Alvestrand , Sean Turner , "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <02b5b7c2-dde2-6ff0-06fa-bcaf10a0030b@alvestrand.no> To: Adam Roach X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [rtcweb] Request for status update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 11:01:38 -0000 > On 12 Jul 2019, at 23:59, Adam Roach wrote: > On 7/4/19 5:54 AM, Harald Alvestrand wrote: >> Can you assure me that -4566bis, -clue-protocol, -rmcat-eval-criteria >> and -ice-sip-sdp are not blockers for pushing out the rest of the 238 >> cluster? >=20 > As that's a bit outside a single WG's area, I'll answer this as AD. ... > The documents draft-rmcat-eval-criteria and draft-rmcat-wireless-tests = are dependencies for draft-ietf-rmcat-eval-test. That document, = in turn, is part of the cluster because it has dependencies pointing = into the cluster. No dependencies point outward towards = draft-ietf-rmcat-eval-test, so these two documents do not block = publication of the WebRTC portion of the cluster. Also, the RMCAT drafts are in WG last call, and should be ready to go to = the IESG shortly.=20 Colin (as RMCAT co-chair) From nobody Mon Jul 15 18:26:41 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160511200DB for ; Mon, 15 Jul 2019 18:26:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 gV1PsAuuGQOa for ; Mon, 15 Jul 2019 18:26:32 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 8E2E0120176 for ; Mon, 15 Jul 2019 18:26:30 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id k10so17822634qtq.1 for ; Mon, 15 Jul 2019 18:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=91kYkRLItxKDNiCDM4afRueIpk9+QvTA4orJ8UoMgkg=; b=RbQ/ACkc8a1KUha1C/uckNoS/MlQ/n8tSXqsWkw5K873Ta2SOvliKIaNKB3mLqJCnF 1DCBB3/UJdd8LW2OS1DRMPnqcKF/1neNUaU/MwYmVmr6/Io96FEge4aTBnm8XCR5WByf mc1bw8qawEbYnna+TVcHLaM6h9pBOFQPn45EQ= 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=91kYkRLItxKDNiCDM4afRueIpk9+QvTA4orJ8UoMgkg=; b=WqIWvlCc2q3PJS/kBVXpWFjoakK+/g8ZNamhLyHbBvb3eANaOL4Voft18fxqNKBsii SZTVTuPDt3dabJApyKPKtD1UBpvqOOZ1K8KVVX6uqkGsFJTaYasIgt87tvX8KP0LQsnN ldaieDTVtaXwwBefBn7wtUoQP0WPxhAgOzopxDz23SEPfzVdTZMwJkv7wQ8k3R6r+xHa +eHBUIjZZJDD+89gF8aAiEEszTjGcw6zNNXrP6MQaXegECAg7gYy21V2jiJDa5WsGXkq tURV/k9XK94El6xGroJpEE1H1qAg5ch28BtvY+84CDws6GZwuZXSimfFineB9sVKlyyK ubbA== X-Gm-Message-State: APjAAAV6iCEE0+qzyXFSa0/vR1GP/M6qNaGhHTizTw+SYBVIrfDkqxmw L6J7oa5gVDmo5U40iSQbw/0= X-Google-Smtp-Source: APXvYqz9Fc/0x+I2vaho3jqfL1s7+LDuHbZJmXEvnx8e54oa/vey6QZr1O1eVZ7i5DWTZqJ8GQiepQ== X-Received: by 2002:ac8:2ae8:: with SMTP id c37mr20780893qta.267.1563240389259; Mon, 15 Jul 2019 18:26:29 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id z33sm9269046qtc.56.2019.07.15.18.26.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 18:26:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <156298687631.5338.9177112247281960499.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2019 21:26:27 -0400 Cc: The IESG , draft-ietf-rtcweb-security-arch@ietf.org, rtcweb-chairs@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <156298687631.5338.9177112247281960499.idtracker@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-security-arch-19: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 01:26:33 -0000 > On Jul 12, 2019, at 23:01, Benjamin Kaduk via Datatracker = wrote: >=20 > Thanks for addressing my Discuss points! > I'll leave the original Comment section below, as I note that at least = one > issue remains (I spot-checked the SDP Offer/Answer reference, that = still > points to RFC 6454, which is "the Web Origin Concept". I didn't make = any > attempt to trim points that did get addressed. I knew I would miss an easy one. Addressed in the following PR: https://github.com/rtcweb-wg/security-arch/pull/99 spt= From nobody Tue Jul 16 10:25:40 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF5120ACB; Tue, 16 Jul 2019 10:25:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.4 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <156329793861.15182.15587896468944020937@ietfa.amsl.com> Date: Tue, 16 Jul 2019 10:25:38 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 17:25:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-10.txt Pages : 13 Date : 2019-07-16 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-10 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-fec-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 16 11:11:56 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFC6120114; Tue, 16 Jul 2019 11:11:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.98.4 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ted.ietf@gmail.com, adam@nostrum.com, rtcweb-chairs@ietf.org, Ted Hardie , draft-ietf-rtcweb-fec@ietf.org, rtcweb@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156330070290.15267.1510062269956948702.idtracker@ietfa.amsl.com> Date: Tue, 16 Jul 2019 11:11:42 -0700 Archived-At: Subject: [rtcweb] Protocol Action: 'WebRTC Forward Error Correction Requirements' to Proposed Standard (draft-ietf-rtcweb-fec-10.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 18:11:43 -0000 The IESG has approved the following document: - 'WebRTC Forward Error Correction Requirements' (draft-ietf-rtcweb-fec-10.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ Technical Summary In situations where packet loss is high or perfect media quality is essential, Forward Error Correction (FEC) can be used to proactively recover from packet losses. This specification provides guidance on which FEC mechanisms to use, and how to use them, for WebRTC implementations. Working Group Summary The working group support for the document was generally high. One issued was raised in working group last call regarding the effectiveness of the Opus internal FEC mechanism. The document currently states that it is RECOMMENDED for protection against individual packet loss and that other methods are needed for multi-packet protection. This mirrors text in RFC 6716 and accurately captures a limitation of the in-band FEC mechanism. The question of effectiveness is thus tightly tied to the loss pattern. While data on this was presented, there was no evident consensus to update the requirement, so the recommendation from RFC 6716 was retained. Document Quality This document appears to have the support of the relevant development community and will likely be implemented and deployed. Reviews by Mo Zanaty, Magnus Westerlund, and Bernard Aboba were particularly helpful. Personnel Ted Hardie is the Document Shepherd. Adam Roach is the Responsible Area Director. From nobody Mon Jul 22 06:54:26 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC811200B5 for ; Mon, 22 Jul 2019 06:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 HHaFXMtE1Ty4 for ; Mon, 22 Jul 2019 06:54:22 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 50154120059 for ; Mon, 22 Jul 2019 06:54:22 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id v22so28623539qkj.8 for ; Mon, 22 Jul 2019 06:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=pzRg89YnTPe2Te7WQf84X7UYHnNGmCEO6orkmlxX6r4=; b=Gi/4zyGkbk35xOMtymA8WOdQc8BOkdWz50u88z+GWh5cw7bxa2KV/vV/5zM/mPLX+b IEbJtaSQSFbYSqiqbFpmZmPb/hsH1vrX5UD4nn4ktD2HkAQHufCH0Ndq+evYzoGREWkR stta8BOlcEEccZCnkzW1J2y8R/+L7TzfvKWJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=pzRg89YnTPe2Te7WQf84X7UYHnNGmCEO6orkmlxX6r4=; b=QfjrXVUlwNltQ5I9cRhg5t/9sHvKFxcEDgze9qe0GMcSoC6G/FQCVYnZIVRT8BV0FJ /gvXJ0dehmNKOKGQGqkg9/52qmm1/KrCjQZOlyOCp0PNmlNzZ5yJ9U/4EvvAXqdmnJ76 2y5iBjrFtsZKtW19VnCkAi+LTmaJ90yMNFX3jOSpSY1L6qwP+CrTjxbb37mH08ylEwTw fiOPv9zjj3MwGXFCSqYEBDTMdlvaxJRjQ5YUzry5B3x5x/3oimko9X+/24z1OexuEZ7i 6SAsNFWbRG1ifE1rKGT+Fb7TDs4Ajpj33q5MuH2Tu1B5HIBI1fSMgZd2P7SRgmLykXp0 UJ9Q== X-Gm-Message-State: APjAAAWkfOta8JAe9iGoo/KaYHWcVoIP22gRQmxbaduXI1aGYsh7eIeN moa0e2KrdlAqZAmsRnVg1ZYRyzaPLGc= X-Google-Smtp-Source: APXvYqxwPLz5RHXTK+UiV/lioWbh9IC/u1UQ3uYZpufddjomGdSQOwgvCdXRLzyRicOf13RvIPjyDA== X-Received: by 2002:a37:6982:: with SMTP id e124mr13066261qkc.291.1563803661292; Mon, 22 Jul 2019 06:54:21 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:b81e:cafc:6735:5203? ([2001:67c:1232:144:b81e:cafc:6735:5203]) by smtp.gmail.com with ESMTPSA id j61sm18346523qte.47.2019.07.22.06.54.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 06:54:20 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 09:54:19 -0400 References: <545FC32C-D601-4888-80E9-BF615FE98BD0@sn3rd.com> To: RTCWeb IETF , Eric Rescorla , Adam Roach In-Reply-To: <545FC32C-D601-4888-80E9-BF615FE98BD0@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Final PRs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 13:54:24 -0000 All, Jully 22nd is here so I am going to close this out and consider the PRs = approved. ekr, Please spin a new version to incorporate the PR for the reference = change. Adam. Once the new version hits the street feel free to hit the button to move = this to the next state. spt > On Jul 10, 2019, at 19:12, Sean Turner wrote: >=20 > Hi! ekr has spun a new version of draft-ietf-rtcweb-security-arc [0]. = All of the changes were to address the outstanding IESG DISCUSS = positions or were a result of following on discussions with Ben K = (Security AD). While I think all of these are good changes, there were = three changes that affected 2119-language and we need to get the WGs = take on these. Two of these changes are in s5.1.4 (SHOULD->MUST and = the addition of a new MUST) and one is in s7.6 (addition of a new = SHOULD). These are most easily seen by looking at the diffs [1]. If = you object to these changes, then please let the list know by July 22nd. >=20 > Note that these are the last issues remaining before this draft as = well as draft-ietf-rtcweb-security and draft-ietf-rtcweb-ip-handling can = move into the RFC editor=E2=80=99s queue. At that point we will be = dangerously close to be done. >=20 > Thanks, >=20 > spt >=20 > [0] https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ >=20 > [1] = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-rtcweb-security-arch-18&url= 2=3Ddraft-ietf-rtcweb-security-arch-19 From nobody Mon Jul 22 07:30:10 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83D9120359 for ; Mon, 22 Jul 2019 07:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 cwgJs8SwwGTl for ; Mon, 22 Jul 2019 07:30:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091F4120305 for ; Mon, 22 Jul 2019 07:30:01 -0700 (PDT) Received: from Orochi.local ([199.189.26.34]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6METv92048023 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jul 2019 09:29:59 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563805800; bh=JyxM19Az8Nx78hiw2n7O3AiN4pTkGiv1NuqLDmoczp0=; h=Subject:To:References:From:Date:In-Reply-To; b=BB5/g8qWwWklRDI8Ndz9/RCT60+xKL8z0PCrH65JYLev9XwH93XYBhluQb14tjutL s/+aEkFUp7V5IDEm6zi6oMEeCqAqt+eTGYN0bFoHspHAQDoAFhh3p1scC51xUu4nzn 6r8Ysj/goNJFSfKklGZjaWDOmRqYvaHuQhS1hpcg= X-Authentication-Warning: raven.nostrum.com: Host [199.189.26.34] claimed to be Orochi.local To: Sean Turner , RTCWeb IETF , Eric Rescorla References: <545FC32C-D601-4888-80E9-BF615FE98BD0@sn3rd.com> From: Adam Roach Message-ID: <30b81b47-e920-3f48-8971-b11edcd1bf89@nostrum.com> Date: Mon, 22 Jul 2019 10:29:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Final PRs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:30:09 -0000 In the interest of getting this into the editors' hands as soon as possible, I'm going to fix the reference in an RFC Editor note and put this document in the queue. No new version is necessary. Thanks. /a On 7/22/19 09:54, Sean Turner wrote: > All, > > Jully 22nd is here so I am going to close this out and consider the PRs approved. > > ekr, > > Please spin a new version to incorporate the PR for the reference change. > > Adam. > > Once the new version hits the street feel free to hit the button to move this to the next state. > > spt > > >> On Jul 10, 2019, at 19:12, Sean Turner wrote: >> >> Hi! ekr has spun a new version of draft-ietf-rtcweb-security-arc [0]. All of the changes were to address the outstanding IESG DISCUSS positions or were a result of following on discussions with Ben K (Security AD). While I think all of these are good changes, there were three changes that affected 2119-language and we need to get the WGs take on these. Two of these changes are in s5.1.4 (SHOULD->MUST and the addition of a new MUST) and one is in s7.6 (addition of a new SHOULD). These are most easily seen by looking at the diffs [1]. If you object to these changes, then please let the list know by July 22nd. >> >> Note that these are the last issues remaining before this draft as well as draft-ietf-rtcweb-security and draft-ietf-rtcweb-ip-handling can move into the RFC editor’s queue. At that point we will be dangerously close to be done. >> >> Thanks, >> >> spt >> >> [0] https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ >> >> [1] https://www.ietf.org/rfcdiff?url1=draft-ietf-rtcweb-security-arch-18&url2=draft-ietf-rtcweb-security-arch-19 From nobody Mon Jul 22 07:52:29 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E27B1202C0; Mon, 22 Jul 2019 07:52:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , rtcweb@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, sean@sn3rd.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156380713637.27967.12266470492870261365.idtracker@ietfa.amsl.com> Date: Mon, 22 Jul 2019 07:52:16 -0700 Archived-At: Subject: [rtcweb] Protocol Action: 'WebRTC Security Architecture' to Proposed Standard (draft-ietf-rtcweb-security-arch-19.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:52:21 -0000 The IESG has approved the following document: - 'WebRTC Security Architecture' (draft-ietf-rtcweb-security-arch-19.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ Technical Summary This document defines the security architecture for WebRTC. This draft is bound standards track because it includes protocol for web-based peer authentication. Working Group Summary This draft has been discussed on the mailing list and at numerous RTCweb f2f meetings. It’s been amended numerous times based on WG feedback and it reflects the WG consensus. Document Quality WebRTC, including its underlying security and privacy model, has been implemented by all major web browsers. Personnel Sean Turner is the Shepherd. Adam Roach is the responsible AD. RFC Editor Note Please adjust the reference in section 5.1 as follows: OLD This section defines the SDP Offer/Answer [RFC6454] considerations for the SDP 'identity' attribute. NEW This section defines the SDP Offer/Answer [RFC3264] considerations for the SDP 'identity' attribute. Additionally, please add RFC 3264 to the list of normative references for this document. Thanks! From nobody Mon Jul 22 07:56:20 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE1D120286; Mon, 22 Jul 2019 07:56:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <156380737498.28087.17178567236646140368@ietfa.amsl.com> Date: Mon, 22 Jul 2019 07:56:15 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-20.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 14:56:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-20.txt Pages : 43 Date : 2019-07-22 Abstract: This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-arch-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 30 13:08:52 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E892D120242 for ; Tue, 30 Jul 2019 13:08:41 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 6nzIM0ZEO9Qw for ; Tue, 30 Jul 2019 13:08:39 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10073.outbound.protection.outlook.com [40.107.1.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D2612023B for ; Tue, 30 Jul 2019 13:08:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vd3caEBBz+bKEUH/xdYQbMrxETz8l3DIWn6RbERNhUUy3D7Ui8ItA3laN+4w9YSTeq8fQ3K7JI7SNFDLNPrcJdW0P3dm70JzpOaEkomXfibhkG7/dp1/uzZ+biruYzLq8hrvHmZErnlgstE3hPBcByVxcYCaatjC627UBfPIsbTSKaKa48y11g/F4afIQm0pmkxpflt/teBbD1kU8yqXdXD0xsa2JQDYsnMBKV0hz0vXgf1akqEPqm15EOjSDTvbeUE+04/+IKu07wo2ymh5vZtCKBVXd2EJg6K/AGOU0eb3MhZ+6AqOgyhvTUyM9lTJdUHEZk3u3n+cXYnm2X548g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z882OZoMfuCsIcgwRvNWRsm6jtLDgpNgxjIGVcCqLx4=; b=gFgLwSebi52UT1uFUYKXJKALcdvTlwTe8myuCvfljOwdiZYMyf+iJzdiD445NFpUw4WmsZM6GRQbdzTO+Wpi1L0piV/lA6Of26kWAwOAI78aBeY32YxhPoFR8ZvU+xRq43R/fR/JSa+wf61VW3bsONYFDhQYL6wRMWl7ljGvhnl0OgJ7Dbm5wD9E8UdGD4RLBpWjj5zh/1EmYMb0DxdofFC23xtopfl4AP3xyfKGosFe4c7woN+N7phFoAhKI541JJkwk7TzGXSm30qFtx9MtYNbJp3LEX0zogSGgk+dE86ljqv3mGay5Uuqmx7TeK4rW3wnP2QqHj5lhcb9ldSrAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z882OZoMfuCsIcgwRvNWRsm6jtLDgpNgxjIGVcCqLx4=; b=OZEv3Ub0FdIchhClMFUJrfyZatVdBxrAhYXsPKR0kru4GP9LN1YMBFUtsnSUfnNhFGt8X63o3JTTkEo5x0RIQlKeqbHtM/b0nA/KLQ7uYMEdEVEqdSgxb1e2aXmPJ8uS+ULkjNaSmSc59HO7YgSUoHSI1oHzsYMSdcUbQYeecGQ= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4299.eurprd07.prod.outlook.com (20.176.166.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.9; Tue, 30 Jul 2019 20:08:36 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7%6]) with mapi id 15.20.2136.010; Tue, 30 Jul 2019 20:08:36 +0000 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP and ice-pacing attribute Thread-Index: AdVHEpE+giMmYQ8tTyuReNcouqrB6A== Date: Tue, 30 Jul 2019 20:08:36 +0000 Message-ID: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4069e22d-df2e-4398-c216-08d71529b4c5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4299; x-ms-traffictypediagnostic: HE1PR07MB4299: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(366004)(396003)(346002)(136003)(199004)(189003)(33656002)(53936002)(54896002)(6306002)(9686003)(5640700003)(52536014)(68736007)(6436002)(476003)(2351001)(55016002)(6916009)(486006)(2906002)(14454004)(44832011)(99286004)(9326002)(25786009)(6506007)(7696005)(26005)(102836004)(186003)(2501003)(256004)(790700001)(6116002)(3846002)(478600001)(7736002)(74316002)(8936002)(81166006)(81156014)(8676002)(558084003)(1730700003)(76116006)(86362001)(3480700005)(66946007)(66446008)(66066001)(64756008)(66556008)(66476007)(316002)(71190400001)(71200400001)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4299; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AXVaNppQ2GBLWyx1NywCfAN8V/5od+4D+N+XEGjU7v79VkX1cPYLAQOprqxv3HxtkAJCjywbfk04mzYhZU70Y00XfthMlAptUrySMLowZ0eHHC5MrJjJyUk5hvhNPtlBp1HWL3aFtG9GdgxPoCqiuDSVcd/nS8ds40oZ4xcLneqAySy8719tQTarWH4UL78mlebyVyOg3iyQefSk1DK5tWP0Viki6IGgQfBT+Apkego/6HRoHvzm1QG6Qx9w7qYPrwDldxwyfQgefSSl8N82acdXTGL7Sml1K06vGlcX5q/q40BtK8wZN1r2hE9PwE4NiCJdJ3tGhWSYWWqOsYnSfVIyG7+jWFPWZVFYH1cNh5f4ym+2gmGiwSBTpKxdJndmRU8qpblH9I2D/tsunAY76s1YWujdAIjiXUwX7GIrUak= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161E5882EE23A304E86111E93DC0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4069e22d-df2e-4398-c216-08d71529b4c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 20:08:36.2188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4299 Archived-At: Subject: [rtcweb] JSEP and ice-pacing attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 20:08:50 -0000 --_000_HE1PR07MB3161E5882EE23A304E86111E93DC0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I noted that JSEP does not specify the usage of the ice-pacing attribute. I= s there a reason for that? It does explicitly specify how all the other ICE= related SDP attributes are used. Regards, Christer --_000_HE1PR07MB3161E5882EE23A304E86111E93DC0HE1PR07MB3161eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I noted that JSEP does not specify the usage of the = ice-pacing attribute. Is there a reason for that? It does explicitly specif= y how all the other ICE related SDP attributes are used.

 

Regards,

 

Christer

--_000_HE1PR07MB3161E5882EE23A304E86111E93DC0HE1PR07MB3161eurp_-- From nobody Tue Jul 30 14:55:53 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C03B120114 for ; Tue, 30 Jul 2019 14:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 smftm7LwqXnt for ; Tue, 30 Jul 2019 14:55:49 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE85C120074 for ; Tue, 30 Jul 2019 14:55:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 975977C4888 for ; Tue, 30 Jul 2019 23:55:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwKW6S-Wc40S for ; Tue, 30 Jul 2019 23:55:44 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4A0357C487C for ; Tue, 30 Jul 2019 23:55:44 +0200 (CEST) To: rtcweb@ietf.org References: From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <5dc4a383-93ce-8313-3b1c-434fb0a97876@alvestrand.no> Date: Tue, 30 Jul 2019 23:55:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] JSEP and ice-pacing attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2019 21:55:52 -0000 Den 30.07.2019 22:08, skrev Christer Holmberg: > Hi, > > > > I noted that JSEP does not specify the usage of the ice-pacing > attribute. Is there a reason for that? It does explicitly specify how > all the other ICE related SDP attributes are used. I think we overlooked it. "ice-pacing" was introduced in draft-ietf-mmusic-ice-sip-sdp-03 (July 2014), so we can't claim it's because it's too new..... JSEP was only at its version -07 at that time. According to RFC 8445 section 14.2, this attribute sets the value of the Ta timer (or at least this is the only interpretation that I can see that makes sense). According to draft-ietf-mmusic-ice-sip-sdp-36, "ice-pacing" only allows increasing the value of Ta to a value larger than its default (50 ms) (while 8445 seems to indicate that a single agent can go all the way down to 5 ms, but not lower). I'm happy to interpret jsep's silence on the matter as "does not define additional rules for ice-pacing", and leave it on the list of issues to consider when JSEP is revised. > > > > Regards, > > > > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Tue Jul 30 21:09:01 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB20120058; Tue, 30 Jul 2019 21:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bluejeans.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 Y7_Cd2oniw1l; Tue, 30 Jul 2019 21:08:47 -0700 (PDT) Received: from mx0b-00292101.pphosted.com (mx0b-00292101.pphosted.com [148.163.152.156]) (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 B49CD12002E; Tue, 30 Jul 2019 21:08:47 -0700 (PDT) Received: from pps.filterd (m0114296.ppops.net [127.0.0.1]) by mx0b-00292101.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6V40STK013053; Wed, 31 Jul 2019 04:08:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluejeans.com; h=from : to : subject : date : message-id : content-type : mime-version; s=pod032818; bh=c5XCyC4Rc/Hc9CImEfG5KC0tNdN0jFvz5/sb0liwiuQ=; b=O9uwCextePFKUtL57RP0dRb2wNzAOdMMwfqSatp8t9Axd8SFAvypKy0ovxpIafWGYaoj 8YsJMezQx+eQCBbXeupD2+rmsAmk9aqz2t15TIXFiUYep2DackAst+CXSWqAiuxmyXs/ wxvFi0RChg8u7Enyes20OWF3SFtpdd67mvLre9iKlW4vDE846/6mS5q9OtkIzH+Zw3ag 9OuKuYHZrOoXfVYTPbd1PgLP31A/AsxdX/P/3pk+m/fKEMfNziWOV4fTpSotBzX5rMj9 RGD1RwD6536bsG4AADyottBepFO/T2uwiWR4g6YG7ooYtM9WKkjdBS8o4BOFgK36eyOX Xg== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2059.outbound.protection.outlook.com [104.47.41.59]) by mx0b-00292101.pphosted.com with ESMTP id 2u10g3hqq0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 04:08:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=baZVJDVzprEyKxLlR2Ux7n7s8vjEesHtTFFKFYN9xJ6o4WJxmTvBGfB0xly0XnSUTRrFXvjimcqOOPcP6HlrkeQMyECXVmaNdS3OXVxZ8b9uY70CT13NiPxwVsGakMz9BdrybHbMJX8zRt/oxoh7iH+qEW2S1Y80gCRdWwrhrpaGixyn2+3tKvb4HqU1037sNMzrynnnHQ4Gwmc9OhvtAorDddlx1hZwlWFcodTba58eN5hwP+Gg6lsfe/klYVFNIh6cyFyTNwOLVcqJvlIN9ayx5ETuIV7vIJMygNujmc3iRwWyMtijYL7BmlhtaXVfjjElNxm+rGnFuI0B+hBEmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c5XCyC4Rc/Hc9CImEfG5KC0tNdN0jFvz5/sb0liwiuQ=; b=A3Xu6f05LEtqyehBHXFwONC2Pu5ahqUzSVB7ojFVu9fWJArGat5VaCGVU/ClS5zAMs9AIGaGzbosIHglyN86U2Agn+TnPOPsBgZwuOKPPPq5f1r7CWsmuBLFrUtofd2y8u0z6birM4EgZ6kGJLgk/okP7iXVHADIzhtoNGEM0D+WfJ+PoPRHnStGgHAhPM6JoUZS/NTqfAC/VRQ6+04kgZZZhJ8/Lq3kh6T25tEs8YlMDKe0aCXtuGqzR2y1lc6VwD+L8g7U/kQ0JLABur8wi0L3LNFMHExNvvoZlJESWzKacSeSUf8tFrT9Q+zMQbBcAW2cGo72w/QYME0BmyyTog== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=bluejeans.com;dmarc=pass action=none header.from=bluejeans.com;dkim=pass header.d=bluejeans.com;arc=none Received: from BY5PR13MB3585.namprd13.prod.outlook.com (10.255.154.206) by BY5PR13MB3078.namprd13.prod.outlook.com (10.255.163.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.10; Wed, 31 Jul 2019 04:08:43 +0000 Received: from BY5PR13MB3585.namprd13.prod.outlook.com ([fe80::6db8:97bd:25ac:febd]) by BY5PR13MB3585.namprd13.prod.outlook.com ([fe80::6db8:97bd:25ac:febd%5]) with mapi id 15.20.2136.010; Wed, 31 Jul 2019 04:08:43 +0000 From: Matthew Kaufman To: "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: STUN DSCP and draft-ietf-tsvwg-rtcweb-qos Thread-Index: AQHVR1Wk05FT/JEWvEyZjv/Ejg3eBA== Date: Wed, 31 Jul 2019 04:08:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df1:e307:3:8b4d:8db7:a772:aaa3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a776895f-faec-499b-d9c6-08d7156cc6d8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BY5PR13MB3078; x-ms-traffictypediagnostic: BY5PR13MB3078: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(366004)(396003)(39850400004)(189003)(199004)(450100002)(33656002)(110136005)(53936002)(14454004)(256004)(6486002)(86362001)(8936002)(966005)(102836004)(606006)(2906002)(6436002)(316002)(9686003)(236005)(6512007)(6506007)(25786009)(71200400001)(476003)(71190400001)(486006)(68736007)(36756003)(4744005)(5660300002)(66946007)(76116006)(66556008)(81166006)(2501003)(91956017)(66476007)(99286004)(81156014)(46003)(64756008)(6116002)(8676002)(478600001)(186003)(7736002)(66446008)(6306002)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3078; H:BY5PR13MB3585.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bluejeans.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: yjmmb/5EVyoKM1pbYDrMTCgrWT6t/J/kqnGHK/SCnbArv7G76LS9BUR8FYnMHo/PRKEsSDxNe7NvIkMy4nFoqWcekIgTI+OKKCnUfYNcLr9BI3K+a7x/AS2+5tv1EyLhtRJnrDe7nUogWW2vvWxBl3dOo9as2GOL+50Axopuik+5oShjAdgp3FEw76aILjBSMYAyNo0LtZ8dvVZD5BWL8FtRpPKxeyi81kRZx7d/RxyF8LmRJlZe24Ne5pX3WFMAJap+AZ3g4q+0UV9sDnJmiIrfercKM30SQy50HcA2Bm07Hc7e06JC2oTLNjHylXLJxq/d+7TusZ/NSS992I8YBbPzXmvKDjyfPtq04AzSr5HdLoLURioLWko8siaOEs/gwe9G363rIU0ezt0I83tWF05fr7b4BlQub2jUxteWpTE= Content-Type: multipart/alternative; boundary="_000_EA953E3451FA4B17A0B26CF75146A754contosocom_" MIME-Version: 1.0 X-OriginatorOrg: bluejeans.com X-MS-Exchange-CrossTenant-Network-Message-Id: a776895f-faec-499b-d9c6-08d7156cc6d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 04:08:43.1486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 78d2bd57-5099-4199-92a8-4626e5d3c18b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mkaufman@bluejeans.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3078 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-31_02:2019-07-29,2019-07-31 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 impostorscore=0 suspectscore=0 adultscore=0 mlxscore=0 bulkscore=0 malwarescore=0 spamscore=0 clxscore=1011 mlxlogscore=811 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907310041 Archived-At: Subject: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 04:08:50 -0000 --_000_EA953E3451FA4B17A0B26CF75146A754contosocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2FzIGNoYXNpbmcgZG93biBzb21lIHdlYnJ0YyByYWJiaXQgaG9sZXMgdG9kYXksIGFuZCBjYW1l IGFjcm9zcyB0aGUgZm9sbG93aW5nIGNvbmNlcm46DQoNCmRyYWZ0LWlldGYtdHN2d2ctcnRjd2Vi LXFvcyBoYXMgZXhhY3RseSB6ZXJvIGxhbmd1YWdlIGFib3V0IGhvdyB0aGUgU1RVTiBwYWNrZXRz IHNob3VsZCBiZSBtYXJrZWQgZm9yIElDRSBuZWdvdGlhdGlvbi4gVGhlIGlzc3VlIGlzIG1lbnRp b25lZCBpbiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJlc2huZXNzLCBidXQgSSBi ZWxpZXZlIHRoYXQgdGhlIHJ0Y3dlYi1xb3MgZG9jdW1lbnQgc2hvdWxkIGJlIHRoZSByZWZlcmVu Y2UgdG8gaG93IGFuIHJ0Y3dlYiB0cmFuc3BvcnQgYXV0aG9yIHNob3VsZCBiZSBzZXR0aW5nIERp ZmZTZXJ2IG1hcmtpbmdzLg0KDQpBbHNvLCB0aGVyZSB3YXMgYSBncmVhdCBjb252ZXJzYXRpb24g b24gdGhlIHRvcGljIGJhY2sgaW4gMjAxNCB0aGF0IHVuZm9ydHVuYXRlbHkgc2VlbXMgdG8gaGF2 ZSBwZXRlcmVkIG91dCBiZWZvcmUgYSByZXNvbHV0aW9uIHRvIHNvbWUgb2J2aW91cyBvcGVuIGlz c3VlczogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9ydGN3ZWIvP2di dD0xJmluZGV4PUhIMHF6dHF0NFV0ZlpkcHV4SFRWY2c3aFpkRQ0KDQpXb3VsZCBiZSBncmVhdCB0 byBmaW5pc2ggdGhlIGNvbnZlcnNhdGlvbiBiZWZvcmUgZmluYWxpemluZyB0aGUgc3BlY2lmaWNh dGlvbiBmb3IgaG93IHRvIG1hcmsgdGhlc2UuDQoNClBlcnNvbmFsbHkgSeKAmW0gaW4gdGhlIOKA nElDRSBpcyB0ZXN0aW5nIGNvbm5lY3Rpdml0eSwgc28gU1RVTiBtdXN0IGJlIG1hcmtlZCBleGFj dGx5IHRoZSBzYW1lIGFzIGNvcnJlc3BvbmRpbmcgbWVkaWHigJ0gY2FtcC4NCg0KTWF0dGhldyBL YXVmbWFuDQo= --_000_EA953E3451FA4B17A0B26CF75146A754contosocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XYXMgY2hhc2luZyBkb3duIHNvbWUgd2Vi cnRjIHJhYmJpdCBob2xlcyB0b2RheSwgYW5kIGNhbWUgYWNyb3NzIHRoZSBmb2xsb3dpbmcgY29u Y2Vybjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmRyYWZ0LWll dGYtdHN2d2ctcnRjd2ViLXFvcyBoYXMgZXhhY3RseSB6ZXJvIGxhbmd1YWdlIGFib3V0IGhvdyB0 aGUgU1RVTiBwYWNrZXRzIHNob3VsZCBiZSBtYXJrZWQgZm9yIElDRSBuZWdvdGlhdGlvbi4gVGhl IGlzc3VlIGlzIG1lbnRpb25lZCBpbiBkcmFmdC1pZXRmLXJ0Y3dlYi1zdHVuLWNvbnNlbnQtZnJl c2huZXNzLCBidXQgSSBiZWxpZXZlIHRoYXQNCiB0aGUgcnRjd2ViLXFvcyBkb2N1bWVudCBzaG91 bGQgYmUgdGhlIHJlZmVyZW5jZSB0byBob3cgYW4gcnRjd2ViIHRyYW5zcG9ydCBhdXRob3Igc2hv dWxkIGJlIHNldHRpbmcgRGlmZlNlcnYgbWFya2luZ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5BbHNvLCB0aGVyZSB3YXMgYSBncmVhdCBjb252ZXJzYXRpb24g b24gdGhlIHRvcGljIGJhY2sgaW4gMjAxNCB0aGF0IHVuZm9ydHVuYXRlbHkgc2VlbXMgdG8gaGF2 ZSBwZXRlcmVkIG91dCBiZWZvcmUgYSByZXNvbHV0aW9uIHRvIHNvbWUgb2J2aW91cyBvcGVuIGlz c3VlczoNCjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2Uv cnRjd2ViLz9nYnQ9MSZhbXA7aW5kZXg9SEgwcXp0cXQ0VXRmWmRwdXhIVFZjZzdoWmRFIj4NCmh0 dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93c2UvcnRjd2ViLz9nYnQ9MSZhbXA7 aW5kZXg9SEgwcXp0cXQ0VXRmWmRwdXhIVFZjZzdoWmRFPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+V291bGQgYmUgZ3JlYXQgdG8gZmluaXNoIHRoZSBjb252 ZXJzYXRpb24gYmVmb3JlIGZpbmFsaXppbmcgdGhlIHNwZWNpZmljYXRpb24gZm9yIGhvdyB0byBt YXJrIHRoZXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGVy c29uYWxseSBJ4oCZbSBpbiB0aGUg4oCcSUNFIGlzIHRlc3RpbmcgY29ubmVjdGl2aXR5LCBzbyBT VFVOIG11c3QgYmUgbWFya2VkIGV4YWN0bHkgdGhlIHNhbWUgYXMgY29ycmVzcG9uZGluZyBtZWRp YeKAnSBjYW1wLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+TWF0 dGhldyBLYXVmbWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_EA953E3451FA4B17A0B26CF75146A754contosocom_-- From nobody Tue Jul 30 21:36:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3612D120058 for ; Tue, 30 Jul 2019 21:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJw3lnhPxf8Q for ; Tue, 30 Jul 2019 21:36:26 -0700 (PDT) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 549F8120019 for ; Tue, 30 Jul 2019 21:36:26 -0700 (PDT) Received: by mail-ua1-x931.google.com with SMTP id g11so3895680uak.0 for ; Tue, 30 Jul 2019 21:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DuJLKFBVDaXQo5brM5z8BtL8swfnrUmuXDHT1cC7P7I=; b=ouwZKVEwq2V8Y8k3fYBsEMcpkEpAJDxpo5Jdc3jnMkP0ZxXhxKc6e05OutkxhZ/r58 y34VcMfbrpkvrvmOOZAcoQka4k6EIATemk0NT8XaGxbzWPqjB46Ua1Iryc6jcgX3jU9s MpDfsl8FcakHJL/XUayGlkWYoHCIFWI0nb7XpNEae11zLx1DGzS78SjjJp0dXjNvAFSE Fp4F+yxs4Vx+ro5JK+Cv+++TVMcSMe5lNTUB9oxX5dsde4GKz0miIk8h+ebtvHjf/H4C JMyLvrmAhdwNPYUIUND+lH2VsTfEmVoi1wBZ0e1/lRBPtgD8D/04vDom64ofiGcTn5ev Dv5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DuJLKFBVDaXQo5brM5z8BtL8swfnrUmuXDHT1cC7P7I=; b=eD/12dywnD1AZCzcadlNxYAizXvFrcohZr9PtZRDc2B7u3+5weZb03GrFkQjEbb0dV u70NWwcJOSQpNcObki2w+yhi4+pnv4XZuk+PFvCqeXcoVCNInEzxLQIUuVm0RGN7rlsN 4xiNmiuTIUsN2sgAn2phds5fSsv2V9oBgUnq/FjH119N2M07NMx90kA0LcMcnTXufiAk eQ+2oay3BwzTU4cj6jlr7BWkEbWlYsrhWyaTanUxlMBfLQj7uyjuDxeNokWgbuE9/f+7 Hj4mEHtX5JnSIFwG6SDBdFN3D8SeLtNYBmreQq1uSYdj03MHPmvqT/kkVeF6NojRcmCq 4D9Q== X-Gm-Message-State: APjAAAWY6PtQHlkPZd4ftwlMRVRfoEZijcH1AzcjF6sf25lw1aqxVUTr /IE0M0eMwXryBFE9+FPMnP3HH5E0f8dwDbUtwSWPUVUfNKI= X-Google-Smtp-Source: APXvYqwJGD3opVypRN4rs/mka4QYO5KZXbLph/inU++xkfPnDz5GhNM0q3QG/1kiV9GWCmlgUE9fd3HLuvNJwfhn/lY= X-Received: by 2002:ab0:6e2:: with SMTP id g89mr31135459uag.56.1564547784819; Tue, 30 Jul 2019 21:36:24 -0700 (PDT) MIME-Version: 1.0 References: <5dc4a383-93ce-8313-3b1c-434fb0a97876@alvestrand.no> In-Reply-To: <5dc4a383-93ce-8313-3b1c-434fb0a97876@alvestrand.no> From: Justin Uberti Date: Tue, 30 Jul 2019 21:36:13 -0700 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000f3254f058ef2aa87" Archived-At: Subject: Re: [rtcweb] JSEP and ice-pacing attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 04:36:28 -0000 --000000000000f3254f058ef2aa87 Content-Type: text/plain; charset="UTF-8" Right, I don't think JSEP has much to say on the matter here - the pacing isn't exposed as an API to the application, so default values (or ones close to the defaults) will typically be used. On Tue, Jul 30, 2019 at 2:56 PM Harald Alvestrand wrote: > Den 30.07.2019 22:08, skrev Christer Holmberg: > > Hi, > > > > > > > > I noted that JSEP does not specify the usage of the ice-pacing > > attribute. Is there a reason for that? It does explicitly specify how > > all the other ICE related SDP attributes are used. > > I think we overlooked it. > > "ice-pacing" was introduced in draft-ietf-mmusic-ice-sip-sdp-03 (July > 2014), so we can't claim it's because it's too new..... JSEP was only at > its version -07 at that time. > > According to RFC 8445 section 14.2, this attribute sets the value of the > Ta timer (or at least this is the only interpretation that I can see > that makes sense). > > According to draft-ietf-mmusic-ice-sip-sdp-36, "ice-pacing" only allows > increasing the value of Ta to a value larger than its default (50 ms) > (while 8445 seems to indicate that a single agent can go all the way > down to 5 ms, but not lower). > > I'm happy to interpret jsep's silence on the matter as "does not define > additional rules for ice-pacing", and leave it on the list of issues to > consider when JSEP is revised. > > > > > > > > > > Regards, > > > > > > > > Christer > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000f3254f058ef2aa87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, I don't think JSEP has much to say on the matte= r here - the pacing isn't exposed as an API to the application, so defa= ult values (or ones close to the defaults) will typically be used.
On Tue, J= ul 30, 2019 at 2:56 PM Harald Alvestrand <harald@alvestrand.no> wrote:
Den 30.07.2019 22:08, skrev Christer Holmberg= :
> Hi,
>
> =C2=A0
>
> I noted that JSEP does not specify the usage of the ice-pacing
> attribute. Is there a reason for that? It does explicitly specify how<= br> > all the other ICE related SDP attributes are used.

I think we overlooked it.

"ice-pacing" was introduced in draft-ietf-mmusic-ice-sip-sdp-03 (= July
2014), so we can't claim it's because it's too new..... JSEP wa= s only at
its version -07 at that time.

According to RFC 8445 section 14.2, this attribute sets the value of the Ta timer (or at least this is the only interpretation that I can see
that makes sense).

According to draft-ietf-mmusic-ice-sip-sdp-36, "ice-pacing" only = allows
increasing the value of Ta to a value larger than its default (50 ms)
(while 8445 seems to indicate that a single agent can go all the way
down to 5 ms, but not lower).

I'm happy to interpret jsep's silence on the matter as "does n= ot define
additional rules for ice-pacing", and leave it on the list of issues t= o
consider when JSEP is revised.


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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000f3254f058ef2aa87-- From nobody Tue Jul 30 21:38:55 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A06120058 for ; Tue, 30 Jul 2019 21:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omTIAjO2UEEQ for ; Tue, 30 Jul 2019 21:38:45 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 37FDF120075 for ; Tue, 30 Jul 2019 21:38:43 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id k9so45246668vso.5 for ; Tue, 30 Jul 2019 21:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sZs+MY9cawaxzvfG5kG56LE28nXZPay/TmJn+vYZJm4=; b=E4F6TNU3gbiPMMHuQFdhcXW/sZg4Zo6LHr2kqr7An2aJ+lX+8/ICr0II9TwcYVUqv1 un65Dc0Pu39P0V6FP60j8DbnMy1ZeESMQS1VU3YxIQ86NU6n/Gak00x4LDn2xuVwFsEa p/0AlZLHJ602uomlYrLWF8A0ffILPWzYEb2fN9hIrjULI4KRQ4xfRabMbcPRzGT6oyXf o/DLWXwZarG0bxfeZ59DxBdkDj23gbjEQ/uRQJWDnxhAJr36wioSP/og6PClPf5Dbt2b SdjlieGbwKXuxsPwjRUFHUMhRe1po1quqe85qLtyGC3zunUQag1jaQtfFv3XBeyG6/fH 9Liw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sZs+MY9cawaxzvfG5kG56LE28nXZPay/TmJn+vYZJm4=; b=HBoMsDxKg4NOzrQ6cLYhFZeUQm/267iTqOoRGBsIfulbEj188tBqAwsG+ElJrTety5 2EwVl3EFiWWYk3dlDsxn/aBripXj+8/oaa7KNF7rt1JJIIygqwzsxN9G4fr6ELN61epT F4SBhBizkzYPzB6snGAEhYvVGlBI1C9yfw/yK08Y7+eRAQ2vZ5zGJ9qhXhmvBozK8Bhq RVvJCzQZTHaXbB9W4DFl9NhT6yYgN456l3ciF5PiKpVq7YoVaxuz24qhRCn1bnFLrH+d q0ZpT3kQe9PnJGDAhtEDkTufO8p+VxtcSEPADIWNHF1ieuc1hhmozXDoxreFyl61rfBZ JE7w== X-Gm-Message-State: APjAAAVq+PuEzBbVNqt93hyYChst1KNa7AQD+sv7ZCy/1U7OEKQ/Tyej LEBv+lxlZCfS4Z5stVIjUpehsjzQQIxuotqHq5f+Gw== X-Google-Smtp-Source: APXvYqx0o0tOi9i97rWNixqVmBqzv1Ke3HdVn4YItfDm3EKDHsZKM1I3P8WdFKj1kfyCIb0+U9JSBVoyQL5Zf8+Qvo8= X-Received: by 2002:a67:8d8a:: with SMTP id p132mr75247420vsd.103.1564547921800; Tue, 30 Jul 2019 21:38:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 30 Jul 2019 21:38:30 -0700 Message-ID: To: Matthew Kaufman Cc: "tsvwg@ietf.org" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001d56ec058ef2b3e6" Archived-At: Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 04:38:46 -0000 --0000000000001d56ec058ef2b3e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I had thought this was already covered in https://tools.ietf.org/html/rfc5245#section-7.1.2.4, which basically says exactly what you are asking for. On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman wrote: > Was chasing down some webrtc rabbit holes today, and came across the > following concern: > > > > draft-ietf-tsvwg-rtcweb-qos has exactly zero language about how the STUN > packets should be marked for ICE negotiation. The issue is mentioned in > draft-ietf-rtcweb-stun-consent-freshness, but I believe that the rtcweb-q= os > document should be the reference to how an rtcweb transport author should > be setting DiffServ markings. > > > > Also, there was a great conversation on the topic back in 2014 that > unfortunately seems to have petered out before a resolution to some obvio= us > open issues: > https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qztqt= 4UtfZdpuxHTVcg7hZdE > > > > Would be great to finish the conversation before finalizing the > specification for how to mark these. > > > > Personally I=E2=80=99m in the =E2=80=9CICE is testing connectivity, so ST= UN must be marked > exactly the same as corresponding media=E2=80=9D camp. > > > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000001d56ec058ef2b3e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I had thought this was already covered in=C2=A0https://tools.ietf.org= /html/rfc5245#section-7.1.2.4, which basically says exactly what you ar= e asking for.

On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman <mkaufman@bluejeans.com> wrote:

Was chasing down some= webrtc rabbit holes today, and came across the following concern:

=C2=A0<= /span>

draft-ietf-tsvwg-rtcw= eb-qos has exactly zero language about how the STUN packets should be marke= d for ICE negotiation. The issue is mentioned in draft-ietf-rtcweb-stun-con= sent-freshness, but I believe that the rtcweb-qos document should be the reference to how an rtcweb transport= author should be setting DiffServ markings.

=C2=A0<= /span>

Also, there was a gre= at conversation on the topic back in 2014 that unfortunately seems to have = petered out before a resolution to some obvious open issues: https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qzt= qt4UtfZdpuxHTVcg7hZdE

=C2=A0<= /span>

Would be great to fin= ish the conversation before finalizing the specification for how to mark th= ese.

=C2=A0<= /span>

Personally I=E2=80=99= m in the =E2=80=9CICE is testing connectivity, so STUN must be marked exact= ly the same as corresponding media=E2=80=9D camp.

=C2=A0<= /span>

Matthew Kaufman

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000001d56ec058ef2b3e6-- From nobody Tue Jul 30 21:47:49 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131BA120075; Tue, 30 Jul 2019 21:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bluejeans.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 xdrBX5Y8O6YC; Tue, 30 Jul 2019 21:47:36 -0700 (PDT) Received: from mx0a-00292101.pphosted.com (mx0a-00292101.pphosted.com [148.163.148.252]) (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 6124A120019; Tue, 30 Jul 2019 21:47:36 -0700 (PDT) Received: from pps.filterd (m0114294.ppops.net [127.0.0.1]) by mx0a-00292101.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6V4jd3G012592; Wed, 31 Jul 2019 04:47:32 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluejeans.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pod032818; bh=UtIokF/tFaCkrY8MtpFbkEs8vqxPlO79oUkm/as5784=; b=oxu8v3CAIbGuwl9pgEoWlou4D293azpLyyz5H8Y28mgJRpuN9NZ1JCcCHP46q6fvwuaH F0G3hk1moiUhyVQLRKJr3dk4hgAVZ0ykPTwrcLMr/rApHZJx08kpnHbEkuz6tpG++s3E qerU4i5r2acmvGUBCzOctNZR/MI/KbjqFz3cF36TAm8a+XHIewVJ16BAUPFhRlXp+KXo iBK11kfy8MgImyT4rfeDbGRqkce9jK5QGvrCmh29LCdWO/NiQy+hB+qvDVNstmDKZQOR 3jpTL97vyUGKh2f2P+PnGW63P9dyAMSZ9BeGuchVH9zwa4D41DkddfKXYzbaDcG/RP/R VA== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2057.outbound.protection.outlook.com [104.47.36.57]) by mx0a-00292101.pphosted.com with ESMTP id 2u0eexj4kq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 04:47:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RVXbp+1Aixg2BKhBjKB6Yr+vTzy6m8WtHdhHhsNWEDHXFZyOQ7Ja0P5zBj51+BeasyGR6aicc679Y+xqXGwE9vdYNKHlO5QIAgZJ1xm6oCl124RM29SPlJEPOM5APrIUhH1QuNsZNEZwJpmL3znug+Wv2xsPDnjBaEfRK35DN7kWCkSviYUmcR5s4Xyt8KZfZlod5hOWjuesnOuViZlNkWQWsv2DyIzYZIa1TCGb2CX+GhgJqWfPZXKxdXCqiM7xIknaTpvJs9uRb8PWCWXP84uGqVc9dnnF/TJr0irWD3kiWRc7Kvw4yzKWL/uZqW24cgnN9S6D3gd+nrVswestuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UtIokF/tFaCkrY8MtpFbkEs8vqxPlO79oUkm/as5784=; b=V+41k7m+fHQxPP/9U09bgAt4BbBnxMZSvkH4UDMRJ9pikCmaP13klYnQaQE7EzhA/f/4M/GnfPQfovR8xQ0z1xEJltnKPmGwTfSpIW31j2QDMs3Qw0fqUGV6hAKTk2F2KS2vKAYawzPUuIRWm4vqm2Out6K4aySmZRzR45BomsPG8Uu2eCpcHi5Nm/4ayXbxNFx1M1gufawlnnNAUTPeHT+0bV62Fx08lQijPdBYPlUkf5JPw+oIhNyZdpqV9Tf6rnWSAN8tcFkQA/qCjftcKH/S0cEOpMOBHmEWc07cddFOwxGkqhldEL8QiJK44wWZbKnXzXJ2GIkvkAuQnySU9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=bluejeans.com;dmarc=pass action=none header.from=bluejeans.com;dkim=pass header.d=bluejeans.com;arc=none Received: from BY5PR13MB3585.namprd13.prod.outlook.com (10.255.154.206) by BY5PR13MB3585.namprd13.prod.outlook.com (10.255.154.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.9; Wed, 31 Jul 2019 04:47:30 +0000 Received: from BY5PR13MB3585.namprd13.prod.outlook.com ([fe80::6db8:97bd:25ac:febd]) by BY5PR13MB3585.namprd13.prod.outlook.com ([fe80::6db8:97bd:25ac:febd%5]) with mapi id 15.20.2136.010; Wed, 31 Jul 2019 04:47:30 +0000 From: Matthew Kaufman To: Justin Uberti CC: "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos Thread-Index: AQHVR1Wk05FT/JEWvEyZjv/Ejg3eBKbkJO8AgABetoA= Date: Wed, 31 Jul 2019 04:47:30 +0000 Message-ID: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df1:e307:3:8b4d:8db7:a772:aaa3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74d9d989-6f32-4384-39b8-08d7157231ef x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BY5PR13MB3585; x-ms-traffictypediagnostic: BY5PR13MB3585: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(366004)(136003)(346002)(376002)(199004)(189003)(86362001)(6916009)(68736007)(33656002)(54896002)(6486002)(6306002)(36756003)(7736002)(6436002)(6512007)(606006)(8936002)(256004)(81166006)(81156014)(229853002)(8676002)(91956017)(76116006)(66556008)(64756008)(66446008)(66476007)(66946007)(4326008)(25786009)(478600001)(6116002)(46003)(2906002)(486006)(446003)(11346002)(2616005)(14454004)(966005)(6246003)(54906003)(186003)(316002)(71190400001)(71200400001)(476003)(99286004)(5660300002)(53936002)(6506007)(236005)(53546011)(102836004)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3585; H:BY5PR13MB3585.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bluejeans.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QrtSOKkqRjlIRO3Oi13AlwAPOy7H4NzaWd5AjbXUaUX+AXIql4b3V6PJOntrKQHQE6LBQva8EVeOszZvpNr9XKe+2v7jVByyrAf12THOYHrs7BFrGgbRSPSJVMGWp0YSsQF+lYmWZTU/kprHONx3WeCLDoQKr59yym6CkH+HcRhVlopGhUz2hSlpljwuUH0iEjlpD1TN3ssQ3QQKM/LMlY21rH7F9MYWi6O0JpwDc7mXzbinrznoHsPe38tcc6Jjii3rT/zDn9ALTmfnL0iiLlfbOk0bdnWnBw5LBHhPuVWFyak0TBEyUU0W9q1C6lH026TSWdN6CeMH8qI3KrIhgvigrPf40X/B+E/0tLhY0nskKQHmvvhCSGAgN7FimUmZdJEaF+fIWjlKqXE4BgW3PL/ZGp9VRYVcZSj5og0HYKY= Content-Type: multipart/alternative; boundary="_000_64D66E22E8164AC788879CDC01A3252Cbluejeanscom_" MIME-Version: 1.0 X-OriginatorOrg: bluejeans.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74d9d989-6f32-4384-39b8-08d7157231ef X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 04:47:30.2941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 78d2bd57-5099-4199-92a8-4626e5d3c18b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mkaufman@bluejeans.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3585 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-31_02:2019-07-31,2019-07-31 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 mlxscore=0 mlxlogscore=999 phishscore=0 adultscore=0 priorityscore=1501 clxscore=1011 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907310048 Archived-At: Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 04:47:39 -0000 --_000_64D66E22E8164AC788879CDC01A3252Cbluejeanscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SUYgb25lIGJlbGlldmVzIHRoYXQgbm9uZSBvZiB0aGUgb3BlbiBpc3N1ZXMgbWVudGlvbmVkIGlu IHRoZSBlbWFpbCB0aHJlYWQgSSBzZW50IGFyZSBhbiBpc3N1ZSwgdGhlbiBzdXJlLCBSRkM1MjQ1 IGFwcGxpZXMuDQoNCkJ1dCBldmVuIHNvLCBJIHdvdWxkIGFyZ3VlIHRoYXQgZHJhZnQtaWV0Zi10 c3Z3Zy1ydGN3ZWItcW9zIHNob3VsZCBzYXkgd2hhdCB0byBkbyBhbmQgcmVmZXJlbmNlIDUyNDUu DQoNCkFsdGVybmF0aXZlbHksIG9uZSBtaWdodCBiZWxpZXZlIHRoYXQgb25lIG9yIG1vcmUgb2Yg dGhlIGlzc3VlcyBhcmUgYSByZWFsIHByb2JsZW3igKYgaW4gd2hpY2ggY2FzZSB3ZSBzaG91bGQg c3BlY2lmeSBhbHRlcm5hdGl2ZSBiZWhhdmlvci4NCg0KTWF0dGhldyBLYXVmbWFuDQoNCkZyb206 IEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgSnVs eSAzMSwgMjAxOSBhdCAxMDowOCBBTQ0KVG86IE1hdHRoZXcgS2F1Zm1hbiA8bWthdWZtYW5AYmx1 ZWplYW5zLmNvbT4NCkNjOiAidHN2d2dAaWV0Zi5vcmciIDx0c3Z3Z0BpZXRmLm9yZz4sICJydGN3 ZWJAaWV0Zi5vcmciIDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gU1RV TiBEU0NQIGFuZCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MNCg0KSSBoYWQgdGhvdWdodCB0 aGlzIHdhcyBhbHJlYWR5IGNvdmVyZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzUyNDUjc2VjdGlvbi03LjEuMi40PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1MjQ1LTIzc2VjdGlvbi0y RDcuMS4yLjQmZD1Ed01GYVEmYz1QcFBjYWJrbk5GNlhKRkJhZUdIMDZnJnI9OVpkd2liY2FpdFJa eW84ME9uZ3NJUUlYVHM1di05UEc4SFQxWWxJYXRWSSZtPWZicE1JVmw0THVGTjVzb1UyQXZpMU5i SUktLW9wb2xWSGVqZWxYbjJzdkUmcz1sdEdFZ2JwMTBpVWMxZ0JPX2NpbVF2dFpaOUhmaUpPbV95 c3AzWk9vMGVRJmU9Piwgd2hpY2ggYmFzaWNhbGx5IHNheXMgZXhhY3RseSB3aGF0IHlvdSBhcmUg YXNraW5nIGZvci4NCg0KT24gVHVlLCBKdWwgMzAsIDIwMTkgYXQgOTowOSBQTSBNYXR0aGV3IEth dWZtYW4gPG1rYXVmbWFuQGJsdWVqZWFucy5jb208bWFpbHRvOm1rYXVmbWFuQGJsdWVqZWFucy5j b20+PiB3cm90ZToNCldhcyBjaGFzaW5nIGRvd24gc29tZSB3ZWJydGMgcmFiYml0IGhvbGVzIHRv ZGF5LCBhbmQgY2FtZSBhY3Jvc3MgdGhlIGZvbGxvd2luZyBjb25jZXJuOg0KDQpkcmFmdC1pZXRm LXRzdndnLXJ0Y3dlYi1xb3MgaGFzIGV4YWN0bHkgemVybyBsYW5ndWFnZSBhYm91dCBob3cgdGhl IFNUVU4gcGFja2V0cyBzaG91bGQgYmUgbWFya2VkIGZvciBJQ0UgbmVnb3RpYXRpb24uIFRoZSBp c3N1ZSBpcyBtZW50aW9uZWQgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItc3R1bi1jb25zZW50LWZyZXNo bmVzcywgYnV0IEkgYmVsaWV2ZSB0aGF0IHRoZSBydGN3ZWItcW9zIGRvY3VtZW50IHNob3VsZCBi ZSB0aGUgcmVmZXJlbmNlIHRvIGhvdyBhbiBydGN3ZWIgdHJhbnNwb3J0IGF1dGhvciBzaG91bGQg YmUgc2V0dGluZyBEaWZmU2VydiBtYXJraW5ncy4NCg0KQWxzbywgdGhlcmUgd2FzIGEgZ3JlYXQg Y29udmVyc2F0aW9uIG9uIHRoZSB0b3BpYyBiYWNrIGluIDIwMTQgdGhhdCB1bmZvcnR1bmF0ZWx5 IHNlZW1zIHRvIGhhdmUgcGV0ZXJlZCBvdXQgYmVmb3JlIGEgcmVzb2x1dGlvbiB0byBzb21lIG9i dmlvdXMgb3BlbiBpc3N1ZXM6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9icm93 c2UvcnRjd2ViLz9nYnQ9MSZpbmRleD1ISDBxenRxdDRVdGZaZHB1eEhUVmNnN2haZEU8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2 ZS5pZXRmLm9yZ19hcmNoX2Jyb3dzZV9ydGN3ZWJfLTNGZ2J0LTNEMS0yNmluZGV4LTNESEgwcXp0 cXQ0VXRmWmRwdXhIVFZjZzdoWmRFJmQ9RHdNRmFRJmM9UHBQY2Fia25ORjZYSkZCYWVHSDA2ZyZy PTlaZHdpYmNhaXRSWnlvODBPbmdzSVFJWFRzNXYtOVBHOEhUMVlsSWF0VkkmbT1mYnBNSVZsNEx1 Rk41c29VMkF2aTFOYklJLS1vcG9sVkhlamVsWG4yc3ZFJnM9RmxyU1B4TXZVSXJOLWlxRHNFbVJJ MVUwVVJKbklOc3J1MVRFVldOTVVCUSZlPT4NCg0KV291bGQgYmUgZ3JlYXQgdG8gZmluaXNoIHRo ZSBjb252ZXJzYXRpb24gYmVmb3JlIGZpbmFsaXppbmcgdGhlIHNwZWNpZmljYXRpb24gZm9yIGhv dyB0byBtYXJrIHRoZXNlLg0KDQpQZXJzb25hbGx5IEnigJltIGluIHRoZSDigJxJQ0UgaXMgdGVz dGluZyBjb25uZWN0aXZpdHksIHNvIFNUVU4gbXVzdCBiZSBtYXJrZWQgZXhhY3RseSB0aGUgc2Ft ZSBhcyBjb3JyZXNwb25kaW5nIG1lZGlh4oCdIGNhbXAuDQoNCk1hdHRoZXcgS2F1Zm1hbg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWls aW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19ydGN3ZWImZD1Ed01GYVEmYz1QcFBjYWJrbk5GNlhKRkJhZUdIMDZnJnI9OVpkd2li Y2FpdFJaeW84ME9uZ3NJUUlYVHM1di05UEc4SFQxWWxJYXRWSSZtPWZicE1JVmw0THVGTjVzb1Uy QXZpMU5iSUktLW9wb2xWSGVqZWxYbjJzdkUmcz04OUdrU3h3RWhHNjMtaWw5YW42OUNPeDROTnJB OG5NM2k0c2lSVUhNRkhNJmU9Pg0K --_000_64D66E22E8164AC788879CDC01A3252Cbluejeanscom_ Content-Type: text/html; charset="utf-8" Content-ID: <996106EC7FA0C845B24000E727D13D51@namprd13.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklGIG9uZSBiZWxpZXZlcyB0aGF0IG5vbmUgb2YgdGhlIG9wZW4gaXNzdWVzIG1l bnRpb25lZCBpbiB0aGUgZW1haWwgdGhyZWFkIEkgc2VudCBhcmUgYW4gaXNzdWUsIHRoZW4gc3Vy ZSwgUkZDNTI0NSBhcHBsaWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgZXZlbiBzbywg SSB3b3VsZCBhcmd1ZSB0aGF0IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyBzaG91bGQgc2F5 IHdoYXQgdG8gZG8gYW5kIHJlZmVyZW5jZSA1MjQ1LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bHRlcm5hdGl2ZWx5LCBvbmUgbWlnaHQgYmVsaWV2ZSB0aGF0IG9uZSBvciBtb3JlIG9mIHRoZSBp c3N1ZXMgYXJlIGEgcmVhbCBwcm9ibGVt4oCmIGluIHdoaWNoIGNhc2Ugd2Ugc2hvdWxkIHNwZWNp ZnkgYWx0ZXJuYXRpdmUgYmVoYXZpb3IuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hdHRoZXcg S2F1Zm1hbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SnVzdGlu IFViZXJ0aSAmbHQ7anViZXJ0aUBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRu ZXNkYXksIEp1bHkgMzEsIDIwMTkgYXQgMTA6MDggQU08YnI+DQo8Yj5UbzogPC9iPk1hdHRoZXcg S2F1Zm1hbiAmbHQ7bWthdWZtYW5AYmx1ZWplYW5zLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O3RzdndnQGlldGYub3JnJnF1b3Q7ICZsdDt0c3Z3Z0BpZXRmLm9yZyZndDssICZxdW90O3J0 Y3dlYkBpZXRmLm9yZyZxdW90OyAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5SZTogW3J0Y3dlYl0gU1RVTiBEU0NQIGFuZCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dl Yi1xb3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgaGFkIHRob3VnaHQgdGhpcyB3YXMgYWxyZWFkeSBjb3ZlcmVkIGluJm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzUyNDUtMjNzZWN0aW9uLTJENy4xLjIuNCZhbXA7 ZD1Ed01GYVEmYW1wO2M9UHBQY2Fia25ORjZYSkZCYWVHSDA2ZyZhbXA7cj05WmR3aWJjYWl0Ulp5 bzgwT25nc0lRSVhUczV2LTlQRzhIVDFZbElhdFZJJmFtcDttPWZicE1JVmw0THVGTjVzb1UyQXZp MU5iSUktLW9wb2xWSGVqZWxYbjJzdkUmYW1wO3M9bHRHRWdicDEwaVVjMWdCT19jaW1RdnRaWjlI ZmlKT21feXNwM1pPbzBlUSZhbXA7ZT0iPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 MjQ1I3NlY3Rpb24tNy4xLjIuNDwvYT4sDQogd2hpY2ggYmFzaWNhbGx5IHNheXMgZXhhY3RseSB3 aGF0IHlvdSBhcmUgYXNraW5nIGZvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDMwLCAyMDE5IGF0IDk6MDkgUE0gTWF0dGhldyBLYXVm bWFuICZsdDs8YSBocmVmPSJtYWlsdG86bWthdWZtYW5AYmx1ZWplYW5zLmNvbSI+bWthdWZtYW5A Ymx1ZWplYW5zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldhcyBjaGFzaW5n IGRvd24gc29tZSB3ZWJydGMgcmFiYml0IGhvbGVzIHRvZGF5LCBhbmQgY2FtZSBhY3Jvc3MgdGhl IGZvbGxvd2luZyBjb25jZXJuOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ZHJhZnQtaWV0 Zi10c3Z3Zy1ydGN3ZWItcW9zIGhhcyBleGFjdGx5IHplcm8gbGFuZ3VhZ2UgYWJvdXQgaG93IHRo ZSBTVFVOIHBhY2tldHMgc2hvdWxkIGJlIG1hcmtlZCBmb3IgSUNFIG5lZ290aWF0aW9uLiBUaGUg aXNzdWUgaXMgbWVudGlvbmVkIGluIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVz aG5lc3MsDQogYnV0IEkgYmVsaWV2ZSB0aGF0IHRoZSBydGN3ZWItcW9zIGRvY3VtZW50IHNob3Vs ZCBiZSB0aGUgcmVmZXJlbmNlIHRvIGhvdyBhbiBydGN3ZWIgdHJhbnNwb3J0IGF1dGhvciBzaG91 bGQgYmUgc2V0dGluZyBEaWZmU2VydiBtYXJraW5ncy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkFsc28sIHRoZXJlIHdhcyBhIGdyZWF0IGNvbnZlcnNhdGlvbiBvbiB0aGUgdG9waWMgYmFj ayBpbiAyMDE0IHRoYXQgdW5mb3J0dW5hdGVseSBzZWVtcyB0byBoYXZlIHBldGVyZWQgb3V0IGJl Zm9yZSBhIHJlc29sdXRpb24gdG8gc29tZSBvYnZpb3VzIG9wZW4gaXNzdWVzOg0KPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYWls YXJjaGl2ZS5pZXRmLm9yZ19hcmNoX2Jyb3dzZV9ydGN3ZWJfLTNGZ2J0LTNEMS0yNmluZGV4LTNE SEgwcXp0cXQ0VXRmWmRwdXhIVFZjZzdoWmRFJmFtcDtkPUR3TUZhUSZhbXA7Yz1QcFBjYWJrbk5G NlhKRkJhZUdIMDZnJmFtcDtyPTlaZHdpYmNhaXRSWnlvODBPbmdzSVFJWFRzNXYtOVBHOEhUMVls SWF0VkkmYW1wO209ZmJwTUlWbDRMdUZONXNvVTJBdmkxTmJJSS0tb3BvbFZIZWplbFhuMnN2RSZh bXA7cz1GbHJTUHhNdlVJck4taXFEc0VtUkkxVTBVUkpuSU5zcnUxVEVWV05NVUJRJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dz ZS9ydGN3ZWIvP2didD0xJmFtcDtpbmRleD1ISDBxenRxdDRVdGZaZHB1eEhUVmNnN2haZEU8L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Xb3VsZCBiZSBncmVhdCB0byBmaW5pc2ggdGhl IGNvbnZlcnNhdGlvbiBiZWZvcmUgZmluYWxpemluZyB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgaG93 IHRvIG1hcmsgdGhlc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QZXJzb25hbGx5IEni gJltIGluIHRoZSDigJxJQ0UgaXMgdGVzdGluZyBjb25uZWN0aXZpdHksIHNvIFNUVU4gbXVzdCBi ZSBtYXJrZWQgZXhhY3RseSB0aGUgc2FtZSBhcyBjb3JyZXNwb25kaW5nIG1lZGlh4oCdIGNhbXAu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NYXR0aGV3IEthdWZtYW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f cnRjd2ViJmFtcDtkPUR3TUZhUSZhbXA7Yz1QcFBjYWJrbk5GNlhKRkJhZUdIMDZnJmFtcDtyPTla ZHdpYmNhaXRSWnlvODBPbmdzSVFJWFRzNXYtOVBHOEhUMVlsSWF0VkkmYW1wO209ZmJwTUlWbDRM dUZONXNvVTJBdmkxTmJJSS0tb3BvbFZIZWplbFhuMnN2RSZhbXA7cz04OUdrU3h3RWhHNjMtaWw5 YW42OUNPeDROTnJBOG5NM2k0c2lSVUhNRkhNJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_64D66E22E8164AC788879CDC01A3252Cbluejeanscom_-- From nobody Tue Jul 30 22:06:59 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E14A120075 for ; Tue, 30 Jul 2019 22:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.4 X-Spam-Level: X-Spam-Status: No, score=-17.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxaDjg2visnJ for ; Tue, 30 Jul 2019 22:06:45 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 834DA120019 for ; Tue, 30 Jul 2019 22:06:45 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id j26so45320998vsn.10 for ; Tue, 30 Jul 2019 22:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LYDptezAr72Zpsnf7mmc04SCGTlD9LZkultljDP3d/U=; b=rZdKjxyOyQXk0YZhs3h9oB2+JZaYGMinQAYcSynZMHBPI/uNRGMsv1dxKgEmsXBA2j TXceEeHQ/jVV9fh2+tK5BR7V9ZhljJQjpWdpwoX+rE9QTt5IiCtoFru1kV37HQuDCd/N sVcms5MjfzquwJnW4ANSMmXvmD/+001hjGpipgmo6rn4rT8hDPgIYtIH89gC04goV7ak tkSVjekXETkhFDBPrkABzGvVml/fsQiE2b0Zz8/HXMPpmLhXqIeJHTfAa29dm3bcwhLJ ZzcAXujho2ZzPWmjI6BjNRE+K+Jz+QfgUyZC+aoVGoH/MRYHUEHTxLSGZ0WWbK91M8gO ERaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LYDptezAr72Zpsnf7mmc04SCGTlD9LZkultljDP3d/U=; b=ASCZZLmGitCBbzI7a8Xm2BuKD2pgFo6ueiGRPGG+LldT809ttMSkOk/T/kOEj7vgDl q8OEQ60u6qwoQvLOt1pdE64sAzegJJGyYX4mkU8n6xUdj3YTyieyWj29c2lWABrgtDxv rK3KFQRnal1wndbdCJa1NCAD1oZYwyXsx7YOQTkq2toK21wKcwFKbcwJSln/3Ndm5IFB PFVi2KVWaZPq61KeGy9YeWifYpRL3d5NZLfRpjSK26oNyvJROgj4TdmqpyeiF9rUC3Ho Z6Uwg5ed7bdco6QRBbSrhbSoWrk8oFsOB4Yil7Gb6s4zvwyDjEJAcooDWyjC+tRNqzOz jxqA== X-Gm-Message-State: APjAAAVgPdyY9CuTbG1syrpp4/9eHXec+qDO7xX8bEESlSAWnY0Bkoml 50ECAugtcy9ItviPgX7ZVsNMcOS63KRJW8Oy4EPy1A== X-Google-Smtp-Source: APXvYqzIc4gPleeh9yJTRZrPOCgvhUsi5nqfXo5wQvt7CbKgVpwLg1qqNNscKjP6bAjysHtuCu6uSuSnTbBQfQamm/8= X-Received: by 2002:a67:ff0a:: with SMTP id v10mr79603765vsp.1.1564549604032; Tue, 30 Jul 2019 22:06:44 -0700 (PDT) MIME-Version: 1.0 References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> In-Reply-To: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> From: Justin Uberti Date: Tue, 30 Jul 2019 22:06:32 -0700 Message-ID: To: Matthew Kaufman Cc: "tsvwg@ietf.org" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000623cb2058ef31782" Archived-At: Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 05:06:49 -0000 --000000000000623cb2058ef31782 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hmm, right. We have definitely observed that some networks will eat marked traffic, so there needs to be some sort of trial exchange to ensure a given marking will work. Can you summarize the other issues you are concerned about? On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman wrote: > IF one believes that none of the open issues mentioned in the email threa= d > I sent are an issue, then sure, RFC5245 applies. > > > > But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos should say > what to do and reference 5245. > > > > Alternatively, one might believe that one or more of the issues are a rea= l > problem=E2=80=A6 in which case we should specify alternative behavior. > > > > Matthew Kaufman > > > > *From: *Justin Uberti > *Date: *Wednesday, July 31, 2019 at 10:08 AM > *To: *Matthew Kaufman > *Cc: *"tsvwg@ietf.org" , "rtcweb@ietf.org" < > rtcweb@ietf.org> > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos > > > > I had thought this was already covered in > https://tools.ietf.org/html/rfc5245#section-7.1.2.4 > , > which basically says exactly what you are asking for. > > > > On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman > wrote: > > Was chasing down some webrtc rabbit holes today, and came across the > following concern: > > > > draft-ietf-tsvwg-rtcweb-qos has exactly zero language about how the STUN > packets should be marked for ICE negotiation. The issue is mentioned in > draft-ietf-rtcweb-stun-consent-freshness, but I believe that the rtcweb-q= os > document should be the reference to how an rtcweb transport author should > be setting DiffServ markings. > > > > Also, there was a great conversation on the topic back in 2014 that > unfortunately seems to have petered out before a resolution to some obvio= us > open issues: > https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qztqt= 4UtfZdpuxHTVcg7hZdE > > > > > Would be great to finish the conversation before finalizing the > specification for how to mark these. > > > > Personally I=E2=80=99m in the =E2=80=9CICE is testing connectivity, so ST= UN must be marked > exactly the same as corresponding media=E2=80=9D camp. > > > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --000000000000623cb2058ef31782 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hmm, right. We have definitely observed that some networks= will eat marked traffic, so there needs to be some sort of trial exchange = to ensure a given marking will work.=C2=A0

Can you summa= rize the other issues you are concerned about?=C2=A0

On Tue, Jul 30, 2= 019 at 9:47 PM Matthew Kaufman <mkaufman@bluejeans.com> wrote:

IF one believes that none of the open issues mention= ed in the email thread I sent are an issue, then sure, RFC5245 applies.<= /u>

=C2=A0

But even so, I would argue that draft-ietf-tsvwg-rtc= web-qos should say what to do and reference 5245.

=C2=A0

Alternatively, one might believe that one or more of= the issues are a real problem=E2=80=A6 in which case we should specify alt= ernative behavior.

=C2=A0

Matthew Kaufman

=C2=A0

From: = Justin Uberti <juberti@google.com= >
Date: Wednesday, July 31, 2019 at 10:08 AM
To: Matthew Kaufman <mkaufman@bluejeans.com>
Cc: "tsvwg@= ietf.org" <= tsvwg@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

=C2=A0

I had thought this was already covered in=C2=A0https://tools.ietf.org/html/rfc5245#= section-7.1.2.4, which basically says exactly what you are asking for.

=C2=A0

On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman <= mkaufman@blueje= ans.com> wrote:

Was chasing down some webrtc rabbit holes today, and= came across the following concern:

=C2=A0

draft-ietf-tsvwg-rtcweb-qos has exactly zero languag= e about how the STUN packets should be marked for ICE negotiation. The issu= e is mentioned in draft-ietf-rtcweb-stun-consent-freshness, but I believe that the rtcweb-qos document should be the reference to how = an rtcweb transport author should be setting DiffServ markings.

=C2=A0

Also, there was a great conversation on the topic ba= ck in 2014 that unfortunately seems to have petered out before a resolution= to some obvious open issues: https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qzt= qt4UtfZdpuxHTVcg7hZdE

=C2=A0

Would be great to finish the conversation before fin= alizing the specification for how to mark these.

=C2=A0

Personally I=E2=80=99m in the =E2=80=9CICE is testin= g connectivity, so STUN must be marked exactly the same as corresponding me= dia=E2=80=9D camp.

=C2=A0

Matthew Kaufman

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

--000000000000623cb2058ef31782-- From nobody Tue Jul 30 22:10:11 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32ACB120075; Tue, 30 Jul 2019 22:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bluejeans.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 q9TcMOKQRFez; Tue, 30 Jul 2019 22:10:07 -0700 (PDT) Received: from mx0a-00292101.pphosted.com (mx0a-00292101.pphosted.com [148.163.148.252]) (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 1BE1D120019; Tue, 30 Jul 2019 22:10:07 -0700 (PDT) Received: from pps.filterd (m0114293.ppops.net [127.0.0.1]) by mx0a-00292101.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6V5A4ir021903; Wed, 31 Jul 2019 05:10:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bluejeans.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pod032818; bh=IdcrDirTBfZ6/+EgFuUHO64fCzna6reDIQALbEEZvJ4=; b=tm2WYsumBUmaKhYlBvjGNhKtdIqtTbCzo9xQ+vFykUKP3duY4yKzE6Dwlb+iufjN6pQH TT1wwl2WxKIJvJrEQE1C0yMs4whCgniGFt8tW7ynqRP81AzM0HcpKJhyOSkBW9cqT3zw +sg3T2GWsgQVNX0aCfZAqN32kmy/Z+WsUy/oXxVemJWHuF50nRT2bnqBXdQN+Y2nDRYA 2T578Umux04/gtWdu6+CdETJ9Hhyh/lRkiQmjf+eU5BvqRfHbpseb4yDgw/hp6Q6zvaB 8qfNKYjirnmK6dZQX7PWLcqqNsqjoEcy4Aeq+MHOPMwU9a2HGD3wfE9QPGcgUiAdeiWQ kQ== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2056.outbound.protection.outlook.com [104.47.37.56]) by mx0a-00292101.pphosted.com with ESMTP id 2u0d9wt5gs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 05:10:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nMLSm+Zr9m9FWFY5o+TzMTYlDuG5JkHOOJBpg6mfMhWAib55v/nKp81BZpRwM2gFBCs55Gdqqmf3FEcIraFlg+1q1QqylreekjqbJZxLfQj8LDAVGPpJ69OwQ2bRAE39GANAci1aETtPkTEYqdnHP4fer82ZaliuQG8rFuJUEchmYc8h8FSe2JdVh6InSypcCP2mGoEY15lD/qroRvuWZrmSQkF81TpOud6ARgTJaY5Jb1qx0mjjx0f3GYj80Jc+Z5MrJIN/ZTmtUoKj67uaYidDehS8oihRxDZ9wevK75WuJJW4itSrOJAupy6yZWFUEl4T7LcVqBfGXc0h9FRVWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IdcrDirTBfZ6/+EgFuUHO64fCzna6reDIQALbEEZvJ4=; b=donYzjhLoZvYTCRlL87Ft0fv0ZYt0xov5E61FmflVLoloA9J0HhjriBQ9ssZ+V2iys7W4IfC4ubjM+PWv6ma2OZDLutlHCFyY+zE/TLuO43tnM9IYXg65ipwdQ4BtJs3zvgtrtzyrh2jLjxu52p9uJbghhTS6LTqTJSVApJaQRIpzaVc6D8UxNmhqa4e2MmpP7+eQPBo4sdZ9QLcxC6R79bfO+a8wKcX7r4f/5ZujSxybpRCLaK2Il3a4WcLV8tuhJ6B7jkb/L5o/qSlm19ygwBiL8jAKX6Dp1WKRhzuzmcq87lQPXuN9I9hn2b+qidhqhrMbV/FCWlUA2vnHAnI/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=bluejeans.com;dmarc=pass action=none header.from=bluejeans.com;dkim=pass header.d=bluejeans.com;arc=none Received: from BY5PR13MB3585.namprd13.prod.outlook.com (10.255.154.206) by BY5PR13MB3159.namprd13.prod.outlook.com (10.255.163.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.9; Wed, 31 Jul 2019 05:09:59 +0000 Received: from BY5PR13MB3585.namprd13.prod.outlook.com ([fe80::6db8:97bd:25ac:febd]) by BY5PR13MB3585.namprd13.prod.outlook.com ([fe80::6db8:97bd:25ac:febd%5]) with mapi id 15.20.2136.010; Wed, 31 Jul 2019 05:09:59 +0000 From: Matthew Kaufman To: Justin Uberti CC: "tsvwg@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos Thread-Index: AQHVR1Wk05FT/JEWvEyZjv/Ejg3eBKbkJO8AgABetoD//6kfAIAAXSqA Date: Wed, 31 Jul 2019 05:09:59 +0000 Message-ID: References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [115.114.78.133] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62b56aa0-7112-42e9-bd58-08d71575563e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BY5PR13MB3159; x-ms-traffictypediagnostic: BY5PR13MB3159: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39850400004)(366004)(396003)(199004)(189003)(4326008)(3846002)(6116002)(53936002)(71200400001)(71190400001)(26005)(33656002)(102836004)(55236004)(53546011)(6506007)(186003)(8936002)(25786009)(81166006)(81156014)(8676002)(478600001)(7736002)(99286004)(76176011)(2906002)(68736007)(54906003)(229853002)(6246003)(316002)(236005)(6512007)(54896002)(6306002)(6436002)(6916009)(11346002)(486006)(66066001)(476003)(86362001)(2616005)(446003)(6486002)(606006)(256004)(5660300002)(36756003)(66556008)(66476007)(76116006)(64756008)(14454004)(66446008)(66946007)(91956017)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR13MB3159; H:BY5PR13MB3585.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bluejeans.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: q/pGzs8mGh3DkjZNiEr4hrs9ZinNUb39E35E6Vt8rGpZ/E8aRDSgz9/EoL8T8En9oDIQeG0fbb3QcUjo7MNCdYQzCgF7mBsB5+3bE5WmYFUQTWdI8eoXBbeqGWyC5yVXKmdplYudpUYlesfTppxd+WUhJwGzmTUf5FZ1oDeN6lQrCR9/UDH0n14yS942xpCk/5RnfvFRLkky3NI5pVm6pSNAFtCSQHIpDxo/WIA1yDjS9/p/o+vbqveQwVSSkSatXYr7CNqvoJms3doGEpDKUzY9ZxE6AHBQs8M3UKibp3/mVKKNL9KBCV16B2Ebz2DJpiqlB2ub/tr5wLTa7sluz1PVV4dytJ4VhPhqQ+O2+Qxz6HdqEZTpocWLFtrCvZ//D2Xc/3RBj0JlGWhD+9V1y55M0twzNjvxYpMh5ayxCQM= Content-Type: multipart/alternative; boundary="_000_D36DCE878A9E4D3E92413BA356D1ACFBbluejeanscom_" MIME-Version: 1.0 X-OriginatorOrg: bluejeans.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62b56aa0-7112-42e9-bd58-08d71575563e X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 05:09:59.7544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 78d2bd57-5099-4199-92a8-4626e5d3c18b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mkaufman@bluejeans.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3159 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-31_02:2019-07-31,2019-07-31 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 phishscore=0 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907310053 Archived-At: Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 05:10:10 -0000 --_000_D36DCE878A9E4D3E92413BA356D1ACFBbluejeanscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBub3RlZCB0d28gb2YgcGFydGljdWxhciBpbnRlcmVzdOKApiBvbmUgaXMgdGhlIOKAnG5ldHdv cmsgZWF0cyBEU0NQLW1hcmtlZCBidXQgYWxsb3dzIG5vbi1tYXJrZWTigJ0gY2FzZS4gQXJndW1l bnRzIGdvIGJvdGggd2F5cyBhcyB0byB3aGF0IG9uZSBzaG91bGQgZG8gaW4gdGhpcyBjYXNlIChm b2xsb3cgbmV0d29yayBhZG1pbiBkZXNpcmVzIHZzLiB3b3JrIGFzIG9mdGVuIGFzIHBvc3NpYmxl KS4NCg0KVGhlIG90aGVyIGlzIHBpY2tpbmcgd2hpY2ggRFNDUCB2YWx1ZSBpbiB0aGUgY2FzZSB3 aGVyZSBtdWx0aXBsZXhpbmcgaXMgaW4gdXNlIGFuZCB5b3UgZG9u4oCZdCBrbm93IHdoZXRoZXIg eW914oCZcmUgYXVkaW8tb25seSBvciBhdWRpby1wbHVzLXZpZGVvIG9yIGRhdGEtb25seSBhdCB0 aGUgdGltZSB5b3UgZG8gdGhlIElDRSBleGNoYW5nZS4NCg0KKE5ldmVyIG1pbmQgdGhhdCBXaW5k b3dzIGhhcyBsaW1pdGF0aW9ucyBvbiBtYXJraW5nLCB3aGljaCBJ4oCZbSBzdXJlIHdl4oCZdmUg YWxsIGRlYWx0IHdpdGgpDQoNCk1hdHRoZXcgS2F1Zm1hbg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRp IDxqdWJlcnRpQGdvb2dsZS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMzEsIDIwMTkgYXQg MTA6MzYgQU0NClRvOiBNYXR0aGV3IEthdWZtYW4gPG1rYXVmbWFuQGJsdWVqZWFucy5jb20+DQpD YzogInRzdndnQGlldGYub3JnIiA8dHN2d2dAaWV0Zi5vcmc+LCAicnRjd2ViQGlldGYub3JnIiA8 cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFNUVU4gRFNDUCBhbmQgZHJh ZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zDQoNCmhtbSwgcmlnaHQuIFdlIGhhdmUgZGVmaW5pdGVs eSBvYnNlcnZlZCB0aGF0IHNvbWUgbmV0d29ya3Mgd2lsbCBlYXQgbWFya2VkIHRyYWZmaWMsIHNv IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgc29ydCBvZiB0cmlhbCBleGNoYW5nZSB0byBlbnN1cmUg YSBnaXZlbiBtYXJraW5nIHdpbGwgd29yay4NCg0KQ2FuIHlvdSBzdW1tYXJpemUgdGhlIG90aGVy IGlzc3VlcyB5b3UgYXJlIGNvbmNlcm5lZCBhYm91dD8NCg0KT24gVHVlLCBKdWwgMzAsIDIwMTkg YXQgOTo0NyBQTSBNYXR0aGV3IEthdWZtYW4gPG1rYXVmbWFuQGJsdWVqZWFucy5jb208bWFpbHRv Om1rYXVmbWFuQGJsdWVqZWFucy5jb20+PiB3cm90ZToNCklGIG9uZSBiZWxpZXZlcyB0aGF0IG5v bmUgb2YgdGhlIG9wZW4gaXNzdWVzIG1lbnRpb25lZCBpbiB0aGUgZW1haWwgdGhyZWFkIEkgc2Vu dCBhcmUgYW4gaXNzdWUsIHRoZW4gc3VyZSwgUkZDNTI0NSBhcHBsaWVzLg0KDQpCdXQgZXZlbiBz bywgSSB3b3VsZCBhcmd1ZSB0aGF0IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyBzaG91bGQg c2F5IHdoYXQgdG8gZG8gYW5kIHJlZmVyZW5jZSA1MjQ1Lg0KDQpBbHRlcm5hdGl2ZWx5LCBvbmUg bWlnaHQgYmVsaWV2ZSB0aGF0IG9uZSBvciBtb3JlIG9mIHRoZSBpc3N1ZXMgYXJlIGEgcmVhbCBw cm9ibGVt4oCmIGluIHdoaWNoIGNhc2Ugd2Ugc2hvdWxkIHNwZWNpZnkgYWx0ZXJuYXRpdmUgYmVo YXZpb3IuDQoNCk1hdHRoZXcgS2F1Zm1hbg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRp QGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXks IEp1bHkgMzEsIDIwMTkgYXQgMTA6MDggQU0NClRvOiBNYXR0aGV3IEthdWZtYW4gPG1rYXVmbWFu QGJsdWVqZWFucy5jb208bWFpbHRvOm1rYXVmbWFuQGJsdWVqZWFucy5jb20+Pg0KQ2M6ICJ0c3Z3 Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+IiA8dHN2d2dAaWV0Zi5vcmc8bWFpbHRv OnRzdndnQGlldGYub3JnPj4sICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4iIDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW3J0Y3dlYl0gU1RVTiBEU0NQIGFuZCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MNCg0K SSBoYWQgdGhvdWdodCB0aGlzIHdhcyBhbHJlYWR5IGNvdmVyZWQgaW4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzUyNDUjc2VjdGlvbi03LjEuMi40PGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1 MjQ1LTIzc2VjdGlvbi0yRDcuMS4yLjQmZD1Ed01GYVEmYz1QcFBjYWJrbk5GNlhKRkJhZUdIMDZn JnI9OVpkd2liY2FpdFJaeW84ME9uZ3NJUUlYVHM1di05UEc4SFQxWWxJYXRWSSZtPWZicE1JVmw0 THVGTjVzb1UyQXZpMU5iSUktLW9wb2xWSGVqZWxYbjJzdkUmcz1sdEdFZ2JwMTBpVWMxZ0JPX2Np bVF2dFpaOUhmaUpPbV95c3AzWk9vMGVRJmU9Piwgd2hpY2ggYmFzaWNhbGx5IHNheXMgZXhhY3Rs eSB3aGF0IHlvdSBhcmUgYXNraW5nIGZvci4NCg0KT24gVHVlLCBKdWwgMzAsIDIwMTkgYXQgOTow OSBQTSBNYXR0aGV3IEthdWZtYW4gPG1rYXVmbWFuQGJsdWVqZWFucy5jb208bWFpbHRvOm1rYXVm bWFuQGJsdWVqZWFucy5jb20+PiB3cm90ZToNCldhcyBjaGFzaW5nIGRvd24gc29tZSB3ZWJydGMg cmFiYml0IGhvbGVzIHRvZGF5LCBhbmQgY2FtZSBhY3Jvc3MgdGhlIGZvbGxvd2luZyBjb25jZXJu Og0KDQpkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MgaGFzIGV4YWN0bHkgemVybyBsYW5ndWFn ZSBhYm91dCBob3cgdGhlIFNUVU4gcGFja2V0cyBzaG91bGQgYmUgbWFya2VkIGZvciBJQ0UgbmVn b3RpYXRpb24uIFRoZSBpc3N1ZSBpcyBtZW50aW9uZWQgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItc3R1 bi1jb25zZW50LWZyZXNobmVzcywgYnV0IEkgYmVsaWV2ZSB0aGF0IHRoZSBydGN3ZWItcW9zIGRv Y3VtZW50IHNob3VsZCBiZSB0aGUgcmVmZXJlbmNlIHRvIGhvdyBhbiBydGN3ZWIgdHJhbnNwb3J0 IGF1dGhvciBzaG91bGQgYmUgc2V0dGluZyBEaWZmU2VydiBtYXJraW5ncy4NCg0KQWxzbywgdGhl cmUgd2FzIGEgZ3JlYXQgY29udmVyc2F0aW9uIG9uIHRoZSB0b3BpYyBiYWNrIGluIDIwMTQgdGhh dCB1bmZvcnR1bmF0ZWx5IHNlZW1zIHRvIGhhdmUgcGV0ZXJlZCBvdXQgYmVmb3JlIGEgcmVzb2x1 dGlvbiB0byBzb21lIG9idmlvdXMgb3BlbiBpc3N1ZXM6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9icm93c2UvcnRjd2ViLz9nYnQ9MSZpbmRleD1ISDBxenRxdDRVdGZaZHB1eEhU VmNnN2haZEU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX2Jyb3dzZV9ydGN3ZWJfLTNGZ2J0LTNEMS0y NmluZGV4LTNESEgwcXp0cXQ0VXRmWmRwdXhIVFZjZzdoWmRFJmQ9RHdNRmFRJmM9UHBQY2Fia25O RjZYSkZCYWVHSDA2ZyZyPTlaZHdpYmNhaXRSWnlvODBPbmdzSVFJWFRzNXYtOVBHOEhUMVlsSWF0 VkkmbT1mYnBNSVZsNEx1Rk41c29VMkF2aTFOYklJLS1vcG9sVkhlamVsWG4yc3ZFJnM9RmxyU1B4 TXZVSXJOLWlxRHNFbVJJMVUwVVJKbklOc3J1MVRFVldOTVVCUSZlPT4NCg0KV291bGQgYmUgZ3Jl YXQgdG8gZmluaXNoIHRoZSBjb252ZXJzYXRpb24gYmVmb3JlIGZpbmFsaXppbmcgdGhlIHNwZWNp ZmljYXRpb24gZm9yIGhvdyB0byBtYXJrIHRoZXNlLg0KDQpQZXJzb25hbGx5IEnigJltIGluIHRo ZSDigJxJQ0UgaXMgdGVzdGluZyBjb25uZWN0aXZpdHksIHNvIFNUVU4gbXVzdCBiZSBtYXJrZWQg ZXhhY3RseSB0aGUgc2FtZSBhcyBjb3JyZXNwb25kaW5nIG1lZGlh4oCdIGNhbXAuDQoNCk1hdHRo ZXcgS2F1Zm1hbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19ydGN3ZWImZD1Ed01GYVEmYz1QcFBjYWJrbk5GNlhKRkJh ZUdIMDZnJnI9OVpkd2liY2FpdFJaeW84ME9uZ3NJUUlYVHM1di05UEc4SFQxWWxJYXRWSSZtPWZi cE1JVmw0THVGTjVzb1UyQXZpMU5iSUktLW9wb2xWSGVqZWxYbjJzdkUmcz04OUdrU3h3RWhHNjMt aWw5YW42OUNPeDROTnJBOG5NM2k0c2lSVUhNRkhNJmU9Pg0K --_000_D36DCE878A9E4D3E92413BA356D1ACFBbluejeanscom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgbm90ZWQgdHdvIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3TigKYgb25lIGlzIHRo ZSDigJxuZXR3b3JrIGVhdHMgRFNDUC1tYXJrZWQgYnV0IGFsbG93cyBub24tbWFya2Vk4oCdIGNh c2UuIEFyZ3VtZW50cyBnbyBib3RoIHdheXMgYXMgdG8gd2hhdCBvbmUgc2hvdWxkIGRvIGluIHRo aXMgY2FzZSAoZm9sbG93IG5ldHdvcmsgYWRtaW4gZGVzaXJlcyB2cy4gd29yayBhcyBvZnRlbiBh cyBwb3NzaWJsZSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvdGhlciBpcyBwaWNraW5n IHdoaWNoIERTQ1AgdmFsdWUgaW4gdGhlIGNhc2Ugd2hlcmUgbXVsdGlwbGV4aW5nIGlzIGluIHVz ZSBhbmQgeW91IGRvbuKAmXQga25vdyB3aGV0aGVyIHlvdeKAmXJlIGF1ZGlvLW9ubHkgb3IgYXVk aW8tcGx1cy12aWRlbyBvciBkYXRhLW9ubHkgYXQgdGhlIHRpbWUgeW91IGRvIHRoZSBJQ0UgZXhj aGFuZ2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihOZXZlciBtaW5kIHRoYXQgV2luZG93cyBo YXMgbGltaXRhdGlvbnMgb24gbWFya2luZywgd2hpY2ggSeKAmW0gc3VyZSB3ZeKAmXZlIGFsbCBk ZWFsdCB3aXRoKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXR0aGV3IEthdWZtYW48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkp1c3RpbiBVYmVydGkgJmx0O2p1 YmVydGlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdWx5IDMx LCAyMDE5IGF0IDEwOjM2IEFNPGJyPg0KPGI+VG86IDwvYj5NYXR0aGV3IEthdWZtYW4gJmx0O21r YXVmbWFuQGJsdWVqZWFucy5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDt0c3Z3Z0BpZXRm Lm9yZyZxdW90OyAmbHQ7dHN2d2dAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtydGN3ZWJAaWV0Zi5vcmcm cXVvdDsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFty dGN3ZWJdIFNUVU4gRFNDUCBhbmQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5obW0s IHJpZ2h0LiBXZSBoYXZlIGRlZmluaXRlbHkgb2JzZXJ2ZWQgdGhhdCBzb21lIG5ldHdvcmtzIHdp bGwgZWF0IG1hcmtlZCB0cmFmZmljLCBzbyB0aGVyZSBuZWVkcyB0byBiZSBzb21lIHNvcnQgb2Yg dHJpYWwgZXhjaGFuZ2UgdG8gZW5zdXJlIGEgZ2l2ZW4gbWFya2luZyB3aWxsIHdvcmsuJm5ic3A7 DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3Ug c3VtbWFyaXplIHRoZSBvdGhlciBpc3N1ZXMgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQ/Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFR1ZSwgSnVsIDMwLCAyMDE5IGF0IDk6NDcgUE0gTWF0dGhldyBLYXVmbWFuICZsdDs8YSBocmVm PSJtYWlsdG86bWthdWZtYW5AYmx1ZWplYW5zLmNvbSI+bWthdWZtYW5AYmx1ZWplYW5zLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklGIG9uZSBiZWxpZXZlcyB0aGF0IG5vbmUg b2YgdGhlIG9wZW4gaXNzdWVzIG1lbnRpb25lZCBpbiB0aGUgZW1haWwgdGhyZWFkIEkgc2VudCBh cmUgYW4gaXNzdWUsIHRoZW4gc3VyZSwgUkZDNTI0NSBhcHBsaWVzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QnV0IGV2ZW4gc28sIEkgd291bGQgYXJndWUgdGhhdCBkcmFmdC1pZXRmLXRz dndnLXJ0Y3dlYi1xb3Mgc2hvdWxkIHNheSB3aGF0IHRvIGRvIGFuZCByZWZlcmVuY2UgNTI0NS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsdGVybmF0aXZlbHksIG9uZSBtaWdodCBiZWxp ZXZlIHRoYXQgb25lIG9yIG1vcmUgb2YgdGhlIGlzc3VlcyBhcmUgYSByZWFsIHByb2JsZW3igKYg aW4gd2hpY2ggY2FzZSB3ZSBzaG91bGQgc3BlY2lmeSBhbHRlcm5hdGl2ZSBiZWhhdmlvci48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1hdHRoZXcgS2F1Zm1hbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5KdXN0aW4gVWJlcnRpICZsdDs8YSBocmVm PSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29n bGUuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdWx5IDMxLCAyMDE5 IGF0IDEwOjA4IEFNPGJyPg0KPGI+VG86IDwvYj5NYXR0aGV3IEthdWZtYW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpta2F1Zm1hbkBibHVlamVhbnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWthdWZtYW5A Ymx1ZWplYW5zLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWls dG86dHN2d2dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50c3Z3Z0BpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRz dndnQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtydGN3ZWJdIFNUVU4gRFNDUCBhbmQg ZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYWQgdGhvdWdodCB0aGlzIHdh cyBhbHJlYWR5IGNvdmVyZWQgaW4mbmJzcDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNTI0 NS0yM3NlY3Rpb24tMkQ3LjEuMi40JmFtcDtkPUR3TUZhUSZhbXA7Yz1QcFBjYWJrbk5GNlhKRkJh ZUdIMDZnJmFtcDtyPTlaZHdpYmNhaXRSWnlvODBPbmdzSVFJWFRzNXYtOVBHOEhUMVlsSWF0Vkkm YW1wO209ZmJwTUlWbDRMdUZONXNvVTJBdmkxTmJJSS0tb3BvbFZIZWplbFhuMnN2RSZhbXA7cz1s dEdFZ2JwMTBpVWMxZ0JPX2NpbVF2dFpaOUhmaUpPbV95c3AzWk9vMGVRJmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1I3NlY3Rpb24tNy4x LjIuNDwvYT4sDQogd2hpY2ggYmFzaWNhbGx5IHNheXMgZXhhY3RseSB3aGF0IHlvdSBhcmUgYXNr aW5nIGZvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBUdWUsIEp1bCAzMCwgMjAxOSBhdCA5OjA5IFBNIE1hdHRoZXcgS2F1Zm1hbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1rYXVmbWFuQGJsdWVqZWFucy5jb20iIHRhcmdldD0iX2JsYW5rIj5ta2F1 Zm1hbkBibHVlamVhbnMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldhcyBjaGFzaW5nIGRvd24gc29tZSB3ZWJy dGMgcmFiYml0IGhvbGVzIHRvZGF5LCBhbmQgY2FtZSBhY3Jvc3MgdGhlIGZvbGxvd2luZyBjb25j ZXJuOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWIt cW9zIGhhcyBleGFjdGx5IHplcm8gbGFuZ3VhZ2UgYWJvdXQgaG93IHRoZSBTVFVOIHBhY2tldHMg c2hvdWxkIGJlIG1hcmtlZCBmb3IgSUNFIG5lZ290aWF0aW9uLiBUaGUgaXNzdWUgaXMgbWVudGlv bmVkIGluIGRyYWZ0LWlldGYtcnRjd2ViLXN0dW4tY29uc2VudC1mcmVzaG5lc3MsDQogYnV0IEkg YmVsaWV2ZSB0aGF0IHRoZSBydGN3ZWItcW9zIGRvY3VtZW50IHNob3VsZCBiZSB0aGUgcmVmZXJl bmNlIHRvIGhvdyBhbiBydGN3ZWIgdHJhbnNwb3J0IGF1dGhvciBzaG91bGQgYmUgc2V0dGluZyBE aWZmU2VydiBtYXJraW5ncy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsc28sIHRoZXJl IHdhcyBhIGdyZWF0IGNvbnZlcnNhdGlvbiBvbiB0aGUgdG9waWMgYmFjayBpbiAyMDE0IHRoYXQg dW5mb3J0dW5hdGVseSBzZWVtcyB0byBoYXZlIHBldGVyZWQgb3V0IGJlZm9yZSBhIHJlc29sdXRp b24gdG8gc29tZSBvYnZpb3VzIG9wZW4gaXNzdWVzOg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9y Z19hcmNoX2Jyb3dzZV9ydGN3ZWJfLTNGZ2J0LTNEMS0yNmluZGV4LTNESEgwcXp0cXQ0VXRmWmRw dXhIVFZjZzdoWmRFJmFtcDtkPUR3TUZhUSZhbXA7Yz1QcFBjYWJrbk5GNlhKRkJhZUdIMDZnJmFt cDtyPTlaZHdpYmNhaXRSWnlvODBPbmdzSVFJWFRzNXYtOVBHOEhUMVlsSWF0VkkmYW1wO209ZmJw TUlWbDRMdUZONXNvVTJBdmkxTmJJSS0tb3BvbFZIZWplbFhuMnN2RSZhbXA7cz1GbHJTUHhNdlVJ ck4taXFEc0VtUkkxVTBVUkpuSU5zcnUxVEVWV05NVUJRJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9ydGN3ZWIvP2didD0x JmFtcDtpbmRleD1ISDBxenRxdDRVdGZaZHB1eEhUVmNnN2haZEU8L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Xb3VsZCBiZSBncmVhdCB0byBmaW5pc2ggdGhlIGNvbnZlcnNhdGlvbiBi ZWZvcmUgZmluYWxpemluZyB0aGUgc3BlY2lmaWNhdGlvbiBmb3IgaG93IHRvIG1hcmsgdGhlc2Uu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QZXJzb25hbGx5IEnigJltIGluIHRoZSDigJxJ Q0UgaXMgdGVzdGluZyBjb25uZWN0aXZpdHksIHNvIFNUVU4gbXVzdCBiZSBtYXJrZWQgZXhhY3Rs eSB0aGUgc2FtZSBhcyBjb3JyZXNwb25kaW5nIG1lZGlh4oCdIGNhbXAuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5NYXR0aGV3IEthdWZtYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19ydGN3ZWImYW1wO2Q9 RHdNRmFRJmFtcDtjPVBwUGNhYmtuTkY2WEpGQmFlR0gwNmcmYW1wO3I9OVpkd2liY2FpdFJaeW84 ME9uZ3NJUUlYVHM1di05UEc4SFQxWWxJYXRWSSZhbXA7bT1mYnBNSVZsNEx1Rk41c29VMkF2aTFO YklJLS1vcG9sVkhlamVsWG4yc3ZFJmFtcDtzPTg5R2tTeHdFaEc2My1pbDlhbjY5Q094NE5OckE4 bk0zaTRzaVJVSE1GSE0mYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D36DCE878A9E4D3E92413BA356D1ACFBbluejeanscom_-- From nobody Tue Jul 30 22:13:18 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036BE120019 for ; Tue, 30 Jul 2019 22:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.4 X-Spam-Level: X-Spam-Status: No, score=-17.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRRAmAJ83HaZ for ; Tue, 30 Jul 2019 22:13:06 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 A702812004C for ; Tue, 30 Jul 2019 22:13:06 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id 190so45313941vsf.9 for ; Tue, 30 Jul 2019 22:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EOMIYR1GEwP4AIrOdfRbesZqnZKtwBeUyS7FK79BnXs=; b=j4cptWVK+iXZ7/4Rg6ared26JYfT1o08LD/kwnbxwU7w8HadmMfjBoMe4lUZeCt9as AA0v5QGhHdTMSSieP3c4/0mkfkrWFMSSqmQvWYT3cwVdIsDY+P3SYx+FJJQrX+eK/Xx9 mGBUnvjXVccq7IiJEnF2eubHA18T3w92Ei8A53hYIIKUQ16onrHmMOukUmSCtV4N6ULF R1NQXKpR16SUZ8N+Eq4/eZWFHoFbg8W1ZsnAtJVjvDU4N6smKsIsajgPAtQ15SaAvz/U 56Y+MOokikx8DI5a35gYUZD3l3LDczaVl8k3205K/y5MHMUBoyNU2qcMW0uHFP4IvZYB mPow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EOMIYR1GEwP4AIrOdfRbesZqnZKtwBeUyS7FK79BnXs=; b=dXZ+0pJEbdck6/Zks81OTz4lctYo3vktfrb4//v378CuewbFts4uDqjEM0legbPrWO 3djDW29kWspFo1Cj4E83hWJEO7+6NKRLluPHcI4zf7FO6watVOTE3DMzsuBq3Y/Ebdb7 PXdCkEQXSopYXX+lT2YmbLfyX7ZEE3XI/dv5BWgNQZsQROggiJC/skZBdIddp6ntmXCI l/vupWAfMNZJDoS6+uYFZlEeO94jJvPAIt/lp44kgyCaJYxavjZ0I1V7lc12r7SNljFN MSpFqSVyAuvW1i/ze1BVcWQqybzS+oEIliHgMI5VVq5deP4CCHknRxUSoCaLh4puC6Hh k91g== X-Gm-Message-State: APjAAAVGQnGqy85KDTuLB9epwoE8pDVYCXsM6Hp3c+j0UoH9ys+ICAxm qjORfXjTCMWFKk/aPTdvtheGX2muexCa7A1vWCLESw== X-Google-Smtp-Source: APXvYqymAzL8xRvLWzDbddYyN/Fp9k5gngfuyt4SoklrFoXjd5keuUP15aZ8XJ/TxuJJ4GybD4SPdkq8pGfb/wGgG3M= X-Received: by 2002:a67:e906:: with SMTP id c6mr28576056vso.82.1564549985159; Tue, 30 Jul 2019 22:13:05 -0700 (PDT) MIME-Version: 1.0 References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> In-Reply-To: From: Justin Uberti Date: Tue, 30 Jul 2019 22:12:53 -0700 Message-ID: To: Matthew Kaufman Cc: "tsvwg@ietf.org" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001a0013058ef32e45" Archived-At: Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 05:13:10 -0000 --0000000000001a0013058ef32e45 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman wrote: > I noted two of particular interest=E2=80=A6 one is the =E2=80=9Cnetwork e= ats DSCP-marked > but allows non-marked=E2=80=9D case. Arguments go both ways as to what on= e should > do in this case (follow network admin desires vs. work as often as > possible). > I lean towards 'work as often as possible', which suggests we probably need both marked and unmarked ICE checks to determine whether we should mark media traffic (and potentially multiple differently marked checks in the mux case). > > > The other is picking which DSCP value in the case where multiplexing is i= n > use and you don=E2=80=99t know whether you=E2=80=99re audio-only or audio= -plus-video or > data-only at the time you do the ICE exchange. > > > > (Never mind that Windows has limitations on marking, which I=E2=80=99m su= re we=E2=80=99ve > all dealt with) > > > > Matthew Kaufman > > > > *From: *Justin Uberti > *Date: *Wednesday, July 31, 2019 at 10:36 AM > *To: *Matthew Kaufman > *Cc: *"tsvwg@ietf.org" , "rtcweb@ietf.org" < > rtcweb@ietf.org> > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos > > > > hmm, right. We have definitely observed that some networks will eat marke= d > traffic, so there needs to be some sort of trial exchange to ensure a giv= en > marking will work. > > > > Can you summarize the other issues you are concerned about? > > > > On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman > wrote: > > IF one believes that none of the open issues mentioned in the email threa= d > I sent are an issue, then sure, RFC5245 applies. > > > > But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos should say > what to do and reference 5245. > > > > Alternatively, one might believe that one or more of the issues are a rea= l > problem=E2=80=A6 in which case we should specify alternative behavior. > > > > Matthew Kaufman > > > > *From: *Justin Uberti > *Date: *Wednesday, July 31, 2019 at 10:08 AM > *To: *Matthew Kaufman > *Cc: *"tsvwg@ietf.org" , "rtcweb@ietf.org" < > rtcweb@ietf.org> > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos > > > > I had thought this was already covered in > https://tools.ietf.org/html/rfc5245#section-7.1.2.4 > , > which basically says exactly what you are asking for. > > > > On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman > wrote: > > Was chasing down some webrtc rabbit holes today, and came across the > following concern: > > > > draft-ietf-tsvwg-rtcweb-qos has exactly zero language about how the STUN > packets should be marked for ICE negotiation. The issue is mentioned in > draft-ietf-rtcweb-stun-consent-freshness, but I believe that the rtcweb-q= os > document should be the reference to how an rtcweb transport author should > be setting DiffServ markings. > > > > Also, there was a great conversation on the topic back in 2014 that > unfortunately seems to have petered out before a resolution to some obvio= us > open issues: > https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qztqt= 4UtfZdpuxHTVcg7hZdE > > > > > Would be great to finish the conversation before finalizing the > specification for how to mark these. > > > > Personally I=E2=80=99m in the =E2=80=9CICE is testing connectivity, so ST= UN must be marked > exactly the same as corresponding media=E2=80=9D camp. > > > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --0000000000001a0013058ef32e45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 30, 2019 at 10:10 PM Matt= hew Kaufman <mkaufman@bluejean= s.com> wrote:

I noted two of particular interest=E2=80=A6 one is t= he =E2=80=9Cnetwork eats DSCP-marked but allows non-marked=E2=80=9D case. A= rguments go both ways as to what one should do in this case (follow network= admin desires vs. work as often as possible).

=

I lean towards 'work as often as possible', whi= ch suggests we probably need both marked and unmarked ICE checks to determi= ne whether we should mark media traffic (and potentially multiple different= ly marked checks in the mux case).=C2=A0

=C2=A0

The other is picking which DSCP value in the case wh= ere multiplexing is in use and you don=E2=80=99t know whether you=E2=80=99r= e audio-only or audio-plus-video or data-only at the time you do the ICE ex= change.

=C2=A0

(Never mind that Windows has limitations on marking,= which I=E2=80=99m sure we=E2=80=99ve all dealt with)

=C2=A0

Matthew Kaufman

=C2=A0

From: = Justin Uberti <juberti@google.com= >
Date: Wednesday, July 31, 2019 at 10:36 AM
To: Matthew Kaufman <mkaufman@bluejeans.com>
Cc: "tsvwg@= ietf.org" <= tsvwg@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

=C2=A0

hmm, right. We have definitely observed that some ne= tworks will eat marked traffic, so there needs to be some sort of trial exc= hange to ensure a given marking will work.=C2=A0

=C2=A0

Can you summarize the other issues you are concerned= about?=C2=A0

=C2=A0

On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman <= mkaufman@blueje= ans.com> wrote:

IF one believes that none of the open issues mention= ed in the email thread I sent are an issue, then sure, RFC5245 applies.<= /u>

=C2=A0

But even so, I would argue that draft-ietf-tsvwg-rtc= web-qos should say what to do and reference 5245.

=C2=A0

Alternatively, one might believe that one or more of= the issues are a real problem=E2=80=A6 in which case we should specify alt= ernative behavior.

=C2=A0

Matthew Kaufman

=C2=A0

From: Justin Uberti <juberti@google.com= >
Date: Wednesday, July 31, 2019 at 10:08 AM
To: Matthew Kaufman <mkaufman@bluejeans.com>
Cc: "tsvwg@= ietf.org" <= tsvwg@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos

=C2=A0

I had thought this was already covered in=C2=A0https://tools.ietf.org/html/rfc5245#= section-7.1.2.4, which basically says exactly what you are asking for.

=C2=A0

On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman <= mkaufman@blueje= ans.com> wrote:

Was chasing down some webrtc rabbit holes today, and= came across the following concern:

=C2=A0

draft-ietf-tsvwg-rtcweb-qos has exactly zero languag= e about how the STUN packets should be marked for ICE negotiation. The issu= e is mentioned in draft-ietf-rtcweb-stun-consent-freshness, but I believe that the rtcweb-qos document should be the reference to how = an rtcweb transport author should be setting DiffServ markings.

=C2=A0

Also, there was a great conversation on the topic ba= ck in 2014 that unfortunately seems to have petered out before a resolution= to some obvious open issues: https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qzt= qt4UtfZdpuxHTVcg7hZdE

=C2=A0

Would be great to finish the conversation before fin= alizing the specification for how to mark these.

=C2=A0

Personally I=E2=80=99m in the =E2=80=9CICE is testin= g connectivity, so STUN must be marked exactly the same as corresponding me= dia=E2=80=9D camp.

=C2=A0

Matthew Kaufman

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

--0000000000001a0013058ef32e45-- From nobody Tue Jul 30 23:02:33 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329A7120025 for ; Tue, 30 Jul 2019 23:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 K57c3VGyZnAZ for ; Tue, 30 Jul 2019 23:02:29 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60076.outbound.protection.outlook.com [40.107.6.76]) (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 905BD120019 for ; Tue, 30 Jul 2019 23:02:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ll5qZj/FOmOflKqW/EFCxGIh+KoRGswKfYNvcaTKvnkcnRUAFYzKSyybC9/aEm+bExDEgtNtmA3qHcdObIcGrrdD1zxx0zNmTWW29/0FDfIYTL5x0r7xV4OvyPauqg8KE/6y6FAsYp8dOAfuR6uBXhUCWhq2mRJlAVJxhy0TCZQAofFmqjPxEqBMmVioEKNKQs/hCM0sUuCZOou5bNa8Y3IvTQ+2Vt9C3uD7cNSMP6Rpysp+KWPTTgMvHGgayIZFTF7vCsE1eivB2YQdMbtm0VQrI5JUkqGlxvtTxSNjaTVJXlCES4bS1rKuxx2DYpsmmLJ2aPmhzuLL9bdewdKeAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q7qv4lbTbyj5QvbjEj3CixWUg5yrNEcwPfXpSPTON70=; b=Gdp8XhCtUN8CuBoaqZvQq3CdNe1eQdc4bsiDEBYF8uimzY57KlbWobjssTIBcbbfRtwgwZZBALkMLaFGbzkfEVWSJpHsEiQ2h2X5ibv+By3oz+xJj9ZNRZeTLQbIc75vaUPooEgw8vWT8m7gNFFyQinkx5w1j8MvUZeRuXj2vMN6zpscZeEOvmDgW/vNs9eyNw9b/UDHZ1YW3JFb0Pmtrix+qOYa383awntEYZ6sIhUZT7+whrVyU40si/YUhh2GKIvy+DAq5XwACOVczMG5L2dUVAE7Wf5fCbQsxwa9D//7CJ1IBNmzYUXWlZbcfoMq5ydag+ctIg7pV5LJyzoFTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q7qv4lbTbyj5QvbjEj3CixWUg5yrNEcwPfXpSPTON70=; b=nnjTFz7Jb3jxhvE9zR8L/Mn85wKC/lnoIp40lEY6100pjZEk0ph46Wxm6EOHiJJyKP7lnjN+DsO7ciA/n+fDrxHXKkfnVVpPR91TWlupVJYAy/xvvxD4F3begdG5d7UCEW1vCtiqX13i/MAqCgcqdbYhCrStJiGsl0ecZBnAjzg= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3514.eurprd07.prod.outlook.com (10.170.247.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.11; Wed, 31 Jul 2019 06:02:26 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7%6]) with mapi id 15.20.2136.010; Wed, 31 Jul 2019 06:02:26 +0000 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP and ice-pacing attribute Thread-Index: AdVHEpE+giMmYQ8tTyuReNcouqrB6AADvgIAABDkLnA= Date: Wed, 31 Jul 2019 06:02:26 +0000 Message-ID: References: <5dc4a383-93ce-8313-3b1c-434fb0a97876@alvestrand.no> In-Reply-To: <5dc4a383-93ce-8313-3b1c-434fb0a97876@alvestrand.no> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b5bdb2c8-6008-43ee-579f-08d7157ca997 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3514; x-ms-traffictypediagnostic: HE1PR07MB3514: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(199004)(189003)(74316002)(2906002)(76116006)(6436002)(316002)(478600001)(14454004)(256004)(99286004)(110136005)(6506007)(76176011)(4744005)(102836004)(7696005)(68736007)(26005)(44832011)(8676002)(55016002)(25786009)(8936002)(33656002)(7736002)(81166006)(81156014)(9686003)(86362001)(11346002)(446003)(5660300002)(64756008)(476003)(486006)(66946007)(3846002)(186003)(2501003)(71190400001)(53936002)(66476007)(71200400001)(66446008)(305945005)(66556008)(6116002)(66066001)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3514; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LS4InbfPfsHzeyVwNRyUgVpr9HkMBEDKncqaWBYKW3XeU+cRUGvd/by+JyTFKrrge/Hl5Po5AChvoeDUS3bC/jgzx4YMmGgiUtULdWT9BjXn5eYM+/IWXXQ3HH1XvX1+CuulqohlDZJhTucXdPc7eW/xFMcvKC0gyYtyHhC00ApVuuCMtrV8QrR4f1f1tZI+p5mrspigVn5WMLu3PfgDdiOHKWurUUDJ+sb7o+SABm94mLFwUG9/1k5hyvvBvyXcp+g9jm0FF5dmd9+9aV/aVqyDXuoh1lo5o+uXbA+2Cb4gP5If02JPefic72TGFF+Xf6RUt5t9qZJJ5H/VIHkJQVTxNqSLCy4a5n9hzyuYvFaZ8qScR9gYjehUAeBbJ715EMyXCIcAb3PPyaw5mHnDT7JFnspgC69hDBCCWWrgQHc= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b5bdb2c8-6008-43ee-579f-08d7157ca997 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 06:02:26.0830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3514 Archived-At: Subject: Re: [rtcweb] JSEP and ice-pacing attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 06:02:31 -0000 Hi Harald, >> I noted that JSEP does not specify the usage of the ice-pacing=20 >> attribute. Is there a reason for that? It does explicitly specify how=20 >> all the other ICE related SDP attributes are used. > > I think we overlooked it. > > "ice-pacing" was introduced in draft-ietf-mmusic-ice-sip-sdp-03 (July 201= 4), so we can't claim > it's because it's too new..... JSEP was only at its version -07 at that t= ime. > > According to RFC 8445 section 14.2, this attribute sets the value of the = Ta timer (or at least this=20 > is the only interpretation that I can see that makes sense). Correct. > According to draft-ietf-mmusic-ice-sip-sdp-36, "ice-pacing" only allows i= ncreasing the value of Ta=20 > to a value larger than its default (50 ms) (while 8445 seems to indicate = that a single agent can go=20 > all the way down to 5 ms, but not lower). I gave the exact same comment some time ago, wrote a PR about it, and it ha= s now been fixed in -37, that was submitted yesterday :) Regards, Christer From nobody Tue Jul 30 23:05:30 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F91120025 for ; Tue, 30 Jul 2019 23:05:23 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 viCaxqmYyyCZ for ; Tue, 30 Jul 2019 23:05:20 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40077.outbound.protection.outlook.com [40.107.4.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87955120019 for ; Tue, 30 Jul 2019 23:05:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nmeh9k063YUotZpGoh8V34h2pLsz29xLO5OXwENqMYSXsRhDO2LOIUhDKXN8rwzIaELN/yg8oIxyjDNtKH4UKfKCKMl6UDc6c8qSWCpex4CcA/ukAQNiWDBtv1/VR0nCO6C6qV7OlkphxwC/2oBpL6eNK5FQJ4vThzpLqJUuE2Jb2onRGd461Pjc5YdBnHNmaHH1V4fRdmDMBj6m+4pIj0B7/LqoUcECCW0eAFoRht7Iq5vt6l4va9SLTOYjWDuOSkOK//FSZUTbEpzCTZv+dQUhMtq0yOELS5p79NDbeFE+Wi9MKv9vGgBLj0WkvyW73C5TBDi1NnOq9qkeKxLyQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4zcrV320ladOzX2jX4x2fTfnWBw1LMIbrlD2mt6M0pI=; b=oUZzvyeXYTT7w66smrWIDFhi8gNi/E6mdDDNGfIGD98ZVzkHTmfvq+J1n6DtP0OkuxzgIkeimSL2kfNza8JSYjIGKCxIrA767kCtbwpjPsqy8UXOuO6KygjuKKSCCie8sqUl7329bkUO7irg6qRZ7NErwJGEoEfrjPxnTrZiVUbl1xXu0lad2HR2IdCVNpbK84/0XvF6lsTGYIGHvVvbMdXyMj7IAlEQH6LT/jnRIKFMHQI4CFimnSzwQOqQT9URYHgan7WIsmtqKfdXM9n6jfkC/1ipX3I4IUozNwS2i0Hl2oHlrhWFjHb96JvDFH3mg8/DZd0+rwJkD6pj5kD0cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4zcrV320ladOzX2jX4x2fTfnWBw1LMIbrlD2mt6M0pI=; b=fq0+ffUsgYSh1BKG5gIvGuuwRr4yrqbB8JIRq8306BqrL6Nr0NC1G67nw7ZCQRK+1SOuMTpDXO9bjdVQNQvNSue3i1qTy/m4s7Wtnir+kQVspIbF5+XV9iMax0pGOsORyGlwGQTw1mut+SKawpGvgx2Tfi/Hj6issZKiKByjQe0= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3449.eurprd07.prod.outlook.com (10.170.247.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.10; Wed, 31 Jul 2019 06:05:13 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec0d:f9d3:7159:ba7%6]) with mapi id 15.20.2136.010; Wed, 31 Jul 2019 06:05:13 +0000 From: Christer Holmberg To: Justin Uberti , Harald Alvestrand CC: RTCWeb IETF Thread-Topic: [rtcweb] JSEP and ice-pacing attribute Thread-Index: AdVHEpE+giMmYQ8tTyuReNcouqrB6AADvgIAAA38moAAAwR/IA== Date: Wed, 31 Jul 2019 06:05:13 +0000 Message-ID: References: <5dc4a383-93ce-8313-3b1c-434fb0a97876@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [79.134.118.162] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 875ad7e8-1d7f-4a29-ce3b-08d7157d0d23 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB3449; x-ms-traffictypediagnostic: HE1PR07MB3449: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(39860400002)(396003)(366004)(136003)(199004)(189003)(51444003)(53546011)(64756008)(3846002)(316002)(7736002)(6116002)(2906002)(14454004)(486006)(478600001)(14444005)(44832011)(33656002)(52536014)(11346002)(446003)(66556008)(81166006)(81156014)(790700001)(966005)(76116006)(66446008)(476003)(8936002)(66946007)(66476007)(86362001)(25786009)(110136005)(6506007)(9686003)(8676002)(606006)(9326002)(256004)(68736007)(74316002)(26005)(5660300002)(7696005)(102836004)(236005)(71200400001)(54896002)(66066001)(53936002)(6306002)(71190400001)(6436002)(186003)(76176011)(99286004)(55016002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3449; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2q8NQygtZvZ/6H8iX1hsXlS5DbPDHrSmsRdmEuaklMufGK34DRkc8QDJjLIM4rtTwQTF1CLVNjoM2SESjnpyIuAwhvF5tSgUrBdWVGF9atkRMlqZ8K5d4jhxhO85ttHUDfiOZe3zskGpf6O0H7QM2woC50TFV5rPLUUTaa5poztIKefGnl8CBdbFnHCE7YMidBFg/5/FtEkWfsDztVYPi4+1OYhGuzMtjK6u6PNd37WFxHvOJlXkLt0Kaf8M7iKbnXSK6kkFv1sgZWxvPaYkSbInV0Uz+3MWLI2nXjjcK7n0xkmoEN8CPORk/Ev+pXDqw656TlgK1O+Ngcge4ep6GJmjUBRJgnYx3aOYsj8XoJcuoCM7W4zI6Df1XZcjZLGDp+xA/qsKd6pOsR0rBJb3BvGgeqX1s3wN3LCF9TVk5Dk= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB31615F00C56CD5C15F6AFFA693DF0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 875ad7e8-1d7f-4a29-ce3b-08d7157d0d23 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 06:05:13.0880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: christer.holmberg@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3449 Archived-At: Subject: Re: [rtcweb] JSEP and ice-pacing attribute X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 06:05:23 -0000 --_000_HE1PR07MB31615F00C56CD5C15F6AFFA693DF0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5SaWdodCwgSSBkb24ndCB0aGluayBKU0VQIGhhcyBtdWNoIHRvIHNheSBvbiB0aGUg bWF0dGVyIGhlcmUgLSB0aGUgcGFjaW5nIGlzbid0IGV4cG9zZWQgYXMgYW4gQVBJIHRvIHRoZSA+ YXBwbGljYXRpb24sIHNvIGRlZmF1bHQgdmFsdWVzIChvciBvbmVzIGNsb3NlIHRvIHRoZSBkZWZh dWx0cykgd2lsbCB0eXBpY2FsbHkgYmUgdXNlZC4NCg0KSWYgc29tZXRoaW5nIGlzIE5PVCB1c2Vk L2V4cG9zZWQsIEkgdGhpbmsgdGhhdCB3b3VsZCBoYXZlIGJlZW4gZ29vZCB0byBpbmRpY2F0ZS4N Cg0KQnV0LCBJIHJlYWxpemUgaXTigJlzIGxhdGUgaW4gdGhlIHByb2Nlc3MsIHNvIEnigJlsbCBs ZWF2ZSBpdCBhdCB0aGVyZS4gSnVzdCB3YW50ZWQgdG8gY2xhcmlmeS4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQpPbiBUdWUsIEp1bCAzMCwgMjAxOSBhdCAyOjU2IFBNIEhhcmFsZCBBbHZl c3RyYW5kIDxoYXJhbGRAYWx2ZXN0cmFuZC5ubzxtYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8+ PiB3cm90ZToNCkRlbiAzMC4wNy4yMDE5IDIyOjA4LCBza3JldiBDaHJpc3RlciBIb2xtYmVyZzoN Cj4gSGksDQo+DQo+DQo+DQo+IEkgbm90ZWQgdGhhdCBKU0VQIGRvZXMgbm90IHNwZWNpZnkgdGhl IHVzYWdlIG9mIHRoZSBpY2UtcGFjaW5nDQo+IGF0dHJpYnV0ZS4gSXMgdGhlcmUgYSByZWFzb24g Zm9yIHRoYXQ/IEl0IGRvZXMgZXhwbGljaXRseSBzcGVjaWZ5IGhvdw0KPiBhbGwgdGhlIG90aGVy IElDRSByZWxhdGVkIFNEUCBhdHRyaWJ1dGVzIGFyZSB1c2VkLg0KDQpJIHRoaW5rIHdlIG92ZXJs b29rZWQgaXQuDQoNCiJpY2UtcGFjaW5nIiB3YXMgaW50cm9kdWNlZCBpbiBkcmFmdC1pZXRmLW1t dXNpYy1pY2Utc2lwLXNkcC0wMyAoSnVseQ0KMjAxNCksIHNvIHdlIGNhbid0IGNsYWltIGl0J3Mg YmVjYXVzZSBpdCdzIHRvbyBuZXcuLi4uLiBKU0VQIHdhcyBvbmx5IGF0DQppdHMgdmVyc2lvbiAt MDcgYXQgdGhhdCB0aW1lLg0KDQpBY2NvcmRpbmcgdG8gUkZDIDg0NDUgc2VjdGlvbiAxNC4yLCB0 aGlzIGF0dHJpYnV0ZSBzZXRzIHRoZSB2YWx1ZSBvZiB0aGUNClRhIHRpbWVyIChvciBhdCBsZWFz dCB0aGlzIGlzIHRoZSBvbmx5IGludGVycHJldGF0aW9uIHRoYXQgSSBjYW4gc2VlDQp0aGF0IG1h a2VzIHNlbnNlKS4NCg0KQWNjb3JkaW5nIHRvIGRyYWZ0LWlldGYtbW11c2ljLWljZS1zaXAtc2Rw LTM2LCAiaWNlLXBhY2luZyIgb25seSBhbGxvd3MNCmluY3JlYXNpbmcgdGhlIHZhbHVlIG9mIFRh IHRvIGEgdmFsdWUgbGFyZ2VyIHRoYW4gaXRzIGRlZmF1bHQgKDUwIG1zKQ0KKHdoaWxlIDg0NDUg c2VlbXMgdG8gaW5kaWNhdGUgdGhhdCBhIHNpbmdsZSBhZ2VudCBjYW4gZ28gYWxsIHRoZSB3YXkN CmRvd24gdG8gNSBtcywgYnV0IG5vdCBsb3dlcikuDQoNCkknbSBoYXBweSB0byBpbnRlcnByZXQg anNlcCdzIHNpbGVuY2Ugb24gdGhlIG1hdHRlciBhcyAiZG9lcyBub3QgZGVmaW5lDQphZGRpdGlv bmFsIHJ1bGVzIGZvciBpY2UtcGFjaW5nIiwgYW5kIGxlYXZlIGl0IG9uIHRoZSBsaXN0IG9mIGlz c3VlcyB0bw0KY29uc2lkZXIgd2hlbiBKU0VQIGlzIHJldmlzZWQuDQoNCg0KPg0KPg0KPg0KPiBS ZWdhcmRzLA0KPg0KPg0KPg0KPiBDaHJpc3Rlcg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0 Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYg0K --_000_HE1PR07MB31615F00C56CD5C15F6AFFA693DF0HE1PR07MB3161eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uU2hrcG9zdGl0eXlsaTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7UmlnaHQsIEkgZG9uJ3QgdGhpbmsgSlNFUCBoYXMgbXVjaCB0byBzYXkgb24g dGhlIG1hdHRlciBoZXJlIC0gdGhlIHBhY2luZyBpc24ndCBleHBvc2VkIGFzIGFuIEFQSSB0byB0 aGUgJmd0O2FwcGxpY2F0aW9uLCBzbyBkZWZhdWx0IHZhbHVlcyAob3Igb25lcyBjbG9zZSB0byB0 aGUgZGVmYXVsdHMpIHdpbGwgdHlwaWNhbGx5IGJlIHVzZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgc29tZXRoaW5nIGlzIE5PVCB1c2VkL2V4cG9zZWQsIEkgdGhpbmsgdGhh dCB3b3VsZCBoYXZlIGJlZW4gZ29vZCB0byBpbmRpY2F0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QnV0LCBJIHJlYWxpemUgaXTigJlzIGxhdGUgaW4gdGhlIHByb2Nlc3MsIHNvIEnigJlsbCBs ZWF2ZSBpdCBhdCB0aGVyZS4gSnVzdCB3YW50ZWQgdG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDMwLCAyMDE5IGF0IDI6NTYgUE0gSGFyYWxk IEFsdmVzdHJhbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubyI+aGFy YWxkQGFsdmVzdHJhbmQubm88L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlbiAzMC4wNy4yMDE5IDIyOjA4LCBz a3JldiBDaHJpc3RlciBIb2xtYmVyZzo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0 OyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBub3RlZCB0aGF0IEpTRVAgZG9lcyBub3Qg c3BlY2lmeSB0aGUgdXNhZ2Ugb2YgdGhlIGljZS1wYWNpbmc8YnI+DQomZ3Q7IGF0dHJpYnV0ZS4g SXMgdGhlcmUgYSByZWFzb24gZm9yIHRoYXQ/IEl0IGRvZXMgZXhwbGljaXRseSBzcGVjaWZ5IGhv dzxicj4NCiZndDsgYWxsIHRoZSBvdGhlciBJQ0UgcmVsYXRlZCBTRFAgYXR0cmlidXRlcyBhcmUg dXNlZC48YnI+DQo8YnI+DQpJIHRoaW5rIHdlIG92ZXJsb29rZWQgaXQuPGJyPg0KPGJyPg0KJnF1 b3Q7aWNlLXBhY2luZyZxdW90OyB3YXMgaW50cm9kdWNlZCBpbiBkcmFmdC1pZXRmLW1tdXNpYy1p Y2Utc2lwLXNkcC0wMyAoSnVseTxicj4NCjIwMTQpLCBzbyB3ZSBjYW4ndCBjbGFpbSBpdCdzIGJl Y2F1c2UgaXQncyB0b28gbmV3Li4uLi4gSlNFUCB3YXMgb25seSBhdDxicj4NCml0cyB2ZXJzaW9u IC0wNyBhdCB0aGF0IHRpbWUuPGJyPg0KPGJyPg0KQWNjb3JkaW5nIHRvIFJGQyA4NDQ1IHNlY3Rp b24gMTQuMiwgdGhpcyBhdHRyaWJ1dGUgc2V0cyB0aGUgdmFsdWUgb2YgdGhlPGJyPg0KVGEgdGlt ZXIgKG9yIGF0IGxlYXN0IHRoaXMgaXMgdGhlIG9ubHkgaW50ZXJwcmV0YXRpb24gdGhhdCBJIGNh biBzZWU8YnI+DQp0aGF0IG1ha2VzIHNlbnNlKS48YnI+DQo8YnI+DQpBY2NvcmRpbmcgdG8gZHJh ZnQtaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHAtMzYsICZxdW90O2ljZS1wYWNpbmcmcXVvdDsgb25s eSBhbGxvd3M8YnI+DQppbmNyZWFzaW5nIHRoZSB2YWx1ZSBvZiBUYSB0byBhIHZhbHVlIGxhcmdl ciB0aGFuIGl0cyBkZWZhdWx0ICg1MCBtcyk8YnI+DQood2hpbGUgODQ0NSBzZWVtcyB0byBpbmRp Y2F0ZSB0aGF0IGEgc2luZ2xlIGFnZW50IGNhbiBnbyBhbGwgdGhlIHdheTxicj4NCmRvd24gdG8g NSBtcywgYnV0IG5vdCBsb3dlcikuPGJyPg0KPGJyPg0KSSdtIGhhcHB5IHRvIGludGVycHJldCBq c2VwJ3Mgc2lsZW5jZSBvbiB0aGUgbWF0dGVyIGFzICZxdW90O2RvZXMgbm90IGRlZmluZTxicj4N CmFkZGl0aW9uYWwgcnVsZXMgZm9yIGljZS1wYWNpbmcmcXVvdDssIGFuZCBsZWF2ZSBpdCBvbiB0 aGUgbGlzdCBvZiBpc3N1ZXMgdG88YnI+DQpjb25zaWRlciB3aGVuIEpTRVAgaXMgcmV2aXNlZC48 YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0K Jmd0OyBDaHJpc3Rlcjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBydGN3ZWIgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQomZ3Q7 IDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_HE1PR07MB31615F00C56CD5C15F6AFFA693DF0HE1PR07MB3161eurp_-- From nobody Tue Jul 30 23:32:31 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD40B120052; Tue, 30 Jul 2019 23:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkrIuKbMGNG0; Tue, 30 Jul 2019 23:32:18 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC6112004F; Tue, 30 Jul 2019 23:32:18 -0700 (PDT) Received: from MacBook-Pro-5.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8216B1B000FA; Wed, 31 Jul 2019 07:32:11 +0100 (BST) Message-ID: <5D4135E9.90104@erg.abdn.ac.uk> Date: Wed, 31 Jul 2019 07:32:09 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Justin Uberti CC: Matthew Kaufman , "rtcweb@ietf.org" , "tsvwg@ietf.org" References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 06:32:23 -0000 On 31/07/2019, 06:12, Justin Uberti wrote: > > > On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman > > wrote: > > I noted two of particular interest… one is the “network eats > DSCP-marked but allows non-marked” case. Arguments go both ways as > to what one should do in this case (follow network admin desires > vs. work as often as possible). > > Is that a real observed case - that all traffic that sets a specific DSCP is lost, rather than re-marked? - There's also an obvious case where a specific DSCP is conditioned (e.g. rate-limited), which means some packets traverse the path, but a full media flow will not. However, not sure that observation helps at all. Gorry > I lean towards 'work as often as possible', which suggests we probably > need both marked and unmarked ICE checks to determine whether we > should mark media traffic (and potentially multiple differently marked > checks in the mux case). > > The other is picking which DSCP value in the case where > multiplexing is in use and you don’t know whether you’re > audio-only or audio-plus-video or data-only at the time you do the > ICE exchange. > > (Never mind that Windows has limitations on marking, which I’m > sure we’ve all dealt with) > > Matthew Kaufman > > *From: *Justin Uberti > > *Date: *Wednesday, July 31, 2019 at 10:36 AM > *To: *Matthew Kaufman > > *Cc: *"tsvwg@ietf.org " >, "rtcweb@ietf.org > " > > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos > > hmm, right. We have definitely observed that some networks will > eat marked traffic, so there needs to be some sort of trial > exchange to ensure a given marking will work. > > Can you summarize the other issues you are concerned about? > > On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman > > wrote: > > IF one believes that none of the open issues mentioned in the > email thread I sent are an issue, then sure, RFC5245 applies. > > But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos > should say what to do and reference 5245. > > Alternatively, one might believe that one or more of the > issues are a real problem… in which case we should specify > alternative behavior. > > Matthew Kaufman > > *From: *Justin Uberti > > *Date: *Wednesday, July 31, 2019 at 10:08 AM > *To: *Matthew Kaufman > > *Cc: *"tsvwg@ietf.org " >, "rtcweb@ietf.org > " > > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos > > I had thought this was already covered in > https://tools.ietf.org/html/rfc5245#section-7.1.2.4 > , > which basically says exactly what you are asking for. > > On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman > > wrote: > > Was chasing down some webrtc rabbit holes today, and came > across the following concern: > > draft-ietf-tsvwg-rtcweb-qos has exactly zero language > about how the STUN packets should be marked for ICE > negotiation. The issue is mentioned in > draft-ietf-rtcweb-stun-consent-freshness, but I believe > that the rtcweb-qos document should be the reference to > how an rtcweb transport author should be setting DiffServ > markings. > > Also, there was a great conversation on the topic back in > 2014 that unfortunately seems to have petered out before a > resolution to some obvious open issues: > https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=1&index=HH0qztqt4UtfZdpuxHTVcg7hZdE > > > Would be great to finish the conversation before > finalizing the specification for how to mark these. > > Personally I’m in the “ICE is testing connectivity, so > STUN must be marked exactly the same as corresponding > media” camp. > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From nobody Tue Jul 30 23:42:10 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E4612004F for ; Tue, 30 Jul 2019 23:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUgvZRsn1PeI for ; Tue, 30 Jul 2019 23:42:04 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 9B9CE120045 for ; Tue, 30 Jul 2019 23:42:04 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id k9so45407279vso.5 for ; Tue, 30 Jul 2019 23:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JWRaSS9iFXzad3eElZT92r+y5aFOaRczc+9dsZFgWaQ=; b=BdkadCyp8+xcETBbwoWvH1FX+EqRg9BZQoUr5pOv/9WTmBjamuDbr+2fYFM6+LCEFb phpCZ8GZepBpeWy1EzSaDJClwPUIhkL+asoJxW8lHsLM5RFvvnFpOYTG55xenibN6ixJ PLfVot00ZpqVyalGwqbUdmwerAs620rW6gQbBIm+HAp2+HJ6RyYFnpycNaLk7wHItOBN N5izrIeBvEvkyiUtJaOA98M+SIigePQGPJ87pyWn0tFaH/xD1H3XU0VpyNC9cWeZ9hxP QdBQVKPBL2AsckTOTLMxWMzU/3vnKHABelOc/ot3zZkE2BqZYR4rglpzWTqieaxf6/xP Oeog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JWRaSS9iFXzad3eElZT92r+y5aFOaRczc+9dsZFgWaQ=; b=bFclyl1PKQimrQKxoQ5xb3BAl/iQO6HoKSw+ZlA/DySUj9cZoyC5vTNWi92oJYgzBX +fRKByZL5hcPrzEvEcELqbGGcc3Gm3GnnW0BlFYEk3ZquuITbuGRgyCiL9+kqSuvAdoJ 5YykOAtq1jk5LMiHZe1v8kXulI8m51tN1O7kPcukfD7FDV85u5129gwIIFwH6KNdLNAR xnJj1q/wbqyI5bOvdbQqZMRypmnS3rtCPJjo8Fa36jesvrW64O5HJFmx6TBij7jjo4K2 WpPn0O+DhfxY0FDKqH/40c+zjZq8Ye7T7hIj5Beo1kQvoHkgJVzex7v9g1kovJlXWqVY Jg5A== X-Gm-Message-State: APjAAAXRdPw02wx5DMLkd/4BTJJ8HwSAKhBw0+J54QNwFxeBG5clCBxV /8s4tqI0nQ1cdrhuNp7jYEF8ERSwEZMuwiGz+3YYxw== X-Google-Smtp-Source: APXvYqxasHA7f7EQoW/NyXXeemOvqw+ULagiV9PfPKMIMJ9+zNNqNncmfyV+gWCoQ24pwuBuGT2YiG0fe/V6P7BOf7c= X-Received: by 2002:a67:e906:: with SMTP id c6mr28743491vso.82.1564555323108; Tue, 30 Jul 2019 23:42:03 -0700 (PDT) MIME-Version: 1.0 References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> <5D4135E9.90104@erg.abdn.ac.uk> In-Reply-To: <5D4135E9.90104@erg.abdn.ac.uk> From: Justin Uberti Date: Tue, 30 Jul 2019 23:41:50 -0700 Message-ID: To: gorry@erg.abdn.ac.uk Cc: Matthew Kaufman , "rtcweb@ietf.org" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="000000000000445e4a058ef46cf9" Archived-At: Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 06:42:09 -0000 --000000000000445e4a058ef46cf9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 30, 2019 at 11:32 PM Gorry Fairhurst wrote: > On 31/07/2019, 06:12, Justin Uberti wrote: > > > > > > On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman > > > wrote: > > > > I noted two of particular interest=E2=80=A6 one is the =E2=80=9Cnet= work eats > > DSCP-marked but allows non-marked=E2=80=9D case. Arguments go both = ways as > > to what one should do in this case (follow network admin desires > > vs. work as often as possible). > > > > > Is that a real observed case - that all traffic that sets a specific > DSCP is lost, rather than re-marked? > > - There's also an obvious case where a specific DSCP is conditioned > (e.g. rate-limited), which means some packets traverse the path, but a > full media flow will not. However, not sure that observation helps at all= . > I can't speak for others, but our experience with deploying DSCP en masse is that there are enough cases where dropping happens to outweigh the prioritization benefits. > > Gorry > > > I lean towards 'work as often as possible', which suggests we probably > > need both marked and unmarked ICE checks to determine whether we > > should mark media traffic (and potentially multiple differently marked > > checks in the mux case). > > > > The other is picking which DSCP value in the case where > > multiplexing is in use and you don=E2=80=99t know whether you=E2=80= =99re > > audio-only or audio-plus-video or data-only at the time you do the > > ICE exchange. > > > > (Never mind that Windows has limitations on marking, which I=E2=80= =99m > > sure we=E2=80=99ve all dealt with) > > > > Matthew Kaufman > > > > *From: *Justin Uberti >> > > *Date: *Wednesday, July 31, 2019 at 10:36 AM > > *To: *Matthew Kaufman > > > > *Cc: *"tsvwg@ietf.org " > >, "rtcweb@ietf.org > > " = > > > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos > > > > hmm, right. We have definitely observed that some networks will > > eat marked traffic, so there needs to be some sort of trial > > exchange to ensure a given marking will work. > > > > Can you summarize the other issues you are concerned about? > > > > On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman > > > wrote: > > > > IF one believes that none of the open issues mentioned in the > > email thread I sent are an issue, then sure, RFC5245 applies. > > > > But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos > > should say what to do and reference 5245. > > > > Alternatively, one might believe that one or more of the > > issues are a real problem=E2=80=A6 in which case we should spec= ify > > alternative behavior. > > > > Matthew Kaufman > > > > *From: *Justin Uberti > > > > *Date: *Wednesday, July 31, 2019 at 10:08 AM > > *To: *Matthew Kaufman > > > > *Cc: *"tsvwg@ietf.org " > >, "rtcweb@ietf.org > > " > > > > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-q= os > > > > I had thought this was already covered in > > https://tools.ietf.org/html/rfc5245#section-7.1.2.4 > > < > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_rfc5245-23section-2D7.1.2.4&d=3DDwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9Zd= wibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opo= lVHejelXn2svE&s=3DltGEgbp10iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=3D > >, > > which basically says exactly what you are asking for. > > > > On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman > > > wrote: > > > > Was chasing down some webrtc rabbit holes today, and came > > across the following concern: > > > > draft-ietf-tsvwg-rtcweb-qos has exactly zero language > > about how the STUN packets should be marked for ICE > > negotiation. The issue is mentioned in > > draft-ietf-rtcweb-stun-consent-freshness, but I believe > > that the rtcweb-qos document should be the reference to > > how an rtcweb transport author should be setting DiffServ > > markings. > > > > Also, there was a great conversation on the topic back in > > 2014 that unfortunately seems to have petered out before a > > resolution to some obvious open issues: > > > https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qztqt= 4UtfZdpuxHTVcg7hZdE > > < > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarchive.ietf.o= rg_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg7hZdE&d=3D= DwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1Y= lIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=3DFlrSPxMvUIrN-iqD= sEmRI1U0URJnINsru1TEVWNMUBQ&e=3D > > > > > > Would be great to finish the conversation before > > finalizing the specification for how to mark these. > > > > Personally I=E2=80=99m in the =E2=80=9CICE is testing conne= ctivity, so > > STUN must be marked exactly the same as corresponding > > media=E2=80=9D camp. > > > > Matthew Kaufman > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > < > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_rtcweb&d=3DDwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo= 80OngsIQIXTs5v-9PG8HT1YlIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2s= vE&s=3D89GkSxwEhG63-il9an69COx4NNrA8nM3i4siRUHMFHM&e=3D > > > > > > --000000000000445e4a058ef46cf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 30, 2019 at 11:32 PM Gorr= y Fairhurst <gorry@erg.abdn.ac.u= k> wrote:
On 31/07/2019, 06:12, Justin Uberti wrote:
>
>
> On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman
> <mkaufm= an@bluejeans.com <mailto:mkaufman@bluejeans.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I noted two of particular interest=E2=80=A6 one is = the =E2=80=9Cnetwork eats
>=C2=A0 =C2=A0 =C2=A0DSCP-marked but allows non-marked=E2=80=9D case. Ar= guments go both ways as
>=C2=A0 =C2=A0 =C2=A0to what one should do in this case (follow network = admin desires
>=C2=A0 =C2=A0 =C2=A0vs. work as often as possible).
>
>
Is that a real observed case - that all traffic that sets a specific
DSCP is lost, rather than re-marked?

- There's also an obvious case where a specific DSCP is conditioned (e.g. rate-limited), which means some packets traverse the path, but a
full media flow will not. However, not sure that observation helps at all.<= br>

I can't speak for others, but our e= xperience with deploying DSCP en masse is that there are enough cases where= dropping happens to outweigh the prioritization benefits.=C2=A0

Gorry

> I lean towards 'work as often as possible', which suggests we = probably
> need both marked and unmarked ICE checks to determine whether we
> should mark media traffic (and potentially multiple differently marked=
> checks in the mux case).
>
>=C2=A0 =C2=A0 =C2=A0The other is picking which DSCP value in the case w= here
>=C2=A0 =C2=A0 =C2=A0multiplexing is in use and you don=E2=80=99t know w= hether you=E2=80=99re
>=C2=A0 =C2=A0 =C2=A0audio-only or audio-plus-video or data-only at the = time you do the
>=C2=A0 =C2=A0 =C2=A0ICE exchange.
>
>=C2=A0 =C2=A0 =C2=A0(Never mind that Windows has limitations on marking= , which I=E2=80=99m
>=C2=A0 =C2=A0 =C2=A0sure we=E2=80=99ve all dealt with)
>
>=C2=A0 =C2=A0 =C2=A0Matthew Kaufman
>
>=C2=A0 =C2=A0 =C2=A0*From: *Justin Uberti <juberti@google.com <mailto:juberti@google.com>>= ;
>=C2=A0 =C2=A0 =C2=A0*Date: *Wednesday, July 31, 2019 at 10:36 AM
>=C2=A0 =C2=A0 =C2=A0*To: *Matthew Kaufman <mkaufman@bluejeans.com
>=C2=A0 =C2=A0 =C2=A0<mailto:mkaufman@bluejeans.com>>
>=C2=A0 =C2=A0 =C2=A0*Cc: *"tsvwg@ietf.org <mailto:tsvwg@ietf.org>" <tsvwg@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:tsvwg@ietf.org>>, "rtcweb@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:rtcweb@ietf.org>" <rtcweb@ietf.org <mailto:rtcweb@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0*Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-ts= vwg-rtcweb-qos
>
>=C2=A0 =C2=A0 =C2=A0hmm, right. We have definitely observed that some n= etworks will
>=C2=A0 =C2=A0 =C2=A0eat marked traffic, so there needs to be some sort = of trial
>=C2=A0 =C2=A0 =C2=A0exchange to ensure a given marking will work.
>
>=C2=A0 =C2=A0 =C2=A0Can you summarize the other issues you are concerne= d about?
>
>=C2=A0 =C2=A0 =C2=A0On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman
>=C2=A0 =C2=A0 =C2=A0<mkaufman@bluejeans.com <mailto:mkaufman@bluejeans.com>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IF one believes that none of the open= issues mentioned in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email thread I sent are an issue, the= n sure, RFC5245 applies.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But even so, I would argue that draft= -ietf-tsvwg-rtcweb-qos
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should say what to do and reference 5= 245.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alternatively, one might believe that= one or more of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issues are a real problem=E2=80=A6 in= which case we should specify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alternative behavior.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Matthew Kaufman
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*From: *Justin Uberti <juberti@google.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:juberti@google.com>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Date: *Wednesday, July 31, 2019 at 1= 0:08 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*To: *Matthew Kaufman <mkaufman@bluejeans.com=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:mkaufman@bluejeans.com>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Cc: *"tsvwg@ietf.org <mailto:tsvwg@ietf.org>" <tsvwg@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tsvwg@ietf.org>>, "rtcweb@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:rtcweb@ietf.org>" <rtcweb@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:rtcweb@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Subject: *Re: [rtcweb] STUN DSCP and= draft-ietf-tsvwg-rtcweb-qos
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I had thought this was already covere= d in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://too= ls.ietf.org/html/rfc5245#section-7.1.2.4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://urldefense.proofpoint.com/v2/url?u=3D= https-3A__tools.ietf.org_html_rfc5245-23section-2D7.1.2.4&d=3DDwMFaQ&am= p;c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1Yl= IatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=3DltGEgbp10= iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=3D>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which basically says exactly what you= are asking for.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Jul 30, 2019 at 9:09 PM Matth= ew Kaufman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mkaufman@bluejeans.com <mailto:mkaufman@bluejeans.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Was chasing down some w= ebrtc rabbit holes today, and came
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0across the following co= ncern:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tsvwg-rtcweb= -qos has exactly zero language
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0about how the STUN pack= ets should be marked for ICE
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0negotiation. The issue = is mentioned in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-rtcweb-stun-= consent-freshness, but I believe
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that the rtcweb-qos doc= ument should be the reference to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0how an rtcweb transport= author should be setting DiffServ
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0markings.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Also, there was a great= conversation on the topic back in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02014 that unfortunately= seems to have petered out before a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resolution to some obvi= ous open issues:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.or= g/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qztqt4UtfZdpuxHTVcg7hZdE >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarch= ive.ietf.org_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg= 7hZdE&d=3DDwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo8= 0OngsIQIXTs5v-9PG8HT1YlIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelX= n2svE&s=3DFlrSPxMvUIrN-iqDsEmRI1U0URJnINsru1TEVWNMUBQ&e=3D><= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would be great to finis= h the conversation before
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0finalizing the specific= ation for how to mark these.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Personally I=E2=80=99m = in the =E2=80=9CICE is testing connectivity, so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0STUN must be marked exa= ctly the same as corresponding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0media=E2=80=9D camp. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Matthew Kaufman
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://www.ietf.org/mailman/listinfo/rtcweb
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_mailman_listinfo_rtcweb&d=3DDwMFaQ&c=3DP= pPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&a= mp;m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=3D89GkSxwEhG63-il9= an69COx4NNrA8nM3i4siRUHMFHM&e=3D>
>

--000000000000445e4a058ef46cf9-- From nobody Wed Jul 31 00:19:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7820512009E; Wed, 31 Jul 2019 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Smu-aAuCmxJ; Wed, 31 Jul 2019 00:19:06 -0700 (PDT) Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 BEA8312001B; Wed, 31 Jul 2019 00:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1564557544; x=1596093544; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wv1QDl7KXwF+l8b3w8oExljxD0cftK/g77vP2RN2muE=; b=0dmIdTVdDO6A7pFX5hRlB6gkgQnGFBWng30SLOhweiQLztGsrrCZ8CYO 88gbrABfY4zDqLuiONX8kOMoUiqdU77VzwpOJFrR1qSgMGbUgmwbc1M2Y DwmhDE3DUH4BNSoRKcKFzDK3N/M2ZWz4jCROeetEOw1hcWZQHpBe2cX56 DrNb5Is+SQvD9WSU9w47UICfPUOFhZvcYqtljTZDL1iMzwbXVuX84k9uX hmV+YggLXk1GimQ9zD+eDFmjBoK6UuYLiLw2H2X+Fm6xTwNuk4yBOZWkw E3bI+HoNjda9UQ5gvKk8XxXLD3euIqI1BUjwAya7gBzYJlyel/o7uPFJ/ w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Jul 2019 09:19:00 +0200 X-IronPort-AV: E=Sophos;i="5.64,329,1559512800"; d="scan'208,217";a="470311215" X-MGA-submission: =?us-ascii?q?MDH3tfq2XnJx7tWcjBvnryc7E8047qBEEkgsun?= =?us-ascii?q?ZKcDeo9eQgcAEX1MBqvcP7cFBTVA59wD9w760+RYikIkl8W/sP7Lg2bV?= =?us-ascii?q?hRS4CvrCFtBkFRq4vvO8mqIGsDOEnVyQYVUI+XTUWlqr9urLb8ssfypk?= =?us-ascii?q?8Ipj275YiPdmXvPBLvoX/qBA=3D=3D?= Received: from he105865.emea1.cds.t-internal.com ([10.169.119.42]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 31 Jul 2019 09:19:01 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105865.emea1.cds.t-internal.com (10.169.119.42) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 31 Jul 2019 09:19:00 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 31 Jul 2019 09:19:00 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.19) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 31 Jul 2019 09:19:00 +0200 Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.26) by FRXPR01MB0776.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Wed, 31 Jul 2019 07:19:00 +0000 Received: from FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1]) by FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE ([fe80::64eb:180c:69d1:8be1%5]) with mapi id 15.20.2115.005; Wed, 31 Jul 2019 07:18:59 +0000 From: To: CC: , Thread-Topic: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos Thread-Index: AQHVR15XOUV7TKNSIESqeuE6AVqH3qbkLnmAgAAWJYCAAAK1AIAACFWQ Date: Wed, 31 Jul 2019 07:18:59 +0000 Message-ID: References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> <5D4135E9.90104@erg.abdn.ac.uk> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.190] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e6933dd7-e5c9-44f7-06bb-08d715875bb6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRXPR01MB0776; x-ms-traffictypediagnostic: FRXPR01MB0776: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(346002)(136003)(396003)(189003)(199004)(476003)(5660300002)(11346002)(486006)(81156014)(54906003)(19627235002)(186003)(2906002)(256004)(53936002)(76116006)(26005)(14454004)(66946007)(66446008)(66556008)(64756008)(446003)(66476007)(86362001)(71190400001)(71200400001)(7696005)(52396003)(76176011)(68736007)(4326008)(85202003)(66066001)(53546011)(6306002)(54896002)(9686003)(33656002)(81166006)(85182001)(478600001)(55016002)(316002)(8676002)(7736002)(6116002)(790700001)(3846002)(236005)(8936002)(102836004)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0776; H:FRXPR01MB0710.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CgYpIdwWLXqVxQcfz6+Nll/gsqwyGUmr7YKuAhDr0QYsws5/kCDgdh//0avAbZBF326uaWFUTN0pEHGV1ThkGaStAEYVJthZRlLbMaLvrgoX+xpXo7SKA8BXbKai+mNdtP2/s6HsiBf+XjqFlopsP4Y2X6hiZ+iHhSXELLyvrQostA0lbAzaoqRs93k6dX+BDRj5PUmcWosl9tTQFWwPc5GFymCsdX3GjHsup2lRCJHkTTOW7SDrLm8wXLTVu3wh3HxO4cRHznmqnFWFg9uj3tOcbBgBR6Ou8XDfx06RQSiHq3ykkCXSPA+JUxOvJdjnfPW+CAa6IOTbgOF0KJziV4Q43D2876vT/MlUheJvmJsLOY1iWdWatq4OfPxmiuJ3NdsW3TXReA/AZlzjMvsOW0JUlHqo7X0B4x8+ZR00mYg= Content-Type: multipart/alternative; boundary="_000_FRXPR01MB0710D9C908354A917443FE6D9CDF0FRXPR01MB0710DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e6933dd7-e5c9-44f7-06bb-08d715875bb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 07:18:59.8569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ruediger.Geib@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0776 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 07:19:10 -0000 --_000_FRXPR01MB0710D9C908354A917443FE6D9CDF0FRXPR01MB0710DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNvbnNlcnZhdGl2ZSBhcHByb2FjaCBpcyB0byBtYXJrIHRyYWZmaWMgYnkgdGhlIGRlZmF1 bHQgRFNDUCwgZXNwZWNpYWxseSBpZiB0aGVyZeKAmXMgbm8gUW9TIFNMQSBiZXR3ZWVuIGludGVy Y29ubmVjdGVkIHByb3ZpZGVycy4gSeKAmW0gbm90IHN1cmUgaG93IG1hbnkgbmV0d29ya3MgZHJv cCB0cmFmZmljIHdpdGggdW5rbm93biBEU0NQcy4gSWYgdGhlIHNvbHV0aW9uIHRvIHRoaXMgaXNz dWUgaXMgdG8gc2VuZCB0cmFmZmljIHdpdGggYSBzZXQgb2YgRFNDUHMgdG8gZmlndXJlIG91dCB3 aGF04oCZcyBwYXNzaW5nLCB0aGUgYXBwbGljYXRpb24gc2hvdWxkIGFsc28gYmUgYWJsZSB0byBk ZWFsIHdpdGggcmVtYXJrZWQgdHJhZmZpYyAod2hpY2ggSSBhc3N1bWUgdG8gYmUgYSBuZXR3b3Jr IGJlaGF2aW9yIHRvIGJlIGV4cGVjdGVkKS4NCg0KUmVnYXJkcywgUnVlZGlnZXINCg0KT24gVHVl LCBKdWwgMzAsIDIwMTkgYXQgMTE6MzIgUE0gR29ycnkgRmFpcmh1cnN0IDxnb3JyeUBlcmcuYWJk bi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PiB3cm90ZToNCk9uIDMxLzA3LzIw MTksIDA2OjEyLCBKdXN0aW4gVWJlcnRpIHdyb3RlOg0KPg0KPg0KPiBPbiBUdWUsIEp1bCAzMCwg MjAxOSBhdCAxMDoxMCBQTSBNYXR0aGV3IEthdWZtYW4NCj4gPG1rYXVmbWFuQGJsdWVqZWFucy5j b208bWFpbHRvOm1rYXVmbWFuQGJsdWVqZWFucy5jb20+IDxtYWlsdG86bWthdWZtYW5AYmx1ZWpl YW5zLmNvbTxtYWlsdG86bWthdWZtYW5AYmx1ZWplYW5zLmNvbT4+PiB3cm90ZToNCj4NCj4gICAg IEkgbm90ZWQgdHdvIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3TigKYgb25lIGlzIHRoZSDigJxuZXR3 b3JrIGVhdHMNCj4gICAgIERTQ1AtbWFya2VkIGJ1dCBhbGxvd3Mgbm9uLW1hcmtlZOKAnSBjYXNl LiBBcmd1bWVudHMgZ28gYm90aCB3YXlzIGFzDQo+ICAgICB0byB3aGF0IG9uZSBzaG91bGQgZG8g aW4gdGhpcyBjYXNlIChmb2xsb3cgbmV0d29yayBhZG1pbiBkZXNpcmVzDQo+ICAgICB2cy4gd29y ayBhcyBvZnRlbiBhcyBwb3NzaWJsZSkuDQo+DQo+DQpJcyB0aGF0IGEgcmVhbCBvYnNlcnZlZCBj YXNlIC0gdGhhdCBhbGwgdHJhZmZpYyB0aGF0IHNldHMgYSBzcGVjaWZpYw0KRFNDUCBpcyBsb3N0 LCByYXRoZXIgdGhhbiByZS1tYXJrZWQ/DQoNCi0gVGhlcmUncyBhbHNvIGFuIG9idmlvdXMgY2Fz ZSB3aGVyZSBhIHNwZWNpZmljIERTQ1AgaXMgY29uZGl0aW9uZWQNCihlLmcuIHJhdGUtbGltaXRl ZCksIHdoaWNoIG1lYW5zIHNvbWUgcGFja2V0cyB0cmF2ZXJzZSB0aGUgcGF0aCwgYnV0IGENCmZ1 bGwgbWVkaWEgZmxvdyB3aWxsIG5vdC4gSG93ZXZlciwgbm90IHN1cmUgdGhhdCBvYnNlcnZhdGlv biBoZWxwcyBhdCBhbGwuDQoNCkkgY2FuJ3Qgc3BlYWsgZm9yIG90aGVycywgYnV0IG91ciBleHBl cmllbmNlIHdpdGggZGVwbG95aW5nIERTQ1AgZW4gbWFzc2UgaXMgdGhhdCB0aGVyZSBhcmUgZW5v dWdoIGNhc2VzIHdoZXJlIGRyb3BwaW5nIGhhcHBlbnMgdG8gb3V0d2VpZ2ggdGhlIHByaW9yaXRp emF0aW9uIGJlbmVmaXRzLg0K --_000_FRXPR01MB0710D9C908354A917443FE6D9CDF0FRXPR01MB0710DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFn ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20g NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRoZSBjb25zZXJ2YXRpdmUgYXBwcm9hY2ggaXMgdG8gbWFyayB0cmFmZmlj IGJ5IHRoZSBkZWZhdWx0IERTQ1AsIGVzcGVjaWFsbHkgaWYgdGhlcmXigJlzIG5vIFFvUyBTTEEg YmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBwcm92aWRlcnMuIEnigJltIG5vdCBzdXJlIGhvdyBtYW55 IG5ldHdvcmtzIGRyb3AgdHJhZmZpYyB3aXRoIHVua25vd24gRFNDUHMuIElmIHRoZSBzb2x1dGlv biB0byB0aGlzDQogaXNzdWUgaXMgdG8gc2VuZCB0cmFmZmljIHdpdGggYSBzZXQgb2YgRFNDUHMg dG8gZmlndXJlIG91dCB3aGF04oCZcyBwYXNzaW5nLCB0aGUgYXBwbGljYXRpb24gc2hvdWxkIGFs c28gYmUgYWJsZSB0byBkZWFsIHdpdGggcmVtYXJrZWQgdHJhZmZpYyAod2hpY2ggSSBhc3N1bWUg dG8gYmUgYSBuZXR3b3JrIGJlaGF2aW9yIHRvIGJlIGV4cGVjdGVkKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlJlZ2FyZHMsIFJ1ZWRpZ2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKdWwgMzAsIDIwMTkg YXQgMTE6MzIgUE0gR29ycnkgRmFpcmh1cnN0ICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJn LmFiZG4uYWMudWsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzMS8w Ny8yMDE5LCAwNjoxMiwgSnVzdGluIFViZXJ0aSB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgT24gVHVlLCBKdWwgMzAsIDIwMTkgYXQgMTA6MTAgUE0gTWF0dGhldyBLYXVmbWFu IDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpta2F1Zm1hbkBibHVlamVhbnMuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWthdWZtYW5AYmx1ZWplYW5zLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86bWthdWZtYW5AYmx1ZWplYW5zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1rYXVm bWFuQGJsdWVqZWFucy5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO0kgbm90ZWQgdHdvIG9mIHBhcnRpY3VsYXIgaW50ZXJlc3TigKYg b25lIGlzIHRoZSDigJxuZXR3b3JrIGVhdHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtE U0NQLW1hcmtlZCBidXQgYWxsb3dzIG5vbi1tYXJrZWTigJ0gY2FzZS4gQXJndW1lbnRzIGdvIGJv dGggd2F5cyBhczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RvIHdoYXQgb25lIHNob3Vs ZCBkbyBpbiB0aGlzIGNhc2UgKGZvbGxvdyBuZXR3b3JrIGFkbWluIGRlc2lyZXM8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDt2cy4gd29yayBhcyBvZnRlbiBhcyBwb3NzaWJsZSkuPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQpJcyB0aGF0IGEgcmVhbCBvYnNlcnZlZCBjYXNlIC0gdGhhdCBh bGwgdHJhZmZpYyB0aGF0IHNldHMgYSBzcGVjaWZpYyA8YnI+DQpEU0NQIGlzIGxvc3QsIHJhdGhl ciB0aGFuIHJlLW1hcmtlZD88YnI+DQo8YnI+DQotIFRoZXJlJ3MgYWxzbyBhbiBvYnZpb3VzIGNh c2Ugd2hlcmUgYSBzcGVjaWZpYyBEU0NQIGlzIGNvbmRpdGlvbmVkIDxicj4NCihlLmcuIHJhdGUt bGltaXRlZCksIHdoaWNoIG1lYW5zIHNvbWUgcGFja2V0cyB0cmF2ZXJzZSB0aGUgcGF0aCwgYnV0 IGEgPGJyPg0KZnVsbCBtZWRpYSBmbG93IHdpbGwgbm90LiBIb3dldmVyLCBub3Qgc3VyZSB0aGF0 IG9ic2VydmF0aW9uIGhlbHBzIGF0IGFsbC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuJ3Qgc3BlYWsgZm9yIG90aGVycywg YnV0IG91ciBleHBlcmllbmNlIHdpdGggZGVwbG95aW5nIERTQ1AgZW4gbWFzc2UgaXMgdGhhdCB0 aGVyZSBhcmUgZW5vdWdoIGNhc2VzIHdoZXJlIGRyb3BwaW5nIGhhcHBlbnMgdG8gb3V0d2VpZ2gg dGhlIHByaW9yaXRpemF0aW9uIGJlbmVmaXRzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FRXPR01MB0710D9C908354A917443FE6D9CDF0FRXPR01MB0710DEUP_-- From nobody Wed Jul 31 02:22:06 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485CC120154; Wed, 31 Jul 2019 02:22:04 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 zreCda_aLRk0; Wed, 31 Jul 2019 02:22:01 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60074.outbound.protection.outlook.com [40.107.6.74]) (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 788DD120096; Wed, 31 Jul 2019 02:22:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EC0N5zKZEBEPEHce0O+xppOIfaw73SfYX/cah3eA47GmqDSu4scQD9jMOISZ2WZOHHdJnDlarPEQxAUbfKXCNAncprozqwgixCV0FBv3bZW3/RbpticUYMjOhfIM6EdQOgsrVtuxLLJBABNzwidLIbCrN4/iPLtSUPB1Hf0H1z4L07MWAGlqSlK67MnlZu6jwmXxXUwcPJSopKUpUgfh0G/1D5yojPW3BPAQ1i4065Pkk1KWP/TceH25Ex5IoGTiMJ9Fx1DAIDXwEjRLgsifuTL+ckmfOxGnYytwLorYdrphi78wvfTOsf1Wnf14A2AMBEWw8Bkzl1+Zwt6uprr4Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7XhssAMP1LzT5jM2pkMIqFKXwLsWSrmsR+5ZeFlGcNI=; b=CO/580sRc2sw2/OjIPL3kZE+zfo+C2JIuRtb4u9M/qNRdBkCDp9Qfiwyt+ed4E+ArlhwsmAgRXIzzYL+IUf+gd2k0zWGiUcnW77/dvl5xPaDvkYNs0O5OYycjixH59D/RZJWgU663S5PD/5qnSQYodAnKC1jaDkszxCLiMMAp84g18grie7OCEiOzgR+lRwzj1YI78bKw7kP498tYs8YHTvJ8FgBCun7pCIrdkuKYCAp2G4x57QFtnXYqERnhhlgove3EM4iglxSac0sw+PiPPDbA6dpE/N2tVu1uNNBk/aaPdEdMn38ty798LKtkdYTNKxWvPAUkqYtj3VuvJgckg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7XhssAMP1LzT5jM2pkMIqFKXwLsWSrmsR+5ZeFlGcNI=; b=OOPIFbK9syuXsxbrlc6p+n6o5ReJqGj8s9DfBDqiaQIycVrfmry+NhY5dvoMmE3S02a3FxMReYA8FlYexti9viQZxnFGNAwTXS0CzU2KlCPNZcDeAhh4keEcdbtCysqKdRU2sK2BbfjukLg80docZ3/MjOJ6+jffWEiSWSMq4fA= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4481.eurprd07.prod.outlook.com (52.135.151.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.11; Wed, 31 Jul 2019 09:21:58 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::118c:953f:8fb9:9e5]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::118c:953f:8fb9:9e5%5]) with mapi id 15.20.2136.010; Wed, 31 Jul 2019 09:21:58 +0000 From: Mirja Kuehlewind To: "Ruediger.Geib@telekom.de" , "juberti=40google.com@dmarc.ietf.org" CC: "rtcweb@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos Thread-Index: AQHVR15RiYmENo5dE0m0G61qgvCbHabkLnmAgAAWJYCAAAK1AIAACmGAgABD44A= Date: Wed, 31 Jul 2019 09:21:57 +0000 Message-ID: References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> <5D4135E9.90104@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [87.123.206.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1f61d657-a24b-41af-49c7-08d715988971 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:AM0PR07MB4481; x-ms-traffictypediagnostic: AM0PR07MB4481: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(346002)(396003)(39860400002)(199004)(189003)(5660300002)(4326008)(8936002)(66066001)(102836004)(6506007)(53546011)(76176011)(486006)(476003)(99286004)(236005)(71200400001)(86362001)(71190400001)(229853002)(256004)(68736007)(446003)(33656002)(6512007)(11346002)(316002)(186003)(26005)(54906003)(110136005)(2616005)(44832011)(66476007)(6246003)(6436002)(36756003)(14454004)(66946007)(66556008)(6116002)(6486002)(64756008)(7736002)(54896002)(76116006)(91956017)(2501003)(6306002)(66446008)(8676002)(2906002)(25786009)(81166006)(53936002)(81156014)(3846002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4481; H:AM0PR07MB4691.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: d2eL0JEppwXjwVFd8SpWaLssMzaahjjgLDJ48/kz7KYIaQYVPe/E98K7Si6zarCkw+9ZL9llI+3q/721Wm7OjgRT51HOLO0BTgjMMZea5Kop2nNO2Ce8igLHMwkU9RDOqykUeVvAaI3dHqwx/4TVollpTL2+/VeBeQpDk1xeW6ImFIWl2II5jZMF91QZYmlYW647SHejCcgFx42PdiG0bTYhAJBfXLQLGZnstRyX65UilHyrpIDeJovDhDdMTsDoAP19ScEtTLHskXSMMTjrHfsV517diqWFAzupa4SKzAk7Z3zFI4KKFqFUzzfPCM6vT0C+l3p0p2Cy/+dVgKHTBublqTfzvBh4WaqwjCC8stqUf79Ms2y9vz36pxhfYl1Er8x8rV3pgEWDoSxNrILU7WVbC+emFBQr+nZva3WRIVg= Content-Type: multipart/alternative; boundary="_000_A9A04BCC6588475991F4C25BEF163683ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f61d657-a24b-41af-49c7-08d715988971 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 09:21:58.0480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mirja.kuehlewind@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4481 Archived-At: Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 09:22:05 -0000 --_000_A9A04BCC6588475991F4C25BEF163683ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBpbiBtZWFzdXJlbWVudHMgd2UgdXN1YWxseSBzZWUgYmxlYWNoaW5nIChub3QgZHJvcHBp bmcpLiBTbyBpdCBzaG91bGQgYmUgdGVzdGVkIHdpdGggdGhlIERTQ1AgdGhhdCBpcyBzdXBwb3Nl ZCB0byBiZSB1c2VkIGZvciB0aGUgd2VicnRjIHRyYWZmaWMgYW5kIG9ubHkgdGVzdGVkIHdpdGhv dXQgRFNDUCBpZiBjb25uZWN0aXZpdHkgZm9yIHRoZSBjYXNlIHdpdGggRFNDUCB3YXMgbm90IHN1 Y2Nlc3NmdWwuDQoNClRoZSBjYXNlIEdvcnJ5IG1lbnRpb25lZCwgd2hlcmUgc29tZSBEU0NQIGFy ZSByYXRlLWxpbWl0ZWQsIGlzIGEgcHJvYmxlbSBidXQgaXTigJlzIG5vdCBJQ0XigJlzIHByb2Js ZW0gKHdoZXJlIHRoZSBDIHN0YW5kcyBmb3IgQ29ubmVjdGl2aXR5KS4NCg0KTWlyamENCg0KDQoN CkZyb206IHRzdndnIDx0c3Z3Zy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIlJ1ZWRp Z2VyLkdlaWJAdGVsZWtvbS5kZSIgPFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZT4NCkRhdGU6IFdl ZG5lc2RheSwgMzEuIEp1bHkgMjAxOSBhdCAwOToxOQ0KVG86ICJqdWJlcnRpPTQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZyIgPGp1YmVydGk9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0K Q2M6ICJydGN3ZWJAaWV0Zi5vcmciIDxydGN3ZWJAaWV0Zi5vcmc+LCAidHN2d2dAaWV0Zi5vcmci IDx0c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIFtydGN3ZWJdIFNUVU4gRFND UCBhbmQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zDQoNClRoZSBjb25zZXJ2YXRpdmUgYXBw cm9hY2ggaXMgdG8gbWFyayB0cmFmZmljIGJ5IHRoZSBkZWZhdWx0IERTQ1AsIGVzcGVjaWFsbHkg aWYgdGhlcmXigJlzIG5vIFFvUyBTTEEgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBwcm92aWRlcnMu IEnigJltIG5vdCBzdXJlIGhvdyBtYW55IG5ldHdvcmtzIGRyb3AgdHJhZmZpYyB3aXRoIHVua25v d24gRFNDUHMuIElmIHRoZSBzb2x1dGlvbiB0byB0aGlzIGlzc3VlIGlzIHRvIHNlbmQgdHJhZmZp YyB3aXRoIGEgc2V0IG9mIERTQ1BzIHRvIGZpZ3VyZSBvdXQgd2hhdOKAmXMgcGFzc2luZywgdGhl IGFwcGxpY2F0aW9uIHNob3VsZCBhbHNvIGJlIGFibGUgdG8gZGVhbCB3aXRoIHJlbWFya2VkIHRy YWZmaWMgKHdoaWNoIEkgYXNzdW1lIHRvIGJlIGEgbmV0d29yayBiZWhhdmlvciB0byBiZSBleHBl Y3RlZCkuDQoNClJlZ2FyZHMsIFJ1ZWRpZ2VyDQoNCk9uIFR1ZSwgSnVsIDMwLCAyMDE5IGF0IDEx OjMyIFBNIEdvcnJ5IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5 QGVyZy5hYmRuLmFjLnVrPj4gd3JvdGU6DQpPbiAzMS8wNy8yMDE5LCAwNjoxMiwgSnVzdGluIFVi ZXJ0aSB3cm90ZToNCj4NCj4NCj4gT24gVHVlLCBKdWwgMzAsIDIwMTkgYXQgMTA6MTAgUE0gTWF0 dGhldyBLYXVmbWFuDQo+IDxta2F1Zm1hbkBibHVlamVhbnMuY29tPG1haWx0bzpta2F1Zm1hbkBi bHVlamVhbnMuY29tPiA8bWFpbHRvOm1rYXVmbWFuQGJsdWVqZWFucy5jb208bWFpbHRvOm1rYXVm bWFuQGJsdWVqZWFucy5jb20+Pj4gd3JvdGU6DQo+DQo+ICAgICBJIG5vdGVkIHR3byBvZiBwYXJ0 aWN1bGFyIGludGVyZXN04oCmIG9uZSBpcyB0aGUg4oCcbmV0d29yayBlYXRzDQo+ICAgICBEU0NQ LW1hcmtlZCBidXQgYWxsb3dzIG5vbi1tYXJrZWTigJ0gY2FzZS4gQXJndW1lbnRzIGdvIGJvdGgg d2F5cyBhcw0KPiAgICAgdG8gd2hhdCBvbmUgc2hvdWxkIGRvIGluIHRoaXMgY2FzZSAoZm9sbG93 IG5ldHdvcmsgYWRtaW4gZGVzaXJlcw0KPiAgICAgdnMuIHdvcmsgYXMgb2Z0ZW4gYXMgcG9zc2li bGUpLg0KPg0KPg0KSXMgdGhhdCBhIHJlYWwgb2JzZXJ2ZWQgY2FzZSAtIHRoYXQgYWxsIHRyYWZm aWMgdGhhdCBzZXRzIGEgc3BlY2lmaWMNCkRTQ1AgaXMgbG9zdCwgcmF0aGVyIHRoYW4gcmUtbWFy a2VkPw0KDQotIFRoZXJlJ3MgYWxzbyBhbiBvYnZpb3VzIGNhc2Ugd2hlcmUgYSBzcGVjaWZpYyBE U0NQIGlzIGNvbmRpdGlvbmVkDQooZS5nLiByYXRlLWxpbWl0ZWQpLCB3aGljaCBtZWFucyBzb21l IHBhY2tldHMgdHJhdmVyc2UgdGhlIHBhdGgsIGJ1dCBhDQpmdWxsIG1lZGlhIGZsb3cgd2lsbCBu b3QuIEhvd2V2ZXIsIG5vdCBzdXJlIHRoYXQgb2JzZXJ2YXRpb24gaGVscHMgYXQgYWxsLg0KDQpJ IGNhbid0IHNwZWFrIGZvciBvdGhlcnMsIGJ1dCBvdXIgZXhwZXJpZW5jZSB3aXRoIGRlcGxveWlu ZyBEU0NQIGVuIG1hc3NlIGlzIHRoYXQgdGhlcmUgYXJlIGVub3VnaCBjYXNlcyB3aGVyZSBkcm9w cGluZyBoYXBwZW5zIHRvIG91dHdlaWdoIHRoZSBwcmlvcml0aXphdGlvbiBiZW5lZml0cy4NCg== --_000_A9A04BCC6588475991F4C25BEF163683ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1 cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+WWVzLCBpbiBtZWFzdXJlbWVudHMgd2UgdXN1YWxseSBzZWUgYmxlYWNoaW5nIChub3QgZHJv cHBpbmcpLiBTbyBpdCBzaG91bGQgYmUgdGVzdGVkIHdpdGggdGhlIERTQ1AgdGhhdCBpcyBzdXBw b3NlZCB0byBiZSB1c2VkIGZvciB0aGUgd2VicnRjIHRyYWZmaWMgYW5kIG9ubHkgdGVzdGVkIHdp dGhvdXQgRFNDUCBpZg0KIGNvbm5lY3Rpdml0eSBmb3IgdGhlIGNhc2Ugd2l0aCBEU0NQIHdhcyBu b3Qgc3VjY2Vzc2Z1bC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGNhc2Ug R29ycnkgbWVudGlvbmVkLCB3aGVyZSBzb21lIERTQ1AgYXJlIHJhdGUtbGltaXRlZCwgaXMgYSBw cm9ibGVtIGJ1dCBpdOKAmXMgbm90IElDReKAmXMgcHJvYmxlbSAod2hlcmUgdGhlIEMgc3RhbmRz IGZvciBDb25uZWN0aXZpdHkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk1pcmph PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj50c3Z3ZyAmbHQ7dHN2d2ctYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m ICZxdW90O1J1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSZxdW90OyAmbHQ7UnVlZGlnZXIuR2VpYkB0 ZWxla29tLmRlJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIDMxLiBKdWx5IDIwMTkg YXQgMDk6MTk8YnI+DQo8Yj5UbzogPC9iPiZxdW90O2p1YmVydGk9NDBnb29nbGUuY29tQGRtYXJj LmlldGYub3JnJnF1b3Q7ICZsdDtqdWJlcnRpPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyZn dDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3J0Y3dlYkBpZXRmLm9yZyZxdW90OyAmbHQ7cnRjd2Vi QGlldGYub3JnJmd0OywgJnF1b3Q7dHN2d2dAaWV0Zi5vcmcmcXVvdDsgJmx0O3RzdndnQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3RzdndnXSBbcnRjd2ViXSBTVFVOIERT Q1AgYW5kIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo ZSBjb25zZXJ2YXRpdmUgYXBwcm9hY2ggaXMgdG8gbWFyayB0cmFmZmljIGJ5IHRoZSBkZWZhdWx0 IERTQ1AsIGVzcGVjaWFsbHkgaWYgdGhlcmXigJlzIG5vIFFvUyBTTEEgYmV0d2VlbiBpbnRlcmNv bm5lY3RlZCBwcm92aWRlcnMuIEnigJltIG5vdCBzdXJlIGhvdyBtYW55IG5ldHdvcmtzIGRyb3Ag dHJhZmZpYyB3aXRoIHVua25vd24NCiBEU0NQcy4gSWYgdGhlIHNvbHV0aW9uIHRvIHRoaXMgaXNz dWUgaXMgdG8gc2VuZCB0cmFmZmljIHdpdGggYSBzZXQgb2YgRFNDUHMgdG8gZmlndXJlIG91dCB3 aGF04oCZcyBwYXNzaW5nLCB0aGUgYXBwbGljYXRpb24gc2hvdWxkIGFsc28gYmUgYWJsZSB0byBk ZWFsIHdpdGggcmVtYXJrZWQgdHJhZmZpYyAod2hpY2ggSSBhc3N1bWUgdG8gYmUgYSBuZXR3b3Jr IGJlaGF2aW9yIHRvIGJlIGV4cGVjdGVkKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsIFJ1ZWRp Z2VyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBKdWwgMzAsIDIwMTkgYXQgMTE6MzIgUE0gR29ycnkgRmFp cmh1cnN0ICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVy Zy5hYmRuLmFjLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMzEvMDcvMjAxOSwgMDY6MTIs IEp1c3RpbiBVYmVydGkgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFR1 ZSwgSnVsIDMwLCAyMDE5IGF0IDEwOjEwIFBNIE1hdHRoZXcgS2F1Zm1hbiA8YnI+DQomZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86bWthdWZtYW5AYmx1ZWplYW5zLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1rYXVmbWFuQGJsdWVqZWFucy5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1r YXVmbWFuQGJsdWVqZWFucy5jb20iIHRhcmdldD0iX2JsYW5rIj5ta2F1Zm1hbkBibHVlamVhbnMu Y29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtJIG5vdGVkIHR3byBvZiBwYXJ0aWN1bGFyIGludGVyZXN04oCmIG9uZSBpcyB0aGUg4oCc bmV0d29yayBlYXRzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7RFNDUC1tYXJrZWQgYnV0 IGFsbG93cyBub24tbWFya2Vk4oCdIGNhc2UuIEFyZ3VtZW50cyBnbyBib3RoIHdheXMgYXM8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0byB3aGF0IG9uZSBzaG91bGQgZG8gaW4gdGhpcyBj YXNlIChmb2xsb3cgbmV0d29yayBhZG1pbiBkZXNpcmVzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7dnMuIHdvcmsgYXMgb2Z0ZW4gYXMgcG9zc2libGUpLjxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KSXMgdGhhdCBhIHJlYWwgb2JzZXJ2ZWQgY2FzZSAtIHRoYXQgYWxsIHRyYWZmaWMgdGhh dCBzZXRzIGEgc3BlY2lmaWMgPGJyPg0KRFNDUCBpcyBsb3N0LCByYXRoZXIgdGhhbiByZS1tYXJr ZWQ/PGJyPg0KPGJyPg0KLSBUaGVyZSdzIGFsc28gYW4gb2J2aW91cyBjYXNlIHdoZXJlIGEgc3Bl Y2lmaWMgRFNDUCBpcyBjb25kaXRpb25lZCA8YnI+DQooZS5nLiByYXRlLWxpbWl0ZWQpLCB3aGlj aCBtZWFucyBzb21lIHBhY2tldHMgdHJhdmVyc2UgdGhlIHBhdGgsIGJ1dCBhIDxicj4NCmZ1bGwg bWVkaWEgZmxvdyB3aWxsIG5vdC4gSG93ZXZlciwgbm90IHN1cmUgdGhhdCBvYnNlcnZhdGlvbiBo ZWxwcyBhdCBhbGwuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5JIGNhbid0IHNwZWFrIGZvciBvdGhlcnMsIGJ1dCBvdXIgZXhwZXJpZW5j ZSB3aXRoIGRlcGxveWluZyBEU0NQIGVuIG1hc3NlIGlzIHRoYXQgdGhlcmUgYXJlIGVub3VnaCBj YXNlcyB3aGVyZSBkcm9wcGluZyBoYXBwZW5zIHRvIG91dHdlaWdoIHRoZSBwcmlvcml0aXphdGlv biBiZW5lZml0cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A9A04BCC6588475991F4C25BEF163683ericssoncom_-- From nobody Wed Jul 31 06:37:02 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B642120020; Wed, 31 Jul 2019 06:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=H/0jAPr0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=n1muHp2Q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1yIH6WXsf_x; Wed, 31 Jul 2019 06:36:57 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 8F13F12004F; Wed, 31 Jul 2019 06:36:57 -0700 (PDT) Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6VDYRN3011479; Wed, 31 Jul 2019 09:36:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=y8HFYqnDh6n+EfDnU9rISgEBiAJri2wvF00I9aVdZ+Q=; b=H/0jAPr0HzsC8xBoRSuBS7bqfSKli3Rp7i//lOFcAEMSi87aAvR3vsJUKv0Gb35StyKL OGuGIzQyZjKGkcmKkHmD+wTK8Kk8f193xPZHbv3rOQySMAWV7IXJToDwLGyw1pDL5oLD zoWIISTtgoo/OVRxnjvm94B3/uDO28Qr1EbcIpnbgvRRqE9AFzaI/Wb7xQjCVBm3buFZ jiESqlKqWGVApwF/CXxkWdbREr1d+39zXXobJ3KTgajR1H6pPD6+0yamvSsnNWfqjtYL LACILkSllxXucd+XaqExiLmRzOuo7/Kw3uu0DmCRtoljayDet5zsunJQ0keXr9I6tM+T gA== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2u2h6bptdw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 09:36:51 -0400 Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6VDY1KS120741; Wed, 31 Jul 2019 09:36:51 -0400 Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by mx0b-00154901.pphosted.com with ESMTP id 2u3bqrgb1e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 31 Jul 2019 09:36:51 -0400 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6VDZ1ZJ032383 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Jul 2019 09:36:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com x6VDZ1ZJ032383 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1564580210; bh=XF2og1ij2zXDvT7uWn5wHY/nHMk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=n1muHp2QkWkHZEBKlbj1QkwKny2XjInidmivipUkpeWMNfbKOjKBO4D6wk4x6ZWrg mzNuRVYH14JtlK6hnPY9BdtZZGheW0jofqluujwwgzhd6ouoMdjybkkvD2RWecSHwk /sbNWlTs2e8NdY8ULjr08ycG+fMdpTsFHL03mKdM= Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 31 Jul 2019 09:34:24 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x6VDYNj1002968 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 31 Jul 2019 09:34:24 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0439.000; Wed, 31 Jul 2019 09:34:23 -0400 From: "Black, David" To: Mirja Kuehlewind , "Ruediger.Geib@telekom.de" , "juberti=40google.com@dmarc.ietf.org" CC: "rtcweb@ietf.org" , "tsvwg@ietf.org" , "Black, David" Thread-Topic: [tsvwg] [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos Thread-Index: AQHVR15PWUhrNuoNEk6cZW57DKHA7abkcYeAgAAWJoCAAAK0AIAACmGAgAAiXICAAABlQA== Date: Wed, 31 Jul 2019 13:34:23 +0000 Message-ID: References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> <5D4135E9.90104@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-07-31T13:23:25.7535014Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [10.238.21.131] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949363064A398MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public, GIS Solicitation X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-31_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907310140 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907310140 Archived-At: Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 13:37:00 -0000 --_000_CE03DB3D7B45C245BCA0D243277949363064A398MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gTWlyamHigJlzIHJlbWFya3MuICBUaGVyZSBhcmUgRFNDUC1zZW5zaXRpdmUgcm91dGlu ZyB0ZWNobm9sb2dpZXMsIGFuZCBEZXROZXQgKERldGVybWluaXN0aWMgTmV0d29ya2luZykgd2ls bCB1c2UgdGhlIERTQ1AgYXMgcGFydCBvZiBzZWxlY3RpbmcgdGhlIGRhdGEgcGxhbmUgYXQgRGV0 TmV0IG5ldHdvcmsgbm9kZXMsIHNvIHVzZSBvZiB0aGUgc2FtZSBEU0NQIGFzIHRoZSB0cmFmZmlj IHRvIGJlIHNlbnQgaGVscHMgZW5zdXJlIHRoYXQgdGhlIGVzdGFibGlzaGVkIGNvbm5lY3Rpdml0 eSBhY3R1YWxseSB3b3JrcyBmb3IgdGhlIHRyYWZmaWMgdG8gYmUgc2VudCDigKYgd2hpY2ggaXMg YXQgbGVhc3QgY29udmVuaWVudCA7LSkuDQoNCk5leHQgY29uY2VybiDigJMgd2hpY2ggRFNDUHM/ ICBUaGVyZSBhcmUgYSBsb3Qgb2YgRFNDUHMgbGlzdGVkIGluIGRyYWZ0LWlldGYtdHN2d2ctcnRj d2ViLXFvcy4gIFN1Z2dlc3RlZCBhbGdvcml0aG0gdG8gc2VsZWN0IGluaXRpYWwgRFNDUDoNCg0K ICAxLiAgcGljayBoaWdoZXN0IHJvdyBpbiB0YWJsZSB0aGF0IHdpbGwgYmUgdXNlZCBpbiB0aGUg V2ViUlRDIHNlc3Npb24gKGUuZy4sIHNlbGVjdCBJbnRlcmFjdGl2ZSBWaWRlbyBvdmVyIE5vbi1J bnRlcmFjdGl2ZSBWaWRlbyk7DQogIDIuICBzZWxlY3QgcmlnaHRtb3N0IGNlbGwgaW4gdGhhdCBy b3cgdGhhdCB3aWxsIGJlIHVzZWQgKGUuZy4sIHNlbGVjdCBIaWdoIG92ZXIgTWVkaXVtKTsgYW5k DQogIDMuICBpZiB0aGF0IGNlbGwgY29udGFpbnMgdHdvIEFGIERTQ1BzLCB1c2UgdGhlIG9uZSB3 aXRoIHRoZSBiZXR0ZXIgZHJvcCBwcmVjZWRlbmNlIChlLmcuLCBzZWxlY3QgQUY0MSBvdmVyIEFG NDIpLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KRnJvbTogdHN2d2cgPHRzdndnLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaXJqYSBLdWVobGV3aW5kDQpTZW50OiBXZWRuZXNkYXksIEp1 bHkgMzEsIDIwMTkgNToyMiBBTQ0KVG86IFJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZTsganViZXJ0 aT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcNCkNjOiBydGN3ZWJAaWV0Zi5vcmc7IHRzdndn QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RzdndnXSBbcnRjd2ViXSBTVFVOIERTQ1AgYW5kIGRy YWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcw0KDQoNCltFWFRFUk5BTCBFTUFJTF0NClllcywgaW4g bWVhc3VyZW1lbnRzIHdlIHVzdWFsbHkgc2VlIGJsZWFjaGluZyAobm90IGRyb3BwaW5nKS4gU28g aXQgc2hvdWxkIGJlIHRlc3RlZCB3aXRoIHRoZSBEU0NQIHRoYXQgaXMgc3VwcG9zZWQgdG8gYmUg dXNlZCBmb3IgdGhlIHdlYnJ0YyB0cmFmZmljIGFuZCBvbmx5IHRlc3RlZCB3aXRob3V0IERTQ1Ag aWYgY29ubmVjdGl2aXR5IGZvciB0aGUgY2FzZSB3aXRoIERTQ1Agd2FzIG5vdCBzdWNjZXNzZnVs Lg0KDQpUaGUgY2FzZSBHb3JyeSBtZW50aW9uZWQsIHdoZXJlIHNvbWUgRFNDUCBhcmUgcmF0ZS1s aW1pdGVkLCBpcyBhIHByb2JsZW0gYnV0IGl04oCZcyBub3QgSUNF4oCZcyBwcm9ibGVtICh3aGVy ZSB0aGUgQyBzdGFuZHMgZm9yIENvbm5lY3Rpdml0eSkuDQoNCk1pcmphDQoNCg0KDQpGcm9tOiB0 c3Z3ZyA8dHN2d2ctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiAiUnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVkaWdl ci5HZWliQHRlbGVrb20uZGU+IiA8UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPG1haWx0bzpSdWVk aWdlci5HZWliQHRlbGVrb20uZGU+Pg0KRGF0ZTogV2VkbmVzZGF5LCAzMS4gSnVseSAyMDE5IGF0 IDA5OjE5DQpUbzogImp1YmVydGk9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpq dWJlcnRpPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4iIDxqdWJlcnRpPTQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86anViZXJ0aT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5v cmc+Pg0KQ2M6ICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4iIDxydGN3 ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+LCAidHN2d2dAaWV0Zi5vcmc8bWFp bHRvOnRzdndnQGlldGYub3JnPiIgPHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBbcnRjd2ViXSBTVFVOIERTQ1AgYW5kIGRyYWZ0LWll dGYtdHN2d2ctcnRjd2ViLXFvcw0KDQpUaGUgY29uc2VydmF0aXZlIGFwcHJvYWNoIGlzIHRvIG1h cmsgdHJhZmZpYyBieSB0aGUgZGVmYXVsdCBEU0NQLCBlc3BlY2lhbGx5IGlmIHRoZXJl4oCZcyBu byBRb1MgU0xBIGJldHdlZW4gaW50ZXJjb25uZWN0ZWQgcHJvdmlkZXJzLiBJ4oCZbSBub3Qgc3Vy ZSBob3cgbWFueSBuZXR3b3JrcyBkcm9wIHRyYWZmaWMgd2l0aCB1bmtub3duIERTQ1BzLiBJZiB0 aGUgc29sdXRpb24gdG8gdGhpcyBpc3N1ZSBpcyB0byBzZW5kIHRyYWZmaWMgd2l0aCBhIHNldCBv ZiBEU0NQcyB0byBmaWd1cmUgb3V0IHdoYXTigJlzIHBhc3NpbmcsIHRoZSBhcHBsaWNhdGlvbiBz aG91bGQgYWxzbyBiZSBhYmxlIHRvIGRlYWwgd2l0aCByZW1hcmtlZCB0cmFmZmljICh3aGljaCBJ IGFzc3VtZSB0byBiZSBhIG5ldHdvcmsgYmVoYXZpb3IgdG8gYmUgZXhwZWN0ZWQpLg0KDQpSZWdh cmRzLCBSdWVkaWdlcg0KDQpPbiBUdWUsIEp1bCAzMCwgMjAxOSBhdCAxMTozMiBQTSBHb3JyeSBG YWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51 az4+IHdyb3RlOg0KT24gMzEvMDcvMjAxOSwgMDY6MTIsIEp1c3RpbiBVYmVydGkgd3JvdGU6DQo+ DQo+DQo+IE9uIFR1ZSwgSnVsIDMwLCAyMDE5IGF0IDEwOjEwIFBNIE1hdHRoZXcgS2F1Zm1hbg0K PiA8bWthdWZtYW5AYmx1ZWplYW5zLmNvbTxtYWlsdG86bWthdWZtYW5AYmx1ZWplYW5zLmNvbT4g PG1haWx0bzpta2F1Zm1hbkBibHVlamVhbnMuY29tPG1haWx0bzpta2F1Zm1hbkBibHVlamVhbnMu Y29tPj4+IHdyb3RlOg0KPg0KPiAgICAgSSBub3RlZCB0d28gb2YgcGFydGljdWxhciBpbnRlcmVz dOKApiBvbmUgaXMgdGhlIOKAnG5ldHdvcmsgZWF0cw0KPiAgICAgRFNDUC1tYXJrZWQgYnV0IGFs bG93cyBub24tbWFya2Vk4oCdIGNhc2UuIEFyZ3VtZW50cyBnbyBib3RoIHdheXMgYXMNCj4gICAg IHRvIHdoYXQgb25lIHNob3VsZCBkbyBpbiB0aGlzIGNhc2UgKGZvbGxvdyBuZXR3b3JrIGFkbWlu IGRlc2lyZXMNCj4gICAgIHZzLiB3b3JrIGFzIG9mdGVuIGFzIHBvc3NpYmxlKS4NCj4NCj4NCklz IHRoYXQgYSByZWFsIG9ic2VydmVkIGNhc2UgLSB0aGF0IGFsbCB0cmFmZmljIHRoYXQgc2V0cyBh IHNwZWNpZmljDQpEU0NQIGlzIGxvc3QsIHJhdGhlciB0aGFuIHJlLW1hcmtlZD8NCg0KLSBUaGVy ZSdzIGFsc28gYW4gb2J2aW91cyBjYXNlIHdoZXJlIGEgc3BlY2lmaWMgRFNDUCBpcyBjb25kaXRp b25lZA0KKGUuZy4gcmF0ZS1saW1pdGVkKSwgd2hpY2ggbWVhbnMgc29tZSBwYWNrZXRzIHRyYXZl cnNlIHRoZSBwYXRoLCBidXQgYQ0KZnVsbCBtZWRpYSBmbG93IHdpbGwgbm90LiBIb3dldmVyLCBu b3Qgc3VyZSB0aGF0IG9ic2VydmF0aW9uIGhlbHBzIGF0IGFsbC4NCg0KSSBjYW4ndCBzcGVhayBm b3Igb3RoZXJzLCBidXQgb3VyIGV4cGVyaWVuY2Ugd2l0aCBkZXBsb3lpbmcgRFNDUCBlbiBtYXNz ZSBpcyB0aGF0IHRoZXJlIGFyZSBlbm91Z2ggY2FzZXMgd2hlcmUgZHJvcHBpbmcgaGFwcGVucyB0 byBvdXR3ZWlnaCB0aGUgcHJpb3JpdGl6YXRpb24gYmVuZWZpdHMuDQo= --_000_CE03DB3D7B45C245BCA0D243277949363064A398MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVt YWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojOTkzMzY2Ow0KCWZvbnQtd2VpZ2h0Om5v cm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjo3MC44NXB0IDcwLjg1cHQgNTYuN3B0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo4NDAyNjgyNDk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE4MjIzMTg4OTggNjk0NzM5NjY4IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ64oCTOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoy MC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTYuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6OTIuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMjguMjVwdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MTY0LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIwMC4y NXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIzNi4yNXB0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoyNzIuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzA4LjI1cHQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDoxMzEzNTU4OTg5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMzc5NTQ1MTg4IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBs aXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjM4LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NzQuMjVw dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJbWFyZ2luLWxlZnQ6MTEwLjI1cHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MTQ2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTgyLjI1 cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjIxOC4yNXB0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjI1NC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI5MC4y NXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDozMjYuMjVwdDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij4mIzQzOzEgb24gTWly amHigJlzIHJlbWFya3MuJm5ic3A7IFRoZXJlIGFyZSBEU0NQLXNlbnNpdGl2ZSByb3V0aW5nIHRl Y2hub2xvZ2llcywgYW5kIERldE5ldCAoRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nKSB3aWxsIHVz ZSB0aGUgRFNDUCBhcyBwYXJ0IG9mIHNlbGVjdGluZyB0aGUgZGF0YSBwbGFuZSBhdCBEZXROZXQg bmV0d29yayBub2Rlcywgc28gdXNlIG9mIHRoZSBzYW1lIERTQ1ANCiBhcyB0aGUgdHJhZmZpYyB0 byBiZSBzZW50IGhlbHBzIGVuc3VyZSB0aGF0IHRoZSBlc3RhYmxpc2hlZCBjb25uZWN0aXZpdHkg YWN0dWFsbHkgd29ya3MgZm9yIHRoZSB0cmFmZmljIHRvIGJlIHNlbnQg4oCmIHdoaWNoIGlzIGF0 IGxlYXN0IGNvbnZlbmllbnQgOy0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkzMzY2Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2 NiI+TmV4dCBjb25jZXJuIOKAkyB3aGljaCBEU0NQcz8mbmJzcDsgVGhlcmUgYXJlIGEgbG90IG9m IERTQ1BzIGxpc3RlZCBpbiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MuJm5ic3A7IFN1Z2dl c3RlZCBhbGdvcml0aG0gdG8gc2VsZWN0IGluaXRpYWwgRFNDUDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjojOTkzMzY2O21hcmdpbi1sZWZ0 OjIuMjVwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpwaWNrIGhpZ2hlc3Qgcm93IGluIHRh YmxlIHRoYXQgd2lsbCBiZSB1c2VkIGluIHRoZSBXZWJSVEMgc2Vzc2lvbiAoZS5nLiwgc2VsZWN0 IEludGVyYWN0aXZlIFZpZGVvIG92ZXIgTm9uLUludGVyYWN0aXZlIFZpZGVvKTs8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6Izk5MzM2Njtt YXJnaW4tbGVmdDoyLjI1cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0Kc2VsZWN0IHJpZ2h0 bW9zdCBjZWxsIGluIHRoYXQgcm93IHRoYXQgd2lsbCBiZSB1c2VkIChlLmcuLCBzZWxlY3QgSGln aCBvdmVyIE1lZGl1bSk7IGFuZDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJjb2xvcjojOTkzMzY2O21hcmdpbi1sZWZ0OjIuMjVwdDttc28tbGlzdDps MSBsZXZlbDEgbGZvMSI+DQppZiB0aGF0IGNlbGwgY29udGFpbnMgdHdvIEFGIERTQ1BzLCB1c2Ug dGhlIG9uZSB3aXRoIHRoZSBiZXR0ZXIgZHJvcCBwcmVjZWRlbmNlIChlLmcuLCBzZWxlY3QgQUY0 MSBvdmVyIEFGNDIpLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM5OTMzNjYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+ VGhhbmtzLCAtLURhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MzM2NiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gdHN2d2cgJmx0 O3RzdndnLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpNaXJqYSBL dWVobGV3aW5kPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAzMSwgMjAxOSA1OjIy IEFNPGJyPg0KPGI+VG86PC9iPiBSdWVkaWdlci5HZWliQHRlbGVrb20uZGU7IGp1YmVydGk9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJAaWV0Zi5vcmc7 IHRzdndnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIFtydGN3ZWJd IFNUVU4gRFNDUCBhbmQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJjb2xvcjojQ0UxMTI2Ij5bRVhU RVJOQUwgRU1BSUxdIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WWVzLCBpbiBtZWFzdXJlbWVudHMgd2UgdXN1YWxseSBzZWUgYmxlYWNoaW5nIChu b3QgZHJvcHBpbmcpLiBTbyBpdCBzaG91bGQgYmUgdGVzdGVkIHdpdGggdGhlIERTQ1AgdGhhdCBp cyBzdXBwb3NlZCB0byBiZSB1c2VkIGZvciB0aGUgd2VicnRjIHRyYWZmaWMgYW5kIG9ubHkgdGVz dGVkIHdpdGhvdXQgRFNDUCBpZiBjb25uZWN0aXZpdHkgZm9yIHRoZSBjYXNlIHdpdGggRFNDUCB3 YXMgbm90IHN1Y2Nlc3NmdWwuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNhc2UgR29y cnkgbWVudGlvbmVkLCB3aGVyZSBzb21lIERTQ1AgYXJlIHJhdGUtbGltaXRlZCwgaXMgYSBwcm9i bGVtIGJ1dCBpdOKAmXMgbm90IElDReKAmXMgcHJvYmxlbSAod2hlcmUgdGhlIEMgc3RhbmRzIGZv ciBDb25uZWN0aXZpdHkpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaXJqYTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIGxhbmc9IkRF IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iREUiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj50c3Z3 ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmciPnRzdndnLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOlJ1 ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSI+UnVlZGlnZXIuR2VpYkB0ZWxla29tLmRlPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOlJ1ZWRpZ2VyLkdlaWJAdGVsZWtvbS5kZSI+UnVlZGlnZXIu R2VpYkB0ZWxla29tLmRlPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCAzMS4g SnVseSAyMDE5IGF0IDA5OjE5PGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 anViZXJ0aT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciPmp1YmVydGk9NDBnb29nbGUuY29t QGRtYXJjLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGk9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnIj5qdWJlcnRpPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOnRzdndnQGlldGYub3JnIj50c3Z3Z0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+dHN2d2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW3RzdndnXSBbcnRjd2ViXSBTVFVOIERTQ1AgYW5kIGRyYWZ0LWll dGYtdHN2d2ctcnRjd2ViLXFvczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5n PSJERSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBjb25zZXJ2YXRpdmUg YXBwcm9hY2ggaXMgdG8gbWFyayB0cmFmZmljIGJ5IHRoZSBkZWZhdWx0IERTQ1AsIGVzcGVjaWFs bHkgaWYgdGhlcmXigJlzIG5vIFFvUyBTTEEgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBwcm92aWRl cnMuIEnigJltIG5vdCBzdXJlIGhvdyBtYW55IG5ldHdvcmtzIGRyb3AgdHJhZmZpYyB3aXRoIHVu a25vd24gRFNDUHMuIElmIHRoZSBzb2x1dGlvbg0KIHRvIHRoaXMgaXNzdWUgaXMgdG8gc2VuZCB0 cmFmZmljIHdpdGggYSBzZXQgb2YgRFNDUHMgdG8gZmlndXJlIG91dCB3aGF04oCZcyBwYXNzaW5n LCB0aGUgYXBwbGljYXRpb24gc2hvdWxkIGFsc28gYmUgYWJsZSB0byBkZWFsIHdpdGggcmVtYXJr ZWQgdHJhZmZpYyAod2hpY2ggSSBhc3N1bWUgdG8gYmUgYSBuZXR3b3JrIGJlaGF2aW9yIHRvIGJl IGV4cGVjdGVkKS48c3BhbiBsYW5nPSJERSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxzcGFuIGxhbmc9 IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+UmVnYXJkcywgUnVlZGlnZXI8c3BhbiBsYW5nPSJERSI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPiZuYnNwOzxzcGFuIGxhbmc9IkRFIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBsYW5nPSJERSI+T24gVHVlLCBKdWwgMzAsIDIwMTkgYXQgMTE6MzIgUE0gR29ycnkgRmFp cmh1cnN0ICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVy Zy5hYmRuLmFjLnVrPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBsYW5nPSJERSI+ T24gMzEvMDcvMjAxOSwgMDY6MTIsIEp1c3RpbiBVYmVydGkgd3JvdGU6PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFR1ZSwgSnVsIDMwLCAyMDE5IGF0IDEwOjEwIFBNIE1hdHRoZXcg S2F1Zm1hbiA8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bWthdWZtYW5AYmx1ZWplYW5z LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1rYXVmbWFuQGJsdWVqZWFucy5jb208L2E+ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOm1rYXVmbWFuQGJsdWVqZWFucy5jb20iIHRhcmdldD0iX2JsYW5r Ij5ta2F1Zm1hbkBibHVlamVhbnMuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJIG5vdGVkIHR3byBvZiBwYXJ0aWN1bGFyIGludGVy ZXN04oCmIG9uZSBpcyB0aGUg4oCcbmV0d29yayBlYXRzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7RFNDUC1tYXJrZWQgYnV0IGFsbG93cyBub24tbWFya2Vk4oCdIGNhc2UuIEFyZ3VtZW50 cyBnbyBib3RoIHdheXMgYXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0byB3aGF0IG9u ZSBzaG91bGQgZG8gaW4gdGhpcyBjYXNlIChmb2xsb3cgbmV0d29yayBhZG1pbiBkZXNpcmVzPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dnMuIHdvcmsgYXMgb2Z0ZW4gYXMgcG9zc2libGUp Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KSXMgdGhhdCBhIHJlYWwgb2JzZXJ2ZWQgY2FzZSAt IHRoYXQgYWxsIHRyYWZmaWMgdGhhdCBzZXRzIGEgc3BlY2lmaWMgPGJyPg0KRFNDUCBpcyBsb3N0 LCByYXRoZXIgdGhhbiByZS1tYXJrZWQ/PGJyPg0KPGJyPg0KLSBUaGVyZSdzIGFsc28gYW4gb2J2 aW91cyBjYXNlIHdoZXJlIGEgc3BlY2lmaWMgRFNDUCBpcyBjb25kaXRpb25lZCA8YnI+DQooZS5n LiByYXRlLWxpbWl0ZWQpLCB3aGljaCBtZWFucyBzb21lIHBhY2tldHMgdHJhdmVyc2UgdGhlIHBh dGgsIGJ1dCBhIDxicj4NCmZ1bGwgbWVkaWEgZmxvdyB3aWxsIG5vdC4gSG93ZXZlciwgbm90IHN1 cmUgdGhhdCBvYnNlcnZhdGlvbiBoZWxwcyBhdCBhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48c3BhbiBsYW5nPSJERSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIGxhbmc9IkRFIj5JIGNhbid0IHNwZWFrIGZvciBvdGhlcnMsIGJ1dCBvdXIgZXhw ZXJpZW5jZSB3aXRoIGRlcGxveWluZyBEU0NQIGVuIG1hc3NlIGlzIHRoYXQgdGhlcmUgYXJlIGVu b3VnaCBjYXNlcyB3aGVyZSBkcm9wcGluZyBoYXBwZW5zIHRvIG91dHdlaWdoIHRoZSBwcmlvcml0 aXphdGlvbiBiZW5lZml0cy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949363064A398MX307CL04corpem_-- From nobody Wed Jul 31 07:07:53 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377F51200D7; Wed, 31 Jul 2019 07:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 PKwz7rHSGTOA; Wed, 31 Jul 2019 07:07:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C69120077; Wed, 31 Jul 2019 07:07:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B7E977C3625; Wed, 31 Jul 2019 16:07:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BI9Mxt5Fa8Nv; Wed, 31 Jul 2019 16:07:44 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id D99D77C32EF; Wed, 31 Jul 2019 16:07:43 +0200 (CEST) To: Justin Uberti , Matthew Kaufman Cc: "rtcweb@ietf.org" , "tsvwg@ietf.org" References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <3cc1b783-13ed-7a7f-a884-84d5aaa4092d@alvestrand.no> Date: Wed, 31 Jul 2019 16:07:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 14:07:51 -0000 draft-ietf-tsvwg-rtcweb-qos is out of scope for this working group, but didn't we cover this ground extensively in draft-ietf-rtcweb-transport? Namely (from -17): 4.2. Usage of Quality of Service - DSCP and Multiplexing When the packet is sent, the network will make decisions about queueing and/or discarding the packet that can affect the quality of the communication. The sender can attempt to set the DSCP field of the packet to influence these decisions. Implementations SHOULD attempt to set QoS on the packets sent, according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. It is appropriate to depart from this recommendation when running on platforms where QoS marking is not implemented. The implementation MAY turn off use of DSCP markings if it detects symptoms of unexpected behaviour like priority inversion or blocking of packets with certain DSCP markings. Some examples of such behaviors are described in [ANRW16]. The detection of these conditions is implementation dependent. A particularly hard problem is when one media transport uses multiple DSCP code points, where one may be blocked and another may be allowed. This is allowed even within a single media flow for video in [I-D.ietf-tsvwg-rtcweb-qos]. Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCP code points that are intended to be used once a candidate pair has been selected. If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0. This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent. This switch will of course invalidate any congestion information gathered up to that point. Failures can also start happening during the lifetime of the call; this case is expected to be rarer, and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart. Note that when a DSCP code point causes non-delivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes. Other flows on the same transport, using different DSCP code points, don't need to change. All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point. The code point used SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the highest priority data channel carried. Note that this means that all data packets, no matter what their relative priority is, will be treated the same by the network. All packets on one TCP connection, no matter what it carries, MUST use a single DSCP code point. More advice on the use of DSCP code points with RTP and on the relationship between DSCP and congestion control is given in [RFC7657]. Den 31.07.2019 07:12, skrev Justin Uberti: > > > On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman > wrote: > > I noted two of particular interest… one is the “network eats > DSCP-marked but allows non-marked” case. Arguments go both ways as > to what one should do in this case (follow network admin desires vs. > work as often as possible). > > > I lean towards 'work as often as possible', which suggests we probably > need both marked and unmarked ICE checks to determine whether we should > mark media traffic (and potentially multiple differently marked checks > in the mux case).  > > ____ > > __ __ > > The other is picking which DSCP value in the case where multiplexing > is in use and you don’t know whether you’re audio-only or > audio-plus-video or data-only at the time you do the ICE exchange.____ > > __ __ > > (Never mind that Windows has limitations on marking, which I’m sure > we’ve all dealt with)____ > > __ __ > > Matthew Kaufman____ > > __ __ > > *From: *Justin Uberti > > *Date: *Wednesday, July 31, 2019 at 10:36 AM > *To: *Matthew Kaufman > > *Cc: *"tsvwg@ietf.org " >, "rtcweb@ietf.org " > > > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos____ > > __ __ > > hmm, right. We have definitely observed that some networks will eat > marked traffic, so there needs to be some sort of trial exchange to > ensure a given marking will work.  ____ > > __ __ > > Can you summarize the other issues you are concerned about? ____ > > __ __ > > On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman > > wrote:____ > > IF one believes that none of the open issues mentioned in the > email thread I sent are an issue, then sure, RFC5245 applies.____ > >  ____ > > But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos > should say what to do and reference 5245.____ > >  ____ > > Alternatively, one might believe that one or more of the issues > are a real problem… in which case we should specify alternative > behavior.____ > >  ____ > > Matthew Kaufman____ > >  ____ > > *From: *Justin Uberti > > *Date: *Wednesday, July 31, 2019 at 10:08 AM > *To: *Matthew Kaufman > > *Cc: *"tsvwg@ietf.org " >, "rtcweb@ietf.org > " > > *Subject: *Re: [rtcweb] STUN DSCP and > draft-ietf-tsvwg-rtcweb-qos____ > >  ____ > > I had thought this was already covered > in https://tools.ietf.org/html/rfc5245#section-7.1.2.4 > , > which basically says exactly what you are asking for.____ > >  ____ > > On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman > > wrote:____ > > Was chasing down some webrtc rabbit holes today, and came > across the following concern:____ > >  ____ > > draft-ietf-tsvwg-rtcweb-qos has exactly zero language about > how the STUN packets should be marked for ICE negotiation. > The issue is mentioned in > draft-ietf-rtcweb-stun-consent-freshness, but I believe that > the rtcweb-qos document should be the reference to how an > rtcweb transport author should be setting DiffServ markings.____ > >  ____ > > Also, there was a great conversation on the topic back in > 2014 that unfortunately seems to have petered out before a > resolution to some obvious open issues: > https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=1&index=HH0qztqt4UtfZdpuxHTVcg7hZdE > ____ > >  ____ > > Would be great to finish the conversation before finalizing > the specification for how to mark these.____ > >  ____ > > Personally I’m in the “ICE is testing connectivity, so STUN > must be marked exactly the same as corresponding media” > camp.____ > >  ____ > > Matthew Kaufman____ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > ____ > From nobody Wed Jul 31 16:21:26 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8861200B5 for ; Wed, 31 Jul 2019 16:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyQeRsAJCDRf for ; Wed, 31 Jul 2019 16:21:22 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 183891200FF for ; Wed, 31 Jul 2019 16:21:22 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id j26so47555663vsn.10 for ; Wed, 31 Jul 2019 16:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Eb+j5f0s9w1Ul5sSz6VhGRMXCTt1W0q+cLCpuNcy+s8=; b=nwLKXmSfjC5CemGFJWqYXQlUSD8Tonh+gi6RbtIinzgohvjFz8SjftxuKdc9Pk+qbS ZRd4/+rejVQgZYWO+3lc8+lY3APfPqNdoTbtKan8SckhUUeivmbyH58RnX9nu7XzrJm9 ckdD+16qPbABRUmGX/Qk0X9x82b6bBVjFWtdRx1SC4q/kZb3TadFRN2RHoNM+QuIo19Q ExboSC0pQMoqGmyTjyXjWbozEZNi1A41l9qA5Aau74kXM4a5BP6C2YhRPx/gvjrIX+bR LvNMXsqg9SARs/JUdFxdeA5MFjZAUfd2dj6uhymOCL8hTSa5bM9NhJQZV8w0UvX79KAB 68dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Eb+j5f0s9w1Ul5sSz6VhGRMXCTt1W0q+cLCpuNcy+s8=; b=ET5gPkRqVKf4IogZxf3rusM/QxsCgllHOXj2GXcf7bkFof1AhHfaOXcEIx9LFUdBH0 5AlcKSvTCbo0NLULR4xCFJY/nthN6U/lnP2yQxzRB4DhYSKkOz0jAPXaaRPwseUP8YOp BYJXN5keDV4eolqphJWu9xSxDZ1ZKh77Hj1Rxz+aWmbaBNjRdo6IwPD2+dpHo6vN0flg GbtSTSf7QbX1z6ZR3O8lZ6Ow3L4lhkbWj+Tdk2hLeauPXMJKwIpR5NwCSx3txYwIrvNY ceEnfsmRXEp1hJvd7qtW7L7fl9ztAiNRyHtu2IuqqwPgjRS5MKo+cjkV9p20bAVFMkPN xMXw== X-Gm-Message-State: APjAAAVAH/+iqb47JvG9xoaVY5682mIWWmklAO4iakWHX4y4sV9jHt4z ufNw7QCDBoBPTvfC5A8Rwv18VbMSMzI/EjSNe2C7nw== X-Google-Smtp-Source: APXvYqwm8emP6uw8Cwz41igKL/tPXQc6Kn5QCF2YruhnkdARe+A9HD7t4QNL/J+AI8f1cqO6VN1HYIAoFBLzvox7bJE= X-Received: by 2002:a67:8d8a:: with SMTP id p132mr79283473vsd.103.1564615280502; Wed, 31 Jul 2019 16:21:20 -0700 (PDT) MIME-Version: 1.0 References: <64D66E22-E816-4AC7-8887-9CDC01A3252C@bluejeans.com> <3cc1b783-13ed-7a7f-a884-84d5aaa4092d@alvestrand.no> In-Reply-To: <3cc1b783-13ed-7a7f-a884-84d5aaa4092d@alvestrand.no> From: Justin Uberti Date: Wed, 31 Jul 2019 16:21:09 -0700 Message-ID: To: Harald Alvestrand Cc: Matthew Kaufman , "rtcweb@ietf.org" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="000000000000018711058f02625a" Archived-At: Subject: Re: [rtcweb] [tsvwg] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2019 23:21:25 -0000 --000000000000018711058f02625a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great, glad that we've already got this speced. Thanks Harald. On Wed, Jul 31, 2019 at 7:07 AM Harald Alvestrand wrote: > draft-ietf-tsvwg-rtcweb-qos is out of scope for this working group, but > didn't we cover this ground extensively in draft-ietf-rtcweb-transport? > > Namely (from -17): > > 4.2. Usage of Quality of Service - DSCP and Multiplexing > > When the packet is sent, the network will make decisions about > queueing and/or discarding the packet that can affect the quality of > the communication. The sender can attempt to set the DSCP field of > the packet to influence these decisions. > > Implementations SHOULD attempt to set QoS on the packets sent, > according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos]. It is > appropriate to depart from this recommendation when running on > platforms where QoS marking is not implemented. > > The implementation MAY turn off use of DSCP markings if it detects > symptoms of unexpected behaviour like priority inversion or blocking > of packets with certain DSCP markings. Some examples of such > behaviors are described in [ANRW16]. The detection of these > conditions is implementation dependent. > > A particularly hard problem is when one media transport uses multiple > DSCP code points, where one may be blocked and another may be > allowed. This is allowed even within a single media flow for video > in [I-D.ietf-tsvwg-rtcweb-qos]. Implementations need to diagnose > this scenario; one possible implementation is to send initial ICE > probes with DSCP 0, and send ICE probes on all the DSCP code points > that are intended to be used once a candidate pair has been selected. > If one or more of the DSCP-marked probes fail, the sender will switch > the media type to using DSCP 0. This can be carried out > simultaneously with the initial media traffic; on failure, the > initial data may need to be resent. This switch will of course > invalidate any congestion information gathered up to that point. > > Failures can also start happening during the lifetime of the call; > this case is expected to be rarer, and can be handled by the normal > mechanisms for transport failure, which may involve an ICE restart. > > Note that when a DSCP code point causes non-delivery, one has to > switch the whole media flow to DSCP 0, since all traffic for a single > media flow needs to be on the same queue for congestion control > purposes. Other flows on the same transport, using different DSCP > code points, don't need to change. > > All packets carrying data from the SCTP association supporting the > data channels MUST use a single DSCP code point. The code point used > SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for the > highest priority data channel carried. Note that this means that all > data packets, no matter what their relative priority is, will be > treated the same by the network. > > All packets on one TCP connection, no matter what it carries, MUST > use a single DSCP code point. > > More advice on the use of DSCP code points with RTP and on the > relationship between DSCP and congestion control is given in > [RFC7657]. > > Den 31.07.2019 07:12, skrev Justin Uberti: > > > > > > On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman > > wrote: > > > > I noted two of particular interest=E2=80=A6 one is the =E2=80=9Cnet= work eats > > DSCP-marked but allows non-marked=E2=80=9D case. Arguments go both = ways as > > to what one should do in this case (follow network admin desires vs= . > > work as often as possible). > > > > > > I lean towards 'work as often as possible', which suggests we probably > > need both marked and unmarked ICE checks to determine whether we should > > mark media traffic (and potentially multiple differently marked checks > > in the mux case). > > > > ____ > > > > __ __ > > > > The other is picking which DSCP value in the case where multiplexin= g > > is in use and you don=E2=80=99t know whether you=E2=80=99re audio-o= nly or > > audio-plus-video or data-only at the time you do the ICE > exchange.____ > > > > __ __ > > > > (Never mind that Windows has limitations on marking, which I=E2=80= =99m sure > > we=E2=80=99ve all dealt with)____ > > > > __ __ > > > > Matthew Kaufman____ > > > > __ __ > > > > *From: *Justin Uberti >> > > *Date: *Wednesday, July 31, 2019 at 10:36 AM > > *To: *Matthew Kaufman > > > > *Cc: *"tsvwg@ietf.org " > >, "rtcweb@ietf.org = " > > > > > *Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-tsvwg-rtcweb-qos__= __ > > > > __ __ > > > > hmm, right. We have definitely observed that some networks will eat > > marked traffic, so there needs to be some sort of trial exchange to > > ensure a given marking will work. ____ > > > > __ __ > > > > Can you summarize the other issues you are concerned about? ____ > > > > __ __ > > > > On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman > > > wrote:____ > > > > IF one believes that none of the open issues mentioned in the > > email thread I sent are an issue, then sure, RFC5245 applies.__= __ > > > > ____ > > > > But even so, I would argue that draft-ietf-tsvwg-rtcweb-qos > > should say what to do and reference 5245.____ > > > > ____ > > > > Alternatively, one might believe that one or more of the issues > > are a real problem=E2=80=A6 in which case we should specify alt= ernative > > behavior.____ > > > > ____ > > > > Matthew Kaufman____ > > > > ____ > > > > *From: *Justin Uberti > > > > *Date: *Wednesday, July 31, 2019 at 10:08 AM > > *To: *Matthew Kaufman > > > > *Cc: *"tsvwg@ietf.org " > >, "rtcweb@ietf.org > > " rtcweb@ietf.org>> > > *Subject: *Re: [rtcweb] STUN DSCP and > > draft-ietf-tsvwg-rtcweb-qos____ > > > > ____ > > > > I had thought this was already covered > > in https://tools.ietf.org/html/rfc5245#section-7.1.2.4 > > < > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_rfc5245-23section-2D7.1.2.4&d=3DDwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9Zd= wibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opo= lVHejelXn2svE&s=3DltGEgbp10iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=3D > >, > > which basically says exactly what you are asking for.____ > > > > ____ > > > > On Tue, Jul 30, 2019 at 9:09 PM Matthew Kaufman > > > > wrote:____ > > > > Was chasing down some webrtc rabbit holes today, and came > > across the following concern:____ > > > > ____ > > > > draft-ietf-tsvwg-rtcweb-qos has exactly zero language about > > how the STUN packets should be marked for ICE negotiation. > > The issue is mentioned in > > draft-ietf-rtcweb-stun-consent-freshness, but I believe tha= t > > the rtcweb-qos document should be the reference to how an > > rtcweb transport author should be setting DiffServ > markings.____ > > > > ____ > > > > Also, there was a great conversation on the topic back in > > 2014 that unfortunately seems to have petered out before a > > resolution to some obvious open issues: > > > https://mailarchive.ietf.org/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qztqt= 4UtfZdpuxHTVcg7hZdE > > < > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarchive.ietf.o= rg_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg7hZdE&d=3D= DwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1Y= lIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=3DFlrSPxMvUIrN-iqD= sEmRI1U0URJnINsru1TEVWNMUBQ&e=3D > >____ > > > > ____ > > > > Would be great to finish the conversation before finalizing > > the specification for how to mark these.____ > > > > ____ > > > > Personally I=E2=80=99m in the =E2=80=9CICE is testing conne= ctivity, so STUN > > must be marked exactly the same as corresponding media=E2= =80=9D > > camp.____ > > > > ____ > > > > Matthew Kaufman____ > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > < > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_rtcweb&d=3DDwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo= 80OngsIQIXTs5v-9PG8HT1YlIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2s= vE&s=3D89GkSxwEhG63-il9an69COx4NNrA8nM3i4siRUHMFHM&e=3D > >____ > > > > --000000000000018711058f02625a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, glad that we've already got this speced. Thanks= Harald.

On Wed, Jul 31, 2019 at 7:07 AM Harald Alvestrand <harald@alvestrand.no> wrote:
draft-ietf-tsvwg-rtcweb-qos = is out of scope for this working group, but
didn't we cover this ground extensively in draft-ietf-rtcweb-transport?=

Namely (from -17):

4.2.=C2=A0 Usage of Quality of Service - DSCP and Multiplexing

=C2=A0 =C2=A0When the packet is sent, the network will make decisions about=
=C2=A0 =C2=A0queueing and/or discarding the packet that can affect the qual= ity of
=C2=A0 =C2=A0the communication.=C2=A0 The sender can attempt to set the DSC= P field of
=C2=A0 =C2=A0the packet to influence these decisions.

=C2=A0 =C2=A0Implementations SHOULD attempt to set QoS on the packets sent,=
=C2=A0 =C2=A0according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos].=C2= =A0 It is
=C2=A0 =C2=A0appropriate to depart from this recommendation when running on=
=C2=A0 =C2=A0platforms where QoS marking is not implemented.

=C2=A0 =C2=A0The implementation MAY turn off use of DSCP markings if it det= ects
=C2=A0 =C2=A0symptoms of unexpected behaviour like priority inversion or bl= ocking
=C2=A0 =C2=A0of packets with certain DSCP markings.=C2=A0 Some examples of = such
=C2=A0 =C2=A0behaviors are described in [ANRW16].=C2=A0 The detection of th= ese
=C2=A0 =C2=A0conditions is implementation dependent.

=C2=A0 =C2=A0A particularly hard problem is when one media transport uses m= ultiple
=C2=A0 =C2=A0DSCP code points, where one may be blocked and another may be<= br> =C2=A0 =C2=A0allowed.=C2=A0 This is allowed even within a single media flow= for video
=C2=A0 =C2=A0in [I-D.ietf-tsvwg-rtcweb-qos].=C2=A0 Implementations need to = diagnose
=C2=A0 =C2=A0this scenario; one possible implementation is to send initial = ICE
=C2=A0 =C2=A0probes with DSCP 0, and send ICE probes on all the DSCP code p= oints
=C2=A0 =C2=A0that are intended to be used once a candidate pair has been se= lected.
=C2=A0 =C2=A0If one or more of the DSCP-marked probes fail, the sender will= switch
=C2=A0 =C2=A0the media type to using DSCP 0.=C2=A0 This can be carried out<= br> =C2=A0 =C2=A0simultaneously with the initial media traffic; on failure, the=
=C2=A0 =C2=A0initial data may need to be resent.=C2=A0 This switch will of = course
=C2=A0 =C2=A0invalidate any congestion information gathered up to that poin= t.

=C2=A0 =C2=A0Failures can also start happening during the lifetime of the c= all;
=C2=A0 =C2=A0this case is expected to be rarer, and can be handled by the n= ormal
=C2=A0 =C2=A0mechanisms for transport failure, which may involve an ICE res= tart.

=C2=A0 =C2=A0Note that when a DSCP code point causes non-delivery, one has = to
=C2=A0 =C2=A0switch the whole media flow to DSCP 0, since all traffic for a= single
=C2=A0 =C2=A0media flow needs to be on the same queue for congestion contro= l
=C2=A0 =C2=A0purposes.=C2=A0 Other flows on the same transport, using diffe= rent DSCP
=C2=A0 =C2=A0code points, don't need to change.

=C2=A0 =C2=A0All packets carrying data from the SCTP association supporting= the
=C2=A0 =C2=A0data channels MUST use a single DSCP code point.=C2=A0 The cod= e point used
=C2=A0 =C2=A0SHOULD be that recommended by [I-D.ietf-tsvwg-rtcweb-qos] for = the
=C2=A0 =C2=A0highest priority data channel carried.=C2=A0 Note that this me= ans that all
=C2=A0 =C2=A0data packets, no matter what their relative priority is, will = be
=C2=A0 =C2=A0treated the same by the network.

=C2=A0 =C2=A0All packets on one TCP connection, no matter what it carries, = MUST
=C2=A0 =C2=A0use a single DSCP code point.

=C2=A0 =C2=A0More advice on the use of DSCP code points with RTP and on the=
=C2=A0 =C2=A0relationship between DSCP and congestion control is given in =C2=A0 =C2=A0[RFC7657].

Den 31.07.2019 07:12, skrev Justin Uberti:
>
>
> On Tue, Jul 30, 2019 at 10:10 PM Matthew Kaufman <mkaufman@bluejeans.com
> <mailto:mkaufman@bluejeans.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I noted two of particular interest=E2=80=A6 one is = the =E2=80=9Cnetwork eats
>=C2=A0 =C2=A0 =C2=A0DSCP-marked but allows non-marked=E2=80=9D case. Ar= guments go both ways as
>=C2=A0 =C2=A0 =C2=A0to what one should do in this case (follow network = admin desires vs.
>=C2=A0 =C2=A0 =C2=A0work as often as possible).
>
>
> I lean towards 'work as often as possible', which suggests we = probably
> need both marked and unmarked ICE checks to determine whether we shoul= d
> mark media traffic (and potentially multiple differently marked checks=
> in the mux case).=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0The other is picking which DSCP value in the case w= here multiplexing
>=C2=A0 =C2=A0 =C2=A0is in use and you don=E2=80=99t know whether you=E2= =80=99re audio-only or
>=C2=A0 =C2=A0 =C2=A0audio-plus-video or data-only at the time you do th= e ICE exchange.____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0(Never mind that Windows has limitations on marking= , which I=E2=80=99m sure
>=C2=A0 =C2=A0 =C2=A0we=E2=80=99ve all dealt with)____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0Matthew Kaufman____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0*From: *Justin Uberti <juberti@google.com <mailto:juberti@google.com>>= ;
>=C2=A0 =C2=A0 =C2=A0*Date: *Wednesday, July 31, 2019 at 10:36 AM
>=C2=A0 =C2=A0 =C2=A0*To: *Matthew Kaufman <mkaufman@bluejeans.com
>=C2=A0 =C2=A0 =C2=A0<mailto:mkaufman@bluejeans.com>>
>=C2=A0 =C2=A0 =C2=A0*Cc: *"tsvwg@ietf.org <mailto:tsvwg@ietf.org>" <tsvwg@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:tsvwg@ietf.org>>, "rtcweb@ietf.org <mailto:rtcweb@ietf.org>"
>=C2=A0 =C2=A0 =C2=A0<rtcweb@ietf.org <mailto:rtcweb@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0*Subject: *Re: [rtcweb] STUN DSCP and draft-ietf-ts= vwg-rtcweb-qos____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0hmm, right. We have definitely observed that some n= etworks will eat
>=C2=A0 =C2=A0 =C2=A0marked traffic, so there needs to be some sort of t= rial exchange to
>=C2=A0 =C2=A0 =C2=A0ensure a given marking will work.=C2=A0 ____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0Can you summarize the other issues you are concerne= d about?=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0On Tue, Jul 30, 2019 at 9:47 PM Matthew Kaufman
>=C2=A0 =C2=A0 =C2=A0<mkaufman@bluejeans.com <mailto:mkaufman@bluejeans.com>> wrot= e:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IF one believes that none of the open= issues mentioned in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0email thread I sent are an issue, the= n sure, RFC5245 applies.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0But even so, I would argue that draft= -ietf-tsvwg-rtcweb-qos
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should say what to do and reference 5= 245.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Alternatively, one might believe that= one or more of the issues
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are a real problem=E2=80=A6 in which = case we should specify alternative
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0behavior.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Matthew Kaufman____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*From: *Justin Uberti <juberti@google.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:juberti@google.com>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Date: *Wednesday, July 31, 2019 at 1= 0:08 AM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*To: *Matthew Kaufman <mkaufman@bluejeans.com=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:mkaufman@bluejeans.com>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Cc: *"tsvwg@ietf.org <mailto:tsvwg@ietf.org>" <tsvwg@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:tsvwg@ietf.org>>, "rtcweb@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:rtcweb@ietf.org>" <rtcweb@ietf.org <mailto:rtcweb@ietf.org>>=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Subject: *Re: [rtcweb] STUN DSCP and=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tsvwg-rtcweb-qos____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I had thought this was already covere= d
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in=C2=A0htt= ps://tools.ietf.org/html/rfc5245#section-7.1.2.4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://urldefense.proofpoint.com/v2/url?u=3D= https-3A__tools.ietf.org_html_rfc5245-23section-2D7.1.2.4&d=3DDwMFaQ&am= p;c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1Yl= IatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=3DltGEgbp10= iUc1gBO_cimQvtZZ9HfiJOm_ysp3ZOo0eQ&e=3D>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which basically says exactly what you= are asking for.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Jul 30, 2019 at 9:09 PM Matth= ew Kaufman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mkaufman@bluejeans.com <mailto:mkaufman@bluejeans.com>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Was chasing down some w= ebrtc rabbit holes today, and came
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0across the following co= ncern:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tsvwg-rtcweb= -qos has exactly zero language about
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0how the STUN packets sh= ould be marked for ICE negotiation.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The issue is mentioned = in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-rtcweb-stun-= consent-freshness, but I believe that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the rtcweb-qos document= should be the reference to how an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rtcweb transport author= should be setting DiffServ markings.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Also, there was a great= conversation on the topic back in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02014 that unfortunately= seems to have petered out before a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0resolution to some obvi= ous open issues:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://mailarchive.ietf.or= g/arch/browse/rtcweb/?gbt=3D1&index=3DHH0qztqt4UtfZdpuxHTVcg7hZdE >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarch= ive.ietf.org_arch_browse_rtcweb_-3Fgbt-3D1-26index-3DHH0qztqt4UtfZdpuxHTVcg= 7hZdE&d=3DDwMFaQ&c=3DPpPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo8= 0OngsIQIXTs5v-9PG8HT1YlIatVI&m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelX= n2svE&s=3DFlrSPxMvUIrN-iqDsEmRI1U0URJnINsru1TEVWNMUBQ&e=3D>_= ___
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would be great to finis= h the conversation before finalizing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the specification for h= ow to mark these.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Personally I=E2=80=99m = in the =E2=80=9CICE is testing connectivity, so STUN
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must be marked exactly = the same as corresponding media=E2=80=9D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0camp.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Matthew Kaufman____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________= ________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rtcweb mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://www.ietf.org/mailman/listinfo/rtcweb
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_mailman_listinfo_rtcweb&d=3DDwMFaQ&c=3DP= pPcabknNF6XJFBaeGH06g&r=3D9ZdwibcaitRZyo80OngsIQIXTs5v-9PG8HT1YlIatVI&a= mp;m=3DfbpMIVl4LuFN5soU2Avi1NbII--opolVHejelXn2svE&s=3D89GkSxwEhG63-il9= an69COx4NNrA8nM3i4siRUHMFHM&e=3D>____
>

--000000000000018711058f02625a--