From nobody Tue May 1 14:33: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 EC25712EACB for ; Tue, 1 May 2018 14:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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=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 29Z0sENGjQFs for ; Tue, 1 May 2018 14:33:22 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 1C66B12EAD2 for ; Tue, 1 May 2018 14:33:22 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id q4-v6so6731657ite.3 for ; Tue, 01 May 2018 14:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qf6PyVqisEfCDJAisWsWBUrkA3RecvNvLk/AgJHYKCs=; b=QURX6R3Zz+ATUwaLsoq1tY0ZEcW03HYdKfFiwwGmGPJUCYgDDOFsXbk32NzfXuHIk0 8XQ4QId4MPF0zfoS38mtBuPykWh9dgpVNQbVvHx00W7cHuXIYFLESlMBW6QJ087eVCKi nbU4Rl4lzFDqaIfWHHJJv5Ee/bogDMS052wh/EDpM9J8kZUHtgSBhMwAuXc0jFj8u3t5 RwsxMjwZAu9BQ/M0lHji2sMhu43Z9PPbYBTsNGiThKwSVMFwegpmFE/gSy51WivYGYRD MaxhBViHDcQ1Wi0nnHg45nbAObpAlKHwBanAcPoqItm2ylIva30VBDuYek2GdzdpdzCA OLGQ== 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=qf6PyVqisEfCDJAisWsWBUrkA3RecvNvLk/AgJHYKCs=; b=IabEvrl2fZgqQ4Dglo0ro/5XCHeC305/i9imuXdgBOyVMvIy84J8dkwzZVili614KU ZPG98OWo/dZDHrrpACUsvPCzjwoALYweGE9NziTcP/9ju09+rL5HJhol853aR9phl+9S 2d/pBQMYwXJBF7WqIFITgc5OepIRkfZvQupnCOOM6W8O8kqTGDrJMFnfBYXfR/L/DuqN FJ04zVsigoOVCCfeuy0hgwBtBtvitRg32cdYdyZoi2BAiLrMNQVO425BOy5y8DqM3m+W Pi4YjrD+eQkQyACPrUFgssiNmCKkRflG/uIgu6tOpEjpp+HvnkamtA9GDdiWDsSFOg7F 7Sug== X-Gm-Message-State: ALQs6tALn1pkG57FyDD42nfkd8ClcrzlLu31YWENMY5C4elmpcDpWVCr Lfj91MM3N7jfjsRiw8RLbCD8Ky1pk1NdoH26XgrgaRr/ X-Google-Smtp-Source: AB8JxZoI+ZZpZim0N05V1Njfw083Mf/ugO3+nH+Qdw28a8XFrkrzCNAArpn1QyCxk/s1jDL1CSV3XIQlkvAdbtYZppM= X-Received: by 2002:a24:df04:: with SMTP id r4-v6mr17528944itg.105.1525210400927; Tue, 01 May 2018 14:33:20 -0700 (PDT) MIME-Version: 1.0 References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> In-Reply-To: From: Justin Uberti Date: Tue, 01 May 2018 21:33:08 +0000 Message-ID: To: Nils Ohlmeier Cc: Cullen Jennings , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000002849ab056b2bb8bd" 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: Tue, 01 May 2018 21:33:25 -0000 --0000000000002849ab056b2bb8bd Content-Type: text/plain; charset="UTF-8" Do you want to take a shot at the text? (either in email or as a PR) On Mon, Apr 30, 2018 at 3:21 PM Nils Ohlmeier wrote: > > On Apr 30, 2018, at 15:03, Justin Uberti wrote: > > Any TURN server provided by the browser is in effect a proxy, and forcing > use of said proxy can be done either through firewall config or explicit > selection of Mode 4. (IOW, no new mode is needed.) > > > I do agree that these two configurations result in a similar behavior. > But I doubt that these use the same code path in implementations. > And (thus) I doubt readers of the draft/RFC will automatically come to the > same conclusion. > > It think it might be helpful to add another sentence explaining this > scenario. > > The document originally pointed at RETURN as an example of how such TURN > proxying could work, but was removed in order to avoid a dependency. > > > Fair enough. > > Nils > > On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings wrote: > >> >> >> On Apr 17, 2018, at 3:15 AM, Justin Uberti < >> juberti=40google.com@dmarc.ietf.org> wrote: >> >> IMO "trusting the TURN relay but not the application" is not a >> significant enough benefit to merit adding specific functionality for. >> >> >> In the case were the TURN server is provided by the JS, I agree. But in >> the case where the configuration of the browser provided the TURN server, >> then I think it is as trusted as say a VPN server. >> >> >> > --0000000000002849ab056b2bb8bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do you want to take a shot at the text? (either in email o= r as a PR)

On Mon, Apr= 30, 2018 at 3:21 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
On Apr 30, 2018, at 15:03, Justin Uber= ti <juberti@goog= le.com> wrote:

Any TURN server provided by the browser= is in effect a proxy, and forcing use of said proxy can be done either thr= ough firewall config or explicit selection of Mode 4. (IOW, no new mode is = needed.)

I do agree that these = two configurations result in a similar behavior.
But I doubt that= these use the same code path in implementations.
And (thus= ) I doubt readers of the draft/RFC will automatically come to the same conc= lusion.

It think it might be helpful to add anothe= r sentence explaining this scenario.

=
The document originally pointed at RETURN as an examp= le of how such TURN proxying could work, but was removed in order to avoid = a dependency.

Fair enough.

=C2=A0 Nils

On Fri, Apr 27, 2018 at 11:22 AM C= ullen Jennings <fluff= y@iii.ca> wrote:


On Apr 17, 2018, at 3:15 AM, Justin Uberti <jube= rti=3D40google.com@dmarc.ietf.org> wrote:

IMO "trusting the TURN relay but not the application"= ; is not a significant enough benefit to merit adding specific functionalit= y for.


In the case were the = TURN server is provided by the JS, I agree. But in the case where the confi= guration of the browser provided the TURN server, then I think it is as tru= sted as say a VPN server.=C2=A0



--0000000000002849ab056b2bb8bd-- From nobody Tue May 1 16:47:23 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 A450A12AAB6 for ; Tue, 1 May 2018 16:47:22 -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, 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 EyryUzOPwmsg for ; Tue, 1 May 2018 16:47:19 -0700 (PDT) Received: from smtp81.ord1d.emailsrvr.com (smtp81.ord1d.emailsrvr.com [184.106.54.81]) (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 EADFB129C6E for ; Tue, 1 May 2018 16:47:18 -0700 (PDT) Received: from smtp19.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 509CE60084; Tue, 1 May 2018 19:47:18 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E9C1D60069; Tue, 1 May 2018 19:47:17 -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); Tue, 01 May 2018 19:47:18 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Tue, 1 May 2018 17:47:16 -0600 Cc: Martin Thomson , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <3992EB2F-E5B8-4118-AB75-B42BC0847BEA@iii.ca> References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> To: Tim Hollebeek X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Tue, 01 May 2018 23:47:23 -0000 > On Apr 30, 2018, at 9:20 AM, Tim Hollebeek = wrote: >=20 > It's entirely possible that there isn't actually a problem if you do = all the right things. > But it's important that all those right things are actually required, = and the rationale > is clearly explained in the security considerations. For example, = doing certificate=20 > expiration checks, so that there isn't crypto data lying around that = can be used in=20 > "interesting" ways in the future when the standard may have evolved = into something=20 > else, seems like a good idea to me. I certainly think it would be worth advising the IdP protocols designers = that they they probably want to consider making the tokens only valid = for a short time such as 30 seconds and they are welcome to have a way = to invalidate and check validity of tokens if they want to do that.=20 >=20 > I also think the musings in Martin's last paragraph make sense and are = headed in the=20 > right direction. There's no harm in making protocols robust against = attack scenarios > we haven't thought of yet. For sure - but we don=E2=80=99t want to do is make it so hard to use = that no one uses. Something the IETF excels at :-) But as long as we can = improve the robustness of the security without huge complication to use, = I=E2=80=99m for that.=20 >=20 > -Tim >=20 >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Monday, April 30, 2018 12:30 AM >> To: Cullen Jennings >> Cc: Tim Hollebeek ; RTCWeb IETF >> >> Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb- >> security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) >>=20 >> I agree with Cullen. >>=20 >> I would also point out that with an intended recipient, the IdP can = limit the >> information that can be obtained from an assertion. If the assertion = were >> provided to other than the intended recipient, the IdP could refuse = to provide >> an identity. That requires authenticating the recipient as well, = which isn't >> something we naturally assume, but the mechanisms for enabling that = are all in >> place. >>=20 >> FWIW, I think that an abundance of caution suggests that limiting the = assertion >> to a particular session is sensible. The problem there is that we = would need a >> session identifier in order to do that. Until we discovered that = RTCCertificate >> was portable, that was considered sufficient, I would prefer to = remove that >> portability. Maybe we should consider adding an origin to = RTCCertificate that >> would allow it to be moved to other origins, but not be used by them. >>=20 >> On Sun, Apr 29, 2018 at 2:01 AM, Cullen Jennings = wrote: >>>=20 >>> Tim - that sounds about right but this is the part I don=E2=80=99t = get=E2=80=A6. >>>=20 >>> All the identity assertion does is bind the public key from the TLS >>> connection to the a name/identity. Think of it like a certificate = that >>> binds my private key to name. Anyone can get my cert and pass it >>> around however they want. That is fine. Similarly the assertion can = be >>> passed around handed to bad people etc. But anyone using it need to >>> match it with a TLS connection that does proof of possession of the >>> private key that matches the public key. That private key is going = to >>> be very narrowly scoped on what has access to it. People that want = to >>> rely on this identity assertion have to be sure that they require = proof of >> possession of private key. >>>=20 >>> So I do not see the issue at all that the identity assertion, just >>> like a normal X508 certificate, can be passed around. I=E2=80=99m = not getting >>> whey this is Slightly Less than Awesome :-) >>>=20 >>> I=E2=80=99m not arguing there is no problem, but I am not getting = what the >>> problem is. >>>=20 >>> Cullen >>>=20 >>>=20 >>>=20 >>> On Apr 27, 2018, at 6:13 PM, Tim Hollebeek >>> >>> wrote: >>>=20 >>> I=E2=80=99m going from my memory from the IETF 101 hackathon here, = so someone >>> feel free to correct me if I=E2=80=99m remembering the details wrong = (I >>> probably am for at least some of it), but as I recall it, the issue >>> was essentially that when one requests an identity assertion, if one >>> presents it to someone, the security properties are Awesome [TM] >>> because only authorized persons can get an identity assertion from = the IDP. >>>=20 >>> However, after one has presented an identity assertion to a >>> potentially untrusted party, presentation of that assertion to >>> additional parties is Slightly Less Than Awesome [TM], because the >>> additional parties cannot distinguish between the person who >>> legitimately obtained the identity assertion, and the party to which >>> the identity assertion was previously presented. >>>=20 >>> Various arguments were made that this is not a problem because the >>> lifetime of identity assertions is short, with lifetimes on the = order >>> of days to hours. There was also some discussion (before the issue >>> was found) about if expiration of the relevant temporary = certificates >>> needed to be checked at all. Call me crazy, but only having a few >>> hours to carry out my attack doesn=E2=80=99t hinder me much as an = attacker! >>>=20 >>> One solution that was discussed, which may or may not work for all = use >>> cases and this certainly should be explored, was that identity >>> assertions are cheap and therefore supporting the complexity of >>> identity assertion re-use might not make sense. We discussed simply >>> adding a nonce to the creation of identity assertions, so IDPs could >>> enforce that they are validated only once, essentially turning them >>> into bearer tokens. If the process fails (network hiccup, etc) it = is >>> possible to transparently regenerate a new assertion and retry. = IIRC >>> certain non-attack failure scenarios needed this retry logic anyway. >>>=20 >>> If needed, I can go back and re-read the messages from that weekend = to >>> help refresh my memory, but that=E2=80=99s what I remember. >>>=20 >>> -Tim >>>=20 >>> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen >>> Jennings >>> Sent: Thursday, April 26, 2018 9:03 PM >>> To: Sean Turner >>> Cc: RTCWeb IETF >>> Subject: Re: [rtcweb] Addressing WGLC comments for >>> draft-ietf-rtcweb-security-arch? (was Re: WGLC for >>> draft-ietf-rtcweb-security-arch) >>>=20 >>>=20 >>>=20 >>>=20 >>> On Apr 12, 2018, at 7:45 AM, Sean Turner wrote: >>>=20 >>> 1) Tweak protocol to include an identifier to prevent reuse of >>> assertion on every RTCPeerConnection: >>>=20 >>> More complex sites frequently generate multiple RTCPeerConnection >>> instances for their communications, especially for group >>> conversations. If the browser requests an assertion once and they = use >>> that value for every RTCPeerConnection, then that's OK. =46rom my >>> perspective, I would be happy modifying the protocol to include an >>> identifier and prevent that; for this the IdP can use caching or its >>> local storage. >>>=20 >>> So, what would that look like? >>>=20 >>>=20 >>> It=E2=80=99s not clear to me what the problem we are solving here = is. Who are >>> we trying to stop from reusing an assertion and why. The assertion = is >>> already bound to the specific private key and specific web origin. = The >>> IdP can bind it to a narrow time range if the IdP wants ( most do). >>> I=E2=80=99m not seeing the big difference from reusing an assertion = vs. asking the for a >> bunch of them. >>> The protocol that users the assertion may end up forking the same >>> assertion to many places regardless of what the browser does. >>>=20 >>> Changing this so that the IdP see how many PeerConnections are = formed >>> seems like it just reveal more usage information to the IdP and does >>> not help security. >>>=20 >>> Assuming I am just not getting the problem and we do want to solve >>> this =E2=80=A6 I is not clear to me how to make this all work with = tls-id due >>> to all the bundle issues. Another approach would the browser greater = a >>> GUID for the PeerConnection and that is passed in the IdP proxy code >>> and the IdP can bind it into the assertion or not but if it does = bind >>> into the assertion, then the browser will only validate the = assertion >>> on the PeerConnection with matching GUID. This is probably wrong and >>> half baked as I don=E2=80=99t really get the problem. >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>>=20 From nobody Tue May 1 16:47: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 BFDF312D874 for ; Tue, 1 May 2018 16:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OIYomPNOYx5y for ; Tue, 1 May 2018 16:47:56 -0700 (PDT) Received: from smtp81.ord1d.emailsrvr.com (smtp81.ord1d.emailsrvr.com [184.106.54.81]) (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 C30BC12D94B for ; Tue, 1 May 2018 16:47:55 -0700 (PDT) Received: from smtp19.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 5816D60079; Tue, 1 May 2018 19:47:55 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1982960083; Tue, 1 May 2018 19:47:55 -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); Tue, 01 May 2018 19:47:55 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Tue, 1 May 2018 17:47:54 -0600 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> To: Martin Thomson X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Tue, 01 May 2018 23:47:58 -0000 > On Apr 29, 2018, at 10:29 PM, Martin Thomson = wrote: >=20 > I agree with Cullen. >=20 > I would also point out that with an intended recipient, the IdP can > limit the information that can be obtained from an assertion. If the > assertion were provided to other than the intended recipient, the IdP > could refuse to provide an identity. That requires authenticating the > recipient as well, which isn't something we naturally assume, but the > mechanisms for enabling that are all in place. >=20 > FWIW, I think that an abundance of caution suggests that limiting the > assertion to a particular session is sensible. The problem there is > that we would need a session identifier in order to do that. Until we > discovered that RTCCertificate was portable, that was considered > sufficient, I would prefer to remove that portability. Maybe we > should consider adding an origin to RTCCertificate that would allow it > to be moved to other origins, but not be used by them. I=E2=80=99m not following how the private keys move between origins - = how does that happen ? Sorry that I missed that part of the thread.=20 From nobody Tue May 1 16:54: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 6C5D61275F4 for ; Tue, 1 May 2018 16:54:27 -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 4AY8bSwNfCFg for ; Tue, 1 May 2018 16:54:25 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 C95B51200A0 for ; Tue, 1 May 2018 16:54:25 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id y15-v6so11397321oia.13 for ; Tue, 01 May 2018 16:54:25 -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:content-transfer-encoding; bh=E5kjga8PWFCq9G1f8hfmqI7HX5dYXz3eIlKXIWN4ZdA=; b=ipx+nHaCt1w+p4x7sgVyHZnY4PAsjeplnUKtHxbRUbira2g4eQzvIyQXFkx1XRnbDJ eET/NZBS6+NorEIvJWKe+OM9Ek2NYJmsp41LmSgw5j69/8pcoFRPpzjau2SyXtlInypt /+fMiSruPM80yeE51X9WrVAmBoPd3zL3ORlBq+dx7r1WI9nNB4C79WMS+hiWcjcSIglQ MlhxGY4QnBsj/KHSA8Y1F/058eIn+Zgx0X+NsDkOIDuYDtgNeuueSDcus2Joxne2WCPX VU82wD9pJsQ8mf1WfihxAepCHiPccCXYOL5fTCGWV1aynwVsZQBdK4KqNpigJDUtcYVq f93Q== 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:content-transfer-encoding; bh=E5kjga8PWFCq9G1f8hfmqI7HX5dYXz3eIlKXIWN4ZdA=; b=SJ6C4yS95XyC14w2hPzWRLN6XzOMzS/+2d/GxBtyN2i5KQQDR21FO1nv0g1YXNcUXe fUOqlos3je9DoYUeZ7L4l/VrwPhgFb/q3C/jRFFwWsmES8+ofqOKyORrUYR7w3Ryxsbq 5K6VwtA1Iqw4uVswWYMWr0Fy2A9uwI5RysAItO5uQeccv0rhYaqHKn4em1aQd1BMSYrn xXj1QU67TMFVldU7sMrErrwCQzK8J8lr5m+/UOexATW2p05UfrrCCpZ5UNn9Jw+kd0Nc wR/8O7p726sZUoW/ETcLEW6pRfFlgUdc6WMU195xvmXpn0EEGeAL/14cfwmKR4lbbTV6 k3dA== X-Gm-Message-State: ALQs6tDsxmpc1MMplvTIZWKL0FBYHwRLwWKkEf3UUf8rO9C4ivoizy2O Z+z9i5q+8AxkqDEjQGhNhX8hJaDeERJRf/7rEjs= X-Google-Smtp-Source: AB8JxZrQQAsv2GToyruxGFmKDek7J/pMgbbNc76rOeAEAp2ZsG4rQjAWdbuH3HdpLCNLhwSme0fAgb/HnQHLqgD85Qo= X-Received: by 2002:aca:1218:: with SMTP id 24-v6mr10250050ois.144.1525218865016; Tue, 01 May 2018 16:54:25 -0700 (PDT) MIME-Version: 1.0 References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> In-Reply-To: <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> From: Martin Thomson Date: Tue, 01 May 2018 23:54:14 +0000 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Tue, 01 May 2018 23:54:27 -0000 On Wed, May 2, 2018 at 1:47 AM Cullen Jennings wrote: > I=E2=80=99m not following how the private keys move between origins - ho= w does that happen ? Sorry that I missed that part of the thread. In order to enable saving of RTCCertificate to indexedDB and the like, we made it Transferable. That means that origin X can use postMessage to send it to origin Y. That's the problem that was discovered during the hackathon. If our intent is to retain the ability to save, but not the ability to move, then binding RTCCertificate to a single origin would work. From nobody Tue May 1 23:04: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 62B2712D86B for ; Tue, 1 May 2018 23:04:24 -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 p6xvdAolEoEB for ; Tue, 1 May 2018 23:04:22 -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 1BFE312D80E for ; Tue, 1 May 2018 23:04:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9F8717C02E3 for ; Wed, 2 May 2018 08:04:20 +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 r5NhI2hhtJvq for ; Wed, 2 May 2018 08:04:19 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 10C4F7C4374 for ; Wed, 2 May 2018 08:03:28 +0200 (CEST) To: rtcweb@ietf.org References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> From: Harald Alvestrand Message-ID: <7ed02fe1-69cc-f774-f61f-ee79f2e9a61d@alvestrand.no> Date: Wed, 2 May 2018 08:03:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.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] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Wed, 02 May 2018 06:04:24 -0000 Den 02. mai 2018 01:54, skrev Martin Thomson: > On Wed, May 2, 2018 at 1:47 AM Cullen Jennings wrote: >> I’m not following how the private keys move between origins - how does > that happen ? Sorry that I missed that part of the thread. > > In order to enable saving of RTCCertificate to indexedDB and the like, we > made it Transferable. That means that origin X can use postMessage to send > it to origin Y. That's the problem that was discovered during the > hackathon. > > If our intent is to retain the ability to save, but not the ability to > move, then binding RTCCertificate to a single origin would work. Actually the RTCCertificate is not marked Transferable (there is no such annotation), but it does support structured cloning (in prose). > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Wed May 2 00:54: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 36B77126C2F for ; Wed, 2 May 2018 00:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd1FUWAvXE3r for ; Wed, 2 May 2018 00:54:49 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 26FA31252BA for ; Wed, 2 May 2018 00:54:49 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id k5-v6so5324658oiw.0 for ; Wed, 02 May 2018 00:54:48 -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:content-transfer-encoding; bh=ilktjPXFL3VlSg+nG88rnVO8G1ocs81HGy1R412hSuo=; b=Ayz1uXpBc5nVJCFqu1enIOrX8LYQ6v/OPiEuCKojZn0CpCCuQzHqBLYzVsk1JiOns3 OTvS29H/yoPu8DCLF8NRsQJud8jmVXoDWj0NardkyQwv4BS3GdB5yux1Hdd6nqzqmZjz rG2sjdm7Qsil/2rgVJIMu70xa3HNJjKIHomOnatHUohrcaNEFbruy01kC+4hR49BQYlJ fwuWwE5/ja9gOcTNJTp0Rkam/B83EFdmsjvh6baEUyaDzRx/Ndv6gj+KO9ccGnUG52f1 xZZOTMIdxLHXmXS2S7vDvYSWLJD+R4EZusPlIrb0WMdR8d2pURzKgx5FWvWX3daQdKdW RTqA== 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:content-transfer-encoding; bh=ilktjPXFL3VlSg+nG88rnVO8G1ocs81HGy1R412hSuo=; b=awZQgxUrINiRkm5Lw30p175z5ggCtgtmgL+E/+eV7HAx8x5zcUyaZjya4GiLafSOzN emMnc9AfzJ6AnXaFuBSAr1AYm0/vZlObhsvvmLwzv8X9137YyNSQXPdqLyOJ/W5r0sbn +N/x8V7DyDzt15CfbV+x84ZGRAYry+3sskzznHHbrd9Xg5EYsqEFMuAyj4bUHnWxx9jw CcNpEllfmG17pclq//iWJctVeHNkIgPv4/+Ji7Xcqi6q3zFqA+tw74hX8BZwdazXiT+I SXr2uBPOrx0wRCA0qLkYW54JHWqvI6mPGIJMxwygbwbhIFiHcTQwwIIiMFgzQC3x6vj3 LDOg== X-Gm-Message-State: ALQs6tCilYdKsYPAAIFDkvNBpkrOowvwjYTz57oE1xfgiwNYkhxn++ba sgkFitQaG5iPT8nEagjuOrgLipzt6ZgPzEhF9qNh6w== X-Google-Smtp-Source: AB8JxZraGtHj7izBmMxsNg5QoI9IyF6ESrEIp6qDzYsYsYqzYjfTmNkUpwDgSfXsMLTYV6Zuc/LgUteIDeEBTh6/Jlc= X-Received: by 2002:aca:d593:: with SMTP id m141-v6mr5174053oig.346.1525247688322; Wed, 02 May 2018 00:54:48 -0700 (PDT) MIME-Version: 1.0 References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> <7ed02fe1-69cc-f774-f61f-ee79f2e9a61d@alvestrand.no> In-Reply-To: <7ed02fe1-69cc-f774-f61f-ee79f2e9a61d@alvestrand.no> From: Martin Thomson Date: Wed, 02 May 2018 07:54:37 +0000 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Wed, 02 May 2018 07:54:51 -0000 Thanks for the correction Harald. I should have checked. The point is that postMessage can be used to move it around. Both structure cloning and Transferable enable that. (Transferable could indeed be preferable because then at least only one origin could use the object at the one time, but it's still not perfect.) On Wed, May 2, 2018 at 4:04 PM Harald Alvestrand wrote: > Den 02. mai 2018 01:54, skrev Martin Thomson: > > On Wed, May 2, 2018 at 1:47 AM Cullen Jennings wrote: > >> I=E2=80=99m not following how the private keys move between origins -= how does > > that happen ? Sorry that I missed that part of the thread. > > > > In order to enable saving of RTCCertificate to indexedDB and the like, we > > made it Transferable. That means that origin X can use postMessage to send > > it to origin Y. That's the problem that was discovered during the > > hackathon. > > > > If our intent is to retain the ability to save, but not the ability to > > move, then binding RTCCertificate to a single origin would work. > Actually the RTCCertificate is not marked Transferable (there is no such > annotation), but it does support structured cloning (in prose). > > > > _______________________________________________ > > 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 May 2 06:34: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 3CBF0126FDC for ; Wed, 2 May 2018 06:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QO6XIbrpUMHA for ; Wed, 2 May 2018 06:34:21 -0700 (PDT) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (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 3340A126FB3 for ; Wed, 2 May 2018 06:34:21 -0700 (PDT) Received: from smtp35.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 582C760EE; Wed, 2 May 2018 09:34:17 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp35.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E1B1858A7; Wed, 2 May 2018 09:34:16 -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); Wed, 02 May 2018 09:34:17 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Wed, 2 May 2018 07:34:15 -0600 Cc: Harald Alvestrand , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> <7ed02fe1-69cc-f774-f61f-ee79f2e9a61d@alvestrand.no> To: Martin Thomson X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Wed, 02 May 2018 13:34:23 -0000 Ok - that makes sense. But it can only be transferred between two JS = apps that trust each other and are trying to share it. This sounds like = a feature not a bug. I=E2=80=99m still missing the problem with this.=20 > On May 2, 2018, at 1:54 AM, Martin Thomson = wrote: >=20 > Thanks for the correction Harald. I should have checked. >=20 > The point is that postMessage can be used to move it around. Both > structure cloning and Transferable enable that. (Transferable could = indeed > be preferable because then at least only one origin could use the = object at > the one time, but it's still not perfect.) > On Wed, May 2, 2018 at 4:04 PM Harald Alvestrand = > wrote: >=20 >> Den 02. mai 2018 01:54, skrev Martin Thomson: >>> On Wed, May 2, 2018 at 1:47 AM Cullen Jennings = wrote: >>>> I=E2=80=99m not following how the private keys move between origins = - how does >>> that happen ? Sorry that I missed that part of the thread. >>>=20 >>> In order to enable saving of RTCCertificate to indexedDB and the = like, > we >>> made it Transferable. That means that origin X can use postMessage = to > send >>> it to origin Y. That's the problem that was discovered during the >>> hackathon. >>>=20 >>> If our intent is to retain the ability to save, but not the ability = to >>> move, then binding RTCCertificate to a single origin would work. >=20 >=20 >> Actually the RTCCertificate is not marked Transferable (there is no = such >> annotation), but it does support structured cloning (in prose). >=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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed May 2 15:58: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 5049112D873; Wed, 2 May 2018 15:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 4Kqu5noQWxva; Wed, 2 May 2018 15:58:10 -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 760CA1270AB; Wed, 2 May 2018 15:58:10 -0700 (PDT) Received: from [10.0.1.86] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w42Mw53p049726 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 May 2018 17:58:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.86] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Ben Campbell In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> Date: Wed, 2 May 2018 17:58:04 -0500 Cc: mmusic WG , "ice@ietf.org" , "rtcweb@ietf.org" , The IESG , Christer Holmberg Content-Transfer-Encoding: quoted-printable Message-Id: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> To: "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Wed, 02 May 2018 22:58:13 -0000 Adam, Ekr, and I spoke last week, and came to the conclusion that trying = to untangle all JSEP dependencies on SIP would require more effort than = is justified, and that the most expedient approach would to just fix the = currently orphaned JSEP references to point to = draft-ietf-mmusic-ice-sip-sdp. Adam has removed this point from his discuss, and has entered an RFC = editor note on JSEP to change the relevant references. (If anyone sees = JSEP references that will still be orphaned after applying that note, = please speak up asap.) I further note that Adam had other DISCUSS points and comments in his = review of draft-ietf-mmusic-trickle-ice-sip that I do not think have = been responded to. The discussion regarding Mirja=E2=80=99s discuss also = seems to have been left hanging. Authors, please follow up on those at = your earliest opportunity. Thanks! Ben. > On Apr 15, 2018, at 2:16 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> Yes. The question is whether to just move the references in JSEP to = point to mmusic-trickle-sip, or do something different. >=20 > I think it would be good to have a list of all the reference instances = that need to be modified. >=20 > Regards, >=20 > Christer >=20 >> On Apr 13, 2018, at 1:29 PM, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> In addition, as I mentioned earlier, there are cases where JSEP = references draft-ice-trickle for things and procedures that don=E2=80=99t = exist in draft-ice-trickle. Instead those references should be to = draft-mmusic-trickle. >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my iPhone >>=20 >> On 13 Apr 2018, at 17.56, Ben Campbell wrote: >>=20 >>>=20 >>>=20 >>>> On Apr 13, 2018, at 7:06 AM, Christer Holmberg = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>>>> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre=20 >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>> On 4/3/18 2:41 PM, Suhas Nandakumar wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell >>>>>> > wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre=20 >>>>>>>> > wrote: >>>>>>>>=20 >>>>>>>> On 4/3/18 12:27 PM, Suhas Nandakumar wrote: >>>>>>>>> Just to complete, ice-bis doesn=C4=85t normatively reference=20= >>>>>>>>> ice-sip-SDP draft when it moved to using =C5=82usages =C5=82 = indirections=20 >>>>>>>>> for signaling protocols. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Trickle ice can use similar approach and refer to trickle-sip=20= >>>>>>>>> as usage for trickle. >>>>>>>>=20 >>>>>>>> It already does. That's why we pulled all the SDP/SIP stuff out=20= >>>>>>>> of draft-ietf-ice-trickle. >>>>>>>=20 >>>>>>> I assume Suhas meant separating the SDP stuff from the SIP=20 >>>>>>> stuff. (I also assume he will correct me if I am wrong.) >>>>>>>=20 >>>>>>>=20 >>>>>>> That's right Ben .. I was just thinking minimal localized = changes=20 >>>>>>> (thus small time to get new draft done) and then asking trickle,=20= >>>>>>> trickle-sip to refer to the new one. (work done to refer is much=20= >>>>>>> smaller for these drafts that are at the very end of approval=20 >>>>>>> journey) >>>>>>>=20 >>>>>>> I do agree with Adam, no matter what version of the proposal we=20= >>>>>>> pick, there is some work that needs to be done and we should do=20= >>>>>>> it. >>>>>>=20 >>>>>> These documents are on the telechat tomorrow. Are we proposing to=20= >>>>>> delay consideration by the IESG while we get this mess sorted = out?=20 >>>>>> ;-) >>>>>=20 >>>>> Hi Peter, >>>>>=20 >>>>> I currently plan to leave it on. We may discuss a way forward on=20= >>>>> the telechat. Also, I=C4=85d like to get feedback on the rest of = the=20 >>>>> draft(s) from the other ADs sooner than later. >>>>=20 >>>> Did you discuss this at the telechat? >>>>=20 >>>> Any other discussions on how to move forward with this? >>>=20 >>> Yes, Adam and I have been discussing this with the RTCWEB chairs. = We=E2=80=99ve since discovered that this is not the only JSEP normative = reference chain back to SIP. The RTCWEB chairs are currently discussing = whether they can live with that. They may decide to just reference = things as they stand. If their answer involves a request to restructure = anything, I will pull in the authors and MMUSIC/ICE chairs. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed May 2 18:21: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 BCC3B127522 for ; Wed, 2 May 2018 18:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXaS5dV_Fh-s for ; Wed, 2 May 2018 18:21:50 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 3D8A4126DCA for ; Wed, 2 May 2018 18:21:50 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id b130-v6so14686882oif.12 for ; Wed, 02 May 2018 18:21:50 -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:content-transfer-encoding; bh=qBLvx0o526o4U0LsLGX1dIav3qxxCGrgJNxFw13ZqNc=; b=J6NlX8M/Byy4+LRQfdDyPKWzPS5NYE48qM+PAgr87kJjllPXPoiQa0MUAYfQOLyJ+d TMr9A5OvTACyxSzntsLJWaBX35tq8MexEmTJvz3NCMP3+43EK90+2kLnd+lmM1AFFikB +K34g6AwgsqqXI6wn/bnsWxbSM+MqjtXrX546IC2rTIBDpq6LAnFM1lUiySwZ8Fm9xqs AhHFDUeMlbOz7cqZVuIvOapPUXEyLD9KV4vIdnttz+wfXmu4vdYM/pFYPTFY0Ai6wPQg n02o4hNezfC7VSTnsXaF+I54kkWs4L2q8usjbbjDQnyeAyBi3UbCp6DFVqfh40XGBRBD IJZw== 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:content-transfer-encoding; bh=qBLvx0o526o4U0LsLGX1dIav3qxxCGrgJNxFw13ZqNc=; b=HUghI0svnDl83JOHVfTAPaTszOK/2d2PWiK4ofZaE2lf2x0hi4KhFYUzGR1hllonuh TDMcVDZ9u8AYlAWaYOfZ9tILMiLlGTa+DEO1QYmWkzByXkPXqid50AH7554GFrOWemM2 nDDyGIHAEHE8DEhB3IwXiiDllyH2mNa/wwKaJ2gbF7Qw5kPTSxSKaCgPM1pLoARyXyn7 vVQd/SxOtv7DXKhjf8RBu1KdWoSqHMCmImbWHqtm4cd20e1E3TH3nmWa90ZO5PhsE6RY Xa4KxpxpvqdfYabd+Y5meSWC+MjdTNWlaU9xLXCwktZHtIHB7ODrRZQ0UjJLNwvj1K36 OATQ== X-Gm-Message-State: ALQs6tBxCErtdNzNivtYdVeMuiyV0pwgjIn4RVMJ6KvSb4GtUL5aHn4P 2iJXt8jr2TkidhECbYEJH8WLes5NZt5PTTJOm8U= X-Google-Smtp-Source: AB8JxZogdYMjZoNqvpIm5AEs1pV4FiH6x8FukY9rFyGNLdk/BdsIloZxTJ0bAv/bUTQj6szY5c0H92s+ombo8vLWa5c= X-Received: by 2002:aca:1218:: with SMTP id 24-v6mr12752778ois.144.1525310509491; Wed, 02 May 2018 18:21:49 -0700 (PDT) MIME-Version: 1.0 References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> <7ed02fe1-69cc-f774-f61f-ee79f2e9a61d@alvestrand.no> In-Reply-To: From: Martin Thomson Date: Thu, 03 May 2018 01:21:38 +0000 Message-ID: To: Cullen Jennings Cc: Harald Alvestrand , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Thu, 03 May 2018 01:21:53 -0000 An IdP is given the origin of the requesting site. That allows it to make authorization decisions on that basis. For instance, it might request "login", but instead use that to do something similar to the OAuth authorization interstitial pages that are common with federated logins: " callsite.example.com wants to access your user@idp.example.net identity: [allow] [deny]". If callsite.example.com was then able to pass that along to others, that invalidates the basic assumption that the IdP has. There is also the principled position that says that private keys don't move, rather the point should be have every context have its own keys and to transfer properties to those keys. I'm not aware of any use case that can't be addressed by using indirection such that user X is known to have N keys rather than 1. (Those following this discussion might see similar thoughts echoed in < https://github.com/w3c/webrtc-pc/issues/1853>.) On Wed, May 2, 2018 at 11:34 PM Cullen Jennings wrote: > Ok - that makes sense. But it can only be transferred between two JS apps that trust each other and are trying to share it. This sounds like a feature not a bug. I=E2=80=99m still missing the problem with this. > > On May 2, 2018, at 1:54 AM, Martin Thomson wrote: > > > > Thanks for the correction Harald. I should have checked. > > > > The point is that postMessage can be used to move it around. Both > > structure cloning and Transferable enable that. (Transferable could indeed > > be preferable because then at least only one origin could use the object at > > the one time, but it's still not perfect.) > > On Wed, May 2, 2018 at 4:04 PM Harald Alvestrand > > wrote: > > > >> Den 02. mai 2018 01:54, skrev Martin Thomson: > >>> On Wed, May 2, 2018 at 1:47 AM Cullen Jennings wrote: > >>>> I=E2=80=99m not following how the private keys move between origins = - how does > >>> that happen ? Sorry that I missed that part of the thread. > >>> > >>> In order to enable saving of RTCCertificate to indexedDB and the like= , > > we > >>> made it Transferable. That means that origin X can use postMessage t= o > > send > >>> it to origin Y. That's the problem that was discovered during the > >>> hackathon. > >>> > >>> If our intent is to retain the ability to save, but not the ability t= o > >>> move, then binding RTCCertificate to a single origin would work. > > > > > >> Actually the RTCCertificate is not marked Transferable (there is no such > >> annotation), but it does support structured cloning (in prose). > > > > > >>> > >>> _______________________________________________ > >>> 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 From nobody Wed May 2 23:59:19 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 42F4C126B6E for ; Wed, 2 May 2018 23:59:13 -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=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 gtCPXhLkSTMX for ; Wed, 2 May 2018 23:59: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 87007127444 for ; Wed, 2 May 2018 23:59: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=1525330747; 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=exwYXOWsj+6YvbSlsZE64+Kq+WU4NqwVC7ML/43iDQc=; b=f+yPp0ODm7/yJjg21CeM5v0r68oLekxpIJ+Jhhi/Z2qyPo/mf07d4Jn5lH/6CIPZ k06oEXBuXgEbeOGUKKGQChuVdVSZvr2vk0zmpBfIp/v9PxMVWkqxL4s0lk7P6QXf 9cLTubUtmq2dVFHha38FMfr9S8kW4JeLe9xPrbL4JNg=; X-AuditID: c1b4fb3a-112a09c00000729c-11-5aeab33b248e Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DB.5F.29340.B33BAEA5; Thu, 3 May 2018 08:59:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0382.000; Thu, 3 May 2018 08:57:54 +0200 From: Christer Holmberg To: Ben Campbell , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" CC: mmusic WG , "ice@ietf.org" , "rtcweb@ietf.org" , The IESG Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4A= Date: Thu, 3 May 2018 06:57:54 +0000 Message-ID: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <68485975D94E4543A4EFBF0AC1E3BC2F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7ja715ldRBse7zCzmd55mt/ixdjmz xbcLtRYz/kxktji/cz2TxdTlj1ks1v5rZ3dg91iy5CeTx6ydT1gCmKK4bFJSczLLUov07RK4 Mib8XMBccF+vYkvnbMYGxilqXYycHBICJhKPJ29k6WLk4hASOMIo8f7RBihnEaPExTsv2boY OTjYBCwkuv9pg8RFBLYxStx495AJpJtZoF7i4fcuNhBbWKBAomfvfhYQW0SgUGLtjkdsEA2b GCVm3NoD1sAioCJx6vpMsCJeAWuJ/0svQ23r5ZL4vW8xWIJTwF5i85KXzCA2o4CYxPdTa6C2 iUvcejKfCeJuAYkle84zQ9iiEi8f/2MFsUUF9CQ2nLjNDnK1hICSxO0NThCtehLPTs1iAQkz A+3dOSkMIqwtsWzha2aIcwQlTs58wjKBUXwWkmWzkHTPQuiehaR7FpLuBYysqxhFi1OLi3PT jYz0Uosyk4uL8/P08lJLNjEC4/Pglt9WOxgPPnc8xCjAwajEw/tq46soIdbEsuLK3EOMEhzM SiK8U7qBQrwpiZVVqUX58UWlOanFhxilOViUxHmd0iyihATSE0tSs1NTC1KLYLJMHJxSDYy2 S65/3XP0u5nC3kkahZcXWMw57Fdxo1f83jm9tLa7OodExSq/fFP6G7dXsH76CnezYM8TVrv/ 7dITW3b3XfFe1cbLG6f8f1SYpPdptrJRT/zSmB13I6031k6a9TQ84fWM5POSL//43HrN8V9S T/6quqj3lakKk1qXLo0yv2kne5B1arq0+jx9JZbijERDLeai4kQAVnu5sssCAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Thu, 03 May 2018 06:59:14 -0000 Hi, >Adam, Ekr, and I spoke last week, and came to the conclusion that trying >to untangle all JSEP dependencies on SIP would require more effort than >is justified, and that the most expedient approach would to just fix the >currently orphaned JSEP references to point to >draft-ietf-mmusic-ice-sip-sdp. > >Adam has removed this point from his discuss, and has entered an RFC >editor note on JSEP to change the relevant references. (If anyone sees >JSEP references that will still be orphaned after applying that note, >please speak up asap.) FIRST, what do you mean by "relevant references"? Is there a list of the trickle references that is to be changed (draft-ice-trickle -> draft-mmusic-trickle) in JSEP, or do you assume ALL trickle references in JSEP will be changed? After a quick scan of JSEP, it seems like most of the references CAN be changed, but e.g., section 1.1 of JSEP says: "However, [I-D.ietf-mmusic-trickle-ice-sip] allows SIP to be used with trickle ICE [I-D.ietf-ice-trickle], in which the session description can be sent immediately and the transport information can be sent when available." If we are going to keep that sentence I assume the reference do draft-ietf-ice-trickle will stay. --- SECOND, in some cases it is not enough to simply change the reference, because the text in JSEP references specific section numbers, which are not the same in draft-ice-trickle and draft-music-trickle. Those section numbers need to be updated too (or removed completely), and I don't think the RFC editor is expected to figure out what the correct modified section numbers are? --- THIRD, bringing up an old pending issue related to this, I think we should now also change the core ICE reference in JSEP from RFC5245 to draft-5245bis. Draft-5245bis is now in the RFC editor's queue, and I think the MISREFs for 5245bis and JSEP are more or less the same, so I don't think 5245bis is going to delay the publication of JSEP. --- Regards, Christer >> On Apr 15, 2018, at 2:16 AM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >>> Yes. The question is whether to just move the references in JSEP to >>>point to mmusic-trickle-sip, or do something different. >>=20 >> I think it would be good to have a list of all the reference instances >>that need to be modified. >>=20 >> Regards, >>=20 >> Christer >>=20 >>> On Apr 13, 2018, at 1:29 PM, Christer Holmberg >>> wrote: >>>=20 >>> Hi, >>>=20 >>> In addition, as I mentioned earlier, there are cases where JSEP >>>references draft-ice-trickle for things and procedures that don't exist >>>in draft-ice-trickle. Instead those references should be to >>>draft-mmusic-trickle. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> Sent from my iPhone >>>=20 >>> On 13 Apr 2018, at 17.56, Ben Campbell wrote: >>>=20 >>>>=20 >>>>=20 >>>>> On Apr 13, 2018, at 7:06 AM, Christer Holmberg >>>>> wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>>>> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre >>>>>>> >>>>>>> wrote: >>>>>>>=20 >>>>>>> On 4/3/18 2:41 PM, Suhas Nandakumar wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre >>>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> On 4/3/18 12:27 PM, Suhas Nandakumar wrote: >>>>>>>>>> Just to complete, ice-bis doesn=B1t normatively reference >>>>>>>>>> ice-sip-SDP draft when it moved to using =B3usages =B3 indirecti= ons >>>>>>>>>> for signaling protocols. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Trickle ice can use similar approach and refer to trickle-sip >>>>>>>>>> as usage for trickle. >>>>>>>>>=20 >>>>>>>>> It already does. That's why we pulled all the SDP/SIP stuff out >>>>>>>>> of draft-ietf-ice-trickle. >>>>>>>>=20 >>>>>>>> I assume Suhas meant separating the SDP stuff from the SIP >>>>>>>> stuff. (I also assume he will correct me if I am wrong.) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> That's right Ben .. I was just thinking minimal localized changes >>>>>>>> (thus small time to get new draft done) and then asking trickle, >>>>>>>> trickle-sip to refer to the new one. (work done to refer is much >>>>>>>> smaller for these drafts that are at the very end of approval >>>>>>>> journey) >>>>>>>>=20 >>>>>>>> I do agree with Adam, no matter what version of the proposal we >>>>>>>> pick, there is some work that needs to be done and we should do >>>>>>>> it. >>>>>>>=20 >>>>>>> These documents are on the telechat tomorrow. Are we proposing to >>>>>>> delay consideration by the IESG while we get this mess sorted out? >>>>>>> ;-) >>>>>>=20 >>>>>> Hi Peter, >>>>>>=20 >>>>>> I currently plan to leave it on. We may discuss a way forward on >>>>>> the telechat. Also, I=B1d like to get feedback on the rest of the >>>>>> draft(s) from the other ADs sooner than later. >>>>>=20 >>>>> Did you discuss this at the telechat? >>>>>=20 >>>>> Any other discussions on how to move forward with this? >>>>=20 >>>> Yes, Adam and I have been discussing this with the RTCWEB chairs. >>>>We've since discovered that this is not the only JSEP normative >>>>reference chain back to SIP. The RTCWEB chairs are currently >>>>discussing whether they can live with that. They may decide to just >>>>reference things as they stand. If their answer involves a request to >>>>restructure anything, I will pull in the authors and MMUSIC/ICE chairs. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu May 3 04:39:49 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 6527B12E89B for ; Thu, 3 May 2018 04:39:31 -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 rx1CmAVG9VR5 for ; Thu, 3 May 2018 04:39:28 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 8410A12D961 for ; Thu, 3 May 2018 04:39:22 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id 77-v6so20212151otd.4 for ; Thu, 03 May 2018 04:39:22 -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=eMT1NrpByUmjGu/QQBl2myrUNBjEsWTXDLphRi7K69s=; b=HMxOy6EQrQuIqESlMAN8HcvmDTcCGjU0BnHh8LM8WJTUmDtXuaRQ/S8TpV9A7hpbPp ptjgk92+n8NfVX0pfRPR6rVKU79rMxXXwrC/GKn7nJxiT64lv6/0bQluPgWx/zvxdXVw /Gfnh6jyk/w4qU3B95tmsRCL7w3mxAX9VnCIPkoBzs1RH6nRp38CGsTyZ3VD83V5WMpc M3qQVqszgTfpk4vy87u5NzNyRgLEK9EIH1C1VdHZbJLGgtLCIbZg+QivqbE9rvFM7AWJ /SSm03DaZaJCHSTHjaMzIaKiH+PfQ8tx3G0JkNLmDXj9ELwCmtdY8Ytdy2j7Ylp52HNr mFIA== 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=eMT1NrpByUmjGu/QQBl2myrUNBjEsWTXDLphRi7K69s=; b=c23nIxuReiPFmdQNUIoRTojve0dCyNqvT2GvrBFhQfxywa78HADsTtbP0z9Io8qGBF k7JiNrSc2eDiQ9u+dD0JEJ7fY3m5FBsLBGX6X0n91YeZtTfSX9hY7VANWHJ7VjgR0NoP l+/+8TGkB68RCwoXX09+xEA7nJNBUVugN9ALaSKtP5FUd3CykTyJ++uAOgdl7bWCP40P oX66j7BgC3v9DvjqtgkcVjdlcb83EO4veU3wTrOWl/wYhmuz2G3pn6ahvhDcdYrZtNiE VQCXgRqYWMvMFpP0cxjTfFPCfhxCHwBnddHqv59CtNfaOiB1Fq4qk20uku/oMo/Dx0i6 Qclw== X-Gm-Message-State: ALQs6tClObPsMSTK7OeW/WZVFx8bxoVyg3/8x56dG4cvjk1O3Yd0QzWH tXrkUCScg7eV38tK5+puaoXPHlyZYseE1nS5Ks2DlA== X-Google-Smtp-Source: AB8JxZrBUavVkX/XNZ7d1ZKjMW4DQpMWc3z2lFQHEqzY2fQY/NjmEEOBCDxN3LLAZHcIDHpG8WyyRxXBQb6O6Ey3Ly4= X-Received: by 2002:a9d:5917:: with SMTP id t23-v6mr13300567oth.217.1525347561873; Thu, 03 May 2018 04:39:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 04:38:41 -0700 (PDT) In-Reply-To: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Thu, 3 May 2018 04:38:41 -0700 Message-ID: To: Christer Holmberg Cc: Ben Campbell , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" , The IESG , "rtcweb@ietf.org" , mmusic WG , "ice@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095aeec056b4ba7aa" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Thu, 03 May 2018 11:39:44 -0000 --00000000000095aeec056b4ba7aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 2, 2018 at 11:57 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >Adam, Ekr, and I spoke last week, and came to the conclusion that trying > >to untangle all JSEP dependencies on SIP would require more effort than > >is justified, and that the most expedient approach would to just fix the > >currently orphaned JSEP references to point to > >draft-ietf-mmusic-ice-sip-sdp. > > > >Adam has removed this point from his discuss, and has entered an RFC > >editor note on JSEP to change the relevant references. (If anyone sees > >JSEP references that will still be orphaned after applying that note, > >please speak up asap.) > > FIRST, what do you mean by "relevant references"? Is there a list of the > trickle references that is to be changed (draft-ice-trickle -> > draft-mmusic-trickle) in JSEP, or do you assume ALL trickle references in > JSEP will be changed? > > After a quick scan of JSEP, it seems like most of the references CAN be > changed, but e.g., section 1.1 of JSEP says: > > "However, [I-D.ietf-mmusic-trickle-ice-sip] > allows SIP to be used with trickle ICE [I-D.ietf-ice-trickle], in > which the session description can be sent immediately and the > transport information can be sent when available." > > > If we are going to keep that sentence I assume the reference do > draft-ietf-ice-trickle will stay. > > --- > > SECOND, in some cases it is not enough to simply change the reference, > because the text in JSEP references specific section numbers, which are > not the same in draft-ice-trickle and draft-music-trickle. Those section > numbers need to be updated too (or removed completely), and I don't think > the RFC editor is expected to figure out what the correct modified sectio= n > numbers are? > > --- > > > THIRD, bringing up an old pending issue related to this, I think we shoul= d > now also change the core ICE reference in JSEP from RFC5245 to > draft-5245bis. Draft-5245bis is now in the RFC editor's queue, and I thin= k > the MISREFs for 5245bis and JSEP are more or less the same, so I don't > think 5245bis is going to delay the publication of JSEP. > This isn't simply an issue of what we reference but which protocol we expect people to implement, as they are non-identical. -Ekr > --- > > Regards, > > Christer > > > > >> On Apr 15, 2018, at 2:16 AM, Christer Holmberg > >> wrote: > >> > >> Hi, > >> > >>> Yes. The question is whether to just move the references in JSEP to > >>>point to mmusic-trickle-sip, or do something different. > >> > >> I think it would be good to have a list of all the reference instances > >>that need to be modified. > >> > >> Regards, > >> > >> Christer > >> > >>> On Apr 13, 2018, at 1:29 PM, Christer Holmberg > >>> wrote: > >>> > >>> Hi, > >>> > >>> In addition, as I mentioned earlier, there are cases where JSEP > >>>references draft-ice-trickle for things and procedures that don't exis= t > >>>in draft-ice-trickle. Instead those references should be to > >>>draft-mmusic-trickle. > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> Sent from my iPhone > >>> > >>> On 13 Apr 2018, at 17.56, Ben Campbell wrote: > >>> > >>>> > >>>> > >>>>> On Apr 13, 2018, at 7:06 AM, Christer Holmberg > >>>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>>> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre > >>>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>> On 4/3/18 2:41 PM, Suhas Nandakumar wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre > >>>>>>>>> > wrote: > >>>>>>>>> > >>>>>>>>> On 4/3/18 12:27 PM, Suhas Nandakumar wrote: > >>>>>>>>>> Just to complete, ice-bis doesn=C4=85t normatively reference > >>>>>>>>>> ice-sip-SDP draft when it moved to using =C5=82usages =C5=82 i= ndirections > >>>>>>>>>> for signaling protocols. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Trickle ice can use similar approach and refer to trickle-sip > >>>>>>>>>> as usage for trickle. > >>>>>>>>> > >>>>>>>>> It already does. That's why we pulled all the SDP/SIP stuff out > >>>>>>>>> of draft-ietf-ice-trickle. > >>>>>>>> > >>>>>>>> I assume Suhas meant separating the SDP stuff from the SIP > >>>>>>>> stuff. (I also assume he will correct me if I am wrong.) > >>>>>>>> > >>>>>>>> > >>>>>>>> That's right Ben .. I was just thinking minimal localized change= s > >>>>>>>> (thus small time to get new draft done) and then asking trickle, > >>>>>>>> trickle-sip to refer to the new one. (work done to refer is much > >>>>>>>> smaller for these drafts that are at the very end of approval > >>>>>>>> journey) > >>>>>>>> > >>>>>>>> I do agree with Adam, no matter what version of the proposal we > >>>>>>>> pick, there is some work that needs to be done and we should do > >>>>>>>> it. > >>>>>>> > >>>>>>> These documents are on the telechat tomorrow. Are we proposing to > >>>>>>> delay consideration by the IESG while we get this mess sorted out= ? > >>>>>>> ;-) > >>>>>> > >>>>>> Hi Peter, > >>>>>> > >>>>>> I currently plan to leave it on. We may discuss a way forward on > >>>>>> the telechat. Also, I=C4=85d like to get feedback on the rest of t= he > >>>>>> draft(s) from the other ADs sooner than later. > >>>>> > >>>>> Did you discuss this at the telechat? > >>>>> > >>>>> Any other discussions on how to move forward with this? > >>>> > >>>> Yes, Adam and I have been discussing this with the RTCWEB chairs. > >>>>We've since discovered that this is not the only JSEP normative > >>>>reference chain back to SIP. The RTCWEB chairs are currently > >>>>discussing whether they can live with that. They may decide to just > >>>>reference things as they stand. If their answer involves a request to > >>>>restructure anything, I will pull in the authors and MMUSIC/ICE chair= s. > >>>> > >>>> Thanks! > >>>> > >>>> Ben. > >>>> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > > --00000000000095aeec056b4ba7aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 2, 2018 at 11:57 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

>Adam, Ekr, and I spoke last week, and came to the conclusion that tryin= g
>to untangle all JSEP dependencies on SIP would require more effort than=
>is justified, and that the most expedient approach would to just fix th= e
>currently orphaned JSEP references to point to
>draft-ietf-mmusic-ice-sip-sdp.
>
>Adam has removed this point from his discuss, and has entered an RFC >editor note on JSEP to change the relevant references. (If anyone sees<= br> >JSEP references that will still be orphaned after applying that note, >please speak up asap.)

FIRST, what do you mean by "relevant references"? Is there= a list of the
trickle references that is to be changed (draft-ice-trickle ->
draft-mmusic-trickle) in JSEP, or do you assume ALL trickle references in JSEP will be changed?

After a quick scan of JSEP, it seems like most of the references CAN be
changed, but e.g., section 1.1 of JSEP says:

=C2=A0 "However, [I-D.ietf-mmusic-trickle-ice-sip]
=C2=A0 =C2=A0allows SIP to be used with trickle ICE [I-D.ietf-ice-trickle],= in
=C2=A0 =C2=A0which the session description can be sent immediately and the<= br> =C2=A0 =C2=A0transport information can be sent when available."


If we are going to keep that sentence I assume the reference do
draft-ietf-ice-trickle will stay.

---

SECOND, in some cases it is not enough to simply change the reference,
because the text in JSEP references specific section numbers, which are
not the same in draft-ice-trickle and draft-music-trickle. Those section numbers need to be updated too (or removed completely), and I don't thi= nk
the RFC editor is expected to figure out what the correct modified section<= br> numbers are?

---


THIRD, bringing up an old pending issue related to this, I think we should<= br> now also change the core ICE reference in JSEP from RFC5245 to
draft-5245bis. Draft-5245bis is now in the RFC editor's queue, and I th= ink
the MISREFs for 5245bis and JSEP are more or less the same, so I don't<= br> think 5245bis is going to delay the publication of JSEP.

This isn't simply an issue of what we reference but w= hich protocol we expect people
to implement, as they are non-iden= tical.

-Ekr


---

Regards,

Christer



>> On Apr 15, 2018, at 2:16 AM, Christer Holmberg
>><christer.holm= berg@ericsson.com> wrote:
>>
>> Hi,
>>
>>> Yes. The question is whether to just move the references in JS= EP to
>>>point to mmusic-trickle-sip, or do something different.
>>
>> I think it would be good to have a list of all the reference insta= nces
>>that need to be modified.
>>
>> Regards,
>>
>> Christer
>>
>>> On Apr 13, 2018, at 1:29 PM, Christer Holmberg
>>><christer.= holmberg@ericsson.com> wrote:
>>>
>>> Hi,
>>>
>>> In addition, as I mentioned earlier, there are cases where JSE= P
>>>references draft-ice-trickle for things and procedures that don= 't exist
>>>in draft-ice-trickle. Instead those references should be to
>>>draft-mmusic-trickle.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> Sent from my iPhone
>>>
>>> On 13 Apr 2018, at 17.56, Ben Campbell <ben@nostrum.com> wrote:
>>>
>>>>
>>>>
>>>>> On Apr 13, 2018, at 7:06 AM, Christer Holmberg
>>>>><c= hrister.holmberg@ericsson.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre=
>>>>>>> <stp= eter@mozilla.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 4/3/18 2:41 PM, Suhas Nandakumar wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campb= ell <ben@nostrum.com
>>>>>>>> <mailto:ben@nostrum.com>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Apr 3, 2018, at 2:20 PM, Peter Sain= t-Andre
>>>>>>>>> <stpeter@mozilla.com <mailto:stpeter@mozilla.com>> wrote:
>>>>>>>>>
>>>>>>>>> On 4/3/18 12:27 PM, Suhas Nandakumar w= rote:
>>>>>>>>>> Just to complete, ice-bis doesn=C4= =85t normatively reference
>>>>>>>>>> ice-sip-SDP draft when it moved to= using =C5=82usages =C5=82 indirections
>>>>>>>>>> for signaling protocols.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Trickle ice can use similar approa= ch and refer to trickle-sip
>>>>>>>>>> as usage for trickle.
>>>>>>>>>
>>>>>>>>> It already does. That's why we pul= led all the SDP/SIP stuff out
>>>>>>>>> of draft-ietf-ice-trickle.
>>>>>>>>
>>>>>>>> I assume Suhas meant separating the SDP st= uff from the SIP
>>>>>>>> stuff. (I=C2=A0 also assume he will correc= t me if I am wrong.)
>>>>>>>>
>>>>>>>>
>>>>>>>> That's right Ben .. I was just thinkin= g minimal localized changes
>>>>>>>> (thus small time to get new draft done) an= d then asking trickle,
>>>>>>>> trickle-sip to refer to the new one. (work= done to refer is much
>>>>>>>> smaller for these drafts that are at the v= ery end of approval
>>>>>>>> journey)
>>>>>>>>
>>>>>>>> I do agree with Adam, no matter what versi= on of the proposal we
>>>>>>>> pick, there is some work that needs to be = done and we should do
>>>>>>>> it.
>>>>>>>
>>>>>>> These documents are on the telechat tomorrow. = Are we proposing to
>>>>>>> delay consideration by the IESG while we get t= his mess sorted out?
>>>>>>> ;-)
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> I currently plan to leave it on. We may discuss a = way forward on
>>>>>> the telechat. Also, I=C4=85d like to get feedback = on the rest of the
>>>>>> draft(s) from the other ADs sooner than later.
>>>>>
>>>>> Did you discuss this at the telechat?
>>>>>
>>>>> Any other discussions on how to move forward with this= ?
>>>>
>>>> Yes, Adam and I have been discussing this with the RTCWEB = chairs.
>>>>We've since discovered that this is not the only JSEP n= ormative
>>>>reference chain back to SIP. The RTCWEB chairs are currentl= y
>>>>discussing whether they can live with that. They may decide= to just
>>>>reference things as they stand. If their answer involves a = request to
>>>>restructure anything, I will pull in the authors and MMUSIC= /ICE chairs.
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmus= ic
>


--00000000000095aeec056b4ba7aa-- From nobody Thu May 3 04:59:02 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 6FE67126B72 for ; Thu, 3 May 2018 04:59:01 -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 18xihIe_p2OX for ; Thu, 3 May 2018 04:58:59 -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 28B82124E15 for ; Thu, 3 May 2018 04:58:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id ACBBC7C3E8B for ; Thu, 3 May 2018 13:58: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 M77xaEWWAjI6 for ; Thu, 3 May 2018 13:58:57 +0200 (CEST) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id E1DDD7C3B7B for ; Thu, 3 May 2018 13:58:56 +0200 (CEST) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: Date: Thu, 3 May 2018 13:58:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Moving Identity tokens between contexts 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: Thu, 03 May 2018 11:59:01 -0000 To make sure we're all on the same page: The identity token is a JSON blob - ie a string. There's absolutely no way to prevent the page from passing it to anyone it wants to pass it to - and there shouldn't be. In contrast, the RTCCertificate is an object with an interface that has a specific guarantee: "No mechanism is provided for applications to access the [[KeyingMaterial]] internal slot." and therefore this further statement can be made to implementors: "In implementations where an RTCCertificate might not directly hold private keying material (it might be stored in a secure module), a reference to the private key can be held in the [[KeyingMaterial]] internal slot, allowing the private key to be stored and used." I think it doesn't make sense to move such an object between origins. We might want to state that explictly. (But that's a W3C issue, so ought to be addressed to a different list.) From nobody Thu May 3 05:01:40 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 AC63312DA07 for ; Thu, 3 May 2018 05:01:29 -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=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 3k71bsGjiBTJ for ; Thu, 3 May 2018 05:01:27 -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 5EBCA12D9FF for ; Thu, 3 May 2018 05:01: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=1525348874; 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=vDnn1jCtWz5ciivWYs5dqubW97MpCB6qUg4fMDLzPLk=; b=CiTCxMiC9zgmTjpUAsAvbH0Mw4+jNN9ZSDv++cJJqGm9S0OZQNmbiJLGlRAc2swE tcqg6fsSJXhp77/BdZdO+8Q6JgFfe4ftR7TWSGEY9Pw7vFcqG7iWZddkoVYi7XX6 rfQpSh/NUJSV6bQk+/CjXQf84ChPJR3UvxxHvG0uUwA=; X-AuditID: c1b4fb2d-ea2cf9c0000055bf-39-5aeafa0ab272 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0E.22.21951.A0AFAEA5; Thu, 3 May 2018 14:01:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0382.000; Thu, 3 May 2018 14:00:17 +0200 From: Christer Holmberg To: Eric Rescorla CC: Ben Campbell , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" , The IESG , "rtcweb@ietf.org" , mmusic WG , "ice@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4CAABtpgIAAORYA Date: Thu, 3 May 2018 12:00:18 +0000 Message-ID: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: multipart/alternative; boundary="_000_D710D4872F31Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUyM2K7hy7Xr1dRBgeeGVrM7zzNbvFj7XJm ixWvz7FbfLtQazHjz0Rmi/M71zNZTF3+mMVi7b92dgcOjyVLfjJ5zNr5hMVj8uM25gDmKC6b lNSczLLUIn27BK6Mea3XWQpO8lZ0TnRrYDzJ3cXIySEhYCJx68R1li5GLg4hgSOMEm/+LWYE SQgJLGKU2HjQvouRg4NNwEKi+582SFhEQEHi158TYPXMApuZJF7e7mMCSQgLFEj07N3PAlFU KLF2xyM2kCIRgX2MEmvefGEDSbAIqEhcPfIdrIFXwFpi8p8brBDL2rglTu43BrE5BQIlNjbt ZwexGQXEJL6fWgNWzywgLnHryXwmiKsFJJbsOc8MYYtKvHz8D2yOqICexIYTt9lBjpYQUJK4 vcEJojVB4tTDg2wQawUlTs58wjKBUXQWkqmzkJTNQlIGETeQeH9uPjOErS2xbOFrKFtfYuOX s4wQtrXE0/8T2JHVLGDkWMUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGMkHt/zW3cG4+rXj IUYBDkYlHt6aV6+ihFgTy4orcw8xSnAwK4nwTukGCvGmJFZWpRblxxeV5qQWH2KU5mBREufV W7UnSkggPbEkNTs1tSC1CCbLxMEp1cCY6645afWmQ1O/CL0NnifQJ7IseH/H/Wo2E0MDvuYj r0U3qAhfCBI16PomNlnwQFb46YbPsucVXvHHnLO0DYwSSPu/xr5p//LZ7nL+T2WKDG8XKS43 lj5mPmPd9zwGztkzXmw76BLar+NfoL347sotNVbGMz8/Wp/Rd5r/13u/loUxsvsYl4YosRRn JBpqMRcVJwIAaVIZOOACAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Thu, 03 May 2018 12:01:30 -0000 --_000_D710D4872F31Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, > This isn't simply an issue of what we reference but which protocol we exp= ect people > to implement, as they are non-identical. Sure. But, my comment was on Ben=92s message that we=92ll ask the RFC edito= r to change the references. Regards, Christer --_000_D710D4872F31Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <23E8A6C7E0BCD9478E0C868DE94AD425@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

> This isn't simply an issue of what we reference but which protoco= l we expect people
> to implement, as they are non-identical.

Sure. But, my comment was on Ben=92s message that we=92ll ask the RFC = editor to change the references.

Regards,

Christer

 --_000_D710D4872F31Bchristerholmbergericssoncom_-- From nobody Thu May 3 05:03: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 D1E0E1200B9 for ; Thu, 3 May 2018 05:02:56 -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 pDgA6xo7I7_z for ; Thu, 3 May 2018 05:02:55 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 16ECE12D965 for ; Thu, 3 May 2018 05:02:53 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id i5-v6so8612429otf.1 for ; Thu, 03 May 2018 05:02:53 -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=Q8rodrA0f0iqtigLmXK5+vweUgiYodSReI4LwmpkUaA=; b=uflFAQ/9rnIaq216nTzVVEclDODs9rAbjXISGsvmVDtKn/4jSO+2zqF4UKDr38cEw1 nitrpvIfXqM78Po3h6pPa47GlnDPlxg/I6E+wF4yMCfDunvUIZ7E0cF28jISujRWh6Qn EVbrcYBfJ8QyX9LI6dWpurEDh5MVidQNxWDNDm1fLJE6wcVxtLsnnQ4yr0Rc0Z4XEr5n GKE8kfoR0uZaBVwpr1yvjvs32xQWtWtoNdT6g36KJB+Dl/KQ7txBnBluB6sS/l+l3nhU FrW1DgYNN4C3cGObk7W2DhIDBWOoX8b4oHAO8RLkzc8kDTibZ0+eTUmEYk0kAGRb6fZq WTXw== 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=Q8rodrA0f0iqtigLmXK5+vweUgiYodSReI4LwmpkUaA=; b=rKzp4aWL/YOyESfYOXrpiLoR5yNPfSDIYdXuJUHnSeJ2dokC2VAuTMrgfSgU2YfXAJ A6Vq4gD54cAhmMTLfPWvEtJbv6PZS1f7gS1tZTpqdIL9XmyQEx0z0eULQ5bso00W0HP1 mUNrP+KtXPFDmGC7oREG02xRW7LjJfV0BIEu0G1KezFzcYuHfoNnGpnDcy6ex+LQNMSq 6i20hDzDOKSOCHiKRpIa1/jBNFEKIezgPYXW95gvV30Qfxd3kH4c9sHZkd0jNr0XYv8V kxGuDr3UzbtrdnHCtWQ43C1mj+daf5TN7CpyC8HCCS4QbLkwAP1kLwr9VrdkGs9a3Dtw 5jPQ== X-Gm-Message-State: ALQs6tDXluu+KAtl+z8NBwDazYoP/QNP2T3cPZVbiMoGMojXdQ1y7sDD 45U2fdr5UQVpr+RemiOKPKrWy4I/l2Ik3KRi/z19qA== X-Google-Smtp-Source: AB8JxZoSe5jmLsB0exSsBUDBgr2WhhyC7r/ijBe5T1I7wWrnsGEIdsPxLGhskIhzk5tuSJacxD206Ji53u2Vzm2ZTww= X-Received: by 2002:a9d:3694:: with SMTP id h20-v6mr1058994otc.176.1525348972412; Thu, 03 May 2018 05:02:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 05:02:11 -0700 (PDT) In-Reply-To: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Thu, 3 May 2018 05:02:11 -0700 Message-ID: To: Christer Holmberg Cc: Ben Campbell , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" , The IESG , "rtcweb@ietf.org" , mmusic WG , "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a8d914056b4bfb76" Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Thu, 03 May 2018 12:02:57 -0000 --000000000000a8d914056b4bfb76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 3, 2018 at 5:00 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > This isn't simply an issue of what we reference but which protocol we > expect people > > to implement, as they are non-identical. > > Sure. But, my comment was on Ben=E2=80=99s message that we=E2=80=99ll ask= the RFC editor > to change the references. > But changing the ICE reference *also* changes the protocol. -Ekr Regards, > > Christer > > --000000000000a8d914056b4bfb76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 3, 2018 at 5:00 AM, Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:
Hi,

> This isn't simply an issue of what we reference but which pro= tocol we expect people
> to implement, as they are non-identical.

Sure. But, my comment was on Ben=E2=80=99s message that we=E2= =80=99ll ask the RFC editor to change the references.

But changing the ICE reference *also= * changes the protocol.

-Ekr

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Regards,

Christer

--000000000000a8d914056b4bfb76-- From nobody Thu May 3 05:17: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 CC2BD12DA41 for ; Thu, 3 May 2018 05:17:24 -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=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 rmbbZXbEBcQJ for ; Thu, 3 May 2018 05:17:18 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78B512D96C for ; Thu, 3 May 2018 05:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525349834; 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=oFdKkbCMq2LErOm4feSuPu7yDiJ1v+6rQV9217nRSGI=; b=WdeCtvebxR+HzKw5gm4X3sQ/uE0g9Y9TD3T3NDl0YX1rYcEilkRSbuzrWuu2bXKe RkqW1NkK2U2/p1xPdoxNzqKnrRiEVUJCXOCQ7dOsHdyV01MZlcgAJHCs7GgmT3N/ kggtH7+PDHKkR/J22T+vHM3x8no2KuGrneYKSs5RzIQ=; X-AuditID: c1b4fb3a-112a09c00000729c-45-5aeafdca2263 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.A6.29340.9CDFAEA5; Thu, 3 May 2018 14:17:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Thu, 3 May 2018 14:16:32 +0200 From: Christer Holmberg To: Eric Rescorla CC: Ben Campbell , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" , The IESG , "rtcweb@ietf.org" , mmusic WG , "ice@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4CAABtpgIAAORYA///Ne4AABuHFAA== Date: Thu, 3 May 2018 12:16:31 +0000 Message-ID: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: multipart/alternative; boundary="_000_D710D7D42F328christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsUyM2K7ou6pv6+iDJ6t5bWY33ma3eLH2uXM Fiten2O3+Hah1mLGn4nMFud3rmeymLr8MYvF2n/t7A4cHkuW/GTymLXzCYvH5MdtzAHMUVw2 Kak5mWWpRfp2CVwZO2/vZivYKlhx4uR7lgbGL3xdjJwcEgImEmtvTGHrYuTiEBI4wiixZP8Z ZghnEaPE75P9rF2MHBxsAhYS3f+0QRpEBBQkfv05wQJSwyywmUni5e0+JpCEsECBRM/e/SwQ RYUSa3c8ApsqInCOUeL60U/MIAkWARWJ7q7dbCBDeQWsJd6fl4JY9p9b4uqWbWA1nAKBElsf /WEEsRkFxCS+n1oDtoBZQFzi1pP5TBBnC0gs2XOeGcIWlXj5+B8riC0qoCex4cRtdpD5EgJK Erc3OEG0Jki0HjnABmLzCghKnJz5hGUCo+gsJFNnISmbhaQMIm4g8f7cfGYIW1ti2cLXULa+ xMYvZxkhbGuJr41n2JDVLGDkWMUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGM0Ht/y22sF4 8LnjIUYBDkYlHl6LV6+ihFgTy4orcw8xSnAwK4nwTukGCvGmJFZWpRblxxeV5qQWH2KU5mBR Eud1SrOIEhJITyxJzU5NLUgtgskycXBKNTCasF39XtTSYXfo/6EHgk1frm7lqNigYGXD+nJf 0MU7CeJfbMuKO6qk/sYkK/Ot/rgg8WnsWUNZ8zLTLzlJL6ynHHivuGeBQxxHiqBURfTF6oun UzRttEy9rUW9/8yyEF5l1vA3VfalwsFwgfmeOiITV3L87On3Wm6/SDH4hd7XEvmY2cYTuZRY ijMSDbWYi4oTASFrON/iAgAA Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Thu, 03 May 2018 12:17:27 -0000 --_000_D710D7D42F328christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >> This isn't simply an issue of what we reference but which protocol we ex= pect people >> to implement, as they are non-identical. > > Sure. But, my comment was on Ben=92s message that we=92ll ask the RFC edi= tor to change the references. > > But changing the ICE reference *also* changes the protocol. Fair enough. My suggestion is that we do that change. Regards, Christer --_000_D710D7D42F328christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>> This isn't simply an issue of what we reference but which pro= tocol we expect people
>> to implement, as they are non-identical.
>
> Sure. But, my comment was on Ben=92s message that we=92ll ask the= RFC editor to change the references.
>
> But changing the ICE reference *also* changes the protocol.

Fair enough. My suggestion is that we do that change.

Regards,

Christer


--_000_D710D7D42F328christerholmbergericssoncom_-- From nobody Thu May 3 09:32: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 5863312E885; Thu, 3 May 2018 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 QAiF4CixcOHS; Thu, 3 May 2018 09:32:19 -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 E32A3128D2E; Thu, 3 May 2018 09:32:18 -0700 (PDT) Received: from [10.0.1.86] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w43GWDqg025829 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 May 2018 11:32:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.86] From: Ben Campbell Message-Id: <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4DDBD498-2C88-47F6-85D9-79BEBAF44028"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 3 May 2018 11:32:12 -0500 In-Reply-To: Cc: Eric Rescorla , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" , The IESG , "rtcweb@ietf.org" , mmusic WG , "ice@ietf.org" To: Christer Holmberg References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Thu, 03 May 2018 16:32:21 -0000 --Apple-Mail=_4DDBD498-2C88-47F6-85D9-79BEBAF44028 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christer, Have you looked at the RFC editor note Adam entered for jsep? https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/writeup/ (scoll = down) > On May 3, 2018, at 7:00 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > > This isn't simply an issue of what we reference but which protocol = we expect people > > to implement, as they are non-identical. >=20 > Sure. But, my comment was on Ben=E2=80=99s message that we=E2=80=99ll = ask the RFC editor to change the references. >=20 > Regards, >=20 > Christer >=20 --Apple-Mail=_4DDBD498-2C88-47F6-85D9-79BEBAF44028 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrrOYwACgkQgFZKbJXz 1A02chAAiZ4Xq0Lwjeh5y1pFJ9hZqSXIQqevEsMbKd0GByC3ky4ORqWhXwLvCKjx xAv00KEwEbtM/2qaRGp8WO0/xCt18BGgIUePjYSCvTJV02jVH2/KUFxPxo6vln/G AQLdNPyq9R8yd2CnyPuzObHzbam+BiSHv9LO21caBiC6+4u88+PSgepQdZ+RjAyc bu5ZH4gzdTCQ5ZJ9bS45HSXYrDKfPi0hpsKuoPMCEz3bPQ7ltchafTC/oRYkluWQ GXTWRnRck8fkIZPHismA/bOAeZ8LKQFOcYiZPeViSAO/sob+rx1YIpDKvsYtQuO1 /rJZu50RGCcxpwg82N14O6rXJkFXlXxbtyBsnwbqCVcG0ebL+0Z1m4p1GQTOXpyX NW2WFHGdorEbMndO7rf3UTZXXdubu1isOTxrFtIWWoXaMKtnpQIUAzUmTrRo3KeI 23AuQ2V5VK2nEcghMlH75ds2uTGZDR32KXgwLD2nNI7tGWa6vj1y6Wt9U1ZkT8NS hLe2oKxnKU0kRCZt0l3zs7HqnsPzTXjFmYwAuhF3CUm0nKxHdYX/1ou0NP/hq2HD /+rlpec7Uc5F2w2FJAEzv7kMWakniXlVQj05qAM++05uEsjKRuq8ueBK7oyAA78B sZzAGU5TMmR+a+/paKt0pBr1V6JVQ1KKFClDktrCvhohOxSDamY= =PIJy -----END PGP SIGNATURE----- --Apple-Mail=_4DDBD498-2C88-47F6-85D9-79BEBAF44028-- From nobody Thu May 3 10:34: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 D888312EAA7 for ; Thu, 3 May 2018 10:34:18 -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=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 9Iz9CLAws72g for ; Thu, 3 May 2018 10:34:17 -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 8728F12EAB7 for ; Thu, 3 May 2018 10:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525368847; 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=FeUt9MyvJyHyicBIDtc7cW5XW/Q7a2K7wvtaXYxT++I=; b=Awfuh+lWi8YfuRY/tq9ZYpd4PNraysFwzgC0CL0Bf3pbe1SPDZvUjRY6l1EDp/1D EqsRtTYWmHGDvdUU/H/PWsi863XieTZTRWdufYpj89+r/SWLjLPYi8SMKq4EsTLp G++hCqixhoV4wmX6AgilWnpgyEySoK3EE/e4NQcKtZk=; X-AuditID: c1b4fb3a-112a09c00000729c-ed-5aeb480eeafc Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A0.6B.29340.E084BEA5; Thu, 3 May 2018 19:34:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0382.000; Thu, 3 May 2018 19:32:36 +0200 From: Christer Holmberg To: Ben Campbell CC: Eric Rescorla , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" , The IESG , "rtcweb@ietf.org" , mmusic WG , "ice@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4CAABtpgIAAORYAgAAY7ACAADI8QA== Date: Thu, 3 May 2018 17:32:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> In-Reply-To: <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7sS6/x+sog2cH2Szmd55mt/ixdjmz xYrX59gtvl2otZjxZyKzxfmd65kspi5/zGKx9l87uwOHx5IlP5k8Zu18wuIx+XEbcwBzFJdN SmpOZllqkb5dAldG874dLAUN7BUzj59na2B8wdbFyMkhIWAisalzKhOILSRwhFHicWNAFyMX kL2IUeLEt5lACQ4ONgELie5/2iA1IgJKEs+bt7KA1DALrGeS6JiwDqxZWKBAYuOcVjaIokKJ tTseQdnnGCW2LrAEsVkEVCRm7DsKFucV8JW4tb6TDWLZW26J1nevWUASnAL2EsfPXgErYhQQ k/h+ag3YAmYBcYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtpLE0/9LwI5mFtCUWL9LH6JVUWJK 90N2iL2CEidnPmGZwCg6C8nUWQgds5B0zELSsYCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5q ySZGYKQd3PLbagfjweeOhxgFOBiVeHhd9F5HCbEmlhVX5h5ilOBgVhLhjVECCvGmJFZWpRbl xxeV5qQWH2KU5mBREud1SrOIEhJITyxJzU5NLUgtgskycXBKNTAK2QStjs0+VVDVmumy6TXr DGvvN+/vcy2U1D8RWb1MJOTZVZn41haB9ML996S/H974wK3iw9rXhx+1f3wsM537tbuV6Ynj R5rnydp27/5xSH/NSQbxSx+9J+g6/zjGp/YigX+XWHFdYszjGZrPFjktLC3NfnsmPud41u5J 0vaty8p/ZJxh0vmixFKckWioxVxUnAgA9yF9TrACAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Thu, 03 May 2018 17:34:19 -0000 SGksDQoNCj5IYXZlIHlvdSBsb29rZWQgYXQgdGhlIFJGQyBlZGl0b3Igbm90ZSBBZGFtIGVudGVy ZWQgZm9yIGpzZXA/DQo+DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1ydGN3ZWItanNlcC93cml0ZXVwLyAgKHNjb2xsIGRvd24pDQoNCk5vLCBJIGhhdmVuJ3Qu IEkgZGlkbid0IGtub3cgaXQgd2FzIHRoZXJlLiBTb3JyeSBmb3IgdGhhdC4NCg0KSSB3aWxsIHRh a2UgYSBsb29rLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo+IE9uIE1heSAzLCAyMDE4LCBh dCA3OjAwIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gPiBUaGlzIGlzbid0IHNpbXBseSBhbiBpc3N1 ZSBvZiB3aGF0IHdlIHJlZmVyZW5jZSBidXQgd2hpY2ggcHJvdG9jb2wgDQo+ID4gd2UgZXhwZWN0 IHBlb3BsZSB0byBpbXBsZW1lbnQsIGFzIHRoZXkgYXJlIG5vbi1pZGVudGljYWwuDQo+IA0KPiBT dXJlLiBCdXQsIG15IGNvbW1lbnQgd2FzIG9uIEJlbuKAmXMgbWVzc2FnZSB0aGF0IHdl4oCZbGwg YXNrIHRoZSBSRkMgZWRpdG9yIHRvIGNoYW5nZSB0aGUgcmVmZXJlbmNlcy4NCj4gDQo+IFJlZ2Fy ZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCg0K From nobody Fri May 4 00:08:15 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 D216D12D574 for ; Fri, 4 May 2018 00:08: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 F4wTGwSkKFFt for ; Fri, 4 May 2018 00:08:10 -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 853B41273E2 for ; Fri, 4 May 2018 00:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525417684; 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=MZhZBlNV6CpwaEeM2R2YIfBGeJNBS4SsoS71meKHKHU=; b=EbAmjuqURQq+ijuvRgpzsb26uSFmhBfg05CCze6kN3su2bHyrXycCr8Si8q1fgeu 9LnOkDoJQOn2vlYFVI5vWILiuvEORmrgRnrAKf7Fjt+Aloy82JN66p28PwCHY50x /KRkB+NDx0gj5u5M5xXRj7fpMCxczEt1JJgKacb2EnY=; X-AuditID: c1b4fb25-98ba79c0000064d0-f1-5aec06d4f6f4 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 49.20.25808.4D60CEA5; Fri, 4 May 2018 09:08:04 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0382.000; Fri, 4 May 2018 09:07:14 +0200 From: Christer Holmberg To: Christer Holmberg , Ben Campbell CC: Eric Rescorla , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" , "mmusic-chairs@ietf.org" , The IESG , "rtcweb@ietf.org" , mmusic WG , "ice@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4CAABtpgIAAORYAgAAY7ACAADI8QIAA9U0A Date: Fri, 4 May 2018 07:07:14 +0000 Message-ID: References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> 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: [131.160.50.130] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <644A5570A2D3E1499F2D9E083EB2BB18@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUyM2J7uO4VtjdRBhsumVjM7zzNbvFj7XJm ixWvz7FbfLtQazHjz0Rmi/M71zNZTF3+mMVi7b92dgcOjyVLfjJ5zNr5hMVj8uM25gDmKC6b lNSczLLUIn27BK6MFf+PsBVM5q1YtPI3YwPjHq4uRk4OCQETiTmnt7N3MXJxCAkcYZRoa9rB CuEsYpS48PMUcxcjBwebgIVE9z9tkAYRgQiJb3cWM4HUMAusZ5LomLCOCSQhLFAg0bN3PwtE UaHE2h2P2ECKRAQuMUps613PCpJgEVCReLr8O5jNK2At8fblbiaIbRt5JK7uuAc2iVPAT+L/ vH9gkxgFxCS+n1oDFmcWEJe49WQ+E8TdAhJL9pxnhrBFJV4+/gc2VFRAT2LDidvsIFdLCChJ 3N7gBNGqJ3Fj6hQ2CNtaYvXMO6wQtrbEsoWvmSHuEZQ4OfMJywRG8VlIts1C0j4LSfssJO2z kLQvYGRdxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYtwe3/FbdwXj5jeMhRgEORiUeXqFv r6OEWBPLiitzDzFKcDArifDOOgQU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzvvQfHOUkEB6Yklq dmpqQWoRTJaJg1OqgTHGZN7cDDbvBfV6Z+r2n3PcNfF2xu+ds3p6j++uLJpy7eGu+v8Lpu95 HCktHyl0577iu6sHLJ0tOFiDYi6vW+zx19anNmgjn9wmC90mW2vJHtVpB1+kWT/uv+hnPtlp XtTMM+LO1/urnllNOPrz4Iyb3GtaTCVZ9N0SdGfKrxY783TR7Ziyuv1KLMUZiYZazEXFiQAi xUdc1wIAAA== Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Fri, 04 May 2018 07:08:12 -0000 Hi, I had a look at Adam=B9s note to the RFC editor. As far as fixing the trickle references are concerned, it looks ok. Regarding core ICE, I still think we shall replace the RFC5245 reference with a reference to draft-5245bis, for the following technical reasons: 1) JSEP implicitly references 5245bis, via other references 2) Trickle ICE is based on 5245bis, and I think (please correct me if I=B9m wrong) that one must implement draft-5245bis in order to be able to implement trickle according to the spec. Finally, an editorial nit. Section 13.5.2.1 says: "The candidate details are specified in an IceCandidate field, using the same SDP syntax as the "candidate-attribute" field defined in [RFC5245], Section 15.1." There is no "candidate-attribute" field. I suggest s/"candidate-attribute"/"candidate" attribute Regards, Christer On 03/05/18 20:32, "Christer Holmberg" wrote: >Hi, > >>Have you looked at the RFC editor note Adam entered for jsep? >> >>https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/writeup/ (scoll >>down) > >No, I haven't. I didn't know it was there. Sorry for that. > >I will take a look. > >Regards, > >Christer > >> On May 3, 2018, at 7:00 AM, Christer Holmberg >> wrote: >>=20 >> Hi, >>=20 >> > This isn't simply an issue of what we reference but which protocol >> > we expect people to implement, as they are non-identical. >>=20 >> Sure. But, my comment was on Ben=B9s message that we=B9ll ask the RFC >>editor to change the references. >>=20 >> Regards, >>=20 >> Christer >>=20 > From nobody Fri May 4 07:50:39 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 6E5E3126D05; Fri, 4 May 2018 07:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7MXqIgVDRzg; Fri, 4 May 2018 07:50:35 -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 BBC3912D7F7; Fri, 4 May 2018 07:50:35 -0700 (PDT) Received: from [10.0.1.86] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w44EoCs7049226 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 May 2018 09:50:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.86] From: Ben Campbell Message-Id: <4308D658-CEA6-48AC-9567-C66B33B00C7B@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_EBE654FC-B0F6-4DAE-B82A-B687BD43C62A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 4 May 2018 09:50:09 -0500 In-Reply-To: Cc: Eric Rescorla , "rtcweb@ietf.org" , Adam Roach , rtcweb-chairs@ietf.org To: Christer Holmberg References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Fri, 04 May 2018 14:50:37 -0000 --Apple-Mail=_EBE654FC-B0F6-4DAE-B82A-B687BD43C62A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (- IESG, MMUSIC, ICE, etc, since this seems to have moved on to be = strictly a JSEP discussion) I seem to recall there was a plan to revisit the 5245/5245bis reference = question in general when Cluster 238 starts to break loose, and let the = RFC Editor fix it. Is that still the case? (Or am I confused?) Ben. > On May 4, 2018, at 2:07 AM, Christer Holmberg = wrote: >=20 >=20 > Hi, >=20 > I had a look at Adam=C2=B9s note to the RFC editor. As far as fixing = the > trickle references are concerned, it looks ok. >=20 > Regarding core ICE, I still think we shall replace the RFC5245 = reference > with a reference to draft-5245bis, for the following technical = reasons: >=20 > 1) JSEP implicitly references 5245bis, via other references > 2) Trickle ICE is based on 5245bis, and I think (please correct me if = I=C2=B9m > wrong) that one must implement draft-5245bis in order to be able to > implement trickle according to the spec. >=20 >=20 > Finally, an editorial nit. >=20 > Section 13.5.2.1 says: >=20 > "The candidate details are specified in an IceCandidate field, using > the same SDP syntax as the "candidate-attribute" field defined in > [RFC5245], Section 15.1." >=20 > There is no "candidate-attribute" field. I suggest > s/"candidate-attribute"/"candidate" attribute >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > On 03/05/18 20:32, "Christer Holmberg" = > wrote: >=20 >> Hi, >>=20 >>> Have you looked at the RFC editor note Adam entered for jsep? >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/writeup/ = (scoll >>> down) >>=20 >> No, I haven't. I didn't know it was there. Sorry for that. >>=20 >> I will take a look. >>=20 >> Regards, >>=20 >> Christer >>=20 >>> On May 3, 2018, at 7:00 AM, Christer Holmberg >>> wrote: >>>=20 >>> Hi, >>>=20 >>>> This isn't simply an issue of what we reference but which protocol >>>> we expect people to implement, as they are non-identical. >>>=20 >>> Sure. But, my comment was on Ben=C2=B9s message that we=C2=B9ll ask = the RFC >>> editor to change the references. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>=20 >=20 --Apple-Mail=_EBE654FC-B0F6-4DAE-B82A-B687BD43C62A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrscyEACgkQgFZKbJXz 1A33uw//SaleDfthFkDTMC2zxekwM7iEPPFRU+Z26lQAYwa1HF16tpx6fxuRXgyn Q0jgwNLh83ovoC8KJGSf0aifG1/RkLLiH6xr48rQZHz7Y22OEyVC8r0p+OdLrwnb ZJslIgj4aD3Wv3lEBcD+QO/jvipzR6yiw+qHFBPh+/pONUsuUuJz+jFXxYD7Zdwt v7V5hc9UKiMsoEwK/ckkRvupm1YUWJr0VNwzw43PLmgF1CF2TS9RAXdKVl6Q+P7B PLpUo3QChGUZ9qIoI3AzOVjOIR0Tao53m8vW0w+NHoKhbySARiuZolySrArxGKmp dK2hAr97xOK89HVv/TuqxFORNXv9Z+4RyIDGKfELGPYPxnHF0lKWsGSlzVlTSOnC k0Eb6WoPZ0yi23hibtAnAIuX6U+yGOY42nkpjTjGPbsiw4COxh1jYZjEuSwt/IEq WWCnBPawdRoVWa5t6d42xmnc9Ydl5Wh+17I+3Hn8qW9vGZ4p/wExYrd1k6Fyavu7 To13QwjvymNLSKfjHRSxDTNblRuHABmYZZw7ajRCNMl+99h8KfiuH0MrSVxcta2x Ba/+9f47d9CpdSWtxmw1LWwq5xRIx8SpYRrDD5olE93JxedC7zmg3cvJoA+E3yBd kEG+ks5uYV1QdwbWI/DBzSw9uI9B9SUBAYutN6fNLNkxNl3s2RY= =hLiK -----END PGP SIGNATURE----- --Apple-Mail=_EBE654FC-B0F6-4DAE-B82A-B687BD43C62A-- From nobody Fri May 4 08:03: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 70DAD12D810 for ; Fri, 4 May 2018 08:03:10 -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=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 MT1GdNdxFWol for ; Fri, 4 May 2018 08:03:08 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960F612D7F1 for ; Fri, 4 May 2018 08:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525446186; 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=83XSvnbd0VXjwBBcW87DuGFoIl766Nam9wDJ1PtuOJ4=; b=Qe4iru5SVT4Zxu3veH3Xa4uDCmI0p/UH6haJ++iiyOa3s1kA+BaH+9buItUT1tew voMNsz3bbNyHoTtXg2K3vQYeIRi5K7fgKt/Nn0pdVSFPN9BHJKQSeNArGa3fzcvi KB/zpP/Tryi6ae8jerEKOZNDLjplU7fLSrBROKfT8kc=; X-AuditID: c1b4fb30-0f7ff70000007681-0d-5aec762a5c45 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.E3.30337.A267CEA5; Fri, 4 May 2018 17:03:06 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0382.000; Fri, 4 May 2018 17:03:06 +0200 From: Christer Holmberg To: Ben Campbell CC: Eric Rescorla , "rtcweb@ietf.org" , "Adam Roach" , "rtcweb-chairs@ietf.org" Thread-Topic: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4CAABtpgIAAORYAgAAY7ACAADI8QIAA9U0AgABOSICAACJS0A== Date: Fri, 4 May 2018 15:03:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EB102C@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <4308D658-CEA6-48AC-9567-C66B33B00C7B@nostrum.com> In-Reply-To: <4308D658-CEA6-48AC-9567-C66B33B00C7B@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.166] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7k65W2Zsog6/zrCz2/F3EbjG/8zS7 xYrX59gtet7eYLFY+6+d3YHVY8mSn0wes3Y+YfGY/LiNOYA5issmJTUnsyy1SN8ugSvjUP9j 5oJNshXfWr4zNTBekOli5OSQEDCReL/jLGMXIxeHkMARRokpbdtYIZxFjBITz54Acjg42AQs JLr/aYM0iAgoSTxv3soCUsMsMJtRYuf8N2wgCWGBAomNc1rZIIoKJdbueMQGUiQi8IhRYtv/ NnaQBIuAisSRrrssIDavgK/E1fv9zBDbZvBKtL39yQyS4BSwl3h4cztYA6OAmMT3U2uYQGxm AXGJW0/mM0HcLSCxZM95ZghbVOLl43+sELaSxNHTl8CuZhbQlFi/Sx+iVVFiSvdDdoi9ghIn Zz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmBEHdzy 22AH48vnjocYBTgYlXh4d8e/iRJiTSwrrsw9xCjBwawkwjvr0OsoId6UxMqq1KL8+KLSnNTi Q4zSHCxK4rwWfpujhATSE0tSs1NTC1KLYLJMHJxSDYzxR6rPPVhVGbn/sN5Zk81pz9WUeGSu hz2X9rcWM8wJO1ZWYR7eYX74WmdiKM9fHWHpZn4+tabALWvef0/8biV8sU9bL3nhvGKRmmWL 1p8w326v/PJCRdhuu81C0rcXV2ffq3RJ+dzYNbUkWTTYPmSv2/wml8TfjAtLbtb9V+77d0H6 WZTSeSWW4oxEQy3mouJEAHKZEYSkAgAA Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Fri, 04 May 2018 15:03:10 -0000 SGksDQoNCj4gKC0gSUVTRywgTU1VU0lDLCBJQ0UsIGV0Yywgc2luY2UgdGhpcyBzZWVtcyB0byBo YXZlIG1vdmVkIG9uIHRvIGJlIHN0cmljdGx5IGEgSlNFUCBkaXNjdXNzaW9uKQ0KPg0KPiBJIHNl ZW0gdG8gcmVjYWxsIHRoZXJlIHdhcyBhIHBsYW4gdG8gcmV2aXNpdCB0aGUgNTI0NS81MjQ1Ymlz IHJlZmVyZW5jZSBxdWVzdGlvbiBpbiBnZW5lcmFsIHdoZW4gDQo+IENsdXN0ZXIgMjM4IHN0YXJ0 cyB0byBicmVhayBsb29zZSwgYW5kIGxldCB0aGUgUkZDIEVkaXRvciBmaXggaXQuIElzIHRoYXQg c3RpbGwgdGhlIGNhc2U/IChPciBhbSBJIGNvbmZ1c2VkPykNCg0KSnVzdCB0byBrZWVwIGluIG1p bmQgdGhhdCBpdCBpcyBub3QgYW4gZWRpdG9yaWFsIGJlYXV0eSBjb250ZXN0LiBBcyBJIGluZGlj YXRlZCBlYXJsaWVyLCB0cmlja2xlIElDRSBpcyBiYXNlZCBvbiBwcm9jZWR1cmVzIGluIDUyNDVi aXMsIHRoYXQgYXJlIGRpZmZlcmVudCBmcm9tIFJGQzUyNDUuDQoNCkkgdGhpbmsgRWtyIGFsc28g c2FpZCB0aGF0IGNoYW5naW5nIHRoZSByZWZlcmVuY2Ugd291bGQgYmUgYSBjaGFuZ2Ugb2YgcHJv dG9jb2wsIGV2ZW4gdGhvdWdoIGhlIG1heSBub3QgYWdyZWUgd2Ugc2hvdWxkIGRvIHRoZSBjaGFu Z2UuDQoNCk5vdywgaW4gc29tZSBjYXNlcyAod2hlbiByZWZlcmVuY2luZyBTRFAgYXR0cmlidXRl cyBldGMpIHRoZSByZWZlcmVuY2Ugd291bGQgbm90IGJlIHRvIDUyNDViaXMsIGJ1dCB0byBkcmFm dC1pZXRmLW1tdXNpYy1pY2Utc2lwLXNkcCwgd2hpY2ggaXMgbm90IHlldCBpbiB0aGUgUkZDIGVk aXRvcidzIHF1ZXVlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCj4gT24gTWF5IDQsIDIw MTgsIGF0IDI6MDcgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gDQo+IEhpLA0KPiANCj4gSSBoYWQgYSBsb29rIGF0IEFk YW3CuXMgbm90ZSB0byB0aGUgUkZDIGVkaXRvci4gQXMgZmFyIGFzIGZpeGluZyB0aGUgDQo+IHRy aWNrbGUgcmVmZXJlbmNlcyBhcmUgY29uY2VybmVkLCBpdCBsb29rcyBvay4NCj4gDQo+IFJlZ2Fy ZGluZyBjb3JlIElDRSwgSSBzdGlsbCB0aGluayB3ZSBzaGFsbCByZXBsYWNlIHRoZSBSRkM1MjQ1 IA0KPiByZWZlcmVuY2Ugd2l0aCBhIHJlZmVyZW5jZSB0byBkcmFmdC01MjQ1YmlzLCBmb3IgdGhl IGZvbGxvd2luZyB0ZWNobmljYWwgcmVhc29uczoNCj4gDQo+IDEpIEpTRVAgaW1wbGljaXRseSBy ZWZlcmVuY2VzIDUyNDViaXMsIHZpYSBvdGhlciByZWZlcmVuY2VzDQo+IDIpIFRyaWNrbGUgSUNF IGlzIGJhc2VkIG9uIDUyNDViaXMsIGFuZCBJIHRoaW5rIChwbGVhc2UgY29ycmVjdCBtZSBpZiAN Cj4gScK5bQ0KPiB3cm9uZykgdGhhdCBvbmUgbXVzdCBpbXBsZW1lbnQgZHJhZnQtNTI0NWJpcyBp biBvcmRlciB0byBiZSBhYmxlIHRvIA0KPiBpbXBsZW1lbnQgdHJpY2tsZSBhY2NvcmRpbmcgdG8g dGhlIHNwZWMuDQo+IA0KPiANCj4gRmluYWxseSwgYW4gZWRpdG9yaWFsIG5pdC4NCj4gDQo+IFNl Y3Rpb24gMTMuNS4yLjEgc2F5czoNCj4gDQo+ICAgIlRoZSBjYW5kaWRhdGUgZGV0YWlscyBhcmUg c3BlY2lmaWVkIGluIGFuIEljZUNhbmRpZGF0ZSBmaWVsZCwgdXNpbmcNCj4gICAgdGhlIHNhbWUg U0RQIHN5bnRheCBhcyB0aGUgImNhbmRpZGF0ZS1hdHRyaWJ1dGUiIGZpZWxkIGRlZmluZWQgaW4N Cj4gICAgW1JGQzUyNDVdLCBTZWN0aW9uIDE1LjEuIg0KPiANCj4gVGhlcmUgaXMgbm8gImNhbmRp ZGF0ZS1hdHRyaWJ1dGUiIGZpZWxkLiBJIHN1Z2dlc3QgDQo+IHMvImNhbmRpZGF0ZS1hdHRyaWJ1 dGUiLyJjYW5kaWRhdGUiIGF0dHJpYnV0ZQ0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVy DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gT24gMDMvMDUvMTggMjA6MzIsICJDaHJpc3RlciBIb2xt YmVyZyIgDQo+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+IHdyb3RlOg0KPiAN Cj4+IEhpLA0KPj4gDQo+Pj4gSGF2ZSB5b3UgbG9va2VkIGF0IHRoZSBSRkMgZWRpdG9yIG5vdGUg QWRhbSBlbnRlcmVkIGZvciBqc2VwPw0KPj4+IA0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLWpzZXAvd3JpdGV1cC8gIA0KPj4+IChzY29sbA0K Pj4+IGRvd24pDQo+PiANCj4+IE5vLCBJIGhhdmVuJ3QuIEkgZGlkbid0IGtub3cgaXQgd2FzIHRo ZXJlLiBTb3JyeSBmb3IgdGhhdC4NCj4+IA0KPj4gSSB3aWxsIHRha2UgYSBsb29rLg0KPj4gDQo+ PiBSZWdhcmRzLA0KPj4gDQo+PiBDaHJpc3Rlcg0KPj4gDQo+Pj4gT24gTWF5IDMsIDIwMTgsIGF0 IDc6MDAgQU0sIENocmlzdGVyIEhvbG1iZXJnIA0KPj4+IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpLA0KPj4+IA0KPj4+PiBUaGlzIGlzbid0IHNp bXBseSBhbiBpc3N1ZSBvZiB3aGF0IHdlIHJlZmVyZW5jZSBidXQgd2hpY2ggcHJvdG9jb2wgDQo+ Pj4+IHdlIGV4cGVjdCBwZW9wbGUgdG8gaW1wbGVtZW50LCBhcyB0aGV5IGFyZSBub24taWRlbnRp Y2FsLg0KPj4+IA0KPj4+IFN1cmUuIEJ1dCwgbXkgY29tbWVudCB3YXMgb24gQmVuwrlzIG1lc3Nh Z2UgdGhhdCB3ZcK5bGwgYXNrIHRoZSBSRkMgDQo+Pj4gZWRpdG9yIHRvIGNoYW5nZSB0aGUgcmVm ZXJlbmNlcy4NCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IA0KPj4+IENocmlzdGVyDQo+Pj4gDQo+ PiANCj4gDQoNCg== From nobody Fri May 4 08:26: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 21EB912D7F1 for ; Fri, 4 May 2018 08:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 d1g3VVCGC6OS for ; Fri, 4 May 2018 08:26:42 -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 4A94212D86D for ; Fri, 4 May 2018 08:26:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x22so16886025qkb.12 for ; Fri, 04 May 2018 08:26:42 -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=Bc4aIsDQ5Q/yncUeCwxa44IDwGF03tpFfjhcPHEYE7M=; b=Iib0XSvRIJdWNPnCusJVygTQ854MqnqOlOS7DJ5rO/MFGw1Sag59mv91kPShYO2Y+C bkfSjWG+pUZsmnOUSkI4k/or0yGx11SNcr+xb0szVuDV1SlzdNGNGHQXj5m4b5Kc6/6n SJ89Xq0NpxNYqu1wMFI4utetUCYxpkWIAXV+4= 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=Bc4aIsDQ5Q/yncUeCwxa44IDwGF03tpFfjhcPHEYE7M=; b=AbMxuWBrAmJ5mRlR7u26N4Rma/YNUQ9u3Ha281BMBOv2JVAsOt+efBQ8yhP1uoQDUf jH4KBAp4SykNI1JZR4fLt8sFXO/5NRJ3Vi4sR+fV15TTNpG4PriWqkKhz9tsQGqgnCEx +wJP2lYfmvc3M5/oOH9evEMs4JgBG09ru42QUEKYPYslZgs77VJCnKAugvXAVnoOnz0z lml26qM1v7p3T5cKzVWgYS3+vgj1ehX6fBVg2gJiCGDVgZyDRWIBZqJ8M7ESQECTm4/z 4SPfiFgAKgxG2D7CVdk7Rc3Uj6wV70Lau3suMlo/vUGy3nmkoPuc1yrxe8v4ISaYOQSc uiHw== X-Gm-Message-State: ALQs6tAsz2nqZPmwPmSJdUXV+2BwFI/6L2O9uMZhRL7oriOFkWqKZntq Ev2Gu+TSPQOOdETEZXVlcN7t9g== X-Google-Smtp-Source: AB8JxZoX9RS/uMFjl7i9BJ7hyPvvN+l5Yzi11bm/vHSJhXs0gwuTlu8FI6NcMdd1M2BzROoTZEEzng== X-Received: by 10.55.73.76 with SMTP id w73mr21725031qka.139.1525447601330; Fri, 04 May 2018 08:26:41 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id c20sm11825936qkm.59.2018.05.04.08.26.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 08:26:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sean Turner In-Reply-To: Date: Fri, 4 May 2018 11:26:39 -0400 Cc: RTCWeb IETF , Justin Uberti Content-Transfer-Encoding: quoted-printable Message-Id: <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> To: Nils Ohlmeier 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: Fri, 04 May 2018 15:26:45 -0000 Repo is here :) https://github.com/juberti/draughts spt > On May 1, 2018, at 17:33, Justin Uberti = wrote: >=20 > Do you want to take a shot at the text? (either in email or as a PR) >=20 > On Mon, Apr 30, 2018 at 3:21 PM Nils Ohlmeier = wrote: >=20 >> On Apr 30, 2018, at 15:03, Justin Uberti wrote: >>=20 >> Any TURN server provided by the browser is in effect a proxy, and = forcing use of said proxy can be done either through firewall config or = explicit selection of Mode 4. (IOW, no new mode is needed.) >=20 > I do agree that these two configurations result in a similar behavior. > But I doubt that these use the same code path in implementations. > And (thus) I doubt readers of the draft/RFC will automatically come to = the same conclusion. >=20 > It think it might be helpful to add another sentence explaining this = scenario. >=20 >> The document originally pointed at RETURN as an example of how such = TURN proxying could work, but was removed in order to avoid a = dependency. >=20 > Fair enough. >=20 > Nils >=20 >> On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings = wrote: >>=20 >>=20 >>> On Apr 17, 2018, at 3:15 AM, Justin Uberti = wrote: >>>=20 >>> IMO "trusting the TURN relay but not the application" is not a = significant enough benefit to merit adding specific functionality for. >>>=20 >>=20 >> In the case were the TURN server is provided by the JS, I agree. But = in the case where the configuration of the browser provided the TURN = server, then I think it is as trusted as say a VPN server.=20 >>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri May 4 09:50:24 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 3F797129C70 for ; Fri, 4 May 2018 09:50:22 -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 g6tMgTtquNu3 for ; Fri, 4 May 2018 09:50:15 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F9C129C6A for ; Fri, 4 May 2018 09:50:15 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id v63so17859836pfk.8 for ; Fri, 04 May 2018 09:50:14 -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=o1iP3GTYEthYrCNFX8zjfHs+B9flusfhKmaYRizxR9Q=; b=ELCBhXlbub7Q1Y6/kWMLV2LgX5Tet3ALn9jxUxdgfaoy3i1zi2furL6/cALqpaaY8f NBw1rUCo1NjoIQuR1VOOMFsYYfHPuTFnxlCEKV1Mgb6QYQLMSDDQRDBLPl7pa8Xl5Yy4 vkJXUGnkLhvHceEWPpZIuGVcPlWTOI8Pj2zBU= 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=o1iP3GTYEthYrCNFX8zjfHs+B9flusfhKmaYRizxR9Q=; b=aVbZFJUEmzobsOuOoHFDZz7JiA78jbggfr5AUyy1c8NKrgVw06FsUAJ8NCr7dwvu1k ldHA5Na6bEICGpC+ty0sneSrFOZR7p9NJ4bG5Qr6FRJMxaJNiaQzz+latAOwgTGKYew6 1TIYddRhXlKmcRzHFcYoh3KuF18R5AG2RScLmb1kAxO6E1a67M6PTWSno8yDiY9L2xkx Fv8xIQ0W7Xsy2jMfE607xdrS+lMIVN5Co/N1VUXkyBU72v3WalYvndKDaTb7W0ticF2h OnLzEERVBH3uBWNkZIbPey9PXgPlPDBfVIMkwhjnYVwaG7pByqAaSejQ3JiXZiIPGvAy LyDA== X-Gm-Message-State: ALQs6tCE3Nt3UhBh7gK9ky6k5qo2RPu5+X2xADq210cz8WmBqnhibTa1 q0nhLP/c8SeH0YZ/+RV4FtbI8w== X-Google-Smtp-Source: AB8JxZrf2wdKhTpjqe9goDMNhnpnkhrjRRzrtDT1nCpe9A97d+llZB3uG50CDAtbfMECakd78Dleow== X-Received: by 2002:a63:6185:: with SMTP id v127-v6mr22717063pgb.441.1525452613514; Fri, 04 May 2018 09:50:13 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:bdfe:eedf:56fb:d0e7? ([2620:101:80fc:224:bdfe:eedf:56fb:d0e7]) by smtp.gmail.com with ESMTPSA id d19sm37969251pfk.59.2018.05.04.09.50.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 09:50:12 -0700 (PDT) From: Nils Ohlmeier Message-Id: <574256E1-7AF4-4E25-9462-04B4B599C801@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B304B97A-2305-473C-A4A6-30895C272AEE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 4 May 2018 09:50:09 -0700 In-Reply-To: <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> Cc: RTCWeb IETF , Justin Uberti To: Sean Turner References: <1D5B431C-801E-4F8C-8026-6BCBB72FF478@sn3rd.com> <296F0D20-F716-4C6C-8ABB-9FC21FC8189D@mozilla.com> <0E876BDE-C438-43AD-B87A-95894ADCBF8F@sn3rd.com> 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: Fri, 04 May 2018 16:50:22 -0000 --Apple-Mail=_B304B97A-2305-473C-A4A6-30895C272AEE Content-Type: multipart/alternative; boundary="Apple-Mail=_83AB0C8B-3661-4336-92E5-B0EA4F08B9C4" --Apple-Mail=_83AB0C8B-3661-4336-92E5-B0EA4F08B9C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Created https://github.com/juberti/draughts/pull/101 = Nils > On May 4, 2018, at 08:26, Sean Turner wrote: >=20 > Repo is here :) >=20 > https://github.com/juberti/draughts >=20 > spt >=20 >> On May 1, 2018, at 17:33, Justin Uberti = wrote: >>=20 >> Do you want to take a shot at the text? (either in email or as a PR) >>=20 >> On Mon, Apr 30, 2018 at 3:21 PM Nils Ohlmeier = wrote: >>=20 >>> On Apr 30, 2018, at 15:03, Justin Uberti wrote: >>>=20 >>> Any TURN server provided by the browser is in effect a proxy, and = forcing use of said proxy can be done either through firewall config or = explicit selection of Mode 4. (IOW, no new mode is needed.) >>=20 >> I do agree that these two configurations result in a similar = behavior. >> But I doubt that these use the same code path in implementations. >> And (thus) I doubt readers of the draft/RFC will automatically come = to the same conclusion. >>=20 >> It think it might be helpful to add another sentence explaining this = scenario. >>=20 >>> The document originally pointed at RETURN as an example of how such = TURN proxying could work, but was removed in order to avoid a = dependency. >>=20 >> Fair enough. >>=20 >> Nils >>=20 >>> On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings = wrote: >>>=20 >>>=20 >>>> On Apr 17, 2018, at 3:15 AM, Justin Uberti = wrote: >>>>=20 >>>> IMO "trusting the TURN relay but not the application" is not a = significant enough benefit to merit adding specific functionality for. >>>>=20 >>>=20 >>> In the case were the TURN server is provided by the JS, I agree. But = in the case where the configuration of the browser provided the TURN = server, then I think it is as trusted as say a VPN server. >>>=20 >>>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail=_83AB0C8B-3661-4336-92E5-B0EA4F08B9C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Created https://github.com/juberti/draughts/pull/101

  Nils

On May 4, 2018, at 08:26, Sean Turner <sean@sn3rd.com> = wrote:

Repo is here :)

https://github.com/juberti/draughts

spt

On May 1, 2018, at 17:33, Justin Uberti = <juberti=3D40google.com@dmarc.ietf.org> wrote:

Do you want to take a shot at the text? (either in email or = as a PR)

On Mon, Apr 30, 2018 at 3:21 PM = Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

On Apr 30, 2018, at = 15:03, Justin Uberti <juberti@google.com> wrote:

Any TURN server provided by the browser is in effect a proxy, = and forcing use of said proxy can be done either through firewall config = or explicit selection of Mode 4. (IOW, no new mode is needed.)

I do agree that these two = configurations result in a similar behavior.
But I doubt = that these use the same code path in implementations.
And = (thus) I doubt readers of the draft/RFC will automatically come to the = same conclusion.

It think it might be = helpful to add another sentence explaining this scenario.

The = document originally pointed at RETURN as an example of how such TURN = proxying could work, but was removed in order to avoid a dependency.

Fair enough.

 Nils

On Fri, Apr 27, 2018 at 11:22 AM Cullen = Jennings <fluffy@iii.ca> wrote:


On Apr 17, 2018, at 3:15 = AM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> = wrote:

IMO "trusting the TURN relay but not = the application" is not a significant enough benefit to merit adding = specific functionality for.


In the case were the TURN server is provided by the JS, I = agree. But in the case where the configuration of the browser provided = the TURN server, then I think it is as trusted as say a VPN server.



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


= --Apple-Mail=_83AB0C8B-3661-4336-92E5-B0EA4F08B9C4-- --Apple-Mail=_B304B97A-2305-473C-A4A6-30895C272AEE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrsj0IACgkQY2o/VmzJ +KHw2xAAm2EmEvXlHv9MhWVYU+RbGouY2aXGNXuK2Qo/TJh643szxPZgmXjQo+mK f57+aSDiMIL9GOYzUdrnjFolNyCwVUR595iNAk/47EccZVqENgYYiWd3L87PKJl4 PDRurMwYFkvAyUYofK5Tq8nQiiavv2pFV4BkxMEhNX/2+Gfu3RzW/zQXmGWvarGZ g/8hYnd6pjGfB58KyweTqLtK7FfOcz+O1ISRL1zjkVMZEJRKhZTiWbFADKH5ZRst f7DjTcG0ZQDepIwCOgN7WUy5NKQlfjs0YxoDYkSztS+8WGQTsk09VgqePBNcmeNs vCcHALgRwt0jIn5yVZvk9x8ulx1ZanHP2yPEVTmL6tF//mE1kWj2FmR2HyflG8pb PAAGnAGKzBSJB4Q1ZNZ0K8MWccfXaOV6zRfoH4KuLEzTFqu2c2lPkVWwItRddYQx rzC+URcpXg0j/mo+rfTkoEVf6qlWm8Bw2StOrRCG8YIckwxajvkkbGtLocIYfyS1 yGr00h8EZD1WIT3xcD7F4sjQlOUmTFNRxaY0t2lQ461qCgHamjef+W3h8lDwWBwN ZxFhr1g1W3A2Tt1xxPl2NO2aAqs3d0rsjWUpdw1RAedYT5U0fcysdK9ghlPoEx2S jV6dmbX3ODGl5jTGWQDNuMBBKgR+ewYTV01rA9+Z27wClvfG2VA= =W9ef -----END PGP SIGNATURE----- --Apple-Mail=_B304B97A-2305-473C-A4A6-30895C272AEE-- From nobody Fri May 4 16:33:09 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 545D612DDD2 for ; Fri, 4 May 2018 16:32:52 -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 q_xEk9rt6Moh for ; Fri, 4 May 2018 16:32:50 -0700 (PDT) Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42]) (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 47AE112DA21 for ; Fri, 4 May 2018 16:32:46 -0700 (PDT) Received: by mail-pg0-f42.google.com with SMTP id e1-v6so5059095pga.6 for ; Fri, 04 May 2018 16:32:46 -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=Gx6X9Uc3XpNMz3iQFn6B8epg67jVsacqHafa9WQ9PX0=; b=gVeOKw6UuPxNRbMjTgtSZTTfyyqYatw/puREKbD8JwOWPP8uq2FCYqLffM8kjX4eM0 Xqg4D4m2mactrYKNteN+lSzcbc38/y8YAoyG4svKUTuLIvuWQQY4WCtlDgJruYal36xE qtwUQSvIg71Gu/j4WrOYKv4FyAQ7Ns0KgK4U4= 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=Gx6X9Uc3XpNMz3iQFn6B8epg67jVsacqHafa9WQ9PX0=; b=Efw0C/RG5aZRPQPYXCW4kUQnwRj96PPG3FoPWBreqWYI9DRaF6mf0Bc1HqSVHb0nDi FyFpohOkVYHKxNTSzz48J9jmvIvqpebL5dQzBOLAEqJerT2MbWeZwacg9ZfDgRibcLhu lsG+0sPYVPVcHHOPQ01yOBRNz0x7HtwsxzypVph70iVzGuHgG21aKrMHsMedPy+AaCU+ RCDZ3xUowMdt4C9Dxb1NSU9H65sqxRARTXxqfiDY2aaxHM8sR92vQOqX7dLXeUM0t0iM RS/fpqBM5eZ8H3PLjkWXmuEQJ18cY0sdfo/RDGdB/N+E2bCTMmS/GkttqDB0w4ZWoD5R 6LPQ== X-Gm-Message-State: ALQs6tCygH+VT1nNcfULJ0FW4oIDQnbvWJvyEJ7Rve7TEMv/X5sQWoQ7 Vb7Q8epE+U8uZRNMgvUDN5yz2Q== X-Google-Smtp-Source: AB8JxZqPXAOREFHA4aa77RzrYiz2JWp2KQWjnBHm20nInpLVar5Esm+PjR4GETZVOpEB2pSCxRZ1pw== X-Received: by 2002:a17:902:52ed:: with SMTP id a100-v6mr29654014pli.131.1525476765592; Fri, 04 May 2018 16:32:45 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:bdfe:eedf:56fb:d0e7? ([2620:101:80fc:224:bdfe:eedf:56fb:d0e7]) by smtp.gmail.com with ESMTPSA id k13sm40503183pfj.186.2018.05.04.16.32.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 May 2018 16:32:44 -0700 (PDT) From: Nils Ohlmeier Message-Id: <0F8D6F20-D112-4A07-9256-AFF07E470D2A@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0F69C971-020F-4071-98AE-5EFEC01281E1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 4 May 2018 16:32:42 -0700 In-Reply-To: Cc: Ben Campbell , "mmusic-chairs@ietf.org" , mmusic WG , "ice@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" To: Christer Holmberg References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Fri, 04 May 2018 23:32:53 -0000 --Apple-Mail=_0F69C971-020F-4071-98AE-5EFEC01281E1 Content-Type: multipart/alternative; boundary="Apple-Mail=_779E90B1-C496-41C0-BDBA-141BBC48FF45" --Apple-Mail=_779E90B1-C496-41C0-BDBA-141BBC48FF45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christer, > On May 4, 2018, at 00:07, Christer Holmberg = wrote: >=20 > 2) Trickle ICE is based on 5245bis, and I think (please correct me if = I=C2=B9m > wrong) that one must implement draft-5245bis in order to be able to > implement trickle according to the spec. Chrome and Firefox both have implemented trickle without supporting = 5245bis. So it works fine if one just implements 5245. Although I guess by the true definition of the hopefully soon published = trickle RFC neither of these have implemented trickle correct, as they = both don=E2=80=99t support the new 3rd nomination algorithm. Nils Ohlmeier >=20 > Finally, an editorial nit. >=20 > Section 13.5.2.1 says: >=20 > "The candidate details are specified in an IceCandidate field, using > the same SDP syntax as the "candidate-attribute" field defined in > [RFC5245], Section 15.1." >=20 > There is no "candidate-attribute" field. I suggest > s/"candidate-attribute"/"candidate" attribute >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > On 03/05/18 20:32, "Christer Holmberg" > > wrote: >=20 >> Hi, >>=20 >>> Have you looked at the RFC editor note Adam entered for jsep? >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/writeup/ = (scoll >>> down) >>=20 >> No, I haven't. I didn't know it was there. Sorry for that. >>=20 >> I will take a look. >>=20 >> Regards, >>=20 >> Christer >>=20 >>> On May 3, 2018, at 7:00 AM, Christer Holmberg >>> wrote: >>>=20 >>> Hi, >>>=20 >>>> This isn't simply an issue of what we reference but which protocol >>>> we expect people to implement, as they are non-identical. >>>=20 >>> Sure. But, my comment was on Ben=C2=B9s message that we=C2=B9ll ask = the RFC >>> editor to change the references. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_779E90B1-C496-41C0-BDBA-141BBC48FF45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Christer,

On May 4, 2018, at 00:07, Christer Holmberg = <christer.holmberg@ericsson.com> wrote:

2) Trickle = ICE is based on 5245bis, and I think (please correct me if = I=C2=B9m
wrong) that = one must implement draft-5245bis in order to be able to
implement = trickle according to the spec.

Chrome and Firefox both have implemented trickle = without supporting 5245bis.
So it works fine if one just = implements 5245.
Although I guess by the true definition of = the hopefully soon published trickle RFC neither of these have = implemented trickle correct, as they both don=E2=80=99t support the new = 3rd nomination algorithm.

  = Nils Ohlmeier


Finally, an editorial nit.

Section 13.5.2.1 says:

  "The candidate details are specified in an = IceCandidate field, using
   the same SDP syntax as the = "candidate-attribute" field defined in
   [RFC5245], Section 15.1."

There is no = "candidate-attribute" field. I suggest
s/"candidate-attribute"/"candidate" attribute

Regards,

Christer





On 03/05/18 20:32, "Christer Holmberg" <christer.holmberg@ericsson.com>
wrote:

Hi,

Have you looked at the = RFC editor note Adam entered for jsep?

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/writeup= /  (scoll
down)

No, I haven't. I didn't know it was there. Sorry for that.

I will take a look.

Regards,

Christer

On May 3, = 2018, at 7:00 AM, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
Hi,

This isn't simply an issue of what we reference but which = protocol
we expect people to implement, as they are = non-identical.

Sure. But, my = comment was on Ben=C2=B9s message that we=C2=B9ll ask the RFC
editor to change the references.

Regards,

Christer



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

= --Apple-Mail=_779E90B1-C496-41C0-BDBA-141BBC48FF45-- --Apple-Mail=_0F69C971-020F-4071-98AE-5EFEC01281E1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlrs7ZoACgkQY2o/VmzJ +KFDgA/+J6XFlO8n5Xvu1jDyhCk4qRwd0dt+Vy0Tuay08opcZi2KIxc1khdN1oeL NTP53QDpIcV+SZ3p/0+43SnIhfyecmaCwu1NRhsE0R5Ovsgt2VsXwtgQwZwey9Xz HHQrFawsVfJ1T3H+D3rr4rta3rWA3wssg4pZzMq773pwgn30u5K8jpKAFsUQKFRu J93bYopxsBFJ4nBmRVY05SmXAf2oTDTfLStAsWUOjkyK2UzwBvv+YjTue90lqzem zbyOsGZcsES23mOWCpEiPivp0SsJgwj36IMwsUCEb5FUhiCSc2v6r2LCjulXY2u+ 06Ok/LXINJIYZDazBFo0dm9tsW8Jzl5/RwXtu55FfOWehEe/i3qOdD8+W9DtCj3I g4CyltO9OCbUxaapZEnEB7HOh7rXx0DBnuxAxqBXfSqvNmwzkkD95V/7ms8bC+yz ZUFKhVFhc1r1DnynISnlZLw31SUUwm6Zrw26nLAMiB/UozEscp4Rzn8QxsIpbQaH 4obtiBazdFjYKslS2gLpJnZ1h9ZsclT2kz5y/lWV87bRMKTUHL4icU3jWvnUtiBY ZuWVPuVir4B07snBmAzaD6gn7UBWbMtkAOnEhBTUO4NQt9dHu7pEQC5s2dEOHJMF /HZYW0NuNKu3deKtznCWgxLw+nv8O6S/3T3LA7BhCjhY8qxcvJU= =dyJL -----END PGP SIGNATURE----- --Apple-Mail=_0F69C971-020F-4071-98AE-5EFEC01281E1-- From nobody Fri May 4 23:48:50 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 B22B412E053 for ; Fri, 4 May 2018 23:48:48 -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 Gua3Z-OAxMhC for ; Fri, 4 May 2018 23:48:46 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE62127201 for ; Fri, 4 May 2018 23:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525502924; 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=S5YoPeGrZbC4xKPn+0CB3urZSTbB9GAd+CMcD6FK6uA=; b=eKj01hpLR6svcOYb8uuiz8NDXv16RlT1rTzO1/Z7YQDppzN9SovIZziLGDmxpXqs N40a5ooy0pPr0AV3SoQv2xUqnbJajmA8u9mBnhtM/tE4ixsi8wPGxVB+Eid5WF5q S4+hoVLj50RuygtwQAo8yu9YSm6jgXaCjXAW3vmsYmw=; X-AuditID: c1b4fb2d-ea2cf9c0000055bf-d8-5aed53cc8d76 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2B.74.21951.CC35DEA5; Sat, 5 May 2018 08:48:44 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Sat, 5 May 2018 08:46:54 +0200 From: Christer Holmberg To: Nils Ohlmeier CC: Ben Campbell , "mmusic-chairs@ietf.org" , mmusic WG , "ice@ietf.org" , "rtcweb@ietf.org" , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4CAABtpgIAAORYAgAAY7ACAADI8QIAA9U0AgADgSACAAJjFwA== Date: Sat, 5 May 2018 06:46:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EB3160@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <0F8D6F20-D112-4A07-9256-AFF07E470D2A@mozilla.com> In-Reply-To: <0F8D6F20-D112-4A07-9256-AFF07E470D2A@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7ou6Z4LdRBq/X6FnM7zzNbvFj7XJm i28Xai1m/JnIbHF+53omi6nLH7NYXJ83mdFi7b92dgcOjyVLfjJ59B3oYvWYtfMJSwBzFJdN SmpOZllqkb5dAlfG41W72Ar2iFZsXfmAsYHxi0gXIyeHhICJxMRDv1i6GLk4hASOMEpsv3Kd EcJZxCjR9eQxUxcjBwebgIVE9z9tEFNEQFPixEY+kBJmgc1MElc3TmQFGSQsUClx6e45RhBb RKBKYs2p38wgRSICjxglfhx7wg7SzCKgInH5TT5IDa+Ar8SNCVOZQGwhgRm8El+3yIPYnAL2 En33N4LNZBQQk/h+ag1YDbOAuMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW0li1q2NYCczA925 fpc+RKuixJTuh+wQawUlTs58wjKBUXQWkqmzEDpmIemYhaRjASPLKkbR4tTi4tx0I2O91KLM 5OLi/Dy9vNSSTYzAODu45bfuDsbVrx0PMQpwMCrx8DoEvo0SYk0sK67MPcQowcGsJMK7/cCb KCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8eqv2RAkJpCeWpGanphakFsFkmTg4pRoYF7bLeS+9 2nUh/uwbm/cGIR2/a1Ye6jo62874ycZ5F1dvvt4w6efecJ7pd4MLF9wPsDLNmDBNorjJWH5C V/b+B5+nyS2aVBe1rEY3RUyB/018qV53SFe5rvoziS2fOYveOl/59Cef7eiO/bW9FTPVI5iM DWdLKSxeltH1zi9kbfGONxqcZoo7lFiKMxINtZiLihMB5qGtgK8CAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Sat, 05 May 2018 06:48:49 -0000 SGkgTmlscywNCg0KPj4gMikgVHJpY2tsZSBJQ0UgaXMgYmFzZWQgb24gNTI0NWJpcywgYW5kIEkg dGhpbmsgKHBsZWFzZSBjb3JyZWN0IG1lIGlmIEnCuW0NCj4+IHdyb25nKSB0aGF0IG9uZSBtdXN0 IGltcGxlbWVudCBkcmFmdC01MjQ1YmlzIGluIG9yZGVyIHRvIGJlIGFibGUgdG8NCj4+IGltcGxl bWVudCB0cmlja2xlIGFjY29yZGluZyB0byB0aGUgc3BlYy4NCj4NCj4gQ2hyb21lIGFuZCBGaXJl Zm94IGJvdGggaGF2ZSBpbXBsZW1lbnRlZCB0cmlja2xlIHdpdGhvdXQgc3VwcG9ydGluZyA1MjQ1 YmlzLg0KPiBTbyBpdCB3b3JrcyBmaW5lIGlmIG9uZSBqdXN0IGltcGxlbWVudHMgNTI0NS4NCj4g QWx0aG91Z2ggSSBndWVzcyBieSB0aGUgdHJ1ZSBkZWZpbml0aW9uIG9mIHRoZSBob3BlZnVsbHkg c29vbiBwdWJsaXNoZWQgdHJpY2tsZSBSRkMgbmVpdGhlciBvZiB0aGVzZSANCj4gaGF2ZSBpbXBs ZW1lbnRlZCB0cmlja2xlIGNvcnJlY3QsIGFzIHRoZXkgYm90aCBkb27igJl0IHN1cHBvcnQgdGhl IG5ldyAzcmQgbm9taW5hdGlvbiBhbGdvcml0aG0uDQoNCkNvcnJlY3QuIFJGQyA1MjQ1IGRvZXMg Y29udGFpbiBhbGwgdGhlIHBpZWNlcyBuZWVkZWQgdG8gZGVmaW5lIGEgdHJpY2tsZSBleHRlbnNp b24sIGJ1dCBwZW9wbGUgd2lsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgdGhlIGRldGFpbHMgdGhlbXNl bHZlcy4NCg0KQmVjYXVzZSwgaWYgeW91IHdhbnQgdG8gaW1wbGVtZW50IHRyaWNrbGUgYWNjb3Jk aW5nIHRvIHRoZSB0cmlja2xlIGRyYWZ0IGl0IGhhcyB0byBiZSBiYXNlZCBvbiA1MjQ1YmlzLCBi ZWNhdXNlIHNvbWUgb2YgdGhlIGFsZ29yaXRobXMvcHJvY2VkdXJlcyBhcmUgNTI0NWJpcy1zcGVj aWZpYy4gDQoNCkZvciBleGFtcGxlLCB0aGUgY2hlY2sgbGlzdCBzdGF0ZSB1cGRhdGUgcHJvY2Vk dXJlcyBpbiBzZWN0aW9uIDEyIGFyZSBiYXNlZCBvbiA1MjQ1YmlzLiBUaG9zZSBhcmUgZGlmZmVy ZW50IGZyb20gdGhlIHByb2NlZHVyZXMgaW4gUkZDIDUyNDUsIGFuZCB3ZXJlIGRvbmUgYmFzZWQg b24gIkVtaWwncyB0YWJsZSIuDQoNClNlY3Rpb24gOCBpcyBhbm90aGVyIGV4YW1wbGUgd2hlcmUg dGhlIHByb2NlZHVyZXMgYXJlIDUyNDViaXMtc3BlY2lmaWMuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KDQoNCg0KDQoNCk9uIDAzLzA1LzE4IDIwOjMyLCAiQ2hyaXN0ZXIgSG9sbWJlcmci IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQp3cm90ZToNCg0KDQpIaSwNCg0KDQpI YXZlIHlvdSBsb29rZWQgYXQgdGhlIFJGQyBlZGl0b3Igbm90ZSBBZGFtIGVudGVyZWQgZm9yIGpz ZXA/DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2Vi LWpzZXAvd3JpdGV1cC8gwqAoc2NvbGwNCmRvd24pDQoNCk5vLCBJIGhhdmVuJ3QuIEkgZGlkbid0 IGtub3cgaXQgd2FzIHRoZXJlLiBTb3JyeSBmb3IgdGhhdC4NCg0KSSB3aWxsIHRha2UgYSBsb29r Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCk9uIE1heSAzLCAyMDE4LCBhdCA3OjAwIEFN LCBDaHJpc3RlciBIb2xtYmVyZw0KPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3Jv dGU6DQoNCkhpLA0KDQoNClRoaXMgaXNuJ3Qgc2ltcGx5IGFuIGlzc3VlIG9mIHdoYXQgd2UgcmVm ZXJlbmNlIGJ1dCB3aGljaCBwcm90b2NvbA0Kd2UgZXhwZWN0IHBlb3BsZSB0byBpbXBsZW1lbnQs IGFzIHRoZXkgYXJlIG5vbi1pZGVudGljYWwuDQoNClN1cmUuIEJ1dCwgbXkgY29tbWVudCB3YXMg b24gQmVuwrlzIG1lc3NhZ2UgdGhhdCB3ZcK5bGwgYXNrIHRoZSBSRkMNCmVkaXRvciB0byBjaGFu Z2UgdGhlIHJlZmVyZW5jZXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxp c3QNCnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0K From nobody Wed May 9 07: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 74E47126CB6 for ; Wed, 9 May 2018 07:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.245 X-Spam-Level: * X-Spam-Status: No, score=1.245 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.246, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTCulWJCYp7M for ; Wed, 9 May 2018 07:19:05 -0700 (PDT) Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.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 49221126BF3 for ; Wed, 9 May 2018 07:19:05 -0700 (PDT) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 737831FAF8; Wed, 9 May 2018 10:19:02 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D462325110; Wed, 9 May 2018 10:19:01 -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); Wed, 09 May 2018 10:19:02 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_33705377-9C1F-4DA6-BD48-6333F9F18C34" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: <4308D658-CEA6-48AC-9567-C66B33B00C7B@nostrum.com> Date: Wed, 9 May 2018 08:19:00 -0600 Cc: Christer Holmberg , RTCWeb IETF , rtcweb-chairs@ietf.org Message-Id: <3F40BE92-D283-4206-B1B9-773169A47D37@iii.ca> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <4308D658-CEA6-48AC-9567-C66B33B00C7B@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Wed, 09 May 2018 14:19:06 -0000 --Apple-Mail=_33705377-9C1F-4DA6-BD48-6333F9F18C34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 4, 2018, at 8:50 AM, Ben Campbell wrote: >=20 > (- IESG, MMUSIC, ICE, etc, since this seems to have moved on to be = strictly a JSEP discussion) >=20 > I seem to recall there was a plan to revisit the 5245/5245bis = reference question in general when Cluster 238 starts to break loose, = and let the RFC Editor fix it. Is that still the case? (Or am I = confused?) >=20 > Ben. We did agree to discuss it when we got closer but it is not just an = issue of what order things get published in or if they block or not, it = is an issue of which protocol we use as that are not the same thing.=20= --Apple-Mail=_33705377-9C1F-4DA6-BD48-6333F9F18C34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On May 4, 2018, at 8:50 AM, Ben Campbell <ben@nostrum.com> = wrote:

(- IESG, MMUSIC, ICE, etc, since = this seems to have moved on to be strictly a JSEP discussion)

I seem to recall there was a = plan to revisit the 5245/5245bis reference question in general when = Cluster 238 starts to break loose, and let the RFC Editor fix it. Is = that still the case? (Or am I confused?)

Ben.

We did agree to discuss it when we got closer but it is not = just an issue of what order things get published in or if they block or = not, it is an issue of which protocol we use as that are not the same = thing. 
= --Apple-Mail=_33705377-9C1F-4DA6-BD48-6333F9F18C34-- From nobody Wed May 9 07:55:18 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 9A877124D68 for ; Wed, 9 May 2018 07:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 X0xybEVx2sQt for ; Wed, 9 May 2018 07:55:11 -0700 (PDT) Received: from smtp81.ord1c.emailsrvr.com (smtp81.ord1c.emailsrvr.com [108.166.43.81]) (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 0BE4312762F for ; Wed, 9 May 2018 07:55:11 -0700 (PDT) Received: from smtp3.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 69A27A027D; Wed, 9 May 2018 10:55:10 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 19F7CA049C; Wed, 9 May 2018 10:55:10 -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); Wed, 09 May 2018 10:55:10 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_250ED366-20A4-4903-99AB-DA58080CC65E" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Wed, 9 May 2018 08:55:08 -0600 Cc: Harald Alvestrand , RTCWeb IETF Message-Id: <921E50B5-4074-4099-8C2B-27A68364DC2E@iii.ca> References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> <7ed02fe1-69cc-f774-f61f-ee79f2e9a61d@alvestrand.no> To: Martin Thomson X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Wed, 09 May 2018 14:55:14 -0000 --Apple-Mail=_250ED366-20A4-4903-99AB-DA58080CC65E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 2, 2018, at 7:21 PM, Martin Thomson = wrote: >=20 > An IdP is given the origin of the requesting site. That allows it to = make > authorization decisions on that basis. Really ? I don=E2=80=99t think it can trust that. I can easily get my = browser to send whatever origin I want to the IdP. I think it needs to = do the usual OAuth like things to authenticate the user.=20 --Apple-Mail=_250ED366-20A4-4903-99AB-DA58080CC65E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 2, 2018, at 7:21 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

An IdP is given the origin of = the requesting site.  That allows it to make
authorization decisions on that = basis.

Really ?  I don=E2=80=99t think it can trust that. =  I can easily get my browser to send whatever origin I want to the = IdP. I think it needs to do the usual OAuth like things to authenticate = the user. 




= --Apple-Mail=_250ED366-20A4-4903-99AB-DA58080CC65E-- From nobody Wed May 9 08:01:33 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 D8A9D124D68; Wed, 9 May 2018 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.61 X-Spam-Level: X-Spam-Status: No, score=-12.61 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJGJE060-jo5; Wed, 9 May 2018 08:01:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCD3127444; Wed, 9 May 2018 08:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3405; q=dns/txt; s=iport; t=1525878086; x=1527087686; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bKLz8hRpDxeMkbs68ze6GrMVr83i2oCXRmZsM++8yNQ=; b=Zj6DZNxrosLS3q6FceT33cW14gE6ea779DBpmS6UXfvWeO2s4/sh+EuA vTEhsgF8RUYeMOUjV+1vXibt3kjduzwVR0Rs8SSUUIBDp/Vbv/pBo8aNo FFRRo7fKzTeEs89h5BXcqXS3B79R0tv6G/BHktd5zG533abywvedmRtWu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAwASDPNa/40NJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdnhjKAqYWIMIjjaGbAuEbAKCayE4FAECAQEBAQEBAmw?= =?us-ascii?q?ohSkGeRACAQgENwQHMhQRAgQOBYMjgR1kqmSIQ4JIiCWCE4EygmiII4IkApg?= =?us-ascii?q?sCAKOTYxjkCgCERMBgSQBMyGBUnAVZQGCGIJIjgZvkAyBGAEB?= X-IronPort-AV: E=Sophos;i="5.49,381,1520899200"; d="scan'208,217";a="389766506" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2018 15:01:25 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w49F1P4w012864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2018 15:01:25 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 9 May 2018 11:01:24 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1320.000; Wed, 9 May 2018 11:01:24 -0400 From: "Cullen Jennings (fluffy)" To: Christer Holmberg CC: Ben Campbell , "mmusic-chairs@ietf.org" , Eric Rescorla , mmusic WG , "ice@ietf.org" , RTCWeb IETF , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [Ice] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHT4wUD4dlCjPaQK0KuuVtb52JvA6QfahIAgAhgIoA= Date: Wed, 9 May 2018 15:01:24 +0000 Message-ID: <8AB44737-5B8B-421C-9A3E-54A8183BCBBD@cisco.com> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.228.210] Content-Type: multipart/alternative; boundary="_000_8AB447375B8B421C9A3E54A8183BCBBDciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] [Ice] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Wed, 09 May 2018 15:01:31 -0000 --_000_8AB447375B8B421C9A3E54A8183BCBBDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On May 4, 2018, at 1:07 AM, Christer Holmberg > wrote: Regarding core ICE, I still think we shall replace the RFC5245 reference with a reference to draft-5245bis, for the following technical reasons: I would view this as a huge changes that would need some pretty significant= testing and discussion in the WG. Right now, as far as I can tell the brow= ser have implemented ice not bis. I would like WebRTC 1.0 to be what peopl= e have implemented - the reason it is ice not bis is it is unclear if bis p= erforms as wells as ice. --_000_8AB447375B8B421C9A3E54A8183BCBBDciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

On May 4, 2018, at 1:07 AM, Christer Holmberg <christer.holmberg@eri= csson.com> wrote:

Regarding core ICE, I still think we shall replace the RFC5245 reference
with a reference to draft-5245bis, for the following technical reasons:<= /div>

I would view this as a huge changes that would need some pr= etty significant testing and discussion in the WG. Right now, as far as I c= an tell the browser have implemented ice not bis.  I would like WebRTC= 1.0 to be what people have implemented - the reason it is ice not bis is it is unclear if bis performs as wells a= s ice. 


--_000_8AB447375B8B421C9A3E54A8183BCBBDciscocom_-- From nobody Wed May 9 08:02:30 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 035751242F5; Wed, 9 May 2018 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpnznPBJEzpw; Wed, 9 May 2018 08:02:26 -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 ADE601276AF; Wed, 9 May 2018 08:02:23 -0700 (PDT) Received: from [10.0.1.94] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w49F2Hd8043392 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 9 May 2018 10:02:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.94] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DACA8CA9-AB57-4082-BA36-1112F9BAB250"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 9 May 2018 10:02:16 -0500 In-Reply-To: <3F40BE92-D283-4206-B1B9-773169A47D37@iii.ca> Cc: Christer Holmberg , RTCWeb IETF , rtcweb-chairs@ietf.org To: Cullen Jennings References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <4308D658-CEA6-48AC-9567-C66B33B00C7B@nostrum.com> <3F40BE92-D283-4206-B1B9-773169A47D37@iii.ca> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Wed, 09 May 2018 15:02:28 -0000 --Apple-Mail=_DACA8CA9-AB57-4082-BA36-1112F9BAB250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 9, 2018, at 9:19 AM, Cullen Jennings wrote: >=20 >=20 >=20 >> On May 4, 2018, at 8:50 AM, Ben Campbell wrote: >>=20 >> (- IESG, MMUSIC, ICE, etc, since this seems to have moved on to be = strictly a JSEP discussion) >>=20 >> I seem to recall there was a plan to revisit the 5245/5245bis = reference question in general when Cluster 238 starts to break loose, = and let the RFC Editor fix it. Is that still the case? (Or am I = confused?) >>=20 >> Ben. >=20 > We did agree to discuss it when we got closer but it is not just an = issue of what order things get published in or if they block or not, it = is an issue of which protocol we use as that are not the same thing. Sure, that=E2=80=99s what I meant by =E2=80=9Crevisit=E2=80=9D. Ben. --Apple-Mail=_DACA8CA9-AB57-4082-BA36-1112F9BAB250 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlrzDXgACgkQgFZKbJXz 1A0q/g/+M6Qb5rozQwjG68s87TZ7ZnS72l15AjDH68U93QFGRwuw7GiZuH+19evG NcQY30dZKSGd107g2gapGxrpdWcYPMrIsciufevJSBJsV+EV6+6i+eokym3XcHxg A1W/oopvMJ20K01+EApbv72HO543vGzqpaS0xXpQGkri4cmUjYqqb9RLq0D2+5Lx spG3pjon94IDMyKhpQf/8ADW1gKooF/SXd10Xf7C8yswTDGsyAr4/johFAsdVjy1 RM5dwmYf7EbMKnzje4K96alTPbJSC3rkk9gPWqtKx+wk5m8PFbl9zvOP9l/H4NHs R2ZEE7EHEOm+9fna0s/bzv+OR8w+j1CjeVrO6VgKxtI1gAxawx8EHdYHeyU6+u1b baz66BfSwIyeZ0Wylk30O5iyoGIPOjVMUAbphJOt6jY1dkxrSljRO/MBSkMKO6mP wf4ewxROGjS1hrvcT8xCpQpKikObrhaB8iCtLGW26eua4pfRLyx99qBcKrn0Upil jr4hcl5QGtVwhwR+Yrnv7Qjhe+BbQnqGnEAo18Ym7HmjeFWp5GsWFSA1+mfgMMMW eOa+XX8azAy9mD1JXG+pWIwGSwGFb/oeOuVicT2etU5gzvGPi/o5Ah/er10SfBBx mu/VVOIsKGZSIFAeg1ChWjqbiFryRtWk/9ReN4V0BVdLeFeVFaU= =sjKU -----END PGP SIGNATURE----- --Apple-Mail=_DACA8CA9-AB57-4082-BA36-1112F9BAB250-- From nobody Wed May 9 13:46: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 2402A12E04A for ; Wed, 9 May 2018 13:46:32 -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 tSCFl2muv9M1 for ; Wed, 9 May 2018 13:46:31 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBECE12DA6C for ; Wed, 9 May 2018 13:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525898786; 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=+mRS7STS2lpJGIvEdBC+3fCBuRIAoe3X82xRxmt3x40=; b=QdqRzJ58WrqG70D/0NRJCdny3NXSHllT1Xq118GGZvoK08jpnpsYNCzW5w8iApns As7vYqePjHW7Q1oVRiBzss17gsxqsWB0LuRkvm6W9pYvrqv+qsqblT4laMF1Bmgr TPgmL6CDOV6+u/ZkSPFMGXAmIirukRChWarCoMuGTNI=; X-AuditID: c1b4fb30-2a5ff70000006e0c-3a-5af35e213b8a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.51.28172.12E53FA5; Wed, 9 May 2018 22:46:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Wed, 9 May 2018 22:46:25 +0200 From: Christer Holmberg To: "Cullen Jennings (fluffy)" CC: Ben Campbell , "mmusic-chairs@ietf.org" , Eric Rescorla , mmusic WG , "ice@ietf.org" , RTCWeb IETF , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [Ice] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHTy2yX73Ehi4UWF02QdXKK9x8zEKPvKNAAgAAAqICAAAKUAIAAAkMAgAAC5ICAAAKPAIAABSyAgAABrACAAA6TAIAAAI6AgAAWLYCAAUXTgIAAFRIAgA3/bYD///x6AIAAXRFN///2vYCAAnGPMIAbnZwAgAC5G4CAABtpgIAAORYAgAAY7ACAADI8QIAA9U0AgAgtFQCAAH+FkA== Date: Wed, 9 May 2018 20:46:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EBD2A6@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <8AB44737-5B8B-421C-9A3E-54A8183BCBBD@cisco.com> In-Reply-To: <8AB44737-5B8B-421C-9A3E-54A8183BCBBD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7tK5S3Ocogyd/OC3md55mt/ixdjmz xYrX59gtOiazWXy7UGsx489EZovzO9czWUxd/pjFYu2/dnYHTo8pvzeyeixZ8pPJY9bOJywe kx+3MQewRHHZpKTmZJalFunbJXBl3L22nbngMEfFn11zmRoY77J1MXJySAiYSHy6dgzMFhI4 wiix/1tBFyMXkL2IUWLVxweMXYwcHGwCFhLd/7RBakQEDCWa9sxjAqlhFjjLJNHTMYkVJCEs UCax4fs1sHoRgXKJl58NQGpEBB4xSnxdspwJpIZFQEViwt077CA2r4CvxIG1TUwQy6bxSsy4 tIoVpJlTwFZi8/cEkBpGATGJ76fWgPUyC4hL3HoynwniaAGJJXvOM0PYohIvH/9jhbCVJJZP 28IOUa8ncWPqFDYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIHRd3DLb4MdjC+fOx5iFOBgVOLhdff4HCXEmlhWXJl7iFGC g1lJhPf/g09RQrwpiZVVqUX58UWlOanFhxilOViUxHkt/DZHCQmkJ5akZqemFqQWwWSZODil Ghjd2vtnlXS/4e6ykZj1bsaRBe/fBO1p2Pn7p9m7S8EOa4Kdo6JnTjgiYfJN3d9H331BacP3 TdPXJ/cYaHXnZgs0sHr/6DWYa+qsur2rb47Xw7pLW0MOBBRfv8Op8n7Ggs0Pnts/1w/St8n1 evPu/8LbKx5Inr+s3558PDbm5Bvn9Vl3V738e6FPiaU4I9FQi7moOBEAFM6uproCAAA= Archived-At: Subject: Re: [rtcweb] [Ice] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Wed, 09 May 2018 20:46:33 -0000 Hi, >> Regarding core ICE, I still think we shall replace the RFC5245 reference >> with a reference to draft-5245bis, for the following technical reasons: > > I would view this as a huge changes that would need some pretty significa= nt testing and discussion in the=20 > WG. Right now, as far as I can tell the browser have implemented ice not = bis. So, "the browser" supports e.g., both types of nomination? > I would like WebRTC 1.0 to be what people have implemented - the reason i= t is ice not bis is it is unclear if bis performs as wells as ice.=A0 I assume our primary task is not to document what has been implemented, but= to provide procedures on how to implement things. As I said earlier, e.g., many of the trickle ICE procedures are based on th= e 5245bis procedures. If you want to implement trickle based on RFC 5245 th= ere are details and procedures that you will have to figure out yourself, b= ecause they are not documented, which means that different implementations = likely will do things in different ways. Regards, Christer From nobody Wed May 9 13:51:51 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 7CDEB12DB6B for ; Wed, 9 May 2018 13:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ApJr0ENbxUWS for ; Wed, 9 May 2018 13:51:41 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 B2AA012E892 for ; Wed, 9 May 2018 13:51:24 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id z4-v6so547019iof.5 for ; Wed, 09 May 2018 13:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=kLL4j85bmrgWQz/7oHinBk7kRiQypiMTkR7HPb+FStE=; b=IqKR7TeR/9CXacsT2IY75oHt0KZCIgYSqtVICGqyNXD40pYYwUKN4VVjx5XqU2LP5p xMNcv5xCrHrnXY9G/VMJ0bbuOzx2oYhjk4BNK12bZnQGSaOgBNY7xIdoiEfwijfW1+N6 cx2FgMeNoSds89mh0UdjeOAr47N2NRl/keF8o= 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; bh=kLL4j85bmrgWQz/7oHinBk7kRiQypiMTkR7HPb+FStE=; b=uYFHpy6wcSfcW1W+o3Aimyrvr+/9AjZOQyqdy4CsvlzVevPs0OkzJn3CmgF4V/1dZx 212hDCn4vhjIeVzY2JOQhsEVm6x8JBppdew+s8WvJL2VN0dM3oJ2VW4/qeXP4l+ALZ8/ gxV0lk6yPOooWKVLOQgqtgUPYrwFB8iWeEnB4yqgH/P2mNyvL8KXksh4j9W4YMF0fVHx 1nEt+KQoHcPKzI8PK0ZbjwHqrwe4x8NoPrPfeHEYUXUl4KBNoQ51D7NcS4hd2ZryEi7O DsuCpGYEuQpOrkLxUFSQX3Fj4j5dF1NUuENJZi0tmmVzh/RvzUddTxBh+SJy3VNG76i2 Jp0w== X-Gm-Message-State: ALQs6tBZz4G5pWV4bqzuQF41jyAw9KbK4b6Y/5oQLIPRH1id9E4Jruc8 YPTUZGUHQGjzRxVXWwXx61pujg== X-Google-Smtp-Source: AB8JxZoxl64YcvTHOMaQM18LBeuCZ1J5N5V++CJVx3NEPqQhu56gYo9FWqJHKFPPnC90epQsOXN/Bg== X-Received: by 2002:a6b:8f51:: with SMTP id r78-v6mr49601685iod.233.1525899084057; Wed, 09 May 2018 13:51:24 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id m16-v6sm13473247iob.69.2018.05.09.13.51.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 13:51:22 -0700 (PDT) To: Christer Holmberg , "Cullen Jennings (fluffy)" Cc: Ben Campbell , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , RTCWeb IETF , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <8AB44737-5B8B-421C-9A3E-54A8183BCBBD@cisco.com> <7594FB04B1934943A5C02806D1A2204B72EBD2A6@ESESSMB109.ericsson.se> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Wed, 9 May 2018 14:51:21 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EBD2A6@ESESSMB109.ericsson.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g7gqvuhwetTRoR0RuxTs2sqSe6emN7MJV" Archived-At: Subject: Re: [rtcweb] [MMUSIC] [Ice] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Wed, 09 May 2018 20:51:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g7gqvuhwetTRoR0RuxTs2sqSe6emN7MJV Content-Type: multipart/mixed; boundary="EKnQO5mXKLsg69JrwE3qgRSepZM8310J4"; protected-headers="v1" From: Peter Saint-Andre To: Christer Holmberg , "Cullen Jennings (fluffy)" Cc: Ben Campbell , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , RTCWeb IETF , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Message-ID: Subject: Re: [MMUSIC] [Ice] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <6b2e132d-88ee-9274-b19d-c24937e46ad2@nostrum.com> <07de7983-293d-f97e-8ca9-08713ce48e1c@mozilla.com> <3E157C5A-A2CD-4361-9BFE-B87EA71D8FFD@nostrum.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <8AB44737-5B8B-421C-9A3E-54A8183BCBBD@cisco.com> <7594FB04B1934943A5C02806D1A2204B72EBD2A6@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EBD2A6@ESESSMB109.ericsson.se> --EKnQO5mXKLsg69JrwE3qgRSepZM8310J4 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 5/9/18 2:46 PM, Christer Holmberg wrote: > Hi, >=20 >>> Regarding core ICE, I still think we shall replace the RFC5245 refere= nce >>> with a reference to draft-5245bis, for the following technical reason= s: >> >> I would view this as a huge changes that would need some pretty signif= icant testing and discussion in the=20 >> WG. Right now, as far as I can tell the browser have implemented ice n= ot bis. >=20 > So, "the browser" supports e.g., both types of nomination? >=20 >> I would like WebRTC 1.0 to be what people have implemented - the reaso= n it is ice not bis is it is unclear if bis performs as wells as ice.=C2=A0= >=20 > I assume our primary task is not to document what has been implemented,= but to provide procedures on how to implement things. >=20 > As I said earlier, e.g., many of the trickle ICE procedures are based o= n the 5245bis procedures. If you want to implement trickle based on RFC 5= 245 there are details and procedures that you will have to figure out you= rself, because they are not documented, which means that different implem= entations likely will do things in different ways. Although the trickle *technique* goes back to 2005 and thus predates the publication of RFC 5245 by ~5 years, formally speaking you are correct about alignment of details between draft-ietf-ice-trickle and 5245bis. Peter --EKnQO5mXKLsg69JrwE3qgRSepZM8310J4-- --g7gqvuhwetTRoR0RuxTs2sqSe6emN7MJV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrzX0kACgkQZWGMGH9o FKlB1w/+KB65cSvZHlCU8psd3Uxfc3s2Yv/2a/IWDcH0YeTQnzcO27/LwFuZY+4+ vAD/F6yQL7TU5SNGAjrEAUKZLZLm6bfX/sYzNmIrXMNzsKN7Ulz0V7zynAS3LxD7 MkFety9aOtjenvVFqgcKsqPhmzS/9LB7pJWiTHQyHGNLhKBmCM9ccMXxgASMHTz8 f29039t9ZzBQIwrhyRI7uct3QpeD45iLi2a8ADlTk7zEj8Dn8Lsc1qAGgOSwvmtn SWKZIqqyInCaSv4elydHu5mS1J0r22BTVTYSaEuPHj6/Khf5XDlaRCDIE/IcKKU9 Nbh0mbxv+uaP8H0oumjk02u94mcwZygP2Oxxizz8Cf6XytGn/XCTCsmnLK2NR7FJ Mu9fawLIuSAQGiFOHLvgSUWtFUp7RIjGfLV+shCMLgEbd3LE7wd9HMkY2kVDIVQ0 POqaUTWqTSb1xAbPQTWO3QshvLdrZtNne4q6qWKFM92gf7ptNaokjoPpQMx0m7wr jQS4thzz1M6tP3iqTRX/IDBVQUkMuTO/YGJQ6HTRbeMeYjVuAB6gdA1ULcpFCtVh A4xBORghtc+JLvNzyezadH1xf21pHqH4Md4UfSpJKamYXI8hlQ1wqDsaS8CaoGXB CXMZbLD7oKenWYkH4Nx31a3Id5GM5NYYwWW7YRxFv5uV+WXFaX0= =kkLN -----END PGP SIGNATURE----- --g7gqvuhwetTRoR0RuxTs2sqSe6emN7MJV-- From nobody Wed May 9 14:02:51 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 AB75B12E057 for ; Wed, 9 May 2018 14:02:35 -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 Yvql15ZH4aEH for ; Wed, 9 May 2018 14:02:34 -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 9F7F812DDD0 for ; Wed, 9 May 2018 14:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525899748; 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=M5z81jTlMRE2sliTBwpNpdRwG4yagcVuxC/Ma/MRs9o=; b=g+pID1CAZ5NOxPF4imMj3mZ8VQ/JVR6xVpktYUAtz3A9i4YUkjFm3AU3MACUXECE /PAvnf1da7/r2G6+cBdgAGG/VkieX9NLXRGH04BWLsP/5BkkDPG33yl1XiYpC/Q7 NSmDqguOLVVqCNH7DT2goeUbBjOqhBbEZgeCwKBtKIE=; X-AuditID: c1b4fb3a-035ff70000005668-5d-5af361e4b0ad Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1F.E2.22120.4E163FA5; Wed, 9 May 2018 23:02:28 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Wed, 9 May 2018 23:02:27 +0200 From: Christer Holmberg To: Peter Saint-Andre , "Cullen Jennings (fluffy)" CC: Ben Campbell , mmusic WG , "mmusic-chairs@ietf.org" , "ice@ietf.org" , RTCWeb IETF , The IESG , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" Thread-Topic: [MMUSIC] [Ice] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) Thread-Index: AQHT59d+D5H/R27sPUmpE1r4kpPdwqQn4Y9A Date: Wed, 9 May 2018 21:02:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EBD3B9@ESESSMB109.ericsson.se> References: <152274059303.13991.7963954297164952826.idtracker@ietfa.amsl.com> <8BBC3434-DEA2-437B-AB32-DA113AE085AA@nostrum.com> <7B683890-F38A-4D78-BEAC-02F6F90025D1@ericsson.com> <14DA7FB6-2F60-4106-BC80-8F43CA621740@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72E72F58@ESESSMB109.ericsson.se> <0610F9B5-3DE5-4580-B2BB-9F70CDA99B26@nostrum.com> <7594FB04B1934943A5C02806D1A2204B72EAF553@ESESSMB109.ericsson.se> <8AB44737-5B8B-421C-9A3E-54A8183BCBBD@cisco.com> <7594FB04B1934943A5C02806D1A2204B72EBD2A6@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7tO6TxM9RBu/mKVnM7zzNbvFj7XJm i47JbBbfLtRazPgzkdni/M71TBZTlz9msVj7r53d4tnKU4wOnB5Tfm9k9Viy5CeTR9+BLlaP WTufsASwRHHZpKTmZJalFunbJXBlzLm0iKngE3/FrX8TmRsY9/B3MXJySAiYSLx5sIu5i5GL Q0jgCKPElKs3WCCcRYwSK/ceYe1i5OBgE7CQ6P6nDdIgIhAjsfHEWnaQGmaBtUwS37qPs4Ik hAXKJN78Xc8CUi8iUC4xc74cRL2RxNnVa9lAbBYBFYmlGw4ygdi8Ar4Svxfvh9rVwiHx48c5 RpAEp4C9xNWHb1lAbEYBMYnvp9aANTALiEvcejKfCeJqAYkle84zQ9iiEi8f/2OFsJUklk/b wg5yA7OApsT6XfoQrYoSU7ofskPsFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGEWLU4uL c9ONjPRSizKTi4vz8/TyUks2MQJj7+CW31Y7GA8+dzzEKMDBqMTD+9T9c5QQa2JZcWXuIUYJ DmYlEd7H8UAh3pTEyqrUovz4otKc1OJDjNIcLErivE5pFlFCAumJJanZqakFqUUwWSYOTqkG Rvn1bvmyC/L8TaI+BTMaLq5ZNMfF9YFZnUzsnMsvXDcVlK12Ohb8V+CLuIO92Ff5Mynuvf+u X94U9cnMS77x4abOyGVuF3LFz3W62ds5/DW2Ofu3XXGN7hLNyNnv49eJzRZIntYfEvX637r5 /W7X3RRezzPq+LLh8Ncdia94psY1Tgr+xW4frsRSnJFoqMVcVJwIANtkU6G5AgAA Archived-At: Subject: Re: [rtcweb] [MMUSIC] [Ice] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT) 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: Wed, 09 May 2018 21:02:36 -0000 SGksDQoNCj4+Pj4gUmVnYXJkaW5nIGNvcmUgSUNFLCBJIHN0aWxsIHRoaW5rIHdlIHNoYWxsIHJl cGxhY2UgdGhlIFJGQzUyNDUgDQo+Pj4+IHJlZmVyZW5jZSB3aXRoIGEgcmVmZXJlbmNlIHRvIGRy YWZ0LTUyNDViaXMsIGZvciB0aGUgZm9sbG93aW5nIHRlY2huaWNhbCByZWFzb25zOg0KPj4+DQo+ Pj4gSSB3b3VsZCB2aWV3IHRoaXMgYXMgYSBodWdlIGNoYW5nZXMgdGhhdCB3b3VsZCBuZWVkIHNv bWUgcHJldHR5IA0KPj4+IHNpZ25pZmljYW50IHRlc3RpbmcgYW5kIGRpc2N1c3Npb24gaW4gdGhl IFdHLiBSaWdodCBub3csIGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBicm93c2VyIGhhdmUgaW1w bGVtZW50ZWQgaWNlIG5vdCBiaXMuDQo+PiANCj4+IFNvLCAidGhlIGJyb3dzZXIiIHN1cHBvcnRz IGUuZy4sIGJvdGggdHlwZXMgb2Ygbm9taW5hdGlvbj8NCj4+IA0KPj4+IEkgd291bGQgbGlrZSBX ZWJSVEMgMS4wIHRvIGJlIHdoYXQgcGVvcGxlIGhhdmUgaW1wbGVtZW50ZWQgLSB0aGUgDQo+Pj4g cmVhc29uIGl0IGlzIGljZSBub3QgYmlzIGlzIGl0IGlzIHVuY2xlYXIgaWYgYmlzIHBlcmZvcm1z IGFzIHdlbGxzIGFzIGljZS4NCj4+IA0KPj4gSSBhc3N1bWUgb3VyIHByaW1hcnkgdGFzayBpcyBu b3QgdG8gZG9jdW1lbnQgd2hhdCBoYXMgYmVlbiBpbXBsZW1lbnRlZCwgYnV0IHRvIHByb3ZpZGUg cHJvY2VkdXJlcyBvbiBob3cgdG8gaW1wbGVtZW50IHRoaW5ncy4NCj4+IA0KPj4gQXMgSSBzYWlk IGVhcmxpZXIsIGUuZy4sIG1hbnkgb2YgdGhlIHRyaWNrbGUgSUNFIHByb2NlZHVyZXMgYXJlIGJh c2VkIG9uIHRoZSA1MjQ1YmlzIHByb2NlZHVyZXMuIElmIHlvdSB3YW50IHRvIGltcGxlbWVudCAN Cj4+IHRyaWNrbGUgYmFzZWQgb24gUkZDIDUyNDUgdGhlcmUgYXJlIGRldGFpbHMgYW5kIHByb2Nl ZHVyZXMgdGhhdCB5b3Ugd2lsbCBoYXZlIHRvIGZpZ3VyZSBvdXQgeW91cnNlbGYsIGJlY2F1c2Ug dGhleSBhcmUgbm90IA0KPj4gZG9jdW1lbnRlZCwgd2hpY2ggbWVhbnMgdGhhdCBkaWZmZXJlbnQg aW1wbGVtZW50YXRpb25zIGxpa2VseSB3aWxsIGRvIHRoaW5ncyBpbiBkaWZmZXJlbnQgd2F5cy4N Cj4NCj4gQWx0aG91Z2ggdGhlIHRyaWNrbGUgKnRlY2huaXF1ZSogZ29lcyBiYWNrIHRvIDIwMDUg YW5kIHRodXMgcHJlZGF0ZXMgdGhlIHB1YmxpY2F0aW9uIG9mIFJGQyA1MjQ1IGJ5IH41IHllYXJz LCBmb3JtYWxseSBzcGVha2luZyANCj4geW91IGFyZSBjb3JyZWN0IGFib3V0IGFsaWdubWVudCBv ZiBkZXRhaWxzIGJldHdlZW4gZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSBhbmQgNTI0NWJpcy4NCg0K Q29ycmVjdC4gVGhlIHRlY2huaXF1ZSBpdHNlbGYgZ29lcyB3YXkgYmFjaywgYnV0IHRoZSBzdGFu ZGFyZGl6ZWQgcHJvY2VkdXJlcyAoZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSkgZm9yIGltcGxlbWVu dGluZyBpdCBhcmUgYmFzZWQgb24gNTI0NWJpcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCiAN Cg0K From nobody Wed May 9 18:44: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 8AAEA12D870 for ; Wed, 9 May 2018 18:44:39 -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 6nK45KggwHo7 for ; Wed, 9 May 2018 18:44:38 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 74C6612E86A for ; Wed, 9 May 2018 18:44:36 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id m11-v6so567295otf.3 for ; Wed, 09 May 2018 18:44:36 -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:content-transfer-encoding; bh=UnPADZbUsyoroxBcxTgkKkbvvMbNDrvLbCEVK9o+Ic4=; b=OawcojxSH/4VTZKBTwlwuTJDRNuYXrOcu2FvJc7SD8l8RDFmR56sBU6kn7GVG+epFB sQ3U03FnrwRYW3Rky1+r32W/8my+qA/vN/ZlracFEJ5DuZfB+xrvMAdC5B/z07x1xIXz lFCS/oBmsuUviRHHnlnvmt2IBAo1wrEPRiVpMS27BgHPaCr354atV8fnA5bIluAdjnJV 9xHOx+plR7yA/HAYKIeGCp1XONq0rdjpEWLxQBeDDNmVRyzEmRrADD0LJ01ZmuAl0W1X mh741YY2B1zbqT4h9rFojXc8uajbm3U7hr8b2hdjYEZcivsQ+tgJNUeTqFbY3gQM8ZY3 Dijg== 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:content-transfer-encoding; bh=UnPADZbUsyoroxBcxTgkKkbvvMbNDrvLbCEVK9o+Ic4=; b=Hu9hvEh7JFNXoz6Relv7R29J3Onf721B1PHovfYwfyiv0UM0yhQ2YJGcbNkf9sPptR 0zl7kYByJaTD9oMrRo0g7tQmjiPzaAN/OSuAgsNLszOAWHzA08KF3LG7LLyP6uuyaoix O5pp3FFUEa2ZfP+lKjeJyqkxrKW5yhs2lahnMePvOZzD/1gr2OtHP4Md1uTmamFHM54Y 46uRAcwNUwgOP3saBktyTi5/aW1KiXgSIohP9KIIu0KxL+zug/Z4jkHChAJQGoU1urzL L3OpZthjJrqoFkAFpVWizaVnp5Y3RanPxO77qppRDUN5kS4Y6mDbv0h45eHclam9c0ht VZYA== X-Gm-Message-State: ALQs6tCWBWhwRZecbcDqMh6arMDHLynQH2Z/omJY2DsVj+gxavD/jDT9 MlqVOKbdmIS9JnJwUAd3Wtpew5/y5FS5O1xegiw= X-Google-Smtp-Source: AB8JxZoEyifu6hll5AXwYAG5LXQD7clGn7sLS7KJmnsGT+yAa/xSAUxX7X5ldH3uzYTbLGSd7aOy/0d6JwmL1BqazOA= X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr20694824otk.392.1525916675745; Wed, 09 May 2018 18:44:35 -0700 (PDT) MIME-Version: 1.0 References: <7A02A97A-56AC-45A1-AB86-C77B6263D799@iii.ca> <3FE62B51-C01D-4238-902D-6867ABF8549E@iii.ca> <8C7FC320-724C-435E-AF8D-340ACB20DB02@iii.ca> <7ed02fe1-69cc-f774-f61f-ee79f2e9a61d@alvestrand.no> <921E50B5-4074-4099-8C2B-27A68364DC2E@iii.ca> In-Reply-To: <921E50B5-4074-4099-8C2B-27A68364DC2E@iii.ca> From: Martin Thomson Date: Thu, 10 May 2018 01:44:25 +0000 Message-ID: To: Cullen Jennings Cc: Harald Alvestrand , RTCWeb IETF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Thu, 10 May 2018 01:44:40 -0000 On Thu, May 10, 2018 at 12:55 AM Cullen Jennings wrote: > On May 2, 2018, at 7:21 PM, Martin Thomson wrote: >> An IdP is given the origin of the requesting site. That allows it to make >> authorization decisions on that basis. > Really ? I don=E2=80=99t think it can trust that. I can easily get my b= rowser to send whatever origin I want to the IdP. I think it needs to do the usual OAuth like things to authenticate the user. Yes, it can trust that. Of course it still needs to authenticate the user, but the origin it receives from the browser needs to be correct. There's the attack where the IdP is instantiated by an attacker who controls absolutely everything, including the origin, but the defense there is that the attacker would also have to provide the IdP with authentication credentials for the user and that's where it breaks down for the attacker. From nobody Thu May 10 07:40: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 AD12012D9FE for ; Thu, 10 May 2018 07:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Lu3HqEGNAopK for ; Thu, 10 May 2018 07:39:57 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9B912D951 for ; Thu, 10 May 2018 07:39:56 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z75-v6so1723770qkb.6 for ; Thu, 10 May 2018 07:39:56 -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=XLdOttqJ7ABX/IkdXh1vSSCGDApR/qoX0ul6Iyg8naw=; b=CEVzpHIyBxVfTdOGMWLd/mO5X+3rY0Dx7mld8hO31sfstXjbKX+T2xtVyfmMz3w/RC kQPjbJdRzdGPBSOZD0yAA4cbhaLV/PYAxla8x9a6wNYjczjYPBWl733Gg0wziUg0Ocum VPfstE2Wfl7meZwxCd7Jmbu4gr3PHdkWkchH4= 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=XLdOttqJ7ABX/IkdXh1vSSCGDApR/qoX0ul6Iyg8naw=; b=jjxfmO8xsqsMrhnKZE+ZJU+Atw7un8xxRW0BTG7RSlFEnDF2+ykGCrtX00mgl5j90V Ol5tTPH6ziGjj/sqxCdgx5rMwo9soCV5Vh4pk5N0encWGwXs6AbcycmIdrZxYT+WLzol yC2saGdpvwiiJA4qUmj6ghdc/RzLI+9Npr4H7YGJfvXpRHc9QiFagSZxwq9BzPDeiwXD lr9sYEa2uyFo905Nl7ODvpFBOpTshl7/4lAJ93UznuzoMejHKEi7N1sXBKnlpnHm7utb 0R7f357i+x3rmwv/YecOdU+ztCsat88loAUfnF+w0iWFHRN8c8+kx3EpGJ2rUzUOKK1r jYFA== X-Gm-Message-State: ALKqPwdMO6IOFpyVaSirNpswUvTevILpW9D6AFx4kgpVbi7gD++ZWZAf Vic0QG1n38goCPuw0utosdXWPA== X-Google-Smtp-Source: AB8JxZrd21R46kfUTeVFbTSu3cX3Ffv0C2GtfH9hwo9Ev6spgI+Majfh2xjol6UO8IHd1W1rB2S6Ew== X-Received: by 2002:ae9:f408:: with SMTP id y8-v6mr1391852qkl.82.1525963195748; Thu, 10 May 2018 07:39:55 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id d197-v6sm655469qkb.9.2018.05.10.07.39.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 07:39:54 -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: Date: Thu, 10 May 2018 10:39:53 -0400 Cc: Martin Thomson , Eric Rescorla , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christer Holmberg X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Thu, 10 May 2018 14:39:59 -0000 Just wanted to make sure we don=E2=80=99t loose these. > On Apr 27, 2018, at 02:10, Christer Holmberg = wrote: >=20 > Hi, >=20 >>> A couple of questions on the SDP identity attribute. >>>=20 >>> Q1: >>> --- >>>=20 >>> The draft lacks the offer/answer procedure sections (generate offer, >>> generate answer, modify session etc) for the attribute, which I = think >>> should be added. My question is regarding the following statement, = which >>> seems to indicate that the attribute is only used in offers: >>>=20 >>> "Implementations SHOULD only include a single identity attribute in = an >>> offer=C2=B2 (there is no text about including the attribute in an = answer) >>=20 >> This is about what to do if you include a=3Didentity not about = whether to >> include it. >=20 > When new SDP attributes are defined, there needs to be offer/answer > procedures. Because, I assume the attribute can be used on the wire, = in > SDP offers and answers? >=20 > Also, if the attribute is scoped to WebRTC, or to some specific = security > solutions, I think that also needs to be covered. >=20 >=20 >>> However, in draft-ietf-rtcweb-sdp it is included in both the offer = and >>> answer. >>=20 >> I think that draft-ietf-rtcweb-sdp includes them in both the offer = and >> the answer because the examples are using the WEBRTC Identity = mechanism. >> I think this is consistent with what is in both draft-ietf-rtcweb-sdp = and >> draft-ietf-rtcweb-jsep: >>=20 >> If WebRTC identity is being used, an "a=3Didentity" line as >> described in [I-D.ietf-rtcweb-security-arch], Section 5. >=20 >=20 > That sentence is only for the initial offer. Unless I=E2=80=99ve = missed it, there > is no text about a=3Didentity regarding answers. Would making the following two change make it clearer that a=3Didentity = can be included in either/both: 1) s.5.6.3 (r/SDP offer/exchange transaction/SDP offer/answer exchange) OLD: An identity assertion binds the user's identity (as asserted by the IdP) to the SDP offer/exchange transaction and specifically to the media. NEW: An identity assertion binds the user's identity (as asserted by the IdP) to the SDP offer/answer exchange and specifically to the media. 2) s.5.6.4.1 OLD: Once an IdP has generated an assertion, it is attached to the SDP message. This is done by adding a new identity attribute to the SDP. NEW: Once an IdP has generated an assertion, it is attached to the SDP offer/answer message. This is done by adding a new identity = attribute to the SDP. or we could go even further: NEW: Once an IdP has generated an assertion, it is attached to the SDP offer/answer message. This is done by adding a new identity = attribute to the SDP; the offer includes the caller=E2=80=99s assertion; the = answer includes the callee=E2=80=99s assertion. Now as far as what more might be said to scope the attribute to WebRTC, = I=E2=80=99m pretty sure that=E2=80=99s covered in two ways: 1) If folks are coming at this attribute from the IANA registry, then = the =E2=80=9CAppropriate Values=E2=80=9D registry entry points to = s5.6.4.2 of this document and that section pretty much gets you to using = IdP as described in this draft. 2) If folks are coming at it from reading the draft/RFC, then well = it=E2=80=99s pretty clear that this attribute is used with IdPs. >>> Q2: >>> --- >>>=20 >>> Also, the mux category is missing = (draft-ietf-mmusic-sdp-mux-attributes >>> also covers session-level attributes). I assume it is =C2=B3NORMAL=C2=B2= . >>=20 >> I think this mans adding: >>=20 >> Mux Category: NORMAL >>=20 >> to the IANA registration? >=20 > Correct. But, NORMAL is just my assumption - I want people to confirm > whether that is correct :) I submitted PR to address this: https://github.com/rtcweb-wg/security-arch/pull/66 I included =E2=80=9CNORMAL=E2=80=9D, but if somebody thinks this is = wrong I can change it.=20 spt > Regards, >=20 > Christer >=20 >=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 23/04/18 01:47, "rtcweb on behalf of Martin Thomson" >>> = wrote: >>>=20 >>>> tls-id is connection-based (i.e., it applies to a single bundle), >>>> whereas identity is session-based. That was my initial thought, = but >>>> then we have to deal with the 1:N problem there. The simplest >>>> approach might be to move a=3Didentity to the bundle, but that = leads to >>>> some interesting downstream effects. You probably want to avoid >>>> having multiple identities in the same RTCPeerConnection, for >>>> instance. >>>>=20 >>>> On Sat, Apr 21, 2018 at 11:10 AM, Eric Rescorla = wrote: >>>>>=20 >>>>>=20 >>>>> On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner = wrote: >>>>>>=20 >>>>>> The WGLC for this document has ended. I think it was really good >>>>>> that >>>>>> @ >>>>>> IETF101 the IdP hackathon happened because it looked like they = might >>>>>> have >>>>>> uncovered something to be changed in our document and possibly in = the >>>>>> webrtc-pc draft; see the [0] thread. As the Shepherd trying to = drive >>>>>> this >>>>>> to closure, we need to we need to decide what changes might be = made >>>>>> in >>>>>> draft-ietf-rtcweb-security-arch. In that thread, I saw two = things >>>>>> that we >>>>>> might change (both from mt): >>>>>>=20 >>>>>> 0) More text to address a linkability concern: >>>>>>=20 >>>>>> As a practical matter, if the browser were to use the same >>>>>> certificate >>>>>> for multiple origins, then it would create a massive privacy = problem >>>>>> that enables linkability (aka user tracking). I couldn't find = that >>>>>> written down, but I thought it was. If it isn't written down, = then >>>>>> we >>>>>> should correct that. >>>>>=20 >>>>>=20 >>>>> Isn't this the relevant text: >>>>> " >>>>>=20 >>>>> API Requirement: Unless the user specifically configures an >>>>> external >>>>> key pair, different key pairs MUST be used for each origin. >>>>> (This >>>>> avoids creating a super-cookie.) >>>>>=20 >>>>> " >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> I actually think this is basically covered here: >>>>>>=20 >>>>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4. >>>>>> 1 >>>>>> But want to make sure others agree: >>>>>>=20 >>>>>> 1) Tweak protocol to include an identifier to prevent reuse of >>>>>> assertion >>>>>> on every RTCPeerConnection: >>>>>>=20 >>>>>> More complex sites frequently generate multiple RTCPeerConnection >>>>>> instances for their communications, especially for group >>>>>> conversations. If the browser requests an assertion once and = they >>>>>> use >>>>>> that value for every RTCPeerConnection, then that's OK. =46rom = my >>>>>> perspective, I would be happy modifying the protocol to include = an >>>>>> identifier and prevent that; for this the IdP can use caching or = its >>>>>> local storage. >>>>>>=20 >>>>>> So, what would that look like? >>>>>=20 >>>>>=20 >>>>> Wouldn't it be sufficient to include the tls-id in the identity >>>>> binding? >>>>>=20 >>>>> -Ekr >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Did I miss anything else that needs to be addressed? >>>>>>=20 >>>>>> spt >>>>>>=20 >>>>>> [0] >>>>>>=20 >>>>>>=20 >>>>>> = https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYFrDw7j >>>>>> XE >>>>>> w >>>>>>=20 >>>>>>> On Mar 12, 2018, at 19:08, Sean Turner wrote: >>>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> This is the WGLC for the =C2=B3WebRTC Security Architecture=C2=B2 = draft >>>>>> available >>>>>>> @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. >>>>>> Please >>>>>>> review the draft and send your comments to this list by 2359UTC = on >>>>>> April >>>>>>> 6th, 2018. >>>>>>>=20 >>>>>>> Note the gh repo is here: >>>>>>> https://github.com/rtcweb-wg/security-arch >>>>>>>=20 >>>>>>> Thanks, >>>>>>> C/T/S >>>>>>=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 >>>>>=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 >>=20 >=20 From nobody Thu May 10 10:21: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 3A335126E01 for ; Thu, 10 May 2018 10:21:18 -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 gQEF7n_DslmP for ; Thu, 10 May 2018 10:21:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD03E124B17 for ; Thu, 10 May 2018 10:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525972873; 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=WYa7Fhp4ZDag4dCh5JoiDfBQF2KqhlOCZVazMUUVtX4=; b=J5C0Wicclyae+MclMrT8MYhQ/RuaVapyhTfGXjGt4BJde8S1Fkb/g4W0KwBmIkbP OT+oIIXIgyEkJT3Qnq9OmKzv/YMGyI156mSNGv3XazX2pSNpNTltdDPp9rEQBW1w X8YaoAkpq2OCPPg0hACCjh7q4ylUI53FrHfvwQQPgAY=; X-AuditID: c1b4fb3a-01dff70000005668-1c-5af47f895725 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AF.49.22120.98F74FA5; Thu, 10 May 2018 19:21:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0382.000; Thu, 10 May 2018 19:21:13 +0200 From: Christer Holmberg To: Sean Turner CC: Martin Thomson , Eric Rescorla , RTCWeb IETF Thread-Topic: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) Thread-Index: AQHT2ovhiDchN2k/30+uRrZXdqGfAqQOWzwAgAVK9ACAAJMRAIAUyaOAgABMNwA= Date: Thu, 10 May 2018 17:21:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EBE65A@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7jW5n/Zcog+lrTS1WvD7HbnHtzD9G i7X/2tktrqxqZHZg8dg56y67x5IlP5k8Jj9uY/Y4eJAxgCWKyyYlNSezLLVI3y6BK+Pe3XPs BQcSK+5PvMTawNgQ38XIySEhYCJxftcvti5GLg4hgSOMEi833mGFcBYzSlx6dY+9i5GDg03A QqL7nzZIg4iAgkTT0QesIDazQI7Esj+tLCD1wgJdjBIPOq4wgzgiAt2MEid23GeH6PCTODpp PpjNIqAqcf7mDWYQm1fAV2LJqYfMENuOM0v0TlsMVsQpYCvx8PJONhCbUUBM4vupNUwQ68Ql bj2ZzwRxt4DEkj3nmSFsUYmXj/+xQthKErNubWQCuZpZQFNi/S59iFZFiSndD9kh9gpKnJz5 hGUCo+gsJFNnIXTMQtIxC0nHAkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiB8XRwy2+r HYwHnzseYhTgYFTi4RWN/xIlxJpYVlyZe4hRgoNZSYT3x7nPUUK8KYmVValF+fFFpTmpxYcY pTlYlMR5ndIsooQE0hNLUrNTUwtSi2CyTBycUg2Mk3n27XdKentFWMFU1fzDq64d72aeuLK3 Wcj03vyA1kV7F/Hw89UeS6k5c6YiIrVjEvN54x3snkyL2G8eu84a/mf/6g1LkmekB98SVXlR +dbm0KVVHolzdlya7bck/nmPaH7Ekks5Llp7J4TcXc+vbfl15dJEtb/3nyjXRnceTODf5rgg 1fIysxJLcUaioRZzUXEiAJoxnB+jAgAA Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Thu, 10 May 2018 17:21:18 -0000 SGksDQoNCj4+Pj4gQSBjb3VwbGUgb2YgcXVlc3Rpb25zIG9uIHRoZSBTRFAgaWRlbnRpdHkgYXR0 cmlidXRlLg0KPj4+PiANCj4+Pj4gUTE6DQo+Pj4+IC0tLQ0KPj4+PiANCj4+Pj4gVGhlIGRyYWZ0 IGxhY2tzIHRoZSBvZmZlci9hbnN3ZXIgcHJvY2VkdXJlIHNlY3Rpb25zIChnZW5lcmF0ZSBvZmZl ciwgDQo+Pj4+IGdlbmVyYXRlIGFuc3dlciwgbW9kaWZ5IHNlc3Npb24gZXRjKSBmb3IgdGhlIGF0 dHJpYnV0ZSwgd2hpY2ggSSANCj4+Pj4gdGhpbmsgc2hvdWxkIGJlIGFkZGVkLiBNeSBxdWVzdGlv biBpcyByZWdhcmRpbmcgdGhlIGZvbGxvd2luZyANCj4+Pj4gc3RhdGVtZW50LCB3aGljaCBzZWVt cyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBhdHRyaWJ1dGUgaXMgb25seSB1c2VkIGluIG9mZmVyczoN Cj4+Pj4gDQo+Pj4+ICJJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIG9ubHkgaW5jbHVkZSBhIHNpbmds ZSBpZGVudGl0eSBhdHRyaWJ1dGUgaW4gDQo+Pj4+IGFuIG9mZmVywrIgKHRoZXJlIGlzIG5vIHRl eHQgYWJvdXQgaW5jbHVkaW5nIHRoZSBhdHRyaWJ1dGUgaW4gYW4gDQo+Pj4+IGFuc3dlcikNCj4+ PiANCj4+PiBUaGlzIGlzIGFib3V0IHdoYXQgdG8gZG8gaWYgeW91IGluY2x1ZGUgYT1pZGVudGl0 eSBub3QgYWJvdXQgd2hldGhlciANCj4+PiB0byBpbmNsdWRlIGl0Lg0KPj4gDQo+PiBXaGVuIG5l dyBTRFAgYXR0cmlidXRlcyBhcmUgZGVmaW5lZCwgdGhlcmUgbmVlZHMgdG8gYmUgb2ZmZXIvYW5z d2VyIA0KPj4gcHJvY2VkdXJlcy4gQmVjYXVzZSwgSSBhc3N1bWUgdGhlIGF0dHJpYnV0ZSBjYW4g YmUgdXNlZCBvbiB0aGUgd2lyZSwgDQo+PiBpbiBTRFAgb2ZmZXJzIGFuZCBhbnN3ZXJzPw0KPj4g DQo+PiBBbHNvLCBpZiB0aGUgYXR0cmlidXRlIGlzIHNjb3BlZCB0byBXZWJSVEMsIG9yIHRvIHNv bWUgc3BlY2lmaWMgDQo+PiBzZWN1cml0eSBzb2x1dGlvbnMsIEkgdGhpbmsgdGhhdCBhbHNvIG5l ZWRzIHRvIGJlIGNvdmVyZWQuDQo+PiANCj4+IA0KPj4+PiBIb3dldmVyLCBpbiBkcmFmdC1pZXRm LXJ0Y3dlYi1zZHAgaXQgaXMgaW5jbHVkZWQgaW4gYm90aCB0aGUgb2ZmZXIgDQo+Pj4+IGFuZCBh bnN3ZXIuDQo+Pj4gDQo+Pj4gSSB0aGluayB0aGF0IGRyYWZ0LWlldGYtcnRjd2ViLXNkcCBpbmNs dWRlcyB0aGVtIGluIGJvdGggdGhlIG9mZmVyIA0KPj4+IGFuZCB0aGUgYW5zd2VyIGJlY2F1c2Ug dGhlIGV4YW1wbGVzIGFyZSB1c2luZyB0aGUgV0VCUlRDIElkZW50aXR5IG1lY2hhbmlzbS4NCj4+ PiBJIHRoaW5rIHRoaXMgaXMgY29uc2lzdGVudCB3aXRoIHdoYXQgaXMgaW4gYm90aCBkcmFmdC1p ZXRmLXJ0Y3dlYi1zZHAgDQo+Pj4gYW5kIGRyYWZ0LWlldGYtcnRjd2ViLWpzZXA6DQo+Pj4gDQo+ Pj4gIElmIFdlYlJUQyBpZGVudGl0eSBpcyBiZWluZyB1c2VkLCBhbiAiYT1pZGVudGl0eSIgbGlu ZSBhcyAgZGVzY3JpYmVkIA0KPj4+IGluIFtJLUQuaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaF0s IFNlY3Rpb24gNS4NCj4+IA0KPj4gDQo+PiBUaGF0IHNlbnRlbmNlIGlzIG9ubHkgZm9yIHRoZSBp bml0aWFsIG9mZmVyLiBVbmxlc3MgSeKAmXZlIG1pc3NlZCBpdCwgDQo+PiB0aGVyZSBpcyBubyB0 ZXh0IGFib3V0IGE9aWRlbnRpdHkgcmVnYXJkaW5nIGFuc3dlcnMuDQo+DQo+IFdvdWxkIG1ha2lu ZyB0aGUgZm9sbG93aW5nIHR3byBjaGFuZ2UgbWFrZSBpdCBjbGVhcmVyIHRoYXQgYT1pZGVudGl0 eSBjYW4gYmUgaW5jbHVkZWQgaW4gZWl0aGVyL2JvdGg6DQo+DQo+IDEpIHMuNS42LjMgKHIvU0RQ IG9mZmVyL2V4Y2hhbmdlIHRyYW5zYWN0aW9uL1NEUCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UpDQo+ DQo+IE9MRDoNCj4NCj4gICBBbiBpZGVudGl0eSBhc3NlcnRpb24gYmluZHMgdGhlIHVzZXIncyBp ZGVudGl0eSAoYXMgYXNzZXJ0ZWQgYnkgdGhlDQo+ICAgSWRQKSB0byB0aGUgU0RQIG9mZmVyL2V4 Y2hhbmdlIHRyYW5zYWN0aW9uIGFuZCBzcGVjaWZpY2FsbHkgdG8gdGhlDQo+ICAgbWVkaWEuDQo+ DQo+IE5FVzoNCj4NCj4gICBBbiBpZGVudGl0eSBhc3NlcnRpb24gYmluZHMgdGhlIHVzZXIncyBp ZGVudGl0eSAoYXMgYXNzZXJ0ZWQgYnkgdGhlDQo+ICAgSWRQKSB0byB0aGUgU0RQIG9mZmVyL2Fu c3dlciBleGNoYW5nZSBhbmQgc3BlY2lmaWNhbGx5IHRvIHRoZQ0KPiAgIG1lZGlhLg0KPg0KPg0K PiAyKSBzLjUuNi40LjENCj4NCj4gT0xEOg0KPg0KPiAgIE9uY2UgYW4gSWRQIGhhcyBnZW5lcmF0 ZWQgYW4gYXNzZXJ0aW9uLCBpdCBpcyBhdHRhY2hlZCB0byB0aGUgU0RQDQo+ICAgbWVzc2FnZS4g IFRoaXMgaXMgZG9uZSBieSBhZGRpbmcgYSBuZXcgaWRlbnRpdHkgYXR0cmlidXRlIHRvIHRoZSBT RFAuDQo+DQo+IE5FVzoNCj4NCj4gICBPbmNlIGFuIElkUCBoYXMgZ2VuZXJhdGVkIGFuIGFzc2Vy dGlvbiwgaXQgaXMgYXR0YWNoZWQgdG8gdGhlIFNEUA0KPiAgIG9mZmVyL2Fuc3dlciBtZXNzYWdl LiAgVGhpcyBpcyBkb25lIGJ5IGFkZGluZyBhIG5ldyBpZGVudGl0eSBhdHRyaWJ1dGUNCj4gICB0 byB0aGUgU0RQLg0KPg0KPiBvciB3ZSBjb3VsZCBnbyBldmVuIGZ1cnRoZXI6DQo+DQo+IE5FVzoN Cj4NCj4gICBPbmNlIGFuIElkUCBoYXMgZ2VuZXJhdGVkIGFuIGFzc2VydGlvbiwgaXQgaXMgYXR0 YWNoZWQgdG8gdGhlIFNEUA0KPiAgIG9mZmVyL2Fuc3dlciBtZXNzYWdlLiAgVGhpcyBpcyBkb25l IGJ5IGFkZGluZyBhIG5ldyBpZGVudGl0eSBhdHRyaWJ1dGUNCj4gICB0byB0aGUgU0RQOyB0aGUg b2ZmZXIgaW5jbHVkZXMgdGhlIGNhbGxlcuKAmXMgYXNzZXJ0aW9uOyB0aGUgYW5zd2VyIGluY2x1 ZGVzDQo+ICAgdGhlIGNhbGxlZeKAmXMgYXNzZXJ0aW9uLg0KDQpXaXRob3V0IGNvbW1lbnRpbmcg b24gdGhlIHNwZWNpZmljcyBhYm92ZSBhdCB0aGlzIHBvaW50LCB0aGUgc3RydWN0dXJlIHdlIG5v cm1hbGx5IHVzZSBpczoNCg0KeC4gIFNEUCBYWFggQXR0cmlidXRlICAgIDwtLS0gVGhpcyBzZWN0 aW9uIGRlZmluZXMgdGhlIGF0dHJpYnV0ZQ0KeS4gIFNEUCBPZmZlci9BbnN3ZXIgUHJvY2VkdXJl cw0KeS4xLiAgR2VuZXJhbA0KeS4yLiAgR2VuZXJhdGluZyB0aGUgSW5pdGlhbCBTRFAgT2ZmZXIN CnkuMy4gIEdlbmVyYXRpbmcgdGhlIEFuc3dlcg0KeS40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9m IHRoZSBTRFAgQW5zd2VyDQp5LjUuICBNb2RpZnlpbmcgdGhlIFNlc3Npb24NCg0KPiBOb3cgYXMg ZmFyIGFzIHdoYXQgbW9yZSBtaWdodCBiZSBzYWlkIHRvIHNjb3BlIHRoZSBhdHRyaWJ1dGUgdG8g V2ViUlRDLCBJ4oCZbSBwcmV0dHkgc3VyZSB0aGF04oCZcyBjb3ZlcmVkIGluIHR3byB3YXlzOg0K Pg0KPiAxKSBJZiBmb2xrcyBhcmUgY29taW5nIGF0IHRoaXMgYXR0cmlidXRlIGZyb20gdGhlIElB TkEgcmVnaXN0cnksIHRoZW4gdGhlIOKAnEFwcHJvcHJpYXRlIFZhbHVlc+KAnSByZWdpc3RyeSBl bnRyeSANCj4gcG9pbnRzIHRvIHM1LjYuNC4yIG9mIHRoaXMgZG9jdW1lbnQgYW5kIHRoYXQgc2Vj dGlvbiBwcmV0dHkgbXVjaCBnZXRzIHlvdSB0byB1c2luZyBJZFAgYXMgZGVzY3JpYmVkIGluIHRo aXMgZHJhZnQuDQo+DQo+IDIpIElmIGZvbGtzIGFyZSBjb21pbmcgYXQgaXQgZnJvbSByZWFkaW5n IHRoZSBkcmFmdC9SRkMsIHRoZW4gd2VsbCBpdOKAmXMgcHJldHR5IGNsZWFyIHRoYXQgdGhpcyBh dHRyaWJ1dGUgaXMgdXNlZCB3aXRoIElkUHMuDQoNClN1cmUsIGFuZCBpdCB3b3VsZCBwcm9iYWJs eSBiZSBlbm91Z2ggdG8gc2F5IHRoYXQgdGhlIGF0dHJpYnV0ZSBpcyBhcHBsaWNhYmxlIHRvIGVu dGl0aWVzIHRoYXQgc3VwcG9ydC91c2UgSWRQcy4gVGhlbiB3ZSBkb24ndCBuZWVkIHRvIHNheSAi V2ViUlRDIiwgYmVjYXVzZSBpdCBpcyBxdWl0ZSB1bmNsZWFyIHdoYXQgdGhhdCByZWFsbHkgbWVh bnMuDQoNCi0tLS0NCg0KPj4+PiBRMjoNCj4+Pj4gLS0tDQo+Pj4+IA0KPj4+PiBBbHNvLCB0aGUg bXV4IGNhdGVnb3J5IGlzIG1pc3NpbmcgDQo+Pj4+IChkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4 LWF0dHJpYnV0ZXMNCj4+Pj4gYWxzbyBjb3ZlcnMgc2Vzc2lvbi1sZXZlbCBhdHRyaWJ1dGVzKS4g SSBhc3N1bWUgaXQgaXMgwrNOT1JNQUzCsi4NCj4+PiANCj4+PiBJIHRoaW5rIHRoaXMgbWFucyBh ZGRpbmc6DQo+Pj4gDQo+Pj4gTXV4IENhdGVnb3J5OiBOT1JNQUwNCj4+PiANCj4+PiB0byB0aGUg SUFOQSByZWdpc3RyYXRpb24/DQo+PiANCj4+IENvcnJlY3QuIEJ1dCwgTk9STUFMIGlzIGp1c3Qg bXkgYXNzdW1wdGlvbiAtICBJIHdhbnQgcGVvcGxlIHRvIGNvbmZpcm0gDQo+PiB3aGV0aGVyIHRo YXQgaXMgY29ycmVjdCA6KQ0KPg0KPiBJIHN1Ym1pdHRlZCBQUiB0byBhZGRyZXNzIHRoaXM6DQo+ IGh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvc2VjdXJpdHktYXJjaC9wdWxsLzY2DQo+DQo+ IEkgaW5jbHVkZWQg4oCcTk9STUFM4oCdLCBidXQgaWYgc29tZWJvZHkgdGhpbmtzIHRoaXMgaXMg d3JvbmcgSSBjYW4gY2hhbmdlIGl0LiANCg0KQXNzdW1pbmcgIk5PUk1BTCIgaXMgY29ycmVjdCwg dGhlIFBSIGxvb2tzIGdvb2QgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQoN Cg0KDQoNCj4+PiBPbiAyMy8wNC8xOCAwMTo0NywgInJ0Y3dlYiBvbiBiZWhhbGYgb2YgTWFydGlu IFRob21zb24iDQo+Pj4gPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+PiB0bHMtaWQgaXMgY29ubmVj dGlvbi1iYXNlZCAoaS5lLiwgaXQgYXBwbGllcyB0byBhIHNpbmdsZSBidW5kbGUpLCANCj4+Pj4g d2hlcmVhcyBpZGVudGl0eSBpcyBzZXNzaW9uLWJhc2VkLiAgVGhhdCB3YXMgbXkgaW5pdGlhbCB0 aG91Z2h0LCANCj4+Pj4gYnV0IHRoZW4gd2UgaGF2ZSB0byBkZWFsIHdpdGggdGhlIDE6TiBwcm9i bGVtIHRoZXJlLiAgVGhlIHNpbXBsZXN0IA0KPj4+PiBhcHByb2FjaCBtaWdodCBiZSB0byBtb3Zl IGE9aWRlbnRpdHkgdG8gdGhlIGJ1bmRsZSwgYnV0IHRoYXQgbGVhZHMgDQo+Pj4+IHRvIHNvbWUg aW50ZXJlc3RpbmcgZG93bnN0cmVhbSBlZmZlY3RzLiAgWW91IHByb2JhYmx5IHdhbnQgdG8gYXZv aWQgDQo+Pj4+IGhhdmluZyBtdWx0aXBsZSBpZGVudGl0aWVzIGluIHRoZSBzYW1lIFJUQ1BlZXJD b25uZWN0aW9uLCBmb3IgDQo+Pj4+IGluc3RhbmNlLg0KPj4+PiANCj4+Pj4gT24gU2F0LCBBcHIg MjEsIDIwMTggYXQgMTE6MTAgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4gd3JvdGU6 DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gT24gVGh1LCBBcHIgMTIsIDIwMTggYXQgNjo0NSBBTSwg U2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBUaGUg V0dMQyBmb3IgdGhpcyBkb2N1bWVudCBoYXMgZW5kZWQuICBJIHRoaW5rIGl0IHdhcyByZWFsbHkg Z29vZCANCj4+Pj4+PiB0aGF0IEANCj4+Pj4+PiBJRVRGMTAxIHRoZSBJZFAgaGFja2F0aG9uIGhh cHBlbmVkIGJlY2F1c2UgaXQgbG9va2VkIGxpa2UgdGhleSANCj4+Pj4+PiBtaWdodCBoYXZlIHVu Y292ZXJlZCBzb21ldGhpbmcgdG8gYmUgY2hhbmdlZCBpbiBvdXIgZG9jdW1lbnQgYW5kIA0KPj4+ Pj4+IHBvc3NpYmx5IGluIHRoZSB3ZWJydGMtcGMgZHJhZnQ7IHNlZSB0aGUgWzBdIHRocmVhZC4g IEFzIHRoZSANCj4+Pj4+PiBTaGVwaGVyZCB0cnlpbmcgdG8gZHJpdmUgdGhpcyB0byBjbG9zdXJl LCB3ZSBuZWVkIHRvIHdlIG5lZWQgdG8gDQo+Pj4+Pj4gZGVjaWRlIHdoYXQgY2hhbmdlcyBtaWdo dCBiZSBtYWRlIGluIA0KPj4+Pj4+IGRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2guICBJ biB0aGF0IHRocmVhZCwgSSBzYXcgdHdvIA0KPj4+Pj4+IHRoaW5ncyB0aGF0IHdlIG1pZ2h0IGNo YW5nZSAoYm90aCBmcm9tIG10KToNCj4+Pj4+PiANCj4+Pj4+PiAwKSBNb3JlIHRleHQgdG8gYWRk cmVzcyBhIGxpbmthYmlsaXR5IGNvbmNlcm46DQo+Pj4+Pj4gDQo+Pj4+Pj4gQXMgYSBwcmFjdGlj YWwgbWF0dGVyLCBpZiB0aGUgYnJvd3NlciB3ZXJlIHRvIHVzZSB0aGUgc2FtZSANCj4+Pj4+PiBj ZXJ0aWZpY2F0ZSBmb3IgbXVsdGlwbGUgb3JpZ2lucywgdGhlbiBpdCB3b3VsZCBjcmVhdGUgYSBt YXNzaXZlIA0KPj4+Pj4+IHByaXZhY3kgcHJvYmxlbSB0aGF0IGVuYWJsZXMgbGlua2FiaWxpdHkg KGFrYSB1c2VyIHRyYWNraW5nKS4gIEkgDQo+Pj4+Pj4gY291bGRuJ3QgZmluZCB0aGF0IHdyaXR0 ZW4gZG93biwgYnV0IEkgdGhvdWdodCBpdCB3YXMuICBJZiBpdCANCj4+Pj4+PiBpc24ndCB3cml0 dGVuIGRvd24sIHRoZW4gd2Ugc2hvdWxkIGNvcnJlY3QgdGhhdC4NCj4+Pj4+IA0KPj4+Pj4gDQo+ Pj4+PiBJc24ndCB0aGlzIHRoZSByZWxldmFudCB0ZXh0Og0KPj4+Pj4gIg0KPj4+Pj4gDQo+Pj4+ PiAgQVBJIFJlcXVpcmVtZW50OiAgVW5sZXNzIHRoZSB1c2VyIHNwZWNpZmljYWxseSBjb25maWd1 cmVzIGFuIA0KPj4+Pj4gZXh0ZXJuYWwNCj4+Pj4+ICAgICBrZXkgcGFpciwgZGlmZmVyZW50IGtl eSBwYWlycyBNVVNUIGJlIHVzZWQgZm9yIGVhY2ggb3JpZ2luLg0KPj4+Pj4gKFRoaXMNCj4+Pj4+ ICAgICBhdm9pZHMgY3JlYXRpbmcgYSBzdXBlci1jb29raWUuKQ0KPj4+Pj4gDQo+Pj4+PiAiDQo+ Pj4+PiANCj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IEkgYWN0dWFsbHkgdGhpbmsgdGhpcyBpcyBi YXNpY2FsbHkgY292ZXJlZCBoZXJlOg0KPj4+Pj4+IA0KPj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS0xMCNzZWN0aW9uLTQuNC4NCj4+ Pj4+PiAxDQo+Pj4+Pj4gQnV0IHdhbnQgdG8gbWFrZSBzdXJlIG90aGVycyBhZ3JlZToNCj4+Pj4+ PiANCj4+Pj4+PiAxKSBUd2VhayBwcm90b2NvbCB0byBpbmNsdWRlIGFuIGlkZW50aWZpZXIgdG8g cHJldmVudCByZXVzZSBvZiANCj4+Pj4+PiBhc3NlcnRpb24gb24gZXZlcnkgUlRDUGVlckNvbm5l Y3Rpb246DQo+Pj4+Pj4gDQo+Pj4+Pj4gTW9yZSBjb21wbGV4IHNpdGVzIGZyZXF1ZW50bHkgZ2Vu ZXJhdGUgbXVsdGlwbGUgUlRDUGVlckNvbm5lY3Rpb24gDQo+Pj4+Pj4gaW5zdGFuY2VzIGZvciB0 aGVpciBjb21tdW5pY2F0aW9ucywgZXNwZWNpYWxseSBmb3IgZ3JvdXAgDQo+Pj4+Pj4gY29udmVy c2F0aW9ucy4gIElmIHRoZSBicm93c2VyIHJlcXVlc3RzIGFuIGFzc2VydGlvbiBvbmNlIGFuZCAN Cj4+Pj4+PiB0aGV5IHVzZSB0aGF0IHZhbHVlIGZvciBldmVyeSBSVENQZWVyQ29ubmVjdGlvbiwg dGhlbiB0aGF0J3MgT0suICANCj4+Pj4+PiBGcm9tIG15IHBlcnNwZWN0aXZlLCBJIHdvdWxkIGJl IGhhcHB5IG1vZGlmeWluZyB0aGUgcHJvdG9jb2wgdG8gDQo+Pj4+Pj4gaW5jbHVkZSBhbiBpZGVu dGlmaWVyIGFuZCBwcmV2ZW50IHRoYXQ7IGZvciB0aGlzIHRoZSBJZFAgY2FuIHVzZSANCj4+Pj4+ PiBjYWNoaW5nIG9yIGl0cyBsb2NhbCBzdG9yYWdlLg0KPj4+Pj4+IA0KPj4+Pj4+IFNvLCB3aGF0 IHdvdWxkIHRoYXQgbG9vayBsaWtlPw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFdvdWxkbid0IGl0 IGJlIHN1ZmZpY2llbnQgdG8gaW5jbHVkZSB0aGUgdGxzLWlkIGluIHRoZSBpZGVudGl0eSANCj4+ Pj4+IGJpbmRpbmc/DQo+Pj4+PiANCj4+Pj4+IC1Fa3INCj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ IA0KPj4+Pj4+IA0KPj4+Pj4+IERpZCBJIG1pc3MgYW55dGhpbmcgZWxzZSB0aGF0IG5lZWRzIHRv IGJlIGFkZHJlc3NlZD8NCj4+Pj4+PiANCj4+Pj4+PiBzcHQNCj4+Pj4+PiANCj4+Pj4+PiBbMF0N Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBodHRwczovL21haWxhcmNoaXZlLmlldGYuLm9yZy9h cmNoL21zZy9ydGN3ZWIvMnIydTIwVVFJS3dOZVkxUHNZRg0KPj4+Pj4+IHJEdzdqDQo+Pj4+Pj4g WEUNCj4+Pj4+PiB3DQo+Pj4+Pj4gDQo+Pj4+Pj4+IE9uIE1hciAxMiwgMjAxOCwgYXQgMTk6MDgs IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4gd3JvdGU6DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBB bGwsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGlzIGlzIHRoZSBXR0xDIGZvciB0aGUgwrNXZWJSVEMg U2VjdXJpdHkgQXJjaGl0ZWN0dXJlwrIgZHJhZnQNCj4+Pj4+PiBhdmFpbGFibGUNCj4+Pj4+Pj4g QCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1 cml0eS8uDQo+Pj4+Pj4gUGxlYXNlDQo+Pj4+Pj4+IHJldmlldyB0aGUgZHJhZnQgYW5kIHNlbmQg eW91ciBjb21tZW50cyB0byB0aGlzIGxpc3QgYnkgMjM1OVVUQyANCj4+Pj4+Pj4gb24NCj4+Pj4+ PiBBcHJpbA0KPj4+Pj4+PiA2dGgsIDIwMTguDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBOb3RlIHRoZSBn aCByZXBvIGlzIGhlcmU6DQo+Pj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvc2Vj dXJpdHktYXJjaA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBDL1QvUw0KPj4+ Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHJ0Y3dlYkBpZXRmLm9yZw0K Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+Pj4+ PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+Pj4gcnRjd2Vi QGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYg0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+Pj4+IHJ0Y3dlYkBp ZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dl Yg0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gcnRjd2ViIG1haWxpbmcgbGlzdA0KPj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+PiANCj4gDQoNCg== From nobody Fri May 11 03:20: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 24C3B12D947 for ; Fri, 11 May 2018 03:20:08 -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 OHWDFqMTE5Yy for ; Fri, 11 May 2018 03:20:06 -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 961A0127078 for ; Fri, 11 May 2018 03:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526034004; 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=sx0/abuUqODLjd7k4RV81s2Y3prl0XosyRyUDMslEiI=; b=YfbZjqRKwlJBfmhrzsJYmVN6kaDfOUjQC/oRUQ1pRUCzAIGjzjb6tikxpVndFTvE dBsydgvTBtfeyH5j7aglLXEspZicYhr4v/qjUMWhJlxF5DdpnD8pTsUkDyCdEPUe sm7pXwy6qxH7+L+2hMONqFWvRkQnGtSBn1PDkJ1sihI=; X-AuditID: c1b4fb2d-a6b079c00000050d-32-5af56e549aed Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1A.82.01293.45E65FA5; Fri, 11 May 2018 12:20:04 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.34]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Fri, 11 May 2018 12:20:03 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute Thread-Index: AQHT6RGfenU2OZxm10q2tYkeSmM/qA== Date: Fri, 11 May 2018 10:20:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [131.160.50.130] Content-Type: multipart/alternative; boundary="_000_D71B49BA2F885christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7tG5I3tcog3v3ZCzW/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoyPc5kKPitX7DvzmrGB8btsFyMnh4SAicSkx8fYuxi5OIQE jjBK3F98lwnCWcwoMWfKR7YuRg4ONgELie5/2iANIgLqEpcfXmAHsYUFfCUmdi9ngYiHSKz5 /ZYdwtaTuNPylQmklUVAVWLNZx+QMK+AtcSB7XPYQGxGATGJ76fWMIHYzALiEreezGeCuEdA Ysme88wQtqjEy8f/WEFsUaCRG07cZgcZKSGgJHF7gxNEa4LEoxnP2CHGC0qcnPmEZQKj0Cwk U2chKZuFpAwibiDx/tx8ZghbW2LZwtdQtr7Exi9nGSFsa4lpl1+gqFnAyLGKUbQ4tbg4N93I WC+1KDO5uDg/Ty8vtWQTIzBODm75rbuDcfVrx0OMAhyMSjy8N/2+RgmxJpYVV+YeYpTgYFYS 4d234kuUEG9KYmVValF+fFFpTmrxIUZpDhYlcV69VXuihATSE0tSs1NTC1KLYLJMHJxSDYw6 zCIVJwu36h+vSOD/pqgepVt7mj9OmM9d7q7l4eUnfDKTV6w5mO+5h9+u7jpjYuZvjTirayYv /r2/xivT2usY2qz3c+7kn98FEpy/hVQ9jGMpe+DjsEf/5W5vGwHxL9ph0y8KOjVviz2T8rm0 7J2Ag8eto7vTPj2/ZM/+o0TGvmlGHUuurxJLcUaioRZzUXEiANIKujSPAgAA Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute 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: Fri, 11 May 2018 10:20:08 -0000 --_000_D71B49BA2F885christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A few questions/comments on the SDP identity attribute. Q1: ---- The draft says that, at minimum, the fingerprint needs to be bound to the i= dentity. Does this mean that, in order to include an SDP identity attribute in an of= fer/answer, the offer/answer MUST also contain at least one SDP fingerprint= attribute? Based on the text about generating the identity it seems like t= hat, but it is not very clear in the SDP procedures. Q2: ---- Section 5.6.4.1 says: "The "a=3Didentity" attribute MUST include all fingerprint values that are included in "a=3Dfingerprint" lines." First, related to the generation of the assertion value, it is unclear how = this is implemented. For example, is there a separate JSON object (section = 5.6.4) provided to the IdP for each fingerprint? The text talks about =93si= ngle=94 fingerprint in the object. Or, are all fingerprints included in the= same JSON object? Second, it is unclear what =93attribute MUST include all fingerprint values= =94 means. I assume that the attribute will only include a single attribute= assertion value, but that the value will be generated by the IdP based on = all fingerprint values? Q3: ---- In the example in Section 5.6.4.1 the SDP fingerprint attribute is included= as a session-level attribute. However, it is a media-level attribute. AFAI= R, media-level attributes cannot be included as session-level attributes. Regards, Christer --_000_D71B49BA2F885christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

A few questions/comments on the SDP identity attribute.

Q1:
----

The draft says that, at minimum, the fingerprint needs to be bound to = the identity.

Does this mean that, in order to include an SDP identity attribute in = an offer/answer, the offer/answer MUST also contain at least one SDP finger= print attribute? Based on the text about generating the identity it seems l= ike that, but it is not very clear in the SDP procedures.


Q2:
----

Section 5.6.4.1 says:
   "The "a=3Didentity&qu=
ot; attribute MUST include all
   fingerprint values that are included in "a=3Dfingerprint" line=
s."

First, related to the generation of the assertion value, it is unclear= how this is implemented. For example, is there a separate JSON object (sec= tion 5.6.4) provided to the IdP for each fingerprint? The text talks about = =93single=94 fingerprint in the object. Or, are all fingerprints included in the same JSON object?

Second, it is unclear what =93attribute MUST include all fingerprint v= alues=94 means. I assume that the attribute will only include a single attr= ibute assertion value, but that the value will be generated by the IdP base= d on all fingerprint values?


Q3: 
----

In the example in Section 5.6.4.1 the SDP fingerprint attribute is inc= luded as a session-level attribute. However, it is a media-level attribute.= AFAIR, media-level attributes cannot be included as session-level attribut= es.


Regards,

Christer


=
--_000_D71B49BA2F885christerholmbergericssoncom_-- From nobody Fri May 11 10:08: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 8E534127775 for ; Fri, 11 May 2018 10:08:18 -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 uY1Nt8KdQt4L for ; Fri, 11 May 2018 10:08:16 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 75005124319 for ; Fri, 11 May 2018 10:08:16 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id c9-v6so7772789iob.12 for ; Fri, 11 May 2018 10:08:16 -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=OJpxWvSJPeRTqUnFPmoL56krS2S+R1SkJb/hVPICKLM=; b=Uf2vdGQNhPKf/E8dhFsv4h1s5JADy6EObzUBTROvwgUSTk0HWxpvZZ8bE5Or52P/LP Mz2xbEATzHu28erqzEyWKpCX4kb6UBkrCG7Jmdg7E2kMb3NF3nXHjfSN7f/LqS0Ba8TY udFbVwYEsgpx4alHdEVzjIQ6mHQwYUyOGqrhOCD1QD3h2MDLIaYBKTm5OKNhq+epBLXC T0wVTR/QJE+AMcj32fJFsjtQvW56/d4VsWmf68i+GCsIoFj5pTpNyLmDhpPUTaBHc+XS 2gbsKC3MD3nsiEEis4kid36+LBCj4Es4364oXlu33Z9F+R7wfGyuAh94jzI6w2q8DqJW P1jQ== 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=OJpxWvSJPeRTqUnFPmoL56krS2S+R1SkJb/hVPICKLM=; b=GKlBFWCSJPiFfbnBfWSibHQLjdTsMo63JhhVskw7Et00zl3VBFrUCEAik/HCtOfUSu ioNeHU+fqjjW1SEawV5ZXDvewSwXv74wa34HAqn+VH/NOKkjeFo1idX9Eg72A57xn2WQ oCOIaV6BNKn42KGhoRpnkXwgULZta9jztwid2yUU5gWaRH01u/UhOKKDdGtOAZbbdg44 tDVFGP5Yaj3hnbw52SxF6zhPfAjly8EKWb+9BgKcxOpYiOXeDQmplUDWwx3YmRQjLFLe uzzZXs40XqUsEcfxeUa1NRI+6mj7PuwWQ6SaeEPx16W0GgO3j3dOSm0TQAODUvv72yPL VwUg== X-Gm-Message-State: ALKqPweqez3BtZTtmgda/paDkYKMjSNrrcTCogXOSBETdtFbqDTsmfNp aJCvxfcxG6+/JqnmriX648i4K7N2l66aXaQs+pNu8d5O3pI= X-Google-Smtp-Source: AB8JxZoe93L3Pnbdfegx8UcOy2APhgCJTkGSxjx8P6dZVkWamM6Q5mSCMbeDxjrr8xJ3c+OuXaolYPzf+voM0tTsyQw= X-Received: by 2002:a6b:8e8b:: with SMTP id q133-v6mr6681787iod.262.1526058495245; Fri, 11 May 2018 10:08:15 -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> In-Reply-To: <574256E1-7AF4-4E25-9462-04B4B599C801@mozilla.com> From: Justin Uberti Date: Fri, 11 May 2018 10:08:03 -0700 Message-ID: To: Nils Ohlmeier Cc: Sean Turner , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000084985d056bf12ec1" 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: Fri, 11 May 2018 17:08:18 -0000 --00000000000084985d056bf12ec1 Content-Type: text/plain; charset="UTF-8" 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? On Fri, May 4, 2018 at 9:50 AM Nils Ohlmeier wrote: > Created https://github.com/juberti/draughts/pull/101 > > Nils > > On May 4, 2018, at 08:26, Sean Turner wrote: > > Repo is here :) > > https://github.com/juberti/draughts > > spt > > On May 1, 2018, at 17:33, Justin Uberti 40google.com@dmarc.ietf.org> wrote: > > Do you want to take a shot at the text? (either in email or as a PR) > > On Mon, Apr 30, 2018 at 3:21 PM Nils Ohlmeier > wrote: > > On Apr 30, 2018, at 15:03, Justin Uberti wrote: > > Any TURN server provided by the browser is in effect a proxy, and forcing > use of said proxy can be done either through firewall config or explicit > selection of Mode 4. (IOW, no new mode is needed.) > > > I do agree that these two configurations result in a similar behavior. > But I doubt that these use the same code path in implementations. > And (thus) I doubt readers of the draft/RFC will automatically come to the > same conclusion. > > It think it might be helpful to add another sentence explaining this > scenario. > > The document originally pointed at RETURN as an example of how such TURN > proxying could work, but was removed in order to avoid a dependency. > > > Fair enough. > > Nils > > On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings wrote: > > > On Apr 17, 2018, at 3:15 AM, Justin Uberti 40google.com@dmarc.ietf.org> wrote: > > IMO "trusting the TURN relay but not the application" is not a significant > enough benefit to merit adding specific functionality for. > > > In the case were the TURN server is provided by the JS, I agree. But in > the case where the configuration of the browser provided the TURN server, > then I think it is as trusted as say a VPN server. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > --00000000000084985d056bf12ec1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the PR. I spent some time thinking about this a= nd ultimately concluded that more significant changes to the document will = be necessary if it is to prescribe how a browser-provided TURN server shoul= d be handled, essentially incorporating much of the guidance from=C2=A0https://too= ls.ietf.org/html/draft-ietf-rtcweb-return-02

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

As= such, I see 3 paths forward here:
a) Leave the document as-is. W= hile leaving some ambiguity on this topic, the eventual (hopefully) publica= tion 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?

On Fr= i, May 4, 2018 at 9:50 AM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
Created=C2=A0https://github.com/juberti/draughts/pull/101

<= /div>
=C2=A0 Nils

On May 4, = 2018, at 08:26, Sean Turner <sean@sn3rd.com> wrote:

Repo is here :)

https://github.com/ju= berti/draughts

spt

On May 1, 20= 18, at 17:33, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:<= br>
Do you want to take a shot at the text? (either in email or as a PR)=

On Mon, Apr 30, 2018 at 3:21 PM Nils Ohlmeier <nohlmeier@mozilla.com> wro= te:

On Apr 30, 2018, at 15:03, Justin Uber= ti <juberti@goog= le.com> wrote:

Any TURN server provided by the browser is in = effect a proxy, and forcing use of said proxy can be done either through fi= rewall config or explicit selection of Mode 4. (IOW, no new mode is needed.= )

I do agree that these two configurations result in a = similar behavior.
But I doubt that these use the same code path in imple= mentations.
And (thus) I doubt readers of the draft/RFC will automatical= ly come to the same conclusion.

It think it might be helpful to add = another sentence explaining this scenario.

The document originally pointed at RETURN as an example of how such TURN p= roxying could work, but was removed in order to avoid a dependency.

Fair enough.

=C2=A0Nils

On Fri, Apr 27, 2018 at 11:22 AM Cullen Jennings <fluffy@iii.ca> wrote:


On Apr 17, 2018, at 3:15 AM, Justin Uberti <juber= ti=3D40goo= gle.com@dmarc.ietf.org> wrote:

IMO "trusting the TURN re= lay but not the application" is not a significant enough benefit to me= rit adding specific functionality for.


In the case = were the TURN server is provided by the JS, I agree. But in the case where = the configuration of the browser provided the TURN server, then I think it = is as trusted as say a VPN server.



___________= ____________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www= .ietf.org/mailman/listinfo/rtcweb


--00000000000084985d056bf12ec1-- From nobody Mon May 14 06:20: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 1F75212E043 for ; Mon, 14 May 2018 06:20:52 -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 kk4z9ltP5W3G for ; Mon, 14 May 2018 06:20:50 -0700 (PDT) Received: from smtp65.ord1d.emailsrvr.com (smtp65.ord1d.emailsrvr.com [184.106.54.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 6881B124D6C for ; Mon, 14 May 2018 06:20:50 -0700 (PDT) Received: from smtp1.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id B1F0240086; Mon, 14 May 2018 09:20:49 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5775E40078; Mon, 14 May 2018 09:20:49 -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); Mon, 14 May 2018 09:20:49 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_EA91D61B-245E-4E4A-AFFD-EAD6118739E1" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Mon, 14 May 2018 07:20:48 -0600 Cc: Nils Ohlmeier , RTCWeb IETF Message-Id: <6DF5B202-803F-452B-B17E-5346F4C6FB4B@iii.ca> 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> To: Justin Uberti 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, 14 May 2018 13:20:52 -0000 --Apple-Mail=_EA91D61B-245E-4E4A-AFFD-EAD6118739E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 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? 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 --Apple-Mail=_EA91D61B-245E-4E4A-AFFD-EAD6118739E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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. 


= --Apple-Mail=_EA91D61B-245E-4E4A-AFFD-EAD6118739E1-- From nobody Thu May 17 10:50: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 9F1F812EB6A for ; Thu, 17 May 2018 10:50:09 -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 XEuBTR0YiKnM for ; Thu, 17 May 2018 10:50:06 -0700 (PDT) Received: from smtp65.ord1d.emailsrvr.com (smtp65.ord1d.emailsrvr.com [184.106.54.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 BDBCC12EB69 for ; Thu, 17 May 2018 10:50:06 -0700 (PDT) Received: from smtp1.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id D1C5F404E6; Thu, 17 May 2018 13:50:05 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7962D405C9; Thu, 17 May 2018 13:50:05 -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, 17 May 2018 13:50:05 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A0C42B86-258C-402A-A326-8D79C44C7EC0" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: Date: Thu, 17 May 2018 11:50:04 -0600 Cc: RTCWeb IETF Message-Id: References: To: Christer Holmberg X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute 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: Thu, 17 May 2018 17:50:10 -0000 --Apple-Mail=_A0C42B86-258C-402A-A326-8D79C44C7EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 11, 2018, at 4:20 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > A few questions/comments on the SDP identity attribute. >=20 > Q1: > ---- >=20 > The draft says that, at minimum, the fingerprint needs to be bound to = the identity. >=20 > Does this mean that, in order to include an SDP identity attribute in = an offer/answer, the offer/answer MUST also contain at least one SDP = fingerprint attribute? Based on the text about generating the identity = it seems like that, but it is not very clear in the SDP procedures. >=20 >=20 JSEP requires DTLS/SRTP which requires adding the fingerprint so I think = this is already required. Also JSEP points out lack of fingerprint will = cause negotiation failure.=20 > Q2: > ---- >=20 > Section 5.6.4.1 says: > "The "a=3Didentity" attribute MUST include all > fingerprint values that are included in "a=3Dfingerprint" lines." >=20 > First, related to the generation of the assertion value, it is unclear = how this is implemented. For example, is there a separate JSON object = (section 5.6.4) provided to the IdP for each fingerprint? The text talks = about =E2=80=9Csingle=E2=80=9D fingerprint in the object. Or, are all = fingerprints included in the same JSON object? Yah, I think it would get a Identity token for each fingerprint via a = Generate Assertion for each fingerprint. But I think that is largely = WebRTC issue.=20 >=20 > Second, it is unclear what =E2=80=9Cattribute MUST include all = fingerprint values=E2=80=9D means. I assume that the attribute will only = include a single attribute assertion value, but that the value will be = generated by the IdP based on all fingerprint values? So if there were multiple fingerprint, the SDP would have multiple = Identity lines. =20 >=20 >=20 > Q3:=20 > ---- >=20 > In the example in Section 5.6.4.1 the SDP fingerprint attribute is = included as a session-level attribute. However, it is a media-level = attribute. AFAIR, media-level attributes cannot be included as = session-level attributes. >=20 I think fingerprint is valid as both session-level or media-level so I = suspect this is fine. JSEP also says that if the certs are the same, = then it can be session level but if different then must be media level. = So I think this is covered in JSEP.=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_A0C42B86-258C-402A-A326-8D79C44C7EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 11, 2018, at 4:20 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

A few questions/comments on the SDP identity = attribute.

Q1:
----

The draft says that, at minimum, the fingerprint needs = to be bound to the identity.

Does this mean that, in order to include an SDP identity = attribute in an offer/answer, the offer/answer MUST also contain at = least one SDP fingerprint attribute? Based on the text about generating = the identity it seems like that, but it is not very clear in the SDP procedures.



JSEP requires DTLS/SRTP which requires adding the = fingerprint so I think this is already required. Also JSEP points out = lack of fingerprint will cause negotiation failure. 


Q2:
----

Section 5.6.4.1 says:
   "The =
"a=3Didentity" attribute MUST include all
   fingerprint values that are included in "a=3Dfingerprint" =
lines."

First, related to the generation of the assertion value, = it is unclear how this is implemented. For example, is there a separate = JSON object (section 5.6.4) provided to the IdP for each fingerprint? = The text talks about =E2=80=9Csingle=E2=80=9D fingerprint in the object. Or, are all fingerprints included in the same JSON = object?

Yah, I = think it would get a Identity token for each fingerprint via a Generate = Assertion for each fingerprint. But I think that is largely WebRTC = issue. 


Second, it is unclear what =E2=80=9Cattribute MUST = include all fingerprint values=E2=80=9D means. I assume that the = attribute will only include a single attribute assertion value, but that = the value will be generated by the IdP based on all fingerprint = values?

So if = there were multiple fingerprint, the SDP would have multiple Identity = lines.
 


Q3: 
----

In the example in Section 5.6.4.1 the SDP fingerprint = attribute is included as a session-level attribute. However, it is a = media-level attribute. AFAIR, media-level attributes cannot be included = as session-level attributes.


I = think fingerprint is valid as both session-level or media-level so I = suspect this is fine. JSEP also says that if the certs are the same, = then it can be session level but if different then must be media level. = So I think this is covered in JSEP. 



Regards,

Christer


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

= --Apple-Mail=_A0C42B86-258C-402A-A326-8D79C44C7EC0-- From nobody Thu May 17 11:05: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 706EC12D941 for ; Thu, 17 May 2018 11:04:58 -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 52CO4McFOBdj for ; Thu, 17 May 2018 11:04:56 -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 B5712126CD8 for ; Thu, 17 May 2018 11:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526580293; 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=/d2ho8QffhVWBIPvMoY6Ehjeac9DonnggCVcJEby3Sc=; b=d/pOEk1V+RdO+wVK5RlmhYTMG8YKP4XMdmKzg5Db+7QYKh6/QHpOE9mxjdrMTpQi ccXmm6FRFTLPv+zFSOYoKzLrnti5mShj/EZCR4o6sl2M0lY+ujn5q2aXxNGN4yvX sn+tHcqYM6mcDPC3u8D3Dr3KWpSvrDWr1I93OsK8MZ0=; X-AuditID: c1b4fb25-f8bff700000079fb-f3-5afdc4451fa3 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.49.31227.544CDFA5; Thu, 17 May 2018 20:04:53 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0382.000; Thu, 17 May 2018 20:03:45 +0200 From: Christer Holmberg To: Cullen Jennings CC: RTCWeb IETF Thread-Topic: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute Thread-Index: AQHT6RGfenU2OZxm10q2tYkeSmM/qKQ0G04AgAAiMMA= Date: Thu, 17 May 2018 18:03:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72EEFB16ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7rq7rkb9RBtPWyFh8WP+D0WLtv3Z2 ByaPJUt+MnlcPv+RMYApissmJTUnsyy1SN8ugStj1YRT7AXLFjJWPJt+l62BsWEuYxcjJ4eE gIlE/7VnrF2MXBxCAkcYJba+ucwM4SxmlNizcjuQw8HBJmAh0f1PG6RBREBZ4tyOu8wgNrOA osSX5fPZQGxhgRiJxbuXMkPUxErc378NyraS+DT3AhvIGBYBVYl1z0xBwrwCvhIdE/rASoQE siVO9cwGszmByp/sfg82klFATOL7qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4//sULYShIn uzezQNTnS+x9N5UJYpegxMmZT1gmMIrMQjJqFpKyWUjKZgFdyiygKbF+l/4sqCendD9kh7A1 JFrnzGVHFl/AyL6KUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCuDm75rbqD8fIbx0OMAhyM Sjy8wvv+RgmxJpYVV+YeYpTgYFYS4fWrBArxpiRWVqUW5ccXleakFh9ilOZgURLnfWi+OUpI ID2xJDU7NbUgtQgmy8TBKdXAqF79S1ln1cl/Qi635k/4nFPqsM93gqPBFpbSpAtz/A6ebg2b zVGWbL7RedFrB1utoz2pb55uKS05lp3tNnfm37pfV8pVX54+EvjSQmSL67eAxbfOizFwm1ed DtW6tPlJ+I5l+f5rp31ov/f5a2zXgUBBxfiwG+Gh05dNks+w9ZKpj16ZtEVVRImlOCPRUIu5 qDgRAK6z0cmnAgAA Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute 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: Thu, 17 May 2018 18:04:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72EEFB16ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KQSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRzIG9uIHRoZSBTRFAgaWRlbnRpdHkgYXR0 cmlidXRlLg0KDQpRMToNCi0tLS0NCg0KVGhlIGRyYWZ0IHNheXMgdGhhdCwgYXQgbWluaW11bSwg dGhlIGZpbmdlcnByaW50IG5lZWRzIHRvIGJlIGJvdW5kIHRvIHRoZSBpZGVudGl0eS4NCg0KRG9l cyB0aGlzIG1lYW4gdGhhdCwgaW4gb3JkZXIgdG8gaW5jbHVkZSBhbiBTRFAgaWRlbnRpdHkgYXR0 cmlidXRlIGluIGFuIG9mZmVyL2Fuc3dlciwgdGhlIG9mZmVyL2Fuc3dlciBNVVNUIGFsc28gY29u dGFpbiBhdCBsZWFzdCBvbmUgU0RQIGZpbmdlcnByaW50IGF0dHJpYnV0ZT8gQmFzZWQgb24gdGhl IHRleHQgYWJvdXQgZ2VuZXJhdGluZyB0aGUgaWRlbnRpdHkgaXQgc2VlbXMgbGlrZSB0aGF0LCBi dXQgaXQgaXMgbm90IHZlcnkgY2xlYXIgaW4gdGhlIFNEUCBwcm9jZWR1cmVzLg0KDQoNCkpTRVAg cmVxdWlyZXMgRFRMUy9TUlRQIHdoaWNoIHJlcXVpcmVzIGFkZGluZyB0aGUgZmluZ2VycHJpbnQg c28gSSB0aGluayB0aGlzIGlzIGFscmVhZHkgcmVxdWlyZWQuIEFsc28gSlNFUCBwb2ludHMgb3V0 IGxhY2sgb2YgZmluZ2VycHJpbnQgd2lsbCBjYXVzZSBuZWdvdGlhdGlvbiBmYWlsdXJlLg0KDQpU aGlzIGlzIG5vdCBhYm91dCBKU0VQLCBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhlIFNEUCBpZGVu dGl0eSBhdHRyaWJ1dGUuIEFzIHRoaXMgYXR0cmlidXRlIGNhbiAoSSBhc3N1bWUpIGJlIHVzZWQg b24gdGhlIHdpcmUsIGl0IG5lZWRzIHRvIGRlZmluZWQgYXMgc3VjaC4NCg0KVGhlIFVTQUdFIG9m IHRoZSBhdHRyaWJ1dGUgY2FuIHRoZW4gYmUgc2NvcGVkIHRvIFdlYlJUQywgSlNFUCwgb3Igd2hh dGV2ZXIuDQoNCg0KUTI6DQotLS0tDQoNClNlY3Rpb24gNS42LjQuMSBzYXlzOg0KDQogICAiVGhl ICJhPWlkZW50aXR5IiBhdHRyaWJ1dGUgTVVTVCBpbmNsdWRlIGFsbA0KDQogICBmaW5nZXJwcmlu dCB2YWx1ZXMgdGhhdCBhcmUgaW5jbHVkZWQgaW4gImE9ZmluZ2VycHJpbnQiIGxpbmVzLiINCg0K Rmlyc3QsIHJlbGF0ZWQgdG8gdGhlIGdlbmVyYXRpb24gb2YgdGhlIGFzc2VydGlvbiB2YWx1ZSwg aXQgaXMgdW5jbGVhciBob3cgdGhpcyBpcyBpbXBsZW1lbnRlZC4gRm9yIGV4YW1wbGUsIGlzIHRo ZXJlIGEgc2VwYXJhdGUgSlNPTiBvYmplY3QgKHNlY3Rpb24gNS42LjQpIHByb3ZpZGVkIHRvIHRo ZSBJZFAgZm9yIGVhY2ggZmluZ2VycHJpbnQ/IFRoZSB0ZXh0IHRhbGtzIGFib3V0IOKAnHNpbmds ZeKAnSBmaW5nZXJwcmludCBpbiB0aGUgb2JqZWN0LiBPciwgYXJlIGFsbCBmaW5nZXJwcmludHMg aW5jbHVkZWQgaW4gdGhlIHNhbWUgSlNPTiBvYmplY3Q/DQoNCllhaCwgSSB0aGluayBpdCB3b3Vs ZCBnZXQgYSBJZGVudGl0eSB0b2tlbiBmb3IgZWFjaCBmaW5nZXJwcmludCB2aWEgYSBHZW5lcmF0 ZSBBc3NlcnRpb24gZm9yIGVhY2ggZmluZ2VycHJpbnQuIEJ1dCBJIHRoaW5rIHRoYXQgaXMgbGFy Z2VseSBXZWJSVEMgaXNzdWUuDQoNCldoaWxlIGl0IG1heSBiZSBhbiBXZWJSVEMgaXNzdWUgaG93 IHRvIHVzZSBtdWx0aXBsZSBmaW5nZXJwcmludHMgaW4gZ2VuZXJhbCwgaXQgaXMgYW4gU0RQIGlz c3VlIGhvdyB0byBlbmNvZGUgdGhlIGF0dHJpYnV0ZS4NCg0KDQpTZWNvbmQsIGl0IGlzIHVuY2xl YXIgd2hhdCDigJxhdHRyaWJ1dGUgTVVTVCBpbmNsdWRlIGFsbCBmaW5nZXJwcmludCB2YWx1ZXPi gJ0gbWVhbnMuIEkgYXNzdW1lIHRoYXQgdGhlIGF0dHJpYnV0ZSB3aWxsIG9ubHkgaW5jbHVkZSBh IHNpbmdsZSBhdHRyaWJ1dGUgYXNzZXJ0aW9uIHZhbHVlLCBidXQgdGhhdCB0aGUgdmFsdWUgd2ls bCBiZSBnZW5lcmF0ZWQgYnkgdGhlIElkUCBiYXNlZCBvbiBhbGwgZmluZ2VycHJpbnQgdmFsdWVz Pw0KDQpTbyBpZiB0aGVyZSB3ZXJlIG11bHRpcGxlIGZpbmdlcnByaW50LCB0aGUgU0RQIHdvdWxk IGhhdmUgbXVsdGlwbGUgSWRlbnRpdHkgbGluZXMuDQoNCg0KSW4gdGhhdCBjYXNlIEkgZG9u4oCZ dCB1bmRlcnN0YW5kIHRoZSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiA1LjYuNC4yLCB0aGF0IHNheXM6 DQoNCiAgIOKAnFRoZSBzZW1hbnRpY3Mgb2YgbXVsdGlwbGUgaWRlbnRpdHkgYXR0cmlidXRlcyBh cmUgdW5kZWZpbmVkLuKAnQ0KDQpBbHNvLCB0byBtZSDigJxhdHRyaWJ1dGUgTVVTVCBpbmNsdWRl IGFsbCBmaW5nZXJwcmludCB2YWx1ZXPigJ0gc291bmRzIGxpa2UgYSBzaW5nbGUgYXR0cmlidXRl IHdpdGggbXVsdGlwbGUgZmluZ2VycHJpbnQgdmFsdWVzLg0KDQoNCg0KUTM6DQotLS0tDQoNCklu IHRoZSBleGFtcGxlIGluIFNlY3Rpb24gNS42LjQuMSB0aGUgU0RQIGZpbmdlcnByaW50IGF0dHJp YnV0ZSBpcyBpbmNsdWRlZCBhcyBhIHNlc3Npb24tbGV2ZWwgYXR0cmlidXRlLiBIb3dldmVyLCBp dCBpcyBhIG1lZGlhLWxldmVsIGF0dHJpYnV0ZS4gQUZBSVIsIG1lZGlhLWxldmVsIGF0dHJpYnV0 ZXMgY2Fubm90IGJlIGluY2x1ZGVkIGFzIHNlc3Npb24tbGV2ZWwgYXR0cmlidXRlcy4NCg0KDQpJ IHRoaW5rIGZpbmdlcnByaW50IGlzIHZhbGlkIGFzIGJvdGggc2Vzc2lvbi1sZXZlbCBvciBtZWRp YS1sZXZlbCBzbyBJIHN1c3BlY3QgdGhpcyBpcyBmaW5lLiBKU0VQIGFsc28gc2F5cyB0aGF0IGlm IHRoZSBjZXJ0cyBhcmUgdGhlIHNhbWUsIHRoZW4gaXQgY2FuIGJlIHNlc3Npb24gbGV2ZWwgYnV0 IGlmIGRpZmZlcmVudCB0aGVuIG11c3QgYmUgbWVkaWEgbGV2ZWwuIFNvIEkgdGhpbmsgdGhpcyBp cyBjb3ZlcmVkIGluIEpTRVAuDQoNCkpTRVAgZG9lcyBub3QgZGVmaW5lIHRoZSBhdHRyaWJ1dGUu IElmIHRoZSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQgYm90aCBvbiBzZXNzaW9uLSBhbmQgbWVkaWEt bGV2ZWwgaXQgbmVlZHMgdG8gYmUgZGVmaW5lZCBpbiBzdWNoIHdheSBpbiBkcmFmdC1pZXRmLXJ0 Y3B3ZWItc2VjdXJpdHktYXJjaC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== --_000_7594FB04B1934943A5C02806D1A2204B72EEFB16ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRz IG9uIHRoZSBTRFAgaWRlbnRpdHkgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5RMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0tLS08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGRyYWZ0IHNheXMgdGhhdCwg YXQgbWluaW11bSwgdGhlIGZpbmdlcnByaW50IG5lZWRzIHRvIGJlIGJvdW5kIHRvIHRoZSBpZGVu dGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RG9lcyB0 aGlzIG1lYW4gdGhhdCwgaW4gb3JkZXIgdG8gaW5jbHVkZSBhbiBTRFAgaWRlbnRpdHkgYXR0cmli dXRlIGluIGFuIG9mZmVyL2Fuc3dlciwgdGhlIG9mZmVyL2Fuc3dlciBNVVNUIGFsc28gY29udGFp biBhdCBsZWFzdCBvbmUgU0RQIGZpbmdlcnByaW50IGF0dHJpYnV0ZT8gQmFzZWQgb24gdGhlDQog dGV4dCBhYm91dCBnZW5lcmF0aW5nIHRoZSBpZGVudGl0eSBpdCBzZWVtcyBsaWtlIHRoYXQsIGJ1 dCBpdCBpcyBub3QgdmVyeSBjbGVhciBpbiB0aGUgU0RQIHByb2NlZHVyZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KU0VQIHJl cXVpcmVzIERUTFMvU1JUUCB3aGljaCByZXF1aXJlcyBhZGRpbmcgdGhlIGZpbmdlcnByaW50IHNv IEkgdGhpbmsgdGhpcyBpcyBhbHJlYWR5IHJlcXVpcmVkLiBBbHNvIEpTRVAgcG9pbnRzIG91dCBs YWNrIG9mIGZpbmdlcnByaW50IHdpbGwgY2F1c2UgbmVnb3RpYXRpb24gZmFpbHVyZS4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOnJlZCI+VGhpcyBpcyBub3QgYWJvdXQgSlNFUCwgYnV0IHRoZSBkZWZpbml0 aW9uIG9mIHRoZSBTRFAgaWRlbnRpdHkgYXR0cmlidXRlLiBBcyB0aGlzIGF0dHJpYnV0ZSBjYW4g KEkgYXNzdW1lKSBiZSB1c2VkIG9uIHRoZSB3aXJlLCBpdCBuZWVkcyB0byBkZWZpbmVkIGFzIHN1 Y2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+VGhlIFVTQUdFIG9mIHRoZSBh dHRyaWJ1dGUgY2FuIHRoZW4gYmUgc2NvcGVkIHRvIFdlYlJUQywgSlNFUCwgb3Igd2hhdGV2ZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5RMjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0tLS08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2VjdGlvbiA1LjYu NC4xIHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dzOiAyO3dv cmQtd3JhcDogYnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7Jm5ic3A7ICZx dW90O1RoZSAmcXVvdDthPWlkZW50aXR5JnF1b3Q7IGF0dHJpYnV0ZSBNVVNUIGluY2x1ZGUgYWxs PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZpbmdlcnByaW50IHZhbHVlcyB0 aGF0IGFyZSBpbmNsdWRlZCBpbiAmcXVvdDthPWZpbmdlcnByaW50JnF1b3Q7IGxpbmVzLiZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rmlyc3QsIHJlbGF0ZWQg dG8gdGhlIGdlbmVyYXRpb24gb2YgdGhlIGFzc2VydGlvbiB2YWx1ZSwgaXQgaXMgdW5jbGVhciBo b3cgdGhpcyBpcyBpbXBsZW1lbnRlZC4gRm9yIGV4YW1wbGUsIGlzIHRoZXJlIGEgc2VwYXJhdGUg SlNPTiBvYmplY3QgKHNlY3Rpb24gNS42LjQpIHByb3ZpZGVkIHRvIHRoZQ0KIElkUCBmb3IgZWFj aCBmaW5nZXJwcmludD8gVGhlIHRleHQgdGFsa3MgYWJvdXQg4oCcc2luZ2xl4oCdIGZpbmdlcnBy aW50IGluIHRoZSBvYmplY3QuIE9yLCBhcmUgYWxsIGZpbmdlcnByaW50cyBpbmNsdWRlZCBpbiB0 aGUgc2FtZSBKU09OIG9iamVjdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllhaCwgSSB0 aGluayBpdCB3b3VsZCBnZXQgYSBJZGVudGl0eSB0b2tlbiBmb3IgZWFjaCBmaW5nZXJwcmludCB2 aWEgYSBHZW5lcmF0ZSBBc3NlcnRpb24gZm9yIGVhY2ggZmluZ2VycHJpbnQuIEJ1dCBJIHRoaW5r IHRoYXQgaXMgbGFyZ2VseSBXZWJSVEMgaXNzdWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6cmVkIj5XaGlsZSBpdCBtYXkgYmUgYW4gV2ViUlRDIGlzc3VlIGhvdyB0byB1c2UgbXVsdGlw bGUgZmluZ2VycHJpbnRzIGluIGdlbmVyYWwsIGl0IGlzIGFuIFNEUCBpc3N1ZSBob3cgdG8gZW5j b2RlIHRoZSBhdHRyaWJ1dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5TZWNvbmQsIGl0IGlzIHVuY2xlYXIgd2hhdCDigJxhdHRyaWJ1dGUgTVVTVCBpbmNsdWRlIGFs bCBmaW5nZXJwcmludCB2YWx1ZXPigJ0gbWVhbnMuIEkgYXNzdW1lIHRoYXQgdGhlIGF0dHJpYnV0 ZSB3aWxsIG9ubHkgaW5jbHVkZSBhIHNpbmdsZSBhdHRyaWJ1dGUgYXNzZXJ0aW9uIHZhbHVlLCBi dXQgdGhhdA0KIHRoZSB2YWx1ZSB3aWxsIGJlIGdlbmVyYXRlZCBieSB0aGUgSWRQIGJhc2VkIG9u IGFsbCBmaW5nZXJwcmludCB2YWx1ZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBp ZiB0aGVyZSB3ZXJlIG11bHRpcGxlIGZpbmdlcnByaW50LCB0aGUgU0RQIHdvdWxkIGhhdmUgbXVs dGlwbGUgSWRlbnRpdHkgbGluZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SW4gdGhhdCBjYXNlIEkgZG9u 4oCZdCB1bmRlcnN0YW5kIHRoZSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiA1LjYuNC4yLCB0aGF0IHNh eXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7IOKAnFRoZSBzZW1h bnRpY3Mgb2YgbXVsdGlwbGUgaWRlbnRpdHkgYXR0cmlidXRlcyBhcmUgdW5kZWZpbmVkLuKAnTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkFsc28sIHRvIG1lIDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6cmVkIj7igJxhdHRyaWJ1dGUgTVVTVCBpbmNsdWRlIGFsbCBmaW5nZXJwcmlu dCB2YWx1ZXPigJ0gc291bmRzIGxpa2UgYSBzaW5nbGUgYXR0cmlidXRlIHdpdGggbXVsdGlwbGUg ZmluZ2VycHJpbnQgdmFsdWVzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlEzOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ LS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0aGUg ZXhhbXBsZSBpbiBTZWN0aW9uIDUuNi40LjEgdGhlIFNEUCBmaW5nZXJwcmludCBhdHRyaWJ1dGUg aXMgaW5jbHVkZWQgYXMgYSBzZXNzaW9uLWxldmVsIGF0dHJpYnV0ZS4gSG93ZXZlciwgaXQgaXMg YSBtZWRpYS1sZXZlbCBhdHRyaWJ1dGUuIEFGQUlSLCBtZWRpYS1sZXZlbCBhdHRyaWJ1dGVzDQog Y2Fubm90IGJlIGluY2x1ZGVkIGFzIHNlc3Npb24tbGV2ZWwgYXR0cmlidXRlcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBmaW5n ZXJwcmludCBpcyB2YWxpZCBhcyBib3RoIHNlc3Npb24tbGV2ZWwgb3IgbWVkaWEtbGV2ZWwgc28g SSBzdXNwZWN0IHRoaXMgaXMgZmluZS4gSlNFUCBhbHNvIHNheXMgdGhhdCBpZiB0aGUgY2VydHMg YXJlIHRoZSBzYW1lLCB0aGVuIGl0IGNhbiBiZSBzZXNzaW9uIGxldmVsIGJ1dCBpZiBkaWZmZXJl bnQgdGhlbiBtdXN0IGJlIG1lZGlhIGxldmVsLiBTbyBJIHRoaW5rIHRoaXMgaXMgY292ZXJlZA0K IGluIEpTRVAuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkpTRVAgZG9lcyBub3QgZGVmaW5l IHRoZSBhdHRyaWJ1dGUuIElmIHRoZSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQgYm90aCBvbiBzZXNz aW9uLSBhbmQgbWVkaWEtbGV2ZWwgaXQgbmVlZHMgdG8gYmUgZGVmaW5lZCBpbiBzdWNoIHdheSBp biBkcmFmdC1pZXRmLXJ0Y3B3ZWItc2VjdXJpdHktYXJjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6cmVkIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQi PkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B72EEFB16ESESSMB109erics_-- From nobody Thu May 17 23:43: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 B92EC12741D for ; Thu, 17 May 2018 23:43:22 -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 2gRhyHPtqqyz for ; Thu, 17 May 2018 23:43:16 -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 732C2127342 for ; Thu, 17 May 2018 23:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526625793; 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=xIw9aaonw/foDzPzVSdIWIYglMCkNBzwD5iDI7y1R9c=; b=RRQjRknrP7ocuPcIjbHF8NPduLhezfbbDFEa+UkDOfaKB9wLmGx/UXQ1prJdAMVQ KFb5ulyOoG3C9VDEykQm9kasBiCWW6mlvj0WYgHxVdEBxb41hOcuzka5EBTt5RGL LpOsVFa9ni31fewbzeguz12OiPZkn29egWE1zTgSQ1Y=; X-AuditID: c1b4fb2d-a6b079c00000050d-c1-5afe7601cd26 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5B.DE.01293.1067EFA5; Fri, 18 May 2018 08:43:13 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0382.000; Fri, 18 May 2018 08:42:05 +0200 From: Christer Holmberg To: Cullen Jennings CC: RTCWeb IETF Thread-Topic: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute Thread-Index: AQHT6RGfenU2OZxm10q2tYkeSmM/qKQ0G04AgAAiMMCAAOi6AA== Date: Fri, 18 May 2018 06:42:04 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se> 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: [131.160.50.130] Content-Type: multipart/alternative; boundary="_000_D72450E12FE33christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2J7oC5j2b8og85eRYsP638wWqz9187u wOSxZMlPJo/L5z8yBjBFcdmkpOZklqUW6dslcGX0L2hjK1jZzVjR0D6PuYFxSlUXIyeHhICJ xNWt11m7GLk4hASOMErMbX4I5SxmlGjZ+5G5i5GDg03AQqL7nzZIg4iAssS5HXeZQWxmAUWJ L8vns4HYwgIxEnNnd7JC1MRK3N+/jRnCdpJY9v4/WJxFQFVi/coesHpeAWuJb08amSB2rWeU +HbtBivILk4BP4lnE0pBahgFxCS+n1rDBLFLXOLWk/lMEEcLSCzZc54ZwhaVePn4H9h8UQE9 iQ0nbrODjJEQUJK4vcEJojVBYtWrn+wQawUlTs58wjKBUXQWkqmzkJTNQlIGETeQeH9uPjOE rS2xbOFrKFtfYuOXs4wQtrXE4isz2ZHVLGDkWMUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokR GIcHt/zW3cG4+rXjIUYBDkYlHt6zSf+ihFgTy4orcw8xSnAwK4nwWpkChXhTEiurUovy44tK c1KLDzFKc7AoifPqrdoTJSSQnliSmp2aWpBaBJNl4uCUamBsMdj226/BVNcjKqzJtPm9xozb Qp/cVX49+zVTcXn0NratDF4fjxisaTkaWLpj1QX1hbqnnQ8oJimqBz62//3JtFAv3GHJEcnD 83Yt4/xa93iFz8cjrGfvMv9WW/OAfZWveUCwVLr+xlfl8x8Yim2uvG1dfYJBeGbTQpNwYR95 OTaeJd1ly94psRRnJBpqMRcVJwIAytldQb8CAAA= Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute 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: Fri, 18 May 2018 06:43:23 -0000 --_000_D72450E12FE33christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Resending, as it seems like my reply to Cullen yesterday got stucked somewh= ere on the Internet. Regards, Christer From: Christer Holmberg > Date: Thursday 17 May 2018 at 21:03 To: Cullen Jennings > Cc: "rtcweb@ietf.org" > Subject: RE: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP ide= ntity attribute Hi, A few questions/comments on the SDP identity attribute. Q1: ---- The draft says that, at minimum, the fingerprint needs to be bound to the i= dentity. Does this mean that, in order to include an SDP identity attribute in an of= fer/answer, the offer/answer MUST also contain at least one SDP fingerprint= attribute? Based on the text about generating the identity it seems like t= hat, but it is not very clear in the SDP procedures. JSEP requires DTLS/SRTP which requires adding the fingerprint so I think th= is is already required. Also JSEP points out lack of fingerprint will cause= negotiation failure. This is not about JSEP, but the definition of the SDP identity attribute. A= s this attribute can (I assume) be used on the wire, it needs to defined as= such. The USAGE of the attribute can then be scoped to WebRTC, JSEP, or whatever. Q2: ---- Section 5.6.4.1 says: "The "a=3Didentity" attribute MUST include all fingerprint values that are included in "a=3Dfingerprint" lines." First, related to the generation of the assertion value, it is unclear how = this is implemented. For example, is there a separate JSON object (section = 5.6.4) provided to the IdP for each fingerprint? The text talks about =93si= ngle=94 fingerprint in the object. Or, are all fingerprints included in the= same JSON object? Yah, I think it would get a Identity token for each fingerprint via a Gener= ate Assertion for each fingerprint. But I think that is largely WebRTC issu= e. While it may be an WebRTC issue how to use multiple fingerprints in general= , it is an SDP issue how to encode the attribute. Second, it is unclear what =93attribute MUST include all fingerprint values= =94 means. I assume that the attribute will only include a single attribute= assertion value, but that the value will be generated by the IdP based on = all fingerprint values? So if there were multiple fingerprint, the SDP would have multiple Identity= lines. In that case I don=92t understand the statement in section 5.6.4.2, that sa= ys: =93The semantics of multiple identity attributes are undefined.=94 Also, to me =93attribute MUST include all fingerprint values=94 sounds like= a single attribute with multiple fingerprint values. Q3: ---- In the example in Section 5.6.4.1 the SDP fingerprint attribute is included= as a session-level attribute. However, it is a media-level attribute. AFAI= R, media-level attributes cannot be included as session-level attributes. I think fingerprint is valid as both session-level or media-level so I susp= ect this is fine. JSEP also says that if the certs are the same, then it ca= n be session level but if different then must be media level. So I think th= is is covered in JSEP. JSEP does not define the attribute. If the attribute can be used both on se= ssion- and media-level it needs to be defined in such way in draft-ietf-rtc= pweb-security-arch. Regards, Christer --_000_D72450E12FE33christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5CD03C4C6803B647970079AA97E59914@ericsson.com> Content-Transfer-Encoding: quoted-printable

Resending, as it seems like my reply to Cullen yesterday got stucked s= omewhere on the Internet.

Regards,

Christer

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thursday 17 May 2018 at 21:03=
To: Cullen Jennings <fluffy@iii.ca>
Cc: "rtcweb@ietf.org" <= rtcweb@ietf.org>
Subject: RE: [rtcweb] draft-ietf-rt= cweb-security-arch: Questions on SDP identity attribute

 = ;

Hi,=

 

A few questions/comments on the SDP identity attrib= ute.

 

Q1:

----

 

The draft says that, at minimum, the fingerprint ne= eds to be bound to the identity.

 

Does this mean that, in order to include an SDP ide= ntity attribute in an offer/answer, the offer/answer MUST also contain at l= east one SDP fingerprint attribute? Based on the text about generating the identity it seems like that, but it is not very = clear in the SDP procedures.

 

 

JSEP requires DTLS/SRTP which requires adding the fi= ngerprint so I think this is already required. Also JSEP points out lack of= fingerprint will cause negotiation failure. 

 

This is not about JSEP, but the definitio= n of the SDP identity attribute. As this attribute can (I assume) be used o= n the wire, it needs to defined as such.

 

The USAGE of the attribute can then be sc= oped to WebRTC, JSEP, or whatever.



Q2:

----

 

Section 5.6.4.1 says:

   "The "a=3Didentit=
y" attribute MUST include all
   fingerprint values that are included in "a=3Dfingerp=
rint" lines."

 

First, related to the generation of the assertion v= alue, it is unclear how this is implemented. For example, is there a separa= te JSON object (section 5.6.4) provided to the IdP for each fingerprint? The text talks about =93single=94 fingerprint in= the object. Or, are all fingerprints included in the same JSON object?

 

Yah, I think it would get a Identity token for each = fingerprint via a Generate Assertion for each fingerprint. But I think that= is largely WebRTC issue. 


While it may be an WebRTC issue how to use multiple fingerprints= in general, it is an SDP issue how to encode the attribute.

 

 

Second, it is unclear what =93attribute MUST includ= e all fingerprint values=94 means. I assume that the attribute will only in= clude a single attribute assertion value, but that the value will be generated by the IdP based on all fingerprint values?

 

So if there were multiple fingerprint, the SDP would= have multiple Identity lines.

 

 

In that case I don=92t und= erstand the statement in section 5.6.4.2, that says:

 

   =93The semant= ics of multiple identity attributes are undefined.=94

 

Also, to me =93attribute MUST include all fingerprint values=94 sounds like a singl= e attribute with multiple fingerprint values.

 

 

Q3: 

----

 

In the example in Section 5.6.4.1 the SDP fingerpri= nt attribute is included as a session-level attribute. However, it is a med= ia-level attribute. AFAIR, media-level attributes cannot be included as session-level attributes.

 

 

I think fingerprint is valid as both session-level o= r media-level so I suspect this is fine. JSEP also says that if the certs a= re the same, then it can be session level but if different then must be med= ia level. So I think this is covered in JSEP. 

 

JSEP does not define the a= ttribute. If the attribute can be used both on session- and media-level it = needs to be defined in such way in draft-ietf-rtcpweb-security-arch.

 

Regards,

 

Christer

 --_000_D72450E12FE33christerholmbergericssoncom_-- From nobody Sun May 20 12:49: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 8DB7012D80F for ; Sun, 20 May 2018 12:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kpapa6mkqxN for ; Sun, 20 May 2018 12:49:18 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id A03D812D93E for ; Sun, 20 May 2018 12:49:18 -0700 (PDT) X-AuditID: 1207440f-e97ff7000000582b-99-5b01d13bfa66 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B1.26.22571.C31D10B5; Sun, 20 May 2018 15:49:16 -0400 (EDT) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id w4KJnDX2009427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 20 May 2018 15:49:15 -0400 To: "rtcweb@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B72EF3DA9@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <477e3870-00bc-19e2-21bb-563dd9c3df7a@alum.mit.edu> Date: Sun, 20 May 2018 15:49:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EF3DA9@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixO6iqGtzkTHa4M1TY4u1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fePa0G/WcWdr/+ZGxj3aHQxcnJICJhIrGqYx9rFyMUhJLCD SeJcxyk2kISQwHcmiebNmiC2sECMxNzZnawgtoiAusTlhxfYIRqWMkl0rZ7EDpJgE9CSmHPo PwuIzStgLzF3zwmwBhYBVYmm1Z1gNaICaRL3N09ihKgRlDg58wlQPQcHp4CfxJzvFSBhZgFb iTtzdzND2OISt57MZ4Kw5SWat85mnsDIPwtJ9ywkLbOQtMxC0rKAkWUVo1xiTmmubm5iZk5x arJucXJiXl5qka6JXm5miV5qSukmRkhI8u9g7Fovc4hRgINRiYf3RiFDtBBrYllxZe4hRkkO JiVRXi6r/1FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHiVlzFGC/GmJFZWpRblw6SkOViUxHlZ TfZGCQmkJ5akZqemFqQWwWRlODiUJHgPnAdqFCxKTU+tSMvMKUFIM3FwggznARr+FKSGt7gg Mbc4Mx0if4pRl2PK8/4eZiGWvPy8VClx3t8gRQIgRRmleXBzYKnkFaM40FvCvIoXgKp4gGkI btIroCVMQEs6DgF9x1tckoiQkmpgtIne9aPOVMHvYEyQb/rcua5bJy5pdVmzRltj5Yyvyh0P Qn1qzx9KZg3TdRc8vW9qnvOk4AerLm5nY7iz4OS9/bISPcEOWU5PPpp2LI9t33pM8EH5plcX GVguRd23UMi12lVoGZm0dV9hQ+oSD5Wcmp7Xbfti13MsV7DjmfKRbaOanTmTw6sQJZbijERD Leai4kQAts6RDAADAAA= Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute 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: Sun, 20 May 2018 19:49:21 -0000 Christer just made me aware of this discussion. I have a couple of comments about definition of the attribute. FIRST: I find the extension mechanism to be atypical. Currently it is: identity-attribute = "identity:" identity-assertion [ SP identity-extension *(";" [ SP ] identity-extension) ] This sets the list of extensions off from the identity assertion with a space while then separating them from one another by semicolons. This seems to blend SDP and SIP syntax oddly. I would expect to go more fully in one direction or the other. Either: identity-attribute = "identity:" identity-assertion *( SP identity-extension ) or identity-attribute = "identity:" identity-assertion *(";" identity-extension) (May require tweaking extension-att-value.) SECOND: Form of SDP attribute definitions: Historically there have been problems with the definitions of new SDP attributes. Especially, the manner of defining the syntax was inconsistent. RFC4566 gave insufficient guidance on how to do this. draft-ietf-mmusic-rfc4566bis (especially section 8.2.4.1) has provided more guidance on how to do this. Please do your definitions in that style. For instance: 5.6.4.2 a=identity Attribute The identity attribute is session level only. It contains an identity assertion, encoded as a base-64 string [RFC4648]. Attribute Name: identity Attribute Value: identity-value Usage Level: session Charset Dependent: No Mux Category: ??? The Augmented BNF syntax [2] for the attribute is: identity-value = identity-assertion [ SP identity-extension *(";" [ SP ] identity-extension) ] ; perhaps altered based on above discussion [continue on with remainder of section.] 7. IANA Considerations This document defines the SDP attribute,'identity'. The details of the attribute are defined in Section 5. For issues regarding this attribute contact Eric Rescorla (ekr@rftm.com). But it seems that current practice is moving away from identifying individuals in the contact information, in favor of listing a wg mailing list or the iesg mailing list. Thanks, Paul On 5/18/18 3:46 PM, Christer Holmberg wrote: > FYI, > > You may want to take a look at this. I wasn’t even aware that they are > defining an SDP attribute in the security architecture document, and as > far as I know there has been no request to e.g., the SDP security > directorate to look at it. > > Regards, > > Christer > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 18 May 2018 08:42 > *To:* Cullen Jennings > *Cc:* RTCWeb IETF > *Subject:* Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on > SDP identity attribute > > Resending, as it seems like my reply to Cullen yesterday got stucked > somewhere on the Internet. > > Regards, > > Christer > > *From: *Christer Holmberg > > *Date: *Thursday 17 May 2018 at 21:03 > *To: *Cullen Jennings > > *Cc: *"rtcweb@ietf.org " > > *Subject: *RE: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on > SDP identity attribute > > Hi, > > A few questions/comments on the SDP identity attribute. > > Q1: > > ---- > > The draft says that, at minimum, the fingerprint needs to be bound > to the identity. > > Does this mean that, in order to include an SDP identity attribute > in an offer/answer, the offer/answer MUST also contain at least one > SDP fingerprint attribute? Based on the text about generating the > identity it seems like that, but it is not very clear in the SDP > procedures. > > JSEP requires DTLS/SRTP which requires adding the fingerprint so I think > this is already required. Also JSEP points out lack of fingerprint will > cause negotiation failure. > > This is not about JSEP, but the definition of the SDP identity > attribute. As this attribute can (I assume) be used on the wire, it > needs to defined as such. > > The USAGE of the attribute can then be scoped to WebRTC, JSEP, or whatever. > > > > > Q2: > > ---- > > Section 5.6.4.1 says: > >    "The "a=identity" attribute MUST include all > >    fingerprint values that are included in "a=fingerprint" lines." > > First, related to the generation of the assertion value, it is > unclear how this is implemented. For example, is there a separate > JSON object (section 5.6.4) provided to the IdP for each > fingerprint? The text talks about “single” fingerprint in the > object. Or, are all fingerprints included in the same JSON object? > > Yah, I think it would get a Identity token for each fingerprint via a > Generate Assertion for each fingerprint. But I think that is largely > WebRTC issue. > > > While it may be an WebRTC issue how to use multiple fingerprints in > general, it is an SDP issue how to encode the attribute. > > Second, it is unclear what “attribute MUST include all fingerprint > values” means. I assume that the attribute will only include a > single attribute assertion value, but that the value will be > generated by the IdP based on all fingerprint values? > > So if there were multiple fingerprint, the SDP would have multiple > Identity lines. > > In that case I don’t understand the statement in section 5.6.4.2, that says: > >    “The semantics of multiple identity attributes are undefined.” > > Also, to me “attribute MUST include all fingerprint values” sounds like > a single attribute with multiple fingerprint values. > > > Q3: > > ---- > > In the example in Section 5.6.4.1 the SDP fingerprint attribute is > included as a session-level attribute. However, it is a media-level > attribute. AFAIR, media-level attributes cannot be included as > session-level attributes. > > I think fingerprint is valid as both session-level or media-level so I > suspect this is fine. JSEP also says that if the certs are the same, > then it can be session level but if different then must be media level. > So I think this is covered in JSEP. > > JSEP does not define the attribute. If the attribute can be used both on > session- and media-level it needs to be defined in such way in > draft-ietf-rtcpweb-security-arch. > > Regards, > > Christer > From nobody Wed May 23 05:55: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 1388F126FB3 for ; Wed, 23 May 2018 05:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 VX8TMazIS5Zu for ; Wed, 23 May 2018 05:55:15 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EA712E035 for ; Wed, 23 May 2018 05:55:13 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id 32-v6so3848321qtr.13 for ; Wed, 23 May 2018 05:55:13 -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=sB697wNF+bnVh31SGd1oH0WGLoLR/Plg+RX7gdGUTmI=; b=H4DgVnO9lBpX3tpfo2SWiVkkjTnoX0aMTTAsbxMQUkrIHnO/Z03Of5T33k5ryGCYVv WU4gJqRGaW9CAeMStEALFsUN4pwqPE3Lh8JRm1Y0CG7Cg5KrkYYu8CBgtGANorSI5VCL lBIHP5s8n51PoQntNYwDmCyAIiFlZD7ZZ5D44= 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=sB697wNF+bnVh31SGd1oH0WGLoLR/Plg+RX7gdGUTmI=; b=rpJ0ZIBRgOZRyZGtFhp1zn2gYe1hrPmGeu5Dg/+FR25RTlM3RhhedwIinTfihOD2Eq 2FK1LPd8pcDS1YXHF+KchOCQNabdXxqyZrBlSOcO2Qy3VL9Ja5d1QnoxzTXZPZyCNdag E5Xty2n/ZYXTj8HQ8qe1oBWC9Gt59RMQQ4MHGTsw8cSXh+1SaNpSXtK7GhGzxcyN0AZq D3iOygTnIRNh1OHfBclJO6jr5exd1/drqLYj5Wzq52OR7arLU8LMuSubOWL1uTQb7T2l ZoEvbO+E0QulGr/TCB5Ig94//MotucflImsJHTe4lcvvqkqMi8F+J+KB8y15lipLxD6O nU7A== X-Gm-Message-State: ALKqPwfBF4oSyrV0dS43D7qkLUqKQRttz0uNusXN2p1HrXIxllRXDfyL zeRVAqKIRepisaIVIhsJUQEveg== X-Google-Smtp-Source: AB8JxZoNfZaJirS8DpZNTKtn7b5zC571gY9Lr5jIVGl5V1qr2CVjqArNNPkhSlUL+V8kZTNVXTHP5A== X-Received: by 2002:ac8:4a2:: with SMTP id s34-v6mr2430657qtg.129.1527080112194; Wed, 23 May 2018 05:55:12 -0700 (PDT) Received: from [172.16.0.18] ([96.231.224.71]) by smtp.gmail.com with ESMTPSA id b3-v6sm12391623qkd.37.2018.05.23.05.55.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 05:55:11 -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: <7594FB04B1934943A5C02806D1A2204B72EBE65A@ESESSMB109.ericsson.se> Date: Wed, 23 May 2018 08:55:09 -0400 Cc: Martin Thomson , Eric Rescorla , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <1AEA14E0-7F36-4224-8375-E6899936D804@sn3rd.com> References: <7594FB04B1934943A5C02806D1A2204B72EBE65A@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) 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: Wed, 23 May 2018 12:55:19 -0000 > On May 10, 2018, at 13:21, Christer Holmberg = wrote: >=20 > Hi, >=20 >>>>> A couple of questions on the SDP identity attribute. >>>>>=20 >>>>> Q1: >>>>> --- >>>>>=20 >>>>> The draft lacks the offer/answer procedure sections (generate = offer,=20 >>>>> generate answer, modify session etc) for the attribute, which I=20 >>>>> think should be added. My question is regarding the following=20 >>>>> statement, which seems to indicate that the attribute is only used = in offers: >>>>>=20 >>>>> "Implementations SHOULD only include a single identity attribute = in=20 >>>>> an offer=C2=B2 (there is no text about including the attribute in = an=20 >>>>> answer) >>>>=20 >>>> This is about what to do if you include a=3Didentity not about = whether=20 >>>> to include it. >>>=20 >>> When new SDP attributes are defined, there needs to be offer/answer=20= >>> procedures. Because, I assume the attribute can be used on the wire,=20= >>> in SDP offers and answers? >>>=20 >>> Also, if the attribute is scoped to WebRTC, or to some specific=20 >>> security solutions, I think that also needs to be covered. >>>=20 >>>=20 >>>>> However, in draft-ietf-rtcweb-sdp it is included in both the offer=20= >>>>> and answer. >>>>=20 >>>> I think that draft-ietf-rtcweb-sdp includes them in both the offer=20= >>>> and the answer because the examples are using the WEBRTC Identity = mechanism. >>>> I think this is consistent with what is in both = draft-ietf-rtcweb-sdp=20 >>>> and draft-ietf-rtcweb-jsep: >>>>=20 >>>> If WebRTC identity is being used, an "a=3Didentity" line as = described=20 >>>> in [I-D.ietf-rtcweb-security-arch], Section 5. >>>=20 >>>=20 >>> That sentence is only for the initial offer. Unless I=E2=80=99ve = missed it,=20 >>> there is no text about a=3Didentity regarding answers. >>=20 >> Would making the following two change make it clearer that a=3Didentity= can be included in either/both: >>=20 >> 1) s.5.6.3 (r/SDP offer/exchange transaction/SDP offer/answer = exchange) >>=20 >> OLD: >>=20 >> An identity assertion binds the user's identity (as asserted by the >> IdP) to the SDP offer/exchange transaction and specifically to the >> media. >>=20 >> NEW: >>=20 >> An identity assertion binds the user's identity (as asserted by the >> IdP) to the SDP offer/answer exchange and specifically to the >> media. >>=20 >>=20 >> 2) s.5.6.4.1 >>=20 >> OLD: >>=20 >> Once an IdP has generated an assertion, it is attached to the SDP >> message. This is done by adding a new identity attribute to the = SDP. >>=20 >> NEW: >>=20 >> Once an IdP has generated an assertion, it is attached to the SDP >> offer/answer message. This is done by adding a new identity = attribute >> to the SDP. >>=20 >> or we could go even further: >>=20 >> NEW: >>=20 >> Once an IdP has generated an assertion, it is attached to the SDP >> offer/answer message. This is done by adding a new identity = attribute >> to the SDP; the offer includes the caller=E2=80=99s assertion; the = answer includes >> the callee=E2=80=99s assertion. >=20 > Without commenting on the specifics above at this point I went ahead and submitted PR: https://github.com/rtcweb-wg/security-arch/pull/68 Martin pointed out that the 2nd suggestion for s.5.6.4.1 that the = caller/callee distinction isn=E2=80=99t quite right because they = aren=E2=80=99t always in the same offer/answer roles. So I went with = the first suggestion or s5.6.4.1. > , the structure we normally use is: >=20 > x. SDP XXX Attribute <--- This section defines the attribute > y. SDP Offer/Answer Procedures > y.1. General > y.2. Generating the Initial SDP Offer > y.3. Generating the Answer > y.4. Offerer Processing of the SDP Answer > y.5. Modifying the Session Luckily, there are a bunch of SDP attributes defined and some follow = this structure and some don=E2=80=99t ;) I=E2=80=99ll admit that I=E2=80=99= m a little hesitant to suggest that we do a major editorial revision = because the draft has basically had the same layout for 2+ years.=20 >> Now as far as what more might be said to scope the attribute to = WebRTC, I=E2=80=99m pretty sure that=E2=80=99s covered in two ways: >>=20 >> 1) If folks are coming at this attribute from the IANA registry, then = the =E2=80=9CAppropriate Values=E2=80=9D registry entry=20 >> points to s5.6.4.2 of this document and that section pretty much gets = you to using IdP as described in this draft. >>=20 >> 2) If folks are coming at it from reading the draft/RFC, then well = it=E2=80=99s pretty clear that this attribute is used with IdPs. >=20 > Sure, and it would probably be enough to say that the attribute is = applicable to entities that support/use IdPs. Then we don't need to say = "WebRTC", because it is quite unclear what that really means. What it says is this: Purpose: This attribute carries an identity assertion, binding an identity to the transport-level security session. with the Appropriate values it=E2=80=99s pretty clear what goes in the = attribute. > ---- >=20 >>>>> Q2: >>>>> --- >>>>>=20 >>>>> Also, the mux category is missing=20 >>>>> (draft-ietf-mmusic-sdp-mux-attributes >>>>> also covers session-level attributes). I assume it is =C2=B3NORMAL=C2= =B2. >>>>=20 >>>> I think this mans adding: >>>>=20 >>>> Mux Category: NORMAL >>>>=20 >>>> to the IANA registration? >>>=20 >>> Correct. But, NORMAL is just my assumption - I want people to = confirm=20 >>> whether that is correct :) >>=20 >> I submitted PR to address this: >> https://github.com/rtcweb-wg/security-arch/pull/66 >>=20 >> I included =E2=80=9CNORMAL=E2=80=9D, but if somebody thinks this is = wrong I can change it.=20 >=20 > Assuming "NORMAL" is correct, the PR looks good :) Yeah I was kind of hoping that this PR would force people to comment ;) spt > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>>> On 23/04/18 01:47, "rtcweb on behalf of Martin Thomson" >>>> = wrote: >>>>=20 >>>>> tls-id is connection-based (i.e., it applies to a single bundle),=20= >>>>> whereas identity is session-based. That was my initial thought,=20= >>>>> but then we have to deal with the 1:N problem there. The simplest=20= >>>>> approach might be to move a=3Didentity to the bundle, but that = leads=20 >>>>> to some interesting downstream effects. You probably want to = avoid=20 >>>>> having multiple identities in the same RTCPeerConnection, for=20 >>>>> instance. >>>>>=20 >>>>> On Sat, Apr 21, 2018 at 11:10 AM, Eric Rescorla = wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Apr 12, 2018 at 6:45 AM, Sean Turner = wrote: >>>>>>>=20 >>>>>>> The WGLC for this document has ended. I think it was really = good=20 >>>>>>> that @ >>>>>>> IETF101 the IdP hackathon happened because it looked like they=20= >>>>>>> might have uncovered something to be changed in our document and=20= >>>>>>> possibly in the webrtc-pc draft; see the [0] thread. As the=20 >>>>>>> Shepherd trying to drive this to closure, we need to we need to=20= >>>>>>> decide what changes might be made in=20 >>>>>>> draft-ietf-rtcweb-security-arch. In that thread, I saw two=20 >>>>>>> things that we might change (both from mt): >>>>>>>=20 >>>>>>> 0) More text to address a linkability concern: >>>>>>>=20 >>>>>>> As a practical matter, if the browser were to use the same=20 >>>>>>> certificate for multiple origins, then it would create a massive=20= >>>>>>> privacy problem that enables linkability (aka user tracking). I=20= >>>>>>> couldn't find that written down, but I thought it was. If it=20 >>>>>>> isn't written down, then we should correct that. >>>>>>=20 >>>>>>=20 >>>>>> Isn't this the relevant text: >>>>>> " >>>>>>=20 >>>>>> API Requirement: Unless the user specifically configures an=20 >>>>>> external >>>>>> key pair, different key pairs MUST be used for each origin. >>>>>> (This >>>>>> avoids creating a super-cookie.) >>>>>>=20 >>>>>> " >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> I actually think this is basically covered here: >>>>>>>=20 >>>>>>> = https://tools.ietf.org/html/draft-ietf-rtcweb-security-10#section-4.4. >>>>>>> 1 >>>>>>> But want to make sure others agree: >>>>>>>=20 >>>>>>> 1) Tweak protocol to include an identifier to prevent reuse of=20= >>>>>>> assertion on every RTCPeerConnection: >>>>>>>=20 >>>>>>> More complex sites frequently generate multiple = RTCPeerConnection=20 >>>>>>> instances for their communications, especially for group=20 >>>>>>> conversations. If the browser requests an assertion once and=20 >>>>>>> they use that value for every RTCPeerConnection, then that's OK. = =20 >>>>>>> =46rom my perspective, I would be happy modifying the protocol = to=20 >>>>>>> include an identifier and prevent that; for this the IdP can use=20= >>>>>>> caching or its local storage. >>>>>>>=20 >>>>>>> So, what would that look like? >>>>>>=20 >>>>>>=20 >>>>>> Wouldn't it be sufficient to include the tls-id in the identity=20= >>>>>> binding? >>>>>>=20 >>>>>> -Ekr >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Did I miss anything else that needs to be addressed? >>>>>>>=20 >>>>>>> spt >>>>>>>=20 >>>>>>> [0] >>>>>>>=20 >>>>>>>=20 >>>>>>> = https://mailarchive.ietf..org/arch/msg/rtcweb/2r2u20UQIKwNeY1PsYF >>>>>>> rDw7j >>>>>>> XE >>>>>>> w >>>>>>>=20 >>>>>>>> On Mar 12, 2018, at 19:08, Sean Turner wrote: >>>>>>>>=20 >>>>>>>> All, >>>>>>>>=20 >>>>>>>> This is the WGLC for the =C2=B3WebRTC Security Architecture=C2=B2= draft >>>>>>> available >>>>>>>> @ https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. >>>>>>> Please >>>>>>>> review the draft and send your comments to this list by 2359UTC=20= >>>>>>>> on >>>>>>> April >>>>>>>> 6th, 2018. >>>>>>>>=20 >>>>>>>> Note the gh repo is here: >>>>>>>> https://github.com/rtcweb-wg/security-arch >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> C/T/S >>>>>>>=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 >>>>>>=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 >>>=20 >>=20 >=20 From nobody Wed May 23 06:12: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 0979912DA6C for ; Wed, 23 May 2018 06:11:59 -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 cwPM8lNPqlkV for ; Wed, 23 May 2018 06:11:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79718124D6C for ; Wed, 23 May 2018 06:11: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=1527081068; 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=ThQ05Ykw4es4czHuLq2qjO5l4F+UBglayUMyIFp835M=; b=OiyNTIePx+wCKcxGzpYxkEezA1jeyNHObab06m06nSNp6h2K9TVS5m63evfljrVQ kofHBVtrhATaKQzUKkkjIQtxdmrbmKMyUChUXA68aiwzaNst6eFxTK8xjdQcK3AG WZyvh7Ok8YeSFjWYRR1q5K1JKD+iI7rztExELQr9NfE=; X-AuditID: c1b4fb3a-77c239c00000451c-3d-5b05686cd195 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.65.17692.C68650B5; Wed, 23 May 2018 15:11:08 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0382.000; Wed, 23 May 2018 15:10:55 +0200 From: Christer Holmberg To: Sean Turner CC: Martin Thomson , Eric Rescorla , RTCWeb IETF Thread-Topic: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) - SDP O/A structure Thread-Index: AdPylxr2uLzTa8s0T76r47ULvo8kYw== Date: Wed, 23 May 2018 13:10:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72F02D42@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.171] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7um5OBmu0weJ/BhYrXp9jt7h25h+j xdp/7ewWV1Y1MjuweOycdZfdY8mSn0wekx+3MXscPMgYwBLFZZOSmpNZllqkb5fAlfFiwS7W giN8FfdffmdrYJzC18XIwSEhYCJxZ6F7FyMXh5DAEUaJ4x1XWLoYOYGcxYwS356YgNSwCVhI dP/TBgmLCChINB19wApiMwvkSCz708oC0issMI9RovHoX2aIovmMEp2feSBsPYkJDQ1gM1kE VCX2TdoK1swr4Ctx7OsSsDijgJjE91NrmCCGikvcejIfzJYQEJBYsuc8M4QtKvHy8T9WCFtJ 4sTDRmaQ25gFNCXW79KHaFWUmNL9kB1ivKDEyZlPWCYwCs9CMnUWQscsJB2zkHQsYGRZxSha nFpcnJtuZKSXWpSZXFycn6eXl1qyiREYFwe3/LbawXjwueMhRgEORiUe3gVprNFCrIllxZW5 hxglOJiVRHhDY4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZ3SLKKEBNITS1KzU1MLUotgskwc nFINjKJhWRGJjyZl72Z/3lW9VfHfJaWdF14onH+5bcknj6pgp2OSa7uWTPMu2HlyzoW3U1L5 J37XnDh/ZmApZ9Cr3buj/s/stJDvS614rfyz9HLo8kXKS/T53/JJxrA5H/Is1t+tHntRX3V/ /r705oo3L3SnT1stK76L4ZvI6VtlE3cVNb2vE59s902JpTgj0VCLuag4EQBT+VUAhwIAAA== Archived-At: Subject: Re: [rtcweb] Addressing WGLC comments for draft-ietf-rtcweb-security-arch? (was Re: WGLC for draft-ietf-rtcweb-security-arch) - SDP O/A structure 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: Wed, 23 May 2018 13:11:59 -0000 DQpIaSwNCg0KLi4uDQoNCj4+ICwgdGhlIHN0cnVjdHVyZSB3ZSBub3JtYWxseSB1c2UgaXM6DQo+ PiANCj4+IHguICBTRFAgWFhYIEF0dHJpYnV0ZSAgICA8LS0tIFRoaXMgc2VjdGlvbiBkZWZpbmVz IHRoZSBhdHRyaWJ1dGUNCj4+IHkuICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCj4+IHku MS4gIEdlbmVyYWwNCj4+IHkuMi4gIEdlbmVyYXRpbmcgdGhlIEluaXRpYWwgU0RQIE9mZmVyIA0K Pj4geS4zLiAgR2VuZXJhdGluZyB0aGUgQW5zd2VyIA0KPj4geS40LiAgT2ZmZXJlciBQcm9jZXNz aW5nIG9mIHRoZSBTRFAgQW5zd2VyIA0KPj4geS41LiAgTW9kaWZ5aW5nIHRoZSBTZXNzaW9uDQo+ DQo+IEx1Y2tpbHksIHRoZXJlIGFyZSBhIGJ1bmNoIG9mIFNEUCBhdHRyaWJ1dGVzIGRlZmluZWQg YW5kIHNvbWUgZm9sbG93IHRoaXMgc3RydWN0dXJlIGFuZCBzb21lIGRvbuKAmXQgOykNCg0KTGF0 ZWx5IHdlIGhhdmUgYmVlbiB2ZXJ5IHN0cmljdCB0aGF0IHRoZXkgZG8gZm9sbG93IHRoZSBzdHJ1 Y3R1cmUuIA0KDQpOb3csIGJhc2VkIG9uIHJlY2VudCBkaXNjdXNzaW9ucyByZWxhdGVkIHRvIEJV TkRMRSwgdGhlcmUgbWF5IGJlIHNvbWUgY2hhbmdlcyB0byB0aGlzIHN0cnVjdHVyZSAob3IsIGF0 IGxlYXN0IHRoZSB0ZXJtaW5vbG9neSB1c2VkKSwgYnV0IHVudGlsIHRoYXQgaGFwcGVucyB3ZSBz aG91bGQgdXNlIGl0Lg0KDQpFc3BlY2lhbGx5IHdoZW4gaXQgY29tZXMgdG8gImluaXRpYWwgU0RQ IG9mZmVyIiwgaXQgaXMgdXNlZnVsIHRvIGNsYXJpZnkgdGhhdCB0aGUgdGV4dCByZWZlcnMgdG8g dGhlIG9mZmVyIGluIHdoaWNoIHRoZSBhdHRyaWJ1dGUgaXMgZmlyc3QgaW5jbHVkZWQuIEl0IG1h eSBiZSB0aGUgaW5pdGlhbCBvZmZlciBvZiBhIHNlc3Npb24sIGJ1dCBhbHNvIGEgc3Vic2VxdWVu dCBvZmZlci4NCg0KPiBJ4oCZbGwgYWRtaXQgdGhhdCBJ4oCZbSBhIGxpdHRsZSBoZXNpdGFudCB0 byBzdWdnZXN0IHRoYXQgd2UgZG8gYSBtYWpvciBlZGl0b3JpYWwgcmV2aXNpb24gYmVjYXVzZSB0 aGUgZHJhZnQgaGFzIGJhc2ljYWxseSBoYWQgdGhlIHNhbWUgbGF5b3V0IGZvciAyKyB5ZWFycy4g DQoNClBlcnNvbmFsbHksIGFzIEkgaGF2ZW4ndCBiZWVuIGZvbGxvd2luZyB0aGUgc2VjdXJpdHkg d29yayB2ZXJ5IGNsb3NlbHksIEkgdW5mb3J0dW5hdGVseSBkaWRuJ3QgcmVhbGl6ZSB0aGF0IHdl IGFyZSBkZWZpbmluZyBhbiBTRFAgYXR0cmlidXRlIGluIHRoZSBzZWN1cml0eSBhcmNoaXRlY3R1 cmUgZG9jdW1lbnQsIHdoaWNoIGlzIHRoZSByZWFzb24gSSBkaWRuJ3QgY29tbWVudCBlYXJsaWVy LiBJIGFtIHNvcnJ5IGZvciB0aGF0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K From nobody Thu May 24 01:19: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 06A3F12D96A for ; Thu, 24 May 2018 01:19:55 -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 Y4-bdU0JMbI0 for ; Thu, 24 May 2018 01:19:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A7312D964 for ; Thu, 24 May 2018 01:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527149990; 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=G9FWhdw6Kqo8LoGPSZvN07CdCB9lrYfZC9FhJCexles=; b=O2exwLTo/gCtJdsz70Ni3w+eMiM3Txdcp3F5if0KZsMwcn/nAVo8w2sdNObYUcbu B7CjurbLhT0FXbefTXUvOcSfjPdl8JagyGyy2SHyeTso3WOjuS8ZvbAq3Y9FZUcw AFTsE6yar5DqiUTxRpkyDB2dnH+V/Y1SdHhD8hAoZKA=; X-AuditID: c1b4fb30-549ff700000065fb-c3-5b0675a678bb Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 90.A0.26107.6A5760B5; Thu, 24 May 2018 10:19:50 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0382.000; Thu, 24 May 2018 10:19:50 +0200 From: Christer Holmberg To: RTCWeb IETF , "sdp-directorate-private@ietf.org" CC: "rtcweb-chairs@ietf.org" , "mmusic-chairs@ietf.org" , "adam@nostrum.com" , Ben Campbell Thread-Topic: SDP directorate review of SDP Identity attribute (draft-ietf-rtcweb-security-arch-14) Thread-Index: AdPzN1wT5XjwzlheSrOwvOSQwMHuDg== Date: Thu, 24 May 2018 08:19:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72F048B9@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.169] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72F048B9ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7tO6yUrZog40N2hZ7/i5it5jfeZrd 4vzO9UwWPW9vsFis/dfObvH00Q4WBzaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvjw6PP jAVvFjJWrF3cwNrA2NvD2MXIySEhYCJxbPtKti5GLg4hgSOMEq1zl0M5ixklfi3qAXI4ONgE LCS6/2mDNIgIZElM/76EHaSGWWAzo8TOnq3sIAlhgQSJNxN2s0MUpUrs376AEcLWk/j0/Ak7 yBwWAVWJlb3MIGFeAV+Jc7u+sIDYjAJiEt9PrWECsZkFxCVuPZnPBHGcgMSSPeeZIWxRiZeP /7FC2EoSJ7s3s0DU50s0v77PCjFTUOLkzCcsExiFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssW vmaGsc8ceMyELL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmBMHdzy22AH48vnjocY BTgYlXh4TxWzRQuxJpYVV+YeYpTgYFYS4V2QBBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOa+G3 OUpIID2xJDU7NbUgtQgmy8TBKdXAGDK56OjDt8Vawdye789kvzl8027b1pnHfon3vXSuP6ES curZjJadGfM89h3bHpBRsjbxXVKpmL/FxEdlD5h8txrXdy6s7N2dkCYxKXYye9cczaas/mpJ 5/L1pxfNdrN3DlORMKna03rh1Xfuy8Zv107f+Tv5xZ6Je3Js5Jd/SklM0XTS+9rQrMRSnJFo qMVcVJwIAPxyukWlAgAA Archived-At: Subject: [rtcweb] SDP directorate review of SDP Identity attribute (draft-ietf-rtcweb-security-arch-14) 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: Thu, 24 May 2018 08:19:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72F048B9ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is my SDP directorate review of the SDP Identity attribute, defined i= n draft-ietf-rtcweb-security-arch-14. Most of the comments have previously been given as individual comments by P= aul K and myself. Some have also been addressed by Sean T, but I will inclu= de them for completeness. --- Q0 (Scope): As the SDP attribute definition should be able to stand on its own legs, th= ere should be a description/reference to the IdP solution that it is used f= or. Also, if the usage of the attribute is scoped to devices implementing the W= ebRTC specification, that should be indicated. --- Q1 (Structure): The document lacks the offer/answer procedure structure used for SDP attrib= utes. X.1 Generating the Initial Offer X.2 Generating the Answer X.3 Offerer Processing of the Answer X.4 Modifying the Session Based on discussion in MMUSIC, it is also good to clarify that "initial off= er" refers to the offer where the extension is first introduced. The O/A procedures also need to cover the case when an offer/answer from a = peer does not include an Identity attribute. --- Q2 (Missing information): The mux category is missing. --- Q3 (Grammar): The current ABNF says: identity-attribute =3D "identity:" identity-assertion [ SP identity-extension *(";" [ SP ] identity-extension) ] This mixes the usage of space and semicolon for separating identity asserti= ons. Please use one: identity-attribute =3D "identity:" identity-assertion *( SP identity-extension ) ...or: identity-attribute =3D "identity:" identity-assertion *(";" identity-extension) --- Q4 (Attribute definition): Historically there have been problems with the definitions of new SDP attri= butes. Especially, the manner of defining the syntax was inconsistent. RFC4= 566 gave insufficient guidance on how to do this. draft-ietf-mmusic-rfc4566= bis (especially section 8.2.4.1) has provided more guidance on how to do th= is. Please do your definitions in that style. For instance: 5.6.4.2 a=3Didentity Attribute The identity attribute is session level only. It contains an identity assertion, encoded as a base-64 string [RFC4648]. Attribute Name: identity Attribute Value: identity-value Usage Level: session Charset Dependent: No Mux Category: ??? The Augmented BNF syntax [2] for the attribute is: identity-attribute =3D "identity:" identity-assertion *( SP identity-extension ) [continue on with remainder of section.] --- Q5: The draft says that, at minimum, the fingerprint needs to be bound to the i= dentity. First, I assume this means that, for each assertion, the associated SDP fin= gerprint attribute must be included in the offer/answer. If so, please incl= ude text about that. Second, it would be good to indicate that, in the SDP, there is no link bet= ween a given assertion and the associated fingerprint. --- Q6: Section 5.6.4.1 says: "The "a=3Didentity" attribute MUST include all fingerprint values that are included in "a=3Dfingerprint" lines." It is unclear what "attribute MUST include all fingerprint values" means. I= assume that the text should say something like: "The "a=3Didentity" attribute MUST include an assertion for each a=3Dfingerprint attribute value that are included in the SDP offer/answe= r." It should also be clarified that, if the attribute is used on media-level i= n an m- section, it contains the assertion for each fingerprint associated = with that m- section. --- Q7: Section 5.6.4.2 says: "The semantics of multiple identity attributes are undefined." First, I don't see the difference in having a single attribute with multipl= e assertions, or multiple attributes with single assertions. Having said th= at, if we only want to allow one way, I would suggest to simply forbid mult= iple attributes. Second, it needs to be clarified that the rule apply to a given m- section. --- Q8: In the example in Section 5.6.4.1 the SDP fingerprint attribute is included= as a session-level attribute. However, it is currently only defined as a m= edia-level attribute. --- Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B72F048B9ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below is my SDP directorate review of the SDP Identi= ty attribute, defined in draft-ietf-rtcweb-security-arch-14.

 

Most of the comments have previously been given as i= ndividual comments by Paul K and myself. Some have also been addressed by S= ean T, but I will include them for completeness.

 

---

 

Q0 (Scope):

 

As the SDP attribute definition should be able to st= and on its own legs, there should be a description/reference to the IdP sol= ution that it is used for.

 

Also, if the usage of the attribute is scoped to dev= ices implementing the WebRTC specification, that should be indicated.<= /o:p>

 

---

 

Q1 (Structure):

 

The document lacks the offer/answer procedure struct= ure used for SDP attributes.

 

X.1  Generating the Initial Offer

X.2  Generating the Answer

X.3  Offerer Processing of the Answer

X.4  Modifying the Session

 

Based on discussion in MMUSIC, it is also good to cl= arify that “initial offer” refers to the offer where the extens= ion is first introduced.

 

The O/A procedures also need to cover the case when = an offer/answer from a peer does not include an Identity attribute.

 

---

 

Q2 (Missing information):

 

The mux category is missing.

 

---

 

Q3 (Grammar):

 

The current ABNF says:

 

    identity-attribute  =3D &= quot;identity:" identity-assertion

        &= nbsp;           &nbs= p;             =        [ SP identity-extension

        &= nbsp;           &nbs= p;             =        *(";" [ SP ] identity-e= xtension) ]

 

This mixes the usage of space and semicolon for s= eparating identity assertions. Please use one:

 

    identity-attribute  =3D &= quot;identity:" identity-assertion

        &= nbsp;           &nbs= p;             =       *( SP identity-extension )

 

…or:

 

    identity-attribute  =3D &= quot;identity:" identity-assertion

        &= nbsp;           &nbs= p;             =       *(";" identity-extension)

 

---

 

Q4 (Attribute definition):

 

Historically there have been problems with the de= finitions of new SDP attributes. Especially, the manner of defining the syn= tax was inconsistent. RFC4566 gave insufficient guidance on how to do this.= draft-ietf-mmusic-rfc4566bis (especially section 8.2.4.1) has provided more guidance on how to do this. Please do y= our definitions in that style. For instance:

 

    5.6.4.2  a=3Didentity Att= ribute

 

    The identity attribute is sess= ion level only.  It contains an

    identity assertion, encoded as= a base-64 string [RFC4648].

 

      Attribute Name: id= entity

 

      Attribute Value: i= dentity-value

 

      Usage Level: sessi= on

 

      Charset Dependent:= No

 

      Mux Category: ???<= o:p>

 

    The Augmented BNF syntax [2] f= or the attribute is:

 

    identity-attribute  =3D &= quot;identity:" identity-assertion

        &= nbsp;           &nbs= p;             =       *( SP identity-extension )

 

    [continue on with remainder of= section.]

 

---

 

Q5:

 

The draft says that= , at minimum, the fingerprint needs to be bound to the identity.=

 

First, I assume thi= s means that, for each assertion, the associated SDP fingerprint attribute = must be included in the offer/answer. If so, please include text about that= .

 

Second, it would be= good to indicate that, in the SDP, there is no link between a given assert= ion and the associated fingerprint.

 

---

 

Q6:

 

Section 5.6.4.1 say= s:

 
   "The "a=3Didentity" attribute MUST include=
 all
   fingerprint values that are included in "a=3Dfingerp=
rint" lines."

 

It is unclear what = “attribute MUST include all fingerprint values” means. I assume= that the text should say something like:

 

   "The "a=3Didentity" attribute MUST include=
 an assertion for each
   a=3Dfingerprint attribute value that are included in the =
SDP offer/answer.”
 
It should also be clarified that, if the attribute is used on media-l=
evel in an m- section, it contains the assertion for each fingerprint assoc=
iated with that m- section.
 
---
 
Q7:
 
Section 5.6.4.2 says:
 
  “The semantics of multiple identity attributes are undefi=
ned.”
 
First, I don’t see the difference in having a single attribute =
with multiple assertions, or multiple attributes with single assertions. Ha=
ving said that, if we only want to allow one way, I would suggest to simply=
 forbid multiple attributes.
 
Second, it needs to be clarified that the rule apply to a given m- se=
ction.
 
---
 
Q8:
 

In the example in S= ection 5.6.4.1 the SDP fingerprint attribute is included as a session-level= attribute. However, it is currently only defined as a media-level attribut= e.

 

---

 

Regards,=

 

Christer=

--_000_7594FB04B1934943A5C02806D1A2204B72F048B9ESESSMB109erics_-- From nobody Thu May 24 10:46: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 6A33312EAE6 for ; Thu, 24 May 2018 10:46:40 -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, 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 T5dubOQIbU9r for ; Thu, 24 May 2018 10:46:38 -0700 (PDT) Received: from smtp73.iad3b.emailsrvr.com (smtp73.iad3b.emailsrvr.com [146.20.161.73]) (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 010F412EAD6 for ; Thu, 24 May 2018 10:46:38 -0700 (PDT) Received: from smtp10.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 038BEE006D; Thu, 24 May 2018 13:46:37 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp10.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9CEE2E0068; Thu, 24 May 2018 13:46:36 -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, 24 May 2018 13:46:36 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se> Date: Thu, 24 May 2018 11:46:34 -0600 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8335F3D9-3A20-4B8F-AB44-62E2E966BAAB@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute 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: Thu, 24 May 2018 17:46:41 -0000 You are right Christer, I was looking at this the wrong way of how it = was used vs the defn. of Identity. Let me answer the questions from only = the point of view how the Identity header is defined by = draft-ietf-rtcweb-security-arch and not how the identity header is used = in WebRTC in general.=20 > On May 17, 2018, at 12:03 PM, Christer Holmberg = wrote: >=20 > =20 > Hi, > =20 > A few questions/comments on the SDP identity attribute. > =20 > Q1: > ---- > =20 > The draft says that, at minimum, the fingerprint needs to be bound to = the identity. > =20 > Does this mean that, in order to include an SDP identity attribute in = an offer/answer, the offer/answer MUST also contain at least one SDP = fingerprint attribute? Based on the text about generating the identity = it seems like that, but it is not very clear in the SDP procedures. > =20 > =20 It seems to me that the defn of an Identity header does not need it to = be use for fingerprints at all. What goes in it the assertion is pretty = much determined by the IdP. Some future system that did not have = fingerprints but used token binding or blockchain style smart contracts = could probably work just fine. It=E2=80=99s up to the IdP.=20 So I might be wrong but I would say that Identity header does not = require a fingerprint to be in the SDP, but when Identity is used in = WebRTC, there will also be a fingerprint.=20 >=20 > Q2: > ---- > =20 > Section 5.6.4.1 says: > "The "a=3Didentity" attribute MUST include all > fingerprint values that are included in "a=3Dfingerprint" lines." > =20 > First, related to the generation of the assertion value, it is unclear = how this is implemented. For example, is there a separate JSON object = (section 5.6.4) provided to the IdP for each fingerprint? The text talks = about =E2=80=9Csingle=E2=80=9D fingerprint in the object. Or, are all = fingerprints included in the same JSON object? > =20 >=20 As you point out, all that is the Identity assertion definition defines = is how to encode it and that=E2=80=99s base 64 of JSON so that part is = fine. Section 5.6.4.1 is about how it Identity is used in the contact of = WebRTC. How the IdP does this is pretty out of scope of IETF stuff but I = think you raise a good point that this implies that in the WebRTC case, = if there=20 > =20 > Second, it is unclear what =E2=80=9Cattribute MUST include all = fingerprint values=E2=80=9D means. I assume that the attribute will only = include a single attribute assertion value, but that the value will be = generated by the IdP based on all fingerprint values? > =20 > =20 > =20 > Q3:=20 > ---- > =20 > In the example in Section 5.6.4.1 the SDP fingerprint attribute is = included as a session-level attribute. However, it is a media-level = attribute. AFAIR, media-level attributes cannot be included as = session-level attributes. > =20 > =20 Section 8 of RFC4572 that defines the fingerprint attribute says that it = is both at session and media-level attribute. (2nd para of = https://tools.ietf.org/html/rfc4572#section-8 )=20 From nobody Thu May 24 10:50: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 E416D12EAD0; Thu, 24 May 2018 10:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6bV4WpZDDcr; Thu, 24 May 2018 10:50:31 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E57112E88B; Thu, 24 May 2018 10:50:31 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id p62-v6so2232502oie.10; Thu, 24 May 2018 10:50:31 -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=Oz7cQMydx2a1Yl0YwahS3z2Oa/C41QDK5UbXyCP68oY=; b=f1iBsMSYRCjfJ6ILj477KI1W9oVQ9QQnvnl9Pu85QwXhLnwtMQ6GpddCCnVmcrFP5s QNfHz2Ck0YK/1NNa9ACL6J5XAYQYrKcOZlK5uETRBKARmsM2qAhQKaB0pz2TOtPpbeEZ IPvF2jZzITVAD7IO8ICjZxZO3KCGLdEDuX+4eFDCJQyuYjWUUdH+FpNAO2fisyIymmN8 rJdEldqRBJcfhUyLe7uW1deUzWkxWDK2oVCqvIGtX/hVvr5XcCueBL5AXcr4FHosSA6W Q2Yt61StttN6KvkPFqhxeVyyjYLvqXDklnceGFC65vSyqqRki/5hj3rrTqLgK/+PFS2E rwJw== 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=Oz7cQMydx2a1Yl0YwahS3z2Oa/C41QDK5UbXyCP68oY=; b=Es3LL1sdFCKgStYFYyrzSIZentyv1D8qSRmsC5ot7B38CkNBisIK41S1flohjDXJsY FFIc+N/3A8YdHNL7/BKJL3rdkbOTtuyXI2MLazwfmmOvrQlQGI+sZaTQdD+NK12oq8Cq udZ1nyFg3FMhVgk2YyEcg58ng9uEBuiXFICiZCLJmWYLzGCA3B03y56JQYA7fF3boYDY NufC4S0T5nUdgJDMKzY3zacLcYMwmDPRIFAYp/qvMHVpy3pZzbsNMyaup0W7TegubIB2 C01wcpL0GggVsUDldyFTvFDjbm62398EZBe5bhXbzEbEcgTHYeNM/7hwU/lDoWGEVHM2 +eVQ== X-Gm-Message-State: ALKqPwfQtyFBsAPSiDsnaR9MlEEEGFRf7ApIwvJQyoIWOFL/b7bZh8NZ s88axI6aU2n7vE+w7Iv9MTMdySZxEQNXVfnCpew= X-Google-Smtp-Source: AB8JxZqTKepRiJRNy0MhD6C1+iNOoAl4xMipTnez5GId14iwaQ2iJ/p/xcUzZvzTn3No8y8GPxC74aJN4FBy698rQKY= X-Received: by 2002:aca:5f0b:: with SMTP id t11-v6mr4651953oib.103.1527184230179; Thu, 24 May 2018 10:50:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d5:0:0:0:0:0 with HTTP; Thu, 24 May 2018 10:49:59 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B72F048B9@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72F048B9@ESESSMB109.ericsson.se> From: Ted Hardie Date: Thu, 24 May 2018 10:49:59 -0700 Message-ID: To: Christer Holmberg Cc: RTCWeb IETF , "sdp-directorate-private@ietf.org" , "rtcweb-chairs@ietf.org" , "mmusic-chairs@ietf.org" , "adam@nostrum.com" , Ben Campbell Content-Type: multipart/alternative; boundary="0000000000008be734056cf7495b" Archived-At: Subject: Re: [rtcweb] SDP directorate review of SDP Identity attribute (draft-ietf-rtcweb-security-arch-14) 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: Thu, 24 May 2018 17:50:34 -0000 --0000000000008be734056cf7495b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, Can you let us know which of those you believe are still outstanding? Ted On Thu, May 24, 2018 at 1:19 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Below is my SDP directorate review of the SDP Identity attribute, defined > in draft-ietf-rtcweb-security-arch-14. > > > > Most of the comments have previously been given as individual comments by > Paul K and myself. Some have also been addressed by Sean T, but I will > include them for completeness. > > > > --- > > > > Q0 (Scope): > > > > As the SDP attribute definition should be able to stand on its own legs, > there should be a description/reference to the IdP solution that it is us= ed > for. > > > > Also, if the usage of the attribute is scoped to devices implementing the > WebRTC specification, that should be indicated. > > > > --- > > > > Q1 (Structure): > > > > The document lacks the offer/answer procedure structure used for SDP > attributes. > > > > X.1 Generating the Initial Offer > > X.2 Generating the Answer > > X.3 Offerer Processing of the Answer > > X.4 Modifying the Session > > > > Based on discussion in MMUSIC, it is also good to clarify that =E2=80=9Ci= nitial > offer=E2=80=9D refers to the offer where the extension is first introduce= d. > > > > The O/A procedures also need to cover the case when an offer/answer from = a > peer does not include an Identity attribute. > > > > --- > > > > Q2 (Missing information): > > > > The mux category is missing. > > > > --- > > > > Q3 (Grammar): > > > > The current ABNF says: > > > > identity-attribute =3D "identity:" identity-assertion > > [ SP identity-extension > > *(";" [ SP ] identity-extension)= ] > > > > This mixes the usage of space and semicolon for separating identity > assertions. Please use one: > > > > identity-attribute =3D "identity:" identity-assertion > > *( SP identity-extension ) > > > > =E2=80=A6or: > > > > identity-attribute =3D "identity:" identity-assertion > > *(";" identity-extension) > > > > --- > > > > Q4 (Attribute definition): > > > > Historically there have been problems with the definitions of new SDP > attributes. Especially, the manner of defining the syntax was inconsisten= t. > RFC4566 gave insufficient guidance on how to do this. > draft-ietf-mmusic-rfc4566bis (especially section 8.2.4.1) has provided mo= re > guidance on how to do this. Please do your definitions in that style. For > instance: > > > > 5.6.4.2 a=3Didentity Attribute > > > > The identity attribute is session level only. It contains an > > identity assertion, encoded as a base-64 string [RFC4648]. > > > > Attribute Name: identity > > > > Attribute Value: identity-value > > > > Usage Level: session > > > > Charset Dependent: No > > > > Mux Category: ??? > > > > The Augmented BNF syntax [2] for the attribute is: > > > > identity-attribute =3D "identity:" identity-assertion > > *( SP identity-extension ) > > > > [continue on with remainder of section.] > > > > --- > > > > Q5: > > > > The draft says that, at minimum, the fingerprint needs to be bound to the > identity. > > > > First, I assume this means that, for each assertion, the associated SDP > fingerprint attribute must be included in the offer/answer. If so, please > include text about that. > > > > Second, it would be good to indicate that, in the SDP, there is no link > between a given assertion and the associated fingerprint. > > > > --- > > > > Q6: > > > > Section 5.6.4.1 says: > > > > "The "a=3Didentity" attribute MUST include all > > fingerprint values that are included in "a=3Dfingerprint" lines." > > > > It is unclear what =E2=80=9Cattribute MUST include all fingerprint values= =E2=80=9D means. > I assume that the text should say something like: > > > > "The "a=3Didentity" attribute MUST include an assertion for each > > a=3Dfingerprint attribute value that are included in the SDP offer/ans= wer.=E2=80=9D > > > > It should also be clarified that, if the attribute is used on media-level= in an m- section, it contains the assertion for each fingerprint associate= d with that m- section. > > > > --- > > > > Q7: > > > > Section 5.6.4.2 says: > > > > =E2=80=9CThe semantics of multiple identity attributes are undefined.= =E2=80=9D > > > > First, I don=E2=80=99t see the difference in having a single attribute wi= th multiple assertions, or multiple attributes with single assertions. Havi= ng said that, if we only want to allow one way, I would suggest to simply f= orbid multiple attributes. > > > > Second, it needs to be clarified that the rule apply to a given m- sectio= n. > > > > --- > > > > Q8: > > > > In the example in Section 5.6.4.1 the SDP fingerprint attribute is > included as a session-level attribute. However, it is currently only > defined as a media-level attribute. > > > > --- > > > > Regards, > > > > Christer > --0000000000008be734056cf7495b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

Can you let us = know which of those you believe are still outstanding?

=
Ted

On Thu, May 24, 2018 at 1:19 AM, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Below is my SDP directorate review of the SDP Identi= ty attribute, defined in draft-ietf-rtcweb-security-arch-14.=

=C2=A0

Most of the comments have previously been given as i= ndividual comments by Paul K and myself. Some have also been addressed by S= ean T, but I will include them for completeness.

=C2=A0

---

=C2=A0

Q0 (Scope):

=C2=A0

As the SDP attribute definition should be able to st= and on its own legs, there should be a description/reference to the IdP sol= ution that it is used for.

=C2=A0

Also, if the usage of the attribute is scoped to dev= ices implementing the WebRTC specification, that should be indicated.

=C2=A0

---

=C2=A0

Q1 (Structure):

=C2=A0

The document lacks the offer/answer procedure struct= ure used for SDP attributes.

=C2=A0

X.1 =C2=A0Generating the Initial Offer=

X.2=C2=A0 Generating the Answer

X.3=C2=A0 Offerer Processing of the Answer=

X.4 =C2=A0Modifying the Session

=C2=A0

Based on discussion in MMUSIC, it is also good to cl= arify that =E2=80=9Cinitial offer=E2=80=9D refers to the offer where the ex= tension is first introduced.

=C2=A0

The O/A procedures also need to cover the case when = an offer/answer from a peer does not include an Identity attribute.<= u>

=C2=A0

---

=C2=A0

Q2 (Missing information):=

=C2=A0

The mux category is missing.=

=C2=A0

---

=C2=A0

Q3 (Grammar):<= /p>

=C2=A0

The current ABNF says:

=C2=A0

=C2=A0=C2=A0=C2=A0 identity-= attribute=C2=A0 =3D "identity:" identity-assertion<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[ SP iden= tity-extension

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*(";= " [ SP ] identity-extension) ]

=C2=A0

This mixes the usage of spac= e and semicolon for separating identity assertions. Please use one:<= u>

=C2=A0

=C2=A0=C2=A0=C2=A0 identity-= attribute=C2=A0 =3D "identity:" identity-assertion<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*( SP identity-= extension )

=C2=A0

=E2=80=A6or:

=C2=A0

=C2=A0=C2=A0=C2=A0 identity-= attribute=C2=A0 =3D "identity:" identity-assertion<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*(";"= identity-extension)

=C2=A0

---

=C2=A0

Q4 (Attribute definition):

=C2=A0

Historically there have been= problems with the definitions of new SDP attributes. Especially, the manne= r of defining the syntax was inconsistent. RFC4566 gave insufficient guidan= ce on how to do this. draft-ietf-mmusic-rfc4566bis (especially section 8.2.4.1) has provided more guidance on how to do this. Please do y= our definitions in that style. For instance:

=C2=A0

=C2=A0=C2=A0=C2=A0 5.6.4.2= =C2=A0 a=3Didentity Attribute

=C2=A0

=C2=A0=C2=A0=C2=A0 The ident= ity attribute is session level only.=C2=A0 It contains an

=C2=A0=C2=A0=C2=A0 identity = assertion, encoded as a base-64 string [RFC4648].

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Attribute Name: identity

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Attribute Value: identity-value

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Usage Level: session

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Charset Dependent: No

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Mux Category: ???

=C2=A0

=C2=A0=C2=A0=C2=A0 The Augme= nted BNF syntax [2] for the attribute is:

=C2=A0

=C2=A0=C2=A0=C2=A0 identity-= attribute=C2=A0 =3D "identity:" identity-assertion<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*( SP identity-= extension )

=C2=A0

=C2=A0=C2=A0=C2=A0 [continue= on with remainder of section.]

=C2=A0

---

=C2=A0

Q5:

=C2=A0

The draft says that= , at minimum, the fingerprint needs to be bound to the identity.<= /u>

=C2=A0

First, I assume thi= s means that, for each assertion, the associated SDP fingerprint attribute = must be included in the offer/answer. If so, please include text about that= .

=C2=A0

Second, it would be= good to indicate that, in the SDP, there is no link between a given assert= ion and the associated fingerprint.

=C2=A0

---

=C2=A0

Q6:

=C2=A0

Section 5.6.4.1 say= s:

=C2=A0
=C2=A0=C2=A0 "The "a=3Didentity" attribute MUST include=
 all
=C2=A0=C2=A0 fingerprint values that are included in "a=3Dfingerp=
rint" lines."

=C2=A0

It is unclear what = =E2=80=9Cattribute MUST include all fingerprint values=E2=80=9D means. I as= sume that the text should say something like:

=C2=A0

=C2=A0=C2=A0 "The "a=3Didentity" attribute MUST include=
 an assertion for each
=C2=A0=C2=A0 a=3Dfingerprint attribute value that are included in the =
SDP offer/answer.=E2=80=9D
=C2=A0
It should also be clarified that, if the attribute is used on media-l=
evel in an m- section, it contains the assertion for each fingerprint assoc=
iated with that m- section.
=C2=A0
---
=C2=A0
Q7:
=C2=A0
Section 5.6.4.2 says:
=C2=A0
=C2=A0 =E2=80=9CThe semantics of multiple identity attributes are unde=
fined.=E2=80=9D
=C2=A0
First, I don=E2=80=99t see the difference in having a single attribut=
e with multiple assertions, or multiple attributes with single assertions. =
Having said that, if we only want to allow one way, I would suggest to simp=
ly forbid multiple attributes.
=C2=A0
Second, it needs to be clarified that the rule apply to a given m- se=
ction.
=C2=A0
---
=C2=A0
Q8:
=C2=A0

In the example in S= ection 5.6.4.1 the SDP fingerprint attribute is included as a session-level= attribute. However, it is currently only defined as a media-level attribut= e.

=C2=A0

---

=C2=A0

Regards,

=

=C2=A0

Christer<= /u>


--0000000000008be734056cf7495b-- From nobody Thu May 24 12: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 346B312EB11 for ; Thu, 24 May 2018 12:36:42 -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 JPgGOomHhr7a for ; Thu, 24 May 2018 12:36:40 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E50F12EB13 for ; Thu, 24 May 2018 12:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527190595; 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=B23bjUF3hHQOUw42KOQd/Wj4AhO/5P18jnFHn9ZeR10=; b=Qi9UmaenyRiq133Xq7WiSpxdvoZeaGjKZhUrt396WnhJOpPnMVNoP4cAAJ0NErs5 uXXcEnbh3Rw9Tcq7Eh1kzsCKWIH4plG4A2bjNDdNjMeB9nYSYxHz4T+zkdPqVgzY yCUnC7eopWvOe2GwslVeM9ZHc0rUHPVa9edoxqUqLwM=; X-AuditID: c1b4fb30-561ff700000065fb-5d-5b071443b32d Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E7.B3.26107.344170B5; Thu, 24 May 2018 21:36:35 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0382.000; Thu, 24 May 2018 21:36:34 +0200 From: Christer Holmberg To: Ted Hardie CC: RTCWeb IETF , "sdp-directorate-private@ietf.org" , "rtcweb-chairs@ietf.org" , "mmusic-chairs@ietf.org" , "adam@nostrum.com" , Ben Campbell Thread-Topic: SDP directorate review of SDP Identity attribute (draft-ietf-rtcweb-security-arch-14) Thread-Index: AdPzN1wT5XjwzlheSrOwvOSQwMHuDgAP4KCAAAfSrcA= Date: Thu, 24 May 2018 19:36:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72F06F33@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72F048B9@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.170] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B72F06F33ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7hK6zCHu0wYfvuhZ7/i5it5jfeZrd 4vzO9UwWPW9vsFis/dfObvH00Q4Wi8a5dg7sHjtn3WX3WLLkJ5PHrJ1PWAKYo7hsUlJzMstS i/TtErgyPuy4xFzwbj5TxZEDy9gbGFfMYOpi5OSQEDCRaGh/y9jFyMUhJHCEUeL1m1tQzmJG icmNF1i6GDk42AQsJLr/aYM0iAgoS+y9soMNpIZZYDaTxNfuxSwgCWGBFIlni/ewQxSlSuzf voARwraSmL5lGVgNi4CqxK33y1hBbF4BX4k5e5+BxYUEpjBKfFyrD2JzCgRK7N51Few6RgEx ie+n1oDZzALiEreezIe6WkBiyZ7zzBC2qMTLx/9YIWwliTObnrNA1OdLPDrTyQ6xS1Di5Mwn LBMYRWYhGTULSdksJGWzgF5mFtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYRYtTi5Ny 042M9FKLMpOLi/Pz9PJSSzYxAqPy4JbfBjsYXz53PMQowMGoxMObw8MeLcSaWFZcmXuIUYKD WUmEt/sXW7QQb0piZVVqUX58UWlOavEhRmkOFiVxXgu/zVFCAumJJanZqakFqUUwWSYOTqkG RpPf/L6VNwoUvple61Cq99l0wr/C6tuByGNfM5Y1LLIVXbGDe9WxCfYPCzlOKr4V1r2tuYXz oFvpVVbDWQ6bLxUaVvDu8kzm/x2zZwLDS62TtRZzCprnbXzyVbWApYTrtMm+Da/NmX8qWd22 qWP0zFivbGWko9VjsynohKH/tuMHNBZYfzCaocRSnJFoqMVcVJwIAERfkaHGAgAA Archived-At: Subject: Re: [rtcweb] SDP directorate review of SDP Identity attribute (draft-ietf-rtcweb-security-arch-14) 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: Thu, 24 May 2018 19:36:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B72F06F33ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5DYW4geW91IGxldCB1cyBrbm93IHdoaWNoIG9mIHRob3NlIHlvdSBiZWxpZXZlIGFy ZSBzdGlsbCBvdXRzdGFuZGluZz8NCg0KSSBiZWxpZXZlIGFsbCBleGNlcHQgUTIgYXJlIHN0aWxs IG91dHN0YW5kaW5nLg0KDQpTZWFuIGRpZCBoYXZlIHNvbWUgaW5wdXQgb24gUTAsIGJ1dCBJIGFt IG5vdCBzdXJlIHRoZXJlIHdhcyBldmVyIGFuIG91dGNvbWUuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KDQpPbiBUaHUsIE1heSAyNCwgMjAxOCBhdCAxOjE5IEFNLCBDaHJpc3RlciBIb2xt YmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpCZWxvdyBpcyBteSBTRFAgZGlyZWN0 b3JhdGUgcmV2aWV3IG9mIHRoZSBTRFAgSWRlbnRpdHkgYXR0cmlidXRlLCBkZWZpbmVkIGluIGRy YWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTQuDQoNCk1vc3Qgb2YgdGhlIGNvbW1lbnRz IGhhdmUgcHJldmlvdXNseSBiZWVuIGdpdmVuIGFzIGluZGl2aWR1YWwgY29tbWVudHMgYnkgUGF1 bCBLIGFuZCBteXNlbGYuIFNvbWUgaGF2ZSBhbHNvIGJlZW4gYWRkcmVzc2VkIGJ5IFNlYW4gVCwg YnV0IEkgd2lsbCBpbmNsdWRlIHRoZW0gZm9yIGNvbXBsZXRlbmVzcy4NCg0KLS0tDQoNClEwIChT Y29wZSk6DQoNCkFzIHRoZSBTRFAgYXR0cmlidXRlIGRlZmluaXRpb24gc2hvdWxkIGJlIGFibGUg dG8gc3RhbmQgb24gaXRzIG93biBsZWdzLCB0aGVyZSBzaG91bGQgYmUgYSBkZXNjcmlwdGlvbi9y ZWZlcmVuY2UgdG8gdGhlIElkUCBzb2x1dGlvbiB0aGF0IGl0IGlzIHVzZWQgZm9yLg0KDQpBbHNv LCBpZiB0aGUgdXNhZ2Ugb2YgdGhlIGF0dHJpYnV0ZSBpcyBzY29wZWQgdG8gZGV2aWNlcyBpbXBs ZW1lbnRpbmcgdGhlIFdlYlJUQyBzcGVjaWZpY2F0aW9uLCB0aGF0IHNob3VsZCBiZSBpbmRpY2F0 ZWQuDQoNCi0tLQ0KDQpRMSAoU3RydWN0dXJlKToNCg0KVGhlIGRvY3VtZW50IGxhY2tzIHRoZSBv ZmZlci9hbnN3ZXIgcHJvY2VkdXJlIHN0cnVjdHVyZSB1c2VkIGZvciBTRFAgYXR0cmlidXRlcy4N Cg0KWC4xICBHZW5lcmF0aW5nIHRoZSBJbml0aWFsIE9mZmVyDQpYLjIgIEdlbmVyYXRpbmcgdGhl IEFuc3dlcg0KWC4zICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhlIEFuc3dlcg0KWC40ICBNb2Rp ZnlpbmcgdGhlIFNlc3Npb24NCg0KQmFzZWQgb24gZGlzY3Vzc2lvbiBpbiBNTVVTSUMsIGl0IGlz IGFsc28gZ29vZCB0byBjbGFyaWZ5IHRoYXQg4oCcaW5pdGlhbCBvZmZlcuKAnSByZWZlcnMgdG8g dGhlIG9mZmVyIHdoZXJlIHRoZSBleHRlbnNpb24gaXMgZmlyc3QgaW50cm9kdWNlZC4NCg0KVGhl IE8vQSBwcm9jZWR1cmVzIGFsc28gbmVlZCB0byBjb3ZlciB0aGUgY2FzZSB3aGVuIGFuIG9mZmVy L2Fuc3dlciBmcm9tIGEgcGVlciBkb2VzIG5vdCBpbmNsdWRlIGFuIElkZW50aXR5IGF0dHJpYnV0 ZS4NCg0KLS0tDQoNCg0KUTIgKE1pc3NpbmcgaW5mb3JtYXRpb24pOg0KDQoNCg0KVGhlIG11eCBj YXRlZ29yeSBpcyBtaXNzaW5nLg0KDQoNCg0KLS0tDQoNCg0KDQpRMyAoR3JhbW1hcik6DQoNCg0K DQpUaGUgY3VycmVudCBBQk5GIHNheXM6DQoNCg0KDQogICAgaWRlbnRpdHktYXR0cmlidXRlICA9 ICJpZGVudGl0eToiIGlkZW50aXR5LWFzc2VydGlvbg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFsgU1AgaWRlbnRpdHktZXh0ZW5zaW9uDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKigiOyIgWyBTUCBdIGlkZW50aXR5LWV4dGVu c2lvbikgXQ0KDQoNCg0KVGhpcyBtaXhlcyB0aGUgdXNhZ2Ugb2Ygc3BhY2UgYW5kIHNlbWljb2xv biBmb3Igc2VwYXJhdGluZyBpZGVudGl0eSBhc3NlcnRpb25zLiBQbGVhc2UgdXNlIG9uZToNCg0K DQoNCiAgICBpZGVudGl0eS1hdHRyaWJ1dGUgID0gImlkZW50aXR5OiIgaWRlbnRpdHktYXNzZXJ0 aW9uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqKCBTUCBpZGVu dGl0eS1leHRlbnNpb24gKQ0KDQoNCg0K4oCmb3I6DQoNCg0KDQogICAgaWRlbnRpdHktYXR0cmli dXRlICA9ICJpZGVudGl0eToiIGlkZW50aXR5LWFzc2VydGlvbg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKigiOyIgaWRlbnRpdHktZXh0ZW5zaW9uKQ0KDQoNCg0K LS0tDQoNCg0KDQpRNCAoQXR0cmlidXRlIGRlZmluaXRpb24pOg0KDQoNCg0KSGlzdG9yaWNhbGx5 IHRoZXJlIGhhdmUgYmVlbiBwcm9ibGVtcyB3aXRoIHRoZSBkZWZpbml0aW9ucyBvZiBuZXcgU0RQ IGF0dHJpYnV0ZXMuIEVzcGVjaWFsbHksIHRoZSBtYW5uZXIgb2YgZGVmaW5pbmcgdGhlIHN5bnRh eCB3YXMgaW5jb25zaXN0ZW50LiBSRkM0NTY2IGdhdmUgaW5zdWZmaWNpZW50IGd1aWRhbmNlIG9u IGhvdyB0byBkbyB0aGlzLiBkcmFmdC1pZXRmLW1tdXNpYy1yZmM0NTY2YmlzIChlc3BlY2lhbGx5 IHNlY3Rpb24gOC4yLjQuMSkgaGFzIHByb3ZpZGVkIG1vcmUgZ3VpZGFuY2Ugb24gaG93IHRvIGRv IHRoaXMuIFBsZWFzZSBkbyB5b3VyIGRlZmluaXRpb25zIGluIHRoYXQgc3R5bGUuIEZvciBpbnN0 YW5jZToNCg0KDQoNCiAgICA1LjYuNC4yICBhPWlkZW50aXR5IEF0dHJpYnV0ZQ0KDQoNCg0KICAg IFRoZSBpZGVudGl0eSBhdHRyaWJ1dGUgaXMgc2Vzc2lvbiBsZXZlbCBvbmx5LiAgSXQgY29udGFp bnMgYW4NCg0KICAgIGlkZW50aXR5IGFzc2VydGlvbiwgZW5jb2RlZCBhcyBhIGJhc2UtNjQgc3Ry aW5nIFtSRkM0NjQ4XS4NCg0KDQoNCiAgICAgIEF0dHJpYnV0ZSBOYW1lOiBpZGVudGl0eQ0KDQoN Cg0KICAgICAgQXR0cmlidXRlIFZhbHVlOiBpZGVudGl0eS12YWx1ZQ0KDQoNCg0KICAgICAgVXNh Z2UgTGV2ZWw6IHNlc3Npb24NCg0KDQoNCiAgICAgIENoYXJzZXQgRGVwZW5kZW50OiBObw0KDQoN Cg0KICAgICAgTXV4IENhdGVnb3J5OiA/Pz8NCg0KDQoNCiAgICBUaGUgQXVnbWVudGVkIEJORiBz eW50YXggWzJdIGZvciB0aGUgYXR0cmlidXRlIGlzOg0KDQoNCg0KICAgIGlkZW50aXR5LWF0dHJp YnV0ZSAgPSAiaWRlbnRpdHk6IiBpZGVudGl0eS1hc3NlcnRpb24NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICooIFNQIGlkZW50aXR5LWV4dGVuc2lvbiApDQoNCg0K DQogICAgW2NvbnRpbnVlIG9uIHdpdGggcmVtYWluZGVyIG9mIHNlY3Rpb24uXQ0KDQoNCg0KLS0t DQoNCg0KDQpRNToNCg0KVGhlIGRyYWZ0IHNheXMgdGhhdCwgYXQgbWluaW11bSwgdGhlIGZpbmdl cnByaW50IG5lZWRzIHRvIGJlIGJvdW5kIHRvIHRoZSBpZGVudGl0eS4NCg0KRmlyc3QsIEkgYXNz dW1lIHRoaXMgbWVhbnMgdGhhdCwgZm9yIGVhY2ggYXNzZXJ0aW9uLCB0aGUgYXNzb2NpYXRlZCBT RFAgZmluZ2VycHJpbnQgYXR0cmlidXRlIG11c3QgYmUgaW5jbHVkZWQgaW4gdGhlIG9mZmVyL2Fu c3dlci4gSWYgc28sIHBsZWFzZSBpbmNsdWRlIHRleHQgYWJvdXQgdGhhdC4NCg0KU2Vjb25kLCBp dCB3b3VsZCBiZSBnb29kIHRvIGluZGljYXRlIHRoYXQsIGluIHRoZSBTRFAsIHRoZXJlIGlzIG5v IGxpbmsgYmV0d2VlbiBhIGdpdmVuIGFzc2VydGlvbiBhbmQgdGhlIGFzc29jaWF0ZWQgZmluZ2Vy cHJpbnQuDQoNCi0tLQ0KDQoNCg0KUTY6DQoNClNlY3Rpb24gNS42LjQuMSBzYXlzOg0KDQoNCg0K ICAgIlRoZSAiYT1pZGVudGl0eSIgYXR0cmlidXRlIE1VU1QgaW5jbHVkZSBhbGwNCg0KICAgZmlu Z2VycHJpbnQgdmFsdWVzIHRoYXQgYXJlIGluY2x1ZGVkIGluICJhPWZpbmdlcnByaW50IiBsaW5l cy4iDQoNCkl0IGlzIHVuY2xlYXIgd2hhdCDigJxhdHRyaWJ1dGUgTVVTVCBpbmNsdWRlIGFsbCBm aW5nZXJwcmludCB2YWx1ZXPigJ0gbWVhbnMuIEkgYXNzdW1lIHRoYXQgdGhlIHRleHQgc2hvdWxk IHNheSBzb21ldGhpbmcgbGlrZToNCg0KDQogICAiVGhlICJhPWlkZW50aXR5IiBhdHRyaWJ1dGUg TVVTVCBpbmNsdWRlIGFuIGFzc2VydGlvbiBmb3IgZWFjaA0KDQogICBhPWZpbmdlcnByaW50IGF0 dHJpYnV0ZSB2YWx1ZSB0aGF0IGFyZSBpbmNsdWRlZCBpbiB0aGUgU0RQIG9mZmVyL2Fuc3dlci7i gJ0NCg0KDQoNCkl0IHNob3VsZCBhbHNvIGJlIGNsYXJpZmllZCB0aGF0LCBpZiB0aGUgYXR0cmli dXRlIGlzIHVzZWQgb24gbWVkaWEtbGV2ZWwgaW4gYW4gbS0gc2VjdGlvbiwgaXQgY29udGFpbnMg dGhlIGFzc2VydGlvbiBmb3IgZWFjaCBmaW5nZXJwcmludCBhc3NvY2lhdGVkIHdpdGggdGhhdCBt LSBzZWN0aW9uLg0KDQoNCg0KLS0tDQoNCg0KDQpRNzoNCg0KDQoNClNlY3Rpb24gNS42LjQuMiBz YXlzOg0KDQoNCg0KICDigJxUaGUgc2VtYW50aWNzIG9mIG11bHRpcGxlIGlkZW50aXR5IGF0dHJp YnV0ZXMgYXJlIHVuZGVmaW5lZC7igJ0NCg0KDQoNCkZpcnN0LCBJIGRvbuKAmXQgc2VlIHRoZSBk aWZmZXJlbmNlIGluIGhhdmluZyBhIHNpbmdsZSBhdHRyaWJ1dGUgd2l0aCBtdWx0aXBsZSBhc3Nl cnRpb25zLCBvciBtdWx0aXBsZSBhdHRyaWJ1dGVzIHdpdGggc2luZ2xlIGFzc2VydGlvbnMuIEhh dmluZyBzYWlkIHRoYXQsIGlmIHdlIG9ubHkgd2FudCB0byBhbGxvdyBvbmUgd2F5LCBJIHdvdWxk IHN1Z2dlc3QgdG8gc2ltcGx5IGZvcmJpZCBtdWx0aXBsZSBhdHRyaWJ1dGVzLg0KDQoNCg0KU2Vj b25kLCBpdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQgdGhhdCB0aGUgcnVsZSBhcHBseSB0byBhIGdp dmVuIG0tIHNlY3Rpb24uDQoNCg0KDQotLS0NCg0KDQoNClE4Og0KDQoNCkluIHRoZSBleGFtcGxl IGluIFNlY3Rpb24gNS42LjQuMSB0aGUgU0RQIGZpbmdlcnByaW50IGF0dHJpYnV0ZSBpcyBpbmNs dWRlZCBhcyBhIHNlc3Npb24tbGV2ZWwgYXR0cmlidXRlLiBIb3dldmVyLCBpdCBpcyBjdXJyZW50 bHkgb25seSBkZWZpbmVkIGFzIGEgbWVkaWEtbGV2ZWwgYXR0cmlidXRlLg0KDQotLS0NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B72F06F33ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm04MDMyNjQ1MjMz ODU3MDgyNjM1bXNvcGxhaW50ZXh0LCBsaS5tODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4 dCwgZGl2Lm04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0DQoJe21zby1zdHlsZS1uYW1l Om1fODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b25zb2xhcyIsc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5ob2Vu emINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5DYW4geW91IGxldCB1cyBrbm93IHdoaWNoIG9mIHRob3NlIHlv dSBiZWxpZXZlIGFyZSBzdGlsbCBvdXRzdGFuZGluZz88c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGJlbGlldmUg YWxsIGV4Y2VwdCBRMiBhcmUgc3RpbGwgb3V0c3RhbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZWFuIGRpZCBoYXZlIHNvbWUgaW5wdXQgb24gUTAsIGJ1 dCBJIGFtIG5vdCBzdXJlIHRoZXJlIHdhcyBldmVyIGFuIG91dGNvbWUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUaHUsIE1heSAyNCwgMjAxOCBhdCAxOjE5IEFNLCBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlbG93IGlzIG15IFNE UCBkaXJlY3RvcmF0ZSByZXZpZXcgb2YgdGhlIFNEUCBJZGVudGl0eSBhdHRyaWJ1dGUsIGRlZmlu ZWQgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC0xNC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk1vc3Qgb2YgdGhlIGNvbW1lbnRzIGhhdmUgcHJldmlvdXNseSBiZWVuIGdp dmVuIGFzIGluZGl2aWR1YWwgY29tbWVudHMgYnkgUGF1bCBLIGFuZCBteXNlbGYuIFNvbWUgaGF2 ZSBhbHNvIGJlZW4gYWRkcmVzc2VkIGJ5IFNlYW4gVCwgYnV0IEkgd2lsbCBpbmNsdWRlIHRoZW0g Zm9yIGNvbXBsZXRlbmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+UTAgKFNjb3BlKTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkFzIHRoZSBTRFAgYXR0cmlidXRlIGRlZmluaXRpb24gc2hvdWxkIGJlIGFibGUgdG8gc3Rh bmQgb24gaXRzIG93biBsZWdzLCB0aGVyZSBzaG91bGQgYmUgYSBkZXNjcmlwdGlvbi9yZWZlcmVu Y2UgdG8gdGhlIElkUCBzb2x1dGlvbiB0aGF0IGl0IGlzIHVzZWQgZm9yLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QWxzbywgaWYgdGhlIHVzYWdlIG9mIHRoZSBhdHRyaWJ1dGUgaXMgc2Nv cGVkIHRvIGRldmljZXMgaW1wbGVtZW50aW5nIHRoZSBXZWJSVEMgc3BlY2lmaWNhdGlvbiwgdGhh dCBzaG91bGQgYmUgaW5kaWNhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0tPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5RMSAoU3RydWN0dXJlKTo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSBkb2N1bWVudCBsYWNrcyB0aGUgb2ZmZXIvYW5zd2VyIHByb2NlZHVy ZSBzdHJ1Y3R1cmUgdXNlZCBmb3IgU0RQIGF0dHJpYnV0ZXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5YLjEgJm5ic3A7R2VuZXJhdGluZyB0aGUgSW5pdGlhbCBPZmZlcjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5YLjImbmJzcDsgR2VuZXJhdGluZyB0aGUgQW5z d2VyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlguMyZuYnNwOyBPZmZl cmVyIFByb2Nlc3Npbmcgb2YgdGhlIEFuc3dlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5YLjQgJm5ic3A7TW9kaWZ5aW5nIHRoZSBTZXNzaW9uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5CYXNlZCBvbiBkaXNjdXNzaW9uIGluIE1NVVNJQywgaXQgaXMgYWxzbyBn b29kIHRvIGNsYXJpZnkgdGhhdCDigJxpbml0aWFsIG9mZmVy4oCdIHJlZmVycyB0byB0aGUgb2Zm ZXIgd2hlcmUgdGhlIGV4dGVuc2lvbiBpcyBmaXJzdCBpbnRyb2R1Y2VkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhlIE8vQSBwcm9jZWR1cmVzIGFsc28gbmVlZCB0byBjb3ZlciB0aGUg Y2FzZSB3aGVuIGFuIG9mZmVyL2Fuc3dlciBmcm9tIGEgcGVlciBkb2VzIG5vdCBpbmNsdWRlIGFu IElkZW50aXR5IGF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tLTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+UTIgKE1pc3Npbmcg aW5mb3JtYXRpb24pOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgy NjM1bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0 NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+VGhlIG11eCBjYXRlZ29yeSBpcyBtaXNzaW5nLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1z b3BsYWludGV4dCI+LS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcw ODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMy NjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij5RMyAoR3JhbW1hcik6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij5U aGUgY3VycmVudCBBQk5GIHNheXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUy MzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaWRl bnRpdHktYXR0cmlidXRlJm5ic3A7ID0gJnF1b3Q7aWRlbnRpdHk6JnF1b3Q7IGlkZW50aXR5LWFz c2VydGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNv cGxhaW50ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7WyBTUCBpZGVudGl0eS1leHRlbnNpb248bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyooJnF1b3Q7OyZxdW90OyBbIFNQIF0gaWRlbnRpdHktZXh0ZW5zaW9uKSBdPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxh aW50ZXh0Ij5UaGlzIG1peGVzIHRoZSB1c2FnZSBvZiBzcGFjZSBhbmQgc2VtaWNvbG9uIGZvciBz ZXBhcmF0aW5nIGlkZW50aXR5IGFzc2VydGlvbnMuIFBsZWFzZSB1c2Ugb25lOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlkZW50aXR5LWF0dHJpYnV0ZSZuYnNwOyA9ICZxdW90O2lk ZW50aXR5OiZxdW90OyBpZGVudGl0eS1hc3NlcnRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyooIFNQIGlkZW50aXR5 LWV4dGVuc2lvbiApPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2 MzVtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1 MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij7igKZvcjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBpZGVudGl0eS1hdHRyaWJ1dGUmbmJzcDsgPSAmcXVvdDtpZGVudGl0eTomcXVvdDsg aWRlbnRpdHktYXNzZXJ0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4 NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsqKCZxdW90OzsmcXVvdDsgaWRlbnRpdHktZXh0 ZW5zaW9uKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNv cGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1 NzA4MjYzNW1zb3BsYWludGV4dCI+LS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2 NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij5RNCAoQXR0cmlidXRlIGRlZmlu aXRpb24pOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNv cGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1 NzA4MjYzNW1zb3BsYWludGV4dCI+SGlzdG9yaWNhbGx5IHRoZXJlIGhhdmUgYmVlbiBwcm9ibGVt cyB3aXRoIHRoZSBkZWZpbml0aW9ucyBvZiBuZXcgU0RQIGF0dHJpYnV0ZXMuIEVzcGVjaWFsbHks IHRoZSBtYW5uZXIgb2YgZGVmaW5pbmcgdGhlIHN5bnRheCB3YXMgaW5jb25zaXN0ZW50LiBSRkM0 NTY2IGdhdmUgaW5zdWZmaWNpZW50IGd1aWRhbmNlIG9uIGhvdyB0byBkbyB0aGlzLiBkcmFmdC1p ZXRmLW1tdXNpYy1yZmM0NTY2YmlzDQogKGVzcGVjaWFsbHkgc2VjdGlvbiA4LjIuNC4xKSBoYXMg cHJvdmlkZWQgbW9yZSBndWlkYW5jZSBvbiBob3cgdG8gZG8gdGhpcy4gUGxlYXNlIGRvIHlvdXIg ZGVmaW5pdGlvbnMgaW4gdGhhdCBzdHlsZS4gRm9yIGluc3RhbmNlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IDUuNi40LjImbmJzcDsgYT1pZGVudGl0eSBBdHRyaWJ1dGU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFp bnRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgaWRlbnRpdHkgYXR0cmlidXRlIGlzIHNlc3Np b24gbGV2ZWwgb25seS4mbmJzcDsgSXQgY29udGFpbnMgYW48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGlkZW50aXR5IGFzc2VydGlvbiwgZW5jb2RlZCBhcyBhIGJhc2UtNjQgc3RyaW5nIFtSRkM0NjQ4 XS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWlu dGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2 MzVtc29wbGFpbnRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdHRyaWJ1dGUg TmFtZTogaWRlbnRpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4 MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2 NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBdHRyaWJ1dGUgVmFsdWU6IGlkZW50aXR5LXZhbHVlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVXNhZ2UgTGV2ZWw6IHNlc3Npb248bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGFyc2V0IERlcGVuZGVudDogTm88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFp bnRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNdXggQ2F0ZWdvcnk6ID8/Pzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1z b3BsYWludGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBBdWdtZW50ZWQgQk5GIHN5bnRheCBb Ml0gZm9yIHRoZSBhdHRyaWJ1dGUgaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2 NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxhaW50ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsg aWRlbnRpdHktYXR0cmlidXRlJm5ic3A7ID0gJnF1b3Q7aWRlbnRpdHk6JnF1b3Q7IGlkZW50aXR5 LWFzc2VydGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1 bXNvcGxhaW50ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KiggU1AgaWRlbnRpdHktZXh0ZW5zaW9uICk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBbY29udGludWUgb24gd2l0aCByZW1haW5kZXIgb2Ygc2Vj dGlvbi5dPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29w bGFpbnRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3 MDgyNjM1bXNvcGxhaW50ZXh0Ij4tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODAzMjY0 NTIzMzg1NzA4MjYzNW1zb3BsYWludGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPlE1OjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdCI+VGhlIGRyYWZ0IHNheXMgdGhhdCwgYXQgbWluaW11bSwg dGhlIGZpbmdlcnByaW50IG5lZWRzIHRvIGJlIGJvdW5kIHRvIHRoZSBpZGVudGl0eS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5GaXJzdCwgSSBhc3N1bWUg dGhpcyBtZWFucyB0aGF0LCBmb3IgZWFjaCBhc3NlcnRpb24sIHRoZSBhc3NvY2lhdGVkIFNEUCBm aW5nZXJwcmludCBhdHRyaWJ1dGUgbXVzdCBiZSBpbmNsdWRlZCBpbiB0aGUgb2ZmZXIvYW5zd2Vy LiBJZiBzbywgcGxlYXNlDQogaW5jbHVkZSB0ZXh0IGFib3V0IHRoYXQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+U2Vjb25kLCBpdCB3b3VsZCBiZSBnb29k IHRvIGluZGljYXRlIHRoYXQsIGluIHRoZSBTRFAsIHRoZXJlIGlzIG5vIGxpbmsgYmV0d2VlbiBh IGdpdmVuIGFzc2VydGlvbiBhbmQgdGhlIGFzc29jaWF0ZWQgZmluZ2VycHJpbnQuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4tLS08L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibTgwMzI2NDUyMzM4NTcwODI2MzVtc29wbGFpbnRleHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04MDMyNjQ1MjMzODU3MDgyNjM1bXNvcGxh aW50ZXh0Ij5RNjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij5TZWN0aW9uIDUuNi40LjEgc2F5czo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDt3b3JkLXdyYXA6YnJl YWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7ICZxdW90O1RoZSAmcXVvdDthPWlkZW50aXR5JnF1b3Q7IGF0dHJpYnV0 ZSBNVVNUIGluY2x1ZGUgYWxsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZp bmdlcnByaW50IHZhbHVlcyB0aGF0IGFyZSBpbmNsdWRlZCBpbiAmcXVvdDthPWZpbmdlcnByaW50 JnF1b3Q7IGxpbmVzLiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0Ij5JdCBpcyB1bmNsZWFyIHdoYXQg4oCcYXR0cmlidXRlIE1VU1QgaW5jbHVkZSBhbGwgZmlu Z2VycHJpbnQgdmFsdWVz4oCdIG1lYW5zLiBJIGFzc3VtZSB0aGF0IHRoZSB0ZXh0IHNob3VsZCBz YXkgc29tZXRoaW5nIGxpa2U6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1b3Q7VGhlICZxdW90O2E9aWRlbnRpdHkm cXVvdDsgYXR0cmlidXRlIE1VU1QgaW5jbHVkZSBhbiBhc3NlcnRpb24gZm9yIGVhY2g8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYT1maW5nZXJwcmludCBhdHRyaWJ1dGUgdmFs dWUgdGhhdCBhcmUgaW5jbHVkZWQgaW4gdGhlIFNEUCBvZmZlci9hbnN3ZXIu4oCdPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JdCBzaG91bGQgYWxzbyBiZSBjbGFyaWZpZWQgdGhhdCwgaWYgdGhlIGF0dHJpYnV0ZSBp cyB1c2VkIG9uIG1lZGlhLWxldmVsIGluIGFuIG0tIHNlY3Rpb24sIGl0IGNvbnRhaW5zIHRoZSBh c3NlcnRpb24gZm9yIGVhY2ggZmluZ2VycHJpbnQgYXNzb2NpYXRlZCB3aXRoIHRoYXQgbS0gc2Vj dGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tLS08L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5RNzo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5TZWN0aW9uIDUuNi40LjIgc2F5czo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IOKAnFRoZSBzZW1hbnRpY3Mg b2YgbXVsdGlwbGUgaWRlbnRpdHkgYXR0cmlidXRlcyBhcmUgdW5kZWZpbmVkLuKAnTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Rmlyc3QsIEkgZG9u4oCZdCBzZWUgdGhlIGRpZmZlcmVuY2UgaW4gaGF2aW5nIGEgc2lu Z2xlIGF0dHJpYnV0ZSB3aXRoIG11bHRpcGxlIGFzc2VydGlvbnMsIG9yIG11bHRpcGxlIGF0dHJp YnV0ZXMgd2l0aCBzaW5nbGUgYXNzZXJ0aW9ucy4gSGF2aW5nIHNhaWQgdGhhdCwgaWYgd2Ugb25s eSB3YW50IHRvIGFsbG93IG9uZSB3YXksIEkgd291bGQgc3VnZ2VzdCB0byBzaW1wbHkgZm9yYmlk IG11bHRpcGxlIGF0dHJpYnV0ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+U2Vjb25kLCBpdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQgdGhhdCB0aGUgcnVsZSBh cHBseSB0byBhIGdpdmVuIG0tIHNlY3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LS0tPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+UTg6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij5JbiB0aGUgZXhhbXBsZSBpbiBTZWN0aW9uIDUuNi40LjEgdGhlIFNEUCBm aW5nZXJwcmludCBhdHRyaWJ1dGUgaXMgaW5jbHVkZWQgYXMgYSBzZXNzaW9uLWxldmVsIGF0dHJp YnV0ZS4gSG93ZXZlciwgaXQgaXMgY3VycmVudGx5IG9ubHkgZGVmaW5lZCBhcw0KIGEgbWVkaWEt bGV2ZWwgYXR0cmlidXRlLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0Ij4tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiM4 ODg4ODgiPkNocmlzdGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B72F06F33ESESSMB109erics_-- From nobody Thu May 24 12:49:19 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 2297212DA3F for ; Thu, 24 May 2018 12:49:18 -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 Msd7oaCA0pec for ; Thu, 24 May 2018 12:49:16 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D77128959 for ; Thu, 24 May 2018 12:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527191354; 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=QFKlunO/n887eFQ4uHrLHe7MyAmwxMtdwYlGJ3OI2MY=; b=IWXdNIJ1l8Vwk5F7JFFJtKqV6YZiyjEVVe5Bh1CGCN85jFw12wW9gWevwoPC2+1p 6+4zf8WWPwQWEbH9B8tI9q8hlf61lNhkXz6G+rPXbDXRuwTTddeVJv3TubEnMb5X eqzoqcg0ztCKfMeCT8Mct2rYS6ZNJ9QBpqnEYINJN+g=; X-AuditID: c1b4fb30-549ff700000065fb-15-5b0717395687 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.45.26107.937170B5; Thu, 24 May 2018 21:49:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.29]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0382.000; Thu, 24 May 2018 21:49:13 +0200 From: Christer Holmberg To: Cullen Jennings CC: RTCWeb IETF Thread-Topic: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute Thread-Index: AQHT6RGfenU2OZxm10q2tYkeSmM/qKQ0G04AgAAiMMCACt0nAIAAQWoA Date: Thu, 24 May 2018 19:49:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B72F06FBD@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B72EEFB16@ESESSMB109.ericsson.se> <8335F3D9-3A20-4B8F-AB44-62E2E966BAAB@iii.ca> In-Reply-To: <8335F3D9-3A20-4B8F-AB44-62E2E966BAAB@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.170] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7t66VOHu0Qdc8DosP638wWqz9187u wOSxZMlPJo/L5z8yBjBFcdmkpOZklqUW6dslcGW0/WhhKTinWXHx+m/GBsYjGl2MHBwSAiYS K36EdzFycQgJHGGUaNt6kgnCWcwocenNdUaQIjYBC4nuf9pdjJwcIgLKEud23GUGsZkFFCW+ LJ/PBmILC8RILN69lBmiJlbi/v5tULabxIrmB2A2i4CqxMyeBWA2r4CvxM2/zYwQu+4zSizv mcgOsotTwEpi2e8akBpGATGJ76fWMEHsEpe49WQ+mC0hICCxZM95ZghbVOLl43+sELaSxJlN z1lAxjALaEqs36UPc+aU7ofsEGsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypG0eLU4qTc dCMjvdSizOTi4vw8vbzUkk2MwAg5uOW3wQ7Gl88dDzEKcDAq8fDm8LBHC7EmlhVX5h5ilOBg VhLh7f7FFi3Em5JYWZValB9fVJqTWnyIUZqDRUmc18Jvc5SQQHpiSWp2ampBahFMlomDU6qB MddQ0vjWOo/keLVHin2fxTbMPPTKpe2BU/Jfm6hLWgp2F9iiG/y+Sk6V3PdTmseBj/uiiuzk QIO92/dqdy0yXqIr87e5r+LsmuQ78zW8C39+lzHZYWyv/+XLUaG7Uuyc4nEnTsivfsCxZxd3 G8c76Xdvs57+mSmSLHs1kHXpyiUz/sU9ZxZepsRSnJFoqMVcVJwIAELHVrqMAgAA Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch: Questions on SDP identity attribute 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: Thu, 24 May 2018 19:49:18 -0000 SGksDQoNCj4gWW91IGFyZSByaWdodCBDaHJpc3RlciwgSSB3YXMgbG9va2luZyBhdCB0aGlzIHRo ZSB3cm9uZyB3YXkgb2YgaG93IGl0IHdhcyB1c2VkIHZzIHRoZSBkZWZuLiBvZiBJZGVudGl0eS4g DQo+IExldCBtZSBhbnN3ZXIgdGhlIHF1ZXN0aW9ucyBmcm9tIG9ubHkgdGhlIHBvaW50IG9mIHZp ZXcgaG93IHRoZSBJZGVudGl0eSBoZWFkZXIgaXMgZGVmaW5lZCBieSANCj4gZHJhZnQtaWV0Zi1y dGN3ZWItc2VjdXJpdHktYXJjaCBhbmQgbm90IGhvdyB0aGUgaWRlbnRpdHkgaGVhZGVyIGlzIHVz ZWQgaW4gV2ViUlRDIGluIGdlbmVyYWwuIA0KPiANCj4+IFExOg0KPj4gLS0tLQ0KPj4gIA0KPj4g VGhlIGRyYWZ0IHNheXMgdGhhdCwgYXQgbWluaW11bSwgdGhlIGZpbmdlcnByaW50IG5lZWRzIHRv IGJlIGJvdW5kIHRvIHRoZSBpZGVudGl0eS4NCj4+ICANCj4+IERvZXMgdGhpcyBtZWFuIHRoYXQs IGluIG9yZGVyIHRvIGluY2x1ZGUgYW4gU0RQIGlkZW50aXR5IGF0dHJpYnV0ZSBpbiBhbiBvZmZl ci9hbnN3ZXIsIHRoZSBvZmZlci9hbnN3ZXIgTVVTVCANCj4+IGFsc28gY29udGFpbiBhdCBsZWFz dCBvbmUgU0RQIGZpbmdlcnByaW50IGF0dHJpYnV0ZT8gQmFzZWQgb24gdGhlIHRleHQgYWJvdXQg Z2VuZXJhdGluZyB0aGUgaWRlbnRpdHkgaXQgc2VlbXMgDQo+PiBsaWtlIHRoYXQsIGJ1dCBpdCBp cyBub3QgdmVyeSBjbGVhciBpbiB0aGUgU0RQIHByb2NlZHVyZXMuDQo+ICANCj4gSXQgc2VlbXMg dG8gbWUgdGhhdCB0aGUgZGVmbiBvZiBhbiBJZGVudGl0eSBoZWFkZXIgZG9lcyBub3QgbmVlZCBp dCB0byBiZSB1c2UgZm9yIGZpbmdlcnByaW50cyBhdCBhbGwuIFdoYXQgZ29lcyBpbiBpdCB0aGUg DQo+IGFzc2VydGlvbiBpcyBwcmV0dHkgbXVjaCBkZXRlcm1pbmVkIGJ5IHRoZSBJZFAuIFNvbWUg ZnV0dXJlIHN5c3RlbSB0aGF0IGRpZCBub3QgaGF2ZSBmaW5nZXJwcmludHMgYnV0IHVzZWQgdG9r ZW4gYmluZGluZyANCj4gb3IgYmxvY2tjaGFpbiBzdHlsZSBzbWFydCBjb250cmFjdHMgY291bGQg cHJvYmFibHkgd29yayBqdXN0IGZpbmUuIEl04oCZcyB1cCB0byB0aGUgSWRQLiANCj4NCj4gU28g SSBtaWdodCBiZSB3cm9uZyBidXQgSSB3b3VsZCBzYXkgdGhhdCBJZGVudGl0eSBoZWFkZXIgZG9l cyBub3QgcmVxdWlyZSBhIGZpbmdlcnByaW50IHRvIGJlIGluIHRoZSBTRFAsIGJ1dCB3aGVuIElk ZW50aXR5IA0KPiBpcyB1c2VkIGluIFdlYlJUQywgdGhlcmUgd2lsbCBhbHNvIGJlIGEgZmluZ2Vy cHJpbnQuIA0KDQpCdXQsIHRoZSB0ZXh0IHNheXMgdGhhdCwgYXQgYSBtaW5pbXVtLCB0aGUgZmlu Z2VycHJpbnQgbmVlZHMgdG8gYmUgYm91bmQgdG8gdGhlIGlkZW50aXR5Lg0KDQpJZiB0aGF0IGlz IG5vdCB0cnVlLCB0aGF0IHN0YXRlbWVudCBuZWVkcyB0byBiZSByZW1vdmVkL21vZGlmaWVkLiBJ ZiBpdCBkb2VzIGFwcGx5IHRvIFdlYlJUQywgaXQgbmVlZHMgdG8gYmUgY2xlYXIgdGhhdCBpdCBp cyBhIFdlYlJUQyByZXF1aXJlbWVudCwgbm90IGEgZ2VuZXJpYyBhdHRyaWJ1dGUgcmVxdWlyZW1l bnQuDQoNCi0tLQ0KDQo+PiBRMjoNCj4+IC0tLS0NCj4+ICANCj4+IFNlY3Rpb24gNS42LjQuMSBz YXlzOg0KPj4gICAgIlRoZSAiYT1pZGVudGl0eSIgYXR0cmlidXRlIE1VU1QgaW5jbHVkZSBhbGwN Cj4+ICAgIGZpbmdlcnByaW50IHZhbHVlcyB0aGF0IGFyZSBpbmNsdWRlZCBpbiAiYT1maW5nZXJw cmludCIgbGluZXMuIg0KPj4gIA0KPj4gRmlyc3QsIHJlbGF0ZWQgdG8gdGhlIGdlbmVyYXRpb24g b2YgdGhlIGFzc2VydGlvbiB2YWx1ZSwgaXQgaXMgdW5jbGVhciBob3cgdGhpcyBpcyBpbXBsZW1l bnRlZC4gRm9yIGV4YW1wbGUsIGlzIA0KPj4gdGhlcmUgYSBzZXBhcmF0ZSBKU09OIG9iamVjdCAo c2VjdGlvbiA1LjYuNCkgcHJvdmlkZWQgdG8gdGhlIElkUCBmb3IgZWFjaCBmaW5nZXJwcmludD8g VGhlIHRleHQgdGFsa3MgYWJvdXQg4oCcc2luZ2xl4oCdIA0KPj4gZmluZ2VycHJpbnQgaW4gdGhl IG9iamVjdC4gT3IsIGFyZSBhbGwgZmluZ2VycHJpbnRzIGluY2x1ZGVkIGluIHRoZSBzYW1lIEpT T04gb2JqZWN0Pw0KPiAgDQo+IEFzIHlvdSBwb2ludCBvdXQsIGFsbCB0aGF0IGlzIHRoZSBJZGVu dGl0eSBhc3NlcnRpb24gZGVmaW5pdGlvbiBkZWZpbmVzIGlzIGhvdyB0byBlbmNvZGUgaXQgYW5k IHRoYXTigJlzIGJhc2UgNjQgb2YgSlNPTiANCj4gc28gdGhhdCBwYXJ0IGlzIGZpbmUuIFNlY3Rp b24gNS42LjQuMSBpcyBhYm91dCBob3cgaXQgSWRlbnRpdHkgaXMgdXNlZCBpbiB0aGUgY29udGFj dCBvZiBXZWJSVEMuIEhvdyB0aGUgSWRQIGRvZXMgdGhpcyBpcyANCj4gcHJldHR5IG91dCBvZiBz Y29wZSBvZiBJRVRGIHN0dWZmIGJ1dCBJIHRoaW5rIHlvdSByYWlzZSBhIGdvb2QgcG9pbnQgdGhh dCB0aGlzIGltcGxpZXMgdGhhdCBpbiB0aGUgV2ViUlRDIGNhc2UsIGlmIHRoZXJlIA0KDQpNeSBx dWVzdGlvbiB3YXMgd2hldGhlciBlYWNoIGFzc2VydGlvbiB3aWxsIGJlIGluIGEgc2VwYXJhdGUg SlNPTi4gQnV0LCB3aGVuIHJlLXJlYWRpbmcgdGhlIGRyYWZ0IEkgdGhpbmsgSSBmb3VuZCB0aGUg YW5zd2VyLiBUaGUgQUJORiBjYW4gY29udGFpbiBtdWx0aXBsZSBhc3NlcnRpb25zLCBhbmQgdGhl cmUgaXMgdGV4dCBzYXlpbmcgdGhhdCBlYWNoIGFzc2VydGlvbiBpcyBhIEpTT04uDQoNCj4+IFNl Y29uZCwgaXQgaXMgdW5jbGVhciB3aGF0IOKAnGF0dHJpYnV0ZSBNVVNUIGluY2x1ZGUgYWxsIGZp bmdlcnByaW50IHZhbHVlc+KAnSBtZWFucy4gSSBhc3N1bWUgdGhhdCB0aGUgYXR0cmlidXRlIHdp bGwgb25seSANCj4+IGluY2x1ZGUgYSBzaW5nbGUgYXR0cmlidXRlIGFzc2VydGlvbiB2YWx1ZSwg YnV0IHRoYXQgdGhlIHZhbHVlIHdpbGwgYmUgZ2VuZXJhdGVkIGJ5IHRoZSBJZFAgYmFzZWQgb24g YWxsIGZpbmdlcnByaW50IHZhbHVlcz8NCg0KLS0tDQoNCj4+IFEzOiANCj4+IC0tLS0NCj4+ICAN Cj4+IEluIHRoZSBleGFtcGxlIGluIFNlY3Rpb24gNS42LjQuMSB0aGUgU0RQIGZpbmdlcnByaW50 IGF0dHJpYnV0ZSBpcyBpbmNsdWRlZCBhcyBhIHNlc3Npb24tbGV2ZWwgYXR0cmlidXRlLiBIb3dl dmVyLCBpdCANCj4+IGlzIGEgbWVkaWEtbGV2ZWwgYXR0cmlidXRlLiBBRkFJUiwgbWVkaWEtbGV2 ZWwgYXR0cmlidXRlcyBjYW5ub3QgYmUgaW5jbHVkZWQgYXMgc2Vzc2lvbi1sZXZlbCBhdHRyaWJ1 dGVzLg0KPiAgIA0KPiBTZWN0aW9uIDggb2YgUkZDNDU3MiB0aGF0IGRlZmluZXMgdGhlIGZpbmdl cnByaW50IGF0dHJpYnV0ZSBzYXlzIHRoYXQgaXQgaXMgYm90aCBhdCBzZXNzaW9uIGFuZCBtZWRp YS1sZXZlbCBhdHRyaWJ1dGUuIA0KPiAoMm5kIHBhcmEgb2YgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzQ1NzIjc2VjdGlvbi04ICkgDQoNClllcywgYnV0IHRoaXMgZHJhZnQgZGVmaW5l cyB0aGUgSWRlbnRpdHkgYXR0cmlidXRlIDopDQoNCkp1c3QgYmVjYXVzZSB0aGUgSWRlbnRpdHkg YXR0cmlidXRlIGNhbiBiZSB1c2VkIHRvZ2V0aGVyIHdpdGggdGhlIEZpbmdlcnByaW50IGF0dHJp YnV0ZSBpdCBkb2Vzbid0IG1lYW4gdGhhdCBpdCBhdXRvbWF0aWNhbGx5IGluaGVyaXRzIHRoZSBw cm9wZXJ0aWVzIG9mIHRoZSBGaW5nZXJwcmludCBhdHRyaWJ1dGUgLSBlc3BlY2lhbGx5IHNpbmNl IHlvdSBlYXJsaWVyIGluZGljYXRlZCB0aGF0IHRoZXJlIG1heSBiZSBjYXNlcyB3aGVyZSB0aGUg ZmluZ2VycHJpbnQgaXNuJ3QgZXZlbiB1c2VkIGZvciB0aGUgYXNzZXJ0aW9uLiBUaGUgZGVmaW5p dGlvbiBvZiB0aGUgSWRlbnRpdHkgYXR0cmlidXRlIG5lZWRzIHRvIHN0YXRlIHdoZXRoZXIgaXQg Y2FuIGJlIHVzZWQgb24gc2Vzc2lvbiBhbmQvb3IgbWVkaWEtbGV2ZWwuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg== From nobody Wed May 30 06:18:36 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 B6B68124319; Wed, 30 May 2018 06:18:32 -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, sean@sn3rd.com, rtcweb-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2018 06:18:32 -0700 Archived-At: Subject: [rtcweb] rtcweb - Not having a session at IETF 102 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 30 May 2018 13:18:33 -0000 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. From nobody Thu May 31 01:12: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 DAB8212D86F for ; Thu, 31 May 2018 01:12:00 -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 Fzw8-u-8uxbz for ; Thu, 31 May 2018 01:11:59 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9702126DEE for ; Thu, 31 May 2018 01:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527754317; 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=IQIKf4H3+F611jIbj8wtWF0yG3ajYuRPZgTKBy9Kv2Q=; b=QOzc2rrJB/AQyVg1fyEDQyLJM88dV36LQJ+Z7sAXdrvbxavIQ/0imKw/g50MoItD l1ZTuFKnq8RRhumqn2f3dxXLvyYk2z11S5VwIudgw2tfVRPtCyArPYJNXe6PUoGC wraKwcLAheVXeA3FfPTbVlvu4rSk3IqFXXjJ21nDe0Q=; X-AuditID: c1b4fb30-36b839c0000002c8-e4-5b0fae4df863 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.1E.00712.D4EAF0B5; Thu, 31 May 2018 10:11:57 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSHC020.ericsson.se (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 10:11:25 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 31 May 2018 10:11:24 +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, 31 May 2018 10:11:24 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" CC: "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] rtcweb - Not having a session at IETF 102 Thread-Index: AQHT+BpFMR1PpqciJ0m6GiSkkXrIhqRJj6OA Date: Thu, 31 May 2018 08:11:24 +0000 Message-ID: References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> In-Reply-To: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="us-ascii" Content-ID: <103304C7079E02409E0CE7D3B73E9106@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2K7n67vOv5ogwn/eS163t5gsVj7r53d gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZva/WMhYcZKv4+fo/UwPjatYuRk4OCQETiX8P29m7 GLk4hASOMEocaL7PCuFsYZS4ObWNCcL5xihxsmU/I4SzjFHi2vy9QA4HB5uAhUT3P22QUSIC 6hKXH15gBwkzC5hKzLgfDBIWFrCX+LamhxmixEHi2NqlLBC2kcT9zm2MIDaLgKrE8zv3wOK8 AtYSFy9PBrtOSMBP4mNDD9gmTgF/ia//rEDCjAJiEt9PrWECsZkFxCVuPZnPBPGMgMSSPeeZ IWxRiZeP/4GNERXQk9hw4jY7RFxJYkvvFqheHYkFuz+xQdjWEu87DjJC2NoSyxa+ZoY4R1Di 5MwnLBDnaEu0LJ7APoFRahaS1bOQjJqFZNQsJKNmIRm1gJF1FaNocWpxUm66kZFealFmcnFx fp5eXmrJJkZgtB7c8ttgB+PL546HGAU4GJV4eIuX8UcLsSaWFVfmHmKU4GBWEuGdUgYU4k1J rKxKLcqPLyrNSS0+xCjNwaIkzmvhtzlKSCA9sSQ1OzW1ILUIJsvEwSnVwNh8oeXC+vQU7Y3R R2JSuF+4hvF1eM8WYXiU1x17cvY/do6jWwu03tyZOYtDb27dule9fArHG5wO/St5z/qH7Wj/ rRX+Xyed+2YtqMQ40fXppRCXj6fTV2kttrpi4O732X97A8POoIyF8V2X576LPHyyXX6ZcVjw Mz+rSMUd7vGeb7qOG1VufajEUpyRaKjFXFScCADP1rBB0gIAAA== Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 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: Thu, 31 May 2018 08:12:01 -0000 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 From nobody Thu May 31 06: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 0DB3312EC57; Thu, 31 May 2018 06:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.599, 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=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olJS85NHcEFd; Thu, 31 May 2018 06:40:52 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.198]) (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 E25AB12F2AB; Thu, 31 May 2018 06:40:51 -0700 (PDT) Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-8.messagelabs.com id BF/BD-28268-36BFF0B5; Thu, 31 May 2018 13:40:51 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjH9+6cHU/i6nVqe5LsspLCmmihqV3 UT0kRBhl0EfIsT260i+ysmvZBofIytcyKbKmzsgXWKEupLLvYummIiqYUUS4hKg3Nwrwk7exM q2+/5/n/+b/P8/LQhKyTCqZZs4k16hmtgvIlexc1+CtVE3N2R5w9CjHt556gmOLBXjLGMZXvk 0Akjf/sppJqasbEW8W7JBq9ymBOk6jzBholmUcSzZa8T0QuerHBgnxpEhcT4KwakfCFDJ8Qw8 ilQiQU7xC0llaRFjSLpnAEvG56LuY5EKdCT90NHwuiaQJHQfn7bXw7AMeDs3KIFCwJ8MxxmeQ tgTgOyit8+TaJQ+Gi84PHInWn/H5nl/AswzkwfPIUwfMsvA7yhyo9HoTnwmjLNc+rBJbDm36b hwEHQl9HKyVwEHz+OCUR/KlQOdLs7Svg1dtcUuAQ6LQVedYCXC+G1sEur0kJQ2fOEAI/QjDcI Rc4DK7Zq7ye/dD7cIyY7hc4rd4hFkBtSR8phDYRcN1SgARhPjS0XaIEoYSCoe5bpLBmOpyubf YKHxHcnSijStEK6z/rWd0agW0IHCfaJVbPP/nDy3P9pGBSQuODR4TAC+H2YIWX10L5+GNK4MV wuqjPR+Ao+Pp0GFUjuhYt51jjQdaojIwOVxk1GWqTjtFolZERMeE6luOYDFbLqLjwvQbdTeS+ rxyRCN1Bpfc2NqN5tFgRJP3WNme3bLbKkJ6lZjj1HuMBLcs1o/k0rQBp9rhb8zeyGax5n0brP tJpGWg/RaA0a8wtS7lMRsdpMgSpBSnpyfqyYkJG6g16Nlgu3cJnYN6kPqCfiZg+9U4UEhwgRS KRSOaXyRp1GtP/+hckp5EiQJrDp/hp9KaZl764hxC7hyjI8wxhYv5KwbmIPLT0amxyfe6xsi3 k5PqGlmObF6rOJ0F2rMF1y8aJ0lzLAkZ70rcfvGKY2ORrb4RPURdSCiHHdtgeNzd+wxr2e2LB cVfyj9V+Nnvdr/bulY2fx9f27t+088qSppMDKW1d0avw2P2yNife0b+jIkzuKkqodlkd8ZWx+ aHPrxclJSpITs1EhhFGjvkDcNnzduUDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-10.tower-220.messagelabs.com!1527774049!197890431!1 X-Originating-IP: [216.32.181.17] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32104 invoked from network); 31 May 2018 13:40:50 -0000 Received: from mail-co1nam03lp0017.outbound.protection.outlook.com (HELO NAM03-CO1-obe.outbound.protection.outlook.com) (216.32.181.17) by server-10.tower-220.messagelabs.com with AES256-SHA256 encrypted SMTP; 31 May 2018 13:40:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7ttye3kCnP5dxRzMaomXoJUWEIB59eHcVszMptP3ja8=; b=YL+MkzwPpYWp5gds8A4w6P/xFQE3Wlqi/XYoaoBJ+XqGqzOM8zeQtQxasDHPtJfpmR+JWJs6JdvE3Ec0rE0OZvOwRokHpMmMby5O3bcFX6MvcAvp913dpffDvmb3HVIVbcWmAw91YJN4NuEDNURjsoATGXCQ51UOslkAEHDp3Yo= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1396.namprd14.prod.outlook.com (10.172.150.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.11; Thu, 31 May 2018 13:40:47 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::4dfb:25a:be82:3618]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::4dfb:25a:be82:3618%3]) with mapi id 15.20.0820.010; Thu, 31 May 2018 13:40:47 +0000 From: Tim Hollebeek To: Christer Holmberg , "rtcweb@ietf.org" CC: "rtcweb-chairs@ietf.org" Thread-Topic: [rtcweb] rtcweb - Not having a session at IETF 102 Thread-Index: AQHT+Bi955vJ8JyMWkyn1RMHvtdmMaRJfb0AgABc91A= Date: Thu, 31 May 2018 13:40:47 +0000 Message-ID: References: <152768631266.27594.10418369950986413860.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.71.184.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1396; 7:uG//ShkDVmkQICtDofHrje5jXVFkpILg16v+OyfQRgquEIPEYfO6GNCdcq+LbuyP45D5kvwRaVAr+nHx3+pbrojzb3XeW0L6Wa0cf8T0OB5PeWrVQBFtnCjhXTl1vJSaBDSgkHqOtXXtIkWjXq0y+zAVsIAFxgTDAoxPfcuV1P0q8iE648Q2vz/VTZWxYqquxbYJwo3ryeBLzGvPp49EcNE58fECPJOIGHMwkmxGRAeHHwGd1pYzBsccmkafsNwZ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1396; x-ms-traffictypediagnostic: BN6PR14MB1396: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1396; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1396; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(366004)(39860400002)(376002)(346002)(189003)(199004)(13464003)(966005)(76176011)(5250100002)(7696005)(44832011)(97736004)(6436002)(14454004)(478600001)(229853002)(5660300001)(4326008)(53546011)(2501003)(6506007)(110136005)(476003)(59450400001)(99286004)(102836004)(486006)(3660700001)(86362001)(11346002)(446003)(2906002)(186003)(316002)(26005)(3280700002)(9686003)(6116002)(3846002)(6306002)(55016002)(33656002)(53936002)(6246003)(25786009)(105586002)(106356001)(68736007)(99936001)(7736002)(81166006)(66066001)(81156014)(8676002)(8936002)(2900100001)(305945005)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1396; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: b1mvCLuYJSw2XlcuhhQ31IAZyxtwOEC/k8iXWVp6MvtV5NOhSXZKt/xiA3V6Pfh9naH/d3TqCpO8zd3N/hgl29zPEXwMw1IhbliRJ6MGykJkCYmhPzPCCt3ElonCc+dhPHUQ6I7TJmRCYEeS8deJPKYl0+m719RDqIh0929Bs+syLWFyYxqqAteTb0pNWNy6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0723_01D3F8C3.F0802F00" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: bd2f94d8-2443-4bbe-8e49-08d5c6fc1dbb X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd2f94d8-2443-4bbe-8e49-08d5c6fc1dbb X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 13:40:47.4432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1396 Archived-At: Subject: Re: [rtcweb] rtcweb - Not having a session at IETF 102 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: Thu, 31 May 2018 13:41:02 -0000 ------=_NextPart_000_0723_01D3F8C3.F0802F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0723_01D3F8C3.F0802F00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNTMxMTM0NDE2WjAvBgkqhkiG9w0BCQQxIgQghd7Mt87zY1KtZKf0GlFiM/Xs24KJ RfHWh2dKKD7EocEwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMaXGHe3L1rEpaG7iUX5sd6cPoC1KOi0uE1y6lm+AEwYhl7XPZkfZulStzoDnC6ucl7oH9Mf gsHheIlLOz2jGCpAe7UC6xodluJAeRWhLBkjPkQxtz2R3Eu9X1tEbHV53DJIoC9R1lGaRd0Tg8KF PAARwoLVV+8NmK8Yu3AWsl5wvXPRehqUwL+Q2dswOOrsnHoHuG1lIATMuVDScOfZgJhGkctqDVvg uCq9VZ94yLokngdecQOAaCyvXd2jHcUWgKg20DdyiHiv8iotP5nOEDfQ6drYyOs+u4g3N0EDyQ9U zXrRLRRemv34HDID+xCgyejkPaiEaYmVGhP/vkOuOU8AAAAAAAA= ------=_NextPart_000_0723_01D3F8C3.F0802F00-- From nobody Thu May 31 11:24:32 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 9772312EA55 for ; Thu, 31 May 2018 11:24:30 -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 kzVPijFMFTUU for ; Thu, 31 May 2018 11:24:27 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 B247012EB67 for ; Thu, 31 May 2018 11:24:27 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id i2-v6so15654113uah.0 for ; Thu, 31 May 2018 11:24: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=5h0uf1/Jt0w1Q00AsARw3vKCBCItevCs2yY073aTWYU=; b=SriZVjS5QU7SeEmyWVuI8Yu38J9uO9I+JijMT0pggNNtSdLXWn+4HX5UQ/K06r9p8T 9eJa+QXvf9DPfpolFZWmxabn+VogcK3g093h3fHAw0s9cLjsmXZYzKo93ITPVja+L7a2 KjRst/rjQe8FHgStEJdD5jND38h5w8SAQ2nerljfcDQhEMjlv65eVeH8eGGKn+KMnlC+ /qS3dKi0XrZV0KQF8PAyPqzrJT8vjsOmKvLPTYv7/ujH1RKpLktaNMsBaZriJ9jLurVw TpCunh5qehWOerw639IuvNSWOHgCoR4dV2fT80XLcFpOz9YF/xIDtni0zyagEwNZCTr9 BmEA== 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=5h0uf1/Jt0w1Q00AsARw3vKCBCItevCs2yY073aTWYU=; b=fMVoVIyY4UnFUeEISNJtuKerFTSn7Q7kYHKSEYMdYd2JSRB2M7dS/yBKjVItHqD0e/ sK2pPyb1tlw/42AmW2PjqP4yMzZa6hh4iLSGQqR3fSwe4XII2bzv0GZXeqIddLFVsoj+ 8kDodXcqb22fTcTVh4Z2cujC9LSQ/iL7n3bJLq9/IblituemwG+FII1anaJRoubRIDcD GMX/veaQWhCQjn/2dDxReycthIS8irC9AR0Pt8e5Ng8xImmrWFUy5r/YCLeKkOo/Jhm2 +xfDvj8eC222GjbxAvC61P0yLP0d4/h552jmaVY55oTfkcT7QwgxINsnP7QhhRJ4qZtF e0Cw== X-Gm-Message-State: ALKqPwdd4LdznGvEGM9IFPTsMlWTrFOj6mFa8UoWmLB3mfVazMJrTR6S hr6Dy9/IizGGJg8aEj+F5ims03POrrk8nJ6P5znifkQVckM= X-Google-Smtp-Source: ADUXVKKAioj5fmzrnk55wGDaobN7rvOvjuu+WkZSlmxO66b3VsPgFBoIQYmB/x3EDUrHrRHjcc5haDZjVWYy9EUAYgE= X-Received: by 2002:a9f:3d6b:: with SMTP id m43-v6mr4943451uai.129.1527791065890; Thu, 31 May 2018 11:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Thu, 31 May 2018 11:24:25 -0700 (PDT) From: Taylor Brandstetter Date: Thu, 31 May 2018 11:24:25 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c6882b056d849356" 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.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: Thu, 31 May 2018 18:24:31 -0000 --000000000000c6882b056d849356 Content-Type: text/plain; charset="UTF-8" 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. Corresponding webrtc-pc issue: https://github.com/w3c/webrtc-pc/issues/1879 --000000000000c6882b056d849356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One might expect that a "reliable" dat= a channel is guaranteed to be, well, reliable. But in current implementatio= ns, the first messages may be lost if the application is negotiating the ch= annels out-of-band, and creates the receiving channel too late.
<= br>
Here's a fiddle that demonstrates this (happens with Chro= me and Firefox): https://jsfiddl= e.net/o2m8tp20/

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

But if for whatever reason, an applicatio= n creates a data channel *after* the SCTP association is established, then = it will instantly be "open" as soon as it's created. If a mes= sage 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? S= ome possibilities:
  1. Say "this is expected behav= ior" and document it better, breaking the reliability promise.
    2. Run the closing procedure if a message is received on a stream before a da= ta channel is ready to receive it.
  2. Don't even allow an out-of-b= and negotiated channel to be created after the SCTP association is establis= hed.
  3. 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 addit= ional buffering logic seems like overkill if this isn't a use case we r= eally intended to support.

Corresponding webrtc-p= c issue:=C2=A0http= s://github.com/w3c/webrtc-pc/issues/1879
--000000000000c6882b056d849356-- From nobody Thu May 31 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 4502812EAD0 for ; Thu, 31 May 2018 11:38:28 -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 (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 BsMLKDLYxQlr for ; Thu, 31 May 2018 11:38:25 -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 9845A12D886 for ; Thu, 31 May 2018 11:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527791902; 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=043wNSv1mLG3ajLTrusdJg0NPqdFa5IrfORGqH8Ppvs=; b=KlixXlsGHsyvydqn6llfy822WQtDqBV57vFsIN32beoCAcMxbaaVlzkuej1/zPib i9QgVE8VqX6jjFCWdSmd22bPRsYlTGC/3JDCoWNy7aHu1ABJzXXhfaQZk3kqPCfO z73BL5LHqKDKqxNGM/hInqMZgUqR2o3C7h9bpQdznM8=; X-AuditID: c1b4fb2d-c61ff700000028db-df-5b10411e7472 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.22.10459.E11401B5; Thu, 31 May 2018 20:38:22 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSHC024.ericsson.se (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 31 May 2018 20:38:22 +0200 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 31 May 2018 20:38:22 +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, 31 May 2018 20:38:22 +0200 From: Christer Holmberg To: Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels Thread-Index: AQHT+QykkBgeKHb7x06HnWNksweot6RKKQ9g Date: Thu, 31 May 2018 18:38:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/alternative; boundary="_000_c2aec186b055485c8705cfb24be6f70eericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2J7lK6co0C0weOFxhaPLvtYrP3Xzu7A 5HFi2RVWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZcy7wl/QNZGx4sit10wNjDN6GbsYOTkkBEwk 9rYdZe9i5OIQEjjCKDFl2RtGCGcLo8Tuz33MEM43RomrK6dCOcsYJZb97WTrYuTgYBOwkOj+ pw0ySkQgXuLIz5VsILawQIHEwqX9LBDxQolz1yHWiQgYSTy61cIEYrMIqEpsbtjACmLzClhL TJp1DaxGSCBA4uLEncwg4zkFAiV2taqAhBkFxCS+n1oD1sosIC5x68l8JogPBCSW7DnPDGGL Srx8/I8VwlaS2HvsOgtEfbLEwQOnGSFWCUqcnPmEBWKVtkTL4gnsExjFZiEZOwtJyywkLbOA LmIW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjEC4/Dglt+6OxhXv3Y8xCjAwajEwzvLXCBaiDWxrLgy9xCjBAezkgjvlDL+aCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8eqv2RAkJpCeWpGanphakFsFkmTg4pRoYY3XfWO1qPn/b6XjJVCmT X4Z2+xZ/3vZHpUn5zxeHvlUcFa4Oh7a7aswpbThy8fGOaY+rzvrv1H93/PuWeXmzFz9ibJij 7Wd8R6OutWHxBW1ZjeXdSlq5Qv2/v9yc9uI194JDMSpfDXZnr+eS1rcXEd1YNI/xg/SGrnnu jmZHtKZMlV243kRKQImlOCPRUIu5qDgRAPS1/Cy/AgAA 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.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: Thu, 31 May 2018 18:38:29 -0000 --_000_c2aec186b055485c8705cfb24be6f70eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHRoZSBkYXRhIGNoYW5uZWwgaXMgcmVhbGl6ZWQgYXMgYW4gU0NUUCBzdHJlYW0s IGl0IHNvdW5kcyB2ZXJ5IHdlaXJkIHRoYXQgb25lIHdvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIG5l Z290aWF0ZSBhIGRhdGEgY2hhbm5lbCBhZnRlciB0aGUgU0NUUCBhc3NvY2lhdGlvbiBoYXMgYmVl biBlc3RhYmxpc2hlZOKApg0KDQpCdXQsIGlmIGEgZGF0YSBjaGFubmVsIGlzIGVzdGFibGlzaGVk IG91dC1vZi1iYW5kLCBzaG91bGRu4oCZdCB0aGUgYXNzb2NpYXRlZCBvZmZlci9hbnN3ZXIgdHJh bnNhY3Rpb24gY29tcGxldGUgYmVmb3JlIHRoZSBkYXRhIGNoYW5uZWwgaXMgdXNlZD8NCg0KU2Vj dGlvbiA2LjUgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBzYXlzOg0K DQogICAgICDigJxFYWNoIGFnZW50IGFwcGxpY2F0aW9uIE1VU1Qgd2FpdCB0byBzZW5kIGRhdGEg dW50aWwgaXQgaGFzDQogICAgICAgIGNvbmZpcm1hdGlvbiB0aGF0IHRoZSBkYXRhIGNoYW5uZWwg YXQgdGhlIHBlZXIgaXMgaW5zdGFudGlhdGVkLuKAnQ0KDQpJbiBhZGRpdGlvbiwgdGhlIHNlY3Rp b24gZGVzY3JpYmVzIHdoZW4gdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIGNhbiBjb25zaWRlciB0 aGF0IHRoZSBkYXRhIGNoYW5uZWwgaGFzIGJlZW4gaW5zdGFudGlhdGVkIGF0IHRoZSBwZWVyLg0K DQpTbywgaW4gbXkgb3BpbmlvbiBhbnkgZGF0YSB0aGF0IGlzIHNlbnQgYmVmb3JlIHRoYXQgY291 bGQgc2ltcGx5IGJlIGRyb3BwZWQsIHdoaWNoIEkgZ3Vlc3Mgd291bGQgYmUgYWx0ZXJuYXRpdmUg NSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3 ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRheWxvciBCcmFuZHN0ZXR0ZXINClNl bnQ6IDMxIE1heSAyMDE4IDIwOjI0DQpUbzogUlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9yZz4N ClN1YmplY3Q6IFtydGN3ZWJdIFBvc3NpYmxlIHRvIGxvc2UgaW5pdGlhbCBtZXNzYWdlcyBzZW50 IGJ5IHJlbGlhYmxlLCBvdXQtb2YtYmFuZCBuZWdvdGlhdGVkIGRhdGEgY2hhbm5lbHMNCg0KT25l IG1pZ2h0IGV4cGVjdCB0aGF0IGEgInJlbGlhYmxlIiBkYXRhIGNoYW5uZWwgaXMgZ3VhcmFudGVl ZCB0byBiZSwgd2VsbCwgcmVsaWFibGUuIEJ1dCBpbiBjdXJyZW50IGltcGxlbWVudGF0aW9ucywg dGhlIGZpcnN0IG1lc3NhZ2VzIG1heSBiZSBsb3N0IGlmIHRoZSBhcHBsaWNhdGlvbiBpcyBuZWdv dGlhdGluZyB0aGUgY2hhbm5lbHMgb3V0LW9mLWJhbmQsIGFuZCBjcmVhdGVzIHRoZSByZWNlaXZp bmcgY2hhbm5lbCB0b28gbGF0ZS4NCg0KSGVyZSdzIGEgZmlkZGxlIHRoYXQgZGVtb25zdHJhdGVz IHRoaXMgKGhhcHBlbnMgd2l0aCBDaHJvbWUgYW5kIEZpcmVmb3gpOiBodHRwczovL2pzZmlkZGxl Lm5ldC9vMm04dHAyMC8NCg0KTm9ybWFsbHkgdGhpcyBpc24ndCBhbiBpc3N1ZSwgYmVjYXVzZSBh IHR5cGljYWwgYXBwbGljYXRpb24gd291bGQgY3JlYXRlIHRoZSBvdXQtb2YtYmFuZCBuZWdvdGlh dGVkIGNoYW5uZWxzIGJlZm9yZSB0aGUgZmlyc3Qgb2ZmZXIvYW5zd2VyIGlzIGNvbXBsZXRlLCBh bmQgdGh1cyBiZWZvcmUgdGhlIFNDVFAgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQuIE1lYW5p bmcgdGhhdCBieSB0aGUgdGltZSBhIGRhdGEgY2hhbm5lbCBpcyAib3BlbiIsIGl0J3MgZ3VhcmFu dGVlZCB0aGF0IHRoZSBvdGhlciBwZWVyIGhhcyBhIGNvcnJlc3BvbmRpbmcgY2hhbm5lbC4NCg0K QnV0IGlmIGZvciB3aGF0ZXZlciByZWFzb24sIGFuIGFwcGxpY2F0aW9uIGNyZWF0ZXMgYSBkYXRh IGNoYW5uZWwgKmFmdGVyKiB0aGUgU0NUUCBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZCwgdGhl biBpdCB3aWxsIGluc3RhbnRseSBiZSAib3BlbiIgYXMgc29vbiBhcyBpdCdzIGNyZWF0ZWQuIElm IGEgbWVzc2FnZSBpcyBzZW50IGF0IHRoaXMgcG9pbnQsIGFuZCBpdCdzIHJlY2VpdmVkIGJ5IHRo ZSBvdGhlciBwZWVyIGJlZm9yZSBpdCdzIGNyZWF0ZWQgaXRzIGNvcnJlc3BvbmRpbmcgZGF0YSBj aGFubmVsLCB0aGVuIHRoZSBtZXNzYWdlIHdpbGwganVzdCBiZSBkaXNjYXJkZWQuDQoNClNvLCBo b3cgc2hvdWxkIHdlIGRlYWwgd2l0aCB0aGlzPyBTb21lIHBvc3NpYmlsaXRpZXM6DQoNCiAgMS4g IFNheSAidGhpcyBpcyBleHBlY3RlZCBiZWhhdmlvciIgYW5kIGRvY3VtZW50IGl0IGJldHRlciwg YnJlYWtpbmcgdGhlIHJlbGlhYmlsaXR5IHByb21pc2UuDQogIDIuICBSdW4gdGhlIGNsb3Npbmcg cHJvY2VkdXJlIGlmIGEgbWVzc2FnZSBpcyByZWNlaXZlZCBvbiBhIHN0cmVhbSBiZWZvcmUgYSBk YXRhIGNoYW5uZWwgaXMgcmVhZHkgdG8gcmVjZWl2ZSBpdC4NCiAgMy4gIERvbid0IGV2ZW4gYWxs b3cgYW4gb3V0LW9mLWJhbmQgbmVnb3RpYXRlZCBjaGFubmVsIHRvIGJlIGNyZWF0ZWQgYWZ0ZXIg dGhlIFNDVFAgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQuDQogIDQuICBCdWZmZXIgdGhlc2Ug bWVzc2FnZXMgZm9yIHVwIHRvIFggc2Vjb25kcyAob3IgdXAgdG8gWCBieXRlcyksIHRvIGJlIGRl bGl2ZXJlZCB0byB0aGUgZGF0YSBjaGFubmVsIG9uY2UgaXQncyBjcmVhdGVkLiBSdW4gdGhlIGNs b3NpbmcgcHJvY2VkdXJlIGlmIFggaXMgZXhjZWVkZWQuDQpJJ2Qgdm90ZSBmb3IgIzIuIEFkZGlu ZyBhZGRpdGlvbmFsIGJ1ZmZlcmluZyBsb2dpYyBzZWVtcyBsaWtlIG92ZXJraWxsIGlmIHRoaXMg aXNuJ3QgYSB1c2UgY2FzZSB3ZSByZWFsbHkgaW50ZW5kZWQgdG8gc3VwcG9ydC4NCg0KQ29ycmVz cG9uZGluZyB3ZWJydGMtcGMgaXNzdWU6IGh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2VicnRjLXBj L2lzc3Vlcy8xODc5DQo= --_000_c2aec186b055485c8705cfb24be6f70eericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI0MDk5MjIyMDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMxNDY5NDU1ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkFzIHRoZSBkYXRhIGNoYW5uZWwgaXMgcmVhbGl6ZWQgYXMgYW4gU0NUUCBzdHJlYW0sIGl0IHNv dW5kcyB2ZXJ5IHdlaXJkIHRoYXQgb25lIHdvdWxkIG5vdCBiZSBhbGxvd2VkIHRvIG5lZ290aWF0 ZSBhIGRhdGEgY2hhbm5lbCBhZnRlcg0KIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGhhcyBiZWVuIGVz dGFibGlzaGVk4oCmIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QnV0 LCBpZiBhIGRhdGEgY2hhbm5lbCBpcyBlc3RhYmxpc2hlZCBvdXQtb2YtYmFuZCwgc2hvdWxkbuKA mXQgdGhlIGFzc29jaWF0ZWQgb2ZmZXIvYW5zd2VyIHRyYW5zYWN0aW9uIGNvbXBsZXRlIGJlZm9y ZSB0aGUgZGF0YSBjaGFubmVsDQogaXMgdXNlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlNlY3Rpb24gNi41IG9mIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5l bC1zZHBuZWcgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigJxFYWNoIGFnZW50IGFwcGxpY2F0aW9uIE1V U1Qgd2FpdCB0byBzZW5kIGRhdGEgdW50aWwgaXQgaGFzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtjb25maXJtYXRpb24gdGhhdCB0aGUgZGF0YSBjaGFubmVsIGF0IHRoZSBwZWVyIGlz IGluc3RhbnRpYXRlZC7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkluIGFkZGl0aW9uLCB0aGUgc2VjdGlvbiBkZXNjcmliZXMgd2hlbiB0aGUgb2ZmZXJlciBhbmQg YW5zd2VyZXIgY2FuIGNvbnNpZGVyIHRoYXQgdGhlIGRhdGEgY2hhbm5lbCBoYXMgYmVlbiBpbnN0 YW50aWF0ZWQgYXQgdGhlIHBlZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5TbywgaW4gbXkgb3BpbmlvbiBhbnkgZGF0YSB0aGF0IGlzIHNlbnQgYmVmb3JlIHRoYXQg Y291bGQgc2ltcGx5IGJlIGRyb3BwZWQsIHdoaWNoIEkgZ3Vlc3Mgd291bGQgYmUgYWx0ZXJuYXRp dmUgNSA6KQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv bXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNl c0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGF5bG9yIEJyYW5kc3RldHRlcjxicj4N CjxiPlNlbnQ6PC9iPiAzMSBNYXkgMjAxOCAyMDoyNDxicj4NCjxiPlRvOjwvYj4gUlRDV2ViIElF VEYgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3J0Y3dlYl0g UG9zc2libGUgdG8gbG9zZSBpbml0aWFsIG1lc3NhZ2VzIHNlbnQgYnkgcmVsaWFibGUsIG91dC1v Zi1iYW5kIG5lZ290aWF0ZWQgZGF0YSBjaGFubmVsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG1pZ2h0IGV4cGVjdCB0aGF0IGEgJnF1b3Q7 cmVsaWFibGUmcXVvdDsgZGF0YSBjaGFubmVsIGlzIGd1YXJhbnRlZWQgdG8gYmUsIHdlbGwsIHJl bGlhYmxlLiBCdXQgaW4gY3VycmVudCBpbXBsZW1lbnRhdGlvbnMsIHRoZSBmaXJzdCBtZXNzYWdl cyBtYXkgYmUgbG9zdCBpZiB0aGUgYXBwbGljYXRpb24gaXMgbmVnb3RpYXRpbmcgdGhlIGNoYW5u ZWxzIG91dC1vZi1iYW5kLCBhbmQgY3JlYXRlcyB0aGUgcmVjZWl2aW5nIGNoYW5uZWwNCiB0b28g bGF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGVyZSdzIGEgZmlkZGxlIHRoYXQgZGVtb25zdHJhdGVzIHRoaXMgKGhhcHBlbnMgd2l0aCBD aHJvbWUgYW5kIEZpcmVmb3gpOg0KPGEgaHJlZj0iaHR0cHM6Ly9qc2ZpZGRsZS5uZXQvbzJtOHRw MjAvIj5odHRwczovL2pzZmlkZGxlLm5ldC9vMm04dHAyMC88L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vcm1hbGx5IHRoaXMgaXNuJ3Qg YW4gaXNzdWUsIGJlY2F1c2UgYSB0eXBpY2FsIGFwcGxpY2F0aW9uIHdvdWxkIGNyZWF0ZSB0aGUg b3V0LW9mLWJhbmQgbmVnb3RpYXRlZCBjaGFubmVscyBiZWZvcmUgdGhlIGZpcnN0IG9mZmVyL2Fu c3dlciBpcyBjb21wbGV0ZSwgYW5kIHRodXMgYmVmb3JlIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGlz IGVzdGFibGlzaGVkLiBNZWFuaW5nIHRoYXQgYnkgdGhlIHRpbWUgYSBkYXRhDQogY2hhbm5lbCBp cyAmcXVvdDtvcGVuJnF1b3Q7LCBpdCdzIGd1YXJhbnRlZWQgdGhhdCB0aGUgb3RoZXIgcGVlciBo YXMgYSBjb3JyZXNwb25kaW5nIGNoYW5uZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBpZiBmb3Igd2hhdGV2ZXIgcmVhc29uLCBhbiBh cHBsaWNhdGlvbiBjcmVhdGVzIGEgZGF0YSBjaGFubmVsICphZnRlciogdGhlIFNDVFAgYXNzb2Np YXRpb24gaXMgZXN0YWJsaXNoZWQsIHRoZW4gaXQgd2lsbCBpbnN0YW50bHkgYmUgJnF1b3Q7b3Bl biZxdW90OyBhcyBzb29uIGFzIGl0J3MgY3JlYXRlZC4gSWYgYSBtZXNzYWdlIGlzIHNlbnQgYXQg dGhpcyBwb2ludCwgYW5kIGl0J3MgcmVjZWl2ZWQgYnkgdGhlIG90aGVyDQogcGVlciBiZWZvcmUg aXQncyBjcmVhdGVkIGl0cyBjb3JyZXNwb25kaW5nIGRhdGEgY2hhbm5lbCwgdGhlbiB0aGUgbWVz c2FnZSB3aWxsIGp1c3QgYmUgZGlzY2FyZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgaG93IHNob3VsZCB3ZSBkZWFsIHdpdGggdGhp cz8gU29tZSBwb3NzaWJpbGl0aWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpTYXkgJnF1b3Q7dGhpcyBpcyBleHBlY3RlZCBiZWhhdmlv ciZxdW90OyBhbmQgZG9jdW1lbnQgaXQgYmV0dGVyLCBicmVha2luZyB0aGUgcmVsaWFiaWxpdHkg cHJvbWlzZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQpSdW4gdGhlIGNsb3NpbmcgcHJvY2VkdXJlIGlmIGEgbWVzc2FnZSBp cyByZWNlaXZlZCBvbiBhIHN0cmVhbSBiZWZvcmUgYSBkYXRhIGNoYW5uZWwgaXMgcmVhZHkgdG8g cmVjZWl2ZSBpdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQpEb24ndCBldmVuIGFsbG93IGFuIG91dC1vZi1iYW5kIG5lZ290 aWF0ZWQgY2hhbm5lbCB0byBiZSBjcmVhdGVkIGFmdGVyIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGlz IGVzdGFibGlzaGVkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCkJ1ZmZlciB0aGVzZSBtZXNzYWdlcyBmb3IgdXAgdG8gWCBz ZWNvbmRzIChvciB1cCB0byBYIGJ5dGVzKSwgdG8gYmUgZGVsaXZlcmVkIHRvIHRoZSBkYXRhIGNo YW5uZWwgb25jZSBpdCdzIGNyZWF0ZWQuIFJ1biB0aGUgY2xvc2luZyBwcm9jZWR1cmUgaWYgWCBp cyBleGNlZWRlZC48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JJ2Qgdm90ZSBmb3IgIzIuIEFkZGluZyBhZGRpdGlvbmFsIGJ1ZmZlcmluZyBsb2dpYyBz ZWVtcyBsaWtlIG92ZXJraWxsIGlmIHRoaXMgaXNuJ3QgYSB1c2UgY2FzZSB3ZSByZWFsbHkgaW50 ZW5kZWQgdG8gc3VwcG9ydC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNvcnJlc3BvbmRpbmcgd2VicnRjLXBjIGlzc3VlOiZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS93M2Mvd2VicnRjLXBjL2lzc3Vlcy8xODc5Ij5odHRwczov L2dpdGh1Yi5jb20vdzNjL3dlYnJ0Yy1wYy9pc3N1ZXMvMTg3OTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_c2aec186b055485c8705cfb24be6f70eericssoncom_-- From nobody Thu May 31 12:30: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 5B1B412E89B for ; Thu, 31 May 2018 12:30:09 -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 mdj2SgrhW7ZA for ; Thu, 31 May 2018 12:30:06 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B02412FB42 for ; Thu, 31 May 2018 12:30:06 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id e8-v6so15760003uam.13 for ; Thu, 31 May 2018 12:30: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=q/In5nNw3UdkZ5KW/SzNyF3zm1HkEkwvzOSr3dxu4fc=; b=s2jS/0nNYQC7DlsIfNIwueYqB5+oxFmJtVVfYoTiMD6BO3iVTO3hz35Txm7kOz3vJi RxHsQivHg1kQxT3rIrt5946AxVjV0oHu9W34BSghVReDr+1QPkCy75gYq1jBj8zJ7exc rOdrWLjvuZgZRyg+x+fWOlpWyrU3ytdz0jXStTchk4uMoljNt8P52wPYlGxgLaB2KKJt nwdI7iCWGit+YPGTkGiwWWihrFKgvUiRqdZ2RjibEfnDsDrsoFm0HefNlRaDaTvcrV0K 1MaIsBdYiVnAWb6+e6bkHM8L7lvmTL9wd5Rc7XK03zfcyfYdGPDoQypJmDJgtcsQjnXJ 63uw== 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=q/In5nNw3UdkZ5KW/SzNyF3zm1HkEkwvzOSr3dxu4fc=; b=pIm67F99fnubK0iD2QO8uh41p0CMd3VeNDRajc47cTfSNLr8UYrsoiMfIxCHXUfcZL t33UrwIX1cKZTA7aEKkKB001+n3u/3Tl6Y2bnu93IEwRPUAW4XHqO9AiQ9P/nqRYHaBx VMzjIdyFw3YXk/J1VAdZV7kBlGyQ207N6d5I2fPeP65V1E4nplwPQUgKKUAMh1DYSeZP OiIyL6u48xsgxGViJhXSOamvbShyBybkFKQwdM8yhSZwcCbxZR7yQEIzRnMF8dYnvVta ounKAoSnwrAJR+3ZmBvo3ILTlC4uBUAk9GAlsYIMTi/onJl/bs68to/NxpWupYrqXydH PhFQ== X-Gm-Message-State: ALKqPwfFVv5GPQkgZycDQalRUrr1hADq0VsNzB/77hzzP6mHClC0jlft rmyaVAU75u0xF1rnNF4CiZ3sDmNs3NXMKNuiPtcCTg== X-Google-Smtp-Source: ADUXVKLN6T+dczIRmdhmkWTTGwRC5ePCjtMPF8d3l0DErdQRR98MB32u4lnqA10ueWI21J7LlrutKycrwOJgN1Hk5Co= X-Received: by 2002:ab0:7011:: with SMTP id k17-v6mr5429349ual.107.1527795004843; Thu, 31 May 2018 12:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1f:9302:0:0:0:0:0 with HTTP; Thu, 31 May 2018 12:30:04 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Thu, 31 May 2018 12:30:04 -0700 Message-ID: To: Christer Holmberg Cc: Taylor Brandstetter , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000008e2f30056d857ee8" 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.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: Thu, 31 May 2018 19:30:10 -0000 --0000000000008e2f30056d857ee8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > As the data channel is realized as an SCTP stream, it sounds very weird > that one would not be allowed to negotiate a data channel after the SCTP > association has been established=E2=80=A6 > You can, using in-band negotiation. I'm only talking about out-of-band negotiation, where typically an application will create the data channel immediately after creating the PeerConnection. Section 6.5 of draft-ietf-mmusic-data-channel-sdpneg says... > WebRTC doesn't use this, though. WebRTC data channels are established either in-band, using draft-ietf-rtcweb-data-protocol, or out-of-band, which is completely up to the application and doesn't involve SDP. On Thu, May 31, 2018 at 11:38 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > As the data channel is realized as an SCTP stream, it sounds very weird > that one would not be allowed to negotiate a data channel after the SCTP > association has been established=E2=80=A6 > > > > But, if a data channel is established out-of-band, shouldn=E2=80=99t the > associated offer/answer transaction complete before the data channel is > used? > > > > Section 6.5 of draft-ietf-mmusic-data-channel-sdpneg says: > > > > =E2=80=9CEach agent application MUST wait to send data until it has > > confirmation that the data channel at the peer is instantiated.= =E2=80=9D > > > > In addition, the section describes when the offerer and answerer can > consider that the data channel has been instantiated at the peer. > > > > So, in my opinion any data that is sent before that could simply be > dropped, which I guess would be alternative 5 :) > > > > Regards, > > > > Christer > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Taylor > Brandstetter > *Sent:* 31 May 2018 20:24 > *To:* RTCWeb IETF > *Subject:* [rtcweb] Possible to lose initial messages sent by reliable, > out-of-band negotiated data channels > > > > 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 th= at > 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 receiv= ed > by the other peer before it's created its corresponding data channel, the= n > 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 proce= dure > 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. > > > > Corresponding webrtc-pc issue: https://github.com/w3c/ > webrtc-pc/issues/1879 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0000000000008e2f30056d857ee8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As the data channel is realized as an SCTP stream,= it sounds very weird that one would not be allowed to negotiate a data cha= nnel after the SCTP association has been established=E2=80=A6

You can, using in-band negotiation. I'm o= nly talking about out-of-band negotiation, where typically an application w= ill create the data channel immediately after creating the PeerConnection.<= /div>

Section 6.5 of draft-ietf-mmusic-data-channel-sdpneg says...

WebRTC= doesn't use this, though. WebRTC data channels are established either = in-band, using draft-ietf-rtcweb-data-protocol, or out-of-band, which is co= mpletely up to the application and doesn't involve SDP.

<= /div>

On Thu= , May 31, 2018 at 11:38 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:

Hi,

=C2=A0

As the data channel is realized as an= SCTP stream, it sounds very weird that one would not be allowed to negotia= te a data channel after the SCTP association has been established=E2=80=A6

=C2=A0

But, if a data channel is established= out-of-band, shouldn=E2=80=99t the associated offer/answer transaction com= plete before the data channel is used?

=C2=A0

Section 6.5 of draft-ietf-mmusic-data= -channel-sdpneg says:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =E2=80= =9CEach agent application MUST wait to send data until it has=

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0confirmation that the data channel at the peer is instantiated.=E2=80= =9D

=C2=A0

In addition, the section describes wh= en the offerer and answerer can consider that the data channel has been ins= tantiated at the peer.

=C2=A0

So, in my opinion any data that is se= nt before that could simply be dropped, which I guess would be alternative = 5 :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Taylor Brandstetter
Sent: 31 May 2018 20:24
To: RTCWeb IETF <rtcweb@ietf.org>
Subject: [rtcweb] Possible to lose initial messages sent by reliable= , out-of-band negotiated data channels

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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 dat= a 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 deliver= ed to the data channel once it's created. Run the closing procedure if = X is exceeded.

I'd vote for #2. Adding additional buffering log= ic seems like overkill if this isn't a use case we really intended to s= upport.

=C2=A0

Corresponding webrtc-pc issue:=C2=A0https://github.c= om/w3c/webrtc-pc/issues/1879


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

--0000000000008e2f30056d857ee8-- From nobody Thu May 31 15:52: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 1BA231318DD for ; Thu, 31 May 2018 15:52:32 -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 BNRKQzW1eMiX for ; Thu, 31 May 2018 15:52:29 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4FF131831 for ; Thu, 31 May 2018 15:52:29 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id f16-v6so19171364wrm.3 for ; Thu, 31 May 2018 15:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RNV61n2iNIRNcBDIIrsOndIlXHb5fhNCtQ1HH5EE6D8=; b=F+31j33wLSDErhyz6Z1dC1/7vybHu+M6L2b0PmKObDZyFR5wtDXe8GF45JZgXX8yQ5 R3trdNiK94x55i6Xo7vVcGOL1JQZm0ieppVEFjh7y9CN6w14m4lALsdX+h0xmoo8KEpf FV6t9A/f6bP8QNZFab4ddC5v0tVNOmXAAuEEpA4sfqul/8WSe6mWrz4uxCphaK9baCbF QL8NPvjpzlILlX7oAqHlhKVQDI01OF+1urbIZ9WD/aMcODcObGiPYA1PzzuG5RekFUM+ FnVdPx4JJr6E90ePmiqfWuahGdyIYY5g8W8jRy0+VQv3OVhHwFtB5OJwUrWVYmKkYxsE 0d/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RNV61n2iNIRNcBDIIrsOndIlXHb5fhNCtQ1HH5EE6D8=; b=j2w6Tq/7b3p3ov22JP41FdqfyOTiEkTQt8a2MsLpxEv+gUS7WidjGfNoLwM10WHLxX tz8z0Jc0B8opvN/OMo/VoD7qlHpZsnuiVqfTXDokLWTj9QQSY7rqpEFipruVxTLTHhh2 lgZdAkhGqJdBqpQxCu7EAY1hfAjG3mOfkzffNJm1N1t0FQEfKGMi83GLfPHFdP89M7Tb XbGsXFlx+hPa1o0jazNuLFcZaAHYUldX8DdKBprVxV3q/DsDDKnt8PpGY9ai2AWqQ4da 3UJaZJdLjYx/1mSaYgSBXVuJli4AzXtVMqqsrnweakWlUhz+JFfVcxrWzGke5JdOqGNU bRGw== X-Gm-Message-State: ALKqPwd5hJ9gBr8aXYXF+j0M/9Ow97+zK3pRIpGZ95ASwi1BnSJP1sdY ZV21jx8ILBaN0nRaitwZLtRbrg== X-Google-Smtp-Source: ADUXVKI0FixbFr4F8+miDcnQKKf/xpzbYzLRRmYWhKKFdBzs89oPUWvrut0+DzwFXh49YmsNFplhSg== X-Received: by 2002:adf:8462:: with SMTP id 89-v6mr7371171wrf.138.1527807147548; Thu, 31 May 2018 15:52:27 -0700 (PDT) Received: from ?IPv6:2003:cd:6f1f:4900:dda4:b912:267f:26de? (p200300CD6F1F4900DDA4B912267F26DE.dip0.t-ipconnect.de. [2003:cd:6f1f:4900:dda4:b912:267f:26de]) by smtp.gmail.com with ESMTPSA id k4-v6sm1014220wrr.68.2018.05.31.15.52.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 15:52:27 -0700 (PDT) To: rtcweb@ietf.org References: Cc: Taylor Brandstetter From: Lennart Grahl Message-ID: Date: Fri, 1 Jun 2018 00:52:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit 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.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: Thu, 31 May 2018 22:52:33 -0000 Hi, I'm not sure yet going for anything but 4. is a good idea but this is just a gut feeling. If it has to be any of the first three options, I would want it to be 3. on the sender side and 2. on the receiver side because I very much prefer APIs that fail explicitly rather than implicitly. Cheers Lennart On 31.05.2018 20:24, 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 > 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. > > Corresponding webrtc-pc issue: https://github.com/w3c/webrtc-pc/issues/1879 > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu May 31 17:11: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 EB7C512025C for ; Thu, 31 May 2018 17:11:04 -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 mm2UkzVCdT9j for ; Thu, 31 May 2018 17:11:02 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 93076120227 for ; Thu, 31 May 2018 17:11:02 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id t5-v6so15220072ioa.8 for ; Thu, 31 May 2018 17:11:02 -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=ikq0T3tSeLjdcMaAr/roLYV+uuBw6gMeqPDgLfEyPyM=; b=S42BY9ay/C8dcvV+YBuJGVCgUj8RHdZ6xShYl2G23uZmYZ24nD+XDohpnp/WoNV8Y8 VM8HsUswiaygAjtLD2HMgooUr0DD4C0gaIjw4laN1dq95fzyqGLZZgVA6PKvHJQNr0GC VgFbakqnD+t5EN6kLXoDLpKhEg4xtrF1Mra2amqhNx9I5eDhoK71fGENDSz3m8hkxQD8 720R8nhCBP5bk9cmo0aJ/fqxECit/NrYL5iCi9b/q3dqoX3JA6pfTNqW+PiYs2Yx85Yy k17n6xm+kifHU1VKFtvmcEKX8hBsA/NafkhzRFQpRyeZE1hJBPQkwuP6f/Xlx94XcMJD tDsA== 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=ikq0T3tSeLjdcMaAr/roLYV+uuBw6gMeqPDgLfEyPyM=; b=Up9U7Yr2LW+J+kYCed9+n/xPO50ZvHGeCFuGSQt0cNRZMG660qHDh2BrrTKNq2VHbW 0lwR6Ka2OGsLXev6ZgA23oYrX32nQqvng9HhYWZzc515UuHxgZETy4Mjp2cWg07PBjMS 3kHZlgw+5l/yhM+OacPHwFQq8vzoigTqsGi0DpHmF7RW5+Mad1CQFd8h9x9mlB0buldi zid5F46GtyMnaq6WWwUzp7bhS0fayqjZba93OtvldqIO1Dnn7FUci3NjcJf84dT/EW+7 XRH3rYcsUtP6jnD9LYoqLxvGfJIg/gtOEawize0uE3OvgoGbinUb12kP187ohgWWQCyY Dp4Q== X-Gm-Message-State: APt69E0dmypcpjotQOeLZTIJ7iJ2p1gAbd+VtDr5kxwIH6Z+A3BQI6kV 2ARfSC/QIt37eeVV3DaThce3IMp4t/0U7Hx98+rxmg== X-Google-Smtp-Source: ADUXVKL5Dclw1l9yEtq+anVeDCguQ7FjyhcOoUzdwzyeuYDabZFurMK2az1vllTsyaM5r9ErBlH1cLrK1u5HrH/AQ6g= X-Received: by 2002:a6b:7402:: with SMTP id s2-v6mr8198247iog.87.1527811861462; Thu, 31 May 2018 17:11:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 31 May 2018 17:10:49 -0700 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000004a035f056d896b46" 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.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: Fri, 01 Jun 2018 00:11:05 -0000 --0000000000004a035f056d896b46 Content-Type: text/plain; charset="UTF-8" #2 seems like the least bad option, but it's going to be very difficult to debug without additional information regarding why the close occurred. On Thu, May 31, 2018 at 3:52 PM Lennart Grahl wrote: > Hi, > > I'm not sure yet going for anything but 4. is a good idea but this is > just a gut feeling. If it has to be any of the first three options, I > would want it to be 3. on the sender side and 2. on the receiver side > because I very much prefer APIs that fail explicitly rather than > implicitly. > > Cheers > Lennart > > > On 31.05.2018 20:24, 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 > > 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. > > > > Corresponding webrtc-pc issue: > https://github.com/w3c/webrtc-pc/issues/1879 > > > > > > > > _______________________________________________ > > 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 > --0000000000004a035f056d896b46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
#2 seems like the least bad option, but it's goin= g to be very difficult to debug without additional information regarding wh= y the close occurred.

On Thu, May 31, 2018 at 3:52 PM Lennart Grahl <lennart.grahl@gmail.com> wrote:
Hi,

I'm not sure yet going for anything but 4. is a good idea but this is <= br> just a gut feeling. If it has to be any of the first three options, I
would want it to be 3. on the sender side and 2. on the receiver side
because I very much prefer APIs that fail explicitly rather than implicitly= .

Cheers
Lennart


On 31.05.2018 20:24, Taylor Brandstetter 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 lo= st if
> the application is negotiating the channels out-of-band, and creates t= he
> 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= that
> by the time a data channel is "open", it's guaranteed th= at 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 "o= pen" as
> soon as it's created. If a message is sent at this point, and it&#= 39;s received
> by the other peer before it's created its corresponding data chann= el, then
> the message will just be discarded.
>
> So, how should we deal with this? Some possibilities:
>
>=C2=A0 =C2=A0 =C2=A01. Say "this is expected behavior" and do= cument it better, breaking the
>=C2=A0 =C2=A0 =C2=A0reliability promise.
>=C2=A0 =C2=A0 =C2=A02. Run the closing procedure if a message is receiv= ed on a stream before
>=C2=A0 =C2=A0 =C2=A0a data channel is ready to receive it.
>=C2=A0 =C2=A0 =C2=A03. Don't even allow an out-of-band negotiated c= hannel to be created
>=C2=A0 =C2=A0 =C2=A0after the SCTP association is established.
>=C2=A0 =C2=A0 =C2=A04. Buffer these messages for up to X seconds (or up= to X bytes), to be
>=C2=A0 =C2=A0 =C2=A0delivered to the data channel once it's created= . Run the closing procedure
>=C2=A0 =C2=A0 =C2=A0if 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.
>
> Corresponding webrtc-pc issue: https://github.com/w= 3c/webrtc-pc/issues/1879
>
>
>
> _______________________________________________
> 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
--0000000000004a035f056d896b46-- From nobody Thu May 31 20:49: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 570AE126C25 for ; Thu, 31 May 2018 20:49:06 -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=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 dBEZUAv9Q0Fv for ; Thu, 31 May 2018 20:49:02 -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 449EF126CBF for ; Thu, 31 May 2018 20:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527824940; 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=IXN1aUBfZ56xq69kp3Wtzcrr259BihM6urXSXpGCAZc=; b=e/WrG2zY0fXv5rXV9v23Ws0JVKczCw0FjodNmkFa9NlGij+wJ29GM1lx2dGc9K0F +Pi8e9/X0zqi2xlUWg8150AqNWTgM19OMu810D2VBcxlUhjYgz56obg3EPEXieT+ bpfzMS8LEAPPzQjfn07Y9kH0JqAbBuerPTQdij83uO0=; X-AuditID: c1b4fb3a-323229c000005fee-b1-5b10c22c6bf4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.4E.24558.C22C01B5; Fri, 1 Jun 2018 05:49:00 +0200 (CEST) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSHC022.ericsson.se (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 1 Jun 2018 05:48:43 +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; Fri, 1 Jun 2018 05:48:42 +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, 1 Jun 2018 05:48:42 +0200 From: Christer Holmberg To: Taylor Brandstetter CC: Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels Thread-Index: AQHT+QykkBgeKHb7x06HnWNksweot6RKKQ9g///u3QCAAKzZlw== Date: Fri, 1 Jun 2018 03:48:42 +0000 Message-ID: <6006213D-67E3-4AD3-8C0B-EEF9F5130087@ericsson.com> References: , 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_6006213D67E34AD38C0BEEF9F5130087ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2J7iK7OIYFog5PrpS0eXfaxuLziIavF 2n/t7A7MHieWXWH1WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBk7T01hKeiZz1jx4vkWtgbG N7MYuxg5OCQETCQWLqrtYuTiEBI4wiix9so2JghnM6PE4olt7BDOV0aJGauvQTlLGSXmvDnG DNLOJmAh0f1Pu4uRk0NEQFfi5teFbCA2s0C8xNT/+1lAbGGBAok/V5ewQtQUSpy73gu2WUTA SaJxEy9ImEVAReL8/yfMIDavgL3E9AuXWCFWHWeUaHjawg6S4BQIlDjy6zyYzSggJvH91Bom iF3iEreezAezJQQEJJbsOc8MYYtKvHz8jxWiJlniS/sTRogFghInZz4Bu01IQFuiZfEE9gmM YrOQjJqFpGUWkpZZQGczC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxcW56UZG eqlFmcnFxfl5enmpJZsYgbF5cMtvqx2MB587HmIU4GBU4uE9uEUgWog1say4MvcQowQHs5II 75Qy/mgh3pTEyqrUovz4otKc1OJDjNIcLErivE5pFlFCAumJJanZqakFqUUwWSYOTqkGRvYP hfs+CVVPrZORuqR+Ivho55MEg8cVWftYJu36XiRdISxmqKXBnlZ1X065L9isYPb0Z/sOpl43 /LZyY6668rspppxa+n337i/ZI39p8575h7ZLVO4LMOw5khPbr5Mz8/qWdoOZR2O0I4uVeuc6 Bj39HHEh/fqyTf8PpEqHPcyxclRi+vF6shJLcUaioRZzUXEiAEV/6JTJAgAA 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.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: Fri, 01 Jun 2018 03:49:06 -0000 --_000_6006213D67E34AD38C0BEEF9F5130087ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vIG1hdHRlciB3aGF0IG91dC1vZi1iYW5kIHByb3RvY29sIHlvdSB1c2UgZm9yIG9w ZW5pbmcgYSBkYXRhIGNoYW5uZWwsIGl0IG5lZWRzIHRvIHByb3ZpZGUgc29tZSBraW5kIG9mIGlu ZGljYXRpb24gdGhhdCB0aGUgcGVlciBpcyByZWFkeSAtIGFuZCB0aGF0IHRoZSBwZWVyIGFjY2Vw dHMgdGhlIGRhdGEgY2hhbm5lbCB0byBiZWdpbiB3aXRoLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIDMxIE1heSAyMDE4LCBhdCAyMi4zMCwgVGF5 bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbTxtYWlsdG86ZGVhZGJlZWZAZ29v Z2xlLmNvbT4+IHdyb3RlOg0KDQpBcyB0aGUgZGF0YSBjaGFubmVsIGlzIHJlYWxpemVkIGFzIGFu IFNDVFAgc3RyZWFtLCBpdCBzb3VuZHMgdmVyeSB3ZWlyZCB0aGF0IG9uZSB3b3VsZCBub3QgYmUg YWxsb3dlZCB0byBuZWdvdGlhdGUgYSBkYXRhIGNoYW5uZWwgYWZ0ZXIgdGhlIFNDVFAgYXNzb2Np YXRpb24gaGFzIGJlZW4gZXN0YWJsaXNoZWTigKYNCg0KWW91IGNhbiwgdXNpbmcgaW4tYmFuZCBu ZWdvdGlhdGlvbi4gSSdtIG9ubHkgdGFsa2luZyBhYm91dCBvdXQtb2YtYmFuZCBuZWdvdGlhdGlv biwgd2hlcmUgdHlwaWNhbGx5IGFuIGFwcGxpY2F0aW9uIHdpbGwgY3JlYXRlIHRoZSBkYXRhIGNo YW5uZWwgaW1tZWRpYXRlbHkgYWZ0ZXIgY3JlYXRpbmcgdGhlIFBlZXJDb25uZWN0aW9uLg0KDQpT ZWN0aW9uIDYuNSBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnIHNheXMu Li4NCg0KV2ViUlRDIGRvZXNuJ3QgdXNlIHRoaXMsIHRob3VnaC4gV2ViUlRDIGRhdGEgY2hhbm5l bHMgYXJlIGVzdGFibGlzaGVkIGVpdGhlciBpbi1iYW5kLCB1c2luZyBkcmFmdC1pZXRmLXJ0Y3dl Yi1kYXRhLXByb3RvY29sLCBvciBvdXQtb2YtYmFuZCwgd2hpY2ggaXMgY29tcGxldGVseSB1cCB0 byB0aGUgYXBwbGljYXRpb24gYW5kIGRvZXNuJ3QgaW52b2x2ZSBTRFAuDQoNCg0KT24gVGh1LCBN YXkgMzEsIDIwMTggYXQgMTE6MzggQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+ IHdyb3RlOg0KSGksDQoNCkFzIHRoZSBkYXRhIGNoYW5uZWwgaXMgcmVhbGl6ZWQgYXMgYW4gU0NU UCBzdHJlYW0sIGl0IHNvdW5kcyB2ZXJ5IHdlaXJkIHRoYXQgb25lIHdvdWxkIG5vdCBiZSBhbGxv d2VkIHRvIG5lZ290aWF0ZSBhIGRhdGEgY2hhbm5lbCBhZnRlciB0aGUgU0NUUCBhc3NvY2lhdGlv biBoYXMgYmVlbiBlc3RhYmxpc2hlZOKApg0KDQpCdXQsIGlmIGEgZGF0YSBjaGFubmVsIGlzIGVz dGFibGlzaGVkIG91dC1vZi1iYW5kLCBzaG91bGRu4oCZdCB0aGUgYXNzb2NpYXRlZCBvZmZlci9h bnN3ZXIgdHJhbnNhY3Rpb24gY29tcGxldGUgYmVmb3JlIHRoZSBkYXRhIGNoYW5uZWwgaXMgdXNl ZD8NCg0KU2VjdGlvbiA2LjUgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5l ZyBzYXlzOg0KDQogICAgICDigJxFYWNoIGFnZW50IGFwcGxpY2F0aW9uIE1VU1Qgd2FpdCB0byBz ZW5kIGRhdGEgdW50aWwgaXQgaGFzDQogICAgICAgIGNvbmZpcm1hdGlvbiB0aGF0IHRoZSBkYXRh IGNoYW5uZWwgYXQgdGhlIHBlZXIgaXMgaW5zdGFudGlhdGVkLuKAnQ0KDQpJbiBhZGRpdGlvbiwg dGhlIHNlY3Rpb24gZGVzY3JpYmVzIHdoZW4gdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIGNhbiBj b25zaWRlciB0aGF0IHRoZSBkYXRhIGNoYW5uZWwgaGFzIGJlZW4gaW5zdGFudGlhdGVkIGF0IHRo ZSBwZWVyLg0KDQpTbywgaW4gbXkgb3BpbmlvbiBhbnkgZGF0YSB0aGF0IGlzIHNlbnQgYmVmb3Jl IHRoYXQgY291bGQgc2ltcGx5IGJlIGRyb3BwZWQsIHdoaWNoIEkgZ3Vlc3Mgd291bGQgYmUgYWx0 ZXJuYXRpdmUgNSA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBydGN3ZWIgW21h aWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgVGF5bG9yIEJyYW5kc3RldHRlcg0KU2VudDogMzEgTWF5IDIwMTgg MjA6MjQNClRvOiBSVENXZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogW3J0Y3dlYl0gUG9zc2libGUgdG8gbG9zZSBpbml0aWFsIG1lc3Nh Z2VzIHNlbnQgYnkgcmVsaWFibGUsIG91dC1vZi1iYW5kIG5lZ290aWF0ZWQgZGF0YSBjaGFubmVs cw0KDQpPbmUgbWlnaHQgZXhwZWN0IHRoYXQgYSAicmVsaWFibGUiIGRhdGEgY2hhbm5lbCBpcyBn dWFyYW50ZWVkIHRvIGJlLCB3ZWxsLCByZWxpYWJsZS4gQnV0IGluIGN1cnJlbnQgaW1wbGVtZW50 YXRpb25zLCB0aGUgZmlyc3QgbWVzc2FnZXMgbWF5IGJlIGxvc3QgaWYgdGhlIGFwcGxpY2F0aW9u IGlzIG5lZ290aWF0aW5nIHRoZSBjaGFubmVscyBvdXQtb2YtYmFuZCwgYW5kIGNyZWF0ZXMgdGhl IHJlY2VpdmluZyBjaGFubmVsIHRvbyBsYXRlLg0KDQpIZXJlJ3MgYSBmaWRkbGUgdGhhdCBkZW1v bnN0cmF0ZXMgdGhpcyAoaGFwcGVucyB3aXRoIENocm9tZSBhbmQgRmlyZWZveCk6IGh0dHBzOi8v anNmaWRkbGUubmV0L28ybTh0cDIwLw0KDQpOb3JtYWxseSB0aGlzIGlzbid0IGFuIGlzc3VlLCBi ZWNhdXNlIGEgdHlwaWNhbCBhcHBsaWNhdGlvbiB3b3VsZCBjcmVhdGUgdGhlIG91dC1vZi1iYW5k IG5lZ290aWF0ZWQgY2hhbm5lbHMgYmVmb3JlIHRoZSBmaXJzdCBvZmZlci9hbnN3ZXIgaXMgY29t cGxldGUsIGFuZCB0aHVzIGJlZm9yZSB0aGUgU0NUUCBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hl ZC4gTWVhbmluZyB0aGF0IGJ5IHRoZSB0aW1lIGEgZGF0YSBjaGFubmVsIGlzICJvcGVuIiwgaXQn cyBndWFyYW50ZWVkIHRoYXQgdGhlIG90aGVyIHBlZXIgaGFzIGEgY29ycmVzcG9uZGluZyBjaGFu bmVsLg0KDQpCdXQgaWYgZm9yIHdoYXRldmVyIHJlYXNvbiwgYW4gYXBwbGljYXRpb24gY3JlYXRl cyBhIGRhdGEgY2hhbm5lbCAqYWZ0ZXIqIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGlzIGVzdGFibGlz aGVkLCB0aGVuIGl0IHdpbGwgaW5zdGFudGx5IGJlICJvcGVuIiBhcyBzb29uIGFzIGl0J3MgY3Jl YXRlZC4gSWYgYSBtZXNzYWdlIGlzIHNlbnQgYXQgdGhpcyBwb2ludCwgYW5kIGl0J3MgcmVjZWl2 ZWQgYnkgdGhlIG90aGVyIHBlZXIgYmVmb3JlIGl0J3MgY3JlYXRlZCBpdHMgY29ycmVzcG9uZGlu ZyBkYXRhIGNoYW5uZWwsIHRoZW4gdGhlIG1lc3NhZ2Ugd2lsbCBqdXN0IGJlIGRpc2NhcmRlZC4N Cg0KU28sIGhvdyBzaG91bGQgd2UgZGVhbCB3aXRoIHRoaXM/IFNvbWUgcG9zc2liaWxpdGllczoN Cg0KICAxLiAgU2F5ICJ0aGlzIGlzIGV4cGVjdGVkIGJlaGF2aW9yIiBhbmQgZG9jdW1lbnQgaXQg YmV0dGVyLCBicmVha2luZyB0aGUgcmVsaWFiaWxpdHkgcHJvbWlzZS4NCiAgMi4gIFJ1biB0aGUg Y2xvc2luZyBwcm9jZWR1cmUgaWYgYSBtZXNzYWdlIGlzIHJlY2VpdmVkIG9uIGEgc3RyZWFtIGJl Zm9yZSBhIGRhdGEgY2hhbm5lbCBpcyByZWFkeSB0byByZWNlaXZlIGl0Lg0KICAzLiAgRG9uJ3Qg ZXZlbiBhbGxvdyBhbiBvdXQtb2YtYmFuZCBuZWdvdGlhdGVkIGNoYW5uZWwgdG8gYmUgY3JlYXRl ZCBhZnRlciB0aGUgU0NUUCBhc3NvY2lhdGlvbiBpcyBlc3RhYmxpc2hlZC4NCiAgNC4gIEJ1ZmZl ciB0aGVzZSBtZXNzYWdlcyBmb3IgdXAgdG8gWCBzZWNvbmRzIChvciB1cCB0byBYIGJ5dGVzKSwg dG8gYmUgZGVsaXZlcmVkIHRvIHRoZSBkYXRhIGNoYW5uZWwgb25jZSBpdCdzIGNyZWF0ZWQuIFJ1 biB0aGUgY2xvc2luZyBwcm9jZWR1cmUgaWYgWCBpcyBleGNlZWRlZC4NCkknZCB2b3RlIGZvciAj Mi4gQWRkaW5nIGFkZGl0aW9uYWwgYnVmZmVyaW5nIGxvZ2ljIHNlZW1zIGxpa2Ugb3ZlcmtpbGwg aWYgdGhpcyBpc24ndCBhIHVzZSBjYXNlIHdlIHJlYWxseSBpbnRlbmRlZCB0byBzdXBwb3J0Lg0K DQpDb3JyZXNwb25kaW5nIHdlYnJ0Yy1wYyBpc3N1ZTogaHR0cHM6Ly9naXRodWIuY29tL3czYy93 ZWJydGMtcGMvaXNzdWVzLzE4NzkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg0KDQo= --_000_6006213D67E34AD38C0BEEF9F5130087ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI aSwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vIG1hdHRlciB3aGF0IG91dC1vZi1iYW5kIHBy b3RvY29sIHlvdSB1c2UgZm9yIG9wZW5pbmcgYSBkYXRhIGNoYW5uZWwsIGl0IG5lZWRzIHRvIHBy b3ZpZGUgc29tZSBraW5kIG9mIGluZGljYXRpb24gdGhhdCB0aGUgcGVlciBpcyByZWFkeSAtIGFu ZCB0aGF0IHRoZSBwZWVyIGFjY2VwdHMgdGhlIGRhdGEgY2hhbm5lbCB0byBiZWdpbiB3aXRoLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkNocmlzdGVyJm5ic3A7PGJyPg0KPGJyPg0KPGRpdiBpZD0iQXBwbGVNYWls U2lnbmF0dXJlIj5TZW50IGZyb20gbXkgaVBob25lPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIDMxIE1h eSAyMDE4LCBhdCAyMi4zMCwgVGF5bG9yIEJyYW5kc3RldHRlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRlYWRiZWVmQGdvb2dsZS5jb20iPmRlYWRiZWVmQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXYg ZGlyPSJsdHIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu OjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQp O3BhZGRpbmctbGVmdDoxZXgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOnJnYigzMSw3MywxMjUpO2Zv bnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTQuNjY2N3B4O2ZvbnQtc3R5 bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBz Om5vcm1hbDtmb250LXdlaWdodDo0MDA7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9y bWFsO3dvcmQtc3BhY2luZzowcHg7YmFja2dyb3VuZC1jb2xvcjpyZ2IoMjU1LDI1NSwyNTUpO3Rl eHQtZGVjb3JhdGlvbi1zdHlsZTppbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjppbml0aWFs O2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmUiPkFzDQogdGhlIGRhdGEgY2hhbm5lbCBpcyByZWFs aXplZCBhcyBhbiBTQ1RQIHN0cmVhbSwgaXQgc291bmRzIHZlcnkgd2VpcmQgdGhhdCBvbmUgd291 bGQgbm90IGJlIGFsbG93ZWQgdG8gbmVnb3RpYXRlIGEgZGF0YSBjaGFubmVsIGFmdGVyIHRoZSBT Q1RQIGFzc29jaWF0aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVk4oCmPC9zcGFuPjxicj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdSBjYW4sIHVzaW5nIGluLWJhbmQg bmVnb3RpYXRpb24uIEknbSBvbmx5IHRhbGtpbmcgYWJvdXQgb3V0LW9mLWJhbmQgbmVnb3RpYXRp b24sIHdoZXJlIHR5cGljYWxseSBhbiBhcHBsaWNhdGlvbiB3aWxsIGNyZWF0ZSB0aGUgZGF0YSBj aGFubmVsIGltbWVkaWF0ZWx5IGFmdGVyIGNyZWF0aW5nIHRoZSBQZWVyQ29ubmVjdGlvbi48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigy MDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6cmdiKDMx LDczLDEyNSk7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNC42NjY3 cHgiPlNlY3Rpb24gNi41IG9mIGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtPC9zcGFuPjx3YnIgc3R5 bGU9ImNvbG9yOnJnYigzMSw3MywxMjUpO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtm b250LXNpemU6MTQuNjY2N3B4Ij48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDMxLDczLDEyNSk7Zm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxNC42NjY3cHgiPmNoYW5uZWwt c2RwbmVnDQogc2F5cy4uLjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5XZWJSVEMgZG9lc24ndCB1c2UgdGhpcywgdGhvdWdoLiBXZWJSVEMgZGF0YSBj aGFubmVscyBhcmUgZXN0YWJsaXNoZWQgZWl0aGVyIGluLWJhbmQsIHVzaW5nIGRyYWZ0LWlldGYt cnRjd2ViLWRhdGEtcHJvdG9jb2wsIG9yIG91dC1vZi1iYW5kLCB3aGljaCBpcyBjb21wbGV0ZWx5 IHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBhbmQgZG9lc24ndCBpbnZvbHZlIFNEUC48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVGh1LCBNYXkgMzEsIDIwMTggYXQgMTE6MzggQU0s IENocmlzdGVyIEhvbG1iZXJnIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1s ZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1HQiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJtXzE3NjQ4ODM0OTkwNjcx NDM4MTRXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxZjQ5N2QiPkhpLDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFmNDk3ZCI+QXMgdGhlIGRhdGEgY2hhbm5lbCBpcyByZWFsaXplZCBhcyBhbiBTQ1RQIHN0 cmVhbSwgaXQgc291bmRzIHZlcnkgd2VpcmQgdGhhdCBvbmUgd291bGQgbm90IGJlIGFsbG93ZWQg dG8gbmVnb3RpYXRlIGEgZGF0YSBjaGFubmVsIGFmdGVyIHRoZSBTQ1RQIGFzc29jaWF0aW9uIGhh cw0KIGJlZW4gZXN0YWJsaXNoZWTigKYgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJz cDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMWY0OTdkIj5CdXQsIGlmIGEgZGF0YSBjaGFubmVsIGlzIGVzdGFibGlzaGVkIG91 dC1vZi1iYW5kLCBzaG91bGRu4oCZdCB0aGUgYXNzb2NpYXRlZCBvZmZlci9hbnN3ZXIgdHJhbnNh Y3Rpb24gY29tcGxldGUgYmVmb3JlIHRoZSBkYXRhIGNoYW5uZWwgaXMgdXNlZD88dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiPlNlY3Rpb24gNi41IG9mIGRy YWZ0LWlldGYtbW11c2ljLWRhdGEtPHdicj5jaGFubmVsLXNkcG5lZyBzYXlzOjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IOKAnEVhY2ggYWdlbnQgYXBwbGljYXRpb24gTVVTVCB3YWl0IHRvIHNlbmQg ZGF0YSB1bnRpbCBpdCBoYXM8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NvbmZpcm1hdGlvbiB0aGF0IHRoZSBkYXRhIGNoYW5u ZWwgYXQgdGhlIHBlZXIgaXMgaW5zdGFudGlhdGVkLuKAnTx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIj48 dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFmNDk3ZCI+SW4gYWRkaXRpb24sIHRoZSBzZWN0aW9uIGRlc2Ny aWJlcyB3aGVuIHRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlciBjYW4gY29uc2lkZXIgdGhhdCB0aGUg ZGF0YSBjaGFubmVsIGhhcyBiZWVuIGluc3RhbnRpYXRlZCBhdCB0aGUgcGVlci48dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiPlNvLCBpbiBteSBvcGluaW9u IGFueSBkYXRhIHRoYXQgaXMgc2VudCBiZWZvcmUgdGhhdCBjb3VsZCBzaW1wbHkgYmUgZHJvcHBl ZCwgd2hpY2ggSSBndWVzcyB3b3VsZCBiZSBhbHRlcm5hdGl2ZSA1IDopDQo8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxZjQ5N2QiPlJlZ2FyZHMsPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdkIj5DaHJpc3Rlcjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Im1fMTc2NDg4MzQ5 OTA2NzE0MzgxNF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMWY0OTdk Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWItYm91bmNlc0Bp ZXRmLjx3YnI+b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VGF5bG9yIEJyYW5kc3RldHRl cjxicj4NCjxiPlNlbnQ6PC9iPiAzMSBNYXkgMjAxOCAyMDoyNDxicj4NCjxiPlRvOjwvYj4gUlRD V2ViIElFVEYgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbcnRjd2Vi XSBQb3NzaWJsZSB0byBsb3NlIGluaXRpYWwgbWVzc2FnZXMgc2VudCBieSByZWxpYWJsZSwgb3V0 LW9mLWJhbmQgbmVnb3RpYXRlZCBkYXRhIGNoYW5uZWxzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4m bmJzcDs8dT48L3U+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T25lIG1pZ2h0IGV4cGVjdCB0aGF0IGEgJnF1b3Q7cmVsaWFibGUmcXVvdDsgZGF0YSBjaGFu bmVsIGlzIGd1YXJhbnRlZWQgdG8gYmUsIHdlbGwsIHJlbGlhYmxlLiBCdXQgaW4gY3VycmVudCBp bXBsZW1lbnRhdGlvbnMsIHRoZSBmaXJzdCBtZXNzYWdlcyBtYXkgYmUgbG9zdCBpZiB0aGUgYXBw bGljYXRpb24gaXMgbmVnb3RpYXRpbmcgdGhlIGNoYW5uZWxzIG91dC1vZi1iYW5kLCBhbmQgY3Jl YXRlcyB0aGUgcmVjZWl2aW5nIGNoYW5uZWwNCiB0b28gbGF0ZS48dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSdzIGEgZmlkZGxl IHRoYXQgZGVtb25zdHJhdGVzIHRoaXMgKGhhcHBlbnMgd2l0aCBDaHJvbWUgYW5kIEZpcmVmb3gp Og0KPGEgaHJlZj0iaHR0cHM6Ly9qc2ZpZGRsZS5uZXQvbzJtOHRwMjAvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9qc2ZpZGRsZS5uZXQvbzJtOHRwMjAvPC9hPjx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3JtYWxseSB0aGlzIGlz bid0IGFuIGlzc3VlLCBiZWNhdXNlIGEgdHlwaWNhbCBhcHBsaWNhdGlvbiB3b3VsZCBjcmVhdGUg dGhlIG91dC1vZi1iYW5kIG5lZ290aWF0ZWQgY2hhbm5lbHMgYmVmb3JlIHRoZSBmaXJzdCBvZmZl ci9hbnN3ZXIgaXMgY29tcGxldGUsIGFuZCB0aHVzIGJlZm9yZSB0aGUgU0NUUCBhc3NvY2lhdGlv biBpcyBlc3RhYmxpc2hlZC4gTWVhbmluZyB0aGF0IGJ5IHRoZSB0aW1lIGEgZGF0YQ0KIGNoYW5u ZWwgaXMgJnF1b3Q7b3BlbiZxdW90OywgaXQncyBndWFyYW50ZWVkIHRoYXQgdGhlIG90aGVyIHBl ZXIgaGFzIGEgY29ycmVzcG9uZGluZyBjaGFubmVsLjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgaWYgZm9yIHdoYXRldmVyIHJl YXNvbiwgYW4gYXBwbGljYXRpb24gY3JlYXRlcyBhIGRhdGEgY2hhbm5lbCAqYWZ0ZXIqIHRoZSBT Q1RQIGFzc29jaWF0aW9uIGlzIGVzdGFibGlzaGVkLCB0aGVuIGl0IHdpbGwgaW5zdGFudGx5IGJl ICZxdW90O29wZW4mcXVvdDsgYXMgc29vbiBhcyBpdCdzIGNyZWF0ZWQuIElmIGEgbWVzc2FnZSBp cyBzZW50IGF0IHRoaXMgcG9pbnQsIGFuZCBpdCdzIHJlY2VpdmVkIGJ5IHRoZSBvdGhlcg0KIHBl ZXIgYmVmb3JlIGl0J3MgY3JlYXRlZCBpdHMgY29ycmVzcG9uZGluZyBkYXRhIGNoYW5uZWwsIHRo ZW4gdGhlIG1lc3NhZ2Ugd2lsbCBqdXN0IGJlIGRpc2NhcmRlZC48dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIGhvdyBzaG91bGQg d2UgZGVhbCB3aXRoIHRoaXM/IFNvbWUgcG9zc2liaWxpdGllczo8dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIj5TYXkgJnF1b3Q7dGhpcyBpcyBleHBlY3RlZCBiZWhhdmlvciZxdW90OyBh bmQgZG9jdW1lbnQgaXQgYmV0dGVyLCBicmVha2luZyB0aGUgcmVsaWFiaWxpdHkgcHJvbWlzZS48 dT48L3U+PHU+PC91PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiPlJ1biB0aGUgY2xvc2luZyBw cm9jZWR1cmUgaWYgYSBtZXNzYWdlIGlzIHJlY2VpdmVkIG9uIGEgc3RyZWFtIGJlZm9yZSBhIGRh dGEgY2hhbm5lbCBpcyByZWFkeSB0byByZWNlaXZlIGl0Ljx1PjwvdT48dT48L3U+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCI+RG9uJ3QgZXZlbiBhbGxvdyBhbiBvdXQtb2YtYmFuZCBuZWdvdGlh dGVkIGNoYW5uZWwgdG8gYmUgY3JlYXRlZCBhZnRlciB0aGUgU0NUUCBhc3NvY2lhdGlvbiBpcyBl c3RhYmxpc2hlZC48dT48L3U+PHU+PC91PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiPkJ1ZmZl ciB0aGVzZSBtZXNzYWdlcyBmb3IgdXAgdG8gWCBzZWNvbmRzIChvciB1cCB0byBYIGJ5dGVzKSwg dG8gYmUgZGVsaXZlcmVkIHRvIHRoZSBkYXRhIGNoYW5uZWwgb25jZSBpdCdzIGNyZWF0ZWQuIFJ1 biB0aGUgY2xvc2luZyBwcm9jZWR1cmUgaWYgWCBpcyBleGNlZWRlZC48dT48L3U+PHU+PC91Pjwv bGk+PC9vbD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2Qgdm90ZSBmb3IgIzIuIEFk ZGluZyBhZGRpdGlvbmFsIGJ1ZmZlcmluZyBsb2dpYyBzZWVtcyBsaWtlIG92ZXJraWxsIGlmIHRo aXMgaXNuJ3QgYSB1c2UgY2FzZSB3ZSByZWFsbHkgaW50ZW5kZWQgdG8gc3VwcG9ydC48dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNv cnJlc3BvbmRpbmcgd2VicnRjLXBjIGlzc3VlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS93M2Mvd2VicnRjLXBjL2lzc3Vlcy8xODc5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9n aXRodWIuY29tL3czYy88d2JyPndlYnJ0Yy1wYy9pc3N1ZXMvMTg3OTwvYT48dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPGJyPg0KcnRj d2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0 Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi88d2JyPmxpc3RpbmZvL3J0Y3dlYjwvYT48YnI+DQo8 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6006213D67E34AD38C0BEEF9F5130087ericssoncom_--