From nobody Mon Aug 1 07:00:50 2016 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 1659B12DA17; Mon, 1 Aug 2016 07:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-oh4IlYjKQk; Mon, 1 Aug 2016 07:00:45 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B930112DA78; Mon, 1 Aug 2016 06:56:23 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id r9so173002184ywg.0; Mon, 01 Aug 2016 06:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MCjSQERsUuFDaDKouSkASvfB5JmdsA6R3WcS3rl4oxw=; b=HLmjP17h1NT1Gqq9GzLhN8HtuSOj5kMSToiMfHSqkX2t1miXY8XVUd4YDBXUo2rWkO 4k2XwH0uWi2qc5Rhd6tK8isn4IvuaGCwGrdeE2g9VjlG+Gi9GK2Yoz8+ulpGHPdxmzt3 t3vchC2iPFJoZAV/HDc98Zw51YdDjf2xgFMHTqTZh78tqhVTbba7f/ysp/hajfx1mgzx S1L1N8IYykC5SI1swvCNM95YGbJ2ryExZUh+dG6+UKyBzKg7NKdTnyyk374Hzeoek2dH VAYax9KZ1Q3YmaSfH1QKWzWg7VPX23B2AsyZhtqljGGKBFKT46OS3z4sf+zfvZ7p+mdJ ZAQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MCjSQERsUuFDaDKouSkASvfB5JmdsA6R3WcS3rl4oxw=; b=Ro9eDGgHfMVwyYMXJ6nb4MLX6nLkpui2WlH7fXcR5BVzMRbRreTxKTkm7i9z5DF6ij femen7f6fItoh+zeNYM9lWsYUo/rKvM3l1rnfVLmSPcyaWKVFJpQdcmLpgd8vwG1tNCM I8RoB8nST6kI5TRyXzo5KSI7Sq8wrSgZu5rkbQzbsqsgIBArSwKe/UnBh/nMTeL4hdDg Py1jmtlpKKB2nM6TmU+zUeV1ZuGAFzbFK2JpRA+X4TLF76ORtm2KYyuH00+L6JSK6vne /FuWkLs2fR2StdW5h6c43RlGehsIRSxSXqyu+VtpvJGfQbxPJ4lvb0jQe7FNXHz39/lQ 3Ytw== X-Gm-Message-State: AEkoouu/HlAm+tWwMzKKrHrxCjBRtsM7FXQGKlYOSQzkIW2q3jegVh9U8P0485DDrzpbJaFS1dapvLrPXOW9Ww== X-Received: by 10.37.50.72 with SMTP id y69mr35222270yby.5.1470059782894; Mon, 01 Aug 2016 06:56:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.198 with HTTP; Mon, 1 Aug 2016 06:56:22 -0700 (PDT) In-Reply-To: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> From: Spencer Dawkins at IETF Date: Mon, 1 Aug 2016 08:56:22 -0500 Message-ID: To: "Black, David" Content-Type: multipart/alternative; boundary=001a1146d19e2878c1053902f74c Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 01 Aug 2016 14:00:49 -0000 --001a1146d19e2878c1053902f74c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, all, On Thu, Jul 14, 2016 at 4:13 PM, Black, David wrote: > Magnus, > > I think that's a fine suggestion. I think the next step is: > > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in draft-ietf-rtcweb-transport= s > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about th= e > > need, and indicate future forthcoming specification or if we hold this > > document up until this solution is available? > > I'll attend the Thu RTCWEB session in Berlin to see how this comes out, > after which it should be straightforward for the draft authors and yours > truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will > need. I'm just following up on this because we have draft-ietf-rtcweb-transports on the telechat agenda this week, and I didn't see a discussion on this topic in the RTCWeb agenda (or in poking around for minutes, jabber, etherpad, etc). Did it happen? Was there a resolution? Thanks, Spencer > Thanks, --David > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, July 14, 2016 4:53 AM > > To: Cullen Jennings (fluffy); Black, David > > Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org > > Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in > draft-ietf-tsvwg-rtcweb-qos ? > > > > Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): > > > > > > short answer here but as David suggested =E2=80=A6 some implementati= on use > > > the STUN packets in ICE or just in WebRTC style liveness tests to > > > do the tests of if a given DSCP works or not. In general ICE is a > > > good tool to take a bunch of possible paths, test which work, and > > > select the best. > > > > I do agree that how you do the path checks when setting DSCP values != =3D 0 > > is dependent on the context. For the WebRTC I do agree doing checks > > using ICE is quite reasonable. > > > > We already have similar path testing usages of ICE in the ECN for RTP > > specification (RFC6679), see Section 7.2.1. I will note that taking thi= s > > as blueprint for DSCP testing, what is needed clearly requires a new > > separate specification. The components needs are: 1) A new STUN > > parameter to request the ICE peer to echo the DSCP field value received= . > > 2) A ICE capability parameter to be used in signalling negotiations to > > determine capability for this feature. 3) Behaviour specification on ho= w > > to test values and interpret responses. This include things like if one > > should actually establish multiple candidate pairs one with DSCP testin= g > > and one without? > > > > So the question here is how to proceed with this issue. So I would > > suggest the following way forward. > > > > 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the > > user to apply path verification methods but don't specify them. > > > > 2. Someone takes on the task to write a DSCP path verification extensio= n > > to ICE. > > > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in draft-ietf-rtcweb-transport= s > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about th= e > > need, and indicate future forthcoming specification or if we hold this > > document up until this solution is available? > > > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1146d19e2878c1053902f74c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, all,

On Thu, Jul 14, 2016 at 4:13 PM, Black, David <= ;david.black@emc.c= om> wrote:
Magnus,

I think that's a fine suggestion.=C2=A0 =C2=A0I think the next step is:=

> 3. The natural place to indicate the need/recommendation for
> implementing this functionality would be in draft-ietf-rtcweb-transpor= ts
> (Currently in IETF LC). However, here I think we need to have a
> discussion if RTCWEB WG wants to only place a suitable warning about t= he
> need, and indicate future forthcoming specification or if we hold this=
> document up until this solution is available?

I'll attend the Thu RTCWEB session in Berlin to see how this com= es out,
after which it should be straightforward for the draft authors and yours truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will need.

I'm just following up on this bec= ause we have draft-ietf-rtcweb-transports on the telechat agenda this week,= and I didn't see a discussion on this topic in the RTCWeb agenda (or i= n poking around for minutes, jabber, etherpad, etc).=C2=A0

Did it happen? Was there a resolution?

Th= anks,

Spencer
=C2=A0
Thanks, --David

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Thursday, July 14, 2016 4:53 AM
> To: Cullen Jennings (fluffy); Black, David
> Cc: RTCWeb IETF; Michael Welzl; tsvw= g@ietf.org
> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg-= rtcweb-qos ?
>
> Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy):
> >
> > short answer here but as David suggested =E2=80=A6=C2=A0 some imp= lementation use
> > the STUN packets in ICE=C2=A0 or just=C2=A0 in WebRTC style liven= ess tests to
> > do the tests of if a given DSCP works or not. In general ICE is a=
> > good tool to take a bunch of possible paths, test which work, and=
> > select the best.
>
> I do agree that how you do the path checks when setting DSCP values != =3D 0
> is dependent on the context. For the WebRTC I do agree doing checks > using ICE is quite reasonable.
>
> We already have similar path testing usages of ICE in the ECN for RTP<= br> > specification (RFC6679), see Section 7.2.1. I will note that taking th= is
> as blueprint for DSCP testing, what is needed clearly requires a new > separate specification. The components needs are: 1) A new STUN
> parameter to request the ICE peer to echo the DSCP field value receive= d.
> 2) A ICE capability parameter to be used in signalling negotiations to=
> determine capability for this feature. 3) Behaviour specification on h= ow
> to test values and interpret responses. This include things like if on= e
> should actually establish multiple candidate pairs one with DSCP testi= ng
> and one without?
>
> So the question here is how to proceed with this issue. So I would
> suggest the following way forward.
>
> 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the=
> user to apply path verification methods but don't specify them. >
> 2. Someone takes on the task to write a DSCP path verification extensi= on
> to ICE.
>
> 3. The natural place to indicate the need/recommendation for
> implementing this functionality would be in draft-ietf-rtcweb-transpor= ts
> (Currently in IETF LC). However, here I think we need to have a
> discussion if RTCWEB WG wants to only place a suitable warning about t= he
> need, and indicate future forthcoming specification or if we hold this=
> document up until this solution is available?
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------=
> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Phone=C2=A0 +46 10 7148287
> F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=

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

--001a1146d19e2878c1053902f74c-- From nobody Mon Aug 1 13:45:49 2016 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 EAFDC12D8E8; Mon, 1 Aug 2016 13:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=Kkj0iNsK; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=W031w3qH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCjdH2jsv0f9; Mon, 1 Aug 2016 13:45:42 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1D012DA20; Mon, 1 Aug 2016 13:45:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 958CA2067C; Mon, 1 Aug 2016 16:45:41 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 01 Aug 2016 16:45:41 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=AFDFX +K994eFkQzLno3EubiSf7o=; b=Kkj0iNsK3qNNSa6hR8fPHtWusEVsNOvlidqv2 QwitDmgBLoRKFvlEDQ5p/zKOfezTFJ7pipxeYkPO3b0yGU+olje1/Nt6ACw5EyBB ObMn4BjwVTX72p6My3c/sYwQ1Zk5evzUlCHVFkurdeq6RLK28N7VzQVXXttJaoAf HCCOeU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=AFDFX+K994eFkQzLno3EubiSf7o=; b=W031w 3qHT2TZS9qi1YBkijLqbNeOPe+jiUkIHkDGS0pgGgIjTrInbhRzm7ymoJvY9mbHy iGwroxMasd++SZemN1UlsrpG5tGY8zrFWCdCEV+WeX6NAD5CoR+wV2DMuAM7ES4L vN5az9XUwNP8Xy2ZU/x83stEu0onkexT1dH2mk= X-Sasl-enc: u6f5Puchf4HaGcuZCVucZV6HoBma5Y5EofE3k2dExM6f 1470084341 Received: from dhcp-171-68-20-97.cisco.com (dhcp-171-68-20-97.cisco.com [171.68.20.97]) by mail.messagingengine.com (Postfix) with ESMTPA id C58CAF29DA; Mon, 1 Aug 2016 16:45:40 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AE2B08F5-CFBA-4038-8C8C-BCAF818E7229" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 1 Aug 2016 13:45:40 -0700 Message-Id: <0915F1AF-30A8-46D4-A073-BD1FC4A06FDC@cooperw.in> References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Black, David" , RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 01 Aug 2016 20:45:45 -0000 --Apple-Mail=_AE2B08F5-CFBA-4038-8C8C-BCAF818E7229 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Spencer, > On Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, all, >=20 > On Thu, Jul 14, 2016 at 4:13 PM, Black, David > wrote: > Magnus, >=20 > I think that's a fine suggestion. I think the next step is: >=20 > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in = draft-ietf-rtcweb-transports > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about = the > > need, and indicate future forthcoming specification or if we hold = this > > document up until this solution is available? >=20 > I'll attend the Thu RTCWEB session in Berlin to see how this comes = out, > after which it should be straightforward for the draft authors and = yours > truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos = will > need. >=20 > I'm just following up on this because we have = draft-ietf-rtcweb-transports on the telechat agenda this week, and I = didn't see a discussion on this topic in the RTCWeb agenda (or in poking = around for minutes, jabber, etherpad, etc).=20 Here is the relevant bit from the RTCWEB minutes: DSCP Black-holing Issue David Black (TSVWG co-chair) presented the DSCP black-hole issue with = -rtcweb-transports = draft = that was recently discussed on the list. This issue needs to be solved = and described, even though both -rtcweb-transports and the referenced = draft-ietf-tsvwg-rtcweb-qos has gone through IESG review. Magnus = Westerlund has suggested a solution to the list, but what should the = -rtcweb-transports draft say about DSCP black-holing and the possibility = to use ICE to avoid it? The WG discussed this and concluded that the issue should be described = by the -rtcweb-transports draft. Ted Hardie summarized the discussion by = suggesting a text formulation for a resolution that seemed acceptable to = the WG: =E2=80=9CWe will treat DSCP-induced path failure parallel with = other types of path failures and resolve it by using ICE restart. Note: = There is a problem with multiple DSCP codepoints on a single transport, = where one might be blocked and other might get through. In this case, = the ICE probes, using one DSCP codepoint, may succeed while others fail. = This is complex and should be warned about. A likely viable solution is = ICE restart with DSCP markings turned off, but detection requires = watching the multiple-DCSP-codepoint-using channels for differential = failures=E2=80=9D. If there are other proposals for resolution, please = contact Harald. Cullen Jennings asked David if this solution was = acceptable, but David wanted to see the text proposal. The = -rtcweb-transports author Harald Alvestrand took on the action item and = will work with Justin Uberti to send a text proposal to the list. Harald has been on holidays since the IETF meeting but will aim to get = to this before the telechat. Best, Alissa >=20 > Did it happen? Was there a resolution? >=20 > Thanks, >=20 > Spencer > =20 > Thanks, --David >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com = ] > > Sent: Thursday, July 14, 2016 4:53 AM > > To: Cullen Jennings (fluffy); Black, David > > Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org = > > Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ? > > > > Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): > > > > > > short answer here but as David suggested =E2=80=A6 some = implementation use > > > the STUN packets in ICE or just in WebRTC style liveness tests = to > > > do the tests of if a given DSCP works or not. In general ICE is a > > > good tool to take a bunch of possible paths, test which work, and > > > select the best. > > > > I do agree that how you do the path checks when setting DSCP values = !=3D 0 > > is dependent on the context. For the WebRTC I do agree doing checks > > using ICE is quite reasonable. > > > > We already have similar path testing usages of ICE in the ECN for = RTP > > specification (RFC6679), see Section 7.2.1. I will note that taking = this > > as blueprint for DSCP testing, what is needed clearly requires a new > > separate specification. The components needs are: 1) A new STUN > > parameter to request the ICE peer to echo the DSCP field value = received. > > 2) A ICE capability parameter to be used in signalling negotiations = to > > determine capability for this feature. 3) Behaviour specification on = how > > to test values and interpret responses. This include things like if = one > > should actually establish multiple candidate pairs one with DSCP = testing > > and one without? > > > > So the question here is how to proceed with this issue. So I would > > suggest the following way forward. > > > > 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends = the > > user to apply path verification methods but don't specify them. > > > > 2. Someone takes on the task to write a DSCP path verification = extension > > to ICE. > > > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in = draft-ietf-rtcweb-transports > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about = the > > need, and indicate future forthcoming specification or if we hold = this > > document up until this solution is available? > > > > > > Cheers > > > > Magnus Westerlund > > > > = ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > = ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com = > > = ---------------------------------------------------------------------- >=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 --Apple-Mail=_AE2B08F5-CFBA-4038-8C8C-BCAF818E7229 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Spencer,

On = Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, all,

On Thu, Jul 14, 2016 at 4:13 PM, Black, David = <david.black@emc.com> = wrote:
Magnus,

I think that's a fine suggestion.   I think the next step = is:

> 3. The natural place to indicate the need/recommendation for
> implementing this functionality would be in = draft-ietf-rtcweb-transports
> (Currently in IETF LC). However, here I think we need to have a
> discussion if RTCWEB WG wants to only place a suitable warning = about the
> need, and indicate future forthcoming specification or if we hold = this
> document up until this solution is available?

I'll attend the Thu RTCWEB session in Berlin to see how this = comes out,
after which it should be straightforward for the draft authors and = yours
truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos = will
need.

I'm= just following up on this because we have draft-ietf-rtcweb-transports = on the telechat agenda this week, and I didn't see a discussion on this = topic in the RTCWeb agenda (or in poking around for minutes, jabber, = etherpad, etc). 

Here is the relevant bit from the RTCWEB = minutes:

DSCP Black-holing Issue

David = Black (TSVWG co-chair) presented the DSCP black-hole issue with -rtcweb-transports draft that was = recently discussed on the list. This issue needs to be solved and = described, even though both -rtcweb-transports and the referenced = draft-ietf-tsvwg-rtcweb-qos has gone through IESG review. Magnus = Westerlund has suggested a solution to the list, but what should the = -rtcweb-transports draft say about DSCP black-holing and the possibility = to use ICE to avoid it?

The WG discussed this and concluded that the issue = should be described by the -rtcweb-transports draft. Ted Hardie = summarized the discussion by suggesting a text formulation for a = resolution that seemed acceptable to the WG: =E2=80=9CWe will treat = DSCP-induced path failure parallel with other types of path failures and = resolve it by using ICE restart. Note: There is a problem with multiple = DSCP codepoints on a single transport, where one might be blocked and = other might get through. In this case, the ICE probes, using one DSCP = codepoint, may succeed while others fail. This is complex and should be = warned about. A likely viable solution is ICE restart with DSCP markings = turned off, but detection requires watching the = multiple-DCSP-codepoint-using channels for differential failures=E2=80=9D.= If there are other proposals for resolution, please contact Harald. = Cullen Jennings asked David if this solution was acceptable, but David = wanted to see the text proposal. The -rtcweb-transports author Harald = Alvestrand took on the action item and will work with Justin Uberti to = send a text proposal to the list.


Harald has been on holidays since the IETF meeting = but will aim to get to this before the telechat.

Best,
Alissa


Did it happen? Was there a resolution?
Thanks,

Spencer
 
Thanks, --David

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Thursday, July 14, 2016 4:53 AM
> To: Cullen Jennings (fluffy); Black, David
> Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org
> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ?
>
> Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy):
> >
> > short answer here but as David suggested =E2=80=A6  some = implementation use
> > the STUN packets in ICE  or just  in WebRTC style = liveness tests to
> > do the tests of if a given DSCP works or not. In general ICE = is a
> > good tool to take a bunch of possible paths, test which work, = and
> > select the best.
>
> I do agree that how you do the path checks when setting DSCP values = !=3D 0
> is dependent on the context. For the WebRTC I do agree doing = checks
> using ICE is quite reasonable.
>
> We already have similar path testing usages of ICE in the ECN for = RTP
> specification (RFC6679), see Section 7.2.1. I will note that taking = this
> as blueprint for DSCP testing, what is needed clearly requires a = new
> separate specification. The components needs are: 1) A new STUN
> parameter to request the ICE peer to echo the DSCP field value = received.
> 2) A ICE capability parameter to be used in signalling negotiations = to
> determine capability for this feature. 3) Behaviour specification = on how
> to test values and interpret responses. This include things like if = one
> should actually establish multiple candidate pairs one with DSCP = testing
> and one without?
>
> So the question here is how to proceed with this issue. So I = would
> suggest the following way forward.
>
> 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends = the
> user to apply path verification methods but don't specify them.
>
> 2. Someone takes on the task to write a DSCP path verification = extension
> to ICE.
>
> 3. The natural place to indicate the need/recommendation for
> implementing this functionality would be in = draft-ietf-rtcweb-transports
> (Currently in IETF LC). However, here I think we need to have a
> discussion if RTCWEB WG wants to only place a suitable warning = about the
> need, and indicate future forthcoming specification or if we hold = this
> document up until this solution is available?
>
>
> Cheers
>
> Magnus Westerlund
>
> = ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> = ----------------------------------------------------------------------
> Ericsson AB                =  | Phone  +46 10 7148287
> F=C3=A4r=C3=B6gatan 6            =      | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> = ----------------------------------------------------------------------

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

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

= --Apple-Mail=_AE2B08F5-CFBA-4038-8C8C-BCAF818E7229-- From nobody Mon Aug 1 15:12:31 2016 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 A35ED12D9AA; Mon, 1 Aug 2016 15:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=fj3DglkY; dkim=pass (1024-bit key) header.d=rsa.com header.b=RurdnPwZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NH67OlatuTjQ; Mon, 1 Aug 2016 15:12:27 -0700 (PDT) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 10D5712D922; Mon, 1 Aug 2016 15:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1470089547; x=1501625547; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kZPTH/edjl4JF7sYYVdW7RhvWv8PecR/AxRrg6pIUZI=; b=fj3DglkYIoY6zB6OUeHDU3pYl9MIIn1du4f2487//S57TG7rjNK9ED2K DYZfdX+vg7QeoEK2rpszMu4rtTxkc1ijyrO/oQmtfCwLooJ9VgP4ogVG/ sfghZIVuYiR549wkZ4iRG5A2nDjOpqJwRiZPF8d3T5U166unF5XjMMId5 8=; Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2016 03:12:25 +0500 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u71MCN1s017313 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 1 Aug 2016 18:12:24 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com u71MCN1s017313 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1470089544; bh=waD71DKY2mEwon3ATGuzAIyx6ys=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=RurdnPwZe9FYT2sOVFECc8mddPn84Ms6Hneouq2dvvkaL19tKnIP4dCcrbE/eoIbX Dt1dr4hamQcpTrKLHlFk1sI+WgN7ecMzZHH3nqMZGVrzu7OHJLZrCkm/FHoxk+VNmW fPAPizyMvXXBO6WfVuVV6/2sMV/GSDyeTGRvABX0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com u71MCN1s017313 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 1 Aug 2016 18:11:05 -0400 Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u71MC4mR024135 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 1 Aug 2016 18:12:04 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0266.001; Mon, 1 Aug 2016 18:12:04 -0400 From: "Black, David" To: Alissa Cooper , Spencer Dawkins at IETF Thread-Topic: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? Thread-Index: AQHR6/x+Yfnf52M+gEetQ5PAz44zZ6A01mkA///TD4A= Date: Mon, 1 Aug 2016 22:12:03 +0000 Message-ID: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> <0915F1AF-30A8-46D4-A073-BD1FC4A06FDC@cooperw.in> In-Reply-To: <0915F1AF-30A8-46D4-A073-BD1FC4A06FDC@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F61C852MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 01 Aug 2016 22:12:30 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F61C852MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGUgLXJ0Y3dlYi10cmFuc3BvcnRzIGF1dGhvciBIYXJhbGQgQWx2ZXN0cmFuZCB0b29rIG9u IHRoZSBhY3Rpb24gaXRlbSBhbmQgd2lsbCB3b3JrIHdpdGggSnVzdGluIFViZXJ0aSB0byBzZW5k IGEgdGV4dCBwcm9wb3NhbCB0byB0aGUgbGlzdC4NCkFuZCB3aGVuIHRoYXQgdGV4dCBhcHBlYXJz LCB3ZSBjYW4gZmlndXJlIG91dCB0aGUgd29yZGluZyAocHJvYmFibHkgYSBzaG9ydCBzZW50ZW5j ZSkgdG8gYWRkIHRvIHRoZSB0c3Z3Zy1ydGN3ZWItcW9zIGRyYWZ0IHRvIHBvaW50IHRvIGl0IG92 ZXIgaW4gdGhlIHJ0Y3dlYi10cmFuc3BvcnRzIGRyYWZ0Lg0KDQpUaGFua3MsIC0tRGF2aWQNCg0K RnJvbTogQWxpc3NhIENvb3BlciBbbWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KU2VudDogTW9u ZGF5LCBBdWd1c3QgMDEsIDIwMTYgNDo0NiBQTQ0KVG86IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRG DQpDYzogQmxhY2ssIERhdmlkOyBSVENXZWIgSUVURjsgdHN2d2dAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBbdHN2d2ddIEZhbGwtYmFjayB0byBEU0NQIDAgaW4gZHJhZnQtaWV0Zi10 c3Z3Zy1ydGN3ZWItcW9zID8NCg0KSGkgU3BlbmNlciwNCg0KT24gQXVnIDEsIDIwMTYsIGF0IDY6 NTYgQU0sIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWls LmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGks IGFsbCwNCg0KT24gVGh1LCBKdWwgMTQsIDIwMTYgYXQgNDoxMyBQTSwgQmxhY2ssIERhdmlkIDxk YXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj4gd3JvdGU6DQpN YWdudXMsDQoNCkkgdGhpbmsgdGhhdCdzIGEgZmluZSBzdWdnZXN0aW9uLiAgIEkgdGhpbmsgdGhl IG5leHQgc3RlcCBpczoNCg0KPiAzLiBUaGUgbmF0dXJhbCBwbGFjZSB0byBpbmRpY2F0ZSB0aGUg bmVlZC9yZWNvbW1lbmRhdGlvbiBmb3INCj4gaW1wbGVtZW50aW5nIHRoaXMgZnVuY3Rpb25hbGl0 eSB3b3VsZCBiZSBpbiBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzDQo+IChDdXJyZW50bHkg aW4gSUVURiBMQykuIEhvd2V2ZXIsIGhlcmUgSSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgYQ0KPiBk aXNjdXNzaW9uIGlmIFJUQ1dFQiBXRyB3YW50cyB0byBvbmx5IHBsYWNlIGEgc3VpdGFibGUgd2Fy bmluZyBhYm91dCB0aGUNCj4gbmVlZCwgYW5kIGluZGljYXRlIGZ1dHVyZSBmb3J0aGNvbWluZyBz cGVjaWZpY2F0aW9uIG9yIGlmIHdlIGhvbGQgdGhpcw0KPiBkb2N1bWVudCB1cCB1bnRpbCB0aGlz IHNvbHV0aW9uIGlzIGF2YWlsYWJsZT8NCg0KSSdsbCBhdHRlbmQgdGhlIFRodSBSVENXRUIgc2Vz c2lvbiBpbiBCZXJsaW4gdG8gc2VlIGhvdyB0aGlzIGNvbWVzIG91dCwNCmFmdGVyIHdoaWNoIGl0 IHNob3VsZCBiZSBzdHJhaWdodGZvcndhcmQgZm9yIHRoZSBkcmFmdCBhdXRob3JzIGFuZCB5b3Vy cw0KdHJ1bHkgdG8gd3JpdGUgdGhlIHNlbnRlbmNlIG9yIHR3byB0aGF0IGRyYWZ0LWlldGYtdHN2 d2ctcnRjd2ViLXFvcyB3aWxsDQpuZWVkLg0KDQpJJ20ganVzdCBmb2xsb3dpbmcgdXAgb24gdGhp cyBiZWNhdXNlIHdlIGhhdmUgZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cyBvbiB0aGUgdGVs ZWNoYXQgYWdlbmRhIHRoaXMgd2VlaywgYW5kIEkgZGlkbid0IHNlZSBhIGRpc2N1c3Npb24gb24g dGhpcyB0b3BpYyBpbiB0aGUgUlRDV2ViIGFnZW5kYSAob3IgaW4gcG9raW5nIGFyb3VuZCBmb3Ig bWludXRlcywgamFiYmVyLCBldGhlcnBhZCwgZXRjKS4NCg0KSGVyZSBpcyB0aGUgcmVsZXZhbnQg Yml0IGZyb20gdGhlIFJUQ1dFQiBtaW51dGVzOg0KDQpEU0NQIEJsYWNrLWhvbGluZyBJc3N1ZQ0K RGF2aWQgQmxhY2sgKFRTVldHIGNvLWNoYWlyKSBwcmVzZW50ZWQgdGhlIERTQ1AgYmxhY2staG9s ZSBpc3N1ZSB3aXRoIC1ydGN3ZWItdHJhbnNwb3J0czxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLz4gZHJhZnQgdGhhdCB3YXMgcmVj ZW50bHkgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0LiBUaGlzIGlzc3VlIG5lZWRzIHRvIGJlIHNvbHZl ZCBhbmQgZGVzY3JpYmVkLCBldmVuIHRob3VnaCBib3RoIC1ydGN3ZWItdHJhbnNwb3J0cyBhbmQg dGhlIHJlZmVyZW5jZWQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIGhhcyBnb25lIHRocm91 Z2ggSUVTRyByZXZpZXcuIE1hZ251cyBXZXN0ZXJsdW5kIGhhcyBzdWdnZXN0ZWQgYSBzb2x1dGlv biB0byB0aGUgbGlzdCwgYnV0IHdoYXQgc2hvdWxkIHRoZSAtcnRjd2ViLXRyYW5zcG9ydHMgZHJh ZnQgc2F5IGFib3V0IERTQ1AgYmxhY2staG9saW5nIGFuZCB0aGUgcG9zc2liaWxpdHkgdG8gdXNl IElDRSB0byBhdm9pZCBpdD8NClRoZSBXRyBkaXNjdXNzZWQgdGhpcyBhbmQgY29uY2x1ZGVkIHRo YXQgdGhlIGlzc3VlIHNob3VsZCBiZSBkZXNjcmliZWQgYnkgdGhlIC1ydGN3ZWItdHJhbnNwb3J0 cyBkcmFmdC4gVGVkIEhhcmRpZSBzdW1tYXJpemVkIHRoZSBkaXNjdXNzaW9uIGJ5IHN1Z2dlc3Rp bmcgYSB0ZXh0IGZvcm11bGF0aW9uIGZvciBhIHJlc29sdXRpb24gdGhhdCBzZWVtZWQgYWNjZXB0 YWJsZSB0byB0aGUgV0c6IOKAnFdlIHdpbGwgdHJlYXQgRFNDUC1pbmR1Y2VkIHBhdGggZmFpbHVy ZSBwYXJhbGxlbCB3aXRoIG90aGVyIHR5cGVzIG9mIHBhdGggZmFpbHVyZXMgYW5kIHJlc29sdmUg aXQgYnkgdXNpbmcgSUNFIHJlc3RhcnQuIE5vdGU6IFRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIG11 bHRpcGxlIERTQ1AgY29kZXBvaW50cyBvbiBhIHNpbmdsZSB0cmFuc3BvcnQsIHdoZXJlIG9uZSBt aWdodCBiZSBibG9ja2VkIGFuZCBvdGhlciBtaWdodCBnZXQgdGhyb3VnaC4gSW4gdGhpcyBjYXNl LCB0aGUgSUNFIHByb2JlcywgdXNpbmcgb25lIERTQ1AgY29kZXBvaW50LCBtYXkgc3VjY2VlZCB3 aGlsZSBvdGhlcnMgZmFpbC4gVGhpcyBpcyBjb21wbGV4IGFuZCBzaG91bGQgYmUgd2FybmVkIGFi b3V0LiBBIGxpa2VseSB2aWFibGUgc29sdXRpb24gaXMgSUNFIHJlc3RhcnQgd2l0aCBEU0NQIG1h cmtpbmdzIHR1cm5lZCBvZmYsIGJ1dCBkZXRlY3Rpb24gcmVxdWlyZXMgd2F0Y2hpbmcgdGhlIG11 bHRpcGxlLURDU1AtY29kZXBvaW50LXVzaW5nIGNoYW5uZWxzIGZvciBkaWZmZXJlbnRpYWwgZmFp bHVyZXPigJ0uIElmIHRoZXJlIGFyZSBvdGhlciBwcm9wb3NhbHMgZm9yIHJlc29sdXRpb24sIHBs ZWFzZSBjb250YWN0IEhhcmFsZC4gQ3VsbGVuIEplbm5pbmdzIGFza2VkIERhdmlkIGlmIHRoaXMg c29sdXRpb24gd2FzIGFjY2VwdGFibGUsIGJ1dCBEYXZpZCB3YW50ZWQgdG8gc2VlIHRoZSB0ZXh0 IHByb3Bvc2FsLiBUaGUgLXJ0Y3dlYi10cmFuc3BvcnRzIGF1dGhvciBIYXJhbGQgQWx2ZXN0cmFu ZCB0b29rIG9uIHRoZSBhY3Rpb24gaXRlbSBhbmQgd2lsbCB3b3JrIHdpdGggSnVzdGluIFViZXJ0 aSB0byBzZW5kIGEgdGV4dCBwcm9wb3NhbCB0byB0aGUgbGlzdC4NCg0KSGFyYWxkIGhhcyBiZWVu IG9uIGhvbGlkYXlzIHNpbmNlIHRoZSBJRVRGIG1lZXRpbmcgYnV0IHdpbGwgYWltIHRvIGdldCB0 byB0aGlzIGJlZm9yZSB0aGUgdGVsZWNoYXQuDQoNCkJlc3QsDQpBbGlzc2ENCg0KDQoNCkRpZCBp dCBoYXBwZW4/IFdhcyB0aGVyZSBhIHJlc29sdXRpb24/DQoNClRoYW5rcywNCg0KU3BlbmNlcg0K DQpUaGFua3MsIC0tRGF2aWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bTxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPl0NCj4gU2VudDogVGh1cnNk YXksIEp1bHkgMTQsIDIwMTYgNDo1MyBBTQ0KPiBUbzogQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkp OyBCbGFjaywgRGF2aWQNCj4gQ2M6IFJUQ1dlYiBJRVRGOyBNaWNoYWVsIFdlbHpsOyB0c3Z3Z0Bp ZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbdHN2d2ddIFty dGN3ZWJdIEZhbGwtYmFjayB0byBEU0NQIDAgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9z ID8NCj4NCj4gRGVuIDIwMTYtMDctMTIga2wuIDE4OjE5LCBza3JldiBDdWxsZW4gSmVubmluZ3Mg KGZsdWZmeSk6DQo+ID4NCj4gPiBzaG9ydCBhbnN3ZXIgaGVyZSBidXQgYXMgRGF2aWQgc3VnZ2Vz dGVkIOKApiAgc29tZSBpbXBsZW1lbnRhdGlvbiB1c2UNCj4gPiB0aGUgU1RVTiBwYWNrZXRzIGlu IElDRSAgb3IganVzdCAgaW4gV2ViUlRDIHN0eWxlIGxpdmVuZXNzIHRlc3RzIHRvDQo+ID4gZG8g dGhlIHRlc3RzIG9mIGlmIGEgZ2l2ZW4gRFNDUCB3b3JrcyBvciBub3QuIEluIGdlbmVyYWwgSUNF IGlzIGENCj4gPiBnb29kIHRvb2wgdG8gdGFrZSBhIGJ1bmNoIG9mIHBvc3NpYmxlIHBhdGhzLCB0 ZXN0IHdoaWNoIHdvcmssIGFuZA0KPiA+IHNlbGVjdCB0aGUgYmVzdC4NCj4NCj4gSSBkbyBhZ3Jl ZSB0aGF0IGhvdyB5b3UgZG8gdGhlIHBhdGggY2hlY2tzIHdoZW4gc2V0dGluZyBEU0NQIHZhbHVl cyAhPSAwDQo+IGlzIGRlcGVuZGVudCBvbiB0aGUgY29udGV4dC4gRm9yIHRoZSBXZWJSVEMgSSBk byBhZ3JlZSBkb2luZyBjaGVja3MNCj4gdXNpbmcgSUNFIGlzIHF1aXRlIHJlYXNvbmFibGUuDQo+ DQo+IFdlIGFscmVhZHkgaGF2ZSBzaW1pbGFyIHBhdGggdGVzdGluZyB1c2FnZXMgb2YgSUNFIGlu IHRoZSBFQ04gZm9yIFJUUA0KPiBzcGVjaWZpY2F0aW9uIChSRkM2Njc5KSwgc2VlIFNlY3Rpb24g Ny4yLjEuIEkgd2lsbCBub3RlIHRoYXQgdGFraW5nIHRoaXMNCj4gYXMgYmx1ZXByaW50IGZvciBE U0NQIHRlc3RpbmcsIHdoYXQgaXMgbmVlZGVkIGNsZWFybHkgcmVxdWlyZXMgYSBuZXcNCj4gc2Vw YXJhdGUgc3BlY2lmaWNhdGlvbi4gVGhlIGNvbXBvbmVudHMgbmVlZHMgYXJlOiAxKSBBIG5ldyBT VFVODQo+IHBhcmFtZXRlciB0byByZXF1ZXN0IHRoZSBJQ0UgcGVlciB0byBlY2hvIHRoZSBEU0NQ IGZpZWxkIHZhbHVlIHJlY2VpdmVkLg0KPiAyKSBBIElDRSBjYXBhYmlsaXR5IHBhcmFtZXRlciB0 byBiZSB1c2VkIGluIHNpZ25hbGxpbmcgbmVnb3RpYXRpb25zIHRvDQo+IGRldGVybWluZSBjYXBh YmlsaXR5IGZvciB0aGlzIGZlYXR1cmUuIDMpIEJlaGF2aW91ciBzcGVjaWZpY2F0aW9uIG9uIGhv dw0KPiB0byB0ZXN0IHZhbHVlcyBhbmQgaW50ZXJwcmV0IHJlc3BvbnNlcy4gVGhpcyBpbmNsdWRl IHRoaW5ncyBsaWtlIGlmIG9uZQ0KPiBzaG91bGQgYWN0dWFsbHkgZXN0YWJsaXNoIG11bHRpcGxl IGNhbmRpZGF0ZSBwYWlycyBvbmUgd2l0aCBEU0NQIHRlc3RpbmcNCj4gYW5kIG9uZSB3aXRob3V0 Pw0KPg0KPiBTbyB0aGUgcXVlc3Rpb24gaGVyZSBpcyBob3cgdG8gcHJvY2VlZCB3aXRoIHRoaXMg aXNzdWUuIFNvIEkgd291bGQNCj4gc3VnZ2VzdCB0aGUgZm9sbG93aW5nIHdheSBmb3J3YXJkLg0K Pg0KPiAxLiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MgaWRlbnRpZmllcyB0aGUgaXNzdWUg YW5kIHJlY29tbWVuZHMgdGhlDQo+IHVzZXIgdG8gYXBwbHkgcGF0aCB2ZXJpZmljYXRpb24gbWV0 aG9kcyBidXQgZG9uJ3Qgc3BlY2lmeSB0aGVtLg0KPg0KPiAyLiBTb21lb25lIHRha2VzIG9uIHRo ZSB0YXNrIHRvIHdyaXRlIGEgRFNDUCBwYXRoIHZlcmlmaWNhdGlvbiBleHRlbnNpb24NCj4gdG8g SUNFLg0KPg0KPiAzLiBUaGUgbmF0dXJhbCBwbGFjZSB0byBpbmRpY2F0ZSB0aGUgbmVlZC9yZWNv bW1lbmRhdGlvbiBmb3INCj4gaW1wbGVtZW50aW5nIHRoaXMgZnVuY3Rpb25hbGl0eSB3b3VsZCBi ZSBpbiBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzDQo+IChDdXJyZW50bHkgaW4gSUVURiBM QykuIEhvd2V2ZXIsIGhlcmUgSSB0aGluayB3ZSBuZWVkIHRvIGhhdmUgYQ0KPiBkaXNjdXNzaW9u IGlmIFJUQ1dFQiBXRyB3YW50cyB0byBvbmx5IHBsYWNlIGEgc3VpdGFibGUgd2FybmluZyBhYm91 dCB0aGUNCj4gbmVlZCwgYW5kIGluZGljYXRlIGZ1dHVyZSBmb3J0aGNvbWluZyBzcGVjaWZpY2F0 aW9uIG9yIGlmIHdlIGhvbGQgdGhpcw0KPiBkb2N1bWVudCB1cCB1bnRpbCB0aGlzIHNvbHV0aW9u IGlzIGF2YWlsYWJsZT8NCj4NCj4NCj4gQ2hlZXJzDQo+DQo+IE1hZ251cyBXZXN0ZXJsdW5kDQo+ DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVz LCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24g QUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFu IDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBT dG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t PG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIg bWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0 DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQoNCg== --_000_CE03DB3D7B45C245BCA0D243277949362F61C852MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDIN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiBDaGFy IjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5nbWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtO30NCnNwYW4uSGVhZGluZzJDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcg MiI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglm b250LXdlaWdodDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJ dGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPlRoZSAtcnRjd2ViLXRyYW5z cG9ydHMgYXV0aG9yIEhhcmFsZCBBbHZlc3RyYW5kIHRvb2sgb24gdGhlIGFjdGlvbiBpdGVtIGFu ZCB3aWxsIHdvcmsgd2l0aCBKdXN0aW4gVWJlcnRpIHRvIHNlbmQgYSB0ZXh0IHByb3Bvc2FsIHRv IHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCB3aGVuIHRoYXQgdGV4dCBhcHBl YXJzLCB3ZSBjYW4gZmlndXJlIG91dCB0aGUgd29yZGluZyAocHJvYmFibHkgYSBzaG9ydCBzZW50 ZW5jZSkgdG8gYWRkIHRvIHRoZSB0c3Z3Zy1ydGN3ZWItcW9zIGRyYWZ0IHRvIHBvaW50IHRvIGl0 IG92ZXIgaW4gdGhlIHJ0Y3dlYi10cmFuc3BvcnRzDQogZHJhZnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzLCAtLURhdmlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gQWxpc3NhIENvb3BlciBbbWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDAxLCAyMDE2IDQ6NDYgUE08YnI+DQo8Yj5U bzo8L2I+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGPGJyPg0KPGI+Q2M6PC9iPiBCbGFjaywgRGF2 aWQ7IFJUQ1dlYiBJRVRGOyB0c3Z3Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3J0Y3dlYl0gW3RzdndnXSBGYWxsLWJhY2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYtdHN2d2ct cnRjd2ViLXFvcyA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIFNwZW5jZXIsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEF1ZyAxLCAyMDE2LCBhdCA2OjU2IEFNLCBTcGVuY2VyIERhd2tpbnMg YXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29t Ij5zcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIGFsbCw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCA0OjEzIFBN LCBCbGFjaywgRGF2aWQgJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxhY2tAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFnbnVzLDxicj4NCjxicj4NCkkgdGhpbmsg dGhhdCdzIGEgZmluZSBzdWdnZXN0aW9uLiZuYnNwOyAmbmJzcDtJIHRoaW5rIHRoZSBuZXh0IHN0 ZXAgaXM6PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyAzLiBUaGUgbmF0dXJh bCBwbGFjZSB0byBpbmRpY2F0ZSB0aGUgbmVlZC9yZWNvbW1lbmRhdGlvbiBmb3I8L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyBpbXBsZW1lbnRpbmcgdGhpcyBmdW5jdGlvbmFs aXR5IHdvdWxkIGJlIGluIGRyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHM8L3NwYW4+PGJyPg0K PHNwYW4gY2xhc3M9ImdtYWlsLSI+Jmd0OyAoQ3VycmVudGx5IGluIElFVEYgTEMpLiBIb3dldmVy LCBoZXJlIEkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIGE8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImdtYWlsLSI+Jmd0OyBkaXNjdXNzaW9uIGlmIFJUQ1dFQiBXRyB3YW50cyB0byBvbmx5IHBsYWNl IGEgc3VpdGFibGUgd2FybmluZyBhYm91dCB0aGU8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Imdt YWlsLSI+Jmd0OyBuZWVkLCBhbmQgaW5kaWNhdGUgZnV0dXJlIGZvcnRoY29taW5nIHNwZWNpZmlj YXRpb24gb3IgaWYgd2UgaG9sZCB0aGlzPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJnbWFpbC0i PiZndDsgZG9jdW1lbnQgdXAgdW50aWwgdGhpcyBzb2x1dGlvbiBpcyBhdmFpbGFibGU/PC9zcGFu Pjxicj4NCjxicj4NCkknbGwgYXR0ZW5kIHRoZSBUaHUgUlRDV0VCIHNlc3Npb24gaW4gQmVybGlu IHRvIHNlZSBob3cgdGhpcyBjb21lcyBvdXQsPGJyPg0KYWZ0ZXIgd2hpY2ggaXQgc2hvdWxkIGJl IHN0cmFpZ2h0Zm9yd2FyZCBmb3IgdGhlIGRyYWZ0IGF1dGhvcnMgYW5kIHlvdXJzPGJyPg0KdHJ1 bHkgdG8gd3JpdGUgdGhlIHNlbnRlbmNlIG9yIHR3byB0aGF0IGRyYWZ0LWlldGYtdHN2d2ctcnRj d2ViLXFvcyB3aWxsPGJyPg0KbmVlZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkknbSBqdXN0IGZvbGxvd2luZyB1cCBvbiB0aGlzIGJlY2F1c2Ugd2UgaGF2 ZSBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzIG9uIHRoZSB0ZWxlY2hhdCBhZ2VuZGEgdGhp cyB3ZWVrLCBhbmQgSSBkaWRuJ3Qgc2VlIGEgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGluIHRo ZSBSVENXZWIgYWdlbmRhIChvciBpbiBwb2tpbmcgYXJvdW5kIGZvciBtaW51dGVzLCBqYWJiZXIs IGV0aGVycGFkLCBldGMpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhlcmUgaXMgdGhlIHJlbGV2YW50IGJpdCBmcm9tIHRoZSBSVENXRUIgbWludXRl czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGgyPjxzcGFuIHN0eWxlPSJjb2xv cjojMzY1RjkxIj5EU0NQIEJsYWNrLWhvbGluZyBJc3N1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvaDI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRhdmlkIEJsYWNrIChUU1ZXRyBjby1jaGFpcikgcHJl c2VudGVkIHRoZSBEU0NQIGJsYWNrLWhvbGUgaXNzdWUgd2l0aCZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMv IiB0YXJnZXQ9Il9ibGFuayI+LXJ0Y3dlYi10cmFuc3BvcnRzPC9hPiZuYnNwO2RyYWZ0DQogdGhh dCB3YXMgcmVjZW50bHkgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0LiBUaGlzIGlzc3VlIG5lZWRzIHRv IGJlIHNvbHZlZCBhbmQgZGVzY3JpYmVkLCBldmVuIHRob3VnaCBib3RoIC1ydGN3ZWItdHJhbnNw b3J0cyBhbmQgdGhlIHJlZmVyZW5jZWQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIGhhcyBn b25lIHRocm91Z2ggSUVTRyByZXZpZXcuIE1hZ251cyBXZXN0ZXJsdW5kIGhhcyBzdWdnZXN0ZWQg YSBzb2x1dGlvbiB0byB0aGUgbGlzdCwgYnV0DQogd2hhdCBzaG91bGQgdGhlIC1ydGN3ZWItdHJh bnNwb3J0cyBkcmFmdCBzYXkgYWJvdXQgRFNDUCBibGFjay1ob2xpbmcgYW5kIHRoZSBwb3NzaWJp bGl0eSB0byB1c2UgSUNFIHRvIGF2b2lkIGl0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgV0cgZGlzY3Vzc2VkIHRoaXMgYW5kIGNvbmNsdWRlZCB0aGF0IHRoZSBp c3N1ZSBzaG91bGQgYmUgZGVzY3JpYmVkIGJ5IHRoZSAtcnRjd2ViLXRyYW5zcG9ydHMgZHJhZnQu IFRlZCBIYXJkaWUgc3VtbWFyaXplZCB0aGUgZGlzY3Vzc2lvbiBieSBzdWdnZXN0aW5nIGEgdGV4 dCBmb3JtdWxhdGlvbiBmb3INCiBhIHJlc29sdXRpb24gdGhhdCBzZWVtZWQgYWNjZXB0YWJsZSB0 byB0aGUgV0c6IOKAnFdlIHdpbGwgdHJlYXQgRFNDUC1pbmR1Y2VkIHBhdGggZmFpbHVyZSBwYXJh bGxlbCB3aXRoIG90aGVyIHR5cGVzIG9mIHBhdGggZmFpbHVyZXMgYW5kIHJlc29sdmUgaXQgYnkg dXNpbmcgSUNFIHJlc3RhcnQuIE5vdGU6IFRoZXJlIGlzIGEgcHJvYmxlbSB3aXRoIG11bHRpcGxl IERTQ1AgY29kZXBvaW50cyBvbiBhIHNpbmdsZSB0cmFuc3BvcnQsIHdoZXJlIG9uZQ0KIG1pZ2h0 IGJlIGJsb2NrZWQgYW5kIG90aGVyIG1pZ2h0IGdldCB0aHJvdWdoLiBJbiB0aGlzIGNhc2UsIHRo ZSBJQ0UgcHJvYmVzLCB1c2luZyBvbmUgRFNDUCBjb2RlcG9pbnQsIG1heSBzdWNjZWVkIHdoaWxl IG90aGVycyBmYWlsLiBUaGlzIGlzIGNvbXBsZXggYW5kIHNob3VsZCBiZSB3YXJuZWQgYWJvdXQu IEEgbGlrZWx5IHZpYWJsZSBzb2x1dGlvbiBpcyBJQ0UgcmVzdGFydCB3aXRoIERTQ1AgbWFya2lu Z3MgdHVybmVkIG9mZiwgYnV0IGRldGVjdGlvbg0KIHJlcXVpcmVzIHdhdGNoaW5nIHRoZSBtdWx0 aXBsZS1EQ1NQLWNvZGVwb2ludC11c2luZyBjaGFubmVscyBmb3IgZGlmZmVyZW50aWFsIGZhaWx1 cmVz4oCdLiBJZiB0aGVyZSBhcmUgb3RoZXIgcHJvcG9zYWxzIGZvciByZXNvbHV0aW9uLCBwbGVh c2UgY29udGFjdCBIYXJhbGQuIEN1bGxlbiBKZW5uaW5ncyBhc2tlZCBEYXZpZCBpZiB0aGlzIHNv bHV0aW9uIHdhcyBhY2NlcHRhYmxlLCBidXQgRGF2aWQgd2FudGVkIHRvIHNlZSB0aGUgdGV4dCBw cm9wb3NhbC4NCiBUaGUgLXJ0Y3dlYi10cmFuc3BvcnRzIGF1dGhvciBIYXJhbGQgQWx2ZXN0cmFu ZCB0b29rIG9uIHRoZSBhY3Rpb24gaXRlbSBhbmQgd2lsbCB3b3JrIHdpdGggSnVzdGluIFViZXJ0 aSB0byBzZW5kIGEgdGV4dCBwcm9wb3NhbCB0byB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFyYWxkIGhhcyBiZWVuIG9uIGhv bGlkYXlzIHNpbmNlIHRoZSBJRVRGIG1lZXRpbmcgYnV0IHdpbGwgYWltIHRvIGdldCB0byB0aGlz IGJlZm9yZSB0aGUgdGVsZWNoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGlzc2E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGlkIGl0IGhhcHBl bj8gV2FzIHRoZXJlIGEgcmVzb2x1dGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVuY2VyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgLS1EYXZpZDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQomZ3Q7IEZyb206IE1hZ251cyBXZXN0ZXJsdW5kIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSI+bWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE0LCAyMDE2IDQ6 NTMgQU08YnI+DQomZ3Q7IFRvOiBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk7IEJsYWNrLCBEYXZp ZDxicj4NCiZndDsgQ2M6IFJUQ1dlYiBJRVRGOyBNaWNoYWVsIFdlbHpsOyA8YSBocmVmPSJtYWls dG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDog UmU6IFt0c3Z3Z10gW3J0Y3dlYl0gRmFsbC1iYWNrIHRvIERTQ1AgMCBpbiBkcmFmdC1pZXRmLXRz dndnLXJ0Y3dlYi1xb3MgPzxicj4NCiZndDs8YnI+DQomZ3Q7IERlbiAyMDE2LTA3LTEyIGtsLiAx ODoxOSwgc2tyZXYgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpOjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBzaG9ydCBhbnN3ZXIgaGVyZSBidXQgYXMgRGF2aWQgc3VnZ2VzdGVkIOKApiZu YnNwOyBzb21lIGltcGxlbWVudGF0aW9uIHVzZTxicj4NCiZndDsgJmd0OyB0aGUgU1RVTiBwYWNr ZXRzIGluIElDRSZuYnNwOyBvciBqdXN0Jm5ic3A7IGluIFdlYlJUQyBzdHlsZSBsaXZlbmVzcyB0 ZXN0cyB0bzxicj4NCiZndDsgJmd0OyBkbyB0aGUgdGVzdHMgb2YgaWYgYSBnaXZlbiBEU0NQIHdv cmtzIG9yIG5vdC4gSW4gZ2VuZXJhbCBJQ0UgaXMgYTxicj4NCiZndDsgJmd0OyBnb29kIHRvb2wg dG8gdGFrZSBhIGJ1bmNoIG9mIHBvc3NpYmxlIHBhdGhzLCB0ZXN0IHdoaWNoIHdvcmssIGFuZDxi cj4NCiZndDsgJmd0OyBzZWxlY3QgdGhlIGJlc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBkbyBh Z3JlZSB0aGF0IGhvdyB5b3UgZG8gdGhlIHBhdGggY2hlY2tzIHdoZW4gc2V0dGluZyBEU0NQIHZh bHVlcyAhPSAwPGJyPg0KJmd0OyBpcyBkZXBlbmRlbnQgb24gdGhlIGNvbnRleHQuIEZvciB0aGUg V2ViUlRDIEkgZG8gYWdyZWUgZG9pbmcgY2hlY2tzPGJyPg0KJmd0OyB1c2luZyBJQ0UgaXMgcXVp dGUgcmVhc29uYWJsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZSBhbHJlYWR5IGhhdmUgc2ltaWxh ciBwYXRoIHRlc3RpbmcgdXNhZ2VzIG9mIElDRSBpbiB0aGUgRUNOIGZvciBSVFA8YnI+DQomZ3Q7 IHNwZWNpZmljYXRpb24gKFJGQzY2NzkpLCBzZWUgU2VjdGlvbiA3LjIuMS4gSSB3aWxsIG5vdGUg dGhhdCB0YWtpbmcgdGhpczxicj4NCiZndDsgYXMgYmx1ZXByaW50IGZvciBEU0NQIHRlc3Rpbmcs IHdoYXQgaXMgbmVlZGVkIGNsZWFybHkgcmVxdWlyZXMgYSBuZXc8YnI+DQomZ3Q7IHNlcGFyYXRl IHNwZWNpZmljYXRpb24uIFRoZSBjb21wb25lbnRzIG5lZWRzIGFyZTogMSkgQSBuZXcgU1RVTjxi cj4NCiZndDsgcGFyYW1ldGVyIHRvIHJlcXVlc3QgdGhlIElDRSBwZWVyIHRvIGVjaG8gdGhlIERT Q1AgZmllbGQgdmFsdWUgcmVjZWl2ZWQuPGJyPg0KJmd0OyAyKSBBIElDRSBjYXBhYmlsaXR5IHBh cmFtZXRlciB0byBiZSB1c2VkIGluIHNpZ25hbGxpbmcgbmVnb3RpYXRpb25zIHRvPGJyPg0KJmd0 OyBkZXRlcm1pbmUgY2FwYWJpbGl0eSBmb3IgdGhpcyBmZWF0dXJlLiAzKSBCZWhhdmlvdXIgc3Bl Y2lmaWNhdGlvbiBvbiBob3c8YnI+DQomZ3Q7IHRvIHRlc3QgdmFsdWVzIGFuZCBpbnRlcnByZXQg cmVzcG9uc2VzLiBUaGlzIGluY2x1ZGUgdGhpbmdzIGxpa2UgaWYgb25lPGJyPg0KJmd0OyBzaG91 bGQgYWN0dWFsbHkgZXN0YWJsaXNoIG11bHRpcGxlIGNhbmRpZGF0ZSBwYWlycyBvbmUgd2l0aCBE U0NQIHRlc3Rpbmc8YnI+DQomZ3Q7IGFuZCBvbmUgd2l0aG91dD88YnI+DQomZ3Q7PGJyPg0KJmd0 OyBTbyB0aGUgcXVlc3Rpb24gaGVyZSBpcyBob3cgdG8gcHJvY2VlZCB3aXRoIHRoaXMgaXNzdWUu IFNvIEkgd291bGQ8YnI+DQomZ3Q7IHN1Z2dlc3QgdGhlIGZvbGxvd2luZyB3YXkgZm9yd2FyZC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyAxLiBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MgaWRlbnRp ZmllcyB0aGUgaXNzdWUgYW5kIHJlY29tbWVuZHMgdGhlPGJyPg0KJmd0OyB1c2VyIHRvIGFwcGx5 IHBhdGggdmVyaWZpY2F0aW9uIG1ldGhvZHMgYnV0IGRvbid0IHNwZWNpZnkgdGhlbS48YnI+DQom Z3Q7PGJyPg0KJmd0OyAyLiBTb21lb25lIHRha2VzIG9uIHRoZSB0YXNrIHRvIHdyaXRlIGEgRFND UCBwYXRoIHZlcmlmaWNhdGlvbiBleHRlbnNpb248YnI+DQomZ3Q7IHRvIElDRS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyAzLiBUaGUgbmF0dXJhbCBwbGFjZSB0byBpbmRpY2F0ZSB0aGUgbmVlZC9yZWNv bW1lbmRhdGlvbiBmb3I8YnI+DQomZ3Q7IGltcGxlbWVudGluZyB0aGlzIGZ1bmN0aW9uYWxpdHkg d291bGQgYmUgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0czxicj4NCiZndDsgKEN1cnJl bnRseSBpbiBJRVRGIExDKS4gSG93ZXZlciwgaGVyZSBJIHRoaW5rIHdlIG5lZWQgdG8gaGF2ZSBh PGJyPg0KJmd0OyBkaXNjdXNzaW9uIGlmIFJUQ1dFQiBXRyB3YW50cyB0byBvbmx5IHBsYWNlIGEg c3VpdGFibGUgd2FybmluZyBhYm91dCB0aGU8YnI+DQomZ3Q7IG5lZWQsIGFuZCBpbmRpY2F0ZSBm dXR1cmUgZm9ydGhjb21pbmcgc3BlY2lmaWNhdGlvbiBvciBpZiB3ZSBob2xkIHRoaXM8YnI+DQom Z3Q7IGRvY3VtZW50IHVwIHVudGlsIHRoaXMgc29sdXRpb24gaXMgYXZhaWxhYmxlPzxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDaGVlcnM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNYWdudXMg V2VzdGVybHVuZDxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFNl cnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFC L1RYTTxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgRXJpY3Nzb24gQUImbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg UGhvbmUmbmJzcDsgJiM0Mzs0NiAxMCA3MTQ4Mjg3PGJyPg0KJmd0OyBGw6Ryw7ZnYXRhbiA2Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8IE1vYmlsZSAmIzQzOzQ2IDczIDA5NDkwNzk8YnI+DQomZ3Q7IFNFLTE2NCA4MCBTdG9ja2hv bG0sIFN3ZWRlbiB8IG1haWx0bzogPGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVy aWNzc29uLmNvbSI+DQptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+PGJyPg0KJmd0 OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpy dGN3ZWJAaWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D243277949362F61C852MX307CL04corpem_-- From nobody Mon Aug 1 17:39:10 2016 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 0566E12B068; Mon, 1 Aug 2016 17:39:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160802003905.2947.87616.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2016 17:39:05 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-transports-14: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 00:39:06 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-transports-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for writing this. It's a well written document that really helps bring together the rather fragmented specifications that an implementor needs to understand. I have one minor and a few editorial comments: Minor Comments: - 4.2, 2nd to last paragraph:"Sending data over multiple 5-tuples is not supported." I am confused by this, since the last few paragraphs required support for a separate 5-tuple per media stream. That seems to be a form of sending data over multiple 5-tuples. Does this mean to distinguish "data" from "media", maybe in the in the sense of "data-channels"? - Informative References: Please consider whether the references to rtcweb-overview, RFC 4595, and RFC 7656 should be normative references. They are cited for definition of terms used in this document; if those definitions are needed to fully understand this document, they should be normative. (IMHO, these are borderline). Editorial Comments: - Please expand TURN, SSL, and ICE on first mention. - 3.4, 5th paragraph from end: "using TCP only between the endpoint and its relay" I _think_ this means the use of TCP on the hop between the endpoint and the relay and not on other hops, but some may read it as the use of TCP but not other protocols on that hop. - 4.2: There are a few instances of text of the form of "... packets...use a single DSCP code point", which I think would be more clear with s/a single/the same. From nobody Mon Aug 1 19:33:28 2016 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 C8A7312D0EA for ; Mon, 1 Aug 2016 19:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (bad RSA signature)" header.d=sdiwc.info Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW2n4lyxQfwe for ; Mon, 1 Aug 2016 19:33:25 -0700 (PDT) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 85DEB12B056 for ; Mon, 1 Aug 2016 19:33:24 -0700 (PDT) Received: (qmail 14216 invoked by uid 0); 2 Aug 2016 02:33:20 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 2 Aug 2016 02:33:20 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw4 with id S2UF1t00C2Yhrsa012UJm0; Mon, 01 Aug 2016 20:28:20 -0600 X-Authority-Analysis: v=2.1 cv=TIHWFTVa c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=7z1cN_iqozsA:10 a=N1z6yVdWAAAA:8 a=OMXp1m1dUqanHaIfPZIA:9 a=CjuIK1q_8ugA:10 a=oLxjuRFzDpwA:10 a=NWVoK91CQySWRX1oVYDe:22 a=FST94vGo_0DdB_9W1aeC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding: Content-Type:MIME-Version; bh=ku7LL5HJSPcn+ddUtCmDViv8qb4gFDQs3KHBK2dLfgY=; b=i6a/3HP7jtiVkkIqFimsUSRbTgIRfbBRJ9IoxKzhwa1yoaLAtItzccZiemrN9RA2p56xTdQi+g n3tCCdHnd10NuuYqqgV7C+D3W5ST2TjQMFQ1rL5QRZt3K2if8hrOzK; Received: from [127.0.0.1] (port=35833 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bUPRH-0005dU-3H for rtcweb@ietf.org; Mon, 01 Aug 2016 20:28:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 01 Aug 2016 20:28:09 -0600 From: Jackie Blanco To: rtcweb@ietf.org Message-ID: X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.6 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box817.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sdiwc.info X-Source-IP: 127.0.0.1 X-Exim-ID: 1bUPRH-0005dU-3H X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box817.bluehost.com) [127.0.0.1]:35833 X-Source-Auth: jackie@sdiwc.info X-Email-Count: 0 X-Source-Cap: c2Rpd2NuZXQ7c2Rpd2NuZXQ7Ym94ODE3LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [rtcweb] Extended CFP :: Fifth World Congress on Computing, Engineering and Technology :: Malaysia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 02:33:27 -0000 The Fifth World Congress on Computing, Engineering and Technology (WCET) Asia Pacific University of Technology & Innovation (A.P.U) Kuala Lumpur, Malaysia September 06-08, 2016 http://sdiwc.net/congress/wcet2016/ WCET brings together leaders from governments, NGOs, international organizations, research institutions and private sectors to discuss the cutting edge topics in the area of computing, security, digital information, green computing, and other related topics. This multi-conference event provides the opportunity for all researchers to share and promote their knowledge. The conferences: 1. The Fifth International Conference on E-Learning and E-Technologies in Education (ICEEE2016) 2. The International Conference on Data Mining, Multimedia, Image Processing and their Applications (ICDMMIPA2016) 3. The Fourth International Conference on Green Computing, Technology and Innovation (ICGCTI2016) 4. The Fourth International Conference on Technological Advances in Electrical, Electronics and Computer Engineering (TAEECE2016) 5. The Fourth International Conference on Digital Information Processing, E-Business and Cloud Computing (DIPECC2016) 6. The Third International Conference on Digital Security and Forensics (DigitalSec2016) World Congress Committees ========================== Patron: Datuk Dr Parmjit Singh CEO of the Asia Pacific University of Technology & Innovation (A.P.U) and Asia Pacific Institute of Information Technology (APIIT) General Chair: Andy Seddon Asia Pacific University of Technology and Innovation (APU), Malaysia Deputy Chair and Head of Organizing Committee: Muhammad Ehsan Rana Asia Pacific University of Technology & Innovation (A.P.U), Malaysia Extended Submission Deadline: August 10, 2016 From nobody Tue Aug 2 00:54:55 2016 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 621CA12B004; Tue, 2 Aug 2016 00:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 G5nzpXN2KNlz; Tue, 2 Aug 2016 00:54:47 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C478F12B006; Tue, 2 Aug 2016 00:54:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C36837C8EF5; Tue, 2 Aug 2016 09:54:44 +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 l9VeZZ_SVNV9; Tue, 2 Aug 2016 09:54:43 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:a4fe:4267:cbb1:50be] (unknown [IPv6:2001:470:de0a:1:a4fe:4267:cbb1:50be]) by mork.alvestrand.no (Postfix) with ESMTPSA id DB3B67C8EF4; Tue, 2 Aug 2016 09:54:42 +0200 (CEST) To: Ben Campbell , The IESG References: <20160802003905.2947.87616.idtracker@ietfa.amsl.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <57A051C1.9070705@alvestrand.no> Date: Tue, 2 Aug 2016 09:54:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160802003905.2947.87616.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-transports-14: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 07:54:49 -0000 Thanks for the review! Den 02. aug. 2016 02:39, skrev Ben Campbell: > Ben Campbell has entered the following ballot position for > draft-ietf-rtcweb-transports-14: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for writing this. It's a well written document that really helps > bring together the rather fragmented specifications that an implementor > needs to understand. I have one minor and a few editorial comments: > > Minor Comments: > > - 4.2, 2nd to last paragraph:"Sending data over multiple 5-tuples is not > supported." > I am confused by this, since the last few paragraphs required support for > a separate 5-tuple per media stream. That seems to be a form of sending > data over multiple 5-tuples. Does this mean to distinguish "data" from > "media", maybe in the in the sense of "data-channels"? Yes, that's the intention. Sending data-channel data (that is, not "media") over multiple 5-tuples is not supported. Filed as #27 > > - Informative References: > Please consider whether the references to rtcweb-overview, RFC 4595, and > RFC 7656 should be normative references. They are cited for definition of > terms used in this document; if those definitions are needed to fully > understand this document, they should be normative. (IMHO, these are > borderline). Filed as #28. Earlier discussions have shown a preference for a) keeping terminology in -overview, and b) keeping references to -overview informational, to avoid the "all must be done before anything is done" problem. Treating definitions consistently seems reasonable to me. Agree that it's borderline. Advice sought. > > Editorial Comments: > > - Please expand TURN, SSL, and ICE on first mention. > > - 3.4, 5th paragraph from end: "using TCP only between the endpoint and > its relay" > I _think_ this means the use of TCP on the hop between the endpoint and > the relay and not on other hops, but some may read it as the use of TCP > but not other protocols on that hop. > > - 4.2: There are a few instances of text of the form of "... > packets...use a single DSCP code point", which I think would be more > clear with s/a single/the same. > Editorials filed as #29. The reason to use "a single" is to avoid the misinterpretation of "the same" as "the same as in a previous paragraph", which may be an issue with the TCP paragraph, but not with the SCTP paragraph. Language should be consistent between the two. > From nobody Tue Aug 2 01:23:31 2016 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 C478212B043 for ; Tue, 2 Aug 2016 01:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 SEBfWSSyYbwu for ; Tue, 2 Aug 2016 01:23:27 -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 478F212B004 for ; Tue, 2 Aug 2016 01:23:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 971627C8EF8 for ; Tue, 2 Aug 2016 10:23:25 +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 Z90EsOTX81dz for ; Tue, 2 Aug 2016 10:23:24 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:a4fe:4267:cbb1:50be] (unknown [IPv6:2001:470:de0a:1:a4fe:4267:cbb1:50be]) by mork.alvestrand.no (Postfix) with ESMTPSA id 9B6607C8EF7 for ; Tue, 2 Aug 2016 10:23:24 +0200 (CEST) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: <57A0587C.9090102@alvestrand.no> Date: Tue, 2 Aug 2016 10:23:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Fix for DSCP bleaching issue suggested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 08:23:29 -0000 My proposed text for the DSCP blocking/bleaching issue is here: https://github.com/rtcweb-wg/rtcweb-transport/pull/30 Note that this differs from what was said at the IETF meeting - after considering, I didn't see a reason to recommend ICE restart. The text does not contain MUST or SHOULD. This is implementation advice. Is this approprate, given the current state of our knowledge of the issue? Diff: @@ -344,6 +344,18 @@ of packets with certain DSCP markings. The detection of these conditions is implementation dependent. + A particularly hard problem is when one media transport uses + multiple DSCP code points, where one may be blocked and another may be + allowed. This is allowed for video in . Implementations need to diagnose + this scenario; one possible implementation is to send initial ICE + probes with DSCP 0, and send ICE probes on all the DSCP code points + that are intended to be used once a candidate pair has been selected. + If one or more of the DSCP-marked probes fail, the sender will switch + the transport to using DSCP 0. This can be carried out simultaneously + with the initial media traffic; on failure, the initial data may need + to be resent. + All packets carrying data from the SCTP association supporting the data channels MUST use a single DSCP code point. The code point used SHOULD be that recommended by 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 D85D112B041 for ; Tue, 2 Aug 2016 03:43:57 -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 Jkm1PRxuKsoT for ; Tue, 2 Aug 2016 03:43:56 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29E512D504 for ; Tue, 2 Aug 2016 03:43:55 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id o80so283620869wme.1 for ; Tue, 02 Aug 2016 03:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P7RKX8lXnNdT4RI1ukepj/eYcZ0lXHxnBLmlmHK4Xlw=; b=agyNecD++hGwGHig+raXL//Vv5NON9RwCehYAymH0hMPHEzP6apo0CHU3cWN0O/GdD 7o+mNSf/iCHnABsYJatHQ9sX2D6xQfZZwRP3c3NVHbp5yeG0/tVWswMDQ40EaPQUDKQr G17VUIO4YPldQcJC2M12DT7Or9etZ4apOGqzx+XfqG1mGyvjyGXPS6FGzay9uXU/OFeZ zjhDazKEe03DHdDYNl7xpXniMEtFVS1YInCGkzwf74uBMGS0UnMlc35n2XQ7Zvmhn8x0 Gvvxxaqq9z7H0fAmWMG/A+Pc8uA1LNmBFMmNvZTLq+JDc09/FVoSBO/5P15gQgu6hpfw KLBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P7RKX8lXnNdT4RI1ukepj/eYcZ0lXHxnBLmlmHK4Xlw=; b=b2PafbQm7+SL8CkvVGHHYCCRDjwAwbaC2rR62uzBjcUCOV4KbsUAj+VZMdAghJ3mlX sfo0/2ud1zi5e+KRH4T/mVQ0brTPxso64i/l4iirOfNGj+zoAv8Uj8CYM0WwAzNk0kkf qOoAaqF23vvmTD3vD/w1rCBl7FfkwDlbqN4zt7S24hrmVqx3pVIf2iXfuf48rymduZWY UhPCvth2AmP9EjUHDihlszEm8Tjpqobr85yk/n7MnwvQ/7BnKhY/b/P134ctTDwArrTE fS7FbmNk0X4ZCPyTsPyvwyuaDcII6QtkeuQ/sHcIsmIsyq+/WL+zd5f8slMYNyFF1bSQ QYcA== X-Gm-Message-State: AEkoousujO568bbCpLgiM+XEg+NY+2jj1Jo+pWAqhNp5PTQZc+mJ0Pt3n3rqwGOEB636/u7qEyxbJbcNb7ICYw== X-Received: by 10.194.175.38 with SMTP id bx6mr60725889wjc.47.1470134634428; Tue, 02 Aug 2016 03:43:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.167.150 with HTTP; Tue, 2 Aug 2016 03:43:53 -0700 (PDT) In-Reply-To: <57A0587C.9090102@alvestrand.no> References: <57A0587C.9090102@alvestrand.no> From: Martin Thomson Date: Tue, 2 Aug 2016 20:43:53 +1000 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fix for DSCP bleaching issue suggested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 10:43:58 -0000 http://www.dictionary.com/browse/resent - I know what you mean, of course. Presumably if DSCP 0 passes, but probes with DSCP N fails, only traffic that was intended to be sent with DSCP N would be sent with DSCP 0. If DSCP M succeeds, then you could continue to use that; your text implies otherwise. You might like to point out that switching DSCP marking mid-flow can have negative effects on things like congestion controllers and loss recovery. On 2 August 2016 at 18:23, Harald Alvestrand wrote: > My proposed text for the DSCP blocking/bleaching issue is here: > > https://github.com/rtcweb-wg/rtcweb-transport/pull/30 > > Note that this differs from what was said at the IETF meeting - after > considering, I didn't see a reason to recommend ICE restart. > > The text does not contain MUST or SHOULD. This is implementation advice. > Is this approprate, given the current state of our knowledge of the issue? > > Diff: > > @@ -344,6 +344,18 @@ > of packets with certain DSCP markings. The detection of these > conditions is implementation dependent. > > + A particularly hard problem is when one media transport uses > + multiple DSCP code points, where one may be blocked and another > may be > + allowed. This is allowed for video in + target="I-D.ietf-tsvwg-rtcweb-qos"/>. Implementations need to > diagnose > + this scenario; one possible implementation is to send initial ICE > + probes with DSCP 0, and send ICE probes on all the DSCP code points > + that are intended to be used once a candidate pair has been > selected. > + If one or more of the DSCP-marked probes fail, the sender will > switch > + the transport to using DSCP 0. This can be carried out > simultaneously > + with the initial media traffic; on failure, the initial data > may need > + to be resent. > + > All packets carrying data from the SCTP association > supporting the > data channels MUST use a single DSCP code point. The code point > used > SHOULD be that recommended by > Comments welcome, especially if they come today! - the item is on > Thursday's telechat, and it would be nice to release a fixed version > well before the telechat. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Aug 2 04:49:09 2016 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 42E8C12D52F for ; Tue, 2 Aug 2016 04:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 MXa5knsxeESo for ; Tue, 2 Aug 2016 04:49:04 -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 36D6F12D51B for ; Tue, 2 Aug 2016 04:49:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CAFAB7C8F03 for ; Tue, 2 Aug 2016 13:49:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OAeMrbczBiF for ; Tue, 2 Aug 2016 13:49:00 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:a4fe:4267:cbb1:50be] (unknown [IPv6:2001:470:de0a:1:a4fe:4267:cbb1:50be]) by mork.alvestrand.no (Postfix) with ESMTPSA id AB0757C8F02 for ; Tue, 2 Aug 2016 13:49:00 +0200 (CEST) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: <57A088AB.3010909@alvestrand.no> Date: Tue, 2 Aug 2016 13:48:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Please review: Fixes to RTCWEB review comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 11:49:07 -0000 I believe I now have PRs covering all the issues raised during and after Last Call that were not fixed in -15. These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly editorial. Please review the PRs at https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if there are no objections, I hope to merge them early Wednesday morning CET (that's late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can use as basis for balloting on Thursday (August 4). Harald From nobody Tue Aug 2 06:40:57 2016 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 C42E712D5D5 for ; Tue, 2 Aug 2016 06:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCX_1rhuwngv for ; Tue, 2 Aug 2016 06:40:54 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0004712D5CB for ; Tue, 2 Aug 2016 06:40:53 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f6so200987721ith.0 for ; Tue, 02 Aug 2016 06:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hSWWsgKJQvYMm1+Kv/RafIuyXe4DAQSMYJ3g1TRY4dc=; b=0nO1YSIobEb8Pb+Yjy3k9hKcww/j6/CkPVoUutT/FHxzMdXtqreaYPnqTPe+umfSpS asS9k8xYXFvflhqwom76Z8C1cPDu+VSfHR+zxmETCRh2W8JJDH5sBIOlEg5pu5AtMn/7 n3Nv/Lqf4PC9ZU7jk4ddtsXwlE8OIgiUPix+ByClGqWGLu/V+MPDKgPxFo5tMlBbpLoN iNBOiZIefDz6NxETihQeJ2gZ/VepKcCYvOOil2n1GviAv7c1qRk7Jcx+XA0htzoM9Rrj 9RSxQiG7NZIBgcH2OWO76eTO5FxUKr9CCkddJlYv/1njTC+wepcoedL99KEeQ+wnpJtn +N9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hSWWsgKJQvYMm1+Kv/RafIuyXe4DAQSMYJ3g1TRY4dc=; b=MF5oNTY8cQtdHBsjg5nEXH52TtkR9UU4/nW9uy6LgwyJ4AWi8nJrvqlVyfwHRlh3Kj u8gZHYpX8NTSHRH9BkSYV0hLPKq8QBU9Kqnq3nZ1by7iGVJJvszmlTLEWsrWEKDvsu7f GlrM1bVtfp576fOISUOMZJrSt1RWRcse7xQeKA4ejsxjw+T0kfemn77KSq/LIkAxdaD1 EqWOlSPr84nQlpmUn1EG3468/D0dy0LN3r92LnPMBQtdjParhofQXYBA+RN1cNhzFeQY LRpqQocKizbdwOTwcpJBfPHUtH5yYMIdQ/hRpOu+Dpuso7rWdbhkwtOn03kcKy23a8CQ zJyw== X-Gm-Message-State: AEkoouuqfqGWwpgPj9rasZI9BDEdqhxst+HHRV2vmPiDavvtx6rSclTr3j9DVUzqRr6Wg+9gRhB0fAXZB6XwZw== X-Received: by 10.36.19.16 with SMTP id 16mr19983680itz.41.1470145253007; Tue, 02 Aug 2016 06:40:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.26 with HTTP; Tue, 2 Aug 2016 06:40:52 -0700 (PDT) In-Reply-To: <57A088AB.3010909@alvestrand.no> References: <57A088AB.3010909@alvestrand.no> From: Andy Hutton Date: Tue, 2 Aug 2016 14:40:52 +0100 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1140591a92ef14053916dd29 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please review: Fixes to RTCWEB review comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 13:40:56 -0000 --001a1140591a92ef14053916dd29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is still the issue of what to say in section 3.4 about auto-discovery of TURN servers and the conflicts between application provided, auto discovered, and configured TURN servers. Section 3.4 currently includes the statement "WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application". Previously I suggested the text: "WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application. WebRTC browsers MAY also discover TURN servers using TURN Auto-Discovery [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TURN servers provided by configuration, auto-discovery, and the application WebRTC browsers MAY implement the procedures specified in Recursively Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D. This suggestion was based on the fact that the -return- draft is I believe the only place where there is a statement about what to do about the conflict between application provided and locally configured TURN servers. Regards Andy On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand wrote: > > I believe I now have PRs covering all the issues raised during and after > Last Call that were not fixed in -15. > > These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly > editorial. > > Please review the PRs at > https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if there are > no objections, I hope to merge them early Wednesday morning CET (that's > late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can > use as basis for balloting on Thursday (August 4). > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --001a1140591a92ef14053916dd29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is still the issue of what to say in section 3.4 abo= ut auto-discovery of TURN servers and the conflicts between application pro= vided, auto discovered, and configured TURN servers.

Sec= tion 3.4 currently includes the statement "WebRTC browsers MUST support configuration of STU= N and TURN servers,=C2=A0both from browser configuration and from an application".

Previou= sly I suggested the text:

"WebRTC browsers MUST support configuratio= n of STUN and TURN servers, both from browser configuration and from an app= lication. WebRTC browsers MAY also discover TURN servers using TURN Auto-Di= scovery [draft-ietf-tram-turn-server-discovery]. To resolve conflicts betwe= en TURN servers provided by configuration, auto-discovery, and the applicat= ion WebRTC browsers MAY implement the procedures specified in Recursively E= ncapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D.
This suggestion was based on the fact that the -return- draft = is I believe the only place where there is a statement about what to do abo= ut the conflict between application provided and locally configured TURN se= rvers.

Regards
Andy

=


On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>= ;
> I believe I now have PRs covering all the issues raised during an= d after
> Last Call that were not fixed in -15.
>
> These= are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly
> = editorial.
>
> Please review the PRs at
> https://github.com/rtcweb-= wg/rtcweb-transport/pulls ASAP - if there are
> no objections, I = hope to merge them early Wednesday morning CET (that's
> late Tue= sday evening US-PT) August 3 and ship a -16 that the IESG can
> use a= s basis for balloting on Thursday (August 4).
>
> Harald
>= ;
> _______________________________________________
> rtcweb ma= iling list
> rtcweb@ietf.org> https://www= .ietf.org/mailman/listinfo/rtcweb
--001a1140591a92ef14053916dd29-- From nobody Tue Aug 2 07:43:03 2016 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 DFCB312D66D; Tue, 2 Aug 2016 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 BtG1adtmSrXX; Tue, 2 Aug 2016 07:42:55 -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 98E9A12D63E; Tue, 2 Aug 2016 07:42:55 -0700 (PDT) Received: from [10.0.1.4] (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 u72Egnt9061221 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Aug 2016 09:42:50 -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.4] From: "Ben Campbell" To: "Harald Alvestrand" Date: Tue, 02 Aug 2016 09:42:48 -0500 Message-ID: In-Reply-To: <57A051C1.9070705@alvestrand.no> References: <20160802003905.2947.87616.idtracker@ietfa.amsl.com> <57A051C1.9070705@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: rtcweb-chairs@ietf.org, rtcweb@ietf.org, The IESG , draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-transports-14: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 14:43:02 -0000 Thanks for the response. See inline: Ben. On 2 Aug 2016, at 2:54, Harald Alvestrand wrote: [...] >> >> - Informative References: >> Please consider whether the references to rtcweb-overview, RFC 4595, >> and >> RFC 7656 should be normative references. They are cited for >> definition of >> terms used in this document; if those definitions are needed to fully >> understand this document, they should be normative. (IMHO, these are >> borderline). > > > Filed as #28. Earlier discussions have shown a preference for a) > keeping > terminology in -overview, and b) keeping references to -overview > informational, to avoid the "all must be done before anything is done" > problem. > > Treating definitions consistently seems reasonable to me. Agree that > it's borderline. > Advice sought. The litmus test is whether a reader can fully understand the draft without reading the informative references. It will leave these to you and Alissa to decide whether that is the case here; I'm not going to block on this either way. > > > >> >> Editorial Comments: >> >> - Please expand TURN, SSL, and ICE on first mention. >> >> - 3.4, 5th paragraph from end: "using TCP only between the endpoint >> and >> its relay" >> I _think_ this means the use of TCP on the hop between the endpoint >> and >> the relay and not on other hops, but some may read it as the use of >> TCP >> but not other protocols on that hop. >> >> - 4.2: There are a few instances of text of the form of "... >> packets...use a single DSCP code point", which I think would be more >> clear with s/a single/the same. >> > > > Editorials filed as #29. The reason to use "a single" is to avoid the > misinterpretation of "the same" as "the same as in a previous > paragraph", which may be an issue with the TCP paragraph, but not with > the SCTP paragraph. Language should be consistent between the two. I'm okay with the current wording if there is a reason to keep it that way. From nobody Tue Aug 2 09:00:43 2016 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 C203C12D7EF for ; Tue, 2 Aug 2016 09:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 ODFCxK-EtlR2 for ; Tue, 2 Aug 2016 09:00:37 -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 2EB9612D7E1 for ; Tue, 2 Aug 2016 09:00:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5F49A7C8F17; Tue, 2 Aug 2016 18:00:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLsOe-VByN7w; Tue, 2 Aug 2016 18:00:25 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:420:37e6:fae:7038] (unknown [IPv6:2001:470:de0a:1:420:37e6:fae:7038]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1C25F7C8F16; Tue, 2 Aug 2016 18:00:25 +0200 (CEST) To: Martin Thomson References: <57A0587C.9090102@alvestrand.no> From: Harald Alvestrand Message-ID: <57A0C398.10008@alvestrand.no> Date: Tue, 2 Aug 2016 18:00:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fix for DSCP bleaching issue suggested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 16:00:40 -0000 On 08/02/2016 12:43 PM, Martin Thomson wrote: > http://www.dictionary.com/browse/resent - I know what you mean, of course. > > Presumably if DSCP 0 passes, but probes with DSCP N fails, only > traffic that was intended to be sent with DSCP N would be sent with > DSCP 0. If DSCP M succeeds, then you could continue to use that; your > text implies otherwise. The particular case I'm worried about is video with AF42 on the level-0 frames and AF43 on the level-1 frames; the congestion control works because AF43 is guaranteed to be delivered through the same queueing as AF42, just with larger drop probability (I may have the language wrong here). So if AF43 isn't making it, you want to go to DSCP 0 for both components, because otherwise they aren't in the same queue any more. If I'm right, I may need to emphasize that point. (If I'm wrong, I need to change my mind of course!) > > You might like to point out that switching DSCP marking mid-flow can > have negative effects on things like congestion controllers and loss > recovery. Yup. The effect should be less disruptive than an ICE restart, however. > > > On 2 August 2016 at 18:23, Harald Alvestrand wrote: >> My proposed text for the DSCP blocking/bleaching issue is here: >> >> https://github.com/rtcweb-wg/rtcweb-transport/pull/30 >> >> Note that this differs from what was said at the IETF meeting - after >> considering, I didn't see a reason to recommend ICE restart. >> >> The text does not contain MUST or SHOULD. This is implementation advice. >> Is this approprate, given the current state of our knowledge of the issue? >> >> Diff: >> >> @@ -344,6 +344,18 @@ >> of packets with certain DSCP markings. The detection of these >> conditions is implementation dependent. >> >> + A particularly hard problem is when one media transport uses >> + multiple DSCP code points, where one may be blocked and another >> may be >> + allowed. This is allowed for video in > + target="I-D.ietf-tsvwg-rtcweb-qos"/>. Implementations need to >> diagnose >> + this scenario; one possible implementation is to send initial ICE >> + probes with DSCP 0, and send ICE probes on all the DSCP code points >> + that are intended to be used once a candidate pair has been >> selected. >> + If one or more of the DSCP-marked probes fail, the sender will >> switch >> + the transport to using DSCP 0. This can be carried out >> simultaneously >> + with the initial media traffic; on failure, the initial data >> may need >> + to be resent. >> + >> All packets carrying data from the SCTP association >> supporting the >> data channels MUST use a single DSCP code point. The code point >> used >> SHOULD be that recommended by > >> Comments welcome, especially if they come today! - the item is on >> Thursday's telechat, and it would be nice to release a fixed version >> well before the telechat. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. From nobody Tue Aug 2 10:28:39 2016 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 2185412D82B; Tue, 2 Aug 2016 10:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho11jFXqgmME; Tue, 2 Aug 2016 10:28:34 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057BB12D821; Tue, 2 Aug 2016 10:28:34 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j12so204008619ywb.2; Tue, 02 Aug 2016 10:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wq6ROmjne9RnTk9+rh/lcuFd73XTX54EnOkDWXDJY3g=; b=QAvLvzEEXL0YSRxy/J8CNfFiTLnGctKUWi7cHuYE9Rf/QQ0bpVGWb7MqlMBeqyRQyZ vQkj/S+quZoUo/dBRthh8MUPrwu5LL4kzyHMMEk9BXDZJh+BGGVvDpNK9u1pPpStROy0 2bdE6FFKiAPiX/qGpphXAQKSBL/0lmG9PdrJdoDC6UgvVrEAkhPuKy4nu9BHEb7IcOpK hWsqWvTki2ZJdcEWXNAz7OT690fklYdVEQsmkVSjjxAsxgiTeqZijYDOnLnvzeZ1JGSI VFmCNR4lSQk8GCWGqhAUZ2N2miDLskf2HBxJaD+DyaeuGbOCNdJIP7DBAhVwKjKs5Nxn ZlAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wq6ROmjne9RnTk9+rh/lcuFd73XTX54EnOkDWXDJY3g=; b=bd+z8ee5H3tmOWoUJHedTCg6Jwe030bB03VEcLzsXJzPgkGfftlNww3RQadOIUxEVW cnGGETUVLDU6K6jDYzor6bSx1/aQxLzswbpH/13XVO2BvNb7rcWEIr6vzdXT1YCY6XIV DGrlDbgI3UjWuIpdHC0n5NxxXwFc+iLmuUjJqxu0PPJTEzy/uv6RZsiBvOPqb3HdhKpj x66Hy0jkdjI0IQrcP6kVgzuijUyn7dyAZq+06qS4nnhNZ6gV20hONpfob9lpQb6WjFOE 4I0tMAUMRQd7zH3Gi/GCIWfjn5S2n5eT8JtvMGI9yz5A46uLcYlS+PJfmF5Kd/1TJo/F Lp6Q== X-Gm-Message-State: AEkoouvTwKD+Zivib3XCTctMUFyzTQGxl4bvRNjsyEx2AYkjM7Dj04ZM3jOcEBNbncc3w/d2p0OlW2wg343jkg== X-Received: by 10.37.163.104 with SMTP id d95mr25241559ybi.132.1470158913170; Tue, 02 Aug 2016 10:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.88 with HTTP; Tue, 2 Aug 2016 10:28:32 -0700 (PDT) In-Reply-To: References: <4D9967BC-D23D-4DB9-9ABE-9DA6B15B33A8@ifi.uio.no> <09203BA7-ED00-405C-AA66-C31D411A2B11@cisco.com> <4f7acb04-6b37-0f95-3613-c127ff8b31ad@ericsson.com> <0915F1AF-30A8-46D4-A073-BD1FC4A06FDC@cooperw.in> From: Spencer Dawkins at IETF Date: Tue, 2 Aug 2016 12:28:32 -0500 Message-ID: To: "Black, David" Content-Type: multipart/alternative; boundary=94eb2c19a4f0c8737d05391a0b22 Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 17:28:37 -0000 --94eb2c19a4f0c8737d05391a0b22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Alissa and David, Thanks to both of you. I didn't see the minutes on the Proceedings page but didn't think to look for draft minutes on the mailing list. Very helpful. Spencer On Mon, Aug 1, 2016 at 5:12 PM, Black, David wrote: > > The -rtcweb-transports author Harald Alvestrand took on the action item > and will work with Justin Uberti to send a text proposal to the list. > > And when that text appears, we can figure out the wording (probably a > short sentence) to add to the tsvwg-rtcweb-qos draft to point to it over = in > the rtcweb-transports draft. > > > > Thanks, --David > > > > *From:* Alissa Cooper [mailto:alissa@cooperw.in] > *Sent:* Monday, August 01, 2016 4:46 PM > *To:* Spencer Dawkins at IETF > *Cc:* Black, David; RTCWeb IETF; tsvwg@ietf.org > *Subject:* Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in > draft-ietf-tsvwg-rtcweb-qos ? > > > > Hi Spencer, > > > > On Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, all, > > > > On Thu, Jul 14, 2016 at 4:13 PM, Black, David wrote= : > > Magnus, > > I think that's a fine suggestion. I think the next step is: > > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in draft-ietf-rtcweb-transport= s > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about th= e > > need, and indicate future forthcoming specification or if we hold this > > document up until this solution is available? > > I'll attend the Thu RTCWEB session in Berlin to see how this comes out, > after which it should be straightforward for the draft authors and yours > truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will > need. > > > > I'm just following up on this because we have draft-ietf-rtcweb-transport= s > on the telechat agenda this week, and I didn't see a discussion on this > topic in the RTCWeb agenda (or in poking around for minutes, jabber, > etherpad, etc). > > > > Here is the relevant bit from the RTCWEB minutes: > > > DSCP Black-holing Issue > > David Black (TSVWG co-chair) presented the DSCP black-hole issue with > -rtcweb-transports > draft > that was recently discussed on the list. This issue needs to be solved an= d > described, even though both -rtcweb-transports and the referenced > draft-ietf-tsvwg-rtcweb-qos has gone through IESG review. Magnus Westerlu= nd > has suggested a solution to the list, but what should the > -rtcweb-transports draft say about DSCP black-holing and the possibility = to > use ICE to avoid it? > > The WG discussed this and concluded that the issue should be described by > the -rtcweb-transports draft. Ted Hardie summarized the discussion by > suggesting a text formulation for a resolution that seemed acceptable to > the WG: =E2=80=9CWe will treat DSCP-induced path failure parallel with ot= her types > of path failures and resolve it by using ICE restart. Note: There is a > problem with multiple DSCP codepoints on a single transport, where one > might be blocked and other might get through. In this case, the ICE probe= s, > using one DSCP codepoint, may succeed while others fail. This is complex > and should be warned about. A likely viable solution is ICE restart with > DSCP markings turned off, but detection requires watching the > multiple-DCSP-codepoint-using channels for differential failures=E2=80=9D= . If there > are other proposals for resolution, please contact Harald. Cullen Jenning= s > asked David if this solution was acceptable, but David wanted to see the > text proposal. The -rtcweb-transports author Harald Alvestrand took on th= e > action item and will work with Justin Uberti to send a text proposal to t= he > list. > > > > Harald has been on holidays since the IETF meeting but will aim to get to > this before the telechat. > > > > Best, > > Alissa > > > > > > Did it happen? Was there a resolution? > > > > Thanks, > > > > Spencer > > > > Thanks, --David > > > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, July 14, 2016 4:53 AM > > To: Cullen Jennings (fluffy); Black, David > > Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org > > Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in > draft-ietf-tsvwg-rtcweb-qos ? > > > > Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): > > > > > > short answer here but as David suggested =E2=80=A6 some implementati= on use > > > the STUN packets in ICE or just in WebRTC style liveness tests to > > > do the tests of if a given DSCP works or not. In general ICE is a > > > good tool to take a bunch of possible paths, test which work, and > > > select the best. > > > > I do agree that how you do the path checks when setting DSCP values != =3D 0 > > is dependent on the context. For the WebRTC I do agree doing checks > > using ICE is quite reasonable. > > > > We already have similar path testing usages of ICE in the ECN for RTP > > specification (RFC6679), see Section 7.2.1. I will note that taking thi= s > > as blueprint for DSCP testing, what is needed clearly requires a new > > separate specification. The components needs are: 1) A new STUN > > parameter to request the ICE peer to echo the DSCP field value received= . > > 2) A ICE capability parameter to be used in signalling negotiations to > > determine capability for this feature. 3) Behaviour specification on ho= w > > to test values and interpret responses. This include things like if one > > should actually establish multiple candidate pairs one with DSCP testin= g > > and one without? > > > > So the question here is how to proceed with this issue. So I would > > suggest the following way forward. > > > > 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the > > user to apply path verification methods but don't specify them. > > > > 2. Someone takes on the task to write a DSCP path verification extensio= n > > to ICE. > > > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in draft-ietf-rtcweb-transport= s > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about th= e > > need, and indicate future forthcoming specification or if we hold this > > document up until this solution is available? > > > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > _______________________________________________ > 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 > > > --94eb2c19a4f0c8737d05391a0b22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Alissa and David,

Thanks to both of= you. I didn't see the minutes on the Proceedings page but didn't t= hink to look for draft minutes on the mailing list.

Very helpful.

Spencer

On Mon, Aug 1, 2016 at 5:12 PM, Black, D= avid <david.black@emc.com> wrote:

> The -rtcweb-transports author Harald Alvestrand took on the action i= tem and will work with Justin Uberti to send a text proposal to the list.

And when that text= appears, we can figure out the wording (probably a short sentence) to add = to the tsvwg-rtcweb-qos draft to point to it over in the rtcweb-transports draft.

=C2=A0

Thanks, --David=

=C2=A0

From: Alissa C= ooper [mailto:alissa= @cooperw.in]
Sent: Monday, August 01, 2016 4:46 PM
To: Spencer Dawkins at IETF
Cc: Black, David; RTCWeb IETF; tsvwg@ietf.org
Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvw= g-rtcweb-qos ?

=C2=A0

Hi Spencer,

=C2=A0

On Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF = <spen= cerdawkins.ietf@gmail.com> wrote:

=C2=A0

Hi, all,

=C2=A0

On Thu, Jul 14, 2016 at 4:13 PM, Black, David <david.black@emc.com<= /a>> wrote:

Magnus,

I think that's a fine suggestion.=C2=A0 =C2=A0I think the next step is:=

> 3. The natural place to indicate the need/recommendation for
> implementing this functionality would be in draft-ietf-rtcweb-tr= ansports
> (Currently in IETF LC). However, here I think we need to have a<= /span>
> discussion if RTCWEB WG wants to only place a suitable warning a= bout the
> need, and indicate future forthcoming specification or if we hol= d this
> document up until this solution is available?

I'll attend the Thu RTCWEB session in Berlin to see how this comes out,=
after which it should be straightforward for the draft authors and yours truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos will need.

=C2=A0

I'm just following up on this because we have dr= aft-ietf-rtcweb-transports on the telechat agenda this week, and I didn'= ;t see a discussion on this topic in the RTCWeb agenda (or in poking around= for minutes, jabber, etherpad, etc).=C2=A0

=C2=A0

Here is the relevant bit from the RTCWEB minutes:=

=C2=A0

DSCP Black-holing Issue<= /u>

David Black (TSVWG co-chair) presented the DSCP blac= k-hole issue with=C2=A0-rtcweb-transports=C2=A0draft that was recently discussed on the list. This issue needs to be solved and= described, even though both -rtcweb-transports and the referenced draft-ie= tf-tsvwg-rtcweb-qos has gone through IESG review. Magnus Westerlund has sug= gested a solution to the list, but what should the -rtcweb-transports draft say about DSCP black-holing and t= he possibility to use ICE to avoid it?

The WG discussed this and concluded that the issue s= hould be described by the -rtcweb-transports draft. Ted Hardie summarized t= he discussion by suggesting a text formulation for a resolution that seemed acceptable to the WG: =E2=80=9CWe will treat DSCP= -induced path failure parallel with other types of path failures and resolv= e it by using ICE restart. Note: There is a problem with multiple DSCP code= points on a single transport, where one might be blocked and other might get through. In this case, the ICE probes= , using one DSCP codepoint, may succeed while others fail. This is complex = and should be warned about. A likely viable solution is ICE restart with DS= CP markings turned off, but detection requires watching the multiple-DCSP-codepoint-using channels for different= ial failures=E2=80=9D. If there are other proposals for resolution, please = contact Harald. Cullen Jennings asked David if this solution was acceptable= , but David wanted to see the text proposal. The -rtcweb-transports author Harald Alvestrand took on the action item an= d will work with Justin Uberti to send a text proposal to the list.<= u>

=C2=A0

Harald has been on holidays since the IETF meeting b= ut will aim to get to this before the telechat.

=C2=A0

Best,

Alissa



=C2=A0

Did it happen? Was there a resolution?=

=C2=A0

Thanks,

=C2=A0

Spencer

=C2=A0

Thanks, --David


> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Thursday, July 14, 2016 4:53 AM
> To: Cullen Jennings (fluffy); Black, David
> Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org
> Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg-= rtcweb-qos ?
>
> Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy):
> >
> > short answer here but as David suggested =E2=80=A6=C2=A0 some imp= lementation use
> > the STUN packets in ICE=C2=A0 or just=C2=A0 in WebRTC style liven= ess tests to
> > do the tests of if a given DSCP works or not. In general ICE is a=
> > good tool to take a bunch of possible paths, test which work, and=
> > select the best.
>
> I do agree that how you do the path checks when setting DSCP values != =3D 0
> is dependent on the context. For the WebRTC I do agree doing checks > using ICE is quite reasonable.
>
> We already have similar path testing usages of ICE in the ECN for RTP<= br> > specification (RFC6679), see Section 7.2.1. I will note that taking th= is
> as blueprint for DSCP testing, what is needed clearly requires a new > separate specification. The components needs are: 1) A new STUN
> parameter to request the ICE peer to echo the DSCP field value receive= d.
> 2) A ICE capability parameter to be used in signalling negotiations to=
> determine capability for this feature. 3) Behaviour specification on h= ow
> to test values and interpret responses. This include things like if on= e
> should actually establish multiple candidate pairs one with DSCP testi= ng
> and one without?
>
> So the question here is how to proceed with this issue. So I would
> suggest the following way forward.
>
> 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends the=
> user to apply path verification methods but don't specify them. >
> 2. Someone takes on the task to write a DSCP path verification extensi= on
> to ICE.
>
> 3. The natural place to indicate the need/recommendation for
> implementing this functionality would be in draft-ietf-rtcweb-transpor= ts
> (Currently in IETF LC). However, here I think we need to have a
> discussion if RTCWEB WG wants to only place a suitable warning about t= he
> need, and indicate future forthcoming specification or if we hold this=
> document up until this solution is available?
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------=
> Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| Phone=C2=A0 +46 10 7148287
> F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=

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

=C2=A0

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

=C2=A0


--94eb2c19a4f0c8737d05391a0b22-- From nobody Tue Aug 2 10:36:19 2016 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 CF64A12D82E; Tue, 2 Aug 2016 10:36:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160802173617.27875.40513.idtracker@ietfa.amsl.com> Date: Tue, 02 Aug 2016 10:36:17 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-transports-14: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 02 Aug 2016 17:36:18 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-rtcweb-transports-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I noted that some comments that I agreed with have appeared during Last Call, and hope they'll be reflected in a -15. Beyond that, I had a few comments of my own, but wanted to thank the working group for producing very clear and helpful transport guidance. In this text If some of the temporary IPv6 addresses, but not all, are marked deprecated, the client SHOULD discard the deprecated addresses. I would find some explanation of why this is a SHOULD to be helpful ("if some of the addresses are deprecated, and you could discard them because you still have addresses that are not marked deprecated, why would you not discard the deprecated addresses?"). In this text In order to deal with firewalls that block all UDP traffic, the mode of TURN that uses TCP between the client and the server MUST be supported, and the mode of TURN that uses TLS over TCP between the client and the server MUST be supported. See [RFC5766] section 2.1 for details. I think MUST for both TCP and TLS over TCP is still a good requirement, but I note that RFC 5766 significantly predates RFC 7258, and wonder if it's worth mentioning the tradeoffs in selecting which to use in a pervasively monitored Internet, with RFC 7258 as a reference (RFC 5766 couldn't do that, of course). In this text For data transport over the WebRTC data channel [I-D.ietf-rtcweb-data-channel], WebRTC implementations MUST support SCTP over DTLS over ICE. This encapsulation is specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. I-D.ietf-tsvwg-sctp-dtls-encaps seems to call this "SCTP over DTLS over ICE/UDP". That would be clearer to me. I agree with There exist a number of schemes for achieving quality of service that do not depend solely on DSCP code points. Some of these schemes depend on classifying the traffic into flows based on 5-tuple (source address, source port, protocol, destination address, destination port) or 6-tuple (5-tuple + DSCP code point). Under differing conditions, it may therefore make sense for a sending application to choose any of the configurations: and the text that follows it, but I'm not understanding how a sending application would know which configuration to choose, if we're still talking about downloaded Javascript on an arbitrary browser instance (is that still accurate? If not, my apologies). Is the sending application just guessing/applying heuristics, or is there any guidance (or a reference to guidance) you can provide? From nobody Tue Aug 2 20:59:34 2016 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 9C11912D771; Tue, 2 Aug 2016 20:59:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160803035930.27802.48004.idtracker@ietfa.amsl.com> Date: Tue, 02 Aug 2016 20:59:30 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] Suresh Krishnan's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 03:59:30 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-rtcweb-transports-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for writing this draft. It really helped clarify a lot of things for me. I do have a concern though. In Section 3.3. Usage of temporary IPv6 addresses, the draft states " The IPv6 default address selection specification [RFC6724] specifies that temporary addresses [RFC4941] are to be preferred over permanent addresses." While this is technically true, this is only the seventh rule in an ordered list of eight rules. e.g. A valid permanent address would be preferred over a deprecated temporary address based on Rule 3. If a host had only a valid permanent address and a deprecated temporary address, the mechanism specified in the draft would result in no addresses being made available, whereas the permanent address would have been an acceptable choice using RFC6724. So, it is not entirely clear to me what the draft is trying to accomplish. It says " However, this rule is not completely obvious in the ICE scope. This is therefore clarified as follows:" What rule is this talking about when it says "this rule"? Similarly, it also says "When a client gathers all IPv6 addresses on a host..." but it is not clear what "client" the draft is referring to. I think if you can clarify what you want to achieve with the address selection we can work together on some replacement text. From nobody Wed Aug 3 02:43:47 2016 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 EB20712D0F8; Wed, 3 Aug 2016 02:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 ontrxsGWpTvQ; Wed, 3 Aug 2016 02:43:41 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4ED312D090; Wed, 3 Aug 2016 02:43:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 14F137C8DB5; Wed, 3 Aug 2016 11:43:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cygTT5aisLLS; Wed, 3 Aug 2016 11:43:33 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660] (unknown [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2BFFE7C8D9B; Wed, 3 Aug 2016 11:43:33 +0200 (CEST) To: Spencer Dawkins , The IESG References: <20160802173617.27875.40513.idtracker@ietfa.amsl.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <57A1BCC4.8050801@alvestrand.no> Date: Wed, 3 Aug 2016 11:43:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160802173617.27875.40513.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-transports-14: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 09:43:46 -0000 Thanks for the comments! Responses inline and on github. Den 02. aug. 2016 19:36, skrev Spencer Dawkins: > Spencer Dawkins has entered the following ballot position for > draft-ietf-rtcweb-transports-14: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I noted that some comments that I agreed with have appeared during Last > Call, and hope they'll be reflected in a -15. Beyond that, I had a few > comments of my own, but wanted to thank the working group for producing > very clear and helpful transport guidance. Thanks! > > In this text > > If some of the temporary IPv6 addresses, but not all, are marked > deprecated, the client SHOULD discard the deprecated addresses. > > I would find some explanation of why this is a SHOULD to be helpful ("if > some of the addresses are deprecated, and you could discard them because > you still have addresses that are not marked deprecated, why would you > not discard the deprecated addresses?"). > I'm attaching this comment to https://github.com/rtcweb-wg/rtcweb-transport/issues/22, since it is the same block of text. My memory (always less than trustworthy) says that people raised the issue of "what if there's an ongoing connection using a deprecated address, there's no non-deprecated useable address available, shouldn't we keep the in-use address in the pool?" (otherwise we'd lose the connection at an ICE restart, even though the address still worked) - with the response being something like "this is complicated, we'll get experience to see if this is ever a real case, but let's make it a SHOULD so that if people figure out that the problem is real, they'll not be in formal non-conformance". This is the SHOULD version that means "it's a really good idea to do this, but we're not sure we've identified all the corner cases where it's a good idea not to; in case you encounter one, go ahead and be my guest". > In this text > > In order to deal with firewalls that block all UDP traffic, the mode > of TURN that uses TCP between the client and the server MUST be > supported, and the mode of TURN that uses TLS over TCP between the > client and the server MUST be supported. See [RFC5766] section 2.1 > for details. > > I think MUST for both TCP and TLS over TCP is still a good requirement, > but I note that RFC 5766 significantly predates RFC 7258, and wonder if > it's worth mentioning the tradeoffs in selecting which to use in a > pervasively monitored Internet, with RFC 7258 as a reference (RFC 5766 > couldn't do that, of course). Filed as https://github.com/rtcweb-wg/rtcweb-transport/issues/36 RFC 5766 section 2.1 has this to say about TLS-over-TCP mode: TURN supports TLS-over-TCP transport between the client and the server because TLS provides additional security properties not provided by TURN's default digest authentication; properties that some clients may wish to take advantage of. In particular, TLS provides a way for the client to ascertain that it is talking to the correct server, and provides for confidentiality of TURN control messages. TURN does not require TLS because the overhead of using TLS is higher than that of digest authentication; for example, using TLS likely means that most application data will be doubly encrypted (once by TLS and once to ensure it is still encrypted in the UDP datagram). I thought this text was clear enough that I didn't want to try to improve on it. > > In this text > > For data transport over the WebRTC data channel > [I-D.ietf-rtcweb-data-channel], WebRTC implementations MUST support > SCTP over DTLS over ICE. This encapsulation is specified in > [I-D.ietf-tsvwg-sctp-dtls-encaps]. > > I-D.ietf-tsvwg-sctp-dtls-encaps seems to call this "SCTP over DTLS over > ICE/UDP". That would be clearer to me. I reacted violently to "ICE/UDP" when I first encountered it, and still do - because the transport might not be UDP after all, given the various options mentioned above. Not a big deal, but I feel that "ICE/UDP" is misleading. > > I agree with > > There exist a number of schemes for achieving quality of service that > do not depend solely on DSCP code points. Some of these schemes > depend on classifying the traffic into flows based on 5-tuple (source > address, source port, protocol, destination address, destination > port) or 6-tuple (5-tuple + DSCP code point). Under differing > conditions, it may therefore make sense for a sending application to > choose any of the configurations: > > and the text that follows it, but I'm not understanding how a sending > application would know which configuration to choose, if we're still > talking about downloaded Javascript on an arbitrary browser instance (is > that still accurate? If not, my apologies). > > Is the sending application just guessing/applying heuristics, or is there > any guidance (or a reference to guidance) you can provide? Filed as https://github.com/rtcweb-wg/rtcweb-transport/issues/37 I don't think we have the experience that could form the basis for guidance yet, so my suggestion is "no change". From nobody Wed Aug 3 02:58:10 2016 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 185FB12D0F5; Wed, 3 Aug 2016 02:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 qbHj11d495kf; Wed, 3 Aug 2016 02:58:07 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DAE12D0DD; Wed, 3 Aug 2016 02:58:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 98BD37C8DB5; Wed, 3 Aug 2016 11:58:05 +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 TDuBkA_t79Qf; Wed, 3 Aug 2016 11:58:04 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660] (unknown [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660]) by mork.alvestrand.no (Postfix) with ESMTPSA id 85CE97C8D9B; Wed, 3 Aug 2016 11:58:04 +0200 (CEST) To: Suresh Krishnan , The IESG References: <20160803035930.27802.48004.idtracker@ietfa.amsl.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <57A1C02C.5040507@alvestrand.no> Date: Wed, 3 Aug 2016 11:58:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160803035930.27802.48004.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org, draft-ietf-rtcweb-transports@ietf.org, rtcweb-chairs@ietf.org Subject: Re: [rtcweb] Suresh Krishnan's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 09:58:09 -0000 Thanks for the comment! I've attached this to https://github.com/rtcweb-wg/rtcweb-transport/issues/22 because it deals with the same block of text. Den 03. aug. 2016 05:59, skrev Suresh Krishnan: > In Section 3.3. Usage of temporary IPv6 addresses, the draft states > > " The IPv6 default address selection specification [RFC6724] specifies > that temporary addresses [RFC4941] are to be preferred over permanent > addresses." > > While this is technically true, this is only the seventh rule in an > ordered list of eight rules. > e.g. A valid permanent address would be preferred over a deprecated > temporary address based on Rule 3. > > If a host had only a valid permanent address and a deprecated temporary > address, the mechanism specified in the draft would result in no > addresses being made available, whereas the permanent address would have > been an acceptable choice using RFC6724. The previous fix added "non-deprecated" into the sentence. See https://github.com/rtcweb-wg/rtcweb-transport/pull/32/files > > So, it is not entirely clear to me what the draft is trying to > accomplish. It says > > " However, this rule is not completely obvious in the ICE scope. This > is therefore clarified as follows:" > > What rule is this talking about when it says "this rule"? Rule seven. The reason why it's not obvious is that ICE doesn't "prefer" addresses - it gathers a bunch of them, and then sends the whole set to its partner, where it will be tried in some order - which means that it's observable by anyone who can see the signalling. I believe rule seven was flipped in 6724 because of a concern with privacy-enhanced addresses (which are temporary); if the permanent address is tried before the temporary address, the permanent address will be exposed when it doesn't have to. In the ICE case, if it is gathered, it will be exposed; the only way to preserve privacy of the permanent address is to discard it when gathering ICE candidates. No similar privacy concern was raised for the other steps of the algorithm. > > Similarly, it also says > > "When a client gathers all IPv6 addresses on a host..." The intent is "WebRTC endpoint", as defined in -overview. I'll change the terminology. > > but it is not clear what "client" the draft is referring to. > > I think if you can clarify what you want to achieve with the address > selection we can work together on some replacement text. Is it clear enough what we wanted to accomplish? From nobody Wed Aug 3 07:25:11 2016 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 7DACF12DCA9 for ; Wed, 3 Aug 2016 07:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJXILIX96_bd for ; Wed, 3 Aug 2016 07:25:08 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3B912DDB8 for ; Wed, 3 Aug 2016 07:20:06 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id r9so228908377ywg.0 for ; Wed, 03 Aug 2016 07:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aZVlN13yreBvCnXe8oypuQlwtGe7wufAy7AP7KS7lz8=; b=hXF+HJ9VqN8Pdave8k5udyiBy/pGytqKKS74letKgVqv+Occv25hkusg5x//VpHsE1 493t4weqjlPskAQsOksUYiPvuyzmtzOWjg93s42v1+yKV54vMK7JEQOkzfGcF4of+EbO 9yasRceQvlSlZBlEikt1Ah+cR608XFc/FYowivV2QxzOkv6/yxu8ZNUAplz01HWf1rRM QyB2RZ9pb0QYnHsuR0GfP9N7CSkSgdZNuZcPzpV+3NfcIvWW5qtDW0Z3vQa5Jq1B3j6R FvAox9LZWPSIxcx4AZPEF1MBkwglhfBlfXXWiAW+4HfROXvB2+evqdupK31sYMtdGLH/ oP2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=aZVlN13yreBvCnXe8oypuQlwtGe7wufAy7AP7KS7lz8=; b=dCiisHnlw10b2m7tnQXjKC7FsIErr8d6/UOyr1xnHdYc7TKHlsU4oxBYKBpOivheDL RcRjkqT5lr0Qofh8TfQjevT+c2hZzS4Gz49hl2+fk8YIMNaH63CzIxk7wEa/z4FYxjFp t/uOnnu/e+nvoVaI3fp7K9AfQ7tRFMowLyvmpR4M428AmAMe11yfGuFcLIbj4kvPY+hG ZrT+aC0YUYJ3qvFGWhui4c0JFArnJ1sRjfBJYTk+g3DvlFC6iSiJI5OI0qW/NOOnFYug 8dYvnAetS+utXK3fXiQxtlHykOj0rM6E7cEkEe0POE/wsLoZuE6h22RsyumYj3I5CWx4 NgsQ== X-Gm-Message-State: AEkoouuGkaBkSTX+NGSBPqIoMmohnVVQvTNAi7d+9Jzp6Zn0da+SZDd8BKUQlT6Fuyy9ztVGrPhC20KdX5ZIPA== X-Received: by 10.37.75.129 with SMTP id y123mr1749090yba.61.1470234005339; Wed, 03 Aug 2016 07:20:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.33.136 with HTTP; Wed, 3 Aug 2016 07:19:44 -0700 (PDT) In-Reply-To: References: <57A088AB.3010909@alvestrand.no> From: Michael Davey Date: Wed, 3 Aug 2016 15:19:44 +0100 Message-ID: To: Andy Hutton Content-Type: multipart/alternative; boundary=94eb2c095774a005dd05392b877f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please review: Fixes to RTCWEB review comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: md84419@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:25:10 -0000 --94eb2c095774a005dd05392b877f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ...And I have previously proposed that the second instance of MAY from Andy's text be upgraded to "SHOULD .." or "are RECOMMENDED to ...". On 2 August 2016 at 14:40, Andy Hutton wrote: > There is still the issue of what to say in section 3.4 about > auto-discovery of TURN servers and the conflicts between application > provided, auto discovered, and configured TURN servers. > > Section 3.4 currently includes the statement "WebRTC browsers MUST > support configuration of STUN and TURN servers, both from browser > configuration and from an application". > > Previously I suggested the text: > > "WebRTC browsers MUST support configuration of STUN and TURN servers, > both from browser configuration and from an application. WebRTC browsers > MAY also discover TURN servers using TURN Auto-Discovery > [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TUR= N > servers provided by configuration, auto-discovery, and the application > WebRTC browsers MAY implement the procedures specified in Recursively > Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D. > > This suggestion was based on the fact that the -return- draft is I believ= e > the only place where there is a statement about what to do about the > conflict between application provided and locally configured TURN servers= . > > Regards > Andy > > > > On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand > wrote: > > > > I believe I now have PRs covering all the issues raised during and afte= r > > Last Call that were not fixed in -15. > > > > These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly > > editorial. > > > > Please review the PRs at > > https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if there are > > no objections, I hope to merge them early Wednesday morning CET (that's > > late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can > > use as basis for balloting on Thursday (August 4). > > > > Harald > > > > _______________________________________________ > > 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 > > --94eb2c095774a005dd05392b877f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
...And I have previously proposed that the second instance= of MAY from Andy's text be upgraded to "SHOULD .." or "= are RECOMMENDED to ...".
=

On 2 August 2016 = at 14:40, Andy Hutton <andyhutton.ietf@gmail.com> wr= ote:
There is still the = issue of what to say in section 3.4 about auto-discovery of TURN servers an= d the conflicts between application provided, auto discovered, and configur= ed TURN servers.

Section 3.4 currently includes the stat= ement "WebRTC bro= wsers MUST support configuration of STUN and TURN servers,=C2=A0both from browser configur= ation and from an application".

Previously I suggested the text:

"We= bRTC browsers MUST support configuration of STUN and TURN servers, both fro= m browser configuration and from an application. WebRTC browsers MAY also d= iscover TURN servers using TURN Auto-Discovery [draft-ietf-tram-turn-server= -discovery]. To resolve conflicts between TURN servers provided by configur= ation, auto-discovery, and the application WebRTC browsers MAY implement th= e procedures specified in Recursively Encapsulated TURN (RETURN) [draft-iet= f-rtcweb-return]=E2=80=9D.

This suggestion was bas= ed on the fact that the -return- draft is I believe the only place where th= ere is a statement about what to do about the conflict between application = provided and locally configured TURN servers.

Rega= rds
Andy



On Tue, Aug 2,= 2016 at 12:48 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>
>= I believe I now have PRs covering all the issues raised during and after> Last Call that were not fixed in -15.
>
> These are PR #= 30, #31, #32, #33, #34 and #35. Most of them are strictly
> editorial= .
>
> Please review the PRs at
> https://github.co= m/rtcweb-wg/rtcweb-transport/pulls ASAP - if there are
> no objec= tions, I hope to merge them early Wednesday morning CET (that's
>= late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can
&= gt; use as basis for balloting on Thursday (August 4).
>
> Hara= ld
>
> _______________________________________________
> = rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtc= web

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


--94eb2c095774a005dd05392b877f-- From nobody Wed Aug 3 07:51:35 2016 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 3B73012D5AF; Wed, 3 Aug 2016 07:51:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160803145129.6144.18245.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2016 07:51:29 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 14:51:29 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-rtcweb-transports-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to briefly chat about one aspect of this... Section 3.4: Allowing configuration of STUN/TURN servers from JS makes it easier for a calling server to track a user's call meta-data, if the JS supplied configuration is e.g. always preferred. Shouldn't a browser prefer locally configured servers if those exist and can be used? Or are there other things to be said about which STUN/TURN servers to use when there are multiple choices? (Apologies if this is handled by ICE already, I forget;-) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 3.1: Would "TURN/TLS" not be better than "TURN/SSL"? - 3.2: Would s/or its TURN server/or the peer's TURN server/ be better? From nobody Wed Aug 3 08:41:22 2016 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 AE93D12B024; Wed, 3 Aug 2016 08:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 y3zl5cVWDGXT; Wed, 3 Aug 2016 08:41:10 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB84D12B078; Wed, 3 Aug 2016 08:40:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E96607C8F40; Wed, 3 Aug 2016 17:40:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8VMEFtOEhzn; Wed, 3 Aug 2016 17:40:00 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660] (unknown [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660]) by mork.alvestrand.no (Postfix) with ESMTPSA id F324D7C8F3E; Wed, 3 Aug 2016 17:39:59 +0200 (CEST) To: Stephen Farrell , The IESG References: <20160803145129.6144.18245.idtracker@ietfa.amsl.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <57A2104F.1010504@alvestrand.no> Date: Wed, 3 Aug 2016 17:39:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160803145129.6144.18245.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 15:41:15 -0000 Den 03. aug. 2016 16:51, skrev Stephen Farrell: > Stephen Farrell has entered the following ballot position for > draft-ietf-rtcweb-transports-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I'd like to briefly chat about one aspect of this... > > Section 3.4: Allowing configuration of STUN/TURN servers > from JS makes it easier for a calling server to track a > user's call meta-data, if the JS supplied configuration is > e.g. always preferred. I'm a bit confused by this remark. Yes, doing "pc = new RTCPeerConnection({iceservers: {urls: "turn:trackserver.net"}) will cause packets to be sent to "trackserver.net" whenever the PC attempts to open a connection. What is the tracking attack that is facilitated by this ability, which isn't more simply facilitated by some variant of or its Javascript equivalent? > Shouldn't a browser prefer locally > configured servers if those exist and can be used? Or are > there other things to be said about which STUN/TURN > servers to use when there are multiple choices? (Apologies > if this is handled by ICE already, I forget;-) I have understood the lists of servers to be additive: That the browser, if provided with two lists, would attempt all of them. It would then be up to corporate policy to block access to all but the corporate, locally-configured server, if that's their desire. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 3.1: Would "TURN/TLS" not be better than "TURN/SSL"? Yes. I have changed this in https://github.com/rtcweb-wg/rtcweb-transport/pull/35. > > - 3.2: Would s/or its TURN server/or the peer's TURN > server/ be better? Yes, it would. I'll change this. Added to https://github.com/rtcweb-wg/rtcweb-transport/pull/31/files since that PR was changing the next line of the draft. From nobody Wed Aug 3 08:44:59 2016 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 1073112D696; Wed, 3 Aug 2016 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN3Up-JgT4UY; Wed, 3 Aug 2016 08:44:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2C6C12D54F; Wed, 3 Aug 2016 08:44:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 025D0BE4C; Wed, 3 Aug 2016 16:44:52 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkHQ-oX1lf-z; Wed, 3 Aug 2016 16:44:51 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A0DCBE33; Wed, 3 Aug 2016 16:44:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470239091; bh=YwpTknMd4A4Z86RHjjYp0fLDv30uHMbVHR1Cn5BOcJ8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=iwWpxo/4Ma+mYVLqSWSNCfXMPmLhHfmSO7xUQepCFYf+OcNuxtetTtKqzc8EXCCz7 iK5loQdQWSf3Eo0I8vpAASdLt+ubFfpCaGX6FWPbgpCgvvD4rJCR564XR6BhtpN5k2 xEk8kJPnjYb1g4ZqtHGMEqPv7mFn8dJzS9/lcUZA= To: Harald Alvestrand , The IESG References: <20160803145129.6144.18245.idtracker@ietfa.amsl.com> <57A2104F.1010504@alvestrand.no> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 3 Aug 2016 16:44:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57A2104F.1010504@alvestrand.no> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070603090506050400000705" Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 15:44:59 -0000 This is a cryptographically signed message in MIME format. --------------ms070603090506050400000705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 03/08/16 16:39, Harald Alvestrand wrote: > Den 03. aug. 2016 16:51, skrev Stephen Farrell: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-rtcweb-transports-14: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> I'd like to briefly chat about one aspect of this... >> >> Section 3.4: Allowing configuration of STUN/TURN servers >> from JS makes it easier for a calling server to track a >> user's call meta-data, if the JS supplied configuration is >> e.g. always preferred. >=20 > I'm a bit confused by this remark. >=20 > Yes, doing "pc =3D new RTCPeerConnection({iceservers: {urls: > "turn:trackserver.net"}) will cause packets to be sent to > "trackserver.net" whenever the PC attempts to open a connection. >=20 > What is the tracking attack that is facilitated by this ability, which > isn't more simply facilitated by some variant of src=3D"http://trackserver.net"> or its Javascript equivalent? The one I thought of is call duration if there are keep-alives. There could I guess be more meta-data visible via STUN/TURN but it seems like at least the above is a new thing that the call-server can get at, and possibly desirable (to a tracker). >=20 >> Shouldn't a browser prefer locally >> configured servers if those exist and can be used? Or are >> there other things to be said about which STUN/TURN >> servers to use when there are multiple choices? (Apologies >> if this is handled by ICE already, I forget;-) >=20 > I have understood the lists of servers to be additive: That the browser= , > if provided with two lists, would attempt all of them. It would then be= > up to corporate policy to block access to all but the corporate, > locally-configured server, if that's their desire. Ack. So I guess my discuss then comes down to whether the additional call meta-data that a call server might access via selection of it's preferred STUN/TURN servers is sufficiently worrisome to be more prescriptive in how a browser handles the various lists. Cheers, S. >=20 >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - 3.1: Would "TURN/TLS" not be better than "TURN/SSL"? >=20 > Yes. I have changed this in > https://github.com/rtcweb-wg/rtcweb-transport/pull/35. >=20 >> >> - 3.2: Would s/or its TURN server/or the peer's TURN >> server/ be better? >=20 > Yes, it would. I'll change this. >=20 > Added to https://github.com/rtcweb-wg/rtcweb-transport/pull/31/files > since that PR was changing the next line of the draft. >=20 --------------ms070603090506050400000705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDMx NTQ0NTFaMC8GCSqGSIb3DQEJBDEiBCCs7ar9ZMABJpd2tt/KLHpRnXU6Z1ah2JuCUQRIj71i azBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAQ68EXE1HATDvhEC7sBzS+XOutOZuLQLc5ojYdhUiiOjg7REcf5mBb k35xZ77OCVb+vF6CNS7F8rAK49zN7aFJTPYumHtYEwXvNBzV1fWdobObxCToyUF4WAinknnw xLBQpS6etG+tYhepuFx8D7U1Jn2WSpsC0RST1dERtiORgEUOXlUKmfajwa0dy9ajpAti/PIs eS3ULqB1XCrMEqxxsp+420t/CF2n1+J6zOl7WCvKMKryok6ajD5kY3892Rf1JY1d5xjQUt4a EipZXTIDOpUARVKOCkvltYTqnlbKpxUrXh8Dzu7ckb6fJJyk2ioyjY++Poqm5eQog+qD32fN AAAAAAAA --------------ms070603090506050400000705-- From nobody Wed Aug 3 08:59:34 2016 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 BDC5712D796; Wed, 3 Aug 2016 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 4nwUAKEc32M9; Wed, 3 Aug 2016 08:59:28 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA57212D7B7; Wed, 3 Aug 2016 08:57:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 14FEC7C8E84; Wed, 3 Aug 2016 17:57:21 +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 57DNl7vtFwmI; Wed, 3 Aug 2016 17:57:19 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660] (unknown [IPv6:2001:470:de0a:1:5591:c0a8:94e7:f660]) by mork.alvestrand.no (Postfix) with ESMTPSA id 323467C8F40; Wed, 3 Aug 2016 17:57:19 +0200 (CEST) To: Stephen Farrell , The IESG References: <20160803145129.6144.18245.idtracker@ietfa.amsl.com> <57A2104F.1010504@alvestrand.no> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <57A2145E.9020204@alvestrand.no> Date: Wed, 3 Aug 2016 17:57:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 15:59:34 -0000 Den 03. aug. 2016 17:44, skrev Stephen Farrell: > > Hiya, > > On 03/08/16 16:39, Harald Alvestrand wrote: >> Den 03. aug. 2016 16:51, skrev Stephen Farrell: >>> Stephen Farrell has entered the following ballot position for >>> draft-ietf-rtcweb-transports-14: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> I'd like to briefly chat about one aspect of this... >>> >>> Section 3.4: Allowing configuration of STUN/TURN servers >>> from JS makes it easier for a calling server to track a >>> user's call meta-data, if the JS supplied configuration is >>> e.g. always preferred. >> >> I'm a bit confused by this remark. >> >> Yes, doing "pc = new RTCPeerConnection({iceservers: {urls: >> "turn:trackserver.net"}) will cause packets to be sent to >> "trackserver.net" whenever the PC attempts to open a connection. >> >> What is the tracking attack that is facilitated by this ability, which >> isn't more simply facilitated by some variant of > src="http://trackserver.net"> or its Javascript equivalent? > > The one I thought of is call duration if there are keep-alives. > There could I guess be more meta-data visible via STUN/TURN > but it seems like at least the above is a new thing that the > call-server can get at, and possibly desirable (to a tracker). Well, you only get call duration if you get the server chosen as a TURN server, since the client won't notify the TURN server about a decision not to use an address. You can also get call duration by setting a trigger on a PeerConnection's "onstatechange" handler and firing off a query to "trackserver.net" inside that handler once the state goes to "closed". The Javascript that created the PeerConnection is able to attach pieces of itself to very many events that happen over the PeerConnection's lifetime - PeerConnections are very far away from "fire and forget". > >> >>> Shouldn't a browser prefer locally >>> configured servers if those exist and can be used? Or are >>> there other things to be said about which STUN/TURN >>> servers to use when there are multiple choices? (Apologies >>> if this is handled by ICE already, I forget;-) >> >> I have understood the lists of servers to be additive: That the browser, >> if provided with two lists, would attempt all of them. It would then be >> up to corporate policy to block access to all but the corporate, >> locally-configured server, if that's their desire. > > Ack. So I guess my discuss then comes down to whether the > additional call meta-data that a call server might access via > selection of it's preferred STUN/TURN servers is sufficiently > worrisome to be more prescriptive in how a browser handles > the various lists. The meta-data available at call setup time seems to be available to the script that's configuring the call anyway, through SDP and inspecting the state variables or stats records. This is a lot richer than anything I can see being exposed to the TURN servers that are configured from the same script by using these lists. I may have overlooked it, but I don't see the new attack. From nobody Wed Aug 3 09:00:19 2016 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 C0AC912DBCC; Wed, 3 Aug 2016 09:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP5C3xIYWPJW; Wed, 3 Aug 2016 08:59:39 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0FA12D675; Wed, 3 Aug 2016 08:57:31 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id z8so231794541ywa.1; Wed, 03 Aug 2016 08:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vdVQmkJG8YLzIFkKp/Qf//lnjghanKVE9LjzvfvsWFA=; b=aMqv9AsI+d/HPDeltXTrvTGgSvq1SEQRNgY0EG+Hry29JpgWRfCj/mSVeU8W2u3CvB fQvz+dlh2MVj+g2RBM7NcSMBIbOxXdeghoybMjz3BdWHBD7dmoVjcMO9saKzDl6JWck5 raxoEGeKAMJpcMFXyeDs/dtgtQG2s55Oe8bdxQF0+JZ2+KbSYvj7tLGTWXru656hu5AX 2IQl5bz1NWQnaWU1r1u/RCuhZh6yjK95VPrefijKsosyu++g6AjCnq90zQjCKb2K8SDM kpXs5u8YJ7HOT3pjuyokH1lK5rnfbFVjieOx6vHHEkipIW5krej6sMl1hDWF4fE+zIbn WKVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vdVQmkJG8YLzIFkKp/Qf//lnjghanKVE9LjzvfvsWFA=; b=QDtiNo5UcSlskRzgfSayA61pUZwVG2QMgm26eCPkx++Dw5AvNLRKsnOVeIQp26A3tL bqaU4CHb9RVUL8yGICqYVQ8zbNiF4/eUApiMFlgt2rDllCOOseYOUJjyDwSrnQVJwa+F d7IVlOrmbPy1boJqhHi3G4LEt7JJUzfq68bkUYJebRQ/oBDKbuKkclMcCa/TJoTtfYWr bDqabtmPCePVTI5hnrXaVDR7nrLlrrQCMULNVyOONxXHvzX69I3GuYxqoiSoc5LXR77s Pmqa11kkxe/mVSdvqjwc1bNeLQsRseQKIeCNX1fskGXnxj43r8b7fSIoY235QDDbdB8Y SunQ== X-Gm-Message-State: AEkoousDOSZoAtrMcAp0DtVIMu3pUtl3i3I+5BistMZXc1okvcOmtsUsy9i7tXQJ9XJlJAKAVxWzFIpGynJTrg== X-Received: by 10.129.82.130 with SMTP id g124mr55111095ywb.208.1470239850392; Wed, 03 Aug 2016 08:57:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.88 with HTTP; Wed, 3 Aug 2016 08:57:29 -0700 (PDT) In-Reply-To: <57A1BCC4.8050801@alvestrand.no> References: <20160802173617.27875.40513.idtracker@ietfa.amsl.com> <57A1BCC4.8050801@alvestrand.no> From: Spencer Dawkins at IETF Date: Wed, 3 Aug 2016 10:57:29 -0500 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114dc320048bd705392ce44b Archived-At: Cc: rtcweb-chairs@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-transports-14: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:00:01 -0000 --001a114dc320048bd705392ce44b Content-Type: text/plain; charset=UTF-8 Hi, Harald, On Wed, Aug 3, 2016 at 4:43 AM, Harald Alvestrand wrote: > Thanks for the comments! > > Responses inline and on github. > > Den 02. aug. 2016 19:36, skrev Spencer Dawkins: > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-rtcweb-transports-14: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I noted that some comments that I agreed with have appeared during Last > > Call, and hope they'll be reflected in a -15. Beyond that, I had a few > > comments of my own, but wanted to thank the working group for producing > > very clear and helpful transport guidance. > > Thanks! > > > > > In this text > > > > If some of the temporary IPv6 addresses, but not all, are marked > > deprecated, the client SHOULD discard the deprecated addresses. > > > > I would find some explanation of why this is a SHOULD to be helpful ("if > > some of the addresses are deprecated, and you could discard them because > > you still have addresses that are not marked deprecated, why would you > > not discard the deprecated addresses?"). > > > > I'm attaching this comment to > https://github.com/rtcweb-wg/rtcweb-transport/issues/22, since it is the > same block of text. > > My memory (always less than trustworthy) says that people raised the > issue of "what if there's an ongoing connection using a deprecated > address, there's no non-deprecated useable address available, shouldn't > we keep the in-use address in the pool?" (otherwise we'd lose the > connection at an ICE restart, even though the address still worked) - > with the response being something like "this is complicated, we'll get > experience to see if this is ever a real case, but let's make it a > SHOULD so that if people figure out that the problem is real, they'll > not be in formal non-conformance". > > This is the SHOULD version that means "it's a really good idea to do > this, but we're not sure we've identified all the corner cases where > it's a good idea not to; in case you encounter one, go ahead and be my > guest". > So, would it be correct to say, "the client SHOULD discard the deprecated addresses unless they are used in an ongoing connection"? > > > In this text > > > > In order to deal with firewalls that block all UDP traffic, the mode > > of TURN that uses TCP between the client and the server MUST be > > supported, and the mode of TURN that uses TLS over TCP between the > > client and the server MUST be supported. See [RFC5766] section 2.1 > > for details. > > > > I think MUST for both TCP and TLS over TCP is still a good requirement, > > but I note that RFC 5766 significantly predates RFC 7258, and wonder if > > it's worth mentioning the tradeoffs in selecting which to use in a > > pervasively monitored Internet, with RFC 7258 as a reference (RFC 5766 > > couldn't do that, of course). > > Filed as https://github.com/rtcweb-wg/rtcweb-transport/issues/36 > > RFC 5766 section 2.1 has this to say about TLS-over-TCP mode: > > TURN supports TLS-over-TCP transport between the client and the > server because TLS provides additional security properties not > provided by TURN's default digest authentication; properties that > some clients may wish to take advantage of. In particular, TLS > provides a way for the client to ascertain that it is talking to the > correct server, and provides for confidentiality of TURN control > messages. TURN does not require TLS because the overhead of using > TLS is higher than that of digest authentication; for example, using > TLS likely means that most application data will be doubly encrypted > (once by TLS and once to ensure it is still encrypted in the UDP > datagram). > > I thought this text was clear enough that I didn't want to try to > improve on it. I thought that text was clear, but wondered if the scales had tipped between TLS-over-TCP and TCP due to our improved understanding of pervasive monitoring. If they haven't tipped, there's no need to twiddle with the guidance. > > > > In this text > > > > For data transport over the WebRTC data channel > > [I-D.ietf-rtcweb-data-channel], WebRTC implementations MUST support > > SCTP over DTLS over ICE. This encapsulation is specified in > > [I-D.ietf-tsvwg-sctp-dtls-encaps]. > > > > I-D.ietf-tsvwg-sctp-dtls-encaps seems to call this "SCTP over DTLS over > > ICE/UDP". That would be clearer to me. > > I reacted violently to "ICE/UDP" when I first encountered it, and still > do - because the transport might not be UDP after all, given the various > options mentioned above. > > Not a big deal, but I feel that "ICE/UDP" is misleading. > I find it awesome that you are reacting to the last three letters in ICE/UDP, while I'm reacting to the first three ... but I understand your point. I guess it's even less likely to be using ICE as transport than UDP, isn't it? Of course, I also note that I'm the shepherding AD for ietf-tsvwg-sctp-dtls-encaps, and I could have had this brilliant realization a couple of years ago ... I suppose that a right answer is to leave this. > > > > > I agree with > > > > There exist a number of schemes for achieving quality of service that > > do not depend solely on DSCP code points. Some of these schemes > > depend on classifying the traffic into flows based on 5-tuple (source > > address, source port, protocol, destination address, destination > > port) or 6-tuple (5-tuple + DSCP code point). Under differing > > conditions, it may therefore make sense for a sending application to > > choose any of the configurations: > > > > and the text that follows it, but I'm not understanding how a sending > > application would know which configuration to choose, if we're still > > talking about downloaded Javascript on an arbitrary browser instance (is > > that still accurate? If not, my apologies). > > > > Is the sending application just guessing/applying heuristics, or is there > > any guidance (or a reference to guidance) you can provide? > > Filed as https://github.com/rtcweb-wg/rtcweb-transport/issues/37 > > I don't think we have the experience that could form the basis for > guidance yet, so my suggestion is "no change". > That's very reasonable. I wonder if it's worth saying that, but I'm fine if you don't make a change. Thanks! Spencer --001a114dc320048bd705392ce44b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Harald,

On Wed, Aug 3, 2016 at 4:43 AM, Harald Alvestrand <harald@al= vestrand.no> wrote:
Thanks for the comments!

Responses inline and on github.

Den 02. aug. 2016 19:36, skrev Spencer Dawkins:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-rtcweb-transports-14: Yes
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/= draft-ietf-rtcweb-transports/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I noted that some comments that I agreed with have appeared during Las= t
> Call, and hope they'll be reflected in a -15. Beyond that, I had a= few
> comments of my own, but wanted to thank the working group for producin= g
> very clear and helpful transport guidance.

Thanks!

>
> In this text
>
>=C2=A0 =C2=A0 If some of the temporary IPv6 addresses, but not all, are= marked
>=C2=A0 =C2=A0 deprecated, the client SHOULD discard the deprecated addr= esses.
>
> I would find some explanation of why this is a SHOULD to be helpful (&= quot;if
> some of the addresses are deprecated, and you could discard them becau= se
> you still have addresses that are not marked deprecated, why would you=
> not discard the deprecated addresses?").
>

I'm attaching this comment to
https://github.com/rtcweb-wg/rtcweb-transport= /issues/22, since it is the
same block of text.

My memory (always less than trustworthy) says that people raised the
issue of "what if there's an ongoing connection using a deprecated=
address, there's no non-deprecated useable address available, shouldn&#= 39;t
we keep the in-use address in the pool?" (otherwise we'd lose the<= br> connection at an ICE restart, even though the address still worked) -
with the response being something like "this is complicated, we'll= get
experience to see if this is ever a real case, but let's make it a
SHOULD so that if people figure out that the problem is real, they'll not be in formal non-conformance".

This is the SHOULD version that means "it's a really good idea to = do
this, but we're not sure we've identified all the corner cases wher= e
it's a good idea not to; in case you encounter one, go ahead and be my<= br> guest".

So, would it be correct to= say, "the client SHOULD discard the deprecated addresses unless they = are used in an ongoing connection"?
=C2=A0

> In this text
>
>=C2=A0 =C2=A0 In order to deal with firewalls that block all UDP traffi= c, the mode
>=C2=A0 =C2=A0 of TURN that uses TCP between the client and the server M= UST be
>=C2=A0 =C2=A0 supported, and the mode of TURN that uses TLS over TCP be= tween the
>=C2=A0 =C2=A0 client and the server MUST be supported.=C2=A0 See [RFC57= 66] section 2.1
>=C2=A0 =C2=A0 for details.
>
> I think MUST for both TCP and TLS over TCP is still a good requirement= ,
> but I note that RFC 5766 significantly predates RFC 7258, and wonder i= f
> it's worth mentioning the tradeoffs in selecting which to use in a=
> pervasively monitored Internet, with RFC 7258 as a reference (RFC 5766=
> couldn't do that, of course).

Filed as https://github.com/rtcweb-wg/= rtcweb-transport/issues/36

RFC 5766 section 2.1 has this to say about TLS-over-TCP mode:

=C2=A0 =C2=A0TURN supports TLS-over-TCP transport between the client and th= e
=C2=A0 =C2=A0server because TLS provides additional security properties not=
=C2=A0 =C2=A0provided by TURN's default digest authentication; properti= es that
=C2=A0 =C2=A0some clients may wish to take advantage of.=C2=A0 In particula= r, TLS
=C2=A0 =C2=A0provides a way for the client to ascertain that it is talking = to the
=C2=A0 =C2=A0correct server, and provides for confidentiality of TURN contr= ol
=C2=A0 =C2=A0messages.=C2=A0 TURN does not require TLS because the overhead= of using
=C2=A0 =C2=A0TLS is higher than that of digest authentication; for example,= using
=C2=A0 =C2=A0TLS likely means that most application data will be doubly enc= rypted
=C2=A0 =C2=A0(once by TLS and once to ensure it is still encrypted in the U= DP
=C2=A0 =C2=A0datagram).

I thought this text was clear enough that I didn't want to try to
improve on it.

I thought that text was clea= r, but wondered if the scales had tipped between TLS-over-TCP and TCP due t= o our improved understanding of pervasive monitoring. If they haven't t= ipped, there's no need to twiddle with the guidance.
=C2=A0
>=
> In this text
>
>=C2=A0 =C2=A0 For data transport over the WebRTC data channel
>=C2=A0 =C2=A0 [I-D.ietf-rtcweb-data-channel], WebRTC implementations MU= ST support
>=C2=A0 =C2=A0 SCTP over DTLS over ICE.=C2=A0 This encapsulation is spec= ified in
>=C2=A0 =C2=A0 [I-D.ietf-tsvwg-sctp-dtls-encaps].
>
> I-D.ietf-tsvwg-sctp-dtls-encaps seems to call this "SCTP over DTL= S over
> ICE/UDP". That would be clearer to me.

I reacted violently to "ICE/UDP" when I first encountered = it, and still
do - because the transport might not be UDP after all, given the various options mentioned above.

Not a big deal, but I feel that "ICE/UDP" is misleading.

I find it awesome that you are reacting to the = last three letters in ICE/UDP, while I'm reacting to the first three ..= . but I understand your point. I guess it's even less likely to be usin= g ICE as transport than UDP, isn't it?=C2=A0

O= f course, I also note that I'm the shepherding AD for ietf-tsvwg-sctp-d= tls-encaps, and I could have had this brilliant realization a couple of yea= rs ago ...=C2=A0

I suppose that a right answer is = to leave this.
=C2=A0

>
> I agree with
>
>=C2=A0 =C2=A0 There exist a number of schemes for achieving quality of = service that
>=C2=A0 =C2=A0 do not depend solely on DSCP code points.=C2=A0 Some of t= hese schemes
>=C2=A0 =C2=A0 depend on classifying the traffic into flows based on 5-t= uple (source
>=C2=A0 =C2=A0 address, source port, protocol, destination address, dest= ination
>=C2=A0 =C2=A0 port) or 6-tuple (5-tuple + DSCP code point).=C2=A0 Under= differing
>=C2=A0 =C2=A0 conditions, it may therefore make sense for a sending app= lication to
>=C2=A0 =C2=A0 choose any of the configurations:
>
> and the text that follows it, but I'm not understanding how a send= ing
> application would know which configuration to choose, if we're sti= ll
> talking about downloaded Javascript on an arbitrary browser instance (= is
> that still accurate? If not, my apologies).
>
> Is the sending application just guessing/applying heuristics, or is th= ere
> any guidance (or a reference to guidance) you can provide?

Filed as https://github.com/rtcweb-wg/= rtcweb-transport/issues/37

I don't think we have the experience that could form the basis for
guidance yet, so my suggestion is "no change".

That's very reasonable. I wonder if it's worth sa= ying that, but I'm fine if you don't make a change.

<= /div>
Thanks!

Spencer=C2=A0
<= /div> --001a114dc320048bd705392ce44b-- From nobody Wed Aug 3 09:04:55 2016 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 9404212D7A8; Wed, 3 Aug 2016 09:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.588 X-Spam-Level: X-Spam-Status: No, score=-5.588 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, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIEJRLp1mg07; Wed, 3 Aug 2016 09:04:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8E712D7A3; Wed, 3 Aug 2016 09:02:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EA520BE4C; Wed, 3 Aug 2016 17:02:25 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Plg4Wk3Q_7Yj; Wed, 3 Aug 2016 17:02:25 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 487F0BE3F; Wed, 3 Aug 2016 17:02:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1470240145; bh=eSb930LUZg7EVG5PkckSyxwPehtWonHf8Q41/hppmPE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=2Ip3+eOEJrKUzKAtTl+sjNkox/a7F55g/X/7WZCe06zjCT5ErTLc3sebHHCkpRjJw KtF5adGzFL1c3ZyA/tBI3KptkICVeYNQipsWlfeDQL9JoF1csxQ5Evx3e1aTK9rCBt KXj+OLM8BkDhAGd+PQwQG2QTl63yPuQ6nsWUu4JQ= To: Harald Alvestrand , The IESG References: <20160803145129.6144.18245.idtracker@ietfa.amsl.com> <57A2104F.1010504@alvestrand.no> <57A2145E.9020204@alvestrand.no> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <88f81543-02ef-ff1d-c83f-665c33521378@cs.tcd.ie> Date: Wed, 3 Aug 2016 17:02:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <57A2145E.9020204@alvestrand.no> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070808090302060305010204" Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS and COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 16:04:53 -0000 This is a cryptographically signed message in MIME format. --------------ms070808090302060305010204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/08/16 16:57, Harald Alvestrand wrote: >=20 > You can also get call duration by setting a trigger on a > PeerConnection's "onstatechange" handler and firing off a query to > "trackserver.net" inside that handler once the state goes to "closed". Ah - good point. I don't recall seeing that mentioned in any of the webrtc stuff I've scanned, but then maybe it's obvious if one has coded this stuff up. (I've clearly not:-) > I may have overlooked it, but I don't see the new attack. And seems to me like you're correct. I've cleared. Thanks, S. --------------ms070808090302060305010204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MDMx NjAyMjRaMC8GCSqGSIb3DQEJBDEiBCDxe4pebuaQjMvbnQ/AiZ7OzVMSRJcsgbMLixwhVj/u VjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAhNLJnxyDqVSfolefSX1krCHpuUiEKz27+f7OmUaCAalmfhktxR235 MELJQnxKzYBZhNvk9FcQfQods3ud3TtEQu2zJDuZ7ssuShbLE+1Gb5YmFJ9GZ5ASefH1osIi ue3OWnUOP6S4OG5dGw/pcG1XeqxRQ2SwM9L1LhKN1A2+gmlUFCaoRvK/L8pOXqoMutMGQhWf XXuv7OAYeZh935Nh8pg0s6GjwW/4GUOJv2BNCUr3uNAkBtNw+YBLs5uUD0CHk+iwJ/QCx3lk iUC45S9Y2vP1bD7Vzi6nqVL5pHY134HmJxaXhTS8/86M7e6k3TTsYWtR/ssQj/aC4uiJ1Wx0 AAAAAAAA --------------ms070808090302060305010204-- From nobody Wed Aug 3 12:56:56 2016 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 0E93212D13E; Wed, 3 Aug 2016 12:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 gl2sLnLD-FVF; Wed, 3 Aug 2016 12:56:45 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EEF12D7FF; Wed, 3 Aug 2016 12:56:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id ACC157C8F49; Wed, 3 Aug 2016 21:56:43 +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 7eCCCTkucndo; Wed, 3 Aug 2016 21:56:41 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:c830:4f59:b6ab:5fdd] (unknown [IPv6:2001:470:de0a:1:c830:4f59:b6ab:5fdd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 732D27C8F48; Wed, 3 Aug 2016 21:56:41 +0200 (CEST) To: Spencer Dawkins at IETF References: <20160802173617.27875.40513.idtracker@ietfa.amsl.com> <57A1BCC4.8050801@alvestrand.no> From: Harald Alvestrand Message-ID: <57A24C78.9070203@alvestrand.no> Date: Wed, 3 Aug 2016 21:56:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010207000204080904020309" Archived-At: Cc: rtcweb-chairs@ietf.org, "rtcweb@ietf.org" , The IESG , draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] Spencer Dawkins' Yes on draft-ietf-rtcweb-transports-14: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 19:56:49 -0000 This is a multi-part message in MIME format. --------------010207000204080904020309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/03/2016 05:57 PM, Spencer Dawkins at IETF wrote: > Hi, Harald, > > On Wed, Aug 3, 2016 at 4:43 AM, Harald Alvestrand > > wrote: > > Thanks for the comments! > > Responses inline and on github. > > Den 02. aug. 2016 19:36, skrev Spencer Dawkins: > > Spencer Dawkins has entered the following ballot position for > > draft-ietf-rtcweb-transports-14: Yes > > > > When responding, please keep the subject line intact and reply > to all > > email addresses included in the To and CC lines. (Feel free to > cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > I noted that some comments that I agreed with have appeared > during Last > > Call, and hope they'll be reflected in a -15. Beyond that, I had > a few > > comments of my own, but wanted to thank the working group for > producing > > very clear and helpful transport guidance. > > Thanks! > > > > > In this text > > > > If some of the temporary IPv6 addresses, but not all, are marked > > deprecated, the client SHOULD discard the deprecated addresses. > > > > I would find some explanation of why this is a SHOULD to be > helpful ("if > > some of the addresses are deprecated, and you could discard them > because > > you still have addresses that are not marked deprecated, why > would you > > not discard the deprecated addresses?"). > > > > I'm attaching this comment to > https://github.com/rtcweb-wg/rtcweb-transport/issues/22, since it > is the > same block of text. > > My memory (always less than trustworthy) says that people raised the > issue of "what if there's an ongoing connection using a deprecated > address, there's no non-deprecated useable address available, > shouldn't > we keep the in-use address in the pool?" (otherwise we'd lose the > connection at an ICE restart, even though the address still worked) - > with the response being something like "this is complicated, we'll get > experience to see if this is ever a real case, but let's make it a > SHOULD so that if people figure out that the problem is real, they'll > not be in formal non-conformance". > > This is the SHOULD version that means "it's a really good idea to do > this, but we're not sure we've identified all the corner cases where > it's a good idea not to; in case you encounter one, go ahead and be my > guest". > > > So, would it be correct to say, "the client SHOULD discard the > deprecated addresses unless they are used in an ongoing connection"? That works for me, given that it calls out a specific case I think was raised, and continues to use SHOULD. I'll add this. --------------010207000204080904020309 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
<snip stuff that we've finished discussing>
On 08/03/2016 05:57 PM, Spencer Dawkins at IETF wrote:
Hi, Harald,

On Wed, Aug 3, 2016 at 4:43 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
Thanks for the comments!

Responses inline and on github.

Den 02. aug. 2016 19:36, skrev Spencer Dawkins:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-rtcweb-transports-14: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I noted that some comments that I agreed with have appeared during Last
> Call, and hope they'll be reflected in a -15. Beyond that, I had a few
> comments of my own, but wanted to thank the working group for producing
> very clear and helpful transport guidance.

Thanks!

>
> In this text
>
>    If some of the temporary IPv6 addresses, but not all, are marked
>    deprecated, the client SHOULD discard the deprecated addresses.
>
> I would find some explanation of why this is a SHOULD to be helpful ("if
> some of the addresses are deprecated, and you could discard them because
> you still have addresses that are not marked deprecated, why would you
> not discard the deprecated addresses?").
>

I'm attaching this comment to
https://github.com/rtcweb-wg/rtcweb-transport/issues/22, since it is the
same block of text.

My memory (always less than trustworthy) says that people raised the
issue of "what if there's an ongoing connection using a deprecated
address, there's no non-deprecated useable address available, shouldn't
we keep the in-use address in the pool?" (otherwise we'd lose the
connection at an ICE restart, even though the address still worked) -
with the response being something like "this is complicated, we'll get
experience to see if this is ever a real case, but let's make it a
SHOULD so that if people figure out that the problem is real, they'll
not be in formal non-conformance".

This is the SHOULD version that means "it's a really good idea to do
this, but we're not sure we've identified all the corner cases where
it's a good idea not to; in case you encounter one, go ahead and be my
guest".

So, would it be correct to say, "the client SHOULD discard the deprecated addresses unless they are used in an ongoing connection"?

That works for me, given that it calls out a specific case I think was raised, and continues to use SHOULD. I'll add this.

--------------010207000204080904020309-- From nobody Wed Aug 3 13:02:51 2016 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 2265D12D807 for ; Wed, 3 Aug 2016 13:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 wq1DsXJqHCqH for ; Wed, 3 Aug 2016 13:02:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F3012D7FE for ; Wed, 3 Aug 2016 13:02:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 778D67C8F49; Wed, 3 Aug 2016 22:02:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8OJNXeHc_Ff; Wed, 3 Aug 2016 22:02:29 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:c830:4f59:b6ab:5fdd] (unknown [IPv6:2001:470:de0a:1:c830:4f59:b6ab:5fdd]) by mork.alvestrand.no (Postfix) with ESMTPSA id D0FF97C8F48; Wed, 3 Aug 2016 22:02:28 +0200 (CEST) To: md84419@gmail.com, Andy Hutton References: <57A088AB.3010909@alvestrand.no> From: Harald Alvestrand Message-ID: <57A24DD1.2040404@alvestrand.no> Date: Wed, 3 Aug 2016 22:02:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040100050405080706010103" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please review: Fixes to RTCWEB review comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 20:02:50 -0000 This is a multi-part message in MIME format. --------------040100050405080706010103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit My problem with adding this is that it's new text after WG Last Call, and I don't recall a consensus to add the text - my memory is that the discussions at IETFs were inconclusive, and that no declaration of consensus to add has been made by the chairs. New technical content added the day before IESG telechat treatment is likely to make the IESG nervous about document stability. I'll take instruction from the chairs on this issue, but won't add this text to -15. On 08/03/2016 04:19 PM, Michael Davey wrote: > ...And I have previously proposed that the second instance of MAY from > Andy's text be upgraded to "SHOULD .." or "are RECOMMENDED to ...". > > On 2 August 2016 at 14:40, Andy Hutton > wrote: > > There is still the issue of what to say in section 3.4 about > auto-discovery of TURN servers and the conflicts between > application provided, auto discovered, and configured TURN servers. > > Section 3.4 currently includes the statement "WebRTC browsers MUST > support configuration of STUN and TURN servers, both from browser > configuration and from an application". > > Previously I suggested the text: > > "WebRTC browsers MUST support configuration of STUN and TURN > servers, both from browser configuration and from an application. > WebRTC browsers MAY also discover TURN servers using TURN > Auto-Discovery [draft-ietf-tram-turn-server-discovery]. To resolve > conflicts between TURN servers provided by configuration, > auto-discovery, and the application WebRTC browsers MAY implement > the procedures specified in Recursively Encapsulated TURN (RETURN) > [draft-ietf-rtcweb-return]â€. > > This suggestion was based on the fact that the -return- draft is I > believe the only place where there is a statement about what to do > about the conflict between application provided and locally > configured TURN servers. > > Regards > Andy > > > > On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand > > wrote: > > > > I believe I now have PRs covering all the issues raised during > and after > > Last Call that were not fixed in -15. > > > > These are PR #30, #31, #32, #33, #34 and #35. Most of them are > strictly > > editorial. > > > > Please review the PRs at > > https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if > there are > > no objections, I hope to merge them early Wednesday morning CET > (that's > > late Tuesday evening US-PT) August 3 and ship a -16 that the > IESG can > > use as basis for balloting on Thursday (August 4). > > > > Harald > > > > _______________________________________________ > > 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 > > -- Surveillance is pervasive. Go Dark. --------------040100050405080706010103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
My problem with adding this is that it's new text after WG Last Call, and I don't recall a consensus to add the text - my memory is that the discussions at IETFs were inconclusive, and that no declaration of consensus to add has been made by the chairs.

New technical content added the day before IESG telechat treatment is likely to make the IESG nervous about document stability.

I'll take instruction from the chairs on this issue, but won't add this text to -15.

On 08/03/2016 04:19 PM, Michael Davey wrote:
...And I have previously proposed that the second instance of MAY from Andy's text be upgraded to "SHOULD .." or "are RECOMMENDED to ...".

On 2 August 2016 at 14:40, Andy Hutton <andyhutton.ietf@gmail.com> wrote:
There is still the issue of what to say in section 3.4 about auto-discovery of TURN servers and the conflicts between application provided, auto discovered, and configured TURN servers.

Section 3.4 currently includes the statement "WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application".

Previously I suggested the text:

"WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application. WebRTC browsers MAY also discover TURN servers using TURN Auto-Discovery [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TURN servers provided by configuration, auto-discovery, and the application WebRTC browsers MAY implement the procedures specified in Recursively Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]â€.

This suggestion was based on the fact that the -return- draft is I believe the only place where there is a statement about what to do about the conflict between application provided and locally configured TURN servers.

Regards
Andy



On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>
> I believe I now have PRs covering all the issues raised during and after
> Last Call that were not fixed in -15.
>
> These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly
> editorial.
>
> Please review the PRs at
> https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if there are
> no objections, I hope to merge them early Wednesday morning CET (that's
> late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can
> use as basis for balloting on Thursday (August 4).
>
> Harald
>
> _______________________________________________
> 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




-- 
Surveillance is pervasive. Go Dark.
--------------040100050405080706010103-- From nobody Wed Aug 3 14:51:39 2016 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 B2ECA12D14B; Wed, 3 Aug 2016 14:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFcg4JLPShOa; Wed, 3 Aug 2016 14:51:34 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.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 9120312B03D; Wed, 3 Aug 2016 14:51:34 -0700 (PDT) X-AuditID: c618062d-597ff70000000a08-51-57a267c677d7 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id 57.BB.02568.6C762A75; Wed, 3 Aug 2016 23:53:12 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0301.000; Wed, 3 Aug 2016 17:37:47 -0400 From: Suresh Krishnan To: Harald Alvestrand , The IESG Thread-Topic: [rtcweb] Suresh Krishnan's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS) Thread-Index: AQHR7TtzYoUwO6hJl0mGIzStjTvSRQ== Date: Wed, 3 Aug 2016 21:37:46 +0000 Message-ID: References: <20160803035930.27802.48004.idtracker@ietfa.amsl.com> <57A1C02C.5040507@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXSPt+6J9EXhBj+nm1hc7Fe0ONbXxWYx 489EZouetzdYLNb+a2d3YPW4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJm7VzPWPBKsmL2 713sDYyvRboYOTkkBEwk2lacYOpi5OIQEtjAKLGh8x07hLOMUeJuZz8TSBUbUNWGnZ+BbA4O EQE3iTePnUHCzALrGSU6HwiA2MICKRJbV01kAbFFBFIllnf+YYKw9SQuX1vJCmKzCKhIrFv1 hxnE5hXwlZgyuxOsXgio986jNWA2o4CYxPdTa5gg5otL3HoynwniUAGJJXvOM0PYohIvH/9j hbCVJOa8vsYMUa8jsWD3JzYIW1ti2cLXULsEJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWM HKXFBTm56UYGmxiBEXFMgk13B+P96Z6HGAU4GJV4eBUMF4ULsSaWFVfmHmKU4GBWEuG9lwIU 4k1JrKxKLcqPLyrNSS0+xCjNwaIkziv2SDFcSCA9sSQ1OzW1ILUIJsvEwSnVwLg15Fw6/7QG BeG21MCvD358t517JG+/slHvlv3d374evXZf58W7VrlXylNeXBUMKd1cwWjpz807Syanskpg ztHv4hcSHGyltt7b9Y9rTebRggtuE2RYvNV3Pn3UfmHVFn6b5PxZVT1//T1e6E94Nm1Tl83r ypW+LsG2WYVZO62iz69TsH1/K0mJpTgj0VCLuag4EQB72Y6thAIAAA== Archived-At: Cc: "rtcweb@ietf.org" , "draft-ietf-rtcweb-transports@ietf.org" , "rtcweb-chairs@ietf.org" Subject: Re: [rtcweb] Suresh Krishnan's Discuss on draft-ietf-rtcweb-transports-14: (with DISCUSS) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 21:51:37 -0000 Hi Harald,=0A= Thanks for clarifying your intent of culling the address set for ICE. = =0A= Sounds reasonable. The text changes you have proposed for the next rev look= =0A= good to me. I will clear as soon as the new rev is published.=0A= =0A= Regards=0A= Suresh=0A= =0A= On 08/03/2016 05:58 AM, Harald Alvestrand wrote:=0A= > Thanks for the comment!=0A= >=0A= > I've attached this to=0A= > https://github.com/rtcweb-wg/rtcweb-transport/issues/22 because it deals= =0A= > with the same block of text.=0A= >=0A= > Den 03. aug. 2016 05:59, skrev Suresh Krishnan:=0A= >> In Section 3.3. Usage of temporary IPv6 addresses, the draft states=0A= >>=0A= >> " The IPv6 default address selection specification [RFC6724] specifies= =0A= >> that temporary addresses [RFC4941] are to be preferred over permanent= =0A= >> addresses."=0A= >>=0A= >> While this is technically true, this is only the seventh rule in an=0A= >> ordered list of eight rules.=0A= >> e.g. A valid permanent address would be preferred over a deprecated=0A= >> temporary address based on Rule 3.=0A= >>=0A= >> If a host had only a valid permanent address and a deprecated temporary= =0A= >> address, the mechanism specified in the draft would result in no=0A= >> addresses being made available, whereas the permanent address would have= =0A= >> been an acceptable choice using RFC6724.=0A= >=0A= > The previous fix added "non-deprecated" into the sentence. See=0A= > https://github.com/rtcweb-wg/rtcweb-transport/pull/32/files=0A= >=0A= >>=0A= >> So, it is not entirely clear to me what the draft is trying to=0A= >> accomplish. It says=0A= >>=0A= >> " However, this rule is not completely obvious in the ICE scope. This= =0A= >> is therefore clarified as follows:"=0A= >>=0A= >> What rule is this talking about when it says "this rule"?=0A= >=0A= > Rule seven.=0A= >=0A= > The reason why it's not obvious is that ICE doesn't "prefer" addresses -= =0A= > it gathers a bunch of them, and then sends the whole set to its partner,= =0A= > where it will be tried in some order - which means that it's observable= =0A= > by anyone who can see the signalling.=0A= >=0A= > I believe rule seven was flipped in 6724 because of a concern with=0A= > privacy-enhanced addresses (which are temporary); if the permanent=0A= > address is tried before the temporary address, the permanent address=0A= > will be exposed when it doesn't have to.=0A= >=0A= > In the ICE case, if it is gathered, it will be exposed; the only way to= =0A= > preserve privacy of the permanent address is to discard it when=0A= > gathering ICE candidates.=0A= >=0A= > No similar privacy concern was raised for the other steps of the algorith= m.=0A= >=0A= >=0A= >>=0A= >> Similarly, it also says=0A= >>=0A= >> "When a client gathers all IPv6 addresses on a host..."=0A= >=0A= > The intent is "WebRTC endpoint", as defined in -overview. I'll change=0A= > the terminology.=0A= >=0A= >>=0A= >> but it is not clear what "client" the draft is referring to.=0A= >>=0A= >> I think if you can clarify what you want to achieve with the address=0A= >> selection we can work together on some replacement text.=0A= >=0A= > Is it clear enough what we wanted to accomplish?=0A= >=0A= =0A= From nobody Wed Aug 3 23:27:18 2016 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 B4A8212B060 for ; Wed, 3 Aug 2016 23:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcAcJe4e0VQZ for ; Wed, 3 Aug 2016 23:27:14 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3BA126FDC for ; Wed, 3 Aug 2016 23:27:14 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id b62so263514455iod.3 for ; Wed, 03 Aug 2016 23:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z0bqX3hPvr4zPILdDoMJLXfOqvStPWTDx1K6y7sLf+U=; b=TMNpmohnJ7Ho0KJkD7LmhPMoMje6ZO5wAm+5J90cPpN0P1KgqUjhdXsk0FRvWbvePn mHaa+Eqnwi6XCNhMTQeMS10U8rfgbqDYoosdJuQgWw8g+3LOgFwJywr9YX3DwVvC0ClU 4xmfg4+nPEP3nY81sGyVpDZOwqfOtxX4Z76okh4kHK+P8E/cOufkxDeH/tFgrlQRn40g 3NAkvYdQoe52rTTl9djefEnH1aA0kyNs6Kkdlw6dSRD6h5pmCpygzTCcVpqcaC4MKD68 gmt/zt1cgS3L3Qhs93OVwVVOfUmdIFDPtTcq9niUCMyUEsJpKM7L87xYjssRpmJlc2Xv qt5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z0bqX3hPvr4zPILdDoMJLXfOqvStPWTDx1K6y7sLf+U=; b=DwutGaj7x8Ocp0bW49zgpvIdcGO+VGyZPDSUxcBDwJQedyZObnl2hXZTsJBbt9omhp FUAkyjAK0w3BmL6+VUCfxXIKJgdOW2kIXlMmILNpZ6CQKJoZzmHvBhQwBcWqB8wzFSto Sdxcdm+ZCWrhn/Zp8uY0rqQFSHgDhHhAwzw918fYMkcc8l1YRImWN6PST5fZPuITGJve ZehcyqsDWwr98MZAxkf+/5fH85UH1sbId0UkqMcJfmCy6P9LgycIYah9q72qwkMq60dn kpEKSGZSd3OdV4EOAObn57gm2K4f/Eu2qnSsjyYOravRFevKwqnLm67Ac0XycFUdMQmP ifGQ== X-Gm-Message-State: AEkoouth8Nhw+HyXXs3ec0l/Xt0XaaI+A1fBSaT+/r83wAenyrSsdJhE4+gPw80NUUZZCACcoRLW5LQB+W9NEw== X-Received: by 10.107.160.204 with SMTP id j195mr73719018ioe.70.1470292033448; Wed, 03 Aug 2016 23:27:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.26 with HTTP; Wed, 3 Aug 2016 23:27:12 -0700 (PDT) In-Reply-To: <57A24DD1.2040404@alvestrand.no> References: <57A088AB.3010909@alvestrand.no> <57A24DD1.2040404@alvestrand.no> From: Andy Hutton Date: Thu, 4 Aug 2016 07:27:12 +0100 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113c6c765eb12e0539390a9c Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please review: Fixes to RTCWEB review comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 06:27:17 -0000 --001a113c6c765eb12e0539390a9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe the comment was made during WGLC but Ii cannot check that right now. Do you believe there is anything controversial in the text? My thinking was it was just referring to other drafts to clarify the case when there are conflicts. Andy On Wednesday, 3 August 2016, Harald Alvestrand wrote= : > My problem with adding this is that it's new text after WG Last Call, and > I don't recall a consensus to add the text - my memory is that the > discussions at IETFs were inconclusive, and that no declaration of > consensus to add has been made by the chairs. > > New technical content added the day before IESG telechat treatment is > likely to make the IESG nervous about document stability. > > I'll take instruction from the chairs on this issue, but won't add this > text to -15. > > On 08/03/2016 04:19 PM, Michael Davey wrote: > > ...And I have previously proposed that the second instance of MAY from > Andy's text be upgraded to "SHOULD .." or "are RECOMMENDED to ...". > > On 2 August 2016 at 14:40, Andy Hutton > wrote: > >> There is still the issue of what to say in section 3.4 about >> auto-discovery of TURN servers and the conflicts between application >> provided, auto discovered, and configured TURN servers. >> >> Section 3.4 currently includes the statement "WebRTC browsers MUST >> support configuration of STUN and TURN servers, both from browser >> configuration and from an application". >> >> Previously I suggested the text: >> >> "WebRTC browsers MUST support configuration of STUN and TURN servers, >> both from browser configuration and from an application. WebRTC browsers >> MAY also discover TURN servers using TURN Auto-Discovery >> [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TU= RN >> servers provided by configuration, auto-discovery, and the application >> WebRTC browsers MAY implement the procedures specified in Recursively >> Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D. >> >> This suggestion was based on the fact that the -return- draft is I >> believe the only place where there is a statement about what to do about >> the conflict between application provided and locally configured TURN >> servers. >> >> Regards >> Andy >> >> >> >> On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand > > wrote: >> > >> > I believe I now have PRs covering all the issues raised during and aft= er >> > Last Call that were not fixed in -15. >> > >> > These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictl= y >> > editorial. >> > >> > Please review the PRs at >> > https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if there ar= e >> > no objections, I hope to merge them early Wednesday morning CET (that'= s >> > late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can >> > use as basis for balloting on Thursday (August 4). >> > >> > Harald >> > >> > _______________________________________________ >> > 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 >> >> > > > -- > Surveillance is pervasive. Go Dark. > > --001a113c6c765eb12e0539390a9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe the comment was made during WGLC but Ii cannot check that right n= ow.

Do you believe there is anything controversial in th= e text?

My thinking was it was just referring to o= ther drafts to clarify the case when there are conflicts.

Andy

On Wednesday, 3 August 2016, Harald Alvest= rand <harald@alvestrand.no&g= t; wrote:
=20 =20 =20
My problem with adding this is that it's new text after WG Last Call, and I don't recall a consen= sus to add the text - my memory is that the discussions at IETFs were inconclusive, and that no declaration of consensus to add has been made by the chairs.

New technical content added the day before IESG telechat treatment is likely to make the IESG nervous about document stability.

I'll take instruction from the chairs on this issue, but won'= t add this text to -15.

On 08/03/2016 04:19 PM, Michael Davey wrote:
...And I have previously proposed that the second instance of MAY from Andy's text be upgraded to "SHOULD ..= " or "are RECOMMENDED to ...&quo= t;.

On 2 August 2016 at 14:40, Andy Hutton <andyhutton.iet= f@gmail.com> wrote:
There is still the issue of what to say in section 3.4 about auto-discovery of TURN servers and the conflicts between application provided, auto discovered, and configured TURN servers.

Section 3.4 currently includes the statement "WebRTC browsers MUST support configuration of STUN and TURN servers,=C2=A0both from browser configuration and from an application".=
Pre= viously I suggested the text:
&qu= ot;WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application. WebRTC browsers MAY also discover TURN servers using TURN Auto-Discovery [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TURN servers provided by configuration, auto-discovery, and the application WebRTC browsers MAY implement the procedures specified in Recursively Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D.

This suggestion was based on the fact that the -return- draft is I believe the only place where there is a statement about what to do about the conflict between application provided and locally configured TURN servers.

Regards
Andy



On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand <harald@alvestrand.no>= ; wrote:
>
> I believe I now have PRs covering all the issues raised during and after
> Last Call that were not fixed in -15.
>
> These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly
> editorial.
>
> Please review the PRs at
> https://github.com/rtcweb-wg/rtcweb-transpo= rt/pulls ASAP - if there are
> no objections, I hope to merge them early Wednesday morning CET (that's
> late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can
> use as basis for balloting on Thursday (August 4).
>
> Harald
>
> _______________________________________________ > rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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




--=20
Surveillance is pervasive. Go Dark.
--001a113c6c765eb12e0539390a9c-- From nobody Thu Aug 4 02:19:57 2016 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 9CAFF12D879; Thu, 4 Aug 2016 02:19:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160804091953.15852.31672.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 02:19:53 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-rtcweb-transports-14=3A_=28with_DISCUSS=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 09:19:53 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-rtcweb-transports-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks, I think this is a very useful and well written document. Sorry for my late discuss but I don't think this is anything complicated to address. Based on the TSV review I agree that this document should say more about congestion control. While the TSV reviewer (Thanks Allison!) only proposes to refer draft-ietf-avtcore-rtp-circuit-breakers-17 and draft-ietf-rmcat-cc-requirements-09, I would even prefer to have a normative sentence that says that congestion control MUST be implemented for all traffic flows. Please also provide the update on DSCP black-holing (in the middle of a flow) as mentioned by David Black. From nobody Thu Aug 4 02:23:52 2016 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 D65B012D6A9 for ; Thu, 4 Aug 2016 02:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 KHOH6IRyV1Zp for ; Thu, 4 Aug 2016 02:23:48 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CB312D1A6 for ; Thu, 4 Aug 2016 02:23:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 57A0C7C8C9A; Thu, 4 Aug 2016 11:23:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rww1h7q7FK_S; Thu, 4 Aug 2016 11:23:45 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d] (unknown [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d]) by mork.alvestrand.no (Postfix) with ESMTPSA id 61B537C897B; Thu, 4 Aug 2016 11:23:45 +0200 (CEST) To: Martin Thomson References: <57A0587C.9090102@alvestrand.no> From: Harald Alvestrand Message-ID: <57A309A0.2000908@alvestrand.no> Date: Thu, 4 Aug 2016 11:23:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fix for DSCP bleaching issue suggested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 09:23:51 -0000 Den 02. aug. 2016 12:43, skrev Martin Thomson: > http://www.dictionary.com/browse/resent - I know what you mean, of course. :-) the word seems strangely appropriate :-) > > Presumably if DSCP 0 passes, but probes with DSCP N fails, only > traffic that was intended to be sent with DSCP N would be sent with > DSCP 0. If DSCP M succeeds, then you could continue to use that; your > text implies otherwise. > > You might like to point out that switching DSCP marking mid-flow can > have negative effects on things like congestion controllers and loss > recovery. After chewing this over in my head for another day, I added two more paragraphs and a bit. New text: A particularly hard problem is when one media transport uses multiple DSCP code points, where one may be blocked and another may be allowed. This is allowed even within a single media flow for video in . Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCP code points that are intended to be used once a candidate pair has been selected. If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0. This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent. This switch will of course invalidate any congestion information gathered up to that point. Failures can also start happening during the lifetime of the call; this case is expected to be rarer, and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart. Note that when a DSCP code point causes non-delivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes. Other flows on the same transport, using different DSCP code points, don't need to change. I'll incorporate this in -15; if we need to tweak more, this needs to go into -16 (if any). From nobody Thu Aug 4 03:06:27 2016 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 0C8EC12D9C5 for ; Thu, 4 Aug 2016 03:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qP7ANBQXVi0 for ; Thu, 4 Aug 2016 03:06:23 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3DD312D95D for ; Thu, 4 Aug 2016 03:05:21 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id r9so247912058ywg.0 for ; Thu, 04 Aug 2016 03:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=tb7JgHrt0PaV2oGqo+qTUDb+o+9UcFxIXJK5U/DAOI0=; b=pcJ/BPV68z06fmlJg59Axlcqo+onm/8bxqOcsv89LD9ZqyGPAuaAFv2rcXPBU3fLWE dYq9Ubc+RRoFL7h7o9AgEdS9GA9p4qhWJLvZITJtmlL3QJNhL83DxAb+HWOk0dB3pzLW BQ5mRAdOlQWBSP4Uz9bTq8iYvOo3nIARLqKAUZnROCsk6ecDHhtO1DolqSzYTs0Z8MpV Xa6eE+rfXrb0NoxxYeF3h+jlb5MFUYRyNJd7pdIKyppLYn4Jr01Pwp7/bwiAsITycfi5 kXW0GJiYGlfaF19BgARKIrAQ0yXpiAjQPzh8avBYZ9RVYKzBHfMvZdcoAMaSBIYxB2hY rAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=tb7JgHrt0PaV2oGqo+qTUDb+o+9UcFxIXJK5U/DAOI0=; b=TP5yaw1z9EBmtPTdK+uw4aweMPSVJ4somWqTQpUE+SYzU9OMD8JhOZMCIwJ5nKy9og 1m4ix7sZbAp/qskrT4VBi4ZujJYf3N7ySXi3ekEa20uhuokWOje7Fj3JXYDZG5It+b7h wTsS+LZmAldBcuzyujCZ+WMj4fTbFRELA9epYouWpLyvruXBnofbJOMkVcTsTZyilU2H WgK8LsqjQ5cjOePFIFowq0Hr11MRxEOotQx2VM9iXwTJ0230X3y1B+q6WG7QSPmdo4qY Sv+DFbhbOEwJO+9IBbSRfl6GQE/x1mvQM+QgYE8es3OJsofNn3VDFIV11xv+gmjISiMl OT7Q== X-Gm-Message-State: AEkooutZgeub9CPpNgE2xD85c+WUuhBBM5eTHvb/Udajel/EbWRsGGT6cc7PZbNyjM9asqxM9TLuKp02hLPF1Q== X-Received: by 10.13.201.199 with SMTP id l190mr56831967ywd.181.1470305121077; Thu, 04 Aug 2016 03:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.33.136 with HTTP; Thu, 4 Aug 2016 03:05:00 -0700 (PDT) In-Reply-To: References: <57A088AB.3010909@alvestrand.no> <57A24DD1.2040404@alvestrand.no> From: Michael Davey Date: Thu, 4 Aug 2016 11:05:00 +0100 Message-ID: To: Andy Hutton Content-Type: multipart/alternative; boundary=001a114e711c7413b805393c16c5 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Please review: Fixes to RTCWEB review comments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: md84419@gmail.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 10:06:26 -0000 --001a114e711c7413b805393c16c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes it was. The email subject line was: "WGLC comment on draft-ietf-rtcweb-transports - return", discussion 20th-22nd June. I agree its just a reminder that TURN servers may be auto-discovered as discussed elsewhere in the spec. and what to do in the case of conflicts. --=20 Michael On 4 August 2016 at 07:27, Andy Hutton wrote: > I believe the comment was made during WGLC but Ii cannot check that right > now. > > Do you believe there is anything controversial in the text? > > My thinking was it was just referring to other drafts to clarify the case > when there are conflicts. > > Andy > > > On Wednesday, 3 August 2016, Harald Alvestrand > wrote: > >> My problem with adding this is that it's new text after WG Last Call, an= d >> I don't recall a consensus to add the text - my memory is that the >> discussions at IETFs were inconclusive, and that no declaration of >> consensus to add has been made by the chairs. >> >> New technical content added the day before IESG telechat treatment is >> likely to make the IESG nervous about document stability. >> >> I'll take instruction from the chairs on this issue, but won't add this >> text to -15. >> >> On 08/03/2016 04:19 PM, Michael Davey wrote: >> >> ...And I have previously proposed that the second instance of MAY from >> Andy's text be upgraded to "SHOULD .." or "are RECOMMENDED to ...". >> >> On 2 August 2016 at 14:40, Andy Hutton wrote= : >> >>> There is still the issue of what to say in section 3.4 about >>> auto-discovery of TURN servers and the conflicts between application >>> provided, auto discovered, and configured TURN servers. >>> >>> Section 3.4 currently includes the statement "WebRTC browsers MUST >>> support configuration of STUN and TURN servers, both from browser >>> configuration and from an application". >>> >>> Previously I suggested the text: >>> >>> "WebRTC browsers MUST support configuration of STUN and TURN servers, >>> both from browser configuration and from an application. WebRTC browser= s >>> MAY also discover TURN servers using TURN Auto-Discovery >>> [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between >>> TURN servers provided by configuration, auto-discovery, and the applica= tion >>> WebRTC browsers MAY implement the procedures specified in Recursively >>> Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D. >>> >>> This suggestion was based on the fact that the -return- draft is I >>> believe the only place where there is a statement about what to do abou= t >>> the conflict between application provided and locally configured TURN >>> servers. >>> >>> Regards >>> Andy >>> >>> >>> >>> On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand >>> wrote: >>> > >>> > I believe I now have PRs covering all the issues raised during and >>> after >>> > Last Call that were not fixed in -15. >>> > >>> > These are PR #30, #31, #32, #33, #34 and #35. Most of them are strict= ly >>> > editorial. >>> > >>> > Please review the PRs at >>> > https://github.com/rtcweb-wg/rtcweb-transport/pulls ASAP - if there >>> are >>> > no objections, I hope to merge them early Wednesday morning CET (that= 's >>> > late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can >>> > use as basis for balloting on Thursday (August 4). >>> > >>> > Harald >>> > >>> > _______________________________________________ >>> > 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 >>> >>> >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> --001a114e711c7413b805393c16c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes it was.=C2=A0 The email subject line was: "WGLC c= omment on draft-ietf-rtcweb-transports - return", discussion 20th-22nd= June.

I agree its just a reminder that TURN servers may= be auto-discovered as discussed elsewhere in the spec. and what to do in t= he case of conflicts.

--=C2=A0
Michael


On 4 August 2016 at 07:27, Andy Hutton <andyhutton.ietf@gm= ail.com> wrote:
I believe t= he comment was made during WGLC but Ii cannot check that right now.
Do you believe there is anything controversial in the text?

My thinking was it was just referring to other drafts= to clarify the case when there are conflicts.
=

Andy


On Wednesday, 3 August 2016, Harald Alvestrand <harald@alvestrand.no= > wrote:
=20 =20 =20
My problem with adding this is that it's new text after WG Last Call, and I don't recall a consen= sus to add the text - my memory is that the discussions at IETFs were inconclusive, and that no declaration of consensus to add has been made by the chairs.

New technical content added the day before IESG telechat treatment is likely to make the IESG nervous about document stability.

I'll take instruction from the chairs on this issue, but won'= t add this text to -15.

On 08/03/2016 04:19 PM, Michael Davey wrote:
...And I have previously proposed that the second instance of MAY from Andy's text be upgraded to "SHOULD ..= " or "are RECOMMENDED to ...&quo= t;.

On 2 August 2016 at 14:40, Andy Hutton <andyhutton.ietf@gmail.com> wrote:
There is still the issue of what to say in section 3.4 about auto-discovery of TURN servers and the conflicts between application provided, auto discovered, and configured TURN servers.

Section 3.4 currently includes the statement "WebRTC browsers MUST support configuration of STUN and TURN servers,=C2=A0both from browser configuration and from an application".=
Pre= viously I suggested the text:
&qu= ot;WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application. WebRTC browsers MAY also discover TURN servers using TURN Auto-Discovery [draft-ietf-tram-turn-server-discovery]. To resolve conflicts between TURN servers provided by configuration, auto-discovery, and the application WebRTC browsers MAY implement the procedures specified in Recursively Encapsulated TURN (RETURN) [draft-ietf-rtcweb-return]=E2=80=9D.

This suggestion was based on the fact that the -return- draft is I believe the only place where there is a statement about what to do about the conflict between application provided and locally configured TURN servers.

Regards
Andy



On Tue, Aug 2, 2016 at 12:48 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>
> I believe I now have PRs covering all the issues raised during and after
> Last Call that were not fixed in -15.
>
> These are PR #30, #31, #32, #33, #34 and #35. Most of them are strictly
> editorial.
>
> Please review the PRs at
> https://github.com/rtcweb-wg/rtcweb-tr= ansport/pulls ASAP - if there are
> no objections, I hope to merge them early Wednesday morning CET (that's
> late Tuesday evening US-PT) August 3 and ship a -16 that the IESG can
> use as basis for balloting on Thursday (August 4).
>
> Harald
>
> _____________________________________________= __
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb<= /a>

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




--=20
Surveillance is pervasive. Go Dark.

--001a114e711c7413b805393c16c5-- From nobody Thu Aug 4 03:33:26 2016 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 8CACE12DA17; Thu, 4 Aug 2016 03:33:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160804103325.15840.76242.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 03:33:25 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-15.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 10:33:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-15.txt Pages : 19 Date : 2016-08-04 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 4 03:46:18 2016 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 0F04512DCE0 for ; Thu, 4 Aug 2016 03:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 PNz2FC142F8C for ; Thu, 4 Aug 2016 03:46:16 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9603012DC6A for ; Thu, 4 Aug 2016 03:45:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7648A7C8F61 for ; Thu, 4 Aug 2016 12:45:56 +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 2VAwZcpYV1Ri for ; Thu, 4 Aug 2016 12:45:55 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d] (unknown [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d]) by mork.alvestrand.no (Postfix) with ESMTPSA id BBEAC7C8F4E for ; Thu, 4 Aug 2016 12:45:55 +0200 (CEST) To: "rtcweb@ietf.org" From: Harald Alvestrand Message-ID: Date: Thu, 4 Aug 2016 12:45:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 10:46:18 -0000 I have submitted -15 and closed those issues that I believe it resolves. There are six left in the tracker: One I forgot (#40), one raised today in the IESG (#41), and Andy's "RETURN reference" issue (#42), as well as 3 issues where I suggested "no change" as a resolution. Comments welcome! Note - I believe #41 and #42 are technical changes, so should formally require IESG re-processing. I believe the others are editorial in nature, so can be done without a new IESG pass. Harald From nobody Thu Aug 4 05:33:03 2016 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 9B92612D15E; Thu, 4 Aug 2016 05:33:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160804123300.15799.43046.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 05:33:00 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] Suresh Krishnan's Yes on draft-ietf-rtcweb-transports-15: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 12:33:00 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-rtcweb-transports-15: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing the issues from my DISCUSS in version 15. I am clearing. From nobody Thu Aug 4 05:40:30 2016 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 E985012D182 for ; Thu, 4 Aug 2016 05:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LulnBte4SIFN for ; Thu, 4 Aug 2016 05:40:18 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B25EA12B049 for ; Thu, 4 Aug 2016 05:40:17 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id q83so270417640iod.1 for ; Thu, 04 Aug 2016 05:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=652jlqjHpcNU3v8tWsYnDqshWTgl1nbUykl2ZfFHjQI=; b=mqLlgGCEx27R0uHEyHv2wjbtHRqHOFLIKYxEKK88c5KYlOiAJLgs+HA6Mp8q1wgXLm /qzl71vCrTrjHXibd39+Urgf7+qImA7O9ZmUcHwN4sTMC5Ub8viO+sDttFWe2gVbWdLA YJih6XwnvrFkM1IaO+xvO4IRxwFzXuGqW0kIayGRrvLTx55Slk7aSK+NGS4PFpPVGmNw kTBHEM89JizULO7KFI2UP/73uma4Rn3eO3Qbksi1C/soFn/c7jaUw+4wtzyEw6YQiKiE s5HnARA9UE1S3XJ2cT01anw4x18OgA3VuqKqVA+2vB+mW8k7HRPe+fZWs/nYTLsr08Bs 4qtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=652jlqjHpcNU3v8tWsYnDqshWTgl1nbUykl2ZfFHjQI=; b=QhrKz1IT5tHXwjq6Lrub1NBa3Alm68CK1nlherPZRNV+Hu/VbW9ifIsS4jMWPC3PlK MqGd29ky2U8ku/ERSW8/yHnLjn+oPDsnG8jwExQXsssbi/sIUbDPMOO/Rh2vogpOzpN0 S6fTHifKidv2p3H3Hp4r2FHRGJrf7QTKzGLDUNzPbK3AJaEch2ogzr0l/++X9ZmXJZ/B VBT2k05wD4MKNogsWoiyY7mLFS1O9Cyhau4ctHKGMAxuy8ryzp3RnUyvl4DWe98jdWHL zVHtB6znLUFEURTdgc3TXs6NCHZu/CRDfRog+WG67kAKhY5ODgllw5mRc4iDOwWa4k4p jnbw== X-Gm-Message-State: AEkooutbEgWkCgDkX3OIxoclwIVdJFtODavrBuVyWOYN1HWgA9a8LGDaPuqUuJ60HYBt0YRY6ljMu+a+PmmewA== X-Received: by 10.107.55.70 with SMTP id e67mr74479701ioa.51.1470314417124; Thu, 04 Aug 2016 05:40:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.26 with HTTP; Thu, 4 Aug 2016 05:40:16 -0700 (PDT) In-Reply-To: References: From: Andy Hutton Date: Thu, 4 Aug 2016 13:40:16 +0100 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114a6d768a7a5505393e408e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 12:40:29 -0000 --001a114a6d768a7a5505393e408e Content-Type: text/plain; charset=UTF-8 Harald, I don't think that #42 is really a technical change can you explain why why you think it is? The referencing of -return- was mentioned in te AD evaluation by Alissa see https://www.ietf.org/mail-archive/web/rtcweb/current/msg15943.html Andy On Thursday, 4 August 2016, Harald Alvestrand wrote: > I have submitted -15 and closed those issues that I believe it resolves. > There are six left in the tracker: One I forgot (#40), one raised today > in the IESG (#41), and Andy's "RETURN reference" issue (#42), as well as > 3 issues where I suggested "no change" as a resolution. > > Comments welcome! > > Note - I believe #41 and #42 are technical changes, so should formally > require IESG re-processing. I believe the others are editorial in > nature, so can be done without a new IESG pass. > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114a6d768a7a5505393e408e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Harald,

I don't think that #42 is really a tec= hnical change can you explain why why you think it is?

T= he referencing of -return- was mentioned in te AD evaluation by Alissa see= =C2=A0https://www.ietf.org/mail-archive/web/rtcweb/current/msg15943.htm= l

Andy

On Thursday, 4 Augu= st 2016, Harald Alvestrand <hara= ld@alvestrand.no> wrote:
I have s= ubmitted -15 and closed those issues that I believe it resolves.
There are six left in the tracker: One I forgot (#40), one raised today
in the IESG (#41), and Andy's "RETURN reference" issue (#42),= as well as
3 issues where I suggested "no change" as a resolution.

Comments welcome!

Note - I believe #41 and #42 are technical changes, so should formally
require IESG re-processing. I believe the others are editorial in
nature, so can be done without a new IESG pass.

Harald

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--001a114a6d768a7a5505393e408e-- From nobody Thu Aug 4 06:05:38 2016 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 A51AB12D51C for ; Thu, 4 Aug 2016 06:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 jcJ-Q5o914od for ; Thu, 4 Aug 2016 06:05:33 -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 A138F12D18F for ; Thu, 4 Aug 2016 06:05:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id D88C27C8F69; Thu, 4 Aug 2016 15:05:31 +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 zs-bnW4m7PoZ; Thu, 4 Aug 2016 15:05:28 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d] (unknown [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8E9E67C8EF9; Thu, 4 Aug 2016 15:05:28 +0200 (CEST) To: Andy Hutton References: From: Harald Alvestrand Message-ID: <21a3cec4-c913-d3a9-b3a6-f9ccbb34fb09@alvestrand.no> Date: Thu, 4 Aug 2016 15:05:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:05:37 -0000 Den 04. aug. 2016 14:40, skrev Andy Hutton: > Harald, > > I don't think that #42 is really a technical change can you explain why > why you think it is? > Because it introduces two new drafts that have to be understood in order to completely understand the specification, one of which is expired. While these are at MAY strength, I don't see how it's editorial. > The referencing of -return- was mentioned in te AD evaluation by Alissa > see https://www.ietf.org/mail-archive/web/rtcweb/current/msg15943.html I can't see -return- in the referenced message; where do you see it? > > Andy > > On Thursday, 4 August 2016, Harald Alvestrand > wrote: > > I have submitted -15 and closed those issues that I believe it resolves. > There are six left in the tracker: One I forgot (#40), one raised today > in the IESG (#41), and Andy's "RETURN reference" issue (#42), as well as > 3 issues where I suggested "no change" as a resolution. > > Comments welcome! > > Note - I believe #41 and #42 are technical changes, so should formally > require IESG re-processing. I believe the others are editorial in > nature, so can be done without a new IESG pass. > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Aug 4 06:06:16 2016 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 B331012B04D for ; Thu, 4 Aug 2016 06:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 o2sjgRK73fl2 for ; Thu, 4 Aug 2016 06:06:12 -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 37A3212D519 for ; Thu, 4 Aug 2016 06:06:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B19C17C8F69; Thu, 4 Aug 2016 15:06:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjyQBJ-ZNAxB; Thu, 4 Aug 2016 15:06:09 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d] (unknown [IPv6:2001:470:de0a:1:fd3f:129d:cdbc:a28d]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4B3C07C8EF9; Thu, 4 Aug 2016 15:06:09 +0200 (CEST) To: Andy Hutton References: From: Harald Alvestrand Message-ID: Date: Thu, 4 Aug 2016 15:06:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:06:14 -0000 Den 04. aug. 2016 14:40, skrev Andy Hutton: > Harald, > > I don't think that #42 is really a technical change can you explain why > why you think it is? > > The referencing of -return- was mentioned in te AD evaluation by Alissa > see https://www.ietf.org/mail-archive/web/rtcweb/current/msg15943.html Yes. There was no determination by the chairs after that on the issue, as far as I can tell. > > Andy > > On Thursday, 4 August 2016, Harald Alvestrand > wrote: > > I have submitted -15 and closed those issues that I believe it resolves. > There are six left in the tracker: One I forgot (#40), one raised today > in the IESG (#41), and Andy's "RETURN reference" issue (#42), as well as > 3 issues where I suggested "no change" as a resolution. > > Comments welcome! > > Note - I believe #41 and #42 are technical changes, so should formally > require IESG re-processing. I believe the others are editorial in > nature, so can be done without a new IESG pass. > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Aug 4 06:30:26 2016 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 102A812B069 for ; Thu, 4 Aug 2016 06:30:24 -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 hhGw1Kffc9BG for ; Thu, 4 Aug 2016 06:30:21 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 5724512B071 for ; Thu, 4 Aug 2016 06:30:21 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id pp5so83077198pac.3 for ; Thu, 04 Aug 2016 06:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+4JrVpH3Roe6u3s6G0Qp/w9AVkvUtvbqqJBBDL+PHiE=; b=Zg8Ew6VOOhhNOPA/K+iqf2SwyeCp+lOi48DEvKuOueya1c8E237kITKwk2n0UtIGSK UB3wsOwYJ0UCcJ7NVX+dR9AFjFTxZib5nM7h/sA7n3hvA13FMVI6pcrv2O5kF8CMB94Z ZyDjO9xQZhKtpbHJgARQoRUwnKHPcOX1ZrQ6fseWgqbJCfibm5TGK7/AUanyHta/e44x FxpEg6vHTxzM4eXWualCREsaLfAOJ8XhodajqAbt742HMc/7MBhqNS8Jie1vTnPOBovV Xu180zQM4e7u0+Wh0793dVvxACkraACvchme3mSzsbAzXyhklRYIYUAuk9vgDhutUsV9 5vqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+4JrVpH3Roe6u3s6G0Qp/w9AVkvUtvbqqJBBDL+PHiE=; b=gXpraXwGuBUXQYZvflwtJwaHKDt2R37B56EHjy7X+zv5x3C8/gx+PbCwqW8lEvMEfT okIp0EdJtIBGExoGYQba0KktEgQlB++jLKMHIlKZ58FwOtO6Z8JoBoIvqWgqXYkA+87c YoNcYUXzmMKHLkC1oungZ0gCHDbbg6dKEh18EH0nb6ZGMYIB9GHKUndnKbaRu/WxafXy XfmEdopgGmTKYDU8bgNvOTU/iVhVu9ol2WA+YVzGGu3I1lzCxBDIsIv+z48j0yizkon2 o7InO6kYENyIADi6m8eHbZ5UTrfqZjgtopKQXZ2oqSg3Zg+7EEWi9HeRKsxqyznKMiPW MHRw== X-Gm-Message-State: AEkoouu749z8uJ+0nBvHyCuueoWNBDGN8vz87zu4skFxFM6uiAzJ+uQ+QJRUlbvZCtip0g== X-Received: by 10.66.160.41 with SMTP id xh9mr127458458pab.85.1470317420745; Thu, 04 Aug 2016 06:30:20 -0700 (PDT) Received: from [10.0.1.3] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id p14sm20658957par.32.2016.08.04.06.30.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 06:30:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13G34) In-Reply-To: <57A0587C.9090102@alvestrand.no> Date: Thu, 4 Aug 2016 06:30:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <72E44150-3DE9-4718-9904-5CD0A2A0E317@gmail.com> References: <57A0587C.9090102@alvestrand.no> To: Harald Alvestrand Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fix for DSCP bleaching issue suggested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:30:24 -0000 On Aug 2, 2016, at 01:23, Harald Alvestrand wrote: >=20 > My proposed text for the DSCP blocking/bleaching issue is here: >=20 > https://github.com/rtcweb-wg/rtcweb-transport/pull/30 >=20 > Note that this differs from what was said at the IETF meeting - after > considering, I didn't see a reason to recommend ICE restart. >=20 > The text does not contain MUST or SHOULD. This is implementation advice. > Is this approprate, given the current state of our knowledge of the issue?= >=20 > Diff: >=20 > @@ -344,6 +344,18 @@ > of packets with certain DSCP markings. The detection of these > conditions is implementation dependent. >=20 > + A particularly hard problem is when one media transport uses > + multiple DSCP code points, where one may be blocked and another > may be > + allowed. This is allowed for video in + target=3D"I-D.ietf-tsvwg-rtcweb-qos"/>. Implementations need to > diagnose > + this scenario; one possible implementation is to send initial ICE= > + probes with DSCP 0, [BA]Seems reasonable. > and send ICE probes on all the DSCP code points > + that are intended to be used once a candidate pair has been > selected. [BA] Not sure what "probe" means here - are you referring to keepalives and/= or consent checks? > + If one or more of the DSCP-marked probes fail, the sender will > switch > + the transport to using DSCP 0. This can be carried out > simultaneously > + with the initial media traffic; on failure, the initial data > may need > + to be resent. [BA] Losing a single consent check does not tell you much, and if some conse= nt checks with a marking were responded to, changing markings based on a sub= sequent loss is most probably a bad idea. Does "resent" refer to RFC 4588 (R= TX)?=20 > + > All packets carrying data from the SCTP association > supporting the > data channels MUST use a single DSCP code point. The code point > used > SHOULD be that recommended by =20 > Comments welcome, especially if they come today! - the item is on > Thursday's telechat, and it would be nice to release a fixed version > well before the telechat. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Aug 4 06:43:24 2016 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 E5E0A12B031 for ; Thu, 4 Aug 2016 06:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=Tfmp3cjk; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=tJHTjHh7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkBC4n5csOnM for ; Thu, 4 Aug 2016 06:43:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DDD12D1CA for ; Thu, 4 Aug 2016 06:43:18 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EA467202ED; Thu, 4 Aug 2016 09:43:17 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 04 Aug 2016 09:43:17 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=x2ziY hz8srRjB/JhghmYX8VR88o=; b=Tfmp3cjkbw7RWqTFdpHGQw2Rg9buk8ixPLp/m iBIHgrk2SI9M84RHpf1Jzap3wtYnDMPkYLg1Wfq7YKqU0EaBHkGwblHcHHB26GCa SVhNNq8W5eJFJUf72CQ3ZDw5sFvalN4Wj/tIZY34Qq1cvMG0EalK8uyPzO/rFsbt Ja8BSA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=x2ziYhz8srRjB/JhghmYX8VR88o=; b=tJHTj Hh7IqxVz7A41fPTSxzOPsTZ5GDvK0Q30NqQMCY3jTmkl4BzAPrfgbTHfmHhECAj6 fl9jF3cXrZ4W1V9UWG7w38N8SB6nE2e2VQSPcrRCkL1iTUQkiqt3BXXgqHX9/YLZ vVh8wx+gUHpiV3lcQWv8zy4x8DpPZ0r6rPC1v0= X-Sasl-enc: Xam+QlBCMhbDmZ2PEPn0pWv5xvYw/WWjlhScZW+2420g 1470318197 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 5EBE0F2D2C; Thu, 4 Aug 2016 09:43:17 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_30CD94EF-6DBE-4491-92F0-D16F5E1E7601" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Thu, 4 Aug 2016 06:43:15 -0700 Message-Id: References: To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:43:22 -0000 --Apple-Mail=_30CD94EF-6DBE-4491-92F0-D16F5E1E7601 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you, Harald, for processing all the comments so efficiently. > On Aug 4, 2016, at 3:45 AM, Harald Alvestrand = wrote: >=20 > I have submitted -15 and closed those issues that I believe it = resolves. > There are six left in the tracker: One I forgot (#40), one raised = today > in the IESG (#41), and Andy's "RETURN reference" issue (#42), as well = as > 3 issues where I suggested "no change" as a resolution. >=20 > Comments welcome! >=20 > Note - I believe #41 and #42 are technical changes, so should formally > require IESG re-processing. I believe the others are editorial in > nature, so can be done without a new IESG pass. For #41, Mirja has suggested the following text: "For transport of media, secure RTP is used. The details of the profile = of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C This is non-normative text suggested in a non-blocking comment, and = it=E2=80=99s up to the WG to decide whether to include it. But whether = or not it gets included, if the text is along the lines that she = suggests then the document will not have to be re-processed by the IESG. For #42, the issue is mentioned in the shepherd write-up = >, so the IESG has already had visibility into it. My comment in = AD evaluation was that I wanted to see the text added to the document, = rather than included as an RFC Editor=E2=80=99s note. I believe the = shepherd write-up indicates that the chairs believe there is consensus = to include some non-normative text about this. So I don=E2=80=99t think = this needs to go back to the IESG if it is added assuming the return bit = is non-normative, but I do think whatever text the WG settles on should = be included in the next rev before this doc goes to the RFC Editor. Thanks, Alissa >=20 > Harald >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_30CD94EF-6DBE-4491-92F0-D16F5E1E7601 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you, Harald, for processing all the = comments so efficiently.

On Aug 4, 2016, at 3:45 AM, = Harald Alvestrand <harald@alvestrand.no> wrote:

I = have submitted -15 and closed those issues that I believe it = resolves.
There are six left in the tracker: One I forgot = (#40), one raised today
in the IESG (#41), and Andy's = "RETURN reference" issue (#42), as well as
3 issues where = I suggested "no change" as a resolution.

Comments welcome!

Note - I = believe #41 and #42 are technical changes, so should formally
require IESG re-processing. I believe the others are = editorial in
nature, so can be done without a new IESG = pass.

For #41, Mirja has suggested the following = text:

"For transport of media, = secure RTP is used.  The details of the profile of RTP used are = described in "RTP Usage=E2=80=9C [I-D.ietf-rtcweb-rtp-usage], which = mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further = guidance).=E2=80=9C

This is = non-normative text suggested in a non-blocking comment, and it=E2=80=99s = up to the WG to decide whether to include it. But whether or not it gets = included, if the text is along the lines that she suggests then the = document will not have to be re-processed by the IESG.

For #42, the issue is mentioned in the shepherd = write-up <https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/s= hepherdwriteup/>, so the IESG has already had visibility into it. = My comment in AD evaluation was that I wanted to see the text added to = the document, rather than included as an RFC Editor=E2=80=99s note. I = believe the shepherd write-up indicates that the chairs believe there is = consensus to include some non-normative text about this. So I don=E2=80=99= t think this needs to go back to the IESG if it is added assuming the = return bit is non-normative, but I do think whatever text the WG settles = on should be included in the next rev before this doc goes to the RFC = Editor.

Thanks,
Alissa


Harald

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

= --Apple-Mail=_30CD94EF-6DBE-4491-92F0-D16F5E1E7601-- From nobody Thu Aug 4 06:46:31 2016 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 41C2F12D54C for ; Thu, 4 Aug 2016 06:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=xqfdu9EK; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=HZggB6R/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBAXBU7LvNWi for ; Thu, 4 Aug 2016 06:46:28 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD9E12B025 for ; Thu, 4 Aug 2016 06:46:28 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A15ED207CD; Thu, 4 Aug 2016 09:46:27 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 04 Aug 2016 09:46:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=TNAWk sL8LRT6IR/XeIabW/+f0TM=; b=xqfdu9EKoDiWCMJidqpfwKJBd9ziEfqn/rGeG kGOEgqXq7B2XyEbm33x5Qrimo/eQXbzeFbsyFmBrTiwOMrustQyBg6UX37vM6MzV J6DRDnFu3cYpfw6mux9HXkiA2o5yaTEwYF9eJIETLCODn+k2OkhvYVjdzEkjmAg4 zCgbGQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=TNAWksL8LRT6IR/XeIabW/+f0TM=; b=HZggB 6R/OuEYJiXZBc1ITgalMfqP0gyokNoNvqQNk2UYqwsahj1Yfox/7WaGtcpyL3w9d km96Y9AWzh5NJJx2KP/YhT6d81/ouv/xsE2E3XkAjRCPFipd7VyNADbaT1C5k9Fc YT3Iz7iKk3knGqoA+B9C6aHUw0q92720R5aAK8= X-Sasl-enc: yIEAow9GJYOCT9oKeyUjUIf9TFwY3yG6TKDj4lqTUIkz 1470318387 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 03733F2D2B; Thu, 4 Aug 2016 09:46:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C31FDAC4-575B-487E-BA93-6D9E92DA108F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Thu, 4 Aug 2016 06:46:25 -0700 Message-Id: <2076CAA8-A1A0-4FA9-8F20-888BC2FAE36F@cooperw.in> References: To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:46:30 -0000 --Apple-Mail=_C31FDAC4-575B-487E-BA93-6D9E92DA108F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 4, 2016, at 6:43 AM, Alissa Cooper wrote: >=20 > Thank you, Harald, for processing all the comments so efficiently. >=20 >> On Aug 4, 2016, at 3:45 AM, Harald Alvestrand > wrote: >>=20 >> I have submitted -15 and closed those issues that I believe it = resolves. >> There are six left in the tracker: One I forgot (#40), one raised = today >> in the IESG (#41), and Andy's "RETURN reference" issue (#42), as well = as >> 3 issues where I suggested "no change" as a resolution. >>=20 >> Comments welcome! >>=20 >> Note - I believe #41 and #42 are technical changes, so should = formally >> require IESG re-processing. I believe the others are editorial in >> nature, so can be done without a new IESG pass. >=20 > For #41, Mirja has suggested the following text: >=20 > "For transport of media, secure RTP is used. The details of the = profile of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C >=20 > This is non-normative text suggested in a non-blocking comment, and = it=E2=80=99s up to the WG to decide whether to include it. But whether = or not it gets included, if the text is along the lines that she = suggests then the document will not have to be re-processed by the IESG. Apologies, before I sent this I failed to see that Mirja changed her = ballot position from COMMENT to DISCUSS. So this issue requires a = resolution before the document can be approved for publication. Alissa= --Apple-Mail=_C31FDAC4-575B-487E-BA93-6D9E92DA108F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 4, 2016, at 6:43 AM, Alissa Cooper <alissa@cooperw.in> = wrote:

Thank you, Harald, for processing all the comments so = efficiently.

On Aug 4, 2016, at 3:45 AM, Harald = Alvestrand <harald@alvestrand.no> wrote:

I = have submitted -15 and closed those issues that I believe it = resolves.
There are six left in the tracker: One I forgot = (#40), one raised today
in the IESG (#41), and Andy's = "RETURN reference" issue (#42), as well as
3 issues where = I suggested "no change" as a resolution.

Comments welcome!

Note - I = believe #41 and #42 are technical changes, so should formally
require IESG re-processing. I believe the others are = editorial in
nature, so can be done without a new IESG = pass.

For #41, Mirja has suggested the = following text:

"For transport of media, secure RTP is used.  The = details of the profile of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further = guidance).=E2=80=9C

This is non-normative text suggested in a non-blocking = comment, and it=E2=80=99s up to the WG to decide whether to include it. = But whether or not it gets included, if the text is along the lines that = she suggests then the document will not have to be re-processed by the = IESG.

Apologies, before I sent this I failed to see that = Mirja changed her ballot position from COMMENT to DISCUSS. So this issue = requires a resolution before the document can be approved for = publication.

Alissa
= --Apple-Mail=_C31FDAC4-575B-487E-BA93-6D9E92DA108F-- From nobody Thu Aug 4 06:51:14 2016 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 E92EC12D91D; Thu, 4 Aug 2016 06:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=EiKHDOpQ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=bMe/1I/2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQMscUg-arGU; Thu, 4 Aug 2016 06:51:04 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99DF12D901; Thu, 4 Aug 2016 06:51:04 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 008D320719; Thu, 4 Aug 2016 09:51:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 04 Aug 2016 09:51:04 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=11ygT BHGTBA9rcIdxTVqoUrherU=; b=EiKHDOpQnFCH5zqdl2/SDNIy7j7oRYkmkEGP3 lzdqBysC+gINkNAhTI+15MkFk2gY8bFVr4/MXjpAGDnDKk5EzOK6HXoZerUcA/K5 AUMV0Fbv0ttbNODSd+tEPE1wzq1ANXwBXRt6oCorS0VcyqYyGpDb78nt5tRmNrrV 1thnrI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=11ygTBHGTBA9rcIdxTVqoUrherU=; b=bMe/1 I/2US/2njMRGIHbOTgxVMZZHLL3IPAZPj587NTkvNx45tZYjjfAIOoDhghH34hIX ZnvQCCIRfGN8Fdvo2J2aLv/oseh2xdRuVZ0KoJYnb5veUmW8FZYSoH3CDd/n8k90 OFNVpaC48/Gimc8IH8Rf527wZDCWym+Fcpo4gw= X-Sasl-enc: 6qB4avcZZRzCb15ihrJA36py2yOtdiYyFFKHTHxI1b/F 1470318663 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id E9D17F29D9; Thu, 4 Aug 2016 09:51:02 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F7223A3E-C85E-4087-BE90-6BF9B0E1D6BC" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <20160804091953.15852.31672.idtracker@ietfa.amsl.com> Date: Thu, 4 Aug 2016 06:51:01 -0700 Message-Id: References: <20160804091953.15852.31672.idtracker@ietfa.amsl.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtcweb-chairs@ietf.org, RTCWeb IETF , IESG , draft-ietf-rtcweb-transports@ietf.org Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-rtcweb-transports-14=3A_=28with_DISCUSS=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:51:07 -0000 --Apple-Mail=_F7223A3E-C85E-4087-BE90-6BF9B0E1D6BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 4, 2016, at 2:19 AM, Mirja Kuehlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-rtcweb-transports-14: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks, I think this is a very useful and well written document. Sorry > for my late discuss but I don't think this is anything complicated to > address. > Based on the TSV review I agree that this document should say more = about > congestion control. While the TSV reviewer (Thanks Allison!) only > proposes to refer draft-ietf-avtcore-rtp-circuit-breakers-17 and > draft-ietf-rmcat-cc-requirements-09, I would even prefer to have a > normative sentence that says that congestion control MUST be = implemented > for all traffic flows.=20 > Please also provide the update on DSCP black-holing (in the middle of = a > flow) as mentioned by David Black. The new text about this is: A particularly hard problem is when one media transport uses multiple DSCP code points, where one may be blocked and another may be allowed. This is allowed even within a single media flow for video in [I-D.ietf-tsvwg-rtcweb-qos = ]. Implementations need to diagnose this scenario; one possible implementation is to send initial ICE probes with DSCP 0, and send ICE probes on all the DSCP code points that are intended to be used once a candidate pair has been selected. If one or more of the DSCP-marked probes fail, the sender will switch the media type to using DSCP 0. This can be carried out simultaneously with the initial media traffic; on failure, the initial data may need to be resent. This switch will of course invalidate any congestion information gathered up to that point. Failures can also start happening during the lifetime of the call; this case is expected to be rarer, and can be handled by the normal mechanisms for transport failure, which may involve an ICE restart. Note that when a DSCP code point causes non-delivery, one has to switch the whole media flow to DSCP 0, since all traffic for a single media flow needs to be on the same queue for congestion control purposes. Other flows on the same transport, using different DSCP code points, don't need to change. Alissa >=20 >=20 >=20 >=20 --Apple-Mail=_F7223A3E-C85E-4087-BE90-6BF9B0E1D6BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 4, 2016, at 2:19 AM, Mirja Kuehlewind <ietf@kuehlewind.net>= wrote:

Mirja K=C3=BChlewind has entered the following ballot = position for
draft-ietf-rtcweb-transports-14: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/<= /a>



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks, I think this is a very = useful and well written document. Sorry
for my late = discuss but I don't think this is anything complicated to
address.
Based on the TSV review I agree that = this document should say more about
congestion control. = While the TSV reviewer (Thanks Allison!) only
proposes to = refer draft-ietf-avtcore-rtp-circuit-breakers-17 and
draft-ietf-rmcat-cc-requirements-09, I would even prefer to = have a
normative sentence that says that congestion = control MUST be implemented
for all traffic flows.
Please also provide the update on DSCP  black-holing (in = the middle of a
flow) as mentioned by David Black.


A particularly hard problem is when one =
media transport uses multiple
   DSCP code points, where one may be blocked and another may be
   allowed.  This is allowed even within a single media flow for video
   in [I-D.ietf-tsvwg-rtcweb-qos].  =
Implementations need to diagnose
   this scenario; one possible implementation is to send initial ICE
   probes with DSCP 0, and send ICE probes on all the DSCP code points
   that are intended to be used once a candidate pair has been selected.
   If one or more of the DSCP-marked probes fail, the sender will switch
   the media type to using DSCP 0.  This can be carried out
   simultaneously with the initial media traffic; on failure, the
   initial data may need to be resent.  This switch will of course
   invalidate any congestion information gathered up to that point.

   Failures can also start happening during the lifetime of the call;
   this case is expected to be rarer, and can be handled by the normal
   mechanisms for transport failure, which may involve an ICE restart.

   Note that when a DSCP code point causes non-delivery, one has to
   switch the whole media flow to DSCP 0, since all traffic for a single
   media flow needs to be on the same queue for congestion control
   purposes.  Other flows on the same transport, using different DSCP
   code points, don't need to change.

Alissa






= --Apple-Mail=_F7223A3E-C85E-4087-BE90-6BF9B0E1D6BC-- From nobody Thu Aug 4 06:58:26 2016 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 BD43F12B00E; Thu, 4 Aug 2016 06:58:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160804135822.15952.16587.idtracker@ietfa.amsl.com> Date: Thu, 04 Aug 2016 06:58:22 -0700 Archived-At: Cc: rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-transports@ietf.org Subject: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-rtcweb-transports-15=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 13:58:23 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-rtcweb-transports-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for updating! Leaving it to this comment: Based on the TSV review I agree that this document (named "Transports for WebRTC") should say more about congestion control. The TSV reviewer (Thanks Allison!) proposes to refer draft-ietf-avtcore-rtp-circuit-breakers-17 and draft-ietf-rmcat-cc-requirements-09. I would even appreciate to have a sentence that says that congestion control and a circuit breaker is mandated in draft-ietf-rtcweb-rtp-usage-26. From nobody Thu Aug 4 07:05:21 2016 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 C8C8412D95C for ; Thu, 4 Aug 2016 07:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=4VKJXFLU; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=bRe8y+Jt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64ri4W1PhUrM for ; Thu, 4 Aug 2016 07:05:16 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E0012D550 for ; Thu, 4 Aug 2016 07:05:16 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B67C820823; Thu, 4 Aug 2016 10:05:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 04 Aug 2016 10:05:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=elxzm swysYpkIx4B/xkm1YondJs=; b=4VKJXFLUx8t6KJto8JnQiZNTCG+hUlaY8L2e5 q2DuaxFYb1sOEb5ZUaqzShXjcc1TniduiTyXAhJYvvihybW616OsIWDUqNmRxnPi 5ZUUCPQ/K73AtFCk0BDSxd9/4UeieiOR0SHOowFGIxWMsYme3BsyYxzKzZXGsqyN Wi+/hg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=elxzmswysYpkIx4B/xkm1YondJs=; b=bRe8y +JtRZUSDq4lMTk3EVqWv42BsJNE1dEhd7i5lllgT21ECT+IBzZLROV3DdyoHVBRT 3jZTSbajLi46J3nBCUSWf3gLZebcGR858/zZa1iUpzg5EMlUxOzPBHimfvjO1tRL iQzj9rRYGjUlD4BiGcdZzClopf71RuGv2HLSPQ= X-Sasl-enc: 55yFLJMe6fjo4l8nRoXW8zdkGPGp2bMx49aDvJw7JCR8 1470319515 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.178]) by mail.messagingengine.com (Postfix) with ESMTPA id EAD00F29D9; Thu, 4 Aug 2016 10:05:14 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5C08D9B6-9EB7-4EB8-A13C-31DFE5022C20" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <2076CAA8-A1A0-4FA9-8F20-888BC2FAE36F@cooperw.in> Date: Thu, 4 Aug 2016 07:05:13 -0700 Message-Id: References: <2076CAA8-A1A0-4FA9-8F20-888BC2FAE36F@cooperw.in> To: Harald Alvestrand X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 14:05:20 -0000 --Apple-Mail=_5C08D9B6-9EB7-4EB8-A13C-31DFE5022C20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 4, 2016, at 6:46 AM, Alissa Cooper wrote: >=20 >>=20 >> On Aug 4, 2016, at 6:43 AM, Alissa Cooper > wrote: >>=20 >> Thank you, Harald, for processing all the comments so efficiently. >>=20 >>> On Aug 4, 2016, at 3:45 AM, Harald Alvestrand > wrote: >>>=20 >>> I have submitted -15 and closed those issues that I believe it = resolves. >>> There are six left in the tracker: One I forgot (#40), one raised = today >>> in the IESG (#41), and Andy's "RETURN reference" issue (#42), as = well as >>> 3 issues where I suggested "no change" as a resolution. >>>=20 >>> Comments welcome! >>>=20 >>> Note - I believe #41 and #42 are technical changes, so should = formally >>> require IESG re-processing. I believe the others are editorial in >>> nature, so can be done without a new IESG pass. >>=20 >> For #41, Mirja has suggested the following text: >>=20 >> "For transport of media, secure RTP is used. The details of the = profile of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further guidance).=E2=80=9C >>=20 >> This is non-normative text suggested in a non-blocking comment, and = it=E2=80=99s up to the WG to decide whether to include it. But whether = or not it gets included, if the text is along the lines that she = suggests then the document will not have to be re-processed by the IESG. >=20 > Apologies, before I sent this I failed to see that Mirja changed her = ballot position from COMMENT to DISCUSS. So this issue requires a = resolution before the document can be approved for publication. =E2=80=A6 and she has changed ballot positions again back to COMMENT = before the telechat, so I will approve this for publication with a point = raised to await the resolution of the outstanding issues. Alissa >=20 > Alissa > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_5C08D9B6-9EB7-4EB8-A13C-31DFE5022C20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 4, 2016, at 6:46 AM, Alissa Cooper <alissa@cooperw.in> = wrote:


On = Aug 4, 2016, at 6:43 AM, Alissa Cooper <alissa@cooperw.in> = wrote:

Thank you, = Harald, for processing all the comments so efficiently.

On Aug 4, 2016, at 3:45 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

I = have submitted -15 and closed those issues that I believe it = resolves.
There are six left in the tracker: One I forgot = (#40), one raised today
in the IESG (#41), and Andy's = "RETURN reference" issue (#42), as well as
3 issues where = I suggested "no change" as a resolution.

Comments welcome!

Note - I = believe #41 and #42 are technical changes, so should formally
require IESG re-processing. I believe the others are = editorial in
nature, so can be done without a new IESG = pass.

For #41, Mirja has suggested the = following text:

"For transport of media, secure RTP is used.  The = details of the profile of RTP used are described in "RTP Usage=E2=80=9C = [I-D.ietf-rtcweb-rtp-usage], which mandates the use of a circuit breaker = [draft-ietf-avtcore-rtp-circuit-breakers-17] and congestion control (see = [draft-ietf-rmcat-cc-requirements-09] for further = guidance).=E2=80=9C

This is non-normative text suggested in a non-blocking = comment, and it=E2=80=99s up to the WG to decide whether to include it. = But whether or not it gets included, if the text is along the lines that = she suggests then the document will not have to be re-processed by the = IESG.

Apologies, before I sent this I failed = to see that Mirja changed her ballot position from COMMENT to DISCUSS. = So this issue requires a resolution before the document can be approved = for publication.

=E2=80=A6 and she has changed ballot positions = again back to COMMENT before the telechat, so I will approve this for = publication with a point raised to await the resolution of the = outstanding issues.

Alissa


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

= --Apple-Mail=_5C08D9B6-9EB7-4EB8-A13C-31DFE5022C20-- From nobody Thu Aug 4 08:42:56 2016 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 3ECFE12D600 for ; Thu, 4 Aug 2016 08:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 eMS0C0d5AJbc for ; Thu, 4 Aug 2016 08:42:53 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 01295127058 for ; Thu, 4 Aug 2016 08:42:53 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id f6so323871796ith.1 for ; Thu, 04 Aug 2016 08:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FC0RnnmJzVEikjpME2h4kVVEkM6wom24s2XEiobWR0Q=; b=g9GCe+Auz+lOrBQSzNevfsPEjTuc0BBc9Mkwhm62ycmcfHqd+nmSgzfTsQhfSEJCJp 6t4GTfHlO6QZ8IGXWHeNi7M9fRK8MQVGKzGXcFYAQ+YilclxuQ9DekVhpVl22Hk/QXcy KHrnLsaEonQaIZqBJ7L9RQoCdsGkrl3Ri5rdeI+Alnpdzle8jOL3YqiM8Dzy7JkqT6JW kefuQzRVLWzCgLavkw+gmt3VqnRvPlPUFx6bXh69KZzICIpcIZqPYofHTxAQo+o9ptNt 0aVVFZNd5npeJEEVok9LPEL5NKdW4C4jkdQISFrv2WI70J/TajwRe7kF2ubWPbTlsz8E EMcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FC0RnnmJzVEikjpME2h4kVVEkM6wom24s2XEiobWR0Q=; b=V36et+RMHYTTWjc1WArAhNafpwwtbap7QHV0lNICruVAoUTURZ6yHrP8Yd1M6dCAv8 eUNTE5sRZ5rGkCaZ3NLJ4b3l6GKJLy14OwGRMIHFkftJ/8e0KfFF7YZrAWelV1L292LQ 2ZlMt35XSdU1WEEp+2GI6pjHsCQK3ZXuhJjKSUMckPz39vcdzjJl5VVbQQLeTcNx9kq0 CLK1Ju5bXrgadXx38HTffyQDfUCgj8OpTipzx54JwWzyiFoxpJruRTFNRNHx/jvnnX/S PAQimyrJ9DkErMMtrMiKiOPmyhY3FZhHh3GMZxcwmkV4pEadfEKDeNlFfj8MGtIUYpXw WoYQ== X-Gm-Message-State: AEkoousdnKacKhEBggJsmJmJzZqXbb8nHTYyFtaTms1MR0XD2btvtugekUcQYnQK2x1MX4Yb858LPnlPZeYrWg== X-Received: by 10.36.111.65 with SMTP id x62mr6607001itb.32.1470325372202; Thu, 04 Aug 2016 08:42:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.26 with HTTP; Thu, 4 Aug 2016 08:42:51 -0700 (PDT) In-Reply-To: <21a3cec4-c913-d3a9-b3a6-f9ccbb34fb09@alvestrand.no> References: <21a3cec4-c913-d3a9-b3a6-f9ccbb34fb09@alvestrand.no> From: Andy Hutton Date: Thu, 4 Aug 2016 16:42:51 +0100 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1144cb0883dbc7053940cd76 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Transport -15 submitted, still some issues X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 15:42:55 -0000 --001a1144cb0883dbc7053940cd76 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 4, 2016 at 2:05 PM, Harald Alvestrand wrote: > > Den 04. aug. 2016 14:40, skrev Andy Hutton: > > Harald, > > > > I don't think that #42 is really a technical change can you explain why > > why you think it is? > > > > Because it introduces two new drafts that have to be understood in order > to completely understand the specification, one of which is expired. > > While these are at MAY strength, I don't see how it's editorial. Ok understood it is not just editorial however I am not suggesting any change to currently specified procedures only that the procedures are correctly referenced. As I pointed out in my original WGLC comment * https://www.ietf.org/mail-archive/web/rtcweb/current/msg15900.html) the current text regarding how TURN servers are discovered is in my opinion insufficient. I think describing correctly how TURN servers are discovered is an important aspect of the transports draft. The fact that the -return- draft has expired and the fact that the meeting time in Berlin in which we were supposed to discuss it was cancelled is a bit frustrating. I spoke to Ben Schwartz in Berlin and my understanding was that he intends to update the draft. If RETURN is going to be implemented then it is I believe important that transports mentions it. If on the other hand RETURN is not going to be implemented and the draft abandoned then this is also something that should be discussed in the WG. > > > The referencing of -return- was mentioned in te AD evaluation by Alissa > > see https://www.ietf.org/mail-archive/web/rtcweb/current/msg15943.html > > I can't see -return- in the referenced message; where do you see it? > > > > > Andy > > > > On Thursday, 4 August 2016, Harald Alvestrand > > wrote: > > > > I have submitted -15 and closed those issues that I believe it resolves. > > There are six left in the tracker: One I forgot (#40), one raised today > > in the IESG (#41), and Andy's "RETURN reference" issue (#42), as well as > > 3 issues where I suggested "no change" as a resolution. > > > > Comments welcome! > > > > Note - I believe #41 and #42 are technical changes, so should formally > > require IESG re-processing. I believe the others are editorial in > > nature, so can be done without a new IESG pass. > > > > Harald > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a1144cb0883dbc7053940cd76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 4, 2016 at 2:05 PM, Harald Alvestrand = <harald@alvest= rand.no> wrote:
>
> Den 04. aug. 2016 14:40, skrev Andy = Hutton:
> > Harald,
> >
> > I don't think th= at #42 is really a technical change can you explain why
> > why yo= u think it is?
> >
>
> Because it introduces two new d= rafts that have to be understood in order
> to completely understand = the specification, one of which is expired.
>
> While these are= at MAY strength, I don't see how it's editorial.

Ok understood it is not just editorial however I am not suggesting any ch= ange to currently specified procedures only that the procedures are correct= ly referenced.=C2=A0 As I pointed out in my original WGLC comment *htt= ps://www.ietf.org/mail-archive/web/rtcweb/current/msg15900.html) the cu= rrent text regarding how TURN servers are discovered is in my opinion insuf= ficient.

I think describing correctly how TURN ser= vers are discovered is an important aspect of the transports draft.

The fact that the -return- draft has expired and the fact= that the meeting time in Berlin in which we were supposed to discuss it wa= s cancelled is a bit frustrating. I spoke to Ben=C2=A0Schwartz in Berlin and my understanding was= that he intends to update the draft. If RETURN is going to be implemented = then it is I believe important that transports mentions it.

If on the other hand= RETURN is not going to be implemented and the draft abandoned then this is= also something that should be discussed in the WG.


>
> > The referencing of -return- was mentioned in= te AD evaluation by Alissa
> > see https://= www.ietf.org/mail-archive/web/rtcweb/current/msg15943.html
>
&= gt; I can't see -return- in the referenced message; where do you see it= ?
>
> >
> > Andy
> >
> > On Thurs= day, 4 August 2016, Harald Alvestrand <harald@alvestrand.no
> > <mailto:<= a href=3D"mailto:harald@alvestrand.no" target=3D"_blank">harald@alvestrand.= no>> wrote:
> >
> > =C2=A0 =C2=A0 I have submit= ted -15 and closed those issues that I believe it resolves.
> > = =C2=A0 =C2=A0 There are six left in the tracker: One I forgot (#40), one ra= ised today
> > =C2=A0 =C2=A0 in the IESG (#41), and Andy's &qu= ot;RETURN reference" issue (#42), as well as
> > =C2=A0 =C2= =A0 3 issues where I suggested "no change" as a resolution.
&g= t; >
> > =C2=A0 =C2=A0 Comments welcome!
> >
> &= gt; =C2=A0 =C2=A0 Note - I believe #41 and #42 are technical changes, so sh= ould formally
> > =C2=A0 =C2=A0 require IESG re-processing. I beli= eve the others are editorial in
> > =C2=A0 =C2=A0 nature, so can b= e done without a new IESG pass.
> >
> > =C2=A0 =C2=A0 Har= ald
> >
> > =C2=A0 =C2=A0 _______________________________= ________________
> > =C2=A0 =C2=A0 rtcweb mailing list
> >= ; =C2=A0 =C2=A0 rtcweb= @ietf.org <javascript:;>
> > =C2=A0 =C2=A0 https://www.i= etf.org/mailman/listinfo/rtcweb
> >
--001a1144cb0883dbc7053940cd76-- From nobody Thu Aug 4 14:26:45 2016 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 8D48D12D845 for ; Thu, 4 Aug 2016 14:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ2FodQUzftA for ; Thu, 4 Aug 2016 14:26:40 -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 C4F8912D83F for ; Thu, 4 Aug 2016 14:26:40 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id j185so338578811oih.0 for ; Thu, 04 Aug 2016 14:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=srpYLqG36K/kAFw+cJ5nl/+xPEPHAcnjGVQCtFOj8zo=; b=m+zVDFY0bh38v7q0fP6iLvFdaSMfWMAKcg2pPpqJ1TTmFGpMl1OpakVOIf6kicZLFm fhTxltZ7IjFxDjqk/jUt/N4cK319cIxmiPL3G81ljqsydP0uILtcQhJsqdTJKVDJujCj Wo7HMb6uBACC8rxAUpo7zR6ud1fd3UHRXdYjsHMyRkGHvctAKw7wpLp3c6ciznNttapf y9hfM9W4hHHqsiwpkzD0dDr28CFQ0POpADNWW/uHK1Vv0TwdKtAxzTo11zIK6DWZts0c UpPsIVil9Wjipswzsg1eglU/upjzPOsLGRe4cH9VabxVkysL/8BmX8Rehj1gJgotKLtR fR7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=srpYLqG36K/kAFw+cJ5nl/+xPEPHAcnjGVQCtFOj8zo=; b=K3mRj+q6JgN9zUYZ4NrcEOtR34lZPCBYJ5Qnz2dpZ/XPqGU17O1pFoXiEE0fuS+K0H YnW3zJgQumU4PpcHqwHgk0HwPP4hMbtIJRCrG9hhntTSrdsaDC7WvBlULuLNQTuC0pMY vmO5eS/fgFNJR/HI9z04m98fAeRLFzW97U1sUZpWOTSO5aXKJUzkZetcCOkpRXIszqMl XPbFMrRiOgsTOQ1uv1o0EvkC/3/mHYWfOOTgZyZBnzAr2J0KzxqIq83kN+QOqHzyEnFs Lm0vx08UHCLdiPlZpGZW/2nqxSiMXe3GMW1wBvGMqAdtrjzkcaPDL8qVU4zBqByunbhD ZlkQ== X-Gm-Message-State: AEkoout/51t/RqPHLJsl+Ie+AC2KjbG9hwk1XVNboOG1fo1IUB3BXDT04Z5fBnO6833Y8MX5oTE44qInWRarIg== X-Received: by 10.157.58.53 with SMTP id j50mr47293668otc.118.1470346000054; Thu, 04 Aug 2016 14:26:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Thu, 4 Aug 2016 14:26:09 -0700 (PDT) From: Ted Hardie Date: Thu, 4 Aug 2016 14:26:09 -0700 Message-ID: To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings , Alissa Cooper , "Hutton, Andrew" Content-Type: multipart/alternative; boundary=001a1147191007ccce0539459bb0 Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 21:26:42 -0000 --001a1147191007ccce0539459bb0 Content-Type: text/plain; charset=UTF-8 Howdy, Andy Hutton raised an issue with draft-ietf-rtcweb-transports that was considered during the IESG process (this is github issue 42 ). When the subject of configuration was discussed, the chairs did not see consensus for a normative requirement to support RETURN at this stage. We have therefore recommended that the documents only note the existence of RETURN in the relevant RFC editor note or update. regards, Ted, Sean, Cullen --001a1147191007ccce0539459bb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

Andy Hutton raised an issue with draft-= ietf-rtcweb-transports that was considered during the IESG process (this is= github issue 42).=C2=A0 When the subject of configuration was discussed, the chairs did not see=20 consensus for a normative requirement to support=20 RETURN at this stage.=C2=A0

We have therefore recommended that the = documents=20 only note the existence of RETURN in the relevant RFC editor note or update= .

regards,

Ted, Sean, Cullen
--001a1147191007ccce0539459bb0-- From nobody Fri Aug 5 00:15:56 2016 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 6865912D51A for ; Fri, 5 Aug 2016 00:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] 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 7vOGvngIxpLV for ; Fri, 5 Aug 2016 00:15:52 -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 462CA12D18D for ; Fri, 5 Aug 2016 00:15:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4BEA37C8700 for ; Fri, 5 Aug 2016 09:15:50 +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 BZSdeLx1Wa4V for ; Fri, 5 Aug 2016 09:15:48 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:58ed:6238:cae5:99a5] (unknown [IPv6:2001:470:de0a:1:58ed:6238:cae5:99a5]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1681B7C863B for ; Fri, 5 Aug 2016 09:15:48 +0200 (CEST) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <969b24f2-0d6b-4f70-4eab-1f74dd99fd2a@alvestrand.no> Date: Fri, 5 Aug 2016 09:15:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7DF823CF0067AD2BCC8BE143" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 07:15:55 -0000 This is a multi-part message in MIME format. --------------7DF823CF0067AD2BCC8BE143 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/04/2016 11:26 PM, Ted Hardie wrote: > Howdy, > > Andy Hutton raised an issue with draft-ietf-rtcweb-transports that was > considered during the IESG process (this is github issue 42 > ). > When the subject of configuration was discussed, the chairs did not > see consensus for a normative requirement to support RETURN at this > stage. > > We have therefore recommended that the documents only note the > existence of RETURN in the relevant RFC editor note or update. Thanks. I assume that this will be a reference of the form "Note that ongoing work, such as [return], may create new rules about how to handle sets of STUN and TURN servers"? Should we also include a reference to turn auto-discovery, such as "Note that ongoing work, such as [return] and [auto-discovery], may create new rules about discovering and managing sets of potential STUN and TURN servers"? > > regards, > > Ted, Sean, Cullen > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Surveillance is pervasive. Go Dark. --------------7DF823CF0067AD2BCC8BE143 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 08/04/2016 11:26 PM, Ted Hardie wrote:
Howdy,

Andy Hutton raised an issue with draft-ietf-rtcweb-transports that was considered during the IESG process (this is github issue 42).  When the subject of configuration was discussed, the chairs did not see consensus for a normative requirement to support RETURN at this stage. 

We have therefore recommended that the documents only note the existence of RETURN in the relevant RFC editor note or update.

Thanks. I assume that this will be a reference of the form "Note that ongoing work, such as [return], may create new rules about how to handle sets of STUN and TURN servers"?

Should we also include a reference to turn auto-discovery, such as "Note that ongoing work, such as [return] and [auto-discovery], may create new rules about discovering and managing sets of potential STUN and TURN servers"?


regards,

Ted, Sean, Cullen


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



-- 
Surveillance is pervasive. Go Dark.
--------------7DF823CF0067AD2BCC8BE143-- From nobody Fri Aug 5 09:32:49 2016 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 D8DB612D189 for ; Fri, 5 Aug 2016 09:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 alEZFeQIdjWu for ; Fri, 5 Aug 2016 09:32:46 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE34112D8B1 for ; Fri, 5 Aug 2016 09:32:46 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id l203so36425986oib.1 for ; Fri, 05 Aug 2016 09:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LRLr7qOUGti1ar8vbnMLQFL23HTB7N9JaKkMX2CcPjk=; b=Ks6DeQMlDeSfPGcCwFSaJpMfO9JLYpTo0s0/t3z59IyOPtds1kNXkOczFV2T0cRgpc uNcfcV3hrd4yN6mx2NkrB/8s+WGzWDZJs7g43jRfuoekyEfCqVatjd6cqGFDOLBm+fHD fbV65X/uadCW4kkvnQr3EaKXh+VhMggooBzW9L2OiJr7urgpWQjIZY/RXbEmBExSr1R5 Sk/6IIg4e/pD9Dj6pbJqex3TzNE7sR4QsqZc2FqRkOQqnRYEYZ+lZzyXDMfQgLtzIb2p NTvRcl7cl8zTXbu43eRk7k4RGY5zbaxEj7rTV+kG5FOEat9XTD7lVYT3H3sWydQsH8yz Yryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LRLr7qOUGti1ar8vbnMLQFL23HTB7N9JaKkMX2CcPjk=; b=Mi7GxAYhRh4RdicEdx/FyiGRFUM7JoHrzWBDQ8b8USRSXctw/grtRvx5ZScbkMsoLk rJdf5sfMstNPogt2f+AYf5S8HCctvFI6rrHzuNoye23bYXxocrrdFZHrrvJRomO5sz51 aTeKPB5p4ex74N9qbj2doY4mb7YRPK2LmK7CmlJ2NPoGCh8jVF8c3+85f+LWFYhJjTr3 8qzmAFR8JwpcfZorxCPKPltySCqgQjHGZMkH1oIefMkmbiznoLSBykhyqjaXQkplM6FS 0jXQ6tZc1UaH1JVee1jjgzLuiF3LzzbYCVD5GVNVjSNvAZl28xL9tEuIgEaLp9spzrNW ghSg== X-Gm-Message-State: AEkoouvxyZjWAMaDhEuFfNFq5qP7ld3gEnQ5uIZOAITCsMkef/TRhd3T4K/zy9HeD4jz/YqojOmbAmsuyFTZ3Q== X-Received: by 10.157.14.77 with SMTP id n13mr40089otd.118.1470414766038; Fri, 05 Aug 2016 09:32:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.222.213 with HTTP; Fri, 5 Aug 2016 09:32:15 -0700 (PDT) In-Reply-To: <969b24f2-0d6b-4f70-4eab-1f74dd99fd2a@alvestrand.no> References: <969b24f2-0d6b-4f70-4eab-1f74dd99fd2a@alvestrand.no> From: Ted Hardie Date: Fri, 5 Aug 2016 09:32:15 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113de2b6cdcf3b0539559d50 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-transports X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 16:32:49 -0000 --001a113de2b6cdcf3b0539559d50 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 5, 2016 at 12:15 AM, Harald Alvestrand wrote: > On 08/04/2016 11:26 PM, Ted Hardie wrote: > > Howdy, > > Andy Hutton raised an issue with draft-ietf-rtcweb-transports that was > considered during the IESG process (this is github issue 42 > ). > When the subject of configuration was discussed, the chairs did not see > consensus for a normative requirement to support RETURN at this stage. > > We have therefore recommended that the documents only note the existence > of RETURN in the relevant RFC editor note or update. > > > Thanks. I assume that this will be a reference of the form "Note that > ongoing work, such as [return], may create new rules about how to handle > sets of STUN and TURN servers"? > > Should we also include a reference to turn auto-discovery, such as "Note > that ongoing work, such as [return] and [auto-discovery], may create new > rules about discovering and managing sets of potential STUN and TURN > servers"? > > That sounds like a reasonable way forward, thanks. Ted > > regards, > > Ted, Sean, Cullen > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a113de2b6cdcf3b0539559d50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 5, 2016 at 12:15 AM, Harald Alvestrand <ha= rald@alvestrand.no> wrote:
=20 =20 =20
On 08/04/2016 11:26 PM, Ted Hardie wrote:
Howdy,

Andy Hutton raised an issue with draft-ietf-rtcweb-transports that was considered during the IESG process (this is github issue 42).=C2=A0 When the subject of configuration was discussed, the chairs did not see consensus for a normative requirement to support RETURN at this stage.=C2= =A0

We have therefore recommended that the documents only note the existence of RETURN in the relevant RFC editor note or update.

Thanks. I assume that this will be a reference of the form "Note that ongoing work, such as [return], may create new rules about how to handle sets of STUN and TURN servers"?

Should we also include a reference to turn auto-discovery, such as "Note that ongoing work, such as [return] and [auto-discovery], ma= y create new rules about discovering and managing sets of potential STUN and TURN servers"?

That sounds like a reasonable way forward, = thanks.

Ted

=C2=A0

regards,

Ted, Sean, Cullen


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



--=20
Surveillance is pervasive. Go Dark.

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

--001a113de2b6cdcf3b0539559d50-- From nobody Fri Aug 5 14:28:12 2016 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 6055B12D10F; Fri, 5 Aug 2016 14:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=b79rsEEe; dkim=pass (1024-bit key) header.d=emc.com header.b=S0REk2V3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z48e-JGYJz5g; Fri, 5 Aug 2016 14:28:03 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 D19BD12B041; Fri, 5 Aug 2016 14:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1470432482; x=1501968482; h=from:to:cc:subject:date:message-id:mime-version; bh=WW+cTAPhIjSkr9HzxFLxazyxTPxq3fUjab8sedKnFnE=; b=b79rsEEeLUQMG8ydC88MxEzUwlP1/6JAarCy9SRj1dINo5Ltl24shCEM KWScYvilRn44C9Ozc9y/oVbzn45AQLyq4Cee092v2mjp4C29w1pgGqwxZ 28qTRd6Wr2LYFVGwzecq0nEpVoNRu3IzYqOk6t2tW3rqdN4WzorniNz+n A=; Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Aug 2016 02:28:00 +0500 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u75LRwZo028034 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Aug 2016 17:27:59 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u75LRwZo028034 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1470432480; bh=US0lStD2+G21i/r2mt09FqFk6+M=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=S0REk2V38MCSCQbnQ9MFD8keOsm53DFXlWW+pAgrjm6DjHs8+Q1B/FgJm27AXSVf4 gUdrBxyBozwHh8341ljVcjDz1xmH4b36aQPFKkmcGorSQjQ38kW2p9QNG9XLlvq5Sc JfwdRnzX3ijN/JFnFjfhTjDHBzU5Atu0Qs9PBCTI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u75LRwZo028034 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 5 Aug 2016 17:26:30 -0400 Received: from MXHUB319.corp.emc.com (MXHUB319.corp.emc.com [10.146.3.97]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u75LRc9W012134 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 5 Aug 2016 17:27:38 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB319.corp.emc.com ([10.146.3.97]) with mapi id 14.03.0266.001; Fri, 5 Aug 2016 17:27:38 -0400 From: "Black, David" To: Spencer Dawkins at IETF Thread-Topic: Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos - Proposed text Thread-Index: AdHvYC7KgFdWfRgNTs2rskWrM/Pw/A== Date: Fri, 5 Aug 2016 21:27:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.116] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362F62A6EEMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: [rtcweb] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos - Proposed text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 21:28:06 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362F62A6EEMX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIC0xNSB2ZXJzaW9uIG9mIHRoZSBydGN3ZWItdHJhbnNwb3J0cyBkcmFmdCBoYXMgbm93IGJl ZW4gcG9zdGVkLCBhbmQgdGhlIG5ldyB0ZXh0IG9uIG5vbi16ZXJvIERTQ1BzIGJsYWNrLWhvbGlu ZyB0cmFmZmljIGlzIGluIFNlY3Rpb24gNC4yIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0xNSNzZWN0aW9uLTQuMikuICBNYW55IHRoYW5r cyB0byBIYXJhbGQgZm9yIGFkZGluZyB0aGlzIHRleHQuDQoNClRoZSB0c3Z3Zy1ydGN3ZWItcW9z IGRyYWZ0IG5lZWRzIHRvIG5vdGUgdGhpcyBpc3N1ZSBhbmQgcG9pbnQgdG8gdGhhdCBzZWN0aW9u IG9mIHRoZSBydGN3ZWItdHJhbnNwb3J0cyBkcmFmdC4gIEhlcmXigJlzIHByb3Bvc2VkIHRleHQg dG8gZG8gdGhhdCwgd2hpY2ggSSBzdWdnZXN0IGluc2VydGluZyBhcyBhIG5ldyBwYXJhZ3JhcGgg aW4gU2VjdGlvbiA1IGltbWVkaWF0ZWx5IGJlZm9yZSBGaWd1cmUgMSAoaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0xNyNzZWN0aW9uLTUpOg0K DQogICBXZWJSVEMgdXNlIG9mIG11bHRpcGxlIERTQ1AgdmFsdWVzIG1heSBlbmNvdW50ZXIgbmV0 d29yayBibG9ja2luZyBvZiBwYWNrZXRzDQogICB3aXRoIGNlcnRhaW4gRFNDUCB2YWx1ZXMuICAg U2VlIHNlY3Rpb24gNC4yIG9mIFtJLUQuaWV0Zi1ydGN3ZWItdHJhbnNwb3J0c10gIGZvcg0KICAg ZnVydGhlciBkaXNjdXNzaW9uLCBpbmNsdWRpbmcgaG93IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMg ZXN0YWJsaXNoIGFuZA0KICAgbWFpbnRhaW4gY29ubmVjdGl2aXR5IHdoZW4gc3VjaCBibG9ja2lu ZyBpcyBlbmNvdW50ZXJlZC4NCg0KSSBob3BlIHNvbWV0aGluZyB0aGlzIHNob3J0IGFuZCBzaW1w bGUgd2lsbCBzdWZmaWNlLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KRnJvbTogU3BlbmNlciBEYXdr aW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6 IFR1ZXNkYXksIEF1Z3VzdCAwMiwgMjAxNiAxOjI5IFBNDQpUbzogQmxhY2ssIERhdmlkDQpDYzog QWxpc3NhIENvb3BlcjsgUlRDV2ViIElFVEY7IHRzdndnQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W3J0Y3dlYl0gW3RzdndnXSBGYWxsLWJhY2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYtdHN2d2ct cnRjd2ViLXFvcyA/DQoNCkhpLCBBbGlzc2EgYW5kIERhdmlkLA0KDQpUaGFua3MgdG8gYm90aCBv ZiB5b3UuIEkgZGlkbid0IHNlZSB0aGUgbWludXRlcyBvbiB0aGUgUHJvY2VlZGluZ3MgcGFnZSBi dXQgZGlkbid0IHRoaW5rIHRvIGxvb2sgZm9yIGRyYWZ0IG1pbnV0ZXMgb24gdGhlIG1haWxpbmcg bGlzdC4NCg0KVmVyeSBoZWxwZnVsLg0KDQpTcGVuY2VyDQoNCk9uIE1vbiwgQXVnIDEsIDIwMTYg YXQgNToxMiBQTSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpkYXZp ZC5ibGFja0BlbWMuY29tPj4gd3JvdGU6DQo+IFRoZSAtcnRjd2ViLXRyYW5zcG9ydHMgYXV0aG9y IEhhcmFsZCBBbHZlc3RyYW5kIHRvb2sgb24gdGhlIGFjdGlvbiBpdGVtIGFuZCB3aWxsIHdvcmsg d2l0aCBKdXN0aW4gVWJlcnRpIHRvIHNlbmQgYSB0ZXh0IHByb3Bvc2FsIHRvIHRoZSBsaXN0Lg0K QW5kIHdoZW4gdGhhdCB0ZXh0IGFwcGVhcnMsIHdlIGNhbiBmaWd1cmUgb3V0IHRoZSB3b3JkaW5n IChwcm9iYWJseSBhIHNob3J0IHNlbnRlbmNlKSB0byBhZGQgdG8gdGhlIHRzdndnLXJ0Y3dlYi1x b3MgZHJhZnQgdG8gcG9pbnQgdG8gaXQgb3ZlciBpbiB0aGUgcnRjd2ViLXRyYW5zcG9ydHMgZHJh ZnQuDQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxp c3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPl0NClNlbnQ6IE1vbmRheSwg QXVndXN0IDAxLCAyMDE2IDQ6NDYgUE0NClRvOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURg0KQ2M6 IEJsYWNrLCBEYXZpZDsgUlRDV2ViIElFVEY7IHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBbdHN2d2ddIEZhbGwtYmFjayB0byBEU0NQ IDAgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zID8NCg0KSGkgU3BlbmNlciwNCg0KT24g QXVnIDEsIDIwMTYsIGF0IDY6NTYgQU0sIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2Vy ZGF3a2lucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5j b20+PiB3cm90ZToNCg0KSGksIGFsbCwNCg0KT24gVGh1LCBKdWwgMTQsIDIwMTYgYXQgNDoxMyBQ TSwgQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5ibGFja0Bl bWMuY29tPj4gd3JvdGU6DQpNYWdudXMsDQoNCkkgdGhpbmsgdGhhdCdzIGEgZmluZSBzdWdnZXN0 aW9uLiAgIEkgdGhpbmsgdGhlIG5leHQgc3RlcCBpczoNCg0KPiAzLiBUaGUgbmF0dXJhbCBwbGFj ZSB0byBpbmRpY2F0ZSB0aGUgbmVlZC9yZWNvbW1lbmRhdGlvbiBmb3INCj4gaW1wbGVtZW50aW5n IHRoaXMgZnVuY3Rpb25hbGl0eSB3b3VsZCBiZSBpbiBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3Bv cnRzDQo+IChDdXJyZW50bHkgaW4gSUVURiBMQykuIEhvd2V2ZXIsIGhlcmUgSSB0aGluayB3ZSBu ZWVkIHRvIGhhdmUgYQ0KPiBkaXNjdXNzaW9uIGlmIFJUQ1dFQiBXRyB3YW50cyB0byBvbmx5IHBs YWNlIGEgc3VpdGFibGUgd2FybmluZyBhYm91dCB0aGUNCj4gbmVlZCwgYW5kIGluZGljYXRlIGZ1 dHVyZSBmb3J0aGNvbWluZyBzcGVjaWZpY2F0aW9uIG9yIGlmIHdlIGhvbGQgdGhpcw0KPiBkb2N1 bWVudCB1cCB1bnRpbCB0aGlzIHNvbHV0aW9uIGlzIGF2YWlsYWJsZT8NCg0KSSdsbCBhdHRlbmQg dGhlIFRodSBSVENXRUIgc2Vzc2lvbiBpbiBCZXJsaW4gdG8gc2VlIGhvdyB0aGlzIGNvbWVzIG91 dCwNCmFmdGVyIHdoaWNoIGl0IHNob3VsZCBiZSBzdHJhaWdodGZvcndhcmQgZm9yIHRoZSBkcmFm dCBhdXRob3JzIGFuZCB5b3Vycw0KdHJ1bHkgdG8gd3JpdGUgdGhlIHNlbnRlbmNlIG9yIHR3byB0 aGF0IGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyB3aWxsDQpuZWVkLg0KDQpJJ20ganVzdCBm b2xsb3dpbmcgdXAgb24gdGhpcyBiZWNhdXNlIHdlIGhhdmUgZHJhZnQtaWV0Zi1ydGN3ZWItdHJh bnNwb3J0cyBvbiB0aGUgdGVsZWNoYXQgYWdlbmRhIHRoaXMgd2VlaywgYW5kIEkgZGlkbid0IHNl ZSBhIGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYyBpbiB0aGUgUlRDV2ViIGFnZW5kYSAob3IgaW4g cG9raW5nIGFyb3VuZCBmb3IgbWludXRlcywgamFiYmVyLCBldGhlcnBhZCwgZXRjKS4NCg0KSGVy ZSBpcyB0aGUgcmVsZXZhbnQgYml0IGZyb20gdGhlIFJUQ1dFQiBtaW51dGVzOg0KDQpEU0NQIEJs YWNrLWhvbGluZyBJc3N1ZQ0KRGF2aWQgQmxhY2sgKFRTVldHIGNvLWNoYWlyKSBwcmVzZW50ZWQg dGhlIERTQ1AgYmxhY2staG9sZSBpc3N1ZSB3aXRoIC1ydGN3ZWItdHJhbnNwb3J0czxodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzLz4g ZHJhZnQgdGhhdCB3YXMgcmVjZW50bHkgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0LiBUaGlzIGlzc3Vl IG5lZWRzIHRvIGJlIHNvbHZlZCBhbmQgZGVzY3JpYmVkLCBldmVuIHRob3VnaCBib3RoIC1ydGN3 ZWItdHJhbnNwb3J0cyBhbmQgdGhlIHJlZmVyZW5jZWQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWIt cW9zIGhhcyBnb25lIHRocm91Z2ggSUVTRyByZXZpZXcuIE1hZ251cyBXZXN0ZXJsdW5kIGhhcyBz dWdnZXN0ZWQgYSBzb2x1dGlvbiB0byB0aGUgbGlzdCwgYnV0IHdoYXQgc2hvdWxkIHRoZSAtcnRj d2ViLXRyYW5zcG9ydHMgZHJhZnQgc2F5IGFib3V0IERTQ1AgYmxhY2staG9saW5nIGFuZCB0aGUg cG9zc2liaWxpdHkgdG8gdXNlIElDRSB0byBhdm9pZCBpdD8NClRoZSBXRyBkaXNjdXNzZWQgdGhp cyBhbmQgY29uY2x1ZGVkIHRoYXQgdGhlIGlzc3VlIHNob3VsZCBiZSBkZXNjcmliZWQgYnkgdGhl IC1ydGN3ZWItdHJhbnNwb3J0cyBkcmFmdC4gVGVkIEhhcmRpZSBzdW1tYXJpemVkIHRoZSBkaXNj dXNzaW9uIGJ5IHN1Z2dlc3RpbmcgYSB0ZXh0IGZvcm11bGF0aW9uIGZvciBhIHJlc29sdXRpb24g dGhhdCBzZWVtZWQgYWNjZXB0YWJsZSB0byB0aGUgV0c6IOKAnFdlIHdpbGwgdHJlYXQgRFNDUC1p bmR1Y2VkIHBhdGggZmFpbHVyZSBwYXJhbGxlbCB3aXRoIG90aGVyIHR5cGVzIG9mIHBhdGggZmFp bHVyZXMgYW5kIHJlc29sdmUgaXQgYnkgdXNpbmcgSUNFIHJlc3RhcnQuIE5vdGU6IFRoZXJlIGlz IGEgcHJvYmxlbSB3aXRoIG11bHRpcGxlIERTQ1AgY29kZXBvaW50cyBvbiBhIHNpbmdsZSB0cmFu c3BvcnQsIHdoZXJlIG9uZSBtaWdodCBiZSBibG9ja2VkIGFuZCBvdGhlciBtaWdodCBnZXQgdGhy b3VnaC4gSW4gdGhpcyBjYXNlLCB0aGUgSUNFIHByb2JlcywgdXNpbmcgb25lIERTQ1AgY29kZXBv aW50LCBtYXkgc3VjY2VlZCB3aGlsZSBvdGhlcnMgZmFpbC4gVGhpcyBpcyBjb21wbGV4IGFuZCBz aG91bGQgYmUgd2FybmVkIGFib3V0LiBBIGxpa2VseSB2aWFibGUgc29sdXRpb24gaXMgSUNFIHJl c3RhcnQgd2l0aCBEU0NQIG1hcmtpbmdzIHR1cm5lZCBvZmYsIGJ1dCBkZXRlY3Rpb24gcmVxdWly ZXMgd2F0Y2hpbmcgdGhlIG11bHRpcGxlLURDU1AtY29kZXBvaW50LXVzaW5nIGNoYW5uZWxzIGZv ciBkaWZmZXJlbnRpYWwgZmFpbHVyZXPigJ0uIElmIHRoZXJlIGFyZSBvdGhlciBwcm9wb3NhbHMg Zm9yIHJlc29sdXRpb24sIHBsZWFzZSBjb250YWN0IEhhcmFsZC4gQ3VsbGVuIEplbm5pbmdzIGFz a2VkIERhdmlkIGlmIHRoaXMgc29sdXRpb24gd2FzIGFjY2VwdGFibGUsIGJ1dCBEYXZpZCB3YW50 ZWQgdG8gc2VlIHRoZSB0ZXh0IHByb3Bvc2FsLiBUaGUgLXJ0Y3dlYi10cmFuc3BvcnRzIGF1dGhv ciBIYXJhbGQgQWx2ZXN0cmFuZCB0b29rIG9uIHRoZSBhY3Rpb24gaXRlbSBhbmQgd2lsbCB3b3Jr IHdpdGggSnVzdGluIFViZXJ0aSB0byBzZW5kIGEgdGV4dCBwcm9wb3NhbCB0byB0aGUgbGlzdC4N Cg0KSGFyYWxkIGhhcyBiZWVuIG9uIGhvbGlkYXlzIHNpbmNlIHRoZSBJRVRGIG1lZXRpbmcgYnV0 IHdpbGwgYWltIHRvIGdldCB0byB0aGlzIGJlZm9yZSB0aGUgdGVsZWNoYXQuDQoNCkJlc3QsDQpB bGlzc2ENCg0KDQpEaWQgaXQgaGFwcGVuPyBXYXMgdGhlcmUgYSByZXNvbHV0aW9uPw0KDQpUaGFu a3MsDQoNClNwZW5jZXINCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzptYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT5d DQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE0LCAyMDE2IDQ6NTMgQU0NCj4gVG86IEN1bGxlbiBK ZW5uaW5ncyAoZmx1ZmZ5KTsgQmxhY2ssIERhdmlkDQo+IENjOiBSVENXZWIgSUVURjsgTWljaGFl bCBXZWx6bDsgdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KPiBTdWJqZWN0 OiBSZTogW3RzdndnXSBbcnRjd2ViXSBGYWxsLWJhY2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYt dHN2d2ctcnRjd2ViLXFvcyA/DQo+DQo+IERlbiAyMDE2LTA3LTEyIGtsLiAxODoxOSwgc2tyZXYg Q3VsbGVuIEplbm5pbmdzIChmbHVmZnkpOg0KPiA+DQo+ID4gc2hvcnQgYW5zd2VyIGhlcmUgYnV0 IGFzIERhdmlkIHN1Z2dlc3RlZCDigKYgIHNvbWUgaW1wbGVtZW50YXRpb24gdXNlDQo+ID4gdGhl IFNUVU4gcGFja2V0cyBpbiBJQ0UgIG9yIGp1c3QgIGluIFdlYlJUQyBzdHlsZSBsaXZlbmVzcyB0 ZXN0cyB0bw0KPiA+IGRvIHRoZSB0ZXN0cyBvZiBpZiBhIGdpdmVuIERTQ1Agd29ya3Mgb3Igbm90 LiBJbiBnZW5lcmFsIElDRSBpcyBhDQo+ID4gZ29vZCB0b29sIHRvIHRha2UgYSBidW5jaCBvZiBw b3NzaWJsZSBwYXRocywgdGVzdCB3aGljaCB3b3JrLCBhbmQNCj4gPiBzZWxlY3QgdGhlIGJlc3Qu DQo+DQo+IEkgZG8gYWdyZWUgdGhhdCBob3cgeW91IGRvIHRoZSBwYXRoIGNoZWNrcyB3aGVuIHNl dHRpbmcgRFNDUCB2YWx1ZXMgIT0gMA0KPiBpcyBkZXBlbmRlbnQgb24gdGhlIGNvbnRleHQuIEZv ciB0aGUgV2ViUlRDIEkgZG8gYWdyZWUgZG9pbmcgY2hlY2tzDQo+IHVzaW5nIElDRSBpcyBxdWl0 ZSByZWFzb25hYmxlLg0KPg0KPiBXZSBhbHJlYWR5IGhhdmUgc2ltaWxhciBwYXRoIHRlc3Rpbmcg dXNhZ2VzIG9mIElDRSBpbiB0aGUgRUNOIGZvciBSVFANCj4gc3BlY2lmaWNhdGlvbiAoUkZDNjY3 OSksIHNlZSBTZWN0aW9uIDcuMi4xLiBJIHdpbGwgbm90ZSB0aGF0IHRha2luZyB0aGlzDQo+IGFz IGJsdWVwcmludCBmb3IgRFNDUCB0ZXN0aW5nLCB3aGF0IGlzIG5lZWRlZCBjbGVhcmx5IHJlcXVp cmVzIGEgbmV3DQo+IHNlcGFyYXRlIHNwZWNpZmljYXRpb24uIFRoZSBjb21wb25lbnRzIG5lZWRz IGFyZTogMSkgQSBuZXcgU1RVTg0KPiBwYXJhbWV0ZXIgdG8gcmVxdWVzdCB0aGUgSUNFIHBlZXIg dG8gZWNobyB0aGUgRFNDUCBmaWVsZCB2YWx1ZSByZWNlaXZlZC4NCj4gMikgQSBJQ0UgY2FwYWJp bGl0eSBwYXJhbWV0ZXIgdG8gYmUgdXNlZCBpbiBzaWduYWxsaW5nIG5lZ290aWF0aW9ucyB0bw0K PiBkZXRlcm1pbmUgY2FwYWJpbGl0eSBmb3IgdGhpcyBmZWF0dXJlLiAzKSBCZWhhdmlvdXIgc3Bl Y2lmaWNhdGlvbiBvbiBob3cNCj4gdG8gdGVzdCB2YWx1ZXMgYW5kIGludGVycHJldCByZXNwb25z ZXMuIFRoaXMgaW5jbHVkZSB0aGluZ3MgbGlrZSBpZiBvbmUNCj4gc2hvdWxkIGFjdHVhbGx5IGVz dGFibGlzaCBtdWx0aXBsZSBjYW5kaWRhdGUgcGFpcnMgb25lIHdpdGggRFNDUCB0ZXN0aW5nDQo+ IGFuZCBvbmUgd2l0aG91dD8NCj4NCj4gU28gdGhlIHF1ZXN0aW9uIGhlcmUgaXMgaG93IHRvIHBy b2NlZWQgd2l0aCB0aGlzIGlzc3VlLiBTbyBJIHdvdWxkDQo+IHN1Z2dlc3QgdGhlIGZvbGxvd2lu ZyB3YXkgZm9yd2FyZC4NCj4NCj4gMS4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIGlkZW50 aWZpZXMgdGhlIGlzc3VlIGFuZCByZWNvbW1lbmRzIHRoZQ0KPiB1c2VyIHRvIGFwcGx5IHBhdGgg dmVyaWZpY2F0aW9uIG1ldGhvZHMgYnV0IGRvbid0IHNwZWNpZnkgdGhlbS4NCj4NCj4gMi4gU29t ZW9uZSB0YWtlcyBvbiB0aGUgdGFzayB0byB3cml0ZSBhIERTQ1AgcGF0aCB2ZXJpZmljYXRpb24g ZXh0ZW5zaW9uDQo+IHRvIElDRS4NCj4NCj4gMy4gVGhlIG5hdHVyYWwgcGxhY2UgdG8gaW5kaWNh dGUgdGhlIG5lZWQvcmVjb21tZW5kYXRpb24gZm9yDQo+IGltcGxlbWVudGluZyB0aGlzIGZ1bmN0 aW9uYWxpdHkgd291bGQgYmUgaW4gZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cw0KPiAoQ3Vy cmVudGx5IGluIElFVEYgTEMpLiBIb3dldmVyLCBoZXJlIEkgdGhpbmsgd2UgbmVlZCB0byBoYXZl IGENCj4gZGlzY3Vzc2lvbiBpZiBSVENXRUIgV0cgd2FudHMgdG8gb25seSBwbGFjZSBhIHN1aXRh YmxlIHdhcm5pbmcgYWJvdXQgdGhlDQo+IG5lZWQsIGFuZCBpbmRpY2F0ZSBmdXR1cmUgZm9ydGhj b21pbmcgc3BlY2lmaWNhdGlvbiBvciBpZiB3ZSBob2xkIHRoaXMNCj4gZG9jdW1lbnQgdXAgdW50 aWwgdGhpcyBzb2x1dGlvbiBpcyBhdmFpbGFibGU/DQo+DQo+DQo+IENoZWVycw0KPg0KPiBNYWdu dXMgV2VzdGVybHVuZA0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBhbmQg TmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4 Nzx0ZWw6JTJCNDYlMjAxMCUyMDcxNDgyODc+DQo+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAg ICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5PHRlbDolMkI0NiUyMDczJTIwMDk0OTA3OT4NCj4g U0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBt YWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0KDQo= --_000_CE03DB3D7B45C245BCA0D243277949362F62A6EEMX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDIN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiBDaGFy IjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBk aXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uSGVhZGluZzJDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiI7DQoJ Zm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdl aWdodDpib2xkO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13 ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25l IG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIC0xNSB2ZXJzaW9u IG9mIHRoZSBydGN3ZWItdHJhbnNwb3J0cyBkcmFmdCBoYXMgbm93IGJlZW4gcG9zdGVkLCBhbmQg dGhlIG5ldyB0ZXh0IG9uIG5vbi16ZXJvIERTQ1BzIGJsYWNrLWhvbGluZyB0cmFmZmljIGlzIGlu IFNlY3Rpb24gNC4yICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0xNSNzZWN0aW9uLTQuMiI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXRyYW5zcG9ydHMtMTUjc2VjdGlvbi00LjI8L2E+ KS4NCiAmbmJzcDtNYW55IHRoYW5rcyB0byBIYXJhbGQgZm9yIGFkZGluZyB0aGlzIHRleHQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGUgdHN2d2ctcnRjd2ViLXFvcyBkcmFmdCBuZWVkcyB0byBub3RlIHRoaXMgaXNz dWUgYW5kIHBvaW50IHRvIHRoYXQgc2VjdGlvbiBvZiB0aGUgcnRjd2ViLXRyYW5zcG9ydHMgZHJh ZnQuJm5ic3A7IEhlcmXigJlzIHByb3Bvc2VkIHRleHQgdG8gZG8gdGhhdCwgd2hpY2ggSSBzdWdn ZXN0DQogaW5zZXJ0aW5nIGFzIGEgbmV3IHBhcmFncmFwaCBpbiBTZWN0aW9uIDUgaW1tZWRpYXRl bHkgYmVmb3JlIEZpZ3VyZSAxICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zLTE3I3NlY3Rpb24tNSI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcy0xNyNzZWN0aW9uLTU8L2E+ KTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBXZWJSVEMgdXNlIG9mIG11bHRpcGxlIERTQ1AgdmFs dWVzIG1heSBlbmNvdW50ZXIgbmV0d29yayBibG9ja2luZyBvZiBwYWNrZXRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB3aXRoIGNlcnRhaW4gRFNDUCB2YWx1ZXMu ICZuYnNwOyZuYnNwO1NlZSBzZWN0aW9uIDQuMiBvZiBbSS1ELmlldGYtcnRjd2ViLXRyYW5zcG9y dHNdJm5ic3A7IGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg ZnVydGhlciBkaXNjdXNzaW9uLCBpbmNsdWRpbmcgaG93IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMg ZXN0YWJsaXNoIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg bWFpbnRhaW4gY29ubmVjdGl2aXR5IHdoZW4gc3VjaCBibG9ja2luZyBpcyBlbmNvdW50ZXJlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgaG9wZSBzb21ldGhpbmcgdGhpcyBzaG9ydCBhbmQgc2ltcGxlIHdpbGwgc3Vm ZmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNwZW5j ZXJkYXdraW5zLmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1 Z3VzdCAwMiwgMjAxNiAxOjI5IFBNPGJyPg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQ8YnI+DQo8 Yj5DYzo8L2I+IEFsaXNzYSBDb29wZXI7IFJUQ1dlYiBJRVRGOyB0c3Z3Z0BpZXRmLm9yZzxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gW3RzdndnXSBGYWxsLWJhY2sgdG8gRFNDUCAw IGluIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyA/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBBbGlzc2EgYW5kIERhdmlkLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIHRvIGJvdGgg b2YgeW91LiBJIGRpZG4ndCBzZWUgdGhlIG1pbnV0ZXMgb24gdGhlIFByb2NlZWRpbmdzIHBhZ2Ug YnV0IGRpZG4ndCB0aGluayB0byBsb29rIGZvciBkcmFmdCBtaW51dGVzIG9uIHRoZSBtYWlsaW5n IGxpc3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlZlcnkgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U3BlbmNlcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgQXVnIDEsIDIwMTYgYXQgNToxMiBQTSwgQmxhY2ssIERhdmlkICZsdDs8YSBo cmVmPSJtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhdmlkLmJs YWNrQGVtYy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jmd0Ow0KPC9zcGFuPlRoZSAtcnRjd2ViLXRyYW5zcG9ydHMgYXV0aG9yIEhhcmFs ZCBBbHZlc3RyYW5kIHRvb2sgb24gdGhlIGFjdGlvbiBpdGVtIGFuZCB3aWxsIHdvcmsgd2l0aCBK dXN0aW4gVWJlcnRpIHRvIHNlbmQgYSB0ZXh0IHByb3Bvc2FsIHRvIHRoZSBsaXN0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QW5kIHdoZW4gdGhhdCB0ZXh0IGFwcGVhcnMsIHdlIGNhbiBmaWd1 cmUgb3V0IHRoZSB3b3JkaW5nIChwcm9iYWJseSBhIHNob3J0IHNlbnRlbmNlKSB0byBhZGQgdG8g dGhlDQogdHN2d2ctcnRjd2ViLXFvcyBkcmFmdCB0byBwb2ludCB0byBpdCBvdmVyIGluIHRoZSBy dGN3ZWItdHJhbnNwb3J0cyBkcmFmdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLCAtLURh dmlkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEFsaXNzYSBDb29wZXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86YWxpc3NhQGNvb3Blcncu aW4iIHRhcmdldD0iX2JsYW5rIj5hbGlzc2FAY29vcGVydy5pbjwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBBdWd1c3QgMDEsIDIwMTYgNDo0NiBQTTxicj4NCjxiPlRvOjwvYj4gU3Bl bmNlciBEYXdraW5zIGF0IElFVEY8YnI+DQo8Yj5DYzo8L2I+IEJsYWNrLCBEYXZpZDsgUlRDV2Vi IElFVEY7IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0K dHN2d2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBbdHN2 d2ddIEZhbGwtYmFjayB0byBEU0NQIDAgaW4gZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zID88 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SGkgU3BlbmNlciw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEF1ZyAxLCAyMDE2LCBhdCA2OjU2IEFNLCBTcGVuY2Vy IERhd2tpbnMgYXQgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5IaSwgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBUaHUsIEp1bCAxNCwgMjAxNiBhdCA0OjEzIFBNLCBCbGFjaywgRGF2aWQgJmx0OzxhIGhy ZWY9Im1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZGF2aWQuYmxh Y2tAZW1jLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5NYWdudXMsPGJyPg0KPGJyPg0KSSB0aGluayB0aGF0J3MgYSBmaW5lIHN1Z2dlc3Rp b24uJm5ic3A7ICZuYnNwO0kgdGhpbmsgdGhlIG5leHQgc3RlcCBpczo8YnI+DQo8YnI+DQomZ3Q7 IDMuIFRoZSBuYXR1cmFsIHBsYWNlIHRvIGluZGljYXRlIHRoZSBuZWVkL3JlY29tbWVuZGF0aW9u IGZvcjxicj4NCiZndDsgaW1wbGVtZW50aW5nIHRoaXMgZnVuY3Rpb25hbGl0eSB3b3VsZCBiZSBp biBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzPGJyPg0KJmd0OyAoQ3VycmVudGx5IGluIElF VEYgTEMpLiBIb3dldmVyLCBoZXJlIEkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIGE8YnI+DQomZ3Q7 IGRpc2N1c3Npb24gaWYgUlRDV0VCIFdHIHdhbnRzIHRvIG9ubHkgcGxhY2UgYSBzdWl0YWJsZSB3 YXJuaW5nIGFib3V0IHRoZTxicj4NCiZndDsgbmVlZCwgYW5kIGluZGljYXRlIGZ1dHVyZSBmb3J0 aGNvbWluZyBzcGVjaWZpY2F0aW9uIG9yIGlmIHdlIGhvbGQgdGhpczxicj4NCiZndDsgZG9jdW1l bnQgdXAgdW50aWwgdGhpcyBzb2x1dGlvbiBpcyBhdmFpbGFibGU/PGJyPg0KPGJyPg0KSSdsbCBh dHRlbmQgdGhlIFRodSBSVENXRUIgc2Vzc2lvbiBpbiBCZXJsaW4gdG8gc2VlIGhvdyB0aGlzIGNv bWVzIG91dCw8YnI+DQphZnRlciB3aGljaCBpdCBzaG91bGQgYmUgc3RyYWlnaHRmb3J3YXJkIGZv ciB0aGUgZHJhZnQgYXV0aG9ycyBhbmQgeW91cnM8YnI+DQp0cnVseSB0byB3cml0ZSB0aGUgc2Vu dGVuY2Ugb3IgdHdvIHRoYXQgZHJhZnQtaWV0Zi10c3Z3Zy1ydGN3ZWItcW9zIHdpbGw8YnI+DQpu ZWVkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkn bSBqdXN0IGZvbGxvd2luZyB1cCBvbiB0aGlzIGJlY2F1c2Ugd2UgaGF2ZSBkcmFmdC1pZXRmLXJ0 Y3dlYi10cmFuc3BvcnRzIG9uIHRoZSB0ZWxlY2hhdCBhZ2VuZGEgdGhpcyB3ZWVrLCBhbmQgSSBk aWRuJ3Qgc2VlIGEgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGluIHRoZSBSVENXZWIgYWdlbmRh IChvcg0KIGluIHBva2luZyBhcm91bmQgZm9yIG1pbnV0ZXMsIGphYmJlciwgZXRoZXJwYWQsIGV0 YykuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkhlcmUgaXMgdGhlIHJlbGV2YW50IGJpdCBmcm9tIHRoZSBSVENXRUIgbWludXRlczo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8aDI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzNjVG OTEiPkRTQ1AgQmxhY2staG9saW5nIElzc3VlPC9zcGFuPjxvOnA+PC9vOnA+PC9oMj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+RGF2aWQgQmxhY2sgKFRTVldHIGNvLWNoYWlyKSBwcmVzZW50ZWQg dGhlIERTQ1AgYmxhY2staG9sZSBpc3N1ZSB3aXRoJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy8iIHRhcmdl dD0iX2JsYW5rIj4tcnRjd2ViLXRyYW5zcG9ydHM8L2E+Jm5ic3A7ZHJhZnQNCiB0aGF0IHdhcyBy ZWNlbnRseSBkaXNjdXNzZWQgb24gdGhlIGxpc3QuIFRoaXMgaXNzdWUgbmVlZHMgdG8gYmUgc29s dmVkIGFuZCBkZXNjcmliZWQsIGV2ZW4gdGhvdWdoIGJvdGggLXJ0Y3dlYi10cmFuc3BvcnRzIGFu ZCB0aGUgcmVmZXJlbmNlZCBkcmFmdC1pZXRmLXRzdndnLXJ0Y3dlYi1xb3MgaGFzIGdvbmUgdGhy b3VnaCBJRVNHIHJldmlldy4gTWFnbnVzIFdlc3Rlcmx1bmQgaGFzIHN1Z2dlc3RlZCBhIHNvbHV0 aW9uIHRvIHRoZSBsaXN0LCBidXQNCiB3aGF0IHNob3VsZCB0aGUgLXJ0Y3dlYi10cmFuc3BvcnRz IGRyYWZ0IHNheSBhYm91dCBEU0NQIGJsYWNrLWhvbGluZyBhbmQgdGhlIHBvc3NpYmlsaXR5IHRv IHVzZSBJQ0UgdG8gYXZvaWQgaXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlRoZSBXRyBkaXNjdXNzZWQgdGhpcyBhbmQgY29uY2x1ZGVkIHRoYXQgdGhlIGlzc3VlIHNo b3VsZCBiZSBkZXNjcmliZWQgYnkgdGhlIC1ydGN3ZWItdHJhbnNwb3J0cyBkcmFmdC4gVGVkIEhh cmRpZSBzdW1tYXJpemVkIHRoZSBkaXNjdXNzaW9uIGJ5IHN1Z2dlc3RpbmcgYSB0ZXh0IGZvcm11 bGF0aW9uIGZvcg0KIGEgcmVzb2x1dGlvbiB0aGF0IHNlZW1lZCBhY2NlcHRhYmxlIHRvIHRoZSBX Rzog4oCcV2Ugd2lsbCB0cmVhdCBEU0NQLWluZHVjZWQgcGF0aCBmYWlsdXJlIHBhcmFsbGVsIHdp dGggb3RoZXIgdHlwZXMgb2YgcGF0aCBmYWlsdXJlcyBhbmQgcmVzb2x2ZSBpdCBieSB1c2luZyBJ Q0UgcmVzdGFydC4gTm90ZTogVGhlcmUgaXMgYSBwcm9ibGVtIHdpdGggbXVsdGlwbGUgRFNDUCBj b2RlcG9pbnRzIG9uIGEgc2luZ2xlIHRyYW5zcG9ydCwgd2hlcmUgb25lDQogbWlnaHQgYmUgYmxv Y2tlZCBhbmQgb3RoZXIgbWlnaHQgZ2V0IHRocm91Z2guIEluIHRoaXMgY2FzZSwgdGhlIElDRSBw cm9iZXMsIHVzaW5nIG9uZSBEU0NQIGNvZGVwb2ludCwgbWF5IHN1Y2NlZWQgd2hpbGUgb3RoZXJz IGZhaWwuIFRoaXMgaXMgY29tcGxleCBhbmQgc2hvdWxkIGJlIHdhcm5lZCBhYm91dC4gQSBsaWtl bHkgdmlhYmxlIHNvbHV0aW9uIGlzIElDRSByZXN0YXJ0IHdpdGggRFNDUCBtYXJraW5ncyB0dXJu ZWQgb2ZmLCBidXQgZGV0ZWN0aW9uDQogcmVxdWlyZXMgd2F0Y2hpbmcgdGhlIG11bHRpcGxlLURD U1AtY29kZXBvaW50LXVzaW5nIGNoYW5uZWxzIGZvciBkaWZmZXJlbnRpYWwgZmFpbHVyZXPigJ0u IElmIHRoZXJlIGFyZSBvdGhlciBwcm9wb3NhbHMgZm9yIHJlc29sdXRpb24sIHBsZWFzZSBjb250 YWN0IEhhcmFsZC4gQ3VsbGVuIEplbm5pbmdzIGFza2VkIERhdmlkIGlmIHRoaXMgc29sdXRpb24g d2FzIGFjY2VwdGFibGUsIGJ1dCBEYXZpZCB3YW50ZWQgdG8gc2VlIHRoZSB0ZXh0IHByb3Bvc2Fs Lg0KIFRoZSAtcnRjd2ViLXRyYW5zcG9ydHMgYXV0aG9yIEhhcmFsZCBBbHZlc3RyYW5kIHRvb2sg b24gdGhlIGFjdGlvbiBpdGVtIGFuZCB3aWxsIHdvcmsgd2l0aCBKdXN0aW4gVWJlcnRpIHRvIHNl bmQgYSB0ZXh0IHByb3Bvc2FsIHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGFyYWxkIGhhcyBiZWVuIG9uIGhvbGlk YXlzIHNpbmNlIHRoZSBJRVRGIG1lZXRpbmcgYnV0IHdpbGwgYWltIHRvIGdldCB0byB0aGlzIGJl Zm9yZSB0aGUgdGVsZWNoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbGlzc2E8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGlkIGl0IGhhcHBlbj8g V2FzIHRoZXJlIGEgcmVzb2x1dGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNwZW5jZXI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsIC0tRGF2aWQ8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQomZ3Q7IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBNYWdudXMgV2VzdGVybHVuZCBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+XTxicj4NCiZndDsgU2Vu dDogVGh1cnNkYXksIEp1bHkgMTQsIDIwMTYgNDo1MyBBTTxicj4NCiZndDsgVG86IEN1bGxlbiBK ZW5uaW5ncyAoZmx1ZmZ5KTsgQmxhY2ssIERhdmlkPGJyPg0KJmd0OyBDYzogUlRDV2ViIElFVEY7 IE1pY2hhZWwgV2Vsemw7IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KdHN2d2dAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW3Rzdndn XSBbcnRjd2ViXSBGYWxsLWJhY2sgdG8gRFNDUCAwIGluIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2Vi LXFvcyA/PGJyPg0KJmd0Ozxicj4NCiZndDsgRGVuIDIwMTYtMDctMTIga2wuIDE4OjE5LCBza3Jl diBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IHNob3J0IGFuc3dlciBoZXJlIGJ1dCBhcyBEYXZpZCBzdWdnZXN0ZWQg4oCmJm5ic3A7IHNvbWUg aW1wbGVtZW50YXRpb24gdXNlPGJyPg0KJmd0OyAmZ3Q7IHRoZSBTVFVOIHBhY2tldHMgaW4gSUNF Jm5ic3A7IG9yIGp1c3QmbmJzcDsgaW4gV2ViUlRDIHN0eWxlIGxpdmVuZXNzIHRlc3RzIHRvPGJy Pg0KJmd0OyAmZ3Q7IGRvIHRoZSB0ZXN0cyBvZiBpZiBhIGdpdmVuIERTQ1Agd29ya3Mgb3Igbm90 LiBJbiBnZW5lcmFsIElDRSBpcyBhPGJyPg0KJmd0OyAmZ3Q7IGdvb2QgdG9vbCB0byB0YWtlIGEg YnVuY2ggb2YgcG9zc2libGUgcGF0aHMsIHRlc3Qgd2hpY2ggd29yaywgYW5kPGJyPg0KJmd0OyAm Z3Q7IHNlbGVjdCB0aGUgYmVzdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRvIGFncmVlIHRoYXQg aG93IHlvdSBkbyB0aGUgcGF0aCBjaGVja3Mgd2hlbiBzZXR0aW5nIERTQ1AgdmFsdWVzICE9IDA8 YnI+DQomZ3Q7IGlzIGRlcGVuZGVudCBvbiB0aGUgY29udGV4dC4gRm9yIHRoZSBXZWJSVEMgSSBk byBhZ3JlZSBkb2luZyBjaGVja3M8YnI+DQomZ3Q7IHVzaW5nIElDRSBpcyBxdWl0ZSByZWFzb25h YmxlLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGFscmVhZHkgaGF2ZSBzaW1pbGFyIHBhdGggdGVz dGluZyB1c2FnZXMgb2YgSUNFIGluIHRoZSBFQ04gZm9yIFJUUDxicj4NCiZndDsgc3BlY2lmaWNh dGlvbiAoUkZDNjY3OSksIHNlZSBTZWN0aW9uIDcuMi4xLiBJIHdpbGwgbm90ZSB0aGF0IHRha2lu ZyB0aGlzPGJyPg0KJmd0OyBhcyBibHVlcHJpbnQgZm9yIERTQ1AgdGVzdGluZywgd2hhdCBpcyBu ZWVkZWQgY2xlYXJseSByZXF1aXJlcyBhIG5ldzxicj4NCiZndDsgc2VwYXJhdGUgc3BlY2lmaWNh dGlvbi4gVGhlIGNvbXBvbmVudHMgbmVlZHMgYXJlOiAxKSBBIG5ldyBTVFVOPGJyPg0KJmd0OyBw YXJhbWV0ZXIgdG8gcmVxdWVzdCB0aGUgSUNFIHBlZXIgdG8gZWNobyB0aGUgRFNDUCBmaWVsZCB2 YWx1ZSByZWNlaXZlZC48YnI+DQomZ3Q7IDIpIEEgSUNFIGNhcGFiaWxpdHkgcGFyYW1ldGVyIHRv IGJlIHVzZWQgaW4gc2lnbmFsbGluZyBuZWdvdGlhdGlvbnMgdG88YnI+DQomZ3Q7IGRldGVybWlu ZSBjYXBhYmlsaXR5IGZvciB0aGlzIGZlYXR1cmUuIDMpIEJlaGF2aW91ciBzcGVjaWZpY2F0aW9u IG9uIGhvdzxicj4NCiZndDsgdG8gdGVzdCB2YWx1ZXMgYW5kIGludGVycHJldCByZXNwb25zZXMu IFRoaXMgaW5jbHVkZSB0aGluZ3MgbGlrZSBpZiBvbmU8YnI+DQomZ3Q7IHNob3VsZCBhY3R1YWxs eSBlc3RhYmxpc2ggbXVsdGlwbGUgY2FuZGlkYXRlIHBhaXJzIG9uZSB3aXRoIERTQ1AgdGVzdGlu Zzxicj4NCiZndDsgYW5kIG9uZSB3aXRob3V0Pzxicj4NCiZndDs8YnI+DQomZ3Q7IFNvIHRoZSBx dWVzdGlvbiBoZXJlIGlzIGhvdyB0byBwcm9jZWVkIHdpdGggdGhpcyBpc3N1ZS4gU28gSSB3b3Vs ZDxicj4NCiZndDsgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIHdheSBmb3J3YXJkLjxicj4NCiZndDs8 YnI+DQomZ3Q7IDEuIGRyYWZ0LWlldGYtdHN2d2ctcnRjd2ViLXFvcyBpZGVudGlmaWVzIHRoZSBp c3N1ZSBhbmQgcmVjb21tZW5kcyB0aGU8YnI+DQomZ3Q7IHVzZXIgdG8gYXBwbHkgcGF0aCB2ZXJp ZmljYXRpb24gbWV0aG9kcyBidXQgZG9uJ3Qgc3BlY2lmeSB0aGVtLjxicj4NCiZndDs8YnI+DQom Z3Q7IDIuIFNvbWVvbmUgdGFrZXMgb24gdGhlIHRhc2sgdG8gd3JpdGUgYSBEU0NQIHBhdGggdmVy aWZpY2F0aW9uIGV4dGVuc2lvbjxicj4NCiZndDsgdG8gSUNFLjxicj4NCiZndDs8YnI+DQomZ3Q7 IDMuIFRoZSBuYXR1cmFsIHBsYWNlIHRvIGluZGljYXRlIHRoZSBuZWVkL3JlY29tbWVuZGF0aW9u IGZvcjxicj4NCiZndDsgaW1wbGVtZW50aW5nIHRoaXMgZnVuY3Rpb25hbGl0eSB3b3VsZCBiZSBp biBkcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3BvcnRzPGJyPg0KJmd0OyAoQ3VycmVudGx5IGluIElF VEYgTEMpLiBIb3dldmVyLCBoZXJlIEkgdGhpbmsgd2UgbmVlZCB0byBoYXZlIGE8YnI+DQomZ3Q7 IGRpc2N1c3Npb24gaWYgUlRDV0VCIFdHIHdhbnRzIHRvIG9ubHkgcGxhY2UgYSBzdWl0YWJsZSB3 YXJuaW5nIGFib3V0IHRoZTxicj4NCiZndDsgbmVlZCwgYW5kIGluZGljYXRlIGZ1dHVyZSBmb3J0 aGNvbWluZyBzcGVjaWZpY2F0aW9uIG9yIGlmIHdlIGhvbGQgdGhpczxicj4NCiZndDsgZG9jdW1l bnQgdXAgdW50aWwgdGhpcyBzb2x1dGlvbiBpcyBhdmFpbGFibGU/PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IENoZWVyczxicj4NCiZndDs8YnI+DQomZ3Q7IE1hZ251cyBXZXN0ZXJsdW5k PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgU2VydmljZXMsIE1l ZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNPGJyPg0K Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBFcmljc3NvbiBBQiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBQaG9uZSZuYnNw OyA8YSBocmVmPSJ0ZWw6JTJCNDYlMjAxMCUyMDcxNDgyODciIHRhcmdldD0iX2JsYW5rIj4NCiYj NDM7NDYgMTAgNzE0ODI4NzwvYT48YnI+DQomZ3Q7IEbDpHLDtmdhdGFuIDYmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgTW9iaWxl IDxhIGhyZWY9InRlbDolMkI0NiUyMDczJTIwMDk0OTA3OSIgdGFyZ2V0PSJfYmxhbmsiPg0KJiM0 Mzs0NiA3MyAwOTQ5MDc5PC9hPjxicj4NCiZndDsgU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVu IHwgbWFpbHRvOiA8YSBocmVmPSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+DQptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+PGJy Pg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D243277949362F62A6EEMX307CL04corpem_-- From nobody Fri Aug 5 22:59:16 2016 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 0D1A912B03D for ; Fri, 5 Aug 2016 22:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-1.247] 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 BoDAbmBlO5pr for ; Fri, 5 Aug 2016 22:59:12 -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 6448B12B011 for ; Fri, 5 Aug 2016 22:59:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4C52A7C8F97; Sat, 6 Aug 2016 07:59:09 +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 8bEuhnhr95RU; Sat, 6 Aug 2016 07:59:07 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:a4b7:281d:843a:bfd] (unknown [IPv6:2001:470:de0a:1:a4b7:281d:843a:bfd]) by mork.alvestrand.no (Postfix) with ESMTPSA id 726567C8E03; Sat, 6 Aug 2016 07:59:07 +0200 (CEST) To: Bernard Aboba References: <57A0587C.9090102@alvestrand.no> <72E44150-3DE9-4718-9904-5CD0A2A0E317@gmail.com> From: Harald Alvestrand Message-ID: <9de7b5c4-8d2a-ec5d-9b59-6f0c7dfb894b@alvestrand.no> Date: Sat, 6 Aug 2016 07:59:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <72E44150-3DE9-4718-9904-5CD0A2A0E317@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fix for DSCP bleaching issue suggested X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 05:59:15 -0000 Bernard, you reinforce my fear of on-the-fly protocol design! The previous (pre-15) text tried to push all that stuff into "implementors have to do something". As soon as advice gets more specific, it also risks being wrong. When writing "probe", I was thinking of STUN binding requests as used in RFC 7675 consent (they solicit an identifiable answer, don't require receiver state, and are supported by all conforming ICE implementations). I didn't remember the name of the function while writin= g. Finding that traffic sent with a specific DSCP code point has been delivered (for instance by RTCP feedback) is also a clear indication that this DSCP codepoint isn't blackholed; it should be mentioned. On 08/04/2016 03:30 PM, Bernard Aboba wrote: > On Aug 2, 2016, at 01:23, Harald Alvestrand wrot= e: >> My proposed text for the DSCP blocking/bleaching issue is here: >> >> https://github.com/rtcweb-wg/rtcweb-transport/pull/30 >> >> Note that this differs from what was said at the IETF meeting - after >> considering, I didn't see a reason to recommend ICE restart. >> >> The text does not contain MUST or SHOULD. This is implementation advic= e. >> Is this approprate, given the current state of our knowledge of the is= sue? >> >> Diff: >> >> @@ -344,6 +344,18 @@ >> of packets with certain DSCP markings. The detection of these >> conditions is implementation dependent. >> >> + A particularly hard problem is when one media transport us= es >> + multiple DSCP code points, where one may be blocked and anoth= er >> may be >> + allowed. This is allowed for video in > + target=3D"I-D.ietf-tsvwg-rtcweb-qos"/>. Implementations need = to >> diagnose >> + this scenario; one possible implementation is to send initial= ICE >> + probes with DSCP 0, > [BA]Seems reasonable. > >> and send ICE probes on all the DSCP code points >> + that are intended to be used once a candidate pair has been >> selected. > [BA] Not sure what "probe" means here - are you referring to keepalives= and/or consent checks? > >> + If one or more of the DSCP-marked probes fail, the sender wil= l >> switch >> + the transport to using DSCP 0. This can be carried out >> simultaneously >> + with the initial media traffic; on failure, the initial data >> may need >> + to be resent. > [BA] Losing a single consent check does not tell you much, and if some = consent checks with a marking were responded to, changing markings based = on a subsequent loss is most probably a bad idea. Does "resent" refer to = RFC 4588 (RTX)?=20 > >> + >> All packets carrying data from the SCTP association >> supporting the >> data channels MUST use a single DSCP code point. The code poin= t >> used >> SHOULD be that recommended by > >> Comments welcome, especially if they come today! - the item is on >> Thursday's telechat, and it would be nice to release a fixed version >> well before the telechat. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. From nobody Wed Aug 24 05:55:05 2016 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 F37B112DCF4 for ; Wed, 24 Aug 2016 05:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=ojKETWcs; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=RkCThNWD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koeATyIHWVwr for ; Wed, 24 Aug 2016 05:55:01 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D205912DCE9 for ; Wed, 24 Aug 2016 05:55:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3FD9F204F3 for ; Wed, 24 Aug 2016 08:55:01 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 24 Aug 2016 08:55:01 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=CjR HjenbMi7LIxeeldN+xnJbBBc=; b=ojKETWcsBnV4R9c5nlrQXNF5ILyGXY7lbR/ a7cjiXa+7qdZlbw++olRSEwpzixeba3ARxa8yaIijuXZLVfBuUeBCvrQGczKq9Sk /w7FHpwnXBN5b+3CqdZBn5qJ0k2HRTSCBKpM9DKc7aAArJzvpawBCulqi2m54hv5 CkuWv5HI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=CjRHjenbMi7LIxeeldN+xnJbBBc=; b=RkCTh NWDc/u4SauKjBcUWLdc9fKOfZUAovnOrbeCzyWdUfRsS1K0TrEV/VfMrjiT7dx+G KENO2DFhJALc+Pr+6lc6m14AlscPRB6wvQTI+HL3Zyk2xIWFJ7TN7JUaBaRQJGzS TkMfhcTmwHOPRTL+RxrOrZOGdwxbbpRdNzVKRc= X-Sasl-enc: cPmY1le726GHcGZqGTympPu63xpNodwe5E0FNAIFs5dd 1472043300 Received: from sjc-alcoop-8816.cisco.com (unknown [128.107.241.174]) by mail.messagingengine.com (Postfix) with ESMTPA id AC0FAF29D6 for ; Wed, 24 Aug 2016 08:55:00 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 24 Aug 2016 08:54:58 -0400 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] JSEP plan X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 12:55:03 -0000 Wanted to let people know that based on off-list discussions with the = authors and shepherd of JSEP, the plan is to have a version of the JSEP = document ready for WGLC by October 23. Alissa= From nobody Wed Aug 24 14:20:10 2016 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 A067112D66B for ; Wed, 24 Aug 2016 14:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiGtMFgdSWR6 for ; Wed, 24 Aug 2016 14:20:07 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8029A12D124 for ; Wed, 24 Aug 2016 14:20:07 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id m60so11406374uam.3 for ; Wed, 24 Aug 2016 14:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=DmhiSr1m2FzpV7hmPlg7z/d2EzKW89utAqmT4i7zZ0U=; b=HKNLDaoSiXbgrqeFj3j/6kdlSZDDnmBTCvY9wCCy/UbPp7XLWy0O9OLtFI6hgdLmGX HHbG2b+irkyc4meYf8EZOKoAMXrnDrpoC2M28X+gjNJWrTyuWFcZ2PJYsFHwDpe5fU0x gO25/BvO0EMIEK0KUhAyzzKsO53cxW3aPlUn+gRzLH1JuPFO+8nk0EtJMRtIMOk6SAvf /RnlauocFvH32gBD/LFMacgSPe0uJpbyrpDmW8r407QerPn6OUI9oAecFtYFUTQ64Pwk Z75rkXndNzj0WOPOuxYi90wfaQ7eLLVN845zy8qoQWPe4Na0hN0uC7P3K0d2B12eEptp R0Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DmhiSr1m2FzpV7hmPlg7z/d2EzKW89utAqmT4i7zZ0U=; b=Nj7h/XTTHD3PfS1sFn+W7Dx4D2jXN/Vlmdq/CfoFFgv61hIqatLee6XRAeoxKm8nba lsW0v5kTco+O+Uzw/uKDuFCo81FplGx1bXJRHVx5UgYQ//SD9eu30v9SDaeS0y82sVxZ fNleV3AuRt0HMtS5xknO8GeQ9+jkxZZykwd7v70gA7W8xsDdbbdVQXTW0OQfHb+Z2WjA vX6XQM8s1+clokC9NqqiaDQU9wwywK7X3gkvr3TcJcwrAIN292kDp99EDVaBN/lqFcio Ji3T3ipkA2UXfwofQGEoguaOxhGKIY2EeMYThlZZgfsdpNi0m43tDYVgDtaViotrytjM peMw== X-Gm-Message-State: AE9vXwNBMlxVzna7J9x/P5HDonB1dQRodKYB9gTKYSxkF5XXNV691eyKBsP25RHfmDAkU4br1437a4GZh7K2Ew== X-Received: by 10.176.81.88 with SMTP id f24mr10693uaa.122.1472073606370; Wed, 24 Aug 2016 14:20:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.184 with HTTP; Wed, 24 Aug 2016 14:19:46 -0700 (PDT) From: Bernard Aboba Date: Wed, 24 Aug 2016 14:19:46 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1920ea641c55053ad7d817 Archived-At: Subject: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 24 Aug 2016 21:20:08 -0000 --94eb2c1920ea641c55053ad7d817 Content-Type: text/plain; charset=UTF-8 Currently JSEP references RFC 4572, not draft-ietf-mmusic-rfc4572-update. As a result, JSEP reiterates requirements from RFC 4572, such as the following: the digest algorithm used for the fingerprint MUST match that used in the certificate signature. During the August 23 WEBRTC WG interim, a question arose as to whether the IETF RTCWEB WG intends to revise JSEP to reference draft-ietf-mmusic-rfc4572-update and its allowance of multiple fingerprints per certificate. --94eb2c1920ea641c55053ad7d817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Currently JSEP references RFC 4572, not draft-ietf-mmusic-= rfc4572-update.=C2=A0

As a result, JSEP reiterates requi= rements from RFC 4572, such as the following:=C2=A0

      the digest algorithm used
      for the fingerprint MUST match that used in the certificate
      signature.

=
During the August 23 WEBRTC WG interim, a question=
 arose as to whether the IETF RTCWEB WG intends to revise JSEP to reference=
 draft-ietf-mmusic-rfc4572-update and its allowance of multiple fingerprint=
s per certificate.
--94eb2c1920ea641c55053ad7d817-- From nobody Wed Aug 24 23:06:52 2016 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 60F3B128E19 for ; Wed, 24 Aug 2016 23:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsgTGEnQVzg0 for ; Wed, 24 Aug 2016 23:06:50 -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 E9AA5127077 for ; Wed, 24 Aug 2016 23:06:49 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-8b-57be8af7ce54 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 23.5A.02553.7FA8EB75; Thu, 25 Aug 2016 08:06:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 08:06:46 +0200 From: Christer Holmberg To: Bernard Aboba , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP: multiple fingerprints for a certificate Thread-Index: AQHR/k1N4obaEB6UGkSI2f8MWO5rr6BZQxsA Date: Thu, 25 Aug 2016 06:06:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D3E465F7D952christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7lu6Prn3hBq9Pills2Pef2WLtv3Z2 ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvjxtm1TAW7pCpeT5zH1MB4RKyLkZNDQsBE YuLpHqYuRi4OIYH1jBJNB96wQzhLGCWOXmkEynBwsAlYSHT/0wZpEBEIkmjrWsgIYgsLOEt0 Lz7DBBF3kXg5+wCUbSRx+ds7ZhCbRUBVYs7MJjYQm1fASuLoyy6wuJBAgETDr2NgNqdAoMTD 9tssIDajgJjE91NrwOYwC4hL3HoynwniUAGJJXvOM0PYohIvH/9jBbFFBfQkvn+dDRVXlLg6 fTnYycwC8RJ7FllCrBWUODnzCcsERpFZSKbOQqiahaQKosRA4v25+cwQtrbEsoWvoWx9iY1f zjJC2NYSJ5ZuYkdWs4CRYxWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYKwd3PLbYAfjy+eO hxgFOBiVeHgXPNgbLsSaWFZcmXuIUYKDWUmEd2HrvnAh3pTEyqrUovz4otKc1OJDjNIcLEri vP4vFcOFBNITS1KzU1MLUotgskwcnFINjL7uPeeUe59e132aoPr+abWc2aGsH11OBxP6Jna3 n4uSmKP1QIy3LfV/Y/zmxoLfP3pLNkWYre581fnbN7dKfItW0rJ3jirSNv+mrEzeeWFm5k6B 3dkH33MeOno62mGGrvri22JX1ivIucp8nVgQv0D2abhcy7f9dV8iqx+ujSl6vu4r0/1TjEos xRmJhlrMRcWJAIk72vixAgAA Archived-At: Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 06:06:51 -0000 --_000_D3E465F7D952christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bernard, >Currently JSEP references RFC 4572, not draft-ietf-mmusic-rfc4572-update. > >As a result, JSEP reiterates requirements from RFC 4572, such as the follo= wing: > > the digest algorithm used > for the fingerprint MUST match that used in the certificate > signature. > > During the August 23 WEBRTC WG interim, a question arose as to whether th= e IETF RTCWEB WG intends to revise JSEP to reference draft-ietf-mmusic-rfc4= 572-update and its allowance of multiple fingerprints per certificate. A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 4572, d= o we need to explicitly reference the draft? By referencing RFC 4572, don= =92t we also implicitly reference any specification that updates the RFC? This is an important question, because we also reference other RFCs that ha= ve been updated by recent drafts, and we need to make sure the updates appl= y. Regards, Christer --_000_D3E465F7D952christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <798A957AFF509D44AE806B0660890250@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi Bernard,

>Currently JSEP references RFC 4572, not draft-ietf-mmu= sic-rfc4572-update. 
>
>As a result, JSEP reiterates requirements from RFC 4572, such as t= he following: 
>
>      the digest algorithm used
>     for the fingerprint MUST match that used in the certificate
>      signature.
>
> During the August 23 WEB=
RTC WG interim, a question arose as to whether the IETF RTCWEB WG intends t=
o revise JSEP to reference draft-ietf-mmusic-rfc4572-update and its allowan=
ce of multiple fingerprints per certificate.

A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 45= 72, do we need to explicitly reference the draft? By referencing RFC 4572, = don=92t we also implicitly reference any specification that updates the RFC= ?

This is an important question, because we also reference other RFCs th= at have been updated by recent drafts, and we need to make sure the updates= apply.

Regards,

Christer
--_000_D3E465F7D952christerholmbergericssoncom_-- From nobody Thu Aug 25 00:10:43 2016 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 7FEDE12D561 for ; Thu, 25 Aug 2016 00:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRNR5pIIMp0J for ; Thu, 25 Aug 2016 00:10:40 -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 D728112D522 for ; Thu, 25 Aug 2016 00:10:39 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id n59so69271669uan.2 for ; Thu, 25 Aug 2016 00:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+blvhtolRwV6UExBf/tXLbJq4HphrHOpvc/fL82KuSc=; b=QyFtDVRKlIWvAxmJdmSyqbkQLBWnMdF5s5QvQQQ3Ck4hqcxDORw1RiUcyqKi57NRbg 2fX7KUukYXzle9M+l0snfmJ/6W/LOTvNfLAndamXtiotxSaYQd/KVG3R0G42lMomq4jN ayOamM2JOCZMvnWQMJrqbYjdTFKKO/dm9taoFMjFjxh22M9l4NCYdmaLEN4aUyU+G8d2 U6t6ZLbNG02O/LBQV3mj+0O3hA0lMchNCLRlmm+4WITVTgSviq1/X8/CFv5uLgKMrt+d LpT8xriX5BVw4tWrkXV3gYg2wBteCXBMpuy6KL8fbAgQBloQGvOjVSf8lkEoCgK5tkWJ UJ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+blvhtolRwV6UExBf/tXLbJq4HphrHOpvc/fL82KuSc=; b=BSH1S2rGfPTSnNIB5CWk16EvvueWBVvUreEsTDczGgF8t07X/gJN4PVHkTa0iWb7Nz BwLFqn32KhTQqG2OPnliGuhH19FgKEDKFWM6aJxqvbvMZL8vdouXQPiMxZjLJTA/PEb0 7qCT08+qVB18EGrQ/xgBxPykKd7ItYS1wuQL54ksG54G+GhCjtbn5hCIxbXfKb5S3i5F u91FYFBK7AWw0sKgiXY0zSwN2ml/GaO66he6RKFkvvskTsjWlu8htLWYQPd/64EXs1M9 WpsDA/aOsDyrB4HpYrO8EpYPNDorZpmNHLv0nwsQwmyPI293JS6mh+OQ9OexmWRPnTAF qQpw== X-Gm-Message-State: AE9vXwNpAVzc5ybvT6ekR/xFJZakyaq99Px7GbjVvbrrA+Zd9E9sJCrf0N6g7E6qEi4cnp7YOgrVHwj/iSIOzA== X-Received: by 10.176.81.48 with SMTP id e45mr363814uaa.122.1472109039048; Thu, 25 Aug 2016 00:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.184 with HTTP; Thu, 25 Aug 2016 00:10:18 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 25 Aug 2016 00:10:18 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c1915fe57de86053ae0182e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 07:10:41 -0000 --94eb2c1915fe57de86053ae0182e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer -- If the intent is to continue to impose the RFC 4572 restrictions, then the JSEP text enforcing those restrictions is fine, as is the current JSEP reference to RFC 4572. However, if the desire of the WG is to remove those restrictions and allow multiple fingerprints per certificate, then JSEP text quoting from RFC 4572 needs to be removed - and a reference to RFC 4572 update is required which validates that loosening. On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Bernard, > > >Currently JSEP references RFC 4572, not draft-ietf-mmusic-rfc4572-update= . > > > > >As a result, JSEP reiterates requirements from RFC 4572, such as the > following: > > > > > the digest algorithm used > > for the fingerprint MUST match that used in the certificate > > signature. > > > > > > During the August 23 WEBRTC WG interim, a question arose as to whether = the IETF RTCWEB WG intends to revise JSEP to reference draft-ietf-mmusic-rf= c4572-update and its allowance of multiple fingerprints per certificate. > > > A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 4572, > do we need to explicitly reference the draft? By referencing RFC 4572, > don=E2=80=99t we also implicitly reference any specification that updates= the RFC? > > This is an important question, because we also reference other RFCs that > have been updated by recent drafts, and we need to make sure the updates > apply. > > Regards, > > Christer > --94eb2c1915fe57de86053ae0182e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer --

If the intent is to continu= e to impose the RFC 4572 restrictions, then the JSEP text enforcing those r= estrictions is fine, as is the current JSEP reference to RFC 4572.=C2=A0
However, if the desire of the WG is to remove those restri= ctions and allow multiple fingerprints per certificate, then JSEP text quot= ing from RFC 4572 needs to be removed - and a reference to RFC 4572 update = is required which validates that loosening.=C2=A0

On Wed, Aug 24, 2016 at 1= 1:06 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Bernard,

>Currently JSEP references RFC 4572, not draft-ietf-mmu= sic-rfc4572-update.=C2=A0
>
>As a result, JSEP reiterates requirements from RFC 4572, such as t= he following:=C2=A0
>
>      the digest algorithm used
>     for the fingerprint MUST match that used in the certificate
>      signature.
>
> During the August 23 WEBRTC WG inte=
rim, a question arose as to whether the IETF RTCWEB WG intends to revise JS=
EP to reference draft-ietf-mmusic-rfc4572-update and its allowance of =
multiple fingerprints per certificate.

A generic question: as draft-ietf-mmusic-rfc4572-upda= te updates RFC 4572, do we need to explicitly reference the draft? By refer= encing RFC 4572, don=E2=80=99t we also implicitly reference any specificati= on that updates the RFC?

This is an important question, because we also reference other RFCs th= at have been updated by recent drafts, and we need to make sure the updates= apply.

Regards,

Christer

--94eb2c1915fe57de86053ae0182e-- From nobody Thu Aug 25 00:17:52 2016 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 E059512D61D for ; Thu, 25 Aug 2016 00:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSA09z1aRaL2 for ; Thu, 25 Aug 2016 00:17:49 -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 3BAF512D1A5 for ; Thu, 25 Aug 2016 00:17:49 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-d1-57be9b9a1788 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 07.B7.04209.A9B9EB75; Thu, 25 Aug 2016 09:17:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 09:17:45 +0200 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [rtcweb] JSEP: multiple fingerprints for a certificate Thread-Index: AQHR/k1N4obaEB6UGkSI2f8MWO5rr6BZQxsA///eOwCAADWZAA== Date: Thu, 25 Aug 2016 07:17:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D3E476C0D99Fchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2J7oO7s2fvCDdbvkrTYsO8/s8Xaf+3s DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG4if/WAqmGFRs/ZzdwLhXo4uRk0NCwETi /MFm9i5GLg4hgfWMErtX/mODcJYwSkxcOQUow8HBJmAh0f1PG6RBREBbou/bPiYQm1lAXeLO 4nPsILawgLNE9+IzTBA1LhIvZx+Asp0kOh4tBKthEVCVWLHvIxuIzStgJdGw4CgTxK4TjBKr ll8AK+IUCJRY1LIYzGYUEJP4fmoN1DJxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/rCC2qICexPev s5lBbpYQUJRY3i8HYjILxEsseKYIsVZQ4uTMJywTGEVnIRk6C6FqFpIqiBIDiffn5jND2NoS yxa+hrL1JTZ+OcsIYVtLtE9ex4asZgEjxypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwAg8 uOW36g7Gy28cDzEKcDAq8fAueLA3XIg1say4MvcQowQHs5IIb8WMfeFCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGAvnLnKsvh1o58HjyX234kpMa8t5 pS63vp5nuxZ7tBVanI8JX2rRKvxt/5XDodVC6hci76dcf3J9mu3cjmvyQdKfL83XUW2RDNdJ 3xLsf04wQTzru+RZWcOtc8s2P5sf7CYg25z2n0G9Sq/39/ou1n2zL03w2B2X5uRx5afLkosX uNf1Hsz7q8RSnJFoqMVcVJwIAKonNLu8AgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 07:17:51 -0000 --_000_D3E476C0D99Fchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >If the intent is to continue to impose the RFC 4572 restrictions, then the= JSEP text enforcing those restrictions is fine, as is the current JSEP ref= erence to RFC 4572. > >However, if the desire of the WG is to remove those restrictions and allow= multiple fingerprints per certificate, then JSEP text quoting from RFC 457= 2 needs to be removed - and a reference to RFC 4572 update is required whic= h validates that loosening. I do agree that the text in JSEP shall not restrict usage of multiple finge= rprints, and any quoted text should be from 4572-update. My question is whether we need to explicitly add a reference to 4572-update= for that, or whether 4572-update is implicitly referenced by referencing R= FC 4572. I don=92t really care which way we do =96 I just want to know :) Regards, Christer On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmberg > wrote: Hi Bernard, >Currently JSEP references RFC 4572, not draft-ietf-mmusic-rfc4572-update. > >As a result, JSEP reiterates requirements from RFC 4572, such as the follo= wing: > > the digest algorithm used > for the fingerprint MUST match that used in the certificate > signature. > > During the August 23 WEBRTC WG interim, a question arose as to whether th= e IETF RTCWEB WG intends to revise JSEP to reference draft-ietf-mmusic-rfc4= 572-update and its allowance of multiple fingerprints per certificate. A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 4572, d= o we need to explicitly reference the draft? By referencing RFC 4572, don= =92t we also implicitly reference any specification that updates the RFC? This is an important question, because we also reference other RFCs that ha= ve been updated by recent drafts, and we need to make sure the updates appl= y. Regards, Christer --_000_D3E476C0D99Fchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <23852586FA15394B83784C9160A7A508@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>If the intent is to continue to impose the RFC 4572 restrictions, = then the JSEP text enforcing those restrictions is fine, as is the current = JSEP reference to RFC 4572. 
>
>However, if the desire of the WG is to remove those restrictions a= nd allow multiple fingerprints per certificate, then JSEP text quoting from= RFC 4572 needs to be removed - and a reference to RFC 4572 update is requi= red which validates that loosening. 

I do agree that the text in JSEP shall not restrict usage of multiple = fingerprints, and any quoted text should be from 4572-update. 

My question is whether we need to explicitly add a reference to 4572-u= pdate for that, or whether 4572-update is implicitly referenced by referenc= ing RFC 4572. I don=92t really care which way we do =96 I just want to know= :)

Regards,

Christer



On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:
Hi Bernard,

>Currently JSEP references RFC 4572, not draft-ietf-mmu= sic-rfc4572-update. 
>
>As a result, JSEP reiterates requirements from RFC 4572, such as t= he following: 
>
>      the digest algorithm used
>     for the fingerprint MUST match that used in the certificate
>      signature.
>
> During the August 23 WEBRTC WG inte=
rim, a question arose as to whether the IETF RTCWEB WG intends to revise JS=
EP to reference draft-ietf-mmusic-rfc4572-update and its allowance of =
multiple fingerprints per certificate.

A generic question: as draft-ietf-mmusic-rfc4572-update updates R= FC 4572, do we need to explicitly reference the draft? By referencing RFC 4= 572, don=92t we also implicitly reference any specification that updates th= e RFC?

This is an important question, because we also reference other RFCs th= at have been updated by recent drafts, and we need to make sure the updates= apply.

Regards,

Christer

--_000_D3E476C0D99Fchristerholmbergericssoncom_-- From nobody Thu Aug 25 06:20:45 2016 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 8C70112D0B4 for ; Thu, 25 Aug 2016 06:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 be-haKlavQzL for ; Thu, 25 Aug 2016 06:20:42 -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 8027712B007 for ; Thu, 25 Aug 2016 06:20:42 -0700 (PDT) Received: from smtp3.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D44F260385 for ; Thu, 25 Aug 2016 09:20:41 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 93F6B60338 for ; Thu, 25 Aug 2016 09:20:41 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.7); Thu, 25 Aug 2016 09:20:41 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <724F4BD9-521C-47F7-AA33-155323F25ED3@iii.ca> Date: Thu, 25 Aug 2016 07:20:40 -0600 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] Is support for non square pixels MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 13:20:43 -0000 I was trying to figure out from the specs what the story is on WebRTC = support for non square pixels (for example CIF resolution video is often = not quite square pixels). Thoughts on what the specs should say on this ? Anyone know what browser = do today? Thanks Cullen From nobody Thu Aug 25 08:04:19 2016 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 8DFA912D145 for ; Thu, 25 Aug 2016 08:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 qdYWtCzPsGF2 for ; Thu, 25 Aug 2016 08:04:17 -0700 (PDT) Received: from smtp121.iad3a.emailsrvr.com (smtp121.iad3a.emailsrvr.com [173.203.187.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED45B12B065 for ; Thu, 25 Aug 2016 08:04:16 -0700 (PDT) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0D2F7C0478; Thu, 25 Aug 2016 11:04:14 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 83602C0467; Thu, 25 Aug 2016 11:04:13 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.7); Thu, 25 Aug 2016 11:04:14 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Thu, 25 Aug 2016 09:04:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1F054785-35C3-4C78-BA68-9C1FA8C06633@iii.ca> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 15:04:18 -0000 The JSEP authors have typically tried to have JSEP ref everything that = implementers need to know just to make it easier for them to find it. I = will add a ref to draft-ietf-mmusic-4572-update to JSEP. Given it is an = "update" it technical is a dependency either way.=20 Clearly we want the WebRTC spec to work for where the IETF is going with = 4572-update I do think we need some discussion in mmusic about what the right thing = with this update is.=20 > On Aug 25, 2016, at 1:17 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > >If the intent is to continue to impose the RFC 4572 restrictions, = then the JSEP text enforcing those restrictions is fine, as is the = current JSEP reference to RFC 4572.=20 > > > >However, if the desire of the WG is to remove those restrictions and = allow multiple fingerprints per certificate, then JSEP text quoting from = RFC 4572 needs to be removed - and a reference to RFC 4572 update is = required which validates that loosening.=20 >=20 > I do agree that the text in JSEP shall not restrict usage of multiple = fingerprints, and any quoted text should be from 4572-update.=20 >=20 > My question is whether we need to explicitly add a reference to = 4572-update for that, or whether 4572-update is implicitly referenced by = referencing RFC 4572. I don=92t really care which way we do =96 I just = want to know :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmberg = wrote: >> Hi Bernard, >>=20 >> >Currently JSEP references RFC 4572, not = draft-ietf-mmusic-rfc4572-update.=20 >> > >> >As a result, JSEP reiterates requirements from RFC 4572, such as the = following:=20 >> > >> > the digest algorithm used >> > for the fingerprint MUST match that used in the certificate >> > signature. >>=20 >> > >> > During the August 23 WEBRTC WG interim, a question arose as to = whether the IETF RTCWEB WG intends to revise JSEP to reference = draft-ietf-mmusic-rfc4572-update and its allowance of multiple = fingerprints per certificate. >>=20 >> A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC = 4572, do we need to explicitly reference the draft? By referencing RFC = 4572, don=92t we also implicitly reference any specification that = updates the RFC? >>=20 >> This is an important question, because we also reference other RFCs = that have been updated by recent drafts, and we need to make sure the = updates apply. >>=20 >> Regards, >>=20 >> Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Aug 25 08:11:41 2016 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 EF62712D0E2 for ; Thu, 25 Aug 2016 08:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgSbz8EcXIvB for ; Thu, 25 Aug 2016 08:11:38 -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 DAD7412D11F for ; Thu, 25 Aug 2016 08:11:37 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-b0-57bf0aa79a0f Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 00.96.02553.7AA0FB75; Thu, 25 Aug 2016 17:11:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0301.000; Thu, 25 Aug 2016 17:11:34 +0200 From: Christer Holmberg To: Cullen Jennings Thread-Topic: [rtcweb] JSEP: multiple fingerprints for a certificate Thread-Index: AQHR/k1N4obaEB6UGkSI2f8MWO5rr6BZQxsA///eOwCAADWZAIAATs8AgAAjOAA= Date: Thu, 25 Aug 2016 15:11:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BC61B43@ESESSMB209.ericsson.se> References: <1F054785-35C3-4C78-BA68-9C1FA8C06633@iii.ca> In-Reply-To: <1F054785-35C3-4C78-BA68-9C1FA8C06633@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbHdW3c51/5wg7cvdSw27PvPbPFh/Q9G i7X/2tkdmD12zrrL7rFkyU8mj8vnPzIGMEdx2aSk5mSWpRbp2yVwZZzsPstc0CVecevHFNYG xvVCXYwcHBICJhLfLih2MXJxCAmsZ5RoOviHsYuRE8hZwihx83YsSA2bgIVE9z9tkLCIgLLE uR13mUFsZgEvifV9N1hAbGEBZ4kpe7+xQNS4SLycfYAJpFVEwE+i44cQSJhFQFXiwZMjYCW8 Ar4S2z8cZ4RYu5JJYvPsVWwgCU4BK4mfU68zgdiMAmIS30+tYYLYJS5x68l8MFtCQEBiyZ7z zBC2qMTLx/9YIWwliRXbLzFC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQ tMxC0rKAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmDcHNzy22AH48vnjocYBTgYlXh4 FzzYGy7EmlhWXJl7iFGCg1lJhLeYc3+4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLp iSWp2ampBalFMFkmDk6pBsZAzfvBHX+C98xQ5hb4eNCis9Gv6W7ih2+fqg1dqq26bsqa1Tn2 1tbGxwm/EDWe7ejeqP07Z9sblxXzfjtr8OvvW3vvPquE7R1d8yvHp0c+yby+eGreiQeRh5Zo /p/E+LbjaE+0xclbbz5es9xWfkjFSHVtxc0XuifY9047W76JxWxbd8b6yBVKLMUZiYZazEXF iQAhTAZDlwIAAA== Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 15:11:40 -0000 Hi, >The JSEP authors have typically tried to have JSEP ref everything that imp= lementers >need to know just to make it easier for them to find it. I will = add a ref to draft-ietf->mmusic-4572-update to JSEP. Given it is an "updat= e" it technical is a dependency >either way.=20 Ok. That means we also need to reference a number of other "update" drafts = that affect JSEP, but I think I sent you a list of those already? Regards, Christer >Clearly we want the WebRTC spec to work for where the IETF is going with 4= 572->update > >I do think we need some discussion in mmusic about what the right thing wi= th this >update is.=20 > On Aug 25, 2016, at 1:17 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > >If the intent is to continue to impose the RFC 4572 restrictions, then t= he JSEP text enforcing those restrictions is fine, as is the current JSEP r= eference to RFC 4572.=20 > > > >However, if the desire of the WG is to remove those restrictions and all= ow multiple fingerprints per certificate, then JSEP text quoting from RFC 4= 572 needs to be removed - and a reference to RFC 4572 update is required wh= ich validates that loosening.=20 >=20 > I do agree that the text in JSEP shall not restrict usage of multiple fin= gerprints, and any quoted text should be from 4572-update.=20 >=20 > My question is whether we need to explicitly add a reference to 4572-upda= te for that, or whether 4572-update is implicitly referenced by referencing= RFC 4572. I don't really care which way we do - I just want to know :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On Wed, Aug 24, 2016 at 11:06 PM, Christer Holmberg wrote: >> Hi Bernard, >>=20 >> >Currently JSEP references RFC 4572, not draft-ietf-mmusic-rfc4572-updat= e.=20 >> > >> >As a result, JSEP reiterates requirements from RFC 4572, such as the fo= llowing:=20 >> > >> > the digest algorithm used >> > for the fingerprint MUST match that used in the certificate >> > signature. >>=20 >> > >> > During the August 23 WEBRTC WG interim, a question arose as to whether= the IETF RTCWEB WG intends to revise JSEP to reference draft-ietf-mmusic-r= fc4572-update and its allowance of multiple fingerprints per certificate. >>=20 >> A generic question: as draft-ietf-mmusic-rfc4572-update updates RFC 4572= , do we need to explicitly reference the draft? By referencing RFC 4572, do= n't we also implicitly reference any specification that updates the RFC? >>=20 >> This is an important question, because we also reference other RFCs that= have been updated by recent drafts, and we need to make sure the updates a= pply. >>=20 >> Regards, >>=20 >> Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Aug 25 08:34:19 2016 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 D106F12D1CB for ; Thu, 25 Aug 2016 08:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 CIxGn8UNJfSi for ; Thu, 25 Aug 2016 08:34:09 -0700 (PDT) Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.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 1732612D1C0 for ; Thu, 25 Aug 2016 08:34:09 -0700 (PDT) Received: from smtp10.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3D3C060143; Thu, 25 Aug 2016 11:34:06 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp10.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D10B96035B; Thu, 25 Aug 2016 11:34:05 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.7); Thu, 25 Aug 2016 11:34:06 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BC61B43@ESESSMB209.ericsson.se> Date: Thu, 25 Aug 2016 09:34:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <17511AEF-B567-419F-A197-8AB265E0BC79@iii.ca> References: <1F054785-35C3-4C78-BA68-9C1FA8C06633@iii.ca> <7594FB04B1934943A5C02806D1A2204B4BC61B43@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] JSEP: multiple fingerprints for a certificate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 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, 25 Aug 2016 15:34:18 -0000 > On Aug 25, 2016, at 9:11 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> The JSEP authors have typically tried to have JSEP ref everything = that implementers >need to know just to make it easier for them to find = it. I will add a ref to draft-ietf->mmusic-4572-update to JSEP. Given = it is an "update" it technical is a dependency >either way.=20 >=20 > Ok. That means we also need to reference a number of other "update" = drafts that affect JSEP, but I think I sent you a list of those already? I thought I got everything on your list in latest version but pleas have = a look and see what else is missing. Greatly appreciate you checking = this and helping track down any more updates.=20 Here's the list of things I think that WebRTC normatively depends on so = if we have "updates" to any of these, I should add them=20 draft-ietf-avtcore-multi-media-rtp-session draft-ietf-avtcore-rtp-circuit-breakers draft-ietf-avtcore-rtp-multi-stream draft-ietf-avtcore-rtp-multi-stream-optimisation draft-ietf-avtext-rid draft-ietf-avtext-sdes-hdr-ext draft-ietf-ice-dualstack-fairness draft-ietf-ice-rfc5245bis draft-ietf-ice-trickle draft-ietf-mmusic-ice-sip-sdp draft-ietf-mmusic-msid draft-ietf-mmusic-mux-exclusive draft-ietf-mmusic-rid draft-ietf-mmusic-sctp-sdp draft-ietf-mmusic-sdp-bundle-negotiation draft-ietf-mmusic-sdp-mux-attributes draft-ietf-mmusic-sdp-simulcast draft-ietf-payload-flexible-fec-scheme draft-ietf-rtcweb-alpn draft-ietf-rtcweb-data-channel draft-ietf-rtcweb-data-protocol draft-ietf-rtcweb-fec draft-ietf-rtcweb-jsep draft-ietf-rtcweb-overview draft-ietf-rtcweb-rtp-usage draft-ietf-rtcweb-security draft-ietf-rtcweb-security-arch draft-ietf-rtcweb-transports draft-ietf-tsvwg-rtcweb-qos draft-ietf-tsvwg-sctp-dtls-encaps draft-ietf-tsvwg-sctp-ndata draft-ietf-ice-trickle draft-ietf-tram-stunbis draft-ietf-avtcore-5761-update draft-ietf-mmusic-4572-update draft-ietf-mmusic-dtls-sdp draft-ietf-avtcore-rfc5764-mux-fixes RFC1889 RFC2198 RFC2327 RFC3264 RFC3388 RFC3389 RFC3489 RFC3550 RFC3551 RFC3555 RFC3556 RFC3605 RFC3611 RFC3711 RFC3758 RFC3890 RFC4145 RFC4566 RFC4570 RFC4571 RFC4572 RFC4585 RFC4588 RFC4733 RFC4756 RFC4820 RFC4895 RFC4961 RFC5052 RFC5053 RFC5061 RFC5104 RFC5109 RFC5124 RFC5245 RFC5285 RFC5389 RFC5506 RFC5576 RFC5583 RFC5705 RFC5761 RFC5763 RFC5764 RFC5766 RFC5768 RFC5888 RFC5928 RFC5956 RFC6051 RFC6062 RFC6096 RFC6156 RFC6184 RFC6188 RFC6236 RFC6263 RFC6330 RFC6363 RFC6364 RFC6464 RFC6465 RFC6520 RFC6525 RFC6544 RFC6555 RFC6562 RFC6681 RFC6682 RFC6716 RFC6749 RFC6904 RFC6951 RFC7022 RFC7053 RFC7064 RFC7065 RFC7104 RFC7160 RFC7164 RFC7301 RFC7496 RFC7587 RFC7635 RFC7639 RFC7657 RFC7667 RFC7675 RFC7728 RFC7741 RFC7742 RFC7850 RFC7874 RFC6336 RFC7350 RFC6365 RFC7564 RFC5198 RFC7564 RFC7613 RFC7345 From nobody Tue Aug 30 05:40:19 2016 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 A615E12D1DC for ; Tue, 30 Aug 2016 05:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSuyvScUtWpt for ; Tue, 30 Aug 2016 05:40: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 D069212D1AE for ; Tue, 30 Aug 2016 05:40:15 -0700 (PDT) X-AuditID: c1b4fb3a-c91fe700000009bd-12-57c57ead90fc Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id CF.CE.02493.DAE75C75; Tue, 30 Aug 2016 14:40:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.211]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0301.000; Tue, 30 Aug 2016 14:40:12 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-17 Thread-Index: AQHSArumoLSMhmShLEeaTjKFtTBYDg== Date: Tue, 30 Aug 2016 12:40:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D3EB5A36E346christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ru66uqPhBsvrLNb+a2d3YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGmgeH2ArmmlQcvHmRqYHxnk4XIyeHhICJxM7139m6GLk4hATW M0rc3vwUylnCKLF8Yy9rFyMHB5uAhUT3P22QBhEBdYnLDy+wg9jCAm4SJ99+ZIeIu0vcfLmB BaRcREBP4uJnDpAwi4CqxI/HBxhBbF4BK4nZj1rAyhkFxCS+n1rDBGIzC4hL3HoynwniHgGJ JXvOM0PYohIvH/9jBbFFgUZ+/zobKq4o8fHVPkaI3niJ012PmSDmC0qcnPmEZQKj0CwkY2ch KZuFpAwibiDx/tx8ZghbW2LZwtdQtr7Exi9nGSFsa4kNk9tQ1Cxg5FjFKFqcWlycm25kpJda lJlcXJyfp5eXWrKJERgnB7f8ttrBePC54yFGAQ5GJR5ehYoj4UKsiWXFlbmHGCU4mJVEeItq j4YL8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYGR0/Pex /01bSFLI6YxdD1ZfjL/fPveTSL6PkoyacfDTXQK/v3tbvdT7I3TKTfbnzenhR9g11SqsfF1Z Jtj43BTu8Wyu2nbo9CrhC1oS0uKc/6++eJwhsy1z5/IzEftaQt26VcRmGW7YcXEqr72o7sNZ vx0XKkyZsGRWwtoZ67jbtu7RzlNzr1ViKc5INNRiLipOBABAQzVjjwIAAA== Archived-At: Subject: [rtcweb] FW: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-17 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 12:40:17 -0000 --_000_D3EB5A36E346christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI, Please raise any comments/questions on the MMUSIC list. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Tuesday 30 August 2016 at 15:36 To: "mmusic@ietf.org" > Cc: "mmusic-chairs@ietf.org" > Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sctp-sdp-17 Hi, The new version (-17) of draft-ietf-mmusic-sctp-sdp has finally been submit= ted. -The draft now takes draft-dtls-sdp and draft-4572-update into consideratio= n. -The procedures associated with SCTP/DTLS (DTLS over SCTP) have been remove= d, as nobody indicated a need to keep them. When it comes to the management of SCTP associations, DTLS associations and= TCP connections, the previous version of the draft took an approach from a= n SDP attribute perspective. In the new version, the draft takes an approac= h from an association/connection perspective, describes how each layer is m= anaged and how/if/which SDP attribute impact the association/connection. Th= e text also clarifies that each association/connection is managed independe= ntly of each other. For example, it is possible to re-establish an DTLS ass= ociation without touching the overlaying SCTP association, etc. NOTE: The draft now says that, since each SCTP endpoint is always =91active= =92, and both establish the SCTP association, the SDP =91setup=92 attribute= is not used for SCTP. IF someone thinks there is a use-case where a separa= tion of active and passive SCTP endpoint is needed, please bring it to the = list. There are no changes to how the SDP setup attribute impact the DTLS r= oles (client/server) and the TCP roles (active/passive). The draft was previously already in WGLC, but due to the changes in the lat= est version we should probably wait a bit before we continue the WGLC. I en= courage everyone to take a look =96 especially the browser/JSEP folks. I=92d like to give a special Thank You to Roman Shpount, for the input and = feedback he has given off-line. Regards, Christer --_000_D3EB5A36E346christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <06D038DE158C4F4AB18A8A6C89B9AC5A@ericsson.com> Content-Transfer-Encoding: quoted-printable
FYI,

Please raise any comments/questions on the MMUSIC list.

Regards,

Christer 

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Tuesday 30 August 2016 at 15:= 36
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Cc: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
Subject: [MMUSIC] Draft new version= : draft-ietf-mmusic-sctp-sdp-17

Hi,

The new version (-17) of draft-ietf-mmusic-sctp-sdp has finally b= een submitted.

-The draft now takes draft-dtls-sdp and draft-4572-update into conside= ration.
-The procedures associated with SCTP/DTLS (DTLS over SCTP) have been r= emoved, as nobody indicated a need to keep them. 

When it comes to the management of SCTP associations, DTLS association= s and TCP connections, the previous version of the draft took an approach f= rom an SDP attribute perspective. In the new version, the draft takes an ap= proach from an association/connection perspective, describes how each layer is managed and how/if/which SDP attr= ibute impact the association/connection. The text also clarifies that each = association/connection is managed independently of each other. For example,= it is possible to re-establish an DTLS association without touching the overlaying SCTP association, etc.=

NOTE: The draft now says that, since each SCTP endpoint is always =91a= ctive=92, and both establish the SCTP association, the SDP =91setup=92 attr= ibute is not used for SCTP. IF someone thinks there is a use-case where a s= eparation of active and passive SCTP endpoint is needed, please bring it to the list. There are no changes to how the SD= P setup attribute impact the DTLS roles  (client/server) and the TCP r= oles (active/passive).

The draft was previously already in WGLC, but due to the changes in th= e latest version we should probably wait a bit before we continue the WGLC.= I encourage everyone to take a look =96 especially the browser/JSEP folks.=

I=92d like to give a special Thank You to Roman Shpount, for the input= and feedback he has given off-line.

Regards,

Christer 
 --_000_D3EB5A36E346christerholmbergericssoncom_-- From nobody Tue Aug 30 15:54:55 2016 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 C778112D836 for ; Tue, 30 Aug 2016 15:54:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9Ad0XqxpLYM for ; Tue, 30 Aug 2016 15:54:52 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 2AF1D12D833 for ; Tue, 30 Aug 2016 15:54:52 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id e124so11451272ith.0 for ; Tue, 30 Aug 2016 15:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=XshMkqMod9U8Lvfa1S+jlzxMsIHtv/qiD7Q98rTq/+w=; b=m+weqNSq5JvztqXnxw/BbcnX9TwXMwi0JkChwOWrbB3dERIJWw5+ctVnXA2IOXS83f TMxCjkTEKRAi8vm+YWrQVFeMSEBlyrM020brZJ7mAmpZYIttuoZIRpqAMjUucwY1uIaf owqTP7UHG4/cGWEFrS8l32YbrVLvuHwuFSnXqFIwdpPnHT3QfVVdIsGLFNjhINknVZyx SHH1vWEnRC2zkP49jW6hXSCra5XdbWeAXY2NWr0uCiFzU/ld2qkwXrecJno3JY7OIu3B AzJmGafAlQGSUazz2dWsfbF4jubvn4EqMNwHJ18qpUYHF9nLQAAWYhU6ZVyTCY9Zkcku 6TFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=XshMkqMod9U8Lvfa1S+jlzxMsIHtv/qiD7Q98rTq/+w=; b=M8SPETSkucYPfVmTzpubz4iTVfjfSTTvSb553A3ou0iG7EDDdmxVJL7eZ8U47sfVQW 8CRSVju8rRRCvkofxj5+D5agpv9fnRdE3Uvk7mVxLJT88/c5Asj99YrtY4UtDu/Yn3ft FaUKxQMkf9Jn3iMMrCo7CP3vesPjt2fmTIDVVQQnYCtUfYf7G2cqXI4TaAj1OVgMoxMO /rZvdWZk08tnA/k2U4SN4ZDDIcie/kGUJ11Sd25xkSJX4RxMNRmpP3IAEqDujhwlrU40 Ycxs4KRDIVFZD9VXDpMQf2rntLVd8OlNCzvUbCJFx6S9dIKAw+IvRR3NU7Ge8sLzHgQN J+bw== X-Gm-Message-State: AE9vXwObiICeUMYEX4aQm0j/nD29i6lkLbwwV3HO48vtUHsa/nq1va9seo2SCJDTY6Jpjg== X-Received: by 10.36.155.213 with SMTP id o204mr9176716itd.96.1472597691357; Tue, 30 Aug 2016 15:54:51 -0700 (PDT) Received: from mail-it0-f48.google.com (mail-it0-f48.google.com. [209.85.214.48]) by smtp.gmail.com with ESMTPSA id 28sm581846iok.32.2016.08.30.15.54.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Aug 2016 15:54:51 -0700 (PDT) Received: by mail-it0-f48.google.com with SMTP id g62so65578827ith.1; Tue, 30 Aug 2016 15:54:51 -0700 (PDT) X-Received: by 10.107.20.151 with SMTP id 145mr2001407iou.70.1472597688657; Tue, 30 Aug 2016 15:54:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.14.11 with HTTP; Tue, 30 Aug 2016 15:54:48 -0700 (PDT) From: Roman Shpount Date: Tue, 30 Aug 2016 18:54:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "rtcweb@ietf.org" , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a114fa8ea2131be053b51de4c Archived-At: Subject: [rtcweb] SDP attribute setup=holdconn X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 22:54:54 -0000 --001a114fa8ea2131be053b51de4c Content-Type: text/plain; charset=UTF-8 Hi All, When discussing draft-ietf-mmusic-sctp-sdp with Christer we came up with a question regarding handling setup=holdconn. In case of TCP/DTLS/SCTP, the value of setup attribute is shared between TCP and DTLS. Per RFC 4145, TCP defines a use case for setup=holdconn. At the same time per draft-ietf-mmusic-dtls-sdp, setup=hodlconn must not be used. So, we have two options here: 1. Forbid using setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp 2. Define what setup=holdconn means for DTLS in draft-ietf-mmusic-dtls-sdp To provide the original background, in case of TCP, setup=holdconn essentially means that new TCP connection cannot be established as a result of this offer/answer exchange, no matter what other value has changed. It is used to differentiate the case when connection=existing is used with a passive TCP end point which wants to reuse existing connection and is not ready to accept a new TCP connection. In other words, when passive end point is ready to accept new TCP connection, the offer is sent with connection=existing and setup=passive. When no accept method was issued on the listening socket or if listening socket was already closed, the offer is sent with connection=existing and setup=holdconn. Since in case of DTLS, no accept method needs to be called on the socket before sending an offer and no extra resources are needed to accept new connection, I thought setup=holdconn was not necessary. This is why it was specified in draft-ietf-mmusic-dtls-sdp, that setup=holdconn must not be used. On the other hand there is no harm from setup=hodlconn. Furthermore there are certain aesthetic benefits when setup=holdconn is used with ICE and DTLS. When sending an update offer without ICE restart, specifying setup=holdconn can be used to indicate that answerer is not allowed to start a new DTLS association during this offer/answer exchange. So, once again, what should we do with setup=holdconn? Update draft-ietf-mmusic-dtls-sdp to define handling of setup=holdconn or prohibit setup=holdconn with TCP/DTLS/SCTP in draft-ietf-mmusic-sctp-sdp? Regards, _____________ Roman Shpount --001a114fa8ea2131be053b51de4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

When discussing draft-ietf-mmus= ic-sctp-sdp with Christer we came up with a question regarding handling set= up=3Dholdconn. In case of TCP/DTLS/SCTP,=C2=A0the value of setup attribute = is shared between TCP and DTLS. Per RFC 4145, TCP defines a use case for se= tup=3Dholdconn. At the same time per draft-ietf-mmusic-dtls-sdp, setup=3Dho= dlconn must not be used. So, we have two options here:

=
1. Forbid using setup=3Dholdconn with=C2=A0TCP/DTLS/SCTP in draft-ietf= -mmusic-sctp-sdp
2. Define what=C2=A0setup=3Dholdconn means for D= TLS in=C2=A0draft-ietf-mmusic-dtls-sdp

To provide the original background, in case = of TCP,=C2=A0=C2=A0setup=3Dholdconn essentially means that new TCP connecti= on cannot be established as a result of this offer/answer exchange, no matt= er what other value has changed. It is used to differentiate the case when = connection=3Dexisting is used with a passive TCP end point which wants to r= euse existing connection and is not ready to accept a new TCP connection. I= n other words, when passive end point is ready to accept new TCP connection= , the offer is sent with connection=3Dexisting and setup=3Dpassive. When no= accept method was issued on the listening socket or if listening socket wa= s already closed, the offer is sent with connection=3Dexisting and setup=3D= holdconn.

Since in case of DTLS, no accept method needs to be called on the socke= t before sending an offer and no extra resources are needed to accept new c= onnection, I thought setup=3Dholdconn was not necessary. This is why it was= specified in=C2=A0draft-ietf-mmusic-dtls-sdp, that setup=3Dholdconn must n= ot be used.=C2=A0On the other hand there is no harm from setup=3Dhodlconn. = Furthermore there are certain aesthetic benefits when setup=3Dholdconn is u= sed with ICE and DTLS. When sending an update offer without ICE restart, sp= ecifying=C2=A0setup=3Dholdconn can be used to indicate that answerer is not= allowed to start a new DTLS association during this offer/answer exchange.=

So, o= nce again, what should we do with setup=3Dholdconn? Update draft-ietf-mmusi= c-dtls-sdp to define handling of setup=3Dholdconn or prohibit =C2=A0setup= =3Dholdconn with=C2=A0TCP/DTLS/SCTP in=C2=A0draft-ietf-mmusic-sctp-sdp?

Regards,<= /div>
_______= ______
Roman Shpount
--001a114fa8ea2131be053b51de4c-- From nobody Wed Aug 31 05:01:19 2016 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 C32D712DB1F; Wed, 31 Aug 2016 05:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 ok2CW7qceXMF; Wed, 31 Aug 2016 05:01:08 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 7945412DB2D; Wed, 31 Aug 2016 05:00:58 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bf4CN-0003te-E2; Wed, 31 Aug 2016 14:00:55 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bf4CM-0007p5-4B; Wed, 31 Aug 2016 14:00:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Wed, 31 Aug 2016 14:00:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23F7C863-72FC-47B7-A749-AB6A3B9EBF32@ifi.uio.no> References: To: "Black, David" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 45799 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 56A9146D898A49C56DF4F28E28907B42013DCEFA X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 10972 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: RTCWeb IETF , "tsvwg@ietf.org" Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in draft-ietf-tsvwg-rtcweb-qos - Proposed text X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 12:01:13 -0000 Hi all, A small follow-up on this: given that this paper of ours at ANRW has started this whole discussion = on DSCP blackholing: https://irtf.org/anrw/2016/anrw16-final17.pdf ... I think it would be appropriate for draft-ietf-rtcweb-transports to = cite this paper in the text discussing it. Cheers, Michael > On 05 Aug 2016, at 23:27, Black, David wrote: >=20 > The -15 version of the rtcweb-transports draft has now been posted, = and the new text on non-zero DSCPs black-holing traffic is in Section = 4.2 = (https://tools.ietf.org/html/draft-ietf-rtcweb-transports-15#section-4.2).= Many thanks to Harald for adding this text. > =20 > The tsvwg-rtcweb-qos draft needs to note this issue and point to that = section of the rtcweb-transports draft. Here=E2=80=99s proposed text to = do that, which I suggest inserting as a new paragraph in Section 5 = immediately before Figure 1 = (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-17#section-5): > =20 > WebRTC use of multiple DSCP values may encounter network blocking = of packets > with certain DSCP values. See section 4.2 of = [I-D.ietf-rtcweb-transports] for > further discussion, including how WebRTC implementations establish = and > maintain connectivity when such blocking is encountered. > =20 > I hope something this short and simple will suffice. > =20 > Thanks, --David > =20 > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20= > Sent: Tuesday, August 02, 2016 1:29 PM > To: Black, David > Cc: Alissa Cooper; RTCWeb IETF; tsvwg@ietf.org > Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ? > =20 > Hi, Alissa and David, > =20 > Thanks to both of you. I didn't see the minutes on the Proceedings = page but didn't think to look for draft minutes on the mailing list. > =20 > Very helpful. > =20 > Spencer > =20 > On Mon, Aug 1, 2016 at 5:12 PM, Black, David = wrote: > > The -rtcweb-transports author Harald Alvestrand took on the action = item and will work with Justin Uberti to send a text proposal to the = list. > And when that text appears, we can figure out the wording (probably a = short sentence) to add to the tsvwg-rtcweb-qos draft to point to it over = in the rtcweb-transports draft. > =20 > Thanks, --David > =20 > From: Alissa Cooper [mailto:alissa@cooperw.in]=20 > Sent: Monday, August 01, 2016 4:46 PM > To: Spencer Dawkins at IETF > Cc: Black, David; RTCWeb IETF; tsvwg@ietf.org > Subject: Re: [rtcweb] [tsvwg] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ? > =20 > Hi Spencer, > =20 > On Aug 1, 2016, at 6:56 AM, Spencer Dawkins at IETF = wrote: > =20 > Hi, all, > =20 > On Thu, Jul 14, 2016 at 4:13 PM, Black, David = wrote: > Magnus, >=20 > I think that's a fine suggestion. I think the next step is: >=20 > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in = draft-ietf-rtcweb-transports > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about = the > > need, and indicate future forthcoming specification or if we hold = this > > document up until this solution is available? >=20 > I'll attend the Thu RTCWEB session in Berlin to see how this comes = out, > after which it should be straightforward for the draft authors and = yours > truly to write the sentence or two that draft-ietf-tsvwg-rtcweb-qos = will > need. > =20 > I'm just following up on this because we have = draft-ietf-rtcweb-transports on the telechat agenda this week, and I = didn't see a discussion on this topic in the RTCWeb agenda (or in poking = around for minutes, jabber, etherpad, etc).=20 > =20 > Here is the relevant bit from the RTCWEB minutes: > =20 > DSCP Black-holing Issue >=20 > David Black (TSVWG co-chair) presented the DSCP black-hole issue with = -rtcweb-transports draft that was recently discussed on the list. This = issue needs to be solved and described, even though both = -rtcweb-transports and the referenced draft-ietf-tsvwg-rtcweb-qos has = gone through IESG review. Magnus Westerlund has suggested a solution to = the list, but what should the -rtcweb-transports draft say about DSCP = black-holing and the possibility to use ICE to avoid it? > The WG discussed this and concluded that the issue should be described = by the -rtcweb-transports draft. Ted Hardie summarized the discussion by = suggesting a text formulation for a resolution that seemed acceptable to = the WG: =E2=80=9CWe will treat DSCP-induced path failure parallel with = other types of path failures and resolve it by using ICE restart. Note: = There is a problem with multiple DSCP codepoints on a single transport, = where one might be blocked and other might get through. In this case, = the ICE probes, using one DSCP codepoint, may succeed while others fail. = This is complex and should be warned about. A likely viable solution is = ICE restart with DSCP markings turned off, but detection requires = watching the multiple-DCSP-codepoint-using channels for differential = failures=E2=80=9D. If there are other proposals for resolution, please = contact Harald. Cullen Jennings asked David if this solution was = acceptable, but David wanted to see the text proposal. The = -rtcweb-transports author Harald Alvestrand took on the action item and = will work with Justin Uberti to send a text proposal to the list. > =20 > Harald has been on holidays since the IETF meeting but will aim to get = to this before the telechat. > =20 > Best, > Alissa > =20 >=20 > =20 > Did it happen? Was there a resolution? > =20 > Thanks, > =20 > Spencer > =20 > Thanks, --David >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, July 14, 2016 4:53 AM > > To: Cullen Jennings (fluffy); Black, David > > Cc: RTCWeb IETF; Michael Welzl; tsvwg@ietf.org > > Subject: Re: [tsvwg] [rtcweb] Fall-back to DSCP 0 in = draft-ietf-tsvwg-rtcweb-qos ? > > > > Den 2016-07-12 kl. 18:19, skrev Cullen Jennings (fluffy): > > > > > > short answer here but as David suggested =E2=80=A6 some = implementation use > > > the STUN packets in ICE or just in WebRTC style liveness tests = to > > > do the tests of if a given DSCP works or not. In general ICE is a > > > good tool to take a bunch of possible paths, test which work, and > > > select the best. > > > > I do agree that how you do the path checks when setting DSCP values = !=3D 0 > > is dependent on the context. For the WebRTC I do agree doing checks > > using ICE is quite reasonable. > > > > We already have similar path testing usages of ICE in the ECN for = RTP > > specification (RFC6679), see Section 7.2.1. I will note that taking = this > > as blueprint for DSCP testing, what is needed clearly requires a new > > separate specification. The components needs are: 1) A new STUN > > parameter to request the ICE peer to echo the DSCP field value = received. > > 2) A ICE capability parameter to be used in signalling negotiations = to > > determine capability for this feature. 3) Behaviour specification on = how > > to test values and interpret responses. This include things like if = one > > should actually establish multiple candidate pairs one with DSCP = testing > > and one without? > > > > So the question here is how to proceed with this issue. So I would > > suggest the following way forward. > > > > 1. draft-ietf-tsvwg-rtcweb-qos identifies the issue and recommends = the > > user to apply path verification methods but don't specify them. > > > > 2. Someone takes on the task to write a DSCP path verification = extension > > to ICE. > > > > 3. The natural place to indicate the need/recommendation for > > implementing this functionality would be in = draft-ietf-rtcweb-transports > > (Currently in IETF LC). However, here I think we need to have a > > discussion if RTCWEB WG wants to only place a suitable warning about = the > > need, and indicate future forthcoming specification or if we hold = this > > document up until this solution is available? > > > > > > Cheers > > > > Magnus Westerlund > > > > = ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > = ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > = ---------------------------------------------------------------------- >=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 Aug 31 08:44:50 2016 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 7694512D5D6 for ; Wed, 31 Aug 2016 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 wDmhWEEMxnL4 for ; Wed, 31 Aug 2016 08:44:44 -0700 (PDT) Received: from bongo.tulip.relay.mailchannels.net (bongo.tulip.relay.mailchannels.net [23.83.218.21]) (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 BF2EC12DAEE for ; Wed, 31 Aug 2016 08:28:02 -0700 (PDT) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2FB721BC1DF for ; Wed, 31 Aug 2016 15:27:59 +0000 (UTC) Received: from rcentral501.webserversystems.com (ip-10-107-69-155.us-west-2.compute.internal [10.107.69.155]) by relay.mailchannels.net (Postfix) with ESMTPA id 54C0B1BC98D for ; Wed, 31 Aug 2016 15:27:58 +0000 (UTC) X-Sender-Id: wwwh|x-authuser|randell@jesup.org Received: from rcentral501.webserversystems.com ([TEMPUNAVAIL]. [10.16.27.41]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.6); Wed, 31 Aug 2016 15:27:58 +0000 X-MC-Ingress-Time: 1472657278697 X-MC-Relay: Neutral X-MailChannels-SenderId: wwwh|x-authuser|randell@jesup.org X-MailChannels-Auth-Id: wwwh X-MC-Loop-Signature: 1472657278513:3103591373 Received: from pool-108-16-238-163.phlapa.fios.verizon.net ([108.16.238.163]:61805 helo=[192.168.1.12]) by rcentral501.webserversystems.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bf7RU-0005i4-4k for rtcweb@ietf.org; Wed, 31 Aug 2016 11:28:44 -0400 References: <724F4BD9-521C-47F7-AA33-155323F25ED3@iii.ca> To: rtcweb@ietf.org From: Randell Jesup Message-ID: <127876fa-32a5-473c-3820-af28dd82ab10@jesup.org> Date: Wed, 31 Aug 2016 11:27:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <724F4BD9-521C-47F7-AA33-155323F25ED3@iii.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AuthUser: randell@jesup.org Archived-At: Subject: Re: [rtcweb] Is support for non square pixels MTI X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:44:49 -0000 On 8/25/2016 9:20 AM, Cullen Jennings wrote: > I was trying to figure out from the specs what the story is on WebRTC support for non square pixels (for example CIF resolution video is often not quite square pixels). > > Thoughts on what the specs should say on this ? Anyone know what browser do today? Yeah... ugh. So most cameras *now* are square pixels. Non-square pixel support would allow things like 640x240 (or 320x480) at 2:1/1:2 ratios as well. Some much older cameras are the 10:11-ish ratios that also apply to BT.601/etc (see https://en.wikipedia.org/wiki/Pixel_aspect_ratio), and HDV/HDCAM (1.3 -- 1440x1080). So we should be defining how MediaStreamTracks and PeerConnections deal with this. Must all MSTs be square pixels always? (and what if the source just isn't, must it be converted to square at the input point (typically GetUserMedia)? Can PeerConnection carry a non-square-pixel stream (separate from the MST requirement) for use outside of the W3 environment? If so, how is it signaled? (I suspect there's some way to do so in the SDP, haven't checked). If non-square are allowed in MSTs, we need to define some property of the stream so the
--001a11492ce81ea68e053b63c529-- From nobody Wed Aug 31 15:52:26 2016 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 EBBE412D763 for ; Wed, 31 Aug 2016 15:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 apwrvZpPl0zk for ; Wed, 31 Aug 2016 15:52:23 -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 A60FF12D77D for ; Wed, 31 Aug 2016 15:52:23 -0700 (PDT) Received: from smtp31.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 03BBBA04F4; Wed, 31 Aug 2016 18:52:23 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp31.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 997C8A0474; Wed, 31 Aug 2016 18:52:22 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.7); Wed, 31 Aug 2016 18:52:23 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 31 Aug 2016 16:52:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6975D517-BB5A-4209-BAE2-5CCAB683D321@iii.ca> References: <2AF34981-F961-40FE-83B7-CE0EC64AEBEC@iii.ca> To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: RTCWeb IETF Subject: Re: [rtcweb] draft-ietf-rtcweb-security-arch and crypto agility X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 22:52:25 -0000 > On Aug 31, 2016, at 2:15 PM, Eric Rescorla wrote: >=20 > On Wed, Aug 31, 2016 at 10:51 AM, Cullen Jennings = wrote: > The security arch only requires one cipher = TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve. Only = having one seems like a bad idea of a crypto agility point of view. Lets = say it turns out there is a problem with that curve or with EC in = general, deployments will not have anything they can switch to. >=20 > Having just one MTI cipher suite is pretty much SOP (this is what TLS = 1.2 does, for instance). > I wouldn't be opposed to requiring another group, presumably either = X25519 or FFDH2048. > (Yes, I am aware that these are at opposite ends of the spectrum). >=20 >=20 > I'd like to keep one of the RSA based ciphers as also MTI. >=20 > The RSA ciphers do not provide PFS, so I do not think this is a good = plan >=20 I was assuming some sort of DH combined with RSA. I do know we want to = stick with PFS schemes.=20