From nobody Fri Feb 1 09:09:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB31130934 for ; Fri, 1 Feb 2019 09:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 G5LIelEazw5M for ; Fri, 1 Feb 2019 09:09:17 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 7DAF7131065 for ; Fri, 1 Feb 2019 09:09:17 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id c123so3524239pfb.0 for ; Fri, 01 Feb 2019 09:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YZ0oKaTF9P548qmCWeUeJGbKicw6Jis3S2Z9XYykzzo=; b=0DzLiuCIz9fPI6qJJjKsdsWeSBflPGpn61msvwtHNaxyMSvQAx8Te9gnm0Nm6Tc9vq ADr2qBubBLptPryv2uCGZF7MmIyihZQmIG9Msie1jQ63X3qimuqzDvFAKo8h+jizZPSe Aqu6dyAnhV/JV2pKCxXLL+xFZAPeLTolssWbWuyiSb0I2cbKcbfPA1ot85K6slTfs5JW PSC8HhIrWFnMzmD5/bFTYekMxWPjRoYzeJNZV4YojhDClHTDU8k9h5RsEUd46EdWdJmg r1SjejlVTTTTrRaLlxNCSWHqEeB+H0sZuGuKhQm8CPh6esL6tpZ0Eku7J4CRLbmf6NF9 iNrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YZ0oKaTF9P548qmCWeUeJGbKicw6Jis3S2Z9XYykzzo=; b=dHyQ4jycmfeNEqRbmN8hui2dpYQJh62arOB5KAIV/w5EQrTssz2Yh4mO3lVwSIzbAe 9MnlRE1JzGds9+ffYyLqTPdaWVY2CTHrv9Z2qaq+m90VHsKByWQuKvYgA+SC2PskGIgQ 0jfLSXn0CEhl6qrpHaIDpteVfPaq3MpnVwzT+n3AkBhZGpflNLY4Kv1BX6ZjionaGb4J wLFWjPvEYF97DJcqSAt8qHOPFNYVL4a73icyPoUf5GomjVIehjQo+3WA4gVRf1Hmmv2l muEppr6N+EzWwih2y6ERyx6O27y55XHob7l8pEeyzpupfXWfa9oHFkemHyMKJzYKGhGA 3U2g== X-Gm-Message-State: AHQUAuYdtPjSqeipuFjZAhzANwxUfEZuKg2Btoxyo4ou6VdAkAGqeeka xvjE2oRnsNxn8Af6LnV4c1cElSniiRE= X-Google-Smtp-Source: AHgI3IYnpr/16IPQ6yLvI8QizZbJOS/pFfhVzvmppIxKl/gWNCnhyYzADHnZNmceB4PuAl62fVb6Tw== X-Received: by 2002:a63:9749:: with SMTP id d9mr2900925pgo.415.1549040956754; Fri, 01 Feb 2019 09:09:16 -0800 (PST) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com. [209.85.210.177]) by smtp.gmail.com with ESMTPSA id u12sm3434123pgo.52.2019.02.01.09.09.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 09:09:15 -0800 (PST) Received: by mail-pf1-f177.google.com with SMTP id g62so3488988pfd.12; Fri, 01 Feb 2019 09:09:15 -0800 (PST) X-Received: by 2002:a63:b4c:: with SMTP id a12mr3064102pgl.131.1549040955470; Fri, 01 Feb 2019 09:09:15 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Fri, 1 Feb 2019 12:09:05 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG , Simon Perreault Content-Type: multipart/alternative; boundary="000000000000e4b8c00580d833f5" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 17:09:20 -0000 --000000000000e4b8c00580d833f5 Content-Type: text/plain; charset="UTF-8" Hi Justin, I agree regarding #1 in theory, even though in practice a lot of (most) devices will not accept FQDN in either c= or ICE candidate. Regarding #2, mmusic-ice-sip-sdp was updated ( https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1): : is taken from RFC 4566 [RFC4566 ]. It is the IP address of the candidate. When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value -- the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. Specifically, support for FQDN names there was removed due to RFC 8445 implementation issues. I believe Simon Perreault suggested this change. Regards, _____________ Roman Shpount On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti wrote: > My recommendation here would be that we do c=IN IP6 > 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6 > depending on which type of address is being wrapped. > > Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN > in the c= line. > > unicast-address = IP4-address / IP6-address / FQDN / extn-addr > > > Re #2: Quoth 5245 : > > : is taken from RFC 4566 [RFC4566 ]. It is the > IP address of the candidate, allowing for IPv4 addresses, IPv6 > addresses, and *fully qualified domain names (FQDNs).* When parsing > this field, an agent can differentiate an IPv4 address and an IPv6 > > address by presence of a colon in its value - the presence of a > colon indicates IPv6. An agent MUST ignore candidate lines that > include candidates with IP address versions that are not supported > or recognized. An IP address SHOULD be used, but an FQDN MAY be > used in place of an IP address. In that case, when receiving an > offer or answer containing an FQDN in an a=candidate attribute, > the FQDN is looked up in the DNS first using an AAAA record > (assuming the agent supports IPv6), and if no result is found or > the agent only supports IPv4, using an A. If the DNS query > returns more than one IP address, one is chosen, and then used for > the remainder of ICE processing. > > > > > > > > > > On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount wrote: > >> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti >> wrote: >> >>> We can however all agree that "c=IN IP6" is busted: >>> https://bugs.chromium.org/p/chromium/issues/detail?id=927309 >>> >>>> >>>>> >> I guess one way to interpret this that each address should have a MDNS >> alias. So, if you are dealing with dual stack host, it should provide two >> MDNS candidates, one of which is IPv4 and another IPv6. The c= line should >> specify FQDN for one of those candidates and specify the type (IP4 or IP6). >> >> There are two problems: >> >> 1. There is no way to know which address type is in the candidate-address >> when FQDN is used there. Guidance in ice-sip-sdp is talking about the >> presence of column in IP6 address, but this definitely does not apply to >> FQDN. It would've been better to specify something like local4 and local6 >> as FQDN suffix in MDNS alias to specify the candidate-address type so that >> correct DNS request can be issued. >> >> 2. A lot (if not most) SDP/ICE implementations do no support parsing FQDN >> in candidate-address or c= line. This might create interop problems since >> RFC 5245 specified that candidate-address is an IP Address. >> >> Regards, >> _____________ >> Roman Shpount >> >> > --000000000000e4b8c00580d833f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

I agree regarding #1 in theory, even though in practice a lot of (mos= t) devices will not accept FQDN in either c=3D or ICE candidate.
=
Regarding #2, mmusic-ice-sip-sdp was updated (http= s://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1):<= /div>

RFC 4566 [RFC4566=
].  It is the
      IP address of the candidate.  When parsing this field, an agent
      can differentiate an IPv4 address and an IPv6 address by presence
      of a colon in its value -- the presence of a colon indicates IPv6.
      An agent MUST ignore candidate lines that include candidates with
      IP address versions that are not supported or recognized.

Specifically, suppo= rt for FQDN names there was removed due to=C2=A0RFC 8445 implementation issues. I believe=C2=A0Simon Perreault suggested this change.

Regards,
_____________
Roman = Shpount


On Fri, Feb 1, 2019 at 12:02 AM Ju= stin Uberti <juberti@google.com> wrote:
My recommendation here would be that we= do c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 = or IP6 depending on which type of address is being wrapped.

<= /div>
Re #1:=C2=A0RFC 4566 seems to indicate you can use either IP4 or = IP6 for FQDN in the c=3D line.

     unicast-ad=
dress =3D     IP4-address / IP6-address / FQDN / extn-addr

Re #2: Quoth 5245:

RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When par= sing this field, an agent can differentiate an IPv4 address and an IPv6 
      address by presence of a colon in its value - the presence =
of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.








On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount <= roman@telurix.com> wrote:

I guess one way to interpret this= that each address should have a MDNS alias. So, if you are dealing with du= al stack host, it should provide two MDNS candidates, one of which is IPv4 = and another IPv6. The c=3D line should specify FQDN for one of those candid= ates and specify the type (IP4 or IP6).

There are = two problems:

1. There is no way to know which add= ress type is in the candidate-address when FQDN is used there. Guidance in = ice-sip-sdp is talking about the presence of column in IP6 address, but thi= s definitely does not apply to FQDN. It would've been better to specify= something like local4 and local6 as FQDN suffix in MDNS alias to specify t= he candidate-address type so that correct DNS request can be issued.
<= div>
2. A lot (if not most) SDP/ICE implementations do no sup= port parsing FQDN in candidate-address or c=3D line. This might create inte= rop problems since RFC 5245 specified that candidate-address is an IP Addre= ss.

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000e4b8c00580d833f5-- From nobody Fri Feb 1 09:39:37 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DF81310B8 for ; Fri, 1 Feb 2019 09:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hinBWNJH3khC for ; Fri, 1 Feb 2019 09:39:25 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 1B431131127 for ; Fri, 1 Feb 2019 09:39:25 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id g8so6350944iok.4 for ; Fri, 01 Feb 2019 09:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X48I0BkcRT1I8Qu0jeHdHaGeGuNVVnUqpIZNQMcgDJs=; b=niM0nxrFZgHht9Icb/D9QJ34KwXqOrIaRBI5yBGirinFupgbSDOp7F1UVLquxia3hk 6+mu1VTVTRrmAYCM/Kd4MDOykh18sV6EOd+BRR89sWLy3y6hqzt8qus/n80uuAOdv4Q+ 3n6KPR6ApzKdSQZu6LYwqPwB5Omi28zBP2y363fGpA0yrGxM8rxUbEk91faU+pL9pIru PcQxKebdWabZ++KAaZumxKxFMO2ryV/wz2+7MWO2J7bg/P+M4IDN10k5TeP1QBgOJYNL ok/xcG3+f2/a16b3jYURPdPIZbC2P/gi2+A/D60LzZT0fdf1JztW0zjOYgUnx7UH5t8W XliA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X48I0BkcRT1I8Qu0jeHdHaGeGuNVVnUqpIZNQMcgDJs=; b=V4hhyPBMnDpVS2cU1OQEOEEK5pilsjEMvxWrHfjuNHG6krL/rw52Y8TiVZuEqDPuh2 +OGQKtWNZwxcxeRsY6aG+R7ZOLjx3ylEps7KTXxgYSax+DfrvUBrQVnUzJu/NAmycBa5 XbulxeWf/K6IX9mTUF++Xx7XcE03PII3/jSJc9ED6e2ZzIZkxCel+7WNP0S40nzK0fwe R8tswVEBBVBXVBnLn8OSLxprl6r5pxP1PnezVVjCMsuwlOwBooLMSwuB7ZBOovL+cxr9 HaT/bCyp30cQI6EZUwml3TDYZgCseF8MUy5WqeWkfabaXhwcYHY+CONLC5b4BdB8stTC VGEQ== X-Gm-Message-State: AHQUAua/hxe5r4UuVL88aOtOyZZ6YFYcpeOWspOuEeEhRK15nOzhSSyB 9g++UKA0DTn4YkrkAL2ultY8RR96sWaJqpYs3SGRWw== X-Google-Smtp-Source: ALg8bN6ZYpnX3AnKrPSBU+TuyWS4pf14JlHO7n5ZSVZKKvbUWxD9JUp6NIW5+5YSMjc5dSkZWCEudkukhtY9nseuKac= X-Received: by 2002:a5d:898b:: with SMTP id m11mr22104275iol.181.1549042763859; Fri, 01 Feb 2019 09:39:23 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Justin Uberti Date: Fri, 1 Feb 2019 09:39:12 -0800 Message-ID: To: Roman Shpount Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG , Simon Perreault Content-Type: multipart/alternative; boundary="000000000000af0cc80580d89f22" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 17:39:36 -0000 --000000000000af0cc80580d89f22 Content-Type: text/plain; charset="UTF-8" I understand there were questions about the general case (e.g. regular DNS names), but how do we plan to reconcile this removal with the need for mDNS hostnames? On Fri, Feb 1, 2019 at 9:09 AM Roman Shpount wrote: > Hi Justin, > > I agree regarding #1 in theory, even though in practice a lot of (most) > devices will not accept FQDN in either c= or ICE candidate. > > Regarding #2, mmusic-ice-sip-sdp was updated ( > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1): > > : is taken from RFC 4566 [RFC4566 ]. It is the > IP address of the candidate. When parsing this field, an agent > can differentiate an IPv4 address and an IPv6 address by presence > of a colon in its value -- the presence of a colon indicates IPv6. > An agent MUST ignore candidate lines that include candidates with > IP address versions that are not supported or recognized. > > > Specifically, support for FQDN names there was removed due to RFC 8445 > implementation issues. I believe Simon Perreault suggested this change. > > Regards, > _____________ > Roman Shpount > > > On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti wrote: > >> My recommendation here would be that we do c=IN IP6 >> 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6 >> depending on which type of address is being wrapped. >> >> Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN >> in the c= line. >> >> unicast-address = IP4-address / IP6-address / FQDN / extn-addr >> >> >> Re #2: Quoth 5245 : >> >> : is taken from RFC 4566 [RFC4566 ]. It is the >> IP address of the candidate, allowing for IPv4 addresses, IPv6 >> addresses, and *fully qualified domain names (FQDNs).* When parsing >> this field, an agent can differentiate an IPv4 address and an IPv6 >> >> address by presence of a colon in its value - the presence of a >> colon indicates IPv6. An agent MUST ignore candidate lines that >> include candidates with IP address versions that are not supported >> or recognized. An IP address SHOULD be used, but an FQDN MAY be >> used in place of an IP address. In that case, when receiving an >> offer or answer containing an FQDN in an a=candidate attribute, >> the FQDN is looked up in the DNS first using an AAAA record >> (assuming the agent supports IPv6), and if no result is found or >> the agent only supports IPv4, using an A. If the DNS query >> returns more than one IP address, one is chosen, and then used for >> the remainder of ICE processing. >> >> >> >> >> >> >> >> >> >> On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount wrote: >> >>> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti >>> wrote: >>> >>>> We can however all agree that "c=IN IP6" is busted: >>>> https://bugs.chromium.org/p/chromium/issues/detail?id=927309 >>>> >>>>> >>>>>> >>> I guess one way to interpret this that each address should have a MDNS >>> alias. So, if you are dealing with dual stack host, it should provide two >>> MDNS candidates, one of which is IPv4 and another IPv6. The c= line should >>> specify FQDN for one of those candidates and specify the type (IP4 or IP6). >>> >>> There are two problems: >>> >>> 1. There is no way to know which address type is in the >>> candidate-address when FQDN is used there. Guidance in ice-sip-sdp is >>> talking about the presence of column in IP6 address, but this definitely >>> does not apply to FQDN. It would've been better to specify something like >>> local4 and local6 as FQDN suffix in MDNS alias to specify the >>> candidate-address type so that correct DNS request can be issued. >>> >>> 2. A lot (if not most) SDP/ICE implementations do no support parsing >>> FQDN in candidate-address or c= line. This might create interop problems >>> since RFC 5245 specified that candidate-address is an IP Address. >>> >>> Regards, >>> _____________ >>> Roman Shpount >>> >>> >> --000000000000af0cc80580d89f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understand there were questions about the general case (= e.g. regular DNS names), but how do we plan to reconcile this removal with = the need for mDNS hostnames?

On Fri, Feb 1, 2019 at 9:09 AM Roman Shpount = <roman@telurix.com> wrote:
=
Hi Justin,

I agree reg= arding #1 in theory, even though in practice a lot of (most) devices will n= ot accept FQDN in either c=3D or ICE candidate.

Re= garding #2, mmusic-ice-sip-sdp was updated (htt= ps://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1):= 

   <connection-address>:  is taken fro=
m RFC 456=
6 [RFC4566].  It is =
the
      IP address of the candidate.  When parsing this field, an agent
      can differentiate an IPv4 address and an IPv6 address by presence
      of a colon in its value -- the presence of a colon indicates IPv6.
      An agent MUST ignore candidate lines that include candidates with
      IP address versions that are not supported or recognized.
<=
br>
Specifically, support for FQDN names there was removed due to=C2= =A0RFC 8445 implementation issues. I belie= ve=C2=A0Simon Perreault suggested this chang= e.

Regards,
_____________
Roman Shpount


On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti <<= a href=3D"mailto:juberti@google.com" target=3D"_blank">juberti@google.com> wrote:
My recommendation here would be that w= e do c=3DIN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4= or IP6 depending on which type of address is being wrapped.

=
Re #1:=C2=A0RFC 4566 seems to indicate you can use either IP4 or= IP6 for FQDN in the c=3D line.

     unicast-address =3D     IP4-address / IP6-address / FQDN=
 / extn-addr

Re #2: Quoth 5245:

<connection-address>: is taken from= RFC 4566= [RFC4566]. It is t= he IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When par= sing this field, an agent can differentiate an IPv4 address and an IPv6 
      address by presence of a colon =
in its value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.








On T= hu, Jan 31, 2019 at 8:43 PM Roman Shpount <roman@telurix.com> wrote:
On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti &l= t;juberti@google.co= m> wrote:
<= div dir=3D"ltr">We can however all agree that "c=3DIN IP6" is bus= ted:=C2=A0https://bugs.chromium.org/p/chromium/issues/de= tail?id=3D927309


I guess one way to interpret this= that each address should have a MDNS alias. So, if you are dealing with du= al stack host, it should provide two MDNS candidates, one of which is IPv4 = and another IPv6. The c=3D line should specify FQDN for one of those candid= ates and specify the type (IP4 or IP6).

There are = two problems:

1. There is no way to know which add= ress type is in the candidate-address when FQDN is used there. Guidance in = ice-sip-sdp is talking about the presence of column in IP6 address, but thi= s definitely does not apply to FQDN. It would've been better to specify= something like local4 and local6 as FQDN suffix in MDNS alias to specify t= he candidate-address type so that correct DNS request can be issued.
<= div>
2. A lot (if not most) SDP/ICE implementations do no sup= port parsing FQDN in candidate-address or c=3D line. This might create inte= rop problems since RFC 5245 specified that candidate-address is an IP Addre= ss.

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000af0cc80580d89f22-- From nobody Fri Feb 1 11:18:23 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31FE131295 for ; Fri, 1 Feb 2019 11:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7zTsg4QIKTWm for ; Fri, 1 Feb 2019 11:18:13 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 F210A131298 for ; Fri, 1 Feb 2019 11:18:12 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id d72so3365455pga.9 for ; Fri, 01 Feb 2019 11:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ksCmdtoHl28Hj3jY7BQmUL1XIbv8XQSylwigR5lyfRM=; b=ay9s+HVbcLON6dyEUg81WA2c/r+GX+qsIGVJUKxNGKRA9LQdxgVwAv/gc8TPpRK6xT uO3GvlCn9mShMaQQnmM8ACR6Nxa9jGp+h/eBl46fVBt3ey9QfHwDjg8Tgur2RUnCTHFE wuevjgnSKvvHhUMb5VKRRF8ayJIXGGBN/LTVmy+GHOhFtBGSLGKAOQL4oeT69005FlQK +c5YLvfNBsM4s2heJ0KMvbi+I9L2gXxd3ACZEb2/WGQZg5fJAnuCHzsEV86bvPBo9F25 nfaG9TC12vTG2h/q9lOWxOe1aVjUuml/BTvCdGhGr0WdeP7apg+CfK4Agn9Wa39X+vzO YFNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ksCmdtoHl28Hj3jY7BQmUL1XIbv8XQSylwigR5lyfRM=; b=VaMD3Y64ISAqSjKcpl5pldUEiMMxXmZRaRmd+09s5/eBXvkLQfYBwq415duRur6EA9 LAokb4o9Nncovd2CTjHZGvE4asFIanTzVhs/oH2KAJ5d/KqU14CsSpCv5FvnwL8XtKZh +iLNXkf55YFTtqhT2iZOlEuhNSk0d1QqGXIHdBYeaFlbwVEh+T8HunP7D1bOljHkYjag K9kPEq91EACTOmu7hrnzsvz01UL/Gtda0W04W7gtVo8eA5yDRk1bCjdXZEBFh8Sk3xUH kXvFho0qJLZkM31aWxDFa69f4XEhtiiOSaV9PNddFPjriW6VvFMm/o14herG931utW6F Alvg== X-Gm-Message-State: AHQUAuawQc1vUl9j05zJbT/qg+Q2563d+oKppVmS9GJuFh8vxGvA2I7h 7CGSz+9rgy+X6MJB1RkZoAJHl/VJTrc= X-Google-Smtp-Source: AHgI3IZ1WeFfXUicROyXm+ZU3p+DJqPSM9LBVUVjNJUHumlnmpZ/VCYJni5GOmWhjzrbbiMgEhuNXA== X-Received: by 2002:a62:3a8b:: with SMTP id v11mr9399110pfj.81.1549048692269; Fri, 01 Feb 2019 11:18:12 -0800 (PST) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com. [209.85.210.180]) by smtp.gmail.com with ESMTPSA id g190sm10014309pgc.28.2019.02.01.11.18.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 11:18:11 -0800 (PST) Received: by mail-pf1-f180.google.com with SMTP id w73so3671778pfk.10; Fri, 01 Feb 2019 11:18:11 -0800 (PST) X-Received: by 2002:a62:160d:: with SMTP id 13mr40326587pfw.203.1549048690972; Fri, 01 Feb 2019 11:18:10 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Fri, 1 Feb 2019 14:18:01 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG , Simon Perreault Content-Type: multipart/alternative; boundary="000000000000f71ef00580da00c6" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 19:18:16 -0000 --000000000000f71ef00580da00c6 Content-Type: text/plain; charset="UTF-8" Most likely mDNS draft will need to update RFC 8445 to specify how ICE nomination procedures are modified, when mDNS is used as candidate-address. As far as mmusic-ice-sip-sdp is concerned, one option would be to allow FQDN as candidate-address. The guidance for handling FQDN in candidate-address should be updated from RFC 5245 and should specify that FQDN names should be ignored. mDNS ICE draft then will update ice-sip-sdp and specify that mDNS FQDN should be handled according the procedures of this draft. Another option, which I think word work better with existing specifications is to add a new candidate type -- mdns. This way, instead of magic DNS suffix, candidate type will be used to determine that this candidate should be handled differently. I do not think MDNS candidates can be used for anything except host candidates, so making then a special candidate type might be the least painful option. It might even make sense to make separate types for IPv4 and IPv6 MDNS candidates which would save a DNS query for each candidate. Regards, _____________ Roman Shpount On Fri, Feb 1, 2019 at 12:39 PM Justin Uberti wrote: > I understand there were questions about the general case (e.g. regular DNS > names), but how do we plan to reconcile this removal with the need for mDNS > hostnames? > > On Fri, Feb 1, 2019 at 9:09 AM Roman Shpount wrote: > >> Hi Justin, >> >> I agree regarding #1 in theory, even though in practice a lot of (most) >> devices will not accept FQDN in either c= or ICE candidate. >> >> Regarding #2, mmusic-ice-sip-sdp was updated ( >> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1 >> ): >> >> : is taken from RFC 4566 [RFC4566 ]. It is the >> IP address of the candidate. When parsing this field, an agent >> can differentiate an IPv4 address and an IPv6 address by presence >> of a colon in its value -- the presence of a colon indicates IPv6. >> An agent MUST ignore candidate lines that include candidates with >> IP address versions that are not supported or recognized. >> >> >> Specifically, support for FQDN names there was removed due to RFC 8445 >> implementation issues. I believe Simon Perreault suggested this change. >> >> Regards, >> _____________ >> Roman Shpount >> >> >> On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti wrote: >> >>> My recommendation here would be that we do c=IN IP6 >>> 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6 >>> depending on which type of address is being wrapped. >>> >>> Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN >>> in the c= line. >>> >>> unicast-address = IP4-address / IP6-address / FQDN / extn-addr >>> >>> >>> Re #2: Quoth 5245 : >>> >>> : is taken from RFC 4566 [RFC4566 ]. It is the >>> IP address of the candidate, allowing for IPv4 addresses, IPv6 >>> addresses, and *fully qualified domain names (FQDNs).* When parsing >>> this field, an agent can differentiate an IPv4 address and an IPv6 >>> >>> address by presence of a colon in its value - the presence of a >>> colon indicates IPv6. An agent MUST ignore candidate lines that >>> include candidates with IP address versions that are not supported >>> or recognized. An IP address SHOULD be used, but an FQDN MAY be >>> used in place of an IP address. In that case, when receiving an >>> offer or answer containing an FQDN in an a=candidate attribute, >>> the FQDN is looked up in the DNS first using an AAAA record >>> (assuming the agent supports IPv6), and if no result is found or >>> the agent only supports IPv4, using an A. If the DNS query >>> returns more than one IP address, one is chosen, and then used for >>> the remainder of ICE processing. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount wrote: >>> >>>> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti >>>> wrote: >>>> >>>>> We can however all agree that "c=IN IP6" is busted: >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=927309 >>>>> >>>>>> >>>>>>> >>>> I guess one way to interpret this that each address should have a MDNS >>>> alias. So, if you are dealing with dual stack host, it should provide two >>>> MDNS candidates, one of which is IPv4 and another IPv6. The c= line should >>>> specify FQDN for one of those candidates and specify the type (IP4 or IP6). >>>> >>>> There are two problems: >>>> >>>> 1. There is no way to know which address type is in the >>>> candidate-address when FQDN is used there. Guidance in ice-sip-sdp is >>>> talking about the presence of column in IP6 address, but this definitely >>>> does not apply to FQDN. It would've been better to specify something like >>>> local4 and local6 as FQDN suffix in MDNS alias to specify the >>>> candidate-address type so that correct DNS request can be issued. >>>> >>>> 2. A lot (if not most) SDP/ICE implementations do no support parsing >>>> FQDN in candidate-address or c= line. This might create interop problems >>>> since RFC 5245 specified that candidate-address is an IP Address. >>>> >>>> Regards, >>>> _____________ >>>> Roman Shpount >>>> >>>> >>> --000000000000f71ef00580da00c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Most likely mDNS draft will need to updat= e RFC 8445=C2=A0to specify how ICE = nomination procedures are modified, when mDNS is used as candidate-address.= =C2=A0

As far as mmusic-ic= e-sip-sdp is concerned, one option would be to allow FQDN as candidate-addr= ess. The guidance for handling FQDN in candidate-address should be updated = from RFC 5245 and should specify that FQDN names should be ignored. mDNS IC= E draft then will update ice-sip-sdp and specify that mDNS FQDN should be h= andled according the procedures of this draft.

Another option, which I think word work better with ex= isting specifications is to add a new candidate type -- mdns. This way, ins= tead of magic DNS suffix, candidate type will be used to determine that thi= s candidate should be handled differently. I do not think MDNS candidates c= an be used for anything except host candidates, so making then a special ca= ndidate type might be the least painful option. It might even make sense to= make separate types for IPv4 and IPv6 MDNS candidates which would save a D= NS query for each candidate.

Regards,
_____________
Roman Shpount


On Fri, Feb 1, 2019 at 12:39 PM Justin Uberti <juberti@google.com> wrote:
I understand there = were questions about the general case (e.g. regular DNS names), but how do = we plan to reconcile this removal with the need for mDNS hostnames?
On Fri, = Feb 1, 2019 at 9:09 AM Roman Shpount <roman@telurix.com> wrote:
Hi Justin,

I agree regarding #1 in theory,= even though in practice a lot of (most) devices will not accept FQDN in ei= ther c=3D or ICE candidate.

Regarding #2, mmusic-i= ce-sip-sdp was updated (https://tools.ietf.org/= html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1):

   <connection-address>:  is t=
aken from RFC 4566 [RFC4566].=
  It is the
      IP address of the candidate.  When parsing this field, an agent
      can differentiate an IPv4 address and an IPv6 address by presence
      of a colon in its value -- the presence of a colon indicates IPv6.
      An agent MUST ignore candidate lines that include candidates with
      IP address versions that are not supported or recognized.

Specifically, support for FQDN names t= here was removed due to=C2=A0RFC 8445 impl= ementation issues. I believe=C2=A0Simon Perr= eault suggested this change.

<= /font>
Regards,
_____________
Roman Shpount

<= /div>

On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti <juberti@google.com> wrote:
My recommendation here would be that we do c=3DIN IP6 355= 7773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6 depending o= n which type of address is being wrapped.

Re #1:= =C2=A0RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN in = the c=3D line.

     unicast-address =3D     IP4-address / IP6-add=
ress / FQDN / extn-addr

Re #2: Quoth 5245:

<connection= -address>: is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When par= sing this field, an agent can differentiate an IPv4 address and an IPv6 
      add=
ress by presence of a colon in its value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.








On Thu, Jan 31, 2019 at 8:43 PM R= oman Shpount <rom= an@telurix.com> wrote:
On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti <= ;juberti@google.com= > wrote:
We can however all agree that "c=3DIN IP6" is bust= ed:=C2=A0https://bugs.chromium.org/p/chromium/issues/de= tail?id=3D927309


I guess one way to interpret this= that each address should have a MDNS alias. So, if you are dealing with du= al stack host, it should provide two MDNS candidates, one of which is IPv4 = and another IPv6. The c=3D line should specify FQDN for one of those candid= ates and specify the type (IP4 or IP6).

There are = two problems:

1. There is no way to know which add= ress type is in the candidate-address when FQDN is used there. Guidance in = ice-sip-sdp is talking about the presence of column in IP6 address, but thi= s definitely does not apply to FQDN. It would've been better to specify= something like local4 and local6 as FQDN suffix in MDNS alias to specify t= he candidate-address type so that correct DNS request can be issued.
<= div>
2. A lot (if not most) SDP/ICE implementations do no sup= port parsing FQDN in candidate-address or c=3D line. This might create inte= rop problems since RFC 5245 specified that candidate-address is an IP Addre= ss.

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000f71ef00580da00c6-- From nobody Fri Feb 1 11:39:19 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FDA1312C2 for ; Fri, 1 Feb 2019 11:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPkF5f2Ku7HU for ; Fri, 1 Feb 2019 11:39:13 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 4ABC51312BC for ; Fri, 1 Feb 2019 11:39:13 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id b5so11526033iti.2 for ; Fri, 01 Feb 2019 11:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xcHBuDlh3EaXWoDoQmxZGhJzH/B1FkmLsOZnDiinlzA=; b=JWD8w/vnlAl1mq5fm18raSjveDSjArWqukzE9aNjfmaExr9wQnI30liSDWLQukzyXu p+js2c8FapOMdsE7mf5TeRrlbaS/tg7MAIxVI68mruQDhgPZcrKwHmdztoOj6iolG/RN gnhcp6C/iZEPLD2MT4SGBR6HaRITdmAgZAF1QMo9jD+UNBsDkAvkH6/MLpxVzAIWP+pz NoQdEJE4OEWiT7OjTyqIjTmfQWu3RHDNTlXpRvtyo8s2jtqWeHpnqvrXygD/vOLRjfdF qBpnTHsuxmR31Sn+2hc05xJe5uuqo52scH2AJ+s0QU4LCvfhuE1YFqf7F4l8a29U7IQf uliw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xcHBuDlh3EaXWoDoQmxZGhJzH/B1FkmLsOZnDiinlzA=; b=e1cyvAEod1lu4nXYhJkcqEx7/GVDncIuEMjtkGk3M/0WtoepO9pLfSfkzXgmpI5oON URI7uBD29KFMpsXGqrzOf7wMPLTztEQHSSbBqNFGHf2c3tK1agngB++zYCvllrbfnC0I CFb59fZW7Y8Y99sUge+S6+Tu0q5P3ozH3yO1x6K6Txk1H+eYyGzZDKvbEfKQhWOlzhL1 7VkCMMqHA6YYf5ambhCGEYtK+3k6zjWQsLflCoDmkjvC3LZ99T1TJbJkrbu4QH7RF3Y0 goTbd1S7QuA7iTHrs/LJFjFzEWVJNFKfo0OqqJ29rdjA+KUZULmszdOTqZxLMyYKz12V Gx3A== X-Gm-Message-State: AJcUukd2EW9OXZb5+o7gsfWTpQ0SDQ3ziROXCivxmZtqF0Uub6yfnMJF HJiEd17bRn/JlrMN3rZNut80nozBY2I/F1abN1KlvxI4+dM= X-Google-Smtp-Source: ALg8bN4SUTNQTegwlDqtK/xlWF9ST6S2irLSHYUmeWoDH/TSNHpfJ8Dwb2RJj9JY7R0GaJiRUYxYu0kalmAZlxONFmw= X-Received: by 2002:a02:94eb:: with SMTP id x98mr25051601jah.88.1549049952060; Fri, 01 Feb 2019 11:39:12 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Justin Uberti Date: Fri, 1 Feb 2019 11:39:00 -0800 Message-ID: To: Roman Shpount Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG , Simon Perreault Content-Type: multipart/alternative; boundary="000000000000224ef80580da4c45" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 19:39:17 -0000 --000000000000224ef80580da4c45 Content-Type: text/plain; charset="UTF-8" This has all been discussed at length in rtcweb and I don't think any significant changes are needed, although I tend to think that we should restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only thing not in alignment at this point in time. On Fri, Feb 1, 2019 at 11:18 AM Roman Shpount wrote: > Most likely mDNS draft will need to update RFC 8445 to specify how ICE > nomination procedures are modified, when mDNS is used as candidate-address. > > As far as mmusic-ice-sip-sdp is concerned, one option would be to allow > FQDN as candidate-address. The guidance for handling FQDN in > candidate-address should be updated from RFC 5245 and should specify that > FQDN names should be ignored. mDNS ICE draft then will update ice-sip-sdp > and specify that mDNS FQDN should be handled according the procedures of > this draft. > > Another option, which I think word work better with existing > specifications is to add a new candidate type -- mdns. This way, instead of > magic DNS suffix, candidate type will be used to determine that this > candidate should be handled differently. I do not think MDNS candidates can > be used for anything except host candidates, so making then a special > candidate type might be the least painful option. It might even make sense > to make separate types for IPv4 and IPv6 MDNS candidates which would save a > DNS query for each candidate. > > Regards, > _____________ > Roman Shpount > > > On Fri, Feb 1, 2019 at 12:39 PM Justin Uberti wrote: > >> I understand there were questions about the general case (e.g. regular >> DNS names), but how do we plan to reconcile this removal with the need for >> mDNS hostnames? >> >> On Fri, Feb 1, 2019 at 9:09 AM Roman Shpount wrote: >> >>> Hi Justin, >>> >>> I agree regarding #1 in theory, even though in practice a lot of (most) >>> devices will not accept FQDN in either c= or ICE candidate. >>> >>> Regarding #2, mmusic-ice-sip-sdp was updated ( >>> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-4.1 >>> ): >>> >>> : is taken from RFC 4566 [RFC4566 ]. It is the >>> IP address of the candidate. When parsing this field, an agent >>> can differentiate an IPv4 address and an IPv6 address by presence >>> of a colon in its value -- the presence of a colon indicates IPv6. >>> An agent MUST ignore candidate lines that include candidates with >>> IP address versions that are not supported or recognized. >>> >>> >>> Specifically, support for FQDN names there was removed due to RFC 8445 >>> implementation issues. I believe Simon Perreault suggested this change. >>> >>> Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Fri, Feb 1, 2019 at 12:02 AM Justin Uberti >>> wrote: >>> >>>> My recommendation here would be that we do c=IN IP6 >>>> 3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6 >>>> depending on which type of address is being wrapped. >>>> >>>> Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for >>>> FQDN in the c= line. >>>> >>>> unicast-address = IP4-address / IP6-address / FQDN / extn-addr >>>> >>>> >>>> Re #2: Quoth 5245 : >>>> >>>> : is taken from RFC 4566 [RFC4566 ]. It is the >>>> IP address of the candidate, allowing for IPv4 addresses, IPv6 >>>> addresses, and *fully qualified domain names (FQDNs).* When parsing >>>> this field, an agent can differentiate an IPv4 address and an IPv6 >>>> >>>> address by presence of a colon in its value - the presence of a >>>> colon indicates IPv6. An agent MUST ignore candidate lines that >>>> include candidates with IP address versions that are not supported >>>> or recognized. An IP address SHOULD be used, but an FQDN MAY be >>>> used in place of an IP address. In that case, when receiving an >>>> offer or answer containing an FQDN in an a=candidate attribute, >>>> the FQDN is looked up in the DNS first using an AAAA record >>>> (assuming the agent supports IPv6), and if no result is found or >>>> the agent only supports IPv4, using an A. If the DNS query >>>> returns more than one IP address, one is chosen, and then used for >>>> the remainder of ICE processing. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount >>>> wrote: >>>> >>>>> On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti >>>>> wrote: >>>>> >>>>>> We can however all agree that "c=IN IP6" is busted: >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=927309 >>>>>> >>>>>>> >>>>>>>> >>>>> I guess one way to interpret this that each address should have a MDNS >>>>> alias. So, if you are dealing with dual stack host, it should provide two >>>>> MDNS candidates, one of which is IPv4 and another IPv6. The c= line should >>>>> specify FQDN for one of those candidates and specify the type (IP4 or IP6). >>>>> >>>>> There are two problems: >>>>> >>>>> 1. There is no way to know which address type is in the >>>>> candidate-address when FQDN is used there. Guidance in ice-sip-sdp is >>>>> talking about the presence of column in IP6 address, but this definitely >>>>> does not apply to FQDN. It would've been better to specify something like >>>>> local4 and local6 as FQDN suffix in MDNS alias to specify the >>>>> candidate-address type so that correct DNS request can be issued. >>>>> >>>>> 2. A lot (if not most) SDP/ICE implementations do no support parsing >>>>> FQDN in candidate-address or c= line. This might create interop problems >>>>> since RFC 5245 specified that candidate-address is an IP Address. >>>>> >>>>> Regards, >>>>> _____________ >>>>> Roman Shpount >>>>> >>>>> >>>> --000000000000224ef80580da4c45 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This has all been discussed at length in rtcweb and I don&= #39;t think any significant changes are needed, although I tend to think th= at we should restore the removed FQDN text from mmusic-ice-sip-sdp, which i= s the only thing not in alignment at this point in time.



On Fri, Feb 1, 2019 at 11:18 AM Roman Shpount <roman@telurix.com> wrote:
M= ost likely mDNS draft will need to update = RFC 8445=C2=A0to specify how ICE nomination procedures are modified,= when mDNS is used as candidate-address.=C2=A0

As far as mmusic-ice-sip-sdp is concerned, one option = would be to allow FQDN as candidate-address. The guidance for handling FQDN= in candidate-address should be updated from RFC 5245 and should specify th= at FQDN names should be ignored. mDNS ICE draft then will update ice-sip-sd= p and specify that mDNS FQDN should be handled according the procedures of = this draft.

Another option= , which I think word work better with existing specifications is to add a n= ew candidate type -- mdns. This way, instead of magic DNS suffix, candidate= type will be used to determine that this candidate should be handled diffe= rently. I do not think MDNS candidates can be used for anything except host= candidates, so making then a special candidate type might be the least pai= nful option. It might even make sense to make separate types for IPv4 and I= Pv6 MDNS candidates which would save a DNS query for each candidate.
<= div dir=3D"ltr">
Regards,
<= div dir=3D"ltr" class=3D"gmail-m_8846655286234283596gmail_signature">______= _______
Roman Shpount


On Fri, Feb 1, 2019 at 12:39 PM Jus= tin Uberti <jube= rti@google.com> wrote:
I understand there were questions about the = general case (e.g. regular DNS names), but how do we plan to reconcile this= removal with the need for mDNS hostnames?

On Fri, Feb 1, 2019 at 9:09 AM Ro= man Shpount <roma= n@telurix.com> wrote:
Hi Justin,<= div>
I agree regarding #1 in theory, even though in practice = a lot of (most) devices will not accept FQDN in either c=3D or ICE candidat= e.

Regarding #2, mmusic-ice-sip-sdp was updated (<= a href=3D"https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#sect= ion-4.1" target=3D"_blank">https://tools.ietf.org/html/draft-ietf-mmusic-ic= e-sip-sdp-24#section-4.1):

   <connection-address>:  is=
 taken from RFC 4566 [RFC4566=
].  It is the
      IP address of the candidate.  When parsing this field, an agent
      can differentiate an IPv4 address and an IPv6 address by presence
      of a colon in its value -- the presence of a colon indicates IPv6.
      An agent MUST ignore candidate lines that include candidates with
      IP address versions that are not supported or recognized.

Specificall= y, support for FQDN names there was removed due to=C2=A0RFC 8445 implementation issues. I believe=C2=A0Simon Perreault suggested this change.

Regards= ,
_______= ______
Roman Shpount


On Fri, Feb 1, 201= 9 at 12:02 AM Justin Uberti <juberti@google.com> wrote:
My = recommendation here would be that we do c=3DIN IP6 3557773f-5f01-46a4-aa14-= 54ab35b3d778.local, with either IP4 or IP6 depending on which type of addre= ss is being wrapped.

Re #1:=C2=A0RFC 4566 seems to= indicate you can use either IP4 or IP6 for FQDN in the c=3D line.

     unicast-address =3D     IP4-address / IP6=
-address / FQDN / extn-addr

Re #2: Quoth 5245:

<connection-address>: is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When par= sing this field, an agent can differentiate an IPv4 address and an IPv6 
      address by presence of a colon in its value - the p=
resence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.







=

On Thu, Jan 31, 2019 at 8:43 PM Roman Shpount <roman@telurix.com> wrote:
On Thu, Jan 31, 2019 at 10:58 PM Justin Uberti <juberti@google.com>= wrote:
We can however all agree that "c=3DIN IP6" is busted:=C2= =A0https://bugs.chromium.org/p/chromium/issues/detail?id= =3D927309


I guess one way to interpret this that e= ach address should have a MDNS alias. So, if you are dealing with dual stac= k host, it should provide two MDNS candidates, one of which is IPv4 and ano= ther IPv6. The c=3D line should specify FQDN for one of those candidates an= d specify the type (IP4 or IP6).

There are two pro= blems:

1. There is no way to know which address ty= pe is in the candidate-address when FQDN is used there. Guidance in ice-sip= -sdp is talking about the presence of column in IP6 address, but this defin= itely does not apply to FQDN. It would've been better to specify someth= ing like local4 and local6 as FQDN suffix in MDNS alias to specify the cand= idate-address type so that correct DNS request can be issued.
2. A lot (if not most) SDP/ICE implementations do no support pa= rsing FQDN in candidate-address or c=3D line. This might create interop pro= blems since RFC 5245 specified that candidate-address is an IP Address.

Regards,
_____________
Roman Shpount
=C2=A0
<= /div>
--000000000000224ef80580da4c45-- From nobody Fri Feb 1 11:58:48 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408A5128B01 for ; Fri, 1 Feb 2019 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=OOlQ1A1X; dkim=pass (1024-bit key) header.d=ericsson.com header.b=PlgKUAmF 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 W26RfKWh8H9Q for ; Fri, 1 Feb 2019 11:58:41 -0800 (PST) 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 52B51130E88 for ; Fri, 1 Feb 2019 11:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549051117; x=1551643117; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=J3o/pbjF5l516ONCZLveyTI7s85W/Wo1GCrOx6Um6Jw=; b=OOlQ1A1XjaZAs7R5C1sjZ0OyojvR1EpCJ9JWHQqLenLpsGx3GXDSaBwWmXrMemmS owwCGV1lTC19veE80id7mz0l8zz/m8Pw0tl3s7HJqJxNPda7ai3JSCTNeuJYXANi ouCv5/JwmrjxzZHMIajdycE8AOwXBSpYoTce83pg3yc=; X-AuditID: c1b4fb3a-5c9c29e00000672c-29-5c54a4ed7c99 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.14.26412.DE4A45C5; Fri, 1 Feb 2019 20:58:37 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Feb 2019 20:58:37 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Feb 2019 20:58:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J3o/pbjF5l516ONCZLveyTI7s85W/Wo1GCrOx6Um6Jw=; b=PlgKUAmFDSStjmne8Z9h8QV5Ght34ahUkQYnHv8tRDup1GFdmhtcrMywmzZHAfEQ4Vdvt8fUMnqIjekJymgz+VsPd10C1Y8wA55IRiOvUZhGudvG9BKmaKXbgoTGluSp6gyROYdYe47lA/MnUiGMtbv07q9e+rExqun/Q2s4WWg= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4233.eurprd07.prod.outlook.com (20.176.166.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.14; Fri, 1 Feb 2019 19:58:35 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.013; Fri, 1 Feb 2019 19:58:35 +0000 From: Christer Holmberg To: Roman Shpount , Justin Uberti CC: Simon Perreault , "Dale R. Worley" , RTCWeb IETF , mmusic WG Thread-Topic: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? Thread-Index: AQHUulU2uFx8SsiiZk68wi8iILBKkKXLUQeAgAAK5Co= Date: Fri, 1 Feb 2019 19:58:35 +0000 Message-ID: References: <874l9ousuk.fsf@hobgoblin.ariadne.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.136.56.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4233; 6:kukI0wDWCyB7D0HRwoC1oPBDsrzWf4iEXcdc5D+o6QpWn2YCF0RyJeq9F0yoxiUW9wGWdO1TVHd0O8t869YsX1NsRSqBq2Uk4V7twEdNgCm+3rSea8iF9yQSDW5YVgt+c+suNoRf0r+dn3pPQ29eDTLcm/oUQX+bJMskOA+oO7CRuAFZbgTn7a4DIasQe1ZeSzKmljzToNj0IMP7YQGpcqTBtWaeKn6MH2s/ToMaSTnTfsebvMU1qCZ6ufRUiYhIV1z9I7+9EUTzaR+7rNaJMRTggCSmCICug1gswF+g+XvfpH3KXQ7i3U31D6pHIGz4xEhs8iI/nbEdZ9N8ZZDKvMo1cEJx99r07aw0k7nGlD1cYqhtSGfAi5m97ZJH4ouhz0nLEPIGBTnc0Dk7Q5VWXdLAeFMC6uH7CMYDgeByZH8fPwNJhTTyonKi0oPZvT/8iZ4TMW99zOV64hmhWUr4Zg==; 5:dvuO94EIdYcZk8BDz5wXWVr544noQZlafkIe7JIDfPd7ULTbODTtJrmppnnNiexDojVUYB0UUiuhNobugPj/QfsYFmapKByhiU3co0ipGgWQSZh27DBXQC5bHe5YXczxG0lLt9qf9p24B6C4uTaCnwwbiCFYaSeRfojcfQUrDCtVv7LnWC97ojBdj2WDhbVg8X72YtuaJzGMpcyPIcUQaQ==; 7:uupugpHlMbMnb1ZMnc58LySI5Sdq7VPJjANwmDV/VLIO8JfgRzFcWhHkkcdLDrHsr6ckoRfUhxHz1WvHwXNawzOa2I2s1pweDi1+WgzRQm9cd9Yrwr0kw8xQsQ05kdKyXxE1E8lTd1GiISFBxXcoAQ== x-ms-office365-filtering-correlation-id: 4a6ecbc3-7be1-4c50-ca3b-08d6887fa6b0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4233; x-ms-traffictypediagnostic: HE1PR07MB4233: x-microsoft-antispam-prvs: x-forefront-prvs: 09352FD734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(366004)(136003)(39860400002)(189003)(199004)(476003)(558084003)(6246003)(7736002)(26005)(74316002)(2906002)(53936002)(99286004)(486006)(186003)(102836004)(68736007)(86362001)(6606003)(316002)(71190400001)(110136005)(8936002)(8676002)(81156014)(7696005)(446003)(81166006)(11346002)(19627405001)(44832011)(71200400001)(54906003)(66066001)(6506007)(76176011)(256004)(97736004)(54896002)(105586002)(14444005)(106356001)(33656002)(9686003)(55016002)(4326008)(14454004)(25786009)(6436002)(3846002)(6116002)(478600001)(93886005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4233; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cJ5E2jgRFvbf2mONq2n31HGFgQY2DReQ4mwvcp93bSWS+bCPVK9XAWNg0NiGnFDtF6cY8FQRFyjLLrlSbAsx9xGfqnHMZ1qO9deOMVeJjVB5Pz/x7cQPokb7f+f058SjnwfjrxSLF9GAzoi+UzjVtJx5Pp2Uw8b7QgpGDg2LlGl930y9beUEnh94uj5Wn0SwiK4ep1rNNNHopuS+0dM9s5ExOWqkuJ149NL73UOfAlYpEbcKeUiF2oMEz6yFENBb2IlUkWl96Do1iroKbKKB5KemeJdj7IeE+SnNkqUcz183JhnaCFjM2TmynJWfWgMuEju9LY1Y56kaEc2eUIrnXppU3Ow9PXN7knt+WTWWADrFI6NmhoBggAiiKSRdOax9N9vk7f1XraDvw/FqF35DAeoRuVmwkHmH0WoqF3XzhZo= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161471773206C16258150E493920HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4a6ecbc3-7be1-4c50-ca3b-08d6887fa6b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2019 19:58:35.6650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4233 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+845247S4tu8vXjpMiLIW2oJy0LKImaQJmhFDGrkSc3b2FHJ /pLKigk1UVPX0kRTFLUUQ8H7jFymqKFpoqJ5y6ykVPKSx9zOAv/7Pc/zvt/7vvDRpPSDwJmO SUhiNAmqOJnQlsq/Us96/SgJV/pUTnjK3+RI5TllU5Q8ry+HlFdxD0XyoYEI+bwp5ZRQkdW6 Qipe1CYrSkrWCAVnmCEVI9nqi4KrticjmbiYFEZzJPC6bXRzm55QZzrcNm0NkWmoW6pFNjTg Y2Do6BRqkS0txW8RPDYZrGIFQefWKsmLYgKGTWkWQWEdCZNT1dayLALaNloIXkwi4PSzSIto WojlkMF5mIfY42D4vlZs6SaxDkFXfQsyB3Y4DtZn9SRfFA81Tz5ZOQC6ezcsTOGDUF6gFZpZ jJUwkPvVOvmVACrXtIQ5sMFhsPBIZ2lA2BH+dFVafBI7wch0IcGfiqGkqZfk2QHmpzgBX6+C 1ooJq78fOsenEc9u8LEwA5mHAb4rgtnFaSEfXIAxrpfgg88IXg8bKD5wB11Tg/WlWCi+12ht cIWG1TER3zAngH79imUlKWagrCod6ZCnfse2PCdCUfUE0lvOlsD7/GmK971hOCdbyLMHlBYt kDx7QR5npHb6L5CoAjmwDMvGR/n5eTOamBssm5jgncAk1aLtL9ZetxHQgNrnThsRppFst/h4 VrhSKlClsKnxRgQ0KbMXB93atsSRqtQ7jCbxmiY5jmGNyIWmZE7iv1KJUoqjVElMLMOoGc3/ lKBtnNOQa83PhpfP60LnlHYd+0K4hVx/iYjzkeytcJlp/L30bCikx3+5LEI8ITyq3rN5Ymr0 zPkCf8lg4HLGgXeGkaXSgc30B/mbN4M6ahzvfxsL9j0XVt7mf7b7cFNov6HwV0TmF/e0S83G XbmXF0fHI3pzW7bGetZj+rRINUg/PeSmTjbJKDZa5etOaljVPyJ1qoJeAwAA Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 19:58:42 -0000 --_000_HE1PR07MB3161471773206C16258150E493920HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, > Most likely mDNS draft will need to update RFC > 8445 to specify how ICE nomination procedures are > modified, when mDNS is used as candidate- > address. What part of 8445 would need to be updated? Regards, Christer --_000_HE1PR07MB3161471773206C16258150E493920HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

> Most likely mDNS draft will need to update RFC 
> 8445 to = specify how ICE nomination procedures are
> modified, when mDNS is used as candidate-
> address. 

What part of 8445 would need to be updated?

Regards,

Christer
--_000_HE1PR07MB3161471773206C16258150E493920HE1PR07MB3161eurp_-- From nobody Fri Feb 1 12:09:26 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3E130E89 for ; Fri, 1 Feb 2019 12:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HWTHu72l_AAR for ; Fri, 1 Feb 2019 12:09:16 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 D6981130E84 for ; Fri, 1 Feb 2019 12:09:16 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id y1so3743723plp.9 for ; Fri, 01 Feb 2019 12:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NjeNGy85lYMwb0k0Fdoc9bqfM9ku9gfQVC041YICdr8=; b=yPklsQXH3feVNejAS3Pzy+Zgn6UNx74ce6DayhFRZDw+SbZxCace34Da4jy/+XI2GG mw/97FwCgfTjmlfUqOGGVa06S9KF7vWzfM/cQApBLEQobqpsMBcc3UFjsC8kG2dGx3f7 18Fk3ZpUfTsVv171IMMgr0phwzdouan5Ba5JYUTrJPXtznsKl6xLEzot9gnAhKP2L949 Lr7JuoDHUtU7d+UdXSVBqiSsqMw4QzmT++CSP77TIXDLe8lKqgnWv6qAAGlE7Zp5BfNG YZQJmrGC7t1O9/wx/Y/uNOyv6ftFLyO6MmpZu2Bp3dqoSvJfAAn51Sh98hyZNb/wHkkt 38cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NjeNGy85lYMwb0k0Fdoc9bqfM9ku9gfQVC041YICdr8=; b=aiFA3WaidhPhVBSml0URnBI+xo/t9DyjVYHwKeTi/S1ZRJ+FU5hQSfdA35l8QwDYN3 OK7HPJ3lb2mnPM8xGsplcV8bfOI+wSjsbr0WK6iQs58INo+WLV5lAveYZ79LbfGbpu4U wSossh3WTjJJl0qn4k0xdKWzc4qTYSWCqjsV/2K1ZGf2pIYeTHgkpGMCg6Sa5ejOah2q KnSQFl2dD+sXv+63wmM7I7o+hQfEm+FxLDkCfuSgTIbBVs/mqGFnidbkivo+AtnA7N0j SYLts1jSmeK4SKR4BEirKY9WiyUfpIMGQKoCxXURZCU7LhCtMx+kANdgEKlDfwzpGjam R2Ew== X-Gm-Message-State: AJcUukcWVi2ilp8xvUlnhgjfCyg5J62ZTWniAsbcsUfKH0q/Mv19K/mb 7YWVZk7NVNM3y2IG1JB9nGf9FqnMIvM= X-Google-Smtp-Source: ALg8bN7jP+UF/+sEYfZLQ7kPxDKg7ORNB0l9e+I/DriHDRYSFiavIkTB3wZ5uAk9Zyo1DA2E480RYw== X-Received: by 2002:a17:902:3283:: with SMTP id z3mr41613044plb.76.1549051756275; Fri, 01 Feb 2019 12:09:16 -0800 (PST) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com. [209.85.215.177]) by smtp.gmail.com with ESMTPSA id g26sm10281362pfh.61.2019.02.01.12.09.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 12:09:15 -0800 (PST) Received: by mail-pg1-f177.google.com with SMTP id t13so3414572pgr.11; Fri, 01 Feb 2019 12:09:15 -0800 (PST) X-Received: by 2002:a63:b4c:: with SMTP id a12mr3634101pgl.131.1549051755149; Fri, 01 Feb 2019 12:09:15 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Fri, 1 Feb 2019 15:09:05 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Justin Uberti , Simon Perreault , "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000009ac2140580dab76f" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 20:09:20 -0000 --0000000000009ac2140580dab76f Content-Type: text/plain; charset="UTF-8" On Fri, Feb 1, 2019 at 2:58 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Most likely mDNS draft will need to update RFC > > 8445 to specify how ICE nomination procedures are > > modified, when mDNS is used as candidate- > > address. > > What part of 8445 would need to be updated? > > Currently RFC 8445 specifies that candidates are only IP addresses and not an FQDN: 2.1. Gathering Candidates In order to execute ICE, an ICE agent identifies and gathers one or more address candidates. A candidate has a transport address -- a combination of IP address and port for a particular transport protocol (with only UDP specified here). There are different types of candidates; some are derived from physical or logical network interfaces, and others are discoverable via STUN and TURN. In case of mDNS, candidate is a FQDN name. So when gathering candidates, DNS query will need to be performed and its result added to the candidate list. Also, I am not 100% sure, but I think mDNS can resolve to either IPv4/IPv6 or both addresses. So, single mDNS candidate can result in two actual ICE candidates. All of this looks like RFC 8445 update. Regards, _____________ Roman Shpount --0000000000009ac2140580dab76f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 1, 2019 at 2:58 PM Ch= rister Holmberg <chris= ter.holmberg@ericsson.com> wrote:

> Most likely mDNS draft will need to update RFC=C2=A0

> 8445=C2=A0to = specify how ICE nomination procedures are
> modified, when mDNS is used as candidate-
> address.=C2=A0

What part of 8445 would need to be updated?

=
Currently RFC 8445 specifies that candidates are only IP add= resses and not=C2=A0an FQDN:
<= div>
=C2=A0 = =C2=A02.1.=C2=A0 Gathering Candidates
=
=C2=A0 =C2= =A0In order to execute ICE, an ICE agent identifies and gathers one or
=C2=A0 = =C2=A0more address candidates.=C2=A0 A candidate has a transport address --= a
= =C2=A0 =C2=A0combination of IP address and port for a particular transport<= /span>
=C2= =A0 =C2=A0protocol (with only UDP specified here).=C2=A0 There are differen= t types
=C2=A0 =C2=A0of candidates; some are derived from physical or logical ne= twork
=C2=A0 =C2=A0interfaces, and others are discoverable via STUN and TURN.=C2=A0=C2=A0

In case of mDNS, candidate is a FQDN name. So when gatheri= ng candidates, DNS query will need to be performed and its result added to = the candidate list. Also, I am not 100% sure, but I think mDNS can resolve = to either IPv4/IPv6 or both addresses. So, single mDNS candidate can result= in two actual ICE candidates. All of this looks like RFC 8445 update.

Regards,_____________
Roman Shpount
=C2=A0
--0000000000009ac2140580dab76f-- From nobody Fri Feb 1 12:22:32 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204F7130E84 for ; Fri, 1 Feb 2019 12:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2quyvbQGta15 for ; Fri, 1 Feb 2019 12:22:28 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 D86E7130E6A for ; Fri, 1 Feb 2019 12:22:27 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id t13so3429614pgr.11 for ; Fri, 01 Feb 2019 12:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZxiszQvP8ZFDDvqn+Bf1lIlGwm+vjhJUim4CvEgEaHQ=; b=P6UXgvFmxnhUSbYRiOimooOaR7ScKbVThYvHTEQ8rvCzm2DbLVxg7Wkjda9Mtxnoqp oTjCBJcnBEBqCQNl3IdzICTyJk3Dvk3Cqrg42O4BRrgxD00dQb9iFS7xZmgT7ZwqCDRr 2Ron1C0Smmx0aoeUWRH1sVsPh4xrRlSf2VlnbMyzHGSXmyr5J8ah6EqyyiVmhDoB39CT v4v6y5+CGogOOHG69VD4qwwRGkC6Uy7vQSw4u+k3/i/dn3dcXWpNwWFPfPDQuLjQM9QX xP+B6sgC6DQbYNQtq+S/PJVOSUZLXWamRqTqkEGcROf4QvgUptDceiQgH7xrcCTxolxI NTJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZxiszQvP8ZFDDvqn+Bf1lIlGwm+vjhJUim4CvEgEaHQ=; b=Ap7lMFkVUWUisEi1Qp+itQwREsZuEIiWI3lstdv+us+qKEkAcdGZ0y0892gwhJ7fZ4 D0204uqAiDrmCNoA7ZVzAUqdGS75NczqHcFh+1vfnhfcoVR9atVQYg/e4uvYM4MX3CEM ZzJbHSzKslpVHJIglw8NBpS9zaVV0xHNJLcATe0DcsioCTkx/o75u6C9yKis/O7GCzfi zcTyLZRs1iGFsnMJsCKszpggZaLk2nMeT0IRpjGyQ7XwIcafVo4CnJKFaw2piPwW7y3z GfbjanfSY5DOSWqi1JeuYdVDF7jkclenzkOnBXphKSx5wmI7nV38p4M/KbBX56oMMMy/ F6Ew== X-Gm-Message-State: AJcUukcDimdXs8sz0Hruq6wpbU9DcF61OyZ0Umz2lqhbyS62B19aT0gd 1uL/k/ErBwQcwRn+qEvd40nEF1AA1pc= X-Google-Smtp-Source: ALg8bN5hpoGCwNe0h9Fsle3nr2V7nrqY64s6o6KVRM23P0HC7lRWDSPpQjfvf+bZ2kMIaetHnK6hsQ== X-Received: by 2002:a63:1f1c:: with SMTP id f28mr37082470pgf.193.1549052547104; Fri, 01 Feb 2019 12:22:27 -0800 (PST) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com. [209.85.215.172]) by smtp.gmail.com with ESMTPSA id c13sm10673219pfo.121.2019.02.01.12.22.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 12:22:26 -0800 (PST) Received: by mail-pg1-f172.google.com with SMTP id z11so3458617pgu.0; Fri, 01 Feb 2019 12:22:26 -0800 (PST) X-Received: by 2002:a63:b4c:: with SMTP id a12mr3678195pgl.131.1549052545848; Fri, 01 Feb 2019 12:22:25 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Fri, 1 Feb 2019 15:22:15 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: "Dale R. Worley" , RTCWeb IETF , mmusic WG , Simon Perreault Content-Type: multipart/alternative; boundary="000000000000bbdaa90580dae688" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 20:22:30 -0000 --000000000000bbdaa90580dae688 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti wrote: > This has all been discussed at length in rtcweb and I don't think any > significant changes are needed, although I tend to think that we should > restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only > thing not in alignment at this point in time. > I agree that FQDN should be put back into connection-address definition, but the portion which talks about handling it is completely broken. Quoting 5245 : : is taken from RFC 4566 [RFC4566 ]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and *fully qualified domain names (FQDNs).* When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing. I think it was discussed in quite a detail why using a random DNS resolution result is not going to work here. The only options we have here are: a. Fix FQDN connection address handling. Probably the most logical way of dealing with this would be to specify that candidate with FQDN should be converted as a result of DNS resolution into multiple candidates, with each candidate corresponding to A or AAAA record in DNS query result. We will also need to specify how FQDN candidate gets applied to c= line address. Something that says IN IP4 FQDN, if any A records exist for this DNS name and IN IP6 FQDN if only AAAA records exist. Once candidate is nominated, address family in c= line should match address family used for communications. This will definitely require a lot more work and discussion. b. Specify that FQDN connection addresses should be ignored until their handling is defined in a future specification. This seems easy and only requires a sentence or two to fix. Regards, _____________ Roman Shpount > --000000000000bbdaa90580dae688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 1, 2019 at 2:39 PM Ju= stin Uberti <juberti@google.com> wrote:


Quoting=C2=A05245:
= 
   <connection-address>:  is=
 taken from RFC 4566 [RFC4566=
].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When par=
sing
      this field, an agent can differentiate an IPv4 address and an IPv6

      address by presence of a colon in its =
value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.

I think it was discussed in quite = a detail why using a random DNS resolution result is not going to work here= .

The only options we have h= ere are:

a. Fix FQDN connect= ion address handling. Probably the most logical way of dealing with this wo= uld be to specify that candidate with FQDN should be converted as a result = of DNS resolution into multiple candidates, with each candidate correspondi= ng to A or AAAA record in DNS query result. We will also need to specify ho= w FQDN candidate gets applied to c=3D line address. Something that says IN = IP4 FQDN, if any A records exist for this DNS name and IN IP6 FQDN if only = AAAA records exist. Once candidate is nominated, address family in c=3D lin= e should match address family used for communications. This will definitely= require a lot more work and discussion.

b. Specify that FQDN connection addresses should be ignored un= til their handling is defined in a future specification. This seems easy an= d only requires a sentence or two to fix.

Regards,
_____________
Roman Shpount
--000000000000bbdaa90580dae688-- From nobody Fri Feb 1 12:27:43 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7B4130E96 for ; Fri, 1 Feb 2019 12:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=K+oG7krw; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VQsqxFjE 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 EdSrZvu4Nqw5 for ; Fri, 1 Feb 2019 12:27:35 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE35130E84 for ; Fri, 1 Feb 2019 12:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549052851; x=1551644851; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=X7YMOSKglwjZWwdZjCIG9hOm/umU/mz5TU3WUTNV7Ug=; b=K+oG7krwG+kEiIjDICFkM/nPTUrriyL6NL2umubWM6arYkbrfm9zcPmw0BcATK20 mH/pHg2CVxaG5YyHc+eKHNykz0VMYdnivKllJABr5N/ACKZBia2AhOJqp7VZ2fCI EN9s+u47517TJ/zHrI9+PVSpgSeE51Hc0BVzT/VIxgQ=; X-AuditID: c1b4fb2d-d9dff7000000062f-8f-5c54abb3e28e Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6C.D6.01583.3BBA45C5; Fri, 1 Feb 2019 21:27:31 +0100 (CET) Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESBMB502.ericsson.se (153.88.183.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Feb 2019 21:27:30 +0100 Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Feb 2019 21:27:30 +0100 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Feb 2019 21:27:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X7YMOSKglwjZWwdZjCIG9hOm/umU/mz5TU3WUTNV7Ug=; b=VQsqxFjEfDI7atawNeRDCWLFjimt7zlIirb6MutKKbaMRh2s/pXzy82bG4sZEYw3iECWbn+knDPA8AUwYopYPj8R6VSVKOEk1mKJCqD9jTsHFqBiPMJcRi9FI497QntxyT1mlKZ9+1xdAamucERsiFcmjxx5jtI+JDre5wcCh+s= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3308.eurprd07.prod.outlook.com (10.170.246.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.11; Fri, 1 Feb 2019 20:27:28 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.013; Fri, 1 Feb 2019 20:27:28 +0000 From: Christer Holmberg To: Roman Shpount CC: Justin Uberti , Simon Perreault , "Dale R. Worley" , RTCWeb IETF , "mmusic WG" Thread-Topic: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? Thread-Index: AQHUulU2uFx8SsiiZk68wi8iILBKkKXLUQeAgAAK5CqAAANhgIAAA0UT Date: Fri, 1 Feb 2019 20:27:28 +0000 Message-ID: References: <874l9ousuk.fsf@hobgoblin.ariadne.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.136.56.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3308; 6:TAIGx55XOKzdmSw/iZ1toN81X841wHCHWt49T+z0wjZu+EtBMvE5tZLlRmvo+Cy1dKN9iSoolmaRzgtrsF5svfE+Jmue4ZFtn2o9f2EaEW7RBwhy2/uQRVnXIMKMJzDANCsftPIjK6V8VKkQrLwcvDiY5PwTW1gEbybdRGOt6sz+MeeKrl/8U6ZbSAc9IrgwqizZJ1mR2lQJcfxgLm2D2Si/muyZZVVqZP6yyNJMpxtPFGAMxXOM9cmVhcb6Fmb2YCmT+/RHNZLMNP08mJ6K5+4mHP3S2mEj/uhXq9UMCFzoYwnhImDXjUwQSi9X9c3EhBSTLpOqZoV0Z9yi361Fj5bxpYbkN50YBhvUOFSYdp/tTxQyI0kOqs5RGXHDWmwvjnKzp2zuZhq1g/2UgjEqNmlbHVz+Tao869UP7IejsLma1n0SKMQ+KhHt0blKmDtSY1OxLXMMk8YOc/fJA6tpUQ==; 5:N5XZIjmIIRV6rOZEKpoxx+VROPkOpNeIGDBzKwYvg62lnlJ2uo5wMRg+8ukeNkemYx1qHbaZNVT1MmEKrTSMEmDcnFaVZUgmL+gCC5Xer86v8naq77xVgIjbqLhfSORYyk/Xp+M0EhiD7WLmGEAnoR+NSBOn+1Vdz0gEFB3pWWiMX3K4poFYryRLbTT3VlSU8uQfxP0wzeS0ncmGPcirLA==; 7:29CYj/YABg/iJIIclWZF/txJLhVSRvVNg3iMXxKX0ErkF8Es+UgXqqCmNdz1p/R1m0d0xm15IJVKR98SAF84xxhhtkJ5G2E3mk2inm7zOqn4LqkeRr3x1750EACh8CCLIyCusuWnJ1yJtJ6yvA7Qhg== x-ms-office365-filtering-correlation-id: 3d8a8843-bac4-45c5-1439-08d68883af42 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3308; x-ms-traffictypediagnostic: HE1PR07MB3308: x-microsoft-antispam-prvs: x-forefront-prvs: 09352FD734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(346002)(376002)(136003)(199004)(189003)(106356001)(26005)(93886005)(86362001)(105586002)(6916009)(186003)(6606003)(19627405001)(256004)(14444005)(54906003)(99286004)(2906002)(102836004)(316002)(7696005)(68736007)(6506007)(76176011)(9686003)(54896002)(55016002)(8676002)(6116002)(53936002)(3846002)(486006)(8936002)(478600001)(81156014)(7736002)(81166006)(6246003)(25786009)(4326008)(74316002)(6436002)(14454004)(66066001)(229853002)(476003)(71190400001)(33656002)(71200400001)(44832011)(11346002)(446003)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3308; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6rcPEo6t+ZWL3AkzVQoRpvBgN8rEK/JSRewhevhz+eaU+OuIEPKKm0oHEr/4iMNM0kKm86jhtgDs4dO+kWs45CoKAO6Z7dT7RKSX8GcEA2tHE3550LKfXL7UnnvemYRkyC0bCQPBWXrKhS4RgBtvsdV0lnQyxrAoBEh12R+tPKQ7cE0/smV+ahUzgWjw9fha8G+zzaGH1Bvn+rOT5x1S0s4zXTS+pLj2I7Fu3hCqLq9y5WF1+jeKd00NYjf3LLH/IVxxgZBU8pOWph1MmWVOQ4Iaxr+1JJaaMLNapP9xhdmlktAgH+sG0WlDJFMRW5xQ7AY1onuxdvXJ8qgSFmBqHbWs/lFWutXIL/1CxsVO3BH9q38aalyYiux16vp2+to8G2Gh/3jV0J789nKW1Yg25WY8oJupc3pVFGjNvNOdXjk= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161C0316B63EEE9C6B926DB93920HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3d8a8843-bac4-45c5-1439-08d68883af42 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2019 20:27:28.0739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3308 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01SfSyUcRzf757nnnvuuO3nkO9US7cwDJHpljJla7dWWzVK0XTjmbfD7R4s rZZYqqPYjkIZSrUdWo68bGTdWiJSKmISOcrIUvOScnL3qPnv8/28fF9++9GEpIPvSMclpTDq JIVSSonI4rBG1rOuKiRie4ZBJHtcKJEVPhgjZUWvCwlZjemyQNb/LlQ2+SItiJJr2+YIebk+ VV5Z+YsnN90eJ+SDBarD/JOi3dGMMi6NUXsHnhbFZi9r+aop3zO137S8DPTeQ4OENGA/qHmr RxokoiX4GYLs79f5XDGHoLm0mvpfjA9dQuaIBN/lwa16V7NA4nwCntxsFnAuLQ+GNV18zjWK oHzaRYNomsIyyDFZ5tlhZ1he0PLMfgI3IDD2ZPLMgi1WwtJECcGZEqE2r48wZ+3wftBPhJpp Em+DyY5hS3sxjoCW6rq1uR0UDI8OWbJCfAS6jC2UGSO8ARY6qy39CewAg8YyHnc0hsqWHoLD 9jA5ZuJzfgW06UbWeCdoHzYiDm+G3rIcyyMBzhTAQGsxxQmHoG5xkeKEAQSaotq1tDsMZY6t pRPgZ56O5PAmaFr8KOACg3zo/NpK5iPPknUbcjgZGnPekCWWU22go9hIcrwXfCgsoDjsAfcr pggOe0KRyUCu58uRQIfsWYZlE2N8d3gx6rgolk1O8kpiUvRo9YM9rf/t2YSqpvYaEKaR1FrM 6kIiJHxFGpueaEBAE1I78b74VUocrUg/y6iTI9WpSoY1oI00KXUQ/5HYREhwjCKFSWAYFaP+ p/JooWMGOuAfds6tX+Mnt4prCL+wZyn4VUWAW2/3sb4Rq1ln1bxbwaOVIcVMovWVLsGdhJCX ZTaDX8JdPo0GXivvFkayF5X3nn/uvnE8SxecO581TfzIPTHb3uVu2xe05WCkKnvnwxV//fl4 g3Zm6y7rmIJSGx9X+6uTpqMOUadueds5BQQIo6QkG6vwcSfUrOIvFouILVwDAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 20:27:39 -0000 --_000_HE1PR07MB3161C0316B63EEE9C6B926DB93920HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >>> Most likely mDNS draft will need to update RFC >>> 8445 to specify how ICE nomination procedures >>> are modified, when mD= NS is used as candidate- >>> address. >> >> What part of 8445 would need to be updated? > > Currently RFC 8445 specifies that candidates are > only IP addresses and not an FQDN: > > 2.1. Gathering Candidates > > In order to execute ICE, an ICE agent identifies and > gathers one or more address candidates. A > candidate has a transport address -- a combination > of IP address and port for a particular transport > protocol (with only UDP specified here). There are > different types of candidates; some are derived > from physical or logical network interfaces, and > others are discoverable via STUN and TURN. > > In case of mDNS, candidate is a FQDN name. So > when gathering candidates, DNS query will need to > be performed and its result added to the candidate > list. The 8445 text does not talk about encoding of candidates on the wire. A can= didate always has an IP address and port - and that is true no matter what = you signal in the SDP on the wire. > Also, I am not 100% sure, but I think mDNS can > resolve to either IPv4/IPv6 or both addresses. So, > single mDNS candidate can result in two actual ICE > candidates. All of this looks like RFC 8445 update. I raised this issue before, and I think the agreement was that, with ICE, m= DNS would only result in ONE address (either IPv4 OR IPv6). Regards, Christer --_000_HE1PR07MB3161C0316B63EEE9C6B926DB93920HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


>>> Most likely mDNS draft will need to update RFC 
>>> 8445 to s= pecify how ICE nomination procedures >>> are modified, when mDNS i= s used as candidate-
>>> address. 
>>
>> What part of 8445 wou= ld need to be updated?
>
> Currently RFC 8445 specifies that candidates are 
> only IP addresses and not a= n FQDN:
>
>   2.1.  Gathering Candidate= s
>
>   In order to execute ICE, an IC= E agent identifies and 
>   gathers one or more address candidates.  A =
>   candidate has a transport= address -- a combination
>   of IP address and port fo= r a particular transport
>   protocol (with only UDP specif= ied here).  There are 
>   different types of candidates; some are derived =
>   from physical or logical = network interfaces, and
>   others are discoverable v= ia STUN and TURN.  
>
> In case of mDNS, candidate is a FQDN name= . So 
> when gathering candidates, DNS query will= need to 
> be performed and its result added to the = candidate 
> list. 

The 8445 text does not talk about encoding of = candidates on the wire. A candidate always has an IP address and port - and= that is true no matter what you signal in the SDP on the wire.

> Also, I am not 100% sure, but I think mDN= S can 
> resolve to either IPv4/IPv6 or both addre= sses. So, 
> single mDNS candidate can result in two a= ctual ICE 
> candidates. All of this looks like RFC 84= 45 update.

I raised this issue before, and I think the ag= reement was that, with ICE, mDNS would only result in ONE address (either I= Pv4 OR IPv6).

Regards,

Christer
 
--_000_HE1PR07MB3161C0316B63EEE9C6B926DB93920HE1PR07MB3161eurp_-- From nobody Fri Feb 1 13:02:43 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649DC130E8F for ; Fri, 1 Feb 2019 13:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.852 X-Spam-Level: X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=WA173W+i; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZOo5YLOp 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 gx04N3tSsgV3 for ; Fri, 1 Feb 2019 13:02:20 -0800 (PST) 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 38D3B124408 for ; Fri, 1 Feb 2019 13:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549054935; x=1551646935; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Cvsp8+sM9hs4gTAJszW/mMnQbERQz0yXX3UJ0ZzdzDc=; b=WA173W+iYHi3Fkf8vM2PQTDNpkttg9u7Bm9spQ5HfhWbT7DkmJ/pPexyESZhM3Mu +/GUSY0+XyArBquDubEm5Gx6SnZc5Kult394HHzciJKGAtCTQMs2Y9h04dTHjMsK g28t26weniBKQZfuL2E/yr8tpaxIWFX9/42YubIDu68=; X-AuditID: c1b4fb3a-167ff7000000672c-14-5c54b3d77ffc Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C5.FA.26412.7D3B45C5; Fri, 1 Feb 2019 22:02:15 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Feb 2019 22:02:15 +0100 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Feb 2019 22:02:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cvsp8+sM9hs4gTAJszW/mMnQbERQz0yXX3UJ0ZzdzDc=; b=ZOo5YLOpOXHPv43LYM48uro4gmCHCes9r8jXJGS8UDCNzhbSziW3TEHss1DSa03jUpFY7AImEeQ7FHDDsI45PlSdpHXWcv+5PxFAT7hyJIvnoJRWFFzcfn4cOyaC2KhT00pMoCCSPxuE6KuNpm7cSjM27nzwvZ86FaXEaAVKPWg= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3082.eurprd07.prod.outlook.com (10.170.244.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.14; Fri, 1 Feb 2019 21:02:14 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.013; Fri, 1 Feb 2019 21:02:14 +0000 From: Christer Holmberg To: Roman Shpount , Justin Uberti CC: Simon Perreault , "Dale R. Worley" , RTCWeb IETF , mmusic WG Thread-Topic: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? Thread-Index: AQHUulU2uFx8SsiiZk68wi8iILBKkKXLUQeAgAAF3QCAAAwVgIAACK4A Date: Fri, 1 Feb 2019 21:02:14 +0000 Message-ID: References: <874l9ousuk.fsf@hobgoblin.ariadne.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.136.56.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3082; 6:gvHPX9xSCDlQm2cBGKliaxwp3FfqLiRIjsjOZILo/DlzIVNRdRmHFQ43qlMszyAFkQK6XX7cyIvnhzYMchh9ch/Tuif6fwEFoI35XJ/dfrs4BHmmFpibN+GUAX1BBSn428TWlZdZCJcyXz/tlF/N/a6eH3afqUjAxpffDeGFsSx5MuUMSEIMAlAJtFDQho4f0z9OFRngnSfOHNQvlwWdxageAAWM4ca1fJ1XZPbq9iXSGZ3N//Hy5Ee6ps4zMkf57wyxPbkipEQx/omhEFkHaYTGwwSLcnyLCnLXCP0DD4FZnvamCoCQCtbhlJGgATA0a0QmhMgi/Z11142qJfOPWRApyna3WQV8IQ6C3dz+rDjpD2NL2KIp8BtxBLhch2jmKc2hHjszLxF2us+ZUQT2wAcTwW5ISPoYr4d+wSbYlwBZw56lm7o63+5ksncUJqVD/5eZAbiC+92KpXm/4goaxw==; 5:OECNRopP2ffBFga51TKE/XpMp9N91FQD5m8D4yLQycWw4THBkD8nzliTfn/MIz3KAqszb9L/lDzYFBbfZ6ce/iss7VffOQmMet2uoabcFGfrxvcdam4x1nZ8oyvyzuwCoCdGZT5jnAxrnZTPHmqqagv0H04vMPaLKpMpwWNxmrUqsENIrLHUBs8vXS/DY5WJwBkP0I/xrpsBWPDvLY9gOg==; 7:nFs9j0LsCsGH6+w4CACp/JiBdVZym51YLP11R24ZsCj1saJo1au8bBfWVFMONiPM3yYWb5mXXcFbIJnQj5RusmANWwrOXynFmvd98cvHkv517LUbY3VPlVe/eOHlUjrYZByiEsFnVlN5SkS/wVpvAg== x-ms-office365-filtering-correlation-id: 5bed3c24-ae36-4975-7c13-08d688888aa4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3082; x-ms-traffictypediagnostic: HE1PR07MB3082: x-microsoft-antispam-prvs: x-forefront-prvs: 09352FD734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(346002)(376002)(396003)(199004)(189003)(8936002)(53936002)(93886005)(86362001)(99286004)(71190400001)(106356001)(71200400001)(1015004)(53546011)(14454004)(6506007)(236005)(6606003)(7736002)(74316002)(33656002)(229853002)(25786009)(68736007)(606006)(256004)(14444005)(76176011)(476003)(2906002)(446003)(6436002)(486006)(19627405001)(110136005)(26005)(54906003)(105586002)(102836004)(4326008)(44832011)(478600001)(11346002)(81156014)(7696005)(9686003)(55016002)(97736004)(8676002)(5070765005)(186003)(6246003)(81166006)(6306002)(66066001)(54896002)(316002)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3082; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dDQDtotYETEvYpjXnGUmogB2wnZ/abcAGzhoOIOfp1CX3m843KfvmFtL+EzQ6EflAvSCD6qhQJaRCI9py913rIVFgeQiXwTzeHAy7SGSFPKoO2UhKKN4YLB46MflN91n/AbxcKK7dSsVb2yzRcOtUFUH0OYaBN7pCeFt4+p0rO+G1/qg8Z0W2vWTV8qXTLcWBtzGHBwecfaMqw8/0BXPbW70uTLnvV2qUtacrPCulab3UE4rWeLPS2p42vbo7RRMF3t/vrs7E9zP0RW+8wcLVZAoGmnzDikCFvu8YNIRweC6ySv9og3ju6jz43lN1zzwrLECeUP5yQ81IsgpZR88WUlGA+znHMqLu6P90CAZk7NgN7Qv/pzgicuY+XEr/ENhH8mXYpyJ+QqL9/BTswcKxn/3fms1Jvq4mSQJZXSlg6A= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB31617DB79BE41B64AECF082693920HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5bed3c24-ae36-4975-7c13-08d688888aa4 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2019 21:02:14.1378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3082 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGOfu+ffscDo7L5ZsV1pAwb5UVTI2woFh/SBcMpCY68kNtF2Wf WgmVWVIY4kAHNRINV+btjzSZeckc5mVdvZB5zdI07WbU8JLM2o6B//3e53k4530Oh6WknUJf NkWfzhn0aq2cEdO3Y63nQgbqYlQ7f3WGK+pNUoWpfIJW3HpjohQ1zusixUD/ScVMV2YUoyxs dVDK0toMpcWyKFA673yilENFaceEp8T7EjltSiZn2LE/QZxcNvUDpT1WnW9YyRZlI1t0HvJg Ae+Brt56lIfErBS3I6ju6UEuQ4odCOamZcQoE0DPeJvANdDYSMFycS5NnEIBOPpaGDJ8QFBR WEXlIZZlsAJuOoNcR3njI/B1sYxyZShsRGC3PnHfsQ5rYWnKTJGQDh4WvF3lw2BumnVnaOwP bV/fi1wswSpo/lhOk/1aGKj77WYPfBwsL1658wivh3l7tcDFFPaBockSASmKwdL8miIsg5kJ p5Dk1dBaOb6qb4HOsUlEeDP0ltx0PwzgHBE8bexniBENCwP5QmIMIrjR/1Poagw4EO69iyOo AWP36r2boGFhVETiRQyU5DgYUoCD8ppcZETB5jW7Ek6Fvu8rtNnd2Qu6b0/SRA+Fd6YihnAQ 3L/7hSIcArecNnqtXopElUjGczyvSwoLC+UMKWd4PlUfqufSa9G/79X26E9EA2qbPmBDmEVy T0ldZYxKKlRn8hd0NgQsJfeWHDz7T5Ikqi9kcYbUeEOGluNtaCNLy30ky1IvlRQnqdM5Dcel cYb/roD18M1Gh2qEfpcC5VZNol9+1LglsiA50pT+0n8hdinAnvFgWHbieePg9Y7gvqzwN+bL jK5lODdipOmabC6h62JuUrt169G6DPP2z/PbNl+Nl8l3jxTINoyNt4c905yugA6zPd5H/K13 i2DwbJVIv3f20MJzWeHhhLiOgDtM8ajV4lmad0VO88nqXYGUgVf/BTXWc65aAwAA Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:02:23 -0000 --_000_HE1PR07MB31617DB79BE41B64AECF082693920HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have no problem with allowing FQDNs - as long as they result in a SINGLE = address:port. If we want to define ICE usage of FDNSs resulting in MULTIPLE addresses:por= ts, I really think that should be a separate document - it should NOT be ad= ded as a last minute thing to draft-ice-sip-sdp. ...and, yes, perhaps such work would also affect 8445. Regards, Christer ________________________________ From: rtcweb on behalf of Roman Shpount Sent: Friday, February 1, 2019 10:22 PM To: Justin Uberti Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when FQDN i= s used for the default candidate? On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti > wrote: This has all been discussed at length in rtcweb and I don't think any signi= ficant changes are needed, although I tend to think that we should restore = the removed FQDN text from mmusic-ice-sip-sdp, which is the only thing not = in alignment at this point in time. I agree that FQDN should be put back into connection-address definition, bu= t the portion which talks about handling it is completely broken. Quoting 5245: : is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=3Dcandidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing. I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here.. The only options we have here are: a. Fix FQDN connection address handling. Probably the most logical way of d= ealing with this would be to specify that candidate with FQDN should be con= verted as a result of DNS resolution into multiple candidates, with each ca= ndidate corresponding to A or AAAA record in DNS query result. We will also= need to specify how FQDN candidate gets applied to c=3D line address. Some= thing that says IN IP4 FQDN, if any A records exist for this DNS name and I= N IP6 FQDN if only AAAA records exist. Once candidate is nominated, address= family in c=3D line should match address family used for communications. T= his will definitely require a lot more work and discussion. b. Specify that FQDN connection addresses should be ignored until their han= dling is defined in a future specification. This seems easy and only requir= es a sentence or two to fix. Regards, _____________ Roman Shpount --_000_HE1PR07MB31617DB79BE41B64AECF082693920HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


I have no problem with allowing F= QDNs - as long as they result in a SINGLE address:port.


If we want to define ICE usage of= FDNSs resulting in MULTIPLE addresses:ports, I really think that should be= a separate document - it should NOT be added as a last minute thing to dra= ft-ice-sip-sdp.


...and, yes, perhaps such work wo= uld also affect 8445.


Regards,


Christer






From: rtcweb <rtcweb-bou= nces@ietf.org> on behalf of Roman Shpount <roman@telurix.com>
Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when= FQDN is used for the default candidate?
 
On Fri, Feb 1, 2019 at 2:39 PM= Justin Uberti <juberti@google.com> w= rote:
This has all been discussed at length in rtcweb and I don'= t think any significant changes are needed, although I tend to think that w= e should restore the removed FQDN text from mmusic-ice-sip-sdp, which is th= e only thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definitio= n, but  the portion which talks about handling it is completely broken= .

Quoting 5245:
   <connection-address>:  is taken fr=
om RFC 4566 [RFC4566].  It is the=0A=
      IP address of the candidate, allowing for IPv4 addresses, IPv6=0A=
      addresses, and fully qualified domain names (FQDNs).  When par=
sing=0A=
      this field, an agent can differentiate an IPv4 address and an IPv6=0A=

      address by presence of a colon in its=
 value - the presence of a=0A=
      colon indicates IPv6.  An agent MUST ignore candidate lines that=0A=
      include candidates with IP address versions that are not supported=0A=
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be=0A=
      used in place of an IP address.  In that case, when receiving an=0A=
      offer or answer containing an FQDN in an a=3Dcandidate attribute,=0A=
      the FQDN is looked up in the DNS first using an AAAA record=0A=
      (assuming the agent supports IPv6), and if no result is found or=0A=
      the agent only supports IPv4, using an A.  If the DNS query=0A=
      returns more than one IP address, one is chosen, and then used for=0A=
      the remainder of ICE processing.=0A=

I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here..

The only options we have here are:

a. Fix FQDN connection address handling. Probably the most = logical way of dealing with this would be to specify that candidate with FQ= DN should be converted as a result of DNS resolution into multiple candidat= es, with each candidate corresponding to A or AAAA record in DNS query result. We will also need to specify how = FQDN candidate gets applied to c=3D line address. Something that says IN IP= 4 FQDN, if any A records exist for this DNS name and IN IP6 FQDN if only AA= AA records exist. Once candidate is nominated, address family in c=3D line should match address family used fo= r communications. This will definitely require a lot more work and discussi= on.

b. Specify that FQDN connection addresses should be ignored= until their handling is defined in a future specification. This seems easy= and only requires a sentence or two to fix.

Regards,
_____________
Roman Shpount
--_000_HE1PR07MB31617DB79BE41B64AECF082693920HE1PR07MB3161eurp_-- From nobody Fri Feb 1 13:06:39 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E49B130EAB for ; Fri, 1 Feb 2019 13:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 1sKCH9hYv0sw for ; Fri, 1 Feb 2019 13:06:30 -0800 (PST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 ACCBE124408 for ; Fri, 1 Feb 2019 13:06:30 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id r11so3494870pgp.6 for ; Fri, 01 Feb 2019 13:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iff0lhNlCF7xnZCR8/in3v6Cm0JzBcSy7qWsRAEn5xQ=; b=ZBiT+H/KeUmADUCSeNXUlryUQgRc6jlbi/oQw7251D/PclCLhZw1vFzArTCEVIAd+0 taVGOnp3oUnooA2/MurSgrsgFlLlF1V4rAFk4EYo3rLbD9FEwpyv6ydf6u4yTRX8bAZI OYzcpZpI3zODgX+ew5b3QjxDzjIzFjxPNe807faDLECfqiP1qjHOpbpIQW+4rmJV3L7c l6Sy94wBvOxXLXJ5ydvEAwKXyBhMOP96ZukIEQxdRduDPfG4E1GCGxiVVsZ+CXWJhEtf DCxJSHMSnjHkYm2FqmVZBBX2McO05FXswgjIYax66Lx316ZebGYdyG1bosdiD++zdUWS yIpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iff0lhNlCF7xnZCR8/in3v6Cm0JzBcSy7qWsRAEn5xQ=; b=g8xTH+MpbTsNLZwK4Dcby7hhrxi+F43vCVS4FqKNGxN+F/xHb3i7mIFVtxNzRM9j8S ZtFM1QH6kcjt05gwrTWRIi2iXuLvCI0Eg4h6P7ItQzEW+LEnxTDt0jFOg72S859UL1Bu a1J/aEhfTyQ8eowmvG4tF2/Y8Zh4VQx+2n/osvLPj0hFSFYADDOVZVNESpgFhCbSaVAz 7WmhgGPqhhQX8gxi1xxoyi/Ra3r7JeApkSvEX6fcZ3ZCV0w9ZPKxVS1r/kxp/DD9NXSm DzPv6RIxx922bUZV2SxGc2F5+b0yS3fomXJ/0uQjcd+txdWdMxb/Zg/enEQAtW+BTahw Mauw== X-Gm-Message-State: AHQUAuad7i1BAHREClMB1Z0WwA4HRuA/7XG0Yr43mqH15Wr4y7+JxJlo yYyQeAvaT4Q3BU5LwPJDYFUW5nAOZo0= X-Google-Smtp-Source: AHgI3Ibastm4ax3ZdmStPFs0pN31bCDPf/GfUnI/Y2STxSjxwm1sgSF2+tXLKnVWCB2krfUIiGEtCA== X-Received: by 2002:a63:d157:: with SMTP id c23mr2158612pgj.170.1549055189986; Fri, 01 Feb 2019 13:06:29 -0800 (PST) Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com. [209.85.214.171]) by smtp.gmail.com with ESMTPSA id h129sm27548879pfb.110.2019.02.01.13.06.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Feb 2019 13:06:29 -0800 (PST) Received: by mail-pl1-f171.google.com with SMTP id p8so3829127plo.2; Fri, 01 Feb 2019 13:06:29 -0800 (PST) X-Received: by 2002:a17:902:720c:: with SMTP id ba12mr41396137plb.79.1549055188791; Fri, 01 Feb 2019 13:06:28 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Roman Shpount Date: Fri, 1 Feb 2019 16:06:18 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Justin Uberti , Simon Perreault , "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000004403690580db84ee" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:06:34 -0000 --0000000000004403690580db84ee Content-Type: text/plain; charset="UTF-8" In this case section 4.1 of ice-sip-sdp should be updated to allow FQDN in connection-address and, perhaps specify that FWDN which return multiple results should be ignored. Would this work for everyone? Regards, _____________ Roman Shpount On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I have no problem with allowing FQDNs - as long as they result in a SINGLE > address:port. > > > If we want to define ICE usage of FDNSs resulting in MULTIPLE > addresses:ports, I really think that should be a separate document - it > should NOT be added as a last minute thing to draft-ice-sip-sdp. > > > ...and, yes, perhaps such work would also affect 8445. > > > Regards, > > > Christer > > > > > > > ------------------------------ > *From:* rtcweb on behalf of Roman Shpount < > roman@telurix.com> > *Sent:* Friday, February 1, 2019 10:22 PM > *To:* Justin Uberti > *Cc:* Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG > *Subject:* Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN > is used for the default candidate? > > On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti wrote: > > This has all been discussed at length in rtcweb and I don't think any > significant changes are needed, although I tend to think that we should > restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only > thing not in alignment at this point in time. > > > I agree that FQDN should be put back into connection-address definition, > but the portion which talks about handling it is completely broken. > > Quoting 5245 : > > : is taken from RFC 4566 [RFC4566 ]. It is the > IP address of the candidate, allowing for IPv4 addresses, IPv6 > addresses, and *fully qualified domain names (FQDNs).* When parsing > this field, an agent can differentiate an IPv4 address and an IPv6 > > address by presence of a colon in its value - the presence of a > colon indicates IPv6. An agent MUST ignore candidate lines that > include candidates with IP address versions that are not supported > or recognized. An IP address SHOULD be used, but an FQDN MAY be > used in place of an IP address. In that case, when receiving an > offer or answer containing an FQDN in an a=candidate attribute, > the FQDN is looked up in the DNS first using an AAAA record > (assuming the agent supports IPv6), and if no result is found or > the agent only supports IPv4, using an A. If the DNS query > returns more than one IP address, one is chosen, and then used for > the remainder of ICE processing. > > > I think it was discussed in quite a detail why using a random DNS > resolution result is not going to work here.. > > The only options we have here are: > > a. Fix FQDN connection address handling. Probably the most logical way of > dealing with this would be to specify that candidate with FQDN should be > converted as a result of DNS resolution into multiple candidates, with each > candidate corresponding to A or AAAA record in DNS query result. We will > also need to specify how FQDN candidate gets applied to c= line address. > Something that says IN IP4 FQDN, if any A records exist for this DNS name > and IN IP6 FQDN if only AAAA records exist. Once candidate is nominated, > address family in c= line should match address family used for > communications. This will definitely require a lot more work and discussion. > > b. Specify that FQDN connection addresses should be ignored until their > handling is defined in a future specification. This seems easy and only > requires a sentence or two to fix. > > Regards, > _____________ > Roman Shpount > > --0000000000004403690580db84ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In this case section 4.1 of ice-sip-sdp s= hould be updated to allow FQDN in connection-address and, perhaps specify t= hat FWDN which return multiple results should be ignored.

Would this work for everyone?

Regards,
_____= ________
Roman Shpount


On Fri, Feb 1, 2019 at 4:02 PM Chr= ister Holmberg <christ= er.holmberg@ericsson.com> wrote:

I have no problem with allowing FQDNs - as long as they result in a SINGL= E address:port.


If we want to define ICE usag= e of FDNSs resulting in MULTIPLE addresses:ports, I really think that shoul= d be a separate document - it should NOT be added as a last minute thing to= draft-ice-sip-sdp.


...and, yes, perhaps such wor= k would also affect 8445.


Regards,


Christer






Fro= m: rtcweb <rtcweb-bounces@ietf.org> on behalf of Roman Shpount <roman@telurix.com> Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when= FQDN is used for the default candidate?
=C2=A0
On= Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <juberti@google.com>= ; wrote:
This has all been discussed at length in rtcweb and I don&= #39;t think any significant changes are needed, although I tend to think th= at we should restore the removed FQDN text from mmusic-ice-sip-sdp, which i= s the only thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definitio= n, but=C2=A0 the portion which talks about handling it is completely broken= .

Quoting=C2=A05245:
   <connection-ad=
dress>:  is taken from RFC 4566 [RFC4566].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When par=
sing
      this field, an agent can differentiate an IPv4 address and an IPv6

      address by pre=
sence of a colon in its value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.

I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here..

The only options we have here are:

a. Fix FQDN connection address handling. Probably the most logical way= of dealing with this would be to specify that candidate with FQDN should b= e converted as a result of DNS resolution into multiple candidates, with ea= ch candidate corresponding to A or AAAA record in DNS query result. We will also need to specify how = FQDN candidate gets applied to c=3D line address. Something that says IN IP= 4 FQDN, if any A records exist for this DNS name and IN IP6 FQDN if only AA= AA records exist. Once candidate is nominated, address family in c=3D line should match address family used fo= r communications. This will definitely require a lot more work and discussi= on.

b. Specify that FQDN connection addresses should be ignored until thei= r handling is defined in a future specification. This seems easy and only r= equires a sentence or two to fix.

Regards,
_____________
Roman Shpount
--0000000000004403690580db84ee-- From nobody Fri Feb 1 13:17:41 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A0124408 for ; Fri, 1 Feb 2019 13:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.852 X-Spam-Level: X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hbaJl/oE; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VfCFbBkx 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 CftfrAxb7or7 for ; Fri, 1 Feb 2019 13:17:32 -0800 (PST) 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 7A7831312D5 for ; Fri, 1 Feb 2019 13:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549055847; x=1551647847; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=J0InleAtJk46yikHo6O6Zf6T8deC0Yjl5TJz5YBZsgQ=; b=hbaJl/oE4Xy+CpLHvseb/9tqUVnQE92sU8dS0z/5EiTWwH0oR7S8x3sN211YjYHV YH+805mcNWfnek53WL3rEeBc+tjxwmuShEOun8lKZXJIx5rDkQkFg96Yr5IwnJVY zidjVIlCFDx6ELO8+6X2IDS9pCtwxo9ubuLNubbg2S8=; X-AuditID: c1b4fb25-209009e000005ff7-c1-5c54b7678952 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.B5.24567.767B45C5; Fri, 1 Feb 2019 22:17:27 +0100 (CET) Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB505.ericsson.se (153.88.183.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Feb 2019 22:17:03 +0100 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Feb 2019 22:17:03 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 1 Feb 2019 22:17:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J0InleAtJk46yikHo6O6Zf6T8deC0Yjl5TJz5YBZsgQ=; b=VfCFbBkxm8ONFovLGvzK7dwoDUzyCehgikf+eFU0zsMdYK46lhm/kXDbLEDx7I4sY5BLXKdgs+OMFrulaMufI85EjxOeBx3WULxjqOx5r4w6tXtBCP800jnRliZNlctVo3+LuGx1iyhWUaOipFTAKxwE83NVju/dXfRd/BkuzR4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3212.eurprd07.prod.outlook.com (10.170.246.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.13; Fri, 1 Feb 2019 21:16:55 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.013; Fri, 1 Feb 2019 21:16:55 +0000 From: Christer Holmberg To: Roman Shpount CC: Justin Uberti , Simon Perreault , "Dale R. Worley" , RTCWeb IETF , "mmusic WG" Thread-Topic: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? Thread-Index: AQHUulU2uFx8SsiiZk68wi8iILBKkKXLUQeAgAAF3QCAAAwVgIAACK4AgAADoQCAAAJpqQ== Date: Fri, 1 Feb 2019 21:16:55 +0000 Message-ID: References: <874l9ousuk.fsf@hobgoblin.ariadne.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [37.136.56.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3212; 6:BP2y/87cuLmx+0Hw55gic25xvOFFs561kVwVwa7KBKbEh5P4oEizU3R6Qxqv+xoSz1BW+PkBq+/ogreMW4wBEYb+Bk0fT6tZru9w6gYgw5yQLyy3xy/qu0htruv+vk5qQMKCAgNhffAELrcN3vJoAc7E10eaV9MeKTPnjmPkpRLD8yLjYgDz1+RHATQBsPHrizNLPqWQygqV1k9a9beA5tMKqPoSa9Ktqdff9kUcSDxO7gQGsheoKagIxWmf/erD28FLBFHMDRnHd5B3UbGtBRDKHXOxpFvnRfHKSnP8lknCOeZK/lzG/lKMus7vwoM8XI2wcGc01zIbkPA1h5RGZvpn5q1vLAmbCi8KgWsFO3qAp2W+J2UH9OVfuwshl591p1SMt+pDJ0KwHENs2XAKfk0ykxD9/7bMIX65sOKWQL81Dh03N/G0iS75YZToOR340xUAHGmU/TKA4S9IGOXJbQ==; 5:ef906xqG4BYU1c66olg97fQlSXZvXY169NEV71LuCcFyT7MoYc/pQMMuao4lsDjz9f7jmcPvVpvisF1+uQg58fWs9qGKab1cvGZPqLt/wMr7I/cgXHRrLcGKGNG4NDRL56WI5xmbl5d8UVr06w4Z7XzBhuWOq1kAU1TEY8UaMI5GUU0N0UjwvJN5Rr6X/ANEwF2QB0kjrejSVsbqbyRI/Q==; 7:3wzarknytigYpCLqwtfmvFVJHcJhS/PfdF9r2QDKYdwlKPG+Ep5vtsFnJUDtzP1bNG6T7pxmWq/7jViTj98wJWS9tfksQsMn+q+BuSwy6GDTQtMzBL6tW6b95a+o9lDBKeZql5TH+5qKfRVnX6pYHg== x-ms-office365-filtering-correlation-id: d08360ff-f4e0-4ff0-1148-08d6888a982c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3212; x-ms-traffictypediagnostic: HE1PR07MB3212: x-microsoft-antispam-prvs: x-forefront-prvs: 09352FD734 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(136003)(366004)(199004)(189003)(6246003)(8676002)(229853002)(6916009)(256004)(6606003)(8936002)(54906003)(81156014)(6436002)(2906002)(53546011)(316002)(6506007)(14454004)(102836004)(5070765005)(106356001)(66066001)(81166006)(53936002)(68736007)(606006)(14444005)(19627405001)(74316002)(71190400001)(478600001)(71200400001)(86362001)(76176011)(105586002)(6116002)(3846002)(1015004)(7696005)(93886005)(7736002)(99286004)(54896002)(6306002)(9686003)(186003)(26005)(55016002)(486006)(236005)(476003)(97736004)(11346002)(44832011)(446003)(33656002)(4326008)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3212; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nUZof7AElP1kHWrx8JW/Cc/e4pcQG4fRhVzYcMqFGa7L8JRFyd8G+PPCOI6hEsNmoWVtYVM/xxrvfMwrSZHs9teXMd6xbuJDFN0ASNLpSXY8Q14S8GJU6BvOi2yyI4Smy3sFWIpG46J9VYSQ9DZONlTCNmxlP2AAHKhzBJ4gCvcTkSKBfiTzLQACVUr3mpAOLhjwRKf+tZzo1qreeNxwvK/eu2GcVlQb+zp13AZi9up4+gtv/lbVHf0xaaN28AuyMY27sbJU/w6ICd+UWxMulP+p/qc6FADVkxrVMdpM4Qvia4lvimmikhenfzxRaAGYBT8L0palNNTu2pgYZEli/IaBor9CuHbf+jaS6umJIHMdNujoyRWqi2BoG/q91TJsOWYWBeQI9aFharqyDgJRpvxtV8cTDhSOKTdBsr6Uvus= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161679C1754C88B01279A3493920HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d08360ff-f4e0-4ff0-1148-08d6888a982c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2019 21:16:55.7581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3212 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObv37l6Xo+t8e3zLGlrgeyZ4P4TYp4YQJGiK+LbypuJ0tunQ onAGSUoozoHKQkWpMI00TYnQmmKWoZmSNUsUV6JpWLSsrGvbjkXffv///znPc57DYQjZBOXL 5BeV8JoipUoulpBNqQMXwnMHktKj2u/6cP1GGWe8uUxyjS+MBNctVNHc3GwytzquixcrDMM2 QtHaW6ro6PghUgim94TC0lB8kkqTHM3hVfk6XhMZly3Jmx+rQcUmXdl14VIFas+pRi4MsDHQ N7FNVCMJI2NHEWxZKkVY2BD0zNxC/4TpzpfdpF0Etv4rlEOQbB0Bwy2NFE7qRbC28FyMxZL9 TOeavQHDiFkOaoRQx0QPNhh+bxmcrQj2PgLrlGOiC+POquDnh2YCFxVCT+2rXT4FI9O3xQ4m 2SDQm7coB0vZdLBZqkg8bI6G7qEx2hG4sInQ/7bR2RSxXrD1rMvJBOsNFmuLCO/NQsfDKQKz J6wuCxSuV8Jw5+Kuvx+eLFgR5gB42VLjfA1gK2lom6/YDU7AozkDhYM3CITaDQoHIbC2uENj LoCuzR4Ssz8Mfn9H4wP1Yli+XCWuQ+HN/90Qsxo2bF/pZueqbvC0yUpiPwJeGxvEmEPhRttH AnM4NApm8n+/FdGdyFPLa08X5kYfieA1+We0WnVRRBFf0ovsX+xx33bwIJpZP2ZGLIPkrlJ9 Z1K6jFLqtOWFZgQMIfeQWvrtljRHWX6e16izNKUqXmtGfgwp95b+krmly9hcZQlfwPPFvOZv KmJcfCtQ2IPFyaxM03GP5KFA14srosjswJRvCZOzXhlnr7lmRna5raS656znHlBXJ+yLWvoc 364/lJY2uiZZyO7jZqQGhTVlSD0aMa736hLo1cqST+5CnSlmbyBd1XYudI9tc9tgu3dVVZ9Y 5neQyxsJl0SXhgXs+PhPT8TGlvdkBMV5yUltnvJwCKHRKv8A3gL9QF4DAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 21:17:35 -0000 --_000_HE1PR07MB3161679C1754C88B01279A3493920HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, > In this case section 4.1 of ice-sip-sdp should be updated to allow FQDN i= n > connection-address and, perhaps specify that FWDN which return multiple > results should be ignored. I suggest MUST be ignored, perhaps with a note saying that a future specifi= cation will have to define how to use FQDNs that return multiple results. > Would this work for everyone? It would work for me. Regards, Christer On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg > wrote: I have no problem with allowing FQDNs - as long as they result in a SINGLE = address:port. If we want to define ICE usage of FDNSs resulting in MULTIPLE addresses:por= ts, I really think that should be a separate document - it should NOT be ad= ded as a last minute thing to draft-ice-sip-sdp. ...and, yes, perhaps such work would also affect 8445. Regards, Christer ________________________________ From: rtcweb > on b= ehalf of Roman Shpount > Sent: Friday, February 1, 2019 10:22 PM To: Justin Uberti Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when FQDN i= s used for the default candidate? On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti > wrote: This has all been discussed at length in rtcweb and I don't think any signi= ficant changes are needed, although I tend to think that we should restore = the removed FQDN text from mmusic-ice-sip-sdp, which is the only thing not = in alignment at this point in time. I agree that FQDN should be put back into connection-address definition, bu= t the portion which talks about handling it is completely broken. Quoting 5245: : is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=3Dcandidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing. I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here.. The only options we have here are: a. Fix FQDN connection address handling. Probably the most logical way of d= ealing with this would be to specify that candidate with FQDN should be con= verted as a result of DNS resolution into multiple candidates, with each ca= ndidate corresponding to A or AAAA record in DNS query result. We will also= need to specify how FQDN candidate gets applied to c=3D line address. Some= thing that says IN IP4 FQDN, if any A records exist for this DNS name and I= N IP6 FQDN if only AAAA records exist. Once candidate is nominated, address= family in c=3D line should match address family used for communications. T= his will definitely require a lot more work and discussion. b. Specify that FQDN connection addresses should be ignored until their han= dling is defined in a future specification. This seems easy and only requir= es a sentence or two to fix. Regards, _____________ Roman Shpount --_000_HE1PR07MB3161679C1754C88B01279A3493920HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Hi,
 
> In this case section 4.1 of ice-sip-sdp should be upd= ated to allow FQDN in 
> connection-address and, perhaps specify that FWDN whi= ch return multiple 
> results should be ignored.

I suggest MUST be ignored, perhaps with a note saying that= a future specification will have to define how to use FQDNs that return mu= ltiple results.

> Would this work for everyone?

It would work for me.

Regards,

Christer



On Fri, Feb 1, 2019 at 4:02 PM Chri= ster Holmberg <christer.holmberg= @ericsson.com> wrote:

I have no problem with allowing FQDNs - as long as they result in a SING= LE address:port.


If we want to define ICE usa= ge of FDNSs resulting in MULTIPLE addresses:ports, I really think that shou= ld be a separate document - it should NOT be added as a last minute thing t= o draft-ice-sip-sdp.


...and, yes, perhaps such wo= rk would also affect 8445.


Regards,


Christer






F= rom: rtcweb <rtcw= eb-bounces@ietf.org> on behalf of Roman Shpount <roman@telurix.com>
Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when= FQDN is used for the default candidate?
 
= On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <juberti@google= .com> wrote:
This has all been discussed at length in rtcweb and I don'= t think any significant changes are needed, although I tend to think that w= e should restore the removed FQDN text from mmusic-ice-sip-sdp, which is th= e only thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definitio= n, but  the portion which talks about handling it is completely broken= .

Quoting 5245:
   <connec=
tion-address>:  is taken from RFC 4566 [R=
FC4566].  It is the=0A=
      IP address of the candidate, allowing for IPv4 addresses, IPv6=0A=
      addresses, and fully qualified domain names (FQDNs).  When par=
sing=0A=
      this field, an agent can differentiate an IPv4 address and an IPv6=0A=

      address=
 by presence of a colon in its value - the presence of a=0A=
      colon indicates IPv6.  An agent MUST ignore candidate lines that=0A=
      include candidates with IP address versions that are not supported=0A=
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be=0A=
      used in place of an IP address.  In that case, when receiving an=0A=
      offer or answer containing an FQDN in an a=3Dcandidate attribute,=0A=
      the FQDN is looked up in the DNS first using an AAAA record=0A=
      (assuming the agent supports IPv6), and if no result is found or=0A=
      the agent only supports IPv4, using an A.  If the DNS query=0A=
      returns more than one IP address, one is chosen, and then used for=0A=
      the remainder of ICE processing.=0A=

I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here..

The only options we have here are:

a. Fix FQDN connection address handling. Probably the most logical way= of dealing with this would be to specify that candidate with FQDN should b= e converted as a result of DNS resolution into multiple candidates, with ea= ch candidate corresponding to A or AAAA record in DNS query result. We will also need to specify how FQDN = candidate gets applied to c=3D line address. Something that says IN IP4 FQD= N, if any A records exist for this DNS name and IN IP6 FQDN if only AAAA re= cords exist. Once candidate is nominated, address family in c=3D line should match address family used for communica= tions. This will definitely require a lot more work and discussion.

b. Specify that FQDN connection addresses should be ignored until thei= r handling is defined in a future specification. This seems easy and only r= equires a sentence or two to fix.

Regards,
_____________
Roman Shpount
--_000_HE1PR07MB3161679C1754C88B01279A3493920HE1PR07MB3161eurp_-- From nobody Fri Feb 1 14:23:01 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEABF130ED6; Fri, 1 Feb 2019 14:22:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <154905977485.28430.5824308143067661041@ietfa.amsl.com> Date: Fri, 01 Feb 2019 14:22:54 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-arch-18.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 22:22:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : WebRTC Security Architecture Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-arch-18.txt Pages : 43 Date : 2019-02-01 Abstract: This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-arch-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-arch-18 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 Fri Feb 1 14:23:14 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C09B1312B9; Fri, 1 Feb 2019 14:23:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <154905978253.28577.10807319265606888678@ietfa.amsl.com> Date: Fri, 01 Feb 2019 14:23:02 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-11.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 22:23:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : Security Considerations for WebRTC Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-11.txt Pages : 25 Date : 2019-02-01 Abstract: WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-11 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-11 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 Fri Feb 1 15:28:23 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAA6130F6D for ; Fri, 1 Feb 2019 15:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.641 X-Spam-Level: X-Spam-Status: No, score=-17.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dBS-wMyDHyS for ; Fri, 1 Feb 2019 15:28:12 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 4C0CB130DFA for ; Fri, 1 Feb 2019 15:28:12 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id t24so7196264ioi.0 for ; Fri, 01 Feb 2019 15:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ot9NtzC2DaxpHhVI//RiX2SQDQ2wZDVa1JI2nBQD2Q=; b=SRFRMx/bEi5BZWQKo3OW+1XPD1XiPPv16Mzlt1+WR+iFsOCMwgKVxvt8kdli4eHEkB lVlUEs/S9RUgxOS7rXDtDxSjqM5OJ+6VuIw8PXdAXI8erDNlTwlBLQRDgM+kUDdLMT+k OsjYNeIFaAdkjsW7SiQhpIMKBVWGNjvewCwN02f2gNWRY6wyjEQ0+YaLGkzY47g+ypGt HbSxUttex+n2DFFLxf/gnsp7z9mE1hfd9HLcMw5wMF/LJukjmGMOkCkbZaQFRZyCMxTP MbIJKx+YZyPMpqfNJiWZ0YT8cbF2TR1Y/Vu9ym7rE75ZZblTtlG8QNgyLh+KMcl4DxWn tWlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ot9NtzC2DaxpHhVI//RiX2SQDQ2wZDVa1JI2nBQD2Q=; b=nHtBsU8Wq+rykZR9Y/0qJqrLzsYxQ04DO5VJcU7kvUWoPi9txwXS55DainKv0yaSYc djhE2vTrYKQM1/krwhCOydIaYrdpS2vOdYZqm8ROnYqSkdHBrG159hUox3Y59gRrJnY+ BrzeyS2CYp07xZvnL2wWSKMeLW7FSL0cUqqSgYhP/2b0yA2kN1Gvojyhxjjvrte/DDTi yDnS9mRmRJlpElFyc3EXiKYpohIcnzdjhku92dat5ZefdzPCD//0L8dNpGTOWxI47Q/7 Ut77NR5M4ajsaXofN9i3tlt9XYJNGTEiAMfKls1u24ylLEt1UiugZNswbnD49Ta4lUX5 0L2w== X-Gm-Message-State: AHQUAuaZAV243vunkMsoyj0TWsKRD9asAUpr9WZ7RsiWn3yaGl0djt0n p5mGxf8a/TjN+8tvXM1G9BTb/B7AbpT0pyRWZTYIYQ== X-Google-Smtp-Source: AHgI3IYdJUF4HlMD0PRr2IV8iHBKMUWmU/jMa5eKJ6z6FtgTZgD9YEslUDyyw535bAcHFF8/cFccg3FXp7cbiXkm8BE= X-Received: by 2002:a5e:920d:: with SMTP id y13mr22265000iop.95.1549063691156; Fri, 01 Feb 2019 15:28:11 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> In-Reply-To: From: Justin Uberti Date: Fri, 1 Feb 2019 15:27:56 -0800 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Simon Perreault , "Dale R. Worley" , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="0000000000000c703c0580dd7ff3" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 23:28:16 -0000 --0000000000000c703c0580dd7ff3 Content-Type: text/plain; charset="UTF-8" That works for me as well - it then becomes a clarification of 5245, rather than a removal of functionality. On Fri, Feb 1, 2019 at 1:17 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > > In this case section 4.1 of ice-sip-sdp should be updated to allow FQDN > in > > connection-address and, perhaps specify that FWDN which return multiple > > results should be ignored. > > I suggest MUST be ignored, perhaps with a note saying that a future > specification will have to define how to use FQDNs that return multiple > results. > > > Would this work for everyone? > > It would work for me. > > Regards, > > Christer > > > > On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > I have no problem with allowing FQDNs - as long as they result in a SINGLE > address:port. > > > If we want to define ICE usage of FDNSs resulting in MULTIPLE > addresses:ports, I really think that should be a separate document - it > should NOT be added as a last minute thing to draft-ice-sip-sdp. > > > ...and, yes, perhaps such work would also affect 8445. > > > Regards, > > > Christer > > > > > > > ------------------------------ > *From:* rtcweb on behalf of Roman Shpount < > roman@telurix.com> > *Sent:* Friday, February 1, 2019 10:22 PM > *To:* Justin Uberti > *Cc:* Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG > *Subject:* Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN > is used for the default candidate? > > On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti wrote: > > This has all been discussed at length in rtcweb and I don't think any > significant changes are needed, although I tend to think that we should > restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only > thing not in alignment at this point in time. > > > I agree that FQDN should be put back into connection-address definition, > but the portion which talks about handling it is completely broken. > > Quoting 5245 : > > : is taken from RFC 4566 [RFC4566 ]. It is the > IP address of the candidate, allowing for IPv4 addresses, IPv6 > addresses, and *fully qualified domain names (FQDNs).* When parsing > this field, an agent can differentiate an IPv4 address and an IPv6 > > address by presence of a colon in its value - the presence of a > colon indicates IPv6. An agent MUST ignore candidate lines that > include candidates with IP address versions that are not supported > or recognized. An IP address SHOULD be used, but an FQDN MAY be > used in place of an IP address. In that case, when receiving an > offer or answer containing an FQDN in an a=candidate attribute, > the FQDN is looked up in the DNS first using an AAAA record > (assuming the agent supports IPv6), and if no result is found or > the agent only supports IPv4, using an A. If the DNS query > returns more than one IP address, one is chosen, and then used for > the remainder of ICE processing. > > > I think it was discussed in quite a detail why using a random DNS > resolution result is not going to work here.. > > The only options we have here are: > > a. Fix FQDN connection address handling. Probably the most logical way of > dealing with this would be to specify that candidate with FQDN should be > converted as a result of DNS resolution into multiple candidates, with each > candidate corresponding to A or AAAA record in DNS query result. We will > also need to specify how FQDN candidate gets applied to c= line address. > Something that says IN IP4 FQDN, if any A records exist for this DNS name > and IN IP6 FQDN if only AAAA records exist. Once candidate is nominated, > address family in c= line should match address family used for > communications. This will definitely require a lot more work and discussion. > > b. Specify that FQDN connection addresses should be ignored until their > handling is defined in a future specification. This seems easy and only > requires a sentence or two to fix. > > Regards, > _____________ > Roman Shpount > > --0000000000000c703c0580dd7ff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That works for me as well - it then becomes a clarifi= cation of 5245, rather than a removal of functionality.

On Fri, Feb 1, 2019 = at 1:17 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:


Hi,
=C2=A0
> In this case section 4.1 of ice-sip-sdp should be upd= ated to allow FQDN in=C2=A0
> connection-address and, perhaps specify that FWDN whi= ch return multiple=C2=A0
> results should be ignored.

I suggest MUST be ignored, perhaps with a note saying that= a future specification will have to define how to use FQDNs that return mu= ltiple results.

> Would this work for everyone?

It would work for me.

Regards,

Christer



On Fri, = Feb 1, 2019 at 4:02 PM Christer Holmberg <christer.holmberg= @ericsson.com> wrote:

I have no problem with allowing FQDNs - as long as they result in a SINGL= E address:port.


If we want to define ICE usag= e of FDNSs resulting in MULTIPLE addresses:ports, I really think that shoul= d be a separate document - it should NOT be added as a last minute thing to= draft-ice-sip-sdp.


...and, yes, perhaps such wor= k would also affect 8445.


Regards,


Christer






From: rtcweb <rtcweb-bounces@ietf.o= rg> on behalf of Roman Shpount <roman@telurix.com>
Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when= FQDN is used for the default candidate?
=C2=A0
On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <= ;juber= ti@google.com> wrote:
This has all been discussed at length in rtcweb and I don&= #39;t think any significant changes are needed, although I tend to think th= at we should restore the removed FQDN text from mmusic-ice-sip-sdp, which i= s the only thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definitio= n, but=C2=A0 the portion which talks about handling it is completely broken= .

Quoting=C2=A05245:
   <connection-address>:  is taken from RFC 4566 [<=
a title=3D""SDP: Session Description Protocol"" class=3D"gmail-m_=
4281477119354329881x_gmail-m_-7925862921453132447OWAAutoLink gmail-m_428147=
7119354329881OWAAutoLink" id=3D"gmail-m_4281477119354329881LPlnk550807" hre=
f=3D"https://tools.ietf.org/html/rfc4566" target=3D"_blank">RFC4566].  =
It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).  When par=
sing
      this field, an agent can differentiate an IPv4 address and an IPv6

      address by presence of a colon in its value - the presence o=
f a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.

I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here..

The only options we have here are:

a. Fix FQDN connection address handling. Probably the most logical way= of dealing with this would be to specify that candidate with FQDN should b= e converted as a result of DNS resolution into multiple candidates, with ea= ch candidate corresponding to A or AAAA record in DNS query result. We will also need to specify how FQDN = candidate gets applied to c=3D line address. Something that says IN IP4 FQD= N, if any A records exist for this DNS name and IN IP6 FQDN if only AAAA re= cords exist. Once candidate is nominated, address family in c=3D line should match address family used for communica= tions. This will definitely require a lot more work and discussion.

b. Specify that FQDN connection addresses should be ignored until thei= r handling is defined in a future specification. This seems easy and only r= equires a sentence or two to fix.

Regards,
_____________
Roman Shpount
--0000000000000c703c0580dd7ff3-- From nobody Fri Feb 1 16:37:39 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7025613102B; Fri, 1 Feb 2019 16:37:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , draft-ietf-rtcweb-security@ietf.org, rtcweb@ietf.org, sean@sn3rd.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154906785144.28589.7587361466598943024.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2019 16:37:31 -0800 Archived-At: Subject: [rtcweb] Last Call: (Security Considerations for WebRTC) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 00:37:32 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'Security Considerations for WebRTC' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Feb 1 16:38:09 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F00813130D; Fri, 1 Feb 2019 16:37:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , rtcweb@ietf.org, draft-ietf-rtcweb-security-arch@ietf.org, sean@sn3rd.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154906787838.28409.11248083287351288061.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2019 16:37:58 -0800 Archived-At: Subject: [rtcweb] Last Call: (WebRTC Security Architecture) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 00:38:03 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC Security Architecture' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7918: Transport Layer Security (TLS) False Start (Informational - IETF stream) From nobody Fri Feb 1 16:38:26 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB181312FD; Fri, 1 Feb 2019 16:38:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk CC: adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , draft-ietf-rtcweb-ip-handling@ietf.org, rtcweb@ietf.org, sean@sn3rd.com Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <154906790062.28589.8178588125980264217.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2019 16:38:20 -0800 Archived-At: Subject: [rtcweb] Last Call: (WebRTC IP Address Handling Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 00:38:25 -0000 The IESG has received a request from the Real-Time Communication in WEB-browsers WG (rtcweb) to consider the following document: - 'WebRTC IP Address Handling Requirements' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides information and requirements for how IP addresses should be handled by WebRTC implementations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Feb 3 18:11:05 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901C712D4EC for ; Sun, 3 Feb 2019 18:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id busjCokzc_Ll for ; Sun, 3 Feb 2019 18:11:01 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97887126F72 for ; Sun, 3 Feb 2019 18:11:01 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id c21so7466268qkl.6 for ; Sun, 03 Feb 2019 18:11:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Arqnd2II3+oUvsnS+KKbaz6ZDvuZyBeClVXURy9hCbM=; b=L6TNxmiRDTLroDqxaThoo8LT3OTl21NgpuzxEe6KSKWJy/RI0G5h5l3FMU7V6Fdvxw fgWjciFBuLE+TRTzTu8JKRSFIm2O1SWenT/rEH9J8f8q+pFxJTZaEW3s+eejQU+iAkHJ exDuQCd5VhTFuGXpDgzFFfDaRCvWOA9FsAUQY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Arqnd2II3+oUvsnS+KKbaz6ZDvuZyBeClVXURy9hCbM=; b=iC8M/s7PTnTFNKVaRW9jcHRaeYuap3XxgAOhQS/I/bLk//snuohgVEW6GqHQHnq8v1 5EV8LDHuyV/ZE6TDOeQvkeVVm+wyydTG3zkgD1eO7I7GARYHjRte+R7HDL5srMXIFOP3 PM5OcACJQc9jqm2jIJ6Zsc1mJkDyd7HsIW6Olj+UfasE2b5wzZqxNFOsrd+MxZAhG6n2 JMid8gxRZHusRRqT8WiXIHH+/s7gv+/NLaSlo7j1iSLt4+A2NW512T2lidUKnOw3JDAi +JV9h+megaXdSnir7+BMXPnZDuzKRKhxx5Bvk3NfIHW9hDKa65LwuPalrxUzMXf6FEwB JL8Q== X-Gm-Message-State: AHQUAuZObnsyuIskDQeNU8YHw1huWsRdUIfafssINpefcDDx4dTy5vdW 6szAz2BhrmtunTmGuNWdcdqlOauRj48= X-Google-Smtp-Source: AHgI3IZ3LTxe/1+zbRO0wQFzuzq9uWp1J/m4CxZhU9ckyAolJcbYNHxmidpet9GgApimBQu2+da/Zw== X-Received: by 2002:a37:d405:: with SMTP id l5mr2443026qki.268.1549246260412; Sun, 03 Feb 2019 18:11:00 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id g5sm13059398qkd.55.2019.02.03.18.10.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Feb 2019 18:10:59 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <58A21EB7-1395-4141-86F4-7CC26FBA630D@sn3rd.com> Date: Sun, 3 Feb 2019 21:10:58 -0500 To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [rtcweb] IETF LC's started for the security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 02:11:04 -0000 Hi, In case you missed it, Adam has kicked off the IETF LC=E2=80=99s for the = three security drafts: [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/kVFED2FlqzWBPBEdHe3kmbemjv4 [1] = https://mailarchive.ietf.org/arch/msg/rtcweb/iuTO-OzhZkxU9z9Odz4wQgi1xrk [2] = https://mailarchive.ietf.org/arch/msg/rtcweb/PkzqlzkiKoLpqV8pEO6Y8GfowsE Cheers, spt= From nobody Sun Feb 3 18:22:45 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBD812D4EC for ; Sun, 3 Feb 2019 18:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NsPxSKlR6rw for ; Sun, 3 Feb 2019 18:22:43 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 4AAD8126F72 for ; Sun, 3 Feb 2019 18:22:43 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id b15so2123749qto.8 for ; Sun, 03 Feb 2019 18:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=q3hXfswhp2yA/dB57pS9wE2rjoZGDhq4F3L6Q905U78=; b=eQnCyWroDxkG4KF0p7XgzOn5sG3d1nxLkJGwuL5zFozIHzx9p76n8DV6v/xlXfgPv/ ZcKIWR16Dv/vfQaqaZxxDFGdPyBc7GBYFWC1lq/d9WaSUDehiM5ugd/La/mQuzWh0H/0 bErltx3hpK180bxv6ZT4XgE9A5B58XvKUVmfo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=q3hXfswhp2yA/dB57pS9wE2rjoZGDhq4F3L6Q905U78=; b=EgVmV8Lc+RCTLfrR8oMIV7RajfHBVMAZZIgEI88KYyQICjtrR5vOWuJ2pLgWAyIsl2 LzzmJtZsJIEJAJDazDgEA/1WH43CSAQDymb47xmZskMXg+/xHNlJEVXZUUTlN6IMKbrd weObtefknaGDa1ZEXexKVJtoULR4UIGjn4IHe78zPOC6OPF2KvV4ex+kkCe2l1TgEd4Q gNJwKLG2nGx9HB6/dynPYPMRzLcbRynKJGal/MQCu581K4XnOlm1PY+UNeTLCEQsvavB 1WGvKcVBeFwWHZ1Kkk+Lj2tw2ir/FAbo+zx7xLklH+3lbPN4/8O/wtl7/7JQYykuiPTu 7I8g== X-Gm-Message-State: AJcUukcKQ8sOvzSPVCkb/wQbhPV4AIrreykVEYe9sW7EG1hEiGh5oC0M iZm3o7WQ/tOgLJF3j74X+m6Ez2UzPaI= X-Google-Smtp-Source: ALg8bN6OgH3Oysy+TPFWFTaZFKYR2j57BmuhLLXTdO7l9z3HU3fKC18tjMqblt/qG54veZ+x4EpVjA== X-Received: by 2002:a0c:aa84:: with SMTP id f4mr45677965qvb.243.1549246962074; Sun, 03 Feb 2019 18:22:42 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id l15sm9807683qtr.25.2019.02.03.18.22.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Feb 2019 18:22:41 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <0415436F-75F5-467A-B373-412C72ED56EB@sn3rd.com> Date: Sun, 3 Feb 2019 21:22:40 -0500 To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [rtcweb] IETF LC's started for the security drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 02:22:45 -0000 Hi, In case you missed it, Adam has kicked off the IETF LC=E2=80=99s for the = three security drafts: [0] = https://mailarchive.ietf.org/arch/msg/rtcweb/kVFED2FlqzWBPBEdHe3kmbemjv4 [1] = https://mailarchive.ietf.org/arch/msg/rtcweb/iuTO-OzhZkxU9z9Odz4wQgi1xrk [2] = https://mailarchive.ietf.org/arch/msg/rtcweb/PkzqlzkiKoLpqV8pEO6Y8GfowsE Probably best to reply to those individual threads instead of this one. Cheers, spt= From nobody Tue Feb 5 07:03:56 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681FE12D4EF; Tue, 5 Feb 2019 07:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-mKvWZFfNRI; Tue, 5 Feb 2019 07:03:50 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D2C5B128CF3; Tue, 5 Feb 2019 07:03:49 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id z26so2882119lfj.6; Tue, 05 Feb 2019 07:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=owExOrfkKjs/wCjN5kHmH+mHynDVt0DON6xDWz+TcX4=; b=NU0CrmYinnNr9NHoiZiltcBGCDdDvbfIMQ65nYAO3vbkG6OOiEKdIwYhML2xKd00jB pO5b4csuQ0CaD1A0kGzHW5RtGYd8LwBewWM61bPrygAXOV6LWcVVyy+0J/6UB8E94H9i 4uAiAd+YklyX6oGQFRedodTWMQTxyMdlJTLNcbLIV/WBITf/YFdk42VICI93j1A7RC2U opvhATMyLkwyLb4zD7xNPJ5HXLieoHD2SltiZ0FgkcN6Drpw4UbpCoW2hcUAbiVToahw tKWQamyphicThCOCY+f4gnXcj/KLEWdVgAuIlSqLdcgAPKyP+wuobDj/573rJEXjWzUq rsDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=owExOrfkKjs/wCjN5kHmH+mHynDVt0DON6xDWz+TcX4=; b=TLw16q+Yz4t0HP8/YmnTukVQjM8YDWDA5HSaz/XlTuZPoRHo2XH+GVx07PFpwTmxU+ zU6jTpDnbyIJinZ0LyfxQFXZha4RD1q6LpAvnYGyk5PX0XTMG/xXRjIRLpOCPR70r3Cp jHbOktZQFygc97bBvVFoP0+yNkxm0MhFrWw9xEJ+C+jTyufSqrx7PTAwoc9f/MgbHXfY HNXYO0STbrXQ7/A75hcIIAY1FymWamLfwBUhURP9FyYhpeg/k2Bvjuzyha++uI3qZgGE T/lCfz6RCSQUd1AVcdtrEfF6jxpJVUdkOAD1CXvLrAMccTLTRlEyC0BrM6VmkTb5YgIN RBAg== X-Gm-Message-State: AHQUAua0Ujj3VsusSDARwxg8yW1OFUTVYrXQyJVf2VlgAAoxGCEKNArW fibgl5ZDSCC0WufSl6f5S5s= X-Google-Smtp-Source: AHgI3Ibi4gH6z0SIjn2NjhT129hNKcBq49ekleyaPpz9sL6MAsQ5RdA73wUJwJ6wmSVKJVvl4TXghw== X-Received: by 2002:a19:d1d2:: with SMTP id i201mr3365742lfg.136.1549379027942; Tue, 05 Feb 2019 07:03:47 -0800 (PST) Received: from [192.168.1.66] ([31.185.193.196]) by smtp.gmail.com with ESMTPSA id y24-v6sm3271987ljd.20.2019.02.05.07.03.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 07:03:45 -0800 (PST) From: Alan Ford Message-Id: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 5 Feb 2019 15:03:41 +0000 In-Reply-To: Cc: Christer Holmberg , Simon Perreault , RTCWeb IETF , mmusic WG To: Roman Shpount References: <874l9ousuk.fsf@hobgoblin.ariadne.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 15:03:53 -0000 --Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If that update was to be made, this goes against the text in = draft-ietf-rtcweb-mdns-ice-candidates-02 which says: An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others. The ICE agent SHOULD, if available, use the first IPv6 address resolved, otherwise the first IPv4 address. But there=E2=80=99s a bigger problem here, which is how to cope with an = FQDN is not resolvable. So the intention, as I understand it, is that = when these host candidates leave the mDNS domain and are thus not = resolvable, they will be treated as peer reflexive candidates. But at that point there is no address family information available, so = how does an ICE agent know to do pairing with these candidates, which = requires the address family to be known? Regards, Alan > On 1 Feb 2019, at 21:06, Roman Shpount wrote: >=20 > In this case section 4.1 of ice-sip-sdp should be updated to allow = FQDN in connection-address and, perhaps specify that FWDN which return = multiple results should be ignored. >=20 > Would this work for everyone? >=20 > Regards, > _____________ > Roman Shpount >=20 >=20 > On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg = > = wrote: > I have no problem with allowing FQDNs - as long as they result in a = SINGLE address:port. >=20 > If we want to define ICE usage of FDNSs resulting in MULTIPLE = addresses:ports, I really think that should be a separate document - it = should NOT be added as a last minute thing to draft-ice-sip-sdp. >=20 > ...and, yes, perhaps such work would also affect 8445. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > From: rtcweb > on behalf of Roman Shpount = > > Sent: Friday, February 1, 2019 10:22 PM > To: Justin Uberti > Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG > Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when = FQDN is used for the default candidate? > =20 > On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti > wrote: > This has all been discussed at length in rtcweb and I don't think any = significant changes are needed, although I tend to think that we should = restore the removed FQDN text from mmusic-ice-sip-sdp, which is the only = thing not in alignment at this point in time. >=20 > I agree that FQDN should be put back into connection-address = definition, but the portion which talks about handling it is completely = broken.. >=20 > Quoting 5245 : > : is taken from RFC 4566 = [RFC4566 = ]. It is the > IP address of the candidate, allowing for IPv4 addresses, IPv6 > addresses, and fully qualified domain names (FQDNs). When = parsing > this field, an agent can differentiate an IPv4 address and an = IPv6 > address by presence of a colon in its value - the presence of a > colon indicates IPv6. An agent MUST ignore candidate lines that > include candidates with IP address versions that are not = supported > or recognized. An IP address SHOULD be used, but an FQDN MAY be > used in place of an IP address. In that case, when receiving an > offer or answer containing an FQDN in an a=3Dcandidate = attribute, > the FQDN is looked up in the DNS first using an AAAA record > (assuming the agent supports IPv6), and if no result is found or > the agent only supports IPv4, using an A. If the DNS query > returns more than one IP address, one is chosen, and then used = for > the remainder of ICE processing. >=20 > I think it was discussed in quite a detail why using a random DNS = resolution result is not going to work here.. >=20 > The only options we have here are: >=20 > a. Fix FQDN connection address handling. Probably the most logical way = of dealing with this would be to specify that candidate with FQDN should = be converted as a result of DNS resolution into multiple candidates, = with each candidate corresponding to A or AAAA record in DNS query = result. We will also need to specify how FQDN candidate gets applied to = c=3D line address. Something that says IN IP4 FQDN, if any A records = exist for this DNS name and IN IP6 FQDN if only AAAA records exist. Once = candidate is nominated, address family in c=3D line should match address = family used for communications. This will definitely require a lot more = work and discussion. >=20 > b. Specify that FQDN connection addresses should be ignored until = their handling is defined in a future specification. This seems easy and = only requires a sentence or two to fix. >=20 > Regards, > _____________ > Roman Shpount > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = that update was to be made, this goes against the text = in draft-ietf-rtcweb-mdns-ice-candidates-02 which says:

   An ICE = agent that supports mDNS candidates MUST support the situation
   where the hostname resolution results in more = than one IP address.
   In this case, the ICE = agent MUST take exactly one of the resolved IP
  =  addresses and ignore the others.  The ICE agent SHOULD, if = available,
   use the first IPv6 address = resolved, otherwise the first IPv4
  =  address.

But there=E2=80=99s a bigger problem here, which = is how to cope with an FQDN is not resolvable. So the intention, as I = understand it, is that when these host candidates leave the mDNS domain = and are thus not resolvable, they will be treated as peer reflexive = candidates.

But at that point there = is no address family information available, so how does an ICE agent = know to do pairing with these candidates, which requires the address = family to be known?

Regards,
Alan

On 1 Feb = 2019, at 21:06, Roman Shpount <roman@telurix.com> wrote:

In this case section 4.1 of = ice-sip-sdp should be updated to allow FQDN in connection-address and, = perhaps specify that FWDN which return multiple results should be = ignored.

Would this work for everyone?

Regards,
_____________
Roman = Shpount


On Fri, Feb = 1, 2019 at 4:02 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
I have no = problem with allowing FQDNs - as long as they result in a SINGLE = address:port.

If = we want to define ICE usage of FDNSs resulting in MULTIPLE = addresses:ports, I really think that should be a separate document - it = should NOT be added as a last minute thing to = draft-ice-sip-sdp.

...and, yes, perhaps such work would also affect = 8445.

Regards,

Christer





From: rtcweb <rtcweb-bounces@ietf.org> on behalf of Roman Shpount = <roman@telurix.com>
Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; = mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D = line address when FQDN is used for the default candidate?
 
On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <juberti@google.com> wrote:
This has all been discussed at length in = rtcweb and I don't think any significant changes are needed, although I = tend to think that we should restore the removed FQDN text from = mmusic-ice-sip-sdp, which is the only thing not in alignment at this point in time.

I agree that FQDN should be put back into = connection-address definition, but  the portion which talks about = handling it is completely broken..

Quoting 5245:
   =
<connection-address>:  is taken from RFC =
4566 [RFC4566].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names =
(FQDNs).  When parsing
      this field, an agent can differentiate an IPv4 address and an IPv6

      address by presence =
of a colon in its value - the presence of a
      colon indicates IPv6.  An agent MUST ignore candidate lines that
      include candidates with IP address versions that are not supported
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be
      used in place of an IP address.  In that case, when receiving an
      offer or answer containing an FQDN in an a=3Dcandidate attribute,
      the FQDN is looked up in the DNS first using an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.

I think it was discussed in quite a detail why using a random DNS = resolution result is not going to work here..

The only options we have here are:

a. Fix FQDN connection address handling. Probably the = most logical way of dealing with this would be to specify that candidate = with FQDN should be converted as a result of DNS resolution into = multiple candidates, with each candidate corresponding to A or AAAA record in DNS query result. We will also need to specify = how FQDN candidate gets applied to c=3D line address. Something that = says IN IP4 FQDN, if any A records exist for this DNS name and IN IP6 = FQDN if only AAAA records exist. Once candidate is nominated, address family in c=3D line should match address family used = for communications. This will definitely require a lot more work and = discussion.

b. Specify that FQDN connection addresses should be = ignored until their handling is defined in a future specification. This = seems easy and only requires a sentence or two to fix.

Regards,
_____________
Roman Shpount
_______________________________________________
mmusic = mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

= --Apple-Mail=_D52ECA0E-FEE4-4068-9E22-7E0B9B278114-- From nobody Tue Feb 5 10:19:34 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A1D1311F8 for ; Tue, 5 Feb 2019 10:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 R03GmkN0gWTF for ; Tue, 5 Feb 2019 10:19:19 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 66BAB1311E4 for ; Tue, 5 Feb 2019 10:19:19 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id 64so1837591pfr.9 for ; Tue, 05 Feb 2019 10:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5C7Wzh1W2jkgNal52qiy3718jGsLLm53TwMcxaUG1jI=; b=q2kGLaBq55xRiugKR0/C+IeJgryuM8x9QjCIwd9nUEJjLXqemV630s+BNKPp5vXvDK mDwNS0BNbb4vJdUGgM1pW/cjMqpFWjJhu7j2MxOXDTm2dVkMw+bJ/lPfxQQz3xxDt01H dFuQBnIcsLx3wc0z0Kh+vV+15skhOAB4QxLCChKd5iy1Wq/wWdyzUs2UrMYaFMR2U8zb mR2ENhScWrQ4pjggIMM7JmZxGGHL8eRnTP3WdvH5xTP4AcHXih6IXWuEFqbJZTcRBtQK 8rYAwYIQBLaud1BAuCShKLT6LfznqPU8sdzUfyDhjDVeYwAQ/4bn8mxLM3DpyCI2ObZa kTDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5C7Wzh1W2jkgNal52qiy3718jGsLLm53TwMcxaUG1jI=; b=S3LUmLTVjU2LTpR9xdAFV2VLf568WZII6d+HV3MZo+3Fwedq8kpjNppvJJ5zUrp2sG QnU9ep6PSJM6EkmmugFIuZTrYHrm2cr6zm58rhADxbtt+tvE6AQGtoK3YXD0INypHDj7 bAt8txhgaSVWF//zlqgbInHkPbzU7ACsU9FzofvE4DKvXtuNsg2l1oOoAeTlb6QBD7eE DC+P0KcmtTeha5eUU4igLAqKDIjtKOhBNS7lrjtUaSupLl8nqvQ+iB4NutB24mTMrs+Q hCx/GdJw8M8lB6N9cylK90eI55vIckBFb7Qd4qky9O4PuzDKszOcALZ5tPNlqcx0Fz/3 scXg== X-Gm-Message-State: AHQUAuZuc4XRfHqsdLoPX6tc5fqYyggTL/1m6ES71wLbV8mYYZr2f3xz IHm32Q2wedJVuTKv7RrBsTpiL0JTZGI= X-Google-Smtp-Source: AHgI3Ia0+ZXEFkbGFM/uf/Lxu7wWrB2j+kAuFQYpYX9UUl0NC/xluV4LBjLr8c0pqaGpVif6u1nqLg== X-Received: by 2002:a65:6553:: with SMTP id a19mr1321543pgw.267.1549390758510; Tue, 05 Feb 2019 10:19:18 -0800 (PST) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id x186sm5095034pfb.59.2019.02.05.10.19.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 10:19:17 -0800 (PST) Received: by mail-pl1-f181.google.com with SMTP id u18so1846577plq.7; Tue, 05 Feb 2019 10:19:17 -0800 (PST) X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr6476391plb.55.1549390757224; Tue, 05 Feb 2019 10:19:17 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> In-Reply-To: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> From: Roman Shpount Date: Tue, 5 Feb 2019 13:19:06 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Cc: Christer Holmberg , Simon Perreault , RTCWeb IETF , mmusic WG Content-Type: multipart/alternative; boundary="000000000000b3e5af058129a5d8" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 18:19:27 -0000 --000000000000b3e5af058129a5d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 5, 2019 at 10:03 AM Alan Ford wrote: > If that update was to be made, this goes against the text > in draft-ietf-rtcweb-mdns-ice-candidates-02 which says: > > An ICE agent that supports mDNS candidates MUST support the situation > where the hostname resolution results in more than one IP address. > In this case, the ICE agent MUST take exactly one of the resolved IP > addresses and ignore the others. The ICE agent SHOULD, if available, > use the first IPv6 address resolved, otherwise the first IPv4 > address. > This is obviously not going to work. At the very minimum ICE client should be listening for connectivity checks on all addresses to which FQDN candidate resolves, including IPv4 and IPv6. It also should do connectivity checks to all addresses. Otherwise, if you have two clients, one dual stack and another single stack, they are not going to see each other, since one will be listening and sending connectivity checks via IPv6 and another via IPv4. This is why language about FQDN was removed from mmusic-ice-sip-sdp -- it was broken. For ICE to work, you want to include all possible addresses for FQDN in the candidate list and then proceed with nomination as if they were independent candidates. But there=E2=80=99s a bigger problem here, which is how to cope with an FQD= N is not > resolvable. So the intention, as I understand it, is that when these host > candidates leave the mDNS domain and are thus not resolvable, they will b= e > treated as peer reflexive candidates. > > But at that point there is no address family information available, so ho= w > does an ICE agent know to do pairing with these candidates, which require= s > the address family to be known? > I do not think this is a problem. For peer reflexive candidates, ICE agent knows address family/local address/port where connectivity check was received and the address family/remote address/port from which the connectivity check was received. Everything, including the address family is known in this case and agent can proceed with nomination as with any other peer reflexive candidate. Regards, _____________ Roman Shpount --000000000000b3e5af058129a5d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 5, 2019 at 10:03 AM A= lan Ford <alan.ford@gmail.com= > wrote:
=C2=A0 =C2=A0An ICE agent that su= pports mDNS candidates MUST support the situation
=C2=A0 =C2=A0where the= hostname resolution results in more than one IP address.
=C2=A0 =C2=A0I= n this case, the ICE agent MUST take exactly one of the resolved IP
=C2= =A0 =C2=A0addresses and ignore the others.=C2=A0 The ICE agent SHOULD, if a= vailable,
=C2=A0 =C2=A0use the first IPv6 address resolved, otherwise th= e first IPv4
=C2=A0 =C2=A0address.
=C2=A0
This is obviously not going to work. At the very min= imum ICE client should be listening for connectivity checks on all addresse= s to which FQDN candidate resolves, including IPv4 and IPv6. It also should= do connectivity checks to all addresses. Otherwise, if you have two client= s, one dual stack and another single stack, they are not going to see each = other, since one will be listening and sending connectivity checks via IPv6= and another via IPv4. This is why language about FQDN was removed from mmu= sic-ice-sip-sdp -- it was broken.

For ICE to work,= you want to include all possible addresses for FQDN in the candidate list = and then proceed with nomination as if they were independent candidates.

But there=E2=80=99s= a bigger problem here, which is how to cope with an FQDN is not resolvable= . So the intention, as I understand it, is that when these host candidates = leave the mDNS domain and are thus not resolvable, they will be treated as = peer reflexive candidates.

But at that point there= is no address family information available, so how does an ICE agent know = to do pairing with these candidates, which requires the address family to b= e known?

I do not think t= his is a problem. For peer reflexive candidates, ICE agent knows address fa= mily/local address/port where connectivity check was received and the addre= ss family/remote address/port from which the connectivity check was receive= d. Everything, including the address family is known in this case and agent= can proceed with nomination as with any other peer reflexive candidate.

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000b3e5af058129a5d8-- From nobody Tue Feb 5 11:53:06 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B125313121D for ; Tue, 5 Feb 2019 11:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.852 X-Spam-Level: X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=eZKvO9v5; dkim=pass (1024-bit key) header.d=ericsson.com header.b=l7/zh4OK 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 GyMgWFPcnGEP for ; Tue, 5 Feb 2019 11:52:55 -0800 (PST) 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 683E213121E for ; Tue, 5 Feb 2019 11:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549396371; x=1551988371; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=83GZQUo+GG+MWYiQbd7fU6xg635/scO/IaMIJnlZh80=; b=eZKvO9v5fHlc7Pxqa54BGHh4y8NVRYDZOQJ9TN+5ljQiq6KQBdw149UN6OnUjcuM Hd59Q2fsPmv+7jadLQ4uJ9UcN1Ji9+gQLWfs+z6QQEOxZWVaN3mRUVkSwOKuPkn5 O73bppbyB1keB2AjJrxFjuejLgTpsy6YMpWN/lXQlZA=; X-AuditID: c1b4fb30-f93ff7000000355c-e3-5c59e993a91f Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0B.6B.13660.399E95C5; Tue, 5 Feb 2019 20:52:51 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Feb 2019 20:52:50 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 5 Feb 2019 20:52:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=83GZQUo+GG+MWYiQbd7fU6xg635/scO/IaMIJnlZh80=; b=l7/zh4OKHlqUMquWoxlcgdM4wSmH5vPnVLoNv+Kj2e4IYBS0dCi+gBlQTpFQ1V/9kXkolmeE3hc1dO8vx+AA3fidpK6iRUMvauP5vodxlhc4As1eTQBV11Ul6t4C24yQHpCXIWrH5xLSYChMDdwApnJmYhqlqMmLaB6Bu0QPhSg= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3098.eurprd07.prod.outlook.com (10.170.244.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.14; Tue, 5 Feb 2019 19:52:49 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.016; Tue, 5 Feb 2019 19:52:49 +0000 From: Christer Holmberg To: Alan Ford , Roman Shpount CC: Simon Perreault , RTCWeb IETF , mmusic WG Thread-Topic: [MMUSIC] [rtcweb] What goes into c= line address when FQDN is used for the default candidate? Thread-Index: AQHUvWQJ5AXujZ/OCkayq1rv1scozqXRnTFt Date: Tue, 5 Feb 2019 19:52:48 +0000 Message-ID: References: <874l9ousuk.fsf@hobgoblin.ariadne.com> , <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> In-Reply-To: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [87.93.22.227] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3098; 6:7yH1A2AwzUDzFMxlPqDbixEaPBvS4dbXiwoxb6L4UAJBHAl1o+SaSvhP1fo5EWgFqf7H3Qsb8XfUxp20aAOQ7HvDRm3zyT5lYDDvqTW/2pidXxxUYLdopiizx9sOoHTlu73C/MuqfOmU98i0oxh4IHuroiHkZLkwO74NTsjjW+HHvHQw+0w9vewqKstzBWFYrMRGEMIgpW31/2YM32H7/mA9IjYCrlmupbEetNKZ4bbgdPVR+oesCyL+G+rZTvGLPVQAkZIVD+G9ct5oGaWmgS9FYityKWrMLgVqgBXCu2vBYmUSMtyWTschnTAgZOGH59wmsohIkpucLVMAiCST180IZRFx1x3Pgm+7QWuVUXpNPq7R8JsW3/uslmgTUzLDg8IchONEqh638hHmvnBC+HkW8MhyjoNop1XF2zmNTxRF6Gcjp7BcNxbdJcXAzzVYuyo5J3iA5iIFFam2pswxHQ==; 5:jYSbY3kbci3ap5zF5XKlYTbEVYpTe1r8hNMfI9FYzOsmTFCv1iOp/wi1BPYELSWktWrxKMR1nPFos1D+qaX7GG+3gendjlZ235vG08bnlRCs3hQKBOGmFr37Em3/JiILBPDkswHXnuNufJiAHZiIXIYftBhqyazWOwqJFNwM5VuS70cx0OJlznJvL4sCKYPclB8N4RuKraxazQGtBrWTzQ==; 7:eZ6+eeLOhpb4mqIbEMoOp3LoJY9YVMIiuqqhp7lPyFoMsp70DLtC0220I23nJLT7xtKVpgXdHHJYjI8veLr3GkU8cbztNk0d5PlXFdXUBnK6UZxwQb68BwTNovS8Krt6aN08LyQ+D6X3/7HbQZKlng== x-ms-office365-filtering-correlation-id: e8e6c23b-7d62-4011-3628-08d68ba381a8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3098; x-ms-traffictypediagnostic: HE1PR07MB3098: x-microsoft-antispam-prvs: x-forefront-prvs: 0939529DE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(366004)(39860400002)(346002)(189003)(199004)(54896002)(6306002)(66066001)(3846002)(9686003)(4326008)(7736002)(14454004)(97736004)(478600001)(6116002)(93886005)(236005)(606006)(19627405001)(966005)(8936002)(6506007)(53546011)(102836004)(71200400001)(71190400001)(81166006)(186003)(26005)(99286004)(7696005)(76176011)(446003)(110136005)(54906003)(11346002)(476003)(105586002)(2906002)(106356001)(1015004)(316002)(55016002)(6436002)(33656002)(81156014)(8676002)(68736007)(6606003)(25786009)(486006)(229853002)(14444005)(53936002)(6246003)(44832011)(74316002)(256004)(5070765005)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3098; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: if4/YqnPkSxO6JnmfTqTu7wIiSUPd/BisBhjPQ4qFLsHT8LipF+5fgSN+0qyqZS9ysumat0dhZJAi92f6EWpqVFYUxKzqHsouQAO6OKGLYJxklM1W5Xz2jN8yPXFRfSYJOdzgFGWHKnuyIGIO+gJlOSXXsGaDbZ9MtuCuOW1ov4l6sLI5EbD4Mynby+VzPz1fDuuy+Wive+0jTEcwrYu4JudEZ4i4uZJK+/ZqSd+YR3ecJGdzQMdVUj8jSdCaihhOulsrlQVFoTvjy4wZJUYmjQmXefkY/A8Kv0kBnY/v2PRWcgh3HD2g0YdQj8KTVdZ4Asv7RGr4Y+c8V2g3c/t4zqYwhJKgKYY0wZKV7bRhCxOnGpbUpdLBC/iKqhxJT5LsriXAi6ND70q9JbaiH6/PGN611UiFZoYggw+xZ8ng44= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161A360F1C281127CCFDCF5936E0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e8e6c23b-7d62-4011-3628-08d68ba381a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2019 19:52:48.9307 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3098 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURzGO3vf7X23Gh2Xlz9aGkMMpk6TyH3QSAixRChLyBjoytcL6pS9 yzIJLFrJVqapeMlbuTLNC4qikk4dRuqHrBCvdBGnsso+VBaWjJzHwG+///95Hp5zDoelZFah J5um1XM6rSZDLpLQled7+MASe7w6+M9DH1XT62eUqqxxkVZVvCmjVK2OO4xqejLuuDCqr+o9 E2U2rwuiHNVLVNRcafZp+oIkLInLSMvhdEHHEiWptnYTlV14G13tthiYfFStMyIxC/gIFHbc p41IwsrwCILJXpOIDGsI7IaebaVBAK+GChjnQOMiCl6slCBnXoZLNpWlcOJaQDBjKdvMs6wI q8Dk8Hd6XHEklCwXipxM4RRw1C1TTt6HM2BlsI0mnkyo6cpHhEOg7Vu9wMk09oWG1o2trBSr wVhajUiXkYXRKQvl7BLjcDD/iHF6EHaH3+MtAtLlAXO2OgG5JwZz/wRF2A3siw4h8WtgsPnT 9v4gdAwZt/kAvKszbXUBvsnA1MQSQ4QYKF+1MUSYRWCZeykkggJsH0YQ4XSoqm3eDuyH3r5h AQlUi8B07zNNno6DxlYDKkIBVTtOSzgL2isMWyzFLjBWaaPJXgkzZaUiwv7w9NEXinAgVDis 9M59PWKakRvP8RczU0JClJwu7RLPZ2mVWk7fiTZ/1nDX3+BeZF+JsCLMIvkeafJCvFom1OTw uZlWBCwld5UGdG+upEma3GucLitBdzmD463Ii6XlHtINmYtahlM0ei6d47I53X9VwIo985H7 oY95EcrkaPVaXXfigH9I1620rKkAa//uk8Vva/amd5oTUq94N6zHjo+f8CoIHms7lSebFuZm 3/UK/uqj0M+Ieov9EgZWj7cZXH3jQr2bciXu2G/Ucr1/17nHz+fFQd9r51vOzoau/kJnmOjy By1hlQk3fi5KAmqeKMyRsYr4o3KaT9UcVlA6XvMPL+LiP1UDAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 19:52:57 -0000 --_000_HE1PR07MB3161A360F1C281127CCFDCF5936E0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >If that update was to be made, this goes against the text in draft-ietf-rt= cweb-mdns-ice- >candidates-02 which says: > > An ICE agent that supports mDNS candidates MUST support the situation > where the hostname resolution results in more than one IP address. > In this case, the ICE agent MUST take exactly one of the resolved IP > addresses and ignore the others. The ICE agent SHOULD, if available, >use the first IPv6 address resolved, otherwise the first IPv4 address. This is what I have previously commented. The text needs to be modified. Regards, Christer On 1 Feb 2019, at 21:06, Roman Shpount > wrote: In this case section 4.1 of ice-sip-sdp should be updated to allow FQDN in = connection-address and, perhaps specify that FWDN which return multiple res= ults should be ignored. Would this work for everyone? Regards, _____________ Roman Shpount On Fri, Feb 1, 2019 at 4:02 PM Christer Holmberg > wrote: I have no problem with allowing FQDNs - as long as they result in a SINGLE = address:port. If we want to define ICE usage of FDNSs resulting in MULTIPLE addresses:por= ts, I really think that should be a separate document - it should NOT be ad= ded as a last minute thing to draft-ice-sip-sdp. ...and, yes, perhaps such work would also affect 8445. Regards, Christer ________________________________ From: rtcweb > on b= ehalf of Roman Shpount > Sent: Friday, February 1, 2019 10:22 PM To: Justin Uberti Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when FQDN i= s used for the default candidate? On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti > wrote: This has all been discussed at length in rtcweb and I don't think any signi= ficant changes are needed, although I tend to think that we should restore = the removed FQDN text from mmusic-ice-sip-sdp, which is the only thing not = in alignment at this point in time. I agree that FQDN should be put back into connection-address definition, bu= t the portion which talks about handling it is completely broken.. Quoting 5245: : is taken from RFC 4566 [RFC4566]. It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully qualified domain names (FQDNs). When parsing this field, an agent can differentiate an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with IP address versions that are not supported or recognized. An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. In that case, when receiving an offer or answer containing an FQDN in an a=3Dcandidate attribute, the FQDN is looked up in the DNS first using an AAAA record (assuming the agent supports IPv6), and if no result is found or the agent only supports IPv4, using an A. If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing. I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here.. The only options we have here are: a. Fix FQDN connection address handling. Probably the most logical way of d= ealing with this would be to specify that candidate with FQDN should be con= verted as a result of DNS resolution into multiple candidates, with each ca= ndidate corresponding to A or AAAA record in DNS query result. We will also= need to specify how FQDN candidate gets applied to c=3D line address. Some= thing that says IN IP4 FQDN, if any A records exist for this DNS name and I= N IP6 FQDN if only AAAA records exist. Once candidate is nominated, address= family in c=3D line should match address family used for communications. T= his will definitely require a lot more work and discussion. b. Specify that FQDN connection addresses should be ignored until their han= dling is defined in a future specification. This seems easy and only requir= es a sentence or two to fix. Regards, _____________ Roman Shpount _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_HE1PR07MB3161A360F1C281127CCFDCF5936E0HE1PR07MB3161eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

>If th= at update was to be made, this goes against the text in draft-ietf-rtc= web-mdns-ice-
>candi= dates-02 which says:
>
>  An ICE = agent that supports mDNS candidates MUST support the situation
>   where the hostname resolution results in more than one IP = address.
>  In this case, the ICE agent MUST take exactly one of the re= solved IP
>  addresses and ignore the others.  The ICE agent SHOULD= , if available, 
>use the first = IPv6 address resolved, otherwise the first IPv4 address.<= /font>

This is what I have previously commented. The text needs to be modifie= d.

Regards,

Christer



On 1 Feb 2019, at 21:06, Roman Shpount <= roman@telurix.com> wrote:

In this case section 4.1 of ice-sip-sdp should be updated = to allow FQDN in connection-address and, perhaps specify that FWDN which re= turn multiple results should be ignored.

Would this work for everyone?

Regards,
_____________
Roman Shpount


On Fri, Feb 1, 2019 at 4:02 PM Chri= ster Holmberg <christer.holmberg= @ericsson.com> wrote:
I have no problem with allowing FQDNs - as long as they result in a SI= NGLE address:port.

If we want to define ICE u= sage of FDNSs resulting in MULTIPLE addresses:ports, I really think that sh= ould be a separate document - it should NOT be added as a last minute thing= to draft-ice-sip-sdp.

...and, yes, perhaps such = work would also affect 8445.

Regards,

Christer





From: rtcweb &l= t;rtcweb-bounces@ietf.or= g> on behalf of Roman Shpount <roman@telurix.com>
Sent: Friday, February 1, 2019 10:22 PM
To: Justin Uberti
Cc: Simon Perreault; Dale R. Worley; RTCWeb IETF; mmusic WG
Subject: Re: [rtcweb] [MMUSIC] What goes into c=3D line address when= FQDN is used for the default candidate?
 
= On Fri, Feb 1, 2019 at 2:39 PM Justin Uberti <juberti@googl= e.com> wrote:
This has all been discussed at length in rtcweb and I don'= t think any significant changes are needed, although I tend to think that w= e should restore the removed FQDN text from mmusic-ice-sip-sdp, which is th= e only thing not in alignment at this point in time.

I agree that FQDN should be put back into connection-address definitio= n, but  the portion which talks about handling it is completely broken= ..

Quoting 5245:
   <connection-address>: =
 is taken from RFC 4566 [RFC4566].  It i=
s the=0A=
      IP address of the candidate, allowing for IPv4 addresses, IPv6=0A=
      addresses, and fully qualified domain names (FQDNs).  When par=
sing=0A=
      this field, an agent can differentiate an IPv4 address and an IPv6=0A=

      address by presence of a =
colon in its value - the presence of a=0A=
      colon indicates IPv6.  An agent MUST ignore candidate lines that=0A=
      include candidates with IP address versions that are not supported=0A=
      or recognized.  An IP address SHOULD be used, but an FQDN MAY be=0A=
      used in place of an IP address.  In that case, when receiving an=0A=
      offer or answer containing an FQDN in an a=3Dcandidate attribute,=0A=
      the FQDN is looked up in the DNS first using an AAAA record=0A=
      (assuming the agent supports IPv6), and if no result is found or=0A=
      the agent only supports IPv4, using an A.  If the DNS query=0A=
      returns more than one IP address, one is chosen, and then used for=0A=
      the remainder of ICE processing.=0A=

I think it was discussed in quite a detail why using a random DNS resolutio= n result is not going to work here..

The only options we have here are:

a. Fix FQDN connection address handling. Probably the most logical way= of dealing with this would be to specify that candidate with FQDN should b= e converted as a result of DNS resolution into multiple candidates, with ea= ch candidate corresponding to A or AAAA record in DNS query result. We will also need to specify how FQDN = candidate gets applied to c=3D line address. Something that says IN IP4 FQD= N, if any A records exist for this DNS name and IN IP6 FQDN if only AAAA re= cords exist. Once candidate is nominated, address family in c=3D line should match address family used for communica= tions. This will definitely require a lot more work and discussion.

b. Specify that FQDN connection addresses should be ignored until thei= r handling is defined in a future specification. This seems easy and only r= equires a sentence or two to fix.

Regards,
_____________
Roman Shpount
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--_000_HE1PR07MB3161A360F1C281127CCFDCF5936E0HE1PR07MB3161eurp_-- From nobody Tue Feb 5 16:57:39 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEE2128CF2 for ; Tue, 5 Feb 2019 16:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.642 X-Spam-Level: X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi5Wg-mjbLdG for ; Tue, 5 Feb 2019 16:57:34 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 69891128CE4 for ; Tue, 5 Feb 2019 16:57:34 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id c9so2513013itj.1 for ; Tue, 05 Feb 2019 16:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lNMNPz7PRH05KqR1BtjFReUSJ13QsK6ioyH3/IOKo8I=; b=PD3odNS/vMaV7fw0lM1XAXLDXgDXcKJ9UKN9Nb27broQDfANTcBuJWgJC5vSsp9Qn5 IQCbmjs2Pt8tvQ5cK1pgIAYr+Y+nXdiI/3ejPMSf4EP8hduvbmEQFkCGNfpf1H+OLZOX /DT4wbPrbX43bE5dRNI6Q84JIm1H4UG1x9zNE4M28iy/FAjOKWfYWaB8mDaVRng6KWfl 0Fw89HN3LmUHEVHBDSxE2KP8BoWp6z2CA8kL//CfB062ZFTQYGzbAAsGZq1WazRccpZH Q4CCW+qwz4RnmCsMzIEX0IyEVmKV+rDZV0EBKthh4QTJnTJ6Sft0pnycEwEW58QQ+2W+ qkKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lNMNPz7PRH05KqR1BtjFReUSJ13QsK6ioyH3/IOKo8I=; b=lTzXCYJ/qJ0SzYPmlv4HCaE0xlI/rAQqvD+LAUCffkXD/HPzGaPXpcJ0OBss0LsAE8 Io/4dkV4brc6z0gKc2oie7ydv5mTvPje7e+KDCQsScPPKlE2z3yQEiwMyu1x6TgCWNum ehG4aef33+LXPwyWLBOtBU8dZpDQqLG0yML1CenFOauiCl6g7ucqPiZjj8P83OfVPgtc GPqXfF3vlOOSj1cYtf7Ub4e3N0t5ie5ze94GUMw9HwXcsLHVIF7hGNzdF3Ovg3z+lXGI g0KbZwy/qghpOaxOarpq1/boByo6S8vpWt4XTka4F7pp/uwc0vASFOxGyp1nO8JM9zsC tkEQ== X-Gm-Message-State: AHQUAuaoCJisq+N7/PWPfQ0miG2DAsbnrBwL5bAI0jR1XJaqkebXGJ2C TyPHYXzLZhzmcurJqGK47pO24FDFYLwhkqLJPxNLkQ== X-Google-Smtp-Source: AHgI3IaWIHlB7CyCoa2uXbZJ7nldnvnd9Y/GvURh7kRmvfxzK/dS2JICWODU5lMpHrFBWQkfgIjFj1zdd1IUhZ+1nE8= X-Received: by 2002:a24:738f:: with SMTP id y137mr897186itb.136.1549414653359; Tue, 05 Feb 2019 16:57:33 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> In-Reply-To: From: Justin Uberti Date: Tue, 5 Feb 2019 16:57:21 -0800 Message-ID: To: Roman Shpount Cc: Alan Ford , Simon Perreault , RTCWeb IETF , mmusic WG , Christer Holmberg Content-Type: multipart/alternative; boundary="0000000000000667ea05812f360e" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 00:57:37 -0000 --0000000000000667ea05812f360e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 5, 2019 at 10:19 AM Roman Shpount wrote: > On Tue, Feb 5, 2019 at 10:03 AM Alan Ford wrote: > >> If that update was to be made, this goes against the text >> in draft-ietf-rtcweb-mdns-ice-candidates-02 which says: >> >> An ICE agent that supports mDNS candidates MUST support the situation >> where the hostname resolution results in more than one IP address. >> In this case, the ICE agent MUST take exactly one of the resolved IP >> addresses and ignore the others. The ICE agent SHOULD, if available, >> use the first IPv6 address resolved, otherwise the first IPv4 >> address. >> > > This is obviously not going to work. At the very minimum ICE client shoul= d > be listening for connectivity checks on all addresses to which FQDN > candidate resolves, including IPv4 and IPv6. It also should do connectivi= ty > checks to all addresses. Otherwise, if you have two clients, one dual sta= ck > and another single stack, they are not going to see each other, since one > will be listening and sending connectivity checks via IPv6 and another vi= a > IPv4. This is why language about FQDN was removed from mmusic-ice-sip-sdp > -- it was broken. > > For ICE to work, you want to include all possible addresses for FQDN in > the candidate list and then proceed with nomination as if they were > independent candidates. > I don't think this is correct behavior, but it's really beside the point since we can ignore it if we have the one-FQDN-per-address concept we discussed. > > But there=E2=80=99s a bigger problem here, which is how to cope with an F= QDN is >> not resolvable.. So the intention, as I understand it, is that when thes= e >> host candidates leave the mDNS domain and are thus not resolvable, they >> will be treated as peer reflexive candidates. >> >> But at that point there is no address family information available, so >> how does an ICE agent know to do pairing with these candidates, which >> requires the address family to be known? >> > > I do not think this is a problem. For peer reflexive candidates, ICE agen= t > knows address family/local address/port where connectivity check was > received and the address family/remote address/port from which the > connectivity check was received. Everything, including the address family > is known in this case and agent can proceed with nomination as with any > other peer reflexive candidate. > Right - this is implemented today in Chrome and appears to be working well so far (with a few minor bugs discovered along the way). --0000000000000667ea05812f360e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Feb 5, 2019 at 10:19 AM Roman Shp= ount <roman@telurix.com> wro= te:
On Tue, Feb 5, 2019 at 10:03 AM Alan Ford <alan.ford@gmail.com&g= t; wrote:
If that update was to be made, this g= oes against the text in=C2=A0draft-ietf-rtcweb-mdns-ice-candidates-02 which= says:

=C2=A0 =C2=A0An ICE agent that supports mDNS candidates MUST support the= situation
=C2=A0 =C2=A0where the hostname resolution results in more th= an one IP address.
=C2=A0 =C2=A0In this case, the ICE agent MUST take ex= actly one of the resolved IP
=C2=A0 =C2=A0addresses and ignore the other= s.=C2=A0 The ICE agent SHOULD, if available,
=C2=A0 =C2=A0use the first = IPv6 address resolved, otherwise the first IPv4
=C2=A0 =C2=A0address.
=C2=A0
This is obviously= not going to work. At the very minimum ICE client should be listening for = connectivity checks on all addresses to which FQDN candidate resolves, incl= uding IPv4 and IPv6. It also should do connectivity checks to all addresses= . Otherwise, if you have two clients, one dual stack and another single sta= ck, they are not going to see each other, since one will be listening and s= ending connectivity checks via IPv6 and another via IPv4. This is why langu= age about FQDN was removed from mmusic-ice-sip-sdp -- it was broken.=C2=A0<= /div>

For IC= E to work, you want to include all possible addresses for FQDN in the candi= date list and then proceed with nomination as if they were independent cand= idates.

I don't think= this is correct behavior, but it's really beside the point since we ca= n ignore it if we have the one-FQDN-per-address concept we discussed.=C2=A0=

But there=E2=80=99s a bigger probl= em here, which is how to cope with an FQDN is not resolvable.. So the inten= tion, as I understand it, is that when these host candidates leave the mDNS= domain and are thus not resolvable, they will be treated as peer reflexive= candidates.

But at that point there is no address= family information available, so how does an ICE agent know to do pairing = with these candidates, which requires the address family to be known?
=

I do not think this is a probl= em. For peer reflexive candidates, ICE agent knows address family/local add= ress/port where connectivity check was received and the address family/remo= te address/port from which the connectivity check was received. Everything,= including the address family is known in this case and agent can proceed w= ith nomination as with any other peer reflexive candidate.

Right - this is implemented today in Chro= me and appears to be working well so far (with a few minor bugs discovered = along the way).=C2=A0
--0000000000000667ea05812f360e-- From nobody Tue Feb 5 17:04:02 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C53128BCC for ; Tue, 5 Feb 2019 17:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 K5JGAO9nqm4v for ; Tue, 5 Feb 2019 17:03:52 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFA5128CE4 for ; Tue, 5 Feb 2019 17:03:51 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id 64so2322270pfr.9 for ; Tue, 05 Feb 2019 17:03:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Em3bFbsX//W0Sbg5kR97WtfmM4E8TdthFeA1COv7/M=; b=OjgybrdQ4n2tBv7vlzIUvP4YxB+jPWVV+uMxYIObn+J2eFiog/X+Fl6nNNJcpzvN0t pc3uEw8Xv2RbNfOb7dExvnasmgi+KKSfIOGLMD7N27IEr6x6NIfbVGfDNz1U3SNhv5iS SwmJ/IpYrqpnR/wy/zY5eza+F3GogwpSffyrT3K2rNC+hXtnpLJ7+ZMns67MDu8pRKCK dbExuNkm42iLQjwuiTSwRo8imto089CmuNZxLYkDDyO7G9w15SqiHMr8ruhbQiLDUkZW 9KCAgsrroW6Jz3GlVjsF03PnyuxuuyCa5ejwJNIjbNLLwQ/ljXb/ee5NeIQ+CB+SADnH 2xeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Em3bFbsX//W0Sbg5kR97WtfmM4E8TdthFeA1COv7/M=; b=B+HrvkiNfmeqyyHAzfls/RvXoqd02YMEaAOlcKJIyS4hvf3w7c7y+KcAcJ3euGpNy0 MpMkxN16Gk1jfIC/sRi79sXMOWFPlMejuz/2b5gT2W+ifIAgDy9olITdg3Vv8wa7n8S5 djO2GF2fnTLJkGfocdAYXMd92B/lsoI7pz4RMgX4uY8918lO+pvmUb/u3Fl2r/+p6orE aN5W4VFlJnKENUg3cv5pNyjfK/nfKdHdeO0oXicm92yCRKszH9NmHpJzqh4dvhs5MYmj Z96QSctl6Pf2TIrJo2z9EoaWk35aG+qt7wvtJDZk3HQ4hgsN3LfDcu8IvU8q/TACzDRu aq5g== X-Gm-Message-State: AHQUAubsE9sjSJTTPU5GmKkufS0POlT+ZbctB0ihPQUubrv3aAVYR7ed +JNwqr+ivw8zbUW5PHkCh5MAzOk211Q= X-Google-Smtp-Source: AHgI3IZX9oQlDlfObI3BxDjPQw7/0B0G3HJoItKmLUVWvezPtZ29gt1aWv1Zylq0UebxJTrLcmGKIw== X-Received: by 2002:a62:1f9d:: with SMTP id l29mr7862664pfj.14.1549415030617; Tue, 05 Feb 2019 17:03:50 -0800 (PST) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com. [209.85.210.173]) by smtp.gmail.com with ESMTPSA id m67sm6878069pfb.25.2019.02.05.17.03.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Feb 2019 17:03:49 -0800 (PST) Received: by mail-pf1-f173.google.com with SMTP id 64so2322239pfr.9; Tue, 05 Feb 2019 17:03:49 -0800 (PST) X-Received: by 2002:a63:5861:: with SMTP id i33mr7215522pgm.60.1549415028850; Tue, 05 Feb 2019 17:03:48 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> In-Reply-To: From: Roman Shpount Date: Tue, 5 Feb 2019 20:03:38 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Alan Ford , Simon Perreault , RTCWeb IETF , mmusic WG , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000067873705812f4c36" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 01:03:55 -0000 --00000000000067873705812f4c36 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 5, 2019 at 7:57 PM Justin Uberti wrote: > > On Tue, Feb 5, 2019 at 10:19 AM Roman Shpount wrote: > >> On Tue, Feb 5, 2019 at 10:03 AM Alan Ford wrote: >> >>> If that update was to be made, this goes against the text >>> in draft-ietf-rtcweb-mdns-ice-candidates-02 which says: >>> >>> An ICE agent that supports mDNS candidates MUST support the situation >>> where the hostname resolution results in more than one IP address. >>> In this case, the ICE agent MUST take exactly one of the resolved IP >>> addresses and ignore the others. The ICE agent SHOULD, if available, >>> use the first IPv6 address resolved, otherwise the first IPv4 >>> address. >>> >> >> This is obviously not going to work. At the very minimum ICE client >> should be listening for connectivity checks on all addresses to which FQDN >> candidate resolves, including IPv4 and IPv6. It also should do connectivity >> checks to all addresses. Otherwise, if you have two clients, one dual stack >> and another single stack, they are not going to see each other, since one >> will be listening and sending connectivity checks via IPv6 and another via >> IPv4. This is why language about FQDN was removed from mmusic-ice-sip-sdp >> -- it was broken. >> > >> For ICE to work, you want to include all possible addresses for FQDN in >> the candidate list and then proceed with nomination as if they were >> independent candidates. >> > > I don't think this is correct behavior, but it's really beside the point > since we can ignore it if we have the one-FQDN-per-address concept we > discussed. > I am not sure why this is wrong, but I agree this is besides the point if we agree on one-FQDN-per-address. If we agree on one-FQDN-per-address, rtcweb-mdns-ice-candidates needs to be modified to match. Behavior currently described there (each sides picks an address in random) is definitely wrong. Regards, _____________ Roman Shpount --00000000000067873705812f4c36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 5, 2019 at 7:57 PM Ju= stin Uberti <juberti@google.com> wrote:

On Tu= e, Feb 5, 2019 at 10:19 AM Roman Shpount <roman@telurix.com> wrote:
On Tue, Feb 5, 2019 at 10:03 AM Alan Ford <<= a href=3D"mailto:alan.ford@gmail.com" target=3D"_blank">alan.ford@gmail.com= > wrote:
If that update was to be made, = this goes against the text in=C2=A0draft-ietf-rtcweb-mdns-ice-candidates-02= which says:

=C2=A0 =C2=A0An ICE agent that supports mDNS candidates MUST sup= port the situation
=C2=A0 =C2=A0where the hostname resolution results in= more than one IP address.
=C2=A0 =C2=A0In this case, the ICE agent MUST= take exactly one of the resolved IP
=C2=A0 =C2=A0addresses and ignore t= he others.=C2=A0 The ICE agent SHOULD, if available,
=C2=A0 =C2=A0use th= e first IPv6 address resolved, otherwise the first IPv4
=C2=A0 =C2=A0add= ress.
=C2=A0
This is o= bviously not going to work. At the very minimum ICE client should be listen= ing for connectivity checks on all addresses to which FQDN candidate resolv= es, including IPv4 and IPv6. It also should do connectivity checks to all a= ddresses. Otherwise, if you have two clients, one dual stack and another si= ngle stack, they are not going to see each other, since one will be listeni= ng and sending connectivity checks via IPv6 and another via IPv4. This is w= hy language about FQDN was removed from mmusic-ice-sip-sdp -- it was broken= .=C2=A0

For ICE to work, you want to include all possible addresses for FQDN in t= he candidate list and then proceed with nomination as if they were independ= ent candidates.

I don'= ;t think this is correct behavior, but it's really beside the point sin= ce we can ignore it if we have the one-FQDN-per-address concept we discusse= d.=C2=A0

I am not sur= e why this is wrong, but I agree this is besides the point if we agree on o= ne-FQDN-per-address. If we agree on one-FQDN-per-address, rtcweb-mdns-ice-c= andidates needs to be modified to match. Behavior currently described there= (each sides picks an address in random) is definitely wrong.
Regards,
_____________
Roman Shpount
=C2=A0
--00000000000067873705812f4c36-- From nobody Thu Feb 7 08:01:24 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4B5126D00 for ; Thu, 7 Feb 2019 08:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pkZvWW2AmDk for ; Thu, 7 Feb 2019 08:01:20 -0800 (PST) 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 663FA12008F for ; Thu, 7 Feb 2019 08:01:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6BE7E7C3BBE for ; Thu, 7 Feb 2019 17:01:18 +0100 (CET) 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 hV8nTvJBdD7Z for ; Thu, 7 Feb 2019 17:01:16 +0100 (CET) Received: from [192.168.3.17] (unknown [188.113.75.166]) by mork.alvestrand.no (Postfix) with ESMTPSA id 99C877C0C58 for ; Thu, 7 Feb 2019 17:01:16 +0100 (CET) To: rtcweb@ietf.org References: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> From: Harald Alvestrand Openpgp: preference=signencrypt Autocrypt: addr=harald@alvestrand.no; prefer-encrypt=mutual; keydata= xsFNBFRpbhYBEADXu8uE7LDQgrEB/zclYiwWRb50FnuJjIdK5Q7t68tSxx+LU8HTfxwOgHo9 vMyQvntoRBOHQZDJzvdAnZj/7vtl9RDfWvhUz+o9jSMyORzrt0kiW2QNICVkOkc0ZbI14Rn8 EjFRinK5m5+PXrng3PwZgK+sQJ1nzUxjE9oGTWClsAEqJw62z7JmzNqaEwAyHoHAZ1JAptSP ak91dUxjueJ2R+rFUBl6ParRZ2de7QKr3rN5Jbu/ikjHsAeTSo0R0BPKbzU23tXXxQ/dADvM V/PZp3hRFmXT7x05Q82O6k6hsGd5fJToBDRrlsC3jwWWhDhFhsWcdYKxFbYUsJVetPrWDtD4 6sjrbsQ+7kWRYgQWvL2EJ0s7QGpLxitopoISUEt0MlCcJhq7ZxiWhGnwM3GgADn+9W+aqwuk Y1tlUbdw0qdHyU0WM0k/yPd/eOghk3PLtlOizg4Q22VqfzNRXd3pwUmVjPYHQS0PwIjzuTEI em03qlVeJ8xn0X9W90E8PEnxZmREZBI90qCcUrxWOywEcLq21eLXurRzwnbY3oi6NxmSedcL xDWFdrVTHfPNNqh8zqXV/z9Ezz+7kSwgRygpG5+/sHfFq/YivoSHJdkL8xDzlNiqYCs8EL4A ipQWlKIuFH1F/pXLmXZlcDExw6aTlAP2rR+rw4Lc7kENZlMMMwARAQABzS9IYXJhbGQgQWx2 ZXN0cmFuZCAoMjAxNCkgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPsLBfgQTAQIAKAUCVO3uHAIb IwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQawFW3omifDRKiA/+KtWpGwNa EaMMjxuVhdvMkQ6cS362iWydVbha03TBf/7HM380nO+2/t4S0kiSRtX89bY9lvrjS5oHd0tZ qS14vwBn8ZKbZl+k/NRiFlNNxhBx1PDRni1lfh/lU4xJraKI17h2h9mVJbMGk0kFuLqDUwMc 18mZZcfJEeUxSVUCndFMab4LQWSvRaqcwGrpDXuCxmWzMxtRjZzS2vkNX0oiBO7/NuEdQZL8 /CM3/GTqEd6kqY5Rkddvhr21KqhDyNT0NYRLgQ4yToTRDeXrHkjDD8cIQJhOHSNm6/3tuHB1 Bunxg1If3oEZxZirTGiuNZfBUAuXXJa//wEqhS+28/iQc6RE4bQXh2TyqtHs1mn3VDeKqbp7 lp31FfQ6GVGUaVfKfhg6UPSeczHTKWG3vX5UL7SOLXyaSniuYDkPIV/YR46GFPNhSsQ9YccU 5zAbn8ZhyONwO7524WjhIHgITiPVnCiSIHQKOw0S3+Ns0/5TIUgEc6+M97vsJTxTOqKfPthj xkHckF7VUFzu9ee6IMupJJp1wxVjpPQpJTjUG2aDnWk+E2OArulIjHER2dj0DEiOuqjjwTQH CKfrsWUMIs6TJ9jIKEfOSVOz5opGKLimQaOJ8Y1NYZKOy7fyJjofcC+dkAIpYBRzQTdDXm0A 4eryQBqLSpRldX4rvnU77i2/ryHOwU0EVGluFgEQAK2r1cmzqfJzOIielYx4OGVWlh3TmGdI mPgYI8yx/W8Uyvwknto7Qm5HaBBy9/33usNiovygYLFr7X5U/+ynXClkpAHaPOzS+bMCybpd UsS9Yq/jPmyq0Tlqn6b1tjSjFwysTiUVRS6nHufRlHQEOyxlYAjmePfjJI85g9J3iOa3eY87 +YSlF/rzhPrlvW0yD1YBGBmtuDdRnd4qSof8pcVmiN91QylbnTO5+/VtQtZydk2couaBHkf+ h0eDlJLB7igJ6Ks0ae2UoUNOBv2F1roQ1jZC8yMPScXygmjsoBSuTUirHatyR7AUiCHNymB+ EdhK4Vl+ZVHdCY9l269g5ocw0y6BZofHpqhE9K3RGBWQjWKTXuOk1fVjLfAum3wQqztYEhlD uKZgfEn7reDuzBq4cqzUe7CI6lZwCU7DnA0Dz2vBaqBhrZb7eKfTqmXddNm/dXmPn1nB554N fxWoxb3L8fHXwLgJiBgxLM6OYhJM51PxwW1qoQM1ax6gu+H101uEE4ZZq+s7c301HqwFwGMi SMmn1oJ7/+OquMkYHjeVAhxRE6blcRH2cmqxFSrpHsHgpXMVyWgTZRZsMmQathzCTUWKf5hC EOzwb4rp/UvU1LUHo1uPqbBafW62VB+iUaFp/zOg69Wo8/Z6urM5m+ldiWTbx+ivxKlPQDEA 332dABEBAAHCwWUEGAECAA8FAlRpbhYCGwwFCQlmAYAACgkQawFW3omifDRKhg//eHcjvxcA ENNe66f5R3ULi5pMbrHGLMGirVX9pHTRf5+5OFaGr8bwXeYkCHpptpxr2Kk/PUzpUWOL2uvL lh7QhPw3+GoEWubXOAgHiQW5iIzkA9wYw/nctZ+5veHN7InVqJ7djhtTN7K9Luj4nDR1T7Vf 61zpCKLlEW6W5MAp4slRVzRiFfaMfMYkxLm6MBxC961j8Lrqx2XNMGugaYh1QzcFYTbFmGKX 5SY4EQsETiB0PeE3IBVtXfiabrk8YX2IuL9BrEgD6GngXTd78hUMnZeqjvnS772bjRgwLCz7 Hab6hQESrFCNXfxzb39y5DLHwXtB/HruYqVD48XvPnNV0UNsWcS+7rtPFMmkd3MTvoAOWjkV zeQHpvF71IlwWginXbkf9aR/QsAbMIQDZWhsd+ma67V6g6KH41r6mNXAgK2JlA1CqgblM7iB hl01vL0V5bkbInZq2sB505Hn1DSc4NoP2WHlwe8Bm8vVG5oyfyPw9ReS9WLVY9w7fK4EKOgk VnOsIQuE0WIPT0Ak+hJ0UigOduuCX7s7NIVaOgWQe1q4Xytgj1RHjg9qlA6eQiTUrAx7Mu7s eliWCFuWsQXoaktVEDjoWVbP9dgozanL5kwWh/sJNtHVQbgu3IG4w8D3QvvOE83+jAdzgOzv pqHJkrqlWu+R9ZqBucZLqjQvQZk= Message-ID: <0fd991e5-73c9-edd2-67e4-2c527ccc6e95@alvestrand.no> Date: Thu, 7 Feb 2019 17:01:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:01:23 -0000 Den 05.02.2019 16:03, skrev Alan Ford: > If that update was to be made, this goes against the text > in draft-ietf-rtcweb-mdns-ice-candidates-02 which says: > >    An ICE agent that supports mDNS candidates MUST support the situation >    where the hostname resolution results in more than one IP address. >    In this case, the ICE agent MUST take exactly one of the resolved IP >    addresses and ignore the others.  The ICE agent SHOULD, if available, >    use the first IPv6 address resolved, otherwise the first IPv4 >    address. > > But there’s a bigger problem here, which is how to cope with an FQDN is > not resolvable. So the intention, as I understand it, is that when these > host candidates leave the mDNS domain and are thus not resolvable, they > will be treated as peer reflexive candidates. > > But at that point there is no address family information available, so > how does an ICE agent know to do pairing with these candidates, which > requires the address family to be known? Peer reflective candidates are identified by means of an incoming packet. The address family is very obvious from the packet. From nobody Thu Feb 7 08:01:49 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4A130EA3 for ; Thu, 7 Feb 2019 08:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 fF35KdDjNoZS for ; Thu, 7 Feb 2019 08:01:27 -0800 (PST) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6846129C6A for ; Thu, 7 Feb 2019 08:01:26 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id z9so129497pfi.2 for ; Thu, 07 Feb 2019 08:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o1g5rkWcKWGEx7n0CudN65EaAdkhaD37UcLCl4jPQ0g=; b=oXsceddh5IRL3aEQRNjvO0NuJTsJzpCpmVHyUupnbgDgYAT6/y1a2fvdMOjb4sQMeD HRNxub2+DVcsVNWfmLEwt2kzxR7tFHNSVcNH7gJCjvn/SVDdolVBj+Wp7LdPuuTlcheI AZqJR+BT9hi/ey3hgTWp3kh0oDhAQ+Kom1v0Elx7O7Lvz4TyHtnkcadOXDir8u1ECt2Z Fxf17cb5mweNo4isJAsWBY70fPYM+lGqiPf6UjOoJ0U0Q6exvhBOP1PI8uMrqttQ0E9A BvnGGDX/g5atp3hQFPOgvZ2ZmWkn4cQxZQpYqQv0sJx6k0t/kmCZNdKywSz9esVN4B26 8Wsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o1g5rkWcKWGEx7n0CudN65EaAdkhaD37UcLCl4jPQ0g=; b=H2YfJBwVvXb+aw8IqgbUi5FZPc+JZQMuWD8wPnXBl+JvAtz/lr0xf87XnwG39B3b+2 kyJzKSRbFR8GKIXheiu3snq2wAdHH2GX6KX4rNaWhfyBHNF46JrrkLpJNuDq64ZyWVAo 7/KAuwP3EY4fpgDZWd8LLlOpXMYo0L8jhG/w8llYlCnx3bgr8qEE8dKpopdbQOJIkSt8 GLMwTM7RMn86TnRsALdMVuC44SE3Anf5jKm6YtM7Szd1oQgM6da7HHeQGqB5RwZEWNfZ 08Zb6ntnfMFvS62psiwWaAZ0rNhePuXWIoOJa1GlMZfG98hH06KnxKX3+MOtMQc1XFP1 aAAg== X-Gm-Message-State: AHQUAubcnHWJSIY5TEoawrYJTexxs+QghZXf/RhuU+wO+RGlVYi1BeJz xPPmfkntQwlHC+5O9YPSEmXs6Q4xIHI= X-Google-Smtp-Source: AHgI3IZsgyonxKiPefey69xfKWvVsQoDJPP25RuR+KSI6Sre+YF+hxltWAXJ7iJGQitGuOHCPOikPA== X-Received: by 2002:a63:2a89:: with SMTP id q131mr11895077pgq.216.1549555286260; Thu, 07 Feb 2019 08:01:26 -0800 (PST) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com. [209.85.215.172]) by smtp.gmail.com with ESMTPSA id v15sm11710316pfn.94.2019.02.07.08.01.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 08:01:25 -0800 (PST) Received: by mail-pg1-f172.google.com with SMTP id d72so107137pga.9; Thu, 07 Feb 2019 08:01:25 -0800 (PST) X-Received: by 2002:a63:db04:: with SMTP id e4mr907773pgg.40.1549555284882; Thu, 07 Feb 2019 08:01:24 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> In-Reply-To: From: Roman Shpount Date: Thu, 7 Feb 2019 11:01:11 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Alan Ford , Simon Perreault , RTCWeb IETF , mmusic WG , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000050c2ff05814ff431" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:01:34 -0000 --00000000000050c2ff05814ff431 Content-Type: text/plain; charset="UTF-8" Hi All, >From what I can see there is a new problem identified during mDNS discussion with using FQDN: If all the candidates are FQDN and these names do not resolve or resolve to more then one address, so all the candidates will end up being ignored. ICE agent might end up with no remote candidates and no candidate pairs to form. I think RFC 8445 does not handle this situation, but I might be missing something. P.S. I am not arguing against FQDN, I am just trying to figure out what needs to be done to get this documented and operational. _____________ Roman Shpount --00000000000050c2ff05814ff431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

<= div dir=3D"ltr">From what I can see there is a new problem identified durin= g mDNS discussion with using FQDN: If all the candidates are FQDN and these= names do not resolve or resolve to more then one address, so all the candi= dates will end up being ignored. ICE agent might end up with no remote cand= idates and no candidate pairs to form. I think=C2=A0 RFC 8445=C2=A0does not handle this situati= on, but I might be missing something.

P.S. I am not ar= guing against FQDN, I am just trying to figure out what needs to be done to= get this documented and operational.=C2=A0
_____= ________
Roman Shpount
--00000000000050c2ff05814ff431-- From nobody Thu Feb 7 08:28:23 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBE31289FA for ; Thu, 7 Feb 2019 08:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.601 X-Spam-Level: X-Spam-Status: No, score=-15.601 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRj1uPM7j0KL for ; Thu, 7 Feb 2019 08:28:20 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 3D3BA1271FF for ; Thu, 7 Feb 2019 08:28:20 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id h193so1108481ita.5 for ; Thu, 07 Feb 2019 08:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZPjsf/7bKO0wyzci99XS0gtw94x6TUjkAtC2V322o7E=; b=IJjpwqx+tuIV+lJK90opMumyIEKgX1H7dOZ5g1gveFEWla/T+477n78HTjA9cYFFUu 99sfNxh9CTw14EAFcq7dhkr0cDnNkXGEZTgUKn/03B5vM72IwejY2oKEUXVNu3Mpi1yd sAbREja75mdgAmwhawneLXgUcQQ+MoSwRz/wPPcsKFEA0DTJwRrE5CJ6C2d/XOEybehw kM6Gk+u40ND0f8k4AsC4PvV7ENIjg++NXu8oZJ/2uP8i7d+rnWbp2RzthCiWwBwF7B9C tM3EPIi8hZNg2dSq5yNWPjloQmOqwaRWNrz+YoLGmS1rXxGq7W1LNiF7KMU/jKq9cGM8 ArbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZPjsf/7bKO0wyzci99XS0gtw94x6TUjkAtC2V322o7E=; b=mxFAKku6HWhBcGkkCVgBn77G8PetJUUi1ZunyJlY7T8QVMe3+Sl9iSlq0qgGuPlOIJ GqOil1pE3J363nrCXue3KLywxkgekJiiGGqOHMRnCw4i0xBPaIYx7x1R+QZlorlvdKHx mlxxeQ+ZXF4G3sHzskb+dkI+TYTYEIICDw73xQIJybZ1jgO2SRCeb9YkBxJY8fNM/2nJ sC82rHLY5ZQtLoAx2jGRRP1t2Ga07i+9kcIl8GDny+BXITKr3i9e7GyPx0HzIX1OrMAs uUxKnbSaPeJDGfVyJDOC2JVkZV53cTlW3D4CekhqaLJh4DmM/ZdmKjP/fYcs7WXw0aQc d1NQ== X-Gm-Message-State: AHQUAuatfUDkT1FNLnKz1xV4DweAjh95jWhIuKmzAFkdS0F6p3+DvNNz FFsomFplYPNBgh+KYcLpAUOdr+/GcfVXPjLfKpYiMKK/CYU= X-Google-Smtp-Source: AHgI3IaYnW3ge+QM9A8bdCJ6WJ1+a6EUnVl4bbidwbhqhbeAPSuLi+lEKW271nIyMct2pzuyT0MXrE2s5XGXmoQ09Zs= X-Received: by 2002:a24:9fc1:: with SMTP id c184mr5347505ite.8.1549556899066; Thu, 07 Feb 2019 08:28:19 -0800 (PST) MIME-Version: 1.0 References: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> <0fd991e5-73c9-edd2-67e4-2c527ccc6e95@alvestrand.no> In-Reply-To: <0fd991e5-73c9-edd2-67e4-2c527ccc6e95@alvestrand.no> From: Justin Uberti Date: Thu, 7 Feb 2019 08:28:06 -0800 Message-ID: To: Harald Alvestrand Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000087e5270581505490" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:28:22 -0000 --00000000000087e5270581505490 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Note also that only host candidates will be mDNS; srflx and relay candidates will continue to work as before. On Thu, Feb 7, 2019 at 8:01 AM Harald Alvestrand wrote: > Den 05.02.2019 16:03, skrev Alan Ford: > > If that update was to be made, this goes against the text > > in draft-ietf-rtcweb-mdns-ice-candidates-02 which says: > > > > An ICE agent that supports mDNS candidates MUST support the situatio= n > > where the hostname resolution results in more than one IP address. > > In this case, the ICE agent MUST take exactly one of the resolved IP > > addresses and ignore the others. The ICE agent SHOULD, if available= , > > use the first IPv6 address resolved, otherwise the first IPv4 > > address. > > > > But there=E2=80=99s a bigger problem here, which is how to cope with an= FQDN is > > not resolvable. So the intention, as I understand it, is that when thes= e > > host candidates leave the mDNS domain and are thus not resolvable, they > > will be treated as peer reflexive candidates. > > > > But at that point there is no address family information available, so > > how does an ICE agent know to do pairing with these candidates, which > > requires the address family to be known? > > Peer reflective candidates are identified by means of an incoming packet. > The address family is very obvious from the packet. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000087e5270581505490 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note also that only host candidates will be mDNS; srflx an= d relay candidates will continue to work as before.=C2=A0



On Thu, Feb 7, 2019 at 8:01 AM Harald Alvestrand <harald@alvestrand.no> wrote:
=
Den 05.02.2019 16:03, skr= ev Alan Ford:
> If that update was to be made, this goes against the text
> in=C2=A0draft-ietf-rtcweb-mdns-ice-candidates-02 which says:
>
> =C2=A0 =C2=A0An ICE agent that supports mDNS candidates MUST support t= he situation
> =C2=A0 =C2=A0where the hostname resolution results in more than one IP= address.
> =C2=A0 =C2=A0In this case, the ICE agent MUST take exactly one of the = resolved IP
> =C2=A0 =C2=A0addresses and ignore the others.=C2=A0 The ICE agent SHOU= LD, if available,
> =C2=A0 =C2=A0use the first IPv6 address resolved, otherwise the first = IPv4
> =C2=A0 =C2=A0address.
>
> But there=E2=80=99s a bigger problem here, which is how to cope with a= n FQDN is
> not resolvable. So the intention, as I understand it, is that when the= se
> host candidates leave the mDNS domain and are thus not resolvable, the= y
> will be treated as peer reflexive candidates.
>
> But at that point there is no address family information available, so=
> how does an ICE agent know to do pairing with these candidates, which<= br> > requires the address family to be known?

Peer reflective candidates are identified by means of an incoming packet. The address family is very obvious from the packet.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000087e5270581505490-- From nobody Thu Feb 7 08:44:09 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D142129284 for ; Thu, 7 Feb 2019 08:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7T7MInE40Qar for ; Thu, 7 Feb 2019 08:44:02 -0800 (PST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05720124BF6 for ; Thu, 7 Feb 2019 08:44:02 -0800 (PST) Received: by mail-pf1-x434.google.com with SMTP id d22so141408pfo.3 for ; Thu, 07 Feb 2019 08:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IoYBOqruYN5tr2PW3ihlq0WKcoh43/9BXT5d+67ueXM=; b=qwe7oUR8zO71XB5JmMCLF2MxQ9dhWs68xzHRLeycslVwxPff2dvRZdqtSxsLey2bAA s+knFGn8uDTO71avCkHWzTusDWRNtZLBCgGpSnmU2jBc1v7JpO9m2Xc5DFQsi96gWw6R ETxkxsBwY+Bro5B3EPOcVXk1bZj0ItXAztiRG5DEYkckAhJHPx6LjK8ux9hf1sa4HkCv FsshdmNfoQzA9YqLjBhTfw6cxs7YrDftqCz5QEmAcMoCvCgCrj6bdApBir5AwK/e4Np2 huIdy/zCQ42AAKcvncGfmAYgarUvROlNTivF6IXN5xPtuLIT9fp6t9mPIhBkULVjNHGz ia2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IoYBOqruYN5tr2PW3ihlq0WKcoh43/9BXT5d+67ueXM=; b=ZzGN6FMUPAnlFg86Ej/drMHU1QvOyI0VYV6URAjzpcqFgGmavG54JKDH7LRIFQtu6w S1W/6JiVTKA7MmX3WQt7fCqSzm+k9ijXhEu5KR+rFN+Ogc/12ldYEtlPyGy1xJXIgkBk 8Hz8akhNe3JNdy0fNiMfs8ivY5DNDVjauCIajTuy9z2awWOlVIpfrSINLZaPscG53QB9 4W71UCqUmQ/Zs2pCvcqPnk+1vS65EDQdRY9RwZCKz+VmHP0fHgbbKC5haoj0bpK4Mk+K WCQApgWlMbziREDHNHnxGnP4/c5eaV4rQ9Kazf81OdyhQhvzfW/rFWduSpEVYKKhZ16T u4dA== X-Gm-Message-State: AHQUAuZEKVm1rJsbS0+bzuDFcYHw9XXepQzihi47z7pqgjl23Y/sVa3R hM+92iZTQPSGAy00RELHks611wXZSVw= X-Google-Smtp-Source: AHgI3IZbpPNwGH6uWenUm/emfpdsG//rx30XLcQOkIpHfXdd+tIR9uQEIbb0fBARXQbJ+5DU2z5Xlg== X-Received: by 2002:a62:29c3:: with SMTP id p186mr17246400pfp.117.1549557841179; Thu, 07 Feb 2019 08:44:01 -0800 (PST) Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com. [209.85.215.173]) by smtp.gmail.com with ESMTPSA id b26sm20189630pfe.91.2019.02.07.08.44.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 08:44:00 -0800 (PST) Received: by mail-pg1-f173.google.com with SMTP id w7so148121pgp.13 for ; Thu, 07 Feb 2019 08:44:00 -0800 (PST) X-Received: by 2002:a62:4bcf:: with SMTP id d76mr17709642pfj.170.1549557840020; Thu, 07 Feb 2019 08:44:00 -0800 (PST) MIME-Version: 1.0 References: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> <0fd991e5-73c9-edd2-67e4-2c527ccc6e95@alvestrand.no> In-Reply-To: From: Roman Shpount Date: Thu, 7 Feb 2019 11:43:47 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Harald Alvestrand , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000009d0c3d0581508c0c" Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:44:04 -0000 --0000000000009d0c3d0581508c0c Content-Type: text/plain; charset="UTF-8" On Thu, Feb 7, 2019 at 11:28 AM Justin Uberti wrote: > Note also that only host candidates will be mDNS; srflx and relay > candidates will continue to work as before. > > If client is running without STUN or TURN servers and communicates with a server on the public IP with UDP and TCP candidates, all the candidates in the client session description will be mDNS. This use case was working without mDNS, but it is broken now, since server ends up with session description with no usable candidates, which means ICE nomination stops before it even begins or any peer reflexive candidates are received. Amusingly, this still works with ICE-lite, since server there will simply wait for connectivity checks while ignoring all the client candidate information. Regards, _____________ Roman Shpount --0000000000009d0c3d0581508c0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb= 7, 2019 at 11:28 AM Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> = wrote:
Note also that only host can= didates will be mDNS; srflx and relay candidates will continue to work as b= efore.=C2=A0


If client= is running without STUN or TURN servers and communicates with a server on = the public IP with UDP and TCP candidates, all the candidates in the client= session description will be mDNS. This use case was working without mDNS, = but it is broken now, since server ends up with session description with no= usable candidates, which means ICE nomination stops before it even begins = or any peer reflexive candidates are received.

Amu= singly, this still works with ICE-lite, since server there will simply wait= for connectivity checks while ignoring all the client candidate informatio= n.

Regards,
_____________
Roman Shpount
=C2= =A0
--0000000000009d0c3d0581508c0c-- From nobody Thu Feb 7 08:44:49 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ADE124BF6; Thu, 7 Feb 2019 08:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLjvombKQcmh; Thu, 7 Feb 2019 08:44:38 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 19FA51292F1; Thu, 7 Feb 2019 08:44:38 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id z13so349157lfe.11; Thu, 07 Feb 2019 08:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TiK8Nzc06AQ1Yx6Hpz1jW+UZ+keiCasr59vYPP087zs=; b=lW6ElDmmQL+BRcK3WhRYbhNT1+/Z6029aDIlnwcSMip/PzgMJZCkH5oikPlGrcDlCS 4Eh40ChHbGPqeFsuUaMdz1oyICi1fpI4KcJN7jy4ioGQDGLeyD0P71TsRhRBFCd5Lf5o rWnac8zF2pcLC66FrfMjNtMN2nUB//hkjqKZSEM9DRl0YtJk2cYr4YCkcps18DNWooXA 6R+uSfWTrJJ9z8RkvkqIMAAEWk+kftshgS6qi2ZZ3eTcUbquz/IZYFTl4dm18CvYyqhf V+jCxn8GDFhEUqTiLC5i6XhwFsZf45tAhv76bDt9GfF6mQl2IUAhS0lqgZixc+JA/4sl XsdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TiK8Nzc06AQ1Yx6Hpz1jW+UZ+keiCasr59vYPP087zs=; b=afvueVC4MpN8Mrln43AiGVSIXbeeSryFvAMtuLFCYiXe5WhSUlSvuhiJYuB6EdH1kc s1EZ436hhOfIpqrBFMgpTInRyHyFVFp4dNCB4hxpbpeW/g5odS/WTdIdiEgDPUN0Rs8h XppULSlnM3y5R5WIzBwGpQg0+SfIq5tZyNoSjGPjjfZYX3WZqpb4jU/PEcF9OSCX8bzF 0DM5zdQCVfDQUDFET7p/wN/ii3aHXZua6b9ksGowzm8J1L8wsiXM5u4/i2XFqhnkt84S knOR7NN9e04sRypSkQGjvKx1XcW3sEbMYfLy81Pk3neiJHiQwjLdf6W/3WVZhU0p+I8+ tMvg== X-Gm-Message-State: AHQUAuYdhft76FDiHk2WgCqkf+i7VZ5rM2XmPuxNk/eS7GlQAO5Q/Bne TcYbakJai1BnxIjd8XpWOlVY/oUEl6UEPRSNoRk= X-Google-Smtp-Source: AHgI3IZmKr1AvHe6ihDHz+cxdfBmJBgLDPKQvtdj+6T2qzpfQuUi3KKXscP0Hx7zrXkll0k0syDzntchU1+n7b/y5zE= X-Received: by 2002:ac2:50c8:: with SMTP id h8mr2678339lfm.35.1549557876140; Thu, 07 Feb 2019 08:44:36 -0800 (PST) MIME-Version: 1.0 References: <874l9ousuk.fsf@hobgoblin.ariadne.com> <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> In-Reply-To: From: youenn fablet Date: Thu, 7 Feb 2019 08:44:24 -0800 Message-ID: To: Roman Shpount Cc: Justin Uberti , Simon Perreault , RTCWeb IETF , mmusic WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:44:40 -0000 FWIW, Safari Tech Preview introduced last year an mDNS experiment which is close to Chrome experiment. This experiment is now on by default in Safari Tech Preview. As of the case of no ICE candidate at all, this already happens in Safari 12: by default, mode 3 is used. As mentioned by Harald, peer reflexive candidates are already used in some products to enable Safari connection with SFUs or Chrome instances. In some cases, implementations had to be updated to better cope with this, in particular the case of a successful connection triggered by peer reflexive candidates, leading to not expose server reflexive candidates to the web site. Providing guidance to implementors in that area might indeed be good. Le jeu. 7 f=C3=A9vr. 2019 =C3=A0 08:01, Roman Shpount a= =C3=A9crit : > > Hi All, > > From what I can see there is a new problem identified during mDNS discuss= ion with using FQDN: If all the candidates are FQDN and these names do not = resolve or resolve to more then one address, so all the candidates will end= up being ignored. ICE agent might end up with no remote candidates and no = candidate pairs to form. I think RFC 8445 does not handle this situation, = but I might be missing something. > > P.S. I am not arguing against FQDN, I am just trying to figure out what n= eeds to be done to get this documented and operational. > _____________ > Roman Shpount > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Feb 7 08:58:22 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C3C1271FF for ; Thu, 7 Feb 2019 08:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it 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 jcz_HLtGFski for ; Thu, 7 Feb 2019 08:58:17 -0800 (PST) Received: from smtpcmd03116.aruba.it (smtpcmd03116.aruba.it [62.149.158.116]) by ietfa.amsl.com (Postfix) with ESMTP id 7894C1200D8 for ; Thu, 7 Feb 2019 08:58:16 -0800 (PST) Received: from lminiero ([93.44.53.39]) by smtpcmd03.ad.aruba.it with bizsmtp id Zsy81z00H0qlM9p01sy8C8; Thu, 07 Feb 2019 17:58:15 +0100 Date: Thu, 7 Feb 2019 17:58:07 +0100 From: Lorenzo Miniero To: Justin Uberti Cc: Harald Alvestrand , RTCWeb IETF Message-ID: <20190207175807.22179e2b@lminiero> In-Reply-To: References: <24551658-0943-431C-B319-D74B5DC169B9@gmail.com> <0fd991e5-73c9-edd2-67e4-2c527ccc6e95@alvestrand.no> Organization: Meetecho X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1549558695; bh=r3p9LNtlL3mXadA4mF+jl6Dbq2ZX7zM8ELppR7ZcBQY=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=jL58F1VX8vKU6nHET6V/kl72vsJ4/GZvFpFSH9JEIztIuJE/3GDBZZXPVy6HwHBN1 g4xmjA9me/vhV1++f6pRlH+qrWvmbmnLgAS6QRwOSysrjd6I/BX15rzikDrLFAl7c2 7Tsn7RgFh1K6X7G9QkQ6OE5te5DAMN5p8cLfqOK62hjsm7Pga8Zu7b8kVt04jtlYY1 QuPrFH83pNIeyIm7y+/T5o6SMW1xn9trpwQiMgjArzzUQ5comrwiojxlYV3Mp7ePyJ blZoshwFoFX7kjVQj8nwTO7hSqmoMkCPjr/mxDg4tEqQqF3WTnfvN+/7pg89C4zgu4 Qi4Pxf2rewgnw== Archived-At: Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:58:21 -0000 On Thu, 7 Feb 2019 08:28:06 -0800 Justin Uberti wrote: > Note also that only host candidates will be mDNS; srflx and relay > candidates will continue to work as before. >=20 I assume you mean host candidates associated with *private* addresses, and not host candidates associated with public addresses as well? In the latter case, not sure what benefit mDNS would be supposed to provide, if it can be used at all. Lorenzo >=20 >=20 > On Thu, Feb 7, 2019 at 8:01 AM Harald Alvestrand > wrote: >=20 > > Den 05.02.2019 16:03, skrev Alan Ford: =20 > > > If that update was to be made, this goes against the text > > > in draft-ietf-rtcweb-mdns-ice-candidates-02 which says: > > > > > > An ICE agent that supports mDNS candidates MUST support the > > > situation where the hostname resolution results in more than one > > > IP address. In this case, the ICE agent MUST take exactly one of > > > the resolved IP addresses and ignore the others. The ICE agent > > > SHOULD, if available, use the first IPv6 address resolved, > > > otherwise the first IPv4 address. > > > > > > But there=E2=80=99s a bigger problem here, which is how to cope with = an > > > FQDN is not resolvable. So the intention, as I understand it, is > > > that when these host candidates leave the mDNS domain and are > > > thus not resolvable, they will be treated as peer reflexive > > > candidates. > > > > > > But at that point there is no address family information > > > available, so how does an ICE agent know to do pairing with these > > > candidates, which requires the address family to be known? =20 > > > > Peer reflective candidates are identified by means of an incoming > > packet. The address family is very obvious from the packet. > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > =20 --=20 I'm getting older but, unlike whisky, I'm not getting any better https://twitter.com/elminiero From nobody Fri Feb 8 10:43:31 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4641286E7 for ; Fri, 8 Feb 2019 10:43:28 -0800 (PST) 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 kz8MT2BSaVXH for ; Fri, 8 Feb 2019 10:43:26 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 9149D1279E6 for ; Fri, 8 Feb 2019 10:43:26 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id i145so11203457ita.4 for ; Fri, 08 Feb 2019 10:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8hrB9cockMp5HNmZLja8/0xU8M3V89KffarQIPlvrQY=; b=Cy8WRwYh5mQoj4EQEflN6wbKNKuNaBSuGk+DPVPSpJ9/fJ0X6yFAwsHFEgHojMnMyx OC1nKrWAUzzWalwjKv85/52PBziGaXf9F63m/sVd6PyotQFSp7R7OoDV6K5if4m2wKzm RxMHfFNWB6AsEvxGCiHKX+tbJ2Qe92YmSVcSlgZPM/iI/cuyjCit2lyj+5lB5adcLART XI9ll/kDc99xUHynr5G9hbWpoUIZH5hE+MpFByIaHWi44qMyXI1FHF654gS9lrzbHPRU heFDwzwKOGTdLDwYBY3swil24FMoNzKIPjmCL2a6dD8dM2K9JgmGJSJz1RGaC1EIDdGn DSAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8hrB9cockMp5HNmZLja8/0xU8M3V89KffarQIPlvrQY=; b=b7MuVo+4gO0gFSv84/I0jSU40b9NK2Zuam5jiNyRFHYmJ62I1FRNohrkj/BGF9mPZE FRdjOx5Wda4UKxeYjgzbVTQKcvY2B+nu4hI+66j7qAabf+vb+gNtsPuvWshS18BiKKY1 fO5Ssma/M3wCdp3WoHSTJJMOQSFlVvEyKa+8LCuPqgflVs/HwqE1426oKpz/k/Ds2PaL DJNEbkpe7yMgUlgJ3FJFg1Q9Im0Pu+RzgF8s94IR0B4G8BNCf70a6Pe4O+bWs93LjNzn y6NFMT/9qIDPqTqQz2hqbQ9PIL/yJXGU251PrWWXp77z87bkkvSAiMMlf64FW6UAm/0r eVqw== X-Gm-Message-State: AHQUAuY8EMzvJ/ctaZ9+ISx4CLBKlfbfLnRkA4WRIa41QNe5Pb7Ovzeh qcPV0wAUNg5wrVdAGrA/UDe9Jm+D7LDucy8xgGcnJyti X-Google-Smtp-Source: AHgI3IZo3PgKssvOBFmTFD7Ll7Ve+F/RkS4+UXzZfNDVXUveV2X9p3Vs26e7kiiigve5xE1GYYiN2CVwivUl4axjZgA= X-Received: by 2002:a6b:d318:: with SMTP id s24mr12459855iob.6.1549651405306; Fri, 08 Feb 2019 10:43:25 -0800 (PST) MIME-Version: 1.0 From: Ted Hardie Date: Fri, 8 Feb 2019 10:42:58 -0800 Message-ID: To: RTCWeb IETF , Sean Turner , Adam Roach Content-Type: multipart/alternative; boundary="00000000000089ff7405816655dc" Archived-At: Subject: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 18:43:29 -0000 --00000000000089ff7405816655dc Content-Type: text/plain; charset="UTF-8" Over the the past few weeks, the working group has discussed whether to adopt a change to JSEP which would adjust how the ICE proto line transport parameters are populated in certain mid-session offers where the final candidate is a TCP candidate. Outside of the extensive working group discussion on the mailing list, participants may also wish to review the follow issue: https://github.com/rtcweb-wg/jsep/issues/854 and the conversations related to these two pull requests: https://github.com/rtcweb-wg/jsep/pull/862 and https://github.com/rtcweb-wg/jsep/pull/863 The chairs believe that there is technical consensus that this proposed change would not materially affect JSEP-only exchanges, since this parameter is ignored in those. The remaining technical issues are: * whether making one of these changes would improve interoperability between WebRTC and non-WebRTC clients which use SIP/SDP. * whether the additional complexity in tracking the use of UDP vs. TCP and populating the parameter accordingly is onerous or unwarranted for WebRTC implementations. After reviewing the discussion to date, the chairs believe that there is rough consensus for the first point, though there is also broad agreement that the benefit of this change is currently theoretical, since no existing WebRTC browser implementation has relevant code. On the second point, the chairs believe that there is no consensus yet demonstrated. Because we believe that this is in part because the actual proposal has not been entirely clear, and the complexity is therefore somewhat hard to gauge, the chairs wish to make a specific call for consensus. Does the working group approve the change in the following PR: https://github.com/rtcweb-wg/jsep/pull/863 ? Working group participants who have objections to the change are asked to specify whether they believe it has a technical fault, whether they object on the basis of its complexity, or whether they have other issues related to the change they need to raise. The chairs are already aware of the objection of Eric Rescorla on the basis of complexity, and will factor it into the review. Please send comments by February 15th, 2019. regards, Ted Hardie and Sean Turner --00000000000089ff7405816655dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Over the the past few weeks, the working group has di= scussed=20 whether to adopt a change to JSEP which would adjust how the ICE proto=20 line transport parameters are populated in certain mid-session offers=20 where the final candidate is a TCP candidate.=C2=A0 Outside of the extensiv= e=20 working group discussion on the mailing list, participants may also wish to review the follow issue:


and the conversati= ons related to these two pull requests:

and

The chairs believe that there is technical consensus that this proposed=20 change would not materially affect JSEP-only exchanges, since this paramete= r is=20 ignored in those.=C2=A0

The remaining technic= al issues are:=C2=A0

* whether making one of = these changes would improve interoperability between WebRTC and non-WebRTC = clients which use SIP/SDP.

* whether the additional complexity in tracking the use of UDP vs. TCP=20 and populating the parameter accordingly is onerous or unwarranted for=20 WebRTC implementations.

After reviewing the=20 discussion to date, the chairs believe that there is rough consensus for the first point, though there is also broad agreement that the benefit=20 of this change is currently theoretical, since no existing WebRTC=20 browser implementation has relevant code.

On=20 the second point, the chairs believe that there is no consensus yet=20 demonstrated.=C2=A0 Because we believe that this is in part because the=20 actual proposal has not been entirely clear, and the complexity is=20 therefore somewhat hard to gauge, the chairs wish to make a specific=20 call for consensus.

Does the working group approve= the change in the following PR:


Working group participants who have objections to the change are asked to=20 specify whether they believe it has a technical fault, whether they=20 object on the basis of its complexity, or whether they have other issues related to the change they need to raise.

The cha= irs are already aware of the objection of Eric Rescorla on the basis of com= plexity, and will factor it into the review.

Pleas= e send comments by February 15th, 2019.

regards,

Ted Hardie and Sean Turner
=

--00000000000089ff7405816655dc-- From nobody Fri Feb 8 11:14:52 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649BD130EE5 for ; Fri, 8 Feb 2019 11:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8hgJspYSEYd for ; Fri, 8 Feb 2019 11:14:48 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 EA21512426E for ; Fri, 8 Feb 2019 11:14:47 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id y1so1979570pgk.11 for ; Fri, 08 Feb 2019 11:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fGiwYGQfk92X+vD8k5p0/O0VB/DqCKgquZcOkIh/ik0=; b=ud4A6sk/vkAqAZduI63S4r7Zz0kcKSSaZN7W/HSp30DufBCY60OmMMW7GySKKZKWKw F/kqk/Pz5uzLfcsWc3uoAXtnZLllWPe7HZQgmALUHQNee4WRPt307xTyGEopb/SyHu4I IVGCG6Tmg6qU31KhlDVnnXeg6uQ1W1Jn3s8QBLHC4WRznNnmxMyyZ+qha8KUCQCD9Fl7 GuBzevTzsImDgL5O2F6diBQvBE0ZBceBfkG5HRL2aeo63cxcuCTqBunEeUVmVTkgoEZ6 7u1h7qMxAF1Hq+PcY+49KmXvJNWOQ8hUCk1Af12rh7BKO4bGp6fmVIq6Gv1RcXQm+cdm NzPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fGiwYGQfk92X+vD8k5p0/O0VB/DqCKgquZcOkIh/ik0=; b=oXj/47LlqMKXBBY9Zl2zzAt6R6HX+/M5n8znfZ+JZhJNI/BdCrV5O+mfbUEAvnmvCi ES/ipBKS8Iv078wEB3C9n4HG+aKoMER2v5ovB5X1EwNPKnUmVDiXsXukMwWSd/ilVnm6 zugPzbeod22QFQ6iD/n/S7oCYEzPs0w0oPdp3pUjZHtGFyDDqMr4eGE/dO8FDh+iMzDl U6nxZv5fMiLTBu5dL6uIUSU4a1rqMXQfBjbzLK8guSOlqq1ey042T2zMgxbqPymw8KYq SwmVgqJ2GdQi4jX+G05YSib5DYekG7NfNJmYItc+ladvxybfwIX1Mjl/7FuDbl+4U1M2 5fdw== X-Gm-Message-State: AHQUAub0aM8cnoXoiBQgywbozuJj1rbNLY9QS0QoluqFN5SKGbfScADG dIYncNRBB+RGGiEuIpNhcQPNcXuGtdg= X-Google-Smtp-Source: AHgI3IbHgUny+ebM4OJ3GbNcvdUFCvUsuKIb82VkAJ4eExFBqQwKun0gvohJ/WEJmkgXoF/oFtRFeQ== X-Received: by 2002:a63:6a05:: with SMTP id f5mr21507988pgc.72.1549653286980; Fri, 08 Feb 2019 11:14:46 -0800 (PST) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com. [209.85.210.181]) by smtp.gmail.com with ESMTPSA id h129sm9409379pfb.110.2019.02.08.11.14.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 11:14:46 -0800 (PST) Received: by mail-pf1-f181.google.com with SMTP id w73so2114093pfk.10 for ; Fri, 08 Feb 2019 11:14:45 -0800 (PST) X-Received: by 2002:a63:db04:: with SMTP id e4mr7401962pgg.40.1549653285698; Fri, 08 Feb 2019 11:14:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Fri, 8 Feb 2019 14:14:36 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: RTCWeb IETF , Sean Turner , Adam Roach Content-Type: multipart/alternative; boundary="0000000000009e8589058166c5c2" Archived-At: Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 19:14:50 -0000 --0000000000009e8589058166c5c2 Content-Type: text/plain; charset="UTF-8" I am, obviously for this change. As far as I know additional complexity is minimal if not completely non-existent. JSEP already requires m= and c= line updates based on the default candidate. I do not think there is a lot of extra effort in updating the same line based on the same input in two places vs one place. I would also like to note that: 1. JSEP requires browsers to update the m= line more often then mmusic-ice-sip-sdp or RFC 5245. For offers sent during ICE nomination process, JSEP asks to set m= and c= line to the last used ICE candidate pair. RFC 5245 asks in this case to set this to the default candidate pair, which changes a lot less often. It is unclear what is the benefit of additional JSEP requirement. It looks like some sort of left over logic from re-nomination. This being said, it should not create any interop issues and will simply creates additional complexity. 2. JSEP can produce the answer where default candidate protocol does not match the m= line protocol. This is an old RFC 5245 issue and can be fixed in the future specification or mmusic-ice-sip-sdp. Regards, _____________ Roman Shpount On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie wrote: > Over the the past few weeks, the working group has discussed whether to > adopt a change to JSEP which would adjust how the ICE proto line transport > parameters are populated in certain mid-session offers where the final > candidate is a TCP candidate. Outside of the extensive working group > discussion on the mailing list, participants may also wish to review the > follow issue: > > https://github.com/rtcweb-wg/jsep/issues/854 > > and the conversations related to these two pull requests: > > https://github.com/rtcweb-wg/jsep/pull/862 > and > https://github.com/rtcweb-wg/jsep/pull/863 > > The chairs believe that there is technical consensus that this proposed > change would not materially affect JSEP-only exchanges, since this > parameter is ignored in those. > > The remaining technical issues are: > > * whether making one of these changes would improve interoperability > between WebRTC and non-WebRTC clients which use SIP/SDP. > > * whether the additional complexity in tracking the use of UDP vs. TCP and > populating the parameter accordingly is onerous or unwarranted for WebRTC > implementations. > > After reviewing the discussion to date, the chairs believe that there is > rough consensus for the first point, though there is also broad agreement > that the benefit of this change is currently theoretical, since no existing > WebRTC browser implementation has relevant code. > > On the second point, the chairs believe that there is no consensus yet > demonstrated. Because we believe that this is in part because the actual > proposal has not been entirely clear, and the complexity is therefore > somewhat hard to gauge, the chairs wish to make a specific call for > consensus. > > Does the working group approve the change in the following PR: > > https://github.com/rtcweb-wg/jsep/pull/863 ? > > Working group participants who have objections to the change are asked to > specify whether they believe it has a technical fault, whether they object > on the basis of its complexity, or whether they have other issues related > to the change they need to raise. > > The chairs are already aware of the objection of Eric Rescorla on the > basis of complexity, and will factor it into the review. > > Please send comments by February 15th, 2019. > > regards, > > Ted Hardie and Sean Turner > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009e8589058166c5c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am, obviously for this change. As far as I know addition= al complexity is minimal if not completely non-existent. JSEP already requi= res m=3D and c=3D line updates based on the default candidate. I do not thi= nk there is a lot of extra effort in updating the same line based on the sa= me input in two places vs one place.

I would also like t= o note that:

1.=C2=A0 JSEP requires browsers to up= date the m=3D line more often then mmusic-ice-sip-sdp or RFC 5245. For offe= rs sent during ICE nomination process, JSEP asks to set m=3D and c=3D line = to the last used ICE candidate pair. RFC 5245 asks in this case to set this= to the default candidate pair, which changes a lot less often. It is uncle= ar what is the benefit of additional JSEP requirement. It looks like some s= ort of left over logic from re-nomination. This being said, it should not c= reate any interop issues and will simply creates additional complexity.

2. JSEP can produce the answer where default candidat= e protocol does not match the m=3D line protocol. This is an old RFC 5245 i= ssue and can be fixed in the future specification or mmusic-ice-sip-sdp.

Regards,
_____________
R= oman Shpount


On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie= <ted.ietf@gmail.com> wrote= :
Over the the past few weeks, the working group has discussed=20 whether to adopt a change to JSEP which would adjust how the ICE proto=20 line transport parameters are populated in certain mid-session offers=20 where the final candidate is a TCP candidate.=C2=A0 Outside of the extensiv= e=20 working group discussion on the mailing list, participants may also wish to review the follow issue:


and the conversati= ons related to these two pull requests:

and

The chairs believe that there is technical consensus that this proposed=20 change would not materially affect JSEP-only exchanges, since this paramete= r is=20 ignored in those.=C2=A0

The remaining technic= al issues are:=C2=A0

* whether making one of = these changes would improve interoperability between WebRTC and non-WebRTC = clients which use SIP/SDP.

* whether the additional complexity in tracking the use of UDP vs. TCP=20 and populating the parameter accordingly is onerous or unwarranted for=20 WebRTC implementations.

After reviewing the=20 discussion to date, the chairs believe that there is rough consensus for the first point, though there is also broad agreement that the benefit=20 of this change is currently theoretical, since no existing WebRTC=20 browser implementation has relevant code.

On=20 the second point, the chairs believe that there is no consensus yet=20 demonstrated.=C2=A0 Because we believe that this is in part because the=20 actual proposal has not been entirely clear, and the complexity is=20 therefore somewhat hard to gauge, the chairs wish to make a specific=20 call for consensus.

Does the working group approve= the change in the following PR:


Working group participants who have objections to the change are asked to=20 specify whether they believe it has a technical fault, whether they=20 object on the basis of its complexity, or whether they have other issues related to the change they need to raise.

The cha= irs are already aware of the objection of Eric Rescorla on the basis of com= plexity, and will factor it into the review.

Pleas= e send comments by February 15th, 2019.

regards,

Ted Hardie and Sean Turner


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009e8589058166c5c2-- From nobody Fri Feb 8 11:20:43 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9C0130E96 for ; Fri, 8 Feb 2019 11:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuMxqVsrpaml for ; Fri, 8 Feb 2019 11:20:38 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 5A3E0130DEF for ; Fri, 8 Feb 2019 11:20:38 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id z20so11685682itc.3 for ; Fri, 08 Feb 2019 11:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lv1hOtXG7ACBDx7X3pmE8sWaFI+2mTpRnPus3lq031c=; b=CvCDGxlK8++DLn5l4qIJpa1zAVSKZ7f+tdb1qAnOIiPQ8li5iajxz81ZNRqXxPqoMQ UOL9ObXkRopscR7zxu5gBnM4FyIloa2bJThTQikWQTRvEYX9xOvXgbLU4px8KBwYVl9i byd0dnLtc9BIf7QTBD0vQtoLYxgT8aLwMZpHPAEBxkx3U14ZsVGuMF4SHKymJ8+EVZCt fERZ3nx4RAaPUTm2rMKnzAtvuElknfmTPr9DHITGkvwUpbRBa79jlZWzUg1SqKrVqhLd o6FVr18nAUfaIo9jEkJsBII4QtXm7zofVmIVnkI7gSy7ZXN/F2IYwxkOnJMDGzuEbrGn 1VPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lv1hOtXG7ACBDx7X3pmE8sWaFI+2mTpRnPus3lq031c=; b=WF5s3yNc2ipcDI6kx9zCpvE6kCMOvF2CRYxwM/O3W4OPaU/7LVC3NetAKPv/NFyvom rSord6TFR84GWhchmtqZMZ1jBainH69CWPBHkeGJZQE8dsxIEljgQyaZ/xdaXBNbJWk6 aHZj4zdnBQ1y8XBurZ3He+EmgGbBosrukI8bdspQugGQwfl7+RFO+GTGJkzBytgNE3Iu b3eiSe5y3kJCa0jRBjlrxnl8nyHQry1Xlxugbjuzc5mG8y+3/jIlQAPZRmphjz+q4CT7 4AF3+NxMlRhbtqxybYerHyOkU/hD8v3ZQgbdESNiZDzmSd/9CN1E0tr4JC8yDrAomQYb Mg1w== X-Gm-Message-State: AHQUAuauay58khCms0BUksYkZyD4HeFfIl5bidIjwmXM0GISMSYkuGmP rGroKGSoGyHlRnnahyuyHk8sF4Gjf3q+GOyUDe10Uw== X-Google-Smtp-Source: AHgI3IYPrB8BjLs2W9jELgdtwEzMVggeppFrD9bt2RajcdAhqzx6NlQFryWlCx7sYR6VyHqQlN4+hpiNTPb9XzboRH8= X-Received: by 2002:a24:738f:: with SMTP id y137mr58775itb.136.1549653637166; Fri, 08 Feb 2019 11:20:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Fri, 8 Feb 2019 11:20:25 -0800 Message-ID: To: Roman Shpount Cc: Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000920461058166dab2" Archived-At: Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2019 19:20:41 -0000 --000000000000920461058166dab2 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 8, 2019 at 11:15 AM Roman Shpount wrote: > I am, obviously for this change. As far as I know additional complexity is > minimal if not completely non-existent. JSEP already requires m= and c= > line updates based on the default candidate. I do not think there is a lot > of extra effort in updating the same line based on the same input in two > places vs one place. > > I would also like to note that: > > 1. JSEP requires browsers to update the m= line more often then > mmusic-ice-sip-sdp or RFC 5245. For offers sent during ICE nomination > process, JSEP asks to set m= and c= line to the last used ICE candidate > pair. RFC 5245 asks in this case to set this to the default candidate pair, > which changes a lot less often. It is unclear what is the benefit of > additional JSEP requirement. It looks like some sort of left over logic > from re-nomination. This being said, it should not create any interop > issues and will simply creates additional complexity. > I agree that this should probably be removed from JSEP and codified in sip-sdp instead; as previously discussed, JSEP doesn't actually use this info. > > 2. JSEP can produce the answer where default candidate protocol does not > match the m= line protocol. This is an old RFC 5245 issue and can be fixed > in the future specification or mmusic-ice-sip-sdp. > This should probably also be fixed in sip-sdp. > > Regards, > _____________ > Roman Shpount > > > On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie wrote: > >> Over the the past few weeks, the working group has discussed whether to >> adopt a change to JSEP which would adjust how the ICE proto line transport >> parameters are populated in certain mid-session offers where the final >> candidate is a TCP candidate. Outside of the extensive working group >> discussion on the mailing list, participants may also wish to review the >> follow issue: >> >> https://github.com/rtcweb-wg/jsep/issues/854 >> >> and the conversations related to these two pull requests: >> >> https://github.com/rtcweb-wg/jsep/pull/862 >> and >> https://github.com/rtcweb-wg/jsep/pull/863 >> >> The chairs believe that there is technical consensus that this proposed >> change would not materially affect JSEP-only exchanges, since this >> parameter is ignored in those. >> >> The remaining technical issues are: >> >> * whether making one of these changes would improve interoperability >> between WebRTC and non-WebRTC clients which use SIP/SDP. >> >> * whether the additional complexity in tracking the use of UDP vs. TCP >> and populating the parameter accordingly is onerous or unwarranted for >> WebRTC implementations. >> >> After reviewing the discussion to date, the chairs believe that there is >> rough consensus for the first point, though there is also broad agreement >> that the benefit of this change is currently theoretical, since no existing >> WebRTC browser implementation has relevant code. >> >> On the second point, the chairs believe that there is no consensus yet >> demonstrated. Because we believe that this is in part because the actual >> proposal has not been entirely clear, and the complexity is therefore >> somewhat hard to gauge, the chairs wish to make a specific call for >> consensus. >> >> Does the working group approve the change in the following PR: >> >> https://github.com/rtcweb-wg/jsep/pull/863 ? >> >> Working group participants who have objections to the change are asked to >> specify whether they believe it has a technical fault, whether they object >> on the basis of its complexity, or whether they have other issues related >> to the change they need to raise. >> >> The chairs are already aware of the objection of Eric Rescorla on the >> basis of complexity, and will factor it into the review. >> >> Please send comments by February 15th, 2019. >> >> regards, >> >> Ted Hardie and Sean Turner >> >> >> _______________________________________________ >> 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 > --000000000000920461058166dab2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 8, 2019 at 11:15 AM Roman= Shpount <roman@telurix.com>= wrote:
I am, obviously for this change. As far as I know additional compl= exity is minimal if not completely non-existent. JSEP already requires m=3D= and c=3D line updates based on the default candidate. I do not think there= is a lot of extra effort in updating the same line based on the same input= in two places vs one place.

I would also like to note t= hat:

1.=C2=A0 JSEP requires browsers to update the= m=3D line more often then mmusic-ice-sip-sdp or RFC 5245. For offers sent = during ICE nomination process, JSEP asks to set m=3D and c=3D line to the l= ast used ICE candidate pair. RFC 5245 asks in this case to set this to the = default candidate pair, which changes a lot less often. It is unclear what = is the benefit of additional JSEP requirement. It looks like some sort of l= eft over logic from re-nomination. This being said, it should not create an= y interop issues and will simply creates additional complexity.
=

I agree that this should probably be remov= ed from JSEP and codified in sip-sdp instead; as previously discussed, JSEP= doesn't actually use this info.=C2=A0

2. JSEP can pro= duce the answer where default candidate protocol does not match the m=3D li= ne protocol. This is an old RFC 5245 issue and can be fixed in the future s= pecification or mmusic-ice-sip-sdp.

=
This should probably also be fixed in sip-sdp.=C2=A0

= Regards,
_____________
Roman Shpount


On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie <ted.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Over= the the past few weeks, the working group has discussed=20 whether to adopt a change to JSEP which would adjust how the ICE proto=20 line transport parameters are populated in certain mid-session offers=20 where the final candidate is a TCP candidate.=C2=A0 Outside of the extensiv= e=20 working group discussion on the mailing list, participants may also wish to review the follow issue:


and the conversati= ons related to these two pull requests:

and

The chairs believe that there is technical consensus that this proposed=20 change would not materially affect JSEP-only exchanges, since this paramete= r is=20 ignored in those.=C2=A0

The remaining technic= al issues are:=C2=A0

* whether making one of = these changes would improve interoperability between WebRTC and non-WebRTC = clients which use SIP/SDP.

* whether the additional complexity in tracking the use of UDP vs. TCP=20 and populating the parameter accordingly is onerous or unwarranted for=20 WebRTC implementations.

After reviewing the=20 discussion to date, the chairs believe that there is rough consensus for the first point, though there is also broad agreement that the benefit=20 of this change is currently theoretical, since no existing WebRTC=20 browser implementation has relevant code.

On=20 the second point, the chairs believe that there is no consensus yet=20 demonstrated.=C2=A0 Because we believe that this is in part because the=20 actual proposal has not been entirely clear, and the complexity is=20 therefore somewhat hard to gauge, the chairs wish to make a specific=20 call for consensus.

Does the working group approve= the change in the following PR:


Working group participants who have objections to the change are asked to=20 specify whether they believe it has a technical fault, whether they=20 object on the basis of its complexity, or whether they have other issues related to the change they need to raise.

The cha= irs are already aware of the objection of Eric Rescorla on the basis of com= plexity, and will factor it into the review.

Pleas= e send comments by February 15th, 2019.

regards,

Ted Hardie and Sean Turner


_______________________________________________
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
--000000000000920461058166dab2-- From nobody Sat Feb 9 01:12:53 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481891311A4 for ; Sat, 9 Feb 2019 01:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Gj32Yzay; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CTAK6+cy 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 nxYD4k5DV2ct for ; Sat, 9 Feb 2019 01:12:48 -0800 (PST) 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 908E6130F2F for ; Sat, 9 Feb 2019 01:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549703565; x=1552295565; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bluHsxhcgSG8Qnkh5sROXLhkt3YH9SgduXfDUPmxjZA=; b=Gj32YzaytFChDtGkWH4DKQS+HTxnrMH4UHu9A+1Oqk9p55DhAwlDjTY3eE4+0ir4 lSfjDrn0t/Uf7QqhhFXZlUjtWcVPpaIce3GIE4ndWmCRp5yIMf/z82JSwKCn+8xw Ewo5GH8MSr+YYpJk7FCilewp8VV75jTIWnU3Av0Yp+c=; X-AuditID: c1b4fb25-d89ff70000005ff7-55-5c5e998dd38b Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.8B.24567.D899E5C5; Sat, 9 Feb 2019 10:12:45 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB504.ericsson.se (153.88.183.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 9 Feb 2019 10:12:45 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 9 Feb 2019 10:12:45 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 9 Feb 2019 10:12:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bluHsxhcgSG8Qnkh5sROXLhkt3YH9SgduXfDUPmxjZA=; b=CTAK6+cy8fqxWyWU4l2ft8Yo3Xpbv3BB8xpKW5wQkF0ITFEqepHfpu+8N9YjcynErOSxJjDc555cw0ABHAPQTP9RAbmy+eG/K9BUINxVR2/CeIc1maL8EO0f91acWZwW3GDnKNkamngi4t71gqzhgLs7xCHjM68lt5LYMKV4anE= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3402.eurprd07.prod.outlook.com (10.170.247.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.12; Sat, 9 Feb 2019 09:12:43 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::ec90:1d14:9549:fdf0%4]) with mapi id 15.20.1601.016; Sat, 9 Feb 2019 09:12:43 +0000 From: Christer Holmberg To: Justin Uberti , Roman Shpount CC: RTCWeb IETF Thread-Topic: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). Thread-Index: AQHUv95CrUmogQGN6kCdzvDflARjaKXWRVIAgAABoICAAPlNAA== Date: Sat, 9 Feb 2019 09:12:43 +0000 Message-ID: <1CBB5877-1CBC-46F8-BD41-9B97EE6FB3F3@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3402; 6:4dj8edteHYmbYJyl+Ri9LoAgy/ha25vscJxQGXfb0t7lDZyXGu/dIRGfFgn4wn5Em8BsULrkpjuytA4s9Cwiz4auPGao2Whcxm8lXz0m2rdUtcFc3riWbSzVrzSuc2BEuOPLfoOFua7MsIBgY+XNLahvT9ndRRonbcWA5dWUjPQyu0zNjub4axWrxDDwTK0t/wu8m5BNnpG5Z9jO2/ljpdNukg6Rt21g0Te2kT//ovgh2mKBszfg4VmhI/+c3mvPcjYFKKNRBQZ5Yd3BlR9ZlAeycNTa2wrr0zIVlP578dYF2a7BS/5KqywY3zZ1XZ62gh2UWzZFTAPE0q3GaY3bpyGhgx9lH6ufAV24M10++5C044CWUFxeifFc106ysUmnJ1yZoN2RHFYMAninjukssHGoNZNRCku0L9A81olpYWQYs3ZWvQRONKmCyscfUrsP5wc8CPOZhucp3ix1deysGg==; 5:Mn8SlY0xkl9M6S46zvhOXLoXnLvrD2JhdZ8iMqW49eOVzI4ycxj8d5mLGnPGJwmBKuFcPwaSRnZFgQG4R/77XDsLYRyKyAFYCxKQaVGZdJfvz15sxnl7Y+WdA1EoactqTI8DhaeY9WG1XaXu97rB0cB580q8yDPGjEgZohS2SsmTb0FuXrGof8NjRCvPmvO9/jvR5oPBnlAEH9T29/DYIQ==; 7:GzpXvYhkSW9T6ZiZEgRaG1+ORZ0sheoeOgG6/d4zUYWHKbeMl2PgoqJLh6ANf3Ay4wwPurzJX7ZejfJJT0U59vgwTTqX4bwc9TIJs2KlYIqBW+KiRYbW3YkgaO/B2u8GkbiTw2h3LPXOL6++JK7Flw== x-ms-office365-filtering-correlation-id: 8a8c4f3b-9687-4bd7-774c-08d68e6ebfce x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3402; x-ms-traffictypediagnostic: HE1PR07MB3402: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 09435FCA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(376002)(136003)(39860400002)(199004)(189003)(10913002)(54896002)(99286004)(44832011)(71190400001)(83716004)(71200400001)(236005)(110136005)(14444005)(6512007)(76176011)(58126008)(53936002)(6306002)(68736007)(36756003)(6436002)(561944003)(316002)(33656002)(6486002)(486006)(97736004)(3846002)(6116002)(82746002)(105586002)(106356001)(4326008)(6246003)(6346003)(2906002)(26005)(2616005)(66066001)(25786009)(8936002)(966005)(14454004)(476003)(66574012)(11346002)(6506007)(186003)(446003)(606006)(229853002)(478600001)(53546011)(8676002)(86362001)(256004)(102836004)(81166006)(81156014)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3402; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wrqAju0TAijyBRAIQbKRbdR1/djYr80gZI8lGw/XWpPKbWILPwa53leOx4Bg4FDrWm2MoWhkG/u7g1neLo+zv6bK4ycz6HaHKlIcApAvo/Lynqk/2bPZTeqXCQ9ZWArXdGPnQ7HGq1hKeS/dAxJ80ZaOnFGc9ttt1SwMKdqbNWM2Db1cv2wk/2MBNzX0tkb3/ou0Iv3pCo73QkRAvpFesEA2k6BJwPMombP6RmxCGSo+KYJP9DCBMKQ2ZArbNl4fuHUF0p8unJRoN36UfPqZGvlhSP1vnmaS4OejADZwPBabO1bWHkWH0mVSFqUlPLCubYG7bJP2R0XlmWyiSVw4KM2B9HqDsffYdFP7da9f7mi4drqFFjMd8tan2gCx78DMhfD0DJ4b8zs74Pmjrk500Uoczk3Ftql63YXKQ8OqErs= Content-Type: multipart/alternative; boundary="_000_1CBB58771CBC46F8BD419B97EE6FB3F3ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8a8c4f3b-9687-4bd7-774c-08d68e6ebfce X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2019 09:12:43.2758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3402 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzHfZ/nubvncPN1yGfoDxfFtUj649paZGb3h1pqpXGTiyfk9z0Y 1pqFFJUfO/nRj6Ous0WibJpZclNIjuXHUGM31mRNtkgi6+6eq/nv9f583+99fuxLk+Ienhud lJbFqNKUKRK+LVV3vjP/wO26GMXB6W4vWVHZW56sdrSalD3bLhEEk/IB3ThPrtVuEPIZdcYp Msr2aDyTkpTDqPyPxdomVq/X8DNm21CufqqJV4AKW1ApEtKAD8O8oYMoRba0GPch6K/8QnJi DcG9lQbef7HROMrnxGMCvk+WI7OgcAUJw79mrJkqAroqmq3CiGBq4oYpQ9N8LIOy7f3mjs5Y AbXV6wIzk9gTVps0fDM74ShYGvvE4zzR0PVoGnEcAr2Gd5Y6hb1gclRNmFmEg6BSV2sdaRbB n3GjJSDEEaDtMJJmRngXrL9vIbhmrjCzoCG4tTFou0dIjl3g6/y2pYEL9ofNpiGKq3vC8LLR 6t8NHzVl1pNdE8DNHnuOT0CdQWM5H+Bp08Jbi3zuQQptn4ut7AbLU62U+RCAk6GmnceVPWD9 +k+qAvnX7xiP4ziobHxJ1lv2dITBugWq3pQmsS8877LaPUFdZhRw7APF9x8IOIscpprsdloa EP0UubAMezE14VCgH6NKimPZ9DS/NCbrBTJ9q96OTe9XaOzbcT3CNJLYi1ZLYxRinjKHzUvV I6BJibOIUZtKonhlXj6jSr+gyk5hWD1ypymJq2hL7KgQ4wRlFpPMMBmM6t8rQQvdCtCZfpFT 6NV+ptDwW8iWKAbmpMJUSbCu5VzYXMTaXsNQg7L4tWzwR2B0UaT35fD01jAfuyVNpsPKRN+d N+Xh2luZuoe9Ou/2oBZvx7te7iFDoVeUkSOLOR7ZDsvjT0671Z+1UWd1pu+Rs+OEODag+RJ9 BPtK99mQJ3OvfqiK8U+QUGyiMkBKqljlX7E9uPFSAwAA Archived-At: Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 09:12:51 -0000 --_000_1CBB58771CBC46F8BD419B97EE6FB3F3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWxzbyBzdXBwb3J0IHRoaXMgY2hhbmdlLg0KDQpJIHNoYXJlIFJvbWFu4oCZcyBp c3N1ZSBpbiB0aGlzIG5vdGUgIzEsIGJ1dCBzaW5jZSBKdXN0aW4gc2VlbXMgdG8gYmUgZmluZSBy ZW1vdmluZyB0aGUgYXNzb2NpYXRlZCB0ZXh0IGl0IHNob3VsZCBiZSBzb2x2ZWQuDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiA8cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpPTQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZz4NCkRhdGU6IEZyaWRheSwgOCBGZWJydWFyeSAyMDE5IGF0IDIwLjIxDQpUbzogUm9t YW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+DQpDYzogInJ0Y3dlYkBpZXRmLm9yZyIgPHJ0 Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBDYWxsIGZvciBjb25zZW5zdXMg b24gSUNFIHRyYW5zcG9ydCBwYXJhbWV0ZXIgaXNzdWUgKEZlYnJ1YXJ5IDE1KS4NCg0KDQoNCk9u IEZyaSwgRmViIDgsIDIwMTkgYXQgMTE6MTUgQU0gUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJp eC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQpJIGFtLCBvYnZpb3VzbHkg Zm9yIHRoaXMgY2hhbmdlLiBBcyBmYXIgYXMgSSBrbm93IGFkZGl0aW9uYWwgY29tcGxleGl0eSBp cyBtaW5pbWFsIGlmIG5vdCBjb21wbGV0ZWx5IG5vbi1leGlzdGVudC4gSlNFUCBhbHJlYWR5IHJl cXVpcmVzIG09IGFuZCBjPSBsaW5lIHVwZGF0ZXMgYmFzZWQgb24gdGhlIGRlZmF1bHQgY2FuZGlk YXRlLiBJIGRvIG5vdCB0aGluayB0aGVyZSBpcyBhIGxvdCBvZiBleHRyYSBlZmZvcnQgaW4gdXBk YXRpbmcgdGhlIHNhbWUgbGluZSBiYXNlZCBvbiB0aGUgc2FtZSBpbnB1dCBpbiB0d28gcGxhY2Vz IHZzIG9uZSBwbGFjZS4NCg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8gbm90ZSB0aGF0Og0KDQoxLiAg SlNFUCByZXF1aXJlcyBicm93c2VycyB0byB1cGRhdGUgdGhlIG09IGxpbmUgbW9yZSBvZnRlbiB0 aGVuIG1tdXNpYy1pY2Utc2lwLXNkcCBvciBSRkMgNTI0NS4gRm9yIG9mZmVycyBzZW50IGR1cmlu ZyBJQ0Ugbm9taW5hdGlvbiBwcm9jZXNzLCBKU0VQIGFza3MgdG8gc2V0IG09IGFuZCBjPSBsaW5l IHRvIHRoZSBsYXN0IHVzZWQgSUNFIGNhbmRpZGF0ZSBwYWlyLiBSRkMgNTI0NSBhc2tzIGluIHRo aXMgY2FzZSB0byBzZXQgdGhpcyB0byB0aGUgZGVmYXVsdCBjYW5kaWRhdGUgcGFpciwgd2hpY2gg Y2hhbmdlcyBhIGxvdCBsZXNzIG9mdGVuLiBJdCBpcyB1bmNsZWFyIHdoYXQgaXMgdGhlIGJlbmVm aXQgb2YgYWRkaXRpb25hbCBKU0VQIHJlcXVpcmVtZW50LiBJdCBsb29rcyBsaWtlIHNvbWUgc29y dCBvZiBsZWZ0IG92ZXIgbG9naWMgZnJvbSByZS1ub21pbmF0aW9uLiBUaGlzIGJlaW5nIHNhaWQs IGl0IHNob3VsZCBub3QgY3JlYXRlIGFueSBpbnRlcm9wIGlzc3VlcyBhbmQgd2lsbCBzaW1wbHkg Y3JlYXRlcyBhZGRpdGlvbmFsIGNvbXBsZXhpdHkuDQoNCkkgYWdyZWUgdGhhdCB0aGlzIHNob3Vs ZCBwcm9iYWJseSBiZSByZW1vdmVkIGZyb20gSlNFUCBhbmQgY29kaWZpZWQgaW4gc2lwLXNkcCBp bnN0ZWFkOyBhcyBwcmV2aW91c2x5IGRpc2N1c3NlZCwgSlNFUCBkb2Vzbid0IGFjdHVhbGx5IHVz ZSB0aGlzIGluZm8uDQoNCjIuIEpTRVAgY2FuIHByb2R1Y2UgdGhlIGFuc3dlciB3aGVyZSBkZWZh dWx0IGNhbmRpZGF0ZSBwcm90b2NvbCBkb2VzIG5vdCBtYXRjaCB0aGUgbT0gbGluZSBwcm90b2Nv bC4gVGhpcyBpcyBhbiBvbGQgUkZDIDUyNDUgaXNzdWUgYW5kIGNhbiBiZSBmaXhlZCBpbiB0aGUg ZnV0dXJlIHNwZWNpZmljYXRpb24gb3IgbW11c2ljLWljZS1zaXAtc2RwLg0KDQpUaGlzIHNob3Vs ZCBwcm9iYWJseSBhbHNvIGJlIGZpeGVkIGluIHNpcC1zZHAuDQoNClJlZ2FyZHMsDQpfX19fX19f X19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0KT24gRnJpLCBGZWIgOCwgMjAxOSBhdCAxOjQzIFBN IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86dGVkLmlldGZAZ21haWwuY29t Pj4gd3JvdGU6DQpPdmVyIHRoZSB0aGUgcGFzdCBmZXcgd2Vla3MsIHRoZSB3b3JraW5nIGdyb3Vw IGhhcyBkaXNjdXNzZWQgd2hldGhlciB0byBhZG9wdCBhIGNoYW5nZSB0byBKU0VQIHdoaWNoIHdv dWxkIGFkanVzdCBob3cgdGhlIElDRSBwcm90byBsaW5lIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGFy ZSBwb3B1bGF0ZWQgaW4gY2VydGFpbiBtaWQtc2Vzc2lvbiBvZmZlcnMgd2hlcmUgdGhlIGZpbmFs IGNhbmRpZGF0ZSBpcyBhIFRDUCBjYW5kaWRhdGUuICBPdXRzaWRlIG9mIHRoZSBleHRlbnNpdmUg d29ya2luZyBncm91cCBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIHBhcnRpY2lwYW50 cyBtYXkgYWxzbyB3aXNoIHRvIHJldmlldyB0aGUgZm9sbG93IGlzc3VlOg0KDQpodHRwczovL2dp dGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvaXNzdWVzLzg1NA0KDQphbmQgdGhlIGNvbnZlcnNhdGlv bnMgcmVsYXRlZCB0byB0aGVzZSB0d28gcHVsbCByZXF1ZXN0czoNCg0KaHR0cHM6Ly9naXRodWIu Y29tL3J0Y3dlYi13Zy9qc2VwL3B1bGwvODYyDQphbmQNCmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3 ZWItd2cvanNlcC9wdWxsLzg2Mw0KDQpUaGUgY2hhaXJzIGJlbGlldmUgdGhhdCB0aGVyZSBpcyB0 ZWNobmljYWwgY29uc2Vuc3VzIHRoYXQgdGhpcyBwcm9wb3NlZCBjaGFuZ2Ugd291bGQgbm90IG1h dGVyaWFsbHkgYWZmZWN0IEpTRVAtb25seSBleGNoYW5nZXMsIHNpbmNlIHRoaXMgcGFyYW1ldGVy IGlzIGlnbm9yZWQgaW4gdGhvc2UuDQoNClRoZSByZW1haW5pbmcgdGVjaG5pY2FsIGlzc3VlcyBh cmU6DQoNCiogd2hldGhlciBtYWtpbmcgb25lIG9mIHRoZXNlIGNoYW5nZXMgd291bGQgaW1wcm92 ZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gV2ViUlRDIGFuZCBub24tV2ViUlRDIGNsaWVudHMg d2hpY2ggdXNlIFNJUC9TRFAuDQoNCiogd2hldGhlciB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5 IGluIHRyYWNraW5nIHRoZSB1c2Ugb2YgVURQIHZzLiBUQ1AgYW5kIHBvcHVsYXRpbmcgdGhlIHBh cmFtZXRlciBhY2NvcmRpbmdseSBpcyBvbmVyb3VzIG9yIHVud2FycmFudGVkIGZvciBXZWJSVEMg aW1wbGVtZW50YXRpb25zLg0KDQpBZnRlciByZXZpZXdpbmcgdGhlIGRpc2N1c3Npb24gdG8gZGF0 ZSwgdGhlIGNoYWlycyBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgcm91Z2ggY29uc2Vuc3VzIGZvciB0 aGUgZmlyc3QgcG9pbnQsIHRob3VnaCB0aGVyZSBpcyBhbHNvIGJyb2FkIGFncmVlbWVudCB0aGF0 IHRoZSBiZW5lZml0IG9mIHRoaXMgY2hhbmdlIGlzIGN1cnJlbnRseSB0aGVvcmV0aWNhbCwgc2lu Y2Ugbm8gZXhpc3RpbmcgV2ViUlRDIGJyb3dzZXIgaW1wbGVtZW50YXRpb24gaGFzIHJlbGV2YW50 IGNvZGUuDQoNCk9uIHRoZSBzZWNvbmQgcG9pbnQsIHRoZSBjaGFpcnMgYmVsaWV2ZSB0aGF0IHRo ZXJlIGlzIG5vIGNvbnNlbnN1cyB5ZXQgZGVtb25zdHJhdGVkLiAgQmVjYXVzZSB3ZSBiZWxpZXZl IHRoYXQgdGhpcyBpcyBpbiBwYXJ0IGJlY2F1c2UgdGhlIGFjdHVhbCBwcm9wb3NhbCBoYXMgbm90 IGJlZW4gZW50aXJlbHkgY2xlYXIsIGFuZCB0aGUgY29tcGxleGl0eSBpcyB0aGVyZWZvcmUgc29t ZXdoYXQgaGFyZCB0byBnYXVnZSwgdGhlIGNoYWlycyB3aXNoIHRvIG1ha2UgYSBzcGVjaWZpYyBj YWxsIGZvciBjb25zZW5zdXMuDQoNCkRvZXMgdGhlIHdvcmtpbmcgZ3JvdXAgYXBwcm92ZSB0aGUg Y2hhbmdlIGluIHRoZSBmb2xsb3dpbmcgUFI6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWIt d2cvanNlcC9wdWxsLzg2MyA/DQoNCldvcmtpbmcgZ3JvdXAgcGFydGljaXBhbnRzIHdobyBoYXZl IG9iamVjdGlvbnMgdG8gdGhlIGNoYW5nZSBhcmUgYXNrZWQgdG8gc3BlY2lmeSB3aGV0aGVyIHRo ZXkgYmVsaWV2ZSBpdCBoYXMgYSB0ZWNobmljYWwgZmF1bHQsIHdoZXRoZXIgdGhleSBvYmplY3Qg b24gdGhlIGJhc2lzIG9mIGl0cyBjb21wbGV4aXR5LCBvciB3aGV0aGVyIHRoZXkgaGF2ZSBvdGhl ciBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgY2hhbmdlIHRoZXkgbmVlZCB0byByYWlzZS4NCg0KVGhl IGNoYWlycyBhcmUgYWxyZWFkeSBhd2FyZSBvZiB0aGUgb2JqZWN0aW9uIG9mIEVyaWMgUmVzY29y bGEgb24gdGhlIGJhc2lzIG9mIGNvbXBsZXhpdHksIGFuZCB3aWxsIGZhY3RvciBpdCBpbnRvIHRo ZSByZXZpZXcuDQoNClBsZWFzZSBzZW5kIGNvbW1lbnRzIGJ5IEZlYnJ1YXJ5IDE1dGgsIDIwMTku DQoNCnJlZ2FyZHMsDQoNClRlZCBIYXJkaWUgYW5kIFNlYW4gVHVybmVyDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxp c3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0 Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViDQo= --_000_1CBB58771CBC46F8BD419B97EE6FB3F3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4C171BB64035EF40AA7A9682D4EC2592@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkkgYWxzbyBzdXBwb3J0IHRoaXMgY2hhbmdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBzaGFy ZSBSb21hbuKAmXMgaXNzdWUgaW4gdGhpcyBub3RlICMxLCBidXQgc2luY2UgSnVzdGluIHNlZW1z IHRvIGJlIGZpbmUgcmVtb3ZpbmcgdGhlIGFzc29jaWF0ZWQgdGV4dCBpdCBzaG91bGQgYmUgc29s dmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlz dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5ydGN3ZWIgJmx0O3J0Y3dlYi1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgSnVzdGluIFViZXJ0aSAmbHQ7anViZXJ0aT00MGdvb2dsZS5jb21A ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgOCBGZWJydWFyeSAy MDE5IGF0IDIwLjIxPGJyPg0KPGI+VG86IDwvYj5Sb21hbiBTaHBvdW50ICZsdDtyb21hbkB0ZWx1 cml4LmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3J0Y3dlYkBpZXRmLm9yZyZxdW90OyAm bHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3J0Y3dlYl0g Q2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFyYW1ldGVyIGlzc3VlIChGZWJy dWFyeSAxNSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiA4LCAyMDE5IGF0IDExOjE1IEFNIFJvbWFuIFNo cG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9tYW5AdGVsdXJp eC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtLCBvYnZpb3VzbHkgZm9yIHRoaXMgY2hh bmdlLiBBcyBmYXIgYXMgSSBrbm93IGFkZGl0aW9uYWwgY29tcGxleGl0eSBpcyBtaW5pbWFsIGlm IG5vdCBjb21wbGV0ZWx5IG5vbi1leGlzdGVudC4gSlNFUCBhbHJlYWR5IHJlcXVpcmVzIG09IGFu ZCBjPSBsaW5lIHVwZGF0ZXMgYmFzZWQgb24gdGhlIGRlZmF1bHQgY2FuZGlkYXRlLiBJIGRvIG5v dCB0aGluayB0aGVyZSBpcyBhIGxvdCBvZiBleHRyYSBlZmZvcnQNCiBpbiB1cGRhdGluZyB0aGUg c2FtZSBsaW5lIGJhc2VkIG9uIHRoZSBzYW1lIGlucHV0IGluIHR3byBwbGFjZXMgdnMgb25lIHBs YWNlLiA8bzpwPg0KPC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3 b3VsZCBhbHNvIGxpa2UgdG8gbm90ZSB0aGF0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiZuYnNwOyBKU0VQIHJlcXVpcmVzIGJyb3dzZXJz IHRvIHVwZGF0ZSB0aGUgbT0gbGluZSBtb3JlIG9mdGVuIHRoZW4gbW11c2ljLWljZS1zaXAtc2Rw IG9yIFJGQyA1MjQ1LiBGb3Igb2ZmZXJzIHNlbnQgZHVyaW5nIElDRSBub21pbmF0aW9uIHByb2Nl c3MsIEpTRVAgYXNrcyB0byBzZXQgbT0gYW5kIGM9IGxpbmUgdG8gdGhlIGxhc3QgdXNlZCBJQ0Ug Y2FuZGlkYXRlIHBhaXIuIFJGQyA1MjQ1IGFza3MgaW4gdGhpcyBjYXNlDQogdG8gc2V0IHRoaXMg dG8gdGhlIGRlZmF1bHQgY2FuZGlkYXRlIHBhaXIsIHdoaWNoIGNoYW5nZXMgYSBsb3QgbGVzcyBv ZnRlbi4gSXQgaXMgdW5jbGVhciB3aGF0IGlzIHRoZSBiZW5lZml0IG9mIGFkZGl0aW9uYWwgSlNF UCByZXF1aXJlbWVudC4gSXQgbG9va3MgbGlrZSBzb21lIHNvcnQgb2YgbGVmdCBvdmVyIGxvZ2lj IGZyb20gcmUtbm9taW5hdGlvbi4gVGhpcyBiZWluZyBzYWlkLCBpdCBzaG91bGQgbm90IGNyZWF0 ZSBhbnkgaW50ZXJvcCBpc3N1ZXMNCiBhbmQgd2lsbCBzaW1wbHkgY3JlYXRlcyBhZGRpdGlvbmFs IGNvbXBsZXhpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxk IHByb2JhYmx5IGJlIHJlbW92ZWQgZnJvbSBKU0VQIGFuZCBjb2RpZmllZCBpbiBzaXAtc2RwIGlu c3RlYWQ7IGFzIHByZXZpb3VzbHkgZGlzY3Vzc2VkLCBKU0VQIGRvZXNuJ3QgYWN0dWFsbHkgdXNl IHRoaXMgaW5mby4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBKU0VQIGNhbiBwcm9kdWNlIHRo ZSBhbnN3ZXIgd2hlcmUgZGVmYXVsdCBjYW5kaWRhdGUgcHJvdG9jb2wgZG9lcyBub3QgbWF0Y2gg dGhlIG09IGxpbmUgcHJvdG9jb2wuIFRoaXMgaXMgYW4gb2xkIFJGQyA1MjQ1IGlzc3VlIGFuZCBj YW4gYmUgZml4ZWQgaW4gdGhlIGZ1dHVyZSBzcGVjaWZpY2F0aW9uIG9yIG1tdXNpYy1pY2Utc2lw LXNkcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNob3VsZCBwcm9iYWJseSBhbHNvIGJlIGZp eGVkIGluIHNpcC1zZHAuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8YnIgY2xlYXI9 ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBGZWIgOCwgMjAxOSBh dCAxOjQzIFBNIFRlZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T3ZlciB0aGUgdGhlIHBhc3QgZmV3IHdlZWtzLCB0aGUgd29ya2luZyBncm91 cCBoYXMgZGlzY3Vzc2VkIHdoZXRoZXIgdG8gYWRvcHQgYSBjaGFuZ2UgdG8gSlNFUCB3aGljaCB3 b3VsZCBhZGp1c3QgaG93IHRoZSBJQ0UgcHJvdG8gbGluZSB0cmFuc3BvcnQgcGFyYW1ldGVycyBh cmUgcG9wdWxhdGVkIGluIGNlcnRhaW4gbWlkLXNlc3Npb24gb2ZmZXJzIHdoZXJlIHRoZSBmaW5h bCBjYW5kaWRhdGUgaXMgYSBUQ1ANCiBjYW5kaWRhdGUuJm5ic3A7IE91dHNpZGUgb2YgdGhlIGV4 dGVuc2l2ZSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCwgcGFy dGljaXBhbnRzIG1heSBhbHNvIHdpc2ggdG8gcmV2aWV3IHRoZSBmb2xsb3cgaXNzdWU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9pc3N1ZXMvODU0IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL2lzc3Vlcy84NTQ8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB0 aGUgY29udmVyc2F0aW9ucyByZWxhdGVkIHRvIHRoZXNlIHR3byBwdWxsIHJlcXVlc3RzOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjI8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9wdWxsLzg2MyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9wdWxsLzg2MzwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNoYWlycyBi ZWxpZXZlIHRoYXQgdGhlcmUgaXMgdGVjaG5pY2FsIGNvbnNlbnN1cyB0aGF0IHRoaXMgcHJvcG9z ZWQgY2hhbmdlIHdvdWxkIG5vdCBtYXRlcmlhbGx5IGFmZmVjdCBKU0VQLW9ubHkgZXhjaGFuZ2Vz LCBzaW5jZSB0aGlzIHBhcmFtZXRlciBpcyBpZ25vcmVkIGluIHRob3NlLiZuYnNwOw0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZW1h aW5pbmcgdGVjaG5pY2FsIGlzc3VlcyBhcmU6Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIHdoZXRoZXIgbWFraW5nIG9uZSBvZiB0 aGVzZSBjaGFuZ2VzIHdvdWxkIGltcHJvdmUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIFdlYlJU QyBhbmQgbm9uLVdlYlJUQyBjbGllbnRzIHdoaWNoIHVzZSBTSVAvU0RQLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIHdoZXRoZXIgdGhlIGFk ZGl0aW9uYWwgY29tcGxleGl0eSBpbiB0cmFja2luZyB0aGUgdXNlIG9mIFVEUCB2cy4gVENQIGFu ZCBwb3B1bGF0aW5nIHRoZSBwYXJhbWV0ZXIgYWNjb3JkaW5nbHkgaXMgb25lcm91cyBvciB1bndh cnJhbnRlZCBmb3IgV2ViUlRDIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWZ0ZXIgcmV2aWV3aW5nIHRoZSBkaXNj dXNzaW9uIHRvIGRhdGUsIHRoZSBjaGFpcnMgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIHJvdWdoIGNv bnNlbnN1cyBmb3IgdGhlIGZpcnN0IHBvaW50LCB0aG91Z2ggdGhlcmUgaXMgYWxzbyBicm9hZCBh Z3JlZW1lbnQgdGhhdCB0aGUgYmVuZWZpdCBvZiB0aGlzIGNoYW5nZSBpcyBjdXJyZW50bHkgdGhl b3JldGljYWwsIHNpbmNlIG5vIGV4aXN0aW5nIFdlYlJUQyBicm93c2VyDQogaW1wbGVtZW50YXRp b24gaGFzIHJlbGV2YW50IGNvZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIHRoZSBzZWNvbmQgcG9pbnQsIHRoZSBjaGFpcnMgYmVsaWV2 ZSB0aGF0IHRoZXJlIGlzIG5vIGNvbnNlbnN1cyB5ZXQgZGVtb25zdHJhdGVkLiZuYnNwOyBCZWNh dXNlIHdlIGJlbGlldmUgdGhhdCB0aGlzIGlzIGluIHBhcnQgYmVjYXVzZSB0aGUgYWN0dWFsIHBy b3Bvc2FsIGhhcyBub3QgYmVlbiBlbnRpcmVseSBjbGVhciwgYW5kIHRoZSBjb21wbGV4aXR5IGlz IHRoZXJlZm9yZSBzb21ld2hhdCBoYXJkIHRvIGdhdWdlLA0KIHRoZSBjaGFpcnMgd2lzaCB0byBt YWtlIGEgc3BlY2lmaWMgY2FsbCBmb3IgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIHRoZSB3b3JraW5nIGdyb3VwIGFw cHJvdmUgdGhlIGNoYW5nZSBpbiB0aGUgZm9sbG93aW5nIFBSOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dp dGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjM8L2E+ID88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V29ya2luZyBncm91cCBwYXJ0aWNp cGFudHMgd2hvIGhhdmUgb2JqZWN0aW9ucyB0byB0aGUgY2hhbmdlIGFyZSBhc2tlZCB0byBzcGVj aWZ5IHdoZXRoZXIgdGhleSBiZWxpZXZlIGl0IGhhcyBhIHRlY2huaWNhbCBmYXVsdCwgd2hldGhl ciB0aGV5IG9iamVjdCBvbiB0aGUgYmFzaXMgb2YgaXRzIGNvbXBsZXhpdHksIG9yIHdoZXRoZXIg dGhleSBoYXZlIG90aGVyIGlzc3VlcyByZWxhdGVkIHRvIHRoZSBjaGFuZ2UNCiB0aGV5IG5lZWQg dG8gcmFpc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBjaGFpcnMgYXJlIGFscmVhZHkgYXdhcmUgb2YgdGhlIG9iamVjdGlvbiBvZiBF cmljIFJlc2NvcmxhIG9uIHRoZSBiYXNpcyBvZiBjb21wbGV4aXR5LCBhbmQgd2lsbCBmYWN0b3Ig aXQgaW50byB0aGUgcmV2aWV3LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc2VuZCBjb21tZW50cyBieSBGZWJydWFyeSAxNXRoLCAy MDE5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UZWQgSGFyZGllIGFuZCBTZWFuIFR1cm5lciA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1CBB58771CBC46F8BD419B97EE6FB3F3ericssoncom_-- From nobody Sat Feb 9 10:51:02 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E95C130DD6; Sat, 9 Feb 2019 10:50:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley To: Cc: draft-ietf-rtcweb-security-arch.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154973824800.29421.10047365396889314189@ietfa.amsl.com> Date: Sat, 09 Feb 2019 10:50:48 -0800 Archived-At: Subject: [rtcweb] Genart last call review of draft-ietf-rtcweb-security-arch-18 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 18:50:48 -0000 Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-rtcweb-security-arch-18 Reviewer: Russ Housley Review Date: 2019-02-07 IETF LC End Date: 2019-02-15 IESG Telechat date: unknown Summary: Almost Ready Major Concerns: Section 4.1 says "... preferably over TLS ...", but it does not tell what the consequences are if TLS is not used. Since this is the security architecture, I would expect these consequences to be described. Section 4.2: Please add a sentence or two that defines Interactive Connectivity Establishment (ICE) data and non-ICE data. Section 6.5 includes a contradiction. One place it says, " MUST NOT negotiate cipher suites with NULL encryption", and another place it says, "if Null ciphers are used ...". Please make these consistent. Section 6.5 requires implementation of certificate fingerprints or a Short Authentication String (SAS). Please add a sentence to tell how they are used to provide out-of-band verification. Without such a sentence, it is easy to imagine an implementation with a UI that is too awkward to actually get the information on the screen while the call is in progress. Section 10: since this is a standards track document, the IESG should be responsible for this new codepoint, not the document author. Minor Concerns: Section 3.1 uses https://www.evil.org/ as an example. However, this is a registered domain. It would be better to follow the IESG statement on examples: https://www6.ietf.org/iesg/statement/examples.html. Section 6.2 uses customerservice@ford.com as an example. Of course, ford.com is a registered domain. It would be better to follow the IESG statement on examples (the URL is above). Section 7 uses Poker Galaxy as an example. Of course, this is a real web site. It would be better to follow the IESG statement on examples (the URL is above). It seems best to use the same names here as are used in Section 7.2. Nits: Section 1 includes: "... SDP-based like SIP." Please add a reference for SDP. Section 4.1: s/ permissions till later/ permissions until later/ Section 4.4: please add a reference for STUN. Section 6.2: s/(though see Section 6.3/(See Section 6.3/ Section 6.4: please do not enclose the note is '[' and ']'. Avoid confusion with reference syntax. One solution is to put the note at the end of the paragraph. Section 6.4: s/non-turn candidates/non-TURN candidates/ Section 6.5: the phrase "Implementations MUST implement" seems awkward. Perhaps "Implementations MUST support". This appears several places. Section 6.5 ought to begin with "All data channels MUST be secured via DTLS." This appears half way through the section, but the material that comes before is really in support of this sentence. Section 8.1 discusses "@", but the discussion of "user" (note the quotes) and the discussion of domain (note the absense of quotes) are using different conventions. Please use quotes in both places or neither place. There are places in this document where "settings" is confusing. It is unclear whether the word is referring to configuration settings or it is referring to an environment or situation. Please look at each use of this word and consider alternatives. From nobody Sun Feb 10 16:07:53 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F761295D8 for ; Sun, 10 Feb 2019 16:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUHr49_XhCO0 for ; Sun, 10 Feb 2019 16:07:49 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 05F04129284 for ; Sun, 10 Feb 2019 16:07:49 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id e27so6354173lfj.8 for ; Sun, 10 Feb 2019 16:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2E98GxPPlsJ392T/gDl835Tox96T1tNHz0AOLzRSzKI=; b=BXGt2+aLxokrY65+pJqExEvIfq+g+CsB8jHxXQs3TnUF+M4Z/EtVwkAaZhKiGVdLCk UGVO7GXwUu++edG61HMEsH7SsCQOpDaZP+p8yF2FyelmCb3b0dJlGkjEpSK0kSNMqun6 HGq6ff5DzFDgKnKToA4ndxLJ4VcSTgjAXVDHWFYOmq3oA48TQjPqRIoHMRQxKvZFEUSW Q0Es8TPH6AB2gNNrbUXq55xppRDXEECqUCV3/vvteS59V7y6hZXfpou7NHt1rQjP06vZ futuoSmUK9zZgF4zjc6aNB28DupaiDOE9VxYbAm6cjeLJKvlcoLulkZnmzrPtZz4Imuj 8fkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2E98GxPPlsJ392T/gDl835Tox96T1tNHz0AOLzRSzKI=; b=cGSCitUlNTLr1wYK5RE2hhdFXDdJCSQ+j3+PAtnfH8hAB3Waf90SUxh/HU2PzqHJR6 XzFc72bCPBbuDNjUBYT9Vyyem6c+6cCQLHRfDK7UpOVEWPp99zVWCRcWKiXt6Y8gzKm9 pQibvcZSbuInEBR8sUTz8/rYg+IsiAl4LVZUo5i636exzo9l8ee+gYcc4T0owFnDsOu9 9MoU0JMJondzXWRcP7oFKLQ3SeEu7i6HFrGzByHYaSXOMLNU8Ls6TALs6BJLZFWyCCar rEiVtLlPfhQvMUXOJJ0cmEkZOerrMDFL+r7J9gmeHMrzGyHtJODdqsIdjtWvsh1jFPKJ E25Q== X-Gm-Message-State: AHQUAuZwsGb4Xw8wXCd/wwz5l0ns5v7LuH8ROJsnueM1MdJpF8plwJZh Ar2fqZYeZQe07m0tAct4YWOlWXs1LgWYSHTeWJh//p9v X-Google-Smtp-Source: AHgI3IYpZ5S7gOstyeXYLFWEjgWtp/W1snN570HbFRZS4ubY3J1y3sz7AGV17i9I4yWRrGu0ZBrb6xwc08NRpEKRvGQ= X-Received: by 2002:a19:f204:: with SMTP id q4mr21090411lfh.133.1549843667025; Sun, 10 Feb 2019 16:07:47 -0800 (PST) MIME-Version: 1.0 References: <1CBB5877-1CBC-46F8-BD41-9B97EE6FB3F3@ericsson.com> In-Reply-To: <1CBB5877-1CBC-46F8-BD41-9B97EE6FB3F3@ericsson.com> From: Eric Rescorla Date: Sun, 10 Feb 2019 16:07:08 -0800 Message-ID: To: Christer Holmberg Cc: Justin Uberti , Roman Shpount , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003b13dc0581931918" Archived-At: Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 00:07:52 -0000 --0000000000003b13dc0581931918 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not in favor of this change for the reasons I already laid out. -Ekr On Sat, Feb 9, 2019 at 1:13 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I also support this change. > > > > I share Roman=E2=80=99s issue in this note #1, but since Justin seems to = be fine > removing the associated text it should be solved. > > > > Regards, > > > > Christer > > > > *From: *rtcweb on behalf of Justin Uberti > > *Date: *Friday, 8 February 2019 at 20.21 > *To: *Roman Shpount > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Call for consensus on ICE transport parameter > issue (February 15). > > > > > > > > On Fri, Feb 8, 2019 at 11:15 AM Roman Shpount wrote: > > I am, obviously for this change. As far as I know additional complexity i= s > minimal if not completely non-existent. JSEP already requires m=3D and c= =3D > line updates based on the default candidate. I do not think there is a lo= t > of extra effort in updating the same line based on the same input in two > places vs one place. > > > > I would also like to note that: > > > > 1. JSEP requires browsers to update the m=3D line more often then > mmusic-ice-sip-sdp or RFC 5245. For offers sent during ICE nomination > process, JSEP asks to set m=3D and c=3D line to the last used ICE candida= te > pair. RFC 5245 asks in this case to set this to the default candidate pai= r, > which changes a lot less often. It is unclear what is the benefit of > additional JSEP requirement. It looks like some sort of left over logic > from re-nomination. This being said, it should not create any interop > issues and will simply creates additional complexity. > > > > I agree that this should probably be removed from JSEP and codified in > sip-sdp instead; as previously discussed, JSEP doesn't actually use this > info. > > > > 2. JSEP can produce the answer where default candidate protocol does not > match the m=3D line protocol. This is an old RFC 5245 issue and can be fi= xed > in the future specification or mmusic-ice-sip-sdp. > > > > This should probably also be fixed in sip-sdp. > > > > Regards, > > _____________ > Roman Shpount > > > > > > On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie wrote: > > Over the the past few weeks, the working group has discussed whether to > adopt a change to JSEP which would adjust how the ICE proto line transpor= t > parameters are populated in certain mid-session offers where the final > candidate is a TCP candidate. Outside of the extensive working group > discussion on the mailing list, participants may also wish to review the > follow issue: > > > > https://github.com/rtcweb-wg/jsep/issues/854 > > > > and the conversations related to these two pull requests: > > > > https://github.com/rtcweb-wg/jsep/pull/862 > > and > > https://github.com/rtcweb-wg/jsep/pull/863 > > > > The chairs believe that there is technical consensus that this proposed > change would not materially affect JSEP-only exchanges, since this > parameter is ignored in those. > > > > The remaining technical issues are: > > > > * whether making one of these changes would improve interoperability > between WebRTC and non-WebRTC clients which use SIP/SDP. > > > > * whether the additional complexity in tracking the use of UDP vs. TCP an= d > populating the parameter accordingly is onerous or unwarranted for WebRTC > implementations. > > > > After reviewing the discussion to date, the chairs believe that there is > rough consensus for the first point, though there is also broad agreement > that the benefit of this change is currently theoretical, since no existi= ng > WebRTC browser implementation has relevant code. > > > > On the second point, the chairs believe that there is no consensus yet > demonstrated. Because we believe that this is in part because the actual > proposal has not been entirely clear, and the complexity is therefore > somewhat hard to gauge, the chairs wish to make a specific call for > consensus. > > > > Does the working group approve the change in the following PR: > > > > https://github.com/rtcweb-wg/jsep/pull/863 ? > > > > Working group participants who have objections to the change are asked to > specify whether they believe it has a technical fault, whether they objec= t > on the basis of its complexity, or whether they have other issues related > to the change they need to raise. > > > > The chairs are already aware of the objection of Eric Rescorla on the > basis of complexity, and will factor it into the review. > > > > Please send comments by February 15th, 2019. > > > > regards, > > > > Ted Hardie and Sean Turner > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000003b13dc0581931918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not in favor of this change for the reasons I al= ready laid out.

-Ekr

On Sat, F= eb 9, 2019 at 1:13 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Hi,

=C2=A0

I also support this change.<= /u>

=C2=A0

I share Roman=E2=80=99s issue i= n this note #1, but since Justin seems to be fine removing the associated t= ext it should be solved.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = rtcweb <rtcweb-bounces@ietf.org<= /a>> on behalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org><= br> Date: Friday, 8 February 2019 at 20.21
To: Roman Shpount <roman@telurix.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Call for consensus on ICE transport parameter = issue (February 15).

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 8, 2019 at 11:15 AM Roman Shpount <roman@telurix.com&= gt; wrote:

I am, obviously for this change. As far as I know ad= ditional complexity is minimal if not completely non-existent. JSEP already= requires m=3D and c=3D line updates based on the default candidate. I do n= ot think there is a lot of extra effort in updating the same line based on the same input in two places vs one pla= ce.

=C2=A0

I would also like to note that:

=C2=A0

1.=C2=A0 JSEP requires browsers to update the m=3D l= ine more often then mmusic-ice-sip-sdp or RFC 5245. For offers sent during = ICE nomination process, JSEP asks to set m=3D and c=3D line to the last use= d ICE candidate pair. RFC 5245 asks in this case to set this to the default candidate pair, which changes a lot less often.= It is unclear what is the benefit of additional JSEP requirement. It looks= like some sort of left over logic from re-nomination. This being said, it = should not create any interop issues and will simply creates additional complexity.

=C2=A0

I agree that this should probably be removed from JS= EP and codified in sip-sdp instead; as previously discussed, JSEP doesn'= ;t actually use this info.=C2=A0

=C2=A0

2. JSEP can produce the answer where default candida= te protocol does not match the m=3D line protocol. This is an old RFC 5245 = issue and can be fixed in the future specification or mmusic-ice-sip-sdp.

=C2=A0

This should probably also be fixed in sip-sdp.=C2=A0=

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0

On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie <ted.ietf@gmail.com>= ; wrote:

Over the the past few weeks, the working group has d= iscussed whether to adopt a change to JSEP which would adjust how the ICE p= roto line transport parameters are populated in certain mid-session offers = where the final candidate is a TCP candidate.=C2=A0 Outside of the extensive working group discussion on the = mailing list, participants may also wish to review the follow issue:=

=C2=A0

=C2=A0

and the conversations related to these two pull requ= ests:

=C2=A0

and

=C2=A0

The chairs believe that there is technical consensus= that this proposed change would not materially affect JSEP-only exchanges,= since this parameter is ignored in those.=C2=A0

=C2=A0

The remaining technical issues are:=C2=A0 =

=C2=A0

* whether making one of these changes would improve = interoperability between WebRTC and non-WebRTC clients which use SIP/SDP.

=C2=A0

* whether the additional complexity in tracking the = use of UDP vs. TCP and populating the parameter accordingly is onerous or u= nwarranted for WebRTC implementations.

=C2=A0

After reviewing the discussion to date, the chairs b= elieve that there is rough consensus for the first point, though there is a= lso broad agreement that the benefit of this change is currently theoretica= l, since no existing WebRTC browser implementation has relevant code.

=C2=A0

On the second point, the chairs believe that there i= s no consensus yet demonstrated.=C2=A0 Because we believe that this is in p= art because the actual proposal has not been entirely clear, and the comple= xity is therefore somewhat hard to gauge, the chairs wish to make a specific call for consensus.

=C2=A0

Does the working group approve the change in the fol= lowing PR:

=C2=A0

=C2=A0

Working group participants who have objections to th= e change are asked to specify whether they believe it has a technical fault= , whether they object on the basis of its complexity, or whether they have = other issues related to the change they need to raise.

=C2=A0

The chairs are already aware of the objection of Eri= c Rescorla on the basis of complexity, and will factor it into the review.<= u>

=C2=A0

Please send comments by February 15th, 2019.<= u>

=C2=A0

regards,

=C2=A0

Ted Hardie and Sean Turner

=C2=A0

=C2=A0

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

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000003b13dc0581931918-- From nobody Tue Feb 12 11:45:01 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 573E4130DC4; Tue, 12 Feb 2019 11:44:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joe Clarke To: Cc: draft-ietf-rtcweb-security.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155000069929.8344.2037971001030338378@ietfa.amsl.com> Date: Tue, 12 Feb 2019 11:44:59 -0800 Archived-At: Subject: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 19:44:59 -0000 Reviewer: Joe Clarke Review result: Not Ready I have been assigned to review this document on behalf of the Ops directorate. In general, I found the document well-written, but the reason I marked it as not ready as I was confused as to its standards track trajectory. I do not see any kind of inter-operable standard being defined here. On my reading -- before I noticed it was standards track -- it felt informational. While it does set out a threat model for the browser, I struggle to see how that needs to be standardized. On that threat model note, the abstract indicates that the WebRTC threat model will be laid out, but section 3 defines a more general browser threat model. Beyond those items, I noticed various nits and other small items when reading the document. Most broadly, I feel this document would benefit from a terminology section to define acronyms such as ICE, TURN, STUN, VoIP, etc. Additionally, in section 3.1, the document refers to "scripts" in a general way. While the implication is JavaScript code that will run in a browser, I think that kind of context setting might be made more explicit in a terminology section. Other nits are mentioned below on a section-by-section basis. Section 1: s/implementated/implemented/ === Section 3.2: s/provide a escape hatch/provide an escape hatch/ === Section 4.2: s/signficant/significant/ === Section 4.2.3: s/ threats is less severe/threats are less severe/ === Section 4.3: s/ The calling service is is/The calling service is/ === Section 4.3.2.1: OLD: (a) the browser to trusted UI to provide the name and I don't grok this sentence fragment. There seems to be a verb missing, and I'm not sure what your intent is here. === Section 4.3.2.2: s/e.g., read aloud over the the voice/e.g., read aloud over the voice/ s/However, it it is well-known/However, it is well-known/ From nobody Tue Feb 12 23:57:10 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F419D130E6E; Tue, 12 Feb 2019 23:56:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Cc: draft-ietf-rtcweb-fec.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155004461594.8627.1832684939296277208@ietfa.amsl.com> Date: Tue, 12 Feb 2019 23:56:55 -0800 Archived-At: Subject: [rtcweb] Opsdir telechat review of draft-ietf-rtcweb-fec-08 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 07:56:56 -0000 Reviewer: Jürgen Schönwälder Review result: Has Nits I have reviewed this document and I did not find any issues that are affect the operations of networks (except that FEC requires more bandwidth and that it may not help much or even make things worse if bandwidth is the cause of packet loss, which is explained in the document). While reading the document, I wrote down the following notes that the editor may take into account when revising the document: - in 3.1, expland SSRC on first usage and say that this is about sending streams over RTP somewhere early on (I assume this is implied by using the term WebRTC but for outsiders like me it may help to be more specific). - To what extend is this document WebRTC specific? Do the requirements also apply if I use RTP without a WebRTC context? If so, should the title rather say "RTP Forward Error Correction Requirements"? Well, section 6 may be WebRTC specific but that section just says that nothing is being recommended, so the recommendations are really all about FEC usage over RTP as far as I can tell (as an outsider). - stylistic: I am not a big fan of using citations like '[RFC2198]' as ordinary words or nouns, it makes text difficult to follow unless you know the RFC numbers by heart and your brain translates them back to something meaningful on the fly. This makes texts more difficult to read for outsiders. Example: This mechanism is similar to the [RFC2198] mechanism described above. I prefer this: This mechanism is similar to the redundant encoding mechanism described above. There are couple of such usages of [RFCXXXX] in the document - add reference for PCMU From nobody Wed Feb 13 10:53:23 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA371292F1 for ; Wed, 13 Feb 2019 10:53:21 -0800 (PST) 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 Fr8uBdwfyoj6 for ; Wed, 13 Feb 2019 10:53:18 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 10DC0126F72 for ; Wed, 13 Feb 2019 10:53:18 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id h6so6859307itl.1 for ; Wed, 13 Feb 2019 10:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0NeXLEgvqCCxo/lLRYAn23MtUdIF/bc0KGXJP+y2+q4=; b=oZGUXObPAGN5wF/aoYckeLXQsOiTMaBCgLqLjZz0rI+/dO34eIRJTM0JZme0Zwbq8Z RlQom5CA7jN3fasfkOOxF2pmZfFE8So9Lv2VbTceoWuzqT3aXYf5Ak+xgtztsWfXlVfu ZhTkXOmpuUAv4GmuiV+DPS8pmYiy6nrn/7gusLAZHjv8Bk2DyzKShq6z+dEGXIswV3h1 VZMtW8kHHouDJa95b87K6QblObksFnVOXL3afX6yPs2R+/0vKsc0EMI+JFwvK6Hxdyl+ SZpYFgjFxmlb2S/qG5t+McbVvsp2V2GEVDu3xvZFudX2ybmFrqKIoXptkm1uHtEYukUL t2bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0NeXLEgvqCCxo/lLRYAn23MtUdIF/bc0KGXJP+y2+q4=; b=OLBt5FZrIJUB1rkpeY6hTqOG1QE7F9X+dIgha81LYvXP6M4j820htrY/VJciduLE8N j9ndY4WBhQ1Ax7WDObTieKV7RsfkutO+OLSxa3XrQdmWYNnftMwLw+oCLTN3oDKUvK5+ IDTJz/eaNrtK7EavKzVUkUXzcZwSPuHE++qfzShq9TLv9f/cH8zk46013fS7WzWLM/IJ 4n9sCdTSjjMb8Aw/fogMrboqHDYKkrNfysGxV2mYnL0hEmM+0byWZBlQKS65fVOy/0Pe Omybs3AEfqEHRMzB2F8bsWbRnWv2y6itvua+OnaZ4wnTZ570FSa68djrhaBg9k0ysdwW atDA== X-Gm-Message-State: AHQUAuZcT9mWI0cmy3kDiDLIx1I3/s1MIxy2ZLMlX/7VQN0bqtPsISlL rw1aVnPm22PtJOk2oewAPtkZVGb391qXonHjDHVElw== X-Google-Smtp-Source: AHgI3IYzXj8fzNhYA078p2GzM7Yn2Ib0gqVXT0QLC9YccriLhHIQxB1WqH96Aw9XsZXupdhpYkHIW9G8ukQnYhXoNFo= X-Received: by 2002:a02:601d:: with SMTP id i29mr1134854jac.11.1550083996098; Wed, 13 Feb 2019 10:53:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Wed, 13 Feb 2019 10:52:49 -0800 Message-ID: To: RTCWeb IETF , Sean Turner , Adam Roach Content-Type: multipart/alternative; boundary="000000000000f5a3380581cb0d57" Archived-At: Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 18:53:21 -0000 --000000000000f5a3380581cb0d57 Content-Type: text/plain; charset="UTF-8" As an individual, I support this change. While I agree that the benefit is currently theoretical, I think having the breadcrumbs for what to do when it ceases to be theoretical is worth the effort. Ted On Fri, Feb 8, 2019 at 10:42 AM Ted Hardie wrote: > Over the the past few weeks, the working group has discussed whether to > adopt a change to JSEP which would adjust how the ICE proto line transport > parameters are populated in certain mid-session offers where the final > candidate is a TCP candidate. Outside of the extensive working group > discussion on the mailing list, participants may also wish to review the > follow issue: > > https://github.com/rtcweb-wg/jsep/issues/854 > > and the conversations related to these two pull requests: > > https://github.com/rtcweb-wg/jsep/pull/862 > and > https://github.com/rtcweb-wg/jsep/pull/863 > > The chairs believe that there is technical consensus that this proposed > change would not materially affect JSEP-only exchanges, since this > parameter is ignored in those. > > The remaining technical issues are: > > * whether making one of these changes would improve interoperability > between WebRTC and non-WebRTC clients which use SIP/SDP. > > * whether the additional complexity in tracking the use of UDP vs. TCP and > populating the parameter accordingly is onerous or unwarranted for WebRTC > implementations. > > After reviewing the discussion to date, the chairs believe that there is > rough consensus for the first point, though there is also broad agreement > that the benefit of this change is currently theoretical, since no existing > WebRTC browser implementation has relevant code. > > On the second point, the chairs believe that there is no consensus yet > demonstrated. Because we believe that this is in part because the actual > proposal has not been entirely clear, and the complexity is therefore > somewhat hard to gauge, the chairs wish to make a specific call for > consensus. > > Does the working group approve the change in the following PR: > > https://github.com/rtcweb-wg/jsep/pull/863 ? > > Working group participants who have objections to the change are asked to > specify whether they believe it has a technical fault, whether they object > on the basis of its complexity, or whether they have other issues related > to the change they need to raise. > > The chairs are already aware of the objection of Eric Rescorla on the > basis of complexity, and will factor it into the review. > > Please send comments by February 15th, 2019. > > regards, > > Ted Hardie and Sean Turner > > > --000000000000f5a3380581cb0d57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an individual, I support this change.=C2=A0 While = I agree that the benefit is currently theoretical, I think having the bread= crumbs for what to do when it ceases to be theoretical is worth the effort.=

Ted

On Fri, Feb 8, 2019 at 10:42 AM = Ted Hardie <ted.ietf@gmail.com= > wrote:
Over the the past few weeks, the working group has discus= sed=20 whether to adopt a change to JSEP which would adjust how the ICE proto=20 line transport parameters are populated in certain mid-session offers=20 where the final candidate is a TCP candidate.=C2=A0 Outside of the extensiv= e=20 working group discussion on the mailing list, participants may also wish to review the follow issue:


and the conversati= ons related to these two pull requests:

and

The chairs believe that there is technical consensus that this proposed=20 change would not materially affect JSEP-only exchanges, since this paramete= r is=20 ignored in those.=C2=A0

The remaining technic= al issues are:=C2=A0

* whether making one of = these changes would improve interoperability between WebRTC and non-WebRTC = clients which use SIP/SDP.

* whether the additional complexity in tracking the use of UDP vs. TCP=20 and populating the parameter accordingly is onerous or unwarranted for=20 WebRTC implementations.

After reviewing the=20 discussion to date, the chairs believe that there is rough consensus for the first point, though there is also broad agreement that the benefit=20 of this change is currently theoretical, since no existing WebRTC=20 browser implementation has relevant code.

On=20 the second point, the chairs believe that there is no consensus yet=20 demonstrated.=C2=A0 Because we believe that this is in part because the=20 actual proposal has not been entirely clear, and the complexity is=20 therefore somewhat hard to gauge, the chairs wish to make a specific=20 call for consensus.

Does the working group approve= the change in the following PR:


Working group participants who have objections to the change are asked to=20 specify whether they believe it has a technical fault, whether they=20 object on the basis of its complexity, or whether they have other issues related to the change they need to raise.

The cha= irs are already aware of the objection of Eric Rescorla on the basis of com= plexity, and will factor it into the review.

Pleas= e send comments by February 15th, 2019.

regards,

Ted Hardie and Sean Turner


--000000000000f5a3380581cb0d57-- From nobody Wed Feb 13 11:38:41 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCDC1200B3 for ; Wed, 13 Feb 2019 11:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn9_iz_45kwF for ; Wed, 13 Feb 2019 11:38:36 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 56C5812E036 for ; Wed, 13 Feb 2019 11:38:36 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id h6so7218691itl.1 for ; Wed, 13 Feb 2019 11:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0IrHFWxNEWMyyvUPeyxK1Yq2040dMR8lBMOGFu0gaKs=; b=WmU6COzFGgvGwai03LxMzthBEKNszCUmo41EJUj7z41D6sFZy243YMXfiX7VhcJ91b 4hztxrkNl1ZTiz4myrumpleijHHa3OYX15GrdrOLWTdBt/BITzBYEWSIo+gtLILdPNoL E+pluBW2jEjez6tEjmauZhDm33HpiigteSCYzoh1NLFQPyIiiajAMgmjpgldb2Dr7q2U SuyxVCZ0CGQ+PQDxXa+YX8JpuaF9YO2blQXijSI4CfR065hFzroCb0l7BaFVxDtELVeC Kc+4Q30ISN5MYj1X6mDZs32d5dO4REgEGGfka3SwpISJj7Zhu6sQevSWGCJbd49HivSe IHMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0IrHFWxNEWMyyvUPeyxK1Yq2040dMR8lBMOGFu0gaKs=; b=BTgsb4GGT13Y0v6k1WwFSAuFfPbgfegutItkroH42JodnsK9VBQ0mNythhseV5v6sU eaZZyaJ2ZwI6RXJi+f2TgSRrZCjmKlBxrZ8wL49rBek3GZZF1PhVB+b9pWLM+ik3ZBHs PuHvBLVm12201Rtpbi10QnNXsjq851f6XSMLTNxQq/vhz0jXE/KdArey685rQFp13Oiv DHsgI5dv6KmaMZ4xgBckgW449tKVmoNdGohcpeC7ROYq81syocUwocbFgfqS8QZnjD+8 tzGFgcBagL0zDd2Gs4Z3Ev/UHaGof+L/E0ZRM47ROXt7ORhPk+HeH5bG/9l9u3km9CgA SVgg== X-Gm-Message-State: AHQUAuanCSogIY16lOxvRh2yd0OXWYRRGb2JGZu/NOB6Wxtq7WWxiZ/B S5nE8+dMzynVlFBGrPnoYfuaNHCuGIcTUPeQk1Q0Rw== X-Google-Smtp-Source: AHgI3IZacPO/sAPj8Y2owVcH9SEVxbIk6+a6irdqDMSyQT4iP/zqjLPPJ7CKi1HtyS9kk17Drxs4AOtKHvcN/z6nkfg= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr1245199ioh.95.1550086714526; Wed, 13 Feb 2019 11:38:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Wed, 13 Feb 2019 11:38:23 -0800 Message-ID: To: Ted Hardie Cc: RTCWeb IETF , Sean Turner , Adam Roach Content-Type: multipart/alternative; boundary="000000000000fe01a10581cbaf35" Archived-At: Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15). X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 19:38:40 -0000 --000000000000fe01a10581cbaf35 Content-Type: text/plain; charset="UTF-8" I support this change, solely to avoid confusion for implementers caused by different guidance from JSEP and ice-sip-sdp. On Wed, Feb 13, 2019 at 10:53 AM Ted Hardie wrote: > As an individual, I support this change. While I agree that the benefit > is currently theoretical, I think having the breadcrumbs for what to do > when it ceases to be theoretical is worth the effort. > > Ted > > On Fri, Feb 8, 2019 at 10:42 AM Ted Hardie wrote: > >> Over the the past few weeks, the working group has discussed whether to >> adopt a change to JSEP which would adjust how the ICE proto line transport >> parameters are populated in certain mid-session offers where the final >> candidate is a TCP candidate. Outside of the extensive working group >> discussion on the mailing list, participants may also wish to review the >> follow issue: >> >> https://github.com/rtcweb-wg/jsep/issues/854 >> >> and the conversations related to these two pull requests: >> >> https://github.com/rtcweb-wg/jsep/pull/862 >> and >> https://github.com/rtcweb-wg/jsep/pull/863 >> >> The chairs believe that there is technical consensus that this proposed >> change would not materially affect JSEP-only exchanges, since this >> parameter is ignored in those. >> >> The remaining technical issues are: >> >> * whether making one of these changes would improve interoperability >> between WebRTC and non-WebRTC clients which use SIP/SDP. >> >> * whether the additional complexity in tracking the use of UDP vs. TCP >> and populating the parameter accordingly is onerous or unwarranted for >> WebRTC implementations. >> >> After reviewing the discussion to date, the chairs believe that there is >> rough consensus for the first point, though there is also broad agreement >> that the benefit of this change is currently theoretical, since no existing >> WebRTC browser implementation has relevant code. >> >> On the second point, the chairs believe that there is no consensus yet >> demonstrated. Because we believe that this is in part because the actual >> proposal has not been entirely clear, and the complexity is therefore >> somewhat hard to gauge, the chairs wish to make a specific call for >> consensus. >> >> Does the working group approve the change in the following PR: >> >> https://github.com/rtcweb-wg/jsep/pull/863 ? >> >> Working group participants who have objections to the change are asked to >> specify whether they believe it has a technical fault, whether they object >> on the basis of its complexity, or whether they have other issues related >> to the change they need to raise. >> >> The chairs are already aware of the objection of Eric Rescorla on the >> basis of complexity, and will factor it into the review. >> >> Please send comments by February 15th, 2019. >> >> regards, >> >> Ted Hardie and Sean Turner >> >> >> _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000fe01a10581cbaf35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support this change, solely to avoid confusion for imple= menters caused by different guidance from JSEP and ice-sip-sdp.



On Wed, Feb 13, 2019 at 10:53 AM Ted Hardie <ted.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
As a= n individual, I support this change.=C2=A0 While I agree that the benefit i= s currently theoretical, I think having the breadcrumbs for what to do when= it ceases to be theoretical is worth the effort.

<= div>Ted

On Fri, Feb 8, 2019 at 10:42 AM Ted Hardie <ted.ietf@gmail.com> wro= te:
Over the the past few weeks, the working group has discussed=20 whether to adopt a change to JSEP which would adjust how the ICE proto=20 line transport parameters are populated in certain mid-session offers=20 where the final candidate is a TCP candidate.=C2=A0 Outside of the extensiv= e=20 working group discussion on the mailing list, participants may also wish to review the follow issue:


and the conversati= ons related to these two pull requests:

and

The chairs believe that there is technical consensus that this proposed=20 change would not materially affect JSEP-only exchanges, since this paramete= r is=20 ignored in those.=C2=A0

The remaining technic= al issues are:=C2=A0

* whether making one of = these changes would improve interoperability between WebRTC and non-WebRTC = clients which use SIP/SDP.

* whether the additional complexity in tracking the use of UDP vs. TCP=20 and populating the parameter accordingly is onerous or unwarranted for=20 WebRTC implementations.

After reviewing the=20 discussion to date, the chairs believe that there is rough consensus for the first point, though there is also broad agreement that the benefit=20 of this change is currently theoretical, since no existing WebRTC=20 browser implementation has relevant code.

On=20 the second point, the chairs believe that there is no consensus yet=20 demonstrated.=C2=A0 Because we believe that this is in part because the=20 actual proposal has not been entirely clear, and the complexity is=20 therefore somewhat hard to gauge, the chairs wish to make a specific=20 call for consensus.

Does the working group approve= the change in the following PR:


Working group participants who have objections to the change are asked to=20 specify whether they believe it has a technical fault, whether they=20 object on the basis of its complexity, or whether they have other issues related to the change they need to raise.

The cha= irs are already aware of the objection of Eric Rescorla on the basis of com= plexity, and will factor it into the review.

Pleas= e send comments by February 15th, 2019.

regards,

Ted Hardie and Sean Turner


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000fe01a10581cbaf35-- From nobody Thu Feb 14 11:24:12 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6420F12EB11 for ; Thu, 14 Feb 2019 11:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3Yxc1HOzN34 for ; Thu, 14 Feb 2019 11:24:00 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1FF1200ED for ; Thu, 14 Feb 2019 11:24:00 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id x9so4314459qkf.0 for ; Thu, 14 Feb 2019 11:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xWLbt88AkC3sznlMnrKlC7vCE67xYnr8vo0ZFCgJgMc=; b=ejIKBEchjc7OoG8UAtNFxzAkYXTWDGCpmXOzcmcGvxBZgAtTzKHy+7DmYrc8U2MOJI bXZ+eO228p0yzWNjej+iA/J9SuaDseGnJW1m9wS0NadPZjig2QQcxjl4I4M5WiLEFwpt tOTMMIRA+/l2zWefezUFQPsPnECVSgFCb/r7g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xWLbt88AkC3sznlMnrKlC7vCE67xYnr8vo0ZFCgJgMc=; b=h39kfGKfsMoyb87/Fx9uMnaJbOEvPlKlmtkGXLoNXBYSXYQAP5Pp9kltppZHNWdEXB ePuv0zQzd2dQ1vwjhNxWVbaISsP99RXiM35oC9UJoRXohF2bQN6fzQ0AG4G0sBHJTdkq vlVILWqslLaKtnlWxz3A8r9ofOABHXBPDVl50/UNjNSZ1sxX7/Q0SPFtTiFmTL5FTbJD w3uicojSJ/hnrQ25qH5GgzQ2vx3aeKgrnDYfe1WOPvGHrGOzD1KMqfqmwW3r6l0UbLEw xEVsWz/u46fraDseEzTs8zYM/SxaXxP2qgoIh5vK7hBKgqsLbOYmh7y5COSd0dKPP0JU 9dZg== X-Gm-Message-State: AHQUAuYZ074wz917uHDhCh1idf8Xet408BkDPHjwY4mOs2XofF42jr1F gQuOxNaWkS5DaBpTU+VpzBr1lg== X-Google-Smtp-Source: AHgI3IaXtRvRMwYklE+MeA8tNvBTGfxDi75F/a4+U48XP8b/3TL5qZ55ZW4/qlrZzkx30oRyH67rnw== X-Received: by 2002:a37:7883:: with SMTP id t125mr4043748qkc.201.1550172239064; Thu, 14 Feb 2019 11:23:59 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id c10sm1833813qtm.64.2019.02.14.11.23.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 11:23:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <155000069929.8344.2037971001030338378@ietfa.amsl.com> Date: Thu, 14 Feb 2019 14:23:56 -0500 Cc: ops-dir@ietf.org, draft-ietf-rtcweb-security.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155000069929.8344.2037971001030338378@ietfa.amsl.com> To: Joe Clarke X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:24:03 -0000 Hi! Doc Shepherd here ;) > On Feb 12, 2019, at 14:44, Joe Clarke wrote: >=20 > Reviewer: Joe Clarke > Review result: Not Ready >=20 > I have been assigned to review this document on behalf of the Ops = directorate.=20 > In general, I found the document well-written, but the reason I marked = it as > not ready as I was confused as to its standards track trajectory. I = do not see > any kind of inter-operable standard being defined here. On my reading = -- > before I noticed it was standards track -- it felt informational. = While it > does set out a threat model for the browser, I struggle to see how = that needs > to be standardized. The rationale I provided in the Shepherd write was this: This draft is bound standards track because it includes all of the = WebRTC security considerations and will referred to from all WebRTC WG = drafts. There are also 8 2119-MUSTs/MUST NOTs is the document that affect = browser behavior, which (I think) gets it over the informational level = hurdle. > On that threat model note, the abstract indicates that the WebRTC = threat model > will be laid out, but section 3 defines a more general browser threat = model. It does, but the 1st sentence explains why they are the same. I guess = we could rename the section, but it=E2=80=99s just a layer of = indirection. > Beyond those items, I noticed various nits and other small items when = reading > the document. Most broadly, I feel this document would benefit from a > terminology section to define acronyms such as ICE, TURN, STUN, VoIP, = etc.=20 > Additionally, in section 3.1, the document refers to "scripts" in a = general > way. While the implication is JavaScript code that will run in a = browser, I > think that kind of context setting might be made more explicit in a = terminology > section. >=20 > Other nits are mentioned below on a section-by-section basis. I addressed these in the following PR: https://github.com/rtcweb-wg/security/pull/13 > Section 1: >=20 > s/implementated/implemented/ >=20 > =3D=3D=3D >=20 > Section 3.2: >=20 > s/provide a escape hatch/provide an escape hatch/ >=20 > =3D=3D=3D >=20 > Section 4.2: >=20 > s/signficant/significant/ >=20 > =3D=3D=3D >=20 > Section 4.2.3: >=20 > s/ threats is less severe/threats are less severe/ >=20 > =3D=3D=3D >=20 > Section 4.3: >=20 > s/ The calling service is is/The calling service is/ >=20 > =3D=3D=3D >=20 > Section 4.3.2.1: >=20 > OLD: >=20 > (a) the browser to trusted UI to provide the name and >=20 > I don't grok this sentence fragment. There seems to be a verb = missing, and I'm > not sure what your intent is here. I suggest =E2=80=9Cthe browser has trusted UI =E2=80=A6=E2=80=9D. if = that=E2=80=99s wrong I can amend the PR. > =3D=3D=3D >=20 > Section 4.3.2.2: >=20 > s/e.g., read aloud over the the voice/e.g., read aloud over the voice/ >=20 > s/However, it it is well-known/However, it is well-known/ From nobody Thu Feb 14 11:35:31 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C07128B33; Thu, 14 Feb 2019 11:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61AoL4-B_OHi; Thu, 14 Feb 2019 11:35:21 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDFF131190; Thu, 14 Feb 2019 11:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2938; q=dns/txt; s=iport; t=1550172920; x=1551382520; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Jzj+X0bLSPI+flvduXRel3gSPQyiPmcFZc4/WASf85Y=; b=lHoIeqCOZW6b9UJdnHzbwtCjaERP7L6NNSEax2k7Zaw7pqx0jmkeQFuY 3BrQNA3WQ5goyUicGgjc7IJFNEzaJmqUSbvJXiVgwFu++I8OX4X71mpbV Ga/24ab+a0lGB11G7Sg1WlYbcBbApga8I06+X9uAWHLYWvZz0wk3stUEO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXAADEwWVc/5NdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYIDZwOBACeEBpQLgWAIJZoODSOESQKDYyI4EgEDAQE?= =?us-ascii?q?CAQECbRwMhUoBAQEBAgEjDwFGEAkCGAICJgICVwYNBgIBAYMcAYFqCA+PG5t?= =?us-ascii?q?hgS+KMwWBC4s5F4FAP4ERJwyCX4MeAoFhd4ISglcCkECBBoVzi3UJhzqLFAY?= =?us-ascii?q?ZgW6IbCaHc499jFWBXSGBVk0jFYMngigXg0uKcSEDMAyQUAEB?= X-IronPort-AV: E=Sophos;i="5.58,369,1544486400"; d="scan'208";a="515674795" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2019 19:35:19 +0000 Received: from [192.168.10.214] (rtp-jclarke-nitro5.cisco.com [10.118.87.86]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTP id x1EJZJpU019656; Thu, 14 Feb 2019 19:35:19 GMT To: Sean Turner Cc: ops-dir@ietf.org, draft-ietf-rtcweb-security.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org References: <155000069929.8344.2037971001030338378@ietfa.amsl.com> From: Joe Clarke Openpgp: preference=signencrypt Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= mQGiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3bQeSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+iF8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL27kBDQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wviE4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfq5AQ0EOjVwnhAEAISFEZSt e45iDHTCLknBVOsSvo5CoFVRa45UR+by1drKaYx/7kOezDBrjnLOz3JFwpz4wVfE5t9k7sPn wsq23NoLdKLok/+Vlo9BDHgH1nsNcwV19qJBny6kuoLnFQ0urXBBTej5iRJl/rVg3Joqsf8V 4knzFWIizHZSvmA5DAw7AAMFA/9wVjsn3ZwRhyr9vM8fucKv9r4WJ1GAgHVQ9mVgiYs0EzG5 HMRCCgMLQI+sqiqvWofNp7eFR5eWXo1XuO470dp18CeVUPXiE7k40yw8Pt6q/ZTdO+1Wd9oc m+VCyXFu+eo/Wd2AdhUwDcOih4AoWklVcfZGCRZQIIK2lO5ot/f8L4hOBBgRAgAGBQI6NXCe ABIJEM3tNcJabgLfB2VHUEcAAQEG3QCfUfEs1DJbrva/dwTL+nwFvY+qk2YAn2HBAKjjCb/t 2fmMS4g7VnAmOEn6 Organization: Cisco Message-ID: <717ca3f4-a1bd-a56a-2585-e19547c21b2e@cisco.com> Date: Thu, 14 Feb 2019 14:35:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.118.87.86, rtp-jclarke-nitro5.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-security-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:35:23 -0000 On 2/14/19 14:23, Sean Turner wrote: > Hi! Doc Shepherd here ;) > >> On Feb 12, 2019, at 14:44, Joe Clarke wrote: >> >> Reviewer: Joe Clarke >> Review result: Not Ready >> >> I have been assigned to review this document on behalf of the Ops directorate. >> In general, I found the document well-written, but the reason I marked it as >> not ready as I was confused as to its standards track trajectory. I do not see >> any kind of inter-operable standard being defined here. On my reading -- >> before I noticed it was standards track -- it felt informational. While it >> does set out a threat model for the browser, I struggle to see how that needs >> to be standardized. > > The rationale I provided in the Shepherd write was this: > This draft is bound standards track because it includes all of the WebRTC > security considerations and will referred to from all WebRTC WG drafts. > > There are also 8 2119-MUSTs/MUST NOTs is the document that affect browser behavior, which (I think) gets it over the informational level hurdle. Not sure, TBH. The way it read to me was more informational, which is why I was surprised to see it on the standards track after the read-through. But given this extra bit of context about its intent, perhaps standard is the way to go. I'm glad it's been considered/discussed, and I would defer to ADs on that. > >> On that threat model note, the abstract indicates that the WebRTC threat model >> will be laid out, but section 3 defines a more general browser threat model. > > It does, but the 1st sentence explains why they are the same. I guess we could rename the section, but it’s just a layer of indirection. It is. But while the requirements follow directly, there are additional considerations. I think renaming would make it clearer. > >> Beyond those items, I noticed various nits and other small items when reading >> the document. Most broadly, I feel this document would benefit from a >> terminology section to define acronyms such as ICE, TURN, STUN, VoIP, etc. >> Additionally, in section 3.1, the document refers to "scripts" in a general >> way. While the implication is JavaScript code that will run in a browser, I >> think that kind of context setting might be made more explicit in a terminology >> section. >> >> Other nits are mentioned below on a section-by-section basis. > > I addressed these in the following PR: > https://github.com/rtcweb-wg/security/pull/13 Thanks! >> === >> >> Section 4.3.2.1: >> >> OLD: >> >> (a) the browser to trusted UI to provide the name and >> >> I don't grok this sentence fragment. There seems to be a verb missing, and I'm >> not sure what your intent is here. > > I suggest “the browser has trusted UI …”. if that’s wrong I can amend the PR. To that correction, perhaps, "the browser has a trusted UI" Joe From nobody Fri Feb 15 14:56:46 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA79131130 for ; Fri, 15 Feb 2019 14:56:44 -0800 (PST) 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 VBhwdToxrw8Q for ; Fri, 15 Feb 2019 14:56:43 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 C9BCD131129 for ; Fri, 15 Feb 2019 14:56:42 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id y184so28053557itc.1 for ; Fri, 15 Feb 2019 14:56:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=l8sQPwe37FrdFeQx6aQds7QJeQM6e08Tle2FpLOvX4U=; b=CpbKd0E5vMfkAN/IXr5g/ZfC+QQvJLSuEQiaL1EF7h2NRzejtA8aWZbvY9Otw7Ndiw 6pAo1wCyq/WJLrLH9RsgqNFqWTVKYrQ20V3ExPcF74iAJdzI1d3HCybPTR6sNLJVQP5E XgEMpiNfQdXHhLK6dwqwxoLu/xWf8gMT0ad851g6lD61OVSPbGT1NCx1zSFO0SjKFH+j ypcS8X9ovDt8bT1+vRJBnNo7KR9AXNWK45rexnoBUXBDnOJphhVEpgd0nhaDtSpVjTiz AKb21ue2kYshTgvNHpLqBrV08GT/Xifk9ddS5Q2AUEnzq0hgtlhIh5ue+uHDoB66BJ6Z +T0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l8sQPwe37FrdFeQx6aQds7QJeQM6e08Tle2FpLOvX4U=; b=m6sRCLaLgp6M9U0s/Jut/L7gC6tcqN51sz28FDrMOjr7rLMgP/mo+5gKYUctAu5ye1 5Z8y58Yue7i+K3a0YDP8RDEaDEicAcJXy/zx5cEfOvr80HeenHgk0k2cYhYAtUqsooDV y/d9TJfgNjpg70PYlK/kr7EuReVVsTHShU3YdRoDypRGzxZ9scxRgjGmL8JVLW/4XKrv n/wJFCAux3dfXujVeabMdDSR+nIGWudHmBh6ZVfWPo7ChGoU/S7ihHAEeRuYSS/rVC+p eXxYyOcXIU1m75GKrJsCzXWD1iDoHvtSJWmaldYFG0CdiaXiHUcJlxwulrwzMLyyFjO3 P9aw== X-Gm-Message-State: AHQUAuar0Fv7lgu9KTV6/mJtpqvixpHq365R1szcnIN6lNbElwwcvE4I vXHjMxISFEYy4YIg1RwtAZDRZSYes6x+fmyd3VDtXphpdkA= X-Google-Smtp-Source: AHgI3IbQUGGIxVQy+LkugAh3eqzyAN4v2ocDTk4Bg0MgNNEpW7PEzBoxCrTnTE0/VPjZcNNv/93ak2Y3g7GyOjQTVU8= X-Received: by 2002:a02:cd11:: with SMTP id g17mr6772154jaq.79.1550271401479; Fri, 15 Feb 2019 14:56:41 -0800 (PST) MIME-Version: 1.0 From: Ted Hardie Date: Fri, 15 Feb 2019 14:56:15 -0800 Message-ID: To: RTCWeb IETF , Adam Roach , Sean Turner Content-Type: multipart/alternative; boundary="00000000000030d2f40581f6b0ac" Archived-At: Subject: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 22:56:45 -0000 --00000000000030d2f40581f6b0ac Content-Type: text/plain; charset="UTF-8" The chairs believe that there was rough consensus among those responding to make the change in: https://github.com/rtcweb-wg/jsep/pull/863 Given the state of the document, it will be the Area Director's call as to how much of the post-working group approval process must be re-done. Authors, please wait on his direction before publishing a new version with this merged. Regards, Ted and Sean --00000000000030d2f40581f6b0ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The chairs believe that there was ro= ugh consensus among those responding to make the change in:

<= /div>

Given the sta= te of the document, it will be the Area Director's call as to how much = of the post-working group approval process must be re-done.=C2=A0 Authors, = please wait on his direction before publishing a new version with this merg= ed.

Regards,
Ted and Sean
<= /div>
--00000000000030d2f40581f6b0ac-- From nobody Fri Feb 15 17:57:16 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B373F130E58 for ; Fri, 15 Feb 2019 17:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYE9Xu0Tkirg for ; Fri, 15 Feb 2019 17:57:12 -0800 (PST) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 B2DB9130E3F for ; Fri, 15 Feb 2019 17:57:12 -0800 (PST) Received: by mail-it1-x134.google.com with SMTP id v72so28142562itc.0 for ; Fri, 15 Feb 2019 17:57:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UrNU2fCxQf04O8OON0JcCw0YHPI65oN8hIFu3PdDOJs=; b=c1zFHPPboG5w5L36YrU7sG9OkwKm8MKGOSkKiKOTBel3VBTYlKJaO5N88NGuWJYtJp hWIXJAytsAf0NSkAKCXitk8fLo/Vxy73JA2NMmnyNge3uvHR8GhruC9kmUOTgEel/iu/ W6r+10LyZWBxPeoJ18en/YzwX7MBCI/LUWA7m9NHFWgPq2LiFWYLOoJOefW6s9BnoZ/j 27dv9GRwHXqJiq1u/iS6Wx52bTRVIg4mZYGnED89ouFbvjdmjGQF32Gmffeija9Nmfxi S3+zTtgFOdIzAKs3reAV8en3HwjhzwVKEGEGnGS3uZh2tgbXqZHNBjQ0xtm/jNMJZwdE qKYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UrNU2fCxQf04O8OON0JcCw0YHPI65oN8hIFu3PdDOJs=; b=mPRO3TnlgSRuoQrU3TVBCiZqX1dLhonzh/9fzsfWRdHzV4QQkS68xaQob6e0QxGBbX tE/YvFBAqzH99Jutlg2axPfJxsZ9g05/AzU/Lf18SQLDchWNG7mJFoKXK6dtlrQFdN+a tWD/y/1mxiBmgy/ePchfvCZCkb2VHWioBS6L9IHrFFxTD45DbqeZYw0nO5fIWNnZJQdE np+o/N4x8ud2TDQ4NGHeJ3vTMgXBan3QyQiff5oVtQG2XiIw9LpXX7tbg0pnhOGGHdVX Wkui1beZnnnlbsScYdefa5FAVj9ik8BAVPQ4bdq1HK3pmGj2kpW6vnithGuc5cHUZBJ0 ND2A== X-Gm-Message-State: AHQUAuat/iR0Ay4ixfz2KdiNrqw9daR9H3Z9KQi6QTZVBVynYn0C1cme jxbwF4+hyc2LTjH3iDMqw3ISgHrv+7o1fjL/b1e1zg== X-Google-Smtp-Source: AHgI3Ibmo9O+LUhJrFmkNx1aB8lL1OoYpchLVURpheT/rfivmuFekmQJFAA3dnMpqvZVVAuHTUvY3WvsSSRiuDpb9Qw= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr6868894ioh.95.1550282231555; Fri, 15 Feb 2019 17:57:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Fri, 15 Feb 2019 17:56:57 -0800 Message-ID: To: Ted Hardie Cc: RTCWeb IETF , Adam Roach , Sean Turner Content-Type: multipart/alternative; boundary="000000000000b70d000581f93567" Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 01:57:15 -0000 --000000000000b70d000581f93567 Content-Type: text/plain; charset="UTF-8" I have updated this PR to incorporate minor feedback that was received during the consensus call. Those who had feedback, please take another look and comment on the PR if you are satisfied. On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie wrote: > The chairs believe that there was rough consensus among those responding > to make the change in: > > https://github.com/rtcweb-wg/jsep/pull/863 > > Given the state of the document, it will be the Area Director's call as to > how much of the post-working group approval process must be re-done. > Authors, please wait on his direction before publishing a new version with > this merged. > > Regards, > Ted and Sean > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000b70d000581f93567 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have updated this PR to incorporate minor feedback that = was received during the consensus call. Those who had feedback, please take= another look and comment on the PR if you are satisfied.

On Fri, Feb 15, 20= 19 at 2:56 PM Ted Hardie <ted.ietf= @gmail.com> wrote:
The chairs believe that t= here was rough consensus among those responding to make the change in:


Given the state of the document, it will be the Area Direct= or's call as to how much of the post-working group approval process mus= t be re-done.=C2=A0 Authors, please wait on his direction before publishing= a new version with this merged.

Regards,
Ted and Sean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000b70d000581f93567-- From nobody Sun Feb 17 07:06:22 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9ED12D4EA; Sun, 17 Feb 2019 07:06:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: Ted Hardie , ted.ietf@gmail.com, rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155041598050.4092.17319548267050845938.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2019 07:06:20 -0800 Archived-At: Subject: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 15:06:21 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-rtcweb-fec-08: 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-fec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3278 COMMENTS S 5.2. > as described in [RFC5956], Section 4.1 is not currently defined for > WebRTC, and SHOULD NOT be offered. > > Answerers SHOULD reject any FEC-only m-lines, unless they > specifically know how to handle such a thing in a WebRTC context > (perhaps defined by a future version of the WebRTC specifications). It seems like the above three paragraphs are generic to this document, and just grouped with video because the audio codecs tend to have internal FEC? If so, maybe put them elasewhere? S 9. > > As described in [RFC3711], Section 10, the default processing when > using FEC with SRTP is to perform FEC followed by SRTP at the sender, > and SRTP followed by FEC at the receiver. This ordering is used for > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as > described in [RFC5764], Section 4.1.2. I of course agree with this text, but I wonder if it's maximally clear. Perhaps rewrite the first sentence as: ```The FEC schemes described in this document use other packets to recover when a packet is lost or damaged but do not allow for recovery of a damaged packet on its own. This is consistent with the default processing for using FEC with SRTP described in RFC 3711, which is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver, which implies that damaged packets will be rejected by the SRTP integrity check and discarded.``` From nobody Sun Feb 17 09:55:34 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 130EB12D4E8; Sun, 17 Feb 2019 09:55:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Touch To: Cc: draft-ietf-rtcweb-ip-handling.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155042612497.4083.2465692313767522646@ietfa.amsl.com> Date: Sun, 17 Feb 2019 09:55:25 -0800 Archived-At: Subject: [rtcweb] Tsvart last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 17:55:25 -0000 Reviewer: Joseph Touch Review result: Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This document has no significant transport issues. As a very minor issue, the document refers to the use of UDP "connect": Once a suitable remote IP has been determined, the implementation can create a UDP socket, bind it to the appropriate wildcard address, and tell it to connect to the remote IP. Generally, this results in the socket being assigned a local address based on the kernel routing table, without sending any packets over the network. It might be useful to be more clear that this is an OS command (not a protocol one). If the particular semantics of this command are relevant, that should be noted as well. From nobody Sun Feb 17 13:58:24 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8468A124BAA; Sun, 17 Feb 2019 13:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.77 X-Spam-Level: X-Spam-Status: No, score=-0.77 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 3nIYQ2Gc1bHA; Sun, 17 Feb 2019 13:58:07 -0800 (PST) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 EA2171292F1; Sun, 17 Feb 2019 13:58:03 -0800 (PST) Received: by mail-vk1-xa35.google.com with SMTP id y14so3439450vkd.1; Sun, 17 Feb 2019 13:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2nko5san7wRXwnLLnnjXJAYWvO8KjlymykUhNCeqWys=; b=qq7MOwMuT7W2KnC1yG/0cBbb5GWM9T29lQM/dTcsRJFPmik2KrEpzx1ikk+zXIznbo ENBG1N7hoWrEyiNR9dqyL2fkTvfAVwomm3dm1fMxW0G3LGLmUbwItsW09ILHDLl3ycER 8RRUYjDiQgAYFDFFZhXLypJ85gxnVpYrPnl6xgRtQWY+HULX8OfaJwKMfocOBGz+BS1C ZcQPxx137drCYYb4eRYKIoXEPqz1e+pPbs3GBrxU21gmZG/lJ3USZVUoTx1ypvcE8CLJ 0F9e35VU8xlQm/DrgkbPlQCYWZOGqs6D8LTz+Nh+2h5kP7ktcXPWRXnOE+ERb3wgCmt2 WZFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2nko5san7wRXwnLLnnjXJAYWvO8KjlymykUhNCeqWys=; b=dWA3QvPqkJqh9VCIMmP38lTBiY3sqS9kVX3ylcFE2CS4JNR/zfegwP6i5EqGsBFvwn DHevHZ8il7uBDnnx3egc3HcaOwrgpYrVKT+w3ymrxwPlaHPnIXDPIneT8Kfrcbuycdtz Jo+2sVh+AfIxBEMlLobAjXH77lgxXMV+15DAPC+icw3dXi6vXYk7tGN3SFxIFztQnAJp d+DGl4dP2Hj/uwOgp3t/rfzJIuLe5ICarE7LS0+c4ep4RqQb/6LzUYZjuL2JpYtfhmcO F/5CgaMdiIPCYgBSlnP7LzKFer2wFMfpQgEt2EoyCIySUpMlYWW7cbJd3IB0dtoGJBSR Tvag== X-Gm-Message-State: AHQUAubBtzzhyuW2JUumkrAYNAFqYDfknYh9iZkX/iln+ZpWXG6BlGpZ v9WbJDudLmzRXmcRu/vCbHpqI5anP8lktr1d3aF+T3M= X-Google-Smtp-Source: AHgI3IaijKr3eCdHsEPmqSpBpiK4vIuE5Sapel7gW8WE6/CWwPGSYNmT8DqtDY+jWhOgNf7f/A8q6F6Fim90K+LXrQY= X-Received: by 2002:a1f:1ac3:: with SMTP id a186mr10501414vka.34.1550440682373; Sun, 17 Feb 2019 13:58:02 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?157XoNeX150g15PXldeT15In?= Date: Sun, 17 Feb 2019 23:57:50 +0200 Message-ID: To: ops-dir@ietf.org Cc: ietf@ietf.org, rtcweb@ietf.org, draft-ietf-rtcweb-ip-handling.all@ietf.org, justin@uberti.name Content-Type: multipart/alternative; boundary="0000000000001e460005821e1aef" Archived-At: Subject: [rtcweb] [OPS-DIR] Opsdir last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 21:58:09 -0000 --0000000000001e460005821e1aef Content-Type: text/plain; charset="UTF-8" Reviewer: Menachem Dodge Review Result: Has Nits This document has "Intended Status" for the Standards Track but the document is written as an informational guide. I suggest that the ADs decide whether this is informational or for the Standards Track. On the whole the document is written well and is understandable. In Section 5.2 it states that: "Mode 1 MUST only be used when user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to *getUserMedia *consent. " I'm not sure what "getUserMedia consent" refers to. While the document defines that Mode 1 should be used when there is user consent and Mode 2 should be used when there is no User consent , however when should Mode 3 and Mode 4 be used? The document also states that: "Future documents may define additional modes and/or update the recommended default modes. " If this is the case should there be a "version" defined so that the webRTC client and Server no which implementation has been implemented? Thank you kindly, Best Regards, Menachem --0000000000001e460005821e1aef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
Reviewer: Menachem Dodge=C2=A0
Review Result: Has Nits

<= div dir=3D"ltr">This document has "Intended Status" for the Stand= ards Track but the document is written as an informational guide. I suggest= =C2=A0 that the ADs decide whether this is informational or for the Standar= ds Track.

On the whole the= document is written well and is understandable.=C2=A0

In Section 5.2 it states that:

=C2=A0 "Mode 1 MUST only be used w= hen user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent.=C2=A0 =C2= =A0"

I'm not = sure what "getUserMedia consent" refers to.

While the document defines that Mode 1 should b= e used when there is user consent and Mode 2 should be used when there is n= o User consent , however when should Mode 3 and Mode 4 be used?

The document also states that:=C2=A0<= /div>

=C2=A0 "Future docume= nts may define additional modes and/or update the recommended default modes. "=C2=A0

If this is the case should there be a "version"= ; defined so that the webRTC client and Server no which implementation has = been implemented?

Thank yo= u kindly,

Best Regards,
Menachem


--0000000000001e460005821e1aef-- From nobody Sun Feb 17 14:33:07 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37864124D68; Sun, 17 Feb 2019 14:33:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-rtcweb-fec@ietf.org, Ted Hardie , rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2019 14:33:05 -0800 Archived-At: Subject: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 22:33:05 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-rtcweb-fec-08: 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-fec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 nit: The subsequent discussion seems to indicate that at least some of these mechanisms are already specified and not new in this document; (if so) it would be nice to have the exposition reflect that. Section 3.3 For Opus, packets deemed as important are re-encoded at a lower bitrate and added to the subsequent packet, allowing partial recovery Is "added" supposed to be something other than "appended" (which strongly resembles the "redundant encoding" of the previous section)? Section 4.1 Does it make sense to give subsection backreferences when talking about (e.g.) redundant encoding? Section 5.2 Support for a SSRC-multiplexed flexfec stream to protect a given RTP stream SHOULD be indicated by including one of the formats described in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an nit: Since this Section 5 is solely for video, is it more appropriate to refer to Section 5.1.2 ("Registration of video/flexfec") of draft-ietf-payload-flexible-fec-scheme? Section 7 To support the functionality recommended above, implementations MUST be able to receive and make use of the relevant FEC formats for their supported audio codecs, and MUST indicate this support, as described in Section 4. Use of these formats when sending, as mentioned above, is RECOMMENDED. Just to double-check: this is explicitly only mandating FEC for audio and ignoring video entirely? Section 8 Because use of FEC always causes redundant data to be transmitted, and the total amount of data must remain within any bandwidth limits indicated by congestion control and the receiver, this will lead to less bandwidth available for the primary encoding, even when the redundant data is not being used. This is in contrast to methods like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] retransmissions, which only transmit redundant data when necessary, at the cost of an extra roundtrip. This seems to imply that "FEC" is a specific usage and that flexfec is not a subset of generic FEC. If so, this could probably be reworded to be less confusing to the reader (though my suspicion is that the "always causes redundant data to be transmitted" is only intended to apply to specific mechanisms from Section 3). Section 9 This document seems to be agnostic on the question of RTP vs. SRTP; I would consider referencing their respective security considerations as well as what is already covered here. As described in [RFC3711], Section 10, the default processing when using FEC with SRTP is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver. This ordering is used for all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as described in [RFC5764], Section 4.1.2. I was going to comment about the lack of clarity here, but I see that Ekr has already gotten the core points, and that the secdir review has already resulted in some chanegs in the editor's copy. It would be nice to have the result of the (merged) edits available to look at, though. From nobody Tue Feb 19 04:52:09 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B108130E91; Tue, 19 Feb 2019 04:51:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-rtcweb-fec@ietf.org, Ted Hardie , rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155058071936.20784.14656321188511454784.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2019 04:51:59 -0800 Archived-At: Subject: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-rtcweb-fec-08=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 12:52:00 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-rtcweb-fec-08: 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-fec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not fully sure about the intended status of this document. The shepherd write-up says "the document has normative requirements for conforming WebRTC implementations", however, for me it seems this document makes "only" recommendations and has actually no normative requirements. Therefore informational status might be more appropriate, however, I will not block publication as PS. One mostly minor editorial note: Sec 3.3: "experiments performed indicate that when Opus FEC is used, the overhead imposed is about 20-30%, depending on the amount of protection needed." Would it be possible to provide a reference for this number? Also this section says: "See [RFC6716], Section 2.1.7 for complete details." However, section 2.1.7 in RFC6716 is very short and actually does not provide any details... From nobody Tue Feb 19 12:04:54 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAEC1310DD for ; Tue, 19 Feb 2019 12:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=I8cyCSBG; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jmuwVPHx 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 xPSiEMbbG_Au for ; Tue, 19 Feb 2019 12:04:44 -0800 (PST) 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 BCD6B130F1D for ; Tue, 19 Feb 2019 12:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550606682; x=1553198682; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JSQUvN5E2srI14moi/qod0T4KQ5P605plPvfmkPbwS0=; b=I8cyCSBGfptcVFiEqs+CLi4cPXOaCjO+TZyiA+VaUFWvpT7iXzNnFfV0D6PSvmLL HFI956yGqZkuqNd478fa+NmK7DG4S6oxiNj2y2pg3gUsd8ouXynquJQAQ2k2nskh ruL8q+O6u8T5JsSUpRBAZRnAZ5bRf1zPOx5D/HA6Rho=; X-AuditID: c1b4fb25-d89ff70000005ff7-01-5c6c615a12a9 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 02.46.24567.A516C6C5; Tue, 19 Feb 2019 21:04:42 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 19 Feb 2019 21:04:41 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 19 Feb 2019 21:04:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JSQUvN5E2srI14moi/qod0T4KQ5P605plPvfmkPbwS0=; b=jmuwVPHxuvWVUIdzyq6bBP9qm/HpGXgijC36jTDGCstHrcJf2LevPkIdC/htywnFOtf7TblTcESZMqcDcHaaZOapIfEV0F+fctXztt4ZdkLVTUItzEezuZJrlGx/ydKAoAFNDtxXSUpYH6fN+K1msejftX0KdBeZESW1WwVfYew= Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB3392.eurprd07.prod.outlook.com (10.175.244.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Tue, 19 Feb 2019 20:04:40 +0000 Received: from VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::654f:5349:f2b4:176f]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::654f:5349:f2b4:176f%4]) with mapi id 15.20.1622.020; Tue, 19 Feb 2019 20:04:40 +0000 From: Christer Holmberg To: Justin Uberti , Ted Hardie CC: RTCWeb IETF Thread-Topic: [rtcweb] Results of call for consensus on ICE transport parameter issue Thread-Index: AQHUxYHCF4jGTlyGqkCBEfyt1ATxTKXhqseAgAYIbIA= Date: Tue, 19 Feb 2019 20:04:40 +0000 Message-ID: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.15.0.190117 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [192.176.1.94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2dff060f-1161-48ae-4630-08d696a57b9c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB3392; x-ms-traffictypediagnostic: VI1PR07MB3392: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzMzkyOzIzOnFnczAybDhVUkNPZnBpUTJxZWFLSnlOMHU0?= =?utf-8?B?RFlZQ09UQ0tMRkk0MzJGMkIxTGRkK2JyQjBaQXdQNERPSnJiTXdwaTNwVXZX?= =?utf-8?B?QXFObFBhNkp1RzlxVmx5TmNYWUJSb2ZTS0N0bkZ2WU9ldTRUTU5mdnB1L296?= =?utf-8?B?NjhYNlN1NkNVMjNPdFNyaTY2NmFaT05neTlUN0tYVFJGQ0dVWC8yekFSWTVl?= =?utf-8?B?RU5MSGRMQ0c3d1FTczlwNHd5T3BQYVpSU082c0dDR25jMDNKZjJBUU5qUWd1?= =?utf-8?B?MEp4ZC9QSHZWbW9ybXFZK0x0R0FtQ0tPRWtFWUk1K2lmV01xQ2hIWklzbFFs?= =?utf-8?B?a0FRQitJMEZTNzF0WHRWU2d2eWVGdzdrdFhqYnRJME1HeEt5Y1lXRzFHSHMz?= =?utf-8?B?QWtQYmltZnR5RkcrYmNGLzZuSE90ckMycUJlQ2lQT3l1SkRkMndOWXAxZ0Nh?= =?utf-8?B?MkpIZzJmaDZyTG5sRXlsWXNpMHNNSGdTQmYvRGNJaUxXTURBYkhvcCtxa0VY?= =?utf-8?B?bXI4cjVCR1RGYnZQOVRPZzRrbEhRN2hKVzhsVHlLWmVuN21KdnRPOWYwZW5v?= =?utf-8?B?NHdnb3AyS3dqRVg0Vml2V2pjZW1iOU94TkU1eWNnTlFYcUMzUytzTnozc2p6?= =?utf-8?B?Ylk5YWlGNFB1VzBtRlpJRm5BMWZDY01NbXZpTHdmZ3lMV01qM25BYTF4WUhR?= =?utf-8?B?REUwMGNiUjBvNjlpRnF4dERyV2J0TFd1NENFQzJUZjdodU1VMjhud3BBbExy?= =?utf-8?B?OTBtbXF1TDRiQkIvcWMxU3EwSGdGb2FDQTUvdlhGZGFoaFJKZXU0V3Fka1Nl?= =?utf-8?B?Z28vWTdERlNIamJYMWpZNTM5NnFZT1hNZk8rbjA4bkZNZytnYjdWTXlBQ1dm?= =?utf-8?B?MmZHbitHNmJWN2tzdVF2RVRhOUEyTHBOWTBRanUrQUtrYUc5cjhwcUhLYW41?= =?utf-8?B?TDdCa2F5R3Y4ODhNUS95N0VtelpmMU1HZGlPbG8xQUdCWW1LNDU5b0NOUThh?= =?utf-8?B?VjgvYWYrMXRPVWVxYkdMclovYS9Yd1NwaXM1NjVlRkJVZG5YOFFrWmNxV250?= =?utf-8?B?alZZY1l4UksyUmtGVGFPd0hBMU5ySDhvMlVMaENUNVNnYnJTcGs2eERNNzVl?= =?utf-8?B?Z3U2eksyOWdIQklZZlNYaFdnNldNVnZIVVY1RWduSndvQzk2d3M5L3EyZXFG?= =?utf-8?B?MmEwZEphNm84VWF6eE5LUy8xVGFoZG5FV3VITjVTQjRDNG02STF2MDdjL2pM?= =?utf-8?B?cWRpdUUwK3huNGg0ekM1TElqbFN0Q0dIa0xvdlVtWGFObXRHSmhHdWNxZXU3?= =?utf-8?B?NzBaM1lZaFJjWGYyYUIrTzhkUUNrZXpadHUwU0dBUEFyZm5MMzZka2F6TURU?= =?utf-8?B?T2ZDZkhhMUwvVnd3bFg5N0hnMml6VUE2R0wybU9RNElZUmJkemt3a3QrUHFw?= =?utf-8?B?c2x5eUVLTWZYbUVaTlJ0T1d3VjI2aEZSS0syc3hZUlhmZExtREN4RXIyUjlZ?= =?utf-8?B?NmdsaU1JYjUwUnpCNnRQd0QvSWF1QnhtT05KL0RVTEtvNUxVZHYyRmtXZENy?= =?utf-8?B?Y2dWME93QUFMUFBjb3FSQ28xZ2g4dHgzOVBuOEZMTzM3eTZTSnhLblc3SE9x?= =?utf-8?B?enhpM3hadU9BVStZT2NSWEhtRmlkd0ZmNmdTZEViendNNXhDRWwzdzBEb0pR?= =?utf-8?B?aFlnVkhqQ3BycWNWMHRwRklTY3F3KytYQWUvOEdSeTd0YUV2T0VUN3dXMU5a?= =?utf-8?B?Q2o2VWdnVDJDRGVwbE50TUs3eDB6YXVxclpJc29ucFIwQk9kMnducXF1SFVB?= =?utf-8?Q?Ca3r91OSxWGnQ?= x-microsoft-antispam-prvs: x-forefront-prvs: 09538D3531 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(366004)(39860400002)(346002)(189003)(199004)(186003)(44832011)(446003)(236005)(6486002)(6246003)(316002)(36756003)(83716004)(26005)(486006)(476003)(229853002)(53936002)(6506007)(256004)(102836004)(68736007)(53546011)(11346002)(54896002)(6306002)(86362001)(6436002)(71200400001)(71190400001)(5660300002)(6512007)(2616005)(76176011)(478600001)(106356001)(6116002)(3846002)(606006)(99286004)(966005)(66066001)(97736004)(14454004)(33656002)(81166006)(7736002)(110136005)(25786009)(2906002)(58126008)(82746002)(4326008)(8936002)(81156014)(8676002)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3392; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0guYTv/bI9DTIlO017qChaAIkv2SGmIAeVRvrM8ONkLRjKTKKSlHdrTQ1hdu0Ndf5HidqWXFwMmtTb2s+FhT33N+fUyP1lTsSxtB+DMwNqs5bs1KszkgSGgGLXl51AerpW7TZnQRI52XFG8iDJKoJFSxc+AzJz8KWGDgK97WIscy2JQ5WGThPITq7PsR1h3T6I+cQwAingU6/qfGVpdGpdfWKLtn/S77vny+RCqwEVrlzD3PFj2+L32fwoAf6DVHNeomSMh6gL0jz3tzqSME3SaMUWPdc/XBQY2Ef+yPafvCQRa3DZQjVVVqsh/WwsVQWe+bEiawz6IU6k5TQYMG+HscSj/lZt8PnQJrE484Heg9bunxHxfaDhfXimvAb0YiGtnDA/BYbH51ZBYWh9fPavxaaSYsbI6HObP0V62jR5w= Content-Type: multipart/alternative; boundary="_000_0F9730B23E44439D98324C4AEBC054B5ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2dff060f-1161-48ae-4630-08d696a57b9c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2019 20:04:40.6042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3392 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsUyM2J7pW5UYk6MwZWbTBYt3UdZLdb+a2e3 aJxr58DscWLZFVaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugStj6sffzAVv7Cq+dm5la2Bs t+1i5OSQEDCRmHbuKHsXIxeHkMARRoner9PZIJxvjBIr515ihnCWMEkc3P+TCcRhEZjALHHy 2WKonslMEiea5kM5jxgltnedBhrAwcEmYCHR/U8bZImIQJTE8uXnmUFsZgFFiS/L57OB2MIC YRKXH+9jhKgJl3gy9x8rhG0l8WJvC1gNi4CqxNaWz2A1vAL2Erv+nWeB2DWdUWLPm9vsIAlO gUCJ3j3TwRYwCohJfD+1hglimbjErSfzmSA+FZBYsgfiCAkBUYmXjyGWiQroS/xefpoFojdR Yv+qB1A1ChKt15tZIWxZiUvzuxkhbF+JZ692goNCQuAmo8ShTZegGrQkXrTfg7KlJL4//sgO UdQqJDGl6xdUd7bE60OL2CBsGYnbp6czT2DUm4XkWAg7WWLr0uvss8C+FpQ4OfMJyyxgoDIL aEqs36U/CxqQU7ofskPYGhKtc+ZC2R4Srzt+sSKrWcDIsYpRtDi1OCk33chYL7UoM7m4OD9P Ly+1ZBMjMFkd3PJbdQfj5TeOhxgFOBiVeHhfRubECLEmlhVX5h5ilOBgVhLhXekOFOJNSays Si3Kjy8qzUktPsQozcGiJM77R0gwRkggPbEkNTs1tSC1CCbLxMEp1cAof24pj47yEjOG0P21 CZ8KLVY+e/fPlGPmu3AVxQ0bWfTvRlw8YnB548zFihtqU9sXMGtmvV6xJGFGX91Uy4sZnlu+ C1/td7Et12951VQ6s9TMXMFX5pfb65/WPw8+z/N7LvPaa7d00vkDSj1vNG/NXCVm4l/nu+LD /d09CdnHJGN6VPN+qdUosRRnJBpqMRcVJwIAYMLgXVIDAAA= Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 20:04:53 -0000 --_000_0F9730B23E44439D98324C4AEBC054B5ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIDxydGN3 ZWItYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEp1c3RpbiBVYmVydGkgPGp1YmVydGk9 NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogU2F0dXJkYXksIDE2IEZlYnJ1YXJ5 IDIwMTkgYXQgMy41Nw0KVG86IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4NCkNjOiAi cnRjd2ViQGlldGYub3JnIiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJd IFJlc3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFyYW1ldGVy IGlzc3VlDQoNCkkgaGF2ZSB1cGRhdGVkIHRoaXMgUFIgdG8gaW5jb3Jwb3JhdGUgbWlub3IgZmVl ZGJhY2sgdGhhdCB3YXMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBjb25zZW5zdXMgY2FsbC4gVGhvc2Ug d2hvIGhhZCBmZWVkYmFjaywgcGxlYXNlIHRha2UgYW5vdGhlciBsb29rIGFuZCBjb21tZW50IG9u IHRoZSBQUiBpZiB5b3UgYXJlIHNhdGlzZmllZC4NCg0KT24gRnJpLCBGZWIgMTUsIDIwMTkgYXQg Mjo1NiBQTSBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdt YWlsLmNvbT4+IHdyb3RlOg0KVGhlIGNoYWlycyBiZWxpZXZlIHRoYXQgdGhlcmUgd2FzIHJvdWdo IGNvbnNlbnN1cyBhbW9uZyB0aG9zZSByZXNwb25kaW5nIHRvIG1ha2UgdGhlIGNoYW5nZSBpbjoN Cg0KaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL3B1bGwvODYzDQoNCkdpdmVuIHRo ZSBzdGF0ZSBvZiB0aGUgZG9jdW1lbnQsIGl0IHdpbGwgYmUgdGhlIEFyZWEgRGlyZWN0b3IncyBj YWxsIGFzIHRvIGhvdyBtdWNoIG9mIHRoZSBwb3N0LXdvcmtpbmcgZ3JvdXAgYXBwcm92YWwgcHJv Y2VzcyBtdXN0IGJlIHJlLWRvbmUuICBBdXRob3JzLCBwbGVhc2Ugd2FpdCBvbiBoaXMgZGlyZWN0 aW9uIGJlZm9yZSBwdWJsaXNoaW5nIGEgbmV3IHZlcnNpb24gd2l0aCB0aGlzIG1lcmdlZC4NCg0K UmVnYXJkcywNClRlZCBhbmQgU2Vhbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGN3ZWINCg== --_000_0F9730B23E44439D98324C4AEBC054B5ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Mb29rcyBnb29kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+cnRjd2ViICZsdDtydGN3ZWItYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIEp1c3RpbiBVYmVydGkgJmx0O2p1YmVydGk9NDBnb29nbGUuY29tQGRt YXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRheSwgMTYgRmVicnVhcnkg MjAxOSBhdCAzLjU3PGJyPg0KPGI+VG86IDwvYj5UZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFp bC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtydGN3ZWJAaWV0Zi5vcmcmcXVvdDsgJmx0 O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtydGN3ZWJdIFJl c3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFyYW1ldGVyIGlz c3VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhhdmUgdXBkYXRlZCB0aGlzIFBSIHRvIGluY29ycG9yYXRlIG1pbm9yIGZlZWRi YWNrIHRoYXQgd2FzIHJlY2VpdmVkIGR1cmluZyB0aGUgY29uc2Vuc3VzIGNhbGwuIFRob3NlIHdo byBoYWQgZmVlZGJhY2ssIHBsZWFzZSB0YWtlIGFub3RoZXIgbG9vayBhbmQgY29tbWVudCBvbiB0 aGUgUFIgaWYgeW91IGFyZSBzYXRpc2ZpZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxNSwgMjAxOSBhdCAyOjU2IFBNIFRlZCBIYXJk aWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20iPnRlZC5pZXRmQGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNoYWlycyBiZWxp ZXZlIHRoYXQgdGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBhbW9uZyB0aG9zZSByZXNwb25kaW5n IHRvIG1ha2UgdGhlIGNoYW5nZSBpbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13 Zy9qc2VwL3B1bGwvODYzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dl Yi13Zy9qc2VwL3B1bGwvODYzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGUgc3RhdGUgb2YgdGhlIGRvY3VtZW50LCBpdCB3 aWxsIGJlIHRoZSBBcmVhIERpcmVjdG9yJ3MgY2FsbCBhcyB0byBob3cgbXVjaCBvZiB0aGUgcG9z dC13b3JraW5nIGdyb3VwIGFwcHJvdmFsIHByb2Nlc3MgbXVzdCBiZSByZS1kb25lLiZuYnNwOyBB dXRob3JzLCBwbGVhc2Ugd2FpdCBvbiBoaXMgZGlyZWN0aW9uIGJlZm9yZSBwdWJsaXNoaW5nIGEg bmV3IHZlcnNpb24gd2l0aCB0aGlzIG1lcmdlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZCBhbmQgU2VhbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0F9730B23E44439D98324C4AEBC054B5ericssoncom_-- From nobody Tue Feb 19 13:19:13 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F05112D4EF for ; Tue, 19 Feb 2019 13:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OUalNqTTYTsA for ; Tue, 19 Feb 2019 13:19:09 -0800 (PST) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 05A2B12D4ED for ; Tue, 19 Feb 2019 13:19:09 -0800 (PST) Received: by mail-pg1-x536.google.com with SMTP id m1so10703086pgq.8 for ; Tue, 19 Feb 2019 13:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9biXuBX33DjY4N/Z1I0LtkZCgA+K5M3xNJvFB3mNBPU=; b=bPewHBxay2MJTktUy9K+7Ulydt2I6E8mCSJZ4vG4dvcdv2Dqo1w5a0zu97pjJ5gXdx DIeeK4sHG0FxAKR/ZWBZCq/IYoN/G1jn3SpcOywXf7IzuwuPURzT+DnhTy4g0Ld/BiIj PIfHhxPoVeqU3YGZq2PCB1T6YshuO/t4lup4kBNCIWNYzD6l+OLWTEfiKIwkMoRwwsgW zMzdPVCI9lARRtY9ARp4GojpYd37tmO+LHuSKyoWAMFQocYaJxkhegxtIe17iPWVzCJw tq5SpZO5Lh3HB28F3O5G5aV286fyf+RvDbfkIkdg+Cwr2G2vcpB2SGORFm5w9N382Xus BszQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9biXuBX33DjY4N/Z1I0LtkZCgA+K5M3xNJvFB3mNBPU=; b=N/memwznGNPVbDBrYyzCSYjyFJtm/yyDic8jE/m6xKoobsV6VP64BVY/wrysIxREIm cJoUXJ3T9ddeuRdXL2ijpq9IkkCvaRQqR5+a7Uuv2TETXArSCMNXR4ZG41ggOP+rg/eJ SC5sBpfMsZcwKfNFK3ga88xcluAoX+ELDbD4UVESN27NUpI/9alUSfi5fQ1+j6tPlae/ ko27ehe9dhn27JB4o4+rRSC0g8DwaLANrAQQmuc6tQpxP7alhBewGknh4pPeE2kcTv+V V/1k2OBvOZ2PeWcwoR4bLoTX/HHtILWBpeyNpYXKpMJR8M07odwLgWfygPxuy71Jkfr1 Obvg== X-Gm-Message-State: AHQUAubDfhqxcU0PP38p9JxnRNrbsNgMkh5cNxKxjStTw00PsN2PrIUW Z5eIzR0QgspLch/wMRIRPCmLq9PMw9U= X-Google-Smtp-Source: AHgI3IZU70tep3OJxBOq6SOBLwfo6q8DrhV5sRhHMYqaXXQA2HGxkfsm498/ca+CDmmXzSSYYE+zsQ== X-Received: by 2002:a63:6e02:: with SMTP id j2mr21361969pgc.229.1550611147342; Tue, 19 Feb 2019 13:19:07 -0800 (PST) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com. [209.85.215.171]) by smtp.gmail.com with ESMTPSA id o16sm18979951pgv.41.2019.02.19.13.19.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Feb 2019 13:19:06 -0800 (PST) Received: by mail-pg1-f171.google.com with SMTP id i130so10730605pgd.1 for ; Tue, 19 Feb 2019 13:19:06 -0800 (PST) X-Received: by 2002:a63:1a62:: with SMTP id a34mr2089748pgm.60.1550611146093; Tue, 19 Feb 2019 13:19:06 -0800 (PST) MIME-Version: 1.0 References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> In-Reply-To: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> From: Roman Shpount Date: Tue, 19 Feb 2019 16:18:55 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Ted Hardie , RTCWeb IETF , Christer Holmberg Content-Type: multipart/alternative; boundary="0000000000008c3a62058245ca7d" Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 21:19:11 -0000 --0000000000008c3a62058245ca7d Content-Type: text/plain; charset="UTF-8" Hi Justin, I did provide editorial feedback to the change on github: 1. This document refers to SDP protocol as profile. If you look at the referenced documents that define "profiles" in JSEP, they all refer to them as protocols. Also, in case of SRTP, profile is actually something different and refers to SRTP key parameters. 2. Default candidate does not have profile (or protocol), it has transport, port, and (connection-)address. So each "m=" and "c=" MUST be filled in with port, protocol, and address to match port, transport, and address of the default candidate for the m= section, as described in ice-sip-sdp. Regards, _____________ Roman Shpount On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Looks good. > > > > Regards, > > > > Christer > > > > *From: *rtcweb on behalf of Justin Uberti > > *Date: *Saturday, 16 February 2019 at 3.57 > *To: *Ted Hardie > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport > parameter issue > > > > I have updated this PR to incorporate minor feedback that was received > during the consensus call. Those who had feedback, please take another look > and comment on the PR if you are satisfied. > > > > On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie wrote: > > The chairs believe that there was rough consensus among those responding > to make the change in: > > > > https://github.com/rtcweb-wg/jsep/pull/863 > > > > Given the state of the document, it will be the Area Director's call as to > how much of the post-working group approval process must be re-done. > Authors, please wait on his direction before publishing a new version with > this merged. > > > > Regards, > > Ted and Sean > > _______________________________________________ > 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 > --0000000000008c3a62058245ca7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

I did provi= de editorial feedback to the change on github:

1. This document refers to SDP protocol as profile. If you look at the re= ferenced documents that define "profiles" in JSEP, they all refer= to them as protocols. Also, in case of SRTP, profile is actually something= different and refers to SRTP key parameters.

2. D= efault candidate does not have profile (or protocol), it has transport, por= t, and (connection-)address. So each "m=3D" and "c=3D" = MUST be filled in with port, protocol, and address to match port, transport= , and address of the default candidate for the m=3D section, as described i= n ice-sip-sdp.

Regards,
_____________
Roman Shpount


On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:

Looks good.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = rtcweb <rtcweb-bounces@ietf.org<= /a>> on behalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org><= br> Date: Saturday, 16 February 2019 at 3.57
To: Ted Hardie <ted.ietf@gmail.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

I have updated this PR to incorporate minor feedback= that was received during the consensus call. Those who had feedback, pleas= e take another look and comment on the PR if you are satisfied.

=C2=A0

On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

The chairs believe that there was rough consensus am= ong those responding to make the change in:

=C2=A0

=C2=A0

Given the state of the document, it will be the Area= Director's call as to how much of the post-working group approval proc= ess must be re-done.=C2=A0 Authors, please wait on his direction before pub= lishing a new version with this merged.

=C2=A0

Regards,

Ted and Sean

_______________________________________________
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
--0000000000008c3a62058245ca7d-- From nobody Wed Feb 20 09:56:28 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 453A0130DD3; Wed, 20 Feb 2019 09:56:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-rtcweb-fec@ietf.org, Ted Hardie , rtcweb-chairs@ietf.org, ted.ietf@gmail.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155068537927.31452.11334457138991637471.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2019 09:56:19 -0800 Archived-At: Subject: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 17:56:19 -0000 Ben Campbell has entered the following ballot position for draft-ietf-rtcweb-fec-08: 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-fec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this effort. I am balloting "yes", but have some minor comments: §8: - "Given this, WebRTC implementations SHOULD consider using RTX or flexfec retransmissions instead of FEC when RTT is low," "consider" seems vague for a normative requirement. Can you describe concrete requirements? Otherwise I suggest descriptive language. Can you give guidance on what RTT would be reasonable to consider as "low"? - "Note that when probing bandwidth, i.e., speculatively sending extra data to determine if additional link capacity exists, FEC SHOULD be used in all cases." I assume the point of this is the redundant FEC data should _be_ that extra data. But one could read this to mean that, if you are already sending extra data, you should also use FEC. §9, 2nd paragraph: I'm by no means an expert in this, and leave it to the crypto experts to know if this matters, but does the additional redundancy of FEC have any impact on SRTP encryption? From nobody Wed Feb 20 19:09:08 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ADB128D0B for ; Wed, 20 Feb 2019 19:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWGvlxttgp8L for ; Wed, 20 Feb 2019 19:09:03 -0800 (PST) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 AAAB81286D8 for ; Wed, 20 Feb 2019 19:09:03 -0800 (PST) Received: by mail-qt1-x841.google.com with SMTP id y4so29883827qtc.10 for ; Wed, 20 Feb 2019 19:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s/ev7QCaEGrjfw1tD1K5+uZrBGL05XgW1UwZWCBMhaU=; b=m9BWnUQo/hmNqsoEM7fgmvbOHzcp4PCP9MLYyy2EEpUg8d5KbGOGKzlwDoI5PKbGV7 qa9oKzQ17uPP6Ol/k+DMl0iHjWmYCItxm+vnqjCx7HFyPJgzfnc166Cowym8K9dlyNKV jdxAlHnU8u0r48Oy+pa4+8hgaq76Mx0MvR5To= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s/ev7QCaEGrjfw1tD1K5+uZrBGL05XgW1UwZWCBMhaU=; b=Nn5ugYlDeA+PncFlwPwEY4+2FZhBUfoHPyXHuVc/9ASPtEx2jK/dNOEaUSGwqgYkzG xc+WKLzHJ19toH5SVVV5lKg1eZzNI5aEmoxCj7XGWXZTzN49WwmW5izRlEhQhOBcyXp7 +cqacCAPrjdW0/HHwu3sLD/GxazhV5BsQLN9h45NLMKUUvukrXjUc6xAybq9tP1ahR27 jFIFbvdspW6Y91LhwUHyM1RY9kCga2sTJI+P/zVSjmKP1c/58LI9NUt35zugudrBqY8x JcdmV4iAqnJcUQUgPwR8Pc/rrFvkr2HLKVtMzCgWOssIaFGiOb5LaNXKNMFJ7O7kQDuk G6Dw== X-Gm-Message-State: AHQUAubhsgUcLzkYHD2G/S4B//c9k+fDZYNBkgQBaqvjqTVpg+5kKZyI Q6RIMxjrepR8J0Iq5FznMSivEA== X-Google-Smtp-Source: AHgI3Iam2fuQMMTX1TDCHmsgklwpp4sDzgQX168nA3kMY5g1d8Cz5U3GBKneLF9WIJG3Vg/LqE2K+w== X-Received: by 2002:ac8:2734:: with SMTP id g49mr29835875qtg.115.1550718542346; Wed, 20 Feb 2019 19:09:02 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id 20sm12564505qts.82.2019.02.20.19.09.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 19:09:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <154973824800.29421.10047365396889314189@ietfa.amsl.com> Date: Wed, 20 Feb 2019 22:09:00 -0500 Cc: gen-art@ietf.org, draft-ietf-rtcweb-security-arch.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154973824800.29421.10047365396889314189@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Genart last call review of draft-ietf-rtcweb-security-arch-18 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 03:09:07 -0000 I generated PR for these: https://github.com/rtcweb-wg/security-arch/pull/85 > On Feb 9, 2019, at 13:50, Russ Housley wrote: >=20 > Reviewer: Russ Housley > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-ietf-rtcweb-security-arch-18 > Reviewer: Russ Housley > Review Date: 2019-02-07 > IETF LC End Date: 2019-02-15 > IESG Telechat date: unknown >=20 > Summary: Almost Ready >=20 >=20 > Major Concerns: >=20 > Section 4.1 says "... preferably over TLS ...", but it does not tell > what the consequences are if TLS is not used. Since this is the > security architecture, I would expect these consequences to be > described. There is s9.1 that addresses this :) > Section 4.2: Please add a sentence or two that defines Interactive > Connectivity Establishment (ICE) data and non-ICE data. Since s4.2 of this document points to s4.2 of security-arch and = there=E2=80=99s an entire subsection on ICE I am hoping that the = references are enough. > Section 6.5 includes a contradiction. One place it says, " MUST NOT > negotiate cipher suites with NULL encryption", and another place it > says, "if Null ciphers are used ...". Please make these consistent. I deleted the display requirements section because I think the = prohibiting on negotiating NULL drives the display requirement. > Section 6.5 requires implementation of certificate fingerprints or a > Short Authentication String (SAS). Please add a sentence to tell how > they are used to provide out-of-band verification. Without such a > sentence, it is easy to imagine an implementation with a UI that is > too awkward to actually get the information on the screen while the > call is in progress. Would something like this work: These are compared by the peers to authenticate one another. > Section 10: since this is a standards track document, the IESG should > be responsible for this new codepoint, not the document author. changed > Minor Concerns: >=20 > Section 3.1 uses https://www.evil.org/ as an example. However, this = is > a registered domain. It would be better to follow the IESG statement = on > examples: https://www6.ietf.org/iesg/statement/examples.html. I was really hoping a Dr. Evil included their info the DNS. It wasn=E2=80= =99t there. I changed to http://example.org > Section 6.2 uses customerservice@ford.com as an example. Of course, > ford.com is a registered domain. It would be better to follow the IESG > statement on examples (the URL is above). Changed it to customerservice@example.org > Section 7 uses Poker Galaxy as an example. Of course, this is a real > web site. It would be better to follow the IESG statement on examples > (the URL is above). It seems best to use the same names here as are > used in Section 7.2. I changed to =E2=80=9Ca poker site=E2=80=9D to match that phrase, which = is used in the 1st para of that section. > Nits: >=20 > Section 1 includes: "... SDP-based like SIP." Please add a reference > for SDP. I have to admit that I=E2=80=99d probably be confused if there was a = reference to SDP after "SDP-based like SIP [RFC4566]=E2=80=9D and it = reads a little awkward if we do "SDP-based [RFC4566[ like SIP. RFC 4566 = is referred to in s3 when the SDP attribute is defined and there=E2=80=99s= a reference tor SIP, which also refers to SDP, earlier. I tend think = the reader won=E2=80=99t be that confused ;) > Section 4.1: s/ permissions till later/ permissions until later/ Fixed > Section 4.4: please add a reference for STUN. The reference is a sentence later. > Section 6.2: s/(though see Section 6.3/(See Section 6.3/ fixed > Section 6.4: please do not enclose the note is '[' and ']'. Avoid > confusion with reference syntax. One solution is to put the note at > the end of the paragraph. fixed (I just remove the [ ]). > Section 6.4: s/non-turn candidates/non-TURN candidates/ fixed > Section 6.5: the phrase "Implementations MUST implement" seems = awkward. > Perhaps "Implementations MUST support". This appears several places. fixed > Section 6.5 ought to begin with "All data channels MUST be secured via > DTLS." This appears half way through the section, but the material = that > comes before is really in support of this sentence. Eh - when I read that I thought - generic requirements and then ones for = media and the data channels. > Section 8.1 discusses "@", but the discussion of "user" > (note the quotes) and the discussion of domain (note the absense of > quotes) are using different conventions. Please use quotes in both > places or neither place. I think I fixed this. > There are places in this document where "settings" is confusing. It = is > unclear whether the word is referring to configuration settings or it > is referring to an environment or situation. Please look at each use > of this word and consider alternatives. I=E2=80=99ll leave this for ekr. From nobody Fri Feb 22 16:19:09 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811F130DE4 for ; Fri, 22 Feb 2019 16:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff_kYnAWI5lS for ; Fri, 22 Feb 2019 16:18:59 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 D42B0130E68 for ; Fri, 22 Feb 2019 16:18:55 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id y13so3193467iop.11 for ; Fri, 22 Feb 2019 16:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5lqqBiG8xKVfWLOiaYDflroy+ySgwzbZW1GiW215VQA=; b=mwMpzgOlxdxs5WD4G/wh/feLHv6e1g2smqgqjmU1YY5HFdYyfnyYE3FC0NbEm8Ov1l NNkqriZlGdaNFQKQxpJXxPybHdaTdULdzoLJuGKjVPkqfYyz4ujZwdDjJnAROpTtUWN1 f1xTZR+A2k+yl9KrMlBvuWad8Q9xSEh9wyo0LXszHvGi2Etopnfln6s6Y2VxtkAjYLd+ 9cLLhsSWWx72W+FQYA6IpafnEgGsUsQMXIyqCSGlBl1qgzATDix+dUnjwQC2GzHzMcSC Xgvwnsyh1FFNWoMz+07lJk8jA77p7jnTBtKF0/Ij4gbc0wVC50OShQ4R3POP1Cf8U5/w 1L4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5lqqBiG8xKVfWLOiaYDflroy+ySgwzbZW1GiW215VQA=; b=C9a2KR6eTw2D0+o7032FtJRkJBPGK+3aBxEza1Tiv4MLopYkD3FSq9lOHVAl0uRmQn +RQ+jaOQzCI+2L9lFBbpW0pfGLaGa3F0PaP8GGjoYtUfH7BNLww0SFi/4zK6FAdxLAmN LiU1buzI+NEP8WT7amWnbmxuxjRd9gkoGeycD3+Rcwr+TCG7sHmyiM7krjcQX404YcRT 4HaYU3PX0bT7MC8Kbp/1QwS/HlSP08SePNhprWQKiRlmLx7zmMOQtQF5myuHmQbF20OY I0dulRtWFp8eJMTpOa19B7o2RRS31Kbckns1TToPBebVwB65Gru5mlRriL6Hg7kA21m6 1Gcw== X-Gm-Message-State: AHQUAuZihJHRRa9ernzzSh9yyR82OTJgYNgE/+mfBZm0Rso3PFju6wJv ehYKa/FOtwVetW+U8eCctG4Z2sDvygHaDQQ7qOamjQ== X-Google-Smtp-Source: AHgI3Iaf79v/QJUhiWFCYjjZ00MbBRlYwYMzITo73rhbpY1xryKejAuE30mQox9RHsAttxCaYy8cvUDoXYMtPs7dfvg= X-Received: by 2002:a6b:f01a:: with SMTP id w26mr3762367ioc.101.1550881134086; Fri, 22 Feb 2019 16:18:54 -0800 (PST) MIME-Version: 1.0 References: <155041598050.4092.17319548267050845938.idtracker@ietfa.amsl.com> In-Reply-To: <155041598050.4092.17319548267050845938.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Fri, 22 Feb 2019 16:18:42 -0800 Message-ID: To: Eric Rescorla Cc: The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org Content-Type: multipart/alternative; boundary="000000000000168238058284a7db" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 00:19:01 -0000 --000000000000168238058284a7db Content-Type: text/plain; charset="UTF-8" Thanks for your comments, see below: On Sun, Feb 17, 2019 at 7:06 AM Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3278 > > > > COMMENTS > S 5.2. > > as described in [RFC5956], Section 4.1 is not currently defined for > > WebRTC, and SHOULD NOT be offered. > > > > Answerers SHOULD reject any FEC-only m-lines, unless they > > specifically know how to handle such a thing in a WebRTC context > > (perhaps defined by a future version of the WebRTC specifications). > > It seems like the above three paragraphs are generic to this document, > and just grouped with video because the audio codecs tend to have > internal FEC? If so, maybe put them elasewhere? > As noted elsewhere in the document, the recommendation is to only use flexfec with video. These paras could be put elsewhere, e.g., in a "negotiating flexfec" section, and then 5.2 could point to said section, but it's not clear this would enhance readability. > > > S 9. > > > > As described in [RFC3711], Section 10, the default processing when > > using FEC with SRTP is to perform FEC followed by SRTP at the > sender, > > and SRTP followed by FEC at the receiver. This ordering is used for > > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as > > described in [RFC5764], Section 4.1.2. > > I of course agree with this text, but I wonder if it's maximally > clear. Perhaps rewrite the > first sentence as: > > ```The FEC schemes described in this document use other packets to > recover when a packet is lost or damaged but do not allow for recovery > of a damaged packet on its own. This is consistent with the default > processing for using FEC with SRTP described in RFC 3711, which is to > perform FEC followed by SRTP at the sender, and SRTP followed by FEC > at the receiver, which implies that damaged packets will be rejected > by the SRTP integrity check and discarded.``` > I rewrote this in the most recent commit, https://github.com/juberti/draughts/commit/6e991d1eeaf1e505bb89957319be38df4ada56f5. LMK if you think that still needs to be clarified. --000000000000168238058284a7db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments, see below:=

= On Sun, Feb 17, 2019 at 7:06 AM Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the following ballot position = for
draft-ietf-rtcweb-fec-08: 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/s= tatement/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-r= tcweb-fec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3278


COMMENTS
S 5.2.
>=C2=A0 =C2=A0 =C2=A0 as described in [RFC5956], Section 4.1 is not curr= ently defined for
>=C2=A0 =C2=A0 =C2=A0 WebRTC, and SHOULD NOT be offered.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Answerers SHOULD reject any FEC-only m-lines, unle= ss they
>=C2=A0 =C2=A0 =C2=A0 specifically know how to handle such a thing in a = WebRTC context
>=C2=A0 =C2=A0 =C2=A0 (perhaps defined by a future version of the WebRTC= specifications).

It seems like the above three paragraphs are generic to this document,
and just grouped with video because the audio codecs tend to have
internal FEC? If so, maybe put them elasewhere?

As noted elsewhere in the document, the recommendation is to only = use flexfec with video. These paras could be put elsewhere, e.g., in a &quo= t;negotiating flexfec" section, and then 5.2 could point to said secti= on, but it's not clear this would enhance readability.=C2=A0


S 9.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 As described in [RFC3711], Section 10, the default= processing when
>=C2=A0 =C2=A0 =C2=A0 using FEC with SRTP is to perform FEC followed by = SRTP at the sender,
>=C2=A0 =C2=A0 =C2=A0 and SRTP followed by FEC at the receiver.=C2=A0 Th= is ordering is used for
>=C2=A0 =C2=A0 =C2=A0 all the SRTP Protection Profiles used in DTLS-SRTP= [RFC5763], as
>=C2=A0 =C2=A0 =C2=A0 described in [RFC5764], Section 4.1.2.

I of course agree with this text, but I wonder if it's maximally
clear. Perhaps rewrite the
first sentence as:

```The FEC schemes described in this document use other packets to
recover when a packet is lost or damaged but do not allow for recovery
of a damaged packet on its own. This is consistent with the default
processing for using FEC with SRTP described in RFC 3711, which is to
perform FEC followed by SRTP at the sender, and SRTP followed by FEC
at the receiver, which implies that damaged packets will be rejected
by the SRTP integrity check and discarded.```

I rewrote this in the most recent commit,=C2=A0= https://github.com/juberti/draughts/commit/6e991d1eeaf1e505bb89957319be38df= 4ada56f5. LMK if you think that still needs to be clarified.
--000000000000168238058284a7db-- From nobody Fri Feb 22 16:31:25 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB70412D4F0 for ; Fri, 22 Feb 2019 16:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di-2bwy7MMaM for ; Fri, 22 Feb 2019 16:31:20 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 262D9126C7E for ; Fri, 22 Feb 2019 16:31:20 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id x3so3233628ior.6 for ; Fri, 22 Feb 2019 16:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LUwSf1s+GR1WLHcZB6HNSTWR6dQFHvgWhYbjFP8R7Kc=; b=uKNK6xQMD9vyDeocjG1ryx1GguMiUyymPxWKWGK6Frf9WoQJ5YDUxPFTv0qOGKUcTU dVbP9BKApHmyZidrHL1O2tA00nF4rtwmBQZcpzRW/OcP8Bg41tYvEmeFSljii/oGmMjk bZfYhH7sPFJ1SpVWi8deha1JvsDq6RFfzZ02P+ZGQVcbzQG6OZ1zjEt/yDMiAoi/T7cO uFkIeGVxymyq6NJ5jtE2MmaMO46UvlLU/W5RWuhZmUKOTKSFjaTO45lLtNEACl4uE2Oi aZQNDGCLXrcbbRpgzA7d4gWKSGxNNFulVQMMzLDv8m/sy61nep+MR/CgSc6EZv0q/raE mYNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LUwSf1s+GR1WLHcZB6HNSTWR6dQFHvgWhYbjFP8R7Kc=; b=B9N5K5QxER+sGa8YevluLa2ZUY+gRCeV3MpcgJjL793Eh8wFrBavQdJjBn/pkbtXCc pxXozEhP7zGTs5JTtbhpMefDF7X4jBxfuN7vB15wn+m/wDi/aiBzh+EGjU2R7iOq4y0t hxWS8csZKnZBZUM4qz7/HWvg5bdHfZFMe0YJJch9Xc7RChck6AOS5uuE9M6YCKJXDFEO wcnKdqosZyw1e8qzjPFhS/dAMi/132ae1pyUeNlrGpQJJZflzax68r8MaPNHhyiOYAwo cn2fAEXxfcQ69JwbpLevPeKr9WfdrMiIVJocH67UTwwc6xH1pxtFHFu89ZdpH21RLp7q u6cg== X-Gm-Message-State: AHQUAuYvGicSFtFoY2ObkdnCzilS14sj98YfcN/bxegBk62q6PlXBBKF 72H4umLOn2OKHjHlm7nxEyu/S9V/TAvWqoB7NTJwGQ== X-Google-Smtp-Source: AHgI3IZA6Z4vIH+juS+E5l34HUVtbMMlefnG1/c/plU0dihotYVflPA/iMVuwbCQ8A7tasIIx+AQAoICPDcFaMIV5YA= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr3509472ioh.95.1550881878501; Fri, 22 Feb 2019 16:31:18 -0800 (PST) MIME-Version: 1.0 References: <155068537927.31452.11334457138991637471.idtracker@ietfa.amsl.com> In-Reply-To: <155068537927.31452.11334457138991637471.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Fri, 22 Feb 2019 16:31:07 -0800 Message-ID: To: Ben Campbell Cc: The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org Content-Type: multipart/alternative; boundary="000000000000754a2c058284d39c" Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 00:31:24 -0000 --000000000000754a2c058284d39c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your comments. See below: On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this effort. I am balloting "yes", but have some minor comment= s: > > =C2=A78: > - "Given this, WebRTC implementations SHOULD consider using RTX or > flexfec retransmissions instead of FEC when RTT is low," > > "consider" seems vague for a normative requirement. Can you describe > concrete > requirements? Otherwise I suggest descriptive language. > Perhaps "prefer" rather than "consider" would be less squishy. > > Can you give guidance on what RTT would be reasonable to consider as "low= "? > This is somewhat application-dependent, but ~100 ms would be a reasonable threshold. > > - "Note that when probing bandwidth, i.e., speculatively sending extra > data to determine if additional link capacity exists, FEC SHOULD be > used in all cases." > > I assume the point of this is the redundant FEC data should _be_ that ext= ra > data. But one could read this to mean that, if you are already sending > extra > data, you should also use FEC. > I see what you mean, agree this could be clarified. > > =C2=A79, 2nd paragraph: > > I'm by no means an expert in this, and leave it to the crypto experts to > know > if this matters, but does the additional redundancy of FEC have any impac= t > on > SRTP encryption? > My understanding is that the fact that FEC is sent as its own stream with its own IV means that even if the data was identical to the primary payload, there would be no issue. But given that no new mechanisms are being proposed in this document, it's probably covered elsewhere. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000754a2c058284d39c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments. See below:
On We= d, Feb 20, 2019 at 9:56 AM Ben Campbell <ben@nostrum.com> wrote:
Ben Campbell has entered the following= ballot position for
draft-ietf-rtcweb-fec-08: 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/s= tatement/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-r= tcweb-fec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this effort. I am balloting "yes", but have some minor= comments:

=C2=A78:
- "Given this, WebRTC implementations SHOULD consider using RTX or
flexfec retransmissions instead of FEC when RTT is low,"

"consider" seems vague for a normative requirement. Can you descr= ibe concrete
requirements? Otherwise I suggest descriptive language.

Perhaps "prefer" rather than "consider"= ; would be less squishy.=C2=A0

Can you give guidance on what RTT would be reasonable to consider as "= low"?

This is somewhat application= -dependent, but ~100 ms would be a reasonable threshold.

- "Note that when probing bandwidth, i.e., speculatively sending extra=
data to determine if additional link capacity exists, FEC SHOULD be
used in all cases."

I assume the point of this is the redundant FEC data should _be_ that extra=
data. But one could read this to mean that, if you are already sending extr= a
data, you should also use FEC.

I see wh= at you mean, agree this could be clarified.=C2=A0

=C2=A79, 2nd paragraph:

I'm by no means an expert in this, and leave it to the crypto experts t= o know
if this matters, but does the additional redundancy of FEC have any impact = on
SRTP encryption?

My understanding is th= at the fact that FEC is sent as its own stream with its own IV means that e= ven if the data was identical to the primary payload, there would be no iss= ue. But given that no new mechanisms are being proposed in this document, i= t's probably covered elsewhere.=C2=A0


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000754a2c058284d39c-- From nobody Fri Feb 22 16:46:13 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4E4130EDB for ; Fri, 22 Feb 2019 16:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrkBhEKFR-B9 for ; Fri, 22 Feb 2019 16:46:08 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 67B29130ECA for ; Fri, 22 Feb 2019 16:46:08 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id p18so3258232ioh.5 for ; Fri, 22 Feb 2019 16:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wEiyvU8A7jWYsoiAugsl4RFw5rjeaXKwpFqqVheENRs=; b=KmzK6P0VPp3L+gJsn/zQxUntcaB0guRC6+yzw0g7X6WcnQDtqDx+fMHn3RNa+7r5jC b0BkANAJJ2VeexgmzPODCDkNt36awMkZyQe1GQOOn6Tkvg+2PFGl7OSXm2Ex5WQ6oFo0 7Rc7z5NK84mmPiA9HwbqW3xE63EpojXILmF9v6kD1M2YPbXPMP/1PdybdhoMg3mKcC4/ 8hgK50+S47oLMhBwpjMFqnbY/i1YuC6GK2bYoYQ57rz966CH+RZoli2Ob1Lip1wGmYZy wQO6zEq8xCAQ5zCDdJYJURKHR7/EihO7SEsNKd6VVwnMFoCdzK1EXCYMQhu1HaSZ0ZaX nkeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wEiyvU8A7jWYsoiAugsl4RFw5rjeaXKwpFqqVheENRs=; b=TId5MD7SFfW1AnCLl64W93zLhNuq8wBCq6j1vCweUOiaqpiJdrcC0wcef6mcKrUyFN 4bneIsKIYoxMt+FwGT3MqTrpHZ8M4u1aG3X1hKA0E82GXmEbC1gs/wegelRUdOgQr4F7 st/4LA+7krTncDU3q8pSLp8T/79TMpLJzNo8/BN1N8jNdLe6VVZt0o1c+FDhKFvQIiJk d5D3djTFrfmTnAYEC6Ggrx6qQ3fj6OlU1jhD25BK/RPUx8IyW3T855e9BOO8U9R8lpVr oAbICzg/tiI+ajowBRG3iJFDF2PBUFqBZ1axDAvkJGPqkVwfzs0lSBoD4XGT9KubYwDW 8W/g== X-Gm-Message-State: AHQUAuZCx0D85WAW0SdZqy1MN1sz+06zcayNPrV42imqwK6m17fZ9XPV L60IoNht4ZHf7u/5YdGt8hlScumkvOarHXJA+x+XCA== X-Google-Smtp-Source: AHgI3IbEKEPEJiYqdJthuWQk7hPm2yQoPiIq1wtJYhqlqQb1z5x8Z87X6nvj3Nqh9QJQfSijc7Or9Ejeo0lTsLExYPU= X-Received: by 2002:a6b:ef02:: with SMTP id k2mr3529507ioh.95.1550882766752; Fri, 22 Feb 2019 16:46:06 -0800 (PST) MIME-Version: 1.0 References: <155004461594.8627.1832684939296277208@ietfa.amsl.com> In-Reply-To: <155004461594.8627.1832684939296277208@ietfa.amsl.com> From: Justin Uberti Date: Fri, 22 Feb 2019 16:45:55 -0800 Message-ID: To: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Cc: ops-dir@ietf.org, draft-ietf-rtcweb-fec.all@ietf.org, RTCWeb IETF , IETF discussion list Content-Type: multipart/alternative; boundary="00000000000066ec010582850898" Archived-At: Subject: Re: [rtcweb] Opsdir telechat review of draft-ietf-rtcweb-fec-08 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 00:46:12 -0000 --00000000000066ec010582850898 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 12, 2019 at 11:57 PM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder < j.schoenwaelder@jacobs-university.de> wrote: > Reviewer: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder > Review result: Has Nits > > I have reviewed this document and I did not find any issues that are > affect the operations of networks (except that FEC requires more > bandwidth and that it may not help much or even make things worse if > bandwidth is the cause of packet loss, which is explained in the > document). > > While reading the document, I wrote down the following notes that the > editor may take into account when revising the document: > > - in 3.1, expland SSRC on first usage and say that this is about > sending streams over RTP somewhere early on (I assume this is > implied by using the term WebRTC but for outsiders like me it may > help to be more specific). > Acknowledged. > > - To what extend is this document WebRTC specific? Do the requirements > also apply if I use RTP without a WebRTC context? If so, should the > title rather say "RTP Forward Error Correction Requirements"? Well, > section 6 may be WebRTC specific but that section just says that > nothing is being recommended, so the recommendations are really all > about FEC usage over RTP as far as I can tell (as an outsider). > This document indicates what mechanisms WebRTC implementations should support, so while the recommendations could also be applied to non-WebRTC endpoints, that is not the focus of the document. > - stylistic: I am not a big fan of using citations like '[RFC2198]' as > ordinary words or nouns, it makes text difficult to follow unless > you know the RFC numbers by heart and your brain translates them > back to something meaningful on the fly. This makes texts more > difficult to read for outsiders. Example: > > This mechanism is similar to the > [RFC2198] mechanism described above. > > I prefer this: > > This mechanism is similar to the > redundant encoding mechanism described above. > > There are couple of such usages of [RFCXXXX] in the document > OK. - add reference for PCMU > OK. Reminder to self, RFC 5391. --00000000000066ec010582850898 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 12, 2019 at 11:57 PM J=C3= =BCrgen Sch=C3=B6nw=C3=A4lder <j.schoenwaelder@jacobs-university.de> wrote:
Reviewer: J=C3=BCrgen Sc= h=C3=B6nw=C3=A4lder
Review result: Has Nits

I have reviewed this document and I did not find any issues that are
affect the operations of networks (except that FEC requires more
bandwidth and that it may not help much or even make things worse if
bandwidth is the cause of packet loss, which is explained in the
document).

While reading the document, I wrote down the following notes that the
editor may take into account when revising the document:

- in 3.1, expland SSRC on first usage and say that this is about
=C2=A0 sending streams over RTP somewhere early on (I assume this is
=C2=A0 implied by using the term WebRTC but for outsiders like me it may =C2=A0 help to be more specific).

Ackno= wledged.=C2=A0

- To what extend is this document WebRTC specific? Do the requirements
=C2=A0 also apply if I use RTP without a WebRTC context? If so, should the<= br> =C2=A0 title rather say "RTP Forward Error Correction Requirements&quo= t;? Well,
=C2=A0 section 6 may be WebRTC specific but that section just says that
=C2=A0 nothing is being recommended, so the recommendations are really all<= br> =C2=A0 about FEC usage over RTP as far as I can tell (as an outsider).
<= /blockquote>

This document indicates what mechanisms Web= RTC implementations should support, so while the recommendations could also= be applied to non-WebRTC endpoints, that is not the focus of the document.=


- stylistic: I am not a big fan of using citations like '[RFC2198]'= as
=C2=A0 ordinary words or nouns, it makes text difficult to follow unless =C2=A0 you know the RFC numbers by heart and your brain translates them
=C2=A0 back to something meaningful on the fly. This makes texts more
=C2=A0 difficult to read for outsiders. Example:

=C2=A0 =C2=A0 =C2=A0This mechanism is similar to the
=C2=A0 =C2=A0 =C2=A0[RFC2198] mechanism described above.

=C2=A0 I prefer this:

=C2=A0 =C2=A0 =C2=A0This mechanism is similar to the
=C2=A0 =C2=A0 =C2=A0redundant encoding mechanism described above.

=C2=A0 There are couple of such usages of [RFCXXXX] in the document

OK.

- add reference for PCMU

OK. Reminder t= o self, RFC 5391.
--00000000000066ec010582850898-- From nobody Fri Feb 22 16:53:48 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77A312D4ED for ; Fri, 22 Feb 2019 16:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB89Xz_Pja7T for ; Fri, 22 Feb 2019 16:53:35 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 34F8A1200D8 for ; Fri, 22 Feb 2019 16:53:35 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id r11so5649618itc.2 for ; Fri, 22 Feb 2019 16:53:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wqfH/gIM5k+vdGGAFhzPsMvk1Qtl6y7yYRA9GJv99GM=; b=eQruJqT3W9jiqeD3/gaX/H3HFCKX6rya41WY7e/Wur6tB2PQyGtYRpph81XEPmYGYL 3C82ihSzgog7flAN77yDbVFS4juBpUhR2usWC39rND4dxHu4UXYpJIYprYhjO9Ucedk1 tV6wFVUSiN/cIhNocm8i8+47Vu6cwJBROlTLWh5qK535ktGzKWyoUbGG+6JdsOglT/PL MCZK4NqndCf3tZZOVRyYBJUmI5msq9ld01bFQu4ABogMwprzzhUeyhvmgU9LKKBvxXNy kwlW/1JKEjV2x+V1MD93dhZY1xH16qdy4R3fVhWK4XkV4skApFnnv9LA4ujg7/F5XW0Y LCeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wqfH/gIM5k+vdGGAFhzPsMvk1Qtl6y7yYRA9GJv99GM=; b=OehoGMqogg/I3MS0BNYg1NoztAj1Ko4gvT/E+5RXRR/CXqfg9qoEk/l/qGn7m7nZdd a3PND/3IXPyXI+aYDjluv5M4rHGcX58O8xQ+VWlwCtKw+RI0iBgJTXJ5bHOstbWH/bJd 9XXkgN7qN4SzBOjPR6CbCyCNawmds90JkCTIX1pctmurOWZoo2W4JgSO0uKlAaRTFyud Pi96oEvfl8/Ea+iyoH0D4RighdQp32BnDwKQTQ/15eTW5KFo1yazd/qyqcnOIjHuZde2 C7x2OzgLR3XO4KM2xZgh2DDmHTkN8HJ0K6AAIh/I3DBxT6k5EODncBTRucePHEK5Sde7 sJhQ== X-Gm-Message-State: AHQUAuY0HvbQKww2rDuhI9hciEt5jvngFaBhwnICmpIH5FDb+tlRahiz aTE6xmDcSE5QkT6yjVtu2czZoev9i7dGqAv2+gE3pw== X-Google-Smtp-Source: AHgI3IY5RF8ZvUe+tCwct+fAndOJbf8tjKKvYtYeEDd4dP3/v+/PpcIOTm6Ro1j50Vh1wcAU6PKQPm3tZZz/ydV3240= X-Received: by 2002:a02:1d6:: with SMTP id 83mr3994650jak.29.1550883213551; Fri, 22 Feb 2019 16:53:33 -0800 (PST) MIME-Version: 1.0 References: <155058071936.20784.14656321188511454784.idtracker@ietfa.amsl.com> In-Reply-To: <155058071936.20784.14656321188511454784.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Fri, 22 Feb 2019 16:53:21 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org Content-Type: multipart/alternative; boundary="00000000000008a2ba05828523c4" Archived-At: Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-rtcweb-fec-08=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 00:53:39 -0000 --00000000000008a2ba05828523c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your comments. See below. On Tue, Feb 19, 2019 at 4:52 AM Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm not fully sure about the intended status of this document. The shephe= rd > write-up says "the document has normative requirements for conforming > WebRTC > implementations", however, for me it seems this document makes "only" > recommendations and has actually no normative requirements. Therefore > informational status might be more appropriate, however, I will not block > publication as PS. > > One mostly minor editorial note: > > Sec 3.3: "experiments performed indicate that when Opus FEC is used, the > overhead imposed > is about 20-30%, depending on the amount of protection needed." > Would it be possible to provide a reference for this number? > I believe this came from a WG mailing list post (possibly my own), rather than an external document that could be linked to. Suggestions? > > Also this section says: "See [RFC6716], Section 2.1.7 for complete > details." > However, section 2.1.7 in RFC6716 is very short and actually does not > provide > any details... > Unfortunately, that was the best RFC reference I could find. --00000000000008a2ba05828523c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments. See below.
On Tu= e, Feb 19, 2019 at 4:52 AM Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
Mirja K=C3=BChlewind has entered the fol= lowing ballot position for
draft-ietf-rtcweb-fec-08: 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/s= tatement/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-r= tcweb-fec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm not fully sure about the intended status of this document. The shep= herd
write-up says "the document has normative requirements for conforming = WebRTC
implementations", however, for me it seems this document makes "o= nly"
recommendations and has actually no normative requirements. Therefore
informational status might be more appropriate, however, I will not block publication as PS.

One mostly minor editorial note:

Sec 3.3: "experiments performed indicate that when Opus FEC is used, t= he
overhead imposed
=C2=A0 =C2=A0is about 20-30%, depending on the amount of protection needed.= "
Would it be possible to provide a reference for this number?

I believe this came from a WG mailing list post (poss= ibly my own), rather than an external document that could be linked to. Sug= gestions?

Also this section says: "See [RFC6716], Section 2.1.7 for complete det= ails."
However, section 2.1.7 in RFC6716 is very short and actually does not provi= de
any details...

Unfortunately, that was = the best RFC reference I could find.

--00000000000008a2ba05828523c4-- From nobody Fri Feb 22 16:57:27 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149BE130ED1; Fri, 22 Feb 2019 16:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfRgEKgVAUDy; Fri, 22 Feb 2019 16:57:16 -0800 (PST) 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 3B99112D4ED; Fri, 22 Feb 2019 16:57:16 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1N0v7Ol025418 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Feb 2019 18:57:09 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550883430; bh=Z2aRgokIl0/7f0N7HOZNw69+Pw7EOBVJ8cOkM4KOyj8=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=X5UA1IAwlxqQjpT76w/G/FLx7yXt+C8/Qby7lkZGtAP/tzx1ZO6x7fqp9kXVAza3O 3H1TOvmbDyqMNnGWOUVc63kRx4QP1Dcsi3Epe4gQbLtr/NZvm7fJJzFHGcHbJPUsWk vJ1qSMrAzNSgH4WPRN6PlM4jJmx7fPUkNGRWZshE= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: <4C5C447B-3CAA-436C-A60D-432B4374C39A@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_606450F9-7D0E-430A-BF0F-CA08D0DA20E9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 22 Feb 2019 18:57:05 -0600 In-Reply-To: Cc: The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org To: Justin Uberti References: <155068537927.31452.11334457138991637471.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 00:57:18 -0000 --Apple-Mail=_606450F9-7D0E-430A-BF0F-CA08D0DA20E9 Content-Type: multipart/alternative; boundary="Apple-Mail=_AD71D437-BD2E-48C5-87F2-CF6ADBA38009" --Apple-Mail=_AD71D437-BD2E-48C5-87F2-CF6ADBA38009 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the response. Comments below: > On Feb 22, 2019, at 6:31 PM, Justin Uberti wrote: >=20 > Thanks for your comments. See below: >=20 > On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell > wrote: [=E2=80=A6] > ---------------------------------------------------------------------- >=20 > Thanks for this effort. I am balloting "yes", but have some minor = comments: >=20 > =C2=A78: > - "Given this, WebRTC implementations SHOULD consider using RTX or > flexfec retransmissions instead of FEC when RTT is low," >=20 > "consider" seems vague for a normative requirement. Can you describe = concrete > requirements? Otherwise I suggest descriptive language. >=20 > Perhaps "prefer" rather than "consider" would be less squishy. Prefer is better, thanks. >=20 > Can you give guidance on what RTT would be reasonable to consider as = "low"? >=20 > This is somewhat application-dependent, but ~100 ms would be a = reasonable threshold. Would it make sense to say that the threshold for =E2=80=9Clow=E2=80=9D = is application dependent, but that would be a reasonable number for = =E2=80=9Ctypical=E2=80=9D applications? >=20 > - "Note that when probing bandwidth, i.e., speculatively sending extra > data to determine if additional link capacity exists, FEC SHOULD be > used in all cases." >=20 > I assume the point of this is the redundant FEC data should _be_ that = extra > data. But one could read this to mean that, if you are already sending = extra > data, you should also use FEC. >=20 > I see what you mean, agree this could be clarified. Thanks >=20 > =C2=A79, 2nd paragraph: >=20 > I'm by no means an expert in this, and leave it to the crypto experts = to know > if this matters, but does the additional redundancy of FEC have any = impact on > SRTP encryption? >=20 > My understanding is that the fact that FEC is sent as its own stream = with its own IV means that even if the data was identical to the primary = payload, there would be no issue. Is that true for the case of in-band FEC at the codec level? > But given that no new mechanisms are being proposed in this document, = it's probably covered elsewhere. I can accept that argument. Thanks! Ben. --Apple-Mail=_AD71D437-BD2E-48C5-87F2-CF6ADBA38009 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the response. Comments below:
On Feb = 22, 2019, at 6:31 PM, Justin Uberti <juberti@google.com> = wrote:

Thanks for your comments. = See below:

On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell = <ben@nostrum.com> wrote:

[=E2=80=A6]

--------------------------------------------------------------------= --

Thanks for this effort. I am balloting = "yes", but have some minor comments:

=C2=A78:=
- "Given this, WebRTC implementations SHOULD consider = using RTX or
flexfec retransmissions instead of FEC when = RTT is low,"

"consider" seems vague for a = normative requirement. Can you describe concrete
requirements? Otherwise I suggest descriptive language.

Perhaps "prefer" rather than "consider" would be less = squishy. 

Prefer is better, thanks.


Can you give = guidance on what RTT would be reasonable to consider as "low"?

This is somewhat application-dependent, but ~100 ms would be = a reasonable threshold.

Would it make sense to say that the threshold for = =E2=80=9Clow=E2=80=9D is application dependent, but that would be a = reasonable number for =E2=80=9Ctypical=E2=80=9D = applications?



- "Note that when probing bandwidth, i.e., speculatively = sending extra
data to determine if additional link = capacity exists, FEC SHOULD be
used in all cases."

I assume the point of this is the redundant = FEC data should _be_ that extra
data. But one could read = this to mean that, if you are already sending extra
data, = you should also use FEC.

I see what you mean, agree this could = be clarified. 

Thanks


=C2=A79, 2nd = paragraph:

I'm by no means an expert in = this, and leave it to the crypto experts to know
if this = matters, but does the additional redundancy of FEC have any impact on
SRTP encryption?
My understanding is that the fact that = FEC is sent as its own stream with its own IV means that even if the = data was identical to the primary payload, there would be no issue. =

Is = that true for the case of in-band FEC at the codec level?

But given = that no new mechanisms are being proposed in this document, it's = probably covered = elsewhere. 

I can accept that argument.

Thanks!

Ben.
= --Apple-Mail=_AD71D437-BD2E-48C5-87F2-CF6ADBA38009-- --Apple-Mail=_606450F9-7D0E-430A-BF0F-CA08D0DA20E9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxwmmEACgkQgFZKbJXz 1A0FKBAAggLTXOnRocj8+De31Te4ulocKIZJySGGECVXd0sV78wZu21y7FXYLurt 5tTzeb1+faVqS020Q61P1X14oXZJi03zzwsf1OTOop8tXif91mqZ2zfAQPJkztuo UtDDLlFIStevKt6AiOEA0uUsUO4RbySlMJrQ+gUWSKorQr6d5Yp90qghzR3lYgaA zsgaKnZHR9+TaoGFEi1Lx/FQ/FyoSipdLmPHLepktvIAf08wI6Pk35xGGMWjz4R+ 5QaE3eUB98d1P+VgYqtpc/oyLMzIwojacK4gwRQO1b6fW5srxka+cMR7kmdSQW45 Q9eWecn3gHIqARcnNah5nDfs2OybrvkSJXXjJ1Ku8e8sLqaMPr0mXtnkuBlJJnmy CMwbEC4dpKUPU2I9MTCBQ7jvZgMq2wXHF2mN2YxWVUWvVop4CeXRfsgjtvGLEJwB I/9o70LcIxzw0aNSyWnzIoUQC57wv9duERuSgvvD1+k0YSEX74o7P+uhKwRFScqw Tbw76g69aYphiJ2Ak39UcfpCyqpifsPVa8eipAOpimYB7j/VQ2x4eeC24v3KVv9z +gfSSfC66TGa5sywwQRLsVWHQRuj80jDzt1EAXfGRef2FO+viiD82gPIQbN4tXvR VV9qEPEEt/5F8Mf3XeOOGOqYvq0LOCICSLz1MEoGS6FagF+pxwo= =7mO4 -----END PGP SIGNATURE----- --Apple-Mail=_606450F9-7D0E-430A-BF0F-CA08D0DA20E9-- From nobody Fri Feb 22 17:10:56 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5073C130ED1 for ; Fri, 22 Feb 2019 17:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiTilnZaH_QQ for ; Fri, 22 Feb 2019 17:10:50 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 44238130F25 for ; Fri, 22 Feb 2019 17:10:50 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id r11so5690053itc.2 for ; Fri, 22 Feb 2019 17:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BuEqxC9SR1fSgPYTI40Hh8mgLJapdiUUMDeIkSxPDMo=; b=W40rRhQxq+Wj5PVa46MDiFyBGXiyNIerWfLYsjTBJsiN6gn/yVZNsWTPVIzpLmqXii wp8kG19cEbo9zxRkSeDkzhORXK1U9Y1DkCfjKZ0dWrFq5EMuB9Zz5pbsF5W0E8CcPf3x MFyi8DnRPjykjov//tfeLe7WixByQ0XJeoC9wYqYFCtGFPVvdwPcNvYBiw8ga4loE2Pr DrubymbFoFx82rKdD6YvwIaYOOLrMVruO20m/Y/VNLUxrJyhlfp/pwxTfQ72ie11re+w Ynh+9uV6j5EdjpOHwoPhr/atWA1kufwLVp+3x4CDMdT083KOqwFnVAOrT1pOcJDUSqVM AYxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BuEqxC9SR1fSgPYTI40Hh8mgLJapdiUUMDeIkSxPDMo=; b=B7QyL/wc9DU6uXtaa8+2rl/SbQJFVjeJfaOCIh7I8SlVA3mL3aXvlj+ufHVfXbg5RY kH8jegxQiIe6VXJSJ6Z0InH6TUnNpitB0PAAeqkb/OnA6QJGxnRna5BUrB1tTpNz9txx XKVrbIk8IcvVrAp7nSPWn7f+dS7XbLUjuH1mVkad40Vh7CeGeStKDC+StDyEfxYwJWGq 3O4CUTOm6oDdiKMf56ak2eDCWxdG/Fm3139HsnXkQx/2lmzl6K4r5c1uJi0nX9ydoV/e 9QxetujPYMHeZxOYDiR33LTFbZB9xRNZqeQU06qalAvQ52vhUVYlYxT79drz46T66bdk kfLQ== X-Gm-Message-State: AHQUAuY0mb4HPox42hMdY7ncoIP0i3jgJ+TdnmQMEgbBlOdl4Cw6Ixff c4bYbQq7ZRW5OcEF7spweekzSMDRKaU/nS4C6FryGw== X-Google-Smtp-Source: AHgI3IZZTKcZu2aDzBeecIOGg1FiHRqNXFanKV+fVScyw8T+pVzd7A1B7LbEanzNQCbix4n+bTmN7iEETG9o6V6Rcdc= X-Received: by 2002:a24:ccc5:: with SMTP id x188mr3928155itf.123.1550884248531; Fri, 22 Feb 2019 17:10:48 -0800 (PST) MIME-Version: 1.0 References: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> In-Reply-To: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Fri, 22 Feb 2019 17:10:35 -0800 Message-ID: To: Benjamin Kaduk Cc: The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org Content-Type: multipart/alternative; boundary="000000000000b9525a05828560c8" Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 01:10:54 -0000 --000000000000b9525a05828560c8 Content-Type: text/plain; charset="UTF-8" Thanks for your comments. See below. On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3 > > nit: The subsequent discussion seems to indicate that at least some of > these mechanisms are already specified and not new in this document; (if > so) it would be nice to have the exposition reflect that. > > Section 3.3 > > For Opus, packets deemed as important are re-encoded at a lower > bitrate and added to the subsequent packet, allowing partial recovery > > Is "added" supposed to be something other than "appended" (which strongly > resembles the "redundant encoding" of the previous section)? > It's similar to the redundant encoding, but done within the Opus bitstream, rather than at the RTP level. > > Section 4.1 > > Does it make sense to give subsection backreferences when talking about > (e.g.) redundant encoding? > Yes, this could be done easily. > > Section 5.2 > > Support for a SSRC-multiplexed flexfec stream to protect a given RTP > stream SHOULD be indicated by including one of the formats described > in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an > > nit: Since this Section 5 is solely for video, is it more appropriate to > refer to Section 5.1.2 ("Registration of video/flexfec") of > draft-ietf-payload-flexible-fec-scheme? > Agreed - earlier versions of flexfec were slightly different. > > Section 7 > > To support the functionality recommended above, implementations MUST > be able to receive and make use of the relevant FEC formats for their > supported audio codecs, and MUST indicate this support, as described > in Section 4. Use of these formats when sending, as mentioned above, > is RECOMMENDED. > > Just to double-check: this is explicitly only mandating FEC for audio and > ignoring video entirely? > This para only applies to audio. The following para discusses video, but is SHOULD-strength given the relative newness of flexfec. > > Section 8 > > Because use of FEC always causes redundant data to be transmitted, > and the total amount of data must remain within any bandwidth limits > indicated by congestion control and the receiver, this will lead to > less bandwidth available for the primary encoding, even when the > redundant data is not being used. This is in contrast to methods > like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] > retransmissions, which only transmit redundant data when necessary, > at the cost of an extra roundtrip. > > This seems to imply that "FEC" is a specific usage and that flexfec is not > a subset of generic FEC. If so, this could probably be reworded to be > less confusing to the reader (though my suspicion is that the "always > causes redundant data to be transmitted" is only intended to apply to > specific mechanisms from Section 3). > flexfec is not quite a subset of generic FEC, since it also has a retransmission format. Thoughts on how this could be reworded? > > Section 9 > > This document seems to be agnostic on the question of RTP vs. SRTP; I would > consider referencing their respective security considerations as well as > what is already covered here. > > As described in [RFC3711], Section 10, the default processing when > using FEC with SRTP is to perform FEC followed by SRTP at the sender, > and SRTP followed by FEC at the receiver. This ordering is used for > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as > described in [RFC5764], Section 4.1.2. > > I was going to comment about the lack of clarity here, but I see that Ekr > has already gotten the core points, and that the secdir review has already > resulted in some chanegs in the editor's copy. It would be nice to have > the result of the (merged) edits available to look at, though. > > Here's the latest text. Let me know if this needs to be further clarified. In the WebRTC context, FEC is specifically concerned with recovering data from lost packets; any corrupted packets will be discarded by the SRTP decryption process. Therefore, as described in , Section 10, the default processing when using FEC with SRTP is to perform FEC followed by SRTP at the sender, and SRTP followed by FEC at the receiver. This ordering is used for all the SRTP Protection Profiles used in DTLS-SRTP , which are enumerated in , Section 4.1.2. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000b9525a05828560c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments= . See below.

On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Benjamin Kaduk has entered the following = ballot position for
draft-ietf-rtcweb-fec-08: 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/s= tatement/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-r= tcweb-fec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3

nit: The subsequent discussion seems to indicate that at least some of
these mechanisms are already specified and not new in this document; (if so) it would be nice to have the exposition reflect that.

Section 3.3

=C2=A0 =C2=A0For Opus, packets deemed as important are re-encoded at a lowe= r
=C2=A0 =C2=A0bitrate and added to the subsequent packet, allowing partial r= ecovery

Is "added" supposed to be something other than "appended&quo= t; (which strongly
resembles the "redundant encoding" of the previous section)?
<= /blockquote>

It's similar to the redundant encoding,= but done within the Opus bitstream, rather than at the RTP level.

Section 4.1

Does it make sense to give subsection backreferences when talking about
(e.g.) redundant encoding?

Yes, this co= uld be done easily.=C2=A0

Section 5.2

=C2=A0 =C2=A0Support for a SSRC-multiplexed flexfec stream to protect a giv= en RTP
=C2=A0 =C2=A0stream SHOULD be indicated by including one of the formats des= cribed
=C2=A0 =C2=A0in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an<= br>
nit: Since this Section 5 is solely for video, is it more appropriate to refer to Section 5.1.2 ("Registration of video/flexfec") of
draft-ietf-payload-flexible-fec-scheme?

Agreed - earlier versions of flexfec were slightly different.=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Section 7

=C2=A0 =C2=A0To support the functionality recommended above, implementation= s MUST
=C2=A0 =C2=A0be able to receive and make use of the relevant FEC formats fo= r their
=C2=A0 =C2=A0supported audio codecs, and MUST indicate this support, as des= cribed
=C2=A0 =C2=A0in Section 4.=C2=A0 Use of these formats when sending, as ment= ioned above,
=C2=A0 =C2=A0is RECOMMENDED.

Just to double-check: this is explicitly only mandating FEC for audio and ignoring video entirely?

This para only= applies to audio. The following para discusses video, but is SHOULD-streng= th given the relative newness of flexfec.=C2=A0

Section 8

=C2=A0 =C2=A0Because use of FEC always causes redundant data to be transmit= ted,
=C2=A0 =C2=A0and the total amount of data must remain within any bandwidth = limits
=C2=A0 =C2=A0indicated by congestion control and the receiver, this will le= ad to
=C2=A0 =C2=A0less bandwidth available for the primary encoding, even when t= he
=C2=A0 =C2=A0redundant data is not being used.=C2=A0 This is in contrast to= methods
=C2=A0 =C2=A0like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-s= cheme]
=C2=A0 =C2=A0retransmissions, which only transmit redundant data when neces= sary,
=C2=A0 =C2=A0at the cost of an extra roundtrip.

This seems to imply that "FEC" is a specific usage and that flexf= ec is not
a subset of generic FEC.=C2=A0 If so, this could probably be reworded to be=
less confusing to the reader (though my suspicion is that the "always<= br> causes redundant data to be transmitted" is only intended to apply to<= br> specific mechanisms from Section 3).

fl= exfec is not quite a subset of generic FEC, since it also has a retransmiss= ion format. Thoughts on how this could be reworded?

Section 9

This document seems to be agnostic on the question of RTP vs. SRTP; I would=
consider referencing their respective security considerations as well as what is already covered here.

=C2=A0 =C2=A0As described in [RFC3711], Section 10, the default processing = when
=C2=A0 =C2=A0using FEC with SRTP is to perform FEC followed by SRTP at the = sender,
=C2=A0 =C2=A0and SRTP followed by FEC at the receiver.=C2=A0 This ordering = is used for
=C2=A0 =C2=A0all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], = as
=C2=A0 =C2=A0described in [RFC5764], Section 4.1.2.

I was going to comment about the lack of clarity here, but I see that Ekr has already gotten the core points, and that the secdir review has already<= br> resulted in some chanegs in the editor's copy.=C2=A0 It would be nice t= o have
the result of the (merged) edits available to look at, though.

=C2=A0Here's the latest text. Let me know if this= needs to be further clarified.

=C2=A0 =C2=A0= =C2=A0 In the WebRTC context, FEC is specifically concerned with recoverin= g
=C2=A0 =C2=A0 =C2=A0 data from lost packets; any corrupted pack= ets will be discarded by the
=C2=A0 =C2=A0 =C2=A0 SRTP <xref t= arget=3D"RFC3711" /> decryption process. Therefore, as describ= ed
=C2=A0 =C2=A0 =C2=A0 in <xref target=3D"RFC3711" = />, Section 10, the default processing when
=C2=A0 =C2=A0 =C2= =A0 using FEC with SRTP is to perform FEC followed by SRTP at the sender, a= nd
=C2=A0 =C2=A0 =C2=A0 SRTP followed by FEC at the receiver. Thi= s ordering is used for all the
=C2=A0 =C2=A0 =C2=A0 SRTP Protecti= on Profiles used in DTLS-SRTP
=C2=A0 =C2=A0 =C2=A0 <xref targe= t=3D"RFC5763" />, which are enumerated in
=C2=A0 =C2= =A0 =C2=A0 <xref target=3D"RFC5764" />, Section 4.1.2.
=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000b9525a05828560c8-- From nobody Fri Feb 22 17:17:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3ED130ED1 for ; Fri, 22 Feb 2019 17:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhBBMh3YSPXC for ; Fri, 22 Feb 2019 17:17:33 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 27CE612D4E7 for ; Fri, 22 Feb 2019 17:17:33 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id m137so5720920ita.0 for ; Fri, 22 Feb 2019 17:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lvaMjMfnnBW6ip6H4W6bSDt3TXPafq8PanvisqXnFS0=; b=rtJIYmHoGNauLVJErT4EfEx5SQXmFlWjfrZguR5diB6/sQ5MYDlS0b0v8ZZgg+enu2 bIm0HlDaTsfVbNtkOjPUoYq46mL5/hbJVVsxIjizAYV8AMpIg8UzEbuiJ3ICM4RzUoY7 482Zze6mijiDxP4AnSoLYgyERSa6YbI8zsZZ5r/NiP0+EIsqWVH5d0mQ+MqUayST+jto Lgshns0ZVDMtuOnhIbJCq+ozlkejEjr6D7/7ETURXLtL6qIs8eeAXyiA2Z8t/Slh4QDR HDrPb8ObkFdfnTqto7ZW4/9HvLfrryBFWfpJrXHwPnP3foGJT5OBpGhDswqj/fwIaXBl Tqhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lvaMjMfnnBW6ip6H4W6bSDt3TXPafq8PanvisqXnFS0=; b=udVjGitCuAeDR3GMhe/X0h6jH6Jr5rf6ckpQwmo3hUPTrBsdGDaxKBSjwVjMZvNMnx tNxWbqrzEt36U3hL5EsxDRYj47UJf5oLUmj1k58mvCjX0OJRfYR5CTo9ZOaJ8fRSnJWo psbDQKwozEwb9Z5Ki8Db5v051/PN02ZKzo5bJ/68W4Ya75JGFwdLvmt1vm2yWKfdu8iV udIjmIHUjKgW6DcFSpownachBt4eGqNjLVDhZAavJBd73SHQIsUIrG4V1FRhp1P/xK8Y rP0u64kGYS0dKguMWVVR2ipyxnfl47T3abakMtOxcUVCb9meRi+kkL9X2C+N+Hqg3At/ 2wcA== X-Gm-Message-State: AHQUAuZ+D0XnmxCjQwxfuLPRF2+5zF9sKoKSEpr9mmXao20suUvhXux4 sI/LSN91wf7jXNZNCnpFC2B9qSrQ9NA3HvgsPMgfyg== X-Google-Smtp-Source: AHgI3IbNHOukt5WKm/sAX7Sn0aPa8cBVKUmfBevbIcUtFS4wdom0pQLpdywHxfD4k+FLiPklpEmrVuQxhjAyXxmTMoo= X-Received: by 2002:a02:94eb:: with SMTP id x98mr3964942jah.88.1550884651568; Fri, 22 Feb 2019 17:17:31 -0800 (PST) MIME-Version: 1.0 References: <155068537927.31452.11334457138991637471.idtracker@ietfa.amsl.com> <4C5C447B-3CAA-436C-A60D-432B4374C39A@nostrum.com> In-Reply-To: <4C5C447B-3CAA-436C-A60D-432B4374C39A@nostrum.com> From: Justin Uberti Date: Fri, 22 Feb 2019 17:17:20 -0800 Message-ID: To: Ben Campbell Cc: The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org Content-Type: multipart/alternative; boundary="000000000000bf01cf0582857824" Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 01:17:36 -0000 --000000000000bf01cf0582857824 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 22, 2019 at 4:57 PM Ben Campbell wrote: > Thanks for the response. Comments below: > > On Feb 22, 2019, at 6:31 PM, Justin Uberti wrote: > > Thanks for your comments. See below: > > On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell wrote: > > > [=E2=80=A6] > > ---------------------------------------------------------------------- >> >> Thanks for this effort. I am balloting "yes", but have some minor >> comments: >> >> =C2=A78: >> - "Given this, WebRTC implementations SHOULD consider using RTX or >> flexfec retransmissions instead of FEC when RTT is low," >> >> "consider" seems vague for a normative requirement. Can you describe >> concrete >> requirements? Otherwise I suggest descriptive language. >> > > Perhaps "prefer" rather than "consider" would be less squishy. > > > Prefer is better, thanks. > > >> Can you give guidance on what RTT would be reasonable to consider as >> "low"? >> > > This is somewhat application-dependent, but ~100 ms would be a reasonable > threshold. > > > Would it make sense to say that the threshold for =E2=80=9Clow=E2=80=9D i= s application > dependent, but that would be a reasonable number for =E2=80=9Ctypical=E2= =80=9D applications? > > > >> - "Note that when probing bandwidth, i.e., speculatively sending extra >> data to determine if additional link capacity exists, FEC SHOULD be >> used in all cases." >> >> I assume the point of this is the redundant FEC data should _be_ that >> extra >> data. But one could read this to mean that, if you are already sending >> extra >> data, you should also use FEC. >> > > I see what you mean, agree this could be clarified. > > > Thanks > > >> =C2=A79, 2nd paragraph: >> >> I'm by no means an expert in this, and leave it to the crypto experts to >> know >> if this matters, but does the additional redundancy of FEC have any >> impact on >> SRTP encryption? >> > > My understanding is that the fact that FEC is sent as its own stream with > its own IV means that even if the data was identical to the primary > payload, there would be no issue. > > > Is that true for the case of in-band FEC at the codec level? > In the RFC 2198 case, SRTP is once again run over a new packet, again with a new IV (from a new sequence number), and a new primary payload, so the cipher state will be entirely different when the previous data is re-encrypted. In the codec in-band case, you have a new bitstream, so there are no repeated bytes. > > But given that no new mechanisms are being proposed in this document, it'= s > probably covered elsewhere. > > > I can accept that argument. > > Thanks! > > Ben. > --000000000000bf01cf0582857824 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 4:57 PM Ben C= ampbell <ben@nostrum.com> wrot= e:
Thanks for the response. Comments below:

On Feb 22, 2019, at 6:31 PM, Justin U= berti <juberti@g= oogle.com> wrote:

Thanks for your comments. See below:

On Wed, Feb 20, 2019 at 9:56 AM Ben = Campbell <ben@nostr= um.com> wrote:

[=E2=80=A6]

---------------------------------------------= -------------------------

Thanks for this effort. I am balloting &qu= ot;yes", but have some minor comments:

=C2=A78:
- "Give= n this, WebRTC implementations SHOULD consider using RTX or
flexfec retr= ansmissions instead of FEC when RTT is low,"

"consider&quo= t; seems vague for a normative requirement. Can you describe concrete
re= quirements? Otherwise I suggest descriptive language.
=
Perhaps "prefer" rather than "consider" = would be less squishy.=C2=A0

<= /div>
Prefer is better, thanks.


Can you give guidance on what RTT w= ould be reasonable to consider as "low"?
This is somewhat application-dependent, but ~100 ms would be a = reasonable threshold.

Would it make sense to say that the threshold for =E2=80=9Clow=E2=80=9D = is application dependent, but that would be a reasonable number for =E2=80= =9Ctypical=E2=80=9D applications?


=

- "Note that whe= n probing bandwidth, i.e., speculatively sending extra
data to determine= if additional link capacity exists, FEC SHOULD be
used in all cases.&qu= ot;

I assume the point of this is the redundant FEC data should _be_= that extra
data. But one could read this to mean that, if you are alrea= dy sending extra
data, you should also use FEC.
I see what you mean, agree this could be clarified.=C2=A0
=

Thanks


=C2=A79, 2nd = paragraph:

I'm by no means an expert in this, and leave it to th= e crypto experts to know
if this matters, but does the additional redund= ancy of FEC have any impact on
SRTP encryption?
My understanding is that the fact that FEC is sent as its own s= tream with its own IV means that even if the data was identical to the prim= ary payload, there would be no issue.
=

Is that true for the case of in-band FEC at the codec l= evel?

In the RFC 2198 cas= e, SRTP is once again run over a new packet, again with a new IV (from a ne= w sequence number), and a new primary payload, so the cipher state will be = entirely different when the previous data is re-encrypted. In the codec in-= band case, you have a new bitstream, so there are no repeated bytes.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

But given that no new mechani= sms are being proposed in this document, it's probably covered elsewher= e.=C2=A0

I can acce= pt that argument.

Thanks!

Ben.
--000000000000bf01cf0582857824-- From nobody Fri Feb 22 17:20:15 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603AF130EB0 for ; Fri, 22 Feb 2019 17:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZfub2GvMPLL for ; Fri, 22 Feb 2019 17:20:08 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 31C4D12D4E7 for ; Fri, 22 Feb 2019 17:20:06 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id i2so5970337ite.5 for ; Fri, 22 Feb 2019 17:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2jGUF1PqVz2Ca52vwsHOwTM89RNMEMBP9Z7LdIl/8pc=; b=UlVPgtgklXjS6Eu2z7xl9oHRzrvvza+pocswtZYeu/dvmUPJ0ZM1yJoS6dYQECvHE7 3ArBgZrEiRHHpjEZZOHWRDkln/Tmf2LuBLuau7PmywnsVXLMQaMYYmNuJ3OQDR04oJ2g gMQoeU048iZL36UAo1yf2kov2icXKmQzLDlQdmPt+5UU2x/G+oEchs6gSsUr8STEzAKn c94YVxlrNT7h+xNP3F5CIXv2cm/1b1HP/aGEKfB28C6npNkoog+a9pZuQd5D2vgd63Zx hdekUqc+RKllDf0a6b7/9ytbOfePQ+l730WEzKFsg1xmxxgiUG8l9vJIk5yFib79jtYc 02zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2jGUF1PqVz2Ca52vwsHOwTM89RNMEMBP9Z7LdIl/8pc=; b=dMsfj5Rolv0Do0lZqpumgfjcQ6Ceh1o9l6Jh9lVDJld/3quflKZnunkEEVdojJadQc KnG49ByYe1p+UCk9BbZp2yhlvTUSeHLZL0DL8f4y20X0Oh5q8MxnPr/Ab+v8ipRiQhRm Jc5MpMs6UljuTnr8qEMYZ0d1w+DfVoJff2sr5agC82Y9aQtxzVWHDAkm1NfiR1fNRAEf 2CEXN9/1ZdRE65M1ogsvT9gb1QzE3p8ofEagkYYrFfoKDhQAlQb4rjTxjzBSGczk574z je63de0vYno9QZvSWLFqUHJCaDgd9v8mazPV04mfZQ7c6leRuNzz7WxC59yo02r2A9wD PNgQ== X-Gm-Message-State: AHQUAubqsAlpGTv+8JL280syuhKcYDaCAjHlNUcFZJTjzIipjG4YTFtn DUFe4v6+6GtX2vxAEpBN3nsz0D++ZYJSSoVzq5CpuQ== X-Google-Smtp-Source: AHgI3IaFCzL1vbw1zFVP48RR7wb+ZrwIzTclhrD3CJhbItnkzQpcZsMKwfX9z5a5kpstQQ0l+iPMMfZb5Ek5aRttMuo= X-Received: by 2002:a24:28cb:: with SMTP id h194mr3876974ith.8.1550884804784; Fri, 22 Feb 2019 17:20:04 -0800 (PST) MIME-Version: 1.0 References: <155042612497.4083.2465692313767522646@ietfa.amsl.com> In-Reply-To: <155042612497.4083.2465692313767522646@ietfa.amsl.com> From: Justin Uberti Date: Fri, 22 Feb 2019 17:19:53 -0800 Message-ID: To: Joseph Touch Cc: tsv-art@ietf.org, draft-ietf-rtcweb-ip-handling.all@ietf.org, RTCWeb IETF , IETF discussion list Content-Type: multipart/alternative; boundary="000000000000e0d0d20582858175" Archived-At: Subject: Re: [rtcweb] Tsvart last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 01:20:09 -0000 --000000000000e0d0d20582858175 Content-Type: text/plain; charset="UTF-8" Thanks for your comments. See below. On Sun, Feb 17, 2019 at 9:56 AM Joseph Touch wrote: > Reviewer: Joseph Touch > Review result: Ready > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's > authors and WG to allow them to address any issues raised and also to the > IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > This document has no significant transport issues. > > As a very minor issue, the document refers to the use of UDP "connect": > > Once a suitable remote IP has been determined, the implementation can > create a UDP socket, bind it to the appropriate wildcard address, and > tell it to connect to the remote IP. Generally, this results in the > socket being assigned a local address based on the kernel routing > table, without sending any packets over the network. > > It might be useful to be more clear that this is an OS command (not a > protocol > one). If the particular semantics of this command are relevant, that > should be > noted as well. > Agreed. Thoughts on what would make this clearer? --000000000000e0d0d20582858175 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your comments. See below.
On Su= n, Feb 17, 2019 at 9:56 AM Joseph Touch <touch@strayalpha.com> wrote:
Reviewer: Joseph Touch
Review result: Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org = if you reply to or forward this review.

This document has no significant transport issues.

As a very minor issue, the document refers to the use of UDP "connect&= quot;:

=C2=A0 =C2=A0Once a suitable remote IP has been determined, the implementat= ion can
=C2=A0 =C2=A0create a UDP socket, bind it to the appropriate wildcard addre= ss, and
=C2=A0 =C2=A0tell it to connect to the remote IP.=C2=A0 Generally, this res= ults in the
=C2=A0 =C2=A0socket being assigned a local address based on the kernel rout= ing
=C2=A0 =C2=A0table, without sending any packets over the network.

It might be useful to be more clear that this is an OS command (not a proto= col
one). If the particular semantics of this command are relevant, that should= be
noted as well.

Agreed. Thoughts on what= would make this clearer?=C2=A0
--000000000000e0d0d20582858175-- From nobody Fri Feb 22 17:28:32 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02413130EB0 for ; Fri, 22 Feb 2019 17:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZQBBmccOJOn for ; Fri, 22 Feb 2019 17:28:28 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 2FB10130F29 for ; Fri, 22 Feb 2019 17:28:28 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id y6so3283463ioq.10 for ; Fri, 22 Feb 2019 17:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PcnL2yucadYuTG4YW6p662J+uA6i2sW6uhEg7sImxY0=; b=h6AOQo2T5uA6yHuKvbzkSQu2Uk6Xe6WadGl1TFDZGhTrx4+qEQMLyrR0DOK3ijBCqq c+Rb/0R/dXY3SUd2yX3nF8lIV91ijp9ePvbuwHYdTfXQTuoTYG3EnWxEzUnZSmVcbr/S 63Msbu/9508kPdYtwnQKMHyqqyKFHFhGlQJ2Q4pgBJG77IXJDEe7zrGOg8innMBeWE4B 5Uk883SNkM6ZEVdlwIFBWPGa5HeThh1F1s6miFfNEn1QQZiumexR087SGvWoOprjqHhE +70ECLLvMqOb12EW70IbK55Ux7+xNstchWRBFVKUoxuyhMKAKwXvKY28jFgWZtCkjjRw +9ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PcnL2yucadYuTG4YW6p662J+uA6i2sW6uhEg7sImxY0=; b=GQdfpQke0ugJB+vn1S6L0zUn/yCkzwwb6/51V2Ff1fgYKDn0txtuPWTFnK4JRBgcbO Ge2Sm6ryxy4JWh+X14NZ0xeO3KRm4a9v4W7qtcBzdEiSCynd/U8oxmVrt+5YyaMSsF0i 0/SiaccDbHop8/QKVFwNXhtxxLhn5/UafiSMzRB0DEG99NZ575crfZPCwSmuytt/pGcz wFLdO/JjJ69bj/V19O124gKGpxNG8kUWu49BUCzMRgjKq14Ob8qBhKXnkBBXjFhvmTTF TVP3LJZ18DkRGaAt4hATEiVl5atWwJFMBJ1glYjSCl3NASvK7fLpsTD0QtO2YzfIVxIS R4pQ== X-Gm-Message-State: AHQUAuZcRlsy2x6q+p7P8WKiW0DiRLOIZwwMf3BG9I0DNs6plJm1icc4 eo9TcUM8D108Zc9HRl2BpTHUKvMzxkDR9VJR5nHg2Q== X-Google-Smtp-Source: AHgI3IZy7nNJ848QiIc+C1sPDBhgB4P0PvR88abXQPaXA08eQ+Oi97IvEKvE3mvsMrkyhxn8g8iz1WU0NIErzUUx3gM= X-Received: by 2002:a6b:f01a:: with SMTP id w26mr3861549ioc.101.1550885306668; Fri, 22 Feb 2019 17:28:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Fri, 22 Feb 2019 17:28:13 -0800 Message-ID: To: =?UTF-8?B?157XoNeX150g15PXldeT15In?= Cc: ops-dir@ietf.org, draft-ietf-rtcweb-ip-handling.all@ietf.org, RTCWeb IETF , IETF discussion list , Justin Uberti Content-Type: multipart/alternative; boundary="000000000000cb2ed60582859f37" Archived-At: Subject: Re: [rtcweb] [OPS-DIR] Opsdir last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 01:28:31 -0000 --000000000000cb2ed60582859f37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your comments. See below. =E2=80=AAOn Sun, Feb 17, 2019 at 1:59 PM =E2=80=AB=D7=9E=D7=A0=D7=97=D7=9D = =D7=93=D7=95=D7=93=D7=92'=E2=80=AC=E2=80=8E wrote:=E2=80=AC > > Reviewer: Menachem Dodge > Review Result: Has Nits > > This document has "Intended Status" for the Standards Track but the > document is written as an informational guide. I suggest that the ADs > decide whether this is informational or for the Standards Track. > Not sure exactly how this is decided, but this document is trying to set specific requirements for how browsers should operate. As such, it seems like Standards Track is probably the better opion. > > On the whole the document is written well and is understandable. > > In Section 5.2 it states that: > > "Mode 1 MUST only be used when user consent has been provided. The > details of this consent are left to the implementation; one potential > mechanism is to tie this consent to *getUserMedia *consent. " > > I'm not sure what "getUserMedia consent" refers to. > I can add a reference to security-arch, e.g. https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#section-6.2 > > While the document defines that Mode 1 should be used when there is user > consent and Mode 2 should be used when there is no User consent , however > when should Mode 3 and Mode 4 be used? > These modes roughly equate to stops on a maximum-performance<-->minimum-disclosure tradeoff slider. Implementations that are willing to incur the performance consequences may decide to adopt stricter default modes (and, we have seen that the Brave browser does exactly that.) As noted in the document: However, implementations MAY choose stricter modes if desired, e.g., if a user indicates they want all WebRTC traffic to follow the default route. > The document also states that: > > "Future documents may define additional modes and/or update the > recommended default modes. " > > If this is the case should there be a "version" defined so that the webRT= C > client and Server no which implementation has been implemented? > The server doesn't need to know which mode has been selected; the modes are entirely specific to client behavior. --000000000000cb2ed60582859f37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your com= ments. See below.

=E2=80=AAOn Sun, Feb 17, 2019 at 1:59 PM =E2=80=AB=D7=9E= =D7=A0=D7=97=D7=9D =D7=93=D7=95=D7=93=D7=92'=E2=80=AC=E2=80=8E <menachemdodge1@gmail.com> wr= ote:=E2=80=AC
=C2=A0
Reviewer: Menachem Dodge=C2=A0
<= div dir=3D"ltr">Review Result: Has Nits

This document has "Intended Status" for the Standar= ds Track but the document is written as an informational guide. I suggest= =C2=A0 that the ADs decide whether this is informational or for the Standar= ds Track.

Not sure exactly how = this is decided, but this document is trying to set specific requirements f= or how browsers should operate. As such, it seems like Standards Track is p= robably the better opion.

On the w= hole the document is written well and is understandable.=C2=A0

In Section 5.2 it states that:

=C2=A0 "Mode 1 MUST only be = used when user consent has been provided. The details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent.=C2=A0 =C2= =A0"

I'm not = sure what "getUserMedia consent" refers to.

I can add a reference to security-arch, e.g.=C2=A0https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#se= ction-6.2=C2=A0
=

While the docu= ment defines that Mode 1 should be used when there is user consent and Mode= 2 should be used when there is no User consent , however when should Mode = 3 and Mode 4 be used?

These mod= es roughly equate to stops on a maximum-performance<-->minimum-disclo= sure tradeoff slider. Implementations that are willing to incur the perform= ance consequences may decide to adopt stricter default modes (and, we have = seen that the Brave browser does exactly that.) As noted in the document:

=C2=A0 =C2=A0However, implementations MAY
=C2=A0 =C2=A0choose stricter modes if desired, e.g., if a user indicates t= hey want
=C2=A0 =C2=A0all WebRTC traffic to follow the default ro= ute.=C2=A0



The document also states that:=C2=A0

=C2=A0 "Future documents may define additional mod= es and/or update the recommended default modes. "=C2=A0

If this is the case should there be a "version"= ; defined so that the webRTC client and Server no which implementation has = been implemented?

The server do= esn't need to know which mode has been selected; the modes are entirely= specific to client behavior.
--000000000000cb2ed60582859f37-- From nobody Fri Feb 22 17:33:54 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F5F12D4E7; Fri, 22 Feb 2019 17:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 bsIWOhonVn1g; Fri, 22 Feb 2019 17:33:44 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6D155130F83; Fri, 22 Feb 2019 17:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nsVzVrziw5gAPccQHP6yxsA2fPalvt0rdCorx1e3/FU=; b=fRq5d01ESTHPO5k9KH8sMc0c6 IXh1nBhO7yPHEtwykDmvVg1KA0T4Qt6iqFv+xXKWJ5ZG15V2+QXGkq9U5wuYwCp+PwjNd6o4XZRqw 8PZm728csNOcIVvrxs6OdYVeLWovXMg+DNG38kxvf9tiwi+upPS6gwXyfXKS0MTf5mmW3FBivVk0H 5D3/vLVZUedh6wj3+cZCAoI20heOWY/hEkG3OL4c9EoIAV/lWgoegTnOBqeZJ31Ene0VI7euCzkfR vYPVpLByO8R7RU5ffEPUuITpCnAYOZvrwx0i2L5YFmjtk2x3/4+MAH/OyXq2uxKkxeIHifU3iO/5M DEoCQ5Pnw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:57804 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gxMCC-002oM2-ES; Fri, 22 Feb 2019 20:33:42 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7E2481DD-3ECA-45AD-9DEC-3FDE5308948B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joe Touch In-Reply-To: Date: Fri, 22 Feb 2019 17:33:39 -0800 Cc: tsv-art@ietf.org, RTCWeb IETF , IETF discussion list , draft-ietf-rtcweb-ip-handling.all@ietf.org Message-Id: <7214C146-4B65-429E-AA90-4ED9E2654472@strayalpha.com> References: <155042612497.4083.2465692313767522646@ietfa.amsl.com> To: Justin Uberti X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [rtcweb] [Tsv-art] Tsvart last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 01:33:47 -0000 --Apple-Mail=_7E2481DD-3ECA-45AD-9DEC-3FDE5308948B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You could just add =E2=80=9CUnix=E2=80=9D or =E2=80=9CUnix-like=E2=80=9D = to before =E2=80=9Cconnect=E2=80=9D, or refer to these calls as = =E2=80=9Cbind()=E2=80=9D and =E2=80=9Cconnect()=E2=80=9D. It is important that these are the semantics of Unix-like sockets; other = APIs may not have a corresponding mechanism. Further, the UDP source = address might change later (i.e., in TCP the =E2=80=9Cconnect=E2=80=9D = always forces a static source IP address selected at the initiation of = the TCP connection; in UDP, there=E2=80=99s no need for this to happen = only once at the time the =E2=80=9Cconnect()=E2=80=9D is issued. Joe > On Feb 22, 2019, at 5:19 PM, Justin Uberti = wrote: >=20 > Thanks for your comments. See below. >=20 > On Sun, Feb 17, 2019 at 9:56 AM Joseph Touch > wrote: > Reviewer: Joseph Touch > Review result: Ready >=20 > This document has been reviewed as part of the transport area review = team's > ongoing effort to review key IETF documents. These comments were = written > primarily for the transport area directors, but are copied to the = document's > authors and WG to allow them to address any issues raised and also to = the IETF > discussion list for information. >=20 > When done at the time of IETF Last Call, the authors should consider = this > review as part of the last-call comments they receive. Please always = CC > tsv-art@ietf.org if you reply to or forward = this review. >=20 > This document has no significant transport issues. >=20 > As a very minor issue, the document refers to the use of UDP = "connect": >=20 > Once a suitable remote IP has been determined, the implementation = can > create a UDP socket, bind it to the appropriate wildcard address, = and > tell it to connect to the remote IP. Generally, this results in = the > socket being assigned a local address based on the kernel routing > table, without sending any packets over the network. >=20 > It might be useful to be more clear that this is an OS command (not a = protocol > one). If the particular semantics of this command are relevant, that = should be > noted as well. >=20 > Agreed. Thoughts on what would make this clearer?=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art --Apple-Mail=_7E2481DD-3ECA-45AD-9DEC-3FDE5308948B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You = could just add =E2=80=9CUnix=E2=80=9D or =E2=80=9CUnix-like=E2=80=9D to = before =E2=80=9Cconnect=E2=80=9D, or refer to these calls as = =E2=80=9Cbind()=E2=80=9D and =E2=80=9Cconnect()=E2=80=9D.

It is important that = these are the semantics of Unix-like sockets; other APIs may not have a = corresponding mechanism. Further, the UDP source address might change = later (i.e., in TCP the =E2=80=9Cconnect=E2=80=9D always forces a static = source IP address selected at the initiation of the TCP connection; in = UDP, there=E2=80=99s no need for this to happen only once at the time = the =E2=80=9Cconnect()=E2=80=9D is issued.

Joe

On Feb = 22, 2019, at 5:19 PM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:

Thanks for your comments. See = below.

On Sun, Feb 17, 2019 at 9:56 AM Joseph Touch <touch@strayalpha.com> wrote:
Reviewer: Joseph Touch
Review result: Ready

This document has been reviewed as part of the transport area review = team's
ongoing effort to review key IETF documents. These comments were = written
primarily for the transport area directors, but are copied to the = document's
authors and WG to allow them to address any issues raised and also to = the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider = this
review as part of the last-call comments they receive. Please always = CC
tsv-art@ietf.org if you reply to or forward this = review.

This document has no significant transport issues.

As a very minor issue, the document refers to the use of UDP = "connect":

   Once a suitable remote IP has been determined, the = implementation can
   create a UDP socket, bind it to the appropriate wildcard = address, and
   tell it to connect to the remote IP.  Generally, this = results in the
   socket being assigned a local address based on the kernel = routing
   table, without sending any packets over the network.

It might be useful to be more clear that this is an OS command (not a = protocol
one). If the particular semantics of this command are relevant, that = should be
noted as well.

Agreed. Thoughts on what would make = this clearer? 
_______________________________________________
Tsv-art = mailing list
Tsv-art@ietf.org
https://www.ietf.org/mailman/listinfo/tsv-art

= --Apple-Mail=_7E2481DD-3ECA-45AD-9DEC-3FDE5308948B-- From nobody Fri Feb 22 17:46:40 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB10130F93 for ; Fri, 22 Feb 2019 17:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8l1a4byQYT8 for ; Fri, 22 Feb 2019 17:46:36 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 0BCE612D4E9 for ; Fri, 22 Feb 2019 17:46:35 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id m137so5780020ita.0 for ; Fri, 22 Feb 2019 17:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=98l/SZb13KgQbkv7Qk9HCwvXQSVJonxKRoxxrA9YWJ4=; b=dnGkGya3lR6mZqwtQPlkZH420laS1zEU5Pz5+cJYHoqCEArFiQSiO1PfB8X8Ig1euA PCKmpPsatUfnpARSNTlFie3fASEtb1H/jkZJIMy8hSc4C+fnJPC3nJvq5/zsGYefnuRP VxvvKbFyVwd16haD1Er6lKqIa9fI40Wyc0oqoKq9nYGQV8j77MHgFoiPp3taA/aCx51E SF7GR7inucomZ+bFq89tRYSPomxP74z6XrOx2oCsLW7lfZF3ZW/3ExmUN1bhVtm1uZHA hXz40w2icYsyQe5l8DR5QSDVI7Ax9sVpzbo6+LKX9FAtQZDzSkh4IQOu+/lN3TebBpF5 ydAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=98l/SZb13KgQbkv7Qk9HCwvXQSVJonxKRoxxrA9YWJ4=; b=j40Wf/gNpmMcZHKIAISK7mnAHYIHCoJHTAgWAwrmtRGnIKB0sw/z1L2eIR/aA81T3d Id9RXzK35oLcK6rIBlFJiTZfTn449oEdr0kp5aUuqxKaggmwoKxQli2oYgmoTtpDYvcf X2g0/9MylsVLxOQXxuU6spEkf82W2XitQsMvLnvXosC3NJHHdM92ENdN5DPMavblNX/q /VgM3pdypJQ8+scbHz99c2dgLzmSBLUfSVYfr6mrJPZxq0M2JqKtt3BZQMhJDJi5KnbK eTPIYqULxdTsL6CgfhwLndmY9UwYqFuY8s/COY4STyUzDxkySo6TgRbAyDkeCiMDrdVG eVQw== X-Gm-Message-State: AHQUAuYG9HjLVZIHIPwInCLxCRHdapTzI5IPuIdJLoxKzdf3y+VmC42Y brXpx3QC9oeZxNbZSDyjwqvcOgOSNl3IheboEF9P+Q== X-Google-Smtp-Source: AHgI3IYgVkwcU/LacdTEUlntWE3B4BYTb1Ev+9MvMrP/CsSU9/If7z479aTl6zp29pY6QqB2DCVq/bGDZl7ts2NymfQ= X-Received: by 2002:a24:28cb:: with SMTP id h194mr3910655ith.8.1550886394614; Fri, 22 Feb 2019 17:46:34 -0800 (PST) MIME-Version: 1.0 References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> In-Reply-To: From: Justin Uberti Date: Fri, 22 Feb 2019 17:46:23 -0800 Message-ID: To: Roman Shpount Cc: Ted Hardie , RTCWeb IETF , Christer Holmberg Content-Type: multipart/alternative; boundary="000000000000a3aa6d058285e00f" Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 01:46:39 -0000 --000000000000a3aa6d058285e00f Content-Type: text/plain; charset="UTF-8" Roman, thanks for raising this. I looked into this a bit and it's kind of ambiguous; https://tools.ietf.org/html/rfc7850 uses "profile", "proto", and "protocol" (although "protocol" is used most frequently). JSEP actually uses both profile and protocol to refer to the transport, depending on the section; if we make a change here, we should hit all usages, which probably means that it is outside of the scope of this particular issue. On Tue, Feb 19, 2019 at 1:19 PM Roman Shpount wrote: > Hi Justin, > > I did provide editorial feedback to the change on github: > > 1. This document refers to SDP protocol as profile. If you look at the > referenced documents that define "profiles" in JSEP, they all refer to them > as protocols. Also, in case of SRTP, profile is actually something > different and refers to SRTP key parameters. > > 2. Default candidate does not have profile (or protocol), it has > transport, port, and (connection-)address. So each "m=" and "c=" MUST be > filled in with port, protocol, and address to match port, transport, and > address of the default candidate for the m= section, as described in > ice-sip-sdp. > > Regards, > _____________ > Roman Shpount > > > On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Looks good. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From: *rtcweb on behalf of Justin Uberti >> > >> *Date: *Saturday, 16 February 2019 at 3.57 >> *To: *Ted Hardie >> *Cc: *"rtcweb@ietf.org" >> *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport >> parameter issue >> >> >> >> I have updated this PR to incorporate minor feedback that was received >> during the consensus call. Those who had feedback, please take another look >> and comment on the PR if you are satisfied. >> >> >> >> On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie wrote: >> >> The chairs believe that there was rough consensus among those responding >> to make the change in: >> >> >> >> https://github.com/rtcweb-wg/jsep/pull/863 >> >> >> >> Given the state of the document, it will be the Area Director's call as >> to how much of the post-working group approval process must be re-done. >> Authors, please wait on his direction before publishing a new version with >> this merged. >> >> >> >> Regards, >> >> Ted and Sean >> >> _______________________________________________ >> 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 >> > --000000000000a3aa6d058285e00f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Roman, thanks for raising this. I looked = into this a bit and it's kind of ambiguous; https://tools.ietf.org/html/rfc7850 uses "pro= file", "proto", and "protocol" (although "pro= tocol" is used most frequently).

JSEP actually uses= both profile and protocol to refer to the transport, depending on the sect= ion; if we make a change here, we should hit all usages, which probably mea= ns that it is outside of the scope of this particular issue.

On = Tue, Feb 19, 2019 at 1:19 PM Roman Shpount <roman@telurix.com> wrote:
Hi Justin,
=
I did provide editorial feedback to the change on github:

1. This document refers to SDP protocol as prof= ile. If you look at the referenced documents that define "profiles&quo= t; in JSEP, they all refer to them as protocols. Also, in case of SRTP, pro= file is actually something different and refers to SRTP key parameters.

2. Default candidate does not have profile (or protoc= ol), it has transport, port, and (connection-)address. So each "m=3D&q= uot; and "c=3D" MUST be filled in with port, protocol, and addres= s to match port, transport, and address of the default candidate for the m= =3D section, as described in ice-sip-sdp.

Regards,=
_____________
Roman Shpount


<= div class=3D"gmail_quote">
On Tue, Feb= 19, 2019 at 3:05 PM Christer Holmberg <christer.holmberg@ericsson.com> = wrote:

Looks good.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = rtcweb <rtcweb-bounces@ietf.org<= /a>> on behalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org>=
Date: Saturday, 16 February 2019 at 3.57
To: Ted Hardie <ted.ietf@gmail.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

I have updated this PR to incorporate minor feedback= that was received during the consensus call. Those who had feedback, pleas= e take another look and comment on the PR if you are satisfied.

=C2=A0

On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

The chairs believe that there was rough consensus am= ong those responding to make the change in:

=C2=A0

=C2=A0

Given the state of the document, it will be the Area= Director's call as to how much of the post-working group approval proc= ess must be re-done.=C2=A0 Authors, please wait on his direction before pub= lishing a new version with this merged.

=C2=A0

Regards,

Ted and Sean

_______________________________________________
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
--000000000000a3aa6d058285e00f-- From nobody Fri Feb 22 19:51:38 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41F113103F; Fri, 22 Feb 2019 19:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2Jmy5wTEfZY; Fri, 22 Feb 2019 19:51:34 -0800 (PST) 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 5512D130EE8; Fri, 22 Feb 2019 19:51:34 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1N3pSVh052957 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 Feb 2019 21:51:31 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550893893; bh=Y9VN/aPX4CSzx9611QLFycOQO8JzBjNvVIs3YqUkYTA=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=GUV9JKzGF2WP3yapIkAN7I5UFP57RDSgShrRqwnugmA3otRj3HeLohzHNTZlasZA6 Jt9biYpFjnUFmeUHqtkWCi5F2HnOQwa5+do0HiMsYq7bd7/SEwmJGAUrb32eAV5C3A ZP+scKJCDecvdvmexOT/36LduxzAij5WS8L/NooY= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A948554D-568E-41CB-BAF4-23F15CC50C17"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 22 Feb 2019 21:51:23 -0600 In-Reply-To: Cc: RTCWeb IETF , The IESG , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org To: Justin Uberti References: <155068537927.31452.11334457138991637471.idtracker@ietfa.amsl.com> <4C5C447B-3CAA-436C-A60D-432B4374C39A@nostrum.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 03:51:37 -0000 --Apple-Mail=_A948554D-568E-41CB-BAF4-23F15CC50C17 Content-Type: multipart/alternative; boundary="Apple-Mail=_8BAEF597-BE05-4703-B040-662A433E031F" --Apple-Mail=_8BAEF597-BE05-4703-B040-662A433E031F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 22, 2019, at 7:17 PM, Justin Uberti = wrote: >=20 >=20 >=20 > On Fri, Feb 22, 2019 at 4:57 PM Ben Campbell > wrote: > Thanks for the response. Comments below: >=20 >> On Feb 22, 2019, at 6:31 PM, Justin Uberti > wrote: >>=20 >> Thanks for your comments. See below: >>=20 >> On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell > wrote: >=20 > [=E2=80=A6] >=20 >> = ---------------------------------------------------------------------- >>=20 >> Thanks for this effort. I am balloting "yes", but have some minor = comments: >>=20 >> =C2=A78: >> - "Given this, WebRTC implementations SHOULD consider using RTX or >> flexfec retransmissions instead of FEC when RTT is low," >>=20 >> "consider" seems vague for a normative requirement. Can you describe = concrete >> requirements? Otherwise I suggest descriptive language. >>=20 >> Perhaps "prefer" rather than "consider" would be less squishy. >=20 > Prefer is better, thanks. >=20 >>=20 >> Can you give guidance on what RTT would be reasonable to consider as = "low"? >>=20 >> This is somewhat application-dependent, but ~100 ms would be a = reasonable threshold. >=20 > Would it make sense to say that the threshold for =E2=80=9Clow=E2=80=9D = is application dependent, but that would be a reasonable number for = =E2=80=9Ctypical=E2=80=9D applications? >=20 >=20 >>=20 >> - "Note that when probing bandwidth, i.e., speculatively sending = extra >> data to determine if additional link capacity exists, FEC SHOULD be >> used in all cases." >>=20 >> I assume the point of this is the redundant FEC data should _be_ that = extra >> data. But one could read this to mean that, if you are already = sending extra >> data, you should also use FEC. >>=20 >> I see what you mean, agree this could be clarified. >=20 > Thanks >=20 >>=20 >> =C2=A79, 2nd paragraph: >>=20 >> I'm by no means an expert in this, and leave it to the crypto experts = to know >> if this matters, but does the additional redundancy of FEC have any = impact on >> SRTP encryption? >>=20 >> My understanding is that the fact that FEC is sent as its own stream = with its own IV means that even if the data was identical to the primary = payload, there would be no issue. >=20 > Is that true for the case of in-band FEC at the codec level? >=20 > In the RFC 2198 case, SRTP is once again run over a new packet, again = with a new IV (from a new sequence number), and a new primary payload, = so the cipher state will be entirely different when the previous data is = re-encrypted. In the codec in-band case, you have a new bitstream, so = there are no repeated bytes. Okay, I=E2=80=99m convinced. Thanks! Ben. --Apple-Mail=_8BAEF597-BE05-4703-B040-662A433E031F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 22, 2019, at 7:17 PM, Justin Uberti <juberti=3D40google.com@dmarc.ietf.org> wrote:



On Fri, Feb 22, 2019 at 4:57 PM Ben Campbell <ben@nostrum.com> = wrote:
Thanks for the response. Comments below:

On Feb 22, 2019, at 6:31 PM, Justin Uberti = <juberti@google.com> wrote:

Thanks for = your comments. See below:

On Wed, Feb = 20, 2019 at 9:56 AM Ben Campbell <ben@nostrum.com> wrote:

[=E2=80=A6]

---------------------------------------= -------------------------------

Thanks for = this effort. I am balloting "yes", but have some minor comments:

=C2=A78:
- "Given this, WebRTC = implementations SHOULD consider using RTX or
flexfec = retransmissions instead of FEC when RTT is low,"

"consider" seems vague for a normative requirement. Can you = describe concrete
requirements? Otherwise I suggest = descriptive language.

Perhaps "prefer" rather than "consider" = would be less squishy. 

Prefer is better, = thanks.


Can you give = guidance on what RTT would be reasonable to consider as "low"?

This is somewhat application-dependent, but ~100 ms would be = a reasonable threshold.

Would it make sense to = say that the threshold for =E2=80=9Clow=E2=80=9D is application = dependent, but that would be a reasonable number for =E2=80=9Ctypical=E2=80= =9D applications?



- "Note that = when probing bandwidth, i.e., speculatively sending extra
data to determine if additional link capacity exists, FEC = SHOULD be
used in all cases."

I= assume the point of this is the redundant FEC data should _be_ that = extra
data. But one could read this to mean that, if you = are already sending extra
data, you should also use = FEC.

I see what you mean, agree this could be = clarified. 

Thanks


=C2=A79, 2nd = paragraph:

I'm by no means an expert in = this, and leave it to the crypto experts to know
if this = matters, but does the additional redundancy of FEC have any impact on
SRTP encryption?
My understanding is that the fact that = FEC is sent as its own stream with its own IV means that even if the = data was identical to the primary payload, there would be no issue. =

Is that true for the case of in-band = FEC at the codec level?

In the RFC 2198 case, SRTP is once = again run over a new packet, again with a new IV (from a new sequence = number), and a new primary payload, so the cipher state will be entirely = different when the previous data is re-encrypted. In the codec in-band = case, you have a new bitstream, so there are no repeated = bytes.

Okay, I=E2=80=99m convinced. Thanks!

Ben.

= --Apple-Mail=_8BAEF597-BE05-4703-B040-662A433E031F-- --Apple-Mail=_A948554D-568E-41CB-BAF4-23F15CC50C17 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxwwzsACgkQgFZKbJXz 1A1ZYg/+NBV2Cc31UkXsBHo1BP/jqHG/ITWdsOBj2f4O5DQmuReljWDz0/k8RQCh F4SPmU30jhCRyvuLpuuWqgLKA72Clwsmx0Bk4mjGvkOPxMLC1XMuBZrZpsSbz8+R pUFYqkvFgY/ZF0kuUX43OK12YeAJNCbJiYGFabZsBJk+Vgt6bts1RB7CRY2kAT/o YBNKdd+peCCC42fzUrEtl0uUyt5JZSJnayOyRo3GFXwgvr/KtKcUj4PqhrQjICYf t783AOrswblCwe0e4d6u3kJBVOgXl83t+akORqfhgxZ9NZVERi/DLtPKWFrqAYa2 pN+kAsvpmihkfCl5s6XcmsIHG3s/v+23Wge/d/45Wx0HRPzlsfuMDU8p3KM38v7q zA1YRJAdaOiSTVniXZzMpCsRaQpsffu3dztC0Watlh5TWHBzUC248iZW6lJlPxte fOLJVrTGhuwCIEk8uZyo9psvek/cYkDiQ9a+G5KoxHw8azB/vAOyJR8RGgjy/99M ps50NqKVvJw6Am68EQr+TK+ZaCAhGTAnx02NvBaZnlsbG0lLStcupdQcVArSyxmG FeSEa+qt/F0hWEl8/ZreFVjHQxYImt+fLV6THBjLUcHAwcMX2M0EEYgRLyvKcu9r f4r0O5MMsOPTkxVayIczChIBfD+B94Uio15bzOGJQNwXKisRt4I= =KTIn -----END PGP SIGNATURE----- --Apple-Mail=_A948554D-568E-41CB-BAF4-23F15CC50C17-- From nobody Sat Feb 23 04:30:31 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C789130EE7 for ; Sat, 23 Feb 2019 04:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ7VueBH2Iyt for ; Sat, 23 Feb 2019 04:30:28 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29B1130EC9 for ; Sat, 23 Feb 2019 04:30:27 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id g80so3779014ljg.6 for ; Sat, 23 Feb 2019 04:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4kHrOpR9YNWAUGMomS8HMqqDEQ29itIBr7Sy1GawsPE=; b=kvDaHJe7Wxdreo3N7gGwe7a67OUGkWvSim1HsgBr5PBno31CML2bBL69phdWDLtV2v quJ0/sM8CV2PV2ulE0Eyjtse5RL+4zb2tgvuw8IuDbMg/L5BFcjGCGkrIExiXH4aoDnf YX+l2H45Gj2znN8f3DmKdBv9fdXuP7C3VaU6qJ+NcpZ3D5uXrfyRxTQSu250T4DaM9lz HI8ZgFJwXpayJC89gofr+8knQU1TU75Ld7iE+LzEISz0cyoFjkTznk7PSDx/tRdG/Yll xfr2iU5tweJHeGIxoc2Lx2TQLrvOGNj1cmQFx2bO6L2sxzpJcgKkiVW4Ti9vfj3BrduL Uphg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4kHrOpR9YNWAUGMomS8HMqqDEQ29itIBr7Sy1GawsPE=; b=Jr2ZawvKmID1FOdpJeBiISpgKuQtZ1n/AT+6fBG+KI5ZuVNYJVgnIF3BDElCO/jqBk BWyWmzh1JEVVLEkK1AGTMsQFV2oX80VLsWIVfTS+YcdUnzoCOAiP3icaxX2yK7R1c3+D AxGdGpm/bVPCmqLZSza1MoM/+2ubux6cqHkT4nVaMDszHU/4djFwwh3pfDC5JiFsPHro Dvx2aaOfRaF/O4ueqwlqGIR7+UJ5mQUQ1tPFlr1zblJOrw52Q/vs5L7lVGacEXE2fjPf xI2KigCf6HkeH9tPq9ZOn+Ty4TEYQ5/eJbYD1t697hmXDXjRbIcy1N/vqo8CToIeacbu P3FA== X-Gm-Message-State: AHQUAuaN1nE7jhsRqSKN4q7UDokujUTod2prpzY+GKh2N++xbc7Yov+S VZ/p3Qib0Tx1tz2OCZhXK3dPY6/Kmt7kbsbfniclcg== X-Google-Smtp-Source: AHgI3IYkieSBXEoZdw0SY3Ec+uDcR0RazvoaijjZq/UAWOk3yLF5QZqvdjHaHS3TIMBjapGL6peSNJwj7Z7ZW6paJuU= X-Received: by 2002:a2e:3c19:: with SMTP id j25mr4949833lja.72.1550925025392; Sat, 23 Feb 2019 04:30:25 -0800 (PST) MIME-Version: 1.0 References: <155041598050.4092.17319548267050845938.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Sat, 23 Feb 2019 04:29:46 -0800 Message-ID: To: Justin Uberti Cc: The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org Content-Type: multipart/alternative; boundary="00000000000036533c05828edfd4" Archived-At: Subject: Re: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 12:30:30 -0000 --00000000000036533c05828edfd4 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 22, 2019 at 4:18 PM Justin Uberti wrote: > Thanks for your comments, see below: > > On Sun, Feb 17, 2019 at 7:06 AM Eric Rescorla wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-rtcweb-fec-08: 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-fec/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Rich version of this review at: >> https://mozphab-ietf.devsvcdev.mozaws.net/D3278 >> >> >> >> COMMENTS >> S 5.2. >> > as described in [RFC5956], Section 4.1 is not currently defined for >> > WebRTC, and SHOULD NOT be offered. >> > >> > Answerers SHOULD reject any FEC-only m-lines, unless they >> > specifically know how to handle such a thing in a WebRTC context >> > (perhaps defined by a future version of the WebRTC specifications). >> >> It seems like the above three paragraphs are generic to this document, >> and just grouped with video because the audio codecs tend to have >> internal FEC? If so, maybe put them elasewhere? >> > > As noted elsewhere in the document, the recommendation is to only use > flexfec with video. These paras could be put elsewhere, e.g., in a > "negotiating flexfec" section, and then 5.2 could point to said section, > but it's not clear this would enhance readability. > OK. I'm not going to push on this point. >> >> S 9. >> > >> > As described in [RFC3711], Section 10, the default processing when >> > using FEC with SRTP is to perform FEC followed by SRTP at the >> sender, >> > and SRTP followed by FEC at the receiver. This ordering is used >> for >> > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as >> > described in [RFC5764], Section 4.1.2. >> >> I of course agree with this text, but I wonder if it's maximally >> clear. Perhaps rewrite the >> first sentence as: >> >> ```The FEC schemes described in this document use other packets to >> recover when a packet is lost or damaged but do not allow for recovery >> of a damaged packet on its own. This is consistent with the default >> processing for using FEC with SRTP described in RFC 3711, which is to >> perform FEC followed by SRTP at the sender, and SRTP followed by FEC >> at the receiver, which implies that damaged packets will be rejected >> by the SRTP integrity check and discarded.``` >> > > I rewrote this in the most recent commit, > https://github.com/juberti/draughts/commit/6e991d1eeaf1e505bb89957319be38df4ada56f5. > LMK if you think that still needs to be clarified. > LGTM -Ekr --00000000000036533c05828edfd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 22, 2019 at 4:18 PM Justi= n Uberti <juberti@google.com&g= t; wrote:
Thanks for your comments, see below:
=
On Sun= , Feb 17, 2019 at 7:06 AM Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the following ba= llot position for
draft-ietf-rtcweb-fec-08: 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/s= tatement/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-r= tcweb-fec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3278


COMMENTS
S 5.2.
>=C2=A0 =C2=A0 =C2=A0 as described in [RFC5956], Section 4.1 is not curr= ently defined for
>=C2=A0 =C2=A0 =C2=A0 WebRTC, and SHOULD NOT be offered.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Answerers SHOULD reject any FEC-only m-lines, unle= ss they
>=C2=A0 =C2=A0 =C2=A0 specifically know how to handle such a thing in a = WebRTC context
>=C2=A0 =C2=A0 =C2=A0 (perhaps defined by a future version of the WebRTC= specifications).

It seems like the above three paragraphs are generic to this document,
and just grouped with video because the audio codecs tend to have
internal FEC? If so, maybe put them elasewhere?

As noted elsewhere in the document, the recommendation is to only = use flexfec with video. These paras could be put elsewhere, e.g., in a &quo= t;negotiating flexfec" section, and then 5.2 could point to said secti= on, but it's not clear this would enhance readability.=C2=A0

OK. I'm not going to push= on this point.




S 9.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 As described in [RFC3711], Section 10, the default= processing when
>=C2=A0 =C2=A0 =C2=A0 using FEC with SRTP is to perform FEC followed by = SRTP at the sender,
>=C2=A0 =C2=A0 =C2=A0 and SRTP followed by FEC at the receiver.=C2=A0 Th= is ordering is used for
>=C2=A0 =C2=A0 =C2=A0 all the SRTP Protection Profiles used in DTLS-SRTP= [RFC5763], as
>=C2=A0 =C2=A0 =C2=A0 described in [RFC5764], Section 4.1.2.

I of course agree with this text, but I wonder if it's maximally
clear. Perhaps rewrite the
first sentence as:

```The FEC schemes described in this document use other packets to
recover when a packet is lost or damaged but do not allow for recovery
of a damaged packet on its own. This is consistent with the default
processing for using FEC with SRTP described in RFC 3711, which is to
perform FEC followed by SRTP at the sender, and SRTP followed by FEC
at the receiver, which implies that damaged packets will be rejected
by the SRTP integrity check and discarded.```

I rewrote this in the most recent commit,=C2=A0https://github.com/juberti/draughts/commit/6e991d1eeaf1e5= 05bb89957319be38df4ada56f5. LMK if you think that still needs to be cla= rified.

LGTM
<= div>
-Ekr

--00000000000036533c05828edfd4-- From nobody Sun Feb 24 16:25:47 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2532F130DE9; Sun, 24 Feb 2019 16:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu 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 0qGtj3rOhueN; Sun, 24 Feb 2019 16:25:36 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760098.outbound.protection.outlook.com [40.107.76.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED582130DC2; Sun, 24 Feb 2019 16:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jt+RixW57HoFLVHzsH2egxRtzbBu7enlpKgcBF4NQVg=; b=Tkg8vLRcG/80sw2XUrHK97h1Hp6VkaoQyGv1gRqWRjpbwSs+fMXKtnt1vAJ7BfdZ4BvIh6a4ij4PnY92h1E4j9wqjFK3A2zAU/ABiNeX0HRMPUPE2NVCYFJKuIufIfQzwfthKnH2WJP7WaQJWohQmlatQRU7eJILTdyVaVjWdeI= Received: from SN6PR01CA0029.prod.exchangelabs.com (2603:10b6:805:b6::42) by BN8PR01MB5601.prod.exchangelabs.com (2603:10b6:408:be::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 00:25:33 +0000 Received: from CO1NAM03FT017.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::202) by SN6PR01CA0029.outlook.office365.com (2603:10b6:805:b6::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Mon, 25 Feb 2019 00:25:33 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT017.mail.protection.outlook.com (10.152.80.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 25 Feb 2019 00:25:32 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1P0PS1j031223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Feb 2019 19:25:30 -0500 Date: Sun, 24 Feb 2019 18:25:28 -0600 From: Benjamin Kaduk To: Justin Uberti CC: Mirja =?iso-8859-1?Q?K=FChlewind?= , RTCWeb IETF , The IESG , , Message-ID: <20190225002528.GD78133@kduck.mit.edu> References: <155058071936.20784.14656321188511454784.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(39860400002)(346002)(2980300002)(199004)(189003)(76176011)(426003)(126002)(2870700001)(5660300002)(1076003)(88552002)(8936002)(86362001)(956004)(476003)(356004)(7696005)(75432002)(11346002)(446003)(186003)(6246003)(53416004)(336012)(246002)(786003)(54906003)(26005)(106466001)(47776003)(305945005)(36906005)(58126008)(106002)(316002)(33656002)(478600001)(53546011)(2906002)(486006)(966005)(66574012)(104016004)(224303003)(229853002)(23756003)(55016002)(6306002)(50466002)(26826003)(4326008)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN8PR01MB5601; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d7ab095b-b0b9-4271-ab0d-08d69ab7c11d X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:BN8PR01MB5601; X-MS-TrafficTypeDiagnostic: BN8PR01MB5601: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; BN8PR01MB5601; 20:7Y8A5nxQ3wyv6HPA2PWi/6atWC6QyvBsxJIIUvUXG2ICOqxTZJ75RuP2PzRjDWWeF9N8hpEwT/7RkO+lhwOZxujzza4UpcMvFXeGIe3c4dq7sFXsX6lmE6nxw59Hj0V3wrv5436rXkD54xHmzvn99cu+ajgoi2PWgfcDzi1D7ffSzhXzUytmn/5NYKVfWv60asNsRgR4NVjEgrNTRwrdLTAJntkBFUwINeTMRAyJ6LuwcVoNiMBOpPrIJZRu3/CMo0m2CNzD33kNVsoz4ujENidp1a77UMNtFvVHGX7GDJ5JyIDYmHjhJA9ai2kzG0yixgOqjbCcUrIFvxlhunjQrbkRBeG6hRBUyH8ddzpH8kFaB6SsQ6zKnIRXaACeBGwtNGimATiuGYvde6MeaynuGv6FsJRa2SF8HIxnpeVgBfwTgi8OOacywmQa4tdu0V2mNBCeGspXliPPTOYNiGSxOjcExrSs5NiQqAnvu1nseXDq+GtP7H4f6AiTzTV7CR63iXffVfjQiPC5HnDknSlNcDS3XMXkAXtbZyLn1zJc5BAyLSyD85sj9FnjxW7gnRodTSXfuwLOrOx5MHJ2ln0+QFpDWgjvl9RoN2gmBFe32Ss= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 095972DF2F X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; BN8PR01MB5601; 23:d7sLUK6MX+MNYfErOWPJKvPjoTlfDx/TZ7oJ/IV?= =?iso-8859-1?Q?9VV797cOUTtXrFWcRG2HnKEfyikqSRtH8tVFWzix3pgTSbX97Elhn74Nyj?= =?iso-8859-1?Q?FZS/eCxXO0yvA38DOj85B8kh+y3Uag0tCBnG3PcJ04ANte/FvcCuVmN4z4?= =?iso-8859-1?Q?mX6jivRe2gaPdx1NOamYeWlWLa3My6sSixrIf23RxVNw1+E3k5bW3q9Z9h?= =?iso-8859-1?Q?WlK94Ns6T51PdbpBOZ25u0SSCqQ1nEf/PCijYlfmdwlAgqLgTwSnUPFXHi?= =?iso-8859-1?Q?foEmRp99ZfGpWworKoXkp0CK/EE4wDyvjRG1lIRQFGhzkZrgN5ryUOMqQC?= =?iso-8859-1?Q?Jwl8CjG8x+UIu9ESaTrXV7kwRX1glpF77gS1NQ72Jxk1XPxXMn2S6nchlG?= =?iso-8859-1?Q?H9kV83WmtJWL671o2pvMdgeGQV/SA3aYzp8NaADWRJthsygratPwLzN/qT?= =?iso-8859-1?Q?SzVwzZtA+CdZjjd8i/KNDCvOHYkrNqAoR9Q/L/J01SZBhPc58018gqoWWr?= =?iso-8859-1?Q?nPU0gdZozPbQ+1r4AohySPbLp9F6uHFfDpiuF183Uh2tC4hzFkfxuZDSmc?= =?iso-8859-1?Q?CUuc1xBRR9A1mse4uyqJ/ZDbVmAf/UOeH2EFDq5UI1D68jCQS9+f6Hvh/6?= =?iso-8859-1?Q?64rzJ/8hzoKpwfsEJNjXVU59wDMko+Uw5gU79mEZbOuicXJ6jL7YBoStTh?= =?iso-8859-1?Q?SLdt7Lp4YmPHNhehnTkWi9AlQ6Q5bKatxkKoew9qz2zE7uGjaaTyOnOc1O?= =?iso-8859-1?Q?YD56hVy8Uy8Rz/EFH0z1V1JciPvEJnjxDYXQP6yLiI57PfB4Wj/3nO4p/e?= =?iso-8859-1?Q?YC3iArWMe2eo4wkcqCVLXTkbU/wxpbyNpFLSgu7Ewys3vwfFP9VI8Xew7Z?= =?iso-8859-1?Q?OfafL3ZSn98qciPcqUQNnz9vGrJZIa1Na7AHdO3RTiUL+eEL3UqJ9ozGQ+?= =?iso-8859-1?Q?ugwv0bESGPisiZayfzrXG16/zRJ/TeCyATqWdcszferbHekvS6/vuusRuS?= =?iso-8859-1?Q?S7vDanMNLOqDozpcRKKjD928zrQLg7cuyE4QO7CzweCu36ikhka3rTCqRF?= =?iso-8859-1?Q?4WFGujdvH/pll/M7mCp9Z88v0j6p7LUr4qAQ+i2pwYaJZngT7W+t/dXA+9?= =?iso-8859-1?Q?xFzXjDwqsgE9U1e+vWa6gDLSOxscI2QBG1iJGHMmbZRfvUfrPCduxMEa90?= =?iso-8859-1?Q?QShVpyWCLz4HR9A+KtNF89ZOMIonMxVqN3NKSWVX1WtViPqnT3Om4w0NwR?= =?iso-8859-1?Q?vXZTBWsDsDv6WzvPjhvZ2BuqxbOvtftMnZwajgw=3D=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: t2gC0xH5f6DXzY2QdmfIi1gfQ/hxwkYWtgLyevCQTKI4BNIyJuf89uTy8PSTcccjl39wpMYjXY8suaaOmFwZQ5Onz7KpOqWf9uovj/oLJ/0TsyWatynnkk1agKRTBRrVdPfVM+Z5RD6yvcGO0yegmwuY346ijLyx181u7+6TFYKg5xtR2AK9m7Rw08mXH066LaJnHyHiA9O5UCzIwLfIjZSk2G90mOhDCZzGgdTJFxPpmR1HVwD6zNNvANgxvDB1erVSmL5BTxPsKIswdArw9Uoi78+W0E40VUMparsW6NtJQhFBXY1VUMjNLlkpdozp8uKG1o8WUIhZBA4vBrI8npVjtVcoMJVZ0CQbR+3dkEUaTuS4FKTue9ztQNYqqYvQg0Tf4CXg02MPoHmtoTMknkYjMdltf0JmiCXEzSnSoD4= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2019 00:25:32.5007 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d7ab095b-b0b9-4271-ab0d-08d69ab7c11d X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR01MB5601 Archived-At: Subject: Re: [rtcweb] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dr?= =?iso-8859-1?q?aft-ietf-rtcweb-fec-08=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 00:25:38 -0000 On Fri, Feb 22, 2019 at 04:53:21PM -0800, Justin Uberti wrote: > Thanks for your comments. See below. > > On Tue, Feb 19, 2019 at 4:52 AM Mirja Khlewind wrote: > > > Mirja Khlewind has entered the following ballot position for > > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I'm not fully sure about the intended status of this document. The shepherd > > write-up says "the document has normative requirements for conforming > > WebRTC > > implementations", however, for me it seems this document makes "only" > > recommendations and has actually no normative requirements. Therefore > > informational status might be more appropriate, however, I will not block > > publication as PS. > > > > One mostly minor editorial note: > > > > Sec 3.3: "experiments performed indicate that when Opus FEC is used, the > > overhead imposed > > is about 20-30%, depending on the amount of protection needed." > > Would it be possible to provide a reference for this number? > > > > I believe this came from a WG mailing list post (possibly my own), rather > than an external document that could be linked to. Suggestions? Informative references to mailarchive.ietf.org URLs are acceptable. > > > > Also this section says: "See [RFC6716], Section 2.1.7 for complete > > details." > > However, section 2.1.7 in RFC6716 is very short and actually does not > > provide > > any details... > > > > Unfortunately, that was the best RFC reference I could find. Perhaps it is unwise to refer to it as providing "complete" details, at least. -Benjamin From nobody Sun Feb 24 17:32:51 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4E0130EB0; Sun, 24 Feb 2019 17:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 RHngWYePdObm; Sun, 24 Feb 2019 17:32:46 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800109.outbound.protection.outlook.com [40.107.80.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C324A130EAE; Sun, 24 Feb 2019 17:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TrtZzWiT6/fkVgZg8lf9Zx54dQBskrwLlsGXZW4XBm0=; b=s+f9TzgqYVigfm0bWyzguwyiadqo5gC7coc1zBlMAyz7OgQkYBbpXdDbac2IVIebDiam+0XFUqk8ljVm5AFWxGtv2CP05LhDH1nXxJ5sbaCdGTDVy2ETBqbOJjoqH3Dhf8D5Tdk8flerjmCCLvHY9dwos0aSnEfGgTjs4MbSwQs= Received: from BYAPR01CA0058.prod.exchangelabs.com (2603:10b6:a03:94::35) by SN6PR01MB3998.prod.exchangelabs.com (2603:10b6:805:27::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.14; Mon, 25 Feb 2019 01:32:43 +0000 Received: from BY2NAM03FT063.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::204) by BYAPR01CA0058.outlook.office365.com (2603:10b6:a03:94::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.21 via Frontend Transport; Mon, 25 Feb 2019 01:32:43 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT063.mail.protection.outlook.com (10.152.85.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 25 Feb 2019 01:32:43 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1P1WdYd015650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Feb 2019 20:32:41 -0500 Date: Sun, 24 Feb 2019 19:32:39 -0600 From: Benjamin Kaduk To: Justin Uberti CC: The IESG , RTCWeb IETF , , Message-ID: <20190225013238.GE78133@kduck.mit.edu> References: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(136003)(346002)(376002)(2980300002)(189003)(199004)(51914003)(246002)(5660300002)(46406003)(8676002)(54906003)(106466001)(76176011)(7696005)(11346002)(33656002)(956004)(1076003)(2906002)(106002)(126002)(486006)(356004)(14444005)(53416004)(476003)(97756001)(305945005)(88552002)(6246003)(4326008)(104016004)(53546011)(23726003)(426003)(446003)(336012)(186003)(26005)(50466002)(8936002)(26826003)(478600001)(75432002)(966005)(229853002)(47776003)(316002)(786003)(36906005)(86362001)(55016002)(6916009)(58126008)(6306002)(16586007)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB3998; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 275cf920-11f3-4527-8f3a-08d69ac12385 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:SN6PR01MB3998; X-MS-TrafficTypeDiagnostic: SN6PR01MB3998: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB3998; 20:QB48f6DxZNsrE1iRB/Td9Q6igf05q+BV90IhcEpCNe2kIxZIe6ShtPGlKE++LWF9diCi+UKPVScZx7Vsem1XvTX5Le+dL67NG3355R0oMI4GsOZqdiIpp0C9JuAW4WWpgwaNqsLXnUn9Hkb9XzNoNZIegPBkzyag8E9rfwnl884GKKPRcgDvc3EDM8hCKf4qWchux5Kr5n4OhVpN/Of0UytsIOjBJpM+VLwX0uuMHxLJKkgoPiF7mfmSa0efCat0sIlHa4/b0P4Uu8Ps12l1A2CWmLvisObQQ4vWH7x/GklDAFLcw/B9KPTNgV8Z4DJjO4xsC5v2sYbRb3PSVpyzZHF9Bz58Py1hBcaxpA2TUnPVc/y5jGTeHehwpbuO7pekD3OVDp/LW2ioOeIVfsJmfGZstyApjxniGblNbbwL15VVpcVMasbfPXyWcDWEGtqdeSziMcmswZjMVPB9NHxtervEwrhsAOuvc0MNbWPLPjDSo90hZeYcCuOSGJFNvt0EnS+5YcFVP5cTUOpZJWBDSFjduw9LGwXpav3gr8LZTh1jMPeko9ZFU5u8/TW3HPS/rsx1qFbmTfMDc1wrspMzpLCgVlMdkod3vT80K3c8yck= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 095972DF2F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB3998; 23:f7+4fzQhh6Ywelfq2gp1Z6pmUr5BvrWjapkHWnEsR?= =?us-ascii?Q?hQJjWo9Gcr6hIW2Ne0wWQph0hB5mD8H5iG/RsJLQBdazVUEzmpBQBEUzj8h3?= =?us-ascii?Q?+CXJIwlN4xFRmhnScuW0BVW2ff4AZIEjcab0U9M8kICo9JGf2vTZNPCRdZxi?= =?us-ascii?Q?TNHNNmfanB/f+Iwoty21IA29ut+dIK6VjMu9kM1srdCc/j0oExq0A3pkQk9Y?= =?us-ascii?Q?YXousePORgLAbZyTAXEVqYUK5Ii0QVwEIfKOQqBUnYoRW319p7fCAFnvPwh7?= =?us-ascii?Q?nDayBuL/AJL9/AZi96FaE7bO5pomUiuJIF+25WNX8KabZOV3lcqftPuG3b4t?= =?us-ascii?Q?UpIEElwxKPtW+lm1P/L0WXifbGRDO0w+gVfnXlPaA1GnI2JIpwP4WwZOvW7x?= =?us-ascii?Q?rLmo+AufVDmBi8bPygczCaUVxJmMAGQIleVls8Vf+auOabEql17zUHSyxvV1?= =?us-ascii?Q?YkFyJ4cpKbhQW0y5sbFYWgKlMVrsPG5GPh73l1Ugz+jGZTQpxbhlDdFauaoU?= =?us-ascii?Q?Budp16kdA9Vl9BTfZlOVg5ONVHMN11W0lqiodyJhgYy9YBBC4EcQ/kGKReuM?= =?us-ascii?Q?QNFJ/okIYVjqeVfqVbe5+9NVoT0bVHNOvZfHM0oHWjbDbdA1BDpGgNVWDFv4?= =?us-ascii?Q?HBNq+R3OH7C3kmlsJeOqNSNxrYjvW/NB335+qa8KxtVKmY8tEFfW/LGMIH91?= =?us-ascii?Q?ry8Y7nxQmr/UAlqE1ERg44ioPvoVpPhEf7IQyK6H7MPGW8W5mVnmBoW3Mll7?= =?us-ascii?Q?Jna+7BAA6x4kwNG6yYQcaJN4URLwEiAEHmXWVyXVhukfP9EnBvDY3L0nozc2?= =?us-ascii?Q?T55tqNFK86hHuEyxK6ScHd58Jk7vU6b5OHHkTzyWWyj3RJo0eCQPB7XGcmPp?= =?us-ascii?Q?dmuj/KuVXAeZiMc+78GqQOW1MH6ZD+/pwzXfvhRODE8icPi5M9udgJDGBREm?= =?us-ascii?Q?EsncAjrE8Ttu2gbDb3FZ9ZJJSmSEUD7woizheXVUb9HHUkx/HeY5fgtgUJhX?= =?us-ascii?Q?F9z4ZuCK60SH/FCDGLwhNUcon8U9uWPTD7AoPfyTxWLAjsYrajkD2oBSuWnR?= =?us-ascii?Q?0NFJKFFJvne4WD+5TVPMwsl7SZxinhMtFwdDvmeHIKqtf4G0uWYiyQRUCrfH?= =?us-ascii?Q?illyxAAoIjgSY1FeTJkBaUqPPvEhWEO80jKX4inPL2HZl6dmIyi+lTXRXAq6?= =?us-ascii?Q?jqn5WHGBr2ZNYtWDt6b0oDl3njYA9IHIohLFiOpfTeMVWvll1yyBhDcaeLD9?= =?us-ascii?Q?D+XC/IHfwXDQALpA5yEVzVqYFROI5dORzgxEaT8FnmP+GuomET9zbXFlY0jd?= =?us-ascii?Q?UHpfnCPtw+pfEgsczvD2pg=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: DE6NpB++//XtY+mktI6tOIJdnJHN5eWOEcQ/ebs9RJHGeEVqC9hCtfJpONjS9e+ai+zKQuCi/IZgaqMaeW7SvJVePJpcXS8bDUChEkY1DpGC3T3VBO6nqYbFJd3HJjlj7s1NGsaodYOruE2PI39kla5gZdVir7outZP/nvXVOGhn38C3nab0nWPf7Z9wP0ysZKE3xvLb0+6wHUpqOehzWh5TS1dTT9BTSVci51uQ0qa5GJu5ScX6G53CGbBeMoLG1EpHVVECVd6/jP29wtFKs12LTrXnq9YvyTB7c9WFuMZqPpE3G+SW828yVjeLefdFQN9/rhrV7QUop1UZxfEmT676Hsxdfyh4qoegf8y8vCL4c5IGSP7UwglkHJcCnzN7sQjpXFdB8QSdntwF7uZqltVpAMpQySi424B68ucI2m0= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2019 01:32:43.0931 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 275cf920-11f3-4527-8f3a-08d69ac12385 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB3998 Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 01:32:49 -0000 On Fri, Feb 22, 2019 at 05:10:35PM -0800, Justin Uberti wrote: > Thanks for your comments. See below. > > On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 3 > > > > nit: The subsequent discussion seems to indicate that at least some of > > these mechanisms are already specified and not new in this document; (if > > so) it would be nice to have the exposition reflect that. > > > > Section 3.3 > > > > For Opus, packets deemed as important are re-encoded at a lower > > bitrate and added to the subsequent packet, allowing partial recovery > > > > Is "added" supposed to be something other than "appended" (which strongly > > resembles the "redundant encoding" of the previous section)? > > > > It's similar to the redundant encoding, but done within the Opus bitstream, > rather than at the RTP level. > > > > > Section 4.1 > > > > Does it make sense to give subsection backreferences when talking about > > (e.g.) redundant encoding? > > > > Yes, this could be done easily. > > > > > Section 5.2 > > > > Support for a SSRC-multiplexed flexfec stream to protect a given RTP > > stream SHOULD be indicated by including one of the formats described > > in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an > > > > nit: Since this Section 5 is solely for video, is it more appropriate to > > refer to Section 5.1.2 ("Registration of video/flexfec") of > > draft-ietf-payload-flexible-fec-scheme? > > > > Agreed - earlier versions of flexfec were slightly different. > > > > > Section 7 > > > > To support the functionality recommended above, implementations MUST > > be able to receive and make use of the relevant FEC formats for their > > supported audio codecs, and MUST indicate this support, as described > > in Section 4. Use of these formats when sending, as mentioned above, > > is RECOMMENDED. > > > > Just to double-check: this is explicitly only mandating FEC for audio and > > ignoring video entirely? > > > > This para only applies to audio. The following para discusses video, but is > SHOULD-strength given the relative newness of flexfec. > > > > > Section 8 > > > > Because use of FEC always causes redundant data to be transmitted, > > and the total amount of data must remain within any bandwidth limits > > indicated by congestion control and the receiver, this will lead to > > less bandwidth available for the primary encoding, even when the > > redundant data is not being used. This is in contrast to methods > > like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] > > retransmissions, which only transmit redundant data when necessary, > > at the cost of an extra roundtrip. > > > > This seems to imply that "FEC" is a specific usage and that flexfec is not > > a subset of generic FEC. If so, this could probably be reworded to be > > less confusing to the reader (though my suspicion is that the "always > > causes redundant data to be transmitted" is only intended to apply to > > specific mechanisms from Section 3). > > > > flexfec is not quite a subset of generic FEC, since it also has a > retransmission format. Thoughts on how this could be reworded? I think it would need to be "Because use of FEC in the form of always causes [...]", but I'm not entirely sure what is. Is it just "this document" or is there a broader framework or structure to which this document adheres? > > > > Section 9 > > > > This document seems to be agnostic on the question of RTP vs. SRTP; I would > > consider referencing their respective security considerations as well as > > what is already covered here. > > > > As described in [RFC3711], Section 10, the default processing when > > using FEC with SRTP is to perform FEC followed by SRTP at the sender, > > and SRTP followed by FEC at the receiver. This ordering is used for > > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as > > described in [RFC5764], Section 4.1.2. > > > > I was going to comment about the lack of clarity here, but I see that Ekr > > has already gotten the core points, and that the secdir review has already > > resulted in some chanegs in the editor's copy. It would be nice to have > > the result of the (merged) edits available to look at, though. > > > > Here's the latest text. Let me know if this needs to be further clarified. > > In the WebRTC context, FEC is specifically concerned with recovering > data from lost packets; any corrupted packets will be discarded by the > SRTP decryption process. Therefore, as described > in , Section 10, the default processing when > using FEC with SRTP is to perform FEC followed by SRTP at the sender, and > SRTP followed by FEC at the receiver. This ordering is used for all the > SRTP Protection Profiles used in DTLS-SRTP > , which are enumerated in > , Section 4.1.2. This is a lot better; the only thing that I might wonder about is whether the "this ordering is used for all the SRTP protection profiles used in DTLS-SRTP" is a new requirement imposed by this document or if that's supposed to be something that is stated in one of the references. Thanks for the updates and confirmations of my understanding, Benjamin From nobody Sun Feb 24 18:16:26 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92669128701; Sun, 24 Feb 2019 18:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6jjne5olijDV; Sun, 24 Feb 2019 18:16:21 -0800 (PST) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (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 CC70E1200D8; Sun, 24 Feb 2019 18:16:20 -0800 (PST) Received: by mail-lj1-f174.google.com with SMTP id d24so5729136ljc.12; Sun, 24 Feb 2019 18:16:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YIKCU6aqFxuLSf9vXprC4m6A0ww4HLM/VGGlUYjfYTo=; b=cTPtQdkIvsfS+BJAUzRSvcpZvaU8IorpjQt/jFdOgvYtg7hDGH9e7E4qFrZ6IJD7C+ NP8olXefe5Q9EkNV7a1DO/fFjLjZxJCc7jlDOvJi/GgM2iYKjS9WLj45HeN8ycfr04ZL BtuGYdjCgBo6CylpJwU96uvHmBaQ+9+Um0g/HM/n5tz+eoKD8RcwZDpdnJUlM4FT0Hli J0gqejEoX4pFMa7RCo9mA87HXiEWIhfpLtHblphi04gD/xig1i6URcKR73Rf3hVkssjb XM31PLkVIEVLpn/2j99/Nf2f+b12T0/zb1p5Q+ADNKyqgc/UKPJyfp38kHYSNdxyYu3K Zw5g== X-Gm-Message-State: AHQUAuaEsXoTkvdWiFsC1PWevFpy/9MidXJl/MprngUR6AaHs5L6hKwJ 8+PX4P/S8UhOVLD6kR61fkr4NcTjCJ0i5fFGqb8= X-Google-Smtp-Source: AHgI3IZ6K1sEoY8noxDAGgieCfQABtFDy2upSS+E+UoigWTAorXSY1Jihn0dQwTnfKJrYfAi9L4thdZotG9JRbZLRxM= X-Received: by 2002:a2e:9916:: with SMTP id v22mr8148414lji.68.1551060978519; Sun, 24 Feb 2019 18:16:18 -0800 (PST) MIME-Version: 1.0 References: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> <20190225013238.GE78133@kduck.mit.edu> In-Reply-To: <20190225013238.GE78133@kduck.mit.edu> From: Justin Uberti Date: Sun, 24 Feb 2019 18:16:06 -0800 Message-ID: To: Benjamin Kaduk Cc: Justin Uberti , The IESG , RTCWeb IETF , rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org Content-Type: multipart/alternative; boundary="000000000000a65f4e0582ae8603" Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 02:16:24 -0000 --000000000000a65f4e0582ae8603 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 24, 2019 at 5:32 PM Benjamin Kaduk wrote: > On Fri, Feb 22, 2019 at 05:10:35PM -0800, Justin Uberti wrote: > > Thanks for your comments. See below. > > > > On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk wrote: > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Section 3 > > > > > > nit: The subsequent discussion seems to indicate that at least some of > > > these mechanisms are already specified and not new in this document; > (if > > > so) it would be nice to have the exposition reflect that. > > > > > > Section 3.3 > > > > > > For Opus, packets deemed as important are re-encoded at a lower > > > bitrate and added to the subsequent packet, allowing partial > recovery > > > > > > Is "added" supposed to be something other than "appended" (which > strongly > > > resembles the "redundant encoding" of the previous section)? > > > > > > > It's similar to the redundant encoding, but done within the Opus > bitstream, > > rather than at the RTP level. > > > > > > > > Section 4.1 > > > > > > Does it make sense to give subsection backreferences when talking about > > > (e.g.) redundant encoding? > > > > > > > Yes, this could be done easily. > > > > > > > > Section 5.2 > > > > > > Support for a SSRC-multiplexed flexfec stream to protect a given RTP > > > stream SHOULD be indicated by including one of the formats described > > > in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an > > > > > > nit: Since this Section 5 is solely for video, is it more appropriate > to > > > refer to Section 5.1.2 ("Registration of video/flexfec") of > > > draft-ietf-payload-flexible-fec-scheme? > > > > > > > Agreed - earlier versions of flexfec were slightly different. > > > > > > > > Section 7 > > > > > > To support the functionality recommended above, implementations MUST > > > be able to receive and make use of the relevant FEC formats for > their > > > supported audio codecs, and MUST indicate this support, as described > > > in Section 4. Use of these formats when sending, as mentioned > above, > > > is RECOMMENDED. > > > > > > Just to double-check: this is explicitly only mandating FEC for audio > and > > > ignoring video entirely? > > > > > > > This para only applies to audio. The following para discusses video, but > is > > SHOULD-strength given the relative newness of flexfec. > > > > > > > > Section 8 > > > > > > Because use of FEC always causes redundant data to be transmitted, > > > and the total amount of data must remain within any bandwidth limits > > > indicated by congestion control and the receiver, this will lead to > > > less bandwidth available for the primary encoding, even when the > > > redundant data is not being used. This is in contrast to methods > > > like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] > > > retransmissions, which only transmit redundant data when necessary, > > > at the cost of an extra roundtrip. > > > > > > This seems to imply that "FEC" is a specific usage and that flexfec is > not > > > a subset of generic FEC. If so, this could probably be reworded to be > > > less confusing to the reader (though my suspicion is that the "always > > > causes redundant data to be transmitted" is only intended to apply to > > > specific mechanisms from Section 3). > > > > > > > flexfec is not quite a subset of generic FEC, since it also has a > > retransmission format. Thoughts on how this could be reworded? > > I think it would need to be "Because use of FEC in the form of > always causes [...]", but I'm not entirely sure what is. Is it > just "this document" or is there a broader framework or structure to which > this document adheres? > This document incorporates multiple FEC schemes, so there isn't another overarching document (to my knowledge) that captures all of the mechanisms. The intent here was to say "Because FEC, in general, always causes...", but open to other phrasings. > > > > > > Section 9 > > > > > > This document seems to be agnostic on the question of RTP vs. SRTP; I > would > > > consider referencing their respective security considerations as well > as > > > what is already covered here. > > > > > > As described in [RFC3711], Section 10, the default processing when > > > using FEC with SRTP is to perform FEC followed by SRTP at the > sender, > > > and SRTP followed by FEC at the receiver. This ordering is used for > > > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as > > > described in [RFC5764], Section 4.1.2. > > > > > > I was going to comment about the lack of clarity here, but I see that > Ekr > > > has already gotten the core points, and that the secdir review has > already > > > resulted in some chanegs in the editor's copy. It would be nice to > have > > > the result of the (merged) edits available to look at, though. > > > > > > Here's the latest text. Let me know if this needs to be further > clarified. > > > > In the WebRTC context, FEC is specifically concerned with > recovering > > data from lost packets; any corrupted packets will be discarded by > the > > SRTP decryption process. Therefore, as > described > > in , Section 10, the default processing > when > > using FEC with SRTP is to perform FEC followed by SRTP at the > sender, and > > SRTP followed by FEC at the receiver. This ordering is used for > all the > > SRTP Protection Profiles used in DTLS-SRTP > > , which are enumerated in > > , Section 4.1.2. > > This is a lot better; the only thing that I might wonder about is whether > the "this ordering is used for all the SRTP protection profiles used in > DTLS-SRTP" is a new requirement imposed by this document or if that's > supposed to be something that is stated in one of the references. > It's really just a reiteration of an existing point from RFC 3711 to head off common questions about the interaction of FEC and encryption. > > Thanks for the updates and confirmations of my understanding, > > Benjamin > --000000000000a65f4e0582ae8603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 24, 2019 at 5:32 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Fri, Feb 22, 2019 at 05:10:35PM -0800, Justin Uberti= wrote:
> Thanks for your comments. See below.
>
> On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-rtcweb-fec-08: 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 cu= t 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 her= e:
> > https://datatracker.ietf.org/doc/dr= aft-ietf-rtcweb-fec/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > Section 3
> >
> > nit: The subsequent discussion seems to indicate that at least so= me of
> > these mechanisms are already specified and not new in this docume= nt; (if
> > so) it would be nice to have the exposition reflect that.
> >
> > Section 3.3
> >
> >=C2=A0 =C2=A0 For Opus, packets deemed as important are re-encoded= at a lower
> >=C2=A0 =C2=A0 bitrate and added to the subsequent packet, allowing= partial recovery
> >
> > Is "added" supposed to be something other than "ap= pended" (which strongly
> > resembles the "redundant encoding" of the previous sect= ion)?
> >
>
> It's similar to the redundant encoding, but done within the Opus b= itstream,
> rather than at the RTP level.
>
> >
> > Section 4.1
> >
> > Does it make sense to give subsection backreferences when talking= about
> > (e.g.) redundant encoding?
> >
>
> Yes, this could be done easily.
>
> >
> > Section 5.2
> >
> >=C2=A0 =C2=A0 Support for a SSRC-multiplexed flexfec stream to pro= tect a given RTP
> >=C2=A0 =C2=A0 stream SHOULD be indicated by including one of the f= ormats described
> >=C2=A0 =C2=A0 in [I-D.ietf-payload-flexible-fec-scheme], Section 5= .1, as an
> >
> > nit: Since this Section 5 is solely for video, is it more appropr= iate to
> > refer to Section 5.1.2 ("Registration of video/flexfec"= ) of
> > draft-ietf-payload-flexible-fec-scheme?
> >
>
> Agreed - earlier versions of flexfec were slightly different.
>
> >
> > Section 7
> >
> >=C2=A0 =C2=A0 To support the functionality recommended above, impl= ementations MUST
> >=C2=A0 =C2=A0 be able to receive and make use of the relevant FEC = formats for their
> >=C2=A0 =C2=A0 supported audio codecs, and MUST indicate this suppo= rt, as described
> >=C2=A0 =C2=A0 in Section 4.=C2=A0 Use of these formats when sendin= g, as mentioned above,
> >=C2=A0 =C2=A0 is RECOMMENDED.
> >
> > Just to double-check: this is explicitly only mandating FEC for a= udio and
> > ignoring video entirely?
> >
>
> This para only applies to audio. The following para discusses video, b= ut is
> SHOULD-strength given the relative newness of flexfec.
>
> >
> > Section 8
> >
> >=C2=A0 =C2=A0 Because use of FEC always causes redundant data to b= e transmitted,
> >=C2=A0 =C2=A0 and the total amount of data must remain within any = bandwidth limits
> >=C2=A0 =C2=A0 indicated by congestion control and the receiver, th= is will lead to
> >=C2=A0 =C2=A0 less bandwidth available for the primary encoding, e= ven when the
> >=C2=A0 =C2=A0 redundant data is not being used.=C2=A0 This is in c= ontrast to methods
> >=C2=A0 =C2=A0 like RTX [RFC4588] or flexfec [I-D.ietf-payload-flex= ible-fec-scheme]
> >=C2=A0 =C2=A0 retransmissions, which only transmit redundant data = when necessary,
> >=C2=A0 =C2=A0 at the cost of an extra roundtrip.
> >
> > This seems to imply that "FEC" is a specific usage and = that flexfec is not
> > a subset of generic FEC.=C2=A0 If so, this could probably be rewo= rded to be
> > less confusing to the reader (though my suspicion is that the &qu= ot;always
> > causes redundant data to be transmitted" is only intended to= apply to
> > specific mechanisms from Section 3).
> >
>
> flexfec is not quite a subset of generic FEC, since it also has a
> retransmission format. Thoughts on how this could be reworded?

I think it would need to be "Because use of FEC in the form of <som= ething>
always causes [...]", but I'm not entirely sure what <something= > is.=C2=A0 Is it
just "this document" or is there a broader framework or structure= to which
this document adheres?

This document in= corporates multiple FEC schemes, so there isn't another overarching doc= ument (to my knowledge) that captures all of the mechanisms.=C2=A0

The intent here was to say "Because FEC, in general, = always causes...", but open to other phrasings.


> >
> > Section 9
> >
> > This document seems to be agnostic on the question of RTP vs. SRT= P; I would
> > consider referencing their respective security considerations as = well as
> > what is already covered here.
> >
> >=C2=A0 =C2=A0 As described in [RFC3711], Section 10, the default p= rocessing when
> >=C2=A0 =C2=A0 using FEC with SRTP is to perform FEC followed by SR= TP at the sender,
> >=C2=A0 =C2=A0 and SRTP followed by FEC at the receiver.=C2=A0 This= ordering is used for
> >=C2=A0 =C2=A0 all the SRTP Protection Profiles used in DTLS-SRTP [= RFC5763], as
> >=C2=A0 =C2=A0 described in [RFC5764], Section 4.1.2.
> >
> > I was going to comment about the lack of clarity here, but I see = that Ekr
> > has already gotten the core points, and that the secdir review ha= s already
> > resulted in some chanegs in the editor's copy.=C2=A0 It would= be nice to have
> > the result of the (merged) edits available to look at, though. > >
> >=C2=A0 Here's the latest text. Let me know if this needs to be= further clarified.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the WebRTC context, FEC is specifically c= oncerned with recovering
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data from lost packets; any corrupted packet= s will be discarded by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTP <xref target=3D"RFC3711" /= > decryption process. Therefore, as described
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in <xref target=3D"RFC3711" /&g= t;, Section 10, the default processing when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using FEC with SRTP is to perform FEC follow= ed by SRTP at the sender, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTP followed by FEC at the receiver. This o= rdering is used for all the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTP Protection Profiles used in DTLS-SRTP >=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref target=3D"RFC5763" />,= which are enumerated in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref target=3D"RFC5764" />,= Section 4.1.2.

This is a lot better; the only thing that I might wonder about is whether the "this ordering is used for all the SRTP protection profiles used i= n
DTLS-SRTP" is a new requirement imposed by this document or if that= 9;s
supposed to be something that is stated in one of the references.

It's really just a reiteration of an existin= g point from RFC 3711 to head off common questions about the interaction of= FEC and encryption.

Thanks for the updates and confirmations of my understanding,

Benjamin
--000000000000a65f4e0582ae8603-- From nobody Sun Feb 24 18:37:29 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E854C129619; Sun, 24 Feb 2019 18:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 8LjuoEhgwveA; Sun, 24 Feb 2019 18:37:24 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on071b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe46::71b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E333E130EA1; Sun, 24 Feb 2019 18:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NpbJsoZzlSEKEn/4mPIDSgXL+Ae3JGWYlArv9eMjzFQ=; b=RRTvN+osbX3b59aBG9vAcJVGZ4Q02GpTmtts+T6BVuWj4aPr+bLn+q4QxGRTus73k17Xdn8rAnatEL3UIdlG3ELngrQk9CBn2IJa6iY/sNe1PpJhMa82RXnVI3Iww8UResUnmWH5dxJdw3+DNvOCHQXpLsuVG+s+g+Jhp1cshQo= Received: from MWHPR01CA0034.prod.exchangelabs.com (2603:10b6:300:101::20) by MWHPR01MB3295.prod.exchangelabs.com (2603:10b6:300:fd::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Mon, 25 Feb 2019 02:37:21 +0000 Received: from CO1NAM03FT046.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::202) by MWHPR01CA0034.outlook.office365.com (2603:10b6:300:101::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.15 via Frontend Transport; Mon, 25 Feb 2019 02:37:21 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT046.mail.protection.outlook.com (10.152.81.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 25 Feb 2019 02:37:20 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1P2bGNo032482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 Feb 2019 21:37:18 -0500 Date: Sun, 24 Feb 2019 20:37:16 -0600 From: Benjamin Kaduk To: Justin Uberti CC: Justin Uberti , The IESG , RTCWeb IETF , , Message-ID: <20190225023716.GG78133@kduck.mit.edu> References: <155044278522.4109.16405267305237327974.idtracker@ietfa.amsl.com> <20190225013238.GE78133@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(376002)(136003)(2980300002)(199004)(189003)(51914003)(4326008)(478600001)(97756001)(75432002)(6916009)(106002)(26826003)(6246003)(966005)(1076003)(50466002)(47776003)(14444005)(6306002)(33656002)(956004)(126002)(16586007)(86362001)(486006)(316002)(476003)(93886005)(786003)(55016002)(36906005)(446003)(336012)(54906003)(229853002)(426003)(23726003)(11346002)(104016004)(58126008)(46406003)(305945005)(246002)(26005)(5660300002)(106466001)(88552002)(8676002)(2906002)(186003)(356004)(8936002)(53416004)(53546011)(76176011)(7696005)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR01MB3295; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f81579d7-352f-44ee-0df4-08d69aca2ac2 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:MWHPR01MB3295; X-MS-TrafficTypeDiagnostic: MWHPR01MB3295: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Exchange-Diagnostics: 1; MWHPR01MB3295; 20:o1tL9S2ZuUrSjXY/GU3qlnJ7Y6CyNG8mV7fpsxqaJFiQCGTdgqsuzUcmqtb4ghINi2i4RIjrUK+HMchS1/ixUHh5BAIDBPrJ0YVkoitlbgYo7mmJ+zhpnolqJQ6UkYrtdJOUJxFWLW11l/Tweo5fz7524ouvXsVthhxxkSqIZ1yztrPVbCMuEDTdlEqXsUD7yXIjrbRwPNydlVBhRAO3mPM1i3uxD08CzeBuC+sKmcpdMRgOB0qcZFYZjwRkTGNeAIY02J2AcqYNlcnELDDnJd1mnGp1vUdyrReoF0qWvW26+nunqZDJh6jci5sct06OjFC4l5kAHuwk9jRnXPzeJX/4BY61OA6DQRYZH8GCLm7WbEE7QMHsYy/bnlc0XoK963YVhFtpmeIKK4jQB+8u1bgqczCn8ki2CLdxQamfL3iQVxu+GZzdTni568jW8tCxuWZYdQnZwIpT+VBUEN9X7Dw7QD7PKC4HopNi5HoAexquYcCl5xecCPr2nlAi3ZxRqrHPFgl4Wx433jq287E79LlwEMOwQe9SMKI8IQ1FQOpnFkbnllIxy0cXXRar3J6yASwo5fxru8oN9Bx2CnkgH9H/7IM5CnPDb8tK6fscixQ= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 095972DF2F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR01MB3295; 23:fikkKQ5RLB9oL8QskPUXazeoEk2dbCdVwDR7gSdHg?= =?us-ascii?Q?pfdvoH/1fkJDZzGK0I5CW0Th0nQ8QIiDuwV2pmuueiq5mkjpWSJf2CHagHJ/?= =?us-ascii?Q?Uyd/UduvP/iDpqWzM0zF7zYHMTzam56i7n+m/VPfdrYsNezaqBThBvbDQcQW?= =?us-ascii?Q?mMrxMX3rV5fSyJMnXC3Bi+YbrSUsDwHFZOfkxIphSWk4idgJuuATfqtkeXAM?= =?us-ascii?Q?AfUjDlxl8CBwjnSyk224pylWbqjAV/UUxuDivL37fdg5n4Xp4jdVmUS1YUY3?= =?us-ascii?Q?akO2b2Ybsb8vYMu5SadCrUXSEwVoqma9y7LyamnWagTrYZR6QHxaxJH08hb6?= =?us-ascii?Q?bAnaYT7wyO4BjtN1Ek2K4+JgTL7lTeSCfTCjGwx2DXU3FqyaYcvPQVcPnVhW?= =?us-ascii?Q?8gFnTqBVKVx+i/IMJs2mRLbwp/hHQEoWg55JndBwgh9R8KAHQ+20dhVFgZP2?= =?us-ascii?Q?BUP6F9FYR6/KnCnE8w61CtUBmnTAqRwU+2onvG7lf+lu3apASU7IlgiBSMKS?= =?us-ascii?Q?rFQntZ2fbotV+BxWCFu9VnJUn9uHEZ8AGfaxmKEwx9F0u8ikGSioZbkL/aIr?= =?us-ascii?Q?ihWLMmild6u7F9k2RDwL6djWDTx3vzjDKXxdCqX6EVXRdHzgfQmV8maiv6hi?= =?us-ascii?Q?e93AK+c2xQ0AUPioqT5SmVFV40S1Ii7qdpbdAQPs5/u4R1cE5HAKICR8yNkN?= =?us-ascii?Q?fRNZBF2+MyD+3keQPr/bqWQ0y1W45vDwU4D28Uvvk5p8d7LXkCXYN6FK3850?= =?us-ascii?Q?m39Tyy6tj8hepa/HBufssbriuBQnhJa0uunHT5OZZFDtpj5kLT4xgPGSod6z?= =?us-ascii?Q?msw9Dj9ocWPajqcJW7AvSBV36miI7POwsx2HKUXFlgkx1DiDuY1HLlXAL7ry?= =?us-ascii?Q?9q6V4L6vooo+YKsfpqAKGeePxWBPC9dx17TEENJaNNdFieEuaITewXGZkevq?= =?us-ascii?Q?YmsihtK+PpR324TuewwXbT3FO4LaQQUd1p6GBIe3tHVvCLxBYCl7kaH9TYHB?= =?us-ascii?Q?ggrYAM4BRumHaEfRUk9NAkxwkQOydVNWHmDXijkDK/HW0Jzt2DwfszqKgCIM?= =?us-ascii?Q?tUDfoO+OzQ/Ylnvasolr8rkLjZ66r/8JKFUzNcSOToksk3wnCPkZZdx8FzPs?= =?us-ascii?Q?7AqoYIst21d+3Z84j2IYHSehGJzCr5mAr09RfNgwF0Qvjg9ob9+VNM3k/Le3?= =?us-ascii?Q?sGLkgiChxvA5RWJw4Ol5Z9k9vT09VZ31ENxYTTxtm4tBhB76cqi1rEkHLPop?= =?us-ascii?Q?9UBY/hX8r7TXd53vE4GadPJEcks6bCSclME5NMMO5kgmGiKRiGF+6IQ/IxzT?= =?us-ascii?Q?LXCBtiNMJdlgZDycAED1olkZTvyYO5PsCoN+nrw0h6z?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: XH+RTsvUmr+AodNop4hfsxRemUsrVTP5YpGN3y/Dl+wkdZiVVOpLOFhA4UMAibOMoaXn6ZOsqr+6j9gojscyp9ErsEkNe6DSb/uMHEUDNrcbb1oUFwVSW7am08a5kJmNpPaOyzcu1O0WEc0wTTaMSLCE58WXhUAxAQV/D0dJwtaruOWkFqwsCDU6xC66mMEx7GWS7p6AjUEPGMCspKXjUBdubFEQ3Z243Wyh1dZk3H/NkMtQKa0T1BVPYQx8gJh3SKccefddsAaZtMN0KauOaQlxjQ87PLV+Hlx8y+XoBTy0DxL7hYo1nsXWHxjzJ7WS0hD0RepKkn2e6AH0syS7TWh2GxrW23iSo4hB0H+XrazbyosXJKwWQBniWd3vQLFScABDRDQj653Gb8TcHeiuB4cm6bAEu+Hcb2i3YJxdnaM= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2019 02:37:20.4985 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f81579d7-352f-44ee-0df4-08d69aca2ac2 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB3295 Archived-At: Subject: Re: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 02:37:28 -0000 On Sun, Feb 24, 2019 at 06:16:06PM -0800, Justin Uberti wrote: > On Sun, Feb 24, 2019 at 5:32 PM Benjamin Kaduk wrote: > > > On Fri, Feb 22, 2019 at 05:10:35PM -0800, Justin Uberti wrote: > > > Thanks for your comments. See below. > > > > > > On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk wrote: > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > draft-ietf-rtcweb-fec-08: 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-fec/ > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > Section 3 > > > > > > > > nit: The subsequent discussion seems to indicate that at least some of > > > > these mechanisms are already specified and not new in this document; > > (if > > > > so) it would be nice to have the exposition reflect that. > > > > > > > > Section 3.3 > > > > > > > > For Opus, packets deemed as important are re-encoded at a lower > > > > bitrate and added to the subsequent packet, allowing partial > > recovery > > > > > > > > Is "added" supposed to be something other than "appended" (which > > strongly > > > > resembles the "redundant encoding" of the previous section)? > > > > > > > > > > It's similar to the redundant encoding, but done within the Opus > > bitstream, > > > rather than at the RTP level. > > > > > > > > > > > Section 4.1 > > > > > > > > Does it make sense to give subsection backreferences when talking about > > > > (e.g.) redundant encoding? > > > > > > > > > > Yes, this could be done easily. > > > > > > > > > > > Section 5.2 > > > > > > > > Support for a SSRC-multiplexed flexfec stream to protect a given RTP > > > > stream SHOULD be indicated by including one of the formats described > > > > in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an > > > > > > > > nit: Since this Section 5 is solely for video, is it more appropriate > > to > > > > refer to Section 5.1.2 ("Registration of video/flexfec") of > > > > draft-ietf-payload-flexible-fec-scheme? > > > > > > > > > > Agreed - earlier versions of flexfec were slightly different. > > > > > > > > > > > Section 7 > > > > > > > > To support the functionality recommended above, implementations MUST > > > > be able to receive and make use of the relevant FEC formats for > > their > > > > supported audio codecs, and MUST indicate this support, as described > > > > in Section 4. Use of these formats when sending, as mentioned > > above, > > > > is RECOMMENDED. > > > > > > > > Just to double-check: this is explicitly only mandating FEC for audio > > and > > > > ignoring video entirely? > > > > > > > > > > This para only applies to audio. The following para discusses video, but > > is > > > SHOULD-strength given the relative newness of flexfec. > > > > > > > > > > > Section 8 > > > > > > > > Because use of FEC always causes redundant data to be transmitted, > > > > and the total amount of data must remain within any bandwidth limits > > > > indicated by congestion control and the receiver, this will lead to > > > > less bandwidth available for the primary encoding, even when the > > > > redundant data is not being used. This is in contrast to methods > > > > like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] > > > > retransmissions, which only transmit redundant data when necessary, > > > > at the cost of an extra roundtrip. > > > > > > > > This seems to imply that "FEC" is a specific usage and that flexfec is > > not > > > > a subset of generic FEC. If so, this could probably be reworded to be > > > > less confusing to the reader (though my suspicion is that the "always > > > > causes redundant data to be transmitted" is only intended to apply to > > > > specific mechanisms from Section 3). > > > > > > > > > > flexfec is not quite a subset of generic FEC, since it also has a > > > retransmission format. Thoughts on how this could be reworded? > > > > I think it would need to be "Because use of FEC in the form of > > always causes [...]", but I'm not entirely sure what is. Is it > > just "this document" or is there a broader framework or structure to which > > this document adheres? > > > > This document incorporates multiple FEC schemes, so there isn't another > overarching document (to my knowledge) that captures all of the mechanisms. > > The intent here was to say "Because FEC, in general, always causes...", but > open to other phrasings. Ah, I see now. I think what would help is "in contrast to methods like RTX or flexfec (when retransmissions are used) [I-D.<...>]" > > > > > > > > > Section 9 > > > > > > > > This document seems to be agnostic on the question of RTP vs. SRTP; I > > would > > > > consider referencing their respective security considerations as well > > as > > > > what is already covered here. > > > > > > > > As described in [RFC3711], Section 10, the default processing when > > > > using FEC with SRTP is to perform FEC followed by SRTP at the > > sender, > > > > and SRTP followed by FEC at the receiver. This ordering is used for > > > > all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as > > > > described in [RFC5764], Section 4.1.2. > > > > > > > > I was going to comment about the lack of clarity here, but I see that > > Ekr > > > > has already gotten the core points, and that the secdir review has > > already > > > > resulted in some chanegs in the editor's copy. It would be nice to > > have > > > > the result of the (merged) edits available to look at, though. > > > > > > > > Here's the latest text. Let me know if this needs to be further > > clarified. > > > > > > In the WebRTC context, FEC is specifically concerned with > > recovering > > > data from lost packets; any corrupted packets will be discarded by > > the > > > SRTP decryption process. Therefore, as > > described > > > in , Section 10, the default processing > > when > > > using FEC with SRTP is to perform FEC followed by SRTP at the > > sender, and > > > SRTP followed by FEC at the receiver. This ordering is used for > > all the > > > SRTP Protection Profiles used in DTLS-SRTP > > > , which are enumerated in > > > , Section 4.1.2. > > > > This is a lot better; the only thing that I might wonder about is whether > > the "this ordering is used for all the SRTP protection profiles used in > > DTLS-SRTP" is a new requirement imposed by this document or if that's > > supposed to be something that is stated in one of the references. > > > > It's really just a reiteration of an existing point from RFC 3711 to head > off common questions about the interaction of FEC and encryption. Okay. Thanks for confirming! -Benjamin > > > > Thanks for the updates and confirmations of my understanding, > > > > Benjamin > > From nobody Sun Feb 24 20:10:14 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB477130EE4 for ; Sun, 24 Feb 2019 20:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUuoRmeCWdyC for ; Sun, 24 Feb 2019 20:10:06 -0800 (PST) Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 213CC130ECF for ; Sun, 24 Feb 2019 20:10:00 -0800 (PST) Received: by mail-it1-x129.google.com with SMTP id z124so11377670itc.2 for ; Sun, 24 Feb 2019 20:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aAV3WJCgvuTNJvc5iqBvZejxRNJWbzPflLmAE8iw/O4=; b=vQcUkGJAaiNa9gyI1HIgF/jHgK2tOyHrUDeaDnllIphzYzNl8iHFJxW5KUP+3s53pz Xo/sK8X3JY1RRQrHjj+gqs+H8og+0XSvkbwD8eV+d0ZYZPeM0pN8sAu+CkRVSn+6SbmH +XXrEx8lSrF7UC4129ShMfhK82Llhlv/7QsEsgCIBCl5kmqIxkTzM35FxQ5IekGaJuoP CVydcBfk/M6NzJ9CJJg90HMZRmy/vnUWW3O84VQ/322s0PdptLTeR8izakerdGG22ptO oURg42j972dITHdYas3f8fHpN8xbxKrtNEbAcgihoyCmh7fmgTxo42WnD6rcdqWNZ2fc 0W+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aAV3WJCgvuTNJvc5iqBvZejxRNJWbzPflLmAE8iw/O4=; b=ba5UUFcEe3c1HPYIsWtFzGz+mt4hZ5aYyEPmnFoAi3fS9vN5Pyj3FyBsNyBazcO+t/ 51+jxMLV1Xf7djWmvKZltqbcOxjC4zMkfVWrf8D5dSll059/wzD0LFrqJ8QmAAbRItAA lnPw8IDVDbAB4SqJIR6M85lpURz4wgvv8rRcvt27Yw/RutB8/QKovyOb6MgdKSVhGr4X D/pns+JxsKSSwSJ7ZLLqwJCtbYKsmxAc+uvFt7QtIkYH09datc11vNXi6sRx6PemFZHj XktBWJ9GkHOJm3npikCQlRhB14Ej+1/2ZHnBetCf7LtjmUPMoMqdhDmvu0i2GUkGZ0hf l5Mw== X-Gm-Message-State: AHQUAubr8c/FNY4SkvyvXQGA4G/bHwDGjgHDFYFFx3omKYQArzQAQiOc vGD2Z3ZV9Ynt25rPxNOMg+YRX2YHFAqsGSa/RNlpnw== X-Google-Smtp-Source: AHgI3IZpcbHVtwDZm736SJxcGQezAIQsf2WcYRR3K/cAsiMZfweqGMnSXU5x5rmS+UUJMf1IskLyrjgC2bNDfZ72t4w= X-Received: by 2002:a24:ccc5:: with SMTP id x188mr8435558itf.123.1551067798919; Sun, 24 Feb 2019 20:09:58 -0800 (PST) MIME-Version: 1.0 References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> In-Reply-To: From: Justin Uberti Date: Sun, 24 Feb 2019 20:09:47 -0800 Message-ID: To: Roman Shpount Cc: Ted Hardie , RTCWeb IETF , Christer Holmberg Content-Type: multipart/alternative; boundary="0000000000002dd5ff0582b01d8b" Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 04:10:10 -0000 --0000000000002dd5ff0582b01d8b Content-Type: text/plain; charset="UTF-8" Found a way to address this with minor changes to the existing PR. On Fri, Feb 22, 2019 at 5:46 PM Justin Uberti wrote: > Roman, thanks for raising this. I looked into this a bit and it's kind of > ambiguous; https://tools.ietf.org/html/rfc7850 uses "profile", "proto", > and "protocol" (although "protocol" is used most frequently). > > JSEP actually uses both profile and protocol to refer to the transport, > depending on the section; if we make a change here, we should hit all > usages, which probably means that it is outside of the scope of this > particular issue. > > On Tue, Feb 19, 2019 at 1:19 PM Roman Shpount wrote: > >> Hi Justin, >> >> I did provide editorial feedback to the change on github: >> >> 1. This document refers to SDP protocol as profile. If you look at the >> referenced documents that define "profiles" in JSEP, they all refer to them >> as protocols. Also, in case of SRTP, profile is actually something >> different and refers to SRTP key parameters. >> >> 2. Default candidate does not have profile (or protocol), it has >> transport, port, and (connection-)address. So each "m=" and "c=" MUST be >> filled in with port, protocol, and address to match port, transport, and >> address of the default candidate for the m= section, as described in >> ice-sip-sdp. >> >> Regards, >> _____________ >> Roman Shpount >> >> >> On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> Looks good. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Christer >>> >>> >>> >>> *From: *rtcweb on behalf of Justin Uberti >>> > >>> *Date: *Saturday, 16 February 2019 at 3.57 >>> *To: *Ted Hardie >>> *Cc: *"rtcweb@ietf.org" >>> *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport >>> parameter issue >>> >>> >>> >>> I have updated this PR to incorporate minor feedback that was received >>> during the consensus call. Those who had feedback, please take another look >>> and comment on the PR if you are satisfied. >>> >>> >>> >>> On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie wrote: >>> >>> The chairs believe that there was rough consensus among those responding >>> to make the change in: >>> >>> >>> >>> https://github.com/rtcweb-wg/jsep/pull/863 >>> >>> >>> >>> Given the state of the document, it will be the Area Director's call as >>> to how much of the post-working group approval process must be re-done. >>> Authors, please wait on his direction before publishing a new version with >>> this merged. >>> >>> >>> >>> Regards, >>> >>> Ted and Sean >>> >>> _______________________________________________ >>> 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 >>> >> --0000000000002dd5ff0582b01d8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Found a way to address this with minor changes to the exis= ting PR.

On Fri, Feb 22, 2019 at 5:46 PM Justin Uberti <juberti@google.com> wrote:
Ro= man, thanks for raising this. I looked into this a bit and it's kind of= ambiguous; https://tools.ietf.org/html/rfc7850 uses "profile", "= proto", and "protocol" (although "protocol" is use= d most frequently).

JSEP actually uses both profile and = protocol to refer to the transport, depending on the section; if we make a = change here, we should hit all usages, which probably means that it is outs= ide of the scope of this particular issue.

On Tue, Feb 19, 2019= at 1:19 PM Roman Shpount <roman@telurix.com> wrote:
Hi Justin,
I did provide editorial feedback to the change on github:=

1. This document refers to SDP protocol as p= rofile. If you look at the referenced documents that define "profiles&= quot; in JSEP, they all refer to them as protocols. Also, in case of SRTP, = profile is actually something different and refers to SRTP key parameters.<= /div>

2. Default candidate does not have profile (or pro= tocol), it has transport, port, and (connection-)address. So each "m= =3D" and "c=3D" MUST be filled in with port, protocol, and a= ddress to match port, transport, and address of the default candidate for t= he m=3D section, as described in ice-sip-sdp.

Rega= rds,
_____________
Roman Shpount
<= /div>

On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg <= christe= r.holmberg@ericsson.com> wrote:

Looks good.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = rtcweb <rtcweb-bounces@ietf.org<= /a>> on behalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org>=
Date: Saturday, 16 February 2019 at 3.57
To: Ted Hardie <ted.ietf@gmail.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

I have updated this PR to incorporate minor feedback= that was received during the consensus call. Those who had feedback, pleas= e take another look and comment on the PR if you are satisfied.

=C2=A0

On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

The chairs believe that there was rough consensus am= ong those responding to make the change in:

=C2=A0

=C2=A0

Given the state of the document, it will be the Area= Director's call as to how much of the post-working group approval proc= ess must be re-done.=C2=A0 Authors, please wait on his direction before pub= lishing a new version with this merged.

=C2=A0

Regards,

Ted and Sean

_______________________________________________
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
--0000000000002dd5ff0582b01d8b-- From nobody Sun Feb 24 23:59:02 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1409130ED7 for ; Sun, 24 Feb 2019 23:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=g8Hdo6ks; dkim=pass (1024-bit key) header.d=ericsson.com header.b=cQCLeZVy 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 N6-h4hVvlvDH for ; Sun, 24 Feb 2019 23:58:56 -0800 (PST) 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 7AB2D130ED4 for ; Sun, 24 Feb 2019 23:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551081533; x=1553673533; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fiBKDKuyoZksL5LsY7FS7aQsLs8yFLhHW8apgNlbuEs=; b=g8Hdo6ksylDiYmZiNTReqVAiuFW9fRIBOcyobKfbqwUZ51zoFquxoEXz6Lxp+XBN E81Wb0IshR9OVNBr6SURNoplpo+6AzM/o25ZMpGoq9ByiWH8u+Nwjvo/utG2564C Y5tGpBHXH91jMlF3MBqi3im6lMjR9aDsTRyVNXB3AuU=; X-AuditID: c1b4fb3a-5c9c29e00000672c-87-5c73a03de4ac Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.A7.26412.D30A37C5; Mon, 25 Feb 2019 08:58:53 +0100 (CET) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 25 Feb 2019 08:58:50 +0100 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 25 Feb 2019 08:58:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fiBKDKuyoZksL5LsY7FS7aQsLs8yFLhHW8apgNlbuEs=; b=cQCLeZVyclY6lKQcEprzXQmPLnZ4cssAinxy1p8Flk8eR6Vlzy4pExJN9JSF9VVnT++sw5mzjOEjNuBJqBx3q64l1OpRHqhVQAsNCX+euRJWIx35IsT3j2BUDN3rz8ltHdoUif11RTAE5Q3M+ncvNGPsjttVCFHqlgP615C9lyY= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3098.eurprd07.prod.outlook.com (10.170.244.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.6; Mon, 25 Feb 2019 07:58:47 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1665.012; Mon, 25 Feb 2019 07:58:47 +0000 From: Christer Holmberg To: Justin Uberti , Roman Shpount CC: Ted Hardie , RTCWeb IETF Thread-Topic: [rtcweb] Results of call for consensus on ICE transport parameter issue Thread-Index: AQHUxYHCF4jGTlyGqkCBEfyt1ATxTKXhqseAgAYIbID///M5gIAFAbmAgANMu4CAAGGBAA== Date: Mon, 25 Feb 2019 07:58:47 +0000 Message-ID: <8C8AC253-4995-4FD8-B9A7-2E4F303B5153@ericsson.com> References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 799769ff-fd9f-4b0f-7f3f-08d69af71236 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3098; x-ms-traffictypediagnostic: HE1PR07MB3098: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzMDk4OzIzOnYvWGxyZzVHMzdPQldoRzVMemJoS1Y3QUNV?= =?utf-8?B?QmVzTmRTT2ptNDVCQjNBekMyaGlWMGtkSS9DMjc5RHZyd25lUU1tZ3Z2bm9U?= =?utf-8?B?ZmIrbHlqUlh3SzZJV294QVlDeXQ4VTY3N2xWUWYvM0JrcVgydkQzZzRyZVpt?= =?utf-8?B?TlI5eDBZQldudXVpVGI0RXlWVGFRQjRzUEdiL3JpOW1CUlVQWWFLVjdxYit6?= =?utf-8?B?Yzg3QmhOSUVGR2ZQYlczeGRWWUE0ZllsemxJRE9ta1o5bEtFNURhZGZHRmxk?= =?utf-8?B?anRQSEs0cFhUSU1NeTB0bFNSUlJqYTZkL1lMYWw5eDFVUklvZHZ3aWtSc3Ux?= =?utf-8?B?WVJFZEJKZFJad0JQa3c1Wk5wZDlqMG1wNGpEanZFMFh5aVdaRFR6Zkp6ZkRB?= =?utf-8?B?TnZwVThvUDd5M1QwaGF0RGpqSFdINEI3VzY0QlVyb2ZaMWZ3Y1pNSFlBcncz?= =?utf-8?B?Sm5JWkNaeHE3MTNsaWNpbTllTlRFaUNhTTRxcDIzMTZYTk9nL0pzbUJIR3hj?= =?utf-8?B?SlllUWkwK3U1UHR4L1pJRFRSOExKVDJEOERWOE1VK0dMMUlOejAwalBhUWZw?= =?utf-8?B?MEpFNE5lYXhaTm1KZVYybW1LZlpvZXp6SDJnMHE3d2xGRFZySWRoeTdxcVAz?= =?utf-8?B?bzdDZVNwajJPVzRZMW9aVHVoTlBnQlM1dUo0aUc5S0wxM0RIQ2pyc3lGamMv?= =?utf-8?B?REVCV3dGaWNjSjFVQ0lucE1tQ05lWERkTW5MZTR0TEZWbXVXdGc2Y1lIdyto?= =?utf-8?B?R08xSmZkWkNjazNKYVBENHYvQ0FDYTR3ZVFiNFBtZnYvUDBOckZ1MDJZTXEz?= =?utf-8?B?R0JZT2luUDQ5bGVDV29tYWhrZm55RGVUUEpLMzJJTkF1UktRbzhVcUpSZEFD?= =?utf-8?B?R3BVcktFNmRFM1JybW1pQjg5NklTU00rMWJXTjE2REkzcGFISkx1NWZYRVVn?= =?utf-8?B?ak5UbjNkek1mMzNMM3Q0M28zVmQrV1B0eVpRYkR5MTRDWWErdk1HU285b2xJ?= =?utf-8?B?N1VROXJIdHNhNTFsQTN3NTR6TElCa3JDdG5PQjUrSnI4TjkvODFHbjYzKzFK?= =?utf-8?B?LythbW8wak1YUTIwc0FMSHNlaVFRenMwQ0Zxa29hRFNBaHNUY0lBNFluZzB0?= =?utf-8?B?a2V1bytwK0VmekxIOVNFbndBZGg3cXlxUkcvZGJhZWQvYUZMbHpNQ293YW5y?= =?utf-8?B?OGxrdDFUV290cnNoYWpUYmt0cXU1TFBUK2l0U0QvMGJmS0ZBaTZmSzRXYjNX?= =?utf-8?B?ODZVK3ZqS3ZtcnMxUFlYcHFCNHFYbDhiYmlxL2VLT292YTFuYm5ERVl0UHdD?= =?utf-8?B?eE9yU1J3RGgwemFGZTdWcExITHJieTcyQVB6M3BVOWtTTndBTVhKOEttTUNq?= =?utf-8?B?empPMmFQcUtrd0Y1YXRsVzdheFcwdElmeHRWc0ExdkpkQ3RVekEvZVQvRUFB?= =?utf-8?B?VGMwR1B0WUdyWHRJaWdjYVZoQXdudWdBak1waS9EVTFqTkludlFUcnFkSDB5?= =?utf-8?B?Q2FMM2ZGaHMxYkhlRUZqVnZmNmx5cGFLdHNOazVKZk1IMGEwOFY3eHYxRkJB?= =?utf-8?B?TGREY3EvY2loNlBZZ3pVd0JMWnA5aEdVaEx6dDZHVkE1KzM5RzVRcU1zR0s5?= =?utf-8?B?R1FIM2tYOWo0K3kveFltWkNwYmJCWEdzNG1FbXp6KzhDWjg2bHhEdk5WM3Zk?= =?utf-8?B?aDNlM242SW13MUFoREZrTktXblRzTEE0c3QvWTE5MHNHV2lQQ1lpNVZoMnNX?= =?utf-8?B?NklWZS9McUdQOFcvc1BJKzdKVXMyQXBZUHMwKzRoQzdBYTQyNzRZblcwSmJz?= =?utf-8?B?MlNPcGVhRlFRWGtQdmNjaXg4WG5EMVdLdTZRc3A3d1ZHOUkzMkRId0Zpc2hE?= =?utf-8?Q?xhvAIvUo3s8=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(366004)(136003)(396003)(199004)(189003)(256004)(54906003)(110136005)(66066001)(3846002)(6116002)(53546011)(102836004)(316002)(58126008)(106356001)(105586002)(478600001)(26005)(6506007)(186003)(5660300002)(8936002)(6436002)(53936002)(86362001)(6512007)(14454004)(33656002)(68736007)(6486002)(54896002)(6306002)(7736002)(236005)(44832011)(82746002)(606006)(99286004)(6246003)(93886005)(76176011)(25786009)(2906002)(36756003)(229853002)(966005)(97736004)(2616005)(476003)(71200400001)(71190400001)(83716004)(486006)(446003)(11346002)(81156014)(81166006)(8676002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3098; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: boB4Y4NFhtLKOu8Ky4auIDbzhV+BPqNhFzcyaJI7xM+L4E3EE26OEHVknxbxDCGYNPuojopl27G58P83NCdRVF9FPODFBFmQZUhRQENA/tWE0MrjuDeA/u8AS4WYyap8nKqFTFS19XQDwGecOW/k168QMvtnkQQEXuR4Dvng1Hr5muXDp0V2weomKHb+SAChqudJjBCZImDvns1g4FWC0IGa/24mWe3vIM6ZV6cFpOPgJQXBaPi0PaIXIyTkVU4q9LrsmdWBzOpLpJFuAUF7l2ncAPxjgkzZ2tVqKPRQfn0NfdXgA7PL3YZd24NyQ/zTKfAAcnNqWhZeCUDdcTM23Ajcoj3l8uTBg4wXyBHU2a5MWIal60nRFXFk8hlX3CZiSdfuJWIo1SaHwJjj0f9kMGLWWSmiM5iUEVftcWX5i0s= Content-Type: multipart/alternative; boundary="_000_8C8AC25349954FD8B9A72E4F303B5153ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 799769ff-fd9f-4b0f-7f3f-08d69af71236 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 07:58:47.1103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3098 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjm2znbzsTR59R8sfrh6KJGWtaPZaklQRMJEkrNrFx6UnFe2pmm EqVGCs5EcFZOx5wopWniUrxkhjKFimFlltk0LwMrKUNHoZXl2Vngv+fK+70vH0VIzHxvKjVD TasyFEqpwIWsju3K3RNSx8Tv/W7dKeusksjuvqwiZK1rJUJZoT70CCnv0U0K5XWmbHlDwwpP PqHNOknGuRxOopWpObQqMDTBJaVx1Yiy7htQ7osCjaAAldSgUiSiAB8AU9sQUYpcKAk2I2h9 bBZy5AeC2bJCPkcaeGB/8wCxhMQVBFiKJ3hsX4IreaCpiOJSswjeGqbWKxQlwDLQrO1mMx44 AmpbpgWsTOBwsHRdYWV3HA2jc/2Ii8SATb/maHqs69rO7axM4h0wYSp3TBLjMFhYWCW5SfUE PBwoIlhDhKPAuMxhhDfDz+ctjgKBvWDCZuBxa2Jo6BshOOwJn+fYWSLKEwdCR/k0yXUV8LR5 2pnxAcu3GWd3G7w2aJznOgHW0XLHuQC/RzDYdMNp+INtyuzE3mAcsQu50CsJLN8aE3JGGhQV feRzeCsstbcIKlCAbsNjdY4bJcL8yjmdY2k3eFZtIznZD9p6A7m0D2g1M0IO+8LNWr0Ty2Gh ySjYmKlDVDPyZGiGSU8OCgqgVamJDJOZEZBBq01o/W8NdPwK7kYD80cHEaaQ1FX8Qc/ES/iK HCYvfRABRUg9xFWsJE5S5OXTqswLqmwlzQyiLRQp9RL/lrjFS3CyQk2n0XQWrfrv8iiRdwGK Lhs27krJCZqPjItcLrzq15e8adzt4EjTobQnUfdCw+Mb9ytjLdfVMTnHlxOSwi5q79RfmzxW k3mqCJM9fHVQS/tlnf2v71j1bculbu3Z/HH7Gb61rnvxfMhQpHWpvdKgWaUXi4O7vrpGnP5j cTcNT+b2v3v0aSHK2JtEZ0d/YaQkk6LY50+oGMU/Ocr/0lcDAAA= Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 07:58:59 -0000 --_000_8C8AC25349954FD8B9A72E4F303B5153ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkluIDQ1NjZiaXMsIDxwcm90bz4gZGVmaW5lcyBhIHRyYW5zcG9ydCBwcm90b2NvbC4N Cg0KSW4gY2FzZSBvZiBSVFAsIHRoZSB0ZXh0IHJlZmVycyB0byBSVFAvQVZQIGFzIGFuIOKAnFJU UCBwcm9maWxl4oCdLCBidXQgaXQgaXMgc3RpbGwgYSB0cmFuc3BvcnQgcHJvdG9jb2wuDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xl LmNvbT4NCkRhdGU6IE1vbmRheSwgMjUgRmVicnVhcnkgMjAxOSBhdCA2LjEwDQpUbzogUm9tYW4g U2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+DQpDYzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21h aWwuY29tPiwgInJ0Y3dlYkBpZXRmLm9yZyIgPHJ0Y3dlYkBpZXRmLm9yZz4sIENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBSZTogW3J0 Y3dlYl0gUmVzdWx0cyBvZiBjYWxsIGZvciBjb25zZW5zdXMgb24gSUNFIHRyYW5zcG9ydCBwYXJh bWV0ZXIgaXNzdWUNCg0KRm91bmQgYSB3YXkgdG8gYWRkcmVzcyB0aGlzIHdpdGggbWlub3IgY2hh bmdlcyB0byB0aGUgZXhpc3RpbmcgUFIuDQoNCk9uIEZyaSwgRmViIDIyLCAyMDE5IGF0IDU6NDYg UE0gSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb20+PiB3cm90ZToNClJvbWFuLCB0aGFua3MgZm9yIHJhaXNpbmcgdGhpcy4gSSBsb29rZWQg aW50byB0aGlzIGEgYml0IGFuZCBpdCdzIGtpbmQgb2YgYW1iaWd1b3VzOyBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNzg1MCB1c2VzICJwcm9maWxlIiwgInByb3RvIiwgYW5kICJwcm90 b2NvbCIgKGFsdGhvdWdoICJwcm90b2NvbCIgaXMgdXNlZCBtb3N0IGZyZXF1ZW50bHkpLg0KDQpK U0VQIGFjdHVhbGx5IHVzZXMgYm90aCBwcm9maWxlIGFuZCBwcm90b2NvbCB0byByZWZlciB0byB0 aGUgdHJhbnNwb3J0LCBkZXBlbmRpbmcgb24gdGhlIHNlY3Rpb247IGlmIHdlIG1ha2UgYSBjaGFu Z2UgaGVyZSwgd2Ugc2hvdWxkIGhpdCBhbGwgdXNhZ2VzLCB3aGljaCBwcm9iYWJseSBtZWFucyB0 aGF0IGl0IGlzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoaXMgcGFydGljdWxhciBpc3N1ZS4N Cg0KT24gVHVlLCBGZWIgMTksIDIwMTkgYXQgMToxOSBQTSBSb21hbiBTaHBvdW50IDxyb21hbkB0 ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCkhpIEp1c3RpbiwN Cg0KSSBkaWQgcHJvdmlkZSBlZGl0b3JpYWwgZmVlZGJhY2sgdG8gdGhlIGNoYW5nZSBvbiBnaXRo dWI6DQoNCjEuIFRoaXMgZG9jdW1lbnQgcmVmZXJzIHRvIFNEUCBwcm90b2NvbCBhcyBwcm9maWxl LiBJZiB5b3UgbG9vayBhdCB0aGUgcmVmZXJlbmNlZCBkb2N1bWVudHMgdGhhdCBkZWZpbmUgInBy b2ZpbGVzIiBpbiBKU0VQLCB0aGV5IGFsbCByZWZlciB0byB0aGVtIGFzIHByb3RvY29scy4gQWxz bywgaW4gY2FzZSBvZiBTUlRQLCBwcm9maWxlIGlzIGFjdHVhbGx5IHNvbWV0aGluZyBkaWZmZXJl bnQgYW5kIHJlZmVycyB0byBTUlRQIGtleSBwYXJhbWV0ZXJzLg0KDQoyLiBEZWZhdWx0IGNhbmRp ZGF0ZSBkb2VzIG5vdCBoYXZlIHByb2ZpbGUgKG9yIHByb3RvY29sKSwgaXQgaGFzIHRyYW5zcG9y dCwgcG9ydCwgYW5kIChjb25uZWN0aW9uLSlhZGRyZXNzLiBTbyBlYWNoICJtPSIgYW5kICJjPSIg TVVTVCBiZSBmaWxsZWQgaW4gd2l0aCBwb3J0LCBwcm90b2NvbCwgYW5kIGFkZHJlc3MgdG8gbWF0 Y2ggcG9ydCwgdHJhbnNwb3J0LCBhbmQgYWRkcmVzcyBvZiB0aGUgZGVmYXVsdCBjYW5kaWRhdGUg Zm9yIHRoZSBtPSBzZWN0aW9uLCBhcyBkZXNjcmliZWQgaW4gaWNlLXNpcC1zZHAuDQoNClJlZ2Fy ZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg0KT24gVHVlLCBGZWIgMTksIDIw MTkgYXQgMzowNSBQTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkxv b2tzIGdvb2QuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiA8cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIEp1c3RpbiBVYmVydGkgPGp1YmVydGk9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn PG1haWx0bzo0MGdvb2dsZS4uY29tQGRtYXJjLmlldGYub3JnPj4NCkRhdGU6IFNhdHVyZGF5LCAx NiBGZWJydWFyeSAyMDE5IGF0IDMuNTcNClRvOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5j b208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+DQpDYzogInJ0Y3dlYkBpZXRmLm9yZzxtYWls dG86cnRjd2ViQGlldGYub3JnPiIgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBSZXN1bHRzIG9mIGNhbGwgZm9yIGNvbnNlbnN1 cyBvbiBJQ0UgdHJhbnNwb3J0IHBhcmFtZXRlciBpc3N1ZQ0KDQpJIGhhdmUgdXBkYXRlZCB0aGlz IFBSIHRvIGluY29ycG9yYXRlIG1pbm9yIGZlZWRiYWNrIHRoYXQgd2FzIHJlY2VpdmVkIGR1cmlu ZyB0aGUgY29uc2Vuc3VzIGNhbGwuIFRob3NlIHdobyBoYWQgZmVlZGJhY2ssIHBsZWFzZSB0YWtl IGFub3RoZXIgbG9vayBhbmQgY29tbWVudCBvbiB0aGUgUFIgaWYgeW91IGFyZSBzYXRpc2ZpZWQu DQoNCk9uIEZyaSwgRmViIDE1LCAyMDE5IGF0IDI6NTYgUE0gVGVkIEhhcmRpZSA8dGVkLmlldGZA Z21haWwuY29tPG1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNClRoZSBjaGFpcnMg YmVsaWV2ZSB0aGF0IHRoZXJlIHdhcyByb3VnaCBjb25zZW5zdXMgYW1vbmcgdGhvc2UgcmVzcG9u ZGluZyB0byBtYWtlIHRoZSBjaGFuZ2UgaW46DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWIt d2cvanNlcC9wdWxsLzg2Mw0KDQpHaXZlbiB0aGUgc3RhdGUgb2YgdGhlIGRvY3VtZW50LCBpdCB3 aWxsIGJlIHRoZSBBcmVhIERpcmVjdG9yJ3MgY2FsbCBhcyB0byBob3cgbXVjaCBvZiB0aGUgcG9z dC13b3JraW5nIGdyb3VwIGFwcHJvdmFsIHByb2Nlc3MgbXVzdCBiZSByZS1kb25lLiAgQXV0aG9y cywgcGxlYXNlIHdhaXQgb24gaGlzIGRpcmVjdGlvbiBiZWZvcmUgcHVibGlzaGluZyBhIG5ldyB2 ZXJzaW9uIHdpdGggdGhpcyBtZXJnZWQuDQoNClJlZ2FyZHMsDQpUZWQgYW5kIFNlYW4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGlu ZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2Vi QGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K --_000_8C8AC25349954FD8B9A72E4F303B5153ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5J biA0NTY2YmlzLCAmbHQ7cHJvdG8mZ3Q7IGRlZmluZXMgYSB0cmFuc3BvcnQgcHJvdG9jb2wuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5JbiBjYXNlIG9mIFJUUCwgdGhlIHRleHQgcmVmZXJzIHRvIFJUUC9B VlAgYXMgYW4g4oCcUlRQIHByb2ZpbGXigJ0sIGJ1dCBpdCBpcyBzdGlsbCBhIHRyYW5zcG9ydCBw cm90b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5D aHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SnVzdGluIFViZXJ0aSAmbHQ7anViZXJ0aUBnb29n bGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDI1IEZlYnJ1YXJ5IDIwMTkgYXQg Ni4xMDxicj4NCjxiPlRvOiA8L2I+Um9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj5UZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7 LCAmcXVvdDtydGN3ZWJAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDssIENo cmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbcnRjd2ViXSBSZXN1bHRzIG9mIGNhbGwgZm9yIGNvbnNl bnN1cyBvbiBJQ0UgdHJhbnNwb3J0IHBhcmFtZXRlciBpc3N1ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm91bmQgYSB3YXkgdG8g YWRkcmVzcyB0aGlzIHdpdGggbWlub3IgY2hhbmdlcyB0byB0aGUgZXhpc3RpbmcgUFIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAyMiwg MjAxOSBhdCA1OjQ2IFBNIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRp QGdvb2dsZS5jb20iPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Sb21hbiwgdGhhbmtzIGZvciByYWlzaW5nIHRoaXMuIEkgbG9va2VkIGludG8gdGhpcyBh IGJpdCBhbmQgaXQncyBraW5kIG9mIGFtYmlndW91czsNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3ODUwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc4NTA8L2E+IHVzZXMgJnF1b3Q7cHJvZmlsZSZxdW90OywgJnF1b3Q7cHJv dG8mcXVvdDssIGFuZCAmcXVvdDtwcm90b2NvbCZxdW90OyAoYWx0aG91Z2ggJnF1b3Q7cHJvdG9j b2wmcXVvdDsgaXMgdXNlZCBtb3N0IGZyZXF1ZW50bHkpLg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KU0VQIGFjdHVhbGx5IHVzZXMgYm90aCBwcm9maWxl IGFuZCBwcm90b2NvbCB0byByZWZlciB0byB0aGUgdHJhbnNwb3J0LCBkZXBlbmRpbmcgb24gdGhl IHNlY3Rpb247IGlmIHdlIG1ha2UgYSBjaGFuZ2UgaGVyZSwgd2Ugc2hvdWxkIGhpdCBhbGwgdXNh Z2VzLCB3aGljaCBwcm9iYWJseSBtZWFucyB0aGF0IGl0IGlzIG91dHNpZGUgb2YgdGhlIHNjb3Bl IG9mIHRoaXMgcGFydGljdWxhciBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAxOSwgMjAxOSBhdCAx OjE5IFBNIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIEp1c3RpbiwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRpZCBwcm92aWRlIGVkaXRvcmlhbCBmZWVkYmFjayB0byB0aGUgY2hhbmdl IG9uIGdpdGh1Yjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjEuIFRoaXMgZG9jdW1lbnQgcmVmZXJzIHRvIFNEUCBwcm90b2NvbCBh cyBwcm9maWxlLiBJZiB5b3UgbG9vayBhdCB0aGUgcmVmZXJlbmNlZCBkb2N1bWVudHMgdGhhdCBk ZWZpbmUgJnF1b3Q7cHJvZmlsZXMmcXVvdDsgaW4gSlNFUCwgdGhleSBhbGwgcmVmZXIgdG8gdGhl bSBhcyBwcm90b2NvbHMuIEFsc28sIGluIGNhc2Ugb2YgU1JUUCwgcHJvZmlsZSBpcyBhY3R1YWxs eSBzb21ldGhpbmcgZGlmZmVyZW50IGFuZCByZWZlcnMgdG8NCiBTUlRQIGtleSBwYXJhbWV0ZXJz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y LiBEZWZhdWx0IGNhbmRpZGF0ZSBkb2VzIG5vdCBoYXZlIHByb2ZpbGUgKG9yIHByb3RvY29sKSwg aXQgaGFzIHRyYW5zcG9ydCwgcG9ydCwgYW5kIChjb25uZWN0aW9uLSlhZGRyZXNzLiBTbyBlYWNo ICZxdW90O209JnF1b3Q7IGFuZCAmcXVvdDtjPSZxdW90OyBNVVNUIGJlIGZpbGxlZCBpbiB3aXRo IHBvcnQsIHByb3RvY29sLCBhbmQgYWRkcmVzcyB0byBtYXRjaCBwb3J0LCB0cmFuc3BvcnQsIGFu ZCBhZGRyZXNzIG9mIHRoZSBkZWZhdWx0IGNhbmRpZGF0ZQ0KIGZvciB0aGUgbT0gc2VjdGlvbiwg YXMgZGVzY3JpYmVkIGluIGljZS1zaXAtc2RwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpS b21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMTksIDIwMTkgYXQgMzowNSBQTSBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkxvb2tzIGdvb2QuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hyaXN0 ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+cnRjd2Vi ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKdXN0aW4g VWJlcnRpICZsdDtqdWJlcnRpPTxhIGhyZWY9Im1haWx0bzo0MGdvb2dsZS4uY29tQGRtYXJjLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+U2F0dXJkYXksIDE2IEZlYnJ1YXJ5IDIwMTkgYXQgMy41Nzxi cj4NCjxiPlRvOiA8L2I+VGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbcnRjd2ViXSBSZXN1bHRzIG9mIGNhbGwgZm9yIGNvbnNl bnN1cyBvbiBJQ0UgdHJhbnNwb3J0IHBhcmFtZXRlciBpc3N1ZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSB1cGRh dGVkIHRoaXMgUFIgdG8gaW5jb3Jwb3JhdGUgbWlub3IgZmVlZGJhY2sgdGhhdCB3YXMgcmVjZWl2 ZWQgZHVyaW5nIHRoZSBjb25zZW5zdXMgY2FsbC4gVGhvc2Ugd2hvIGhhZCBmZWVkYmFjaywgcGxl YXNlIHRha2UgYW5vdGhlciBsb29rIGFuZCBjb21tZW50IG9uIHRoZSBQUiBpZiB5b3UgYXJlDQog c2F0aXNmaWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIEZyaSwgRmViIDE1LCAyMDE5IGF0IDI6NTYgUE0gVGVkIEhhcmRpZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGNoYWlycyBiZWxpZXZlIHRo YXQgdGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyBhbW9uZyB0aG9zZSByZXNwb25kaW5nIHRvIG1h a2UgdGhlIGNoYW5nZSBpbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cv anNlcC9wdWxsLzg2MyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWIt d2cvanNlcC9wdWxsLzg2MzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkdpdmVuIHRoZSBzdGF0ZSBvZiB0aGUgZG9jdW1lbnQsIGl0 IHdpbGwgYmUgdGhlIEFyZWEgRGlyZWN0b3IncyBjYWxsIGFzIHRvIGhvdyBtdWNoIG9mIHRoZSBw b3N0LXdvcmtpbmcgZ3JvdXAgYXBwcm92YWwgcHJvY2VzcyBtdXN0IGJlIHJlLWRvbmUuJm5ic3A7 IEF1dGhvcnMsIHBsZWFzZSB3YWl0IG9uIGhpcyBkaXJlY3Rpb24NCiBiZWZvcmUgcHVibGlzaGlu ZyBhIG5ldyB2ZXJzaW9uIHdpdGggdGhpcyBtZXJnZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UZWQgYW5kIFNlYW48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpy dGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8C8AC25349954FD8B9A72E4F303B5153ericssoncom_-- From nobody Mon Feb 25 09:54:05 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6632B129284 for ; Mon, 25 Feb 2019 09:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0HnsB_nWpDE for ; Mon, 25 Feb 2019 09:54:00 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 47868126D00 for ; Mon, 25 Feb 2019 09:54:00 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id e24so134192itl.1 for ; Mon, 25 Feb 2019 09:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EnDZreUKjD9HlOvK7xr+0HissL903Go7dLNPNLM+9FU=; b=br3mI4vV/xG12MhZz1uCTXyzh4kgm7RJ0EkmPtoKWWekXT5Y7hVcw6M3B94/Nvau0h 0V2Zv9OUurAOrpnbf63VhW4OyitomRy9HkFOQVBWbTUlNJ3nHR9Qqt0I9F+drnyzjrb5 oRHjKUDcK+FWk0gKvSGSTpEjKMbY0SEFwBGgwLVPPcSUeCBLxUSCFf/j6EPpM/xAJSRf NFt1ZIZ6FMCbfAyPdWneSg3tG0R8QO3qzw13bGoQGP1e4oVQ5Kt9AvQ0pN2MjWh4MW5J MnJWo1P/bflJQLJRhc/p5ZK8P1aREWNVBQHqHdr7MgOZZpLjezI8SioUXgV3yu+fofUt sC9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EnDZreUKjD9HlOvK7xr+0HissL903Go7dLNPNLM+9FU=; b=IcL3kcez4plTO46vHYb3iEWPu/LqQFA7XSYYztf3Szgr4f8Rq2aX/KSIZs+rEO9j7R nmZm9s7HN/4lfDSLGOkUomXe/Aul4sKCo2Kbovsfr6vrOtoc9mIbBItblNSNmCRJdG/T HFlEyHZ+h7fCe7S1csQ6GQqgGDzS06QvWjsaHE/tv6Ir190DiCNkPXNxKLyb4H7Kd3qO HmXD6uNZSZBBnRFt21MXsf98KZpWtgUXP/XDM1eyE6gpxwonekwwPtN28FeizcPr2TQC tFLmgfcco+KFsiFR6o7dTooEXXm/H8MSdMKL5JSgh3KKLiSfQQqEWtrL9j7WuNBMAKVt 6wyQ== X-Gm-Message-State: AHQUAubPE4xMpc+yQBwUvfbZBJDMGOMOM2H1sieposTJBRaPKFj26ZBU YgB1MYAxpLOR2HcE1mEnS9NYWsS+6at1LqdDTVL8pg== X-Google-Smtp-Source: AHgI3IaJZ3DT6Kafdc0WwisScmqkNO8mVxmUZSLQqILVUxyjs9NFc0kdlAnJg+HLsyAocc+dSzmp7fxYDl7Q3t+/VtY= X-Received: by 2002:a02:313:: with SMTP id y19mr6045812jad.88.1551117238887; Mon, 25 Feb 2019 09:53:58 -0800 (PST) MIME-Version: 1.0 References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> <8C8AC253-4995-4FD8-B9A7-2E4F303B5153@ericsson.com> In-Reply-To: <8C8AC253-4995-4FD8-B9A7-2E4F303B5153@ericsson.com> From: Justin Uberti Date: Mon, 25 Feb 2019 09:53:45 -0800 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000007d4780582bba0dd" Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 17:54:03 -0000 --00000000000007d4780582bba0dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, but I think it makes sense to use the same terminology (i.e., "profile") as is used in other RTP-related documents. On Sun, Feb 24, 2019 at 11:58 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > In 4566bis, defines a transport protocol. > > > > In case of RTP, the text refers to RTP/AVP as an =E2=80=9CRTP profile=E2= =80=9D, but it is > still a transport protocol. > > > > Regards, > > > > Christer > > > > *From: *Justin Uberti > *Date: *Monday, 25 February 2019 at 6.10 > *To: *Roman Shpount > *Cc: *Ted Hardie , "rtcweb@ietf.org" , > Christer Holmberg > *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport > parameter issue > > > > Found a way to address this with minor changes to the existing PR. > > > > On Fri, Feb 22, 2019 at 5:46 PM Justin Uberti wrote: > > Roman, thanks for raising this. I looked into this a bit and it's kind of > ambiguous; https://tools.ietf.org/html/rfc7850 uses "profile", "proto", > and "protocol" (although "protocol" is used most frequently). > > > > JSEP actually uses both profile and protocol to refer to the transport, > depending on the section; if we make a change here, we should hit all > usages, which probably means that it is outside of the scope of this > particular issue. > > > > On Tue, Feb 19, 2019 at 1:19 PM Roman Shpount wrote: > > Hi Justin, > > > > I did provide editorial feedback to the change on github: > > > > 1. This document refers to SDP protocol as profile. If you look at the > referenced documents that define "profiles" in JSEP, they all refer to th= em > as protocols. Also, in case of SRTP, profile is actually something > different and refers to SRTP key parameters. > > > > 2. Default candidate does not have profile (or protocol), it has > transport, port, and (connection-)address. So each "m=3D" and "c=3D" MUST= be > filled in with port, protocol, and address to match port, transport, and > address of the default candidate for the m=3D section, as described in > ice-sip-sdp. > > > > Regards, > > _____________ > Roman Shpount > > > > > > On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Looks good. > > > > Regards, > > > > Christer > > > > *From: *rtcweb on behalf of Justin Uberti > > > *Date: *Saturday, 16 February 2019 at 3.57 > *To: *Ted Hardie > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport > parameter issue > > > > I have updated this PR to incorporate minor feedback that was received > during the consensus call. Those who had feedback, please take another lo= ok > and comment on the PR if you are satisfied. > > > > On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie wrote: > > The chairs believe that there was rough consensus among those responding > to make the change in: > > > > https://github.com/rtcweb-wg/jsep/pull/863 > > > > Given the state of the document, it will be the Area Director's call as t= o > how much of the post-working group approval process must be re-done. > Authors, please wait on his direction before publishing a new version wit= h > this merged. > > > > Regards, > > Ted and Sean > > _______________________________________________ > 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 > > --00000000000007d4780582bba0dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, but I think it makes sense to use the same terminolo= gy (i.e., "profile") as is used in other RTP-related documents.
On= Sun, Feb 24, 2019 at 11:58 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

In 4566bis, <proto> defin= es a transport protocol.

=C2=A0

In case of RTP, the text refers= to RTP/AVP as an =E2=80=9CRTP profile=E2=80=9D, but it is still a transpor= t protocol.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Justin Uberti <juberti@google.com= >
Date: Monday, 25 February 2019 at 6.10
To: Roman Shpount <roman@telurix.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Christer Holmberg <<= a href=3D"mailto:christer.holmberg@ericsson.com" target=3D"_blank">christer= .holmberg@ericsson.com>
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

Found a way to address this with minor changes to th= e existing PR.

=C2=A0

On Fri, Feb 22, 2019 at 5:46 PM Justin Uberti <juberti@google.com> wrote:

Roman, thanks for raising this. I looked into this a= bit and it's kind of ambiguous; https://t= ools.ietf.org/html/rfc7850 uses "profile", "proto",= and "protocol" (although "protocol" is used most frequ= ently).

=C2=A0

JSEP actually uses both profile and protocol to refe= r to the transport, depending on the section; if we make a change here, we = should hit all usages, which probably means that it is outside of the scope= of this particular issue.

=C2=A0

On Tue, Feb 19, 2019 at 1:19 PM Roman Shpount <roman@telurix.com&= gt; wrote:

Hi Justin,

=C2=A0

I did provide editorial feedback to the change on gi= thub:

=C2=A0

1. This document refers to SDP protocol as profile. = If you look at the referenced documents that define "profiles" in= JSEP, they all refer to them as protocols. Also, in case of SRTP, profile = is actually something different and refers to SRTP key parameters.

=C2=A0

2. Default candidate does not have profile (or proto= col), it has transport, port, and (connection-)address. So each "m=3D&= quot; and "c=3D" MUST be filled in with port, protocol, and addre= ss to match port, transport, and address of the default candidate for the m=3D section, as described in ice-sip-sdp.

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0

On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Looks good.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: rtcweb <rtcweb-bounces@ietf.org<= /a>> on behalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org>=
Date: Saturday, 16 February 2019 at 3.57
To: Ted Hardie <ted.ietf@gmail.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

I have updated this PR to incorporate minor feedback= that was received during the consensus call. Those who had feedback, pleas= e take another look and comment on the PR if you are satisfied.

=C2=A0

On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

The chairs believe that there was rough consensus am= ong those responding to make the change in:

=C2=A0

=C2=A0

Given the state of the document, it will be the Area= Director's call as to how much of the post-working group approval proc= ess must be re-done.=C2=A0 Authors, please wait on his direction before publishing a new version with this merged.

=C2=A0

Regards,

Ted and Sean

_______________________________________________
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

--00000000000007d4780582bba0dd-- From nobody Mon Feb 25 11:43:37 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6C812941A for ; Mon, 25 Feb 2019 11:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hXihcHfF; dkim=pass (1024-bit key) header.d=ericsson.com header.b=XcnXSWi2 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 Vj_BFzhv_kVm for ; Mon, 25 Feb 2019 11:43:31 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF15128CF2 for ; Mon, 25 Feb 2019 11:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551123808; x=1553715808; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OruybWlKBM8DpvRMaiVe5IoyrIsbjMeaqGk5UAdeKTc=; b=hXihcHfFHVhGwOJ/1mE3+yVSXrQ2wuZA3eEyQW6GHJ4njcIlbVWYdlshgi18waDg EF27ncg2Z3sBamlFotbP9M7ZmtBjWnzPblm6ugV4WhQ4FWcBhPWLjkI12s+eR1hV Jsw7II3nW1lF7lB9EkALsvHmIZu1vmqYegwQ7F6V4Yw=; X-AuditID: c1b4fb2d-db5ff7000000062f-6a-5c744560025b Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 48.62.01583.065447C5; Mon, 25 Feb 2019 20:43:28 +0100 (CET) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 25 Feb 2019 20:43:27 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 25 Feb 2019 20:43:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OruybWlKBM8DpvRMaiVe5IoyrIsbjMeaqGk5UAdeKTc=; b=XcnXSWi2zf19La2vk1dSjTSgxC1Ixwrga14bQnfFrpO88s/1218I87bZCujPWI5lXYD9J0rSnNiBea//4DlaqMtq19bfcLf7LWgEXvkVpS+gvglwsw7QvzvRUqJk54RgQMNZphqeZ9Ty4xHD6cLkPCcxrd+klAsp6FJes8BWl2I= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3468.eurprd07.prod.outlook.com (10.170.247.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.13; Mon, 25 Feb 2019 19:43:26 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1665.012; Mon, 25 Feb 2019 19:43:26 +0000 From: Christer Holmberg To: Justin Uberti CC: Roman Shpount , Ted Hardie , "RTCWeb IETF" Thread-Topic: [rtcweb] Results of call for consensus on ICE transport parameter issue Thread-Index: AQHUxYHCF4jGTlyGqkCBEfyt1ATxTKXhqseAgAYIbID///M5gIAFAbmAgANMu4CAAGGBAIAAhLWAgABALIA= Date: Mon, 25 Feb 2019 19:43:26 +0000 Message-ID: References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> <8C8AC253-4995-4FD8-B9A7-2E4F303B5153@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d0780ab-7bee-4da8-736b-08d69b5982c9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3468; x-ms-traffictypediagnostic: HE1PR07MB3468: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDY4OzIzOkRWVjdLdTJsSTFINmRqSDhrYW5jVjVmbHU5?= =?utf-8?B?V3BwdEdHYlFLalA3cW1xb2xxbThkRW81RHdNQU00eTg1aWU0UE05NXpRVitr?= =?utf-8?B?eHpmaDE1VTlFbWpZZU92aUZvRTN4OS9jcEROUFNGZE5WUnY2ZlRTSG96OW5y?= =?utf-8?B?bzNuVy83S3RCaWR6TWtZT043V1ZmbXYrbnJRQUpueTJTazZmMCtoeUc4dnVy?= =?utf-8?B?MEhJZzMxT3BGc0IwMlYwbDJvYVl1VTJmMkFISWV3cHBxNkhVSXM2bnpjeFFl?= =?utf-8?B?d3pIUUVKck8yL05aeEg0dzg0Nm8rMUVvb2xxZlhNNGpRMm9mdkNyL3dIL2tR?= =?utf-8?B?azFmdEZtUXF1aHhsL0NESE92VzlwRlJDcnZwenZ0cmZ5dldPSm5uUzNCMjZ6?= =?utf-8?B?c2R5LzlGQlpndlE3OTVLd2t3TjdhNlI5dk0vcUR3RHlNbS9qd2cySGVadTg1?= =?utf-8?B?RTlHaFlFMFNnb0s0aVFPQ1lVWDZPTEV1ajR2Ymw1NWFQVUVtQlZGT2JodFJJ?= =?utf-8?B?TTZVYUFLMkJrZjVXdlhZWVNvQlR4ajZ6amFDV1pkYWdzTHJQcDhUZm1pNGd1?= =?utf-8?B?YTdXSlN1a0FaMXNyejJXR3JES1BZN3JZQVEyOVltamhhZnAwMkp6UHVDbEMw?= =?utf-8?B?UUoxdW54eFVXVFN3OEQ5QkdGZzAxNnhQNTMrc0NOdkk3d3RicDNKWEp0OUIy?= =?utf-8?B?R3NIZXRPTnhsMmhPOGxFL1BRR0Jrc2FpUUU4SU52MElFQmIybWllTW5TR3lv?= =?utf-8?B?R0VGK3AxQ1JQNzc4WlRRNG5rNGQ5c2c2Wmw4SG9MZHI5UkVSbFNlZm0zTUFG?= =?utf-8?B?M3graXU0NXlDLzg5SWJkb3prRjJqRVJLU25MdW1BWmZmMWx4RjlZRjVMa3hT?= =?utf-8?B?ZHVDc2hZR2pReEtZdWNmdHFBOVRFdjNHSEVGMGdTT1NlQnFBeE5kUmdobjBK?= =?utf-8?B?SDA3anRlSk5NMndqYmUrTHphaDArd3FLUXhIOVZFMitzV0NNSzhSUWZCRHB3?= =?utf-8?B?TlVibUVNYnJ3YkRZYm1VZktabW9UOWFOZUlPenhITjRQZlZQL1BvSzMzNlVr?= =?utf-8?B?SmNWc25XaWtUQkVkbEx4NDY0Wkh6VnpFVGJxMFdBaC9HbEhBRVdGSS9rVUtk?= =?utf-8?B?cXNQQjZZa1ZJUENUdThrcjVhQVZ6VXpJejFRNTl1VVdiRHJ4Wll4ZExBaTdM?= =?utf-8?B?TlM4N1BscXhPQlpjalZtcC9RTWVHTzF6c1RZbzdRSHhCam9kQ2ovS0g4NHR5?= =?utf-8?B?UWNOUlVtTno1WFVLanRrY25LbWEwemI1ZkpDdWJzaUlOWVlNbjBPdmk5Q1A3?= =?utf-8?B?c0h5a1BwelpTeVIyaXJ4UzBsNjJ3UENjc09CZFNBUjRIaEFLbHBDT0dqVFdy?= =?utf-8?B?VkVNNHp0aVBwZ1UyY1o3Ympxcmd3VFhmYllYNTAvb25WdlVWZjIvK3BGZ1do?= =?utf-8?B?RnN0cksrQnRwcTFYWEJLc2RYV0NPcTNGMjd4YytNc3RONVhaRlpRbHJqTTRY?= =?utf-8?B?YXJ1eXowTXg0aFo0VnUvWVRnZ1R6YVliUVQzVTRuOUY4SkRhN21vR3dqWlB1?= =?utf-8?B?MU12Q1hwMVY0M0JERlNhbi90YnU5cGpQSnFRb1V4c2dDdHAxcnpDZTlNV3NE?= =?utf-8?B?bmdoRUVRQTVPOUZlS201Zkwxdm1TRXdpeVlqTFJlaWJoZWdTNWRVVVF6cjFN?= =?utf-8?B?MW9jUGNmc0dHWlM4VUZsUWVsdzhBdEFjZ1BtcytBNlRiMlpBZEJ5RXpoN3B3?= =?utf-8?B?SUpMRkJ1eTdPeTdpN29LUjlFNU1HckJxVWpPckNmbkFIQjF5WW1GVGh2YUlp?= =?utf-8?B?eUVpd05FR1UxTWFZUjVSemxhclZWdzI1UjlwMWJWQjlNaVl6WHpoTG81MHc2?= =?utf-8?Q?WD6SO3BTZvXYlpwjm6DV59tELVsV46V3?= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39860400002)(396003)(376002)(136003)(199004)(189003)(6486002)(5660300002)(26005)(82746002)(53936002)(86362001)(36756003)(6506007)(236005)(66066001)(81156014)(81166006)(4326008)(83716004)(53546011)(229853002)(6916009)(6116002)(3846002)(68736007)(6512007)(76176011)(186003)(6436002)(6306002)(6346003)(102836004)(33656002)(54896002)(478600001)(106356001)(105586002)(966005)(8936002)(71190400001)(71200400001)(11346002)(446003)(256004)(99286004)(476003)(2616005)(14454004)(486006)(44832011)(6246003)(93886005)(2906002)(58126008)(54906003)(7736002)(8676002)(316002)(97736004)(606006)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3468; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gYgeulDWXRgmikbXk1iCRdP7Nm9AVuiIqJ4OwyQ4i4Vpef7fZlyyklCpxxgFJAF8HpAHYA9ajp6BH13UFcIIDMB0L5fwmCSids2+zkOI3WXiI9/Yoq7+8ObUPNu7cr6DdqgRT/Szq4oPPY+EtECWJNb+S/IBUvLbho7JFBK9JBgrHSTiQ/dopJ2SJPJ8qtZRflV1kiXADbJ29yNvmoZXwZp7YWI0hLtr0qnlYEQWkx7P4DmkXntDhP5TbXo4hD2KbblR60admeKvYnA7tTLaDqr3p/iI3TLbt1erLylWUVGe2sCPP1Q7CwQUfgs5l+nhwcHsW8fARG7/ie/jkMFC+TgqK6tmGkaQH6c/LbKnF8iNDKeBlpiAXvSviJUpBHUH3nnwhQ6ZYgA2/oGwLcZ76k9SXIOVewynULvgBhRIaAI= Content-Type: multipart/alternative; boundary="_000_E7496DAB784644B48C58FA3BB5D55BC6ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8d0780ab-7bee-4da8-736b-08d69b5982c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 19:43:26.7438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3468 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHO7t323U1PV41nzQhV0kZaq+2QswoYVBCEZSIlEtvOtRNdldo 9MGgN7cKi5lt+FYuJJ1JNm3LslILil6WIywlci8UJVpEKSOznGeB337n/H/nPOd5OAzFPhHG MCq1jtOqlSUykYQ2Zd/VJeVl6nLXVj1dJe+qYeVXnTWUvH3mrFh+sj49g1Y4zB/EiqbOowqL xS9QDBvL9tA5krQCrkR1jNOmpOdJis73OEVl3z+h8raWBlSJvKNIj0IYwBvhfL9JqEcShsUD CM79bKECAYsnEXQ/V5HAIoCO+jo6sKBxNQWVf2w0SYwC6G320+SIB8F4V4QeMYwIy8Ewsyaw HYkTwG2+JwwwhVXgG/w4xxF4P7i8vYg4B8BXPyMkfBhGr58RBZjGK2Go//McS/E2MN0xBes2 0tBueCXWIzETgveCMyOgILwYpp5bBaRUNAz7GgWkSwyW+68pwlHwxUtKReEUsF0cpcl+PLyc cAf9OBhsNAQnlAX2V465CQF+j6D6lE9IgkRw1N4UE46Ba69/ionkZaFr6lZQKgan0RW8dSn8 uG0VEalWBA9crYJqlGye91rC+TDUbaDMc02HwzOTjzbPzpTCq6HjXgpR4sFocIsJr4LTdfVB VoDnxiV6vtOEmFYUxXM8X1q4fkMyp1Xl87xGnazmdJ1o9nM9tv1OsqO2se19CDNItkiatlOX ywqVx/iK0j4EDCWLlB78xuey0gJlxXFOqzmkPVrC8X0olqFl0dJpNjyXxYVKHVfMcWWc9n8q YEJiKtGmv1cW2e1hmvxpTVhbTdWvrVmXl/tHQgvKl4btTtrVeqIhbEXV5Lu3qCbCYCsWRLmX xK3h3mROpu77OuUxazqLPLH+ZKPNPm51Utl9CQODD8cdo6EWxQIXt2VLxTLv8JHBFxfGPQtz NjdYJT/yFuwoSOVGenrOTjSPWUN6cvSPZDRfpFyXSGl55T/pyAZhWAMAAA== Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 19:43:36 -0000 --_000_E7496DAB784644B48C58FA3BB5D55BC6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gbm90IHN1cmUgd2hhdCBvdGhlciBkb2N1bWVudCB5b3UgcmVmZXIgdG8sIGJ1 dCBpdCByZWFsbHkgZGVwZW5kcyBvbiB3aGF0IHRoZSB0ZXh0IGlzIHRhbGtpbmcgYWJvdXQ6IHRo ZSBzZW1hbnRpY3Mgb2YgdGhlIDxwcm90bz4gZmllbGQsIHdoaWNoIGlzIGEgdHJhbnNwb3J0IHBy b3RvY29sLCBvciB3aGF0ZXZlciBpcyB1c2VkIGFzIGEgdHJhbnNwb3J0IHByb3RvY29sIChlLmcu LCBhbiBSVFAgcHJvZmlsZSkuDQoNCkhhdmluZyBzYWlkIHRoYXQsIEkgYW0gYXdhcmUgdGhhdCBk b2N1bWVudHMgdW5mb3J0dW5hdGVseSBkb27igJl0IHVzZSBjb25zaXN0ZW50IHRlcm1pbm9sb2d5 LCBzbyBJIHdvdWxkbuKAmXQgYmUgc3VycHJpc2VkIGlmIHRoZSA0NTY2YmlzIHRlcm1pbm9sb2d5 IGlzbuKAmXQgdXNlZCBldmVyeXdoZXJlIChhbHNvLCB0aGVyZSBoYXZlIGJlZW4gZGlzY3Vzc2lv bnMgYWJvdXQgdGhlIDQ1NjZiaXMgdGVybWlub2xvZ3kgaXRzZWxm4oCmKS4NCg0KTXkgcGVyc29u YWwgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBiZSBhbGlnbmVkIHdpdGggNDU2NmJpcywgYnV0IGFz IGxvbmcgYXMgd2UgYXJlIGNvbnNpc3RlbnQgd2l0aGluIEpTRVAgSSBjYW4gbGl2ZSB3aXRoIGl0 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IEp1c3RpbiBVYmVydGkgPGp1YmVy dGlAZ29vZ2xlLmNvbT4NCkRhdGU6IE1vbmRheSwgMjUgRmVicnVhcnkgMjAxOSBhdCAxOS41NA0K VG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpD YzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+LCBUZWQgSGFyZGllIDx0ZWQuaWV0 ZkBnbWFpbC5jb20+LCAicnRjd2ViQGlldGYub3JnIiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtydGN3ZWJdIFJlc3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFu c3BvcnQgcGFyYW1ldGVyIGlzc3VlDQoNClN1cmUsIGJ1dCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNl IHRvIHVzZSB0aGUgc2FtZSB0ZXJtaW5vbG9neSAoaS5lLiwgInByb2ZpbGUiKSBhcyBpcyB1c2Vk IGluIG90aGVyIFJUUC1yZWxhdGVkIGRvY3VtZW50cy4NCg0KT24gU3VuLCBGZWIgMjQsIDIwMTkg YXQgMTE6NTggUE0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwN Cg0KSW4gNDU2NmJpcywgPHByb3RvPiBkZWZpbmVzIGEgdHJhbnNwb3J0IHByb3RvY29sLg0KDQpJ biBjYXNlIG9mIFJUUCwgdGhlIHRleHQgcmVmZXJzIHRvIFJUUC9BVlAgYXMgYW4g4oCcUlRQIHBy b2ZpbGXigJ0sIGJ1dCBpdCBpcyBzdGlsbCBhIHRyYW5zcG9ydCBwcm90b2NvbC4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29t PG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+Pg0KRGF0ZTogTW9uZGF5LCAyNSBGZWJydWFyeSAy MDE5IGF0IDYuMTANClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20+Pg0KQ2M6IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbTxt YWlsdG86dGVkLmlldGZAZ21haWwuY29tPj4sICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZz4iIDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+LCBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFJl c3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFyYW1ldGVyIGlz c3VlDQoNCkZvdW5kIGEgd2F5IHRvIGFkZHJlc3MgdGhpcyB3aXRoIG1pbm9yIGNoYW5nZXMgdG8g dGhlIGV4aXN0aW5nIFBSLg0KDQpPbiBGcmksIEZlYiAyMiwgMjAxOSBhdCA1OjQ2IFBNIEp1c3Rp biBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4g d3JvdGU6DQpSb21hbiwgdGhhbmtzIGZvciByYWlzaW5nIHRoaXMuIEkgbG9va2VkIGludG8gdGhp cyBhIGJpdCBhbmQgaXQncyBraW5kIG9mIGFtYmlndW91czsgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzc4NTAgdXNlcyAicHJvZmlsZSIsICJwcm90byIsIGFuZCAicHJvdG9jb2wiIChh bHRob3VnaCAicHJvdG9jb2wiIGlzIHVzZWQgbW9zdCBmcmVxdWVudGx5KS4NCg0KSlNFUCBhY3R1 YWxseSB1c2VzIGJvdGggcHJvZmlsZSBhbmQgcHJvdG9jb2wgdG8gcmVmZXIgdG8gdGhlIHRyYW5z cG9ydCwgZGVwZW5kaW5nIG9uIHRoZSBzZWN0aW9uOyBpZiB3ZSBtYWtlIGEgY2hhbmdlIGhlcmUs IHdlIHNob3VsZCBoaXQgYWxsIHVzYWdlcywgd2hpY2ggcHJvYmFibHkgbWVhbnMgdGhhdCBpdCBp cyBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGlzIHBhcnRpY3VsYXIgaXNzdWUuDQoNCk9uIFR1 ZSwgRmViIDE5LCAyMDE5IGF0IDE6MTkgUE0gUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5j b208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQpIaSBKdXN0aW4sDQoNCkkgZGlk IHByb3ZpZGUgZWRpdG9yaWFsIGZlZWRiYWNrIHRvIHRoZSBjaGFuZ2Ugb24gZ2l0aHViOg0KDQox LiBUaGlzIGRvY3VtZW50IHJlZmVycyB0byBTRFAgcHJvdG9jb2wgYXMgcHJvZmlsZS4gSWYgeW91 IGxvb2sgYXQgdGhlIHJlZmVyZW5jZWQgZG9jdW1lbnRzIHRoYXQgZGVmaW5lICJwcm9maWxlcyIg aW4gSlNFUCwgdGhleSBhbGwgcmVmZXIgdG8gdGhlbSBhcyBwcm90b2NvbHMuIEFsc28sIGluIGNh c2Ugb2YgU1JUUCwgcHJvZmlsZSBpcyBhY3R1YWxseSBzb21ldGhpbmcgZGlmZmVyZW50IGFuZCBy ZWZlcnMgdG8gU1JUUCBrZXkgcGFyYW1ldGVycy4NCg0KMi4gRGVmYXVsdCBjYW5kaWRhdGUgZG9l cyBub3QgaGF2ZSBwcm9maWxlIChvciBwcm90b2NvbCksIGl0IGhhcyB0cmFuc3BvcnQsIHBvcnQs IGFuZCAoY29ubmVjdGlvbi0pYWRkcmVzcy4gU28gZWFjaCAibT0iIGFuZCAiYz0iIE1VU1QgYmUg ZmlsbGVkIGluIHdpdGggcG9ydCwgcHJvdG9jb2wsIGFuZCBhZGRyZXNzIHRvIG1hdGNoIHBvcnQs IHRyYW5zcG9ydCwgYW5kIGFkZHJlc3Mgb2YgdGhlIGRlZmF1bHQgY2FuZGlkYXRlIGZvciB0aGUg bT0gc2VjdGlvbiwgYXMgZGVzY3JpYmVkIGluIGljZS1zaXAtc2RwLg0KDQpSZWdhcmRzLA0KX19f X19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQoNCk9uIFR1ZSwgRmViIDE5LCAyMDE5IGF0IDM6 MDUgUE0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpMb29rcyBnb29k Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBydGN3ZWIgPHJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBK dXN0aW4gVWJlcnRpIDxqdWJlcnRpPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86 NDBnb29nbGUuLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBTYXR1cmRheSwgMTYgRmVicnVh cnkgMjAxOSBhdCAzLjU3DQpUbzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0 bzp0ZWQuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6ICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZz4iIDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW3J0Y3dlYl0gUmVzdWx0cyBvZiBjYWxsIGZvciBjb25zZW5zdXMgb24gSUNF IHRyYW5zcG9ydCBwYXJhbWV0ZXIgaXNzdWUNCg0KSSBoYXZlIHVwZGF0ZWQgdGhpcyBQUiB0byBp bmNvcnBvcmF0ZSBtaW5vciBmZWVkYmFjayB0aGF0IHdhcyByZWNlaXZlZCBkdXJpbmcgdGhlIGNv bnNlbnN1cyBjYWxsLiBUaG9zZSB3aG8gaGFkIGZlZWRiYWNrLCBwbGVhc2UgdGFrZSBhbm90aGVy IGxvb2sgYW5kIGNvbW1lbnQgb24gdGhlIFBSIGlmIHlvdSBhcmUgc2F0aXNmaWVkLg0KDQpPbiBG cmksIEZlYiAxNSwgMjAxOSBhdCAyOjU2IFBNIFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNv bTxtYWlsdG86dGVkLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpUaGUgY2hhaXJzIGJlbGlldmUg dGhhdCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGFtb25nIHRob3NlIHJlc3BvbmRpbmcgdG8g bWFrZSB0aGUgY2hhbmdlIGluOg0KDQpodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAv cHVsbC84NjMNCg0KR2l2ZW4gdGhlIHN0YXRlIG9mIHRoZSBkb2N1bWVudCwgaXQgd2lsbCBiZSB0 aGUgQXJlYSBEaXJlY3RvcidzIGNhbGwgYXMgdG8gaG93IG11Y2ggb2YgdGhlIHBvc3Qtd29ya2lu ZyBncm91cCBhcHByb3ZhbCBwcm9jZXNzIG11c3QgYmUgcmUtZG9uZS4gIEF1dGhvcnMsIHBsZWFz ZSB3YWl0IG9uIGhpcyBkaXJlY3Rpb24gYmVmb3JlIHB1Ymxpc2hpbmcgYSBuZXcgdmVyc2lvbiB3 aXRoIHRoaXMgbWVyZ2VkLg0KDQpSZWdhcmRzLA0KVGVkIGFuZCBTZWFuDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0K cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWINCg== --_000_E7496DAB784644B48C58FA3BB5D55BC6ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkkgYW0gbm90IHN1cmUgd2hhdCBvdGhlciBkb2N1bWVudCB5b3UgcmVmZXIgdG8sIGJ1dCBp dCByZWFsbHkgZGVwZW5kcyBvbiB3aGF0IHRoZSB0ZXh0IGlzIHRhbGtpbmcgYWJvdXQ6IHRoZSBz ZW1hbnRpY3Mgb2YgdGhlICZsdDtwcm90byZndDsgZmllbGQsIHdoaWNoIGlzIGEgdHJhbnNwb3J0 IHByb3RvY29sLCBvciB3aGF0ZXZlciBpcyB1c2VkIGFzIGEgdHJhbnNwb3J0IHByb3RvY29sIChl LmcuLA0KIGFuIFJUUCBwcm9maWxlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhhdmluZyBzYWlkIHRo YXQsIEkgYW0gYXdhcmUgdGhhdCBkb2N1bWVudHMgdW5mb3J0dW5hdGVseSBkb27igJl0IHVzZSBj b25zaXN0ZW50IHRlcm1pbm9sb2d5LCBzbyBJIHdvdWxkbuKAmXQgYmUgc3VycHJpc2VkIGlmIHRo ZSA0NTY2YmlzIHRlcm1pbm9sb2d5IGlzbuKAmXQgdXNlZCBldmVyeXdoZXJlIChhbHNvLCB0aGVy ZSBoYXZlIGJlZW4gZGlzY3Vzc2lvbnMgYWJvdXQgdGhlIDQ1NjZiaXMNCiB0ZXJtaW5vbG9neSBp dHNlbGbigKYpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk15IHBlcnNvbmFsIHByZWZlcmVuY2Ugd291 bGQgYmUgdG8gYmUgYWxpZ25lZCB3aXRoIDQ1NjZiaXMsIGJ1dCBhcyBsb25nIGFzIHdlIGFyZSBj b25zaXN0ZW50IHdpdGhpbiBKU0VQIEkgY2FuIGxpdmUgd2l0aCBpdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkp1c3RpbiBVYmVydGkgJmx0O2p1YmVydGlAZ29vZ2xlLmNvbSZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCAyNSBGZWJydWFyeSAyMDE5IGF0IDE5LjU0PGJyPg0K PGI+VG86IDwvYj5DaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+Um9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJp eC5jb20mZ3Q7LCBUZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7LCAmcXVvdDty dGN3ZWJAaWV0Zi5vcmcmcXVvdDsgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+UmU6IFtydGN3ZWJdIFJlc3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElD RSB0cmFuc3BvcnQgcGFyYW1ldGVyIGlzc3VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJlLCBidXQgSSB0aGluayBpdCBtYWtl cyBzZW5zZSB0byB1c2UgdGhlIHNhbWUgdGVybWlub2xvZ3kgKGkuZS4sICZxdW90O3Byb2ZpbGUm cXVvdDspIGFzIGlzIHVzZWQgaW4gb3RoZXIgUlRQLXJlbGF0ZWQgZG9jdW1lbnRzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBGZWIgMjQsIDIw MTkgYXQgMTE6NTggUE0gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiA0NTY2YmlzLCAmbHQ7cHJvdG8mZ3Q7IGRlZmluZXMg YSB0cmFuc3BvcnQgcHJvdG9jb2wuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SW4gY2FzZSBvZiBS VFAsIHRoZSB0ZXh0IHJlZmVycyB0byBSVFAvQVZQIGFzIGFuIOKAnFJUUCBwcm9maWxl4oCdLCBi dXQgaXQgaXMgc3RpbGwgYSB0cmFuc3BvcnQgcHJvdG9jb2wuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5KdXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+TW9uZGF5LCAyNSBGZWJydWFyeSAyMDE5IGF0IDYuMTA8YnI+DQo8Yj5Ubzog PC9iPlJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9i PlRlZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFp bHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5ydGN3ZWJAaWV0Zi5vcmc8L2E+Jmd0OywgQ2hyaXN0ZXIgSG9sbWJlcmcNCiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbcnRjd2ViXSBSZXN1bHRzIG9mIGNhbGwgZm9yIGNvbnNlbnN1cyBvbiBJQ0UgdHJh bnNwb3J0IHBhcmFtZXRlciBpc3N1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvdW5kIGEgd2F5IHRvIGFkZHJlc3MgdGhp cyB3aXRoIG1pbm9yIGNoYW5nZXMgdG8gdGhlIGV4aXN0aW5nIFBSLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDIyLCAyMDE5IGF0 IDU6NDYgUE0gSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Sb21h biwgdGhhbmtzIGZvciByYWlzaW5nIHRoaXMuIEkgbG9va2VkIGludG8gdGhpcyBhIGJpdCBhbmQg aXQncyBraW5kIG9mIGFtYmlndW91czsNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3ODUwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc4NTA8L2E+IHVzZXMgJnF1b3Q7cHJvZmlsZSZxdW90OywgJnF1b3Q7cHJvdG8mcXVvdDss IGFuZCAmcXVvdDtwcm90b2NvbCZxdW90OyAoYWx0aG91Z2ggJnF1b3Q7cHJvdG9jb2wmcXVvdDsg aXMgdXNlZCBtb3N0IGZyZXF1ZW50bHkpLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SlNFUCBhY3R1YWxseSB1c2VzIGJvdGggcHJvZmlsZSBhbmQg cHJvdG9jb2wgdG8gcmVmZXIgdG8gdGhlIHRyYW5zcG9ydCwgZGVwZW5kaW5nIG9uIHRoZSBzZWN0 aW9uOyBpZiB3ZSBtYWtlIGEgY2hhbmdlIGhlcmUsIHdlIHNob3VsZCBoaXQgYWxsIHVzYWdlcywg d2hpY2ggcHJvYmFibHkgbWVhbnMgdGhhdCBpdA0KIGlzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9m IHRoaXMgcGFydGljdWxhciBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTksIDIwMTkgYXQg MToxOSBQTSBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5j b20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBKdXN0 aW4sDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J IGRpZCBwcm92aWRlIGVkaXRvcmlhbCBmZWVkYmFjayB0byB0aGUgY2hhbmdlIG9uIGdpdGh1Yjo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4xLiBUaGlzIGRvY3VtZW50IHJlZmVycyB0byBTRFAgcHJvdG9jb2wgYXMgcHJvZmls ZS4gSWYgeW91IGxvb2sgYXQgdGhlIHJlZmVyZW5jZWQgZG9jdW1lbnRzIHRoYXQgZGVmaW5lICZx dW90O3Byb2ZpbGVzJnF1b3Q7IGluIEpTRVAsIHRoZXkgYWxsIHJlZmVyIHRvIHRoZW0gYXMgcHJv dG9jb2xzLiBBbHNvLCBpbiBjYXNlIG9mDQogU1JUUCwgcHJvZmlsZSBpcyBhY3R1YWxseSBzb21l dGhpbmcgZGlmZmVyZW50IGFuZCByZWZlcnMgdG8gU1JUUCBrZXkgcGFyYW1ldGVycy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuIERl ZmF1bHQgY2FuZGlkYXRlIGRvZXMgbm90IGhhdmUgcHJvZmlsZSAob3IgcHJvdG9jb2wpLCBpdCBo YXMgdHJhbnNwb3J0LCBwb3J0LCBhbmQgKGNvbm5lY3Rpb24tKWFkZHJlc3MuIFNvIGVhY2ggJnF1 b3Q7bT0mcXVvdDsgYW5kICZxdW90O2M9JnF1b3Q7IE1VU1QgYmUgZmlsbGVkIGluIHdpdGggcG9y dCwgcHJvdG9jb2wsIGFuZCBhZGRyZXNzDQogdG8gbWF0Y2ggcG9ydCwgdHJhbnNwb3J0LCBhbmQg YWRkcmVzcyBvZiB0aGUgZGVmYXVsdCBjYW5kaWRhdGUgZm9yIHRoZSBtPSBzZWN0aW9uLCBhcyBk ZXNjcmliZWQgaW4gaWNlLXNpcC1zZHAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fXzxicj4N ClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxOSwgMjAxOSBhdCAzOjA1 IFBNIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkxvb2tzIGdvb2QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hyaXN0ZXI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+cnRjd2ViICZsdDs8YSBocmVm PSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBKdXN0aW4gVWJlcnRpICZsdDtq dWJlcnRpPTxhIGhyZWY9Im1haWx0bzo0MGdvb2dsZS4uY29tQGRtYXJjLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+U2F0dXJkYXksIDE2IEZlYnJ1YXJ5IDIwMTkgYXQgMy41Nzxicj4NCjxiPlRvOiA8 L2I+VGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4m cXVvdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRj d2ViQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbcnRjd2ViXSBSZXN1bHRzIG9mIGNhbGwgZm9yIGNvbnNlbnN1cyBvbiBJQ0Ug dHJhbnNwb3J0IHBhcmFtZXRlciBpc3N1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSB1cGRhdGVkIHRoaXMgUFIg dG8gaW5jb3Jwb3JhdGUgbWlub3IgZmVlZGJhY2sgdGhhdCB3YXMgcmVjZWl2ZWQgZHVyaW5nIHRo ZSBjb25zZW5zdXMgY2FsbC4gVGhvc2Ugd2hvIGhhZCBmZWVkYmFjaywgcGxlYXNlIHRha2UgYW5v dGhlciBsb29rIGFuZCBjb21tZW50IG9uIHRoZSBQUiBpZiB5b3UgYXJlDQogc2F0aXNmaWVkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwg RmViIDE1LCAyMDE5IGF0IDI6NTYgUE0gVGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRl ZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGNoYWlycyBiZWxpZXZlIHRoYXQgdGhlcmUgd2Fz IHJvdWdoIGNvbnNlbnN1cyBhbW9uZyB0aG9zZSByZXNwb25kaW5nIHRvIG1ha2UgdGhlIGNoYW5n ZSBpbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9wdWxsLzg2 MyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvanNlcC9wdWxs Lzg2MzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkdpdmVuIHRoZSBzdGF0ZSBvZiB0aGUgZG9jdW1lbnQsIGl0IHdpbGwgYmUgdGhl IEFyZWEgRGlyZWN0b3IncyBjYWxsIGFzIHRvIGhvdyBtdWNoIG9mIHRoZSBwb3N0LXdvcmtpbmcg Z3JvdXAgYXBwcm92YWwgcHJvY2VzcyBtdXN0IGJlIHJlLWRvbmUuJm5ic3A7IEF1dGhvcnMsIHBs ZWFzZSB3YWl0IG9uIGhpcyBkaXJlY3Rpb24NCiBiZWZvcmUgcHVibGlzaGluZyBhIG5ldyB2ZXJz aW9uIHdpdGggdGhpcyBtZXJnZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UZWQgYW5kIFNlYW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpydGN3ZWIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dl YiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E7496DAB784644B48C58FA3BB5D55BC6ericssoncom_-- From nobody Mon Feb 25 11:56:10 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38049130E7A for ; Mon, 25 Feb 2019 11:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc_-joluWULn for ; Mon, 25 Feb 2019 11:56:06 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 A37F8129A85 for ; Mon, 25 Feb 2019 11:56:05 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id f186so620671ita.0 for ; Mon, 25 Feb 2019 11:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=krFnf0UP6nkuJkaei0POJxdKt/xcGdZ6OY5jffPeJ1s=; b=KqE2eqbxmWOb9zkvdvh+zQJv4asQFXJ8mgXOAZCmW1CwFMA2t8ozYV9wFZNP3zOfAC nPt92zhY+nWkTdNiZcgR9IGfgANFPlP3TQfLZkhI1wtx8/tAr0H+EYgKbQnlie1K0Wzq lW3W5IBCk4yHmEPiA0Dh1QUdRkxkxiELxqkg5SPodUTmpsfUQVxzmYa5kOCzartwJP6u 5yclUPooMisZqkbqMpFL+qSsIxmFAy1JSX5Oji2/pCttDJl9pnLywexgAhs6NscGl9Q4 GwjF64koGT+T7Ux2c9bwXQoIeqmLRfYAN0PSRvZa4IlCOUxj4FBZRvpFsLglTlL2YldR AUyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=krFnf0UP6nkuJkaei0POJxdKt/xcGdZ6OY5jffPeJ1s=; b=GeJlucBCmfP3FCb4Bw4cTK0ZUbsJZ8KxFujfkFBGKzJMENu9VS4yHW/dYeWWEsajOO FaJ3Ii1JSphBaqUMCwXwaUO6YNoaV+Gny337Ye8vMb2HjPJPI4N146mvaQtaNwOKg07J lg7jPYkK+6KEMTJRZEhy0vAPffE97jsV5S2drCb3esd9tLU5I8qPW9RxJgr/J/dNHAZC tNTsRxYp5koS8FLF7zjEFgvb2b2WUxAiVYk4VTw8XDnhUd3+aHS/g6RsbqDzG9rMbvXr gqcvdMyjG1Ww3dHyd7p+x03RXCaeXnh7+LveNQ8WgihcmjlSg5fG+aJYeL8U4kDqgdZQ a83w== X-Gm-Message-State: AHQUAuY3ucENOJGpy/u4IjUH1XA9oWrXyPEWhTr3eQI+KwzcwhUONgvX oMQsbRiDG0KGjur5mu3eoQDpXPgWdlfinFepdZJvIw== X-Google-Smtp-Source: AHgI3IYNc5OsJAGdAuRQp22Nr7Ynu7lcxegxhA18BUMZkM569mV5AP2F5NKlIq2fNOZ0S+aeD0XRC3MuS/nuF3h3Ihw= X-Received: by 2002:a02:1d6:: with SMTP id 83mr10814101jak.29.1551124564393; Mon, 25 Feb 2019 11:56:04 -0800 (PST) MIME-Version: 1.0 References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> <8C8AC253-4995-4FD8-B9A7-2E4F303B5153@ericsson.com> In-Reply-To: From: Justin Uberti Date: Mon, 25 Feb 2019 11:55:52 -0800 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Ted Hardie , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000aa32700582bd5494" Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 19:56:09 -0000 --000000000000aa32700582bd5494 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the current PR makes JSEP internally consistent. On Mon, Feb 25, 2019 at 11:43 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I am not sure what other document you refer to, but it really depends on > what the text is talking about: the semantics of the field, which > is a transport protocol, or whatever is used as a transport protocol (e.g= ., > an RTP profile). > > > > Having said that, I am aware that documents unfortunately don=E2=80=99t u= se > consistent terminology, so I wouldn=E2=80=99t be surprised if the 4566bis > terminology isn=E2=80=99t used everywhere (also, there have been discussi= ons about > the 4566bis terminology itself=E2=80=A6). > > > > My personal preference would be to be aligned with 4566bis, but as long a= s > we are consistent within JSEP I can live with it. > > > > Regards, > > > > Christer > > > > > > *From: *Justin Uberti > *Date: *Monday, 25 February 2019 at 19.54 > *To: *Christer Holmberg > *Cc: *Roman Shpount , Ted Hardie , > "rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport > parameter issue > > > > Sure, but I think it makes sense to use the same terminology (i.e., > "profile") as is used in other RTP-related documents. > > > > On Sun, Feb 24, 2019 at 11:58 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > In 4566bis, defines a transport protocol. > > > > In case of RTP, the text refers to RTP/AVP as an =E2=80=9CRTP profile=E2= =80=9D, but it is > still a transport protocol. > > > > Regards, > > > > Christer > > > > *From: *Justin Uberti > *Date: *Monday, 25 February 2019 at 6.10 > *To: *Roman Shpount > *Cc: *Ted Hardie , "rtcweb@ietf.org" , > Christer Holmberg > *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport > parameter issue > > > > Found a way to address this with minor changes to the existing PR. > > > > On Fri, Feb 22, 2019 at 5:46 PM Justin Uberti wrote: > > Roman, thanks for raising this. I looked into this a bit and it's kind of > ambiguous; https://tools.ietf.org/html/rfc7850 uses "profile", "proto", > and "protocol" (although "protocol" is used most frequently). > > > > JSEP actually uses both profile and protocol to refer to the transport, > depending on the section; if we make a change here, we should hit all > usages, which probably means that it is outside of the scope of this > particular issue. > > > > On Tue, Feb 19, 2019 at 1:19 PM Roman Shpount wrote: > > Hi Justin, > > > > I did provide editorial feedback to the change on github: > > > > 1. This document refers to SDP protocol as profile. If you look at the > referenced documents that define "profiles" in JSEP, they all refer to th= em > as protocols. Also, in case of SRTP, profile is actually something > different and refers to SRTP key parameters. > > > > 2. Default candidate does not have profile (or protocol), it has > transport, port, and (connection-)address. So each "m=3D" and "c=3D" MUST= be > filled in with port, protocol, and address to match port, transport, and > address of the default candidate for the m=3D section, as described in > ice-sip-sdp. > > > > Regards, > > _____________ > Roman Shpount > > > > > > On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Looks good. > > > > Regards, > > > > Christer > > > > *From: *rtcweb on behalf of Justin Uberti > > > *Date: *Saturday, 16 February 2019 at 3.57 > *To: *Ted Hardie > *Cc: *"rtcweb@ietf.org" > *Subject: *Re: [rtcweb] Results of call for consensus on ICE transport > parameter issue > > > > I have updated this PR to incorporate minor feedback that was received > during the consensus call. Those who had feedback, please take another lo= ok > and comment on the PR if you are satisfied. > > > > On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie wrote: > > The chairs believe that there was rough consensus among those responding > to make the change in: > > > > https://github.com/rtcweb-wg/jsep/pull/863 > > > > Given the state of the document, it will be the Area Director's call as t= o > how much of the post-working group approval process must be re-done. > Authors, please wait on his direction before publishing a new version wit= h > this merged. > > > > Regards, > > Ted and Sean > > _______________________________________________ > 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 > > --000000000000aa32700582bd5494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the current PR makes JSEP internally consistent.=

= On Mon, Feb 25, 2019 at 11:43 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:=

Hi,

=C2=A0

I am not sure what other docume= nt you refer to, but it really depends on what the text is talking about: t= he semantics of the <proto> field, which is a transport protocol, or = whatever is used as a transport protocol (e.g., an RTP profile).

=C2=A0

Having said that, I am aware th= at documents unfortunately don=E2=80=99t use consistent terminology, so I w= ouldn=E2=80=99t be surprised if the 4566bis terminology isn=E2=80=99t used = everywhere (also, there have been discussions about the 4566bis terminology itself=E2=80=A6).

=C2=A0

My personal preference would be= to be aligned with 4566bis, but as long as we are consistent within JSEP I= can live with it.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = Justin Uberti <juberti@google.com= >
Date: Monday, 25 February 2019 at 19.54
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Roman Shpount <roman@telurix.com>, Ted Hardie <ted.ietf@gmail.com>, "rtcweb@ietf.org" <= ;rtcweb@ietf.org&g= t;
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

Sure, but I think it makes sense to use the same ter= minology (i.e., "profile") as is used in other RTP-related docume= nts.

=C2=A0

On Sun, Feb 24, 2019 at 11:58 PM Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

In 4566bis, <proto> defin= es a transport protocol.

=C2=A0

In case of RTP, the text refers= to RTP/AVP as an =E2=80=9CRTP profile=E2=80=9D, but it is still a transpor= t protocol.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: Justin Uberti <juberti@google.com= >
Date: Monday, 25 February 2019 at 6.10
To: Roman Shpount <roman@telurix.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, Christer Holmberg <ch= rister.holmberg@ericsson.com>
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

Found a way to address this with minor changes to th= e existing PR.

=C2=A0

On Fri, Feb 22, 2019 at 5:46 PM Justin Uberti <juberti@google.com> wrote:

Roman, thanks for raising this. I looked into this a= bit and it's kind of ambiguous; https://t= ools.ietf.org/html/rfc7850 uses "profile", "proto",= and "protocol" (although "protocol" is used most frequ= ently).

=C2=A0

JSEP actually uses both profile and protocol to refe= r to the transport, depending on the section; if we make a change here, we = should hit all usages, which probably means that it is outside of the scope of this particular issue.

=C2=A0

On Tue, Feb 19, 2019 at 1:19 PM Roman Shpount <roman@telurix.com&= gt; wrote:

Hi Justin,

=C2=A0

I did provide editorial feedback to the change on gi= thub:

=C2=A0

1. This document refers to SDP protocol as profile. = If you look at the referenced documents that define "profiles" in= JSEP, they all refer to them as protocols. Also, in case of SRTP, profile is actually something different and refers to SRTP key param= eters.

=C2=A0

2. Default candidate does not have profile (or proto= col), it has transport, port, and (connection-)address. So each "m=3D&= quot; and "c=3D" MUST be filled in with port, protocol, and addre= ss to match port, transport, and address of the default candidate for the m= =3D section, as described in ice-sip-sdp.

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0

On Tue, Feb 19, 2019 at 3:05 PM Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Looks good.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: rtcweb <rtcweb-bounces@ietf.org<= /a>> on behalf of Justin Uberti <juberti=3D40google.com@dmarc.ietf.org>=
Date: Saturday, 16 February 2019 at 3.57
To: Ted Hardie <ted.ietf@gmail.com>
Cc: "rtcwe= b@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Results of call for consensus on ICE transport= parameter issue

=C2=A0

I have updated this PR to incorporate minor feedback= that was received during the consensus call. Those who had feedback, pleas= e take another look and comment on the PR if you are satisfied.

=C2=A0

On Fri, Feb 15, 2019 at 2:56 PM Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

The chairs believe that there was rough consensus am= ong those responding to make the change in:

=C2=A0

=C2=A0

Given the state of the document, it will be the Area= Director's call as to how much of the post-working group approval proc= ess must be re-done.=C2=A0 Authors, please wait on his direction before publishing a new version with this merged.

=C2=A0

Regards,

Ted and Sean

_______________________________________________
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

--000000000000aa32700582bd5494-- From nobody Mon Feb 25 12:04:14 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EC312D7F8 for ; Mon, 25 Feb 2019 12:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=U1uxdF/l; dkim=pass (1024-bit key) header.d=ericsson.com header.b=AfvWOF7Y 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 gnB4-ekB3gNU for ; Mon, 25 Feb 2019 12:04:07 -0800 (PST) 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 1C1A6129A85 for ; Mon, 25 Feb 2019 12:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551125045; x=1553717045; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EA3hrCIRlYf1qhncMbiwFruuospH3Dz4cx00MKm03wQ=; b=U1uxdF/lZwm7MNgEjZCr+Wnz5KQwSwsa0Y4p6av9+eqS++/53F4sFNwgt6GFIPz8 obst5q/IEdg+6Z6D9HnbSiuymu1GmZp6neBbqKEIpJU6uAc41lc8b2un+oJstYNq AIScWeOVui91ghb1kIYKivhQbrtMnN7NKkM8maWQ8l0=; X-AuditID: c1b4fb3a-5c9c29e00000672c-55-5c744a35a186 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.FD.26412.53A447C5; Mon, 25 Feb 2019 21:04:05 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 25 Feb 2019 21:03:59 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 25 Feb 2019 21:03:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EA3hrCIRlYf1qhncMbiwFruuospH3Dz4cx00MKm03wQ=; b=AfvWOF7YOjrVfg1W7ZTCs7eQL1ymhVf3Es7pGfjH8KXGNzITP8YFWRPq4/w3GVAD1fr0x77ZKn7f3J0vabKc22MVbUzFKDncF6Uxsq4fhtKTLCobk/0CKuKIoPrv5gRrA+1lh4mzadkYRx0B1Tjj0Hgjho0O4OHqOq5Rf+i+JhU= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4441.eurprd07.prod.outlook.com (20.176.167.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.13; Mon, 25 Feb 2019 20:03:58 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1665.012; Mon, 25 Feb 2019 20:03:58 +0000 From: Christer Holmberg To: Justin Uberti CC: Roman Shpount , Ted Hardie , "RTCWeb IETF" Thread-Topic: [rtcweb] Results of call for consensus on ICE transport parameter issue Thread-Index: AQHUxYHCF4jGTlyGqkCBEfyt1ATxTKXhqseAgAYIbID///M5gIAFAbmAgANMu4CAAGGBAIAAhLWAgABALID//+HzAIAAI8oA Date: Mon, 25 Feb 2019 20:03:58 +0000 Message-ID: <00148707-E12E-4844-9763-0A4BC8C1EFC9@ericsson.com> References: <0F9730B2-3E44-439D-9832-4C4AEBC054B5@ericsson.com> <8C8AC253-4995-4FD8-B9A7-2E4F303B5153@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f3c7b7f3-3094-45c2-e32e-08d69b5c6127 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4441; x-ms-traffictypediagnostic: HE1PR07MB4441: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0NDQxOzIzOkJXeDAwR2Y5V0t5c0hmWTZPQkxhSHRYZExk?= =?utf-8?B?a1E0VnZSUzBiYzdYcjRqdFlrOGhlNEJVakU3c2pnUU5reWtQS0w5aFhweFQ3?= =?utf-8?B?aXFQNnFWOGRZTDFDODJ0anhHSVpuckFtaE5YU2V2N3lPQitrdkdYaDZHSDJw?= =?utf-8?B?dVN6YjQ4OE02Y1VlRmZFVUE3dmlyVHRIRHRoczVORjJLMFRvRkxuV2xTVnlx?= =?utf-8?B?RGRFR0ZucXlDdWcrOENURDI1Z3g0ZGEwUEdha0ZqUCtDTjFrTmF6cFZKdU4r?= =?utf-8?B?czlZN2F0bVJvQUlZZFgycnpncmd0OEI4Wi9TdWgxMEZKOW44MnJROFpwaGE0?= =?utf-8?B?b1RjT0QvU3oxenVTUlIvNjRqdGpkeGVsblJleGxWQW5QWjhuNUR2RFJQTnEr?= =?utf-8?B?bzc1RjNSSmxMSVFPNjBBak9LVTVKME85aExZcXcrL1RaelZWZTJGSE1wai9q?= =?utf-8?B?Tm01QzhtbEZXTTlyNDY0Z0ZEUzFCQlBneGpVZ0U2bE5pd2hNWjMwV1VnKzVx?= =?utf-8?B?OEp3a2YrOTNXMWt0b3dvSHBZbVVRSVE3NGhYL08vdVh0ejVBbTJudE5BalBq?= =?utf-8?B?Qm44dzFJR2ZTQnBENTVyTy9OOUNGRWFiUlViYXNvQjBycG9SV2lRcWNDYzNt?= =?utf-8?B?aHZPbDlDbkVVckZvdGw2SGVhbzB6bTZSOTI2U3ViQWswTkoyN1dhUTQ2R0du?= =?utf-8?B?QXdLZ1FjamYzN0M1amQ1NkYvZEs4bm9uVDBJcXlOcFVWOWNlWUJjOXRXVHVH?= =?utf-8?B?a003ODB1alRQdzVzeGlTMWwyMng0RnJEWGdrYXdoV0l1eTdVcm5lU1ZGT2dG?= =?utf-8?B?UEIzb2JzZ0lyem9ZM29OL3RvcUM1dnZTSitsNUwzcG9aSG5RUmlMR21OcTFD?= =?utf-8?B?b2VCbktIbmE1RXJ3MFZGVDZFaVVhd0ZsWEErbU5Nc1VaTHV5bDR5RHEvRGM4?= =?utf-8?B?aERKQW1henVWUGNNK0RzRXVEZUtqRklJL0haYlp6cHhGTjZYcWMxbXdEQStP?= =?utf-8?B?U0xqMEdDLzhhV0p4dTJkeUt2czlpSmx5MjB5WEVmV2d1ZEN4NVlOTnVXZ3hT?= =?utf-8?B?ZnhjdGZrZVVjUG0zWFV3RTBteWdsNkJsRGVpVDVORmk2eVNJaXJraVJsdlcx?= =?utf-8?B?cU9iVkMrRm8vR3ExNXhWWTVSSGdwakNGakpVVWdyTzlqQzVzNHVoNVZTdWxz?= =?utf-8?B?OC9xbXpLeTVmVlN3QmxrQnc2NDJTWkIydU5xWHNzYU0rVWR3c1hXVjhScGpF?= =?utf-8?B?Z1VCMDA4R0pici84T21VZXh6NnBTblNTM0ZhZkpVcVBKT1NVR0wzbEJUVUNr?= =?utf-8?B?Q3BlakFkdFcvT3JuZnNLWHhGYTBXb29FNWNQTmlEUHFHSk9QMXBmMkl6VWdG?= =?utf-8?B?M3p4UkRqaHB4ZDdpUjg2RlhuQWtKOE5uS2lkUDUzL2pnS3BXTDlTMk1rSnJJ?= =?utf-8?B?RTVINlB1bllYdWpHNEhmZjVDQ1NRSGdKQ2hQUWZTRXBoSWZqTFBMKzZWaVNL?= =?utf-8?B?U2REM2tKL1NtdGpUOUVDRisxVjREZkI1dkdIWjdzZWluWG5PVzRCK21nMVps?= =?utf-8?B?NkxoZlQ5b0lkUDdETEZPaTJXemtPanA5cGNzME9Ra3pHYm1McEo2MHhMalhz?= =?utf-8?B?ejZwOHg2RGo1bFBxbXJjcytpS3ZCalQ0YzlicXlUYk52bVlZMjUrRWswdXNU?= =?utf-8?B?NWtVZWthODgrVEU1K2hWYXlYK292Tit2S1ovZ1dvZEwxaWl3b2tqdG93c1NT?= =?utf-8?B?UjgzYk52Y0dmMzVqSEJOWnorSW1wZGVodXZDdk82TEJUSWZyRU0yZUNqTk5E?= =?utf-8?B?Y2wrLzBRUWVXL1NHd2R3MWQydnRRNlY5U3owc3BZMXdUQkVXTDhwbjNVYW1Y?= =?utf-8?Q?eV2Z0zcbA/sBKIPFoZpVbPXjLD2sDBoz?= x-microsoft-antispam-prvs: x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(366004)(346002)(136003)(199004)(189003)(58126008)(33656002)(93886005)(966005)(66066001)(71190400001)(71200400001)(8936002)(6306002)(83716004)(97736004)(478600001)(82746002)(2906002)(54896002)(236005)(54906003)(6512007)(102836004)(53546011)(5660300002)(76176011)(99286004)(6506007)(53936002)(6346003)(6436002)(316002)(86362001)(68736007)(2616005)(486006)(36756003)(7736002)(44832011)(186003)(11346002)(476003)(229853002)(8676002)(81156014)(3846002)(6116002)(446003)(6486002)(81166006)(4326008)(6246003)(256004)(25786009)(6916009)(106356001)(606006)(26005)(105586002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4441; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: S1FfP9CBolZuuNlZxR56zsZCo3pz8Bu9Gq6EuTHPmm1PloGQuDpwm2jL2OH5DuUeNePe7wq64S7XJSvx+o7iFgO4oRsxpYWqCi7n8k8gH9YkmcOaFzmsD/AC3vfv6b/9/2VRftvwlyOg+d7KBCLpGbNX/MuBHx5TRP5aacLnc8OPGS3+bsvbmITvRCa2E6hpVrSmq191WKpaxvoduMW4SiVaMXQcAQF0ZWeC6FAxyyIVs+S/kjrksyeoL424vxnvgO4zLI/PYVjxR1z6+QPxt1hlRGnwkdnwP6ZiYNU4hs+2KoKE48G6iQxVPZ/mx2AAgGxTafG9C/QjX/SRLRscGAE0vxR2+ifd3wfLCsUs+orio/ZuJLkFDMXf0kbqr+YZjmd2g/F+EqP/mSc8n2EY7R3J5+QeQ5HK9IZAQf0v7Ys= Content-Type: multipart/alternative; boundary="_000_00148707E12E484497630A4BC8C1EFC9ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f3c7b7f3-3094-45c2-e32e-08d69b5c6127 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2019 20:03:58.8183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4441 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOffebXejwfGm+aD2YauktLTCaESYEcQIjPrQCzayoZcczWX3 LtE+WKvM2iqtZtnQ1ByEZUqrmUpGmkS+lKWUzcqXtt4IKjUsTUZuZ4Hffv/z/J/zf57DYWmu UxLFGkxmXjDpjWqpgrm6+37uijVbzLqVNW9kGncppyl7UUprbvuLZBpLRXIKo212vJdpq1yH tU7nFKUdtOdsY9IU6zN5oyGXFxKT9ymy3JfdKOepjcr7e2GaPoYen6SsSM4CToJLjQ6pFSlY Dncg8I8V0URMInBNdIWEk4IR2xVJQDC4hIafA2cpUrFT8Nbei4j4gKDB921WsKwUa8Dmjw+E hONYGHW0SAJMYwP4+oaDPB/vhH7vQ0Q8u8BX4ZcQNoG1YSp4zuAl0FHYQwdYiTdAceNzhmSV S+CLpzvYIMfboeaURxpghBfA7646ioRFwqCvMrQpBueDXppwBHz1krAInAj3zo8w5FwFz76P hvwLoa/ShginwuQtSzAYsAdBpdcbaoiDP20XQ5dGQXXvLxkxeTloHmiSksIBqA2OHeAYGL9T JyWmK1J4VTxBl6AEx5xpCWdAfWORzBFcOww6r/oYx+yr0ngZNLQkEosK7LZRGeGlUFheEWIt lN0ooeZ6qhB7E0WIvChm71+9OoEXDBmieNCUYOLNLjT7wdru/V3XhNo+b2xHmEXqecrXm8w6 TqLPFfOz2xGwtDpcufeHqOOUmfr8I7xwMF04bOTFdhTNMupI5QwXpuPwfr2ZP8DzObzwv0qx 8qhjaJ61zFOfEZt7u1Nv7J8u6H666M1l9Eg/PMmdXlwzsDlds6fpknj/TOqTvJ7qsdauta6R d0mDi2KWn4hvTWr+pD0nX1YXvvGFDJcLJ48ORb9SUVGtqlMT8ZZhZcpZ93hWd8cOU8HdQ2nC taGZbR93vvQfH9ZRv7bXPrSEbTWbw66nqxkxS78qjhZE/T99xAURXAMAAA== Archived-At: Subject: Re: [rtcweb] Results of call for consensus on ICE transport parameter issue X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 20:04:10 -0000 --_000_00148707E12E484497630A4BC8C1EFC9ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIGJlbGlldmUgdGhlIGN1cnJlbnQgUFIgbWFrZXMgSlNFUCBpbnRlcm5hbGx5IGNv bnNpc3RlbnQuDQoNCk9rLCBJIHdhc27igJl0IHN1cmUgdGhhdCBpcyB3aGF0IHlvdSBtZWFudCB3 aGVuIHlvdSBzYWlkIHRoYXQgeW91IOKAnGZvdW5kIGEgd2F5IHRvIGFkZHJlc3MgdGhpc+KAnSDw n5iKDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpPbiBNb24sIEZlYiAyNSwgMjAxOSBh dCAxMTo0MyBBTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0K DQpJIGFtIG5vdCBzdXJlIHdoYXQgb3RoZXIgZG9jdW1lbnQgeW91IHJlZmVyIHRvLCBidXQgaXQg cmVhbGx5IGRlcGVuZHMgb24gd2hhdCB0aGUgdGV4dCBpcyB0YWxraW5nIGFib3V0OiB0aGUgc2Vt YW50aWNzIG9mIHRoZSA8cHJvdG8+IGZpZWxkLCB3aGljaCBpcyBhIHRyYW5zcG9ydCBwcm90b2Nv bCwgb3Igd2hhdGV2ZXIgaXMgdXNlZCBhcyBhIHRyYW5zcG9ydCBwcm90b2NvbCAoZS5nLiwgYW4g UlRQIHByb2ZpbGUpLg0KDQpIYXZpbmcgc2FpZCB0aGF0LCBJIGFtIGF3YXJlIHRoYXQgZG9jdW1l bnRzIHVuZm9ydHVuYXRlbHkgZG9u4oCZdCB1c2UgY29uc2lzdGVudCB0ZXJtaW5vbG9neSwgc28g SSB3b3VsZG7igJl0IGJlIHN1cnByaXNlZCBpZiB0aGUgNDU2NmJpcyB0ZXJtaW5vbG9neSBpc27i gJl0IHVzZWQgZXZlcnl3aGVyZSAoYWxzbywgdGhlcmUgaGF2ZSBiZWVuIGRpc2N1c3Npb25zIGFi b3V0IHRoZSA0NTY2YmlzIHRlcm1pbm9sb2d5IGl0c2VsZuKApikuDQoNCk15IHBlcnNvbmFsIHBy ZWZlcmVuY2Ugd291bGQgYmUgdG8gYmUgYWxpZ25lZCB3aXRoIDQ1NjZiaXMsIGJ1dCBhcyBsb25n IGFzIHdlIGFyZSBjb25zaXN0ZW50IHdpdGhpbiBKU0VQIEkgY2FuIGxpdmUgd2l0aCBpdC4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpGcm9tOiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdv b2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+DQpEYXRlOiBNb25kYXksIDI1IEZl YnJ1YXJ5IDIwMTkgYXQgMTkuNTQNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ Pg0KQ2M6IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbT4+LCBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRm QGdtYWlsLmNvbT4+LCAicnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+IiA8 cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFty dGN3ZWJdIFJlc3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFy YW1ldGVyIGlzc3VlDQoNClN1cmUsIGJ1dCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIHVzZSB0 aGUgc2FtZSB0ZXJtaW5vbG9neSAoaS5lLiwgInByb2ZpbGUiKSBhcyBpcyB1c2VkIGluIG90aGVy IFJUUC1yZWxhdGVkIGRvY3VtZW50cy4NCg0KT24gU3VuLCBGZWIgMjQsIDIwMTkgYXQgMTE6NTgg UE0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSW4gNDU2 NmJpcywgPHByb3RvPiBkZWZpbmVzIGEgdHJhbnNwb3J0IHByb3RvY29sLg0KDQpJbiBjYXNlIG9m IFJUUCwgdGhlIHRleHQgcmVmZXJzIHRvIFJUUC9BVlAgYXMgYW4g4oCcUlRQIHByb2ZpbGXigJ0s IGJ1dCBpdCBpcyBzdGlsbCBhIHRyYW5zcG9ydCBwcm90b2NvbC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KRnJvbTogSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpq dWJlcnRpQGdvb2dsZS5jb20+Pg0KRGF0ZTogTW9uZGF5LCAyNSBGZWJydWFyeSAyMDE5IGF0IDYu MTANClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVs dXJpeC5jb20+Pg0KQ2M6IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86dGVk LmlldGZAZ21haWwuY29tPj4sICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4iIDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+LCBDaHJpc3RlciBI b2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFJlc3VsdHMgb2Yg Y2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFyYW1ldGVyIGlzc3VlDQoNCkZv dW5kIGEgd2F5IHRvIGFkZHJlc3MgdGhpcyB3aXRoIG1pbm9yIGNoYW5nZXMgdG8gdGhlIGV4aXN0 aW5nIFBSLg0KDQpPbiBGcmksIEZlYiAyMiwgMjAxOSBhdCA1OjQ2IFBNIEp1c3RpbiBVYmVydGkg PGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQpS b21hbiwgdGhhbmtzIGZvciByYWlzaW5nIHRoaXMuIEkgbG9va2VkIGludG8gdGhpcyBhIGJpdCBh bmQgaXQncyBraW5kIG9mIGFtYmlndW91czsgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc4NTAgdXNlcyAicHJvZmlsZSIsICJwcm90byIsIGFuZCAicHJvdG9jb2wiIChhbHRob3VnaCAi cHJvdG9jb2wiIGlzIHVzZWQgbW9zdCBmcmVxdWVudGx5KS4NCg0KSlNFUCBhY3R1YWxseSB1c2Vz IGJvdGggcHJvZmlsZSBhbmQgcHJvdG9jb2wgdG8gcmVmZXIgdG8gdGhlIHRyYW5zcG9ydCwgZGVw ZW5kaW5nIG9uIHRoZSBzZWN0aW9uOyBpZiB3ZSBtYWtlIGEgY2hhbmdlIGhlcmUsIHdlIHNob3Vs ZCBoaXQgYWxsIHVzYWdlcywgd2hpY2ggcHJvYmFibHkgbWVhbnMgdGhhdCBpdCBpcyBvdXRzaWRl IG9mIHRoZSBzY29wZSBvZiB0aGlzIHBhcnRpY3VsYXIgaXNzdWUuDQoNCk9uIFR1ZSwgRmViIDE5 LCAyMDE5IGF0IDE6MTkgUE0gUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRv OnJvbWFuQHRlbHVyaXguY29tPj4gd3JvdGU6DQpIaSBKdXN0aW4sDQoNCkkgZGlkIHByb3ZpZGUg ZWRpdG9yaWFsIGZlZWRiYWNrIHRvIHRoZSBjaGFuZ2Ugb24gZ2l0aHViOg0KDQoxLiBUaGlzIGRv Y3VtZW50IHJlZmVycyB0byBTRFAgcHJvdG9jb2wgYXMgcHJvZmlsZS4gSWYgeW91IGxvb2sgYXQg dGhlIHJlZmVyZW5jZWQgZG9jdW1lbnRzIHRoYXQgZGVmaW5lICJwcm9maWxlcyIgaW4gSlNFUCwg dGhleSBhbGwgcmVmZXIgdG8gdGhlbSBhcyBwcm90b2NvbHMuIEFsc28sIGluIGNhc2Ugb2YgU1JU UCwgcHJvZmlsZSBpcyBhY3R1YWxseSBzb21ldGhpbmcgZGlmZmVyZW50IGFuZCByZWZlcnMgdG8g U1JUUCBrZXkgcGFyYW1ldGVycy4NCg0KMi4gRGVmYXVsdCBjYW5kaWRhdGUgZG9lcyBub3QgaGF2 ZSBwcm9maWxlIChvciBwcm90b2NvbCksIGl0IGhhcyB0cmFuc3BvcnQsIHBvcnQsIGFuZCAoY29u bmVjdGlvbi0pYWRkcmVzcy4gU28gZWFjaCAibT0iIGFuZCAiYz0iIE1VU1QgYmUgZmlsbGVkIGlu IHdpdGggcG9ydCwgcHJvdG9jb2wsIGFuZCBhZGRyZXNzIHRvIG1hdGNoIHBvcnQsIHRyYW5zcG9y dCwgYW5kIGFkZHJlc3Mgb2YgdGhlIGRlZmF1bHQgY2FuZGlkYXRlIGZvciB0aGUgbT0gc2VjdGlv biwgYXMgZGVzY3JpYmVkIGluIGljZS1zaXAtc2RwLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19f Xw0KUm9tYW4gU2hwb3VudA0KDQoNCk9uIFR1ZSwgRmViIDE5LCAyMDE5IGF0IDM6MDUgUE0gQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpMb29rcyBnb29kLg0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBydGN3ZWIgPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBKdXN0aW4gVWJl cnRpIDxqdWJlcnRpPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUu LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpEYXRlOiBTYXR1cmRheSwgMTYgRmVicnVhcnkgMjAxOSBh dCAzLjU3DQpUbzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQuaWV0 ZkBnbWFpbC5jb20+Pg0KQ2M6ICJydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9y Zz4iIDxydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogW3J0Y3dlYl0gUmVzdWx0cyBvZiBjYWxsIGZvciBjb25zZW5zdXMgb24gSUNFIHRyYW5zcG9y dCBwYXJhbWV0ZXIgaXNzdWUNCg0KSSBoYXZlIHVwZGF0ZWQgdGhpcyBQUiB0byBpbmNvcnBvcmF0 ZSBtaW5vciBmZWVkYmFjayB0aGF0IHdhcyByZWNlaXZlZCBkdXJpbmcgdGhlIGNvbnNlbnN1cyBj YWxsLiBUaG9zZSB3aG8gaGFkIGZlZWRiYWNrLCBwbGVhc2UgdGFrZSBhbm90aGVyIGxvb2sgYW5k IGNvbW1lbnQgb24gdGhlIFBSIGlmIHlvdSBhcmUgc2F0aXNmaWVkLg0KDQpPbiBGcmksIEZlYiAx NSwgMjAxOSBhdCAyOjU2IFBNIFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 dGVkLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpUaGUgY2hhaXJzIGJlbGlldmUgdGhhdCB0aGVy ZSB3YXMgcm91Z2ggY29uc2Vuc3VzIGFtb25nIHRob3NlIHJlc3BvbmRpbmcgdG8gbWFrZSB0aGUg Y2hhbmdlIGluOg0KDQpodHRwczovL2dpdGh1Yi5jb20vcnRjd2ViLXdnL2pzZXAvcHVsbC84NjMN Cg0KR2l2ZW4gdGhlIHN0YXRlIG9mIHRoZSBkb2N1bWVudCwgaXQgd2lsbCBiZSB0aGUgQXJlYSBE aXJlY3RvcidzIGNhbGwgYXMgdG8gaG93IG11Y2ggb2YgdGhlIHBvc3Qtd29ya2luZyBncm91cCBh cHByb3ZhbCBwcm9jZXNzIG11c3QgYmUgcmUtZG9uZS4gIEF1dGhvcnMsIHBsZWFzZSB3YWl0IG9u IGhpcyBkaXJlY3Rpb24gYmVmb3JlIHB1Ymxpc2hpbmcgYSBuZXcgdmVyc2lvbiB3aXRoIHRoaXMg bWVyZ2VkLg0KDQpSZWdhcmRzLA0KVGVkIGFuZCBTZWFuDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGll dGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Y3dlYg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCnJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86 cnRjd2ViQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dGN3ZWINCg== --_000_00148707E12E484497630A4BC8C1EFC9ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <56B0B30DE2F8C2459200238857DEC2D6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7SSBiZWxpZXZlIHRoZSBjdXJyZW50IFBSIG1h a2VzIEpTRVAgaW50ZXJuYWxseSBjb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5PaywgSSB3YXNu4oCZdCBzdXJlIHRoYXQgaXMgd2hhdCB5b3UgbWVhbnQgd2hlbiB5b3Ugc2Fp ZCB0aGF0IHlvdSDigJxmb3VuZCBhIHdheSB0byBhZGRyZXNzIHRoaXPigJ0NCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FwcGxlIENvbG9yIEVtb2pp JnF1b3Q7Ij4mIzEyODUyMjs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiAyNSwgMjAxOSBhdCAxMTo0MyBB TSBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+SSBhbSBub3Qgc3VyZSB3aGF0IG90aGVyIGRvY3VtZW50IHlvdSByZWZl ciB0bywgYnV0IGl0IHJlYWxseSBkZXBlbmRzIG9uIHdoYXQgdGhlIHRleHQgaXMgdGFsa2luZyBh Ym91dDogdGhlIHNlbWFudGljcyBvZiB0aGUgJmx0O3Byb3RvJmd0OyBmaWVsZCwgd2hpY2ggaXMg YSB0cmFuc3BvcnQNCiBwcm90b2NvbCwgb3Igd2hhdGV2ZXIgaXMgdXNlZCBhcyBhIHRyYW5zcG9y dCBwcm90b2NvbCAoZS5nLiwgYW4gUlRQIHByb2ZpbGUpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PkhhdmluZyBzYWlkIHRoYXQsIEkgYW0gYXdhcmUgdGhhdCBkb2N1bWVudHMgdW5mb3J0dW5hdGVs eSBkb27igJl0IHVzZSBjb25zaXN0ZW50IHRlcm1pbm9sb2d5LCBzbyBJIHdvdWxkbuKAmXQgYmUg c3VycHJpc2VkIGlmIHRoZSA0NTY2YmlzIHRlcm1pbm9sb2d5IGlzbuKAmXQgdXNlZCBldmVyeXdo ZXJlDQogKGFsc28sIHRoZXJlIGhhdmUgYmVlbiBkaXNjdXNzaW9ucyBhYm91dCB0aGUgNDU2NmJp cyB0ZXJtaW5vbG9neSBpdHNlbGbigKYpLiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk15IHBl cnNvbmFsIHByZWZlcmVuY2Ugd291bGQgYmUgdG8gYmUgYWxpZ25lZCB3aXRoIDQ1NjZiaXMsIGJ1 dCBhcyBsb25nIGFzIHdlIGFyZSBjb25zaXN0ZW50IHdpdGhpbiBKU0VQIEkgY2FuIGxpdmUgd2l0 aCBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkp1c3Rp biBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25k YXksIDI1IEZlYnJ1YXJ5IDIwMTkgYXQgMTkuNTQ8YnI+DQo8Yj5UbzogPC9iPkNocmlzdGVyIEhv bG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzogPC9iPlJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDssIFRl ZCBIYXJkaWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv OnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mcXVv dDsNCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbcnRjd2Vi XSBSZXN1bHRzIG9mIGNhbGwgZm9yIGNvbnNlbnN1cyBvbiBJQ0UgdHJhbnNwb3J0IHBhcmFtZXRl ciBpc3N1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlN1cmUsIGJ1dCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNlIHRvIHVzZSB0 aGUgc2FtZSB0ZXJtaW5vbG9neSAoaS5lLiwgJnF1b3Q7cHJvZmlsZSZxdW90OykgYXMgaXMgdXNl ZCBpbiBvdGhlciBSVFAtcmVsYXRlZCBkb2N1bWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBGZWIgMjQsIDIwMTkgYXQgMTE6NTgg UE0gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPkluIDQ1NjZiaXMsICZsdDtwcm90byZndDsgZGVmaW5lcyBhIHRyYW5zcG9ydCBwcm90 b2NvbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBjYXNlIG9mIFJUUCwgdGhlIHRleHQgcmVm ZXJzIHRvIFJUUC9BVlAgYXMgYW4g4oCcUlRQIHByb2ZpbGXigJ0sIGJ1dCBpdCBpcyBzdGlsbCBh IHRyYW5zcG9ydCBwcm90b2NvbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkp1c3Rp biBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25k YXksIDI1IEZlYnJ1YXJ5IDIwMTkgYXQgNi4xMDxicj4NCjxiPlRvOiA8L2I+Um9tYW4gU2hwb3Vu dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+ cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+VGVkIEhhcmRpZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5p ZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9y ZzwvYT4mZ3Q7LCBDaHJpc3RlciBIb2xtYmVyZw0KICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtydGN3ZWJd IFJlc3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFyYW1ldGVy IGlzc3VlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Rm91bmQgYSB3YXkgdG8gYWRkcmVzcyB0aGlzIHdpdGggbWlub3IgY2hh bmdlcyB0byB0aGUgZXhpc3RpbmcgUFIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBGZWIgMjIsIDIwMTkgYXQgNTo0NiBQTSBKdXN0aW4g VWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+anViZXJ0aUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJvbWFuLCB0aGFua3MgZm9yIHJh aXNpbmcgdGhpcy4gSSBsb29rZWQgaW50byB0aGlzIGEgYml0IGFuZCBpdCdzIGtpbmQgb2YgYW1i aWd1b3VzOw0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc4NTAiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzg1MDwvYT4gdXNl cyAmcXVvdDtwcm9maWxlJnF1b3Q7LCAmcXVvdDtwcm90byZxdW90OywgYW5kICZxdW90O3Byb3Rv Y29sJnF1b3Q7IChhbHRob3VnaCAmcXVvdDtwcm90b2NvbCZxdW90OyBpcyB1c2VkIG1vc3QgZnJl cXVlbnRseSkuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5KU0VQIGFjdHVhbGx5IHVzZXMgYm90aCBwcm9maWxlIGFuZCBwcm90b2NvbCB0byByZWZl ciB0byB0aGUgdHJhbnNwb3J0LCBkZXBlbmRpbmcgb24gdGhlIHNlY3Rpb247IGlmIHdlIG1ha2Ug YSBjaGFuZ2UgaGVyZSwgd2Ugc2hvdWxkIGhpdCBhbGwgdXNhZ2VzLCB3aGljaCBwcm9iYWJseSBt ZWFucyB0aGF0IGl0DQogaXMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgdGhpcyBwYXJ0aWN1bGFy IGlzc3VlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxOSwgMjAxOSBhdCAxOjE5IFBNIFJvbWFuIFNo cG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEp1c3RpbiwNCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZGlkIHByb3ZpZGUgZWRp dG9yaWFsIGZlZWRiYWNrIHRvIHRoZSBjaGFuZ2Ugb24gZ2l0aHViOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuIFRoaXMg ZG9jdW1lbnQgcmVmZXJzIHRvIFNEUCBwcm90b2NvbCBhcyBwcm9maWxlLiBJZiB5b3UgbG9vayBh dCB0aGUgcmVmZXJlbmNlZCBkb2N1bWVudHMgdGhhdCBkZWZpbmUgJnF1b3Q7cHJvZmlsZXMmcXVv dDsgaW4gSlNFUCwgdGhleSBhbGwgcmVmZXIgdG8gdGhlbSBhcyBwcm90b2NvbHMuIEFsc28sIGlu IGNhc2Ugb2YNCiBTUlRQLCBwcm9maWxlIGlzIGFjdHVhbGx5IHNvbWV0aGluZyBkaWZmZXJlbnQg YW5kIHJlZmVycyB0byBTUlRQIGtleSBwYXJhbWV0ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi4gRGVmYXVsdCBjYW5kaWRhdGUg ZG9lcyBub3QgaGF2ZSBwcm9maWxlIChvciBwcm90b2NvbCksIGl0IGhhcyB0cmFuc3BvcnQsIHBv cnQsIGFuZCAoY29ubmVjdGlvbi0pYWRkcmVzcy4gU28gZWFjaCAmcXVvdDttPSZxdW90OyBhbmQg JnF1b3Q7Yz0mcXVvdDsgTVVTVCBiZSBmaWxsZWQgaW4gd2l0aCBwb3J0LCBwcm90b2NvbCwgYW5k IGFkZHJlc3MNCiB0byBtYXRjaCBwb3J0LCB0cmFuc3BvcnQsIGFuZCBhZGRyZXNzIG9mIHRoZSBk ZWZhdWx0IGNhbmRpZGF0ZSBmb3IgdGhlIG09IHNlY3Rpb24sIGFzIGRlc2NyaWJlZCBpbiBpY2Ut c2lwLXNkcC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDE5LCAyMDE5IGF0IDM6MDUgUE0gQ2hyaXN0ZXIgSG9s bWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+TG9va3MgZ29vZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5ydGN3ZWIgJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWIt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYi1ib3VuY2VzQGlldGYub3Jn PC9hPiZndDsgb24gYmVoYWxmIG9mIEp1c3RpbiBVYmVydGkgJmx0O2p1YmVydGk9PGEgaHJlZj0i bWFpbHRvOjQwZ29vZ2xlLi5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdv b2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TYXR1cmRh eSwgMTYgRmVicnVhcnkgMjAxOSBhdCAzLjU3PGJyPg0KPGI+VG86IDwvYj5UZWQgSGFyZGllICZs dDs8YSBocmVmPSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGVk LmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cnRjd2ViQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtydGN3 ZWJdIFJlc3VsdHMgb2YgY2FsbCBmb3IgY29uc2Vuc3VzIG9uIElDRSB0cmFuc3BvcnQgcGFyYW1l dGVyIGlzc3VlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIHVwZGF0ZWQgdGhpcyBQUiB0byBpbmNvcnBvcmF0ZSBt aW5vciBmZWVkYmFjayB0aGF0IHdhcyByZWNlaXZlZCBkdXJpbmcgdGhlIGNvbnNlbnN1cyBjYWxs LiBUaG9zZSB3aG8gaGFkIGZlZWRiYWNrLCBwbGVhc2UgdGFrZSBhbm90aGVyIGxvb2sgYW5kIGNv bW1lbnQgb24gdGhlIFBSIGlmIHlvdSBhcmUNCiBzYXRpc2ZpZWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBGZWIgMTUsIDIwMTkgYXQg Mjo1NiBQTSBUZWQgSGFyZGllICZsdDs8YSBocmVmPSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+dGVkLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgY2hhaXJzIGJlbGlldmUgdGhhdCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3Vz IGFtb25nIHRob3NlIHJlc3BvbmRpbmcgdG8gbWFrZSB0aGUgY2hhbmdlIGluOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL3B1bGwvODYzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9qc2VwL3B1bGwvODYzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+R2l2ZW4g dGhlIHN0YXRlIG9mIHRoZSBkb2N1bWVudCwgaXQgd2lsbCBiZSB0aGUgQXJlYSBEaXJlY3Rvcidz IGNhbGwgYXMgdG8gaG93IG11Y2ggb2YgdGhlIHBvc3Qtd29ya2luZyBncm91cCBhcHByb3ZhbCBw cm9jZXNzIG11c3QgYmUgcmUtZG9uZS4mbmJzcDsgQXV0aG9ycywgcGxlYXNlIHdhaXQgb24gaGlz IGRpcmVjdGlvbg0KIGJlZm9yZSBwdWJsaXNoaW5nIGEgbmV3IHZlcnNpb24gd2l0aCB0aGlzIG1l cmdlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRlZCBhbmQgU2VhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnJ0Y3dlYiBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRjd2ViQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcnRjd2ViIG1haWxpbmcgbGlzdDxi cj4NCjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3 ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Y3dlYjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_00148707E12E484497630A4BC8C1EFC9ericssoncom_-- From nobody Wed Feb 27 07:11:11 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0356B130E71 for ; Wed, 27 Feb 2019 07:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=XVaFAksG; dkim=pass (1024-bit key) header.d=ericsson.com header.b=EpGfSWVX 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 x0jwS48U9k5A for ; Wed, 27 Feb 2019 07:11:07 -0800 (PST) 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 88BC3130FDB for ; Wed, 27 Feb 2019 07:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551280264; x=1553872264; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pkhTppLZx5LJd3k7zDaryLd9FzSyPPtHm0Q7Ml8bw6k=; b=XVaFAksGlnWFpsKQfslkv00UMHMuc/UuSHZ+qRGBFL7k15yDr3zdmtuC/UEFQcc0 sPXNKh4MwcisaINVkFy80snH+/othr7FNDeTOs+OfzFZl9rAGCJpT6XkABQFNTNj y0k0nQL7LtVneXUXDgTwANLZc/8F+35E9LXsViS6sOk=; X-AuditID: c1b4fb30-41b3a9e00000355c-ca-5c76a8887222 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 03.8E.13660.888A67C5; Wed, 27 Feb 2019 16:11:04 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 27 Feb 2019 16:11:00 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 27 Feb 2019 16:11:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pkhTppLZx5LJd3k7zDaryLd9FzSyPPtHm0Q7Ml8bw6k=; b=EpGfSWVXPjhcsQRi99fUxS/DzEWcAXqDzIZcckZC0+JEKjK1WQvHIOCCS+522+qfgNlIEycmNExx5UOCxwxxW/g25oDuM6hGvSKsfrwwGr05L7RIifr7MM8SgR8tRkVtnnvrFz0SowfvquBvAU4MapBdLh4D0P8dUU5bsz10N30= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3451.eurprd07.prod.outlook.com (10.170.247.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.5; Wed, 27 Feb 2019 15:11:00 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::dd59:bc9e:2910:48ae%3]) with mapi id 15.20.1665.012; Wed, 27 Feb 2019 15:10:59 +0000 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: Draft new: draft-holmberg-ice-premature-00 Thread-Index: AQHUzq5rQ4cjYjGrok+RsDk23rIzn6Xz4XSA Date: Wed, 27 Feb 2019 15:10:59 +0000 Message-ID: <14802D65-D27C-4AF5-B7F2-78004B2354ED@ericsson.com> References: <6ED3E9B1-648B-40DE-B8E6-4992D61C22EF@ericsson.com> In-Reply-To: <6ED3E9B1-648B-40DE-B8E6-4992D61C22EF@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df298527-ec45-4a92-790b-08d69cc5c825 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3451; x-ms-traffictypediagnostic: HE1PR07MB3451: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDUxOzIzOklYYWtyUnZLcy9LRkNZdXVVanhLUUQzVzc1?= =?utf-8?B?SW5LbVNCUFNoeFV6SWJYWjFrU2YvV2J0bXJKTHNOL3d3a1BhRURiQmpONzZh?= =?utf-8?B?WTRYdXRib2RFYU5OVVp3UFhIZURFajhFMUg1S1pOQnNtRnF6WnZ2OHRqL0xY?= =?utf-8?B?MDFIbHcxaE9Vb1ZVOFVOK0xReGZGYVdmZWdUS3JxTmY0VVFYbXhDRFRRUGp1?= =?utf-8?B?ZXZ4NlBZUHVDRnlVQnB0UlM3a25zMVBweHBlVm1mRWVDbWY5clZ2ZFZxUllH?= =?utf-8?B?WG1QS0w0Ukk5S2VMaGxvZVVrd0NHclVwZkxwc2UvbVdDMi9PYmNiRkZSd0tY?= =?utf-8?B?ZzhjNW5zQ3RGWXZzTGUwZjF1ajhXUzFtTXVNTmJPajR3OXlTWjViandoWjgz?= =?utf-8?B?dmorVDYxeU55RWExbHd1RGJ3UVNOOXJmRC9KelBxK2dkMUdmQ2JsYjBjRDlT?= =?utf-8?B?OWpkSFdvS1VyWGd6b1laMUVsNzZzWDhhbG1aRmR4d0xwU3Mva2g2Mks3ZU1N?= =?utf-8?B?T3lEQWVybkprN3pXWU1xYmhjU2kxcGpqR1NPbm5KNS9IKzBMNjNDYWE5aE95?= =?utf-8?B?elNTeER1blF3bHUzdXJ0QTloRERNaisxcnZQRm5xaDd0ZUZCNHRQREVEVVh5?= =?utf-8?B?YWt6MkZoVDB6RTBwQUdNWEZ2UWFzNWN2UW5YZ0dJMnVhdFdKWXVVZng5TDcr?= =?utf-8?B?aUd0VUQ2N2ZoSCtXWXRDVFVJZzQ4blhFR0FZTHhYWGxhb2lqek0wQjRtRUNU?= =?utf-8?B?Y1lnOThzZ3FiWjBXOU50M01NelFja0JEYi9DUGVUMFY3ekIrU29jR2x5QjdU?= =?utf-8?B?ZytuWFN3MkR5VUwzT24xaW5mT0FHWmpJcldrOUgzSGpMM3JJbXVUZ2tIMnQx?= =?utf-8?B?WEpkNDVMS3dqNG1ZL0EvK3kvWG5GaDJ3YmRZcDJnRnNkbkxqcGdtai81ODEv?= =?utf-8?B?VGM4OVd6M1A4MG1DaVlGVTFrVm8zQ3huc0xHaVYrMTRmSmJacVo4eWxtMHhJ?= =?utf-8?B?S3BNWjBCd2twMGN5aittWllMclhDN3N1dTZtMWdaRFZQQk9xVEJoOXZ2WWM5?= =?utf-8?B?VWw0OHpac3JsMEN4K3lxUXZLQzVxNW1tMXpmVEdvcHU2blIwYUtMQngrRDBa?= =?utf-8?B?MExlaHEram9sUm85Nk1tS0pmQnd6VS9HUnpBbkxIcUxXQU5PaUVZN2lwenpn?= =?utf-8?B?SHpNaW1qdWFvZmNNUmlBU1RiVDNJQXoxR2g5cXZqQ0hmMGFUeEFTQk5KZ1Ir?= =?utf-8?B?bEVTc0MzSEM4TXBMZEUzemVmRHZVdXdjcEJEa3d4R2ZwdkRCcDIrNlZicVJa?= =?utf-8?B?MWVxaHdsVE1haFc0RW82WXFtQmV5M3JMd0duT0dYQVRrN3ltYmtoU0ZtYXhB?= =?utf-8?B?aGRtVlVaMlQ1aXNwQ3E5cFJkNWNiU25qNVAwWjB6TWFWVUJIYllvdXFRaGF6?= =?utf-8?B?cFZoTlo1M0dnSVpWcVVlc3NlR1JZMWRWVkpwZE5sazFjQTVIU21MTEZNcGwx?= =?utf-8?B?dWNwa3ZmMDJFajF1aXMxUFBZNjMrSDZmVnpQTUI3MThkdEdhVCtjeUdBZHN6?= =?utf-8?B?MXdYc2ZINDFGSGl6TnFQWDgvV0NaOTR6M3NpZ3RFcXJIMXRwL2FwSFZYbnQ3?= =?utf-8?B?eG1hRzhVKzlEbEIwSG5lZkNnRHpYd2hHTVczeW9vSFFxSkRkK05vcHMydlFV?= =?utf-8?B?bUhuUFMwWGhQZW03RThFQWxVSkM5VklxK2kxOHlHYzlKYS9xV2NVMmg5NEhO?= =?utf-8?B?eldSRWhEUE00K0cvWHNQY2kySjN3VHZCYlFpS1JTYmhSVDR0ZFhYU2xIZ0ww?= =?utf-8?B?TnV6VlQwVnFHOUZYc3RYZTZoNDhQZlNXVFBYS29GTG90QmpmTnkxLzZ3eUtM?= =?utf-8?Q?QMuySHXxG1h2FvymwFGpXXIMNMYN2BQ5?= x-microsoft-antispam-prvs: x-forefront-prvs: 0961DF5286 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(396003)(39860400002)(136003)(189003)(199004)(68736007)(83716004)(14444005)(76176011)(36756003)(1730700003)(81156014)(81166006)(256004)(8676002)(53936002)(8936002)(102836004)(14454004)(6506007)(82746002)(71190400001)(71200400001)(236005)(476003)(229853002)(44832011)(6486002)(486006)(99286004)(2616005)(11346002)(6306002)(6436002)(6512007)(5640700003)(2473003)(66066001)(966005)(446003)(97736004)(33656002)(26005)(54896002)(3846002)(6116002)(25786009)(2906002)(106356001)(105586002)(2351001)(606006)(478600001)(5660300002)(7736002)(58126008)(316002)(6916009)(86362001)(186003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3451; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZZn07IauAx5SweQkzzo4s59tJmzNle29eUcwrpPM3QHEeEGeHABR10RzO3zRgwUdOImndBymcqC2ba+Dgla8Yca1FC3btejCS7FVm5VeUXGAK1kO2wV0TdJm4tCT+6VIZZqVNYQUeQV8Mwb2w8X5x5ETBBxjjgeFoxrt89Jd6jA/uMXM7sWnf0gxE9yrsjKNKCJ3BxkWcMRSEgFaeLmgNMSb5F2+kncLPawOF7yz94v1kma97fXPRmJB3J2brvv0GOxYzw6aRA9t1f13tYvZH7ejY9xMlgYmrEShE63gscoERmiv3obmVd//kdQUikV3Mrao2gPVJEi6RPXuKd+xIwveODkyedEwjP9vYvOmZAhmrm7rPn2YSl3uNRhd3a1UMdDGPwiwkqbqHbUtmeBJYo1FA6GamZGa1NLeXyY0zUQ= Content-Type: multipart/alternative; boundary="_000_14802D65D27C4AF5B7F278004B2354EDericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: df298527-ec45-4a92-790b-08d69cc5c825 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 15:10:59.8362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3451 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObt3u3ej0XH58mD5wfWirubcMBoSaX0aRmAfIhGzll506aZs Zs1PStNE04SCdGpKjjDTBF/SQpCmVpqhmUS+kbahqKgrUNHZate7wG+/5zy//znPA4cmJE38 YFpnyGWMBm2WVCAiqxO778hLmvKSo+o+ydStnvtUHNLYbNu8BJQkOpvGZOnyGKPi3A1RxuY3 aU7JxbuDlhFUgNyaUiSkAUfD6uIGVYpEtAQPIHBYbb5iE8GipYPkChsPyt+089iCxJUEdPf1 8Nm8BD/iQcuEhrN+IhisXfc2aFqA1VDmOck6/jgMvs6PUSwfwmdgenSG4s7VsFLYTnKsgt8D Q4hlEh+HFaudx7IYx0JZyTri3ooFV9/LPV+I42D1lZNgGeFA2Bpu2fMJHARTznoetxsGW+8o wXEALDk8ezMHYAV0VsyRXFYLfc1zPicUPq/N+7IhMF5fhji+BJ6273x2R8CTCCae1QjYHQHL 4EPXLc4Jhi3HL4pzHBKodxf7LsqE970/fP4RcD08zjk1AuitekpWIrl139wcp8KCq5Cy7u3v B0PVTtLqjRM4AtreKjglFB6XzVMch0NRbZ2PNfBxeora7zQguhkFmBjTTX26ShXJGHWpJlO2 IdLA5LYj7/951+mO6kFLi+ftCNNIekCsa8xLlvC1eSaz3o6AJqT+4mN13iNxmtaczxizrxtv ZzEmOzpMk9Ig8a7EL1mC07W5TCbD5DDG/10eLQwuQA9kGXKPZO3yhJUgGq/tLNjLE5Q71VeF zwWzw+pTFSP94TNDMRXx1qjlg69PJyh1J15UuNUxy4H8FOecWUnk/olv3tVXJflVfbmwnV90 JdHVtR3hlPfnRP+1WFQd481d7jGLodXcOjuuCDs6GZJiC9sYLJ67p08TPRlKaKDCpaQpQ6uU EUaT9h9RGWT2OwMAAA== Archived-At: Subject: [rtcweb] FW: Draft new: draft-holmberg-ice-premature-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:11:09 -0000 --_000_14802D65D27C4AF5B7F278004B2354EDericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLA0KDQpUaGlzIGlzIHJlbGV2YW50IHRvIFJUQ1dFQiwgYXMgaXQgTUFZIGJlIHNvbWV0aGlu ZyB3ZSB3YW50IHRvIHJlZmVyZW5jZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTog Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkRhdGU6 IFdlZG5lc2RheSwgMjcgRmVicnVhcnkgMjAxOSBhdCAxNy4wOQ0KVG86ICJpY2VAaWV0Zi5vcmci IDxpY2VAaWV0Zi5vcmc+DQpDYzogImljZS1jaGFpcnNAaWV0Zi5vcmciIDxpY2UtY2hhaXJzQGll dGYub3JnPg0KU3ViamVjdDogRHJhZnQgbmV3OiBkcmFmdC1ob2xtYmVyZy1pY2UtcHJlbWF0dXJl LTAwDQoNCkhpLA0KDQpUb2RheSwgODQ0NSBkZWZpbmVzIHRoYXQgaWYgYW4gSUNFIGVuZHBvaW50 IGRpc2NhcmRzIGl0cyBjYW5kaWRhdGVzIGFuZCBpcyBub3QgYWJsZSB0byBmb3JtIGNhbmRpZGF0 ZSBwYWlycywgb3Igd2hlbiB0aGUgdGVzdCBvZiBhbGwgcGFpcnMgZmFpbCwgdGhlIElDRSBhZ2Vu dCB3aWxsIHRyaWdnZXIgSUNFIGZhaWx1cmUuDQoNClRoZSBJQ0UgYWdlbnQgbWF5IGRvIHRoaXMg YmVmb3JlIGl0IGhhcyByZWNlaXZlZCBhbnkgY29ubmVjdGl2aXR5IGNoZWNrcyBmcm9tIHRoZSBy ZW1vdGUgcGVlciwgYW5kIHN1Y2ggY29ubmVjdGl2aXR5IGNoZWNrcyBtaWdodCB0cmlnZ2VyIGNh bmRpZGF0ZSBwYWlycyB0aGF0IHdvcmsuDQoNCk1lIGFuZCBKdXN0aW4gcHV0IHRvZ2V0aGVyIGEg ZHJhZnQgdGhhdCB1cGRhdGVzIFJGQyA4NDQ1LCBieSBpbmRpY2F0aW5nIHRoYXQgYW4gSUNFIGFn ZW50IHNob3VsZCB3YWl0ICh0aGVyZSBpcyBhIHN1Z2dlc3RlZCBkdXJhdGlvbikgZm9yIHJlbW90 ZSBjb25uZWN0aXZpdHkgY2hlY2tzIGJlZm9yZSBpdCB0cmlnZ2VycyBJQ0UgZmFpbHVyZS4NCg0K TGluazoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbWJlcmct aWNlLXByZW1hdHVyZS8NCg0KRm9yIHRoZSBHaXRIdWIgZmFuczoNCg0KaHR0cHM6Ly9naXRodWIu Y29tL2NkaDR1L2RyYWZ0LWljZS1wcmVtYXR1cmUNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== --_000_14802D65D27C4AF5B7F278004B2354EDericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAy LjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZZSSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGlzIGlzIHJl bGV2YW50IHRvIFJUQ1dFQiwgYXMgaXQgTUFZIGJlIHNvbWV0aGluZyB3ZSB3YW50IHRvIHJlZmVy ZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkNocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgMjcgRmVicnVhcnkgMjAxOSBhdCAxNy4wOTxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7aWNlQGlldGYub3JnJnF1b3Q7ICZsdDtpY2VAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtpY2UtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtp Y2UtY2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5EcmFmdCBuZXc6IGRy YWZ0LWhvbG1iZXJnLWljZS1wcmVtYXR1cmUtMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksIDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRvZGF5LCA4NDQ1IGRl ZmluZXMgdGhhdCBpZiBhbiBJQ0UgZW5kcG9pbnQgZGlzY2FyZHMgaXRzIGNhbmRpZGF0ZXMgYW5k IGlzIG5vdCBhYmxlIHRvIGZvcm0gY2FuZGlkYXRlIHBhaXJzLCBvciB3aGVuIHRoZSB0ZXN0IG9m IGFsbCBwYWlycyBmYWlsLCB0aGUgSUNFIGFnZW50IHdpbGwgdHJpZ2dlciBJQ0UgZmFpbHVyZS4N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5UaGUgSUNFIGFnZW50IG1heSBkbyB0aGlzIGJlZm9yZSBpdCBoYXMgcmVj ZWl2ZWQgYW55IGNvbm5lY3Rpdml0eSBjaGVja3MgZnJvbSB0aGUgcmVtb3RlIHBlZXIsIGFuZCBz dWNoIGNvbm5lY3Rpdml0eSBjaGVja3MgbWlnaHQgdHJpZ2dlciBjYW5kaWRhdGUgcGFpcnMgdGhh dCB3b3JrLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1lIGFuZCBKdXN0aW4gcHV0IHRvZ2V0aGVyIGEgZHJhZnQg dGhhdCB1cGRhdGVzIFJGQyA4NDQ1LCBieSBpbmRpY2F0aW5nIHRoYXQgYW4gSUNFIGFnZW50IHNo b3VsZCB3YWl0ICh0aGVyZSBpcyBhIHN1Z2dlc3RlZCBkdXJhdGlvbikgZm9yIHJlbW90ZSBjb25u ZWN0aXZpdHkgY2hlY2tzIGJlZm9yZSBpdCB0cmlnZ2VycyBJQ0UgZmFpbHVyZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+TGluazo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaG9sbWJlcmctaWNlLXByZW1hdHVyZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWhvbG1iZXJnLWljZS1wcmVtYXR1cmUvPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5Gb3IgdGhlIEdpdEh1YiBmYW5zOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2dpdGh1 Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXByZW1hdHVyZSI+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1 L2RyYWZ0LWljZS1wcmVtYXR1cmU8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_14802D65D27C4AF5B7F278004B2354EDericssoncom_-- From nobody Wed Feb 27 17:33:47 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DF51277D2; Wed, 27 Feb 2019 17:33:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <155131762558.13980.18344455416535381001@ietfa.amsl.com> Date: Wed, 27 Feb 2019 17:33:45 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-26.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:33:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : JavaScript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-26.txt Pages : 115 Date : 2019-02-27 Abstract: This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 27 17:41:15 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6E9130EAB for ; Wed, 27 Feb 2019 17:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_h9W6JSEQ99 for ; Wed, 27 Feb 2019 17:41:12 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 3BC9D1277D2 for ; Wed, 27 Feb 2019 17:41:12 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id w18so12386900itj.4 for ; Wed, 27 Feb 2019 17:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jCb010/xAdhrw9PR8lW5qPD1SMLWtzqnmFT1sO1RGr4=; b=DS+Oaa4LAp2FZdjkACbvZHNg8f16PeJjWRKvCJjVNeEGRcNXANv0jEBltoG4Yd9nJV g3+AEYOll5BjbUv66XOVRqQ9NKmv+3d7uLyeA9pEF342cYSwfYmoh9LnGlD/QutPyUzr D7gBNgncpyBRC5y6oGgSMynlyusBRqr3ncXDiOxJ93ngUu0XXHdx2GuPPbHKhxkM/eh5 986EvXkBo7AQdXyoULSa8Zc2Q2CQDua64ffmljbHYH+bc7pkfz//iNvNgfgvnhGuAwZs 9ORgqzup73SI0NPOkDKFhfm81k/ANRpnY6Kov041fsJs8IHW+kxgqpjlVmofG4LlEUzq qZQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jCb010/xAdhrw9PR8lW5qPD1SMLWtzqnmFT1sO1RGr4=; b=goVXDfWVgZk0gpXZtkQXq8M7kIkZB3n/K+Cdeg7tiAKtGugCy2ERoV8asgjdxfJt4J x+ASw9HRZDz/sRbhwFoXvhJcx6irsTvhkQyOsVfvDw34YI9NUlnlxAt2hV3hNQxFk88L dffYYNtkRs2ddsKwfUDMt7n8D2oAPKEFrI/jv9QCmzJDiIgSN91bCYWiNme/7wZjFdZd k+6iITEqQIX+X2lEGBWRm14KTaCdbksjbBiI1GGHLWlQ7SBkVUcruzPoYGUN1PLbKvzk h+Y8D3K7s/sEghTruuSqguy10jgyx4vvXjjuNiCIh/l/4sXuq0uIYRJB3v3eqwrRl094 6s5g== X-Gm-Message-State: AHQUAua0w70G/ohDvuKy15zxArCm7TsUApQVJ2v96rAmxoPjYFJhhcGd mftpHcPw332pOTJqAHeDWQKmvJLov17u+xh5LtWtEtBKD0Y= X-Google-Smtp-Source: AHgI3IYMMJQTdOrBNhGODUFtrELh95e2RTfyUOZj3BHvq3CqoPKzQEs3ynfxptKhwwXS/CBanfYGULCCH23zEv8tcSc= X-Received: by 2002:a02:313:: with SMTP id y19mr3184922jad.88.1551318070715; Wed, 27 Feb 2019 17:41:10 -0800 (PST) MIME-Version: 1.0 References: <155131762558.13980.18344455416535381001@ietfa.amsl.com> In-Reply-To: <155131762558.13980.18344455416535381001@ietfa.amsl.com> From: Justin Uberti Date: Wed, 27 Feb 2019 17:40:58 -0800 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000008a52fd0582ea6210" Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-26.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 01:41:14 -0000 --0000000000008a52fd0582ea6210 Content-Type: text/plain; charset="UTF-8" This update of JSEP addresses the open issues around session id generation and m= line profile selection. On Wed, Feb 27, 2019 at 5:33 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Real-Time Communication in WEB-browsers > WG of the IETF. > > Title : JavaScript Session Establishment Protocol > Authors : Justin Uberti > Cullen Jennings > Eric Rescorla > Filename : draft-ietf-rtcweb-jsep-26.txt > Pages : 115 > Date : 2019-02-27 > > Abstract: > This document describes the mechanisms for allowing a JavaScript > application to control the signaling plane of a multimedia session > via the interface specified in the W3C RTCPeerConnection API, and > discusses how this relates to existing signaling protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-26 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-26 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000008a52fd0582ea6210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This update of JSEP addresses the open issues around sessi= on id generation and m=3D line profile selection.

On Wed, Feb 27, 2019 at 5:= 33 PM <internet-drafts@ietf.= org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= JavaScript Session Establishment Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eric Rescorla
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-jsep-26.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 115
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-02-27

Abstract:
=C2=A0 =C2=A0This document describes the mechanisms for allowing a JavaScri= pt
=C2=A0 =C2=A0application to control the signaling plane of a multimedia ses= sion
=C2=A0 =C2=A0via the interface specified in the W3C RTCPeerConnection API, = and
=C2=A0 =C2=A0discusses how this relates to existing signaling protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= rtcweb-jsep/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-j= sep-26
https://datatracker.ietf.org/doc/html= /draft-ietf-rtcweb-jsep-26

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-rtcweb-jsep-26


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

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

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000008a52fd0582ea6210-- From nobody Thu Feb 28 04:09:53 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F06124BAA; Thu, 28 Feb 2019 04:09:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-rtcweb-ip-handling@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155135578600.28760.5168168372267952324.idtracker@ietfa.amsl.com> Date: Thu, 28 Feb 2019 04:09:46 -0800 Archived-At: Subject: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-rtcweb-ip-handling-11=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 12:09:46 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-rtcweb-ip-handling-11: 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-ip-handling/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To me this doc reads more like a BCP. Thanks for replying to the TSV-ART review (and thanks, Joe, for the review)! Please edit the doc accordingly. From nobody Thu Feb 28 10:00:15 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2719B12F1AB; Thu, 28 Feb 2019 10:00:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-rtcweb-security@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155137680815.28736.10104782585142415268.idtracker@ietfa.amsl.com> Date: Thu, 28 Feb 2019 10:00:08 -0800 Archived-At: Subject: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-rtcweb-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 18:00:08 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-rtcweb-security-11: 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-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this document is clearly informational. Other RTCweb documents should refer this document informatively and only reference the sec arch doc normatively. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would have also expected some discussion about the risks to the user if the browser gets corrupted, as indicated by the trust model presented in draft-ietf-rtcweb-security-arch. Alternatively, this document could go in the appendix of draft-ietf-rtcweb-security-arch instead. From nobody Thu Feb 28 10:00:31 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0575B130F8E; Thu, 28 Feb 2019 10:00:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-rtcweb-security-arch@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, sean@sn3rd.com, rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155137681601.28667.4721382539333995604.idtracker@ietfa.amsl.com> Date: Thu, 28 Feb 2019 10:00:16 -0800 Archived-At: Subject: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-rtcweb-security-arch-18=3A_=28with_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 18:00:24 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-rtcweb-security-arch-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) This is related to my discuss on draft-ietf-rtcweb-security. I think I don't fully understand the split between those two documents, as section 4.2 seems to introduce a normative reference to draft-ietf-rtcweb-security: "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) media consent verification is provided via ICE. " However, given that section 6.3 actually normatively (re-)states the ICE requirements as well, I would maybe recommend to instead say: "As described in ([I-D.ietf-rtcweb-security]; Section 4.2) and stated in section 6.3 media consent verification is provided via ICE. " and then move the reference to draft-ietf-rtcweb-security to informative. 2) I would have also expected some discussion in the security considerations sections about the risks to the user if the browser gets corrupted, as indicated by the trust model presented in sec 3. 3) In Sec 9.2: "Combined WebRTC/Tor implementations SHOULD arrange to route the media as well as the signaling through Tor. Currently this will produce very suboptimal performance." Maybe make these sentences a bit more general, e.g. "Combined WebRTC/anonymity service implementations SHOULD arrange to route the media as well as the signaling through the anonymity network. Currently with e.g. Tor this will produce very suboptimal performance. From nobody Thu Feb 28 12:11:51 2019 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4A4130F85; Thu, 28 Feb 2019 12:11:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Vijay Gurbani To: Cc: draft-ietf-rtcweb-ip-handling.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155138469731.28638.15165601679967743186@ietfa.amsl.com> Date: Thu, 28 Feb 2019 12:11:37 -0800 Archived-At: Subject: [rtcweb] Genart last call review of draft-ietf-rtcweb-ip-handling-11 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 20:11:38 -0000 Reviewer: Vijay Gurbani Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-rtcweb-ip-handling-?? Reviewer: Vijay K. Gurbani Review Date: 2019-02-28 IETF LC End Date: 2019-02-15 IESG Telechat date: 2019-03-07 Summary: Ready as a proposed standard with 1 minor comment and some nits. In the enumeration below, "Sn" stands for "Section n". Major issues: Minor issues: - S8: Perhaps a short sentence like the following one is a bit more descriptive than the current text in the section. (Please feel free to use your editorial discretion to disregard this comment, just that it does not hurt to be explicit in standard documents. At least that is my opinion.) This document has described leak of IP address privacy when WebRTC engages in peer-to-peer connections. This document suggests mitigations against the leak of this privacy in the form of four different modes of WebRTC communications that explicitly guide the WebRTC developer in making an informed choice on how private the peer-to-peer communication should be. Nits/editorial comments: - S3: s/private physical\/virtual/private physical or virtual/ - S3: OLD: ...exposed upwards to the web application, so that they can be communicated to the remote endpoint for its checks. NEW: ...provided to the web application so they can be communicated to the remote endpoint for connectivity checks. - S3: s/concerns, #1/concerns, the first/ (Similarly for other places where you have #2, etc. Better to be pedantic and minimize colloquialism when writing RFCs.) - S4: s/As a result, we want to avoid blunt solutions/As a result, the preference is to avoid blunt solutions/ (Reason: Pronouns like "We" are fine for academic paper, but perhaps avoided in RFCs.) - S6.2: - s/sent to the web application host/sent to the remote web application host/ - s/and TCP get the same routing/and TCP get the same routing treatment/ Thanks! From nobody Thu Feb 28 13:23:30 2019 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E94D127AC2 for ; Thu, 28 Feb 2019 13:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fiv4B7IkeMpv for ; Thu, 28 Feb 2019 13:23:22 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 5130B126C01 for ; Thu, 28 Feb 2019 13:23:19 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id w6so18476847ljd.7 for ; Thu, 28 Feb 2019 13:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bhcPelD7JcN4DPpY56v0bjesrU1XdwYRKeAanjUGl3I=; b=hOLuXwhCFHMi0PS15fkPXh/U0yN9xrBM7CwJlKGQc7hGgYMsHFGTd5QkP4Ev/jLdv7 KP5eucL/O8U1rH0g+INVWuuJLCH/MkvG89vnUKe519IhhdRcMHi4NX4XxoevZlTO+D9z Ro7G5dnWd2+mjDWc9evoYQPA1swTTi9p7hL0S01K9EqNcnPhuDE77p8ydgjqy5j0VDZy 3Ca4WfmVOzQCKCQ46XaIKQdPzHJc3xiFCDiWDeT7vdvxdGtuwtkofVuBpv6p0FOGtoV3 bId45g0nEQUKkOcpAPFGY0C3gRiXAszIb3GqcQMEbnK7v0l5ssv0qCnzmWqAG1gXLjpB yH8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bhcPelD7JcN4DPpY56v0bjesrU1XdwYRKeAanjUGl3I=; b=IgmhdeadOppLbWXVViaadhYy9vg81XI6aO1Frujbau5bj3VL3P/fpGZX1FXSiPO+4F q1s5RXHxa4CqN/En1duGfXC+zG/9HLfCVDYCLEQBVZz7nra1dRy4Q+mFGew5cy9n1s/Y jc6kkH4NSSe3EBw/prHVUxTHbEL6/xxnxJpu4Ng3yVr+VvhBau2V5w5y9nz+Ur6jwXFl QPZU0Z+0XVXP943NBXd/S4Y6Pa+XEDBomWRO91A9qWZBGB5rAG6ZtQ52J2E3cbw1hCu9 kL+NLUXf9c8Qe2lAVd2P9FP/sS+NiMZWrh3LqfAN3oFnCbJitdnRxWJut6/N2AcwPhZc Xfqw== X-Gm-Message-State: APjAAAW/rjhS2FSGhdJRWsNE3wOyA0IVCTrwZPjipFlYw2OOnEGvDgGA y7tDeIW3lTVsiYMGBF9Ktsenpy6zZnNmSzIsTideFA== X-Google-Smtp-Source: APXvYqx6YDuWa7mXQ57E3jwzSNG6Q42LeO5T4dkqKKkWu9PJztZizYRzO44hIqRZGlUurQqhvoqVa9TcK6DbotJww5E= X-Received: by 2002:a2e:a28f:: with SMTP id k15mr608996lja.160.1551388997418; Thu, 28 Feb 2019 13:23:17 -0800 (PST) MIME-Version: 1.0 References: <155137680815.28736.10104782585142415268.idtracker@ietfa.amsl.com> In-Reply-To: <155137680815.28736.10104782585142415268.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 28 Feb 2019 13:22:39 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-rtcweb-security@ietf.org, Sean Turner , rtcweb-chairs@ietf.org, RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000199a850582fae6ea" Archived-At: Subject: Re: [rtcweb] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-iet?= =?utf-8?q?f-rtcweb-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 21:23:25 -0000 --000000000000199a850582fae6ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 28, 2019 at 10:00 AM Mirja K=C3=BChlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-rtcweb-security-11: 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-security/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I think this document is clearly informational. Other RTCweb documents > should > refer this document informatively and only reference the sec arch doc > normatively. > I don't feel strongly one way or the other. I will defer to the AD. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I would have also expected some discussion about the risks to the user if > the > browser gets corrupted, as indicated by the trust model presented in > draft-ietf-rtcweb-security-arch. Alternatively, this document could go in > the > appendix of draft-ietf-rtcweb-security-arch instead. > Hmm... We generally assume that the browser is uncorrupted. If it is, it's pretty much game over. Can you explain more about your position. --000000000000199a850582fae6ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Feb 28, 2019 at 10:00 AM Mirj= a K=C3=BChlewind <ietf@kuehlewind= .net> wrote:
Mirja K=C3=BChlewind has entered the following ballot position for
draft-ietf-rtcweb-security-11: 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/s= tatement/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-i= etf-rtcweb-security/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I think this document is clearly informational. Other RTCweb documents shou= ld
refer this document informatively and only reference the sec arch doc
normatively.

I don't feel strongly = one way or the other. I will defer to the AD.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I would have also expected some discussion about the risks to the user if t= he
browser gets corrupted, as indicated by the trust model presented in
draft-ietf-rtcweb-security-arch. Alternatively, this document could go in t= he
appendix of draft-ietf-rtcweb-security-arch instead.
<= br>
Hmm... We generally assume that the browser is uncorrupted. I= f it is, it's pretty much game over. Can you explain more about your po= sition.
--000000000000199a850582fae6ea--