From nobody Sun Jun 3 20:48:53 2018 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 08B521200F1 for ; Sun, 3 Jun 2018 20:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 GBGrpsmlpZSX for ; Sun, 3 Jun 2018 20:48:48 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707181200A0 for ; Sun, 3 Jun 2018 20:48:48 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id c132-v6so279892ith.1 for ; Sun, 03 Jun 2018 20:48:48 -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=FGoI3xhywWeerFCK0QGWDyjanK3rVMUbfVlyHotMJSI=; b=JDUEFDWcGNiEFmox5TlA9FMKYIFQDoJnRQoMNOdTwzw+geF1V89Wl3lK0hi1tTVkiL jb9LSPMpsWUEgunGDzeycN7kAUhqPwgBXSScfMvubRJKKMmcCThdcUOdj3aWgLbBl0Wy kNYAz0qwKIYck7uttM8gYkxIGgQanaPN7sIfg98YIv2QToEsk0AwGbFmgz/Qelk/0phX TDYeYomvthh1JXsX0Ye9Xol0KpAUHWlcRzM8daPfEjeTp33TLgZbvqItOz++Ta4zVEwm ZfXei1OKYw/orOdpWU/62Yfl//DRA+/quiUitKaN/g2mnS+OD1098koNAk5nFsnnjuyV /1zA== 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=FGoI3xhywWeerFCK0QGWDyjanK3rVMUbfVlyHotMJSI=; b=uKERT5xHrawldtgZnz69Yn/B4kM1AfseTRnLnSDAyeCb95Xz7Smfhk0k+ivB1kViK4 09pqawhxV/Re5fgwxNK5CdP0wnqaxsDFrDpQ5UTFjudr4sSW9bv0PwyHpG3m9vKdPgqW LLUIBqmtwgiH3+Rl2jxPRIXCgPre1fFGRcRazSPFomfR5oRKCzm9x7R9N6VPjD8GBUCi DYw7SkPpIAJbIDW4wIves9vMUF4lhv1553+b24TQ4QCZ7NtILE9ucQWf6vikQkfvBsU/ sDTJN9bvo76k/ByGKE8qP6l1EmPuNaE4Eyx5O5yXV6vcDRH6irkFyrsN8tn1wp5aL6Ra 7oTA== X-Gm-Message-State: APt69E1m5Zhg3XoV3/9wN5w3FnzqLbEGq3w606CdlS6BXxlHcOYlcS3+ diGF48I6tBfylLtlTSQx57+2lKhK5ja7sR/u5V+b7Q== X-Google-Smtp-Source: ADUXVKKfDbaE5FdbM2WVjztETbaoQkW4DLT7R+E8aUL0cl3rdcfJSBPkJXNPAtwpio4H/wn7d9lHRQ/c7yqxVV2ve/U= X-Received: by 2002:a24:7582:: with SMTP id y124-v6mr12597497itc.115.1528084127144; Sun, 03 Jun 2018 20:48:47 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> <574256E1-7AF4-4E25-9462-04B4B599C801@mozilla.com> <6DF5B202-803F-452B-B17E-5346F4C6FB4B@iii.ca> In-Reply-To: <6DF5B202-803F-452B-B17E-5346F4C6FB4B@iii.ca> From: Justin Uberti Date: Sun, 3 Jun 2018 20:48:34 -0700 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000967c07056dc8cf95" Archived-At: Subject: Re: [rtcweb] Nils comments [Was: WGLC for draft-ietf-rtcweb-ip-handling] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jun 2018 03:48:51 -0000 --000000000000967c07056dc8cf95 Content-Type: text/plain; charset="UTF-8" Agreed. Created https://github.com/juberti/draughts/pull/102 that adds a high-level discussion of enterprise TURN servers, hopefully enough to clarify the situation. If you think "browser-provided TURN server" is a clearer term, I could use that instead. On Mon, May 14, 2018 at 6:21 AM Cullen Jennings wrote: > > > On May 11, 2018, at 11:08 AM, Justin Uberti < > juberti=40google.com@dmarc.ietf.org> wrote: > > Thanks for the PR. I spent some time thinking about this and ultimately > concluded that more significant changes to the document will be necessary > if it is to prescribe how a browser-provided TURN server should be handled, > essentially incorporating much of the guidance from > https://tools.ietf.org/html/draft-ietf-rtcweb-return-02 > > For example, candidates produced from the TURN server should not have > raddr/rport set; interactions between the browser-provided and any > application-provided TURN server need to be described; the question of > whether local candidates should be provided needs to be considered. > > As such, I see 3 paths forward here: > a) Leave the document as-is. While leaving some ambiguity on this topic, > the eventual (hopefully) publication of RETURN should clarify things, at > which point we can publish a -bis. > b) Discuss the general concept of browser-provided TURN servers, but > mention that this is an area of further study, and give some guidance based > on our current understanding. That is, explain how the existing modes would > work in the presence of a browser-provided TURN server. > c) Restore the reference to RETURN and progress the RETURN doc. > > Overall, I don't expect the mode recommendations to change in the presence > of a browser- or network- provided TURN server, so I think any changes here > will be almost entirely additive. > > Thoughts? > > > > I lean towards option B as it sounds like it meets our current needs and > allows us to separate out the harder stuff to do later. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000967c07056dc8cf95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed. Created=C2=A0https://github.com/juberti/draughts/p= ull/102 that adds a high-level discussion of enterprise TURN servers, h= opefully enough to clarify the situation.

If you think &= quot;browser-provided TURN server" is a clearer term, I could use that= instead.



On Mon, May 14, 2018 at 6:21 AM Cullen Jennings= <fluffy@iii.ca&g= t; wrote:


On May 11, 2018, at 11:08 AM, Justin Uberti <juberti=3D40google= .com@dmarc.ietf.org> wrote:

<= div dir=3D"ltr">Thanks for the PR. I spent some time thinking about this an= d ultimately concluded that more significant changes to the document will b= e necessary if it is to prescribe how a browser-provided TURN server should= be handled, essentially incorporating much of the guidance from=C2=A0https://tools.ietf.org/html/draft-ietf-rtcweb-return-02
<= br>
For example, candidates produced from the TURN server should = not have raddr/rport set; interactions between the browser-provided and any= application-provided TURN server need to be described; the question of whe= ther local candidates should be provided needs to be considered.
=
As such, I see 3 paths forward here:
a) Leave the = document as-is. While leaving some ambiguity on this topic, the eventual (h= opefully) publication of RETURN should clarify things, at which point we ca= n publish a -bis.
b) Discuss the general concept of browser-provi= ded TURN servers, but mention that this is an area of further study, and gi= ve some guidance based on our current understanding. That is, explain how t= he existing modes would work in the presence of a browser-provided TURN ser= ver.
c) Restore the reference to RETURN and progress the RETURN d= oc.

Overall, I don't expect the mode recommend= ations to change in the presence of a browser- or network- provided TURN se= rver, so I think any changes here will be almost entirely additive.

Thoughts?

I lean towards option B as it sounds like it meets our current= needs and allows us to separate out the harder stuff to do later.=C2=A0


____________________________________= ___________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000967c07056dc8cf95-- From nobody Sun Jun 3 21:12:04 2018 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 240FA12025C for ; Sun, 3 Jun 2018 21:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 GZfqO4PagFHF for ; Sun, 3 Jun 2018 21:11:57 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93381200F1 for ; Sun, 3 Jun 2018 21:11:57 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id z9-v6so15513050plk.11 for ; Sun, 03 Jun 2018 21:11:57 -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=BjVCJbiarmticXH2V8QKNDguCNVmoDV6v/zGD/g896k=; b=d1wHNWJ4cfbd4/ngRgKKao+c+OepJ1zRXT1H/gSrYjA8I3hKT2HLaHq8kH+hSWIA8N Dty8woU+XezIry6/DdTa7XfmKFQNEnq6krFNOUzVcK7/rvn+Kqo/0/9LJqgVo1Jy1+A1 RaBFLBbxGthP/t6dS/7uWsorU/ngzJj5f26QQ= 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=BjVCJbiarmticXH2V8QKNDguCNVmoDV6v/zGD/g896k=; b=JIgUYncZmLJ5RNznaYvNbg6FHSyTjzYVWpO/PGSnBFSudV90xwCPARtwvvIzIePEBa tN1LHAgLo8mTcYCYNMc0gs2luWKzLaQddpxolhazSf/deW8tzP/TLfQISRbVnh9R6Uhh TASj8CWBSeOsJCmOvoRNfV+t/HMNsuxxs6ktfLh83cKOZqzK8HwMmyDxfxXP+bG5CyLg k45zLjgMUaGvyE4p59uVaxN21vEsD8JxsDkoTTu28SQk+Pty2oLs4ZX7MZyMAhSStf67 FGMlY4R2N8Y3aevrP/MSsDaL6BbquApB9YHlTMXaHPIWr+JGc8UJnptHzckBpd6JYHaU BD/A== X-Gm-Message-State: ALKqPwcpdhfBr7m+7ngMOgMRcoxTmGfXxEZGYD9Q3fdjCcfM2v6d8ALW azevWKPQPEg8P/9pbnp0xCckLg== X-Google-Smtp-Source: ADUXVKK0UDClhzbDU4BPYCNSSNAXILPax0Kruw6d9VhzjbhB3LPb+Rh3E+nvwgXsJJFO9QiL/TysUg== X-Received: by 2002:a17:902:2c01:: with SMTP id m1-v6mr19285492plb.347.1528085517015; Sun, 03 Jun 2018 21:11:57 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:7060:4a41:4c65:761a? ([2601:647:4600:3f31:7060:4a41:4c65:761a]) by smtp.gmail.com with ESMTPSA id i4-v6sm21248421pfk.133.2018.06.03.21.11.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Jun 2018 21:11:55 -0700 (PDT) From: Nils Ohlmeier Message-Id: <0051C70E-362F-4E20-9DF8-9290DD4EB989@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ED41ABE0-5863-4C84-B2A3-7D59B67B9376" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 3 Jun 2018 21:11:53 -0700 In-Reply-To: Cc: Cullen Jennings , RTCWeb IETF To: Justin Uberti References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> <574256E1-7AF4-4E25-9462-04B4B599C801@mozilla.com> <6DF5B202-803F-452B-B17E-5346F4C6FB4B@iii.ca> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] Nils comments [Was: WGLC for draft-ietf-rtcweb-ip-handling] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jun 2018 04:12:02 -0000 --Apple-Mail=_ED41ABE0-5863-4C84-B2A3-7D59B67B9376 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I reviewed the diff and I think it helps to clarify this. Best Nils > On Jun 3, 2018, at 20:48, Justin Uberti = wrote: >=20 > Agreed. Created https://github.com/juberti/draughts/pull/102 = that adds a high-level = discussion of enterprise TURN servers, hopefully enough to clarify the = situation. >=20 > If you think "browser-provided TURN server" is a clearer term, I could = use that instead. >=20 >=20 >=20 > On Mon, May 14, 2018 at 6:21 AM Cullen Jennings > wrote: >=20 >=20 >> On May 11, 2018, at 11:08 AM, Justin Uberti = > wrote: >>=20 >> Thanks for the PR. I spent some time thinking about this and = ultimately concluded that more significant changes to the document will = be necessary if it is to prescribe how a browser-provided TURN server = should be handled, essentially incorporating much of the guidance from = https://tools.ietf.org/html/draft-ietf-rtcweb-return-02 = >>=20 >> For example, candidates produced from the TURN server should not have = raddr/rport set; interactions between the browser-provided and any = application-provided TURN server need to be described; the question of = whether local candidates should be provided needs to be considered. >>=20 >> As such, I see 3 paths forward here: >> a) Leave the document as-is. While leaving some ambiguity on this = topic, the eventual (hopefully) publication of RETURN should clarify = things, at which point we can publish a -bis. >> b) Discuss the general concept of browser-provided TURN servers, but = mention that this is an area of further study, and give some guidance = based on our current understanding. That is, explain how the existing = modes would work in the presence of a browser-provided TURN server. >> c) Restore the reference to RETURN and progress the RETURN doc. >>=20 >> Overall, I don't expect the mode recommendations to change in the = presence of a browser- or network- provided TURN server, so I think any = changes here will be almost entirely additive. >>=20 >> Thoughts? >=20 >=20 > I lean towards option B as it sounds like it meets our current needs = and allows us to separate out the harder stuff to do later.=20 >=20 >=20 > _______________________________________________ > 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=_ED41ABE0-5863-4C84-B2A3-7D59B67B9376 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = reviewed the diff and I think it helps to clarify this.
Best
  = Nils

On Jun 3, 2018, at 20:48, Justin Uberti = <juberti=3D40google.com@dmarc.ietf.org> wrote:

Agreed. Created https://github.com/juberti/draughts/pull/102 that adds a = high-level discussion of enterprise TURN servers, hopefully enough to = clarify the situation.

If you think "browser-provided TURN server" is a clearer = term, I could use that instead.



On = Mon, May 14, 2018 at 6:21 AM Cullen Jennings <fluffy@iii.ca> wrote:

On May 11, 2018, at 11:08 AM, Justin Uberti = <juberti=3D40google..com@dmarc.ietf.org>= ; wrote:

Thanks for the PR. I spent some time thinking about this and = ultimately concluded that more significant changes to the document will = be necessary if it is to prescribe how a browser-provided TURN server = should be handled, essentially incorporating much of the guidance = from https://tools.ietf.org/html/draft-ietf-rtcweb-return-02

For = example, candidates produced from the TURN server should not have = raddr/rport set; interactions between the browser-provided and any = application-provided TURN server need to be described; the question of = whether local candidates should be provided needs to be = considered.

As = such, I see 3 paths forward here:
a) Leave the = document as-is. While leaving some ambiguity on this topic, the eventual = (hopefully) publication of RETURN should clarify things, at which point = we can publish a -bis.
b) Discuss the general = concept of browser-provided TURN servers, but mention that this is an = area of further study, and give some guidance based on our current = understanding. That is, explain how the existing modes would work in the = presence of a browser-provided TURN server.
c) = Restore the reference to RETURN and progress the RETURN doc.

Overall, I don't expect = the mode recommendations to change in the presence of a browser- or = network- provided TURN server, so I think any changes here will be = almost entirely additive.

Thoughts?


I lean = towards option B as it sounds like it meets our current needs and allows = us to separate out the harder stuff to do later. 


_______________________________________________
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=_ED41ABE0-5863-4C84-B2A3-7D59B67B9376-- From nobody Mon Jun 4 04:28:35 2018 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 DA25612D946 for ; Mon, 4 Jun 2018 04:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 RqGvIA6bYsVj for ; Mon, 4 Jun 2018 04:28:31 -0700 (PDT) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A480512D945 for ; Mon, 4 Jun 2018 04:28:31 -0700 (PDT) Received: by mail-pl0-x232.google.com with SMTP id g20-v6so1752176plq.1 for ; Mon, 04 Jun 2018 04:28:31 -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=LzD8NY6kYyAvtjbXfsnOgAu+n4XhbEHrAqy4Cd2UuwA=; b=OfaQUwyUPaganQ5lbZDX6sILWqWqsGyWu7SymDIEqVbXgaIsRwhjk7thwrO71o8E+u gHcv/LMXJerfs58TscgM5upOS0Rvajp1dfNgvUAcJSKd0mWAYubj4ESKbn33U7PRZe/M J5lZV/0gYVVARg4txtko3mvxmVM8tSJGFJIos= 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=LzD8NY6kYyAvtjbXfsnOgAu+n4XhbEHrAqy4Cd2UuwA=; b=Zj7OhX4xxvuGQp4i2pg5y5l4b3njyRUlMolMhW8dpYZoPki02MfJLEZBicR8+l2jNp +eyNkYhVW30oGM3LwkUW+UVaATioruvw4uDg+RAw8ikKfw0ZUBlf9gkMm8Pnhdm4igtF xPHJqOQCftoto0mhTM5RvN7Kix0pImfwHteHCSINoPkqgE1Vk/XCRIE8SOTOXGeKkLKJ AN3p+aECO589dlScDj8cXUoX5IdPMOxywyov8t/CYzCtjqwQoHfqwX5trn73K6TwksRT 47RtsRuKJ7ayBtkCXjjwT1jDfxZXpBKu55oK5nIGbmgflrDJG6VFGjT4TPZPY3CRv2Du tVFg== X-Gm-Message-State: ALKqPwc+D22UD/YV6zg/pXpexD0TDJvJ17Ny1Ca5qEpICqfrKeTUK1yf nVUM7PyLdUeVd+bxFj6NAsBMrC6HnVo= X-Google-Smtp-Source: ADUXVKLcxJZgA1UPCUCeKOX0u9S8aLKqlVCG7EknFnxdXnBK9PP6cS75LOUL/tfrkxSLchtPPZTP8Q== X-Received: by 2002:a17:902:3001:: with SMTP id u1-v6mr21485357plb.376.1528111710941; Mon, 04 Jun 2018 04:28:30 -0700 (PDT) Received: from [5.5.33.250] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id g15-v6sm59204248pgv.58.2018.06.04.04.28.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jun 2018 04:28:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: <0051C70E-362F-4E20-9DF8-9290DD4EB989@mozilla.com> Date: Mon, 4 Jun 2018 13:28:22 +0200 Cc: Justin Uberti , Nils Ohlmeier Content-Transfer-Encoding: quoted-printable Message-Id: <9216A555-846F-4E87-9D8B-2F2014B598FC@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> <574256E1-7AF4-4E25-9462-04B4B599C801@mozilla.com> <6DF5B202-803F-452B-B17E-5346F4C6FB4B@iii.ca> <0051C70E-362F-4E20-9DF8-9290DD4EB989@mozilla.com> To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Nils comments [Was: WGLC for draft-ietf-rtcweb-ip-handling] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 04 Jun 2018 11:28:34 -0000 Let=E2=80=99s let this simmer until June 11th, but then we ought to = merge it. spt > On Jun 4, 2018, at 06:11, Nils Ohlmeier wrote: >=20 > I reviewed the diff and I think it helps to clarify this. >=20 > Best > Nils >=20 >> On Jun 3, 2018, at 20:48, Justin Uberti = wrote: >>=20 >> Agreed. Created https://github.com/juberti/draughts/pull/102 that = adds a high-level discussion of enterprise TURN servers, hopefully = enough to clarify the situation. >>=20 >> If you think "browser-provided TURN server" is a clearer term, I = could use that instead. >>=20 >>=20 >>=20 >> On Mon, May 14, 2018 at 6:21 AM Cullen Jennings = wrote: >>=20 >>=20 >>> On May 11, 2018, at 11:08 AM, Justin Uberti = wrote: >>>=20 >>> Thanks for the PR. I spent some time thinking about this and = ultimately concluded that more significant changes to the document will = be necessary if it is to prescribe how a browser-provided TURN server = should be handled, essentially incorporating much of the guidance from = https://tools.ietf.org/html/draft-ietf-rtcweb-return-02 >>>=20 >>> For example, candidates produced from the TURN server should not = have raddr/rport set; interactions between the browser-provided and any = application-provided TURN server need to be described; the question of = whether local candidates should be provided needs to be considered. >>>=20 >>> As such, I see 3 paths forward here: >>> a) Leave the document as-is. While leaving some ambiguity on this = topic, the eventual (hopefully) publication of RETURN should clarify = things, at which point we can publish a -bis. >>> b) Discuss the general concept of browser-provided TURN servers, but = mention that this is an area of further study, and give some guidance = based on our current understanding. That is, explain how the existing = modes would work in the presence of a browser-provided TURN server. >>> c) Restore the reference to RETURN and progress the RETURN doc. >>>=20 >>> Overall, I don't expect the mode recommendations to change in the = presence of a browser- or network- provided TURN server, so I think any = changes here will be almost entirely additive. >>>=20 >>> Thoughts? >>=20 >>=20 >> I lean towards option B as it sounds like it meets our current needs = and allows us to separate out the harder stuff to do later.=20 >>=20 >>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jun 11 17:40:38 2018 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 9C435130DEE for ; Mon, 11 Jun 2018 17:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 R1mOccEV-7ES for ; Mon, 11 Jun 2018 17:40:27 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE32130E7D for ; Mon, 11 Jun 2018 17:40:27 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a3-v6so13332758itd.0 for ; Mon, 11 Jun 2018 17:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9XwyDLWm5s9hnXlizpZyQEkCUJ2BMYA3f9QIr+h6sbQ=; b=CRG6eH4HTASciNxFMapgc1+5TEeBdxrb7RzXhXgccGuXvSRnfZzCqsHfC5d/B2ujcs 9NntI7S/LQSdoV3dUwxPCrZ6wL+Yzdm0aY8gEaxFF8nY4RJZXY9fQRSu6vilnSclxla6 S8qig2jzE00dGKQ6edL88J6OcSfrjdZ8CDgY2K9j7JXRA9Ai3sn1eaS/s8k6dXfOH067 zqMQgnkqQoaYKFO9ru5Xby0nJy5fx+xFMgi/LdOnwQAjc649PAGcV7SnHA9iUJwi0XZY MXAlrndg94lRRPmgf2reDjL28ZDf2JZBRvYvt5KEz+LHdnUqCIk2WNTehHH0vj0Bo4jb NwiA== 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=9XwyDLWm5s9hnXlizpZyQEkCUJ2BMYA3f9QIr+h6sbQ=; b=X7tCXgBfggDGFxylqOMWPP0MQmcnK6Ff4b+pIcnK3qdsuJsZNiY0Dw3m+Lk1qdwxMq rGlaWO8PB2jqIQW2QtlA63CcAisGUX2tYOn6fpKrxjOqmRCKwLPp+Knk+J7XVkVLjpWV NNu0iXrugFYrChdrwiHvftRquNEGqEs5oV5fxeZimCNt/C/szmwPv5Rs9RcKXAQqk5xW 0b6OrOIzD/2FeE6YsyGhUqleC4v6VXlMmfejry2eNl2vG9oPUk56ZJvHAwtvuzwGS6DB nFIloBuOiaJeFfsJLr1/vizRohBQE4UdArEA5+Bj9Hnr+nxtovF0+PgyINn9NYnDRpVA fmRg== X-Gm-Message-State: APt69E0wpjC/fewFXZqw9KAU8tU2MIg17jUQiHrRpULq3c0F24arArYx M9t806dxCxoQd4slr4rQiWa/nEMF+cpBsc6OBLDI7u2j X-Google-Smtp-Source: ADUXVKKasshrpWGzMoPdQ4FPbeTAuCSveMgJ/YaRbPSQ04I4FE/1SyNyV7qb+RI1T8yPQFPeD6TQv9Z7muGRmFFqQ/4= X-Received: by 2002:a24:7582:: with SMTP id y124-v6mr1101444itc.115.1528764026111; Mon, 11 Jun 2018 17:40:26 -0700 (PDT) MIME-Version: 1.0 From: Justin Uberti Date: Mon, 11 Jun 2018 17:40:14 -0700 Message-ID: To: RTCWeb IETF , yfablet@apple.com, Sean Turner Content-Type: multipart/alternative; boundary="000000000000b97ab3056e671c38" Archived-At: Subject: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 00:40:33 -0000 --000000000000b97ab3056e671c38 Content-Type: text/plain; charset="UTF-8" The Safari team has come up with a clever approach to avoid disclosing private IP addresses for host candidates. As discussed in this WebKit bug , the technique works as follows: 1. Register a random UUID-based mDNS name when ICE gathering starts 2. Replace the private IP address by a "{UUID}.local" string in each host candidate (and set raddr to 0.0.0.0 for other candidates) 3. The other party will do mDNS resolution on any candidate having a .local suffix, similar to how hostnames in candidates are handled in RFC 5245, Section 15.1. This technique is relevant to the IP handling document, as it addresses one of the lesser problems (private IP disclosure) from the overall problem statement. While I don't think this will have a large impact on the document, including the default mode selection, incorporating this technique would result in some moderate changes: - Section 5.1 would mention concealing private IPs in the default case as an explicit goal. - In Section 6, Mode 2 would change from handling out private IPs to handing out mDNS names. - This document would have to describe the technique or point to another document that describes the technique. mmusic-ice-sip-sdp, Section 4.1 seems like a good option, as it already covers how to handle DNS names in ICE candidates. This is a significant improvement and I think we will want to incorporate this suggestion. Is this something we could do as part of this WGLC, or should we look for another option? --000000000000b97ab3056e671c38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The Safari team has come up with a clever approach to avoi= d disclosing private IP addresses for host candidates. As discussed in = this WebKit bug, the technique works as follows:
  1. R= egister a random UUID-based mDNS name when ICE gathering starts
    2. Replace the private IP address by a "{UUID}.local" string in eac= h host candidate (and set raddr to 0.0.0.0 for other candidates)
    The other party will do mDNS resolution on any candidate having a .local = suffix, similar to how hostnames in candidates are handled in RFC 5245, Sec= tion 15.1.
This technique is relevant to the IP handling = document, as it addresses one of the lesser problems (private IP disclosure= ) from the overall problem statement. While I don't think this will hav= e a large impact on the document, including the default mode selection, inc= orporating this technique would result in some moderate changes:
  • Section 5.1 would mention concealing private IPs in the= default case as an explicit goal.
  • In Section 6, Mode 2 would chang= e from handling out private IPs to handing out mDNS names.
  • This doc= ument would have to describe the technique or point to another document tha= t describes the technique. mmusic-ice-sip-sdp, Section 4.1=C2= =A0seems like a good option, as it already covers how to handle DNS names i= n ICE candidates.
This is a significant improvement and I thi= nk we will want to incorporate this suggestion. Is this something we could = do as part of this WGLC, or should we look for another option?
<= /div> --000000000000b97ab3056e671c38-- From nobody Tue Jun 12 04:15:20 2018 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 CA443130E1C for ; Tue, 12 Jun 2018 04:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 d2-jE8mteTvE for ; Tue, 12 Jun 2018 04:15:10 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD36130E13 for ; Tue, 12 Jun 2018 04:15:10 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id v131-v6so22512982wma.1 for ; Tue, 12 Jun 2018 04:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=owd603Xr6Df/78kgF6TGDJaLJAoH6xQEqt3IpKYoCuI=; b=fFAe5Rhe6oZW79QDfx8tr4k7eT24/4AVmzSjDxTg/rqEbesyNpMomiWIF+TSw8Huva 71+iIitenimleIjIsmhRIuZRo0keHIbWVzzqswSjsxNBhB3WrlgViOuyzeGbFsN3iItt ZatEvj10uPmgqlH7R2XjVdoxDKfDsvUWL+VkCvgoAhzI6FiFg4MiZ/CmmCBLYf8A1Spm Ft+yAzYjtwQqbsn1q1wB4JtvofJ2zrPQrScXz/XRzdTxM4Pa1SNV9z9LlgBzYjMSbaBX OU9mQYlS/pI33JeXcCBekt4eAqwn/tZGVVd8lNE3F4cUOa8Qkw+PKv+0vaVygqJKUvhT zPtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=owd603Xr6Df/78kgF6TGDJaLJAoH6xQEqt3IpKYoCuI=; b=gvml37v1o95Z8PitADW1SwHrMZNC4okjRW/YThZi7k38skg1vaMbtDmPheMwQeSx3o OouLBahHP4H1wcSUyaxHMVGk1sg2aHp2rh45zJNZZjJ+oTtymv2B232YJoALiiVYTpc5 LpjmUKfizqtiQ5C6gjazC1w7tvUVG7TYWdGsrF8zPWDLqgbtixWoblQpZwFIGvPEIZtk PNgPbMVrQ9W1zNgWmaRpjHu3RsA44dR4uICCycbgS/JqQvKhzc24tw5kTgqU4AVOy6Ow roUY/M8depYUko6wc885Xwcw15Xoez47kmqecVXCTqMmNSvElmhe50mYjpW4MaDXuyce AD6Q== X-Gm-Message-State: APt69E1tHDJDRY2uj8adZ1Jc79V5d9QNQtuFThMWyuQH+8BxFLp21OKg /ZpMcvVKm6iUHfd5NuNoqZU= X-Google-Smtp-Source: ADUXVKIyeVqLSy8JmRqyj2o/8tzRFIbwERRfaVnSq8+WAUzESoHdX7nT3+IFePnO/JcBqPQmmYS57g== X-Received: by 2002:a1c:6fce:: with SMTP id c75-v6mr1786585wmi.83.1528802108233; Tue, 12 Jun 2018 04:15:08 -0700 (PDT) Received: from ?IPv6:2003:cd:6f1f:4900:c556:a374:c7f2:7e61? (p200300CD6F1F4900C556A374C7F27E61.dip0.t-ipconnect.de. [2003:cd:6f1f:4900:c556:a374:c7f2:7e61]) by smtp.gmail.com with ESMTPSA id b204-v6sm286227wmh.22.2018.06.12.04.15.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 04:15:07 -0700 (PDT) To: rtcweb@ietf.org References: From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; prefer-encrypt=mutual; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Cc: Justin Uberti , yfablet@apple.com Message-ID: <436903fe-1ec7-e595-7733-0cc2f9c3a53d@gmail.com> Date: Tue, 12 Jun 2018 13:15:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 11:15:17 -0000 On 12.06.2018 02:40, Justin Uberti wrote: > The Safari team has come up with a clever approach to avoid disclosing > private IP addresses for host candidates. As discussed in this WebKit bug > , the technique works as > follows: > > 1. Register a random UUID-based mDNS name when ICE gathering starts > 2. Replace the private IP address by a "{UUID}.local" string in each > host candidate (and set raddr to 0.0.0.0 for other candidates) > 3. The other party will do mDNS resolution on any candidate having a > .local suffix, similar to how hostnames in candidates are handled in RFC > 5245, Section 15.1. > > This technique is relevant to the IP handling document, as it addresses one > of the lesser problems (private IP disclosure) from the overall problem > statement. While I don't think this will have a large impact on the > document, including the default mode selection, incorporating this > technique would result in some moderate changes: > > - Section 5.1 would mention concealing private IPs in the default case > as an explicit goal. > - In Section 6, Mode 2 would change from handling out private IPs to > handing out mDNS names. IMHO that would create a large gap between mode 1 and 2. Instead, I would suggest using mDNS *in addition* to mode 2 and 3. For mode 2 this would mean that only the default private IP is being transmitted but all other interfaces are hidden by UUID-based hostnames. For mode 3, all private IPs are hidden by UUID-based hostnames. > - This document would have to describe the technique or point to another > document that describes the technique. mmusic-ice-sip-sdp, Section 4.1 > > seems > like a good option, as it already covers how to handle DNS names in ICE > candidates. Since this will be useful for ORTC as well, I would not tie that to an SDP-specific document. > This is a significant improvement and I think we will want to incorporate > this suggestion. Is this something we could do as part of this WGLC, or > should we look for another option? I haven't seen a better solution than mDNS so far to prevent IPs from leaking and I would appreciate having this to fix the following issues: - Allowing browsers to use stricter modes by default without significant drawbacks, - establishing direct connections even in case no "consent" has been given because the devices are in fact in the same network segment (with the exception of mode 4), and - use cases where gUM cannot be applied and no other way of expressing consent has been provided (which is the status quo). Cheers Lennart From nobody Tue Jun 12 08:39:43 2018 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 D4B6E130E6A for ; Tue, 12 Jun 2018 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 IL5bqxznSKHd for ; Tue, 12 Jun 2018 08:39:35 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370DF130E61 for ; Tue, 12 Jun 2018 08:39:35 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id r24-v6so28573926ioh.9 for ; Tue, 12 Jun 2018 08:39:35 -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=Wtt4Q5D57fpJrkfF7WLrkNHrPgJPIOodf4E78XV0ncM=; b=XcG3uzIprRJqpgPPonEOlj8zZqjr6m5rtTmoGv2Xs9S9JsFNtCAcEKaaEXDCux4w2o MUhuuAhPI7qO5sDdaX0AHifpPLxxMN0D5QDssV9QiKEMmnHsiw/JWiyNBByU1mGLhHTJ /bI/nUH/qcQ2pEkUkQ3x8L4WuyhR99amCf5JxCLomH7yEm+1w6U0dNxeWlOEpei5eEpQ 6mY7RNfE4HZREhKHfYjm4At3ZmJxU1Rf/oZifdMW37ZZyLi+q363XBmJ8gEPuT46xi1m qHfdW+eZXeHtKqgRm23Cfd7Wo7Z9qcxdGgUTNUwqKaHrMAFQz/g4EHMQDgXyXghXW68g UkoA== 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=Wtt4Q5D57fpJrkfF7WLrkNHrPgJPIOodf4E78XV0ncM=; b=Ku/1OgNp5NHDCQ4U6p7IJmtIQtmGeFwYk5Q5MRokDOwosND0jjS0tNOOP8tR+S5a7H eq2Ke/Mjk1/F+1z7cgFdF+FjE/8JsBqXRq5KrIJMVMY9uGDu0021MIFTpQUZtjm8DZP5 /othblJskiC2dqELEpDuM2Lgii0mB2U9Cif9nHHLCzW0PiqX2h/4ItmicB7JmtS+lg0A KuzY5p898EbxttWBOuQp8bYdBNOQSo6360DEwKO5twR1cYguKNkDQB2ELgzC7VRpYwqP lNpnfL7PyjChFlDGMqO5qye3ggOQG27KNJ56TcSVXlNflzfgSUNiFYvt2lfrujtmBjgP e61A== X-Gm-Message-State: APt69E2Un9sPEqJebpMAj4Ok0LRFxJDQ2vVEWqLMbKHcbWc/iB06DWtx Wzhomuf+WJuHcsUSnVGRDKd9x5YLAcWIX13Lndj79g== X-Google-Smtp-Source: ADUXVKJKZSFRczNxE8ahyi1Zsl7qjWMPLujxUgB3fnIENEz+YcnltdF3ntJyI7zx3W0tjQJPGXndtNNHH4khg1cn94k= X-Received: by 2002:a6b:3245:: with SMTP id y66-v6mr944236ioy.87.1528817974072; Tue, 12 Jun 2018 08:39:34 -0700 (PDT) MIME-Version: 1.0 References: <436903fe-1ec7-e595-7733-0cc2f9c3a53d@gmail.com> In-Reply-To: <436903fe-1ec7-e595-7733-0cc2f9c3a53d@gmail.com> From: Justin Uberti Date: Tue, 12 Jun 2018 08:39:21 -0700 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF , yfablet@apple.com Content-Type: multipart/alternative; boundary="00000000000045f3fd056e73ac1f" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 15:39:39 -0000 --00000000000045f3fd056e73ac1f Content-Type: text/plain; charset="UTF-8" On Tue, Jun 12, 2018 at 4:15 AM Lennart Grahl wrote: > On 12.06.2018 02:40, Justin Uberti wrote: > > The Safari team has come up with a clever approach to avoid disclosing > > private IP addresses for host candidates. As discussed in this WebKit bug > > , the technique works as > > follows: > > > > 1. Register a random UUID-based mDNS name when ICE gathering starts > > 2. Replace the private IP address by a "{UUID}.local" string in each > > host candidate (and set raddr to 0.0.0.0 for other candidates) > > 3. The other party will do mDNS resolution on any candidate having a > > .local suffix, similar to how hostnames in candidates are handled in > RFC > > 5245, Section 15.1. > > > > This technique is relevant to the IP handling document, as it addresses > one > > of the lesser problems (private IP disclosure) from the overall problem > > statement. While I don't think this will have a large impact on the > > document, including the default mode selection, incorporating this > > technique would result in some moderate changes: > > > > - Section 5.1 would mention concealing private IPs in the default case > > as an explicit goal. > > - In Section 6, Mode 2 would change from handling out private IPs to > > handing out mDNS names. > > IMHO that would create a large gap between mode 1 and 2. Instead, I > would suggest using mDNS *in addition* to mode 2 and 3. For mode 2 this > would mean that only the default private IP is being transmitted but all > other interfaces are hidden by UUID-based hostnames. For mode 3, all > private IPs are hidden by UUID-based hostnames. > I don't see a clear benefit of doing that. If you have the mDNS hostnames, you don't need the private IPs. Or, looking at it a different way, if mode 3 is as you describe, why would we ever use mode 2? > > > - This document would have to describe the technique or point to > another > > document that describes the technique. mmusic-ice-sip-sdp, Section 4.1 > > < > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1> > > seems > > like a good option, as it already covers how to handle DNS names in > ICE > > candidates. > > Since this will be useful for ORTC as well, I would not tie that to an > SDP-specific document. > ORTC already depends on this document (it explains ICE restarts, amongst other things), so I don't see this as an issue. The nice thing about this document is that it's nearing last call, but we still have time to make edits like the ones suggested. > > > This is a significant improvement and I think we will want to incorporate > > this suggestion. Is this something we could do as part of this WGLC, or > > should we look for another option? > I haven't seen a better solution than mDNS so far to prevent IPs from > leaking and I would appreciate having this to fix the following issues: > > - Allowing browsers to use stricter modes by default without significant > drawbacks, > - establishing direct connections even in case no "consent" has been > given because the devices are in fact in the same network segment (with > the exception of mode 4), and > - use cases where gUM cannot be applied and no other way of expressing > consent has been provided (which is the status quo). > Noted. Thanks. --00000000000045f3fd056e73ac1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Jun 12, 2018 at 4:15 AM Lennart Grahl <lennart.grahl@gmail.com> wrote:
On 12.06.2018 02:40, Justin Uberti wrote:
> The Safari team has come up with a clever approach to avoid disclosing=
> private IP addresses for host candidates. As discussed in this WebKit = bug
> <https://bugs.webkit.org/show_bug.cgi?id= =3D174500>, the technique works as
> follows:
>
>=C2=A0 =C2=A0 1. Register a random UUID-based mDNS name when ICE gather= ing starts
>=C2=A0 =C2=A0 2. Replace the private IP address by a "{UUID}.local= " string in each
>=C2=A0 =C2=A0 host candidate (and set raddr to 0.0.0.0 for other candid= ates)
>=C2=A0 =C2=A0 3. The other party will do mDNS resolution on any candida= te having a
>=C2=A0 =C2=A0 .local suffix, similar to how hostnames in candidates are= handled in RFC
>=C2=A0 =C2=A0 5245, Section 15.1.
>
> This technique is relevant to the IP handling document, as it addresse= s one
> of the lesser problems (private IP disclosure) from the overall proble= m
> statement. While I don't think this will have a large impact on th= e
> document, including the default mode selection, incorporating this
> technique would result in some moderate changes:
>
>=C2=A0 =C2=A0 - Section 5.1 would mention concealing private IPs in the= default case
>=C2=A0 =C2=A0 as an explicit goal.
>=C2=A0 =C2=A0 - In Section 6, Mode 2 would change from handling out pri= vate IPs to
>=C2=A0 =C2=A0 handing out mDNS names.

IMHO that would create a large gap between mode 1 and 2. Instead, I
would suggest using mDNS *in addition* to mode 2 and 3. For mode 2 this
would mean that only the default private IP is being transmitted but all other interfaces are hidden by UUID-based hostnames. For mode 3, all
private IPs are hidden by UUID-based hostnames.

I don't see a clear benefit of doing that. If you have the mDN= S hostnames, you don't need the private IPs.

O= r, looking at it a different way, if mode 3 is as you describe, why would w= e ever use mode 2?=C2=A0

>=C2=A0 =C2=A0 - This document would have to describe the technique or p= oint to another
>=C2=A0 =C2=A0 document that describes the technique. mmusic-ice-sip-sdp= , Section 4.1
>=C2=A0 =C2=A0 <https:= //tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1><= br> > seems
>=C2=A0 =C2=A0 like a good option, as it already covers how to handle DN= S names in ICE
>=C2=A0 =C2=A0 candidates.

Since this will be useful for ORTC as well, I would not tie that to an
SDP-specific document.

ORTC already dep= ends on this document (it explains ICE restarts, amongst other things), so = I don't see this as an issue. The nice thing about this document is tha= t it's nearing last call, but we still have time to make edits like the= ones suggested.

> This is a significant improvement and I think we will want to incorpor= ate
> this suggestion. Is this something we could do as part of this WGLC, o= r
> should we look for another option?
I haven't seen a better solution than mDNS so far to prevent IPs from leaking and I would appreciate having this to fix the following issues:

- Allowing browsers to use stricter modes by default without significant drawbacks,
- establishing direct connections even in case no "consent" has b= een
given because the devices are in fact in the same network segment (with
the exception of mode 4), and
- use cases where gUM cannot be applied and no other way of expressing
consent has been provided (which is the status quo).
<= br>
Noted. Thanks.
=C2=A0
--00000000000045f3fd056e73ac1f-- From nobody Tue Jun 12 09:34:42 2018 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 90A21130EDB for ; Tue, 12 Jun 2018 09:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h96dTJqkgasA for ; Tue, 12 Jun 2018 09:34:27 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8684D129C6B for ; Tue, 12 Jun 2018 09:34:26 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id f16-v6so24781861wrm.3 for ; Tue, 12 Jun 2018 09:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b265TlYZgVwuGFn3DHbbQVwbp4SLEIOkG36nzOK16G8=; b=JbuwuXrDap+nJtAy+YTJ8x6RUGulHp6fsLwSOZASc3mcSDDCBQLJyO60wUAO8S0DK0 b0MTGA7w5LI2i5HtziS31gevQivESI/jN/Srk2ByE7flcM6H5mHlMeX6dW8YDFFE4p2+ DHGUxPK8kAeZ/NaM1/SY+XPKmizEVNE4xFu3kdbjEwxoNxSBz3R2Wnvptb8/ynFw79Jv XOSZ2JP+3ey1otMYORSjwf1NvRXcT/VAd+YgOLGY7wlKYfvptnXM4WRM/9N/3wL/oI7I hSZAeK7VEyA8Ao8v0r2qvZanrf3p9q162dOOTOzKbwBC/rxrYx73JWc0YkcdyPveHgiF OWCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=b265TlYZgVwuGFn3DHbbQVwbp4SLEIOkG36nzOK16G8=; b=IESWa16kcLOxcbqYipkx0vNTWxQq5XJZTwcHXVgGKGPaMLxrHG9A/K/B74Z1pMoeFB TnY+jtjlRvesp9Vh9sDuFRLFc7SxEhSSvJ/8WTUIybbfbdhi04GvA2p9dEsKQL4IIJH4 k19jm8Bzxs1sJ7AyH9J9clUL5TzbGIw2sOgYQAD1osqHHa1YOk+cNp4uFHmkufrBTvkJ /icwp3gy3qDnUz8lKQHKdWJSofabxazn7XzkQRYaBPg0ScPnm1Z009Jj67+UfyFqfENP ix28Yz3oHBFghbqglc9LwuO5O2senQ3Stt1C6fbnINZwuA5ClVTfKOy6bObBhHRUBa+o +/YQ== X-Gm-Message-State: APt69E00r0F11MKBFovWni5kAR1PK59AEKkYHDgfvOk9BwggtZ2ZjD54 0dZ0/ejjkorJFNGQxsHkFt4= X-Google-Smtp-Source: ADUXVKJpnsUadzJPPNQeLV0jWndDp+Zes2WVumlPs4uw8JNPXqkA6lO+wFQUktxzYR0IWvb13/t32Q== X-Received: by 2002:adf:ef4f:: with SMTP id c15-v6mr824242wrp.182.1528821265105; Tue, 12 Jun 2018 09:34:25 -0700 (PDT) Received: from ?IPv6:2003:cd:6f1f:4900:c556:a374:c7f2:7e61? (p200300CD6F1F4900C556A374C7F27E61.dip0.t-ipconnect.de. [2003:cd:6f1f:4900:c556:a374:c7f2:7e61]) by smtp.gmail.com with ESMTPSA id b190-v6sm1345160wma.24.2018.06.12.09.34.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 09:34:24 -0700 (PDT) To: Justin Uberti Cc: RTCWeb IETF , yfablet@apple.com References: <436903fe-1ec7-e595-7733-0cc2f9c3a53d@gmail.com> From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; prefer-encrypt=mutual; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: Date: Tue, 12 Jun 2018 18:34:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 16:34:36 -0000 On 12.06.2018 17:39, Justin Uberti wrote: > On Tue, Jun 12, 2018 at 4:15 AM Lennart Grahl > wrote: > >> On 12.06.2018 02:40, Justin Uberti wrote: >>> The Safari team has come up with a clever approach to avoid disclosing >>> private IP addresses for host candidates. As discussed in this WebKit bug >>> , the technique works as >>> follows: >>> >>> 1. Register a random UUID-based mDNS name when ICE gathering starts >>> 2. Replace the private IP address by a "{UUID}.local" string in each >>> host candidate (and set raddr to 0.0.0.0 for other candidates) >>> 3. The other party will do mDNS resolution on any candidate having a >>> .local suffix, similar to how hostnames in candidates are handled in >> RFC >>> 5245, Section 15.1. >>> >>> This technique is relevant to the IP handling document, as it addresses >> one >>> of the lesser problems (private IP disclosure) from the overall problem >>> statement. While I don't think this will have a large impact on the >>> document, including the default mode selection, incorporating this >>> technique would result in some moderate changes: >>> >>> - Section 5.1 would mention concealing private IPs in the default case >>> as an explicit goal. >>> - In Section 6, Mode 2 would change from handling out private IPs to >>> handing out mDNS names. >> >> IMHO that would create a large gap between mode 1 and 2. Instead, I >> would suggest using mDNS *in addition* to mode 2 and 3. For mode 2 this >> would mean that only the default private IP is being transmitted but all >> other interfaces are hidden by UUID-based hostnames. For mode 3, all >> private IPs are hidden by UUID-based hostnames. >> > > I don't see a clear benefit of doing that. If you have the mDNS hostnames, > you don't need the private IPs. > > Or, looking at it a different way, if mode 3 is as you describe, why would > we ever use mode 2 Mode 2 with mDNS hostnames exclusively would only work when the devices are in the same network segment. Anything that stops multicast would require the use of a STUN server. That makes mode 2 a lot less powerful. Whereas mode 2 as of today and with my suggestion does work without a STUN server, even if you are not in the same network segment. Think of IPv6 global addresses or corporate networks with several private networks. And exposing an IP is still useful for establishing a connection with an implementation that doesn't support mDNS (not even resolving). > >> >>> - This document would have to describe the technique or point to >> another >>> document that describes the technique. mmusic-ice-sip-sdp, Section 4.1 >>> < >> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1> >>> seems >>> like a good option, as it already covers how to handle DNS names in >> ICE >>> candidates. >> >> Since this will be useful for ORTC as well, I would not tie that to an >> SDP-specific document. >> > > ORTC already depends on this document (it explains ICE restarts, amongst > other things), so I don't see this as an issue. The nice thing about this > document is that it's nearing last call, but we still have time to make > edits like the ones suggested. Fair enough. Cheers Lennart From nobody Tue Jun 12 10:32:37 2018 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 C861A130F81 for ; Tue, 12 Jun 2018 10:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 Ym93vN3RVRlP for ; Tue, 12 Jun 2018 10:32:32 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC9C130F7B for ; Tue, 12 Jun 2018 10:32:32 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id e15-v6so347921iog.1 for ; Tue, 12 Jun 2018 10:32:32 -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=Cm65J7JpRVKVXCpGKdlVHYjgDXIjmJP1CRnuxQmtFYw=; b=PLG5771p5T7z3L+nJ4G6iAFdR6FqRvxcx5WpapspSE8zSCYXGYx32o2h0Lxjsu8S8o 9okN2wI73/y5OeIizxXdb87JXG465zjHOK6KwTxsYBg7W7Ld/cnt3upQoUQoVq4Btwv3 QJ/SE6QYMOLWi44PBtQ/+jkeysWjTt3jrk0+XvVJ1COTEEDx5w7oSrY4gh6I8Fg3fTXl JAIwpakqhxwZ5dzgd5ixaotglmaGF72JIvZ/vlkKE2Kt+vSde1xEjwlhB+kEA+uKhWoI wLTbXmvrkbl1ROa2p3sG/S/X6z82NHq644DkKzlvOVt+5C/d8+bhz56hbZCrN8FzTfsV /1pA== 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=Cm65J7JpRVKVXCpGKdlVHYjgDXIjmJP1CRnuxQmtFYw=; b=Vn3kw8yZBzxY/UNlnkpg/kv8UNREGLCXuoUmogRd0dSvGHtknEjkR1FPih6EoTxhMx vRa84/Q77p263gtZTWkcHSMLKjDzXHydt2cfJooA6xN9LJZQ9YGnx/Z4XlCmmhWXoXY1 7w4VF6DOr5OdSFgB5fTqQHDUlAMdL9GsSDYbXeQN+zhsH7encso0TiWkVyel1CEQspsg YuTKwGGv0EXs/nyxOt2gUG9yhclg2AjC6/B0kHj/eguhg2KySn92bxdU7mDfAeCE2SCC TFJw4pwxbrvlsPc3skznHeK0dg4nv1R8HjkU3EO6nKOjsVb2KT77y1rNLx6RNjQyHQMx Qitw== X-Gm-Message-State: APt69E0+YNzfzOI5acS5f7f7+YM30rMYdvBot5seFMvAJx6G0gxyaBBW zXO3faEUjFOZhwKvEkECvhV5jHGDI1VIv9SytgCmWLma X-Google-Smtp-Source: ADUXVKIUTXDIHqe4bBCUoTTJJv15kfXfCkiB26k5vGHq3Hq3wcf+tWBjbpkri90MGt7jHIhI5xEDFsEfCxt70hSq1tU= X-Received: by 2002:a6b:e907:: with SMTP id u7-v6mr1500505iof.38.1528824750787; Tue, 12 Jun 2018 10:32:30 -0700 (PDT) MIME-Version: 1.0 References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> In-Reply-To: From: Justin Uberti Date: Tue, 12 Jun 2018 10:32:16 -0700 Message-ID: To: RTCWeb IETF Cc: rtcweb-chairs@ietf.org, yfablet@apple.com Content-Type: multipart/alternative; boundary="000000000000328ba2056e7540e3" Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 17:32:36 -0000 --000000000000328ba2056e7540e3 Content-Type: text/plain; charset="UTF-8" Checking in on this. Are we going to have a session at IETF 102? On Thu, May 31, 2018 at 6:41 AM Tim Hollebeek wrote: > I agree. > > -Tim > > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > Sent: Thursday, May 31, 2018 4:11 AM > > To: rtcweb@ietf.org > > Cc: rtcweb-chairs@ietf.org > > Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 > > > > Hi, > > > > I think we need to have discussions (in SOME forum) about the Identity > > attribute. Because, in addition to the things that need to be clarified, > based on > > the comments it seem like there are opinions/understandings that > contradict > > what is currently written in the draft. > > > > Regards, > > > > Christer > > > > > > On 30/05/18 16:18, "rtcweb on behalf of IETF Meeting Session Request > Tool" > > wrote: > > > > > > > > > > >Sean Turner, a chair of the rtcweb working group, indicated that the > > >rtcweb working group does not plan to hold a session at IETF 102. > > > > > >This message was generated and sent by the IETF Meeting Session Request > > >Tool. > > > > > > > > >_______________________________________________ > > >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 > --000000000000328ba2056e7540e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Checking in on this. Are we going to have a session at IET= F 102?=C2=A0

On Thu, M= ay 31, 2018 at 6:41 AM Tim Hollebeek <tim.hollebeek@digicert.com> wrote:
=
I agree.

-Tim

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer
> Holmberg
> Sent: Thursday, May 31, 2018 4:11 AM
> To: rtcweb@ietf.o= rg
> Cc: rtcweb= -chairs@ietf.org
> Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102
>
> Hi,
>
> I think we need to have discussions (in SOME forum) about the Identity=
> attribute. Because, in addition to the things that need to be clarifie= d,
based on
> the comments it seem like there are opinions/understandings that
contradict
> what is currently written in the draft.
>
> Regards,
>
> Christer
>
>
> On 30/05/18 16:18, "rtcweb on behalf of IETF Meeting Session Requ= est Tool"
> <rtcwe= b-bounces@ietf.org on behalf of session-request@ietf.org> wrote:
>
> >
> >
> >Sean Turner, a chair of the rtcweb working group, indicated that t= he
> >rtcweb working group does not plan to hold a session at IETF 102.<= br> > >
> >This message was generated and sent by the IETF Meeting Session Re= quest
> >Tool.
> >
> >
> >_______________________________________________
> >rtcweb mailing list
> >rtcweb@ietf.o= rg
> >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
--000000000000328ba2056e7540e3-- From nobody Tue Jun 12 10:33:08 2018 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 64F72130F7F for ; Tue, 12 Jun 2018 10:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 5EyyFgVSlfdf for ; Tue, 12 Jun 2018 10:33:01 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E354C130F79 for ; Tue, 12 Jun 2018 10:33:00 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id r24-v6so310483ioh.9 for ; Tue, 12 Jun 2018 10:33:00 -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=F/sfrDtfkyQG/YbpwGjcy+u1QqBQbb+9eO/6uQCmWX0=; b=eT45OFzzC9zUH2rW4+uo8H9WugWIypZVkX/6vA8Ob7ETyQpjU9O/rE2xTqLCPEncCK dWVp45XwVW2vElu3X3/BD/b8NYBDQ/4h+N0LZ6AXgwbOEegi/of4X4Vn/2TCm8VluES4 hnhO1rWXZS4+mGYAUl9GpQ7Cz9MGc6v+c2fZvRuVyVjY6MOoApdcOf9Rb1oW5A9viPgR rsJUm1stBi2ZdevXQn1Y9M0I0Ed7Umn4ZTlqygxeFU92WUL6yqEAOCLhXGsZTjwkxAf0 d8ZPUCFMfNoSFXEEAUlWTV5/8Uqinu9wuJJARvByNJ4YEyf8f7+XH0t+TxXnmjnGFuQ+ s0cw== 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=F/sfrDtfkyQG/YbpwGjcy+u1QqBQbb+9eO/6uQCmWX0=; b=UycRIOUepi+8RXvwU5URyhDmSE0POgKo1sK9VJzVtw4xB5pWhVFpTRet5jUvX1fh08 GP548bcnwd6TpXCrbsUdNMdbfOL31dZxCl53/Ep2piA3xTPqdpdHdGgXJktpWdFME//0 tTp54I0d7bx7wTW7f7NMlygEWQJlrL0Rz1VJ5SvcivgYTDoXbFXudP+09+DRRt3xeBFD lu+skFpWzKW15zOvzUAgGAhwg3L778BK3G6gLN2PcMxoFS+vx3yLohzcgaYC0QoRXS0l H5/nMTAD/D6AdEuaYti/blmBt1fYNUpQ6hDWj/+PgCr92jVL2/2Mx9DJpXI5bNXQlLPk iyCQ== X-Gm-Message-State: APt69E0E+PQHnQFMcGlMki3DxtNQkYG0lK4o5gm/+obT35tQl9qmjW2q zaCpwbFTPal58qTuiCGakYt4vO58VSsNCRM1JOeEJa8R X-Google-Smtp-Source: ADUXVKIf0SgZbh35R8T5dyx/RemuN23aiBrywoDQblSYz9YJ2mt2JnkK1NGlDoh0MA77z1g/VYfoj1el27ZIXnnEcNA= X-Received: by 2002:a6b:9156:: with SMTP id t83-v6mr1513593iod.32.1528824779749; Tue, 12 Jun 2018 10:32:59 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> <574256E1-7AF4-4E25-9462-04B4B599C801@mozilla.com> <6DF5B202-803F-452B-B17E-5346F4C6FB4B@iii.ca> <0051C70E-362F-4E20-9DF8-9290DD4EB989@mozilla.com> <9216A555-846F-4E87-9D8B-2F2014B598FC@sn3rd.com> In-Reply-To: <9216A555-846F-4E87-9D8B-2F2014B598FC@sn3rd.com> From: Justin Uberti Date: Tue, 12 Jun 2018 10:32:47 -0700 Message-ID: To: Sean Turner Cc: RTCWeb IETF , Nils Ohlmeier Content-Type: multipart/alternative; boundary="000000000000eca1d9056e754145" Archived-At: Subject: Re: [rtcweb] Nils comments [Was: WGLC for draft-ietf-rtcweb-ip-handling] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 17:33:05 -0000 --000000000000eca1d9056e754145 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Assuming no further comments, will land this today and publish a new version. On Mon, Jun 4, 2018 at 4:28 AM Sean Turner wrote: > Let=E2=80=99s let this simmer until June 11th, but then we ought to merge= it. > > spt > > > On Jun 4, 2018, at 06:11, Nils Ohlmeier wrote: > > > > I reviewed the diff and I think it helps to clarify this. > > > > Best > > Nils > > > >> On Jun 3, 2018, at 20:48, Justin Uberti 40google.com@dmarc.ietf.org> wrote: > >> > >> Agreed. Created https://github.com/juberti/draughts/pull/102 that adds > a high-level discussion of enterprise TURN servers, hopefully enough to > clarify the situation. > >> > >> If you think "browser-provided TURN server" is a clearer term, I could > use that instead. > >> > >> > >> > >> On Mon, May 14, 2018 at 6:21 AM Cullen Jennings wrote: > >> > >> > >>> On May 11, 2018, at 11:08 AM, Justin Uberti 40google..com@dmarc.ietf.org> wrote: > >>> > >>> Thanks for the PR. I spent some time thinking about this and > ultimately concluded that more significant changes to the document will b= e > necessary if it is to prescribe how a browser-provided TURN server should > be handled, essentially incorporating much of the guidance from > https://tools.ietf.org/html/draft-ietf-rtcweb-return-02 > >>> > >>> For example, candidates produced from the TURN server should not have > raddr/rport set; interactions between the browser-provided and any > application-provided TURN server need to be described; the question of > whether local candidates should be provided needs to be considered. > >>> > >>> As such, I see 3 paths forward here: > >>> a) Leave the document as-is. While leaving some ambiguity on this > topic, the eventual (hopefully) publication of RETURN should clarify > things, at which point we can publish a -bis. > >>> b) Discuss the general concept of browser-provided TURN servers, but > mention that this is an area of further study, and give some guidance bas= ed > on our current understanding. That is, explain how the existing modes wou= ld > work in the presence of a browser-provided TURN server. > >>> c) Restore the reference to RETURN and progress the RETURN doc. > >>> > >>> Overall, I don't expect the mode recommendations to change in the > presence of a browser- or network- provided TURN server, so I think any > changes here will be almost entirely additive. > >>> > >>> Thoughts? > >> > >> > >> I lean towards option B as it sounds like it meets our current needs > and allows us to separate out the harder stuff to do later. > >> > >> > >> _______________________________________________ > >> 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 > > --000000000000eca1d9056e754145 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Assuming no further comments, will land this today and pub= lish a new version.

On Mon, Jun 4, 2018 at 4:28 AM Sean Turner <sean@sn3rd.com> wrote:
Let=E2=80=99s let this simmer until June 11th, but then we ought to merg= e it.

spt

> On Jun 4, 2018, at 06:11, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
>
> I reviewed the diff and I think it helps to clarify this.
>
> Best
>=C2=A0 =C2=A0Nils
>
>> On Jun 3, 2018, at 20:48, Justin Uberti <juberti=3D40google.com@dmarc.iet= f.org> wrote:
>>
>> Agreed. Created https://github.com/juberti/drau= ghts/pull/102 that adds a high-level discussion of enterprise TURN serv= ers, hopefully enough to clarify the situation.
>>
>> If you think "browser-provided TURN server" is a clearer= term, I could use that instead.
>>
>>
>>
>> On Mon, May 14, 2018 at 6:21 AM Cullen Jennings <fluffy@iii.ca> wrote:
>>
>>
>>> On May 11, 2018, at 11:08 AM, Justin Uberti <juberti=3D40google..com= @dmarc.ietf.org> wrote:
>>>
>>> Thanks for the PR. I spent some time thinking about this and u= ltimately concluded that more significant changes to the document will be n= ecessary if it is to prescribe how a browser-provided TURN server should be= handled, essentially incorporating much of the guidance from https://tools.ietf.org/html/draft-ietf-rtcweb-return-02
>>>
>>> For example, candidates produced from the TURN server should n= ot have raddr/rport set; interactions between the browser-provided and any = application-provided TURN server need to be described; the question of whet= her local candidates should be provided needs to be considered.
>>>
>>> As such, I see 3 paths forward here:
>>> a) Leave the document as-is. While leaving some ambiguity on t= his topic, the eventual (hopefully) publication of RETURN should clarify th= ings, at which point we can publish a -bis.
>>> b) Discuss the general concept of browser-provided TURN server= s, but mention that this is an area of further study, and give some guidanc= e based on our current understanding. That is, explain how the existing mod= es would work in the presence of a browser-provided TURN server.
>>> c) Restore the reference to RETURN and progress the RETURN doc= .
>>>
>>> Overall, I don't expect the mode recommendations to change= in the presence of a browser- or network- provided TURN server, so I think= any changes here will be almost entirely additive.
>>>
>>> Thoughts?
>>
>>
>> I lean towards option B as it sounds like it meets our current nee= ds and allows us to separate out the harder stuff to do later.
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000eca1d9056e754145-- From nobody Tue Jun 12 11:38:29 2018 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 C3F98130E93 for ; Tue, 12 Jun 2018 11:38:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRjeFAHZCdH1 for ; Tue, 12 Jun 2018 11:38:20 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB3C130E7F for ; Tue, 12 Jun 2018 11:38:19 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id r83-v6so9717859vkf.6 for ; Tue, 12 Jun 2018 11:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X/Ntq+kCdTJ7LmHdKLtrBFzjP8bPHrPTgOvwYwjLeNA=; b=ZPKL8pe7jpu4DLgr0v2M1uk/1VX7QbNCEFeSFGIheHma0glQcQykgO5Zz9K8nNzAwV Z+OzYxrO6atGvHyXQOSZZk/Kn+x2rWIwBC9AwxANRyLQfBE2Vq//27lZHj5C0GRbAm3S 8+9Yzs+svW4vN09I1RWMpPUtOa/Z/NsUO5HeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X/Ntq+kCdTJ7LmHdKLtrBFzjP8bPHrPTgOvwYwjLeNA=; b=NxGNFKp0qsHpPQm0nAVBV/eDVemCH3V9YtuxQZ4xXtWLx/Y1M1UUe8Bo1iYPWJjvEN nIZ0BGFvqjL3OP7WeNCIvTVC9j9GCIUhJeACzUKbaaLvdVHWzK3O6s28f0nGvKDgmCWJ ydu26g9kYHZpHqQRX5ToRS6HmE3MmTcfj7cqA78Dsaltawn9Xl08UhZhKaP8f5bZnxtq j8VsXVfaKkiJxRQyPQ8XMZmmLKkTxUnXry6kDWNsKN/UwUBr7pm3sfblg9eGkjNtuzeO IagLbYPEMzFMIAYGndaeGyiZDJBk124x3QKYMRNBuScOZAA0b3pshGUdDzQjZeTJPCjz /9ZA== X-Gm-Message-State: APt69E2duYZP1fu8pedgLF+iGpqM+wa0wyhWF/TvPcpcpoeHQcsalg3f 1xclSJWcWBZ7YZV3f2RKWMnDJN2+Iz1uA6qW6VKULQ== X-Google-Smtp-Source: ADUXVKKKRW1ivykV0uJbs8mVrG93gL/z8gYt/j+OFafOP9B1bMhEpTShQSZ3U7JWZzl7wPga/m8Eam3Dbn7wdhmBPPw= X-Received: by 2002:a1f:8c96:: with SMTP id o144-v6mr1050649vkd.94.1528828698641; Tue, 12 Jun 2018 11:38:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:1981:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 11:37:57 -0700 (PDT) In-Reply-To: References: From: Joseph Lorenzo Hall Date: Tue, 12 Jun 2018 14:37:57 -0400 Message-ID: To: Justin Uberti Cc: RTCWeb IETF , yfablet@apple.com, Sean Turner Content-Type: multipart/alternative; boundary="000000000000815f66056e762b9e" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 18:38:24 -0000 --000000000000815f66056e762b9e Content-Type: text/plain; charset="UTF-8" inveterate lurker here; I'd definitely +1 getting this in during the WGLC for this document if there are no strong objections. On Mon, Jun 11, 2018 at 8:40 PM, Justin Uberti < juberti=40google.com@dmarc.ietf.org> wrote: > The Safari team has come up with a clever approach to avoid disclosing > private IP addresses for host candidates. As discussed in this WebKit bug > , the technique works as > follows: > > 1. Register a random UUID-based mDNS name when ICE gathering starts > 2. Replace the private IP address by a "{UUID}.local" string in each > host candidate (and set raddr to 0.0.0.0 for other candidates) > 3. The other party will do mDNS resolution on any candidate having a > .local suffix, similar to how hostnames in candidates are handled in RFC > 5245, Section 15.1. > > This technique is relevant to the IP handling document, as it addresses > one of the lesser problems (private IP disclosure) from the overall problem > statement. While I don't think this will have a large impact on the > document, including the default mode selection, incorporating this > technique would result in some moderate changes: > > - Section 5.1 would mention concealing private IPs in the default case > as an explicit goal. > - In Section 6, Mode 2 would change from handling out private IPs to > handing out mDNS names. > - This document would have to describe the technique or point to > another document that describes the technique. mmusic-ice-sip-sdp, > Section 4.1 > seems > like a good option, as it already covers how to handle DNS names in ICE > candidates. > > This is a significant improvement and I think we will want to incorporate > this suggestion. Is this something we could do as part of this WGLC, or > should we look for another option? > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --000000000000815f66056e762b9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
inveterate lurker here; I'd definitely +1 getting this= in during the WGLC for this document if there are no strong objections.
On Mon, Jun 11, 2018= at 8:40 PM, Justin Uberti <juberti=3D40google.com@dm= arc.ietf.org> wrote:
The Safari team has come up with a clever approach to avoid disc= losing private IP addresses for host candidates. As discussed in this W= ebKit bug, the technique works as follows:
  1. Registe= r a random UUID-based mDNS name when ICE gathering starts
  2. Repla= ce the private IP address by a "{UUID}.local" string in each host= candidate (and set raddr to 0.0.0.0 for other candidates)
  3. The = other party will do mDNS resolution on any candidate having a .local suffix= , similar to how hostnames in candidates are handled in RFC 5245, Section 1= 5.1.
This technique is relevant to the IP handling docume= nt, as it addresses one of the lesser problems (private IP disclosure) from= the overall problem statement. While I don't think this will have a la= rge impact on the document, including the default mode selection, incorpora= ting this technique would result in some moderate changes:
  • Section 5.1 would mention concealing private IPs in the defau= lt case as an explicit goal.
  • In Section 6, Mode 2 would change from= handling out private IPs to handing out mDNS names.
  • This document = would have to describe the technique or point to another document that desc= ribes the technique. mmusic-ice-sip-sdp, Sectio= n 4.1=C2=A0seems like a good option, as it already covers how to handle= DNS names in ICE candidates.
This is a significant improveme= nt and I think we will want to incorporate this suggestion. Is this somethi= ng we could do as part of this WGLC, or should we look for another option?<= /div>

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



--
=
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & = Technology [https://www.c= dt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825,= pgp: https://= josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01= 607 5F86 6987 40A9 A871

--000000000000815f66056e762b9e-- From nobody Tue Jun 12 11:56:38 2018 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 EB3B1130FAB for ; Tue, 12 Jun 2018 11:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 eLIFc47clmn4 for ; Tue, 12 Jun 2018 11:56:31 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A68130E5A for ; Tue, 12 Jun 2018 11:56:30 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id i19-v6so9783otk.10 for ; Tue, 12 Jun 2018 11:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+xgtZVjn0BP1L5cVfyOSW9irb1kSU5xaaModoLloHMo=; b=TiLBOKMzYovTl/Opl2UM9JfOkqB+u7nT0b5mHQofHqyUEmWc44IGExRHpSS2Byy3gG VsLviWYKM7AWurbIZgG7Jeq9dj6AnK8DYyHPuq2I5WXtBqVh5hbq5QwZpu3C4dsIJgA0 cT4D7t+lnl2a89FuaBLHenzdzNSmhTTPAqAl8vAZN93d7ojA2E3yMSp+w8/PqXBEYN2G 1tI40LEj4PuY8vv3EwCguGC+qB8COmh/atwvcdUW6vAPM6n/qDE/B3FXWyHbP/J4xSLk ibtYUA6sxvS1MBCYSvVbt0Ai190Zasa2V44BQ6PORGohs0hu4xPUhp1ytPUxYRcEQhb+ /9jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+xgtZVjn0BP1L5cVfyOSW9irb1kSU5xaaModoLloHMo=; b=erpL4Vn4ej1WhHMLDMJUTH++CSWUdN9ZTACxcNYHLCUXLdcqLZ8+d7NHqpQF9yh+Qr LRFN7TmLoYJJ7kKDQ/n1VNc9qJtPCflpsQ9B/KYCc4+11ceH1Ic+6zf8cxzSAiKYJ9G/ OtWp4b7M3MTL4mAPSGIaFJMSxeZjY1GRM/B3RtkjzR+0MGw3D+AZnifuDqEbG20fMRZK RcjQsA0wRza7BZYd/Y3u4erD3LMJpBwfHzYO+9XeLNHVcog9ztoz+kwH1NdDr36E9Bui k1GOisxJAxrVv8i/7Yc7K2JfbhQy+phG5KQy/Ld3zzYOaIfstIFZjU/NMCbDYefLLQVt L49Q== X-Gm-Message-State: APt69E0wsVg4Jr2weMO2GL38DQigKh9m7lYe1Rd1+oUyBh8tjdLce/+3 ddth8PkAd3tpvaHL4Loj4iGh51I6PJ7U7B1qp4E= X-Google-Smtp-Source: ADUXVKKUICuH4SYfn2nekETfhPFn0+Xtt0PE7NX+RdiaCrEEsCXucr64T0BzbVXMT+8sOXZXmNUh2LW3U0PsBMf3Qe0= X-Received: by 2002:a9d:282e:: with SMTP id m43-v6mr1139261otb.393.1528829790178; Tue, 12 Jun 2018 11:56:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 11:55:59 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 12 Jun 2018 20:55:59 +0200 Message-ID: To: Justin Uberti Cc: RTCWeb IETF , yfablet@apple.com, Sean Turner Content-Type: multipart/alternative; boundary="00000000000090d1ce056e766cc7" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 18:56:36 -0000 --00000000000090d1ce056e766cc7 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti < juberti=40google.com@dmarc.ietf.org> wrote: > > This is a significant improvement and I think we will want to incorporate > this suggestion. Is this something we could do as part of this WGLC, or > should we look for another option? > > Without having cleared this with Cullen or Sean, my personal chair-hat opinion is that we can do this in WGLC. If a new technical solution is found during WG last call, I see no reason not to incorporate it. That said, I see two no-hats issues that will want pretty strong text. The first is that these are really UUIDs, not traditional mDNS names. We'll need text to strongly discourage the re-use of an existing mDNS name, since those can leak other information. Second, we'll need text on what to do if this name can't be registered or resolved in a particular environment (not every network supports mDNS, after all). Does it go back to the previous Mode 2 behavior, or skip private addresses entirely? I think the right idea is "go back to the previous Mode 2 behavior" personally, but text on it one way or the other is required. regards, Ted > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --00000000000090d1ce056e766cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

This is a significant improvement and = I think we will want to incorporate this suggestion. Is this something we c= ould do as part of this WGLC, or should we look for another option?


Without having cleared this with Culle= n or Sean, my personal chair-hat opinion is that we can do this in WGLC.=C2= =A0 If a new technical solution is found during WG last call, I see no reas= on not to incorporate it.

That said, I see two no-= hats issues that will want pretty strong text.=C2=A0 The first is that thes= e are really UUIDs, not traditional mDNS names.=C2=A0 We'll need text t= o strongly discourage the re-use of an existing mDNS name, since those can = leak other information.=C2=A0 Second, we'll need text on what to do if = this name can't be registered or resolved in a particular environment (= not every network supports mDNS, after all).=C2=A0 Does it go back to the p= revious Mode 2 behavior, or skip private addresses entirely?=C2=A0 I think = the right idea is "go back to the previous Mode 2 behavior" perso= nally, but text on it one way or the other is required.

regards,

Ted

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

--00000000000090d1ce056e766cc7-- From nobody Tue Jun 12 12:08:42 2018 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 CA29E13106C for ; Tue, 12 Jun 2018 12:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBynHOsZDG9l for ; Tue, 12 Jun 2018 12:08:29 -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 CCC9313106F for ; Tue, 12 Jun 2018 12:08:29 -0700 (PDT) Received: from [172.23.63.134] ([12.176.89.6]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w5CJ8OpF057651 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Jun 2018 14:08:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [12.176.89.6] claimed to be [172.23.63.134] Content-Type: multipart/alternative; boundary=Apple-Mail-A0DFF369-4FC2-448B-81FA-AD0FEB111051 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Tue, 12 Jun 2018 12:08:24 -0700 Cc: Justin Uberti , RTCWeb IETF , yfablet@apple.com Content-Transfer-Encoding: 7bit Message-Id: <14D68A0E-860B-4546-AA68-FD319A2FFAEE@nostrum.com> References: To: Ted Hardie Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 19:08:41 -0000 --Apple-Mail-A0DFF369-4FC2-448B-81FA-AD0FEB111051 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99d like to point out that, while this works fine in most residentia= l settings, it=E2=80=99s pretty broken for multi-segment enterprise deployme= nts.=20 /a > On Jun 12, 2018, at 11:55, Ted Hardie wrote: >=20 >> On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti wrote: >>=20 >> This is a significant improvement and I think we will want to incorporate= this suggestion. Is this something we could do as part of this WGLC, or sho= uld we look for another option? >>=20 >=20 > Without having cleared this with Cullen or Sean, my personal chair-hat opi= nion is that we can do this in WGLC. If a new technical solution is found d= uring WG last call, I see no reason not to incorporate it. >=20 > That said, I see two no-hats issues that will want pretty strong text. Th= e first is that these are really UUIDs, not traditional mDNS names. We'll n= eed text to strongly discourage the re-use of an existing mDNS name, since t= hose can leak other information. Second, we'll need text on what to do if t= his name can't be registered or resolved in a particular environment (not ev= ery network supports mDNS, after all). Does it go back to the previous Mode= 2 behavior, or skip private addresses entirely? I think the right idea is "= go back to the previous Mode 2 behavior" personally, but text on it one way o= r the other is required. >=20 > regards, >=20 > Ted >=20 >=20 > =20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-A0DFF369-4FC2-448B-81FA-AD0FEB111051 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I=E2=80=99d like to point o= ut that, while this works fine in most residential settings, it=E2=80=99s pr= etty broken for multi-segment enterprise deployments. 

/a

On Jun 12, 2018, at 11:55, Ted Hardie <ted.ietf@gmail.com> wrote:

<= blockquote type=3D"cite">
On Tue, Jun 12, 2018 at 2:40 A= M, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org<= /a>> wrote:

This is a signifi= cant improvement and I think we will want to incorporate this suggestion. Is= this something we could do as part of this WGLC, or should we look for anot= her option?


Without having cleared this with Cullen= or Sean, my personal chair-hat opinion is that we can do this in WGLC. = ; If a new technical solution is found during WG last call, I see no reason n= ot to incorporate it.

That said, I see two no-hats i= ssues that will want pretty strong text.  The first is that these are r= eally UUIDs, not traditional mDNS names.  We'll need text to strongly d= iscourage the re-use of an existing mDNS name, since those can leak other in= formation.  Second, we'll need text on what to do if this name can't be= registered or resolved in a particular environment (not every network suppo= rts mDNS, after all).  Does it go back to the previous Mode 2 behavior,= or skip private addresses entirely?  I think the right idea is "go bac= k to the previous Mode 2 behavior" personally, but text on it one way or the= other is required.

regards,

Ted


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


____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-A0DFF369-4FC2-448B-81FA-AD0FEB111051-- From nobody Tue Jun 12 12:14:41 2018 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 B334C130E7C for ; Tue, 12 Jun 2018 12:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 qrZdw3NvmUUB for ; Tue, 12 Jun 2018 12:14:35 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F090C130E5A for ; Tue, 12 Jun 2018 12:14:34 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id f1-v6so682748ioh.6 for ; Tue, 12 Jun 2018 12:14:34 -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=kPed5DChM9A00nB2JKbGKzr1x6XIbtUh9ZZ//JL05EU=; b=r9csTooq6qxodi68RQdp4wITzrlMNsgyIwa5/21oKsoPHmrO/Z2taSOQgZYTbALTmN ZxGZ5OZl+3sxAiAXfmnPtNZWxWUsTUQ8tU8cndM1fbfSJ4EeNP7WqF1RWF1LHYvAi8G4 lVokUOHhNFhZQzgf5781E/qhNHuee5HAzpzTryVoiMhw2OOzlMbnO7neEjmTurfLkP3b HjOxrSaD/0RYSq5q1uHB7WTq9iTvpap8+aL+OHix+vGRQbL4IsedlgIFe+nSsBK6idGS BgmeplDkeAHzVL2zSQ8nPCxys3xgp15EirJRdif497XVNJtJE3Es6GUab0TAXysdNdSV 4uvQ== 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=kPed5DChM9A00nB2JKbGKzr1x6XIbtUh9ZZ//JL05EU=; b=KcadZDG324oPjg55qNNrSBX14x/k0cAzamGrCX4RtH7F1eLlgp1DNubJSI0so+iCh+ PrhqUGbwKBVfdH9oRO/Z12+rICSvrGoJDbJf1gJUgLSNZ9gSTxYjYAwkZXbtMEluc5sH az5gyRppK52X4+vcTosQ21VOSJLD1VE+X+0YsqqqcgAsSKlLT8gR6HEYMNP3ZVzYQYGZ TqjVYUs+niScb/I9XOQoEWJ0AmVPeevILbj7+h0dTabZsF2uStQue/aNRjt5QOHgYCDh Ooxzjp07hafU07NPhB+iWhCF78/ZlAxAdNkv7oUW4ZwjNdiO00CmwE5+o1as7NhvM5Bh swFw== X-Gm-Message-State: APt69E3o0HHMpJYzGnJMQ7yIOg9HGqnp5yDTe0l7d5++vqO1Ls/vw2XW OoNajgklpinL/g66EOloet3+9GntCKqI/I7wFxPBZybOcqo= X-Google-Smtp-Source: ADUXVKLhZ4v4D5OZ6XgLA0KAHjYvM2wQSDm29mnFEnEx52JI/ovD/Meh69fytS44oxZGpwiqM7OIKviDChpeONV87cQ= X-Received: by 2002:a6b:3245:: with SMTP id y66-v6mr1702888ioy.87.1528830873777; Tue, 12 Jun 2018 12:14:33 -0700 (PDT) MIME-Version: 1.0 References: <14D68A0E-860B-4546-AA68-FD319A2FFAEE@nostrum.com> In-Reply-To: <14D68A0E-860B-4546-AA68-FD319A2FFAEE@nostrum.com> From: Justin Uberti Date: Tue, 12 Jun 2018 12:14:19 -0700 Message-ID: To: Adam Roach Cc: Ted Hardie , RTCWeb IETF , yfablet@apple.com Content-Type: multipart/alternative; boundary="00000000000027e1f4056e76ada4" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 19:14:38 -0000 --00000000000027e1f4056e76ada4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One option could be that Mode 2 incorporates RFC 4941 stateless IPv6 addresses, if supported. Otherwise, mDNS is used. This mode would never include RFC 1918 IPv4 addresses. This would work well in more environments and still provide significant privacy improvements. On Tue, Jun 12, 2018 at 12:08 PM Adam Roach wrote: > I=E2=80=99d like to point out that, while this works fine in most residen= tial > settings, it=E2=80=99s pretty broken for multi-segment enterprise deploym= ents. > > /a > > On Jun 12, 2018, at 11:55, Ted Hardie wrote: > > On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti < > juberti=3D40google.com@dmarc.ietf.org> wrote: > >> >> This is a significant improvement and I think we will want to incorporat= e >> this suggestion. Is this something we could do as part of this WGLC, or >> should we look for another option? >> >> > Without having cleared this with Cullen or Sean, my personal chair-hat > opinion is that we can do this in WGLC. If a new technical solution is > found during WG last call, I see no reason not to incorporate it. > > That said, I see two no-hats issues that will want pretty strong text. > The first is that these are really UUIDs, not traditional mDNS names. > We'll need text to strongly discourage the re-use of an existing mDNS nam= e, > since those can leak other information. Second, we'll need text on what = to > do if this name can't be registered or resolved in a particular environme= nt > (not every network supports mDNS, after all). Does it go back to the > previous Mode 2 behavior, or skip private addresses entirely? I think th= e > right idea is "go back to the previous Mode 2 behavior" personally, but > text on it one way or the other is required. > > regards, > > Ted > > > > >> _______________________________________________ >> 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 > > --00000000000027e1f4056e76ada4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One option could be that Mode 2 incorporates RFC 4941 stateless IPv6 addresses, if supported. Otherwise,= =C2=A0mDNS is used. This mode would never include RFC 1918 IPv4 addr= esses.

This would work well in more environments and= still provide significant privacy improvements.

On Tue, Jun 12, 2018 at 12:08 PM Adam Roa= ch <adam@nostrum.com> wrote:<= br>
I= =E2=80=99d like to point out that, while this works fine in most residentia= l settings, it=E2=80=99s pretty broken for multi-segment enterprise deploym= ents.=C2=A0

/a

On Jun 12, 2018, at 1= 1:55, Ted Hardie <ted.ietf@gmail.com> wrote:

=
On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:=

This is a significant improvement a= nd I think we will want to incorporate this suggestion. Is this something w= e could do as part of this WGLC, or should we look for another option?


Without having cleared this with Culle= n or Sean, my personal chair-hat opinion is that we can do this in WGLC.=C2= =A0 If a new technical solution is found during WG last call, I see no reas= on not to incorporate it.

That said, I see two no-= hats issues that will want pretty strong text.=C2=A0 The first is that thes= e are really UUIDs, not traditional mDNS names.=C2=A0 We'll need text t= o strongly discourage the re-use of an existing mDNS name, since those can = leak other information.=C2=A0 Second, we'll need text on what to do if = this name can't be registered or resolved in a particular environment (= not every network supports mDNS, after all).=C2=A0 Does it go back to the p= revious Mode 2 behavior, or skip private addresses entirely?=C2=A0 I think = the right idea is "go back to the previous Mode 2 behavior" perso= nally, but text on it one way or the other is required.

regards,

Ted

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


___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb=
--00000000000027e1f4056e76ada4-- From nobody Tue Jun 12 16:34:25 2018 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 AA2551310A1; Tue, 12 Jun 2018 16:34:12 -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.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152884645263.31326.11361488791273831693@ietfa.amsl.com> Date: Tue, 12 Jun 2018 16:34:12 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-08.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 23:34:18 -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 Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-08.txt Pages : 11 Date : 2018-06-03 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 12 16:37:06 2018 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 65AB0130EF3 for ; Tue, 12 Jun 2018 16:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 X8Q8YSdgJSH6 for ; Tue, 12 Jun 2018 16:36:57 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00DE129619 for ; Tue, 12 Jun 2018 16:36:56 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id k3-v6so1449310iog.3 for ; Tue, 12 Jun 2018 16:36: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=8A49MY66ZvadF3Fscim6ZAnpjTAoGVQeTO8dIbvAdK8=; b=ezuuBxZIlHBZihCOu5F6T99T+aas1N5C5xelVMSCb3syVYPXW6Y4W/rPlBHV460Ww/ w1OrdppFi+z65gbbvwHHcU3BDfxk9EIaAV0y/KcBe7Kzm6A9Iy6p5UHq0R/Kj53Rbhao Dur+QM1nNSR5mBCQjg51ocMA4RE3/wzh5aiksAPjOx89Mf31L2UK5uz+HpJ9GWx9rzBB 024VvvOBHW9mMoVlyRj1TRmKDmVl7f1eHahrXFBH9FAoJC36suRONrQAlH3GWa/wcx72 WZtVQm+Pgx38plinboUWMhNWSUabBX0RvuK8oAxmSyOWgMrwAp7sCCgEbatcXzO3TcS8 mV/A== 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=8A49MY66ZvadF3Fscim6ZAnpjTAoGVQeTO8dIbvAdK8=; b=pV7ZEsjUlff59d1mB5vfJXAQslHB2Tn3JAOKAdyKCT4sWvTAwx7nCpT4MpjImOfaOi 2RxW5PNzFjNNKkHCx4h9UVRtH/vAPDM7JRyLl8bFpyJcRqd9f4I8IAXuEkV1QWyBcP0F ZNCkJzP2BB7n5RTNRWxquNJqts61P/IWtmMkEXzuzMwoKyQJnZkPu7n4FfiCX2DkeoDt leD+lI88JyhDNtRaqla2+McgT1VJRp4OPqeX6cw2lBpEv82chEftx1Kaf/U02LLS2QoM l3XIPtGs6mJZfPwyQSJCbBmU+WCDSl5zC7Onh5iOyQ9CcAZ0ThJ5rkNj9tBOyWWGvG/r cMAg== X-Gm-Message-State: APt69E1CWBukfAtCNJn4QnZNts3HtGDvxYXWeDjAnpvHm1YLV/uVULge zy0KFzchkSlEO9jUM5xL/gdDrQmjZRqIGaRSgSnNCQ== X-Google-Smtp-Source: ADUXVKLlkTQ8mCEYsh+3gUOGehfM/4K3SMEqkoXz7MS4OKFHECcixBGL1gFbr1O+VphQMqawWvLD5mJTZ0NnFT0OT/c= X-Received: by 2002:a6b:3245:: with SMTP id y66-v6mr2487938ioy.87.1528846615719; Tue, 12 Jun 2018 16:36:55 -0700 (PDT) MIME-Version: 1.0 References: <14D68A0E-860B-4546-AA68-FD319A2FFAEE@nostrum.com> In-Reply-To: From: Justin Uberti Date: Tue, 12 Jun 2018 16:36:44 -0700 Message-ID: To: Adam Roach Cc: Ted Hardie , RTCWeb IETF , yfablet@apple.com Content-Type: multipart/alternative; boundary="00000000000072bc68056e7a5741" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 23:37:04 -0000 --00000000000072bc68056e7a5741 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Given the general support here, I'll start writing up a PR to incorporate the aforementioned changes, with the goal to avoid emitting private IPv4 addresses in the default mode. On Tue, Jun 12, 2018 at 12:14 PM Justin Uberti wrote: > One option could be that Mode 2 incorporates RFC 4941 stateless IPv6 > addresses, if supported. Otherwise, mDNS is used. This mode would never > include RFC 1918 IPv4 addresses. > > This would work well in more environments and still provide significant > privacy improvements. > > On Tue, Jun 12, 2018 at 12:08 PM Adam Roach wrote: > >> I=E2=80=99d like to point out that, while this works fine in most reside= ntial >> settings, it=E2=80=99s pretty broken for multi-segment enterprise deploy= ments. >> >> /a >> >> On Jun 12, 2018, at 11:55, Ted Hardie wrote: >> >> On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti < >> juberti=3D40google.com@dmarc.ietf.org> wrote: >> >>> >>> This is a significant improvement and I think we will want to >>> incorporate this suggestion. Is this something we could do as part of t= his >>> WGLC, or should we look for another option? >>> >>> >> Without having cleared this with Cullen or Sean, my personal chair-hat >> opinion is that we can do this in WGLC. If a new technical solution is >> found during WG last call, I see no reason not to incorporate it. >> >> That said, I see two no-hats issues that will want pretty strong text. >> The first is that these are really UUIDs, not traditional mDNS names. >> We'll need text to strongly discourage the re-use of an existing mDNS na= me, >> since those can leak other information. Second, we'll need text on what= to >> do if this name can't be registered or resolved in a particular environm= ent >> (not every network supports mDNS, after all). Does it go back to the >> previous Mode 2 behavior, or skip private addresses entirely? I think t= he >> right idea is "go back to the previous Mode 2 behavior" personally, but >> text on it one way or the other is required. >> >> regards, >> >> Ted >> >> >> >> >>> _______________________________________________ >>> 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 >> >> --00000000000072bc68056e7a5741 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given the general support here, I'll start writing up = a PR to incorporate the aforementioned changes, with the goal to avoid emit= ting private IPv4 addresses in the default mode.

On Tue, Jun 12, 2018 at 12:14 PM Justin Uber= ti <juberti@goog= le.com> wrote:
One option could be that Mode 2 incorporates RFC 4941 stateless IPv6 addresses, if supported. Otherwise,=C2=A0mD= NS is used. This mode would never include RFC 1918 IPv4 addresses.
=
This would work well in more environments and still provide = significant privacy improvements.

On Tue, Jun 12, 2018 at 12:08 PM Adam Roach <adam@nostrum.com> wro= te:
I=E2=80=99d like to point out that, while this works fine in most reside= ntial settings, it=E2=80=99s pretty broken for multi-segment enterprise dep= loyments.=C2=A0

/a

On Jun 12, 2018, = at 11:55, Ted Hardie <ted.ietf@gmail.com> wrote:

On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wr= ote:

This is a significant improveme= nt and I think we will want to incorporate this suggestion. Is this somethi= ng we could do as part of this WGLC, or should we look for another option?<= /div>


Without having cleared this with Culle= n or Sean, my personal chair-hat opinion is that we can do this in WGLC.=C2= =A0 If a new technical solution is found during WG last call, I see no reas= on not to incorporate it.

That said, I see two no-= hats issues that will want pretty strong text.=C2=A0 The first is that thes= e are really UUIDs, not traditional mDNS names.=C2=A0 We'll need text t= o strongly discourage the re-use of an existing mDNS name, since those can = leak other information.=C2=A0 Second, we'll need text on what to do if = this name can't be registered or resolved in a particular environment (= not every network supports mDNS, after all).=C2=A0 Does it go back to the p= revious Mode 2 behavior, or skip private addresses entirely?=C2=A0 I think = the right idea is "go back to the previous Mode 2 behavior" perso= nally, but text on it one way or the other is required.

regards,

Ted

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


___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb=
--00000000000072bc68056e7a5741-- From nobody Tue Jun 12 20:20:54 2018 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 87C97130E72 for ; Tue, 12 Jun 2018 20:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 KnTpUV_NUtE6 for ; Tue, 12 Jun 2018 20:20:45 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095A4130DD7 for ; Tue, 12 Jun 2018 20:20:44 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id a195-v6so1968628itd.3 for ; Tue, 12 Jun 2018 20:20:44 -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=3lxzCsrNsCd1mi8g0JE7rOdAZZ60M8IwT12O3/RzuUg=; b=XEGuMemjDz4xis/hf5sITI+vlNhYw5YD+gOuIFW6am4UP4Dik9WgcSEW+pp5B8gfy7 Xlj0j0JuNPpquMOu31k8i9qXx8p/GIhZnGIJUVC2/D55l5unh8031DB9iFMiXSiEtXNV cMR6rdMHPjIzogjdIBHdnByyhgbeMRJnPEz5KoZPNtnFUCC1lhcHObLhfp8022dL6aZ8 NOZM9Ndn1v59pKo2PwDW1mnZjqszENZaMnTn+0pnGdugg/H0sycDgxtE/1Gr+i7+q75H USrkTSzCwnar65cwunswxM3zFpQAjawMu7MZPdyzf8MMAwQToEHrrsdBPMaEk5YbYi4Z 3Y7w== 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=3lxzCsrNsCd1mi8g0JE7rOdAZZ60M8IwT12O3/RzuUg=; b=K1uF23zBI/wi7fgViD9BRreU8SsFMAaLd63PFMoIzkq/+jrTEYleQd/2xZNNb8KPA5 uFv8Uw6tL7j11HwySbwEONx7nYC0UnpFoMZnAo4vqkNTtaZMM5q1zhD+V9MzC6bQxa5J u+FaW+oCdH1VaY1DYNo8tF57EWGNde7LetWoHntgiDJqbgi1ggOSyYNcjrWZKRLQfoWh oglRq8OM+sQahfoo9F2+3cEUbZh7DZkce1C9F6Hb56fZA5bFNf32ivGdlFEZThzzVUPA ZMvHLWU6LysLZM9X+xkLfYSDgHn7BR/1AgMYbMdARN28TdmaccaZ95CKQUQTcviQdZXg 3JNw== X-Gm-Message-State: APt69E0pjMLlL/7tdyUPunSKpDNzkRjABkKDe8fSnjkHuc3HK5gg4b00 fkH73fphmg9/ffB2d00WanFtzI9PYChUP4dZtKyCkQ== X-Google-Smtp-Source: ADUXVKJwZ37N+Sjr42+1ntVsLxtxEdIpCre90GTz5RscsW9+F3PNWU5E8puqJa6A2hbcoau++2bph9i7FMIF9sZyqI4= X-Received: by 2002:a24:2246:: with SMTP id o67-v6mr2961679ito.25.1528860043809; Tue, 12 Jun 2018 20:20:43 -0700 (PDT) MIME-Version: 1.0 References: <14D68A0E-860B-4546-AA68-FD319A2FFAEE@nostrum.com> In-Reply-To: From: Justin Uberti Date: Tue, 12 Jun 2018 20:20:30 -0700 Message-ID: To: Adam Roach Cc: Ted Hardie , RTCWeb IETF , yfablet@apple.com Content-Type: multipart/alternative; boundary="000000000000d31b37056e7d77e4" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 03:20:51 -0000 --000000000000d31b37056e7d77e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable PTAL at https://github.com/juberti/draughts/pull/103. It would be great to have some time to discuss this in Montreal. On Tue, Jun 12, 2018 at 4:36 PM Justin Uberti wrote: > Given the general support here, I'll start writing up a PR to incorporate > the aforementioned changes, with the goal to avoid emitting private IPv4 > addresses in the default mode. > > On Tue, Jun 12, 2018 at 12:14 PM Justin Uberti wrote= : > >> One option could be that Mode 2 incorporates RFC 4941 stateless IPv6 >> addresses, if supported. Otherwise, mDNS is used. This mode would never >> include RFC 1918 IPv4 addresses. >> >> This would work well in more environments and still provide significant >> privacy improvements. >> >> On Tue, Jun 12, 2018 at 12:08 PM Adam Roach wrote: >> >>> I=E2=80=99d like to point out that, while this works fine in most resid= ential >>> settings, it=E2=80=99s pretty broken for multi-segment enterprise deplo= yments. >>> >>> /a >>> >>> On Jun 12, 2018, at 11:55, Ted Hardie wrote: >>> >>> On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti < >>> juberti=3D40google.com@dmarc.ietf.org> wrote: >>> >>>> >>>> This is a significant improvement and I think we will want to >>>> incorporate this suggestion. Is this something we could do as part of = this >>>> WGLC, or should we look for another option? >>>> >>>> >>> Without having cleared this with Cullen or Sean, my personal chair-hat >>> opinion is that we can do this in WGLC. If a new technical solution is >>> found during WG last call, I see no reason not to incorporate it. >>> >>> That said, I see two no-hats issues that will want pretty strong text. >>> The first is that these are really UUIDs, not traditional mDNS names. >>> We'll need text to strongly discourage the re-use of an existing mDNS n= ame, >>> since those can leak other information. Second, we'll need text on wha= t to >>> do if this name can't be registered or resolved in a particular environ= ment >>> (not every network supports mDNS, after all). Does it go back to the >>> previous Mode 2 behavior, or skip private addresses entirely? I think = the >>> right idea is "go back to the previous Mode 2 behavior" personally, but >>> text on it one way or the other is required. >>> >>> regards, >>> >>> Ted >>> >>> >>> >>> >>>> _______________________________________________ >>>> 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 >>> >>> --000000000000d31b37056e7d77e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It would be great to have some time to discuss this in Mont= real.

On Tue, Ju= n 12, 2018 at 4:36 PM Justin Uberti <juberti@google.com> wrote:
Given the general support here, I'll start writing u= p a PR to incorporate the aforementioned changes, with the goal to avoid em= itting private IPv4 addresses in the default mode.

On Tue, Jun 12, 2018 at 12:14 PM Justin U= berti <juberti@g= oogle.com> wrote:
One option could be that Mode 2 incorporates RFC 4941 stateless IPv6 addresses, if supported. Otherwise,=C2=A0mDNS is used. This mode would never include RFC 1918 IPv4 addresses.
=

This would work well in more environments and still pro= vide significant privacy improvements.

On Tue, Jun 12, 2018 at 12:08 PM Adam Roach <adam@nostrum.com> = wrote:
I=E2=80=99d like to point out that, while this works fine in most res= idential settings, it=E2=80=99s pretty broken for multi-segment enterprise = deployments.=C2=A0

/a

On Jun 12, 201= 8, at 11:55, Ted Hardie <ted.ietf@gmail.com> wrote:

On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti= <juberti=3D40google.com@dmarc.ietf.org>= wrote:

This is a significant improv= ement and I think we will want to incorporate this suggestion. Is this some= thing we could do as part of this WGLC, or should we look for another optio= n?


Without having cleared this with Culle= n or Sean, my personal chair-hat opinion is that we can do this in WGLC.=C2= =A0 If a new technical solution is found during WG last call, I see no reas= on not to incorporate it.

That said, I see two no-= hats issues that will want pretty strong text.=C2=A0 The first is that thes= e are really UUIDs, not traditional mDNS names.=C2=A0 We'll need text t= o strongly discourage the re-use of an existing mDNS name, since those can = leak other information.=C2=A0 Second, we'll need text on what to do if = this name can't be registered or resolved in a particular environment (= not every network supports mDNS, after all).=C2=A0 Does it go back to the p= revious Mode 2 behavior, or skip private addresses entirely?=C2=A0 I think = the right idea is "go back to the previous Mode 2 behavior" perso= nally, but text on it one way or the other is required.

regards,

Ted

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


___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/rtcweb=
--000000000000d31b37056e7d77e4-- From nobody Wed Jun 13 01:13:13 2018 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 37FD7126F72 for ; Wed, 13 Jun 2018 01:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 ISwxuPKmflKw for ; Wed, 13 Jun 2018 01:13:07 -0700 (PDT) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8D2130E04 for ; Wed, 13 Jun 2018 01:13:07 -0700 (PDT) Received: by mail-pl0-x22f.google.com with SMTP id w17-v6so1077327pll.9 for ; Wed, 13 Jun 2018 01:13:07 -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=heRRz48pZFat2JEebyy6smxh6EP4hIqF1ggzZYWyM3Y=; b=hu4KVnvWxGu72NmWsngsyCsL2JtMWEx9A5ndDi/GSb4bUTxIKBxeq3ocSVirnslclj D58GT1lRklw6e/GKW+IVJnQ6rdqiM3FsmB7eub8wq1uIdhN4e2e7z81jRi5Q5UpgriFC Np1GIxW0G2GQf7ESj/tzPP5fGiLv/YhmaD72U= 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=heRRz48pZFat2JEebyy6smxh6EP4hIqF1ggzZYWyM3Y=; b=Q2gNCvgqOmnF2kWI1TjgXA79MjiJtOWBJwzuSXjpjbgKNgowbPsFUKgTfXEyzvJt40 rvTI2H39IpAn4B4S+P5L3nIEOvcuvHy2vQhuHcrk8gDfnY1Y3PAUgEr10DrWsRLoqnXM B5+MHeS5PwBNs76lU/Iwuz6AiWOnNpEn4pKX3nL4MJ9NBNXmTm3wiSYw6SQyN6084nGV d9IaLi1+kbktnR4FTQrTENna5CHQSc7tDPJllXAHd2AcWMZF86kAUvW/farRI+JzwbnA aGML/RdhJY8Qk6+BN9zqwMBLdApy6Q0Ex2jqA3MlcC4AZxTkeGsK9uO2LvFxob4/+2t9 iG2A== X-Gm-Message-State: APt69E2DadRoXKReC7XximkIJATk3dzsGMMLL7Vo1Q3Qw+LaFLQN40uq p/37jdQ97C5EPn9ljSuO6U+FmQ== X-Google-Smtp-Source: ADUXVKLS/argzRR7XK9/4PJZQh3Ul2OJzWwcQc/Y6wHbBZm/tLPS7oquLtMXPrr9bq0jiprI0T7kNQ== X-Received: by 2002:a17:902:9b8f:: with SMTP id y15-v6mr4066886plp.187.1528877586525; Wed, 13 Jun 2018 01:13:06 -0700 (PDT) Received: from [5.5.33.193] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id v27-v6sm4293197pfi.23.2018.06.13.01.13.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 01:13:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sean Turner In-Reply-To: Date: Wed, 13 Jun 2018 09:12:58 +0100 Cc: RTCWeb IETF , rtcweb-chairs@ietf.org, yfablet@apple.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> To: Justin Uberti X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 08:13:11 -0000 We had not planned on it. spt > On Jun 12, 2018, at 18:32, Justin Uberti wrote: >=20 > Checking in on this. Are we going to have a session at IETF 102?=20 >=20 > On Thu, May 31, 2018 at 6:41 AM Tim Hollebeek = wrote: > I agree. >=20 > -Tim >=20 > > -----Original Message----- > > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > Sent: Thursday, May 31, 2018 4:11 AM > > To: rtcweb@ietf.org > > Cc: rtcweb-chairs@ietf.org > > Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 > >=20 > > Hi, > >=20 > > I think we need to have discussions (in SOME forum) about the = Identity > > attribute. Because, in addition to the things that need to be = clarified, > based on > > the comments it seem like there are opinions/understandings that > contradict > > what is currently written in the draft. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > On 30/05/18 16:18, "rtcweb on behalf of IETF Meeting Session Request = Tool" > > = wrote: > >=20 > > > > > > > > >Sean Turner, a chair of the rtcweb working group, indicated that = the > > >rtcweb working group does not plan to hold a session at IETF 102. > > > > > >This message was generated and sent by the IETF Meeting Session = Request > > >Tool. > > > > > > > > >_______________________________________________ > > >rtcweb mailing list > > >rtcweb@ietf.org > > >https://www.ietf.org/mailman/listinfo/rtcweb > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Jun 13 13:28:11 2018 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 240DE130E5A for ; Wed, 13 Jun 2018 13:28:09 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ygGJ_YEekdYj for ; Wed, 13 Jun 2018 13:28:05 -0700 (PDT) Received: from smtp113.ord1d.emailsrvr.com (smtp113.ord1d.emailsrvr.com [184.106.54.113]) (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 AF91A130E27 for ; Wed, 13 Jun 2018 13:28:05 -0700 (PDT) Received: from smtp15.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp15.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 1210D6020F; Wed, 13 Jun 2018 16:28:05 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp15.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A0F98603E6; Wed, 13 Jun 2018 16:28:04 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 13 Jun 2018 16:28:05 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_778ADC18-32D5-4A3F-850B-AF7DA2FBA3F2" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Cullen Jennings In-Reply-To: Date: Wed, 13 Jun 2018 14:28:03 -0600 Cc: RTCWeb IETF , youenn fablet , Sean Turner Message-Id: References: To: Justin Uberti X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 20:28:10 -0000 --Apple-Mail=_778ADC18-32D5-4A3F-850B-AF7DA2FBA3F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With my individual hat on =E2=80=A6 I have a bunch of concerns about this but the biggest is that mDNS does = not work on a large percentage of medium and large corporate WiFI = Networks. The problem is the large multicast domains trash the WiFi = performance so many APs turn off mDNS or limit it=E2=80=99s range to = much less than the scope of where just testing the address with ICE = would be routable. It=E2=80=99s exactly theses environment where using = the local IP vs a TURN IP provides lots of benefit. I like the idea of = trying to use mDNS but I=E2=80=99d want tot see strong evidence it = worked in theses environments before putting it in at the last minute.=20= > On Jun 11, 2018, at 6:40 PM, Justin Uberti = wrote: >=20 > The Safari team has come up with a clever approach to avoid disclosing = private IP addresses for host candidates. As discussed in this WebKit = bug , the technique = works as follows: > Register a random UUID-based mDNS name when ICE gathering starts > Replace the private IP address by a "{UUID}.local" string in each host = candidate (and set raddr to 0.0.0.0 for other candidates) > The other party will do mDNS resolution on any candidate having a = .local suffix, similar to how hostnames in candidates are handled in RFC = 5245, Section 15.1. > This technique is relevant to the IP handling document, as it = addresses one of the lesser problems (private IP disclosure) from the = overall problem statement. While I don't think this will have a large = impact on the document, including the default mode selection, = incorporating this technique would result in some moderate changes: > Section 5.1 would mention concealing private IPs in the default case = as an explicit goal. > In Section 6, Mode 2 would change from handling out private IPs to = handing out mDNS names. > This document would have to describe the technique or point to another = document that describes the technique. mmusic-ice-sip-sdp, Section 4.1 = = seems like a good option, as it already covers how to handle DNS names = in ICE candidates. > This is a significant improvement and I think we will want to = incorporate this suggestion. Is this something we could do as part of = this WGLC, or should we look for another option? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_778ADC18-32D5-4A3F-850B-AF7DA2FBA3F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


With = my individual hat on =E2=80=A6

I have a bunch of concerns about this but the biggest is that = mDNS does not work on a large percentage of medium and large corporate = WiFI Networks. The problem is the large multicast domains trash the WiFi = performance so many APs turn off mDNS or limit it=E2=80=99s range to = much less than the scope of where just testing the address with ICE = would be routable. It=E2=80=99s exactly theses environment where using = the local IP vs a TURN IP provides lots of benefit.  I like the = idea of trying to use mDNS but I=E2=80=99d want tot see strong evidence = it worked in theses environments before putting it in at the last = minute. 



On Jun 11, 2018, at 6:40 PM, Justin Uberti = <juberti=3D40google.com@dmarc.ietf.org> wrote:

The Safari team has come up with a clever approach to avoid = disclosing private IP addresses for host candidates. As discussed in this WebKit bug, the technique works as = follows:
  1. Register a random UUID-based mDNS name when ICE gathering = starts
  2. Replace the private IP address = by a "{UUID}.local" string in each host candidate (and set raddr to = 0.0.0.0 for other candidates)
  3. The = other party will do mDNS resolution on any candidate having a .local = suffix, similar to how hostnames in candidates are handled in RFC 5245, = Section 15.1.
This technique is = relevant to the IP handling document, as it addresses one of the lesser = problems (private IP disclosure) from the overall problem statement. = While I don't think this will have a large impact on the document, = including the default mode selection, incorporating this technique would = result in some moderate changes:
  • Section 5.1 would mention concealing private = IPs in the default case as an explicit goal.
  • In = Section 6, Mode 2 would change from handling out private IPs to handing = out mDNS names.
  • This document would have to describe = the technique or point to another document that describes the technique. = mmusic-ice-sip-sdp, Section 4.1 seems like a = good option, as it already covers how to handle DNS names in ICE = candidates.
This is a significant improvement = and I think we will want to incorporate this suggestion. Is this = something we could do as part of this WGLC, or should we look for = another option?
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_778ADC18-32D5-4A3F-850B-AF7DA2FBA3F2-- From nobody Wed Jun 13 13:32:56 2018 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 50A4F130E27; Wed, 13 Jun 2018 13:32:44 -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.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152892196430.14364.6063380921831292050@ietfa.amsl.com> Date: Wed, 13 Jun 2018 13:32:44 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 20:32:45 -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 Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-09.txt Pages : 11 Date : 2018-06-13 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-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 Jun 13 13:33:10 2018 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 C73BA13101C for ; Wed, 13 Jun 2018 13:33:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8f3DWCTqs1un for ; Wed, 13 Jun 2018 13:32:57 -0700 (PDT) Received: from smtp121.ord1d.emailsrvr.com (smtp121.ord1d.emailsrvr.com [184.106.54.121]) (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 93733130FED for ; Wed, 13 Jun 2018 13:32:57 -0700 (PDT) Received: from smtp24.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id E7726A02B8; Wed, 13 Jun 2018 16:32:56 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp24.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9A1E5A02AD; Wed, 13 Jun 2018 16:32:56 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 13 Jun 2018 16:32:56 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_C599E62C-3183-4F23-9AA8-6B9DA992756B" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Cullen Jennings In-Reply-To: Date: Wed, 13 Jun 2018 14:32:55 -0600 Cc: RTCWeb IETF Message-Id: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> References: To: Taylor Brandstetter X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 20:33:07 -0000 --Apple-Mail=_C599E62C-3183-4F23-9AA8-6B9DA992756B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 31, 2018, at 12:24 PM, Taylor Brandstetter = wrote: >=20 > One might expect that a "reliable" data channel is guaranteed to be, = well, reliable. But in current implementations, the first messages may = be lost if the application is negotiating the channels out-of-band, and = creates the receiving channel too late. >=20 > Here's a fiddle that demonstrates this (happens with Chrome and = Firefox): https://jsfiddle.net/o2m8tp20/ = >=20 > Normally this isn't an issue, because a typical application would = create the out-of-band negotiated channels before the first offer/answer = is complete, and thus before the SCTP association is established. = Meaning that by the time a data channel is "open", it's guaranteed that = the other peer has a corresponding channel. >=20 > But if for whatever reason, an application creates a data channel = *after* the SCTP association is established, then it will instantly be = "open" as soon as it's created. If a message is sent at this point, and = it's received by the other peer before it's created its corresponding = data channel, then the message will just be discarded. >=20 > So, how should we deal with this? Some possibilities: > Say "this is expected behavior" and document it better, breaking the = reliability promise. > Run the closing procedure if a message is received on a stream before = a data channel is ready to receive it. > Don't even allow an out-of-band negotiated channel to be created after = the SCTP association is established. > Buffer these messages for up to X seconds (or up to X bytes), to be = delivered to the data channel once it's created. Run the closing = procedure if X is exceeded. > I'd vote for #2. Adding additional buffering logic seems like overkill = if this isn't a use case we really intended to support. I lean toward something that just did not allow the out-of-band channel = negotiation be used until it was set up. But whatever we do, not option 1=20 =20 --Apple-Mail=_C599E62C-3183-4F23-9AA8-6B9DA992756B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=3D40google.com@dmarc.ietf.org> = wrote:

One might expect = that a "reliable" data channel is guaranteed to be, well, reliable. But = in current implementations, the first messages may be lost if the = application is negotiating the channels out-of-band, and creates the = receiving channel too late.

Here's a fiddle that demonstrates this (happens with Chrome = and Firefox): https://jsfiddle.net/o2m8tp20/

Normally this isn't an issue, because a = typical application would create the out-of-band negotiated channels = before the first offer/answer is complete, and thus before the SCTP = association is established. Meaning that by the time a data channel is = "open", it's guaranteed that the other peer has a corresponding = channel.

But = if for whatever reason, an application creates a data channel *after* = the SCTP association is established, then it will instantly be "open" as = soon as it's created. If a message is sent at this point, and it's = received by the other peer before it's created its corresponding data = channel, then the message will just be discarded.
So, how should we deal with this? Some = possibilities:
  1. Say "this is expected behavior" and document it better, = breaking the reliability promise.
  2. Run the closing = procedure if a message is received on a stream before a data channel is = ready to receive it.
  3. Don't even allow an out-of-band = negotiated channel to be created after the SCTP association is = established.
  4. Buffer these messages for up to X = seconds (or up to X bytes), to be delivered to the data channel once = it's created. Run the closing procedure if X is exceeded.
I'd vote for #2. Adding additional buffering logic seems like = overkill if this isn't a use case we really intended to = support.

I = lean toward something that just did not allow the  out-of-band = channel negotiation be used until it was set up.

But whatever we do, not option = 1 





 





= --Apple-Mail=_C599E62C-3183-4F23-9AA8-6B9DA992756B-- From nobody Wed Jun 13 13:36:43 2018 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 A0F85130E91 for ; Wed, 13 Jun 2018 13:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.189 X-Spam-Level: X-Spam-Status: No, score=-17.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 F_N-i1V3LOw6 for ; Wed, 13 Jun 2018 13:36:40 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097F9130E27 for ; Wed, 13 Jun 2018 13:36:40 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id n7-v6so5523775itn.1 for ; Wed, 13 Jun 2018 13:36:39 -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:cc; bh=Vslrp8OUOEBIdHbQUstVg52pSzAkodp/rZEgwbgvZHQ=; b=jN0yc2HftcSC7RQX2jZjqRHjEPcuF6ZdSfBq6leIYf8nC1dbF5fwuvikgUgpUkDV4P 6DPDq1xYLmXYLj+Lr3zf38rI682ASmY+XpvbNPgDNuLWbuG/ab7pNbJSJcXGi8XehEmw rh43ovadzAMncIuN0RsD+TdhHUvuiU/MEVmiFPJpY+JAQ/n4gK5kpfRd43r+vhUcEvMD ZcIlRVQ1roK17oqcBFi4ZrKacbvt3o7YAyKMOh6tF5fFLTJ7aJTL0onquKhC7GsZFu+d WExMIej0HgFw3arKc2I72nq8TCKQjQAEu2C7YPpat5dvkRn9CKQVym9P6f/KlDFD0+Ac xy7Q== 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:cc; bh=Vslrp8OUOEBIdHbQUstVg52pSzAkodp/rZEgwbgvZHQ=; b=Ym8evGrke92+IU5sCS9p/NLjE0wzzynLfNs1Ls0hbBW01SnreNYgXHaUajVGpCAdWo v/aFNfXuI0uHfKJ+PusimJTsAdfXwA7HRkFJGtzxFu3dp35OLWeI/ML2kMWI4uSk8+4+ prfiJOkS/OCjVfcpA5hGDqu9S51DgBgC/iFif3f40d74sgMU4x7SMOabWxRvZNAOYoVO Ly7DEyJ4vwDc9Zx3awfiYvEkVrDF6tIh6CuGc5I9LtpMj6ONtpVxmeywm4gY+A6G9mTb SesyPmFzmjNnW+AY4OAxXo4LU8cU9xCA81UpuQF+R85XQnoCG2iG7S1sALEpkYi6gh0Z va1A== X-Gm-Message-State: APt69E2wHTcvuLJn7JlrENL6tXEESbNBHb9gghvnq9toahdTRLOgAmgm uYDxsPXpYFNfkCt7lZ1uVSlvMHZfGfbLRdc67/FhIjkB X-Google-Smtp-Source: ADUXVKIRJjzIc2C8RkiZ4vZwGOBxztIyOO0ntEsqcKVp5aBkeG8FxKjenDuxhzDHjxAXCCDoPgIi+mdSVX3n5X61bpg= X-Received: by 2002:a24:5901:: with SMTP id p1-v6mr5955517itb.119.1528922198570; Wed, 13 Jun 2018 13:36:38 -0700 (PDT) MIME-Version: 1.0 References: <152892196430.14364.6063380921831292050@ietfa.amsl.com> In-Reply-To: <152892196430.14364.6063380921831292050@ietfa.amsl.com> From: Justin Uberti Date: Wed, 13 Jun 2018 13:36:26 -0700 Message-ID: Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000899a88056e8bf051" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-09.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 20:36:42 -0000 --000000000000899a88056e8bf051 Content-Type: text/plain; charset="UTF-8" This update resolves a minor text issue regarding enterprise TURN servers that was introduced in the -08 rev. Details here . Thanks to Lennart Grahl for catching this. On Wed, Jun 13, 2018 at 1:33 PM wrote: > > 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 > Authors : Justin Uberti > Guo-wei Shieh > Filename : draft-ietf-rtcweb-ip-handling-09.txt > Pages : 11 > Date : 2018-06-13 > > 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-09 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-ip-handling-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000899a88056e8bf051 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This update resolves a minor text issue regarding enterpri= se TURN servers that was introduced in the -08 rev. Details here.=C2=A0

<= div>Thanks to Lennart Grahl for catching this.

On Wed, Jun 13, 2018 at 1:33 PM <internet-drafts@ietf.org> wrote= :

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers WG= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC IP Address Handling Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=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 Guo-wei Shieh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-ip-handling-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-06-13

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how IP=
=C2=A0 =C2=A0addresses should be handled by WebRTC implementations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-r= tcweb-ip-handling-09
https://datatracker.ietf.org/d= oc/html/draft-ietf-rtcweb-ip-handling-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-rtcweb-ip-handling-09


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

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000899a88056e8bf051-- From nobody Wed Jun 13 15:48:25 2018 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 90FDD130E96 for ; Wed, 13 Jun 2018 15:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 0qYGK5xtxmdp for ; Wed, 13 Jun 2018 15:48:18 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C961D130EB1 for ; Wed, 13 Jun 2018 15:48:17 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id 200-v6so2542363vkc.0 for ; Wed, 13 Jun 2018 15:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dtaUcqRI9cmJdxXcvAF00w+WH/+8C8kwm+JT+hOD8p4=; b=EjaSoOvvURseJMtiKbpcBaVY65rnLpOh3F6ozkxLcLpXVFNLcU8mmb6imUfz+RlAAA eYkTP88QSQKZPxSRvj1LuKRvgUAbMast1HAW+7Sz9oLM0uo2F5tnYJizDlklfoExI3Dn 9fisDMifanXIcwY3cgDxdZQZmFkwTqCEikCheLuu5hVmiuh7lm4T8oZTkDCkm37k7TFs WWjkjVhmoUkcSrKkC8XCTGZFDupGY8KsX//D2N9krpJ/kwtBu4eIBUQIn3IIWdWlPKp6 us0wRQ+mW9bImryNdZ28gzcyCpiDgposFhpiXacLfIAm7haObPir39+LQPR1wvM/PjPh yJwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dtaUcqRI9cmJdxXcvAF00w+WH/+8C8kwm+JT+hOD8p4=; b=Z9imxbQiUOwjXsX8H+bO+ojjqwErXTkOdHHEUGQkPNBoNPiod1LPA5VUiZanGSGyHn ClEr2hkQoaT+GLPA9mjaJkAJwoGCWeJ5cy/kfFBI2j6dumB1sEOfSDHu4nvbhoMF5iI/ s72o+RAVVJx4clZrFPekYzGxKbUqoDHrNnC8GkNukpTeJm7JeEbr7q052wqv7bYgWckn 1sBL0WZpRk9L41KZFS60fUM/Bg9uIk9imFevo6c2SOKUu2/fLLDUSmcMguAardzA4St0 jHw/QijXbGDF9CxtzJP33lmnR9qIyejDuqBS1VpQAeSry1aaljIvlm1xUZu94fVWvWwb ifKg== X-Gm-Message-State: APt69E3nJeRJgj+bY3Ede0o4sixOT6elIIWRxd2yKsp4rTLoNgDqr9nK I02mPWqY5owaaCc02ME/0HQoXE1EGd+mV1PhGZA4o3ln X-Google-Smtp-Source: ADUXVKJgEMmajBxhFSaQ/oYzYmvMcbS0naHkh7xoOfSkzlCLudCKedcX1QRs1Gsoh9AUcaj1MU867DuAwcs5LPG64lg= X-Received: by 2002:a1f:6d03:: with SMTP id i3-v6mr62933vkc.198.1528930096548; Wed, 13 Jun 2018 15:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 15:48:15 -0700 (PDT) In-Reply-To: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> From: Taylor Brandstetter Date: Wed, 13 Jun 2018 15:48:15 -0700 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000004b141d056e8dc7bf" Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 13 Jun 2018 22:48:23 -0000 --0000000000004b141d056e8dc7bf Content-Type: text/plain; charset="UTF-8" It sounds like you and Christer are suggesting the same thing: "don't allow messages to be sent until you're sure the other peer has a channel to receive them". Except that there's no way for the WebRTC stack to know that, since these channels are not signaled in SDP or any in-band message. On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings wrote: > > > On May 31, 2018, at 12:24 PM, Taylor Brandstetter < > deadbeef=40google.com@dmarc.ietf.org> wrote: > > One might expect that a "reliable" data channel is guaranteed to be, well, > reliable. But in current implementations, the first messages may be lost if > the application is negotiating the channels out-of-band, and creates the > receiving channel too late. > > Here's a fiddle that demonstrates this (happens with Chrome and Firefox): > https://jsfiddle.net/o2m8tp20/ > > Normally this isn't an issue, because a typical application would create > the out-of-band negotiated channels before the first offer/answer is > complete, and thus before the SCTP association is established. Meaning that > by the time a data channel is "open", it's guaranteed that the other peer > has a corresponding channel. > > But if for whatever reason, an application creates a data channel *after* > the SCTP association is established, then it will instantly be "open" as > soon as it's created. If a message is sent at this point, and it's received > by the other peer before it's created its corresponding data channel, then > the message will just be discarded. > > So, how should we deal with this? Some possibilities: > > 1. Say "this is expected behavior" and document it better, breaking > the reliability promise. > 2. Run the closing procedure if a message is received on a stream > before a data channel is ready to receive it. > 3. Don't even allow an out-of-band negotiated channel to be created > after the SCTP association is established. > 4. Buffer these messages for up to X seconds (or up to X bytes), to be > delivered to the data channel once it's created. Run the closing procedure > if X is exceeded. > > I'd vote for #2. Adding additional buffering logic seems like overkill if > this isn't a use case we really intended to support. > > > I lean toward something that just did not allow the out-of-band channel > negotiation be used until it was set up. > > But whatever we do, not option 1 > > > > > > > > > > > > --0000000000004b141d056e8dc7bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It sounds like you and Christer are suggesting the same th= ing: "don't allow messages to be sent until you're sure the ot= her peer has a channel to receive them". Except that there's no wa= y for the WebRTC stack to know that, since these channels are not signaled = in SDP or any in-band message.

On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <fluff= y@iii.ca> wrote:
<= br>

On May 31, 2018, at 12:24 PM, Ta= ylor Brandstetter <deadbeef=3D40google.com@dmarc.ietf.org> = wrote:

One might expect that a "reliable" = data channel is guaranteed to be, well, reliable. But in current implementa= tions, the first messages may be lost if the application is negotiating the= channels out-of-band, and creates the receiving channel too late.

Here's a fiddle that demonstrates this (happens with C= hrome and Firefox): https://jsfiddle.net/o2m8tp20/

Normally = this isn't an issue, because a typical application would create the out= -of-band negotiated channels before the first offer/answer is complete, and= thus before the SCTP association is established. Meaning that by the time = a data channel is "open", it's guaranteed that the other peer= has a corresponding channel.

But if for whatever = reason, an application creates a data channel *after* the SCTP association = is established, then it will instantly be "open" as soon as it= 9;s created. If a message is sent at this point, and it's received by t= he other peer before it's created its corresponding data channel, then = the message will just be discarded.

So, how should= we deal with this? Some possibilities:
  1. Say "t= his is expected behavior" and document it better, breaking the reliabi= lity promise.
  2. Run the closing procedure if a message is received on= a stream before a data channel is ready to receive it.
  3. Don't e= ven allow an out-of-band negotiated channel to be created after the SCTP as= sociation is established.
  4. Buffer these messages for up to X seconds= (or up to X bytes), to be delivered to the data channel once it's crea= ted. Run the closing procedure if X is exceeded.
I'd vote= for #2. Adding additional buffering logic seems like overkill if this isn&= #39;t a use case we really intended to support.

I lean toward something that just did not al= low the =C2=A0out-of-band channel negotiation be used until it was set up.<= /div>

But whatever we do, not option 1=C2=A0
<= br>




= =C2=A0





--0000000000004b141d056e8dc7bf-- From nobody Wed Jun 13 23:11:11 2018 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 8BE4A1310D2 for ; Wed, 13 Jun 2018 23:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 gN7iD3NrzGIu for ; Wed, 13 Jun 2018 23:10:10 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844B51310FC for ; Wed, 13 Jun 2018 23:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1528956606; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c7NYH9BBS91kTK2TLJGtqejJQJlY/7tANQISEcOYhx4=; b=U/etlB9UVSOhl/M1PYFF+iaRg1xo1maZbXwrtUGBeKs0n00fGncMT5sMn6+nqzlf EYftpQt03IAcjTYkYQGCdeUDk4YZj9qa1qkwsU7H3Xb7i1hXmlVFsoEM91gkbW/B mkAl0MKNlJrKYksVb3KjpZTuL3YME711PQyFPik9rsc=; X-AuditID: c1b4fb3a-dcb6e9c0000079c1-5f-5b2206bedc42 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1E.A0.31169.EB6022B5; Thu, 14 Jun 2018 08:10:06 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSHC015.ericsson.se (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 14 Jun 2018 08:09:13 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 14 Jun 2018 08:09:13 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Thu, 14 Jun 2018 08:09:13 +0200 From: Christer Holmberg To: Taylor Brandstetter , "Cullen Jennings" CC: RTCWeb IETF Thread-Topic: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels Thread-Index: AQHT+QykkBgeKHb7x06HnWNksweot6Rel8qAgAAl0ICAAK7QAA== Date: Thu, 14 Jun 2018 06:09:13 +0000 Message-ID: References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.157] Content-Type: multipart/alternative; boundary="_000_D747E0C431570christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsUyM2K7ve4+NqVog4uvjS0eXfax+LD+B6PF 2n/t7A7MHieWXWH1WLLkJ5PH5fMfGQOYo7hsUlJzMstSi/TtErgyXhy6xlTwwbpi790FjA2M Fw27GDk5JARMJN4evsDUxcjFISRwhFFiwdzPrBDOFkaJieseM0I43xglDlz9ywzSIiSwjFHi x9f0LkYODjYBC4nuf9ogYRGBZImNJ5+xgNjMAooSX5bPZwOxhQUKJP5cXcIKUVMoce56LyNI q4iAk8T8e/UgYRYBVYm+g+vBynkFrCWm/X7BArH2OKPE40lHwGZyCgRKnHm/kBHEZhQQk/h+ ag0TxC5xiVtP5jNBfCMgsWTPeWYIW1Ti5eN/YHtFBfQkNpy4zQ4RV5LY0rsFqjdB4sLmRnaI xYISJ2c+YYF4UVuiZfEE9gmMErOQrJiFpGUWkhaIuIHE+3PzmSFsbYllC19D2foSG7+cZYSw rSXOn1zGjqxmASPHKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAGD+45bfVDsaDzx0PMQpw MCrx8Dq+UowWYk0sK67MPcQowcGsJMI7+SdQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9TmkWU kEB6YklqdmpqQWoRTJaJg1OqgdFo6qd/De9Dt706/HSWvXFO5jSvf1MO19UanPdQK+hTUgra eM9co+JIqvUjt7sM1axLY5tfPpqSO5elJrjV3eLJIbEVPKrx1S0y9vLXP9t9O3N7jdD+R/8F GpqDxX92vhHq7/t3cZ9sk0C8dkWWxtMHzoUGV1ky5rFq6c/fWf/y/TkXhVTph0osxRmJhlrM RcWJACxEhgftAgAA Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 06:10:17 -0000 --_000_D747E0C431570christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >It sounds like you and Christer are suggesting the same thing: "don't allo= w messages to be sent until you're sure the other peer has a channel to rec= eive them". Except that there's no way for the WebRTC stack to know that, s= ince these channels are not signaled in SDP or any in-band message. Even if the Web app cannot tell the WebRTC stack when the peer has a data c= hannel, the Web app can still control when it starts sending data on the da= ta channel, can=92t it? Regards, Christer On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings > wrote: On May 31, 2018, at 12:24 PM, Taylor Brandstetter > wrote: One might expect that a "reliable" data channel is guaranteed to be, well, = reliable. But in current implementations, the first messages may be lost if= the application is negotiating the channels out-of-band, and creates the r= eceiving channel too late. Here's a fiddle that demonstrates this (happens with Chrome and Firefox): h= ttps://jsfiddle.net/o2m8tp20/ Normally this isn't an issue, because a typical application would create th= e out-of-band negotiated channels before the first offer/answer is complete= , and thus before the SCTP association is established. Meaning that by the = time a data channel is "open", it's guaranteed that the other peer has a co= rresponding channel. But if for whatever reason, an application creates a data channel *after* t= he SCTP association is established, then it will instantly be "open" as soo= n as it's created. If a message is sent at this point, and it's received by= the other peer before it's created its corresponding data channel, then th= e message will just be discarded. So, how should we deal with this? Some possibilities: 1. Say "this is expected behavior" and document it better, breaking the = reliability promise. 2. Run the closing procedure if a message is received on a stream before= a data channel is ready to receive it. 3. Don't even allow an out-of-band negotiated channel to be created afte= r the SCTP association is established. 4. Buffer these messages for up to X seconds (or up to X bytes), to be d= elivered to the data channel once it's created. Run the closing procedure i= f X is exceeded. I'd vote for #2. Adding additional buffering logic seems like overkill if t= his isn't a use case we really intended to support. I lean toward something that just did not allow the out-of-band channel ne= gotiation be used until it was set up. But whatever we do, not option 1 --_000_D747E0C431570christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <19ED623AF1388E418D30543D53A6FF74@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>It sounds like you and Christer are suggesting the sam= e thing: "don't allow messages to be sent until you're sure the other = peer has a channel to receive them". Except that there's no way for th= e WebRTC stack to know that, since these channels are not signaled in SDP or any in-band message.

Even if the Web app cannot tell the WebRTC stack when the peer has a d= ata channel, the Web app can still control when it starts sending data on t= he data channel, can=92t it?

Regards,

Christer





On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings= <fluffy@iii.ca>= ; wrote:


On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=3D40go= ogle.com@dmarc.ietf.org> wrote:

One might expect that a "reliable" data channel is guarantee= d to be, well, reliable. But in current implementations, the first messages= may be lost if the application is negotiating the channels out-of-band, an= d creates the receiving channel too late.

Here's a fiddle that demonstrates this (happens with Chrome and Firefo= x): https://jsfiddle.net/o2m8tp20/

Normally this isn't an issue, because a typical application would crea= te the out-of-band negotiated channels before the first offer/answer is com= plete, and thus before the SCTP association is established. Meaning that by= the time a data channel is "open", it's guaranteed that the other peer has a corresponding channel.

But if for whatever reason, an application creates a data channel *aft= er* the SCTP association is established, then it will instantly be "op= en" as soon as it's created. If a message is sent at this point, and i= t's received by the other peer before it's created its corresponding data channel, then the message will just be disc= arded.

So, how should we deal with this? Some possibilities:
  1. Say "this is expected behavior" and document it better, break= ing the reliability promise.
  2. Run the closing procedure if a message= is received on a stream before a data channel is ready to receive it.
    3. =
  3. Don't even allow an out-of-band negotiated channel to be created after = the SCTP association is established.
  4. Buffer these messages for up t= o X seconds (or up to X bytes), to be delivered to the data channel once it= 's created. Run the closing procedure if X is exceeded.
I'd vote for #2. Adding additional buffering logic seems like overkill= if this isn't a use case we really intended to support.
I lean toward something that just did not allow the  out-of-band = channel negotiation be used until it was set up.

But whatever we do, not option 1 





 






 --_000_D747E0C431570christerholmbergericssoncom_-- From nobody Thu Jun 14 10:06:10 2018 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 E8E0B130E4A for ; Thu, 14 Jun 2018 10:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 aGV8idyfqb-w for ; Thu, 14 Jun 2018 10:06:06 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988CF1294D0 for ; Thu, 14 Jun 2018 10:06:06 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id d7-v6so4577832uam.13 for ; Thu, 14 Jun 2018 10:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gKkP+S1/NAkJgY3/bOlefhA6viwC+4JXIgAsl1WqXR0=; b=J1bojhKaRIg6/XNPRnBN8xPoRbh4IjkeK0MY2RB2O81JJwdXlFPzqEmf63eS5QCBkq 4oHDY9Fu8EAOq+iK1xzUU1JL5+R9za4Zo67q6UCAhHdYWBaAGaoedbK9EF9BkjV/PjaM vixyxhbStRx+fAyU0q99lsY3ag8mMT925VQulss41PMJqBbbu/L+g/KdsfoqmR/KLcNp h/7vTiDYzPKLs/gIfJSr7XZIri68DU5fDt3L0rWAfP0MITDPHNVCijwhg0LQHBoCrcy9 9DnKbujmx1c5S99BPD7/w7LAcNYkkDgkNHK7XBo7iAXp9BUj3JdMkf5Y4RMNcVLSzQ+4 jmng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gKkP+S1/NAkJgY3/bOlefhA6viwC+4JXIgAsl1WqXR0=; b=OHKSQ/khM+tupznaSrGPZrKuhRdvRoOJttST34M8f+VSB81mJMDri0Di4qFjksuOHp y34Gd9bQP/NPEen0uTuNKgbFFmIkgwFACiLvrtgo4nwXtYUmIZwC+1uXWLJzpxdoZJtS Ir3vUK9PFfdFn73eJph/MhdSEpSTBkhSnekH4SOR/crHztC78Sr83gc8Fua/DjRs9BTQ 7Q57JI3GoP+ZvRhmbWiZqq2LGBJl10VXd02K5VKOzHK+NtHhOZfmmmYMU/bSV+HiObFT sjQWHmLFviyu857uR6XzuTo7Gu4tbeJLuvFaxr3AxiiZf8gr/sIcHGsxdaX2mRMrUaw1 uveA== X-Gm-Message-State: APt69E2dpjaAoYjTGvCJHLjZ1EUpY+lAa5W7azrtiOMQo7j0E51oT4hl B7IwwN3Zvk9cM2pBMiQW8SPohVpQc6I3vOix3ONaQQ== X-Google-Smtp-Source: ADUXVKLOKHu0jXyLmVmlm/Q3OTE+5MOvMQm/6yTZ8s9jGQoDF0syzqp3n0bUnQv+r5T0O4GWZ5hChykDYfjLMIWHSsE= X-Received: by 2002:ab0:718c:: with SMTP id l12-v6mr2413273uao.197.1528995963786; Thu, 14 Jun 2018 10:06:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 10:06:03 -0700 (PDT) In-Reply-To: References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> From: Taylor Brandstetter Date: Thu, 14 Jun 2018 10:06:03 -0700 Message-ID: To: Christer Holmberg Cc: Cullen Jennings , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000004964ea056e9d1d9e" Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 17:06:10 -0000 --0000000000004964ea056e9d1d9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So you're suggesting for the web app to just take care to avoid this? But the point of this thread is to decide what happens if it *doesn't*. On Wed, Jun 13, 2018 at 11:09 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >It sounds like you and Christer are suggesting the same thing: "don't > allow messages to be sent until you're sure the other peer has a channel = to > receive them". Except that there's no way for the WebRTC stack to know > that, since these channels are not signaled in SDP or any in-band message= . > > Even if the Web app cannot tell the WebRTC stack when the peer has a data > channel, the Web app can still control when it starts sending data on the > data channel, can=E2=80=99t it? > > Regards, > > Christer > > > > > > On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings wrote: > >> >> >> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < >> deadbeef=3D40google.com@dmarc.ietf.org> wrote: >> >> One might expect that a "reliable" data channel is guaranteed to be, >> well, reliable. But in current implementations, the first messages may b= e >> lost if the application is negotiating the channels out-of-band, and >> creates the receiving channel too late. >> >> Here's a fiddle that demonstrates this (happens with Chrome and Firefox)= : >> https://jsfiddle.net/o2m8tp20/ >> >> Normally this isn't an issue, because a typical application would create >> the out-of-band negotiated channels before the first offer/answer is >> complete, and thus before the SCTP association is established. Meaning t= hat >> by the time a data channel is "open", it's guaranteed that the other pee= r >> has a corresponding channel. >> >> But if for whatever reason, an application creates a data channel *after= * >> the SCTP association is established, then it will instantly be "open" as >> soon as it's created. If a message is sent at this point, and it's recei= ved >> by the other peer before it's created its corresponding data channel, th= en >> the message will just be discarded. >> >> So, how should we deal with this? Some possibilities: >> >> 1. Say "this is expected behavior" and document it better, breaking >> the reliability promise. >> 2. Run the closing procedure if a message is received on a stream >> before a data channel is ready to receive it. >> 3. Don't even allow an out-of-band negotiated channel to be created >> after the SCTP association is established. >> 4. Buffer these messages for up to X seconds (or up to X bytes), to >> be delivered to the data channel once it's created. Run the closing >> procedure if X is exceeded. >> >> I'd vote for #2. Adding additional buffering logic seems like overkill i= f >> this isn't a use case we really intended to support. >> >> >> I lean toward something that just did not allow the out-of-band channel >> negotiation be used until it was set up. >> >> But whatever we do, not option 1 >> >> >> >> >> >> >> >> >> >> >> >> > --0000000000004964ea056e9d1d9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So you're suggesting for the web app to just take care= to avoid this? But the point of this thread is to decide what happens if i= t *doesn't*.

On Wed, Jun 13, 2018 at 11:09 PM, Christer Holmberg = <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>It sounds like you and Christer are suggesting the sam= e thing: "don't allow messages to be sent until you're sure th= e other peer has a channel to receive them". Except that there's n= o way for the WebRTC stack to know that, since these channels are not signaled in SDP or any in-band message.

Even if the Web app cannot tell the WebRTC stack when the peer = has a data channel, the Web app can still control when it starts sending da= ta on the data channel, can=E2=80=99t it?

Regards,

Christer





On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings= <fluffy@iii.ca>= ; wrote:


On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=3D40go= ogle.com@dmarc.ietf.org> wrote:

One might expect that a "reliable" data channel is guarantee= d to be, well, reliable. But in current implementations, the first messages= may be lost if the application is negotiating the channels out-of-band, an= d creates the receiving channel too late.

Here's a fiddle that demonstrates this (happens with Chrome and Fi= refox): https://jsfiddle.net/o2m8tp20/

Normally this isn't an issue, because a typical application would = create the out-of-band negotiated channels before the first offer/answer is= complete, and thus before the SCTP association is established. Meaning tha= t by the time a data channel is "open", it's guaranteed that the other peer has a corresponding channel.

But if for whatever reason, an application creates a data channel *aft= er* the SCTP association is established, then it will instantly be "op= en" as soon as it's created. If a message is sent at this point, a= nd it's received by the other peer before it's created its corresponding data channel, then the message will just be disc= arded.

So, how should we deal with this? Some possibilities:
  1. Say "this is expected behavior" and document it better, break= ing the reliability promise.
  2. Run the closing procedure if a message= is received on a stream before a data channel is ready to receive it.
    3. =
  3. Don't even allow an out-of-band negotiated channel to be created af= ter the SCTP association is established.
  4. Buffer these messages for = up to X seconds (or up to X bytes), to be delivered to the data channel onc= e it's created. Run the closing procedure if X is exceeded.
I'd vote for #2. Adding additional buffering logic seems like over= kill if this isn't a use case we really intended to support.
I lean toward something that just did not allow the =C2=A0out-of-band = channel negotiation be used until it was set up.

But whatever we do, not option 1=C2=A0





=C2=A0

--0000000000004964ea056e9d1d9e-- From nobody Thu Jun 14 10:14:56 2018 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 BA9A2130E57 for ; Thu, 14 Jun 2018 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 ODws9v380izy for ; Thu, 14 Jun 2018 10:14:52 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14702130E52 for ; Thu, 14 Jun 2018 10:14:52 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a3-v6so9743782itd.0 for ; Thu, 14 Jun 2018 10:14:52 -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=ZE/FZDKtiPK7cqrLF2tcOZ+ajwJ0HhdZbFGYw4+OgQY=; b=i4Q/p1AFZTudYuGYSlWS/oPq+DOgAxSSweymYQQ3LP/Bmp/f0mm4UGb4zB8sCkGNAB ItPAfHJ0NoqAnmPWrBmeFuxU841LbK5efk+GoIs0JR7fPsmIc3pX4WOf/Fo9EZkDEH7t 3wJWzALR4pTu+uifdnuYNnzDioCjd4PGEwnqy4/siflrAKuDOO5G/xJFdpiK+cAcLdm3 xMu8Jr53ahmxjbQ9Owb+2ejQU8gTxwcIzjqClNBh1kHjq9KyeQ/CyCJMnfnQ5cxs9csS 7lSu5B985I1WEeI7ti57UiipZ7dFRNLfUFGK3VTbVPXxdfs9KyDaNOc2q6Iz/u6ImOvk KACA== 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=ZE/FZDKtiPK7cqrLF2tcOZ+ajwJ0HhdZbFGYw4+OgQY=; b=AMizbkTcSFMKNI0gasJE/t6aB3IZaDLJAHIxWikGnhrLoIRgjBlGiRsvaCzMceXyPW XfDn7/fQdp5E+T//fIOCEgkpPQMoso8FdsfNcTpWZvzqT/WlCQIRRX0KnYMsN2diBCZ/ pLIRUZtO+W3txuUc/xw5Meuco+A10H70k5f3v+w23veO2S2TC8gooRRad26oSOxpEhQe c+XILxnfxHsmv3BtqeUd7azLZWpFtiQc4A487RfJBaAj/D0KFzyojGuEZbOrie5jjbMT c3Xgkecy91qv6Vd8/uExPUIclzWZaF4JXPefgn7vVF/Wzd3ta57lrv+/7KMjo67FN/BK 4l6A== X-Gm-Message-State: APt69E38TTdOu0Lrte+1uKR9U3UDzbu0NykmUCGLgYe+x8Xzn3sB24RP wnahARIBxsMIqvQjFinRrRcc/fu7o41RekL560awXA== X-Google-Smtp-Source: ADUXVKJyPd3nhqneNq7/yFIxWm3ex8f7chFzqpnwRrHnRdD3O4Ch4tPxybZ53QiWNB/u8GjTUJtCAZeFmd1ZLhqNQL0= X-Received: by 2002:a24:7582:: with SMTP id y124-v6mr2927339itc.115.1528996490932; Thu, 14 Jun 2018 10:14:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 14 Jun 2018 10:14:39 -0700 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF , youenn fablet , Sean Turner Content-Type: multipart/alternative; boundary="000000000000b536f2056e9d3c2a" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 17:14:55 -0000 --000000000000b536f2056e9d3c2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a valid concern, but keep in mind that this only applies to: - apps without gUM permission (or else they can use Mode 1) - on networks that don't support IPv6 (or else they can use the RFC 4941 v6 address) - on networks where mDNS is turned off or constrained I tend to think this is still a pretty good tradeoff. One other option could be to add a new Mode 1.5 that did hand out the private IP which could be selected by domain admins, but given how subtle this area is, I tend to think that it would rarely, if ever, be enabled. On Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings wrote: > > > With my individual hat on =E2=80=A6 > > I have a bunch of concerns about this but the biggest is that mDNS does > not work on a large percentage of medium and large corporate WiFI Network= s. > The problem is the large multicast domains trash the WiFi performance so > many APs turn off mDNS or limit it=E2=80=99s range to much less than the = scope of > where just testing the address with ICE would be routable. It=E2=80=99s e= xactly > theses environment where using the local IP vs a TURN IP provides lots of > benefit. I like the idea of trying to use mDNS but I=E2=80=99d want tot = see strong > evidence it worked in theses environments before putting it in at the las= t > minute. > > > > On Jun 11, 2018, at 6:40 PM, Justin Uberti < > juberti=3D40google.com@dmarc.ietf.org> wrote: > > The Safari team has come up with a clever approach to avoid disclosing > private IP addresses for host candidates. As discussed in this WebKit bug > , the technique works a= s > follows: > > 1. Register a random UUID-based mDNS name when ICE gathering starts > 2. Replace the private IP address by a "{UUID}.local" string in each > host candidate (and set raddr to 0.0.0.0 for other candidates) > 3. The other party will do mDNS resolution on any candidate having a > .local suffix, similar to how hostnames in candidates are handled in R= FC > 5245, Section 15.1. > > This technique is relevant to the IP handling document, as it addresses > one of the lesser problems (private IP disclosure) from the overall probl= em > statement. While I don't think this will have a large impact on the > document, including the default mode selection, incorporating this > technique would result in some moderate changes: > > - Section 5.1 would mention concealing private IPs in the default case > as an explicit goal. > - In Section 6, Mode 2 would change from handling out private IPs to > handing out mDNS names. > - This document would have to describe the technique or point to > another document that describes the technique. mmusic-ice-sip-sdp, > Section 4.1 > seems > like a good option, as it already covers how to handle DNS names in IC= E > candidates. > > This is a significant improvement and I think we will want to incorporate > this suggestion. Is this something we could do as part of this WGLC, or > should we look for another option? > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --000000000000b536f2056e9d3c2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a valid concern, but keep in mind that this only a= pplies to:
- apps without gUM permission (or else they can use Mode= 1)
- on networks that don't support IPv6 (or else they can u= se the RFC 4941 v6 address)
- on networks where mDNS is turned of= f or constrained

I tend to think this is still a p= retty good tradeoff.=C2=A0

One other option could = be to add a new Mode 1.5 that did hand out the private IP which could be se= lected by domain admins, but given how subtle this area is, I tend to think= that it would rarely, if ever, be enabled.

On Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings= <fluffy@iii.ca> wrote:


With my individual hat = on =E2=80=A6

I have a bunch of concerns about this but t= he biggest is that mDNS does not work on a large percentage of medium and l= arge corporate WiFI Networks. The problem is the large multicast domains tr= ash the WiFi performance so many APs turn off mDNS or limit it=E2=80=99s ra= nge to much less than the scope of where just testing the address with ICE = would be routable. It=E2=80=99s exactly theses environment where using the = local IP vs a TURN IP provides lots of benefit.=C2=A0 I like the idea of tr= ying to use mDNS but I=E2=80=99d want tot see strong evidence it worked in = theses environments before putting it in at the last minute.=C2=A0



On Jun 11, 201= 8, at 6:40 PM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org&= gt; wrote:

The Safari team has come up with a clever approach= to avoid disclosing private IP addresses for host candidates. As discussed= in this WebKit bug, the technique works as follows:
<= ol>
  • Register a random UUID-based mDNS name when ICE gathering starts
    =
  • Replace the private IP address by a "{UUID}.local" strin= g in each host candidate (and set raddr to 0.0.0.0 for other candidates)
  • The other party will do mDNS resolution on any candidate having a= .local suffix, similar to how hostnames in candidates are handled in RFC 5= 245, Section 15.1.
    • This technique is relevant to the IP h= andling document, as it addresses one of the lesser problems (private IP di= sclosure) from the overall problem statement. While I don't think this = will have a large impact on the document, including the default mode select= ion, incorporating this technique would result in some moderate changes:
    • Section 5.1 would mention concealing private IP= s in the default case as an explicit goal.
    • In Section 6, Mode 2 wou= ld change from handling out private IPs to handing out mDNS names.
    • = This document would have to describe the technique or point to another docu= ment that describes the technique. mmusic-ice-s= ip-sdp, Section 4.1=C2=A0seems like a good option, as it already covers= how to handle DNS names in ICE candidates.
    This is a signifi= cant improvement and I think we will want to incorporate this suggestion. I= s this something we could do as part of this WGLC, or should we look for an= other option?
    _______________________________________________
    rtcweb mailing list
    <= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
    = = https://www.ietf.org/mailman/listinfo/rtcweb

    --000000000000b536f2056e9d3c2a-- From nobody Thu Jun 14 10:34:46 2018 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 A9ED2130F26 for ; Thu, 14 Jun 2018 10:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 Wt7TrWx7R792 for ; Thu, 14 Jun 2018 10:34:30 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (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 76B9D130F2D for ; Thu, 14 Jun 2018 10:34:30 -0700 (PDT) Received: (qmail 20291 invoked from network); 14 Jun 2018 17:34:28 -0000 X-APM-Authkey: 255286/0(159927/0) 2011 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 14 Jun 2018 17:34:28 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 8FCF618A034F; Thu, 14 Jun 2018 18:34:28 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MW9Q63lFY3WE; Thu, 14 Jun 2018 18:34:28 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 5372118A01C6; Thu, 14 Jun 2018 18:34:28 +0100 (BST) From: T H Panton Message-Id: <54A66854-7212-49CE-B164-A9F1E83B4802@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_D2855255-D8C8-45A7-822E-A0B4CC2BD496" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 14 Jun 2018 18:34:27 +0100 In-Reply-To: Cc: Cullen Jennings , RTCWeb IETF , youenn fablet To: Justin Uberti References: X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 17:34:44 -0000 --Apple-Mail=_D2855255-D8C8-45A7-822E-A0B4CC2BD496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In the case of Burningman/town-hall intranet meeting - the side = _sending_ the media would presumably have GUM permissions, so be advertising it's 'private' IPv4s - I guess we might get a direct = connection set up via peer-reflexives discovered that way. T. > On 14 Jun 2018, at 18:14, Justin Uberti = wrote: >=20 > This is a valid concern, but keep in mind that this only applies to: > - apps without gUM permission (or else they can use Mode 1) > - on networks that don't support IPv6 (or else they can use the RFC = 4941 v6 address) > - on networks where mDNS is turned off or constrained >=20 > I tend to think this is still a pretty good tradeoff.=20 >=20 > One other option could be to add a new Mode 1.5 that did hand out the = private IP which could be selected by domain admins, but given how = subtle this area is, I tend to think that it would rarely, if ever, be = enabled. >=20 > On Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings > wrote: >=20 >=20 > With my individual hat on =E2=80=A6 >=20 > I have a bunch of concerns about this but the biggest is that mDNS = does not work on a large percentage of medium and large corporate WiFI = Networks. The problem is the large multicast domains trash the WiFi = performance so many APs turn off mDNS or limit it=E2=80=99s range to = much less than the scope of where just testing the address with ICE = would be routable. It=E2=80=99s exactly theses environment where using = the local IP vs a TURN IP provides lots of benefit. I like the idea of = trying to use mDNS but I=E2=80=99d want tot see strong evidence it = worked in theses environments before putting it in at the last minute.=20= >=20 >=20 >=20 >> On Jun 11, 2018, at 6:40 PM, Justin Uberti = > wrote: >>=20 >> The Safari team has come up with a clever approach to avoid = disclosing private IP addresses for host candidates. As discussed in = this WebKit bug , the = technique works as follows: >> Register a random UUID-based mDNS name when ICE gathering starts >> Replace the private IP address by a "{UUID}.local" string in each = host candidate (and set raddr to 0.0.0.0 for other candidates) >> The other party will do mDNS resolution on any candidate having a = .local suffix, similar to how hostnames in candidates are handled in RFC = 5245, Section 15.1. >> This technique is relevant to the IP handling document, as it = addresses one of the lesser problems (private IP disclosure) from the = overall problem statement. While I don't think this will have a large = impact on the document, including the default mode selection, = incorporating this technique would result in some moderate changes: >> Section 5.1 would mention concealing private IPs in the default case = as an explicit goal. >> In Section 6, Mode 2 would change from handling out private IPs to = handing out mDNS names. >> This document would have to describe the technique or point to = another document that describes the technique. mmusic-ice-sip-sdp, = Section 4.1 = = seems like a good option, as it already covers how to handle DNS names = in ICE candidates. >> This is a significant improvement and I think we will want to = incorporate this suggestion. Is this something we could do as part of = this WGLC, or should we look for another option? >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_D2855255-D8C8-45A7-822E-A0B4CC2BD496 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = the case of Burningman/town-hall intranet meeting - the side _sending_ = the media would presumably have GUM permissions,
    so be = advertising it's 'private' IPv4s - I guess we might get a direct = connection set up via peer-reflexives discovered that way.

    T.


    On 14 Jun 2018, at 18:14, Justin Uberti = <juberti=3D40google.com@dmarc.ietf.org> wrote:

    This is a valid concern, but keep in mind that this only = applies to:
    - apps without gUM permission = (or else they can use Mode 1)
    - on networks that = don't support IPv6 (or else they can use the RFC 4941 v6 = address)
    - on networks where mDNS is turned off or = constrained

    I = tend to think this is still a pretty good tradeoff. 

    One other option could = be to add a new Mode 1.5 that did hand out the private IP which could be = selected by domain admins, but given how subtle this area is, I tend to = think that it would rarely, if ever, be enabled.

    On = Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings <fluffy@iii.ca> wrote:


    With my individual hat on =E2=80=A6

    I have a bunch of concerns about this = but the biggest is that mDNS does not work on a large percentage of = medium and large corporate WiFI Networks. The problem is the large = multicast domains trash the WiFi performance so many APs turn off mDNS = or limit it=E2=80=99s range to much less than the scope of where just = testing the address with ICE would be routable. It=E2=80=99s exactly = theses environment where using the local IP vs a TURN IP provides lots = of benefit.  I like the idea of trying to use mDNS but I=E2=80=99d = want tot see strong evidence it worked in theses environments before = putting it in at the last minute. 



    On Jun = 11, 2018, at 6:40 PM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

    The Safari team has come up with = a clever approach to avoid disclosing private IP addresses for host = candidates. As discussed in this WebKit bug, the technique works as = follows:
    1. Register a random UUID-based mDNS name when ICE gathering = starts
    2. Replace the private IP address = by a "{UUID}.local" string in each host candidate (and set raddr to = 0.0.0.0 for other candidates)
    3. The = other party will do mDNS resolution on any candidate having a .local = suffix, similar to how hostnames in candidates are handled in RFC 5245, = Section 15.1.
    This technique is = relevant to the IP handling document, as it addresses one of the lesser = problems (private IP disclosure) from the overall problem statement. = While I don't think this will have a large impact on the document, = including the default mode selection, incorporating this technique would = result in some moderate changes:
    • Section 5.1 would mention concealing private = IPs in the default case as an explicit goal.
    • In = Section 6, Mode 2 would change from handling out private IPs to handing = out mDNS names.
    • This document would have to describe = the technique or point to another document that describes the technique. = mmusic-ice-sip-sdp, Section = 4.1 seems like a good option, as it already covers how to = handle DNS names in ICE candidates.
    This is a = significant improvement and I think we will want to incorporate this = suggestion. Is this something we could do as part of this WGLC, or = should we look for another option?
    _______________________________________________
    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=_D2855255-D8C8-45A7-822E-A0B4CC2BD496-- From nobody Thu Jun 14 11:14:05 2018 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 93FE4130E6B for ; Thu, 14 Jun 2018 11:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZoXaFIR3PBb for ; Thu, 14 Jun 2018 11:14:01 -0700 (PDT) Received: from smtp89.ord1d.emailsrvr.com (smtp89.ord1d.emailsrvr.com [184.106.54.89]) (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 28E09130E61 for ; Thu, 14 Jun 2018 11:14:01 -0700 (PDT) Received: from smtp20.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp20.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 6BA48C0320; Thu, 14 Jun 2018 14:14:00 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp20.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id F3658C01DB; Thu, 14 Jun 2018 14:13:59 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Thu, 14 Jun 2018 14:14:00 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_B6B4CECF-8B3C-4E71-8723-EAF3BE8F5FA9" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Cullen Jennings In-Reply-To: Date: Thu, 14 Jun 2018 12:13:58 -0600 Cc: RTCWeb IETF , youenn fablet , Sean Turner Message-Id: References: To: Justin Uberti X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 18:14:04 -0000 --Apple-Mail=_B6B4CECF-8B3C-4E71-8723-EAF3BE8F5FA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fair points - I still lean to =E2=80=9Cadd this later=E2=80=9D but I = could live with it either way.=20 > On Jun 14, 2018, at 11:14 AM, Justin Uberti = wrote: >=20 > This is a valid concern, but keep in mind that this only applies to: > - apps without gUM permission (or else they can use Mode 1) > - on networks that don't support IPv6 (or else they can use the RFC = 4941 v6 address) > - on networks where mDNS is turned off or constrained >=20 > I tend to think this is still a pretty good tradeoff.=20 >=20 > One other option could be to add a new Mode 1.5 that did hand out the = private IP which could be selected by domain admins, but given how = subtle this area is, I tend to think that it would rarely, if ever, be = enabled. >=20 > On Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings > wrote: >=20 >=20 > With my individual hat on =E2=80=A6 >=20 > I have a bunch of concerns about this but the biggest is that mDNS = does not work on a large percentage of medium and large corporate WiFI = Networks. The problem is the large multicast domains trash the WiFi = performance so many APs turn off mDNS or limit it=E2=80=99s range to = much less than the scope of where just testing the address with ICE = would be routable. It=E2=80=99s exactly theses environment where using = the local IP vs a TURN IP provides lots of benefit. I like the idea of = trying to use mDNS but I=E2=80=99d want tot see strong evidence it = worked in theses environments before putting it in at the last minute.=20= >=20 >=20 >=20 >> On Jun 11, 2018, at 6:40 PM, Justin Uberti = > wrote: >>=20 >> The Safari team has come up with a clever approach to avoid = disclosing private IP addresses for host candidates. As discussed in = this WebKit bug , the = technique works as follows: >> Register a random UUID-based mDNS name when ICE gathering starts >> Replace the private IP address by a "{UUID}.local" string in each = host candidate (and set raddr to 0.0.0.0 for other candidates) >> The other party will do mDNS resolution on any candidate having a = .local suffix, similar to how hostnames in candidates are handled in RFC = 5245, Section 15.1. >> This technique is relevant to the IP handling document, as it = addresses one of the lesser problems (private IP disclosure) from the = overall problem statement. While I don't think this will have a large = impact on the document, including the default mode selection, = incorporating this technique would result in some moderate changes: >> Section 5.1 would mention concealing private IPs in the default case = as an explicit goal. >> In Section 6, Mode 2 would change from handling out private IPs to = handing out mDNS names. >> This document would have to describe the technique or point to = another document that describes the technique. mmusic-ice-sip-sdp, = Section 4.1 = = seems like a good option, as it already covers how to handle DNS names = in ICE candidates. >> This is a significant improvement and I think we will want to = incorporate this suggestion. Is this something we could do as part of = this WGLC, or should we look for another option? >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb = >=20 --Apple-Mail=_B6B4CECF-8B3C-4E71-8723-EAF3BE8F5FA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    Fair points - I still lean to  =E2=80=9Cadd this = later=E2=80=9D but I could live with it either way. 


    On Jun 14, 2018, at 11:14 AM, Justin Uberti = <juberti@google.com> wrote:

    This is a valid concern, but keep in mind that this only = applies to:
    - apps without gUM permission = (or else they can use Mode 1)
    - on networks that = don't support IPv6 (or else they can use the RFC 4941 v6 = address)
    - on networks where mDNS is turned off or = constrained

    I = tend to think this is still a pretty good tradeoff. 

    One other option could = be to add a new Mode 1.5 that did hand out the private IP which could be = selected by domain admins, but given how subtle this area is, I tend to = think that it would rarely, if ever, be enabled.

    On = Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings <fluffy@iii.ca> wrote:


    With my individual hat on =E2=80=A6

    I have a bunch of concerns about this = but the biggest is that mDNS does not work on a large percentage of = medium and large corporate WiFI Networks. The problem is the large = multicast domains trash the WiFi performance so many APs turn off mDNS = or limit it=E2=80=99s range to much less than the scope of where just = testing the address with ICE would be routable. It=E2=80=99s exactly = theses environment where using the local IP vs a TURN IP provides lots = of benefit.  I like the idea of trying to use mDNS but I=E2=80=99d = want tot see strong evidence it worked in theses environments before = putting it in at the last minute. 



    On Jun = 11, 2018, at 6:40 PM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

    The Safari team has come up with = a clever approach to avoid disclosing private IP addresses for host = candidates. As discussed in this WebKit bug, the technique works as = follows:
    1. Register a random UUID-based mDNS name when ICE gathering = starts
    2. Replace the private IP address = by a "{UUID}.local" string in each host candidate (and set raddr to = 0.0.0.0 for other candidates)
    3. The = other party will do mDNS resolution on any candidate having a .local = suffix, similar to how hostnames in candidates are handled in RFC 5245, = Section 15.1.
    This technique is = relevant to the IP handling document, as it addresses one of the lesser = problems (private IP disclosure) from the overall problem statement. = While I don't think this will have a large impact on the document, = including the default mode selection, incorporating this technique would = result in some moderate changes:
    • Section 5.1 would mention concealing private = IPs in the default case as an explicit goal.
    • In = Section 6, Mode 2 would change from handling out private IPs to handing = out mDNS names.
    • This document would have to describe = the technique or point to another document that describes the technique. = mmusic-ice-sip-sdp, Section = 4.1 seems like a good option, as it already covers how to = handle DNS names in ICE candidates.
    This is a = significant improvement and I think we will want to incorporate this = suggestion. Is this something we could do as part of this WGLC, or = should we look for another option?
    _______________________________________________
    rtcweb = mailing list
    rtcweb@ietf.org
    https://www.ietf.org/mailman/listinfo/rtcweb


    = --Apple-Mail=_B6B4CECF-8B3C-4E71-8723-EAF3BE8F5FA9-- From nobody Thu Jun 14 14:15:41 2018 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 D62B4130F30 for ; Thu, 14 Jun 2018 14:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 x4D_FcYgheT2 for ; Thu, 14 Jun 2018 14:15:37 -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 C748E130F15 for ; Thu, 14 Jun 2018 14:15:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 303FB7C0685 for ; Thu, 14 Jun 2018 23:15:35 +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 TNQBgpYOSqyJ for ; Thu, 14 Jun 2018 23:15:33 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9ECBD7C051F for ; Thu, 14 Jun 2018 23:15:33 +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: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> Date: Thu, 14 Jun 2018 23:15:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.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] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 21:15:40 -0000 I have some worries about this proposal. It seems neat, and solves a specific problem for a specific use case, but it's not a written-up proposal, rather a sketch for one - and I'm afraid of devils in the details. For instance: - If this technique is used for a computer directly connected to the Internet, with a public IP address, it won't communicate - unless it is only used on private addresses - because "uuid.local" doesn't resolve, whereas a public IP address is globally reachable. - The above means that the proposal needs a definition of "private address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6 range is covered by the proposal? - It will only work if the private address usage is the same scope as mDNS resolution. On an unmanaged LAN it works, and on a network with explicit mDNS forwarding it works. But on any other deployment, it forces traffic to go via public IP addresses learned by STUN. I think this is worth adding. Perhaps as a new "mode 2m"? But I'd like a commitment to not adding it until we have a full proposal. Den 12. juni 2018 02:40, skrev Justin Uberti: > The Safari team has come up with a clever approach to avoid disclosing > private IP addresses for host candidates. As discussed in this WebKit > bug , the technique > works as follows: > > 1. Register a random UUID-based mDNS name when ICE gathering starts > 2. Replace the private IP address by a "{UUID}.local" string in each > host candidate (and set raddr to 0.0.0.0 for other candidates) > 3. The other party will do mDNS resolution on any candidate having a > .local suffix, similar to how hostnames in candidates are handled in > RFC 5245, Section 15.1. > > This technique is relevant to the IP handling document, as it addresses > one of the lesser problems (private IP disclosure) from the overall > problem statement. While I don't think this will have a large impact on > the document, including the default mode selection, incorporating this > technique would result in some moderate changes: > > * Section 5.1 would mention concealing private IPs in the default case > as an explicit goal. > * In Section 6, Mode 2 would change from handling out private IPs to > handing out mDNS names. > * This document would have to describe the technique or point to > another document that describes the technique. mmusic-ice-sip-sdp, > Section 4.1 >  seems > like a good option, as it already covers how to handle DNS names in > ICE candidates. > > This is a significant improvement and I think we will want to > incorporate this suggestion. Is this something we could do as part of > this WGLC, or should we look for another option? > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Jun 14 14:32:46 2018 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 B456D130E5A for ; Thu, 14 Jun 2018 14:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 6QAAbcMm1RaS for ; Thu, 14 Jun 2018 14:32:41 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8575812D949 for ; Thu, 14 Jun 2018 14:32:41 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id k17-v6so3498561ita.0 for ; Thu, 14 Jun 2018 14:32: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=PNfzC77MKPo0tZl7+u8H6vN8g7IoaGrut5BIgJM44+c=; b=C+9LZL2rg2MN0tUoH9wutXRfYCJuuR4Y0j8+bpVb54H5JUPUXZae8MMK7kaJZRdIWo V+slDyogUBu8yYGPZ2pKTcFpdnYp1h+3qOoY9MnW3gqrMYbn0ufmAsKlmNVH/RKNfK3f bVioYQe9J5E+xzOqZxR3kvMsuIknZE3MMJ9Pisz0LSvTYoTTotT4Mv+JfJjWGH786U01 nMdToSLbXPU2Y9YZW0z1RAJ6jgdwe+GV7msLQbZ1RlZvl6POLt2y9rsmN8rlTdonKIRf BK4OFyh0wfM2qQQKC6Lt0C0k8L2albxC85+jlmyrMUxBIARAP1gYS8EWGJH973C6+I3j aazQ== 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=PNfzC77MKPo0tZl7+u8H6vN8g7IoaGrut5BIgJM44+c=; b=aN70Osp/N+tw3N7UxC7aIGAZ1UvB7P+D/6w0x2XNZYUtJEfG90MFtQ21KH0W9AD2R2 U3NuFTHIJDZDEWDPK9tCltzktnzxIllmLMJMvuraD0ySGHfRvNWm/yizxE3YMTT+TVjO hR+sw1PTaoPy/XZmM83mMyAF6/Q3MXPuvsYTCv/q1X8rsyPHNBkXVAYvSwGvNUY1ujE/ CG3s2D+x0mzAHZ/YfXfDzMzYOvXuOUuGXJXwW9gIJ5tM4Gwq7RGuJdjN07TONsHhZYfn AxH7lht24iPJWSnlAhSOWL5PkKMWg9GI1FaUnEBAgyrKWBKNSdTb/aOeDz0lrmTCI53O WCUg== X-Gm-Message-State: APt69E0ccgxcXeQGkxxMpkbTOvVAhtcFMLS3msYH1XcQ0+gisA56aCRx s70rZPjE89NKmuII0jEphz7IaRd+2Ma3FyPdV1nNR1JigYo= X-Google-Smtp-Source: ADUXVKJ7m9gXR4ifOtVJAGOkrsT/aKMitmu+Fx1SIVKKrnRvRYqveNfW6ptTqKSLPqR9rG4+7MYsdAsPhX1zCvw77Os= X-Received: by 2002:a24:5901:: with SMTP id p1-v6mr3759218itb.119.1529011960496; Thu, 14 Jun 2018 14:32:40 -0700 (PDT) MIME-Version: 1.0 References: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> In-Reply-To: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> From: Justin Uberti Date: Thu, 14 Jun 2018 14:32:28 -0700 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c3fb2f056ea0d6cb" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 21:32:44 -0000 --000000000000c3fb2f056ea0d6cb Content-Type: text/plain; charset="UTF-8" On Thu, Jun 14, 2018 at 2:15 PM Harald Alvestrand wrote: > I have some worries about this proposal. It seems neat, and solves a > specific problem for a specific use case, but it's not a written-up > proposal, rather a sketch for one - and I'm afraid of devils in the > details. > > For instance: > > - If this technique is used for a computer directly connected to the > Internet, with a public IP address, it won't communicate - unless it is > only used on private addresses - because "uuid.local" doesn't resolve, > whereas a public IP address is globally reachable. > - The above means that the proposal needs a definition of "private > address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6 > range is covered by the proposal? > > - It will only work if the private address usage is the same scope as > mDNS resolution. On an unmanaged LAN it works, and on a network with > explicit mDNS forwarding it works. But on any other deployment, it > forces traffic to go via public IP addresses learned by STUN. > > I think this is worth adding. Perhaps as a new "mode 2m"? > > But I'd like a commitment to not adding it until we have a full proposal. > I have sketched out the proposal in https://github.com/juberti/draughts/pull/103, which while not complete, does address most of your questions. > > Den 12. juni 2018 02:40, skrev Justin Uberti: > > The Safari team has come up with a clever approach to avoid disclosing > > private IP addresses for host candidates. As discussed in this WebKit > > bug , the technique > > works as follows: > > > > 1. Register a random UUID-based mDNS name when ICE gathering starts > > 2. Replace the private IP address by a "{UUID}.local" string in each > > host candidate (and set raddr to 0.0.0.0 for other candidates) > > 3. The other party will do mDNS resolution on any candidate having a > > .local suffix, similar to how hostnames in candidates are handled in > > RFC 5245, Section 15.1. > > > > This technique is relevant to the IP handling document, as it addresses > > one of the lesser problems (private IP disclosure) from the overall > > problem statement. While I don't think this will have a large impact on > > the document, including the default mode selection, incorporating this > > technique would result in some moderate changes: > > > > * Section 5.1 would mention concealing private IPs in the default case > > as an explicit goal. > > * In Section 6, Mode 2 would change from handling out private IPs to > > handing out mDNS names. > > * This document would have to describe the technique or point to > > another document that describes the technique. mmusic-ice-sip-sdp, > > Section 4.1 > > < > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1 > > seems > > like a good option, as it already covers how to handle DNS names in > > ICE candidates. > > > > This is a significant improvement and I think we will want to > > incorporate this suggestion. Is this something we could do as part of > > this WGLC, or should we look for another option? > > > > > > _______________________________________________ > > 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 > --000000000000c3fb2f056ea0d6cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Thu= , Jun 14, 2018 at 2:15 PM Harald Alvestrand <harald@alvestrand.no> wrote:
    I have some worries about this proposal. I= t seems neat, and solves a
    specific problem for a specific use case, but it's not a written-up
    proposal, rather a sketch for one - and I'm afraid of devils in the det= ails.

    For instance:

    - If this technique is used for a computer directly connected to the
    Internet, with a public IP address, it won't communicate - unless it is=
    only used on private addresses - because "uuid.local" doesn't= resolve,
    whereas a public IP address is globally reachable.=C2=A0

    - The above means that the proposal needs a definition of "private
    address". Do we mean "private" in the RFC 1918 sense? If so,= which IPv6
    range is covered by the proposal?

    - It will only work if the private address usage is the same scope as
    mDNS resolution. On an unmanaged LAN it works, and on a network with
    explicit mDNS forwarding it works. But on any other deployment, it
    forces traffic to go via public IP addresses learned by STUN.

    I think this is worth adding. Perhaps as a new "mode 2m"?

    But I'd like a commitment to not adding it until we have a full proposa= l.

    I have sketched out the proposal in= =C2=A0https://gith= ub.com/juberti/draughts/pull/103, which while not complete, does addres= s most of your questions.

    Den 12. juni 2018 02:40, skrev Justin Uberti:
    > The Safari team has come up with a clever approach to avoid disclosing=
    > private IP addresses for host candidates. As discussed in this WebKit<= br> > bug <https://bugs.webkit.org/show_bug.cgi?id= =3D174500>, the technique
    > works as follows:
    >
    >=C2=A0 1. Register a random UUID-based mDNS name when ICE gathering sta= rts
    >=C2=A0 2. Replace the private IP address by a "{UUID}.local" = string in each
    >=C2=A0 =C2=A0 =C2=A0host candidate (and set raddr to 0.0.0.0 for other = candidates)
    >=C2=A0 3. The other party will do mDNS resolution on any candidate havi= ng a
    >=C2=A0 =C2=A0 =C2=A0.local suffix, similar to how hostnames in candidat= es are handled in
    >=C2=A0 =C2=A0 =C2=A0RFC 5245, Section 15.1.
    >
    > This technique is relevant to the IP handling document, as it addresse= s
    > one of the lesser problems (private IP disclosure) from the overall > problem statement. While I don't think this will have a large impa= ct on
    > the document, including the default mode selection, incorporating this=
    > technique would result in some moderate changes:
    >
    >=C2=A0 =C2=A0* Section 5.1 would mention concealing private IPs in the = default case
    >=C2=A0 =C2=A0 =C2=A0as an explicit goal.
    >=C2=A0 =C2=A0* In Section 6, Mode 2 would change from handling out priv= ate IPs to
    >=C2=A0 =C2=A0 =C2=A0handing out mDNS names.
    >=C2=A0 =C2=A0* This document would have to describe the technique or po= int to
    >=C2=A0 =C2=A0 =C2=A0another document that describes the technique. mmus= ic-ice-sip-sdp,
    >=C2=A0 =C2=A0 =C2=A0Section 4.1
    >=C2=A0 =C2=A0 =C2=A0<= https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1>=C2=A0seems
    >=C2=A0 =C2=A0 =C2=A0like a good option, as it already covers how to han= dle DNS names in
    >=C2=A0 =C2=A0 =C2=A0ICE candidates.
    >
    > This is a significant improvement and I think we will want to
    > incorporate this suggestion. Is this something we could do as part of<= br> > this WGLC, or should we look for another option?
    >
    >
    > _______________________________________________
    > 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
    --000000000000c3fb2f056ea0d6cb-- From nobody Thu Jun 14 14:41:05 2018 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 AF6FA12D949 for ; Thu, 14 Jun 2018 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Y8xHhGP6OBoE for ; Thu, 14 Jun 2018 14:41:00 -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 63929130E5A for ; Thu, 14 Jun 2018 14:40:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D544F7C0685 for ; Thu, 14 Jun 2018 23:40:57 +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 pIOal0oyXC5v for ; Thu, 14 Jun 2018 23:40:56 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9FFB47C051F for ; Thu, 14 Jun 2018 23:40:56 +0200 (CEST) To: rtcweb@ietf.org References: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> 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: <84521828-4669-06b7-d0e8-7c1c31bae6bf@alvestrand.no> Date: Thu, 14 Jun 2018 23:40:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 14 Jun 2018 21:41:04 -0000 I found Justin's specific proposal after I sent my previous message. Apologies for not reading the whole thread. Detailed comments have been entered on the PR. Den 14. juni 2018 23:15, skrev Harald Alvestrand: > I have some worries about this proposal. It seems neat, and solves a > specific problem for a specific use case, but it's not a written-up > proposal, rather a sketch for one - and I'm afraid of devils in the details. > > For instance: > > - If this technique is used for a computer directly connected to the > Internet, with a public IP address, it won't communicate - unless it is > only used on private addresses - because "uuid.local" doesn't resolve, > whereas a public IP address is globally reachable. > > - The above means that the proposal needs a definition of "private > address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6 > range is covered by the proposal? > > - It will only work if the private address usage is the same scope as > mDNS resolution. On an unmanaged LAN it works, and on a network with > explicit mDNS forwarding it works. But on any other deployment, it > forces traffic to go via public IP addresses learned by STUN. > > I think this is worth adding. Perhaps as a new "mode 2m"? > > But I'd like a commitment to not adding it until we have a full proposal. > > Den 12. juni 2018 02:40, skrev Justin Uberti: >> The Safari team has come up with a clever approach to avoid disclosing >> private IP addresses for host candidates. As discussed in this WebKit >> bug , the technique >> works as follows: >> >> 1. Register a random UUID-based mDNS name when ICE gathering starts >> 2. Replace the private IP address by a "{UUID}.local" string in each >> host candidate (and set raddr to 0.0.0.0 for other candidates) >> 3. The other party will do mDNS resolution on any candidate having a >> .local suffix, similar to how hostnames in candidates are handled in >> RFC 5245, Section 15.1. >> >> This technique is relevant to the IP handling document, as it addresses >> one of the lesser problems (private IP disclosure) from the overall >> problem statement. While I don't think this will have a large impact on >> the document, including the default mode selection, incorporating this >> technique would result in some moderate changes: >> >> * Section 5.1 would mention concealing private IPs in the default case >> as an explicit goal. >> * In Section 6, Mode 2 would change from handling out private IPs to >> handing out mDNS names. >> * This document would have to describe the technique or point to >> another document that describes the technique. mmusic-ice-sip-sdp, >> Section 4.1 >>  seems >> like a good option, as it already covers how to handle DNS names in >> ICE candidates. >> >> This is a significant improvement and I think we will want to >> incorporate this suggestion. Is this something we could do as part of >> this WGLC, or should we look for another option? >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Jun 15 06:18:01 2018 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 9E539130E73 for ; Fri, 15 Jun 2018 06:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 zyyKOSL5qFoO for ; Fri, 15 Jun 2018 06:17:57 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36053130DE0 for ; Fri, 15 Jun 2018 06:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529068675; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QFRhIhCKqn4xorRR85EjSGDCMiNRjcvaMsyE01n7lig=; b=Q+bZjBSSCP6fg8spxfuUMnaKCfELKkSJLrFYXjW1FZIH9j6/cgJD6Xn2rHSZIX+7 VG7aF8Lop3I0lSU9datxBwLrkylZj0hcf0FNnvv3/WYokLW6ojGYzlYySpvXBsLE PNYlg21kmbSkSxQgIo/Dv4LCw4AAVPt9bPWdk9bAxcA=; X-AuditID: c1b4fb25-97bdd9c000007b3f-91-5b23bc83e22f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 30.77.31551.38CB32B5; Fri, 15 Jun 2018 15:17:55 +0200 (CEST) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSHC011.ericsson.se (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 15 Jun 2018 15:17:36 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 15 Jun 2018 15:17:35 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Fri, 15 Jun 2018 15:17:35 +0200 From: Christer Holmberg To: Taylor Brandstetter CC: Cullen Jennings , RTCWeb IETF Thread-Topic: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels Thread-Index: AQHT+QykkBgeKHb7x06HnWNksweot6Rel8qAgAAl0ICAAK7QAIAAg+iAgAF0CMY= Date: Fri, 15 Jun 2018 13:17:35 +0000 Message-ID: <7EE07FBB-40FA-4E1D-BB51-5060F92CF4A2@ericsson.com> References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7EE07FBB40FA4E1DBB515060F92CF4A2ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7sW7zHuVog46J4haXVzxktfiw/gej xdp/7ewOzB4LNpV6LFnyk8nj8vmPjAHMUVw2Kak5mWWpRfp2CVwZp1r2sBasS6tY8vcDewPj ieQuRg4OCQETiUW/+LsYuTiEBI4wSrxsWcoG4WxhlJjwfRsrhPONUeLhpZlAGU4gZxmjRFuj HUg3m4CFRPc/bZCwiICuxM2vC8FKmAWcJK7e3MEOYgsLFEj8ubqEFaKmUOLc9V5GCNtP4vTk HrB6FgFViVM/+8BqeAXsJVbebWWG2LuPSeLdtO/MIAlOgUCJ1gVrwIYyCohJfD+1hglimbjE rSfzwWwJAQGJJXvOM0PYohIvH/9jhahJlmiZMQlqgaDEyZlPWCB+0ZZoWTyBfQKj2Cwko2Yh aZmFpGUW0MvMApoS63fpQ5QoSkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGxXmpRZnJx cX6eXl5qySZGYGQe3PJbdQfj5TeOhxgFOBiVeHgPLVGOFmJNLCuuzD3EKMHBrCTC21uiFC3E m5JYWZValB9fVJqTWnyIUZqDRUmc96H55ighgfTEktTs1NSC1CKYLBMHp1QDY60ye/xyraOb LJwFpDnTbt97qnpgul793adnL871fjjTsnTh3tyuyPUeWw/dSz/C9zVFrz5jU71w/74Zh7x5 a+Iiz/Xc2xO/lj858NNyt5NnD+r5GO5fFL0wqmr+a8W/Go9Tr1b5JTTZhB+/9Plh4UzPo6kn XxfOX3JBP95UdX+lHZPwMaNp5UosxRmJhlrMRcWJABcsBaDIAgAA Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 13:18:00 -0000 --_000_7EE07FBB40FA4E1DBB515060F92CF4A2ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBoYXBwZW5zIGlmIGl0IGRvZXNu4oCZdCBzaG91bGQgYmUgdW5zcGVjaWZpZWQgaW4gbXkg b3Bpbmlvbi4gVGhlIGltcG9ydGFudCB0aGluZyB0byBwb2ludCBvdXQgaXMgdGhhdCB0aGUgcmVs aWFiaWxpdHkgb2YgdGhlIGRhdGEgY2hhbm5lbCBkb2VzbuKAmXQgYXBwbHkgdW50aWwgYm90aCBw ZWVycyBoYXZlIG9wZW5lZCB0aGUgZGF0YSBjaGFubmVsLiBIb3cgdGhlIHBlZXJzIGluZm9ybSBl YWNoIG90aGVyIGFib3V0IHRoYXQgaXMgc2lnbmFsaW5nIHByb3RvY29sIHNwZWNpZmljLg0KDQpB cyBhIGZ1dHVyZSBleHRlbnNpb24gLCBldmVuIGlmIGEgZGF0YSBjaGFubmVsIGlzIG5lZ290aWF0 ZWQgb3V0LW9mLWJhbmQsIHdlIGNvdWxkIGRlZmluZSB0aGF0IGFuIGluLWJhbmQgaGFuZHNoYWtl IHN0aWxsIHRha2VzIHBsYWNlIGJlZm9yZSBhbnkgZGF0YSBpcyBzZW50Lg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIDE0IEp1biAyMDE4LCBhdCAx OS4wNiwgVGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbTxtYWlsdG86ZGVh ZGJlZWZAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpTbyB5b3UncmUgc3VnZ2VzdGluZyBmb3IgdGhl IHdlYiBhcHAgdG8ganVzdCB0YWtlIGNhcmUgdG8gYXZvaWQgdGhpcz8gQnV0IHRoZSBwb2ludCBv ZiB0aGlzIHRocmVhZCBpcyB0byBkZWNpZGUgd2hhdCBoYXBwZW5zIGlmIGl0ICpkb2Vzbid0Ki4N Cg0KT24gV2VkLCBKdW4gMTMsIDIwMTggYXQgMTE6MDkgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCj5JdCBzb3VuZHMgbGlrZSB5b3UgYW5kIENocmlz dGVyIGFyZSBzdWdnZXN0aW5nIHRoZSBzYW1lIHRoaW5nOiAiZG9uJ3QgYWxsb3cgbWVzc2FnZXMg dG8gYmUgc2VudCB1bnRpbCB5b3UncmUgc3VyZSB0aGUgb3RoZXIgcGVlciBoYXMgYSBjaGFubmVs IHRvIHJlY2VpdmUgdGhlbSIuIEV4Y2VwdCB0aGF0IHRoZXJlJ3Mgbm8gd2F5IGZvciB0aGUgV2Vi UlRDIHN0YWNrIHRvIGtub3cgdGhhdCwgc2luY2UgdGhlc2UgY2hhbm5lbHMgYXJlIG5vdCBzaWdu YWxlZCBpbiBTRFAgb3IgYW55IGluLWJhbmQgbWVzc2FnZS4NCg0KRXZlbiBpZiB0aGUgV2ViIGFw cCBjYW5ub3QgdGVsbCB0aGUgV2ViUlRDIHN0YWNrIHdoZW4gdGhlIHBlZXIgaGFzIGEgZGF0YSBj aGFubmVsLCB0aGUgV2ViIGFwcCBjYW4gc3RpbGwgY29udHJvbCB3aGVuIGl0IHN0YXJ0cyBzZW5k aW5nIGRhdGEgb24gdGhlIGRhdGEgY2hhbm5lbCwgY2Fu4oCZdCBpdD8NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQoNCg0KDQpPbiBXZWQsIEp1biAxMywgMjAxOCBhdCAxOjMyIFBNLCBDdWxs ZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZmeUBpaWkuY2E+PiB3cm90ZToN Cg0KDQpPbiBNYXkgMzEsIDIwMTgsIGF0IDEyOjI0IFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIDxk ZWFkYmVlZj00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmRlYWRiZWVmPTQwZ29v Z2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpPbmUgbWlnaHQgZXhwZWN0IHRoYXQg YSAicmVsaWFibGUiIGRhdGEgY2hhbm5lbCBpcyBndWFyYW50ZWVkIHRvIGJlLCB3ZWxsLCByZWxp YWJsZS4gQnV0IGluIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zLCB0aGUgZmlyc3QgbWVzc2FnZXMg bWF5IGJlIGxvc3QgaWYgdGhlIGFwcGxpY2F0aW9uIGlzIG5lZ290aWF0aW5nIHRoZSBjaGFubmVs cyBvdXQtb2YtYmFuZCwgYW5kIGNyZWF0ZXMgdGhlIHJlY2VpdmluZyBjaGFubmVsIHRvbyBsYXRl Lg0KDQpIZXJlJ3MgYSBmaWRkbGUgdGhhdCBkZW1vbnN0cmF0ZXMgdGhpcyAoaGFwcGVucyB3aXRo IENocm9tZSBhbmQgRmlyZWZveCk6IGh0dHBzOi8vanNmaWRkbGUubmV0L28ybTh0cDIwLw0KDQpO b3JtYWxseSB0aGlzIGlzbid0IGFuIGlzc3VlLCBiZWNhdXNlIGEgdHlwaWNhbCBhcHBsaWNhdGlv biB3b3VsZCBjcmVhdGUgdGhlIG91dC1vZi1iYW5kIG5lZ290aWF0ZWQgY2hhbm5lbHMgYmVmb3Jl IHRoZSBmaXJzdCBvZmZlci9hbnN3ZXIgaXMgY29tcGxldGUsIGFuZCB0aHVzIGJlZm9yZSB0aGUg U0NUUCBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZC4gTWVhbmluZyB0aGF0IGJ5IHRoZSB0aW1l IGEgZGF0YSBjaGFubmVsIGlzICJvcGVuIiwgaXQncyBndWFyYW50ZWVkIHRoYXQgdGhlIG90aGVy IHBlZXIgaGFzIGEgY29ycmVzcG9uZGluZyBjaGFubmVsLg0KDQpCdXQgaWYgZm9yIHdoYXRldmVy IHJlYXNvbiwgYW4gYXBwbGljYXRpb24gY3JlYXRlcyBhIGRhdGEgY2hhbm5lbCAqYWZ0ZXIqIHRo ZSBTQ1RQIGFzc29jaWF0aW9uIGlzIGVzdGFibGlzaGVkLCB0aGVuIGl0IHdpbGwgaW5zdGFudGx5 IGJlICJvcGVuIiBhcyBzb29uIGFzIGl0J3MgY3JlYXRlZC4gSWYgYSBtZXNzYWdlIGlzIHNlbnQg YXQgdGhpcyBwb2ludCwgYW5kIGl0J3MgcmVjZWl2ZWQgYnkgdGhlIG90aGVyIHBlZXIgYmVmb3Jl IGl0J3MgY3JlYXRlZCBpdHMgY29ycmVzcG9uZGluZyBkYXRhIGNoYW5uZWwsIHRoZW4gdGhlIG1l c3NhZ2Ugd2lsbCBqdXN0IGJlIGRpc2NhcmRlZC4NCg0KU28sIGhvdyBzaG91bGQgd2UgZGVhbCB3 aXRoIHRoaXM/IFNvbWUgcG9zc2liaWxpdGllczoNCg0KICAxLiAgU2F5ICJ0aGlzIGlzIGV4cGVj dGVkIGJlaGF2aW9yIiBhbmQgZG9jdW1lbnQgaXQgYmV0dGVyLCBicmVha2luZyB0aGUgcmVsaWFi aWxpdHkgcHJvbWlzZS4NCiAgMi4gIFJ1biB0aGUgY2xvc2luZyBwcm9jZWR1cmUgaWYgYSBtZXNz YWdlIGlzIHJlY2VpdmVkIG9uIGEgc3RyZWFtIGJlZm9yZSBhIGRhdGEgY2hhbm5lbCBpcyByZWFk eSB0byByZWNlaXZlIGl0Lg0KICAzLiAgRG9uJ3QgZXZlbiBhbGxvdyBhbiBvdXQtb2YtYmFuZCBu ZWdvdGlhdGVkIGNoYW5uZWwgdG8gYmUgY3JlYXRlZCBhZnRlciB0aGUgU0NUUCBhc3NvY2lhdGlv biBpcyBlc3RhYmxpc2hlZC4NCiAgNC4gIEJ1ZmZlciB0aGVzZSBtZXNzYWdlcyBmb3IgdXAgdG8g WCBzZWNvbmRzIChvciB1cCB0byBYIGJ5dGVzKSwgdG8gYmUgZGVsaXZlcmVkIHRvIHRoZSBkYXRh IGNoYW5uZWwgb25jZSBpdCdzIGNyZWF0ZWQuIFJ1biB0aGUgY2xvc2luZyBwcm9jZWR1cmUgaWYg WCBpcyBleGNlZWRlZC4NCg0KSSdkIHZvdGUgZm9yICMyLiBBZGRpbmcgYWRkaXRpb25hbCBidWZm ZXJpbmcgbG9naWMgc2VlbXMgbGlrZSBvdmVya2lsbCBpZiB0aGlzIGlzbid0IGEgdXNlIGNhc2Ug d2UgcmVhbGx5IGludGVuZGVkIHRvIHN1cHBvcnQuDQoNCkkgbGVhbiB0b3dhcmQgc29tZXRoaW5n IHRoYXQganVzdCBkaWQgbm90IGFsbG93IHRoZSAgb3V0LW9mLWJhbmQgY2hhbm5lbCBuZWdvdGlh dGlvbiBiZSB1c2VkIHVudGlsIGl0IHdhcyBzZXQgdXAuDQoNCkJ1dCB3aGF0ZXZlciB3ZSBkbywg bm90IG9wdGlvbiAxDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg== --_000_7EE07FBB40FA4E1DBB515060F92CF4A2ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpX aGF0IGhhcHBlbnMgaWYgaXQgZG9lc27igJl0IHNob3VsZCBiZSB1bnNwZWNpZmllZCBpbiBteSBv cGluaW9uLiBUaGUgaW1wb3J0YW50IHRoaW5nIHRvIHBvaW50IG91dCBpcyB0aGF0IHRoZSByZWxp YWJpbGl0eSBvZiB0aGUgZGF0YSBjaGFubmVsIGRvZXNu4oCZdCBhcHBseSB1bnRpbCBib3RoIHBl ZXJzIGhhdmUgb3BlbmVkIHRoZSBkYXRhIGNoYW5uZWwuIEhvdyB0aGUgcGVlcnMgaW5mb3JtIGVh Y2ggb3RoZXIgYWJvdXQgdGhhdCBpcyBzaWduYWxpbmcNCiBwcm90b2NvbCBzcGVjaWZpYy4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFzIGEgZnV0dXJlIGV4dGVuc2lvbiAsIGV2ZW4gaWYgYSBk YXRhIGNoYW5uZWwgaXMgbmVnb3RpYXRlZCBvdXQtb2YtYmFuZCwgd2UgY291bGQgZGVmaW5lIHRo YXQgYW4gaW4tYmFuZCBoYW5kc2hha2Ugc3RpbGwgdGFrZXMgcGxhY2UgYmVmb3JlIGFueSBkYXRh IGlzIHNlbnQuPGJyPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNocmlzdGVyPGJyPg0KPGJyPg0KPGRpdiBpZD0iQXBwbGVN YWlsU2lnbmF0dXJlIj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIDE0 IEp1biAyMDE4LCBhdCAxOS4wNiwgVGF5bG9yIEJyYW5kc3RldHRlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmRlYWRiZWVmQGdvb2dsZS5jb20iPmRlYWRiZWVmQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxk aXYgZGlyPSJsdHIiPlNvIHlvdSdyZSBzdWdnZXN0aW5nIGZvciB0aGUgd2ViIGFwcCB0byBqdXN0 IHRha2UgY2FyZSB0byBhdm9pZCB0aGlzPyBCdXQgdGhlIHBvaW50IG9mIHRoaXMgdGhyZWFkIGlz IHRvIGRlY2lkZSB3aGF0IGhhcHBlbnMgaWYgaXQgKmRvZXNuJ3QqLjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEp1 biAxMywgMjAxOCBhdCAxMTowOSBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPHNwYW4gZGlyPSJsdHIi Pg0KJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRh cmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bh bj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDtjb2xvcjpyZ2IoMCwwLDApO2Zv bnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZiI+DQo8ZGl2PkhpLDwv ZGl2Pg0KPHNwYW4gY2xhc3M9IiI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Im1fMzc2 MjUxNzIxMzI2MzMyNzIxT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGRpcj0ibHRyIj4mZ3Q7SXQgc291bmRzIGxpa2UgeW91IGFuZCBDaHJpc3RlciBhcmUgc3VnZ2Vz dGluZyB0aGUgc2FtZSB0aGluZzogJnF1b3Q7ZG9uJ3QgYWxsb3cgbWVzc2FnZXMgdG8gYmUgc2Vu dCB1bnRpbCB5b3UncmUgc3VyZSB0aGUgb3RoZXIgcGVlciBoYXMgYSBjaGFubmVsIHRvIHJlY2Vp dmUgdGhlbSZxdW90Oy4gRXhjZXB0IHRoYXQgdGhlcmUncyBubyB3YXkgZm9yIHRoZSBXZWJSVEMg c3RhY2sgdG8ga25vdyB0aGF0LCBzaW5jZSB0aGVzZSBjaGFubmVscw0KIGFyZSBub3Qgc2lnbmFs ZWQgaW4gU0RQIG9yIGFueSBpbi1iYW5kIG1lc3NhZ2UuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+RXZlbiBpZiB0aGUgV2Vi IGFwcCBjYW5ub3QgdGVsbCB0aGUgV2ViUlRDIHN0YWNrIHdoZW4gdGhlIHBlZXIgaGFzIGEgZGF0 YSBjaGFubmVsLCB0aGUgV2ViIGFwcCBjYW4gc3RpbGwgY29udHJvbCB3aGVuIGl0IHN0YXJ0cyBz ZW5kaW5nIGRhdGEgb24gdGhlIGRhdGEgY2hhbm5lbCwgY2Fu4oCZdCBpdD88L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5DaHJpc3RlcjwvZGl2Pg0KPHNwYW4gY2xhc3M9IiI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0ibV8zNzYyNTE3MjEz MjYzMzI3MjFPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xh c3M9ImdtYWlsX3F1b3RlIj5PbiBXZWQsIEp1biAxMywgMjAxOCBhdCAxOjMyIFBNLCBDdWxsZW4g SmVubmluZ3MgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpmbHVmZnlAaWlp LmNhIiB0YXJnZXQ9Il9ibGFuayI+Zmx1ZmZ5QGlpaS5jYTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8 YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2xpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2Ui PjxzcGFuPjxicj4NCjxkaXY+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pk9u IE1heSAzMSwgMjAxOCwgYXQgMTI6MjQgUE0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpkZWFkYmVlZj00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5kZWFkYmVlZj00MGdvb2dsZS5jb21AZG1hcmMuaTx3YnI+ZXRmLm9yZzwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJtXzM3NjI1MTcyMTMyNjMzMjcyMW1fMzQwNTk3MzQ2 MTMyNTg0OTY2MUFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPg0KPGRpdj4NCjxkaXY+T25lIG1pZ2h0IGV4cGVjdCB0aGF0IGEgJnF1b3Q7cmVsaWFibGUm cXVvdDsgZGF0YSBjaGFubmVsIGlzIGd1YXJhbnRlZWQgdG8gYmUsIHdlbGwsIHJlbGlhYmxlLiBC dXQgaW4gY3VycmVudCBpbXBsZW1lbnRhdGlvbnMsIHRoZSBmaXJzdCBtZXNzYWdlcyBtYXkgYmUg bG9zdCBpZiB0aGUgYXBwbGljYXRpb24gaXMgbmVnb3RpYXRpbmcgdGhlIGNoYW5uZWxzIG91dC1v Zi1iYW5kLCBhbmQgY3JlYXRlcyB0aGUgcmVjZWl2aW5nIGNoYW5uZWwgdG9vIGxhdGUuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5IZXJlJ3MgYSBmaWRkbGUgdGhhdCBkZW1vbnN0cmF0 ZXMgdGhpcyAoaGFwcGVucyB3aXRoIENocm9tZSBhbmQgRmlyZWZveCk6IDxhIGhyZWY9Imh0dHBz Oi8vanNmaWRkbGUubmV0L28ybTh0cDIwLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9qc2Zp ZGRsZS5uZXQvbzJtOHRwMjAvPC9hPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tm9y bWFsbHkgdGhpcyBpc24ndCBhbiBpc3N1ZSwgYmVjYXVzZSBhIHR5cGljYWwgYXBwbGljYXRpb24g d291bGQgY3JlYXRlIHRoZSBvdXQtb2YtYmFuZCBuZWdvdGlhdGVkIGNoYW5uZWxzIGJlZm9yZSB0 aGUgZmlyc3Qgb2ZmZXIvYW5zd2VyIGlzIGNvbXBsZXRlLCBhbmQgdGh1cyBiZWZvcmUgdGhlIFND VFAgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQuIE1lYW5pbmcgdGhhdCBieSB0aGUgdGltZSBh IGRhdGEgY2hhbm5lbCBpcyAmcXVvdDtvcGVuJnF1b3Q7LA0KIGl0J3MgZ3VhcmFudGVlZCB0aGF0 IHRoZSBvdGhlciBwZWVyIGhhcyBhIGNvcnJlc3BvbmRpbmcgY2hhbm5lbC48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkJ1dCBpZiBmb3Igd2hhdGV2ZXIgcmVhc29uLCBhbiBhcHBsaWNh dGlvbiBjcmVhdGVzIGEgZGF0YSBjaGFubmVsICphZnRlciogdGhlIFNDVFAgYXNzb2NpYXRpb24g aXMgZXN0YWJsaXNoZWQsIHRoZW4gaXQgd2lsbCBpbnN0YW50bHkgYmUgJnF1b3Q7b3BlbiZxdW90 OyBhcyBzb29uIGFzIGl0J3MgY3JlYXRlZC4gSWYgYSBtZXNzYWdlIGlzIHNlbnQgYXQgdGhpcyBw b2ludCwgYW5kIGl0J3MgcmVjZWl2ZWQgYnkgdGhlIG90aGVyIHBlZXIgYmVmb3JlIGl0J3MNCiBj cmVhdGVkIGl0cyBjb3JyZXNwb25kaW5nIGRhdGEgY2hhbm5lbCwgdGhlbiB0aGUgbWVzc2FnZSB3 aWxsIGp1c3QgYmUgZGlzY2FyZGVkLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U28s IGhvdyBzaG91bGQgd2UgZGVhbCB3aXRoIHRoaXM/IFNvbWUgcG9zc2liaWxpdGllczo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxvbD4NCjxsaT5TYXkgJnF1b3Q7dGhpcyBpcyBleHBlY3RlZCBiZWhh dmlvciZxdW90OyBhbmQgZG9jdW1lbnQgaXQgYmV0dGVyLCBicmVha2luZyB0aGUgcmVsaWFiaWxp dHkgcHJvbWlzZS48L2xpPjxsaT5SdW4gdGhlIGNsb3NpbmcgcHJvY2VkdXJlIGlmIGEgbWVzc2Fn ZSBpcyByZWNlaXZlZCBvbiBhIHN0cmVhbSBiZWZvcmUgYSBkYXRhIGNoYW5uZWwgaXMgcmVhZHkg dG8gcmVjZWl2ZSBpdC48L2xpPjxsaT5Eb24ndCBldmVuIGFsbG93IGFuIG91dC1vZi1iYW5kIG5l Z290aWF0ZWQgY2hhbm5lbCB0byBiZSBjcmVhdGVkIGFmdGVyIHRoZSBTQ1RQIGFzc29jaWF0aW9u IGlzIGVzdGFibGlzaGVkLjwvbGk+PGxpPkJ1ZmZlciB0aGVzZSBtZXNzYWdlcyBmb3IgdXAgdG8g WCBzZWNvbmRzIChvciB1cCB0byBYIGJ5dGVzKSwgdG8gYmUgZGVsaXZlcmVkIHRvIHRoZSBkYXRh IGNoYW5uZWwgb25jZSBpdCdzIGNyZWF0ZWQuIFJ1biB0aGUgY2xvc2luZyBwcm9jZWR1cmUgaWYg WCBpcyBleGNlZWRlZC48L2xpPjwvb2w+DQo8ZGl2PkknZCB2b3RlIGZvciAjMi4gQWRkaW5nIGFk ZGl0aW9uYWwgYnVmZmVyaW5nIGxvZ2ljIHNlZW1zIGxpa2Ugb3ZlcmtpbGwgaWYgdGhpcyBpc24n dCBhIHVzZSBjYXNlIHdlIHJlYWxseSBpbnRlbmRlZCB0byBzdXBwb3J0LjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+DQo8L3NwYW4+DQo8 ZGl2PkkgbGVhbiB0b3dhcmQgc29tZXRoaW5nIHRoYXQganVzdCBkaWQgbm90IGFsbG93IHRoZSAm bmJzcDtvdXQtb2YtYmFuZCBjaGFubmVsIG5lZ290aWF0aW9uIGJlIHVzZWQgdW50aWwgaXQgd2Fz IHNldCB1cC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJ1dCB3aGF0ZXZlciB3ZSBk bywgbm90IG9wdGlvbiAxJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJyPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7EE07FBB40FA4E1DBB515060F92CF4A2ericssoncom_-- From nobody Fri Jun 15 07:10:04 2018 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 7F0AB130DDA for ; Fri, 15 Jun 2018 07:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ln0xhFXJHgyY for ; Fri, 15 Jun 2018 07:09:59 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37DA126CC7 for ; Fri, 15 Jun 2018 07:09:59 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id l15-v6so11120090oth.6 for ; Fri, 15 Jun 2018 07:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1mmQaJURjzEVmIMcLsHpafctCkB7ubL2d4ELs9KeAZY=; b=cB1/ieQQjT+ZJhPzoEDbNlFaypukeyCTFW9OGu8GJFfkIvvuB7sA2zTgB29PkQmiiq fYtvzqmrBdESytWCoHGqw66F68+3EP0RcnThk7X2o2VKMjKArYb99xs6fYiYyIe+CkzM IshGmUA3zgFByPrTL1iTztFDP8i/VWGY4binb1xxdoQ05Yy+1rdIpLzkMYdGUrJqaUns J+OloMh5ohgdQsYA4sG1Nmx1A9a0dNU2EKFocKUCVXhNY1k5ERiwj3TNZHtEb+GTpzQP Q4FPIiZGcc82LZDoD7C1W9nFaKfGkf32ayBIx4IOZJHrJunp2kkOav36KZUJ/nV3B/Ip jpZw== 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=1mmQaJURjzEVmIMcLsHpafctCkB7ubL2d4ELs9KeAZY=; b=Wk/NA6W8jci0DXsg5m0EENo+5EWSsJLRN+hQ0Qv8lSo2GW3j+T4ZVt2R9p4+mlefCA SScF3+ijHR3fg7MmFpc+oaVVj219TrwhfASTZbu2CZVWmn9qizWjUo7A1Sig+rFUtO8Q bZK4aGJgM/o6mrm9DXufMClJjCnOi4uLqTfBS+OHk4VVePhDyDY+VtEQOy/UyW6iXVVn T4sH05azC+Glx4QDuxaPNQqOCz3BuAYxg+PIyTnGl6/EIFW8LYa63G152P+xIQGT2f0M Rzqo5iytpzVcnyrcNj33iFX0yQEA0ouXlObMZPYXc1unI8OTn498IfvXO/sCEwnEtCJu enMQ== X-Gm-Message-State: APt69E2Plj/1I46isx7keQP60RYKZwy7NtUrU/XzpSkmWDVjFDSGqXO2 ocO0xFRZw6qXXjn0ywdVOHpbN5pmUoXDIkbK00U= X-Google-Smtp-Source: ADUXVKIRKkN5tUtOxxvvxIEc47dxBM5wm2xdHrCW/CTGpoRRFDQTPtDM4okLFcPGAuhBTK4KhzB7I6Jeh744nz1uP28= X-Received: by 2002:a9d:5b49:: with SMTP id e9-v6mr1150622otj.193.1529071798752; Fri, 15 Jun 2018 07:09:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66c3:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 07:09:28 -0700 (PDT) From: Ted Hardie Date: Fri, 15 Jun 2018 07:09:28 -0700 Message-ID: To: RTCWeb IETF , Sean Turner , Cullen Jennings , Adam Roach Content-Type: multipart/alternative; boundary="000000000000669b56056eaec540" Archived-At: Subject: [rtcweb] ACTION REQUIRED: Virtual Interim availability check X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 14:10:03 -0000 --000000000000669b56056eaec540 Content-Type: text/plain; charset="UTF-8" Howdy, There are two issues currently in front of the group that need resolution: the "identity" SDP attribute characteristics (see Christer's Directorate review) and the mDNS proposal for IP-handling. A couple of folks approached the chairs about scheduling an RTCWEB meeting for Montreal to discuss those, but unfortunately, we missed the cut-off date by two weeks. While we can certainly have side discussions there (and potentially even a side meeting), the chairs want to gauge availability of working group participants for a virtual meeting to be held in advance of IETF 102. If you are available on July 2nd or July 3rd 2018 at 15:00 UTC for a 2 hour meeting, please reply to the chairs by 12:00 June 19 2018 to let us know whether you can make both dates, or, if only one, which it is. We will assume anyone who did not reply cannot attend, but feel free to tell us that directly as well. We will make a call June 19th on whether there is critical mass for the meeting and schedule if so. If not, we will look to schedule a virtual meeting after IETF 102, using a Doodle poll on a broader set of dates. regards, Ted --000000000000669b56056eaec540 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Howdy,

    There are two issues = currently in front of the group that need resolution:=C2=A0 the "ident= ity" SDP attribute characteristics (see Christer's Directorate rev= iew) and the mDNS proposal for IP-handling.=C2=A0=C2=A0 A couple of folks a= pproached the chairs about scheduling an RTCWEB meeting for Montreal to dis= cuss those, but unfortunately, we missed the cut-off date by two weeks.=C2= =A0 While we can certainly have side discussions there (and potentially eve= n a side meeting), the chairs want to gauge availability of working group p= articipants for a virtual meeting to be held in advance of IETF 102.

    If you are available on July 2nd or July 3rd 2018 a= t 15:00 UTC for a 2 hour meeting, please reply to the chairs=C2=A0 by 12:00= June 19 2018 to let us know whether you can make both dates, or, if only o= ne, which it is. We will assume anyone who did not reply cannot attend, but= feel free to tell us that directly as well.

    We wi= ll make a call June 19th on whether there is critical mass for the meeting = and schedule if so.=C2=A0 If not, we will look to schedule a virtual meetin= g after IETF 102, using a Doodle poll on a broader set of dates.
    =
    regards,

    Ted
    --000000000000669b56056eaec540-- From yfablet@apple.com Tue Jun 12 08:45:04 2018 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 BFCEE130E61 for ; Tue, 12 Jun 2018 08:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=apple.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 Xy6YkFimWxYS for ; Tue, 12 Jun 2018 08:45:00 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5AC130E62 for ; Tue, 12 Jun 2018 08:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528818299; x=2392731899; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BcKxfbpamLIr/J4JzidyfWabzx0zE2NKzpIEXoEOZs0=; b=fBJwoFre3u14fxY3ivWHrcF+2j7F2bglqPOz1vnr6QBYwxRPmp1BYNNkAqvIVFpj 1Eji3zd8OTWy8YczFHhoe6pN774OKFglK+RVSKXfJXShv8oIYtvOpW+pI9sQGZwh 4pvm/KyOTSnE97ODwrG7OFtm62ZGFN7ulhlaVcAs5vZ2d9gbsHkqpR4ayMpjUs9J dRUnBksCgkqlUCH1Sjo1Gel+qus0tTC6V66QdItZbPfLTZStB3cAEa05FFUxnTJ4 g0mN0PTTHzOQCUNx/40ZbFTv3ZkV/I0f844GEQDNGeeqP4/GDJ8BlfQhd+aXsRkI 1CjZZLE7Q80nSqRj+etN8g==; X-AuditID: 11973e16-6d9ff7000000740c-4a-5b1fea7aaa11 Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 08.26.29708.A7AEF1B5; Tue, 12 Jun 2018 08:44:59 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VqZZi4CxMs/utpwpPVybMg)" Received: from ma1-mmpp-sz07.apple.com (ma1-mmpp-sz07.apple.com [17.171.128.149]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PA70063CVQYIR00@mr2-mtap-s01.rno.apple.com>; Tue, 12 Jun 2018 08:44:58 -0700 (PDT) Received: from [17.192.25.194] (unknown [17.192.25.194]) by ma1-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PA700L1RVQX7U80@ma1-mmpp-sz07.apple.com>; Tue, 12 Jun 2018 08:44:58 -0700 (PDT) X-Va-A: X-Va-T-CD: d1542198541ccb2ed9731e9c7cba448a X-Va-E-CD: e2f1231772ca3dd6d9060cb8380bca67 X-Va-R-CD: 7e0ecfc399d2e63c65dae0115042fc2f X-Va-CD: 0 X-Va-ID: fa59b5b1-489f-4a81-adbc-3b050322abc4 X-V-A: X-V-T-CD: 89ad7b32b7f661dc2401e6afbd0aabcc X-V-E-CD: e2f1231772ca3dd6d9060cb8380bca67 X-V-R-CD: 7e0ecfc399d2e63c65dae0115042fc2f X-V-CD: 0 X-V-ID: b385cf11-de65-4c0f-8c18-530e26b8b042 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-12_01:,, signatures=0 Sender: youenn@apple.com From: youenn fablet Message-id: <4C3DAC42-0F1B-4393-A2B7-40F6D226CF8B@apple.com> Date: Tue, 12 Jun 2018 08:44:41 -0700 In-reply-to: To: RTCWeb IETF References: <436903fe-1ec7-e595-7733-0cc2f9c3a53d@gmail.com> X-Mailer: Apple Mail (2.3445.100.9.7) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUiuPlRq271K/logzOzmSy2ThWy+HB8KavF 2n/t7A7MHjtn3WX3WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBm/e70LOqIrnp//x9bAuNun i5GTQ0LARGLZx+NMXYxcHEICB5gkzr/+xgSS4BUQlPgx+R4LiM0sECZx8PkzqKL1TBJtDROY IZyJTBK9j34yQYxil/jzawcLhK0t8erNKTYYu3/vKSYYu2viSVYIm0tiwdbTULauxMaX36F6 2STWn1gCVM8BZGtJvD4lDBHWkri3ZSErjH1gcg8zhM0pcf7LRHYIW0fi6Z1zjBB2tsSj3lVg trCAhMSer51g49kE1CX2Xp/ADPGkjcSf7W9YIGrcJfr/vwCbzyKgKvFk4Rwwm1MgWGLf+tVM kIDwl9jX/xtsl4iAIlDNEkZIOJxhlJi57B7UEaoSH/quMU9glJ2FFJCzkAJyFtBrzEB3TJmS CxHWlnjy7gIrhK0msfD3IiZk8QWMbKsYhXITM3N0M/PM9RILCnJS9ZLzczcxghLEdDuxHYwP V1kdYhTgYFTi4bW4Ih8txJpYVlyZe4hRmoNFSZz3tTpQSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA+PBq1bLoiJyLaNt40LCzweZ2Ny2u3JoCW+Tatj/jrbVpQzXuXc4WSrms6m9ED1pwpCc FZ1oeiqcQ7n6xHvRNblxZ+4VSMnlxj2fqcjwzO53KJ+N46N9/JfN0vW44+6kppTuEFgoxm2y 3eHXW4HPZ+49k9LQ/2Vp6DjZof7hD8bvwfNM/gUZK7EUZyQaajEXFScCAMy3g4zxAgAA Archived-At: X-Mailman-Approved-At: Fri, 15 Jun 2018 08:35:00 -0700 Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 12 Jun 2018 17:00:41 -0000 --Boundary_(ID_VqZZi4CxMs/utpwpPVybMg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi all, Would it make sense to reserve a time slot at next IETF 102 meeting to = discuss this? Apparently, the RTCWeb WG is not meeting there. Maybe MMUSIC session would be a good place? Thanks, Y > Le 12 juin 2018 =C3=A0 8:39 AM, Justin Uberti a = =C3=A9crit : >=20 >=20 >=20 > On Tue, Jun 12, 2018 at 4:15 AM Lennart Grahl > wrote: > On 12.06.2018 02:40, Justin Uberti wrote: > > The Safari team has come up with a clever approach to avoid = disclosing > > private IP addresses for host candidates. As discussed in this = WebKit bug > > >, the technique works = as > > follows: > >=20 > > 1. Register a random UUID-based mDNS name when ICE gathering = starts > > 2. Replace the private IP address by a "{UUID}.local" string in = each > > host candidate (and set raddr to 0.0.0.0 for other candidates) > > 3. The other party will do mDNS resolution on any candidate = having a > > .local suffix, similar to how hostnames in candidates are handled = in RFC > > 5245, Section 15.1. > >=20 > > This technique is relevant to the IP handling document, as it = addresses one > > of the lesser problems (private IP disclosure) from the overall = problem > > statement. While I don't think this will have a large impact on the > > document, including the default mode selection, incorporating this > > technique would result in some moderate changes: > >=20 > > - Section 5.1 would mention concealing private IPs in the default = case > > as an explicit goal. > > - In Section 6, Mode 2 would change from handling out private IPs = to > > handing out mDNS names. >=20 > IMHO that would create a large gap between mode 1 and 2. Instead, I > would suggest using mDNS *in addition* to mode 2 and 3. For mode 2 = this > would mean that only the default private IP is being transmitted but = all > other interfaces are hidden by UUID-based hostnames. For mode 3, all > private IPs are hidden by UUID-based hostnames. >=20 > I don't see a clear benefit of doing that. If you have the mDNS = hostnames, you don't need the private IPs. >=20 > Or, looking at it a different way, if mode 3 is as you describe, why = would we ever use mode 2?=20 >=20 > > - This document would have to describe the technique or point to = another > > document that describes the technique. mmusic-ice-sip-sdp, = Section 4.1 > > = = > > > seems > > like a good option, as it already covers how to handle DNS names = in ICE > > candidates. >=20 > Since this will be useful for ORTC as well, I would not tie that to an > SDP-specific document. >=20 > ORTC already depends on this document (it explains ICE restarts, = amongst other things), so I don't see this as an issue. The nice thing = about this document is that it's nearing last call, but we still have = time to make edits like the ones suggested. >=20 > > This is a significant improvement and I think we will want to = incorporate > > this suggestion. Is this something we could do as part of this WGLC, = or > > should we look for another option? > I haven't seen a better solution than mDNS so far to prevent IPs from > leaking and I would appreciate having this to fix the following = issues: >=20 > - Allowing browsers to use stricter modes by default without = significant > drawbacks, > - establishing direct connections even in case no "consent" has been > given because the devices are in fact in the same network segment = (with > the exception of mode 4), and > - use cases where gUM cannot be applied and no other way of expressing > consent has been provided (which is the status quo). >=20 > Noted. Thanks. --Boundary_(ID_VqZZi4CxMs/utpwpPVybMg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = all,

    Would it make = sense to reserve a time slot at next IETF 102 meeting to discuss = this?
    Apparently, the RTCWeb WG is not meeting = there.
    Maybe MMUSIC session would be a good = place?

    Thanks,
    Y

    Le 12 juin 2018 =C3=A0 8:39 AM, Justin Uberti = <juberti@google.com> a =C3=A9crit :



    On Tue, Jun 12, 2018 at 4:15 AM Lennart Grahl <lennart.grahl@gmail.com> wrote:
    On 12.06.2018 = 02:40, Justin Uberti wrote:
    > The Safari team has come = up with a clever approach to avoid disclosing
    > private = IP addresses for host candidates. As discussed in this WebKit bug
    > <https://bugs.webkit.org/show_bug.cgi?id=3D174500>, the = technique works as
    > follows:
    > 
    >  =   1. Register a random UUID-based mDNS name when ICE gathering = starts
    >    2. Replace the private IP address = by a "{UUID}.local" string in each
    >    host = candidate (and set raddr to 0.0.0.0 for other candidates)
    >    3. The other party will do mDNS resolution = on any candidate having a
    >    .local suffix, = similar to how hostnames in candidates are handled in RFC
    >    5245, Section 15.1.
    > 
    > This = technique is relevant to the IP handling document, as it addresses = one
    > of the lesser problems (private IP disclosure) = from the overall problem
    > statement. While I don't = think this will have a large impact on the
    > document, = including the default mode selection, incorporating this
    > technique would result in some moderate changes:
    > 
    >    - Section 5.1 would mention concealing = private IPs in the default case
    >    as an = explicit goal.
    >    - In Section 6, Mode 2 = would change from handling out private IPs to
    >  =   handing out mDNS names.

    IMHO that = would create a large gap between mode 1 and 2. Instead, I
    would suggest using mDNS *in addition* to mode 2 and 3. For = mode 2 this
    would mean that only the default private IP is = being transmitted but all
    other interfaces are hidden by = UUID-based hostnames. For mode 3, all
    private IPs are = hidden by UUID-based hostnames.

    I don't see a clear = benefit of doing that. If you have the mDNS hostnames, you don't need = the private IPs.

    Or, looking at it a different way, if mode 3 is as you = describe, why would we ever use mode 2? 

    >    = - This document would have to describe the technique or point to = another
    >    document that describes the = technique. mmusic-ice-sip-sdp, Section 4.1
    >  =   <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#se= ction-4.1>
    > seems
    >  =   like a good option, as it already covers how to handle DNS names = in ICE
    >    candidates.

    Since this will be useful for ORTC as well, I would not tie = that to an
    SDP-specific document.

    ORTC already depends on this document (it explains ICE = restarts, amongst other things), so I don't see this as an issue. The = nice thing about this document is that it's nearing last call, but we = still have time to make edits like the ones suggested.

    > This is a = significant improvement and I think we will want to incorporate
    > this suggestion. Is this something we could do as part = of this WGLC, or
    > should we look for another = option?
    I haven't seen a better solution than mDNS so far = to prevent IPs from
    leaking and I would appreciate having = this to fix the following issues:

    - = Allowing browsers to use stricter modes by default without = significant
    drawbacks,
    - establishing direct = connections even in case no "consent" has been
    given = because the devices are in fact in the same network segment (with
    the exception of mode 4), and
    - use cases where = gUM cannot be applied and no other way of expressing
    consent= has been provided (which is the status quo).

    Noted. Thanks.

    = --Boundary_(ID_VqZZi4CxMs/utpwpPVybMg)-- From nobody Fri Jun 15 09:18:16 2018 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 AD58A130DC0 for ; Fri, 15 Jun 2018 09:18:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 prT7iYIXv0Xp for ; Fri, 15 Jun 2018 09:18:03 -0700 (PDT) Received: from smtp65.ord1c.emailsrvr.com (smtp65.ord1c.emailsrvr.com [108.166.43.65]) (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 6E143130E30 for ; Fri, 15 Jun 2018 09:17:53 -0700 (PDT) Received: from smtp9.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C296F2035B; Fri, 15 Jun 2018 12:17:50 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp9.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6F7F2203DB; Fri, 15 Jun 2018 12:17:50 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 15 Jun 2018 12:17:50 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_7EE89519-20AB-4DEF-ABEB-D6391F49A89F" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Cullen Jennings In-Reply-To: Date: Fri, 15 Jun 2018 10:17:49 -0600 Cc: RTCWeb IETF Message-Id: <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> To: Taylor Brandstetter X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 16:18:13 -0000 --Apple-Mail=_7EE89519-20AB-4DEF-ABEB-D6391F49A89F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can the browser take care of it from what it knows about setting up the = channel?=20 > On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter = wrote: >=20 > It sounds like you and Christer are suggesting the same thing: "don't = allow messages to be sent until you're sure the other peer has a channel = to receive them". Except that there's no way for the WebRTC stack to = know that, since these channels are not signaled in SDP or any in-band = message. >=20 > On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings > wrote: >=20 >=20 >> On May 31, 2018, at 12:24 PM, Taylor Brandstetter = > wrote: >>=20 >> One might expect that a "reliable" data channel is guaranteed to be, = well, reliable. But in current implementations, the first messages may = be lost if the application is negotiating the channels out-of-band, and = creates the receiving channel too late. >>=20 >> Here's a fiddle that demonstrates this (happens with Chrome and = Firefox): https://jsfiddle.net/o2m8tp20/ = >>=20 >> Normally this isn't an issue, because a typical application would = create the out-of-band negotiated channels before the first offer/answer = is complete, and thus before the SCTP association is established. = Meaning that by the time a data channel is "open", it's guaranteed that = the other peer has a corresponding channel. >>=20 >> But if for whatever reason, an application creates a data channel = *after* the SCTP association is established, then it will instantly be = "open" as soon as it's created. If a message is sent at this point, and = it's received by the other peer before it's created its corresponding = data channel, then the message will just be discarded. >>=20 >> So, how should we deal with this? Some possibilities: >> Say "this is expected behavior" and document it better, breaking the = reliability promise. >> Run the closing procedure if a message is received on a stream before = a data channel is ready to receive it. >> Don't even allow an out-of-band negotiated channel to be created = after the SCTP association is established. >> Buffer these messages for up to X seconds (or up to X bytes), to be = delivered to the data channel once it's created. Run the closing = procedure if X is exceeded. >> I'd vote for #2. Adding additional buffering logic seems like = overkill if this isn't a use case we really intended to support. >=20 > I lean toward something that just did not allow the out-of-band = channel negotiation be used until it was set up. >=20 > But whatever we do, not option 1=20 >=20 >=20 >=20 >=20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_7EE89519-20AB-4DEF-ABEB-D6391F49A89F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

    Can the browser take care of it from = what it knows about setting up the channel? 

    On Jun = 13, 2018, at 4:48 PM, Taylor Brandstetter <deadbeef@google.com>= wrote:

    It sounds like you and Christer are suggesting = the same thing: "don't allow messages to be sent until you're sure the = other peer has a channel to receive them". Except that there's no way = for the WebRTC stack to know that, since these channels are not signaled = in SDP or any in-band message.

    On Wed, = Jun 13, 2018 at 1:32 PM, Cullen Jennings <fluffy@iii.ca> wrote:


    On May = 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=3D40google.com@dmarc.ietf.org> = wrote:

    One= might expect that a "reliable" data channel is guaranteed to be, well, = reliable. But in current implementations, the first messages may be lost = if the application is negotiating the channels out-of-band, and creates = the receiving channel too late.

    Here's a fiddle that demonstrates this = (happens with Chrome and Firefox): https://jsfiddle.net/o2m8tp20/

    Normally this isn't an issue, because a = typical application would create the out-of-band negotiated channels = before the first offer/answer is complete, and thus before the SCTP = association is established. Meaning that by the time a data channel is = "open", it's guaranteed that the other peer has a corresponding = channel.

    But = if for whatever reason, an application creates a data channel *after* = the SCTP association is established, then it will instantly be "open" as = soon as it's created. If a message is sent at this point, and it's = received by the other peer before it's created its corresponding data = channel, then the message will just be discarded.
    So, how should we deal with this? Some = possibilities:
    1. Say "this is expected behavior" and document it better, = breaking the reliability promise.
    2. Run the closing = procedure if a message is received on a stream before a data channel is = ready to receive it.
    3. Don't even allow an out-of-band = negotiated channel to be created after the SCTP association is = established.
    4. Buffer these messages for up to X = seconds (or up to X bytes), to be delivered to the data channel once = it's created. Run the closing procedure if X is exceeded.
    I'd vote for #2. Adding additional buffering logic seems like = overkill if this isn't a use case we really intended to = support.

    I lean toward something that = just did not allow the  out-of-band channel negotiation be used = until it was set up.

    But whatever we do, not option 1 


     







    = --Apple-Mail=_7EE89519-20AB-4DEF-ABEB-D6391F49A89F-- From nobody Fri Jun 15 09:28:27 2018 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 0ED44130E46 for ; Fri, 15 Jun 2018 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 AJIxVTIYD5-v for ; Fri, 15 Jun 2018 09:28:15 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42189130DC0 for ; Fri, 15 Jun 2018 09:28:15 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id r24-v6so11205316ioh.9 for ; Fri, 15 Jun 2018 09:28:15 -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=VnoN9RIiBuIUk/6FmAt7I+mWSzM0ObfCkj54Ku6u2RU=; b=PVhwcSRtcsB0E0hkh3kG3omlBLjfE29fOJxu07TPHMt+hFU038Y9s8p0KGJ01DycFf pAhsNp/XxRT/R0f6JlCmYCcRXDOlkfqC9aW4pMEJbfxwGCrax5ZMRtxyRen1DpUVZfxh 8T+JsOtpFJ/H1eMFGkr7cZsZig8STg9kaYeu7FHg7SSj9WxhisT1272QTzLx2yg2hLZl d4aO+f4mhz3Lj0fIOO8O0I4O20InymiXU1ZGccVKSlfz1r6BmhlyD0bzHSTvXpKOwQ4x +lrhuypMGbl/NUt4iUK6etjR9AkVCQoQPG+vh0Ab+BlCjo+Q/+eMtIcFf7er4m1xyeFV uwsw== 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=VnoN9RIiBuIUk/6FmAt7I+mWSzM0ObfCkj54Ku6u2RU=; b=nIoeG0KaHj02mPWy4T1cwjKwXibQhaEVgA+W5ul+uO8mN5k6ewoHj2gavZCn9RhKgj jc9WgzxWiVCWlz0KOr96oCDITfn5mOPa2lOSGqrtOdhpE6boaiADZmS694yH6s/zVpLa 2Gf1yZltRiOQhgqhqtYLxNhesJjwQbbFHQyl7tOYIIOi1BXCQrpnWzgTtGqJUAVJl6Xb slkQvouD1ubTem10eZfUJL0lv4xy6hZcmGTYKgZGO/A/ks6qj/xqodRJjEM1dYLMyWPU bm9RFe2ux5DMvJb4p7VQFTi/FlnoqP+PDnswkDnMI3BkNJy37pxSESE5iUUNEmZ5EJfs vBaQ== X-Gm-Message-State: APt69E1Rpizs7hRkRgdce+VjRJmG20j5Hd2EfTBGvnIWZtkx+54dSN/k pZdH5e+e3hb8ZAnFgAbSTXhzj4/OtTohwHQ7z0SYxg== X-Google-Smtp-Source: ADUXVKKEwS4TgwwMYsfIBmzq7E4Tw4nF2FtuxLF52isEirJhUlmQNoUVH5Ql0lGjRO+DZO5L9C652NP+va5D8kS59xo= X-Received: by 2002:a6b:e907:: with SMTP id u7-v6mr2194387iof.38.1529080094192; Fri, 15 Jun 2018 09:28:14 -0700 (PDT) MIME-Version: 1.0 References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> In-Reply-To: <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> From: Justin Uberti Date: Fri, 15 Jun 2018 09:28:02 -0700 Message-ID: To: Cullen Jennings Cc: Taylor Brandstetter , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000d9ac94056eb0b34e" Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 16:28:23 -0000 --000000000000d9ac94056eb0b34e Content-Type: text/plain; charset="UTF-8" The key question is: what should the browser do if it gets a data channel message on a channel that it doesn't know about? I believe the only realistic options are: 1) eat it (silent failure) 2) explode (noisy but imprecise failure) On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings wrote: > > Can the browser take care of it from what it knows about setting up the > channel? > > On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter > wrote: > > It sounds like you and Christer are suggesting the same thing: "don't > allow messages to be sent until you're sure the other peer has a channel to > receive them". Except that there's no way for the WebRTC stack to know > that, since these channels are not signaled in SDP or any in-band message. > > On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings wrote: > >> >> >> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < >> deadbeef=40google.com@dmarc.ietf.org> wrote: >> >> One might expect that a "reliable" data channel is guaranteed to be, >> well, reliable. But in current implementations, the first messages may be >> lost if the application is negotiating the channels out-of-band, and >> creates the receiving channel too late. >> >> Here's a fiddle that demonstrates this (happens with Chrome and Firefox): >> https://jsfiddle.net/o2m8tp20/ >> >> Normally this isn't an issue, because a typical application would create >> the out-of-band negotiated channels before the first offer/answer is >> complete, and thus before the SCTP association is established. Meaning that >> by the time a data channel is "open", it's guaranteed that the other peer >> has a corresponding channel. >> >> But if for whatever reason, an application creates a data channel *after* >> the SCTP association is established, then it will instantly be "open" as >> soon as it's created. If a message is sent at this point, and it's received >> by the other peer before it's created its corresponding data channel, then >> the message will just be discarded. >> >> So, how should we deal with this? Some possibilities: >> >> 1. Say "this is expected behavior" and document it better, breaking >> the reliability promise. >> 2. Run the closing procedure if a message is received on a stream >> before a data channel is ready to receive it. >> 3. Don't even allow an out-of-band negotiated channel to be created >> after the SCTP association is established. >> 4. Buffer these messages for up to X seconds (or up to X bytes), to >> be delivered to the data channel once it's created. Run the closing >> procedure if X is exceeded. >> >> I'd vote for #2. Adding additional buffering logic seems like overkill if >> this isn't a use case we really intended to support. >> >> >> I lean toward something that just did not allow the out-of-band channel >> negotiation be used until it was set up. >> >> But whatever we do, not option 1 >> >> >> >> >> >> >> >> >> >> >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000d9ac94056eb0b34e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The key question is: what should the browser do if it gets= a data channel message on a channel that it doesn't know about?
    I believe the only realistic options are:
    1) eat it = (silent failure)
    2) explode (noisy but imprecise failure)


    On Fri, = Jun 15, 2018 at 9:18 AM Cullen Jennings <fluffy@iii.ca> wrote:

    Can the browser take care of it from what it knows about setting up the ch= annel?=C2=A0

    On Jun 13, 2018, at= 4:48 PM, Taylor Brandstetter <deadbeef@google.com> wrote:

    It sounds l= ike you and Christer are suggesting the same thing: "don't allow m= essages to be sent until you're sure the other peer has a channel to re= ceive them". Except that there's no way for the WebRTC stack to kn= ow that, since these channels are not signaled in SDP or any in-band messag= e.

    On We= d, Jun 13, 2018 at 1:32 PM, Cullen Jennings <fluffy@iii.ca> wr= ote:


    <= div>On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=3D40goo= gle.com@dmarc.ietf.org> wrote:

    One might expect that a "reliable" data channel is guarant= eed to be, well, reliable. But in current implementations, the first messag= es may be lost if the application is negotiating the channels out-of-band, = and creates the receiving channel too late.

    Here&#= 39;s a fiddle that demonstrates this (happens with Chrome and Firefox): https://jsfiddle.= net/o2m8tp20/

    Normally this isn't an issue= , because a typical application would create the out-of-band negotiated cha= nnels before the first offer/answer is complete, and thus before the SCTP a= ssociation is established. Meaning that by the time a data channel is "= ;open", it's guaranteed that the other peer has a corresponding ch= annel.

    But if for whatever reason, an application = creates a data channel *after* the SCTP association is established, then it= will instantly be "open" as soon as it's created. If a messa= ge is sent at this point, and it's received by the other peer before it= 's created its corresponding data channel, then the message will just b= e discarded.

    So, how should we deal with this? Som= e possibilities:
    1. Say "this is expected behavio= r" and document it better, breaking the reliability promise.
    2. R= un the closing procedure if a message is received on a stream before a data= channel is ready to receive it.
    3. Don't even allow an out-of-ban= d negotiated channel to be created after the SCTP association is establishe= d.
    4. Buffer these messages for up to X seconds (or up to X bytes), to= be delivered to the data channel once it's created. Run the closing pr= ocedure if X is exceeded.
    I'd vote for #2. Adding additio= nal buffering logic seems like overkill if this isn't a use case we rea= lly intended to support.

    I lean toward something that just did not allow the =C2=A0out-of-ba= nd channel negotiation be used until it was set up.

    But whatever we do, not option 1=C2=A0





    =C2=A0







    ________________________________________= _______
    rtcweb mailing list
    rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
    --000000000000d9ac94056eb0b34e-- From nobody Fri Jun 15 09:44:26 2018 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 B5D65130DFB for ; Fri, 15 Jun 2018 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U6g7fUUhsCv for ; Fri, 15 Jun 2018 09:44:22 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A644D12F18C for ; Fri, 15 Jun 2018 09:44:21 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id x6-v6so4496831wmc.3 for ; Fri, 15 Jun 2018 09:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G8VXefMzev2i1C4zc+NM+2jPu5Od27OJ6bTY3I9SJ9g=; b=XxFNtIGRer3ahf63iWejX/jBT4K2eEhedobrX+4NITf2Ig464hadRlmqOdygmZ+eZH Q9JIl+2GyTuWL9DElZF/0dZc95Q1Na3ThZLAvIHw3hDmV/hAvc5IQ0Q3kNQgvL/+LHBn 8ReTJv1ZU1Gzqb2Iua7PATQpQpV21NqN8NWbkyDqHHPfIQZ/iHn/+vk5sVI0un2bv0RD gsg7SHQxubZVR7evfydXU5h3ntQMV51blARJH4VY5GArcUFz38IaoPWklnV/O+Z2eopD Q8YlqdlwnlySSTYTXRYSSU4BUR8K/86zTmrUZrxRnDodTAjG5y1o5po0w39yb2R0Ay88 IHMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=G8VXefMzev2i1C4zc+NM+2jPu5Od27OJ6bTY3I9SJ9g=; b=tW0VNjpeMvl0jjjOJXXaCU/h5lzkNUfVPFvK29ng0JR1h+rPZbp+cPGQ7zkZ2td8QU ZSyvq4I9CUI8ErcHk5ZzP2RunY0OJMLfBZHgfUE3o11Xc1LHZ5NFlcDdRFii2iyuvZZ7 kyu2z31HSHFHynN00pkYVhw153Xo5PleW697WhPx/+aZalcOusJXwAWjfPCA4/Rr9kpP aN4+8mUKkIK3OmKNWFojlp3TldBrMULvf9nw5jGX11JYJ5n3klTAIqzaA7/4Z+mk7W2p EU683q2202iPo1zSqGrBEpLfqwD4dOB9lwzXtMTC7rO0lfkjfS+QxNV72NeYwvs2+a+P auCw== X-Gm-Message-State: APt69E3wzKcGi+iq1Dc2QpT0cHHfzT8dZolZl/X+ITR4mM2//Dfg3cDD nfxZm9VOH5ZDyB/NdzY9y9FZ8Q== X-Google-Smtp-Source: ADUXVKLU3o+wl7MpW5tEt/RwlEBAmNtDkQFTdd/6m+gK6YgukFYUJ/FiQX0LRtDBvvaEl1SkoE16tQ== X-Received: by 2002:a1c:dc41:: with SMTP id t62-v6mr1887745wmg.42.1529081059778; Fri, 15 Jun 2018 09:44:19 -0700 (PDT) Received: from ?IPv6:2003:cd:6f1f:4900:55c6:1b2b:232c:2fb2? (p200300CD6F1F490055C61B2B232C2FB2.dip0.t-ipconnect.de. [2003:cd:6f1f:4900:55c6:1b2b:232c:2fb2]) by smtp.gmail.com with ESMTPSA id 11-v6sm1998646wmd.35.2018.06.15.09.44.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jun 2018 09:44:19 -0700 (PDT) From: Lennart Grahl To: rtcweb@ietf.org References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; prefer-encrypt=mutual; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> Date: Fri, 15 Jun 2018 18:44:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 16:44:25 -0000 I would be fine with either Taylor's option 4) or Justin's option 2) by raising an explicit error containing a stream ID. In the WebRTC spec, we could then resolve this by adding an `error` event to the `RTCSctpTransport` interface where the event would contain the stream ID a message has been received on. Cheers Lennart On 15.06.2018 18:28, Justin Uberti wrote: > The key question is: what should the browser do if it gets a data channel > message on a channel that it doesn't know about? > > I believe the only realistic options are: > 1) eat it (silent failure) > 2) explode (noisy but imprecise failure) > > > On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings wrote: > >> >> Can the browser take care of it from what it knows about setting up the >> channel? >> >> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter >> wrote: >> >> It sounds like you and Christer are suggesting the same thing: "don't >> allow messages to be sent until you're sure the other peer has a channel to >> receive them". Except that there's no way for the WebRTC stack to know >> that, since these channels are not signaled in SDP or any in-band message. >> >> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings wrote: >> >>> >>> >>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < >>> deadbeef=40google.com@dmarc.ietf.org> wrote: >>> >>> One might expect that a "reliable" data channel is guaranteed to be, >>> well, reliable. But in current implementations, the first messages may be >>> lost if the application is negotiating the channels out-of-band, and >>> creates the receiving channel too late. >>> >>> Here's a fiddle that demonstrates this (happens with Chrome and Firefox): >>> https://jsfiddle.net/o2m8tp20/ >>> >>> Normally this isn't an issue, because a typical application would create >>> the out-of-band negotiated channels before the first offer/answer is >>> complete, and thus before the SCTP association is established. Meaning that >>> by the time a data channel is "open", it's guaranteed that the other peer >>> has a corresponding channel. >>> >>> But if for whatever reason, an application creates a data channel *after* >>> the SCTP association is established, then it will instantly be "open" as >>> soon as it's created. If a message is sent at this point, and it's received >>> by the other peer before it's created its corresponding data channel, then >>> the message will just be discarded. >>> >>> So, how should we deal with this? Some possibilities: >>> >>> 1. Say "this is expected behavior" and document it better, breaking >>> the reliability promise. >>> 2. Run the closing procedure if a message is received on a stream >>> before a data channel is ready to receive it. >>> 3. Don't even allow an out-of-band negotiated channel to be created >>> after the SCTP association is established. >>> 4. Buffer these messages for up to X seconds (or up to X bytes), to >>> be delivered to the data channel once it's created. Run the closing >>> procedure if X is exceeded. >>> >>> I'd vote for #2. Adding additional buffering logic seems like overkill if >>> this isn't a use case we really intended to support. >>> >>> >>> I lean toward something that just did not allow the out-of-band channel >>> negotiation be used until it was set up. >>> >>> But whatever we do, not option 1 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Fri Jun 15 09:52:46 2018 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 CD40A130DFB for ; Fri, 15 Jun 2018 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6_qH_zo69pM6 for ; Fri, 15 Jun 2018 09:52:33 -0700 (PDT) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (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 E6B7512F18C for ; Fri, 15 Jun 2018 09:52:32 -0700 (PDT) Received: (qmail 11048 invoked from network); 15 Jun 2018 16:52:31 -0000 X-APM-Authkey: 255286/0(159927/0) 1564 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 15 Jun 2018 16:52:31 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 56BA518A0236; Fri, 15 Jun 2018 17:52:31 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pOoxPgjA7DRq; Fri, 15 Jun 2018 17:52:31 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E805918A016F; Fri, 15 Jun 2018 17:52:30 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: T H Panton In-Reply-To: <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> Date: Fri, 15 Jun 2018 17:52:30 +0100 Cc: rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> To: Lennart Grahl X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 16:52:36 -0000 With my very old SNMP hat on, I say 1) you silently drop it. I'd also say that this indicates that the {negotiated:true, id:0} thing = is=20 a misfeature. T. =20 > On 15 Jun 2018, at 17:44, Lennart Grahl = wrote: >=20 > I would be fine with either Taylor's option 4) or Justin's option 2) = by > raising an explicit error containing a stream ID. In the WebRTC spec, = we > could then resolve this by adding an `error` event to the > `RTCSctpTransport` interface where the event would contain the stream = ID > a message has been received on. >=20 > Cheers > Lennart >=20 > On 15.06.2018 18:28, Justin Uberti wrote: >> The key question is: what should the browser do if it gets a data = channel >> message on a channel that it doesn't know about? >>=20 >> I believe the only realistic options are: >> 1) eat it (silent failure) >> 2) explode (noisy but imprecise failure) >>=20 >>=20 >> On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings = wrote: >>=20 >>>=20 >>> Can the browser take care of it from what it knows about setting up = the >>> channel? >>>=20 >>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter = >>> wrote: >>>=20 >>> It sounds like you and Christer are suggesting the same thing: = "don't >>> allow messages to be sent until you're sure the other peer has a = channel to >>> receive them". Except that there's no way for the WebRTC stack to = know >>> that, since these channels are not signaled in SDP or any in-band = message. >>>=20 >>> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings = wrote: >>>=20 >>>>=20 >>>>=20 >>>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < >>>> deadbeef=3D40google.com@dmarc.ietf.org> wrote: >>>>=20 >>>> One might expect that a "reliable" data channel is guaranteed to = be, >>>> well, reliable. But in current implementations, the first messages = may be >>>> lost if the application is negotiating the channels out-of-band, = and >>>> creates the receiving channel too late. >>>>=20 >>>> Here's a fiddle that demonstrates this (happens with Chrome and = Firefox): >>>> https://jsfiddle.net/o2m8tp20/ >>>>=20 >>>> Normally this isn't an issue, because a typical application would = create >>>> the out-of-band negotiated channels before the first offer/answer = is >>>> complete, and thus before the SCTP association is established. = Meaning that >>>> by the time a data channel is "open", it's guaranteed that the = other peer >>>> has a corresponding channel. >>>>=20 >>>> But if for whatever reason, an application creates a data channel = *after* >>>> the SCTP association is established, then it will instantly be = "open" as >>>> soon as it's created. If a message is sent at this point, and it's = received >>>> by the other peer before it's created its corresponding data = channel, then >>>> the message will just be discarded. >>>>=20 >>>> So, how should we deal with this? Some possibilities: >>>>=20 >>>> 1. Say "this is expected behavior" and document it better, = breaking >>>> the reliability promise. >>>> 2. Run the closing procedure if a message is received on a stream >>>> before a data channel is ready to receive it. >>>> 3. Don't even allow an out-of-band negotiated channel to be = created >>>> after the SCTP association is established. >>>> 4. Buffer these messages for up to X seconds (or up to X bytes), = to >>>> be delivered to the data channel once it's created. Run the = closing >>>> procedure if X is exceeded. >>>>=20 >>>> I'd vote for #2. Adding additional buffering logic seems like = overkill if >>>> this isn't a use case we really intended to support. >>>>=20 >>>>=20 >>>> I lean toward something that just did not allow the out-of-band = channel >>>> negotiation be used until it was set up. >>>>=20 >>>> But whatever we do, not option 1 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Jun 15 10:49:12 2018 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 2520A130E36 for ; Fri, 15 Jun 2018 10:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matthew-at.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 zAJdVPnQ2gRZ for ; Fri, 15 Jun 2018 10:49:06 -0700 (PDT) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66869124D68 for ; Fri, 15 Jun 2018 10:49:06 -0700 (PDT) Received: by mail-pl0-x22c.google.com with SMTP id 31-v6so5718122plc.4 for ; Fri, 15 Jun 2018 10:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matthew-at.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V8X3mjpRL3xXf6iT6S1QxVB7c1BUGez+F1o2O79txOg=; b=WOxF82efLhygboK5MP38g7K5zz/CGEy3mj5PV5bUhuQWDXE1kWcu3llC5ty9lFsta4 Bdmjg9NZlHbW0rMRJJwZ3yigAnnlSwzVX+MHj/5BIDaaTG17EqIyqfg0/eRBJAFIEL03 1f+ri+FdJOgUqZBcgckhnv2L2LebAAEL59HIYoc0tJKkCrdWAOhBNZaXLp2QFW7W+9Dp bPz4jbAXZNWWUttNpkycWfgTzPmw9FKWFY1pMenDmV8SEktaha+xMALX6niXsNniTVNV DfiDPiTfyT/knDEhI5LtgycaxXvXA+Xg5q1KIRNQWaE8yfeg1JKGXtxKS2TwSQx5VtjN Zw7Q== 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=V8X3mjpRL3xXf6iT6S1QxVB7c1BUGez+F1o2O79txOg=; b=Biftk9nkaOXhmwYpxA+NEMSl97VzWlszKEeS8X3Fq2p4dUlFgugnlcaePaM4rS7Xzq FqvntgQUtEQdt+kSv1sQ8/cYLtv0mFX1j2z51EwvnGcma546an2bYIom2YMrfLui7P0e lbAeHg0zfQQGoI0Xo9N46HjqbmKF4iQtlwN+07GdNtI//pAcxwz2RXS+2Co09XJqL46s aIeT5dSlg2vCE7Jxz4uq4gUltetgsFKVjP/l9xehBrDcZ9mzEjORp9MGSSW2d9MFozJs x69JjF2tLiwRX+ocksgWDhkXlo4YnJuGh+hIYQP7QB5ekvNhcppMJgank863Ax20AETn J0ng== X-Gm-Message-State: APt69E3mROjO+QNuan0DMi3o6OVOQdxmjzxH3SMw5PnXWyrr85FoOIaw pohAv4r6T8j7/A0hhvEOzbXalvrjRNaV3XEOuZ92wQ== X-Google-Smtp-Source: ADUXVKL93hVB6kJVWrHCm1sPzRICsV7RfQntg18W6tlYxsv/D8TOw+COVVLd6crKog8m/jvGvicL/uqOlKDg88gewIM= X-Received: by 2002:a17:902:ab8d:: with SMTP id f13-v6mr3142638plr.81.1529084945697; Fri, 15 Jun 2018 10:49:05 -0700 (PDT) MIME-Version: 1.0 References: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> In-Reply-To: From: Matthew Kaufman Date: Fri, 15 Jun 2018 10:48:54 -0700 Message-ID: To: Justin Uberti Cc: Harald Alvestrand , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000052462056eb1d5ca" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 17:49:11 -0000 --000000000000052462056eb1d5ca Content-Type: text/plain; charset="UTF-8" Opposed because we shouldn't waste any more time on IPv4, and IPv6 has no analog that we can implement for IPv6 and then implement for IPv4 largely for free. Matthew Kaufman On Thu, Jun 14, 2018 at 2:32 PM Justin Uberti wrote: > On Thu, Jun 14, 2018 at 2:15 PM Harald Alvestrand > wrote: > >> I have some worries about this proposal. It seems neat, and solves a >> specific problem for a specific use case, but it's not a written-up >> proposal, rather a sketch for one - and I'm afraid of devils in the >> details. >> >> For instance: >> >> - If this technique is used for a computer directly connected to the >> Internet, with a public IP address, it won't communicate - unless it is >> only used on private addresses - because "uuid.local" doesn't resolve, >> whereas a public IP address is globally reachable. > > >> - The above means that the proposal needs a definition of "private >> address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6 >> range is covered by the proposal? >> >> - It will only work if the private address usage is the same scope as >> mDNS resolution. On an unmanaged LAN it works, and on a network with >> explicit mDNS forwarding it works. But on any other deployment, it >> forces traffic to go via public IP addresses learned by STUN. >> >> I think this is worth adding. Perhaps as a new "mode 2m"? >> >> But I'd like a commitment to not adding it until we have a full proposal. >> > > I have sketched out the proposal in > https://github.com/juberti/draughts/pull/103, which while not complete, > does address most of your questions. > >> >> Den 12. juni 2018 02:40, skrev Justin Uberti: >> > The Safari team has come up with a clever approach to avoid disclosing >> > private IP addresses for host candidates. As discussed in this WebKit >> > bug , the technique >> > works as follows: >> > >> > 1. Register a random UUID-based mDNS name when ICE gathering starts >> > 2. Replace the private IP address by a "{UUID}.local" string in each >> > host candidate (and set raddr to 0.0.0.0 for other candidates) >> > 3. The other party will do mDNS resolution on any candidate having a >> > .local suffix, similar to how hostnames in candidates are handled in >> > RFC 5245, Section 15.1. >> > >> > This technique is relevant to the IP handling document, as it addresses >> > one of the lesser problems (private IP disclosure) from the overall >> > problem statement. While I don't think this will have a large impact on >> > the document, including the default mode selection, incorporating this >> > technique would result in some moderate changes: >> > >> > * Section 5.1 would mention concealing private IPs in the default case >> > as an explicit goal. >> > * In Section 6, Mode 2 would change from handling out private IPs to >> > handing out mDNS names. >> > * This document would have to describe the technique or point to >> > another document that describes the technique. mmusic-ice-sip-sdp, >> > Section 4.1 >> > < >> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1 >> > seems >> > like a good option, as it already covers how to handle DNS names in >> > ICE candidates. >> > >> > This is a significant improvement and I think we will want to >> > incorporate this suggestion. Is this something we could do as part of >> > this WGLC, or should we look for another option? >> > >> > >> > _______________________________________________ >> > 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 > --000000000000052462056eb1d5ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Opposed because we shouldn't waste any more time on IP= v4, and IPv6 has no analog that we can implement for IPv6 and then implemen= t for IPv4 largely for free.

    Matthew Kaufman

    On Thu, Jun 14, 2018 at 2:32 PM Jus= tin Uberti <juberti=3D40g= oogle.com@dmarc.ietf.org> wrote:
    On Thu, J= un 14, 2018 at 2:15 PM Harald Alvestrand <harald@alvestrand.no> wrote:
    I have some worries about t= his proposal. It seems neat, and solves a
    specific problem for a specific use case, but it's not a written-up
    proposal, rather a sketch for one - and I'm afraid of devils in the det= ails.

    For instance:

    - If this technique is used for a computer directly connected to the
    Internet, with a public IP address, it won't communicate - unless it is=
    only used on private addresses - because "uuid.local" doesn't= resolve,
    whereas a public IP address is globally reachable.=C2=A0

    - The above means that the proposal needs a definition of "private
    address". Do we mean "private" in the RFC 1918 sense? If so,= which IPv6
    range is covered by the proposal?

    - It will only work if the private address usage is the same scope as
    mDNS resolution. On an unmanaged LAN it works, and on a network with
    explicit mDNS forwarding it works. But on any other deployment, it
    forces traffic to go via public IP addresses learned by STUN.

    I think this is worth adding. Perhaps as a new "mode 2m"?

    But I'd like a commitment to not adding it until we have a full proposa= l.

    I have sketched out the proposal in=C2=A0https://gith= ub.com/juberti/draughts/pull/103, which while not complete, does addres= s most of your questions.

    Den 12. juni 2018 02:40, skrev Justin Uberti:
    > The Safari team has come up with a clever approach to avoid disclosing=
    > private IP addresses for host candidates. As discussed in this WebKit<= br> > bug <https://bugs.webkit.org/show_bug.cgi?id= =3D174500>, the technique
    > works as follows:
    >
    >=C2=A0 1. Register a random UUID-based mDNS name when ICE gathering sta= rts
    >=C2=A0 2. Replace the private IP address by a "{UUID}.local" = string in each
    >=C2=A0 =C2=A0 =C2=A0host candidate (and set raddr to 0.0.0.0 for other = candidates)
    >=C2=A0 3. The other party will do mDNS resolution on any candidate havi= ng a
    >=C2=A0 =C2=A0 =C2=A0.local suffix, similar to how hostnames in candidat= es are handled in
    >=C2=A0 =C2=A0 =C2=A0RFC 5245, Section 15.1.
    >
    > This technique is relevant to the IP handling document, as it addresse= s
    > one of the lesser problems (private IP disclosure) from the overall > problem statement. While I don't think this will have a large impa= ct on
    > the document, including the default mode selection, incorporating this=
    > technique would result in some moderate changes:
    >
    >=C2=A0 =C2=A0* Section 5.1 would mention concealing private IPs in the = default case
    >=C2=A0 =C2=A0 =C2=A0as an explicit goal.
    >=C2=A0 =C2=A0* In Section 6, Mode 2 would change from handling out priv= ate IPs to
    >=C2=A0 =C2=A0 =C2=A0handing out mDNS names.
    >=C2=A0 =C2=A0* This document would have to describe the technique or po= int to
    >=C2=A0 =C2=A0 =C2=A0another document that describes the technique. mmus= ic-ice-sip-sdp,
    >=C2=A0 =C2=A0 =C2=A0Section 4.1
    >=C2=A0 =C2=A0 =C2=A0<= https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1>=C2=A0seems
    >=C2=A0 =C2=A0 =C2=A0like a good option, as it already covers how to han= dle DNS names in
    >=C2=A0 =C2=A0 =C2=A0ICE candidates.
    >
    > This is a significant improvement and I think we will want to
    > incorporate this suggestion. Is this something we could do as part of<= br> > this WGLC, or should we look for another option?
    >
    >
    > _______________________________________________
    > 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
    --000000000000052462056eb1d5ca-- From nobody Fri Jun 15 11:30:58 2018 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 23CC4130DBE for ; Fri, 15 Jun 2018 11:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 J5ol2itxm_-a for ; Fri, 15 Jun 2018 11:30:53 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EFB12F18C for ; Fri, 15 Jun 2018 11:30:53 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id r24-v6so11524882ioh.9 for ; Fri, 15 Jun 2018 11:30:53 -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=vzMSICnpItcb2vIV4nO3Euih144c1fTZuq2vrjQrazI=; b=A1Y3Q68QMdzhkuBF/zJzKFz30Fi5saEBAeEGQ4I2eKImnG3JY08FT83P3zKgDK/ttl 4fxZYlNbpN/Cu0iVolqleqDN0daOnecKnizT2mpx1s2ulGLPzya8BlSgYhHSvGOKcMwr hwW7qd2iD0EVhJTc3/vL9wJv2xC0ukU+o6xHED7QYaq+8zUKNswOxgqrIUT9Htousvf+ NI680uNH6tQBmBYHfXpuPllVqnDaSY8D3fmHUr0+Xil2uLC38dTup492RDMcEcqOX+n9 tfI965YvFpu1BUOx1Q6mVgew/Gy2EyUW5EP2i0lfeqLwK58Qhmw8AyhgJxwutN1eSklN mEhw== 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=vzMSICnpItcb2vIV4nO3Euih144c1fTZuq2vrjQrazI=; b=XwP7So06Eu+EfpKtel4ErPBaIP3J7+HzKpT/awdFUQkgU2qXX09DGauFLTude7CErw 7Zzl6Xzh53cnH6NNoPcjY2kvyHQZrT0IEbJaEfFlDt7bcVBFTeXr4dD76Z3Vu3qNjTYv iFVqjAuq8/PQiN8KOyOyPHQ48T+TQwdafGKQDDba0Ie4T6v5XB8A7qVdH6qThtNKALCF lshlh1LgWfhhPMzHXZ5Vnfj1gAWG9/f01IX5w/s54BjYAxvvGGRdZEc1FMjk7yZ6RO73 Wd4Wh3m8HQqsWculqhXdwsOTvCOHPsLYLvUIOVJzBH5Puxs4GhpDD3UKlOw+4Blctr87 whHg== X-Gm-Message-State: APt69E3YaJA83dYlHJ4OApjs5lt/SWrmArbWgTFSKQy0hm0TkifAds29 dywcHFoMG4Z49452d0a2fFv8TpT8nPq9pS8ORrO+OA== X-Google-Smtp-Source: ADUXVKIKj9uX14xX9+c0pAFHrIHjcEsqnuqDCBT/Jpk38VNfgcjUnPxUumChrfES+2BdiX9/tuAOWcCttUWnwEf5m0U= X-Received: by 2002:a6b:3245:: with SMTP id y66-v6mr2348083ioy.87.1529087451978; Fri, 15 Jun 2018 11:30:51 -0700 (PDT) MIME-Version: 1.0 References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> In-Reply-To: <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> From: Justin Uberti Date: Fri, 15 Jun 2018 11:30:40 -0700 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000006861ba056eb26a84" Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 18:30:56 -0000 --0000000000006861ba056eb26a84 Content-Type: text/plain; charset="UTF-8" To be clear, I tried to keep the same numbering as Taylor - my #2 "explode" option is the same as Taylor's #2 "run the closing procedure". On Fri, Jun 15, 2018 at 9:44 AM Lennart Grahl wrote: > I would be fine with either Taylor's option 4) or Justin's option 2) by > raising an explicit error containing a stream ID. In the WebRTC spec, we > could then resolve this by adding an `error` event to the > `RTCSctpTransport` interface where the event would contain the stream ID > a message has been received on. > > Cheers > Lennart > > On 15.06.2018 18:28, Justin Uberti wrote: > > The key question is: what should the browser do if it gets a data channel > > message on a channel that it doesn't know about? > > > > I believe the only realistic options are: > > 1) eat it (silent failure) > > 2) explode (noisy but imprecise failure) > > > > > > On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings wrote: > > > >> > >> Can the browser take care of it from what it knows about setting up the > >> channel? > >> > >> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter > >> wrote: > >> > >> It sounds like you and Christer are suggesting the same thing: "don't > >> allow messages to be sent until you're sure the other peer has a > channel to > >> receive them". Except that there's no way for the WebRTC stack to know > >> that, since these channels are not signaled in SDP or any in-band > message. > >> > >> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings wrote: > >> > >>> > >>> > >>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < > >>> deadbeef=40google.com@dmarc.ietf.org> wrote: > >>> > >>> One might expect that a "reliable" data channel is guaranteed to be, > >>> well, reliable. But in current implementations, the first messages may > be > >>> lost if the application is negotiating the channels out-of-band, and > >>> creates the receiving channel too late. > >>> > >>> Here's a fiddle that demonstrates this (happens with Chrome and > Firefox): > >>> https://jsfiddle.net/o2m8tp20/ > >>> > >>> Normally this isn't an issue, because a typical application would > create > >>> the out-of-band negotiated channels before the first offer/answer is > >>> complete, and thus before the SCTP association is established. Meaning > that > >>> by the time a data channel is "open", it's guaranteed that the other > peer > >>> has a corresponding channel. > >>> > >>> But if for whatever reason, an application creates a data channel > *after* > >>> the SCTP association is established, then it will instantly be "open" > as > >>> soon as it's created. If a message is sent at this point, and it's > received > >>> by the other peer before it's created its corresponding data channel, > then > >>> the message will just be discarded. > >>> > >>> So, how should we deal with this? Some possibilities: > >>> > >>> 1. Say "this is expected behavior" and document it better, breaking > >>> the reliability promise. > >>> 2. Run the closing procedure if a message is received on a stream > >>> before a data channel is ready to receive it. > >>> 3. Don't even allow an out-of-band negotiated channel to be created > >>> after the SCTP association is established. > >>> 4. Buffer these messages for up to X seconds (or up to X bytes), to > >>> be delivered to the data channel once it's created. Run the closing > >>> procedure if X is exceeded. > >>> > >>> I'd vote for #2. Adding additional buffering logic seems like overkill > if > >>> this isn't a use case we really intended to support. > >>> > >>> > >>> I lean toward something that just did not allow the out-of-band > channel > >>> negotiation be used until it was set up. > >>> > >>> But whatever we do, not option 1 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> 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 > --0000000000006861ba056eb26a84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    To be clear, I tried to keep the same numbering as Taylor = - my #2 "explode" option is the same as Taylor's #2 "run= the closing procedure".

    On Fri, Jun 15, 2018 at 9:44 AM Lennart Grahl <lennart.grahl@gmail.com> wrote:
    I would be fine with either Taylor's = option 4) or Justin's option 2) by
    raising an explicit error containing a stream ID. In the WebRTC spec, we could then resolve this by adding an `error` event to the
    `RTCSctpTransport` interface where the event would contain the stream ID a message has been received on.

    Cheers
    Lennart

    On 15.06.2018 18:28, Justin Uberti wrote:
    > The key question is: what should the browser do if it gets a data chan= nel
    > message on a channel that it doesn't know about?
    >
    > I believe the only realistic options are:
    > 1) eat it (silent failure)
    > 2) explode (noisy but imprecise failure)
    >
    >
    > On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings <fluffy@iii.ca> wrote:
    >
    >>
    >> Can the browser take care of it from what it knows about setting u= p the
    >> channel?
    >>
    >> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter <deadbeef@google.com>
    >> wrote:
    >>
    >> It sounds like you and Christer are suggesting the same thing: &qu= ot;don't
    >> allow messages to be sent until you're sure the other peer has= a channel to
    >> receive them". Except that there's no way for the WebRTC = stack to know
    >> that, since these channels are not signaled in SDP or any in-band = message.
    >>
    >> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <fluffy@iii.ca> wrote:
    >>
    >>>
    >>>
    >>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <
    >>> deadbeef=3D40google.com@dmarc.ietf.org> wrote:
    >>>
    >>> One might expect that a "reliable" data channel is g= uaranteed to be,
    >>> well, reliable. But in current implementations, the first mess= ages may be
    >>> lost if the application is negotiating the channels out-of-ban= d, and
    >>> creates the receiving channel too late.
    >>>
    >>> Here's a fiddle that demonstrates this (happens with Chrom= e and Firefox):
    >>> https://jsfiddle.net/o2m8tp20/
    >>>
    >>> Normally this isn't an issue, because a typical applicatio= n would create
    >>> the out-of-band negotiated channels before the first offer/ans= wer is
    >>> complete, and thus before the SCTP association is established.= Meaning that
    >>> by the time a data channel is "open", it's guara= nteed that the other peer
    >>> has a corresponding channel.
    >>>
    >>> But if for whatever reason, an application creates a data chan= nel *after*
    >>> the SCTP association is established, then it will instantly be= "open" as
    >>> soon as it's created. If a message is sent at this point, = and it's received
    >>> by the other peer before it's created its corresponding da= ta channel, then
    >>> the message will just be discarded.
    >>>
    >>> So, how should we deal with this? Some possibilities:
    >>>
    >>>=C2=A0 =C2=A0 1. Say "this is expected behavior" and = document it better, breaking
    >>>=C2=A0 =C2=A0 the reliability promise.
    >>>=C2=A0 =C2=A0 2. Run the closing procedure if a message is rece= ived on a stream
    >>>=C2=A0 =C2=A0 before a data channel is ready to receive it.
    >>>=C2=A0 =C2=A0 3. Don't even allow an out-of-band negotiated= channel to be created
    >>>=C2=A0 =C2=A0 after the SCTP association is established.
    >>>=C2=A0 =C2=A0 4. Buffer these messages for up to X seconds (or = up to X bytes), to
    >>>=C2=A0 =C2=A0 be delivered to the data channel once it's cr= eated. Run the closing
    >>>=C2=A0 =C2=A0 procedure if X is exceeded.
    >>>
    >>> I'd vote for #2. Adding additional buffering logic seems l= ike overkill if
    >>> this isn't a use case we really intended to support.
    >>>
    >>>
    >>> I lean toward something that just did not allow the=C2=A0 out-= of-band channel
    >>> negotiation be used until it was set up.
    >>>
    >>> But whatever we do, not option 1
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>
    >> _______________________________________________
    >> rtcweb mailing list
    >> rtcweb@ietf.o= rg
    >> 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
    --0000000000006861ba056eb26a84-- From nobody Fri Jun 15 13:16:01 2018 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 818FD130E57 for ; Fri, 15 Jun 2018 13:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ieOJwQ62TMv for ; Fri, 15 Jun 2018 13:15:56 -0700 (PDT) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717A6130E44 for ; Fri, 15 Jun 2018 13:15:56 -0700 (PDT) Received: by mail-ot0-x22e.google.com with SMTP id r18-v6so12340512otk.1 for ; Fri, 15 Jun 2018 13:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UkG5ERwRPk5gSpHYzMyK1M+ku0SJyJgjc9OM/NT1jj8=; b=HCFqtybI1YExSA+73sf7n9EispQqReZwmE9DfAGK5ji9fYVoxlgA6L+O/zSHRHAPn+ c6rsqP4uuWxWnJsrRJloE7WjDpyIt2q0AYzhvSwdSeI+WZ9aFNpv8WYmx1F3NhYI6qo7 vsAFiPyrT/e965gpJUr+l01LrBVTZO94GlCYuX2+UC6sw9FvZTkQrvqcueM1WKi8bAvI wyJgnm3XLsdkR/LbD2QmRyzUPqXqlXk1DQuOtUArMtbWuAMZ3+QkqJ//ssieGLm3Ic/j ZmQv2ug8YdAxZgXs3HxcPqoybnk6/0DVSklKQ/9Bgp/CclHU1DcByhoWNZjrrHHW5fYo AcxQ== 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=UkG5ERwRPk5gSpHYzMyK1M+ku0SJyJgjc9OM/NT1jj8=; b=mtWcMZPGIpKJd93U5ZXBnJiVQPzAz0/ywAwAc4wZmtsTFImwPjSfEHbeA09XBtt5Hw kCGQz68XLhgZ86o6ZEv+RL1eoKICt53HqJQVffvB5sQG/9cBMcb/Vu79pdJIz9J/foAV RVLFes98Z4V+25WdeU63Vajnef94VuM3E4zvfiXksRuFE64DO+wUuWt2vwU8ykG/rC/G fQDg1a8D4fod+5I1ssyLec+tw8P2HqaRkFPhvAYsdJB+exRLcsxQvItqypt28XNY7xGd sEqkgnH6c/4CxCFQniMQgg5sNjVlJ+wbmmpqzOOjEghZjzqb3zFDuWpBwJJ2hg4KImci HVsA== X-Gm-Message-State: APt69E3f0cvricux3IYBehZdeyVmFIzb8ExKG+nkc9iIoUUsJmeAl8/Y LpW1B8pRxLcatULjc99rccOh6Obi+3scmKaQsIBMxQ== X-Google-Smtp-Source: ADUXVKLFpMAeYDzMC3W2Z+AoewjO51JQS2lhWD8mOMDgUN4qhyOuZ5csikeg/DFo2g05JI/6cTXXW3SySEeEyBuBSjM= X-Received: by 2002:a9d:5201:: with SMTP id e1-v6mr1838088oth.396.1529093755660; Fri, 15 Jun 2018 13:15:55 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Fri, 15 Jun 2018 13:15:47 -0700 Message-ID: To: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [rtcweb] Seeking reviewers for draft-ietf-mmusic-sdp-uks X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 15 Jun 2018 20:16:00 -0000 Hi Folks, We've this draft in mmusic that addresses a minor, but annoying hole in SDP negotiation. We've had some review of this and we think that it's basically good, but we'd like to see more review before we decide to publish. It's a little tricky to understand, so we're particularly looking for feedback on helping to improve the description of the attack. Cheers, Martin From nobody Sat Jun 16 08:40:17 2018 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 A35ED130EEF for ; Sat, 16 Jun 2018 08:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 YYirrH32BRVd for ; Sat, 16 Jun 2018 08:40:12 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA82D130DCA for ; Sat, 16 Jun 2018 08:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529163609; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tIfWknineg6u6+xLyN3GiR4rS+RW9ZRoDL9u6Q06Dm4=; b=hPltNhv8VODvWnIAxqJS83Hr/+TTWOKSBF6l16p/BOqlr3y2eE8uTcciGwNZ9FDv uYcRCfo17slGU5KtvxFwNKAzJQ6/b7FYUWaRDc5afSetZpF2CWwLzzlvRTyXa4/k xN4/OzRCErUrdBiR6Vp9fkQTOju24xt3n6Q3aRlCQYQ=; X-AuditID: c1b4fb3a-9e9ff700000079c1-59-5b252f593c3a Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 75.34.31169.95F252B5; Sat, 16 Jun 2018 17:40:09 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 16 Jun 2018 17:40:09 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Sat, 16 Jun 2018 17:40:09 +0200 From: Christer Holmberg To: T H Panton , Lennart Grahl CC: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels Thread-Index: AQHT+QykkBgeKHb7x06HnWNksweot6Rel8qAgAAl0ICAAreTgIAAAtsAgAAEjACAAAJKAIABntpQ Date: Sat, 16 Jun 2018 15:40:09 +0000 Message-ID: <4627e628bbaf4263b478e9abdaa2b7fe@ericsson.com> References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7tW6kvmq0wZqdShYfji9ltVj7r53d Yt37YywOzB47Z91l91iy5CeTx8Vp+5kCmKO4bFJSczLLUov07RK4Mk7db2QtmKNecffgU7YG xi6FLkZODgkBE4mpbx8wdjFycQgJHGWU2HX9NBuE841RovP/ZjaQKiGBZYwSb/aodjFycLAJ WEh0/9MGCYsI+Ehs372REcRmFlCXuLP4HDuILSxQILFwaT8LRE2hxLnrvYwQdpTEz13/WEDG sAioSrxc5QsS5hWwlnjychcrxNqVzBK73t9kBklwCjhJfD7yAMxmFBCT+H5qDRPELnGJW0/m M0E8ICCxZM95ZghbVOLl43+sELaSxN5j11kg6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCK zUIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzCmDm75bbWD8eBz x0OMAhyMSjy8sXqq0UKsiWXFlbmHGCU4mJVEeIvLVKKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ 8zqlWUQJCaQnlqRmp6YWpBbBZJk4OKUaGJmij9xOC8mOnD9piyVz5p/Y3K8pz++e7/m452j2 5V3ber+F7NP6/cXve8hvKxMtFo0rcUpKnc8NFrxbxLipzNmK/dXm78puf58rXrHh2eDmst8v yd9fOKazoPzqPvVJ/n+7jj33OXTsdOKmI1n31jlrXsz6x++nqzHTapYk0yx+yftTBbacL1Fi Kc5INNRiLipOBADKYpqCpQIAAA== Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 16 Jun 2018 15:40:15 -0000 +1 Regards, Christer=20 -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of T H Panton Sent: 15 June 2018 18:53 To: Lennart Grahl Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, o= ut-of-band negotiated data channels With my very old SNMP hat on, I say 1) you silently drop it. I'd also say that this indicates that the {negotiated:true, id:0} thing is = a misfeature. T. =20 > On 15 Jun 2018, at 17:44, Lennart Grahl wrote: >=20 > I would be fine with either Taylor's option 4) or Justin's option 2)=20 > by raising an explicit error containing a stream ID. In the WebRTC=20 > spec, we could then resolve this by adding an `error` event to the=20 > `RTCSctpTransport` interface where the event would contain the stream=20 > ID a message has been received on. >=20 > Cheers > Lennart >=20 > On 15.06.2018 18:28, Justin Uberti wrote: >> The key question is: what should the browser do if it gets a data=20 >> channel message on a channel that it doesn't know about? >>=20 >> I believe the only realistic options are: >> 1) eat it (silent failure) >> 2) explode (noisy but imprecise failure) >>=20 >>=20 >> On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings wrote: >>=20 >>>=20 >>> Can the browser take care of it from what it knows about setting up=20 >>> the channel? >>>=20 >>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter=20 >>> >>> wrote: >>>=20 >>> It sounds like you and Christer are suggesting the same thing:=20 >>> "don't allow messages to be sent until you're sure the other peer=20 >>> has a channel to receive them". Except that there's no way for the=20 >>> WebRTC stack to know that, since these channels are not signaled in SDP= or any in-band message. >>>=20 >>> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings wrote: >>>=20 >>>>=20 >>>>=20 >>>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <=20 >>>> deadbeef=3D40google.com@dmarc.ietf.org> wrote: >>>>=20 >>>> One might expect that a "reliable" data channel is guaranteed to=20 >>>> be, well, reliable. But in current implementations, the first=20 >>>> messages may be lost if the application is negotiating the channels=20 >>>> out-of-band, and creates the receiving channel too late. >>>>=20 >>>> Here's a fiddle that demonstrates this (happens with Chrome and Firefo= x): >>>> https://jsfiddle.net/o2m8tp20/ >>>>=20 >>>> Normally this isn't an issue, because a typical application would=20 >>>> create the out-of-band negotiated channels before the first=20 >>>> offer/answer is complete, and thus before the SCTP association is=20 >>>> established. Meaning that by the time a data channel is "open",=20 >>>> it's guaranteed that the other peer has a corresponding channel. >>>>=20 >>>> But if for whatever reason, an application creates a data channel=20 >>>> *after* the SCTP association is established, then it will instantly=20 >>>> be "open" as soon as it's created. If a message is sent at this=20 >>>> point, and it's received by the other peer before it's created its=20 >>>> corresponding data channel, then the message will just be discarded. >>>>=20 >>>> So, how should we deal with this? Some possibilities: >>>>=20 >>>> 1. Say "this is expected behavior" and document it better, breaking >>>> the reliability promise. >>>> 2. Run the closing procedure if a message is received on a stream >>>> before a data channel is ready to receive it. >>>> 3. Don't even allow an out-of-band negotiated channel to be created >>>> after the SCTP association is established. >>>> 4. Buffer these messages for up to X seconds (or up to X bytes), to >>>> be delivered to the data channel once it's created. Run the closing >>>> procedure if X is exceeded. >>>>=20 >>>> I'd vote for #2. Adding additional buffering logic seems like=20 >>>> overkill if this isn't a use case we really intended to support. >>>>=20 >>>>=20 >>>> I lean toward something that just did not allow the out-of-band=20 >>>> channel negotiation be used until it was set up. >>>>=20 >>>> But whatever we do, not option 1 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Sun Jun 17 03:59:37 2018 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 C1C1C130EBF; Sun, 17 Jun 2018 03:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 YYpSi_t3J40v; Sun, 17 Jun 2018 03:59:33 -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 E110F12F1A2; Sun, 17 Jun 2018 03:59:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id F35197C06D3; Sun, 17 Jun 2018 12:59:30 +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 YWswqTav8Tk5; Sun, 17 Jun 2018 12:59:29 +0200 (CEST) Received: from [192.168.8.102] (196-251-232.connect.netcom.no [178.232.251.196]) by mork.alvestrand.no (Postfix) with ESMTPSA id 281927C06AF; Sun, 17 Jun 2018 12:59:29 +0200 (CEST) Date: Sun, 17 Jun 2018 12:59:18 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WLMEWWZXG5NLPQXXGBHW1PGS76V9P7" Content-Transfer-Encoding: 7bit To: rtcweb@ietf.org, Christer Holmberg , "rtcweb@ietf.org" CC: "rtcweb-chairs@ietf.org" From: Harald Alvestrand Message-ID: <5B6BEA50-3B50-4E7A-8CFB-A59822647A4B@alvestrand.no> Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 17 Jun 2018 10:59:36 -0000 ------WLMEWWZXG5NLPQXXGBHW1PGS76V9P7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable BOF or bar BOF? Den 31=2E mai 2018 10:11:24 CEST, skrev Christer Holmberg : >Hi, > >I think we need to have discussions (in SOME forum) about the Identity >attribute=2E Because, in addition to the things that need to be >clarified, >based on the comments it seem like there are opinions/understandings >that >contradict what is currently written in the draft=2E > >Regards, > >Christer > > >On 30/05/18 16:18, "rtcweb on behalf of IETF Meeting Session Request >Tool" > wrote= : > >> >> >>Sean Turner, a chair of the rtcweb working group, indicated that the >>rtcweb working group does not plan to hold a session at IETF 102=2E >> >>This message was generated and sent by the IETF Meeting Session >Request >>Tool=2E >> >> >>_______________________________________________ >>rtcweb mailing list >>rtcweb@ietf=2Eorg >>https://www=2Eietf=2Eorg/mailman/listinfo/rtcweb > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/rtcweb --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------WLMEWWZXG5NLPQXXGBHW1PGS76V9P7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable BOF or bar BOF?

    = Den 31=2E mai 2018 10:11:24 CEST, skrev Christer Holmberg <christer=2Eho= lmberg@ericsson=2Ecom>:
    Hi,

    I think we need to have discussions (in S=
OME forum) about the Identity
    attribute=2E Because, in addition to the t=
hings that need to be clarified,
    based on the comments it seem like ther=
e are opinions/understandings that
    contradict what is currently written =
in the draft=2E

    Regards,

    Christer


    On 30/05/18 16:1=
8, "rtcweb on behalf of IETF Meeting Session Request Tool"
    <rtcweb-bo=
unces@ietf=2Eorg on behalf of session-request@ietf=2Eorg> wrote:

    =



    Sean Turner, a cha=
ir of the rtcweb working group, indicated that the
    rtcweb working group =
does not plan to hold a session at IETF 102=2E

    This message was gene=
rated and sent by the IETF Meeting Session Request
    Tool=2E



    rtcweb mailing list
    rtcweb@ietf=2Eorg
    https://www=2Eietf=2Eorg/mailman/listin=
fo/rtcweb


    rtcweb mailing list
    rtcweb@iet=
f=2Eorg
    htt=
ps://www=2Eietf=2Eorg/mailman/listinfo/rtcweb

    --
    Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------WLMEWWZXG5NLPQXXGBHW1PGS76V9P7-- From nobody Sun Jun 17 12:37:21 2018 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 504FC130E42 for ; Sun, 17 Jun 2018 12:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 aZ7Z87AaiY4M for ; Sun, 17 Jun 2018 12:37:17 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EF3127148 for ; Sun, 17 Jun 2018 12:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529264235; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8qzYCkHYkx6fe19lLjYeyzNlM1OyrIcTuIWhGifPVJA=; b=Zpn9wQiLYH8Bc0nz3DbB6xZJOTW7F8F30YnCtM9HPDHZkvcupvxmYr0uRwYIij6n 8PiVbhtiHHsguRT3goGa1kf6gGiqPyh+M+l2i9aNCkmi0Ew9Xc7UhX99QiRHhapB 65YvlioStYTqBDsPnE4N3ZhvPdqfYbibPdi4npxyKvQ=; X-AuditID: c1b4fb25-59dff70000007b3f-fb-5b26b86b1b42 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.35.31551.B68B62B5; Sun, 17 Jun 2018 21:37:15 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 17 Jun 2018 21:37:14 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Sun, 17 Jun 2018 21:37:15 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" , "rtcweb@ietf.org" CC: "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] rtcweb - Not having a session at IETF 102 Thread-Index: AQHT+BpFMR1PpqciJ0m6GiSkkXrIhqRJj6OAgBqzGwCAALGEAA== Date: Sun, 17 Jun 2018 19:37:15 +0000 Message-ID: References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> <5B6BEA50-3B50-4E7A-8CFB-A59822647A4B@alvestrand.no> In-Reply-To: <5B6BEA50-3B50-4E7A-8CFB-A59822647A4B@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/alternative; boundary="_000_bfda0a793cd543afa1a5ab2316da31a3ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2J7sW72DrVogxUd4hbH+rrYLHre3mCx WPuvnd2B2ePKhCusHkuW/GQKYIrisklJzcksSy3St0vgyvh64CBTwb3oijk3rjE2MM6J7GLk 5JAQMJFo+L6bsYuRi0NI4CijxM+H/YwgCSGBb4wSF9rLIRLLGCXmzW1l6WLk4GATsJDo/qcN UiMiUCHxf8VLZpAws4CpxIz7wSBhYQF7iSNzP7BAlDhIHFu7FKxTRMBJYts3axCTRUBVYsF1 G5AKXgFriaV7GlkgFm1nlPhw9R0rSIJTwFFi79ePbCA2o4CYxPdTa5hAbGYBcYlbT+YzQZwv ILFkz3lmCFtU4uXjf6wQtpLE3mPXWSDqkyV2L1jPBLFMUOLkzCcsExhFZyEZNQtJ2SwkZbPA HtOUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYx AmPu4JbfqjsYL79xPMQowMGoxMPrul0tWog1say4MvcQowQHs5IIb3OWarQQb0piZVVqUX58 UWlOavEhRmkOFiVx3ofmm6OEBNITS1KzU1MLUotgskwcnFINjK1PjD36nB7ycdZs5IqXsl31 7M7/4jfdIsyLJ/BM2PwmIzEsgvvUqwdX3j3NjK/Ys6PgoaJYg1XvxqSaUhfzk5qa07pmn3Fy VbX/vfagARfr7qhlt55NPrb8tdOEpTJ1T+YVJJnxrLzcHfolM5g54Yf2jvAjszfeuitas9Zj +sM/TNHHZBfbxyuxFGckGmoxFxUnAgCqaMARtQIAAA== Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 17 Jun 2018 19:37:20 -0000 --_000_bfda0a793cd543afa1a5ab2316da31a3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgZG9u4oCZdCByZWFsbHkgY2FyZSB3aGF0IHdlIGNhbGwgdGhlIGZvcnVtIHdoZXJl IGl0IHdpbGwgYmUgZGlzY3Vzc2VkLCBidXQgYXJlbuKAmXQgQk9GcyBtZWFudCBmb3IgZGlzY3Vz c2luZyBuZXcgc3R1ZmY/IFRoZSBJZGVudGl0eSBoZWFkZXIgZmllbGQgaXMgYWxyZWFkeSBwYXJ0 IG9mIG91ciB3b3JrLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBIYXJhbGQgQWx2 ZXN0cmFuZCBbbWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vXQ0KU2VudDogMTcgSnVuZSAyMDE4 IDEyOjU5DQpUbzogcnRjd2ViQGlldGYub3JnOyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgcnRjd2ViQGlldGYub3JnDQpDYzogcnRjd2ViLWNoYWly c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIHJ0Y3dlYiAtIE5vdCBoYXZpbmcgYSBz ZXNzaW9uIGF0IElFVEYgMTAyDQoNCkJPRiBvciBiYXIgQk9GPw0KRGVuIDMxLiBtYWkgMjAxOCAx MDoxMToyNCBDRVNULCBza3JldiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjoNCg0K SGksDQoNCkkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIGRpc2N1c3Npb25zIChpbiBTT01FIGZvcnVt KSBhYm91dCB0aGUgSWRlbnRpdHkNCmF0dHJpYnV0ZS4gQmVjYXVzZSwgaW4gYWRkaXRpb24gdG8g dGhlIHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUgY2xhcmlmaWVkLA0KYmFzZWQgb24gdGhlIGNvbW1l bnRzIGl0IHNlZW0gbGlrZSB0aGVyZSBhcmUgb3BpbmlvbnMvdW5kZXJzdGFuZGluZ3MgdGhhdA0K Y29udHJhZGljdCB3aGF0IGlzIGN1cnJlbnRseSB3cml0dGVuIGluIHRoZSBkcmFmdC4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAzMC8wNS8xOCAxNjoxOCwgInJ0Y3dlYiBvbiBiZWhh bGYgb2YgSUVURiBNZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sIg0KPHJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBzZXNzaW9uLXJlcXVlc3RAaWV0Zi5vcmc8bWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnJTIwb24lMjBiZWhhbGYlMjBvZiUyMHNlc3Npb24tcmVxdWVz dEBpZXRmLm9yZz4+IHdyb3RlOg0KDQoNClNlYW4gVHVybmVyLCBhIGNoYWlyIG9mIHRoZSBydGN3 ZWIgd29ya2luZyBncm91cCwgaW5kaWNhdGVkIHRoYXQgdGhlDQpydGN3ZWIgd29ya2luZyBncm91 cCBkb2VzIG5vdCBwbGFuIHRvIGhvbGQgYSBzZXNzaW9uIGF0IElFVEYgMTAyLg0KDQpUaGlzIG1l c3NhZ2Ugd2FzIGdlbmVyYXRlZCBhbmQgc2VudCBieSB0aGUgSUVURiBNZWV0aW5nIFNlc3Npb24g UmVxdWVzdA0KVG9vbC4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpy dGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpy dGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCi0tDQpTZW50IGZyb20gbXkgQW5kcm9pZCBk ZXZpY2Ugd2l0aCBLLTkgTWFpbC4gUGxlYXNlIGV4Y3VzZSBteSBicmV2aXR5Lg0K --_000_bfda0a793cd543afa1a5ab2316da31a3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYg OSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3Jt YXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRvbuKAmXQgcmVhbGx5IGNhcmUg d2hhdCB3ZSBjYWxsIHRoZSBmb3J1bSB3aGVyZSBpdCB3aWxsIGJlIGRpc2N1c3NlZCwgYnV0IGFy ZW7igJl0IEJPRnMgbWVhbnQgZm9yIGRpc2N1c3NpbmcgbmV3IHN0dWZmPyBUaGUgSWRlbnRpdHkN CiBoZWFkZXIgZmllbGQgaXMgYWxyZWFkeSBwYXJ0IG9mIG91ciB3b3JrLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEhhcmFsZCBBbHZlc3RyYW5k IFttYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTcgSnVu ZSAyMDE4IDEyOjU5PGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5vcmc7IENocmlzdGVyIEhv bG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7OyBydGN3ZWJAaWV0 Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYi1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtydGN3ZWJdIHJ0Y3dlYiAtIE5vdCBoYXZpbmcgYSBzZXNzaW9uIGF0IElF VEYgMTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5CT0Ygb3IgYmFyIEJPRj88bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZW4gMzEuIG1haSAyMDE4IDEwOjExOjI0IENF U1QsIHNrcmV2IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SGksPGJyPjxicj5JIHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSBkaXNjdXNzaW9u cyAoaW4gU09NRSBmb3J1bSkgYWJvdXQgdGhlIElkZW50aXR5PGJyPmF0dHJpYnV0ZS4gQmVjYXVz ZSwgaW4gYWRkaXRpb24gdG8gdGhlIHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUgY2xhcmlmaWVkLDxi cj5iYXNlZCBvbiB0aGUgY29tbWVudHMgaXQgc2VlbSBsaWtlIHRoZXJlIGFyZSBvcGluaW9ucy91 bmRlcnN0YW5kaW5ncyB0aGF0PGJyPmNvbnRyYWRpY3Qgd2hhdCBpcyBjdXJyZW50bHkgd3JpdHRl biBpbiB0aGUgZHJhZnQuPGJyPjxicj5SZWdhcmRzLDxicj48YnI+Q2hyaXN0ZXI8YnI+PGJyPjxi cj5PbiAzMC8wNS8xOCAxNjoxOCwgJnF1b3Q7cnRjd2ViIG9uIGJlaGFsZiBvZiBJRVRGIE1lZXRp bmcgU2Vzc2lvbiBSZXF1ZXN0IFRvb2wmcXVvdDs8YnI+Jmx0OzxhIGhyZWY9Im1haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZyUyMG9uJTIwYmVoYWxmJTIwb2YlMjBzZXNzaW9uLXJlcXVlc3RA aWV0Zi5vcmciPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzZXNzaW9uLXJl cXVlc3RAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3MjlGQ0YgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206Ni4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj48YnI+U2VhbiBUdXJuZXIsIGEgY2hhaXIgb2YgdGhlIHJ0Y3dlYiB3b3JraW5nIGdyb3Vw LCBpbmRpY2F0ZWQgdGhhdCB0aGU8YnI+cnRjd2ViIHdvcmtpbmcgZ3JvdXAgZG9lcyBub3QgcGxh biB0byBob2xkIGEgc2Vzc2lvbiBhdCBJRVRGIDEwMi48YnI+PGJyPlRoaXMgbWVzc2FnZSB3YXMg Z2VuZXJhdGVkIGFuZCBzZW50IGJ5IHRoZSBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0PGJy PlRvb2wuPGJyPjxicj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+PC9wcmU+DQo8 cHJlPjxicj5ydGN3ZWIgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0 Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+ PGhyIHNpemU9IjMiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj48L3ByZT4NCjxwcmU+PGJy PnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyI+ cnRjd2ViQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWI8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0gPGJyPg0KU2VudCBmcm9tIG15IEFuZHJvaWQgZGV2 aWNlIHdpdGggSy05IE1haWwuIFBsZWFzZSBleGN1c2UgbXkgYnJldml0eS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_bfda0a793cd543afa1a5ab2316da31a3ericssoncom_-- From nobody Sun Jun 17 12:40:59 2018 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 8DAF5130E41; Sun, 17 Jun 2018 12:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 PXgyoGypCgQd; Sun, 17 Jun 2018 12:40:54 -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 6D5E7127148; Sun, 17 Jun 2018 12:40:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 48C4A7C06D3; Sun, 17 Jun 2018 21:40: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 3qK_6THK9H5u; Sun, 17 Jun 2018 21:40:51 +0200 (CEST) Received: from [192.168.3.218] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id E5F9B7C04C2; Sun, 17 Jun 2018 21:40:50 +0200 (CEST) To: Christer Holmberg , "rtcweb@ietf.org" Cc: "rtcweb-chairs@ietf.org" References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> <5B6BEA50-3B50-4E7A-8CFB-A59822647A4B@alvestrand.no> 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: <1ec1bf10-f9df-7a72-60a3-bb75d6be58e8@alvestrand.no> Date: Sun, 17 Jun 2018 21:40:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------049D65DBB64E045B4BF923FB" Content-Language: en-GB Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 17 Jun 2018 19:40:58 -0000 This is a multi-part message in MIME format. --------------049D65DBB64E045B4BF923FB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/17/2018 09:37 PM, Christer Holmberg wrote: > > Hi, > >   > > I don’t really care what we call the forum where it will be discussed, > but aren’t BOFs meant for discussing new stuff? The Identity header > field is already part of our work. > It's what we use when we don't have a forum to discuss whatever it is we're discussing. Another possibility is to ask for a slot in the universal SDP forum - MMUSIC. >   > > Regards, > >   > > Christer > >   > > *From:*Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* 17 June 2018 12:59 > *To:* rtcweb@ietf.org; Christer Holmberg > ; rtcweb@ietf.org > *Cc:* rtcweb-chairs@ietf.org > *Subject:* Re: [rtcweb] rtcweb - Not having a session at IETF 102 > >   > > BOF or bar BOF? > > Den 31. mai 2018 10:11:24 CEST, skrev Christer Holmberg > >: > > Hi, > > I think we need to have discussions (in SOME forum) about the Identity > attribute. Because, in addition to the things that need to be clarified, > based on the comments it seem like there are opinions/understandings that > contradict what is currently written in the draft. > > Regards, > > Christer > > > On 30/05/18 16:18, "rtcweb on behalf of IETF Meeting Session Request Tool" > > wrote: > > > Sean Turner, a chair of the rtcweb working group, indicated that the > rtcweb working group does not plan to hold a session at IETF 102. > > This message was generated and sent by the IETF Meeting Session Request > Tool. > > ------------------------------------------------------------------------ > > 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 > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Surveillance is pervasive. Go Dark. --------------049D65DBB64E045B4BF923FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    On 06/17/2018 09:37 PM, Christer Holmberg wrote:

    Hi,

     

    I don’t really care what we call the forum where it will be discussed, but aren’t BOFs meant for discussing new stuff? The Identity header field is already part of our work.


    It's what we use when we don't have a forum to discuss whatever it is we're discussing.

    Another possibility is to ask for a slot in the universal SDP forum - MMUSIC.

     

    Regards,

     

    Christer

     

    From: Harald Alvestrand [mailto:harald@alvestrand.no]
    Sent: 17 June 2018 12:59
    To: rtcweb@ietf.org; Christer Holmberg <christer.holmberg@ericsson.com>; rtcweb@ietf.org
    Cc: rtcweb-chairs@ietf.org
    Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102

     

    BOF or bar BOF?

    Den 31. mai 2018 10:11:24 CEST, skrev Christer Holmberg <christer.holmberg@ericsson.com>:

    Hi,

I think we need to have discussions (in SOME forum) about the Identity
attribute. Because, in addition to the things that need to be clarified,
based on the comments it seem like there are opinions/understandings that
contradict what is currently written in the draft.

Regards,

Christer


On 30/05/18 16:18, "rtcweb on behalf of IETF Meeting Session Request Tool"
<rtcweb-bounces@ietf.org on behalf of session-request@ietf.org> wrote:
    
Sean Turner, a chair of the rtcweb working group, indicated that the
rtcweb working group does not plan to hold a session at IETF 102.

This message was generated and sent by the IETF Meeting Session Request
Tool.


    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


    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    -- 
Surveillance is pervasive. Go Dark.
    --------------049D65DBB64E045B4BF923FB-- From nobody Mon Jun 18 00:00:14 2018 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 C1F4E130DE6 for ; Mon, 18 Jun 2018 00:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 Zgy6PgZqX1V3 for ; Mon, 18 Jun 2018 00:00:05 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E7A130DEB for ; Mon, 18 Jun 2018 00:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1529305201; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fcp1q5TeNp0YtcgAwUdJ29cNraRCaWl6LHQ+vA1AtZ8=; b=S97M8UgCjj1jGpICfQIGfCL3d+RB+5YyT49MPMVFAtcMveamfRthJ1njeDeYtgkW aoqX+v1p6zcv7ugCcaVTmqgFsA+pxp1ZsOYZvASksp5+4SKQLqDXmsiUToh1VU4f l3HK+JELh0xvS1SyPrmQXEqfZQWp2uad9tcsP7Yy3Eo=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-86-5b2758710ee4 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4C.26.22015.178572B5; Mon, 18 Jun 2018 09:00:01 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 18 Jun 2018 09:00:00 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Mon, 18 Jun 2018 09:00:00 +0200 From: Christer Holmberg To: Harald Alvestrand , "rtcweb@ietf.org" CC: "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] rtcweb - Not having a session at IETF 102 Thread-Index: AQHT+BpFMR1PpqciJ0m6GiSkkXrIhqRJj6OAgBqzGwCAALGEAP//4DMAgADxWYA= Date: Mon, 18 Jun 2018 07:00:00 +0000 Message-ID: References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> <5B6BEA50-3B50-4E7A-8CFB-A59822647A4B@alvestrand.no> <1ec1bf10-f9df-7a72-60a3-bb75d6be58e8@alvestrand.no> In-Reply-To: <1ec1bf10-f9df-7a72-60a3-bb75d6be58e8@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8DC3719CCEFE244B8BBB014BDDA2AFDD@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM2J7uW5hhHq0wf4ZqhbH+rrYLHre3mCx WPuvnd2B2ePKhCusHkuW/GQKYIrisklJzcksSy3St0vgyuhZeZ+toFew4uTuGawNjE18XYyc HBICJhKzznxi7GLk4hASOMooMXXVKxYI5xujxK4bu9khnGWMEptu7GTqYuTgYBOwkOj+pw3S LSIQLNH7/D0jSJhZwFRixv1gkLCwgL3EtzU9zBAlDhLH1i5lgbD9JE7t+sEIYrMIqEr8+nCE CcTmFbCWuNX6FOqIBUwSt1/sAWvmFHCUOHliK1gzo4CYxPdTa8AamAXEJW49mc8E8YGAxJI9 55khbFGJl4//sYLYogJ6EhtO3GaHiCtJbOndAtWrJ3Fj6hQ2CNta4uDHeawQtrbEsoWvmSEO EpQ4OfMJywRGiVlI1s1C0j4LSfssJO2zkLQvYGRdxShanFpcnJtuZKyXWpSZXFycn6eXl1qy iREYkwe3/Nbdwbj6teMhRgEORiUeXkZ/9Wgh1sSy4srcQ4wSHMxKIrzqMkAh3pTEyqrUovz4 otKc1OJDjNIcLErivHqr9kQJCaQnlqRmp6YWpBbBZJk4OKUaGG2UWzoSqrK1m7dtV5K15ivR SnoUn7Z01b6nATavJyYuUd+RJ3PEhSvB1W5pQvF+9ztH72q0X4ru+nZEIUVe1O5T1CZHacvz dmH+b0MvKjP61iyOfmKn47g84VCytK5mVc0Ve5tXp1ZtfiZQ3PEo6fn3isZH1nW1V5cKOnAw xUbYX2Z/W8CrxFKckWioxVxUnAgAdaxdVMUCAAA= Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 07:00:12 -0000 Hi, =20 >> I don=B9t really care what we call the forum where it will be discussed, >>but aren=B9t BOFs meant for discussing new stuff? The Identity >> header field is already part of our work. > > It's what we use when we don't have a forum to discuss whatever it is >we're discussing. > > Another possibility is to ask for a slot in the universal SDP forum - >MMUSIC. Yes. We just need to make sure the right people are available (on-spot or remote). The author has not commented on the issues yet, as far as I remember. Regards, Christer =20 From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 17 June 2018 12:59 To: rtcweb@ietf.org; Christer Holmberg ; rtcweb@ietf.org Cc:=20 rtcweb-chairs@ietf.org Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 =20 BOF or bar BOF? Den 31. mai 2018 10:11:24 CEST, skrev Christer Holmberg : Hi, I think we need to have discussions (in SOME forum) about the Identity attribute. Because, in addition to the things that need to be clarified, based on the comments it seem like there are opinions/understandings that contradict what is currently written in the draft. Regards, Christer On 30/05/18 16:18, "rtcweb on behalf of IETF Meeting Session Request Tool" > wrote:Sean Turner, a chair of the rtcweb working group, indicated that the rtcweb working group does not plan to hold a session at IETF 102. This message was generated and sent by the IETF Meeting Session Request Tool. ________________________________________ rtcweb mailing list rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb ________________________________________ rtcweb mailing list rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb --=20 Sent from my Android device with K-9 Mail. Please excuse my brevity. --=20 Surveillance is pervasive. Go Dark. From nobody Mon Jun 18 15:45:06 2018 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 E259F13101C; Mon, 18 Jun 2018 15:44:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, rtcweb@ietf.org, lflynn@amsl.com, rtcweb-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152936189484.3120.16950226259858094588.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2018 15:44:54 -0700 Archived-At: Subject: [rtcweb] rtcweb - New Meeting Session Request for IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 18 Jun 2018 22:45:04 -0000 A new meeting session request has just been submitted by Liz Flynn, on behalf of the rtcweb working group. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: People who must be present: Sean Turner Adam Roach Cullen Jennings Ted Hardie Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jun 19 15:51:52 2018 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 45D00130FA6 for ; Tue, 19 Jun 2018 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 m-nUZd8hcBp4 for ; Tue, 19 Jun 2018 15:51:45 -0700 (PDT) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 6B813130FCD for ; Tue, 19 Jun 2018 15:51:44 -0700 (PDT) Received: by mail-ua0-x242.google.com with SMTP id k14-v6so904942uao.12 for ; Tue, 19 Jun 2018 15:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7VLkSgMwwiJQEjlDgJ+ErRoF0btOVLe23mHb22cIOgE=; b=JQ8ieY/gspWMsffXX9fBqiBGxNPlPf3CBpZGPOCIQkCh79545tKDK7Rb7ug4CiSF4O zXWhTz2hM5pmkGrYuTIOsN/ioc8TiV69ndaM/9go3EsZaC0nimgAUFLesb9yIoVyVaGK NEdcbJL/VXUh0R7s8AqpP/yAwmPtcDxJ0w5EmtLSkqW5eX7+G0wj3LTciRBnSAMW/3ha rAZPbs5bvayd5Phw7dwxi3gZUks7CN8kZK6fVu+nyQdtQC+ITPFW/bae2Z7HihZ8zRBh ZEqCxG2HoLMHdfhfFE09iz7dkAfh+BksjbDSZVI7VK/QSlUYNGVtPk3kMwdQWa9PZPk8 vUtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7VLkSgMwwiJQEjlDgJ+ErRoF0btOVLe23mHb22cIOgE=; b=WyVG5DtSRWY49WGuatGsRBOw0/r+sE6wHiJXd3hDQICVr7BX+lvjrKoDSmq8ukxdr+ 5gMjhhT5sPT27K8de93ZDu4fcq+dn0Go4zl3VOwQcAXJersMYViP9H25KySoT8AOELru G2c3d4jrfmtbq/lEobptEtaS34djAqqDslG0/djVoCBn1EQMoIVHDWhsyx6mtcdB7I3v 3r2NZA190oM3xYrarVdD7rdqODmUSutkLzFXFaSDrCyvSxxmX/6w0BbffrFZqBSrpUSc QDtpJG+JOWg0Xz5U1d17rHO7aSok7Nw6WMIQSAKspJ6pxAO+xixSUwlXjm0PsA7wYyEZ X6GQ== X-Gm-Message-State: APt69E0CraOrpUF6l/M9hKGoHAHNoKYTXHWwySVbGNX9KvdzpH4M4z1L 0m2Fbvf3+S1nT9nkAoa+cjfYnooibSgQpOVA+OIvtQ== X-Google-Smtp-Source: ADUXVKJhVQWR5FEbDLr4R7rIv4gKdf8jPjv8x5nRGrkfx9HJYlyVe5avpITW9OQxKs0/0e4tguj9b5lTUWm8X+1jiZw= X-Received: by 2002:ab0:130a:: with SMTP id g10-v6mr10962563uae.175.1529448703149; Tue, 19 Jun 2018 15:51:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 15:51:42 -0700 (PDT) In-Reply-To: <4627e628bbaf4263b478e9abdaa2b7fe@ericsson.com> References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> <4627e628bbaf4263b478e9abdaa2b7fe@ericsson.com> From: Taylor Brandstetter Date: Tue, 19 Jun 2018 15:51:42 -0700 Message-ID: To: Christer Holmberg Cc: T H Panton , Lennart Grahl , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a7befd056f06869c" Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 22:51:51 -0000 --000000000000a7befd056f06869c Content-Type: text/plain; charset="UTF-8" It looks like we have 2 votes for "silently drop", 1 for "blow up" and 1 for "behave nicely"... Since this behavior is already undefined, "silently drop" would certainly be the easiest; we can just add a note to the W3C spec: https://github.com/w3c/webrtc-pc/pull/1903 On Sat, Jun 16, 2018 at 8:40 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > +1 > > Regards, > > Christer > > -----Original Message----- > From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of T H Panton > Sent: 15 June 2018 18:53 > To: Lennart Grahl > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, > out-of-band negotiated data channels > > > With my very old SNMP hat on, I say 1) you silently drop it. > > I'd also say that this indicates that the {negotiated:true, id:0} thing is > a misfeature. > > T. > > > > On 15 Jun 2018, at 17:44, Lennart Grahl wrote: > > > > I would be fine with either Taylor's option 4) or Justin's option 2) > > by raising an explicit error containing a stream ID. In the WebRTC > > spec, we could then resolve this by adding an `error` event to the > > `RTCSctpTransport` interface where the event would contain the stream > > ID a message has been received on. > > > > Cheers > > Lennart > > > > On 15.06.2018 18:28, Justin Uberti wrote: > >> The key question is: what should the browser do if it gets a data > >> channel message on a channel that it doesn't know about? > >> > >> I believe the only realistic options are: > >> 1) eat it (silent failure) > >> 2) explode (noisy but imprecise failure) > >> > >> > >> On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings wrote: > >> > >>> > >>> Can the browser take care of it from what it knows about setting up > >>> the channel? > >>> > >>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter > >>> > >>> wrote: > >>> > >>> It sounds like you and Christer are suggesting the same thing: > >>> "don't allow messages to be sent until you're sure the other peer > >>> has a channel to receive them". Except that there's no way for the > >>> WebRTC stack to know that, since these channels are not signaled in > SDP or any in-band message. > >>> > >>> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings > wrote: > >>> > >>>> > >>>> > >>>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < > >>>> deadbeef=40google.com@dmarc.ietf.org> wrote: > >>>> > >>>> One might expect that a "reliable" data channel is guaranteed to > >>>> be, well, reliable. But in current implementations, the first > >>>> messages may be lost if the application is negotiating the channels > >>>> out-of-band, and creates the receiving channel too late. > >>>> > >>>> Here's a fiddle that demonstrates this (happens with Chrome and > Firefox): > >>>> https://jsfiddle.net/o2m8tp20/ > >>>> > >>>> Normally this isn't an issue, because a typical application would > >>>> create the out-of-band negotiated channels before the first > >>>> offer/answer is complete, and thus before the SCTP association is > >>>> established. Meaning that by the time a data channel is "open", > >>>> it's guaranteed that the other peer has a corresponding channel. > >>>> > >>>> But if for whatever reason, an application creates a data channel > >>>> *after* the SCTP association is established, then it will instantly > >>>> be "open" as soon as it's created. If a message is sent at this > >>>> point, and it's received by the other peer before it's created its > >>>> corresponding data channel, then the message will just be discarded. > >>>> > >>>> So, how should we deal with this? Some possibilities: > >>>> > >>>> 1. Say "this is expected behavior" and document it better, breaking > >>>> the reliability promise. > >>>> 2. Run the closing procedure if a message is received on a stream > >>>> before a data channel is ready to receive it. > >>>> 3. Don't even allow an out-of-band negotiated channel to be created > >>>> after the SCTP association is established. > >>>> 4. Buffer these messages for up to X seconds (or up to X bytes), to > >>>> be delivered to the data channel once it's created. Run the closing > >>>> procedure if X is exceeded. > >>>> > >>>> I'd vote for #2. Adding additional buffering logic seems like > >>>> overkill if this isn't a use case we really intended to support. > >>>> > >>>> > >>>> I lean toward something that just did not allow the out-of-band > >>>> channel negotiation be used until it was set up. > >>>> > >>>> But whatever we do, not option 1 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > 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 > --000000000000a7befd056f06869c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It looks like we have 2 votes for "silently drop"= ;, 1 for "blow up" and 1 for "behave nicely"...
    Since this behavior is already undefined, "silently drop&q= uot; would certainly be the easiest; we can just add a note to the W3C spec= :=C2=A0https://githu= b.com/w3c/webrtc-pc/pull/1903
    On Sat, Jun 16, 2018 at 8:40 AM, Christer Holmb= erg <christer.holmberg@ericsson.com> wrote:
    =
    +1

    Regards,

    Christer

    -----Original Message-----
    From: rtcweb [mailto:rtcweb-boun= ces@ietf.org] On Behalf Of T H Panton
    Sent: 15 June 2018 18:53
    To: Lennart Grahl <lennart.gr= ahl@gmail.com>
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, o= ut-of-band negotiated data channels


    With my very old SNMP hat on, I say 1) you silently drop it.

    I'd also say that this indicates that the {negotiated:true, id:0} thing= is a misfeature.

    T.


    > On 15 Jun 2018, at 17:44, Lennart Grahl <lennart.grahl@gmail.com> wrote:
    >
    > I would be fine with either Taylor's option 4) or Justin's opt= ion 2)
    > by raising an explicit error containing a stream ID. In the WebRTC > spec, we could then resolve this by adding an `error` event to the > `RTCSctpTransport` interface where the event would contain the stream =
    > ID a message has been received on.
    >
    > Cheers
    > Lennart
    >
    > On 15.06.2018 18:28, Justin Uberti wrote:
    >> The key question is: what should the browser do if it gets a data =
    >> channel message on a channel that it doesn't know about?
    >>
    >> I believe the only realistic options are:
    >> 1) eat it (silent failure)
    >> 2) explode (noisy but imprecise failure)
    >>
    >>
    >> On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings <fluffy@iii.ca> wrote:
    >>
    >>>
    >>> Can the browser take care of it from what it knows about setti= ng up
    >>> the channel?
    >>>
    >>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter
    >>> <deadbeef@google.com= >
    >>> wrote:
    >>>
    >>> It sounds like you and Christer are suggesting the same thing:=
    >>> "don't allow messages to be sent until you're sur= e the other peer
    >>> has a channel to receive them". Except that there's n= o way for the
    >>> WebRTC stack to know that, since these channels are not signal= ed in SDP or any in-band message.
    >>>
    >>> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <fluffy@iii.ca> wrote:
    >>>
    >>>>
    >>>>
    >>>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < >>>> deadbeef=3D= 40google.com@dmarc.ietf.org> wrote:
    >>>>
    >>>> One might expect that a "reliable" data channel = is guaranteed to
    >>>> be, well, reliable. But in current implementations, the fi= rst
    >>>> messages may be lost if the application is negotiating the= channels
    >>>> out-of-band, and creates the receiving channel too late. >>>>
    >>>> Here's a fiddle that demonstrates this (happens with C= hrome and Firefox):
    >>>> https://jsfiddle.net/o2m8tp20/
    >>>>
    >>>> Normally this isn't an issue, because a typical applic= ation would
    >>>> create the out-of-band negotiated channels before the firs= t
    >>>> offer/answer is complete, and thus before the SCTP associa= tion is
    >>>> established. Meaning that by the time a data channel is &q= uot;open",
    >>>> it's guaranteed that the other peer has a correspondin= g channel.
    >>>>
    >>>> But if for whatever reason, an application creates a data = channel
    >>>> *after* the SCTP association is established, then it will = instantly
    >>>> be "open" as soon as it's created. If a mess= age is sent at this
    >>>> point, and it's received by the other peer before it&#= 39;s created its
    >>>> corresponding data channel, then the message will just be = discarded.
    >>>>
    >>>> So, how should we deal with this? Some possibilities:
    >>>>
    >>>>=C2=A0 =C2=A01. Say "this is expected behavior" a= nd document it better, breaking
    >>>>=C2=A0 =C2=A0the reliability promise.
    >>>>=C2=A0 =C2=A02. Run the closing procedure if a message is r= eceived on a stream
    >>>>=C2=A0 =C2=A0before a data channel is ready to receive it.<= br> >>>>=C2=A0 =C2=A03. Don't even allow an out-of-band negotia= ted channel to be created
    >>>>=C2=A0 =C2=A0after the SCTP association is established.
    >>>>=C2=A0 =C2=A04. Buffer these messages for up to X seconds (= or up to X bytes), to
    >>>>=C2=A0 =C2=A0be delivered to the data channel once it's= created. Run the closing
    >>>>=C2=A0 =C2=A0procedure if X is exceeded.
    >>>>
    >>>> I'd vote for #2. Adding additional buffering logic see= ms like
    >>>> overkill if this isn't a use case we really intended t= o support.
    >>>>
    >>>>
    >>>> I lean toward something that just did not allow the=C2=A0 = out-of-band
    >>>> channel negotiation be used until it was set up.
    >>>>
    >>>> But whatever we do, not option 1
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>> _______________________________________________
    >>> rtcweb mailing list
    >>> rtcweb@ietf.org
    >>> https://www.ietf.org/mailman/listinf= o/rtcweb
    >>>
    >>
    >>
    >>
    >> _______________________________________________
    >> rtcweb mailing list
    >> rtcweb@ietf.org
    >> https://www.ietf.org/mailman/listinfo/rtcw= eb
    >>
    >
    >
    > _______________________________________________
    > 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

    --000000000000a7befd056f06869c-- From nobody Tue Jun 19 16:58:08 2018 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 6FA72131012 for ; Tue, 19 Jun 2018 16:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.488 X-Spam-Level: X-Spam-Status: No, score=-16.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 U6v9RpW5_xbw for ; Tue, 19 Jun 2018 16:58:03 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 5DEA3130E58 for ; Tue, 19 Jun 2018 16:58:03 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id g7-v6so1843124ioh.11 for ; Tue, 19 Jun 2018 16:58:03 -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:cc; bh=NygX3IcKZ49kzyGc6Bduel+rdLQrj7Xv7wRNbrT2RA4=; b=gdH9VU+MQizTIesGj8nraRnnV/UwVHZbYLNBZd9R2nAHvSXJdhq/u4mG4BQzFwpMBV 4zdVV/9CaHNj3ogT9JspuFe63Zed1P45x28Isddsa9CIrGHkRfia4H0Hs9roL0G30ItF QM/PNbj3xUMC7+FuSSvZZDz1LVTfKW9KpURNLLaE+aXdWvmF3n6IQKnC/HB9UCSOaUC3 XdSHrZZvim1JQyXIArVkkB9oGcua00pdr9NqxhQsYof2MUbA2rF27YPIYw51Rh1vcS52 +qBJwXWAVKTJmAkmK+7+ddD5L4BPo1ZLeJa9JNRl5iKXBAFyt7KmOaqgRHxeWljp0NTE CaqQ== 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:cc; bh=NygX3IcKZ49kzyGc6Bduel+rdLQrj7Xv7wRNbrT2RA4=; b=Ws6/koZTrDhVCNUl5nrEQcW9aIRtjWRFUE4bjACLZkMqR4LVXXxOPs0y/xrVbdiBrW YWpr0oS9akMN+U/wtbiByqk9RwoKr+4j58vgpoTsWN6sIYsq9PHhQ5mX5tFO+iap+iqC TZJdbEXqWBwOCkdSLb4nLa1qAzNPmktXNtUnoEZGJqYSwfUOrtuOuVn7qusr1Rac/DNS urikwlFbmCY5WXFnr/+wRAQrFkUxPJ4Gnex77WX2bi+4efuhlrJ5b+m1SnRUm1Ue4Soh xQqK/W9+UAR7Ew5eTFM5d3yAQigMu/twTy8zbd8YrnLYXvmDG04PbFWlIo2ou7uPB1hV vzFQ== X-Gm-Message-State: APt69E0Z0LuoY3jV3OvhshD3lNX6BAxry4z6BWFFliXdgRndtMAMwJg4 OLghC8vva1FGBK4WCJQt+QTpAK/fhqHlOgTm1a/IbA== X-Received: by 2002:a6b:e907:: with SMTP id u7-v6mt261615iof.38.1529452682193; Tue, 19 Jun 2018 16:58:02 -0700 (PDT) MIME-Version: 1.0 References: <4C57BFED-4A4D-4B9E-931A-173E1FE493DF@iii.ca> <5A43B371-5B53-4066-9C8C-AD64684DB357@iii.ca> <9a5be20f-52e9-8ac7-f213-384f29a7bd28@gmail.com> <4627e628bbaf4263b478e9abdaa2b7fe@ericsson.com> In-Reply-To: From: Justin Uberti Date: Tue, 19 Jun 2018 16:57:51 -0700 Message-ID: Cc: Christer Holmberg , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000d4f973056f077372" Archived-At: Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 19 Jun 2018 23:58:07 -0000 --000000000000d4f973056f077372 Content-Type: text/plain; charset="UTF-8" I'm fine with that. We could advise implementations to log something to the console when this happens. On Tue, Jun 19, 2018 at 3:52 PM Taylor Brandstetter wrote: > It looks like we have 2 votes for "silently drop", 1 for "blow up" and 1 > for "behave nicely"... > > Since this behavior is already undefined, "silently drop" would certainly > be the easiest; we can just add a note to the W3C spec: > https://github.com/w3c/webrtc-pc/pull/1903 > > On Sat, Jun 16, 2018 at 8:40 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> +1 >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of T H Panton >> Sent: 15 June 2018 18:53 >> To: Lennart Grahl >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, >> out-of-band negotiated data channels >> >> >> With my very old SNMP hat on, I say 1) you silently drop it. >> >> I'd also say that this indicates that the {negotiated:true, id:0} thing >> is a misfeature. >> >> T. >> >> >> > On 15 Jun 2018, at 17:44, Lennart Grahl >> wrote: >> > >> > I would be fine with either Taylor's option 4) or Justin's option 2) >> > by raising an explicit error containing a stream ID. In the WebRTC >> > spec, we could then resolve this by adding an `error` event to the >> > `RTCSctpTransport` interface where the event would contain the stream >> > ID a message has been received on. >> > >> > Cheers >> > Lennart >> > >> > On 15.06.2018 18:28, Justin Uberti wrote: >> >> The key question is: what should the browser do if it gets a data >> >> channel message on a channel that it doesn't know about? >> >> >> >> I believe the only realistic options are: >> >> 1) eat it (silent failure) >> >> 2) explode (noisy but imprecise failure) >> >> >> >> >> >> On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings wrote: >> >> >> >>> >> >>> Can the browser take care of it from what it knows about setting up >> >>> the channel? >> >>> >> >>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter >> >>> >> >>> wrote: >> >>> >> >>> It sounds like you and Christer are suggesting the same thing: >> >>> "don't allow messages to be sent until you're sure the other peer >> >>> has a channel to receive them". Except that there's no way for the >> >>> WebRTC stack to know that, since these channels are not signaled in >> SDP or any in-band message. >> >>> >> >>> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings >> wrote: >> >>> >> >>>> >> >>>> >> >>>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < >> >>>> deadbeef=40google.com@dmarc.ietf.org> wrote: >> >>>> >> >>>> One might expect that a "reliable" data channel is guaranteed to >> >>>> be, well, reliable. But in current implementations, the first >> >>>> messages may be lost if the application is negotiating the channels >> >>>> out-of-band, and creates the receiving channel too late. >> >>>> >> >>>> Here's a fiddle that demonstrates this (happens with Chrome and >> Firefox): >> >>>> https://jsfiddle.net/o2m8tp20/ >> >>>> >> >>>> Normally this isn't an issue, because a typical application would >> >>>> create the out-of-band negotiated channels before the first >> >>>> offer/answer is complete, and thus before the SCTP association is >> >>>> established. Meaning that by the time a data channel is "open", >> >>>> it's guaranteed that the other peer has a corresponding channel. >> >>>> >> >>>> But if for whatever reason, an application creates a data channel >> >>>> *after* the SCTP association is established, then it will instantly >> >>>> be "open" as soon as it's created. If a message is sent at this >> >>>> point, and it's received by the other peer before it's created its >> >>>> corresponding data channel, then the message will just be discarded. >> >>>> >> >>>> So, how should we deal with this? Some possibilities: >> >>>> >> >>>> 1. Say "this is expected behavior" and document it better, breaking >> >>>> the reliability promise. >> >>>> 2. Run the closing procedure if a message is received on a stream >> >>>> before a data channel is ready to receive it. >> >>>> 3. Don't even allow an out-of-band negotiated channel to be created >> >>>> after the SCTP association is established. >> >>>> 4. Buffer these messages for up to X seconds (or up to X bytes), to >> >>>> be delivered to the data channel once it's created. Run the closing >> >>>> procedure if X is exceeded. >> >>>> >> >>>> I'd vote for #2. Adding additional buffering logic seems like >> >>>> overkill if this isn't a use case we really intended to support. >> >>>> >> >>>> >> >>>> I lean toward something that just did not allow the out-of-band >> >>>> channel negotiation be used until it was set up. >> >>>> >> >>>> But whatever we do, not option 1 >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> _______________________________________________ >> >>> 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 >> >> _______________________________________________ >> 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 > --000000000000d4f973056f077372 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm fine with that. We could advise implementations to= log something to the console when this happens.

    On Tue, Jun 19, 2018 at 3:52 PM Taylor Brandstet= ter <deadbeef=3D40google.= com@dmarc.ietf.org> wrote:
    <= div dir=3D"ltr">It looks like we have 2 votes for "silently drop"= , 1 for "blow up" and 1 for "behave nicely"...

    =
    Since this behavior is already undefined, "silently drop&qu= ot; would certainly be the easiest; we can just add a note to the W3C spec:= =C2=A0https://github.com/w3c/webrtc-pc/pull/1903

    On Sat, Jun 16, 2018 at 8:40 A= M, Christer Holmberg <christer.holmberg@ericsson.com><= /span> wrote:
    +1

    Regards,

    Christer

    -----Original Message-----
    From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of T H Panton
    Sent: 15 June 2018 18:53
    To: Lennart Grahl <lennart.grahl@gmail.com>
    Cc: rtcweb@ietf.org
    Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, o= ut-of-band negotiated data channels


    With my very old SNMP hat on, I say 1) you silently drop it.

    I'd also say that this indicates that the {negotiated:true, id:0} thing= is a misfeature.

    T.


    > On 15 Jun 2018, at 17:44, Lennart Grahl <    lennart.grahl@gmail.com> wrote: >
    > I would be fine with either Taylor's option 4) or Justin's opt= ion 2)
    > by raising an explicit error containing a stream ID. In the WebRTC > spec, we could then resolve this by adding an `error` event to the > `RTCSctpTransport` interface where the event would contain the stream =
    > ID a message has been received on.
    >
    > Cheers
    > Lennart
    >
    > On 15.06.2018 18:28, Justin Uberti wrote:
    >> The key question is: what should the browser do if it gets a data =
    >> channel message on a channel that it doesn't know about?
    >>
    >> I believe the only realistic options are:
    >> 1) eat it (silent failure)
    >> 2) explode (noisy but imprecise failure)
    >>
    >>
    >> On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings <fluffy@iii.ca> wrote:
    >>
    >>>
    >>> Can the browser take care of it from what it knows about setti= ng up
    >>> the channel?
    >>>
    >>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter
    >>> <d= eadbeef@google.com>
    >>> wrote:
    >>>
    >>> It sounds like you and Christer are suggesting the same thing:=
    >>> "don't allow messages to be sent until you're sur= e the other peer
    >>> has a channel to receive them". Except that there's n= o way for the
    >>> WebRTC stack to know that, since these channels are not signal= ed in SDP or any in-band message.
    >>>
    >>> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <fluffy@iii.ca> wrote: >>>
    >>>>
    >>>>
    >>>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter < >>>> deadbeef=3D40google.com@dmarc.ietf.org> wrote:
    >>>>
    >>>> One might expect that a "reliable" data channel = is guaranteed to
    >>>> be, well, reliable. But in current implementations, the fi= rst
    >>>> messages may be lost if the application is negotiating the= channels
    >>>> out-of-band, and creates the receiving channel too late. >>>>
    >>>> Here's a fiddle that demonstrates this (happens with C= hrome and Firefox):
    >>>> https://jsfiddle.net/o2m8tp20/
    >>>>
    >>>> Normally this isn't an issue, because a typical applic= ation would
    >>>> create the out-of-band negotiated channels before the firs= t
    >>>> offer/answer is complete, and thus before the SCTP associa= tion is
    >>>> established. Meaning that by the time a data channel is &q= uot;open",
    >>>> it's guaranteed that the other peer has a correspondin= g channel.
    >>>>
    >>>> But if for whatever reason, an application creates a data = channel
    >>>> *after* the SCTP association is established, then it will = instantly
    >>>> be "open" as soon as it's created. If a mess= age is sent at this
    >>>> point, and it's received by the other peer before it&#= 39;s created its
    >>>> corresponding data channel, then the message will just be = discarded.
    >>>>
    >>>> So, how should we deal with this? Some possibilities:
    >>>>
    >>>>=C2=A0 =C2=A01. Say "this is expected behavior" a= nd document it better, breaking
    >>>>=C2=A0 =C2=A0the reliability promise.
    >>>>=C2=A0 =C2=A02. Run the closing procedure if a message is r= eceived on a stream
    >>>>=C2=A0 =C2=A0before a data channel is ready to receive it.<= br> >>>>=C2=A0 =C2=A03. Don't even allow an out-of-band negotia= ted channel to be created
    >>>>=C2=A0 =C2=A0after the SCTP association is established.
    >>>>=C2=A0 =C2=A04. Buffer these messages for up to X seconds (= or up to X bytes), to
    >>>>=C2=A0 =C2=A0be delivered to the data channel once it's= created. Run the closing
    >>>>=C2=A0 =C2=A0procedure if X is exceeded.
    >>>>
    >>>> I'd vote for #2. Adding additional buffering logic see= ms like
    >>>> overkill if this isn't a use case we really intended t= o support.
    >>>>
    >>>>
    >>>> I lean toward something that just did not allow the=C2=A0 = out-of-band
    >>>> channel negotiation be used until it was set up.
    >>>>
    >>>> But whatever we do, not option 1
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>>
    >>>
    >>> _______________________________________________
    >>> rtcweb mailing list
    >>> rtcweb@ie= tf.org
    >>> https://www.ietf.org/mailman/listinfo/rtc= web
    >>>
    >>
    >>
    >>
    >> _______________________________________________
    >> rtcweb mailing list
    >> rtcweb@ietf.o= rg
    >> 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

    _______________________________________________
    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
    --000000000000d4f973056f077372-- From nobody Sun Jun 24 21:21:28 2018 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 45268127AC2 for ; Sun, 24 Jun 2018 21:21:27 -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] 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 Q28Dhixqv6BP for ; Sun, 24 Jun 2018 21:21:24 -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 78C991277CC for ; Sun, 24 Jun 2018 21:21:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id F38EB7C3AF3 for ; Mon, 25 Jun 2018 06:21:22 +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 a-XVpA-Fvjte for ; Mon, 25 Jun 2018 06:21:21 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id C4E417C3AE8 for ; Mon, 25 Jun 2018 06:21:21 +0200 (CEST) To: rtcweb@ietf.org References: <152936189484.3120.16950226259858094588.idtracker@ietfa.amsl.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: <81cdccf7-b945-61f6-1545-fbf9d3ec6ff6@alvestrand.no> Date: Mon, 25 Jun 2018 06:21:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152936189484.3120.16950226259858094588.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] rtcweb - New Meeting Session Request for IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 04:21:28 -0000 I assume this means that we've gotten a waiver for the deadline, and that there will be no July 2-3 interim. I'd like to add Martin Thomson to the "people who must be present" list. Den 19. juni 2018 00:44, skrev IETF Meeting Session Request Tool: > > > A new meeting session request has just been submitted by Liz Flynn, on behalf of the rtcweb working group. > > > --------------------------------------------------------- > Working Group Name: Real-Time Communication in WEB-browsers > Area Name: Applications and Real-Time Area > Session Requester: Liz Flynn > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 50 > Conflicts to Avoid: > > > > > > People who must be present: > Sean Turner > Adam Roach > Cullen Jennings > Ted Hardie > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Sun Jun 24 21:34:57 2018 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 BF1821277CC for ; Sun, 24 Jun 2018 21:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 T0Y34AEQkOiQ for ; Sun, 24 Jun 2018 21:34:52 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 8BCB3127AC2 for ; Sun, 24 Jun 2018 21:34:52 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id y127-v6so11053809itd.1 for ; Sun, 24 Jun 2018 21:34:52 -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=wCPeSzQmc1L7HaHEJ61DNj7iHXGUDqfpyn/35UhLrUU=; b=YVTizEjGyBnG5DDkpVT/GiWFt/cGWZte84p/PuR2wuqZGyEhJXV73aHJjAnOryI9c1 MzRffkbmIKwXLoNmOHiPRSv7ud7MzfOAXcMi1EUnpWWdSWnpRay+58X+bJ/LDve0slLW l2nHlR9WQH5w5zRAln+xmWo/7DecG5Y/MI4gUVWp+G7Sq1bOCCZZv/+dm64IG/pzwIHk h16akKH4El8BZ3F5jrxzkxNmxXu4mAz63mTIdbayYKRy55xIaVvU22PkUCpTVjMv+XlR LZB8Fj+ObI6vW30VaMu8G3rzLqvHqqrA08TmOLVqEpRZo3m+pju8+DcFp3A+HikQZ495 7FbQ== 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=wCPeSzQmc1L7HaHEJ61DNj7iHXGUDqfpyn/35UhLrUU=; b=ZH5aW3+lBss+st5m9arXs2zHXuDVw0YSaKNlkoZCR+FdhH2BDw8MtsBfNveJrtDLEU b2ORpQMGdv4gkw57RFegEr2DLtHJ/kH+xWHJKn9uOWj47M7Dxbgc1kVbyuIT+YsLYr5z 0jZ7UsJxPIwffSztasmZ6W7wmM/eBrU1l3v1uIJvt8JBuxBDSX1LgaQZQAmsVQXyYxbi 6NB1CpAQ5LCUbM6qO1wo664MAh5C7FfJAYksAUMDlzmHzd46o3BGQHgJBRoFJJzZTTFu mk4VfMqYBRuWB1v5L41BR9z7Xk9FI18fSfR0kNEEzmtOIT2bomEcHIkrPCiOYth9w/il 9dFw== X-Gm-Message-State: APt69E3uAYXyZDDXVMQVcoy2fCu162NMGtbUj5Qv3udf7mAI2xaIQ1kG LX7+0WZZ6hwQ1aIEm2o3so4G85shU2JtneF527tDNkIvztI= X-Google-Smtp-Source: ADUXVKLQ7BMuKkVfmw7nWtMUTtuvkLQ0CdCsm85REvg9Vc6D1E9gAtfgxkP4A1HQwmAEOt5O/UKwl5YUhlj3+C95+aI= X-Received: by 2002:a02:4550:: with SMTP id y77-v6mr1271752jaa.12.1529901291579; Sun, 24 Jun 2018 21:34:51 -0700 (PDT) MIME-Version: 1.0 References: <152936189484.3120.16950226259858094588.idtracker@ietfa.amsl.com> <81cdccf7-b945-61f6-1545-fbf9d3ec6ff6@alvestrand.no> In-Reply-To: <81cdccf7-b945-61f6-1545-fbf9d3ec6ff6@alvestrand.no> From: Justin Uberti Date: Sun, 24 Jun 2018 21:34:39 -0700 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000071dbe056f6fe773" Archived-At: Subject: Re: [rtcweb] rtcweb - New Meeting Session Request for IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 04:34:55 -0000 --000000000000071dbe056f6fe773 Content-Type: text/plain; charset="UTF-8" Yep, on the official agenda : Real-Time Communication in WEB-browsers - Tuesday 1430 - 1530 On Sun, Jun 24, 2018 at 9:21 PM Harald Alvestrand wrote: > I assume this means that we've gotten a waiver for the deadline, and > that there will be no July 2-3 interim. > > I'd like to add Martin Thomson to the "people who must be present" list. > > Den 19. juni 2018 00:44, skrev IETF Meeting Session Request Tool: > > > > > > A new meeting session request has just been submitted by Liz Flynn, on > behalf of the rtcweb working group. > > > > > > --------------------------------------------------------- > > Working Group Name: Real-Time Communication in WEB-browsers > > Area Name: Applications and Real-Time Area > > Session Requester: Liz Flynn > > > > Number of Sessions: 1 > > Length of Session(s): 1 Hour > > Number of Attendees: 50 > > Conflicts to Avoid: > > > > > > > > > > > > People who must be present: > > Sean Turner > > Adam Roach > > Cullen Jennings > > Ted Hardie > > > > Resources Requested: > > > > Special Requests: > > > > --------------------------------------------------------- > > > > _______________________________________________ > > 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 > --000000000000071dbe056f6fe773 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Yep, on the official agenda:
    Real-Time = Communication in WEB-browsers - Tuesday 1430 - 1530

    On Sun, Jun 24, 2018 at 9:21 PM Harald = Alvestrand <harald@alvestrand.no= > wrote:
    I assume this means= that we've gotten a waiver for the deadline, and
    that there will be no July 2-3 interim.

    I'd like to add Martin Thomson to the "people who must be present&= quot; list.

    Den 19. juni 2018 00:44, skrev IETF Meeting Session Request Tool:
    >
    >
    > A new meeting session request has just been submitted by Liz Flynn, on= behalf of the rtcweb working group.
    >
    >
    > ---------------------------------------------------------
    > Working Group Name: Real-Time Communication in WEB-browsers
    > Area Name: Applications and Real-Time Area
    > Session Requester: Liz Flynn
    >
    > Number of Sessions: 1
    > Length of Session(s):=C2=A0 1 Hour
    > Number of Attendees: 50
    > Conflicts to Avoid:
    >
    >
    >
    >
    >
    > People who must be present:
    >=C2=A0 =C2=A0Sean Turner
    >=C2=A0 =C2=A0Adam Roach
    >=C2=A0 =C2=A0Cullen Jennings
    >=C2=A0 =C2=A0Ted Hardie
    >
    > Resources Requested:
    >
    > Special Requests:
    >=C2=A0 =C2=A0
    > ---------------------------------------------------------
    >
    > _______________________________________________
    > 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
    --000000000000071dbe056f6fe773-- From nobody Sun Jun 24 21:37:20 2018 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 B3D88127AC2 for ; Sun, 24 Jun 2018 21:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyvb6waqORKT for ; Sun, 24 Jun 2018 21:37:16 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24421277CC for ; Sun, 24 Jun 2018 21:37:15 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id d19-v6so13613979oti.8 for ; Sun, 24 Jun 2018 21:37:15 -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=qwtgoZApgIfk3WHG7eyohcbtTkxws8WklT1ylq71lOs=; b=m9c41NKOldd6HZH6/SOI+z5oDH1iTKDud8SiQXcyheaUkW0mL6IxLQdtiYqRVSQSEq j6gIw6qSGlnkp1Z51FZwIBLG8vDkagFRYoFz9F56V87U9K3tKhMT1J0/WxxGjFlEgFEU v6hnPVeu9zUNYINHbp8Cim44oqPCfi7xhpySRoDV/bCdzLl2CR3bH3H8D4S8yoMjWumA C3pOBnuG7S+rmd5fYYAC/hP9CJZr7OufUfUw6tTHXbnrYgH4DAMpkjqJfy3vHcAdWxdl HMkfYRFdYNA3TTt9GYK/VG/Jyn6SXRlL6p4JwU5q+H36z1GtleXvu/8otmUDAsGaFipT n7Og== 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=qwtgoZApgIfk3WHG7eyohcbtTkxws8WklT1ylq71lOs=; b=ISLt2nB6EGDghnR1y8x2YvMjIkKAEjBV+0o7eZBeUSiSpO8uNXPpe7ghuu86aMz7l8 FXUiI2RehG8l+GgZxIxdZqEIx2LvW8M5gfvdZyIP61DJs0Y+FjmwUn8jtqJcTs6SbTqp RSE1zuedc4sTh5ChRNRQyCpvmJs6byebNSFHNDhPxLrC1qxUxZYjmvsuCJrdj8kbnHww O8R+jOWI4Vvzibi4Nild4BjpjKJ6rxTWaGy8AbntW1tZQdXlB8u5zWX0qGo5Eo4NmH1D uo56nYf3Ds2Am4a9rKkqQQP+hRvKbdX6JNZZgN6y5gJ7BdHjeL9bsNAUdkq382Beg8PD HH1Q== X-Gm-Message-State: APt69E2ZxcaMi3zb7H01SNLAgz5FVzxca1yTzF/hs97ffSXJXtwzyBgj 82KZYVOEosC4W+N4073GXlgEwoCSsJlWnHouIIsX7Q== X-Google-Smtp-Source: ADUXVKIhkaAsjNgBjG5gKjt2VnIJ2HBHWf1viWZY589Z9IX0YXUqYEOHjkzxGjBUeY6mqthoiozw/1rD1QlOXVAJBRE= X-Received: by 2002:a9d:e2a:: with SMTP id c39-v6mr6767273otc.241.1529901435137; Sun, 24 Jun 2018 21:37:15 -0700 (PDT) MIME-Version: 1.0 References: <152936189484.3120.16950226259858094588.idtracker@ietfa.amsl.com> <81cdccf7-b945-61f6-1545-fbf9d3ec6ff6@alvestrand.no> In-Reply-To: <81cdccf7-b945-61f6-1545-fbf9d3ec6ff6@alvestrand.no> From: Martin Thomson Date: Mon, 25 Jun 2018 14:37:04 +1000 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [rtcweb] rtcweb - New Meeting Session Request for IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 04:37:19 -0000 It's OK, I'll be there. No conflicts on that slot (yet). On Mon, Jun 25, 2018 at 2:21 PM Harald Alvestrand wrote: > > I assume this means that we've gotten a waiver for the deadline, and > that there will be no July 2-3 interim. > > I'd like to add Martin Thomson to the "people who must be present" list. > > Den 19. juni 2018 00:44, skrev IETF Meeting Session Request Tool: > > > > > > A new meeting session request has just been submitted by Liz Flynn, on behalf of the rtcweb working group. > > > > > > --------------------------------------------------------- > > Working Group Name: Real-Time Communication in WEB-browsers > > Area Name: Applications and Real-Time Area > > Session Requester: Liz Flynn > > > > Number of Sessions: 1 > > Length of Session(s): 1 Hour > > Number of Attendees: 50 > > Conflicts to Avoid: > > > > > > > > > > > > People who must be present: > > Sean Turner > > Adam Roach > > Cullen Jennings > > Ted Hardie > > > > Resources Requested: > > > > Special Requests: > > > > --------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jun 25 05:27:04 2018 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 7B65C130DD1 for ; Mon, 25 Jun 2018 05:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gL2BY9Hy1hlw for ; Mon, 25 Jun 2018 05:27:00 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FCA12F1A2 for ; Mon, 25 Jun 2018 05:27:00 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id b129-v6so7328570qke.7 for ; Mon, 25 Jun 2018 05:27:00 -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=oz7OOUj0ek6pj0+6wOnn+fqKfSB/2ubTsrcfLQkAJTY=; b=VUIZvqaFBhDLWFCxPOVSA6P/QS+BEi5UBszTSDvkqBgJslpa35h/mi4WqPBpNIwYLr JVwVlHTpVdPthz2DxQ0Eozbtp8AiRnhQ6hgjJTQu5S6Db8tZ1paeTgNXXPUpf2F393pH A5E7HFXm92KnyH8AeRnpg+MT8lz5cBJh0PTO4= 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=oz7OOUj0ek6pj0+6wOnn+fqKfSB/2ubTsrcfLQkAJTY=; b=SA6fQA/T9uvySrkTSDycf31AcQbkqIQ7buDd96YMNlON3JTH9YFyoaYAdNXVdlPCKJ 8gbgBXZBIS1BQmUDabTa03/xvvO3cafo8PncKIz4I/MHPveK2w570tI3nEBbb2XGnV4F 9k1ZhMOm7a3bLlLKIEUGdzhOqu6sbCgHZYGR1o48yy6OJtacUAXMKV822jDien3d5pkG CKKWGcoGF5EHs8nTP+CN45PwvR/0PcqlGZXge/lwCZBWYKh4w+BgS4V/LVSm/+yZ/1oR cqpXJ0cwLQrbO3qR4iQwd08TpfaH6F8rcMjyTu7OIABfsvfQpvAatg6yKK5Qstza14Hw d9aw== X-Gm-Message-State: APt69E1JqPQ9RCHWPPcImPMvbKQwp+cEDj2o9r1oY8F2evIwknp8NhUx Xz0PgfxbDhkGNB7BYtw0QRIlUAZKET0= X-Google-Smtp-Source: ADUXVKKrm59pC7eZSlYCH7JFhRutJn7oNtoIUTPO5t32EiB86OejsXXV2madikUkbMtLsxZCCD0Wfw== X-Received: by 2002:a37:4a09:: with SMTP id x9-v6mr10329029qka.5.1529929619252; Mon, 25 Jun 2018 05:26:59 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id l73-v6sm20849486qkl.78.2018.06.25.05.26.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 05:26:57 -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 11.4 \(3445.8.2\)) Date: Mon, 25 Jun 2018 08:26:56 -0400 References: <152936189484.3120.16950226259858094588.idtracker@ietfa.amsl.com> <81cdccf7-b945-61f6-1545-fbf9d3ec6ff6@alvestrand.no> To: RTCWeb IETF In-Reply-To: Message-Id: <5E8D8FD6-A3F2-456F-8C39-72E0555952B0@sn3rd.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] rtcweb - New Meeting Session Request for IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 25 Jun 2018 12:27:03 -0000 Yeah Adam pulled out his magic pixie dust. And, we were lucky to be = able share a session slot. Here is the meeting info: Date: 20180717 Location: Centre Ville Time: 14:30-15:30 Note that we are sharing the slot with regext, which will meet from = 13:30-14:30, so don=E2=80=99t freak out if there are people you might = not recognize at 1330 :) We=E2=80=99ve got two agenda items are to address WGLC comments: - IP Handling: mDNS names for host candidates - RTCweb Security Architecture: Identity Attribute (PR to be produced) spt > On Jun 25, 2018, at 00:37, Martin Thomson = wrote: >=20 > It's OK, I'll be there. No conflicts on that slot (yet). > On Mon, Jun 25, 2018 at 2:21 PM Harald Alvestrand = wrote: >>=20 >> I assume this means that we've gotten a waiver for the deadline, and >> that there will be no July 2-3 interim. >>=20 >> I'd like to add Martin Thomson to the "people who must be present" = list. >>=20 >> Den 19. juni 2018 00:44, skrev IETF Meeting Session Request Tool: >>>=20 >>>=20 >>> A new meeting session request has just been submitted by Liz Flynn, = on behalf of the rtcweb working group. >>>=20 >>>=20 >>> --------------------------------------------------------- >>> Working Group Name: Real-Time Communication in WEB-browsers >>> Area Name: Applications and Real-Time Area >>> Session Requester: Liz Flynn >>>=20 >>> Number of Sessions: 1 >>> Length of Session(s): 1 Hour >>> Number of Attendees: 50 >>> Conflicts to Avoid: >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> People who must be present: >>> Sean Turner >>> Adam Roach >>> Cullen Jennings >>> Ted Hardie >>>=20 >>> Resources Requested: >>>=20 >>> Special Requests: >>>=20 >>> --------------------------------------------------------- >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 28 04:30:17 2018 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 8831B130F6F for ; Thu, 28 Jun 2018 04:30:14 -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] 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 Rf86hnA0kzVK for ; Thu, 28 Jun 2018 04:30:11 -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 873BA130F69 for ; Thu, 28 Jun 2018 04:30:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B93A17C0699 for ; Thu, 28 Jun 2018 13:30:07 +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 N9RZETHB_M7e for ; Thu, 28 Jun 2018 13:30:06 +0200 (CEST) Received: from [192.168.3.218] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id DBC717C038A for ; Thu, 28 Jun 2018 13:30:06 +0200 (CEST) To: "rtcweb@ietf.org" 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: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> Date: Thu, 28 Jun 2018 13:30:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 11:30:15 -0000 In considering the datachannel API, we encountered one interesting race condition: A: A: CreateOffer(), SetLocalDescription(), send SDP B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP B: Configure an externally defined data channel, with #3249 B: Send a message on #3249 A: SetRemoteDescription A: Wait a while (THE PAUSE) A: Configure #3249 Now, if a message comes in to A on #3249 during THE PAUSE, what is the implementation to do? I studied draft-ietf-rtcweb-data-channel-13 for at least 3 minutes before concluding that it doesn't say. What I'd PREFER it to say is "these messages will be dropped on the floor. Tough luck." I would prefer it to say so explicitly. Can we do this? -- Surveillance is pervasive. Go Dark. From nobody Thu Jun 28 05:51:34 2018 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 C51FB130F99 for ; Thu, 28 Jun 2018 05:51:32 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 H7A-0W6BT9zF for ; Thu, 28 Jun 2018 05:51:28 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88950130F88 for ; Thu, 28 Jun 2018 05:51:28 -0700 (PDT) Received: from [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d] (p200300CD6F1A97003C96AA9C3349E44D.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 6493D721E2822; Thu, 28 Jun 2018 14:51:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Michael Tuexen In-Reply-To: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> Date: Thu, 28 Jun 2018 14:51:24 +0200 Cc: "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 12:51:33 -0000 > On 28. Jun 2018, at 13:30, Harald Alvestrand = wrote: >=20 > In considering the datachannel API, we encountered one interesting = race > condition: >=20 > A: >=20 > A: CreateOffer(), SetLocalDescription(), send SDP >=20 > B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP >=20 > B: Configure an externally defined data channel, with #3249 >=20 > B: Send a message on #3249 >=20 > A: SetRemoteDescription >=20 > A: Wait a while (THE PAUSE) >=20 > A: Configure #3249 >=20 > Now, if a message comes in to A on #3249 during THE PAUSE, what is the > implementation to do? Isn't that some kind or error condition? If that it true, one could apply: If a message with an unsupported PPID is received or some error condition related to the received message is detected by the receiver (for example, illegal ordering), the receiver SHOULD close the corresponding data channel. This implies in particular that extensions using additional PPIDs can't be used without prior negotiation. > I studied draft-ietf-rtcweb-data-channel-13 for at least 3 minutes > before concluding that it doesn't say. >=20 > What I'd PREFER it to say is "these messages will be dropped on the > floor. Tough luck." >=20 > I would prefer it to say so explicitly. >=20 > Can we do this? Not sure about the procedural thing... That ID is stuck in the RFC = editor queue for a long time... Best regards Michael >=20 > --=20 > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jun 28 07:22:20 2018 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 1805C130E1C for ; Thu, 28 Jun 2018 07:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uWccfEQxiELI for ; Thu, 28 Jun 2018 07:22: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 DAF99130DC3 for ; Thu, 28 Jun 2018 07:22:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 427D77C06FD; Thu, 28 Jun 2018 16:22:13 +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 PRecLwgh1OYP; Thu, 28 Jun 2018 16:22:12 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id D7B607C06F6; Thu, 28 Jun 2018 16:22:11 +0200 (CEST) To: Michael Tuexen Cc: "rtcweb@ietf.org" References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> 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: <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no> Date: Thu, 28 Jun 2018 16:22:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 14:22:19 -0000 Den 28. juni 2018 14:51, skrev Michael Tuexen: >> On 28. Jun 2018, at 13:30, Harald Alvestrand wrote: >> >> In considering the datachannel API, we encountered one interesting race >> condition: >> >> A: >> >> A: CreateOffer(), SetLocalDescription(), send SDP >> >> B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP >> >> B: Configure an externally defined data channel, with #3249 >> >> B: Send a message on #3249 >> >> A: SetRemoteDescription >> >> A: Wait a while (THE PAUSE) >> >> A: Configure #3249 >> >> Now, if a message comes in to A on #3249 during THE PAUSE, what is the >> implementation to do? > Isn't that some kind or error condition? > > If that it true, one could apply: > > If a message with an unsupported PPID is received or some error > condition related to the received message is detected by the receiver > (for example, illegal ordering), the receiver SHOULD close the > corresponding data channel. This implies in particular that > extensions using additional PPIDs can't be used without prior > negotiation. The receiver can't close the datachannel if the datachannel doesn't exist yet, so this doesn't work for that case. > >> I studied draft-ietf-rtcweb-data-channel-13 for at least 3 minutes >> before concluding that it doesn't say. >> >> What I'd PREFER it to say is "these messages will be dropped on the >> floor. Tough luck." >> >> I would prefer it to say so explicitly. >> >> Can we do this? > Not sure about the procedural thing... That ID is stuck in the RFC editor queue > for a long time... > > Best regards > Michael >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Jun 28 07:35:22 2018 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 472C0130E8C for ; Thu, 28 Jun 2018 07:35:21 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 S8N743MVuyDq for ; Thu, 28 Jun 2018 07:35:19 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17603130E21 for ; Thu, 28 Jun 2018 07:35:19 -0700 (PDT) Received: from [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d] (p200300CD6F1A97003C96AA9C3349E44D.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 65216721E2822; Thu, 28 Jun 2018 16:35:16 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Michael Tuexen In-Reply-To: <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no> Date: Thu, 28 Jun 2018 16:35:15 +0200 Cc: "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <87B266DF-5AE5-4B22-B21F-B2FC37EB3FF2@lurchi.franken.de> References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 14:35:22 -0000 > On 28. Jun 2018, at 16:22, Harald Alvestrand = wrote: >=20 > Den 28. juni 2018 14:51, skrev Michael Tuexen: >>> On 28. Jun 2018, at 13:30, Harald Alvestrand = wrote: >>>=20 >>> In considering the datachannel API, we encountered one interesting = race >>> condition: >>>=20 >>> A: >>>=20 >>> A: CreateOffer(), SetLocalDescription(), send SDP >>>=20 >>> B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP >>>=20 >>> B: Configure an externally defined data channel, with #3249 >>>=20 >>> B: Send a message on #3249 >>>=20 >>> A: SetRemoteDescription >>>=20 >>> A: Wait a while (THE PAUSE) >>>=20 >>> A: Configure #3249 >>>=20 >>> Now, if a message comes in to A on #3249 during THE PAUSE, what is = the >>> implementation to do? >> Isn't that some kind or error condition? >>=20 >> If that it true, one could apply: >>=20 >> If a message with an unsupported PPID is received or some error >> condition related to the received message is detected by the = receiver >> (for example, illegal ordering), the receiver SHOULD close the >> corresponding data channel. This implies in particular that >> extensions using additional PPIDs can't be used without prior >> negotiation. >=20 >=20 > The receiver can't close the datachannel if the datachannel doesn't > exist yet, so this doesn't work for that case. I was assuming that the SCTP receives a user message on a stream. When this message is delivered to its upper layer, doesn't this layer know that there is no data channel? I would assume that this layer triggers the stream reset procedure. I'm not saying that the user (for example via a JS API) is involved... I'm more talking about implementing this iside the browser...=20 Best regards Michael >=20 >>=20 >>> I studied draft-ietf-rtcweb-data-channel-13 for at least 3 minutes >>> before concluding that it doesn't say. >>>=20 >>> What I'd PREFER it to say is "these messages will be dropped on the >>> floor. Tough luck." >>>=20 >>> I would prefer it to say so explicitly. >>>=20 >>> Can we do this? >> Not sure about the procedural thing... That ID is stuck in the RFC = editor queue >> for a long time... >>=20 >> Best regards >> Michael >>>=20 >>> --=20 >>> Surveillance is pervasive. Go Dark. >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 From nobody Thu Jun 28 08:01:06 2018 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 16BC3130DCC for ; Thu, 28 Jun 2018 08:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5ur2ccEjO0Hm for ; Thu, 28 Jun 2018 08:01:03 -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 0104A130DC7 for ; Thu, 28 Jun 2018 08:01:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6626C7C06FD; Thu, 28 Jun 2018 17:01:01 +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 8gvARhiqf0a2; Thu, 28 Jun 2018 17:01:00 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 512E57C06F6; Thu, 28 Jun 2018 17:01:00 +0200 (CEST) To: Michael Tuexen Cc: "rtcweb@ietf.org" References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no> <87B266DF-5AE5-4B22-B21F-B2FC37EB3FF2@lurchi.franken.de> 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: <596309ba-2aeb-7699-6bc6-ef7e461b5295@alvestrand.no> Date: Thu, 28 Jun 2018 17:01:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87B266DF-5AE5-4B22-B21F-B2FC37EB3FF2@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 15:01:05 -0000 Den 28. juni 2018 16:35, skrev Michael Tuexen: >> On 28. Jun 2018, at 16:22, Harald Alvestrand wrote: >> >> Den 28. juni 2018 14:51, skrev Michael Tuexen: >>>> On 28. Jun 2018, at 13:30, Harald Alvestrand wrote: >>>> >>>> In considering the datachannel API, we encountered one interesting race >>>> condition: >>>> >>>> A: >>>> >>>> A: CreateOffer(), SetLocalDescription(), send SDP >>>> >>>> B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP >>>> >>>> B: Configure an externally defined data channel, with #3249 >>>> >>>> B: Send a message on #3249 >>>> >>>> A: SetRemoteDescription >>>> >>>> A: Wait a while (THE PAUSE) >>>> >>>> A: Configure #3249 >>>> >>>> Now, if a message comes in to A on #3249 during THE PAUSE, what is the >>>> implementation to do? >>> Isn't that some kind or error condition? >>> >>> If that it true, one could apply: >>> >>> If a message with an unsupported PPID is received or some error >>> condition related to the received message is detected by the receiver >>> (for example, illegal ordering), the receiver SHOULD close the >>> corresponding data channel. This implies in particular that >>> extensions using additional PPIDs can't be used without prior >>> negotiation. >> >> >> The receiver can't close the datachannel if the datachannel doesn't >> exist yet, so this doesn't work for that case. > I was assuming that the SCTP receives a user message on a stream. When > this message is delivered to its upper layer, doesn't this layer know > that there is no data channel? I would assume that this layer triggers > the stream reset procedure. I'm not saying that the user (for example > via a JS API) is involved... I'm more talking about implementing this > iside the browser.. Exactly, it could close the stream, but it can't close the data channel since it doesn't exist. I think closing the stream would be a mistake, since that would make the outcome about whether you end up with the datachannel or not racy; discarding data will give you a working datachannel once A gets around to configuring it. From nobody Thu Jun 28 08:19:08 2018 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 C480D130DE1 for ; Thu, 28 Jun 2018 08:19:06 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 ZzB7LhXeNKyi for ; Thu, 28 Jun 2018 08:19:05 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C1D130DD5 for ; Thu, 28 Jun 2018 08:19:04 -0700 (PDT) Received: from [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d] (p200300CD6F1A97003C96AA9C3349E44D.dip0.t-ipconnect.de [IPv6:2003:cd:6f1a:9700:3c96:aa9c:3349:e44d]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 72DA0721E2822; Thu, 28 Jun 2018 17:19:02 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Michael Tuexen In-Reply-To: <596309ba-2aeb-7699-6bc6-ef7e461b5295@alvestrand.no> Date: Thu, 28 Jun 2018 17:19:01 +0200 Cc: "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2C11444C-6CC8-45E7-B699-02738D845BF0@lurchi.franken.de> References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no> <87B266DF-5AE5-4B22-B21F-B2FC37EB3FF2@lurchi.franken.de> <596309ba-2aeb-7699-6bc6-ef7e461b5295@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 15:19:07 -0000 > On 28. Jun 2018, at 17:01, Harald Alvestrand = wrote: >=20 > Den 28. juni 2018 16:35, skrev Michael Tuexen: >>> On 28. Jun 2018, at 16:22, Harald Alvestrand = wrote: >>>=20 >>> Den 28. juni 2018 14:51, skrev Michael Tuexen: >>>>> On 28. Jun 2018, at 13:30, Harald Alvestrand = wrote: >>>>>=20 >>>>> In considering the datachannel API, we encountered one interesting = race >>>>> condition: >>>>>=20 >>>>> A: >>>>>=20 >>>>> A: CreateOffer(), SetLocalDescription(), send SDP >>>>>=20 >>>>> B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send = SDP >>>>>=20 >>>>> B: Configure an externally defined data channel, with #3249 >>>>>=20 >>>>> B: Send a message on #3249 >>>>>=20 >>>>> A: SetRemoteDescription >>>>>=20 >>>>> A: Wait a while (THE PAUSE) >>>>>=20 >>>>> A: Configure #3249 >>>>>=20 >>>>> Now, if a message comes in to A on #3249 during THE PAUSE, what is = the >>>>> implementation to do? >>>> Isn't that some kind or error condition? >>>>=20 >>>> If that it true, one could apply: >>>>=20 >>>> If a message with an unsupported PPID is received or some error >>>> condition related to the received message is detected by the = receiver >>>> (for example, illegal ordering), the receiver SHOULD close the >>>> corresponding data channel. This implies in particular that >>>> extensions using additional PPIDs can't be used without prior >>>> negotiation. >>>=20 >>>=20 >>> The receiver can't close the datachannel if the datachannel doesn't >>> exist yet, so this doesn't work for that case. >> I was assuming that the SCTP receives a user message on a stream. = When >> this message is delivered to its upper layer, doesn't this layer know >> that there is no data channel? I would assume that this layer = triggers >> the stream reset procedure. I'm not saying that the user (for example >> via a JS API) is involved... I'm more talking about implementing this >> iside the browser.. >=20 >=20 > Exactly, it could close the stream, but it can't close the data = channel > since it doesn't exist. Well, I can run the procedure and the peer will get an indication that something isn't working well. >=20 > I think closing the stream would be a mistake, since that would make = the > outcome about whether you end up with the datachannel or not racy; > discarding data will give you a working datachannel once A gets around > to configuring it. But if the user configures a reliable data channel, the user does not get the service that was required... Best regards Michael >=20 From nobody Thu Jun 28 10:38:36 2018 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 271C1130DFC for ; Thu, 28 Jun 2018 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 mGTw_VpKS5oX for ; Thu, 28 Jun 2018 10:38:31 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DE9130DEE for ; Thu, 28 Jun 2018 10:38:31 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id j11-v6so3779525vke.8 for ; Thu, 28 Jun 2018 10:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uv18pqbPpwh3LFoGRZXcNav0GY40uYL/TU5Hp4hBFqI=; b=XkHb8nwWtM8TmywCATUEI0pkfM0MOGlIWDRTjpFAoRs+Un1UlP7I2g/Vy48mjJHU10 8hU9WswbkFhe4NMj2arCrvTaUVkrG/b92jnPJdT0K/Gin+1swIUo+VTO03vrEZoKhNJ7 bvngYxP+CVPQNqR/dNTzfeQsH1B4R3DoVFUOnFufsiPs7XAnhotm5Z2V8eLq3bSRd1+M mAA4t8r1V2et9yiLrIkxie0P05XULT2hKF2MTTrupz53AeN/2qYb1/agDwmSaIgqfBAH cS8slfKMPLoS6PAT+nCUSmfpAQ35MhuLpHDRUecTD4HMonMXwW9WOz1YaWFzC971QIf/ iGdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uv18pqbPpwh3LFoGRZXcNav0GY40uYL/TU5Hp4hBFqI=; b=gd6LjYu+fTxYrfc+WhQL4/OsCT2I36I5B3/FWSa/lEFmQS7mCrCovMLOJdOHyZEHbB nbhuFNRVs6NTaTY6LkJH44f3+jdcPb8xP9/CAYXORA8d/Gtjegea9v5xiOg9K41iKX+q bSicoKQoZdZPN34OOl57fObrT0TekgyQrD3kWs4HkUeyfJ1uFNm6NbkI/4vhQ1/J8l0j M7BlnqT7eReQ8kztACUaRwWPapnz9EsXbwI6S7vqkCN8Diej/3C62GEfnzunQJGaSxUu AZCDmu51srQdkTTgbPqDz/sYM3QXhfTW2qkSFX03Lr/J8QulDydgliZanJzcTvZILiSW 4TQw== X-Gm-Message-State: APt69E1t1uip60OouaXWohlGly1gIQ81YnKYk3J9CVtqLN6hA1HbLiw2 dtawECOSWALHd1PK3/Y3IxHrjA/uty3vRrcSYRafICw+crU= X-Google-Smtp-Source: AAOMgpf3zHuZSSQ8zdyp+AJVBgsZ4Cj/xpvDPiqHpLklaRf0oidvye+9PRCOu9rMtk1Ro70Y4ZG0v3BjTnyVhi4ozck= X-Received: by 2002:a1f:874a:: with SMTP id j71-v6mr6832576vkd.57.1530207510277; Thu, 28 Jun 2018 10:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 10:38:29 -0700 (PDT) In-Reply-To: <2C11444C-6CC8-45E7-B699-02738D845BF0@lurchi.franken.de> References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no> <87B266DF-5AE5-4B22-B21F-B2FC37EB3FF2@lurchi.franken.de> <596309ba-2aeb-7699-6bc6-ef7e461b5295@alvestrand.no> <2C11444C-6CC8-45E7-B699-02738D845BF0@lurchi.franken.de> From: Taylor Brandstetter Date: Thu, 28 Jun 2018 10:38:29 -0700 Message-ID: To: Michael Tuexen Cc: Harald Alvestrand , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="00000000000015d684056fb733ff" Archived-At: Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 28 Jun 2018 17:38:34 -0000 --00000000000015d684056fb733ff Content-Type: text/plain; charset="UTF-8" Note that I started a thread about this last month: https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqifrs_ius On Thu, Jun 28, 2018 at 8:19 AM, Michael Tuexen < michael.tuexen@lurchi.franken.de> wrote: > > > > On 28. Jun 2018, at 17:01, Harald Alvestrand > wrote: > > > > Den 28. juni 2018 16:35, skrev Michael Tuexen: > >>> On 28. Jun 2018, at 16:22, Harald Alvestrand > wrote: > >>> > >>> Den 28. juni 2018 14:51, skrev Michael Tuexen: > >>>>> On 28. Jun 2018, at 13:30, Harald Alvestrand > wrote: > >>>>> > >>>>> In considering the datachannel API, we encountered one interesting > race > >>>>> condition: > >>>>> > >>>>> A: > >>>>> > >>>>> A: CreateOffer(), SetLocalDescription(), send SDP > >>>>> > >>>>> B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP > >>>>> > >>>>> B: Configure an externally defined data channel, with #3249 > >>>>> > >>>>> B: Send a message on #3249 > >>>>> > >>>>> A: SetRemoteDescription > >>>>> > >>>>> A: Wait a while (THE PAUSE) > >>>>> > >>>>> A: Configure #3249 > >>>>> > >>>>> Now, if a message comes in to A on #3249 during THE PAUSE, what is > the > >>>>> implementation to do? > >>>> Isn't that some kind or error condition? > >>>> > >>>> If that it true, one could apply: > >>>> > >>>> If a message with an unsupported PPID is received or some error > >>>> condition related to the received message is detected by the receiver > >>>> (for example, illegal ordering), the receiver SHOULD close the > >>>> corresponding data channel. This implies in particular that > >>>> extensions using additional PPIDs can't be used without prior > >>>> negotiation. > >>> > >>> > >>> The receiver can't close the datachannel if the datachannel doesn't > >>> exist yet, so this doesn't work for that case. > >> I was assuming that the SCTP receives a user message on a stream. When > >> this message is delivered to its upper layer, doesn't this layer know > >> that there is no data channel? I would assume that this layer triggers > >> the stream reset procedure. I'm not saying that the user (for example > >> via a JS API) is involved... I'm more talking about implementing this > >> iside the browser.. > > > > > > Exactly, it could close the stream, but it can't close the data channel > > since it doesn't exist. > Well, I can run the procedure and the peer will get an indication that > something isn't working well. > > > > I think closing the stream would be a mistake, since that would make the > > outcome about whether you end up with the datachannel or not racy; > > discarding data will give you a working datachannel once A gets around > > to configuring it. > But if the user configures a reliable data channel, the user does not > get the service that was required... > > Best regards > Michael > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000015d684056fb733ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Note that I started a thread about this last month:=C2=A0<= a href=3D"https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqi= frs_ius">https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqif= rs_ius

    O= n Thu, Jun 28, 2018 at 8:19 AM, Michael Tuexen <michael.tue= xen@lurchi.franken.de> wrote:


    > On 28. Jun 2018, at 17:01, Harald Alvestrand <harald@alvestrand.no> wrote:
    >
    > Den 28. juni 2018 16:35, skrev Michael Tuexen:
    >>> On 28. Jun 2018, at 16:22, Harald Alvestrand <harald@alvestrand.no> wrote:
    >>>
    >>> Den 28. juni 2018 14:51, skrev Michael Tuexen:
    >>>>> On 28. Jun 2018, at 13:30, Harald Alvestrand <harald@alvestrand.no> wrote:
    >>>>>
    >>>>> In considering the datachannel API, we encountered one= interesting race
    >>>>> condition:
    >>>>>
    >>>>> A: <configure for datachannel>
    >>>>>
    >>>>> A: CreateOffer(), SetLocalDescription(), send SDP
    >>>>>
    >>>>> B: SetRemoteDescription, CreateAnswer, SetLocalDescrip= tion, send SDP
    >>>>>
    >>>>> B: Configure an externally defined data channel, with = #3249
    >>>>>
    >>>>> B: Send a message on #3249
    >>>>>
    >>>>> A: SetRemoteDescription
    >>>>>
    >>>>> A: Wait a while (THE PAUSE)
    >>>>>
    >>>>> A: Configure #3249
    >>>>>
    >>>>> Now, if a message comes in to A on #3249 during THE PA= USE, what is the
    >>>>> implementation to do?
    >>>> Isn't that some kind or error condition?
    >>>>
    >>>> If that it true, one could apply:
    >>>>
    >>>>=C2=A0 If a message with an unsupported PPID is received or= some error
    >>>>=C2=A0 condition related to the received message is detecte= d by the receiver
    >>>>=C2=A0 (for example, illegal ordering), the receiver SHOULD= close the
    >>>>=C2=A0 corresponding data channel.=C2=A0 This implies in pa= rticular that
    >>>>=C2=A0 extensions using additional PPIDs can't be used = without prior
    >>>>=C2=A0 negotiation.
    >>>
    >>>
    >>> The receiver can't close the datachannel if the datachanne= l doesn't
    >>> exist yet, so this doesn't work for that case.
    >> I was assuming that the SCTP receives a user message on a stream. = When
    >> this message is delivered to its upper layer, doesn't this lay= er know
    >> that there is no data channel? I would assume that this layer trig= gers
    >> the stream reset procedure. I'm not saying that the user (for = example
    >> via a JS API) is involved... I'm more talking about implementi= ng this
    >> iside the browser..
    >
    >
    > Exactly, it could close the stream, but it can't close the data ch= annel
    > since it doesn't exist.
    Well, I can run the procedure and the peer will get an indicati= on that
    something isn't working well.
    >
    > I think closing the stream would be a mistake, since that would make t= he
    > outcome about whether you end up with the datachannel or not racy;
    > discarding data will give you a working datachannel once A gets around=
    > to configuring it.
    But if the user configures a reliable data channel, the user does no= t
    get the service that was required...

    Best regards
    Michael
    >

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

    --00000000000015d684056fb733ff-- From nobody Thu Jun 28 20:57:45 2018 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 EB969130E61 for ; Thu, 28 Jun 2018 20:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 LdhoxEV6t1dt for ; Thu, 28 Jun 2018 20:57:36 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2D0130E53 for ; Thu, 28 Jun 2018 20:57:36 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id a195-v6so996708itd.3 for ; Thu, 28 Jun 2018 20:57:36 -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=YBTiXKsL9dXMrF/viVPjnMD01kxceMkHr+xDZ7pb0L8=; b=U7feuGtuzcdr+TRqkJrWCcTYLFVCZADPVV7MS5/F9wSJwFdQqaLH9KQEQ04lpOEKOx mu8GnJZFSpNjADtdGlhteyEVhNv4DZYiq8fqueHuT9ADnUwjt25vLqoCrVpKVH+2c4IX MkU6Hx4GIgFn3CgwhShlQ6eNsvFtWJRJ3cIpJk5nopYbVOJ2nWuezm2g6KE6P0VY9bj5 IAdD1RDGKcJ1DOB5pHzJ1mtb/26VZeEbxCMu1+1iNRqjj2fdQlg6KDcdg95qNPzEL2+n l9SD9vilZMrYIXcwtWdthQcbEqYQ1gvi+gopdK2g7KOCNVfmXzX94TM16UE00jfWo8TS PFjg== 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=YBTiXKsL9dXMrF/viVPjnMD01kxceMkHr+xDZ7pb0L8=; b=eQHu+vRX06ia93zs+q0bSkcDQW45iuA8wEa13BzFhfc3nHSfd0Mf1vYFKFj2ElYFFf Cou5ha49lgUJynZUon22g7gEKNutZp8iOTZ3f9LAatx+/FFXiTux3AV9upXlVn0MPemp 57ZPNGEMdtySX4PCxsC24yrkRXFQKJveSjH1z/1EOmFwPqUdqT+SV5E/UozJ1TWe4m8n HsUcmAuGF+RkxdhCbjmzi5MykKDDUpiDnxs/cGWLS7SW7DjewQ1dEL66G5PBfuhFI9Um YrcdNt3MAOoe57V3IPMGpQKgcxJBhrD3ThRTqftc+M33Lih1luIHwuLdVG+yGd4IHeBJ kQ0g== X-Gm-Message-State: APt69E0K2Cv6h25ebOmM+BBy5NNjhubJE4/kz4Llgi4WDliqO4bxzxsT lx54+BTMhYWTZUuek/3oSf3qZ07n8YEAu6a/HWffFD60 X-Google-Smtp-Source: AAOMgpe9GzZAInaAHtOj3VgbNvdJA3oMAej+VqEehiKxToLevNqB//YZz3RmMeQJa7l31fi+8NyhCcfNRksBwAdxITY= X-Received: by 2002:a02:9c33:: with SMTP id q48-v6mr9562751jak.103.1530244650306; Thu, 28 Jun 2018 20:57:30 -0700 (PDT) MIME-Version: 1.0 References: <5e7eebae-a08e-8c21-5c22-3b26b7385a7a@alvestrand.no> <4A875994-54C3-422B-8E6F-9284D273BE0E@lurchi.franken.de> <85a4defc-e432-eed3-f5fb-e1d0df2bf326@alvestrand.no> <87B266DF-5AE5-4B22-B21F-B2FC37EB3FF2@lurchi.franken.de> <596309ba-2aeb-7699-6bc6-ef7e461b5295@alvestrand.no> <2C11444C-6CC8-45E7-B699-02738D845BF0@lurchi.franken.de> In-Reply-To: From: Justin Uberti Date: Thu, 28 Jun 2018 20:57:18 -0700 Message-ID: To: deadbeef=40google.com@dmarc.ietf.org Cc: =?UTF-8?Q?Michael_T=C3=BCxen?= , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000cd9ded056fbfd814" Archived-At: Subject: Re: [rtcweb] Data channel: Handling of packets on unknown channels X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 03:57:44 -0000 --000000000000cd9ded056fbfd814 Content-Type: text/plain; charset="UTF-8" Taylor is correct. In that thread, we agreed that the PeerConnection doc should say "tough luck". On Thu, Jun 28, 2018 at 10:38 AM Taylor Brandstetter wrote: > Note that I started a thread about this last month: > https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqifrs_ius > > On Thu, Jun 28, 2018 at 8:19 AM, Michael Tuexen < > michael.tuexen@lurchi.franken.de> wrote: > >> >> >> > On 28. Jun 2018, at 17:01, Harald Alvestrand >> wrote: >> > >> > Den 28. juni 2018 16:35, skrev Michael Tuexen: >> >>> On 28. Jun 2018, at 16:22, Harald Alvestrand >> wrote: >> >>> >> >>> Den 28. juni 2018 14:51, skrev Michael Tuexen: >> >>>>> On 28. Jun 2018, at 13:30, Harald Alvestrand >> wrote: >> >>>>> >> >>>>> In considering the datachannel API, we encountered one interesting >> race >> >>>>> condition: >> >>>>> >> >>>>> A: >> >>>>> >> >>>>> A: CreateOffer(), SetLocalDescription(), send SDP >> >>>>> >> >>>>> B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP >> >>>>> >> >>>>> B: Configure an externally defined data channel, with #3249 >> >>>>> >> >>>>> B: Send a message on #3249 >> >>>>> >> >>>>> A: SetRemoteDescription >> >>>>> >> >>>>> A: Wait a while (THE PAUSE) >> >>>>> >> >>>>> A: Configure #3249 >> >>>>> >> >>>>> Now, if a message comes in to A on #3249 during THE PAUSE, what is >> the >> >>>>> implementation to do? >> >>>> Isn't that some kind or error condition? >> >>>> >> >>>> If that it true, one could apply: >> >>>> >> >>>> If a message with an unsupported PPID is received or some error >> >>>> condition related to the received message is detected by the >> receiver >> >>>> (for example, illegal ordering), the receiver SHOULD close the >> >>>> corresponding data channel. This implies in particular that >> >>>> extensions using additional PPIDs can't be used without prior >> >>>> negotiation. >> >>> >> >>> >> >>> The receiver can't close the datachannel if the datachannel doesn't >> >>> exist yet, so this doesn't work for that case. >> >> I was assuming that the SCTP receives a user message on a stream. When >> >> this message is delivered to its upper layer, doesn't this layer know >> >> that there is no data channel? I would assume that this layer triggers >> >> the stream reset procedure. I'm not saying that the user (for example >> >> via a JS API) is involved... I'm more talking about implementing this >> >> iside the browser.. >> > >> > >> > Exactly, it could close the stream, but it can't close the data channel >> > since it doesn't exist. >> Well, I can run the procedure and the peer will get an indication that >> something isn't working well. >> > >> > I think closing the stream would be a mistake, since that would make the >> > outcome about whether you end up with the datachannel or not racy; >> > discarding data will give you a working datachannel once A gets around >> > to configuring it. >> But if the user configures a reliable data channel, the user does not >> get the service that was required... >> >> Best regards >> Michael >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000cd9ded056fbfd814 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Taylor is correct. In that thread, we agreed that the Peer= Connection doc should say "tough luck".

    On Thu, Jun 28, 2018 at 10:38 AM Taylor Brandst= etter <deadbeef=3D40google.com@dmarc.ietf.org> wrote:
    Note that I started a thread about thi= s last month:=C2=A0https://mailarchive.ietf.org= /arch/msg/rtcweb/lIuiu91_L2nOh935eAqifrs_ius

    On Thu, Jun 28, 2018 at 8:19 AM, Micha= el Tuexen <michael.tuexen@lurchi.franken.de> = wrote:


    > On 28. Jun 2018, at 17:01, Harald Alvestrand <harald@alvestrand.no> wrote: >
    > Den 28. juni 2018 16:35, skrev Michael Tuexen:
    >>> On 28. Jun 2018, at 16:22, Harald Alvestrand <harald@alvestrand.no> w= rote:
    >>>
    >>> Den 28. juni 2018 14:51, skrev Michael Tuexen:
    >>>>> On 28. Jun 2018, at 13:30, Harald Alvestrand <harald@alvestrand.no> wrote:
    >>>>>
    >>>>> In considering the datachannel API, we encountered one= interesting race
    >>>>> condition:
    >>>>>
    >>>>> A: <configure for datachannel>
    >>>>>
    >>>>> A: CreateOffer(), SetLocalDescription(), send SDP
    >>>>>
    >>>>> B: SetRemoteDescription, CreateAnswer, SetLocalDescrip= tion, send SDP
    >>>>>
    >>>>> B: Configure an externally defined data channel, with = #3249
    >>>>>
    >>>>> B: Send a message on #3249
    >>>>>
    >>>>> A: SetRemoteDescription
    >>>>>
    >>>>> A: Wait a while (THE PAUSE)
    >>>>>
    >>>>> A: Configure #3249
    >>>>>
    >>>>> Now, if a message comes in to A on #3249 during THE PA= USE, what is the
    >>>>> implementation to do?
    >>>> Isn't that some kind or error condition?
    >>>>
    >>>> If that it true, one could apply:
    >>>>
    >>>>=C2=A0 If a message with an unsupported PPID is received or= some error
    >>>>=C2=A0 condition related to the received message is detecte= d by the receiver
    >>>>=C2=A0 (for example, illegal ordering), the receiver SHOULD= close the
    >>>>=C2=A0 corresponding data channel.=C2=A0 This implies in pa= rticular that
    >>>>=C2=A0 extensions using additional PPIDs can't be used = without prior
    >>>>=C2=A0 negotiation.
    >>>
    >>>
    >>> The receiver can't close the datachannel if the datachanne= l doesn't
    >>> exist yet, so this doesn't work for that case.
    >> I was assuming that the SCTP receives a user message on a stream. = When
    >> this message is delivered to its upper layer, doesn't this lay= er know
    >> that there is no data channel? I would assume that this layer trig= gers
    >> the stream reset procedure. I'm not saying that the user (for = example
    >> via a JS API) is involved... I'm more talking about implementi= ng this
    >> iside the browser..
    >
    >
    > Exactly, it could close the stream, but it can't close the data ch= annel
    > since it doesn't exist.
    Well, I can run the procedure and the peer will get an indicati= on that
    something isn't working well.
    >
    > I think closing the stream would be a mistake, since that would make t= he
    > outcome about whether you end up with the datachannel or not racy;
    > discarding data will give you a working datachannel once A gets around=
    > to configuring it.
    But if the user configures a reliable data channel, the user does no= t
    get the service that was required...

    Best regards
    Michael
    >

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

    _______________________________________________
    rtcweb mailing list
    rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
    --000000000000cd9ded056fbfd814-- From nobody Fri Jun 29 07:03:34 2018 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 3D354130E83 for ; Fri, 29 Jun 2018 07:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LWgvxiXWeRJ for ; Fri, 29 Jun 2018 07:03:27 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3075130EF7 for ; Fri, 29 Jun 2018 07:03:26 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id t198-v6so3437019ywc.3 for ; Fri, 29 Jun 2018 07:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6gjK3VkUKLBa0295hS1zIQp05H41d5J5TTIzSt/jSAI=; b=pWPoGIIMcHmcfmjj5Tn4zXloqvowCgyZGogjJ8KEjBm7CydWClt559uwC5ae8YmpAM oNX+geb8ej2I53S0mDUMTio8Fx+VW7tRDk5+dq1/whVzvHttgwVu7j5tx92yXGHaVbdd 6fBLD/I1VimO0Ffi0j0y4JLQ0F/711m8pJYfuiLbcRFsbdxbJ2XCGchdcrxxpR9LhaUH e9dol5jTtLrl1E7xy5wzW5UVPBjlbXOVVpXFpV98WnPj1LzksKmYYW1ZRGwz4qnL+29g Q9tHp82E7MkR4temvctrMf1BASzLuIJQgbDYkXYNGLvC0Io12DJn8DGJgDUVIbvYw2l6 dKvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6gjK3VkUKLBa0295hS1zIQp05H41d5J5TTIzSt/jSAI=; b=O83vmvIONJyhJuA9/cdgJ71wYEEb1c/y+PhGQcLnSeC2ZT8sgACwRhraB3kmAuM3/x DNQVgRwqRMfU39+EdWrI9Ac1xgWh9cIHtHCIMeJH8Cz3zObl+D2Hs2Xdq+ldNkOAZm1x VWnJYMW2e2Yt8NtuOuAlbzXVw/b8TPzVmPaC3wm2Ot+Q+Xt8O1UcS5UiSG4K2/ND7eSd eh50H0Uz6inxkwJftb6oFlGcBCBBuOKEvlTC7m4CMBPiABDi2pYjruZtATomtV7ZoDGT JBDUh/7DRuVNf142sng3krsDtSzuWGpyvNQ+ZEgEblMYYunDDB/V8qEzULm9yEypG5Hc /kJw== X-Gm-Message-State: APt69E2Y8p3O8B7BYVZGQ+BK6L5mD908dsNMHpL2TN+MzPU5pGEwzt0a hOfzWNuyF0QSMyuYoJGoRCKFtJJ1RxkSgg+rYCbx5KuQ X-Google-Smtp-Source: AAOMgpe+DiBZrCVITMeDGu+VmvR8hx0viPzddRmnv1SuD/D/n4i3dlDafN/Lt8zKFGxw7fzLPSXBn+JAKe9LzRYExlc= X-Received: by 2002:a81:2ec8:: with SMTP id u191-v6mr7162376ywu.430.1530281005944; Fri, 29 Jun 2018 07:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 29 Jun 2018 07:02:45 -0700 (PDT) In-Reply-To: References: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> From: Eric Rescorla Date: Fri, 29 Jun 2018 07:02:45 -0700 Message-ID: To: Matthew Kaufman Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c4382c056fc84f80" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 14:03:32 -0000 --000000000000c4382c056fc84f80 Content-Type: text/plain; charset="UTF-8" It seems like this is something one could A/B test and measure connection rates. Has someone done so? -Ekr On Fri, Jun 15, 2018 at 10:48 AM, Matthew Kaufman wrote: > Opposed because we shouldn't waste any more time on IPv4, and IPv6 has no > analog that we can implement for IPv6 and then implement for IPv4 largely > for free. > > Matthew Kaufman > > > On Thu, Jun 14, 2018 at 2:32 PM Justin Uberti ietf.org> wrote: > >> On Thu, Jun 14, 2018 at 2:15 PM Harald Alvestrand >> wrote: >> >>> I have some worries about this proposal. It seems neat, and solves a >>> specific problem for a specific use case, but it's not a written-up >>> proposal, rather a sketch for one - and I'm afraid of devils in the >>> details. >>> >>> For instance: >>> >>> - If this technique is used for a computer directly connected to the >>> Internet, with a public IP address, it won't communicate - unless it is >>> only used on private addresses - because "uuid.local" doesn't resolve, >>> whereas a public IP address is globally reachable. >> >> >>> - The above means that the proposal needs a definition of "private >>> address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6 >>> range is covered by the proposal? >>> >>> - It will only work if the private address usage is the same scope as >>> mDNS resolution. On an unmanaged LAN it works, and on a network with >>> explicit mDNS forwarding it works. But on any other deployment, it >>> forces traffic to go via public IP addresses learned by STUN. >>> >>> I think this is worth adding. Perhaps as a new "mode 2m"? >>> >>> But I'd like a commitment to not adding it until we have a full proposal. >>> >> >> I have sketched out the proposal in https://github.com/juberti/ >> draughts/pull/103, which while not complete, does address most of your >> questions. >> >>> >>> Den 12. juni 2018 02:40, skrev Justin Uberti: >>> > The Safari team has come up with a clever approach to avoid disclosing >>> > private IP addresses for host candidates. As discussed in this WebKit >>> > bug , the technique >>> > works as follows: >>> > >>> > 1. Register a random UUID-based mDNS name when ICE gathering starts >>> > 2. Replace the private IP address by a "{UUID}.local" string in each >>> > host candidate (and set raddr to 0.0.0.0 for other candidates) >>> > 3. The other party will do mDNS resolution on any candidate having a >>> > .local suffix, similar to how hostnames in candidates are handled >>> in >>> > RFC 5245, Section 15.1. >>> > >>> > This technique is relevant to the IP handling document, as it addresses >>> > one of the lesser problems (private IP disclosure) from the overall >>> > problem statement. While I don't think this will have a large impact on >>> > the document, including the default mode selection, incorporating this >>> > technique would result in some moderate changes: >>> > >>> > * Section 5.1 would mention concealing private IPs in the default >>> case >>> > as an explicit goal. >>> > * In Section 6, Mode 2 would change from handling out private IPs to >>> > handing out mDNS names. >>> > * This document would have to describe the technique or point to >>> > another document that describes the technique. mmusic-ice-sip-sdp, >>> > Section 4.1 >>> > >> 20#section-4.1> seems >>> > like a good option, as it already covers how to handle DNS names in >>> > ICE candidates. >>> > >>> > This is a significant improvement and I think we will want to >>> > incorporate this suggestion. Is this something we could do as part of >>> > this WGLC, or should we look for another option? >>> > >>> > >>> > _______________________________________________ >>> > 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 >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --000000000000c4382c056fc84f80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It seems like this is something one could A/B test an= d measure connection rates. Has someone done so?

    -Ekr



    On Fri, Jun 15, 2018 at 10:48 AM, Matthew K= aufman <matthew@matthew.at> wrote:
    Opposed because we shouldn't waste any m= ore time on IPv4, and IPv6 has no analog that we can implement for IPv6 and= then implement for IPv4 largely for free.

    Matthew Kaufman

    On Thu, Jun 14, 2018 at 2:= 32 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
    =
    On Thu, Jun 14, 2018 at 2:15 PM Harald Alvestrand &l= t;harald@alvestra= nd.no> wrote:
    I have some worries about this proposal. It seems neat, and solves a specific problem for a specific use case, but it's not a written-up
    proposal, rather a sketch for one - and I'm afraid of devils in the det= ails.

    For instance:

    - If this technique is used for a computer directly connected to the
    Internet, with a public IP address, it won't communicate - unless it is=
    only used on private addresses - because "uuid.local" doesn't= resolve,
    whereas a public IP address is globally reachable.=C2=A0

    - The above means that the proposal needs a definition of "private
    address". Do we mean "private" in the RFC 1918 sense? If so,= which IPv6
    range is covered by the proposal?

    - It will only work if the private address usage is the same scope as
    mDNS resolution. On an unmanaged LAN it works, and on a network with
    explicit mDNS forwarding it works. But on any other deployment, it
    forces traffic to go via public IP addresses learned by STUN.

    I think this is worth adding. Perhaps as a new "mode 2m"?

    But I'd like a commitment to not adding it until we have a full proposa= l.

    I have sketched out the proposal in=C2=A0https://gith= ub.com/juberti/draughts/pull/103, which while not complete, does a= ddress most of your questions.

    Den 12. juni 2018 02:40, skrev Justin Uberti:
    > The Safari team has come up with a clever approach to avoid disclosing=
    > private IP addresses for host candidates. As discussed in this WebKit<= br> > bug <https://bugs.webkit.org/show_bug.c= gi?id=3D174500>, the technique
    > works as follows:
    >
    >=C2=A0 1. Register a random UUID-based mDNS name when ICE gathering sta= rts
    >=C2=A0 2. Replace the private IP address by a "{UUID}.local" = string in each
    >=C2=A0 =C2=A0 =C2=A0host candidate (and set raddr to 0.0.0.0 for other = candidates)
    >=C2=A0 3. The other party will do mDNS resolution on any candidate havi= ng a
    >=C2=A0 =C2=A0 =C2=A0.local suffix, similar to how hostnames in candidat= es are handled in
    >=C2=A0 =C2=A0 =C2=A0RFC 5245, Section 15.1.
    >
    > This technique is relevant to the IP handling document, as it addresse= s
    > one of the lesser problems (private IP disclosure) from the overall > problem statement. While I don't think this will have a large impa= ct on
    > the document, including the default mode selection, incorporating this=
    > technique would result in some moderate changes:
    >
    >=C2=A0 =C2=A0* Section 5.1 would mention concealing private IPs in the = default case
    >=C2=A0 =C2=A0 =C2=A0as an explicit goal.
    >=C2=A0 =C2=A0* In Section 6, Mode 2 would change from handling out priv= ate IPs to
    >=C2=A0 =C2=A0 =C2=A0handing out mDNS names.
    >=C2=A0 =C2=A0* This document would have to describe the technique or po= int to
    >=C2=A0 =C2=A0 =C2=A0another document that describes the technique. mmus= ic-ice-sip-sdp,
    >=C2=A0 =C2=A0 =C2=A0Section 4.1
    >=C2=A0 =C2=A0 =C2=A0<= https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#sect= ion-4.1>=C2=A0seems
    >=C2=A0 =C2=A0 =C2=A0like a good option, as it already covers how to han= dle DNS names in
    >=C2=A0 =C2=A0 =C2=A0ICE candidates.
    >
    > This is a significant improvement and I think we will want to
    > incorporate this suggestion. Is this something we could do as part of<= br> > this WGLC, or should we look for another option?
    >
    >
    > _______________________________________________
    > 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

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

    --000000000000c4382c056fc84f80-- From nobody Fri Jun 29 11:10:36 2018 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 80D02130DE3 for ; Fri, 29 Jun 2018 11:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 73C4ujQfz9g2 for ; Fri, 29 Jun 2018 11:10:30 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61480130DF6 for ; Fri, 29 Jun 2018 11:10:30 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a195-v6so4048388itd.3 for ; Fri, 29 Jun 2018 11:10:30 -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=ScDWiLfw4Icpg+zUGGwFiLim6s1d7WD4gL+TZKSZGw8=; b=i44UIhMXFslXIAwKSjyhpKUpy1a1eRb7c25zgeElxIJIRjyZORIfOvhwE4my2jLG3b Bv5kQIj+JsWqtS4fVNcHgu8a+QcS+cX6nOJjoU2CpXu4YqpiLtQTx3rXkPFt2RlnxVqI AfPOBfJFWGl1/roHF77Dn+9oorlxqf2BPJfuwaoxpRSwiZd35RSiGIZ65/VaitgJgPXA PuPj2jzqZRjf1B6W0yFbTRRqMr2h5/C26z/5BgKkVlnwY5fQuGtWqz4t5EpkgTXtWaN+ fjcu898ut+hNQOCnOErULYhHUjAdTxGc95qx5lqJru3pX4V33ZYCL2UxbwqKBmBjpeC0 liww== 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=ScDWiLfw4Icpg+zUGGwFiLim6s1d7WD4gL+TZKSZGw8=; b=VdPQPmcH/2GVH+ncIgzQhiuA8Eo+VZcdtKL402h5PZsxZ1jFwT8P6ruD8MvkVOlOED 9EdCXOdLInBx70gi3Zam6SMezraadfhRz2RNjl6qPC/IPbWQIt+SXaZeADIisMIhYvy6 Wf6BvbEpnInHirmg3OBU5Itz3xDvN38K3Jz6BwvdLw1YitFuCDXyMSVbNZoxVRzXMmHA AZYELEMLCxcEeugyYSyQ7Vyi1sJLzZdP7aT/8aAAO14qc13d7LOAfK7bkuHJ3XElqDsM W1h3/kmjAJVQk4ge+HY76DMXqDgYhV3DdaMZgyHjjm9hUGwgj5+85sVxGCoCw0Re2O4J NIVA== X-Gm-Message-State: APt69E3zf3WubfZaZgNSZSreqAuLAB5VG2kuvHq/7VN/TUUMqKl1s6HY O38dA7E5TIizKZo55eVUmkDgWKl4jIGsaunhSM3wCA== X-Google-Smtp-Source: AAOMgpcOOiA4y6An/FLgUZO+mjS3eFoFbF4VT9Gybf2ExdJlUGkEz1sZlnUzY/ZHJMW/4jWqC0IYmKF6yXq0hYIxMvw= X-Received: by 2002:a24:ce81:: with SMTP id v123-v6mr2560798itg.119.1530295829240; Fri, 29 Jun 2018 11:10:29 -0700 (PDT) MIME-Version: 1.0 References: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> In-Reply-To: From: Justin Uberti Date: Fri, 29 Jun 2018 11:10:17 -0700 Message-ID: To: Eric Rescorla Cc: Matthew Kaufman , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000004e39c8056fcbc344" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 29 Jun 2018 18:10:34 -0000 --0000000000004e39c8056fcbc344 Content-Type: text/plain; charset="UTF-8" I believe such data will be forthcoming from the Safari team. We are also working on this. On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla wrote: > It seems like this is something one could A/B test and measure connection > rates. Has someone done so? > > -Ekr > > > > On Fri, Jun 15, 2018 at 10:48 AM, Matthew Kaufman > wrote: > >> Opposed because we shouldn't waste any more time on IPv4, and IPv6 has no >> analog that we can implement for IPv6 and then implement for IPv4 largely >> for free. >> >> Matthew Kaufman >> >> >> On Thu, Jun 14, 2018 at 2:32 PM Justin Uberti > 40google.com@dmarc.ietf.org <40google.com@dmarc.ietf..org>> wrote: >> >>> On Thu, Jun 14, 2018 at 2:15 PM Harald Alvestrand >>> wrote: >>> >>>> I have some worries about this proposal. It seems neat, and solves a >>>> specific problem for a specific use case, but it's not a written-up >>>> proposal, rather a sketch for one - and I'm afraid of devils in the >>>> details. >>>> >>>> For instance: >>>> >>>> - If this technique is used for a computer directly connected to the >>>> Internet, with a public IP address, it won't communicate - unless it is >>>> only used on private addresses - because "uuid.local" doesn't resolve, >>>> whereas a public IP address is globally reachable. >>> >>> >>>> - The above means that the proposal needs a definition of "private >>>> address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6 >>>> range is covered by the proposal? >>>> >>>> - It will only work if the private address usage is the same scope as >>>> mDNS resolution. On an unmanaged LAN it works, and on a network with >>>> explicit mDNS forwarding it works. But on any other deployment, it >>>> forces traffic to go via public IP addresses learned by STUN. >>>> >>>> I think this is worth adding. Perhaps as a new "mode 2m"? >>>> >>>> But I'd like a commitment to not adding it until we have a full >>>> proposal. >>>> >>> >>> I have sketched out the proposal in >>> https://github.com/juberti/draughts/pull/103, which while not complete, >>> does address most of your questions. >>> >>>> >>>> Den 12. juni 2018 02:40, skrev Justin Uberti: >>>> > The Safari team has come up with a clever approach to avoid disclosing >>>> > private IP addresses for host candidates. As discussed in this WebKit >>>> > bug , the technique >>>> > works as follows: >>>> > >>>> > 1. Register a random UUID-based mDNS name when ICE gathering starts >>>> > 2. Replace the private IP address by a "{UUID}.local" string in each >>>> > host candidate (and set raddr to 0.0.0.0 for other candidates) >>>> > 3. The other party will do mDNS resolution on any candidate having a >>>> > .local suffix, similar to how hostnames in candidates are handled >>>> in >>>> > RFC 5245, Section 15.1. >>>> > >>>> > This technique is relevant to the IP handling document, as it >>>> addresses >>>> > one of the lesser problems (private IP disclosure) from the overall >>>> > problem statement. While I don't think this will have a large impact >>>> on >>>> > the document, including the default mode selection, incorporating this >>>> > technique would result in some moderate changes: >>>> > >>>> > * Section 5.1 would mention concealing private IPs in the default >>>> case >>>> > as an explicit goal. >>>> > * In Section 6, Mode 2 would change from handling out private IPs to >>>> > handing out mDNS names. >>>> > * This document would have to describe the technique or point to >>>> > another document that describes the technique. mmusic-ice-sip-sdp, >>>> > Section 4.1 >>>> > < >>>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1 >>>> > seems >>>> > like a good option, as it already covers how to handle DNS names >>>> in >>>> > ICE candidates. >>>> > >>>> > This is a significant improvement and I think we will want to >>>> > incorporate this suggestion. Is this something we could do as part of >>>> > this WGLC, or should we look for another option? >>>> > >>>> > >>>> > _______________________________________________ >>>> > 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 >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --0000000000004e39c8056fcbc344 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I believe such data will be forthcoming from the Safari te= am. We are also working on this.

    On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <ekr@rtfm.com> wrote:
    It seems like this is something one co= uld A/B test and measure connection rates. Has someone done so?

    -Ekr



    On Fri, Jun 15, 2018 at 10:= 48 AM, Matthew Kaufman <matthew@matthew.at> wrote:
    Opposed because we shouldn't= waste any more time on IPv4, and IPv6 has no analog that we can implement = for IPv6 and then implement for IPv4 largely for free.

    M= atthew Kaufman

    On Thu, Jun 14, 2018 at 2:= 32 PM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:
    On Thu, Jun 14, 2018 at 2:15 PM Harald Alvestrand <harald@alvestrand.n= o> wrote:
    I have some worries about this proposal. It seems neat, and solves a
    specific problem for a specific use case, but it's not a written-up
    proposal, rather a sketch for one - and I'm afraid of devils in the det= ails.

    For instance:

    - If this technique is used for a computer directly connected to the
    Internet, with a public IP address, it won't communicate - unless it is=
    only used on private addresses - because "uuid.local" doesn't= resolve,
    whereas a public IP address is globally reachable.=C2=A0

    - The above means that the proposal needs a definition of "private
    address". Do we mean "private" in the RFC 1918 sense? If so,= which IPv6
    range is covered by the proposal?

    - It will only work if the private address usage is the same scope as
    mDNS resolution. On an unmanaged LAN it works, and on a network with
    explicit mDNS forwarding it works. But on any other deployment, it
    forces traffic to go via public IP addresses learned by STUN.

    I think this is worth adding. Perhaps as a new "mode 2m"?

    But I'd like a commitment to not adding it until we have a full proposa= l.

    I have sketched out the proposal in=C2=A0https://gith= ub.com/juberti/draughts/pull/103, which while not complete, does addres= s most of your questions.

    Den 12. juni 2018 02:40, skrev Justin Uberti:
    > The Safari team has come up with a clever approach to avoid disclosing=
    > private IP addresses for host candidates. As discussed in this WebKit<= br> > bug <https://bugs.webkit.org/show_bug.cgi?id= =3D174500>, the technique
    > works as follows:
    >
    >=C2=A0 1. Register a random UUID-based mDNS name when ICE gathering sta= rts
    >=C2=A0 2. Replace the private IP address by a "{UUID}.local" = string in each
    >=C2=A0 =C2=A0 =C2=A0host candidate (and set raddr to 0.0.0.0 for other = candidates)
    >=C2=A0 3. The other party will do mDNS resolution on any candidate havi= ng a
    >=C2=A0 =C2=A0 =C2=A0.local suffix, similar to how hostnames in candidat= es are handled in
    >=C2=A0 =C2=A0 =C2=A0RFC 5245, Section 15.1.
    >
    > This technique is relevant to the IP handling document, as it addresse= s
    > one of the lesser problems (private IP disclosure) from the overall > problem statement. While I don't think this will have a large impa= ct on
    > the document, including the default mode selection, incorporating this=
    > technique would result in some moderate changes:
    >
    >=C2=A0 =C2=A0* Section 5.1 would mention concealing private IPs in the = default case
    >=C2=A0 =C2=A0 =C2=A0as an explicit goal.
    >=C2=A0 =C2=A0* In Section 6, Mode 2 would change from handling out priv= ate IPs to
    >=C2=A0 =C2=A0 =C2=A0handing out mDNS names.
    >=C2=A0 =C2=A0* This document would have to describe the technique or po= int to
    >=C2=A0 =C2=A0 =C2=A0another document that describes the technique. mmus= ic-ice-sip-sdp,
    >=C2=A0 =C2=A0 =C2=A0Section 4.1
    >=C2=A0 =C2=A0 =C2=A0<= https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1>=C2=A0seems
    >=C2=A0 =C2=A0 =C2=A0like a good option, as it already covers how to han= dle DNS names in
    >=C2=A0 =C2=A0 =C2=A0ICE candidates.
    >
    > This is a significant improvement and I think we will want to
    > incorporate this suggestion. Is this something we could do as part of<= br> > this WGLC, or should we look for another option?
    >
    >
    > _______________________________________________
    > 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

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


    --0000000000004e39c8056fcbc344-- From nobody Fri Jun 29 18:06:54 2018 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 52F85130F90 for ; Fri, 29 Jun 2018 18:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50fZIvNGLY5z for ; Fri, 29 Jun 2018 18:06:50 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F135F130E3B for ; Fri, 29 Jun 2018 18:06:49 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id g3-v6so8606501ljk.12 for ; Fri, 29 Jun 2018 18:06:49 -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=pBDikq7/AtJDt5kYE41/oLyF5s0ZsYQNZxy2hr2huz0=; b=m3yE4HI07X72Pcqx2kMAaEC2yrMBcpsE1Z5GZ2NGByi0H+oqM7Kdg4I7unVX5mwgBO OGqcWX7T+6qQiWwy33889yZWbCGUnHee2Nx8cJfg+46WYl+7My8xMsUMDPrJgzgV+Zub xw4yaX/9l/XWZ0HtlQxH/c+kAhOSMuJQN9FQTj3b3znm1LOmN1rTJRUpCQbAq+IC9vKN VMWFUcgm0n91+3XUTSzqUfYsRbnxuKS/UzeZht1y3QUc/mJnqa8hYQKIj1Ob0qjYPbJ8 o3y6Hun8EgUW16zYWr2hmeREbF97M5fJ7TJ2fI8UG42RsHcUtTAuU9ZZZwJvbD7BIFjC leog== 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=pBDikq7/AtJDt5kYE41/oLyF5s0ZsYQNZxy2hr2huz0=; b=jnWhWaybWKJbxgQmPounW8YK+/yXUHlR2Hj82F8Qi8ratsIVJv+pt1bd9Y3YiAA+BO t0lNFfY3BJn5zyBDQZPLOSCus1tw88cb+IHxeBJRVL+IH7qstO1iO9vujDmpB21w9l0F EeQd5a5yEVJLCMlU8NSVhJvRw31/P1VFdTHGPiWJfVSHAsLkHnzUX3at81giNi+tNqsQ LMKiROW1VUVO20jxuIwX0p0XejJK7ITCLxVIHmG2Co8pcURDO2OrIwr2OKzfZAOTvDEg esUvnpqo8s9P72LoOCENetRpEAjpL7VdVb1XzYixOuTTTF5snPiBsL4U6RTqQS/OJTtM Qwjw== X-Gm-Message-State: APt69E3jkrSIp/G/QUTxFZskrHgB1tp1H1hfxKYBa63jnL4ZMOoZzuFU WqqMSqLMtFZTrHnuVhQehDFAyWYYXkh0OytaoBQ= X-Google-Smtp-Source: AAOMgpevm41/CsA4jHGIMnnuvkG29w9geUeZ5LFu9yVVBWrhDSIuzfJN628RMGckujhRZj+BknntRiLmpFYvZgrugA8= X-Received: by 2002:a2e:83cf:: with SMTP id s15-v6mr7173438ljh.101.1530320808075; Fri, 29 Jun 2018 18:06:48 -0700 (PDT) MIME-Version: 1.0 References: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> In-Reply-To: From: youenn fablet Date: Fri, 29 Jun 2018 18:06:35 -0700 Message-ID: To: Justin Uberti Cc: Eric Rescorla , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000002868ed056fd194c2" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 01:06:53 -0000 --0000000000002868ed056fd194c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A draft describing the Safari/WebKit approach is available at https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt Eric, can you precise the kind of information you would like to have? Some testing has been done to validate the approach but I do not think this is representative of the actual state of the affair. Safari/WebKit is not gathering any related statistic. Y Le ven. 29 juin 2018 =C3=A0 11:10, Justin Uberti a =C3=A9crit : > I believe such data will be forthcoming from the Safari team. We are also > working on this. > > On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla wrote: > >> It seems like this is something one could A/B test and measure connectio= n >> rates. Has someone done so? >> >> -Ekr >> > --0000000000002868ed056fd194c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    A draft describing the Safari/WebKit approach is available= at=C2=A0https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt

    Eric, can you precise the kind of information you would like to hav= e?
    Some testing has been done to validate the approach but I do not= think this is representative of the actual state of the affair. Safari/Web= Kit is not gathering any related statistic.

    =C2=A0= =C2=A0Y

    Le=C2=A0= ven. 29 juin 2018 =C3=A0=C2=A011:10, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> a = =C3=A9crit=C2=A0:
    = I believe such data will be forthcoming from the Safari team. We are also w= orking on this.

    On= Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <ekr@rtfm.com> wrote:
    It seems like this is something one c= ould A/B test and measure connection rates. Has someone done so?
    <= div>
    -Ekr
    --0000000000002868ed056fd194c2-- From nobody Sat Jun 30 05:44:31 2018 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 402D21310B8 for ; Sat, 30 Jun 2018 05:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drbDmrHf7KYH for ; Sat, 30 Jun 2018 05:44:27 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F48130DFA for ; Sat, 30 Jun 2018 05:44:27 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id g123-v6so5128327ywf.13 for ; Sat, 30 Jun 2018 05:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S8ZkO3+FGoitEOyp1MhUlhehahrbEgwWjylkA1wILu8=; b=RzopFVd5o5OeZ7PS0l9y7N6rjwebZdOHk89ZsNnUmL9/N5iHyrKWRVkkW99t0yAoVH Yhfbw8b2HXE32Upmt1thq061OnWxXx+TjNXU2EZx8CwQQb3BYOmDRsIVcSRbFQFpvXc7 Md/xkvHpEJUXYZfaGqy199Eaox2iuLBq3BfIAiORVK+DQTjZTdDdrdfp/tgrF/cumtf+ S9v6ipm9uKhDqNfkAVYmX/egfqmcsHq9tBdZ6ZH77ykSBhMzS7LjlCzalsvtzsSArHjq B7PrETdkCLtxlFff+8Wvzng5HBd5kT70VR4AwlNZnugJFJjq+KXdJLQJ1bosxCUCTRHm 9RzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S8ZkO3+FGoitEOyp1MhUlhehahrbEgwWjylkA1wILu8=; b=uhZUrSszJn/lz1iV6AdqSzvuiBW0Il/6muCYYF5uUmNeI/EDkN5N2+fDbvaTkeMwdK FUuiqwCMqB7CRr4Vi/ZqyBodfwXsA8QH/ViT0rAvscgbBARASeoNJTJpv18Sx0ZCRf+S JDIceJ9vPJ5oBFXt2+9myCsV1RnIzsgVSynYvilpkRo1y6vWmvfav+/+9bUxC0a1rqBF yNXGOOZwGx6b2If7WZG8NCmRXnO4PmAu3M3wihH6sN6TzkqmnaZlRq9CFRFAZoc2dtIL CmsQL0t5eRD2itDVOVzmyRxG3WxBCsHKlatndjMO+0pyLeJ1gDCzVPthpjtQKheMTouV We6A== X-Gm-Message-State: APt69E3q0Iabdf5AsH7JMuD0S6o0n1ALAlMmyKudSCvDjKNimlQ8Di4x LKKAf54CBLvMiDo+Mhj9O2Hxy06fOr/YfEgrNc1pJw== X-Google-Smtp-Source: AAOMgpfCp3EU8pMksf/7KGA30A9mo2rEiCdAXuOorJdYnd9X6yyeW/1gvZueGB/vTMVGcPzkrgc6y1qicb68aMK8sVs= X-Received: by 2002:a81:b642:: with SMTP id h2-v6mr3791845ywk.102.1530362666509; Sat, 30 Jun 2018 05:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Sat, 30 Jun 2018 05:43:45 -0700 (PDT) In-Reply-To: References: <092e15c3-3ae8-5b18-1195-498f9cef1488@alvestrand.no> From: Eric Rescorla Date: Sat, 30 Jun 2018 05:43:45 -0700 Message-ID: To: youenn fablet Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000001d8178056fdb5315" Archived-At: Subject: Re: [rtcweb] IP handling: Using mDNS names for host candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 30 Jun 2018 12:44:31 -0000 --0000000000001d8178056fdb5315 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't thought about it too much, but I think that I would probably do is an A/B test where I randomly set clients to this strategy or the current strategy and measured success rates, time to connect, and (maybe) some sort of call quality stat. It's not going to be easy because I don't know how much non-permissioned WebRTC there is in the wild. -Ekr On Fri, Jun 29, 2018 at 6:06 PM, youenn fablet wrote: > A draft describing the Safari/WebKit approach is available at > https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt > > Eric, can you precise the kind of information you would like to have? > Some testing has been done to validate the approach but I do not think > this is representative of the actual state of the affair. Safari/WebKit i= s > not gathering any related statistic. > > Y > > Le ven. 29 juin 2018 =C3=A0 11:10, Justin Uberti ietf.org> a =C3=A9crit : > >> I believe such data will be forthcoming from the Safari team. We are als= o >> working on this. >> >> On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla wrote: >> >>> It seems like this is something one could A/B test and measure >>> connection rates. Has someone done so? >>> >>> -Ekr >>> >> --0000000000001d8178056fdb5315 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I haven't thought about it too much, but I think = that I would probably do is an A/B test where I randomly set clients to thi= s strategy or the current strategy and measured success rates, time to conn= ect, and (maybe) some sort of call quality stat. It's not going to be e= asy because I don't know how much non-permissioned WebRTC there is in t= he wild.
    -Ekr


    On Fri, Jun 29, 2018 at 6:06 PM, youen= n fablet <youennf@gmail.com> wrote:
    A draft describing the Safari/WebKit approach i= s available at=C2=A0https://www.ietf.org/id/draft-mdns-ice= -candidates-00.txt

    Eric, can you precise the ki= nd of information you would like to have?
    Some testing has been don= e to validate the approach but I do not think this is representative of the= actual state of the affair. Safari/WebKit is not gathering any related sta= tistic.

    =
    =C2=A0 =C2=A0Y

    Le=C2=A0ven. 29 juin 2018 =C3=A0=C2=A011:= 10, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> a =C3=A9crit= =C2=A0:
    I believe = such data will be forthcoming from the Safari team. We are also working on = this.

    On Fri, Jun = 29, 2018 at 7:03 AM Eric Rescorla <ekr@rtfm.com> wrote:
    It seems like this is something one could A/B t= est and measure connection rates. Has someone done so?

    -Ekr

    --0000000000001d8178056fdb5315-- From nobody Sat Jun 30 22:08:03 2018 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 0FD0F130E4A; Sat, 30 Jun 2018 22:07:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153042167701.26517.14133107980117613569@ietfa.amsl.com> Date: Sat, 30 Jun 2018 22:07:57 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 01 Jul 2018 05:07:58 -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 : Annotated Example SDP for WebRTC Authors : Suhas Nandakumar Cullen Jennings Filename : draft-ietf-rtcweb-sdp-10.txt Pages : 120 Date : 2018-06-30 Abstract: The Real-Time Communications in WEB-browsers (Rtcweb) working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the Rtcweb framework, Session Description protocol (SDP) is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common Rtcweb use-cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-10 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-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 Sat Jun 30 22:10:57 2018 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 6CF27130E5F for ; Sat, 30 Jun 2018 22:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZgdeXIiiDTe for ; Sat, 30 Jun 2018 22:10:53 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1CC130E4A for ; Sat, 30 Jun 2018 22:10:52 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id v16-v6so4397928vkd.6 for ; Sat, 30 Jun 2018 22:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jYugYJjJDAUODKfkGJAAxLmzwjHVZghpc285dqfOybw=; b=R4BEPE8SChNDuBI+cimYm9mrPjtBmulh55qa/qKwWN2NHByuKIXz8vnJZtC96kLyWl dy/bYk/8ISoMcgDTh4JhgMtPnITQyGL1doqYSW8IV4s6CVhujVCouOyHYTYygPJ89F3u rPoLi3MParIci691H5o11CAsGtwktlwotYHIAcUIoIEAKGfsHJrJ30gH3DO63zScDc+U f8g14bgD1ScZcJiSnmw9P3pExZPIDn8b38ICr8tFq/btjTEcnhbXsP2nhMOhY4OB0/WR i37PPgV1AWcAfy1BOWhEQPcXvA0OoFsX7ZyrP5uUgSwEq4GMNehfggK2dMpSAOHo+5yR X3WQ== 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=jYugYJjJDAUODKfkGJAAxLmzwjHVZghpc285dqfOybw=; b=Tbe59Ub8N3tUAcpqVULA3JnJJRDtdEnvMaQWZa8+4CvphC0UZnavBZeNhCaKVciWcC p5gXtPJUM64Js7qdGTI6g7Idj7dbU28OaDrYTq8cjnXQ2oEf2I+Ar/7hCVvEgk8E61aD oMWiFAToemx2lGcpZUTgLbh4aVnEJ3Gc1TnBiE4qvpDuiht0cLaoqpM1NnK+ST0CzUtG H9fJx6UaWij+uefvB030AxEaLE37xGwRxDVN/22hdIN4iC5UqcQteB69vc1oGi7NnUis 6+xsggwJJTvuR73xoEL2OgHGCOyfVzN+vHEBJE9BeJKqEDqA/yEvMwZpyamH5vOGdPjX QtAw== X-Gm-Message-State: APt69E39l0T8WIjo0ttZkeI91Uj2RHF/7DkQaTXjQExq6UjTaKZ5LSVg GEJdMebeHbvFEt5uhZb96aeRPqUJEYHVnZHnDsg= X-Google-Smtp-Source: AAOMgpcRMuxQ19kbx7D9V09Mes5iSK8fNhtLkm1TpMZ6WeQ1WiYjytZCMcIdnRMR6L84iReFdoKD3+r8o20Oj4jvLxQ= X-Received: by 2002:a1f:a38b:: with SMTP id m133-v6mr2459715vke.20.1530421851750; Sat, 30 Jun 2018 22:10:51 -0700 (PDT) MIME-Version: 1.0 References: <153042167701.26517.14133107980117613569@ietfa.amsl.com> In-Reply-To: <153042167701.26517.14133107980117613569@ietfa.amsl.com> From: Suhas Nandakumar Date: Sat, 30 Jun 2018 22:10:40 -0700 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="000000000000d486ce056fe91a4a" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.26 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, 01 Jul 2018 05:10:56 -0000 --000000000000d486ce056fe91a4a Content-Type: text/plain; charset="UTF-8" Hello All Version 10 includes changes per Flemming's review of section 5.4 Thanks Suhas On Sat, Jun 30, 2018 at 10:09 PM wrote: > > 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 : Annotated Example SDP for WebRTC > Authors : Suhas Nandakumar > Cullen Jennings > Filename : draft-ietf-rtcweb-sdp-10.txt > Pages : 120 > Date : 2018-06-30 > > Abstract: > The Real-Time Communications in WEB-browsers (Rtcweb) working group > is charged to provide protocol support for direct interactive rich > communication using audio, video and data between two peers' web > browsers. With in the Rtcweb framework, Session Description protocol > (SDP) is used for negotiating session capabilities between the peers. > Such a negotiation happens based on the SDP Offer/Answer exchange > mechanism. > > This document provides an informational reference in describing the > role of SDP and the Offer/Answer exchange mechanism for the most > common Rtcweb use-cases. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-10 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-sdp-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000d486ce056fe91a4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello All

    =C2=A0 Version 10 includes ch= anges per Flemming's review of section 5.4=C2=A0


    Thanks
    Suhas

    On Sat, Jun 30, 2018 at 10:09 PM <internet-drafts@ietf.org> wrote:
    <= /div>

    A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
    This draft is a work item of the Real-Time Communication in WEB-browsers WG= of the IETF.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Annotated Example SDP for WebRTC
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Suha= s Nandakumar
    =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 Cullen Jennings
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-sdp-10.txt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 120
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-06-30

    Abstract:
    =C2=A0 =C2=A0The Real-Time Communications in WEB-browsers (Rtcweb) working = group
    =C2=A0 =C2=A0is charged to provide protocol support for direct interactive = rich
    =C2=A0 =C2=A0communication using audio, video and data between two peers= 9; web
    =C2=A0 =C2=A0browsers.=C2=A0 With in the Rtcweb framework, Session Descript= ion protocol
    =C2=A0 =C2=A0(SDP) is used for negotiating session capabilities between the= peers.
    =C2=A0 =C2=A0Such a negotiation happens based on the SDP Offer/Answer excha= nge
    =C2=A0 =C2=A0mechanism.

    =C2=A0 =C2=A0This document provides an informational reference in describin= g the
    =C2=A0 =C2=A0role of SDP and the Offer/Answer exchange mechanism for the mo= st
    =C2=A0 =C2=A0common Rtcweb use-cases.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-r= tcweb-sdp/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-rtcweb-sd= p-10
    https://datatracker.ietf.org/doc/html/= draft-ietf-rtcweb-sdp-10

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-rtcweb-sdp-10


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

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

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